Como configurar um IPS no Fedora 17

Introdução

Este guia mostra como montar um Sistema de Prevenção de Intrusões (IPS) funcional no Fedora 17 usando apenas pacotes dos repositórios oficiais: Vuurmuur (gestor de firewall) e Suricata (IDS/IPS multithread). Vou cobrir instalação, testes em modo IDS, configuração de encaminhamento de tráfego para inspeção, ativação do modo inline do Suricata e uma regra de exemplo que bloqueia acessos a um domínio.

Nota: um IPS pode bloquear tráfego produtivo se estiver mal configurado. Teste em IDS antes de ativar o modo inline.

Importante: Faça backup das configurações de firewall e regras antes de modificar o sistema em produção.

O que vamos usar

• Vuurmuur: interface que traduz regras legíveis para iptables. Permite visualização de logs e gestão de interfaces.
• Suricata: motor IDS/IPS moderno, multithread, capaz de inspeção profunda e extração de arquivos HTTP.
• Regras Emerging Threats otimizadas para Suricata (gratuitas).

Instalar Vuurmuur e Suricata

Instale os pacotes via yum:

yum install suricata Vuurmuur-daemon Vuurmuur-tui

Executar Suricata em modo IDS (teste passivo)

Antes de passar ao IPS (que bloqueia), teste em modo IDS. Baixe as regras Emerging Threats e coloque-as em /etc/suricata/rules/:

cd /etc/suricata/
curl -O https://rules.emergingthreatspro.com/open/suricata/emerging.rules.tar.gz
tar xzvf emerging.rules.tar.gz
ln -s /etc/suricata/rules/reference.config /etc/suricata/reference.config
ln -s /etc/suricata/rules/classification.config /etc/suricata/classification.config
cp /etc/suricata/rules/suricata-1.2-prior-open.yaml /etc/suricata/suricata.yaml

Teste o Suricata apontando para a interface de rede (ex.: eth0):

suricata -c /etc/suricata/suricata.yaml -i eth0

Deixe rodando alguns minutos e gere tráfego (abra um navegador, visite sites). Verifique /var/log/suricata/stats.log e /var/log/suricata/http.log para confirmar a captura de tráfego.

Preparar Vuurmuur para encaminhar tráfego a Suricata

Usaremos o Vuurmuur para encaminhar tráfego ao Suricata via NFQUEUE. Primeiro configure uma regra permissiva em Vuurmuur para capturar tudo (modo inicial):

Abra o utilitário de configuração do Vuurmuur (vuurmuur_conf), vá em Rules e adicione:

accept service any from any to any log

A captura desta regra mostrará tráfego no visualizador de logs de Vuurmuur.

Em seguida, adicione a interface física que o Vuurmuur deve controlar: vá a Interfaces e crie uma nova entrada com device = eth0 (ou a interface apropriada).

Saia do konfigurador quando terminar.

Ajuste do rsyslog

Para que o log do Vuurmuur funcione corretamente, edite /etc/rsyslog.conf e acrescente:

*.debug /var/log/debug

Reinicie o rsyslog:

service rsyslog restart

Iniciar Vuurmuur e habilitar no boot

Inicie o serviço e habilite-o para iniciar automaticamente:

service vuurmuur start
systemctl enable vuurmuur.service

Abra o visualizador de logs do Vuurmuur (vuurmuur_conf → logviewer) para checar se o tráfego está visível.

Encaminhar todo o tráfego para Suricata

Altere a regra do Vuurmuur para enviar o tráfego para NFQUEUE, que permite que o Suricata inspecione e decida aceitar ou rejeitar pacotes:

nfqueue service any from any to any

Aplique as mudanças em vuurmuur_conf — isso atualiza o firewall automaticamente. O log deve mostrar que o tráfego está sendo passado para a fila:

Inicie o Suricata em modo inline (NFQUEUE) com prioridade de fila 0:

suricata -c /etc/suricata/suricata.yaml -q0

Verifique novamente /var/log/suricata/stats.log e /var/log/suricata/http.log para confirmar inspeção de tráfego.

Exemplo parcial de stats.log (saída típica para diagnóstico):

-------------------------------------------------------------------
Date: 10/8/2012 -- 17:20:08 (uptime: 0d, 01h 39m 02s)
-------------------------------------------------------------------
Counter                   | TM Name                   | Value
-------------------------------------------------------------------
decoder.pkts              | Decode1                   | 3147
decoder.bytes             | Decode1                   | 1453192
... (saída resumida)
detect.alert              | Detect                    | 0

Exemplo parcial de http.log (entradas de navegação):

10/08/2012-17:24:02.447292 www.howtoforge.com [] / [] Mozilla/5.0 ... 192.168.122.48:48396 -> 188.40.16.205:80
10/08/2012-17:24:02.544458 static.howtoforge.com [] /misc/drupal.css ... 192.168.122.48:52942 -> 178.63.27.110:80

