Controllare Spoof Protection e DoS Settings

Spoof Protection e DoS Settings rientrano tra le classiche funzioni di hardening di un Sophos Firewall. Le funzionalità riducono i pacchetti semplici, rumorosi o ovviamente errati prima che diventino rumore inutile nei log, nelle regole o nei servizi pubblicati. Allo stesso tempo queste impostazioni non costituiscono una protezione magica contro ogni tipo di attacco.

L’articolo classifica le funzioni come un accurato rafforzamento di base: comprendere prima la progettazione della rete e i percorsi di ritorno, quindi attivare, testare e controllare i log. La distinzione è particolarmente importante: queste funzioni completano le regole del firewall correttamente configurate, IPS, Threat Feeds, WAF e il logging. Non sostituiscono questi elementi costitutivi.

Breve spiegazione

Spoof Protection controlla se i pacchetti con un indirizzo di origine plausibile arrivano sull’interfaccia prevista. Ad esempio, se un pacchetto con un indirizzo di origine interno appare dalla direzione di Internet, ciò è sospetto nella maggior parte dei progetti. DoS Settings, d’altro canto, rispondono a determinati modelli di Flooding o di attacco alla connessione, ad esempio quantità notevoli di traffico SYN, UDP o ICMP.

In SFOS 22 e SFOS 23 il percorso in WebAdmin è:

Intrusion prevention > DoS & spoof protection

Le impostazioni di questa pagina intervengono sull’elaborazione dei pacchetti. Prima di selezionare Apply o Save, annotare i valori esistenti e definire una procedura di rollback.

Cosa fanno le funzioni

• Spoof Protection: scarta i pacchetti con un IP sorgente non plausibile, riduce i tentativi di spoofing semplici e rende più visibili i pacchetti instradati in modo errato. La funzione non sostituisce però una corretta pianificazione di zone, interfacce e routing.
• DoS Settings: limitano i pattern di flooding semplici e consentono di rilevare prima attacchi con elevati volumi di traffico o configurazioni errate. La funzione non sostituisce però la protezione DDoS del provider, una WAF o un’architettura upstream correttamente dimensionata.

In pratica, queste funzioni sono particolarmente interessanti come rafforzamento di base. Il vantaggio è ridurre le ovvie sciocchezze. Nei veri attacchi DDoS volumetrici, la connessione Internet è spesso già al completo prima che il firewall possa rispondere in modo significativo. Quindi è necessaria la protezione da parte del provider, lo scrubbing a monte o un’altra architettura.

Non confondere i tipi di protezione

Nella stessa schermata sono presenti diversi meccanismi che rispondono a domande operative differenti.

• Enable spoof prevention: attiva Spoof Prevention per le zone selezionate. Zone o percorsi di ritorno interpretati in modo errato possono interessare il traffico legittimo.
• Trusted MAC e coppie IP-MAC: gli indirizzi MAC o le combinazioni IP-MAC note vengono considerati attendibili. Dispositivi mobili, cambi DHCP o virtualizzazione possono creare lavoro di manutenzione.
• DoS settings: impostano soglie e flag per flood SYN, UDP, TCP o ICMP/ICMPv6. Valori troppo rigidi disturbano picchi di carico legittimi, scansioni, monitoring o VoIP.
• DoS bypass rule: esclude determinato traffico dai DoS Settings di WebAdmin. Eccezioni ampie indeboliscono questa protezione. Per l’interazione con le policy CLI, vedere le precisazioni sulla versione nella sezione CLI.

Questa distinzione è importante, perché un errore dopo l’attivazione non è automaticamente un problema di una regola firewall. A volte la soglia DoS è troppo aggressiva, a volte un binding IP-MAC non è più corretto e, in altri casi, Spoof Protection indica un vero problema di routing o VLAN.

Quando Spoof Protection ha senso

Spoof Protection si adatta particolarmente bene a reti chiaramente segmentate in cui le reti di origine, le interfacce e i percorsi sono chiaramente pianificati. Quanto più chiara è la struttura della rete, tanto più facile è valutare se un indirizzo sorgente su un’interfaccia è plausibile.

Applicazioni utili:

• Internet WAN su cui non dovrebbero apparire fonti interne RFC1918.
• DMZ o zone server con reti di origine e destinazione chiaramente definite.
• Zone client, guest o IoT nelle quali non devono comparire come sorgente altre reti interne.
• Luoghi in cui il percorso, VLAN e zone sono chiaramente documentati.
• Ambienti nei quali gli scarti di pacchetti devono poter essere ricostruiti successivamente tramite Packet Capture e log.

Le cose diventano più difficili con routing asimmetrico, reti di transito complesse, percorsi di migrazione temporanei, VLAN documentate in modo errato o più firewall nello stesso percorso dati. Un flusso di dati legittimo può sembrare uno spoofing, sebbene la progettazione del routing o il percorso di ritorno siano in realtà impuri.

Controllo prima dell’attivazione

Spoof Protection e DoS Settings non devono essere attivati ​​alla cieca in un ambiente di produzione. Dovrebbe essere chiaro in anticipo quali reti e servizi sono interessati.

Punti di controllo importanti:

1. Documentare zone, interfacce, VLAN, bridge e LAG.
2. Controlla le route statiche, le route SD-WAN, le route VPN e i percorsi asimmetrici.
3. Identificare i servizi pubblicati tramite DNAT o WAF.
4. Nota servizi critici come VoIP, monitoraggio, backup, scansioni, VPN e connessioni al sito.
5. Preparare la registrazione e la valutazione centrale se gli eventi devono essere tracciabili in un secondo momento.
6. Imposta la finestra di manutenzione o l’area pilota per la prima attivazione.
7. Controllare le DoS bypass rules, le voci Trusted MAC e i binding IP-MAC esistenti.
8. Annotare il tipo di controllo spoof e le zone selezionate, Restrict unknown IP on trusted MAC, tutti i flag Apply, Packet Rate, Burst Rate, eccezioni e binding esistenti. Questi valori serviranno per il rollback.

Se le normali regole del firewall sono difficili da comprendere, è necessario prima ripulire la regola e lo stato del routing. Per le singole connessioni di test, Test della regola firewall con Log Viewer, Policy Test e Packet Capture è un inizio migliore.

Attivare Spoof Protection con cautela

Un approccio graduale ha senso per Spoof Protection. Dovresti proteggere prima le aree la cui architettura di rete è più chiara e meglio compresa, non tutte le zone speciali immediatamente.

Processo pratico:

1. Salvare la configurazione corrente o almeno documentare le impostazioni interessate.
2. In Intrusion prevention > DoS & spoof protection, selezionare Enable spoof prevention, il tipo di controllo necessario e, inizialmente, solo zone ben documentate.
3. Selezionare Apply.
4. Esegui test di connessione pianificati: accesso a Internet, VPN, servizi pubblicati, server centrali, monitoraggio.
5. Controllare in Log Viewer e Packet Capture la presenza di pacchetti scartati inattesi.
6. In caso di scarti anomali di pacchetti legittimi, non ricorrere subito a eccezioni ampie, ma verificare prima routing, Source-IP e interfaccia.

Un errore frequente è trattare Spoof Protection come una semplice casella di controllo per la sicurezza. In realtà, la funzione verifica un presupposto relativo all’architettura di rete. Se tale presupposto non è corretto, non significa necessariamente che Spoof Protection sia errata. Spesso, in questi casi, un’interfaccia, una route, una VLAN o un percorso di ritorno non sono configurati come previsto.

Capire correttamente IP, MAC e coppie IP-MAC

Sophos distingue diversi tipi di verifica. IP spoofing scarta il traffico se l’IP sorgente non corrisponde alla tabella di routing o se il pacchetto non proviene da una sottorete direttamente connessa. MAC filter scarta i pacchetti il cui indirizzo MAC non è registrato come Trusted MAC; a questo scopo deve essere configurato almeno un Trusted MAC Address. Il filtro MAC non viene applicato ai pacchetti DHCP. IP-MAC pair filter verifica se la combinazione in ingresso di indirizzo IP e indirizzo MAC corrisponde a una coppia nota.

Questo è utile in reti statiche e chiaramente controllate, ma negli ambienti dinamici può generare rapidamente lavoro di manutenzione. DHCP, roaming Wi-Fi, macchine virtuali, hypervisor, cluster, NAC, docking station o sostituzione di dispositivi possono produrre cambi MAC/IP legittimi. Per queste reti è meglio osservare prima e creare binding solo dove la realtà operativa è sufficientemente stabile.

Esempio con un core switch: lo switch gestisce il routing inter-VLAN e utilizza Sophos Firewall come gateway predefinito. Un client nella VLAN 1 con 10.10.10.5 invia una richiesta Internet che arriva all’interfaccia LAN del firewall. Il fatto che lo switch conosca le VLAN non rende le relative sottoreti direttamente connesse al firewall. Prima dell’attivazione, verificare sul firewall la route per 10.10.10.5 e le sottoreti direttamente connesse. Se le condizioni documentate per IP spoofing non sono soddisfatte, la richiesta può essere scartata nonostante l’indirizzo del client sia legittimo. Un solo test di accesso WAN non sostituisce questa verifica del percorso interno.

Per verificare la tabella locale dei nodi adiacenti e creare consapevolmente un’associazione statica tra IP, MAC e interfaccia, consultare Controllare la cache dei nodi adiacenti ARP e NDP.

È importante distinguere i casi: se non è configurata alcuna Trusted MAC, il IP-MAC pair filter attivo consente tutto il traffico attraverso questo controllo. Un elenco Trusted MAC vuoto non equivale a un pacchetto che non corrisponde a un binding IP-MAC configurato. In presenza di voci, il filtraggio dipende dai binding e da Restrict unknown IP on trusted MAC; l’assenza di una coppia corrispondente non comporta sempre un blocco indipendentemente da questa opzione. La protezione richiede binding mantenuti e testati.

L’opzione Restrict unknown IP on trusted MAC è particolarmente restrittiva: quando IP-MAC pair filter è attivo nelle zone selezionate e l’opzione è selezionata, Sophos descrive lo scarto dei pacchetti provenienti da un Trusted MAC senza associazione IP se l’IP è sconosciuto. «Sconosciuto» significa qui: nessuna voce corrispondente nella tabella di routing oppure nessuna provenienza da una sottorete direttamente connessa. Questo migliora la sicurezza nelle reti controllate, ma può rappresentare un ostacolo con DHCP, migrazioni e cambi temporanei di IP.

Per l’opzione non selezionata, la guida generale di SFOS 22 e SFOS 23 indica che sono consentiti un Trusted MAC con qualsiasi IP e un Trusted MAC senza associazione IP. La procedura separata per Add afferma invece in termini generali che, in presenza di un’associazione, viene accettata solo una coppia IP-MAC corrispondente. Queste affermazioni non devono essere combinate per dedurne una garanzia di blocco incondizionata. Controllare congiuntamente tipo di verifica, zona, associazione e casella di controllo, e verificare nella build installata i casi consentiti e non corrispondenti necessari; se l’effetto non è chiaro, chiarirlo con Sophos Support prima dell’impiego in produzione.

