Sophos Firewall: Bloccare paesi e IP dannosi

Una volta che i servizi sono accessibili da Internet, si nota spesso rapidamente traffico indesiderato: scansioni di porte, tentativi di login, reti bot conosciute o accessi da paesi da cui non ci si aspetta utenti. Su Sophos Firewall è possibile bloccare tali fonti a più livelli.

La scelta rapida per SFOS 22 è questa: bloccare normalmente i paesi con una regola firewall Drop, le pubblicazioni WAF con Blocked countries e i servizi locali con Device access o una Local Service ACL Exception Rule. Per IP dannosi in continua evoluzione, i Sophos Firewall Threat Feeds sono più gestibili delle liste manuali. Black Hole DNAT resta uno strumento mirato per destinazioni WAN pubblicate, soprattutto quando una normale regola firewall non valuta il traffico WAF verso la Hosted address.

Da SFOS 22, Active Threat Response può confrontare anche l’IP sorgente del traffico DNAT e WAF in entrata con feed MDR, NDR e di terze parti. Gli scanner noti non devono quindi essere gestiti esclusivamente con regole Black Hole statiche.

Orientamento

Prima di bloccare fonti, deve essere chiaro quale traffico si intende: servizi pubblicati, servizi locali del firewall, traffico client in uscita o traffico WAF. Il metodo adatto dipende esattamente da questo.

Quale metodo è adatto quando?

• Regola del firewall con Drop: Blocca il traffico in base a Source Country, Source Network o Source Host. È adatta per blocchi di paesi, singole reti o liste di IP dannosi mantenute manualmente.
• Black Hole DNAT: Traduce il traffico verso un IP fittizio inesistente e non instradato, prima della regola DNAT di produzione.
• WAF Blocked countries: Vale per server web pubblicati tramite WAF. I paesi vengono bloccati direttamente nella regola WAF.
• Local service ACL exception rule: Controlla servizi locali del firewall come WebAdmin, User Portal, VPN Portal o SSH. È il punto corretto quando si deve proteggere il firewall stesso.
• Threat Feeds: Usano liste dinamiche IPv4, dominio o URL. In SFOS 22 i feed IPv4 rilevano anche sorgenti davanti a DNAT e WAF; valutare un nuovo feed con Monitor prima di passare a Block.

Quale metodo sia sensato dipende da dove il traffico viene elaborato tecnicamente. Le regole del firewall non si applicano in ogni caso per il traffico che va a un indirizzo ospitato utilizzato in WAF. In tali casi, una regola WAF per i paesi o una regola Black Hole DNAT è spesso più adatta.

In entrata, in uscita o firewall locale

Prima di una regola di blocco, dovrebbe essere chiaro quale tipo di traffico si intende. Altrimenti si blocca nel punto sbagliato e ci si chiede più tardi perché l’attacco è ancora visibile o perché il traffico legittimo non funziona.

• In entrata verso server pubblicati: Inoltro di porta su RDP, HTTPS, SMTP o applicazione propria. Ordine DNAT, regola WAF, regola del firewall, IPS e logging
• In entrata verso il firewall stesso: WebAdmin, User Portal, VPN Portal, SSH, Ping o DNS sul firewall. Device Access e Local Service ACL Exception Rules
• In uscita da client interni: I client contattano obiettivi sospetti su Internet. Regola del firewall, Threat Feeds, Web Protection, DNS Protection e logging
• Server web tramite WAF: Applicazione web pubblica dietro Web Server Protection. Regola WAF, paesi bloccati, autenticazione, MFA e log WAF

Questa separazione è importante perché una regola per i paesi in Rules and policies > Firewall rules non protegge automaticamente ogni superficie di attacco del firewall. Per i server pubblicati, di solito la catena NAT e WAF è in primo piano. Per i portali di amministrazione conta prima di tutto se il servizio del firewall locale è raggiungibile dalla zona. Per il traffico client in uscita, Threat Feeds, Web Protection e DNS Protection sono spesso gli strumenti più puliti.

Non confondere con Device Access

Il blocco dei paesi e Black Hole DNAT proteggono principalmente il traffico elaborato da regole del firewall o NAT. I servizi locali di Sophos Firewall sono un altro caso. Questi includono, ad esempio, WebAdmin, SSH, User Portal, VPN Portal, DNS, Ping e in parte anche servizi di accesso remoto.

Per questi servizi locali è rilevante prima di tutto Administration > Device access. Lì si decide da quali zone un servizio è generalmente raggiungibile. Se si desidera consentire l’accesso solo per singoli indirizzi IP di amministrazione, paesi o fonti di supporto, le Local service ACL exception rules sono il punto di controllo corretto. La procedura è descritta in Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

⚠️ Una regola di blocco dei paesi non sostituisce una configurazione pulita di Device Access. Se WebAdmin, User Portal, VPN Portal o SSH sono troppo ampiamente accessibili, il firewall stesso rimane una superficie di attacco. Il blocco dei paesi può ridurre il rischio, ma non sostituire il rafforzamento dell’accesso di base.

Per servizi locali particolarmente sensibili, WAN non dovrebbe essere attivato in modo generico sotto Local service ACL. È meglio una exception rule che consenta solo le fonti attese o blocchi paesi indesiderati. Per WebAdmin, un IP amministrativo fisso o una VPN di gestione è di solito più pulito di un filtro paese, perché Geo-IP non è una vera verifica dell’identità.

Pianificare le regole di blocco

Le regole di blocco devono essere pianificate in modo da non interrompere traffico legittimo per errore.

Creare correttamente un Country Group

SFOS include già Country Groups organizzati per continente. Per una selezione operativa personalizzata, ad esempio paesi con cui non esiste una relazione commerciale, creare in Hosts and services > Country group > Add un gruppo con un nome descrittivo. Selezionare quindi i paesi o le regioni necessari e salvare con Save. Un paese o una regione può appartenere a più gruppi.

Nella selezione si può cercare il nome completo o il codice alpha-2 di due lettere. Le singole regioni mancanti in un gruppo predefinito possono essere aggiunte manualmente a un gruppo predefinito o personalizzato. Prima di una modifica successiva, aggiornare e controllare la colonna Usage, perché lo stesso Country Group può essere usato in regole firewall, NAT, routing o altre policies.

Bloccare paesi con una regola del firewall

Per il blocco generale dei paesi, creare una regola firewall con Drop. SFOS valuta le regole dall’alto verso il basso e si ferma alla prima corrispondenza.

Percorso del menu:

Rules and policies > Firewall rules > IPv4 o IPv6 > Add firewall rule > New firewall rule

Campi consigliati:

• Nome della regola: Nome descrittivo, ad esempio BLOCK_COUNTRY_PANAMA
• Posizione della regola: Top
• Rule group: None o un gruppo scelto consapevolmente
• Azione: Drop
• Zone di origine: Any
• Reti e dispositivi di origine: Paese, gruppo di paesi, lista di IP o gruppo di host
• Durante il tempo programmato: All the time
• Zone di destinazione: Any
• Reti di destinazione: Any
• Servizi: Any o un servizio definito
• Log firewall traffic: Attivo

Per rendere efficace questo schema, Sophos richiede Source zones: Any e Destination zones: Any. Reti e servizi possono comunque essere limitati a una pubblicazione specifica. Le regole IPv4 e IPv6 sono separate; in dual-stack vanno configurate e testate entrambe.

Paesi e gruppi di paesi vengono usati come oggetti sotto Hosts and services. Per più paesi, una Country group è più chiara di molti paesi singoli direttamente in ogni regola. Le liste di IP dannosi appartengono invece a oggetti IP host o IP host group adatti. Bisogna conoscerne i limiti: le IP host list non sono pensate per feed dinamici arbitrariamente grandi. Per infrastruttura di attacco che cambia continuamente, i Threat Feeds sono più gestibili.

Il blocco dei paesi dovrebbe essere inoltre inteso come un controllo Best-Effort. I dati Geo-IP possono essere errati, gli utenti viaggiano, gli attaccanti utilizzano proxy o sistemi compromessi in paesi consentiti, e i servizi cloud utilizzano infrastrutture distribuite a livello globale. Pertanto, una regola per i paesi non dovrebbe mai essere l’unica misura di protezione.

Quando non bloccare troppo ampiamente

Una regola di blocco è facile da creare, ma può successivamente generare effetti collaterali difficili da comprendere. Bisogna essere particolarmente cauti quando le applicazioni produttive dipendono da piattaforme esterne, CDN, fornitori di pagamenti, servizi cloud, fornitori di monitoraggio o partner di supporto.

Prima di un blocco ampio di paesi o IP, è quindi necessario chiarire:

• Ci sono utenti, partner o fornitori di servizi nei paesi interessati?
• Un’applicazione utilizza infrastrutture cloud o CDN con indirizzi di origine variabili?
• Gli aggiornamenti, i webhook, il monitoraggio, i backup o gli accessi di supporto vengono attivati tramite servizi esterni?
• C’è un modo per registrare prima solo i log o testare la regola per un periodo limitato?
• È chiaro chi verifica i falsi positivi e come viene concessa un’eccezione?

Per i servizi Internet con autentica registrazione degli utenti, le regole per i paesi sono spesso solo una misura aggiuntiva. MFA, regole del firewall strette, sistemi di destinazione aggiornati, IPS, protezione WAF, logging e Threat Feeds rimangono più importanti di una lista di blocco il più lunga possibile.

Pianificare una Allowlist prima di una Blocklist

Per i servizi critici, una Allowlist è spesso più pulita di una Blocklist sempre più lunga. Se un servizio deve essere accessibile solo da partner fissi, filiali, sistemi di monitoraggio o sedi amministrative, si dovrebbero prima consentire queste fonti e bloccare il resto. Questo riduce il carico di manutenzione e impedisce di dover bloccare reattivamente ogni nuovo IP di scanner singolarmente.

Una Allowlist è particolarmente adatta per:

• Accessi amministrativi a servizi di gestione pubblicati
• Interfacce B2B con indirizzi IP di partner conosciuti
• Monitoraggio, backup, webhook o endpoint API con sistemi di origine fissi
• Accessi di supporto temporanei con ticket, data di scadenza e revisione

Una Blocklist è più adatta quando un servizio deve rimanere consapevolmente accessibile pubblicamente, ma si desidera ridurre le fonti sospette. In tal caso, la regola dovrebbe essere gestita con logging, data di revisione e eccezioni chiare. Per i server web pubblicati tramite WAF, è inoltre rilevante Sophos Firewall WAF: pubblicare in sicurezza i server web, poiché lì paesi, autenticazione e protezione del server web sono gestiti più vicino all’applicazione pubblicata.

Trattare separatamente i filtri paese WAF

In Web Server Protection, la regola WAF ha campi propri per Allowed client networks, Blocked client networks, Blocked countries e Block IP addresses of unknown country-origin. Queste impostazioni appartengono all’applicazione web pubblicata e non sono la stessa cosa di una normale regola firewall Drop.

Questo è pratico perché il filtro paese è collegato direttamente alla pubblicazione WAF. Allo stesso tempo serve cautela: Block IP addresses of unknown country-origin può escludere utenti legittimi se il loro indirizzo IP non può essere assegnato chiaramente. Prima dell’attivazione, conviene verificare il proprio indirizzo IP esterno con la GeoIP2 Databases Demo. Questa opzione dovrebbe essere attivata solo se l’effetto è stato testato ed è noto al processo di supporto.

Per le regole WAF, i filtri paese sono solo un elemento. Autenticazione, MFA, certificato, Web Server Protection, firme IPS/WAF, logging e un server backend aggiornato restano più importanti di una lunga lista di paesi bloccati.

Black Hole DNAT e Threat Feeds

Per servizi pubblicati può essere utile intercettare fonti indesiderate prima della regola DNAT produttiva. Per infrastrutture d’attacco dinamiche sono utili anche i Threat Feeds.

Black Hole DNAT per fonti indesiderate

Una regola Black Hole DNAT traduce il traffico verso una destinazione inesistente. Insieme alla policy firewall impedisce che raggiunga il servizio reale: NAT traduce gli indirizzi, ma non autorizza né blocca autonomamente l’accesso.

Questo è particolarmente utile quando un servizio viene pubblicato tramite DNAT e si desidera intercettare determinate fonti prima dell’effettivo inoltro di porta.

Black Hole DNAT dovrebbe essere utilizzato in modo mirato. È particolarmente adatto per il traffico verso servizi pubblicati, dove sotto c’è una normale regola DNAT. Per il traffico client in uscita generale, servizi del firewall locali o server web pubblicati tramite WAF, di solito una regola del firewall, Device Access o un’impostazione WAF è il punto di controllo migliore.

Nella regola NAT è importante non confondere la vista originale dell’attaccante con la destinazione dummy tradotta. Creare la regola in Rules and policies > NAT rules > Add NAT rule > New NAT rule, sopra la regola DNAT di produzione. Original source contiene la lista di IP bloccati, il paese o il gruppo di paesi. Original destination è l’indirizzo WAN pubblico o l’oggetto host WAN a cui si rivolge l’attaccante. Translated destination è l’host dummy non instradato. In questo schema, la traduzione di sorgente e servizio normalmente resta impostata su Original.

Dopo il salvataggio, bisogna verificare nel Log Viewer se viene colpita la NAT Rule ID prevista. Se la normale regola DNAT continua a corrispondere, la regola Black Hole è troppo in basso, la sorgente non corrisponde, oppure il servizio o la destinazione raggiunti non corrispondono al traffico di test.

La regola Black Hole DNAT richiede comunque una regola firewall adatta o un percorso di log, in modo che il match resti tracciabile. NAT traduce soltanto, non è un’autorizzazione di accesso autonoma. Se in seguito nessuno sa più perché esiste l’host fittizio o quale fonte viene intercettata, questa tecnica diventa rapidamente un residuo legacy.

Esempio:

• Nome della regola: BLOCK_BAD_IPS_COUNTRIES
• Posizione della regola: Top
• Origine originale: Lista di IP dannosi, paese o gruppo di paesi
• Destinazione originale: IP WAN pubblico o oggetto host WAN
• Servizio originale: Any o il servizio pubblicato
• Origine tradotta (SNAT): Original
• Destinazione tradotta (DNAT): IP host BLACKHOLE-192.0.2.254 con 192.0.2.254, se questo indirizzo di documentazione non è usato né instradato internamente
• Servizio tradotto (PAT): Original
• Interfaccia in entrata: Any
• Interfaccia in uscita: Any

192.0.2.254 appartiene a TEST-NET-1. Sostituirlo con un indirizzo sicuramente libero e non instradato se tale rete è già usata internamente. La regola resta sopra le DNAT effettive.

L’host fittizio non dovrebbe essere scelto a caso. È sensato un indirizzo da una rete di documentazione o fittizia interna non utilizzata, che non viene instradata e non è pianificata per sistemi reali in futuro. La regola dovrebbe descrivere chiaramente perché questo host esiste, in modo che non venga eliminato accidentalmente o utilizzato in produzione.

Perché l’ordine è decisivo

Per le regole NAT vince la prima regola corrispondente. Una regola Black Hole DNAT deve quindi essere molto in alto, di solito in cima alla tabella delle regole NAT.

Ordine esemplificativo:

1. Black Hole DNAT per lista di IP dannosi e paesi bloccati
2. Regole DNAT specifiche per servizi pubblicati
3. Regole SNAT speciali
4. Regola MASQ generale per il traffico in uscita

Per le regole del firewall vale lo stesso principio: le regole di blocco specifiche stanno sopra le regole di autorizzazione generali. Altrimenti può succedere che il traffico sia già stato autorizzato prima che la regola di drop venga verificata.

Non lasciare inutilmente la fonte su Any

Per i servizi pubblicati, si dovrebbe restringere la fonte il più possibile.

Fonti sensate possono essere:

• singoli indirizzi IP pubblici
• Reti di partner o filiali
• Paesi da cui ci si aspetta l’accesso
• Host FQDN o gruppi di host DNS, se appropriato
• Gruppi di host curati con indirizzi IP di amministrazione consentiti

Any è sensato solo se il servizio deve essere veramente accessibile a livello mondiale. In tal caso, si dovrebbero attivare misure di protezione aggiuntive: logging, IPS, MFA dove possibile, autenticazione forte, sistemi di destinazione aggiornati e Threat Feeds.

IPv6 deve essere pianificato separatamente. Una regola paese IPv4 non dimostra che la stessa applicazione sia protetta anche tramite IPv6. In ambienti dual-stack servono regole IPv6 adatte, logging e un percorso di test. Se IPv6 non viene usato in produzione, deve essere disattivato, bloccato o introdotto in modo documentato.

Utilizzare anche Threat Feeds in SFOS 22

Le liste manuali e le regole per i paesi sono statiche. L’infrastruttura degli attaccanti cambia continuamente. Pertanto, consigliamo anche i Sophos Firewall Threat Feeds.

I Threat Feeds aiutano particolarmente con:

• indirizzi IP di scanner conosciuti
• Reti bot
• Infrastruttura malware
• Host compromessi
• Liste di IP dannosi gestite dinamicamente

Non serve così gestire ogni IP manualmente. I feed IPv4, domini e URL di cybora.io sono un esempio tecnicamente adatto; come ogni fornitore, vanno valutati per aggiornamento, match utili e falsi positivi.

Per DNAT e WAF in entrata, attivare anche Remote source match (inbound traffic) in System services > Log settings > Active threat response. È disattivato per impostazione predefinita e rende visibili questi eventi nel log Active Threat Response. Avviare un nuovo feed con Action: Monitor e passare a Block solo dopo aver verificato Sync status, numero di indicatori, match e falsi positivi.

Test e operatività

Dopo la modifica, contatori, log e percorsi di accesso attesi devono essere controllati consapevolmente.

Gestione e revisione delle liste di blocco

Le liste di blocco sono utili solo se rimangono comprensibili in funzione. Una regola per i paesi o una lista di IP dannosi non dovrebbe quindi semplicemente crescere indefinitamente senza che qualcuno verifichi i colpi, le eccezioni e gli effetti collaterali.

Per ogni lista di blocco manuale dovrebbe essere documentato:

• perché la fonte è stata bloccata
• se si tratta di un blocco temporaneo o permanente
• chi gestisce la lista
• quando la regola verrà nuovamente verificata
• quali servizi o regole DNAT sono interessati
• come viene concesso un falso positivo

Soprattutto con reti cloud, CDN, hosting o supporto, bisogna essere cauti. Un singolo indirizzo IP può appartenere successivamente a un altro cliente, un intervallo CDN può contenere servizi legittimi e un fornitore di servizi esterno può cambiare il proprio IP di uscita. Se un accesso legittimo viene bloccato, non si dovrebbe disattivare immediatamente l’intera regola. È meglio un’eccezione stretta con motivo, ticket e data di revisione.

Per i server pubblicati, si dovrebbe inoltre verificare se la lista di blocco effettivamente precede la regola DNAT produttiva. Il controllo operativo in Pubblicare server tramite DNAT su Sophos Firewall aiuta a valutare insieme servizi pubblicati, regole NAT e logging. Se le fonti bloccate passano attraverso una regola del firewall, Testare la regola del firewall con Log Viewer, Policy Test e Packet Capture è il percorso di test appropriato.

Una revisione sensata non consiste solo in uno sguardo alla regola. Si dovrebbe controllare nel Log Viewer se la regola colpisce ancora, quali fonti sono interessate e se i colpi corrispondono al rischio previsto. Per una valutazione a lungo termine, Central Firewall Reporting o Inviare i log di Sophos Firewall a SIEM sono migliori dei soli log locali.

Procedura di test dopo la modifica

Dopo una nuova regola di blocco, non si dovrebbe solo verificare se l’accesso indesiderato scompare. È importante anche se il traffico desiderato continua a funzionare e se il firewall registra il colpo in modo comprensibile.

Procedura pratica:

1. Creare la regola con nome descrittivo, logging e descrizione dettagliata.
2. Se possibile, testare prima con una piccola lista di origine o un singolo paese.
3. Verificare il blocco previsto da una fonte esterna appropriata.
4. Filtrare nel Log Viewer per origine, destinazione, servizio, ID regola del firewall e ID regola NAT.
5. Testare un accesso legittimo da una fonte consentita.
6. Per i server pubblicati, verificare se la regola DNAT produttiva continua a funzionare per le fonti consentite.
7. Documentare la data di revisione e il proprietario della regola.

Una regola Drop deve mostrare la Firewall Rule ID prevista e un’azione bloccata. Per Black Hole DNAT verificare anche NAT Rule ID e destinazione tradotta. Dopo una modifica NAT aprire una nuova connessione: quelle esistenti non vengono rivalutate.

Se non è possibile un test esterno pulito, usare Log Viewer, Diagnostics > Packet capture e una finestra di manutenzione stretta. Packet Capture mostra NAT ID, Rule ID, Status e Reason.

Rollback sicuro

• Firewall Rule: Disattivare o ripristinare la posizione precedente e ripetere entrambi i test.
• Black Hole DNAT: Disattivare o ripristinare l’ordine precedente e aprire una nuova connessione. Eliminare l’host fittizio solo se Usage non mostra riferimenti.
• Filtro paese WAF: Rimuovere i paesi aggiunti o disattivare Block IP addresses of unknown country-origin, quindi testare da una fonte legittima.
• Third-party Threat Feed: Riportare Action da Block a Monitor. Una Threat Exclusion globale non equivale al rollback perché riguarda anche altri moduli.

Troubleshooting

Se il risultato atteso manca, si controllano passo per passo logging, rule matching e comportamento delle policy.

Errori tipici

• Black Hole DNAT è sotto la regola DNAT normale: La regola DNAT normale corrisponde prima, la regola di blocco non si applica
• La destinazione fittizia esiste nella rete: Il traffico finisce inaspettatamente su un sistema reale
• La fonte viene gestita diversamente in NAT e regola del firewall: Le regole diventano difficili da comprendere e divergono
• Il blocco dei paesi viene utilizzato come unica misura di protezione: I bot da paesi consentiti possono continuare ad attaccare
• WAF e DNAT vengono confusi: Una regola firewall Drop non protegge automaticamente ogni pubblicazione WAF. Controllare separatamente WAF Blocked countries.
• I servizi locali del firewall vengono protetti con normali regole firewall: Per WebAdmin, User Portal, VPN Portal e SSH controllare prima Device Access e Local Service ACL.
• IPv6 viene dimenticato: Una regola IPv4 non blocca un percorso IPv6.
• I blocchi IP temporanei non vengono mai verificati: Voci vecchie bloccano successivamente accessi legittimi o creano complessità inutile
• Gli intervalli cloud o CDN vengono bloccati troppo ampiamente: Applicazioni aziendali, aggiornamenti o fornitori di servizi esterni possono fallire
• Il logging è disattivato: Nel Log Viewer non è chiaro quale regola ha colpito
• Manca Remote source match: L’evento DNAT o WAF in entrata non appare nel log Active Threat Response
• Si riutilizza una connessione esistente: Le modifiche NAT valgono solo per nuove connessioni

Risoluzione dei problemi

Se una regola di blocco non si applica, si dovrebbe verificare in questo ordine:

1. La regola NAT o del firewall è davvero sopra le regole di autorizzazione?
2. L’IP di origine corrisponde alla lista di IP dannosi o al paese scelto?
3. Il traffico viene elaborato da una regola WAF, regola DNAT o regola del firewall?
4. Il logging è attivo sulla regola del firewall interessata?
5. Il Log Viewer mostra l’ID della regola del firewall o l’ID della regola NAT previsto?
6. Si vede il traffico in Diagnostics > Packet capture?
7. C’è un’eccezione più recente, un gruppo di host o un’esclusione di Threat Feed che influenza il blocco previsto?
8. Un blocco temporaneo è stato lasciato permanentemente dopo un incidente?

Per l’analisi aiutano anche La regola del firewall non si applica: verificare ordine, corrispondenza e log, Utilizzare lo strumento Packet Capture in WebAdmin e Comprendere NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Se il traffico bloccato appartiene effettivamente a un server pubblicato, si dovrebbe inoltre verificare la regola DNAT produttiva: la regola Black Hole DNAT è davvero sopra, viene colpito lo stesso indirizzo di destinazione pubblico e il servizio è identico o volutamente più ampio? Per la pubblicazione completa si adatta Pubblicare server tramite DNAT su Sophos Firewall.

FAQ