Bem-vindo à aula sobre Segurança de Wazuh! Nesta aula, você aprenderá sobre os componentes essenciais que tornam o Wazuh uma plataforma robusta de monitoramento de segurança. Vamos explorar como os agents coletam dados, como as rules (regras) analisam esses dados para detectar ameaças, como o integrity monitoring (monitoramento de integridade) protege arquivos críticos e como as respostas ativas podem automatizar ações defensivas. Ao final, você terá uma compreensão sólida para implementar e gerenciar o Wazuh em seu ambiente.

O Wazuh é uma solução open source de SIEM e XDR que oferece visibilidade em tempo real sobre eventos de segurança em endpoints e infraestruturas. Sua arquitetura é composta por um servidor central (manager) e por agents instalados nos hosts monitorados. Nesta aula, focaremos nos aspectos de segurança que você, como profissional, precisa dominar para extrair o máximo da plataforma.

Agents

Os agents são componentes leves instalados nos hosts que você deseja monitorar. Eles coletam dados de segurança, como logs de sistema, eventos de autenticação, integridade de arquivos e informações de inventário, e os enviam para o servidor Wazuh (manager) através de canais criptografados. A comunicação entre agent e manager é protegida por TLS/SSL, garantindo confidencialidade e integridade dos dados.

A instalação de um agent envolve a criação de um pacote específico para o sistema operacional do host e a configuração do endereço do manager. O processo típico é:

  1. Adicionar o repositório do Wazuh e instalar o pacote do agent.
  2. Registrar o agent no manager usando um comando como agent-auth.
  3. Configurar o arquivo ossec.conf para definir o endereço do manager e as opções de monitoramento.
  4. Iniciar o serviço do agent.

Exemplo de configuração básica do ossec.conf para um agent:

<ossec_config>
  <client>
    <server>
      <address>192.168.1.100</address>
      <port>1514</port>
      <protocol>tcp</protocol>
    </server>
    <crypto_method>aes</crypto_method>
  </client>
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>
</ossec_config>

Os agents podem ser gerenciados centralmente pelo manager, permitindo atualizações remotas e configuração distribuída. Eles também suportam o modo de agente sem servidor (serverless) para ambientes efêmeros, como contêineres.

Rules

As rules são o coração da detecção de ameaças no Wazuh. Elas definem padrões e correlações que geram alertas quando eventos específicos ocorrem. As rules são escritas em formato XML e podem ser baseadas em campos de logs, como nível de severidade, fonte, destino, entre outros. O Wazuh inclui um conjunto padrão de regras, mas você pode criar regras personalizadas para atender às necessidades do seu ambiente.

A estrutura básica de uma rule inclui:

  • <rule>: elemento raiz que contém a definição.
  • id: identificador único da regra.
  • level: nível de severidade (0-15), que determina a importância do alerta.
  • field: campos do evento que serão comparados.
  • match ou regex: padrão a ser correspondido.

Exemplo de uma regra que detecta múltiplas falhas de autenticação SSH:

<rule id="100001" level="5" frequency="5" timeframe="60">
  <if_matched_sid>5710</if_matched_sid>
  <description>Múltiplas falhas de autenticação SSH em 1 minuto</description>
  <group>authentication_failures,</group>
</rule>

Nesta regra, se houver 5 eventos correspondentes à regra 5710 (falha de autenticação SSH) em 60 segundos, um alerta de nível 5 será gerado. As rules podem ser combinadas com if_sid, if_group, if_matched_sid para criar correlações complexas.

Para testar suas regras, você pode usar a ferramenta ossec-logtest, que simula eventos e verifica se correspondem às regras. Isso é essencial para ajustar regras sem gerar alertas falsos.

Integrity monitoring

O integrity monitoring (FIM - File Integrity Monitoring) é um recurso que detecta alterações em arquivos e diretórios críticos. Ele calcula somas de verificação (checksums) dos arquivos monitorados e compara com valores anteriores. Qualquer modificação, criação ou exclusão gera um alerta. Isso é fundamental para detectar atividades maliciosas, como alteração de arquivos de sistema ou instalação de rootkits.

Para configurar o FIM, você deve adicionar entradas <syscheck> no arquivo ossec.conf do manager ou do agent. Exemplo:

<syscheck>
  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <ignore>/etc/mtab</ignore>
  <frequency>3600</frequency>
</syscheck>

Aqui, os diretórios /etc, /usr/bin e /usr/sbin serão monitorados a cada 3600 segundos (1 hora). O atributo check_all verifica todas as propriedades (permissões, owner, tamanho, hash). Você também pode usar check_sum, check_sha256, etc. para personalizar.

O FIM também suporta monitoramento em tempo real via whodata, que fornece informações sobre quem fez a alteração (usuário, processo). Para ativar, use whodata="yes" na entrada de diretório. Isso é útil em ambientes onde a responsabilidade é importante.

