«Il sito dovrebbe essere bloccato e invece passa» è probabilmente lo scenario più frequente dell’intero dominio di ispezione dei contenuti, ed è raramente colpa di una categoria sbagliata. Nella grande maggioranza dei casi la causa sta a monte: un altro filtro ha già emesso il verdetto, il pattern non ha fatto match come credevi, oppure il FortiGate non ha mai visto il nome del sito. Questa unità ti dà l’ordine con cui guardare.

L’ordine dei filtri decide chi vince

I filtri web vengono applicati in sequenza fissa: URL filter, FortiGuard Web Filtering, web content filter, web script filter, scansione antivirus. L’URL filter arriva per primo, quindi una voce di URL filter batte sempre la categoria FortiGuard. Se hai un Allow su un dominio e un Block sulla sua categoria, vince l’Allow: il traffico prosegue verso i filtri successivi e, se non incontra altro, arriva a destinazione.

Le quattro azioni dell’URL filter non sono equivalenti:

  • Block nega l’accesso e mostra un replacement message;
  • Allow passa il traffico ai filtri rimanenti; se un URL non compare nella lista, il traffico è comunque permesso;
  • Monitor si comporta esattamente come Allow, ma genera un log a ogni match;
  • Exempt fa saltare del tutto i filtri rimanenti.

Exempt spegne molto più di quanto sembri

Exempt è la prima cosa da cercare quando un sito passa senza motivo apparente. Un URL con azione exempt bypassa i restanti filtri FortiGuard, i content filter, i web script filter, la scansione antivirus e le operazioni DLP del proxy. Dalla GUI non c’è granularità: impostare l’azione su Exempt esenta l’URL da tutti i security profile.

La selezione fine esiste solo in CLI, e non è visibile nell’interfaccia — motivo per cui una configurazione letta dalla GUI può ingannare:

config webfilter urlfilter
    edit 1
        config entries
            edit 1
                set action exempt
                set exempt av web-content fortiguard
            next
        end
    next
end

Le opzioni disponibili sono av, web-content, activex-java-cookie, dlp, fortiguard, range-block, pass, antiphish e all.

Simple contro wildcard: il match che non scatta

Il secondo motivo classico è un pattern che non corrisponde a quello che credi. Il tipo Simple fa match stretto sul contesto completo: se scrivi www.facebook.com non copri facebook.com né message.facebook.com. Il tipo Regular expression/wildcard fa match sul pattern: *fa* intercetta www.facebook.com, message.facebook.com e anche fast.com, con tutti i falsi positivi che ne conseguono.

La trappola vera è che lo stesso simbolo significa cose diverse nei due mondi. Nel web content filter, in modalità wildcard forti*.com corrisponde a fortinet.com e fortiguard.com, perché l’asterisco rappresenta qualsiasi carattere ripetuto un numero qualunque di volte. In modalità regular expression lo stesso forti*.com corrisponde a fortiii.com ma non a fortinet.com, perché lì l’asterisco si riferisce al carattere che lo precede.

Sul content filter ricorda anche il meccanismo a punteggio: ogni parola o frase vietata ha uno score, e la pagina viene bloccata quando la somma supera la soglia del profilo. Score e soglia valgono 10 di default, quindi di default basta una sola corrispondenza per bloccare. Il punteggio di una parola si conta una volta sola anche se compare molte volte nella pagina, e una frase tra virgolette si conta solo se compare esattamente come scritta. Score e soglia si configurano solo da CLI.

Quando il FortiGate non vede il nome del sito

Se il pattern è giusto e nessun exempt è in gioco, il problema è che il firewall non sta leggendo l’hostname.

Con la sola certificate inspection il filtraggio si appoggia all’SNI in chiaro del ClientHello. Encrypted Client Hello lo cifra, e questo può rompere la certificate inspection: con ECH attivo il nome che ti serve non è più leggibile. Le contromisure sono bloccare i ClientHello che usano ECH, così il TLS ricade sul ClientHello in chiaro, oppure rimuovere il parametro ECH dalle risposte DNS con set strip-ech enable in un profilo DNS filter. Il blocco di ECH è supportato solo in modalità di ispezione proxy. Con la deep inspection il problema non si pone: il FortiGate rimuove sempre l’estensione ECH, costringendo di fatto il browser a una connessione TLS senza ECH.

Verifica poi le esenzioni dalla decifratura. Nel profilo SSL/SSH, la sezione Exempt from SSL Inspection arriva già popolata con le categorie Finance and Banking, Health and Wellness e Personal Privacy, e l’opzione Reputable Websites esenta i siti che FortiGuard considera affidabili. Un sito che ricade lì non viene decifrato, e con esso non viene ispezionato.

Quando la categoria è giusta ma l’esito no

Restano due comportamenti che spiegano gli ultimi casi.

Il primo è il rating error. Se la licenza FortiGuard non è valida o il servizio non è raggiungibile, il rating fallisce; con set options error-allow attivo, i siti che restituiscono un rating error vengono lasciati passare. È una scelta legittima per la continuità operativa, ma va conosciuta.

Il secondo è la doppia classificazione. Con set options rate-server-ip il FortiGate invia a FortiGuard sia il dominio sia l’indirizzo IP del pacchetto, e se le due categorie divergono decide in base a un peso di rating cablato in FortiOS. Analogamente, ssl-exemption-ip-rating nel profilo SSL e address-ip-rating nelle protocol options sono abilitati di default: quando dominio e IP hanno categorie diverse, prevale quella dell’IP. Disabilitarli forza l’uso della categoria del dominio, che è quasi sempre quella corretta.