Vous êtes sur la page 1sur 97

'

&
$
%
Rapport de stage

ETUDE IPSec ET INTEGRATION


DE LEXTENSION (( MODE CONFIG ))
DANS LE MODULE IPSec DES UTMs
NETASQ
Jigar SOLANKI
Avril-Septembre 2008
Master 2 Cryptologie et Securite Informatique
Responsables
Universite : Emmanuel Fleury NETASQ : Yvan Vanhullebus
Abdou Guermouche
Universite Bordeaux 1 NETASQ - We Secure IT
351, Cours de la Liberation 3 rue Archim`ede
33405 Talence Cedex 59650 Villeneuve dAscq
.
Table des mati`eres
Remerciements 8
Introduction 10
NETASQ en quelques mots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Objetifs du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Plan du rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
I Les protocoles IPSec 14
I.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.1.1 Champ daction dIPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.1.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I.1.3 Pourquoi deployer IPSec ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
I.2 Vue generale des protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
I.2.1 Mode Transport, Mode Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 19
I.2.2 Protocole AH, Protocole ESP . . . . . . . . . . . . . . . . . . . . . . . . . . 21
I.2.3 Etablissement dune negociation IPSec . . . . . . . . . . . . . . . . . . . . . 24
I.3 Design et architecture de securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
I.3.1 Extremites de tunnel, de trac . . . . . . . . . . . . . . . . . . . . . . . . . 26
I.3.2 Associations de Securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
I.3.3 politiques de securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
I.4 Phases de negociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
I.4.1 Phase1 : ISAKMP SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
I.4.2 Phase2 : IPSEC SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
I.5 Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
II Extensions IPSec et problematiques de securite 33
II.1 Authentication XAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
II.1.1 Principe et fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
II.1.2 Notications de type XAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 34
II.1.3 Securite de XAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
II.1.4 XAuth et le Group Password . . . . . . . . . . . . . . . . . . . . . . . . . . 37
II.2 Hybrid-Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
II.2.1 Presentation generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
II.2.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
II.2.3 Authentication forte et compl`ete . . . . . . . . . . . . . . . . . . . . . . . 39
II.3 Mode Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
II.3.1 Presentation Generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
II.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
II.3.3 Param`etres disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
II.3.4 Pool et penurie dadresses IP . . . . . . . . . . . . . . . . . . . . . . . . . . 41
II.4 Interactions XAuth, Hybrid et Mode Cong . . . . . . . . . . . . . . . . . . . . . . 42
II.5 Faiblesses dIPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
II.5.1 Failles cryptographiques intrins`eques . . . . . . . . . . . . . . . . . . . . . . 42
II.5.2 Probl`emes dimplementation . . . . . . . . . . . . . . . . . . . . . . . . . . 43
II.5.3 Deploiements reels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
IIILes UTMs NETASQ 45
III.1 Presentation des UTMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
III.1.1 Quest ce que lUTM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
III.1.2 La premi`ere generation des UTMs NETASQ : Les series F . . . . . . . . . . 47
III.1.3 La nouvelle generation G2 : Les series U . . . . . . . . . . . . . . . . . . . . 49
III.2 LASQ - Active Security Qualication . . . . . . . . . . . . . . . . . . . . . . . . . 51
III.2.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
III.2.2 ASQ : Pile OSI Virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
III.2.3 Analyses de lASQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
- 4 -
III.3 Fonctionalites Avancees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
III.3.1 Authentication et PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
III.3.2 Traitement des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
III.3.3 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
III.4 Managment et Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
IVIntegration du Mode Cong 61
IV.1 Tests et audit sur ipsec-tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
IV.1.1 Etat dipsec-tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
IV.1.2 Congurations Racoon (( basique )) . . . . . . . . . . . . . . . . . . . . . . . 62
IV.1.3 Injection de politiques de securite par setkey . . . . . . . . . . . . . . . . . 64
IV.1.4 Conguration en XAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
IV.1.5 Mode Cong : racoon vs racoon . . . . . . . . . . . . . . . . . . . . . . . . . 67
IV.1.6 Mode Cong : racoon vs quelques clients VPN . . . . . . . . . . . . . . . . 68
IV.1.7 Bilan des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
IV.2 Extension du format du chier de conguration IPSec . . . . . . . . . . . . . . . . 71
IV.2.1 Fichiers de conguration NETASQ et parseurs . . . . . . . . . . . . . . . . 71
IV.2.2 Conception et extension du chier . . . . . . . . . . . . . . . . . . . . . . . 72
IV.3 Integration et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
IV.3.1 Imperatifs dimplementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
IV.3.2 Premiers tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
IV.3.3 Validation et Commit dans le rmware . . . . . . . . . . . . . . . . . . . . . 76
Conclusion et Bilan 78
Annexe A : Protocole AH et ESP appronfondis 81
Annexe B : Echange Die-Hellman 91
RFCs IPSec 93
References et Bibliographie 95
- 5 -
Table des gures
I.1 Positionnement dIPSec dans la pile IP . . . . . . . . . . . . . . . . . . . . . . . . 16
I.2 IPSec en Mode Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
I.3 En-tete en Mode Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
I.4 IPSec en Mode Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
I.5 En-tete en Mode Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
I.6 Authentication Header - AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
I.7 Encapsulating Security Payload - ESP . . . . . . . . . . . . . . . . . . . . . . . . . 23
I.8 Synoptique de Fonctionnement IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . 25
I.9 Extremites de tunnel, de trac - www.cisco.com . . . . . . . . . . . . . . . . . . . . 27
I.10 Echanges de Phase 1 en Main Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 30
I.11 Echanges de Phase 1 en Aggressive Mode . . . . . . . . . . . . . . . . . . . . . . . 30
I.12 Quelques exemples de param`etres negocies lors dune Phase 2 . . . . . . . . . . . . 31
II.1 Principaux attributs lors dun echange XAuth . . . . . . . . . . . . . . . . . . . . . 35
III.1 Gamme pour PME : F25, F50, F60 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
III.2 Moyenne et Grosse gamme : F200 au F1200 . . . . . . . . . . . . . . . . . . . . . 48
III.3 Haute Gamme pour grands comptes : F2500 et F5500 . . . . . . . . . . . . . . . . 49
III.4 Anciens UTMs G1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
III.5 Nouveaux UTMs G2 - www.netasq.com . . . . . . . . . . . . . . . . . . . . . . . . . 50
III.6 ASQ : Pile OSI virtuelle en 7 couches . . . . . . . . . . . . . . . . . . . . . . . . . 52
III.7 Dierentes etapes danalyses de lASQ . . . . . . . . . . . . . . . . . . . . . . . . . 52
III.8 Haute Gamme pour grands comptes : F2500 et F5500 . . . . . . . . . . . . . . . . 54
III.9 Synoptique des UTMs NETASQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
III.10High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
III.11Suite dadministration des IPS-Firewalls NETASQ . . . . . . . . . . . . . . . . . . 59
III.12NETASQ Firewall Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
IV.1 ScreenShot ShrewSoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
IV.2 Paquet IPv4 Generique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
IV.3 Champ de len-tete AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
IV.4 Hash AH en mode Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
IV.5 Hash AH en mode Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
IV.6 En-tete ESP avec (` a d.) et sans (` a g.) Authentication . . . . . . . . . . . . . . . . 88
IV.7 Paquet ESP en Mode Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
IV.8 Paquet ESP en Mode Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
IV.9 Protocole Die-Hellman - www.plenz.com . . . . . . . . . . . . . . . . . . . . . . . 92
- 7 -
Remerciements
Je voudrais en tout premier lieu adresser mes sinc`eres remerciements `a Yvan Vanhullebus, qui
a bien voulu me faire lhonneur daccepter de superviser mes travaux au sein de NETASQ. Son
attention et sa disponibilite, dont jai use et abuse, mont ete dune aide tout `a fait precieuse ; ses
recommandations et ses conseils reellement enrichissants.
Je dois egalement beaucoup `a Damien Deville et, plus indirectement `a Frederic Raynal, sans
qui je ne serai sans doute jamais arrive `a NETASQ.
Mes chaleureux remerciements `a tous ceux que jai pu cotoyer, de pr`es ou de loin, `a NETASQ et
en particluer, `a lensemble des equipes du laboratoire R&D. Mavoir acceuilli avec cette amabilite
et gentillesse qui les caracterisent mont ete dun reel reconfort tout au long de cette periode.

