mardi 20 décembre 2011

[BT Services] Lettre de Sécurité de décembre 2011

La Lettre De Sécurité de BT Services pour le mois de décembre est à présent disponible.
Elle est accessible à l'URL ci-dessous:
ftp://ftp.soc.btservices.fr/pub/btservices/lettredesecurite/2011/LS108_Decembre_2011.pdf

Le sommaire est:
  • Quelle sécurité pour la téléphonie?
  • Check Point : Connexion au SmartDashboard impossible (problème de base de données) ?
  • Alertes de sécurité
    1. Red Hat
    2. Microsoft Windows
    3. Mobilité
    4. Cisco
    5. Novell
    6. Oracle Solaris
    7. Juniper
    8. RSA
    9. Liste des éditeurs produits non affectés
  • Top ten des virus
  • Evenements
  • Sur le Web

vendredi 9 décembre 2011

[NES Security Lab]: Bienvenue au blog sécurité du labo R&D NES

Un billet pour l'ouverture par le pôle audit de NES de leur blog sécurité: NES Security Lab.
Bonjour à tous et bienvenue sur ce blog, Après plusieurs mois de réflexion, nous avons décidé de créer cet espace de publication dédié à nos retours d'expériences concernant la sécurité informatique. A travers ce blog, le lab R&D sécurité et Pentest de NES publiera des articles et des dossiers permettant à un public néophyte mais [...]

vendredi 2 décembre 2011

Concur: deux postes à pourvoir

Un ami qui travaille chez Concur m'a parlé aujourd'hui de deux offres en tant qu'ingé. système.

Si vous souhaitez postuler:
 . Senior System Engineer
Job Overview:
The senior system engineer act as a technical reference on production environments for systems and applications layers. He coordinates changes and new services onboarding. He leads some medium to large scale projects.
 . System Engineer II
Mission:
Au sein de l’équipe d’exploitation Informatique, vous intégrez l’équipe d'Administration ou vous aurez pour missions principales :
  • participation aux projets de refonte d'architecture et d’optimisation de la production
  • recette technique, intégration et mise en production de nouvelles applications
  • assurer la continuité de l’activité (monitoring, suivi de capacité), supervision
  • administration des systèmes Unix et Windows
  • collaborer avec les chefs de projet dans les phases de mises en œuvre lors des mises en production.

Alors n'hésitez pas !

mercredi 9 novembre 2011

InterMapper 5.5 est à présent disponible !

InterMapper 5.5 est à présent disponible !

Cet outil de supervision édité par la société Dartware vient de sortir en version 5.5.

