Elastic stack: анализ security логов

Статья 5: Анализ логов c Active Directory

Содержание статьи

1. Введение
2. Предустановленные дашборды
3. Построенный дашборд
4. Проактивное обнаружение инцидентов
5. Заключение

Введение

Добрый день, коллеги! В прошлой статье мы рассмотрели, как подгружаются события с AD сервера. Следующая задача, которая возникает перед нами — выявить, что вообще мы можем сделать с этими логами, какая польза от них, что необходимо отслеживать. Главная задача — не просто собрать логи, а закрыть те или иные задачи мониторинга инцидентов ИБ в организации, либо задачи бизнеса или инфраструктуры. В рамках данной статьи рассмотрим существующие дашборды, предложим их улучшение и сделаем базовый алерт.

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

Предустановленные дашборды

Базовый дашборд — overview показывает общую информацию и статистику. А именно: общее количество логов за определенный промежуток времени, наиболее часто срабатываемые коды событий, уровень пришедших логов и графическое представление приходящих событий по времени. Как общая статистика данный дашборд применим, но все равно непонятно, какая от него может быть конечная польза. Как вариант, если вдруг произойдёт большое количество событий или ошибок, мы увидим всплеск на графике по отношению к другим временным промежуткам. Затем побежим разбираться, в чем была причина, чтобы исправить проблему. Ну и разумеется, в случае большого количества логов с уровнем ошибка, необходимо разбираться в этом.

Переходим к следующему дашборду:

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

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

Фильтруем события по event.code : 4625 — это код ошибки аутентификации. И изучаем, на каких машинках появляются ошибки, какие пользователи указаны в событиях.

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

Построенный дашборд

Для примера, переделаем дашборд по overview и настроим меню со списком пользователей. В конечном виде построенный дашборд выглядит вот так:

Рассмотрим пару визуализаций отсюда предметным образом.

Это tsvb график. Смотрим количество логов по времени от разных событийных журналов windows. В сумме по всем пользователям информация не так интересна, но позже увидим, что отдельно по пользователям весьма показательна.

Это timelion визуализация. В некоторых случаях она удобна для создания и поднастройки под желания сотрудников. Строится 3 графика на одной оси, которые задаются в текстовом виде:

.es(q='log.level.keyword:information').label(information).lines(fill=1,width=2).color(#006837).title("Event Levels ECS"),

.es(q='log.level.keyword:warning').label(warning).lines(fill=1,width=2).color(#ffffbe),

.es(q='log.level.keyword:error').label(error).lines(fill=1,width=2).color(#a50026).legend(columns=3, position=nw)

Здесь параметр q — это фильтр, label — название графика, lines — параметры линий, color — цвет, title — название визуализации. Также существуют и другие параметры, которые можно настроить. Прочитать о них можно в официальной документации по timelion. И последняя визуализация, которую рассмотрим — это control или выпадающий список:

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

Теперь давайте попробуем фильтрануть по пользователю, например, за последние 2 дня:

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

Проактивное обнаружение инцидентов

Возникает еще одна задача: а как вообще понять, что сейчас произошел инцидент безопасности. Не 2 часа назад, не 30 минут назад, а в данный момент времени. Можно повесить телевизор в рабочем офисе с данными визуализациями и постоянно наблюдать за их изменением. Это хорошо для выполнения требования международных стандартов в ИБ, но легко можно пропустить инциденты и вовремя не среагировать на них. Поэтому важной частью в системах мониторинга является настройка алертинга. В платной версии настройку алертов можно произвести в кибане. Но так как мы все в основном работаем в бесплатной версии, настраивать алерты будем через ПО Elastalert. Полную настройку данного сервиса рассмотрим в последующих статьях, сейчас составим алерт, если на каком-то ПК возникло 3 ошибки аутентификации за какой-то период, например, за 10 минут.

Сначала настроим тип алерта и частоту срабатывания:

name: Windows Login Failed 3 times
# Alert on x events in y seconds
type: frequency
# Alert when this many documents matching the query occur within a timeframe
num_events: 3
# num_events must occur within this amount of time to trigger an alert
timeframe:
  minutes: 10
buffer_time:
  minutes: 10
run_every:
  minutes: 1
realert: 
  seconds: 0
query_key: 'related.user'
# Index to search, wildcard supported
index: winlogbeat-*
timestamp_field: "@timestamp"

Данный алерт будет срабатывать, если за 10 минут произошло 3 ошибки аутентификации по одному пользователю (query_key: 'related.user'). Запускаем проверку каждую минуту.

Далее настроим фильтр на событие logon-failed:

filter: 
- query:
    query_string:
      query: "event.action:\"logon-failed\""
include:
  - event.action
  - event.code
  - host.name
  - related.user
  - "@timestamp"
  - _index
  - _id

Это значит, что будут срабатывать алерты, только если найдутся события по такому фильтру. В include мы ставим те поля, которые мы хотим собрать из событий, которые сработали по фильтру.

После этого настраиваем текст алерта и куда мы его отправляем:

alert_text: |-
  Action: {}
  Event code: {}
  The host name: {}
  The user name: {}
  Time: {}
alert_text_args:
  - event.action
  - event.code
  - host.name
  - related.user
  - "@timestamp"
# The alert is use when a match is found
alert:
  - telegram
alert_text_type: alert_text_only
telegram_bot_token: ********
telegram_room_id: "*********"

Здесь мы указываем вид текста (alert_text), {} — сюда подставляется переменная, которую мы указываем в alert_text_args в порядке нумерации. Алертим в чат телеграма, в результате получаем сообщение такого вида:

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

Заключение

Можно настроить, чтобы алерт отправлялся не в телеграм, а во внутреннюю тикетовую систему. При настройке достаточного количества алертов, можно построить процесс обработки инцидентов в организации, особенно удобно, если автоматически по алерту будет создаваться тикет, который необходимо взять в работу специалисту. Разумеется, такой подход применим к любым типам логов, начиная от работы и ошибок внутренних сервисов, заканчивая security инцидентам, такими, как сработка IPS или обнаружение вируса на конечной машинке антивирусом.

Автор: Глеб Ряскин, инженер TS Solution