Системы класса SIEM традиционно используются для сбора событий ИБ с источников и выявления подозрительных активностей в этих событиях. Однако, системы SIEM можно также использовать в качестве ядра для комплекса автоматического реагирования на выявленные угрозы. По сути, мы получаем некий аналог Intrusion Prevention System. В качестве нашего рабочего инструмента у нас традиционно будет Wazuh. В предыдущих статьях мы уже рассмотрели написание правил нормализации и корреляции для данного SIEM, и теперь мы можем смело подключить любой источник, в котором есть журналы событий и написать любые правила корреляции.
В качестве подозрительной активности, которую нам надо предотвратить мы рассмотрим атаку на веб-ресурс. Вот лишь несколько примеров таких активностей на веб сайтах.
Подбор пароля
Нестареющая классика. В качестве примера можно привести использование переборщика паролей Hydra. Если уязвимый сайт victim_host использует для передачи паролей метод POST, и известно, как выглядит запрос, передающий данные и сообщение о неверном вводе пароля, команда для подбора паролей из файла pass.txt для пользователя admin будет иметь следующий вид:
hydra -l admin -P pass.txt victim_host http-post-form “/dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:Login failed”
Каждая попытка аутентификации должна фиксироваться в логах веб сервера и передаваться в SIEM и, таким образом мы можем выявлять данные атаки.
Кстати, приведенное в примере приложение DVWA содержит много других, интересных уязвимостей, которые тоже можно выявлять с помощью SIEM.
Directory Traversal
Атака с обходом каталога использует недостаточную проверку безопасности или недостаточную очистку предоставленных пользователем имен файлов и путей, так что символы, представляющие «переход в родительский каталог», переда ются в API файловой системы операционной системы. Уязвимое приложение может быть использовано для получения несанкционированного доступа к файловой системе. Например, веб ресурсу можно передать что-то такое: https://localhost/wp-admin/post.php?post=application_id&action=edit&sjb_file=../../../../wp-config.php
И в случае наличия данной уязвимости мы увидим содержимое wp-config.php
Перебор каталогов и файлов - dirbusting
Dirtbusting — это перебор известными имен папок и файлов и отслеживание HTTP-ответов для выявления содержимого сервера. Эта информация может быть использована как для поиска файлов по умолчанию и их атаки, так и для фингерпринта веб-приложения. В качестве примера можно использовать утилиту dirb из состава Kali Linux. Указываем адрес жертвы и словарь: dirb http://127.14.0.1 /usr/share/seclists/Discovery/Web-Content/directory-list-1.0.txt
Признаками такого перебора в логах является большое количество записей со статусом 404, ведь большинство обращений будут идти в пустоту.
Сканирование на уязвимости
В Kali Linux можно найти множество утилит, предназначенных для поиска уязвимостей на веб сайтах. Например, можно попробовать воспользоваться утилитой nikto.
nikto –h victim_host
В логах веб-сервера такие сканеры оставляют много различных интересных следов. И это далеко не полный список возможных атак на веб, которые может попытаться реализовать злоумышленник. В контексте использования SIEM нас будет интересовать IP адрес узла атакующего. Мы будем блокировать доступ к веб-ресурсам с IP-адресов злоумышленников на веб-сервере.
Еще один вариант проверить IP адрес на принадлежность к хакерским ресурсам это воспользоваться базами данных репутации IP-адресов, содержащими информацию о подозрительных узлах.
Общая стратегия
Мы получаем IP адрес узла атакующего либо из логов веб сервера, либо от средства защиты, либо из базы репутаций, но так или иначе, у нас есть адрес узла атакующего. Что мы будем делать дальше? В качестве примера активного реагирования предлагается заблокировать средствами Wazuh доступ к веб серверу узла атакующего, например на 60 секунд. Это позволит отбить у злоумышленников охоту продолжать свои вредоносные действия.
Для реализации этого сценария нам потребуется веб-сервер Apache, который собственно и будет выступать в роли узла жертвы. Здесь нам потребуется модуль активного реагирования Wazuh для автоматической блокировки подключений с конечной точки злоумышленника.
Собираем тестовый стенд
Развернем тестовый веб сервер на который и будут производиться атаки. На сервере для установки Apache выполните следующие действия:
$ sudo apt update
$ sudo apt install apache2
Если брандмауэр включен, измените его настройки, чтобы разрешить внешний доступ к веб-портам. Пропустите этот шаг, если брандмауэр отключен:
$ sudo ufw status
$ sudo ufw app list
$ sudo ufw allow 'Apache'
Проверьте статус сервиса Apache. Он должен быть Running:
$ sudo systemctl status apache2
И в завершении убедитесь в доступности дефолтной веб страницы:
$ curl http://<UBUNTU_IP>
Если с веб сервером все успешно настроено, то можно переходить к настройкам Wazuh. Для этого откроем файл настроек /var/ossec/etc/ossec.conf и настроим мониторинг логов Apache. Для этого в файл нужно добавить следующие строки:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/apache2/access.log</location>
</localfile>Перезапустим агента Wazuh:
$ sudo systemctl restart wazuh-agent
В случае, если у вас в качестве ОС для веб сервера используется Windows, то вы также можете установить Apache. Для этого установите последнюю версию Visual C++ Redistributable package. Далее загрузите установочный файл Apache web server Win64 и распакуйте ZIP архив. Скопируйте содержимое архива например, в папку Apache24 на диске C:.
Далее перейдите в каталог C:\Apache24\bin\ и запустите под административными привилегиями следующую команду PowerShell:
.\httpd.exe
При первом запуске Windows Defender Firewall выдаст запрос для разрешения доступа для веб сервера. Нажмем Allow Access. Это позволит серверу Apache взаимодействовать с внешними сетями. По сути мы создадим входящее соединение на порт 80. Также проверим доступность веб сервера с помощью браузера.
Настройка агента на виндовой машине выполняется аналогичным образом: вносим дополнения в файл настроек агента C:\Program Files (x86)\ossec-agent\ossec.conf, чтобы агент Wazuh мог отслеживать журналы доступа Apache:
<localfile>
<log_format>syslog</log_format>
<location>C:\Apache24\logs\access.log</location>
</localfile>
И перезапустим Wazuh agent в терминале PowerShell с правами администратора, чтобы применить изменения:
Restart-Service -Name wazuh
Wazuh CDB
Прежде чем переходить к настройкам сервера Wazuh поговорим о базах CDB. Constant DB это по сути список в формате ключ : значение. Однако, записи могут содержать только одно значение, например:
10.1.1.1:
Для того, чтобы блокировать узел атакующего нам необходимо добавить IP-адрес атакующего в список CDB, а затем настроить правила и активный ответ. В общем случае мы можем просто создать текстовый файл, в который с помощью правил корреляции будет добавлен выявленный адрес атакующего:
$ sudo echo "<ATTACKER_IP>" >> /var/ossec/etc/lists/alienvault_reputation
Назначим необходимые права и владельца на данный файл
$ sudo chown wazuh:wazuh /var/ossec/etc/lists/blacklist-alienvault
Теперь нам необходимо настроить скрипт для активного реагирования. Для этого добавим в файл /var/ossec/etc/rules/local_rules.xml следующие строки:
<group name="attack,">
<rule id="100100" level="10">
<if_group>web|attack|attacks</if_group>
<list field="srcip" lookup="address_match_key">etc/lists/blacklist-alienvault</list>
<description>IP address found in AlienVault reputation database.</description>
</rule>
</group>
Далее, отредактируем конфигурационный файл Wazuh server /var/ossec/etc/ossec.conf и добавим список etc/lists/blacklist-alienvault в раздел <ruleset>:
<ossec_config>
<ruleset>
<!-- Default ruleset -->
<decoder_dir>ruleset/decoders</decoder_dir>
<rule_dir>ruleset/rules</rule_dir>
<rule_exclude>0215-policy_rules.xml</rule_exclude>
<list>etc/lists/audit-keys</list>
<list>etc/lists/amazon/aws-eventnames</list>
<list>etc/lists/security-eventchannel</list>
<list>etc/lists/blacklist-alienvault</list>
<!-- User-defined ruleset -->
<decoder_dir>etc/decoders</decoder_dir>
<rule_dir>etc/rules</rule_dir>
</ruleset>
</ossec_config>Затем добавим команду firewall-drop, которая вносит изменения в настройки локального файрволла iptables, блокирующие входящие соединения с узла атакующего на 60 секунд:
<ossec_config>
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>100100</rules_id>
<timeout>60</timeout>
</active-response>
</ossec_config>
В завершении перезапустим менеджер:
$ sudo systemctl restart wazuh-manager
Теперь, если адрес атакующего попадет в CDB, то файрволл заблокирует его узел на одну минуту.
А что в консоли Wazuh?
Действия атакующего можно увидеть в консоли нашего SIEM. Для этого нам необходимо открыть модуль Threat Hunting и добавить в поиск следующие фильтры. Для веб-сервера под Linux — rule.id:(651 OR 100100)
Для веб-сервера под Windows - rule.id:(657 OR 100100)
В результате мы получаем отчет о том, сколько попыток обращений было заблокировано.
Заключение
В этой статье мы рассмотрели достаточно простой сценарий, в котором система SIEM не только выявляет подозрительную активность, но и принимает защитные меры по блокировке данной активности. Более сложные сценарии мы с коллегами рассматриваем в рамках практического онлайн‑курса «Специалист по внедрению SIEM». По ссылке вы можете зарегистрироваться на бесплатный вебинар: «Как поймать хакера с помощью SIEM?».