Sei sulla pagina 1di 6

---------NAT----------

Definire un PORT-FORWARDING per poter raggiungere una macchina interna nella LAN, un tipico esempio
di DMZ. Esempio di DNAT su un FW che si trova dietro a una CPE del cliente a difesa del perimetro. E’
possibile realizzare un PORT-FORWARDING in 2 modi:

1. Utilizzare come DNAT un IP di una subnet che è instradata sulla CPE dal SP, quindi oltre all'IP
pubblico della CPE che si presenta all'esterno, il provider potrebbe aver instradato altre subnet
pubbliche verso la CPE da usare lato LAN, quindi utilizziamo un IP libero sulla stessa rete che c'è tra
la P2P fra la CPE e il FW.
2. La CPE non ha ulteriori IP pubblici a disposizione quindi il nostro FW avrà un IP privato, e dovremo
fare o 2 PORT-FORWARDING e quindi 2 DNAT, con un NAT statico sull'interfaccia della CPE che si
presenta all'esterno e poi gestire il DNAT tramite il FW ulteriormente. Lo facciamo 2 volte perché:
ogni volta che si fa un NAT non rimane traccia nel pacchetto, sia nel traffico di uscita quando
facciamo un SNAT, sia nel traffico in ingresso dall'esterno quando facciamo un DNAT, cambiamo
solo gli indirizzi e quindi la checksum dell'intestazione del pacchetto.

Un pacchetto quando arriva ad un CPE o FW potrebbe essere stato già nattato n volte, senza che ce ne
accorgiamo, ciò vuol dire che poi il traffico per essere gestito correttamente deve ritornare per lo stesso
percorso che ha intrapreso nella parte opposta altrimenti si perderà l'informazione che serve a ricostruire il
flusso dati. Le macchine che fanno NAT mantengono uno storico di come deve essere gestito il traffico di
ritorno. Quindi il doppio DNAT viene fatto perché poi dovremmo fare anche una FW policy che mi può
anche sollecitare l'uso dell'UTM col richiamo dei security profile ispezionando meglio il traffico, per
proteggere meglio la macchina di destinazione e cioè l'eventuale server nella DMZ
Col DNAT c'è da ricordare però che il FW abbina il termine di VIP (virtual IP), che è un NAT 1:1, con un ip
esterno mappato con un IP interno e se abbiamo 10 pc interni, possono essere rappresentati anche da 1
singolo VIP senza dover creare per forza 10 VIP esterni per 10 IP interni.
La regola del DNAT se considera anche la porta di destinazione si parla di PORT-FORWARDING, quindi
quando sui FG si parla di PORT-FORWARDING è un DNAT basato sulle porte e perciò bisogna pensare ai VIP
e di conseguenza creare un VIP.

Esercizio pratico DI PORT-FORWARDING nel LAB:


Le richieste sulla porta 8080 sul FG-1 le vogliamo girare al FGM (Il FGM ha una licenza abbinata all'indirizzo
di gestione): se devo fare un port-forwarding su 2 porte diverse devo per forza creare 2 vip a differenza
degli ip. Creiamo un vip nel menù della GUI in policy&object, se vogliamo lavorare senza central-nat
dobbiamo disabilitarlo dalla CLI, dopo la modifica se sono già dentro la GUI devo fare il log-out e log-in.

FG-1# conf sys settings


FG-1# set central-nat disable
FG-1# end

A livello di Kernel della macchina, il DNAT avviene prima del routing (quindi è un pre-routing) e del policy
LOOKUP. Il DNAT si applica sulla interfaccia che si interfaccia all'esterno e quindi mapperemo l'IP esterno
dell'interfaccia con l'IP interno. Infine attiviamo anche il flag su PORT-FORWARDING mappando la porta
external 8080 (alternative http port) sulla porta 443 del FGM.
Utilizziamo la 8080 e no la 443 come External Port, perché la 443 è già utilizzata dalla GUI del FG1.
Per attivare il VIP dobbiamo creare una FW policy, perché il Central-NAT è disabilitato. Questo anche
perché il DNAT avviene prima del policy LOOKUP e questo è uno dei motivi del perché hanno introdotto il
Central-NAT oltre al perché si ha una maggiore granularità dei controlli.
Il DNAT pur essendo un'attività che avviene prima del policy LOOKUP, in assenza del Central-NAT, ci vuole
una policy che vada a richiamare il vip.
Se abbiamo configurate 2 o più interfacce in ingresso e/o in uscita, noteremo che dall'interfaccia GUI in alto
a destra non sarà possibile flaggare la voce "Interface Pair View:

Da tenere bene a mente che se vogliamo delle policy con più interfacce in ingresso o in uscita, dalla CLI è
immediatamente disponibile, invece dalla GUI dobbiamo abilitarlo da SYSTEM>FEATURE
VISIBILITY>MULTIPLE INTERFACE POLICIES

Nella policy indicheremo come porta di ingresso quella su cui ci presentiamo e cioè in questo caso da
internet, come porta di uscita quella collegata verso il FGM, come source IP ALL oppure HOST ONLY e come
Destination Address utilizzeremo l'IP del VIP, nel service invece dovrò indicare la porta HTTPS e non la
porta esterna 8080, questo perché la policy viene dopo il DNAT e quindi non c'è dubbio che dovrò indicare
la porta interna 443 e quindi non ho la necessità di creare un servizio ad hoc che rappresenti la porta
esterna 8080.
Inserendo il VIP come Destination abilita il DNAT.
Il flag "NAT" della policy sulla GUI, indica il SNAT, se è abilitato significa che eventualmente il nostro FGM
vedrà arrivare il traffico 443 non dall'IP source originario del client in internet, ma eventualmente dall'IP
dell'interfaccia di uscita o di un pool. Questo è utile quando una macchina interna raggiungibile da Internet
non è supportata da un Routing interno che consenta poi l'uscita
Su internet, così in questo modo forzeremo il traffico di ritorno del client interno verso il FW su cui è
flaggato il SNAT. Questo è utile per proteggersi da scenari DUAL HOMED o MULTI-HOMED con più provider
e quindi più uscite verso internet, perché altrimenti la macchina interna potrebbe raggiungere il suo Source
IP per strade alternative, andando a contattare un'altra macchina tipo uno Switch di L3 e quindi non
intercettando nella direzione del ritorno la macchina in grado di gestire il NAT. Quindi il SNAT è una
protezione da scenari che hanno più uscite verso Internet e pertanto serve a forzare il traffico di ritorno
utilizzando lo stesso percorso da cui abbiamo ricevuto il traffico.
Questo perché il Routing è sempre indipendente in un verso e nell'altro, quindi non è detto che il traffico di
ritorno utilizzi lo stesso percorso da cui ha ricevuto il traffico e quindi potrebbe utilizzare macchine terze.

BEST PRACTICE: non aprire in genere più porte di quelle necessarie e cioè evitare l'ANY nel service.

Quando nel service inseriamo l'HTTPS, chi ci garantisce che sia effettivamente traffico web generato da un
browser e che vada a contattare un server web? quindi in questo caso andremo a proteggerci andando ad
applicare una SSL INSPECTION per poter fare una DEEP INSPECTION, dopo andremo a fare una Application
control oppure un sistema di reverse PROXY (che serve a nascondere i server, mentre un PROXY lato client
serve a nascondere appunto i client) cioè per essere sicuri che il traffico 443 sia effettivamente un servizio
HTTP. Se creiamo una nuova policy che blocca tutto il traffico dalla port3 alla porta1, con un ANY-ANY e la
spostiamo in testa alla policy che mi richiama il VIP, non bloccherà il traffico della policy che ha come
Destination il VIP, in quanto il DNAT avviene prima del policy LOOKUP e quindi tutte le policy che hanno il
VIP vengono elaborate prima di tutte le policy normali e non sono confrontabili con queste ultime ma solo
con le policy che hanno un VIP, questo ovviamente perché siamo in assenza del Central-NAT e quindi
abbiamo bisogno delle firewall policy per gestire il traffico in ingresso e in uscita dal FW.

