[ INFORMATICA ] // 19 Ottobre 2026 // [ 9 MIN READ ]

Fortezza Cibernetica On-Premise: OPNsense High Availability, Graylog SIEM, Zabbix e l’AI Forense Sec-Sentinel

Cyberpunk Security Operations Center con OPNsense HA cluster, Suricata IDS shield e Sec-Sentinel AI core
// ARCHITECTURAL_CORE_SUMMARY

Nel panorama moderno della cybersecurity, la sicurezza perimetrale tradizionale basata su un singolo firewall statico è ormai obsoleta. Per garantire resilienza assoluta, zero downtime e sovranità del dato, la nostra infrastruttura implementa una difesa attiva e stratificata a quattro livelli: un Cluster OPNsense in High Availability (HA) con sincronizzazione CARP/pfsync e convergenza sub-secondo; il motore Suricata IDS/IPS con esportazione EVE-JSON; la sala di controllo SIEM con Graylog e pipeline di parsing Layer 3/4; la correlazione hardware predittiva di Zabbix 7.0 LTS; e al vertice l’agente Sec-Sentinel di OpenClaw, intelligenza artificiale forense on-premise non censurata (Qwen Uncensored) per l’ispezione profonda dei payload malevoli e la sanitizzazione preventiva dei dati personali (PII).

⚡ I Numeri Chiave dell’Infrastruttura di Difesa

< 2 sec
Tempo Convergenza Failover CARP
100%
Stati Sessione Replicati (pfsync)
0 PII
Dati Sensibili Sanitizzati da Sec-Sentinel
3 Livelli
Correlazione Allarmi Zabbix (Warn/High/Disaster)

🗺️ Lo Schema Architetturale di Difesa Distribuita

L’architettura unisce ridondanza hardware e intelligenza software in un unico flusso continuo: dall’accesso pubblico FTTH attraverso il gateway di confine in DMZ fino all’orchestrazione degli agenti autonomi locali.

Fortezza Cibernetica OPNsense e Sec-Sentinel Core

1. La Fortezza Perimetrale: Cluster OPNsense High Availability

Alla base dell’infrastruttura difensiva vi è l’eliminazione sistematica di qualsiasi Single Point of Failure (SPOF). La protezione è affidata a due appliance firewall basate su FreeBSD 15.1 e OPNsense 26.7, strutturate in un cluster attivo-passivo stateful:

Topologia Dual-Node e Sincronizzazione Real-Time

  • Nodo Alpha (fw-core-01 – Master Preferito): advskew 1, IP WAN 172.16.100.11, IP LAN 10.10.1.11.
  • Nodo Beta (fw-core-02 – Backup Preferito): advskew 101, IP WAN 172.16.100.12, IP LAN 10.10.1.12.
  • Interfaccia di Sincronizzazione Dedicata (vtnet2 / opt1): Canale isolato punto-punto 10.99.0.0/24 a latenza sub-millisecondo che veicola due flussi critici:
    • pfsync: Replica istantaneamente ogni sessione aperta nella tabella di stato del kernel (syncok: 1). In caso di crash o manutenzione del nodo master, il nodo secondario acquisisce il traffico senza interrompere download in corso, videochiamate, sessioni SSH o tunnel VPN.
    • XMLRPC Sync: Replica le modifiche a regole, alias di blocco, tabelle NAT e certificati dal Master al Backup, garantendo conformità al 100%.
  • Kea DHCP High Availability: Replica dello stato delle concessioni IP dinamiche via socket dedicato su porta 8111 e sincronizzazione notturna programmata delle prenotazioni statiche.

Virtual IP CARP e Outbound NAT Avanzato

I nodi fisici non comunicano mai direttamente con l’esterno, ma utilizzano indirizzi virtuali condivisi (CARP Virtual IP):

  • CARP WAN VIP (172.16.100.254, vhid 1, vMAC 00:00:5e:00:01:01): Destinazione dell’Exposed Host configurato sul router upstream di confine.
  • CARP LAN VIP (10.10.1.1, vhid 3, vMAC 00:00:5e:00:01:03): Gateway predefinito e resolver DNS per tutti i client e server interni.
  • Advanced Manual Outbound NAT: Tutte le reti interne mascherano il traffico in uscita esclusivamente con il CARP VIP WAN anziché con l’IP fisico del singolo nodo.
  • WireGuard in HA: Il server VPN è vincolato all’evento CARP (carp_depend_on) con la disattivazione mirata del flag reply-to, evitando asimmetrie di routing sui dispositivi mobili e sui client remoti.

2. Il Caso di Studio Ingegneristico: Risoluzione del MAC Leak e Convergenza in < 2 Secondi

Durante il collaudo del cluster è emerso un problema di routing particolarmente insidioso, tipico degli ambienti FreeBSD posti a valle di apparati di accesso SOHO:

La Root Cause del Blackout Inbound

Quando i nodi eseguivano il failover (Nodo Alpha degradato a Backup, Nodo Beta promosso a Master), la navigazione in uscita continuava a funzionare ma tutti i servizi pubblicati su Internet (HTTP/HTTPS 80/443, reverse proxy, VPN) diventavano istantaneamente irraggiungibili.

  • FreeBSD Physical MAC Leak: Nell’eseguire l’Outbound NAT, lo stack di rete di FreeBSD incapsulava i frame Ethernet con il MAC fisico dell’interfaccia di trasmissione (Nodo Alpha: 02:fe:88:11:22:a1), anziché con il Virtual MAC CARP (00:00:5e:00:01:01).
  • Inquinamento ARP del Gateway Upstream: Il router memorizzava nella propria tabella ARP che l’IP virtuale 172.16.100.254 apparteneva al MAC fisico di Nodo Alpha.
  • Scarto su Nodo in Backup: Al momento del passaggio a Master di Nodo Beta, il router continuava a inviare i pacchetti in ingresso a Nodo Alpha. Trovandosi in stato Backup per CARP, Nodo Alpha scartava silenziosamente i pacchetti. Nodo Beta non riceveva alcun frame.

La Soluzione: Syshook di Transizione CARP (50-carp-arp-sync)

Per superare la latenza di aggiornamento della tabella ARP del router (che poteva protrarsi per svariati minuti), è stato sviluppato e registrato su entrambi i nodi uno script syshook in /usr/local/etc/rc.syshook.d/carp/50-carp-arp-sync:

#!/bin/sh
# /usr/local/etc/rc.syshook.d/carp/50-carp-arp-sync
# Hook istantaneo invocato al cambio di stato CARP ($1 = subsys, $2 = event)

SUBSYS="$1"
EVENT="$2"

ROUTER_IP="172.16.100.1"
WAN_VIP="172.16.100.254"
LAN_VIP="10.10.1.1"
LAN_BACKEND="10.10.1.20"

/usr/bin/logger -t carp_hook "CARP transition detected: subsystem=${SUBSYS} event=${EVENT}"

if [ "${EVENT}" = "MASTER" ]; then
    # 1. Forza l'aggiornamento ARP sul router upstream con ping unicast originato dalla CARP WAN VIP
    /sbin/ping -c 4 -S "${WAN_VIP}" "${ROUTER_IP}" >/dev/null 2>&1 &
    # 2. Aggiorna l'ARP sul backend di Reverse Proxy interno
    /sbin/ping -c 2 -S "${LAN_VIP}" "${LAN_BACKEND}" >/dev/null 2>&1 &
    /usr/bin/logger -t carp_hook "CARP MASTER: Triggered ARP refresh pings for ${WAN_VIP} -> ${ROUTER_IP}"
fi

Risultato verificato: Non appena Nodo Beta viene eletto MASTER, trasmette quattro frame ICMP mirati con sorgente CARP VIP verso il gateway. La tabella ARP del router si aggiorna all’istante: il tempo di ripristino dell’intera erogazione dei servizi esposti è sceso a meno di 2 secondi netti.

3. Deep Packet Inspection: Suricata IDS/IPS in Formato EVE-JSON

La protezione perimetrale è potenziata dal motore Suricata IDS/IPS, attivo in modalità promiscua pcap sia su LAN che su WAN per intercettare pattern di attacco a livello applicativo (Layer 7):

  • Ruleset Emerging Threats (ET): Compilazione e aggiornamento continuo dei set di regole ufficiali:
    • emerging-current_events.rules
    • emerging-malware.rules
    • emerging-exploit.rules
    • emerging-scan.rules
  • Standard EVE-JSON: Gli allarmi di Suricata vengono incapsulati nel formato strutturato EVE-JSON (syslog_eve = 1). Ogni alert contiene metadati avanzati: identificativo della regola (SID), categoria della minaccia, metadati TLS, query DNS correlate e payload applicativo, pronto per l’ingestion centralizzata.

4. La Sala di Controllo SIEM: Graylog Pipeline & Threat Intelligence

Tutti i registri di sistema generati dal cluster OPNsense (filterlog e suricata) confluiscono in tempo reale via Syslog RFC 5424 su socket dedicato (porta UDP/TCP 1514 / 5140 su host 10.10.50.15) all’interno del SIEM Graylog.

La Pipeline di Elaborazione Multistadio

  • Stage 0 (CSV Parser): Il processore di Graylog decodifica il formato CSV nativo di filterlog, estraendo con precisione chirurgica interfaccia, azione (pass / block), protocollo L4 (TCP, UDP, ICMP), IP sorgente, IP destinazione, porte e flag TCP.
  • Stage 1 (GeoIP & Threat Tagging): Ogni IP pubblico viene geolocalizzato tramite database MaxMind GeoIP2 e confrontato con elenchi di reputazione per rilevare botnet e scanner malevoli.
  • Stage 2 (Euristica e Anomalie di Flusso):
    • Port Scan Detection: Identificazione automatica di host che contattano più di 25 porte distinte in un intervallo di 60 secondi.
    • Brute Force & Unauthorized Access: Tracciamento di anomalie ripetute verso porte VPN, protocolli di gestione o endpoint esposti in DMZ.
    • Martian & Spoofed IP: Allerta immediata su pacchetti con IP sorgente privato (RFC 1918) transitanti dall’interfaccia WAN.

