Централизация логов на Windows VPS: WEF/WEC, Sysmon и понятные алерты без SIEM

Почему «централизация логов» обычно умирает на второй неделе

У большинства админов история одинаковая: сначала логи смотрят «по месту» – на каждом сервере. Потом случается инцидент (или просто странность), и выясняется, что на одном хосте журнал переполнен, на другом время уехало, на третьем важные события не включены, а на четвёртом логи уже «съел» ротационный скрипт. Следующий шаг – «нужна SIEM», но SIEM требует бюджета, людей и дисциплины. И на этом тема замораживается.

На практике есть рабочий компромисс: собрать базовую телеметрию и Security-события в одно место штатными средствами Windows (WEF/WEC), добавить Sysmon как источник более качественных событий, а алерты сделать простыми и понятными – без SIEM, но с головой.

Удобнее всего разворачивать такой узел на отдельной Windows VPS: изолированный сервер под сбор, хранение и первичный анализ логов. Поднять Windows VPS можно у разных провайдеров; как пример площадки, где виртуальный сервер разворачивается быстро и со статическим IPv4, можно использовать VPS.house (у них сервера в Москве, что иногда важно по задержкам и требованиям к размещению). Дальше всё зависит не от бренда, а от архитектуры и аккуратной настройки.

WEF/WEC за 5 минут: что это и почему это лучше «агентов на каждый сервер»

WEF (Windows Event Forwarding) – механизм, который позволяет компьютерам отправлять события журналов Windows на центральный сборщик.

WEC (Windows Event Collector) – роль на стороне сборщика, которая эти события принимает и складывает (обычно в журнал Forwarded Events).

Ключевой плюс WEF/WEC – это «родной» для Windows способ: не надо ставить сторонние агенты только ради базового уровня наблюдаемости. Но есть и минусы: по умолчанию легко собрать много шума и трудно сделать удобный поиск, если не продумать структуру.

Архитектура «без боли»: один сборщик, защищённый транспорт, минимальная поверхность атаки

Самый устойчивый вариант для небольших и средних инфраструктур:

Отдельный Windows VPS под WEC (и под хранение EVTX, экспорт, отчёты, алерты)
Источники событий – ваши Windows-серверы/рабочие станции, которые пересылают отфильтрованные события на сборщик
Транспорт – внутри приватной сети или через VPN. Это важно: WEF использует WinRM/WS-Management, и публиковать WinRM в интернет – плохая идея

Если у вас есть возможность построить приватную сеть между серверами у провайдера – используйте её. Если часть источников живёт «в офисе» – поднимайте VPN до VPS и форвардите логи внутри туннеля. Логика простая: протокол сбора должен быть доступен только тем, кому он нужен.

Source-initiated или Collector-initiated: какой режим выбирать

У WEF есть два режима подписок:

Source-initiated – вы создаёте подписку на сборщике, а источники сами подключаются и отправляют события. Удобно, когда источников много и они «появляются/исчезают»
Collector-initiated – сборщик сам «обходит» список источников, прописанных в подписке. Удобно для маленького и стабильного набора хостов, но требует ручного списка

Для реальной эксплуатации чаще выигрывает source-initiated: проще масштабировать и меньше ручной рутины при добавлении машин. Microsoft отдельно описывает различия этих моделей в документации по подпискам WEC/WEF.

Подготовка сборщика: включаем WEC и наводим порядок до первой подписки

На сборщике первое, что делается штатно:

Запускается служба Windows Event Collector
Выполняется quick-config, чтобы подписки переживали ребуты и базовая конфигурация была корректной

Команда (в повышенной консоли):

wecutil qc

Эта команда официально описана в документации по wecutil и делает WEC «готовым к работе» (включая настройки службы и устойчивость подписок).

Безопасность WinRM: что запрещаем сразу

WEF работает поверх WinRM/WS-Management. Типичные ошибки:

включили WinRM и оставили его доступным «откуда угодно»
разрешили слабые режимы аутентификации «чтобы заработало»
не разделили сеть и не ограничили источники

Нормальная практика: доступ к WinRM на сборщике ограничен только подсетью VPN/приватной сети и только от нужных машин. Дальше, в зависимости от среды, используется Kerberos (в домене) или WinRM по HTTPS с сертификатами (когда домена нет, но вы готовы аккуратно пройти этот путь). Снаружи интернет не должен видеть ни WinRM, ни RPC, ни «служебные» порты.

Настройка источников: минимальный набор, без которого будет «тишина»

Источники должны знать, куда отправлять события. В доменной среде это делается через Group Policy: на клиентах прописывается параметр SubscriptionManager с адресом WEC.

В недоменной среде это тоже возможно, но сложнее и требует дисциплины по сертификатам/учёткам. Если инфраструктура небольшая, иногда проще сначала поднять VPN и доменную связность, а уже потом строить WEF.

Самая частая ошибка: «соберём всё», а потом утонем

Если вы сделаете подписку на все события Security, Application, System со всех серверов, сборщик превратится в мусорку, а вы перестанете туда смотреть. Правильная логика обратная:

Определите сценарии, которые вы хотите видеть (а не «все логи мира»)
Под эти сценарии выберите источники журналов и конкретные события
Сразу заложите фильтрацию на стороне подписки, а не «потом разберём»

Почему Sysmon нужен даже «без SIEM»

Windows Security log полезен, но он не всегда даёт ту детализацию, которая нужна для расследований. Sysmon (Sysinternals) дополняет картину событиями процесса, сетевых соединений, загрузок модулей и другими сигналами. Важно: Sysmon хорош только тогда, когда у него есть вменяемая конфигурация. Включить все события без фильтра – это снова шум.

Sysmon документирован Microsoft в Sysinternals, там же перечислены его Event ID и базовые принципы. Например, Event ID 1 – создание процесса, Event ID 3 – сетевое соединение (по умолчанию выключено), и так далее. Это база, на которой строится дальнейший набор правил.

Базовая стратегия конфигурации Sysmon: «меньше, но качественнее»

Нормальная стартовая стратегия:

включить те события, которые дают расследуемую ценность (процессы, сетевые соединения, создание файлов в чувствительных каталогах, изменения в реестре автозапуска, DNS-запросы)
сразу исключить системный шум (служебные директории, известные системные процессы, «болтливые» пути)
оставить себе путь к расширению конфигурации, когда появится опыт «что именно ловим»

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

Что именно форвардить на сборщик: рабочий «минимум», который даёт пользу

Если ваша цель – понятные алерты без SIEM, вы выбираете не «тонну данных», а события, которые поддерживают простые вопросы:

кто и как входил на сервер (успешно/неуспешно, тип входа, откуда)
кто получил повышенные привилегии
кто создал пользователя или добавил в админскую группу
кто поставил сервис/задачу/изменил политику аудита
какие процессы запускались и какие сетевые соединения они делали (для подозрительных цепочек)

Практический набор для Security log (как ориентир, не догма):

4624 – успешный вход
4625 – неуспешный вход
4688 – создание процесса (если включено Audit Process Creation)
4672 – «special privileges assigned» (сигнал админских контекстов)
4720 – создан пользователь
4728/4732 – добавление в группы (особенно админские)
7045/4697 – установка службы (зависит от источника события)
1102 – очистка Security-лога
4719 – изменение политики аудита

