PFE ASA Firewall

AVOLEDO Mickaël
BENBACHIR Amine
BONET Damien
CAPGRAS Etienne
DESTRAS Olivier
PROJET TUTEURE
CONFIGURATION D’ASA CISCO
Département de Génie Electrique et Informatique

4eme année Réseaux et Télécommunications
2008-2009
Tuteur : M. Vincent NICOMETTE

4RT – 2008/2009 [PROJET TUTEURE – CONFIGURATION D’ASA CISCO]
SOMMAIRE
1
INTRODUCTION
I – ETAT DE L’ART DES TECHNOLOGIES VPN 2
I.1 – Introduction 2
I.2 – Les différentes technologies VPN 2
I.2.a - L2F (Layer 2 Forwarding) et L2TP (Layer 2 Tunneling Protocol) 2
I.2.b – PPTP / GRE 3
I.2.b.i – Présentation 3
I.2.b.ii – PPTP et la sécurité 4
I.2.c – IPSEC 5
I.2.c.i – Vue générale 5
I.2.c.ii – Services offerts par IPsec 5
I.2.c.iii – Les « sous-protocoles » d’IPsec 6
I.2.c.iv – IPsec en mode tunnel et transport 7
I.2.c.v – Association de sécurité et politique de sécurité 8
I.2.d – SSH (Secure Shell) 9
I.2.e – SSL (Secure Socket Layer) et TLS (Transport Layer Security) 9
I.2.e.i – Propriétés et caractéristiques de TLS 10
I.2.e.ii – Fonctionnement de TLS 10
I.2.e.iii – Les VPN TLS 10
I.2.e.iv – Forces et faiblesses des VPN TLS 11
I.3 – Conclusion 11
II – PRINCIPALES FONCTIONNALITES 12
II.1 – NAT (Network address translation) 12
II.2 – QoS (Quality of Service) 12
II.3 – Security Context 12
II.4 – ACL (Access Control Lists) 13
II.5 – IPS (Intrusion Prevention Services) 13
II.5.a – AIP SSM 13
II.5.b – CSC SSM 13
II.6 – Threat detection 13
II.7 – Protection contre l’IP Spoofing 14
II.8 – Normalisation TCP 14
II.9 – AAA (Authentication, Authorization, Accounting) 14
II.9.a – Authentification 15
II.9.b – Autorisation 15
II.9.c – Surveillance 15
II.10 – Les filtres HTTP, HTTPS, FTP 15
II.11 – Limites de connexions 15
II.12 – Différences entre IOS 7 et IOS 8 16
INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS

III – ETUDE DES FONCTIONNALITES VPN 17

III.1 – Gestion du trafic 17
III.1.a – Le principe des niveaux de sécurité 17
III.1.b – Listes de contrôle d’accès 18
III.1.c – Droits des utilisateurs 18
III.2 – VPN IPsec 18
III.2.a – Objectifs 18
III.2.b – Choix pédagogiques 18
III.2.c – Adressage et connectivité 19
III.2.c.i - Présentation 19
III.2.c.ii – Difficultés 20
III.2.d – NAT et VPN Lan-to-Lan 21
III.2.d.i – Présentation 21
III.2.d.ii – Difficultés 22
III.2.e – VPN End-to-Lan 22
III.2.e.i – Présentation 22
III.2.e.ii – Difficultés 24
III.2.f – Améliorations possibles 24
III.2.f.i – Authentification par certificat 24
III.2.f.ii – Gestion de différents types de trafic 24
III.2.f.iii – Utilisation de serveurs d’authentification 24
III.2.f.iv – Utilisation de la configuration automatique du client VPN 24
III.2.f.v – Accès à tous les sites depuis l’hôte distant 25
III.2.g – Bilan 25
III.3 – VPN SSL 25
III.3.a – IOS v7 vs. IOS v8 25
III.3.b – Objectifs 26
III.3.c – Choix pédagogiques 26
III.3.d – Matériel utilisé 27
III.3.e – Difficultés rencontrées 27
III.3.f – Portail WebVPN 27
III.3.f.i – Navigation Web 28
III.3.f.ii – Plugins : accès ssh, VNC, etc… 28
III.3.g – AnyConnect 29
III.3.g.i – Description 29
III.3.g.ii – Comparaison à la solution clientless 30
III.3.g.iii – Fonctionnement 30
III.3.g.iv – Problèmes rencontrés 31
CONCLUSION 32
BIBLIOGRAPHIE 33
GLOSSAIRE 34
TABLE DES ANNEXES 35
INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS

INTRODUCTION
L’idée de la conception de l’Adaptative Security Appliance (ASA) est apparue lors de la mise
en place, par Cisco, de la solution Self-Defending Network (le réseau qui se défend tout seul). En
effet, en associant un pare-feu très puissant à un système qui offre les services VPN, l’ASA est la
solution proposée par Cisco pour garantir un réseau accessible de l’extérieur et sécurisé. Il met en
place une défense face aux menaces, et bloque les attaques avant qu’elles ne se propagent dans le
reste du réseau. Grâce à une interface graphique et une utilisation simplifiée des fonctionnalités,
l’ASA offre aux entreprises qui souhaitent sécuriser leur réseau un outil complet et raisonnablement
facile d’utilisation.
Ce rapport de projet ne se veut pas exhaustif. Nous avons fait en sorte d’y expliquer notre
démarche dans l’étude de deux types de connexions VPN : IPsec et SSL. Notre réflexion, nos
difficultés et les connaissances que nous avons pu retirer de cette étude sont présentés dans le
rapport. L’aspect technique, les commandes Cisco, et une démarche structurée pour aboutir à la
configuration de VPNs SSL et IPsec sont présentés en annexe dans les TP.
INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 1

I – ETAT DE L’ART DES TECHNOLOGIES VPN

I.1 – Introduction
Les technologies de réseaux privés virtuels (VPN, Virtual Private Network) permettent
d’utiliser un réseau non sécurisé dont on ne possède pas la maîtrise (typiquement Internet) pour
relier de manière sécurisée deux sites éloignés géographiquement, en s’affranchissant de l’achat ou
de la location d’une ligne spécialisée.
On distingue principalement deux modes d’utilisation de ces technologies :
- Le mode LAN-to-LAN permet de relier deux sites distants, par un tunnel que l’on pourrait
qualifier de « permanent » entre les routeurs d’entrée des deux sites.
- Le mode End-to-LAN (ou RoadWarrior) permet à un hôte mobile d’accéder aux ressources de
son entreprise de la même manière que s’il était sur site.
Nous allons présenter dans la suite un état de l’art des technologies VPN les plus répandues.
Elles seront résumées afin d’en obtenir une vue générale, formant une base pour lancer notre projet
sur les ASA. Nous avons choisi de présenter les différentes technologies selon leur position dans le
modèle en couche OSI, du bas vers le haut.
I.2 – Les différentes technologies VPN

I.2.a - L2F (Layer 2 Forwarding) et L2TP (Layer 2 Tunneling Protocol)
Le protocole L2F est un protocole créé par Cisco. Il est assez similaire à PPTP étant donné
qu’il démarre par l’ouverture d’une connexion PPP du client vers le fournisseur d’accès Internet.
Cependant, contrairement au protocole PPTP (voir plus bas), le tunnel est ici transparent
pour le client. C’est le NAS du FAI qui met en place le tunnel entre lui-même et le serveur d’accès du
réseau distant : c’est le compulsory mode, par opposition au voluntary mode utilisé par PPTP. Cela
entraîne une perte de la maîtrise de la sécurité vu que les données seront visibles par le FAI. L2F est
adapté aux VPN LAN-2-LAN alors que PPTP est plus utilisé pour des VPN End-2-LAN.
Le protocole n’est guère utilisé, il a été remplacé par le protocole L2TP. L2TP consiste à
encapsuler des paquets PPP dans des paquets IP, X.25, Frame Relay ou ATM. Il est utilisé comme
protocole de tunneling à travers Internet en encapsulant avec IP. L2TP met en place deux sessions
PPP, la première entre l’ordinateur distant et le NAS du FAI, la seconde entre l’ordinateur distant et
le NAS du réseau auquel on se connecte.
Encapsulation successive des données avec L2TP :
PPP IP UDP (port 1701) PPP IP TCP,UDP Données

Le LAC (L2TP Access Concentrator) enlève l’entête PPP et envoie le paquet IP au LNS (L2TP
Network Server). Celui-ci lit l’entête UDP et détermine que le protocole L2TP est utilisé grâce au port
réservé 1701. Il traite les informations spécifiques à L2TP telles que l’identifiant du tunnel puis
transmet le paquet PPP au NAS. Le NAS envoie finalement le paquet IP au destinataire.
L2TP assure l’authentification et le support multi-protocole grâce à l’utilisation de PPP,

cependant il n’assure aucunement une sécurisation des données. C’est pourquoi L2TP est souvent
associé à IPsec en mode transport. Cette association permet également d’assurer l’intégrité des
données.
L2TP/IPsec permet de créer des VPN de toutes sortes : End-2-End, End-2-LAN ou LAN-2-LAN.
I.2.b – PPTP / GRE

I.2.b.i – Présentation
PPTP est une extension du protocole PPP, crée par Microsoft. Il est généralement utilisé pour
les VPN de type RoadWarrior, c'est à dire qu'il n'est pas destiné à établir un lien permanent entre
deux réseaux. Il sera utilisé par un employé en déplacement qui veut se connecter au réseau de son
entreprise ou pour des connexions temporaires.
L'utilisation de PPTP nécessite trois machines : un client PPTP, un serveur PPTP et un serveur
d'accès réseau. Dans les petites installations, le serveur d'accès réseau n'existe pas car le client a
accès directement au réseau, la première connexion PPP, présentée ci-dessous, est donc inutile.
Le client va d'abord établir une connexion PPP avec le serveur d'accès réseau. Cette
connexion permet l'authentification auprès du fournisseur d'accès. Il aura alors accès à internet et
pourra se connecter sur le serveur PPTP. Il va ensuite établir 2 connexions avec le serveur. La
première sera une connexion de contrôle. Une deuxième connexion, qui utilise la première, sera
ensuite établie pour le transfert des données.
Le schéma suivant résume bien cela :

Connexion de contrôle :
Elle se fait en TCP sur le port 1723. Le protocole PPTP spécifie une série de messages de
contrôle envoyés entre le client PPTP et serveur PPTP. Les messages de contrôle établissent,
maintiennent et terminent le tunnel PPTP.
Connexion de transmission de données :
Quand le tunnel PPTP est établi, les données utilisateur sont transmises entre le client et le
serveur PPTP. Les données sont transmises dans des datagrammes IP encapsulant des paquets PPP.
Les datagrammes IP sont créés en utilisant une version modifiée du protocole Internet Generic
Routing Encapsulation (GRE). GRE est un protocole qui permet d'encapsuler n'importe quel paquet
de la couche réseau dans n'importe quel paquet de la couche réseau. Ici, il est donc utilisé pour
encapsuler le paquet PPP dans le datagramme IP.
Les paquets PPP encapsulés peuvent contenir différents protocoles comme illustré ci-dessous :
I.2.b.ii – PPTP et la sécurité
Lorsqu'on se connecte à un serveur PPTP, on a accès au réseau privé du serveur, la sécurité

est donc très importante pour éviter tout abus.
L'authentification se fait par login et mot de passe. Tout d'abord au niveau du serveur d'accès
réseau (première connexion PPP) puis au niveau du serveur.

Au niveau du serveur PPTP, elle se fait à l'aide du protocole Ms-CHAPv2, qui permet
l'échange du mot de passe entre les deux parties en toute sécurité. Le cryptage des données se fait
avec le protocole RSA. La clef est générée à partir du login et du mot de passe du client.
Le serveur peut autoriser ou refuser l'accès à son réseau privé à des clients. Une connexion
PPTP peut être autorisée à travers un firewall en autorisant le port 1723 pour la connexion de
contrôle et le port 43 pour GRE.
I.2.c – IPSEC
I.2.c.i – Vue générale
IPsec est probablement le protocole VPN le plus utilisé aujourd’hui. Il fit son apparition en
1995, lors de la publication des RFC 1825 à 1829. On le retrouve désormais dans la RFC 2401. Il prend
en charge les trois composantes d’un VPN, à savoir le transport, l’authentification et la sécurisation
des données.
Pour simplifier son intégration dans les futurs réseaux IP, il fut directement intégré à IPv6.
Pour IPv4, il agit comme une couche supplémentaire. Nous parlerons ici de son implémentation dans
IPv4.
IPsec peut fonctionner selon deux modes, selon ce que l’on veut en faire : mode tunnel et
mode transport. On pourra également faire une combinaison de ces deux modes, on parlera alors de
mode nesting (non détaillé par la suite. Il s’agit en fait d’encapsuler IPsec dans de l’IPsec). Dans la
suite de cet exposé, nous allons détailler les protocoles nécessaires à IPsec pour fonctionner, puis
nous verrons comment utiliser ces protocoles pour IPsec en mode tunnel et IPsec en mode transport.
Avant d’entrer dans les détails, examinons tout d’abord les services offerts par IPsec.
I.2.c.ii – Services offerts par IPsec
Voici la liste des services pouvant être offerts par IPsec. Notons bien que selon le mode
utilisé, tout ou partie de ces services seront disponibles.
- Authentification des extrémités :

Chaque extrémité du tunnel va s’identifier avant d’entamer la communication des données. Cela
permet de s’assurer que l’on dialogue avec la personne convenue. De plus, pour chaque paquet
échangé, IPSec permettra de s’assurer qu’il a été émis par la bonne machine (authenticité des
données).
- Confidentialité des données :

Evite que quelqu’un qui intercepterait les données ne puisse les interpréter. On utilisera pour cela
des techniques de cryptographie.
- Intégrité des données :

IPsec permet de s’assurer qu’un paquet n’a subit aucune modification durant son trajet.

- Protection contre le rejeu :

Ce service permet d’empêcher les attaques consistant à envoyer un paquet valide intercepté (pas
forcément décrypté) afin de bénéficier par la suite des mêmes autorisations que ce paquet pour
entrer dans le réseau.
I.2.c.iii – Les « sous-protocoles » d’IPsec
IKE (Internet Key Exchange)
IKE est un protocole dit administratif, car il ne permet pas de transférer des données
utilisateur. Il permet d’échanger des clefs de cryptage afin de garantir la confidentialité des données.
Au cours de la communication, ces clefs sont renouvelées à plusieurs reprises. Le protocole IKE étant
assez complexe, nous ne le détaillerons pas plus ici. Il est expliqué dans le détail dans la RFC 2409.
AH (Authentication Header)
AH permet d’assurer l’intégrité des données en mode non connecté ainsi que
l’authentification de l’origine des datagrammes IP. Il permet également de se protéger contre le
rejeu. Par contre, il n’assure pas la confidentialité des données (pas de cryptage).
La protection contre le rejeu est assurée par l’ajout d’un numéro de séquence.
L’authentification et l’intégrité sont mises en place par un champ ICV (Integrity Check Value), qui est
en fait la signature des données (et de l’en-tête IP d’origine pour le mode tunnel). Les champs
variables comme le TTL ne sont pas signés. Il est à noter que comme AH signe l’adresse IP source, il
interdit tout mécanisme de translation d’adresses.
AH ne spécifie pas d’algorithme particulier. Ces derniers sont décrits séparément, ce qui
permet plus de souplesse pour IPsec. Cependant, une implémentation conforme à la RFC 2402 est
tenue de respecter les algorithmes de hachage les plus courants : MD5 et SHA-1.
Voici l’en-tête AH :
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Next header Length 0
Security Parameters Index
Sequence number
Authentication Data
Nous reviendrons sur le champ SPI par la suite.

