Pare-feu, WAF, proxy, IDS/IPS, VPN : les défenses de bordure

Une entrée n'a jamais un seul contrôle

À l'entrée du centre commercial Les Arcades, personne ne se contente d'un seul dispositif. Il y a les portiques qui comptent les flux et bloquent les véhicules non autorisés sur le parking. Il y a un vigile qui vérifie d'un coup d'œil qui entre. Devant la bijouterie, un agent fouille les sacs en détail. Au comptoir d'accueil, on relaie les demandes des visiteurs et on note qui a demandé quoi. Des caméras filment partout, et un fourgon blindé transporte les recettes vers la banque sur un trajet sécurisé.

Chaque dispositif a un rôle précis, agit à un endroit précis, et a ses angles morts. Le vigile à l'entrée ne sait pas ce qu'il y a dans un sac fermé. La caméra voit un vol mais n'arrête personne. Aucun n'est suffisant seul, et c'est justement leur empilement qui tient.

Les défenses de bordure d'un système d'information fonctionnent exactement comme ça. Pare-feu, WAF, proxy, IDS/IPS et VPN contrôlent ce qui entre et ce qui sort, mais chacun travaille à une couche différente, avec un objectif différent. Confondre leurs rôles, c'est croire qu'on est protégé là où on ne l'est pas.

Une défense de bordure ne se choisit pas, elle se compose. La bonne question n'est pas « lequel installer ? » mais « à quelle couche chacun agit-il, et que laisse-t-il passer ? ».

Filtrer à la bordure : un travail réparti sur plusieurs couches

La bordure, c'est la frontière entre un réseau de confiance (le SI interne) et un réseau hostile par défaut (Internet). Tout ce qui franchit cette frontière mérite un contrôle. Le point clé, c'est que ce contrôle ne se fait pas à un seul niveau.

Un paquet réseau se lit par couches, comme le décrit le modèle OSI. Une adresse IP et un port vivent en bas de la pile (couches 3 et 4). Une requête HTTP, son URL, ses en-têtes et son corps vivent tout en haut (couche 7). Un outil de bordure ne peut décider que sur ce qu'il sait lire. Un pare-feu réseau classique voit des IP et des ports, pas le contenu d'une requête web. Un WAF lit la requête HTTP entière, mais ne s'occupe pas du routage bas niveau.

C'est exactement la logique de défense en profondeur : on superpose des contrôles indépendants pour que la chute d'un seul ne donne pas accès au reste. Cette idée structure toute la chaîne de bordure, et reste le fil conducteur de cet article.

Voici la cartographie des cinq dispositifs avant d'entrer dans le détail de chacun.

Le pare-feu : qui a le droit d'entrer

Aux Arcades, les portiques et le vigile à l'entrée tranchent une question simple : tu passes, ou tu ne passes pas. Ils ne lisent pas le contenu de ton sac, ils décident sur des critères visibles immédiatement, ta plaque sur le parking, ta présence sur une liste, l'horaire d'ouverture.

Le pare-feu réseau fait pareil aux couches 3 et 4. Il applique une politique de filtrage à partir d'éléments lisibles tôt dans le paquet : adresse IP source et destination, port, protocole, et parfois l'état de la connexion. Une règle typique autorise le trafic entrant vers le port 443 d'un serveur web et bloque tout le reste.

Le document de référence sur le sujet, le NIST SP 800-41 Rev. 1, distingue plusieurs familles. Le filtrage de paquets sans état décide règle par paquet. Le pare-feu à état (stateful) suit les connexions et autorise le trafic retour d'une session qu'il a vue s'ouvrir. Les pare-feu applicatifs poussent plus loin l'inspection.

La règle d'or de la configuration tient en une ligne : deny by default. On bloque tout, puis on n'ouvre que ce qui est explicitement nécessaire. C'est exactement la politique inter-VLAN d'un réseau bien segmenté, tout est interdit sauf les flux décrits un par un.

Un pare-feu décide qui parle à qui, jamais ce qui est dit. Il laissera passer une attaque applicative parfaitement valide sur le plan réseau, parce que cette attaque arrive sur un port légitimement ouvert.

C'est là sa limite structurelle. Un pare-feu qui autorise le port 443 vers un serveur web laissera entrer une injection SQL aussi facilement qu'une requête saine. Les deux sont, pour lui, du trafic HTTPS valide vers une destination autorisée. Il faut un autre outil pour regarder le contenu.

Le WAF : fouiller le contenu de la requête

Devant la bijouterie des Arcades, on ne se contente plus de regarder qui entre. Un agent ouvre les sacs et inspecte ce qu'ils contiennent, parce que la zone est sensible et que le risque ne se voit pas de l'extérieur.

Le WAF (Web Application Firewall) joue ce rôle pour les applications web. Il opère à la couche 7 et lit la requête HTTP dans son entier : la méthode, l'URL, les paramètres, les en-têtes, les cookies, le corps. Il cherche les motifs d'attaque qui ciblent l'applicatif, ceux que le pare-feu réseau ne peut pas voir.

