Suricata IDS/IPS no Ubuntu Server: guia passo a passo

O Suricata é o motor de detecção e prevenção de intrusão (IDS/IPS) open source mais usado hoje fora do mundo Snort — versão estável atual 8.0.6, mantida pela Open Information Security Foundation. Neste guia você instala o Suricata 8 num Ubuntu Server, configura a rede monitorada, atualiza as regras de detecção e liga o modo inline (IPS) com NFQUEUE, tudo com comandos reais para reproduzir.

Por que rodar um IDS/IPS além do firewall

Um firewall como pfSense ou FortiGate decide com base em porta, IP e protocolo — ele não olha o conteúdo do pacote. O Suricata inspeciona a carga útil do tráfego contra milhares de assinaturas (exploits conhecidos, malware, scans, exfiltração) e gera alerta em tempo real. Em modo IDS ele só observa e loga; em modo IPS (inline) ele também derruba o pacote malicioso antes de chegar ao destino. A diferença prática: um SIEM como o Wazuh centraliza e correlaciona logs depois do fato, o Suricata pega a ameaça no fio.

Pré-requisitos

Ubuntu Server 22.04 ou 24.04 com acesso root via sudo, uma interface de rede que você possa colocar em modo de captura (uma porta espelhada do switch, um SPAN/mirror, ou a própria interface do host para começar) e a faixa de IP da rede que o Suricata vai monitorar. Para o modo IPS mais adiante, é preciso que o Ubuntu já esteja no caminho do tráfego que quer inspecionar — como gateway, bridge ou roteador.

Passo a passo: instalar e configurar

1. Adicione o repositório oficial e instale. O pacote do Ubuntu costuma estar desatualizado; o PPA da OISF garante a versão estável mais recente.

   sudo apt update
   sudo apt install -y software-properties-common
   sudo add-apt-repository -y ppa:oisf/suricata-stable
   sudo apt update
   sudo apt install -y suricata jq

2. Confirme a versão instalada.

   suricata --build-info | head -n 3

3. Defina a rede monitorada. Edite /etc/suricata/suricata.yaml e ajuste HOME_NET para a(s) sub-rede(s) local(is) e EXTERNAL_NET para tudo que não é local — isso evita alertas invertidos (tráfego interno classificado como externo).

   sudo nano /etc/suricata/suricata.yaml
   # dentro de vars: address-groups:
   #   HOME_NET: "[192.168.1.0/24,10.0.0.0/8]"
   #   EXTERNAL_NET: "!$HOME_NET"

4. Aponte a interface de captura. No mesmo arquivo, na seção af-packet, troque a interface padrão pela sua (ex.: ens18, eth0).

   # af-packet:
   #   - interface: ens18
   #     cluster-id: 99
   #     cluster-type: cluster_flow

5. Baixe e ative o conjunto de regras. O suricata-update vem junto do pacote e cuida de baixar, mesclar e validar as regras (ET Open por padrão).

   sudo suricata-update
   sudo suricata -T -c /etc/suricata/suricata.yaml -v

   O -T testa a configuração sem subir o processo — rode sempre depois de mexer no YAML ou nas regras, porque um erro de sintaxe aqui derruba o serviço.

6. Suba o serviço e habilite no boot.

   sudo systemctl enable --now suricata
   sudo systemctl status suricata

7. Teste a detecção de verdade. O domínio testmyids.com existe justamente para disparar uma assinatura de teste do ruleset ET — se aparecer no log, a cadeia captura → engine → regra → alerta está funcionando.

   curl http://testmyids.com
   sudo tail -f /var/log/suricata/fast.log

   Para acompanhar em formato estruturado (o que alimenta Wazuh, ELK ou um script próprio), use o eve.json:

   sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'

Ativando o modo IPS (inline) com NFQUEUE

Por padrão o Suricata roda em IDS: só observa uma cópia do tráfego e não pode bloquear nada. Para virar IPS, ele precisa ficar no caminho do pacote — no Linux isso é feito com NFQUEUE, um alvo do iptables que desvia o pacote para o espaço de usuário e espera o veredito do Suricata antes de deixá-lo seguir ou descartá-lo.

1. Redirecione o tráfego relevante para a fila. Em um host que roteia entre duas interfaces:

   sudo iptables -I FORWARD -j NFQUEUE --queue-num 0

   Para inspecionar também o tráfego que entra e sai do próprio host, some:

   sudo iptables -I INPUT -j NFQUEUE --queue-num 0
   sudo iptables -I OUTPUT -j NFQUEUE --queue-num 0

2. Suba o Suricata em modo NFQ, apontando para a mesma fila:

   sudo suricata -c /etc/suricata/suricata.yaml -q 0

3. Troque regras de “alert” para “drop” onde fizer sentido. Regras ET vêm como alert por padrão — só viram bloqueio ativo se você as reclassificar via drop.conf no suricata-update ou escrever suas próprias regras com ação drop.

Cuidado com o pulo do gato: se o processo do Suricata cair com as regras de NFQUEUE ainda ativas no iptables, todo o tráfego que passa pela fila fica preso sem veredito — a rede para. Tenha sempre um plano de rollback (iptables -F) antes de testar em produção, e valide primeiro num host de laboratório ou fora do horário de pico.

Perguntas frequentes

Suricata substitui o firewall?
Não. Ele complementa: o firewall decide o que pode trafegar por porta e IP, o Suricata olha dentro do pacote permitido em busca de ataque conhecido. Os dois trabalham juntos.

Dá para rodar em uma VM pequena?
Dá, mas o consumo de CPU escala com o volume de tráfego inspecionado e o número de regras ativas. Comece só com o ruleset ET Open e monitore htop antes de somar mais fontes de regra.

Qual a diferença para o Snort?
Os dois usam sintaxe de regra compatível, mas o Suricata processa múltiplas threads nativamente e tem suporte nativo a saída JSON (eve.json), o que facilita integrar com SIEM.

Preciso reiniciar o serviço a cada atualização de regra?
Não necessariamente — com rule-reload: true na seção detect-engine do YAML, um kill -USR2 no processo recarrega as regras sem derrubar a captura.

O modo IPS deixa a rede mais lenta?
Adiciona latência, sim, porque cada pacote passa pela fila antes de seguir. Em redes de borda isso costuma ser imperceptível; em backbones de alto throughput, dimensione hardware e número de filas (multi-queue) antes de ativar.

Conclusão

Com o Suricata rodando em modo IDS você já ganha visibilidade real sobre o que passa pela rede — o próximo passo natural é mandar o eve.json para um SIEM (o Wazuh, coberto aqui no PulseIT, aceita esse log nativamente) e só então avaliar se o ambiente pede o salto para IPS inline, que exige mais teste e mais tolerância a risco operacional.