ESP (Encapsulating Security Payload)
ESP assure les fonctions réalisées par AH, auxquelles il rajoute la confidentialité des données
et la protection partielle contre l’analyse de trafic (en mode tunnel). L’IETF a choisi récemment de
rendre optionnelle l’implémentation de AH. On peut supposer qu’à moyen terme, les équipements
n’implémenteront plus AH, mais uniquement ESP.
Comme AH, ESP ne spécifie pas d’algorithme particulier, qui sont décrits séparément. Mais,
conformément à la RFC 2406 (remplacée par la RFC 4303), toute implémentation sera tenue de
supporter l’algorithme de chiffrement DES en mode CBC, ainsi que les algorithmes de hachage MD5
et SHA-1.
Voici l’en-tête ESP :
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Security Parameters Index
Sequence number
Payload data
Padding … Pad length Next header
Authentication data
On remarquera un champ padding, dû au fait que les algorithmes de hachage travaillent sur
des longueurs fixes.
I.2.c.iv – IPsec en mode tunnel et transport
Mode transport
Le mode transport offre une protection aux protocoles de niveau supérieur (TCP, UDP). Il
n’assure pas de protection contre l’analyse de trafic, car il ne modifie pas la partie IP.
On peut utiliser AH si la confidentialité des données n’est pas essentielle ou si elle est assurée
par une autre couche, ou ESP si on veut s’assurer de la confidentialité des données. En mode
transport, les données sont prises au niveau de la couche 4 du modèle OSI (couche transport). Elles
sont cryptées (si ESP) et signées avant d’être transmises à la couche IP.

Mode tunnel
En mode tunnel, l’encapsulation IPSec a lieu après que les données envoyées par
l’application aient traversé la pile de protocoles jusqu’à la couche IP incluse. On peut alors signer et
crypter (si ESP) les adresses.
Ainsi, si on utilise AH, on signera l’intégralité (sauf champs variables) du paquet IP encapsulé
pour s’assurer de son intégrité et de son authenticité. Avec ESP, le paquet sera en plus entièrement
crypté, permettant de s’assurer de la confidentialité des données, et de se protéger partiellement
contre l’analyse du trafic en cryptant les adresses IP source et destination.
Résumé des modes tunnel et transport
Le schéma ci-dessous permet de se faire une idée plus claire des différences entre les deux
modes :
I.2.c.v – Association de sécurité et politique de sécurité
Pour finir avec IPsec, nous allons présenter deux types d’objets nécessaires à la gestion locale
de ce protocole (sur un hôte ou une passerelle).
SA (Security Association)
Une association de sécurité caractérise un demi-canal IPsec entre deux entités, c'est-à-dire :
une source, une destination, un sens de communication, des protocoles utilisés (pour
l'authentification, le chiffrement, la compression), des algorithmes cryptographiques, leurs
paramètres et les clés utilisées. Chaque SA est repérée par un SPI (Security Parameter Index, que l’on
a déjà vu dans AH et ESP). La base des SA valides au niveau d'une entité IPsec est la SAD (Security
Association Database).

SP (Security Policy)
Une politique de sécurité IPSec est une règle indiquant quel traitement appliquer à tel type
de flux, un peu à la manière d’une règle de pare-feu. L’ensemble des SP est regroupé, au niveau d’un
hôte ou d’une passerelle, dans une base de données, la SPD (Security Policy Database).
Lorsque les clés sont gérées dynamiquement par IKE, on définit manuellement des SPD
symétriques sur chaque extrémité du VPN et on laisse les services IKE négocier et établir les SA.
I.2.d – SSH (Secure Shell)

Secure Shell est un protocole de communication sécurisé permettant de tunneliser des
protocoles de niveau 4 par redirection des ports TCP. Sa première version a été développée en 1995
par le finlandais Tatu Ylönen et se concentrait sur la sécurisation des commandes telles que telnet et
rlogin. La version 2 est la version actuelle et apporte de nouveaux algorithmes et de nouveaux
services (tunnelisation, port forwarding, clés privées sécurisées...); elle a été standardisée par l'IETF
en janvier 2006 au travers des 4 RFCs 4251, 4252, 4253, 4254.
SSH utilise des techniques de chiffrement symétriques et asymétriques, l'algorithme de

Diffie-Hellman et divers algorithmes de hachage, garantissant ainsi l'authentification du serveur et du
client et la confidentialité et l'intégrité des données.
La tunnelisation des flux TCP se fait par redirection de port, selon le principe suivant :
I.2.e – SSL (Secure Socket Layer) et TLS (Transport Layer Security)

SSL est un protocole s'appuyant sur la couche 4 du modèle OSI afin d'offrir des services de
sécurité aux couches supérieures. Il a été développé par Netscape en 1994. Sa troisième version a été
soumise à l'IETF en 1996 afin qu'il soit standardisé. C'est ainsi qu'en 1999, après quelques minimes
modifications, est apparu TLS dans sa première version (RFC 2246). Ainsi, SSLv3 et TLSv1 sont quasi-
identiques et c'est pourquoi dans la suite de cet exposé nous utiliserons indifféremment les termes
SSL et TLS.
I.2.e.i – Propriétés et caractéristiques de TLS
TLS garantit confidentialité, intégrité et non-rejeu des données entre deux applications en
communication. A l'origine développé pour sécuriser l'accès à des applications Web, il est désormais
possible de créer des tunnels SSL (applications Stunnel, SSL Wrapper, OpenSSL). Il est à noter que TLS
n'est utilisable que pour la sécurisation de flux TCP. En effet, afin d'optimiser les temps de
transactions, TLS établit des sessions seulement lors de la première connexion entre deux hôtes. Or,
par rapport à UDP, seul TCP permet l'établissement et le maintien de ces sessions. En pratique, la
connexion TLS s'établit une fois la connexion TCP établie, offrant alors les mécanismes suivants:
- échange sécurisé des clés de chiffrement

- authentification du serveur (optionnelle mais très recommandée)
- authentification du client (optionnelle et moins utilisée)
I.2.e.ii – Fonctionnement de TLS
I.2.e.iii – Les VPN TLS
L'utilisation de SSL pour les VPN n'a à ce jour abouti à aucune standardisation complète, de
ce fait les implémentations peuvent varier d'une passerelle à une autre. Cependant, ces différentes
implémentations possèdent des similitudes. En effet, afin de traverser facilement les pare-feu, les
communications entre un terminal et une passerelle se font systématiquement sur le port TCP 443,
qui correspond à HTTPS. Les VPN SSL peuvent s'employer pour interconnecter des sites distants ou
pour permettre aux nomades d'accéder aux ressources d'un intranet.

Interconnexion de sites et TLS
Les paquets IP doivent êtres encapsulés dans un protocole compatible avec TCP.
L'authentification peut être réalisée soit par la couche TLS, soit par le protocole d'encapsulation.
Nomadisme et TLS
L'accès aux ressources se fait par une passerelle, encore appelée serveur mandataire inversé
à cause de son fonctionnement. L'accès aux ressources peut s'effectuer par un simple navigateur
web, ou nécessite des logiciels spécifiques installés sur la machine du client. On parle respectivement
d'applications clientless et non clientless.
 Clientless
Ce mode permet d'accéder à des applications web, webisées et émulées. Les exemples les
plus courants sont le webmail et l'intranet, mais il existe aussi des interfaces html d'applications
basées sur d'autres protocoles (smb ou ftp pour le stockage de fichiers), et d'autres cas plus poussés
où l'exécution d'applets Java et de codes ActiveX peut être nécessaire.
 Non clientless
Dès lors qu'une application spécifique doit accéder aux ressources, il est nécessaire
d'encapsuler tous les flux de cette application dans un flux TLS. C'est le rôle des clients TLS dont on
distingue deux types :
- client léger : établit une connexion TCP à la passerelle. Le terminal n'étant pas accessible
depuis l'intranet, les serveurs ne peuvent pas initier de connexions vers lui. C'est le rôle de la
passerelle, qui sera l'intermédiaire entre les serveurs internes et le terminal.
- client lourd : se connecte à la passerelle et acquiert une adresse IP dans l'intranet. Dès lors, le
terminal est considéré comme hôte du réseau. Ce mode est très proche des VPN IPsec.
I.2.e.iv – Forces et faiblesses des VPN TLS
TLS permet d'accéder aisément aux ressources d'un réseau. De plus, tant que les applications
sont basées Web, aucun client VPN ne doit être installé, configuré et lancé par l'utilisateur avant de
pouvoir accéder aux ressources. L'utilisation est donc plus facile pour les utilisateurs finaux.
L'échange sécurisé de clés de chiffrement garantit une excellente sécurité tant au niveau de la
confidentialité que de l'intégrité des données.
Cependant, TLS ne peut fonctionner que sur TCP, ceci peut poser problème dans le cas
d'utilisation d'applications temps réel comme les conférences audio/vidéo où la retransmission
systématique des paquets est pénalisante. De plus, le cryptage des données ne s'effectue que sur les
données applicatives, laissant les en-têtes des couches transport et réseau en clair, ce qui permet
déjà de collecter un grand nombre d'informations.
I.3 – Conclusion
Les technologies VPN présentées dans cet état de l’art sont les plus couramment utilisées, et
s’appliquent à différents niveaux du modèle OSI. Un utilisateur choisira tel ou tel VPN en fonction de
ses besoins et de ses moyens.

II – PRINCIPALES FONCTIONNALITES
L’ASA offre deux modes pour ses utilisateurs :
 Le mode « routed » est de niveau 3 : quand il y a du trafic, l’ASA est comme un saut sur
un routeur (« router hop in the network »)
 Le mode « transparent » est de niveau 2 : Il facilite la configuration du réseau. Le mode

transparent permet de cacher le pare-feu (aux intrus éventuels). On utilise aussi le mode
transparent pour du trafic qui ne serait pas autorisé par un routeur. Par exemple, il
permet d’autoriser du multicast en utilisant une ACL EtherType.
Par défaut, l’ASA est en mode « routed ».
L’ASA offre de nombreuses fonctionnalités, majoritairement de sécurité. Nous vous

présenterons dans la suite de cette partie celles qui nous paraissent les plus intéressantes, en
soulignant que l’ASA offre beaucoup de fonctionnalités qui ne seront pas abordées.
II.1 – NAT (Network address translation)

L’ASA est en partie un routeur. Il est donc logique qu’il offre du NAT : Il permet de
transformer les adresses privées en adresses publiques afin de pouvoir avoir accès à des réseaux
externes (exemple : réseau internet).
II.2 – QoS (Quality of Service)

La QoS est un gestionnaire de trafic qui permet d’allouer les ressources réseau aux
applications selon leur poids et leur priorité. En effet, dans le cas d’une vidéoconférence, il doit faire
de telle sorte à fournir un débit suffisamment important pour obtenir une image et une voix
acceptable.
Pour implémenter la QoS, il faut :

 Spécifier des classes de trafic
 Associer des actions à chaque classe de trafic afin de former une politique QoS
Une classe de trafic est un ensemble de trafics qui peut être identifié par le contenu de ses
paquets. Par exemple, le trafic TCP dont le port à une valeur de 80 peut être mis dans la classe
« trafic http ».
II.3 – Security Context

Un ASA peut être partitionné en de multiples périphériques virtuels, appelés « Security
Context ». Chaque contexte est un périphérique indépendant, ayant ses propres règles de sécurité,
interfaces, et administrateurs. Avoir de multiples contextes équivaut à avoir plusieurs appareils
indépendants. Plusieurs fonctionnalités peuvent y être utilisées, comme les tables de routage, les
fonctionnalités de pare-feu, l’IPS et l’administration. Par contre, le VPN et les protocoles de routage
dynamiques ne sont pas supportés.
II.4 – ACL (Access Control Lists)

A chaque interface connectée à l’ASA, un numéro de sécurité (entre 0 et 100) est attribué. Le
réseau intérieur se voit attribué par défaut le numéro 100 et le réseau extérieur le numéro 0. Sans
aucune spécification de la part de l’utilisateur, l’ASA interdit le trafic d’une interface vers une autre
interface dont le numéro de sécurité est supérieur. Il autorise d’un autre coté le trafic vers un niveau
de sécurité inférieur. Les Access Lists (ACL) ont été mises en place pour pouvoir interdire ou autoriser
certains trafics d’une interface vers une autre. Elles sont composées d’ACE (Access Entries). Chaque
ACE autorise ou refuse un trafic, en spécifiant l’adresse source et destination ainsi que le protocole.
Il existe deux types d’ACL : extended et EtherType. Les ACL extended concernent le trafic de
type IP, tandis que les ACL EtherType concernent le trafic non-IP. On ne peut appliquer qu’une seule
ACL de chaque type à une interface.
On soulignera qu’en autorisant un trafic de type TCP dans un seul sens, l’ASA l’autorise dans
les deux sens étant donné la connexion qui se met en place entre les deux machines ; pour les trafics
sans connexion (exemple : ICMP), la déclaration doit se faire dans les deux sens.
II.5 – IPS (Intrusion Prevention Services)

Les ASA de la gamme 5500 peuvent utiliser l’AIP SSM. C’est un module de prévention
d’intrusion qui surveille et effectue des analyses en temps réel du trafic sur le réseau en cherchant
les anomalies et les mauvais usages basés sur une bibliothèque de signatures étendue.
Lorsque le système repère une activité non-autorisée, il peut mettre fin à la connexion en
cours, bloquer l’hôte attaquant, enregistrer l’incident, et envoyer une alerte au gérant du réseau. Les
autres connexions légitimes continuent à fonctionner indépendamment, sans interruption.
II.5.a – AIP SSM

L’AIP SSM utilise un logiciel d’IPS (Intrusion Prevention Services) avancé qui fournit un service
de protection pour stopper le trafic malicieux, notamment les vers et les virus réseau, avant qu’ils
n’affectent le reste du réseau.
II.5.b – CSC SSM

Il fournit une protection contre les virus, les spywares, les spams et tout autre trafic non-
désiré en scannant les paquets FTP, HTTP, POP3, et SMTP que l’utilisateur lui demande de scanner.
II.6 – Threat detection

L’ASA fournit une fonctionnalité très importante sous deux formes : la détection de menaces
et la détection basique de menaces.
La détection basique de menaces est celle qui est installée par défaut sur l’ASA. C’est celle-ci
que l’on abordera rapidement (l’autre détection de menaces est à configurer par l’utilisateur).

La détection basique de menaces détecte les activités qui pourraient être liées à une attaque,
comme une attaque DoS (Deny of Service). Elle surveille le taux de paquets abandonnés et les
évènements liés à sécurité, à la recherche des éléments suivants :
 Refus par une ACL

 Mauvais format de paquet
 Limite de connexions atteinte
 Attaque Dos détectée
 Paquets ICMP suspects
 Surcharge sur une interface
 Paquets ayant échoué l’inspection d’applications
 Attaque « scanning » détectée
 Détection de session incomplète (ex : attaque TCP SYN détectée)
Lorsque l’ASA détecte une menace, il envoie un log au système. La détection basique de menaces
n’a un impact, sur les performances de l’ASA, que lorsqu’il y a des abandons de paquets ou qu’une
menace est détectée. Mais même dans ce cas, l’impact est quasi-insignifiant.
II.7 – Protection contre l’IP Spoofing

