Aula 27: OSSEC — HIDS para monitoramento de integridade, logs e resposta a incidentes

Em um ecossistema Linux onde servidores enfrentam ameaças constantes — de tentativas de intrusão a modificações não autorizadas em binários críticos —, monitorar apenas a superfície da rede já não é suficiente. É aqui que entra o OSSEC, um sistema de detecção de intrusão baseado em host (HIDS) que alia análise de logs, verificação de integridade de arquivos, detecção de rootkits, alertas em tempo real e resposta ativa a incidentes. Esta aula foi projetada para levar você, profissional de infraestrutura e segurança, a compreender profundamente como o OSSEC opera e como implementá-lo em ambientes reais, cobrindo desde a instalação minuciosa até a personalização avançada de regras e ações automáticas contra ameaças.

O OSSEC se diferencia de ferramentas puramente reativas porque atua como um vigilante incansável dentro do sistema: ele lê arquivos de log do kernel, do Apache, do SSH, do PostgreSQL e de dezenas de outros serviços, correlaciona eventos com regras pré-definidas, calcula hashes de arquivos sensíveis para detectar alterações e pode, inclusive, bloquear IPs suspeitos via iptables ou null route. Tudo isso de forma integrada. Em nossos projetos na JRT Technology Solutions, utilizamos diariamente o OSSEC como peça central da estratégia de hardening de servidores Linux, complementando firewalls e SELinux com uma camada de inteligência de eventos que opera 24 horas por dia.

Ao longo desta aula, você instalará o OSSEC manualmente — compilando a partir do código-fonte — tanto em distribuições da família Debian/Ubuntu quanto em sistemas RHEL/CentOS/Rocky Linux. Cada etapa será dissecada: desde a instalação de dependências até a configuração do arquivo ossec.conf com comentários detalhados. Você aprenderá a interpretar alertas, ajustar thresholds de severidade, configurar o módulo syscheck para monitorar a integridade do /etc/shadow, /usr/bin e outros diretórios críticos, e a ativar respostas automáticas que transformam o OSSEC de um mero detector em um executor de contramedidas.

Antes de começar, é fundamental que você já possua domínio dos conceitos vistos nas aulas anteriores: administração básica e avançada de Linux, gerenciamento de daemons com systemd, fundamentos de redes (TCP/IP, portas), shell scripting e, especialmente, a Aula 26, onde cobrimos análise de logs com ferramentas como journalctl e logwatch. Se você ainda não concluiu esses módulos, recomendo revisá-los — o OSSEC consolida e eleva tudo isso a um novo patamar. Também será necessário acesso root e, idealmente, uma máquina virtual ou container dedicado para testes, já que a resposta ativa pode alterar regras de firewall e rotas do sistema.

Ao final desta aula, você terá em mãos um HIDS funcional, entendendo cada arquivo de configuração, cada categoria de regra e cada mecanismo de alerta. Saberá testar o sistema com ataques simulados, interpretar os logs gerados e ajustar a sensibilidade do monitoramento para evitar falsos positivos — uma habilidade que diferencia o administrador mediano do especialista em segurança defensiva.

O que você vai aprender nesta aula

• Compreender a arquitetura modular do OSSEC: Manager, Agent, Syscheck, Rootcheck, Logcollector e Active Response
• Instalar e compilar o OSSEC do zero em Ubuntu 24.04 LTS e Rocky Linux 9, com todas as dependências resolvidas manualmente
• Configurar o arquivo ossec.conf com parâmetros detalhados de monitoramento de logs, integridade e alertas
• Habilitar e testar o módulo Syscheck para verificar alterações em arquivos sensíveis usando hashes SHA256
• Interpretar os alertas gerados no arquivo alerts.log e no ossec-logtest
• Configurar regras personalizadas de resposta ativa para bloquear IPs que tentam brute-force no SSH
• Solucionar os erros mais comuns durante a instalação e operação do OSSEC

Pré-requisitos e Ambiente

