Detecção de Intrusões e Threat Hunting no Linux: Guia Prático com Wazuh, Auditd e Osquery

Introdução

Se você administra servidores Linux em 2026, provavelmente já percebeu que o cenário de ameaças ficou absurdamente mais sofisticado nos últimos anos. Com a adoção massiva de nuvem, contêineres e microsserviços, o Linux se tornou o alvo favorito de grupos APT, operadores de ransomware e todo tipo de ator malicioso explorando vulnerabilidades em cadeias de suprimentos. Pra se ter uma ideia, mais de 70% dos workloads em nuvem rodam alguma variante de Linux — então detecção de intrusões e caça proativa a ameaças não é mais luxo, é sobrevivência.

A mudança de postura reativa (reagir só depois que o estrago aparece) para uma abordagem proativa de threat hunting representa algo fundamental. A premissa aqui é simples: assumir que adversários já podem estar dentro do seu ambiente, e usar hipóteses, inteligência de ameaças e telemetria rica para encontrar indicadores de comprometimento (IoCs) e indicadores de ataque (IoAs) antes que o dano se concretize.

Neste guia, vamos explorar três ferramentas que, juntas, formam um ecossistema bem robusto de detecção e resposta: o Auditd, para auditoria profunda de eventos do kernel; o Osquery, que transforma o SO num banco de dados consultável via SQL (sim, é tão legal quanto parece); e o Wazuh, uma plataforma SIEM/XDR open source que integra, correlaciona e automatiza a resposta a ameaças.

Arquitetura de Defesa em Profundidade

O conceito de defesa em profundidade vem lá da estratégia militar, mas se aplica perfeitamente à segurança de sistemas Linux. A ideia é simples: não depender de uma única camada de proteção. Distribuir controles em múltiplas camadas faz com que a falha de um componente não comprometa tudo.

No nosso contexto, cada ferramenta opera numa camada diferente:

• Auditd (Camada do Kernel): Opera no nível mais baixo, interceptando chamadas de sistema diretamente no kernel. Fornece telemetria sobre acessos a arquivos, execução de processos, alterações de privilégios e conexões de rede. É a fonte de dados mais granular — e a mais difícil de evadir.
• Osquery (Camada do Endpoint): Oferece uma visão estruturada do estado atual do sistema, permitindo consultas SQL sobre processos, portas abertas, módulos do kernel, tarefas agendadas e configurações. Perfeito para threat hunting ad-hoc e verificações de conformidade.
• Wazuh (Camada de Correlação e Resposta): Agrega dados das duas fontes anteriores, aplica regras de detecção, correlaciona eventos entre múltiplos hosts e executa respostas automatizadas. É o cérebro central que transforma dados brutos em inteligência acionável.

Essa arquitetura em camadas garante que, mesmo que um atacante sofisticado consiga evadir uma camada, as demais aumentam muito a probabilidade de você pegar a atividade maliciosa.

Auditd: O Pilar da Auditoria do Kernel Linux

Como o Auditd Funciona

O framework de auditoria do Linux é composto por vários componentes trabalhando juntos. No centro temos o audit subsystem no kernel, que intercepta chamadas de sistema com base em regras definidas pelo administrador. O daemon auditd escreve os registros em disco, enquanto utilitários como auditctl, ausearch e aureport permitem gerenciar regras e consultar logs.

O fluxo funciona assim: um processo faz uma chamada de sistema, o kernel verifica se alguma regra de auditoria corresponde, e se positivo, gera um registro enviado ao daemon via socket netlink. O daemon grava tudo em /var/log/audit/audit.log.

Instalação e Configuração Inicial

Na maioria das distros modernas, o auditd já vem instalado. Se não estiver, a instalação é bem direta:

# Ubuntu/Debian
sudo apt update && sudo apt install -y auditd audispd-plugins

# RHEL/CentOS/AlmaLinux
sudo dnf install -y audit audit-libs

# Habilitar e iniciar o serviço
sudo systemctl enable --now auditd

# Verificar o status
sudo systemctl status auditd

A configuração principal fica em /etc/audit/auditd.conf. Aqui estão os parâmetros mais importantes:

# /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log
log_format = ENRICHED
log_group = adm
priority_boost = 4
flush = INCREMENTAL_ASYNC
freq = 50
num_logs = 10
max_log_file = 50
max_log_file_action = ROTATE
space_left = 150
space_left_action = SYSLOG
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
name_format = HOSTNAME

Escrevendo Regras de Auditoria Eficazes

As regras de auditoria ficam em /etc/audit/rules.d/audit.rules. Existem três tipos: regras de controle, watches (sistema de arquivos) e regras de syscalls.

Aqui vai um conjunto abrangente de regras voltadas para detecção de segurança, já mapeadas ao framework MITRE ATT&CK. Honestamente, esse é o tipo de configuração que faz diferença real no dia a dia:

# /etc/audit/rules.d/security.rules

# Limpar regras existentes e definir buffer
-D
-b 8192
--backlog_wait_time 60000

