Pare‑feu : règles de base pour stopper le bruit

On a tous vécu ce moment un peu idiot.

Tu montes un petit serveur Linux en VM. Ou un Windows Server pour un TP AD. Tu ouvres deux trois ports « juste le temps ». Et le lendemain, tu vois les logs SSH qui défilent comme un slot machine. Tentatives de connexion depuis des IP du monde entier. Pareil sur RDP. Pareil sur des applis web.

Ce n’est pas forcément une attaque ciblée. C’est du bruit. Le bruit d’internet.

Et un pare-feu, au fond, c’est d’abord ça : une barrière simple, claire, qui coupe le bruit. Pour que ce qui doit parler puisse parler. Et que le reste se taise.

Dans cet article, je te donne des règles de base. Pas une usine à gaz. Des réflexes. Des trucs que tu peux appliquer en TP, en stage, en petit homelab. Et aussi en prod, évidemment.

Objectif : réduire la surface d’attaque, limiter les erreurs humaines, et garder des règles lisibles.

Le pare-feu, ce n’est pas « ouvrir ou fermer des ports »

Oui, il y a ça. Mais si tu t’arrêtes à « je bloque tout sauf 80 et 443 », tu passes à côté de l’essentiel.

Un pare-feu sert à :

• filtrer selon des flux (source, destination, service, interface, zone)
• journaliser (et donc rendre visible ce qui se passe)
• segmenter (LAN, DMZ, admin, invités, serveurs, etc.)
• imposer un modèle : ce qui est autorisé est explicite, le reste est refusé

Et surtout, il sert à rester cohérent quand tout change autour. Parce que ça change tout le temps : IP, VM, conteneurs, VLAN, sites distants, cloud.

Règle 1 : définir une politique par défaut claire (et l’écrire)

Le premier truc à décider, c’est la politique par défaut.

• Entrant : par défaut, on refuse. Presque toujours.
• Sortant : ça dépend. En entreprise, on tend vers le contrôle. En lab, souvent on autorise, puis on resserre.

Ce qui compte, c’est que ce soit explicite.

Exemple simple :

• WAN vers LAN : refus
• LAN vers WAN : autorisé (au début)
• LAN vers pare-feu (admin) : autorisé uniquement depuis un réseau d’admin

Et tu notes ça quelque part. Dans la doc, dans le wiki, dans le ticket, dans le README du projet. Si tu es en BTS SIO SISR, c’est typiquement le genre de point qui fait la différence dans un dossier E4 ou E5 : on voit une démarche, pas juste des captures.

Petite parenthèse : sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), tu peux justement centraliser ce genre de notes de lab, et te construire une base de révision. Ce n’est pas glamour, mais c’est efficace.

Règle 2 : travailler avec des zones, pas des adresses IP au hasard

Une erreur fréquente, c’est de faire des règles « IP vers IP » sans logique réseau.

Ce qui marche mieux :

• définir des zones (WAN, LAN, DMZ, ADMIN, SERVEURS, IOT, VPN)
• puis autoriser les flux entre zones (et seulement ceux nécessaires)

Exemple :

• ADMIN vers SERVEURS : SSH, RDP, WinRM, HTTPS (outils)
• LAN vers SERVEURS : uniquement ce qui est consommé (HTTP, SMB parfois, impression, etc.)
• WAN vers DMZ : HTTP/HTTPS vers reverse proxy, éventuellement mail
• WAN vers LAN : rien

Même si ton équipement ne parle pas « zones » au sens strict, tu peux émuler ça avec des interfaces, des VLAN, des groupes d’adresses.

Règle 3 : autoriser le minimum vital, et le nommer correctement

Ça paraît évident. En vrai, ça dérape vite.

Une règle propre, c’est une règle :

• spécifique (service précis)
• limitée (sources précises)
• temporaire si besoin (avec une date, ou au moins un commentaire)
• nommée pour être retrouvée

Exemples de noms lisibles :

• ADMIN_vers_ESXI_HTTPS
• LAN_vers_DNS_interne
• WAN_vers_RP_HTTPS
• VPN_users_vers_RDS_TCP3389

Exemples de noms… pas terribles :

• test
• rule 12
• allow all
• temp

Oui, on l’a tous fait. Mais le jour où tu reviens 3 mois après, tu ne sais plus.

Règle 4 : éviter « any any » sauf si tu sais exactement pourquoi

La règle « any source vers any destination en any service » est souvent la première posée. Par facilité. Et ensuite, elle reste.

Le problème n’est pas que ce soit « dangereux » dans l’absolu. Le problème, c’est que ça rend tout le reste inutile.

Si tu dois faire une exception large, fais-le au moins comme ça :

