dimanche 4 novembre 2012

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

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


Article 2/4: Introduction
Accédez directement aux autres articles: Accueil - Introduction -


Introduction

Objectifs

Précisons tout d'abord le contexte:
  • Le Security Management Server:
    • Serveur HP (mais peu importe la marque):
    • Check Point Secure Plateforme (SPLAT) pour l'O.S.
    • Check Point R65 HFA 70 pour la partie firewalling
  • Deux clusters de (chacun) deux modules firewalls en actif/passif:
    • Quatre UTM-1 57x
    • Check Point Secure Plateforme (SPLAT) pour l'O.S.
    • Check Point R65 HFA 70 pour la partie firewalling


Notre objectif est d’effectuer la montée de version logiciel sur l'ensemble des produits en R75.40 SPLAT (et non GAiA - un peu trop récent encore à la mi-2012).

... Si vous voulez toutefois avoir plus d'information sur GAiA et adaptez ce mod-op avec GAiA au lieu de SPLAT, commencez par: Check Point GAiA FAQ...

Nota bene: la version R65.70 n'est plus suivie depuis mars 2011 (cf. Check Point Software Support Timeline) et l’écart entre cette version et la version cible (disponible depuis avril 2012) posent un certain nombre de problèmes... ou en tous cas restreint énormément la marge de manœuvre pour effectuer cette montée de version.

Choix du mode-opératoire

Nous avons découpé cette opération en deux étapes:
  • La migration puis l'upgrade du Security Management Server
  • L'upgarde des Security Gateways

Pour le Security Management Server...

A moins que vous ne souhaitiez repartir d'une configuration vierge... il  faudra récupérer la configuration existante (règles, objets, ...).
Pour cela, il est nécessaire de passer par un outil d'export/import de ces éléments: ça s'appelle "export_database tool".
Le principe est le suivant: depuis un SmartCenter source en version X, on va exporter cette base de données (sous forme d'archive) vers un SmartCenter cible en version Y.
Deux choses sont à prendre en compte dans notre cas:
  • Ce script ne fonctionne qu'entre deux versions X et Y assez proches.
  • Pour faciliter le retour arrière, nous avons souhaité ne pas modifier le SmartCenter source.
En tenant compte du document Check Point R70, R71 and R75 Release Map et en souhaitant minimiser le nombre d'upgrade nous sommes donc parti du schéma d'upgrade suivant:
  1. Exporter la base de données du SmartCenter source en R65 vers la Smart-1 en R70 (compatibilité effective de l'"export_database tool" entre ces deux versions)
  2. Upgrade de la Smart-1: de R70 à R70.50
  3. Upgrade de la Smart-1: de R70.50 à R75.40

Pour les Security Gateways

Encore une fois: la vrai intelligence chez Check Point se trouve dans le SmartCenter.
On peut donc préférer une fresh install au chemin d'upgrade décrit ci-dessus.
Ce mode d'installation est le plus rapide: on va booter sur une image ISO (on verra par la suite comment) et un tout nouveau système sera installé en lieu et place de l'ancien.
  1. Tout d'abord les modules secondaires (même si c'est contraire au mode-opératoire proposé par Check Point) => en cas de retour arrière, la coupure de service est minimisée puisque les modules primaires n'avaient pas été impactés
  2. Ensuite les modules primaires.

Pré-requis

Pour appliquer le mode-opératoire décrit précédemment, il va falloir:
  • Les sauvegardes nécessaires
  • Télécharger les outils, programmes et documentations nécessaires
  • Prévoir quelques bonnes heures devant soi (ne pas faire ces opérations tout seul ! être au moins deux)

Sauvegardes

Les sauvegardes ne sont pas à négliger !
Normalement, l'article How to back up your system serait tout indiqué; mais dans notre cas, cette procédure ne peut s'appliquer (différence trop importante entre les versions source et cible ;) ).
Pour le SmartCenter source: un snapshot habituel suffira puisque l'on y minimise les actions (il ne devrait d'ailleurs serveur que d'au cas où).
Pour les Security Gateways:

Liens utiles

Vous trouverez le long de ces articles tous les liens qui m'ont été utiles à la préparation de cet migration.
Après, il y a deux URL auxquelles vous devrez quasiment forcément accéder:
  • Le portail Check Point User Center: un grand nombre d'éléments nécessaires à cette migration sont accessibles depuis ce portail avec un compte et mot de passe.
    • Par exemple, pour savoir si vous pouvez mettre à jour directement ou via des versions intermédiaires vos produits Check Point, il faut y recherche "release and upgrade path" (le lien actuel est: Check Point R70, R71 and R75 Release Map)
  • Check Point User Group est un portail d'utilisateurs avancés des produits Check Point; pour reprendre leur intitulé: "Fast. Useful. Independent"

