Lab: la SIC si verifica prima di toccarla

La SIC è il meccanismo proprietario con cui i componenti Check Point si autenticano fra loro: certificati, canali TLS e cifratura. I certificati li emette la Internal Certificate Authority che gira sul Security Management Server, con validità predefinita di cinque anni e chiave da 2048 bit. È il punto da cui parte la diagnosi: la fiducia non è una configurazione, è un certificato, e un certificato ha una scadenza, un emittente e un orologio che lo giudica.

SmartConsole espone tre stati, e vanno distinti perché portano in direzioni opposte. Communicating significa che il canale sicuro è stabilito. Unknown significa che non esiste alcuna connessione: nessuno ha risposto, quindi il sospetto è su routing, interfaccia, NAT o una regola che blocca il traffico di gestione. Not Communicating significa che il contatto è avvenuto ma la SIC è fallita: qui il sospetto è sul certificato, sulla activation key o sull’ora. Confondere i due stati porta a cercare mezz’ora nel posto sbagliato.

Dalla riga di comando del gateway, cp_conf sic state mostra lo stato corrente della fiducia. È il primo comando da eseguire, prima di qualunque ipotesi.

La checklist documentata, nell’ordine giusto

La procedura R82 elenca i controlli da fare prima di ricostruire alcunché:

  1. Verificare la connettività fra gateway e Management Server.
  2. Verificare che la activation key sia la stessa sui due lati.
  3. Verificare che le regole permettano la comunicazione fra Management Server e gateway.
  4. Verificare che il file /etc/hosts sul gateway contenga nome e indirizzo del Management Server.
  5. Verificare che data e ora siano sincronizzate, anche quando i due sistemi stanno in fusi orari diversi.

Il quinto punto è dichiarato come prerequisito esplicito dell’inizializzazione della fiducia: gli orologi devono essere sincronizzati prima, non dopo. Uno scarto di orologio produce esattamente il sintomo di un certificato non valido, e nessun reset lo corregge.

Solo quando la checklist ha escluso tutto il resto si ricostruisce. Da SmartConsole: Gateways & Servers, doppio clic sull’oggetto, scheda Communication, Reset, e poi Install Policy per distribuire la CRL aggiornata con il numero di serie del certificato revocato. Da riga di comando sul gateway si usa cpconfig alla voce Secure Internal Communication, oppure cp_conf sic init con la activation key; il parametro norestart evita il riavvio immediato dei servizi Check Point, utile quando si vuole scegliere il momento del fermo. Per i gateway con indirizzo dinamico esiste cp_conf sic cert_pull, che preleva il certificato dal Management Server indicato.

Lab: i processi del gateway, letti per colonne

cpwd_admin list non elenca tutto ciò che gira sul gateway: elenca ciò che il WatchDog sorveglia. La lettura utile è per colonne. STAT vale E per un processo in esecuzione e T per uno terminato. #START conta quante volte il WatchDog lo ha avviato. START_TIME riporta l’ultimo avvio. MON dice se il monitoraggio è attivo (Y) o passivo (N). APP, PID e COMMAND completano il quadro, e -full aggiunge timeout, limiti di risorsa e percorsi completi.

La diagnosi sta nella combinazione, non nella singola cella. Un processo con STAT a E sembra sano, ma se #START è alto e START_TIME è di pochi minuti fa su una macchina accesa da giorni, quel processo sta morendo e rinascendo: lo stai fotografando in uno dei suoi risorgimenti. Un processo con STAT a T e #START fermo è invece caduto una volta sola e non è stato ripreso. Sono due guasti diversi, con cause diverse, e la differenza si legge solo tenendo insieme tre colonne.

Il secondo punto è che quella tabella non si può ricostruire. Un cpstop seguito da cpstart azzera i contatori e allinea gli orari: dopo, nessuno potrà più dire quante volte il processo era caduto. Se serve intervenire su un singolo processo sorvegliato, cpwd_admin start e i comandi correlati sono lo strumento chirurgico da preferire al fermo globale. E comunque si salva prima l’output.

Trappole tipiche d’esame

Ricostruire la SIC prima di aver verificato che sia lei il problema. Lo scenario tipico descrive un gateway che non riceve la policy e offre fra le risposte un reset immediato della SIC. Il reset revoca il certificato, richiede una reinstallazione della policy per distribuire la CRL e fa perdere lo stato. La risposta corretta è quasi sempre il controllo che viene prima: cp_conf sic state, connettività, activation key, /etc/hosts, orologi.

Riavviare i processi senza averne raccolto lo stato. Fra due opzioni in cui una raccoglie e una riavvia vince la raccolta, perché il riavvio azzera #START e START_TIME. Un’opzione che propone cpstop e cpstart come primo passo diagnostico è quasi sempre un distrattore.

Attribuire al gateway un guasto che sta nella comunicazione col Management Server. Uno stato Not Communicating, un errore di installazione della policy o log che non arrivano non dicono che il gateway sia guasto: dicono che il canale non regge. Con processi in stato E e policy installata, continuare a scavare sul gateway è tempo perso.