31 января 2022
Elastic stack: анализ security логов
Статья 4: Сбор логов c Active Directory
Содержание статьи
Введение
Добрый день, коллеги! Продолжим цикл статей, посвященный ELK stack. Так как в рамках цикла нас интересуют в большей мере security логи, то в этот раз рассмотрим настройку получения информации с Active Directory серверов. В данной статье мы опишем, как можно собрать логи с AD сервера, каким образом их лучше обработать, а в следующей статье обсудим применение данной информации.
Один из самых частых запросов и потребностей у заказчиков — это просмотр логов с AD. Разумеется, на первое место выступает вопрос безопасности — наблюдение за ошибками аутентификации, созданием и удалением пользователей. Бывают и специфические кейсы — примерный учет времени активности пользователей. Например, если злоумышленник будет пытаться брутфорсить какие-либо пользовательские компьютеры, с помощью логов системы это возможно обнаружить. Также в Elastic Siem существуют правила детектирования нежелательных действий со стороны пользователей, если установить агенты на пользовательские системы.
Рассмотрим, каким способом настраивается сбор с Windows Active Directory.
Один из самых частых запросов и потребностей у заказчиков — это просмотр логов с AD. Разумеется, на первое место выступает вопрос безопасности — наблюдение за ошибками аутентификации, созданием и удалением пользователей. Бывают и специфические кейсы — примерный учет времени активности пользователей. Например, если злоумышленник будет пытаться брутфорсить какие-либо пользовательские компьютеры, с помощью логов системы это возможно обнаружить. Также в Elastic Siem существуют правила детектирования нежелательных действий со стороны пользователей, если установить агенты на пользовательские системы.
Рассмотрим, каким способом настраивается сбор с Windows Active Directory.
Winlogbeat
Для того, чтобы собрать логи с системы AD, необходимо установить дополнительно ПО на AD сервер: winlogbeat — официальное решение от разработчиков стека ELK.
Система контроля доступа должна разрешать или запрещать субъектам выполнять ту или иную операцию по отношению к тому или иному объекту. Например, одному субъекту разрешена операция чтения и выполнения файла test.exe, а операция удаления — запрещена. Другому субъекту разрешены все операции над файлом test.exe, а третьему все операции запрещены.
Для автоматизированного контроля доступа необходимо, чтобы для каждой пары субъект- объект были однозначно определены правила доступа, на основании которых система могла бы принимать решение о разрешении или запрете выполнения каждой из предусмотренных для данного объекта операции. Такой селективный подход призван защитить ресурсы ИС от ошибочного или намеренно неправильного использования. Другими словами, обеспечить безопасность ИС.
Важнейшими понятиями управляемого доступа являются идентификация, аутентификация и авторизация.
Система контроля доступа должна разрешать или запрещать субъектам выполнять ту или иную операцию по отношению к тому или иному объекту. Например, одному субъекту разрешена операция чтения и выполнения файла test.exe, а операция удаления — запрещена. Другому субъекту разрешены все операции над файлом test.exe, а третьему все операции запрещены.
Для автоматизированного контроля доступа необходимо, чтобы для каждой пары субъект- объект были однозначно определены правила доступа, на основании которых система могла бы принимать решение о разрешении или запрете выполнения каждой из предусмотренных для данного объекта операции. Такой селективный подход призван защитить ресурсы ИС от ошибочного или намеренно неправильного использования. Другими словами, обеспечить безопасность ИС.
Важнейшими понятиями управляемого доступа являются идентификация, аутентификация и авторизация.
Winlogbeat отправляет журналы событий Windows в Elasticsearch или Logstash. ПО устанавливается как служба Windows.
Winlogbeat читает из одного или нескольких журналов событий с помощью API-интерфейсов Windows, фильтрует события на основе настроенных пользователем критериев, а затем отправляет данные о событиях в Elasticsearch или Logstash. Winlogbeat просматривает журналы событий, чтобы новые данные о событиях отправлялись своевременно. Позиция чтения для каждого журнала событий сохраняется на диске, чтобы возобновить работу Winlogbeat с правильного места после перезапуска.
Winlogbeat может записывать данные о событиях из любых журналов событий, работающих в вашей системе. Например, вы можете захватывать события, такие как:
Winlogbeat читает из одного или нескольких журналов событий с помощью API-интерфейсов Windows, фильтрует события на основе настроенных пользователем критериев, а затем отправляет данные о событиях в Elasticsearch или Logstash. Winlogbeat просматривает журналы событий, чтобы новые данные о событиях отправлялись своевременно. Позиция чтения для каждого журнала событий сохраняется на диске, чтобы возобновить работу Winlogbeat с правильного места после перезапуска.
Winlogbeat может записывать данные о событиях из любых журналов событий, работающих в вашей системе. Например, вы можете захватывать события, такие как:
- application events;
- hardware events;
- security events;
- system events.
Установка агенты и сбор информации
- Скачиваем актуальную версию winlogbeat: https://www.elastic.co/downloads/beats/winlogbeat
- Разархивируем и складываем в папку на AD server - в 'C:\Program Files\', в результате будет 'C:\Program Files\Winlogbeat'. Заходим в powershell от имени администратора.
- PS C:\Users\Administrator> cd 'C:\Program Files\Winlogbeat'
- PS C:\Program Files\Winlogbeat> .\install-service-winlogbeat.ps1
- Если не хватает прав из за не лицензированного ПО от windows то: PS C:\Winlogbeat> PowerShell.exe -ExecutionPolicy UnRestricted -File .\install-service-winlogbeat.ps1 (такая команда позволит запустить не подписанный скрипт).
После успешной установки службы, настраиваем конфигурационный файл, расположенный в папке со скриптом. Откроем в блокноте файл C:\Winlogbeat\winlogbeat.yml.
Файл поделен на несколько логичных частей. Сначала настраиваем, какие события будем брать из системы:
winlogbeat.event_logs:
- name: Application
- name: Security
- name: System
После этого настраиваем в качестве приемника IP адрес Logstash и порт:
output.logstash:
hosts: ["IP_address:5044"]
В теории возможно отправлять все данные прямиком в базу elasticsearch. Но я считаю, что такой способ не оптимальный. Возможно, что-то потребуется отредактировать по полям в логе, что-то добавить, либо прикрутить сертификаты в будущем. Через logstash это выполнить намного удобнее и большого количества ресурсов не занимает, так как логи приходят уже в распарсенном виде.
Также в конфиге можно установить предустановленные дашборды для Kibana и указать данные для аутентификации:
setup.kibana:
host: "IP_address:443"
protocol: https
username: "****"
password: "*****"
Включаем логирование службы, указываем конечное местоположение для служебных логов, уровень логирования, и паттерн индексов для предустановленных дашбордов.
logging.to_files: true
logging.files:
path: C:\ProgramData\winlogbeat\Logs
logging.level: info
setup.dashboards.index: "winlogbeat-*"
setup.dashboards.enabled: true
Проверяем на правильность конфигурационного файла, запускаем процесс:
PS C:\Program Files\Winlogbeat> .\winlogbeat.exe test config -c .\winlogbeat.yml -e
PS C:\Program Files\Winlogbeat> Start-Service winlogbeat
Смотрим запущенные сервисы:
PS C:\Program Files\Winlogbeat> services.msc
Остановить процесс:
PS C:\Program Files\Winlogbeat> Stop-Service winlogbeat
Загрузить дашборд в кибану:
PS > .\winlogbeat.exe setup --dashboards
Настройка парсера на Logstash
После проделанных действий проверяем в tcpdump, что трафик доходит до сервера, на котором стоит logstash.
После этого настраиваем конфиг логстэша. В первую очередь, настраиваем input, указываем плагин — beats, и порт, на который приходят логи : 5044. Это значит, что логи приходят именно от агента. Таким агентом может быть Filebeat или Winlogbeat. В фильтре изменяем с помощью фильтра ruby числа на конкретные строчные значения, более удобно при чтении в кибане. Также советую изучить фильтр ruby, с помощью него можно выполнить некоторые специфичные задачи или произвести математические операции. Его особенность в том, что можно написать код, который будет применяться к событию. Соответственно, с точки зрения функционала, это самый мощный плагин, но его надо применять осторожно, так как системные ресурсы не бесконечны, и события могут долго обрабатываться. Может, в последующих статьях мы его рассмотрим.
В результате получаем готовый парсер:
В результате получаем готовый парсер:
input {
beats {
port => 5044
tags => ["winlogbeat"]
}
}
filter {
if "winlogbeat" in [tags] {
if [winlog][event_data][LogonType] {
ruby {
code => " dict = { '0'=>'System', '1'=>'Unknown', '2'=>'Interactive', '3'=>'Network', '4'=>'Packet', '5'=>'As service', '6'=>'Proxy', '7'=>'Lock Release (Locally)', '8'=>'Network (plain text)', '9'=>'New account', '10'=>'Interactive (remotely)', '11'=>'Interactive (from cache)', '12'=>'Interactive (remotely, from cache)', '13'=>'Unlock (from cache)' };
key = event.get('[winlog][event_data][LogonType]');
event.set('[winlog][event_data][LogonType]', dict[key]); "
}
}
if [beat][hostname] {
ruby {code => "event['beat']['hostname'] = event['beat']['hostname'].downcase;"}
}
}
}
output {
if "winlogbeat" in [tags] {
elasticsearch {
hosts => ["10.10.1.200:9200"]
index => "winlogbeat-%{+YYYY.MM.dd}"
user => "******"
password => "*******"
}
}
}После этого перезагружаем logstash и проверяем на кибане, что создался индекс winlogbeat, и туда уже поступают события.
Создаем индекс — паттерн winlogbeat, если в конфиге не подключали настройку дашбордов в кибане. После проверяем в discovery, что сохраняются логи.
Создаем индекс — паттерн winlogbeat, если в конфиге не подключали настройку дашбордов в кибане. После проверяем в discovery, что сохраняются логи.
Проверяем, что все дашборды подгрузились на кибану:
Открываем какие-нибудь из них и проверяем, что дашборды визуализируют информацию.
Заключение
В результате информация с доменного сервера в организации сохраняется в базе elasticsearch. Теперь с этой информацией можно работать, строить свои графики, вырабатывать свою аналитическую базу. Самое главное — понимать, зачем собирается та или иная информация, и получать максимум пользы от нее, чтобы логи не просто лежали на сервере, а еще и помогали в бизнес процессах и процессе обеспечения информационной безопасности в организации. О некоторых базовых задачах, и какую пользу можно получить от логов с AD, читайте в следующей статье.
Автор: Глеб Ряскин, инженер TS Solution
Автор: Глеб Ряскин, инженер TS Solution