De nombreuses nouveautés:
 - Sur InterMapper reports: des canevas de rapport sont à présent disponibles et la gestion des données a été améliorée (accès disque, stockage nécessaire, ...)
 - Une implémentation plus sexy des Charts (faut dire que cela faisait quelques années que cette partie n'avait pas été changée)
 - [et çà !... çà faisait longtemps également !] la possibilité d'afficher dans le label d'un équipement supervisé, une valeur récupérée par la sonde utilisée... et c'est pas tout !
 - Perfectionnement de l'outil Layer-2

La news est disponible sur: http://blog.intermapper.com/?p=390
Plus de détail sur cette nouvelle version: What's new et Release notes
Les liens de téléchargement: Upgrade


... J'ai hâte de tester !...

vendredi 21 octobre 2011

www.xavier-bensemhoun.fr : plus de 1000 visites ! Merci !

Cà y est, le cap des 1000 pages vues !

Je tenais à vous dire merci, tout simplement !
C'est un site qui s'étoffe et... je suis heureux de voir mon travail apprécié : http://blog.intermapper.com/?p=360 (Merci à toute l'équipe de Dartware ainsi qu'à la communauté InterMapper !)



Merci encore.


@très bientôt donc.

mardi 18 octobre 2011

Wiki InterMapper pour la communauté francophone

La communauté francophone peut se targuer d'avoir à présent son Wiki en Français.

En effet, Netwalker, le distributeur d'InterMapper en France et en Belgique héberge et met en œuvre depuis septembre 2011: wiki2.intermapper.fr/intermapperwiki.

Vous pourrez y trouver la documentation en Français ainsi que d'autres éléments: liens utiles et sondes de supervision éditées par les utilisateurs.

Le mot de l'équipe NetWalker:
InterMapper Wiki est un lieu d'échange autour d'InterMapper, c'est la raison pour laquelle nous avons décider de monter ce serveur Wiki afin que chacun puisse contribuer simplement. N'hésitez pas à nous contacter si vous avez une question ou si vous rencontriez un soucis.
Si vous n'êtes pas familier avec le WikiTexte, vous pouvez consulter : [Wikipedia Aide/Syntax] ou nous adresser votre message que nous publierons.

NetWalker Team

support@netwalker.fr



Alors: faites vous connaître et faisons en sorte ensemble d'agrémenter ce Wiki !

Sonde SNMP InterMapper pour PaloAlto Networks / Panorama - version 1.1

[For the English version: click here]

Une nouvelle version de ma sonde de supervision pour les boîtiers Panorama de PaloAlto Networks.
Cette dernière version est la 1.1.
Elle met en avant l'URL de ce blog pour le retour d'expérience des utilisateurs.

 Date        | Version | Who           | Actions
----------------------------------------------------------------------------------
18 oct. 2011 |   1.1   | X. BENSEMHOUN | update information for feedback
        2010 |   1.0   | X. BENSEMHOUN | Creation, first functions


Je vous propose l'accès à cette version:


Cette sonde a été transmise mercredi 19 octobre 2011, vous avez possibilité de la suivre en utilisant les références:
  • Dartware Support Team: Dartware #100727
  • InterMapper-Talk thread: msg06674


Et comme d'habitude, vous avez la possibilité de:

Sonde SNMP InterMapper pour PaloAlto Networks / PA-x020 - version 1.2

[For the English version: click here]

Une nouvelle version de ma sonde de supervision pour les boîtiers PA-x020 de PaloAlto Networks.
Cette dernière version est la 1.2.
Elle met en avant l'URL de ce blog pour le retour d'expérience des utilisateurs.

 Date        | Version | Who           | Actions
----------------------------------------------------------------------------------
18 oct. 2011 |   1.2   | X. BENSEMHOUN | update information for feedback
        2010 |   1.1   | X. BENSEMHOUN | Some modifications
        2010 |   1.0   | X. BENSEMHOUN | Creation, first functions


Je vous propose l'accès à cette version:


Cette sonde a été transmise mercredi 19 octobre 2011, vous avez possibilité de la suivre en utilisant les références:
  • Dartware Support Team: Dartware #100727
  • InterMapper-Talk thread: msg06674


Et comme d'habitude, vous avez la possibilité de:

lundi 17 octobre 2011

Sonde SNMP InterMapper pour Fortinet / Fortigate - version 1.2

[For the English version: click here]

Une nouvelle version de ma sonde de supervision pour les boîtiers Fortigate de Fortinet.
Cette dernière version est la 1.2.
Elle met en avant l'URL de ce blog pour le retour d'expérience des utilisateurs.

 Date        | Version | Who           | Actions
----------------------------------------------------------------------------------
18 oct. 2011 |   1.2   | X. BENSEMHOUN | update information for feedback
        2010 |   1.1   | X. BENSEMHOUN | Some modifications
        2010 |   1.0   | X. BENSEMHOUN | Creation, first functions


Je vous propose l'accès à cette version:

Vous trouverez ci-dessous les image du Set Probe et du Status Windows correspondant:

Cette sonde a été transmise mercredi 19 octobre 2011, vous avez possibilité de la suivre en utilisant les références:
  • Dartware Support Team: Dartware #100728
  • InterMapper-Talk thread: msg06675


Et comme d'habitude, vous avez la possibilité de:

dimanche 9 octobre 2011

Debug VPN sur Check Point / Les domaines d'encryption

Dans le cadre d'un debug de tunnel VPN, un des éléments sur lequel doit porter votre attention est le domaine d'encryption.
En fait, il y en a deux: un local et un distant. Et ces paramètres sont à configurer de part et d'autre du tunnel VPN.

Le domaine d'encryption correspond tout simplement aux plages IP qui seront amenées à transiter au travers de ce tunnel.

Prenons le cas d'un VPN reliant les plages IP 10.0.0.0/24 côté client et 192.168.0.0/16 côté prestataire de service.
Du côté client, le domaine d'encryption local est 10.0.0.0/24, le distant est 192.168.0.0/16 ... et c'est l'inverse côté prestataire.

Maintenant, le comportement de Check Point va différer en fonction de:
 . Domaines d'encryptions erronées
 . Domaine d'encryption local intégrant la plage IP locale ET distante (c'est un cas particulier et, et oui, çà m'est arrivé... :) )
 . Sens de communication des requêtes


Dans le premier cas, vous allez devoir utiliser le mode de débogage VPN ainsi que l'outil (magique ?) IKE Viewer (cf. précédent POST).

Dans les deux derniers cas, il faut comprendre le fonctionnement du firewall pour interpréter les erreurs présentes dans les logs du SmartView Tracker.
Le firewall voit arriver la requête. Les règles sont dépilées jusqu'à celle qui nous concerne. Or la plage IP cible de cette requête est intégrée au domaine d'encryption local => le firewall n'a aucune raison de faire emprunter le tunnel VPN à cette requête (pourtant conformes aux règles de sécurité établies).
Vous verrez donc la requête refusée (très certainement par la dernière règle) et vous vous tirerez les cheveux quelque temps...

Deux raisons pour lesquelles pareille situation peut vous arriver:
 . la plage IP distante fait partie intégrante d'un LAN plus large et déjà présent dans ce domaine d'encryption local.
 . vous deviez initialement translater, en source, les requêtes à destination de ce tunnel. Vous aviez donc placé ce LAN dans le domaine d'encryption local du firewall. Puis, changement de programme... plus besoin de NAT... vous reprenez l'objet, lui attribuez la plage IP cible, modifiez l'objet 'Interoparable device' afin de luis attribuer ce nouveau domaine d'encryption distant... mais qui reste placé dans votre domaine d'encryption local :(

Pour le troisième cas: en fonction du sens des requêtes, Check Point et l'autre équipement d'extrémité VPN vont négocier l'établissement du tunnel VPN différemment.
Il faut savoir que Check Point va agréger les routes (cf. Agrégation des adresses) de son domaine d'encryption local.
En prenant l'exemple plus haut, côté client, le domaine d'encryption local contient également la plage IP 10.0.1.0/24 et 10.0.2.0/24 mais les requêtes ne concernent qu'un poste appartenant à 10.0.0.0/24. La passerelle VPN du client est un Check Point.
Côté prestataire, on ne change rien à propos de son domaine d'encryption local, et sa passerelle VPN est le produit d'un autre fabriquant.

Lorsqu'une requête est à l'initiative du client, le domaine d'encryption local négocié côté Check Point est la plage IP 10.0.0.0/24.
Par contre, lorsqu'une requête va être émise côté prestataire, ce domaine  d'encryption négocié sera le fruit de cette agrégation de plage IP: 10.0.0.0/22. Pour que le tunnel fonctionne correctement, il faudra donc demander au prestataire de configurer son domaine d'encryption distant avec cette dernière plage IP.

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 ;)

