Настраиваем сбор логов Windows Server в ELK Stack
Продолжаю цикл статей по настройке централизованной системы сбора логов ELK Stack. Сегодня расскажу, как собирать логи с Windows Server различных версий в elasticsearch. Данные предложенным способом можно будет собирать не только с серверных систем, но и со всех остальных, где используется журнал windows.
Введение
В своей статье я буду считать, что вы установили и настроили elk stack по моему материалу. Если это не так, то сами подредактируйте представленные конфиги под свои реалии. По большому счету, все самое основное по сбору логов windows серверов уже дано в указанной статье. Как минимум, там рассказано, как начать собирать логи с помощью winlogbeat. Дальше нам нужно их обработать и нарисовать функциональный дашборд для быстрого анализа поступающей информации.
Для того, чтобы оценить представленные мной графики и дашборды, рекомендую собирать логи сразу с нескольких серверов. Так можно будет оценить представленную информацию на практике. С одним сервером не так наглядно получится.
С визуализацией данных из windows журналов проблем нет никаких. Winlogbeat из коробки умеет парсить логи и добавлять все необходимые метаданные. Со стороны logstash не нужны никакие фильтры. Принимаем все данные как есть с winlogbeat.
Сбор windows логов
Приступим к настройке. Устанавливаем последнюю версию winlogbeat на сервер, с которого мы будем отправлять логи в elk stack. Вот конфиг с тестового сервера, по которому пишу статью:
Теперь настраивает logstash на прием этих логов. Добавляем в конфиг:
Я формирую месячные индексы с логами windows серверов. Если у вас очень много логов или хотите более гибкое управление занимаемым объемом, то делайте индексы дневные, указав winsrv-%<+YYYY.MM.dd>.
Перезапускайте службы на серверах и ждите поступления данных в elasticsearch.
Dashboard в Kibana для Windows Server
После того, как данные из логов windows серверов начали поступать в elk stack, можно приступить к их визуализации. Я предлагаю такую информацию для Dashboard в kibana:
- Количество логов с разбивкой по серверам
- Количество записей в каждом журнале
- Разбивка по уровням критичности (поле level)
- Разбивка по ID событий в логах (поле event_id)
- Список имен компьютеров, фигурирующих в логах (поле event_data.Workstation)
- Список пользователей в логах (поле event_data.TargetUserName)
- Разбивка по IP адресам (поле event_data.IpAddress)
Визуализации создаются достаточно просто, плюс они все похожи друг на друга. Вот пример одной из них — разбивка по рабочим станциям:
А вот какой Dashbord у меня получился в итоге:
В самом низу идет список логов с сырым текстом события. Отдельно представляю дашборд для файлового сервера windows.
Сбор и анализ логов Windows Fileserver
Для файлового сервера настраиваем сбор логов в ELK Stack точно так же, как я показал выше. Для визуализации данных я настроил отдельный дашборд в Kibana со следующей информацией:
- Имена пользователей, которые обращаются к файлам (поле event_data.SubjectUserName)
- Типы запросов, которые выполняются (поле file_action)
- Список доступа к файлам (формируется из сохраненного фильтра поиска)
Возможно, кому-то будет актуально выводить на дашборд еще и информацию об именах файлов, к которым идет доступ. Информация об этом хранится в поле event_data.ObjectName. Лично я не увидел в этом необходимости.
Заключение
Материал написан исключительно на основании своего видения и небольшого опыта использования elk stack. Нигде не видел статей и мыслей на данную тему, так что буду рад предложениям, замечаниям. Ко всему прочему, я практически не администрирую windows сервера. Пишите обо всем в комментариях.
Практика ИБ. Централизованный сбор логов с Windows-устройств
Руслан Рахметов, Security Vision
Коллеги, в предыдущей статье мы обсудили инвентаризацию ИТ-активов и кратко рассмотрели простейшие способы сбора технической информации с устройств. Разумеется, кроме сведений о самих активах, в целях решения задач информационной безопасности следует собирать и журналы аудита с контролируемых устройств. В данной статье мы рассмотрим централизованный сбор логов с Windows-устройств посредством использования штатного функционала Windows Event Forwarding и пересылку собранных событий в SIEM-систему (на примере IBM QRadar). Приступим!
Для начала следует напомнить читателям о том, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Microsoft предлагает использовать также бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Можно также пользоваться и веб-версией рекомендаций по настройке аудита.
Разумеется, рекомендуемые в «лучших практиках» настройки аудита следует привести в соответствие конкретной инфраструктуре: например, будет нецелесообразно включать аудит платформы фильтрации (т.е. встроенного брандмауэра Windows) в случае, если в компании применяется другое наложенное хостовое СЗИ с функционалом межсетевого экранирования. Не стоит забывать и о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).
Итак, настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и централизованного их хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull / Collector initiated), так и отправлены самим источником (режим Push / Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push на коллекторе служба WinRM слушает входящие соединения, а на клиентах-источниках WinRM не находится в режиме прослушивания и только периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальных атак на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.
Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.
Для включения сервиса сбора логов следует выполнить нижеописанные шаги:
1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» («Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled»), либо командой winrm set winrm/config/winrs @
2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы сборщика событий Windows. При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.
3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» («Windows Remote Management (WS-Management)»), при этом TCP:5985 не начинает слушаться.
4. Проверить состояние службы WinRM можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» («Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management»).
5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers ( «Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).
6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера. » («Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address. «) и указать адрес сервера-коллектора в следующем формате:
где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.
7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» («Subscriptions»). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Source Computer Initiated» (это означает предпочтительный режим Push). Нажимаем на кнопку «Select Computer Groups», выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Select Events» и вводим XPath-запрос (пример для сбора журналов Security):
8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На коллекторе в eventvwr.msc в разделе «Подписки» можно будет увидеть приходящие события с источников и список самих источников.
9. Далее, решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему (возьмем для примера SIEM security систему IBM QRadar (Курадар)). Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.
Рекомендуем использовать управляемый («Managed») режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en—US (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM Q Radar по TCP:8413 и TCP/UDP:514.
10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника «Microsoft Security Event Log», в поле «Target Destination» в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box «Forwarded Events»).
После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.
Централизованный сбор логов в Windows с разных компьютеров штатными средствами
А вы в курсе, что в винде, начиная с 2008R2 есть замечательная возможность – собирать логи с разных компьютеров в сети, в одном месте? Эта функция называется Windows Event Forwarding. Сегодня покажу как её настроить.
Настраивать функцию можно двумя способами.
Collector Initiated – это когда сервер, на который должны поступать все записи о событиях сам шлет запросы на машины в сети, и получает с них логи.
Source initiated – когда, компьютеры сами стучаться на сборщик и отправляют ему информацию. Настройка тут производится посредством GPO, где указывается адрес сборщика событий.
Я покажу как собирать логи на примере Collector Initiated.
Первым делом, необходимо настроить машины, с которых нужно собирать логи.
Для этого на них должно быть включено удаленное управление, или другими словами – должен быть настроен winrm. Чтобы его настроить необходимо выполнить команду от имени администратора:
Либо можно воспользоваться powershell
Дальше необходимо добавить учетную запись пользователя, или компьютера, на который будут отправляться логи (если вы по какой-то причине не захотите указывать при настройке учетную запись пользователя) в группу Event Log Readers. Но, в некоторых случаях членства в данной группе может быть недостаточно, тогда придется добавлять учетки в группу администратора.
Также если вы хотите собирать журналы безопасности, тогда придется учетной записи Network Service дать право на их чтение. Сделать это можно командой:
Тут все указанные SIDы – стандартные, мы добавляем запись (A;;0x1;;;S-1-5-20).
Для верности, вы можете посмотреть, что у вас указано командой
Если у вас много компьютеров, тогда процесс выдачи прав можно сильно упростить выполнив команду в PowerShell:
Как вы поняли, в папке, откуда вы выполните эту команду должно быть 2 файла:
Computers.txt – список компьютеров, на которых нужно выполнить команду. Каждый – с новой строки.
Security.ps1 – тут только наша команда — wevtutil set-log security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)
На этом настройка отдающих – завершена. Переходим к настройке сервера, где всё будет храниться.
Первым делом включим службу Windows Event Collector, для этого, от имени администратора выполним:
В оснастке службы должна будет появиться данная служба, с типом запуска Delayed Start.
Следующим шагом укажем физическое расположение файла журнала, т.к. если вы задумались о централизованном сборе логов, то их наверняка у вас будет не мало. По этому, лучше под это мероприятие выделить отдельный диск, на который и будут писаться события. Также лучше бы его ограничить по размеру, к примеру 2ГБ, что бы логами можно было относительно комфортно пользоваться.
Запускаем оснастку просмотр событий – eventvwr.msc, windows logs, правой кнопкой по Forwarded Events. И ограничиваем размер, чтобы логи не терялись – лучше выбрать Archieve the log when full, do not owerride events. И конечно указываем путь, где файл должен лежать.
Дальше, создадим подписку – правой кнопкой по Subscriptions – Create Subscription
Тут нужно ввести имя, выбрать лог, куда должны складываться события (по умолчанию – Forwarded Events, по этом ему мы и меняли расположение и размер).
Сразу идем в Advanced Settings и указываем пользователя, от имени которого будет действовать сборщик (если вы указывали имя компьютера ранее на клиентах, тогда этот шаг пропускаем).
Выбираем события, которые должны собираться – select events. Тут можете настроить под себя, как вам угодно. Но не стоит выбирать абсолютно всё, то есть и стандартные логи, и логи приложений, иначе практически наверняка у вас выскочит ошибка, во время сбора логов, о слишком большом запросе.
Осталось только добавить компьютеры, с которых хотим собирать информацию – select computers. После добавления каждого из компьютеров лучше сразу жать test, чтобы удостовериться, что всё будет работать как надо.
Выжидаем некоторое время, и смотрим на статус созданного коллектора. Если он активный, значит в скором времени в forwarded events начнут появляться записи.
Но на этом еще не всё. Когда к вам начнут прилетать записи, вы скорее всего увидите, что для записи отсутствуют описания. Что-то вроде:
The description for Event ID X from source A cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
Частично данную незадачу можно решить, выполнив команду:
И перезапустив службу Windows Event Collector. По умолчанию, за место events установлен RenderedText. И по умолчанию события пререндерятся на удаленных компьютерах и отправляются с локализованными строками, из-за чего есть вероятность, что события не будут распознаны. Кроме того, изменение на Events немного снизит нагрузку на сеть и компьютеры – источники.
Но и после изменения параметра /cf проблема может уйти только частично. Как правило, указанные выше записи будут появляться для каких-то костюмных служб, которых нет на сборщике, например Exchange или SharePoint или еще что-то.
В событии внизу будет указано, кто является источником сообщения, из чего можно сделать вывод – чего не хватает.
Все источники и то, на какие DLL они завязаны можно посмотреть в реестре – HKLM\SYSTEM\CurrentControlSet\services\eventlog. Тут всё разбито по логам, типа Application, System и т.п. Соответственно если нужного источника тут нет, то его необходимо экспортировать с компьютера, где он есть. Соответственно и нужные, как правило, DLLки, со словарями можно посмотреть в этих ветках реестра – это параметры, где есть file в названии. Пути до файлов, для удобства, после импорта можно менять.
Если события пишет небольшое приложение, то источников для него, скорее всего будет 1-2, и их можно спокойно перенести руками, но вот если это что крупное, например exchange, то источников там уже 147. Согласитесь, такое количество руками переносить – мазохизм. Поэтому был написан скрипт, который всё сделает за нас.
Что нужно делать:
Копируем скрипт export-log на сервер, где нужная служба есть, переходим в папку со скриптом и запускаем его от имени администратора с ключом, которым является часть имени источника событий. Например, если мы увидели в просмотре событий, что нет описаний для MSExchange Certificate, то скрипт можно запустить так:
Если источником событий является Microsoft-Sharepoint Foundation, то запустить можно с ключом sharepoint.
Скрипт создаст папку, пройдется по всем разделам eventlog, сделает дамп всех разделов, где в имени присутствует ключ, исходя из путей в параметрах скопирует в папку нужные файлы, а также создаст текстовый файл со списком сдампленных разделов.
Далее нужно скопировать созданную папку на сервер сборщик логов, в папку со скриптом import-log, перейти в powershell запущенном от имени администратора в папку со скриптом, и запустить его с тем же самым ключом.
Скрипт скопирует нужные файлы, импортирует записи в реестр, и изменит пути до файлов в параметрах. Я сделал, чтобы файлы копировались в папку C:\CustomEvents\[ключ], соответственно папка C:\CustomEvents\ должна существовать.
Возможно, чтобы до оснастки просмотр событий дошли изменения, её нужно будет перезапустить. Всё, теперь вы сможете читать логи на компьютере, где нет служб, которые эти логи сгенерировали.
Во время настройки этого хозяйства я столкнулся с некоторыми неприятными моментами, оставлю описание этих моментов тут.
- На парочке серверов были непонятки с WinRM. В диспетчере серверов статус удаленного управления был обозначен как неизвестный. При попытке выполнить winrm qc выскакивало сообщение
WinRM service is already running on this machine.
WSManFault
Message
ProviderFault
WSManFault
Message = Unable to check the status of the firewall.
Error number: -2147024894 0x80070002
The system cannot find the file specified.
Подключения к серверу не осуществлялось. -, с удаленной машины, упорно говорил, что служба не запущена.
Google настойчиво предлагал добавить правила в firewall:
Но для меня это результата не дало, равно как и его включение, отключение и изменение его конфигурации.
Как выяснилось, именно данная ошибка была связана с локализацией системы, на нее был установлен языковой пакет. После изменения языка системы – ошибка ушла, и команда отработала штатно, но доступа – не появилось.
Посмотрел на прослушиваемые порты командой netstat -ant — обнаружил, что порт winrm ( 5985) слушается только на адресе 127.0.0.1
показало, что iis слушает только на адресе 127.0.0.1
Помогло выполнение команд:
Вторая команда – необязательно, т.к. если в списке прослушиваемых адресов нет адресов, то прослушиваются все адреса системы.
2. Мы подцепили лог на диск iSCSI и после перезагрузки системы, данный лог стабильно отваливается. Связано это, скорее всего с тем, что после перезагрузки – iSCSI диски, либо переподключаются, либо изначально долго подключаются, и всё это происходит уже после запуска службы event log. Тут помогло указание в свойствах неправильного пути до лога, и когда система ругнется, что путь не верен – нужно указать верный путь, тогда файл подцепится.
Я добавил в планировщик заданий, на событие start up — простенький файл содержащий следующие строчки:
