Guida alla messa in servizio di Defense Fabric

Il ruolo del software

Defense Fabric esegue rilevamento, filtraggio dei pacchetti e gestione delle policy sui vostri server. La capacità locale dipende da questi server e dai loro collegamenti. Non include la capacità upstream del transito IP protetto Peeryx.

Flow Collector è uno strumento gratuito e separato per osservazione e controllo della deviazione. Non sostituisce il motore di filtraggio Defense Fabric. Il transito Peeryx è il servizio di rete fornito separatamente che può filtrare il traffico a monte dell’infrastruttura.

Server e sistema operativo

L’installer attuale è destinato a Debian 12; il plugin di filtraggio distribuito richiede x86-64. La licenza associata alla macchina richiede TPM 2.0. L’installer vincola VPP e i suoi plugin alla versione 25.10-release: non sostituire questa ABI VPP durante un aggiornamento del sistema operativo.

• Predisporre accesso di gestione indipendente, DNS funzionante, orologio corretto e HTTPS in uscita per registrazione, controlli di licenza e aggiornamenti firmati.
• Verificare insieme CPU, disposizione della memoria, collocazione NUMA, larghezza del collegamento PCIe, codice esatto della scheda, firmware, driver e ottiche. Il nome della famiglia ConnectX non è una convalida di compatibilità.
• Separare la gestione del server dalle interfacce di traffico. Riservare CPU, memoria e spazio sufficienti al motore, alla raccolta dei flussi e alla conservazione delle evidenze.

Dimensionamento e prove di prestazioni

Considerare insieme Gbit/s e Mpps. Ethernet a 100 Gbit/s con frame da 64 byte raggiunge teoricamente circa 148,81 Mpps includendo preambolo e intervallo tra frame. È un calcolo della capacità della linea, non un risultato di filtraggio. Due porte non garantiscono il raddoppio della capacità da un’estremità all’altra.

Le configurazioni hardware pubblicate sono candidate alla qualificazione. Non è pubblicato un rapporto di prestazioni riproducibile per queste configurazioni. Provare la macchina effettiva con numero di regole e dimensioni dei pacchetti previsti, traffico legittimo simultaneo e mitigazione attiva. Registrare perdite, latenza e recupero oltre al throughput.

Licenze, porte e server

La licenza base include una porta 10G. Le porte acquistate costituiscono un pool condiviso tra i server gestiti dalla licenza. Installare un secondo server non duplica il pool. Assegnare velocità e numero di porte necessari a ogni server prima dell’uso a pagamento. Il limite di gestione è di 128 server per licenza.

La prova di 14 giorni non impone quote software al numero di porte o alla velocità dichiarata. Restano validi limiti fisici, qualificazione hardware e requisiti di attivazione della rete. Aggiungere un server non riavvia la prova.

Validità della licenza, identità del server e disponibilità del routing sono controlli separati. Dopo la prova, il funzionamento in licenza richiede pagamento e diritti d’uso validi. L’area clienti riporta scadenza e stato del rinnovo applicabili.

Installazione e registrazione

Iniziare dalla pagina Defense Fabric del proprio account. Creare o selezionare l’abbonamento, aggiungere il server e generare il token di registrazione monouso a breve scadenza. Seguire le istruzioni associate a quel server e mantenere riservati identità e token.

L’installer controlla Debian 12, disponibilità del TPM e versione richiesta di VPP. Un piano dati separato già attivo richiede una migrazione: preparare un piano di manutenzione invece di installare sopra di esso. La verifica della firma e una registrazione riuscita non dimostrano che il traffico dei clienti sia protetto.

• Annotare la versione installata e controllare l’esito dell’installazione.
• Confermare separatamente collegamento al portale, motore, porte assegnate e contatori delle interfacce.
• Mantenere il server in osservazione finché inoltro e percorso di ritorno non sono stati provati.

Interfacce e ritorno del traffico pulito

Identificare l’ingresso del traffico da filtrare e l’interfaccia logica separata che restituisce il traffico pulito. Verificare VLAN, indirizzi, gateway, MTU e raggiungibilità dei next hop sia sul router sia sul server di filtraggio. Non confondere i contatori della gestione Linux con quelli delle porte di filtraggio.

Evitare che il traffico deviato ritorni all’ingresso non filtrato creando un loop. Gli indirizzi del piano di controllo e del gateway pulito devono restare fuori dagli intervalli di destinazione protetti. Misurare traffico reale in entrambe le direzioni prima di considerare pronto il percorso.

Inline, deviazione BGP o modalità ibrida

Inline: il traffico attraversa continuamente il filtro locale. Verificare il comportamento in caso di guasto a server, interfaccia o alimentazione. La sola installazione software non crea un bypass fisico.