Per creare una singola voce Trusted MAC, aprire Intrusion prevention > DoS & spoof protection e usare Add nella sezione Spoof protection trusted MAC. Dopo aver inserito l’indirizzo MAC, selezionare Static e indicare uno o più indirizzi IPv4 o IPv6 separati da virgole, oppure selezionare DHCP per associare automaticamente gli indirizzi assegnati. Dopo Save, verificare un caso IP-MAC corrispondente e uno volutamente diverso; la sola presenza della voce non conferma che il filtro venga applicato.

SFOS 23 documenta le opzioni di ricerca e filtro nell’elenco Trusted MAC per trovare una voce da mantenere. Questa vista non modifica il filtraggio dei pacchetti e non implica che SFOS 22 sia privo di tali controlli.

Importare le Trusted MAC in modo controllato

È possibile importare più Trusted MAC sotto Intrusion prevention > DoS & spoof protection mediante un file .csv o .txt. Nell’area Spoof protection trusted MAC, selezionare Import, scegliere il file con Browse e caricarlo con Upload file. L’indirizzo MAC e IP Association devono essere indicati in ogni riga. La prima riga deve contenere esattamente MAC Address,IP Association,IP Address. Per IP Association sono ammessi Static, DHCP, DHCPv6 e None. Con Static è possibile indicare al massimo 16 indirizzi IP per MAC, separati da virgole; con le altre tre associazioni il campo IP rimane vuoto.

Il seguente esempio di formato mostra associazioni statiche IPv4 e IPv6 e le tre associazioni senza campo IP:

MAC Address,IP Association,IP Address
02:00:00:00:00:01,Static,192.0.2.10,192.0.2.11
02:00:00:00:00:02,Static,2001:db8::10,2001:db8::11
02:00:00:00:00:03,DHCP
02:00:00:00:00:04,DHCPv6
02:00:00:00:00:05,None

Gli indirizzi MAC e IP sono segnaposto fittizi, non dispositivi da autorizzare. Sostituire ogni riga con il MAC effettivo del dispositivo e l’associazione scelta consapevolmente. Static è adatto a indirizzi fissi noti, mentre DHCP e DHCPv6 sono adatti all’associazione automatica tramite lease; None non contiene alcuna associazione IP e quindi non sostituisce una verifica statica della coppia.

Durante l’importazione, il firewall scarta l’intera voce se contiene un indirizzo MAC non valido, una IP Association non valida o un indirizzo IP non valido. Occorre distinguere questo caso dai valori IP inseriti nonostante l’associazione sia DHCP, DHCPv6 o None: questi valori IP vengono scartati; ciò non implica automaticamente la rimozione dell’intera voce MAC. Importare quindi inizialmente poche righe pilota, controllare poi le associazioni visibili e testare un caso IP-MAC consentito e uno intenzionalmente errato. Il completamento del caricamento non dimostra ancora che la logica di filtraggio desiderata sia effettivamente applicata.

Pianificare le DoS Settings

DoS Settings dovrebbe adattarsi all’ambiente. Raramente ha senso adottare i valori di un altro esempio senza verificarli. Un sito con pochi utenti, VoIP e un piccolo WAN si comporta in modo diverso rispetto a un data center, una rete scolastica o un sito con scansioni e monitoraggio regolari.

Prima di modificare le impostazioni, rispondi a queste domande:

• Quali servizi pubblici sono esposti?
• Sono presenti picchi di carico, scansioni, monitoraggio o controlli di integrità legittimi?
• Vengono utilizzati VoIP, VPN, WAF, DNAT o trasferimenti di file di grandi dimensioni?
• Per quali protocolli va attivato il flag Apply, affinché il firewall scarti e registri effettivamente i superamenti della soglia?
• Chi controlla i log dopo l’attivazione?

DoS Settings può contribuire a limitare semplici schemi di flooding. Tuttavia, soglie troppo rigide possono incidere anche sul traffico legittimo. È necessario prestare particolare attenzione a VoIP, ai sistemi di monitoraggio, ai processi di backup, alle scansioni di vulnerabilità e ai servizi pubblicati molto utilizzati.

I tipi di flood comportano carichi diversi: SYN flood genera molte connessioni TCP semiaperte; il server risponde con SYN-ACK, ma non riceve la risposta conclusiva. TCP flood indica in generale un’elevata frequenza di pacchetti TCP. UDP flood può sovraccaricare l’host di destinazione con verifiche delle porte e risposte ICMP per porte non utilizzate. ICMP/ICMPv6 flood riguarda un numero elevato di Echo Requests e può consumare larghezza di banda. Nel caso di DDoS, il carico proviene in modo distribuito da più dispositivi; una singola soglia per Source non risponde quindi alla stessa esigenza di una soglia per Destination.

Nella schermata sono inoltre rilevanti questi flag:

• Dropped source routed packets: scarta i pacchetti il cui percorso è specificato dal mittente. In questo modo viene limitata questa possibilità di manipolazione del routing.
• Disable ICMP/ICMPv6 redirect packet: non accetta redirect ICMP o ICMPv6. I router downstream possono inviare tali messaggi anche legittimamente per indicare una route migliore o attiva; l’opzione modifica quindi un presupposto del routing e non soltanto il rilevamento degli attacchi.
• ARP hardening: consente ARP Replies solo se l’IP sorgente e l’IP di destinazione si trovano nella stessa sottorete. Sophos descrive questa funzione come protezione contro ARP Flood e ARP Poisoning.