Sonde SNMP InterMapper pour Check Point / Security Management / OpenServer - version 1.1.1

[For the English version: click here]

Une nouvelle version de ma sonde de supervision pour les Security Management de Check Point installés sur OpenServer.

Cette dernière version est la 1.1.1.
Elle met en avant l'URL de ce blog pour le retour d'expérience des utilisateurs mais surtout corrige un BUG au niveau des entêtes de la sonde.
Les valeurs des variables flags et address_type étaient erronées.
A l'import, le serveur InterMapper n'indiquait pas d'erreur mais n'acceptait pas (plus) de l'utiliser.
J'en ai averti les équipes support de Dartware.


 Date        | Version | Who           | Actions
----------------------------------------------------------------------------------
06 oct. 2011 |  1.1.1  | X. BENSEMHOUN | update information for feedback

             |         |               | + fix flag header
02 sep. 2011 |  1.1    | X. BENSEMHOUN | usage of HOST-RESOURCES-V2-MIB.mib instead of
             |         |               | V1 version (for ondemand table)
01 sep. 2011 |  1.0.1  | X. BENSEMHOUN | complete layout

             |         |               | + 06 oct. 2011 update
22 aug. 2011 |  0.1    | X. BENSEMHOUN | Creation, first functions



Je vous propose l'accès à cette version ainsi qu'aux version antérieures:
. known good_v1.1.1
. known good_v1.0.1 *

*: Comme il s'agit d'un correctif de bug... je l'ai également appliqué à la version antérieure en la déclinant en 1.0.1.


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

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

