Что подключать полезно, а что не очень
Разбираемся с типами логов и какие из них принесут наибольшую пользу, а какие только съедят EPS и мощности SIEM
Когда речь заходит о логировании, первое, что нужно понять: хакеры ломают то, что знают. Они ищут уязвимости в популярных системах и приложениях, потому что это дает им максимальную отдачу при минимальных усилиях. Windows, Linux, веб-серверы (Apache, Nginx), корпоративные приложения (например, SharePoint, Exchange) — всё это излюбленные цели атакующих. А в интернете очень много исследований обо атаках на эти системы.
Типы логов
События операционной системы Логи операционных систем (Windows Event Log, syslog в Linux). Логи аутентификации (успешные и неуспешные входы), логи процессов (запуск/остановка служб), логи изменений в системе (установка ПО, изменения конфигураций). Эти логи помогают обнаружить несанкционированный доступ, повышение привилегий, установку вредоносного ПО.
Логи приложений
Логи, которые генерируют приложения (веб-серверы, базы данных, CMS, корпоративные системы). Эти логи помогают обнаружить атаки на веб-приложения (например, SQL-инъекции, XSS), подозрительную активность пользователей в приложении. Иногда попытки эксплуатации известных уязвимостей или сбор данных.
Логи протоколов К этой категории я отношу логи DNS, DHCP, NTP. Несмотря на потенциальную пользу, это довольно шумные логи. DNS - есть понятный сценарий обнаружения DNS-туннелей или инетгерации с TI-системами. Но в большинстве случаев они заменяются другими источниками. DHCP - могут быть полезны для контекста, когда уже идет ретроспективное расследование, какому узлу принадлежал этот IP-адрес в конкретный момент времени. Но как самостоятельный источник алертов они практически бесполезны. NTP - чтобы что?
Сетевые логи Логи сетевых устройств и сервисов (Firewall, прокси).
Логи межсетевых экранов (разрешенные/заблокированные соединения), логи прокси-серверов (запросы к внешним ресурсам).
Логи безопасности
Логи, которые генерируют системы защиты (антивирусы, EDR, IDS/IPS).
Логи антивирусов (обнаруженные угрозы), логи EDR (подозрительные процессы), логи IDS/IPS (попытки эксплуатации уязвимостей).
Эти логи предоставляют информацию о попытках эксплуатации уязвимостей, вредоносной активности, а также о том, как система защиты реагирует на угрозы.
Приориетет 1. Логи операционных систем.
Логи операционных систем (ОС) — это фундамент для обнаружения атак, потому что практически все действия злоумышленников оставляют следы на уровне ОС.
Логи ОС дают контекст, который нельзя заменить сетевыми логами. Сетевые логи (Firewall, IDS) показывают что происходит на уровне трафика, но логи ОС отвечают на вопросы:
Кто это сделал?
Какие процессы были задействованы?
Какие изменения внесены в систему?
Например, сетевые логи покажут, что хост 192.168.1.10 подключился к IP-адресу в Tor-сети.
Логи ОС добавят:
Это был пользователь j.smith, запустивший процесс tor.exe через PowerShell в 3:00 ночи.
Затем он скопировал файлы из C:\Confidential в скрытую папку.
Без логов ОС вы не поймете, кто именно действовал и что именно было скомпрометировано. Большинство современных атак нацелено на ОС
Ransomware: Шифрование файлов, изменение расширений, удаление теневых копий — всё это фиксируется в логах файловой системы и процессов.
APT-атаки: Установка персистентности через реестр Windows, службы или cron-задачи — все эти действия видны в логах.
Living-off-the-Land: Злоумышленники используют легитимные инструменты ОС (PowerShell, PsExec, WMI), но их аномальное использование легко выявить через логи процессов и команд.
Если вы собираете только сетевые логи или логи приложений, вы видите лишь часть картины. Логи ОС — это основа, без которой эффективное обнаружение и расследование атак невозможно.
P.S. Даже если злоумышленник попытается очистить логи — факт их удаления (Event ID 1102 в Windows) станет последним индикатором компрометации.
Разбираемся с логами приложений
Логи веб-серверов (Apache, Nginx, IIS) могут быть очень шумными из-за большого объема запросов. Многие запросы — это легитимный трафик, который не представляет угрозы. Поэтому логику обнаружения атак на Web-приложения лучше передать WAF (Web Application Firewall). Jy фильтрует трафик на уровне приложения, блокируя подозрительные запросы (SQL-инъекции, XSS, брутфорс). Он заточен под анализ HTTP-трафика, анадизирует заголовки, снимает TLS, может искать аномалии и многое другое. Реализовывать логику обнаружения атак на web на уровне SIEM в большинстве случаев не имеет смысла.
Логи баз данных (MySQL, PostgreSQL, MSSQL) часто содержат огромное количество запросов, большинство из которых также легитимны. Обнаружение SQL-инъекций через логи БД — это как искать иголку в стоге сена.
Имеет смысл алертить использование опасных функций (например, xp_cmdshell в MSSQL). Но как и любое исполнение кода ОС через приложение, отлично обнаруживается на уровне операционной системы.
Атакующие могут использовать легитимные функции приложений (например, создание пользователей в CRM, изменение данных). Такие действия сложно отличить от нормальной работы пользователей, но их несомненно стоит логировать. Это позволит строить baseline действий пользователей, профилировать активность и искать аномалии. А также предупреждать о потенциально опасных операциях, изменении критичных данных (например, финансовых транзакций). Когда заводите то или иное событие от приложения в SIEM, задавайте себе вопрос, какие тут есть данные и чем оно может мне быть полезно. Ну и помните, чем популярнее приложение, тем более вероятно его будут атаковать.
Выявление эксплуатации уязвимости RCE (Remote Code Execution) на уровне приложения. Конечно, конкретную CVE можно часто обнаружить по логам приложения. Но если вендор не предоставляет регулярное обновление контента с покрытием свежих уязвимостей, самостоятельно заниматься поддержкой таких детектов - не самая тривиальная задача. Любая такая уязвимость обнаруживается на уровне операционной системы, потому что эксплуатация всегда сопровождается запуском процессов или создагием файлов. При этом процессы будут запущены от процесса самого приложения и от имени той же самой учетной записи.
Заводя логи приложений в SIEM отвечайте себе на несколько вопрсоов:
Есть ли у вас какой-то контент для обнаружения атак или аномалий в этом приложении
Насколько информативны события этого приложения, позволяют ли они вам отличить легитимную активность от нелегитимной
Возможно есть другие способы/технологии, которые лучше решат задачу обнаружения атак на это приложение (NTA, WAF)
Сетевые логи: кратко и по делу или много и бесполезно
Они не обнаруживают атаки, а лишь фиксируют метаданные.
Они перегружают SIEM, увеличивая затраты и замедляя анализ.
Они бесполезны без контекста от EDR, логов ОС и UEBA.
Если чуть подробнее.
Сетевые логи фиксируют метаданные (IP-адреса, порты, объем трафика), но не дают ответов на вопросы, которые критичны для безопасности:
Кто инициировал трафик? → Нет связи с пользователем или процессом.
Почему это произошло? → Нет данных о запущенных командах или изменениях в системе.
Какие данные были переданы? → Нет информации о содержимом пакетов (особенно если трафик зашифрован).
Пример:
NetFlow показывает, что хост 192.168.1.10 отправил 1 ГБ данных на внешний IP. Это утечка данных? Или просто резервное копирование?
Атакующий передает данные через зашифрованный HTTPS-канал к Google Drive. NetFlow/DNS-логи покажут только соединение с google.com:443. Логи EDR обнаружат запуск powershell.exe с параметрами для шифрования данных.
Сетевые логи создают шум, но не обнаруживают угрозы. Они генерируют миллионы событий в день.
NetFlow: ~10–50 ГБ/день для сети на 1000 устройств.
DNS: ~1 млн запросов/день даже в небольшой организации.
Шум/сигнал: 99% этих данных — легитимный трафик. SOC-аналитики тратят время на фильтрацию мусора вместо работы с реальными угрозами.
Пример: SIEM получает 10 000 DNS-запросов за час. 9 999 из них — запросы к Google, YouTube, Microsoft. 1 запрос — к фишинговому домену. Без интеграции с Threat Intelligence аналитик никогда не найдет эту иголку в стоге сена.
Даже при расследовании инцидентов сетевые логи не дают достаточного контекста. Восстановление цепочки событий требует ответов на вопросы:
Какие процессы были запущены? → Логи ОС.
Какие учетные данные использовались? → Логи аутентификации.
Какие файлы были изменены? → Логи файловой системы.
Пример:
Обнаружен подозрительный трафик на внешний IP.
Сетевые логи: 192.168.1.10 → 54.230.1.20:443.
Логи EDR: Процесс malware.exe запущен пользователем j.smith через фишинговый Excel-файл, который потом открыл соединение на указанный адрес.
Еще сетевые логи могут использоваться для контроля политик и обнаружения нарушений сегментации (например, трафик из DMZ во внутреннюю сеть). Если трафик не должен ходить - проведите аудит и запретите настройками. Это не задача мониторинга безопасности в реальном времени.
Сетевые логи (Firewall, прокси) и логи протоколов (DNS, DHCP, NetFlow) традиционно используются для мониторинга сетевой активности. Однако их роль меняется с появлением современных технологий, таких как NTA (Network Traffic Analysis).
Логи систем безопасности
Логи систем безопасности (антивирусы, EDR, IDS/IPS, WAF) — это мощный инструмент для обнаружения и расследования угроз. Однако их эффективность зависит от того, как вы их используете. Давайте разберем, как превратить эти логи в реальную пользу для SOC.
Заведите не только блокирующие, но и информационные правила Блокирующие правила фиксируют успешные блокировки (например, антивирус удалил вредонос). Информационные правила фиксируют подозрительную активность, которая не была заблокирована, но требует внимания. Они помогают выявить атаки, которые не были заблокированы, но могут быть частью более сложной кампании.
Расследуйте заблокированные угрозы Не закрывайте инцидент только потому, что угроза была заблокирована.
Антивирус удалил вредоносный файл.
Проверьте:
Как файл попал в систему? (например, через фишинговое письмо).
Какие ещё действия выполнял атакующий? (например, запуск процессов, сетевые соединения).
Есть ли признаки компрометации других систем?
Общие рекомендации
Фокус на качестве, а не количестве: Подключайте только те логи, которые действительно помогают обнаруживать угрозы или расследовать инциденты. Логи ОС: Основной источник для обнаружения атак.
Избегайте дублирования: Если есть NTA, не подключайте NetFlow. Если вы анализируете трафик, то можно пожертвовать событиями LDAP-запросов (EventID 1644), логами DNS и DHCP. Нет смысла заводить логи web-приложений, которые находятся за WAF. (А вот логи ОС web-серверов всегда есть смысл заводить)
Расследуйте заблокированные угрозы: Не закрывайте инцидент только потому, что угроза была заблокирована.
Такой подход позволит минимизировать шум и сосредоточиться на действительно важных событиях.
Last updated