• limite au maximum (une interface, une zone, un groupe)
• mets un commentaire : pourquoi, qui l’a demandé, pour combien de temps
• journalise la règle (au moins au début)
• crée un ticket ou une tâche de suppression

Astuce simple : planifie un nettoyage mensuel. Même 20 minutes. Tu vires ce qui n’a plus de sens.

Règle 5 : penser aux flux sortants (oui, aussi)

En cours, on insiste beaucoup sur l’entrant. Normal. Mais les flux sortants comptent énormément.

Pourquoi ?

• une machine compromise va parler vers l’extérieur
• des malwares utilisent DNS/HTTPS pour exfiltrer
• des scripts peuvent télécharger n’importe quoi
• un poste utilisateur n’a pas besoin de parler en SMB vers internet (évidemment), ni d’initier du SSH vers des pays entiers

Tu n’es pas obligé de bloquer tout le sortant tout de suite. Mais tu peux déjà :

• forcer les DNS vers tes résolveurs (bloquer DNS direct vers internet)
• limiter SMTP sortant (sinon spam assuré si compromis)
• contrôler RDP sortant (rarement nécessaire)
• faire sortir le web via un proxy, ou au moins journaliser

Règle 6 : journaliser intelligemment (sinon tu te noies)

Le piège, c’est le log en mode mitrailleuse.

Tu actives le logging partout, tu te dis « super ». Et tu te retrouves avec 2 millions d’événements dont 95 pour cent sont du scan banal.

Approche plus utile :

• journaliser les refus importants (ex : WAN vers services sensibles)
• journaliser les autorisations critiques (ex : ADMIN vers hyperviseur)
• journaliser temporairement une règle nouvellement créée, pour vérifier le comportement
• envoyer les logs vers un syslog ou un SIEM (même simple : Graylog, Wazuh, ELK)

En lab BTS, un petit combo pfSense + syslog-ng sur une VM, ça fait déjà un mini environnement de supervision. Et c’est valorisable.

Il est également crucial de considérer les devis descriptifs lors de la mise en place de ces stratégies.

Règle 7 : l’ordre des règles, c’est la moitié du boulot

Sur beaucoup de pare-feu, ça matche de haut en bas.

Donc :

• mets les règles les plus spécifiques en haut
• garde les règles « temporaires » dans une section dédiée
• finis par un refus explicite, journalisé si nécessaire
• évite les doublons

Une structure simple qui marche bien :

1. règles d’admin
2. règles serveurs
3. règles utilisateurs
4. règles VPN
5. règles temporaires
6. refus final

Et oui, tu peux commenter. Il faut commenter. Un pare-feu sans commentaire, c’est une énigme.

Règle 8 : séparer administration et production

Celle-là est souvent négligée en petit réseau. Pourtant c’est une des meilleures protections « pas chères ».

Idée : tu n’administres pas tes serveurs depuis le même réseau que les postes utilisateurs.

Concrètement :

• un VLAN ADMIN
• des postes d’admin dédiés (ou une jump box)
• des règles strictes : ADMIN vers SERVEURS, pas l’inverse
• MFA sur le VPN si accès distant

Résultat : si un poste utilisateur se fait compromettre, l’attaquant ne rebondit pas facilement vers ton infra.

Règle 9 : faire simple, puis durcir

Les pare-feu compliqués meurent mal. Ils deviennent intouchables. Personne n’ose modifier.

Donc tu fais simple :

• segmentation de base
• quelques règles essentielles
• logging minimal utile
• documentation courte

Puis tu durcis :

• filtrage sortant
• listes d’IP ou pays si besoin
• IDS/IPS (Suricata, Snort)
• inspection TLS si contexte entreprise (et si tu sais ce que tu fais)
• intégration annuaire, objets dynamiques, automatisation

C’est une progression. Pas un big bang.

Règle 10 : tester, valider, et garder une porte de secours

Avant d’appliquer une règle :

• tu sais ce que tu changes
• tu sais comment revenir en arrière
• tu testes depuis un poste représentatif
• tu évites de faire ça à distance sans plan B (classique : tu te coupes toi-même)

Bon réflexe :

• sauvegarde de config
• accès console (iLO, iDRAC, IPMI, Proxmox console, etc.)
• fenêtre de maintenance
• et si possible un collègue en visio prêt à confirmer que « oui ça marche encore »

En lab, c’est pareil. Quand tu montes un routeur Linux avec nftables, garde une session root ouverte tant que tu n’as pas validé.

Deux mini exemples concrets (niveau TP, mais réalistes)

Exemple 1 : serveur web en DMZ avec reverse proxy

Objectif : exposer uniquement HTTPS vers un reverse proxy, et laisser le proxy parler vers le serveur applicatif.

