Windows event logging server

В предыдущей статье мы рассмотрели, как развернуть собственный централизованный сервер сбора лога с различных типов сетевых устройства на базе стека Graylog (
Graylog
+
OpenSearch
+
MongoDB
). В этой статье мы покажем, как настроить отправку журналов событий с серверов Windows (включая события Active Directory) в Graylog.

Настройка сборщика данных и индексов Graylog для устройств Windows

Сначала нужно настроить в Graylog отдельные сборщики данных и потоки для логов, которые будут отправлять хосты Windows Server (чтобы не смешивались события от разных классов устройств). Перейдите в раздел System -> Inputs и добавьте новый сборщик Windows Server Devices типа Beats, который слушает на порту
TCP:5044
.

Картинка с сайта: winitpro.ru

Затем создайте отдельный индекс для логов журналов событий Windows. На базе нового Input и индекса создайте новый поток для Windows в разделе Streams и запустите его.

Картинка с сайта: winitpro.ru

Отправка событий Windows в Graylog с помощью Winlogbeat

Для отправки логов из журналов событий EventViewer с хостов Windows на сервер Graylog можно воспользоваться службой сборщика логов Winlogbeat. Winlogbeat это один из свободно распространяемых компонентов стека ELK. Службу Winlogbeat нужно установить на каждом хосте Windows, события с которого вы хотите видеть на сервере Graylog.

1. Скачайте архив Winlogbeat со страницы загрузки (https://www.elastic.co/downloads/beats/winlogbeat)
2. Распакуйте архив в папку
   C:\Program Files\winlogbeat
3. Отредактируйте конфигурационный файл winlogbeat.yml

В самом простом случае можно использовать следующую конфигурацию, когда все события из журналов Application, Security и System будут отправлены на указанный сервер Graylog.

winlogbeat.event_logs:
  - name: Application
    ignore_older: 72h
  - name: Security
  - name: System
output.logstash:
  hosts: ["192.168.14.146:5044"]

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

winlogbeat.event_logs:
  - name: Security
    event_id: 4627, 4703, 4780-4782
    ignore_older: 24h
    level: critical, error
  - name: Microsoft-Windows-TerminalServicesRDPClient/Operational
    event_id: 1102

Примеры типовой универсальной конфигурации winlogbeat.yml для Windows Server можно посмотреть тут.

Сохраните файл winlogbeat.yml и проверьте корректность конфигурации Winlogbeat и доступность сервера сбора логов:

cd "C:\Program Files\winlogbeat"
./winlogbeat test config
./winlogbeat test output

Если все ОК, установите и запустите службу winlogbeat:

.\install-service-winlogbeat.ps1
Start-Service winlogbeat

Картинка с сайта: winitpro.ru

Перейдите в веб-интерфейсе GrayLog сервера и проверьте, что в соответствующем потоке стали появляться события с ваших серверов Windows.

Картинка с сайта: winitpro.ru

Сбор и анализ событий с контроллеров домена Active Directory с помощью Graylog

Рассмотрим, как использовать сервер Graylog для поиска и анализа событий Windows на примере контроллеров домена Active Directory.

При наличии множества контроллеров Active Directory администратору бывает сложно найти определенное событие, так как приходится просматривать журналы на каждом DC. Благодаря централизованному серверу Graylog, который хранит события со всех контроллеров домена, нужно событие нужно найти за секунды.

Например, вам нужно найти компьютер, с которого была заблокирована учетная запись пользователя из-за неверного ввода пароля. Для этого откройте строку фильтра Graylog, выберите нужный Stream, или укажите его в запросе (
streams:xxxxxxxxxxxxx
) и выполните следующий запрос:

winlogbeat_event_code:(4740 OR 4625) AND winlogbeat_event_provider:Microsoft\-Windows\-Security\-Auditing

Картинка с сайта: winitpro.ru

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

Еще несколько примеров поиска различных событий в Active Directory:

• Event ID 4767 – позволяет определить кто разблокировал пользователя AD
• Event ID 4724 – кто и когда сбросил пароль пользователю домена
• Event ID 4720 – позволяет узнать, кто и когда создал нового пользователя в AD, 4722 – событие включения учетной записи, 4725 – отключение, 4726 – удаление.
• Отслеживание изменения в группах безопасности AD: 4727 (создана новая группа), 4728 (новый пользователь добавлен в группу), 4729 (пользователь удален из группы), 4730 (группа безопасности удалена)
• Event ID 5137 (создана новая групповая политика домена), 5136 (изменена GPO), 5141 (удалена GPO)
• Event ID 4624 — событие успешного входа пользователя в домен (позволяет быстро получить историю входа пользователя в AD)

Важно настроить отправку логов через Winlogbeat со всех контроллеров домена (список активных DC можно получить с помощью команды Get-ADDomainController. Сбор некоторых событий безопасности Active Directory нужно отдельно включить в настройках политик аудита в Default Domain Controller Policy.

Вы можете создать в Graylog сохранённые запросы и dashboardы для быстрого поиска интересующих вас событий. С помощью оповещений можно настроить рассылку алертов о критических событиях в AD.

Централизованное хранилище логов для хостов Windows

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

• Аудит доступа к файлам и папкам на файловом сервере
• Аудит удаления файлов в сетевой папке
• Аудит изменений NTFS разрешений объектов
• Анализ логов RDP подключений
• Обнаружение перебора паролей к RDP серверу
• Определить кто и когда перезагрузил или выключил сервер Windows:
  winlogbeat_event_code:1074
• Реагирование на очистку журналов событий Windows (возможная компрометация сервера)
• Оповещение об обнаружении вируса на одном из серверов Windows встроенным антивирусом Windows Defender (Event ID 1006, 1116)

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

Картинка с сайта: winitpro.ru

Централизованное хранилище логов Windows и Active Directory удобно использовать для быстрого расследования и реагирования на инциденты информационной безопасности, анализа работы компонентов, выявления сбоев.

Время на прочтение17 мин

Количество просмотров100K

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!

Картинка с сайта: habr.com

Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.

Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Политики аудита Windows

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

Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.

Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра — следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.

Настройка Windows Event Forwarding, интеграция с IBM QRadar

Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм 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 @{AllowRemoteShellAccess=»false»}

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).

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…) и указать адрес сервера-коллектора в следующем формате:

Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*</Select>
  </Query>
