Il pacchetto, gli oggetti, le regole

In SmartConsole la policy non è un file unico ma un Policy Package: una raccolta di policy diverse che viaggiano insieme. Un pacchetto può contenere Access Control (Firewall, NAT, Application Control & URL Filtering, Content Awareness, Mobile Access), Threat Prevention (IPS, Anti-Bot, Anti-Virus, Threat Emulation, Threat Extraction, Zero Phishing), QoS, Desktop Security e HTTPS Inspection. Ogni pacchetto è legato a un insieme di installation targets, cioè i gateway che riceveranno quelle regole al momento dell’Install Policy.

Dentro Access Control la policy vive nella Rule Base, un elenco ordinato di regole costruite con oggetti: host, network, address range, network group, zone, dynamic object, updatable object. Gli oggetti sono la materia prima, e la precisione della policy dipende da loro: la documentazione R82 raccomanda esplicitamente di non scrivere una regola con Any sia in Source sia in Destination quando la regola porta anche un’applicazione o un Data Type, e di indicare invece una destinazione come Internet o l’oggetto del server.

Due regole compaiono in quasi ogni Rule Base di esempio e vanno sapute a memoria: la Stealth rule, che impedisce l’accesso diretto al Security Gateway, e la Cleanup rule, che scarta il traffico non ammesso dalle regole precedenti.

Le colonne che decidono

Ogni regola si legge per colonne. No. è il numero della regola dentro il layer. Hits mostra quante connessioni le hanno corrisposto. Name e Comment servono alle persone, non al motore. Source e Destination sono gli oggetti che dicono da dove parte e dove va il traffico. VPN restringe la regola a una VPN Community. Services & Applications contiene servizi, applicazioni, categorie e siti. Content è il dato da proteggere, per esempio numeri di carta di credito, con una direzione (download, upload o entrambe). Time limita la validità oraria.

Action è la decisione vera e propria: Accept, Drop, Reject, Ask, Inform e Inline Layer. Fissa la differenza fra Drop, che scarta senza rispondere, e Reject, che notifica il mittente. Track stabilisce che cosa resta scritto: None, Log, Accounting e le opzioni di allerta. Install On indica quali oggetti di rete riceveranno la regola: lasciata sul valore Policy Targets, la regola va a tutti i target del pacchetto; puntata su un solo gateway, esiste solo lì.

Accanto alle regole che scrivi ci sono le implied rules, predefinite, che consentono la comunicazione interna necessaria fra Security Management Server e gateway gestiti. Non compaiono nella Rule Base finché non le chiedi: Security Policies > Access Control > Policy, poi Actions > Implied Rules. Si abilitano e si riordinano da Menu > Global properties > Firewall, e l’ordine si decide prima di installare la policy.

Come il gateway cerca la corrispondenza

Il motore lavora a prima corrispondenza: il Security Gateway cerca la prima regola che si applica alla connessione e applica quella. Trovata la corrispondenza piena già sul pacchetto SYN, gli altri motori di ispezione non vengono nemmeno accesi. È il motivo per cui l’ordine non è una questione estetica: una regola larga messa sopra una regola stretta rende la seconda irraggiungibile, e nessun errore te lo segnala.

Quando le regole contengono firme applicative o classificazioni di contenuto, però, la decisione non può essere presa sul SYN: il gateway accende uno o più inspection engine e rinvia la decisione finale finché non ha ispezionato il corpo della connessione. La Rule Base viene quindi valutata più volte — al SYN, sugli header HTTP, sul body — restringendo a ogni passaggio le regole ancora candidate. Da qui la buona pratica di mettere in alto le regole che guardano solo source, destination e porta, e più in basso quelle che guardano applicazioni e contenuti.

Se nessuna regola del layer corrisponde, interviene la Default Cleanup Rule esplicita che hai scritto in fondo; se non l’hai scritta, decide comunque una regola di cleanup implicita che non vedi nella Rule Base.

Trappole tipiche d’esame

  • L’ordine sbagliato non produce un errore, produce traffico. Uno scenario tipico ti mostra una regola permissiva verso Any in posizione 3 e la regola restrittiva verso il server in posizione 7: la risposta corretta è che la regola 7 non verrà mai raggiunta. Non cercare messaggi di errore, cerca la prima regola che corrisponde.
  • Drop non è Reject. Se la domanda chiede perché il client resta in attesa invece di ricevere subito un rifiuto, l’indizio è l’Action della regola.
  • Install On non è Source. Una regola con Install On su un solo gateway non viene applicata dagli altri, anche se il pacchetto è installato su tutti: il traffico passa altrove e sembra un buco di policy.
  • Le implied rules spiegano i falsi misteri. Traffico che passa senza che nessuna regola esplicita lo permetta, e senza log, è quasi sempre una implied rule: vanno mostrate con Actions > Implied Rules prima di concludere che la Rule Base è incoerente.
  • Scrivere non è installare. Una policy corretta in SmartConsole non protegge nulla finché non viene verificata e installata sui target: se lo scenario dice che le modifiche non hanno effetto, controlla prima questo.