Artigo desenvolvido pelo Paulo Deolindo,  Consultor da Unirede.

Introdução

Wazuh é uma ferramenta open source que atua como SIEM/XDR. Seu principal papel então é gerir eventos de segurança e se for o caso, responder a eles. Wazuh, na minha concepção, vai muito além disso. Ele minimamente integra um conjunto de outras ferramentas e tecnologias que, junto à técnicas de “Threat hunting” e repositórios de “Threat Intelligence”, podem elevar o nível de um Security Operations Center (SOC) no que diz respeito às implementações técnicas e funcionalidades extra avançadas, também permitindo diversas integrações, inclusive com ferramentas de função de orquestração (SOAR) e as emergentes tecnologias de Inteligência Artificial IA). Ah, para não deixar passar, ele já é integrado ao Opensearch, outra ferramenta open souce a qual tem a função de indexar os eventos e assim, permitir sua escalabilidade horizontal, o que acaba sendo um dos requisitos para a composição de um SOC em seu mais alto nível de maturidade. Sendo assim, ele tem em si, a capacidade de gerar observação dos eventos, realizar correlacionamentos entre eles, aprender padrões comportamentais e identificar anomalias. 

Sim, Wazuh é tudo isso! 

Neste artigo, vamos explorar um pouco mais de suas capacidades, envolvendo uma prova de conceito (POC) para gerir softwares não desejados no ambiente corporativo. 

Boa leitura! 

Monitorar, Detectar e Responder

Essa tríade “injusta” pode ser vista em várias literaturas quando se fala de funções básicas a serem encontradas em uma ferramenta SIEM/XDR ou ainda, quando se está estruturando um SOC. Então, vamos entender que existem outras literaturas mais completas e precisamos estar cientes de outras fases que podem ser encontradas em um processo de resposta a incidentes de segurança: coletar, analisar, investigar, previnir, remediar, auditar, automatizar. Também é possível que as 3 primeiras citadas (coletar, detectar, responder) estejam de alguma forma em consoância com as outras fases extras desse texto. Bom, é importante pontuar que com Wazuh, você consegue passar por todas essas etapas. Mas neste artigo, pronho uma atividade um pouco mais simples e sim, vamos monitorar, detectar e responder a um evento indesejado: a instalação de um software indesejado em nosso parque de TIC. 

O cenário 

Constantemente as empresas buscam por funcionalidades específicas em softwares para atender algumas de suas demandas em TIC. Uma dessas funcionalidades é conhecida por “Endpoint management”, mas especificamente para este nosso exercício, a função de fazer deploy de softwares homologados pela empresa e undeploy dos que não são homologados. Bom, trago uma outra perspectiva para esse cenário: e se, pela ótica da Segurança da Informação/Cibernética esse software representasse um problema por ser antigo, inseguro, com bugs não corrigidos pelo desenvolvedor, vulnerável e associado a várias CVEs ainda ativas? Bom, daí temos um problema que pode ser tão grande quanto o de simplesmente não querer que alguém tenha o software em nosso parque. Pois bem. Vamos explorar o problema a partir desse ponto de vista. 

 

Inventário de software

Wazuh possui um módulo/processo chamado “syscollector” e pode ser configurado como abaixo: 

no 1h yes yes yes yes yes yes yes <!– Database synchronization settings –>
<synchronization>
<max_eps>10</max_eps>
</synchronization>

Esse bloco de configuração xml permite que o Wazuh Agent faça a coleta de dados de inventário do endpoint por ele monitorado e os envia ao Wazuh Manager. 

Como resultado, remos algo mais ou menos assim:

No caso acima, foi realizado um filtro para buscar por um software em específico, o “apache2”. Se retirarmos o filtro, teremos a lista completa de softwares registrados e algumas de suas informações que podem ser importantes, tal como a sua versão. 

Na grande maioria das vezes, ao intalarmos um software, não nos importamos com o detalhe de sua versão. Mas aí reside um grande perigo: uma versão vulnerável não poderia ser instalada em nosso parque. Mas, quem está de fato olhando para isso? Aposto, sinceramente, que algumas empresas e profisisonais estão, mas garanto, nem todos. Aí entra o Wazuh, com sua capacidade de avaliar tais dados e tomar ações à respeito. Contudo, é importante sinalizar que o Wazuh não é um software do tipo Endpoint Manager, mas aqui ele será usado para esse caso, demonstrando bem rapidamente sua capacidade de “monitorar, detectar e responder” a um evento, que no caso, é a instalação de softare potencialmente inseguro. 

 

 

 

Criando a lista de softwares e suas versões não desejadas 

Aqui, entra o conceito de CDB List (Constant Database) no Wazuh, que são arquivos simples e que possuem estrutura simples, igualmente. Veja o exemplo de uma lista de softwares não desejados: 

/var/ossec/etc/lists/software-to-remove 

ntpdate: apache2:2.4.32 proftpd: 

No caso acima, nossa lista possui apenas 3 linhas, sendo: 

software:version 

