OPNsense: Firewall Open-Source com IDS/IPS para PME em 2026

Uma firewall open-source robusta com IDS/IPS integrado era, até há poucos anos, privilégio de grandes empresas com orçamentos para soluções comerciais como Palo Alto ou Check Point. Em 2026, o OPNsense — um fork do pfSense com desenvolvimento mais rápido e interface moderna — tornou isso acessível a qualquer PME portuguesa. Este guia cobre instalação, interfaces, regras, VPN IPsec/WireGuard e IDS/IPS com Suricata, com comandos testados e configurações práticas.

Introdução — OPNsense vs pfSense vs WatchGuard

O OPNsense nasceu em 2015 como fork do pfSense, motivado por divergências na governância do projecto e na adopção de tecnologias modernas. O resultado, quase uma década depois, é uma distribuição FreeBSD independente com:

  • Interface web moderna — em Vue.js, mais responsiva que o pfSense, com pesquisa global e configuração incremental.
  • Modelo de security releases — actualizações mensais sem reinício obrigatório (excepto kernel), comparável a um appliance comercial.
  • IDS/IPS nativo via Suricata — integrado no core, não como plugin externo.
  • WireGuard nativo — desde 2023, via plugin oficial.
  • Sem telemetria comercial — ao contrário de pfSense+, não exige registo na Netgate.

Comparando com as alternativas mais relevantes para uma PME em 2026:

Critério OPNsense pfSense CE WatchGuard Firebox T15
Licença BSD 2-Clause (livre) Apache 2.0 (livre) Comercial (~600 €/ano)
Interface Vue.js moderna Bootstrap clássico Web UI proprietária
IDS/IPS Suricata nativo Suricata/Snort (plugin) Inspecção pro (incluído)
WireGuard Plugin oficial Kernel module (pfSense+) Não suportado
Custo PME (25 utilizadores) 0 € (hardware próprio) 0 € (CE) ou ~400 €/ano (+) ~1 000 €/ano (LSS)

ℹ️ Nota: O OPNsense é a escolha recomendada para PME que pretendem IDS/IPS sem custo de licença. O pfSense CE mantém-se válido, mas o desenvolvimento da comunidade abrandou desde o lançamento do pfSense+. O WatchGuard é sólido quando se quer hardware certificado e suporte comercial, mas o custo anual não se justifica para PME com competências Linux internas.

Instalar OPNsense

A instalação decorre em três fases: descarregar a ISO, instalar em hardware (PC appliance, VM ou mini-PC com duas NICs) e fazer o primeiro boot com configuração de interfaces. A versão actual é a OPNsense 24.7 (LTS até 2026-12).

Descarregar e gravar a ISO

# Descarregar a imagem amd64 (DVD)
wget https://mirror.opnsense.org/OPNsense-24.7-dvd-amd64.iso.bz2
bunzip2 OPNsense-24.7-dvd-amd64.iso.bz2

# Gravar num USB (Linux/macOS)
sudo dd if=OPNsense-24.7-dvd-amd64.iso of=/dev/sdX bs=4M conv=sync

# Em Proxmox: criar VM com 2 GB RAM, 20 GB disco, 2x virtio NIC
# SCSI: VirtIO SCSI single; Network: virtio, bridge=vmbr0/vmbr1

Primeiro boot — configurar interfaces

Após gravar e arrancar, a consola pede para mapear interfaces. Em hardware típico com duas NICs:

# OPNsense console — login inicial
# user: root  password: opnsense

# 1. Assignar interfaces
# LAN  -> igb0  (rede interna 192.168.1.0/24)
# WAN  -> igb1  (router ISP, DHCP)

# 2. Configurar IP LAN (se DHCP cliente não atribuir)
ifconfig igb0 192.168.1.1/24

# 3. Aceder via browser
# https://192.168.1.1
# Login: root / opnsense (alterar imediatamente)

⚠️ Atenção: A VLAN default do OPNsense é a VLAN 1. Se o switch de acesso está configurado com VLANs não-nativas, atribuir explicitamente a VLAN no assignment (ex: igb0.10 para VLAN 10) antes de activar.

Primeira actualização

# Shell OPNsense — actualizar sistema
opnsense-update

# Instalar plugins essenciais
pkg install os-wireguard os-suricata os-theme-rebellion

# Reiniciar para aplicar kernel updates
reboot

Interfaces e Regras

O OPNsense segue a filosofia pf: tudo o que não é explicitamente permitido é negado. As regras aplicam-se por interface, na direcção de entrada (in), e processam-se de cima para baixo. A primeira regra que coincide é a que se aplica. Isto difere do iptables (cadeias INPUT/OUTPUT/FORWARD) e do firewalld (zones): aqui pensa-se por interface e sentido.

Criar uma regra LAN → Internet (HTTP/S)

No menu Firewall → Rules → LAN:

  • Action: Pass
  • Interface: LAN
  • Direction: in
  • Protocol: TCP
  • Source: LAN net
  • Destination: any
  • Destination port: HTTP (80), HTTPS (443)
  • Log: activado (para análise posterior)

Aliases — reutilizar objectos

Em vez de repetir IPs/portos em regras, usa-se Aliases (menu Firewall → Aliases):

# Alias: servidores_web (tipo Host)
192.168.10.10
192.168.10.11
192.168.10.12

# Alias: portas_web (tipo Port)
80
443
8080

