Possiamo accedere al laboratorio in 2 modalità:

1) la porta3 del FG1 è collegata al Cloud dell’Academy, quindi al bridge con la loro rete, che può essere o la
macchina locale e cioè l’interfaccia host-only del player della macchina virtuale VMWARE.
2) Si può accedere direttamente alla Lan del loro laboratorio tramite il client OpenVPN GUI.
*L'istruttore accede ad una VM su un loro server e quindi ha accesso a un POD*

Explicit Proxy:

Configureremo FG1 come Proxy esplicito per gestire le sessioni di navigazione richieste dai browser che
costruirà altrettante connessioni TCP verso il Server Web richiesto.
Quando si ha un Proxy, il browser fa una connessione TCP con il Proxy stesso, e poi il Proxy ne crea una
nuova. Nel nostro esempio, ciò significa che il traffico che attraverserà il FG1 per raggiungere il Server Web,
non sarà un traffico di transito, e quindi non potrà essere gestito con delle normali policy ipv4 ma
occorreranno delle Proxy policy. Quindi in ogni caso il nostro traffico verso il WEB generato da FG-1,
transiterà sul FG-2 dove avremo predisposto una policy ad hoc, e il FG-2 accede ad Internet grazie al
meccanismo NAT (la nuvola nella nostra topologia indicata come NAT-1) incluso nel GNS3. Quindi dal punto
di vista del funzionamento del Proxy, il FG-2 deve semplicemente consentire l’inoltro del traffico verso
Internet. Allora dovremo lavorare su FG-1 per impostarne le opzioni e cioè Proxy policy e Authentication
Rules.

Andiamo a vedere lo stato dell’arte entrando in FG-1 e verifichiamo come è configurato:

FG1# get system interface physical
N.B. per raggiungere la GUI di FG1 si dovrà usare l'IP della porta3 (10.0.99.170) collegato appunto al Cloud.

Nella scorsa lezione, avevamo già configurato il FG-1 affinché ci consentisse l'accesso alla GUI del FG2
realizzando un Port-forwarding con Central Nat abilitato. Quindi per verificare il Port-forwarding che
abbiamo realizzato su FG-1, andremo a vedere quali sono i VIP e ce ne sarà uno che indica l’indirizzo della
Porta3 di FG-1 mappato sulla Porta2 del FG-2:

Questo VIP è già attivo, quindi richiederà semplicemente una policy (da Porta3 a Porta2 di FG-1) che avrà il
transito con destinazione no l’indirizzo IP del VIP ma l'indirizzo IP del FG2:

Se apriamo una nuova scheda sul Browser https://10.0.99.170:8081, accederemo alla GUI di FG2 in quanto
il Port-forwarding è mappato sulla porta 8081.
Sul FG2 è abilitato anche il CNAT, ed è presente la policy che consente il traffico di transito http e https
proveniente dal Proxy (FG-1). Come possiamo notare, Il traffico verso internet è consentito soltanto dal
10.0.12.1/32, il che significa che stiamo comprovando che il traffico in uscita da un Proxy web
effettivamente corrisponde a delle sessioni nuove generate dal Proxy stesso e quindi sarà consentito a
queste Sorgenti presenti nella policy di FG2 l'accesso su internet:
Un Proxy viene definito esplicito quando è invocato direttamente dal browser.
Un Proxy viene definito implicito quando intercetta le connessioni verso l’http, https, ftp, ecc ecc ...e
vengono interrotte e suddivise in 2 connessioni come un normale Proxy all'insaputa del client.

Da GUI andremo a definire il nostro Proxy esplicito:

Nella nostra GUI molto probabilmente non troveremo la voce Explicit Proxy:

Quindi andremo in Feature Visibility per abilitarlo:

Ma quasi sicuramente non lo troveremo neanche in Feature Visibility.

Questo succede perché?

Per lavorare in modalità Proxy, è necessario prima attivare l'Inspection mode in modalità Proxy, perché è
un prerequisito per poter fare Proxy web e anche perché non lo troveremmo n’è in Network e n’è in
Feature Visibility.
Per abilitarlo dalla GUI:

E Quindi si abiliteranno anche un maggior numero di opzioni per ciascun Security profile da poter applicare
agli oggetti Bufferizzati nella memoria.

Dopodiché troveremo la disponibilità dell’opzione Explicit Proxy nelle Feature Visibility e poi una volta
abilitata l’avremo in corrispondenza nella voce Network:

Poi dobbiamo impostare la porta alla quale si mette in ascolto l' Explicit Web Proxy:
Nel nostro Lab FG-1 è in ascolto sulla Porta3 quindi renderà i servizi Proxy disponibili sulla Porta3.
Nel nostro Lab, l’istruttore ha scelto la porta 3128 non a caso (anche se non è una buona scelta), ma
perché è la porta di default del Proxy Web dell'open source che si chiama squid e che spessissimo è
impiegata e quindi ha voluto usare la stessa porta, questo perché nella realtà non si sa mai qualche cliente
dovesse applicare una configurazione tipo al proprio browser e avesse quindi già incluso la porta 3128.

Questo può succedere perché banalmente un cliente facendo una ricerca su Google potrebbe trovare la
porta 3128 e la potrebbe applicare.

Firefox utilizza e gestisce le impostazioni del Proxy in maniera autonoma, mentre Chrome no, e noi
useremo come browser Chrome che usa le impostazioni automatiche di sistema di Microsoft Windows.
Dove imposteremo l'IP della Porta3 del FG1 con la porta 3128 in ascolto e flaggheremo la voce "non usare
server Proxy per indirizzi locali", così il nostro Proxy intercetterà le richieste provenienti da Chrome.
La configurazione automatica di un Proxy avviene con il PAC file, quando ci colleghiamo ad una rete e il
nostro browser rileva automaticamente questo file di configurazione denominato PAC file.
Vuol dire che il nostro browser sta implementando un meccanismo di Discovery automatica della Proxy
Configuration, e questo protocollo si chiama WPAD (Web Proxy Auto Discovery) e funziona in questo
modo:

La configurazione automatica del Proxy fa leva sulla consegna automatica tramite un protocollo di
Discovery, del PAC file. Significa che il nostro browser dovrà richiedere/cercare il cosiddetto PAC file, che
può essere digitato/incluso direttamente tramite il protocollo WPAD, o distribuito manualmente agli utenti
che lo installeranno sui propri browser.

N.B. un browser per richiedere un PAC file deve conoscere l'IP della macchina che lo ospita, e l'IP lo scopro
con il protocollo WPAD e verrà fatta una richiesta del tipo "http://<ip-server-host>/<wpad.dat o pac.dat>"

Il WPAD si implementa in 2 modi:

1) dhcp inform (la inform che è una messaggistica dhcp che chiede al server parametri aggiuntivi o la
conferma di parametri), il browser invia una richiesta inform al DHCP server chiedendo la URL dove
trovare il PAC file.
2) Oppure si fa una richiesta DNS al server cercando i record, ad esempio WPAD.<dominio1>,
WPAD.<dominio2> ecc ecc... e se non trova il record "A" corrispondente al'IP sul dominio1 per
esempio con tutta la sua gerarchia, continuerà con gli altri record <dominio2> , fino ad arrivare
eventualmente al top-level domain, e cioè WPAD.it ecc ecc..
Se il Server DNS intercetta questa Query e restituisse volutamente un IP contraffatto, il browser non
andrebbe ad autenticare ulteriormente e utilizzerebbe quell'IP per andare a scaricare il file <wpad.dat o
pac.dat> e quindi sarebbe forzato a dirigere la navigazione web verso macchine non sotto il nostro
controllo e ciò sarebbe un problema di sicurezza.

N.B il PAC file dalla GUI si modifica cliccando su PAC File Content>EDIT e andremo ad editare l'automatica
configurazione che eventualmente verrebbe sollecitata col WPAD dal Browser.

Il contenuto di un PAC file ha la forma di uno java script, e si legge come:

Esempio:

if (shExpMatch(url, "*.example.com:/*")) {return "DIRECT";} --> se la URL richiesta dal browser dovesse
corrispondere a qualcosa come "example.com" vai diretto, e cioè non utilizzare il PROXY ma vai diretto.

if (shExpMatch(url, "*.example.com:*/*")) {return "DIRECT";} --> gli * prima e dopo vuol dire tutto, prima
del "*.example.com" vuol dire tutto i nomi di dominio, mentre dopo i 2 punti "com:/*" vuol dire tutte le
porte.
if (isInNet(host, "10.0.0.0", "255.255.248.0")) {return "PROXY fastproxy.example.com:8080";} --> se le
destinazioni sono sulla rete "10.0.0.0 255.255.248.0" usa questo proxy (fastproxy sarebbe il proxy da
utilizzare) sulla porta 8080 che viene indicata dopo i :

