Laboratório de Implantação de IDS/IPS Snort

Um ciclo completo de implantação do Snort 3 como Sistema de Detecção de Intrusão (monitoramento passivo) e como Sistema de Prevenção de Intrusão (bloqueio ativo via iptables), validado contra quatro vetores de ataque em uma rede virtual de três máquinas no Kali Linux.

O laboratório demonstra a distinção operacional entre detecção e prevenção executando uma cadeia de ataque idêntica de quatro vetores duas vezes — primeiro contra um IDS que registra mas não pode bloquear, depois contra uma camada IDS + iptables IPS que elimina ataques seletivamente enquanto preserva o tráfego legítimo.

Índice

• Ambiente do Laboratório
• Topologia de Rede
• Metodologia
• Configuração do Snort
• Regras de Detecção Personalizadas
• Estágio 1 — Modo IDS
• Estágio 2 — Modo IPS
• IDS vs IPS — Resultados Lado a Lado
• Discussão
• Nota de Arquitetura
• Estrutura do Repositório
• Reproduzindo o Laboratório
• Aviso Ético
• Licença

Ambiente do Laboratório

Topologia de Rede

Todo o tráfego entre o Atacante e o Metasploitable é forçado a passar pelo Analisador, tornando-o o ponto de estrangulamento natural tanto para monitoramento quanto para aplicação de regras.

                           ┌─────────────────────────┐
                           │   Analisador / Roteador │
                           │   Kali + Snort 3        │
                           │                         │
   Atacante Kali ──VMnet9──┤ eth1: 10.10.10.1        │
   10.10.10.10             │                         │
                           │ eth0: 192.168.10.143 ───┼──> WAN (NAT)
                           │                         │
   Metasploitable 2 ─VMnet10┤ eth2: 192.168.50.1     │
   192.168.50.10           │                         │
                           └─────────────────────────┘

Substitua este esboço ASCII por screenshots/01-network-topology.png assim que tiver a figura no lugar: Topologia

Metodologia

O laboratório é executado em dois estágios com uma cadeia de ataque idêntica de quatro vetores em cada:

1. Reconhecimento ICMP — ping para descoberta de host
2. Varredura SYN do Nmap — nmap -sS para enumeração de portas (1000 portas)
3. Ataque de força bruta FTP com Hydra — ataque de credenciais contra o serviço vsftpd
4. Backdoor vsftpd 2.3.4 — exploit do Metasploit para CVE-2011-2523

Estágio 1 (IDS) executa o Snort passivamente no Analisador com cinco regras personalizadas — observe os alertas em tempo real, confirme que a exploração prossegue mesmo assim.

Estágio 2 (IPS) combina o Snort com uma camada de aplicação de regras iptables usando regras de descarte cirúrgicas — confirme que os ataques são bloqueados enquanto o ping ICMP e o login FTP legítimo permanecem funcionais.

Configuração pré-implantação

1. Configure o Analisador com três NICs no VMware (duas host-only, uma NAT/ponte).
2. Ative o encaminhamento IP e adicione regras MASQUERADE + FORWARD para que o Analisador roteie entre sub-redes e para a WAN — veja scripts/router_config.sh.
3. Verifique a conectividade ponta a ponta de cada VM com scripts/ping_check.sh antes de instalar o Snort.

Configuração do Snort

O Snort é instalado via gerenciador de pacotes do Kali (sudo apt install snort -y) e configurado em /etc/snort/snort.conf:

HOME_NET = "10.10.10.0/24,192.168.50.0/24"
EXTERNAL_NET = "any"

ips = {
    enable_builtin_rules = true,
    include = "/etc/snort/rules/local.rules",
    variables = default_variables
}

alert_fast = { file = true, packet = false }

HOME_NET abrange ambas as sub-redes internas para que o Snort trate todo o tráfego entre sub-redes no Analisador como digno de inspeção. alert_fast produz alertas compactos de uma linha (o registro por pacote geraria volume excessivo).

Validação da configuração:

sudo snort -T -c /etc/snort/snort.conf
# Resultado: 652 regras carregadas (5 texto personalizado + 647 embutidas), 0 avisos

Regras de Detecção Personalizadas

Cinco regras em /etc/snort/rules/local.rules (arquivo completo em scripts/local.rules):

Estágio 1 — Modo IDS

O Snort executa em modo passivo em ambas as interfaces internas:

sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 \
    -A alert_fast -l /var/log/snort/

# Observe os alertas em um segundo terminal:
sudo tail -f /var/log/snort/alert_fast.txt

A saída de inicialização confirma que pcap DAQ configured to passive — o Snort vê cada pacote, mas não pode descartar ou modificar nenhum deles.