Para executar esta aula sem interrupções, você precisará de uma máquina Linux recém-instalada (ou container com privilégios adequados) com uma das seguintes distribuições: Ubuntu 24.04 LTS, Debian 12, CentOS Stream 9 ou Rocky Linux 9. O sistema deve ter no mínimo 1 GB de RAM livre e 2 GB de espaço em disco para compilação. Acesso root ou sudo pleno é obrigatório, pois alteraremos regras de firewall, criaremos usuários de sistema e compilaremos código C. O ambiente de rede deve permitir que a máquina acesse a internet para baixar o código-fonte e as dependências. Recomenda-se fortemente que você utilize uma VM isolada ou um snapshot que possa ser restaurado, pois os testes de resposta ativa podem modificar configurações de rede.

As ferramentas e bibliotecas que instalaremos incluem: build-essential, libssl-dev, libpcre2-dev, libsystemd-dev, libevent-dev, zlib1g-dev (no Debian/Ubuntu) e seus equivalentes no RHEL via dnf groupinstall. Você também deve ter o git instalado para clonar o repositório oficial. Se estiver utilizando um sistema com SELinux em modo enforcing (como Rocky Linux por padrão), abordaremos os ajustes de contexto necessários para que os binários do OSSEC operem corretamente. Verifique se o serviço sshd está ativo — ele será nosso principal alvo de testes de brute-force simulado.

Arquitetura do OSSEC — Como um HIDS pensa e age

Antes de mergulharmos nos comandos, é essencial compreender a anatomia do OSSEC. Diferentemente de um NIDS como o Snort — que monitora tráfego de rede —, um HIDS como o OSSEC reside no próprio host e analisa o que acontece dentro dele. Sua arquitetura é dividida em componentes que se comunicam via filas de mensagens internas, geralmente utilizando sockets Unix. O cérebro é o ossec-analysisd, que recebe eventos coletados por outros daemons e os cruza com uma base de regras XML. Cada regra possui um id, um level de severidade (0 a 15) e condições de correspondência baseadas em padrões nos logs ou em eventos do sistema.

O ossec-logcollector é responsável por ler arquivos de log em tempo real (ou via syslog) e encaminhar cada linha para análise. Ele suporta múltiplos formatos, incluindo syslog, Apache, Squid e JSON. O ossec-syscheckd monitora a integridade de arquivos e diretórios, calculando hashes (MD5, SHA1, SHA256) periodicamente e gerando alertas quando detecta alterações. O ossec-rootcheck realiza verificações de rootkits conhecidos, anomalias em permissões e processos ocultos. E o ossec-authd gerencia a autenticação de agentes em implantações distribuídas (Manager + Agents).

O componente que torna o OSSEC verdadeiramente proativo é o Active Response. Configurado adequadamente, ele executa scripts automaticamente quando determinadas regras disparam — por exemplo, adicionar um IP ao iptables após 8 tentativas SSH falhas em 60 segundos. Esses scripts residem em /var/ossec/active-response/bin/ e são invocados pelo ossec-execd com privilégios controlados. Em nossos projetos na JRT Technology Solutions, combinamos respostas ativas com notificações via SIEM para criar um ciclo completo de detecção, contenção e registro forense.

A tabela a seguir resume os principais daemons e seus papéis dentro do ecossistema OSSEC:

Compreender essa arquitetura permite solucionar problemas de forma cirúrgica: se um alerta não foi gerado, você sabe inspecionar primeiro se o log está sendo coletado (ossec-logcollector) e depois se a regra correspondente existe e está habilitada (ossec-analysisd). Essa metodologia de troubleshooting será aplicada na prática ainda nesta aula.

Instalação do OSSEC — Ubuntu 24.04 LTS (Passo a Passo Completo)

Iniciaremos com a instalação em Ubuntu 24.04 LTS. Optamos pela compilação a partir do código-fonte oficial em vez de pacotes pré-compilados, pois isso garante a versão mais recente do OSSEC, permite customizar módulos e gera binários otimizados para o kernel e bibliotecas específicas do sistema. O processo é meticuloso, mas cada etapa é reprodutível e didática.

