Quando gerenciamos servidores dedicados ou infraestruturas físicas, a estabilidade do sistema operacional depende diretamente da saúde do hardware. Problemas térmicos na CPU, falhas em fontes de alimentação redundantes, erros de memória ECC ou a abertura indevida da tampa do chassi precisam ser detectados antes que provoquem travamentos inesperados do kernel ou corrupção de dados.
O IPMI (Intelligent Platform Management Interface) e o controlador BMC (Baseboard Management Controller) registram esses eventos em tempo real, independentemente de o sistema operacional estar respondendo ou não. Integrar essa telemetria ao Wazuh permite centralizar alertas de integridade física no mesmo painel utilizado para eventos de segurança.
Neste artigo, vamos entender como o Linux se comunica com o BMC no nível do kernel, como configurar a ingestão de logs no Wazuh via rede ou agente local, como criar decodificadores e regras personalizadas e como configurar ações automáticas de segurança física.
1. Do silício ao kernel: como o Linux conversa com o BMC#
O BMC é um microcontrolador independente instalado na placa-mãe do servidor. Ele continua ligado mesmo quando a máquina principal está desligada, desde que o cabo de força esteja conectado.
A comunicação entre o sistema operacional e o BMC ocorre através de interfaces de hardware como KCS (Keyboard Controller Style), mapeadas em regiões de memória e portas de entrada e saída (I/O).
Os módulos de kernel ipmi_si e ipmi_devintf#
Para que programas em espaço de usuário (como o utilitário ipmitool) consigam ler dados da placa-mãe, o Linux precisa de dois drivers principais:
ipmi_si: detecta a controladora física através das tabelas ACPI ou SMBIOS da placa-mãe, mapeia os endereços de I/O e gerencia interrupções de hardware.ipmi_devintf: cria o arquivo de dispositivo/dev/ipmi0, permitindo que aplicações enviem comandos diretamente ao driver através de chamadas de sistema.
+--------------------------------------------+
| Espaço de Usuário |
| [ Agente Wazuh ] <---> [ ipmitool ] |
+--------------------------|-----------------+
| open(), ioctl()
+--------------------------v-----------------+
| Kernel do Linux |
| [ /dev/ipmi0 ] (ipmi_devintf) |
| | |
| [ Driver de Interface Base ] (ipmi_si) |
+----------|---------------------------------+
| Barramento I/O (LPC / KCS)
+----------v---------------------------------+
| Hardware Físico |
| [ BMC / Controller (iDRAC, iLO, Supermicro)|
+--------------------------------------------+O que acontece no terminal durante a leitura de eventos#
Ao executar ipmitool sel list, o binário realiza chamadas de sistema específicas:
- Abre o descritor de arquivo
/dev/ipmi0. - Executa chamadas
ioctl()com constantes de controle da API do IPMI para enviar os comandos estruturados pelo barramento. - Lê os registros brutos da memória não-volátil (NVRAM) onde o BMC guarda o System Event Log (SEL).
Podemos observar essas chamadas com o strace:
strace -f -e openat,ioctl ipmitool sel last 12. Estratégias para enviar logs do BMC ao Wazuh#
Existem duas formas práticas de coletar os dados do hardware no Wazuh: recepção remota via Syslog ou execução periódica pelo próprio agente instalado no servidor.
Opção 1: Envio remoto via syslog (out-of-band)#
Nesse modelo, configuramos a própria interface web do BMC (como iDRAC da Dell, iLO da HPE ou o painel da Supermicro) para encaminhar mensagens Syslog diretamente pela rede para o IP do Wazuh Manager na porta UDP 514.
No arquivo /var/ossec/etc/ossec.conf do Wazuh Manager, habilitamos a escuta:
<ossec_config>
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>192.168.100.0/24</allowed-ips>
<local_ip>192.168.100.10</local_ip>
</remote>
</ossec_config>Cuidados com buffers de rede UDP no Linux#
Como o Syslog via UDP não realiza controle de fluxo, picos repentinos de eventos físicos podem estourar o buffer de recepção de rede (rmem) do servidor Wazuh, fazendo com que pacotes sejam descartados silenciosamente pelo kernel.
Para evitar perda de mensagens sob estresse, ajuste os buffers de rede no arquivo /etc/sysctl.conf:
sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.rmem_default=26214400Opção 2: Leitura local pelo agente Wazuh (in-band)#
Se o BMC não estiver conectado a uma rede de gerência dedicada com acesso ao Wazuh, o próprio agente instalado no sistema operacional pode consultar o log local periodicamente.
Adicione o bloco <localfile> no arquivo /var/ossec/etc/ossec.conf do agente:
<ossec_config>
<localfile>
<log_format>full_command</log_format>
<command>ipmitool sel last 5</command>
<alias>ipmi_sys_event_log</alias>
<frequency>300</frequency>
</localfile>
</ossec_config>A cada 5 minutos (300 segundos), o agente executa o comando localmente, captura a saída no terminal e a encaminha de forma criptografada pela porta TCP 1514 para o Manager.
3. Construindo decodificadores e regras no Wazuh#
Com as mensagens chegando ao servidor central, precisamos instruir o motor de análise (wazuh-analysisd) a interpretar o formato tabular do ipmitool.
Criando o decodificador personalizado#
Crie o arquivo /var/ossec/etc/decoders/local_ipmi_decoders.xml no Manager:
<!-- Decodificador pai: identifica se o log veio do comando de IPMI -->
<decoder name="ipmi_hardware">
<prematch>^IPMI:|^ossec: output: 'ipmi_sys_event_log':</prematch>
</decoder>
<!-- Decodificador filho: extrai campos como data, hora, sensor e descricao -->
<decoder name="ipmi_hardware_sel">
<parent>ipmi_hardware</parent>
<regex>(\S+) \|\s+(\S+)\s+\|\s+(\S+)\s+\|\s+([^|]+)\s+\|\s+([^|]+)\s+\|\s+(\S+)</regex>
<order>ipmi_record_id, ipmi_date, ipmi_time, ipmi_sensor, ipmi_event_description, ipmi_status</order>
</decoder>Criando as regras de alerta#
Crie o arquivo /var/ossec/etc/rules/local_ipmi_rules.xml para mapear cenários críticos:
<group name="hardware,ipmi,">
<!-- Regra base de agrupamento -->
<rule id="110000" level="0">
<decoded_as>ipmi_hardware</decoded_as>
<description>Eventos fisicos extraidos da controladora IPMI.</description>
</rule>
<!-- Falha de fonte de alimentacao redundante (PSU) -->
<rule id="110001" level="10">
<if_sid>110000</if_sid>
<field name="ipmi_sensor">^Power Supply|^PSU</field>
<field name="ipmi_status">^Asserted</field>
<description>Falha detectada em fonte de alimentacao redundante.</description>
</rule>
<!-- Temperatura critica em processador ou placa -->
<rule id="110002" level="12">
<if_sid>110000</if_sid>
<field name="ipmi_sensor">^Temperature|^CPU Temp</field>
<field name="ipmi_event_description">Upper Critical going high</field>
<description>Limite termico critico atingido no hardware.</description>
</rule>
<!-- Invasao ou abertura fisica do chassi -->
<rule id="110003" level="9">
<if_sid>110000</if_sid>
<field name="ipmi_sensor">^Chassis Intrus|^Physical Security</field>
<description>Alerta de seguranca fisica: chassi do servidor aberto.</description>
</rule>
</group>4. Testando a decodificação com o Wazuh-logtest#
Antes de reiniciar os serviços em produção, utilize o utilitário nativo de testes do Wazuh para validar se os padrões regex capturam os dados corretamente:
/var/ossec/bin/wazuh-logtestCole uma linha de log de exemplo:
ossec: output: 'ipmi_sys_event_log': 002f | 06/18/2026 | 21:22:00 | Temperature #0x02 | Upper Critical going high | AssertedO utilitário deve confirmar o casamento nas três fases:
**Phase 1: Completed pre-decoding.
**Phase 2: Completed decoding.
name: 'ipmi_hardware'
parent: 'ipmi_hardware'
ipmi_sensor: 'Temperature #0x02'
ipmi_event_description: 'Upper Critical going high'
ipmi_status: 'Asserted'
**Phase 3: Completed filtering (rules).
id: '110002'
level: '12'
description: 'Limite termico critico atingido no hardware.'5. Casos de borda e problemas comuns de hardware#
Na prática diária com servidores físicos, alguns comportamentos do ambiente merecem atenção.
Arquivo /dev/ipmi0 inexistente#
Se o comando ipmitool acusar Could not open device at /dev/ipmi0: No such file or directory:
- Verifique se os módulos do kernel foram carregados:
lsmod | grep ipmi- Caso não estejam ativos, carregue-os manualmente:
modprobe ipmi_si
modprobe ipmi_devintf
dmesg | grep -i ipmi- Lembre-se de que máquinas virtuais convencionais (KVM, Proxmox, VMware) não expõem a interface física de IPMI para o sistema convidado por padrão.
Ruído eletrônico e oscilação de sensores (flapping)#
Um sensor com defeito elétrico (como um tacômetro de ventoinha com mau contato) pode alternar de status centenas de vezes por minuto. Isso gera uma enxurrada de logs (log flooding) que sobrecarrega o motor de análise.
Para conter esse ruído sem perder alertas legítimos, crie uma regra de frequência no Wazuh para agregar os eventos:
<rule id="110011" level="10" frequency="20" timeframe="60">
<if_matched_sid>110000</if_matched_sid>
<same_field>ipmi_sensor</same_field>
<description>Sensor de hardware oscilando repetidamente em curto intervalo.</description>
</rule>6. Resposta ativa: desligamento de emergência por superaquecimento#
O módulo de Resposta Ativa (Active Response) do Wazuh permite executar ações automáticas caso um limite de temperatura extrema persista, prevenindo danos permanentes aos componentes físicos.
Configurando o comando no Wazuh manager#
No /var/ossec/etc/ossec.conf:
<ossec_config>
<command>
<name>emergency_halt</name>
<executable>emergency_shutdown.sh</executable>
<timeout>disabled</timeout>
</command>
<active-response>
<command>emergency_halt</command>
<location>local</location>
<rules_id>110002</rules_id>
</active-response>
</ossec_config>Criando o script de mitigação no servidor#
No agente, crie o arquivo em /var/ossec/active-response/bin/emergency_shutdown.sh:
#!/bin/bash
# Desligamento de seguranca acionado pelo Wazuh em caso de calor critico
LOG_FILE="/var/ossec/logs/active-responses.log"
NOW=$(date "+%Y-%m-%d %H:%M:%S")
echo "${NOW} [Active Response] Temperatura critica detectada. Sincronizando discos e desligando." >> ${LOG_FILE}
# Sincroniza dados em memoria com o disco antes do desligamento
sync
# Agenda o desligamento imediato
/sbin/shutdown -h now "Wazuh Active Response: Limite termico ultrapassado no hardware."
exit 0Ajuste as permissões para que apenas o agente consiga executá-lo:
chown root:wazuh /var/ossec/active-response/bin/emergency_shutdown.sh
chmod 750 /var/ossec/active-response/bin/emergency_shutdown.shBoas práticas para manter a telemetria física estável#
Integrar eventos de hardware ao Wazuh transforma falhas físicas silenciosas em alertas visíveis e acionáveis antes que causem indisponibilidade grave.
Para manter o monitoramento confiável:
- Separe o tráfego de gerência: sempre que possível, utilize uma VLAN isolada para a comunicação com as portas de rede dos BMCs (iDRAC, iLO ou Supermicro), evitando que acessos externos alcancem os controladores.
- Monitore a saúde do relógio interno: certifique-se de que o relógio do BMC esteja sincronizado via NTP com a mesma fonte de tempo do sistema operacional para facilitar a correlação de timestamps durante investigações.
- Cruze falhas de hardware com erros de aplicação: eventos como quedas repentinas de bancos de dados ou reinicializações inesperadas de serviços muitas vezes têm sua causa raiz explicada por micro-interrupções de energia ou picos de temperatura registrados momentos antes no log do IPMI.
Este artigo foi útil?
Deixe uma reação rápida para apoiar o conteúdo:
Veja também
Este post está licenciado sob CC BY-NC.
Comentários
Participe da discussão abaixo.
0 comentários