Upgrade Check Point R65 HFA 70 à R75 HFA 40 + migration SmartCenter de Open Server à Smart-1

Voici un (long ?) article pour décrire le mode-opératoire appliqué aux opérations décrites ci-après et effectuées sur des produits Check Point:

• Migration d'un Security Management Server d'un Open Server de R65 HFA 70 à une Smart-1 en R70
• Montée de version logicielle de la Smart-1 en R75.40 SPLAT
• Montée de version logicielle des Security Gateways (UTM-1 57x) de R65 HFA 70 SPLAT à R75.40 SPLAT

Mais avant tout:

• De ces deux interventions et de leur préparations respectives, il faut en retenir:
  • (rappel) toute l'intelligence de vos firewalls Check Point réside dans le Security Management Server
  • Ce dernier, en version R75.40, est parfaitement capable d'administrer des Security Gateway en R65.70 (remontée des logs, compilation, monitoring, ...)
  • (prérequis) il est indispensable d'avoir un accès "Partner" au UserCenter de Check Point
  • Si vous avez plusieurs clusters à migrer, soyez minimum deux et prévoyez large au niveau temps: il se peut que vous ne puissiez pas paralléliser vos actions (problème de boot sur certaines clés USB par exemple... cet aspect sera décrit dans les chapitres suivants).

Je vous propose tout d'abord les axes de cet article:

1. Introduction:
   1. Objectifs
   2. Choix du mode opératoire
   3. Pré-requis
   4. Liens utiles
2. Préparation de l'upgrade: clé USB + paramétrage BIOS
3. Montée de version logicielle (Upgrade):
   1. Migration + upgrade du Security Management Server
   2. Upgrade des Security Gateways
4. Vérifications

Ces opérations étant assez lourdes et longues à décrire, les 4 axes ci-dessus représenteront autant d'articles connexes.


Passons à présent au premier volet de cet article: la description du besoin, le choix du mode-opératoire, la liste des pré-requis et des liens utiles.

--------

Introduction - Préparation - Montée de version & vérifications

Check Point / Et si vous perdiez la communication entre le SmartCenter et vos Security Gateways

Un cas concret cette fois-ci...

Vous travailler sur l'harmonisation de règles de sécurité Check Point... Vous appliquez des règles impactant la communication entre les Security Gateway et le SmartCenter pour un cluster donné. Cela fonctionne, vous souhaitez appliquer les mêmes règles sur votre autre cluster... vous faites un simple copier/coller.

Avant tout: Check Point propose différent mode d'application (push) de règles de sécurité:

 . Un fichier de règles de sécurité (Policy Package) par cluster

 . Un fichier de règles que vous allez appliquer à l'ensemble des cluster ou des Security Gateway.

Dans le premier cas, dans la colonne "INSTALL ON" de chacune des règles, vous avez la possibilité de laisser le champ à la valeur par défaut: "Policy Targets"... vous n'appliquerez ces règles qu'au cluster prévu (cf. Menu 'Policy' -> 'Policy Installation Target').

Dans le deuxième cas, il faudra préciser si la règle s'applique à l'ensemble des clusters gérés ou à l'un ou l'autre.

Revenons à présent à notre cas concret.

Nous utilisons le premier mode d'application des règles mais certaines d'entre-elles stipulent tout de même le cluster cible.

Vous copiez les règles dédiées au cluster 1... et vous les collez dans celui dédié au cluster 2...

A la compilation, le SmartCenter n'installera pas la règle qui autorise les Security Gateway et le SmartCenter à communiquer (puisqu'elle est dédiée à l'autre cluster)... vous venez de perdre la communication entre votre SmartCenter et les membres de votre cluster 2.

En fonction des autorisations qui n'auront pas été installées sur les membres de ce cluster 2, les comportement peuvent varier...

Vous vous dites donc:

 . Où sont mes sauvegardes et de quand datent-elles ?

 . En réinjectant la dernière sauvegarde, module par module, ceux-ci vont redémarrer... le HA va-t-il fonctionner ?

... en fait, une action rapide et surtout efficace peut être réaliser.

Son principe: enlever toute politique de sécurité sur chacune des Security Gateways puis leur demander de récupérer le fichier de règles (Policy Package) corrigé.

Ce mode opératoire est identique à celui que vous devez appliquer lors de la mise en place de nouveaux équipements:

 . Corrigez les règles de sécurité...

 . Vous devez les 'compiler'... il vous faut donc accéder au menu 'Policy' et choisir 'Install Database'.

 . Vous vous connectez tour à tour sur les membres du cluster et, en CLI, vous effectuez les deux actions explicitées ci-dessus:

    - fw unloadlocal

    - fw fetch <adresse IP du SmartCenter>

Le résultat et de ce type:

[Expert@<nom de la Security Gateway>]# fw fetch <adresse IP du SmartCenter>

Fetching Security Policy From: <adresse IP du SmartCenter>


Installing Security Policy <nom du fichier de règles Policy Package> on all.all@<nom de la Security Gateway>

Vous venez de reprendre la main sur vos Security Gateways ... il est même inutile de compiler ;)

Debug VPN sur Check Point / en CLI avec 'vpn debug' et 'vpn tunnelutil' & IKE Viewer

Lorsque votre tunnel VPN ne monte pas ou lorsque les requêtes autorisées n'aboutissent pas, l'application 'vpn' accessible en commandes en ligne (CLI) peut être d'une très grande aide (en fait... c'est quasi obligatoire :) ).

Vous devez donc accéder en CLI sur la Security Gateway VPN active.

Exécutez la commande 'vpn' de sorte à en voir les modalités d'utilisation:

# vpn