L'OWASP décrit le WAF comme un contrôle qui filtre, surveille et bloque le trafic HTTP vers et depuis une application web. Concrètement, il s'attaque aux familles d'attaques du Top 10 OWASP : injection, scripting inter-site (XSS), et autres manipulations de la requête. Le projet open source OWASP Coraza et le Core Rule Set en fournissent une implémentation de référence.

Deux approches de filtrage coexistent :

• Liste de blocage (blocklist) : on connaît des signatures d'attaque et on les rejette. Simple à déployer, mais aveugle aux variantes inédites.
• Liste d'autorisation (allowlist) : on définit ce qui est un trafic légitime et on rejette tout le reste. Plus robuste, mais coûteux à modéliser pour une application complexe.

Un WAF n'est pas un substitut au code sécurisé. L'OWASP est clair sur ce point : c'est une mesure de défense en profondeur, pas une excuse pour ne pas valider les entrées dans l'application elle-même. Un WAF mal réglé génère des faux positifs qui bloquent des utilisateurs légitimes, ou des faux négatifs qui laissent passer une charge habilement encodée.

Le pare-feu réseau et le WAF ne sont pas redondants. L'un protège le réseau, l'autre protège l'application. Retirer le second sous prétexte d'avoir le premier laisse grande ouverte toute la couche 7.

Le proxy et le reverse proxy : le comptoir qui relaie

Au comptoir d'accueil des Arcades, on ne contrôle pas l'accès, on l'organise. Un visiteur demande un magasin, l'accueil oriente, note la demande dans un registre, et sert d'intermédiaire pour ne jamais exposer directement les coulisses. Personne ne parle directement à la réserve, tout passe par le comptoir.

Un proxy est cet intermédiaire pour le trafic réseau. Le proxy sortant (forward proxy) se place devant les clients internes : les postes du SI passent par lui pour accéder à Internet, ce qui permet de journaliser, de filtrer les destinations et de mutualiser le cache.

Le reverse proxy fait l'inverse. Il se place devant les serveurs et reçoit le trafic des clients externes à leur place. Les visiteurs ne parlent qu'au reverse proxy, jamais directement aux serveurs applicatifs, qui restent invisibles depuis l'extérieur. Des solutions comme Nginx ou HAProxy remplissent ce rôle au quotidien.

Le reverse proxy concentre plusieurs fonctions utiles à la bordure :

La terminaison TLS mérite une note. En déchiffrant le trafic au reverse proxy, on rend le contenu lisible pour les contrôles applicatifs en aval. C'est précisément ce qui permet à un WAF de fonctionner : beaucoup de WAF s'intègrent dans le reverse proxy ou juste derrière, là où la requête est enfin en clair. Le proxy et le WAF sont souvent le même point de passage physique avec deux casquettes.

IDS et IPS : voir l'attaque ou l'arrêter

Les Arcades ont des caméras et des vigiles, et la différence entre les deux est exactement celle qui sépare l'IDS de l'IPS.

Une caméra détecte. Elle filme un comportement suspect, déclenche une alerte au PC sécurité, mais n'empêche rien par elle-même. Un vigile intercepte. Il est sur le trajet, il peut bloquer physiquement la personne avant qu'elle n'atteigne la sortie.

Un IDS (Intrusion Detection System) est la caméra. Il observe le trafic, généralement en copie (sur un port miroir), compare ce qu'il voit à des signatures d'attaque ou à un comportement de référence, et lève une alerte. Il ne ralentit pas le trafic puisqu'il n'est pas sur le chemin, mais il ne bloque rien non plus. Sa valeur, c'est la visibilité et l'alimentation du SOC.

Un IPS (Intrusion Prevention System) est le vigile. Il est placé en coupure (inline), directement sur le chemin du trafic. Quand il reconnaît une attaque, il peut la rejeter avant qu'elle n'atteigne sa cible. En contrepartie, il devient un point sur le chemin critique : un faux positif bloque du trafic légitime, et l'équipement doit suivre le débit sans devenir un goulot d'étranglement.

Beaucoup de produits modernes assurent les deux rôles selon la configuration. Les moteurs open source Suricata et Snort en sont les exemples connus : le même outil fonctionne en IDS passif ou en IPS bloquant selon où on le branche.

IDS et IPS répondent à deux questions différentes. L'IDS demande « qu'est-ce qui se passe ? », l'IPS demande « est-ce que je laisse passer ? ». On a souvent besoin des deux, le premier pour comprendre, le second pour arrêter.

Le VPN : un trajet sécurisé hors des murs

Le fourgon blindé qui transporte les recettes des Arcades ne change pas la nature de la route. Il roule sur les mêmes voies publiques que tout le monde. Ce qu'il garantit, c'est que sur ce trajet exposé, le contenu reste confidentiel et arrive intact.

Le VPN (Virtual Private Network) fait exactement cela pour les données. Il établit un tunnel chiffré à travers un réseau non fiable, typiquement Internet, de sorte que ce qui circule reste confidentiel et protégé contre la modification, même sur une infrastructure que l'on ne contrôle pas.

Deux usages dominent :