Pour se protéger contre cette menace, l’ASA inclut l’Unicast Reverse Path Forwarding
(Unicast RPF), que l’on peut activer sur une interface. L’Unicast RPF donne l’instruction à l’ASA de
regarder également l’adresse source (et non pas uniquement l’adresse de destination). En effet, pour
chaque trafic que l’on autorise l’ASA à laisser passer, il crée une table de routage qui contient
également la route vers l’adresse source. Il lui suffit donc d’observer l’adresse source et la table de
routage afin de détecter les menaces.
II.8 – Normalisation TCP

La normalisation TCP est une fonctionnalité qui permet à l’administrateur réseau de rajouter des
critères à la liste de ceux existants pour le scan d’un paquet TCP. En effet, cela offre la possibilité par
exemple de :
 Vérifier le checksum
 Autoriser les paquets dont la taille des données dépasse la limite des paquets TCP
 Abandonner les paquets SYN contenant des données
II.9 – AAA (Authentication, Authorization, Accounting)

AAA permet à l’ASA de savoir qui est l’utilisateur (authentification), ce qu’il est autorisé à
faire (autorisations), ainsi que ce qu’il fait. Il offre ainsi une sécurité supplémentaire.
En effet, supposons que l’ACL autorise le trafic Telnet du réseau interne vers un réseau
externe. N’ayant pas accès aux adresses IP des quelques utilisateurs étant autorisés à se connecter
par Telnet, AAA permet l’authentification au moment de la connexion.

L’ASA peut également transmettre ces données à un serveur Radius ou TACACS.
II.9.a – Authentification
Elle vérifie le nom d’utilisateur et le mot de passe. On peut configurer l’ASA à mettre en place
l’authentification :
 Les connexions administratives : SSH, Telnet, Console série, ASDM (avec https), gestion
du VPN.
 La commande enable
 L’accès au réseau et/ou au VPN
II.9.b – Autorisation
Elle vérifie les autorisations pour chaque utilisateur (après authentification) pour les sessions
suivantes :
 Les commandes de management

 L’accès au réseau et/ou au VPN
II.9.c – Surveillance
Elle permet de garder des traces du trafic qui passe à travers l’ASA. En activant
l’authentification, l’ASA peut surveiller le trafic d’un ou plusieurs utilisateurs spécifiques.
II.10 – Les filtres HTTP, HTTPS, FTP

Etant donnée la grande taille et la nature dynamique du net, l’utilisation des ACL n’est pas
suffisante pour filtrer les sites web ou les serveurs ftp. Il est donc conseiller d’utiliser l’ASA en
parallèle avec un serveur utilisant un produit de filtrage internet (ex : Websense Entreprise, Secure
Computing SmartFilter).
Les performances du réseau peuvent être réduites considérablement par le serveur externe.
Plus il est éloigné du réseau, plus son impact est important.
II.11 – Limites de connexions

L’ASA offre la possibilité de limiter le nombre de connexions TCP et UDP, le nombre de
connexions à l’état embryonnaire, le nombre de connexions par utilisateur, ainsi que détecter les
connexions mortes.

II.12 – Différences entre IOS 7 et IOS 8

Parmi les fonctionnalités supplémentaires qu’apporte la mise à jour vers la version 8.0(2),
voici celles que l’on considère les plus intéressantes :
 Le protocole de routage EIGRP

 Fonctionnalités VPN :
o Possibilité de demander un nom d’utilisateur et un mot de passe en plus du certificat
pour les clients désirant se connecter par SSL VPN
o Clavier virtuel sur la page de connexion, pour éviter tout risque de piratage (ex :
logiciels qui enregistrent ce qui est tapé)
o Une autorité de certification pour le SSL VPN
o Dynamic Access Policies (DAP) : les politiques d’accès peuvent être configurées
dynamiquement
o Possibilité de différentier les utilisateurs des administrateurs lors de l’accès à une
base de donnée (ex : RADIUS ou LDAP (service d’annuaire))
o Aide pour tagger le trafic client. Fonctionne pour les connexions clientless, IPSec et
SSL
o Possède une interface plus claire et plus facile d’utilisation
o Autorise le trafic FTP
o Un framework supplémentaire permet d’accepter les applications basée sur du TCP
sans avoir à installer l’application cliente.
o Permet de créer des tunnels SSL juste pour certaines applications.
o Les administrateurs peuvent inclure au portail clientless des flux RSS
o Les utilisateurs peuvent sauvegarder leurs favoris sur le serveur
o Autorise des ressources IPv6 au dessus d’une connexion publique IPv4
 Fonctionnalités du pare-feu
o Inspection du trafic http
o Permet de renommer une ACL
o Permet de compter le nombre de paquets pour lesquels l’ASA vérifie s’ils sont
autorisés par une ACE
o Permet de configurer du NAT en mode transparent
o Permet de configurer plusieurs règles de sécurité sur l’AIP SSM
o L’inspection SIP gère le protocole IPv6

III – ETUDE DES FONCTIONNALITES VPN

L’étude des technologies VPN implémentées sur l’ASA 5500 s’est découpée en trois grandes
étapes. Il nous a tout d’abord fallu comprendre le fonctionnement et les subtilités de l’ASA 5500, afin
de savoir comment le configurer correctement. Dans un second temps, nous avons imaginé des
topologies intéressantes pouvant exploiter et expliquer au mieux les capacités de l’ASA en ce qui
concerne les accès VPN : IPSec et SSL. Puis nous avons configuré les ASA. Bien entendu les frontières
entre ces trois étapes sont floues et un va et vient permanent entres celles-ci nous a permis d’affiner
nos compétences.
III.1 – Gestion du trafic

La configuration des interfaces, la mise en place des règles d’accès au réseau, et la gestion
des utilisateurs sont autant de notions que nous avons du nous approprier avant de pouvoir débuter
la configuration des VPNs.
III.1.a – Le principe des niveaux de sécurité

Les ASA sont des périphériques orientés Sécurité. Cela engendre de nombreuses différences
dans la philosophie des commandes les plus basiques telles que la configuration des interfaces. Ainsi,
à chaque interface est associé un nom et un niveau de sécurité, qui déterminent les politiques de
sécurité associées.
Les niveaux de sécurité vont de 0 à 100. 100 correspond à une confiance totale et un besoin
accru de protéger ce réseau – ex : réseau interne – tandis que 0 correspond à un réseau dont on se
méfie et dont la protection ne nous concerne pas – ex : Internet.
Donner le nom inside à une interface lui attribue automatiquement un niveau de sécurité
de 100. Tout autre nom d’interface, notamment outside, implique un niveau de sécurité de 0.
Toutefois, il est possible de modifier le niveau de sécurité manuellement.
Les niveaux de sécurité des interfaces influent sur les points suivants :
- Accès réseau : par défaut seules les communications depuis les interfaces de plus haut niveau
vers celle de plus bas niveau peuvent avoir lieu. On dit que ces communications sont
sortantes. Si les interfaces ont le même niveau, le trafic peut être autorisé entre elles avec la
commande same-security-traffic permit inter-interface
- Moteurs d’inspection : les comportements de certains moteurs d’inspection s’adaptent en
fonction du niveau :
o NetBIOS : s’applique seulement aux connections sortantes
o SQL*Net : seule une connexion entrante de données est autorisée.
- Filtrage : les filtrages HTTP et FTP s’appliquent uniquement aux connexions sortantes
- Contrôle NAT : doit être configuré pour les connexions sortantes
- Commande established : cette commande autorise les communications des interfaces
de plus bas niveau vers celles de plus haut niveau si la connexion a été établie auparavant
par l’interface de plus haut niveau.

III.1.b – Listes de contrôle d’accès

Par défaut, les ASA bloquent tout trafic depuis une interface de faible niveau de sécurité vers
une interface de plus haut niveau de sécurité. Les Access Control Lists (ACL) permettent d’affiner ce
fonctionnement, voire de s’y opposer, si nécessaire.
Elles s’avèrent donc nécessaires dès que deux interfaces sont configurées et que l’on
souhaite établir une communication entre les deux réseaux associés.
Bien qu’offrant des fonctionnalités plus étendues, leur fonctionnement général est identique
à celui des ACLs présentes sur les autres routeurs Cisco.
III.1.c – Droits des utilisateurs

L’ASA supporte plusieurs types de serveurs AAA : Radius, LDAP, TACACS, etc. Comme son
nom l’indique (AAA est l’acronyme de « Authentication, Authorization, Accounting »), un serveur
AAA est responsable de l’identification, de la gestion des autorisations et de la sauvegarde des
actions effectuées par les utilisateurs.
Nous avons limité notre étude au serveur AAA proposé par Cisco sur l’ASA. Il est possible de
créer des utilisateurs sur l’ASA, leur associer un mot de passe, un niveau de privilège, une politique
de groupe.
Le niveau de privilège varie entre 0 et 15, 0 correspondant à aucun accès à l’administration

du routeur, et 2 étant la valeur par défaut. Les politiques de groupe régissent les conditions d’accès
au réseau, et des propriétés relatives aux connexions VPN.
III.2 – VPN IPsec

III.2.a – Objectifs
Cette partie avait pour but de réaliser un TP sur les tunnels IPSEC pouvant être réutilisé pour
d’éventuels cours de sécurité informatique. L’objectif initial était d’arriver à mettre en œuvre un
tunnel VPN Lan-to-Lan et un tunnel Roadwarrior, en conservant des paramètres basiques, puis
éventuellement d’étoffer le TP si le temps le permettait.
III.2.b – Choix pédagogiques

Nous souhaitions fournir aux étudiants une vision assez réaliste de l’utilisation des ASA. Nous
avons donc décidé d’opter pour la configuration d’une entreprise ayant deux sites distants afin de
pouvoir mettre en œuvre le tunnel Lan-to-Lan, ainsi que des utilisateurs nomades pour le
Roadwarrior. Par ailleurs, nous avons opté pour un adressage privé, ce qui allait nous permettre de
mettre en œuvre du NAT pour l’accès web, et de faire des exceptions au NAT pour l’accès au site
distant. Nous avons essayé de dimensionner le matériel nécessaire pour pouvoir avoir deux groupes
de TP. Voici la topologie que nous avons choisi de mettre en place pour un groupe :

On y retrouve :
- Les deux sites distants, possédant chacun 3 PC dont un serveur web, 1 switch et un ASA.
- Deux routeurs d’extrémité appartenant à des FAI, pour l’accès à Internet.
- Un serveur web, pour les tests NAT.
- Un PC connecté à Internet, qui exécutera le client VPN Roadwarrior.
Nous avons considéré que les étudiants possédaient les pré-requis suivants :
- Configuration d’adresses IP et de passerelles par défaut sur des machines Unix et Windows.
- Configuration d’adresses IP, de passerelles par défaut, d’interfaces série et d’un routage
statique sur des routeurs Cisco.
Ainsi, les commandes se rapportant à ces pré-requis n’ont pas été précisées dans le TP. Elles
sont toutefois détaillées dans un mémo de configuration proposé en annexe, permettant un
dépannage rapide en TP. Par ailleurs, nous supposons que les étudiants ont des connaissances
générales sur les mécanismes d’ACL et de NAT, ainsi que sur IPSEC, ssh et les proxy web.
III.2.c – Adressage et connectivité

III.2.c.i - Présentation
La première partie consistait à arriver à créer le réseau et réussir les tests de connectivité.
Pour cela, un seul routeur était utilisé entre les ASA, sur lequel étaient implantées les routes
statiques vers les réseaux 10.1.0.0/16 et 10.2.0.0/16.
Pour cela, il fallait réussir l’adressage des interfaces des ASA, découvrir et comprendre les
mécanismes de sécurité, notamment les security levels, et arriver à passer outre.

Les security levels sur les ASA fonctionnent de la manière suivante : chaque interface
possède un niveau de sécurité compris entre 0 et 100. Si l’on accorde une grande confiance au
réseau se trouvant derrière une interface (le réseau dont on a la maîtrise par exemple), on peut lui
attribuer un niveau de sécurité élevé (ex : 100). A l’inverse, si l’on n’a pas confiance en un réseau (par
exemple Internet), il serait judicieux d’affecter à l’interface à laquelle il est connecté un niveau de
sécurité de 0. Par défaut, une fois les interfaces configurées, un paquet sera autorisé à passer d’une
interface ayant un niveau de sécurité m vers une interface ayant un niveau de sécurité n si m>n. Pour
que cela marche si m=n, une commande spéciale doit être entrée.
De plus, et c’est très déroutant quand on ne le sait pas, les interfaces de l’ASA, si aucune ACL
n’est entrée, ne peuvent être pinguées que par les hôtes directement connectés.
Une fois ces mécanismes de sécurité acquis, il nous a fallu comprendre comment les
contourner, tout en restant dans une logique « sécurité ». C’est ainsi que nous avons découvert les
acces-list et les fonctionnalités de suivi d’état de l’ASA. Nous sommes tout d’abord arrivés à a réaliser
des pings sur le routeur Internet à partir des PC internes à un site en activant l’inspection ICMP. Mais
cela ne suffisait pas pour initier des pings depuis l’extérieur. Nous avons donc mis en place des
mécanismes d’ACL, autorisant ICMP et les requêtes http. Les deux méthodes sont présentées dans le
TP, mais seules les ACL sont vraiment utiles pour ce qui nous concerne, puisqu’elles permettent les
pings provenant de n’importe où, contrairement à l’inspection ICMP.
III.2.c.ii – Difficultés
La partie adressage et tests de connectivité fût probablement la plus longue et laborieuse du

projet. Nous avions l’habitude de manier des routeurs Cisco, mais la logique d’utilisation des ASA
s’est révélée complètement différente. De plus, nous connaissions assez peu les ACL, ayant eu le
cours CCNA portant dessus assez tard dans l’année, et bien qu’ayant eu un TP sur les commandes
Iptable.
Nous avons compris assez vite le principe des niveaux de sécurité, mais n’arrivions toujours
pas à faire se pinguer deux ordinateurs entre eux, connectés au même ASA. Même après avoir réussi
à implanter des ACL, nous commencions toujours nos tests de connectivité par pinguer les interfaces
des ASA, et avions l’impression que cela marchait de façon aléatoire. Les informations sur les
principes de base du fonctionnement des ASA étaient réparties ici ou là dans la documentation, et
nous ont mené à pas mal d’essais infructueux. De plus, nous ne pouvions pas faire de sauvegardes
de nos configurations, puisqu’elles n’étaient pas fonctionnelles, et perdions du temps à câbler et
reconfigurer à chaque fois le matériel. Enfin, les fois ou cela marchait, nous avions essayé tant de
choses qu’il nous était difficile de savoir quelles sont les commandes exactes qui nous menaient à la
bonne configuration.
En conclusion de cette partie, nous pouvons affirmer que nous avons procédé à tâtons, de
manière pas forcément très rigoureuse, en essayant pas mal de choses, ce qui nous a fait perdre pas
mal de temps. Il nous a fallu de nombreuses séances avant d’aboutir à une configuration
fonctionnelle et reproductible.

III.2.d – NAT et VPN Lan-to-Lan