Queste opzioni costituiscono misure utili di hardening di base, perché possono ridurre le manipolazioni del comportamento di routing o ARP. È comunque opportuno testarle dopo l’attivazione, soprattutto nelle reti con router downstream, segmenti meno recenti o architetture Layer 2 non comuni.

Per le soglie di WebAdmin sono importanti due termini:

• Packet rate: numero di pacchetti che un host può inviare o ricevere al minuto prima che il traffico venga scartato.
• Burst rate: numero di pacchetti inizialmente consentiti senza controllare il Packet Rate. In seguito possono essere tollerati picchi brevi e occasionali oltre il Packet Rate, ma non superamenti frequenti o prolungati.

L’Apply flag decide se il limite configurato viene realmente applicato al protocollo. Valori troppo alti servono a poco. Valori troppo bassi bloccano picchi legittimi. I valori vanno quindi allineati al traffico reale, ai servizi pubblicati e alle finestre di manutenzione note.

Per una baseline attendibile, registrare prima i normali picchi e i carichi eccezionali pianificati. Scegliere quindi il valore di ogni protocollo in base al picco legittimo misurato e alla capacità del servizio protetto: Sophos non indica un valore di produzione universale. Dopo ogni modifica, eseguire un solo test di carico definito e confrontare Traffic dropped. Il contatore è cumulativo dall’ultimo riavvio del firewall, quindi annotare anche l’ora del test e il valore iniziale.

Leggere correttamente lo stato DoS

Sotto Intrusion prevention > DoS attacks, SFOS mostra in tempo reale per quale Source o Destination viene applicata una soglia e quanti pacchetti sono stati scartati. Fare clic sul tipo di attacco per aprire i dettagli; anche il collegamento di stato da DoS & spoof protection conduce a questa vista. Dopo un rilevamento, la limitazione si applica inizialmente per dieci secondi. Se a quel punto l’attacco è terminato, la limitazione viene rimossa. Se continua, il firewall azzera questo contatore ciclicamente ogni dieci secondi e continua ad applicare la limitazione. Un nuovo attacco dalla stessa Source o verso la stessa Destination azzera nuovamente il contatore e riattiva la limitazione. Quando l’attacco termina, i dati scompaiono dopo 30 secondi. Uno stato vuoto non dimostra quindi che in precedenza non si sia verificato alcun evento DoS; per l’analisi retrospettiva sono necessari gli eventi registrati nei log.

Le soglie di WebAdmin si applicano per Source o Destination, non come somma complessiva indistinta di tutti gli host. Un esempio puramente esplicativo con Burst rate 100: i primi 100 pacchetti vengono inizialmente consentiti senza verifica della Packet rate; successivamente viene confrontata la frequenza. Al di sotto della frequenza configurata il traffico viene accettato, al di sopra può essere scartato. 100 non è un valore consigliato per la produzione.

Non equiparare la sequenza dell’esempio al timer di stato: la guida generale di SFOS 22 e SFOS 23 definisce questa sequenza un tentativo di ARP Flood e descrive ulteriori pacchetti scartati e registrazioni nei log se il pacchetto successivo della stessa Source arriva entro 30 secondi. Descrive la riammissione del traffico se è trascorso più tempo dal pacchetto precedente, ma esclude esplicitamente l’inserimento automatico nella Allow List per il solo fatto che siano trascorsi 30 secondi senza traffico. La guida separata sullo stato DoS descrive invece la limitazione ciclica di dieci secondi illustrata sopra. Questi non sono tempi universali affidabili di riammissione o attesa per ogni tipo di flood. Non dedurre la riammissione basandosi soltanto su un timer: valutare congiuntamente tipo di attacco, stato in tempo reale, log e un flusso di test legittimo chiaramente delimitato; chiarire con Sophos Support i comportamenti non spiegati.

Usare le firme DDoS solo sui modelli supportati

Sophos offre firme DDoS solo su XGS 5500 e firewall di capacità superiore. Su un modello supportato, la procedura è la seguente:

1. In Intrusion prevention > IPS policies > Add, creare una IPS Policy dedicata con un nome univoco a scelta e salvarla con Save.
2. Per questa Policy già salvata, selezionare Edit, quindi Add e inserire un nome univoco per la regola.
3. Selezionare Select all, inserire ddos in Smart filter e applicare il filtro premendo Invio. Impostare deliberatamente Action su Drop packet.
4. Salvare prima la regola con Save e poi la Policy che la contiene con il secondo Save.
5. In Rules and policies > Firewall rules, assegnare la Policy alla regola firewall che elabora realmente il traffico previsto; verificare separatamente l’assegnazione e l’effetto protettivo come nella procedura pilota IPS. Senza questa assegnazione, la Policy non ha effetto.

Queste firme integrano le soglie DoS locali, ma non sostituiscono la protezione DDoS del provider. Se la connessione internet è già satura, il firewall non può risolvere il collo di bottiglia a monte della connessione WAN. Occorre quindi verificare separatamente modello, licenza, corrispondenza della regola e test controllato.

Regole CLI con system dos-config

La Device Console consente di creare policy DoS personalizzate e le relative regole. Questo è necessario, tra l’altro, per IP Flood, perché questo tipo non può essere configurato in WebAdmin. Le unità sono diverse: WebAdmin utilizza pacchetti al minuto, mentre system dos-config utilizza pacchetti al secondo (pps).

