Reencaminhamento de eventos do Windows em larga escala com vários domínios

Question

Deixe-me começar a explicar o que estou tentando fazer: Temos uma ferramenta de RMM instalada em muitos servidores do Windows. Ele é capaz de enviar logs de eventos do Windows para um armazenamento central, mas não de maneira eficiente ou confiável. Eu gostaria de usar o WEF nativo em servidores Windows para enviar eventos específicos para uma loja central analisada de qualquer um dos ruídos redundantes (então, apenas, qual é o id do evento, fonte e outros detalhes específicos para o eventid / source como nome de usuário tentativa, estação de trabalho / IP de origem). Esses servidores não estão no mesmo domínio e estão dispersos geograficamente pelo mundo. Eu sei que existem inúmeras plataformas para fazer isso (Splunk, por exemplo), mas elas normalmente são superfaturadas e se tornaram um absurdo inchado por tentar executar essa tarefa simples.

Minha ideia original era configurar o WEF em servidores e fazer com que eles enviassem os logs para um servidor central com assinaturas configuradas para ouvi-los, fazer com que os logs fossem analisados por detalhes importantes e usar algo como logstash / filebeat / nxlog para empurrá-los para o ELK para que pudéssemos monitorar eventos importantes (logons com falha, logs de segurança sendo limpos, explorações de escalação do kerberos priv / criações de tickets de ouro, etc.). Quanto mais fundo eu tenho, mais eu percebi que não é como o WEF / WinRM deve ser usado. Eles querem que você tenha um servidor local no mesmo domínio para armazenar os logs. O mais próximo que pude encontrar é o seguinte: link , mas ele é direcionado a vários sites no AD pertencentes ao mesmo domínio. Em nosso caso, o servidor de armazenamento de log central não estará em nenhum domínio e precisa aceitar logs de eventos de vários outros domínios.

Antes de passar várias horas configurando, imaginei que pediria aqui - é esse o tipo de coisa que eu deveria usar apenas para analisar e enviar diretamente dos servidores em questão, em vez de se incomodar com o WEF? ? É como está se sentindo agora, mas eu só queria me certificar de que não estou negligenciando algo óbvio.

    

Answer 1

Já faz muito tempo desde que eu tentei o envio nativo de log no Windows, mas lembro que era muito mais difícil do que eu esperava. Não consigo imaginar fazer isso fora do domínio ou mesmo fora da federação. Esta será uma resposta logstash porque é isso que eu sei.

Seus instintos estão corretos, a maneira de fazer isso fora de um único domínio é usar algo como Winlogbeat para extrair os eventos do Windows dos produtores e transmiti-los em algum lugar onde você possa processá-los. Dependendo da sua fluência com a manipulação de Eventos do Windows, pode ser mais fácil fazer a filtragem no nível Eventos do Windows (enviar apenas os eventos que você deseja para um log de eventos do mesmo servidor apenas para isso e apontar WinlogBeat para isso) em vez de fazê-lo no nível de batidas.

Fazer isso em escala significa pensar em compensações. Para uma grande frota de produtores de log de segurança do Windows, você está olhando para uma alta taxa de eventos quando se trata de ingestão. Para configurações maiores, é altamente recomendável usar uma fila de buffer de algum tipo entre as batidas e a camada do Logstash que faz toda a marcação. Existem algumas opções, mas o Redis e o Kafka são suportados se já estiverem na sua infraestrutura.

Você também pode enviar diretamente de batidas para o Elasticsearch, mas isso deixa muito do poder de transformação do Logstash na tabela. Além disso, o ES ingere os dados mais rapidamente (mais eventos por segundo) quando houver alguns nós fazendo grandes inserções em massa, em vez de muitos nós fazendo pequenas inserções em massa. Novamente, você já pode ter a infraestrutura / experiência do ElasticSearch no site onde isso pode não ser um problema.

    

Answer 2

Você pode configurar um servidor Windows em um grupo de trabalho, criar um coletor iniciado por origem e especificar os computadores para os quais os eventos serão recebidos com o curinga do (s) nome (s) DNS da floresta. Veja a parte inferior deste artigo:

link