Os fundamentos da coleta central de log com WEF e WEC

Na semana passada, abordamos o essencial do logging de eventos: garantir que todos os seus sistemas estejam escrevendo logs sobre os eventos ou atividades importantes que ocorrem neles. Esta semana, vamos abordar o essencial da coleta centralizada desses logs de eventos em um servidor Windows Event Collector (WEC), que então encaminha todos os logs para o Elastic Security.

WEF e WEC

As versões modernas do Windows incluem os serviços de gerenciamento remoto do Windows (WinRM) que implementam o protocolo WS-Management (WSman) e, para complicar ainda mais a situação, tudo isso faz parte do Windows Management Instrumentation (WMI). Um componente do WinRM é o serviço de encaminhamento de eventos do Windows (WEF), e é por isso que o WinRM e seus componentes precisam estar habilitados. O WEF pode encaminhar os logs de eventos do Windows para um servidor Windows que execute o serviço coletor de eventos do Windows (WEC).

Existem dois modos de encaminhamento:

1. Iniciada pela fonte: o serviço WEF se conecta ao servidor WEC.
2. Iniciado pelo coletor: O serviço WEC se conecta ao serviço WEF.

Ambos utilizam o WSman para encaminhar os logs e exigem que o WinRM esteja em execução.

Existem diversas armadilhas e obstáculos na criação do WEF e do WEC. Seguindo nosso guia prático do WEC, você pode evitá-los. No entanto, para uma visão mais abrangente e com um contexto mais rico, discutiremos esses pontos aqui, bem como a solução adotada no guia prático.

Arquivo de log de eventos 'Eventos Encaminhados'

No sistema de Log de Eventos do Windows, existem Canais. Esses Canais são, em última instância, compatíveis com um arquivo de log de eventos que armazena todos os logs de eventos gravados nesse Canal. Um sistema Windows vem com um conjunto de Canais predefinidos e os aplicativos podem adicionar seus próprios Canais registrando novos "Provedores".

Isso significa que, de imediato, um servidor WEC só tem os Canais que um servidor Windows normal tem para seus próprios logs. Então, onde se deve armazenar todos os logs que estão sendo encaminhados para o servidor WEC? Existem três opções; Vamos analisá-las:

1. Armazenar no Canal local correspondente ao Canal remoto (ou seja, os eventos remotos do Canal "Segurança" são armazenados no Canal local "Segurança" do WEC). 

Armadilhas:

• todos os seus logs remotos estão misturados com seus logs locais 
• O servidor WEC pode encaminhar seus próprios logs de eventos para este canal.
• O gerenciamento de logs e o controle de acesso tornam-se muito difíceis.

2. Armazene todos os logs remotos no canal local "Eventos Encaminhados".

Armadilhas:

• desempenho de gravação ruim, já que todas as gravações são feitas em um único arquivo.
• Desempenho de busca/leitura ruim, pois os eventos não são particionados em arquivos separados.
• Gerenciamento inadequado do ciclo de vida dos dados, visto que isso ocorre por arquivo de log, portanto todos os eventos encaminhados são tratados da mesma forma.
• Má utilização dos recursos do servidor WEC, pois todo o trabalho fica concentrado em um único arquivo.
• Gerenciamento de acesso deficiente; arquivos separados permitiriam controles de acesso diferenciados aos arquivos.
• Cobertura/visibilidade deficiente — devido aos problemas acima, muitos restringem severamente quais logs de eventos são encaminhados, deixando lacunas em sua visibilidade.

3. Crie novos canais para o servidor WEC. 

Isso não é tão óbvio quanto parece, e a maioria das pessoas seria perdoada por não saber que essa é uma opção. 

Muitos servidores WEC foram configurados com as opções 1 ou 2 (acima), até que a própria equipe de Security interna da Microsoft escreveu um post do blog (há cerca de 15 anos) sobre como eles usaram o SDK do Windows para implementar a opção 3. Aqui está uma revisão semelhante publicada em 2016.

Novos canais para o evento WEC