III.2.d.i – Présentation
A ce stade du projet, nous avions déjà passé beaucoup de temps sur l’adressage et les tests
de connectivité. Nous avons donc décidé de passer directement à la configuration du VPN Lan-to-
Lan, et de garder le NAT pour plus tard.
Nous avons commencé par nous documenter sur l’implémentation des tunnels VPN. Après
les recherches, nous avons mené deux essais infructueux de configuration à l’aide de l’interface en
ligne de commande. La phase de configuration étant assez longue, et le temps pressant, nous avons
choisi de changer la manière de procéder. Nous avons décidé d’explorer les possibilités d’ASDM, un
utilitaire de configuration graphique. Un premier essai fût vain, mais le deuxième a marché. Nous
avons alors noté les commandes envoyées par l’utilitaire aux ASA, afin de pouvoir les analyser chez
nous avec le manuel de configuration.
Cela nous a permis de nous rendre compte que certaines commandes envoyées n’étaient pas
forcément utiles pour la configuration que nous souhaitions appliquer. Par ailleurs, nous avons grâce
à cette méthode compris la configuration du NAT, et comment y ajouter des exceptions.
Nous allons donc présenter le principe de configuration d’un VPN Lan-to-Lan. Il ne s’agit pas
ici d’effectuer un recueil de commandes, mais de présenter les quelques étapes clef de cette
configuration.
La première étape est la configuration du protocole ISAKMP. Ce dernier est utilisé pour
trouver une politique de sécurité commune avec l’autre extrémité du tunnel. Cette politique de
sécurité définit un ensemble de méthodes visant à protéger et authentifier les données. Une
politique ISAKMP regroupe une méthode d’authentification, une méthode de cryptage, une méthode
de hachage, un groupe de Diffie-Hellman et une limite de temps pour le remplacement des clefs de
cryptage. Mis à part des exceptions sur le temps de renouvellement des clefs, les autres paramètres
de la politique de sécurité doivent être les mêmes sur les deux hôtes pour qu’ils puissent poursuivre
la communication.
Une fois la politique ISAKMP déterminée, il nous faut maintenant créer notre tunnel. Pour
cela, on doit configurer un ensemble de paramètres, regroupés dans ce que l’on appelle une
association de sécurité (SA). Sur les ASA, une SA regroupe les éléments suivants, qu’il nous faudra
configurer :
- Un ou plusieurs transform sets

- Une ou plusieurs crypto maps
- Une ou plusieurs access-lists
- Un tunnel group
En fait, une crypto map regroupe un transform set, une ou plusieurs ACL et un hôte distant.
Chaque crypto map permet de protéger le trafic spécifié dans son ACL, pour le tunnel spécifié par
l’hôte distant, avec les moyens indiqués par son transform set. On pourra ainsi se servir de plusieurs
crypto map attribuées au même tunnel, afin de protéger plusieurs types de trafic de manière
différente.

Un transform set est une combinaison de protocoles de sécurité et d’algorithmes qui

définissent comment l’ASA protège les données (une méthode d’authentification et une méthode de
cryptage). Pendant la phase de négociation de l’association de sécurité, les deux pairs doivent
identifier un transform set commun. Les ASA appliquent alors le transform set élu pour protéger les
flux de données identifiés dans l’ACL associée à la crypto map qui implémente le transform set. Un
exemple de transform set pourrait être par exemple d’utiliser ESP, avec 3des comme méthode de
cryptage, et sha1 comme méthode de hachage. Il est par ailleurs à noter que les transform set de
l’ASA ne proposent pas AH pour le protocole IPSec.
Il nous reste donc à expliquer ce qu’est un tunnel group. Il regroupe un ensemble de

paramètres qui spécifient la politique de connexion au tunnel, comme par exemple un serveur
d’authentification, des politiques de groupe, etc … Deux types de tunnel group sont déjà pré-
configurés sur les ASA, un concernant les VPN Lan-to-Lan, l’autre les VPN Remote Access. Pour notre
exemple, il suffit de créer un tunnel-group de type Lan-to-Lan, et de spécifier les paramètres de la
méthode d’authentification. Comme nous avons choisi une authentification par clef pré-partagée, il
nous fallait par exemple spécifier la clef.
En résumé, pour configurer un tunnel VPN Lan-to-Lan basique, il faut suivre les étapes suivantes :
- Définir une politique ISAKMP

- Définir un transform set et spécifier les méthodes de protection des données
- Définir un tunnel group et spécifier les paramètres d’authentification
- Définir une ACL définissant le trafic à protéger
- Associer l’ACL, le transform set et l’adresse de l’autre extrémité dans une crypto map.
III.2.d.ii – Difficultés
La principale difficulté de cette partie fût de comprendre la manière d’implémenter les VPN
sur les ASA. Les paramètres peuvent paraîtres assez confus au premier abord. De plus, les
paramètres étant nombreux, et une seule erreur conduisant à l’échec, il paraît facile de se tromper.
C’est pourquoi il nous semble que la seconde méthode utilisée, consistant à se servir d’ASDM puis
d’analyser les commandes, permet de fortement dégrossir le travail, même si cela demande du
temps.
III.2.e – VPN End-to-Lan

III.2.e.i – Présentation
Après avoir terminé et documenté la configuration du VPN Lan-to-Lan et du NAT, nous avons
attaqué la partie VPN Remote access. Le temps pressant, nous nous sommes directement tournés
vers ASDM. De plus, nous pensions qu’il était utile que les étudiants s’initient à cet outil, et comme
les grands principes de configuration étaient quasiment les mêmes pour les deux types de tunnel, ce
TP s’y prêtait bien.
Nous avons ainsi utilisé ASDM pour la configuration du tunnel. Pour cela, il faut activer le
serveur http de l’ASA, et autoriser l’interface management à recevoir du trafic provenant de notre
PC. Par ailleurs, Java doit être installé sur le PC, car c’est un plugin Java qui fait tourner le logiciel dans
le navigateur.
La configuration du tunnel se fait assez aisément en suivant l’assistant d’installation dédié.

Les étapes supplémentaires par rapport à la mise en place Lan-to-Lan sont les suivantes :
- Création d’une base d’utilisateurs pour l’authentification par login/password

- Création d’un pool d’adresses pour l’adressage virtuel des clients
- Ajout éventuel de paramètres à configurer automatiquement sur le client (DNS,WINS,…)
- Remplacement du type de tunnel group Lan-to-Lan par Remote access
La suite de la configuration s’est révélée plus complexe. Il s’agissait de trouver un client VPN
pour se connecter à l’ASA. Nous avons mis un PC directement sur l’interface outside de l’ASA pour les
tests.
Le premier client testé fût le client officiel Cisco, fournit par l’INSA. Nous avons tenté de créer
un nouveau profil de connexion, et de l’appliquer pour les tests. Malheureusement, les possibilités
de configuration du client sont minimes. Il nous a par exemple été impossible de trouver comment
s’authentifier à l’aide d’une clef pré-partagée. Nous avons pensé que la version dont nous disposions
était une version destinée aux utilisateurs finaux, bridée et sans beaucoup de possibilités de
configuration.
Comme nous voulions faire cohabiter un environnement Unix et Windows, nous ne nous
sommes pas de suite tourné vers le client libre vpnc. Nous avons simplement recherché un client
VPN Windows disponible. Le premier à nous venir à l’esprit fût le client VPN intégré à Windows, que
nous n’avons pas su configurer. Nous nous sommes alors tournés vers un client payant, dont une
version d’essai est disponible sur Internet. Il s’agit de TheGreenBow. Nous avons opté pour celui là
pour deux raisons : la première (qui n’est pas la meilleure !) est que ce client est le premier que nous
avons trouvé, son référencement le plaçant en bonne position dans les moteurs de recherche. La
deuxième est qu’il avait l’air bien documenté.
Ce client VPN sépare clairement les deux phases ISAKMP. Dans la première phase, qui crée le
premier tunnel servant à la négociation, on configurera les paramètres de base : adresse du site
distant, paramètres de sécurité IKE pour l’échange des clefs, clef pré-partagée, login et mot de passe,
ainsi que l’id local, qui doit correspondre au nom du tunnel group sur l’ASA. Par manque de temps,
nous n’avons pas testé le mode de configuration automatique, permettant de récupérer de l’ASA des
paramètres de connexion tels qu’une adresse IP, un serveur DNS,… Bien entendu, c’est ce mode qui
doit être utilisé dans la réalité.
La deuxième partie du tunnel concerne les données. On y spécifie l’adresse IP que l’on
souhaiterait, le réseau auquel on va se connecter, ainsi que les paramètres ESP (chiffrement,
authentification, mode tunnel ou transport).
Une fois que ces paramètres sont établis, on clique sur ouvrir le tunnel pour se connecter.
Contrairement au client Cisco, TheGreenBow ne crée pas d’interface réseau virtuelle sous Windows.
Il faudra donc se convaincre que l’on dispose d’une nouvelle adresse IP en lançant un analyseur de
protocole tel que Wireshark.

III.2.e.ii – Difficultés
La principale difficulté fût la recherche et la configuration d’un client VPN. Comme ASDM ne
nous proposait que des clients officiels Cisco, nous avions peur que cela ne marche pas. Après avoir
testé en vain le client Cisco, nous avions l’impression de travailler dans le vide lorsque nous tentions
de configurer le client TheGreenBow. Heureusement, la documentation précisait qu’il était
compatible avec les ASA. Malheureusement, le temps ne nous a pas permis d’explorer toutes les
possibilités du client, et notamment le mode de configuration automatique, ainsi que la connectivité
au site 2 de l’entreprise par l’intermédiaire du site 1.
III.2.f – Améliorations possibles

Le but de ce projet étant d’arriver à monter un TP fonctionnel, nous avons implanté des
paramètres assez basiques. De nombreuses améliorations pourraient être apportées, que nous
listons ci-dessous.
III.2.f.i – Authentification par certificat
Nous avions commencé par une authentification par clé pré-partagée car c’était la méthode
qui nous a semblé la plus directe au début. Nous comptions revenir dessus, mais n’en avons pas eu le
temps. Il serait intéressant, pour la partie Lan-to-Lan et Remote acces, de configurer des certificats
pour s’authentifier. C’est en effet la méthode qui nous semble être privilégiée dans les entreprises.
III.2.f.ii – Gestion de différents types de trafic
La protection des données par cryptage requiert des ressources processeur et de la bande
passante, chose qui peut se révéler chère si l’on utilise une technologie grande distance pour
connecter les deux sites distants.
L’administrateur peut ainsi vouloir moins bien protéger certaines données peu sensibles, et
au contraire très bien protéger certaines informations capitales pour l’entreprise. En cherchant un
peu, il apparaît que cette fonctionnalité est possible. Il suffit d’implémenter plusieurs crypto map, qui
ont chacune une ACL correspondant au trafic à protéger, et des transform set différents.
III.2.f.iii – Utilisation de serveurs d’authentification
Plutôt que d’utiliser l’authentification locale des ASA, il peut être intéressant de montrer aux
étudiants comment se servir d’un serveur d’authentification tel que Radius, très utilisé en entreprise.
On pourrait ainsi montrer comment gérer les différents groupes d’utilisateurs, appliquer des droits
d’accès différents, etc…
III.2.f.iv – Utilisation de la configuration automatique du client VPN
Nous n’avons pas eu le temps de tester la configuration automatique de l’adresse IP et des

paramètres DNS sur le client. Nous n’avons pas pris le risque de le spécifier dans le TP sans savoir si
cela marchait. Comme c’est un mode utile et sans doute très utilisé, il serait important de le rajouter
au TP.

III.2.f.v – Accès à tous les sites depuis l’hôte distant
Comme vous pourrez le constater dans le TP, nous ne sommes pas parvenus à accéder
directement au site 2 depuis l’hôte distant, qui se connectait à l’ASA du site 1. Nous avons du passer
par ssh et un proxy web.
Il serait intéressant que l’hôte distant ait accès à tous les sites de l’entreprise. L’approche la
plus simple serait d’ouvrir un tunnel différent pour chaque site. Apparemment, le VPN TheGreenBow
peut ouvrir de multiples tunnels en même temps. Malheureusement, si l’entreprise possède de très
nombreux sites, cela pourra vite écrouler le client. De plus, cela n’est pas très confortable pour
l’utilisateur.
La deuxième approche consisterait à développer une topologie en étoile, qui connecterait les
succursales de l’entreprise à un site central. Ce dernier se chargerait de relayer le trafic entre les
utilisateurs distants et les succursales concernées. Par manque de temps, nous n’avons pas pu
essayer d’établir ce genre de connectivité.
III.2.g – Bilan
La première chose que nous a apporté cette partie du projet, c’est bien entendu un savoir-
faire technique sur la configuration des VPN IPsec et des mécanismes sous-jacents.
Mais le principal acquis fût de nous rendre compte qu’une telle configuration, même si elle
peut sembler simple, peut-être extrêmement longue à préparer pour un novice. A titre d’exemple,
une personne était chargée de cette partie. Le temps consacré fût l’ensemble des séances de projet
tuteuré, plus environ la moitié en autonomie en salle de TP, et du travail personnel de
documentation. Bien évidemment, nous avons perdu du temps sur le câblage et la configuration,
ainsi que pour se dépanner entre nous. Mais nous n’avons abouti qu’à une configuration simple, qui
doit être améliorée et contrôlée afin de pouvoir être réellement appliquée dans un contexte
« sécurité ». On peut ainsi en conclure que ce type de mise en place, s’il est bien fait, peut vite se
révéler chronophage pour les employés de l’entreprise.
III.3 – VPN SSL

Comme indiqué dans l’état de l’art, SSL permet des connexions sécurisées, avec ou sans
client. Il se greffe sur la couche 4 du modèle OSI, la couche transport.
III.3.a – IOS v7 vs. IOS v8

L’implémentation proposée dans la version 7 de l’IOS ASA ne permet de configurer SSL qu’en
clientless, pour le seul accès aux applications web, via un portail – ni applications webisées, ni
applications émulées ne sont supportées.
Dans sa version 8, l’IOS ASA propose un accès clientless grâce à un portail évolué permettant
l’accès aux applications web, webisées et émulées, ainsi qu’un accès non clientless par le biais de
l’application java AnyConnect.
La suite de cet exposé concerne la version 8 de l’IOS.

III.3.b – Objectifs
Parmi les technologies VPN, IPSec a dominé le marché pendant une longue période. Aussi,
quand on pense à VPN, tout le monde est tenté de penser à l’encapsulation chiffrée d’IP dans IP.
Pourtant, ce n’est qu’un cas particulier de technologie VPN.
Nous souhaitions donc montrer une technologie VPN différente d’IPSec, dans la mesure où
SSL garantit l’intégrité, la confidentialité et le non-rejeu des données entre deux applications en
communication en opérant au niveau transport du modèle OSI.
De plus, la facilité et la flexibilité des solutions SSL en font des solutions qui méritent d’être
connues.
L’objectif était de prendre du recul par rapport à ce que nous connaissions concrètement des
technologies VPN avec IPSec, et de montrer les forces et faiblesses d’un autre type de VPN.
III.3.c – Choix pédagogiques

Ici, l’ambition principale était de faire la démonstration des capacités de l’ASA en ce qui
concerne la technologie SSL. Ainsi, dans un même TP, nous proposons dans un premier temps de
mettre en place un accès Clientless, puis de le compléter par un accès avec le client AnyConnect.
Nous avons imaginé un scénario réaliste, tout en essayant de présenter des situations qui mettent
l’accent sur des points essentiels.
La topologie suivante a donc été élaborée :
Les parties internes du réseau ont un adressage privé, tandis que l’intranet est dans une
DMZ, avec adressage public. Nous avons simulé Internet sur l’interface outside grâce à la présence
d’un routeur intermédiaire entre un PC et l’ASA.
Un aspect primordial lors de connexions VPN, est de pouvoir gérer les autorisations en
fonction de l’utilisateur connecté. Pour ce faire, des ACLs sont associées aux politiques de groupe.

C’est pourquoi nous avons spécifié dans la topologie qu’un utilisateur pouvait se connecter
indifféremment depuis l’interface inside ou outside. C’est le meilleur moyen que nous ayons trouvé
pour montrer que les ACLs utilisées n’étaient pas liées à des interfaces mais bien à des groupes
d’utilisateur.
Afin que les étudiants puissent expérimenter par eux-mêmes les avantages et inconvénients
de l’ASDM, nous avons choisi de présenter toutes les manipulations à la fois du point de vue du CLI et
du point de vue de l’ASDM.
III.3.d – Matériel utilisé

1 PC pour l’administration de l’ASA
2 PCs pour les connexions des utilisateurs
2 PCs pour les ressources internes (serveur SSH, serveur HTTP) et publiques (Serveur HTTP).
1 ASA
1 Routeur
III.3.e – Difficultés rencontrées
Après plusieurs connexions successives au portail WebVPN, il nous était impossible de nous
connecter à nouveau, et l’erreur « login failed » apparaissait. Ce comportement semblait aléatoire
puisque après un certain temps d’attente la connexion était à nouveau possible.
Après quelques recherches, nous avons compris que l’ASA a un paramètre qui définit le
nombre maximal d’utilisateur (3 par défaut) et un paramètre timeout qui définit combien de temps
un utilisateur peut rester inactif avant que sa session ne soit supprimée (30 minutes par défaut).
L’erreur venait donc du fait que nous nous connections trois fois de suite, et fermions la fenêtre sans
prendre soin de nous déconnecter correctement. Ainsi, nous étions confrontés à l’erreur « login
failed » à la connexion suivante dans la mesure où le nombre d’utilisateurs maximal était dépassé.
III.3.f – Portail WebVPN

Le mode clientless SSL a pour but de permettre un accès à distance sécurisé grâce à un
simple navigateur internet. Les avantages de ce simple pré-requis sont non négligeables :
compatibilité avec tous les systèmes d’exploitation, déploiement de logiciels évité, simplicité
d’utilisation pour l’utilisateur.
Pour se connecter, l’utilisateur se rend sur un portail géré par l’ASA. Une fois identifié, une
page personnalisée s’ouvre et propose un résumé des ressources accessibles ainsi qu’une barre
d’adresse intégrée pour permettre d’accéder aux ressources, y compris les adresses http.

Portail WebVPN
III.3.f.i – Navigation Web
Quand l’utilisateur navigue, de son point de vue le site consulté reste le portail. C’est l’ASA
qui se charge de consulter les pages demandées par l’utilisateur et de les lui transmettre, légèrement
modifiées. En effet, l’ASA modifie tous les liens hypertextes pour qu’ils correspondent à une requête
vers l’ASA, et non un lien vers l’adresse initialement pointée. De plus, afin de permettre à l’utilisateur
de naviguer comme il le souhaite, une boîte à outils est affichée en haut à droite de la page. Cette
boîte à outils offre des raccourcis vers la barre d’adresse, la page d’accueil et la fermeture de session.
Un bouton permet également de la changer de côté dans le cas où elle cacherait une information
utile sur la page.
Boîte à outils en haut à droite de toutes les pages
Afin de faciliter la navigation vers les ressources, il est possible de créer des listes de favoris
et d’en associer une ou plusieurs à un groupe d’utilisateur, afin qu’elle s’affiche sur la page d’accueil.
III.3.f.ii – Plugin : accès ssh, VNC, etc…
SSL est un protocole de niveau transport. Par conséquent, il est en interaction directe avec
les couches applicatives. Dans le cas présent, cette caractéristique présente l’avantage de pouvoir
proposer des services d’émulation de protocoles. Ainsi, Cisco propose de plugins sous forme

d’applets java et qui permettent à l’utilisateur d’accéder à un serveur SSH et même VNC sans
nécessiter de client côté utilisateur.
Dans la mesure où SSL garantit le chiffrage des données, nous n’avons pas réussi à
déterminer le contenu des données échangées entre l’utilisateur et l’ASA au moment d’une
transaction SSH. Seule information disponible : communication sur le port 443, ce qui est normal
pour une session VPN. De même, entre l’ASA et le serveur SSH, on identifie une communication sur le
port 22.
Plugin SSH en action
Il est à noter que la réactivité du terminal SSH est lente.
Par manque de temps, nous n’avons pas pu installer de serveur VNC sur une des machines.
Par conséquent, nous n’avons pas pu tester la qualité du plugin VNC.
III.3.g – AnyConnect
III.3.g.i – Description
Anyconnect est un client léger qui se télécharge automatiquement depuis l’ASA selon le
système d’exploitation présent sur le client. Il crée un tunnel SSL sécurisé entre un client distant et
un site privé. C’est un logiciel récent qui, à terme, supportera les tunnels IpSec afin de regrouper tous
les différents clients Cisco en un seul logiciel. Il permet à l’hôte distant d’utiliser n’importe quelle

application pour accéder aux ressources du réseau interne. Pour cela il peut utiliser n’importe quel
protocole IPv4 unicast.
III.3.g.ii – Comparaison à la solution clientless
Une fois installé AnyConnect est totalement indépendant du navigateur Web. Ce dernier
peut donc être fermé sans que la connexion soit perdue, on peut aussi lancer le client
indépendamment du navigateur. A l’instar du client IpSec, AnyConnect va créer une interface réseau
virtuelle à laquelle il va attribuer une adresse IP. Cela permet à n’importe quelle application d’utiliser
le tunnel créé. Par exemple, on peut utiliser n’importe quel logiciel d’accès à distance directement
sans passer par des plugins Web.
L’interface créée aura une adresse donnée par l’ASA au cours de l’établissement du tunnel.
Cette adresse fait partie d’un pool d’adresses attribuées uniquement aux clients du VPN SSL
anyconnect. Cette interface virtuelle ne sert en réalité qu’à ‘tunneler’ les informations de niveau
applicatif qui seront cryptées grâce à SSL. En effet lorsque le client veut accéder à une ressource
interne, les données sont envoyées en clair depuis l’interface virtuelle vers le serveur se trouvant
derrière l’ASA. Ces données sont transmises cryptées par SSL à travers le tunnel créé entre l’interface
physique du client et l’interface de l’ASA reliée vers l’extérieur.
La connexion au portail est toujours possible, on peut donc aussi bénéficier des avantages de
celui-ci, les bookmarks personnalisés par exemple.
III.3.g.iii – Fonctionnement
Le client, branché sur l’interface de l’ASA où AnyConnect a été configuré, se connecte à l’ASA
en utilisant un navigateur Web et rentre son nom d’utilisateur. Lors de la première connexion, le
client s’installe. Il se télécharge automatiquement depuis l’ASA. A noter que Java RunTime
Environment doit être installé.
Figure 1 : téléchargement d'anyconnect

Après l’installation, la connexion se fait, elle aussi, automatiquement. Lors des prochaines
connexions, le client peut relancer AnyConnect via le navigateur, qui lancera à son tour le logiciel
AnyConnect, ou le lancer directement depuis un terminal.
A la connexion, une interface réseau virtuelle est crée et une adresse IP, choisie dans un
pool, est attribuée au client.
Figure 2 : le client anyconnect
Une nouveauté d’AnyConnect est le support du protocole DTLS ( Datagram Transport Layer
Security) amélioration du protocole TLS. Il permet au client et à l’ASA de communiquer en UDP, cela
permet de réduire le temps de latence qui est souvent élevé avec les connexions SSL
III.3.g.iv – Problèmes rencontrés
Nous avons d’abord essayé de le faire fonctionner sur Linux mais nous obtenions toujours la
même erreur («Impossible d’obtenir le certificat.»). Nous avons trouvé une solution (renommer
différentes librairies) sur un forum Internet mais elle n’a fonctionné qu’une seule fois.
Lors des dernières séances nous avons abandonné linux et testé sous windows. Le client a
parfaitement fonctionné. Nous avons ensuite essayé de nous connecter à un serveur situé derrière
l’ASA mais sans succès. Nous avons finalement trouvé la solution sur le site de cisco : il faut en fait
ajouter une ACL permettant aux serveurs internes de répondre aux requêtes du client.
ciscoasa(config)#access-list split-tunnel standard permit <@IP réseau interne> <netmask>
ciscoasa(config-group-policy)#split-tunnel-policy tunnelspecified
ciscoasa(config-group-policy)#split-tunnel-network-list value split-tunnel

CONCLUSION
Vous avez pu constater, à la lecture de ce rapport, que ce projet rassemble succès et échecs.
En débutants et en vrais novices sur du matériel dédié à la sécurité, nous avons procédé à tâtons, à
l’aide d’une documentation dense et parfois difficile à saisir. Mais cela restera une bonne expérience
pour nous tous car cette démarche est beaucoup plus proche de celle utilisée en entreprise que celle
utilisée en TP, où ce travail de recherche est effectué préalablement par les enseignants.
Le fait que le CRI soit intéressé par notre recherche nous a aussi beaucoup motivés car cela
nous a fixé un objectif plus clair.
De plus, comme nous sommes tous intéressé pour travailler dans la sécurité réseau, ce projet
nous a permis d’avoir un premier aperçu du domaine et d’acquérir des compétences qui nous seront
utiles pour passer la certification CISCO sécurité.
Nous espérons que notre projet pourra être poursuivi par les étudiants des années futures. Il
y a bien sur des choses à améliorer dans nos TP, mais surtout de nombreuses autres fonctionnalités à
découvrir, qui seront probablement très intéressantes à étudier pour les étudiants.

BIBLIOGRAPHIE
- Cyril TESSEREAU. Protocoles SSL/TLS, Avril 2005. [H5230], disponible sur http://www.techniques-
ingenieur.fr
- Wilfrid RABOT. Technologies VPN SSL, Avril 2006. [H5240], disponible sur http://www.techniques-
ingenieur.fr
- Yang KUIHE, Chu XIN. Implementation of Improved VPN Based on SSL, The Eighth International
Conference on Electronic Measurement and Instruments - les 16-19 Août 2007, Xi'an – China
- Wafaa BOU DIAB, Samir TOHME, Carole BASSIL. VPN Analysis and New Perspective for Securing
Voice over VPN Networks, Fourth International Conference on Networking and Services, les 16-21
Mars 2008, Gosier – Guadeloupe
- Zhang ZHENSHENG, Zhang YA-QIN, Chu XIAOWEN, Li BO. Photonic Network Communications. An
Overview of Virtual Private Network, mai 2004, vol. 7, n°3, p.213-225
- Ibrahim HAJJEH, Mohamad BADRA. Le protocole SSH, Octobre 2006. [H5235], disponible sur
http://www.techniques-ingenieur.fr
- Rafael CORVALAN, Ernesto CORVALAN, Yoann LE CORVIC : Les VPN Principes, conception et
déploiement des réseaux privés virtuel.
- http://www.formation.ssi.gouv.fr/stages/documentation/architecture_securisee/vpn.html
- http://www.networksorcery.com/enp/protocol/ah.htm
RFC 2402 (Obsolete) et RFC 4302
- http://www.networksorcery.com/enp/protocol/esp.htm
RFC 2406 (Obsolete) et RFC 4303
- http://www.formation.ssi.gouv.fr/stages/documentation/architecture_securisee/vpn.html
RFC 2409
- Mohammed ACHEMLAL, Michel DUDET - Technologies VPN. Octobre 2004 [H5610], disponible sur
http://www.techniques-ingenieur.fr
RFC 2401 et RFC 2411
- http://www.microsoft.com/france/technet/solutions/RAS/pptp01.mspx
-http://www.cisco.com
-Cisco Security Appliance Command Line Configuration Guide. Cisco Systems, Inc. 2007

GLOSSAIRE
ACL : Access Control List. Liste des adresses et ports autorisés ou interdits par un pare-feu.
ASA : Adaptative security appliance. Matériel crée par l’entreprise Cisco dans le but d’améliorer la
sécurité du réseau. Possède de nombreuses possibilités, notamment pare-feu, VPN et
inspection applicative des paquets.
ASDM : Adaptative security device manager. Client graphique exécuté par un applet Java dans un
navigateur ou en client léger sur un système d’exploitation. Permet de configurer un ASA en
mode graphique.
CLI : Command line interface. Système de configuration très utilisé par les administrateurs réseaux.
Permet la configuration d’un ASA à partir de lignes de textes entrées dans une console de
saisie.
Client léger : par opposition au client lourd, désigne une application à l’interface graphique
simplifiée, et qui laisse le serveur se charger de la majorité des tâches complexes.
Exemple : Cisco AnyConnect
Client lourd : par opposition au client léger, désigne une application cliente graphique exécutée sur
le système d'exploitation de l'utilisateur et effectuant des tâches avancées. Un client
lourd possède généralement des capacités de traitement évoluées et peut posséder
une interface graphique sophistiquée. Exemple : Cisco VPN Client
SSH : Secure Shell. Protocole de communication sécurisé conçu avec l'objectif de remplacer les
différents programmes rlogin, telnet et rsh
SSL : Secure Socket Layer. Protocole de sécurisation des échanges opérant au niveau de la couche
transport du modèle OSI.
VPN : Virtual private network. Ensemble de technologies permettant d’établir une communication
sécurisée entre deux hôtes distants.
VPN Clientless : technologie permettant à un utilisateur distant de se connecter au site de son

entreprise à l’aide d’un simple navigateur web.
VPN End-to-lan : Egalement appelé VPN Roadwarrior ou remote access. Permet à un utilisateur
nomade d’accéder de manière sécurisée au site de son entreprise en établissant
un tunnel chiffré entre le matériel d’entrée de site de l’entreprise et un client
lourd installé sur sa machine.
VPN Lan-to-lan : technologie permettant à deux sites distants de communiquer entre eux de la
même manière que sur un réseau local, en assurant intégrité, confidentialité et
authentification des données.
VNC : Virtual Network Computing. Logiciel ouvert pour se connecter à un ordinateur distant.

TABLE DES ANNEXES
ANNEXE A : TP SECURITE 1
CREATION DE TUNNELS IPSEC LAN-TO-LAN ET END-TO-LAN
ANNEXE B : TP SECURITE 1
MEMO DE CONFIGURATION
ANNEXE C : TP SECURITE 2
MISE EN PLACE D’UN ACCES SSL CLIENT LEGER ET CLIENTLESS

TP SECURITE n°1
CONFIGURATION DE TUNNELS IPSEC

LAN-TO-LAN ET ROADWARRIORS
Le but de ce TP est de vous familiariser à la mise en place et à la sécurisation de tunnels IPSec. Ce
tunnel sera considéré comme « permanent » car il est restera établi entre les routeurs d’entrée des
deux sites. Dans une seconde partie, nous verrons comment implémenter des VPN dits
« RoadWarrior » ou encore « End-to-LAN », permettant à des utilisateurs mobiles d’accéder de
manière sécurisée aux ressources de leur entreprise.
Comme nous voulons que les utilisateurs (locaux ou distants) se situent dans le même réseau local,
nous utiliserons IPSec en mode tunnel, qui permet d’encapsuler IP dans IP, et ainsi de faire passer
des adresses privées sur une infrastructure publique telle qu’Internet. Pour bien vous remémorer les
différences entre IPSec en mode tunnel et transport, vous pouvez vous reporter au schéma ci-
dessous :
I – ETABLISSEMENT D’UN TUNNEL LAN-TO-LAN
INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS A1

I.1 – Cahier des charges
Nous voulons faire communiquer les deux sites de l’entreprise de la même manière que s’ils étaient
sur un réseau local. Nous utiliserons pour cela IPSec en mode tunnel. De plus, chaque site doit
pouvoir accéder à Internet. Comme on veut conserver des adresses privées sur nos machines, nous
allons faire du NAT sur les ASA pour l’accès web, et passer par le tunnel pour l’accès au site distant.
I.2 – Adressage
Nous allons maintenant réaliser l’adressage des machines. Dans la réalité, l’ASA ne disposant pas de
port série, il est relié à un routeur de sortie de site, lui-même relié au routeur d’extrémité du FAI. Ici,
nous connectons directement les ASA aux routeurs du FAI.
L’adressage et surtout le test de connectivité sur les ASA est un peu particulier. Ces machines étant
principalement utilisées pour la sécurité, leur configuration par défaut est très restrictive quand aux
paquets pouvant passer. Nous vous conseillons de commencer par adresser les PC et les routeurs
comme indiqué sur le schéma plus haut. A vous de créer les routes statiques qui vont bien (vous
créerez également dans un premier temps des routes vers les réseaux 10.1.0.0/16 et 10.2.0.0/16 sur
les routeurs du FAI, que nous utiliserons pour les tests de connectivité.)
Passons maintenant à la configuration des ASA. Vous devez vous rappeler une règle de base : chaque
interface possède un niveau de sécurité compris entre 0 et 100. Si vous accordez une grande
confiance au réseau se trouvant derrière une interface (le réseau dont vous avez la maîtrise par
exemple), vous pouvez lui attribuer un niveau de sécurité élevé (ex : 100). A l’inverse, si vous n’avez
pas confiance en un réseau (par exemple Internet), il serait judicieux d’affecter à l’interface à laquelle
il est connecté un niveau de sécurité de 0. Par défaut, une fois les interfaces configurées, un paquet
sera autorisé à passer d’une interface ayant un niveau de sécurité m vers une interface ayant un
niveau de sécurité n si m>n. Pour que cela marche si m=n, vous devrez en plus entrer la commande :
ASA(config)# same-security-traffic permit inter-interface
Ces petites précisions étant acquises, nous pouvons maintenant configurer les interfaces de nos ASA.
Voila ce que cela donne sur ASA1 :
hostname(config)#hostname ASA1
ASA1(config)#interface Ethernet0/0
ASA1(config-if)#nameif inside
--donner le nom inside à une interface lui attribute un security level de 100 automatiquement.
ASA1(config-if)#ip address 10.1.0.254 255.255.0.0
ASA1(config-if)#no shutdown
ASA1(config-if)#interface Ethernet0/1
ASA1(config-if)#nameif outside
--donner le nom outside à une interface lui attribute un security level de 0 automatiquement.
ASA1(config-if)#exit
ASA1(config)#route outside 0.0.0.0 0.0.0.0 195.168.1.2
--crée la route par défaut vers le routeur du FAI.

Vous devez normalement pouvoir pinguer l’interface inside de l’ASA depuis un PC du site 1, et
l’interface outside depuis le routeur1. Sachez que les interfaces de l’ASA ne répondent aux ping
uniquement s’ils proviennent du même sous-réseau (sauf cas particuliers non détaillé ici). Vous ne
pourrez donc pas effectuer de ping du PC vers l’interface outside par exemple.
Effectuez maintenant la configuration de l’ASA2 avec les mêmes commandes. Testez alors les actions
suivantes :
-ping d’un PC vers un routeur

-ping d’un PC du site 1 vers un PC du site 2
-ping d’un routeur vers un PC
Vous constaterez que cela ne fonctionne pas. Plusieurs problèmes sont en cause. Pour le premier
cas, cela devrait normalement marcher, puisque le ping est initié du côté le plus sécurisé. Mais par
défaut, l’ASA ne fait pas de suivi d’état ICMP, et n’autorise donc pas le retour du ping ! Pour remédier
à ce problème, vous pouvez entrer les commandes suivantes, afin d’activer l’inspection ICMP :
ASA(config)#policy-map global_policy
ASA(config)#class inspection_default
ASA(config)#inspect icmp
Vérifiez que cela résoud le problème 1. Les deux autres problèmes viennent du fait que l’on tente
d’initier un ping d’une interface de faible niveau de sécurité vers une interface de haut niveau de
sécurité, ce qui est interdit par l’ASA. Pour autoriser ces paquets, nous devons créer des access list
adaptées au type de trafic que l’on veut faire passer, puis les affecter à une interface. La finalité de ce
TP n’étant pas l’étude détaillée des ACL, nous allons créer des access list peu restrictives pour ne pas
avoir trop de problèmes par la suite. Nous allons autoriser ICMP pour les tests de connectivité, et
HTTP pour les tests NAT.
ASA(config)#access-list NOM_ACL permit icmp any any

ASA(config)#access-list NOM_ACL extended permit tcp any any eq www
ASA(config)#access-group NOM_ACL in interface outside
Configurez les ACL sur les deux ASA. Vérifiez qu’un PC du site 1 peut pinguer un PC du site 2, et que
les deux sites ont accès au serveur web 200.1.1.2. Si le test est concluant, vous pouvez faire tomber
les routes vers les réseaux 10.1.0.0/16 et 10.2.0.0/16 sur les routeurs, pour se replacer en conditions
« réelles ». Vérifiez que vous n’avez plus accès au serveur web.
I.3 – Etablissement du NAT
Nous supposerons que chaque site dispose d’une unique adresse IP routable, ce qui impose d’utiliser
un NAT dynamique (n IP privées pour m IP publiques, pour tout m et n >0), contrairement à un NAT
statique, ou chaque IP privée possède exactement un équivalent public. Les deux versions du NAT
sont implémentées par les ASA.
Voilà une explication très générale de comment les ASA font du NAT (si le contrôle NAT n’est pas
activé, ce qui sera le cas dans ce TP) :
“The security appliance translates an address when a NAT rule matches the traffic. If no NAT rule matches,
processing for the packet continues.”

On a donc des « règles NAT », un peu à la manière d’ACL : si un paquet vérifie une règle, son adresse
sera translatée, sinon il poursuivra son chemin avec son adresse d’origine.
Voici les commandes pour changer les adresses de notre réseau privé en une adresse routable :
ASA1(config)# nat (inside) 1 10.1.0.0 255.255.0.0

--création de la règle NAT numéro 1, pour le trafic arrivant sur l’interface inside, avec une adresse
source appartenant au réseau 10.1.0.0/16.
ASA1(config)# global (outside) 1 195.168.1.3
--application de la règle NAT numéro 1 pour le trafic sortant sur l’interface outside. Ici, un PAT (Port
Address Translation) va être appliqué, car nous n’avons saisi qu’une seule adresse de mappage, et
que nous avons plusieurs adresses à mapper. Il est à noter que le PAT peut ne pas fonctionner avec
certains protocoles(dont IPSEC !) ou certaines applications bien spécifiques. Dans ces cas là, plusieurs
solutions existent avec les ASA (Application Inspection, NAT statique pour certaines adresses sources
et PAT pour les autres, …)
Testez maintenant une requête HTTP sur le serveur web 200.1.1.2. Cela devrait fonctionner, même si
les routeurs n’ont pas les routes vers les réseaux 10.1.0.0 et 10.2.0.0. Lancez wireshark ou tcpdump
sur le serveur, et observez les adresses des paquets. Vérifiez que les adresses sont bien translatées.
Le problème est maintenant le suivant : si les PC du réseau 1 veulent communiquer avec le réseau 2
de la même manière que sur un réseau local, via le tunnel VPN que nous allons créer, il ne faut pas
leur appliquer de NAT. Voici les commandes à appliquer :
ASA1(config)# access-list NONATVPN extended permit ip 10.1.0.0

255.255.0.0 10.2.0.0 255.255.0.0
--création d’une ACL matchant le trafic ip allant du réseau 10.1.0.0/16 vers le réseau 10.2.0.0/16
ASA1(config)# nat (inside) 0 access-list NONATVPN
--on exclue du nat (le numéro de règle 0 est utilisé pour l’exclusion) le trafic entrant par inside et
matchant l’ACL NONATVPN.
I.3 – Etablissement du tunnel VPN
I.3.a – Paramètres ISAKMP
ISAKMP (Internet Security Association and Key Management Protocol) est le protocole de
négociation nécessaire pour que deux hôtes se mettent d’accord sur une politique de sécurité.
ISAKMP sépare la négociation en deux phases. La première phase crée un premier tunnel, qui
protégera les négociations du protocole ISAKMP. La deuxième phase crée le tunnel qui protègera les
données.
Vous allez donc devoir créer une ou plusieurs politiques ISAKMP, qui regroupent les éléments
suivants :
-une méthode d’authentification (pre-share, crack, rsa-sig)
-une méthode de cryptage (aes, aes-192, aes-256, des, 3des)
-une méthode de hachage (md5, sha)
-un groupe de Diffie-Hellman (1, 2, 5, 7)
-une limite de temps pour le remplacement des clefs de cryptage (en secondes)

Comme plusieurs politiques de sécurité peuvent être crées, il faudra définir leur priorité (+petit =
+prioritaire). Ici, nous ne créerons qu’une seule politique ISAKMP. Tous les paramètres ISAKMP
doivent être les mêmes des deux côtés du tunnel, mis à part la durée de remplacement des clefs, qui
doit être plus petite (ou égale) sur le répondeur que sur l’initiateur de la connexion.
Voici les commandes que vous devez exécuter pour établir une politique ISAKMP :
ASA(config)#crypto isakmp policy priority encryption [aes | aes-192
| aes-256 | des | 3des]
ASA(config)#crypto isakmp policy priority hash [md5 | sha]
ASA(config)#crypto isakmp policy priority authentication [pre-share
| crack | rsa-sig]
ASA(config)#crypto isakmp policy priority group [1 | 2 | 5 | 7]
ASA(config)#crypto isakmp policy priority lifetime seconds
Créez sur chaque ASA une politique ISAKMP de priorité 1, avec les paramètres suivants :
authentification par clef pré-partagée, méthode de cryptage 3des, méthode de hachage sha1, groupe
de Diffie-Hellman 2, durée de renouvellement des clefs 86400.
NB1 : la méthode des clefs pré-partagées n’est sans doute pas la plus sécurisée, et est peu utilisée sur
les réseaux importants. Elle présente toutefois l’avantage d’être plus simple à mettre en œuvre que
les certificats d’authenticité et les serveurs d’authentification, et reste très utilisée sur les petits
réseaux.
NB2 : vous devez probablement déjà connaître ce qu’est une méthode de cryptage et
d’authentification, mais pas à quoi sert le groupe de Diffie-Hellman. Sans rentrer dans les détails, il
détermine la force de l’algorithme de détermination des clefs de cryptage. L’ASA utilise cet algorithme
pour déterminer les clefs de cryptage et de hachage. Plus le groupe de Diffie-Hellman est élevé, plus
la méthode est sûre. Certains groupe de Diffie-Hellman ne conviennent pas à certaines méthodes de
cryptage, à vous de vous renseigner si vous voulez en savoir plus.
Une fois votre politique de sécurité crée, vous pouvez activer le protocole ISAKMP sur l’interface
outside avec la commande :
ASA(config)#isakmp enable outside
I.3.b-Transform set
Lorsque vous créez un tunnel VPN, vous voudriez peut-être que des données moins sensibles soient
moins bien protégées que des données très sensibles, afin d’économiser du temps processeur et de
la bande passante. C’est à cela que servent les transform set. Ils sont associés à des ACL, elles-mêmes
associées à des crypto map (que nous verrons bientôt). Un transform set combine une méthode de
cryptage et une méthode de hachage. Ce genre de chose pouvant vite se révéler très complexe à
configurer, nous ne nous en soucieront pas. Sachez simplement qu’au moins un transform set doit
être crée pour pouvoir faire fonctionner un tunnel VPN, et que les deux ASA aux extrémités du tunnel
doivent avoir au moins un transform set en commun. Sur chacun des ASA, vous créerez donc le
transform set suivant :
ASA(config)# crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
I.3.c-Tunnel group
Un tunnel group est une liste de paramètres de connexion pour la création de tunnels VPN. Là
encore, la configuration est assez complexe, et nous ne rentrerons pas dans le détail. Par défaut, un

ASA contient deux tunnel groups déjà enregistrés : le premier est utilisé pour les tunnels End-to-Lan,
le second pour les tunnels Lan-to-Lan. Créez un tunnel group de type Lan-to-Lan sur chaque ASA, à
l’aide de la commande suivante :
ASA(config)#tunnel-group TUNNELNAME type ipsec-l2l
ATTENTION : comme vous avez pu le remarquer, certaines contraintes sur le matériel cisco semblent
douteuses. Dans le cas des tunnel groups, le nom du tunnel doit être une adresse IP, sauf si vous êtes
en mode ISAKMP agressif ou si vous vous authentifiez par certificat. Dans ce cas là, vous pouvez
mettre une chaîne de caractères quelconque. Nous vous conseillons, sur chaque ASA, de mettre
l’adresse IP de l’autre extrémité du tunnel comme nom de tunnel group.
Nous devons maintenant définir la clef pré-partagée entre les deux extrémités du tunnel :
ASA(config)#tunnel-group TUNNELNAME ipsec-attributes

ASA(config-tunnel-ipsec)#pre-shared-key toto
NB: la clef pré-partagée toto est utilisée ici pour éviter des erreurs et des pertes de temps pendant le
TP. Dans la réalité, si vous êtes amenés à choisir une clef pré-partagée, choisissez une combinaison de
chiffres et de lettres suffisamment longue, ne figurant pas dans un dictionnaire et n’ayant aucune
signification particulière.
I.3.c-Crypto map
Avant d’expliquer ce qu’est une crypto map, nous devons configurer une ACL permettant le trafic
dans le tunnel. Souvenez vous, tout est interdit sur les ASA, et depuis le début de ce TP, nous n’avons
autorisé que le trafic ICMP et certaines requêtes HTTP. Nous devons donc autoriser les paquets IP
entre les deux sites distants. Cette ACL sera associée à une crypto map, et c’est le trafic spécifié par
cette ACL qui sera protégé avec les méthodes spécifiées par le transform set de la crypto map. Vous
utiliserez l’ACL suivante sur l’ASA1, et son miroir sur l’ASA2 :
ASA1(config)#access-list IPVPN extended permit ip 10.1.0.0

255.255.0.0 10.2.0.0 255.255.0.0
La crypto map est l’élément qui rassemble tous les paramètres d’association de sécurité IPSec que
vous avez crée précédemment. Elles peuvent être assez complexes, et nous n’étudierons donc que
les paramètres les plus basiques, en protégeant tous les flux traversant le tunnel de la même
manière. La crypto map définit quel trafic est à protéger (défini dans une access-list), où envoyer le
trafic protégé (adresse publique de l’autre extrémité du tunnel) et quelles sécurités appliquer au
trafic (application du transform set). Les crypto map doivent bien entendu être compatibles entre les
deux extrémités du tunnel. Pour éviter les erreurs, nous définirons exactement les mêmes
paramètres sur les deux ASA, mais sachez que cela n’est pas obligatoire.
Voici les commandes à entrer sur l’ASA1 :

ASA1(config)#crypto map MAPNAME 1 match address IPVPN
--la crypto map 1 s’applique au trafic qui matche l’ACL IPVPN (définie ci-dessus)
ASA1(config)#crypto map MAPNAME 1 set peer 195.168.2.1
--on identifie l’ASA à l’autre bout du tunnel par son adresse publique
ASA1(config)#crypto map MAPNAME 1 set transform-set ESP-3DES-SHA
--on appliqué le transform set ESP-3DES-SHA défini précédemment
ASA1(config)#crypto map MAPNAME interface outside
--on active la crypto map sur l’interface outside

