Программа для сбора логов

Ставим Elasticsearch и Kibana

Самое время поставить Elasticsearch:

$ sudo apt install elasticsearch
$ sudo systemctl enable elasticsearch

По умолчанию Elasticsearch слушает локальный 9200-й порт. В большинстве случаев лучше так и оставить, чтобы посторонний не мог получить доступ. Если сервис находится внутри сети или доступен по VPN, то можно указать внешний IP и изменить порт, если он уже занят.

$ sudo nano /etc/elasticsearch/elasticsearch.yml
#network.host: 192.168.0.1
#http.port: 9200

Также стоит помнить, что Elasticsearch любит ОЗУ (по умолчанию запускается с -Xms2g -Xmx2g): возможно, придется поиграть значением, уменьшая или увеличивая его в файле /etc/elasticsearch/jvm.options не выше 50% ОЗУ.

С Kibana то же самое:

$ sudo apt-get install kibana
$ sudo systemctl enable kibana
$ sudo systemctl start kibana

По умолчанию Kibana стартует на localhost:5601. В тестовой среде можно разрешить подключаться удаленно, изменив в файле /etc/kibana/kibana.yml параметр server.host. Но так как какой-то аутентификации не предусмотрено, лучше в качестве фронта использовать nginx, настроив обычный proxy_pass и доступ с htaccess.

Добавляем шаблон индекса в Kibana

После этого, если агенты подключены нормально, в секции Discover начнут появляться логи.

Далее последовательно переходим по вкладкам, настраиваем графики и Dashboard.

Меню выбора графиков

Готовые установки Dashboard можно найти в Сети и импортировать в Kibana.

$ curl -L -O http://download.elastic.co/beats/dashboards/beats-dashboards-1.3.1.zip
$ unzip beats-dashboards-1.3.1.zip
$ cd beats-dashboards-1.3.1/
$ ./load.sh

После импорта переходим в Dashboard, нажимаем Add и выбираем из списка нужный.

У семи нянек дитя без глаза

Когда компания начинает всерьез заниматься информационной безопасностью, ей приходится внедрять огромное количество разнородных систем. Антивирус, межсетевой экран, сетевая система обнаружения вторжений (NIDS), хостовая система обнаружения вторжений (HIDS), Web Application Firewall (WAF), сканер уязвимостей, система контроля целостности — и это далеко не самый полный список того, что может использоваться в организации. Поскольку безопасность — это не только состояние системы (в классическом определении), но и процессы, неотъемлемой частью которых является мониторинг событий ИБ, рано или поздно появится необходимость централизованного наблюдения и анализа логов, которые в огромном количестве могут генерироваться перечисленными системами.

И если ты захочешь проанализировать эти логи все вместе, то столкнешься с несколькими проблемами. Первая проблема заключается в том, что практически у всех источников логов свой собственный формат. При этом некоторые системы могут писать логи в нескольких разных форматах, отличающихся уровнем информативности.

Системы обнаружения вторжений с открытым исходным кодом — практически полная противоположность. Snort NIDS имеет четыре различных формата логов. Один из них, unified2, — бинарный. Для его обработки требуется сторонняя утилита barnyard2. Зато этот формат, в отличие от остальных, может содержать расшифрованные заголовки протоколов прикладного уровня. Три других формата текстовые, два многострочные и один однострочный. Уровень информативности текстовых форматов по понятным причинам различается — от только описания сигнатуры и адресов сокетов до расшифровки заголовков протоколов транспортного уровня. Для примера — формат alert_full выглядит следующим образом:

А формат alert_fast:

OSSEC HIDS имеет меньшее количество форматов логов, всего два — однострочный и многострочный. Зато несколько способов передачи: запись в файл, отправку по протоколу syslog, отправку на ZeroMQ-сервер. Сам формат и содержание лога в большой степени зависит от того, как настроен OSSEC и какие в нем модули. Заголовок у всех сообщений OSSEC одинаковый, но если используется модуль контроля целостности syscheck, то после заголовка, в зависимости от настроек модуля, будут присутствовать контрольные суммы измененного файла и diff его изменений. Но если этот же alert отправляется по протоколу syslog, то diff’а он содержать не будет. Если сообщение сформировано модулем анализа логов log analysis, то будет приведено оригинальное сообщение системного журнала, которое вызвало срабатывание. И таких вариаций довольно много.