Com a capacidade de criar canais de eventos arbitrários, o que devemos criar? Como devemos organizar e arquitetar nosso servidor WEC? Existem muitas linhas de pensamento — o Guia Prático do WEC agrupa os ativos corporativos para que você possa gerenciar o controle de acesso aos seus logs e o ciclo de vida dos dados de forma adequada.

Antes de nos aprofundarmos, vamos analisar outra abordagem. Alguns de vocês podem ter se deparado com a arquitetura e as diretrizes do WEC da Palantir. Nelas, eles criaram um canal para cada tipo de log de eventos: PowerShell, WMI, DNS, Firewall, etc. Esses canais contêm logs de todos os tipos de ativos (controladores de domínio, servidores de domínio, estações de trabalho de domínio) e departamentos/unidades de negócios/unidades organizacionais. Eles também não são organizados em uma hierarquia, portanto, seriam apenas uma longa lista no Visualizador de Eventos. Os canais, consequentemente, também possuem suas assinaturas do WEC. A Palantir também possui uma política de auditoria recomendada. 

Gosto de destacar outras abordagens, como esta da Palantir, pois não existe uma solução única e a abordagem deles pode ser mais adequada para a sua organização do que a apresentada no nosso Guia Prático.

Se você já examinou a lista de canais da Palantir, deve ter notado o formato “WEC#-Algo”, onde o número '#' aumenta a cada sete canais. Isso ocorre porque, no sistema de Log de Eventos do Windows, os canais são definidos pelo que é conhecido como um “Provedor” e podem definir no máximo oito canais:

No entanto, um bug na ferramenta “ecmangen”, que todos nós, da área de segurança e não desenvolvedores do SDK do Windows, usávamos, tornava frustrante ter mais de sete canais por provedor.

Em vez de corrigir os muitos bugs, parece que a Microsoft retirou o ecmangen do SDK do Windows. Ou seja, você usa um SDK mais antigo ou cria o arquivo XML do Manifest você mesmo — talvez com seu editor XML favorito.

Assim como todos os outros, eu usava o ecmangen (originalmente) e me limitava a sete canais para facilitar o processo. O Cookbook atual é baseado em scripts do PowerShell que geram o XML. O ecmangen não é mais necessário, então você pode usar oito canais, se quiser, embora o Cookbook ainda utilize apenas os sete canais recomendados.

Nota: imagine um provedor como uma caixa com oito canais, onde cada canal é, em última análise, um arquivo de log separado.

Organizar por ativo

Aproveitando o fato de que você pode ter quantos provedores quiser, podemos usar isso para organizar por ativo. Em seu ambiente do Active Directory, você provavelmente já agrupou os membros do domínio por tipo de ativo (por exemplo, servidores de domínio, controladores de domínio, estações de trabalho etc.) e/ou pelo departamento (ouso dizer unidade organizacional) ao qual esses ativos pertencem.

Então, no Cookbook você pode facilmente criar Providers para combinar com a organização do seu AD, no sentido de Providers por departamento (Unidade de Negócios ou OU) e/ou por tipo de Ativo e/ou por criticidade de Ativo (Laboratório/Teste/Produção).

Ao separar por tipo de ativo, você obtém o benefício adicional de poder gerenciar melhor o controle de acesso e o ciclo de vida dos logs. Se precisar consultar os logs de um tipo de ativo específico, você saberá onde encontrá-los.

Para simplificar, todos os provedores recebem o mesmo conjunto de canais (até oito). Em seguida, os sistemas são mapeados para um provedor (via Unidade Organizacional) e os logs de eventos desse sistema são mapeados para os canais desse provedor.

Por padrão, o script “wec_config.ps1”, usado para configurar o servidor WEC de acordo com a sua arquitetura do Active Directory, já vem com alguns provedores e atribuições de ativos definidos:

• Controladores de Domínio: Acho que a atribuição de membros está clara aqui.
• Servidores de domínio: Os servidores do seu domínio
• Clientes de domínio: Estações de trabalho do usuário (desktops/laptops)
• Domínio Privilegiado: Sistemas com mais privilégios (ex.: Jumphosts ou Servidor WEC)
• Membros do Domínio: categoria geral para membros normais do domínio; não fazem parte dos outros grupos.
• Domínio Diversos: Diversos, para aqueles hosts que não se encaixam.

É recomendável que você refine e edite a lista para que ela corresponda ao seu ambiente do Active Directory.

A lista de canais padrão é a seguinte:

• Aplicação: “Aplicação” e logs semelhantes
• Segurança: logs de “Segurnça” e similares.
• Sysmon: “Microsoft-Windows-Sysmon/Operacional”
• Sistema: logs “Sistema”, “Eventos de Hardware”, Cliente DNS, Cliente DHCP, “Configuração” e similares.
• Script: “Windows PowerShell” e logs semelhantes
• Serviço: logs de servidor DNS, servidor DHCP e outros serviços.
• Diversos: Quaisquer outros logs diversos

Novamente, você tem total liberdade para alterar isso de acordo com suas necessidades.

Assinaturas WEC

Uma assinatura WEC define o seguinte:

• Um filtro de log de eventos (XPath), que seleciona quais eventos devem ser encaminhados.
• Um canal de destino, indicando onde armazenar os eventos recebidos no servidor WEC.
• Tipo:
  • Iniciado pelo coletor, o WEC se conecta ao serviço WEF.
    • Computadores de destino, uma lista de computadores aos quais se conectar.
  • Iniciada pela fonte, a WEF se conecta ao servidor WEC.
    • Grupos de computadores, os grupos do Active Directory cujos membros (computadores) podem acessar esta assinatura.
• Opções de entrega de eventos para controlar a largura de banda/latência e/ou HTTP/HTTPS.
• Tipo de formato: RenderedText ou apenas o XML do evento

Os scripts do guia (principalmente o setup_subscriptions.ps1) configuram o tipo de formato XML de evento. Esses scripts são muito menores, o que significa maior taxa de transferência, mais logs armazenados, menos carga e menor consumo de largura de banda. No entanto, a desvantagem é que, se o provedor de origem (no sistema remoto) não estiver registrado localmente no sistema de log de eventos do servidor WEC, o Visualizador de Eventos não poderá exibir uma descrição textual da mensagem no seu idioma local. Contudo, o envio de eventos com texto renderizado consome tantos recursos que é difícil justificá-lo.

Mencionei no início que o WEF é uma função do WinRM. Bem, esse componente WinRM é executado como o usuário "Serviço de Rede" do sistema local. Isso significa que o WEF não consegue ler a maioria dos logs do sistema e o servidor WEC receberá uma mensagem de ID de evento 111 bastante genérica, sem nenhum outro log. Por esse motivo, o Guia Prático orienta você na criação de uma GPO para adicionar o "Serviço de Rede" ao grupo local "Leitores de Log de Eventos".

Como o WinRM obtém a configuração para o WEF? Na mesma GPO mencionada acima, também publicamos uma URL do WSman que lista todas as assinaturas do WEC nesse servidor. Na verdade, podemos listar várias URLs de assinaturas do WSman de vários servidores WEC, e o serviço WEF tentará obtê-las e executá-las todas — permitindo, assim, servidores WEC redundantes.

Todas as assinaturas? Não quero que minha estação de trabalho envie logs de eventos para os arquivos de log do meu controlador de domínio! As entradas do WSman que representam uma assinatura têm permissões de grupo do Active Directory aplicadas a elas, conforme configurado na configuração da assinatura. Isso significa que, se o computador no qual o WEF está sendo executado não for membro de um grupo do Active Directory com permissão para ler a assinatura, ele não poderá obtê-la e executá-la. Significa também que, se você não tomar cuidado e um computador for membro de mais de um grupo do Active Directory de assinatura do WEC, você receberá várias cópias do mesmo log de eventos desse host do WEF no seu WEC!