1. Atualizar o sistema e instalar dependências de compilação: O OSSEC exige compilador C, headers do OpenSSL, PCRE2 para suporte a expressões regulares avançadas e outras bibliotecas. Execute os comandos abaixo na ordem exata.
2. Criar o usuário e grupo dedicados: Por segurança, o OSSEC não deve rodar como root. Criaremos o usuário ossec e o grupo correspondente antes da instalação.
3. Baixar o código-fonte oficial: Clonaremos o repositório do GitHub mantido pela Atomicorp, que continua o desenvolvimento ativo do OSSEC.
4. Executar o script de instalação interativa: Diferente de muitos tutoriais que usam instalação unattended, faremos questão de percorrer cada opção para entendimento completo.
5. Compilar e instalar os binários: O script compila todos os módulos e os posiciona em /var/ossec.

Execute os seguintes comandos no terminal como root (ou com sudo):

# Passo 1: Atualizar repositórios e instalar dependências
sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential git libssl-dev libpcre2-dev zlib1g-dev \
    libsystemd-dev libevent-dev libyaml-dev libsqlite3-dev pkg-config \
    libcurl4-openssl-dev make gcc wget

# Passo 2: Criar usuário e grupo dedicados (se já existirem, ignore os erros)
sudo groupadd --system ossec
sudo useradd --system -g ossec -d /var/ossec -m -s /sbin/nologin ossec

# Passo 3: Clonar o repositório estável do OSSEC HIDS
cd /usr/local/src
sudo git clone --branch v3.7.0 https://github.com/ossec/ossec-hids.git
cd ossec-hids

# Passo 4: Iniciar o script de instalação interativa
sudo ./install.sh

Quando o script install.sh for executado, ele fará uma série de perguntas. Responda conforme a tabela abaixo para uma configuração stand-alone (Manager + Agente local no mesmo host):

Ao final do questionário, o script compilará automaticamente todos os binários. A saída esperada da compilação bem-sucedida termina com uma mensagem similar a esta:

[ + ] Configuration finished successfully.
[ + ] You can start OSSEC HIDS by executing:
[ + ]     /var/ossec/bin/ossec-control start
[ + ] More information can be found at https://www.ossec.net
[ + ] Para iniciar o OSSEC HIDS, execute:
[ + ]     /var/ossec/bin/ossec-control start

Analisando linha por linha: O comando apt install -y build-essential instala o GCC, make e headers básicos. libssl-dev fornece suporte a criptografia para comunicação segura entre Manager e Agents. libpcre2-dev é crucial — sem ele, o OSSEC não consegue compilar o suporte a expressões regulares modernas, e muitas regras falharão silenciosamente. libsystemd-dev permite que o OSSEC se integre ao journald do systemd. A clonagem do branch v3.7.0 garante que estamos usando uma versão estável e testada. O diretório /var/ossec foi criado com permissões adequadas graças ao useradd -m.

Instalação do OSSEC — Rocky Linux 9 / CentOS Stream 9 (Passo a Passo Completo)

Em sistemas da família RHEL, o processo é similar, mas as dependências têm nomes diferentes e o SELinux merece atenção especial. O OSSEC pode ser compilado com sucesso em Rocky Linux 9, mas se o SELinux estiver em modo enforcing — como vem por padrão —, alguns alertas podem ser suprimidos ou serviços podem não iniciar. Felizmente, a própria comunidade OSSEC mantém políticas SELinux que aplicaremos.

1. Instalar grupos de desenvolvimento e bibliotecas: Usaremos dnf com o groupinstall “Development Tools”.
2. Habilitar repositórios adicionais (EPEL e PowerTools/CRB): Necessários para libyaml-devel e outras libs.
3. Compilar o OSSEC com suporte a systemd e PCRE2.
4. Ajustar contextos SELinux para /var/ossec.

