Pare-feu vs ACL : quelle différence ?

Quand j’ai commencé la sécurité réseau, j’avais un doute : une ACL et un pare-feu, ça fait la même chose, non ? Les deux laissent passer certains paquets et en bloquent d’autres. Après avoir configuré des ACL sur Cisco Packet Tracer, je vois mieux où se situe la vraie différence.

L’ACL : une liste de règles

Une ACL (Access Control List) est une liste de règles qu’on applique sur une interface d’un routeur ou d’un switch Layer 3. Chaque paquet est comparé aux règles, dans l’ordre. Selon la version de l’ACL, elle peut regarder l’adresse source, l’adresse de destination, le protocole et le port.

Un exemple : autoriser HTTPS vers un serveur, bloquer SSH, laisser passer le reste.

access-list 100 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 443
access-list 100 deny tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 22
access-list 100 permit ip any any

Le point à retenir : le routeur s’arrête à la première règle qui correspond. Si on met permit ip any any en premier, tout passe et les règles suivantes ne servent à rien. C’est l’erreur la plus classique quand on débute, et je l’ai faite aussi.

Le pare-feu : il comprend le contexte

Un pare-feu se place entre plusieurs zones, par exemple Internet, le LAN et la DMZ, et contrôle ce qui circule entre elles.

Sa grande différence avec une ACL classique, c’est qu’il garde en mémoire l’état des connexions (stateful inspection). Quand un PC du LAN ouvre une page web, le pare-feu note cette connexion. La réponse du serveur est alors acceptée automatiquement, parce qu’elle correspond à une session déjà ouverte. En revanche, une connexion qui arrive d’Internet vers le LAN sans que personne l’ait demandée est bloquée.

Une ACL classique ne fait pas ça : elle regarde chaque paquet pour lui-même, sans savoir s’il fait partie d’une conversation déjà en cours. (Cisco propose des mécanismes pour s’en approcher, comme le mot-clé established ou les ACL réflexives, mais ce n’est pas du vrai suivi de session.)

Ce que le pare-feu fait en plus

Selon le modèle, un pare-feu peut aussi gérer le NAT, les VPN, les logs détaillés, la détection d’intrusion (IDS/IPS) ou le filtrage par application. Ce dernier point est intéressant : une ACL voit seulement « TCP 443 », alors qu’un pare-feu de nouvelle génération peut distinguer deux applications qui passent toutes les deux par HTTPS.

Comparaison rapide

	ACL	Pare-feu
Filtrage IP / ports / protocoles	Oui	Oui
Suivi des connexions	Non (ACL classique)	Oui (stateful)
VPN, IDS/IPS, filtrage applicatif	Non	Selon le modèle
Logs	Limités	Détaillés
Mise en place	Simple, sur le routeur	Équipement ou logiciel dédié

Alors, lequel choisir ?

Je trouve que la question est mal posée, parce qu’ils ne servent pas au même niveau.

Dans mon projet de PME sur Packet Tracer, les ACL étaient parfaites pour des règles simples : le VLAN Guest ne peut pas accéder au réseau interne, le VLAN Employés ne peut pas aller sur Finance, et seul le VLAN IT peut se connecter en SSH aux équipements. Pour ça, pas besoin d’un pare-feu complet.

Mais pour protéger un réseau contre Internet, gérer une DMZ ou surveiller le trafic, un vrai pare-feu est bien plus adapté. Dans une entreprise réelle, on utilise donc les deux : le pare-feu en bordure du réseau, et des ACL pour affiner la segmentation entre les VLAN.

Un détail sur le SSH

Pour limiter l’accès SSH à un seul VLAN, on crée une ACL et on l’applique sur les lignes VTY avec access-class (et non access-group, qui sert aux interfaces) :

ip access-list standard SSH_JUSTE_IT
 permit 192.168.40.0 0.0.0.255
 deny any

line vty 0 4
 access-class SSH_JUSTE_IT in

Ce que je retiens

Une ACL dit : « ce trafic passe, celui-là non ». Un pare-feu fait pareil, mais il comprend aussi la session en cours et ajoute des fonctions de protection. Les deux se complètent, et c’est en pratiquant les ACL que j’ai compris pourquoi on a besoin des deux.