# ============================================
# Monitoramento de Arquivos de Credenciais
# MITRE ATT&CK: T1003 - OS Credential Dumping
# ============================================
-w /etc/shadow -p rwa -k credential_access
-w /etc/passwd -p rwa -k credential_access
-w /etc/gshadow -p rwa -k credential_access
-w /etc/security/opasswd -p rwa -k credential_access

# ============================================
# Detecção de Execução de Comandos
# MITRE ATT&CK: T1059 - Command and Scripting Interpreter
# ============================================
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_command_execution
-a always,exit -F arch=b32 -S execve -F euid=0 -k root_command_execution

# Monitorar interpretadores de script
-w /usr/bin/python3 -p x -k script_execution
-w /usr/bin/perl -p x -k script_execution
-w /usr/bin/ruby -p x -k script_execution
-w /usr/bin/bash -p x -k shell_execution

# ============================================
# Tarefas Agendadas
# MITRE ATT&CK: T1053 - Scheduled Task/Job
# ============================================
-w /etc/crontab -p wa -k cron_modification
-w /etc/cron.d/ -p wa -k cron_modification
-w /etc/cron.daily/ -p wa -k cron_modification
-w /etc/cron.hourly/ -p wa -k cron_modification
-w /etc/cron.weekly/ -p wa -k cron_modification
-w /etc/cron.monthly/ -p wa -k cron_modification
-w /var/spool/cron/ -p wa -k cron_modification
-w /etc/systemd/system/ -p wa -k systemd_modification
-w /usr/lib/systemd/system/ -p wa -k systemd_modification

# ============================================
# Escalação de Privilégios
# MITRE ATT&CK: T1548 - Abuse Elevation Control Mechanism
# ============================================
-a always,exit -F arch=b64 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation
-a always,exit -F arch=b32 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation
-w /usr/bin/sudo -p x -k sudo_usage
-w /usr/bin/su -p x -k su_usage
-w /etc/sudoers -p rwa -k sudoers_modification
-w /etc/sudoers.d/ -p rwa -k sudoers_modification

# ============================================
# Conexões de Rede
# MITRE ATT&CK: T1071 - Application Layer Protocol
# ============================================
-a always,exit -F arch=b64 -S connect -F a2=16 -k network_connection_ipv4
-a always,exit -F arch=b64 -S connect -F a2=28 -k network_connection_ipv6

# ============================================
# Carregamento de Módulos do Kernel
# MITRE ATT&CK: T1547.006 - Kernel Modules and Extensions
# ============================================
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_module_load
-a always,exit -F arch=b64 -S delete_module -k kernel_module_unload
-w /sbin/insmod -p x -k kernel_module_tools
-w /sbin/modprobe -p x -k kernel_module_tools
-w /sbin/rmmod -p x -k kernel_module_tools

# ============================================
# Acesso a Chaves SSH
# MITRE ATT&CK: T1098.004 - SSH Authorized Keys
# ============================================
-w /root/.ssh/ -p rwa -k ssh_key_access
-w /home/ -p rwa -k ssh_key_access

# Tornar regras imutáveis (requer reboot para alterar)
-e 2

Para carregar as regras sem reiniciar:

# Carregar novas regras
sudo augenrules --load

# Verificar regras ativas
sudo auditctl -l

# Consultar eventos específicos
sudo ausearch -k credential_access --start today

# Gerar relatório resumido
sudo aureport --summary

Otimização de Desempenho e Gerenciamento de Logs

O auditd pode gerar um volume considerável de dados. Para não derrubar o desempenho em produção, algumas dicas:

• Ajuste o parâmetro -b (backlog buffer) ao volume de eventos do sistema. Valores entre 8192 e 32768 costumam funcionar bem para servidores de alta carga.
• Evite regras muito amplas que monitorem syscalls frequentes como read e write sem filtros específicos — isso gera barulho demais.
• Use o modo INCREMENTAL_ASYNC para flush, que reduz bastante o impacto de I/O.
• Configure a rotação de logs adequadamente para não comer todo o espaço em disco.

Osquery: Consultas SQL para Visibilidade do Endpoint

Arquitetura e Funcionamento

O Osquery foi originalmente criado pelo Facebook (Meta) e hoje é mantido pela Linux Foundation. O conceito é brilhante: ele expõe o sistema operacional como um banco de dados relacional. Cada aspecto do sistema — processos, conexões de rede, usuários, pacotes, configurações do kernel — vira uma tabela SQL consultável com sintaxe padrão.

A arquitetura tem dois componentes principais: o osqueryi, um shell interativo ótimo para threat hunting manual, e o osqueryd, um daemon que roda consultas agendadas, registra mudanças de estado e reporta resultados para sistemas de coleta.

Instalação nas Principais Distribuições

# Ubuntu/Debian
export OSQUERY_KEY=1484120AC4E9F8A1A577AEEE97A80C63C9D8B80B
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys $OSQUERY_KEY
sudo add-apt-repository 'deb [arch=amd64] https://pkg.osquery.io/deb deb main'
sudo apt update && sudo apt install -y osquery

