Snort

1. Contexto histórico e normativo

O Snort foi criado em 1998 por Martin Roesch como um sniffer de rede simples, e evoluiu rapidamente para se tornar um dos mais conhecidos sistemas de detecção e prevenção de intrusão (IDS/IPS) do mundo. Em 2001, Roesch fundou a Sourcefire, adquirida pela Cisco em 2013, e desde então o Snort é mantido pelo time de pesquisa Talos (antigo VRT — Vulnerability Research Team).

O formato de regras do Snort se tornou um padrão de facto tão difundido que o Suricata — concorrente mais recente — foi projetado para ser compatível com ele, permitindo que a maioria das regras escritas para um motor funcione no outro.

Em termos normativos, o Snort implementa detecção por assinatura (análise de padrões), e sua base de regras é alinhada a padrões como CVE (Common Vulnerabilities and Exposures) e boas práticas do NIST SP 800-94 (Guide to Intrusion Detection and Prevention Systems).

2. Arquitetura interna

O Snort é composto por componentes que atuam em sequência:

• Decodificador de pacotes — interpreta protocolos de rede (Ethernet, IP, TCP, UDP, ICMP).
• Pré-processadores — normalizam o tráfego e detectam anomalias (ex.: fragmentação IP, varreduras de porta, ataques de negação de serviço).
• Motor de detecção — aplica regras de assinatura baseadas em padrões de conteúdo, portas, flags e outras características.
• Sistema de logging e saída — gera alertas em formato texto, syslog ou banco de dados (Snort 3 pode exportar em JSON).

No Snort 2.x, o processamento é single-thread, o que limita o throughput em redes de alto volume. O Snort 3 introduz suporte a múltiplos threads, mas a migração ainda é gradual.

3. Snort 2 vs. Snort 3

Snort 2.x, historicamente single-thread, atingiu fim de vida — mas continua amplamente documentado e presente em instalações existentes e material didático. Snort 3 é reescrita moderna, com suporte a multi-thread — mas a adoção de mercado ainda é fragmentada, com boa parte de tutorial e configuração de produção ainda referenciando o 2.x. Antes de seguir qualquer guia, confirme qual versão está de fato instalada — a sintaxe de configuração muda entre as duas.

4. Instalação

# Debian/Ubuntu — pacote da distro costuma ser Snort 2.x
apt update
apt install snort

# Durante a instalação, pergunta a faixa de rede local (HOME_NET) —
# responder com a rede real do ISP, não deixar padrão de exemplo

# Validar configuração antes de rodar em produção
snort -T -c /etc/snort/snort.conf

Snort 3, quando necessário, geralmente exige compilação a partir do código-fonte (Snort3/snort3 no GitHub) ou pacote específico não sempre presente no repositório padrão da distro — processo mais trabalhoso que a instalação via apt do 2.x.

5. Regras — sintaxe e origem VRT/Talos

# Registro gratuito no site da Cisco/Snort libera acesso às regras
# comunitárias e registradas (com atraso de disponibilização frente
# às regras pagas de assinante)
pulledpork.pl -c /etc/snort/pulledpork.conf -l

# Regras ficam em /etc/snort/rules/*.rules, referenciadas em snort.conf via:
# include $RULE_PATH/local.rules

6. Regra própria — exemplo ISP

Mesma lógica de detecção de varredura de porta já vista em Suricata — sintaxe praticamente idêntica, reflexo direto da compatibilidade de formato:

# /etc/snort/rules/local.rules
alert tcp !$HOME_NET any -> $HOME_NET any (msg:"Possivel varredura de porta na rede de gerencia"; \
    flags:S; threshold:type threshold, track by_src, count 15, seconds 60; \
    classtype:attempted-recon; sid:1000001; rev:1;)

7. Modo IDS vs. inline (IPS)

Mesma recomendação de prudência já vista em Suricata: começar em modo passivo (escuta via espelho de tráfego), afinar regras reduzindo falso positivo, só depois migrar pra modo inline (-Q, usando DAQ — Data Acquisition library — em modo AFPacket ou NFQ) onde o Snort de fato bloqueia tráfego em tempo real.

8. OpenAppID — detecção de aplicação

Recurso citado como diferencial do Snort frente ao Suricata em comparação recente: OpenAppID permite detecção de aplicação específica no tráfego (ex: identificar uso de determinado app de mensageria ou P2P), não só assinatura de ataque — relevante pra ISP que quer visibilidade de tipo de tráfego trafegando na rede, além de só segurança pura.

9. Monitoramento e métricas

O Snort pode gerar alertas em syslog, permitindo integração com Zabbix/PRTG. Exemplo de health check:

#!/bin/bash
# check_snort.sh
if pgrep -x snort > /dev/null; then
  echo "OK: Snort rodando"
  exit 0
else
  echo "CRITICAL: Snort parado"
  exit 2
fi

Métricas úteis: número de alertas por minuto, taxa de pacotes processados, uso de CPU/memória e taxa de packet drop.

10. Backup e recuperação

• Configuração — /etc/snort/ (incluindo snort.conf e regras customizadas).
• Regras próprias — local.rules e qualquer arquivo de regra customizado.
• Restauração — recriar os arquivos e reiniciar o serviço.

Use restic ou Borg com a regra 3‑2‑1‑1‑0.

11. Dimensionamento e performance

O Snort 2.x é single-thread, o que limita o throughput a uma única CPU. Para redes de alto volume (> 1 Gbps), é recomendado usar Snort 3 ou Suricata. Em qualquer versão, o número de regras ativas impacta diretamente a performance — mais regras = mais CPU por pacote.

12. Comparação com Suricata

Para redes novas, o Suricata tende a ser a recomendação mais citada; Snort se mantém relevante onde há legado, OpenAppID ou preferência por regras Subscriber da Cisco/Talos.

13. Troubleshooting

14. Glossário

15. Referências

• Cisco Talos / Snort.org — documentação oficial, regras VRT.
• NIST SP 800-94 — Guide to Intrusion Detection and Prevention Systems.
• Página relacionada: Suricata.

Conteúdo técnico independente. Nenhum trecho é cópia literal de fonte de terceiro.