ELK-стек вместо самописных скриптов: Logstash, Elasticsearch 1.7 и Kibana 4 для централизованных логов

У нас был клиент с инфраструктурой примерно на 40 серверов - Linux и Windows в примерно равных долях. Логи писались куда придётся: syslog на Linux-хостах складывался локально, журналы Windows Event Log никуда не форвардились вообще, а «централизованный сбор» - это rsyslog на одной из машин, который собирал логи с половины серверов, и пара bash-скриптов, которые раз в час парсили эти файлы по ключевым словам и слали письма.

Работало. До первого серьёзного инцидента.

Как выглядел инцидент

В пятницу вечером на одном из сегментов сети пошла странная активность: несколько машин начали генерировать нетипичный трафик, Zabbix показал аномальные значения по сети. Разбирались два часа. Не потому что всё было сложно - а потому что логи были разбросаны. Пока собрали с нужных машин через SSH по одной, пока сопоставили временные метки (у двух машин часы расходились на 4 минуты - отдельная радость), пока нашли первое подозрительное событие - время ушло впустую.

Инцидент оказался несерьёзным: один из серверов подобрал чужие учётные данные и пытался достучаться до соседних машин. Угрозы как таковой не было, но ощущение, что мы смотрим на события постфактум и вслепую - осталось.

После этого разговора с клиентом решили переходить на нормальный централизованный сбор.

Почему ELK

Смотрели на несколько вариантов. Коммерческие SIEM-системы - дорого и избыточно для текущего масштаба. Graylog - интересно, но меньше готовых интеграций. В итоге остановились на ELK: Elasticsearch 1.7, Logstash 1.5, Kibana 4. Стек открытый, документации достаточно, сообщество живое, и главное - Kibana 4 по сравнению с третьей версией стала нормальным инструментом построения дашбордов, а не просто поисковым интерфейсом.

Elasticsearch 1.7 на тот момент - стабильная версия с понятной моделью индексов и хорошей поддержкой агрегаций, которые нужны для дашбордов безопасности.

Архитектура сбора

Схема получилась стандартной, без изысков:

Linux-серверы   -> rsyslog -> Logstash (input: syslog UDP/TCP 514)
Windows-серверы -> NXLog   -> Logstash (input: syslog или beats)
                              |
                         Elasticsearch 1.7
                              |
                           Kibana 4

Linux. На всех серверах rsyslog уже стоял. Добавили форвардинг на центральный Logstash:

*.* @@logstash-host:514

Через @@ - TCP, не UDP. С UDP на нагруженных хостах пакеты терялись.

Windows. Здесь сложнее. Стандартными средствами Windows нормально форвардить Event Log в syslog нельзя - нужен агент. Взяли NXLog Community Edition: он читает Windows Event Log и отдаёт в syslog-формате. Установка через MSI, конфиг минимальный. Ansible-роль для Windows у нас уже была после работы с DSC - завернули установку NXLog туда же.

Logstash. Принимает syslog, парсит через grok-паттерны, добавляет поля (тип источника, хост, environment), отдаёт в Elasticsearch. Grok для syslog - стандартный, для Windows Event Log пришлось написать несколько кастомных паттернов под формат NXLog.

Elasticsearch крутится на отдельной машине - 8 ГБ RAM, SSD. Для 40 серверов с текущим объёмом логов хватает с запасом. Индексы по дням (logstash-YYYY.MM.DD), ротация через curator - держим 30 дней горячих.

Дашборды безопасности в Kibana 4

Kibana 4 - это другой инструмент по сравнению с третьей версией. Там появился нормальный построитель визуализаций с агрегациями, и дашборды можно собирать без написания JSON руками.

Сделали несколько дашбордов:

Первый - обзорный. Количество событий по хостам, динамика за последние 24 часа, топ источников по объёму. Сразу видно, если какой-то хост начал генерировать аномальное количество событий.

Второй - безопасность. Сюда попадают события с severity error и выше, плюс конкретные паттерны: failed login, sudo, privilege escalation, изменения в /etc/passwd и /etc/shadow на Linux; Security-канал Event Log на Windows (4625 - неудачный вход, 4720 - создание пользователя, 4732 - добавление в группу).

Третий - Windows-специфичный. Только Windows-хосты, только Security и System журналы. Отдельно потому что объём и паттерны событий на Windows сильно отличаются от Linux, смешивать неудобно.

Фильтрацию по времени в Kibana 4 сделали хорошо - выбираешь любой промежуток и все визуализации пересчитываются. Для расследования инцидентов это ключевое.

Тот самый инцидент - переигровка

Через три недели после запуска случился похожий эпизод - опять нетипичная активность на одном из сегментов. На этот раз зашли в Kibana, выставили временной диапазон, отфильтровали по хостам сегмента, посмотрели Security-дашборд. За пять минут увидели: несколько попыток SSH-брутфорса с одного внешнего IP, одна успешная попытка аутентификации на машине с открытым паролем (и это отдельный разговор), дальше sudo-команды.

Два часа против пяти минут - разница не в скорости нашей работы, а в том, что данные были в одном месте, с нормальным поиском и временной осью.

Что оказалось неочевидным

Парсинг Windows Event Log. NXLog отдаёт события в своём формате, и grok-паттерны приходится писать отдельно под каждый тип события. Потратили на это больше времени, чем ожидали. Готовых рецептов в интернете мало - в основном все пишут про Linux.

Объём логов. Если включить всё подряд, Elasticsearch быстро забивается. На нескольких хостах с включённым debug-логированием приложения за сутки генерировали больше, чем все остальные 35 серверов вместе. Пришлось настраивать фильтрацию на уровне Logstash - drop для debug-уровня, кроме явно нужных приложений.

Время на серверах. Проблема с расходящимися часами никуда не делась - Elasticsearch хранит @timestamp как есть из события. Там где NTP не был настроен, события в Kibana плыли по временной оси. Параллельно прогнали аудит NTP по всему парку - оказалось, пять машин не синхронизировались месяцами.

Kibana требует Elasticsearch. Звучит очевидно, но на практике: если Elasticsearch перегружен или недоступен, Kibana просто не работает. На первое время сделали мониторинг самого ELK-стека через Zabbix - чтобы знать о проблемах с инфраструктурой логов раньше, чем придёт запрос «а почему Kibana не открывается».

Где сейчас

Стек работает третью неделю на проде. Пока всё стабильно, Logstash на текущем объёме не является узким местом, Elasticsearch не перегревается. Дашборды клиент смотрит сам - там есть один человек, который занимается ИБ, и для него это большой шаг вперёд по сравнению с периодическими письмами от скрипта.

Следующий вопрос, который стоит на очереди - алерты. Сейчас Kibana 4 не умеет присылать уведомления по условию на дашборде, это отдельный инструмент (Elastalert, или самодельное решение поверх Elasticsearch API). Пока оставили Zabbix как основной алертинг, Kibana - для расследований и обзора. Это нормально как промежуточное состояние, но хочется замкнуть цикл.

Managed-сопровождение в таких случаях - это не только поднять стек, но и настроить его так, чтобы он реально использовался.