# Passo 1: Instalar dependências de compilação
sudo dnf update -y
sudo dnf groupinstall -y "Development Tools"
sudo dnf install -y epel-release
sudo dnf config-manager --set-enabled crb   # CodeReady Builder (PowerTools)
sudo dnf install -y git openssl-devel pcre2-devel zlib-devel \
    systemd-devel libevent-devel libyaml-devel sqlite-devel \
    libcurl-devel make gcc wget

# Passo 2: Criar usuário dedicado
sudo groupadd --system ossec
sudo useradd --system -g ossec -d /var/ossec -m -s /sbin/nologin ossec

# Passo 3: Clonar e compilar
cd /usr/local/src
sudo git clone --branch v3.7.0 https://github.com/ossec/ossec-hids.git
cd ossec-hids
sudo ./install.sh

Durante o install.sh no Rocky Linux, as perguntas são idênticas às do Ubuntu. Siga a mesma tabela de respostas fornecida anteriormente. Após a compilação, ajuste o SELinux com os comandos abaixo. Este passo é frequentemente omitido em tutoriais e causa horas de debugging:

# Ajustar SELinux para permitir que o OSSEC leia logs e execute ações
sudo semanage fcontext -a -t httpd_sys_content_t "/var/ossec(/.*)?"
sudo restorecon -R -v /var/ossec
sudo setsebool -P daemons_enable_cluster_mode on
sudo chcon -R -t bin_t /var/ossec/bin/
sudo chcon -R -t lib_t /var/ossec/lib/

A saída esperada após o restorecon -R -v /var/ossec deve listar os arquivos com os novos contextos aplicados. Se o comando semanage não for encontrado, instale o pacote policycoreutils-python-utils com dnf install policycoreutils-python-utils -y. Em produção na JRT Technology Solutions, sempre ajustamos o SELinux em vez de desativá-lo — a prática de setenforce 0 é um vetor de risco que o OSSEC inclusive pode detectar e alertar.

Configuração Detalhada do Arquivo ossec.conf

O coração operacional do OSSEC é o arquivo /var/ossec/etc/ossec.conf. Ele é um XML bem estruturado que controla quais logs serão monitorados, com que frequência o Syscheck rodará, quais comandos de resposta ativa serão executados e quais IPs jamais serão bloqueados. Apresentaremos o conteúdo completo de um arquivo de configuração funcional para um servidor web + SSH típico. Abra o arquivo com seu editor preferido (sudo vim /var/ossec/etc/ossec.conf) e substitua pelo conteúdo abaixo. Cada seção está comentada em linha com propósitos didáticos.