Grupos de computadores? Mas eu quero mapear os computadores com base na Unidade Organizacional (OU) em que estão localizados! Infelizmente, não é assim que o WEF/WEC/WinRM/WSman funcionam. No entanto, o Cookbook oferece um mecanismo para manter a associação de um determinado grupo sincronizada com as OUs especificadas. Assim, você pode simular que tudo é feito por meio de OUs!

Reunindo tudo

Há muita complexidade e vários elementos envolvidos que precisam ser configurados corretamente para garantir boa observabilidade ou segurança em casos de uso.

Mas não se preocupe, pois nosso livro de receitas está aqui, acompanhado de um conjunto de scripts em PowerShell para automatizar a maioria das etapas. Isso significa que há menos espaço para erros, as ações são reproduzíveis e, portanto, os erros são mais fáceis de corrigir.

Tudo começa com o script wec_config.ps1, que você pode editar à vontade. Todos os scripts seguintes seguirão o mesmo princípio. Portanto, você pode facilmente, por exemplo, alterar o filtro de log de eventos usado para selecionar quais logs de eventos serão encaminhados em wec_config.ps1 e, em seguida, executar novamente o script setup_subscriptions.ps1 para aplicar a alteração.

Vamos dar uma olhada no que os scripts fazem (o livro de receitas explica com muito mais detalhes como usá-los):

• wec_config.ps1 - A configuração do seu servidor WEC, obtida pelos outros scripts.
• gen_manifest.ps1 - Este script criará o arquivo XML de manifesto que descreve todos os seus provedores e seus respectivos canais para o SDK do Windows (não será mais necessário usar o ecmangen!).
• build_man2dll.ps1 - Usando seu arquivo manifesto, este script criará a DLL do Módulo do Subsistema de Eventos do Windows que implementa todos os seus novos provedores e canais em qualquer sistema em que você o instalar (normalmente o servidor WEC).
• install_channels.ps1 - Instala a DLL e o Manifesto no sistema local.
• configure_channels.ps1 - Aplicará a configuração de Caminho do Log e Tamanho do Log (de wec_config.ps1) a todos os seus canais recém-instalados.
• setup_subscriptions.ps1 - Irá configurar (criar ou reconfigurar) todas as assinaturas para seu provedor/canais no servidor WEC.
• map_ou2group.ps1 - Provavelmente você deseja usar as UOs do seu AD, mas as assinaturas do WEC selecionam computadores por meio de grupos do AD. Este script sincronizará a associação de grupos específicos aos computadores nas UOs especificadas, usando novamente a configuração em wec_config.ps1.
• gen_winlogbeat_config.ps1 - A configuração que acompanha o Winlogbeat não reconhece todos os seus canais adicionais de assinatura WEC, portanto, este arquivo atualizará essa configuração para você.
• beat_cmd.ps1 - Um script auxiliar para interagir com comandos do Beat no PowerShell.

Infelizmente, toda a configuração no Active Directory, como as Políticas de Grupo, ainda precisa ser feita manualmente — mas o Guia Prático contém instruções passo a passo com capturas de tela. Talvez eu escreva scripts para isso também algum dia, fiquem ligados.

Por fim, o Winlogbeat precisa ser configurado para enviar todos os logs do WEC para a Elastic Security. O livro de receitas também vai te guiar por isso.

Conclusão

Espero que após ler este post do blog e possivelmente o próprio livro de receitas você tenha uma boa ideia das decisões que precisa tomar antes de começar, além de agora ter toda a orientação e as ferramentas necessárias para criar o servidor WEC perfeito para sua empresa.

Agora que você configurou as políticas de auditoria adequadas, o WEF e um servidor WEC para encaminhar os logs de eventos do seu domínio AD para o Elastic Security, em nossa próxima post do blog, veremos o que você pode fazer com esses dados de log extremamente importantes e úteis no Elastic Security.

Se você é novo no Elastic Security, pode experimentar nossa versão mais recente no Serviço Elasticsearch no Elastic Cloud. Além disso, não deixe de aproveitar nosso treinamento de Início Rápido para garantir seu sucesso.

Veja outros guias de livros de receitas que escrevi: https://ela.st/tjs-cookbook-lib