Deviazione BGP: il router inoltra le destinazioni attaccate selezionate verso il next hop di filtraggio. Definire filtri di import/export e community espliciti. Verificare annunci, installazione nella FIB, ritorno pulito e ritiro. Ritardi di esportazione e convergenza influiscono sui tempi di risposta.

Ibrida: affiancare il transito protetto Peeryx al filtraggio locale quando serve mitigazione a monte. Il transito richiede attivazione propria, prefissi autorizzati e percorso di consegna collaudato. L’acquisto della licenza non modifica da solo il routing upstream.

BGP, FlowSpec e RTBH

Impostare router ID, indirizzi locali e del peer, ASN, next hop di filtraggio raggiungibile e community di deviazione concordata. L’interruttore di routing nel portale autorizza sessioni e annunci gestiti dall’agente. Salvare una bozza non conferma che il router abbia installato la rotta prevista.

FlowSpec esporta regole selettive a monte solo quando è abilitato, la simulazione è disattivata e la relativa famiglia BGP è stabilita. Iniziare in dry-run, ispezionare le regole generate e provare capacità e limiti del router. Il portale limita a 50 il numero di regole simultanee.

RTBH è l’ultima risorsa: scarta tutto il traffico verso la destinazione interessata, compreso quello legittimo. Soglia, tempo di persistenza e durata di validità fino al ritiro sono controlli distinti. Provare anche il recupero.

sFlow, NetFlow e IPFIX

Attivare la ricezione su un indirizzo raggiungibile dagli exporter autorizzati, preferibilmente su rete privata o VPN. La porta predefinita è UDP 6343. Usare la stessa porta sui due lati e limitare l’elenco degli exporter ammessi. Non esporre a Internet un collector senza restrizioni.

Controllare campionamento e timeout degli exporter prima di scegliere le soglie. sFlow include il rapporto di campionamento; il moltiplicatore configurato si applica a NetFlow/IPFIX quando l’exporter non lo fornisce. La finestra di raccolta è configurabile da 5 a 60 secondi.

Confrontare le velocità stimate con i contatori delle interfacce e verificare l’età dei dati. L’assenza di esportazioni non prova che traffico o attacco siano cessati. Catture di pacchetti e stime dei flussi rappresentano osservazioni diverse.

Prefissi, soglie e recupero

Le policy usano blocchi IPv4 /24 registrati e relative eccezioni /32. Valutare il traffico normale prima di applicare un profilo. In questa versione le soglie di rilevamento per protocollo e destinazione sono espresse in PPS. I parametri Gbit/s di FlowSpec e RTBH riguardano le loro decisioni di capacità separate.

Monitor osserva senza deviazione per attacco. Automatic devia durante gli attacchi rilevati. Permanent mantiene attivo il percorso di filtraggio validato. Impostare la soglia di uscita sotto quella di ingresso e un tempo di mantenimento per evitare continue variazioni di rotta durante attacchi intermittenti.

Un profilo carica soglie per protocollo. Non è un elenco di applicazioni consentite. Un profilo più severo non è automaticamente adatto a una rete più trafficata.

Regole adattive e protezione TCP/UDP

Il rilevamento adattivo può valutare firme in osservazione o applicare le regole generate in modalità attiva. Esaminare la firma registrata e gli effetti sul traffico legittimo prima di escluderla o cambiare backend. Il backend deve corrispondere alla versione installata e all’hardware qualificato.

SYN proxy verifica l’apertura delle connessioni e richiede un percorso simmetrico collaudato. SYN challenge è previsto per il caso asimmetrico supportato. Le due funzioni non sono intercambiabili; il portale impedisce combinazioni incompatibili. Anche la verifica specifica SYNACK richiede il percorso simmetrico documentato.

Le quote per sorgente limitano i pacchetti UDP o il totale SYN/SYNACK per IP sorgente sui prefissi abilitati. Utenti dietro NAT, VPN o proxy possono condividere un indirizzo. Considerare il loro traffico normale complessivo nella scelta della quota.

Eccezioni e firewall dopo il filtraggio

Usare eccezioni /32 per host specifici dentro un /24 registrato. Mantenerle circoscritte e documentate. Una regola accept opera nello stadio firewall successivo al filtraggio: non recupera pacchetti già scartati e non garantisce l’esclusione da tutte le altre verifiche.

Il portale ammette fino a 20 priorità firewall ordinate per prefisso. Verificare protocollo, intervallo sorgente, porte di destinazione e unità delle velocità prima di applicare. I selettori di porta TCP/UDP non sono pertinenti a ogni protocollo IP.