Microsoft подробно описывает, что означают ключевые события аудита входов (например, 4624 и 4625. и события создания процессов (4688), и это полезно использовать как первоисточник смысла полей и рекомендаций мониторинга.

Практический набор для Sysmon (если конфигурация адекватная):

1 – Process creation (основа цепочек)
3 – Network connection (включать аккуратно, фильтровать)
11 – File create (только для чувствительных путей)
13 – Registry value set (автозапуски и системные ключи)
22 – DNS query (полезно для подозрительных доменов и туннелей)

WEF-фильтры: как резать шум до того, как он приехал на сборщик

Самая полезная привычка при WEF – фильтровать на входе. Подписка позволяет задавать XPath-фильтры по Event ID и полям. Хорошая логика: собирать «конструкцию инцидента», а не весь журнал.

Например, для «попыток подбора пароля» часто достаточно 4625 с ограничением по LogonType и исключением ожидаемых сервисных аккаунтов. Для «подозрительных админских входов» – 4624 + 4672 + контекст времени/источника.

Хранилище логов на сборщике: Forwarded Events – это только начало

По умолчанию события попадают в журнал Forwarded Events. Это удобно, но для эксплуатации нужно продумать ещё три вещи:

Размер и удержание: увеличьте размер журналов так, чтобы хватало хотя бы на разумное окно расследований (например, 7-30 дней по вашей нагрузке)
Экспорт: периодически экспортируйте события в EVTX файлы по расписанию, чтобы не зависеть от ротации одного журнала
Доступ: ограничьте, кто может читать логи и кто может менять подписки. Логи – это и чувствительные данные, и источник правды при инциденте

Алерты без SIEM: три модели, которые реально работают

Когда говорят «без SIEM», часто подразумевают «без правил». На самом деле правила нужны, просто они должны быть простыми, прозрачными и обслуживаемыми.

Модель 1. Task Scheduler по событию + PowerShell-уведомление

Вы создаёте задачу, которая триггерится на событие в журнале (на сборщике) и запускает скрипт. Скрипт может:

отправить письмо (SMTP)
кинуть сообщение в Telegram/Slack через webhook
создать тикет через HTTP API вашей системы

Плюс модели – простота и скорость. Минус – надо аккуратно относиться к «штормам событий» (ограничения по частоте, дедупликация).

Модель 2. Периодический «детектор» раз в 1-5 минут

Вместо триггера на каждое событие вы раз в минуту делаете выборку последних N минут через Get-WinEvent и применяете логику: пороги, корреляция, исключения. Это спасает от «тысячи алертов» при брутфорсе и даёт нормальную агрегацию.

Модель 3. Ежедневные отчёты «для человека»

Часть сигналов не требует мгновенной реакции, но требует регулярного просмотра. Ежедневный дайджест в почту или чат часто даёт больше дисциплины, чем «молчаливые логи».

Примеры понятных правил, которые дают реальную пользу

Ниже не «магия», а набор, который обычно окупается сразу. Каждое правило требует настройки исключений под вашу среду.

1. Подбор пароля по RDP или службам

Событие: 4625
Сигнал: за 5 минут ≥ 10 неуспешных входов с одного IP или по одной учётке
Действие: уведомление + опционально временная блокировка IP на периметре/VPN

2. Успешный интерактивный вход «не оттуда»

Событие: 4624 (и полезно связать с 4672 при админских привилегиях)
Сигнал: вход в нетипичное время или с нетипичного IP/подсети
Действие: уведомление, проверка, при необходимости – смена пароля и анализ цепочки процессов

3. Создание пользователя или добавление в админскую группу

События: 4720, 4728/4732
Сигнал: любое событие вне окна изменений
Действие: немедленное уведомление. Это почти всегда важно

4. Очистка журнала Security

Событие: 1102
Сигнал: само событие
Действие: немедленно. Очистка логов в серверной среде редко бывает «случайной»

5. Установка службы или подозрительная персистентность

События: 7045 и/или 4697 (в зависимости от включённых политик и источников)
Сигнал: новая служба, особенно с бинарником из профиля пользователя, Temp или нестандартных путей
Действие: уведомление + проверка файла, подписи, хэша, владельца

6. Sysmon: подозрительная цепочка процессов

Простейшая и очень рабочая корреляция: если вы видите, что winword.exe или excel.exe запускает powershell.exe или cmd.exe, а затем идут сетевые соединения – это почти всегда требует проверки. Для этого нужны события Sysmon 1 (процессы) и 3 (сеть) или Security 4688 (процессы) в связке с сетевыми событиями других источников.

Как не утонуть в Sysmon: «фильтруй пути, а не мечты»

Sysmon становится полезным, когда вы осознанно фильтруете:

пути (Temp, Downloads, AppData, Public – часто интереснее системных)
типы файлов (скрипты, исполняемые, ярлыки)
родительские процессы (Office, браузеры, почтовые клиенты)
сетевые назначения (нестандартные порты, внешние страны, редкие домены)

Если включить «file create» на весь диск, вы получите миллионы событий. Если включить «file create» только на чувствительные каталоги (например, автозагрузки, каталоги сервисов, папки с критичными данными) – вы получите сигнал.

Практическая эксплуатация: время, целостность, резерв и доступ

Централизация логов бесполезна, если:

на машинах разъезжается время (корреляция становится лотереей)
логи могут читать и менять «все админы подряд» без контроля
нет выгрузки EVTX и резервной копии хранилища логов

Минимальная дисциплина:

все хосты синхронизируются с нормальным источником времени
права на подписки WEC и журналы ограничены
EVTX экспортируются по расписанию на отдельный диск/хранилище
раз в месяц вы проверяете «а алерты вообще приходят» (тестовые события)

Тестирование: как понять, что WEF работает, а не «вроде настроили»

Проверка должна быть практичной:

на источнике вызываете контролируемое событие (например, неуспешный вход, запуск тестового процесса)
на сборщике убеждаетесь, что событие приехало в Forwarded Events и содержит нужные поля (Computer, User, IpAddress там, где ожидается)
проверяете задержку доставки и объём шума
проверяете, что алерт срабатывает один раз, а не сотней дублей

Чек-лист внедрения: от нуля до первых алертов за вечер

Выделить отдельный Windows VPS под WEC и анализ
Закрыть WinRM снаружи, обеспечить приватную сеть или VPN
На сборщике выполнить wecutil qc, настроить размеры журналов и доступ
Выбрать модель подписки (обычно source-initiated), создать подписки с фильтрами под сценарии
Подключить источники (GPO/настройки), проверить доставку
Развернуть Sysmon на источниках с умеренным конфигом, начать с полезных Event ID
Собрать «минимальный набор» Security-событий (логины, привилегии, создание пользователей, службы, очистка логов)
Сделать 5-8 правил алертов: брутфорс, подозрительный логин, админские изменения, очистка логов, новая служба, подозрительная цепочка процессов
Настроить дедупликацию и пороги, чтобы алерты не превращались в спам
Наладить экспорт EVTX и резерв

Финальная мысль: «без SIEM» не значит «без системы»

WEF/WEC плюс Sysmon – это честный способ получить центральные логи и расследуемую телеметрию, не покупая SIEM и не превращая инфраструктуру в «зоопарк агентов». Но успех упирается не в галочки, а в дисциплину: что именно вы собираете, зачем, как режете шум и как реагируете на сигналы. Сделайте это один раз аккуратно, и дальше оно работает годами, постоянно окупаясь в момент, когда «всё пошло не так».

Когда логи централизованы, вы перестаёте «прыгать по серверам» и начинаете реально видеть картину. Но сборщик становится инфраструктурным узлом, и ему нужны ресурсы: диск под EVTX и экспорт, CPU под индексацию и выборки, память под запросы. На виртуальном сервере это проще масштабировать, чем на старом железе в углу офиса.

Если вы планируете собирать логи хотя бы с нескольких Windows-серверов и пары десятков рабочих станций, разумно сразу заложить быстрый диск и возможность увеличить объём хранения без миграций. На VPS.house заказать VPS Windows можно как раз в формате «поднял, померил, докрутил», и это часто оказывается быстрее, чем пытаться выжать из случайного локального сервера роль «центрального лог-хаба».