Chapitre 3 : Sécurité de la couche réseau

Introduction
Les mécanismes de sécurité au niveau de la couche réseau sécurisent le trafic pour toutes les
applications et protocoles de transport des couches supérieures. Les applications n’ont pas à
être modifiées. Il existe essentiellement deux mécanismes de sécurité largement utilisés.

I) IPSec
IPSec (IP SECurity) a été développé par l'IETF dans le but de sécuriser TCP/IP au niveau de
la couche 3 (couche réseau du modèle OSI). Il peut fournir le contrôle d’accès,
l’authentification, l’intégrité des données et la confidentialité pour chaque paquet IP entre
deux nœuds réseau (hôte ou passerelle). Aucune modification du matériel ou du logiciel
réseau n’est nécessaire pour router IPSec. Les applications et les protocoles de niveau
supérieur peuvent rester inchangés. IPSec peut être présenté comme :

 étant un patch de sécurité pour IP (IPSec étant en option sous IPv4, mais obligatoire
avec le futur Ipv6),
 étant un protocole pouvant être utilisé sous deux modes (transport et tunnel),
 faisant appel à deux sous-protocoles (AH et ESP),
 et se basant sur plusieurs autres protocoles plus ou moins utilisés dans leur totalité
(ISAKMP, IKE, Oakley, Photuris, Skeme et SKIP).

I.1) Les concepts de base

I.1.1) La tunnelisation : C’est la méthode utilisée pour faire transiter des informations
privées sur un réseau public. Les tunnels sécurisés garantissent la confidentialité et l’intégrité
des données ainsi que l’authenticité des 2 parties. Dans cette méthode dite d’encapsulation,
chaque paquet est complètement chiffré et placé à l’intérieur d’un nouveau paquet.

Il existe 2 modes de transport distincts :

 I.1.1.a) Mode Transport : il protège le contenu d’une trame IP en ignorant l’en-tête.

Ce mode de transport est généralement utilisé entre les points terminaux d’une
connexion, idéal pour une connexion nomade sur un réseau.
 I.1.1.b) Mode Tunnel : plus performant, il crée des tunnels en encapsulant chaque
trame dans une enveloppe qui protège tous les champs de la trame. Il est utilisé entre 2
équipements dont au moins un n’est pas un équipement terminal. Les données peuvent
être chiffrées (mode ESP) ou pas (mode AH). Idéal pour relier 2 réseaux distants.

I.2) Les sous-procoles AH et ESP

I.2.1) Le sous-protocole AH (Authentication Header)

AH offre les services suivants :

1
Chapitre 3 : Sécurité de la couche réseau

a) Authentification : Cette fonctionnalité repose entre autres sur le concept de cookie

comme nous le verrons par la suite et est basée sur des clés pré-partagées, adresses IP,
noms FQDN, certificats X.509, ...,
b) Intégrité : L'intégrité est assurée par le calcul d'une MAC (paramètre ICV comme
nous le verrons par la suite et qui est rajouté dans le champ Authentification Data).
Elle est étroitement liée avec la non-répudiation, et le calcul de la MAC se fait après
cryptage des données, ce qui permet du coté du récepteur de vérifier l'authenticité du
paquet avant de se lancer pour rien si les paquets ont été altérés, dans la lourde
opération de décryptage,
c) Protection anti-rejeu optionnelle. On peut empêcher les attaques de man-in-the-
middle basiques en numérotant les paquets. Ceci est assuré via le champ Sequence
Number,
d) Non-répudiation. Selon les algorithmes utilisés (RSA par exemple).

Figure 1. Format de l'en-tête AH

• next Header (32 bits). Champ identifiant l'en-tête suivant,

• payload Length. Ce champ décrit la taille du AH, exprimé en multiples de 32 bits moins 2,

• reserved (16 bits). Ce champ est réservé pour une utilisation ultérieure. Il doit être fixé à 0
sans quoi le paquet est éliminé,

• SPI (32 bits). Il est sélectionné par le système de destination car c'est ce dernier qui va en
avoir besoin pour savoir comment traiter le paquet qui lui arrive,

• sequence Number (32 bits). Ce champ est le même que celui que l'on trouve dans l'ESP. Ce
champ est toujours présent,

