ipsec_netasq

'

&

$

%

Rapport de stage

——

ETUDE IPSec ET INTEGRATION

DE L’EXTENSION (( 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 Archimede

33405 Talence Cedex 59650 Villeneuve d’Ascq

Table des matieres

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 d’action d’IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 d’une negociation IPSec . . . . . . . . . . . . . . . . . . . . . 24

I.3 Design et architecture de securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

I.3.1 Extremites de tunnel, de trafic . . . . . . . . . . . . . . . . . . . . . . . . . 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 Authentification XAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

II.1.1 Principe et fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

II.1.2 Notifications 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 Authentification forte et complete . . . . . . . . . . . . . . . . . . . . . . . 39

II.3 Mode Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

II.3.1 Presentation Generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

II.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

II.3.3 Parametres disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

II.3.4 Pool et penurie d’adresses IP . . . . . . . . . . . . . . . . . . . . . . . . . . 41

II.4 Interactions XAuth, Hybrid et Mode Config . . . . . . . . . . . . . . . . . . . . . . 42

II.5 Faiblesses d’IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

II.5.1 Failles cryptographiques intrinseques . . . . . . . . . . . . . . . . . . . . . . 42

II.5.2 Problemes d’implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 43

II.5.3 Deploiements reels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

IIILes UTMs NETASQ 45

III.1 Presentation des UTMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

III.1.1 Qu’est ce que l’UTM ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

III.1.2 La premiere generation des UTMs NETASQ : Les series F . . . . . . . . . . 47

III.1.3 La nouvelle generation G2 : Les series U . . . . . . . . . . . . . . . . . . . . 49

III.2 L’ASQ - Active Security Qualification . . . . . . . . . . . . . . . . . . . . . . . . . 51

III.2.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

III.2.2 ASQ : Pile OSI Virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

III.2.3 Analyses de l’ASQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

- 4 -

III.3 Fonctionalites Avancees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

III.3.1 Authentification et PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

III.3.2 Traitement des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

III.3.3 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

III.4 Managment et Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

IV Integration du Mode Config 61

IV.1 Tests et audit sur ipsec-tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

IV.1.1 Etat d’ipsec-tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

IV.1.2 Configurations Racoon (( basique )) . . . . . . . . . . . . . . . . . . . . . . . 62

IV.1.3 Injection de politiques de securite par setkey . . . . . . . . . . . . . . . . . 64

IV.1.4 Configuration en XAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

IV.1.5 Mode Config : racoon vs racoon . . . . . . . . . . . . . . . . . . . . . . . . . 67

IV.1.6 Mode Config : racoon vs quelques clients VPN . . . . . . . . . . . . . . . . 68

IV.1.7 Bilan des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

IV.2 Extension du format du fichier de configuration IPSec . . . . . . . . . . . . . . . . 71

IV.2.1 Fichiers de configuration NETASQ et parseurs . . . . . . . . . . . . . . . . 71

IV.2.2 Conception et extension du fichier . . . . . . . . . . . . . . . . . . . . . . . 72

IV.3 Integration et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

IV.3.1 Imperatifs d’implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

IV.3.2 Premiers tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

IV.3.3 Validation et Commit dans le firmware . . . . . . . . . . . . . . . . . . . . . 76

Conclusion et Bilan 78

Annexe A : Protocole AH et ESP appronfondis 81

Annexe B : Echange Diffie-Hellman 91

RFCs IPSec 93

References et Bibliographie 95

- 5 -

Table des figures

I.1 Positionnement d’IPSec 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 trafic - 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 parametres negocies lors d’une Phase 2 . . . . . . . . . . . . 31

II.1 Principaux attributs lors d’un 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 Differentes etapes d’analyses de l’ASQ . . . . . . . . . . . . . . . . . . . . . . . . . 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 d’administration 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 l’en-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.) Authentification . . . . . . . . . . . . . . . . 88

IV.7 Paquet ESP en Mode Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

IV.8 Paquet ESP en Mode Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

IV.9 Protocole Diffie-Hellman - www.plenz.com . . . . . . . . . . . . . . . . . . . . . . . 92

- 7 -

Remerciements

Je voudrais en tout premier lieu adresser mes sinceres remerciements a Yvan Vanhullebus, qui

a bien voulu me faire l’honneur d’accepter de superviser mes travaux au sein de NETASQ. Son

attention et sa disponibilite, dont j’ai use et abuse, m’ont ete d’une 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 j’ai pu cotoyer, de pres ou de loin, a NETASQ et

en particluer, a l’ensemble des equipes du laboratoire R&D. M’avoir acceuilli avec cette amabilite

et gentillesse qui les caracterisent m’ont ete d’un reel reconfort tout au long de cette periode. Etre

entoure de personnes extremement competentes dans leur domaine n’a fait qu’accroıtre mon envie

de progresser et d’apporter ma minuscule petite pierre a l’edifice. Que ce soit a travers l’ambiance

chaleureuse au sein de la societe, ou encore a travers ces dejeuners copieux, propres a ces chers

ch’tis, rendant souvent les apres-midi compliques, j’y ai passe de tres agreables moments.

Un grand merci a Abdou Guermouche d’avoir accepte d’etre rapporteur et a Emmanuel Fleury

pour sa disponibilite et sa reactivite a l’universite. L’ensemble des remarques dont ils m’ont fait

part m’ont ete d’un grand secours.

Une pensee pour l’ensemble de mes amis qui m’ont toujours aide, encourage et soutenu, dans

les bons moments comme dans les mauvais. Leur bonne humeur et joie de vivre m’ont ete d’un

reconfort inestimable. Qu’ils trouvent ici ma plus profonde gratitude.

Un immense merci a ma famille, mes parents, qui m’ont permis de poursuivre dans la voie qui

m’interessait et qui m’ont toujours aide a aller de l’avant, et enfin, a celle qui m’a soutenu sans

faille aucune et sans qui je ne serai surement pas la aujourd’hui, 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, qu’il s’agisse de re-

lier des reseaux d’agences et de sucursalles par l’Internet, ou de proteger des reseaux difficilement

securisables comme le WiFi.

De plus avec l’apparition du nomadisme, de plus en plus de personnes cherchent a pouvoir acceder

aux ressources internes de l’entreprise de maniere securisee de l’exterieur. 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 flux, et transparente pour l’utilisa-

teur, bases sur des VPN/IPSec en particulier. Plus generalement, NETASQ fournit des solutions

de securite, d’antivirus ou de pare-feux a des entreprises de tailles differentes, allant de la petite

PME aux grands comptes ou encore a l’Armee Francaise.

Le module VPN/IPSec NETASQ propose aujourd’hui embarquer l’ensemble de le configuration

reseau necessaire aux clients nomades pour qu’ils puissent acceder aux ressources internes de l’en-

treprise. Ce module est destine a etre ameliore, notamment par l’integration d’une extension IPSec

appellee Mode Configuration. Cette extension permet d’envoyer cette configuration reseau au client

nomade de maniere securisee, dynamiquement a la volee, pour que celui ci n’aie plus a embarquer

ces informations de maniere statique sur sa machine. D’autre part, cette integration permettra

d’alleger la charge de l’administrateur qui n’aura plus a maintenir individuellement l’ensemble du

parc des machines nomades de son entreprise.

Apres 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 afin de guider le

lecteur, averti ou pas.

NETASQ en quelques mots . . .

Cree en 1998, NETASQ est l’une des societes europeennes majeures sur le marche de la securite

informatique dont le siege social est a Villeneuve d’Ascq 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 unifiee par les appliances UTMs firewalls, la detection des

vulnerabilites par SEISMO ou encore le filtrage et la protection des messageries par les boitiers

MFILTRO.

NETASQ commercialise donc toute une gamme de solutions de securite unifiee (UTM). D’autre

part, l’ensemble des UTMs NETASQ integrent l’ASQ (Active Security Qualification), technologie

de prevention d’intrusion en temps reel protegee par plusieurs brevets.

NETEASQ a ete presente des le debut en Europe, notamment en Belgique, en Italie et au Roy-

aume uni. Aujourd’hui presente dans plus de cinquante pays, par l’intermediaire de partenaires

certifies, elle apporte des solutions adaptees aux marches locaux.

Ces clients viennent de secteurs et de tailles tres variees, des petites entreprises jusqu’aux grands

comptes comme Orange Business Services ou Portugal Telecom.

A la pointe de l’innovation technologique, toujours a l’affut des dernieres avancees en termes

de securite, integrant sa technologie de prevention ASQ sur l’ensemble de sa gamme, les raisons

faisant de NETASQ une societe en securite informatique en avance sur son temps ne manquent pas.

Certifiee par plusieurs organismes, NETASQ a, entre autres, ete recompensee par le Fast 50 en

France pendant deux annees consecutives. Elle a en outre recu la certification internationale des

Criteres Communs V2.2 au niveau EAL2+ (norme ISO 15408 et ISO 18045). Les UTMs

sont testes dans des conditions reelles d’exploitation par des appliances SPIRENT.

Enfin, les retours des clients etant revelateurs de la qualite des produits d’une societe, on peut

notamment citer Sebastien Truttet, responsable des infrastructures du groupe IS Altran : (( Nous

avons decide de supprimer les pare-feux de l’autre fabriquant et de n’utiliser que des pare-feux

NETASQ comme barriere 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 apres vente )).

- 11 -

Objectifs du stage

Le module VPN/IPSec du firmware NETASQ est base sur le projet ipsec-tools, sous licence

BSD. ipsec-tools est constitue de setkey, utilisaire de manipulation et d’injection 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 l’extension IKE Mode Configuration dans le

firwmare NETASQ. Cette extension permet d’envoyer les informations de configuration reseau

aux clients mobiles nomades. On appelle ces clients des road warriors, ils ont la particularite de ne

pas avoir d’adresse IP fixe connue de la passerelle.

Cette integration pourrait se faire en plusieurs etapes :

– Dans un premier temps, prendre en main l’environnement de travail sous FreeBSD, et avoir

une pile IPSec operationnelle.

– Etudier les extensions IKE XAuth, Hybrid et Mode Configuration, puisque les trois extensions

sont activees par une seule option de racoon.

– Evaluer l’implementation actuelle du Mode Configuration d’ipsec-tools, a travers une lecture

et un audit de code, une batterie de tests destines a confirmer ou infirmer la stabilite. Le

cas echeant, modifier le code d’ipsec-tools afin de corriger d’eventuels bugs ou erreurs de

conception et d’en ameliorer les performances.

– Prendre en main les UTMs NETASQ, etudier les differentes fonctionalites et modules disponibles

et se familiariser avec le firmware NETASQ.

– Effectuer un travail de conception avec l’ensemble de l’equipe R&D afin d’etendre le fichier

de configuration VPN NETASQ pour y integrer le Mode Configuration.

– Implementer les differentes librairies.

– Effectuer les premiers tests pour valider l’implementation.

– Effectuer des tests beaucoup plus pousses avec l’equipe de Qualification, notamment des tests

de performances sur des SPIRENT et des tests de non-regression.

– Repartir sur un travail de conception avec l’equipe IHM afin qu’elle puisse integrer les boutons

et/ou fenetres Mode Configuration de la maniere la plus adequate possible compte tenu des

contraintes de racoon, mais egalement de la maniere la plus ergonomique possible pour le

client final.

Le Mode Config, si les objectifs sont atteints, sera disponible en tant que fonctionalite option-

nelle dans la future version du firmware NETASQ.

- 12 -

Plan du rapport

Ce rapport presente l’ensemble du travail realise sur ces six derniers mois, a travers essentielle-

ment quatre chapitres qui refletent le fil directeur que j’ai suivi durant le stage :

Chapitre 1 : IPSec Ce chapitre presente les protocoles IPSec, leur fonctionnement, leur design

et la maniere dont ils sont deployes. Cette etude permettra de mieux finaliser l’ensemble des

tests realises sur IPSec et le Mode Configuration en particulier.

Chapitre 2 : Extensions IPSec Ce chapitre decrit les extensions XAuth, Hybrid et Mode Con-

figuration. Ces extensions permettent d’avoir une authentification supplementaire durant la

phase de negociation (Hybrid et XAuth) et de transmettre les informations de maniere

dynamique et securisee (Mode Config). Une section est egalement consacree a certaines

problematiques de securite posees par les deploiements reel d’IPSec.

Chapitre 3 : UTM NETASQ On etudie, dans ce chapitre, les fonctionalites des firewalls NE-

TASQ. Une description du fonctionnement de l’ASQ permet de mieux comprendre le firmware

NETASQ.

Chapitre 4 : Integration du Mode Config On presente ici l’ensemble de nos travaux, apres

avoir pris en main l’environnement dans son ensemble (etude IPSec, prise en main des UTMs,

etude sur le firmware, etc). Le fichier de configuration NETASQ est etendu et les champs

Mode Configuration ajoutes. Une batterie de tests finaux finissent l’integration.

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 trafic au niveau IP. Il a ete

initiallement developpe au sein du projet KAME pour IPv6, puis backporte a IPv4.

IPSec fournit notamment la confidentialite des donnees qui transitent, leur authen-

tification, leur integrite en mode non-connecte et une protection contre le rejeu. Il

permet ainsi de proteger l’ensemble 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 flux sont chiffres et/ou signes par des algorithmes cryptographiques a cle secrete, a

travers deux protocoles : AH assurant l’authentification et l’integrite des donnees et ESP

assurant principalement leur confidentialite mais permet de les authentifier egalement.

L’echange et le renouvellement de l’ensemble 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 Diffie-Hellman

notamment.

Les parametres d’une politique de securite (identite de l’hote, algorithmes a utiliser, etc)

sont stockes dans une Security Association (SA). L’ensemble des SA sont alors stockees

dans une base de donnees de SA appellees Security Association Database (SAD).

Enfin, les differentes 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 Presentation

I.1.1 Champ d’action d’IPSec

En matiere de securisation des echanges sur un reseau (a fortiori sur un reseau TCP/IP), les

services disponibles peuvent etre relativement differents suivant la couche de la pile reseau dans

laquelle ils operent. On peut citer :

– Les protections au niveau applicatif integres dans l’application en elle meme.

– Les protections au niveau de la couche transport (TCP, UDP...) en utilisant les protocoles

SSL/TLS et OpenVPN pour l’etablissement de tunnels SSL.

– Les protections au niveau de la couche liaison avec par exemple des tunnels PPTP.

Quant a IPSec (Internet Protocol Security), il definit une collection de protocoles destines a

securiser l’ensemble du trafic sur un reseau repute non securise, typiquement a travers l’Internet.

En effet, le protocole IP tel qu’il a ete concu ne prevoit pas la protection et la securisation des

donnees transmises. IPSec definit une extension d’IP destine a palier a ce manque. Il intervient

au niveau de la couche 3 - Reseau - du modele OSI (cf. Fig I.1) en securisant les flux IP. Il opere

donc de maniere totalement transparente pour l’utilisateur, moyennant le temps de latence du aux

negociations avec l’hote distant et aux traitements des paquets du point de vue cryptographique,

les algorithmes de chiffrement et d’authentification etant gourmands en ressources. Le support

d’une pile IPSec est optionnel pour IPv4, mais obligatoire pour toute implementation conforme

d’une pile IPv6. Normalise pour la premiere fois en 1998 dans la RFC 2401, l’architecture IPSec a

connu bien des evolutions en une decenie, qu’il s’agisse de la pile IPSec noyau ou des demons IKE

de negociation de cles ou de manipulation de regles de SPD.

I.1.2 Historique

Les piles IPSec

Une des toutes premieres implementations d’IPSec fut celle du projet KAME. Ce projet re-

groupait pres d’une dizaine de grosses compagnies japonaises, dont Fujitsu, Hitachi, NEC ou en-

core Toshiba, dans le but de fournir une implementation d’une pile IPv6, IPSec et IPMobile pour

les systemes BSD. Les systemes qui ont integre la pile KAME/IPSec s’avereront etre, par la suite,

FreeBSD et NetBSD. Dans le meme temps, il se trouve qu’OpenBSD avait deja implemente sa pro-

pre pile IPSec depuis la version 2.1 datant de 1997, avec ses differents avantages et inconvenients. Le

principal avantage de la pile IPSec d’OpenBSD etait l’integration de l’acceleration cryptographique

materielle en natif, permettant d’accroıtre considerablement les debits et les performances.

Concernant les systemes d’exploitation bases sur un noyau Linux, la toute premiere imple-

mentation d’une pile IPSec fut realisee par le projet FreeS/WAN dont la derniere version, 2.06,

- 15 -

I.1. PRESENTATION

Transport : TCP, UDP

Applications

Liaison, Physique

IPSec

IPSec

AnciennesPiles IPv4

Piles IPv4

IPSec

Intégrant

Récentes Pile IPv6Intégrant

NativementIPSec

Fig. I.1 – Positionnement d’IPSec 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 effet, a l’horizon 2002, deux developpeurs du noyau Linux, A. Kuznetsov et D. S. Miller ont

entierement implemente une pile IPSec en s’inspirant des des travaux du groupe USAGI IPv6.

Cette pile est celle qui est aujourd’hui integree en natif dans les noyaux 2.6.x.

Sur FreeBSD, la pile integree dans le noyau fut a l’origine la pile KAME/IPSec. Toutefois, un

portage de la pile IPSec d’OpenBSD integrant l’acceleration cryptographique materielle a ete

realise, ce qui a donne la pile FastIPSec. Deux piles IPSec ont alors ete maintenues, et lorsque

l’ensemble des fonctionalites presentes dans KAME/IPSec l’ont 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

Parallelement au developpement des differentes piles IPSec, il etait necessaire, comme nous le

verrons plus tard, d’avoir des demons s’executant une espace utilisateur afin de manipuler, config-

urer, maintenir, administrer les differentes configurations et politiques a appliquer aux flux ; comme

par exemple l’authentification du site distant, l’echange 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 -


noyau, et il est possible d’utiliser n’importe quel demon sur toutes1 les piles IPSec decrites plus

haut. Nous verrons un peu plus tard pourquoi ce n’est pas totalement vrai, puisque l’interfacage a

travers lequel ils communiquent avec le noyau n’offre pas autant de requetes qu’il serait souhaitable

d’en avoir.

Ainsi, le projet KAME disposait de son propre demon, racoon, repris plus tard par le projet

ipsec-tools. C’est sur ce projet qu’est base en grande partie le stage. D’autre part, OpenBSD avait

implemente son demon en parallele de la pile, isakmpd aujourd’hui encore integre dans OpenBSD

4.x. Enfin, pour les systemes 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 aujourd’hui tres largement deploye, en particulier pour la mise en place de VPNs2,

afin de securiser les echanges entre sites distants. L’avantage par rapport a d’autres solutions de

tunnelling comme OpenVPN, base sur SSL/TLS securisant TCP, reside dans la totale transparence

au niveau de l’utilisateur et la securisation de l’ensemble des couches basees sur IP, notamment

l’ensemble des couches de transport comme TCP et UDP.

Les implementations proprietaires

Toutes les implementations IPSec ne sont en effet pas OpenSource. Des grands comptes comme

Microsoft ou Cisco possedent aujourd’hui leur propre implementation de pile IPSec. Bien qu’IPSec

soit un moyen extremement robuste afin de transmettre du trafic chiffre, il n’en reste pas moins

vrai que l’interaction avec d’autres piles IPSec pose par moments des problemes de compatibilites.

I.1.3 Pourquoi deployer IPSec ?

Qu’il s’agisse de l’ensemble des services de securite fourni, ou de la flexibilite dans le deploiement,

ou encore du cout moindre par rapport a des lignes dediees, les VPN/IPSec sont de plus en plus

presents dans l’architecture reseau des entreprises.

Services de securite

Le pannel de services disponibles sous IPSec est assez varie ce qui lui permet d’etre tres flexi-

ble lors du deploiement de topologies reseaux securisees. On regroupe ici quelques mecanismes de

securite disponibles :

Authentification des correspondants : Il s’agit d’une authentification a double sens ou chaque

extremite s’assure de l’adresse de son correspondant. Il s’agit principalement des adresses IPs

des machines deploiyant IPSec et non pas des reels utilisateurs des dites machines. Nous ver-

rons la maniere dont les extentions ISAKMP/XAuth et ISAKMP/Hybrid permettent de remedier

a cela en offrant une authentification forte supplementaire des utilisateurs en plus de celle

1sous reserve que les demons soient bien en environnement compatible, racoon ne fonctionnera bien entendu pas

sur une architecture de type Win322VPN :Virtual Private Network, ou Reseaux Virtuels Prives (RVP)

- 17 -

I.1. PRESENTATION

des machines, notamment pour les clients mobiles possedant une IP dynamique.

Authentification des flux : Il s’agit de verifier que les flux qui circulent dans le tunnel ont bien

ete emis et/ou sont bien a destination de l’une ou l’autre des extremites. IPSec dispose prin-

cipalement de methodes de hachages afin de realiser cette operation, a travers le protocole

AH et/ou ESP.

Confidentialite des flux : Le payload des paquets IP est entierement chiffre a l’aide d’algo-

rithmes cryptographiques a cle secrete, envoye a travers le tunnel et dechiffre une fois arrive

a destination.

Integrite des flux : Lorsqu’un paquet IPSec3 subit une quelconque modification lors de son

trajet, elle est detectee et le paquet est ignore. L’integrite en mode non-connecte permet de

detecter une quelconque modification d’un datagramme individuel, mais pas sur l’ordre des

datagrammes, leur ordonnancement, ou la perte de paquets ou l’on parle d’integrite en mode

connecte. Cela protege les flux de toute alteration qu’ils peuvent subir et permet notamment

de se premunir contre des attaques actives. Nous verrons pourquoi ceci est tres problematique

lorsqu’il s’agit de traversser des equipements NAT4 et comment l’extension IPSec NAT-T per-

met d’y remedier.

Protection contre le rejeu et l’analyse de trafic : Bien qu’un attaquant ne puisse pas dechiffrer

ou modifier un paquet chiffre, il pourrait juste le capturer et le renvoyer plus tard. IPSec per-

met de se proteger contre ce type d’attaque par rejeu de paquets. Ceci apporte egalement

une protection supplementaire contre les eventuelles ecoutes et analyses de trafic puisque

l’ensemble du payload etant chiffre, 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 n’est lie a aucun algorithme cryptographique en parti-

culier. Il supporte de multiples algorithmes a cle secrete, et est capable de negocier dy-

namiquement les algorithmes supportes par tel ou tel hote tentant d’etablir une connexion.

Bien que cette souplesse de negociation soit avant tout un avantage, nous mettrons l’accent

sur le fait que cela peut etre d’un niveau de securite moindre lorsque certains parametres

ne sont pas choisis de maniere adequate. A titre d’exemple, un proposal check obey peut

faire en sorte que les hotes negocient le chiffrement DES alors que les deux supportent AES.

Services de flexibilite

Les passerelles VPN/IPSec sont typiquement deployees dans des entreprises qui disposent de

locaux geographiquement eloignes les uns des autres. L’ensemble des services disponibles sur le site

central doivent egalement l’etre sur les differents sites distants. Outre une grande souplesse dans

3paquet AH ou ESP4NAT - Network Address Translation

- 18 -


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 Relay5, ou sur ATM . Avec l’apparition de nouveaux services necessitant de plus

en plus de debit, il a fallu choisir entre multiplier les lignes entre les sites ou trouver d’autres

alternatives securisees et de debits acceptables. D’ou le compromis trouve d’adopter des so-

lutions basees sur IPSec.

Reduction des couts : Avec la diminution des couts des abonnements des fournisseurs d’acces,

avoir une ligne dediee coute beaucoup trop cher en terme de deploiement et de maintenance.

De plus en plus d’entreprises se tournent vers des fournisseurs d’acces et securisent leur flux

plutot que d’acheter des lignes dediees.

Disponibilite, adaptabilite : IPSec peut etre deploye en tout point disposant d’un acces reseau.

Tandis que la plupart des societes possedent deja des lignes de communication dediees entres

leurs differents sites distants, le debit est bien souvent insuffisant lorsqu’il s’agit d’acceder

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 differents sites,

en y faisant passer les informations les moins critiques, alors que les donnees tres sensibles

continuent a etre acheminees a travers le WAN dedie.

I.2 Vue generale des protocolesIPSec regroupe toute une suite de protocoles, de specifications, d’acronymes decrits dans

differentes RFCs se referencant les unes aux autres, ce qui rend sa prise en main relativement

delicate de prime abord. On presente ici une vue d’ensemble de ces differents protocoles afin de

mieux comprendre ce que font les differents modules avant d’approfondir 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 modele OSI) est

