Un pare-feu filtre le trafic réseau en lisant une liste de règles, souvent de haut en bas. Quand un paquet arrive, le pare-feu compare ses caractéristiques (adresse source, port, protocole) à chaque règle dans l’ordre. Dès qu’une correspondance est trouvée, l’action associée s’applique et les règles suivantes sont ignorées.
Dans ce fonctionnement séquentiel, la place de chaque règle change tout. Celle qui pose le plus de questions est la règle de refus par défaut, souvent appelée « deny all » ou « drop all ». Où la positionner pour que le pare-feu protège sans bloquer le trafic légitime ?
A lire en complément : Pourquoi activer la virtualisation ?
Règle de refus par défaut : pourquoi elle existe
Imaginez un vigile à l’entrée d’un immeuble. Il dispose d’une liste de visiteurs autorisés. Si quelqu’un se présente sans figurer sur la liste, le vigile refuse l’accès. La règle de refus par défaut joue ce rôle : elle bloque tout ce qui n’a pas été explicitement autorisé.
Sans cette règle, tout trafic non mentionné dans les règles d’autorisation passerait librement. Un port oublié, un protocole non prévu, une adresse inconnue, tout serait accepté. La surface d’attaque deviendrait difficile à maîtriser.
A lire en complément : Comment mettre la luminosité plus forte ?
C’est pourquoi la plupart des administrateurs réseau travaillent selon le principe du moindre privilège appliqué au trafic réseau. On interdit tout par défaut, puis on ouvre uniquement ce qui est nécessaire au fonctionnement des applications et des services.
Placement en dernière position dans une liste séquentielle
La majorité des pare-feu (iptables, UFW, pfSense, Windows Defender Firewall) évaluent les règles dans l’ordre, de la première à la dernière. Ils s’arrêtent à la première correspondance. Ce mécanisme a une conséquence directe sur le placement de la règle de refus.
La règle de refus par défaut se place en dernière position, après toutes les règles d’autorisation. Pourquoi ? Parce que si vous la placez en premier, elle bloquera tout le trafic avant même que les autorisations ne soient lues. Aucun paquet ne passera, y compris ceux que vous souhaitez accepter.
Prenons un exemple concret. Vous configurez un serveur web qui doit accepter le trafic HTTPS sur le port 443 et le trafic DNS sur le port 53. Votre ensemble de règles ressemble à ceci :
- Autoriser le trafic entrant sur le port 443 (HTTPS) depuis toute source
- Autoriser le trafic entrant sur le port 53 (DNS) depuis le réseau interne
- Refuser tout le reste du trafic entrant (deny all)
Un paquet HTTPS arrive : il correspond à la première règle et passe. Un paquet sur le port 22 (SSH) arrive : il ne correspond ni à la règle 1, ni à la règle 2. Il atteint la dernière ligne et se fait bloquer. Le système fonctionne.
Inversez l’ordre en plaçant le refus en tête, et plus rien ne fonctionne. Même le trafic HTTPS légitime est rejeté dès la première ligne.
Politique par défaut ou règle explicite : deux approches de configuration
Tous les pare-feu ne gèrent pas le refus par défaut de la même façon. Certains proposent une politique par défaut configurable séparément des règles. C’est le cas d’UFW sous Linux, par exemple, où la commande ufw default deny incoming définit le comportement pour tout paquet ne correspondant à aucune règle listée.
Dans ce cas, vous n’avez pas besoin d’écrire une règle « deny all » visible dans la liste. Le pare-feu applique automatiquement le refus après avoir parcouru toutes les règles sans trouver de correspondance. Le résultat est identique : le refus intervient en dernier.
D’autres systèmes exigent une règle explicite en fin de liste. C’est souvent le cas sur les pare-feu matériels ou les configurations manuelles avec iptables. Les deux méthodes aboutissent au même résultat, mais la politique par défaut réduit le risque d’oublier la règle de fermeture.
Quand la position visuelle ne suffit pas
Certaines architectures réseau modernes n’utilisent pas une simple liste séquentielle. Les systèmes à niveaux de priorité, comme le Network Policy API dans Kubernetes, évaluent les règles selon leur niveau hiérarchique (administrateur, politique réseau, niveau de base) puis selon une priorité numérique, avant de considérer l’ordre interne.
Dans ces environnements, la priorité de la règle compte davantage que sa position dans la liste. Une règle de refus globale peut être définie au niveau administrateur avec la priorité la plus basse, tandis que les exceptions sont traitées dans des niveaux appropriés. Le principe reste le même : les autorisations sont évaluées avant le refus.
Erreurs fréquentes lors du placement des règles de pare-feu
Vous avez compris le principe général. Voyons maintenant les pièges concrets qui provoquent des blocages ou des failles.
Le premier piège est une règle d’autorisation trop large placée avant des restrictions. Si vous autorisez tout le trafic depuis une plage d’adresses IP entière en début de liste, les règles de blocage spécifiques qui suivent ne seront jamais atteintes. Le pare-feu s’arrête à la première correspondance.
Le deuxième piège est l’inverse : placer des règles trop spécifiques après des règles générales. Une règle autorisant le port 443 pour une seule adresse IP n’a aucun effet si une règle précédente autorise déjà tout le trafic sur le port 443.
Voici les points de vérification à suivre lors de l’ordonnancement :
- Les règles les plus spécifiques (adresse IP précise, port unique) doivent précéder les règles plus larges (plage d’adresses, tous les ports)
- Les règles de blocage explicites prennent le dessus sur les autorisations en cas de conflit, sur la plupart des systèmes (c’est le cas documenté par Microsoft pour Windows Firewall)
- La règle de refus par défaut reste toujours la dernière évaluée, qu’elle soit écrite explicitement ou définie comme politique
- Après chaque modification, tester avec du trafic réel ou simulé pour vérifier que les autorisations fonctionnent et que le reste est bien bloqué
Trafic sortant : la même logique s’applique
La question du placement concerne aussi les règles de sortie. Les organisations autorisent souvent le trafic sortant par défaut, puis bloquent certains protocoles spécifiques. Dans ce cas, la politique par défaut est « allow » en sortie, et les règles de blocage sont placées avant.
Si vous choisissez une approche plus restrictive avec un refus par défaut en sortie aussi, le même principe s’applique : les autorisations de sortie (HTTPS, DNS, mises à jour système) sont listées en premier, et le refus global ferme le reste.
Le placement de la règle de refus par défaut n’est pas un détail de configuration. C’est le socle de toute stratégie de filtrage réseau. En dernier dans une liste séquentielle, en politique globale sur les systèmes qui le permettent, ou au niveau de priorité le plus bas dans les architectures hiérarchiques, le refus par défaut doit toujours être la dernière décision que le pare-feu prend, après avoir vérifié chaque autorisation explicite.
