Ogni pacchetto che attraversa un FortiGate deve trovare una firewall policy che lo accetti: non esiste traffico che passa e basta. Se nessuna policy corrisponde, il pacchetto viene scartato. Quello che distingue chi ha messo le mani sul prodotto è sapere in che ordine il dispositivo valuta le cose, e cosa cambia davvero passando da flow a proxy.

I criteri di corrispondenza, e cosa succede prima del match

Perché il traffico attraversi il firewall serve una policy che soddisfi tutti i parametri: interfaccia in ingresso, interfaccia in uscita, indirizzo sorgente, indirizzo di destinazione, identità dell’utente, servizio e schedule. Sono in AND fra loro — basta che uno non torni e la policy non matcha — mentre gli oggetti dentro il singolo campo sono in OR. Nella 7.6 il pulsante Show Logic, in Source & Destination, lo rende esplicito stampando le etichette «Any of» e «And any of».

Due conseguenze da fissare. La prima: conta la direzione della comunicazione iniziale, non quella del volume di dati. Un utente che naviga genera traffico su una policy LAN verso WAN anche se il 95% dei byte arriva dal web server. Se le sessioni possono partire da entrambi i lati, servono due policy, una per direzione.

La seconda è meno intuitiva: FortiOS non esegue un reverse-path check sul traffico di risposta che appartiene a una sessione già ammessa in base alla tupla IP. La richiesta può uscire da un’interfaccia e la risposta rientrare da un’altra senza essere scartata.

C’è poi un ordine che rende leggibili le catture: la ricerca della route precede il match della policy.

msg="find a route: gw-192.168.11.254 via port6"
msg="find SNAT: IP-192.168.11.59, port-31925"
msg="Allowed by Policy-3: SNAT"

Se non esiste una route valida verso la destinazione la policy non viene nemmeno consultata: cercare l’errore nella policy list è tempo perso.

Ordine di valutazione e la trappola delle VIP

Le policy si valutano dall’alto verso il basso e vince la prima che corrisponde: la regola specifica va sopra quella generica, sempre. In fondo c’è l’implicit deny, che nei log compare con policyid=0. Se serve tracciare ciò che cade, crea una deny esplicita con il log attivo: è il violation traffic.

La trappola classica riguarda le VIP: le policy con una VIP applicata hanno priorità su quelle normali, quindi mettere una deny «più in alto» non basta a bloccare gli host che raggiungono un server pubblicato. Sulla deny che precede la policy con la VIP serve match-vip abilitato: sulle nuove policy di deny lo è già per default, ma su configurazioni ereditate va verificato. E match-vip non è abilitabile se l’azione è accept.

config firewall policy
    edit 1
        set name "deny-policy-1"
        set srcintf "wan1"
        set dstintf "lan1"
        set srcaddr "src-hosts-to-deny-access"
        set dstaddr "all"
        set action deny
        set schedule "always"
        set service "ALL"
        set match-vip enable
    next
end

Nota finale: quando abiliti internet-service in una policy, l’indirizzo di destinazione e il servizio non vengono più usati, perché la voce ISDB porta con sé sia i range IP sia le porte. È una fonte ricorrente di policy che «non matcha e non si capisce perché».

Flow o proxy: cosa cambia al payload

Non è una preferenza estetica, è come il FortiGate tratta il contenuto. In flow mode il traffico non viene bufferizzato: il payload è ispezionato pacchetto per pacchetto e solo l’ultimo pacchetto resta trattenuto finché la scansione non emette il verdetto. Se emerge una violazione parte un reset verso il ricevente, che chiude la connessione e impedisce la consegna completa del payload. Tutti i moduli flow-based applicabili girano simultaneamente in un unico passaggio con pattern matching DFA, accelerato dai processori CP8 o CP9.

In proxy mode il FortiGate bufferizza: trattiene il file, il messaggio o la pagina finché non ha ispezionato l’intero payload, poi lo rilascia oppure lo scarta sostituendolo con un replacement message. Per evitare il timeout del client si attiva il client comforting, che rilascia piccole porzioni del payload durante l’ispezione; si possono anche bloccare gli oggetti oltre una certa dimensione.

La modalità si imposta per singola policy e il default è flow.

config firewall policy
    edit 1
        set inspection-mode proxy
    next
end

Cosa perdi e cosa guadagni passando a proxy

Il proxy abilita profili che in flow non esistono affatto: Video Filter, Inline CASB, Web Application Firewall, ICAP e Content Disarm and Reconstruction. Su singoli profili la differenza è più sottile e vale la pena ricordarla: in web filter il flow mode non supporta category usage quota né web profile override; in DLP mancano fingerprint e watermark; l’email filter in flow perde tutti i controlli assistiti da FortiGuard e i check DNS su HELO/EHLO e return address; in antivirus manca il CDR.

Il prezzo è in risorse: flow costa meno, non modifica i pacchetti se non c’è nulla da bloccare ed è la modalità raccomandata salvo che servano funzioni specifiche del proxy. La documentazione consiglia di applicare lo stesso tipo di scansione su tutte le policy. Attenzione ai modelli con 2 GB di RAM o meno, dove diversi profili proxy non sono disponibili.

Due dettagli che in laboratorio fanno perdere tempo. Quando abiliti un security profile, il profilo SSL parte da no-inspection e va portato almeno a certificate-inspection, altrimenti sul traffico cifrato non ispezioni nulla. E se le stesse combinazioni di profili tornano su molte policy, raccoglile in un profile group con set profile-type group.