Dopo l’accesso SSH, selezionare 4. Device Console nel menu principale. I comandi vanno eseguiti al prompt console>, non nell’Advanced Shell.

Prima si crea la policy con il tipo di attacco, la soglia e il metodo di conteggio. La regola definisce poi il traffico a cui si applica. L’esempio SYN documentato prevede la policy TestSYN e la regola TestRuleSYN per la sorgente 198.51.100.50, con 1000 pps per sorgente.

Verificare la guida della versione di destinazione prima di creare oggetti: la guida pubblicata per SFOS 22 e SFOS 23 usa rule_name per add dos-rule nei blocchi di sintassi e opzioni, ma rule-name negli esempi. Non è confermato che le due forme siano intercambiabili. Consultare prima la guida di system dos-config nella Device Console della versione installata e verificare il token di aggiunta accettato e i parametri. Se il dubbio rimane, non creare una regola e chiedere chiarimenti a Sophos Support. Il comando completo di aggiunta della regola è volutamente omesso come modello da copiare e incollare. Anche la policy seguente va creata solo dopo questa verifica; da sola non associa ancora il traffico di esempio.

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src

1000 pps è un esempio di sintassi, non una raccomandazione per una rete di produzione. Per una regola personalizzata è necessario adattare consapevolmente almeno i seguenti elementi:

• SYN-Flood: in alternativa UDP-Flood, ICMP-Flood o IP-Flood, disponibile solo qui
• per-src: soglia per sorgente; in alternativa per-dst per destinazione o global per tutto il traffico corrispondente
• le condizioni effettivamente necessarie per sorgente, destinazione, zona, interfaccia e protocollo
• la soglia in base a una baseline misurata e alla capacità del servizio protetto

La modalità di conteggio global non si applica ai contatori in Intrusion prevention > DoS attacks. Questi contatori UI non dimostrano quindi un limite CLI aggregato globalmente. Verificare la configurazione con show e valutare separatamente l’applicazione della protezione con un flusso di test ben definito e delimitato nel tempo e con i relativi log.

I limiti e i campi di corrispondenza CLI sono definiti in modo più preciso di quanto suggerisca la breve regola di esempio:

system dos-config flush dos-rules rimuove tutte le regole DoS CLI e non è un rollback per un singolo test. Prima di un’azione globale di questo tipo si registrano individualmente le regole esistenti con show e si salva la configurazione. Per un rollback normale si elimina in modo mirato la regola indicata. La guida pubblicata descrive flush per le regole, non come eliminazione delle policy associate.

Dopo la creazione, controllare innanzitutto che nomi, tipo, soglia e condizione della regola siano corretti:

system dos-config show dos-policies policy-name TestSYN
system dos-config show dos-rules rule-name TestRuleSYN

Per il rollback, eliminare prima la regola e poi la policy non più utilizzata:

system dos-config delete dos-rule rule-name TestRuleSYN
system dos-config delete dos-policy policy-name TestSYN

La sintassi CLI è documentata nella Sophos Firewall Command Line Help. Va comunque utilizzata prima con un flusso di test controllato. Le regole DoS CLI supportano solo IPv4. Con una policy IP-Flood attiva, la colonna Applied in Intrusion prevention > DoS attacks continua a mostrare No; Sophos descrive questo comportamento come previsto.

Questa limitazione a IPv4 riguarda le regole DoS CLI, non le DoS settings native in Intrusion prevention > DoS & spoof protection in WebAdmin: le impostazioni DoS presenti in questa sezione proteggono sia il traffico IPv4 sia quello IPv6, purché siano configurati i flag dei protocolli e le soglie appropriati.

Per SFOS 22 è documentata la valutazione delle regole e policy CLI prima delle impostazioni DoS e spoof di WebAdmin; con questo ordine, una regola bypass WebAdmin non annulla automaticamente una policy CLI corrispondente. La guida CLI SFOS 23 esaminata non specifica questo ordine tra i due livelli. Ciò non dimostra un cambiamento del comportamento: confermare l’interazione per la versione installata prima di farvi affidamento. All’interno di WebAdmin, entrambe le versioni documentano ancora prima le DoS bypass rules, poi i DoS Settings per il traffico restante.

Usare le DoS bypass rules solo in modo mirato

Le DoS bypass rules sono utili quando un flusso chiaramente noto verrebbe altrimenti bloccato erroneamente dai DoS Settings di WebAdmin. Esempi tipici sono monitoring, Health Checks o un servizio strettamente definito tra indirizzi IP noti. L’eccezione dovrebbe essere il più precisa possibile: sorgente specifica, destinazione specifica, protocollo adatto e intervallo porte ristretto.

Regole ampie con reti grandi, logica any o intervalli di porte generici sono pericolose. Rendono cieca l’ispezione DoS proprio dove potrebbe servire in seguito. Se un’eccezione ampia sembra necessaria, occorre prima verificare se le soglie, l’architettura o il caso di test siano stati valutati in modo errato.

L’ordine delle impostazioni WebAdmin è importante: Sophos Firewall verifica prima se una DoS bypass rule corrisponde e applica i DoS Settings di WebAdmin solo al traffico restante. Una regola di bypass troppo ampia può quindi rendere inefficace questa protezione. Per le regole bypass occorre impostare consapevolmente sorgente, destinazione, protocollo, porta sorgente e porta destinazione, invece di usare * per comodità.