Dessa forma, temos 2 softwares que estão listados e não importam suas versões (ntpdate e proftpd). O primeiro, ntpdate, foi descontinuado e deu lugar a um mais seguro e mantido pela comunidade open source (ntpsec). O segundo, proftpd, apenas porque FTP (Foi o Tempo, Peixe) deveria dar lugar ao SFTP (Secure File Transfer Protocol) há um bom tempo. O terceiro software da lista, o apache2, é um HTTP Server mundialmente conhecido e infelizmente, também possui falhas registradas (felizmente). Tais falhas podem ser consultadas na própria página da Wazuh que trata um banco de dados reunido (CTI). Veja abaixo: 

 

 

No detalhe, o resultado da busca pelo apache2:

 

 

E ao entrarmos em detalhes pelo CTI: 

 

Bom, podemos parar por aqui. Já entendemos que há vários motivos para não se querer um software em nosso ambiente. Porém, estes foram apenas para a ilustração de nosso “use case”, apenas para os fins didáticos do artigo. 

Regras para monitoramento

Agora que sabemos que o Wazuh aceita uma CDB List de softwares não homologados para nosso parque de TIC, vamos avaliar uma regra que monitora a presença desses softwares: 

2902 etc/lists/denied-softwares Inventory alert: an insecure software was installed on the system: $(package):$(version).  

Na regra acima, nos baseamos em outra regra (2902) a qual detecta a instalação de um software pelo gerenciador dpkg (POC feita em Debian/Ubuntu) para identificar se o nome do pacote instalado (package) está presenta na lista. Caso sim, há um alerta de inventário. Aqui, ainda não estamos preocupados com a versãoo software. Queremos apenas detectá-lo. 

Se no endpoint monitorado, tentarmos instalar o software: 

apt -y install ntpdate 

Daí teremos essa reação no Wazuh: 

 

 

Perceba que há apenas 1 evento. Nesse caso, foram aplicados filtros para que o resultado ficasse mais claro na tela. 

Gol! A meta de “monitorar e detectar” foi atingida. Mas ainda não respondemos ao evento. Apenas o registramos. 

Removendo o software não desejado 

Para a continuidade desse trabalho, podemos pensar que, se o software não é desejado, além desse registro, temos de removê-lo. A ideia é simples e para isso, Wazuh vai precisar trabalhar o conceito de “active-response”. 

Um “active-response” é um processo que responde a eventos (a ideia do XDR) e sua maior expressão ocorre quando o Wazuh realiza algum bloqueio, por exempllo, de um IP suspeito. Nesse caso, o “active-response” removerá um software. 

Após o cadastro do “active-response”, temos a regra que registra a remoção: 

2900 ^remove$|^purge$ Dpkg (Debian Package) removed. Package name: $(package):$(version). config_changed,pci_dss_10.6.1,pci_dss_10.2.7,gpg13_4.10,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,nist_800_53_AU.14,tsc_CC7.2,tsc_CC7.3,tsc_CC6.8,tsc_CC8.1,  

Em seguida para testar, removemos o software manualmente (criar um active-reponse nesse caso, não terá efeito retroativo nesse escopo) e reinstalamos o mesmo software: 

apt -y install ntpdate 

Em seguida, no Wazuh, podemos ver nosso active-response em ação pelos resultados do front-end (evitamos inserir mais linhas de código e textos no artigo): 

 

Avaliando a versão do software

Para uma avaliação mais rigorosa, podemos alterar a regra (ou criar uma outra com outro id) que faça a seguinte avaliação da versão do software: 

2902 etc/lists/denied-softwares Inventory alert: an insecure software version was installed on the system: $(package):$(version).  

Onde “xx” em check_value corresponde à versão registrada na CDB List. 

Conclusão

A gestão de vulnerabilidades é uma prática fundamental para garantir a segurança e a integridade dos ambientes corporativos, especialmente em um cenário onde ameaças cibernéticas são cada vez mais sofisticadas e frequentes. Neste artigo, demonstramos como o Wazuh pode ser uma poderosa ferramenta para monitorar, detectar e responder automaticamente à instalação de softwares não desejados ou potencialmente inseguros.

Ao utilizar funcionalidades como o syscollector, CDB Lists e active-response, o Wazuh permite que as organizações criem um ambiente de TI mais seguro e proativo, reduzindo a exposição a riscos e melhorando a conformidade com padrões de segurança. A automação desses processos não apenas minimiza a intervenção manual, mas também acelera a resposta a incidentes, contribuindo para a resiliência da infraestrutura de TI.

Implementar soluções como o Wazuh vai além de simplesmente atender a requisitos técnicos — trata-se de proteger os ativos da empresa, preservar a reputação organizacional e garantir a continuidade dos negócios. Em um cenário onde cada segundo conta, contar com uma ferramenta que combina monitoramento contínuo, inteligência de ameaças e resposta ativa é um diferencial estratégico.

Se sua organização busca fortalecer a gestão de vulnerabilidades e aprimorar as práticas de segurança cibernética, o Wazuh é uma excelente escolha. Explore as possibilidades que essa plataforma oferece e esteja um passo à frente das ameaças!