# RHEL/CentOS/AlmaLinux
curl -L https://pkg.osquery.io/rpm/GPG | sudo tee /etc/pki/rpm-gpg/RPM-GPG-KEY-osquery
sudo dnf config-manager --add-repo https://pkg.osquery.io/rpm/osquery-s3-rpm.repo
sudo dnf install -y osquery

# Habilitar e iniciar o daemon
sudo systemctl enable --now osqueryd

Tabelas Essenciais para Segurança

O Osquery disponibiliza centenas de tabelas. Pra quem trabalha com segurança, estas são as que mais importam:

• processes — Todos os processos em execução com PID, caminho do binário, argumentos, usuário e uso de recursos.
• listening_ports — Portas TCP/UDP em escuta, vinculadas ao processo correspondente.
• users e logged_in_users — Contas de usuário e sessões ativas.
• file — Metadados de arquivos, incluindo permissões, proprietário e timestamps.
• process_open_sockets — Sockets de rede abertos por cada processo.
• crontab — Tarefas agendadas no cron.
• suid_bin — Binários com bit SUID (sempre vale a pena ficar de olho).
• authorized_keys — Chaves SSH autorizadas por usuário.
• kernel_modules — Módulos do kernel carregados.
• iptables — Regras de firewall ativas.

Consultas Práticas para Threat Hunting

Detectando portas de escuta incomuns:

-- Portas em escuta não associadas a serviços conhecidos
SELECT
    lp.port,
    lp.protocol,
    lp.address,
    p.name AS process_name,
    p.path AS process_path,
    p.cmdline,
    p.uid,
    u.username
FROM listening_ports lp
JOIN processes p ON lp.pid = p.pid
LEFT JOIN users u ON p.uid = u.uid
WHERE lp.port NOT IN (22, 80, 443, 3306, 5432, 6379, 8080)
    AND lp.address != '127.0.0.1'
ORDER BY lp.port;

Processos executando a partir de diretórios temporários (um indicador clássico de malware):

-- Processos suspeitos em diretórios temporários
SELECT
    p.pid,
    p.name,
    p.path,
    p.cmdline,
    p.uid,
    u.username,
    p.start_time,
    h.sha256
FROM processes p
LEFT JOIN users u ON p.uid = u.uid
LEFT JOIN hash h ON p.path = h.path
WHERE p.path LIKE '/tmp/%'
    OR p.path LIKE '/var/tmp/%'
    OR p.path LIKE '/dev/shm/%'
    OR p.path LIKE '/run/user/%';

Identificando binários SUID não autorizados:

-- Binários SUID que podem ser explorados para escalação de privilégios
SELECT
    sb.path,
    sb.username,
    sb.groupname,
    sb.permissions,
    f.mtime,
    h.sha256
FROM suid_bin sb
LEFT JOIN file f ON sb.path = f.path
LEFT JOIN hash h ON sb.path = h.path
WHERE sb.path NOT IN (
    '/usr/bin/sudo',
    '/usr/bin/passwd',
    '/usr/bin/chsh',
    '/usr/bin/chfn',
    '/usr/bin/newgrp',
    '/usr/bin/gpasswd',
    '/usr/bin/mount',
    '/usr/bin/umount',
    '/usr/bin/su',
    '/usr/bin/pkexec',
    '/usr/lib/openssh/ssh-keysign',
    '/usr/lib/dbus-1.0/dbus-daemon-launch-helper'
)
ORDER BY f.mtime DESC;

Detectando possíveis reverse shells:

-- Processos com conexões de rede suspeitas (possíveis reverse shells)
SELECT
    p.pid,
    p.name,
    p.path,
    p.cmdline,
    p.parent,
    pos.remote_address,
    pos.remote_port,
    pos.local_port
FROM process_open_sockets pos
JOIN processes p ON pos.pid = p.pid
WHERE pos.remote_address != ''
    AND pos.remote_address != '127.0.0.1'
    AND pos.remote_address != '::1'
    AND pos.remote_address != '0.0.0.0'
    AND (
        p.name IN ('bash', 'sh', 'dash', 'zsh', 'nc', 'ncat', 'socat', 'perl', 'python', 'python3', 'ruby', 'php')
        OR p.cmdline LIKE '%/dev/tcp/%'
        OR p.cmdline LIKE '%socket%'
        OR p.cmdline LIKE '%-e /bin/%'
    );

Verificando chaves SSH não autorizadas:

-- Chaves SSH autorizadas para todos os usuários
SELECT
    ak.uid,
    u.username,
    ak.algorithm,
    ak.key,
    ak.comment,
    ak.key_file
FROM authorized_keys ak
JOIN users u ON ak.uid = u.uid
ORDER BY u.username;

Configuração de Packs para Monitoramento Contínuo

O arquivo de configuração do osquery permite definir consultas que rodam periodicamente. Essa é a parte que transforma o osquery de uma ferramenta de investigação pontual num sistema de monitoramento contínuo:

{
    "options": {
        "config_plugin": "filesystem",
        "logger_plugin": "filesystem",
        "logger_path": "/var/log/osquery",
        "disable_logging": "false",
        "schedule_splay_percent": "10",
        "pidfile": "/var/run/osquery/osqueryd.pidfile",
        "events_expiry": "3600",
        "database_path": "/var/osquery/osquery.db",
        "verbose": "false",
        "worker_threads": "2",
        "enable_monitor": "true",
        "disable_events": "false",
        "disable_audit": "false",
        "audit_allow_config": "true",
        "audit_allow_sockets": "true",
        "host_identifier": "hostname"
    },
    "schedule": {
        "process_monitor": {
            "query": "SELECT pid, name, path, cmdline, uid, gid, start_time FROM processes WHERE path LIKE '/tmp/%' OR path LIKE '/var/tmp/%' OR path LIKE '/dev/shm/%';",
            "interval": 60,
            "description": "Detectar processos em diretórios temporários"
        },
        "listening_ports_monitor": {
            "query": "SELECT lp.port, lp.protocol, lp.address, p.name, p.path, p.cmdline FROM listening_ports lp JOIN processes p ON lp.pid = p.pid WHERE lp.address != '127.0.0.1';",
            "interval": 120,
            "description": "Monitorar portas de escuta expostas"
        },
        "suid_binaries": {
            "query": "SELECT path, username, permissions FROM suid_bin;",
            "interval": 3600,
            "description": "Inventário de binários SUID"
        },
        "crontab_monitor": {
            "query": "SELECT command, path, minute, hour, day_of_month, month, day_of_week FROM crontab;",
            "interval": 300,
            "description": "Monitorar tarefas agendadas"
        },
        "authorized_keys_monitor": {
            "query": "SELECT ak.uid, u.username, ak.algorithm, ak.comment, ak.key_file FROM authorized_keys ak JOIN users u ON ak.uid = u.uid;",
            "interval": 600,
            "description": "Monitorar chaves SSH autorizadas"
        },
        "kernel_modules_monitor": {
            "query": "SELECT name, size, used_by, status FROM kernel_modules WHERE status = 'Live';",
            "interval": 1800,
            "description": "Monitorar módulos do kernel carregados"
        }
    },
    "packs": {
        "threat_hunting": "/etc/osquery/packs/threat_hunting.conf"
    }
}

Wazuh: Plataforma SIEM e XDR Open Source

Visão Geral da Arquitetura

O Wazuh é uma daquelas ferramentas open source que realmente impressionam. É uma plataforma completa que unifica detecção de ameaças, resposta a incidentes, monitoramento de integridade e conformidade regulatória. A arquitetura tem três componentes principais:

• Wazuh Server: O componente central que recebe dados dos agentes, aplica regras de detecção, correlaciona eventos e gera alertas. Inclui motor de análise, módulo de vulnerabilidades e o framework de resposta ativa.
• Wazuh Agent: Instalado em cada endpoint monitorado, coleta logs, dados de auditoria, informações de integridade de arquivos e estado do sistema. Se comunica com o servidor via canal criptografado.
• Wazuh Dashboard: Interface web baseada em OpenSearch Dashboards para visualizar alertas, explorar dados, criar painéis e gerenciar a plataforma.

Integração com Auditd

O Wazuh consome nativamente os logs gerados pelo auditd. O agente monitora /var/log/audit/audit.log e envia os eventos ao servidor. A configuração no agente é feita em /var/ossec/etc/ossec.conf:

    
        audit
        /var/log/audit/audit.log
    

O Wazuh já vem com decoders nativos para o formato do auditd, extraindo automaticamente campos como uid, auid, syscall, key e exe. Isso permite criar regras de detecção que referenciam diretamente os campos dos eventos — bem prático.

Integração com Osquery

Existe um módulo nativo de integração com o osquery no Wazuh. Para habilitar, configure o módulo wodle no agente:

    
        no
        yes
        /var/log/osquery/osqueryd.results.log
        /etc/osquery/osquery.conf
        yes
    

Com essa integração, os resultados das consultas agendadas do osquery são automaticamente ingeridos pelo Wazuh. Isso abre a porta para criar regras de detecção baseadas nos dados estruturados do osquery.

File Integrity Monitoring (FIM) com Suporte a eBPF

O módulo FIM do Wazuh monitora alterações em arquivos e diretórios críticos. As versões mais recentes trouxeram suporte a eBPF (extended Berkeley Packet Filter), permitindo monitoramento em tempo real com impacto mínimo no desempenho — uma evolução significativa em relação ao mecanismo anterior baseado em inotify.

    
        no
        600
        yes

        
        /etc
        /usr/bin
        /usr/sbin
        /boot

        
        /root/.ssh
        /etc/cron.d
        /etc/systemd/system

        
        /etc/mtab
        /etc/resolv.conf
        ^/etc/.*~$

        
        
            yes
            100000
        
    