При таком разнообразии форматов и способов хранения анализ логов всех этих систем может стать довольно трудоемким процессом. Конечно же, для упрощения подобных задач уже существует специальный класс ПО — SIEM. И если хороших систем обнаружения вторжений с открытым исходным кодом хватает, то вот SIEM с открытым исходным кодом практически нет. Существует довольно много решений для конкретной IDS. Например, Snorby для Snort или Analogi для OSSEC. Но возможности добавить в эти системы какие-то дополнительные источники событий не предусмотрено. Есть системы, которые обладают и более широкими возможностями, но, скорее, представляют собой бесплатные версии коммерческих решений с целым набором искусственных ограничений. Я встречал даже такую систему, в которой разработчики намеренно переписали запросы к БД, чтобы сделать их более медленными. Но даже эти системы имели не самый дружественный пользователю интерфейс. Вот и получается, что у семи нянек дитя без глаза.

NewRelic

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

Loggly

Этот сервис уже специально заточен для анализа журналов и позволяет агрегировать любые виды текстовых логов. Ruby, Java, Python, C/C++, JavaScript, PHP, Apache, Tomcat, MySQL, syslog-ng, rsyslog, nxlog, Snare, роутеры и свитчи — неважно. Бесплатно можно собирать до 200 Мб в день (что немало), а ближайший платный тариф начинается от 49 долларов. Работает очень здорово.

Установка Filebeat

Для установки предлагаются apt- и yum-репозитории, deb- и rpm-файлы. Метод установки зависит от задач и версий. Актуальная версия — 5.х. Если все ставится с нуля, то проблем нет. Но бывает, например, что уже используется Elasticsearch ранних версий и обновление до последней нежелательно. Поэтому установку компонентов ELK + Filebeat приходится выполнять персонально, что-то ставя и обновляя из пакетов, что-то при помощи репозитория. Для удобства лучше все шаги занести в плейбук Ansible, тем более что в Сети уже есть готовые решения. Мы же усложнять не будем и рассмотрим самый простой вариант.

Подключаем репозиторий и ставим пакеты:

В Ubuntu 16.04 с Systemd периодически всплывает небольшая проблема: некоторые сервисы, помеченные мейнтейнером пакета как enable при старте, на самом деле не включаются и при перезагрузке не стартуют. Вот как раз для продуктов Elasticsearch это актуально.

$ sudo systemctl enable filebeat

Все настройки производятся в конфигурационном файле /etc/filebeat/filebeat.yml, после установки уже есть шаблон с минимальными настройками. В этом же каталоге лежит файл filebeat.full.yml, в котором прописаны все возможные установки. Если чего-то не хватает, то можно взять за основу его. Файл filebeat.template.json представляет собой шаблон для вывода, используемый по умолчанию. Его при необходимости можно переопределить или изменить.

Конфигурационный файл Filebeat