Resultados do IDS

Após executar scripts/attack_simulator.sh a partir do Atacante:

O IDS detectou tudo e não parou nada. Esta é a lição central do Estágio 1: um IDS funcional sem aplicação de regras é um sistema de alarme, não uma fechadura. Quando um analista de SOC lê os alertas, o atacante já é root.

Uma observação secundária: as regras embutidas do Snort (116:408, 116:414) disparam em tráfego de broadcast DHCP — não é malicioso, mas em uma implantação de produção precisariam de regras de supressão para manter o log de alertas acionável.

Estágio 2 — Modo IPS

A camada IPS é implantada com scripts/ips_setup.sh, que:

1. Libera as regras iptables existentes
2. Reativa o encaminhamento IP e reaplica o roteamento básico
3. Aplica quatro regras de descarte cirúrgicas voltadas a assinaturas de ataque específicas
4. Inicia o Snort em modo daemon (-D) para registro contínuo

Regras iptables

Resultados do IPS

O mesmo script de ataque foi reexecutado a partir do Atacante:

Tráfego normal preservado

Duas verificações manuais confirmaram a aplicação seletiva:

• ping -c 4 192.168.50.10 → 4 pacotes transmitidos, 4 recebidos, 0% de perda
• ftp 192.168.50.10 com msfadmin:msfadmin → 220 (vsFTPd 2.3.4) … 230 Login bem-sucedido

Prova quantitativa dos contadores de pacotes iptables durante a execução: 2051 pacotes aceitos, 12 pacotes descartados pela regra connlimit do FTP, 808 pacotes ICMP aceitos — aplicação seletiva em números.

Registro contínuo do Snort

Mesmo no modo IPS, o Snort continuou disparando alertas SID 1000002 / 1000003 em pacotes que atingiram seu ponto de inspeção passiva antes que o iptables descartasse os subsequentes — significando que iptables fornece aplicação enquanto o Snort fornece auditoria de logs, operando em conjunto.

IDS vs IPS — Resultados Lado a Lado

Discussão

Todos os ataques simulados foram detectados no modo IDS?

Sim — cada um dos SIDs 1000001–1000004 disparou corretamente durante a simulação de ataque:

• Ping ICMP (1000001) — alertas bidirecionais para cada eco/resposta.
• Varredura SYN do Nmap (1000003) — inundação de alertas em milissegundos, randomização de porta de origem característica.
• Força bruta FTP (1000002) — trilha de auditoria limpa das tentativas de conexão paralela do Hydra com timestamps exatos.
• Backdoor vsftpd (1000004) — a correspondência de conteúdo :) capturou a sequência exata de bytes do exploit.

Mas detecção ≠ prevenção. O exploit vsftpd abriu um shell Meterpreter root enquanto todos os alertas estavam disparando. Um analista de SOC monitorando o IDS em tempo real teria visto o comprometimento — mas com o atacante já root em segundos, apenas alertar não é suficiente. Este é o núcleo operacional de por que o IPS existe.

Quão eficaz foi o IPS em bloquear ataques sem quebrar o tráfego normal?

A implementação alcançou mitigação completa de ataques com zero impacto observável no tráfego legítimo. A eficácia vem do design cirúrgico das regras — cada regra iptables visa uma assinatura comportamental, não um protocolo amplo:

• Limite de taxa SYN quebra o padrão de inundação das varreduras de porta sem afetar handshakes normais.
• connlimit por origem bloqueia o paralelismo das ferramentas de força bruta sem quebrar FTP de sessão única.
• Correspondência STRING descarta a carga exata do exploit sem filtrar tráfego de login FTP legítimo.

Uma limitação reconhecida: o ICMP é totalmente permitido, o que significa que um atacante ainda pode confirmar que o Metasploitable está ativo via ping. Em um ambiente de maior segurança, isso seria limitado por taxa ou restrito a fontes confiáveis. Neste laboratório, o ICMP é o principal mecanismo de verificação de conectividade, portanto permanece aberto.

Máquina Snort dedicada vs. plugin pfSense/OPNsense

Este laboratório usa uma máquina Snort dedicada. Comparado a executar o Snort como um plugin dentro de um appliance de firewall como pfSense ou OPNsense:

Vantagens da abordagem dedicada:

• Isolamento de desempenho — CPU e RAM completos disponíveis exclusivamente para inspeção de pacotes; sem contenção com roteamento, DHCP, VPN, DNS.
• Flexibilidade de posicionamento — o IDS/IPS pode ficar em linha, em uma porta SPAN/espelho, ou em um limite de segmento interno para monitorar tráfego leste-oeste que nunca atinge o firewall de perímetro.
• Controle total de configuração — cada preprocessador, configuração DAQ, plugin de saída e agenda de atualização de regras é configurável via CLI. O pfSense expõe apenas um subconjunto através de sua GUI.
• Resiliência — a máquina IDS/IPS pode falhar-aberta ou falhar-fechada independentemente do roteador. No pfSense, uma falha do Snort derruba tanto o roteamento quanto a detecção de uma vez.

Compensações:

• Curva de aprendizado mais íngreme — requer proficiência em CLI e gerenciamento direto de conjuntos de regras.
• Sobrecarga de manutenção — atualizações de regras, upgrades de versão, rotação de logs, todos manuais.

O Snort dedicado é a escolha correta para ambientes empresariais que precisam de desempenho, posicionamento e personalização. A abordagem de plugin pfSense/OPNsense faz mais sentido para ambientes de pequenas empresas ou laboratórios domésticos que priorizam a facilidade de uso.

Nota de Arquitetura

O Estágio 2 é tecnicamente Snort passivo + aplicação iptables, não Snort executando em modo inline verdadeiro — o próprio Snort registra (pcap DAQ configured to passive), e o iptables realiza o descarte com base em limites de taxa, correspondências de string e contagens de conexão.

Este é um padrão de implantação legítimo e comum (é como muitas pilhas IDS/IPS baseadas em Linux do mundo real operam). Um acompanhamento natural seria migrar o Estágio 2 para uma configuração inline verdadeira usando snort --daq nfq (ou afpacket em modo inline) com as ações de regra reject / drop do Snort, para que o próprio Snort realize o descarte com base na correspondência completa de assinaturas, em vez de delegar ao iptables.

Estrutura do Repositório

snort-ids-ips-lab/
├── README.md                       ← este arquivo
├── report/
│   ├── Snort-IDS-IPS-Report.pdf    ← relatório completo do laboratório
│   └── Snort-IDS-IPS-Report.docx   ← fonte editável
├── scripts/
│   ├── router_config.sh            ← encaminhamento IP + roteamento iptables
│   ├── ping_check.sh               ← verificação de conectividade
│   ├── attack_simulator.sh         ← cadeia de ataque de 4 vetores
│   ├── ips_setup.sh                ← regras iptables IPS + daemon Snort
│   └── local.rules                 ← 5 regras Snort personalizadas (SID 1000001-1000005)
├── screenshots/                    ← figuras do relatório
├── .gitignore
└── LICENSE

Reproduzindo o Laboratório

⚠️ Uso exclusivo em laboratório. Estes scripts executam exploits reais e ferramentas de força bruta contra um alvo deliberadamente vulnerável. Não os execute contra qualquer sistema que você não possua e para o qual não tenha autorização explícita por escrito para testar.

1. Construa três VMs no VMware de acordo com a topologia acima (VMnet9 e VMnet10 como host-only).
2. No Analisador: execute scripts/router_config.sh, depois scripts/ping_check.sh para confirmar a conectividade total.
3. Instale o Snort 3 no Analisador:
   root@kitploit:~

   sudo apt update && sudo apt install snort -y
   

4. Coloque scripts/local.rules em /etc/snort/rules/local.rules e defina HOME_NET = "10.10.10.0/24,192.168.50.0/24" em /etc/snort/snort.conf.
5. Valide: sudo snort -T -c /etc/snort/snort.conf — espere 652 regras carregadas, 0 avisos.
6. Estágio 1 — IDS:
   root@kitploit:~

   sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 -A alert_fast -l /var/log/snort/
   # Em outro terminal:
   sudo tail -f /var/log/snort/alert_fast.txt
   

   No Atacante: sudo ./scripts/attack_simulator.sh — observe os alertas disparando e o shell Meterpreter.

Aviso Ético

Todas as atividades documentadas neste repositório foram conduzidas exclusivamente dentro de um ambiente de laboratório virtual VMware autocontido para fins acadêmicos supervisionados. Nenhum sistema externo, de produção ou do mundo real foi alvo, escaneado ou afetado de qualquer forma. O Metasploitable 2 é uma máquina virtual intencionalmente vulnerável projetada especificamente para treinamento de segurança.

Este material não deve ser usado para replicar estas atividades contra qualquer sistema real sem autorização explícita por escrito do proprietário do sistema. Varreduras de porta não autorizadas, ataques de credenciais ou exploração de serviços de rede são ilegais na maioria das jurisdições.

Licença

MIT — veja LICENSE. O relatório do laboratório em si é fornecido para referência educacional.