Criando Regras de Detecção Personalizadas

O Wazuh usa regras em formato XML para detecção. As regras customizadas vão no arquivo /var/ossec/etc/rules/local_rules.xml no servidor:

    
    
        80700
        credential_access
        Acesso detectado a arquivo de credenciais do sistema ($(audit.file.name))
        
            T1003
        
        credential_access,audit,
    

    
    
        100100
        /etc/shadow
        NOT (/usr/bin/passwd|/usr/sbin/useradd|/usr/sbin/usermod|/usr/sbin/groupadd|/usr/bin/chage)
        ALERTA CRÍTICO: Acesso não autorizado ao /etc/shadow por $(audit.exe)
        
            T1003.008
        
        credential_access,high_severity,
    

    
    
        80700
        cron_modification
        Modificação detectada em tarefa agendada: $(audit.file.name)
        
            T1053.003
        
        persistence,scheduled_task,
    

    
    
        80700
        kernel_module_load
        Módulo do kernel carregado: possível rootkit ou persistência
        
            T1547.006
        
        persistence,rootkit,
    

    
    
        24010
        process_monitor
        Osquery: Processo suspeito detectado em diretório temporário
        
            T1059
        
        osquery,execution,
    

Resposta Ativa para Contenção Automatizada

Essa aqui é uma das partes mais legais do Wazuh. O módulo de Active Response permite executar ações automatizadas quando regras específicas disparam — bloquear IPs, desabilitar contas, isolar endpoints comprometidos. Tudo automático.

    
    
        firewall-drop
        firewall-drop
        yes
    

    
    
        disable-account
        disable-account
        no
    

    
    
        firewall-drop
        local
        100101
        3600
    

    
    
        disable-account
        local
        100101
        0
    

E aqui vai um script personalizado de resposta ativa para desabilitar uma conta comprometida:

#!/bin/bash
# /var/ossec/active-response/bin/disable-account
# Script de resposta ativa para desabilitar conta comprometida

LOCAL=$(dirname $0)
LOG_FILE="/var/ossec/logs/active-responses.log"

read INPUT_JSON
ALERT_USER=$(echo $INPUT_JSON | jq -r '.parameters.alert.data.audit.uid')
USERNAME=$(getent passwd "$ALERT_USER" | cut -d: -f1)

# Não desabilitar root ou contas de sistema
if [ "$ALERT_USER" -lt 1000 ] || [ -z "$USERNAME" ]; then
    echo "$(date) - Ignorando desabilitação para UID $ALERT_USER" >> $LOG_FILE
    exit 0
fi

# Desabilitar a conta
/usr/bin/passwd -l "$USERNAME" 2>> $LOG_FILE
/usr/bin/pkill -KILL -u "$USERNAME" 2>> $LOG_FILE

echo "$(date) - Conta $USERNAME (UID: $ALERT_USER) desabilitada e sessões encerradas" >> $LOG_FILE
exit 0

Módulo de Detecção de Vulnerabilidades

O Wazuh também inclui um módulo de detecção de vulnerabilidades que compara o inventário de pacotes instalados com bases de CVEs conhecidas. Na minha experiência, essa funcionalidade sozinha já justifica a adoção da ferramenta em muitos ambientes:

    
        yes
        5m
        6h
        yes

        
            yes
            jammy
            noble
            1h
        

        
            yes
            9
            1h
        

        
            yes
            1h
        
    

Cenário Prático: Detectando um Ataque de Credential Access

Bom, chega de teoria. Vamos simular um cenário completo de detecção de um atacante que conseguiu acesso inicial a um servidor Linux e está tentando extrair credenciais. Esse walkthrough mostra como as três ferramentas trabalham juntas na prática.

Passo 1: Configurar as Regras de Auditd

Primeiro, vamos garantir que as regras de auditoria para monitoramento de credenciais estejam ativas:

# Regras específicas para credential access
sudo auditctl -w /etc/shadow -p rwa -k credential_access
sudo auditctl -w /etc/passwd -p rwa -k credential_access
sudo auditctl -w /etc/gshadow -p rwa -k credential_access
sudo auditctl -w /etc/security/opasswd -p rwa -k credential_access

# Monitorar ferramentas comuns de dump de credenciais
sudo auditctl -w /usr/bin/unshadow -p x -k credential_tools
sudo auditctl -w /usr/sbin/john -p x -k credential_tools

# Verificar que as regras estão ativas
sudo auditctl -l | grep credential

Passo 2: Consultas Osquery para Detecção

Agora configuramos consultas agendadas específicas para detectar atividades de credential access:

{
    "schedule": {
        "credential_file_access": {
            "query": "SELECT f.path, f.atime, f.mtime, f.uid, u.username FROM file f JOIN users u ON f.uid = u.uid WHERE f.path IN ('/etc/shadow', '/etc/gshadow', '/etc/security/opasswd') AND f.atime > (strftime('%s','now') - 300);",
            "interval": 60,
            "description": "Detectar acesso recente a arquivos de credenciais",
            "snapshot": true
        },
        "suspicious_copy_commands": {
            "query": "SELECT pid, name, cmdline, uid, parent FROM processes WHERE (cmdline LIKE '%/etc/shadow%' OR cmdline LIKE '%/etc/passwd%') AND name IN ('cp', 'cat', 'scp', 'rsync', 'curl', 'wget', 'nc');",
            "interval": 30,
            "description": "Detectar cópia de arquivos de credenciais"
        },
        "credential_tools_running": {
            "query": "SELECT pid, name, path, cmdline, uid FROM processes WHERE name IN ('john', 'hashcat', 'hydra', 'unshadow', 'mimipenguin') OR cmdline LIKE '%hashcat%' OR cmdline LIKE '%john%';",
            "interval": 30,
            "description": "Detectar ferramentas de cracking de credenciais"
        }
    }
}

Passo 3: Regras Wazuh para Alertas

As regras do Wazuh correlacionam os eventos do auditd e do osquery para gerar alertas de alta prioridade:

    
    
        80700
        credential_access
        Acesso a arquivo de credenciais detectado: $(audit.file.name) por $(audit.exe)
        
            T1003.008
        
        credential_access,
    

    
    
        100300
        /etc/shadow
        NOT (/usr/bin/passwd|/usr/sbin/useradd|/usr/sbin/usermod|/usr/sbin/chpasswd|/usr/bin/chage|/usr/sbin/pam_tally2)
        CRÍTICO: Acesso não autorizado ao /etc/shadow detectado - possível dump de credenciais
        
            T1003.008
        
        credential_access,high_priority,
    

    
    
        80700
        credential_access
        (/usr/bin/cp|/usr/bin/scp|/usr/bin/rsync|/usr/bin/curl|/usr/bin/wget|/usr/bin/nc)
        ALERTA MÁXIMO: Cópia/exfiltração de arquivo de credenciais detectada via $(audit.exe)
        
            T1003.008
            T1048
        
        credential_access,exfiltration,critical,
    

    
    
        24010
        credential_tools_running
        ALERTA MÁXIMO: Ferramenta de cracking de credenciais em execução no endpoint
        
            T1110
        
        credential_access,brute_force,critical,
    

Passo 4: Resposta Ativa Automatizada

Quando as regras de nível 14 ou 15 disparam, o Wazuh entra em ação automaticamente:

    disable-account
    local
    100301,100302,100303
    0



    firewall-drop
    local
    100302
    7200

Passo 5: Verificação e Investigação

Após a detecção, a equipe de segurança investiga o incidente usando todas as ferramentas disponíveis:

# Consultar eventos de auditoria relacionados
sudo ausearch -k credential_access --start today -i

# Verificar sessões ativas do atacante
sudo ausearch -k credential_access --start today -i | grep "auid="

# Usar osquery para investigação forense
osqueryi "SELECT pid, name, path, cmdline, uid, parent, start_time FROM processes WHERE start_time > (strftime('%s','now') - 3600) ORDER BY start_time DESC;"

# Verificar conexões de rede do atacante
osqueryi "SELECT pos.pid, p.name, p.cmdline, pos.remote_address, pos.remote_port FROM process_open_sockets pos JOIN processes p ON pos.pid = p.pid WHERE pos.remote_address != '' AND pos.remote_address != '127.0.0.1';"

# Verificar alertas no Wazuh via API
curl -k -X GET "https://localhost:55000/security/events?q=rule.id=100301" \
    -H "Authorization: Bearer $TOKEN"

Integrando com Pipelines DevSecOps

Enviando Telemetria para Logging Centralizado

Em ambientes modernos de DevSecOps, a telemetria de segurança precisa se integrar ao pipeline de observabilidade. O Wazuh suporta nativamente o envio de alertas para múltiplos destinos:

    
        custom-elasticsearch
        https://opensearch.internal:9200/wazuh-alerts/_doc
        json
        7
    

    
    
        slack
        https://hooks.slack.com/services/T00/B00/XXXX
        12
        json
    

    
    
        pagerduty
        API_KEY_AQUI
        14
        json
    

Para integrar com o Filebeat e enviar logs para um pipeline centralizado:

# /etc/filebeat/filebeat.yml
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/audit/audit.log
    tags: ["auditd", "linux_security"]
    fields:
      source: auditd
    processors:
      - decode_json_fields:
          fields: ["message"]

  - type: log
    enabled: true
    paths:
      - /var/log/osquery/osqueryd.results.log
    tags: ["osquery", "linux_security"]
    fields:
      source: osquery
    json.keys_under_root: true

output.elasticsearch:
  hosts: ["https://opensearch.internal:9200"]
  index: "security-telemetry-%{+yyyy.MM.dd}"
  ssl.certificate_authorities: ["/etc/filebeat/certs/ca.pem"]

Automatizando Resposta a Incidentes

Além das respostas ativas nativas, dá pra integrar com plataformas SOAR para fluxos mais complexos. Aqui vai um exemplo de webhook que dispara um playbook de resposta:

#!/usr/bin/env python3
# /var/ossec/integrations/custom-soar-integration.py
"""
Integração do Wazuh com plataforma SOAR para resposta automatizada.
"""

import json
import sys
import requests
from datetime import datetime

SOAR_API_URL = "https://soar.internal/api/v1/incidents"
SOAR_API_KEY = "sua_chave_api_aqui"

def create_incident(alert_data):
    """Cria um incidente na plataforma SOAR baseado no alerta Wazuh."""

    incident = {
        "title": f"[Wazuh] {alert_data.get('rule', {}).get('description', 'Alerta de Segurança')}",
        "severity": map_severity(alert_data.get('rule', {}).get('level', 3)),
        "source": "wazuh",
        "timestamp": alert_data.get('timestamp', datetime.utcnow().isoformat()),
        "agent": {
            "id": alert_data.get('agent', {}).get('id'),
            "name": alert_data.get('agent', {}).get('name'),
            "ip": alert_data.get('agent', {}).get('ip')
        },
        "mitre": alert_data.get('rule', {}).get('mitre', {}),
        "raw_alert": alert_data
    }

    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {SOAR_API_KEY}"
    }

    response = requests.post(SOAR_API_URL, json=incident, headers=headers, verify=True)
    return response.status_code

def map_severity(level):
    if level >= 14:
        return "critical"
    elif level >= 10:
        return "high"
    elif level >= 7:
        return "medium"
    return "low"

if __name__ == "__main__":
    alert_file = sys.argv[1]
    with open(alert_file, 'r') as f:
        alert_data = json.load(f)
    create_incident(alert_data)

Monitoramento de Ambientes de Contêineres