</QueryList>

Картинка с сайта: habr.com

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.

9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему 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 QRadar по 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, собранными описанным способом с различных устройств в инфраструктуре компании.

Утилита Sysmon

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги  https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:\folder\sysmon64.exe -accepteula -i C:\folder\sysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe  –  файл-установщик.

Поддерживается запуск установки из сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:\Windows\sysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

XPath-запросы

Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box  «Отобразить аналитический и отладочный журналы».

Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.

Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку  «Подробности», а там выбрать radio-button  «Режим XML», в котором в формате  «ключ-значение» будут представлены данные события безопасности.

Приведем несколько полезных XPath запросов с комментариями.

1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:

<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>

 2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">*[EventData[Data[@Name='DestinationPort'] = '443']]</Select>
  </Query>
</QueryList>

3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
  </Query>
</QueryList>

4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором  «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4624)]]</Select>
<Suppress Path="Security">*[EventData[(Data[@Name='TargetUserSid'] and (Data='S-1-5-18' or Data='S-1-5-19' or Data='S-1-5-20') and Data[@Name='LogonType'] and (Data='4' or Data='5'))]]
or
*[EventData[(Data[@Name='LogonProcessName'] and (Data='Advapi') and Data[@Name='AuthenticationPackageName'] and (Data='Negotiate' or Data='NTLM'))]]
</Suppress>
  </Query>
</QueryList>

IRP-система штатными средствами Windows

Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.

Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв  «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке  «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку  «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант  «При событии», а в открывшейся форме отображения установить radio-button  «Настраиваемое». После этих действий появится кнопка  «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.

Картинка с сайта: habr.com

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

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and 
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

 Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
