Che cosa viaggia nell’export e che cosa resta dov’è

In un deployment distribuito il Security Management Server sta su una macchina sua e i Security Gateway sono macchine separate, spesso parecchie. Quando si migra la gestione, l’export e l’import di migrate_server toccano soltanto quella macchina: portano il database di gestione e la configurazione di Check Point del server, cioè oggetti, regole, policy, profili degli amministratori, la Internal Certificate Authority con i certificati che ha emesso e, salvo esclusione esplicita, le licenze.

I gateway non sono dentro l’archivio. Restano sulle loro macchine con la loro versione, la loro configurazione di Gaia e il certificato SIC che hanno ricevuto al momento dell’inizializzazione. È proprio per questo che la fiducia sopravvive alla migrazione: l’autorità che ha firmato quei certificati viaggia con il database, e il server nuovo la ritrova identica. Se invece si azzera il SIC su un gateway «per sicurezza», si distrugge una relazione che era intatta e si aggiunge lavoro e rischio a una procedura che non lo chiedeva.

Anche i log seguono una regola propria: non partono con il database a meno che l’esportazione non li includa esplicitamente, con o senza indici. Un Log Server dedicato o un SmartEvent Server dedicato sono macchine a sé e si aggiornano o si migrano con la loro procedura, non per riflesso della migrazione del management.

L’ordine delle operazioni in un ambiente distribuito

L’ordine è la parte del modulo su cui si sbaglia di più, ed è semplice da memorizzare: prima i Management Server, poi i Log Server e i SmartEvent Server dedicati, infine i Security Gateway e i cluster. Un management aggiornato può convivere con gateway ancora alla versione precedente, purché quella versione sia nell’elenco di quelle supportate; il contrario non è una configurazione prevista.

Sulla destinazione serve un’installazione pulita, completata con il First Time Configuration Wizard e senza configurazione iniziale da SmartConsole, con licenza valida e Upgrade Tools installati. L’IP può restare lo stesso oppure cambiare, ma la decisione va presa prima: se cambia, il nuovo indirizzo si dichiara nel file preparato sulla destinazione prima dell’importazione.

Il passaggio in produzione è un taglio, non una sovrapposizione: il server vecchio si scollega dalla rete e solo allora si collega quello nuovo. Due server di gestione attivi con lo stesso indirizzo, o con lo stesso certificato dell’autorità interna, sono un problema che si manifesta molto dopo e in modo confuso.

Rimettere in piedi l’ambiente e verificarlo

Finito l’import, si procede in quest’ordine. Si installa SmartConsole R82 e ci si collega al server nuovo. Si controlla la licenza con cplic print, e se l’indirizzo è cambiato si emettono le nuove licenze nel Check Point User Center, si installano, si rimuove la vecchia e si riavviano i servizi. Si aggiorna l’indirizzo e la topologia nell’oggetto del server di gestione e si allinea la versione degli oggetti dei server dedicati già aggiornati.

Poi si guarda il database con gli occhi, prima di scaricarlo sui gateway: gli oggetti ci sono, le regole sono quelle attese, gli amministratori e i profili di permessi sono al loro posto, i gateway compaiono nella vista Gateways & Servers e comunicano. Solo a quel punto si esegue Install database su tutti gli oggetti e si installa la policy sui gateway; se SmartEvent è attivo si installa anche la Event Policy, e se esistono profili SmartLSM si installa la policy anche su quelli. Se SmartConsole si collega attraverso gateway di generazione R7x, va prevista una regola esplicita che permetta la porta TCP 19009.

Trappole tipiche d’esame

  • Il backup che manca è sempre quello «completo». Database, certificati e licenze stanno nell’export, ma un export privo delle licenze, o preso senza avere pubblicato le modifiche, è un backup che sembra completo e non lo è. In un ambiente distribuito va aggiunta la copia del Log Server dedicato.
  • La procedura ha un ordine, e l’ordine è la risposta. Management, poi server di log e SmartEvent, poi gateway. Uno scenario che aggiorna i gateway per primi è sbagliato anche quando ogni singola installazione riesce.
  • Azzerare il SIC non è un passaggio della migrazione. I certificati dei gateway restano validi perché l’autorità interna viaggia nel database. Reinizializzare la fiducia è l’errore che trasforma una migrazione riuscita in un fermo del traffico.
  • Installare la policy prima di verificare il database. I problemi di un database importato male emergono all’installazione della policy: proprio per questo la verifica degli oggetti e l’Install database vengono prima, non dopo.
  • Il vecchio server lasciato acceso. Tenerlo in rete «per un giorno, per sicurezza» è la causa classica di gateway che si collegano al server sbagliato.
  • I log non sono nel database. Chi si aspetta di ritrovare lo storico degli eventi senza avere chiesto l’esportazione dei log scopre l’omissione quando ormai il server sorgente è stato dismesso.