<!-- /var/ossec/etc/ossec.conf — Configuração completa para Monitor Local -->
<ossec_config>
  
  <!-- ============ Global ============ -->
  <global>
    <email_notification>yes</email_notification>
    <email_to>admin@seudominio.com.br</email_to>
    <smtp_server>localhost</smtp_server>
    <email_from>ossec-server@seudominio.com.br</email_from>
    <email_maxperhour>12</email_maxperhour> <!-- Limita e-mails para evitar flood -->
    <white_list>127.0.0.1</white_list>
    <white_list>192.168.1.0/24</white_list> <!-- Rede interna confiável -->
  </global>

  <!-- ============ Syscheck (Monitoramento de Integridade) ============ -->
  <syscheck>
    <frequency>21600</frequency> <!-- 6 horas em segundos -->
    <directories check_all="yes" report_changes="yes" realtime="yes">/etc</directories>
    <directories check_all="yes" report_changes="yes" realtime="yes">/usr/bin</directories>
    <directories check_all="yes" report_changes="yes" realtime="yes">/usr/sbin</directories>
    <directories check_all="yes" report_changes="yes" realtime="yes">/bin</directories>
    <directories check_all="yes" report_changes="yes" realtime="yes">/sbin</directories>
    <directories check_all="yes" report_changes="yes">/var/www/html</directories>
    <!-- Ignorar arquivos que mudam frequentemente e gerariam falsos positivos -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/hosts.deny</ignore>
    <ignore>/var/log</ignore>
    <auto_ignore>no</auto_ignore>
    <alert_new_files>yes</alert_new_files>
  </syscheck>

  <!-- ============ Rootcheck ============ -->
  <rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
    <check_unixaudit>yes</check_unixaudit>
    <check_files>yes</check_files>
    <check_trojans>yes</check_trojans>
    <check_dev>yes</check_dev>
    <check_sys>yes</check_sys>
    <check_pids>yes</check_pids>
    <check_ports>yes</check_ports>
    <check_if>yes</check_if>
  </rootcheck>

  <!-- ============ Logs a serem monitorados (Localfile) ============ -->
  <localfile>
    <location>/var/log/auth.log</location>
    <log_format>syslog</log_format>
  </localfile>
  
  <localfile>
    <location>/var/log/secure</location>
    <log_format>syslog</log_format>
  </localfile>

  <localfile>
    <location>/var/log/messages</location>
    <log_format>syslog</log_format>
  </localfile>

  <localfile>
    <location>/var/log/apache2/access.log</location>
    <log_format>apache</log_format>
  </localfile>

  <localfile>
    <location>/var/log/apache2/error.log</location>
    <log_format>apache</log_format>
  </localfile>

  <localfile>
    <location>/var/log/mysql/error.log</location>
    <log_format>syslog</log_format>
  </localfile>

  <!-- ============ Active Response (Resposta Ativa) ============ -->
  <active-response>
    <command>host-deny</command>
    <location>local</location>
    <level>6</level>
    <timeout>600</timeout> <!-- Bloqueio por 10 minutos -->
  </active-response>

  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <level>10</level>
    <timeout>3600</timeout> <!-- Bloqueio por 1 hora para ataques severos -->
  </active-response>

  <!-- ============ Rules (Regras personalizadas) ============ -->
  <rules>
    <include>rules_config.xml</include>
    <include>local_rules.xml</include>
  </rules>

</ossec_config>

Vamos dissecar os elementos-chave: a tag <directories check_all=”yes” report_changes=”yes” realtime=”yes”> instrui o Syscheck a verificar permissões, ownership, tamanho e hashes (check_all), reportar o conteúdo exato das alterações (report_changes) e monitorar em tempo real via inotify (realtime) — este último é extremamente eficiente para diretórios como /etc, pois qualquer modificação gera um alerta em segundos. A tag <ignore> evita que arquivos de alta volatilidade, como /etc/mtab, disparem alertas a cada reboot. O parâmetro alert_new_files como “yes” garante que a criação de novos arquivos em diretórios monitorados também seja notificada — essencial para detectar backdoors.

Na seção de localfile, observe que incluímos tanto /var/log/auth.log (Debian/Ubuntu) quanto /var/log/secure (RHEL/Rocky). O formato syslog é o mais genérico e casa com a maioria dos logs de sistema; já o formato apache é especializado para logs de acesso web, permitindo que o OSSEC detecte padrões como SQL injection diretamente das URLs registradas. Em servidores de banco de dados, incluímos também o log de erro do MySQL/MariaDB.

Os scripts de resposta ativa host-deny e firewall-drop são extremamente poderosos. O primeiro adiciona IPs suspeitos ao arquivo /etc/hosts.deny, bloqueando o acesso via TCP wrappers (serviços que utilizam libwrap, como SSH). O segundo insere regras diretamente no firewall via iptables ou nftables, dependendo do backend configurado. A diferença de níveis (level 6 para host-deny e level 10 para firewall-drop) define uma escalada de severidade: eventos moderados recebem um bloqueio leve e temporário; ataques comprovadamente maliciosos sofrem bloqueio prolongado no kernel.

Verificando a Instalação e Testando a Configuração