Quando terminar os testes interativos, pare o Suricata com Ctrl-C e edite /etc/sysconfig/suricata para rodar como daemon em NFQUEUE:

OPTIONS="-q 0 -D --pidfile /var/run/suricata.pid"

Inicie via service e habilite no boot:

service suricata start
systemctl enable suricata.service

Passo final: dropar tráfego (exemplo)

Por padrão as regras que baixamos usam ação alert. Para que o Suricata bloqueie, ative o reassembly inline e carregue regras com ação drop.

Edite /etc/suricata/suricata.yaml e, na seção stream, defina inline para yes:

stream:
  memcap: 32mb
  checksum_validation: yes      # reject wrong csums
  inline: yes

Inclua local.rules na lista de rule-files, por exemplo:

default-rule-path: /etc/suricata/rules/
rule-files:
 - local.rules
 - emerging-ftp.rules
 - emerging-policy.rules

Crie /etc/suricata/rules/local.rules e adicione uma regra simples para bloquear requisições contendo facebook.com no header HTTP:

drop tcp any any -> any any (msg:"facebook is blocked"; content:"facebook.com"; http_header; nocase; classtype:policy-violation; sid:1;)

Reinicie o Suricata:

service suricata restart

Agora, ao tentar abrir http://www.facebook.com/ em um navegador, a requisição deverá falhar (timeout). O /var/log/suricata/fast.log mostrará entradas de drop semelhantes a:

10/06/2012-11:40:49.018377  [Drop] [] [1:1:0] facebook is blocked [**] ... {TCP} 192.168.122.48:57113 -> 173.252.100.16:80

Boas práticas e considerações

• Sempre valide regras em um ambiente de teste antes de aplicar em produção.
• Comece em modo IDS (alert) e monitore logs por pelo menos alguns dias.
• Use regras com SID e documentação para facilitar gestão.
• Faça backup das configurações: /etc/suricata/ e /etc/vuurmuur/.

Checklist por função

Administrador de rede:

• Fazer snapshot/backup do servidor.
• Confirmar interfaces de rede e nome (eth0 ou equivalente).
• Instalar pacotes e dependências.
• Validar performance (CPU/memória) ao rodar Suricata.

Analista de segurança:

• Testar regras em IDS.
• Definir políticas de bloqueio (policy-violation).
• Catalogar falsos positivos e ajustar regras.

Operações/Suporte:

• Monitorar /var/log/suricata/*.log e /var/log/debug.
• Garantir processos suricata e vuurmuur em execução.
• Planejar janela de manutenção para mudanças de regras.

Mini-metodologia (passos rápidos)

1. Instale Suricata e Vuurmuur.
2. Baixe regras e verifique configuração básica do Suricata.
3. Rode Suricata em modo IDS (-i) e monitore logs.
4. Configure Vuurmuur para encaminhar tráfego via NFQUEUE.
5. Ative inline no Suricata, adicione local.rules com drops.
6. Teste, ajuste e implante no ambiente de produção.

Fluxo de decisão (usar IDS ou IPS?)

flowchart TD
  A[Início] --> B{É ambiente de produção?}
  B -- Sim --> C[Testar em IDS por 48-72h]
  B -- Não --> D[Permitir IPS em ambiente de teste]
  C --> E{Logs estáveis?}
  E -- Sim --> F[Ativar IPS 'inline' gradualmente]
  E -- Não --> G[Ajustar regras e repetir testes]
  D --> H[Habilitar IPS e monitorar]
  F --> I[Monitorar e manter]
  G --> C
  H --> I

Glossário — termos em uma linha

• IPS: Sistema que bloqueia tráfego malicioso em tempo real.
• IDS: Sistema que apenas detecta e alerta sobre tráfego suspeito.
• NFQUEUE: mecanismo do iptables que envia pacotes para usuáriospace (Suricata).
• Inline: modo do Suricata que permite reassembly de fluxo e ação de bloqueio.

Critérios de aceitação

• Suricata intercepta tráfego encaminhado por Vuurmuur/NFQUEUE.
• Regras de teste em local.rules geram entradas em fast.log com ação Drop.
• Serviços suricata e vuurmuur iniciam automaticamente no boot.
• Não há impactos significativos na conectividade legítima após ajustes.

Quando a abordagem falha / limitações

• Alta taxa de tráfego pode exigir tuning de threads e memória do Suricata.
• Regras muito genéricas geram falsos positivos e bloqueios indevidos.
• Sistemas legados com timeout sensível podem quebrar com drops abruptos.

Recursos recomendados

• Suricata User Guide
• Ferramentas de gestão de regras (oinkmaster, pulledpork)
• Vuurmuur user guide

Resumo final

Este guia explica como usar Vuurmuur + Suricata no Fedora 17 para passar de um IDS passivo para um IPS em modo inline. Comece com testes em IDS, monitore logs e só então ative regras de drop controladas. Mantenha backups, valide regras e monitore performance.