Un CCTE lavora su macchine in produzione che non può permettersi di fermare. Prima ancora dei comandi, l’esame verifica che tu sappia in quale shell ti trovi e che cosa quella shell ti lascia fare.

Le due shell e la regola che le separa

Gaia Clish è la shell predefinita: una restrictive shell con controllo degli accessi basato sui ruoli, comandi strutturati in show, set, add e delete, e configurazione che diventa permanente con save config. Expert mode è la shell Linux completa: ci si entra con expert, si esce con exit, e non esiste una password predefinita — va configurata prima di poter usare la modalità.

Due frasi della Gaia Administration Guide valgono da sole come risposta d’esame: «If a command is supported in Gaia Clish, it is not supported to run the corresponding command in the Expert mode» e «The Expert mode is not a security feature. Rather, it offers protection against mistakes». In Expert mode hai tutto l’arsenale Unix per leggere il sistema — less, grep, tail -f, top, free -m, df -h, netstat, vi — ma se per quella modifica esiste un comando Gaia Clish o un comando Check Point, il file ritoccato a mano è la risposta sbagliata anche quando funziona.

Lab: esaminare le risorse di sistema sui Security Gateway

Il punto di partenza è CPView, «a text based built-in utility on a Check Point computer» che raccoglie informazioni generali di sistema (CPU, memoria, spazio disco) e dati dei Software Blades su Security Gateway, ClusterXL e Scalable Platform Security Group. Si lancia con cpview e si esce con Q. Sopra di esso si appoggiano gli strumenti mirati:

  • fw ctl affinity -l mostra come sono distribuite sulle CPU le istanze CoreXL firewall, le interfacce e i processi user space: -a aggiunge tutte le affinità correnti, -v i numeri IRQ delle interfacce, -r riorganizza l’output per CPU invece che per risorsa.
  • cpwd_admin list elenca i processi sorvegliati dal WatchDog con PID, stato, orario e numero di avvii: distingue un processo assente da uno che riparte di continuo.
  • show spike-detective legge la configurazione di CPU Spike Detective, che registra i picchi di CPU e, a differenza di un debug, non ha impatto sulle prestazioni.

Lab: semplificare le Security Policy

Semplificare una policy non è estetica: cambia il lavoro che il gateway fa per ogni connessione. Il gateway «searches for the first rule that applies to a connection» e valuta le colonne da sinistra a destra — Source, Destination, Services e Applications, Content, Action. Sulla stessa connessione la Rule Base può essere percorsa più volte: al SYN con le sole informazioni di rete, poi sugli header HTTP per Application Control e URL Filtering, poi sul corpo prima della decisione finale.

Da qui le mosse che il modulo chiama semplificazione: in alto le regole che intercettano più traffico, meno regole in totale, oggetti riusati invece di indirizzi duplicati, niente regole larghe che rimandano la decisione a un’ispezione più costosa. L’effetto è misurabile: fwaccel templates mostra le tabelle dei template SecureXL e segnala con un flag le regole che ne impediscono la creazione — oggetti Identity Awareness, Domain object, Dynamic object, Time object, Security Zone object. Una sola regola scritta male in cima alla Rule Base spegne i template per tutto ciò che sta sotto. I Drop Templates, invece, sono disabilitati per impostazione predefinita e si attivano da SmartConsole.

Quanto costa ogni strumento

Gli strumenti di osservazione non sono equivalenti. Il kernel debug è il caso limite: la procedura ufficiale azzera i flag con fw ctl debug 0, alloca il buffer con fw ctl debug -buf 8200, accende moduli e flag con fw ctl debug -m e raccoglie con fw ctl kdebug -T -f -o /var/log/kernel_debug.txt. La guida chiede di pianificare una maintenance window e avverte che il carico di CPU sale prima quando il kernel scrive alcuni messaggi, poi quando li scrive tutti. L’esempio documentato produce un file da 1,6 GB e consiglia la console seriale, perché l’accesso CLI può diventare inutilizzabile. Si chiude sempre con fw ctl debug 0.

L’alternativa è spostare il costo fuori dalla macchina: una cattura analizzata dopo con cpmonitor restituisce statistiche globali, top connections, server e servizi, e permette «better understanding of traffic bursts and peaks» senza lasciare acceso nulla sul gateway.

Trappole tipiche d’esame

Strumento invasivo su un gateway in produzione senza valutarne il costo. Se la domanda descrive un gateway carico e chiede il passo successivo, la risposta parte quasi sempre dallo strumento più leggero: CPView, CPU Spike Detective, una cattura da analizzare offline. Il kernel debug è corretto solo se il testo cita una finestra di manutenzione.

Statistiche in tempo reale scambiate per dati storici. CPView mostra il campione raccolto in quell’istante, non una serie nel tempo: se la domanda chiede quando è iniziato il degrado, la schermata corrente non risponde.

File di configurazione modificato a mano dove esiste un comando. In Expert mode la modifica riesce, e proprio per questo la trappola funziona: resta fuori dal meccanismo che Gaia rende permanente con save config e può essere sovrascritta. Se l’impostazione esiste in Gaia Clish, quella è la risposta.