Pubblicare un server tramite DNAT su Sophos Firewall

Con DNAT pubblichi un server interno tramite un indirizzo IP o una porta pubblica. Il Sophos Firewall inoltra quindi il traffico in entrata al server di destinazione interno. Esempi tipici sono server web, proxy inversi, gateway VPN o altri servizi in una DMZ.

Per il contesto generale di hardening, consultare l’hub Sophos Firewall Hardening: best practice per una configurazione sicura.

L’articolo spiega quali aspetti verificare prima e dopo la creazione di una regola DNAT e come proteggere la pubblicazione con il perimetro più ristretto possibile.

Pianificazione prima della pubblicazione

Prima di pubblicare un servizio tramite DNAT, occorre stabilire se l’accesso pubblico sia davvero necessario e quale variante tecnica sia più adatta. Una buona pianificazione evita porte aperte inutilmente, regole NAT duplicate e percorsi di ritorno difficili da tracciare.

Requisiti

• Indirizzo IP pubblico o interfaccia WAN
• Server interno con indirizzo IP fisso
• Servizio e porta conosciuti, ad esempio TCP 443
• Regola firewall appropriata
• Opzionale: IPS, Web Server Protection o Reverse Proxy a seconda del servizio

⚠️ DNAT pubblica un servizio interno verso il mondo esterno. Ogni servizio pubblicato aumenta la superficie di attacco. Dovrebbe essere pubblicato solo ciò che è veramente necessario. Origine, porto e destinazione dovrebbero essere il più ristretti possibile.

Chiarire in anticipo

Prima di impostare il sistema di controllo, dovresti rispondere a queste domande:

• Quale IP pubblico o interfaccia WAN viene utilizzata?
• Quale porta esterna dovrebbe essere accessibile?
• A quale IP interno viene inoltrato?
• Il porto rimane lo stesso o viene tradotto?
• L’accesso dovrebbe essere consentito da qualsiasi luogo o solo da determinate reti di origine?
• È necessario prendere in considerazione il Source NAT o il Reflexive NAT?
• È necessaria una regola di loopback per i client interni che utilizzano l’FQDN pubblico?
• Verrà pubblicato un solo server interno o più server con bilanciamento del carico?
• Esiste già una regola che utilizza la stessa porta?
• Il firewall Sophos si trova direttamente in Internet o dietro il router del provider?
• È necessario aprire regole aggiuntive in un gruppo di sicurezza cloud?

Queste informazioni impediscono conflitti successivi con le regole NAT o firewall esistenti.

Se i termini Original source, Original destination, Translated destination, Translated service, Loopback o Reflexive Rule non sono ancora chiari, leggere prima Comprensione del NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT. Questa pagina si concentra sulla pubblicazione specifica di un servizio interno.

DNAT, WAF, VPN o ZTNA?

Non tutti i servizi accessibili al pubblico dovrebbero essere pubblicati automaticamente tramite DNAT. DNAT è tecnicamente semplice, ma anche molto diretto: il firewall inoltra una porta a una destinazione interna. Se ciò abbia senso dipende dal servizio, dalle fonti e dalla necessità di protezione.

• Servizio non HTTP con origini chiaramente definite: DNAT con stretta restrizione della fonte, registrazione e IPS.
• Applicazione HTTP o HTTPS pubblica: controllare innanzitutto Sophos Firewall WAF.
• Accesso amministrativo come SSH o RDP: per singole destinazioni fisse utilizzare Clientless SSL VPN, altrimenti VPN, ZTNA o un IP di origine fisso invece di un DNAT aperto.
• Accesso solo per pochi partner o sedi: Preferire IP di origine, VPN o connessione da sito a sito.
• L’applicazione dovrebbe essere accessibile internamente ed esternamente con lo stesso nome: Controlla il DNS diviso o la regola di loopback deliberatamente pianificata.

Per le applicazioni web classiche, WAF è spesso un punto di partenza migliore perché è possibile prendere in considerazione nomi host, certificati, percorsi, profili di protezione web e, facoltativamente, l’autenticazione. DNAT dovrebbe essere utilizzato solo per l’accesso amministrativo in casi eccezionali. Se un servizio interno non ha realmente bisogno di essere pubblico, una VPN o un’architettura ZTNA sono solitamente una soluzione più pulita. Le nozioni di base ZTNA esistenti sono disponibili in Come configurare Sophos ZTNA e Crea Sophos ZTNA Gateway.

Se il firewall è dietro un router

DNAT funziona anche se il firewall Sophos non dispone direttamente dell’indirizzo IP pubblico, ma si trova dietro un router NAT del provider.

In questo caso sono necessari due reindirizzamenti:

1. Sul router del provider, la porta pubblica viene inoltrata all’IP WAN del Sophos Firewall.
2. Sul firewall Sophos, la porta viene inoltrata al server interno tramite DNAT.

Molti router di provider offrono il classico port forwarding oppure una funzione come Exposed Host o DMZ Host. Con una funzione host esposta, molte o tutte le porte in entrata vengono spesso inoltrate al firewall. Questo può essere pratico, ma dovrebbe essere protetto con attenzione perché il controllo effettivo spetta interamente al firewall Sophos.

Se non è presente un IP pubblico fisso è possibile utilizzare DynDNS. Sophos Firewall può impostare il DNS dinamico in modo che un nome DNS punti sempre all’IP pubblico corrente. È comunque importante: il port forwarding sul router del provider deve puntare al firewall Sophos.

Con un indirizzo IPv4 pubblico aggiuntivo su un segmento WAN collegato direttamente può ancora mancare la risoluzione ARP a monte. La procedura separata per configurare Proxy ARP su Sophos Firewall è appropriata solo quando una capture dimostra la richiesta e la mancata risposta del firewall; il DNAT non richiede sempre questo passaggio manuale.

Lo stesso principio si applica negli ambienti cloud. Con Azure, la sola regola DNAT sul Sophos Firewall non è sufficiente. Inoltre, nel gruppo di sicurezza di rete devono essere aperte le regole in entrata appropriate, altrimenti il ​​traffico non raggiungerà affatto il firewall.

Configura DNAT e regola firewall

Una pubblicazione sul server è sempre composta da due parti: la regola NAT traduce la destinazione o la porta, la regola firewall consente e controlla il traffico.

Assistente per l’accesso al server o regola DNAT manuale?

Sophos Firewall offre due modalità per pubblicare i server:

• Server access assistant (DNAT): adatto come procedura standard rapida per una singola pubblicazione. L’assistente crea automaticamente più regole e le posiziona in cima alla rule base.
• Regola DNAT manuale: adatta ad ambienti più complessi con alias IP, PAT, bilanciamento del carico, sorgenti specifiche o una progettazione deliberata delle regole. Ogni campo deve essere impostato e testato singolarmente.

La procedura guidata può essere utile perché non solo crea una regola DNAT in entrata, ma a seconda della selezione crea anche una regola di loopback, una regola SNAT riflessiva e la regola firewall appropriata. Ciò consente di risparmiare tempo, ma non sostituisce la verifica delle regole create.

Usare Server Access Assistant

L’assistente è il modo più rapido per una prima pubblicazione. È particolarmente utile quando un singolo server interno deve essere raggiungibile tramite un indirizzo WAN e un servizio chiaro.

Procedura:

1. Aprire Rules and policies > NAT rules.
2. Selezionare IPv4 o IPv6.
3. Selezionare Add NAT rule > Server access assistant (DNAT). In alternativa, l’assistente può essere avviato anche da Rules and policies > Firewall rules > Add firewall rule.
4. In Internal server IP address selezionare il server interno o inserire un indirizzo IP.
5. In WAN IP address selezionare l’interfaccia WAN o l’indirizzo IP pubblico.
6. In Services selezionare il servizio interno, ad esempio HTTPS.
7. In External source networks and devices impostare le sorgenti consentite. Per servizi pubblici, Any è adatto solo se il servizio deve davvero essere raggiungibile da tutto Internet.
8. Controllare le regole e salvare con Save and finish.

L’assistente attiva direttamente le regole create e le posiziona in alto nelle tabelle NAT e firewall. Proprio per questo, dopo il salvataggio serve un review. Una regola generata automaticamente può funzionare tecnicamente e tuttavia essere troppo ampia, troppo alta o denominata male per l’esercizio.

Per una regola loopback generata automaticamente, come destinazione WAN deve essere selezionata un’interfaccia firewall. Se invece viene inserito un indirizzo IP pubblico, l’assistente non crea automaticamente la stessa logica loopback. In molti ambienti, Split DNS resta comunque più trasparente di Loopback NAT.

Dopo aver utilizzato l’assistente, occorre sempre controllare:

• Le regole NAT e firewall sono nella posizione corretta?
• La sorgente è davvero limitata come previsto o è ancora impostata su Any?
• È stata creata una regola loopback anche se Split DNS sarebbe la soluzione più chiara?
• È stata creata una regola reflexive non necessaria per il traffico in uscita del server?
• La regola firewall corrisponde alla zona di destinazione dopo NAT e all’oggetto di destinazione pubblico prima di NAT?

Negli ambienti di produzione, una regola DNAT denominata manualmente e posizionata deliberatamente è spesso più facile da comprendere. L’assistente offre un avvio rapido, ma le regole create richiedono la stessa revisione delle regole configurate manualmente.

Crea una regola DNAT

Un tipico esempio manuale di DNAT pubblica esternamente TCP 443 verso un web server interno in DMZ. La regola traduce solo l’indirizzo di destinazione e, opzionalmente, la porta di destinazione. Non sostituisce una regola firewall.

Procedura:

1. Aprire Rules and policies > NAT rules.
2. Selezionare IPv4 o IPv6.
3. Selezionare Add NAT rule > New NAT rule.
4. Impostare un Rule name parlante, ad esempio DNAT_WEB_DMZ_HTTPS.
5. Scegliere Rule position in modo che le regole DNAT specifiche stiano prima di regole generali.
6. Impostare Original source sulle sorgenti esterne consentite. Usare Any solo per servizi consapevolmente pubblici.
7. Impostare Original destination sull’oggetto host WAN, sull’IP pubblico o sull’interfaccia WAN adatta.
8. Impostare Original service sul servizio raggiungibile dall’esterno, ad esempio HTTPS.
9. Impostare Translated destination (DNAT) sul server interno o sul gruppo server.
10. Lasciare Translated service (PAT) su Original o impostare la porta interna se serve Port Forwarding.
11. Impostare consapevolmente Inbound interface. Per accesso Internet di solito è l’interfaccia WAN; in casi speciali può servire Any.
12. Per DNAT verso server interni, lasciare normalmente Outbound interface su Any, affinché routing e zona di destinazione funzionino correttamente.
13. Attivare Loopback, reflexive rule, Load balancing e Health check solo se servono tecnicamente.
14. Salvare e attivare la regola.

Se è necessario accedere solo a pochi indirizzi IP di origine esterna, la fonte originale non dovrebbe essere Any, ma dovrebbe essere limitata a queste fonti.

Per le pubblicazioni in produzione, un oggetto host per l’IP pubblico è solitamente più chiaro della selezione diretta di un’interfaccia WAN. L’oggetto rimane tracciabile se in seguito cambiano interfacce, indirizzi alias o dettagli del provider.

Comprendere correttamente Original e Translated

Quando si tratta di regole NAT, la distinzione tra Originale e Tradotto è importante.

• Origine/destinazione/servizio originale descrive il traffico nel momento in cui arriva al Sophos Firewall.
• Origine/destinazione/servizio tradotto descrive il traffico che lascia il Sophos Firewall dopo la traduzione.

Per una regola DNAT in entrata ciò significa:

• Destinazione originale è l’indirizzo IP pubblico o WAN del firewall.
• Servizio originale è la porta esterna a cui si rivolge il client.
• La destinazione tradotta (DNAT) è il server interno.
• Servizio tradotto (PAT) è la porta interna sul server di destinazione se la porta deve essere tradotta.
• La fonte tradotta (SNAT) solitamente rimane su Originale con le normali regole DNAT.

Port forwarding e PAT

Il port forwarding è tecnicamente un servizio di traduzione. Su Sophos Firewall, a questo scopo viene utilizzato il Servizio di traduzione (PAT).

Esempio:

• Esterno: TCP 20120
• Interno: TCP 22

Il client esterno si connette sulla porta 20120, ma il firewall Sophos inoltra internamente sulla porta SSH 22. Ciò può essere utile, ma non sostituisce le restrizioni di accesso. La modifica della porta esterna può ridurre il rumore di fondo, ma non rende sicuro il servizio.

Importante: il protocollo deve rimanere lo stesso. TCP può essere tradotto in un’altra porta TCP, UDP in un’altra porta UDP. Da TCP a UDP non è una traduzione di porta valida.

Se HTTPS è pubblicato, è necessario verificare anche se ci sono conflitti con WebAdmin o Portale Utenti del Sophos Firewall. Per impostazione predefinita, la console di amministrazione utilizza la porta HTTPS 4444, il portale utente utilizza la porta HTTPS 443. In caso di sovrapposizioni è necessario separare chiaramente le porte proprie del firewall o quelle dei servizi pubblicati.

Pianifica consapevolmente l’IP di origine e il percorso di ritorno

Per una normale pubblicazione DNAT, la Fonte tradotta (SNAT) dovrebbe rimanere generalmente su Originale. Il server interno vede così il vero IP sorgente esterno. Questo è importante per i log del server, i rate limit, i meccanismi di protezione simili a Fail2Ban, i log applicativi, l’analisi WAF o reverse proxy e le successive indagini sugli incidenti.

SNAT al firewall o un indirizzo interno potrebbero comunque essere necessari se il percorso di ritorno non passa altrimenti attraverso il firewall Sophos. Ciò è possibile, ad esempio, se il server pubblicato utilizza un gateway predefinito diverso, si trova in un segmento di routing esterno o presenta una situazione di routing asimmetrico.

La decisione dovrebbe essere presa consapevolmente:

• La fonte rimane Original: Il server vede l’IP esterno reale. Il percorso di ritorno deve passare in modo pulito attraverso il firewall.
• La fonte è tradotta tramite SNAT: Il percorso di ritorno è più facile da controllare. Il server vede solo il firewall o l’IP SNAT, l’IP del client reale viene perso nel registro del server.

Se un servizio funziona solo con SNAT, non dovresti semplicemente mantenerlo e lasciare l’argomento alle spalle. È meglio verificare prima se è possibile correggere la progettazione del gateway, del percorso, della VLAN, del firewall del server o del routing. SNAT può rappresentare una soluzione alternativa legittima, ma rende più difficile l’analisi successiva.

Durante il test, dovresti sempre controllare quale IP di origine vede effettivamente il server. Se invece dell’IP del client esterno viene visualizzato solo l’IP del firewall, è necessario documentare chiaramente se ciò è intenzionale.

Controlla la regola del firewall

Una regola NAT da sola non consente automaticamente il traffico. Inoltre è necessaria una regola firewall adeguata.

Con DNAT la visualizzazione nella regola del firewall è insolita perché il firewall deve conoscere contemporaneamente l’accesso originale dall’esterno e la destinazione interna tradotta.

La regola pratica più importante:

⚠️ Con DNAT, la regola del firewall utilizza la zona di destinazione dopo NAT, ma la rete di destinazione prima di NAT.

L’ordine di elaborazione è importante: per il traffico in ingresso, Sophos Firewall cerca prima la regola DNAT corrispondente e determina così la destinazione tradotta. Successivamente viene valutata la regola firewall. Per Destination zone, il firewall utilizza la zona in cui si trova la destinazione tradotta. Per Destination networks, resta invece rilevante l’oggetto di destinazione originale della regola DNAT.

Configurazione tipica:

• Zona di origine: Per lo più WAN quando l’accesso avviene da Internet.
• Reti e dispositivi di origine: Il più limitato possibile, ad esempio IP individuali, reti, paesi o gruppi.
• Zone di destinazione: Zona del server interno tramite DNAT, ad esempio DMZ o SERVER.
• Reti di destinazione: Indirizzo di destinazione pubblico o oggetto host WAN da Original destination.
• Servizi: Servizio esterno da Original service, ovvero la porta a cui accedono i client dall’esterno.
• Profili di sicurezza: A seconda del servizio, IPS, scansione malware, policy web o altro controllo adeguato
• Registrazione: Abilita per i servizi pubblicati

Senza una regola firewall adeguata, il traffico viene rifiutato nonostante il DNAT.

Questo punto è una comune fonte di errore: se si immette il server interno come rete di destinazione, anche se la regola prevede l’oggetto WAN pubblico, la regola non corrisponde. La logica esatta è spiegata in maggior dettaglio nell’articolo Comprensione di NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

L’ordine vale anche per le regole NAT. Sophos controlla le regole NAT dall’alto verso il basso e utilizza la prima regola corrispondente. Una regola NAT superiore troppo generale può quindi impedire l’efficacia della regola DNAT specifica.

Le connessioni già esistenti mantengono la loro traduzione NAT anche se la regola NAT viene modificata in seguito. Per i test dopo una modifica bisogna quindi creare nuove sessioni o terminare pulitamente le vecchie connessioni, altrimenti si rischia di valutare ancora uno stato precedente.

Opzioni NAT avanzate

Queste opzioni diventano rilevanti solo quando i client interni utilizzano nomi pubblici, i percorsi di ritorno devono essere tradotti in modo specifico o quando sono coinvolti più server di destinazione.

Regole NAT di loopback, riflessive e collegate

Sophos Firewall offre diverse opzioni NAT che possono essere facilmente confuse:

• Regola di loopback: aiuta quando i client interni devono raggiungere un server interno tramite l’IP pubblico o il nome DNS pubblico.
• Regola riflessiva: crea una regola SNAT speculare su una regola DNAT in modo che il traffico di ritorno o determinate direzioni opposte vengano tradotti in modo appropriato.
• Regola NAT collegata: creata da una regola firewall ed è una regola SNAT collegata. Una regola NAT collegata non è la stessa cosa di una regola DNAT in entrata per un server pubblicato.

Per le pubblicazioni server classiche, una regola DNAT indipendente più una regola firewall adeguata è solitamente la più chiara. Le regole NAT collegate possono essere utili se una regola firewall richiede direttamente una traduzione SNAT speciale. Tuttavia, in ambienti generali, le regole NAT autonome e chiaramente denominate tendono a rimanere più facili da comprendere e mantenere.

Importante: le regole di loopback e riflessive derivano dalla regola DNAT originale. Se la regola DNAT originale viene successivamente modificata, è necessario controllare separatamente le regole derivate. Altrimenti può succedere che l’accesso esterno sia stato regolato correttamente, ma l’accesso loopback interno o il traffico del server in uscita continuino a funzionare secondo la vecchia logica.

Non è un dettaglio cosmetico. Sophos crea regole loopback e reflexive con riferimento a nome e ID della regola DNAT originale, ma modifiche successive alla regola originale non aggiornano automaticamente le regole derivate. Dopo modifiche a IP pubblico, server di destinazione, servizio o sorgenti, queste regole devono quindi essere aperte e confrontate consapevolmente.

Bilanciamento del carico e controllo dello stato

Quando più server interni vengono pubblicati dietro un IP pubblico, DNAT può essere utilizzato anche per il bilanciamento del carico o il failover.

I metodi possibili sono, ad esempio:

• Round Robin
• Prima viva
• Casuale
• IP permanente
• Uno a uno

Se si desidera che il firewall rilevi se un server di destinazione è disponibile, è necessario configurare un controllo dello stato. Senza un controllo dello stato, il firewall può anche inoltrare il traffico a un server che non può essere raggiunto.

Sicurezza e messa in esercizio

Un servizio pubblicato diventa immediatamente parte della superficie di attacco pubblica. Ecco perché l’accesso ravvicinato, la registrazione, i profili di sicurezza e un chiaro rollback fanno parte del go-live.

Pianifica il go-live e il rollback

Una pubblicazione DNAT deve essere trattata come una piccola modifica di produzione. Non appena la regola è attiva, il servizio può diventare accessibile da Internet. Prima della messa in esercizio occorre quindi documentare quale regola verrà attivata, come verrà testato l’accesso e come eseguire il rollback in caso di problemi.

Controlla prima del go-live:

• Eseguire il backup della configurazione attuale del firewall o almeno documentare le regole NAT e firewall interessate.
• Controlla le regole NAT esistenti per lo stesso IP pubblico, porta esterna e interfaccia WAN.
• Abbinare il router del provider, il gruppo di sicurezza cloud o le regole del firewall upstream alla configurazione di Sophos.
• Considera DNS TTL quando un nome host rimanda all’indirizzo pubblicato.
• Preparare una fonte di test al di fuori della propria LAN, ad esempio telefono cellulare, posizione esterna o test di porta online controllata.
• Imposta le posizioni di registro previste: Visualizzatore registro, ID regola NAT, ID regola firewall, Acquisizione pacchetti e Registro server.
• Definire criteri di rollback, ad esempio servizio errato accessibile, server che non risponde, errore del certificato, profilo di sicurezza che blocca il traffico legittimo o IP di origine imprevisto sul server.

Un semplice rollback solitamente implica la disabilitazione della nuova regola DNAT e della regola firewall corrispondente. Se una vecchia pubblicazione è stata sostituita, dovrebbe essere chiaro se la vecchia regola può essere riattivata o se è necessario reimpostare prima il port forwarding del provider, il DNS o il monitoraggio.

Per i servizi critici, non dovresti modificare più cose contemporaneamente. Se DNS, router del provider, regola NAT, regola firewall e configurazione del server vengono modificati contemporaneamente, è difficile attribuire un errore in seguito. È meglio un processo breve con passaggi chiari: preparare, attivare, testare esternamente, controllare i registri, controllare i server, documentare i risultati.

Limita l’accesso il più strettamente possibile

Non tutti i servizi pubblicati devono essere accessibili da tutta Internet. Se possibile, l’accesso dovrebbe essere limitato.

Restrizioni utili:

• Consenti solo indirizzi IP a sorgente singola.
• Consenti host FQDN noti solo quando l’altra parte utilizza IP dinamici.
• Consenti solo alcuni paesi.
• Bloccare esplicitamente alcuni paesi.
• Consenti l’accesso solo tramite VPN.
• Utilizzare una soluzione ZTNA invece della pubblicazione diretta.

DNAT di solito non è la soluzione migliore per servizi amministrativi come SSH, RDP o portali di amministrazione interni. Se l’accesso non deve essere pubblico, VPN o ZTNA sono quasi sempre la scelta migliore.

Migliora la sicurezza

Per i servizi pubblicati dovresti controllare:

• Il server è attualmente aggiornato?
• Esiste un’opzione WAF o proxy inverso?
• L’IPS è attivo sulla regola del firewall?
• Sono aperti solo i porti necessari?
• Il servizio è registrato?
• Sono previste restrizioni relative all’IP geografico, al feed delle minacce o all’IP di origine?
• È possibile l’AMF se si tratta di un portale?

Per le applicazioni Web, può essere utile anche Web Server Protection/WAF al posto del puro DNAT.

Bot e feed di minacce

Le porte pubbliche come HTTP, HTTPS, SSH o RDP sono costantemente nel mirino dei bot. Non appena una porta è accessibile in Internet, spesso è possibile visualizzare rapidamente nel visualizzatore di log tentativi di connessione, scansioni, tentativi di accesso o sfruttamento del traffico.

Ciò non significa automaticamente che il server sia compromesso. Ma ciò dimostra che il servizio fa parte della superficie di attacco pubblica. Consigliamo pertanto di proteggere ulteriormente i servizi pubblicati con IPS, logging, narrow source e feed di minacce di terze parti.

I feed delle minacce forniscono continuamente al firewall gli attuali indicatori di compromissione, ad esempio indirizzi IP o domini dannosi. Ciò consente al firewall di bloccare aggressori, botnet o scanner noti prima che raggiungano il servizio pubblicato.

Altro: Feed sulle minacce di Sophos Firewall

Prova

Dopo aver salvato la regola DNAT:

• Test da una rete esterna, non dalla stessa LAN
• Controllare solo la porta pubblica prevista, non eseguire scansioni generali con indirizzi stranieri
• Controllare Log Viewer per Firewall Rule ID, NAT Rule ID, Source, Original Destination, destinazione tradotta e stato consentito o scartato.
• Confrontare Packet Capture con source esterna, destination pubblica e destinazione interna.
• Controlla i log del server
• Controlla l’IP di origine visibile sul sistema di destinazione

Se il test deve essere eseguito dalla LAN interna all’IP pubblico, potrebbe essere necessario anche un hairpin NAT o una soluzione DNS interna.

Matrice di test per le pubblicazioni DNAT

Un singolo test della porta raramente è sufficiente per una pubblicazione DNAT in produzione. È meglio usare una piccola matrice di test che separi i percorsi consentiti da quelli indesiderati. In questo modo si verifica non solo se il servizio è raggiungibile, ma anche se restrizioni, log e percorso di ritorno funzionano correttamente.

Sorgenti di test utili:

• Sorgente esterna consentita: testare la connessione da rete mobile, sede esterna o rete partner verso IP pubblico e porta esterna. Nel Log Viewer devono comparire l’ID della regola firewall e l’ID della regola NAT attesi.
• Sorgente esterna non consentita: se la pubblicazione è limitata a sorgenti specifiche, un test da una sorgente non consentita deve fallire intenzionalmente. In caso contrario, la restrizione sulla sorgente è troppo ampia.
• Client interno con nome DNS interno: verificare che gli utenti interni risolvano direttamente l’IP interno del server. Spesso è più pulito del loopback NAT.
• Client interno con FQDN pubblico: testarlo solo se questo accesso è davvero necessario. Se fallisce, controllare prima lo split DNS e non aggiungere automaticamente il loopback NAT.
• Server di destinazione: controllare log del server, firewall locale, servizio in ascolto, certificato e IP sorgente visibile. Così si capisce se il server vede l’IP esterno reale o un indirizzo SNAT.
• Monitoraggio o health check esterno: verificare che il test usi la stessa URL, la stessa porta e la stessa logica di sorgente del monitoraggio reale.

Dopo ogni test va valutato un solo punto: il traffico arriva a Sophos Firewall, la regola NAT attesa corrisponde, la regola firewall attesa corrisponde, il pacchetto raggiunge il server e torna una risposta? Se si modificano più elementi contemporaneamente, l’errore successivo diventa molto più difficile da attribuire.

Un test DNAT pulito mette a confronto tre punti di vista:

• Cliente Esterno: La connessione all’IP pubblico e alla porta esterna funziona o è deliberatamente bloccata.
• Sophos Firewall: Il visualizzatore log mostra l’ID regola firewall e l’ID regola NAT previsti.
• Server interno: Il servizio vede l’IP di origine previsto, risponde tramite il gateway corretto e registra l’accesso.

Se viene esaminata solo una di queste prospettive, gli errori tipici rimangono inosservati. Ad esempio, un test riuscito della porta esterna non dice ancora se la registrazione, l’IPS, le restrizioni sull’origine o i proprietari del server sono adeguatamente documentati.

Risoluzione dei problemi e operazioni

Dopo la messa in esercizio non basta verificare che il servizio sia accessibile. Sono importanti anche Log Viewer, NAT Rule ID, Firewall Rule ID, i log del server e le revisioni periodiche delle pubblicazioni precedenti.

Risoluzione dei problemi

Errori comuni:

• Manca la regola del firewall
• È stato selezionato un IP WAN errato
• Manca il port forwarding sul router del provider
• Il gruppo di sicurezza di rete di Azure blocca la porta
• Il servizio non è in esecuzione internamente
• Il gateway del server non punta al Sophos Firewall
• La regola NAT è sotto un’altra che entra in vigore in anticipo
• La regola del firewall utilizza la rete di destinazione errata in DNAT
• La porta è già utilizzata da un altro servizio
• Loopback mancante quando i client interni utilizzano FQDN pubblico
• Il controllo dello stato è mancante o errato quando si utilizza il bilanciamento del carico
• Il test avviene dalla rete interna e non esternamente
• Il server di destinazione risponde tramite un gateway diverso
• Un profilo di sicurezza blocca il traffico, ma non viene cercato nel registro corretto

Il Visualizzatore registro è il punto di partenza più importante per i problemi DNAT. Qui puoi vedere se arriva traffico, quale regola firewall e quale regola NAT si applicano e se il traffico è consentito o rifiutato. Se l’hit non corrisponde a quanto previsto, La regola del firewall Sophos non si applica: verificare le cause aiuterà.

Per una risoluzione dei problemi più approfondita, non dovresti limitarti a guardare il firewall Sophos. Se il visualizzatore di log consente il traffico e l’acquisizione dei pacchetti mostra che i pacchetti continuano verso il server, la causa è spesso nel sistema di destinazione: firewall locale, gateway predefinito errato, servizio non associato, problema con il certificato, applicazione in ascolto su una porta diversa o proxy inverso upstream che non risponde come previsto.

Una rapida classificazione aiuta a non cercare nel punto sbagliato:

• In Log Viewer non compare alcun hit: Il traffico non raggiunge il firewall oppure viene usato l’IP WAN sbagliato. Controllare router del provider, Cloud Security Group, IP pubblico e Packet Capture su WAN.
• L’ID della regola firewall corrisponde, ma manca l’ID della regola NAT: La regola NAT non corrisponde oppure si trova troppo in basso nell’ordine. Controllare Original destination, Original service, interfaccia in ingresso e ordine NAT.
• L’ID della regola NAT corrisponde, ma il servizio non risponde: Il server di destinazione o il percorso di ritorno non è corretto. Controllare firewall del server, gateway predefinito, routing e Packet Capture verso il server.
• Funziona dall’esterno, ma non internamente tramite FQDN: Manca Split DNS o loopback. Controllare la risoluzione DNS interna e aggiungere loopback solo consapevolmente.
• Dopo una modifica dell’assistente, solo una parte si comporta in modo errato: Una regola loopback o reflexive derivata non è più adatta. Controllare singolarmente le regole NAT e firewall generate.

SMTP tramite DNAT dopo l’upgrade a SFOS 22

Se, dopo un upgrade a SFOS 22, le e-mail in ingresso vengono consegnate sporadicamente in ritardo o non vengono consegnate affatto, NC-184583 può essere la causa. Sophos indica esplicitamente SFOS 22.0 GA Respin Build 411 come versione interessata, ma descrive il problema più in generale per gli upgrade a v22.x. MR1 e MR2 non sono indicate separatamente né tra le versioni interessate né tra quelle corrette. Come fix è riportata soltanto SFOS 23.0 EAP0 Build 253: una versione EAP che non dovrebbe essere installata indiscriminatamente su un sistema di produzione. Non è disponibile un workaround pubblico; Sophos rinvia al supporto.

Un test sulla porta TCP 25 non è sufficiente in questo scenario. Occorre inviare più messaggi reali controllati e annotare l’ora UTC, il mittente, il destinatario e il Message-ID. Successivamente si confrontano la coda del mittente o il bounce con la coda e il Transport Log del mail server interno. Il pacchetto di evidenze per il supporto deve includere build del firmware, timestamp, Rule IDs, fwlog.log, firewall_rule.log, nat_rule.log e i log del mail server. I percorsi dei log e il download del Consolidated Troubleshooting Report sono descritti in Verificare servizi e log di Sophos Firewall tramite CLI. Nel caso di supporto, NC-184583 deve essere menzionato esplicitamente.

Il Known Issue riguarda il percorso DNAT diretto verso il mail server interno. In Sophos Firewall MTA Mode, il firewall riceve direttamente il messaggio e poi lo inoltra. Sophos tuttavia non conferma né che MTA Mode sia sicuramente esclusa dal problema né che una migrazione costituisca il workaround ufficiale.

Quando anche Black Hole DNAT è utile

Se un servizio deve deliberatamente rimanere accessibile al pubblico, ma alcune fonti devono essere intercettate prima della pubblicazione effettiva, può avere senso una regola DNAT del buco nero al di sopra della regola DNAT produttiva. Questo funziona, ad esempio, per elenchi di IP dannosi noti, paesi permanentemente indesiderati o fonti di scansione ricorrenti.

Questa tecnica non sostituisce una pubblicazione correttamente protetta. La regola DNAT di produzione deve restare strettamente limitata, il logging deve essere attivo e il server pubblicato deve essere mantenuto aggiornato. Black Hole DNAT aggiunge un livello di blocco a monte della pubblicazione, ma non costituisce l’architettura di sicurezza vera e propria.

Black Hole DNAT è particolarmente utile in questi casi:

• Le fonti di scanner ricorrenti raggiungono lo stesso servizio pubblicato: Le fonti non possono arrivare a nulla di fronte alla regola produttiva del DNAT.

• I singoli paesi non dovrebbero avere accesso al port forwarding: La regola di blocco può essere posizionata sopra l’effettiva regola DNAT.

• Esiste già un gruppo IP danneggiato: Il gruppo può essere utilizzato come Original source della regola del buco nero.

• Un servizio deve rimanere pubblico, ma dovrebbe ricevere meno traffico bot: La regola produttiva viene mantenuta, le fonti indesiderate vengono intercettate in anticipo

Black Hole DNAT non è adatto per servizi firewall locali come WebAdmin, Portale Utenti, Portale VPN o SSH per il firewall stesso. Accesso al dispositivo e Regole di eccezione ACL del servizio locale sono responsabili di ciò. Per i server Web tramite WAF, è necessario prima controllare la regola WAF, i paesi bloccati, l’autenticazione e i registri WAF.

L’ordine è importante: la regola DNAT del buco nero deve essere al di sopra della regola DNAT produttiva. Dovresti quindi verificare nel visualizzatore di log se le fonti bloccate soddisfano davvero la regola del buco nero e se le fonti autorizzate continuano a utilizzare la regola NAT e firewall produttiva. La procedura esatta è disponibile in Sophos Firewall: blocco di paesi e IP dannosi.

Verifica operativa

Le regole DNAT devono essere revisionate periodicamente. Le pubblicazioni obsolete rappresentano un rischio frequente perché i servizi possono rimanere accessibili anche dopo lo spostamento, la sostituzione o la fine dell’utilizzo dell’applicazione.

Per le regole DNAT di produzione occorre documentare almeno quanto segue:

• Scopo della pubblicazione: La documentazione deve spiegare perché il servizio è accessibile al pubblico.
• Persona o team responsabile: Senza un responsabile, le pubblicazioni obsolete vengono rimosse di rado.
• IP pubblico e porta esterna: Facilita test, monitoraggio e scansioni esterne
• Server di destinazione interno e porta di destinazione: Importante per le migrazioni dei server, il bilanciamento del carico e le modifiche ai certificati
• Fonti previste: Aiuta a determinare se Any è davvero necessario
• Misure protettive: IPS, alternative WAF, MFA, feed delle minacce, registrazione e stato delle patch devono essere tracciabili
• Data di scadenza o data di revisione: Le pubblicazioni temporanee richiedono una data di fine chiara.

Una revisione utile non consiste soltanto nel guardare la regola. Occorre verificare dall’esterno che siano aperte solo le porte previste, controllare in Log Viewer quali sorgenti accedono realmente e confermare sul server di destinazione che l’applicazione sia ancora mantenuta. Se il servizio è necessario solo internamente o per pochi partner, devono essere rivalutati VPN, ZTNA, una restrizione dell’IP sorgente o una regola WAF.

Quando rimuovi le vecchie regole DNAT, non dovresti eliminare semplicemente la regola NAT. Ad esso sono spesso allegati regole firewall, oggetti host, oggetti servizio, regole di loopback, regole riflessive, voci DNS, controlli di monitoraggio o port forwarding del provider. È meglio un breve processo di smantellamento:

1. Controlla gli ultimi accessi nel visualizzatore log.
2. Chiedere alla persona o al dipartimento responsabile di confermare che il servizio non è più necessario.
3. Disattivare innanzitutto la regola NAT e la regola firewall corrispondente.
4. Verificare esternamente se la porta è chiusa.
5. Verificare la presenza di errori nel monitoraggio e nei registri del server.
6. Solo allora ripulite gli oggetti, le voci DNS e le regole del provider che non sono più necessarie.

Se la pubblicazione è ancora necessaria, la revisione deve produrre un risultato concreto: mantenerla invariata, restringerla ulteriormente, migrarla a WAF, collocarla dietro VPN/ZTNA oppure riesaminarla entro una data di scadenza definita.

Domande frequenti