Portale, rapporti e API

Valutare separatamente collegamento al portale, motore, stato BGP e disponibilità della protezione. Un agente connesso o processo attivo non equivale a un test di inoltro riuscito. Le statistiche sono campionate; un dato vecchio va indagato, non interpretato come traffico nullo.

Storico degli attacchi, regole registrate e file PCAP, ZIP o PDF disponibili aiutano l’analisi. Conservazione e campionamento limitano ciò che è ricostruibile. Un’esportazione non è necessariamente una cattura completa dell’attacco.

Consultare la specifica OpenAPI pubblica per operazioni e autorizzazioni disponibili. L’autenticazione è obbligatoria: limitare i token ad account e permessi necessari. Le scritture delle policy usano revisioni e restituiscono uno stato di applicazione in attesa. Controllare il nodo prima di considerare attiva la modifica. Non automatizzare tramite interfacce interne private del portale.

Più server ed ECMP

Una licenza condivisa e un secondo server non creano replica automatica dello stato o alta disponibilità. Definire rilevamento guasti, preferenze delle rotte, ritiro e recupero per l’intera architettura. Provare ogni guasto separatamente.

Il progetto supportato con secondo collegamento usa iBGP direttamente connesso con lo stesso ASN e VLAN separate per traffico non filtrato e pulito. Richiede Fabric 2.8.0 o successivo. Ogni sessione usa il proprio next hop locale. ECMP distribuisce i flussi; un singolo flusso può restare su un solo collegamento.

SYN proxy e SYNACK challenge non sono qualificati per questa modalità a doppio percorso. Due collegamenti 100G non garantiscono 200 Gbit/s di filtraggio.

Aggiornamenti e ripristino della configurazione

Usare il flusso di aggiornamento firmato disponibile nel portale. Pianificare una finestra di manutenzione: l’aggiornamento può riavviare il motore di filtraggio. Confermare la versione prevista e mantenere un accesso indipendente prima di iniziare.

L’updater verifica la versione, conserva la configurazione e prepara file di recupero. Se l’installazione fallisce, esaminare diagnostica e stato ripristinato. Un rollback non dimostra che tutti i percorsi di rete siano tornati operativi.

Prima di modificare policy, conservare la configurazione pertinente e confrontare le modifiche previste. Tenere riservati backup e credenziali. Validare la policy ripristinata sul software in esecuzione prima di inviarle nuovamente traffico deviato.

Verifiche di accettazione in produzione

Concordare test e condizioni di rollback prima di deviare servizi attivi. Usare traffico che si è autorizzati a generare e una destinazione di test controllata.

• Baseline: confrontare traffico normale, contatori, perdite e raggiungibilità delle applicazioni con protezione disattivata e attiva.
• Rilevamento: provare un evento circoscritto e verificare che interessi solo destinazione, regola e rotta previste.
• Recupero: interrompere l’evento, attendere il tempo configurato e confermare ritiro delle regole e inoltro normale.
• Guasti: provare separatamente perdita dell’exporter, di BGP e del nodo di filtraggio. Verificare il percorso effettivo e se il traffico passa o viene bloccato in caso di guasto.
• Registrare versione, server, NIC, dimensioni dei pacchetti, numero di regole, campionamento, durata, perdite e latenza. Conservare evidenze sia del funzionamento sia del rollback.

Individuare il livello del guasto

Nessun contatto con il portale: verificare rete di gestione, DNS, orologio, HTTPS, identità e licenza. Non modificare BGP in produzione solo per ripristinare la connessione di gestione.

Motore attivo senza traffico protetto: controllare interfacce di filtraggio, VLAN, next hop e contatori RX/TX reali. Verificare FIB del router e ritorno pulito indipendentemente dallo stato della sessione BGP.

Mitigazione inattesa: confrontare traffico normale misurato, campionamento, profilo e regola registrata. Modificare una bozza salvata, esaminare la modifica e applicarla consapevolmente. Raccogliere diagnostica prima di riavviare processi o rimuovere rotte.

Limiti noti

Questa guida descrive la versione distribuita Debian 12/x86-64 e il flusso di protezione IPv4. Non certifica altri sistemi operativi, NIC arbitrarie, equivalenza delle policy IPv6, failover senza perdite o uno specifico risultato in Mpps.

Il filtraggio locale non recupera banda già saturata a monte. Il transito Peeryx è un servizio separato che consente di anticipare il punto di filtraggio. Flow Collector può supportare un progetto on-demand verificato separatamente.

Funzioni SYN, ECMP e routing automatico hanno requisiti di compatibilità propri. Una combinazione non provata richiede qualificazione: non è un servizio già attivo.