samedi 3 novembre 2012

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

mercredi 10 octobre 2012

Sonde SNMP InterMapper pour Check Point / Security Gateway / UTM-1 Series - version 1.5

[For the English version: click here]

Une nouvelle version de ma sonde de supervision pour les Security Gateway de type UTM-1 de Check Point.


Cette dernière version est la 1.5.

Elle permet d'accéder de manière plus avancée à la supervision des éléments hardware et pour l'occasion de remplacer CheckPoint par Check Point ;)


 Date        | Version | Who           | Actions
----------------------------------------------------------------------------------
10 oct. 2012 |  1.5    | X. BENSEMHOUN | adding hardware sensors abilities
             |         |               | + dbl click functions (access Web GUI)
             |         |               | + modif CheckPoint by Check Point :)
05 dec. 2011 |  1.4.2  | X. BENSEMHOUN | change flag header to show iface activities
06 oct. 2011 |  1.4.1  | X. BENSEMHOUN | update information for feedback
             |         |               | + fix flag header
02 sep. 2011 |  1.4    | X. BENSEMHOUN | usage of HOST-RESOURCES-V2-MIB.mib instead of
             |         |               | V1 version (for ondemand table)
01 sep. 2011 |  1.3.1  | X. BENSEMHOUN | not include any more partitioning probe
             |         |               | some limitations on version < 5.6 :(
             |         |               | + some cleaning things
             |         |               | + 06 oct. 2011 update
29 aug. 2011 |  1.2.1  | X. BENSEMHOUN | include Host Resources General Informations
             |         |               | (equivalent to 'SNMP Host Resources' integrated probe)
             |         |               | + 06 oct. 2011 update
24 aug. 2011 |  1.1.1  | X. BENSEMHOUN | include partitioning probe (using probe parameters)
             |         |               | + 06 oct. 2011 update
23 aug. 2011 |  1.0.1  | X. BENSEMHOUN | complete layout
             |         |               | + 06 oct. 2011 update
16 aug. 2011 |  0.2    | X. BENSEMHOUN | implementation of all functions
19 aug. 2011 |  0.1    | X. BENSEMHOUN | Creation, first functions


Je vous propose l'accès à cette version ainsi qu'aux versions antérieures:
 . known good_v1.5
 . known good_v1.4.2
 . known good_v1.4.1
 . known good_v1.3.1
 . known good_v1.2.1
 . known good_v1.1.1
 . known good_v1.0.1


Pour que je continue de faire évoluer ces sondes, je vous demande de bien vouloir laisser vos remarques/souhaits.

dimanche 26 août 2012

Comment configurer Zscaler pour des connexion FTP natives ?

Comment configurer Zscaler pour des connexion FTP natives ?

Seul le mode natif du FTP est pris en charge depuis un emplacement connu.

Accéder à l'URL http://ip.zscaler.com afin de vous en assurer.

Toute la configuration Zscaler FTP se fait sous Administration -> Internet Gateways & SSL.
Suivez les étapes ci-dessous afin de configurer Zscaler et votre client FTP:
1. Ajouter votre site
2. Activer le FTP (même pour du FTP over HTTP)
3. Définir la liste des sites qui seront accessibles en FTP 

4. Configurer le client FTP pour vous connecter au travers de Zscaler (ex: gateway.zscaler.net) sur le port 21

Le paramétrage de la connexion FTP doit inclure l’authentification Zscaler:
USER <login> @ <destination_hostname>
PASS <password>
... il vous faudra bien évidement un client FTP qui puisse proxifier cette connexion.

Les connexions FTP natives au travers de Zscaler n'ont pas besoin d'une authentification spécifique. Pour l'heure, l'authentification se base sur la localisation IP de la passerelle.







 


Cette article est la traduction d'une KB émise par Zscaler dont l'exacte retranscription se trouve également sur ce blog: How to setup Zscaler for Native FTP usage.

jeudi 23 août 2012

How to setup Zscaler for Native FTP usage

How to setup Zscaler for Native FTP usage ?

Native FTP is only supported from known location.
All Zscaler FTP configuration is done under Administration -> Internet Gateways & SSL.
Please find below steps to setup Zscaler Native FTP:
1. Add your location
2. Enable FTP (this will enable both FTP over HTTP and Native FTP protocols)
3. Define categories which will have FTP access granted
4. Configure FTP client to connect our proxy (ie: gateway.zscaler.net) on port 21

Zscaler FTP proxy forward customer request to destination FTP server based on Username content.
USER <login>@<destination_hostname>
PASS <password>
Most of FTP client supports proxy confguration.

Zscaler Native FTP doesn't need specific Proxy login / pass credentials.  By now, we authenticate customers based on their gateway location IP.
Copyright 2012 Zscaler Inc.