ruancarlosrc/PFSense-Firewall-Lab-2

# 🔥 pfSense Firewall Lab — Regras, NAT, Logs e IDS/IPS (Suricata) ## 🎯 Objetivo Construir um ambiente funcional de firewall perimetral com pfSense, aplicando configurações reais de regras, NAT e detecção de intrusão com Suricata — simulando o nível de controle de rede encontrado em ambientes corporativos monitorados por um SOC. ## 🗺️ Topologia do Lab ┌─────────────────────────────────────────────┐ │ VirtualBox Host (Windows 10) │ │ │ │ ┌──────────────────────────────────────┐ │ │ │ pfSense CE VM │ │ │ │ em0 (WAN) ← NAT Adapter │ │ │ │ em1 (LAN) ← Internal Network │ │ │ │ 192.168.1.1/24 │ │ │ └──────────────┬───────────────────────┘ │ │ │ Internal Network "labnet" │ │ ┌──────────────┴───────────────────────┐ │ │ │ Kali Linux VM │ │ │ │ 192.168.1.100 │ │ │ │ (atacante e monitor) │ │ │ └──────────────────────────────────────┘ │ └─────────────────────────────────────────────┘ **Recursos de hardware utilizados:** - pfSense VM: 512 MB RAM, 8 GB disco - Kali Linux VM: 2 GB RAM (preexistente) - Total consumido: ~2.5 GB RAM ## 📋 Atividades Realizadas ### ✅ Atividade 1 — Setup do pfSense Instalação e configuração inicial do pfSense CE em VirtualBox com duas interfaces de rede: - `em0` — WAN (NAT Adapter) para saída à internet - `em1` — LAN (Internal Network `labnet`) para a rede interna - DHCP configurado na LAN: range `192.168.1.100–200` - Acesso ao WebConfigurator via `http://192.168.1.1` pelo browser do Kali **Evidência:** `Configuraçoes_iniciais_do_pfsense.png` ### ✅ Atividade 2 — Firewall Rules Criação e teste de regras de controle de tráfego na interface LAN, seguindo o princípio **default deny + allow explícito**. **Regras configuradas (em ordem de avaliação):** | # | Ação | Protocolo | Destino/Porta | Descrição | |---|------|-----------|---------------|-----------| | 1 | ❌ Block | IPv4 ICMP | any | Block ICMP LAN to WAN | | 2 | ❌ Block | IPv4 TCP | 23 (Telnet) | Block Telnet LAN to WAN | | 3 | ✅ Pass | IPv4 TCP | 80 (HTTP) | Allow HTTP LAN to WAN | | 4 | ✅ Pass | IPv4 TCP | 443 (HTTPS) | Allow HTTPS LAN to WAN | | 5 | ✅ Pass | IPv4 * | any | Default allow LAN to any | **Testes validados:** - `ping 8.8.8.8` → bloqueado (ICMP rule) - `curl http://example.com` → passou (HTTP rule) - Port scan multi-porta → entradas block/pass visíveis nos logs **Conceito aplicado:** O pfSense processa regras **de cima para baixo** na interface de entrada do tráfego. A primeira regra que bate é executada; se nenhuma bater, default deny. **Evidências:** `Regras_de_firewall_definidas.png` | `Logs_de_trafego_permitido_e_bloqueado_baseado_nas_regras_criadas.png` ### ✅ Atividade 3 — NAT (Network Address Translation) #### Outbound NAT Migração do modo **Automatic** para **Manual Outbound NAT** para exposição das regras geradas automaticamente pelo pfSense: - Tradução da subnet `192.168.1.0/24` para o IP da WAN - Verificado com `curl ifconfig.me` — retorna o IP público da WAN, não o IP interno do Kali #### Port Forwarding Exposição de serviço interno (servidor Python HTTP na porta 8080 do Kali) pela WAN do pfSense: - Regra criada em `Firewall → NAT → Port Forward` - Redirecionamento: `WAN:8080 → 192.168.1.100:8080` - Regra de firewall associada criada automaticamente - **NAT Reflection (Pure NAT)** habilitado para permitir teste a partir da própria LAN **Conceito aplicado:** Port Forwarding é um vetor primário de exposição de superfície de ataque — serviços internos acessíveis externamente. Em um SOC, regras de Port Forward são auditadas regularmente como parte da gestão de superfície de ataque. **Evidência:** `Alterando_configuraçoes_de_outbound_NAT.png` ### ✅ Atividade 4 — Análise de Logs Exploração dos logs nativos do pfSense em dois formatos: #### Normal View (browser) - Filtro por IP de origem (`192.168.1.100`) para isolar tráfego do Kali - Identificação de entradas `pass` (✅) e `block` (❌) por protocolo - Correlação entre regras criadas e entradas de log correspondentes **Leitura de campos nos logs:** Data/Hora | Interface | Ação | Src:SPort → Dst:DPort | Protocolo #### Raw Format (console pfSense) filterlog: 96,,,em1,match,pass,in,4,tcp,192.168.1.100,142.250.79.161,54270,443,S Campos identificados: interface (`em1`), ação (`pass`), protocolo (`tcp`), IP origem, IP destino, porta destino, TCP flags. **Simulação de port scan para análise:** - Tráfego para portas 21, 22, 23, 25, 80, 443, 445, 3389 gerado sequencialmente - Padrão identificado nos logs: múltiplas tentativas de conexão do mesmo IP em sequência → indicativo de **port scan / reconhecimento de rede** **Evidências:** `Analise_de_logs_de_trafego_permitido_e_bloqueado.png` | `Logs_Raw.png` | `Logs_de_trafego_permitido_e_bloqueado_baseado_nas_regras_criadas.png` ### ✅ Atividade 5 — Instalação e Configuração do Suricata (IDS) **Instalação:** `System → Package Manager → Available Packages → suricata` **Ruleset utilizado:** ETOpen Emerging Threats (gratuito, mantido pela Proofpoint) **Modo inicial:** IDS (apenas alertas, sem bloqueio) **Interface monitorada:** LAN (em1) **Categorias habilitadas:** - `emerging-scan` — detecção de port scans - `emerging-malware` — comportamento de malware - `emerging-exploit` — exploits conhecidos **Evidência:** `Instalação_e_configuraçao_do_suricata.png` ### ✅ Atividade 6 — Simulação de Ataque e Análise de Alertas Geração de tráfego malicioso a partir do Kali para acionar as regras do Suricata. **Ferramentas utilizadas:** - `nmap` — port scan e detecção de versões - `nikto` — scanner de vulnerabilidades web - Alvo: `bancocn.com.br` (ambiente legítimo para testes de hacking) **Alertas gerados:** | SID | Prioridade | Classe | Descrição | Ferramenta | |-----|-----------|--------|-----------|-----------| | 1:2024364 | 1 | Web Application Attack | ET SCAN Possible Nmap User-Agent Observed | nmap | | 1:2221010 | 3 | Generic Protocol Command Decode | SURICATA HTTP unable to match response to request | nikto | | — | 2 | Potentially Bad Traffic | Tráfego suspeito detectado | nikto | **Regra do SID 2024364 analisada:** alert http $HOME_NET any -> any any ( msg:"ET SCAN Possible Nmap User-Agent Observed"; flow:established,to_server; http.user_agent; content:"|20|Nmap"; fast_pattern; classtype:web-application-attack; sid:2024364; rev:5; ) **Análise de triagem (IDS vs Firewall):** | Fonte | O que mostra sobre o mesmo evento | |-------|----------------------------------| | Firewall Log | `TCP 192.168.1.100:47522 → 172.67.192.199:443 — PASS` (fato bruto) | | Suricata Alert | `ET SCAN Possible Nmap User-Agent — Priority 1` (contexto e intenção) | O firewall enxerga **pacotes**. O Suricata enxerga **comportamento**. Ambos são necessários para construir a narrativa completa de um incidente. **Evidências:** `Logs_de_portscan_capturado_pelo_suricata.png` | `Detalhes_de_logs_do_suricata.png` | `Visao_dos_logs_gerados_pelo_nmap_e_nikito_no_firewall_e_no_suricata.png` ## 🔑 Principais Aprendizados 1. **Ordem das regras importa** — pfSense processa top-down; regras mal ordenadas criam brechas silenciosas 2. **NAT Reflection** é necessário em topologias com NAT duplo (VirtualBox + pfSense) para testar Port Forwarding internamente 3. **Port Forwarding = superfície de ataque** — cada serviço exposto é um vetor que precisa ser auditado 4. **IDS sem contexto gera ruído** — entender a anatomia de uma regra Suricata é o que transforma um alerta em decisão de triagem 5. **Firewall log + IDS alert = narrativa completa** — um analista SOC usa as duas fontes juntas, não separadas ## 🛠️ Tecnologias e Ferramentas | Ferramenta | Versão | Função | |---|---|---| | pfSense CE | 2.7+ | Firewall / Gateway / NAT | | Suricata | Via package pfSense | IDS/IPS | | ETOpen Emerging Threats | Atualizado 2026 | Ruleset de detecção | | Kali Linux | 2025.4 | Atacante / Monitor | | VirtualBox | — | Hypervisor | | nmap | — | Port scan / reconhecimento | | nikto | — | Scanner de vulnerabilidades web | ## 📁 Evidências | Arquivo | Atividade | Conteúdo | |---|---|---| | `Configuraçoes_iniciais_do_pfsense.png` | Setup | Wizard de configuração inicial | | `Regras_de_firewall_definidas.png` | Firewall Rules | Regras LAN criadas | | `Logs_de_trafego_permitido_e_bloqueado_baseado_nas_regras_criadas.png` | Firewall Rules | Logs pass/block das regras | | `Alterando_configuraçoes_de_outbound_NAT.png` | NAT | Configuração Manual Outbound NAT | | `Analise_de_logs_de_trafego_permitido_e_bloqueado.png` | Logs | Análise de logs de tráfego | | `Logs_Raw.png` | Logs | Formato raw no console do pfSense | | `Instalação_e_configuraçao_do_suricata.png` | Suricata | Interface configurada e rodando | | `Logs_de_portscan_capturado_pelo_suricata.png` | IDS | Alertas de scan detectados | | `Detalhes_de_logs_do_suricata.png` | IDS | Anatomia de regra Suricata | | `Visao_dos_logs_gerados_pelo_nmap_e_nikito_no_firewall_e_no_suricata.png` | IDS | Visão simultânea firewall + Suricata | ## 🗂️ Roadmap Blue Team Este lab faz parte de um roadmap estruturado de 120 dias para a área de Blue Team / SOC: - ✅ **Fase 0** — Redes e Logs - ✅ **Fase 1** — IAM / Active Directory - ✅ **Fase 2** — Firewall ← *este lab* - 🔜 **Fase 3** — SIEM (Wazuh / Elastic Stack / Splunk) - 🔜 **Fase 4** — EDR / XDR - 🔜 **Fase 5** — SOAR / SOC Simulado