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