Il primo bivio: con chi sta parlando SmartConsole

SmartConsole è un client, e il suo interlocutore è il Security Management Server, oppure il Domain Management Server quando l’ambiente è Multi-Domain. Non è il Security Gateway. Questa frase sembra ovvia e invece decide metà delle diagnosi: se un amministratore non riesce ad aprire SmartConsole, il gateway può essere perfettamente sano, con la policy installata e il traffico che passa, e il problema resta intatto.

Prima di toccare qualsiasi cosa conviene classificare il sintomo in una delle tre famiglie. Il server non risponde affatto: è un problema di raggiungibilità o di processi fermi lato Management Server. Il server risponde e rifiuta: è un problema di identità dell’amministratore o di autorizzazione del posto da cui si connette. Il server accetta e la sessione non si comporta come previsto: tipicamente è la spunta di connessione in sola lettura, oppure il permission profile associato all’amministratore.

Conta anche come si sta entrando: username e password, un certificate file, un certificato CAPI dal Windows Certificate Store, oppure un Identity Provider in SAML. Un guasto che colpisce un metodo non colpisce necessariamente gli altri: se il login con certificato fallisce e quello con username riesce, l’indagine si sposta sul certificato, non sul server.

Il fingerprint non è un guasto

Alla prima connessione verso un dato server SmartConsole mostra il fingerprint e chiede di confermarlo. Dopo la conferma, fingerprint e indirizzo IP del Security Management Server vengono salvati nelle impostazioni utente di Windows, e la richiesta non si ripresenta per quel server.

Da qui la regola pratica: la finestra del fingerprint che compare su una postazione nuova, su un profilo Windows nuovo o dopo un azzeramento delle impostazioni del client è il comportamento normale del prodotto, non un incidente. Diventa un segnale serio solo quando ricompare dove prima non compariva, oppure quando il valore mostrato è diverso da quello atteso.

La verifica si fa sul server, non sul client: fwm fingerprint localhost 443 restituisce il Distinguished Name del certificato e il fingerprint in esadecimale. Il comando accetta anche l’indirizzo di un server remoto e la porta SSL. Su un Multi-Domain Server va eseguito nel contesto del Domain Management Server interessato, passando prima per mdsenv. Se il valore sullo schermo del client coincide con quello del server, la voce va chiusa e l’indagine prosegue altrove.

Trusted Clients: credenziali giuste, porta chiusa

Il Security Management Server limita l’accesso a un elenco di host autorizzati, i Trusted Clients. In SmartConsole si trovano in Manage & Settings > Permissions & Administrators > Trusted Clients, e possono essere espressi come Any, indirizzo IPv4 singolo, range IPv4, netmask IPv4, i corrispettivi IPv6, nome host con IP fisso, oppure wildcard. Solo un amministratore con permessi Super User può aggiungerli, modificarli o eliminarli.

Lo stesso elenco si gestisce dal server con il Check Point Configuration Tool, cioè cpconfig, alla voce GUI Clients, oppure dalla riga di comando: cp_conf client get mostra l’elenco corrente, add e del lo modificano, createlist cancella l’elenco e ne crea uno nuovo, quindi va usato sapendo che cosa si sta sostituendo. Su un Multi-Domain Server cp_conf client non è supportato.

Il quadro clinico è inconfondibile: credenziali corrette, server che risponde, connessione respinta lo stesso. Le cause frequenti non sono errori di configurazione recenti ma cambi di posizione dell’amministratore: indirizzo assegnato in DHCP, subnet di VPN diversa da quella autorizzata, hostname in elenco che non risolve più sullo stesso indirizzo.

Lo stato del server dalla riga di comando

Quando il server sembra muto, la prima misura oggettiva è lo stato dei processi sotto WatchDog. cpwd_admin list mostra le colonne APP, PID, STAT, #START, START_TIME, MON e COMMAND. In STAT, E significa processo in esecuzione e T processo terminato; in MON, Y indica monitoraggio attivo e N passivo. Un processo in T, oppure un contatore #START che cresce con START_TIME sempre recente, racconta un riavvio ciclico: è quello il difetto, non la rete. Fra i processi elencati compaiono CPD, CPVIEWD, INDEXER, SOLR, SMARTVIEW e SMARTLOG_SERVER.

Il secondo strumento è cpstat, che mostra stato e statistiche delle applicazioni Check Point: con il flavour del Management Server si vedono i client connessi, con quello del sistema operativo CPU, memoria e disco. Un disco pieno spiega molti comportamenti che, visti dal client, sembrano problemi di autenticazione.

Trappole tipiche d’esame

  • Lo scenario nomina un gateway e la risposta giusta sta sul Management Server. La domanda descrive un amministratore che non entra in SmartConsole e aggiunge dettagli sul gateway, sulla policy o sul traffico. Sono rumore: il client dialoga con il Security Management Server. Scarta le opzioni che propongono di riavviare servizi sul gateway o di reinstallare la policy per far rientrare un amministratore.
  • Credenziali corrette non bastano. Se la traccia dice che username e password sono validi e che altri amministratori entrano senza problemi, il sospetto principale è l’elenco dei Trusted Clients, non la password. Cerca da quale indirizzo si connette la persona: un cambio di rete, un IP in DHCP o una VPN nuova sono l’indizio piantato apposta.
  • Il fingerprint richiesto alla prima connessione è normale. Una finestra che chiede di confermare il fingerprint su una postazione nuova non è un certificato scaduto né una compromissione: dopo la conferma il valore viene salvato nelle impostazioni utente di Windows. La risposta corretta è confrontarlo con quello del server, non rigenerare certificati o reinstallare SmartConsole.