I due laboratori del dominio M10 vanno in coppia: il primo produce il sintomo, il secondo ti costringe a spiegarlo. Il valore d’esame non sta nei clic, sta nell’ordine con cui raccogli le prove — e nel resistere alla tentazione di riscrivere la regola prima di aver capito che cosa il gateway ha davvero deciso.
Activate the Bad Actor: prima rendi il sintomo ripetibile
Attivare l’host che genera traffico indesiderato serve a una cosa sola: avere un caso che si riproduce a comando. Prima di lanciarlo, prepara il terreno perché lasci tracce. Sulla regola che dovrebbe intercettare quel traffico porta il Track su Log: il valore None non genera alcun log, e ti ritroveresti a indagare su una scena vuota. Poi installa la policy, perché una modifica non installata non esiste per il gateway.
Ricorda anche che cosa vedrà l’utente, perché è un indizio. L’Action Drop scarta il traffico e il Security Gateway non invia risposta: il browser resta appeso e va in timeout, non compare nessuna pagina. Le Action Ask e Inform invece parlano all’utente tramite UserCheck. Se durante il lab vedi un messaggio di blocco, stai guardando una regola con UserCheck; se vedi un timeout, stai guardando un Drop — oppure non stai guardando affatto la regola che credi.
Una nota che fa perdere tempo a molti: la frequenza con cui UserCheck ripropone il messaggio si configura Per rule, Per category, Per application/Site o Per Data type. Se ripeti la prova e il messaggio non ricompare, non è detto che la policy sia cambiata.
Troubleshoot URL Filtering: tre domande, in quest’ordine
La regola ha matchato? In SmartConsole apri Security Policies > Access Control > Policy, seleziona la regola sospetta e fai clic su Logs nel riquadro in basso: vedi le connessioni che quella regola ha gestito. Doppio clic su una riga apre la finestra Log Details. Se per la tua prova non c’è nessun log su quella regola, la connessione non è mai arrivata lì: la prima regola che matcha è quella applicata, quindi il colpevole sta più in alto.
Quale categoria ha assegnato il gateway? È la domanda che quasi nessuno fa per prima, ed è quella che risolve il caso più spesso. La categoria che leggi nel log è il dato reale; la categoria che ti aspetti è un’ipotesi. Se divergono, il problema non è la Rule Base. Controlla allora lo stato del database: Security Policies > Access Control, riquadro Access Tools, voce Updates, poi Management Update nella sezione Application & URL Filtering. E controlla le impostazioni globali in Manage & Settings > Blades: il Fail mode, che decide l’esito quando la categorizzazione non risponde, e il Website categorization mode nella pagina Check Point Online Web Service, che in modalità Background lascia passare la connessione mentre la categorizzazione si completa. Quando la categoria assegnata è oggettivamente sbagliata, la strada non è una regola su misura: il messaggio di blocco di UserCheck può includere un link per segnalare a Check Point che il sito è in una categoria errata.
Il traffico era cifrato? L’impostazione Categorize HTTPS websites vive sotto URL Filtering nella pagina General ed è indipendente dall’HTTPS Inspection. Senza decifratura però il gateway ragiona sul sito, non sul percorso della singola pagina: una regola per categoria regge, una regola su un URL interno no.
Quando i log non bastano: debug del modulo APPI
Se il log non spiega la decisione, si scende al kernel. Il modulo di debug per l’ispezione di Application Control si chiama APPI. La sequenza R82, da eseguire in una finestra di manutenzione perché il debug alza parecchio il carico di CPU, è questa:
fw ctl debug 0
fwaccel dbg resetall
fw ctl set int simple_debug_filter_off 1
fw ctl debug -buf 8200
fw ctl debug | grep buffer
fw ctl debug -m APPI + policy connection urlf_ssl appi_ssl error warning
fw ctl kdebug -T -f -o /var/log/kernel_debug.txt
Si interrompe la raccolta con CTRL+C e si ripulisce sempre lo stato:
fw ctl debug 0
fwaccel dbg resetall
fw ctl set int simple_debug_filter_off 1
I flag che servono qui sono policy per la policy di Application Control, connection per le connessioni, urlf_ssl per URL Filtering su SSL e appi_ssl per Application Control su SSL; referrer aiuta sui siti che si tirano dietro contenuti di terze parti. Su Security Group di piattaforma scalabile il comando è g_fw ctl debug.
Trappole tipiche d’esame
- Concludere che la regola non funziona quando il sito è categorizzato diversamente da come credi. La categoria nel log vince sulla tua intuizione: leggila prima di toccare la Rule Base.
- Trascurare lo stato dell’aggiornamento del database delle categorie. Un database vecchio classifica male i domini recenti, e nessuna riscrittura della regola lo rimedia.
- Non considerare l’HTTPS Inspection quando il traffico è cifrato. Se lo scenario dice HTTPS e tace sull’ispezione, quel silenzio è parte della domanda.
- Fermarsi al lab senza reinstallare la policy o senza Track su Log. Metà dei falsi guasti di laboratorio è una modifica non installata o una prova senza tracce.