I.4-Analyse et vérification
Nous allons maintenant passer à la vérification de notre travail. Pour que cela soit plus intéressant,
vous allez activer un serveur http sur une machine du site 2 (PC6 par exemple), à l’aide de la
commande :
/etc/init.d/apache2.insa start
Vous placerez un hub entre PC1 et le switch, sur lequel vous brancherez également PC2. PC1 va
tenter de se connecter au site web de PC6. PC2 snifera le trafic à l’aide de wireshark. Il cherchera
notamment le paquet contenant le texte de la page web, et le verra en clair. Déplacez maintenant le
hub entre ASA1 et INTERNET1, videz le cache internet de PC1, et renouvelez l’expérience. Vous
devriez constater que le trafic est crypté. Laissez la joie vous envahir, puis continuez vers la partie 2
du TP.
II – ETABLISSEMENT D’UN TUNNEL END-TO-LAN
Nous allons maintenant configurer un tunnel End-to-Lan, également appelé VPN Roadwarrior ou
encore Remote Access VPN. Il s’agit, pour un employé de l’entreprise, de pouvoir se connecter au
réseau interne de cette dernière, de manière sécurisée, à partir d’une connexion Internet
quelconque. Deux approches sont possibles : l’employé se connecte à partir d’un client web, sans
aucune installation nécessaire sur sa machine (VPN SSL, que nous verrons dans un autre TP), ou à
partir d’un client lourd. C’est cette deuxième option que nous allons explorer.
II.1-ASDM (Adaptative Security Device Manager)
Vous avez pu constater lors de la partie I que nous avons configuré les ASA à l’aide de l’interface en
ligne de commande. Vous devez savoir qu’il existe un outil assez développé pour configurer les
machines en mode graphique, à partir d’un navigateur web. Il s’agit d’ASDM.
Bien que cet outil soit moins puissant qu’une interface en ligne de commande, il n’en reste pas moins
utile pour des novices sur ce type d’appareil, ainsi que pour un monitoring graphique des machines,
plus convivial. Il dispose également d’assistants particulièrement utiles pour créer les configurations
les plus courantes, et notamment les VPN lan to lan et remote access.
Nous allons utiliser ASDM version 5 pour cette seconde partie de TP. Gardez cependant à l’esprit que
c’est un outil automatique, qui générera les commandes CLI en fonction de vos clics. Il n’est donc pas
aussi précis qu’une interface en ligne de commande. Pour l’avoir testé sur la configuration du tunnel
lan to lan, il est apparu que certaines commandes générées par ASDM étaient superflues.
Connectez un PC à l’interface management de l’ASA1. Affectez à ce PC l’adresse 192.168.1.2/24, puis

configurez l’ASA à l’aide des commandes suivantes :
ASA1(config)#interface Management 0/0

ASA1(config-if)#nameif management
ASA1(config-if)#no shut
ASA1(config)#http server enable
--active le serveur http de l’ASA
ASA1(config)#http 192.168.1.0 255.255.255.0 management
--autorise l’accès à l’interface management au réseau 192.168.1.0

Vous pouvez désormais vous connecter à l’interface management en tapant https://192.168.1.1 dans
un navigateur web. Acceptez les certificats d’authenticité, et cliquez sur « Launch ASDM » (nécessite
que java soit installé sur votre machine). ASDM se lance. Il vous informe qu’il a détecté une nouvelle
configuration d’ASA, et vous demande de procéder à quelques vérifications. Laissez vous guider
jusqu’à la disparition de ces fenêtres.
II.2-Configuration du tunnel
Vous pouvez maintenant cliquer sur Wizzards, puis VPN wizzard. L’assistant de configuration de
tunnels VPN s’ouvre.
Etape 1
Sélectionnez VPN Remote access. L’interface du tunnel est l’interface outside de l’ASA. Cochez la
case en bas pour passer outre les ACL.
Etape 2
Vous n’avez normalement qu’un seul choix possible. Passez à l’étape suivante. Sachez par avance que
bien que vous avez sélectionné un client Cisco, nous utiliserons un client d’une autre marque sur le
PC distant.
Etape 3
Indiquez comme nom de tunnel 192.168.1.1. Utilisez une authentification par clef pré-partagée, avec
comme clef le mot « lulu ».
Etape 4
Nous n’avons pas le temps dans ce TP de nous authentifier avec un serveur d’authentification dédié
tel que Radius ou AAA. Nous utiliserons donc la base locale d’utilisateurs de l’ASA.
Etape 5
Configurez plusieurs comptes d’utilisateurs à votre guise.
Etape 6
Choisissez le pool d’adresses qui seront affectées aux utilisateurs distants. Nommez le pool
« RemoteAccessPool », et configurez des adresses allant de 10.3.0.1/16 à 10.3.0.253/16.
Etape 7
Cette étape permet de fournir au client certains paramètres de connections automatiquement. Nous
ne nous servirons pas de cette possibilité.
Etape 8 et 9
Conservez les paramètres de cryptage et de hachage par défaut.
Etape 10
Permettez aux utilisateurs distants un accès à toutes les machines du réseau interne, en cliquant
directement sur Add. Activez le split tunneling.
Etape 11
Observez les commandes qui vont être envoyées à l’ASA, et envoyez le tout.

Il faut maintenant configurer le client. Nous utiliserons le client TheGreenBow, dont la version
d’évaluation est disponible sur Internet. La manipulation se fera sous Windows. Consultez les
captures d’écran suivantes pour configurer votre client.
Comme vous l’avez vu dans la première partie du TP, la négociation ISAKMP présente deux phases.
Ce sont ces deux phases que nous allons configurer sur le client.
Entrez ici votre clef pré-partagée

(lulu), le nom de votre tunnel, l’IP
publique de l’autre extrémité du
tunnel et l’interface réseau du client
qui fera office d’extrémité.
Configurez les paramètres de
sécurité en adéquation avec ceux
que vous avez utilisés sur l’ASA.
Entrez ici le login et le mot de passe

de l’utilisateur. Sachez que vous êtes
ici en mode administrateur. Vous
pourrez ensuite bloquer les options
d’administration et laisser un client
simplifié à vos utilisateurs. Dans ce
cas là, laissez ces champs vides, et ils
vous seront demandés lors de la
connexion. La case config mode sert
à récupérer certains paramètres
depuis l’ASA(adresse IP, serveur
DNS,…). La case agressive mode
permet une négociation plus rapide,
mais moins sécurisée. Local et
Remote ID sont les identifiant que
les deux extrémités s’attendent à
recevoir pour s’authentifier
mutuellement.

Ceci correspond à la phase 2 de la

négociation. Vous pouvez
demander une certaine adresse IP
dans le cas ou le mode
configuration n’a pas été activé.
Vous devez spécifier le réseau
distant auquel vous vous connectez.
II.3-Vérification
Installez un serveur web sur le site 1, et un autre sur le site 2, à l’aide des commandes suivantes :
Connectez l’utilisateur distant en cliquant sur « ouvrir le tunnel NOMTUNNEL ». Tentez d’accéder au
site 1, puis au site 2. Vous constaterez que le site 2 n’est pas accessible. Vérifiez-le par un ping.
[Partie à améliorer : il serait judicieux ici de pouvoir faire en sorte d’avoir accès aux différents sites de
l’entreprise simplement en se connectant en remote access. Par manque de temps, nous n’avons pas
exploré dans le détail cette possibilité. Nous avons donc choisi de contourner le problème de la
manière suivante :
-l’utilisateur distant pourra accéder aux machines du site 2 en se connectant en ssh sur une machine
du site 1.
-un proxy web sera installé sur le site 1, pour permettre de relayer les requêtes web sur le serveur du
site 2]
Vérifiez que vous pouvez vous connecter aux machines du site 2 en passant en ssh par une machine
du site 1.
Nous allons maintenant configurer un serveur proxy sur le site 1, afin que l’utilisateur distant puisse
accéder au serveur web du site 2 à partir de son navigateur web. Pour ce faire, redémarrez le PC
serveur du site 1. Redonnez-lui une adresse IP et une passerelle par défaut.

Il vous faudra alors modifier le fichier /etc/apache2/mods-enabled/proxy.conf.

Remplacez :
-ProxyRequest Off par ProxyRequest On
-Deny from all par Allow from all
Lancez le serveur avec la commande : /etc/init.d/apache2.insa start
Ajoutez le serveur proxy dans le navigateur du client, port 80.
Testez maintenant de vous connecter au serveur du site 2 et constatez que ca marche

TP SECURITE 1
MEMO DE DEPANNAGE
1-ADRESSAGE
PCs SITE 1
ifconfig eth0 10.1.0.1à3 netmask 255.255.0.0
route add default gw 10.1.0.254
PCs SITE 2
ifconfig eth0 10.2.0.1à3 netmask 255.255.0.0
SERVEUR INTERNET
ifconfig eth0 200.1.1.2 netmask 255.255.255.0
ROUTEUR INTERNET1
hostname(config)#hostname Internet1
Internet1(config) #interface fastEthernet 0/0
Internet1(config-if) #ip address 195.168.1.2 255.255.255.0
Internet1(config-if) #no shut
Internet1(config-if) #interface fastEthernet 0/1
Internet1(config-if) #interface serial 0/0/0
Internet1(config-if) #clock rate 125000
Internet1(config-if) #exit
Internet1(config) #ip route 10.1.0.0 255.255.0.0 195.168.1.1
Internet1(config) #ip route 0.0.0.0 0.0.0.0 serial 0/0/0
ROUTEUR INTERNET2
hostname(config)#hostname Internet2
Internet2(config) #interface fastEthernet 0/0
Internet2(config-if) #interface serial 0/0/0
Internet2(config-if) #exit
Internet1(config) #ip route 10.2.0.0 255.255.0.0 195.168.2.1
INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS B1
Internet2(config) #ip route 0.0.0.0 0.0.0.0 serial 0/0/0

--ATTENTION pour les routes par défaut. On a crée une boucle de
routage, il faut donc envoyer du trafic dont on sait qu’il sera
correctement expédié.
ASA1
hostname(config)#clear configure all
ASA1(config)#access-list CONNECT permit icmp any any
ASA1(config)#access-list CONNECT extended permit tcp any any eq www
ASA1(config)#access-group CONNECT in interface outside
ASA2
hostname(config)#clear configure all
ASA2(config)#access-list CONNECT permit icmp any any
ASA2(config)#access-list CONNECT extended permit tcp any any eq www
ASA2(config)#access-group CONNECT in interface outside

2-NAT
ROUTEUR INTERNET1
hostname(config)#no ip route 10.1.0.0 255.255.0.0 195.168.1.1
ROUTEUR INTERNET2
hostname(config)#no ip route 10.2.0.0 255.255.0.0 195.168.2.1
ASA1
255.255.0.0 10.2.0.0 255.255.0.0
ASA2
255.255.0.0 10.1.0.0 255.255.0.0
3-TUNNEL VPN LAN-TO-LAN

ASA1
ASA1(config)#crypto isakmp policy 1 encryption 3des
ASA1(config)#crypto isakmp policy 1 hash sha
ASA1(config)#crypto isakmp policy 1 authentication pre-share
ASA1(config)#crypto isakmp policy 1 group 2
ASA1(config)#crypto isakmp policy 1 lifetime 86400
ASA1(config)#isakmp enable outside
ASA1(config)#crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-
hmac
ASA1(config)#tunnel-group 195.168.2.1 type ipsec-l2l
ASA1(config)#tunnel-group 195.168.2.1 ipsec-attributes
ASA1(config-tunnel-ipsec)#pre-shared-key toto
ASA1(config-tunnel-ipsec)#access-list IPVPN extended permit ip 10.1.0.0
255.255.0.0 10.2.0.0 255.255.0.0
ASA1(config)#crypto map MYMAP 1 match address IPVPN
ASA1(config)#crypto map MYMAP 1 set peer 195.168.2.1
ASA1(config)#crypto map MYMAP 1 set transform-set ESP-3DES-SHA
ASA1(config)#crypto map MYMAP interface outside

ASA2
ASA2(config)#crypto isakmp policy 1 encryption 3des
ASA2(config)#crypto isakmp policy 1 hash sha
ASA2(config)#crypto isakmp policy 1 authentication pre-share
ASA2(config)#crypto isakmp policy 1 group 2
ASA2(config)#crypto isakmp policy 1 lifetime 86400
ASA2(config)#isakmp enable outside
ASA2(config)#crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-
hmac
ASA2(config)#tunnel-group 195.168.1.1 type ipsec-l2l
ASA2(config)#tunnel-group 195.168.1.1 ipsec-attributes
ASA2(config-tunnel-ipsec)#pre-shared-key toto
ASA2(config-tunnel-ipsec)#access-list IPVPN extended permit ip 10.2.0.0
255.255.0.0 10.1.0.0 255.255.0.0
ASA2(config)#crypto map MYMAP 1 match address IPVPN
ASA2(config)#crypto map MYMAP 1 set peer 195.168.1.1
ASA2(config)#crypto map MYMAP 1 set transform-set ESP-3DES-SHA
ASA2(config)#crypto map MYMAP interface outside
4-TUNNEL VPN ROADWARRIOR

ASA1
ASA1(config)#interface Management 0/0
ASA1(config-if)#nameif management
ASA1(config-if)#no shut
ASA1(config)#http server enable
ASA1(config)#http 192.168.1.0 255.255.255.0 management








PC DISTANT
ifconfig eth0 100.1.1.2 netmask 255.255.255.0


TP SECURITE n°2
MISE EN PLACE D’UN ACCES SSL CLIENTLESS ET CLIENT LEGER

SSL est un protocole s'appuyant sur la couche 4 du modèle OSI – transport – afin d'offrir des services de
sécurité aux couches supérieures – applicatives. Un VPN SSL, dans son mode Clientless, ne nécessite pas
l’installation d’un logiciel spécifique sur l’ordinateur de l’utilisateur distant. Un simple navigateur web suffit à
assurer un accès sécurisé aux ressources. Ceci garantit facilité de mise en place et simplicité d’utilisation :
pas de distribution de logiciel à effectuer et problèmes de compatibilités logicielles évités.
L’objectif de ce TP est de mettre en place le mode WebVPN proposé par les ASA 5500 de Cisco. WebVPN est
l’implémentation Cisco du mode clientless de SSL. Pour y parvenir, nous allons utiliser les deux outils mis à
disposition par Cisco : la ligne de commande – CLI – et l’interface graphique – ASDM.
Cependant ce mode Clientless ne permet que l’utilisation des plugs-in proposés sur la page web d’accueil.
C’est pourquoi vous mettrez ensuite en place un tunnel SSH utilisant un client léger ‘Anyconnect’ qui permet
l’utilisation de n’importe quel protocole IPv4 unicast ou IPv6.
I – SCENARIO
Imaginons un campus universitaire qui souhaite mettre à disposition des étudiants et du personnel un accès
à Internet ainsi qu’un accès aux ressources internes de l’université (intranet, espace de stockage individuel,
etc.). Le personnel et les étudiants doivent pouvoir accéder à ces ressources depuis l’intérieur et depuis
l’extérieur du campus. De plus, l’accès aux ressources sera différencié selon que l’utilisateur est un étudiant
ou un membre du personnel. La situation est présentée par la topologie suivante.
Le routeur ASA est connecté à Internet via son interface Ethernet 0/0. Pour des raisons pratiques, internet
sera ici simulé par un routeur, derrière lequel un ordinateur sera connecté.
INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS C1

Les membres du personnel ont accès aux ressources présentes sur les réseaux 192.168.2.0/24 et
193.168.2.0/24, tandis que les étudiants n’ont accès qu’aux ressources du réseau 193.168.2.0/24. Ces
ressources sont inaccessibles à toutes les autres personnes.
II – CLIENTLESS SSL
II.1 – Configuration en ligne de commandes (CLI)
II.1.a – Configuration des interfaces
Configurez une à une les interfaces :
(config)# interface Ethernet 0/0

