La distinzione che il blueprint chiede è quella fra gli oggetti che corrispondono a qualcosa di reale e amministrato, cioè i Security Gateway e i server, e gli oggetti che sono soltanto una definizione logica: un indirizzo, un intervallo, un insieme, una porta. Sapere in quale delle due famiglie ricade quello che devi rappresentare è metà della risposta a buona parte delle domande di questo modulo.

Gateways & Servers: gli oggetti che corrispondono a un apparato

La vista Gateways & Servers (Ctrl+1) è il posto in cui si amministrano i dispositivi gestiti dal Security Management Server. Da qui si attivano le Software Blades su un gateway, si configurano i cluster, si eseguono script e si fanno backup e ripristini.

L’oggetto gateway però non vive solo in quella vista: è anche un network object a tutti gli effetti, quindi compare nei selettori delle regole, nelle colonne Source e Destination quando il traffico è diretto a lui o parte da lui, e soprattutto nella colonna Install On, che stabilisce su quali network object la regola viene installata.

Nella categoria Servers stanno invece gli oggetti che descrivono i servizi di infrastruttura a cui l’ambiente si appoggia: trusted certificate authority, server RADIUS, server TACACS.

Network Objects: host, reti, address range, gruppi

Nella categoria Network Objects convivono Security Gateway, host, reti, address range, dynamic object e security zone. Due tipi meritano attenzione perché sono quelli su cui si sbaglia la scelta.

  • L’Address Range rappresenta un intervallo definito dall’indirizzo più basso e da quello più alto. Serve esattamente quando l’intervallo non è esprimibile con un indirizzo di rete e una maschera, e ritorna nelle configurazioni di NAT e di VPN.
  • Il Network Group è un insieme di host, gateway, reti o altri gruppi. Si crea dall’albero degli oggetti con New e Network Group, gli si assegna un nome e, se serve, commento, colore e tag, e si aggiungono i membri con il pulsante di aggiunta. I gruppi si possono annidare. Da R80.20.M2 in poi si può anche associare un oggetto a un gruppo dall’editor dell’oggetto stesso, nella sezione Groups.

Due limiti da sapere a memoria, perché sono il tipo di dettaglio che viene chiesto alla lettera:

  • gli Updatable Objects non si possono inserire in un network group;
  • un network group usato dentro un gruppo con esclusione non può contenere oggetti che non siano basati su IP, per esempio dynamic object e domain object.

Service Objects e proprietà comuni

La categoria Services contiene i servizi e i gruppi di servizi: sono gli oggetti che descrivono protocollo e porta, e finiscono nella colonna Services & Applications insieme ad applicazioni, applicazioni mobili, siti, categorie di traffico e gruppi personalizzati. In quella colonna esiste l’opzione di negazione: indicare alcuni servizi e negarli significa far corrispondere tutti i servizi tranne quelli indicati.

Le proprietà comuni valgono per quasi tutte le famiglie di oggetti: nome, commento, colore e tag. Il nome è il solo campo davvero obbligatorio ed è anche quello che comparirà dentro le regole, quindi una convenzione di denominazione decisa prima vale più di qualunque bonifica fatta dopo. Commento e tag sono ciò che permette di ritrovare l’oggetto quando il database ne contiene migliaia.

Trappole tipiche d’esame

  • Scegliere il tipo di oggetto sbagliato. Per l’intervallo 10.0.5.20-10.0.5.35 serve un Address Range, non una rete: i confini non cadono su una maschera. Chi risponde “una rete con la maschera giusta” o chi crea sedici host separati è esattamente il caso di oggetto mal configurato.
  • Duplicati mascherati. Un host nuovo per un indirizzo già rappresentato, o un gruppo che replica un gruppo esistente con un membro in più, non danno nessun errore: danno due verità nello stesso database. Quando poi l’indirizzo cambia, se ne corregge una sola e l’altra resta a filtrare traffico con il valore vecchio.
  • Updatable Object dentro un network group. Non è permesso: se una risposta propone quel gruppo, è un distrattore.
  • Gruppo con esclusione riempito di oggetti non basati su IP. Dynamic object e domain object non ci possono stare.
  • Leggere Install On come un filtro sul traffico. Non decide chi passa, decide su quali network object la regola viene installata. Un oggetto sbagliato lì produce una regola che semplicemente non esiste dove servirebbe.
  • Modificare l’oggetto gateway credendo di toccare solo la sua scheda. Interfacce, indirizzi e blade attivi si riflettono nelle regole che lo richiamano e nella colonna Install On di tutte le altre.
  • Dimenticare la negazione. Un servizio negato in Services & Applications significa tutti tranne quello: chi lo legge come “solo quello” sbaglia la regola pur conoscendo i servizi a memoria.