Un errore che compare in SmartConsole viene quasi sempre raccontato come un problema del gateway. Di solito non lo è: fra l’amministratore e il gateway ci sono un client, un server di gestione con il suo database e un API Server, e ciascuno sa fallire a modo suo. Il primo lavoro dell’expert è decidere in quale dei tre sta il guasto, prima di aprire un debug.

Separare i piani prima di indagare

SmartConsole è un client: mostra il risultato di chiamate al Management Server. Se un’operazione fallisce lì, le possibilità sono tre — il client non parla con il server, il server non riesce a eseguire, oppure il server esegue e il gateway rifiuta. Tre indagini diverse, tre insiemi di comandi diversi.

fwm ver restituisce la versione Check Point del Management Server. Un’operazione che al gateway non arriva mai esclude di partenza i comandi del gateway; un’installazione di policy che parte e viene respinta sposta invece l’attenzione sul lato remoto. Su Multi-Domain Security Management, prima di qualunque comando va impostato il contesto corretto con mdsenv: un comando eseguito nel contesto sbagliato risponde su un dominio che non è quello del problema, e l’output sembra sano.

Processi, WatchDog e log

Sul Management Server l’indagine strutturale comincia da cpwd_admin list, che elenca i processi sorvegliati dal WatchDog. Vanno lette le colonne: APP è il nome WatchDog del processo, PID il suo identificativo, STAT lo stato (E per executing, T per terminated), #START quante volte il WatchDog lo ha avviato, START_TIME l’orario dell’ultimo avvio, MON il tipo di monitoraggio (Y attivo, N passivo) e COMMAND il comando di avvio. L’opzione -full estende l’output.

È qui che si distingue un servizio fermo da un servizio malato. Un processo con STAT a T è semplicemente giù. Un processo con STAT a E, ma con #START a due cifre e START_TIME recente, è vivo nell’istante in cui guardi e sta ripartendo in ciclo: dal punto di vista dell’utente i due casi si assomigliano, dal punto di vista della diagnosi no.

I processi che contano sul Management Server sono cpd, generico per molti servizi Check Point fra cui installazione e fetch della policy, fwd per i log, cpca per la Certificate Authority, fwm, che la documentazione descrive come processo principale di gestione legacy delle versioni R77.x e precedenti, oltre a CPM, postgres e solr. I rispettivi file di traccia stanno sotto la directory di log del prodotto, e molti sottocomandi fwm accettano l’opzione -d, che ne esegue la variante di debug.

L’API Server: stato, accesso, permessi

L’API Server è un componente a sé e va interrogato come tale. api status ne riporta lo stato, con la riga «Overall API Status: Started» quando è operativo; api restart lo riavvia. La configurazione vive in SmartConsole sotto Manage & Settings > Blades > Management API > Advanced Settings, e contiene due impostazioni che spiegano da sole gran parte dei casi.

La prima è Automatic start, che avvia l’API Server al riavvio del Management Server: è attiva per impostazione predefinita sopra i 4 GB di RAM e disattiva sotto. Un server con poca memoria riparte quindi senza API, e ogni automazione smette di funzionare senza che nulla appaia rotto. La seconda sono le Access settings, con tre scelte: Management server only, che accetta solo mgmt_cli eseguito in locale; All IP addresses that can be used for GUI clients, che ammette i Trusted Clients; All IP addresses. A queste si aggiunge il permesso dell’amministratore: serve un Permission Profile con Management API Login nella sezione Management.

Il client da riga di comando è mgmt_cli, nella forma nome del comando, parametri del comando e switch opzionali; eseguito senza parametri stampa l’elenco completo delle sue opzioni. Esiste anche un portale di documentazione API sul server stesso, all’indirizzo /api_docs, disabilitato per impostazione predefinita (sk174606).

Comandi legacy e comandi attuali

fwm resta il coltellino svizzero del Management Server: logexport per esportare log di sicurezza o di audit in ASCII, unload per scaricare la policy dai gateway gestiti, printcert e fingerprint per i certificati SIC, sic_reset per il SIC del server, mds per le operazioni Multi-Domain. Due sottocomandi però sono un tranello: la documentazione dichiara fwm verify e fwm load obsoleti «for R80 and higher» e rimanda a mgmt_cli. Proporli su R82 è sbagliato anche se i comandi esistono ancora.

Trappole tipiche d’esame

Cercare sul gateway un problema che sta nel Management Server. Se il sintomo è in SmartConsole o in un’automazione, il gateway è l’ultimo posto da guardare. Chiediti prima se la richiesta ha raggiunto il server e se il server l’ha eseguita.

Trascurare l’API Server. Lentezze, oggetti che non si creano e script che falliscono dopo un riavvio hanno spesso una causa sola: API Server non avviato, Access settings troppo restrittive o Permission Profile senza Management API Login. api status costa un secondo.

Non distinguere un servizio fermo da uno che risponde male. STAT a E non significa sano: un #START alto con un START_TIME recente descrive un processo in ciclo di riavvio, e un API Server con stato Started può comunque rifiutare la connessione per origine o permessi.