• authentication Data (multiple de 32 octets). Ce champ contient la variable ICV et est

identique au champ de même nom dans ESP. Ce champ peut ne pas être présent si cette
option n'a pas été choisie dans la SA (Security Association) correspondante.

I.2.2) Le sous-protocole ESP (Encryption Security Payload)

Cette transformation offre en plus ceux de AH, les services suivants :

• confidentialité grâce au cryptage des données.

2
Chapitre 3 : Sécurité de la couche réseau

• protection des identités. Cette option ne peut être opérationnelle qu'en mode tunnel.

Figure 1. Format de l'en-tête AH

• SPI (32 bits). Il est sélectionné par le système de destination car c'est ce dernier qui va en
avoir besoin pour savoir comment traiter le paquet qui lui arrive. Ce champ est toujours
présent,

• sequence Number (32 bits). Chaque paquet est numéroté par ce champ de 32 bits. Ce
champ est initialisé à 0 dès qu'une nouvelle SA est établie, et le premier paquet envoyé sur le
réseau aura un numéro de séquence de 1. Incrémenté de 1 à chaque nouveau paquet envoyé,
sa limite sera donc de 232. Deux cas apparaissent alors quand cette limite est atteinte : soit la
protection anti-rejeu est activée par le récepteur auquel cas une nouvelle SA est générée avant
que ce numéro de séquence maximum de 232 est atteint et le compteur du numéro de
séquence est réinitialisé à 0 ; soit cette protection n'est pas activée et dans ce cas, on reprend
la numérotation des paquets à 1 avec la même SA. Cette option est toujours mise en place par
l'émetteur, mais ne sera vérifiée et prise en compte par le récepteur que si ce dernier le
souhaite (donc si cette option est choisie de son côté). En pratique, durant la phase d'échange
de paramètres de SA, le récepteur peut dire à l'émetteur s'il a activé l'option anti-rejeu, ce qui
évite à l'émetteur de faire du travail inutile. D'autre part, cette option ne peut être activée que
si la non-répudiation l'est aussi. Ce champ est toujours présent,

• payload Data (0-255 bits). Nous trouvons dans ce champ, si l'algorithme choisi le nécessite
(DES par exemple), le paramètre IV -Initialization Vector-. Ce champ est toujours présent,

• padding (0-255 bits). La nécessité du bourrage intervient lors de l'utilisation d'algorithmes

de cryptage nécessitant des chiffrements par blocs comme DES par exemple. Dans ce cas, il
arrive souvent que la longueur des données à chiffrer ne soit pas un multiple entier de cette
longueur de bloc, on rajoutera du bourrage de manière à avoir une longueur à crypter qui soit
un multiple entier de la longueur du bloc. Ce champ est très souvent présent

• pad Lengh. Dans ce champ, nous trouvons la longueur du champ précédent, ce qui nous
permet de savoir quels bits sont à ignorer (ceux de bourrage). Ce champ est toujours présent,

3
Chapitre 3 : Sécurité de la couche réseau

• next Header (8 bits). Ce champ permet de savoir quel est le type d'informations contenues
dans le champ « Payload Data » ; IPv4/IPv6, ICMP, IP, IGRP, … Ce champ est toujours
présent,

• authentication Data (variable). Ce champ contient la variable ICV qui est calculée sur
toute la trame moins ce champ-ci (i.e. « Authentication Data ») et qui permet donc d'assurer
l'intégrité des données transmises. Ce champ peut ne pas être présent si cette option n'a pas été
choisie dans la SA correspondante.

I.3) Association de sécurité SA

Une connexion IPSec repose sur l’usage d’une association de sécurité (SA -Security
Association-) unidirectionnelle (il en faudra donc deux par connexion, une pour chaque sens)
préalablement établie entre les correspondants et qui va permettre aux deux parties de
convenir des différents paramètres de la SA utilisés durant l’échange des données. Trois
paramètres l’identifient :

 un index de paramètres de sécurité (SPI -Security Parameters Index). Il s’agit d’une

chaîne de 32 bits de signification locale (propre au système qui gère l’association),
véhiculée en clair dans les en-têtes AH et ESP. Une SPI de valeur 0 est un cas
particulier pour dire qu’aucune SA n’a été encore créée,
 l’adresse de destination, il peut s’agir d’un système d’extrémité ou d’un système
intermédiaire (routeur, firewall ou poste de travail),
 l’identifiant de protocole de sécurité (SPId -Security Protocol Identifier-) qui indique
la nature de la SA (AH ou ESP).
I.3) La base de politique de sécurité (SPD -Security Political Database-)

On définit aussi une base de politique de sécurité (SPD -Security Political Database-), qui va
permettre de décider pour chaque paquet entrant ou sortant s’il va se voir attribuer des règles
de sécurité et même s’il sera autorisé à passer.

Tableau 2. Exemple de SPD

I.3) La base des associations de sécurité (SAD -Security Association Database-)

Chaque SA va être contenue dans ce que l’on appelle une base des associations de sécurité
(SAD - Security Association Database-). Cette base va contenir pour chaque SA les
informations qui lui sont relatives, ce qui permettra de savoir comment traiter chaque paquet à
envoyer. C’est une simple base de données qui va être consultée par la SPD. Cette base de
données contient toutes les informations de la SA.

4
Chapitre 3 : Sécurité de la couche réseau

Tableau 1. Exemple de SAD avec deux SA

La gestion des clés

Les 3 types de clés existantes

On a trois grands types de clés :

1) les clés de chiffrement de clés. Servant à chiffrer d’autres clés (par exemple crypter la
clé qui va permettre de transmettre la clé symétrique de chiffrement de données), ce
type de clé doit être par conséquent très solide (d’où une utilisation recommandée de
la cryptographie à clé publique) et a une durée de vie en général assez longue,
2) les clés de chiffrement de données. Comme son nom l’indique, ce type de clés permet
de crypter les données échangées. Les données à échanger pouvant être très grandes, le
cryptage / décryptage doit être le plus rapide possible, d'où le choix de clés
symétriques. La « fragilité » de ce type de clés est compensée par le fait que dans la
plupart des cas, ces clés changent souvent (elles ne durent pas plus de 10 minutes par
défaut par exemple sur un VPN monté sur un Firewall NetASQ),
3) les clés maîtresses. Ces clés permettent de générer d’autres clés par dérivation, par
exemple pour le chiffrement ou les signatures numériques.

Comment sont gérées les clés ?

La distribution des clés peut se faire soit manuellement soit automatiquement :

1) dans la distribution manuelle, l'administrateur configure chaque équipement avec sa

clé. Cette technique n'est réalisable que si le réseau est statique et de taille acceptable.
2) dans la distribution automatique, les participants pourront utiliser des clés via DNS en
utilisant un algorithme asymétrique. Ces clés authentifieront les messages de
distribution de clés. Les protocoles les plus utilisés dans cette dernière distribution
sont ISAKMP, OAKLEY et IKE.

5
Chapitre 3 : Sécurité de la couche réseau

II) Le filtrage
Lorsque des données sont envoyées ou reçues d’un ordinateur à un autre via Internet, les
informations entrent et sortent par des portes virtuelles appelées « ports ». Chaque ordinateur
dispose de 65 536 ports. Ces « entrées » sont autant de possibilités pour pénétrer le système
d’information de l’entreprise. Si bien qu’en l’absence de pare-feu (firewall en anglais), des
pirates informatiques ont tout loisir d’infecter ou de détruire les données d’un ordinateur
(virus, vers) ou de récupérer des informations via un cheval de Troie. Un pare-feu joue un rôle
de douanier vis-à-vis des ports : il contrôle les flux de données entrant et sortant de
l’ordinateur ou du réseau de l’entreprise.

Les flux de données circulent par blocs de données appelés « paquets ». Un firewall analyse
chacun de ces paquets sur la base d’un certain nombre de caractéristiques :

 L’adresse IP de l’émetteur du flux

 L’adresse IP du récepteur du flux
 Le type de transport de données ou protocole (IP, UDC, TCP ou ICMP)
 Le service (imprimante partagée par exemple) ou port demandé.

II.1) les types de filtrages

