Splunk вместо SIEM: индексируем логи и смотрим что происходит

История началась с неприятного звонка. У клиента - сеть на пару сотен узлов, Windows-инфраструктура, межсетевой экран на периметре - в один прекрасный вечер несколько машин в бухгалтерии начали вести себя странно. Тормоза, нетипичные сетевые соединения, жалобы что «что-то не так». Разобрались, вычистили, задышали. И сразу возник вопрос: как давно это происходило и почему никто не заметил раньше?

Ответить было нечем. Логи Windows Event Log на машинах - есть, но разбросаны по хостам, ротация короткая, искать по ним что-либо руками - занятие для мазохистов. Syslog с сетевого оборудования шёл в файлы на сервере, которые никто не читал примерно никогда. Логи с firewall экспортировались раз в неделю в CSV и там и лежали.

Клиент спросил: есть ли что-то, что позволит всё это собирать в одно место и смотреть нормально?

Почему Splunk

Мы присматривались к Splunk какое-то время. Инструмент существует давно, но версия 6, которая вышла в прошлом году, подтянула производительность индексирования и серьёзно улучшила работу с distributed-средой. В корпоративном сегменте он позиционируется в том числе как альтернатива классическим SIEM-системам - с той разницей, что не требует долгой интеграционной работы под конкретную инфраструктуру и гораздо лучше работает с неструктурированными данными.

Классические SIEM - это обычно большой проект: коннекторы, нормализация, правила корреляции, которые надо писать и поддерживать. Splunk другой: засылаешь логи, он их индексирует как есть, дальше пишешь поисковые запросы на SPL (Search Processing Language) и строишь дашборды. Порог входа ощутимо ниже.

Лицензия у Splunk считается по объёму индексируемых данных в день. Для инфраструктуры клиента оценка показала приемлемую цифру - не Enterprise-уровень, но честный платный продукт. Есть бесплатный tier на 500 МБ в день: для тестирования хватает, для реального мониторинга - нет.

Что подключили

Разворачивали в три этапа, каждый раз убеждаясь что предыдущий работает нормально.

Первое - Windows Event Log. На всех серверах и на части рабочих станций (прежде всего бухгалтерия и администраторские машины) поставили Splunk Universal Forwarder - лёгкий агент, который пересылает события на Splunk-сервер. Категории: Security (входы, выходы, изменения привилегий, блокировки учёток), System (старты/остановки служб, ошибки ядра), Application (то что пишут приложения). Event ID-шники для приоритетных событий прописали в конфиге форвардера явно - чтобы не гнать весь поток целиком.

Второе - syslog. Сетевые устройства (коммутаторы, маршрутизатор, VPN-концентратор) настроили на отправку syslog на выделенный порт Splunk. Firewall Cisco ASA - отдельно, там формат лога более многословный и полезный: видны сессии, блокировки, NAT-трансляции. Разбирать всё это руками было бы неудобно, Splunk справляется неплохо - у него есть готовые Technology Add-ons (TA) для типовых устройств, которые умеют парсить конкретные форматы.

Третье - антивирус и AD. Добавили логи с антивирусного сервера (у клиента стоял Kaspersky Security Center) и события из Active Directory - изменения групповых политик, создание/удаление учёток, изменения членства в группах. Это отдельно важно: несанкционированное изменение в AD часто является ранним признаком того, что что-то идёт не так.

Что увидели

Первые несколько дней после запуска были показательными.

Залётные брутфорсы. На RDP-порту одного из серверов, который смотрел наружу, шёл постоянный брутфорс - несколько попыток в минуту с разных IP. Это не новость для любого открытого RDP, но раньше никто это просто не видел. Порт закрыли, доступ перенесли через VPN.

Нестандартное время активности. На дашборде входов в AD нарисовался паттерн: несколько учёток регулярно авторизовывались между двумя и четырьмя ночи. Оказалось - легитимное, резервное копирование запускалось под этими учётками. Но сам факт что мы это увидели и пошли разбираться - уже хорошо. Если бы это оказалось не бэкапом, картина была бы другой.

Хвост от инцидента. Прогнали поиск по логам за период, предшествовавший инциденту. Нашли несколько интересных вещей: нетипичные DNS-запросы с машин бухгалтерии за неделю до обнаружения проблемы, несколько попыток обращения к внешним адресам по портам, которые для этих машин нетипичны. Точно восстановить цепочку не удалось - логи частично утеряны из-за короткой ротации, - но направление стало понятнее.

Про дашборды

Это, пожалуй, самое неожиданное. Мы ожидали что дашборды будут полезны, но думали что они будут просто «красивыми графиками для руководства». На практике они оказались рабочим инструментом.

Основной дашборд безопасности показывает в реальном времени: топ источников событий аутентификации, географию входящих подключений, топ заблокированных соединений на firewall, события с критическими Event ID (4625 - неудачный вход, 4720 - создание учётки, 4728 - изменение членства в группе безопасности). Не нужно ничего руками искать - аномалия сама бросается в глаза, если смотреть на эту картину регулярно.

Построить базовый дашборд на SPL занимает время - язык не очень очевидный поначалу, - но после того как понимаешь логику, это становится быстро. Есть готовые app-ы в Splunkbase, но мы в итоге большую часть запросов написали сами: готовые шаблоны часто не учитывают специфику конкретной инфраструктуры.

Где пока непросто

Не всё идеально.

Алёрты требуют тюнинга. Если поставить алёрты на всё подряд, они превращаются в шум, который перестают читать. Порог чувствительности надо подбирать, и это итеративная работа - несколько недель наблюдений, правок, снова наблюдений.

Объём логов растёт. Планировали 2 ГБ в день - вышло больше после того как включили verbose-режим на firewall. Пришлось пересмотреть что реально нужно индексировать, а что можно хранить в сыром виде отдельно.

Корреляция - это не из коробки. Splunk умеет искать паттерны и строить запросы, но готовых правил корреляции между событиями из разных источников нет - их надо писать самому. Классический SIEM в этом плане даёт больше из коробки, просто ценой интеграционного проекта на старте.

Итог пока предварительный: Splunk как инструмент анализа логов работает и работает хорошо. За несколько недель после запуска клиент впервые получил нормальную картину того, что происходит в сети. Аудит инфраструктуры в таких условиях - это уже не работа вслепую, а разговор с данными. Это само по себе меняет качество диалога с клиентом о безопасности.