Com o arquivo de configuração salvo, é hora de iniciar o OSSEC e verificar se todos os módulos estão operacionais. O comando principal de controle é /var/ossec/bin/ossec-control, que aceita as ações start, stop, restart, status e reload. Em ambientes de produção na JRT Technology Solutions, sempre executamos uma verificação completa após qualquer alteração no ossec.conf.

# Iniciar todos os daemons do OSSEC
sudo /var/ossec/bin/ossec-control start

A saída esperada ao iniciar com sucesso em um sistema Ubuntu 24.04 deve ser similar a esta:

Starting OSSEC HIDS v3.7.0 (by Trend Micro Inc.)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-syscheckd...
Started ossec-rootcheck...
Started ossec-monitord...
Completed.

Para verificar o status detalhado de cada daemon, utilize:

sudo /var/ossec/bin/ossec-control status

Saída esperada:

ossec-monitord is running...
ossec-logcollector is running...
ossec-remoted is running...
ossec-syscheckd is running...
ossec-analysisd is running...
ossec-maild is running...
ossec-execd is running...
ossec-rootcheck is running...
ossec-authd is running...

Se algum daemon não aparecer como “running”, inspecione imediatamente o log principal em /var/ossec/logs/ossec.log com sudo tail -f /var/ossec/logs/ossec.log. Mensagens de erro como “Unable to open file” ou “Permission denied” indicam problemas de permissão nos arquivos de log do sistema — verifique se o usuário ossec pertence ao grupo adm (no Ubuntu) ou se os contextos SELinux estão corretos (no Rocky).

Para testar se os alertas estão sendo gerados, simule uma tentativa de acesso SSH com senha incorreta. Em outro terminal, tente conectar-se ao localhost com um usuário inexistente e senha errada três vezes:

ssh nonexistentuser@localhost
# (digite qualquer senha e repita 3 vezes até ser desconectado)

Agora verifique os alertas gerados pelo OSSEC usando a ferramenta de visualização de alertas:

sudo /var/ossec/bin/ossec-logtest -a
# Pressione Ctrl+C após alguns segundos para sair do modo follow
# Ou visualize diretamente o arquivo de alertas:
sudo tail -30 /var/ossec/logs/alerts/alerts.log

Você deverá ver entradas no formato JSON ou texto puro com o campo rule indicando o ID da regra que disparou (por exemplo, 5712 – SSHD brute force attempt) e o nível de severidade. Isso confirma que o pipeline completo — coleta, análise e alerta — está funcionando.

Configurando Regras Personalizadas e Ajuste de Sensibilidade

O OSSEC vem com mais de 500 regras pré-definidas, mas o verdadeiro refinamento está em criar regras locais que adaptem a detecção ao seu ambiente específico. O arquivo /var/ossec/rules/local_rules.xml é o local correto para regras customizadas — ele jamais será sobrescrito durante atualizações. Vamos criar uma regra que eleve a severidade de acessos SSH fora do horário comercial e outra que ignore falsos positivos comuns.

<!-- /var/ossec/rules/local_rules.xml -->
<group name="local,syslog,sshd">

  <!-- Regra 100001: SSH login fora do horário comercial (22h-06h) -->
  <rule id="100001" level="12">
    <if_sid>5715</if_sid> <!-- SID da regra de sucesso de login SSH -->
    <time>22:00-06:00</time>
    <description>SSH login bem-sucedido fora do horário comercial.</description>
    <group>access_control,anomaly_time</group>
  </rule>

  <!-- Regra 100002: Ignorar varreduras do nosso scanner de vulnerabilidades interno -->
  <rule id="100002" level="0">
    <if_sid>31151</if_sid> <!-- SID de varredura de portas -->
    <srcip>192.168.1.100</srcip> <!-- IP do scanner autorizado -->
    <description>Varredura do scanner interno ignorada.</description>
  </rule>

  <!-- Regra 100003: Múltiplas falhas de sudo -->
  <rule id="100003" level="10">
    <if_matched_sid>5401</if_matched_sid> <!-- Falha de sudo -->
    <same_source_ip />
    <frequency>5</frequency>
    <timeframe>120</timeframe>
    <description>Múltiplas falhas de sudo do mesmo IP.</description>
  </rule>