Un’eccezione viene creata sotto Intrusion prevention > DoS & spoof protection, nell’area DoS bypass rule, tramite Add. SFOS 22 e SFOS 23 richiedono IP version, IP sorgente e di destinazione, Protocol, Source Port e Destination Port; * indica qualsiasi indirizzo o qualsiasi porta. Per un health check HTTPS da 198.51.100.20 a 203.0.113.10, una configurazione adeguata sarebbe: IP version IPv4, Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * e Destination Port 443. Entrambi gli indirizzi riservati alla documentazione devono essere sostituiti con gli endpoint reali. Source Port rimane variabile soltanto perché i client utilizzano normalmente una porta sorgente dinamica. Dopo Save, testare esattamente questo flusso e un altro flusso; solo l’health check definito deve poter aggirare la protezione DoS di WebAdmin.

Verificare modifica e failover in HA

In un cluster HA, il Primary sincronizza verso l’Auxiliary la configurazione del firewall, incluse regole, policy, impostazioni e comandi CLI. Apportare quindi le modifiche DoS e spoof sul Primary attuale. Controllare poi lo stato HA in System services > High availability e verificare di nuovo le voci WebAdmin e le regole CLI. In Active-active il test di carico deve includere entrambi i percorsi di elaborazione; in Active-passive va previsto un failover controllato nella finestra di manutenzione, se la procedura operativa lo consente. Non creare una seconda configurazione divergente sull’Auxiliary.

Nota per SFOS 22.0 MR2

Le Release Notes di SFOS 22.0 MR2 Build 546 riportano come risolto il problema NC-180226: WebAdmin in precedenza non mostrava alcun errore aggiungendo un indirizzo MAC duplicato in Spoof protection trusted MAC. Sui build 22.0 precedenti, l’assenza di un errore non dimostra quindi che una voce sia univoca. Controllare l’elenco e il binding effettivo oppure aggiornare a un build corretto.

Automazione XML: preservare identità e campi padre

Prima di automatizzare queste impostazioni, verificare la configurazione salvata e l’API help specifica dell’oggetto nella build installata. Le corrispondenze seguenti si riferiscono a SFOS 22/SFOS 23; completare e verificare la richiesta per la build e l’operazione previste. Usare l’API XML in sicurezza spiega operazioni di scrittura esplicite, protezione dell’accesso e controlli separati di trasporto, risposta XML e oggetto salvato.

Regola bypass: corrispondenza precedente e nuova, non un nome

DoSBypassRules non ha un’identità Name documentata. La corrispondenza comprende IPFamily (IPv4 o IPv6), SourceIPNetmask, DestinationIPNetmask e Protocol (TCP, UDP, ICMP o AllProtocol), con SourcePort e DestinationPort aggiuntivi per TCP/UDP. Le porte sono valori singoli da 1 a 65535 oppure *; la documentazione non conferma qui un payload per intervalli di porte. Per aggiunta/modifica, la tabella indica * per entrambi gli indirizzi e TCP per il protocollo come valori predefiniti. Non adottare questi valori ampi come eccezione desiderata: definire consapevolmente la corrispondenza completa.

Durante un update, DoSBypassRules/OldConfiguration contiene la combinazione precedente degli stessi campi; i figli diretti di DoSBypassRules contengono la nuova corrispondenza desiderata. OldConfiguration appartiene all’identità di update, non alla creazione o eliminazione. La documentazione Delete indica i campi di corrispondenza, non un nome. Identificare quindi la combinazione effettivamente salvata prima di eliminarla. L’esempio Add/Edit specifica espressamente che le porte valgono solo per TCP/UDP, mentre gli elenchi dei parametri, incluso Delete, dichiarano entrambe le porte obbligatorie senza precisazioni. Questo non permette di ricavare un payload di eliminazione affidabile ed eseguibile per ICMP/AllProtocol: chiarire guida specifica dell’oggetto e build, senza inviare valori di porta inventati.

Trusted MAC: chiave MAC e famiglie di indirizzi separate

Per TrustedMAC, l’identità è MACAddress; durante l’update, TrustedMAC/OldConfiguration/MACAddress conserva la vecchia chiave, mentre TrustedMAC/MACAddress contiene il MAC desiderato. Delete indica solo MACAddress, non Name o OldConfiguration. Salvare la voce specifica e le sue associazioni prima di Update o Delete, poi controllare nuovamente l’elenco.

TrustedMAC/IPV4Association e TrustedMAC/IPV6Association sono associazioni indipendenti con Static, DHCP o None; la tabella API indica Static come default per entrambe. I relativi campi di indirizzi CSV si chiamano esattamente IPV4Address e IPV6Address. L’import da file usa anche DHCPv6: non trasferire questo valore a IPV6Association senza verifica. Per AssociateIP, valore di esempio e descrizione sono in conflitto; qui non si deduce alcun valore di scrittura consentito. Le precisazioni precedenti sul filtraggio IP-MAC effettivo restano necessarie anche per le voci gestite tramite API.

L’import da file è un’operazione separata Upload_TrustedMAC con Upload_TrustedMAC/TrustedMACListFile per .csv o .txt. L’esempio indica il nome del file trasmesso tramite multipart, ma non conferma né un nome specifico della parte multipart né il suo collegamento a questo campo XML. Non ricavare dall’esempio una richiesta di upload pronta all’uso; chiarire prima il contratto di upload specifico della build, poi controllare le associazioni importate.

Non appiattire Spoof Prevention e DoS Settings

