В предыдущей статье мы говорили о том, как можно подключить к Wazuh стандартные источники, идущие, что называется, «из коробки». С ними все относительно просто: выполняем действия, представленные в инструкции по подключению Wazuh на источнике (например, перенаправление Syslog), выполняем необходимые правки на стороне агента и все должно начать работать без проблем.
Однако, в реальности все бывает не так просто. Во многих организациях есть самописное или сильно кастомизированное ПО, логи с которых SIEM не умеет нормализовывать. То есть по факту он просто незнаком с данным видом источников. Если такой нестандартный источник передает события по Syslog, то в SIEM, скорее всего, мы увидим событие практически в сыром виде. То есть поля, которые обычно заполняются при нормализации (Source/Dest IP, Username, Hostname и т.д.), в данном случае не будут заполнены.
В этой статье мы поговорим о том, что можно сделать средствами Wazuh для нормализации событий с таких источников. На самом деле, найти пример логов, которые не умеет нормализовывать SIEM из коробки — не так уж и просто. Как правило, сообщения от ОС и основных сервисов нормализуются без проблем. По этой причине при обучении одному коммерческому SIEM в качестве примера логов для нормализации предлагается разбирать логи от кофемашины.
Регулярка — наше всё
Язык регулярных выражений (RegEx) — это формальный язык, используемый в компьютерных программах, работающих с текстом, для поиска и осуществления манипуляций с подстроками в тексте, основанный на использовании метасимволов. Для поиска используется строка-образец, состоящая из символов и метасимволов и задающая правило поиска. Для манипуляций с текстом дополнительно задаётся строка замены, которая также может содержать в себе специальные символы.
При анализе сырых логов нам необходимо использовать язык регулярных выражений для того, чтобы извлекать из сырых событий значения нужных полей. В рамках данной статьи мы не будем подробно рассматривать работу с RegEx, так как этой теме посвящена не одна статья или книга.
Здесь я лишь замечу, что без понимания основных принципов работы регулярных выражений будет крайне сложно написать и отладить собственное правило нормализации.
Пишем новое правило
Для того, чтобы написать собственное правило нормализации для того или иного события нам необходимо прежде всего наличие самого примера события.
Так в примере ниже мы видим событие входа в систему от узла MyHost и процесса example:
Dec 5 22:45:01 MyHost example[12345]: User 'admin' logged from '192.168.1.10'
На самом деле желательно иметь в качестве примеров несколько записей о событиях одного и того же типа. Иногда можно столкнуться тем, что одно и тоже событие в различных случаях может содержать или не содержать те или иные данные.
Для работы с правилами нам потребуются файлы /var/ossec/etc/decoders/local_decoder.xml и /var/ossec/etc/rules/local_rules.xml. Мы рекомендуем создавать новые файлы декодера и правил для более масштабных изменений.
У каждого правила в Wazuh есть свой номер. Для пользовательских правил используйте идентификационные номера от 100000 до 120000.
Вернемся к нашему примеру журнала, соответствующего программе под названием example:
Dec 5 22:45:01 MyHost example[12345]: User 'admin' logged from '192.168.1.10'
Добавим в файл /var/ossec/etc/decoders/local_decoder.xml следующие записи для нормализации логов:
<decoder name="example">
<program_name>^example</program_name>
</decoder>
<decoder name="example">
<parent>example</parent>
<regex>User '(\w+)' logged from '(\d+.\d+.\d+.\d+)'</regex>
<order>user, srcip</order>
</decoder>
Здесь мы определили, как извлекать из сырого события записи, соответствующие нашему приложению example. И далее мы с помощью регулярных выражений извлекаем из сырого события имя пользователя '(\w+)' и IP адрес узла, с которого было осуществлено подключение '(\d+.\d+.\d+.\d+)'. Здесь знатоки RegEx могут докопаться обратить внимание на то, что данное выражение не совсем правильно будет определять шаблон IP адреса. Оно будет реагировать на любые числа с тремя точками. Например, на 995.301.726.553, хотя как мы все знаем, IP адрес не может состоять из таких октетов.
Так что при желании это выражение можно улучшить. Но мы будем считать, что никто не станет специально подавать некорректные данные на вход SIEM.
Далее добавим запись в файл /var/ossec/etc/rules/local_rules.xml.
<group name="custom_rules_example,">
<rule id="100010" level="0">
<program_name>example</program_name>
<description>User logged</description>
</rule>
</group>
На этом с правилами нормализации все. Перейдем к отладке.
Отладка правил
Мы написали обработчик сырых событий, можно конечно сразу перезапустить wazuh-manager и дальше смотреть что же получилось. Но здесь есть ненулевая вероятность, что Manager при рестарте не запустится из-за синтаксических ошибок. И кроме того, в случае, если событие не будет правильно разбираться, не совсем понятно где искать ошибку, как собственно отлаживать правило.
Для отладки правил в состав Wazuh входит утилита wazuh-logtest, предназначенная специально для проверки результатов нормализации. Также, с помощью этой утилиты можно отлаживать правила корреляции, но об этом мы будем говорить в следующих статьях. Итак, для запуска утилиты выполним следующую команду:
sudo /var/ossec/bin/wazuh-logtest
Далее просто в интерактивном передаем примеры сырых событий и смотрим на результаты парсинга:
Dec 25 20:45:02 MyHost example[12345]: User 'admin' logged from '192.168.1.100'
Таким образом, чтобы протестировать ваши правила нормализации с помощью wazuh-logtest, достаточно сохранить внесенные изменения в файлы декодера и правил. Когда вы уверены в том, что сырые события разбираются правильно, а как уже упоминалось ранее, для этого лучше использовать несколько примеров одного и того же события, вам необходимо перезапустить сервис wazuh-manager для того, чтобы правила начали работать в самой системе.
Для этого выполним:
systemctl restart wazuh-manager
В результате мы можем наблюдать нормализованные события в консоли Wazuh.
Заключение
Разработка собственных правил нормализации — процесс непростой и очень увлекательный. И здесь понимание всех нюансов приходит только с опытом. Поэтому я рекомендую самостоятельно попрактиковаться в написании собственных правил для понимания общих принципов нормализации в Wazuh.
Больше практических навыков и инструментов по информационной безопасности вы можете получить в рамках практических онлайн-курсов от экспертов отрасли.
Nec_Romancer
level="0"
в правиле сразу дропнет событие, если не будет поверх другого с этим в <if_sid>. А в примере нет ничего другого, так что ничего он не залогирует.