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, IPS, Threat Feeds, WAF pulite e 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, il percorso 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 IP di origine non plausibile, riduce i semplici tentativi di spoofing, rende visibili i pacchetti instradati in modo errato. non sostituisce la zona pulita, l’interfaccia e la pianificazione del routing.
• DoS Settings: limita semplici schemi di allagamento, rende evidenti attacchi rumorosi o configurazioni errate in precedenza. non sostituisce la protezione DDoS del provider, nessun WAF e nessun design a monte ben dimensionato.

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 libere.
• Zone client, ospiti o IoT in cui nessuna rete interna esterna deve apparire come origine.
• Luoghi in cui il percorso, VLAN e zone sono chiaramente documentati.
• Gli ambienti in cui i pacchetti vengono rilasciati devono essere successivamente tracciabili con Packet Capture e registri.

Le cose diventano più difficili con routing asimmetrico, reti di transito complesse, percorsi di migrazione temporanei, VLANs documentati 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. Zone documento, interfacce, VLAN, bridge e LAG.
2. Controlla i percorsi statici, i percorsi SD-WAN, i percorsi 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 più libere, 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 Log Viewer e Packet Capture per eventuali cadute impreviste.
6. Non gestire immediatamente evidenti cali legittimi con ampie eccezioni, ma prima controlla il routing, l’IP di origine e l’interfaccia.

Un errore comune è considerare Spoof Protection come un puro e semplice gancio di sicurezza. In realtà, la funzione verifica un’ipotesi sulla progettazione della rete. Se questa ipotesi non è corretta, Spoof Protection non deve necessariamente essere sbagliato. Spesso un’interfaccia, un percorso, un VLAN o un percorso di ritorno non vengono costruiti come previsto.

Capire correttamente IP, MAC e coppie IP-MAC

Sophos distingue diversi tipi di controllo. IP spoofing scarta il traffico quando l’IP sorgente non corrisponde alla tabella di routing o a una subnet direttamente collegata. MAC filter lavora con indirizzi MAC attendibili; per questo deve essere mantenuta almeno una Trusted MAC Address. Il MAC filter non viene applicato ai pacchetti DHCP. IP-MAC pair filter controlla se la combinazione in ingresso tra 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.

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 severa: pacchetti da una Trusted MAC senza binding IP corrispondente possono essere scartati se l’IP risulta sconosciuto dal punto di vista del firewall. È un guadagno di sicurezza in reti controllate, ma un ostacolo con DHCP, migrazioni e cambi IP temporanei.

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 in Intrusion prevention > DoS & spoof protection da un file .csv o .txt. La prima riga deve contenere esattamente MAC Address,IP Association,IP Address. I valori consentiti per IP Association sono Static, DHCP, DHCPv6 e None. Con Static è possibile indicare al massimo 16 indirizzi IP separati da virgole per ogni MAC; con le altre tre associazioni il campo IP resta vuoto.

Durante l’importazione il firewall scarta indirizzi MAC, associazioni o indirizzi IP non validi. Scarta anche i valori IP inseriti con DHCP, DHCPv6 o None. Conviene quindi importare inizialmente poche righe pilota, verificare poi le associazioni visibili e testare un caso IP-MAC consentito e uno volutamente errato. Un upload riuscito non dimostra ancora che la logica di filtro prevista sia attiva.

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 adattarsi, 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 allagamento. 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.

Nella schermata non contano solo i flood classici. Ci sono anche flag come Dropped source routed packets, Disable ICMP/ICMPv6 redirect packet e ARP hardening. Queste opzioni sono un buon hardening di base, perché possono ridurre manipolazioni del routing o del comportamento ARP. Dopo l’attivazione vanno comunque testate, soprattutto in reti con router downstream, segmenti vecchi o design Layer 2 insoliti.

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

In Intrusion prevention > DoS attacks, SFOS mostra in tempo reale per quale Source o Destination viene applicato un limite e quanti pacchetti sono stati scartati. Dopo il rilevamento, la limitazione si applica inizialmente per dieci secondi. Se l’attacco continua, il firewall azzera il contatore ogni dieci secondi e continua a limitare il traffico. Quando l’attacco termina, i dati scompaiono dopo 30 secondi. Uno stato vuoto non dimostra quindi che non si sia verificato in precedenza un evento DoS; per l’analisi retrospettiva servono gli eventi registrati.

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. L’esempio non è presentato come testato con successo.

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.

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à.