Etre
entoure de personnes extremement competentes dans leur domaine na fait quaccrotre mon envie
de progresser et dapporter ma minuscule petite pierre `a ledice. Que ce soit `a travers lambiance
chaleureuse au sein de la societe, ou encore `a travers ces dejeuners copieux, propres `a ces ch`ers
chtis, rendant souvent les apr`es-midi compliques, jy ai passe de tr`es agreables moments.
Un grand merci `a Abdou Guermouche davoir accepte detre rapporteur et `a Emmanuel Fleury
pour sa disponibilite et sa reactivite `a luniversite. Lensemble des remarques dont ils mont fait
part mont ete dun grand secours.
Une pensee pour lensemble de mes amis qui mont toujours aide, encourage et soutenu, dans
les bons moments comme dans les mauvais. Leur bonne humeur et joie de vivre mont ete dun
reconfort inestimable. Quils trouvent ici ma plus profonde gratitude.
Un immense merci `a ma famille, mes parents, qui mont permis de poursuivre dans la voie qui
minteressait et qui mont toujours aide `a aller de lavant, et enn, `a celle qui ma soutenu sans
faille aucune et sans qui je ne serai s urement pas l` a aujourdhui, merci `a toi !
`
A mes parents.
Introduction
Truth never damages a cause that is just.
Mahatma Gandhi
Les protocoles IPSec sont deployes `a des echelles de plus en plus grandes, quil sagisse de re-
lier des reseaux dagences et de sucursalles par lInternet, ou de proteger des reseaux dicilement
securisables comme le WiFi.
De plus avec lapparition du nomadisme, de plus en plus de personnes cherchent `a pouvoir acceder
aux ressources internes de lentreprise de mani`ere securisee de lexterieur. On peut citer les com-
merciaux terrains, les ingenieurs travaillant de chez eux ou encore les directeurs en deplacement.
NETASQ propose des solutions robustes de securisation des ux, et transparente pour lutilisa-
teur, bases sur des VPN/IPSec en particulier. Plus generalement, NETASQ fournit des solutions
de securite, dantivirus ou de pare-feux `a des entreprises de tailles dierentes, allant de la petite
PME aux grands comptes ou encore `a lArmee Fran caise.
Le module VPN/IPSec NETASQ propose aujourdhui embarquer lensemble de le conguration
reseau necessaire aux clients nomades pour quils puissent acceder aux ressources internes de len-
treprise. Ce module est destine `a etre ameliore, notamment par lintegration dune extension IPSec
appellee Mode Conguration. Cette extension permet denvoyer cette conguration reseau au client
nomade de mani`ere securisee, dynamiquement `a la volee, pour que celui ci naie plus `a embarquer
ces informations de mani`ere statique sur sa machine. Dautre part, cette integration permettra
dalleger la charge de ladministrateur qui naura plus `a maintenir individuellement lensemble du
parc des machines nomades de son entreprise.
Apr`es avoir expose les activites principales de la societe NETASQ, nous presenterons les ob-
jectifs principaux du stage. On detaillera un plan des principaux chapitres traites an de guider le
lecteur, averti ou pas.
NETASQ en quelques mots . . .
Cree en 1998, NETASQ est lune des societes europeennes majeures sur le marche de la securite
informatique dont le si`ege social est ` a Villeneuve dAscq dans le nord de la France. Elle propose des
solutions qui permettent de repondre aux enjeux et problematiques de la securite des entreprises
sur plusieurs segments : la securite uniee par les appliances UTMs rewalls, la detection des
vulnerabilites par SEISMO ou encore le ltrage et la protection des messageries par les boitiers
MFILTRO.
NETASQ commercialise donc toute une gamme de solutions de securite uniee (UTM). Dautre
part, lensemble des UTMs NETASQ int`egrent lASQ (Active Security Qualication), technologie
de prevention dintrusion en temps reel protegee par plusieurs brevets.
NETEASQ a ete presente d`es le debut en Europe, notamment en Belgique, en Italie et au Roy-
aume uni. Aujourdhui presente dans plus de cinquante pays, par lintermediaire de partenaires
certies, elle apporte des solutions adaptees aux marches locaux.
Ces clients viennent de secteurs et de tailles tr`es variees, des petites entreprises jusquaux grands
comptes comme Orange Business Services ou Portugal Telecom.
A la pointe de linnovation technologique, toujours `a la ut des derni`eres avancees en termes
de securite, integrant sa technologie de prevention ASQ sur lensemble de sa gamme, les raisons
faisant de NETASQ une societe en securite informatique en avance sur son temps ne manquent pas.
Certiee par plusieurs organismes, NETASQ a, entre autres, ete recompensee par le Fast 50 en
France pendant deux annees consecutives. Elle a en outre re cu la certication internationale des
Crit`eres Communs V2.2 au niveau EAL2+ (norme ISO 15408 et ISO 18045). Les UTMs
sont testes dans des conditions reelles dexploitation par des appliances SPIRENT.
Enn, les retours des clients etant revelateurs de la qualite des produits dune societe, on peut
notamment citer Sebastien Truttet, responsable des infrastructures du groupe IS Altran : (( Nous
avons decide de supprimer les pare-feux de lautre fabriquant et de nutiliser que des pare-feux
NETASQ comme barri`ere de securite unique ))et dans un tout autre domaine, Frederic Andre,
Responsable Technique et Informatique du Centre Hospitalier de Valenciennes : (( Depuis plus de
trois ans, nous apprecions la reactivite de NETASQ aussi bien sur les mises `a jours que sur le
service apr`es vente )).
- 11 -
Objectifs du stage
Le module VPN/IPSec du rmware NETASQ est base sur le projet ipsec-tools, sous licence
BSD. ipsec-tools est constitue de setkey, utilisaire de manipulation et dinjection de politiques
de securite, de racoon, demon de negociation IKE que nous allons manipuler tout au long du stage,
et de racoonctl, utilitaire de manipulation de racoon.
Le but principal du stage consite `a integrer lextension IKE Mode Conguration dans le
rwmare NETASQ. Cette extension permet denvoyer les informations de conguration reseau
aux clients mobiles nomades. On appelle ces clients des road warriors, ils ont la particularite de ne
pas avoir dadresse IP xe connue de la passerelle.
Cette integration pourrait se faire en plusieurs etapes :
Dans un premier temps, prendre en main lenvironnement de travail sous FreeBSD, et avoir
une pile IPSec operationnelle.
Etudier les extensions IKE XAuth, Hybrid et Mode Conguration, puisque les trois extensions
sont activees par une seule option de racoon.
Evaluer limplementation actuelle du Mode Conguration dipsec-tools, `a travers une lecture
et un audit de code, une batterie de tests destines `a conrmer ou inrmer la stabilite. Le
cas echeant, modier le code dipsec-tools an de corriger deventuels bugs ou erreurs de
conception et den ameliorer les performances.
Prendre en main les UTMs NETASQ, etudier les dierentes fonctionalites et modules disponibles
et se familiariser avec le rmware NETASQ.
Eectuer un travail de conception avec lensemble de lequipe R&D an detendre le chier
de conguration VPN NETASQ pour y integrer le Mode Conguration.
Implementer les dierentes librairies.
Eectuer les premiers tests pour valider limplementation.
Eectuer des tests beaucoup plus pousses avec lequipe de Qualication, notamment des tests
de performances sur des SPIRENT et des tests de non-regression.
Repartir sur un travail de conception avec lequipe IHM an quelle puisse integrer les boutons
et/ou fenetres Mode Conguration de la mani`ere la plus adequate possible compte tenu des
contraintes de racoon, mais egalement de la mani`ere la plus ergonomique possible pour le
client nal.
Le Mode Cong, si les objectifs sont atteints, sera disponible en tant que fonctionalite option-
nelle dans la future version du rmware NETASQ.
- 12 -
Plan du rapport
Ce rapport presente lensemble du travail realise sur ces six derniers mois, `a travers essentielle-
ment quatre chapitres qui re`etent le l directeur que jai suivi durant le stage :
Chapitre 1 : IPSec Ce chapitre presente les protocoles IPSec, leur fonctionnement, leur design
et la mani`ere dont ils sont deployes. Cette etude permettra de mieux naliser lensemble des
tests realises sur IPSec et le Mode Conguration en particulier.
Chapitre 2 : Extensions IPSec Ce chapitre decrit les extensions XAuth, Hybrid et Mode Con-
guration. Ces extensions permettent davoir une authentication supplementaire durant la
phase de negociation (Hybrid et XAuth) et de transmettre les informations de mani`ere
dynamique et securisee (Mode Cong). Une section est egalement consacree `a certaines
problematiques de securite posees par les deploiements reel dIPSec.
Chapitre 3 : UTM NETASQ On etudie, dans ce chapitre, les fonctionalites des rewalls NE-
TASQ. Une description du fonctionnement de lASQ permet de mieux comprendre le rmware
NETASQ.
Chapitre 4 : Integration du Mode Cong On presente ici lensemble de nos travaux, apr`es
avoir pris en main lenvironnement dans son ensemble (etude IPSec, prise en main des UTMs,
etude sur le rmware, etc). Le chier de conguration NETASQ est etendu et les champs
Mode Conguration ajoutes. Une batterie de tests naux nissent lintegration.
Un approndissement des principaux protocoles IPSec est disponible en annexe.
- 13 -
CHAPITRE I
Les protocoles IPSec
An error does not become truth by reason of multiplied propagation,
nor does truth become error because nobody sees it.
Mahatma Gandhi
Resume :
IPSec est une suite de protocoles destines `a securiser le trac au niveau IP. Il a ete
initiallement developpe au sein du projet KAME pour IPv6, puis backporte `a IPv4.
IPSec fournit notamment la condentialite des donnees qui transitent, leur authen-
tication, leur integrite en mode non-connecte et une protection contre le rejeu. Il
permet ainsi de proteger lensemble des couches superieures reposant sur IP.
IPSec peut fonctionner suivant deux modes : en mode transport pour une utilisation
de type Host-To-Host ou en mode tunnel pour le deploiement de passerelle VPN (Gate-
To-Gate ou Host-To-Gate).
Les ux sont chires et/ou signes par des algorithmes cryptographiques `a cle secr`ete, `a
travers deux protocoles : AH assurant lauthentication et lintegrite des donnees et ESP
assurant principalement leur condentialite mais permet de les authentier egalement.
Lechange et le renouvellement de lensemble des cles cryptographiques est assure par
le protocole IKE - Internet Key Exchange qui lui meme est une instanciation du pro-
tocole ISAKMP - Internet Security Association and Key Managment Protocol
utilisant entre autres, le protocole Oakley permettant de realiser les echanges Die-Hellman
notamment.
Les param`etres dune politique de securite (identite de lhote, algorithmes `a utiliser, etc)
sont stockes dans une Security Association (SA). Lensemble des SA sont alors stockees
dans une base de donnees de SA appellees Security Association Database (SAD).
Enn, les dierentes politiques de securite `a appliquer aux paquets transitant par le
module IPSec sont stockees dans une structure noyau appellee Security Policy Database
(SPD).
CHAPITRE I. LES PROTOCOLES IPSEC
I.1 Pr

esentation
I.1.1 Champ daction dIPSec
En mati`ere de securisation des echanges sur un reseau (a fortiori sur un reseau TCP/IP), les
services disponibles peuvent etre relativement dierents suivant la couche de la pile reseau dans
laquelle ils op`erent. On peut citer :
Les protections au niveau applicatif integres dans lapplication en elle meme.
Les protections au niveau de la couche transport (TCP, UDP...) en utilisant les protocoles
SSL/TLS et OpenVPN pour letablissement de tunnels SSL.
Les protections au niveau de la couche liaison avec par exemple des tunnels PPTP.
Quant `a IPSec (Internet Protocol Security), il denit une collection de protocoles destines `a
securiser lensemble du trac sur un reseau repute non securise, typiquement `a travers lInternet.
En eet, le protocole IP tel quil a ete con cu ne prevoit pas la protection et la securisation des
donnees transmises. IPSec denit une extension dIP destine `a palier `a ce manque. Il intervient
au niveau de la couche 3 - Reseau - du mod`ele OSI (cf. Fig I.1) en securisant les ux IP. Il op`ere
donc de mani`ere totalement transparente pour lutilisateur, moyennant le temps de latence d u aux
negociations avec lh ote distant et aux traitements des paquets du point de vue cryptographique,
les algorithmes de chirement et dauthentication etant gourmands en ressources. Le support
dune pile IPSec est optionnel pour IPv4, mais obligatoire pour toute implementation conforme
dune pile IPv6. Normalise pour la premi`ere fois en 1998 dans la RFC 2401, larchitecture IPSec a
connu bien des evolutions en une decenie, quil sagisse de la pile IPSec noyau ou des demons IKE
de negociation de cles ou de manipulation de r`egles de SPD.
I.1.2 Historique
Les piles IPSec
Une des toutes premi`eres implementations dIPSec fut celle du projet KAME. Ce projet re-
groupait pr`es dune dizaine de grosses compagnies japonaises, dont Fujitsu, Hitachi, NEC ou en-
core Toshiba, dans le but de fournir une implementation dune pile IPv6, IPSec et IPMobile pour
les syst`emes BSD. Les syst`emes qui ont integre la pile KAME/IPSec sav`ereront etre, par la suite,
FreeBSD et NetBSD. Dans le meme temps, il se trouve quOpenBSD avait dej` a implemente sa pro-
pre pile IPSec depuis la version 2.1 datant de 1997, avec ses dierents avantages et inconvenients. Le
principal avantage de la pile IPSec dOpenBSD etait lintegration de lacceleration cryptographique
materielle en natif, permettant daccrotre considerablement les debits et les performances.
Concernant les syst`emes dexploitation bases sur un noyau Linux, la toute premi`ere imple-
mentation dune pile IPSec fut realisee par le projet FreeS/WAN dont la derni`ere version, 2.06,
- 15 -
I.1. PR

ESENTATION
Transport : TCP, UDP
Applications
Liaison, Physique
IPSec
IPSec
Anciennes
Piles IPv4
Piles IPv4
IPSec
Intgrant
Rcentes
Pile IPv6
Intgrant
Nativement
IPSec
Fig. I.1 Positionnement dIPSec dans la pile IP
date de 2004. FreeS/WAN fut alors divise en deux autres projets que sont OpenS/WAN et
StrongS/WAN. Toutefois, aucunes de ces trois piles IPSec ne fut integree dans les noyaux Linux.
En eet, `a lhorizon 2002, deux developpeurs du noyau Linux, A. Kuznetsov et D. S. Miller ont
enti`erement implemente une pile IPSec en sinspirant des des travaux du groupe USAGI IPv6.
Cette pile est celle qui est aujourdhui integree en natif dans les noyaux 2.6.x.
Sur FreeBSD, la pile integree dans le noyau fut `a lorigine la pile KAME/IPSec. Toutefois, un
portage de la pile IPSec dOpenBSD integrant lacceleration cryptographique materielle a ete
realise, ce qui a donne la pile FastIPSec. Deux piles IPSec ont alors ete maintenues, et lorsque
lensemble des fonctionalites presentes dans KAME/IPSec lont egalement ete dans FastIPSec, les
developpeurs FreeBSD ont abandonne la pile KAME. Ainsi, depuis la version FreeBSD 7.0, seule une
pile IPSec est integree et maintenue, `a savoir FastIPSec.
Les demons en espace-utilisateur
Parall`element au developpement des dierentes piles IPSec, il etait necessaire, comme nous le
verrons plus tard, davoir des demons sexecutant une espace utilisateur an de manipuler, cong-
urer, maintenir, administrer les dierentes congurations et politiques `a appliquer aux ux ; comme
par exemple lauthentication du site distant, lechange securise des cles cryptographiques, savoir
si le site distant est toujours disponible, etc.
Theoriquement, les demons en espace utilisateur sont independants de la pile IPSec dans le
- 16 -
CHAPITRE I. LES PROTOCOLES IPSEC
noyau, et il est possible dutiliser nimporte quel demon sur toutes
1
les piles IPSec decrites plus
haut. Nous verrons un peu plus tard pourquoi ce nest pas totalement vrai, puisque linterfa cage `a
travers lequel ils communiquent avec le noyau nore pas autant de requetes quil serait souhaitable
den avoir.
Ainsi, le projet KAME disposait de son propre demon, racoon, repris plus tard par le projet
ipsec-tools. Cest sur ce projet quest base en grande partie le stage. Dautre part, OpenBSD avait
implemente son demon en parall`ele de la pile, isakmpd aujourdhui encore integre dans OpenBSD
4.x. Enn, pour les syst`emes Linux, plusieurs ont vu le jour. On peut citer pluto, demon des
projets xS/WAN, ou encore racoon qui supporte Linux, FreeBSD et NetBSD.
IPSec est aujourdhui tr`es largement deploye, en particulier pour la mise en place de VPNs
2
,
an de securiser les echanges entre sites distants. Lavantage par rapport ` a dautres solutions de
tunnelling comme OpenVPN, base sur SSL/TLS securisant TCP, reside dans la totale transparence
au niveau de lutilisateur et la securisation de lensemble des couches basees sur IP, notamment
lensemble des couches de transport comme TCP et UDP.
Les implementations proprietaires
Toutes les implementations IPSec ne sont en eet pas OpenSource. Des grands comptes comme
Microsoft ou Cisco poss`edent aujourdhui leur propre implementation de pile IPSec. Bien quIPSec
soit un moyen extremement robuste an de transmettre du trac chire, il nen reste pas moins
vrai que linteraction avec dautres piles IPSec pose par moments des probl`emes de compatibilites.
I.1.3 Pourquoi deployer IPSec ?
Quil sagisse de lensemble des services de securite fourni, ou de la exibilite dans le deploiement,
ou encore du co ut moindre par rapport `a des lignes dediees, les VPN/IPSec sont de plus en plus
presents dans larchitecture reseau des entreprises.
Services de securite
Le pannel de services disponibles sous IPSec est assez varie ce qui lui permet detre tr`es exi-
ble lors du deploiement de topologies reseaux securisees. On regroupe ici quelques mecanismes de
securite disponibles :
Authentication des correspondants : Il sagit dune authentication `a double sens o` u chaque
extremite sassure de ladresse de son correspondant. Il sagit principalement des adresses IPs
des machines deploiyant IPSec et non pas des reels utilisateurs des dites machines. Nous ver-
rons la mani`ere dont les extentions ISAKMP/XAuth et ISAKMP/Hybrid permettent de remedier
`a cela en orant une authentication forte supplementaire des utilisateurs en plus de celle
1
sous reserve que les demons soient bien en environnement compatible, racoon ne fonctionnera bien entendu pas
sur une architecture de type Win32
2
VPN :Virtual Private Network, ou Reseaux Virtuels Prives (RVP)
- 17 -
I.1. PR

ESENTATION
des machines, notamment pour les clients mobiles possedant une IP dynamique.
Authentication des ux : Il sagit de verier que les ux qui circulent dans le tunnel ont bien
ete emis et/ou sont bien `a destination de lune ou lautre des extremites. IPSec dispose prin-
cipalement de methodes de hachages an de realiser cette operation, `a travers le protocole
AH et/ou ESP.
Condentialite des ux : Le payload des paquets IP est enti`erement chire `a laide dalgo-
rithmes cryptographiques `a cle secr`ete, envoye `a travers le tunnel et dechire une fois arrive
`a destination.
Integrite des ux : Lorsquun paquet IPSec
3
subit une quelconque modication lors de son
trajet, elle est detectee et le paquet est ignore. Lintegrite en mode non-connecte permet de
detecter une quelconque modication dun datagramme individuel, mais pas sur lordre des
datagrammes, leur ordonnancement, ou la perte de paquets o` u lon parle dintegrite en mode
connecte. Cela prot`ege les ux de toute alteration quils peuvent subir et permet notamment
de se premunir contre des attaques actives. Nous verrons pourquoi ceci est tr`es problematique
lorsquil sagit de traversser des equipements NAT
4
et comment lextension IPSec NAT-T per-
met dy remedier.
Protection contre le rejeu et lanalyse de trac : Bien quun attaquant ne puisse pas dechirer
ou modier un paquet chire, il pourrait juste le capturer et le renvoyer plus tard. IPSec per-
met de se proteger contre ce type dattaque par rejeu de paquets. Ceci apporte egalement
une protection supplementaire contre les eventuelles ecoutes et analyses de trac puisque
lensemble du payload etant chire, un eventuel attaquant ne pourrait pas savoir quelle
couche de transport est utilisee (TCP UDP ICMP . . .) ou encore quelle type de protocole de
niveau superieur (HTTP FTP SMTP), etc.
Souplesse cryptographique : IPSec nest lie `a aucun algorithme cryptographique en parti-
culier. Il supporte de multiples algorithmes `a cle secr`ete, et est capable de negocier dy-
namiquement les algorithmes supportes par tel ou tel hote tentant detablir une connexion.
Bien que cette souplesse de negociation soit avant tout un avantage, nous mettrons laccent
sur le fait que cela peut etre dun niveau de securite moindre lorsque certains param`etres
ne sont pas choisis de mani`ere adequate. A titre dexemple, un proposal check obey peut
faire en sorte que les hotes negocient le chirement DES alors que les deux supportent AES.
Services de exibilite
Les passerelles VPN/IPSec sont typiquement deployees dans des entreprises qui disposent de
locaux geographiquement eloignes les uns des autres. Lensemble des services disponibles sur le site
central doivent egalement letre sur les dierents sites distants. Outre une grande souplesse dans
3
paquet AH ou ESP
4
NAT - Network Address Translation
- 18 -
CHAPITRE I. LES PROTOCOLES IPSEC
la mise en place de tunnels VPNs, on peut noter :
Bande passante : Les WANs traditionnels utilises pour la communication inter-sites sont bases
sur Frame Relay
5
, ou sur ATM. Avec lapparition de nouveaux services necessitant de plus
en plus de debit, il a fallu choisir entre multiplier les lignes entre les sites ou trouver dautres
alternatives securisees et de debits acceptables. Do` u le compromis trouve dadopter des so-
lutions basees sur IPSec.
Reduction des co uts : Avec la diminution des co uts des abonnements des fournisseurs dacc`es,
avoir une ligne dediee co ute beaucoup trop ch`er en terme de deploiement et de maintenance.
De plus en plus dentreprises se tournent vers des fournisseurs dacc`es et securisent leur ux
plutot que dacheter des lignes dediees.
Disponibilite, adaptabilite : IPSec peut etre deploye en tout point disposant dun acc`es reseau.
Tandis que la plupart des societes poss`edent dej` a des lignes de communication dediees entres
leurs dierents sites distants, le debit est bien souvent insusant lorsquil sagit dacceder
`a une panoplie de services de plus en plus gourmands en bande passante. Dans ces cas,
comme precedemment, il est possible de deployer des tunnels IPSec entre ces dierents sites,
en y faisant passer les informations les moins critiques, alors que les donnees tr`es sensibles
continuent `a etre acheminees ` a travers le WAN dedie.
I.2 Vue g

en

erale des protocoles


IPSec regroupe toute une suite de protocoles, de specications, dacronymes decrits dans
dierentes RFCs se referen cant les unes aux autres, ce qui rend sa prise en main relativement
delicate de prime abord. On presente ici une vue densemble de ces dierents protocoles an de
mieux comprendre ce que font les dierents modules avant dapprofondir les caracteristiques des
protocoles en question.
I.2.1 Mode Transport, Mode Tunnel
Suivant les besoins et les utilisations, IPSec peut fonctionner sur deux modes, le mode Trans-
port et le mode Tunnel .
Mode Transport
IPSec en mode Transport (` a ne pas confondre avec la couche transport du mod`ele OSI) est
particuli`erement adapte pour la communication entre deux hotes. Cela presuppose donc linstalla-
tion et la conguration prealables dune pile IPSec sur les deux syst`emes.
En mode Transport, les mecanismes de securisation viennent sintercaler entre les couches
Transport et Reseau : les entetes IPSec appropriees (AH et/ou ESP) sont appliques apr`es que les
5
Relai de trames : transfert de donnees par commutation par paquets, ` a haut debit et sur de longues distances,
evolution de X.25
- 19 -
I.2. VUE G

EN

ERALE DES PROTOCOLES


IPSec Transport Host To Host
Alice Bob
Host A Host B
Fig. I.2 IPSec en Mode Transport
donnees soient passees par la couche -4- Transport et avant de les passer `a la couche -3- Reseau.
Ce mode prot`ege donc lensemble des donnees au dessus dIP.
IP Hdr
IP Hdr
Data
IPSec Hdr Data
A Protger
Fig. I.3 En-tete en Mode Transport
Ainsi, le principal defaut de ce mode reside-t-il dans labsence de masquage dadresses puisque
les adresses IP des deux correspondants sont visibles.
Pour permettre une protection de tout le paquet IP, le mode le plus souvent deploye est le
mode Tunnel .
Mode Tunnel
IPSec en mode Tunnel est utilise pour le deploiement de passerelles VPNs et permet de re-
lier un ensemble de reseaux de mani`ere securisee `a travers un reseau peu s ur comme lInternet.
Lensemble des postes nont alors nullement besoin dinstaller et/ou de congurer des syst`emes
supportant IPSec, seules les deux passerelles en sont dotees.
En mode Tunnel , les traitements IPSec sont appliques apr`es que lensemble des donnees aient
traverses la couche IP egalement. Les entetes (AH et/ou ESP) portent sur un datagramme IP en
entier et non plus seulement sur un datagramme TCP ou UDP ; et une nouvelle entete IP est rajoutee
- 20 -
CHAPITRE I. LES PROTOCOLES IPSEC
IPSec Gateway A IPSec Gateway B
Tunnel Gate To Gate
Fig. I.4 IPSec en Mode Tunnel
au paquet.
IP Hdr
IP Hdr
Data
IPSec Hdr Data
A Protger
New
IP Hdr
Fig. I.5 En-tete en Mode Tunnel
Comme on peut le voir, les adresses source et destination sont enti`erement masquees, les corre-
spondants reels ne sont pas visibles, et lon dispose dune protection contre lanalyse de trac. Le
mode Tunnel est le mode le plus souvent utilise et deploye `a grande echelle.
I.2.2 Protocole AH, Protocole ESP
IPSec repose principalement sur deux protocoles destines `a securiser le trac :
AH : Le protocole AH - Authentication Header.
ESP : Le protocole ESP - Encapsulating Security Protocol.
- 21 -
I.2. VUE G

EN

ERALE DES PROTOCOLES


Protocole AH
AH (Authentication Header) est utilise principalement pour fournir une authentication et
un controle dintegrite des donnees.
AH ne permet pas de chirer les paquets. Il ne doit donc pas etre utilise lorsque lon souhaite avoir
la condentialite des donnees.
AH prot`ege lensemble des donnees, ainsi que lensemble des en-tetes non modiables (numero de
protocole, port de destination, etc). Il nore, en revanche, pas de protection sur lensemble des
en-tetes susceptibles detre modiees lors du trajet du paquet comme par exemple le champ TTL
ou le champ ToS de len-tete IP.
Suivant le mode Transport ou Tunnel, la gure I.6 decrit la mani`ere dont AH encapsule les donnees.
IP Hdr
IP Hdr
Data
AH Data
New
IP Hdr
Authenti sauf les champs modiables dans New IP Hdr
Paquet Original
AH
IP Hdr
Data
Authenti sauf les champs modiables dans IP Hdr
Mode Transport
Mode Tunnel
Fig. I.6 Authentication Header - AH
Comme on peut le voir, AH prot`ege lensemble des champs non-modiables du paquet. Il peut
etre utile lorsque la condentialite des donnees nest pas recherchee dune part, et dautre part
lorsquune authentication forte du paquet est exigee. La transmission du resultat dune election
o` u les donnees sont destinees `a etre publiques mais doivent provenir de source s ure est un bon
exemple.
- 22 -
CHAPITRE I. LES PROTOCOLES IPSEC
Protocole ESP
ESPest le deuxi`eme protocole denit dans la suite IPSec. Protocole le plus repandu dans la pra-
tique, ESP (Encapsulating Security Payload) ore egalement la condentialite des donnees.
Lensemble des donnees sont alors chirees avant detre transmises, suivant dierents mecanismes
et protocoles que lon detaille `a la section I.2.3.
ESP chire, dune part, le champ Data des paquets suivant un ensemble de param`etres negocies
au prealable avec lh ote distant, et dautre part, utilise des mecanismes dauthentication (comme
HMAC) an de fournir une protection anti-rejeu ou encore une integrite des donnees. A ce titre,
ESP est un protocole tr`es complet, orant toute une panoplie de protections allant du simple
chirement des donnees jusqu`a leur authentication en plus.
La gure I.7 decrit la mani`ere dont ESP encapsule lensemble des champs des paquets.
IP Hdr
IP Hdr
Data
Data
New
IP Hdr
ESP
IP Hdr Data
CHIFFRE
Mode Transport
Mode Tunnel
Hdr
ESP
Trailer
ESP
Auth
AUTHENTIFIE
ESP
Hdr
Trailer
Auth
ESP
ESP
CHIFFRE
AUTHENTIFIE
Fig. I.7 Encapsulating Security Payload - ESP
- 23 -
I.2. VUE G

EN

ERALE DES PROTOCOLES


AH et ESP
Il est tout `a fait possible dutiliser les deux protocoles conjointement, meme si cela reste tr`es
peu utilise. Lorsque lon recherche ` a avoir une condentialite des donnees et une authentication
compl`ete du paquet, il est possible dutiliser dans un premier temps ESP an de chirer les donnees
et authentier les champs concernes, puis daposer AH sur le paquet ESP obtenu. On a ainsi une
authentication compl`ete de tous les champs du paquet et un chirement des donnees.
Ce mode de fonctionnement est neanmoins tr`es lourd et gourmand en bande passante. En pra-
tique, le mode Tunnel ESP reste tr`es securise et ore lensemble des services de securite mentionnes
plus haut.
I.2.3 Etablissement dune negociation IPSec
Phases IPSec
Il existe deux fa cons detablir des echanges chires entre deux hotes IPSec :
Dynamique : La negociation dynamique est la plus repandue, la plus securisee et la plus con-
seillee. Elle permet de negocier `a la volee lensemble des param`etres necessaires et assure le
renouvellement periodique des cles cryptographiques mises en jeu et leur echange de mani`ere
securisee.
Statique : Principalement maintenue pour des raisons de compatibilites, ce mode de (( negociation ))est
tr`es obsol`ete et presente quelques failles de securite, puisque les cles sont non seulement sta-
tiques, donc jamais renouvellees. Ainsi, les tentatives dattaques par brute force ont plus de
chances daboutir. Cette methode de negociation ne sera pas abordee dans le cadre de ce
rapport.
Une negociation IPSec dynamique, cest `a dire utilisant un demon de negociation IKE, se fait
principalement en deux etapes ou phases.
Phase 1 : La premi`ere phase sert `a authentier mutuellement les deux correspondants et detablir
un canal de transmission securise. Par la suite, lensemble de la conguration et param`etres
necessaires sont negocies an de proteger les dierents echanges (les duree de vie, les infor-
mations diverses, etc). Lorsque cette phase est terminee, les deux correspondants disposent
dune ISAKMP SA. Il sagit dun canal de transmission securise par lequel les deux cor-
respondants vont sechanger dierentes informations, y compris les cles cryptographiques
destinees `a chirer et/ou authentier le trac des donnees proprement dites.
Phase 2 : La deuxi`eme phase permet essentiellement de se mettre daccord sur les protocoles
cryptographiques `a utiliser pour chirer et authentier tel ou tel type de trac entre les deux
hotes ; et de transferer les cles cryptographiques necessaires. Une fois cette phase realisee, les
correspondants disposent de deux IPSec SA chacun.
- 24 -
CHAPITRE I. LES PROTOCOLES IPSEC
A partir de ce moment, les deux hotes peuvent alors sechanger du trac de mani`ere securisee.
Les SAs sont developpees plus en details dans la section I.3.2.
Politiques et Associations de securite
Etant donne un trac qui doit etre chire avec tel protocole, un autre avec tel protocole et un
dernier ne devant pas letre, comment ce trac est-il eectivement traite ?
Lorsque les paquets arrivent (cf Fig I.8) entre la couche Transport et la couche Reseau, le noyau
verie tout dabord si ce trac doit subir un traitement IPSec ou non en fonction de dierents
champs contenus, entre autres, dans len-tete IP. Pour cela, le noyau cherche une politique de
securite correspondant au paquet, dans une base de politiques (SPD) prealablement conguree par
ladministrateur. La SPD permet de savoir si un type de trac doit subir un traitement IPSec ou
pas. Si ce nest pas le cas, le paquet sera envoye en clair. On pourrait schematiser la SPD - Security
Policy Database - par une seconde table de routage.
Pqt en Clair
IP
IPSec
S P D
Consulte
IPSec : Oui / Non?
S A D
SA1
SA2
SA3
.
.
.
Consulte
Pqt en Clair
Tunnel IPSec
Pqt Chiffr
I K E
Maintient, Ngocie
Modie, Supprime
Demande de
Cration de SA
Administrateur
logs
Congure
Fig. I.8 Synoptique de Fonctionnement IPSec
Si cest le cas, il faut `a present savoir `a quel type de tunnel il correspond. Le type (Tunnel,
Transport, ESP, AH) est egalement stocke dans la SPD. Une base de donnees de SA (SAD) est
maintenue en temps reel et contient lensemble des SAs des politiques IPSec actives. Dans le cas o` u
le noyau trouve une SA correspondante, il va y lire les param`etres necessaires (protocole `a utiliser,
- 25 -
I.3. DESIGN ET ARCHITECTURE DE S

ECURIT

E
taille des cles, etc) et traiter le paquet en consequence (ESP ou AH, Tunnel ou Transport) avant
de lenvoyer.
Si la SA nest pas trouve, le noyau demande au demon IKE le demon racoon du projet
ipsec-tools en locurrence de negocier une SA avec lh ote distant. Durant cette negociation,
lensemble des paquets devant subir un traitement IPSec `a destination de cet hote sont ignores.
Ceci explique le temps de latence lors de la premi`ere communication `a travers un tunnel IPSec.
Le detail et letude approndie des protocols AH et ESP est disponible dans lannexe A.
Maintenant que lon a etudie les protocoles de transmission dIPSec, il sagit de voir comment
les dierents param`etres, clefs de chirement, protocoles, identites des correspondants, etc. sont
geres dans le syst`eme.
Comment se fait le renouvellement periodique des cles ?
Comment detecte t-on lorsque lh ote en face ne repond plus ? Que faire dans ces cas l` a ?
Faut-il garder les param`etres en esperant que labsence soit temporaire ? Ou au contraire les sup-
primer directement ?
Autant de question auxquelles nous tenterons de repondre dans la section suivante.
I.3 Design et architecture de s

ecurit

e
Larchitecture complexe dIPSec repose sur le principe dAssociation de Securite. Il sagit dune
structure contenant un ensemble de param`etres negocies avec lh ote avec lequel lon souhaite etablir
une connexion IPSec. Ces dierentes associations sont stockees dans des bases de donnees dasso-
ciations, an de retrouver rapidement celle qui correspond `a tel ou tel hote.
I.3.1 Extremites de tunnel, de trac
On appelle extremite de tunnel (cf. Fig I.9) les deux extremites entre lesquelles le trac sera
eectivement chire et/ou signe. Il sagit des adresses des deux passerelles IPSec dans le cas dune
conguration en mode tunnel ou de ladresse des deux correspondants dans le cas dune congu-
ration en mode transport.
On appelle extremite de trac (cf. Fig I.9) les sous-reseaux qui sont autorises `a emprunter le
tunnel de part et dautre de la passerelle. Les extremites de trac constituent un point essentiel de
larchitecture IPSec : un sous-reseau bien que faisant partie du reseau interne de lentreprise, sil
nest pas autorise `a envoyer du trac IPSec vers telle ou telle passerelle sera detecte au moment
de la verication sur lextremite de tunnel.
- 26 -
CHAPITRE I. LES PROTOCOLES IPSEC
Fig. I.9 Extremites de tunnel, de trac - www.cisco.com
I.3.2 Associations de Securite
Les SAs representent une structure au coeur de toute connexion IPSec. Il sagit dun ensemble
ou dune collection de param`etres permettant detablir un tunnel de commmunication securise
entre deux hotes. Les SAs sont unidirectionnelles, il en faut ainsi deux pour une communication
bi-directionnelle.
Lorsque deux entites communiquent au travers dIPSec, il faut pouvoir distinguer la mani`ere
dont telles ou telles donnees sont chirees et/ou authentiees de telles ou telles mani`eres. Les SAs
contiennent ainsi, pour un hote distant donne, le protocole `a utiliser (AH et/ou ESP), les algo-
rithmes cryptographiques associes, les cles de chirement, la periode de renouvellement des cles, etc.
Elles sont identiees par un numero de SPI (Security Parameter Index). Le SPI permet
de savoir comment un paquet arrive sur linterface ipsec doit etre authentie et/ou dechire en
allant consulter les param`etres de la SA `a laquelle il correspond ; ou alors, il permet de connatre
les protocoles et cles `a utiliser lors du chirement dun paquet `a envoyer `a un hote donne.
Le concept de SA permet davoir dierents degres de chirement et/ou dauthentication entre
deux, voire plusieurs hotes. A titre dexemple, si lon consid`ere deux liales o` u lacc`es aux services
de mail est moins critique que lacc`es `a des applications nanci`eres. Bien que le tunnel IPSec soit
physiquement le meme, il existera deux politiques de chirement, donc deux SAs de chaque cote
an de chirer les paquets `a destination des applications nanci`eres `a laide de methodes tres ro-
bustes (donc plus co uteuses en temps et en ressources), et les ux `a destination des services mails
`a laide de chirement dun degre moindre.
Les dierentes SAs negociees avec les dierents hotes sont stockees dans une base de donnees
- 27 -
I.4. PHASES DE N

EGOCIATION
de SAs appellee SAD ou SADB (Security Association Database).
I.3.3 politiques de securite
Pour chaque paquet entrant ou sortant, il faut etre capable de determiner si ce paquet est des-
tine `a une quelconque interface IPSec ou sil doit etre envoye en clair sur le reseau. Il existe pour
cela une table dentrees de politiques de securite, pouvant etre assimilee `a une table de routage
interne, permettant de savoir `a quel type de trac est destine un paquet.
Ces dierentes politiques sont stockees dans une SPD (Security Policy Database) qui est
donc consultee `a chaque paquet sortant ou entrant. Ladministrateur a la charge de congurer
et maintenir les politiques dans le noyau `a travers des outils userland comme setkey du projet
ipsec-tools, largement utilise pendant le stage, de pair avec le demon IKE racoon.
Lorsquune SA nexiste pas ou nest plus valide et quun paquet doit etre envoye au travers
dune connexion IPSec, le noyau demande a un demon IKE de negocier une SA avec lh ote distant.
I.4 Phases de n

egociation
La negociation dune SA se fait principalement en deux phases. A lissue de la Phase 1, une
ISAKMP SA est cree. A partir de ce moment, les deux entites disposent dun tunnel securise et
peuvent negocier les param`etres de securisation des donnees en elles-memes : il sagit de la Phase
2 et permet detablir une IPSEC SA.
I.4.1 Phase1 : ISAKMP SA
La Phase 1 represente la negociation initialle an detablir la ISAKMP SA
6
entre les deux
hotes. Elle peut se faire de mani`ere robuste lorsque les conditions le permettent (notamment lorsque
ladresse IP du correspondant est connue `a lavance), il sagit dans ce cas du Main Mode ; ou elle
peut se faire par lAggressive Mode qui ne presuppose pas la connaissance de lIP de lh ote.
La Phase 1 commence par envoyer la liste des propositions dauthentication, de chirement
ainsi que les durees de vies `a negocier. Suivant la mani`ere dont est congure lh ote distant, la
negociation peut etre ou ne pas etre acceptee.
La deuxi`eme etape consiste `a calculer des cles de session par lintermediaire dun echange Die-
Hellman. Une fois les cles de sessions etablies, tout le trac `a partir de ce moment est chire.
6
Contrairement ` a une IPSEC SA, la ISAKMP SA est bidirectionnelle
- 28 -
CHAPITRE I. LES PROTOCOLES IPSEC
Authentication des correspondants
Il faut, `a present, authentier les deux correspondants. racoon dispose de plusieurs methodes
dauthentication, dont deux tr`es couramment utilisees :
Pre Shared Key : Il sagit dune cle pre-partagee `a lavance par les deux hotes (par hote, on
entend une adresse IP, un login ou encore un FQDN). A noter qu` a lheure actuelle, dans le
demon racoon, il nest pas possible de congurer une cle qui soit partagee par un ensemble
dutilisateurs ou par tout le monde (appelle aussi Wildcard ou Goup Password chez
TM
), ce
qui presente des risques de securite non negligeables. Cest la methode dauthentication la
plus frequemment utilisee car la plus simple `a mettre en place. Neanmoins, comme nous le
verrons dans le chapitre suivant, lauthentication en pre shared key est tr`es deconseillee
voire `a proscrire lorsquil sagit dauthentier des hotes de types Road Warrior, cest `a dire
ceux dont ladresse IP nest pas connue `a lavance.
Certicats X509 : Utilisant une Public Key Infrastructure, cest une methode dauthentication
par certicats numeriques X509
7
. Il sagit de la methode la plus s ure actuellement disponibles
`a au moins deux conditions : avoir une CRL
8
`a jour tr`es reguli`erement et en ce qui concerne
les Road Warrior, avoir deux CA dierentes, lune pour signer le certicat de la passerelle
IPSec et la deuxi`eme pour signer les certicats utilisateurs.
Une fois lauthentication des correspondants achevee, chacun accuse de la bonne reception des
dierents param`etres et la ISAKMP SA est consideree comme etablie.
Main Mode - Aggressive Mode
Letablissement de la ISAKMP SA peut se faire soit par six echanges (Main Mode) ou par
un couple dechanges en moins (Aggressive Mode).
Le Main Mode (cf Fig. I.10) permet davoir la Protection des Identites des correspondants
(Identity Protection Mode) ! Les echanges des empreintes des dierentes identites ne se font
quapr`es letablissement dun secret commun partage par les deux entites : lechange Die Hell-
man est fait au niveau 3 et 4 pour etablir la cle de session et lechange des empreintes est faite au
niveau 5 et 6. Lidentite et lempreinte de lidentite sont tous deux chires avec la cle partagee. En
Main Mode avec une authentication en Pre Shared Key, comme les echanges 5 et 6 sont chires,
cest ladresse IP du correspondant qui fait oce didentiant ; ce qui va devenir problematique
pour les road warriors puisque leur IP nest a priori pas connue `a lavance !
L Aggressive Mode (cf Fig. I.11) en revanche ne supporte pas la Protection des Iden-
tites
9
: les identiants sont envoyes en clair sur le reseau. En eet, lechange se fait avant
7
Un certicat X509 est une methode dauthentication liant une cle publique ` a un nom ou une adresse email
8
CRL : liste de revocation mise ` a jour reguli`erement, elle a denir lensemble des certicats qui ne sont plus
valides.
9
Sauf lorsquil sagit dune authentication en Hybrid
- 29 -
I.4. PHASES DE N

EGOCIATION
MAIN MODE
_________________________________________________________
| Initiateur | Repondeur |
|--------------------------------------------------------|
| HDR, SA |=============> |
| |
| <=============| HDR, SA |
| |
| HDR, KE, NONCE |=============> |
| |
| <=============| HDR, KE, NONCE |
| |
| HDR*, IDii, HASH |=============> |
| |
| <=============| HDR*, IDir, HASH |
|________________________________________________________|
Fig. I.10 Echanges de Phase 1 en Main Mode
quun secret commun ne soit determine entre eux. Lempreinte dauthentication nest pas chire,
contrairement au Main Mode et est envoye en clair. Des identites non protegees et une em-
preinte dauthentication non chiree rend l Agressive Mode susceptible `a des attaques de type
Man In The Middle (MITM) lorsquil est utilise de paire avec une authentication en Pre Shared Key.
Si de plus, les Pre Shared Keys sont faibles, un attaquant potentiel peut determiner la cle, hors
ligne, par une attaque par force brute sur lempreinte non chiree.
AGGRESSIVE MODE
_________________________________________________________
| Initiateur | Repondeur |
|--------------------------------------------------------|
| HDR, SA, KE |=============> |
| NONCE, IDii |
| <=============| HDR, SA, KE, NONCE|
| IDir, HASH |
| HDR*, HASH |=============> |
|________________________________________________________|
Fig. I.11 Echanges de Phase 1 en Aggressive Mode
- 30 -
CHAPITRE I. LES PROTOCOLES IPSEC
Chirement Hash PFS Lifetime IPSec Mode
AES SHA-1 Desactive 3600 sec Tunnel
DES MD5 Group 1 2h Transport
3DES Group 2 1 week
Blowsh Group 5
Fig. I.12 Quelques exemples de param`etres negocies lors dune Phase 2
I.4.2 Phase2 : IPSEC SA
Apr`es la Phase 1, durant la Phase 2, les IPSEC SAs sont negociees par IKE, pour securiser le ux
de donnees en lui meme. Ces negociations sont dej` a chires et authenties puisquelles reposent sur
la ISAKMP SA frachement etablie. On appelle egalement ce mode de negociation le Quick Mode.
Comme les IPSEC SA sont uni-directionnelles par nature, il va en suivre un double echange
de cles de chirement, lune pour le trac entrant et lautre pour le trac sortant. Lavantage que
represente cette strategie est de doubler le travail de lattaquant `a lecoute du reseau, puisquil lui
faudra dechirer le trac dans les deux sens.
Durant cette Phase sont negocies des param`etres comme les algorithmes de chirement, de
calcul de signature, les cles de chirement ou encore les durees de vies des dierentes SAs (cf Tab.
I.12).
Perfect Forward Secrecy
Le PFS - Perfect Forward Secrecy determine la mani`ere dont sont generees les cles de
chirement des dierentes IPSEC SAs. Lorsquil est desactive, les cles de(s) IPSEC SA(s) sont
generees `a partir de la cle principale de la ISAKMP SA correspondante. Lorsque lon lactive, ces
cles ne sont plus dependantes de la cle principale, mais au contraire generees `a partir dun nouvel
echange Die Hellman `a chaque nouvelle IPSEC SA negociee. La taille du Group PFS peut etre
de :
1 avec une longueur de cle de 768 bits,
2 avec une longueur de cle de 1024 bits,
5 avec une longueur de cle de 1536 bits.
Lactivation du PFS permet daccrottre la securite des SAs et donc des echanges en four-
nissant une entropie plus importante et donc une plus grande robustesse face aux attaques cryp-
tographiques liees `a ce type de generation de cles.
Il faut tout de meme porter attention au fait que les echanges Die Hellman sont bases sur des
exponentiations de taille non negligeable et sont de ce fait gourmands en ressources CPU. Il nest
- 31 -
I.5. R

ESUM

E
pas impossible de constater une perte de performances par lactivation dun group PFS trop grand.
I.5 R

esum

e
IPSec constitue une suite de protocole de securisation du trac au niveau IP. Il repose sur deux
protocoles : AH - Authentication Header et ESP - Encapsulating Security Payload. Les param`etres
necessaires `a lutilisation de ces mecanismes (cles, algorithmes, duree de vie) sont stockee dans des
SAs. Une base de donnee de SAs est maintenue dans le noyau et geree `a gr ace au protocole IKE
implemente dans dierents demons, comme racoon utilise ici.
Lorsquun ux arrive au niveau IP, une base de donnees de politiques de securite - SPD est
consultee an de savoir le type de securite `a fournir au ux.
Le noyau recherche alors la SA correspondante, chire le paquet et lenvoie. Si la SA nexiste pas,
une demande creation est envoyee au demon IKE qui se charge de la negocier aupr`es de lh ote
distant.
Plusieurs modications, evolutions, extensions ont ete apportee `a dierentes parties des proto-
coles IPSec depuis une dizaine dannee. Certaines ont ete normalisees par lIETF (bien quil faille
toujours supporter les drafts non RFC) et dautres non. Les extensions IPSec les plus signica-
tives se concentrent dune part sur lauthentication des tiers communiquants et dautre part sur
la transmission dinformations internes `a des hotes mobiles, de mani`ere securisee.
- 32 -
CHAPITRE II
Extensions IPSec et problematiques de securite
First they ignore you,
Then they laugh at you,
Then they ght you,
Then you win.
Mahatma Gandhi
Resume :
Les extensions IPSec sont des modications apportees au fur et `a mesure an dameliorer
non pas les protocoles en eux memes, mais plutot un certain manque de communication et/ou
dauthentication des deux hotes. Un des objectifs principaux du stage etant letude de ces
extensions, nous en approfondirons trois dont lune est destinee `a etre integree dans la pile
IPSec du rmware NETASQ.
XAuth : Extension principalement destinee aux clients mobiles, il permet davoir une
authentication forte du c ote du client. On authentie non seulement la machine, mais
egalement lutilisateur.
Hybrid : Lorsque le mode hybrid est active, lauthentication des correspondants peut
etre asymetrique, cest `a dire utilisant des methodes dauthentication dierentes des deux
cotes. Une passerelle IPSec pourrait sauthentier par certicats tandis quun client mobile
en face par cle pre-partagee.
Mode-Cong : Est une extension permettant de transmettre de mani`ere securiee et `a
la volee certaines informations relatives `a larchitecture interne des reseaux aux clients
mobiles en particulier. Lorsquun client mobile se connecte au reseau interne de son entreprise
par un tunnel IPSec, `a moins de les embarquer statiquement sur sa machine, il faudrait,
par exemple, lui envoyer une adresse IP locale
1
, ou encore des serveurs DNS et/ou WINS
internes. Cette extension est destinee `a etre integree dans le module IPSec NETASQ.
Dautre part, si IPSec englobe une suite de protocoles tr`es robustes theoriquement,
nous verrons quelle presente quelques problematiques voire failles de securite lorsquelle
est deployee de mani`ere inapropriee, ou conguree de mani`ere bancale ; comme les SAs sta-
tiques, ou encore une mauvaise de gestion (pas de gestion du tout) de CRLs, lutilisation
de cle pre-partagee en mode aggressif, etc.
II.1. AUTHENTIFICATION XAUTH
Ce chapitre presentant les extensions IPSec principalement dans le cadre des road warriors,
on appellera Client un client mobile, ne disposant pas dune adresse IP xe connue `a lavance ;
et Passerelle le serveur ou la passerelle IPSec sur laquelle le client mobile souhaite etablir une
connexion. Ladresse IP de la passerelle est xe et connue `a lavance du client.
II.1 Authentification XAuth
XAuth (Extended Authentication in IKE) permet davoir un mecanisme supplementaire an
dauthentier le client, apr`es letablissement dune ISAKMP-SA. Dans le cas ou XAuth est utilise
comme methode dauthentication du client, il est important que la passerelle ne fasse absolument
rien avant que XAuth nait correctement abouti. Ce point sera rappele `a la section II.1, lors de la
description dXAuth.
II.1.1 Principe et fonctionnement
XAuth est une methode extension IKE decrite dans le draft-beaulieu-ike-xauth-02.. Elle
permet davoir un complement dauthentication apr`es letablissement dune ISAKMP-SA.
Il sagit dune extension permettant dauthentier le client par diverses methodes (Radius,
OTP, Kerberos, LDAP, SecurID, etc). Pour signaler lutilisation dXAuth, celui ci dispose dun
Vendor ID envoye `a la passerelle lors de la negociation de phase 1. Il sagit des 8 octets suivant :
VendorID = 0x09002689DFD6B712
Les types de messages utilises pour XAuth sont les memes que ceux utilises lors dun Mode Config
(cf. section II.3), `a savoir ISAKMP-CFG-REQUEST, ISAKMP-CFG-REPLY, ISAKMP-CFG-SET, ISAKMP-CFG-ACK.
Seuls les attributs des messages changent. Ces messages sont dits de type Transaction Exchange,
donc des messages envoyes `a titre dinformations, et proteges par les param`etres de negociation de
la ISAKMP-SA.
Nous reviendrons plus en details sur ce type dechanges lors de la description du mode config et
du developpement de celui ci. Le tableau II.1 nous montre les principaux attributs dont dispose
la methode XAuth an dauthentier le client.
Un echange de type XAuth peut etre initie par le client ou par la passerelle. Les messages
echanges seront ainsi de type REQUEST/REPLY ou SET/ACK. Lauthentication peut se faire par un
simple jeu de login/password ou etre basee sur plusieurs facteurs comme un Challenge/Password
pour cacher le mot de passe, ou encore une authentication demandant un Challenge apr`es lin-
sertion dune cle USB ou autre.
II.1.2 Notications de type XAuth
Lors de letablissement de la ISAKMP-SA, la passerelle doit etre notiee de lXAuth, sinon elle
pourrait envoyer au client des paquets Mode Config ou des paquets de Phase 2 Quick Mode. Ceci
- 34 -
CHAPITRE II. EXTENSIONS IPSEC ET PROBL

EMATIQUES DE S

ECURIT

E
XAUTH-TYPE type dechanges denis dans Transaction exchanges.
XAUTH-USER-NAME login, nom dans un X.509, un DN, un email, etc.
XAUTH-PASSCODE token passcode
XAUTH-PASSWORD le mot de passe de lutilisateur.
XAUTH-MESSAGE un message ascii en clair, un challenge par exemple.
XAUTH-CHALLENGE challenge au format texte.
XAUTH-DOMAIN domaine dans lequel lutilisateur doit sauthentier.
XAUTH-STATUS OK=1, FAIL=0, statut de lauthentication.
XAUTH-NEXT-PIN
XAUTH-ANSWER
Fig. II.1 Principaux attributs lors dun echange XAuth
peut se faire de deux mani`eres dierentes :
Notication lors dun echange de phase 1 Le client peut indiquer quun XAuth va suivre en
mettant une notication dans le payload de nimporte quel paquet de phase 1. A moins que
les deux entites supportent les mecanismes de calcul dempreinte decrits dans le
draft-ietf-IPSec-ike-hash-revised-03.txt, ce payload nest pas authentie et ne doit
par consequent pas etre utilise.
Notication via les attributs de la ISAKMP-SA Lutilisation de XAuth est notiee en don-
nant la methode dauthentication choisie dans les attributs de la ISAKMP-SA negociee
lors du premier echange (section proposal dans la section remote de racoon). Lorsque la
passerelle re coit une demande de XAuth dans les attributs de la ISAKMP-SA, aucun echange
`a part XAuth nest possible apr`es une phase 1 correctement negociee.
A choisir une implementation plutot quune autre, en plus des contraintes de comptatibilite, il
serait plus raisonnable de transmettre la notication de XAuth en tant quattribut specique dans
le payload de la ISAKMP-SA en cours de negociation. Dans le cas general, un echange XAuth est
le plus souvent initie par le client, la passerelle se contentant de repondre aux requetes.
II.1.3 Securite de XAuth
XAuth et ISAKMP-SA
Le niveau de securite de XAuth est directement lie `a celui de la ISAKMP-SA
etablie.
La securite de XAuth repose enti`erement sur la ISAKMP-SA, et ore une authentication
complementaire du client uniquement sous reserve que la ISAKMP-SA ait ete negociee de mani`ere
- 35 -
II.1. AUTHENTIFICATION XAUTH
s ure : un XAuth apr`es une phase 1 etablie en Aggressive Mode Pre-Shared-Key a un niveau de
securite assez faible. Ce point est developpe dans la section suivante presentant lauthentication
en Group Password. Un XAuth, meme sil est fait avec des methodes dauthentication
fortes `a plusieurs facteurs, presente des faiblesses sil est fait sur la base dune ISAKMP-SA
ayant un faible niveau de securite.
Ainsi lauthentication du client, meme si elle est, certes, faite au niveau de XAuth, est basee
sur la robustesse de la phase 1 associee : il ne faudrait en aucun cas precipiter letablissement dune
ISAKMP-SA, sous pretexte que lauthentication du client se fera de toute fa con au moment de
lechange XAuth qui sen suit.
XAuth et . . .uniquement XAuth
Lorsque lauthentication de lutilisateur inclut un echange XAuth, on doit considerer que la
phase 1 nest pas compl`etement nie (et donc que la ISAKMP-SA nest pas encore etablie entre les
deux hotes) tant que XAuth nest pas termine et valide. Une fois que lutilisateur sest correctement
authentie echanges XAuth termines et valides , la ISAKMP-SA peut etre consideree comme
operationnelle et lon peut alors commencer des echanges, par exemple, de type Mode Config ou
des negociations Quick Mode en phase 2.
Dautre part, avant que lechange XAuth ne soit termine, lutilisateur nest pas encore compl`etement
authentie sur la passerelle. A ce titre, aucun echange ne doit survenir entre les deux hotes tant
que XAuth na pas abouti (cest `a dire termine et valide). Toute tentative de negociation de type
Mode Config ou de negociation de phase 2, entre autres, sont donc obligatoirement rejettees.
Dans le cas o` u XAuth se termine mais que lauthentication echoue pour une raison ou pour une
autre, aucune information naura ainsi ete transmise. Le dialogue sarrete alors immediatement,
et la ISAKMP-SA correspondante est supprimee
2
. En eet, si le Xauth nest pas valide (i.e que
lauthentication echoue), lutilisateur nest toujours pas authentie aupr`es de la passerelle ! Dans
ce cas, il nest pas pertinent davoir une ISAKMP-SA avec ce client : elle doit donc etre supprimee.
XAuth et transmission dinformations sensibles
Puisquun echange Auth fait intervenir le client et la passerelle dun cote, et la passerelle et
le serveur dauthentication de lautre, il faut etre en mesure de matriser les deux parties, alors
que jusquici, nous nous sommes uniquement interesses au cote public entre le client et la passerelle.
La transmission des informations relatives `a lauthentication des utilisateurs doit se faire de
mani`ere securisee entre le client et la passerelle, mais egalement entre la passerelle et le
serveur qui authentie !
Lechange de mots de passe ne se fait pas en clair entre le client et la passerelle IPSec, et
lorsque lechange se fait de mani`ere chiree, le recepteur est prealablement authentie, en utilisant
2
le draft preconise sa suppression
- 36 -
CHAPITRE II. EXTENSIONS IPSEC ET PROBL

EMATIQUES DE S

ECURIT

E
un Mode Hybrid par exemple, qui est developpe `a la section II.2.
Dautre part, le transit dinformations entre le serveur qui authentie et la passerelle IPSec
est egalement sensible, y compris sur un reseau local interne. Si les equipements dauthentication
sont physiquement isoles du reseau interne et directement relies `a la passerelle, les mots de passe
(ou des empreintes de mots de passe, etc) ne circulent pas exactement de la meme mani`ere que si
les serveurs sont branches sur un HUB relie `a plusieurs centaines de stations de travail, o` u tout le
monde poss`ede un acc`es potentiel aux donnees en les sniant sur le reseau.
II.1.4 XAuth et le Group Password
La negociation dune phase 1 en Aggressive Mode Pre-Shared-Key presente un faible niveau de
securite, meme lorsquun XAuth sen suit.
Lorsque quune seule Pre-Shared-Key est utilise an dauthentier plusieurs utilisateurs ( !)
(methode connue egalement comme Goup Password, un mot de passe de "groupe"), il nest plus
possible de garantir la securite des identiants des utilisateurs legitimes sy connectant, en partic-
ulier les road warriors, bien que ce type dauthentication soit la methode par defaut de quelques
clients VPN/IPSec.
La strategie adoptee par NETASQ a ete de ne pas proposer ce type dauthentication : les clients
mobiles auront un certicat X509 ou une cle RSA.
Pourquoi ce type dauthentication est-il si peu s ur ?
Comme nous lavons vu, lors de la negociation dune phase 1 en Main Mode, les dierents
idientiants sont proteges (Identity Protection Mode), quil sagisse dune authentication par
Pre Shared Key ou par certicats X.509. Puisque lempreinte dauthentication est chiree, sa
provenance est determinee uniquement par lIP de lemetteur. Or, les road warrios nont, par
denition, pas dadresse IP xe.
En Aggressive Mode combine avec une authentication en Pre-Shared-Key, meme lorsque la
cle est uniquement partagee deux entites, rien nempeche un potentiel attaquant ecoutant le trac
reseau dintercepter lempreinte et den deduire la cle si jamais celle ci se revelait faible.
Une authentication en Pre-Shared-Key en Aggressive Mode, lorsquelle est destinee aux
road warriors, est encore plus vulnerable puisque la passerelle IPSec et lensemble des road war-
riors poss`edent la meme Pre-Shared-Key ! Lorsque la negociation se met en place, la passerelle
sait, dans le meilleur des cas, quelle parle `a lun des road warriors, elle na aucun moyen de savoir
precisement lequel. Certes, XAuth intervient apr`es letablissement de la phase 1, pour authentier
le client.
Comme nous lavons vu precedemment, lauthentication du client, meme si elle se pas fait au
niveau de XAuth, repose sur la robustesse de la ISAKMP-SA associee. Si celle ci a ete etablie sur
la base dune Pre-Shared-Key, une authentication supplementaire gr ace au XAuth ny apporte
- 37 -
II.2. HYBRID-AUTH
pas un niveau de securite supplementaire puisque le niveau de securite de lensemble dune chane
equivaut `a celui de son maillon le plus faible !
Il serait, dans ce cas, envisageable dattribuer une cle dediee `a chaque utilisateur. Cette ap-
proche poss`ede un inconvenient majeur : il nest pas possible, `a la reception du paquet, de savoir
quelle cle utiliser pour valider lempreinte, puisquaucun nom dutilisateur nest transmis et que
ladresse IP du client est dynamique. Pour utiliser lauthentication en cle pre-partagee, il devient
alors impossible de ne pas utiliser une cle de groupe.
Dautre part, on peut egalement envisager que le client soit legitime et quil negocie avec une
passerelle frauduleuse. Un road warrior na aucun moyen de savoir quil dialogue bien avec la
passerelle : un potentiel attaquant pourrait dej` a posseder la cle, et il pourrait `a son tour negocier
avec la vraie passerelle, et ainsi, ecouter, intercepter, modier, etc lensemble du trac...Combine
avec Mode Config, ceci peut permettre `a un attaquant de connatre lensemble de larchitecture
reseau interne, dusurper des donnees, etc. La solution serait donc de transmettre un username lors
de la negociation...et ceci peut se faire en utilisant des certicats. Si le client en arrive `a etre vic-
time dune telle attaque MITM pendant un XAuth, celui ci dispose alors, non seulement dun moyen
decouter le trac, mais egalement de pouvoir negocier autant de sessions IKE quil le desire, et
pour peu que le mot de passe de lutilisateur soit le meme `a dierents endroits, lattaquant peut
lire les mails de lutilisateur, sauthentier aupr`es de dierents serveurs internes, acceder `a des
informations condentielles sur diverses base de donees, etc.
Lors dune negociation de phase 1, on authentie alors la passerelle dans un premier temps : le
client doit etre certain quil dialogue bien avec la passerelle legitime.
II.2 Hybrid-Auth
Hybrid Auth est une autre extension IKE decrite dans le draft-zegman-ike-hybrid-auth-01..
Elle permet de realiser une authentication asymetrique entre les dierentes entites.
II.2.1 Presentation generale
Les methodes (( classiques ))dauthentication IKE reposent sur le fait que celle-ci soit mutuelle,
chacune des entites sauthentie vis ` a vis de lautre en utilisant la meme methode dauthentication.
Lauthentication en Hybrid Auth fournit une asymetrie dans la mani`ere dont la passerelle
et le client sauthentient : la passerelle utilise des methodes de cryptographie asymetrique (cles
publiques, cles privees) alors que le client (typiquement un road warrior) va utiliser une authenti-
cation de type Challenge/Reponse. Il est tout `a fait possible de faire linverse egalement. Ainsi,` a
la n dune negociation aboutie de phase 1 utilisant le Mode Hybrid, la passerelle sest unidirec-
tionnelement authentiee aupr`es du client. Il nen est rien quant `a lauthentication du client.
Pour completer lauthentication, XAuth (cf. II.1) pourra etre utilise.
Apr`es un echange Hybrid Auth, on se retrouve donc dans la situation suivante :
Le client mobile sait `a present quil dialogue bien `a la bonne passerelle.
- 38 -
CHAPITRE II. EXTENSIONS IPSEC ET PROBL

EMATIQUES DE S

ECURIT

E
Les echanges entre le client et la passerelle sont securises sur la base de la ISAKMP-SA
etablie.
La passerelle ne connait pas encore lidentite du client mobile. Une authentication du client
est necessaire.
II.2.2 Fonctionnement
Le Mode Hybrid intervient lors des echanges de negociation de phase 1 : une methode dau-
thentication Hybrid est proposee dans les attributs de la ISAKMP-SA. Les valeurs peuvent etre
les suivantes :
HybridInitRSA
HybridInitDSA
HybridRespRSA
HybridRespDSA
Lorsquun client initie la negociation, il choisit les attributs HybridInit* tandis que lors de
linitiation par la passerelle, il sagit de HybridResp*.
Ainsi, lorsque la negociation se fait en Main Mode initie par le client, le paquet 6 de la negociation
envoye par la passerelle est de la forme :
HDR*, IDir, [ CERT, ] SIG_R
o` u [ CERT, ] SIG_R permettent dauthentier celle-ci.
En Aggressive Mode initie par la passerelle, le paquet 3 envoye par la passerelle sera de la
forme :
HDR, [ CERT, ] SIG_I
II.2.3 Authentication forte et compl`ete
Hybrid Mode authentie la passerelle aupr`es du client. Pour que le client le soit egalement, on
peut forcer lutilisation de XAuth juste apr`es letablissement de la ISAKMP-SA. Cest dailleurs ce
que preconise le draft, et cest la mani`ere avec laquelle NETASQ authentiera les road warriors.
Ainsi, lutilisation du mode Hybrid est suivi, dans tous les cas, par un echange XAuth.
Aucune information complementaire, y compris en Mode Cong ne doit etre envoyee et/ou ac-
ceptee. Lorsque XAuth est termine et valide, les deux entites se sont authenties mutuellement.
Peuvent alors commencer des echanges en Mode Config, ou des negociations de phase 2, etc.
Que lechange XAuth soit precede dun echange Hybrid Auth ou pas, en cas dechec dauthenti-
cation `a lissue du XAuth, la ISAKMP-SA frachement etablie est supprimee.
Une fois que les hotes sont authenties, dans le cas dun road warrior, `a moins quil nait
embarque lensemble des param`etres reseaux statiquement sur la machine, il faut les lui transmettre
`a present. Le Mode Configuration se charge de cette t ache.
- 39 -
II.3. MODE CONFIGURATION
II.3 Mode Configuration
II.3.1 Presentation Generale
Lextension Mode Cong est decrite dans le draft-dukes-ike-mode-cgf-02.. Elle permet
de transmettre `a une machine hote distante, typiquement un road warrior, certains param`etres
reseaux, notamment ses extremites distantes de trac. Ces param`etres sont transmis de telle sorte
que le client distant se comporte comme sil etait sur un LAN du reseau interne, `a ceci pr`es que la
connexion se fera par un tunnel IPSec.
Cette transmission est protegee par la ISAKMP-SA, et intervient par consequent apr`es la negociation
aboutie dune Phase 1, et imperativment avant toute tentative de negociation de Phase 2 puisque
celle ci necessite lensemble des param`etres transmit lors du Mode Cong.
Lorsque que le Mode Cong est utilise seul, cest `a dire sans XAuth ou Hybrid Auth, les
negociations sont de la forme :
(*) Phase 1 Main Mode ou Phase 1 Aggressive Mode
(**) Mode Config - Transaction Exchanges
(***) Phase 2 - Quick Mode
pour la negociation initiale, et :
(*) Mode Config - Transaction Exchanges
(**) Phase 2 - Quick Mode
pour les renouvellements de IPSec-SAs.
II.3.2 Fonctionnement
Les attributs disponibles peuvent etre de nature diverse : il peut sagir de transmettre toute une
conguration reseau `a un road warrior comme une adresse locale, un masque de sous reseau, un
serveur DNS/WINS, etc ; ou il peut juste sagir de transmettre ladresse dun serveur DNS interne
pour quil puissse resoudre les noms internes.
Types de messages disponibles :
ISAKMP CFG REQUEST
ISAKMP CFG REPLY
ISAKMP CFG SET
- 40 -
CHAPITRE II. EXTENSIONS IPSEC ET PROBL

EMATIQUES DE S

ECURIT

E
ISAKMP CFG ACK
Les paquets Transaction Exchanges sont bases sur un echange mutuel initie soit par la
passerelle soit par le road warrior.
Dans le cas o` u la passerelle souhaite transmettre les param`etres de son propre chef, il sagit dun
couple dechange SET - ACK dans lequel la passerelle propose un certain nombre de param`etres
(DNS, WINS, etc) et o` u le client envoie juste un accuse de reception.
Dans le cas o` u le client demande ces informations `a la passerelle, il sagit dun couple REQUEST - REPLY
o` u le client demande une conguration reseau formee de certains attributs et o` u la passerelle repond
avec les memes attributs correctement denis, suivant sa conguration.
Il existe dej` a quelques implementations permettant aux clients mobiles de se connecter sur les
passerelles IPSec en ayant leur conguration reseau statique embarquee sur leur machine. Pour
des raisons de compatibilites, il est necessaire que lajout dune implementation Mode Config soit
interoperable avec les implementations actuelles : un client mobile supportant le Mode Config est
cense pouvoir se connecter meme sil refuse les param`etres qui lui ont ete transmis en Mode Config
quil negocie avec des param`etres statiques, sous reserve que ceux ci soient valides.
II.3.3 Param`etres disponibles
Le demon racoon du projet ipsec-tools propose un ensemble de param`etres pouvant etre
transmis en Mode Config, en etant le plus conforme possible vis `a vis du draft.
Authentication : lors dun echange XAuth, permet de denir lequipement dauthentication `a
utiliser : PAM, Kerberos, Radius...
Adresse IP : transmission dune adresse IP locale (RFC 1918) au client mobile sur son interface
IPSec.
Masque de sous reseau : transmission du masque.
DNS, WINS : transmission dadresse ou liste dadresse de serveurs DNS/WINS.
Banni`ere : banni`ere personalisee lors de la connexion du client mobile.
II.3.4 Pool et penurie dadresses IP
En Mode Config, le client peut se voir attribuer notamment une adresse IP locale. Cette attri-
bution peut etre geree directement dans les chiers de conguration de racoon ou alors `a un niveau
superieur dans les ches des utilisateurs dune base LDAP, par exemple. Il serait ainsi possible dim-
poser une adresse IP locale `a un utilisateur, pour quil ne puisse par exemple pas negocier une autre
adresse IP que celle quon lui a attribue lors dune phase 2. Dans le cas o` u la gestion des IPs est
faite par LDAP, il faut au prealable sassurer quil ny ait pas de collisions lors de lattribution : une
IP attribuee `a un client est peut etre dej` a utilisee, ou plusieurs pools dIPs se chevauchent peut etre.
Dautre part, lorsquun pool dadresses IP a ete deni, lorsque lensemble des adresses ont ete
attribuees `a des road warriors, il faudrait pouvoir remonter un message de mani`ere la plus stan-
dardisee possible `a ladministrateur et au road warrior essayant de se connecter. Dans la version
- 41 -
II.4. INTERACTIONS XAUTH, HYBRID ET MODE CONFIG
actuelle dipsec-tools (0.7.1), racoon ne peut encore le faire.
On peut egalement avoir le cas o` u certaines adresses sont dej` a reservees, alors que les road warrios
correspondants ne sont pas en train de les utiliser. Il faudrait ainsi trouver le meilleur compromis
possible en terme de performances.
II.4 Interactions XAuth, Hybrid et Mode Config
Bien que les trois extensions soient independantes, dans le cadre dune conguration robuste
il est preferable de verouiller certaines interactions quant `a lutilisation de lune ou lautre de ces
methodes.
Mode Cong : Independant, peut etre utilise avec/sans XAuth ou Hybrid mais
uniquement apr`es que le client se soit correctement authentie, cest `a dire apr`es
une phase 1 forte, ou apr`es une phase 1 suivi dun XAuth.
XAuth : Independant
Hybrid : le mode Hybrid devrait etre suivi dun XAuth an de completer lauthentication.
Ainsi, dans le cas ideal, letablissement dun tunnel IPSec entre une passerelle et un road warrior
devrait se faire comme suit :
1. Initiation de la negociation de phase 1 par le client, authentication par Certificats ou par
Hybrid Mode.
2. Transaction Exchange XAUTH pour authentier le client.
3. Transaction Exchange ModeConfig pour lui transmettre ses param`etres reseaux.
4. Quick(s) Mode(s).
II.5 Faiblesses dIPSec
Le doigt a dej` a ete mis sur quelques unes des faiblesses des protocoles IPSec, comme lutilisation
de lauthentication en cle pre-partagee lorsque lon negocie en aggressif, ou encore lutilisation
de SAs statiques rendant les attaques par force brute plus probables. Il ne sagit neanmoins pas des
seules. Le but netant pas de faire une liste exhaustive de lensemble des failles connues, quelques
pistes sont plus approfondies an davoir les congurations les plus robustes et securisees possibles.
II.5.1 Failles cryptographiques intrins`eques
La securite des protocoles IPSec est basee sur limplementation des briques cryptographiques
sur lesquelles ils reposent dune part, et sur les reseaux IP et leur fonctionnement dautre part.
Lorsque les cles de sessions de renouvellement de Phase 2 sont par defaut derivees `a partir
de donnees de Phase 1 par defaut. Elles ne sont donc pas independantes. Une attaque par force
brute aboutie sur une cle de session uniquement donnerait des informations non negligeables sur
la cle suivante, voire permettrait de la deduire. Le PFS - Perfect Forward Secrecy - permet
- 42 -
CHAPITRE II. EXTENSIONS IPSEC ET PROBL

EMATIQUES DE S

ECURIT

E
de remedier `a ce probl`eme : les cles de sessions sont calculees uniquement sur la base dun echange
Die-Hellman et non plus sur la base dinformations dej` a connues. Elles sont ainsi independantes
les unes des autres.
On peut egalement citer les attaques par bit ipping des protocoles de chirement en CBC -
Cypher Bloc Chaining. Il sagit dinverser des bits dans un paquet ESP sans avoir `a le dechirer
puis le reemettre en esperant que cela gen`ere une erreur ICMP qui, elle, sera envoyee en clair.
II.5.2 Probl`emes dimplementation
Quil sagisse de congurations par defaut, de congurations trop complexes ou meme de failles
dans le traitement des paquets dans la pile IPSec, les probl`emes dimplementations existent et sont
corriges le plus rapidement possible.
Certaines implementations proposent des param`etres, par defaut, faibles lors de la negociation
de Phase 1 et 2. Ces param`etres, si ils sont combines consitiuent une faille non negligeable. La
verication de proposition par defaut de racoon est en mode strict. Or, pr`es de 9 congura-
tions sur 10 ont un mode de negociation en obey qui accepte la premi`ere proposition de lh ote.
Les deux hotes se retrouveront alors `a chirer en DES alors que tout deux supportent AES. De
plus, parmi les algorithmes de chirement par defaut, on retrouve toujours DES qui sest pourtant
essoue depuis les annees 2000. Le PFS desactive par defaut ne viendra que renforcer linsecurite
de lensemble.
Certains bugs dimplementation permettent egalement `a certains paquets qui ne sont pas censes
emprunter le tunnel detre tout de meme chire en passant `a travers les politiques de securite. Lin-
verse est plus dangeureux, lorsquun paquet cense etre chire sort en clair sur le reseau.
On peut egalement citer tous les probl`emes lies `a la validation des certicats, aux CRLs non
mises `a jour, ou meme `a labsence de confrontation dun certicat `a une CRL. Un utilisateur
revoque, ayant un certicat qui nest plus valide, pourra tout de meme monter un tunnel IPSec
vers sa passerelle.
II.5.3 Deploiements reels
Lensemble des faiblesses citees plus haut provoquent egalement des congurations bancales
lors de leur deploiement eectif.
Certaines congurations ne correspondent pas du tout aux attentes de securite des adminis-
trateurs, d u le plus souvent `a une mauvaise comprehension des protocoles. A titre dexemple, le
mot cle require dans racoon est utilise dans linjection de politiques de securite par setkey.
Lorsque lon desire etablir plusieurs Phase 2 avec un meme correspondant, require ne permet
pas de distinguer une SA specique avec laquelle il faudrait chirer tel ou tel trac. Il en resulte
que nimporte quel SA peut etre utilisee pour chirer nimporte quel type de trac avec cet hote
donne : il nest pas du tout garanti que le trac que lon desirait proteger de telle mani`ere le sera
- 43 -
II.5. FAIBLESSES DIPSEC
eectivement ! Dans le pire des cas, on peut en arriver `a chirer les donnees les plus importantes
avec les congurations les plus faibles !
Dautre part, nombre dadministrateurs sont persuades que les politiques de ltrage ne sont
pas necessaires lors de la mise en place de tunnels IPSec. Les ux passant `a travers ces tunnels ne
sont donc pas surveilles. Une politique de ltrage est absolument necessaire `a la sortie du tunnel
IPSec lorsque le paquet est dechire et quil passe dans le reseau local (( classique )).
Enn, on peut rajouter la mauvaise protection des secrets ou des certicats. Lorsque les cle-
partagee sont faibles ou connues par beaucoup trop de personnes, on ne peut garantir une authen-
tication forte. Il en est de meme pour les certicats, o` u les CRLs ne sont pas mises `a jour assez
reguli`erement...
- 44 -
CHAPITRE III
Les UTMs NETASQ
Live as if you were to die tomorrow.
Learn as if you were to live forever.
Mahatma Gandhi
Resume :
NETASQ developpe aujourdhui une gamme compl`ete de solutions rewalls, VPNs et
AntiSpam pour des entreprises de toute taille.
on presentera ici une description avancee des fonctionalites des rewalls NETASQ.
- Une presentation compl`ete de lancienne et de la nouvelle gamme des UTMs.
- LASQ
TM
: Active Security Qualication, technologie proprietaire de prevention
dintrusion analysant le trac sur lensemble des couches reseaux. LASQ equipe lensemble
de la gamme des solutions.
- Ladministration des rewalls : la suite logicielle graphique dont le Manager et le
Monitor permettant de suivre lensemble de lactivite reseau et de prendre les mesures
necessaires en cas de probl`emes.
- Les fonctionalites avancees des rewalls, comme la HA, le portail dauthentication
ou encore le mode hybrid
1
des interfaces reseaux ; an de securiser des architectures reseaux
complexes et eclatees sur plusieurs sites geographiques.
Linteraction entre les dierents modules, en particulier avec le module IPSec facilite la
prise en main, et ainsi lintegration du Mode Cong.
III.1. PR

ESENTATION DES UTMS


III.1 Pr

esentation des UTMs


III.1.1 Quest ce que lUTM?
Les solutions de securite NETASQ sont toutes basees sur le concept dUTM - Unied Threat
Managment. On ne parle alors plus tellement de rewall, ou dIPS (Intrusion Prevention System)
ou encore dIDS (Intrusion Detection System).
Les UTMs int`egrent, en standard, lensemble des fonctionalites de securite essentielles repondant
aux besoins de des dierentes entreprises. Lavantage sur des architectures de securite basees sur
des produits multiples est triple :
Le prix des infrastructures : Lorsque lon soriente vers de multiples produits, laddition aug-
mente assez rapidement, non seulement en termes de produits en eux memes, mais egalement
en termes de maintenance et demises `a jour. Ainsi, une solution UTM sera moins ch`ere
quun ensemble de solutions de Firewall, dAntivirus, dAntispyware, de Detection dIntru-
sion, dAntispam, etc.
Ladministration et la maintenance : Il est toujours plus simple et ecace dadministrer une
seule solution UTM plutot que de gerer un ensemble de produits. Cela evite davoir recours
`a des methodes dinstallation et de deploiement multiples, des supervisions multiples et une
plus grande diculte `a securiser lensemble de linfrastructure reseau. Il en resulte parfois
des possibilites de trous de securite multiples.
Lattente du marche : Ainsi, lorsquune entreprise securise son informatique interne, elle sat-
tend `a ce que les produits soient unies, que les formations soient courtes, linstallation rapide
et surtout un verrouillage de la securite qui soit central.
Ainsi, les UTMs NETASQ embarquent dans toute leur gamme lensemble des modules disponibles :
IPS en temps reel : Il sagit de lASQ
TM
presente `a la section III.2.2.
Firewall : Non seulement rewall reseau, mais egalement applicatif.
PKI : Il est possible de creer une CA et des Certicats pour lensemble des utilisateurs, le tout
embarque sur lUTM.
Proxy et ltrage de contenu : Permettant une meilleure gestion des sites visites, en particulier
en verrouillant des navigateurs, comme Firefox uniquement.
VPN SSL et IPSec : Technologies de VPN tr`es repandue, SSL et surtout IPSec interconnectent
des sites geographiquement eloignes et permettent egalement aux clients nomales (des com-
merciaux terrains par exemple) dacceder au reseau interne de lentreprise.
- 46 -
CHAPITRE III. LES UTMS NETASQ
III.1.2 La premi`ere generation des UTMs NETASQ : Les series F
An de repondre aux attentes des petites entreprises, des UTMs dentree de gammes comme
le F25, F50 ou le F60 (cf. III.1). Ces mod`eles int`egrent un haut niveau de securite et peuvent
rapidement etre deploye sur les petites infrastructures sans en modier larchitecture.
F25
5 ports Ethernet 10/100
2000 sessions simultanees.
F50
3 ports Ethernet 10/100
5000 sessions simultanees.
F60
7 ports Ethernet 10/100
5000 sessions simultanees.
Fig. III.1 Gamme pour PME : F25, F50, F60
Ces mod`eles nont pas de disque dur integre, uniquement une memoire ash. Les logs sont alors
transferes sur un serveur externe, de meme pour le serveur LDAP qui doit etre externe.
La gamme superieure est la plus commercialisee et la plus repandue chez NETASQ. Elle corre-
spond aux moyennes entreprises, du F200 jusquau 1200 (cf. III.2). Les tests, le developpement,
lintegration et lensemble du stage a ete realisee sur un mod`ele F200, mod`ele NETASQ par excel-
lence. Cette gamme int`egre des disques durs avec lensemble des fonctionalites disponibles : PKI,
LDAP interne, presence des logs, partition de sauvegarde et restauration, etc.
Pour les tr`es grandes entreprises, deux produits NETASQ (cf. III.3) apportent des perfor-
mances Multi-Gigabits et un grand nombre dinterfaces, faisant alors une protection parfaite pour
des zones demilitarisees assez sensibles. Une securite optimale pour proteger entre autres les si`eges
- 47 -
III.1. PR

ESENTATION DES UTMS


F200
4 ports Ethernet 10/100
65000 sessions simultanees.
F500
4 ports Ethernet 10/100 et 2 ports Gigabits
200000 sessions simultanees.
F800
4-8 ports Ethernet 10/100/1000
400000 sessions simultanees.
F1200
10 ports Ethernet 10/100/1000
600000 sessions simultanees.
Fig. III.2 Moyenne et Grosse gamme : F200 au F1200
- 48 -
CHAPITRE III. LES UTMS NETASQ
sociaux.
F2500
6-24 ports Ethernet 10/100
800000 sessions simultanees.
F5500
24 ports Ethernet 10/100/1000
Disques durs Hot Swap en RAID
1500000 sessions simultanees.
Fig. III.3 Haute Gamme pour grands comptes : F2500 et F5500
Ces mod`eles arrivent aujourdhui en n de vie (cf. III.4) et ont recemment ete remplaces par
une nouvelle generation de tr`es hautes performances, et `a la pointe de la technologie comme par
exemple la precense de port en bre optique.
III.1.3 La nouvelle generation G2 : Les series U
Lancienne generation des UTMs etait plus reference comme des rewalls do` u le F. An de
rompre avec cette idee en mettant sur le marche une toute nouvelle generation dUTMs, do` u le U,
avec des performances inegalees jusqu`a aujourdhui.
De lU70 `a lU6000 (cf. III.5), de tr`es hautes performances (Interface Gigabits sur lensemble
de la gamme entre autres), une nouvelle version du rmware NETASQ (version 8.0, Codename DELOS)
devant etre presentee aux Assises de la Securite et des Syst`emes dInformations qui se tiendra `a
Monaco en octobre, cette nouvelle generation est largement en avance sur son temps.
- 49 -
III.1. PR

ESENTATION DES UTMS


Fig. III.4 Anciens UTMs G1
Fig. III.5 Nouveaux UTMs G2 - www.netasq.com
- 50 -
CHAPITRE III. LES UTMS NETASQ
III.2 LASQ - Active Security Qualification
III.2.1 Presentation
Le rewall classique bloquant les protocoles interdits par ladministrateur et ltrant le trac
commence `a etre depasse. Il sagit aujourdhui de pouvoir detecter et surtout de prevenir en temps
reel les comportements anormaux au sein meme du trac autorise. A titre dexemple, la majorite
des attaques se basent aujourdhui sur des protocoles applicatifs comme HTTP ou FTP.
LASQ - Active Security Qualication est une technologie de prevention dintrusion en
temps reel developpee par lequipe R&D d`es 1998 et integree dans les appliances. Il fournit une
prevention dintrusion basee sur le contexte en interceptant les paquets au niveau de la couche 2
OSI, en analysant le trac de la couche 3 OSI jusqu`a la couche 7 OSI applicative et en appliquant
de multiples methodes pour identier et bloquer tout trac malveillant.
LASQ utilise des familles dattaques lui garantissant une precision optimale an de proteger
le reseau contre les menaces tout en conservant des hautes performances et des gros debits. Les
rewalls realisent ainsi un traitement preventif en temps reel, tant au niveau de la couche reseau
quapplicative, sans diminuer les performances du syst`eme.
III.2.2 ASQ : Pile OSI Virtuelle
Lorsque lASQ re coit un paquet `a analyser, il neectue aucune decapsulation `a proprement
parler, on ne remonte pas la pile IP. Il eectue toutes ses analyses de securite au niveau noyau
sur un paquet mis en tampon (cf. III.6). Cele permet notamment daccrotre considerablement les
performances et les debits.
Ainsi, lorsque lensemble des analyses de securite sont realisees, le paquet est transmis `a linter-
face sortante. Le contexte du paquet est garde en memoire pour le traitement du paquet suivant. Le
paquet suivant sera alors analyse suivant le contexte sauvegarde. De fait, toute donnee malformee
ou malicieuse sera detruite.
III.2.3 Analyses de lASQ
Beaucoup plus loin que les simples classement depasses analyse niveau r eseau et analyse niveau applicatif,
lASQ prot`ege les ux suivant trois grandes categories danalyse.
LASQ est lie au ltrage et `a ce titre eectue toute une serie danalyses (cf. III.7) de la couche
3 jusqu`a la couche 7 avant de delivrer le paquet `a lapplication en attente ou de lenvoyer sur le
reseau.
- 51 -
III.2. LASQ - ACTIVE SECURITY QUALIFICATION
Fig. III.6 ASQ : Pile OSI virtuelle en 7 couches
Fig. III.7 Dierentes etapes danalyses de lASQ
- 52 -
CHAPITRE III. LES UTMS NETASQ
Lanalyse Protocolaire
Il sagit, comme son nom lindique, dune analyse des paquets par protocole. Les ux sont
analyses suivant leur protocole et tout trac malforme, non conforme au protocole associe (reseau
ou applicatif) est supprime.
Lanalyse protocolaire verie ainsi la conformite par rapport aux dierentes RFCs (Ethernet, IP,
TCP, UDP) des protocoles reseaux et transports.
Dautre part, une verication est faite par rapport aux RFCs des protocoles applicatifs comme
HTTP, SMTP ou encore FTP gr ave aux plugins applicatifs developpes dans la section suivante.
Ainsi, sont notamment evitees lensemble des attaques basees sur des options des protocoles mal
positionnes.
An de prevenir ladministrateur, le rewall peut lever une alarme, et il en existe aujourdhui pr`es
de 120 classes reparties sur pr`es de 11 categories.
Lanalyse des fragments
La seconde type danalyse eectuee par lASQ evite les attaques basees sur lexploitation du
sequencement des fragments.
Les verications ne sont plus eectuees sur le paquet isole en lui meme mais sur le datagramme
dans son environnement : la coherence entre les donnees des dierents paquets qui prec`edent et/ou
qui suivent est validee.
On conrme alors quaucun fragment ne se chevauche avec un autre, que le paquet initial est
bien reconstitue, quil ny a pas de debordement de taille, etc. Les fragments sont memorises dans
un buer et le paquet est renvoye uniquement sil est reconstitue sans erreur.
Lanalyse Globale
Lanalyse Globale sinteresse au contexte des connexions. Pour chaque connexion acceptee, ses
dierents elements caracteristiques comme les adresses IPs de source et de destination, le contexte
TCP, etc sont memorises. Il sagit de la technologie (( Stafeull Inspection ))permettant danalyser
les ux suivant leur contexte de connexion.
Dautre part, dans lASQ, la sauvegarde des etats de connexion est persistante au reboot, et
les connexions semi-ouvertes sont egalement reprises. Les numero de sequence TCP sont modies
avec un aleat fort et le SACK (Selective Acknowledgment Option)
2
est active. La persistance des
connexions au reboot permet notamment deviter lensemble des attaques DoS qui redemarrent
le rewall apr`es un debordement de pile reseau, et qui esp`erent pouvoir voler des sessions TCP `a
laide des numeros de sequence des retablissements de toutes les connexions coupees.
2
Le SACK permet de renvoyer un paquet particuler sans renvoye tous les paquets suivant le dernier ACK re cu.
- 53 -
III.2. LASQ - ACTIVE SECURITY QUALIFICATION
ASQ Dynamic Filtering
Le ltrage NETASQ est de type (( Statefull Inspection )). Le Statefull, contrairement au
Stateless, sauvegarde lensemble du contexte des dierentes connexions etablies et autorise au-
tomatiquement le ux entrant en relation avec un contexte dune connexion dej` a etablie. Linteret
est alors de verier le trac au niveau contexte de connexione et non plus au niveau paquet
uniquement. Le contenu des paquets est egalement analyse `a la volee sans decapsulation et sans
interruption de liaison, ce qui assure de meilleures performances.
NETASQ a egalement developpe un optimiseur devaluation de r`egles de ltrage : SKIP. SKIP
permet de regrouper un ensemble de r`egles ayant un ou plusieurs crit`eres en commun. Ainsi lors
de lapplication de r`egles de ltrage sur un ux, lensemble des r`egles ayant un crit`ere eliminatoire
en commun sont sautees et ne sont pas evaluees puisquelles retourneront forcement une reponse
negative (cf. III.8). Les performances en sont alors meilleures.
Num Action Protocole Iface Sce Destination Port
. . .
4 Pass TCP IN LAN3 Srv-ftp 21
5 Block ICMP OUT Any LAN2
6 Pass TCP OUT Any Srv-web 80
7 Block TCP OUT LAN1 Srv-smtp 25
8 Pass UDP IN LAN2 Srv-dns 53
. . .
Fig. III.8 Haute Gamme pour grands comptes : F2500 et F5500
On peut voir dans le tableau des r`egles de ltrage quun paquet qui provient du reseau interne
`a destination de lInternet sautera les r`egles 5, 6 et 7.
Lanalyse Applicative
Lanalyse applicative est basee sur une architecture `a plugin, permettant de lactiver ou de la
desactiver. Un plugin va sattacher ` a un certain type de protocole et de services an de verier la
conformite des protocoles applicatifs par rapport aux normes et dierentes RFCs, et den prevenir
les utilisations frauduleuses connues. En outre est eectuee une verication de coherence entre les
donnees transportees par le paquet et les en-tetes de celui-ci. Cela permet didentier des attaques
propres `a chaque type de protocole applicatif.
On peut remarquer que ce syst`eme danalyse pourra bloquer les attaques basees sur des signa-
tures qui ont ete intentionnellement modiees an de tromper les IDS classiques.
Tous ces types danalyses font de lASQ un puissant analyseur temps reel de trac, et nen
aectant pourtant pas les performances globales.
- 54 -
CHAPITRE III. LES UTMS NETASQ
III.3 Fonctionalit

es Avanc

ees
En plus de lASQ, coeur du rmware NETASQ, les appliances disposent de fonctionalites de
plus en plus riches comparees aux pare-feux traditionnels.
III.3.1 Authentication et PKI
A partir des mod`eles F200 (gamme G1), les appliances disposent toutes dun disque dur et
peuvent alors embarquer des annuaires utilisateurs et une mecanique compl`ete detablissement de
PKI. Il est toujours possible dauthentier sur une base externe lorsque les mod`eles nint`egrent pas
de disque dur.
Plusieurs methodes dauthentication sont alors disponibles :
None : les utilisateurs ne sauthentient pas.
LDAP : les utilisateurs sauthentient `a laide de leur mot de passe, dont une empreinte est
stockee dans un champ approprie de leur che LDAP. Lauthentication peut se faire sur
une interface web en HTTPS ou HTTP.
SSL : les utilisateurs sauthentient en presentant au rewall un certicat valide.
SRP : cette methode permet de ne transmettre ni le mot de passe, ni lempreinte du mot de passe `a
travers le reseau. Il sagit dune authentication `a base de challenge-response (Die-Hellman
en particulier).
SRP-LDAP : Methode dauthentication developpee par NETASQ. Le mot de passe LDAP de
lutilisateur est utilise pour generer une cle jetable SRP et permettre lauthentication en
SRP.
Kerberos : les utilisateurs sauthentient via un serveur Kerberos (AS et TGS).
RADIUS : les utilisateurs sauthentient au moyen dun serveur RADIUS externe. Les mecanismes
de transmission de lempreinte du mot de passe sont les meme que pour lauthentication
via LDAP.
NTLM : les utilisateurs sauthentient via un serveur NTLM, execuant Windows NT 4.0 ou une
version precedente.
Parmi ce large eventail de methodes disponibles, les plus utilisees par les clients sont lauthen-
tication par certicats et par LDAP, SRP-LDAP.
Methode SRP
SRP - Secure Remote Password Protocol permet dauthentier les utilisateurs sans divulguer
leur mot de passe, ni leur empreinte de mot de passe sur le reseau. Lidee de lauthentication en
SRP fut lancee sur USENET en 1996 pour la premi`ere fois. Deux cles de sessions sont echangees
durant la phase dauthentication, ` a laide dun Die Hellman et de lempreinte du mot de passe.
On verie que les deux parties connaissent bien le mot de passe sans que celui ci ou son empreinte
- 55 -
III.3. FONCTIONALIT

ES AVANC

EES
nait transite.
Ce protocole dauthentication est resistant face aux attaques decoute de reseau comme aux
attaques par injection de trac dans la sequence dauthentication. Il est ainsi robuste, y compris
lorsque lentropie du mot de passe en lui meme est faible.
Kerberos et Radius
RADIUS - Remote Authentication Dial-In User Service est un protocole dauthentication
centralisee fonctionnant en mode client-serveur. On peut lutiliser, dans le cadre dIPSec en Mode
Cong par exemple, pour authentier les roads warriors se connectant `a la passerelle IPSec. LUTM
NETASQ peut alors se comporter comme un client RADIUS et envoyer des demandes dauthen-
tication au serveur. Lutilisateur sera identie et authentie sur le rewall uniquement sil lest
sur le RADIUS.
Kerberos a une vision dierente de lauthentication. Plut ot que de laisser les mots de passe
ou empreinte de mot de passe circuler sur les reseaux, entre les clients et les machines, il propose
un syst`eme de tickets permettant de sauthentier sur nimporte quel service kerberise. Les ser-
vices ou applications authentiant le feront sur la base du ticket et non plus du mot de passe de
lutilisateur.
III.3.2 Traitement des paquets
A quel module et dans quel ordre sont exactement confrontes les paquets entrants/sortants
depuis les dierentes interfaces reseaux ? Quels sont les priorites ? Pourquoi est ce quun meme
paquet peut passer plusieurs fois par lASQ?
Une synoptique interne de traitement des paquets est presentee sur la gure III.9).
Un paquet entrant est, avant tout, confronte `a la politique NAT du rewall avant detre trans-
mis `a lASQ. Celui ci eectue toutes les analyses quil peut faire et passe la main au module IPSec
qui se charge de decapsuler les donnees. Ces donnees sont alors confontrees `a lASQ (` a la premiere
verication, lASQ peut juste verier la validite du paquet en lui meme et non pas des donnees quil
contient puisque celles ci sont chirees), validees puis transmises sur linterface ou aux applications
en attente.
En sortie, il sagit du chemin inverse : les paquets sortant sont confrontes aux analyses ASQ,
aux r`egles de SPD an de verier sil correspond `a un tunnel IPSec ou pas, puis au NAT.
La table des translations est donc consultee pour chaque session. Concernant le routage des
paquets, il existe quatre types de routage :
Route Statique : Il sagit des routes prioritaires sur toutes les autres.
- 56 -
CHAPITRE III. LES UTMS NETASQ
Fig. III.9 Synoptique des UTMs NETASQ
Routage par interface : Permet de faire du load balancing par exemple, lorsque lon doit router
le trac internet en fonction de la navigation et/ou des telechargements.
Table Load Balancing : Permet de gerer et maintenir les r`egles de routes par interfaces.
Routes par defaut : Routes consultees en dernier, lorsque toutes les autres nont pas matchees.
III.3.3 High Availability
La H.A - Hight Availability ou Haute Disponibilite permet de prevenir la defaillance
materielle sur les boitiers. La HA fonctionne en mode actif-passif : deux rewalls sont relies par
une liaison specique avec les memes congurations, et un seul est actif `a un instant donne.
Ils communiquemnt reguli`erement an de verier que tout se passe bien et lorsquune defaillance
survient, le rewall passif reprend la main automatiquement. Cela permet dassurer la continuite
du service meme en cas de dysfonctionnement de lun des deux rewalls.
La liaison de communication entre les deux rewalls fut une liaison serie autrefois. Ne pouvant
garantir des debits susants, il sagit aujourdhui dune liaions Ethernet.
- 57 -
III.4. MANAGMENT ET MONITORING
Fig. III.10 High Availability
III.4 Managment et Monitoring
Les UTMs NETASQ sont fournis avec une suite dadministration graphique (cf. III.11) developpee
par lequipe IHM. Cette suite est composee de trois logiciels graphiques permettant une congu-
ration ne et poussee des UTMs :
Manager : Constitue le logiciel dadministration principal. La communication entre le logiciel et
le rewall se fait sur le port TCP 1300 et est chiree en AES 128 bits.
Monitor : Est un logiciel permettant de monitorer, de surveiller lensemble du trac en temps reel.
Ce logiciel repertorie lensemble des logs et calcule un ensemble de statistiques congurables
par ladministrateur.
Reporter : Permet de collecter les logs des dierents modules des UTMs.
En sortie dusine, les UTMs ont tous ladresse 10.0.0.254. La premi`ere connexion `a lappli-
ance (cf III.12) seectue obligatoirement par lintermediaire du Manager et sur une interface dite
protegee, cest `a dire une interface qui acceptera des connexions provenant uniquement du sous
reseau auquel elle appartient.
Par defaut, le ltrage est le plus restrictif possible : le rewall rejette la totalite des ux quil
re coit, excepte le trac sur le port TCP 1300.
- 58 -
CHAPITRE III. LES UTMS NETASQ
Fig. III.11 Suite dadministration des IPS-Firewalls NETASQ
Fig. III.12 NETASQ Firewall Manager
- 59 -
III.4. MANAGMENT ET MONITORING
Dautre part, le gestion des dierents logs et traces dactivites sur les reseaux se fait par lin-
termediaire du Monitor et du Reporter.
Le Monitor loggue lensemble du trac, comme les indicateurs syst`emes et de securite (Debits par
interface, CPU, RAM, HA, etc) ; peut chirer les logs et les envoyer `a un serveur syslog distant.
On peut ainsi suivre, en temps reel, lensemble des services et prendre les mesures qui necessaires
en cas de probl`emes :
Un historique des actions dadministrations.
Les utilisateurs authenties
Les evenements syst`emes
Lactivite des dierents modules
. . .
Ainsi, ladministrateur, en cas de probl`emes sur le reseau, peut immediatement mettre tel ou
telle partie du reseau en quarantaine, ou encore supprimer un utilisateur authentie ou encore se
faire notier par une alarme lors dune tentative dintrusion detectee par lASQ.
La suite graphique a tr`es peu ete utilisee durant ces six mois de stages. Lensemble de ladmin-
istration du rewall sest faite par ssh et Port Serie, directement sur les chiers de congurations
manipules par la suite graphique. Ces chiers de congurations seront ceux qui sont manipules lors
de lintegration du Mode Cong dIPSec.
- 60 -
CHAPITRE IV
Integration du Mode Cong
An ounce of practice is worth more than tons of preaching.
Mahatma Gandhi
Resume :
Ce dernier chapitre, apr`es avoir etudie en details IPSec et pris en main les UTMs de
mani`ere avancee, sinteresse `a lintegration proprement dite du module Mode Conguration
dIPSec dans les rewalls. Pour cela, de multiples etapes :
Il a fallu tout dabord eectuer de tr`es nombreux tests avec racoon et setkey an
de savoir exactement letat du Mode Cong dans le projet ipsec-tools.
A partir de ce moment l`a, realiser un travail de conception qui ferait ressor-
tir la mani`ere dont serait integre cette extension dans le format du chier de congura-
tion NETASQ existant dej`a. Le choix sest nalement porte sur quatre nouveaux tokens :
cfg_src, cfg_dst, cfg_dns, cfg_wins.
Implementer cette extension dans le parseur NETASQ.
Tester lensemble, une fois limplementation realisee, et verier le bon comportement
lors de congurations bancales ou non-valides.
Tester ensuite le code an den evaluer les performances, notamment `a laide doutils
comme Spirent.
Enn, realiser un audit aupr`es de lequipe de developpement de la suite graphique
an dintegrer ces tokens de la mani`ere la plus ergonomique possible pour le client.
Parral`ellement, il a fallu realiser un audit du code du projet ipsec-tools an de combler
les manques et dapporter des ameliorations concernant le Mode Cong, notamment au
niveau du nouveau token clientaddr.
IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS
IV.1 Tests et audit sur ipsec-tools
IV.1.1 Etat dipsec-tools
Lun des objectifs `a atteindre dans le cahier des charges etait de dresser une evaluation de
racoon, demon de negociation IKE du projet KAME ipsec-tools, evaluation generale dans un
premier temps, puis sur laspect des dierentes extensions , et enn sur laspect Mode Config en
particulier.
Levaluation generale consistait plus en une prise en main de racoon. Il fallait se familiariser
avec lensemble des options disponibles dans racoon, et connatre limpact sur les dierentes asso-
ciations de securite etablies.
Laspect extensions IPSec - Mode Config - XAuth - Hybrid est venu renforcer le cote authen-
tication des correspondants lors de letablissement dun tunnel IPSec. Il fallait, en eet, dans un
soucis de compatibilite future, etudier les trois extensions, meme si seule Mode Config etait ini-
tiallement destinee `a etre integree dans le rmware NETASQ, dans le cadre du cahier des charges
du stage en tout cas.
Enn, une evaluation assez poussee de tout laspect Mode Config. Une implementation du
Mode Config existait dej` a dans le projet ispec-tools. Toutefois, peu de personnes lavait utilise
ou teste. Lobjectif etait donc double : evaluer le Mode Config en eectuant une batterie de tests
pousses, verier le comportement correct de racoon en cas de mauvaises congurations, et le cas
echeant corriger le code et/ou apporter des modications an den accroitre les performances.
Lensemble des tests eectues en Mode Config ont ete concluants, il sav`ere que limplementation
du Mode Config existante etait stable et operationnelle dans un cadre de deploiement massif. Ainsi
a-t-on mis laccent sur le chier de conguration NETASQ an de lintegrer aussi vite que possible.
IV.1.2 Congurations Racoon (( basique ))
Un chier de conguration basique de racoon se presente de la mani`ere suivante :
remote 193.194.195.196
{
exchange_mode main;
doi ipsec_doi;
situation identity_only;
my_identifier asn1dn;
certificate_type x509 "my.cert.pem" "my.key.pem";
initial_contact on;
proposal_check strict; # obey, strict, or claim
- 62 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group 2;
}
}
sainfo address 203.178.141.209 any address 203.178.141.218 any
{
pfs_group 2;
lifetime time 30 sec;
encryption_algorithm des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
ISAKMP SA
La section remote IP ou remote anonymous nous renseigne sur ladresse de lh ote distant. Il
peut sagir dune conguration anonyme egalement, lorsque ladresse IP du correspondant est dy-
namique, typiquement dans le cas des road warriors.
Lensemble des champs presents dans la section remote permettent de negocier la ISAKMP
SA, IKE-Phase 1. Ils denissent, entre autres, la duree de vie de la phase 1, les algorithmes de
chirement et dauthentication utilises et surtout la exibilite de negociation `a travers le champ
proposal check.
Ce champ est par defaut `a strict. Tr`es nombreuses sont les congurations racoon o` u lon remar-
que ce champ positionne `a obey. Il serait judicieux de nutiliser le mode obey que pour realiser des
tests et passer `a une plus grande robustesse ensuite en utilisant les mode strict, exact, claim.
Dans le mode strict, racoon accepte une negociation de Phase 1 uniquement si les propo-
sitions de chirement, dauthentication et de durees de vies sont au moins equivalentes `a celles
presentes dans la conguration. Si elles sont dun niveau de securite moindre ou de durees de vies
plus faibles, la negociation echoue. exact naccepte que des propositions rigoureusement exactes,
claim essaie de negocier une proposition equivalente au moins en terme de durees de vies.
Dautre part, le champ exchange_mode denit le mode de negociation principal (Identity Pro-
tection Mode) ou aggressif. La plupart du temps, lorsque les IPs des deux correspondants sont
connues `a lavance, le mode utilise est main, comme nous lavons decrit precedemment.
- 63 -
IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS
IPSEC SA
La section sainfo suivante permet de denir les param`etres de negociations de la IPSEC-SA,
IKE-Phase 2. Il sagit des param`etres qui vont etre utilises pour chirer et/ou authentier le trac
utile. Cette section se presente de la mani`ere suivante :
sainfo src_ntwork/mask proto dst_ntwork/mask proto
{. . .}
On denit ainsi les sous-reseaux qui communiqueront de mani`ere chiree `a travers le tunnel.
En outre, les IPSec SAs sont renouvellees `a 80% de leur duree de vie. Ainsi, il existe, dans le
noyau, un flag correspondant `a la maturite des SAs :
Larval : La SA est referencee dans le noyau, en cours de negociation et non-utilisable `a cet instant
donne.
Mature : La SA peut etre utilisee ou est en cours dutilisation actuellement.
Dying : La SA a atteint ou est proche de 80% de sa duree de vie. Elle peut continuer `a etre
utilisee, mais il faudra la renouveller sous peu.
Dead : La SA nest plus valide, mais toujours referencee dans le noyau. Elle ne peut plus etre
utilisee.
Cette conguration est (( classique )) : les adresses IPs des correspondants sont connues, en
mode main avec une authentication en Certicats X509. Cest la conguration la plus largement
deployee aujourdhui pour relier des sites distants.
IV.1.3 Injection de politiques de securite par setkey
setkey est un utilitaire userland developpe au sein du projet ipsec-tools permettant de ma-
nipuler et acher la Security Policy Database - SPD et la Security Association Database - SAD.
setkey est appele lors que lon souhaite injecter des politiques de securite dans la SPD :
flush;
spdflush;
spdadd 127.0.0.0/8 127.0.0.0/8 any -P in none;
spdadd 127.0.0.0/8 127.0.0.0/8 any -P out none;
#Police sortante
spdadd 10.0.11.0/24 any 10.0.11.33/32 any -P out ipsec
esp/tunnel/192.168.0.1-192.168.1.2/require ;
#Police Entrante
spdadd 10.0.11.33/32 any 10.0.11.0/24 any -P in ipsec
esp/tunnel/192.168.1.2-192.168.0.1/require ;
- 64 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


Aucun trac entrant ou sortant nest chire sur la boucle locale.
Une politique de securite pour le trac sortant est ajoute : lensemble du trac provenant du reseau
10.0.11.0/24 `a destination de 10.0.11.33 est du trac IPSec, et sera chire suivant la SA cor-
respondante entre les extremites de tunnels que sont 192.168.0.1 et 192.168.1.2.
Une autre politique de securite pour le trac entrant, qui represente le chemin inverse emprunte par
les paquets : il sagit du trac provenant de 10.0.11.33 `a destination de 10.0.11.0/24, passant
`a travers le meme tunnel IPSec.
On peut voir la table des politiques par setkey -DP :
127.0.0.0/8[any] 127.0.0.0/8[any] any
in none
spid=37 seq=3 pid=61636
refcnt=1
10.0.11.33[any] 10.0.11.0/24[any] any
in ipsec
esp/tunnel/192.168.1.2-192.168.0.1/require
spid=40 seq=2 pid=61636
refcnt=1
127.0.0.0/8[any] 127.0.0.0/8[any] any
out none
spid=38 seq=1 pid=61636
refcnt=1
10.0.11.0/24[any] 10.0.11.33[any] any
out ipsec
esp/tunnel/192.168.0.1-192.168.1.2/require
spid=39 seq=0 pid=61636
refcnt=1
Les extremites de tunnels correspondent aux extremites (192.168.0.1-192.168.1.2) entre lequel
le trac sera eectivement securise (chire, authentie) et les extremites de trac, les extremites
communiquantes `a travers ce tunnel (10.0.11.0/24-10.0.11.33). Un paquet en provenance, par
exemple, de 10.0.12.3 ne pourra pas emprunter le tunnel puisquil ne fait pas partie des extremites
de trac.
Une fois la phase de tests ipsec-tools basique et une prise en main avancee de racoon realisees,
il a fallu passer `a letape de verication des implementations des extensions XAuth et Mode Config
en particulier.
IV.1.4 Conguration en XAuth
Comme nous lavons presente au chapitre consacre aux extensions IPSec decrites dans dierents
drafts, XAuth utilise des paquets de type Transaction Exchange, paquet ISAKMP particuliers.
Les tests sur XAuth ont ete realisee, avec en mode serveur racoon et en mode client TheGreenBow
TM
.
TheGreenBow est un client VPN developpe par TheGreenBow Enterprise Security Solutions et
- 65 -
IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS
fournit par NETASQ, pour les plateformes Microsoft Windows.
En Mode XAuth ou en Mode Cong, un ensemble de clients mobiles dont ladresse IP nest
pas connue `a lavance se connectent sur la passerelle, et doivent sauthentier. En plus de lau-
thentication normale realisee par racoon, XAuth realise une authentication complementaire de
lutilisateur `a proprement parler. On peut rappeller que, bien que lauthentication de lutilisateur
se fasse au niveau de XAuth, les echanges sont proteges par la ISAKMP SA etablie au prealable.
Une ISAKMP SA faible ne prot`ege pas dune eventuelle attaque ou intrusion, meme si lauthen-
tication de lutilisateur par XAuth est faite sur la base de methodes robustes.
La conguration de racoon en mode anonyme en plus du Mode Cong est quelque peu dierente
du cas (( classique )).
remote anonymous # On ne connait pas ladresse du road warrior !!
{ . . .
generate policy on; # On ne connait pas les politiques de securite a lavance
mode_cfg on; # On active les echanges Mode Config
. . .
}
mode_cfg
{
auth_source system ; # pam, radius...
auth_throttle 15 ; # Refuse la connexion de ce user pdt 15s en cas d echec dauth
. . .
}
sainfo ip_passerelle any anonymous
{
. . .
}
Les dierents champs rajoutes permettent une conguration dynamique `a la volee des SAD et
SPD :
anonymous : la section remote devient anonyme puisque lon ignore les adresses IPs des clients
mobiles. Il faut donc que la section match toutes les adresses.
generate policy : gen`ere et injecte dynamiquement les politiques de securite via PF_KEY et la
librairie IPSec. Puisque lon ignore les IPs des mobiles, on ne peut etablir des politiques
de securite par avance. Elles doivent letre `a la volee au moment de la connexion des road
warriors.
mode cfg on : permet dactiver les echanges Mode Conguration (paquets de type Transaction
Exchange) permettant de realiser une authentication en XAuth.
La section mode_cfg vient sajouter aux dierentes sections remote et sainfo dej` a presentes.
Elle presente les param`etres des paquets Mode Cong echanges. Il se trouve que dans le cas present,
- 66 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


nous utiliserons la section Mode Cong uniquement pour authentier lutilisateur en XAuth. On sig-
nale donc `a la passerelle que lauthentication se fera sur les comptes syst`eme, et quen cas dechec
dauthentication dun login particulier, celui ci ne pourra refaire une tentative avant quinze sec-
ondes.
Apr`es XAuth, il a fallu valider le Mode Conguration proprement dit, tel que decrit dans le
draft draft-dukes-ike-mode-cgf-02.
IV.1.5 Mode Cong : racoon vs racoon
Principe
Lorsquun client mobile se presente `a la passerelle IPSec pour y etablir une connexion, deux
choix sorent `a lui :
Il a embarque sur sa machine, au prealable, toute la conguration reseau necessaire `a letablissement
de sa connexion IPSec. Il ne lui reste plus qu` a sauthentier aupr`es de la passerelle pour
que celle ci puisse lui etablir son tunnel IPSec. Les informations embarquees sont, au mini-
mum, lextremite distante de tunnel, les extremites distantes de trac, les adresses deventuels
serveurs de noms, et les cles dauthentication.
Toutefois, maintenir plusieurs dizaines voire centaines de machines mobiles peut tr`es vite
devenir un casse-tete infernal pour ladministrateur, qui se voit attribuer un double travail :
garder tous ces mobiles `a jour en fonction des changements eectues sur la passerelle IPSec et
sur les membres de lentreprise en general (suppression de compte, revocation de certicats,
creation de compte, etc).
Lidee serait donc de pouvoir envoyer toute la conguration reseau necessaire dynamiquement
au client mobile, une fois quil sest correctement authentie. Le Mode Conguration peut
servir, comme decrit au chapitre sur les extensions, `a envoyer ces informations `a la volee.
Test
racoon est utilise des deux cotes client et serveur dans un premier temps. Seules les sections
Mode Cong sont modiees, la section remote restant toujours anonyme du cote du serveur, et
ayant ladresse de la passerelle du cote du client.
. . .
mode_cfg
{
network4 192.168.12.0 ;
netmask4 255.255.255.0 ;
split_network include 10.11.12.0/16 ;
dns4 172.16.4.27 ;
}
On specie dans la section Mode Cong lensemble des param`etres `a transmettre au client
mobile lors de sa connexion :
- 67 -
IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS
network4 : Il sagit du reseau RFC1918 dans le lequel racoon va piocher une adresse IP (( locale ))`a
transmettre `a linterface IPSec du client mobile, pour que celui-ci puisse pretendre etre sur le
LAN de lentreprise. Les adresses sont attribuees dans lordre croissant aux dierents clients,
sont recyclees, et en cas de penurie, les negociations echouent. Dans notre cas, le reseau est
192.168.1.0/24, 254 clients mobiles peuvent se connecter au maximum.
split network : Il sagit de lextremite de trac locale `a transmettre au client mobile. Il pourra
ainsi etablir des politiques de securite an de communiquer en IPSec. Suivant ce champ,
generate_policy injecte les r`egles sur la passerelle.
dns4 : Adresse du serveur de nom ` a transmettre.
Du cote du client, en revanche, aucune section mode_cfg nest necessaire. La recuperation des
informations de connexion se fait via deux scripts predenis dans racoon :
remote ip_passerelle
{
. . .
script " /etc/racoon/phase1-up.sh" phase1_up;
script " /etc/racoon/phase1-down.sh" phase1_down;
. . .
}
Ces scripts sont disponibles dans le repertoire samples de toute installation de racoon. Ils se
chargent, entre autres, de recuperer ladresse RFC1918 envoyee par le serveur, de lattribuer `a
linterface IPSec et dinjecter les politiques de securite re cues dans la SPD du client et de rajouter
les entrees dans les serveurs de noms dej` a disponibles.
IV.1.6 Mode Cong : racoon vs quelques clients VPN
racoon en mode client netant pas vraiment realiste, au vue des congurations des clients de
NETASQ, sur des machines portables souvent sur des plateformes Windows, et cherchant le moins
de conguration possible, on sest oriente vers des clients VPN dej` a disponibles : le client fourni
par Cisco Systems, le client VPN TheGreenBow et ShrewSoft, un client VPN sous licence GPL
developpe par un membre de la core team du projet ipsec-tools, Matthiew Grooms.
Cisco VPN Client
La conguration racoon est restee la meme du cote du serveur durant ces tests.
Le client VPN Cisco a ete teste sur une plateforme Windows 2000 SP4.
Les tests en XAuth ont ete concluants, bien que la gestion des certicats soit lourde et peu er-
gonomique.
Les tests en Mode Config nont pas ete totalement concluant :
Une session Mode Config seule naboutit pas, tandis quune session Mode Config suivie dun XAuth
valide recup`ere correctement certains param`etres, comme ladresse IP RFC1918.
- 68 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


Toutefois, il sav`ere que ce client VPN a ete tr`es decevant au niveau de lensemble des propo-
sitions de Phase 1 quil envoie `a la passerelle. En ayant ecoute le trac reseau au moment de la
negociation, le client Cisco envoye toute une panoplie de propositions en esperant que lune delle
sera retenue. Les passerelles IPSec pour les clients mobiles sont, en eet, le plus souvent congurees
en mode passif et se contentent de repondre aux propositions des clients.
Linconvenient majeur du client Cisco est de ne pas tenir compte des reponses de la passerelle
conguree sous racoon, et denvoyer encore plus de protocoles de chirement, de tailles de cles,
de protocoles dauthentication, de durees de vies dierentes, etc. ce qui a tendance `a saturer le
reseau assez rapidement, meme si la connexion aboutit in fine.
TheGreenBow
TM
Les tests eectues sur les maquettes TheGreenBow ont ete concluant sur XAuth, mais mal-
heureusement tr`es decevant sur le Mode Config.
Bien quune fenetre enti`ere soit dediee au Mode Config, lors des ecoutes reseaux, il sest avere
que le support nest pas integre dans TheGreenBow puisquaucune demande (paquet ISAKMP-
REQUEST, ISAKMP-SET) ni reponse (paquet ISAKMP-REPLY, ISAKMP-ACK) nest envoyee
ou re cue par le client VPN.
Le service R&D a donc ete contacte an de connatre les fonctionalites exactes quant au Mode
Cong. Lors de la sortie de la version suivante, le Changelog annon cait une nouvelle fois le Mode-
Cong, et les tests ont donc ete refaits plusieurs mois apr`es.
Ils ont neanmoins echoues egalement. Les requetes ne sont toujours pas transmises, aucun
paquet annon cant le support du Mode-Cong nest detecte lors de la negociation de Phase 1. The-
GreenBow ne supporterait vraisemblablement pas correctement lextension Mode Cong dans son
ensemble.
ShrewSoft
ShrewSoft est un client VPN/IPSec developpe recemment, sous licence GPL, dont la derni`ere
version 2.1.0 date du 19 juin 2008.
Le Mode Cong a egalement ete teste avec Shrew et lensemble des tests eectues ont ete tout
`a fait satisfaisants, avec une passerelle o` u tourne racoon.
Lensemble des champs disponibles dans le Mode Cong de racoon sont correctement transmis `a
Shrew qui congure correctement les politiques de securite et met en place le tunnel.
Quil sagisse du Mode Config seul, ou du Mode Config suivi de XAuth, la conguration est
correctement transmises et lensemble des param`etres correctement pris en compte.
- 69 -
IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS
Fig. IV.1 ScreenShot ShrewSoft
On veillera toutefois `a desactiver la fragmentation des paquets, fonctionalite encore en cours de
developpement.
IV.1.7 Bilan des tests
Prendre en main IPSec, `a dierents niveaux (noyau, interfa cage PF KEY permettant la com-
munication entre le noyau et lespace utilisateur, et les demons en espace utilisateur), ma fallu
plusieurs semaines. Il a fallu etablir letat dans lequel etait les implementations des extensions dans
le projet ipsec-tools.
Lensemble de ces tests, `a commencer par le plus plausible, celui dun racoon en mode serveur
et client, mont permis de valider les implementations. XAuth et Mode Config sont implementes
et operationnels dans ipsec-tools. Les tests ont ete fait sur des machines sous FreeBSD 7.0, et
beaucoup de congurations non-valides ont ete testees an de bien valider la bonne remontee der-
reur. On peut citer le cas dune demande de Mode Config alors quun XAuth est en cours ou na
pas abouti. La passerelle doit refuser toute tentative de Mode Config ou de negociation de Phase
2 tant que lutilisateur nest pas correctement authentie.
A alors debute un travail conception an de pouvoir integrer ce Mode Config dans le rmware
NETASQ.
- 70 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


IV.2 Extension du format du fichier de configuration
IPSec
IV.2.1 Fichiers de conguration NETASQ et parseurs
Fichiers de conguration
Le module IPSec du rmware NETASQ est base sur la pile IPSec FastIPSec et sur le projet
ipsec-tools.
Toutefois, lensemble des modules du rmware NETASQ nutilise pas directement les chiers de
conguration des dierents projets BSD. NETASQ a, en eet, fait le choix davoir ses propres
chiers de conguration dans un soucis dindependance vis `a vis, notamment, du syst`eme FreeBSD
et des projets BSD sous jacents.
Comment les chiers NETASQ interagissent-ils avec ceux des modules du syst`eme ?
NETASQ denit dans un premier temps un format de chier de conguration, en decrivant lensem-
ble des champs necessaires, lensemble des valeurs disponibles, les valeurs par defaut, etc. Dans
un second temps, ce chier de conguration est parse `a laide de multiples librairies de parsing
developpee par NETASQ. En sortie, on obtient alors un chier de conguration au format du projet
sous jacent qui est utilise pour executer le module.
Lavantage quore ce choix est de pouvoir garder la meme signature des chiers de congu-
ration vis `a vis du client nal. Il arrive que NETASQ doive changer tel projet par tel autre, parce
que des ameliorations ont ete apportees, ou parce que le projet actuel nest plus maintenu, etc.
Dans ce cas, NETASQ ne peut se permettre de changer de module et de laisser le client nal se
debrouiller dans un nouvel environnement quil ne matrise pas forcement.
Ainsi, lorsque cela arrive, le chier de conguration NETASQ reste le meme, seules sont modiees
les librairies de parsing en arri`ere plan an den sortir le chier de conguration au format du
nouveau module frachement integre. Le client manipule ainsi le meme chier de conguration.
Exemple
Le module NAT
1
utilise est, `a lheure actuelle, le module FreeBSD ipnat.
Le chier de conguration NETASQ du NAT se presente comme suit :
[Config]
KeepNAT=0
[NAT]
map bridge Network_inJup to any -> pessac port ephemeral_fw
rdr bridge merignac to pessac port ssh -> pessac_local port ssh
rdr bridge any to pessac port VNC_port -> pessac_local port VNC
rdr bridge any to pessac port vnc_java -> pessac_local port vnc_java
1
NAT - Network Adress Translation
- 71 -
IV.2. EXTENSION DU FORMAT DU FICHIER DE CONFIGURATION IPSEC
Il sagit du chier de conguration NAT que jai utilise sur mon reseau de travail durant les six
mois de stage.
Bien que la syntaxe du chier NETASQ ressemble `a celle dipnat, le parseur permet, `a partir du
chier de conguration NETASQ, dobtenir le chier de conguration au format ipnat :
map sis0 192.168.2.0/24 -> 10.2.29.2/32 portmap tcp/udp 20000:59999
map sis1 192.168.2.0/24 -> 10.2.29.2/32 portmap tcp/udp 20000:59999
map sis3 192.168.2.0/24 -> 10.2.29.2/32 portmap tcp/udp 20000:59999
map sis0 192.168.2.0/24 -> 10.2.29.2/32
map sis1 192.168.2.0/24 -> 10.2.29.2/32
map sis3 192.168.2.0/24 -> 10.2.29.2/32
rdr sis0 from 10.2.29.1/32 to 10.2.29.2/32 port = 22 -> 192.168.2.1 port 22 tcp
rdr sis1 from 10.2.29.1/32 to 10.2.29.2/32 port = 22 -> 192.168.2.1 port 22 tcp
rdr sis3 from 10.2.29.1/32 to 10.2.29.2/32 port = 22 -> 192.168.2.1 port 22 tcp
rdr sis0 from 0/0 to 10.2.29.2/32 port = 5900 -> 192.168.2.1 port 5099 tcp
rdr sis1 from 0/0 to 10.2.29.2/32 port = 5900 -> 192.168.2.1 port 5099 tcp
rdr sis3 from 0/0 to 10.2.29.2/32 port = 5900 -> 192.168.2.1 port 5099 tcp
rdr sis0 from 0/0 to 10.2.29.2/32 port = 5800 -> 192.168.2.1 port 5800 tcp
rdr sis1 from 0/0 to 10.2.29.2/32 port = 5800 -> 192.168.2.1 port 5800 tcp
rdr sis3 from 0/0 to 10.2.29.2/32 port = 5800 -> 192.168.2.1 port 5800 tcp
Il sagit dune conguration NAT basique permettant de translate un reseau, en locurrence
192.168.2.0/24, en une adresse IP, en locurrence 10.2.29.2 ; dune redirection de port ssh,
TCP 22, et dune redirection de port VNC, TCP 5800 et TCP 5900.
Lorsque dans le cahier des charges des versions futures du rmware, il ne sera plus question
dutiliser ipnat, si cela arrive, le chier NETASQ restera le meme. Seul changera la librairie de
parsing qui generera, cette fois ci, un chier au format du nouveau module NAT.
Le chier de conguration IPSec est base sur le meme principe, cest ce chier que nous nous
proposons detendre en vue de lintegration de lextension Mode Cong.
IV.2.2 Conception et extension du chier
Conception
Apr`es ma prise en main des appliances NETASQ et le succ`es des nombreux tests realises avec
racoon, une nouvelle roadmap a ete etablie.
En fonction des demandes des clients, des champs Mode Config disponibles dans racoon, et du
delai imparti pour lintegration, il a nalement ete decide denvoyer la conguration reseau suivante
aux clients mobiles :
Une adresse IP de type RFC 1918 an que linterface IPSec du client mobile soit conguree
de telle mani`ere quelle croit etre sur le reseau interne, do` u tout linteret.
Transmettre son extremite distante de trac pour quil puisse negocier les IPSec SA sans
embarquer ces informations de mani`ere statique sur la machine.
- 72 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


Transmettre ladresse dun serveur DNS
2
.
Transmettre ladresse dun serveur WINS
3
Fichier VPN
Un chier de conguration NETASQ IPSec se presente de la mani`ere suivante :
[Global]
Tunnels=Tunnel_1
[Tunnel_1_1_1]
Dh=2
Hash=1/160
Enc=11/256
[Tunnel_1_2_1]
Mode=ESP,TUNNEL
Auth=3/160
Enc=11/256
Dh=2
Lifetime=3600
Src=any
Dst=merignac
keepalive=60
[Tunnel_1]
Name=tunnel_2
Method=PSK
Mode=MAIN
Lifetime=3600
CheckMode=Exact
ResponderOnly=1
AdvancedMode=1
dpd_mode=passive
Src=fw_out
Peer=merignac
State=1
2
DNS - Domain Name System permet la resolution des noms.
3
WINS - Windows Internet Naming Service permet egalement la resolution de noms pour les syst`emes utilisant
NetBIOS.
- 73 -
IV.2. EXTENSION DU FORMAT DU FICHIER DE CONFIGURATION IPSEC
Ce chier de conguration, lorsquil sera parse, donne en sortie un chier de conguration
racoon, quon appellera plus simplement le chier racoon.conf par la suite.
Les dierents champs sont volontairement intuitifs, an de congurer les tunnels IPSec de la
mani`ere la plus ergonomique possible :
La section [Tunnel_1_1_1] decrit lensemble des param`etres de proposition de phase 1. Elle
comprend notamment le groupe Die-Hellman, les algorithmes de chirement et dauthen-
tication. Cette section donne une partie de la section proposal du racoon.conf.
La section [Tunnel_1_2_1] decrit lensemble des param`etres de Phase 2 et comprend notam-
ment les durees de vie des SAs proposees. Cette section sera parsee en la section sainfo{...}
du racoon.conf.
Enn la section [Tunnel_1] permet de congurer lensemble des param`etres globaux relatifs
au tunnel mis en place. Cela comprend notamment le mode de negociation, la exibilite de
negociation et les durees de vie proposees.
Les algorithmes de chirement et dauthentication sont renseignes dans une table maintenue
`a part : lajout ou la suppression dun algorithme se fait ainsi `a un seul endroit. Cette fa con de
proceder permet de se conformer `a des contraintes legislatives en fournissant des versions ne com-
portant que certains algorithmes ou ne rendant possible lutilisation que de certaines longueurs
de clef. Ceci est particuli`erement utile lorsquil sagit dexporter les appliances NETASQ vers des
pays o` u lEurope impose une legislation dierente en terme dalgorithmes de chirement.
Denition des champs
Lors de la conception des dierents champs destines `a etre integre, laccent a ete mis sur le fait
davoir une architecture peu gourmande en terme de taille de chier.
Il existe dej` a un champ dst dans le chier de conguration NETASQ : ce champ denit lextremite
distante de trac dun tunnel IPSec. Parral`element, le champ src denit lextremite locale de trac
correspondante.
Dautre part, nous avons fait le choix de nautoriser le Mode Cong que dans le cas des road
warriors, cest `a dire dans le cas o` u les adresses IP ne sont pas connues `a lavance, cest `a dire dans
le cas de congurations anonymes.
On se rend compte que lextremite de trac distante (denit par dst) est en n de compte
limitee `a une seule adresse, celle que lon souhaite transmettre en Mode Cong : les extremites
distantes de tunnel et de trac sont confondues.
Il est ainsi judicieux dutiliser le champ dst dej` a deni en tant que pool dadresses IP `a transmettre
aux dierents clients, dans le cas dune conguration en Mode Cong.
Pour recapituler, lorsque loption Mode Cong nest pas activee, le champ dst se comporte
comme etant lextremite de trac distante. Lorsque loption Mode Cong est activee, le champ dst
se comporte comme pool dadresses IP. Une adresse est prise dans le pool et transmise au client.
- 74 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


Lactivation de loption Mode Cong se fait par la denition de quatres champs crees `a cette
n :
cfg dns : Ce champ denit le serveur DNS `a transmettre en Mode Cong. Ce champ sera parse
en dns4 dans le racoon.conf.
cfg wins : Comme DNS, ce champ denit un serveur WINS `a transmettre et sera parse en wins4.
cfg src : Ce champ peut etre positionne `a 1 pour lactiver ou 0, valeur par defaut, permet de
transmettre lextremite locale de trac au client, stockee dans le champ src. Il correspond `a
la partie du reseau interne auquel le client est autorise `a acceder. Cette information est au-
jourdhui embarquee statiquement sur les machines. Dorenavant, elle pourra etre transmises
`a la volee, par Mode Cong, suivant lidentite du client qui se presente.
cfg dst : Positionnable `a 1 ou 0, valeur par defaut. Il sagit du pool dadresses IP disponibles
denit sous la forme dun reseau et masque correspondant. A titre dexemple, si cfg_dst est
positionne `a 1 et le champ dst ` a 192.168.12.0/24, les road warriors qui se presentent auront
une IP du reseau 192.168.1.0/24 et 254 road warriors pourront negocier au maximum au
meme moment. Les adresses liberees sont ensuite recyclees par racoon.
IV.3 Int

egration et validation
IV.3.1 Imperatifs dimplementation
Implementer les fonctions dans la librairie an de parser les quatres champs ne sut pas pour
generer des congurations correctes. Il a fallu verouiller plusieurs champs an quil ne puissent
interferer avec certaines congurations bancales ou interdites.
Le tout premier verrou a ete celui de lutilisation du Mode Cong uniquement dans le cadre
des road warriors. Rien nempeche, en eet, `a racoon de transmettre des informations en Mode
Cong `a un hote distant (( classique ))qui soit lui meme une passerelle IPSec. Les tentatives dutil-
isation du Mode Cong lorsquil ne sagit pas dun tunnel anonyme naboutiront plus.
Ensuite sest pose le probl`eme du champ dst qui peut tr`es bien etre positionne `a any, lensemble
du trac `a destination de cet hote est alors du trac IPSec. Dans le cas du Mode Cong (donc le
champ cfg_dst = 1 , le champ dst ne peut valoir any, puisque dans ce cas, on ne denit aucun
pool dIP dans lequel racoon pourrait piocher. Cette conguration a donc ete interdite egalement :
lutilisation du Mode Cong pour la transmission dadresses RFC1918 impose la denition du
champ dst.
Les objectifs du cahier des charges ont ete correctement remplis, les imperatifs dimplementation
respectes. Une fois realisee, une maquette a alors ete montee et la validation a pu etre lancee.
IV.3.2 Premiers tests
Une fois la maquette en place, lon a pu tester les quatres champs, dabord un par un, puis en
essayant les combinaisons des dierents champs :
[Tunnel_3_2_1]
Mode=ESP,TUNNEL
- 75 -
IV.3. INT

EGRATION ET VALIDATION
Auth=3/160,4/128
Enc=11/128
Dh=2
Lifetime=3600
Src=Netasq_network
Dst=rw_test
Cfg_dst=1
Cfg_src=1
Cfg_dns=rw_dns
Cfg_wins=rw_wins
keepalive=0
Les quatres champs Mode Cong ont ete denis. Au moment de lactivation de la conguration,
le chier racoon.conf est genere et racoon est demarre. Si le parsing echoue ou sil nest pas valide,
racoon ne demarrera pas. On peut verier le parsing correct :
mode_cfg
{
dns4 10.26.43.169 ;
wins4 10.26.42.247 ;
split_network include 10.2.0.0/16;
pool_size 254 ;
network4 10.2.29.0/24 ;
netmask4 255.255.255.0 ;
}
La section Mode Cong est tout `a fait correctement cree et les dierents champs correctement
positionnes :
Dns4 et Wins4 correspondent aux serveurs de noms `a transmettre.
Split network include correspond `a lextremite locale de trac `a transmettre, `a savoir le
champ src du chier NETASQ.
Les trois derniers denissent la mani`ere dont les road warriors se voient attribuer leur
adresse IP RFC1918. On dispose ici dun pool dIPs de 254 adresses disponibles sur le reseau
10.2.29.0/24.
Laction de loption Mode Cong en elle meme aurait pu etre denie par un champ specique.
Finalement, la presence dun seul des quatres champs Mode Cong sut `a activer loption Mode
Cong.
IV.3.3 Validation et Commit dans le rmware
Une fois les premiers tests passes avec succ`es, la nouvelle librairie de parsing et le nouveau
module IPSec ont ete testes et valides par lequipe de Qualication au laboratoire R&D NETASQ.
NETASQ dispose, pour ses tests de validation et de non regression, entre autres, de deux Spirent.
La societe Spirent ore des solutions de tests, validation et monitoring de services reseaux. Sont
- 76 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


notamment testes le routage, la QoS, les protocoles Wireless, IPSec, etc.
Malheureusement, les syst`emes Spirent ne supportent pas le Mode Cong et nont donc pas pu
etre mis `a contribution lors de la validation du code.
Les tests ont ete realises avec ShrewSoft, non plus avec racoon dipsec-tools en face comme
nous lavions fait lors de nos tests preliminaires, mais en face dune appliance NETASQ integrant
le Mode Cong dans son module IPSec.
Lensemble des tests se sont deroules avec succ`es : la recuperation des informations en Mode
Cong est correcte, les congurations interdites sont bien ignorees et les erreurs adequates sont
remontees `a ladministrateur `a chaque fois.
Lensemble du code a donc pu etre ociellement integre dans le rmware NETASQ. Lors de
la prochaine sortie de version majeure, la version 8.0, dont la sortie ocielle est prevue durant le
dernier trimestre de cette annee, les clients disposeront dune option Mode Cong operationnelle.
- 77 -
Conclusion et Bilan
Be the change that you want to see in the world.
Mahatma Gandhi
La sortie de la prochaine version majeure est prevue pour le dernier trimestre 2008. Les pre-
miers retours sur lutilisation du Mode Conguration dIPSec devraient arriver dans le courant du
premier trimestre 2009. Pourtant, lors de mon arrivee `a NETASQ rien ne predisait que le Mode
Conguration puisse etre eectivement integre dans un delai aussi court, delai comprenant la con-
ception, le developpement et surtout la validation `a travers une batterie de tests de non-regression
et de performances, autant sur la partie ipsec-tools et projet OpenSource que sur la partie
rmware NETASQ.
Le stage sur IPSec et sur le Mode Conguration en particulier avait pour objectif de debroussailler
limplementation de cette extension dans ipsec-tools avant tout : evaluer letat de limplementation
actuelle du Mode Conguration `a travers des tests sur des maquettes montees pour loccasion,
evaluer les performances et conrmer ou inrmer la stabilite de racoon confronte `a des congura-
tions reseaux complexes et pas forcement valides du point de vue des draft et des RFCs.
Lensemble des tests eectues sur le Mode Conguration ont ete concluants, que racoon soit
en mode serveur ou en mode client : lensemble des informations sont transmises correctement `a
la volee, juste apr`es letablissement de la ISAKMP-SA
4
.
Apr`es avoir valide de nombreuses congurations, jai pu mettre laccent sur letude du produit en
lui meme, lappliance NETASQ et son rmware : les dierents modules en general, le processus
de ports de FreeBSD, lASQ, coeur du rmware, le fonctionnement par chiers de congurations
NETASQ et leur librairies de parsing, la communication entre la suite graphique et le rewall, etc.
La prise en main de lappliance NETASQ et letude du rmware ont ete facilitees par les certi-
cations NETASQ Certied Administrator - NCA et NETASQ Certied Expert - NCE
que jai eu lhonneur de pouvoir passer.
4
Sous reserve que lauthentication XAuth soit desactivee, si ce nest pas le cas, les informations sont transmises
juste apr`es la validation de lauthentication en XAuth.
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


Cette etape a marque le debut du travail sur le rmware : integrer le Mode Conguration en
tenant compte de toutes les contraintes existantes. Ces contraintes ont ete de plusieurs ordres.
Prendre en main le code des librairies de parsing dej` a existant.
Tenir compte du chier de conguration existant et letendre dans la mesure de lacceptable :
pas dajout de champs inutiles, pas de conguration supplementaire non necessaire pour le
client.
Comportement par defaut correct si le Mode Conguration nest pas active. Il sagit de
limplementer comme une option `a part enti`ere, pour que par defaut, le module IPSec se
comporte comme dans les versions precedentes.
Tenir compte des contraintes indirectes, notamment en terme de Suite Graphique NETASQ :
la lecture des champs par defaut ne doit pas etre perturbee par lapparition des nouveaux
champs que la suite graphique ne connait pas.
La prise en compte de lensemble de ces contraintes a ete sujette `a plusieurs discussions fructueuses,
et a nalement mene `a la creation des quatres champs Mode Conguration implementes dans le
rmware.
Une fois le Mode Conguration implemente, valide et operationnel, jai pu me concentrer sur
lamelioration de limplementation du Mode Conguration dipsec-tools par letude dun nou-
veau champ dans racoon : le champ CLIENTADDR. Le CLIENTADDR permet de matcher lidentite de
lh ote distant suivant quil sagisse de ladresse IP de lh ote ou de ladresse IP RFC1918 denie
dans la conguration Mode Conguration, si celui ci est active. Le CLIENTADDR peut etre utile pour
restreindre la generation de politiques de securite lors que racoon agit comme une passerelle pour
les clients mobiles.
Il se trouve que Matthiew Grooms avait dej` a realise une partie de limplementation sur la branche
principale du projet ipsec-tools. Jai porte le champ de la branche principale vers la version
stable dipsec-tools actuelle, 0.7.1.
Tout au long des six mois passes `a NETASQ, plusieurs idees re cues de letudiant terminant son
cursus ont ete bousculees, `a juste titre et tant mieux. Jai, avant tout, pu constater quil ne sut
pas davoir une conception parfaite une bonne implementation pour quelle puisse etre integree
dans un rmware dej` a existant et soumis `a un certains nombres de contraintes.
- 79 -
IV.3. INT

EGRATION ET VALIDATION
Dej` a fascine par la securite `a luniversite, jai pu porter un regard dierent sur ce monde qui
parait toujours renferme et reserve vu de lexterieur. Jai ainsi pu suivre levolution des failles
OpenSSL et DNS du point de vue dune societe specialisee en securite informatique o` u il fallait
toujours etre sur le qui-vive, suivre les dierents PoC
5
o` u encore etudier les dierents articles
et impressions sur de grandes conferences en securite informatique, quelles soient francophones
comme le SSTIC, ou internationales comme BlackHat ou DefCon.
Je citerai ici Ferdinand Foch - (( Il ny a pas dhommes cultives, il ny a que des hommes qui se
cultivent ))- tout `a fait approprie lorsquil sagit de securite informatique ou de cryptologie.
Pendant toute cette periode, jai eu lhonneur detre entoure dingenieurs extremement competents
dans leur domaine, me permettant davoir les meilleurs conseils possibles de la part de la part de
personnes toujours disponibles et `a lecoute. Je porte aujourdhui un regard tout ` a fait dierent sur
un projet OpenSource, sur lutilisation subtile des dierentes licences (GPL, BSD, Libre, Open-
Source...). Jai egalement pu ameliorer mon niveau en developpement de fa con consequente, en
etant confronte `a des styles de programmation dierents tout en respectant la charte de program-
mation de NETASQ. Dautre part, jai pu remarquer laide apportee par la communeaute lorsquil
sagit dauditer du code source ou de comprendre une RFC o` u se chevauchent des subtilites, souvent
anglaises, de termes comme MAY , MIGHT ou SHOULD ne facilitant pas toujours lintegration
de telle ou telle fonctionalite.
Enn, le plus important `a mes yeux concerne le regard critique que jai pu adopter face `a la
formation que jai re cue `a luniversite. Cette experience ma non seulement permis dapprondir
certains points cles, mais egalement de poser des bases solides pour commencer une carri`ere qui,
je lesp`ere, me permettra detre acteur plutot que spectateur dans le monde de la securite infor-
matique.
5
PoC : Proof Of Concept
- 80 -
Annexe A : Protocole AH et ESP approfondis
En-t

ete IP
Les protocoles AH et ESP reposant sur sur IP, une description sommaire des champs dIP est
donnee dans le tableau ??.
IP est un des protocoles reseau les plus repandu aujourdhui, dans sa version IPv4 qui commence
`a sessouer du manque dadresses disponibles et dans version IPv6 dej` a massivement deploye au
Japon. Il apporte ladressage en couche 3 permettant de router les paquets.
Les champs principaux de lentete IP sont denis de la mani`ere suivante :
ver : Il sagit de la version du protocole IP utilise (4 ou 6), code sur 4 bits. Place en tete, il permet
de verier le format correct du paquet et de le detruire de suite en cas de version inconnue.
IHL : Pour Iinternet Header Lengh, IHL, code sur 4 bits, represente la longueur de len-tete IP
en mots de 32 bits. Sa valeur peut varier de 5 `a 15 (donc de 15 32 = 60octets max) suivant
les options IP et est `a 5 (20 octets) par defaut.
TOS : Pour Type Of Service, sur 8 bits, permet de controler la QoS directement au niveau OSI
3. TOS regroupe des donnees comme la priorite, le delai ou encore le co ut. TOS est lunique
champ recupere par ESP pour lencapsulation ESP-Tunnel.
pkt-len : Il sagit de la longueur totale du paquet IP, code sur 16 bits, en-tete et donnees com-
prises. Exprimee en octets, la longueur totale maximale est donc de 2
1
6 = 65535octets.
ID : Code sur 16 bits, le champ Identication permet de reconstituer les dierents fragments. Les
en-tetes IP des fragments sont les memes `a lexception de la longueur et du checksum.
Flags : Code sur 3 bits, ces ags permettent de connatre letat actuel de la fragmentation. Le
premier bit est `a 1 (Reserved), le deuxi`eme autorise ou non la fragmentation (DF Don

t
Fragment) et le dernier indique sil existe dautres fragments (MF More Fragments).
frag oset : Code sur 13 bits, indique `a quel position se trouve le fragment par rapport au pre-
mier. Le premier poss`ede donc un champ frag oset `a 0.
IV.3. INT

EGRATION ET VALIDATION
TTL : Le champ Time TO Live indique la duree de vie maximale du paquet. Lorsquil baisse `a
0, le paquet est detruit. A chaque passage dans un routeur, ce champ sera decremente. Ceci
permet deviter les boucles innies dans la propagation des trames.
proto : Code sur 8 bits, il represente le champ Protocol. Les plus repandus sont -01-ICMP, -06-TCP
et -17- UDP. Les numeros de protocoles sont attribues par lIANA - Internet Assigned Number
Security.
Checksum : Code sur 16 bits, la somme de controle permet de verier la validite du paquet (et
uniquement celle du paquet et non pas des donnees quil contient : deux trames IP ayant les
meme champs auront la meme somme de controle).
Src IP address : Represente lIP source codee sur 32 bits.
Dst IP address : Represente lIP de destination codee sur 32 bits egalement.
IP Options : Code de 0 `a 40 octets, ce champ permet de passer certaines options `a IP, comme
la Classe ou le Numero permettant de lister les options disponibles.
ver IHL TOS pkt-len
ID ags frag oset
TTL proto = TCP header checksum
Src IP address
Dst IP address
Options IP (si presentes)
TCP Header (proto=6)
TCP Payload
32 bits
: Couvert par le checksum
Fig. IV.2 Paquet IPv4 Generique
Ces champs nous serviront, par exemple, `a denir la mani`ere dont ESP g`ere les priorites de
communications (par la recuperation du TOS) ou encore `a comprendre pourquoi il etait tr`es dif-
cile de deployer IPSec `a travers des equipements NAT, avant le developpement de lextentions
NAT Traversal.
- 82 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


AH - Authentication Header
AH est uniquement utilise pour de lauthentication pas de chirement . Il permet de valider
lidentite de lh ote distant avec lequel on communique an de se premunir des attaques MITM. Il
detecte ainsi toute alteration des donnees et ore une protection forte contre le rejeu de paquets.
En-tete AH
LAuthentication est faite `a partir dune empreinte cryptographique dauthentication base
sur lensemble des champs non modiables du paquet IP. Cela exclut, par exemple, le champ TTL
est decremente, ou encore le checksum qui est recalcule `a chaque passage dans un routeur.
Cette empreinte est alors apose au paquet avant que celui ci ne soit envoye. Lors de la reception du
paquet, lh ote distant calcule `a son tour une empreinte du paquet frachement re cu et le compare
avec celui contenu dedans an de le valider.
next hdr AH lengh Reserved
SPI (Security Parameters Index)
Sequence Number
Authentication Data
hash MD5 ou SHA-1
Fig. IV.3 Champ de len-tete AH
Champs de len-tete AH :
Next Header : Code sur un octet, il contient le numero de protocol de len-tete suivante, donc
le numero de protocole des donnees que le paquet transporte. Ce champ permet de lier les
dierentes en-tetes.
AH lengh : Code sur un octet egalement, il contient la taille de len-tete AH en mots de 32 bits,
otee de 2 (ceci ninclue pas les donnees mais len-tete uniquement). Les 64 bits sont enleves
an detre coherent avec la mani`ere dont IPv6 calcule la taille de len-tete AH. IPSec dans
IPv6 nest pas aborde dans ce rapport, on peut en trouver une description `a ??.
Reserved : est comme son nom lindique, un champ reserve pour un usage futur, code sur 16 bits.
- 83 -
IV.3. INT

EGRATION ET VALIDATION
SPI : Le Security Parameter Index est un identiant permettant de trouver `a quel politique le
paquet doit-il etre soumis, et donc `a quel SA dans la SAD il correspond. Le SPI est code sur
32 bits et sera developpe plus en details dans la section ??.
Sequence Number : Code sur 32 bits, il represente un compteur initialise `a 0 lorsquune SA en-
tre deux hotes est etablie. Il est incremente pour chaque datagramme correspondant `a cette
SA. Il permet didentier chaque paquet de mani`ere unique et ainsi de se proteger contre des
attaques par rejeu.
Authentication Data : Contient lempreinte calculee par le protocole AH.
Comme decrit precedemment, IPSec peut fonctionner suivant le mode Tunnel ou Transport.
AH nest donc pas calcule de la meme mani`ere.
AH en mode Tranport
En mode Transport, len-tete AH est inseree entre len-tete du protocole de Transport (TCP le
plus souvent) et len-tete IP (cf Fig. IV.4).
Comme len-tete AH vient sintercaler entre les en-tete TCP et IP, les champs proto sont suc-
cessivement modies :
Le champ proto du paquet IP, `a lorigine en TCP, est modie au prot de AH. AH, quant `a lui,
garde dans son champ next une trace du protocole Transport utilise, `a savoir TCP, ceci permet de
faire le lien entre les en-tetes.
AH norant pas de chirement, un attaquant potentiel aura acc`es non seulement ` a len-tete,
mais egalement aux donnees, bien quil ne puisse pas alterer le paquet ou le rejouer.
Une fois que le paquet aura ete valide `a la reception, il sera decapsule, len-tete AH enleve, les
champs remis `a jour et le paquet sera passe `a lapplication concernee.
AH en mode Tunnel
En mode Tunnel, le paquet IP est enti`erement reencapsule dans un autre paquet IP avant detre
envoye.
Une en-tete AH est aposee au paquet, comme en mode Transport, ce qui permet de valider
lauthenticite du paquet `a la reception et de se premunir de lalteration des paquets sur le chemin.
Mais contrairement au mode AH-Transport, AH-Tunnel encapsule le paquet IP dans sa totalite,
cest `a dire len-tete IP et le payload. Les addresses reelles de lemetteur et du destinataire sont
donc masquees (cf Fig. IV.5), seules les adresses des deux passerelles formant les deux bouts du
tunnel sont visibles.
- 84 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID flgs offset
ver
len TOS
pkt-len
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID
flgs offset
ver
len TOS
pkt-len
nxt=TCP AH len Reserved
S P I
Seq. Number
Authentication Data
I
P
H
d
r
T
C
P
H
d
r
+
P
l
o
a
d
A
H
H
d
r
T
C
P
H
d
r
+
P
l
o
a
d
I
P
H
d
r
Couvert par AH
Fig. IV.4 Hash AH en mode Transport
- 85 -
IV.3. INT

EGRATION ET VALIDATION
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID flgs offset
ver
len TOS
pkt-len
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Prto=AH Checksum
ID
flgs offset
ver
len TOS
pkt-len
nxt=IP AH len Reserved
S P I
Seq. Number
Authentication Data
I
P
H
d
r
T
C
P
H
d
r
+
P
l
o
a
d
A
H
H
d
r
T
C
P
H
d
r
+
I
P
H
d
r
+
P
l
o
a
d
I
P
H
d
r
Couvert par AH
Dst IP Address
Src IP Address
Prto=TCP Checksum
flgs offset
TOS
pkt-len verlen
ID
TTL
Fig. IV.5 Hash AH en mode Tunnel
- 86 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


Les verications du paquet arrivant `a destination sont les memes quen mode Transport : l
Integrity Check Value est extrait dune part, calcule sur les dierents champs du paquet re cu
dautre part, puis compare. Lorsque le paquet est valide, il est decapsule et delivre `a lapplication
en attente, ou route vers le sous reseau de destination suivant lIP reelle. A partir de ce moment,
il sagit dun paquet IP normal.
La dierence entre le Mode Transport et le Mode Tunnel dans IPSec nest pas explicite puisquil
nexiste pas de champ Mode `a proprement parler. Elle se fait au niveau du champ Next Hdr :
lorsquil vaut IP, il sagit du Mode Tunnel puisquil encapsule enti`erement un paquet IP. A lin-
verse, lorsque ce champ est positionne `a un autre protocole de transport comme TCP, UDP ou ICMP,
il sagit l` a du Mode Transport qui securise le trac de bout en bout.
ESP - Encapsulating Security Payload
En-tete ESP
ESP peut etre considere comme le coeur de la suite de protocoles IPSec. Il permet davoir un
chirement de toute les donnees presentes dans le paquet et eventuellement de les authentier.
ESP est constitue dun header (cf Fig. IV.6) et dun trailer et peut etre utilise en mode Tunnel
comme en mode Transport tout comme AH.
Le chirement des donnees nest lie `a aucun algorithme cryptographique en particulier, comme
explique dans la presentation dIPSec ??. Les plus couramment utilises sont AES, DES, TripleDES
et Blowsh. Les param`etres de chirement et la cle utilisee sont dynamiquement negocies par un
demon IKE (racoon dipsec-tools en locurrence dans le cadre de notre cahier des charges) et
stockes dans une Security Association.
Les champs dun paquet ESP sont principalement :
Payload chire : Correspond aux donnees chirees, de taille variable.
Next Header : utilise comme dans AH, permet de connatre le type de payload du paquet, `a
savoir IP, TCP, UDP, etc.
Padding : il sagit de bourrage permettant lutilisation dalgorithmes cryptographiques par blocs
(comme AES en mode cbc par exemple).
Pad len : Taille du bourrage.
Dautre part, ESP fournit une authentication optionnelle. Lorsquelle est activee, lempreinte
dauthentication vient se greer apr`es le trailer ESP et utilise les meme mecanismes que dans AH
`a ceci pr`es que lauthentication ESP est basee uniquement sur len-tete ESP et le payload, et non
pas sur le paquet IP en entier.
De lexterieur, un attaquant ne peut determiner le contenu dun paquet ESP, ni meme savoir
sil contient une empreinte dauthentication ou non. Neanmoins, lors de lencapsulation ESP, le
- 87 -
IV.3. INT

EGRATION ET VALIDATION
S P I
Sequence Number
Encrypted Payload
padding
pad len nxt hdr
S P I
Sequence Number
Encrypted Payload
padding
pad len nxt hdr
Authentication Data
E
S
P
T
r
l
A
u
t
h
E
S
P
H
d
r
E
S
P
H
d
r
E
S
P
T
r
l
Chiffr
Fig. IV.6 En-tete ESP avec (` a d.) et sans (` a g.) Authentication
champ ToS du paquet IP est recupere `a partir du paquet original. Ce champ, comme nous lavons
vu, sert entre autres, `a denir le champ QoS utilise dans les transmissions de type VoIP par ex-
emple pour avoir un ordre de priorite important.
ESP en mode Transport
ESP en mode Transport (cf Fig. IV.7) fonctionne `a peu de choses pr`es comme AH en mode
Transport.
Destine `a securiser les transferts de donnees entre deux hotes A et B, ESP-Transport encapsule
uniquement le payload (donnees utiles). Comme pour AH, les adresses source et destination sont
donc visibles dans le paquet transmis.
ESP en mode Tunnel
Le mode ESP-Tunnel (cf Fig. IV.8) encapsule enti`erement le paquet IP original dans un autre
paquet IP. Cest ce qui se rapproche le plus dun tunnel VPN au sens o` u la plupart des utilisateurs
lentendent : un tunnel chire parlequel ils peuvent faire transiter des ux sensibles de mani`ere
securisee an de contacter un reseau distant.
Cest le mode le plus souvent utilise lorsquil sagit de monter une passerelle IPSec.
- 88 -
CHAPITRE IV. INT

EGRATION DU MODE CONFIG


TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID flgs offset
ver
len TOS
pkt-len
TCP Payload
Dst IP Address
Src IP Address
TTL Checksum
ID
flgs offset
ver
len TOS
pkt-len
S P I
Seq. Number
I
P
H
d
r
T
C
P
H
d
r
+
P
l
o
a
d
I
P
H
d
r
Chiffr
Authentication Data
padlen nxthdr
padding
nxt=ESP
Authenti
Fig. IV.7 Paquet ESP en Mode Transport
- 89 -
IV.3. INT

EGRATION ET VALIDATION
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID flgs offset
ver
len TOS
pkt-len
TCP Payload
Dst IP Address
Src IP Address
TTL Checksum
ID
flgs offset
ver
len TOS
pkt-len
S P I
Seq. Number
I
P
H
d
r
T
C
P
H
d
r
+
P
l
o
a
d
I
P
H
d
r
Chiffr
Authentication Data
padlen nxthdr
padding
nxt=ESP
Authenti
IP Hdr
Fig. IV.8 Paquet ESP en Mode Tunnel
- 90 -
Annexe B : Echange Die-Hellman
Pr

esentation
Lechange de cles Die-Hellman, ou pour etre plus exact, la negociation de cles par Die-
Hellman a ete developpe par Die et Hellman en 1976, et publie dans le (( New Directions in
Cryptography )). Ce protocole permet `a deux utilisateurs, que nous appellerons traditionnellement
Alice et Bob, de sechanger un secret `a travers un canal non-securise.
Ce protocole est utilise dans des domaines varies, et intervient notamment dans la negociation
de cles de sessions IPSec.
Principe
Le protocole met en place deux param`etres publics : p, un nombre premier, et g, un generateur,
inferieur `a p deni comme suit :
Pour tout entier compris entre 1 et p 1 inclus, il existe une puissance k de g telle que n = g
k
mod p.
Supposons quAlice et Bob souhaitent echanger un secret par Die-Hellman, ils proc`edent alors
comme suit (cf. IV.9) (toutes les operations sont modulo p) :
Alice choisit un nombre aleatoire a et Bob choisit un nombre aleatoire b.
Alice calcule alors x = g
a
et Bob calcule y = g
b
.
Alice envoie x `a Bob et Bob envoie y `a Alice.
Alice calcule alors (g
b
)
a
= g
ab
.
Bob calcule (g
a
)
b
= g
ab
.
Alice et Bob se retrouvent tout deux avec g
ab
.
Le secret partage par Alice et Bob est alors k = g
ab
.
IV.3. INT

EGRATION ET VALIDATION
Fig. IV.9 Protocole Die-Hellman - www.plenz.com
S

ecurit

e et Faiblesses
La securite de lalgorithme Die-Hellman repose sur la diculte du calcul du logarithme discret.
Il suppose quil est tr`es dicile de calculer le secret partage g
ab
`a la seule connaissance de g
a
et de
g
b
lorsque le nombre premier p est grand. Casser un algorithme Die-Hellman est aussi dicile que
de calculer le logarithme discret sous certaines conditions. (Maurer - Advances in Cryptology 1994).
Lechange de cles Die-Hellman est vulnerable `a des attaques de type Man In The Middle. Un
attaquant potentiel, traditionnellement appelle Oscar, intercepte la valeur publique dAlice (g
a
) et
envoie sa propre valeur publique `a Bob. Lorsque Bob envoie sa valeur publique, Oscar lintercepte
egalement et envoie encore sa propre valeur `a Alice. Ainsi, Alice et Oscar etablissent un secret
partage et Oscar et Bob etablissent un autre secret partage, tandis que Alice et Bob croient tous
les deux communiquer lun avec lautre. Oscar est alors capable de dechirer et modier lensemble
du trac entre Alice et Bob.
Cette attaque fonctionne car les correspondants ne sauthentient pas au prealable.
Le protocole Die-Hellman authentie a ete developpe en 1992 an dempecher lattaque
MITM. Ce protocole preconise lutilisation de signatures et de certicats numeriques an dau-
thentier les deux correspondants. Alice et Bob signent alors leur valeur publique `a laide de leur
cle privee. Il est impossible `a Oscar de modier cette signature sans les cles privees respectives.
- 92 -
Les RFCs IPSec
Lensemble des implementations actuelles dIPSec et des demons IKE est basee sur les RFCs
suivantes. Certaines ont ete redenies recemment en 2005.
RFC 2367 - PF KEY Key Managment API, Version 2.
RFC 2401 - Security Architecture for the IP Protocol.
RFC 4301 - New version.
RFC 2402 - IP Authentifcation Header.
RFC 4302 - New version.
RFC 2403 - The Use of HMAC-MD5-96 within AH and ESP.
RFC 2404 - The Use of HMAC-SHA1-96 within AH and ESP.
RFC 2405 - ESP DES-CBC Cypher with Explicit IV.
RFC 2406 - IP Encapsulating Security Payload.
RFC 4303 - New version.
RFC 2407 - IPSec Domain of Interpretation for ISAKMP.
RFC 2408 - ISAKMP Protocol.
RFC 2409 - IKE Protocol.
RFC 2410 - The NULL encryption algorithm and its use with IPSec.
IV.3. INT

EGRATION ET VALIDATION
RFC 2411 - IPSec Document Roadmap.
RFC 2412 - The OAKLEY Key Determination Protocol.
RFC 2451 - ESP CBC-MODE Cypher.
RFC 2857 - The Use of HMAC-RIPEMD-160-96 within AH and ESP.
RFC 3706 - A trac-based method of Detecting dead IKE peers.
RFC 3947 - Negociation of NAT-T in IKE.
RFC 3948 - UDP encapsulation of IPSec ESP packets.
RFC 4304 - Extended Sequence Number (ESN) Addendum to IPSec DOI for ISAKMP.
RFC 4305 - Cryptographic Algorithm Implementation Requirements for AH and ESP.
RFC 4306 - IKEv2 Protocol.
RFC 4308 - Cryptographic Suite for IPSec.
- 94 -
Bibliographie
[1] An Illustrated Guide To Cryptographic Hashes, Unixwiz.net, Tech Tip, Introduction
sur lutilisation de hashs cryptographiques comme MD5 ou SHA-1, utilise dans lauthenti-
cation HMAC.
[2] IPSec Technical Reference, Microsoft, Provides informations on Microsofts IPSec
implementation in Windows Server 2003.
[3] A cryptographic evaluation of IPSec, http://www.schneier.com/paper-ipsec.html,
Bruce Schneier and Niels Ferguson, IPSec is far too complex to ever really be secure.
[4] Cryptography in Theory and Practice : The Case Of Encryption In IPSec
http://eprint.iacr.org/2005/416, De lutilisation de paquets IPSec chires mais non
authenties, attaques reelles et eectives sur des communications reelles (Linux IPSec
implementation).
[5] TCP/IP Illustrated Volume 1, Richad Stevens, protocole TCP/IP.
[6] Vulnerabilities in IKE XAuth, CISCO Systems, 2005.
[7] Detection dintrusions de reseaux, S. Northcutt, J. Novak, Analyse de trac, utilisation
des outils danalyses, TCPDump, Snort, etc.
[8] Applied Cryptography, Bruce Schneier.
[9] IPSec VPN Design, V. Bollapragada, M. Khalid, S. Wainner, Ouvrage de reference sur le
design VPN et IPSec en particulier.
BIBLIOGRAPHIE
[10] IPSec Presentation Technique, Herve Schauer Consultants,
www.hsc.fr/ressources/ipsec.
[11] The FreeBSD HandBook, http://www.freebsd.org/doc/en/books/handbook/
[12] Designing BSD Rootkits, J. Kong, 2007.
[13] Lexx $ Yacc, Levine - Mason- Brow, OReilly, 1992. ipsec-tools : chiers ecrits en Lexx
et Yacc.
[15] RSA Laboratories Die-Hellman, www.rsa.com.
[15] Computer Networks, A. S. Tanembaum, 4`eme Ed.
[16] ipsec-tools, http://ipsec-tools.sourceforge.net.
[17] TheGreenBow, http://thegreenbow.fr
[18] Faiblesses IPSec en deploiement reels, Yvan Vanhullebus,
http://www.sstic.org/SSTIC06/Faiblesses_IPSec/.
[19] Introduction to FreeSWAN, http://www.freeswan.org.
[20] Methodologie de la programmation en C, Api POSIX, A. Braquellaire, Dunod.
[21] IPv6 and IPSec - Securing The Next Generation Internet,
www.ipv6.com/articles/security/IPsec.htm.
- 96 -
BIBLIOGRAPHIE
.
- 97 -