Usage:
vpn debug ...                            # print debug msgs to VPN log files
vpn crl_zap                              # erase all CRLs from cache
vpn drv ...                              # attach vpn driver to fw driver and more
vpn ver [-k]                             # display VPN version
vpn accel ...                            # operations on VPN accelerator card and VPNx
vpn crlview ...                          # debugging tool for CRLs
vpn compstat                             # display compression/decompression statistics
vpn compreset                            # reset compression/decompression statistics
vpn macutil [user_name]                  # display generated MAC address by username or
                                         # DN from arg or stdin (also: vpn mu)
vpn tunnelutil                           # launch TunnelUtil tool to control
                                         # VPN Tunnels (also: vpn tu)
vpn export_p12 ...                       # tool to export p12 from gw certificate
vpn nssm_topology ...                    # generate topology in NSSM format for
                                         # Nokia clients
vpn rll dump fileName                    # Route Lookup Layer: Dump DB
vpn rll sync                             #                     Sync DB
vpn sw_topology ...                      # Download topology for SofaWare GWs
vpn overlap_encdom ...                   # Display overlapping encryption domains
vpn dll dump fileName                    # DNS Lookup Layer: Dump DB
vpn dll resolve [hostname]               #                   Request Resolve
vpn ipafile_check filename [level]       # Verify candidate for ipassignment.conf
vpn set_slim_server...                   # Starting/stopping the slim web server
vpn set_snx_encdom_groups...             # enabling/disabling the encryption domain per usergroup feature for snx
vpn mep_refresh                          # Initiate MEP re-decision in case of
                                         # backup stickiness configuration
vpn rim_cleanup                          # Clean RIM routes
vpn shell ...                            # Command Line Interface
vpn set_trac disable/enable              # Starting/Stopping trac server
vpn neo_proto [on/off]                   #switching neo client protocol

Vous le voyez: cette commande va vous permettre de faire un travail très fin autour de votre VPN.

Les commandes les plus utiles (ou en tous cas celles qui sont suffisantes) sont:

 . vpn debug

 . vpn tunnelutil

La première va vous permettre d'activer certains niveau de debugage => la génération de fichier de debug à utiliser avec des outils externes.

La seconde vous permettra d'interagir avec l'établissement du tunnel et de ses deux phases: IKE et IPSec

Utilisation de la commande 'vpn debug'

Les options suivantes sont disponibles:

# vpn debug --help
 Usage: vpn debug < on [ DEBUG_TOPIC=level ] | off | ikeon [ -s size(Mb) ]| ikeoff | trunc | truncon | truncoff | timeon [ SECONDS ] | timeoff | ikefail [ -s size(Mb) ]| mon | moff >

Les fichiers de debug seront générés dans l'arborescence des fichiers de log $FWDIR/log.

La commande 'vpn debug ikeon' activera ainsi la génération du fichier de debug ike.elg. Celui-ci renseigne sur l'établissement des deux phases de votre VPN: si l'une d'entre-elles a échouée, le fichier en stipulera la raison.

Ce fichier est exploitable par l'outil (magique ?) IKE Viewer.

Ce dernier est accessible depuis le Usercenter à l'URL: http://dl3.checkpoint.com/paid/11/IKEView-NGX.zip?HashKey=1352291050_70cdc9eff560511a1a696b6ebe1d072f&xtn=.zip

Utilisation de la commande 'vpn tunnelutil'

Les options suivantes sont diponibles:

# vpn tunnelutil --help      

**********     Select Option     **********

(1)List all IKE SAs
(2)List all IPsec SAs
(3)List all IKE SAs for a given peer (GW) or user (Client)
(4)List all IPsec SAs for a given peer (GW) or user (Client)
(5)Delete all IPsec SAs for a given peer (GW)
(6)Delete all IPsec SAs for a given User (Client)
(7)Delete all IPsec+IKE SAs for a given peer (GW)
(8)Delete all IPsec+IKE SAs for a given User (Client)
(9)Delete all IPsec SAs for ALL peers and users
(0)Delete all IPsec+IKE SAs for ALL peers and users

(Q)Quit

*******************************************

Et oui: vous allez pouvoir vous assurer du statu des phases IKE et IPSec et interagir avec elles.

Debug VPN sur Check Point

Pour avoir été confronté à de nombreuses reprises à des VPN qui ne fonctionnaient pas tout de suite, il m'a été utile d'en effectuer le debugage.

Il y a plusieurs raisons pour lesquelles un tunnel VPN entre deux gateways ne s'établit pas (en tous cas dès la première tentative ;) ).

Déjà, la bonne méthode est d'échanger avec le partenaire d'en face un document stipulant les différents éléments de configuration que les deux parties veulent (ou exigent) mettre en place.

Il va de soit que les deux étapes d'établissement d'un tunnel VPN (IKE et IPSec) doivent être identiques des deux côtés.

Bon: à présent vous êtes sur un paramétrage identique de part-et-d'autre.. et çà ne fonctionne pas.

Soit:

 . Le tunnel VPN ne s'établit pas (une des deux phases tombe en erreur, dès le départ ou à l'envoi/réception d'une requête)

 . Le tunnel est OK mais les requêtes n'aboutissent pas.

Si la technologie Firewall utilisée est Check Point, trois éléments vont vous aider à en trouver l'origine:

 . L'application Check Point SmartView Tracker

 . Les outils de debug VPN accessible en CLI sur la Security Gateway VPN active

 . Le Usercenter de CheckPoint et/ou CPUG (The CheckPoint User Group)

L'utilisation de ces éléments seront abordés dans des billets dédiés.

Les différents cas qui ont fait que mes tunnels VPN n'aboutissaient pas ou n'étaient pas fonctionnels:

 . Domaines d'encryption local et/ou distant incorrects

 . Réseau naté non présent dans le domaine d'encryption local/distant

Ces cas concrets seront abordés dans des billets dédiés.