Creare un’eccezione in Intrusion prevention > DoS & spoof protection, nella sezione DoS bypass rule, con Add. SFOS 22 richiede IP version, IP sorgente e destinazione, Protocol, porta sorgente e porta destinazione; * indica qualsiasi indirizzo o porta. Per un Health Check HTTPS da 198.51.100.20 a 203.0.113.10, usare sorgente 198.51.100.20, destinazione 203.0.113.10, protocollo TCP, porta sorgente * e porta destinazione 443. Sostituire entrambi gli indirizzi di documentazione con gli endpoint reali. La porta sorgente resta variabile solo perché i client usano normalmente una porta sorgente dinamica. Dopo Save, testare questo flusso e un flusso diverso: solo l’Health Check definito deve bypassare 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.

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: Controlla WAF protezione regole e server web.
• Attacchi IP di origine dannosa noti: Threat Feeds o Controlla paese/blocco IP.
• Tentativo di exploit contro un servizio: Attiva IPS-Policy secondo la regola.
• La linea Internet è piena a causa di DDoS: Includi provider, scrubbing o protezione DDoS upstream.
• La regola del firewall consente troppo: Regole di pulizia, NAT e modello a oggetti.
• I drop sono incomprensibili: Migliora la registrazione, Packet Capture, syslog o reporting centrale.

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. Log Viewer filtro per firewall ed eventi di sicurezza rilevanti.
2. Attiva il traffico di test con IP di origine, IP di destinazione e servizio chiari.
3. Utilizzare Packet Capture per gocce poco chiare.
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 della caduta in Sophos Firewall perde 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

• Spoof Protection attivare senza comprendere il routing: il traffico legittimo può essere bloccato. Controllare in anticipo zone, interfacce, percorsi e percorsi di ritorno.
• Applicare soglie DoS senza controllare: VoIP, il monitoraggio, le scansioni o i servizi pubblicati possono essere interrotti. Pianificare la linea di base e la fase di test.
• Confondere Packet Rate e Burst Rate: il rate permanente e il picco breve sono controlli diversi. Entrambi devono adattarsi al servizio.
• Risolvere ogni anomalia con un’eccezione generale: L’hardening diventa inefficace e confuso. Limitare la causa e documentare attentamente le eccezioni.
• Impostare una DoS bypass rule troppo ampia: in WebAdmin, il bypass viene controllato prima dei DoS Settings e può aggirare completamente questo controllo. Tenere stretti sorgente, destinazione, protocollo e porte; verificare anche le policy CLI separate.
• Lasciare vuoto IP-MAC pair filter: senza voci mantenute non esiste alcun binding efficace. Dopo l’attivazione testare sempre con un client noto.
• Vendere DoS Settings come protezione DDoS: false aspettative per attacchi alla larghezza di banda. Pianificare separatamente la protezione del provider e quella upstream.
• Non controllare i registri: I blocchi o gli attacchi errati rimangono invisibili. Definire Log Viewer, reporting centrale o syslog come punto operativo.
• Interpretare le eliminazioni di spoofing come un puro attacco: Gli errori di routing o VLAN vengono trascurati. Confrontare IP sorgente, interfaccia, percorso 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 tecnicamente.
• Backup o modifica della documentazione disponibile.
• Registrazione e valutazione preparate.
• Area pilota o finestra di manutenzione impostata.

Dopo l’attivazione:

• Internet, VPN, WAF, DNAT, VoIP e monitoraggio testati.
• Log Viewer controllato per cadute impreviste.
• Packet Capture utilizzato per almeno un caso di test chiaro in caso di cadute.
• Le eccezioni vengono fatte solo in modo limitato e motivato.
• DoS bypass rules controllate per sorgente, destinazione, protocollo e porte.
• Risultato registrato nella documentazione operativa.

Regolarmente:

• Controlla gli eventi DoS e spoofing.
• Controlla le eccezioni per necessità.
• Eseguire nuovamente il test dopo modifiche alla rete, modifiche alla VPN o nuovi VLAN. Correlare i registri
• con IPS, feed delle minacce, WAF ed eventi delle regole firewall.

Domande frequenti