Пересылка событий Windows в больших масштабах с несколькими доменами
Позвольте мне начать с объяснения того, что я пытаюсь сделать: у нас на многих серверах Windows установлен инструмент RMM. Он может отправлять журналы событий Windows в центральное хранилище, но не эффективным и надежным способом. Я хотел бы использовать собственный WEF на серверах Windows для отправки определенных событий в центральное хранилище, анализируемых на предмет любого избыточного шума (просто, что такое идентификатор события, источник и другие подробности, относящиеся к Eventid / source, такие как имя пользователя попытка, рабочая станция / исходящий IP). Эти серверы не находятся в одном домене и географически распределены по всему миру. Я знаю, что существует множество платформ для этого (например, Splunk), но они, как правило, завышены и стали раздутой чепухой за попытку выполнить эту простую задачу.
Моя первоначальная идея состояла в том, чтобы настроить WEF на серверах и заставить их отправлять журналы на центральный сервер с подписками, настроенными на их прослушивание, анализировать журналы на предмет важных деталей, а затем использовать что-то вроде logstash/filebeat/nxlog для их отправки. в ELK, чтобы мы могли отслеживать важные события (неудачные входы в систему, очистка журналов безопасности, взломы привилегий Kerberos Priv / создание золотых билетов и т. д.). Чем глубже я становился, тем больше понимал, что WEF/WinRM не предназначены для использования. Они хотят, чтобы у вас был локальный сервер в том же домене для хранения журналов. Самое близкое, что я мог найти к этому - это рецензия: https://blogs.msdn.microsoft.com/canberrapfe/2015/09/21/diy-client-monitoring-setting-up-tiered-event-forwarding/ ориентированы на несколько сайтов в AD, принадлежащих одному домену. В нашем случае центральный сервер хранения журналов не будет находиться в каком-либо домене и должен принимать журналы событий из множества других доменов.
Прежде чем я потратил несколько часов на его настройку, я решил спросить здесь - это что-то вроде того, что я должен просто использовать filebeat для анализа и отправки напрямую с рассматриваемых серверов вместо того, чтобы вообще беспокоиться о WEF? Это то, что я чувствую сейчас, но я просто хотел протянуть руку, чтобы убедиться, что я не пропускаю что-то очевидное.
2 ответа
Прошло много времени с тех пор, как я пытался доставить журналы в Windows, но я помню, что это было намного сложнее, чем я надеялся. Не могу представить, что делаю это вне домена или даже вне федерации. Это будет ответ logstash, потому что это то, что я знаю.
Ваши инстинкты верны, способ сделать это вне одного домена - использовать что-то вроде Winlogbeat для извлечения событий Windows из производителей и передачи их туда, где вы можете их обработать. В зависимости от вашей беглости с манипуляциями с событиями Windows, вам может быть проще выполнить фильтрацию на уровне событий Windows (просто отправьте только те события, которые вы хотите, в один и тот же серверный журнал событий, и укажите WinlogBeat на это), а не делать это на уровне ударов.
Делать это в масштабе означает думать о компромиссах. Для большого парка производителей журналов безопасности Windows вы ожидаете высокой частоты событий, когда дело доходит до приема пищи. Для больших установок настоятельно рекомендуется использовать некоторую очередь буферизации между битами и уровнем Logstash, который выполняет всю разметку. Есть несколько вариантов, но Redis и Kafka поддерживаются, если они уже есть в вашей инфраструктуре.
Вы также можете отправить напрямую из ударов в Elasticsearch, но это оставляет большую преобразующую силу Logstash на столе. Кроме того, ES принимает данные быстрее (больше событий в секунду), когда несколько узлов выполняют большие объемные вставки, а не многие узлы выполняют небольшие объемные вставки. Опять же, у вас уже может быть инфраструктура / опыт ElasticSearch на месте, где это не может быть проблемой.
Вы можете настроить сервер Windows в рабочей группе, создать сборщик, инициируемый источником, и указать компьютеры, с которых будут получать события, с помощью подстановочных знаков DNS-имен леса. Смотрите нижнюю часть этой статьи: