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.

L’articolo spiega quali punti dovresti controllare prima e dopo una regola DNAT e come garantire il più fedelmente possibile il rilascio.

Pianificazione prima della pubblicazione

Prima del rilascio di DNAT dovrebbe essere chiaro se il servizio deve davvero essere accessibile al pubblico e quale variante tecnica è più adatta. Una buona pianificazione previene l’apertura di porte, la duplicazione delle regole NAT e la difficoltà di tracciare percorsi di ritorno.

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, RDP o portale di amministrazione interno: Se possibile, VPN, ZTNA o IP di origine fissa anziché 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.

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:

• ****Assistente per l’accesso al server (DNAT): custodia standard rapida per una singola versione. crea più regole automaticamente e le inserisce in cima alla rule base.
• Regola DNAT manuale: ambienti più complessi con alias IP, PAT, bilanciamento del carico, origini speciali o progettazione di regole deliberate. Ogni campo deve essere impostato e testato tu stesso.

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.

Dopo aver utilizzato l’assistente dovresti sempre controllare:

• Le regole NAT e firewall sono nella posizione corretta?
• La sorgente è davvero così ristretta come previsto o è ancora a Any?
• È stata creata una regola di loopback anche se il DNS diviso sarebbe una soluzione più pulita?
• È stata creata una regola riflessiva che non è necessaria per il traffico del server in uscita?
• La regola del firewall corrisponde alla zona di destinazione dopo NAT e all’oggetto di destinazione pubblico prima di NAT?

Per gli ambienti produttivi, una regola DNAT denominata manualmente e posizionata deliberatamente è spesso più facile da comprendere. La procedura guidata è utile per un avvio rapido, ma le regole create appartengono alla stessa revisione delle regole create manualmente.

Crea una regola DNAT

Un tipico esempio di DNAT:

• Sorgente originale: Any o reti di sorgenti definite
• Destinazione originale: interfaccia WAN-IP o WAN
• Servizio originale: HTTPS
• Destinazione tradotta: server interno
• Servizio di traduzione: porto di destinazione invariato o interno

Procedura:

1. Apri Regole e politiche.
2. Passa all’area Regole NAT.
3. Seleziona Aggiungi regola NAT > Nuova regola NAT.
4. Definire la fonte, la destinazione e il servizio originali.
5. Impostare la destinazione tradotta sul server interno.
6. Facoltativamente, impostare il Servizio di traduzione.
7. Controlla consapevolmente l’interfaccia in entrata e in uscita.
8. Salva e attiva 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 condivisioni di produzione, un oggetto host per l’IP pubblico è solitamente più pulito rispetto alla selezione diretta di un’interfaccia WAN. L’oggetto rimane tracciabile se le interfacce, gli indirizzi alias o i dettagli del provider cambiano successivamente.

Comprendere l’originale e tradotto correttamente

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 versione DNAT, la Fonte tradotta (SNAT) dovrebbe rimanere per lo più su Originale. Quindi il server interno vede il vero IP di origine esterno. Ciò è importante per i log dei server, i limiti di velocità, i meccanismi di protezione simili a Fail2Ban, i log delle applicazioni, la valutazione WAF o proxy inverso e la successiva analisi degli 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.

Incarico tipico:

• 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’ordinanza si applica anche alle regole NAT. Sophos controlla le regole NAT dall’alto verso il basso e utilizza la prima regola corrispondente. Una regola NAT di cui sopra che sia troppo generale può quindi impedire l’efficacia della regola DNAT specifica.

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.

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.

Copertura e go-live

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 versione DNAT dovrebbe essere trattata come una piccola modifica alla produzione. Non appena la regola è attiva, è possibile accedere al servizio da Internet. Pertanto, prima del go-live, dovrebbe essere chiaro quale regola verrà attivata, come verrà testato l’accesso e come tornare indietro 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 il Visualizzatore registro per l’ID regola firewall e l’ID regola NAT
• Confronta l’acquisizione dei pacchetti con fonte esterna, destinazione 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 il go-live, non dovresti solo verificare se il servizio è accessibile. Sono importanti i visualizzatori di log, l’ID della regola NAT, l’ID della regola del firewall, i log del server e le revisioni regolari delle vecchie versioni.

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.

Quando Black Hole anche il DNAT aiuta

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 il rilascio pulito. La regola DNAT produttiva deve essere ancora rigida, il logging deve essere attivo e il server pubblicato deve essere mantenuto aggiornato. Black Hole DNAT è un ulteriore livello di blocco prima di un rilascio, non l’effettiva architettura di sicurezza.

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 dovrebbero essere riviste regolarmente. Le vecchie versioni rappresentano un tipico rischio per la sicurezza perché i servizi pubblicati spesso rimangono accessibili anche se l’applicazione è stata spostata, sostituita o necessaria solo temporaneamente da tempo.

Per le regole DNAT produttive, dovrebbe essere documentato almeno quanto segue:| punto | Warum er wichtig ist |

• Zweck der Freigabe: Successivamente dovrà essere chiaro il motivo per cui il servizio è accessibile al pubblico
• Persona o team responsabile: Senza un proprietario, le vecchie condivisioni vengono raramente rimosse
• 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: I rilasci temporanei necessitano di una conclusione chiara

Una revisione significativa non consiste solo nel guardare alla norma. Dovresti controllare esternamente se sono aperte solo le porte previste, controllare nel visualizzatore di log a quali fonti accedono effettivamente e controllare sul server di destinazione se l’applicazione è ancora in manutenzione. Se il servizio è necessario solo internamente o per pochi partner, è necessario rivalutare VPN, ZTNA, una restrizione IP di origine 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 è ancora necessaria l’autorizzazione, la revisione dovrebbe concludersi con una conclusione concreta: lasciarlo così com’è, limitarlo in modo più restrittivo, passare a WAF, spostarlo dietro VPN/ZTNA o riesaminare con una data di scadenza.

Domande frequenti