Che cosa sta decidendo il gateway quando la regola non scatta

Nella Access Control Policy unificata il gateway cerca la prima regola che si applica alla connessione, dall’alto verso il basso, e quando la trova smette di cercare. Il punto che fa deragliare le diagnosi è che «si applica» ha due gradi. C’è il certain match: il gateway ha tutte le informazioni necessarie e applica subito l’azione della regola. E c’è il possible match: la regola potrebbe applicarsi, ma serve un’ispezione più profonda, quindi il gateway accende uno o più motori di ispezione e rimanda la decisione finale a quando ha ispezionato il corpo della connessione. La rule base viene rivalutata via via che arrivano informazioni nuove — al SYN, all’header HTTP, al body HTTP — e a ogni passaggio l’insieme delle regole ancora candidate si restringe.

Da qui discende il riflesso corretto del troubleshooter: una connessione che «non fa match» con la regola attesa può essere semplicemente una connessione la cui classificazione non è mai arrivata al punto in cui quella regola diventa certa, perché l’URL Filtering o la Content Awareness non hanno ancora risposto. Prima di aprire un debug, la domanda è a quale fase la decisione si è fermata.

La cassetta degli attrezzi, in ordine di costo crescente

Gli strumenti dell’Access Control avanzato si usano dal più economico al più invasivo, e l’ordine è già metà della risposta.

Il primo livello è la topologia della decisione: fw ctl chain mostra i Chain Module attraversati dal traffico in ingresso e in uscita, e serve a capire quale componente può aver preso la decisione prima che la policy unificata entrasse in gioco. Il secondo è fw monitor, che cattura a ogni Chain Module nei due sensi con i quattro punti di ispezione pre-inbound (i), post-inbound (I), pre-outbound (o) e post-outbound (O): se il pacchetto si vede alla i e non alla I, il problema è dentro il FireWall Virtual Machine e non altrove.

Il terzo livello è il kernel debug. fw ctl debug -m elenca i moduli disponibili, una quarantina nella R82. Per l’Access Control i due nomi che contano sono UP, la Unified Policy, e UPIS, la Unified Policy Infrastructure. Il modulo UP espone una ventina abbondante di flag: match osserva la classificazione, rulebase le operazioni sulla rule base, probtrc il flusso di rule matching, prob_impl il rilevamento delle implied rule, clob gli oggetti di classificazione, connection connessioni e transazioni, più error, log, policy, stats e subject. Il modulo UPIS guarda l’infrastruttura sotto la policy, con flag come db, tables, topo, update e upr. Vale la pena sapere che alcuni flag di UP sono documentati come inutilizzati — account, btime, prob, urlf_ssl: accenderli con all costa buffer e non produce nulla.

Aumentare il dettaglio dei log prima di toccare il kernel

Il laboratorio del modulo chiede esplicitamente di alzare il dettaglio dei log prima di procedere, e non è una formalità: il log è l’unica evidenza che puoi raccogliere senza carico aggiuntivo apprezzabile e senza finestra di manutenzione.

Il dettaglio si governa dalla colonna Track della regola sospetta in SmartConsole. L’opzione Log è quella di default e mostra tutte le informazioni che il Security Gateway ha usato per fare match sulla connessione; None non genera log, ed è la ragione più banale e più frequente per cui «non si vede niente» in SmartConsole Logs; Accounting aggiorna il log a intervalli di dieci minuti indicando quanti dati sono passati, utile quando il sospetto è una sessione che resta aperta ma non trasferisce. La guida R82 presenta queste come alcune delle opzioni di tracking e rimanda alla Logging and Monitoring Administration Guide per le altre: assumere che l’elenco che ricordi sia completo è un ottimo modo per sbagliare una domanda.

Due dettagli operativi chiudono il laboratorio. Primo, una modifica alla colonna Track vive nella policy: va pubblicata e installata, altrimenti stai rifacendo il test con lo stesso livello di dettaglio di prima. Secondo, se sospetti una regola diversa da quella che stai guardando, alza il Track anche sulla regola di cleanup: è lì che finisce il traffico che nessuna regola esplicita ha accettato, e vedere il match su quella riga è la differenza fra una diagnosi e un’ipotesi.

Trappole tipiche d’esame

Debuggare il modulo sbagliato. Un problema di Access Control su una regola con applicazioni, siti o access role si diagnostica sulla Unified Policy, cioè con UP ed eventualmente UPIS, non sul modulo di una singola blade. Una risposta che propone il modulo della blade è quasi sempre la distrattrice.

Rifare il test senza aver alzato il dettaglio. Se il Track della regola è su None, il secondo test produce esattamente le stesse zero righe del primo, e la conclusione che si trae è falsa. L’ordine corretto è alzare il dettaglio, pubblicare e installare, poi ripetere.

Confondere un match mancato con un drop deliberato. Sono due esiti diversi: il drop deliberato ha una regola che ha fatto match e un’azione di blocco a log; il match mancato è una connessione finita altrove, spesso sul cleanup, o una classificazione rimasta sospesa fra possible e certain match. La domanda ti dà il log: leggi quale regola compare, non solo l’esito.