(config-if)# nameif outside
(config-if)# ip address 200.100.10.1 255.255.255.0
(config-if)# no shutdown

(config-if)# nameif inside

(config-if)# nameif ressInternes
(config-if)# security-level 100

(config-if)# nameif ressPubliques
(config-if)# security-level 50
II.1.b – Connexion à Internet
Afin de garantir la transmission du trafic internet, il est nécessaire d’établir une route par défaut vers le
routeur qui y donne accès. Créez donc une route statique sur l’interface outside :
(config)# route outside 0.0.0.0 0.0.0.0 200.100.10.254
II.1.c – Activation du WebVPN
Il faut maintenant rendre possible la création de sessions WebVPN sur les interfaces autorisées.
(config)# webvpn
(config-webvpn)# enable inside
(config-webvpn)# enable outside
Désormais, tout ordinateur relié à l’interface inside ou outside de l’ASA est capable d’établir une session
WebVPN avec l’ASA. Pour cela, ouvrez Iceweasel et entrez l’adresse correspondant à l’interface de l’ASA à
laquelle vous êtes relié. Vous remarquez qu’une identification est nécessaire à l’établissement de la session.
II.1.d – Création et configuration des utilisateurs
L’ASA supporte plusieurs types de serveurs AAA : Radius, LDAP, TACACS, etc. Comme son nom l’indique (AAA
est l’acronyme de « Authentication, Authorization, Accounting »), un serveur AAA est responsable de
l’identification, de la gestion des autorisations et de la sauvegarde des actions effectuées. Afin de garder la
configuration simple, nous allons utiliser le serveur AAA Cisco, local au routeur. Il est donc nécessaire de
créer les utilisateurs sur l’ASA :
II.1.d.i – Création des utilisateurs
(config)# username etienne password truc2ouf

(config)# username damien password j8m4la2
II.1.d.ii – Création et configuration des politiques de groupe
Les droits des utilisateurs sont définis par la politique du groupe auquel ils appartiennent. Nous allons donc
créer deux politiques de groupe et spécifier que seul l’accès WebVPN y est autorisé.
(config)# group-policy Etudiant internal

(config)# group-policy Etudiant attributes
(config-group-policy)# vpn-tunnel-protocol webvpn
(config)# group-policy Chef internal
(config)# group-policy Chef attributes
(config-group-policy)# vpn-tunnel-protocol webvpn
II.1.d.i – Assignation des utilisateurs à un groupe
Par défaut, les utilisateurs sont associés à la politique DfltGrpPolicy. Nous allons changer cette association
grâce aux commandes suivantes.
(config)# username damien attributes

(config-username)#vpn-group-policy Etudiant
(config)# username etienne attributes
(config-username)# vpn-group-policy Chef
II.1.e – Gestion des autorisations
Pour le moment, bien qu’étant associé à deux politiques différentes, les utilisateurs ont exactement les
mêmes droits, puisque les politiques sont identiques en tout point.
L’objectif est maintenant d’associer des droits spécifiques à chaque groupe d’utilisateurs. Rappelez-vous que
les membres du personnel ont accès aux ressources présentes sur les réseaux 192.168.2.0/24 et
193.168.2.0/24, tandis que les étudiants n’ont accès qu’aux ressources du réseau 193.168.2.1.
II.1.e.i – Créer les ACL
Il est possible d’associer une ACL à une session WebVPN d’un groupe spécifique.
Pour cela, nous allons créer les deux ACLs :

(config)# access-list WACLEtudiant webtype permit tcp 193.168.2.0

255.255.255.0 eq http
(config)# access-list WACLChef webtype permit tcp 193.168.2.0
255.255.255.0 eq http
(config)# access-list WACLChef webtype permit tcp 192.168.2.0
255.255.255.0 eq ssh
II.1.e.ii – Agir au niveau de la group policy
Ensuite, il faut associer les ACLs aux politiques de groupe correspondantes :
(config)# group-policy Etudiant attributes

(config-group-policy)# webvpn
(config-group-webvpn)# filter WACLEtudiant
(config)# group-policy Chef attributes

(config-group-policy)# webvpn
(config-group-webvpn)# filter WACLChef
II.1.f – Test
Tout est correctement configuré au niveau de l’ASA. Pour vérifier, connectez-vous au portail WebVPN depuis
un ordinateur relié à l’interface inside ou outside.
Un serveur HTTP est en place sur l’hôte 193.168.2.1. Pour y accéder, sélectionner le protocole http dans la
barre d’adresse proposée par le portail et entrez l’adresse IP. Que vous vous soyez identifié en tant que
« etienne » ou « damien », l’accès vous est autorisé.
Un serveur SSH est en place sur l’hôte 192.168.2.1. Sélectionnez le protocle « ssh » dans la barre d’adresse
présente sur le portail et entrez cette adresse. Si vous vous êtes préalablement identifié en tant que
« etienne », vous devez avoir accès au serveur ssh. Sinon, l’accès doit vous être refusé.
Vous avez réussi à mettre en place un accès clientless VPN SSL, avec accès différencié aux ressources selon
l’utilisateur, grâce au mode WebVPN de Cisco.
II.2 – Configuration par l’interface graphique (ASDM)
Vous allez maintenant refaire cette configuration mais en utilisant l’interface graphique proposée par l’ASA :
ASDM. Pour enlever la configuration que vous venez d’établir, faites un reload.
Configuration d’ASDM :
- Configurer l’interface Management 0/0 :

(config) # interface Management 0/0
(config-if) # ip address [@IP] [netmask]
(config-if) # nameif management
(config-if) # no shut
(config-if) # http server enable
(config) # http [@IPsubnet] [netmask] management

- Se connecter au serveur http configuré précédemment avec un navigateur internet en utilisant le

protocole https.
N.B :WebVPN et ASDM ne peuvent être activés sur la même interface de l’ASA sauf si l’on change les
ports utilisés
Cliquez sur le bouton Configuration dans la fenêtre.
II.2.a – Configuration des interfaces
Cliquez sur Device Configuration > Interfaces. Double-cliquez sur l’interface Ethernet 0/0. Une nouvelle
fenêtre apparait ; renseignez là en accord avec la topologie. Valider les informations en appuyant sur OK.
Faites de même avec les autres interfaces.
Rappel : les réseaux 10.10.10.0/8 et 192.168.2.0/24 sont des réseaux de confiance, leur security-level est
donc de 100. Le réseau 193.168.2.0/24 a un security-level de 50 et 200.100.10.0/24 un security-level de 0.
Cliquez sur Apply.

II.2.b – Connexion à Internet
Pour ajouter la route statique : Configuration > Device Setup > Routing > Static Routes. Cliquez sur Add et
remplissez les informations et validez en cliquant sur OK.
Cliquez sur Apply.
II.2.c – Activation du WebVPN
Configuration > Remote Access VPN >Clientless SSL VPN Access > Connection Profiles.
Dans la partie supérieure, Access Interfaces, cochez les cases « allow access » pour les interfaces Inside et
Outside.

Cliquez sur Apply.
II.2.d – Création et configuration des utilisateurs
II.2.d.i – Création et configuration des politiques de groupe
Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies.
Cliquez sur Add, et créez ainsi les politiques de groupe Etudiant et Chef. A chaque fois
, pensez à décocher « Inherit » au niveau des tunneling protocols afin de ne sélectionner que « Clientless SSL
Client ».

Cliquez sur Apply.
II.2.d.ii – Création des utilisateurs
Maintenant que les politiques sont crées, nous allons créer les utilisateurs et les associer à ces politiques.
Configuration> Device Management > Users/AAA > User Accounts.
Cliquez sur Add. Dans la nouvelle fenêtre, renseignez le nom et le mot de passe de l’utilisateur. Ensuite,
sélectionnez VPN Policy dans la partie de gauche. Là, décochez Inherit au niveau du group policy et
sélectionnez une des deux politiques précédemment créée. Créez ainsi deux utilisateurs, chacun
appartenant à une politique de groupe différente.

Cliquez sur Apply.
II.2.e – Gestion des autorisations
II.2.e.i – Création des ACL
Configuration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Web ACLs.
Cliquez sur Add > Add ACL. Nommez l’ACL WACLEtudiant et validez en appuyant sur OK.
Il faut maintenant ajouter une ACE à l’ACL : Add > Add ACE et renseignez les valeurs, comme indiqué sur
l’image.

De même, créez l’ACL WACLChef et associez-y les deux ACE permettant l’accès aux ressources du scénario.
Cliquez sur Apply.
II.2.e.i – Agir au niveau de la group policy
Pour ajouter les ACLs aux politiques de groupes, rendez-vous à la page des politiques de groupe :
Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies.
Là, double-cliquez sur la politique Etudiant et dans la partie « Général », décochez Inherit au niveau de Web
ACL et sélectionnez l’ACL ACLEtudiant, et validez en appuyant sur OK. Faites de même avec la politique Chef.
Cliquez sur Apply.
III – MODE SSL ANYCONNECT
III.1 – Configuration en ligne de commandes (CLI)
III.1.a – Activer le WebVPN
-passer en configuration de webvpn et activer le tunnel ssh sur l’interface souhaitée.

ciscoasa(config)#webvpn
ciscoasa(config-webvpn)#enable [interface]
-choisir le client que proposera l’ASA

ciscoasa(config-webvpn)#svc image disk0:/ anyconnect-win-2.1.0148-k9.pkg
1
//ciscoasa(config-webvpn)#tunnel-group-list enable
ciscoasa(config-webvpn)#svc enable
-créer un utilisateur dans le registre local
ciscoasa(config)# username roger password m2GvE7s5kNgYmR6g encrypted

privilege 0
-créer le pool d’adresses attribuées aux clients anyconnect :
ciscoasa(config)# ip local pool [nom du pool] [@début]-[@fin] mask

[netmask]
-configurer la ‘group policy’ interne qui agira sur les connexions SSL anyconnect : préciser le protocole utilisé
par le tunnel ainsi que le pool d’adresses qui lui est associé
ciscoasa(config)# group-policy [nom group-policy] internal

ciscoasa(config)# group-policy [nom group-policy] attributes
ciscoasa(config-group-policy)# vpn-tunnel-protocol svc
ciscoasa(config-group-policy)# address-pools value [nom du pool]
-configurer le profil de connexion auquel on associera le group-policy ainsi que la pool d’adresses configurés
précédemment :
ciscoasa(config)#tunnel-group [nom tunnel-group] type remote-access

ciscoasa(config)#tunnel-group [nom tunnel-group] general-attributes
ciscoasa(config-tunnel-general)#address-pool [nom du pool]
ciscoasa(config-tunnel-general)#default-group-policy clientgroup
-ajouter l’ACL permettant au serveurs internes de répondre aux requêtes des clients :
ciscoasa(config)#access-list split-tunnel standard permit <@IP réseau interne> <netmask>
ciscoasa(config-group-policy)#split-tunnel-policy tunnelspecified
ciscoasa(config-group-policy)#split-tunnel-network-list value split-tunnel
III.1.b – Vérifications
Afin de connaître les versions du client SSL stockées sur la mémoire de l’ASA :
ciscoasa # show webvpn svc
Pour voir les connexions SSL en cours :
ciscoasa # show vpn-sessiondb svc

Vous pouvez vérifier que la connexion en cours utilise bien la group-policy et le Tunnel Group que vous
venez de créer. De plus vérifiez que l’hôte a bien reçu une adresse appartenant au pool d’adresses utilisé par
le tunnel.
Si vous souhaitez mettre fin à une session VPN SSL, utilisez la commande :
ciscoasa# vpn-sessiondb logoff name [nom user]

(ciscoasa# vpn-sessiondb logoff svc ) permet de terminer toutes les sessions simultanément.
D’autres commandes pour le débogage :
show run webvpn
show run {group-policy | tunnel-group | [group-name] }

debug dap trace
III.1.c – Mise en place du tunnel
Connectez vous à l’adresse suivante : https:// [@ IP interface sur laquelle est activée le tunnel]
III.1.d – Configuration d’un VPN SSL AnyConnect avec ASDM
Après avoir lancé l’utilitaire ASDM en suivant la procédure décrite dans le chapitre précédent, cliquez sur
Wizard/SSL VPN wizzard. Cocher Cisco SSL VPN Client (Anyconnect VPN client).
Indiquez ensuite le nom du ‘connection profile’ et choisissez l’interface sur laquelle vous désirez activer le
tunnel SSL. Concernant l’authentification, optez pour l’utilisation de la base de donnée locale.
Créez ensuite une nouvelle group-policy et un pool d’adresses qui seront associés au tunnel SSL.
Sélectionner dans la flash l’image du client VPN à utiliser. Une fois toutes les étapes du wizzard terminées
basculez dans le menu Network (client) Access->Group Policies. Cliquez sur la group policy que vous venez
de créer, puis sur edit et décochez inherit de Address pools puis indiquez le pool que vous avez mis en place.

PFE ASA Firewall

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PFE ASA Firewall

Transféré par

Droits d'auteur :

Formats disponibles

AVOLEDO Mickaël

CONFIGURATION D’ASA CISCO

Département de Génie Electrique et Informatique

Tuteur : M. Vincent NICOMETTE

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS

III – ETUDE DES FONCTIONNALITES VPN 17

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 1

I – ETAT DE L’ART DES TECHNOLOGIES VPN

On distingue principalement deux modes d’utilisation de ces technologies :

I.2 – Les différentes technologies VPN

Encapsulation successive des données avec L2TP :

PPP IP UDP (port 1701) PPP IP TCP,UDP Données

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 2

L2TP assure l’authentification et le support multi-protocole grâce à l’utilisation de PPP,

I.2.b – PPTP / GRE

Le schéma suivant résume bien cela :

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 3

Connexion de transmission de données :

I.2.b.ii – PPTP et la sécurité

Lorsqu'on se connecte à un serveur PPTP, on a accès au réseau privé du serveur, la sécurité

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 4

I.2.c.ii – Services offerts par IPsec

- Authentification des extrémités :

- Confidentialité des données :

- Intégrité des données :

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 5

- Protection contre le rejeu :

I.2.c.iii – Les « sous-protocoles » d’IPsec

IKE (Internet Key Exchange)

Next header Length 0

Security Parameters Index

Nous reviendrons sur le champ SPI par la suite.

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 6

ESP (Encapsulating Security Payload)

Voici l’en-tête ESP :

Security Parameters Index

Padding … Pad length Next header

I.2.c.iv – IPsec en mode tunnel et transport

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 7

Résumé des modes tunnel et transport

I.2.c.v – Association de sécurité et politique de sécurité

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 8

I.2.d – SSH (Secure Shell)

SSH utilise des techniques de chiffrement symétriques et asymétriques, l'algorithme de

I.2.e – SSL (Secure Socket Layer) et TLS (Transport Layer Security)

I.2.e.i – Propriétés et caractéristiques de TLS

- échange sécurisé des clés de chiffrement

I.2.e.ii – Fonctionnement de TLS

I.2.e.iii – Les VPN TLS

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 10

Interconnexion de sites et TLS

I.2.e.iv – Forces et faiblesses des VPN TLS

INSA Toulouse | AVOLEDO – BENBACHIR – BONET – CAPGRAS – DESTRAS 11

 Le mode « transparent » est de niveau 2 : Il facilite la configuration du réseau. Le mode

Par défaut, l’ASA est en mode « routed ».

L’ASA offre de nombreuses fonctionnalités, majoritairement de sécurité. Nous vous

II.1 – NAT (Network address translation)

II.2 – QoS (Quality of Service)

Pour implémenter la QoS, il faut :

II.3 – Security Context

II.4 – ACL (Access Control Lists)

II.5 – IPS (Intrusion Prevention Services)