particulierement adapte pour la communication entre deux hotes. Cela presuppose donc l’installa-

tion et la configuration prealables d’une pile IPSec sur les deux systemes.

En mode Transport, les mecanismes de securisation viennent s’intercaler entre les couches

Transport et Reseau : les entetes IPSec appropriees (AH et/ou ESP) sont appliques apres que les

5Relai 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 GENERALE 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 protege donc l’ensemble des donnees au dessus d’IP.

IP Hdr

IP Hdr

Data

IPSec Hdr Data

A Protéger

Fig. I.3 – En-tete en Mode Transport

Ainsi, le principal defaut de ce mode reside-t-il dans l’absence de masquage d’adresses 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 maniere securisee a travers un reseau peu sur comme l’Internet.

L’ensemble des postes n’ont alors nullement besoin d’installer et/ou de configurer des systemes

supportant IPSec, seules les deux passerelles en sont dotees.

En mode Tunnel , les traitements IPSec sont appliques apres que l’ensemble 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 -


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 Protéger

New

IP Hdr

Fig. I.5 – En-tete en Mode Tunnel

Comme on peut le voir, les adresses source et destination sont entierement masquees, les corre-

spondants reels ne sont pas visibles, et l’on dispose d’une protection contre l’analyse de trafic. 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 trafic :

AH : Le protocole AH - Authentication Header.

ESP : Le protocole ESP - Encapsulating Security Protocol.

- 21 -


Protocole AH

AH (Authentication Header) est utilise principalement pour fournir une authentification et

un controle d’integrite des donnees.

AH ne permet pas de chiffrer les paquets. Il ne doit donc pas etre utilise lorsque l’on souhaite avoir

la confidentialite des donnees.

AH protege l’ensemble des donnees, ainsi que l’ensemble des en-tetes non modifiables (numero de

protocole, port de destination, etc). Il n’offre, en revanche, pas de protection sur l’ensemble des

en-tetes susceptibles d’etre modifiees lors du trajet du paquet comme par exemple le champ TTL

ou le champ ToS de l’en-tete IP.

Suivant le mode Transport ou Tunnel, la figure I.6 decrit la maniere dont AH encapsule les donnees.

IP Hdr

IP Hdr

Data

AH DataNew

IP Hdr

Authentifié sauf les champs modifiables dans New IP Hdr

Paquet Original

AHIP Hdr Data

Authentifié sauf les champs modifiables dans IP Hdr

Mode Transport

Mode Tunnel

Fig. I.6 – Authentication Header - AH

Comme on peut le voir, AH protege l’ensemble des champs non-modifiables du paquet. Il peut

etre utile lorsque la confidentialite des donnees n’est pas recherchee d’une part, et d’autre part

lorsqu’une authentification forte du paquet est exigee. La transmission du resultat d’une election

ou les donnees sont destinees a etre publiques mais doivent provenir de source sure est un bon

exemple.

- 22 -


Protocole ESP

ESP est le deuxieme protocole definit dans la suite IPSec. Protocole le plus repandu dans la pra-

tique, ESP (Encapsulating Security Payload) offre egalement la confidentialite des donnees.

L’ensemble des donnees sont alors chiffrees avant detre transmises, suivant differents mecanismes

et protocoles que l’on detaille a la section I.2.3.

ESP chiffre, d’une part, le champ Data des paquets suivant un ensemble de parametres negocies

au prealable avec l’hote distant, et d’autre part, utilise des mecanismes d’authentification (comme

HMAC) afin de fournir une protection anti-rejeu ou encore une integrite des donnees. A ce titre,

ESP est un protocole tres complet, offrant toute une panoplie de protections allant du simple

chiffrement des donnees jusqu’a leur authentification en plus.

La figure I.7 decrit la maniere dont ESP encapsule l’ensemble des champs des paquets.

IP Hdr

IP Hdr

Data

DataNew

IP HdrESP

IP Hdr Data

CHIFFRE

Mode Transport

Mode Tunnel

Hdr

ESPTrailer

ESPAuth

AUTHENTIFIE

ESPHdr

Trailer AuthESPESP

CHIFFRE

AUTHENTIFIE

Fig. I.7 – Encapsulating Security Payload - ESP

- 23 -


AH et ESP

Il est tout a fait possible d’utiliser les deux protocoles conjointement, meme si cela reste tres

peu utilise. Lorsque l’on recherche a avoir une confidentialite des donnees et une authentification

complete du paquet, il est possible d’utiliser dans un premier temps ESP afin de chiffrer les donnees

et authentifier les champs concernes, puis d’aposer AH sur le paquet ESP obtenu. On a ainsi une

authentification complete de tous les champs du paquet et un chiffrement des donnees.

Ce mode de fonctionnement est neanmoins tres lourd et gourmand en bande passante. En pra-

tique, le mode Tunnel ESP reste tres securise et offre l’ensemble des services de securite mentionnes

plus haut.

I.2.3 Etablissement d’une negociation IPSec

Phases IPSec

Il existe deux facons d’etablir des echanges chiffres 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 l’ensemble des parametres necessaires et assure le

renouvellement periodique des cles cryptographiques mises en jeu et leur echange de maniere

securisee.

Statique : Principalement maintenue pour des raisons de compatibilites, ce mode de (( negociation ))est

tres obsolete et presente quelques failles de securite, puisque les cles sont non seulement sta-

tiques, donc jamais renouvellees. Ainsi, les tentatives d’attaques par brute force ont plus de

chances d’aboutir. Cette methode de negociation ne sera pas abordee dans le cadre de ce

rapport.

Une negociation IPSec dynamique, c’est a dire utilisant un demon de negociation IKE, se fait

principalement en deux etapes ou phases.

Phase 1 : La premiere phase sert a authentifier mutuellement les deux correspondants et d’etablir

un canal de transmission securise. Par la suite, l’ensemble de la configuration et parametres

necessaires sont negocies afin de proteger les differents echanges (les duree de vie, les infor-

mations diverses, etc). Lorsque cette phase est terminee, les deux correspondants disposent

d’une ISAKMP SA. Il s’agit d’un canal de transmission securise par lequel les deux cor-

respondants vont s’echanger differentes informations, y compris les cles cryptographiques

destinees a chiffrer et/ou authentifier le trafic des donnees proprement dites.

Phase 2 : La deuxieme phase permet essentiellement de se mettre d’accord sur les protocoles

cryptographiques a utiliser pour chiffrer et authentifier tel ou tel type de trafic 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 -


A partir de ce moment, les deux hotes peuvent alors s’echanger du trafic de maniere securisee.

Les SAs sont developpees plus en details dans la section I.3.2.

Politiques et Associations de securite

Etant donne un trafic qui doit etre chiffre avec tel protocole, un autre avec tel protocole et un

dernier ne devant pas l’etre, comment ce trafic est-il effectivement traite ?

Lorsque les paquets arrivent (cf Fig I.8) entre la couche Transport et la couche Reseau, le noyau

verifie tout d’abord si ce trafic doit subir un traitement IPSec ou non en fonction de differents

champs contenus, entre autres, dans l’en-tete IP. Pour cela, le noyau cherche une politique de

securite correspondant au paquet, dans une base de politiques (SPD) prealablement configuree par

l’administrateur. La SPD permet de savoir si un type de trafic doit subir un traitement IPSec ou

pas. Si ce n’est 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 ClairIP

IPSecS P D

Consulte

IPSec : Oui / Non ?

S A D

SA1SA2SA3...

Consulte

Pqt en Clair

Tunnel IPSec

Pqt Chiffré

I K E

Maintient, Négocie

Modifie, Supprime

Demande de

Création de SA

Administrateur

logs

Configure

Fig. I.8 – Synoptique de Fonctionnement IPSec

Si c’est 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 l’ensemble des SAs des politiques IPSec actives. Dans le cas ou

le noyau trouve une SA correspondante, il va y lire les parametres necessaires (protocole a utiliser,

- 25 -

I.3. DESIGN ET ARCHITECTURE DE SECURITE

taille des cles, etc) et traiter le paquet en consequence (ESP ou AH, Tunnel ou Transport) avant

de l’envoyer.

Si la SA n’est pas trouve, le noyau demande au demon IKE – le demon racoon du projet

ipsec-tools en locurrence – de negocier une SA avec l’hote distant. Durant cette negociation,

l’ensemble des paquets devant subir un traitement IPSec a destination de cet hote sont ignores.

Ceci explique le temps de latence lors de la premiere communication a travers un tunnel IPSec.

Le detail et l’etude approndie des protocols AH et ESP est disponible dans l’annexe A.

Maintenant que l’on a etudie les protocoles de transmission d’IPSec, il s’agit de voir comment

les differents parametres, clefs de chiffrement, protocoles, identites des correspondants, etc. sont

geres dans le systeme.

Comment se fait le renouvellement periodique des cles ?

Comment detecte t-on lorsque l’hote en face ne repond plus ? Que faire dans ces cas la ?

Faut-il garder les parametres en esperant que l’absence 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 securite

L’architecture complexe d’IPSec repose sur le principe d’Association de Securite. Il s’agit d’une

structure contenant un ensemble de parametres negocies avec l’hote avec lequel l’on souhaite etablir

une connexion IPSec. Ces differentes associations sont stockees dans des bases de donnees d’asso-

ciations, afin de retrouver rapidement celle qui correspond a tel ou tel hote.

I.3.1 Extremites de tunnel, de trafic

On appelle extremite de tunnel (cf. Fig I.9) les deux extremites entre lesquelles le trafic sera

effectivement chiffre et/ou signe. Il s’agit des adresses des deux passerelles IPSec dans le cas d’une

configuration en mode tunnel ou de l’adresse des deux correspondants dans le cas d’une configu-

ration en mode transport.

On appelle extremite de trafic (cf. Fig I.9) les sous-reseaux qui sont autorises a emprunter le

tunnel de part et d’autre de la passerelle. Les extremites de trafic constituent un point essentiel de

l’architecture IPSec : un sous-reseau bien que faisant partie du reseau interne de l’entreprise, s’il

n’est pas autorise a envoyer du trafic IPSec vers telle ou telle passerelle sera detecte au moment

de la verification sur l’extremite de tunnel.

- 26 -


Fig. I.9 – Extremites de tunnel, de trafic - www.cisco.com

I.3.2 Associations de Securite

Les SAs representent une structure au coeur de toute connexion IPSec. Il s’agit d’un ensemble

ou d’une collection de parametres permettant d’etablir 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 d’IPSec, il faut pouvoir distinguer la maniere

dont telles ou telles donnees sont chiffrees et/ou authentifiees de telles ou telles manieres. 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 chiffrement, la periode de renouvellement des cles, etc.

Elles sont identifiees par un numero de SPI (Security Parameter Index). Le SPI permet

de savoir comment un paquet arrive sur l’interface ipsec doit etre authentifie et/ou dechiffre en

allant consulter les parametres de la SA a laquelle il correspond ; ou alors, il permet de connaıtre

les protocoles et cles a utiliser lors du chiffrement d’un paquet a envoyer a un hote donne.

Le concept de SA permet d’avoir differents degres de chiffrement et/ou d’authentification entre

deux, voire plusieurs hotes. A titre d’exemple, si l’on considere deux filiales ou l’acces aux services

de mail est moins critique que l’acces a des applications financieres. Bien que le tunnel IPSec soit

physiquement le meme, il existera deux politiques de chiffrement, donc deux SAs de chaque cote

afin de chiffrer les paquets a destination des applications financieres a l’aide de methodes tres ro-

bustes (donc plus couteuses en temps et en ressources), et les flux a destination des services mails

a l’aide de chiffrement d’un degre moindre.

Les differentes SAs negociees avec les differents hotes sont stockees dans une base de donnees

- 27 -

I.4. PHASES DE NEGOCIATION

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 s’il doit etre envoye en clair sur le reseau. Il existe pour

cela une table d’entrees de politiques de securite, pouvant etre assimilee a une table de routage

interne, permettant de savoir a quel type de traffic est destine un paquet.

Ces differentes politiques sont stockees dans une SPD (Security Policy Database) qui est

donc consultee a chaque paquet sortant ou entrant. L’administrateur a la charge de configurer

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.

Lorsqu’une SA n’existe pas ou n’est plus valide et qu’un paquet doit etre envoye au travers

d’une connexion IPSec, le noyau demande a un demon IKE de negocier une SA avec l’hote distant.

I.4 Phases de negociation

La negociation d’une SA se fait principalement en deux phases. A l’issue de la Phase 1, une

ISAKMP SA est cree. A partir de ce moment, les deux entites disposent d’un tunnel securise et

peuvent negocier les parametres de securisation des donnees en elles-memes : il s’agit de la Phase

2 et permet d’etablir une IPSEC SA.

I.4.1 Phase1 : ISAKMP SA

La Phase 1 represente la negociation initialle afin d’etablir la ISAKMP SA 6 entre les deux

hotes. Elle peut se faire de maniere robuste lorsque les conditions le permettent (notamment lorsque

l’adresse IP du correspondant est connue a l’avance), il s’agit dans ce cas du Main Mode ; ou elle

peut se faire par l’Aggressive Mode qui ne presuppose pas la connaissance de l’IP de l’hote.

La Phase 1 commence par envoyer la liste des propositions d’authentification, de chiffrement

ainsi que les durees de vies a negocier. Suivant la maniere dont est configure l’hote distant, la

negociation peut etre ou ne pas etre acceptee.

La deuxieme etape consiste a calculer des cles de session par l’intermediaire d’un echange Diffie-

Hellman. Une fois les cles de sessions etablies, tout le traffic a partir de ce moment est chiffre.

6Contrairement a une IPSEC SA, la ISAKMP SA est bidirectionnelle

- 28 -


Authentification des correspondants

Il faut, a present, authentifier les deux correspondants. racoon dispose de plusieurs methodes

d’authentification, dont deux tres couramment utilisees :

Pre Shared Key : Il s’agit d’une cle pre-partagee a l’avance par les deux hotes (par hote, on

entend une adresse IP, un login ou encore un FQDN). A noter qu’a l’heure actuelle, dans le

demon racoon, il n’est pas possible de configurer une cle qui soit partagee par un ensemble

d’utilisateurs ou par tout le monde (appelle aussi Wildcard ou Goup Password chez TM), ce

qui presente des risques de securite non negligeables. C’est la methode d’authentification la

plus frequemment utilisee car la plus simple a mettre en place. Neanmoins, comme nous le

verrons dans le chapitre suivant, l’authentification en pre shared key est tres deconseillee

voire a proscrire lorsqu’il s’agit d’authentifier des hotes de types Road Warrior, c’est a dire

ceux dont l’adresse IP n’est pas connue a l’avance.

Certificats X509 : Utilisant une Public Key Infrastructure, c’est une methode d’authentification

par certificats numeriques X5097. Il s’agit de la methode la plus sure actuellement disponibles

a au moins deux conditions : avoir une CRL8 a jour tres regulierement et en ce qui concerne

les Road Warrior, avoir deux CA differentes, l’une pour signer le certificat de la passerelle

IPSec et la deuxieme pour signer les certificats utilisateurs.

Une fois l’authentification des correspondants achevee, chacun accuse de la bonne reception des

differents parametres et la ISAKMP SA est consideree comme etablie.

Main Mode - Aggressive Mode

L’etablissement de la ISAKMP SA peut se faire soit par six echanges (Main Mode) ou par

un couple d’echanges en moins (Aggressive Mode).

Le Main Mode (cf Fig. I.10) permet d’avoir la “ Protection des Identites ” des correspondants

(Identity Protection Mode) ! Les echanges des empreintes des differentes identites ne se font

qu’apres l’etablissement d’un secret commun partage par les deux entites : l’echange Diffie Hell-

man est fait au niveau 3 et 4 pour etablir la cle de session et l’echange des empreintes est faite au

niveau 5 et 6. L’identite et l’empreinte de l’identite sont tous deux chiffres avec la cle partagee. En

Main Mode avec une authentification en Pre Shared Key, comme les echanges 5 et 6 sont chiffres,

c’est l’adresse IP du correspondant qui fait office d’identifiant ; ce qui va devenir problematique

pour les road warriors puisque leur IP n’est a priori pas connue a l’avance !

L’ Aggressive Mode (cf Fig. I.11) en revanche ne supporte pas la “ Protection des Iden-

tites ”9 : les identifiants sont envoyes en clair sur le reseau. En effet, l’echange se fait avant

7Un certificat X509 est une methode d’authentification liant une cle publique a un nom ou une adresse email8CRL : liste de revocation mise a jour regulierement, elle a definir l’ensemble des certificats qui ne sont plus

valides.9Sauf lorsqu’il s’agit d’une authentification en Hybrid

- 29 -

I.4. PHASES DE NEGOCIATION

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

qu’un secret commun ne soit determine entre eux. L’empreinte d’authentification n’est pas chiffre,

contrairement au Main Mode et est envoye en clair. Des identites non protegees et une em-

preinte d’authentification non chiffree rend l’ Agressive Mode susceptible a des attaques de type

Man In The Middle (MITM) lorsqu’il est utilise de paire avec une authentification 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 l’empreinte non chiffree.

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 -


Chiffrement Hash PFS Lifetime IPSec Mode

AES SHA-1 Desactive 3600 sec Tunnel

DES MD5 Group 1 2h Transport

3DES Group 2 1 week

Blowfish Group 5

Fig. I.12 – Quelques exemples de parametres negocies lors d’une Phase 2

I.4.2 Phase2 : IPSEC SA

Apres la Phase 1, durant la Phase 2, les IPSEC SAs sont negociees par IKE, pour securiser le flux

de donnees en lui meme. Ces negociations sont deja chiffres et authentifies puisqu’elles reposent sur

la ISAKMP SA fraıchement 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 chiffrement, l’une pour le trafic entrant et l’autre pour le trafic sortant. L’avantage que

represente cette strategie est de doubler le travail de l’attaquant a l’ecoute du reseau, puisqu’il lui

faudra dechiffrer le trafic dans les deux sens.

Durant cette Phase sont negocies des parametres comme les algorithmes de chiffrement, de

calcul de signature, les cles de chiffrement ou encore les durees de vies des differentes SAs (cf Tab.

I.12).

Perfect Forward Secrecy

Le PFS - Perfect Forward Secrecy determine la maniere dont sont generees les cles de

chiffrement des differentes IPSEC SAs. Lorsqu’il est desactive, les cles de(s) IPSEC SA(s) sont

generees a partir de la cle principale de la ISAKMP SA correspondante. Lorsque l’on l’active, ces

cles ne sont plus dependantes de la cle principale, mais au contraire generees a partir d’un nouvel

echange Diffie 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.

L’activation du PFS permet d’accroıttre 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 Diffie Hellman sont bases sur des

exponentiations de taille non negligeable et sont de ce fait gourmands en ressources CPU. Il n’est

- 31 -

I.5. RESUME

pas impossible de constater une perte de performances par l’activation d’un group PFS trop grand.

I.5 Resume

IPSec constitue une suite de protocole de securisation du trafic au niveau IP. Il repose sur deux

protocoles : AH - Authentication Header et ESP - Encapsulating Security Payload. Les parametres

necessaires a l’utilisation 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 grace au protocole IKE

implemente dans differents demons, comme racoon utilise ici.

Lorsqu’un flux arrive au niveau IP, une base de donnees de politiques de securite - SPD est

consultee afin de savoir le type de securite a fournir au flux.

Le noyau recherche alors la SA correspondante, chiffre le paquet et l’envoie. Si la SA n’existe pas,

une demande creation est envoyee au demon IKE qui se charge de la negocier aupres de l’hote

distant.

Plusieurs modifications, evolutions, extensions ont ete apportee a differentes parties des proto-

coles IPSec depuis une dizaine d’annee. Certaines ont ete normalisees par l’IETF (bien qu’il faille

toujours supporter les drafts non RFC) et d’autres non. Les extensions IPSec les plus significa-

tives se concentrent d’une part sur l’authentification des tiers communiquants et d’autre part sur

la transmission d’informations internes a des hotes mobiles, de maniere securisee.

- 32 -

CHAPITRE II

Extensions IPSec et problematiques de securite

First they ignore you,

Then they laugh at you,

Then they fight you,

Then you win.

— Mahatma Gandhi

Resume :

Les extensions IPSec sont des modifications apportees au fur et a mesure afin d’ameliorer

non pas les protocoles en eux memes, mais plutot un certain manque de communication et/ou

d’authentification des deux hotes. Un des objectifs principaux du stage etant l’etude de ces

extensions, nous en approfondirons trois dont l’une est destinee a etre integree dans la pile

IPSec du firmware NETASQ.

XAuth : Extension principalement destinee aux clients mobiles, il permet d’avoir une

authentification forte du cote du client. On authentifie non seulement la machine, mais

egalement l’utilisateur.

Hybrid : Lorsque le mode hybrid est active, l’authentification des correspondants peut

etre asymetrique, c’est a dire utilisant des methodes d’authentification differentes des deux

cotes. Une passerelle IPSec pourrait s’authentifier par certificats tandis qu’un client mobile

en face par cle pre-partagee.

Mode-Config : Est une extension permettant de transmettre de maniere securiee et a

la volee certaines informations relatives a l’architecture interne des reseaux aux clients

mobiles en particulier. Lorsqu’un 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 locale1, ou encore des serveurs DNS et/ou WINS

internes. Cette extension est destinee a etre integree dans le module IPSec NETASQ.

D’autre part, si IPSec englobe une suite de protocoles tres robustes theoriquement,

nous verrons qu’elle presente quelques problematiques voire failles de securite lorsqu’elle

est deployee de maniere inapropriee, ou configuree de maniere bancale ; comme les SAs sta-

tiques, ou encore une mauvaise de gestion (pas de gestion du tout) de CRLs, l’utilisation

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 d’une adresse IP fixe connue a l’avance ;

et Passerelle le serveur ou la passerelle IPSec sur laquelle le client mobile souhaite etablir une

connexion. L’adresse IP de la passerelle est fixe et connue a l’avance du client.

II.1 Authentification XAuth

XAuth (Extended Authentication in IKE ) permet d’avoir un mecanisme supplementaire afin

d’authentifier le client, apres l’etablissement d’une ISAKMP-SA. Dans le cas ou XAuth est utilise

comme methode d’authentification du client, il est important que la passerelle ne fasse absolument

rien avant que XAuth n’ait correctement abouti. Ce point sera rappele a la section II.1, lors de la

description d’XAuth.

II.1.1 Principe et fonctionnement

XAuth est une methode extension IKE decrite dans le draft-beaulieu-ike-xauth-02.. Elle

permet d’avoir un complement d’authentification apres l’etablissement d’une ISAKMP-SA.

Il s’agit d’une extension permettant d’authentifier le client par diverses methodes (Radius,

OTP, Kerberos, LDAP, SecurID, etc). Pour signaler l’utilisation d’XAuth, celui ci dispose d’un

Vendor ID envoye a la passerelle lors de la negociation de phase 1. Il s’agit des 8 octets suivant :

VendorID = 0x09002689DFD6B712

Les types de messages utilises pour XAuth sont les memes que ceux utilises lors d’un 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 d’informations, et proteges par les parametres de negociation de

la ISAKMP-SA.

Nous reviendrons plus en details sur ce type d’echanges 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 afin d’authentifier 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. L’authentification 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 authentification demandant un Challenge apres l’in-

sertion d’une cle USB ou autre.

II.1.2 Notifications de type XAuth

Lors de l’etablissement de la ISAKMP-SA, la passerelle doit etre notifiee de l’XAuth, 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 PROBLEMATIQUES DE SECURITE

XAUTH-TYPE type d’echanges definis 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 l’utilisateur.

XAUTH-MESSAGE un message ascii en clair, un challenge par exemple.

XAUTH-CHALLENGE challenge au format texte.

XAUTH-DOMAIN domaine dans lequel l’utilisateur doit s’authentifier.

XAUTH-STATUS OK=1, FAIL=0, statut de l’authentification.

XAUTH-NEXT-PIN

XAUTH-ANSWER

Fig. II.1 – Principaux attributs lors d’un echange XAuth

peut se faire de deux manieres differentes :

Notification lors d’un echange de phase 1 Le client peut indiquer qu’un XAuth va suivre en

mettant une notification dans le payload de n’importe quel paquet de phase 1. A moins que

les deux entites supportent les mecanismes de calcul d’empreinte decrits dans le

draft-ietf-IPSec-ike-hash-revised-03.txt, ce payload n’est pas authentifie et ne doit

par consequent pas etre utilise.

Notification via les attributs de la ISAKMP-SA L’utilisation de XAuth est notifiee en don-

nant la methode d’authentification choisie dans les attributs de la ISAKMP-SA negociee

lors du premier echange (section proposal dans la section remote de racoon). Lorsque la

passerelle recoit une demande de XAuth dans les attributs de la ISAKMP-SA, aucun echange

a part XAuth n’est possible apres une phase 1 correctement negociee.

A choisir une implementation plutot qu’une autre, en plus des contraintes de comptatibilite, il

serait plus raisonnable de transmettre la notification de XAuth en tant qu’attribut specifique 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 entierement sur la ISAKMP-SA, et offre une authentification

complementaire du client uniquement sous reserve que la ISAKMP-SA ait ete negociee de maniere

- 35 -

II.1. AUTHENTIFICATION XAUTH

sure : un XAuth apres 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 l’authentification

en Group Password. Un XAuth, meme s’il est fait avec des methodes d’authentification

fortes a plusieurs facteurs, presente des faiblesses s’il est fait sur la base d’une ISAKMP-SA

ayant un faible niveau de securite.

Ainsi l’authentification 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 l’etablissement d’une

ISAKMP-SA, sous pretexte que l’authentification du client se fera de toute facon au moment de

l’echange XAuth qui s’en suit.

XAuth et . . .uniquement XAuth

Lorsque l’authentification de l’utilisateur inclut un echange XAuth, on doit considerer que la

phase 1 n’est pas completement finie (et donc que la ISAKMP-SA n’est pas encore etablie entre les

deux hotes) tant que XAuth n’est pas termine et valide. Une fois que l’utilisateur s’est correctement

authentifie – echanges XAuth termines et valides –, la ISAKMP-SA peut etre consideree comme

operationnelle et l’on peut alors commencer des echanges, par exemple, de type Mode Config ou

des negociations Quick Mode en phase 2.

D’autre part, avant que l’echange XAuth ne soit termine, l’utilisateur n’est pas encore completement

authentifie sur la passerelle. A ce titre, aucun echange ne doit survenir entre les deux hotes tant

que XAuth n’a pas abouti (c’est 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 ou XAuth se termine mais que l’authentification echoue pour une raison ou pour une

autre, aucune information n’aura ainsi ete transmise. Le dialogue s’arrete alors immediatement,

et la ISAKMP-SA correspondante est supprimee 2. En effet, si le Xauth n’est pas valide (i.e que

l’authentification echoue), l’utilisateur n’est toujours pas authentifie aupres de la passerelle ! Dans

ce cas, il n’est pas pertinent d’avoir une ISAKMP-SA avec ce client : elle doit donc etre supprimee.

XAuth et transmission d’informations sensibles

Puisqu’un echange Auth fait intervenir le client et la passerelle d’un cote, et la passerelle et

le serveur d’authentification de l’autre, il faut etre en mesure de maıtriser les deux parties, alors

que jusqu’ici, nous nous sommes uniquement interesses au cote public entre le client et la passerelle.

La transmission des informations relatives a l’authentification des utilisateurs doit se faire de

maniere securisee entre le client et la passerelle, mais egalement entre la passerelle et le

serveur qui authentifie !

L’echange de mots de passe ne se fait pas en clair entre le client et la passerelle IPSec, et

lorsque l’echange se fait de maniere chiffree, le recepteur est prealablement authentifie, en utilisant

2le draft preconise sa suppression

- 36 -


un Mode Hybrid par exemple, qui est developpe a la section II.2.

D’autre part, le transit d’informations entre le serveur qui authentifie et la passerelle IPSec

est egalement sensible, y compris sur un reseau local interne. Si les equipements d’authentification

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 maniere que si

les serveurs sont branches sur un HUB relie a plusieurs centaines de stations de travail, ou tout le

monde possede un acces potentiel aux donnees en les sniffant sur le reseau.

II.1.4 XAuth et le Group Password

La negociation d’une phase 1 en Aggressive Mode Pre-Shared-Key presente un faible niveau de

securite, meme lorsqu’un XAuth s’en suit.

Lorsque qu’une seule Pre-Shared-Key est utilise afin d’authentifier plusieurs utilisateurs ( !)

(methode connue egalement comme Goup Password, un mot de passe de "groupe"), il n’est plus

possible de garantir la securite des identifiants des utilisateurs legitimes s’y connectant, en partic-

ulier les road warriors, bien que ce type d’authentification soit la methode par defaut de quelques

clients VPN/IPSec.

La strategie adoptee par NETASQ a ete de ne pas proposer ce type d’authentification : les clients

mobiles auront un certificat X509 ou une cle RSA.

Pourquoi ce type d’authentification est-il si peu sur ?

Comme nous l’avons vu, lors de la negociation d’une phase 1 en Main Mode, les differents

idientifiants sont proteges (Identity Protection Mode), qu’il s’agisse d’une authentification par

Pre Shared Key ou par certificats X.509. Puisque l’empreinte d’authentification est chiffree, sa

provenance est determinee uniquement par l’IP de l’emetteur. Or, les road warrios n’ont, par

definition, pas d’adresse IP fixe.

En Aggressive Mode combine avec une authentification en Pre-Shared-Key, meme lorsque la

cle est uniquement partagee deux entites, rien n’empeche un potentiel attaquant ecoutant le trafic

reseau d’intercepter l’empreinte et d’en deduire la cle si jamais celle ci se revelait faible.

Une authentification en Pre-Shared-Key en Aggressive Mode, lorsqu’elle est destinee aux

road warriors, est encore plus vulnerable puisque la passerelle IPSec et l’ensemble des road war-

riors possedent la meme Pre-Shared-Key ! Lorsque la negociation se met en place, la passerelle

sait, dans le meilleur des cas, qu’elle parle a l’un des road warriors, elle n’a aucun moyen de savoir

precisement lequel. Certes, XAuth intervient apres l’etablissement de la phase 1, pour authentifier

le client.

Comme nous l’avons vu precedemment, l’authentification 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 d’une Pre-Shared-Key, une authentification supplementaire grace au XAuth n’y apporte

- 37 -

II.2. HYBRID-AUTH

pas un niveau de securite supplementaire puisque le niveau de securite de l’ensemble d’une chaıne

equivaut a celui de son maillon le plus faible !

Il serait, dans ce cas, envisageable d’attribuer une cle dediee a chaque utilisateur. Cette ap-

proche possede un inconvenient majeur : il n’est pas possible, a la reception du paquet, de savoir

quelle cle utiliser pour valider l’empreinte, puisqu’aucun nom d’utilisateur n’est transmis et que

l’adresse IP du client est dynamique. Pour utiliser l’authentification en cle pre-partagee, il devient

alors impossible de ne pas utiliser une cle de groupe.

D’autre part, on peut egalement envisager que le client soit legitime et qu’il negocie avec une

passerelle frauduleuse. Un road warrior n’a aucun moyen de savoir qu’il dialogue bien avec la

passerelle : un potentiel attaquant pourrait deja posseder la cle, et il pourrait a son tour negocier

avec la vraie passerelle, et ainsi, ecouter, intercepter, modifier, etc l’ensemble du traffic...Combine

avec Mode Config, ceci peut permettre a un attaquant de connaıtre l’ensemble de l’architecture

reseau interne, d’usurper des donnees, etc. La solution serait donc de transmettre un username lors

de la negociation...et ceci peut se faire en utilisant des certificats. Si le client en arrive a etre vic-

time d’une telle attaque MITM pendant un XAuth, celui ci dispose alors, non seulement d’un moyen

d’ecouter le traffic, mais egalement de pouvoir negocier autant de sessions IKE qu’il le desire, et

pour peu que le mot de passe de l’utilisateur soit le meme a differents endroits, l’attaquant peut

lire les mails de l’utilisateur, s’authentifier aupres de differents serveurs internes, acceder a des

informations confidentielles sur diverses base de donees, etc.

Lors d’une negociation de phase 1, on authentifie alors la passerelle dans un premier temps : le

client doit etre certain qu’il dialogue bien avec la passerelle legitime.

II.2 Hybrid-AuthHybrid Auth est une autre extension IKE decrite dans le draft-zegman-ike-hybrid-auth-01..

Elle permet de realiser une authentification asymetrique entre les differentes entites.

II.2.1 Presentation generale

Les methodes (( classiques ))d’authentification IKE reposent sur le fait que celle-ci soit mutuelle,

chacune des entites s’authentifie vis a vis de l’autre en utilisant la meme methode d’authentification.

L’authentification en Hybrid Auth fournit une asymetrie dans la maniere dont la passerelle

et le client s’authentifient : la passerelle utilise des methodes de cryptographie asymetrique (cles

publiques, cles privees) alors que le client (typiquement un road warrior) va utiliser une authentifi-

cation de type Challenge/Reponse. Il est tout a fait possible de faire l’inverse egalement. Ainsi,a

la fin d’une negociation aboutie de phase 1 utilisant le Mode Hybrid, la passerelle s’est unidirec-

tionnelement authentifiee aupres du client. Il n’en est rien quant a l’authentification du client.

Pour completer l’authentification, XAuth (cf. II.1) pourra etre utilise.

Apres un echange Hybrid Auth, on se retrouve donc dans la situation suivante :

– Le client mobile sait a present qu’il dialogue bien a la bonne passerelle.

- 38 -


– Les echanges entre le client et la passerelle sont securises sur la base de la ISAKMP-SA

etablie.

– La passerelle ne connait pas encore l’identite du client mobile. Une authentification du client

est necessaire.

II.2.2 Fonctionnement

Le Mode Hybrid intervient lors des echanges de negociation de phase 1 : une methode d’au-

thentification Hybrid est proposee dans les attributs de la ISAKMP-SA. Les valeurs peuvent etre

les suivantes :

– HybridInitRSA

– HybridInitDSA

– HybridRespRSA

– HybridRespDSA

Lorsqu’un client initie la negociation, il choisit les attributs HybridInit* tandis que lors de

l’initiation par la passerelle, il s’agit 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

ou [ CERT, ] SIG_R permettent d’authentifier 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 Authentification forte et complete

Hybrid Mode authentifie la passerelle aupres du client. Pour que le client le soit egalement, on

peut forcer l’utilisation de XAuth juste apres l’etablissement de la ISAKMP-SA. C’est d’ailleurs ce

que preconise le draft, et c’est la maniere avec laquelle NETASQ authentifiera les road warriors.

Ainsi, l’utilisation du mode Hybrid est suivi, dans tous les cas, par un echange XAuth.

Aucune information complementaire, y compris en Mode Config ne doit etre envoyee et/ou ac-

ceptee. Lorsque XAuth est termine et valide, les deux entites se sont authentifies mutuellement.

Peuvent alors commencer des echanges en Mode Config, ou des negociations de phase 2, etc.

Que l’echange XAuth soit precede d’un echange Hybrid Auth ou pas, en cas d’echec d’authentifi-

cation a l’issue du XAuth, la ISAKMP-SA fraıchement etablie est supprimee.

Une fois que les hotes sont authentifies, dans le cas d’un road warrior, a moins qu’il n’ait

embarque l’ensemble des parametres reseaux statiquement sur la machine, il faut les lui transmettre

a present. Le Mode Configuration se charge de cette tache.

- 39 -

II.3. MODE CONFIGURATION

II.3 Mode Configuration

II.3.1 Presentation Generale

L’extension Mode Config est decrite dans le draft-dukes-ike-mode-cgf-02.. Elle permet

de transmettre a une machine hote distante, typiquement un road warrior, certains parametres

reseaux, notamment ses extremites distantes de trafic. Ces parametres sont transmis de telle sorte

que le client distant se comporte comme s’il etait sur un LAN du reseau interne, a ceci pres que la

connexion se fera par un tunnel IPSec.

Cette transmission est protegee par la ISAKMP-SA, et intervient par consequent apres la negociation

aboutie d’une Phase 1, et imperativment avant toute tentative de negociation de Phase 2 puisque

celle ci necessite l’ensemble des parametres transmit lors du Mode Config.

Lorsque que le Mode Config est utilise seul, c’est 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 s’agir de transmettre toute une

configuration reseau a un road warrior comme une adresse locale, un masque de sous reseau, un

serveur DNS/WINS, etc ; ou il peut juste s’agir de transmettre l’adresse d’un serveur DNS interne

pour qu’il puissse resoudre les noms internes.

Types de messages disponibles :

– ISAKMP CFG REQUEST

– ISAKMP CFG REPLY

– ISAKMP CFG SET

- 40 -


– 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 ou la passerelle souhaite transmettre les parametres de son propre chef, il s’agit d’un

couple d’echange SET - ACK dans lequel la passerelle propose un certain nombre de parametres

(DNS, WINS, etc) et ou le client envoie juste un accuse de reception.

Dans le cas ou le client demande ces informations a la passerelle, il s’agit d’un couple REQUEST - REPLY

ou le client demande une configuration reseau formee de certains attributs et ou la passerelle repond

avec les memes attributs correctement definis, suivant sa configuration.

Il existe deja quelques implementations permettant aux clients mobiles de se connecter sur les

passerelles IPSec en ayant leur configuration reseau statique embarquee sur leur machine. Pour

des raisons de compatibilites, il est necessaire que l’ajout d’une implementation Mode Config soit

interoperable avec les implementations actuelles : un client mobile supportant le Mode Config est

cense pouvoir se connecter meme s’il refuse les parametres qui lui ont ete transmis en Mode Config

qu’il negocie avec des parametres statiques, sous reserve que ceux ci soient valides.

II.3.3 Parametres disponibles

Le demon racoon du projet ipsec-tools propose un ensemble de parametres pouvant etre

transmis en Mode Config, en etant le plus conforme possible vis a vis du draft.

Authentification : lors d’un echange XAuth, permet de definir l’equipement d’authentification a

utiliser : PAM, Kerberos, Radius...

Adresse IP : transmission d’une adresse IP locale (RFC 1918) au client mobile sur son interface

IPSec.

Masque de sous reseau : transmission du masque.

DNS, WINS : transmission d’adresse ou liste d’adresse de serveurs DNS/WINS.

Banniere : banniere personalisee lors de la connexion du client mobile.

II.3.4 Pool et penurie d’adresses IP

En Mode Config, le client peut se voir attribuer notamment une adresse IP locale. Cette attri-

bution peut etre geree directement dans les fichiers de configuration de racoon ou alors a un niveau

superieur dans les fiches des utilisateurs d’une base LDAP, par exemple. Il serait ainsi possible d’im-

poser une adresse IP locale a un utilisateur, pour qu’il ne puisse par exemple pas negocier une autre

adresse IP que celle qu’on lui a attribue lors d’une phase 2. Dans le cas ou la gestion des IPs est

faite par LDAP, il faut au prealable s’assurer qu’il n’y ait pas de collisions lors de l’attribution : une

IP attribuee a un client est peut etre deja utilisee, ou plusieurs pools d’IPs se chevauchent peut etre.

D’autre part, lorsqu’un pool d’adresses IP a ete defini, lorsque l’ensemble des adresses ont ete

attribuees a des road warriors, il faudrait pouvoir remonter un message de maniere la plus stan-

dardisee possible a l’administrateur et au road warrior essayant de se connecter. Dans la version

- 41 -

II.4. INTERACTIONS XAUTH, HYBRID ET MODE CONFIG

actuelle d’ipsec-tools (0.7.1), racoon ne peut encore le faire.

On peut egalement avoir le cas ou certaines adresses sont deja 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 d’une configuration robuste

il est preferable de verouiller certaines interactions quant a l’utilisation de l’une ou l’autre de ces

methodes.

– Mode Config : Independant, peut etre utilise avec/sans XAuth ou Hybrid mais

uniquement apres que le client se soit correctement authentifie, c’est a dire apres

une phase 1 “forte”, ou apres une phase 1 suivi d’un XAuth.

– XAuth : Independant

– Hybrid : le mode Hybrid devrait etre suivi d’un XAuth afin de completer l’authentification.

Ainsi, dans le cas ideal, l’etablissement d’un 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, authentification par Certificats ou par

Hybrid Mode.

2. Transaction Exchange XAUTH pour authentifier le client.

3. Transaction Exchange ModeConfig pour lui transmettre ses parametres reseaux.

4. Quick(s) Mode(s).

II.5 Faiblesses d’IPSec

Le doigt a deja ete mis sur quelques unes des faiblesses des protocoles IPSec, comme l’utilisation

de l’authentification en cle pre-partagee lorsque l’on negocie en aggressif, ou encore l’utilisation

de SAs statiques rendant les attaques par force brute plus probables. Il ne s’agit neanmoins pas des

seules. Le but n’etant pas de faire une liste exhaustive de l’ensemble des failles connues, quelques

pistes sont plus approfondies afin d’avoir les configurations les plus robustes et securisees possibles.

II.5.1 Failles cryptographiques intrinseques

La securite des protocoles IPSec est basee sur l’implementation des briques cryptographiques

sur lesquelles ils reposent d’une part, et sur les reseaux IP et leur fonctionnement d’autre 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 -


de remedier a ce probleme : les cles de sessions sont calculees uniquement sur la base d’un echange

Diffie-Hellman et non plus sur la base d’informations deja connues. Elles sont ainsi independantes

les unes des autres.

On peut egalement citer les attaques par bit flipping des protocoles de chiffrement en CBC -

Cypher Bloc Chaining. Il s’agit d’inverser des bits dans un paquet ESP sans avoir a le dechiffrer

puis le reemettre en esperant que cela genere une erreur ICMP qui, elle, sera envoyee en clair.

II.5.2 Problemes d’implementation

Qu’il s’agisse de configurations par defaut, de configurations trop complexes ou meme de failles

dans le traitement des paquets dans la pile IPSec, les problemes d’implementations existent et sont

corriges le plus rapidement possible.

Certaines implementations proposent des parametres, par defaut, faibles lors de la negociation

de Phase 1 et 2. Ces parametres, si ils sont combines consitiuent une faille non negligeable. La

verification de proposition par defaut de racoon est en mode strict. Or, pres de 9 configura-

tions sur 10 ont un mode de negociation en obey qui accepte la premiere proposition de l’hote.

Les deux hotes se retrouveront alors a chiffrer en DES alors que tout deux supportent AES. De

plus, parmi les algorithmes de chiffrement par defaut, on retrouve toujours DES qui s’est pourtant

essoufle depuis les annees 2000. Le PFS desactive par defaut ne viendra que renforcer l’insecurite

de l’ensemble.

Certains bugs d’implementation permettent egalement a certains paquets qui ne sont pas censes

emprunter le tunnel d’etre tout de meme chiffre en passant a travers les politiques de securite. L’in-

verse est plus dangeureux, lorsqu’un paquet cense etre chiffre sort en clair sur le reseau.

On peut egalement citer tous les problemes lies a la validation des certificats, aux CRLs non

mises a jour, ou meme a l’absence de confrontation d’un certificat a une CRL. Un utilisateur

revoque, ayant un certificat qui n’est plus valide, pourra tout de meme monter un tunnel IPSec

vers sa passerelle.

II.5.3 Deploiements reels

L’ensemble des faiblesses citees plus haut provoquent egalement des configurations bancales

lors de leur deploiement effectif.

Certaines configurations ne correspondent pas du tout aux attentes de securite des adminis-

trateurs, du le plus souvent a une mauvaise comprehension des protocoles. A titre d’exemple, le

mot cle require dans racoon est utilise dans l’injection de politiques de securite par setkey.

Lorsque l’on desire etablir plusieurs Phase 2 avec un meme correspondant, require ne permet

pas de distinguer une SA specifique avec laquelle il faudrait chiffrer tel ou tel trafic. Il en resulte

que n’importe quel SA peut etre utilisee pour chiffrer n’importe quel type de trafic avec cet hote

donne : il n’est pas du tout garanti que le trafic que l’on desirait proteger de telle maniere le sera

- 43 -

II.5. FAIBLESSES D’IPSEC

effectivement ! Dans le pire des cas, on peut en arriver a chiffrer les donnees les plus importantes

avec les configurations les plus faibles !

D’autre part, nombre d’administrateurs sont persuades que les politiques de filtrage ne sont

pas necessaires lors de la mise en place de tunnels IPSec. Les flux passant a travers ces tunnels ne

sont donc pas surveilles. Une politique de filtrage est absolument necessaire a la sortie du tunnel

IPSec lorsque le paquet est dechiffre et qu’il passe dans le reseau local (( classique )).

Enfin, on peut rajouter la mauvaise protection des secrets ou des certificats. Lorsque les cle-

partagee sont faibles ou connues par beaucoup trop de personnes, on ne peut garantir une authen-

tification forte. Il en est de meme pour les certificats, ou les CRLs ne sont pas mises a jour assez

regulierement...

- 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 aujourd’hui une gamme complete de solutions firewalls, VPNs et

AntiSpam pour des entreprises de toute taille.

on presentera ici une description avancee des fonctionalites des firewalls NETASQ.

- Une presentation complete de l’ancienne et de la nouvelle gamme des UTMs.

- L’ASQTM : Active Security Qualification, technologie proprietaire de prevention

d’intrusion analysant le traffic sur l’ensemble des couches reseaux. L’ASQ equipe l’ensemble

de la gamme des solutions.

- L’administration des firewalls : la suite logicielle graphique dont le Manager et le

Monitor permettant de suivre l’ensemble de l’activite reseau et de prendre les mesures

necessaires en cas de problemes.

- Les fonctionalites avancees des firewalls, comme la HA, le portail d’authentification

ou encore le mode hybrid1 des interfaces reseaux ; afin de securiser des architectures reseaux

complexes et eclatees sur plusieurs sites geographiques.

L’interaction entre les differents modules, en particulier avec le module IPSec facilite la

prise en main, et ainsi l’integration du Mode Config.

III.1. PRESENTATION DES UTMS

III.1 Presentation des UTMs

III.1.1 Qu’est ce que l’UTM?

Les solutions de securite NETASQ sont toutes basees sur le concept d’UTM - Unified Threat

Managment. On ne parle alors plus tellement de firewall, ou d’IPS (Intrusion Prevention System)

ou encore d’IDS (Intrusion Detection System).

Les UTMs integrent, en standard, l’ensemble des fonctionalites de securite essentielles repondant

aux besoins de des differentes entreprises. L’avantage sur des architectures de securite basees sur

des produits multiples est triple :

Le prix des infrastructures : Lorsque l’on s’oriente vers de multiples produits, l’addition 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 chere

qu’un ensemble de solutions de Firewall, d’Antivirus, d’Antispyware, de Detection d’Intru-

sion, d’Antispam, etc.

L’administration et la maintenance : Il est toujours plus simple et efficace d’administrer une

seule solution UTM plutot que de gerer un ensemble de produits. Cela evite d’avoir recours

a des methodes d’installation et de deploiement multiples, des supervisions multiples et une

plus grande difficulte a securiser l’ensemble de l’infrastructure reseau. Il en resulte parfois

des possibilites de trous de securite multiples.

L’attente du marche : Ainsi, lorsqu’une entreprise securise son informatique interne, elle s’at-

tend a ce que les produits soient unifies, que les formations soient courtes, l’installation rapide

et surtout un verrouillage de la securite qui soit central.

Ainsi, les UTMs NETASQ embarquent dans toute leur gamme l’ensemble des modules disponibles :

IPS en temps reel : Il s’agit de l’ASQTMpresente a la section III.2.2.

Firewall : Non seulement firewall reseau, mais egalement applicatif.

PKI : Il est possible de creer une CA et des Certificats pour l’ensemble des utilisateurs, le tout

embarque sur l’UTM.

Proxy et filtrage 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 tres repandue, SSL et surtout IPSec interconnectent

des sites geographiquement eloignes et permettent egalement aux clients nomales (des com-

merciaux terrains par exemple) d’acceder au reseau interne de l’entreprise.

- 46 -

CHAPITRE III. LES UTMS NETASQ

III.1.2 La premiere generation des UTMs NETASQ : Les series F

Afin de repondre aux attentes des petites entreprises, des UTMs d’entree de gammes comme

le F25, F50 ou le F60 (cf. III.1). Ces modeles integrent un haut niveau de securite et peuvent

rapidement etre deploye sur les petites infrastructures sans en modifier l’architecture.

F25

5 ports Ethernet 10/100

2000 sessions simultanees.

F50



F60



Fig. III.1 – Gamme pour PME : F25, F50, F60

Ces modeles n’ont pas de disque dur integre, uniquement une memoire flash. 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 jusqu’au 1200 (cf. III.2). Les tests, le developpement,

l’integration et l’ensemble du stage a ete realisee sur un modele F200, modele NETASQ par excel-

lence. Cette gamme integre des disques durs avec l’ensemble des fonctionalites disponibles : PKI,

LDAP interne, presence des logs, partition de sauvegarde et restauration, etc.

Pour les tres grandes entreprises, deux produits NETASQ (cf. III.3) apportent des perfor-

mances Multi-Gigabits et un grand nombre d’interfaces, faisant alors une protection parfaite pour

des zones demilitarisees assez sensibles. Une securite optimale pour proteger entre autres les sieges

- 47 -


F200



F500

4 ports Ethernet 10/100 et 2 ports Gigabits


F800

4-8 ports Ethernet 10/100/1000


F1200

10 ports Ethernet 10/100/1000


Fig. III.2 – Moyenne et Grosse gamme : F200 au F1200

- 48 -


sociaux.

F2500

6-24 ports Ethernet 10/100


F5500

24 ports Ethernet 10/100/1000

Disques durs ”Hot Swap en RAID”


Fig. III.3 – Haute Gamme pour grands comptes : F2500 et F5500

Ces modeles arrivent aujourd’hui en fin de vie (cf. III.4) et ont recemment ete remplaces par

une nouvelle generation de tres hautes performances, et a la pointe de la technologie comme par

exemple la precense de port en fibre optique.

III.1.3 La nouvelle generation G2 : Les series U

L’ancienne generation des UTMs etait plus reference comme des firewalls d’ou le F. Afin de

rompre avec cette idee en mettant sur le marche une toute nouvelle generation d’UTMs, d’ou le U,

avec des performances inegalees jusqu’a aujourd’hui.

De l’U70 a l’U6000 (cf. III.5), de tres hautes performances (Interface Gigabits sur l’ensemble

de la gamme entre autres), une nouvelle version du firmware NETASQ (version 8.0, Codename DELOS)

devant etre presentee aux Assises de la Securite et des Systemes d’Informations qui se tiendra a

Monaco en octobre, cette nouvelle generation est largement en avance sur son temps.

- 49 -


Fig. III.4 – Anciens UTMs G1

Fig. III.5 – Nouveaux UTMs G2 - www.netasq.com

- 50 -


III.2 L’ASQ - Active Security Qualification

III.2.1 Presentation

Le firewall classique bloquant les protocoles interdits par l’administrateur et filtrant le trafic

commence a etre depasse. Il s’agit aujourd’hui de pouvoir detecter et surtout de prevenir en temps

reel les comportements anormaux au sein meme du trafic autorise. A titre d’exemple, la majorite

des attaques se basent aujourd’hui sur des protocoles applicatifs comme HTTP ou FTP.

L’ASQ - Active Security Qualification est une technologie de prevention d’intrusion en

temps reel developpee par l’equipe R&D des 1998 et integree dans les appliances. Il fournit une

prevention d’intrusion basee sur le contexte en interceptant les paquets au niveau de la couche 2

OSI, en analysant le traffic de la couche 3 OSI jusqu’a la couche 7 OSI applicative et en appliquant

de multiples methodes pour identifier et bloquer tout trafic malveillant.

L’ASQ utilise des familles d’attaques lui garantissant une precision optimale afin de proteger

le reseau contre les menaces tout en conservant des hautes performances et des gros debits. Les

firewalls realisent ainsi un traitement preventif en temps reel, tant au niveau de la couche reseau

qu’applicative, sans diminuer les performances du systeme.

III.2.2 ASQ : Pile OSI Virtuelle

Lorsque l’ASQ recoit un paquet a analyser, il n’effectue aucune decapsulation a proprement

parler, on ne remonte pas la pile IP. Il effectue toutes ses analyses de securite au niveau noyau

sur un paquet mis en tampon (cf. III.6). Cele permet notamment d’accroıtre considerablement les

performances et les debits.

Ainsi, lorsque l’ensemble des analyses de securite sont realisees, le paquet est transmis a l’inter-

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 l’ASQ

Beaucoup plus loin que les simples classement depasses analyse niveau reseau et analyse niveau applicatif,

l’ASQ protege les flux suivant trois grandes categories d’analyse.

L’ASQ est lie au filtrage et a ce titre effectue toute une serie d’analyses (cf. III.7) de la couche

3 jusqu’a la couche 7 avant de delivrer le paquet a l’application en attente ou de l’envoyer sur le

reseau.

- 51 -

III.2. L’ASQ - ACTIVE SECURITY QUALIFICATION

Fig. III.6 – ASQ : Pile OSI virtuelle en 7 couches

Fig. III.7 – Differentes etapes d’analyses de l’ASQ

- 52 -


L’analyse Protocolaire

Il s’agit, comme son nom l’indique, d’une analyse des paquets par protocole. Les flux sont

analyses suivant leur protocole et tout trafic malforme, non conforme au protocole associe (reseau

ou applicatif) est supprime.

L’analyse protocolaire verifie ainsi la conformite par rapport aux differentes RFCs (Ethernet, IP,

TCP, UDP) des protocoles reseaux et transports.

D’autre part, une verification est faite par rapport aux RFCs des protocoles applicatifs comme

HTTP, SMTP ou encore FTP grave aux plugins applicatifs developpes dans la section suivante.

Ainsi, sont notamment evitees l’ensemble des attaques basees sur des options des protocoles mal

positionnes.

Afin de prevenir l’administrateur, le firewall peut lever une alarme, et il en existe aujourd’hui pres

de 120 classes reparties sur pres de 11 categories.

L’analyse des fragments

La seconde type d’analyse effectuee par l’ASQ evite les attaques basees sur l’exploitation du

sequencement des fragments.

Les verifications ne sont plus effectuees sur le paquet isole en lui meme mais sur le datagramme

dans son environnement : la coherence entre les donnees des differents paquets qui precedent et/ou

qui suivent est validee.

On confirme alors qu’aucun fragment ne se chevauche avec un autre, que le paquet initial est

bien reconstitue, qu’il n’y a pas de debordement de taille, etc. Les fragments sont memorises dans

un buffer et le paquet est renvoye uniquement s’il est reconstitue sans erreur.

L’analyse Globale

L’analyse Globale s’interesse au contexte des connexions. Pour chaque connexion acceptee, ses

differents elements caracteristiques comme les adresses IPs de source et de destination, le contexte

TCP, etc sont memorises. Il s’agit de la technologie (( Stafeull Inspection ))permettant d’analyser

les flux suivant leur contexte de connexion.

D’autre part, dans l’ASQ, la sauvegarde des etats de connexion est persistante au reboot, et

les connexions semi-ouvertes sont egalement reprises. Les numero de sequence TCP sont modifies

avec un aleat fort et le SACK (Selective Acknowledgment Option)2 est active. La persistance des

connexions au reboot permet notamment d’eviter l’ensemble des attaques DoS qui redemarrent

le firewall apres un debordement de pile reseau, et qui esperent pouvoir voler des sessions TCP a

l’aide des numeros de sequence des retablissements de toutes les connexions coupees.

2Le SACK permet de renvoyer un paquet particuler sans renvoye tous les paquets suivant le dernier ACK recu.

- 53 -

III.2. L’ASQ - ACTIVE SECURITY QUALIFICATION

ASQ Dynamic Filtering

Le filtrage NETASQ est de type (( Statefull Inspection )). Le Statefull, contrairement au

Stateless, sauvegarde l’ensemble du contexte des differentes connexions etablies et autorise au-

tomatiquement le flux entrant en relation avec un contexte d’une connexion deja etablie. L’interet

est alors de verifier le trafic 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 d’evaluation de regles de filtrage : SKIP. SKIP

permet de regrouper un ensemble de regles ayant un ou plusieurs criteres en commun. Ainsi lors

de l’application de regles de filtrage sur un flux, l’ensemble des regles ayant un critere eliminatoire

en commun sont sautees et ne sont pas evaluees puisqu’elles 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 regles de filtrage qu’un paquet qui provient du reseau interne

a destination de l’Internet sautera les regles 5, 6 et 7.

L’analyse Applicative

L’analyse applicative est basee sur une architecture a plugin, permettant de l’activer ou de la

desactiver. Un plugin va s’attacher a un certain type de protocole et de services afin de verifier la

conformite des protocoles applicatifs par rapport aux normes et differentes RFCs, et d’en prevenir

les utilisations frauduleuses connues. En outre est effectuee une verification de coherence entre les

donnees transportees par le paquet et les en-tetes de celui-ci. Cela permet d’identifier des attaques

propres a chaque type de protocole applicatif.

On peut remarquer que ce systeme d’analyse pourra bloquer les attaques basees sur des signa-

tures qui ont ete intentionnellement modifiees afin de tromper les IDS classiques.

Tous ces types d’analyses font de l’ASQ un puissant analyseur temps reel de trafic, et n’en

affectant pourtant pas les performances globales.

- 54 -


III.3 Fonctionalites Avancees

En plus de l’ASQ, coeur du firmware NETASQ, les appliances disposent de fonctionalites de

plus en plus riches comparees aux pare-feux traditionnels.

III.3.1 Authentification et PKI

A partir des modeles F200 (gamme G1), les appliances disposent toutes d’un disque dur et

peuvent alors embarquer des annuaires utilisateurs et une mecanique complete d’etablissement de

PKI. Il est toujours possible d’authentifier sur une base externe lorsque les modeles n’integrent pas

de disque dur.

Plusieurs methodes d’authentification sont alors disponibles :

None : les utilisateurs ne s’authentifient pas.

LDAP : les utilisateurs s’authentifient a l’aide de leur mot de passe, dont une empreinte est

stockee dans un champ approprie de leur fiche LDAP. L’authentification peut se faire sur

une interface web en HTTPS ou HTTP.

SSL : les utilisateurs s’authentifient en presentant au firewall un certificat valide.

SRP : cette methode permet de ne transmettre ni le mot de passe, ni l’empreinte du mot de passe a

travers le reseau. Il s’agit d’une authentification a base de challenge-response (Diffie-Hellman

en particulier).

SRP-LDAP : Methode d’authentification developpee par NETASQ. Le mot de passe LDAP de

l’utilisateur est utilise pour generer une cle jetable SRP et permettre l’authentification en

SRP.

Kerberos : les utilisateurs s’authentifient via un serveur Kerberos (AS et TGS).

RADIUS : les utilisateurs s’authentifient au moyen d’un serveur RADIUS externe. Les mecanismes

de transmission de l’empreinte du mot de passe sont les meme que pour l’authentification

via LDAP.

NTLM : les utilisateurs s’authentifient 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 l’authen-

tification par certificats et par LDAP, SRP-LDAP.

Methode SRP

SRP - Secure Remote Password Protocol permet d’authentifier les utilisateurs sans divulguer

leur mot de passe, ni leur empreinte de mot de passe sur le reseau. L’idee de l’authentification en

SRP fut lancee sur USENET en 1996 pour la premiere fois. Deux cles de sessions sont echangees

durant la phase d’authentification, a l’aide d’un Diffie Hellman et de l’empreinte du mot de passe.

On verifie que les deux parties connaissent bien le mot de passe sans que celui ci ou son empreinte

- 55 -

III.3. FONCTIONALITES AVANCEES

n’ait transite.

Ce protocole d’authentification est resistant face aux attaques d’ecoute de reseau comme aux

attaques par injection de trafic dans la sequence d’authentification. Il est ainsi robuste, y compris

lorsque l’entropie du mot de passe en lui meme est faible.

Kerberos et Radius

RADIUS - Remote Authentication Dial-In User Service est un protocole d’authentification

centralisee fonctionnant en mode client-serveur. On peut l’utiliser, dans le cadre d’IPSec en Mode

Config par exemple, pour authentifier les roads warriors se connectant a la passerelle IPSec. L’UTM

NETASQ peut alors se comporter comme un client RADIUS et envoyer des demandes d’authen-

tification au serveur. L’utilisateur sera identifie et authentifie sur le firewall uniquement s’il l’est

sur le RADIUS.

Kerberos a une vision differente de l’authentification. Plutot 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 systeme de tickets permettant de s’authentifier sur n’importe quel service kerberise. Les ser-

vices ou applications authentifiant le feront sur la base du ticket et non plus du mot de passe de

l’utilisateur.

III.3.2 Traitement des paquets

A quel module et dans quel ordre sont exactement confrontes les paquets entrants/sortants

depuis les differentes interfaces reseaux ? Quels sont les priorites ? Pourquoi est ce qu’un meme

paquet peut passer plusieurs fois par l’ASQ ?

Une synoptique interne de traitement des paquets est presentee sur la figure III.9).

Un paquet entrant est, avant tout, confronte a la politique NAT du firewall avant d’etre trans-

mis a l’ASQ. Celui ci effectue toutes les analyses qu’il peut faire et passe la main au module IPSec

qui se charge de decapsuler les donnees. Ces donnees sont alors confontrees a l’ASQ (a la premiere

verification, l’ASQ peut juste verifier la validite du paquet en lui meme et non pas des donnees qu’il

contient puisque celles ci sont chiffrees), validees puis transmises sur l’interface ou aux applications

en attente.

En sortie, il s’agit du chemin inverse : les paquets sortant sont confrontes aux analyses ASQ,

aux regles de SPD afin de verifier s’il 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 s’agit des routes prioritaires sur toutes les autres.

- 56 -


Fig. III.9 – Synoptique des UTMs NETASQ

Routage par interface : Permet de faire du load balancing par exemple, lorsque l’on doit router

le trafic internet en fonction de la navigation et/ou des telechargements.

Table Load Balancing : Permet de gerer et maintenir les regles de routes par interfaces.

Routes par defaut : Routes consultees en dernier, lorsque toutes les autres n’ont 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 firewalls sont relies par

une liaison specifique avec les memes configurations, et un seul est actif a un instant donne.

Ils communiquemnt regulierement afin de verifier que tout se passe bien et lorsqu’une defaillance

survient, le firewall passif reprend la main automatiquement. Cela permet d’assurer la continuite

du service meme en cas de dysfonctionnement de l’un des deux firewalls.

La liaison de communication entre les deux firewalls fut une liaison serie autrefois. Ne pouvant

garantir des debits suffisants, il s’agit aujourd’hui d’une 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 d’administration graphique (cf. III.11) developpee

par l’equipe IHM. Cette suite est composee de trois logiciels graphiques permettant une configu-

ration fine et poussee des UTMs :

Manager : Constitue le logiciel d’administration principal. La communication entre le logiciel et

le firewall se fait sur le port TCP 1300 et est chiffree en AES 128 bits.

Monitor : Est un logiciel permettant de monitorer, de surveiller l’ensemble du trafic en temps reel.

Ce logiciel repertorie l’ensemble des logs et calcule un ensemble de statistiques configurables

par l’administrateur.

Reporter : Permet de collecter les logs des differents modules des UTMs.

En sortie d’usine, les UTMs ont tous l’adresse 10.0.0.254. La premiere connexion a l’appli-

ance (cf III.12) s’effectue obligatoirement par l’intermediaire du Manager et sur une interface dite

protegee, c’est a dire une interface qui acceptera des connexions provenant uniquement du sous

reseau auquel elle appartient.

Par defaut, le filtrage est le plus restrictif possible : le firewall rejette la totalite des flux qu’il

recoit, excepte le trafic sur le port TCP 1300.

- 58 -


Fig. III.11 – Suite d’administration des IPS-Firewalls NETASQ

Fig. III.12 – NETASQ Firewall Manager

- 59 -

III.4. MANAGMENT ET MONITORING

D’autre part, le gestion des differents logs et traces d’activites sur les reseaux se fait par l’in-

termediaire du Monitor et du Reporter.

Le Monitor loggue l’ensemble du trafic, comme les indicateurs systemes et de securite (Debits par

interface, CPU, RAM, HA, etc) ; peut chiffrer les logs et les envoyer a un serveur syslog distant.

On peut ainsi suivre, en temps reel, l’ensemble des services et prendre les mesures qui necessaires

en cas de problemes :

– Un historique des actions d’administrations.

– Les utilisateurs authentifies

– Les evenements systemes

– L’activite des differents modules

– . . .

Ainsi, l’administrateur, en cas de problemes sur le reseau, peut immediatement mettre tel ou

telle partie du reseau en quarantaine, ou encore supprimer un utilisateur authentifie ou encore se

faire notifier par une alarme lors d’une tentative d’intrusion detectee par l’ASQ.

La suite graphique a tres peu ete utilisee durant ces six mois de stages. L’ensemble de l’admin-

istration du firewall s’est faite par ssh et Port Serie, directement sur les fichiers de configurations

manipules par la suite graphique. Ces fichiers de configurations seront ceux qui sont manipules lors

de l’integration du Mode Config d’IPSec.

- 60 -

CHAPITRE IV

Integration du Mode Config

An ounce of practice is worth more than tons of preaching.

— Mahatma Gandhi

Resume :

Ce dernier chapitre, apres avoir etudie en details IPSec et pris en main les UTMs de

maniere avancee, s’interesse a l’integration proprement dite du module Mode Configuration

d’IPSec dans les firewalls. Pour cela, de multiples etapes :

Il a fallu tout d’abord effectuer de tres nombreux tests avec racoon et setkey afin

de savoir exactement l’etat du Mode Config dans le projet ipsec-tools.

A partir de ce moment la, realiser un travail de conception qui ferait ressor-

tir la maniere dont serait integre cette extension dans le format du fichier de configura-

tion NETASQ existant deja. Le choix s’est finalement porte sur quatre nouveaux tokens :

cfg_src, cfg_dst, cfg_dns, cfg_wins.

Implementer cette extension dans le parseur NETASQ.

Tester l’ensemble, une fois l’implementation realisee, et verifier le bon comportement

lors de configurations bancales ou non-valides.

Tester ensuite le code afin d’en evaluer les performances, notamment a l’aide d’outils

comme Spirent.

Enfin, realiser un audit aupres de l’equipe de developpement de la suite graphique

afin d’integrer ces tokens de la maniere la plus ergonomique possible pour le client.

Parralellement, il a fallu realiser un audit du code du projet ipsec-tools afin de combler

les manques et d’apporter des ameliorations concernant le Mode Config, 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 d’ipsec-tools

L’un 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 l’aspect des differentes extensions , et enfin sur l’aspect Mode Config en

particulier.

L’evaluation generale consistait plus en une prise en main de racoon. Il fallait se familiariser

avec l’ensemble des options disponibles dans racoon, et connaıtre l’impact sur les differentes asso-

ciations de securite etablies.

L’aspect extensions IPSec - Mode Config - XAuth - Hybrid est venu renforcer le cote authen-

tification des correspondants lors de l’etablissement d’un tunnel IPSec. Il fallait, en effet, dans un

soucis de compatibilite future, etudier les trois extensions, meme si seule Mode Config etait ini-

tiallement destinee a etre integree dans le firmware NETASQ, dans le cadre du cahier des charges

du stage en tout cas.

Enfin, une evaluation assez poussee de tout l’aspect Mode Config. Une implementation du

Mode Config existait deja dans le projet ispec-tools. Toutefois, peu de personnes l’avait utilise

ou teste. L’objectif etait donc double : evaluer le Mode Config en effectuant une batterie de tests

pousses, verifier le comportement correct de racoon en cas de mauvaises configurations, et le cas

echeant corriger le code et/ou apporter des modifications afin d’en accroitre les performances.

L’ensemble des tests effectues en Mode Config ont ete concluants, il s’avere que l’implementation

du Mode Config existante etait stable et operationnelle dans un cadre de deploiement massif. Ainsi

a-t-on mis l’accent sur le fichier de configuration NETASQ afin de l’integrer aussi vite que possible.

IV.1.2 Configurations Racoon (( basique ))

Un fichier de configuration basique de racoon se presente de la maniere 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. INTEGRATION 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 l’adresse de l’hote distant. Il

peut s’agir d’une configuration anonyme egalement, lorsque l’adresse IP du correspondant est dy-

namique, typiquement dans le cas des road warriors.

L’ensemble des champs presents dans la section remote permettent de negocier la ISAKMP

SA, IKE-Phase 1. Ils definissent, entre autres, la duree de vie de la phase 1, les algorithmes de

chiffrement et d’authentification utilises et surtout la flexibilite de negociation a travers le champ

proposal check.

Ce champ est par defaut a strict. Tres nombreuses sont les configurations racoon ou l’on remar-

que ce champ positionne a obey. Il serait judicieux de n’utiliser 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 chiffrement, d’authentification et de durees de vies sont au moins equivalentes a celles

presentes dans la configuration. Si elles sont d’un niveau de securite moindre ou de durees de vies

plus faibles, la negociation echoue. exact n’accepte que des propositions rigoureusement exactes,

claim essaie de negocier une proposition equivalente au moins en terme de durees de vies.

D’autre part, le champ exchange_mode definit le mode de negociation principal (Identity Pro-

tection Mode) ou aggressif. La plupart du temps, lorsque les IPs des deux correspondants sont

connues a l’avance, le mode utilise est main, comme nous l’avons decrit precedemment.

- 63 -


IPSEC SA

La section sainfo suivante permet de definir les parametres de negociations de la IPSEC-SA,

IKE-Phase 2. Il s’agit des parametres qui vont etre utilises pour chiffrer et/ou authentifier le trafic

utile. Cette section se presente de la maniere suivante :

sainfo src_ntwork/mask proto dst_ntwork/mask proto

{. . .}

On definit ainsi les sous-reseaux qui communiqueront de maniere chiffree 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 d’utilisation 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 n’est plus valide, mais toujours referencee dans le noyau. Elle ne peut plus etre

utilisee.

Cette configuration est (( classique )) : les adresses IPs des correspondants sont connues, en

mode main avec une authentification en Certificats X509. C’est la configuration la plus largement

deployee aujourd’hui 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 afficher la Security Policy Database - SPD et la Security Association Database - SAD.

setkey est appele lors que l’on 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 -


Aucun trafic entrant ou sortant n’est chiffre sur la boucle locale.

Une politique de securite pour le trafic sortant est ajoute : l’ensemble du trafic provenant du reseau

10.0.11.0/24 a destination de 10.0.11.33 est du trafic IPSec, et sera chiffre 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 trafic entrant, qui represente le chemin inverse emprunte par

les paquets : il s’agit du trafic 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


refcnt=1

127.0.0.0/8[any] 127.0.0.0/8[any] any

out none


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


refcnt=1

Les extremites de tunnels correspondent aux extremites (192.168.0.1-192.168.1.2) entre lequel

le trafic sera effectivement securise (chiffre, authentifie) et les extremites de trafic, 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 puisqu’il ne fait pas partie des extremites

de trafic.

Une fois la phase de tests ipsec-tools basique et une prise en main avancee de racoon realisees,

il a fallu passer a l’etape de verification des implementations des extensions XAuth et Mode Config

en particulier.

IV.1.4 Configuration en XAuth

Comme nous l’avons presente au chapitre consacre aux extensions IPSec decrites dans differents

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 TheGreenBowTM.

TheGreenBow est un client VPN developpe par TheGreenBow Enterprise Security Solutions et

- 65 -


fournit par NETASQ, pour les plateformes Microsoft Windows.

En Mode XAuth ou en Mode Config, un ensemble de clients mobiles dont l’adresse IP n’est

pas connue a l’avance se connectent sur la passerelle, et doivent s’authentifier. En plus de l’au-

thentification normale realisee par racoon, XAuth realise une authentification complementaire de

l’utilisateur a proprement parler. On peut rappeller que, bien que l’authentification de l’utilisateur

se fasse au niveau de XAuth, les echanges sont proteges par la ISAKMP SA etablie au prealable.

Une ISAKMP SA faible ne protege pas d’une eventuelle attaque ou intrusion, meme si l’authen-

tification de l’utilisateur par XAuth est faite sur la base de methodes robustes.

La configuration de racoon en mode anonyme en plus du Mode Config est quelque peu differente

du cas (( classique )).

remote anonymous # On ne connait pas l’adresse du road warrior !!

{ . . .

generate policy on; # On ne connait pas les politiques de securite a l’avance

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 d’auth

. . .

}

sainfo ip_passerelle any anonymous

{

. . .

}

Les differents champs rajoutes permettent une configuration dynamique a la volee des SAD et

SPD :

anonymous : la section remote devient anonyme puisque l’on ignore les adresses IPs des clients

mobiles. Il faut donc que la section match toutes les adresses.

generate policy : genere et injecte dynamiquement les politiques de securite via PF_KEY et la

librairie IPSec. Puisque l’on ignore les IPs des mobiles, on ne peut etablir des politiques

de securite par avance. Elles doivent l’etre a la volee au moment de la connexion des road

warriors.

mode cfg on : permet d’activer les echanges Mode Configuration (paquets de type Transaction

Exchange) permettant de realiser une authentification en XAuth.

La section mode_cfg vient s’ajouter aux differentes sections remote et sainfo deja presentes.

Elle presente les parametres des paquets Mode Config echanges. Il se trouve que dans le cas present,

- 66 -


nous utiliserons la section Mode Config uniquement pour authentifier l’utilisateur en XAuth. On sig-

nale donc a la passerelle que l’authentification se fera sur les comptes systeme, et qu’en cas d’echec

d’authentification d’un login particulier, celui ci ne pourra refaire une tentative avant quinze sec-

ondes.

Apres XAuth, il a fallu valider le Mode Configuration proprement dit, tel que decrit dans le

draft draft-dukes-ike-mode-cgf-02.

IV.1.5 Mode Config : racoon vs racoon

Principe

Lorsqu’un client mobile se presente a la passerelle IPSec pour y etablir une connexion, deux

choix s’offrent a lui :

– Il a embarque sur sa machine, au prealable, toute la configuration reseau necessaire a l’etablissement

de sa connexion IPSec. Il ne lui reste plus qu’a s’authentifier aupres de la passerelle pour

que celle ci puisse lui etablir son tunnel IPSec. Les informations embarquees sont, au mini-

mum, l’extremite distante de tunnel, les extremites distantes de trafic, les adresses d’eventuels

serveurs de noms, et les cles d’authentification.

Toutefois, maintenir plusieurs dizaines voire centaines de machines mobiles peut tres vite

devenir un casse-tete infernal pour l’administrateur, qui se voit attribuer un double travail :

garder tous ces mobiles a jour en fonction des changements effectues sur la passerelle IPSec et

sur les membres de l’entreprise en general (suppression de compte, revocation de certificats,

creation de compte, etc).

– L’idee serait donc de pouvoir envoyer toute la configuration reseau necessaire dynamiquement

au client mobile, une fois qu’il s’est correctement authentifie. Le Mode Configuration 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 Config sont modifiees, la section remote restant toujours anonyme du cote du serveur, et

ayant l’adresse 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 specifie dans la section Mode Config l’ensemble des parametres a transmettre au client

mobile lors de sa connexion :

- 67 -


network4 : Il s’agit du reseau RFC1918 dans le lequel racoon va piocher une adresse IP (( locale ))a

transmettre a l’interface IPSec du client mobile, pour que celui-ci puisse pretendre etre sur le

LAN de l’entreprise. Les adresses sont attribuees dans l’ordre croissant aux differents 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 s’agit de l’extremite de trafic locale a transmettre au client mobile. Il pourra

ainsi etablir des politiques de securite afin de communiquer en IPSec. Suivant ce champ,

generate_policy injecte les regles sur la passerelle.

dns4 : Adresse du serveur de nom a transmettre.

Du cote du client, en revanche, aucune section mode_cfg n’est necessaire. La recuperation des

informations de connexion se fait via deux scripts predefinis 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 l’adresse RFC1918 envoyee par le serveur, de l’attribuer a

l’interface IPSec et d’injecter les politiques de securite recues dans la SPD du client et de rajouter

les entrees dans les serveurs de noms deja disponibles.

IV.1.6 Mode Config : racoon vs quelques clients VPN

racoon en mode client n’etant pas vraiment realiste, au vue des configurations des clients de

NETASQ, sur des machines portables souvent sur des plateformes Windows, et cherchant le moins

de configuration possible, on s’est oriente vers des clients VPN deja 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 configuration 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 certificats soit lourde et peu er-

gonomique.

Les tests en Mode Config n’ont pas ete totalement concluant :

Une session Mode Config seule n’aboutit pas, tandis qu’une session Mode Config suivie d’un XAuth

valide recupere correctement certains parametres, comme l’adresse IP RFC1918.

- 68 -


Toutefois, il s’avere que ce client VPN a ete tres decevant au niveau de l’ensemble des propo-

sitions de Phase 1 qu’il envoie a la passerelle. En ayant ecoute le trafic reseau au moment de la

negociation, le client Cisco envoye toute une panoplie de propositions en esperant que l’une d’elle

sera retenue. Les passerelles IPSec pour les clients mobiles sont, en effet, le plus souvent configurees

en mode passif et se contentent de repondre aux propositions des clients.

L’inconvenient majeur du client Cisco est de ne pas tenir compte des reponses de la passerelle

configuree sous racoon, et d’envoyer encore plus de protocoles de chiffrement, de tailles de cles,

de protocoles d’authentification, de durees de vies differentes, etc. ce qui a tendance a saturer le

reseau assez rapidement, meme si la connexion aboutit in fine.

TheGreenBowTM

Les tests effectues sur les maquettes TheGreenBow ont ete concluant sur XAuth, mais mal-

heureusement tres decevant sur le Mode Config.

Bien qu’une fenetre entiere soit dediee au Mode Config, lors des ecoutes reseaux, il s’est avere

que le support n’est pas integre dans TheGreenBow puisqu’aucune demande (paquet ISAKMP-

REQUEST, ISAKMP-SET) ni reponse (paquet ISAKMP-REPLY, ISAKMP-ACK) n’est envoyee

ou recue par le client VPN.

Le service R&D a donc ete contacte afin de connaıtre les fonctionalites exactes quant au Mode

Config. Lors de la sortie de la version suivante, le Changelog annoncait une nouvelle fois le Mode-

Config, et les tests ont donc ete refaits plusieurs mois apres.

Ils ont neanmoins echoues egalement. Les requetes ne sont toujours pas transmises, aucun

paquet annoncant le support du Mode-Config n’est detecte lors de la negociation de Phase 1. The-

GreenBow ne supporterait vraisemblablement pas correctement l’extension Mode Config dans son

ensemble.

ShrewSoft

ShrewSoft est un client VPN/IPSec developpe recemment, sous licence GPL, dont la derniere

version 2.1.0 date du 19 juin 2008.

Le Mode Config a egalement ete teste avec Shrew et l’ensemble des tests effectues ont ete tout

a fait satisfaisants, avec une passerelle ou tourne racoon.

L’ensemble des champs disponibles dans le Mode Config de racoon sont correctement transmis a

Shrew qui configure correctement les politiques de securite et met en place le tunnel.

Qu’il s’agisse du Mode Config seul, ou du Mode Config suivi de XAuth, la configuration est

correctement transmises et l’ensemble des parametres correctement pris en compte.

- 69 -


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 differents niveaux (noyau, interfacage PF KEY permettant la com-

munication entre le noyau et l’espace utilisateur, et les demons en espace utilisateur), m’a fallu

plusieurs semaines. Il a fallu etablir l’etat dans lequel etait les implementations des extensions dans

le projet ipsec-tools.

L’ensemble de ces tests, a commencer par le plus plausible, celui d’un racoon en mode serveur

et client, m’ont 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 configurations non-valides ont ete testees afin de bien valider la bonne remontee d’er-

reur. On peut citer le cas d’une demande de Mode Config alors qu’un XAuth est en cours ou n’a

pas abouti. La passerelle doit refuser toute tentative de Mode Config ou de negociation de Phase

2 tant que l’utilisateur n’est pas correctement authentifie.

A alors debute un travail conception afin de pouvoir integrer ce Mode Config dans le firmware

NETASQ.

- 70 -


IV.2 Extension du format du fichier de configuration

IPSec

IV.2.1 Fichiers de configuration NETASQ et parseurs

Fichiers de configuration

Le module IPSec du firmware NETASQ est base sur la pile IPSec FastIPSec et sur le projet

ipsec-tools.

Toutefois, l’ensemble des modules du firmware NETASQ n’utilise pas directement les fichiers de

configuration des differents projets BSD. NETASQ a, en effet, fait le choix d’avoir ses propres

fichiers de configuration dans un soucis d’independance vis a vis, notamment, du systeme FreeBSD

et des projets BSD sous jacents.

Comment les fichiers NETASQ interagissent-ils avec ceux des modules du systeme ?

NETASQ definit dans un premier temps un format de fichier de configuration, en decrivant l’ensem-

ble des champs necessaires, l’ensemble des valeurs disponibles, les valeurs par defaut, etc. Dans

un second temps, ce fichier de configuration est parse a l’aide de multiples librairies de parsing

developpee par NETASQ. En sortie, on obtient alors un fichier de configuration au format du projet

sous jacent qui est utilise pour executer le module.

L’avantage qu’offre ce choix est de pouvoir garder la meme signature des fichiers de configu-

ration vis a vis du client final. Il arrive que NETASQ doive changer tel projet par tel autre, parce

que des ameliorations ont ete apportees, ou parce que le projet actuel n’est plus maintenu, etc.

Dans ce cas, NETASQ ne peut se permettre de changer de module et de laisser le client final se

debrouiller dans un nouvel environnement qu’il ne maıtrise pas forcement.

Ainsi, lorsque cela arrive, le fichier de configuration NETASQ reste le meme, seules sont modifiees

les librairies de parsing en arriere plan afin d’en sortir le fichier de configuration au format du

nouveau module fraıchement integre. Le client manipule ainsi le meme fichier de configuration.

Exemple

Le module NAT1 utilise est, a l’heure actuelle, le module FreeBSD ipnat.

Le fichier de configuration 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

1NAT - Network Adress Translation

- 71 -

IV.2. EXTENSION DU FORMAT DU FICHIER DE CONFIGURATION IPSEC

Il s’agit du fichier de configuration NAT que j’ai utilise sur mon reseau de travail durant les six

mois de stage.

Bien que la syntaxe du fichier NETASQ ressemble a celle d’ipnat, le parseur permet, a partir du

fichier de configuration NETASQ, d’obtenir le fichier de configuration au format ipnat :

map sis0 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 sis0 from 0/0 to 10.2.29.2/32 port = 5900 -> 192.168.2.1 port 5099 tcp






Il s’agit d’une configuration NAT basique permettant de translate un reseau, en locurrence

192.168.2.0/24, en une adresse IP, en locurrence 10.2.29.2 ; d’une redirection de port ssh,

TCP 22, et d’une redirection de port VNC, TCP 5800 et TCP 5900.

Lorsque dans le cahier des charges des versions futures du firmware, il ne sera plus question

d’utiliser ipnat, si cela arrive, le fichier NETASQ restera le meme. Seul changera la librairie de

parsing qui generera, cette fois ci, un fichier au format du nouveau module NAT.

Le fichier de configuration IPSec est base sur le meme principe, c’est ce fichier que nous nous

proposons d’etendre en vue de l’integration de l’extension Mode Config.

IV.2.2 Conception et extension du fichier

Conception

Apres ma prise en main des appliances NETASQ et le succes 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 l’integration, il a finalement ete decide d’envoyer la configuration reseau suivante

aux clients mobiles :

– Une adresse IP de type RFC 1918 afin que l’interface IPSec du client mobile soit configuree

de telle maniere qu’elle croit etre sur le reseau interne, d’ou tout l’interet.

– Transmettre son extremite distante de trafic pour qu’il puisse negocier les IPSec SA sans

embarquer ces informations de maniere statique sur la machine.

- 72 -


– Transmettre l’adresse d’un serveur DNS2.

– Transmettre l’adresse d’un serveur WINS3

Fichier VPN

Un fichier de configuration NETASQ IPSec se presente de la maniere 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

2DNS - Domain Name System permet la resolution des noms.3WINS - Windows Internet Naming Service permet egalement la resolution de noms pour les systemes utilisant

NetBIOS.

- 73 -

IV.2. EXTENSION DU FORMAT DU FICHIER DE CONFIGURATION IPSEC

Ce fichier de configuration, lorsqu’il sera parse, donne en sortie un fichier de configuration

racoon, qu’on appellera plus simplement le fichier racoon.conf par la suite.

Les differents champs sont volontairement intuitifs, afin de configurer les tunnels IPSec de la

maniere la plus ergonomique possible :

– La section [Tunnel_1_1_1] decrit l’ensemble des parametres de proposition de phase 1. Elle

comprend notamment le groupe Diffie-Hellman, les algorithmes de chiffrement et d’authen-

tification. Cette section donne une partie de la section proposal du racoon.conf.

– La section [Tunnel_1_2_1] decrit l’ensemble des parametres 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.

– Enfin la section [Tunnel_1] permet de configurer l’ensemble des parametres globaux relatifs

au tunnel mis en place. Cela comprend notamment le mode de negociation, la flexibilite de

negociation et les durees de vie proposees.

Les algorithmes de chiffrement et d’authentification sont renseignes dans une table maintenue

a part : l’ajout ou la suppression d’un algorithme se fait ainsi a un seul endroit. Cette facon de

proceder permet de se conformer a des contraintes legislatives en fournissant des versions ne com-

portant que certains algorithmes ou ne rendant possible l’utilisation que de certaines longueurs

de clef. Ceci est particulierement utile lorsqu’il s’agit d’exporter les appliances NETASQ vers des

pays ou l’Europe impose une legislation differente en terme d’algorithmes de chiffrement.

Definition des champs

Lors de la conception des differents champs destines a etre integre, l’accent a ete mis sur le fait

d’avoir une architecture peu gourmande en terme de taille de fichier.

Il existe deja un champ dst dans le fichier de configuration NETASQ : ce champ definit l’extremite

distante de trafic d’un tunnel IPSec. Parralelement, le champ src definit l’extremite locale de trafic

correspondante.

D’autre part, nous avons fait le choix de n’autoriser le Mode Config que dans le cas des road

warriors, c’est a dire dans le cas ou les adresses IP ne sont pas connues a l’avance, c’est a dire dans

le cas de configurations anonymes.

On se rend compte que l’extremite de trafic distante (definit par dst) est en fin de compte

limitee a une seule adresse, celle que l’on souhaite transmettre en Mode Config : les extremites

distantes de tunnel et de trafic sont confondues.

Il est ainsi judicieux d’utiliser le champ dst deja defini en tant que pool d’adresses IP a transmettre

aux differents clients, dans le cas d’une configuration en Mode Config.

Pour recapituler, lorsque l’option Mode Config n’est pas activee, le champ dst se comporte

comme etant l’extremite de trafic distante. Lorsque l’option Mode Config est activee, le champ dst

se comporte comme pool d’adresses IP. Une adresse est prise dans le pool et transmise au client.

- 74 -


L’activation de l’option Mode Config se fait par la definition de quatres champs crees a cette

fin :

cfg dns : Ce champ definit le serveur DNS a transmettre en Mode Config. Ce champ sera parse

en dns4 dans le racoon.conf.

cfg wins : Comme DNS, ce champ definit un serveur WINS a transmettre et sera parse en wins4.

cfg src : Ce champ peut etre positionne a 1 pour l’activer ou 0, valeur par defaut, permet de

transmettre l’extremite locale de trafic 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-

jourd’hui embarquee statiquement sur les machines. Dorenavant, elle pourra etre transmises

a la volee, par Mode Config, suivant l’identite du client qui se presente.

cfg dst : Positionnable a 1 ou 0, valeur par defaut. Il s’agit du pool d’adresses IP disponibles

definit sous la forme d’un reseau et masque correspondant. A titre d’exemple, 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 Integration et validation

IV.3.1 Imperatifs d’implementation

Implementer les fonctions dans la librairie afin de parser les quatres champs ne suffit pas pour

generer des configurations correctes. Il a fallu verouiller plusieurs champs afin qu’il ne puissent

interferer avec certaines configurations bancales ou interdites.

Le tout premier verrou a ete celui de l’utilisation du Mode Config uniquement dans le cadre

des road warriors. Rien n’empeche, en effet, a racoon de transmettre des informations en Mode

Config a un hote distant (( classique ))qui soit lui meme une passerelle IPSec. Les tentatives d’util-

isation du Mode Config lorsqu’il ne s’agit pas d’un tunnel anonyme n’aboutiront plus.

Ensuite s’est pose le probleme du champ dst qui peut tres bien etre positionne a any, l’ensemble