Depuis leur création, les firewalls ont grandement évolué. Ils sont effectivement la première
solution technologique utilisée pour sécuriser les réseaux. De ce fait, il existe maintenant
différentes catégories de firewall. Chacune d'entre-elles disposent d'avantages et
d'inconvénients qui lui sont propre. Le choix du type d'un type de firewall plutôt qu'un autre
dépendra de l'utilisation que l'on souhaite en faire, mais aussi des différentes contraintes
imposées par le réseau devant être protégé.

II.1.2) Filtrage sans état : stateless

Ce sont les firewalls les plus anciens mais surtout les plus basiques qui existent. Ils font un
contrôle de chaque paquets indépendamment des autres en se basant sur les règles prédéfinies
par l'administrateur (généralement appelées ACL, Access Control List). Ces firewalls
interviennent sur les couches réseau et transport. Les règles de filtrages s'appliquent alors par
rapport à une d'adresses IP sources ou destination, mais aussi par rapport à un port source ou
destination.

II.1.2) Filtrage à état : stateful

Les firewalls à états sont une évolution des firewalls sans états. La différence entre ces deux
types de firewall réside dans la manière dont les paquets sont contrôlés. Les firewalls à états
prennent en compte la validité des paquets qui transitent par rapport aux paquets
précédemment reçus. Ils gardent alors en mémoire les différents attributs de chaque
connexion, de leur commencement jusqu'à leur fin, c'est le mécanisme de stateful inspection.

6
Chapitre 3 : Sécurité de la couche réseau

De ce fait, ils seront capables de traiter les paquets non plus uniquement suivant les règles
définies par l'administrateur, mais également par rapport à l'état de la session :

 NEW : Un client envoie sa première requête.

 ESTABLISHED : Connexion déjà initiée. Elle suit une connexion NEW.
 RELATED : Peut être une nouvelle connexion, mais elle présente un rapport direct
avec une connexion déjà connue.
 INVALID : Correspond à un paquet qui n'est pas valide.

Les attributs gardés en mémoires sont les adresses IP, numéros de port et numéros de
séquence des paquets qui ont traversé le firewall. Les firewalls à états sont alors capables de
déceler une anomalie protocolaire de TCP. De plus, les connexions actives sont sauvegardées
dans une table des états de connexions. L'application des règles est alors possible sans lire les
ACL à chaque fois, car l'ensemble des paquets appartenant à une connexion active seront
acceptés.

Un autre avantage de ce type de firewall, se trouve au niveau de la protection contre certaines

attaques DoS comme par exemple le Syn Flood. Cette attaque très courante consiste à
envoyer en masse des paquets de demande de connexion (SYN) sans en attendre la réponse
(c'est ce que l'on appel flood). Ceci provoque la surcharge de la table des connexions des
serveurs ce qui les rend incapable d'accepter de nouvelles connexions. Les firewalls stateful
étant capables de vérifier l'état des sessions, ils sont capables de détecter les tentatives
excessives de demande de connexion. Il est possible, en autre, de ne pas accepter plus d'une
demande de connexion par seconde pour un client donné.

II.1.3) Filtrage applicatif

Les firewalls applicatif (aussi nommé pare-feu de type proxy ou passerelle applicative)
fonctionne sur la couche 7 du modèle OSI. Cela suppose que le firewall connaisse l'ensemble
des protocoles utilisés par chaque application. Chaque protocole dispose d'un module
spécifique à celui-ci. C'est à dire que, par exemple, le protocole HTTP sera filtré par un
processus proxy HTTP. Ce type de firewall permet alors d'effectuer une analyse beaucoup
plus fine des informations qu'ils font transiter. Ils peuvent ainsi rejeter toutes les requêtes non
conformes aux spécifications du protocole.

II.2) Architecture de Pare-feu

Il existe principalement deux catégories de pare-feux :

II.2.a) Les pare-feu personnels

Ce sont des logiciels installés sur des postes informatiques. Ils contrôlent uniquement les flux
entrant et sortant des ordinateurs sur lesquels ils sont installés. Ce type de firewall est
également utilisé par les particuliers. Windows en comporte un par défaut.

II.2.b) Les pare-feu « réseau »

7
Chapitre 3 : Sécurité de la couche réseau

Ils se matérialisent généralement sous forme de boîtier. Ce type de firewall est souvent placé
entre un accès externe et un réseau d’entreprise afin de protéger ce dernier des différentes
menaces d’Internet.

