Nella Access Control Policy di R82 i layer non sono un abbellimento grafico: decidono l’ordine in cui il Security Gateway ispeziona una connessione e il punto esatto in cui la sorte di quel traffico viene decisa. Chi conosce le regole ma non il percorso che il pacchetto compie fra i layer sbaglia comunque la domanda.

Come il traffico attraversa gli Ordered Layer

Un Ordered Layer è un blocco di regole valutate dall’alto verso il basso fino alla prima che fa match: il gateway applica l’azione di quella regola e smette di cercare dentro quel layer. Quello che succede dopo dipende dall’azione. Con Drop l’elaborazione finisce lì, il pacchetto viene scartato e i layer successivi non vengono nemmeno letti. Con Accept la connessione non è ancora ammessa: il gateway prosegue e controlla le regole dell’Ordered Layer successivo. Un Accept, in altre parole, è un permesso parziale, valido solo per il layer che lo ha concesso.

La conseguenza pratica è asimmetrica e conviene impararla come una formula: per passare, una connessione deve ottenere un Accept in ogni Ordered Layer del Policy package; per essere fermata le basta un Drop in uno qualsiasi di essi. Da qui la best practice della documentazione: in cima un Firewall/Network Ordered Layer con le regole che guardano solo source, destination e port, e sotto un Application Control Ordered Layer per applicazioni, URL e contenuti. Il controllo che costa meno filtra per primo e l’ispezione di contenuto lavora su ciò che è sopravvissuto.

C’è un secondo motivo per cui l’ordine conta. Quando una regola cita una application signature, una site category o un data type, il gateway accende uno o più inspection engine e rimanda la decisione finale al momento in cui avrà abbastanza dati (SYN, HTTP header, HTTP body): il Rule Base può essere percorso più volte sulla stessa connessione, e la regola che decide può non essere quella che sembrava fare match al primo pacchetto.

Inline Layer: una sotto-policy dentro una regola

Un Inline Layer è una sub-policy indipendente dal resto del Rule Base, agganciata a una parent rule il cui Action è Inline Layer. La parent rule funziona da filtro d’ingresso: se la connessione non fa match con essa, l’intero Inline Layer viene saltato e nessuna sotto-regola viene valutata. Se il match c’è, il traffico scorre le sotto-regole e il primo match chiude la valutazione del layer.

Se nessuna sotto-regola fa match interviene l’Implicit Cleanup Rule, la regola implicita che chiude ogni layer e il cui Action predefinito è Drop. Non si vede nel Rule Base, si legge nelle proprietà del layer: per questo la documentazione raccomanda di aggiungere sempre una Cleanup Rule esplicita in fondo a ogni Inline Layer, con la stessa azione dell’Implicit Cleanup Rule, così che il comportamento sia scritto e non dedotto. Un vincolo da ricordare: un oggetto Remote Access VPN community non è supportato nella parent rule di un Inline Layer, dove si usa “Any”.

Perché i layer rendono la policy modulare

Il riuso passa dallo shared layer: spuntando “Multiple policies can use this layer” lo stesso Ordered Layer può essere usato da più Policy package e lo stesso Inline Layer da più layer. Una baseline aziendale — le regole di management, la stealth rule, gli accessi comuni — si scrive una volta e vive in un posto solo. L’Inline Layer serve invece a ritagliare un pezzo di policy attorno a un tema, i web server pubblici o il traffico di un reparto, con la sua cleanup esplicita, un nome e sezioni leggibili; è anche l’unità naturale su cui delegare la gestione a un amministratore tramite permission profile, senza aprirgli l’intera Rule Base. Il prezzo del riuso è la propagazione: quel layer non è una copia, è lo stesso oggetto per tutte le policy che lo usano.

Trappole tipiche d’esame

Scambiare Accept per «passato». Lo scenario classico: la connessione fa match con una regola Accept nel Network Layer e poi con nessuna regola nell’Application Control Layer. Non passa: decide l’Implicit Cleanup Rule di quel secondo layer, che di default è Drop. Specularmente, un Drop trovato nel primo layer rende irrilevante qualunque cosa ci sia sotto.

Trattare uno shared layer come una copia. Collegare un layer condiviso a un secondo Policy package non lo duplica: una modifica fatta lì cambia il comportamento di tutte le policy che lo usano. E scollegarlo da un package non lo cancella dagli altri, né disattiva le regole che contiene. La domanda spesso descrive un ritocco «locale» con un effetto a distanza.

Layer configurati male che producono traffico inatteso. Le cause ricorrenti sono tre: Inline Layer senza cleanup esplicita, quindi silenziosamente Drop; parent rule troppo stretta, che fa saltare l’intero Inline Layer a traffico che ci si aspettava di vedere dentro; Ordered Layer nell’ordine sbagliato, con l’ispezione di contenuto davanti al filtro di rete.

Seguire un log alla regola sbagliata. Quando lo stesso Inline Layer compare più volte nell’Ordered Layer, il comando “Go to rule” a partire dal log può non portare all’istanza corretta: la documentazione indica di usare la ricerca in packet mode.