du trafic a destination de cet hote est alors du trafic IPSec. Dans le cas du Mode Config (donc le

champ cfg_dst = 1 , le champ dst ne peut valoir any, puisque dans ce cas, on ne definit aucun

pool d’IP dans lequel racoon pourrait piocher. Cette configuration a donc ete interdite egalement :

l’utilisation du Mode Config pour la transmission d’adresses RFC1918 impose la definition du

champ dst.

Les objectifs du cahier des charges ont ete correctement remplis, les imperatifs d’implementation

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, l’on a pu tester les quatres champs, d’abord un par un, puis en

essayant les combinaisons des differents champs :

[Tunnel_3_2_1]

Mode=ESP,TUNNEL

- 75 -

IV.3. INTEGRATION 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 Config ont ete definis. Au moment de l’activation de la configuration,

le fichier racoon.conf est genere et racoon est demarre. Si le parsing echoue ou s’il n’est pas valide,

racoon ne demarrera pas. On peut verifier 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 Config est tout a fait correctement cree et les differents champs correctement

positionnes :

– Dns4 et Wins4 correspondent aux serveurs de noms a transmettre.

– Split network include correspond a l’extremite locale de trafic a transmettre, a savoir le

champ src du fichier NETASQ.

– Les trois derniers definissent la maniere dont les road warriors se voient attribuer leur

adresse IP RFC1918. On dispose ici d’un pool d’IPs de 254 adresses disponibles sur le reseau

10.2.29.0/24.

L’action de l’option Mode Config en elle meme aurait pu etre definie par un champ specifique.

Finalement, la presence d’un seul des quatres champs Mode Config suffit a activer l’option Mode

Config.

IV.3.3 Validation et Commit dans le firmware

Une fois les premiers tests passes avec succes, la nouvelle librairie de parsing et le nouveau

module IPSec ont ete testes et valides par l’equipe de Qualification au laboratoire R&D NETASQ.

NETASQ dispose, pour ses tests de validation et de non regression, entre autres, de deux Spirent.

La societe Spirent offre des solutions de tests, validation et monitoring de services reseaux. Sont

- 76 -


notamment testes le routage, la QoS, les protocoles Wireless, IPSec, etc.

Malheureusement, les systemes Spirent ne supportent pas le Mode Config et n’ont donc pas pu

etre mis a contribution lors de la validation du code.

Les tests ont ete realises avec ShrewSoft, non plus avec racoon d’ipsec-tools en face comme

nous l’avions fait lors de nos tests preliminaires, mais en face d’une appliance NETASQ integrant

le Mode Config dans son module IPSec.

L’ensemble des tests se sont deroules avec succes : la recuperation des informations en Mode

Config est correcte, les configurations interdites sont bien ignorees et les erreurs adequates sont

remontees a l’administrateur a chaque fois.

L’ensemble du code a donc pu etre officiellement integre dans le firmware NETASQ. Lors de

la prochaine sortie de version majeure, la version 8.0, dont la sortie officielle est prevue durant le

dernier trimestre de cette annee, les clients disposeront d’une option Mode Config 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 l’utilisation du Mode Configuration d’IPSec devraient arriver dans le courant du

premier trimestre 2009. Pourtant, lors de mon arrivee a NETASQ rien ne predisait que le Mode

Configuration puisse etre effectivement 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

firmware NETASQ.

Le stage sur IPSec et sur le Mode Configuration en particulier avait pour objectif de debroussailler

l’implementation de cette extension dans ipsec-tools avant tout : evaluer l’etat de l’implementation

actuelle du Mode Configuration a travers des tests sur des maquettes montees pour l’occasion,

evaluer les performances et confirmer ou infirmer la stabilite de racoon confronte a des configura-

tions reseaux complexes et pas forcement valides du point de vue des draft et des RFCs.

L’ensemble des tests effectues sur le Mode Configuration ont ete concluants, que racoon soit

en mode serveur ou en mode client : l’ensemble des informations sont transmises correctement a

la volee, juste apres l’etablissement de la ISAKMP-SA4.

Apres avoir valide de nombreuses configurations, j’ai pu mettre l’accent sur l’etude du produit en

lui meme, l’appliance NETASQ et son firmware : les differents modules en general, le processus

de ports de FreeBSD, l’ASQ, coeur du firmware, le fonctionnement par fichiers de configurations

NETASQ et leur librairies de parsing, la communication entre la suite graphique et le firewall, etc.

La prise en main de l’appliance NETASQ et l’etude du firmware ont ete facilitees par les certifi-

cations NETASQ Certified Administrator - NCA et NETASQ Certified Expert - NCE

que j’ai eu l’honneur de pouvoir passer.

4Sous reserve que l’authentification XAuth soit desactivee, si ce n’est pas le cas, les informations sont transmises

juste apres la validation de l’authentification en XAuth.


Cette etape a marque le debut du travail sur le firmware : integrer le Mode Configuration en

tenant compte de toutes les contraintes existantes. Ces contraintes ont ete de plusieurs ordres.

– Prendre en main le code des librairies de parsing deja existant.

– Tenir compte du fichier de configuration existant et l’etendre dans la mesure de l’acceptable :

pas d’ajout de champs inutiles, pas de configuration supplementaire non necessaire pour le

client.

– Comportement par defaut correct si le Mode Configuration n’est pas active. Il s’agit de

l’implementer comme une option a part entiere, 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 l’apparition des nouveaux

champs que la suite graphique ne connait pas.

La prise en compte de l’ensemble de ces contraintes a ete sujette a plusieurs discussions fructueuses,

et a finalement mene a la creation des quatres champs Mode Configuration implementes dans le

firmware.

Une fois le Mode Configuration implemente, valide et operationnel, j’ai pu me concentrer sur

l’amelioration de l’implementation du Mode Configuration d’ipsec-tools par l’etude d’un nou-

veau champ dans racoon : le champ CLIENTADDR. Le CLIENTADDR permet de matcher l’identite de

l’hote distant suivant qu’il s’agisse de l’adresse IP de l’hote ou de l’adresse IP RFC1918 definie

dans la configuration Mode Configuration, 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 deja realise une partie de l’implementation sur la branche

principale du projet ipsec-tools. J’ai porte le champ de la branche principale vers la version

stable d’ipsec-tools actuelle, 0.7.1.

Tout au long des six mois passes a NETASQ, plusieurs idees recues de l’etudiant terminant son

cursus ont ete bousculees, a juste titre et tant mieux. J’ai, avant tout, pu constater qu’il ne suffit

pas d’avoir une conception parfaite une bonne implementation pour qu’elle puisse etre integree

dans un firmware deja existant et soumis a un certains nombres de contraintes.

- 79 -


Deja fascine par la securite a l’universite, j’ai pu porter un regard different sur ce monde qui

parait toujours renferme et reserve vu de l’exterieur. J’ai ainsi pu suivre l’evolution des failles

OpenSSL et DNS du point de vue d’une societe specialisee en securite informatique ou il fallait

toujours etre sur le qui-vive, suivre les differents PoC5 ou encore etudier les differents articles

et impressions sur de grandes conferences en securite informatique, qu’elles soient francophones

comme le SSTIC, ou internationales comme BlackHat ou DefCon.

Je citerai ici Ferdinand Foch - (( Il n’y a pas d’hommes cultives, il n’y a que des hommes qui se

cultivent ))- tout a fait approprie lorsqu’il s’agit de securite informatique ou de cryptologie.

Pendant toute cette periode, j’ai eu l’honneur d’etre entoure d’ingenieurs extremement competents

dans leur domaine, me permettant d’avoir les meilleurs conseils possibles de la part de la part de

personnes toujours disponibles et a l’ecoute. Je porte aujourd’hui un regard tout a fait different sur

un projet OpenSource, sur l’utilisation subtile des differentes licences (GPL, BSD, Libre, Open-

Source...). J’ai egalement pu ameliorer mon niveau en developpement de facon consequente, en

etant confronte a des styles de programmation differents tout en respectant la charte de program-

mation de NETASQ. D’autre part, j’ai pu remarquer l’aide apportee par la communeaute lorsqu’il

s’agit d’auditer du code source ou de comprendre une RFC ou se chevauchent des subtilites, souvent

anglaises, de termes comme MAY , MIGHT ou SHOULD ne facilitant pas toujours l’integration

de telle ou telle fonctionalite.

Enfin, le plus important a mes yeux concerne le regard critique que j’ai pu adopter face a la

formation que j’ai recue a l’universite. Cette experience m’a non seulement permis d’approndir

certains points cles, mais egalement de poser des bases solides pour commencer une carriere qui,

je l’espere, me permettra d’etre acteur plutot que spectateur dans le monde de la securite infor-

matique.

5PoC : Proof Of Concept

- 80 -

Annexe A : Protocole AH et ESP approfondis

En-tete IP

Les protocoles AH et ESP reposant sur sur IP, une description sommaire des champs d’IP est

donnee dans le tableau ??.

IP est un des protocoles reseau les plus repandu aujourd’hui, dans sa version IPv4 qui commence

a s’essoufler du manque d’adresses disponibles et dans version IPv6 deja massivement deploye au

Japon. Il apporte l’adressage en couche 3 permettant de router les paquets.

Les champs principaux de l’entete IP sont definis de la maniere suivante :

ver : Il s’agit de la version du protocole IP utilise (4 ou 6), code sur 4 bits. Place en tete, il permet

de verifier 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 l’en-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 cout. TOS est l’unique

champ recupere par ESP pour l’encapsulation ESP-Tunnel.

pkt-len : Il s’agit 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 216 = 65535octets.

ID : Code sur 16 bits, le champ Identification permet de reconstituer les differents fragments. Les

en-tetes IP des fragments sont les memes a l’exception de la longueur et du checksum.

Flags : Code sur 3 bits, ces flags permettent de connaıtre l’etat actuel de la fragmentation. Le

premier bit est a 1 (Reserved), le deuxieme autorise ou non la fragmentation (DF Don′t

Fragment) et le dernier indique s’il existe d’autres fragments (MF More Fragments).

frag offset : Code sur 13 bits, indique a quel position se trouve le fragment par rapport au pre-

mier. Le premier possede donc un champ frag offset a 0.


TTL : Le champ Time TO Live indique la duree de vie maximale du paquet. Lorsqu’il baisse a

0, le paquet est detruit. A chaque passage dans un routeur, ce champ sera decremente. Ceci

permet d’eviter les boucles infinies 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 l’IANA - Internet Assigned Number

Security.

Checksum : Code sur 16 bits, la somme de controle permet de verifier la validite du paquet (et

uniquement celle du paquet et non pas des donnees qu’il contient : deux trames IP ayant les

meme champs auront la meme somme de controle).

Src IP address : Represente l’IP source codee sur 32 bits.

Dst IP address : Represente l’IP 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 flags frag offset

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 definir la maniere dont ESP gere les priorites de

communications (par la recuperation du TOS) ou encore a comprendre pourquoi il etait tres dif-

ficile de deployer IPSec a travers des equipements NAT, avant le developpement de l’extentions

NAT − Traversal.

- 82 -


AH - Authentication Header

AH est uniquement utilise pour de l’authentification – pas de chiffrement –. Il permet de valider

l’identite de l’hote distant avec lequel on communique afin de se premunir des attaques MITM. Il

detecte ainsi toute alteration des donnees et offre une protection forte contre le rejeu de paquets.

En-tete AH

L’Authentification est faite a partir d’une empreinte cryptographique d’authentification base

sur l’ensemble des champs non modifiables 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, l’hote distant calcule a son tour une empreinte du paquet fraıchement recu et le compare

avec celui contenu dedans afin 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 l’en-tete AH

Champs de l’en-tete AH :

Next Header : Code sur un octet, il contient le numero de protocol de l’en-tete suivante, donc

le numero de protocole des donnees que le paquet transporte. Ce champ permet de lier les

differentes en-tetes.

AH lengh : Code sur un octet egalement, il contient la taille de l’en-tete AH en mots de 32 bits,

otee de 2 (ceci n’inclue pas les donnees mais l’en-tete uniquement). Les 64 bits sont enleves

afin d’etre coherent avec la maniere dont IPv6 calcule la taille de l’en-tete AH. IPSec dans

IPv6 n’est pas aborde dans ce rapport, on peut en trouver une description a ??.

Reserved : est comme son nom l’indique, un champ reserve pour un usage futur, code sur 16 bits.

- 83 -


SPI : Le Security Parameter Index est un identifiant 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 lorsqu’une SA en-

tre deux hotes est etablie. Il est incremente pour chaque datagramme correspondant a cette

SA. Il permet d’identifier chaque paquet de maniere unique et ainsi de se proteger contre des

attaques par rejeu.

Authentication Data : Contient l’empreinte calculee par le protocole AH.

Comme decrit precedemment, IPSec peut fonctionner suivant le mode Tunnel ou Transport.

AH n’est donc pas calcule de la meme maniere.

AH en mode Tranport

En mode Transport, l’en-tete AH est inseree entre l’en-tete du protocole de Transport (TCP le

plus souvent) et l’en-tete IP (cf Fig. IV.4).

Comme l’en-tete AH vient s’intercaler entre les en-tete TCP et IP, les champs proto sont suc-

cessivement modifies :

Le champ proto du paquet IP, a l’origine en TCP, est modifie au profit 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 n’offrant pas de chiffrement, un attaquant potentiel aura acces non seulement a l’en-tete,

mais egalement aux donnees, bien qu’il ne puisse pas alterer le paquet ou le rejouer.

Une fois que le paquet aura ete valide a la reception, il sera decapsule, l’en-tete AH enleve, les

champs remis a jour et le paquet sera passe a l’application concernee.

AH en mode Tunnel

En mode Tunnel, le paquet IP est entierement reencapsule dans un autre paquet IP avant d’etre

envoye.

Une en-tete AH est aposee au paquet, comme en mode Transport, ce qui permet de valider

l’authenticite du paquet a la reception et de se premunir de l’alteration des paquets sur le chemin.

Mais contrairement au mode AH-Transport, AH-Tunnel encapsule le paquet IP dans sa totalite,

c’est a dire l’en-tete IP et le payload. Les addresses reelles de l’emetteur 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 -


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

IPH

dr

TC

PH

dr+

Plo

adA

HH

dr

TC

PH

dr+

Plo

ad

IPH

drCouvert par AH

Fig. IV.4 – Hash AH en mode Transport

- 85 -


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

IPH

dr

TC

PH

dr+

Plo

adA

HH

dr

TC

PH

dr+

IPH

dr+

Plo

ad

IPH

drCouvert par AH

Dst IP Address

Src IP Address

Prto=TCP Checksum

flgs offset

TOS pkt-lenver len

ID

TTL

Fig. IV.5 – Hash AH en mode Tunnel

- 86 -


Les verifications du paquet arrivant a destination sont les memes qu’en mode Transport : l’

Integrity Check Value est extrait d’une part, calcule sur les differents champs du paquet recu

d’autre part, puis compare. Lorsque le paquet est valide, il est decapsule et delivre a l’application

en attente, ou route vers le sous reseau de destination suivant l’IP reelle. A partir de ce moment,

il s’agit d’un paquet IP normal.

La difference entre le Mode Transport et le Mode Tunnel dans IPSec n’est pas explicite puisqu’il

n’existe pas de champ Mode a proprement parler. Elle se fait au niveau du champ Next Hdr :

lorsqu’il vaut IP, il s’agit du Mode Tunnel puisqu’il encapsule entierement un paquet IP. A l’in-

verse, lorsque ce champ est positionne a un autre protocole de transport comme TCP, UDP ou ICMP,

il s’agit la du Mode Transport qui securise le traffic 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 d’avoir un

chiffrement de toute les donnees presentes dans le paquet et eventuellement de les authentifier.

ESP est constitue d’un header (cf Fig. IV.6) et d’un trailer et peut etre utilise en mode Tunnel

comme en mode Transport tout comme AH.

Le chiffrement des donnees n’est lie a aucun algorithme cryptographique en particulier, comme

explique dans la presentation d’IPSec ??. Les plus couramment utilises sont AES, DES, TripleDES

et Blowfish. Les parametres de chiffrement et la cle utilisee sont dynamiquement negocies par un

demon IKE (racoon d’ipsec-tools en locurrence dans le cadre de notre cahier des charges) et

stockes dans une Security Association.

Les champs d’un paquet ESP sont principalement :

Payload chiffre : Correspond aux donnees chiffrees, de taille variable.

Next Header : utilise comme dans AH, permet de connaıtre le type de payload du paquet, a

savoir IP, TCP, UDP, etc.

Padding : il s’agit de bourrage permettant l’utilisation d’algorithmes cryptographiques par blocs

(comme AES en mode cbc par exemple).

Pad len : Taille du bourrage.

D’autre part, ESP fournit une authentification optionnelle. Lorsqu’elle est activee, l’empreinte

d’authentification vient se greffer apres le trailer ESP et utilise les meme mecanismes que dans AH

a ceci pres que l’authentification ESP est basee uniquement sur l’en-tete ESP et le payload, et non

pas sur le paquet IP en entier.

De l’exterieur, un attaquant ne peut determiner le contenu d’un paquet ESP, ni meme savoir

s’il contient une empreinte d’authentification ou non. Neanmoins, lors de l’encapsulation ESP, le

- 87 -


S P ISequence Number

Encrypted Payload

paddingpad len nxt hdr

S P ISequence Number

Encrypted Payload

paddingpad len nxt hdr

Authentication Data

ES

PT

rlA

uth

ES

PH

dr

ES

PH

drE

SP

Trl

Chiffré

Fig. IV.6 – En-tete ESP avec (a d.) et sans (a g.) Authentification

champ ToS du paquet IP est recupere a partir du paquet original. Ce champ, comme nous l’avons

vu, sert entre autres, a definir 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 pres 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 entierement le paquet IP original dans un autre

paquet IP. C’est ce qui se rapproche le plus d’un tunnel VPN au sens ou la plupart des utilisateurs

l’entendent : un tunnel chiffre parlequel ils peuvent faire transiter des flux sensibles de maniere

securisee afin de contacter un reseau distant.

C’est le mode le plus souvent utilise lorsqu’il s’agit de monter une passerelle IPSec.

- 88 -


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

IPH

drT

CP

Hdr

+P

load

IPH

dr

Chiffré

Authentication Data

padlen nxthdr

padding

nxt=ESP

Authentifié

Fig. IV.7 – Paquet ESP en Mode Transport

- 89 -


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

IPH

drT

CP

Hdr

+P

load

IPH

dr

Chiffré

Authentication Data

padlen nxthdr

padding

nxt=ESP

Authentifié

IP Hdr

Fig. IV.8 – Paquet ESP en Mode Tunnel

- 90 -

Annexe B : Echange Diffie-Hellman

Presentation

L’echange de cles Diffie-Hellman, ou pour etre plus exact, la negociation de cles par Diffie-

Hellman a ete developpe par Diffie 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 s’echanger 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 parametres publics : p, un nombre premier, et g, un generateur,

inferieur a p defini comme suit :

Pour tout entier compris entre 1 et p− 1 inclus, il existe une puissance k de g telle que n = gk

mod p.

Supposons qu’Alice et Bob souhaitent echanger un secret par Diffie-Hellman, ils procedent 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 = ga et Bob calcule y = gb.

– Alice envoie x a Bob et Bob envoie y a Alice.

– Alice calcule alors (gb)a = gab.

– Bob calcule (ga)b = gab.

– Alice et Bob se retrouvent tout deux avec gab.

Le secret partage par Alice et Bob est alors k = gab.


Fig. IV.9 – Protocole Diffie-Hellman - www.plenz.com

Securite et Faiblesses

La securite de l’algorithme Diffie-Hellman repose sur la difficulte du calcul du logarithme discret.

Il suppose qu’il est tres difficile de calculer le secret partage gab a la seule connaissance de ga et de

gb lorsque le nombre premier p est grand. Casser un algorithme Diffie-Hellman est aussi difficile que

de calculer le logarithme discret sous certaines conditions. (Maurer - Advances in Cryptology 1994).

L’echange de cles Diffie-Hellman est vulnerable a des attaques de type Man In The Middle. Un

attaquant potentiel, traditionnellement appelle Oscar, intercepte la valeur publique d’Alice (ga) et

envoie sa propre valeur publique a Bob. Lorsque Bob envoie sa valeur publique, Oscar l’intercepte

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 l’un avec l’autre. Oscar est alors capable de dechiffrer et modifier l’ensemble

du trafic entre Alice et Bob.

Cette attaque fonctionne car les correspondants ne s’authentifient pas au prealable.

Le protocole Diffie-Hellman authentifie a ete developpe en 1992 afin d’empecher l’attaque

MITM. Ce protocole preconise l’utilisation de signatures et de certificats numeriques afin d’au-

thentifier les deux correspondants. Alice et Bob signent alors leur valeur publique a l’aide de leur

cle privee. Il est impossible a Oscar de modifier cette signature sans les cles privees respectives.

- 92 -

Les RFCs IPSec

L’ensemble des implementations actuelles d’IPSec et des demons IKE est basee sur les RFCs

suivantes. Certaines ont ete redefinies 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 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 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.


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 traffic-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 l’utilisation de hashs cryptographiques comme MD5 ou SHA-1, utilise dans l’authentifi-

cation HMAC.

[2] IPSec Technical Reference, Microsoft, Provides informations on Microsoft’s 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 l’utilisation de paquets IPSec chiffres mais non

authentifies, attaques reelles et effectives 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 d’intrusions de reseaux, S. Northcutt, J. Novak, Analyse de trafic, utilisation

des outils d’analyses, 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, O’Reilly, 1992. ipsec-tools : fichiers ecrits en Lexx

et Yacc.

[15] RSA Laboratories Diffie-Hellman, www.rsa.com.

[15] Computer Networks, A. S. Tanembaum, 4eme 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 -

ipsec_netasq

Documents

mode configuration

iv integration

mode transport

protocoles ipsec

module ipsec

rfcs ipsec

stageetude ipsec

deployer ipsec