Есть куча систем, созданных для агрегации, систематизации и прочей автоматизации работы с логами, но сегодня я бы хотел выделить Splunk. Это мощное оружие в руках хитрой и умелой команды. Он позволит следить за тонкостями жизни ваших систем, особенно если их много и они достаточно распределенные. И как водится, безопасность — это одна из таких тонкостей, за которой хотелось бы проследить особо. Об этом сегодня и поговорим в общих чертах, ну а в следующий раз я покажу, как его можно использовать для решения некоторых задач ИБ.
Я думаю, большинство так или иначе слышало о Splunk, тем не менее несколько вводных слов я тут напишу. Если коротко, то данный зверь помогает консолидировать логи со всех точек в единую базу.
Допустим, на сервере номер X есть демон, который мониторит N лог файлов и по SSL-каналу пересылает все изменения на сервер Splunk. Там все это консолидируется (ведь есть еще X – 1 серверов), индексируется, фильтруется и уже «бородатый админ», залогинившийся в милый зеленый интерфейс, делает выборку интересных ему событий быстро и без напряга. Есть как бесплатная лицензия (ограничения по объему: 500 метров в день), так и навороченная Enterprise. Ну а поддержка ОС просто великолепна: не только банальные Windows/Linux, но и OS X, и FreeBSD, а кроме того, и такие монстры, как HP-UX и AIX!
Разумеется, это очень полезный инструмент, который поможет отследить кучу информации: от температуры блейдов до нагрузки на CPU или нехватки места на виртуальном диске того или иного сервера. Понятно, что настройка источников логов и прочего — это вопрос отдельный и требует понимания задач и интересов тех, кто будет все это собирать, то есть нас с вами!
Splunk as SIEM
Сбор логов — это, конечно, замечательно, но добротному безопаснику понадобится несколько вещей для работы с этими данными. Ведь если что-то произошло, то надо выделить в логический блок все события из логов, относящиеся к данному инциденту, объединить их в логическую последовательность, при возможности автоматизировать и дать внятное описание. После этого нужно принять меры и задокументировать то, что было сделано.
Вот для таких навороченных систем есть своя ниша, свой рынок и даже свое название — SIEM (Security information and event management). Если обобщить, то SIEM — это такой класс систем для управления и анализа событий и инцидентов безопасности. Это механизм сбора логов и выявления в них событий, относящихся к безопасности. Splunk это умеет, но этого недостаточно, нужно еще управлять инцидентами, например через что-то типа JIRA. То есть Splunk + фильтры Splunk’a + JIRA = SIEM. Да, разумеется, у SIEM есть и иные свойства (комплайнс, корреляция и так далее), но это все детали, которые я тут не умещу.
Кстати, Splunk поддерживает «встраиваемые» приложения (ну типа как плагины на XML + HTML + JavaScript). Конкретно для реализации SIEM-фич есть Splunk App for Enterprise Security, но поставить это можно только на платную/энтерпрайз версию Splunk. Ну и добавим возможность реал-тайм мониторинга с нотификацией ответственных лиц в случае чего! В большой и разветвленной сети без этого точно никуда.
В принципе, можно собрать такую систему и самому (читай: бесплатно), используя Splunk только в роли агрегатора, но тогда придется поработать ручками. Если ты меня спросишь про бесплатный SIEM с «все включено», то я порекомендую OSSIM (в нем есть еще много других вкусностей, но он требует прямых рук и понимания предмета). Но это тема отдельная, которая частично поднималась в статье «Под прессом IT-рисков: обзор Open Source систем управления уязвимостями» за октябрь 2009. Есть и другие представители опенсорса, но все же на рынке больше популярны проприетарные изделия, такие как HP ArcSight (если у тебя денег полно) или SolarWinds Log & Event Manager… в любом случае, каждый выбирает по своим потребностям и возможностям.
Уже много было сказано про плюсы, но вернемся все же к нашей теме — безопасности. Мониторя различные лог-файлы и собирая с них данные, сортируя и упорядочивая, мы легко и в автоматическом режиме можем обнаружить атаки и прочие неприятные вещи. Причем мы думаем теперь только о том, что и как мы собираем, а анализировать можно уже потом и автоматически. И возвращаясь к теме сложности слежения за ситуацией в публичных облаках и облаках вообще: Splunk — идеальное решение, ведь он позволит «объединить» лог-файлы одного логического приложения, которое раскинуто на различных нодах облака, связав все события по временным меткам. Ну и конечно же, Splunk может собирать логи с различных источников — OSSEC, Snort, AppArmor/SELinux или логов аутентификации от SSH, что позволит собирать именно логи, связанные с событиями безопасности.
Начало
Что ж, скачать и установить Splunk довольно легко. Даже если появятся вопросы, как поставить форвардер и настроить его или как открыть сислог-сбор, это все RTFM-стайл вопросы, на которые жалко тратить бумаги, но тут я лишь посоветую уделить внимание менеджменту индексов. Индексирование собираемых данных — важный момент, ведь именно от этого будет зависеть скорость поиска, группирование и даже ограничение доступа различным клиентам. Грубо говоря, можно разным проектам или ролям раздать разные индексы. Скажем, логи с енд-поинтов клиентов (антивирусы, события на рабочках) — это один индекс, а ЕРП-сервис — другой. Фактически это будут разные физические базы данных. Более подробно о конфигурации и развертывании Splunk можно узнать на сайте вендора.
Что будем логировать?
Если наша задача — найти факт проникновения или хотя бы попытку проникновения, то нужно четко определить источники информации, которые нам помогут прямо или косвенно сообщить об этом. Это могут быть логи IDS, логи апача и даже mod_sec или OSSEC, журналы аудита и так далее. Разные лог-файлы имеют разный формат, если ты хочешь сортировать, рисовать графики, выделять нужную информацию — все это возможно сделать в менеджере приложений, правда, придется немного попотеть (в Splunk встроен свой Wizard, но скорее там набор темплейтов XML/HTML). По умолчанию же ты увидишь набор строк, которые сортируются по временным меткам, поэтому очень важно, чтобы в лог-файле были явные временные метки, иначе спланк будет разделять ивенты по своему усмотрению — по отрезку времени мониторинга, за которое было добавлена некая информация. Это плохо: если несколько ивентов были добавлены одновременно, спланк их посчитает за один ивент. После этого уже можно искать события…
Что теперь?
Имея уже солидную базу ивентов, можно смотреть, что было плохо. Для этого можно воспользоваться поиском или состряпать дашборд, ну или скачать готовое приложение (напомню, что для Splunk имеется целая куча бесплатных приложений — для Snort, ModSecurity, OSSEC, логов антивируса и прочего).
В качестве демонстрации мощи Splunk и гибкости языка запросов давай разберем один жизненный пример. Итак, у нас есть некоторый облачный веб-сервис, у него есть доменное имя и какие-то там функциональные скрипты. Если на этот сервис приходит запрос, то в зависимости от IP источника запрос направляется в нужный региональный дата-центр (Европа, Азия, Америка…). Пришедший запрос далее пробрасывается раунд-робином на конкретный виртуальный сервак с Apache. Второй запрос уже попадет в тот же региональный дата-центр, но на другой виртуальный сервак (из-за раунд-робин балансировки), а если клиент поменяет вдруг IP, то следующий запрос пойдет уже в другой дата-центр.
Предположим, что есть «злая» последовательность запросов, которая реализует некую брутфорс-атаку. С учетом архитектуры, в локальных логах Апача будут только отдельные звенья атакующей цепи, однако в Splunk все эти запросы выстроятся в одну цепочку, и таким образом будет обнаружена аномалия на количество запросов к одному логическому ресурсу в единицу времени. Ну вот, к примеру, как это будет выглядеть в строке поиска/фильтра:
index=web-service method=POST url=/service/auth | bucket _time span=1m | stats count by url _time | where count>60
В результате будут найдены все обращения к /service/auth логического ресурса web-service, причем нас интересуют только запросы методом POST. Следующая часть запроса сгруппирует запросы в блоки с периодом в одну минуту, после чего уже следующая часть отсортирует их по времени, в итоге каждый «блок по минуте» будет содержать статистку по количеству событий с данным URL. Ну а последняя часть условия сообщает, что нас интересуют только те минуты, где было более 60 таких событий. Заменив в этой части stats count by url time на stats count by srcip _time, получим то же самое, но уже с сортировкой по IP-адресам, то есть узнаем, с какого IP адреса было больше всего запросов в минуту. Конечно, это лишь один пример того, что «язык» запросов в Splunk очень гибкий и позволяет искать информацию и получать аналитику по самым разным вопросам. Аналогично можно «заменить» логику ModSecurity и искать паттерны SQLi в логах, так как Splunk поддерживает и regexp (по-моему, это уже стрельба из пушки по воробьям, но иногда и такое может быть полезно). Важно понимать, что собираемая в логах информация позволяет вести более адекватный поиск. Формат логов и ваши кастомные приложения в спланке могут оказаться намного полезнее бездумного логирования всего подряд с последующим анализом инцидентов — когда петух уже клюнет и нам надо будет узнать, как нас сломали и что делали злые дяди, вместо того чтобы вовремя определить их активность.
To be continued...
В заключение отмечу еще раз, что Splunk очень мощный инструмент, но основа его мощи — это люди, которые смогут им правильно воспользоваться. Просто даже внедрение и поддержка Splunk требует ресурсов. Конечно, очерк получился очень общим, почти рекламным: я не описывал недостатки, которые тоже имеются, например ограничения по объему трафика в 500 Мб в бесплатной лицензии, жуткий визард приложений, а многие бесплатные приложения написаны словно новичками из ВиндовсМаркета — все как-то недоделано, неполно и «лучше написать самому». В следующий же раз я покажу практическое решение одной задачи, в том числе при помощи именно данного инструмента. Всем Splunk, пацаны!