Нам нужно, по сути, выполнить две основные задачи: указать, какие файлы брать и куда отправлять результат. В установках по умолчанию Filebeat собирает все файлы в пути /var/log/*.log, это означает, что Filebeat соберет все файлы в каталоге /var/log/, заканчивающиеся на .log.

filebeat.prospectors:
— input_type: log
paths:
— /var/log/*.log
document_type: log

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

Источники с одинаковым input_type, log_type и document_type можно указывать по одному в строке. Если они отличаются, то создается отдельная запись.

Поддерживаются все типы, о которых знает Elasticsearch.

Дополнительные опции позволяют отобрать только определенные файлы и события. Например, нам не нужно смотреть архивы внутри каталогов:

По умолчанию экспортируются все строки. Но при помощи регулярных выражений можно включить и исключить вывод определенных данных в Filebeat. Их можно указывать для каждого paths.

Если определены оба варианта, Filebeat сначала выполняет include_lines, а затем exclude_lines. Порядок, в котором они прописаны, значения не имеет. Кроме этого, в описании можно использовать теги, поля, кодировку и так далее.

Теперь переходим к разделу Outputs. Прописываем, куда будем отдавать данные. В шаблоне уже есть установки для Elasticsearch и Logstash. Нам нужен второй.

Здесь самый простой случай. Если отдаем на другой узел, то желательно использовать авторизацию по ключу. В файле есть шаблон.

Чтобы посмотреть результат, можно выводить его в файл:

Нелишними будут настройки ротации:

shipper:
logging:
files:
rotateeverybytes: 10485760 # = 10MB

Это минимум. На самом деле параметров можно указать больше. Все они есть в full-файле. Проверяем настройки:

$ sudo systemctl start filebeat
$ sudo systemctl status filebeat

Сервис может работать, но это не значит, что все правильно. Лучше посмотреть в журнал /var/log/filebeat/filebeat и убедиться, что там нет ошибок. Проверим:

Еще важный момент. Не всегда журналы по умолчанию содержат нужную информацию, поэтому, вероятно, следует пересмотреть и изменить формат, если есть такая возможность. В анализе работы nginx неплохо помогает статистика по времени запроса.

Поддерживаемые типы данных

Каждый плагин для Fluentd обладает определённым набором параметров. Каждый параметр в свою очередь ассоциируется с определенным типом данных. Приведём список типов данных, которые поддерживаются в Fluentd:

Расширяем возможности

В Fluentd используется 5 типов плагинов: плагины вывода, плагины ввода, плагины буферизации, плагины форм и плагины парсинга.

Плагины ввода

Плагины ввода используются для получения догов из внешних источников. Обычно такой плагин создает потоковый сокет (thread socket) и прослушивающий сокет (listen socket). Можно также настроить плагин так, что он будет получен данные из внешнего источника с определённой периодичностью. К плагинам ввода относятся:

Стек ELK

После установки сервисов логи разбросаны по каталогам и серверам, и максимум, что с ними делают, — это настраивают ротацию (кстати, не всегда). Обращаются к журналам, только когда обнаруживаются видимые сбои. Хотя нередко информация о проблемах появляется чуть раньше, чем падает какой-то сервис. Централизованный сбор и анализ логов позволяет решить сразу несколько проблем. В первую очередь это возможность посмотреть на все одновременно. Ведь сервис часто представляется несколькими подсистемами, которые могут быть расположены на разных узлах, и если проверять журналы по одному, то проблема будет не сразу ясна. Тратится больше времени, и сопоставлять события приходится вручную. Во-вторых, повышаем безопасность, так как не нужно обеспечивать прямой доступ на сервер для просмотра журналов тем, кому он вообще не нужен, и тем более объяснять, что и где искать и куда смотреть. Например, разработчики не будут отвлекать админа, чтобы он нашел нужную информацию. В-третьих, появляется возможность парсить, обрабатывать результат и автоматически отбирать интересующие моменты, да еще и настраивать алерты. Особенно это актуально после ввода сервиса в работу, когда массово всплывают мелкие ошибки и проблемы, которые нужно как можно быстрее устранить. В-четвертых, хранение в отдельном месте позволяет защитить журналы на случай взлома или недоступности сервиса и начать анализ сразу после обнаружения проблемы.

И наконец, Kibana — это веб-интерфейс для вывода индексированных Elasticsearch логов. Результатом может быть не только текстовая информация, но и, что удобно, диаграммы и графики. Он может визуализировать геоданные, строить отчеты, при установке X-Pack становятся доступными алерты. Здесь уже каждый подстраивает интерфейс под свои задачи. Все продукты выпускаются одной компанией, поэтому их развертывание и совместная работа не представляет проблем, нужно только все правильно соединить.

В зависимости от инфраструктуры в ELK могут участвовать и другие приложения. Так, для передачи логов приложений с серверов на Logstash мы будем использовать Filebeat. Кроме этого, также доступны Winlogbeat (события Windows Event Logs), Metricbeat (метрики), Packetbeat (сетевая информация) и Heartbeat (uptime).

Logstash

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

Онлайн-сервисы

Самый простой вариант, который на первых порах отлично работал для меня, — использовать облачный сервис. Подобные инструменты активно развиваются, предоставляют поддержку все большего количества технологических стеков и подстраиваются по специфику отдельных IaaS/PaaS’ов вроде AWS и Heroku.

PaperTrail

Отличный сервис, который агрегирует логи приложений, любые текстовые журналы, syslog и прочее. Что интересно: с агрегированными данными можно работать через браузер, командную строку или API. Поиск осуществляется простыми запросами вроде «3pm yesterday» (получить данные со всех систем в три часа ночи за вчерашний день). Все связанные события будут сгруппированы. Для любого условия можно сделать алерт, чтобы вовремя получить предупреждения (изменились настройки в конфигах). Для хранения логов можно использовать S3. В первый месяц дают 5 Гб бонусом, дальше бесплатно предоставляется только 100 Мб в месяц.

Команда героев, которую ждали

Таким образом, у сообщества есть потребность в SIEM из компонентов с открытым исходным кодом, чтобы в ней не было искусственных ограничений и чтобы она обладала такими качествами, как высокая скорость, безопасность и дружественность по отношению к пользователю. Ведь количество угроз информационной безопасности растет с каждым днем. И если ты работаешь в компании из 50 человек, все эти угрозы ее также затрагивают, а бюджет на ИБ, скорее всего, чуть меньше нуля. Ты вполне можешь бесплатно развернуть свободные IDS, а нормальной возможности анализировать их журналы у тебя не будет. После долгих поисков и даже попыток написать SIEM на PHP я нашел решение, которое позволяет вообще не писать программный код и при этом получать неплохие результаты при поиске в логах и сигналах тревоги. Решение состоит в использовании высокоинтегрированного стека приложений ELK — Elasticsearch, Logstash и Kibana. Неплохим дополнением ко всему этому станут плагины Search Guard или Shield. Для объединения всех составных частей: пакетов, конфигов, плагинов и дополнительных скриптов — я написал Ansible playbook и выложил на GitHub под названием LightSIEM.

Резиновый поиск

Центром этого набора является Elasticsearch. Это движок для индексации и поиска по документам, построенный на основе библиотеки Apache Lucene. Разработчиками он позиционируется как возможность создать свой корпоративный Google. Он часто используется как БД для хранения разнородной информации и последующего поиска по ней. Elasticsearch позволяет в режиме реального времени индексировать поток входящих сообщений и вести по ним поиск. Еще одна примечательная особенность Elasticsearch — масштабируемость out of the box. Достаточно просто установить несколько серверов в одной сети, и они найдут друг друга и автоматически распределят между собой хранение индексов. Разумеется, в обработке поискового запроса участвуют все серверы. Все манипуляции, в том числе CRUD, в Elasticsearch выполняются с помощью REST API.

Универсальный конвертер

Все запросы и ответы — в формате JSON, поэтому, чтобы передавать логи в Elasticsearch, нам понадобится Logstash. Его основная функция — конвертация логов из одного формата в другой. В нашем случае из обычного файла или syslog-сообщения мы будем получать JSON-документ, который будет отправляться прямиком на индексацию в Elasticsearch. Logstash очень гибок в настройках благодаря огромному количеству плагинов. Один из самых полезных — это grok. Его основная задача состоит в том, чтобы проверить, соответствует ли полученная на вход строка или строки одному из заданных паттернов. Паттерны grok — это регулярные выражения на стероидах. Во-первых, они позволяют собрать довольно сложные выражения из элементарных блоков. Во-вторых, они позволяют разбить все входящие сообщения на множество полей, каждое из которых будет иметь свое название и смысл. Примерно такой JSON-документ получается на выходе:

Как я уже упоминал, некоторые IDS пишут в свои логи намного больше информации, чем могут отправить по протоколу syslog. То есть события от таких систем оптимально читать непосредственно из многострочного лог-файла, куда они пишут свои сообщения. Долгое время единственным вариантом обработки таких файлов была непосредственная установка Logstash на тот же сервер, где стоит IDS. Не всех устраивал такой вариант, поскольку Logstash при обработке больших объемов логов может давать ощутимую нагрузку на CPU и потреблять довольно много памяти. Кроме того, Logstash написан на JRuby и, соответственно, требует установки на сервер Java, что также не для всех желательно. Специально для таких случаев была разработана отдельная утилита Lumberjack. Позднее ее переименовали в Logstash forwarder, а после этого проект был полностью переписан и получил название Filebeats. Кроме того, в семействе Beats появилось еще несколько утилит: Packet для обработки сетевого трафика, Winlog для отправки в Logstash нативных логов Windows EventLog и другие. Я уже писал, что проекты, связанные с ELK, развиваются очень стремительно, и путь от Lumberjack к Beats — тому отличный пример. Единственная задача Beats — прочитать данные из источника, например файла с логом, и отправить их на сервер Logstash. Эта утилита потребляет очень мало ресурсов, проста в конфигурировании, написана на Go и, следовательно, не требует установки Java. Кроме того, авторы Beats входят в команду разработчиков ELK, а значит, проблемы совместимости протоколов, их реализаций и возможность потерять данные тут минимальны.

Прекрасный цветок «Кибаны»

Из компонентов приятнее всех для пользователя Kibana. Это веб-интерфейс, позволяющий составлять запросы к Elasticsearch, строить различные графики, гистограммы и всячески визуализировать полученные поисковые результаты. Разумеется, просмотреть найденные документы с учетом всех извлеченных в Logstash полей тоже можно. Все диаграммы и визуализации в Kibana полностью интерактивны. То есть, как только на гистограмме будет выделен временной промежуток, он автоматически добавится в фильтры, и вся панель перестроится с учетом нового условия. Если же, например, щелкнуть по столбику, который показывает уровень сигнала тревоги, то он также добавится в фильтр запроса, и на всех визуализациях и поисковой выдаче мы будем уже наблюдать только события с этим уровнем важности.

Лига безопасного интернета поиска

На самом деле если у тебя есть проблема и ты начинаешь использовать для ее решения Elasticsearch, то у тебя появляется сразу две новые проблемы. Первая — это шифрование трафика. Да, Elasticsearch не предоставляет никакого шифрования ни при осуществлении запросов к его серверам, ни при коммуникации серверов между собой. Вторая проблема заключается в отсутствии привычной для баз данных системы ограничения доступа. Все эти GRANT SELECT ON db2.alerts тут по дефолту отсутствуют. В Elasticsearch любой, кто смог подключиться к порту, может выполнять любые запросы — читать, изменять, удалять данные. Большинство настроек в Elasticsearch хранятся в служебных индексах, и их можно менять на лету с помощью точно таких же REST-запросов. В общем, любой злоумышленник, вооруженный Telnet-клиентом, может по полной нарушать конфиденциальность, целостность и доступность твоего кластера Elasticsearch. А ты в нем хранишь данные о действиях как раз этого самого злоумышленника. Непорядок.

Решать эти задачи предполагалось с помощью плагинов для Elasticsearch. Они появились далеко не сразу, и не все дожили до настоящего времени. Разработка многих была остановлена, так как появился плагин непосредственно от разработчиков Elasticsearch — Shield. Хоть он и требовал покупки лицензии, видимо, многие сочли это более простым решением, чем разработка своего плагина безопасности. Другие плагины попросту не успевали за стремительным развитием Elasticsearch. Ведь каждая новая версия привносила изменения в API. На текущий момент есть два основных плагина, которые обеспечивают шифрование и разделение прав. Shield, как я писал выше, — это коммерческая разработка команды Elasticsearch. Другой — Search Guard — является сторонней разработкой германской компании floragunn. Его исходный код опубликован на GitHub.com. Разработчики оказывают коммерческую техническую поддержку. Search Guard представляет собой набор из двух плагинов — Search Guard SSL и Search Guard. Search Guard SSL обеспечивает шифрование данных между серверами и клиентами. Search Guard служит опциональным дополнением к Search Guard SSL, которое обеспечивает аутентификацию и разграничение прав доступа. Права можно ограничивать как к индексам, так и к типам данных (обязательное для каждого документа Elasticsearch поле _type). Например, можно дать доступ к логам систем обнаружения вторжений только офицерам безопасности. А право просмотра логов сетевого оборудования выдать еще и сетевым администраторам.

Rule them all

Сразу после того, как я в первый раз попробовал связать все компоненты воедино, стало понятно, что повторить этот подвиг с нуля через пару месяцев, скорее всего, будет очень тяжело. Причина тому, как всегда, информационная перегрузка и плохая память. На поиски некоторых настроек уходило ощутимое количество времени, и тратить его снова для устранения той же проблемы не хотелось. Но это еще полбеды. Если хочешь, чтобы твоим решением пользовались, оно должно быть доступным. Для бесплатного ПО главный критерий доступности — простота установки. В моем случае она сильно страдала. Самым очевидным вариантом было написать огромную статью, которая бы показывала, как все устанавливать и настраивать. Отягчало проблему то, что стек ELK довольно новый и мало кто разбирался в нем хорошо. Кроме того, какие-то изменения я вносил почти каждый день. Статья рисковала либо оказаться неактуальной к моменту окончания, либо никогда не быть завершенной. Я подумал, что было бы здорово вместо документации написать скрипт, который был бы понятен любому человеку и при этом еще устанавливал и интегрировал все компоненты вместе. Таким скриптом стала утилита автоматизации Ansible. Она позволила писать так называемые playbook’и, которые с виду выглядят достаточно «человекопонятно», а при запуске программой выполняют сложную и скучную последовательность действий для установки и настройки всех компонентов. Помимо этого, Ansible не требует установки на конечные серверы какого-либо агентского ПО, ей достаточно только доступа по SSH.

Unify them all

Помимо проблемы автоматизации, пришлось решать проблемы сопоставления данных из различных источников информации. Во-первых, у каждого источника событий своя шкала уровней тревоги. В общем случае этот уровень должен показывать, насколько вероятно, что произошла или происходит попытка вторжения. В Snort самая высокая вероятность вторжения обозначается уровнем 1, а самая низкая — уровнем 4. А в OSSEC HIDS самая большая вероятность вторжения находится на 15-м уровне сигнала тревоги, а на уровне 0 — события, которые вообще не заслуживают никакого внимания. Во-вторых, разные системы выдают различные наборы данных. Например, в сигналах тревоги от Snort всегда присутствуют адрес источника и адрес цели потенциальной атаки. В сигналах тревоги от OSSEC, напротив, таких данных вообще может не быть или они могут присутствовать в них косвенно. Для того чтобы все эти разнородные данные можно было хоть как-то сопоставлять, пришлось разработать систему полей, на которые разбиваются все входящие сообщения. За основу я взял стандарт IDMEF — Intrusion Detection Message Exchange Format. В нем уже описана структура данных, которая покрыла 90% всех потребностей.

Разворачиваем LightSIEM

На текущий момент в LightSIEM можно направлять практически любые логи по протоколам syslog или Beats. Но не для любого лога написаны паттерны в Logstash. Самая полная поддержка реализована для OSSEC и Snort. Их логи можно отправлять по протоколу syslog, можно писать их в стандартном многострочном формате в файл, а потом отправлять с помощью Filebeat. Первый вариант удобен тем, что достаточно просто настроить отправку логов по протоколу syslog на нужный сервер — сообщения сразу начнут появляться в SIEM. Как я уже писал в начале статьи, во втором варианте информативность будет выше, но и настройка займет чуть больше времени, так как необходимо поставить дополнительный пакет и настроить его. Поддерживаются также логи сетевого оборудования Cisco — роутеров и межсетевых экранов. Частично реализована поддержка логов Auditd.

Хоть я и постарался максимально упростить установку LightSIEM, давай все же разберем детально, как это сделать, что будет происходить во время запуска playbook’а и как будут обрабатываться поступающие логи. Еще до того, как ты начнешь инсталлировать LightSIEM, неплохо иметь источники данных, которые ты будешь анализировать. Как установить сервер OSSEC, ты можешь почитать в моей статье «За высоким забором OSSEC» в «Хакере» . Может тебе пригодиться и моя статья на Хабре. Для начала нам понадобится отдельный сервер под управлением Linux. Лучше всего подойдет CentOS/RHEL/Oracle версии 7.0 и выше. Playbook оптимизирован именно под эти дистрибутивы, но если ты предпочитаешь другие, то всегда можешь разобраться с тем, что делает playbook, и модифицировать его под свой любимый дистрибутив, попутно закоммитив результат работы к нам на GitHub ;). После того как ты подготовил сервер и настроил на нем сеть с выходом в интернет, необходимо установить на него сам Ansible и unzip. Установить Ansible проще всего из репозитория EPEL. Итого, для начала необходимо выполнить две команды:

yum install epel-release
yum install ansible unzip

wget https://github.com/dsvetlov/lightsiem/archive/v0.2.1.zip
unzip master.zip

Теперь все готово к тому, чтобы запустить playbook и заинсталлить все необходимое для LightSIEM:

Вкратце поясню, что делает скрипт. Прежде всего инсталлируются официальные репозитории Elasticsearch. Затем из них уже устанавливаются все основные компоненты — Logstash, Elasticsearch и Kibana. Далее выкладываются конфиги для Logstash. Они разделены на несколько отдельных файлов, чтобы было проще ориентироваться в них. Их назначение разберем чуть позже. Скрипт также устанавливает дополнительные паттерны для grok. Это отдельные файлы с описанием регулярных выражений, которыми потом парсятся входящие сообщения. Также скрипт открывает порты в firewalld. Если на своей системе ты его заменил на iptables — не беда. Скрипт проигнорирует эти ошибки, но порты тебе придется открыть самостоятельно. После этого всего скрипт устанавливает Search Guard и заливает несколько дашбордов для Kibana.

Итак, LightSIEM ты установил, порты открыл. Теперь необходимо направить в него алерты из OSSEC. Самый простой способ сделать это — вписать в главной секции конфига сервера следующие строки:

После этого в игру вступает файл конфигурации, который называется common. Как и следует из его названия, он участвует в обработке абсолютно всех логов. Его основная задача — обогащение наших событий дополнительной информацией.

Получаем из логов события

После этого необходимо из полей, куда попали временные отметки, извлечь и преобразовать время. Тут разнообразие вариантов того, как записываются временные отметки, тоже иногда удивляло.

Поскольку даже при большом объеме событий необходимо их быстро разрешать, в состав LightSIEM вошел DNS-сервер dnsmasq. Чтобы не увеличивать площадь поверхности атаки на сервер и не открывать вовне еще один порт, Ansible устанавливает и настраивает dnsmasq слушать только адрес loopback-интерфейса. Так как на каждом сервере свои собственные настройки DNS-серверов для пересылки запросов, в dnsmasq было решено использовать серверы из /etc/resolv.conf, как наиболее универсальный метод по умолчанию. Для уменьшения нагрузки на серверы пересылки запросов и ускорения ответов dnsmasq настроен кешировать ответы от серверов. Таким образом, если из Logstash придет несколько запросов для одного и того же адреса, он будет разрешен только в первый раз, а все последующие ответы уже будут даны из кеша.

Из Logstash все события передаются для хранения и индексации в Elasticsearch. Основная функция Elasticsearch — хранение поступающих данных и их обработка для быстрого поиска. Все данные хранятся в структурах под названием индексы. Каждый индекс должен состоять как минимум из одного шарда. Шард — это сущность, которая содержит часть индекса. Также в состав индекса могут входить реплики. Реплика — это копия шарда, которая располагается на другом сервере и служит для повышения отказоустойчивости и обработки поисковых запросов. Если одного сервера с Elasticsearch не хватает для обработки всей поступающей информации или для последующего поиска по ней, можно очень легко установить дополнительные серверы. Одна из особенностей Elasticsearch заключается в том, что для настройки кластера из нескольких серверов и распределения между ними нагрузки не нужно тратить много времени. Когда серверы оказываются в одной подсети, они автоматически друг друга находят. После этого они автоматически распределяют между собой шарды и реплики. Такая особенность позволяет легко создавать большие кластеры, которые обеспечивают надежность благодаря тому, что реплики каждого шарда распределены между разными серверами, и масштабируемость производительности.

Несмотря на то что динамически создаваемые поля и автоматически определяемые типы данных — очень удобные функции, особенно на этапе разработки, они иногда создают проблемы. Например, если поле с уровнем сигнала тревоги, записанным в виде числа, случайно определится как текстовое, то многие функции, которые используются в Kibana для построения графиков, станут недоступны. Для настройки типа полей, их названия и еще многих параметров используются специальные шаблоны. В общем случае шаблон создается как документ в Elasticsearch и хранится в нем. При этом в свойствах шаблона указывается то, для каких индексов он применяется.

В LightSIEM Logstash создает новый индекс для данных каждый день. Это необходимо для того, чтобы индексы не разрастались и можно было легко удалить данные за определенный день. Упомянутый шаблон задается как опция для отправки данных в Elasticsearch. Таким образом Logstash проверяет, есть ли уже шаблон в Elasticsearch, и, если его еще нет, создает. В шаблоне, в свою очередь, задаются свойства каждого поля — его тип и необходимость в анализе.

Взаимодействие пользователя с SIEM происходит с помощью веб-интерфейса Kibana. Он был разработан специально для работы с Elasticsearch. Позволяет создавать интерактивные панели с графиками (dashboard). Каждый элемент такого графика кликабельный. При клике на него соответствующее значение добавляется в фильтр поискового запроса всей доски, и все графики на ней перестраиваются с учетом этого фильтра. Например, можно вывести на такую доску список из узлов, от которых зарегистрированы события, список узлов, на которые приходили события, и уровней сигналов тревоги. При клике на конкретный сервер в списке источников атак остальные графики перестроятся, и уже можно будет судить о том, с каких серверов на этот сервер приходили атаки и какой у них уровень сигнала. Если после этого кликнуть на какой-то конкретный уровень сигнала тревоги, он также добавится в фильтр, и мы уже сможем увидеть, с каких серверов шли атаки данного уровня опасности на наш сервер.

Kibana может использовать данные GeoIP, которые добавляет Logstash для отображения на карте источников или жертв атак. Очень полезны гистограммы распределения событий во времени. Они позволяют выделить мышкой нужный промежуток времени и также добавляют его в фильтр для всей панели. Таким образом можно быстро выбирать, события из какого временного промежутка необходимо показывать. Естественно, каждое событие можно смотреть и в краткой форме, и в подробной.

Развернуть все у себя

Мои эксперименты с онлайн-сервисами закончились, когда данных стало так много, что за их агрегацию пришлось бы платить трехзначные суммы. Впрочем, оказалось, что развернуть подобное решение можно и самому. Тут два основных варианта.

Fluentd

Если выбирать standalone-решение, то Fluentd мне понравился больше. В отличие от logstash, которая написана на JRuby и поэтому требует JVM (которую я не люблю), она реализована на CRuby и критические по производительности участки написаны на C. Система опять же открытая и позволяет собирать большие потоки логов, используя более 1500 различных плагинов. Она хорошо документирована и предельно понятна. Текущий вариант сборщика логов у меня развернут именно на Fluentd.

Впервые опубликовано в Хакер #03/182

Логирование системных процессов и сетевой активности

Чтобы найти причину ошибки, специалист техподдержки может попросить предоставить логи с рабочего места. Для сбора логов воспользуйтесь инструкцией:

При закрытии программа предложит удалить сертификат из корневого хранилища. Можно выбрать любой вариант.

Logentries

Еще один неплохой сервис для сбора данных, позволяющий собирать до гигабайта логов в месяц бесплатно. А возможности все те же: мощный поиск, tail в режиме реального времени (выводится все, что «прилетает» из логов на текущий момент), хранение данных в AWS, мониторинг PaaS, IaaS и популярных фреймворков, языков. На бесплатном тарифе можно хранить данные за семь дней.

В рамках этой статьи мы описываем процедуру установки для ОС Ubuntu 14.04. С инструкциями по установке для других операционных систем можно ознакомиться здесь.

Установка и первоначальная настройка Fluentd осуществляются с помощью специального скрипта. Выполним команды:

$ wget http://packages.treasuredata.com/2/ubuntu/trusty/pool/contrib/t/td-agent/td-agent_2.0.4-0_amd64.deb

$ sudo dpkg -i td-agent_2.0.4-0_amd64.deb

По завершении установки запустим Fluentd:

$ /etc/init.d/td-agent restart