Os alertas de FIM aparecem no console do Wazuh com detalhes como arquivo alterado, tipo de alteração (modified, added, deleted) e a soma de verificação antiga e nova. Você pode configurar notificações para esses eventos via e-mail ou integrações com outras ferramentas.

Response

As respostas ativas (active response) são ações automáticas que o Wazuh pode executar quando um alerta é disparado. Elas permitem mitigar ameaças em tempo real, como bloquear um IP, encerrar uma sessão ou desabilitar uma conta de usuário. As respostas podem ser executadas no próprio agent ou no servidor, dependendo da configuração.

A configuração de respostas ativas envolve dois componentes: o <command> e o <active-response> no arquivo ossec.conf do manager. O comando define a ação a ser executada, e a resposta define quando e onde executar.

Um exemplo de comando para bloquear um IP usando iptables:

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop.sh</executable>
  <expect>srcip</expect>
  <timeout_allowed>yes</timeout_allowed>
</command>

E a resposta associada a uma regra:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <level>7</level>
  <rules_id>100001</rules_id>
  <timeout>300</timeout>
</active-response>

Neste exemplo, quando a regra 100001 (definida anteriormente) gerar um alerta de nível 7 ou superior, o comando firewall-drop será executado no agente que originou o evento, bloqueando o IP de origem por 300 segundos.

É crucial testar as respostas ativas em um ambiente controlado para evitar ações indesejadas. O Wazuh oferece a capacidade de definir respostas apenas para determinados grupos de agentes, e você pode usar variáveis como srcip, user, etc., para personalizar.

Boas práticas

Ao trabalhar com Wazuh, considere as seguintes boas práticas:

  • Mantenha as regras atualizadas: utilize as regras padrão e ajuste conforme necessário, mas evite regras muito amplas que gerem ruído.
  • Use o ossec-logtest para validar suas regras antes de implantá-las.
  • Monitore o desempenho do manager: o processamento de muitos eventos pode exigir recursos. Ajuste o frequency do syscheck e a quantidade de agents.
  • Implemente respostas ativas com cuidado: comece com ações não destrutivas e com timeout.
  • Configure alertas de integridade para arquivos críticos, mas evite monitorar diretórios que mudam com frequência para reduzir falsos positivos.

Referências

Exercícios

  1. Qual é a função de um agent no Wazuh e como ele se comunica com o manager?

    ✓ Resposta: O agent é um software instalado no host monitorado que coleta dados (logs, integridade de arquivos, etc.) e os envia ao manager via protocolo criptografado (TLS/SSL) na porta padrão 1514. Ele também pode receber comandos do manager para executar respostas ativas.

  2. Crie uma regra que detecte quando o usuário 'root' fizer login via SSH fora do horário comercial (ex.: entre 22h e 6h).

    ✓ Resposta: Uma possível regra é: 
    <rule id="100002" level="8">
  <if_matched_sid>5715</if_matched_sid> <!-- regra de login SSH bem-sucedido -->
  <field name="user">root</field>
  <field name="time">^(22|23|00|01|02|03|04|05)::</field>
  <description>Login SSH como root fora do horário comercial</description>
</rule>

  3. Explique a diferença entre check_all e check_sha256 no syscheck.

    ✓ Resposta: check_all verifica todas as propriedades do arquivo (permissões, owner, tamanho, hash, etc.), enquanto check_sha256 verifica apenas o hash SHA-256. Usar check_all é mais abrangente, mas pode gerar mais alertas; check_sha256 é mais específico para alterações de conteúdo.

  4. Descreva um cenário em que uma resposta ativa seria útil e como você a configuraria.

    ✓ Resposta: Um cenário comum é bloquear automaticamente um IP que está realizando ataques de força bruta no SSH. Você configuraria um comando que adiciona uma regra no iptables para descartar pacotes desse IP, e uma resposta ativa associada à regra de detecção de múltiplas falhas de autenticação. Exemplo de configuração foi mostrado na seção Response.

  5. Qual é a finalidade da ferramenta ossec-logtest e como ela ajuda no desenvolvimento de regras?

    ✓ Resposta: O ossec-logtest é uma ferramenta de linha de comando que simula eventos de log e verifica se eles correspondem às regras existentes. Ele permite testar regras em tempo real sem gerar alertas reais, ajudando a ajustar padrões e evitar falsos positivos antes da implantação.

Observações finais

Nesta aula, cobrimos os pilares da segurança do Wazuh: agents, rules, integrity monitoring e response. A combinação desses recursos permite uma postura de segurança proativa, detectando e respondendo a ameaças em tempo real. Lembre-se de que a configuração correta e a manutenção contínua são essenciais para o sucesso. Explore a documentação oficial e pratique em um ambiente de laboratório para se tornar proficiente.