5. Correlazione Hardware & Allarmistica Predittiva con Zabbix 7.0 LTS

Nel contesto operativo reale, un volume elevato di pacchetti bloccati non indica necessariamente un disservizio: può trattarsi di normale rumore di fondo di Internet. Per scongiurare la fatica da allarme e rilevare tempestivamente veri attacchi di Denial of Service (DoS), l’infrastruttura adotta il template personalizzato Template Security Graylog - OPNsense su Zabbix 7.0 LTS (host 10.10.50.10), gestito dal subagente specializzato di OpenClaw:

Correlazione Multidimensionale tra Sicurezza e Risorse Fisiche

Livello Severità Trigger & Condizione di Rilevamento Correlazione Hardware OPNsense Azione Operativa
Warning 🟡 Singolo blocco o anomalia a bassa intensità CPU < 30%, Stati pf < 40% Logging passivo, nessun allarme invasivo
High 🟠 Port Scan coordinato (>25 porte/60s), spike drop > 300% CPU moderata, incremento rapido stati pf Tagging minaccia, notifica ai canali operativi
Disaster 🔴 Martian IP su WAN, perdita quorum CARP o attacco volumetrico CPU > 90% o Saturazione tabella stati pf > 90% Escalation immediata, blocco dinamico e failover

6. L’Analista Forense On-Premise: Sec-Sentinel in OpenClaw

Al vertice dell’architettura opera Sec-Sentinel, il subagente specialistico del reparto Sistemista di OpenClaw. La sua ragion d’essere risiede nel superamento dei vincoli critici imposti dalle AI commerciali di terze parti:

Perché un’AI Locale Uncensored?

I modelli linguistici ospitati su piattaforme cloud (OpenAI, Anthropic, Google) integrano filtri etici che tendono a bloccare l’elaborazione di frammenti di codice exploit, stringhe esadecimali malevole, tentativi di SQL injection o payload di reverse shell, rispondendo con rifiuti automatici del tipo “Non posso aiutarti con codice malevolo”.

Sec-Sentinel opera on-premise attraverso Arcane (nodo 10.10.50.25:8088) su un modello locale privo di inibizioni analitiche (Qwen-Uncensored):

  • Ispezione Forense Profonda: Esamina senza interruzioni i dump esadecimali e i payload di Suricata estratti da Graylog, classificando la tipologia di exploit (CWE), il vettore di compromissione e fornendo raccomandazioni tecniche dirette.
  • Privacy Gatekeeper & Sanitizzazione PII: Prima che qualunque stralcio di log, diagnostica o rapporto venga condiviso su canali di comunicazione esterni (Telegram, webhook o archivio storico), Sec-Sentinel individua e sostituisce automaticamente indirizzi IP privati, token API, credenziali in chiaro e hash riservati con tag crittografici sicuri (es. [REDACTED_API_KEY], [REDACTED_INTERNAL_IP]).

7. Direttiva Zero-Secret e Validazione Rigorosa

Tutti i componenti dell’ecosistema operano secondo i principi Safe-by-Default e Zero-Secret Policy:

  • Nessuna Mutazione Distruttiva Autonoma: Gli agenti non applicano modifiche arbitrarie a caldo sull’infrastruttura di produzione; ogni modifica o regola di filtraggio segue un flusso strutturato di validazione mediante script offline (validate_security_event.py e audit_opnsense_graylog.py).
  • Knowledge Base Isolate: Ogni subagente mantiene il proprio archivio vettoriale (Qdrant) confinato per evitare contaminazioni di contesto e conflitti di lock.
  • Sovranità Assoluta del Dato: L’intero ciclo di vita dell’informazione — dal transito del pacchetto di rete alla sua dissezione forense da parte dell’AI — rimane confinato all’interno dell’infrastruttura di proprietà, garantendo una protezione inattaccabile contro intercettazioni o violazioni esterne.

⚡ Conclusione: L’Organismo Difensivo Integrato

L’integrazione di OPNsense HA, Suricata, Graylog, Zabbix e Sec-Sentinel trasforma una serie di strumenti eterogenei in un unico organismo difensivo armonico e resiliente. Una barriera che non si limita a respingere gli attacchi, ma li comprende, li isola e si adatta in tempo reale, dimostrando che l’eccellenza nella cybersecurity nasce dalla perfetta sinergia tra rigore ingegneristico e intelligenza artificiale locale.