Se você trabalha com Docker e Kubernetes (e quem não trabalha hoje em dia?), a detecção de intrusões precisa de monitoramento adicional. O Wazuh oferece suporte nativo:

    
        no
        10m
        5
        yes
    

    
    
        json
        /var/lib/docker/containers/*/*.log
    

E consultas osquery para monitoramento de contêineres:

-- Contêineres Docker em execução
SELECT
    id,
    name,
    image,
    state,
    status,
    pid,
    started_at,
    security_options
FROM docker_containers
WHERE state = 'running';

-- Contêineres com privilégios elevados (risco de segurança)
SELECT
    dc.id,
    dc.name,
    dc.image,
    dc.privileged,
    dc.security_options
FROM docker_containers dc
WHERE dc.privileged = 1
    OR dc.security_options NOT LIKE '%no-new-privileges%';

Boas Práticas e Recomendações

Otimização de Desempenho

Implementar um sistema abrangente de detecção de intrusões pode sim impactar o desempenho dos servidores se a configuração não for bem pensada. Vão aqui algumas recomendações que aprendi na prática:

• Auditd: Evite monitorar syscalls de alta frequência como read, write e open sem filtros bem restritivos. Use filtros por auid (audit UID) para ignorar processos de sistema e focar em atividades de usuários reais. E ajuste o backlog buffer conforme a carga.
• Osquery: Defina intervalos adequados — consultas sobre processos e conexões podem rodar a cada 30-60 segundos, enquanto inventários de pacotes e verificações SUID podem ficar em 30-60 minutos. Use o watchdog para limitar CPU e memória.
• Wazuh: Configure limites de EPS (eventos por segundo) no servidor para evitar sobrecarga em picos de atividade. Use frequency nas regras para evitar flood de alertas repetitivos.

# Configuração de watchdog do Osquery para limitar recursos
{
    "options": {
        "watchdog_memory_limit": "200",
        "watchdog_utilization_limit": "10",
        "watchdog_delay": "60",
        "schedule_default_interval": "60"
    }
}

Políticas de Retenção de Logs

A retenção adequada de logs é crucial tanto para investigação forense quanto para conformidade. Não adianta ter a melhor detecção se os logs são apagados antes que você precise deles.

• Logs de auditoria (auditd): Mínimo de 90 dias locais, com arquivamento de longo prazo (1-7 anos) em armazenamento centralizado, conforme exigido pela regulamentação aplicável.
• Resultados do osquery: 30-90 dias, dependendo do volume e requisitos de compliance.
• Alertas do Wazuh: 90 dias a 1 ano no indexador, com arquivamento em armazenamento frio para retenção de longo prazo.

# Política de rotação de logs do auditd via logrotate
# /etc/logrotate.d/audit
/var/log/audit/audit.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 0600 root root
    postrotate
        /sbin/service auditd rotate >/dev/null 2>&1 || true
    endscript
}

# Script para arquivamento de longo prazo
#!/bin/bash
# /usr/local/bin/archive-audit-logs.sh
ARCHIVE_DIR="/mnt/archive/audit-logs/$(hostname)"
LOG_DIR="/var/log/audit"
DATE=$(date +%Y%m%d)

mkdir -p "$ARCHIVE_DIR"
find "$LOG_DIR" -name "audit.log.*" -mtime +30 \
    -exec gzip -9 {} \; \
    -exec mv {}.gz "$ARCHIVE_DIR/" \;

# Verificar integridade dos arquivos compactados
find "$ARCHIVE_DIR" -name "*.gz" -mtime -1 -exec gzip -t {} \;

Conformidade com Frameworks Regulatórios

A combinação Auditd + Osquery + Wazuh facilita bastante o atendimento a diversos frameworks de conformidade:

• PCI-DSS: Requisitos 10.1 a 10.7 (trilhas de auditoria), 11.4 (detecção de intrusões), 11.5 (monitoramento de integridade). O auditd cobre auditoria, o Wazuh FIM cobre integridade e as regras de detecção satisfazem o requisito de IDS.
• LGPD: Artigos 46 e 47 exigem medidas de segurança para proteger dados pessoais. Monitorar acesso a arquivos com dados pessoais via auditd e Wazuh FIM demonstra conformidade com essas exigências.
• CIS Benchmarks: O Wazuh inclui um módulo nativo de verificação de conformidade CIS, executando avaliações automatizadas de configuração.

    
        yes
        yes
        12h
        yes
        
            cis_ubuntu22-04.yml
            cis_rhel9.yml
        
    

Armadilhas Comuns e Como Evitá-las

Depois de implementar essa stack em vários ambientes, posso dizer que os erros mais comuns são:

1. Excesso de alertas (alert fatigue): Configurar regras com limiares muito baixos gera um volume ingerenciável de alertas. Comece com regras de alta fidelidade e expanda gradualmente. Use frequency e timeframe nas regras do Wazuh para suprimir repetições.
2. Falta de tuning contínuo: As regras de detecção precisam ser revisadas e ajustadas regularmente. Mantenha uma lista de exclusões documentada para falsos positivos conhecidos.
3. Não testar as regras: Simule cenários de ataque regularmente com ferramentas como o Atomic Red Team. Não adianta ter regras bonitas se elas não funcionam quando precisam.
4. Ignorar a segurança da própria infraestrutura de monitoramento: O servidor Wazuh, os logs e as configurações do osquery devem ser protegidos contra tampering. Use regras de auditoria para monitorar os próprios arquivos de configuração das ferramentas.
5. Não correlacionar eventos entre fontes: O verdadeiro valor dessa arquitetura está na correlação. Um evento isolado pode parecer inofensivo, mas quando combinado com outros de diferentes fontes, revela o padrão do ataque.

# Regras de auditd para proteger a infraestrutura de monitoramento
# Monitorar acesso às configurações do Wazuh
-w /var/ossec/etc/ossec.conf -p rwa -k wazuh_config_change
-w /var/ossec/etc/rules/ -p rwa -k wazuh_rules_change
-w /var/ossec/etc/decoders/ -p rwa -k wazuh_decoders_change

# Monitorar acesso às configurações do Osquery
-w /etc/osquery/osquery.conf -p rwa -k osquery_config_change
-w /etc/osquery/packs/ -p rwa -k osquery_packs_change

# Monitorar acesso às próprias regras de auditoria
-w /etc/audit/ -p rwa -k audit_config_change
-w /etc/audit/rules.d/ -p rwa -k audit_rules_change

Conclusão

A detecção de intrusões e a caça proativa a ameaças em ambientes Linux em 2026 exigem uma abordagem integrada e em camadas. Neste guia, vimos como a combinação de Auditd, Osquery e Wazuh cria um ecossistema de segurança robusto que vai desde a auditoria de syscalls no kernel até a correlação inteligente de eventos e a resposta automatizada.

O Auditd fornece a telemetria mais profunda e difícil de evadir, operando no nível do kernel. O Osquery complementa com uma visão estruturada e consultável do sistema, ideal pra investigações e verificações de conformidade. O Wazuh amarra tudo, agregando e correlacionando dados de ambas as fontes com inteligência de detecção e respostas automatizadas.

Pra fechar, os pontos-chave:

• Comece com regras de alta fidelidade e expanda gradualmente — evite alert fatigue desde o início.
• Mapeie suas regras ao framework MITRE ATT&CK para garantir cobertura das técnicas adversárias.
• Invista em tuning contínuo, revisando falsos positivos e adicionando regras conforme o cenário de ameaças evolui.
• Teste regularmente suas capacidades de detecção com simulações de ataque.
• Integre a telemetria nos pipelines de DevSecOps para uma postura de segurança verdadeiramente proativa.
• Proteja a própria infraestrutura de monitoramento contra tampering.

Como próximos passos, vale a pena implementar threat intelligence feeds no Wazuh para enriquecer alertas com contexto sobre IoCs conhecidos, adotar técnicas de machine learning para detecção de anomalias comportamentais, e criar playbooks de resposta documentados e testados para os cenários mais relevantes ao seu ambiente. A segurança é uma jornada contínua, e essas três ferramentas open source oferecem uma base sólida para enfrentar os desafios que continuam surgindo em ambientes Linux modernos.