</group>

Após editar o arquivo, recarregue as regras sem reiniciar todos os daemons:

sudo /var/ossec/bin/ossec-control reload rules

A saída esperada é silenciosa — ausência de erros no log. Para testar a nova regra 100003, tente executar comandos com sudo e senha incorreta várias vezes seguidas. Em seguida, inspecione o alerts.log; você verá um alerta com level 10 e a descrição “Múltiplas falhas de sudo do mesmo IP”. Ajuste a frequência (<frequency>) e o intervalo (<timeframe>) conforme a política de segurança da sua organização.

Resposta Ativa Automatizada — Bloqueio de Brute-Force SSH

O grande diferencial do OSSEC é a capacidade de agir automaticamente. Vamos configurar e testar a resposta ativa para bloquear IPs que executam brute-force contra o serviço SSH. A configuração que já inserimos no ossec.conf utiliza o comando host-deny, que adiciona linhas ao /etc/hosts.deny. Precisamos garantir que o serviço SSH esteja compilado com suporte a TCP wrappers (libwrap). No Ubuntu, isso é padrão; no Rocky, pode ser necessário instalar o pacote tcp_wrappers.

Primeiro, verifique se o SSH usa libwrap:

ldd /usr/sbin/sshd | grep libwrap

Se a saída mostrar algo como libwrap.so.0 => /lib64/libwrap.so.0, o suporte está ativo. Em seguida, edite o arquivo /etc/hosts.allow para garantir que seu próprio IP ou rede interna jamais seja bloqueada — uma medida de segurança crítica que já implementamos indiretamente com <white_list> no ossec.conf, mas a defesa em profundidade exige redundância:

# /etc/hosts.allow
ALL: 127.0.0.1
ALL: 192.168.1.0/24
sshd: ALL

Agora, simule um ataque de brute-force de um IP externo. Como teste, você pode usar um segundo terminal ou máquina virtual para tentar logins SSH repetidos com senhas erradas. Se você estiver limitado a uma única máquina, pode gerar logs manualmente com o comando logger para disparar as regras:

# Simular 8 tentativas de login SSH falhas em 60 segundos (dispara a regra 5712)
for i in {1..8}; do
  logger -p auth.info "sshd[$$]: Failed password for invalid user fakeuser from 203.0.113.44 port $((2222+i)) ssh2"
done

Após executar o loop, aguarde alguns segundos e verifique o arquivo de alertas. O OSSEC deve ter gerado um alerta de nível 10 ou superior e, se a resposta ativa estiver funcionando, o IP 203.0.113.44 será adicionado ao /etc/hosts.deny:

sudo cat /etc/hosts.deny

Saída esperada (parcial):

# Hosts denied by OSSEC HIDS
ALL: 203.0.113.44 : DENY

Para remover o bloqueio manualmente (após o timeout configurado de 600 segundos, ele se auto-removerá), use:

sudo /var/ossec/active-response/bin/host-deny delete - 203.0.113.44

Em nossos projetos na JRT Technology Solutions, sempre configuramos a resposta ativa com timeouts escalonados: 10 minutos para a primeira ocorrência, 1 hora para a segunda no mesmo dia e bloqueio permanente (com notificação manual) para reincidências extremas. Essa lógica é implementada através de regras incrementais no local_rules.xml.

Monitoramento Contínuo e Alertas via E-mail

Para que o OSSEC envie alertas por e-mail, é necessário um agente de transporte de e-mail (MTA) local configurado. Se você não possui um Postfix ou Sendmail funcionando, instale e configure minimamente:

# Ubuntu/Debian

sudo apt install -y postfix mailutils

# Durante a instalação, selec


Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Segurança Linux para equipes corporativas.
  

    

    Falar no WhatsApp