# Alias: redes_corporativas (tipo Network)
192.168.1.0/24
192.168.2.0/24
10.0.0.0/16

Depois, nas regras, usa-se o nome do alias em vez de IP/porto. Se um servidor muda de IP, actualiza-se apenas o alias — todas as regras referenciam o nome.

Boa prática: A última regra de cada interface deve ser uma regra de block log para qualquer tráfego não explicitamente permitido. Isto regista tentativas de acesso indevido para análise no IDS/IPS.

VPN IPsec e WireGuard

O OPNsense suporta três protocolos VPN: IPsec (site-to-site e road warrior), WireGuard (mesh moderno, lightweight) e OpenVPN (road warrior clássico). Para PME portuguesas, IPsec site-to-site entre escritórios e WireGuard para acesso remoto é o padrão recomendado em 2026.

IPsec site-to-site (escritório Lisboa ↔ Porto)

# VPN -> IPsec -> Tunnel
# Phase 1 (IKE):
#   Key Exchange version: IKEv2
#   Local: 85.x.x.x (IP WAN Lisboa)
#   Remote: 82.x.x.x (IP WAN Porto)
#   Authentication: Mutual PSK
#   PSK: 
#   Encryption: AES256-GCM
#   Hash: SHA256
#   DH Group: 14 (2048-bit)

# Phase 2 (ESP):
#   Local Network: 192.168.1.0/24
#   Remote Network: 192.168.2.0/24
#   Encryption: AES256-GCM
#   PFS Group: 14
#   Lifetime: 3600s

# Gerar PSK forte
openssl rand -hex 32

WireGuard — acesso remoto para colaboradores

WireGuard é mais simples, mais rápido e mais seguro que IPsec para acesso individual. Configura-se em minutos via plugin:

# Instalar plugin (uma vez)
pkg install os-wireguard

# VPN -> WireGuard -> Local
# 1. Criar instancia "wg0"
#    Listen port: 51820
#    Interface address: 10.10.0.1/24
#    Peer allowed IPs: 10.10.0.0/24

# 2. Adicionar peers (cada colaborador)
#    Public key: 
#    Allowed IPs: 10.10.0.2/32

# 3. Adicionar regra Firewall: Pass wg0
#    Source: wg0 net
#    Destination: LAN net

# Cliente (Linux/macOS) — gerar chaves
wg genkey | tee private.key | wg pubkey > public.key

⚠️ Cuidado: Não expor a porto WireGuard (51820/UDP) directamente à Internet sem limite de taxa. Adicionar um limite em Firewall → Rules → WAN → Advanced → Max states per host (ex: 50). Ataques de força bruta a WireGuard são raros mas existem — limitar reduz risco.

IDS/IPS com Suricata

Suricata é o motor IDS/IPS integrado no OPNsense. Funciona em dois modos: IDS (alerta apenas, regista) e IPS (bloqueia). Para uma PME, começa-se em IDS durante 2-4 semanas para calibrar falsos positivos, depois muda-se para IPS. As regras vêm de feeds gratuitos (Emerging Threats Open) e comerciais (Proofpoint ET Pro, Talos).

Activar Suricata

# Services -> Intrusion Detection -> Administration
# 1. Suricata version: 7 (incluído no OPNsense 24.7)
# 2. Interfaces: WAN, LAN (ambas para visibilidade)
# 3. Pattern matcher: Hyperscan (mais rápido)
# 4. Logs: Eve JSON (formato compatível com SIEM)

# Descarregar regras (cron diário às 03:00)
# Services -> Intrusion Detection -> Rules
#   ET Open Ruleset: activar
#   Update frequency: 24h

# Para activar IPS (após calibração):
# Services -> Intrusion Detection -> Settings
#   IPS mode: Drop (bloqueia em vez de alertar)

Categorias de regras e impacto

Categoria Risco detectado Acção recomendada Falsos positivos
ET scan Pesquisa de portos (nmap, masscan) Drop (IPS) — bloquear fonte Baixo — scanners legítimos raramente
ET malware C&C, beaconing, payloads conhecidos Drop (IPS) — crítica Baixo — assinaturas específicas
ET exploit Exploits públicos (CVE específicos) Drop (IPS) — crítica Médio — testes de pentest podem disparar
ET trojan Tráfego associado a trojans Drop (IPS) Baixo
ET policy Violação de política (P2P, gaming) Alert (IDS) — decisão por política interna Alto — pode bloquear uso legítimo
ET chat Protocolos de chat/messaging Alert (IDS) — auditoria apenas Muito alto — Teams/Slack disparam
ET dns DNS tunneling, exfiltração Drop (IPS) se confirmado Médio — DoH/DoT legítimo dispara

Analisar alertas

# Reports -> Intrusion Detection -> Alerts
# Filtrar por:
#   Severity: 1 (alta), 2 (média), 3 (baixa)
#   Interface: WAN (ataques externos)
#   Time: últimas 24h

# Exportar Eve JSON para SIEM externo
/var/log/suricata/eve.json

# Exemplo — top 10 IPs de origem atacante
jq -r .src_ip /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head

ℹ️ Nota: Manter Suricata em modo IDS durante pelo menos 2 semanas antes de activar IPS. Registar e analisar alertas para identificar falsos positivos (aplicações internas legítimas que coincidem com assinaturas). Excluir IPs internos críticos (servidores de monitorização, gestores de actualização) das regras que geram ruído.