Как подобрать решение, которое обеспечит стабильную конфигурацию файлов на серверах и стабильный аллертинг в случае изменения этих файлов.
В этом году компании Hostkey понадобилось обеспечить мониторинг ключевых файлов и истории их изменения на серверах. Мы стремились подобрать решение, позволяющее обеспечить стабильную конфигурацию файлов на серверах и стабильный аллертинг в случае изменения этих файлов.
Мы рассматривали несколько сервисов, обеспечивающих мониторинг файлов и в итоге остановились на Wazuh. На то есть несколько причин:
1. Высокое качество клиента. Клиентская часть Wazuh оказалась наименее ресурсозатратной, но при этом стабильной и надежной. Механизм обнаружения, просмотра и сравнения соответствия безопасности с открытым исходным кодом важен, но вторичным ПО. Соответственно, он не должен нагружать сервер. Если 50% ресурса сервера идет на мониторинг, значит, что-то работает не так.
2. Развитость и поддержка клиента. Он работает на нескольких платформах, в том числе на Windows и Linux.
3. Итоговый интерфейс построен на Open Distro. У нас в инфраструктуре уже использовался логгер на Open Distro (со временем мы перешли на OpenSearch). Это решение показалось нам интересным и комфортным с точки зрения минимизации средств поддержки, поскольку используется платформа, с которой мы хорошо знакомы.
Изначально мы искали решение для ОС семейства Linux, но Wazuh оказался универсальным решением. Ниже будет описан опыт администратора Windows. О специфике использования Wazuh на ОС семейства Linux мы расскажем в отдельной статье.
Wazuh — это полноценная SIEM-система (менеджмент информации и событий безопасности), которая хорошо работает с платформами. Wazuh позволяет выполнять сканирование запущенных процессов, проверку уязвимостей CVE, получать отчеты об инцидентах и т. д. В этой статье мы поговорим о сервисе Windows-администраторов, в том числе об опыте подключения к мониторингу Windows-хостов.
Wazuh позволяет осуществить гибкое управление политиками для групп. На хостах выполняется скрипт следующего содержания:
if (!(Get-Service "WazuhSvc" —ErrorAction SilentlyContinue))
{
\\example.ru\SYSVOL\example.ru\scripts\wazuh-agent-4.2.6.msi /q WAZUH_MANAGER='wazuh.example.ru' WAZUH_REGISTRATION_SERVER='wazuh.example.ru' WAZUH_AGENT_GROUP='Windows_Workstations'
}Избежать постоянного скачивания Wazuh-агента из интернета достаточно просто — необходимо разметить его на контроллере домена. В дальнейшем все хосты будут получать скрипт автоматически. Скачать скрипт можно здесь.
Для Wazuh существуют наборы политик. Набор правил Wazuh используется для обнаружения атак, вторжений, неправильного использования программного обеспечения, проблем с конфигурацией, ошибок приложений, вредоносных программ, руткитов, системных аномалий или нарушений политики безопасности.
Набор правил включает сопоставление соответствия с PCI DSS v3.1 и CIS.
Механизм работы мониторинга прост. В var/ossec/etc/shared создаются папки, которые в дальнейшем распространяются по хостам.
При необходимости работать с Workstation используется windows.workstation.yml.
В каждом файле содержатся настройки проверок операционных систем, для каждой ОС есть конкретизированные наборы правил. На каждый хост отправляются три файла:
windows.workstation.yml;
agent.conf;
merged.mg.
Агент выполняет проверку файла windows.workstation.yml, в котором содержится подробный перечень проверок и аннотаций к ним. В том числе есть рекомендации по настройке групповых политик.
Агенты позволяют просматривать подробную статистику проверок. Данные о проверках распределяются по трем категориям:
pass — проверка прошла успешно;
fail — ошибка проверки;
not applicable — не применимо.
Одной из сложностей при работе с Wazuh стало отсутствие возможности осуществить проверку ОС Windows Server 2022. Нам удалось решить эту проблему, отредактировав файл sca_win_audit.yml, предназначенный для проверки всех операционных систем Windows. Мы заменили часть содержимого файла на все проверки для ОС Windows Server 2019. При первом запуске проверки, организованной подобным образом, мы получили примерно следующее распределение по категориям:
pass — 60;
fail — 30;
not applicable — 161.
Далее нам пришлось вручную настраивать политику для группы машин с ОС Windows Server 2022. В дальнейшей настройке нам помог Wazuh, поскольку для каждой проваленной или не состоявшейся проверки выводится удобное графическое описание, где среди прочего представлены варианты решения проблемы и рекомендации по корректной работе конкретной политики. Централизованное управление настройками политик для конечных хостов является весьма удобным инструментом для администрирования большого парка машин.
Вторая сложность — точнее, неудобство — это добавление новой точки наблюдения в инфраструктуре. Ключевым средством мониторинга в нашей компании является Grafana, Естественно, мы хотим осуществлять мониторинг из одной точки, а не перемещаться между разными сервисами. Для решения этой проблемы мы использовали API Wazuh и разделение сообщений по уровням.
Далеко не все сообщения логгера заслуживают внимания инженеров, поэтому мы выбрали для отслеживания только сообщения об ошибках пятого уровня и выше.
Пример запроса для получения информации о событиях за последние 5 минут:
GET /wazuh-alert-4.x-2022.03.15/_search&scroll-10
{
"query": {
"bool": {
"must": {{
"term":
"rule.level": 5
}
}
{
"range": {
"timestamp": {
"gte": "now=5m"
}
}
}
}
}
}Пример ответа:
{
"_index": "wazuh-alerts-4.x-2022.08.24",
….
"message": "\"An account was successfully logged on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-0-0\r\n\tAccount Name:\t\t-\r\n\tAccount Domain:\t\t-\r\n\tLogon ID:\t\t0x0\r\n\r\nLogon Information:\r\n\tLogon Type:\t\t3\r\n\tRestricted Admin Mode:\t-\r\n\tVirtual Account:\t\tNo\r\n\tElevated Token:\t\tYes\r\n\r\nImpersonation Level:\t\tImpersonation\r\n\r\nNew Logon:\r\n\tSecurity ID:\t\tS-1-5-21-2526477096-3969226448-3483117384-1204\r\n\tAccount Name:\t\tDCRU02$\r\n\tAccount Domain:\t\tWIN.HOSTKEY.RU\r\n\tLogon ID:\t\t0x1E2DF59\r\n\tLinked Logon ID:\t\t0x0\r\n\tNetwork Account Name:\t-\r\n\tNetwork Account Domain:\t-\r\n\tLogon GUID:\t\t{2cc363a6-1878-3de5-5960-b16d1cf42fb6}\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x0\r\n\tProcess Name:\t\t-\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\t-\r\n\tSource Network Address:\t172.17.0.12\r\n\tSource Port:\t\t53356\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tKerberos\r\n\tAuthentication Package:\tKerberos\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\t-\r\n\tKey Length:\t\t0\r\n\r\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\r\n\r\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\r\n\r\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.\"",
"version": "2",
…
}
Ответ подробен и информативен, но все же неудобен для просмотра. Информация из него должна быть представлена в более сжатом виде и в удобном для прочтения формате. Для этого разработчики Wazuh предусмотрели механизм интеграции с другими продуктами. В нашем случае — мессенджер Rocket. Chat:
Сообщение об ошибке пятого уровня также отправляется в экспортер, из которого эту метрику забирает Prometheus:
Затем сообщение об ошибке конвертируется для сервиса Grafana, который мы используем как основное средство мониторинга:
Нам удалось построить удобную систему мониторинга ключевых файлов и истории их изменения на серверах. Полная настройка мониторинга с помощью Wazuh заняла около десяти рабочих дней и осуществлялась одним инженером. В итоге автоматизированная оценка конфигурации безопасности Wazuh ищет неправильные конфигурации и помогает поддерживать стандартную конфигурацию на всех управляемых хостах.