Il nome ripetuto è intenzionale nella struttura di esempio: SpoofPrevention è la radice, SpoofPrevention/SpoofPrevention l’interruttore. SpoofPrevention/RestrictUnknownIPOnTrustedMAC è un interruttore separato. I tre tipi di controllo hanno elenchi di zone distinti: SpoofPrevention/IPSpoofing/EnableOnZone/Zone, SpoofPrevention/MACFilter/EnableOnZone/Zone e SpoofPrevention/IPMACFilter/EnableOnZone/Zone. L’esempio mostra Enable/Disable, la tabella dei parametri invece on/off, e la nota sulla disattivazione è ambigua. Né queste indicazioni né elenchi di zone omessi o vuoti confermano una sintassi di cancellazione o disattivazione. Chiarire valori e rollback nella build installata prima di scrivere.

Sotto DoSSettings, SYNFlood, UDPFlood, TCPFlood e ICMPFlood hanno ciascuno i propri genitori Source e Destination. Sotto Source si trovano PacketRatePerSource, BurstRatePerSource e ApplyFlag; sotto Destination, PacketRatePerDestination, BurstRatePerDestination e ApplyFlag. Ad esempio, DoSSettings/UDPFlood/Destination/ApplyFlag riguarda solo il limite UDP di destinazione. La tabella ammette rate di pacchetti di 1–600000 e rate burst di 1–10000; il default 1 e i numeri dell’esempio non costituiscono una baseline di produzione. I flag aggiuntivi si trovano in DoSSettings/DroppedSourceRoutedPackets/Destination/ApplyFlag, DoSSettings/DisableICMPRedirectPacket/Destination/ApplyFlag e DoSSettings/DisableARPFlooding/Destination/ApplyFlag. Non accorpare le etichette ripetute della tabella in un unico PacketRate, BurstRate o ApplyFlag globale; preservare i valori salvati con il relativo percorso padre.

Leggere i codici con operazione e stato salvato

La documentazione elenca i seguenti codici specifici per operazione, non risultati HTTP universali:

• Add DOS ByPass Rules: 200, 400, 401, 403, 409, 500; Edit DOS ByPass Rules: 200, 400, 401, 403, 404, 500. Non confondere in particolare il 409 di Add con il 404 di Edit.
• Configure Spoof Prevention e Configuration DOS Settings: ciascuno 200, 400, 401, 403, 404, 500.
• Upload Trusted MAC List: 200, 400, 401, 403, 404, 409, 500.
• Delete DOS ByPass Rule e Delete Trusted MAC: solo 200, 500 in queste pagine.
• Add Trusted MAC e Update Trusted MAC: ciascuno 200 con Operation Successful. e 500 con Operation Fail..

Per le altre operazioni citate, i messaggi nelle fonti complete restano simboli JavaScript, non testi di risposta risolti:

Dopo ogni modifica, confrontare la risposta con zone, rate, associazioni o combinazione bypass effettivamente salvati. In caso di errore o risposta poco chiara, rileggere lo stato corrente prima di riprovare; non ricreare la voce alla cieca né dedurre l’efficacia del filtro dal solo 200. Verificare poi separatamente un flusso di test corrispondente e uno non corrispondente come descritto sopra.

Cosa non risolvono queste impostazioni

Spoof Protection e DoS Settings sono elementi costitutivi importanti, ma non risolvono tutti i problemi di sicurezza.

• Il server viene attaccato tramite richieste HTTP consentite: verificare la regola WAF e Webserver Protection.
• Una Source-IP notoriamente malevola attacca: valutare Threat Feeds o il blocco per paese/IP.
• Tentativo di exploit contro un servizio: attivare una policy IPS adeguata alla regola.
• La connessione Internet è saturata da un DDoS: coinvolgere il provider, un servizio di scrubbing o una protezione DDoS a monte.
• La regola firewall consente troppo: rivedere e ripulire il set di regole, il NAT e il modello degli oggetti.
• Gli scarti di pacchetti non sono ricostruibili: migliorare logging, Packet Capture, Syslog o Central Reporting.

L’articolo Pubblica server con DNAT su Sophos Firewall è rilevante anche per i server accessibili pubblicamente. Riguarda NAT, le regole del firewall e gli errori tipici di pubblicazione.

Log e controlli successivi

Dopo l’attivazione non dovresti solo controllare se il normale accesso a Internet funziona ancora. Ciò che è importante è se il firewall mostra chiaramente gli eventi attesi e imprevisti.

Controllare:

1. Filtrare Log Viewer per gli eventi Firewall e gli eventi Security rilevanti.
2. Generare traffico di test con IP sorgente, IP di destinazione e servizio chiaramente definiti.
3. Usare Packet Capture se la causa dei pacchetti scartati non è chiara.
4. Per un’archiviazione più lunga, pianificare syslog su SIEM o server di registro.
5. Quando si esegue Sophos Fusion (in precedenza Sophos Central), verificare se Central Firewall Reporting rende visibili gli eventi desiderati.

SFOS registra il traffico scartato da queste protezioni. Per un test DoS, annotare prima ora, sorgente, destinazione, protocollo e contatori. Durante il test, Intrusion prevention > DoS attacks mostra in tempo reale sorgente o destinazione e dati scartati. Poiché lo stato scompare 30 secondi dopo la fine dell’attacco e Traffic dropped è cumulativo dall’ultimo riavvio, è significativo solo un confronto prima/dopo delimitato nel tempo. La modalità CLI global non si applica a questi contatori UI; neppure questo confronto convalida quindi l’aggregazione globale. Per una policy CLI globale, separare il controllo della configurazione con show dalla verifica del flusso di test definito e dei relativi scarti/log. Packet Capture mostra inoltre interfaccia di ingresso e indirizzi del pacchetto, ma da solo non prova quale protezione abbia scartato il flusso.

