CSNE v4 Livre de Formation Labs Virtuels 2020-02-10

SOLUTIONS UNIFIED THREAT MANAGEMENT ET NEXT-GENERATION FIREWALLS
FORMATION EXPERT
STORMSHIELD
NETWORK
SECURITY
NETWORK SECURITY I ENDPOINT SECURITY I DATA SECURITY

2
Prévention d'intrusion 7
Introduction 8
Le moteur de prévention d’intrusion Stormshield Network 11
L’analyse protocolaire IP 14
L’analyse protocolaire sur la couche transport 25
L’analyse applicative 49
L’analyse contextuelle 66
Les profils protocolaires et applicatifs 72
Stormshield Network Vulnerability Manager 84
Les modes d’inspection 90
Infrastructure à clés publiques 99
Qu’est-ce que la cryptographie ? 100
Les types de chiffrement 102
Infrastructures à clés publiques 112
PKI Stormshield Network 117
Création d’une autorité de certification 124
Création d’une identité serveur 129
Création d’une identitité utilisateur 135
Gestion des identités et certificats 143
Révocation de certificats et CRL 146
Proxy SSL 152
Fonctionnement 153
Configuration 159
Exemples d’utilisation 173
VPN IPSec avancé 178
Rappels 179
NAT- Traversal 183
Dead Peer Detection (DPD) Liveliness 186
Étoile / chainage 194
NAT dans IPsec 198
Site à site avec certificats issus de plusieurs autorités 201
Site à site avec certificats issus d'une seule autorité 206
Site à site par certificats avec définition du peer id = subject 209
Nomade par certificat 211
Nomade: mode xauth (IKEv1 uniquement) 226
Nomade: mode hybride (IKEv1 uniquement) 229
Nomade: mode config 231
Failover IPSec 235
3
Tunnels GRE et GRETAP 244
Tunnel GRE 245
Tunnel GRETAP 258
Authentification transparente 267
Introduction 268
SPNEGO 271
Certificat SSL 279
Agent SSO (single sign-on) 285
Multi-utilisateurs 291
Haute Disponibilité 296
Principe de fonctionnement 297
Créer un Cluster 306
Rejoindre un Cluster 309
Les Menus « haute disponibilité » 312
La supervision de la haute disponibilité 318
4
Labs 321
Schéma d'architecture 323
Installation et préparation de la plateforme virtuelle 326
LAB 1: Bases de configuration 329
LAB 2: Suivi stateful en environnement routé 330
LAB 3: Configuration des objets et de la politique de NAT 332
LAB 4: Evènement de protocoles applicatifs 333
LAB 5: PKI 336
LAB 6: Proxy SSL 337
LAB 7: VPN IPSec avec certificats 338
LAB 8: Tunnels GRE et GRETAP 340
LAB 9: Authentification transparente par certificat 341
LAB 10: Haute disponibilité 342
Labs - Corrigés 343

LAB 1: Bases de configuration 345
LAB 2: Suivi stateful en environnement routé 346
LAB 3: Configuration des objets et de la politique de NAT 348
LAB 4: Evènement de protocoles applicatifs 349
LAB 5: PKI 352
LAB 6: Proxy SSL 353
LAB 7: VPN IPSec avec certificats 356
LAB 8: Tunnels GRE et GRETAP 360
LAB 9: Authentification transparente par certificat 362
LAB 10: Haute disponibilité 364
Les images de ce document ne sont pas contractuelles, l'aspect des produits présentés
peut éventuellement varier.
5 Copyright © Stormshield 10/02/2019

6
PRÉVENTION
D’INTRUSION
CSNE - STORMSHIELD NETWORK SECURITY - VERSION 4.X
Programme de la formation
➔ Prévention d’i t usio

Infrastructure à clés publiques
Proxy SSL
VPN IPsec avancé
Tunnels GRE et GRETAP
Authentification transparente
Haute disponibilité
7
Prévention d'intrusion
INTRODUCTION
FIREWALL, FILTRAGE, STATEFUL ET
PRÉVENTION D’INTRUSION
Programme du module
➔ Introduction
Le moteur de prévention d’intrusion Stormshield Network
L’analyse protocolaire IP
L’analyse protocolaire sur la couche transport
L’analyse applicative
L’analyse contextuelle
Les profils protocolaires et applicatifs
Stormshield Network Vulnerability Manager
Les modes d’inspection
8
Qu’est-ce u’u « Firewall » et que peut-on en attendre ?

Le minimum exigible d’u équipement « Firewall » est u’il permette de réglementer
les droits de passage de connexions entre des correspondants, évidemment situés
dans des zones physiques séparées par l’ uipe e t « Firewall ».
Cette fonction de filtrage des flux doit s’appli ue selon une politique définie en
conformité avec une « matrice de flux », elle-même établie en fonction des besoins
des hôtes à communiquer sur divers services et protocoles.
Comme illustré lors du LAB Filtrage de la formation CSNA, l’Ad i ist ateu
s’atta he a à décrire les flux par les critères visibles sur le premier paquet de la
communication.
Selon les paramètres usuels d’u e règle de filtrage, les critères inspectés seraient
couramment :
• l’ad esse IP source du client initiateur de la communication
• l’ad esse IP de destination du serveur sollicité
• le protocole et le port de destination sur lequel le service ciblé est accessible
Ce qui pourrait être représenté schématiquement par un taux de couverture des
couches protocolaires :
Ci-dessous, un exemple de trame commune appartenant à une communication HTTP
:
couvert par le filtrage non couvert par le filtrage
9
COUCHES PROTOCOLAIRES
Ci-dessous la représentation de la couverture des couches IP (RFC 791) et TCP (RFC
793) par les critères usuels de filtrage
En-tête IPv4
couvert par le filtrage
non couvert par le filtrage

En-tête TCP
Filtrage et suivi de connexion

Si l’o regarde un extrait schématisé d’u e communication TCP/IP entre un client a
initiant une connexion à partir d’u port source pa vers un serveur b offrant un
service sur le port pb:
@IPa pa @IPb pb
pa @IPa pb @IPb
Il apparaît clairement que les critères [ IP source | port source ] et [ IP destination |

port destination ] présents dans les paquets TCP/IP alternent tout au long du
dialogue. Ceci met en évidence les limites d’u moteur de filtrage basique qui
s’appuie ait strictement sur la description des paquets et pointe alors la nécessité
d’u mécanisme considérant l’e se le de ces paquets comme faisant partie d’u e
seule connexion, afin notamment de traiter les paquets réponses automatiquement,
alors même que la règle de filtrage pour autoriser ce flux ne décrira que
l’ ta lisse e t du dialogue, en prenant comme critères ceux du premier paquet de
communication.
Ce mécanisme est couramment appelé « stateful » ou encore « S.P.I. : stateful packet
inspection », mais pour une communication TCP, peut-on véritablement considérer
u’u e simple gestion automatique des paquets réponse suffit à prétendre
appliquer une « inspection à suivi de plein état » ?
Une rapide revue des contenus des en-têtes IP et TCP suffit à prendre conscience
u’u mécanisme de type « Stateful » doit intégrer des contrôles bien plus complets
et complexes, ainsi que des vérifications en amont et d’aut es traitements en
complément.
10
LE MOTEUR DE
STORMSHIELD NETWORK
Programme du module
✔ Introduction
➔ Le moteur de prévention d’intrusion Stormshield Network
L’analyse protocolaire IP
11
PRÉVENTION D’INTRUSION : TRAITEMENTS IPS
Signatures contextuelles
Prévention Plugins
d’intrusion
IPS
TCP, UDP, ICMP
Fragmentation
Analyse IP
Analyses IPv4, IPv6
Le moteur de prévention d’i t usio Stormshield Network

Tous les modèles Stormshield Network Security intègrent la même technologie
propriétaire de prévention d’i t usio en temps réel : l’A tive Security Qualification
(ou ASQ).
Intégré à la pile réseau du système d’exploitatio FreeBSD, le moteur de prévention
d’i t usio de SNS dispose d’u accès privilégié aux ressources matérielles (CPU,
mémoire et carte réseau).
Ce système de prévention d’i t usio assure le filtrage des flux ainsi que leur
analyse; dès les couches de transport et jus u’aux couches applicatives, il applique
des contrôles génériques de conformité, ainsi que des contrôles ciblés et
comportementaux. Les opérations de NAT ainsi que certaines opérations de routage
spécifique sont également prises en charge par ce moteur.
Ces analyses sont appliquées directement sur les connexions cherchant à traverser la
pile réseau du système.
Le système de prévention d’i t usio détecte et bloque les tentatives d’atta ues des
applicatifs grâce à des analyses contextuelles et comportementales complétées par
une identification par signatures. Cette association présente deux bénéfices
majeurs :
• Il permet de réaliser un traitement préventif sur toutes les couches de
communication (du réseau à l’appli atio fournissant ainsi une réelle protection
0-day,
12
• L’usage des contextes applicatifs limite le nombre de signatures à examiner et

réduit ainsi les risques de faux positifs tout en optimisant les temps de
traitements pour procurer des performances optimales.
Les signatures utilisées par le moteur de prévention d’i t usio SNS sont
construites pour détecter des attaques identifiables mais également leurs
variantes potentielles. À titre d’exe ple, la signature contextuelle sur une
injection SQL par une commande SELECT (http:url:decoded:95) permet de
contrer plus de 1 540 variantes d’atta ues. En plus de maintenir un espace de
stockage contenu, cette technique permet d’opti ise les temps de traitement
et propose une protection contre de futures attaques basées sur les mêmes
principes.
La mise à jour des bases de signatures du moteur de prévention Stormshield

Network Security est assurée indépendamment de la mise à jour du firmware
pour garantir une actualisation périodique et automatique afin de rester
constamment protégé contre les nouvelles attaques.
Cette fonctionnalité de mise à jour automatique se nomme « Active Update » ;
elle permet également d’ajoute de nouveaux contextes pour intégrer nouvelles
catégories de signatures contextuelles.
Les différents types d’a al ses

Au-delà du simple classement [niveau réseau][niveau applicatif], un firewall
Stormshield Network s’atta he à protéger votre réseau selon trois familles
d’a al ses :
• l’a al se protocolaire : elle assure la conformité des flux réseau vis-à-vis des
standards de communication (IP, TCP, UDP, ...) ainsi que la conformité aux
protocoles applicatifs (HTTP, FTP, …) grâce aux contrôles appliqués par les
contextes applicatifs,
• l’a al se statistique : basée sur des études statistiques du trafic transitant par
le firewall, cette analyse détecte des comportements assimilables à du scan
de ports, à du SYN flooding, ou encore à des tentatives de DoS (Denial of
Service) par maintien de multiples connexions annonçant des petites fenêtres
(SockStress),
• l’a al se par signatures contextuelles : elle vient compléter les contrôles de
conformité sur le trafic. Cette analyse permet de se protéger de tentatives
d’atta ues visant spécifiquement un protocole et une implémentation cliente
ou serveur, mais sans toutefois recourir à une inconformité au standard de
communication. Elle s’appuie sur des bases de signatures construites par nos
soins, maintenues quotidiennement et mises à disposition sur nos serveurs
Active Update.
13
L’ANALYSE
PROTOCOLAIRE IP
Programme du module
✔ Introduction
✔ Le moteur de prévention d’intrusion Stormshield Network
➔ L’analyse protocolaire IP
14
PRÉVENTION D’INTRUSION : ANALYSES IP
Plugins
TCP, UDP, ICMP
Fragmentation
Analyses
Analyses IPv4, IPv6
IP
L’a al se protocolaire IP
• Les analyses de conformité du protocole IP
• Contrôle de légitimité des sources (anti usurpation)
• La mise en quarantaine de machines ou de connexions
• La fragmentation IP
• Les attaques par fragmentation IP
15
• Vérifications sur le protocole IP
Analyses IPv4, IPv6

Version et options du protocole IP
Tailles de l’en-tête et du paquet
Conformité
Somme de contrôle IPv4
Taille, type et chaînage des extensions IPv6
10
Les analyses de conformité du protocole IP

Le moteur de prévention d’i t usio Stormshield Network démarre ses contrôles
à la couche réseau IP :
• Vérifie le numéro de version du protocole IP et la conformité des options
positionnées,
• Vérifie si la taille annoncée dans l’e -tête IPv4 est conforme à la taille effective
de la charge,
• Compare la valeur de la somme de contrôle (checksum) annoncée dans l’e -
tête du paquet IPv4 avec la valeur de cette somme u’il a recalculée,
• Vérifie l’utilisatio conforme des extensions IPv6 (taille, type et ordre de
chaînage des extensions IPv6).
16
• Vérifications sur la légitimité de l’adresse IP source
Analyses IPv4, IPv6

Type 1 = Adresse IP source étrangère et inconnue
(sur une interface interne)
Anti usurpation Type 2 = Adresse IP source incohérente avec la configuration

des interfaces et le routage statique (sur une interface externe)
Type 3 = Adresse IP appartenant au firewall
11
Protection contre l’usu patio d’ad esse

Le mécanisme de protection contre l’usu patio d’ad esse (anti-spoofing) permet de
détecter une incohérence entre l’ad esse IP source du paquet reçu et l’i te fa e
réseau sur laquelle il se présente. On distingue 3 types d’usu patio d’ad esse :
• Type 1 : Une interface protégée reçoit un paquet en provenance d’u e adresse IP
qui ’appa tie t pas à l’u des réseaux protégés associés à l’i te fa e (réseau
directement connecté ou route statique appliquée à l'interface).
• Type 2 : Une interface non protégée reçoit un paquet en provenance d’u e
adresse IP appartenant à un réseau protégé lié à une autre interface.
• Type 3 : une interface, u’elle soit protégée ou non, reçoit un paquet dont
l’ad esse IP source est portée par l'une des interfaces du firewall.
Réseaux Protégés (internes)

Un réseau est dit « Protégé » lo s u’il est directement connecté à une interface
interne ou lo s u’il est joignable par une route statique dont le routeur est connecté
à une interface interne.
Ces réseaux héritent du caractère protégé de l’i te fa e interne à laquelle ils sont
liés.
Ces réseaux font tous implicitement partie du groupe de réseaux décrit par l’o jet
« Network_internals ».
17
• Application de la quarantaine (liste noire)
Analyses IPv4, IPv6

Confrontation des correspondants (couple d’IP)
Liste blanche
aux entrées de :
la liste noire ET / OU la liste blanche

Liste noire
• Application de la liste blanche
12
Inscription en quarantaine
Les entrées de la quarantaine (liste noire) permettent de bannir toute
communication, de manière bidirectionnelle, entre deux entités IP (hôte avec hôte,
hôte avec réseau, réseau avec réseau et même hôte ou réseau avec « Any »).
En cas d’utilisatio de cette fonctionnalité, il est prudent d’i s i e en liste
d’Ex lusio de quarantaine les machines sensibles afin de les protéger d’u e
éventuelle mise en quarantaine dynamique détaillée page suivante.
Cette liste [BlackListExclude] ’est accessible u’e mode CLI (voir article KB).
Liste noire statique

Il est possible, en CLI, de créer des entrées statiques dans la liste de quarantaine pour
bannir toute communication traversante entre des entités IP à définir par les objets
leur correspondant. (voir article KB).
Liste blanche
Une liste blanche (WhiteList ou ByPass ASQ), à définir en CLI, permet de contourner
les contrôles ASQ pour toute communication entre les couples d’o jets déclarés.
ATTENTION : contourner l’ASQ signifie également contourner la politique de filtrage
et les opérations de NAT, ainsi que les routage assuré par le moteur IPS (PBR et LB) !
La Liste Noire est prioritaire sur la Liste Blanche.
18
Mise en quarantaine dynamique

La mise en quarantaine se paramètre comme une action additionnelle à l’action « Interdire »
d’un évènement.
13
Liste noire dynamique

Le moteur de prévention d’i t usio Stormshield Network Security permet de placer
des machines en quarantaine afin que leurs trafics soient bloqués.
Depuis le menu de configuration des alarmes dans le module « Protection
applicative », il est possible d’ajoute une réaction supplémentaire sur réalisation
d’u évènement. Ainsi, toute machine déclenchant cet évènement est
immédiatement placée en quarantaine pour la durée choisie.
La mise en quarantaine dynamique ’est effective que pour une durée limitée
choisie à l’ava e.
19
• Vérification de la fragmentation
Un paquet IP doit être fragmenté par le firewall si sa taille excède la taille limite
fixée par le paramètre MTU de l’interface de sortie
Fragmentation
Fragment 1
Paquet original
Fragment 2
Un paquet IP reçu fragmenté doit être réassemblé pour analyse
Fragmentation
Fragment 1 Reconstruction du paquet
Analyse
Fragment 2
Émission selon la MTU de l’interface de
sortie
14
La fragmentation IP
La taille maximale d’u paquet IP est définie par la valeur du paramètre MTU. Il s’agit
d’u paramètre IP qui permet d’adapte la taille des paquets IP aux capacités de
transport de la couche physique (Ethernet, PPPoE, …) ou à l’utilisatio de liens
spécifiques requérant l’ajout d’e -têtes (VPN IPSec avec l'ajout d'un en-tête ESP).
Lo s u’u paquet IP est émis, sa taille est généralement calculée en fonction de la

taille maximale des trames que peut transmettre l’i te fa e de sortie. Son
acheminement jus u’à destination peut utiliser des liens ayant une capacité de
transmission inférieure. Dans ces conditions, le contenu du paquet IP est découpé
(fragmenté) par les routeurs de transit dont la MTU serait inférieure.
En IPv4, la fragmentation d’u paquet est interdite lorsque le bit DF’ est positionné
dans l’e -tête IP.
En IPv6, la fragmentation par un équipement intermédiaire est interdite.
La MTU minimale obligatoire en IPv4 est fixée à 576 octets.

La MTU minimale obligatoire en IPv6 est fixée à 1280 octets.
La MTU généralement en vigueur sur un réseau ethernet est de 1500 octets.
20
• Exemple de fragmentation : un paquet IP de 1500 octets et une

MTU de 620
20 octets 1480 octets
IP TCP HTTP HTTP

header header header data
600 octets
IP TCP HTTP HTTP

header header header data part 1
600 octets
Offset 0
IP HTTP
header data part 2
280 octets
Offset 600
IP HTTP
Fragment #1 : IP Header (20) + IP DATA 1 (600) = 620 octets
data part
Fragment #2 : IP Header (20) + IP DATA 2 (600) = 620 octets header 3
Fragment #3 : IP Header (20) + IP DATA 3 (280) = 300 octets
Offset 1200
15
Contenu des fragments IP

Comme visible ci-dessus, seul le premier fragment contient les ports (TCP/UDP)
utilisés par la connexion.
E o s ue e, u e a al se f ag e t pa f ag e t ’a pas de se s puis u’elle e
permet pas d’ide tifie les o exio s aux uelles les f ag e ts appa tie e t.
Le paquet original doit donc être réassemblé impérativement pour analyse par le
firewall.
L’optio « offset » détermine la position de chaque portion des données qui ont dû
être fragmentées.
21
Le moteur de prévention d’intrusion Stormshield Network reconstruit

virtuellement les paquets fragmentés.
16
Paramètres de configuration pour la gestion des fragments IP

Les différents fragments d’u même paquet IP d’o igi e sont mémorisés jus u’à
l’a iv e du dernier fragment après lequel le paquet complet est reconstruit.
L’o d e d’a iv e des fragments ’est pas important tant que tous les fragments
parviennent au firewall dans un délai de deux secondes.
Après reconstitution et analyse, le paquet est émis conformément à la MTU de
l’i te fa e de sortie pour le flux en question (la fragmentation initiale ’est pas
répliquée à l’ide ti ue .
22
Les paramètres suivants sont disponibles pour la configuration :
Cette option permet de définir une valeur de MTU (Maximum

Transmission Unit) prépondérante sur les valeurs de MTU des
interfaces. Les paquets IP sont alors dimensionnés selon la plus
Valeur maximale petite MTU entre cette valeur et la valeur MTU de l’i te fa e.
du MTU
Cette option ’est utile que dans le cas où un routeur du réseau
possède une MTU plus faible que la MTU des interfaces du
Firewall et u’il ’i t g e pas de fonction de fragmentation.
Il s’agit de la taille minimale, en octets, du plus petit fragment
intermédiaire acceptable par le moteur de prévention
d’i t usio Stormshield Network. Tout fragment ayant une
Taille i . d’u taille inférieure à cette valeur est rejeté, à l’ex eptio du
fragment dernier fragment.
La valeur par défaut de ce paramètre est fixée à 140 octets.
La valeur minimale de ce paramètre serait 28 octets (inclut
l’e -tête IP)
Temps maximal, exprimé en secondes, durant lequel le moteur
de prévention d’i t usio Stormshield Network Security
conserve les fragments pour reconstituer le paquet original.
E pi atio d’u e
Au-delà de cette limite, tous les fragments du paquet sont
session
détruits.
Le temps par défaut est de 2 secondes.
23
• Exemple d’attaque par fragmentation

IP
header Men
IP Fragment #1
header Menace
IP
Paquet original
header ace
Fragment #2
• Exemples d’attaque par recouvrement

IP Paquet original IP
header Menace Taille = 1500
header Menace
1000 octets 1000 octets
IP IP
header Men header Men bourrage
Fragment #1 Fragment #1
Offset 0 600 octets Offset 0 600 octets
IP IP
header bourrage ace header ace
Fragment #2 Fragment #2
Offset 900 Offset 900 18
Attaque par fragmentation IP

Le mécanisme de fragmentation IP peut être utilisé intentionnellement pour
véhiculer des attaques : la menace est répartie sur plusieurs fragments.
Le vecteur d’atta ue est découpé puis inséré dans des fragments consécutifs. Ainsi,
l’a al se unitaire des fragments ne révèle pas l’atta ue. Ce ’est u’au moment du
réassemblage des fragments que la menace est reconstituée.
Attaque par recouvrement

L’atta ue par recouvrement détourne l’usage de l’optio « offset ». Le principe étant
de définir pour deux fragments consécutifs des valeurs d’offset qui se chevauchent.
Ce mécanisme de chevauchement ’ ta t pas standardisé, car non conforme,
l’a eptatio et la reconstitution du paquet dépend du comportement de
l’i pl e tatio de la pile IP destinataire.
• Premier cas : si la pile IP destinataire place le 2nd fragment à l’offset indiqué,
l’atta ua t ayant forgé un second fragment contenant 100 octets de bourrage en
début de fragment, le 1er fragment écrase le début du 2nd fragment et l’atta ue
est reconstituée.
• Second cas : l’atta ua t a inversé la place du bourrage (en fin de premier
fragment) et la seconde partie de la menace pour parvenir à ses fins, parce que le
second fragment écrase la fin du premier fragment dans l’i pl e tatio de la
pile IP destinataire.
Dans tous les cas, le moteur de prévention d’i t usio Stormshield Network bloque
le chevauchement de fragments IP.
24
L’ANALYSE PROTOCOLAIRE
SUR LA COUCHE
TRANSPORT
Programme du module
✔ Introduction
✔ L’analyse protocolaire IP
➔ L’analyse protocolaire sur la couche transport
25
PRÉVENTION D’INTRUSION : ANALYSES D’ÉTAT / FILTRAGE
Plugins
TCP, UDP, ICMP

Analyses TCP,
UDP, ICMP
Fragmentation
Analyses IPv4, IPv6
20

• Suivi des sessions, filtrage et profils applicatifs
• Le séquençage des segments TCP
• L’optio MSS TCP
• Le proxy SYN
• Les seuils de connexions
• Les paramètres de configuration des protocoles TCP, UDP, ICMP
• Les connexions virtuelles du moteur de prévention d’i t usio Stormshield
Network
26
• Suivi des sessions (Stateful)
TCP,UDP,ICMP
Table des connexions pour le suivi de leurs états
Suivi des sessions Gestion automatique des paquets réponses
Suivi des flags, des options et du séquençage TCP
Liens entre messages ICMP et connexions en cours
21
Firewall stateful
La conservation de l’ tat des sessions permet de contrôler leur conformité aux
standards de communication au fil de leurs évolutions et pendant toute leur durée
de vie. On parle de suivi « stateful » ou « plein état ». Les mécanismes et contrôles
de suivi stateful permettent, non seulement, de gérer automatiquement les paquets
réponses à destination de l’i itiateu de la connexion, mais ils préviennent
également les tentatives d’atta ues par injection de paquets, en vérifiant que le
contenu de chaque paquet est cohérent avec l’ tat de la session en cours.
État des connexions

Le moteur de prévention d’i t usio Stormshield Network applique des contrôles
particuliers aux différentes étapes d’ ta lisse e t, de transport de données et de
clôture des connexions TCP :
• Les flags TCP d’ ta lisse e t produisent des états c_syn (Client SYN), puis s_syn
(Server SYN+ACK)
27
• À l ’issue du handshake TCP, la connexion passe en état data; dès lors, les
valeurs minimales et maximales des numéros de séquences des segments
TCP sont alors contrôlées et comparées avec les quantités de données
émises et acquittées, ainsi que les fenêtres TCP annoncées. La conformité
des flags TCP à l’ tat en cours est contrôlée tout au long de la connexion.
Les options TCP positionnées sont également contrôlées, puisque
certaines ne sont utilisables u’à certains moments de la connexion.
• Les flags de clôture provoquent également des changements d’ tat de la
connexion (close sur réception d’u FIN puis closed après le dernier ACK)
Les contrôles sur ICMP consistent, quant à eux, principalement à l’ide tifi atio de
session TCP/UDP en rapport avec les messages ICMP retournés. Les réponses ICMP
(echo reply) sont également corrélées aux requêtes (echo request) en attente
conservées dans la table de stateful.
Quoique bien plus basique, le protocole UDP est également traité par plusieurs états
(open ou data) pour rendre compte d’u trafic unidirectionnel ou bidirectionnel,
dans le cas d’u dialogue.
Le checksum UDP (facultatif) est vérifié lo s u’il est positionné.
Lors d’u redémarrage, une copie de la table des connexions est écrite sur le disque
dur afin que son contenu, une fois restauré, permette de continuer le suivi des
connexions après que le système ait redémarré; les connexions les moins sensibles à
une inactivité pourront alors se poursuivre.
Pour les connexions TCP, le moteur de prévention d’i t usio Stormshield Network
offre un système de réécriture des numéros de séquence avec un aléa fort. Cette
fonctionnalité permet de compenser les lacunes de certains systèmes d’exploitatio
utilisant un générateur de numéros de séquence initiaux à faible aléa. Si cette option
est activée, les numéros de séquences initiaux seront remplacés par un numéro
généré avec un niveau d’al a bien plus élevé, basé sur l’algo ith e ARC4.
Cette fonctionnalité ’est pas activée par défaut.
Elle est applicable par profil d’i spe tio .
Elle est incompatible avec le suivi de connexion en mode d’i spe tio « firewall ».
28
• Confrontation aux règles de filtrage
TCP,UDP,ICMP
Parcours des règles selon leur ordonnancement strict
Règles de filtrage
Application de l’action de la première règle qui coïncide
23
Règles de filtrage
Toute nouvelle connexion est évaluée par le moteur de filtrage Stormshield Network.
Dès u’u e règle passante de filtrage correspond à la tentative de connexion, cette
dernière est autorisée et le moteur de prévention d’i t usio crée un état
permettant de démarrer le suivi de la connexion. Toute connexion qui ’est pas
explicitement autorisée par une règle de filtrage sera bloquée implicitement sans
u’il ne soit besoin de terminer la politique de filtrage par une règle de blocage et,
par défaut, sans remontée de log.
29
• Sélection du type d’inspection et des profils applicatifs
Profil d’inspection par défaut ou profil désigné

TCP,UDP,ICMP
Profil applicatif
Présélection du plugin applicatif
(pour les analyses suivantes)
24
Profils applicatifs
Chaque règle de filtrage est associée à un profil d’i spe tio . Il est possible de choisir
le profil d’i spe tio à utiliser pour chaque règle tel que décrit ci-dessous:
• Lo s u’au u profil ’est sélectionné, ce sont les profils d’i spe tio par défaut
qui sont utilisés.
o Le profil ENTRANT par défaut (00) s’appli ue a aux connexions provenant
d’u e adresse IP source non protégée (ou non interne),
o Le profil SORTANT par défaut (01) s’appli ue a aux connexions provenant
d’u e adresse IP source incluse dans les réseaux protégés (réseaux
internes).
• Sélection d’u profil d’i spe tio particulier qui sera utilisé pour cette règle (il
existe 8 profils d’i spe tio pouvant être utilisés à la place des profils par défaut
et dont les paramètres sont personnalisables).
• Sélection du mode IDS pour lequel le trafic correspondant à cette règle sera
inspecté sans blocage mais émettra des alarmes en cas de trafic malveillant.
• Sélection du mode Firewall pour ’appli ue aucun contrôle de conformité et ne
mettre en œuv e u’u e gestion basique du suivi d’ tat (gestion primaire
d’ouve tu e et de fermeture de connexion, mais pas de contrôle de conformité
des options ou des numéros de séquence).
30
LE SÉQUENÇAGE DES SEGMENTS TCP
• Vérification du séquençage des segments TCP
Client Serveur
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 SYN
Port source Port destination Séquence = C
Numéro de séquence
Nu o d’ac uitte e t Séquence = S SYN-ACK
Fenêtre Acquittement = C+1
Taille en-tête Réservé URG ACK PSH RST SYN FIN
Somme de contrôle Poi teu d’u ge ce
Options Remplissage Séquence = C+1
ACK
Acquittement = S+1
Données
Données
Séquence = C+1
Acquittement = S+1
• Attaques possibles sur le séquençage Réponse
• Prédiction du système d’exploitation Séquence = S+1

Acquittement = C+1+size
• Vol de session TCP (session hijacking) Suite
Séquence = C+1+size
Acquittement = S+1+size
25
Le séquençage des segments TCP

Le protocole TCP intègre plusieurs mécanismes pour fiabiliser la transmission des
segments de données.
Le principe de base repose sur l’utilisatio conjointe d’u numéro de séquence et

d’u numéro d’a uitte e t présents dans tous les paquets (à quelques exceptions
près) :
• Le numéro de séquence indique au destinataire la position du premier octet de
données du segment en cours dans le flux de données TCP.
• Le numéro d’ac uitte e t annonce le numéro de séquence (numéro d’o tet que
le répondant est prêt à recevoir. L’a o e de ce numéro indique implicitement
que tous les octets précédents (et donc les numéros de séquence précédents) ont
bien été reçus.
Un numéro de séquence initial est fixé aléatoirement par chacun des

correspondants et positionné dans chacun des premiers paquets de
« SYNchronisation » à l’ ta lisse e t de la connexion. Il peut prendre ’i po te
quelle valeur codée sur 32 bits. Pour la suite de l’ ha ge de données, la valeur du
numéro de séquence est incrémentée de la taille de données transmises dans le
segment TCP précédent.
31
A chaque octet transporté, TCP affecte « virtuellement » un numéro de

séquence; le numéro de séquence écrit dans l’e -tête TCP est celui du premier
octet des données transportées par le segment TCP.
Ce mécanisme de séquençage TCP, en numérotant les octets de données
transportés, permet non seulement d’assu e leur ordonnancement avant
présentation à la couche applicative située au dessus de TCP, mais également,
grâce aux acquittements, de gérer les retransmissions de données
éventuellement manquantes, par exemple à cause de pertes de paquets.
Le « marquage » de chaque segment TCP par un numéro de séquence et un
numéro d’a uitte e t permet aux deux correspondants de connaître
précisément, à tout instant de la communication, la quantité d’o tets de
données u’ils ont chacun émise et reçue.
Les attaques utilisant le numéro de séquence TCP

Une des faiblesses potentielles du séquençage des segments TCP réside dans le
choix du numéro initial à chaque établissement de session. L’usage d’u e valeur
identique ou séquentielle, et donc prévisible, pour toutes les connexions,
rendrait possible :
• La détermination du système d’e ploitatio : certaines implémentations du

protocole TCP, utilisent toujours la même valeur. En, connaissant ce système
d’exploitatio , l’atta ua t pourrait mieux cibler ses attaques sur les failles
connues de ce système (failles protocolaires et applicatives).
• Le vol de session : à partir de la valeur du numéro de séquence initial,

l’atta ua t pourrait prédire les numéros de séquence des prochaines
connexions ce qui lui permettrait de préparer des paquets forgés qui
pourraient y être injectés pour tenter de les voler, de les clôturer ou d’ placer
des données illégitimes.
32
L’OPTION TCP MSS
Couche applicative
Applicative DATA 1460 octets
TCP Couche transport

header
IP TCP Couche réseau

header header
Ajout en-tête PPPoe
1508 octets
Taille de trame
ethernet IP TCP C 802.3 inadaptée
header Applicative DATA R 1518 octets
header header C
Hôte du réseau Routeur PPPoE
27
L’optio TCP MSS
Cas d’usage de l’optio MSS (Maximum Segment Size)

À titre d’exe ple, nous considérons une taille standard de paquet IP à 1500 octets
sur un réseau physique ethernet. La configuration réseau fait intervenir en sortie une
connexion PPPoE qui, à cause de la capacité de transport du matériel réseau, limitée
à une taille de trame de 1518 octets (FCS/CRC ethernet inclus), impose une taille de
MTU à 1492 octets (1518 octets moins les 14 octets de l’e -tête ethernet, les 4
octets de FCS/CRC ethernet et les 8 octets d’e -tête du protocole PPPoE).
La présence de MTU différentes sur un chemin favorise la fragmentation lorsque la
MTU de l’ etteu est supérieure aux MTU des équipements chargés de
l’a he i e e t des paquets.
L’optio TCP MSS est abordée dans la RFC 793 et précisée dans les RFC 879, 1122 et
6691.
Elle permet aux deux correspondants d’a o e la taille maximale des segments
TCP (charge utile TCP, hors en-tête) u’ils sont capables de réceptionner et de traiter.
Elle ne peut être annoncée que pendant le handshake TCP (SYN et SYN+ACK), chacun
des deux correspondants dimensionnant ses émissions en conformité avec la limite
annoncée par le correspondant d’e face.
33
Un « détournement » de l’utilisatio de cette option peut permettre de limiter

artificiellement les charges TCP échangées dans les deux sens de la connexion et
ainsi obtenir que la taille des paquets IP résultants soit inférieure à une valeur
choisie.
Le moteur de prévention d’i t usio ’auto ise pas, par défaut, une annonce de
MSS de taille inférieure à 100 octets. Une telle annonce est considérée comme
une « attaque par MSS faible » qui force ainsi une taille de segments TCP très
petite et donc oblige à multiplier, dans une proportion conséquente d’u facteur
supérieur à 14), le nombre de segments TCP à envoyer pour transporter une
quantité de données.
Le cas d’usage le plus fréquent de la limitation de la MSS concerne le transport

de paquets au travers d’u tunnel (VPN IPSec ou GRE). En effet, dans ce cas-là, la
surcharge induite par les en-têtes d’e apsulatio peut peser plusieurs dizaines
d’o tets (dans le cas d’ESP et donc oblige l’i te fa e réseau de sortie à
fragmenter les paquets si la charge utile des flux en clair ’est pas maîtrisée par
une limitation de taille.
34
L’OPTION TCP MSS

La limitation automatique de la MSS est paramétrable dans les profils
profil tcpudp_01
Client MSSLimit=1452 Serveur
Syn [mss=1460] Syn [mss=1452]
Syn+Ack [mss=1452] Syn+Ack [mss=1460]
Lorsque les valeurs de MSS annoncées excèdent la limite forcée, la

modification automatique est appliquée.
29
NOTE
La modification automatique de la MSS est appliquée par les analyses TCP du profil
d’i spe tio attaché au flux. Le profil d’a al se TCP contenant ce paramètre est un
composant d’u profil d’i spe tio .
Il faut attacher ce profil d’i spe tio à la règle de filtrage qui décrit l’ ta lisse e t
de connexion dans le sens client-> serveur.
Le suivi stateful de la connexion applique la modification sur le SYN et sur la réponse
SYN+ACK.
Une fois la connexion établie, les segments TCP envoyés par les deux correspondants
sont limités à une taille correspondant à la valeur forcée par la limite MSS, puisque
chacun d’eux « pense » que l’aut e a annoncé une capacité de réception maximum
bornée à cette valeur et u’ils doivent chacun s’ conformer.
Pour le traitement de flux pris en charge par un tunnel VPN IPSec, il est conseillé de
forcer cette valeur à 1300 octets (lorsque le MTU de l’i te fa e réseau est à 1500
octets) afin de s’assu e une marge suffisante pour éviter la fragmentation.
Cette valeur couvre la majorité des cas où la limitation de la charge TCP est
nécessaire.
Il ’est généralement pas souhaitable d’appli ue une telle modification globalement
en la positionnant sur un des profils par défaut.
Un profil particulier attaché à des règles de filtrage spécifiques évite d’i pa te
l’e se le des flux et permet une gestion fine de ce besoin en limitation de la taille
des segments TCP.
35
SEUIL D’ÉTABLISSEMENT DE NOUVELLES CONNEXIONS
Configurer la limitation du nombre d’ ta lisse e t de nouvelles connexions, pseudo-

connexions ou requêtes ICMP par seconde, et visualiser les alarmes associées.
30
Lorsque le seuil est atteint, l’a tio à appliquer est conditionnée par la configuration
de l’ala e associée.
Cette fonction permet effectivement une protection des serveurs, mais en revanche,
’est pas capable de protéger l’a s au service, puisque toute nouvelle tentative de
connexion excédant le seuil est bloquée sans aucun critère de sélection.
36
SEUIL D’ÉTABLISSEMENT DE NOUVELLES CONNEXIONS
Règles associées avec limitations
31
Passer la souris sur le contenu de la colonne Action pour voir les encadrés affichés
ici.
Pour ICMP, cette fonctionnalité ’a de sens et ’est applicable u’aux messages de

type requêtes.
Lorsque le seuil est atteint, l’a tio à appliquer est conditionnée par la configuration
de l’ala e associée.
Cette fonction permet effectivement une protection des serveurs, mais en revanche,
’est pas capable de protéger l’a s au service, puisque toute nouvelle tentative de
connexion excédant le seuil est bloquée sans aucun critère de sélection.
37
LE PROXY SYN
Client Serveur Client Firewall Serveur Client Firewall Serveur

SYN
SYN SYN
spoofed
SYN
SYN-ACK SYN-ACK
SYN
ACK ACK
original spoofed
SYN SYN-ACK
TCP Handshake SYN-ACK

spoofed
ACK
Avec Proxy SYN
SYN-ACK SPOOFING
Configuration
par règle de
filtrage (action):
32
Le proxy SYN
Le moteur de prévention d’i t usio Stormshield Network embarque un proxy SYN
pour protéger les serveurs internes contre les attaques de type SYN-flooding.
Le proxy SYN entre en action à partir d’u certain nombre de tentatives
d’ ta lisse e t de nouvelles connexions par seconde, à définir sous la forme d’u
seuil dans le champ « Action / Qualité de Service » d’u e règle de filtrage.
Il intercepte alors l’ouve tu e de connexion SYN et répond SYN+ACK à la place du
serveur pour vérifier que le handshake est complété. Si le client répond au SYN-ACK,
la demande de connexion est considérée comme légitime. Le proxy SYN rejoue donc
la phase d’ ta lisse e t de connexion avec le serveur en se faisant passer pour le
client.
Remarque :
Le Proxy SYN ’est applicable u’e protection de machines en zone d’ad essage
interne (machines connectées directement ou indirectement aux interfaces
protégées du Firewall).
38
Mise en œuv e
L’a tivatio du proxy SYN Stormshield Network se configure dans le champ
« Action » de la règle de filtrage autorisant les flux entrants à destination d’u
serveur interne, par la définition d’u e limitation en nombre d’ ta lisse e t de
nouvelles connections par seconde. Le proxy SYN ’e t e en action que lorsque
le seuil acceptable de nouvelles connexions est atteint.
La valeur du seuil ne peut pas être positionnée à 0.

Au moment de sa mise en action, pour forger sa réponse SYN+ACK, le proxy SYN
doit connaître des informations sur le serveur protégé qui va être contacté (MSS,
support du SACK, TCP window et TCP Window Scale Factor). Ces informations
sont stockées dans un cache de la table des hôtes protégés. Au moment de
prendre en charge la connexion, le proxy SYN utilise ces informations du cache.
Puis, après avoir répercuté la connexion vers le serveur protégé, il analyse les
options positionnées sur le SYN+ACK pour maintenir à jour les caractéristiques
de la pile TCP de ce serveur dans la table des hôtes protégés.
Si le client annonce qu'il supporte l’optio SACK (Selective ACK) et que le cache
indique que le serveur le supporte, le proxy SYN positionne cette option lorsqu'il
usurpe le SYN+ACK en réponse au client. Lorsque le proxy SYN réplique le SYN du
client à destination du serveur, il respecte les paramètres MSS, TCP window et
window scale initialement annoncés par le client. Il fait de même lors de l'envoi
du ACK vers le serveur. Ainsi ces valeurs seront toujours en adéquation avec
celles utilisées par les deux correspondants.
Le proxy SYN ayant choisi arbitrairement le numéro de séquence initial
positionné dans son SYN+ACK, il est obligé d’assu e le maintien du différentiel
de séquençage entre les réponses u’il envoit au client et les réponses u’il
obtient du serveur interne.
39
PARAMÈTRES DES ANALYSES PROTOCOLAIRES TCP-UDP
34
Les traitements tcp/udp intègrent, depuis les firmwares v2.1, des fonctions
additionnelles de limitation du nombre de connexions basée sur les adresses IP
sources.
Ces fonctions se paramètrent dans le profil des traitements tcp/udp.
Bien u’appa e e t très similaires aux fonctions de limitations du nombre de
nouvelles connexions décrites précédemment, ces mécanismes visent
principalement à fournir de l’équité d’acc s aux services exposés.
Ces traitements peuvent être activés en compléments des fonctions de limitations

abordées précédemment.
L’appli atio des seuils de blocage de ces fonctionnalités ’i te vie e t u’ap s les
évaluations des seuils de nombre de nouvelles connexions par secondes (car ces
dernières sont directement liées au taux de « matching » de la règle de filtrage).
40
PARAMÈTRES DES ANALYSES PROTOCOLAIRES TCP-UDP
35
Les paramètres d’inspections protocolaires TCP-UDP

Les profils de traitements tcp/udp peuvent être renommés pour mettre en évidence leurs
particularités.
La « réinitialisation » restaure les valeurs par défaut de la configuration usine.
Imposer une Cette option permet d’a tive la limitation de la taille des
limite MSS segments TCP (option inactive par défaut)
Limite MSS (en Valeur maximale en octets de l’optio TCP MSS (non
octets) renseignée par défaut)
Réécrire les Cette option permet d’a tive la ré-écriture des numéros de
séquences TCP séquence TCP des deux correspondants (option inactive par
avec un aléa fort défaut)
(arc4) Option INCOMPATIBLE avec le mode d’i spe tio « firewall »
Protéger contre Bloque les répétitions rapides de paquets d’A uitte e t.

l’e voi p t de Cette fonction bloque les tentatives de déclenchement de
paquets Ack mécanismes apparentés à Reno (pour TCP Fast Recovery)
Délai Temps maximum, exprimé en secondes, autorisé pour

d’ouve tu e l’ ta lisse e t de la connexion (handshake TCP complet : SYN
d’u e co e io / SYN+ACK / ACK).
(SYN) Valeur par défaut : 20 secondes
Temps maximum en secondes, de conservation de l’ tat d’u e
Connexion TCP connexion TCP sans activité.
Valeur par défaut : 3600 secondes
41
Temps maximum, exprimé en secondes, de conservation de

Pseudo-
l’ tat d’u e pseudo-connexion UDP sans activité.
connexion UDP
Temps maximum, exprimé en secondes, admis pour la phase
Fe etu e d’u e de fermeture d’u e connexion TCP (FIN+ACK / ACK / FIN+ACK
connexion (FIN) / ACK).
Connexion Délai, en secondes, de conservation d’u e connexion clôturée

fermée (état closed). Valeur par défaut : 2 secondes
Durée maximale, exprimée en secondes, pendant laquelle des

annonces de fenêtres TCP de petite taille (moins de 100
Petite fenêtre octets) seront tolérées sur une connexion. Ce compteur est
TCP armé sur réception de la première annonce de petite fenêtre.
Si aucun message d’aug e tatio de fenêtre ’i te vie t
avant l’expi atio du compteur, la connexion TCP sera coupée.
Cette option permet de désactiver le déclenchement du proxy
Désactiver le
SYN. L’utilisatio de cette fonction ’est recommandé u’à des
proxy SYN
fins de diagnostic.
Connexion TCP (TCP timeout) :

Le délai de conservation, dans la table de stateful, d’u e connexion TCP restée
inactive, peut être étendu dans certaines situations. De nombreux logiciels client et
serveur sont dépourvus de fonctionnalités de « keep-alive » ou de « polling ». En
conséquence, en cas d’i a tivit de l’utilisateu de l’appli atif, la connexion peut
rester complètement silencieuse, sans aucun échange de paquet. Si le délai
d’expi atio est atteint, le moteur de prévention d’i t usio forge un Reset TCP (RST)
à destination des deux correspondants pour les notifier proprement de l’i te uptio
de la communication.
Connexion fermée :
La conservation de la connexion dans la table de stateful après sa clôture vise à
permettre une éventuelle réémission du deuxième FIN+ACK dans le cas où le dernier
ACK aurait été perdu sur le chemin.
42
PARAMÈTRES GLOBAUX TCP UDP
Certains paramètres sont globaux et donc non paramétrables par profil
37
Pa a t es d’i spectio s TCP-UDP communs à tous les profils

Fonction de détection des comportements de type scan de
ports.
Le paramètre « Nb max. de ports par seconde » détermine le
Nb max. ports nombre de ports pouvant être scannés par seconde avant le
par seconde déclenchement de l'alarme pour un même couple IP source
et destination. Les ports bloquées par le filtrage ’e t e t pas
dans ce calcul; seules les tentatives de connexions passantes
seront recensées.
Lorsque la table des connexions du moteur de prévention
d’i t usio est pleine et u’u e nouvelle tentative de
Fréquence de connexion arrive, le moteur tente, par anticipation, de libérer
purge table de des entrées de sa table (essentiellement les connexions en
session état CLOSED, ainsi que les plus anciennes et celles restées
sans activité). Il renouvelle cette recherche selon la valeur de
ce paramètre.
43
L’u des correspondants a perdu l’ tat de sa connexion tandis

que l’aut e connaît son état actuel. La connexion se trouve
alors dans une situation de désynchronisation majeure. En
fonction du correspondant qui aura subit la perte d’ tat,
l’a tivatio de cette option provoquera l’a eptatio de
paquets Ack vides en réponse à un SYN ou provoquera
Autoriser les l’ issio d’u TCP Reset forgé par le firewall sur réception
connexions d’u paquet de données alors que la connexion ’a pas d’ tat
semi-ouvertes connu.
(RFC 793 section
AVERTISSEMENT
3.4)
L’utilisatio de cette option est déconseillée. En effet, la
sélection de cette option tolérerait le passage de paquets
hors contexte pour l’ tat courant de la connexion. Cette
option est supportée pour des raisons de compatibilité avec
le protocole TCP et ’est à utiliser u’e cas de nécessité
absolue et en connaissance de cause.
Cette option permet de désactiver l’i se tio d’i fo atio s

dans les journaux d’ v e e ts traçant les connexions TCP.
Les données de connexions seront tout de même tracées
dans les journaux d’ v e e ts des traitements applicatifs
Tracer chaque pour les connexions faisant intervenir des fonctions liées aux
connexion TCP proxies (cas de l’a tivi us, de l’antispam, du filtrage URL , …).
AVERTISSEMENT
Il est déconseillé de désactiver cette option. En effet, il ne
vous serait plus possible d’o te i des informations sur les
connexions ne faisant pas intervenir de proxy.
Cette option permet de désactiver l’i se tio d’i fo atio s

dans les journaux d’ v e e ts traçant les pseudo-
Tracer chaque connexions UDP.
pseudo- AVERTISSEMENT
connexion UDP Il est déconseillé de désactiver cette option. En effet, il ne
vous serait plus possible d’o te i des informations sur les
sessions UDP.
44
ANALYSES ICMP
Le délai en secondes de conservation d’un état icmp est paramétrable par
profil.
L’encadré Support donne la possibilité d’ignorer les notifications ICMP.

A n’utiliser que dans un but de diagnostic.
39
Les paramètres de configuration des protocoles TCP, UDP, ICMP
L’i spectio protocolaire ICMP

L’i spe tio des messages ICMP se fait majoritairement par le stateful.
En effet, les messages ICMP constituent pour la plupart des notifications de
problèmes d’a he i e e t de paquets et doivent donc être liés à une session
TCP ou UDP présente dans la table de stateful et pour laquelle un message ICMP
viendrait signaler un problème.
En configuration standard, le traitement d’ICMP par le filtrage ’est applicable
u’aux messages de type requête.
45
E pi atio d’u e Temps maximum de conservation d’u état ICMP sans

session activité (exprimé en secondes).
L’a tivatio de cette option permet d’i di ue au moteur de
prévention d’i t usio de ne pas rechercher d’ ve tuelles
connexions TCP ou pseudo-connexions UDP déjà ouvertes et
auxquelles les messages ICMP seraient relatifs.
Ignorer les
notifications Par défaut, cette option est désactivée et permet d’a epte
ICMP automatiquement les notifications ICMP dès lors u’elles
sont légitimes, ’est à dire inhérentes à une connexion ou
pseudo-connexion connue dans la table de stateful.
En choisissant d’ig o e les notifications ICMP, elles devront
être explicitement autorisées dans les règles de filtrage.
46
LES CONNEXIONS VIRTUELLES (VCONN)
Le mécanisme de connexions virtuelles permet au moteur de

prévention d’intrusion d’établir le lien entre les deux connexions
réelles qui se produisent.
Connexion
VCONN Connexion
Client <-> Firewall
Proxy <-> Serveur
80
8080
41
Les connexions virtuelles du moteur de prévention Stormshield Network

Les équipements Stormshield Network embarquent des proxies transparents pour
les protocoles HTTP, SMTP, POP3, FTP et SSL. Placés en coupure, ils gèrent à la fois
les connexions avec le client et avec le serveur : ils se présentent donc comme
serveur aux yeux du client et comme client aux yeux du serveur.
La connexion virtuelle correspond à ce que voit le client.

Les critères qui la caractérisent en terme d’ad esse IP source, d’ad esse IP de
destination et de port de destination sont ceux que l’ad i ist ateu souhaite définir
dans sa politique de filtrage; ceci indépendamment des mécanismes internes activés
pour le fonctionnement d’u proxy transparent.
47
Il est donc nécessaire que la connexion virtuelle soit matérialisée dans le moteur
de prévention d’i t usio . C’est le proxy qui renseigne le moteur de prévention
d’i t usio en indiquant les paramètres qui établissent le lien entre les deux
connexions réelles u’il entretient avec les deux correspondants (Cx1 avec le
client et Cx2 avec le serveur).
Les traitements particuliers à appliquer à ces connexions par le moteur de

prévention d’i t usio (file de QoS, PBR,…) sont ainsi faciles à définir et
centralisés par la règle de filtrage qui permettra leur traitement.
48
L’ANALYSE
APPLICATIVE
Programme du module
✔ Introduction
✔ L’analyse protocolaire sur la couche transport
➔ L’analyse applicative
49
L’ANALYSE APPLICATIVE
Typage des Plugins

flux, contrôle
de conformité
Plugins
TCP, UDP, ICMP
Fragmentation
Analyses IPv4, IPv6
44
L’a al se applicative
• La caractérisation des flux et l’ vasio de données
• Les analyses de conformité applicative
• La gestion des connexions filles
• Les protections web 2.0
50
L’ANALYSE APPLICATIVE
• Caractérisation des flux et attachement des plugins applicatifs
L’attachement d’un plugin applicatif permet une analyse

complémentaire
Plugins
Caractérisation des flux
Attachement des plugins
explicitement ou par
détection automatique
Sans analyse complémentaire, la règle suivante permettant la

navigation web en HTTP
serait basiquement traduite comme suit dans la politique
45
La caractérisation des flux et l’ vasio de données

Dès lors que l’ ta lisse e t d’u flux a été autorisé par une règle de filtrage, son
suivi par les mécanismes de stateful ne suffit pas à garantir une sécurité complète et
ne permet pas à l’ad i ist ateu de se prononcer strictement sur les protocoles
applicatifs permis.
Il apparaît clairement dans l’exe ple ci-dessus que le critère HTTP désigné par
l’ad i ist ateu a été traduit par TCP/80.
Donc, mis à part le protocole de transport et le numéro de port, rien ne forcerait ici
les flux applicatifs traversant cette règle à se conformer au protocole HTTP. Il serait
donc possible de faire passer dans ces connexions des flux tout à fait différents de
HTTP; ceci constituerait de l’évasion de données.
Pour interdire ce phénomène, l’ide tifi atio et l’a al se de la couche supérieure
s’av e t donc nécessaires.
Ces analyses complémentaires sont confiées aux plugins que le moteur de
prévention d’i t usio attache aux connexions afin de définir le contexte applicatif
associé.
L’atta he e t des plugins peut être assuré de différentes manières :
• Explicite :
o par implication d’u port par défaut,
o par sélection du protocole applicatif.
• Implicite (détection automatique) :
o par identification du protocole reposant sur l’a al se des premiers
échanges de données.
51
ATTACHEMENT DES PLUGINS
Attachement explicite par implication du port par défaut en mode IPS/IDS :
Pour faciliter la configuration,

tout en s’assurant d’appliquer le
plus haut niveau d’analyse, les
plugins applicatifs sont liés aux
ports par défaut correspondants.
Attachement explicite par sélection du protocole en mode IPS/IDS :
Le service http-81 n’est pas un port par défaut, l’attachement du plugin ne

peut être forcé que par la sélection du protocole HTTP.
46
Attachement explicite des plugins sur port par défaut

La plupart des protocoles applicatifs sont utilisés sur un port standard identifié et
prédéfini (well known ports). L’i pli atio d’u service se référant à un port
standard dans des règles de filtrage suggère que le protocole applicatif attendu pour
ces flux est le protocole standard généralement utilisé sur ce port. L’asso iatio de
ce service avec un plugin d’a al se permet de simplifier les critères à définir dans la
configuration, tout en donnant la garantie que le protocole attendu sera respecté. En
effet, en plus d’app ofo di les analyses de conformité poussées jus u’à la couche
applicative, cette méthode d’atta he e t de plugin impose le protocole applicatif
autorisé dans les flux concernés.
Attachement explicite des plugins sur sélection du protocole

Cette méthode présente l’ava tage de permettre une désignation fine du protocole
applicatif à imposer et à contrôler pour des flux pris en charge par une règle de
filtrage; cela, sans pour autant généraliser l’utilisatio de ce protocole applicatif à
tout trafic impliquant le port en question (ici http-81), comme cela serait le cas si ce
port avait été ajouté à la liste des ports par défaut du protocole.
Cette méthode conduit à charger une règle de filtrage avec la syntaxe suivante :
Le protocole applicatif est bien imposé.

CETTE MÉTHODE EST PRÉPONDÉRANTE SUR TOUTE AUTRE MÉTHODE.
52
Attachement implicite par détection du protocole applicatif en mode IPS/IDS :
La détection automatique repose sur l’analyse des premiers octets de

données échangés entre les correspondants.
Le but premier de cette méthode est de toujours chercher à appliquer le plus

haut niveau d’analyse, même en cas d’utilisation de ports non standards ou
non définis dans la règle de filtrage, que ce soit pour une autorisation ou pour
un blocage.
47
Attachement implicite par analyse des premiers paquets

La détection du protocole applicatif est rendue possible par une comparaison du
contenu des premiers paquets de données échangés entre les correspondants avec
les syntaxes caractéristiques des protocoles applicatifs connus par les plugins.
Par exemple, un dialogue HTTP commence par une opération (GET, HEAD, POST,…)
suivie d’u argument de forme prévisible et d’u e version de protocole HTTP /1.0 ou
HTTP/1.1.
Pour la plupart des applicatifs, la forme et la syntaxe des premiers échanges de
données sont standardisés et caractéristiques du protocole.
Au contraire de l’exe ple donné précédemment, cette méthode d’atta he e t

’i pose pas par avance un applicatif attendu.
Toutefois, suite à l’atta he e t automatique du plugin adapté, le flux doit se
conformer à l’appli atif sélectionné par la détection jus u’à la fin de la session.
53
• Conformité des protocoles applicatifs (analyse applicative)

• Typage de flux (définition du contexte applicatif)
Analyse applicative
Plugins
Dialogue protocolaire
Phases d’authentification
Typage de flux Protection contre l’évasion de données
Définition du contexte applicatif
48
Les analyses applicatives

Dès lors u’u plugin applicatif est associé à un flux, il va réaliser une étude
approfondie principalement des données protocolaires applicatives (aspect
séquentiel des dialogues, paramètres positionnés dans les en-têtes, phases
d’authe tifi atio , commandes et codes de retour, formatage des contenus
protocolaires, …).
Parmi les différents plugins présents sur les produits Stormshield Network :
• certains ne servent u’à détecter et caractériser le protocole pour définir le
contexte de suivi des contenus de connexions,
• d’aut es effectuent en plus, des analyses de conformité et des remontées de logs
plus détaillées (HTTP, SMTP, …),
• d’aut es encore, en complément des analyses de conformité, se chargent de
gérer les connexions filles lorsque le protocole concerné en fait usage (FTP, SIP,
DCERPC,…).
Pour chaque analyse applicative, il est possible de configurer certains paramètres de

vérification qui peuvent être classés en trois catégories :
• Support des extensions ou des règles spécifiques de la RFC.
➢ Respect du protocole et protection contre l’ vasio de données.
• Définition des tailles maximales autorisées (en-têtes, options et parfois données).
➢ Protection contre les attaques par débordements de tampon.
• Définition des commandes spécifiques qui sont autorisées pour ce contexte
applicatif.
➢ Blocage d’a tio s indésirables ou autorisation de commandes non
standard.
Le paramétrage des contextes applicatifs peut être personnalisé grâce à 10 profils,
qui interviennent dans la construction des profils d’i spe tio IPS/IDS.
54
Le typage des flux (la définition du contexte applicatif)

C’est le rôle premier de tous les plugins, non seulement parce u’il conditionne les
contrôles de conformité applicative, mais également parce u’il prépare les analyses
suivantes en définissant le contexte applicatif pour les contrôles à venir (analyses
Web 2.0 et examen des signatures contextuelles).
55
• Gestion des connexions filles
Plugins
Connexions dynamiques
Connexions filles
Canaux de contrôle et canaux de DATA
50
La gestion des connexions filles

Les contextes applicatifs des protocoles nécessitant des connexions filles ont la
charge de la gestion de ces connexions dynamiques. C’est notamment le cas pour les
protocoles FTP, SIP, DCERPC, H323 et MGCP.
Ces protocoles utilisent plusieurs canaux de communications dont certains
véhiculent des données protocolaires de contrôle tandis que les autres canaux sont
dédiés au transport des données utilisateur (data, voix,…).
Les canaux de contrôles sont suivis par les plugins applicatifs afin d’ lire les
annonces de connexions filles à venir.
Dès lors u’u e connexion fille est annoncée, le plugin applicatif peut en gérer la
préparation dans le stateful pour que cette connexion dynamique soit acceptée, liée
à son canal de contrôle et traitée correctement par une opération de NAT adaptée si
ces communications ont lieu au travers de NAT.
Cette préparation du stateful est opérée par l’i je tio anticipée d’u e connexion
correspondant aux paramètres de l’a o e et dans un état particulier skel (pour
skeleton) en attendant son établissement effectif.
56
• Désactivation d’un plugin
Plugins
Gestion des trafics non conformes
Désactivation
Flux applicatif clairement identifié sans

plugin applicable à ce flux
51
L’ad i ist ateu peut délibérément limiter la portée des analyses :

• Parce u’il a connaissance de l’inconformité de certains trafics.
• Parce u’il sait par avance u’au u plugin applicatif ’est applicable à des flux
clairement identifiés.
La désactivation d’u plugin peut être nécessaire pour éviter des blocages en cas
d’inconformités protocolaires applicatives avérées de la part d’u serveur auquel
l’a s reste toutefois nécessaire à la production, par exemple.
57
DÉSACTIVATION D’UN PLUGIN
Désactivation explicite par sélection d’un protocole de transport dans le

champ protocole de la règle de filtrage
La sélection explicite de « tcp » dans

la colonne protocole donne la
directive de limiter les analyses à la
couche transport TCP,
indépendamment du fait que le port
spécifié soit un port par défaut lié à
un plugin applicatif.
La syntaxe de la règle de filtrage met en évidence la désactivation

(directive « proto TCP »)
52
Désactivation explicite d’u plugin

Le protocole de transport est explicitement désigné dans le champ protocole.
La sélection d’u protocole de transport dans le champ protocole de la règle de
filtrage donne explicitement la directive de limiter les analyses à cette couche
réseau.
Même en cas de présence, dans le champ port de destination, d’u port par défaut
associé à un plugin applicatif, l’a al se applicative ’est pas effectuée.
Cette directive désactive également toute tentative d’atta he e t automatique de

plugin (basée sur la détection de l’appli atif dans les cas où la règle de filtrage porte
sur un port non standard ’est-à-dire un port non désigné comme port par défaut
dans la configuration d’u plugin) ou si aucun port ’est précisé dans le champ « port
destination » de la règle.
Cette méthode présente l’ava tage d’appa aît e de manière évidente dans la
politique de filtrage. Elle ne laisse ainsi aucune ambiguïté sur le niveau de traitement
recherché par la règle de filtrage.
58
DÉSACTIVATION D’UN PLUGIN
Désactivation implicite dans les paramètres avancés de l’un de ses

profils protocolaires
53
Désactivation d’u plugin dans le profil protocolaire

L’e ad Support offre la possibilité de Désactiver la prévention d’i t usio .
Dans ce cas, le plugin dans ce profil ne procédera à aucune analyse applicative.
Cette méthode présente l’i o v ie t de ne pas être visible explicitement dans la

politique de filtrage, sauf si l’ad i ist ateu adopte une nomenclature rigoureuse et
explicite pour le nommage des profils protocolaires, plus particulièrement les profils
d’i spe tio .
Un nom pertinent pour le profil d’i spe tio faisant appel à cette méthode pourrait
être:
HTTP-OFF
Cette méthode ’est pas conseillée à cause de son manque de visibilité.
59
EXEMPLE DE CONTRÔLE DE CONFORMITÉ APPLICATIVE
Données additionnelles en fin de réponse

Evénement http:150
• Conformité de la taille des données reçues avec le champ ‘Content-Length’

• Prévention contre les attaques véhiculées dans les données additionnelles
Configuration par défaut de l’évènement

Action ‘Interdire’ : les paquets transportant les données au-delà de la taille
annoncée par le champ ‘Content-Length’ seront bloquées par l’IPS
Sévérité ‘Majeure’ : la détection de l’évènement générera une alarme majeure
54
L’exe ple ci-dessus illustre un évènement relatif au contexte HTTP.

Cet évènement est référencé sous l’ide tifia t 150 dans le moteur de prévention
d’i t usio .
L’e -tête HTTP peut contenir un champ « Content-Length », en particulier en
HTTP/1.1; la valeur de ce champ permet d’i di ue au préalable la quantité de
données utiles qui sera transférée par HTTP pour répondre à la requête du client.
Cet évènement est ici remonté car la quantité de données transférées excède déjà la
taille annoncée préalablement par le « Content-Length », alors que l’exp diteu des
données continue de tenter d’e envoyer dans la même réponse.
Ce comportement étant anormal et non conforme, il pourrait constituer une
menace, ’est pourquoi il est bloqué par défaut.
60
• Analyses Web 2.0
Plugins
Inspection de code HTML
Analyses Web 2.0
Inspection de code Javascript
Extensions du protocole HTTP

Suppression automatique de code malveillant
55
Le web 2.0
Ce terme tente de qualifier ce que les utilisateurs attendent aujou d’hui de l’usage
de leur logiciel de navigation et des fonctionnalités offertes sur le Web (Internet en
HTTP).
L’ volutio des sites web vers des contenus enrichis, dynamiques et interactifs a
permis l’ e ge e, puis la prolifération de nouvelles techniques d’atta ues
permettant de conquérir de nouvelles cibles, dont en premier lieu les postes clients.
En effet, couplé à l’e i hisse e t du contenu HTML et à l’utilisatio de Javascript,
l’usage des réseaux sociaux et des contenus proposés par leurs utilisateurs
deviennent involontairement vecteurs de diffusion des attaques.
Un tel constat rend impératif un examen, non plus uniquement des données
protocolaires, mais également des données applicatives, ’est-à-dire des contenus
HTML/Javascript, à la recherche d’a tio s suspectes.
61
LES ANALYSES WEB 2.0

REQUETE
Header
REPONSE
Web application
56
L’app oche Stormshield Network

Face à cette menace, Stormshield Network base ses protections sur les mécanismes
existants de contextes en y adjoignant des traitements spécifiques. Ainsi, la
protection web 2.0 consiste à enchaîner les actions suivantes:
• Simplification du code HTML : Cette étape consiste à normaliser le code HTML
vers sa version la plus simple (décoder les caractères encodés de manière
superflue,…). La page HTML ainsi simplifiée peut alors être soumise à l’exa e
des signatures contextuelles pour la recherche de chaînes et de balises suspectes.
• Standardisation du code javascript : comme pour HTML, la méthode repose
d’a o d sur une lecture complète du code afin de le simplifier (pour éviter
l’offus atio de code) et d’e interpréter les fonctions pour en prévoir les actions.
Le web 2.0
Ce terme tente de qualifier ce que les utilisateurs attendent aujou d’hui de l’usage
de leur logiciel de navigation et des fonctionnalités offertes sur le Web (Internet en
HTTP).
L’ volutio des sites web vers des contenus enrichis, dynamiques et interactifs a
permis l’ e ge e, puis la prolifération de nouvelles techniques d’atta ues
permettant de conquérir de nouvelles cibles, dont en premier lieu les postes clients.
62
En effet, couplé à l’e i hisse e t du contenu HTML et à l’utilisatio de Javascript, l’usage des
réseaux sociaux et des contenus proposés par leurs utilisateurs deviennent involontairement
vecteurs de diffusion des attaques.
Un tel constat rend impératif un examen, non plus uniquement des données protocolaires, mais
également des données applicatives, ’est-à-dire des contenus HTML/Javascript, à la recherche
d’a tio s suspectes.
63
LES ANALYSES WEB 2.0
Normalisation HTML
• Supprime les caractères de surcharge utilisés comme variante d’attaque
• Décode les caractères encodés
Exemple : A devient la caractère ‘A’
Normalisation javascript
• Analyse syntaxiquement le code javascript et identifie les variables, les
fonctions et leurs paramètres
• Réévalue chaque fonction utilisée pour modifier la valeur d’une variable
Exemple : "attacxxxxxk".replace("x", "")
La chaîne "attacxxxxxk" devient "attack"
Signatures contextuelles web 2.0

Exemple : clickjacking
Icontainer["style"]["top"]=e["pageY"]-5+"px";
58
Nettoyage du code HTML

Le moteur de prévention d’i t usio effectue différentes opérations pour nettoyer le
code HTML :
• Suppression des caractères espace en trop,
• Suppression des commentaires,
• Normalisation des caractères encodés () - - %4141u - %20),
• Normalisation Utf-7,
• Etc.
Une fois que le code HTML est nettoyé, il est transmis aux contextes de signatures
(exemple : http:html:tag:attribute ou http:html:tag:content).
64
L’a tio associée à la détection d’u e attaque correspondant à une signature dépend
des options de configuration activées :
- Inspecter le code HTML : la connexion est interrompue.
- Supprimer automatiquement les contenus malveillants : les attributs et les tags
HTML suspects sont supprimés de la page avant transmission au client.
- Inspecter le code JavaScript : la connexion est interrompue sur détection d’u e
fonction suspecte (traitée par les signatures http:javascript:raw et
http:javascript:stack)
Ces analyses portent sur un volume conséquent de données, avec, de plus, la

nécessité de procéder à plusieurs passes lors de la normalisation du code, les
performances de traitements sur HTTP peuvent être pénalisées.
L’utilisatio de l’optio de Suppression des contenus malveillants désactivera la
transmission de contenus compressés entre le client et le serveur (suppression de la
capacité Accept-Encoding: gzip du header HTTP, ce qui aura pour effet de multiplier le
nombre de paquets nécessaire à la transaction)
Normalisation javascript
À partir des balises HTML référençant du code Javascript (<script> et js externe), le
moteur de prévention d’i t usio agit en interpréteur Javascript. Les traitements
effectués peuvent être découpés en deux parties :
▪ Normalisation simple et analyse lexicale : Ces traitements consistent à
supprimer les caractères espace en trop ainsi que les commentaires.
L’a al se lexicale permet d’ide tifie les mots clés spécifiques (eval, alert),
les chaînes de caractères et de nombres et enfin repérer les parenthèses.
▪ Normalisation des évasions : Le but de ces traitements est de remplacer le
code Javascript permettant l’ vasio de données par la donnée effective
résultant de l’ex utio du code.
À titre d’exe ple on peut noter : String.fromCharCode(), eval js’ , string
concatenate, …
Blocage des attaques par Javascript

Dès lors que le code Javascript est normalisé, il est transmis aux contextes
http:javascript:raw et http:javascript:stack pour analyse par signature contextuelle. Il
s’agit d’u contexte applicatif dédié aux attaques véhiculées par le web 2.0. Le
contexte http:javascript:stack permet de détecter des attaques qui utilisent des
techniques de masquage (obfuscation) plus complexes.
65
L’ANALYSE
CONTEXTUELLE
Programme du module
✔ Introduction
✔ L’analyse applicative
➔ L’analyse contextuelle
66
LES SIGNATURES CONTEXTUELLES
Détection par Signatures contextuelles

signature
Plugins
Signatures
Contextuelles
Plugins
TCP, UDP, ICMP
Fragmentation
Analyses IPv4, IPv6
61
L’a al se par signatures contextuelles

• La détection par signature
• Stormshield Network Security et les signatures contextuelles
• Les protections contextuelles
67
• Détection par signature
Signatures
Contextuelles
Détection par Signatures contextuelles

signature
Identification
d’atta ues
Identification des
applications
62
La détection par signature

Le but premier des signatures contextuelles est de caractériser des attaques ou des
comportements d’atta ues ne s’appu a t pas sur des inconformités protocolaires,
mais sur des failles spécifiques d’i pl e tatio s logicielles. En restant conformes
aux standards de communication, ces attaques ne semblent pas suspectes lors des
analyses par les plugins. Il s’av e donc nécessaire de compléter les analyses
protocolaires par une identification d’atta ues ou de comportements d’atta ues
connues. En supplément, puisque les contenus des champs analysés peuvent révéler
les versions de logiciels utilisés pour les communications, les signatures
contextuelles offrent également la possibilité d’auto ise ou d’i te di e l’utilisatio
de certains logiciels ou services ainsi identifiés.
Une signature contextuelle est constituée d’u e ou plusieurs chaînes de caractères
dont des parties peuvent être génériques et qualifier un type d’atta ue dans un
contexte applicatif, et d’aut es parties plus spécifiques qui visent à identifier les
éventuelles différentes variantes du type d’atta ue qualifié.
La base des signatures contextuelles est alimentée régulièrement et publiée sur les
serveurs d’A tive Update pré-renseignés dans la configuration usine.
68
• Détermination du contexte applicatif par le firewall Stormshield
IP Transport Applicative Applicative

Données applicatives
header header header data
Analyse IP TCP, UDP, ICMP Plugins Détermination du contexte
Fragmentation
Pattern Matching
La recherche de signatures et
l’identification des applications
s’effectuent dans un contexte donné Ide tifi atio d’appli atio
63
Stormshield Network et les signatures contextuelles

La recherche de signatures limitée à un contexte applicatif, préalablement fixé par le
plugin attaché à la connexion, procure les deux bénéfices suivants :
• Le nombre de signatures examinées étant restreint, la consommation en
ressources allouées à cet examen est donc optimale.
• Les signatures étant spécifiques au contexte applicatif, le risque de faux positifs
est fortement diminué.
De plus, le moteur de prévention d’i t usio a la capacité de construire des

combinaisons d’exa e s de plusieurs signatures identifiant des actions
concomitantes qui constituent des scénarios d’atta ues. Ces mécanismes sont
appelés « signatures multi-contextes » et sont identifiables dans la liste des
signatures, par le mot clé mix.
69
EXEMPLE SUR LE CONTEXTE HTTP
Tentative d’utilisation ou d’accès à cmd.exe

http://www.monserveur.org/répertoire/cmd.exe
Accès à la commande cmd.exe qui permettrait

d’exécuter des commandes sur un serveur web
URL reçue : http://www.monserveur.org/répertoire/cmd%252Eexe
Traitement URL http://www.monserveur.org/répertoire/cmd.exe

decoding
%252E -> %2E -> caractère ‘.’
Pattern matching cmd.exe -> évènement http:url:decoded:48

Tentative d’utilisation ou d’accès à cmd.exe
64
Les protections contextuelles

Les protections contextuelles consistent en la mise en œuv e de plusieurs
traitements. Une fois l’a al se protocolaire effectuée sur les couches IP, transport et
applicative, le contexte applicatif va réaliser ces traitements.
Avant d’effe tue la recherche par signature, la contexte applicatif va nettoyer les
données reçues. L’exe ple retenu est une attaque ancienne qui ne présente plus de
faille de nos jours mais qui est suffisamment simple pour illustrer le mécanisme.
Pour commencer, le contexte applicatif HTTP va tout d’a o d effectuer un décodage

de l’URL. En effet, l’e odage de caractère est un des moyens utilisés pour dissimuler
une attaque. En l’o u e e, il effectue un décodage récursif : une fois décodé %25
devient le caractère %’ puis %2E devient le caractère .’.
A l’issue du décodage l’atta ue deviendra plus facilement décelable.
Le contexte applicatif peut alors confronter les données à sa base de signatures pour
y rechercher une correspondance. Dans l’exe ple choisi, on détecte une tentative
d’appel à la commande cmd.exe, le contexte applicatif lève l’ala e
http:url:decoded:48 (tentative d’utilisatio ou d’a s à cmd.exe).
Ce comportement par enchaînement de traitements réalisés par les contextes

applicatifs offre plusieurs avantages précédemment énumérés, ainsi que le
nettoyage des données, permettant de limiter le nombre de variantes de signatures
pour une attaque donnée.
70
EXEMPLES D’ÉVÈNEMENTS
http:client:header
Exploit WebDAV sur la faille ntdll.dll
Virus W32.beagle.DS : activité de vers détecté
S ta e suspecte su l’utilisatio d’u ot cl HTTP
http:client:data
XMLRPC : possible injection de code à distance
JBOSS : script Autopwn détecté
http:client:useragent
Injection de code dans le user agent HTTP
Virus : variante de SpyEye détecté
http:javascript:raw
Code javascript unescape() suspect
Exploit détecté Phoenix Kit 2,3
Exploit détecté sur HCP depuis BlackHole Kit
65
71
LES PROFILS
PROTOCOLAIRES ET
APPLICATIFS
Programme du module
✔ Introduction
✔ L’analyse contextuelle
➔ Les profils protocolaires et applicatifs
72
PROFILS PROTOCOLAIRES ET APPLICATIFS
Profils
protocolaires Plugins
et applicatifs
TCP, UDP, ICMP
Fragmentation
Analyse IP
Analyses IPv4, IPv6
67

• Les profils d’i spe tio
• Les profils protocolaires et applicatifs
• L’utilisatio des profils d’i spe tio
• Les évènements de prévention d’i t usio
• La configuration des alarmes
• La réaction aux évènements
• Les évènements et les profils protocolaires et applicatifs
73
PROFILS D’INSPECTION ET PROFILS APPLICATIFS
Les profils d’inspection sont

modulaires.
IPS_00 est le profil appliqué

par défaut aux flux
ENTRANTS.
IPS_01 est le profil appliqué
par défaut aux flux SORTANTS.
68
Les profils d’i spectio

Afin d’off i une certaine flexibilité, les profils d’i spe tio sont construits de
manière modulaire. Le moteur de prévention d’i t usio de Stormshield Network
propose 10 profils d’i spe tio sélectionnables et éditables. Chacun de ces profils
peut être indépendamment associé à une règle de filtrage spécifique. Ainsi, seul le
trafic correspondant à la règle de filtrage est traité et inspecté avec les paramètres
particuliers du profil associé.
Un profil d’i spe tio est constitué d’u ensemble de profils protocolaires et
applicatifs. La mise en place d’u profil d’i spe tio consiste donc à choisir le type
de configuration pour les analyses protocolaires et applicatives.
Dans l’exe ple présenté, le profil d’i spe tio « (0) IPS_00 » est constitué du profil
applicatif « (0) protocol_00 » de chaque analyse protocolaire et applicative. Les
autres profils sont construits par défaut selon le même schéma.
74
CONFIGURATION D’UN PROFIL APPLICATIF
69

La configuration d’u profil protocolaire ou applicatif consiste à définir les
paramètres à utiliser pour les analyses de conformité spécifiques au protocole
concerné. Ils permettent également de définir le comportement des traitements de
plus haut niveau tels que les analyses spécifiques aux proxies lorsque le protocole en
question peut également être pris en charge par un proxy.
Le moteur de prévention d’i t usio Stormshield Network permet de configurer 10

profils protocolaires et applicatifs différents. Chaque profil permet de particulariser
les différents traitements pour le protocole sélectionné.
Cependant, pour chaque protocole ou contexte applicatif, il existe des paramètres

globaux, qui sont appliqués quelque soit le profil sélectionné. A l’ex eptio du cas
des profils protocolaires (IP, ICMP et TCP/UDP) et de quelques profils applicatifs, ces
paramètres communs concernent principalement le port d’atta he e t par défaut
du contexte applicatif.
75
AFFECTATION D’UN PROFIL D’INSPECTION À UN FLUX
Les profils (2) de traitements

protocolaires TCP et HTTP ont
été personnalisés, et
renommés pour des besoins
spécifiques.
Tous deux participent au profil

d’inspection (2), renommé
également pour rendre compte
explicitement des
modifications apportées.
L’attachement de ce profil d’inspection particulier à une règle de filtrage,

permet d’appliquer ces traitements spécifiques aux flux désignés par la
règle.
70
Utilisation d’u profil d’i spectio

Les profils d’i spe tio peuvent être renommés et construits à partir de profils
protocolaires spécifiquement désignés et contenant des paramètres personnalisés.
Ils permettent d’appli ue les divers traitements particuliers définis dans les profils
protocolaires.
Les flux ciblés par ces traitements sont décrits par une règle de filtrage à laquelle le
profil d’i spe tio particulier est assigné.
76
PARAMÉTRAGE DES ÉVÈNEMENTS
Chaque évènement détectable par la prévention d’intrusion est associé

à une alarme configurable.
71
Configuration des évènements de prévention d’i t usio

Par défaut, la liste des évènements est affichée en vue par profil d’i spe tio .
Pour tous les évènements, une action et un niveau d’ale te sont pré-paramétrés.
▪ Autoriser : le moteur de prévention d’i t usio laisse passer le

paquet correspondant à l’ala e.
Action
▪ Interdire : le moteur de prévention d’i t usio bloque le paquet
correspondant à l’ala e.
▪ Majeur : le moteur de prévention d’i t usio émettra une alarme
majeure sur détection de l’ v e e t.
▪ Mineur : le moteur de prévention d’i t usio émettra une alarme
Niveau mineure sur détection de l’ v e e t.
▪ Ignore : le moteur de prévention d’i t usio ’ ett a aucune
alarme sur détection de l’ v e e t. L’a tio définie sera donc
appliquée silencieusement.
77
La réaction aux évènements
Permet de de a de l’e voi d’u e- ail lo s ue l’ v e e t s’est

Envoyer un e-mail
produit N fois dans un laps de temps de T secondes
Permet de définir le comportement du moteur de prévention

d’i t usio suite à la détection de l’ v e e t :
▪ Aucun : aucune réaction supplémentaire ’est définie suite à la
détection de l’ v e e t ,
▪ Envoyer un e-mail : sur détection de l’ v e e t, le moteur de
Avancé / prévention d’i t usio enverra un e-mail pour remonter
Réaction des l’ala e aux destinataires configurés dans le menu des
alarmes « Notifications »,
▪ Mettre en quarantaine : permet de bloquer tout le trafic
impliquant la machine responsable de l’ v e e t. Cette
quarantaine dynamique est associée à une durée (en minutes)
et ne persiste pas au redémarrage (la liste des machines en
quarantaine est réinitialisée lors d’u redémarrage du firewall).
Capture le paquet
Cette option permet de conserver dans les journaux, une copie du
responsable de la
paquet responsable de l’ v e e t. La taille des informations
remontée
dépend du modèle de votre Firewall.
d’ala e
Les v e e ts pou les uels l’a tio appa aît g is e e so t pas pa a t a les
compris en mode CLI).
Tri et sélection pour affichage
Pou fa ilite les e he hes d’ v e e ts da s la liste, il est possi le de o i e

l’utilisatio du outo de at go ies, du e u de p s le tio et du ha p de
recherche. Il est également possible de modifier le tri en cliquant sur les en-têtes de
colonnes.
78
PARAMÉTRAGE DES ÉVÈNEMENTS
En vue par contexte, le menu d’application d’un modèle montre le modèle

actuellement en vigueur et permet de sélectionner un autre modèle.
Les nouvelles signatures contextuelles téléchargées sont appliquées automatiquement et

elles sont marquées par le drapeau « Nouveau » jusqu’à l’approbation de l’administrateur
73
Les évènements dans les profils protocolaires et applicatifs

L’affi hage de la liste des évènements peut également être centré sur les contextes
(HTTP dans cet exemple).
Dans cette vue, le menu d’appli atio de modèles affiche le modèle courant
appliqué au profil et offre la possibilité d’appli ue un autre modèle.
Les signatures contextuelles sont nombreuses et peuvent être mises à jour

quotidiennement. Les nouvelles signatures téléchargées sont appliquées
automatiquement (sans l’app o atio de l’ad i ist ateu aux flux analysés avec
l’a tio et le niveau d’ale te définis par défaut.
Pour distinguer aisément ces nouvelles signatures, un drapeau « Nouveau » les met
en évidence par le pictogramme.
Suite à l’exa e des actions et niveaux d’ale te proposés, l’ad i ist ateu peut
approuver ces évènements pour en faire disparaître le marqueur « Nouveau » et
ainsi rendre les futures signatures plus visibles dans la liste.
Il est possible d’app ouve une sélection de signatures en une seule fois en utilisant
une action multiple accessible en en-tête de colonne .
79
CAS PARTICULIERS SUR LES ALARMES
Alarmes globales
La configuration de quelques alarmes est commune à tous les profils
Alarmes non configurables
Alarmes sensibles
Ces alarmes sont dites "sensibles"

Sur détection d’un évènement sensible en action "passer", le contexte applicatif se
détache dynamiquement de la connexion
74
Les alarmes globales

Il existe quelques évènements pour lesquels le paramétrage est global à tous les
profils. Ce sont principalement des évènements détectés avant l’ valuatio des
règles de filtrage. Or la sélection d’u profil protocolaire ou applicatif s’effe tue
pendant le processus d’ valuatio des règles de filtrage auxquelles sont associées les
profils d’i spe tio s.
C’est par exemple le cas pour l’ v e e t « Usurpation d’ad esse IP » dont la
vérification intervient bien avant l’exa e du stateful et du filtrage.
Les alarmes non configurables

La configuration des actions de certaines alarmes ’est pas possible. Il s’agit pour la
plupart d’ v e e ts particuliers qui sont liés à une information à postériori de
détection d’u évènement (scan de port), d’u e information sur les mécanismes
enclenchés pour la poursuite des analyses (désynchronisation du trafic TCP) ou
encore d’u évènement trop en marge des standards de communication pour
permettre la poursuite des analyses (Attaque Xmas tree). Les alarmes non
configurables sont des alarmes globales.
80
Ci-dessous d’aut es exemples d’ala es non configurables :

▪ L’ v e e t « Adresse IP en liste noire » (ip:93) est forcément
configuré en action « Interdire » , puisque la liste noire a justement
vocation à bloquer des communications impliquant les machines qui y
sont inscrites.
▪ L’ v e e t « Attaque de type Land » (ip:21) est détecté dès u’u
paquet IP est construit avec la même adresse IP dans les champs
source et destination. Cet évènement est forcé sur l’a tio
« Interdire ».
▪ L’ v e e t « machine du réseau interne inconnue » (ip:8) est détecté
sur réception d’u paquet à destination d’u e machine interne qui ’a
pas encore été identifiée par le moteur de prévention d’i t usio . Elle
l’est lo s u’elle répond à la requête initiale qui a déclenché
l’ v e e t. Cet évènement est nécessairement configuré en action
« Autoriser ».
Les alarmes sensibles

Certaines alarmes configurables sont dites « sensibles ».
Elles sont repérées par le pictogramme
Ces alarmes indiquent des évènements d’inconformité qui rendent impossible la
poursuite des analyses avec le même niveau de détail que celui appliqué
jus u’alo s.
Par exemple, lo s u’u e connexion est en cours de suivi par le plugin HTTP et
que l’u ou les deux correspondants utilisent des commandes, syntaxes ou codes
de retour totalement étrangers aux standards décrivant HTTP. Dans ces
conditions, l’a al se du flux en tant que flux HTTP ’est plus possible, l’a tio
« Autoriser » de l’ala e sensible va permettre la poursuite de la connexion en
désactivant les analyses applicatives pour limiter les contrôles aux couches
inférieures uniquement.
La désactivation des analyses applicatives se fait simplement par détachement
dynamique du plugin qui est en cours de suivi.
Ce type d’ala es peut également être relatif à un protocole de plus bas niveau
comme TCP; dans ce cas, le suivi stateful basculera sur un suivi dit « TCP Lite ».
81
PROFILS D’INSPECTION PAR DÉFAUT
Les profils d’inspection par défaut peuvent être choisis par l’administrateur.
Il est également possible de définir la configuration par défaut

de toute nouvelle signature téléchargée par Active Update.
76
Paramètres d’i spectio s par défaut

Afin de faciliter la configuration des règles de filtrage et leur association avec les
profils d’i spe tio , le moteur de prévention d’i t usio Stormshield Network utilise
des profils par défaut. Il existe deux profils par défaut qui s’atta he t
automatiquement en fonction du type de trafic :
▪ (0) IPS_00 : Ce profil est implicitement associé au trafic provenant des
réseaux non protégés du firewall et ce quelque soit le réseau de
destination. Ce trafic est qualifié de trafic entrant.
▪ (1) IPS_01 : Ce profil est implicitement associé au trafic provenant des

réseaux protégés du firewall. Ce trafic est qualifié de trafic sortant.
Les profils par défaut ne sont attachés que lo s u’au u profil d’i spe tio
particulier ’a été spécifié dans la règle de filtrage qui autorise le flux.
82
Configuration par défaut des nouvelles alarmes
Cette option permet de conserver la configuration par

Appliquer le défaut proposée par le laboratoire de développement
modèle par défaut Stormshield Network pour les nouvelles alarmes.
aux nouvelles En désactivant cette option, toute nouvelle signature
alarmes contextuelle prendra les valeurs de configuration définies
dans les champs « Action » et « Niveau ».
Permet de définir l’a tio qui sera affectée à toute
nouvelle alarme intégrée au moteur de prévention
d’i t usio . Il y a deux valeurs possibles :
Action ▪ Passer : le moteur de prévention d’i t usio laisse
passer le paquet correspondant à l’ v e e t
▪ Bloquer : le moteur de prévention d’i t usio bloque
le paquet correspondant à l’ v e e t.
Permet de définir le niveau d’ale te qui sera affecté pour
toute nouvelle alarme qui sera intégrée au moteur de
prévention d’i t usio .
▪ Majeur : le moteur de prévention d’i t usio émettra
une alarme majeure sur réception d’u paquet
correspondant.
Niveau ▪ Mineur : le moteur de prévention d’i t usio émettra
une alarme mineure sur réception d’u paquet
correspondant.
▪ Ignore : le moteur de prévention d’i t usio ’ ett a
aucune alarme sur réception d’u paquet
correspondant.
Cette option permet d’ajoute la capture du paquet aux
Capture du paquet informations écrites dans le journal des évènements de
type alarmes (cas des alarmes majeures et mineures).
83
STORMSHIELD
NETWORK
VULNERABILITY
MANAGER
Programme du module
✔ Introduction
✔ Les profils protocolaires et applicatifs
➔ Stormshield Network Vulnerability Manager
84
Vulnerability Signatures contextuelles

Manager
Pattern
Plugins
ASQ
Plugins
TCP, UDP, ICMP
TCP, UDP, ICMP

Fragmentation
Fragmentation
Analyses IPv4, IPv6

Analyse IP
79

• Présentation de Stormshield Network Vulnerability Manager
• Les objectifs
• Le fonctionnement
85
• Vulnerability Manager
Signatures
Contextuelles
Vulnerability Manager
Inventaire
applicatif
Fourniture de
correctifs à appliquer
80
Présentation de Stormshield Network Vulnerability Manager

Stormshield Network Vulnerability Manager est une solution intégrée (option de
licence) qui vous permet de superviser la sécurité de vos réseaux.
Aussitôt u’u e vulnérabilité est détectée sur votre réseau, Vulnerability Manager
vous avertit et vous donne les informations nécessaires à sa correction.
Cet outil permet à un administrateur réseau de récupérer des informations en temps

réel afin de les analyser pour identifier de possibles vulnérabilités qui pourraient
compromettre la sécurité de son infrastructure.
Stormshield Network Vulnerability Manager récupère et archive ces données ainsi

que des informations concernant les systèmes d’exploitatio s et les différentes
applications qui ont pu être installées sur les machines du réseau. Les applications
clientes sont distinguées des applications serveurs. Les profils de configuration
permettent de cibler le type d’appli atio s à superviser.
Les bénéfices
• Surveiller le niveau de sécurité des applications utilisant le réseau,
• Visualiser en temps réel l’i ve tai e des applications installées,
• Obtenir une classification instantanée des sévérités,
• Consulter facilement les liens vers les corrections à appliquer,
• Analyser/évaluer les risques,
• Conserver les rapports d’ v e e ts de sécurité envoyés automatiquement par
email.
86
SN VULNERABILITY MANAGER
Les différents types

de rapports peuvent
être envoyés à
différents
destinataires.
Les éléments sous

surveillance peuvent
être définis avec des
profils de
supervisions
indépendants.
Certaines machines
peuvent être exclues
de la supervision.
81
Configuration
Les vulnérabilités étant présentes dans les journaux, la journalisation doit également
être activée. Par défaut, l’espa e disque local réservé aux vulnérabilités est de 2% de
l’espa e total de stockage des journaux.
87
IDENTIFICATION ET GESTION
Vue d’ensemble des vulnérabilités détectées
82
Le fonctionnement
• Le moteur de prévention Stormshield Network analyse tous les paquets de trafic
jus u’à la couche applicative.
• L’ide tifi atio de systèmes d’exploitatio est assurée d’a o d par « prise
d’e p ei te » (fingerprinting) en examinant les combinaisons de paramètres
utilisés lors des communications réseau (options TCP, valeur de MSS, …), puis elle
est complétée grâce aux informations collectées par les plugins applicatifs
(bannières, user-agent,…) en même temps que sont recensées les versions des
logiciels utilisés.
• Stormshield Network Vulnerability Manager compare alors les logiciels détectés
avec sa base de données de vulnérabilités.
• La base de vulnérabilités est maintenue quotidiennement et publiée pour une
mise à disposition par Active Update.
Les informations collectées et consolidées sont ensuite inscrites dans les logs et
consultables en temps réel. Ainsi, l’ad i ist ateu peut suivre sa politique de
sécurité, corriger les failles sur le réseau, détecter les applications interdites dans la
politique d’e t ep ise ou encore prendre en charge en temps réel les risques relatifs à
une attaque.
NOTE
Attention, si une vulnérabilité a été détectée il y a moins de 7 jours, il ’ a aucune
nouvelle remontée dans les journaux. Pour visualiser l’e se le des vulnérabilités,
afficher les journaux sur les 30 derniers jours (comme dans l’exe ple ci-dessus), ou
sur une période de temps personnalisée, de plus de 7 jours.
88
ACTION ET CORRECTION
Identification des vulnérabilités et recherche de solution.
83
Rapport
Vue synthétique sur l’i te fa e web :

• Les machines les plus vulnérables ou utilisateurs incriminés,
• Liste des attaques pouvant être exploitées localement/à distance,
• Répartition des attaques exploitables à distance avec une classification par
sévérité,
• Liste des systèmes d’exploitatio détectés,
• Liste des vulnérabilités avec un tri par sévérité .
Vous pouvez ajouter des colonnes aux journaux affichés pour obtenir des
informations plus détaillées.
Action et correction
• Comprendre et connaître les vulnérabilités sur les versions logicielles impactées
ainsi que la date d’appa itio (cliquer droit sur la ligne de journal ou sur ses détails
fournit un lien vers une aide en ligne et la solution corrective adéquate),
• Vérifier et identifier les vulnérabilités pour une application particulière par famille,
machine, port applicatif, etc.
89
LES MODES
D’INSPECTION
Programme du module
✔ Introduction
✔ Les profils protocolaires et applicatifs
✔ Stormshield Network Vulnerability Manager
➔ Les modes d’inspection
90
LES MODES D’INSPECTION
Modes d’i spe tio
Plugins
TCP, UDP, ICMP
Fragmentation
Analyses IPv4, IPv6
85
Les modes d’inspection : niveau d’analyse et niveau de logs

• Le mode IPS
• Le mode IDS
• Le mode Firewall
91
NIVEAU DE LOG ET MODES D’INSPECTION
• Inspection IPS (mode par défaut)
o Application du niveau d’analyse le plus élevé : plugin + signatures

contextuelles
o Journaux de connexion de niveau Protocole : Opération + argument +
résultat (code de retour de l’applicatif)
86
Inspection IPS (Intrusion Prevention System) : journalisation

Le mode IPS est appliqué par défaut.
Il procure le niveau d’a al se le plus élevé, ainsi que le meilleur niveau de détail des
informations de logs pour les connexions, dès lors u’u suivi applicatif leur aura été
appliqué.
Lo s u’u e connexion (ou une opération dans le cas d’HTTP se termine, le moteur de
prévention d’i t usio fournit au système de journalisation tous les détails u’il a pu
recueillir à propos de la connexion.
Outre les informations de base pour une connexion (source, destination et ports), les
opérations et les arguments passés dans l’appli atif sont également journalisés, ainsi
que les codes de retour lorsque le protocole en fait usage.
Le nom et le numéro de la règle de filtrage qui a autorisé cette connexion, ainsi que le
profil d’i spe tio appliqué sont également consignés.
92
NIVEAU DE LOG ET MODES D’INSPECTION
• Inspection IPS (mode par défaut)
o Remontées d’alarmes avec action « block » en cas d’évènement

suspect
Bien que le mode IPS soit sélectionné, les actions associées aux évènements étant
paramétrables, il sera possible d’obtenir une action « pass » pour les évènements
explicitement configuré ainsi.
87
Inspection IPS (Intrusion Prevention System) : alarmes

Le mode IPS est appliqué par défaut.
Il procure le niveau d’a al se le plus élevé, ainsi que le meilleur niveau de détail des
informations de logs pour les connexions, dès lors u’u suivi applicatif leur aura été
appliqué.
Lo s u’u e connexion (ou une opération dans le cas d’HTTP se termine, le moteur de
prévention d’i t usio fournit au système de journalisation tous les détails u’il a pu
recueillir à propos de la connexion.
Outre les informations de base pour une connexion (source, destination et ports), les
opérations et les arguments passés dans l’appli atif sont également journalisés, ainsi
que les codes de retour lorsque le protocole en fait usage.
Le numéro de la règle de filtrage qui a autorisé cette connexion, ainsi que le profil
d’i spe tio u’elle lui a appliqué sont également consignés.
Un évènement suspect subira un blocage et provoquera la levée d’u e alarme qui, elle
aussi, permettra d’ide tifie la règle de filtrage et le profil d’i spe tio qui étaient
attachés à la connexion sur laquelle l’ v e e t s’est produit.
93
NIVEAU DE LOG ET MODES D’INSPECTION DÉGRADÉS
• Inspection IDS
o Application du niveau d’analyse le plus élevé : plugin + signatures

contextuelles
o Journaux de connexion de niveau Protocole : Opération + argument +
résultat (code de retour de l’applicatif)
88
Inspection IDS (Intrusion Detection System) : journalisation

Le mode d’i spe tio IDS est à définir explicitement dans la règle de filtrage.
Il procure le même niveau initial d’a al se que le mode IPS, avec une tolérance
équivalente au paramétrage d’u e action « autoriser » sur l’e se le des évènements
de type alarme.
Ce mode est donc capable de dégrader les analyses pour laisser passer des
évènements majeurs qui se produiraient sur la connexion. Il pourra ainsi détacher un
plugin de suivi applicatif sur réalisation d’u évènement sensible, mais également
abandonner les contrôles sur les couches inférieures, lo s u’u e anomalie majeure s’
produit (un mauvais séquençage TCP par exemple).
Ce mode est même capable de débrayer des blocages d’ v e e ts bas niveau,
comme par exemple l’usu patio d’ad esse IP.
94
• Inspection IDS
o Remontées d’alarmes avec action « pass » en cas d’évènement

suspect
En cas d’évènement qualifié de « sensible » (comme ci-dessus), le plugin applicatif en cours de suivi
sera détaché. Dès lors les informations de niveau applicatif ne seront plus journalisés.
Le log en fin de connexion sera de niveau « Connexion » et non plus « Protocole ».
89
Inspection IDS (Intrusion Detection System) : alarme

Quels que soient les évènements apparus, une alarme est levée conformément à la
configuration du niveau d’ale te de ceux-ci.
95
• Inspection Firewall
o Application du filtrage au 1er paquet, puis analyse basique couvrant :

• la volumétrie de données échangées
• la détection de clôture de la connexion
o Journaux de connexion : uniquement les informations de volumétrie et

de durée
o Action « pass » sans aucune remontée d’alarme en cas d’évènement
suspect (même majeur)
Pour les protocoles nécessitant une gestion de connexions filles (FTP, SIP, DCERPC), les analyses
en mode Firewall sont équivalentes à celles du mode IDS pour les canaux de contrôle. Le niveau de
journalisation obtenu pour ces connexions inclue les opérations et arguments. 90
Inspection Firewall
Le mode d’i spe tio Firewall est à définir explicitement dans la règle de filtrage.
Après acceptation du premier paquet de connexion par la règle de filtrage, il ne
procure u’u suivi basique :
• Création d’u état sur réception d’u premier paquet valide,
• Suivi de la volumétrie des données échangées dans la connexion,
• Détection de la clôture de connexion,
• Aucune levée d’ala e en cas d’ v e e t anormal.
Le suivi des connexions dans ce mode d’i spe tio est appelé « FastPath ».
Dans ce mode d’i spe tio , aucun plugin d’a al se protocolaire ’est attaché, pas
même le plugin TCP.
Il en résulte que les analyses TCP (options, fenêtres et séquençage,…) en suivi
« FastPath » NE SONT PAS EFFECTIVES. Seuls les flags Fin et Reset sont recherchés
pour une détection correcte des clôtures de connexion.
Les canaux de contrôle des protocoles applicatifs FTP, SIP et DCERPC, parce u’ils
annoncent des connexions filles dynamiques, sont nécessairement suivis par leur
plugin respectif. Ces canaux de contrôle ne sont donc pas suivis en « FastPath »,
mais tels u’ils le seraient en mode IDS, cependant sans aucune remontée d’ala e
en cas d’ v e e t non conforme.
Les connexions filles sont quant à elles suivies en mode « Fastpath ».
96
RECOMMANDATIONS DE SÉCURITÉ
• Adapter les profils d’inspection au rôle de l’équipement
• Adapter les profils d’inspection en fonction du contexte
• Remonter à Stormshield les faux positifs
• Approuver régulièrement les nouvelles alarmes
91
En fonction de l’utilisatio de l’ uipe e t, il peut être utile de désactiver certaines

vérifications de l’IPS pour gagner des ressources de calcul. Par exemple ne pas
appliquer un filtrage IPS sur du HTTP si le trafic est ensuite redirigé vers un proxy
filtrant.
Par défaut l’IPS est actif sur toutes les règles de filtrage en mode de détection du
protocole automatique. Afin de mieux inspecter les flux il est recommandé de
qualifier manuellement le type de protocole si le port utilisé ’est pas standard. L’IPS
risquerait de ne pas détecter correctement l’appli atio .
Si des flux sains déclenchent des alarmes, il sera sûrement nécessaire de modifier les
paramètres de l’ASQ pour ne pas bloquer la production. Dans ce cas, les
modifications doivent être faites au plus spécifique. De préférence dans un profil
dédié qui sera appliqué sur les règles identifiants précisément le trafic concerné.
N’h sitez pas à remonter au support ou votre contact privilégié les cas de faux positif
en configuration par défaut.
Afin de profiter pleinement des mises à jour de la liste des signatures IPS, il faut
régulièrement approuver les nouvelles alarmes.
97
LAB 1 – BASES DE CONFIGURATION

LAB 2 – SUIVI STATEFUL EN ENVIRONNEMENT ROUTÉ
LAB 3 – CONFIGURATION DES OBJETS ET DE LA POLITIQUE DE NAT
LAB 4 – ÉVÈNEMENT DE PROTOCOLES APPLICATIFS
92
Pour aller plus loin, consultez les ressources du site documentation.stormshield.eu :

• Identifier les commandes de protocoles industriels traversant le firewall
• Signatures de protection contextuelle personnalisées
Et pour les situations/questions très spécifiques, consultez la base de connaissance

du TAC kb.stormshield.eu.
98
INFRASTRUCTURE À
CLÉS PUBLIQUES
✔ Prévention d’i t usio

➔ Infrastructure à clés publiques
Proxy SSL
VPN IPsec avancé
99
QU’EST CE QUE LA
CRYPTOGRAPHIE ?
INFRASTRUCTURE À CLÉS PUBLIQUES
Programme du module
➔ Qu’est-ce que la cryptographie ?

Les types de chiffrement
Infrastructures à clés publiques
PKI Stormshield Network
Création d’u e autorité de certification
Création d’u e identité serveur
Création d’u e identité utilisateur
Gestion des identités et certificats
Révocation de certificats et CRL
100
CRYPTOGRAPHIE
Cryptographie
Ensemble des techniques permettant la protection des données en assurant :
• Leur confidentialité
• Leur intégrité
• L’authentification des émetteurs / destinataires des données
Clé
Une clé est un opérateur permettant de réaliser une opération
cryptographique (chiffrement, déchiffrement, signature numérique,…).
Exemple : clé de chiffrement de l’avocat (A vaut K) :

A A B C D E F G H I J K L MN O P Q R S T U V WX Y Z K
vaut vaut
K K L MN O P Q R S T U V WX Y Z A B C D E F G H I J A
• Algorithme utilisé : substitution de lettre par décalage de 10 rangs vers la

droite de l’alphabet
• Le chiffrement du mot STORMSHIELD donne CDYBWCRSOVN
• La clé de déchiffrement est K vaut A
Qu’est-ce que la cryptographie?

La cryptographie est un terme générique pour désigner toutes les techniques de
chiffrement de messages.
La cryptographie est donc la bonne solution pour la protection des
communications sur Internet.
Concepts
• La cryptographie se base sur des opérations mathématiques généralement
appelées algorithmes. Les informations à transmettre de manière sécurisée
sont appelées « Message » dans la suite de ce module.
• Une fois que l’op atio mathématique de chiffrement est réalisée,
l’i fo atio d’o igi e (le message) est illisible en l’ tat.
• Le principe de l’op atio de chiffrement consiste à appliquer un algorithme
qui utilise comme paramètre d’e t e une clé de chiffrement.
• Pour effectuer l’op atio de déchiffrement, il faut fournir au destinataire du
message le moyen de le déchiffrer, à savoir la clé de déchiffrement.
Exemple
• L’algo ith e choisi, à savoir un décalage de (+/-) 10 lettres utilise « 10 »
comme clé : « A vaut K » donne une clé « +10 » pour le chiffrement et induit
une clé « -10 » pour le déchiffrement (« K vaut A ») ; et la réciproque est
toujours vraie, si « K vaut A » est choisi pour le chiffrement, « A vaut K » est
utilisé pour le déchiffrement.
101
LES TYPES DE
CHIFFREMENT
Programme du module
✔ Qu’est-ce que la cryptographie ?

➔ Les types de chiffrement
Infrastructures à clés publiques
102
TYPES DE CHIFFREMENT
• Cryptographie symétrique :
1. Génère clé secrète
2. Transmet
3. Crée Message
4. Chiffre message
5. Transmet
Alice Bob
6. Déchiffre ( )=
Avantage : Rapidité des opérations de chiffrement et déchiffrement

Inconvénient : Transmission de la clé secrète de chiffrement (la procédure
doit être sécurisée)
Algorithmes de chiffrement symétrique : AES, DES, Blowfish
Chiffrement symétrique
L’exe ple de l’algo ith e (+/-) N vu avec la clé N=10 sur une diapositive
précédente est simple mais permet de mettre en lumière des éléments de
compréhension importants :
• La clé utilisée est nommée clé symétrique, puis u’il existe une relation
mathématique évidente entre la clé de chiffrement « +10 » et la clé de
déchiffrement « -10 » (le déchiffrement est l’op atio mathématique
inverse),
• Plus généralement, si la connaissance de la clé de chiffrement, et/ou de
l’algo ith e de chiffrement utilisé, permet de calculer la clé de
déchiffrement, il s’agit d’u chiffrement symétrique (ou chiffrement à clé
secrète),
• La clé secrète ou clé symétrique est ainsi assimilée à une clé identique pour
les opérations de chiffrement et de déchiffrement. Les algorithmes utilisés
sont basés sur la combinaison d’op atio s mathématiques simples, ils
offrent donc l’ava tage d’effe tue les opérations cryptographiques
rapidement.
Il existe différents algorithmes de chiffrement symétrique (AES, DES, Blowfish).

Les équipements Stormshield Network sont optimisés pour l’algo ith e AES
qui est un des algorithmes de chiffrement symétrique les plus sûrs.
103
La robustesse d’u procédé cryptographique symétrique réside dans la taille de

la clé. En effet, sachant que la liste des algorithmes symétriques est finie, les
tentatives de déchiffrement illicite de message se basent sur la découverte de la
clé. Or il est plus difficile et plus long de déterminer la valeur d’u e clé de grande
taille. Pour un algorithme de chiffrement donné, il existe plusieurs tailles de clés
possibles. Les valeurs de taille de clé les plus communes sont 256 et 128 bits.
L’usage d’u e clé secrète identique pour le chiffrement et le déchiffrement

constitue l’i o v ie t majeur d’u chiffrement symétrique. En effet, si un
intrus arrive à obtenir ou à voler cette clé, il pourra déchiffrer toutes les données
protégées grâce à cette clé. Ainsi, il est nécessaire de mettre en place une
procédure sécurisée pour transmettre la clé secrète à tous les destinataires
devant déchiffrer le message.
104
• Cryptographie asymétrique
1. Génère clé privée et clé publique
Alice 2. Transmet Bob
3. Crée Message
4. Chiffre message
5. Transmet
6. Déchiffre ( )=
Avantage : Robustesse du chiffrement liée à l’usage d’une paire de clés

Inconvénient : Nécessite des ressources de calcul plus importantes
Algorithmes de chiffrement asymétrique : DSA, RSA
Chiffrement asymétrique
Lorsque la connaissance de la clé de chiffrement et de l’algo ith e utilisé ne permet
pas de calculer la clé de déchiffrement, le chiffrement est dit asymétrique (ou
chiffrement à clé publique). Par ailleurs, la clé permettant le déchiffrement de
messages ’a pas besoin d’ t e échangée.
Les opérations étant plus complexes que les algorithmes symétriques, elles
consomment plus de ressources de calcul. Par conséquent, ces algorithmes sont
généralement mis en œuv e soit pour authentifier une communication soit pour
échanger la clé secrète qui sera utilisée plus tard par un chiffrement symétrique.
DSA et RSA sont des algorithmes de chiffrement asymétrique.
Outre des tailles de clés bien plus grandes que pour la cryptographie symétrique, la
robustesse d’u procédé cryptographique asymétrique réside ainsi dans l’usage
d’u e paire de clé :
• La clé publique, libre d’a s, sert à déchiffrer des informations chiffrés
par la clé privée (signature et haché d’u message), et à chiffrer un
contenu destiné au seul détenteur de la clé privée correspondante,
• La clé privée, déployée sur un seul système, sert à déchiffrer des
informations chiffrés par la clé publique (contenu d’u message), ou à
signer le message.
Les cas d’usage correspondants sont détaillés sur les diapositives suivantes.
105
• Chiffrement asymétrique
1. Transmet clé publique
Alice 2. Crée Message Bob
3. Chiffre message
4. Transmet
5. Déchiffre ( )=
OBJECTIFS
Authentification Authentification Vitesse de
Confidentialité Intégrité
émetteur destinataire traitement
Chiffrement asymétrique pur
0 – Bob crée une bi- l as t i ue, o pos e d’u e pa tie pu li ue l

pu li ue et d’u e pa tie p iv e l p iv e ,
1 – Bob envoie sa clé publique à Alice,
2 – Alice écrit un message pour Bob,
3 – Alice chiffre le message pour Bob avec la clé publique de ce dernier, la
confidentialité du message est assurée par le chiffrement,
4 – Alice envoie le message chiffré à Bob,
5 – Bob déchiffre le message reçu avec sa clé privée, le message chiffré avec la
clé publique de Bob e pouva t t e d hiff u’ave la l p iv e de Bob,
l’authentification du destinataire est assurée, mais les calculs nécessaires
consomment beaucoup de ressources, au détriment de la vitesse de traitement.
106
• Session (chiffrement asymétrique + chiffrement symétrique)

Alice 2. Génère une clé symétrique Bob
3. Chiffre la clé générée
4. Transmet la clé générée
5. Déchiffre ( )=
6. Crée et chiffre un message
7. Transmet le message
8. Déchiffre ( )=
OBJECTIFS
Clé de session
0 – Bob crée une bi- l as t i ue, o pos e d’u e pa tie pu li ue l pu li ue

et d’u e pa tie p iv e l p iv e ,
2 – Alice génère une clé symétrique qui chiffrera les messages,
3 – Alice chiffre la clé symétrique générée pour Bob avec la clé publique de ce
dernier, la confidentialité de cette proposition de clé est assurée par le chiffrement,
la clé symétrique a donc été échangée en toute sécurité,
4 – Alice envoie la proposition chiffrée à Bob,
5 – Bob déchiffre les données reçues avec sa clé privée et récupère la clé symétrique
proposée par Alice, les données chiffrées avec la clé publique de Bob ne pouvant
t e d hiff es u’ave la l p iv e de Bob, l’authentification du destinataire est
assurée,
6 – Alice écrit un message pour Bob, et le chiffre avec la clé symétrique générée
auparavant,
8 – Bob déchiffre le message reçu avec la clé symétrique, les calculs nécessaires pour
chiffrer et déchiffrer le message consomment peu de ressources, accélérant la
vitesse de traitement.
Pour éviter que la clé symétrique puisse être cassée (par un individu mal intentionné
écoutant les échanges de messages chiffrés), elle a une durée de vie. La clé
symétrique échangée en toute sécurité selon le mécanisme ci-dessus, est nommée
l de sessio . Lo s u’elle expi e, u e ouvelle sessio doit t e go i e.
107
• Contrôle d’intégrité
Alice 2. Crée Message Bob
3. Calcule le haché du message
4. Chiffre le message et son haché
5. Transmet [ + ]
6. Déchiffre ( [ + ])= +
7. Calcule le haché du message
8. Compare le haché calculé et le haché reçu
OBJECTIFS
10
Chiffrement asymétrique et intégrité
0 – Bob crée une bi- l as t i ue, o pos e d’u e pa tie pu li ue l pu li ue

et d’u e pa tie p iv e l p iv e ,
2 – Alice écrit un message pour Bob,
3 – Alice calcule le haché de ce message,
4 – Alice chiffre le message et son haché pour Bob avec la clé publique de ce dernier,
la confidentialité du message est assurée par le chiffrement,
6 – Bob déchiffre le message reçu et son haché avec sa clé privée, le message chiffré
avec la clé publique de Bob e pouva t t e d hiff u’ave la l p iv e de Bob,
l’authentification du destinataire est assurée,
7 – Bob calcule le haché du message reçu,
8 – Bob o pa e les 2 ha h s, s’ils so t ide ti ues, l’intégrité du message est
assu e il ’a pas t alt lo s de so t a spo t .
La fonction de hachage est une fonction unidirectionnelle (irréversible) qui lie un

code unique = haché (ou condensat, empreinte, hash, message digest) à un message.
Il est impossible de retrouver le message depuis le haché, qui a une taille fixe. De
plus, uel ue soit la lo gueu du essage d’o igi e, la valeu du ha h est u i ue. Si
une quelconque modification, même mineure, est appliquée au message, la valeur
du haché devient complètement différente de celle du précédent message.
Les algorithmes de hachage les plus utilisés sont SHA1 et SHA2.
108
• Signature numérique
2. Crée Message et son haché
3. Chiffre haché (clé privée Alice)
4. Transmet +
Alice 5. Déchiffre haché ( )= Bob

OBJECTIFS
11
Signature numérique
0 – Alice crée une bi- l as t i ue, o pos e d’u e pa tie pu li ue l

1 – Alice envoie sa clé publique à Bob,
2 – Alice écrit un message pour Bob, et calcule son haché,
3 – Alice chiffre le haché du message avec sa clé privée, ce haché ne pouvant être
d hiff u’ave la l pu li ue d’Alice, l’authentification de l’é etteur du
message est assurée,
4 – Alice envoie le message en clair, et son haché chiffré à Bob,
5 – Bob d hiff e le ha h eçu ave la l pu li ue d’Alice,
6 – Bob compare le haché déchiffré et le haché calculé depuis le message reçu,
s’ils so t ide ti ues, l’intégrité du essage est assu e il ’a pas t alt lo s
de son transport).
La signature numérique consiste à chiffrer le haché d’u message avec la clé

privée de l’ etteu , garantissant à la fois l’i t g it du message et
l’authe tifi atio de son émetteur. En effet, sans chiffrement du haché, une
personne malveillante peut altérer le message et recalculer son haché à partir
du nouveau message.
109
• Signature numérique et chiffrement

3. Crée Message et son haché
4. Chiffre message (clé publique Bob)
5. Chiffre haché (clé privée Alice)
Alice 6. Transmet + Bob
7. Déchiffre message ( )=
8. Déchiffre haché ( )=
OBJECTIFS
12
Signature numérique et chiffrement
0 – Alice et Bob créent chacun une bi- l as t i ue, o pos e d’u e pa tie
pu li ue l pu li ue et d’u e pa tie p iv e l p iv e ,
2 – Alice envoie sa clé publique à Bob,
3 – Alice écrit un message pour Bob, et calcule son haché,
4 – Alice chiffre le message pour Bob avec la clé publique de ce dernier, la
confidentialité du message est assurée par le chiffrement,
5 – Alice chiffre le haché pour Bob avec sa clé privée, ce haché ne pouvant être
d hiff u’ave la l pu li ue d’Alice, l’authentification de l’é etteur du
message est assurée,
6 – Alice envoie le message, et son haché, chiffrés à Bob,
7 – Bob déchiffre le message reçu avec sa clé privée, le message chiffré avec la clé
publique de Bob e pouva t t e d hiff u’ave la l p iv e de Bob,
l’authentification du destinataire est assurée,
8 – Bob d hiff e le ha h eçu ave la l pu li ue d’Alice,
9 – Bob o pa e le ha h d hiff et le ha h al ul ave le essage eçu, s’ils
so t ide ti ues, l’intégrité du essage est assu e il ’a pas t alt lo s de so
transport).
110
La signature numérique consiste à chiffrer le haché d’u message avec la clé privée
de l’ etteu , garantissant à la fois l’i t g it du message et l’authe tifi atio de
son émetteur. En effet, sans chiffrement du haché, une personne malveillante peut
altérer le message et recalculer son haché à partir du nouveau message. De plus, le
chiffrement effectué avec la clé publique du destinataire permet d’assu e la
confidentialité du message et l’authe tifi atio du destinataire, sa clé privée étant
utilisée pour le déchiffrement.
111
INFRASTRUCTURES À
CLÉS PUBLIQUES
Programme du module

✔ Les types de chiffrement
➔ Infrastructures à clés publiques
112
PKI : INFRASTRUCTURE À CLÉS PUBLIQUES
• Génération d’un certificat auto-signé
1. Alice Génère clé privée et clé publique

2. Renseigne les informations relatives à son identité
3. Regroupe ces informations et sa clé publique
4. Calcule le haché de ce regroupement
5. Chiffre le haché avec sa clé privée
15
Certificat auto-signé
1. Alice crée une bi- l as t i ue, o pos e d’u e pa tie pu li ue l
2. Ali e e seig e l’e se le des i fo atio s pe etta t de l’ide tifie ,
3. Alice regroupe ces informations et sa clé publique dans un fichier structuré,
4. Ali e al ule le ha h de l’e se le de es do es,
5. Alice chiffre le haché avec sa clé privée (signature numérique).
6. Le fichier obtenu est un certificat auto-signé, et contient entre autres
l’algo ith e de sig atu e utilis et les ha h s sulta ts selo les diff e ts
algo ith es hoisis lo s de l’op atio .
Le certificat auto-sig ide tifie u e pe so e da s l’exe ple i-dessus, un système
ou un équipement.
Remarquez que le champ « Subject » et le champ « Issued by » sont identiques, ce
qui est toujours le cas pour un certificat auto-signé.
Alice peut transmettre son certificat à ses correspondants, afin que ces derniers
puissent l’authe tifie , en revanche, elle ne doit jamais transmettre sa clé privée à
quiconque.
L’e se le [clé privée + certificat] représente l’ide tit numérique d’u e personne.
Inconvénients
• En cas de perte ou de vol de son ordinateur, Alice ’a plus accès à sa clé privée,
• La gestion d’u grand nombre d’utilisateu s en entreprise ne peut pas s’appu e
sur des certificats auto-signés,
• Les personnes d’u e organisation doivent avoir une relation de confiance avec
Alice pour utiliser son certificat.
113
• Gestion des certificats par une autorité de certification

Demande externe Création d’une identité
Autorité de
certification
Publication des certificats
1. Certificat auto-signé 1. Génère bi-clé et

certificat de Bob
Demande de certificat (CSR)

2. Envoie son identité à Bob Identité de Bob
dans un fichier protégé
Alice 2. Vérifie et émet par mot de passe
Détentrice de
la clé privée
3. Publie les certificats et la CRL
Certificat
d’Alice
Bob
Liste des
certificats
révoqués
(CRL)
LDAP
16
PKI
Autorité de certification (Certification Authority)

Une autorité de certification est un tiers de confiance permettant dans un
périmètre défini (Entreprise, Agence, Continent,…) de gérer les certificats, voire
les identités numériques de toutes les entités (personnes, systèmes,
équipements) amenées à échanger entre elles de manière sécurisée.
Elle est garante de l’authe ti it des certificats et de leur contenu, justifiant ainsi
la relation de confiance envers cette CA et les différents utilisateurs. En effet, sur
présentation d’u certificat, il est vérifié u’il est acceptable en s’appu a t sur la
validité de la signature de ce certificat par la CA.
L’auto it de certification signe (atteste de la validité de) les certificats ainsi que la
liste des certificats révoqués (CRL : Certificate Revocation List).
Certaines architectures peuvent inclure des sous autorités qui sont sous la
responsabilité d’u e autorité racine (CA root).
Demande externe
1 – Alice envoie une demande de certificat (CSR = Certificate Signing Request) à la
CA,
2 – La CA vérifie l’authe ti it de l’ide tit du de a deu , et et u e tifi at
signé pour Alice,
3 – La CA publie le certificat sur un annuaire, pour le rendre visible à tous..
114
Création d’une identité numérique

1 – La CA e pou l’utilisateu Bob une bi- l as t i ue, o pos e d’u e
pa tie pu li ue l pu li ue et d’u e pa tie p iv e l p iv e , e seig e les
informations relatives à Bob, puis génère et signe un certificat pour Bob,
2 – La CA g e u fi hie o te a t l’ide tit u i ue de Bob, protège ce
fi hie pa ot de passe puis u’il o tie t la l p iv e de Bob, et lui envoie
(exemple de fichier .p12) ,
3 – La CA publie le certificat sur un annuaire, pour le rendre visible à tous.
La CA est également responsable de relayer, après vérification, les demandes de

révocation.
NOTE
Une CSR contient un certificat auto-signé pour faciliter le travail de
l’ad i ist ateu de la CA : vérification de l’i t g it de la demande, par
conséquent vérification de la validité de la bi-clé du demandeur (clé publique +
clé privée), la clé publique proposée dans la CSR permettant de vérifier que la
signature numérique du demandeur (décrit sur la page précédente) est correcte
115
• Format des certificats

Défini par la norme X509, un certificat
contient :
• Version et numéro de série du certificat
• Algorithme et valeur de la signature du
certificat
• Issuer : DN (Distinguished Name) de la
CA
• Période de validité (date de début et
date de fin)
• DN du détenteur du certificat
• Informations sur la clé publique (clé
publique et algorithme)
• Possibles extensions qui conditionnent
l’usage du certificat, par exemple liste
des points de distribution de la CRL
(CRLDP)
18

L’i f ast u tu e qui héberge les informations publiques (annuaire, CRL) et qui
permet d’a de aux certificats de l’o ga isatio , d’effe tue un renouvellement
de certificat, ou de le révoquer est nommée PKI (Public Key Infrastructure).
Un certificat peut contenir du texte (extensions .pem, .crt) ou des données
binaires directement (extensions .cer, .der).
La validité du certificat est remise en cause à l’expi atio de ce dernier (limitation

dans le temps), ou de l’expi atio de la CA ; en cas de perte ou de vol de la clé
privée du propriétaire, en cas de départ du propriétaire de la société.
Liste des certificats révoqués

La CRL est un fichier signé par la CA, qui liste les numéros de série des certificats
révoqués avant leur expiration. Cette liste doit être accessible publiquement pour
permettre aux utilisateurs de s’assu e que les identités qui leur sont présentées
sont encore valides.
Stockage des identités numériques par la CA

Lorsque la CA génère les bi-clés, il est simple de contrôler la robustesse des clés
et de les sauvegarder, mais cela nécessite la mise en place d’u e procédure
sécurisée pour délivrer son identité à un utilisateur final. Il existe pour cela un
container protégé standardisé nommé PKCS#12 qui contient traditionnellement :
[clé privée du porteur + certificat du porteur (contenant sa clé publique) +
certificat de la CA signataire].
116
PKI STORMSHIELD
NETWORK
Programme du module

✔ Infrastructures à clés publiques
➔ PKI Stormshield Network
117
PKI STORMSHIELD NETWORK
• Usages de la PKI sur les firewalls Stormshield

Authentification d’utilisateurs VPN SSL et IPsec
1. Présentation du certificat utilisateur
2. Vérification de l’identité via le LDAP
3. Attribution des listes d’accès
Authentification de serveurs/clients pour session SSL/TLS

1. Présentation du certificat serveur
2. Présentation du certificat client (optionnel)
3. Négociation d’une session chiffrée

20

Les firewalls Stormshield intègrent les fonctions permettant la gestion des certificats,
et ce, sur l’e se le des produits SNS de la gamme.
Authentification d’utilisateurs
1. L’utilisateu mobile, ou l’ad i ist ateu de l’i te fa e web, souhaitant
s’authe tifie auprès du firewall présente son certificat utilisateur, soit par son
navigateur web, soit par son client VPN IPsec,
2. Le firewall vérifie la validité du certificat et contrôle l’ide tit de l’utilisateu sur
le serveur LDAP,
3. Les politiques d’a s attachées à cet utilisateur peuvent alors lui être
appliquées, pour permettre l’a s aux ressources réseau internes.
Authentification de serveurs (et / ou de clients)

1. Le serveur, lors de l’i itialisatio d’u e session, présente son certificat serveur au
client, lequel vérifie sa validité,
2. Éventuellement, le client présente son certificat client au serveur, lequel vérifie
sa validité. Lorsque cette étape est présente, il s’agit d’u e session avec
authentification mutuelle ’est le cas par exemple d’u e session TCP/TLS entre le
firewall client et le serveur Syslog Stormshield Visibility Center),
3. Après l’authe tifi atio , le client et le serveur négocient une clé de session.
118
• Usages de la PKI sur les firewalls Stormshield

Authentification de passerelles IPsec
1. Présentation du certificat initiator
2. Présentation du certificat responder
3. Vérification du groupe de CA de confiance
4. Vérification de l’identité de la passerelle (optionnel)
21
Authentification de passerelles IPSec

1. Lors de la phase d’ ta lisse e t du tunnel, le firewall qui initie le tunnel
(Initiator) présente son certificat à la passerelle distante, laquelle vérifie sa
validité,
2. Le firewall qui répond (Responder) présente son certificat à la passerelle
distante, laquelle vérifie sa validité,
3. Outre les vérifications effectuées sur la validité des certificats présentés
(intégrité, signature numérique, période de validité,...), le certificat de l’auto it
de certification ayant signé le certificat de la passerelle distante doit appartenir
au groupe de confiance de CA, ’est-à-dire aux autorités de certification
acceptées dans la politique VPN Ipsec,
4. La vérification de l’ide tit de la passerelle distante permet de garantir que le
tunnel est monté avec la passerelle identifiée par le certificat, ce point optionnel
ne peut être défini u’e CLI.
119
• Gestion des certificats

CA interne
– Le firewall agit en tant qu’autorité de certification racine (root CA)
• Son certificat d’autorité est auto-signé,
• Exemple : autorité par défaut disponible ayant signé un certificat
serveur et un certificat client utilisés par le VPN SSL
– Le firewall agit en tant que sous-autorité de certification
• Son certificat est signé par l’autorité parente (pas nécessairement
une autorité racine), laquelle est une autorité interne ou externe
Génère et signe signe
Identité CA racine
Certificat sous-CA
CA racine
Génère et signe signe
Ide tit s se veu , utilisateu ,… Ce tifi ats se veu , utilisateu ,…

Sous-CA interne 22
CA interne
Cette fonctionnalité de gestion d’u e infrastructure à clés publiques permet de
répondre à un grand nombre de cas d’usage :
• Autorité de certification racine : Le boîtier SNS permet de définir les chaînes de
confiance nécessaires à une authentification par certificat. Des autorités par
défaut sont disponibles pour signer les certificats utilisés par le proxy SSL ou livrer
les certificats nécessaires au fonctionnement du VPN SSL.
Les fonctions proposées par le boitier SNS permettent de répondre pleinement au
rôle d’auto it de certification (création de certificat de différentes natures,
signature de CSR, révocation de certificat et gestion de CRL).
• Sous-autorité de certification : il est possible de définir un boitier SNS comme
étant une sous-autorité de certification d’u e CA parente. Une fois que le
certificat de la sous-autorité est signé par l’auto it parente et importé dans le
boîtier (dans le cas d’u e CA externe), cela permet d’o ga ise plus finement la
répartition et la distribution des identités, par usages ou par entités d’u e même
entreprise.
120
• Gestion des certificats

CA externe
– Le firewall agit en tant que PKI en permettant l’import de

certificats, voire d’identités (protégées par des fichiers de type
PKCS#12), émis par une CA externe
– Les certificats importés sont accessibles aux modules requérant

une authentification par certificats (interface d’administration,
VPN SSL, VPN Ipsec,…)
23
CA externe
Dans le cadre d’usage d’u e CA externe, les fonctionnalités proposées permettent
essentiellement d’i po te des certificats et de définir les relations de confiance
pour divers usages :
• Import de certificats d’auto it de certification.
• Import de certificats d’ uipe e ts.
• Import de certificats et de clés privés d’ uipe e ts (fichiers .p12 protégés ou
pas par mot de passe).
121
• Écrans de gestion des certificats et PKI
24
L’ a du module Certificats et PKI se divise en trois parties :

• En haut de l’ a , les différentes actions possibles sous forme d’u e barre de
recherche et de boutons.
• A gauche, la liste des autorités et des identités ou certificats.
• A droite, les détails concernant l’auto it ou le certificat sélectionné au préalable
dans la liste de gauche, ainsi que les informations concernant la CRL et la
configuration de la CA ou sous CA.
La barre de recherche
Si vous recherchez un certificat ou une CA existante en particulier, saisissez son nom.
Le champ de recherche vous permet de lister tous les certificats et les CA dont le
nom correspond aux mots clés saisis.
Exemple :
Si vous saisissez la lettre « a » dans la barre de recherche, la liste en dessous fera
apparaître tous les certificats possédant un « a ».
122
La zone de filtre
Cette zone permet de choisir le type de certificat à afficher et de ne voir que les
éléments qui vous intéressent. Un menu déroulant vous propose les choix suivants :
Affiche dans la liste de gauche, toutes les autorités et

Tous
certificats préalablement créés.
Affiche dans la liste de gauche, toutes les autorités et sous-

Autorités
autorités.
Certificats Affiche uniquement les certificats utilisateur et les CA dont ils

utilisateur dépendent.
Certificats Affiche seulement les certificats serveur et les CA dont ils

serveur dépendent.
Certificats Affiche uniquement les certificats Smartcard et les CA dont ils

Smartcard dépendent.
Les assistants de configuration

Cette zone permet de démarrer les assistants d’ajout d’ l e ts dans les objets
Certificats et PKI :
Lance l’assista t permettant de créer une autorité de
Ajouter une
certification racine gérée par le firewall. Cette autorité peut
autorité racine
être une sous-autorité d’u e PKI externe.
Lance l’assista t permettant de créer une autorité de
Ajouter une
certification dépendant d’u e autre CA. L’auto it parente doit
sous-autorité
être gérée par le boitier.
Ajouter une
Lance l’assista t permettant de créer une identité utilisateur
identité
dépendant d’u e autorité de certification gérée par le boitier.
utilisateur
Ajouter une Lance l’assista t permettant de créer une identité serveur

identité serveur dépendant d’u e autorité de certification gérée par le boitier.
Ajouter une
Lance l’assista t permettant de créer une identité Smartcard
identité
dépendant d’u e autorité de certification gérée par le boitier.
Smartcard
Importer un Le fichier importé peut être une identité, un certificat, une

fichier CRL.
123
CRÉATION D’UNE
AUTORITÉ DE
CERTIFICATION
Programme du module

✔ PKI Stormshield Network
➔ Création d’u e autorité de certification
124
CRÉATION D’UNE AUTORITÉ DE CERTIFICATION
• Création d’une autorité de certification : étape 1

Autorité racine Sous-autorité
27
Création d’une autorité de certification (C.A.) – 1ère étape

Vous devez définir les propriétés de l’auto it que vous souhaitez ajouter :
AVERTISSEMENT
Ces informations ne sont plus modifiables après leur création.
Saisissez un nom permettant d’ide tifie l’auto it de

CN
certification (64 caractères au maximum)
Permet de définir un raccourci de l’att i ut CN (champ
Identifiant
optionnel)
Pour une sous-autorité, permet d’i di ue l’auto it de
Autorité parente certification parente (forcément créée au préalable
puisqu'elle va signer le certificat de la sous-autorité)
Mot de passe Obligatoire pour valider la signature du certificat de la
autorité parente sous-autorité en cours de création
Organisation (O) Nom de l’o ga isatio
Unité d’organisation
Branche au sein de l’o ga isatio
(OU)
Lieu (L) Ville où est située l’o ga isatio
Etat ou province (ST) Département ou état où est située l’o ga isatio
Pays (C) Pays où est située l’o ga isatio
125
28
Création d’une autorité de certification - 2ième étape

Saisissez un mot de passe de 8 caractères minimum afin de protéger
l’a s à la clé privée de votre CA.
Mot de passe (8
AVERTISSEMENT
car. Min.)
Ce mot de passe ’est pas récupérable sur le firewall. Si vous l’ou liez,
vous ne pourrez plus signer de certificats ou de CRLs avec cette CA.
Confirmez le mot Tapez une seconde fois votre mot de passe dans ce champ afin de le
de passe confirmer.
Ce champ indique le niveau de sécurité de votre mot de passe .
Force du mot de
Il est fo te e t o seill d’utilise des ajus ules, i us ules,
passe
chiffres et caractères spéciaux.
E-mail Renseignez l’ad esse e-mail du gestionnaire de la CA (optionnel).
Choix de la taille de la clé. Plus la taille de la clé est grande, plus les
Taille des clés
opérations réalisées avec cette clé sont sécurisées.
(bits)
Il existe 4 tailles de clés possibles : 1024, 1536, 2048 et 4096 (bits)
Ce champ correspond au nombre de jours durant lesquels votre
certificat d'autorité et par conséquent votre PKI seront valides.
Validité (jours)
Une fois ce certificat expiré, tous les certificats émis sont considérés
comme invalides. Cette valeur ’est pas modifiable par la suite.
126
29
Création d’une autorité de certification - 3ième étape

Vous pouvez indiquer les points de distribution (URL) de la liste des

certificats révoqués (invalides).
Distribution de la
AVERTISSEMENT ces CRLDP sont visibles dans tous les certificats
CRL
signés par cette CA. L’ uipe e t ne maintient pas à jour
automatiquement le fichier CRL disponible à ces emplacements.
127
• Autorité de certification par défaut
30
Définir une autorité de certification en tant u’autorité par défaut

1. Mettez l’auto it souhaitée en surbrillance,
2. Dans le menu Action, cliquez sur Définir comme défaut, l’auto it par défaut
apparaît en vert à l’affi hage.
Nous verrons plus tard dans ce module u’il est possible de générer une identité
utilisateur directement depuis l’a uai e LDAP interne du firewall.
Dans ce cas, le choix de l’auto it signataire se porte automatiquement sur la CA
désignée par défaut.
128
CRÉATION D’UNE
IDENTITÉ SERVEUR
Programme du module

✔ Création d’u e autorité de certification
➔ Création d’u e identité serveur
129
CRÉATION D’UNE IDENTITÉ SERVEUR
• Création d’une identité serveur : étape 1
32
Création d’une identité serveur – 1ère étape

Vous devez définir les propriétés de l’ide tit serveur que vous souhaitez ajouter :
Saisissez le nom de domaine pleinement qualifié du serveur

Nom de
pour lequel il faut générer l’ide tit . Ce paramètre est
domaine
inscrit comme CN dans le certificat correspondant. Il doit
pleinement
généralement coïncider avec le nom DNS du serveur auquel
qualifié (FQDN)
il est destiné et dont il représente l’ide tit .
Permet de définir un raccourci de l’att i ut FQDN (champ
Identifiant
optionnel).
130
33
Création d’un certificat serveur – 2ième étape

Il s’agit de choisir l’auto it de certification à utiliser pour le certificat serveur :
Permet de choisir l’auto it de certification qui génère

l’ide tit serveur et qui va signer le certificat
Autorité de
correspondant.
certification (CA)
Il est possible de choisir l’auto it de certification parmi
toutes celles dont l’ide tit est stockée sur le firewall.
Saisir le mot de passe de l’auto it de certification
Mot de passe de
permet l’a s à sa clé privée utilisée pour signer le
l’autorité
certificat serveur.
Attributs du Il s’agit d’i fo atio s pré-remplies en fonction de

certificat l’auto it de certification sélectionnée.
131
34

Vous devez définir ici la durée de validité du certificat que vous ajoutez :
Durée de validité du certificat serveur. Par défaut, cette

Validité
valeur est fixée à 365 jours.
Définir la taille de clé à utiliser pour les chiffrements

Taille de clé (bits) asymétriques faisant intervenir l’ide tit serveur en cours de
création. Par défaut, cette valeur est fixée à 2048 bits.
132
35

Vous pouvez ajouter au certificat du serveur qui va être signé par la CA des noms DNS
différents (attribut Subject Alternative Name dans un certificat).
Le caractère * (wildcard) ’est pas accepté ici.
133
• Création d’une identité serveur : récapitulatif
36
Création d’un certificat serveur – récapitulatif

Avant de valider la création de l’ide tit du serveur, vérifiez attentivement l’e se le
des informations saisies.
Les noms DNS différents (attribut Subject Alternative Name dans le certificat
correspondant à cette identité) ’appa aisse t pas dans le récapitulatif.
134
CRÉATION D’UNE
IDENTITÉ UTILISATEUR
Programme du module

✔ Création d’u e identité serveur
➔ Création d’u e identité utilisateur
135
CRÉATION D’UNE IDENTITÉ UTILISATEUR
• Création d’une identité utilisateur : étape 1
38
Création d’une identité utilisateur – 1ère étape

Vous devez définir les propriétés d’ide tit de l’utilisateu que vous souhaitez
ajouter :
NOTE
Une fois le certificat généré et publié par l’ad i ist ateu , l’ide tit numérique de
l’utilisateu doit lui être transmise par une voie sécurisée.
Saisissez le nom de l’utilisateu dans la limite de 64

CN
caractères maximum.
Permet de définir un raccourci de l’att i ut CN (champ

Identifiant
optionnel).
Renseigner l’ad esse e-mail de l’utilisateu . Cette information
peut être utilisée pour identifier l’utilisateu lo s u’il
Mail présente son certificat.
Ce champ est obligatoire.
136
39
Création d’une identité utilisateur – 2ième étape

Choisir l’auto it de certification à utiliser pour signer le certificat utilisateur :
Permet de choisir l’auto it de certification signataire du

certificat utilisateur.
Il est possible de choisir l’auto it de certification parmi
Autorité de toutes celles dont la clé privée est stockée dans les objets
certification (CA) PKI.
L’assista t de configuration présélectionne l’auto it de

certification par défaut.
Saisir le mot de passe de l’auto it de certification permet
Mot de passe de
l’a s à sa clé privée utilisée pour signer le certificat
l’autorité
utilisateur.
Il s’agit d’i fo atio s pré-remplies en fonction de
Attributs du
l’auto it de certification sélectionnée ou désignée par
certificat
défaut.
137
40
Création d’une identité utilisateur – 3ième étape
Durée de validité du certificat utilisateur. Par défaut, cette

Validité
valeur est fixée à 365 jours.
Définir la taille de clé à utiliser pour les chiffrements

Taille de clé (bits) asymétriques faisant intervenir l’ide tit utilisateur en cours
de création. Par défaut, cette valeur est fixée à 2048 bits.
En cochant cette case, une copie du certificat est stockée
dans l’a uai e LDAP et ainsi mise à disposition pour
téléchargement à partir du portail captif; ce qui facilite sa
Publier ce certificat distribution.
dans l’annuaire Pour pouvoir utiliser cette option, il est impératif, que
LDAP l’ide tifia t (ID) et l’ad esse email saisis soient identiques à
ceux d’u utilisateur existant dans la base LDAP (interne ou
externe) avec laquelle le firewall est connecté (comme dans
l’exe ple ci-dessus).
138
Le container PKCS#12 contient l ’ide tit de l’utilisateu ,

Mot de passe du
ainsi que le certificat de l'autorité de certification signataire
container PKCS#12
Renseignez un mot de passe afin de protéger ces
publié
informations sensibles.
Confirmez le mot de Retapez une seconde fois votre mot de passe dans ce champ
passe afin de le confirmer.
Ce champ indique le niveau de sécurité de votre mot de
passe : « Très Faible », « Faible », « Moyen », « Bon » ou
Force du mot de
« Excellent ».
passe
Il est fo te e t o seill d’utilise les ajus ules et les
caractères spéciaux.
139
• Création d’une identité utilisateur : récapitulatif
42
Création d’une identité utilisateur – récapitulatif

Avant de valider la création de l’ide tit de l’utilisateu , vérifiez attentivement
l’e se le des informations saisies.
Après validation de la création, la bi-clé est générée, le certificat est signé et tous
deux sont stockés localement sur le firewall dans les objets CERTIFICATS ET PKI ; une
copie du certificat est publiée dans la base LDAP lorsque l’optio correspondante a
été demandée.
140
• Création d’une identité utilisateur via LDAP :
43
Création d’une identité utilisateur à partir de sa fiche LDAP

Il est possible de déclencher la génération d’u e identité utilisateur directement à
partir de l’a uai e LDAP.
Le choix de la CA se porte automatiquement sur la CA désignée par défaut :
• La publication du certificat utilisateur dans la base LDAP est immédiate,
• L’ide tit de l’utilisateu est ajoutée dans les objets CERTIFICATS ET PKI.
Note
• Lorsque l’a uai e est un LDAP de type Active Directory, l’a s en lecture/écriture
utilisant un compte ayant suffisamment de droits est requis pour publier les
certificats sur l’a uai e.
141
• Création d’une identité utilisateur via LDAP : résultat
• Vue du
certificat dans
l’annuaire
Vue de l’identité dans la CA
44
Le certificat correspondant est obligatoirement signé par la CA par défaut, le CN du

certificat est identique au CN de l’utilisateu tel u’il est défini dans la base LDAP.
142
GESTION DES IDENTITÉS

ET CERTIFICATS
Programme du module

✔ Création d’u e identité utilisateur
➔ Gestion des identités et certificats
143
GESTION DES IDENTITÉS ET CERTIFICATS
• Autorité de certification interne :
46
Menu Actions
Pour une autorité de certification interne (créée sur le firewall), les actions suivantes
sont possibles :
• Créer / Renouveler la CRL : Lo s u’u e autorité de certification est créée, vous
pouvez créer la CRL, puis la renouveler ultérieurement. Le renouvellement de la
CRL est automatique sur le firewall (une fois par mois), mais pas la maintenance
des éventuels points de distribution (CRLDP) aux emplacements où ils ont été
définis.
• Supprimer la CRL : il est possible de supprimer la CRL.
• Définir comme défaut : lors de la création d’u e identité utilisateur depuis sa
fiche LDAP, l’a uai e défini par défaut est automatiquement utilisé. L’optio est
grisée dans l’exe ple ci-dessus car l’auto it de certification en surbrillance est
déjà l’auto it par défaut.
Menu Télécharger
• Certificat : le format d’expo t contient des données en base64 (.pem) ou des
données binaires (.der)
• CRL : le fichier de CRL exporté permet de maintenir les CRLDP externes (même
format d’expo t que pour les certificats).
144
GESTION DES IDENTITÉS ET CERTIFICATS
• Identités et certificats serveurs et utilisateurs:
47
Menu Actions
Pour un serveur ou un utilisateur, les actions suivantes sont possibles :
• Supprimer la clé privée : l’ide tit du serveur ou de l’utilisateu est stockée sur le
firewall. Après suppression de la clé privée, il reste seulement le certificat, les
icônes utilisées sont différentes, comme illustré ci-dessus.
• Publication LDAP (utilisateur uniquement) : lorsque le certificat d’u utilisateur
est présent sur le firewall, il peut être publié sur l’a uai e, si les champs ID (login)
et adresse e-mail correspondent, comme détaillé dans le chapitre « Création d’u e
identité utilisateur ».
Menu Télécharger
• Certificat : le format d’expo t contient des données en base64 (.pem) ou des
données binaires (.der). Le fichier exporté contient le certificat du porteur mais
également les certificats des autorités présentes dans la chaîne de confiance de ce
certificat.
• Identité : l’ide tit , puis u’elle contient une clé privée, est sensible et son export
doit être protégé par un mot de passe, lequel permet de chiffrer la clé privée u’il
contient. L’ide tit est pour rappel constituée de la clé privée du porteur, de son
certificat (qui contient sa clé publique), et des certificats de la chaîne de confiance.
le fichier d’expo t est un container .pem ou un container PKCS#12 (ou .p12).
145
RÉVOCATION DE
CERTIFICATS ET CRL
Programme du module

✔ Création d’u e identité utilisateur
✔ Gestion des identités et certificats
➔ Révocation de certificats et CRL
146
RÉVOCATION DE CERTIFICATS ET CRL
• Révocation d’un certificat utilisateur :
49
Révocation d’un certificat utilisateur

La révocation d’u certificat peut être nécessaire pour les raisons suivantes :
• la clé privée de l’utilisateu a été perdue ou volée,
• l’utilisateu change de fonction (son Unité d’O ga isatio (OU) est modifiée par
exemple),
• l’ide tit a été renouvelée l’a ie certificat ’est plus valide),
• Autres…
Révoquer le certificat
1. Mettez l’utilisateu souhaité en surbrillance,
2. Cliquez sur le menu Révoquer,
3. Tapez le mot de passe de la CA et choisissez la raison de la révocation,
4. Téléchargez la CRL (ré)générée et signée par la CA dès la fin de la révocation,
5. Si une copie du certificat utilisateur est stockée dans l’a uai e LDAP, cliquez sur
le bouton Supprimer.
147
• Liste de révocation des certificats
50
Liste de Révocation de Certificats

La CRL contient la liste des numéros de série des certificats révoqués.
La CRL est signée par la CA et possède également une période de validité (de un mois
par défaut).
L’ad i ist ateu a la responsabilité de diffuser et publier la CRL sur les points de
distribution renseignés lors de la création de l’Auto it .
ATTENTION : cette liste est vérifiée dès lors u’elle est présente sur le firewall.
ELLE DOIT TOUJOURS ÊTRE EN COURS DE VALIDITÉ.
Si la période de validité de la CRL est expirée, la vérification des certificats révoqués

’est plus valable, l’e se le des certificats issus de la CA correspondante ne
peuvent plus être considérés comme valides.
148
• CRL d’une CA externe
51
Maintien de la CRL d’une CA externe

Lorsque le certificat d’u e CA externe est importé sur le firewall, il est possible
d’ajoute une liste de CRLDP sur lesquels la présence d’u e nouvelle CRL est vérifiée
toutes les 24 heures.
Pour assurer cette vérification, Il est impératif :

• De créer l’o jet correspondant au nom d’hôte mentionné dans l’URL saisie,
• Que le nom du fichier de CRL géré par l’ad i ist ateu de la CA externe soit
identique à celui renseigné dans l’URL.
La vérification s’effe tue uniquement sur les URL saisies sur le firewall, et non sur les
éventuels CRLDP présents dans le certificat de la CA externe.
NOTE
Le démon VPN IPSec charon utilisé par le firewall Stormshield a la possibilité
d’effe tue dynamiquement une requête avec le protocole OCSP (Online Certificate
Status Protocol) vers le serveur hébergeant la CRL, au lieu de devoir télécharger le
fichier correspondant.
149
• Utiliser une IGC maitrisée, si possible externe au SNS
• Imposer la vérification des CRL dans IPSec
• Configurer l’URL de la CRL et activer la récupération

automatique
52
Il est recommandé d’utilise une IGC (Infrastructure de Gestion de Clés ou PKI)

externe au SNS. Ainsi en cas de compromission de l’ uipe e t, seules les clés
utilisées pour le fonctionnement de celui-ci sont compromises. De plus, cela permet
d’utilise des clefs basées sur les courbes elliptiques.
Par défaut IPSec ne vérifie pas la révocation des certificats. Pour imposer la
vérification des CRL pour le profil 1, il faut utiliser les commandes NSRPC suivantes :
config ipsec update slot=01 CRLrequired=1
config ipsec activate
Faites attention à ce que la CRL soit bien bien accessible lors de l’ ta lisse e t de la
connexion.
Il est recommandé de configure les points de récupération de la CRL pour chaque

CA. Sans cela les certificats révoqués ne seront pas connus du SNS. La récupération
automatique se configure dans Configuration > System > Configuration >
Configuration générale dans la zone Paramètres cryptographiques.
150
LAB 5 – PKI
53

• SDS Easy : intégrer une PKI SNS dans un client SDS

151
PROXY SSL
CSNE - STORMSHIELD NETWORK SECURITY – VERSION 4.X

✔ Infrastructure à clés publiques
➔ Proxy SSL
VPN IPsec avancé
152
Proxy SSL
FONCTIONNEMENT
PROXY SSL
Programme du module
➔ Fonctionnement
Configuration
Exemples d’utilisatio
153
Proxy SSL
FONCTIONNEMENT : L’OUVERTURE D’UNE SESSION TLS
TCP handshake
Client Hello: SNI=www.google.com
Server Hello
Verifying the certificate Server Certificate
presented by the server: Server Hello done
• SNI=cn ou Altnames
• Validity
• Signed by a trusted CA
Client Key Exchange: [pre-master secret]server_pub_key
Change Cipher Spec
Generate session key K Finished: [client finished]K
using pre-master secret Generate session key K
Change Cipher Spec using pre-master secret
Finished: [server finished]K
K K
IP TCP TLS HTTP DATA

Encrypted
Actuellement, plusieurs services réseaux (web, mail, chat, transfert de fichiers, etc.)
utilisent le protocole TLS (Transport Layer Security), plus connu par son ancien nom
SSL (Secure Sockets Layer), pour authentifier les correspondants et chiffrer leurs
communications. Le protocole TLS a été standardisé par l’IETF depuis 1999 et la
dernière version TLSv1.3 a été publiée en 2018 dans la RFC 8446. Les firewalls SNS
supportent les versions TLSv1.0, TLSv1.1 et TLSv1.2.
Le protocole TLS peut fonctionner au-dessus du protocole de transport TCP ou UDP.

Avec une session TLS, l’authe tifi atio est basée sur les certificats (PKI) et les
données sont chiffrées par un algorithme symétrique dont la clé est calculée durant
l’ouve tu e de la session TLS.
La figure ci-dessus détaille l’ouve tu e d’u e session TLS dans le cas d’u e connexion
HTTPS avec une authentification du serveur seulement et un échange de clés basé
sur RSA :
1. TCP Handshake : le client commence par ouvrir une connexion TCP (SYN,
SYN+ACK et ACK) à destination du serveur sur le port TCP/443.
2. Client Hello : le client initie la session TLS en envoyant une commande « Client
Hello » dans laquelle il spécifie les algorithmes cryptographiques supportés
(chiffrement, hachage, etc.), les algorithmes de compression supportés et
différentes extensions. Parmi ces extensions, le SNI (Server Name Indication)
indique le nom du serveur (URL) auquel le client souhaite se connecter.
3. Server Hello : le serveur sélectionne les algorithmes cryptographiques, les
algorithmes de compression et les extensions acceptés parmi ceux proposés par
le client et les renvoie dans la commande « Server Hello ».
154
Proxy SSL
4. Server Certificate : le serveur continue en envoyant son certificat au format

X509.
5. Server Hello done : le serveur envoie cette commande pour signifier au client
u’il a terminé et u’il attend une réponse.
6. Vérification du certificat : le client vérifie le certificat présenté par le serveur en
s’assu a t u’il est valide, u’il est signé par une CA de confiance et que le SNI
demandé correspond bien au CN du certificat ou à un des noms alternatifs.
7. Client Key exchange : Dans le cas où le certificat est validé, le client envoie une
clé pre-master secret chiffrée avec la clé publique du serveur qui se trouve dans
le certificat reçu. La clé pre-master secret est utilisée comme base pour calculer
la clé de session K qui chiffre/déchiffre les données dans le tunnel TLS.
8. Change Cypher Spec : Le client informe le serveur u’il bascule en mode chiffré.
9. Finished : le client envoie le message « client finished » chiffré avec la clé de
session K.
10. Change Cypher Spec : après avoir calculé la clé de session K en se basant la clé
pre-master secret reçue du client, le serveur informe ce dernier u’il bascule en
mode chiffré.
11. Finished : le serveur envoie le message « server finished » chiffré avec la clé de
session K.
Après l’e voi des messages Finished et leurs bonnes réceptions, le tunnel TLS est
ouvert et la transmission chiffrée des flux HTTP démarre.
NOTES : Si les contrôles effectués dans l’ tape 6 ne sont pas valides, l’ouve tu e de la
session TLS continue, mais la connexion TCP est réinitialisée par le client juste après
l’ ta lisse e t du tunnel TLS. Un message d’ave tisse e t est affiché par le
navigateur du client pour l’i fo e du problème rencontré : certificat expiré, CN
non valide, certificat auto-signé, etc. La majorité des navigateurs proposent d’ajoute
une exception qui force la connexion au site, pour cela une nouvelle session TLS est
ouverte.
Dans le cas où la session TLS est ouverte à travers un firewall, ce dernier ne peut ni
analyser ni filtrer les données transmises dans le tunnel TLS, parce u’elles sont
chiffrées. Le firewall ne peut pas calculer la clé de chiffrement/déchiffrement d’u e
session TLS parce u’il ’a pas accès à la pre-master Key qui est chiffrée avec la clé
publique du serveur que seul lui pourra déchiffrer en utilisant sa clé privée.
155
Proxy SSL
FONCTIONNEMENT : L’OUVERTURE D’UNE SESSION TLS VIA LE PROXY

SSL
TLS session 1 TLS Session 2
127.0.0.2:8084
TCP handshake
Proxy SSL
Client Hello : SNI=www.google.com SSL Proxy cache : block
1 TCP handshake
and do not decrypt servers
2 Client Hello : SNI=www.google.com
Verifying the certificate : Server Hello

3 • SNI=cn ou Altnames Server Certificate
• Validity Server Hello done
• Signed by a trusted CA
Client Key Exchange [pre-master secret1]server_pub_key
4 SSL filtering based on SNI
Change Cipher Spec
Finished : [client finished]K1
Change Cipher Spec

Finished : [server finished]K1
7 K1
Server Hello Generate a fake certificate K1
Server Certificate 6 signed by the SSL Proxy CA
Verifying 5
the Server Hello done
certificate
Client Key Exchange [pre-master secret2] fw_pub_key
Change Cipher Spec
Finished : [client finished]K2
Change Cipher Spec Traffic

analyses
Finished : [server finished]K2
K2
K2
Pour pouvoir analyser les données chiffrées par un tunnel TLS, les firewalls SNS
utilisent le proxy SSL qui est positionné comme « homme du milieu (man in the
middle) » entre le client et le serveur durant l’ouve tu e de la session TLS. La figure
ci-dessus illustre les différentes étapes de l’ouve tu e d’u e session TLS pour une
connexion HTTPS au travers du proxy SSL :
1. Interception de la connexion par le proxy SSL : La connexion du client sur le port

TCP/443 est translatée vers le proxy SSL qui écoute sur 127.0.0.2:8084. Le proxy
SSL commence par parcourir un cache contenant une liste de serveurs identifiés
par le trio [IP, port, SNI] déjà visités. Ces serveurs peuvent avoir deux états :
• Bloquer : cet état est dû au fait que le serveur est bloqué par la politique
de filtrage SSL avec l’a tio bloquer sans déchiffrer ou bien le serveur a
présenté un certificat qui ’a pas pu être validé par le firewall. Dans ce
cas, le proxy SSL continue l’ouve tu e de la session TLS avec le client pour
lui envoyer un message de blocage. Aucune connexion ne sera initiée
avec le serveur.
• Passer sans déchiffrer : cet état est engendré par l’a tio passer sans
déchiffrer appliquée à ce serveur par le filtrage SSL. Dans ce cas, le proxy
SSL initie une connexion TCP avec le serveur pour renvoyer les
commandes TLS du client.
Au démarrage du proxy SSL, le cache est vide, des entrées sont ajoutées pour les
deux états décrits ci-dessus. Il est réinitialisé lors de la désactivation du proxy ou
la modification de sa configuration.
156
Proxy SSL
2. Ouverture d’une nouvelle session TLS par le proxy SSL à destination du serveur :
Dans le cas où aucune entrée ’est trouvée dans le cache pour ce site, à la
réception du message client Hello qui contient le nom du serveur SNI, le proxy SSL
entame une nouvelle connexion TCP et une nouvelle session TLS à destination du
serveur.
3. Vérification du certificat serveur : À cette étape, le proxy analyse le certificat

envoyé par le serveur. Il mettra fin à la connexion dans les cas suivants :
• Le serveur ne fournit pas d'informations SSL,
• Le certificat est auto-signé (ce choix est paramétrable),
• Le certificat du serveur n'est pas signé par une autorité de certification de
confiance et il ’est pas explicitement déclaré en exception (ce choix est
paramétrable),
• Le certificat du serveur a expiré (ce choix est paramétrable),
• Le certificat du serveur est révoqué (seulement pour une CA « custom »
pour laquelle la CRL est accessible),
• Le serveur demande une authentification,
• Le SNI ne correspondant pas au CN du certificat ni à aucun des noms
alternatifs
NOTE : Lorsque le certificat serveur ’est pas conforme, l’a s au site est bloqué.
De plus, une entrée est ajoutée au cache du proxy SSL qui lui permettra de
bloquer d’aut es connexions vers le même serveur dans l’ tape 1.
4. Application du filtrage SSL : Après la validation du certificat, le SNI est confronté

aux règles de filtrage SSL pour déterminer l’a tio à appliquer au serveur :
Déchiffrer, Bloquer sans déchiffrer ou Passer sans déchiffrer. Si ’est cette
dernière qui est appliquée, le proxy SSL ferme la connexion TCP avec le serveur
une fois la session TLS établie. Puis il ouvre une nouvelle connexion TCP dans
laquelle, il renverra les commandes TLS du client.
NOTE : Lorsque l’u e des actions Passer sans déchiffrer ou Bloquer sans
déchiffrer est définie pour un SNI, le trio [IP, port, SNI] est ajouté au cache pour
appliquer l’a tio directement dans l’ tape 1 lors d’u e prochaine tentative de
connexion à ce même serveur.
5. Établissement de la session TLS [Firewall – Serveur] : dans le cas où l’a tio

Déchiffrer est appliquée, le proxy SSL finalise l’ouve tu e de la session TLS avec le
serveur. À ce stade toutes les communications entre le firewall et le serveur sont
chiffrées par la clé K1.
157
Proxy SSL
6. Génération d’un certificat usurpé (Fake Certificate) : Si l’a tio à appliquer est
Déchiffrer ou Bloquer sans déchiffrer, le proxy génère dynamiquement un
certificat qui présente le CN du certificat du serveur distant ainsi que ses noms
alternatifs. Les principales différences dans ce certificat sont les informations de
l’ etteu et la signature effectuée par l’auto it dédiée au proxy SSL. Les
certificats usurpés présentent la même clé publique générée avec sa clé privée
au démarrage du proxy SSL. Cette bi-clé est utilisée jus u’au redémarrage du
proxy SSL. Le numéro de série des certificats usurpés est incrémenté à chaque
accès vers un nouveau serveur externe. Pour éviter, en cas d’ho loge non
synchronisée, que le certificat présenté par le proxy ne soit pas encore valide, la
date de début de validité du certificat usurpé commence une semaine avant la
date courante (champ « Not Before » du certificat).
7. Établissement de la session TLS [Firewall – Client] : Le proxy SSL finalise

l’ ta lisse e t de la session TLS initiée par le client en lui présentant le certificat
usurpé. Le client effectue une vérification du certificat. Dans le cas où le
certificat de l’auto it signataire ’a pas été préalablement installé, dans le
navigateur (pour Firefox) ou dans le système (pour Internet Explorer, Edge et
Chrome), et déclaré comme une autorité de confiance, un message d’e eu
s’affi he pour signaler au client que l’auto it signataire ’est pas connue. Toutes
les communications entre le client est le firewall sont chiffrées avec la clé K2.
Après l’ tape 7, le trafic est sécurisé par la session TLS 1 entre le client et le firewall
et par la session TLS 2 entre le firewall et le serveur. Ceci permet au firewall
d’appli ue les protections applicatives sur le trafic qui transite en clair entre les
deux sessions TLS.
NOTE : L’a tivatio du proxy SSL impacte les performances du firewall SNS à cause
des opérations de déchiffrement/chiffrement appliquées à chaque session TLS. Il est
recommandé de choisir un modèle SNS dimensionné correctement pour supporter
tout le trafic traversant le proxy SSL.
158
Proxy SSL
CONFIGURATION
PROXY SSL
Programme du module
✔ Fonctionnement
➔ Configuration
Exemples d’utilisatio
159
Proxy SSL
CONFIGURATION
• Configuration du proxy SSL
La configuration du proxy SSL s’effe tue dans le menu CONFIGURATION ⇒

PROTECTION APPLICATIVE ⇒ Protocoles ⇒ SSL ⇒ Profil ssl_01 ⇒ onglet PROXY
L’e ad Inspection de contenu permet de définir l’a tio (déléguer à l’utilisateur,

bloquer ou continuer l’analyse) qui doit être appliquée par le proxy dans le cas où le
certificat présenté par le serveur distant est :
• un certificat auto-signé,
• un certificat non valide,
• un certificat signé par une autorité inconnue,
• un certificat avec un type inconnu ou non conforme,
• un certificat avec un nom CN incorrect,
• un certificat dont le CN et les noms alternatifs ne correspondent pas au FQDN du
serveur (SNI).
L’optio Autoriser les adresses IP dans les noms de domaine SSL permet d’a de à
un site en utilisant son adresse IP à la place de son nom FQDN.
L’e ad Support contient deux options pour définir l’a tio à appliquer (Bloquer
ou Passer sans déchiffrer) dans le cas où le déchiffrement échoue et dans le cas où
le certificat ne peut être classifié dans les catégories de la base URL (Stormshield ou
Extended Web Control).
Dans le cas où l’a s à un site est bloqué par le proxy SSL à cause d’u des contrôles
ci-dessus, l’utilisateu voit sur son navigateur un message indiquant la raison du
blocage.
160
Proxy SSL
CONFIGURATION
• Configuration de l’autorité signataire des certificats

usurpés
10
Par défaut, le proxy SSL signe les certificats usurpés avec l’auto it SSL proxy default
authority déjà présente sur le firewall. La modification de cette autorité s’effe tue
dans le menu CONFIGURATION ⇒ PROTECTION APPLICATIVE ⇒ Protocoles ⇒
SSL ⇒ Accéder à la configuration globale ⇒ onglet PROXY.
Il suffit de sélectionner la nouvelle autorité dans C.A (signe les certificats) et son
mot de passe dans Mot de passe de l'autorité.
NOTE : Si vous modifiez la CA par défaut, veillez à sauvegarder son mot de passe
dans le cas d’u e réutilisation future. Le mot de passe peut être affiché en clair en
cliquant sur l’i ô e représentant une clé.
161
Proxy SSL
CONFIGURATION
• Gestion des certificats des autorités publiques
11
Lorsque le proxy SSL reçoit le certificat du serveur distant, il vérifie s’il est signé par
une autorité de confiance publique ou privée. Les autorités de confiance publiques
sont préconfigurées et elles sont mises à jour automatiquement par le module
Active Update. Elles sont accessibles depuis le menu CONFIGURATION ⇒
PROTECTION APPLICATIVE ⇒ Protocoles ⇒ SSL ⇒ Accéder à la configuration
globale ⇒ AUTORITÉS DE CERTIFICATION PUBLIQUES. L’i te fa e permet
d’a tive /d sa tive une autorité en cas de besoin.
162
Proxy SSL
CONFIGURATION
• Gestion des certificats d’autorités privées de confiance
• Gestion des certificats de serveurs privés de confiance
12
Si vous souhaitez faire confiance à une autorité privée (non publique), il suffit de
l’ajoute dans le menu CONFIGURATION ⇒ PROTECTION APPLICATIVE ⇒ Protocoles
⇒ SSL ⇒ Accéder à la configuration globale ⇒ AUTORITÉS DE CERTIFICATION
PERSONNALISÉES. Dans ce cas, vous faites confiance à tous les certificats signés par
cette autorité.
Par contre si vous souhaitez faire confiance à un certificat serveur seulement, vous
pouvez ajouter ce certificat dans le menu CONFIGURATION ⇒ PROTECTION
APPLICATIVE ⇒ Protocoles ⇒ SSL ⇒ Accéder à la configuration globale ⇒
CERTIFICATS DE CONFIANCE.
163
Proxy SSL
PROXY HTTPS
• Objet web de type CN : création d’une catégorie

personnalisée
13
Depuis le menu CONFIGURATION ⇒ OBJETS ⇒ Objets Web, dans l’o glet NOM DE CERTIFICAT
(CN), vous pouvez créer vos propres catégories, une catégorie contient une liste de SNI, à
ajouter en respectant les suggestions.
La création de ces objets a déjà été détaillée en CSNA.
164
Proxy SSL
PROXY HTTPS
• Création d’un groupe de catégories personnalisé
14
Depuis le menu CONFIGURATION ⇒ OBJETS ⇒ Objets Web, dans l’o glet GROUPE DE
CATÉGORIES, vous pouvez créer et éditer vos propres groupes de catégories. Choisissez de créer
un objet de type groupe de catégories Certificats.
Un groupe de catégories peut être composé de catégories présentes dans la base (EWC ou
embarquée), mais aussi de catégories personnalisées, comme dans l’e e ple ci-dessus.
Vous pouvez utiliser les touches CTRL et SHIFT pour présélectionner plusieurs groupes avant de
les déplacer.
La création de ces objets a déjà été détaillée en CSNA.
165
Proxy SSL
CONFIGURATION
• Configuration du filtrage SSL
15
Le filtrage SSL est configurable dans le menu CONFIGURATION ⇒ POLITIQUE DE

SÉCURITÉ ⇒ Filtrage SSL. Il est possible de définir jus u’à 10 politiques différentes,
mais une seule peut être activée sur une règle d’i spe tio SSL. Une politique de
filtrage SSL est constituée de plusieurs règles qui sont parcourues séquentiellement.
Une règle définit l’a tio à appliquer pour une catégorie d’URL-CN.
Après la réception du certificat serveur et la confirmation que le SNI demandé
correspond au CN ou à un des noms alternatifs, le SNI est confronté aux règles de
filtrage SSL. Dans le cas où une règle correspond, l’a tio de la règle est appliquée :
• Déchiffrer : le proxy SSL établit une session TLS avec le serveur et une autre avec
le client en lui présentant le certificat usurpé.
• Bloquer sans déchiffrer : le proxy SSL ferme les connexions TCP avec le serveur et
le client après l’ ta lisse e t des sessions TLS. Le client recevra quand même le
certificat usurpé.
• Passer sans déchiffrer : le proxy SSL ferme la connexion TCP après l’ ta lisse e t
de la session TLS et ouvre une deuxième connexion TCP pour renvoyer les
commandes TLS du client.
166
Proxy SSL
NOTES :
• Pour les actions Bloquer sans déchiffrer et Passer sans déchiffrer, le trio [IP, port,
SNI] est ajouté au cache du proxy SSL pour appliquer l’a tio dès la réception du
SNI lors d’u e prochaine connexion au même serveur.
• Le filtrage SSL doit prendre en considération la législation du pays dans lequel le

firewall est utilisé. En effet, le déchiffrement des données personnelles est
encadré par la loi dans la majorité des pays et il peut exposer les entreprises qui
utilisent le proxy SSL sans précaution à des risques juridiques. En utilisant le
filtrage SSL, l’ad i ist ateu doit exclure les sites qui ne doivent pas être
déchiffrés. Pour la France, les aspects juridiques liés au déchiffrement SSL sont
détaillés en annexe du document « Recommandations de sécurité concernant
l’a al se des flux HTTPS » de l’ANSSI (Agence Nationale de la Sécurité des
Systèmes d’I fo atio ).
(https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_TLS_NoteTech.pdf)
• Pour limiter l’i pa t du proxy SSL sur les performances du firewall, le filtrage SSL
peut être utilisé pour passer sans déchiffrer plusieurs sites qui ne représentent
pas une menace sur la sécurité de l’e t ep ise, par exemple les sites de mises
jours des systèmes et des logiciels.
167
Proxy SSL
CONFIGURATION
• Activation du proxy SSL
17
L’a tivatio du proxy SSL se fait dans le menu CONFIGURATION ⇒ POLITIQUE DE

SÉCURITÉ ⇒ FILTRAGE ET NAT => onglet FILTRAGE en ajoutant une règle
d’i spe tio SSL. Un assistant s’affi he pour renseigner les informations suivantes :
• Machines Sources,
• Interface d’e t e,
• Destination,
• Port dest : par défaut le groupe de ports ssl_srv est préconfiguré, il contient les
ports standards des services utilisant une session TLS : HTTPS, IMAPS, LDAPS,
SMTPS, etc.
• Profil d’i spe tio ,
• Politique de filtrage SSL : dans le cas où aucune politique de filtrage ’est
configurée, l’a tio Déchiffrer sera appliquée par défaut pour tous les serveurs.
• Antivirus.
L’assista t crée deux règles de filtrage :

1. La première règle est utilisée pour intercepter les flux provenant du réseau
interne à destination d’i te et sur le groupe de port ssl_srv. Ces flux sont
translatés à destination du proxy SSL qui écoute sur 127.0.0.1:8084. Cette règle
applique l’a tio déchiffrer et le filtrage SSL.
2. La deuxième règle autorise les flux provenant du réseau interne et sortant du
proxy SSL (Via SSL proxy) à destination d’I te et. Les protections applicatives
(Filtrage URL, Antivirus, antispam, etc.) doivent être activées sur cette règle.
NOTE : Le proxy SSL ne permet pas de déchiffrer les flux ftps.
168
Proxy SSL
CONFIGURATION
• Récupération du certificat de la CA utilisée par le proxy

SSL via le navigateur (méthode 1)
18
Une fois le proxy SSL activé, le client qui tente de se connecter à un site HTTPS
déchiffré, voit une alerte s’affi he dans le navigateur pour l’i fo e que le certificat
reçu ’est pas signé par une autorité connue. Cette alerte s’e pli ue par le fait que le
proxy SSL envoie un certificat usurpé signé par une autorité (CA) non publique.
Pour éviter l’affi hage de cette alerte qui peut perturber les utilisateurs, il faut
installer le certificat de la CA racine utilisée par le proxy SSL dans le navigateur (pour
Firefox) ou dans le magasin de certificats du système d’e ploitatio (pour Internet
Explorer, Edge et Chrome) et la déclarer comme une autorité racine de confiance.
Vous pouvez récupérer le certificat de la CA utilisée par le proxy SSL de différentes

manières :
1. Directement depuis le navigateur (Edge dans l’e e ple ci-dessus) quand le
message d’ale te s’affi he, cliquez sur Erreur de certificat, puis Voir le certificat,
mettez la CA racine en surbrillance, et cliquez sur Exporter vers un fichier.
NOTE : Certains sites Web utilisent HSTS (HTTP Strict Transport Security), directive
présentée comme un entête de réponse envoyé par le serveur au navigateur pour
préciser que le domaine interrogé doit être visité en HTTPS uniquement (voir RFC
6797). Le projet Chromium maintient une liste des sites HSTS pré-chargés sur les
navigateurs (Chrome, Firefox et Edge l’utilise t), avec leur certificat valide. Lorsque
vous tentez de joindre un de ces sites, la méthode 1 vue ci-dessus ne fonctionnera
pas (le certificat étant usurpé, ne sera pas accepté par le navigateur).
Vous devrez utiliser les méthodes 2 ou 3 vues sur la diapositive suivante, ou vous
connecter sur un site ’utilisa t pas HSTS, pour récupérer le certificat de la CA
utilisée par le proxy SSL. Une fois le certificat de cette CA installé dans le magasin des
certificats de confiance, les sites utilisant HSTS seront accessibles via le proxy SSL.
169
Proxy SSL
CONFIGURATION
• Récupération du certificat de la CA utilisée par le proxy

SSL via le portail captif (méthode 2)
– Sans authentification :
https://adresse_IP/auth/proxyauthority.crt
– Avec authentification :
19
2. Depuis le portail captif avec l’ad esse :

https://adresse_IP/auth/proxyauthority.crt. Si l’utilisateu est authentifié, il
peut le télécharger depuis le menu Données personnelles.
3. L’ad i ist ateu du firewall peut télécharger le certificat de la CA depuis

l’i te fa e web du firewall, dans le menu CONFIGURATION ⇒ OBJETS ⇒
Certificats et PKI.
170
Proxy SSL
CONFIGURATION
• Installation du certificat de la CA du proxy SSL dans le

navigateur Firefox
20
Sur Firefox, suivez la procédure ci-dessous :

1. Tapez about:preferences#privacy dans la barre de recherche, puis cliquez sur le
bouton Afficher les certificats en bas de page,
2. Allez dans l’o glet Autorités et cliquez sur le bouton Importer,
3. Choisissez le fichier de la CA racine,
4. Dans la fenêtre Téléchargement de certificats, cochez la case Confirmer cette AC
pour identifier des sites web, puis cliquez sur le bouton OK.
5. Vérifiez que l’i po t est effectif (le classement dans Firefox est effectué par le
nom d’o ga isatio décrit dans le certificat).
171
Proxy SSL
CONFIGURATION
• Installation du certificat de la CA du proxy SSL dans le

magasin du système Windows
21
Sur Windows, le certificat est ajouté au magasin de certificats du système

d’e ploitatio , utilisé par les navigateurs Edge et Chrome (et Internet Explorer).
Suivez la procédure ci-dessous :
1. Cliquez droit sur le certificat à installer et choisissez l’optio Installer le certificat,
2. Dans l’assista t, choisissez le magasin pour l’Utilisateur actuel,
3. Sélectionnez le magasin de certificats Autorités de certification racines de
confiance.
NOTES :
• Dans un domaine Active Directory, il est plus simple d’auto atise le déploiement
du certificat de la CA par l’utilisatio des stratégies de groupe (GPO).
• Le magasin de certificats de Windows est accessible par le menu Démarrer,
Exécuter, tapez certmgr.msc.
172
Proxy SSL
EXEMPLES
D’UTILISATION
PROXY SSL
Programme du module
✔ Fonctionnement
✔ Configuration
➔ Exemples d’utilisatio
173
Proxy SSL
EXEMPLES D’UTILISATION
• Inspecter les flux chiffrés : HTTPS, SMTPS, IMAPS, etc.
23
Les protections applicatives (Filtrage URL, antivirus, antispam, filtrage SMTP, etc.)
doivent être activées sur les flux déchiffrés sortants du proxy SSL : règles 2 et 3.
174
Proxy SSL
• Rediriger les utilisateurs vers le portail captif en

accédant à des sites HTTPS.
24
Dans le cas d’u e authentification explicite via le portail captif, la règle

d’authe tifi atio qui renvoie vers le portail captif fonctionne seulement à la
réception d’u e requête HTTP. Si vous voulez renvoyer également les utilisateurs vers
le portail captif quand ils essayent de se connecter à un site en HTTPS, il faut activer
le proxy SSL pour déchiffrer le flux préalablement. La capture ci-dessus illustre les
règles de filtrage nécessaires pour mettre en place cette configuration :
• La première règle intercepte le trafic HTTPS et le redirige vers le proxy SSL,

• La deuxième règle permet de rediriger le navigateur vers le portail captif lo s u’u
utilisateur non encore authentifié essaye d’a de à un site en HTTP ou en
HTTPS,
• La troisième règle autorise l’utilisateu , une fois authentifié depuis une machine
du réseau interne, à surfer sur le WEB en HTTP et HTTPS, tout en étant soumis à
la politique de filtrage URL_Filter_Custom.
175
Proxy SSL
• Bloquer des sites HTTPS seulement
25
Dans certains cas, l’ad i ist ateu souhaite seulement bloquer certaines catégories
de sites web qui peuvent être accessibles en HTTPS et il ne souhaite pas déchiffrer
les autres flux et déployer le certificat de la CA. Pour cela, il est possible d’a tive le
proxy SSL et d’utilise le filtrage SSL seulement pour bloquer des catégories avec
l’a tio Bloquer sans déchiffrer et pour tout le reste, il faut appliquer l’a tio Passer
sans déchiffrer.
Cet exemple a été abordé en formation CSNA.
NOTE : un utilisateur, qui essaye d’a de à un site bloqué, voit le message d’ale te
affiché par le navigateur pour le problème du certificat. Et s’il décide d’ajoute une
exception, il voit un message disant que la connexion a été rejetée par le serveur
SSL. Il ne verra jamais la page de blocage qui est affichée par le filtrage URL.
176
Proxy SSL
LAB 6 : PROXY SSL
26

• Tunnels VPN SSL

177
VPN IPSEC AVANCÉ

✔ Proxy SSL
➔ VPN IPsec avancé
178
VPN IPSec avancé
RAPPELS
VPN IPSEC AVANCÉ
Programme du module
➔ Rappels
NAT- Traversal
Dead Peer Detection (DPD) Liveness
Étoile / chainage
NAT dans IPSec
Site à site avec certificats issus de plusieurs autorités
Site à site avec certificats issus d'une seule autorité
Site à site par certificats avec définition du peer id = subject
Nomade par certificat
Nomade: mode xauth (IKEv1 uniquement)
Nomade: mode hybride (IKEv1 uniquement)
Nomade: mode config
Failover IPSec
179
VPN IPSec avancé
RAPPELS
Le VPN IPSec fournit de manière transparente :

▪ La connectivité entre des réseaux privés au travers d’un réseau public
▪ La connectivité avec des réseaux privés de postes nomades situés en zone publique
▪ La confidentialité des communications IP par encapsulation et chiffrement
Utilisateur
nomade
@pub A
@pub B
Réseau A
Réseau B
180
VPN IPSec avancé
RAPPELS
IKE Phase 1
IKEv1 : ISAKMP-SA
IKEv2 : PARENT-SA
IKE Phase 2
IKEv1 : ESP-SA 1, IKEv2 : Child-SA 1

Pa uet d’o igi e IKEv1 : ESP-SA 2, IKEv2 : Child-SA 2 Pa uet d’o igi e
@IP A, @IP B DATA @IP A, @IP B DATA
@IP FW A, @IP FW B E_ESP @IP A, @IP B DATA F_ESP Auth
Champs chiffrés
Champs authentifiés
4
La négociation des clefs et des algorithmes est prise en charge par le protocole applicatif
ISAKMP (Internet Security Association Key Management Protocol) également appelé IKE
(Internet Key Exchange)
L’i pl e tatio ISAKMP sur Stormshield v4 est compatible IKEv1 et IKEv2.
Le tunneling IPSec est assuré par le protocole ESP (Encapsulating Security Payload)
Le protocole ESP assure l’e apsulatio , l’i t g it et le chiffrement grâce à des algorithmes et
des clefs préalablement négociées.
Les négociations de tunnels se déroulent en deux phases :

▪ Phase 1 ou Parent_SA : présentation des fonctionnalités supportées et authentification
mutuelle des deux correspondants. À l’issue, une clef est négociée = la ISAKMP-SA.
→Cette clef permettra de chiffrer la suite des négociations : le dialogue de phase 2.
▪ Phase 2 ou Child_SA : négociation des paramètres du tunnel avec comparaison des

extrémités de trafic. À l’issue, une paire de clefs est négociée = les IPSec-SA. → Ces clefs
serviront à chiffrer les flux encapsulés dans le protocole ESP.
Les négociations sont menées par ISAKMP sur demande de la pile IPSec lorsque du trafic doit
être pris en charge et que les IPSec-SA sont manquantes ou sur le point d’expi e .
181
VPN IPSec avancé
La version d’IKE utilisée est définie au préalable et doit être la même chez les deux
correspondants.
Pour IKEv1, le mode de négociation Main ou Aggressive doit être prédéfini sur les deux
correspondants et est conditionné par :
• La méthode d’authe tifi atio : PSK ou certificat,
• Le type d’ide tit : adresse IP, FQDN, adresse email ou certificat.
IKEv2 ’i t g e pas de mode de négociation différentié (Main et Aggressive), l’usage des

identités ’est donc plus contrainte.
Contrairement à IKEv1, IKEv2 ne négocie pas les durées de vie (lifetime) des clés. Cette
valeur est gérée localement par chacun des correspondants.
Les politiques IPSec sont chargées dans une structure du noyau du système appelée SPD
(Security Policy Database). Leur contenu est visualisable dans le menu Supervision >
Supervision > Tunnels VPN IPSec.
Les clefs négociées pour IPSec, également appelées SA, sont stockées dans une structure
du noyau appelée la SAD (Security Association Database).
Les journaux de négociations IKE sont aussi consultables dans l’i te fa e web.
Vous pouvez vous référer à la formation CSNA pour plus de détails.
NOTE : Il est possible d’utilise des correspondants IKEv1 et IKEv2 dans la même
politique IPSec. Cette possibilité est ouverte à titre expérimental. Une telle configuration
’est donc pas recommandée en production.
182
VPN IPSec avancé
NAT-TRAVERSAL
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
➔ NAT- Traversal
Dead Peer Detection (DPD) Liveness
Étoile / chainage
NAT dans IPSec
Nomade: mode config
Failover IPSec
183
VPN IPSec avancé
FONCTIONNALITÉ : NAT TRAVERSAL
Priv_IP1 PRIV_IP2 PRIV_IP3

R_PUB_IP FW_PUB_IP
IKE/UDP:500 IKE/UDP:20001
ESP(SPI1)/IP ESP(SPI1)/IP
ESP(SPI1)/IP
NAT Traversal
ESP(SPI1)/UDP:4500/IP ESP(SPI1)/UDP:2011/IP
En effet, les opérations de NAT dynamique réalisent la transformation de N adresses

sources (en général privées) en une seule adresse source (en général publique).
Pour éviter tout risque d’a iguït , dès lors que le seul critère distinctif @IPsource
disparaît au franchissement de la translation, ces opérations de NAT dynamique
transforment également le port source pour introduire un nouveau critère distinctif dont
elles conservent une trace dans la table de NAT pour pouvoir gérer les paquets retour
sans aucune confusion possible.
Ce mécanisme ’est cependant possible que pour des protocoles reposant sur des ports,
’est-à-dire TCP et UDP.
Le protocole ESP ne fait pas usage de ports. La solution adoptée et standardisée par le
NAT-T consiste donc à procéder à une encapsulation des paquets ESP dans de l’UDP afin
d’i t odui e la notion de port qui devient alors le facteur distinctif des différents
correspondants lo s u’ils sont translatés derrière la même adresse IP.
Pour IKEv2, NAT-T est une fonctionnalité intégrée dans le standard du protocole. Elle est
donc obligatoirement supportée dans cette version d’IKE.
Pour IKEv1, l’i pl e tatio NAT-T sur les produits Stormshield Network se conforme à
la RFC3947 (Janvier 2005).
Les versions annoncées au début des négociations sont RFC3947 et NAT-T Draft 2.
Cette fonctionnalité sera activée automatiquement lorsque :

• Les deux correspondants intègrent une version compatible,
• Du NAT aura été détecté lors des négociations.
184
VPN IPSec avancé
FONCTIONNALITÉ : NAT TRAVERSAL
hash_1( hash_2( no NAT

src IP, received src IP,
src port, received src port, hash_1 = hash_2 ?
IP dst, local IP, yes
port dst) local port) No NAT
Protocoles et services : Compatibilité NAT-T :

udp/500 : début des négociations IKE IKEv1: Draft2 + RFC3947
udp/4500 : fin de la phase 1 et phase 2 complète IKEv2: Standard IKEv2
udp/4500[ESP] : encapsulation de ESP
Paquet ESP avant encapsulation NAT-T
Entête Données couche

Entête IP1 UDP H_ESP
IP0 supérieure
F_ESP Auth
Paquet IP d’origine avant encapsulation
La détection de NAT entre les deux correspondants IPSec chargés de négocier le tunnel
est réalisée pendant la négociation de la phase 1.
Les deux correspondants fournissent un haché de leur adresse IP et du port source u’ils
utilisent ainsi u’u haché de l’ad esse IP du correspondant distant et du port
destination u’ils ciblent ; ces deux informations étant issues de leur configuration.
À la réception de ces informations, chacun recalcule les valeurs de haché à partir des
adresses et ports présents dans l’e veloppe IP et UDP des paquets de négociation IKE.
La comparaison montre si les hachés recalculés sont identiques ou diffèrent des hachés
transmis. Les hachés différents révèlent les côtés où du NAT est appliqué.
L’usage du NAT-T provoquera l’ajout d’u en-tête UDP de 8 octets.
L’a tivatio du NAT-T sera visible dans les logs VPN :

NAT detected, switching to port 4500
Puis, sur IKEv1, lo s u’il s’agi a de NAT dynamique, avec modification du port source
original :
Remote port changed (142.61.46.180[20064])
185
VPN IPSec avancé
DEAD PEER DETECTION

(DPD) LIVENESS
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
➔ Dead Peer Detection (DPD) Liveness
Étoile / chainage
NAT dans IPSec
Nomade: mode config
Failover IPSec
186
VPN IPSec avancé
FONCTIONNALITÉ : DEAD PEER DETECTION / LIVENESS
La fonction DPD est assurée par ISAKMP pour vérifier périodiquement la

validité de la clef de phase 1
10
La ISAKMP-SA, clef de phase 1, sert à protéger les négociations de phase 2 par

chiffrement; elle est donc nécessaire pour u’u e phase 2 (ou les Child_SA) puisse être
négociée ou renégociée, à tout moment sur demande de la pile IPSec ou sur réception
d’u e requête de renégociation par le correspondant distant.
Pour être utilisable, cette clef doit être connue par les deux correspondants qui seraient
amenés à renégocier une phase 2.
La fonction DPD vise donc à fournir à ISAKMP, un mécanisme qui permettra de vérifier la
validité de sa clef ISAKMP-SA.
La méthode retenue sur IKEv1 pour tester la validité de cette clef consiste en des
opérations de chiffrement de messages applicatifs standardisés [R-U-THERE+id] pour
lesquels des réponses [R-U-THERE-ACK+id] sont attendues chiffrées avec la même
ISAKMP-SA.
Sur IKEv1, ce dialogue de DPD est standardisé par la RFC 3706.

Sur IKEv2, ce mécanisme a été renommé « Liveness » et fait partie intégrante du standard
applicatif du protocole.
Les paquets de Liveness sur IKEv2 sont des messages de type « Informational » vides,
mais séquencés et chiffrés avec la clef Parent_SA.
L’i pl e tatio de cette fonctionnalité sur SNS s’a o pag e de plusieurs paramètres
permettant d’adapte le comportement du DPD/Liveness aux besoins et aux spécificités
de l’a hite tu e réseau.
187
VPN IPSec avancé
Les paramètres qui conditionnent les décisions du DPD sont :

• La fréquence du test,
• Le délai d’atte te de la réponse,
• Le nombre d’ he s (non-réponse) aux tests.
Si aucune réponse ’est obtenue aux tests de DPD et que donc le seuil du nombre
d’ he s maximum est atteint, IKE considérera que le correspondant ne répond plus et
l’i di ue a par le log « Remote seems to be dead ».
Dans ce cas, toutes les IPSec-SA ainsi que la ISAKMP-SA négociées avec ce correspondant
seront purgées.
188
VPN IPSec avancé
FONCTIONNALITÉ : DEAD PEER DETECTION IKEV1
12
La fonction Dead Peer Detection sur IKEv1 (RFC 3706) est paramétré par défaut sur
« Passif ».
• Inactif (déprécié) : Ce choix vise à désactiver l’a o e de la capacité à utiliser DPD;

ainsi, même si cette fonction est supportée par le correspondant distant, elle ne pourra
pas être utilisée.
• Passif : Paramétré ainsi, IKE ne sera pas à l’i itiative de tests DPD, mais répondra aux
sollicitations du correspondant.
• Bas :
o Fréquence des tests R-U-There : toutes les 600 secondes
o Temps d’atte te de la réponse : 10 secondes
o Nombre d’ he s tolérés : 5
• Haut :
o Fréquence des tests R-U-There : toutes les 30 secondes
o Temps d’atte te de la réponse : 3 secondes
o Nombre d’ he s tolérés : 5
189
VPN IPSec avancé
FONCTIONNALITÉ : DPD/LIVENESS IKEV2
13
La fonction Dead Peer Detection ou Liveness sur IKEv2 est paramétrée par défaut sur
« Passif » et ’est pas désactivable puisque ’est une fonction intégrée dans le standard du
protocole IKEv2.
• Passif : Paramétré ainsi, IKE ne sera pas à l’i itiative de tests DPD, mais répondra aux
sollicitations du correspondant.
• Bas :
o Fréquence des tests : toutes les 500 secondes
o Temps d’atte te de la réponse : 4 secondes. Chaque nouvelle tentative se
produira après une attente de 1,8 x [le temps d’atte te de la tentative
précédente]
o Nombre de réémission du test : 3
• Haut :
o Fréquence des tests : toutes les 30 secondes
o Temps d’atte te (de base) de la 1ère réponse : 4 secondes. Chaque nouvelle
tentative N se produira après une attente de 1,8 x [le temps d’atte te de la
tentative précédente]
o Nombre de réémission du test : 3
Retransmissions et seuil avec les paramètres présentés ci-dessus :

‐ La première tentative a lieu à la seconde 0,
‐ La première retransmission (c-à-d la deuxième tentative) 4 secondes plus tard,
‐ La deuxième retransmission 7 secondes plus tard,
‐ Et enfin la troisième retransmission 13 secondes plus tard.
190
VPN IPSec avancé
FONCTIONNALITÉ : CAS D’USAGE DU DPD / LIVENESS
La Security Association Database contient les IP des correspondants

ainsi que les port UDP en cas de NAT-T
R_PUB_IP FW_PUB_IP
1
Initial Dynamic NAT Security Association Database
Priv_IP R_PUB_IP
IKE/UDP:500 IKE/UDP:20001 R_PUB_IP FW_PUB_IP
ESP/UDP:20011 ESP/UDP:4500
ESP/UDP:4500 ESP/UDP:20011
The Initial Dynamic NAT is lost
2
New session of Dynamic NAT
R_PUB_IP
IKE/UDP:20022
ESP/UDP:20022
14
Faut-il activer le DPD ?
Dans la mesure où la ISAKMP-SA est négociée et que, par conséquent, sa durée de vie est
identique sur les deux correspondants, elle ne devrait jamais disparaître sur l’u des deux
correspondants alors u’elle serait restée valide sur l’aut e.
Toutefois, en considérant un tunnel négocié entre deux correspondants A et B, pour relier
les réseaux internes Net-A et Net-B, des situations similaires pourraient se produire dans
certaines conditions.
1er scénario :
Si le correspondant B est situé derrière un équipement qui réalise une translation
dynamique; l’ad esse IP publique que le correspondant A cherchera à joindre pour les
négociations IKE ainsi que le trafic chiffré est celle portée par le routeur frontal. Si ce
routeur porte une IP dynamique et que celle-ci change, aucun des deux correspondants A
ou B ne s’e apercevra. Et la situation sera bloquée :
• A continuera d’e vo e les paquets vers l’a ie e IP publique connue pour B,
• B continuera d’e vo e ses flux chiffrés et ses éventuelles tentatives de
renégociation de phase 2 vers A, qui ignorera l’e se le de ces paquets
puis u’ils proviendront d’u e adresse IP (la nouvelle IP du routeur côté B) avec
laquelle il ’a négocié aucun tunnel.
Il existe une variante de ce 1er cas, où le routeur frontal qui applique la translation
dynamique, provoque l’expi atio de la session de NAT allouée au trafic IKE/IPSec, à cause
d’u e inactivité prolongée de ce trafic (cas illustré ci-dessus).
191
VPN IPSec avancé
2eme scénario :
Si le correspondant B venait à redémarrer brutalement ou s’il venait à changer d’ad esse

IP (dans le cas où il posséderait une adresse IP attribuée dynamiquement), la ISAKMP-SA
serait perdue ou invalide.
Cependant, dans ces cas, le correspondant B, sur lequel la ISAKMP-SA négociée avec A
serait devenue inutilisable, relancerait spontanément des négociations depuis la phase 1
dès lors que du trafic provenant de son réseau interne Net-B nécessiterait l’usage du
tunnel IPSec pour atteindre Net-A.
Mais si aucun trafic de Net-B ne cherchait à joindre Net-A, alors B ne déclencherait pas de
négociation et la situation resterait figée :
• A ’a a t pas détecté que B ne possède plus les clefs IPSec ou ’est plus
joignable à cette IP, continuerait d’e vo e des flux que B ne pourrait pas traiter,
• B ’a a t pas de flux à acheminer vers Net-A, ne tenterait pas de rétablir la
connectivité en remontant le tunnel.
La situation décrite dans ce cas pourrait également être évitée en activant du keep-alive,
au moins sur le site B pour forcer la renégociation du tunnel.
La fonction de DPD permettra de résoudre ces deux cas en mettant en évidence que le
dialogue IKE est devenu inopérant.
Au-delà du seuil d’ he , la fonction DPD conclura « Remote seems to be dead ».
Les SA IPSec et ISAKMP négociées entre ces deux correspondants seront alors purgées.
N’i po te quel trafic entre Net-A et Net-B nécessitant l’a s au tunnel provoquera alors
des renégociations de phase 1, puis phase 2, et un nouveau tunnel IPSec sera ainsi
opérationnel.
192
VPN IPSec avancé
Quelles valeurs choisir ?
Il est essentiel de choisir des paramètres adaptés aux conditions d’utilisatio .

Notamment, le délai acceptable pour la détection doit être calculé dans le pire des cas,
’est-à-dire en cumulant le temps maximum entre deux tests (la période) avec le temps
d’atte te de la réponse multiplié par le nombre d’ he s toléré :
� = + � × �
La recherche de valeurs basses pour obtenir le délai de détection minimal ne doit pas
conduire à favoriser le risque de provoquer des faux-positifs. Car, comme nous l’avo s dit
précédemment, lorsque DPD conclut « Remote seems to be dead », les SA sont purgées,
donc les tunnels deviennent indisponibles.
Il faut donc trouver un compromis entre un délai acceptable de réactivité du DPD et des
valeurs suffisamment tolérantes pour éviter les faux-positifs.
Les causes probables de faux-positifs :

• Pertes de paquets sur la ligne « Internet » : si l’u , au moins, des points d’a s réseau
permettant aux deux correspondants d’ ha ge les tests de DPD, subit des pertes de
paquets en quantité suffisante pour que tantôt les requêtes R-U-There tantôt les
réponses R-U-There-Ack ne parviennent pas au destinataire, le seuil d’ he pourrait
être rapidement atteint s’il est fixé trop bas.
• La latence des lignes « Internet » : si les paquets de DPD sont échangés sur des lignes à
forte latence, il est possible que la latence d’a he i e e t de la requête R-U-There
cumulée à la latence de retour de la réponse R-U-There-Ack dépasse fréquemment ou
systématiquement le temps d’atte te toléré pour la réception de la réponse. Des
latences si élevées sont majoritairement constatées sur des liens empruntant plusieurs
sauts satellites.
Le choix du paramétrage du DPD dépendra donc principalement de la qualité et de la

réactivité de la ligne.
En cas de nécessité, un paramétrage fin du DPD est possible en mode CLI; la procédure
détaillée est décrite en formation Troubleshooting and Support (CSNTS) ainsi que dans
notre base de connaissance.
193
VPN IPSec avancé
ÉTOILE / CHAINAGE
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ Dead Peer Detection (DPD) Liveness
➔ Étoile / chainage
NAT dans IPSec
Nomade: mode config
Failover IPSec
194
VPN IPSec avancé
CONFIGURATION EN ÉTOILE
Réseau Central
Firewall Central
Firewall A Firewall B
Réseau A Réseau B
18
L’assista t configuration en étoile permet de construire rapidement une topologie

multisites.
L’assista t est exécuté sur le site central. Pour les autres sites ’est un simple tunnel site
à site.
195
VPN IPSec avancé
CONFIGURATION EN ÉTOILE
19
Cette topologie vise à permettre à tous les sites distants de joindre le réseau du site
Central.
Pour un usage plus confortable de cet assistant, il est conseillé de procéder au préalable
à la création de tous les objets de type machines et réseaux de la topologie, ainsi que
des correspondants IPSec.
Les options de l’assista t :

• Considérer les réseaux distants comme des réseaux internes : Externe par défaut,
IPSec deviendra alors une interface interne (protégée). Cela oblige à manuellement
légitimer sur l’i te fa e IPSec les réseaux joignables par les tunnels. Cette action se
résume à ajouter dans la table des routes statiques, des entrées associant ces réseaux
distants à l’i te fa e IPSec. Cette option ’est pas nécessaire au fonctionnement des
tunnels ni des communications au travers des tunnels. Elle peut être désactivée dans
les paramètres avancés de la prévention d’i t usio PROTECTION APPLICATIVE >
Profils d’inspection > Configuration Avancée > Considérer les interfaces IPSec
comme internes.
• Créer les politiques sans chiffrement (none) pour les réseaux internes : Cette option
génère des directives de tunnels bypass dans la politique IPSec. Des tunnels bypass
sont nécessaires lorsque les plans d’ad essage des réseaux directement connectés au
firewall peuvent entrer en conflit avec les plans d’ad essage des réseaux distants
joignables par des tunnels IPSec. Hors assistant, il est possible de générer des
directives de tunnels bypass en définissant une politique impliquant les réseaux à
exclure d’IPSe mais sans indiquer de correspondant (champ du correspondant
positionné à None). Pour u’elles soient efficaces, ces directives doivent être placées
en tête de politique. Cette fonctionnalité est exposée plus en détail en formation
Troubleshooting and Support (CSNTS).
196
VPN IPSec avancé
CHAINAGE : SPOKE TO SPOKE
Réseau Central
Réseau B est Réseau A est annoncé

annoncé comme un comme un réseau
réseau local au local au Central
Central
Firewall Central
Une configuration en étoile peut être

Réseau A étendue pour permettre une Réseau B
communication entre les deux sites
distants via le site central.
20
L’a hite tu e en étoile vue précédemment a été étendue pour permettre une
communication entre les sites distants A et B en passant par le firewall central.
Cette architecture doit être définie dans les politiques du central et des sites distants
pour permettre à IPSec d’ide tifie que le flux doit être pris en charge par un tunnel.
Lors du dialogue IKE de phase 2 avec le firewall A, le Central annonce les deux réseaux
locaux : Central + réseau B
De même, dans les négociations de phase 2 avec B, le Central annonce les deux réseaux
locaux : Central + réseau A
Le Central entretiendra donc quatre tunnels : 2 tunnels avec A et 2 tunnels avec B.
Si d’aut es sites distants devaient rejoindre cette architecture pour interconnecter tous
les sites, il serait plus commode de créer des groupes de réseaux, chacun excluant l’u
des réseaux.
Exemple pour cette même architecture avec 3 sites A, B, C + Central :

• Le groupe de réseaux présenté par Central à A contiendrait [Central + B + C]
• Le groupe de réseaux présenté par Central à B contiendrait [Central + A + C]
• Le groupe de réseaux présenté par Central à C contiendrait [Central + A + B]
NOTE : L’utilisatio de routage sur interfaces VTI serait une alternative avantageuse (voir
CSNA)
197
VPN IPSec avancé
NAT DANS IPSEC

VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ Étoile / chainage
➔ NAT dans IPSec
Nomade: mode config
Failover IPSec
198
VPN IPSec avancé
NAT DANS IPSEC
• SNAT ava t l’e t e des pa uets da s le tu el

• DNAT pour les paquets en provenance du tunnel
VPN Réseau Virtuel A → Réseau Virtuel B
Réseau A Réseau B
Net- A (réel) Firewall A Firewall B
Net- B (réel)
192.168.0.0/24 192.168.0.0/24
Net-A-virtuel Net-B-virtuel
192.168.11.0/24 192.168.22.0/24
Il faudra décider d’un plan d’adressage « virtuel » qui remplacera les adresses réelles
lors des communications au travers du tunnel IPSec
22
Les cas d’usage nécessaires de cette fonction de NAT dans IPSec sont les suivants :
• Recouvrement complet ou partiel des plans d’ad essage des réseaux à relier
• Recouvrement de l’u des plans d’ad essage avec un réseau déjà connu par
l’aut e site (par exemple, un réseau joignable par le biais d’u e route statique
ou d’u autre tunnel IPSec)
• Obligation de présenter, en sortie de tunnel, une adresse spécifique imposée
par l’ad i ist ateu de l’u des sites.
Les opérations de NAT sont nativement conçues pour opérer des modifications dans les
couches de transports (IP et TCP).
Il suffit donc ici d’appli ue une opération de NAT sur l’IP source (SNAT) avant que le
datagramme ne soit envoyé dans le tunnel IPSec, puis de restituer l’ad esse IP réelle de
la cible des datagrammes provenant du tunnel en en modifiant la destination, par une
opération de DNAT.
Il faut donc d’a o d choisir judicieusement des plans d’ad essages qui serviront
d’ad esses virtuelles pour chaque réseau. Ces plans d’ad essages seront décrits par des
objets réseaux. Le masque des « réseaux virtuels » devra être le même que celui des
réseaux réels.
Les opérations de NAT devront appliquer une transformation de manière à faire
correspondre une IP du réseau virtuel à chaque adresse du réseau réel.
199
VPN IPSec avancé
NAT DANS IPSEC
Bimap net_A →net_VIRT_A avec option NAT inside IPSec
La politique VPN est en accord avec les adresses qui se présenteront à IPSec
23
La méthode la plus simple pour réaliser ces transformations de type « n sur n » sera
d’utilise des translations statiques (bimap) de réseaux.
Ces règles de NAT ayant pour but de couvrir un cas spécifique, il sera préférable de les
placer en tête de politique. Il est également recommandé de les décrire avec le
maximum de critères pour s’assu e u’elles ne seront appliquées que dans les cas
spécifiques prévus; ci-dessus, le critère Net-B-Virtuel a été ajouté dans le champ
destination de la règle de SNAT et dans le champ source de la règle de DNAT, afin de les
rendre toutes deux très précises et donc très spécifiques.
200
VPN IPSec avancé
SITE À SITE AVEC

CERTIFICATS ISSUS DE
PLUSIEURS AUTORITÉS
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ NAT dans IPSec
➔ Site à site avec certificats issus de plusieurs autorités
Nomade: mode config
Failover IPSec
201
VPN IPSec avancé
AUTHENTIFICATION IKE/IPSEC PAR CERTIFICAT
Intérêts du certificat par rapport à la PSK :

• Révocation
• Durée de vie limitée
• Taille de clé
• Identification unique par client
Réseau A Réseau B
Cn=a-team-CA Cn=b-team-CA
Ou=IT Ou=IT
O=cieA O=cieB
L=VDA L=Lyon
ST=NPdC ST=AURA
C=Fr C=Fr
25
Ce mode d’authe tifi atio des correspondants IPSec est utilisable sur IKEv1 ou IKEv2
En remplacement d’u e identité portée par une simple chaîne de caractères associée à
une clef pré-partagée, il est possible de faire représenter les identités de correspondants
IKE/IPSec par des certificats numériques.
Cette méthode présente l’ava tage d’i pose aux correspondants la détention d’u e
identité :
• Dont l’ etteu devra être une autorité de confiance (CA),
• Dont l’i t g it est vérifiable par la signature de l’auto it ,
• Dont la durée de validité est par défaut limitée dans le temps,
• Dont la validité peut être écourtée par une révocation anticipée et une
inscription en CRL,
• Dont la chaîne « Subject » pourra, optionnellement, être définie comme
contrainte obligatoire dans la description du correspondant.
En IKEv1, dans le cas particulier des clients mobiles, cette méthode d’authe tifi atio
par certificat permet également de mener les négociations en mode Main, plus sécurisé
que le mode Aggressive.
202
VPN IPSec avancé
IPSEC PAR CERTIFICAT : SITE-À-SITE AVEC PLUSIEURS CA
Import des certificats de CA
26
Pour un tunnel site-à-site, des certificats serveurs seront bien adaptés pour identifier les
correspondants.
Dans le cas où les deux correspondants sont des entreprises distinctes, il sera possible
que chacun utilise un certificat issu de sa propre autorité. La reconnaissance de l’ide tit
du tiers sera alors basée sur la confiance accordée à l’Auto it de Certification (CA)
tierce. Il faudra donc que les deux correspondants se procurent une copie du certificat
de la CA tierce et l’i po te dans le menu Objets > Certificats et PKI.
Les deux correspondants disposent chacun d’u e identité sous la forme d’u certificat
serveur et d’u e clé privée :
• Le certificat du firewall A a été émis par la CA de l’e t ep ise A (a-team-CA),
• Le certificat du firewall B a été émis par la CA de l’e t ep ise B (b-team-CA).
Les certificats contiennent un champ « Issued by » (« émis par ») suivi du nom de

l’auto it qui les a émis. Ce champ est vérifié au moment de la réception d’u certificat
tiers pendant les négociations IKE.
Ce nom de CA est recherché dans la liste des autorités de confiance déclarées. S’il en est
absent, l’auto it ’est pas de confiance, donc le tiers non plus. On aura le log IKE/IPSec
suivant :
• IKEv1 :
Certificate with serial 9F93F855 from issuer
/C=FR/ST=fr/L=there/O=b-team/OU=IT/CN=b-team-CA/emailAddress=admin-
pki@b-team.com:
unable to get local issuer certificate
• IKEv2 :
No CA found for peer certificate
NOTE : Si le certificat présenté par le correspondant est signé par une CA intermédiaire
« CA2 », cette CA2 est donc elle-même approuvée par une autorité « CA1 » de niveau
supérieur. Chacune des CA doit être explicitement déclarée autorité de confiance.
203
VPN IPSec avancé
27
La configuration des correspondants permet de définir :

• L’o jet de type hôte avec qui négocier le tunnel,
• Le certificat à présenter au tiers lors des négociations.
Le certificat encadré ici sera celui présenté par le firewall A à son correspondant
IKE/IPSec FW_B.
204
VPN IPSec avancé
Pour être accepté un correspondant doit :
• Présenter un certificat :
– Provenant d’une CA de confiance
– Valide (date d’expiration et d’émission)
– Non inscrit dans la liste de révocation (CRL)
• Générer une signature valide (prouver qu’il possède la clé

privée)
28
Le panneau de configuration du correspondant ne permet pas de sélectionner

explicitement le certificat du tiers comme identité attendue. Il ’ a aucun champ prévu
pour y sélectionner le certificat du tiers dont on détiendrait une copie.
Ce mécanisme inhiberait complètement les vérifications d’usage sur le certificat :
• CA de confiance
• Signature valide
• Période de validité respectée
• Inscription à la liste de révocation (CRL)
Selon cette méthode, la seule exigence serait de recevoir un certificat identique à la

copie détenue dans la configuration.
L’a se e de CRL pouvant simplement signifier u’au u certificat ’a été révoqué, ne

génère pas d’ he . Avec IKEv1 on a un avertissement : Certificate with serial A17818F7
from issuer /C=FR/ST=here/O=a-team/OU=IT/CN=a-team-CA: unable to get certificate
CRL.
Si en revanche une CRL est présente, il est impératif que celle-ci soit en cours de validité.
Sinon, tout certificat issu de la CA correspondante sera considéré comme invalide,
puis u’il sera impossible de vérifier son inscription à la CRL qui ’a pas été renouvelée.
• Avec IKEv1 la négociation échouera avec le log : Certificate with serial A17818F7 from
issuer /C=FR/ST=here/O=a-team/OU=IT/CN=a-team-CA: CRL has expired
• Avec IKEv2 la négociation se fait mais avec un avertissement : CRL expired since Dec
25 12:02:03 2019
Référez-vous au chapitre PKI pour tout complément d’i fo atio sur l’i po t et le
maintien à jour des CRL.
205
VPN IPSec avancé
SITE À SITE AVEC

CERTIFICATS ISSUS
D’UNE SEULE AUTORITÉ
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ NAT dans IPSec
✔ Site à site avec certificats issus de plusieurs autorités
➔ Site à site avec certificats issus d'une seule autorité
Nomade: mode config
Failover IPSec
206
VPN IPSec avancé
IPSEC PAR CERTIFICAT : SITE-À-SITE AVEC UNE CA
Réseau A Réseau B
Cn=a-team-CA
Ou=IT
O=cieA
L=VDA
ST=NPdC
C=Fr
30
Un seul des deux sites dispose d’u e CA qui devra:

• Signer les certificats serveur pour les deux sites,
• Être ajoutée à la liste des CA de confiance sur les deux sites car le site B va se
présenter avec un certificat serveur issu de cette CA,
• Il faudra donc que le site B se procure une copie du certificat de la CA centrale.
Les deux correspondants disposent chacun d’u e identité sous la forme d’u certificat
serveur :
• Le certificat du firewall A a été émis par sa CA locale (a-team-CA)
• Le certificat du firewall B a été émis par la CA du firewall A (a-team-CA)
L’ad i ist ateu de la CA centrale peut extraire le certificat du site B dans un format
PKCS12 afin de lui transmettre de manière sécurisée.
Dès réception du conteneur PKCS12, le site B peut alors l’i po te depuis le menu
Objets > Certificats et PKI.
207
VPN IPSec avancé
IPSEC PAR CERTIFICAT : SITE-À-SITE AVEC UNE CA
Réseau A Réseau B
31
Chacun des sites doit impérativement ajouter la CA centrale à la liste des autorités de
confiance. Dans le cas contraire, l’ide tit du correspondant ne pourra être approuvée.
Même si la CA centrale est locale au site A, elle doit néanmoins être ajoutée aux
autorités de confiance dans le menu VPN IPSec pour valider la chaine de parenté du
certificat présenté par le correspondant B.
Si la CA signataire du certificat présenté est absente de la liste des CA de confiance, on

aura la même erreur quand dans le cas précédent :
• IKEv1 :
Certificate with serial A17818F7 from issuer /C=FR/ST=here/O=a-
team/OU=IT/CN=a-team-CA: unable to get local issuer certificate
• IKEv2 :
No CA found for peer certificate
208
VPN IPSec avancé
SITE À SITE PAR

CERTIFICATS AVEC
DEFINITION DU PEER ID
= SUBJECT
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ NAT dans IPSec
✔ Site à site avec certificats issus d'une seule autorité
➔ Site à site par certificats avec définition du peer id = subject
Nomade: mode config
Failover IPSec
209
VPN IPSec avancé
IPSEC PAR CERTIFICAT : DESCRIPTION DU SUBJECT DU

CORRESPONDANT
33
Le champ Subject du certificat pourra être ajouté comme contrainte obligatoire dans le
champ Peer ID de la configuration du correspondant.
Le Subject d’u certificat constitue une chaîne descriptive de l’ide tit d’u
correspondant.
Le correspondant pourrait être une machine (correspondant IPSec) ou un utilisateur
(client nomade).
Pour le cas d’u firewall, le certificat à utiliser sera préférentiellement de type « server ».
L’usage veut que dans ce cas, le sujet contiennent un CN (CommonName) qui coïncide
avec le FQDN (nom d’hôte aussi appelé nom DNS) du correspondant IPSec.
Le Subject du correspondant pourra être renseigné selon plusieurs syntaxes :

Syntaxe 1 (valide sur IKEv1 ou IKEv2)
C=FR, ST=Hauts-de-France, L=vda, O=trainer-new, OU=training, CN=SN200.trainer.net
Syntaxe 2 (valide uniquement sur IKEv1) :

C=FR/ST=Hauts-de-France/L=vda/O=trainer-new/OU=training/CN=SN200.trainer.net
Quelque soit la syntaxe, il est possible de décrire le sujet partiellement en utilisant des
« wildcards » : C=FR/ST=Hauts-de-France/L=vda/O=trainer-new/OU=*/CN=*
NOTE :
• Toute erreur de syntaxe dans cette chaîne entraînera un défaut de chargement de la
politique et peut même conduire à l’i possi ilit de démarrer le daemon en charge
des négociations IKE pour IPSec.
• La vérification de cette contrainte sur le « Subject » ’est effectuée que par le firewall
dont le rôle dans la négociation est « responder ».
210
VPN IPSec avancé
NOMADE PAR
CERTIFICAT
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ NAT dans IPSec
✔ Site à site par certificats avec définition du peer id = subject
➔ Nomade par certificat
Nomade: mode config
Failover IPSec
211
VPN IPSec avancé
IPSEC PAR CERTIFICAT : CLIENT NOMADE
@pub_fw
Ressources locales
35
L’appli atio VPN Stormshield Network est disponible en téléchargement sur votre
espace privé. Une version d’essai de trente jours est incluse par défaut. Pour utiliser
l’outil sans limite de date, une licence définitive doit être souscrite.
212
VPN IPSec avancé
• Principales différences :
– type d’identité utilisée
– extrémités de tunnels et de trafic distantes
• Ce type de tunnel est couramment appelé « Tunnel

Anonyme »
36
Ce type de configuration est applicable à :

• Des tunnels « site-à-site » avec des firewalls possédant une adresse IP
dynamique (au lieu d’u e adresse IP fixe),
• Des clients nomades utilisant un client VPN Stormshield ou The Greenbow
(seul clients couverts par notre Support Technique).
213
VPN IPSec avancé
1 2
37
Seule l’ext it de trafic locale doit être sélectionnée (1)

Ici, les ressources à rendre joignables par IPSec sont localisées sur Network_in.
L’ext it de trafic distante (2) est prédéfinie sur « Tous » par l’assista t. Elle est
supposée être imprévisible car, pour le cas des nomades, elle dépend de ce que le client
présentera pendant la phase 2; en fonction de sa configuration et du réseau dans lequel
il se trouve au moment de la négociation.
Tous a donc comme signification « Any » en tant u’e tit IP indéfinie ; ’est-à-dire
’i po te quelle adresse ou plan d’ad essage.
214
VPN IPSec avancé
Création de la configuration du correspondant : nommage

de la configuration et choix du mode d’authentification
1
4
38
L’assista t présenté ici permet de :

• Choisir un nom pour la configuration des correspondants dynamiques,
• Sélectionner le mode d’authe tifi atio par certificat,
• Sélectionner le certificat présenté par le firewall.
L’i pl e tatio IKEv2 actuelle sur les firmwares Stormshield ne permet pas une
authentification en mode Hybride, ni par Certificat + Xauth.
L’assista t de création de la configuration d’u correspondant nomade IKEv2 ne

proposera donc que PSK et Certificat.
215
VPN IPSec avancé
39
216
VPN IPSec avancé
40
En IKEv1, le mode de négociation est positionné à MAIN; le champ LocalID peut être
laissé vide car le certificat suffit à porter l’ide tit .
L’i te fa e graphique ne permet pas de basculer sur du mode AGGRESSIVE ; en cas de

besoin, cette modification reste cependant possible en mode commande. Vous
trouverez la procédure détaillée dans notre base de connaissance accessible sur
https://mystormshield.eu.
217
VPN IPSec avancé
41
La définition du nomade nécessite ensuite la création d’u e identité utilisateur. Le

certificat sera présenté par le nomade lors de l’ tape d’ide tifi atio en phase 1. Il doit
donc impérativement être signé par une autorité de confiance.
Si la PKI est locale au firewall, l’ad i ist ateu peut exporter depuis le menu
Configuration > Objets > Certificats et PKI l’ide tit numérique du client nomade dans
un conteneur PKCS12 afin de la transmettre à l’utilisateu par une voie sécurisée.
Lors de la négociation de phase 1, l’adresse e-mail du certificat est recherchée dans

l’a uai e par défaut et dans la liste des annuaires ajoutés dans la configuration avancée
si l’optio Activer la recherche dans plusieurs annuaires LDAP (mode clé prépartagée et
certificats) est activée.
Cette vérification permet de faire le lien avec un utilisateur existant, puis de contrôler
son droit à l’utilisatio de tunnels IPSec et enfin, de récupérer son login pour
l’authe tifie automatiquement dans l’ASQ.
Pour que la montée du tunnel (et donc l’authe tifi atio de l’utilisateu fonctionne, il
est donc impératif u’u utilisateur possédant cette adresse e-mail existe dans
l’a uai e.
Si le firewall ’est pas connecté à un annuaire LDAP (interne ou externe), la présence de

l’auto it émettrice dans la liste des autorités de confiance et la validité du certificat
seront suffisantes pour légitimer le correspondant.
218
VPN IPSec avancé
42
Le lien avec le LDAP permet (et oblige) d’auto ise les utilisateurs, globalement ou
individuellement, à négocier un tunnel IPSec.
L’ide tit de l’utilisateu est désormais connue. Il faut néanmoins s’assu e que
l’utilisateu concerné dispose du droit VPN IPSec dans le menu Droits d’accès VPN.
Si le droit ’est pas attribué (individuellement ou globalement), le log VPN User Denied
sera alors remonté.
219
VPN IPSec avancé
La politique de filtrage doit explicitement permettre les

négociations et les flux constituants le tunnel
43
Pour les tunnels nomades, aucune règle implicite ’existe, leur IP étant par définition
imprévisible.
Il est donc nécessaire d’auto ise explicitement ces flux par des règles de filtrage.
Les règles qui permettent de définir les flux autorisés au travers du tunnel IPSec peuvent
se baser sur l’utilisateu authentifié. En effet, une fois le tunnel monté, l’utilisateu est
authentifié dans l’ASQ.
220
VPN IPSec avancé
Dans le client renseigner les mêmes paramètres phase 1

que sur le firewall
44
Phase 1 :
• Interface : permet de spécifier l’i te fa e réseau depuis laquelle les
négociations seront menées. La valeur « Any » laissera au système le soin de
sélectionner l’i te fa e permettant de joindre la destination désignée dans le
champ Adresse routeur distant.
• Adresse routeur distant : désigne l’ad esse IP du firewall à contacter pour les
négociations IKE/IPSec.
• Certificat : identité de l’utilisateu . En sélectionnant ce choix, vous devez
importer l’ide tit (certificat + clé privée) au format PEM ou inclus dans un
conteneur PKCS12 dans le magasin de certificats du client VPN STORMSHIELD.
Le certificat est automatiquement sélectionné pour la prochaine négociation
de phase 1.
• Cryptographie : contient les paramètres souhaités pour la proposition de
phase 1.
221
VPN IPSec avancé
L’authentification par certificat sur IKEv1 permet d’utiliser le

mode Main : décocher la case Aggressive Mode
45
Le champ Local ID est non modifiable et grisé. Il est automatiquement renseigné par le
sujet du certificat importé précédemment.
Si le mode de négociation ’est pas équivalent à celui paramétré sur le firewall, le log
VPN « Not acceptable mode » sera levé.
222
VPN IPSec avancé
46
Phase 2 :
• Dans l’e ad Adresses :
• Adresse du client VPN : permet de spécifier l’ad esse qui sera
positionnée en source des flux du client nomade avant leur
chiffrement. Le forçage d’u e adresse sur chaque client nomade
permettra de les individualiser et rendra donc plus aisée une
corrélation des logs de connexions sur le firewall avec les logs des
serveurs auxquels les clients nomades accéderont. De plus, un choix
pertinent de cette adresse permettra aussi de limiter très largement
les risques de recouvrement de plan d’ad essage entre les réseaux
connus sur, et autour du firewall, et les réseaux à partir desquels les
clients nomades opéreront.
En effet, si cette adresse ’est pas spécifiée, le client positionnera,
comme source des flux avant encapsulation, l’ad esse IP réelle utilisée
par la machine cliente.
• Type d’adresse : indique ici une adresse réseau
• Adresse réseau distant / Masque réseau : indiquent l’ad esse et le
masque du réseau que le client joindra par le tunnel IPSec
• ESP / PFS : spécifient les paramètres de la proposition de phase 2
223
VPN IPSec avancé
IKEv1
IKEv2
47
Les logs VPN font apparaître la vérification des droits utilisateur pendant la phase 1, puis
son authentification à l’issue de la phase 2.
Il apparaît également que le client nomade a positionné l’ad esse IP 192.168.227.1 dans
sa configuration comme extrémité locale de trafic (champ Adresse du client VPN vu
précédemment).
224
VPN IPSec avancé
• Les utilisateurs authentifiés et les tunnels sont visibles

dans le monitoring
48
La politique IPSec pour un client nomade ’est effective et donc présente u’à partir du
moment où la phase 2 a été négociée.
L’ext it de trafic présentée par le client est l’ad esse IP qui a été forcée dans sa
configuration (si ce paramètre ’est pas spécifié, l’ad esse présentée sera l’ad esse IP
réelle du poste client).
L’ad esse e-mail du certificat présenté comme identité du client pendant la phase 1
permet de faire le lien avec le login utilisateur dans l’a uai e LDAP et de l’authe tifie
directement dans l’ASQ.
Le nom de l’utilisateu est alors associé à l’ad esse IP u’il a présentée en extrémité de
trafic lors de la phase 2.
La durée initiale de l’authe tifi atio correspond à la durée de vie de la phase 2 ’est-à-
dire des IPSec-SA).
En complément de l’authe tifi atio de l’utilisateu , une requête LDAP est envoyée pour
récupérer la liste des groupes auquel il appartient.
225
VPN IPSec avancé
NOMADE: MODE XAUTH

(IKEV1 UNIQUEMENT)
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ NAT dans IPSec
✔ Nomade par certificat
➔ Nomade: mode xauth (IKEv1 uniquement)
Nomade: mode config
Failover IPSec
226
VPN IPSec avancé
IPSEC PAR CERTIFICAT : CLIENT NOMADE + XAUTH
Annonce de XAUTH lors de la

négociation phase 1
Demande d’affichage explicite du popup

ou informations pré-remplies
50
Le mode Xauth demande à l’utilisateu de prouver son identité (en complément du

certificat) en renseignant un couple Identifiant + mot de passe.
Depuis Stormshield VPN Client, les informations requises par le mode Xauth peuvent
être renseignées manuellement par l’utilisateu dans un pop-up qui s’affi he lors de la
négociation de la phase IKE ou pré-remplies directement dans la configuration du client
IPSec. La méthode à privilégier reste cependant la saisie interactive du login/password.
Xauth représente donc une authentification à deux facteurs :

• Le certificat constitue le facteur détenu par l’utilisateu ,
• Le couple login/mot de passe constitue le facteur connu par l’utilisateu .
La méthode d’authe tifi atio associée à l’utilisateu va dépendre de la politique

d’authe tifi atio configurée sur le firewall.
227
VPN IPSec avancé
IPSEC PAR CERTIFICAT : CLIENT NOMADE + XAUTH
51
La méthode d’authe tifi atio à appliquer dépend du choix de la méthode

d’authe tifi atio par défaut.
Certaines méthodes comme Kerberos par exemple, nécessitent des informations
complémentaires pour fonctionner convenablement (comme l’ad esse du serveur à
contacter ainsi que le port d’ oute du service d’authe tifi atio .
228
VPN IPSec avancé
NOMADE: MODE
HYBRIDE (IKEV1
UNIQUEMENT)
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ NAT dans IPSec
✔ Nomade: mode xauth (IKEv1 uniquement)
➔ Nomade: mode hybride (IKEv1 uniquement)
Nomade: mode config
Failover IPSec
229
VPN IPSec avancé
IPSEC PAR CERTIFICAT : XAUTH + MODE HYBRIDE
Configuration côté client
Configuration côté serveur
53
Lors de la phase 1, seule la passerelle IPSec va prouver son identité au client avec un
certificat. Le client, quant à lui, prouvera son identité grâce au mode Xauth
(authentification nom d’utilisateu + mot de passe).
Sur IKEv1, le mode hybride est resté à l’ tat de draft. L’IETF le référence sous le nom
draft-ietf-IPSec-isakmp-hybrid-auth-05.txt.
Sur le firewall, la configuration du mode hybride est définie dans les paramètres du
correspondant, par le champ méthode d’authe tifi atio .
Sur le client VPN Stormshield Network, le mode hybride s’a tive dans les paramètres
avancés de la phase 1 et nécessite le mode Xauth ainsi u’u e authentification par
certificat. Même si le client ne prouve pas son identité dans ce mode, cela permet de
présenter un certificat dont le payload est vide comme le précise le draft.
En théorie, dans ce mode, le client et la passerelle sont autorisés à initier le tunnel. Dans
la pratique, le client sera toujours à l’i itiative de la négociation de la phase 1 puis u’il
s’agit d’u e configuration anonyme).
Par ailleurs, la transaction des données liées au mode Hybride, doit être initiée par la
passerelle. Cette transaction est protégée par la clef ISAKMP négociée précédemment
durant la phase 1. Si l’utilisateu ne parvient pas à s’authe tifie (mauvais mot de passe
par exemple) la SA-ISAKMP sera alors détruite.
230
VPN IPSec avancé
NOMADE: MODE CONFIG

VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ NAT dans IPSec
✔ Nomade: mode hybride (IKEv1 uniquement)
➔ Nomade: mode config
Failover IPSec
231
VPN IPSec avancé
IPSEC PAR CERTIFICAT : CLIENT NOMADE + MODE CONFIG
Attribution d’une adresse IP, d’un serveur DNS au client
Ressources locales
@pub_fw
Phase 1 mode principal

Plage d’ad esses
pour clients IPSec Transaction des données
config mode
Phase 2
55
Le mode Config est souvent comparé à un service DHCP. Bien que cette fonction
permette de fournir une adresse IP au client IPSec ainsi que l’ad esse IP d’u éventuel
serveur DNS à joindre, son mécanisme protocolaire ne fait aucunement usage du
protocole DHCP.
Sur IKEv1, le mode Config ’est pas standardisé dans une RFC, mais est resté à l’ tat de
draft (draft-ietf-IPSec-isakmp-mode-cfg-05).
Sur IKEv2, ’est une fonctionnalité standard du protocole.
La phase de transaction des données du mode config doit impérativement s’effe tue
une fois la SA-ISAKMP établie et avant que la négociation de la SA-IPSEC ’ait
commencée, puisque cette négociation de phase 2 nécessite une extrémité de trafic. Par
conséquent, tant que le client ’a pas obtenu d’ad esse IP, il ne peut démarrer cette
phase.
232
VPN IPSec avancé
56
L’utilisatio de l’assista t « Nouvelle politique Mode Config » permet de sélectionner le

réseau nomade. L’o jet utilisé ici représente les adresses IP qui seront délivrées aux
clients nomades IPSec qui utilisent le mode config.
Trois types d’o jets peuvent être utilisés dans le champ Réseau nomade : un réseau, une
plage d’ad esses ou une machine.
Si vous activez le mode config sur une politique nomade qui ’a pas été ajoutée depuis
l’assista t, un pop-up vous demandera de sélectionner le réseau nomade, comme ci-
dessous:
233
VPN IPSec avancé
Configuration côté serveur
Configuration côté client VPN
57
La sélection du mode config sur le client VPN Stormshield s’effe tue depuis les
paramètres avancés de la phase 1 pour IKEv1; et pour IKEv2 dans l’o glet Child_SA par
l’optio Obtenir la configuration depuis la passerelle
Un tunnel monté créera sur le poste client une carte réseau virtuelle (VPN TGB) dont
l’ad esse IP fait partie du pool (nommé net_mode_config dans l’exe ple ci-dessus) et
dont l’ad esse IP du serveur DNS à contacter est celui annoncé par la passerelle (DNS_srv
dans l’exe ple .
234
VPN IPSec avancé
FAILOVER IPSEC
VPN IPSEC AVANCÉ
Programme du module
✔ Rappels
✔ NAT- Traversal
✔ NAT dans IPSec
✔ Nomade: mode hybride (IKEv1 uniquement)
✔ Nomade: mode config
➔ Failover IPSec
235
VPN IPSec avancé
IPSEC FAILOVER : TUNNEL DE SECOURS
Un correspondant IPSec peut disposer d’un correspondant de

secours en cas de défaillance. Par conséquent, les extrémités
de trafic restent joignables mais le tunnel est négocié
entre d’autres adresses publiques. Réseau B
@pub B1
@pub B2
@pub A
: Tunnel principal
: Tunnel de secours
Réseau A
59
Les réseaux internes A et B communiquent actuellement grâce à un tunnel négocié entre

@pu A et @pu B . Le DPD, obligatoirement actif pour le bon fonctionnement de
cette fonction, détecte soudain que la SA-ISAKMP ’est plus valide ; en d’aut es termes
que le correspondant @pu B ’est plus joignable (routeur en amont HS ou problème
de routage par exemple). Les SA de phases 1 et 2 du tunnel sont alors supprimées.
Démarre alors une nouvelle négociation avec le correspondant de secours du site @pu
B , à savoir @pu B2 .
Les réseaux A et B peuvent continuer à communiquer, cette fois-ci grâce au tunnel

négocié entre les adresses publiques @pu A et @pu B2 .
Dans la SPD, un couple d’ext it s de trafic (locale et distante) ne peut être associé
u’à un correspondant à la fois. Par conséquent, en cas de détection d’u correspondant
injoignable, la SPD est actualisée avec la nouvelle adresse IP à contacter pour monter le
tunnel.
Sur le firewall, le fichier qui est actualisé en cas de modification de la SPD est
/var/tmp/racoon.conf.
236
VPN IPSec avancé
correspondant de secours
mode de secours
activation du DPD
60
Dans le champ Configuration de secours, sélectionnez le correspondant avec lequel le

tunnel sera négocié dans le cas où le DPD considère que l’IP utilisée dans Passerelle
distante ’est plus joignable.
Dans la configuration avancée du correspondant, il faut impérativement que le DPD soit

actif. Le cas contraire, aucune vérification sur la disponibilité du correspondant ne sera
effectuée et donc la bascule vers le correspondant de secours ne pourra opérer.
Les différentes valeurs de tests du DPD sont détaillées dans le chapitre consacré à cette
fonction.
Le mode de secours, sélectionné par défaut à Temporary , consiste à revenir sur le

correspondant principal dès que celui-ci est de nouveau opérationnel. Pour cela le DPD
va continuer d’i te oge le site principal afin de détecter son retour. La modification du
mode de secours ne peut s’effe tue u’e ligne de commande.
Le second mode disponible, nommé Permanent , permet de maintenir le tunnel en

cours actif même s’il s’agit du tunnel de secours et que le correspondant principal est de
nouveau accessible. Ce mode peut être intéressant dans le cas où le routeur distant
présente des coupures intempestives (afin d’ vite des bascules de tunnels trop
fréquentes).
237
VPN IPSec avancé
Modes de secours: Temporary et Permanent
Réseau B
@pub B1
@pub B2
@pub A
: Tunnel principal
: Tunnel de secours
Réseau A
61
Mode Temporary : Le tunnel est monté entre @pub A et @pub B (tunnel principal). Le
DPD détecte que le correspondant @pub B ’est plus joignable, la négociation bascule
entre @pub A et @pub B2 (correspondant de secours). Si le correspond @pub B est à
nouveau joignable, alors une nouvelle bascule aura lieu pour utiliser le tunnel principal.
Mode Permanent : Le tunnel est monté entre @pub A et @pub B (tunnel principal). Le
DPD détecte que le correspondant @pub B ’est plus joignable, la négociation bascule
entre @pub A et @pub B2 (correspondant de secours). Si le correspond @pub B est à
nouveau joignable, le tunnel de secours reste actif. Pour re-basculer sur le tunnel
principal, il faudrait que le DPD détecte une indisponibilité du correspondant @pub B.
238
VPN IPSec avancé
IPSEC FAILOVER : EN FONCTION DE LA SOURCE
Réseau B
: Tunnel principal
@pub B
: Tunnel de secours
R1
@pub A
R2
@pub A2
Réseau A
62
Il ’est pas tout à fait correct de parler de failover IPSec en fonction de la source puisque
ce mécanisme ne dépend pas du module IPSec mais de passerelle par défaut active au
moment de la négociation (donc du module de routage).
Dans l exe ple ci-dessus, le firewall A dispose de deux adresses IP publiques (@pub A et
@pub A2). Le tunnel principal est monté entre @pubA et @pubB. L’ad i ist ateu du
site A aimerait que le tunnel se négocie entre @pubA2 et @pubB en cas de défaillance
de sa première interface publique.
Pour ce faire, il suffit d’utilise un objet routeur comme passerelle par défaut. Cet objet
aura la passerelle R1 définie en principale et R2 en secondaire.
239
VPN IPSec avancé
Avec cette configuration, la politique chargée par le moteur IPSec utiliserait l’ad esse IP
de l’i te fa e connectée à la passerelle par défaut (R1) pour négocier le tunnel. Si on
détecte que le routeur R1 ’est plus opérationnel, la route par défaut du firewall sera
modifiée par l’ad esse IP du routeur R2 et l’ext it locale de tunnel serait mise à jour
avec l’ad esse IP de l’i te fa e connectée à ce routeur (en l’o u e e @pub A2).
Afin de vérifier le fonctionnement du routeur en amont, il est nécessaire de choisir une

machine (ou un groupe de machines) dans la colonne Équipement pour tester la
disponibilité. Dans ce cas, le firewall va émettre des pings à destination de la machine
sélectionnée via le routeur. Si le firewall ne reçoit pas de réponse aux pings émis (la
fréquence est modifiable en console uniquement), la passerelle par défaut bascule vers
la machine présente dans la section passerelle de secours (le routeur R2 dans notre
exemple).
Pour que la SPD soit mise à jour avec la nouvelle extrémité locale de tunnel, il faut
s’assu e que la passerelle locale, dans la configuration avancée du correspondant, soit
positionnée à « Any ». Ainsi, ’est sur la table de routage que se basera la sélection de
l’i te fa e à utiliser et donc de l’ad esse IP locale à utiliser pour construire la politique et
négocier le tunnel.
Il serait également possible d’assu e partiellement du failover IPSec sur des routes de
type PBR passant par les interfaces VTI (Virtual Tunneling Interface) de deux tunnels
distincts; cette architecture implique que les correspondants possèdent chacun deux
liens Internet distincts. Les VTI seront alors désignées comme objets routeurs, la
configuration requise devient équivalente à du failover de routes; les flux pouvant passer
par l’u ou l’aut e des deux tunnels montés en permanence.
Cette configuration ne supporte cependant pas le cas où chaque firewall perdrait un lien
Internet
Vous pouvez vous référer aux chapitres Objets Routeurs et VPN IPSec de la formation
CSNA pour la manipulation de ces fonctions.
240
VPN IPSec avancé
IPSEC FAILOVER : LIMITATION ET DOCUMENTATION
• DPD actif obligatoire

• Le correspondant de secours ne peut pas avoir de correspondant de secours
lui aussi
• Failover source + destination : fonctionnel mais non supporté
• De nombreux exemples dans la base de connaissance « Some examples of
IPSec Failover policies»
64
Avec l’i pl e tatio actuelle un correspondant de secours ne peut pas avoir de

correspondant de secours.
Exemple : si B est le correspondant de secours de A, alors B ne peut pas avoir de
correspondant de secours lui aussi.
L’i te fa e graphique ne limite pas cette configuration mais elle ne sera ni fonctionnelle,
ni prise en compte par notre service support technique.
Le failover sur la source et la destination en même temps ’est pas une opération
supportée. Elle est décrite dans la base de connaissances car elle peut fonctionner en
respectant toutes les conditions mais aucune aide de la part du support technique ne
sera apportée pour la mise en œuv e ou le débug de cette fonctionnalité en production.
L’a ti le « Some examples of IPSec Failover policies » de la base de connaissances

(disponible depuis votre espace privé), recense de nombreux cas de failover ainsi que les
bonnes pratiques à adopter pour mettre en place cette fonctionnalité. Chaque scénario
est composé d’u schéma illustrant la situation et d’u tableau récapitulatif des
paramètres sur les deux firewalls participant à la négociation IPSec.
241
VPN IPSec avancé
• Configurer les tunnels IPSec de manière sécurisée
• S’assurer de la provenance des flux entrants
• Déclarer les interfaces VPN comme internes
• Configurer les tunnels nomades en mode config
• Activer le DPD
• Maitriser le champ DSCP
65
Lo s u’u VPN IPSec est configuré, il est recommandé de :

• Ajouter une route statique à destination de la boucle locale pour joindre les
réseaux distants. Cela empêchera les paquets de sortir du réseau si le tunnel ’est
pas monté (les SPD étant prioritaires par rapport aux routes statiques).
• Toujours utiliser des politiques IPSec plus large que les règles de filtrage. Ainsi, si
un paquet ’est pas filtré, il est chiffré mais ne sort pas en clair.
Dans une règle de filtrage en provenance d’u réseau joignable via un tunnel IPSec, il
est recommandé de toujours préciser l’optio via tunnel VPN IPSec. Sinon, on
s’expose au risque d’a epte des paquets usurpés venant d’u e autre interface.
Afin de profiter de la fonctionnalité d’antispoofing sur les interfaces IPSec, il est

recommandé de les déclarer comme internes. Cela se fait dans le menu
Configuration > Protection applicative > Profils d’inspection dans le cadre
Propriétés avancées.
Afin de maitriser totalement les adresses IP données aux clients nomades, il est
recommandé de les configurer systématiquement en mode config.
Afin de ne pas laisser des tunnels dans un état inconnu en cas de déconnexion du
correspondant, il est recommandé de toujours activer le DPD, au moins en mode
passif.
Par défaut, la valeur du champ DSCP est répliquée sur le paquet chiffré. En cas de
besoin de sécurité renforcée, il est recommandé de forcer sa valeur pour limiter la
divulgation d’i fo atio s.
242
VPN IPSec avancé
LAB 7 : VPN IPSEC AVEC CERTIFICATS
66

• Interfaces virtuelles IPsec
• Intégration du NAT dans IPsec
• Tunnels VPN SSL
• VPN IPSec : Authentification par clé pré-partagée
• VPN IPSec : Authentification par certificats
• VPN IPSec : Configuration Hub and Spoke
Et pour les situations/questions très spécifiques, consultez la base de connaissance du

TAC kb.stormshield.eu.
243
TUNNELS GRE ET
GRETAP
✔ P ve tio d’i t usio

✔ Proxy SSL
✔ VPN IPsec avancé
➔ Tunnels GRE et GRETAP
244
TUNNEL GRE
TUNNELS GRE ET GRETAP
Programme du module
➔ Tunnel GRE
Tunnel GRETAP
245
PRINCIPE DE FONCTIONNEMENT
172.18.1.0/31 Interfaces of the GRE tunnel 172.18.1.1/31
GRE_A GRE_B
OUT_A OUT_B
Network A
Network B
192.168.1.0/24 @IP_A @IP_B 192.168.2.0/24
FW A FW B
IP TCP/UDP Data IP TCP/UDP Data
IP GRE IP TCP/UDP Data
MTU of a GRE interface = 1476 = 1500 – 20 – 4 bytes
GRE (Generic Routing Encapsulation) est un protocole d’e apsulatio qui permet de
transporter un paquet de couche 3 (réseau) dans un autre paquet de la même
couche. Conçu initialement par CISCO, il est devenu par la suite un standard de l’IETF
(RFC 2784). Son identifiant de protocole est 47 et son entête est constitué de 4
octets obligatoires qui renseignent principalement sur la version du protocole GRE
(version=0) et l’ID du protocole transporté. L’e t te peut contenir en plus des
champs optionnels.
Le protocole GRE permet d’ ta li un tunnel GRE au niveau IP entre deux réseaux

distants (192.168.1.0/24 et 192.168.2.0/24), illustré dans la figure ci-dessus. Le
tunnel GRE ’off e aucune sécurité, il est établi entre deux adresses IP
communicantes (@IP_A et @IP_B) sans authentification et les flux sont transmis en
clair à l’i t ieu du tunnel.
Pour configurer un tunnel GRE, une interface GRE doit être créée sur chaque firewall
(GRE_A et GRE_B). Les deux interfaces portent des adresses IP faisant partie du
même réseau « 172.18.1.0/31 ». Les extrémités du tunnel (@IP_A et @IP_B) sont
renseignées sur chaque interface.
246
Pour accéder à un réseau distant via un tunnel GRE, il suffit d’ajoute des routes
statiques. Pour l’exe ple ci-dessus, une route statique doit être ajoutée sur le
firewall A pour rendre accessible le réseau B via la passerelle GRE_B « 172.18.1.1 ».
Une route statique doit être également ajoutée sur le firewall B pour rendre
accessible le réseau A via la passerelle GRE_A « 172.18.1.0 ».
Ainsi, les paquets IP du réseau interne sont encapsulés à l’i t ieu de paquets GRE
qui sont également encapsulés dans des paquets IP ayant comme adresses source et
destination les adresses IP des extrémités du tunnel.
NOTE :
• Les adresses IP des interfaces GRE ’appa aisse t pas dans l’e t te GRE, ni dans le
datagramme IP transporté par GRE, car ces interfaces agissent comme des
routeurs. Par conséquent, leurs adresses IP ne seront pas visibles dans une
capture du trafic GRE, sauf si une communication IP avait lieu avec elles ou entre
elles.
• Le routage dynamique peut être utilisé comme une alternative au routage
statique pour découvrir les réseaux accessibles via le tunnel GRE.
247
• L’interface GRE est configurée par défaut comme une

interface externe
• L’interface GRE ne peut pas être ajoutée à un bridge
• Le tunnel GRE n’encapsule pas les flux broadcast :

DHCP
• L’encapsulation d’un tunnel GRE à l’intérieur d’un autre

tunnel GRE n’est pas supporté par défaut
– sysctl net.link.gre.max_nesting=X (par défaut X=1)

– Maximum théorique de X = 256
L’i te fa e GRE est configurée par défaut comme une interface externe, cependant,
elle peut être configurée comme une interface interne.
248
CRÉER UNE INTERFACE GRE
• Firewall A
• Firewall B
La création d’u e interface GRE s’effe tue dans l’o glet INTERFACE GRE du menu
CONFIGURATION ⇒ RÉSEAU ⇒ Interfaces virtuelles. Pour cela, il faut ajouter une
ligne et configurer les champs suivants :
• État : Permet d’a tive /d sa tive l’i te fa e,
• Nom : Nom logique de l’i te fa e qui est différent du nom système (gre0, gre1,
etc),
• Adresse IP : de l’i te fa e qui doit appartenir à un plan d’ad esse privé différent
de tout autre plan d’ad essage IP déjà connu sur d’autres interfaces du firewall,
• Masque réseau : de l’i te fa e. Il est recommandé d’utilise un masque en /30
parce que le tunnel GRE est un tunnel point à point qui possède seulement deux
extrémités, par conséquent deux adresses IP seront suffisantes,
• Source du tunnel : L’ad esse IP de l’ext it locale du tunnel,
• Destination du tunnel : L’ad esse IP de l’ext it distante du tunnel.
• Protégée : Permet de configurer l’i te fa e GRE comme une interface protégée
(interne) ou publique (externe). Ce paramètre est caché par défaut.
NOTE : Depuis la V3.3.0, il est possible de configurer un réseau /31 pour les
interfaces GRE qui ’o t pas besoin des adresses réseau et broadcast.
249
ACCÉDER À UN RÉSEAU VIA UN TUNNEL GRE
• Firewall A
• Firewall B
Pour permettre l’a s à un réseau distant via le tunnel GRE, il suffit de définir une
route statique vers ce réseau.
La création de la route statique s’effe tue dans l’o glet ROUTAGE STATIQUE du menu
CONFIGURATION ⇒ RÉSEAU ⇒ Routage. Les paramètres suivants doivent être
renseignés dans la route statique :
• Le réseau de destination : Correspond au réseau distant accessible via le
tunnel GRE,
• La passerelle : Correspond à l’ad esses IP de l’i te fa e GRE distante,
• Interface : Le nom de l’i te fa e GRE locale.
250
FILTRAGE ET NAT POUR UN TUNNEL GRE
• Firewall A
• Firewall B
Dans les règles de filtrage, il faut autoriser en premier le trafic GRE entrant entre les
extrémités de tunnel; le trafic sortant est autorisé par une règle implicite.
Par la ensuite, il faut autorisé le trafic des réseaux qui communiquent via le tunnel.
Pour ces dernières règles, il est conseillé de préciser les interfaces source et
destination.
En ce qui concerne la translation d’ad esse, elle est appliquée sur le trafic avant
l’e apsulatio GRE.
251
EXEMPLE D’UTILISATION : PROBLÉMATIQUES DE ROUTAGE
172.18.1.0/31 172.18.1.1/31
GRE_A GRE_B
OUT_A OUT_B
Network A 192.36.242.200/24 192.36.252.10/24 Network B

192.168.1.0/24 192.168.2.0/24
FW A FW B
FW C
192.36.242.100/24 192.36.252.20/24
Network C
192.168.1.0/24
Les tunnels GRE permettent de résoudre des problématiques de routage dont un

exemple est illustré ci-dessus. Dans ce cas de figure, il est impossible de faire
communiquer le réseau A et le réseau B en utilisant le routage statique via le FW C
parce que ce dernier possède un réseau C configurée avec le même plan d’ad essage
que le réseau A. Le trafic du réseau A vers le réseau B est bloqué par le FW C à cause
d’usu patio d’ad esse IP type=2 parce que FW C reçoit du trafic sur l’i te fa e
externe d’u réseau configuré sur son interface interne. Dans le sens inverse, le trafic
du réseau B vers le réseau A est routé vers le réseau C.
252
EXEMPLE D’UTILISATION : TRANSMISSION DES FLUX MULTICAST
172.18.1.0/31 172.18.1.1/31
GRE_A GRE_B
OUT_A OUT_B
@IP_A @IP_B
FW A FW B
Radio1: 239.1.1.100 Radio1: 239.1.1.100

Radio2: 239.1.1.101
Radio2: 239.1.1.101
TV1 : 239.1.1.200
TV1 : 239.1.1.200
10
Le multicast permet la transmission d’u flux vers un groupe de destinataires

identifié par une adresse IP multicast ( classe D : 224.0.0.0/8 à 239.255.255.255/8).
Ce mode de transmission est utilisé principalement pour les flux multimédia temps
réel (Radios, TVs, conférences, etc.) pour économiser de la bande passante dans le
réseau.
Cependant, les flux multicast ne sont toujours pas routables sur Internet ce qui rend
impossible la transmission de ce type de flux entre deux sites distants. Pour faire
face à ce problème, les tunnels GRE peuvent être utilisés pour encapsuler les flux
multicast et permettre leur transmission via un réseau qui ne le supporte pas.
Dans ce cas de figure, le routage statique multicast doit être utilisé pour router le
flux multicast entre les interfaces.
253
EXEMPLE D’UTILISATION : TRANSMISSION DES FLUX MULTICAST
• Configuration du Firewall A (FW_A)
• Configuration du Firewall B (FW_B)
11
Les captures ci-dessus illustrent la configuration des deux firewalls pour la

t a s issio d’u flux ulti ast via u tu el GRE.
254
EXEMPLE D’UTILISATION : GRE VIA UN VPN IPSEC
172.18.1.0/31 Example 1 172.18.1.1/31
GRE_A GRE_B
@IP_A @IP_B
OUT_A IPSec VPN OUT_B
FW A FW B
172.18.1.0/31 172.18.1.1/31
Example 2
GRE_A GRE_B
@IP_VTI_A @IP_VTI_B
VTI_A IPSec VPN VTI_B
12
Comme le tunnel GRE ’off e aucun service de sécurité, il est possible de

transmettre les flux GRE via un tunnel VPN IPSec selon deux configurations possibles
illustrées ci-dessus dans les exemples 1 et 2 :
1. Les adresses IP des extrémités du tunnel GRE peuvent être renseignées

comme extrémités de trafic dans les paramètres du tunnel VPN IPSec
(même si ces adresses sont également les extrémités du tunnel VPN
IPSec) qui sera limité seulement au protocole GRE.
2. Dans le cas où les extrémités de trafic du tunnel VPN IPSec sont des
interfaces VTI, il suffit de renseigner les adresses IP de ces interfaces
comme extrémités de tunnel dans les paramètres des interfaces GRE.
255
EXEMPLE D’UTILISATION : GRE VIA UN VPN IPSEC (EXEMPLE 1)
13
Les captures ci-dessus illust e t la o figu atio d’u tu el GRE via un VPN IPSec
su le fi e all A selo l’exe ple 1.
256
EXEMPLE D’UTILISATION : GRE VIA UN VPN IPSEC (EXEMPLE 2)
14
La o figu atio de l’exe ple 2 est illust e da s les captures ci-dessus.
257
TUNNEL GRETAP
TUNNELS GRE ET GRETAP
Programme du module
✔ Tunnel GRE
➔ Tunnel GRETAP
258
bridge bridge
192.168.10.253/24 Interfaces of the GRETAP tunnel 192.168.10.254/24
IN GRETAP_A GRETAP_B IN
OUT_A OUT_B
Network A @IP_A @IP_B Network B

192.168.10.0/24 192.168.10.0/24
FW A FW B
MAC IP TCP/UDP Data MAC IP TCP/UDP Data
IP GRE MAC IP TCP/UDP Data
MTU of a GRETAP interface = 1462 = 1500 – 20 – 4 – 14 bytes
16
Le protocole GRE peut être utilisé pour l’e apsulatio d’u e trame de couche 2
(Ethernet) dans un paquet de couche 3 (IP). Ceci permet d’i te o e te au niveau
2 (bridge) deux réseaux distants faisant partie du même plan d’ad essage IP comme
l’illust e la figure ci-dessus.
Pour cela, une interface GRETAP doit être créée sur chaque firewall (GRETAP_A et
GRETAP_B). Chaque interface GRETAP est incluse dans un bridge qui contient
également le réseau u’o souhaite interconnecter. Ainsi, les deux réseaux
communiquent comme s’ils étaient connectés au même bridge (switch). Les
extrémités du tunnel (@IP_A et @IP_B) sont renseignées dans les paramètres de
chaque interface GRETAP.
L’e apsulatio d’u e trame Ethernet permet au tunnel GRETAP de faire transiter
entre les deux réseaux du trafic transmis en broadcast : ARP, DHCP, NetBIOS, etc..
L’i te fa e GRETAP possède les mêmes propriétés u’u e interface Ethernet; une
vitesse de media (fictive) de 10G full-duplex et une MTU de 1462 octets.
259
AJOUTER UNE INTERFACE GRETAP
17
La création d’u e interface GRETAP s’effe tue dans le menu CONFIGURATION ⇒

RÉSEAU ⇒ Interfaces en cliquant sur le bouton Ajouter => Ajouter une interface
GRETAP.
Une nouvelle fenêtre s’affi he pour renseigner les paramètres de la nouvelle

interface :
• Le nom logique de l’i te fa e qui est différent de son nom système (gretap0,
gretap1, …),
• L’i te fa e sera dans la plupart des cas incluse dans un bridge existant,
• Source et destination du tunnel représentent respectivement l’ad esse IP locale et
distante des extrémités du tunnel.
L’i te fa e GRETAP possède les mêmes paramètres u’u e interface Ethernet. Elle se
distingue seulement par les adresses IP des extrémités de tunnel qui se trouvent
dans l’e ad Adresse du tunnel GRETAP.
260
FILTRAGE ET NAT POUR UN TUNNEL GRETAP
18
À l’i sta d’u tunnel GRE, il faut autoriser le trafic GRE en entrée entre les
extrémités de tunnel GRETAP, une règle implicite l’auto ise en sortie. Il faut
également autoriser le trafic transmis via le tunnel GRETAP en ajoutant deux règles
de filtrage dont les critères de sources et de destination seront le plan d’ad essage IP
du réseau interne commun aux deux firewalls et connectable par le tunnel GRETAP.
Les interfaces physique « in » et GRETAP « GRETAP_INTF_A » doivent être
renseignées comme interface source respectivement pour les flux sortants et
entrants.
La translation d’ad esse est toujours appliquée sur le trafic avant encapsulation dans
le tunnel GRETAP.
261
EXEMPLE D’UTILISATION : GRETAP VIA VLAN
BRIDGE BRIDGE
IN GRETAP_A OUT OUT GRETAP_B IN
VLAN_100 VLAN 100 VLAN_100
@IP_VLAN_A @IP_VLAN_B
FW A FW B
MAC IP TCP/UDP Data MAC IP TCP/UDP Data
802.1q IP GRE MAC IP TCP/UDP Data
19
L’exe ple ci-dessous illustre la transmission d’u flux GRETAP via un VLAN. Pour cela,
les extrémités de tunnel renseignées dans les paramètres des interfaces GRETAP
doivent correspondre aux adresses IP des interfaces VLAN.
262
EXEMPLE D’UTILISATION : VLAN VIA GRETAP
IN GRETAP_A OUT_A OUT_B GRETAP_B IN
@IP_A @IP_B
VLAN1_100 VLAN2_100 BRIDGE_vlan100 BRIDGE_vlan100 VLAN1_100 VLAN2_100
VLAN3_200 VLAN4_200 BRIDGE_vlan200 BRIDGE_vlan200 VLAN3_200 VLAN4_200
FW A FW B
MAC 802.1q IP TCP/UDP Data MAC 802.1q IP TCP/UDP Data
IP GRE MAC 802.1q IP TCP/UDP Data
MTU of a GRETAP interface = 1458 = 1500 – 20 – 4 – 14 – 4 bytes
20
L’exe ple ci-dessous illustre la possibilité de transmettre deux VLAN via un tunnel
GRETAP. Pour chaque VLAN, il faut créer deux interfaces VLAN avec un VLAN ID
identique « VLAN1_100 » et « VLAN2_100 » qui seront rattachées respectivement
aux interfaces « IN » et « GRETAP_X ».
Cela revient à créer un bridge d’i te fa e VLAN pour chaque VLAN ID à faire transiter.
Les interfaces physique et GRETAP ne doivent pas être incluses dans le même bridge
que les interfaces vlan.
263
EXEMPLE D’UTILISATION : GRETAP VIA UN VPN IPSEC
BRIDGE BRIDGE
Example 1
@IP_A @IP_B
OUT_A IPSec VPN OUT_B
FW A FW B
BRIDGE BRIDGE
Example 2
@IP_VTI_A @IP_VTI_B
VTI_A IPSec VPN VTI_B
21
À l’i sta du tunnel GRE, il est possible de transmettre les flux GRETAP via un tunnel
VPN IPSec selon les mêmes configurations possibles, à savoir la méthode standard
(exemple 1) ou en utilisant les interfaces VTI (exemple 2).
264
EXEMPLE D’UTILISATION : AGRÉGATION DES LIENS GRETAP
BRIDGE BRIDGE
AGG @IP_A @IP_B AGG
GRETAP_A OUT_A OUT_B GRETAP_B

IN IN
GRETAP_C OUT_C OUT_D GRETAP_D
@IP_C @IP_D
FW A FW B
22
Pour les modèles de firewall qui disposent des interfaces d’ag gatio (SN510,
SN710, SN910, SN2000, SN3000 et SN6000), il est possible d’ag ge des interfaces
GRETAP dans une même interface d’ag gatio « AGG » pour augmenter le débit
entre les deux réseaux et pour assurer une tolérance aux pannes des liens.
265
LAB 8 – TUNNELS GRE ET GRETAP
23

• Encapsulation niveau 2

266
AUTHENTIFICATION
TRANSPARENTE

✔ Proxy SSL
✔ Tunnels GRE et GRETAP
➔ Authentification transparente
267
INTRODUCTION
AUTHENTIFICATION TRANSPARENTE
Programme du module
➔ Introduction
SPNEGO
Certificat SSL
Agent SSO (single sign-on)
Multi-utilisateurs
268
INTRODUCTION
• Les méthodes d’authentification
Les firewalls SNS implémentent plusieurs méthodes d’authe tifi atio qui peuvent
être classées en deux catégories :
• Les méthodes explicites via le portail captif : l’utilisateu est redirigé vers le
portail captif pour saisir un couple identifiant/mot de passe. Ces derniers sont
récupérés par le firewall pour vérifier l’ide tit de l’utilisateu en fonction de la
méthode utilisée : LDAP, RADIUS et KERBEROS. Trois autres méthodes
d’authe tifi atio explicites peuvent être utilisées pour des besoins spécifiques :
compte temporaires, invités et parrainage.
• Les méthodes implicites (transparentes) : l’authe tifi atio est transparente vis-
à-vis de l’utilisateu qui ’a pas besoin de saisir son couple identifiant/mot de
passe explicitement pour accéder au réseau.
NOTES :
• Le « multi-utilisateurs » avec la méthode cookie permet à plusieurs utilisateurs de
s’authe tifie depuis la même adresse IP. Étant donné que les utilisateurs sont
distingués par des cookies dans les requêtes HTTP, cette option fonctionne
seulement pour le flux HTTP et HTTPS avec un proxy SSL actif). Elle est disponible
avec toutes les méthodes d’authe tifi atio à l’ex eptio de l’age t SSO.
269
INTRODUCTION
• Les méthodes implicites (transparentes)
– Difficulté de gérer plusieurs mots de passe

– Potentielle négligence sur la complexité des mots de passe
utilisés
– Mécanisme SSO: une authentification pour plusieurs
applications
– Méthodes d’authentification transparente disponibles:
• SPNEGO
• Certificats SSL
• Agent SSO
Chaque utilisateur d’u réseau doit retenir un nombre important de mots de passe :
pour la connexion au poste de travail, pour l’a s à sa messagerie ou pour accéder à
diverses applications. Pour certains utilisateurs la gestion de multiples mots de passe
devient vite difficile et mène à un comportement négligent :
• Utilisation de mots de passe trop simples,

• Mots de passe identiques sur tous les systèmes,
• Mots de passe écrits sur des post-it ou dans un cahier.
Ce dilemme a donné lieu à la création du programme d’authe tifi atio unique, ou

SSO pour « Single Sign-On » en anglais, qui permet aux utilisateurs de pouvoir
s’authe tifie une seule fois pour accéder à toutes les ressources autorisées sans
devoir saisir les mots de passe liés à chaque application.
De ce principe découlent des méthodes d’authe tifi atio dites transparentes qui
permettent à un utilisateur d’ t e authentifié sur un système sans u’il ne renseigne
la moindre donnée d’authe tifi atio . Plusieurs méthodes d authe tifi atio
transparente sont proposées sur tous les firewalls de la gamme Stormshield
Network:
• SPNEGO,
• Certificats SSL,
• Agent SSO.
270
SPNEGO
Programme du module
✔ Introduction
➔ SPNEGO
Certificat SSL
Multi-utilisateurs
271
SPNEGO
• SPNEGO : introduction
Active Directory
SPNEGO est un système d’authe tifi atio dans lequel interagissent un client
connecté au domaine, un contrôleur de domaine (Microsoft Active Directory) et un
firewall Stormshield Network. Pour fonctionner, cette méthode d’authe tifi atio
s'appuie sur le proxy HTTP du firewall. Dès u’u client non authentifié ouvre son
navigateur pour joindre un site web en HTTP, la mécanique d’authe tifi atio
SPNEGO démarre afin d’authe tifie l’utilisateu de manière transparente et lui
donner accès au site.
Les données d’authe tifi atio sont transmises par le protocole Kerberos. Ce
protocole est particulièrement sensible au temps car les tickets Kerberos transmis
ont une durée de validité (date de début et date de fin). Par conséquent, veillez à ce
que l’e se le des éléments participant aux échanges soient synchronisés (la date,
l’heu e et le fuseau horaire).
Toutes les étapes d’i stallatio sont décrites dans la note technique SPNEGO
disponible sur https://documentation.stormshield.eu. Nous ne détaillerons ici que le
fonctionnement de la méthode et les paramètres à indiquer sur le firewall.
Le script « spnego.bat » est disponible via l’a ti le « Where can I find the last version
of the ''spnego.bat'' script? » dans la base de connaissances, accessible depuis votre
espace privé.
272
SPNEGO
• SPNEGO : fonctionnement
1 – Authentification sur le domaine
7
Active Directory 2 – Authentification autorisée
3 – Connexion vers un site web HTTP
4 – Redi e tio ve s le po tail d’authe tifi atio
8 5 – Le navigateur se connecte au portail
6 – Le fi e all e uie t des do es d’authe tifi atio
7 – Demande de ticket Kerberos
8 – Après vérification, envoi du ticket
1 9 – Envoi du ticket et validation par le firewall
10 – Redirection vers le proxy et accès au site
2
3
10
7
6
Fonctionnement
Toutes les étapes citées ci-dessous ne requièrent aucune action de la part du client,
exceptée l’ouve tu e d’u navigateur pour joindre en HTTP le site web u’il désire.
Étape 1 : L’utilisateu ouvre sa session sur le domaine de l’e t ep ise en tant que
USERNAME.
Étape 2 : Le contrôleur de domaine autorise l’authe tifi atio de USERNAME.
Étape 3 : L’utilisateu ouvre son navigateur WEB pour se connecter en HTTP au site
Internet de son choix.
Étape 4 : Le proxy HTTP intercepte la requête afin de rediriger le navigateur vers le
portail d’authe tifi atio . L’assista t « Règle d’authentification » dans le filtrage doit
être utilisée pour valider cette étape.
Étape 5 : Le navigateur se connecte de manière transparente au portail captif selon
le critère défini dans le menu Configuration ⇒ Système ⇒ Configuration
générale ⇒ Configuration avancée ⇒ Redirection vers le portail captif. Si ce critère
contient un nom (nom du firewall, FQDN), il faut s’assu e u’u e entrée DNS soit
créée sur le contrôleur de domaine pour résoudre ce nom.
Étape 6 : Le firewall informe le navigateur u’il doit lui fournir un ticket client
Kerberos associé à son service (SPN).
273
Étape 7 : Le navigateur demande au contrôleur de domaine d’asso ie le ticket fourni

lors de l’ ha ge numéro 2 au service SPN du firewall. L’asso iatio sera donc
effectuée entre USERNAME et HTTP/FW-NOMDNS
Étape 8 : Après avoir vérifié que l’utilisateu est effectivement authentifié sur le
domaine, le contrôleur de domaine fournit au navigateur WEB le ticket demandé
sous la forme d’u SECRET.
Étape 9 : Le navigateur WEB transfère le nouveau ticket USERNAME / HTTP/FW-
NOMDNS@Domaine au firewall qui déchiffre le contenu grâce à une clé commune
entre le contrôleur de domaine et le firewall. Cette clé s’appelle le keytab et est
négociée pendant l’ex utio du script SPNEGO. L’utilisateu est, à partir de cette
étape, authentifié dans l’ASQ pour une durée définie dans les paramètres « Durées
d’authentification autorisées » des interfaces internes du portail.
Étape 10 : Le navigateur est redirigé vers le site consulté à l’o igi e.
NOTES :
• Il ’ a pas d’i te a tio directe entre le firewall et le contrôleur de domaine.
• Assurez-vous que les horloges et la date du client, du firewall et du contrôleur de
domaine soient parfaitement synchronisées. Un écart de quelques minutes peut
entraîner un échec d’authe tifi atio (5 minutes par défaut avec un domaine
Active Directory).
274
SPNEGO
• Configuration du firewall étape 1
Configuration du firewall
Étape 1 : Dans le menu Configuration ⇒ Utilisateurs ⇒ Authentification ⇒
Méthodes disponibles , ajoutez la méthode SPNEGO. Les paramètres à renseigner
so t fou is lo s de l’ex utio du s ipt sp ego. at su le o t ôleu de do ai e.
Remarque : La syntaxe est importante, veillez à respecter les caractères en

majuscules et en minuscules.
Le fichier keytab est la clé permettant de déchiffrer les éléments d’authe tifi atio
transmis par le navigateur dans l’ tape 9 de la diapositive précédente. Ce fichier est
obtenu suite à l’ex utio du script spnego.bat.
Étape 2 : Dans l’o glet POLITIQUE D’AUTHENTIFICATION, ajoutez une règle qui
définit la méthode SPNEGO en précisant les utilisateurs et la source des connexions.
Dans le cas où la méthode SPNEGO est utilisée, et si le lien vers l’a uai e ’est pas
encore configuré sur le SNS, le domaine none peut être utilisé.
275
SPNEGO
10
Étape 3 : Dans l’o glet PORTAIL CAPTIF, attachez le profil d’authe tifi atio
internal à l’i te fa e depuis la quelle se connecteront les utilisateurs, dans l’exe ple
ci-dessus, ’est l’i te fa e « IN ».
Étape 4 : Dans l’o glet PROFILS DU PORTAIL CAPTIF, dans le profil internal,
sélectionnez l’a uai e qui sera utilisé par défaut et qui doit correspondre à
l’a uai e renseigné sur la règle d’authe tifi atio . Vérifiez dans les propriétés
avancées que la case Activer le portail captif est bien cochée.
276
SPNEGO
11
Étape 5 : Dans la politique de filtrage (menu Configuration ⇒ Politique de sécurité

⇒ Filtrage et NAT), ajoutez une règle d’authe tifi atio afin de rediriger vers le
portail captif les connexions HTTP à destination d’I te et pour les clients qui ne
sont pas encore authentifiés.
La deuxième règle à ajouter permet aux utilisateurs authentifiés d’a de à
l’I te et.
277
SPNEGO
• Cas particulier d’un cluster HA avec SPNEGO

– Création d’une identité serveur personnalisée
– Personnaliser le portail captif avec cette identité
12
Configuration du firewall dans le cas d’un cluster HA

Le fonctionnement de SPNEGO, lors de l’ tape 5,induit une redirection vers le portail
captif. Or, ce dernier peut contenir le nom du firewall (par défaut, son numéro de
série).
Dans le cadre d’u cluster de haute disponibilité, ce fonctionnement ’est pas

envisageable puisque le numéro de série des firewalls est unique. Par conséquent, il
faut créer un élément commun aux deux firewalls ; cet élément est un certificat.
Pour mettre en œuv e ceci sur le firewall, rendez vous dans le menu Configuration
⇒ Objets ⇒ Certificats et PKI, ajoutez une autorité racine puis une identité serveur
dont le nom remplacera FW-NOMDNS dans l’URL (my.company.com dans l’exe ple
ci-dessus). Ensuite, personnalisez le portail captif afin de présenter le certificat
correspondant à cette identité plutôt que le numéro de série du firewall. Pour cela,
rendez vous dans le menu Configuration ⇒ Utilisateurs ⇒ Authentification ⇒
Portail Captif » puis sélectionnez l’ide tit créée précédemment dans le champ
« Certificat (clé privée) ».
NOTE : Pour plus de détails sur la création d’ide tit s ou d’auto it s de certification,
veuillez vous reporter au chapitre PKI.
278
CERTIFICAT SSL
Programme du module
✔ Introduction
✔ SPNEGO
➔ Certificat SSL
Multi-utilisateurs
279
CERTIFICAT SSL
• Configuration : étape 1
• Configuration : étape 2
14
Introduction
La création de certificats SSL sur les SNS nécessite une CA. Pour toutes les
fonctionnalités relatives aux CAs, veuillez vous référer au chapitre correspondant.
Comme pour SPNEGO, la méthode d’authe tifi atio par certificats SSL requiert
l’a tivatio du proxy HTTP. Il est donc indispensable de mettre en place une politique
de filtrage URL ainsi u’u e redirection automatique vers le portail
d’authe tifi atio .
Configuration
Étape 1 : Pour activer la méthode d’authe tifi atio par certificats SSL, rendez-vous
dans le menu Configuration ⇒ Utilisateurs ⇒ Authentification ⇒ Méthodes
disponibles. Ici, ajoutez la méthode SSL. Cette méthode ne nécessite u’u seul
paramètre qui est la liste des autorités de confiance. Lo s u’u utilisateur présente
son certificat pour s’authe tifie , le champ « Émis par » du certificat contient la CA
qui l’a signé. Par conséquent, le firewall va consulter la liste des CA de confiance pour
confirmer la présence de cette autorité et valider ainsi l’authe tifi atio de
l’utilisateu . Les CA de confiance peuvent être internes (créées sur le firewall) ou
externes.
Étape 2 : Dans l’o glet POLITIQUE D’AUTHENTIFICATION, ajoutez une règle qui
définit la méthode SSL en précisant les utilisateurs d’u domaine spécifique et la
source des connexions. L’ l e t permettant de faire le lien entre l’utilisateu du
domaine et le certificat présenté est de préférence l’ad esse e-mail. En effet, il s’agit
d’u champ présent dans tout certificat utilisateur et dans la fiche descriptive de
l’utilisateu sur l’a uai e.
280
CERTIFICATS SSL
15
Étape 3 : Dans l’o glet PORTAIL CAPTIF, attachez le profil d’authe tifi atio
internal à l’i te fa e depuis laquelle se connecteront les utilisateurs, dans l’exe ple
ci-dessus, ’est l’i te fa e « IN ».
Étape 4 : Dans l’o glet PROFILS DU PORTAIL CAPTIF, dans le profil internal,
sélectionnez l’a uai e qui sera utilisé par défaut pour la recherche des utilisateurs
et qui doit correspondre à l’a uai e renseigné sur la règle d’authe tifi atio .
Vérifiez dans les propriétés avancées que la case Activer le portail captif est bien
cochée.
281
CERTIFICATS SSL
16
Étape 5 : Pour que l’utilisateu puisse présenter son certificat lo s u’il tente
d’a de à un site web d’I te et, il est impératif de créer une règle de redirection
automatique vers le portail d’authe tifi atio dans la politique de filtrage.
282
CERTIFICATS SSL
• Utilisation côté client et journalisation correspondante
17
Utilisation
Pour tester ce type d’authe tifi atio , l’utilisateu doit préalablement importer son
identité dans le magasin de son navigateur. Ensuite, pour tout accès à un site web en
HTTP, le client est redirigé vers le portail d’authe tifi atio
(https://adresse_IP_FW/auth/proxy.html) et doit présenter son certificat.
Afin de rendre cette authentification transparente par la suite, vous pouvez cocher la
case « Se souvenir de cette décision » (le nom de cette option dépend du navigateur
utilisé). Ainsi, pour les prochaines connexions, ce choix sera toujours appliqué et
l’utilisateu sera authentifié sur le firewall sans effectuer la moindre action.
La validation de toutes ces étapes entraîne la génération d’u log d’authe tifi atio
« user is logged in for 4 hours » associée à la méthode SSL.
283
CERTIFICATS SSL : CONFIGURATION
• Recherche multicritères et multi-annuaires
18
Depuis la V3.3.0, il est possible de spécifier plusieurs annuaires dans lesquels les
utilisateurs sont recherchés avec un ordre de priorité et en fonction de la valeur d’u
paramètre du certificat reçu durant l’authe tifi atio .
L’ajout des annuaires s’effe tue dans la configuration avancée de la méthode SSL en
activant la recherche dans plusieurs annuaires LDAP et en ajoutant une entrée dans
la liste des critères. Sur une entrée, il faut renseigner :
• Champ du certificat : le paramètre du certificat,
• Expression régulière : la chaîne à rechercher dans le paramètre du certificat. Ce
champ peut contenir une expression régulière (regex).
• Annuaire ou domaine : l’a uai e dans lequel il faut rechercher l’utilisateu .
284
AGENT SSO (SINGLE

SIGN-ON)
Programme du module
✔ Introduction
✔ SPNEGO
✔ Certificat SSL
➔ Agent SSO (single sign-on)
Multi-utilisateurs
285
AGENT SSO
• Fonctionnement de l’agent SSO

Active Directory Agent SSO
Interroge
Ouverture Authentification
de session Transparente
Client
20
L’authe tifi atio par la méthode agent SSO permet d’authe tifie les utilisateurs dès
l’ouve tu e d’u e session sur le domaine, elle se déroule en 3 étapes.
L’ouve tu e de session du client sur le domaine va générer un évènement

d’authe tifi atio répliqué sur l’e se le des contrôleurs de domaine Active
Directory d’u même domaine. Ces évènements portent les ID 4624 ou 4768 sur les
serveurs Windows 2008, 2012 et 2016.
L’age t SSO va ensuite consulter les journaux d’ v e e ts du contrôleur de

domaine. Sur réception d’u nouvel évènement, les informations liées à l’ad esse IP
et au nom du client sont transmises au firewall afin de les ajouter à la table des
utilisateurs authentifiés.
Les échanges entre l’age t et le firewall utilisent le port 1301/TCP et sont chiffrés
grâce au protocole SSL, algorithme PSK-AES256-CBC-SHA.
NOTES :
• Lo s u’elle est utilisée dans une règle, la méthode Agent SSO est
automatiquement la plus prioritaire des méthodes puis u’elle authentifie
l’utilisateu sur le firewall dès u’il ouvre une session sur son domaine.
• Pour l’i stallatio de l’age t SSO sur une machine, veuillez vous reporter à la note
technique disponible sur https://documentation.stormshield.eu.
286
AGENT SSO
• Configuration de la méthode Agent SSO : agents
21
La configuration de l’age t SSO s’effe tue depuis le menu Configuration ⇒

Utilisateurs ⇒ Authentification ⇒ Méthodes disponibles. Après ajout de la
méthode agent SSO, quelques paramètres sont à renseigner:
• Agent SSO : Regroupe les paramètres de connexion à l’agent SSO :

• L’o jet correspondant à l’ad esse IP du serveur où est installé l’age t SSO. Il
est possible d’i stalle l’age t sur le contrôleur de domaine. Consultez la
note technique pour plus d i fo atio s à ce sujet.
• Le port utilisé pour tout échange entre l’age t et le firewall. Par défaut, le
port agent_ad est sélectionné; sa valeur est 1301/TCP. Assurez-vous
d’ha o ise ce port avec celui configuré sur l’age t.
• La clé pré-partagée permettant le chiffrement des échanges entre l’Age t
SSO et le Firewall.
• Agent SSO de secours : Regroupe les paramètres de connexion à l’age t SSO de

secours dans le cas où le principal est inaccessible.
287
AGENT SSO
• Configuration de la méthode agent SSO :

– Contrôleurs de domaine
– Paramètres avancés
22
Contrôleur de domaine :
La listes des adresses IP des contrôleurs de domaine du domaine.
Paramètres avancés : durée :
Par défaut, via la méthode agent SSO, un utilisateur est authentifié pendant 10 heures. Ce
paramètre peut être modifié avec une valeur maximale de 24 heures, soit une journée.
Lorsque le contenu d’u groupe est modifié, l’i fo atio sera transmise à l’age t toutes les
heures. Pour modifier cette fréquence utilisez l’optio « Délai de mises à jour des groupes
d’utilisateurs ».
Paramètres avancés : méthode de détection des déconnexions
L’ v e e t levé sur un contrôleur de domaine pour indiquer la fermeture de session d’u
utilisateur ’est pas pris en compte par l’age t SSO. Par conséquent, nous avons implémenté
deux méthodes permettant de vérifier si la machine est toujours accessible afin de
désauthentifier l’utilisateu le cas échéant.
La première méthode disponible est l’e voi d’u ping depuis l’age t vers la machine
concernée. Si aucune réponse ’est reçue, l’utilisateu associé à cette adresse IP sera alors
considéré comme déconnecté après une période de temps configurable.
La seconde consiste à envoyer à la fois un ping, et, en cas de réponse, d’effe tue une
requête sur la base de registre de la machine sur laquelle l’utilisateu est authentifié. La
requête RPC s’effe tue sur les ports 139 ou 445. Assurez-vous que le pare-feu du poste
autorise ces connexions entrantes.
Comptes d’ad inistration ignorés
La section Comptes d’ad inistration ignorés recense les utilisateurs pour lesquels un
évènement d’authe tifi atio ’est pas transmis au firewall. Par défaut, cette liste inclut les
comptes Administrateur et Administrator pour éviter les événements d’authe tifi atio
générés lors de l’ouve tu e d’u programme en tant u’ad i ist ateu .
288
AGENT SSO
• Détection de changement d’adresse IP

Interroge
Ouverture Authentification
de session transparente
IP : 192.168.1.1
Client IP : 192.168.1.1 <-> Client
23
Lorsque l’utilisateu ouvre sa session sur le domaine, l’authe tifi atio transparente
effectuée par l’age t associe l’ad esse IP du poste à l’utilisateu sur le firewall.
289
AGENT SSO
• Détection de changement d’adresse IP

Requête DNS
Entrée DNS
Mise à jour de la
modifiée
table des utilisateurs
IP : 192.168.1.1
Client IP : 192.168.1.1 <-> Client

IP : 192.168.1.2
IP : 192.168.1.2 <-> Client
24
Imaginons que l’ad esse IP du poste (192.168.1.1 dans notre exemple) soit obtenue
par un serveur DHCP du réseau. Ce bail DHCP a une durée de vie limitée qui dépend
uniquement de la configuration du serveur. À expiration du bail, l’ad esse IP du poste
peut changer alors que l’utilisateu est associé à cette adresse sur le firewall.
Pour faciliter la mise à jour de la table des utilisateurs authentifiés du firewall, l’age t
effectue une requête DNS toutes les 60 secondes (valeur par défaut) afin de
consulter la liste des entrées DNS associées à l’utilisateu « Client ». Il constate que
seule la nouvelle adresse attribuée au client (suite à l’expi atio du bail) lui est
associée.
Il transmet donc la nouvelle association « Adresse IP <-> Nom d’utilisateu » au
firewall afin u’il mette à jour sa table des utilisateurs authentifiés avec la nouvelle
adresse IP.
La fréquence des requêtes DNS émises par l’age t peut être modifiée en suivant la
procédure suivante :
• Arrêter le service agent SSO,
• Éditer le fichier config.ini situé dans le répertoire d’i stallatio de l’age t
SSO,
• Localiser le champ DnsInterval et renseigner la valeur souhaitée,
• Pour information, le champ DnsEnabled permet d’a tive /d sa tive cette
fonctionnalité (par défaut active : True)
• Enregistrer le fichier et redémarrer le service agent SSO.
Si vous disposez de plusieurs contrôleurs de domaine, assurez-vous que les entrées

DNS soient synchronisées.
290
MULTI-UTILISATEURS
Programme du module
✔ Introduction
✔ SPNEGO
✔ Certificat SSL
✔ Agent SSO (single sign-on)
➔ Multi-utilisateurs
291
MULTI-UTILISATEURS
• Activation du multi-utilisateurs
26
Le multi-utilisateurs permet d’authe tifie et de distinguer plusieurs utilisateurs qui

se connectent depuis la même adresse IP.
Un serveur TSE (Terminal Service Edition) ou CITRIX qui autorise plusieurs utilisateurs
à accéder à des applications installées sur un serveur via une connexion RDP
(Remote Desktop Protocol) est un parfait exemple qui illustre le besoin du multi-
utilisateurs.
Il peut être activé avec toutes les méthodes d’authe tifi atio (implicite ou explicite)
utilisant le portail captif. Il ne fonctionne donc pas avec la méthode Agent SSO.
Pour l’a tive , il suffit d’ajoute l’o jet machine qui renseigne l’ad esse IP, depuis
laquelle se connecteront les différents utilisateurs, dans la fenêtre objets multi-
utilisateurs accessible depuis le menu Configuration ⇒ Utilisateurs ⇒
Authentification ⇒ onglet POLITIQUE D’AUTHENTIFICATION.
292
MULTI-UTILISATEURS
• Le multi-utilisateurs fonctionne seulement pour les flux

HTTP (et HTTPS si le proxy SSL est activé)
27
La distinction des utilisateurs se base sur des cookies fixés par le firewall lors de
l’authe tifi atio . Le navigateur ajoutera le cookie dans chaque requête HTTP
envoyée. Par conséquent, les utilisateurs peuvent être distingués seulement pour les
flux HTTP (et HTTPS si le proxy SSL est activé).
Les règle de filtrages définies pour des utilisateurs authentifiés et pour des flux
autres que HTTP, sont signalées par un message d’ave tisse e t et elle ne seront
pas utilisées.
293
MULTI-UTILISATEURS
• Les utilisateurs connectés depuis la même adresse IP

dans les journaux
28
294
LAB 9 : AUTHENTIFICATION TRANSPARENTE PAR CERTIFICAT
29

• Configuration SSO - Microsoft SPNEGO
• Configurer les méthodes d'authentification de type "Guest"
• Installation et déploiement SSO Agent

295
HAUTE DISPONIBILITÉ
✔ P ve tio d’i t usio

✔ Proxy SSL
✔ Tunnels GRE et GRETAP
✔ Authentification transparente
➔ Haute disponibilité
296
PRINCIPE DE
FONCTIONNEMENT
Programme du module
➔ Principe de fonctionnement
Créer un Cluster
Rejoindre un Cluster
Les Menus « haute disponibilité »
La supervision de la haute disponibilité
297
Schéma d’une architecture HA
Cluster HA
Slave Master
Master Master
Actif Passif
Lien de contrôle
Lien de contrôle secondaire

Passif Actif
La fonctionnalité « haute disponibilité » (HA : High Availability), présente dans toute

la gamme des produits Stormshield Network à l’ex eptio des modèles SN150,
SN160, SN200 et SN210, permet d’assu e la continuité de service en cas de panne.
Pour cela, l’a hite tu e doit être spécialement pensée : cela nécessite la duplication
des liens entre les réseaux (ici LAN et WAN). Sur chacun des liens, un firewall SNS est
disposé en coupure de connexion. Les deux firewalls sont reliés avec un ou deux
liens de contrôle (le deuxième lien est facultatif) sur des interfaces dédiées. Cette
configuration forme un cluster HA qui nécessite deux firewalls de gamme identique.
Ce cluster doit inclure au minimum un firewall disposant de la licence « Master »
pour la fonctionnalité « haute disponibilité ».
NOTE : Il ’ a aucune différence fonctionnelle entre les licences « Master » et

« Slave ». Cependant, un cluster ne peut pas être configuré avec deux firewalls
« Slave ».
Les firewalls d’u même cluster possèdent une configuration identique. Ils
fonctionnent en mode passif/actif : à un instant donné un seul firewall est actif et
gère l’e se le du trafic réseau ; l’aut e firewall est en mode passif. En cas de panne
du firewall fonctionnel, le firewall passif le détecte et bascule en mode actif pour
assurer la continuité des services.
NOTE : Si la communication entre les deux firewalls par les liens de contrôle est
interrompue, le firewall passif considèrera que le firewall actif ’est plus accessible
(fonctionnel) et passera en mode actif. Ceci provoquera un dysfonctionnement de
votre réseau parce que les deux firewalls seront actifs avec que les deux firewalls
seront actifs avec des adresses MAC identiques sur leurs interfaces.
298
• Les étapes de mise en place de la HA :

1
FW A FW B
Connecter les deux firewalls sur
des interfaces identiques :
• Lien principal
• Lien secondaire (facultatif)
2 3
Créer un cluster: Joindre le cluster :
• Configurer les interfaces HA • Configurer les interfaces HA
• Définir une clé pré-partagée • Re seig e l’ad esse IP du 1e fi e all et
la clé pré-partagée.
Le firewall :
• Télécharge les configurations HA et
réseau
• Charge les configurations
• Télécharge la configuration complète
• Charge la configuration et redémarre
4
La mise en place de la HA s’effe tue en 3 étapes :

1. Relier les deux firewalls avec un ou deux liens de contrôle en utilisant une ou
deux interfaces dédiées à la HA.
2. Créer le cluster sur l’u des deux firewalls (Master ou Slave) en configurant les
deux interfaces de contrôle avec deux adresses IP et en définissant une clé pré-
partagée. Les adresses IP utilisées par les interfaces HA doivent appartenir à
deux plans d’ad essage différents qui ne sont portés par aucune interface du
firewall.
3. Sur le deuxième firewall, rejoindre le cluster créé précédemment en configurant
également les deux interfaces de contrôle avec des adresses IP appartenant aux
mêmes plans d’ad essage utilisés dans le premier firewall. L’ad esse IP de l’u e
des interfaces HA (principale ou secondaire) de ce dernier et la clé pré-partagée
doivent être également renseignées. Le firewall qui rejoint le cluster effectue
automatiquement plusieurs opérations :
• Il télécharge les configurations HA et réseau du premier firewall,
• Il charge ces deux configurations,
• Il télécharge la totalité de la configuration du premier firewall,
• Il charge la nouvelle configuration et redémarre.
NOTE : Le firewall qui rejoint un cluster perd entièrement sa configuration qui est
écrasée par la configuration du premier firewall.
299
• Types de trafic échangés entre les deux firewalls :
Serverd TCP/1300
SSH/RSYNC (TCP/22)
Trafic Corosync unicast/multicast (UDP/5405)
Ping (ICMP echo request)
Kernel to Kernel synchronization
Différents types de trafic sont échangés entre les deux firewalls SNS pour la mise en
place et le fonctionnement d’u cluster HA :
• Trafic serverd (TCP/1300) : Utilisé par le firewall qui rejoint le cluster pour
récupérer les configurations HA et réseau.
• Trafic RSYNC dans une session SSH (TCP/22) : Permet au firewall qui
rejoint le cluster de télécharger les fichiers de configuration.
• Trafic Corosync unicast et multicast (UDP/5405) : Utilisé par les deux

firewalls pour l’ ha ge des messages en relation avec la HA et pour la
supervision du réseau HA sur les liens de contrôle.
• Trafic Ping (ICMP echo request) : Pour vérifier la communication réseau

d’u firewall.
• Trafic Kernel to Kernel : synchronisation des états de l’ASQ
NOTE : Ces différents types de trafic sont autorisés implicitement (règles de filtrage
implicite) entre les deux firewalls lors de la mise en place de la HA. Le trafic HA est
filtré par un plugin spécifique de l’ASQ (hasync). Si vous souhaitez désactiver la règle
implicite et la remplacer par une explicite, vous devrez le faire en ligne de
commande.
300
• Synchronisation dans un cluster :
– Synchronisation automatique :
• Les tables d’état (connexions, hôtes, etc)
• Les modules active update (signatures, antivirus, etc)
– Synchronisation manuelle : Les modifications de configuration.
• IMPORTANT : La synchronisation dépend des versions

des firmwares sur les deux firewalls.
La synchronisation des informations entre les firewalls d’u même cluster est :
• Automatique : Pour les tables d’ tats (connexions, hôtes, etc.) et les

modules active update, ce qui signifie u’a chaque fois u’il y a une
modification sur le firewall actif, elle est répliquée en temps réel sur le
firewall passif.
• Manuelle : Pour toute les modifications de configuration effectuées sur le

firewall actif. Pour cela, après une modification, une icône (encadrée en
rouge) s’affi he dans l’e t te de la page d’ad i ist atio pour signaler que
la configuration doit être synchronisée.
301
• Synchronisation dans un cluster : Version du firmware

identique sur les deux firewalls
Éléments répliqués Éléments non répliqués
• Les tables de connexions : • L’ tat des plugi s appli atifs à

TCP, UDP l’ex eptio de FTP et SIP
• Plugins applicatifs : FTP, SIP • Les connexions traversant un
• Les tables de hôtes proxy
• Configuration • Les connexions directes au
• LDAP et les utilisateurs firewall : SSH, VPN IKE V1
authentifiés • Les logs
• Les baux DHCP
• Connexions VPN IKE V2
Dans le cas où les deux firewalls utilisent la même version du firmware, les tableaux
ci-dessus résument les informations qui sont synchronisées et les informations qui
ne le sont pas.
NOTE : Il est possible de désactiver la synchronisation de connexions spécifiques.

Pour ce faire éditer la règle de filtrage décrivant les flux concernés : dans la fenêtre
d’ ditio de la règle, aller dans l’o glet Action > Configuration avancée, dans la
section Configuration avancée décochez la case Synchroniser cette connexion entre
les firewalls (HA).
302
• Synchronisation dans un cluster : Version du firmware

différente sur les deux firewalls (mode dégradé)
Lorsque les deux firewalls utilisent des versions de firmware différentes, la HA

fonctionne dans un mode dégradé.
La synchronisation manuelle des configurations affichera un message d’e eu qui

signale que les deux configurations ne peuvent être synchronisées.
Dans ce cas, le tableau des informations non synchronisées, présenté

précédemment, est toujours valide. Par contre, les informations synchronisées
dépendent de la version de trois modules (encadrée en bleu) : ASQ, Sync connexion
et basculement (protocole HA).
NOTE : Il est conseillé d’ vite le mode dégradé en utilisant la même version du

firmware sur les deux firewalls.
303
• Facteur de qualité :
�= � ��
σ�=1 ��ℎ� �
• �= �=��
σ�=1 ��ℎ� �
• Exemple :
× + × + ×75+ × + × + ×
• �= ≅ %
+ +75+ + +
Le facteur de qualité est un paramètre mathématique calculé à partir des états et

des poids des interfaces. Le poids des interfaces est configurable. Pour donner plus
d’i po ta e à u e i te fa e, il suffit d’aug e te so poids.
Ce facteur est calculé par chaque firewall et une comparaison des deux facteurs est
effe tu e lo s de l’ le tio du fi e all a tif.
304
• Élection du firewall SN Actif
Est-ce que le firewall va

s’ tei d e ?
Non
Est-ce que le firewall est Est-ce que le firewall a

forcé à être actif ? Oui Le firewall Oui le numéro de série le
passe actif plus élevé ?
Non
Non
Oui
Est-ce que les facteurs de
qualité des deux firewalls Est-ce que le firewall Est-ce que le firewall
Non Non
sont différents ? est prioritaire ? est déjà actif ?
10
L’ le tio du firewall actif suit le processus présenté dans la figure ci-dessus. Ce

processus est exécuté par chaque firewall au lancement de la HA.
Il est important de noter u’il est possible de forcer un firewall à être actif. Dans ce
cas, ce firewall sera actif même si son facteur de qualité est inférieur. Il est
déconseillé d’utilise cette option sur une ligne de production, elle est utilisée
principalement pour le débogage des configurations.
Cependant, il est possible de donner une priorité à un firewall pour u’il soit actif
dans le cas où les facteurs de qualité des deux firewalls sont égaux.
NOTE : Dans le mode dégradé, le processus d’ le tio du firewall actif est différent.
Dans la majorité des cas, le firewall qui a la plus ancienne version sera actif.
305
CRÉER UN CLUSTER
Programme du module
✔ Principe de fonctionnement
➔ Créer un Cluster
Rejoindre un Cluster
306
CRÉER UN CLUSTER
12
La création d’u cluster s’effe tue à l’aide d’u assistant dans le menu
CONFIGURATION ⇒ SYSTÈME ⇒ Haute disponibilité.
La première étape consiste à choisir si nous voulons créer ou rejoindre un cluster.
La deuxième étape permet de choisir et de configurer les interfaces HA. Le lien

secondaire est facultatif, cependant, il est conseillé de l’utilise afin de limiter le
risque d’avoi deux firewalls actifs dans le même réseau. Les adresses IP sur les deux
interfaces doivent appartenir à deux plans d’ad essage différents qui ne sont portés
par aucune interface du firewall.
307
CRÉER UN CLUSTER
13
La clé pré-partagée est définie dans la troisième étape et la dernière étape résume la
configuration des interfaces HA avant la création du cluster.
308
REJOINDRE UN CLUSTER
Programme du module
✔ Créer un Cluster
➔ Rejoindre un Cluster
309
15
Rejoindre un cluster existant s’effe tue également dans le menu CONFIGURATION ⇒

SYSTÈME ⇒ Haute disponibilité en sélectionnant la deuxième option dans la
première étape.
Les adresses IP des interfaces HA configurées dans la deuxième étape doivent
appartenir aux mêmes plans d’ad essage choisis lors de la création du cluster.
310
16
La troisième étape permet de renseigner l’ad esse IP de l’u e des interfaces HA

(principale ou secondaire) du firewall sur lequel le cluster a été créé. Elle permet
également de renseigner la clé pré-partagée nécessaire pour rejoindre le cluster.
Enfin, la dernière étape résume la configuration des interfaces HA avant de rejoindre
le cluster.
311
LES MENUS
« HAUTE DISPONIBILITÉ »
Programme du module
✔ Rejoindre un Cluster
➔ Les Menus « haute disponibilité »
312
LES MENUS « HAUTE DISPONIBILITÉ »
18
La création d’u cluster fait apparaitre deux nouvelles icônes dans l’e t te de la page
d’ad i ist atio WEB :
• Un raccourci pour accéder au menu Haute disponibilité,
• Un bouton pour synchroniser la configuration des deux firewalls (cette

icône s’affi he uniquement lorsque les configurations des deux firewalls
sont différentes) .
Le contenu du menu CONFIGURATION ⇒ SYSTÈME ⇒ Haute disponibilité est

modifié une fois le cluster créé. La croix en haut, à droite du menu permet de
reconfigurer la HA en relançant l’assista t.
Le menu permet la configuration de plusieurs paramètre dans la partie configuration

avancée :
• Modification de la clé pré-partagée,
• Forcer le firewall actif dans le cas où les facteurs de qualité des deux
firewalls sont égaux avec le paramètre Firewall actif en cas d’égalité. Par
défaut, la valeur automatique est sélectionnée, ce qui signifie que le
firewall actif est désigné par le processus d’ le tio .
313
19
• Activer la synchronisation selon la durée des connexions : Cette option

permet de ne synchroniser que les connexions dont la durée de vie a
atteint le seuil défini ici en secondes.
• Redémarrer les interfaces en bridge pendant le basculement : Cette

option permet de rafraîchir la table du bridge lors de la bascule en
redémarrant les interfaces de ce type.
• Activer l’agrégation de lien lorsque le firewall est passif : Cette option

permet d’ vite une latence (environ 30 secondes) engendrée par la
renégociation LACP après le basculement passif vers actif.
• Transmettre périodiquement des réponses ARP (ARP gratuit) : Cette

option active l’e voi de réponses ARP gratuites à la fréquence configurée
en secondes. Cela rafraîchira les tables ARP des machines voisines (hôtes,
switches et routeurs).
314
20
La atio d’u luste i t oduit des optio s et des pa a t es suppl e tai es

dans le menu CONFIGURATION ⇒ SYSTÈME ⇒ Maintenance :
• L’o glet Mise à jour du système : Un menu déroulant permet de

sélectionner le firewall où envoyer la mise à jour.
• L’o glet Restaurer : Un menu déroulant permet de sélectionner le firewall

sur lequel où restaurer la configuration.
315
21
• Onglet CONFIGURATION :
• Un menu déroulant permet de sélectionner le firewall à
redémarrer ou arrêter.
• L’e ad Haute disponibilité permet de sélectionner le firewall à

forcer en état actif.
316
22
Dans le menu CONFIGURATION ⇒ SYSTÈME ⇒ Licence, le paramètre Installer la

licence sur permet de sélectionner le firewall sur lequel mettre à jour la licence.
317
LA SUPERVISION DE LA
Programme du module
✔ Rejoindre un Cluster
✔ Les Menus « haute disponibilité »
➔ La supervision de la haute disponibilité
318
LA SUPERVISION DE LA HAUTE DISPONIBLITÉ
24
L’ tat de la HA peut être visualisé depuis le menu Supervision > Matériel / Haute
disponibilité qui permet entre autres de visualiser le firewall actif, les facteurs de
qualité, la version de firmware de chacun des deux firewalls, etc..
319
LAB 11 – HAUTE DISPONIBILITÉ
25

• Manuel d'utilisation et de configuration SNS

320
VIRTUAL LABS
321
322
Virtual Labs
SCHÉMA D’ARCHITECTURE
TRAINEE B
TRAINEE A
Graphical Machine Graphical Machine

Virtual Machine provided Virtual Machine provided
by Stormshield by Stormshield
OR OR
Physical host Physical host
192.168.1.254 192.168.2.254
192.36.253.10 192.36.253.20
WAN
172.16.1.254 172.16.2.254
192.36.253.1
DNS : 172.16.1.10
WEB : 172.16.1.11 DNS : 172.16.2.10
FTP : 172.16.1.12 WEB : 172.16.2.11
MAIL : 172.16.1.13 FTP : 172.16.2.12
MAIL : 172.16.2.13
Debian Virtual
Machine Debian Virtual
Machine
Les labs seront effectués en virtuel sous VirtualBox. La plateforme des labs est
présentée ci-dessus, elle est constituée de 2 sites (Trainee A et Trainee B) reliés entre
eux via un réseau externe « 192.36.253.0/24 ».
Chaque site possède un firewall SNS virtuel (EVA1), une machine virtuelle (abrégé VM
pour Virtual Machine) Debian qui embarque 4 serveurs (DNS, WEB, FTP et MAIL).
Par ailleurs, une machine cliente graphique permettant la navigation sur Internet et
ayant un compte utilisateur autorisé à modifier ses paramètres réseau.
Le choix de cette machine graphique est laissé au stagiaire :
• Machine virtuelle fournie par Stormshield (conseillée), l’e se le des TP peut être
effectué en mode « configuration complètement virtualisée », simplifiant ainsi la
configuration réseau à configurer avec VirtualBox, et permettant d’avoi une machine
graphique par site.
• Machine hôte du stagiaire (déconseillée), la configuration réseau devant permettre
que la machine hôte agisse en tant que PC soit sur le réseau A, soit sur le réseau B.
Deux réseaux privés sont configurés sur chaque site : IN « 192.168.x.0/24 » et DMZ :
« 172.16.x.0/24 ». La machine virtuelle Debian est connectée au réseau privé DMZ.
NOTE : Sur tous les firewalls, le mot de passe de l’utilisateu « admin » est « admin ».
323
Virtual Labs
CONFIGURATION COMPLÈTEMENT VIRTUALISÉE
TRAINEE A TRAINEE B
Internal Network Internal Network
LAN_DMZ1_A Debian LAN_DMZ1_B Debian

LAN_IN_A LAN_IN_B
NatNetwork
La configuration réseau des machines virtuelles est décrite sur la figure ci-dessus.
Elle permet d’a de à l’i te fa e Web du firewall SNS d’u site depuis la VM cliente
graphique déployée par OVA. Elle permet également aux firewalls de se connecter à
Internet via l’i te fa e « NatNetwork ».
NOTE : Le réseau VirtualBox « NatNetwork » doit être créé et configuré avant de

démarrer les machines virtuelles.
Les réseaux « Internal_Networks » sont déployés par import des l’OVA.
PRÉREQUIS : L’i f ast u tu e virtuelle complète décrite ci-dessus nécessite un

espace disque minimum de 11,5 Go (les VM fournies ont des disques à allocation
dynamique) et une mémoire RAM de 4,2 Go. Utilisez un hôte disposant de 8 Go de
RAM minimum pour un fonctionnement optimal.
324
Virtual Labs
CONFIGURATION VIRTUELLE + HÔTE PHYSIQUE
TRAINEE A TRAINEE B
LAN_DMZ1_A Debian LAN_DMZ1_B Debian
Virtualbox Host-only Virtualbox Host-only

Ethernet adapter #2 Ethernet adapter #3
NatNetwork
La configuration réseau des machines virtuelles est décrite sur la figure ci-dessus.
Elle permet d’a de à l’i te fa e Web du firewall SNS d’u site depuis l’hôte
physique. Après démarrage des machines virtuelles, la carte réseau « Virtual Host-
only Ethernet Adapter #X » du site que l’o ’utilise pas peut être désactivée.
La configuration permet également aux firewalls de se connecter à Internet via
l’i te fa e « NatNetwork ».
NOTES :
• Toutes les interfaces VirtualBox « Virtual Host-only Ethernet Adapter #X » et le
réseau virtualBox « NatNetwork» doivent être créés et configurés avant de
démarrer les machines virtuelles.
• Stormshield fournissant une VM permettant de faire tous les labs en virtualisation
complète, l’utilisatio de l’hôte physique ne sera pas détaillée dans ce document.
PRÉREQUIS : L’i f ast u tu e virtuelle avec hôte physique décrite ci-dessus nécessite
un espace disque minimum de 7,5 Go (les VM fournies ont des disques à allocation
dynamique) et une mémoire RAM de 2,2 Go. Utilisez un hôte disposant de 6 Go de
RAM minimum pour un fonctionnement optimal.
325
Virtual Labs
Installation et préparation de la plateforme virtuelle
1. Installez Virtualbox.
2. Créez l’i te fa e « NatNetwork » depuis VirtualBox dans le menu Fichier ⇒

Paramètres ⇒ Réseau ⇒ onglet Réseau NAT, configurez la avec le réseau WAN
« 192.36.253.0/24 » et désactivez l’optio « supporte le DHCP ».
Ajoutez le réseau
3. Si et seulement si vous ’utilisez pas la VM graphique fournie par Stormshield,

créez les 2 interfaces « Virtual Host-only Ethernet Adapter #X » (X=2-3) depuis
VirtualBox en cliquant sur Global Tools ⇒ Host Network Manager ⇒ Créez et
configurez leurs adresses IP comme suit :
• « Virtual Host-only Ethernet Adapter #2 » : 10.0.0.10/8

• « Virtual Host-only Ethernet Adapter #3 » : 10.0.0.20/8
Ajoutez l’i te fa e
4. Importez le package « CSNx-v4-FW-DEBIAN.ova » contenant un firewall et une

Debian, depuis le menu VirtualBox « Fichier ⇒ Importer un appareil virtuel » ⇒
cochez la case « Réinitialisez l’ad esse MAC de chaque carte réseau ». Le Firewall
est en configuration usine.
5. Si vous voulez utiliser la VM graphique fournie par Stormshield, importez le
package « Client_TRAINING_V1.x.ova ».
326
Virtual Labs
6. Vérifiez ou configurez les interfaces réseau des VM SNS, Debian, et VM

graphique selon le schéma de la page 4 (ou selon le schéma de la page 5 si
vous utilisez votre hôte physique). Ces VM sont sur le site de Trainee A.
Renommez les VM au besoin.
7. Clonez chaque VM, en cliquant droit sur une VM ⇒ Cloner. Dans l’assista t qui
se lance, renommez votre clone (les VM clonées seront sur le site de Trainee
B) et cochez la case « Réinitialisez l’ad esse MAC de chaque carte réseau ». Sur
la page suivante, cochez la case « Clone intégral » et cliquez sur le bouton
cloner (au lieu de cloner, il est également possible d’i po te à nouveau les
packages, le renommage des VM s’effe tue alors après import).
8. Modifiez les interfaces réseau pour les 3 VM, LAN_IN_A et LAN_DMZ1_A sont
renommées respectivement LAN_IN_B et LAN_DMZ1_B.
327
Virtual Labs
9. Démarrez les VM « SNS_EVA1_V4_A » et « Client_TRAINING_A ». Sur cette

dernière, ouvrez une session (identifiant : user ; mot de passe : user) et double
cliquez sur le raccourci bureau «network_config.sh », puis cliquez sur le bouton
« Run in Terminal ». Le firewall SNS étant encore en mode usine, l’optio
« sns » doit être choisie.
10. En lançant un terminal, vous pouvez vérifier que l’IP de votre carte réseau est
correcte avec la commande « ip address show » (format raccourci « ip a »), et
lancer un ping vers 10.0.0.254 (la connectivité avec le SNS est bien établie).
11. Recommencez les points 9 et 10 avec les VM du site B.
328
Virtual Labs
LAB 1 : Bases de configuration
1. Connectez-vous à l’i te fa e d’ad i ist atio du firewall (HTTPS).
2. Modifiez les préférences de l'interface graphique afin de rester connecté en permanence à la

console d'administration.
3. Paramétrez la langue (traces et clavier) et le fuseau horaire de votre firewall. Vérifiez que
votre firewall est à l’heu e après le redémarrage.
4. Activez le service SSH avec un accès par mot de passe.
5. Modifiez le mot de passe du compte admin (le nouveau doit être composé d'au moins 8
caractères).
6. Vérifiez que le stockage local des logs est activé sur le disque dur de la VM et activez
l’e se le des rapports embarqués.
Notes :
• Pour permettre le bon fonctionnement de chaque lab, vous devez effectuer les configurations
demandées sur le site A, puis sur le site B.
• Lors des labs, si vous levez une alarme « Attaque possible des ressources (connexion) », ’est
que vous avez atteint le nombre de connexions maximum autorisé par la licence de la VM
pédagogique. Dans ce cas, toutes les nouvelles connexions sont bloquées, patientez quelques
minutes, le temps que la table des connexions se purge, pour revenir à un comportement
normal.
329
Virtual Labs
LAB 2 : Suivi stateful en environnement routé
1. Nous débuterons les exercices en environnement routé (sans NAT). Configurez

les deux firewalls A et B comme indiqué sur le schéma principal. Votre passerelle
par défaut sur les firewalls est l’ad esse passerelle du réseau NatNetwork
192.36.253.1. Pour cela utilisez les VM Client_TRAINING_A et
Client_TRAINING_B.
2. Activez la politique de filtrage/NAT (10) Pass all sur tous les firewalls.
3. Sur le firewall B, déclarez une route statique vers le réseau A (192.168.1.0/24).

Autorisez ensuite l’a s à l’i te fa e web d’ad i ist atio du firewall depuis
l’hôte privé 192.168.1.2.
4. Depuis la VM Client_TRAINING_A, vous pouvez maintenant administrer le

firewall B. Pour cela, accédez à l’URL https://192.36.253.20/admin.
5. Reconfigurez le réseau de la VM Client_TRAINING_B. Dans VirtualBox attachez sa

carte réseau au réseau NAT NatNetwork. Puis configurez cette machine pour lui
donner l’ad esse IP 192.36.253.30/24 et la passerelle par défaut 192.36.253.20.
Pour cela tapez les commandes suivantes dans un terminal :
• su - • Élévation de privilèges à root
• ifdown enp0s3 • Désactivation de la carte réseau
(suppression de sa configuration)
• ifup enp0s3 • Activation de la carte réseau
• ip a add 192.36.253.30/24 dev enp0s3 • Ajout d’u e adresse IP à la carte réseau
• ip r add default via 192.36.253.20 • Ajout d’u e route par défaut via
firewall B
330
Virtual Labs
SCHÉMA LAB 2
Client_TRAINING_A Client_TRAINING_B
IP = 192.168.1.2 IP = 192.36.253.30
Gw = 192.168.1.254 Gw = 192.36.253.20
192.168.1.254
Firewall_A Firewall_B
IP = 192.36.253.10 192.36.253.1 IP = 192.36.253.20
Gw = 192.36.253.1 Static route to Net-A
Gw = 192.36.253.1
11
6. Nous constatons ce qui suit :

• Client_TRAINING_B peut joindre Net-A (ping vers Client_TRAINING_A),
• Client_TRAINING_A ne parvient pas à joindre Client_TRAINING_B (ping
vers 192.36.253.30).
7. À l’aide du schéma ci-dessus et des logs des firewalls, trouvez l’expli atio de
ce comportement inattendu. Quelle(s) solution(s) proposeriez-vous ?
8. Reconfigurez le réseau de la VM Client_TRAINING_B pour la rattacher au

réseau LAN_IN_B dans VirtualBox. Puis lancez le script de configuration
network_config.sh pour lui attribuer la configuration Company B.
331
Virtual Labs
LAB 3 : Configuration des objets et de la politique de NAT
1. Démarrez les machines virtuelles Debian en prenant soin de choisir la bonne

compagnie.
2. Créez des objets de type « machine » portant les adresses IP internes et externes de
vos serveurs :
• "srv-dns" : 172.16.x.10
• "srv-web" : 172.16.x.11
• "srv-ftp" : 172.16.x.12
• "srv-ftp-pub" : 192.36.253.x2
Note :
Le « x » doit être remplacé suivant la lettre de l’e t ep ise A⇒1, B⇒2.
Pour la station cliente, le serveur DNS est le « srv-dns/ 172.16.x.10 ».
3. Votre firewall est maintenant configuré comme indiqué par le schéma page 3. Nous
considérons le réseau externe (192.36.253.0/24) comme un réseau public. Les
adressages privés ne doivent donc plus être visibles au-delà des LAN des
compagnies. Renommez la politique « (10) Pass all » en « (10) Pass all + NAT » et
ajoutez les règles de NAT pour permettre :
• À vos réseaux internes d'accéder à Internet.
• À votre serveur WEB d'être joignable depuis l'extérieur sur l'adresse
« 192.36.253.x0 ». Cette règle doit lever une alarme mineure.
• À votre serveur FTP d'être joignable depuis l'extérieur sur l'adresse
« 192.36.253.x2 ».
4. Désactivez les routes statiques créées précédemment et tentez de joindre les

services web et ftp publiés par l’aut e entreprise (vous pouvez utiliser leurs noms
DNS www.X.net et ftp.X.net, où X est à remplacer par la lettre de l’e t ep ise .
Depuis les journaux, observez les traces liées aux accès à votre serveur WEB.
332
Virtual Labs
LAB 4 : Évènement de protocoles applicatifs
Sur la VM graphique A, installez le logiciel Wireshark. Pour cela ouvrez un terminal et tapez les
commandes suivantes :
• su -
• Saisissez le mot de passe root, qui est par défaut « toor »
• apt update
• apt install wireshark
1. Configuration générale :
1.1 Copiez la politique « (10) Pass all + NAT » vers une autre politique vide en la renommant
avec un nom de votre choix.
1.2 Dans les journaux :

• Section « Tous les journaux » : assurez-vous que les colonnes « Journaux », « Nom de
la règle » ou « Règle n° », « Profil IPS (ID) », « Argument », « Contexte », « Reçu »,
« Envoyé », « Opération », « Résultat », « Message » soient affichées (pour ce faire,
cliquez sur la flèche à droite d’u e des colonnes => colonnes => Sélectionnez la
colonne que vous voulez afficher).
• Section « Alarmes » : assurez-vous que la colonne « Paquet capturé » soit affichée.
• Demandez le droit d’a s aux données personnelles.
• Vous pouvez configurer des filtres d’affi hage, et les sauvegarder, pour ’affi he que
ce que vous désirez vérifier dans les journaux.
2. Évènement HTTP (travailler en binôme) :
2.1 Configurez la politique de filtrage comme suit :

• Ajoutez une règle pour autoriser l'accès à votre serveur HTTP depuis l'extérieur. Cette
règle devra lever une alarme mineure.
• Ajoutez une règle pour autoriser l'accès aux serveurs HTTP de l’aut e entreprise
depuis votre réseau interne.
• Testez l’a s au serveur HTTP de l’aut e entreprise en observant les traces levées
dans les journaux, en mode accès complet (droit d’a s aux données personnelles).
2.2 Affichez le document RFC 791 hébergé sur le site web distant. Déterminez les catégories de
traces (alarme, plugin ou connexion ?) dans lesquelles cet accès HTTP a été inscrit.
2.3 Affichez maintenant le document RFC 2616 :

• Identifiez le problème (avec l’aut e entreprise) en trouvant l'évènement bloquant
dans les journaux.
• Modifiez l’ala e qui correspond à cet événement en modifiant son action à
"Autoriser" et en activant la capture de paquet.
• Testez à nouveau et déterminez les catégories de traces (alarme, plugin ou
connexion ?) avec cette nouvelle configuration. Vous pouvez analyser le paquet
capturé avec un clic droit sur la colonne « Paquet capturé ».
333
Virtual Labs
2.4 Remettez l’a tio de l’ala e à son état initial « Interdire » et utilisez le mode
d'inspection « IDS » sur vos règles de filtrage :
Testez encore une fois l’a s au document RFC 2616 et déterminez les catégories de
traces (alarme, plugin ou connexion ?).
2.5 Refaites le test précédent en utilisant cette fois le mode d'inspection « Firewall » sur
vos règles de filtrage.
2.6 Refaites une dernière fois le test en remettant le mode d'inspection « IPS » et en
spécifiant le protocole TCP sur vos règles.
3. Évènement FTP :
3.1 Configurez la politique de filtrage comme suit :
• Ajoutez une règle pour autoriser l'accès à votre serveur FTP depuis l'extérieur.
• Ajoutez une règle pour autoriser l'accès au serveur FTP de l’aut e entreprise
depuis votre réseau interne.
• Désactivez toute autre règle trop permissive.
• Testez l'accès au serveur FTP de l’aut e entreprise.
3.2 Installez le client ftp en invite de commandes. Pour cela ouvrez un terminal et tapez
les commandes suivantes :
• su -
• Saisissez le mot de passe root, qui est par défaut « toor »
• apt update
• apt install ftp
Connectez-vous au serveur FTP de l’aut e entreprise, en utilisant les commandes
suivantes dans un terminal :
• ftp
• ftp> open IP_Pub_FTP_autre_entreprise
• Name: anonymous
• Password: password (le mot de passe importe peu)
Une fois connecté, entrez les commandes suivantes :

• ls (afin de lister le contenu du répertoire FTP)
• quote hello
Que se passe-t-il, et pourquoi ? (vérifiez les logs, ...)
334
Virtual Labs
3.3 Positionnez vos règles relatives aux accès FTP en mode d'inspection "Firewall" :
• Refaites le test précédent en entrant les mêmes commandes.
• Le retour des commandes est-il identique au cas précédent ?
• Vérifiez qu'il vous est encore possible de lister le contenu du serveur.
• Par quelle méthode plus fine pouvons-nous gérer ce cas pour éviter
l'utilisation du mode d'inspection "Firewall" ?
3.4 Vérifiez que la règle de filtrage permettant l’a s à votre serveur FTP interne est en
mode IPS, puis configurez le profil entrant de votre plugin FTP avec comme seul
utilisateur autorisé « anonymous »
• Faites tester l’a s à votre serveur FTP par l’aut e entreprise qui utilisera un
login particulier (par exemple son nom ou son prénom).
Quelles sont les conséquences (regardez vos alarmes et visualisez le résultat côté
client de l’aut e entreprise).
3.5 (Optionnel) Consultez les rapports d'activité suivants :

• Sécurité ⇒ Alarmes
• Réseau ⇒ Protocoles par volume
335
Virtual Labs
LAB 5 : PKI
Attention : Vérifiez au préalable que la date, l'heure et le fuseau horaire de votre firewall
sont corrects.
1. Créez une autorité racine sur votre firewall avec les paramètres suivants :
• CN: CA-cie-X,
• organisation: cie-X,
• unité d'organisation: Lab PKI,
• lieu: Paris,
• état: IDF,
• pays: France,
• la durée de validité de cette autorité de certification est de 3650 jours,
• optionnellement, l'URI de distribution de la CRL pourra être précisée sous la
forme: http://www.x.net/CRL/cie-x.crl.pem
2. Définissez cette autorité comme CA par défaut.
3. Créez une identité serveur dont le FQDN est fw.X.net et pour laquelle la durée de
validité du certificat correspondant est de deux ans.
4. Exportez ce certificat au format PEM ou DER, et visualisez les éléments suivants:

• période de validité,
• le nom commun (CN),
• le CRLDP (point de distribution),
• l'émetteur du certificat.
336
Virtual Labs
LAB 6 : Proxy SSL
1. Utilisez la base d'URL Extended Web Control si elle est disponible, sinon la base
embarquée.
2. Accès à un site HTTPS via le proxy SSL :

• En utilisant l'assistant, configurez une politique de filtrage permettant
l'analyse du trafic HTTPS uniquement.
• Activez votre politique et tentez d'accéder à un site HTTPS (exemple :
https://home.barclays).
• Pourquoi obtenez-vous un message d'avertissement de votre navigateur ?
• Comment résoudre ce problème ? Vous appliquerez votre solution dans
l'étape suivante.
3. Personnalisation des paramètres du proxy SSL :

• Modifiez l'autorité utilisée par le proxy SSL en sélectionnant la CA créée
précédemment.
• Ajustez la politique de filtrage SSL active pour que:
• le site https://www.caymannational.com ne soit pas déchiffré
Regardez le certificat obtenu
4. Filtrage de contenu HTTPS (déchiffrement et URL Filtering) :

• Définissez un objet Web : Barclays-who-we-are qui contient
[ home.barclays/who-we-are/* ]
• Définissez une politique de filtrage d'URL qui renvoie vers la page de blocage
tout accès à Barclays-who-we-are. Le reste des sites sera autorisé.
• Allez sur le site https://www.home.barclays et tentez d'accéder à l’o glet
« Who we are ? ».
• Consultez vos logs web.
5. Consultez les rapports d'activité de la catégorie WEB.
6. a) Accédez à la page https://www.youtube.com et regardez le certificat livré (CN et

Noms alternatifs)
Adaptez la politi ue de filt age SSL pou lo ue l’a s au site

https://www.youtube.com
V ifiez ue l’a s à https://www.google.com ’est pas lo u .
337
Virtual Labs
LAB 7 : VPN IPSec avec certificats
• Activez le portail captif sur les interfaces externes. Un règle de NAT statique
par port doit être créée pour que votre serveur web soit accessible depuis le
réseau public (193.36.253.0/24).
• Configurez une base LDAP interne avec les paramètres suivants:
• Organisation: Cie-x
• Domaine: net
• Pour la suite du lab, travaillez en binôme et décidez ensemble des profils de
chiffrement à utiliser.
• Pou fou i des fi hie s à l’aut e e t ep ise, utilisez vot e se veu FTP. Pou
cela, avec le logiciel WinSCP, connectez-vous à l’ad esse IP 1 2.16 .x.1 e
mode SCP (login : root, mot de passe : root). Placez le fichier dans le dossier
/ho e/ftp. L’aut e e t ep ise pou a t l ha ge le fi hie à l’ad esse
ftp://193.36.253.x2/fichier.
2. Une CA par site :

• Choisissez une politique VPN IPSec et renommez-là « Separated-CA ».
• Configurez un VPN site-à-site entre vos « Network_in » respectifs; l'identité
présentée durant la négociation sera un certificat serveur issu de votre propre
CA.
• Récupérez la CA de l’aut e entreprise à partir de son portail captif et définissez
la relation de confiance.
• Générez du trafic à destination du site distant et validez la montée du tunnel
en affichant les sections « VPN » de la supervision et des logs.
3. Une CA commune aux deux correspondants :

• Dans une autre politique que vous renommerez "Shared-CA", configurez un
tunnel VPN IPsec avec l’aut e entreprise. Pour cela:
• Fournissez à l’aut e entreprise une identité issue de votre CA. Elle
l’utilise a pour configurer son tunnel IPsec avec vous.
• Définissez les relations de confiance nécessaires et initiez la montée du
tunnel.
Il n’est pas possible de traiter les questions suivantes sur votre plateforme virtuelle,
car le client VPN IPSec n’est disponible que sous Windows.
4. Clients nomades :
• Installez le client VPN Stormshield Network sur votre poste.
• Désactivez la politique active.
• Créez un utilisateur pour l’aut e entreprise et son identité dans votre annuaire
et votre PKI. Exportez l’ide tit et déposez la sur votre serveur FTP.
• Attribuez le droit VPN IPSec à cet utilisateur.
• Dans une nouvelle politique IPSec nommée « Mobile Client », configurez une
politique nomade uniquement, pour que cet utilisateur puisse joindre votre
réseau Network_in.
338
Virtual Labs
• Dans la configuration du client VPN IPsec, définissez une adresse IP virtuelle.

Une fois le tunnel monté, affichez la liste des utilisateurs authentifiés,
identifiez l'adresse IP avec laquelle il se présente et la durée
d'authentification.
5. Bonus 1 : Clients nomades + Xauth :

• Modifiez le correspondant afin d'utiliser une authentification de type certificat
+ Xauth.
• Activez l'option dans les paramètres avancés du client VPN IPSec.
6. Bonus 2: Clients nomades + Xauth + Mode config :

• Activez le mode config sur la politique nomade actuelle. Définissez pour cela
une nouvelle plage nommée "Config-mode" dont la valeur est 172.23.255.1 -
172.23.255.10.
• Activez le mode config dans les paramètres avancés de la phase 1 du client
VPN IPSec.
• Montez le tunnel et identifier l'adresse IP obtenue sur la carte réseau associée
au client VPN IPSec et dans SN RTM pour la passerelle IPSec.
339
Virtual Labs
LAB 8 : Tunnels GRE et GRETAP
• Désactivez toutes les politiques VPN créées précédemment.
1. Tunnel GRE :
• Créez un tunnel GRE avec l’aut e entreprise
• Créez les routes et les règles de filtrage nécessaires pour faire

communiquer les deux réseaux internes « IN »
• Bonus : Activez la politique VPN IPSec site-à-site du Lab précédent et

faites transiter le trafic GRE via le tunnel VPN IPSec en utilisant l’u e des
configurations vues en cours (standard ou VTI).
2. Tunnel GRETAP :
• Supprimez les interfaces GRE créées précédemment.
• Créez un tunnel GRETAP pour interconnecter les deux réseaux DMZ des
deux firewalls qui doivent être configurés avec le même plan d’ad essage
« 172.16.XY.0/24 » (X et Y sont les identifiants des entreprises A⇒1,
B⇒2).
• Sur l’u des firewalls, activez le serveur DHCP avec une plage d’ad esses
IP faisant partie du plan d’ad essage précédent.
• Créez les règles de filtrage pour autoriser l’i te o exio des deux
réseaux.
• Connectez vos machines sur les interfaces DMZ. Vérifiez que les deux
machines récupèrent une adresse IP du serveur DHCP et confirmez
u’elles peuvent communiquer entre-elles.
• Bonus : Activez la politique VPN IPSec site-à-site du Lab précédent et

faites transiter le trafic GRETAP via le tunnel VPN IPSec en utilisant l’u e
des configurations vues en cours (standard ou VTI).
340
Virtual Labs
LAB 9 : Authentification transparente par certificat
1. Création de l’utilisateur et de son identité :
• Créez un utilisateur dont le login est authuser-x et dont l'adresse e-mail est
authuser-x@cie-x.net.
• Créez son identité depuis sa fiche LDAP.
2. Configuration et test de la méthode d’authentification :

• Ajoutez et configurez la méthode d'authentification "Certificat SSL" dans les
paramètres du portail. Désignez-la comme méthode par défaut.
• Activez le portail captif également sur les interfaces internes.
• Exportez l’ide tit de cet utilisateur via un conteneur PKCS#12 et importez-le
dans votre navigateur.
• Testez l'authentification sur le portail en tapant l'URL
https://Firewall_IP_address/auth/ssl.html
• Si l'authentification fonctionne correctement, déconnectez l'utilisateur depuis
la supervision.
3. Activation de l’authentification :
• Ajoutez, dans votre politique de filtrage, une règle d'authentification en tête
de liste (en utilisant l'assistant).
• Tentez maintenant d'accéder directement à un site web extérieur en HTTP, et
assurez-vous que l'authentification fonctionne de façon transparente.
4. Bonus Multi-utilisateurs :
• Ajoutez un deuxième utilisateur et créez lui une identité.
• Activez le multi-utilisateurs pour votre machine locale.
• En utilisant les certificats, authentifiez les deux utilisateurs depuis deux
navigateurs différents.
• Appliquez à chaque utilisateur un filtrage d’URL spécifique et validez son
fonctionnement.
341
Virtual Labs
LAB 10 : Haute disponibilité
Il n’est pas possible de traiter les questions suivantes sur votre plateforme virtuelle,
car les firewalls virtuels ont le même numéro de série.
1. Sauvegardez la configuration du firewall sur votre poste
2. Vérifiez que la licence HA de votre firewall indique "Master".
3. En binôme, décidez de l'interface à utiliser pour le lien HA et du plan d'adressage

affecté à ce lien ainsi que le mot de passe.
• Créez d'abord le cluster sur un des firewalls.
• Branchez les interfaces HA des deux boitiers.
• Rejoignez ensuite le cluster avec l'autre firewall. Après le redémarrage,
vérifiez que le cluster HA est fonctionnel (regardez dans la section Matériel
dans le menu supervision.
4. Connectez les interfaces internes d’u cluster et les interfaces de vos machines sur le
même switch (Les interfaces OUT resteront toujours connectées au switch externe).
Assurez-vous que vos deux machines peuvent sortir sur Internet. Si cela fonctionne,
envoyez un ping continu vers l'extérieur, et retirez un câble réseau du firewall actif (mais
pas le lien HA). Observez le nombre de pings perdus.
5. Lancez le téléchargement HTTP d'un fichier volumineux, et ensuite enlevez un câble

réseau du firewall actif, et observez l'impact sur votre téléchargement. (Vous trouverez
un fichier de taille importante disponible sur le serveur du formateur, à l'adresse
http://192.36.253.254/randfile.cgi?3G).
342
VIRTUAL LABS -
CORRIGÉS
343
344
Virtual Labs - Corrigés
Le corrigé est rédigé en se positionnant à la place du stagiaire A. Les adresses IP et autres

o jets elatifs à l’aut e e t ep ise dev o t t e odifi s e o s ue t.
LAB 1 : Bases de configuration
1. La connexion au firewall se fait depuis un navigateur à l'adresse

https://adresse_ip/admin. Pour rappel, le compte utilisateur est admin, et le mot de
passe par défaut est admin également. À cette étape, l'adresse sera donc
https://10.0.0.254/admin
2. Cliquez sur le nom d’utilisateu , puis sur Préférences (icone avec une clef et un
tournevis), sélectionnez ensuite dans la ligne Déconnexion en cas d'inactivité la
valeur Toujours rester connecté. Il n'y a pas de bouton de validation pour ce
changement, cela est pris en compte automatiquement.
3. Dans le menu Configuration ⇒ Système ⇒ Configuration ⇒ Configuration générale,

modifiez les champs « Langue du firewall (traces) » et « Clavier (console) ». Dans
l'encadré « Paramètres de date et heure », sélectionnez le fuseau horaire
correspondant à l’heu e locale.
4. Dans le menu Configuration ⇒ Système ⇒ Configuration ⇒ Administration du

firewall, cochez les cases « Activer l'accès par SSH » ainsi que « Autoriser l'utilisation
de mot de passe » et validez.
5. Dans le menu Configuration ⇒ Système ⇒ Administrateurs ⇒ Compte admin.

Renseignez un nouveau mot de passe. Assurez-vous que le mot de passe contienne
au minimum 8 caractères.
6. Dans le menu Configuration ⇒ Notifications ⇒ Traces - syslog ⇒ Stockage Local,

cliquez sur « Activer le stockage des traces ». Dans le champ Support de stockage,
sélectionnez la carte SD qui est insérée au préalable. Formatez la carte et appliquez.
Pour activer les rapports embarqués, Lancez l'outil Activity Reports, et assurez-vous
d'avoir les droits en écriture. Dans la configuration, cliquez sur « Activer l'analyse des
données », sélectionnez la totalité des rapports puis cliquez sur « Définir l'état On »
et validez.
345
LAB 2 : Suivi stateful en environnement routé
1. Configuration des interfaces réseaux du firewall :

• Cliquez sur le menu Configuration ⇒ Réseau ⇒ Interfaces. Double-cliquez sur
l'interface nommée « in » se trouvant au sein du bridge. Dans l'encadré Plan
d'adressage, choisissez l'option Dynamique/Statique, puis IP fixe (statique).
Dans l'encadré listant les adresses, cliquez sur le bouton Ajouter, puis
renseignez les valeurs suivantes : Adresse/Masque : 192.168.1.254/24.
• Sans cliquer sur Appliquer, sélectionnez maintenant l'interface nommée
« out » se trouvant au sein du bridge. Dans l'encadré Plan d'adressage,
choisissez l'option Dynamique/Statique, puis IP fixe (statique). Dans
l'encadré listant les adresses, cliquez sur le bouton Ajouter, puis renseignez
les valeurs suivantes : Adresse/Masque : 192.36.253.10/24.
• Faites de même avec l'interface « dmz1 » en lui renseignant les valeurs
suivantes : Adresse/Masque : 172.16.1.254/24.
• Validez vos changements en cliquant sur Appliquer. Modifier l'adresse IP de
votre poste pour être dans le même plan d'adressage que l'interface sur
laquelle vous êtes directement connecté. Exemple : si vous êtes connecté sur
l'interface « in », choisissez une adresse IP faisant partie du réseau
192.168.1.0/255.255.255.0. Désormais la connexion au firewall se fera donc à
l'adresse https://192.168.1.254/admin
• Sur la VM Client_TRAINING_A configurez le réseau à l’aide du script disponible
sur le bureau.
• Dans le menu Configuration ⇒ Réseau ⇒ Routage ⇒ Passerelle par défaut.
Cliquez sur l'icône '+' afin de créer l'objet machine correspondant à la
Passerelle par défaut (routeur) : Nom de l'objet : passerelleFormateur,
Résolution DNS: aucune, Adresse IP: 192.36.253.254. Cliquez ensuite sur
Appliquer.
• Répétez les opérations précédentes pour configurer le firewall B et la VM
Client_TRAINING_B.
2. Dans le menu Configuration ⇒ Politique de sécurité ⇒ Filtrage et NAT, cliquez sur le
menu déroulant pour choisir (10) Pass all. Cliquez ensuite sur le bouton Activer cette
politique.
3. Dans le menu Configuration ⇒ Système ⇒ Administration du firewall, dans la

section Accès aux pages d’ad inistration du firewall, cliquez sur ajouter et
sélectionnez l’o jet Network_out. Cliquez sur Appliquez.
346
4. Dans le menu Configuration ⇒ Réseau ⇒ Routage ⇒ Routage statique, cliquez sur

Ajouter puis renseignez les valeurs suivantes :
• Réseau de destination : cliquez sur '+' et ajoutez un objet de type Réseau dont
les valeurs sont : Nom de l'objet : Réseau_A, Adresse IP: 192.168.1.0/24,
Interface: sélectionnez l'interface out.
• Passerelle : cliquez sur '+' et ajoutez un objet de type Machine dont les valeurs
sont : Nom de l'objet : FW_A, Adresse IP : 192.36.253.10
• Double-cliquez dans la colonne état afin d'activer la route statique. Cliquez sur
Appliquer.
5. Si besoin, référez-vous aux premières pages pour configurer le réseau de la machine

virtuelle. Vous pouvez visualiser les routes présentes sur la machine avec la
commande « ip route show ».
6. Net-A ne peut pas joindre Client_TRAINING_B parce que le paquet ICMP « echo
request » est envoyé directement à Client_TRAINING_B grâce à la route directement
connectée que possède le FW-A et qui est prioritaire sur la route par défaut.
Client_TRAINING_B répond avec un paquet ICMP « echo reply » envoyé au firewall B
(passerelle par défaut) parce u’il ne possède pas de route statique correspondante.
Le firewall B bloque cette réponse parce u’elle ne correspond à aucune entrée dans
sa table de connexions l’e t e aurait dû être créée par un paquet ICMP echo
request). Ceci confirme le suivi Stateful des échanges ICMP. Une solution simple
consiste à ajouter une route statique sur la VM Client_TRAINING_B pour éviter le
routage asymétrique. Cela se fait en super utilisateur (root) avec la commande : « ip
route add 192.168.1.0/24 via 192.36.253.10 ».
Echo request Echo reply Alarm: ICMP reply

without request
347
LAB 3 : Configuration des objets et de la politique de NAT
2. Allez dans le menu Configuration ⇒ Objets ⇒ Objets réseaux. Cliquez sur le bouton
Ajouter. Assurez-vous de choisir un objet de type Machine, puis renseignez les
paramètres suivants : Nom de l'objet : srv-dns, Adresse IP : 172.16.1.10. Avec
l'option Créer et dupliquer, réitérez l'opération pour les objets srv-web, srv-ftp et
srv-ftp-pub en prenant soin de modifier leurs adresses IP respectives. Configurez
votre station pour utiliser le serveur DNS « srv-dns /172.16.1.10».
3. Dans le menu Configuration ⇒ Politique de sécurité ⇒ Filtrage et NAT. Renommez

le slot (10) Pass all en cliquant sur Editer ⇒ Renommer et ajoutez les règles de NAT
suivantes :
4. Validez vos règles de NAT en cliquant sur le bouton Appliquer. N'oubliez pas d'activer
votre politique pour que les modifications soient prises en compte. Respectez l'ordre
des règles comme défini ci-dessus pour éviter qu'une règle ne soit jamais appliquée.
348
LAB 4 : Évènements de protocoles applicatifs
Dans le menu Configuration ⇒ Politique de sécurité ⇒ Filtrage et NAT ⇒ Filtrage,
copier la politique « (10) Pass all + NAT » vers une politique vide en cliquant sur « Editer
⇒Copier vers ⇒ (0x) Filter 0x ». Sélectionnez la politique choisie et renommez-la en
cliquant sur « Editer ⇒ Renommer ».
2. Évènements http
2.1 Dans le menu Configuration ⇒ Politique de sécurité ⇒ Filtrage et NAT ⇒ Filtrage,
Ajoutez les règles suivantes :
Validez et activez votre politique.
2.2 Affichage du document RFC 791 :

Affichez les journaux dans la section « Tous les journaux », à l’aide de deux filtres
d’affi hage pour les flux http sortants et entrants, respectivement comme suit :
Vous voyez des journaux de type Plugin dans les deux sens, et Alarme dans le sens
entrant (la colonne message permet de vérifier que ’est une alarme demandée dans la
règle de filtrage). Aucun journal connexion.
349
2.3 Affichage du document RFC 2616 :

• Dans ce cas, les logs que vous devez constater sont Alarme et Connexion.
Aucun log Plugin.
• L'affichage de cette page lève une alarme Protocole HTTP invalide (version).
• Allez alors dans le menu Configuration ⇒ Protection Applicative ⇒
Applications et protections. Lancez une recherche sur « http invalide ».
L'alarme s'affiche. Sélectionnez le bon profil applicatif, celui qui a levé l’ala e
selon le contenu de la colonne « Profil IPS (ID) » dans les journaux « Alarme ».
Dans la colonne Action correspondant à l'alarme, modifiez le comportement
pour passer de « Interdire » à « Autoriser ». Cliquez sur le bouton
« Configurer » afin de capturer le paquet responsable de la levée de l'alarme.
Validez cette modification en cliquant sur Appliquer. Vous devez voir un log
connexion.
• Sur la colonne des journaux « Paquet capturé », cliquez droit et ouvrez le
paquet directement dans Wireshark pour visualiser l’o igi e du problème.
2.4 Mode d’i spe tio « IDS » :

• Pour remettre l'alarme dans son état initial, il suffit de réitérer la manipulation
précédente, de modifier l'Action pour y sélectionner « Interdire » et validez en
cliquant sur Appliquer.
• Afin de paramétrer une règle de filtrage en mode IDS, allez dans le menu
Configuration ⇒ Politique de sécurité ⇒ Filtrage et NAT ⇒ Filtrage. Sur la
règle de filtrage donnant accès à votre serveur web, double cliquez dans le
champ « Inspection de sécurité » puis modifiez la valeur du Niveau
d'inspection à IDS. Validez et activez la politique.
• Dans ce cas, les logs que vous devez constater sont Alarme et Connexion.
Aucun log Plugin.
350
2.5 Mode Firewall :

• Modifiez le champ « Inspection de sécurité » de la règle de filtrage donnant
accès à votre serveur web puis modifiez la valeur du Niveau d'inspection à
Firewall.
• Dans ce cas précis, les logs que vous devez constater sont Alarme et
Connexion. Aucun log Plugin.
2.6 Mode d’i spe tio « IPS » + TCP forcé :

• Repositionnez le mode « IPS » à la règle de filtrage donnant accès au serveur
web. Pour forcer le protocole TCP, double cliquez sur le champ Protocole de la
règle de filtrage. Dans l'encadré Protocole, choisissez Protocole IP dans la
partie Type de protocole. Dans la partie Protocole IP, choisissez tcp. Validez
en cliquant sur Ok puis confirmez et activez votre politique.
• Seuls deux logs, Alarme et Connexion, sont levés.
3. Évènement FTP :
3.1 Configuration de la politique de filtrage :
Si une règle équivalente à un « Pass-All » est toujours présente, désactivez-la.
3.2 Lorsque la commande quote hello est envoyée, on constate dans les évènements
deux nouveaux logs:
• Un log plugin (pour FTP) qui a été détecté.
• Un log alarme dont l'action est à Bloquer/Majeur et dont l'intitulé est
Commande FTP inconnue.
3.3 Mode firewall :

• Modifiez les deux règles de filtrage (pour tester dans les deux sens) afin de
sélectionner le mode d'inspection de sécurité « Firewall ». N'oubliez pas de
valider et activer votre politique et tester à nouveau l'accès au serveur de
l’aut e entreprise.
• Si on teste à nouveau la commande ftp « quote hello », c'est désormais le
serveur qui nous indique « 500 Unknown command. » et non plus le firewall
qui bloque la connexion avec une alarme.
3.4 Utilisateur FTP :

• Dans le menu Configuration ⇒ Protection Applicative ⇒ Profils d’inspection,
cliquez sur le bouton « Accéder aux profils » et vérifiez pour le profil IPS_00
que le profil applicatif FTP est ftp_00. Puis, par le menu Configuration ⇒
Protection Applicative ⇒ Protocoles ⇒ FTP, onglet Utilisateurs FTP, ajoutez
anonymous dans la liste « Utilisateurs autorisés ». Enfin, précisez l’utilisatio
du profil IPS_00 dans la règle de filtrage entrante. L’ala e « Utilisateur non
autorisé » avec l’a tio à Block est affichée.
351
LAB 5 : PKI
1. Création d'une autorité racine

Allez dans le menu Configuration ⇒ Objets ⇒ Certificats et PKI. Cliquez sur Ajouter, puis
sur « Autorité racine ». Renseignez ensuite les champs suivants (avec X = votre lettre de
compagnie) :
• CN: CA-Cie-X
• Organisation: Cie-X
• Unité d'organisation: Lab PKI
• Lieu: Paris
• Etat: IDF
• Pays: France
Cliquez sur Suivant. Renseignez le mot de passe de l'autorité de certification ainsi que sa
durée de vie de 3650 jours. Ajoutez l'URI http://www.x.net/CRL/cie-x.crl.pem en tant
que point de distribution
2. Autorité par défaut : Dans le menu Configuration ⇒ Objets ⇒ Certificats et

PKI cliquez droit sur l'autorité créée précédemment puis sur Action : « Définir comme
défaut ».
3. Création d'une identité serveur : Dans le menu Configuration ⇒ Objets ⇒ Certificats

et PKI cliquez sur Ajouter => Identité serveur et nommez-la fw.X.net. Sa durée de
validité et de 2 ans (730 jours). Le certificat correspondant doit être signé par l'autorité
de certification créée précédemment.
4. Export du certificat serveur : Sélectionnez le certificat puis cliquez sur Téléchargement

⇒ Certificat ⇒ format PEM ou DER.
352
LAB 6 : Proxy SSL
1. Le choix de la base de données Extended Web Control s'effectue depuis le menu

Configuration ⇒ Objets ⇒ Objets Web ⇒ Base d'URL.
2. Accès à un site HTTPS via le proxy SSL :

• Allez dans le menu Configuration ⇒ Politique de sécurité ⇒ Filtrage et NAT
⇒ Filtrage. Cliquez sur nouvelle règle puis « Règle d'inspection SSL ». Un
assistant s'affiche, renseignez les valeurs suivantes:
• Machines sources: Network_in
• Interface d'entrée: any
• Destination: Internet
• Port destination: HTTPS
• Profil d'inspection: vide
• Politique de filtrage SSL: SSLFilter_00
• Antivirus: Off
• Validez en cliquant sur Terminer. Cet assistant génère deux règles de filtrage:
• Appliquez vos changements et activez la politique de filtrage.
• Si on tente d'accéder à https://home.barclays, le navigateur nous indique que

le certificat présenté par le serveur distant n'est pas de confiance. En réalité,
ce n'est pas le certificat du site distant qui est présenté mais le « faux-
certificat » envoyé par le firewall pour négocier le handshake SSL avec le
client.
• Pour ne plus avoir ce message d'avertissement, il faut ajouter la CA utilisée

par le proxy SSL en tant qu'autorité de certification dans le magasin de
certificats du navigateur. Afin de récupérer la CA utilisée par le proxy SSL, il
suffit de se rendre dans le menu Configuration ⇒ Objets ⇒ Certificats et PKI
⇒ Cliquez sur SSL proxy default authority. Ensuite, cliquez sur
Téléchargement puis sur Certificat au format DER. Enregistrez sur votre poste.
Ensuite, dans votre navigateur, intégrez le certificat de la CA dans votre
magasin de certificats. Si vous tentez ensuite d'accéder à nouveau à
https://www.home.barclays, aucun message d'avertissement n'apparaît.
353
3. Personnalisation des paramètres du proxy SSL :

• Le choix de la CA signataire des certificats du proxy SSL se paramètre dans le
menu Configuration ⇒ Protection applicative ⇒ Protocoles ⇒ SSL ⇒ Accéder
à la configuration globale. Sélectionnez la CA créée précédemment.
• Créez 1 objet WEB « white_list_ https » dans le menu Configuration ⇒
Objets ⇒ Objets WEB ⇒ Nom de certificat (CN) contenant
« *.caymannational.com ».
Dans le menu Configuration ⇒ Politique de sécurité ⇒ Filtrage SSL ⇒
SSLFilter_00, ajoutez une règle « Passer sans déchiffrer » pour le groupe
« white_list_https » créé précédemment.
4. Filtrage de contenu HTTPS (CN Filtering) :

• Pour définir un objet web, allez dans le menu Configuration ⇒ Objets ⇒
Objets Web. Dans l'onglet URL, cliquez sur « Ajouter une catégorie
personnalisée ». Renseignez le nom « Barclays-who-we-are ». Ensuite, sur la
partie droite de l'écran, cliquez sur « Ajouter une URL» et renseignez
www.home.barclays/who-we-are/*
• Définissez ensuite une politique de filtrage URL depuis le menu Configuration
⇒ Politique de sécurité ⇒ Filtrage URL. Par défaut, le slot URLFilter_00
apparaît. Nous allons éditer celui-ci. Cliquez sur Ajouter. Double cliquez sur
l'état afin que la règle puisse être active. Dans le champ « Action»,
sélectionnez une page de blocage. Dans le champ « Groupe d'URL »,
sélectionnez « Barclays-who-we-are » créé précédemment. Assurez-vous que
cette nouvelle règle soit placée au-dessus de la règle qui était déjà présente.
Pour rappel, les règles sont traitées par ordre d'apparition dans la politique
(du haut vers le bas). Ensuite, validez les changements.
• Allez dans le menu Configuration ⇒ Politique de sécurité ⇒ Filtrage et NAT.
Sur la seconde règle qui a été créée lors de l'exécution de l'assistant
d'inspection SSL (vu en 7-1), double-cliquez dans le champ Inspection de
sécurité. Dans la partie Filtrage URL, sélectionnez la politique URLFilter_00
que l'on vient de modifier. Validez par Ok puis appliquez et activez votre
politique.
354
• Dans les logs web, on constate l'entrée suivante (tous les champs ne sont pas
renseignés) :
proto=http,
op=GET,
src=192.168.1.1,
srcport=49443,
srcportname=ephemeral_fw_tcp
dst=147.63.166.62,
dstport=443,
dstname=www.home.barclays,
modsrc=192.36.253.10,
modsrcport=17438,
origdst=127.0.0.2,
action=block cat_site=« Barclays-who-we-are »,
arg=« /who-we-are-barclays.html »,
msg=« Blocked url ».
355
LAB 7 : VPN IPSec avec certificats
Le corrigé de la partie nomade, vu en formation présentielle Stormshield, est fourni à

titre indicatif. Il n’est pas possi le de le tester sur otre platefor e irtuelle, le client
VPN IPSec n’étant disponi le ue sous Windo s.
Note : La correction présente la mise en place d'un tunnel entre les firewalls A et B pour
la partie site à site et d’u tunnel configuré avec le firewall A pour la partie nomade.
1. Configuration Générale :
• L’a tivatio du portail captif sur les interfaces externes est visible dans le
menu Configuration ⇒ Utilisateurs ⇒ Authentification ⇒ Portail captif. Le
profil External sur l’i te fa e « out » est lié à l’a uai e par défaut. Pour la
configuration de la base LDAP interne, accédez au menu Configuration ⇒
Utilisateurs ⇒ Configuration des annuaires, exécutez l'assistant de base LDAP
interne en renseignant les paramètres suivants:
• Organisation: Cie-x
• Domaine: net
2. Une CA par site :

• Pour renommer la politique VPN IPSec, cliquez sur éditer ⇒ Renommer dans
le menu Configuration ⇒ VPN ⇒ VPN IPSec.
• Pour créer le tunnel, accédez au menu Configuration ⇒ VPN ⇒ VPN IPSec ⇒
Politique de chiffrement - tunnels ⇒ Site-à-site, cliquez sur Ajouter ⇒ Tunnel
site-à-site et renseignez les informations suivantes aux niveaux des
assistants :
• Réseau local: Network_in
• Réseau distant: Réseau_B
• Correspondant: cliquez sur créer un correspondant et renseignez les
valeurs suivantes:
• Passerelle distante: FW_B
• Nom: Site_FW_B
• Authentification: Certificat
• Choix du certificat: fw.A.net (créé dans le lab5)
• Autorité de confiance: peut rester vide
• Validez le tout et activez la politique. Le profil de chiffrement par défaut est
GoodEncryption pour les phases 1 et 2. En cas de changement, validez les
algorithmes avec l’aut e entreprise.
• Pour obtenir le certificat de l'autorité du firewall B, il suffit de se connecter sur
son portail d'authentification sur son adresse IP publique
(https://192.36.253.20/auth). Obtenez une copie de ce certificat et importez
le dans le menu Configuration ⇒ Objets ⇒ Certificats et PKI,
356
• Cliquez sur Ajouter ⇒ Importer un fichier. Une fois importé, retournez dans
le menu Configuration ⇒ VPN ⇒ VPN IPSec ⇒ Identification puis dans
l'encadré Autorités de certification acceptées, cliquez sur Ajouter et
choisissez la CA du firewall B précédemment importée. Enfin, enregistrez les
modifications.
• Activez la politique et générez du trafic correspondant aux extrémités de trafic
pour provoquer la montée du tunnel (entre les réseaux 192.168.1.0/24 et
192.168.2.0/24 dans notre exemple).
3. Une CA commune aux deux correspondants :

• Sélectionnez une autre politique que vous renommerez "Shared-CA".
• Dans celle-ci, procédez de la manière suivante :
• Création et export de l’ide tit serveur pour l’aut e entreprise : dans
le menu Configuration ⇒ Objets ⇒ Certificats et PKI. Cliquez
sur Ajouter ⇒ Ajouter un certificat serveur . Renseignez les
paramètres suivants:
• Nom de domaine qualifié (FQDN) : entrepriseB-CieA.net
• Identifiant: entrepriseB-CieA.net
• Le certificat correspondant à cette identité sera signé par votre Autorité de
Certification (CA): cliquez sur la loupe afin de sélectionner votre CA (CA-Cie-
A). Une fois créé, cliquez sur Téléchargement ⇒ Identité au format P12.
Fournissez le conteneur à l’aut e entreprise.
• Dans le menu Configuration ⇒ VPN ⇒ VPN IPSec ⇒ Identification, chaque

site devra trouver la CA signataire considérée de confiance :
• Activez la politique et générez du trafic correspondant aux extrémités de trafic
pour provoquer la montée du tunnel (entre les réseaux 192.168.1.0/24 et
192.168.2.0/24 dans notre exemple).
4. Clients nomades (en binôme) :

• Installez le client VPN Stormshield Network fourni par le formateur sur vos
postes.
• Désactivez la politique VPN IPSec active en utilisant le bouton "Désactiver la
politique".
357
• Créez un utilisateur pour l’aut e entreprise. Allez dans Configuration ⇒

Utilisateurs ⇒ Utilisateurs et groupes, puis cliquez sur Ajouter un utilisateur.
• Générez une identité pour cet utilisateur. Allez dans Configuration ⇒ Objets
⇒ Certificats et PKI, puis cliquez sur Ajouter ⇒ Identité utilisateur. L’ad esse
email doit impérativement être la même que celle de l’utilisateu .
• Mettez le fichier .p12 à disposition de l’aut e entreprise sur votre serveur web.
• L’att i utio du droit VPN IPSec s’effe tue dans le menu Configuration ⇒
Utilisateurs ⇒ Droits d'accès VPN ⇒ Accès VPN, cliquez sur Ajouter, puis
activez une règle pour l'utilisateur créé auquel vous attribuez les droits VPN
IPSec en sélectionnant "Autoriser" dans la colonne IPSEC.
• Créez une nouvelle politique IPSec nommée "Mobile Client" dans laquelle seul
l'onglet "Anonyme - Utilisateurs nomades" sera configuré. Cliquez sur Ajouter
⇒ Nouvelle politique puis renseignez les paramètres suivants :
• Ressources locales : Network_in
• Correspondant: Créer un correspondant nomade dont les paramètres
sont :
• nom: nomade_certif
• authentification: par certificat
• certificat: certificat serveur local (fw.a.net par exemple)
• autorité de confiance: votre CA locale (car le certificat
présenté par le client nomade est issu de votre CA)
• Activez la politique.
• Configuration du client VPN de l’autre entreprise :

• Ajoutez une phase 1 qui contient les données suivantes :
• Interface: automatique,
• Adresse routeur distant: 192.36.253.10,
• Authentification: Certificat. Ce choix entraîne l'ouverture de l'onglet
Certificat dans lequel il est nécessaire d'importer le P12 récupéré sur
le serveur FTP ftp://193.36.253.12/fichier.p12
• IKE : Sélectionnez les algorithmes identiques à ceux côté serveur.
• Ajoutez une phase 2 qui contient les données suivantes:
• Adresse du client VPN: l'adresse IP de votre choix (ne faisant pas
partie d'un réseau local connu par le client ou la passerelle IPSec),
• Type d'adresse: Adresse réseau,
• Valeurs: 192.168.1.0 / 255.255.255.0,
• ESP/PFS: sélectionnez les algorithmes identiques à ceux côté serveur.
• Montez le tunnel grâce à un clic droit sur la phase 2 ⇒ Ouvrir le tunnel. Une fois le
tunnel monté, depuis le Real-Time Monitor, on constate que l'utilisateur est
authentifié en SSO et qu'il utilise l'adresse IP choisie dans le champ "Adresse du client
VPN" ci-dessus.
358
5. Bonus 1 : Clients nomades + Xauth (en binôme)

• Sur le Firewall :
• Modifiez le correspondant nomade afin que l'authentification soit de
type Certificat + Xauth plutôt que Certificat uniquement. Validez et
activez la politique IPSec.
• Dans le menu Configuration ⇒ Utilisateurs ⇒ Authentification,
assurez-vous que la méthode d'authentification par défaut soit une
méthode utilisant un couple login+mot de passe. Exemple: LDAP.
• Sur le client VPN :
• dans l'onglet Avancé de la phase 1, cochez la case X-Auth Popup ou
renseignez les informations Login + Mot de passe permettant de vous
authentifier.
• Montez le tunnel grâce à un client droit sur la phase 2 ⇒ Ouvrir le tunnel.
6. Bonus 2 : Clients nomades + Xauth + Mode Config (en binôme)

• Côté Firewall :
• Double cliquez dans la colonne Mode Config de votre politique active
afin d'activer cette fonction. Dans le champ Réseau nomade, créez un
nouvel objet de type plage d'adresse dont les paramètres sont :
• Nom: Config-mode
• Valeur: 172.23.255.1 à 172.23.255.10
• Validez et activez cette politique.
• Côté client : Dans l'onglet Avancé des paramètres de phase 1, cochez la case
Mode config.
359
LAB 8 : Tunnels GRE et GRETAP
La correction de ce Lab est décrite pour le firewall A
1. Tunnel GRE :
• Pour créer un tunnel GRE, il faut créer une interface GRE sur chaque firewall
dans le menu Configuration ⇒ RÉSEAU ⇒ Interfaces virtuelles => onglet
INTERFACE GRE en renseignant les paramètres suivants :
• Nom de l’i te fa e « GRE_int_A »
• Adresse IP « 172.16.12.1 »
• Masque : 255.255.255.252
• Source tunnel : « Firewall_out »
• Destination tunnel : « FW_B : 192.36.253.20 »
• La création d’u e route statique pour le réseau distant s’effe tue dans le
menu Configuration ⇒ RÉSEAU ⇒ Routage => onglet ROUTES STATIQUES en
indiquant les informations suivantes :
• Réseau de destination « NET_B : 192.168.2.0/24 »
• Interface « GRE_int_A »
• Passerelle : l’ad esse IP de l’i te fa e GRE distante « 172.16.12.2 »
• Ajoutez les règles de filtrage ci-dessous :
• Bonus :
• Avec une configuration standard, il suffit de spécifier les adresses IP de
l’ext it s du tunnel GRE comme extrémité de trafic dans le tunnel
VPN IPSec et de sélectionner GRE dans la colonne protocole (pour
afficher la colonne protocole, cliquez sur la petite flèche qui apparait
en mettant le curseur de la souris sur la ligne des paramètres, ensuite
colonne et enfin côchez protocole).
• La deuxième configuration possible consiste à utiliser les interfaces VTI

:
• Créez l’i te fa e VTI dans le menu Configuration ⇒ RÉSEAU ⇒
Interfaces virtuelles => onglet INTERFACE IPSEC (VTI).
• Utilisez les adresses IP des interfaces VTI locale et distante
comme adresses IP des extrémités du tunnel GRE et des
extrémités de trafic pour le tunnel VPN IPSec (cette fois le
paramètre Any doit être sélectionné dans la colonne
protocole).
360
2. Tunnel GRETAP :
• Dans le menu Configuration ⇒ RÉSEAU ⇒ Interfaces, :

• Créer une interface GRETAP « GRETAP_int_A » en cliquant sur Ajouter
⇒ Ajouter une interface GRETAP. La source et la destination du tunnel
doivent être respectivement « Firewall_out : 192.36.253.10 » et
« FW_B : 192.36.253.20 »
• Créer une interface bridge « BRIDGE_GRETAP » en cliquant sur Ajouter

⇒ Ajouter un bridge. L’ad esse IP du bridge doit être
« 172.16.12.254 » l’ad esse IP du bridge sur le firewall B sera
« 172.16.12.253 »). Ce bridge doit contenir les interfaces
« GRETAP_int_A » et « DMZ1 »
• L’a tivatio du DHCP s’effe tue dans le menu Configuration ⇒ RÉSEAU

⇒ DHCP. Côchez Activer le service et sélectionnez serveur DHCP.
Ensuite, ajoutez une ligne dans l’e ad PLAGES D’ADRESSES en
renseignant les paramètres suivants :
• Plage d’ad esses : « 172.16.12.20 – 172.16.12.50 »
• Passerelle : « Firewall_BRIDGE_GRETAP : 172.16.12.254 »
• DNS : « Default »
• Ajoutez les règles de filtrage ci-dessous sur le firewall qui ’a pas

activé le serveur DHCP :
• Bonus : Pour les deux configurations possibles (standard et VTI), il faut

suivre les mêmes étapes décrites pour le tunnel GRE sauf u’il faut
utiliser les extrémités de tunnel de l’i te fa e GRETAP
361
LAB 9 : Authentification transparente par certificat
1. Création de l’utilisateur et de son identité :

• Pour la création de l’utilisateu , accéder au menu Configuration ⇒
Utilisateurs ⇒ Utilisateurs, ensuite cliquez sur « Ajouter un utilisateur » et
renseignez les informations suivantes : Login (authuser-x), Nom (authuser-x),
E-mail (authuser-x@cie-x.net). Après avoir cliquez sur « Appliquer », créez un
mot de passe pour l’utilisateu avec le lien « créer ou modifier le mot de
passe ».
• Pour la création de l’ide tit , cliquez sur « créer le certificat » dans l’o glet
« Certificat » de l’utilisateu . Vous devez renseigner un mot de passe pour le
certificat utilisateur ainsi que le mot de passe de l’auto it de certification qui
signera ce certificat ’est l’auto it par défaut définie dans le menu Objets ⇒
Certificats et PKI).
2. Configuration et test de la méthode d’authentification :

• Accédez au menu Configuration ⇒ Utilisateurs ⇒ Authentification ⇒
Méthodes Disponibles, cliquez sur ajouter une méthode et choisissez
certificat SSL. Dans l'encadré de droite « Liste des autorités de confiance
(C.A) », cliquez sur le bouton Ajouter, puis choisissez dans le menu déroulant
la CA dont le certificat utilisateur est issu. Validez en cliquant sur Appliquer.
• Dans l’o glet Politique d’authentification, sélectionnez certificat SSL
comme méthode d’authentification par défaut.
• Dans l’o glet Portail captif, vérifiez que le portail captif est bien activé sur
l’i te fa e par laquelle l’utilisateu se connectera (in dans le cas du lab).
• Afin d'exporter l’ide tit au format P12 de l'utilisateur, dirigez-vous vers le
menu Configuration ⇒ Objets ⇒ Certificats et PKI, cliquez sur l’ide tit
utilisateur concernée, puis cliquez sur le bouton Téléchargement ⇒ Au format
P12. Choisissez un mot de passe pour le conteneur P12 et enregistrez le
fichier. Depuis votre navigateur, affichez le magasin de certificats et importez
celui que l'on vient d'extraire à l'instant. (Exemple: sous Firefox, le magasin se
trouve dans Options ⇒ Onglet Avancé ⇒ Sous-onglet Chiffrement ⇒
Certificats ⇒ Afficher les certificats ⇒ Onglet Vos certificats ⇒ puis
Importer...)
• Accédez ensuite à l'URL https://192.168.1.254/auth/ssl.html cochez la case
Se souvenir de cette décision (si utilisation de Firefox) et choisir le bon
certificat (authuser-x dans notre exemple). L'authentification est alors
fonctionnelle.
• Pour déconnecter un utilisateur, allez dans le menu Supervision dans la
section Utilisateurs, faire un clic droit sur l'utilisateur en question puis cliquer
sur Déconnecter cet utilisateur.
362
3. Activation de l’authentification :
• Retournez dans le menu Configuration ⇒ Politique de sécurité ⇒ Filtrage et
NAT ⇒ Onglet Filtrage . Cliquez sur Nouvelle règle ⇒ Règle
d'authentification. Un assistant s'affiche, veuillez alors renseigner les valeurs
suivantes:
• Depuis : Network_in
• Vers: Internet
• Validez par le bouton Terminer puis activez cette nouvelle politique de filtrage.
• Accédez à un site web de votre choix, puis consulter la section Utilisateurs de

la supervision. L'utilisateur « authuser-x » devrait apparaître dans la liste des
personnes authentifiées.
4. Bonus Multi-utilisateurs :
• Pour l’ajout du deuxième utilisateur et la création de son identité, refaites les
étapes du point 1.
• Pour l’a tivatio du multi-utilisateurs, ajoutez l’ad esse IP de votre machine
locale dans la fenêtre objets multi-utilisateurs accessible depuis le menu
Configuration ⇒ Utilisateurs ⇒ Authentification ⇒ onglet Politique
d’authentification.
• Pour authentifier les deux utilisateurs, il faut d’a o d déconnecter le premier
utilisateur et installer le certificat du deuxième utilisateur sur le deuxième
navigateur. Ensuite, accédez à un site en HTTP depuis chaque navigateur.
Chaque utilisateur sera authentifié sur un navigateur grâce à son certificat.
• Commencez par définir deux politiques de filtrage URL différentes. Ensuite,
créez une règle de filtrage pour chaque utilisateur en appliquant à chaque
règle une politique de filtrage différente.
363
LAB 10 : Haute disponibilité
Le corrigé ci-dessous, vu en formation présentielle Stormshield, est fourni à titre

indicatif. Il n’est pas possible de le tester sur votre plateforme virtuelle, les firewalls
ayant le même numéro de série.
Note : Dans ce corrigé, on prendra pour exemple de binôme les stagiaires A et B.
1. La sauvegarde de la configuration s’effe tue dans le menu Configuration ⇒ Système

⇒ Maintenance ⇒ onglet sauvegarder ⇒ encadré sauvegarde de configuration en
choisissant le nom du fichier de sauvegarde et en cliquant par la suite sur le bouton
Télécharger la sauvegarde de configuration. Enregistrez le fichier sur votre machine.
2. Pour vérifier le contenu de votre licence, il existe deux méthodes rapides :

• La première consiste à regarder la valeur du paramètre Haute Disponibilité du
détail de la licence dans le menu Configuration ⇒ Système ⇒ Licence. Les
valeurs possibles sont Slave ou Master.
• La seconde possibilité consiste à se connecter en SSH à l'équipement et entrer
la commande getlicence | grep -i hastate sur les deux boitiers. Là encore, les
deux valeurs possibles sont Master ou Slave.
Pour qu'un cluster HA puisse fonctionner, il faut impérativement au moins un Master. Un
cluster Slave/Slave n'est pas possible. Si vos licences sont en Slave/Slave, alors informez-
en le formateur.
3. Dans cet exemple, nous choisirons les éléments suivants:

• Le stagiaire A va créer le cluster, le stagiaire B va rejoindre le cluster.
• L'interface utilisée pour le lien de haute disponibilité sera l'interface
numérotée 5 (dmz3).
• Adresses IP dans le réseau inter-firewall : 172.30.0.1 et 172.30.0.2
• Masque : 255.255.255.0
• Mot de passe : formation
• Création d’un cluster : Afin de créer le cluster HA sur le firewall A, allez dans le menu
Configuration ⇒ Système ⇒ Haute Disponibilité. Cliquez sur Créer un groupe de
firewalls (cluster) et valide par Suivant. Renseignez les informations suivantes :
• Interface : dmz3
• Définir l'adresse IP: 172.30.0.1
• Définir le masque réseau: 255.255.255.0
• Lien secondaire à ne pas remplir pour l'exemple. Cliquez sur Suivant.
• Clé pré-partagée: formation
• Cliquez sur Suivant puis sur Terminer.
Patientez le temps indiqué afin que le cluster se crée, jusqu'à obtention du message « Ce
firewall est prêt à fonctionner en haute disponibilité. Vous pouvez maintenant configurer
un autre firewall pour qu'il rejoigne ce cluster. »
364
• Branchez un câble entre les deux interfaces numérotées 5 des firewalls.

• Rejoindre un cluster : Ensuite, rejoignez le cluster depuis le firewall B, en
sélectionnant l’optio Rejoindre un groupe de firewalls (cluster) existant dans le
menu Configuration ⇒ Système ⇒ Haute Disponibilité. Cliquez sur Suivant, puis
utilisez les paramètres suivants :
• Interface: dmz3 (Port 5), il faut impérativement utiliser la même interface de
part et d'autre
• Définir l'adresse IP : 172.30.0.2
• Définir le masque réseau: 255.255.255.0
• Validez en cliquant sur suivant.
• Indiquez ensuite l'adresse IP que vous devez contacter pour rejoindre le
cluster, c'est à dire l'adresse IP du firewall qui a créé le cluster. Dans notre
exemple il s'agit de 172.30.0.1.
• Enfin, renseignez la même valeur de clé pré-partagée également. Dans notre
exemple, nous avions opté pour formation.
• Validez en cliquant sur Terminer. Le firewall secondaire va redémarrer et
rejoindre le cluster.
Après redémarrage du boîtier, vérifiez le bon fonctionnement de la HA en analysant la
section Matériel du SN RTM ou le tableau de bord de l'interface graphique, dans
l'encadré Matériel. Le boitier passif a la première LED clignotante. C'est un moyen
facile de le repérer.
4. Utilisez un switch afin de connecter les machines aux interfaces internes du firewall
(L'adresse IP du poste stagiaire B devra être modifiée pour désormais être dans le plan
192.168.1.0/24). Assurez-vous que les deux stagiaires aient accès à Internet avant de
continuer l'exercice. Ouvrez une invite de commandes Windows et lancez un ping vers
l'extérieur. (par exemple ping -t 8.8.8.8). Dès que vous êtes prêt, vous pouvez
débrancher un câble du boîtier actif (sauf le lien HA) et constater le nombre de pings
perdus. La bascule est quasi instantanée et le nombre de pings perdus est au maximum
de 2.
5. Préparez le téléchargement d'un gros fichier. Par exemple, sur le serveur web du
formateur, à l'adresse 192.36.253.254/randfile.cgi?1G ou en téléchargeant un fichier ISO
sur Internet. Ensuite, débranchez un câble du boitier Actif (sauf le lien de HA), on
constate alors que le téléchargement n'est pas perdu et continue là où il a été
interrompu. La table des connexions et donc bel et bien répliquée entre les deux
équipements.
365
Lab - Exercices
training@stormshield.eu
366

CSNE v4 Livre de Formation Labs Virtuels 2020-02-10

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CSNE v4 Livre de Formation Labs Virtuels 2020-02-10

Transféré par

Droits d'auteur :

Formats disponibles

SOLUTIONS UNIFIED THREAT MANAGEMENT ET NEXT-GENERATION FIREWALLS

NETWORK SECURITY I ENDPOINT SECURITY I DATA SECURITY

Labs - Corrigés 343

5 Copyright © Stormshield 10/02/2019

➔ Prévention d’i t usio

Qu’est-ce u’u « Firewall » et que peut-on en attendre ?

couvert par le filtrage non couvert par le filtrage

couvert par le filtrage

non couvert par le filtrage

Filtrage et suivi de connexion

Il apparaît clairement que les critères [ IP source | port source ] et [ IP destination |

PRÉVENTION D’INTRUSION : TRAITEMENTS IPS

Le moteur de prévention d’i t usio Stormshield Network

• L’usage des contextes applicatifs limite le nombre de signatures à examiner et

La mise à jour des bases de signatures du moteur de prévention Stormshield

Les différents types d’a al ses

PRÉVENTION D’INTRUSION : ANALYSES IP

TCP, UDP, ICMP

PRÉVENTION D’INTRUSION : ANALYSES IP

• Vérifications sur le protocole IP

Analyses IPv4, IPv6

Les analyses de conformité du protocole IP

PRÉVENTION D’INTRUSION : ANALYSES IP

• Vérifications sur la légitimité de l’adresse IP source

Analyses IPv4, IPv6

Anti usurpation Type 2 = Adresse IP source incohérente avec la configuration

Type 3 = Adresse IP appartenant au firewall

Protection contre l’usu patio d’ad esse

Réseaux Protégés (internes)

PRÉVENTION D’INTRUSION : ANALYSES IP

• Application de la quarantaine (liste noire)

Analyses IPv4, IPv6

la liste noire ET / OU la liste blanche

• Application de la liste blanche

Liste noire statique

La Liste Noire est prioritaire sur la Liste Blanche.

PRÉVENTION D’INTRUSION : ANALYSES IP

Mise en quarantaine dynamique

Liste noire dynamique

PRÉVENTION D’INTRUSION : ANALYSES IP

Un paquet IP reçu fragmenté doit être réassemblé pour analyse

Lo s u’u paquet IP est émis, sa taille est généralement calculée en fonction de la

La MTU minimale obligatoire en IPv4 est fixée à 576 octets.

PRÉVENTION D’INTRUSION : ANALYSES IP

• Exemple de fragmentation : un paquet IP de 1500 octets et une

IP TCP HTTP HTTP

IP TCP HTTP HTTP

Contenu des fragments IP

PRÉVENTION D’INTRUSION : ANALYSES IP

Le moteur de prévention d’intrusion Stormshield Network reconstruit

Paramètres de configuration pour la gestion des fragments IP

Les paramètres suivants sont disponibles pour la configuration :

Cette option permet de définir une valeur de MTU (Maximum

Le temps par défaut est de 2 secondes.

PRÉVENTION D’INTRUSION : ANALYSES IP

• Exemple d’attaque par fragmentation

• Exemples d’attaque par recouvrement

Attaque par fragmentation IP

Attaque par recouvrement

PRÉVENTION D’INTRUSION : ANALYSES D’ÉTAT / FILTRAGE

TCP, UDP, ICMP

Analyses IPv4, IPv6

L’analyse protocolaire sur la couche transport

PRÉVENTION D’INTRUSION : ANALYSES D’ÉTAT / FILTRAGE