II.2) Règles de filtrage (ACL)

Les ACL (en anglais « Acces Control Lists ») ou en Français « Listes de Contrôle d’Accès »,
vous permettent d’établir des règles de filtrage sur les routeurs, pour régler le trafic des
datagrammes en transit.

Les ACL permettent de mettre en place un filtrage dit « statique » des datagrammes, c'est-à-
dire d’instaurer un certain nombre de règles à appliquer sur les champs concernés des en-têtes
des divers protocoles.

II.3) Fonctionnement des ACL

Quelque soit le type d’ACL dont il s’agit ; leur utilisation se fait toujours selon les mêmes
principes généraux :

 Première étape : On crée une ACL, c'est-à-dire une liste de règles. Chaque règle est
du type (condition, action). Les règles sont interprétées séquentiellement. Si la
condition analysée ne correspond pas, on passe à la règle suivante. Si la condition
correspond, l’action correspondante est effectuée, et le parcours de l’ACL est
interrompu. Par défaut, toutes les ACL considèrent la règle (VRAI, REJET) si aucune
des règles précédentes n’a été prise en compte, c'est-à-dire que tout datagramme non
explicitement accepté par une règle préalable sera rejeté.
 Deuxième étape : On applique une ACL en entrée (in) (respectivement en sortie
(out)), c'est-à-dire que l’on décide d’activer la liste de règles correspondante à tous les
datagrammes « entrant » dans le routeur (respectivement « sortant » du routeur) par
l’interface considérée. En conséquence, sur un routeur, il peut y avoir au maximum 2
ACLs (IP) par interface.

II.4) Types d’ACLs

II.4.1) Les ACLs standards

Les ACL standards n’offrent pas énormément de possibilités, elles permettent simplement de
créer des règles dont les conditions ne prennent en compte que les adresses IP sources des
datagrammes IP analysés. C’est assez contraignant, mais cela permet déjà un certain nombre
de manipulations intéressantes.

Syntaxe

<#ACL> {permit/deny} <@IP source> <masque>

 Le numéro de liste (#ACL) doit être compris entre 1 et 99 ou entre 1300 et 1999 pour
une ACL standard

8
Chapitre 3 : Sécurité de la couche réseau

 « Permit ou deny » indique l’action à prendre (deux seules actions sont possibles :
autorisé ou refusé)
 L’IP source + masque indique la condition

Configuration d’une ACL numérique standard

Configuration d’une ACL nommée standard

II.4.2) Les ACLs étendues

La syntaxe un peu plus complète des ACLs étendues, permet, selon le même principe que
précédemment, de créer des règles de filtrage plus précises, en utilisant des conditions
applicables sur d’autres champs des en-têtes des divers protocoles.

Syntaxe

<#ACL> {permit/deny} <protocole> <@IPsource> <masque> [port] <@IPdest>

<masque> [port] [established]

 Le numéro de liste (#ACL) doit être compris entre 100 et 199 ou 2000 à 2699 pour
une ACL étendue.
 « Permit ou deny » indique l’action à prendre (deux seules actions sont possibles :
autorisé ou refusé)
 « protocole » indique le protocole concerné par le filtre (tapez un ? pour avoir la liste
des protocoles disponibles) Les protocoles indiqués peuvent être de différents niveaux
jusqu’au niveau transport (ex : TCP ou UDP, mais également IP ou ICMP). La
distinction sur les protocoles applicatifs (http, FTP …) se fera sur le champ « port ».
 IP et masques suivent les mêmes règles que pour les ACL standards,
 « port » permet d’indiquer un numéro de port (ou son nom symbolique si il est connu
http, FTP, Telnet, …). Notez qu’un port doit être indiqué précédé d’un opérateur (ex :
« eq http » ou « eq 80 » ou « lt 1024 ») avec « eq » (pour « equal »), « lt » (pour «
lower than ») ou « gt » (pour greater than), …

9
Chapitre 3 : Sécurité de la couche réseau

 « established » indique qu’il s’agit d’une communication TCP déjà établie (et donc
pas d’une demande de connexion avec le bit « syn » positionné).

Exemple de règles

10
Chapitre 3 : Sécurité de la couche réseau

11