Se un pacchetto viene scartato ma il motivo non è chiaro, l’analisi sistematica degli scarti di pacchetti in Sophos Firewall scarta pacchetti: controlla le cause aiuta. Descrive inoltre perché Log Viewer e Packet Capture rispondono a domande diverse.

Risoluzione dei problemi dopo l’attivazione

Dopo una modifica, i sintomi non dovrebbero essere interpretati troppo presto come un attacco. L’analisi più rapida consiste di solito nel confrontare aspettativa, osservazione e prossimo test.

• Una singola rete perde l’accesso: la rete sorgente potrebbe arrivare su un’interfaccia diversa da quella prevista. Confrontare route, VLAN, SD-WAN Route e Packet Capture.
• Molti client dietro un NAT upstream sono interessati: se il traffico è già stato sottoposto a NAT prima di raggiungere il firewall Sophos, quest’ultimo vede più client come un’unica sorgente condivisa. Verificare la soglia, il percorso NAT e il picco di carico legittimo.
• VoIP, monitoring o scanner genera drop: rate di pacchetti regolari possono sembrare flooding. Verificare una finestra di test ristretta, Log Viewer e, se necessario, una regola di bypass precisa.
• I dispositivi non funzionano più dopo una modifica DHCP: binding IP-MAC o logica Trusted MAC potrebbero non essere più corretti. Controllare lease, indirizzo MAC e binding.
• Manca solo il traffico di ritorno: è probabile un percorso asimmetrico o un gateway errato. Verificare separatamente andata e ritorno con Packet Capture.
• Una modifica ARP o ICMP crea effetti collaterali: ARP hardening, source-routed packets o ICMP redirect possono colpire design di rete insoliti. Controllare router downstream, segmenti Layer 2 e percorso di routing.

Ripristinare in sicurezza

Se viene colpito traffico legittimo e la causa non è identificabile nella finestra di manutenzione, non improvvisare un’eccezione ampia. Ripristinare Packet Rate, Burst Rate, flag Apply, tipo di controllo spoof, zone e Restrict unknown IP on trusted MAC annotati in precedenza; rimuovere solo le nuove voci bypass o Trusted MAC. Usare Apply o Save e ripetere lo stesso test. Per una policy CLI, eliminare prima solo la regola indicata e poi la policy dedicata ormai inutilizzata. flush dos-rules non fa parte di questo rollback.

Errori tipici

• Attivare Spoof Protection senza comprendere il routing: il traffico legittimo può essere bloccato. Verificare prima zone, interfacce, route e percorsi di ritorno.
• Adottare soglie DoS senza verificarle: VoIP, monitoraggio, scansioni o servizi pubblicati possono subire interruzioni. Pianificare una baseline e una fase di test.
• Confondere Packet Rate e Burst Rate: la frequenza continuativa dei pacchetti e un picco di breve durata sono parametri di regolazione diversi. Entrambi devono essere adeguati al servizio.
• Risolvere ogni anomalia con un’eccezione ampia: l’hardening diventa inefficace e difficile da gestire. Circoscrivere la causa, limitare l’ambito delle eccezioni e documentarle con precisione.
• Impostare una DoS bypass rule troppo ampia: in WebAdmin, il bypass viene verificato prima dei DoS Settings presenti nella stessa interfaccia e può aggirare completamente questo controllo. Impostare Source, Destination, protocollo e porte con un ambito ristretto; verificare inoltre le policy CLI separate.
• Lasciare vuoto il filtro IP-MAC-Pair: senza voci mantenute aggiornate non si crea alcun vincolo efficace. Dopo l’attivazione, verificare sempre con un client di test noto.
• Presentare DoS Settings come protezione DDoS: in caso di attacchi che saturano la banda, si creano aspettative errate. Pianificare separatamente la protezione del provider e quella a monte.
• Non controllare i log: i blocchi erronei o gli attacchi restano invisibili. Definire il controllo di Log Viewer, Central Reporting o Syslog come attività operativa.
• Interpretare gli scarti di pacchetti dovuti allo spoofing esclusivamente come un attacco: si rischia di non rilevare errori di routing o VLAN. Confrontare Source-IP, interfaccia, route e Packet Capture.

Lista di controllo operativa

Prima dell’attivazione:

• Zone, interfacce e routing compresi.
• Servizi critici e casi di test definiti.
• Packet Rate, Burst Rate e flag attivati valutati dal punto di vista tecnico.
• Backup o documentazione della modifica disponibili.
• Logging e analisi predisposti.
• Ambito pilota o finestra di manutenzione definiti.

Dopo l’attivazione:

• Internet, VPN, WAF, DNAT, VoIP e Monitoring testati.
• Log Viewer controllato per individuare pacchetti scartati in modo inatteso.
• Packet Capture utilizzato per almeno un caso di test chiaramente definito, se vengono scartati pacchetti.
• Eccezioni configurate solo con ambito ristretto e con motivazione.
• DoS bypass rules controllate per Source, Destination, protocollo e porte.
• Risultato registrato nella documentazione operativa.

Periodicamente:

• Verificare gli eventi DoS e di spoofing.
• Controllare la necessità delle eccezioni.
• Ripetere i test dopo modifiche all’architettura di rete, modifiche VPN o nuove VLAN.
• Correlare i log con gli eventi IPS, Threat-Feed, WAF e delle regole firewall.

Domande frequenti