• WAN vers DMZ : autoriser TCP 443 vers reverse-proxy
• WAN vers DMZ : refuser le reste
• DMZ vers SERVEURS : autoriser TCP 8080 (ou 80) vers app1 uniquement
• ADMIN vers DMZ : autoriser SSH uniquement depuis VLAN_ADMIN
• DMZ vers WAN : autoriser DNS vers résolveur, NTP, mises à jour (et encore, au besoin)

Ça limite énormément le bruit. Et ça limite les dégâts si le proxy est compromis.

Exemple 2 : accès RDP aux serveurs uniquement via VPN

Objectif : ne jamais exposer 3389 sur internet.

• WAN vers LAN : refuser RDP
• VPN_users vers SERVEURS : autoriser TCP 3389 vers un groupe serveurs_rds
• VPN_users vers LAN : refuser le reste (ou limiter)
• ADMIN vers SERVEURS : autoriser RDP, WinRM, etc.

Tu peux ajouter une jump box, et ne permettre RDP que vers elle. Encore mieux.

Les erreurs qu’on voit tout le temps (et que tu peux éviter)

• ouvrir RDP/SSH sur le WAN « juste pour tester »
• laisser des règles temporaires en place pendant des mois
• ne pas documenter les exceptions
• mélanger flux utilisateurs et flux d’admin
• logs partout, puis plus personne ne regarde
• pas de segmentation, donc règles impossibles à maintenir

Rien de tout ça n’est une honte. C’est juste… la vraie vie. L’important c’est de corriger.

Conclusion : stopper le bruit, garder le contrôle

Un pare-feu, ce n’est pas un mur magique. C’est une discipline. Un ensemble de petites décisions cohérentes.

Si tu ne devais retenir que 5 idées :

• politique par défaut : refus en entrant
• segmentation par zones
• règles minimales, nommées, commentées
• contrôle progressif du sortant
• logs utiles, pas bruyants

Si tu veux, tu peux aussi t’appuyer sur les autres labs et ressources de BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) pour compléter avec des TPs concrets : pfSense, nftables, Windows Firewall avancé, Wazuh, segmentation VLAN. L’idée c’est de pratiquer, et de garder des traces propres. Ça sert pour les exams, et plus tard, au boulot.

Et puis voilà. Moins de bruit. Plus de maîtrise. C’est déjà énorme.

Questions fréquemment posées

Pourquoi voit-on souvent des tentatives de connexion sur SSH et RDP après avoir ouvert quelques ports sur un serveur ?

C'est le bruit d'internet : des scanners et bots essaient automatiquement de se connecter à tous les ports ouverts, sans forcément viser une attaque ciblée. Un pare-feu sert justement à couper ce bruit pour ne laisser passer que ce qui est nécessaire.

Quelles sont les fonctions principales d'un pare-feu au-delà de simplement ouvrir ou fermer des ports ?

Un pare-feu sert à filtrer selon des flux (source, destination, service), journaliser les connexions pour rendre visible l'activité, segmenter le réseau en zones distinctes (LAN, DMZ, admin, invités) et imposer un modèle clair où seules les communications explicitement autorisées sont permises.

Quelle est l'importance de définir une politique par défaut claire pour un pare-feu ?

Définir une politique par défaut claire (par exemple refuser tout entrant et autoriser certains sortants) permet de réduire la surface d'attaque, limiter les erreurs humaines et garder des règles lisibles. Cela doit être documenté pour assurer la cohérence et faciliter la maintenance.

Pourquoi est-il recommandé de travailler avec des zones plutôt qu'avec des adresses IP individuelles dans les règles du pare-feu ?

Travailler avec des zones (comme WAN, LAN, DMZ, ADMIN) permet d'avoir une logique réseau claire et évolutive. On autorise uniquement les flux nécessaires entre zones. Cela évite la complexité et l'erreur liée à gérer des règles IP par IP.

Comment appliquer la règle d'autoriser le minimum vital dans la configuration du pare-feu ?

Il faut créer des règles spécifiques aux services précis, limitées aux sources nécessaires et temporaires si besoin. Par exemple, autoriser uniquement HTTP/HTTPS depuis WAN vers DMZ, ou SSH uniquement depuis le réseau ADMIN vers SERVEURS.

Comment un pare-feu aide-t-il à rester cohérent face aux changements fréquents comme IP dynamiques ou déploiement cloud ?

Le pare-feu impose un modèle clair basé sur des politiques explicites et zones logiques plutôt que sur des adresses IP fixes. Cela facilite l'adaptation aux changements fréquents (VM, conteneurs, VLANs) en gardant les règles simples, lisibles et maintenables.