[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.4.1.
Elle met en avant l'URL de ce blog pour le retour d'expérience des utilisateurs mais surtout corrige un BUG au niveau des entêtes de la sonde.
Les valeurs des variables flags et address_type étaient erronées.
A l'import, le serveur InterMapper n'indiquait pas d'erreur mais n'acceptait pas (plus) de l'utiliser.
J'en ai averti les équipes support de Dartware.

 

  Date        | Version | Who           | Actions                
----------------------------------------------------------------------------------

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 version antérieures:
 . known good_v1.4.1
 . known good_v1.2.1 *
 . known good_v1.1.1 *
 . known good_v1.0.1 *

*: Comme il s'agit d'un correctif de bug... je l'ai également appliqué aux versions antérieures en les déclinant en vX.Y.1.


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

mercredi 5 octobre 2011

Check Point et les règles de sécurité sur la base d'objects 'domain' faisant référence à des FQDN

Avec Check Point, vous allez être capable d'établir des règles de sécurité sur la base d'objets 'domain' faisant référence à des FQDN ou des noms de domaines dont un ou plusieurs domaines de niveau inférieur ont été omis.

Tout d'abord, que dit le support Check Point à ce sujet:
 1) Cela est déconseillé
 2) Si (toutefois) vous en avez besoin (alors qu'on le déconseille), placez ces règles en dernier
 3) Faites attention (;))

Pourquoi ? C'est très simple: les requêtes des utilisateurs qui vont transiter au travers du firewall sous forme de trames ne contiennent pas des FQDN mais des adresses IP.

Le firewall va alors tenter de faire correspondre la requête (@IP source/@IP destination/port destination) à chacune de ses règles de sécurité.
Arrivé à celle(s) contenant ces objets 'domain', le firewall va devoir interroger le DNS pour une résolution inverse lui permettant de traduire l'@IP concernée en un nom FQDN.
=> si le FQDN obtenu correspond à l'objet 'domain', la règle est validée.
=> dans le cas contraire: l'interrogation DNS aura été inutile et le firewall va alors tenter de faire correspondre la requête avec les règles suivantes.

Vous vous douter bien que:
 . Le firewall voit passer énormément de requêtes par seconde...
 . Il est impératif que les DNS soient 'proches' des firewalls
 . Le firewall est à présent dépendant d'un service externe qui peut ne pas être géré par les mêmes équipes qui gèrent le firewall.

Alors bien sûr, le firewall va emmagasiner les résultats des précédentes requêtes DNS.
Mais bon:
 . S'il est prévu une maintenance des serveurs DNS, n'oubliez pas de désactiver les règles de sécurité contenant des objets 'domain'
 . Regroupez ces règles de sécurité dans un label clairement identifié
 . Éliminez un maximum de flux auparavant

samedi 1 octobre 2011

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

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.

MAJ/Upgrade InterMapper, IM DataCenter, IM Flows

La montée en version supérieure d'InterMapper est assez simple.
Vous devez toutefois vous assurer de certaines choses.

Tout d'abord, petit rappel:
 . L'ensemble des données (MAPs, Probes, Charts, logs, conf, ...) d'InterMapper se trouvent dans le répertoire "InterMapper Settings"
 . Les données *Flow issues de InterMapper Flows se trouvent dans le répertoire "ns2flows"
 . Les données d'InterMapper Datacenter sont quant à elles dans le répertoire "imdc"

L'ensemble de ces répertoires auront la même structure, que vous ayez installé ces 'modules' de la suite InterMapper sur MS Windows, GNU/Linux, MAC et autres.

J'évoquerai dans un prochain billet, mes quelques trucs pour nettoyer de temps-en-temps le répertoire InterMapper Settings.


Pour procéder à la montée de version d'un ou de l'ensemble de ces modules, vous devez procéder ainsi:
 . Sauvegarde (à froid, ie: après arrêt de l'appli) de ces répertoires, ce seront alors les données à version 'n'
 . Sauvegarde ou récupération sur le serveur de l'éditeur de votre version actuelle des logiciels (version 'n')
 . MAJ du ou des logiciels (je ne l'ai pas abordé mais: autant rester en même version sur IM et IM DC) en version 'n+1'

Pour un retour arrière (c'est parfaitement fonctionnel, je l'ai essayé ;) ), vous aurez tout simplement à désinstaller cette version 'n+1', installer à nouveau la version 'n' et remplacer les répertoires en 'n+1' par leurs version 'n'.


A propos du client InterMapper RemoteAccess: pour ne pas avoir de problème dans l'édition des MAPs ou si vous devez modifier la configuration du serveur InterMapper, je vous conseille d'avoir votre client IM RA en version identique ou supérieure à celle de votre serveur IM.