Application Control e URL Filtering non hanno una rule base separata: vivono dentro la Access Control Policy, in una colonna e in un tipo di Layer. Sapere quali oggetti entrano in quella colonna, e che cosa succede quando il gateway prova a far corrispondere una regola che li contiene, è la parte del modulo su cui si costruiscono più domande.

I quattro oggetti della colonna Services & Applications

Nelle regole di Access Control la colonna Services & Applications accetta quattro tipi di oggetto. Application: una singola applicazione presa dall’Application Database. Category: un raggruppamento già pronto, per esempio Media Streams o Remote Administration, che copre tutto ciò che il vendore classifica in quel modo. Custom Application/Site: un oggetto creato a mano, dove si elencano gli URL propri dell’organizzazione oppure si scrive un’espressione regolare. Application Group: un gruppo personalizzato che mette insieme categorie, applicazioni e siti personalizzati per tenere la rule base corta. Nell’albero degli oggetti di SmartConsole questi elementi stanno sotto Custom Applications/Sites, accanto ad Applications, Categories e Mobile applications.

Due avvertenze sulle liste personalizzate. La prima: le espressioni regolari complesse si pagano in CPU, ed è una raccomandazione esplicita della documentazione evitarle quando un elenco di URL basta. La seconda: un oggetto personalizzato è un elenco che mantieni tu e che nessuno aggiornerà al posto tuo, al contrario delle categorie.

Come la regola entra nella Access Control Policy

La colonna Services & Applications accetta applicazioni e categorie solo in un Layer in cui il blade Applications and URL Filtering è abilitato. Per ogni Ordered Layer e per ogni Inline Layer si scelgono i blade attivi fra Firewall (che include VPN), Applications and URL Filtering, Content Awareness e Mobile Access; un Inline Layer non deve abilitare un blade che l’Ordered Layer che lo contiene non ha.

L’impianto consigliato prevede un primo Ordered Layer di rete e un secondo Ordered Layer dedicato al controllo applicativo. La valutazione procede dal primo Ordered Layer al successivo: una regola con azione Drop chiude la partita, una regola con azione Accept fa proseguire la connessione al Layer seguente, che può ancora negarla. Se nessuna regola corrisponde, decide la Cleanup Rule del Layer. Dentro un Inline Layer vale la stessa logica in piccolo: se il pacchetto corrisponde alla regola padre ma a nessuna sotto-regola, decide la Cleanup Rule esplicita, e in sua assenza l’Implicit Cleanup Rule. La documentazione raccomanda di scrivere sempre una Cleanup Rule esplicita in fondo a ogni Inline Layer, con la stessa azione di quella implicita.

Nella colonna Action, oltre ad Accept, Drop e Reject, si usano le azioni interattive Ask e Inform, associate a un oggetto UserCheck, e il limite di banda con Limit. La colonna Track vale qui più che altrove: il log è ciò che mostra quale applicazione o quale categoria ha prodotto la corrispondenza.

Che cosa succede al momento della corrispondenza

Il gateway cerca la prima regola applicabile, ma con le applicazioni non può decidere sul primo pacchetto: dagli header ricava al massimo una corrispondenza possibile, e deve ispezionare il corpo della connessione per arrivare a una corrispondenza definitiva. Nel frattempo continua a scorrere la rule base. Da qui discende l’effetto che sorprende di più: una regola più in alto che decide solo su rete e servizio può chiudere definitivamente la partita prima che l’applicazione venga identificata, e la regola applicativa più in basso non viene mai raggiunta. Infine, le applicazioni consentite fanno corrispondenza sui servizi raccomandati, cioè http, https, HTTP_proxy, HTTPS_proxy e quic, a meno di impostazioni personalizzate.

Trappole tipiche d’esame

  • La regola applicativa «non funziona» perché non viene mai valutata. Prima di sospettare l’oggetto, guarda che cosa c’è sopra: una regola di rete che fa corrispondenza definitiva sugli header decide prima che l’applicazione sia riconosciuta. È la spiegazione più frequente di un blocco che sembra troppo restrittivo e di un permesso che sembra ignorato.
  • Il Layer sbagliato. Se la colonna Services & Applications non accetta un’applicazione o una categoria, il problema non è l’oggetto: è il blade Applications and URL Filtering non abilitato su quel Layer. Stessa famiglia di errore quando un Inline Layer prova ad abilitare un blade che il suo Ordered Layer non ha.
  • Accept non è la fine. In un Ordered Layer l’azione Accept manda la connessione al Layer successivo, che può negarla. Chi legge Accept come «passa e basta» sbaglia le domande sull’ordine dei Layer.
  • Cleanup Rule mancante nell’Inline Layer. Senza regola esplicita in coda decide l’Implicit Cleanup Rule, e il traffico che corrisponde alla regola padre ma a nessuna sotto-regola finisce dove nessuno si aspetta.
  • Liste personalizzate ed espressioni regolari. Sono la causa citata di consumo di CPU quando le rule set crescono, e sono anche il posto dove nascono le corrispondenze errate: una regex troppo larga cattura siti che non c’entrano, una troppo stretta manca quelli che contano. Se il caso si può descrivere con una categoria già pronta, la categoria è la risposta migliore.
  • Category e Application nella stessa regola. Il vendore raccomanda regole separate per Application Control e URL Filtering: una regola che li mescola è un distrattore ricorrente.