• Accès distant : un collaborateur en télétravail établit un tunnel vers le SI de l'entreprise. Son poste se comporte comme s'il était sur le réseau interne, mais le trafic transite chiffré sur Internet. C'est l'équivalent d'un convoyeur qui rapporte des fonds vers le coffre central depuis l'extérieur.
• Site-à-site : deux réseaux distants (deux agences, un SI et un prestataire récurrent) sont reliés en permanence par un tunnel. Pour les utilisateurs, les deux sites n'en forment qu'un.

Techniquement, IPsec reste le standard historique pour le site-à-site, et WireGuard s'est imposé comme une option moderne, plus simple et plus légère, pour l'accès distant.

Le VPN protège les données en transit. Il ne dit rien de la légitimité de ce qui circule dans le tunnel. Un poste compromis qui se connecte en VPN apporte sa compromission directement dans le réseau interne, par un canal chiffré et donc opaque aux inspections de bordure. C'est la raison pour laquelle l'approche Zero Trust ne considère jamais un tunnel VPN comme une preuve de confiance suffisante.

Pourquoi on les empile : le cas Capital One

L'empilement n'est pas un excès de prudence, c'est une nécessité démontrée par les incidents. Celui de Capital One, en 2019, l'illustre précisément parce qu'un dispositif de bordure y était présent et a quand même été contourné.

D'après l'acte d'accusation du département de la Justice américain et la plainte d'origine, l'attaquante a exploité une requête côté serveur pour atteindre le service de métadonnées de l'environnement cloud. Ce type de faille, une SSRF (Server-Side Request Forgery), pousse une application à émettre une requête vers une ressource interne à laquelle l'attaquant n'a normalement pas accès.

L'application a ainsi été détournée pour interroger le service de métadonnées de l'instance et récupérer des identifiants temporaires. Ces identifiants ont ensuite servi à lister puis extraire des données stockées. La fuite a touché les informations d'un très grand nombre de clients et de demandeurs de crédit.

Le point instructif pour notre sujet : un pare-feu applicatif faisait partie du décor, et il n'a pas suffi. La requête malveillante était, dans sa forme, une requête que l'application avait le droit d'émettre. Le contrôle de bordure regardait au mauvais endroit pour ce type d'abus.

Plusieurs couches auraient pu rompre la chaîne à des points différents : une validation applicative stricte des requêtes sortantes, un durcissement de l'accès au service de métadonnées, un moindre privilège sur les identifiants obtenus, une détection du comportement anormal d'extraction massive. Aucune n'est le pare-feu de bordure, et c'est tout le propos.

Capital One ne montre pas qu'un pare-feu applicatif est inutile. Il montre qu'aucune défense de bordure ne couvre tous les angles, et que la sécurité tient à la profondeur des couches, pas à la qualité d'un seul rempart.

Composer une bordure cohérente

Mis bout à bout, ces dispositifs dessinent une architecture de bordure lisible. Le trafic entrant traverse d'abord le pare-feu réseau, puis le reverse proxy qui termine le TLS et passe la requête au WAF, avant d'atteindre le serveur applicatif. En parallèle, un IDS observe une copie du trafic pour alimenter la détection, et le VPN ouvre un chemin chiffré séparé pour les accès distants.

Le tableau suivant récapitule chaque outil par couche, rôle et limite. C'est cette grille qui aide à décider, face à un besoin, lequel ajouter et ce qu'il ne couvrira pas.

Aucune ligne de ce tableau ne couvre la colonne « limite » d'une autre. C'est la définition même de la défense en profondeur appliquée à la bordure, et c'est aussi pourquoi ces contrôles ont leur place dans une démarche DevSecOps, où la sécurité s'intègre tôt et à chaque couche plutôt qu'en rempart unique au dernier moment.

Points clés

• La bordure se contrôle à plusieurs couches : pare-feu en bas (IP, port), WAF en haut (requête web), et chacun ne voit que ce qu'il sait lire.
• Un pare-feu décide qui parle à qui, un WAF décide ce qui est dit. Ils se complètent et ne se remplacent pas.
• Le reverse proxy relaie, journalise et termine le TLS, ce qui rend le trafic lisible pour l'inspection applicative en aval.
• IDS et IPS répondent à deux questions : détecter et alerter (en écoute) ou détecter et bloquer (en coupure).
• Le VPN protège les données en transit, pas leur légitimité : un client compromis apporte sa compromission dans le tunnel.
• Capital One (2019) rappelle qu'aucune défense de bordure n'est infaillible. La sécurité tient à la profondeur des couches.

Dans la série

Palier 2 : Verrouiller les accès. Domaine : Réseau & systèmes.

• Précédent : Le modèle OSI côté sécurité
• Suivant : Chiffrement symétrique, asymétrique et hachage
• Vue d'ensemble : Par où commencer dans Les Arcades

Pour aller plus loin

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• OWASP, Web Application Firewall et le Top 10 OWASP
• OWASP Coraza et le Core Rule Set
• Suricata et Snort pour l'IDS/IPS
• Acte d'accusation Capital One, département de la Justice américain
• Qu'est-ce que le DevSecOps ?