Un utente segnala che «il blocco non funziona»: il sito vietato si apre lo stesso, oppure un’applicazione autorizzata viene respinta. Su Quantum in R82 quel sintomo ha quasi sempre una di tre radici — il match nella Rule Base, la categorizzazione, il fatto che il traffico sia cifrato — e saperle separare in fretta è ciò che questo dominio misura davvero.

Come il gateway sceglie la regola

La colonna Services and Applications di una regola di Access Control può contenere servizi, applicazioni, siti web, categorie predefinite di traffico Internet e gruppi o categorie personalizzate. Il punto che fa sbagliare la diagnosi è che il match non è simmetrico. Quando un’applicazione è consentita, la regola matcha solo sui Recommended services dell’applicazione, e per le applicazioni web i Recommended services sono http, https, HTTP_proxy e HTTPS_proxy. Quando invece un’applicazione è bloccata, è bloccata su tutti i servizi, quindi su tutte le porte. Conseguenza: una regola che consente un’applicazione su una porta fuori standard non matcha, e il traffico scende fino alla Cleanup rule. Il rimedio è Match Settings, dove si passa da Recommended services a Any o a Customize.

Vale poi la precedenza: la prima regola che matcha è quella applicata, quindi le regole che consentono vanno sopra quelle che bloccano. E c’è un’indicazione esplicita di Check Point che in esame torna spesso — Application Control e URL Filtering non vanno usati nella stessa regola, perché porta a un match sbagliato: sono due lenti diverse sullo stesso traffico e vanno in regole separate.

Due effetti collaterali da tenere a mente. Una regola di blocco con Source e Destination impostati su Any blocca anche il traffico da e verso il Captive Portal, e può quindi spegnere la Browser-Based Authentication mentre credi di aver toccato solo la navigazione. E una regola con Track su None non produce alcun log: la diagnosi parte cieca, e il primo intervento sensato è portare il Track su Log e reinstallare la policy.

Categoria attesa contro categoria assegnata

Quando il match nella Rule Base è corretto ma l’esito resta sbagliato, il sospetto si sposta sulla categorizzazione. Le impostazioni globali stanno in Manage & Settings > Blades, nella sezione Application Control & URL Filtering.

Nella pagina General c’è il Fail mode, con le due scelte Allow all requests (fail-open) e il blocco di tutte le richieste. È la voce che decide che cosa succede quando il servizio di categorizzazione non risponde, e un gateway in fail-open fa sembrare «rotta» una regola di blocco che in realtà non ha mai ricevuto una categoria su cui decidere.

Nella pagina Check Point Online Web Service c’è il Website categorization mode: decide se la connessione attende la risposta del servizio o prosegue mentre la categorizzazione si completa. In modalità Background il traffico non aspetta, ed è il motivo per cui la prima visita a un sito mai visto può sfuggire alla regola che dalla seconda in poi scatta regolarmente. Sulla stessa pagina sta Categorize social networking widgets, che riguarda i componenti incorporati nelle pagine e non il sito che li ospita.

Resta lo stato del database. L’aggiornamento manuale si lancia da Security Policies > Access Control, riquadro Access Tools, voce Updates, e poi Management Update nella sezione Application & URL Filtering. Un database indietro di settimane classifica un dominio nuovo in modo diverso da come te lo aspetti, e nessuna riscrittura della regola lo correggerà. Prima di ritoccare la policy, verifica la categoria che il prodotto assegna davvero a quel sito, non quella che sembra ovvia.

Quando il traffico è cifrato

Categorize HTTPS websites, sotto URL Filtering nella stessa pagina General, è un’impostazione a sé e funziona sia con HTTPS Inspection abilitata sia con HTTPS Inspection disabilitata. Ma le due cose non danno la stessa visibilità: senza decifratura il gateway lavora su ciò che la sessione TLS espone in chiaro, cioè il sito, non il percorso della singola pagina. Una regola scritta su una categoria continua a funzionare; una regola scritta su un URL specifico dentro quel sito no, e il sintomo è identico a quello di una regola mal posizionata. Prima di spostare regole, chiediti se l’HTTPS Inspection sia attiva su quel gateway.

Trappole tipiche d’esame

  • Dare per scontata la categoria. La domanda descrive un sito «chiaramente» di una certa categoria e una regola che non lo blocca. La risposta giusta non è riordinare la Rule Base: è verificare a quale categoria il prodotto associa davvero quel sito.
  • Ignorare lo stato dell’aggiornamento. Se lo scenario nomina un dominio recente o un gateway isolato dalla rete, guarda prima il database delle categorie, e poi il Fail mode che decide l’esito quando la categoria non arriva.
  • Dimenticare l’HTTPS Inspection. Su traffico cifrato la scelta fra una regola per categoria e una regola per URL cambia il risultato. Se la traccia dice «HTTPS» e non dice nulla di HTTPS Inspection, quella assenza è parte del problema.
  • Confondere il blocco con il permesso. Un’applicazione bloccata lo è su tutte le porte, una consentita solo sui Recommended services: la stessa regola si comporta in modo diverso a seconda dell’Action.