Quindi quando non abbiamo il Central-NAT abilitato e dobbiamo fare troubleshooting sul funzionamento di
un PORT-FORWARDING ricordarsi che le policy con i VIP si confrontano solo con le policy con i VIP e non
con le altre, questo perché il DNAT avviene prima.
Magari un altro problema del PORT-FORWARDING è che abbiamo dimenticato di abilitare il SNAT e quindi
non viene forzato il traffico di ritorno.

------CENTRAL NAT----------
Altri FW hanno già una funzionalità tipo il Central-NAT quindi non è un concetto esclusivamente creata da
FG. Per FG il Central-NAT vuol dire specificare le regole di NAT su altre tabelle e non sulle policy table.

Se per esempio lo abilitiamo in presenza di un VIP regolare (tramite CLI):


#conf sys settings
#set central-nat enable
#end
Mi apparirà in console un msg di allarme "cannot enable central-nat with firewall policy using vip (id=1)."
---> "non posso abilitare il CNAT perché mi stai richiamando il VIP già presente nella policy e va in contrasto
con il processo e il modo di funzionare del CNAT, quindi il DNAT o PORT-FORWARDING dovrà essere
definito su un'altra tabella o nessuna tabella.
Per far funzionare il CNAT devo eliminare la policy e no il VIP, se la disabilito senza eliminarla continuerò ad
avere il msg di warning, questo perché per il FG non devo avere nulla che fa riferimento al VIP e quindi
devo riscrivere il PORT-FORWARDING.
Per vedere poi se il CNAT è attivo dobbiamo sloggarci e riloggarci dalla GUI e dopo vedremo nel menù
policy&objects la voce Central SNAT e DNAT & Virtual IPs. Il VIP configurato precedentemente rimane
configurato e non dobbiamo quindi modificare nulla nel VIP.

Non potendolo richiamare più nelle policy, ciò vuol dire che il DNAT è immediatamente attivo. Con il CNAT,
il DNAT avviene automaticamente alla presenza di un VIP. Quindi per vedere se c'è un PORT-FORWARDING
basta andare sui VIP, ma comunque la policy deve essere presente, perché dobbiamo istruire chi passa e
chi non passa e la provenienza del traffico in quanto nel VIP non è specificato, perderemmo anche la
possibilità di applicare degli UTM e cioè dei security profile. Allora dobbiamo andare a creare la policy che
consente il traffico in ingresso e in uscita verso la destinazione che ci interessa, però in questo caso tra i
firewall address non avremo più disponibile nella tabella il VIP che abbiamo prima creato, questo perché il
DNAT è già avvenuto e quindi dovremmo creare come firewall address (che sarebbe un nuovo oggetto) l'IP
del server di destinazione o macchina che intendiamo raggiungere. Quindi in presenza di CNAT il vip è
automaticamente attivo e non abbiamo bisogno di creare una policy che lo richiami, la policy normale verrà
processata dopo e allora troverà come destinazione l'indirizzo già nattato.

PS: dopo noteremo che non sarà presente più il flag SNAT sulla GUI, ma se lo vogliamo dovremmo andare a
definirlo in una tabella a parte.
Nel caso in cui inserisco come destinazione l'IP del server, a questo punto con la policy in testa BLOCK ALL,
non riuscirò ad accederci perché essendo policy dello stesso tipo e quindi confrontabili, il traffico verrà
bloccato. Il FGM in questione ha problemi di Routing interno, non raggiunge il nostro FG perché ha come
gateway impostato una terza macchina e quindi il traffico di ritorno segue un altro percorso e non arriva al
nostro FW. Perciò andremo a modificare il gateway con l'IP del nostro FW dicendo alla macchina, che
quando viene contattata dall'esterno deve rispondere utilizzando il nostro FW FG. Andremo a modificare
sul FGM il Gateway:

#show system route


#config system route
#edit 1
#set device "port2"
#set gateway 10.200.1.254
#end

#conf sys route


#edit 1
#show full
#set gateway 10.0.1.254
#end
-----------su FG1------------
Se non funziona ancora il flusso facciamo Troubleshooting sul FG1 con i seguenti comandi:

#diag sniffer packet any "tcp and (port 8080 or port 443)" 4 (per vedere l'intestazione IP e il nome
dell'interfaccia) 5 (il n° di righe che vogliamo vedere) per evitare problemi di Routing possiamo creare un
Central SNAT per la stessa policy, facendo in modo che il traffico verso il FGM sia riconosciuto proveniente
dal nostro FG1 come sorgente, in modo tale che il FGM non richiami come gateway altre macchine terze.
Quindi il SNAT sarà una garanzia che il traffico di ritorno passi dalla macchina che ha fatto effettivamente
NAT. Però per farlo partire dobbiamo creare la regola apposita, in modo tale che quel traffico venga nattato
andando nel menù GUI policy&Objects>Central SNAT, in quanto nella policy creata precedentemente, non
esiste più il flag "NAT" e quindi non è possibile specificare il SNAT. Tale regola prescinde dalla policy, in
quanto la policy consentirà solo il traffico e poi con la regola SNAT creata verrà nattato senza nessun
esplicito richiamo.

Per verificare il SNAT all'opera darò di nuovo il comando diag:

#diag sniffer packet any "tcp and (port 8080 or port 443)" 4 (per vedere l'intestazione IP e il nome
dell'interfaccia) 5 (il n° di righe che vogliamo vedere)

---PROXY ESPLICITO E IMPLICITO---

Utilizzeremo il FG1 cm web proxy per accedere alla navigazione web che ci verrà fornita nel nostro caso dal
FG2 che verrà riconosciuto come Gateway. Quindi verrà intercettato il traffico web tra i 2 FW, e abbiamo
utilizzato 2 FW in quanto se avremmo usato solo il FG1 usando già noi per uscire su internet avremmo
creato un LOOP. Configuriamo il FG2 affinché la porta collegata al Cloud ricevi l'IP e poi verifichiamo il
Routing.

FG2 # conf sys int


FG2 # edit port10
FG2 # set mode dhcp
FG2 # end
FG2 # get sys int physical
FG2 # get router info routing-table all ---> controlliamo se viene instradato il traffico verso internet dal
FG2.

Andremo a creare un altro PORT-FORWARDING per entrare nella GUI di FG2 tramite FG1:

FG1# conf sys int


FG1# edit port10
FG1# set allowaccess https http ping
FG1# end

Utilizziamo la porta 8081 per FG2, entriamo nella GUI di FG1 e creiamo un altro VIP:
Policy&Objects>DNAT&VirtualIPs--> porta3 esterna del FG1 ---> IP esterno della porta3 di FG1 -->
---> indirizzo interno mappato della porta2 di FG2 --> abilitiamo il PORT-FORWARDING e mappiamo la
porta esterna 8081 sulla porta interna 443. Dopo creiamo una policy IPv4 per permettere il traffico, ma non
richiamerà il VIP perché non può farlo e quindi utilizzerà come destinazione l'IP reale del FG2.
Dopodiché dobbiamo nattare anche il traffico sorgente dell'interfaccia di uscita di FG1 che va verso il FG2,
perché altrimenti il FG2 non saprà come raggiungere con il traffico di ritorno l'interfaccia di FG1 e quindi
andiamo a creare la regola Central SNAT.

Infine entriamo nella GUI di FG2 per creare una policy che consenta il traffico in uscita verso Internet.
Verifichiamo sempre prima se c'è qualche policy che può creare conflitto, ma sulle porte di nostro interesse
non c'è nulla quindi possiamo crearla. Come Sorgente inseriremo l'IP dell'interfaccia del FW FG1 che fa da
proxy e che è collegata al FG2 che funge da server web. Quindi il nostro browser web instaura una
connessione TCP col proxy web (FG1) e il proxy instaura una connessione TCP con il server web (FG2).
Infine abilitiamo il NAT sorgente direttamente dalla policy perché non abbiamo CNAT su FG2, e anche
perché nel nostro esempio la nuvola NAT non saprebbe nattarlo in quanto è abilitato per servire il NAT solo
sul collegamento verso FG2 e quindi tutto il traffico che uscirà dal proxy dovrà risultare come se fosse stato
generato dal FG2, altrimenti la nuvola NAT non funzionerebbe.

Esempio nel nostro LAB di proxy esplicito e implicito:

Alla fine di tutto possiamo procedere alla configurazione del nostro proxy.