*[System[(EventID=10)]] 
and 
*[EventData[Data[@Name='TargetImage']='C:\Windows\System32\lsass.exe']] 
and 
*[EventData[(Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038'))]]
</Select>
  </Query>
</QueryList>

 Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически  бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.

Event log management is a crucial skill to acquire in all Windows systems. Every second, activity is recorded to Windows event logs, which serve as a security tool and a critical troubleshooting tool.

However, managing separate server event logs becomes unmanageable once a server setup develops past a few servers. Luckily, you have a tool called Windows Event Forwarding (WEF) to make things easier.

The event log forwarding in Windows Server allows system administrators to centralize client and server event logs, making it easier to monitor events without connecting to each server individually. The DMTF WS-Eventing standard is used for forwarding, part of the open Web Services-Management (WS-Man) protocol built into Windows Server as part of the framework. 

Standards of Event Log messages

There are two major standards for log messages in use: Windows Events and Syslog. Syslog is a widely-used open standard on Linux systems. Windows Events adhere to a proprietary standard developed by Microsoft for its products. Third-party products, however, use the Windows Event log format when running on Windows. Similarly, some software developers choose to adhere to the Syslog messaging standard.

Framework for Windows Management (WMF)

In this article, we’ll walk you through configuring Event Log forwarding in Windows Server 2012 R2, including configuring a source server and a collector server. Windows Server 2008 and Vista or later are supported as event collectors.

Because Event Log forwarding uses technologies built into Windows Server, there is no need to install a collection agent. Forwarding is very scalable because one collector can forward to another and process many events per second. For secure messaging, HTTPS is also supported.

Log messages have recently grown in importance. Although every application and the operating system generates system status messages, system administrators have ignored them for decades. Everyone is now eager to collect and save every log message that every system emits.

• Collectors and receivers of logs The requirement to collect all log messages in one location necessitate the creation of a bridge between the two log messaging tribes: Windows Events and Syslog. A log message manager will collect and file all Windows Events log messages in a Windows system but ignore Syslog messages generated on other network parts. Similarly, a Linux log file manager would manage and store Syslog messages but not handle them.
• Messages from the Windows Event Log As a result, a systems administrator who manages both Windows and Linux systems must maintain at least two different log message stores – one for Windows Events and one for Syslog messages. This is an unfavorable scenario for intrusion detection. The solution to this problem requires either the conversion of Windows Event messages into Syslog format or converting Syslog messages into Windows Event message format. Either strategy would allow all system messages to be stored in standard files and searched using a single analytical tool. Converting Windows Events and Syslog messages into a neutral format is a third option for consolidating them. Event log forwarding refers to sending messages from Windows to a Syslog server or a third-party consolidating tool.
• Log servers and event log forwarders The Event log forwarder will only work on your system. The log server and consolidator are not required to be on your premises. There are log servers that can be installed on-site and others that are hosted.
• The Software as a Service (SaaS) model As part of the package, many hosted systems includes the log collector, also known as the Event log forwarder. In these cases, the log collector must still be installed on a Windows host on your site. This is commonly referred to as an “agent”. You will also need to install a Syslog forwarder on one of your Linux machines to combine files from Windows and Linux. A Linux-based agent is also available with SaaS log file management systems. If you host your log file server on your server, the log collector/forwarder and log server will remain separate packages. The server is designed to manage all log messages, whether Windows Events or Syslog.

What Is the Process of Event Log Forwarding?

As Event Log collectors, one or more devices can be configured. Subscriptions on these devices are configured to pull the desired logs from any source computer. There is no unique configuration required on the source computers, except that Windows Remote Management (WinRM) should be enabled, the WinRM Windows Firewall exceptions should be allowed, and the collector’s computer account must have read permission logs you want to subscribe.

This article does not cover variations on this standard configuration, such as configuring push notifications and configuring a user account to authenticate on the source computers. Additional configuration may be required if you work with computers in a workgroup rather than a domain.

What are the limitations of the WEC server?

Three factors limit WEC servers’ scalability. On commodity hardware, a stable WEC server should be able to handle an average of 3,000 events per second for all configured subscriptions.

• Disk I/O In WEC, the received event is not processed or validated. It is buffered and logged to the local event log file (EVTX). EVTX files can only be written at a limited speed due to disc write speed. WEC servers can receive more events per second if they isolate the EVTX files to their arrays or use high-speed discs.
• Network Connections While WEF sources do not maintain a permanent, persistent connection to the WEC server, they do not immediately disconnect after sending events. Therefore, the number of WEF sources connected to the WEC server simultaneously is limited by the number of TCP ports on the WEC server.
• Registry Size To store bookmark and source heartbeat information, a registry key (corresponding to the FQDN of the WEF Client) is created for each unique device that connects to a WEF subscription. If this isn’t pruned to remove inactive clients, this set of registry keys can quickly become unmanageable.

Monitoring event logs allow you to understand system metrics better, identify process bottlenecks, and detect security vulnerabilities. If you keep log data regularly, you most likely have a method for observing event logs in real-time, or you use batch processing. You can monitor event logs in two ways: manually and automatically. What are some of the other benefits of event log monitoring, and how can you make the most of it? 

The Benefits of Event Log Management 

All events can be in one place

While manual log monitoring can work well in a small environment, having an extensive network and system makes manually monitoring event logs exponentially more difficult. Log monitoring software allows you to keep track of local events and remote events in other parts of the network. 

You can centralize event monitoring and control all logs in one place this way. You can customize how event logs are processed and parsed and which events trigger a response by creating a custom set of rules. One of the many benefits of centralized event log monitoring is increased security. In the event of a security breach on one machine, the intruder will be unable to access and compromise its event logs. They will have difficulty concealing their activities.

Improving performance system

Monitoring event log software archives all previous logs, providing an excellent data source for analyzing system behavior by storing all previous event logs in one location. For example, archived event logs can help you identify which processes waste resources or cause bottlenecks, improving resource management and performance. 

You can detect minor problems by monitoring event logs in real-time, and you can prevent further problems before they cause further problems that could cause more severe problems. Because you can customize how you perform event log monitoring, you can develop a method that works for your infrastructure and filters out less significant events to focus on the important ones.

Time-saving

Monitoring event logs typically involves manual monitoring and acting when an issue is detected. The disadvantage of this approach is that someone must constantly monitor event logs, which necessitates more people working in shifts or forces you only partially to monitor the system during specific working hours. Suppose a critical issue arises outside of working hours and you do not have a dedicated person to handle emergencies. In that case, this can result in hours of downtime before someone is available to address the issue. Such events may result in an increase in customer churn, which you should avoid at all costs.

Using Software to monitor log events can avoid this problem and reduce the time required to detect and resolve an issue. Event logs can become large and difficult to navigate manually, which is another reason to automate and speed up the process. Suppose you believe that time is of the essence when a security breach occurs. In that case, automated monitoring can assist you in reacting in real-time by sending real-time alerts as soon as a security issue arises.

One of the most valuable features of automated event log monitoring is configuring the monitoring software to act automatically whenever a specific type of warning is detected.

Automatically fix issues

Another significant advantage of using automated log monitoring is configuring the monitoring software to take action when a specific event occurs. There is a universal and straightforward solution for some events every time the event occurs. This reduces the time required to detect the event and decide on the best course of action and ensures system uptime without human involvement. Some events, for example, generate a low memory warning, which can be resolved by restarting the complex process or the entire system. Configuring an automatic action, such as resuming a function every time it triggers a low memory warning, can save a significant amount of time between detecting a sign in the event log and resolving the issue.

Commercial Event Log Forwarding Software

The Event Log forwarding function is built into many log management packages. One example is ManageEngine EventLog Analyzer. This package acts as a log server, receiving logs from multiple sources and in different formats. It is able to collect Windows Events and Syslog as well as many application-specific log formats. The service will convert all of the logs it receives into its own standard format. This enables it to forward logs from different sources to different destinations. 

Картинка с сайта: www.netadmintools.com

The package allows administrators to set up a custom format for each log before sending it on. All log messages can be displayed together in one stream, which enables log correlation and security or performance scanning. Users can set up their own queries to run continuously. This creates a customized performance monitor or security scanner. 

The EventLog Analyzer system is an on-premises package and it will run on Windows Server or Linux. You can examine the system and try out setting up your own parsing or format conversion routines by accessing a 30-day free trial.

ManageEngine EventLog Analyzer
Access a 30-day FREE Trial

Inside the Perimeter Security

Security is always at the forefront of any organization’s IT strategy, regardless of size. Typically, this strategy focuses on the network’s perimeter to prevent unauthorized access or attacks from malicious parties unaffiliated with the organization.

As discussed in the Executive Summary, the potential for liability is significant when an unauthorized individual gains access to data protected by legislation. A security breach is just as likely to occur from within the organization as it is from without. It could be even higher.

You can locate and prevent small events before they turn into significant disasters by establishing a comprehensive ELM strategy for security monitoring of Windows event logs for internal activities and changes outside the scope of normal business activities.

Prepare for the Worst in Compliance Initiatives

Regulatory compliance may or may not apply to your organization. Most likely, if you are a private entity, you do not. However, this should not prevent you from comprehending the requirements of the regulatory standards. Using these standards as a guideline can provide you with a framework for your internal security plans and log management strategy.

Many of the requirements for log management in other legislative or industry-specific initiatives for security and compliance overlap with those of Sarbanes-Oxley. Non-compliance with Sarbanes-Oxley, for example, can result in heavy fines and legal liability for the officers if your organization is public. As a result, every public company and many private companies look to that standard for guidance when developing a log management strategy.

A high-level overview of each of the standards listed below will provide you with a comprehensive understanding of how they can affect your log management strategy.

The decision to implement event log monitoring is entirely up to you. Still, the benefits far outweigh the costs of time and human resources (if manual monitoring is chosen) or money (if you choose paid event log monitoring software). If you decide to use event log monitoring software, compare different products and features before making a final decision.