return "PROXY proxy.example.com:8080; DIRECT"; --> altrimenti su un'altra possibile destinazione vai su
quest'altro proxy

Nel nostro caso lo dovremmo adeguare sul nostro IP e porta in ascolto che stiamo utilizzando, esempio:

return "PROXY 10.0.99.170:3128; DIRECT"; --> il "DIRECT" dopo il ; significa che se il browser dovesse
avere difficoltà nella connessione sulla porta 3128 con questa macchina "10.0.99.170", in alternativa come
failover vai diretto.

Quindi il; dopo la parola PROXY ("PROXY 10.0.99.170:3128;"), significa se perdo la connettività.

N.B: il PAC file è lo script di configurazione del PROXY, che descrive le destinazioni richieste e se queste
devono essere accessibili tramite connessione diretta o tramite PROXY e quindi se c'è un bypass del PROXY
oppure no. Quindi quando vediamo indirizzi IP significa verso quale destinazione dobbiamo andare e mai
sono sorgenti. Per inserire invece manualmente il PAC file nel browser, dobbiamo scaricare il file proxy.pac
cliccando sulla voce "download" presente nella GUI.

N.B. le opzioni sono 2:

1) return "DIRECT"=non usare il PROXY
2) return "PROXY"=usa il PROXY

N.B. se il nostro Browser scopre automaticamente le impostazioni PROXY, vuol dire che non si tratta di un
PROXY implicito ma esplicito, che deriva la configurazione con il protocollo WPAD.

Default Firewall Policy Action>Deny --> non è una policy del FW ma è una PROXY policy, ed è l'azione per
tutte quelle richieste che arrivano al PROXY che non hanno trovato un match nelle PROXY policy.

Quando c'è un PROXY, il browser farà una connessione TCP con il PROXY e il PROXY valutata la necessità di
soddisfarla, farà attraverso Internet la connessione verso il server, quindi poi ci sarà una seconda
connessione TCP che proverrà dall'IP del PROXY.

Esempio di come intercetta una connessione TCP di un Browser un PROXY esplicito:

Quindi il traffico della nostra navigazione si interrompe appena arriva al PROXY e perciò non è gestibile da
una FW policy perché non è un traffico in transito, e quindi dobbiamo definire le cosiddette PROXY POLICY
per far funzionare il nostro PROXY, e le troviamo nella GUI in Policy&Objects>Proxy Policy determina chi
entra e chi esce, però visto che la default ha come Action>Accept e cioè accettare il traffico, potremmo
anche non definirne alcuna, ma ne definiamo una che la useremo per testare 2 elementi fondamentali:

1) PROXY ADDRESS:
Il PROXY ADDRESS significa poter indagare quali metodi http sono utilizzati ed è una categoria di oggetti
che può essere utilizzata nel campo Sorgente per filtrare determinate destinazioni URL (che sono sempre
dei FW ADDRESS specificati però nella destinazione che vanno a lavorare sulle URL) o anche limitare
l'utilizzo di particolare metodi http. L'HTTP si compone di vari comandi/azioni, i cosiddetti verbi, per
esempio l'upload o invio di un file sarà di tipo post, e lo si può limitare (andando a creare una proxy policy e
mettere come Action un DENY) definendolo come metodo http nella Sorgente di una proxy policy.
In ogni caso la scelta del metodo specifico dell'http, si gestisce col proxy address e lo inseriremo nella
Sorgente (il metodo HTTP si può definire solo come Src e non dst) della proxy policy.

Esempio: "metodi HTTP per limitare upload di un file in proxy policy":

La sorgente indica che tipo di richiesta facciamo al PROXY (es. HTTP, HTTPS) e quando si inseriscono sia
nelle Fw policy che nelle proxy policy, 2 o più oggetti di diverso tipo, la condizione/opzione diventa un
"AND" logico e non un "OR" (e cioè HOST-ONLY+block upload).
Una proxy policy accetterà le richieste di connessione di servizi proxy HTTP, il cui service non è tcp ma c'è
soltanto il servizio web proxy, perché non è traffico di transito ma è la richiesta di accedere al servizio.
Mentre la destinazione è su quale sito (URL) vogliamo andare, e le URL le andremo a matchare con il proxy
address.
Esempio: "definizione Proxy policy per servizi web”:

La Proxy policy definisce anche il traffico in uscita pertanto dobbiamo usare la stessa porta di uscita che usa
il Proxy altrimenti la policy non funziona, inoltre dobbiamo configurare il Routing statico indicando la porta
di uscita esatta e il Gateway (quando la Subnet non è specificata sarà già in automatico la rotta di default).

Nell’Explicit proxy, se flagghiamo ACCEPT anzichè DENY alla voce "Default Firewall Policy Action", tutte le
richieste di connessione HTTP che arriveranno al proxy e che non matchano nessuna condizione, in
automatico quel traffico verrà accettato, quindi l'action dovrà essere sempre sul DENY, e ciò significa che il
traffico si deve accettare solo per mezzo delle Proxy policy.

N.B. l'ordine delle policy è importante.

N.B: la navigazione tramite il metodo get dell'http viene consentito, ma fare attenzione perché alcuni siti
possono anche utilizzare il metodo post per richiamare alcune pagine web, infatti se andiamo a bloccare
con una Proxy policy il metodo post, potrebbe capitare che le pagine web richiamate dal POST potrebbero
risultare irraggiungibili perché bloccate appunto dalla Proxy policy.

2) AUTENTICAZIONE:
Nella proxy policy oltre al metodo, come sorgente può essere aggiunta anche l'autenticazione, che deve
basarsi su un database di utenza (es. utenti locali o utenti AD) e quindi è possibile oltre agli Address (FW e
Proxy) specificare degli utenti.

Da GUI:
User&Device>User Definition>User Type (Local User)> Login Credentials (Username e Password)>Contact
Info (email (che si può anche omettere)) - SMS - two-factor authentication (che se dovessimo abilitarlo
userebbe il token, ma è più comodo usare l'SMS come autenticazione a doppio fattore)>NEXT>SUBMIT

Ci sono 2 tipi di utenti:

Utenti locali con le credenziali memorizzate localmente nel FG stesso o utenti remoti. Ora possiamo
specificarlo nella proxy policy come sorgente, possiamo anche creare un gruppo di utenti, in base agli
schemi di autenticazione verrà sollecitata un certo tipo di autenticazione. Gli schemi di autenticazione,
significa specificare quali utenti si autenticano e come, e si può definire da CLI (fare riferimento alla
comandistica presente nelle SLIDE ufficiali FG). L'autenticazione basic è un'autenticazione standard
implementata dai browser tramite http. Dopo andremo a creare l'authentication rule, prevedendo che una
sorgente (nel caso nostro ALL) tramite protocollo HTTP vada a invocare lo schema di autenticazione che
creiamo prima tramite CLI. --> vedere immagine "creazione authentication rules"

AUTHENTICATION SCHEME e RULES:

Esempio: "creazione schema di autenticazione Proxy"

FG1# conf authentication scheme

FG1# edit <scheme-name>
FG1# set method negotiate --> con questo metodo, il browser parla col Proxy e dice quale metodo
utilizzare oppure:
FG1# set method basic ecc ecc...
FG1# set user-database local --> nel nostro caso perché abbiamo definito utenti locali
FG1# end
!
FG1# conf authentication rule
FG1# edit Proxytest
FG1# set srcaddr all
FG1# set active-auth-method ProxyTEST
!
FG1# conf authentication setting --> è il 3, parametro utilizzato per l'autenticazione ed è il valore di default
e sono le impostazioni che vengono applicate quando nessun'altra authentication rule è stata matchata.
FG1# set sso-auth-scheme <scheme-name>
FG1# set active-auth-scheme <scheme-name>
Quindi il metodo di autenticazione che verrà richiamato in una Proxy policy dove abbiamo specificato degli
utenti, dipenderà dalla authentication rule che applicherà di conseguenza uno schema di autenticazione.

Esempio: "richiamo dell'autenticazione tramite URL":

Monitor>Firewall User Monitor --> possiamo vedere l'utente che sta navigando e che sta usando il proxy, e
si vede che il proxy-user è stato autenticato grazie a uno schema richiamato dal Proxy esplicito.

-------------------------------------------------------------------------------------------------------------------------------
FSSO (fortinet single sign-on) è un meccanismo che cerca di rilevare l'identità dell'utente tramite il dialogo
con Active Directory.