Découvrir le pare-feu : filtrer les connexions entrantes et sortantes sur un serveur Linux

Un serveur qui héberge un site public et une interface d'administration ne devrait pas répondre à tout le monde sur tous ses ports. Comment décider qui entre, et qui sort ?

Petite vérification

Avant de commencer, vérifiez si vous savez encore répondre à ces 3 questions très simples, sur la séance précédente consacrée au smartphone personnel utilisé pour le travail :

1. sous quel délai, en principe, le responsable d'un traitement doit-il notifier une violation de données à la CNIL, lorsqu'elle est susceptible d'engendrer un risque pour les personnes ?
2. un employeur peut-il consulter les photos privées du téléphone personnel d'un salarié ?
3. quel est le nom du droit qui protège le salarié des sollicitations professionnelles en dehors de son temps de travail ?

📌 Réponse attendue

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

---

TP pour réfléchir et résoudre des problèmes

Votre défi pour aujourd'hui consiste à bloquer l'accès à une interface d'administration sans toucher au service qui la fournit, puis à passer d'un pare-feu qui interdit ce qui est connu à un pare-feu qui n'autorise que ce qui est utile

info

L'association « Les Jardins Partagés » et son serveur sont fictifs, construits pour l'exercice. Pour que vous puissiez tout faire seul(e) sur une seule VM, les « clients » se connectent depuis la machine elle-même, par la boucle locale (127.0.0.1).

attention

Vous modifiez ici le pare-feu de votre propre VM, jamais celui d'un serveur partagé. La dernière étape vous demande de laisser passer le port 22 (SSH) : si vous êtes connecté(e) à votre VM par SSH, ne l'oubliez jamais, sous peine de vous couper l'accès.

L'association « Les Jardins Partagés » héberge sur un petit serveur Linux deux services web : le site public de l'association (port 8080) et une interface d'administration (port 8081), qui ne doit servir qu'aux bénévoles. Un bénévole vous demande : « Comment faire pour que personne d'autre ne puisse atteindre l'administration ? »

Étape 1 — Lancer les deux services

Dans le terminal de votre VM Debian, installez les outils et créez un dossier de travail :

sudo apt install nftables curl
mkdir -p ~/tp-parefeu/site ~/tp-parefeu/admin
cd ~/tp-parefeu
echo "Site public des Jardins Partages" > site/index.html
echo "Interface d'administration" > admin/index.html

Lancez les deux services (deux petits serveurs web fournis par Python), puis listez les ports en écoute :

python3 -m http.server 8080 --bind 127.0.0.1 --directory site &
python3 -m http.server 8081 --bind 127.0.0.1 --directory admin &
ss -tln

1. Quels ports voyez-vous en écoute, et sur quelle adresse ?
2. Interrogez chaque service avec curl -s http://127.0.0.1:8080/ puis curl -s http://127.0.0.1:8081/. Que répondent-ils ?

📌 Réponse attendue

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

Étape 2 — Constater l'absence de filtrage

Regardez ce que votre pare-feu contient pour le moment :

sudo nft list tables
curl -s --max-time 3 http://127.0.0.1:8081/ ; echo "code retour : $?"

1. Que contient la liste des tables ?
2. Que vous répond l'interface d'administration, et quel est le code retour de curl ?
3. Que peut-on en conclure sur la protection de cette interface ?

📌 Réponse attendue

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

Étape 3 — Un premier filtre sur les connexions entrantes

Créez une table, une chaîne qui examine les paquets entrants, puis une règle qui jette les paquets destinés au port 8081 :

sudo nft add table inet filtre_tp
sudo nft add chain inet filtre_tp entrant '{ type filter hook input priority 0 ; policy accept ; }'
sudo nft add rule inet filtre_tp entrant tcp dport 8081 drop
sudo nft list ruleset

Testez les deux services, puis vérifiez que les services tournent toujours :

curl -s --max-time 3 http://127.0.0.1:8080/ ; echo "code retour : $?"
curl -s --max-time 3 http://127.0.0.1:8081/ ; echo "code retour : $?"
ss -tln

1. Que fait la politique policy accept de la chaîne ?
2. Que répondent les deux services, et quels sont les codes retour ?
3. Le service d'administration est-il arrêté ? Qu'est-ce qui a changé exactement ?

📌 Réponse attendue

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

Étape 4 — Jeter ou refuser

Remplacez la règle par une règle qui refuse explicitement la connexion plutôt que de l'ignorer :

sudo nft flush chain inet filtre_tp entrant
sudo nft add rule inet filtre_tp entrant tcp dport 8081 reject
curl -sS --max-time 3 http://127.0.0.1:8081/ ; echo "code retour : $?"

1. Quelle différence de comportement observez-vous par rapport à l'étape précédente (message, durée, code retour) ?
2. Quel est l'avantage de drop face à un attaquant qui scanne les ports du serveur ? Et celui de reject pour un administrateur ?

📌 Réponse attendue

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

Étape 5 — Filtrer aussi les connexions sortantes

Un pare-feu s'applique aussi aux connexions qui partent de la machine. Ajoutez une chaîne pour les paquets sortants, puis une règle qui refuse les connexions vers le port 8080 :

sudo nft flush chain inet filtre_tp entrant
sudo nft add chain inet filtre_tp sortant '{ type filter hook output priority 0 ; policy accept ; }'
sudo nft add rule inet filtre_tp sortant tcp dport 8080 reject
curl -sS --max-time 3 http://127.0.0.1:8080/ ; echo "code retour : $?"
curl -sS --max-time 3 http://127.0.0.1:8081/ ; echo "code retour : $?"

1. Pourquoi le site public (8080) n'est-il plus joignable, alors que la chaîne des paquets entrants ne contient plus aucune règle ?
2. Pourquoi l'interface d'administration (8081) répond-elle de nouveau ?
3. Dans quel cas réel un administrateur filtrerait-il des connexions sortantes ?

📌 Réponse attendue

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

Étape 6 — N'autoriser que ce qui est utile

Vous avez jusqu'ici interdit ce que vous connaissiez. Inversez la logique : refusez tout par défaut, puis autorisez uniquement ce qui est nécessaire. Supprimez l'ancienne table et créez-en une nouvelle :

sudo nft delete table inet filtre_tp
sudo nft add table inet filtre_strict
sudo nft add chain inet filtre_strict entrant '{ type filter hook input priority 0 ; policy drop ; }'
sudo nft add rule inet filtre_strict entrant ct state established,related accept
sudo nft add rule inet filtre_strict entrant tcp dport 22 accept
sudo nft add rule inet filtre_strict entrant tcp dport 8080 accept

Lancez ensuite un troisième service, que l'association a installé sans prévenir, puis testez les trois ports :

python3 -m http.server 8082 --bind 127.0.0.1 --directory site &
for p in 8080 8081 8082; do curl -sS --max-time 3 http://127.0.0.1:$p/ | head -1 ; echo "port $p : code retour ${PIPESTATUS[0]}" ; done

Quand vous avez terminé, nettoyez :

sudo nft delete table inet filtre_strict
pkill -f "http.server"

1. Quels ports répondent, et quel est le sort du service 8082 que personne n'avait déclaré ?
2. Pourquoi ajouter la règle ct state established,related accept ?
3. Pourquoi la règle du port 22 est-elle indispensable, même si votre test n'utilise pas SSH ?

📌 Réponse attendue

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

Étape 7 — Conseiller l'association

Le bénévole vous demande ce qu'il doit retenir de votre intervention : « Quels ports laisser ouverts, pourquoi refuser tout par défaut, et le pare-feu suffit-il à protéger le serveur ? » Que lui répondez-vous ?

---

Restitution orale

Un étudiant (ou un binôme) vient présenter à la classe les règles posées sur le serveur (étapes 3 à 6) et les conseils donnés à l'association (étape 7).

• Durée : 5 minutes de présentation + 2 à 3 minutes de questions.
• Qui passe : un(e) étudiant(e) (ou un binôme) désigné(e) par l'enseignant.
• Support : le travail réalisé pendant le TP, aucune préparation supplémentaire n'est nécessaire.
• Ce qui est attendu :
  • rappeler le contexte (le serveur de l'association et l'interface à protéger) ;
  • présenter la démarche suivie (entrant, sortant, politique par défaut) et les conseils donnés ;
  • répondre aux questions de la classe.

astuce

Cet exercice entraîne à l'oral technique court exigé par plusieurs épreuves du BTS (notamment E5 et E6) : clarté, structure, capacité à répondre à l'improviste.

📌 Une solution

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

---

Notions théoriques

Vous venez de contrôler ce qui entre et ce qui sort d'un serveur, par port. Voyons ce qu'est un pare-feu, les décisions qu'il prend et ses limites.

Qu'est-ce qu'un pare-feu ?

Un pare-feu (firewall) est un composant qui examine les paquets réseau et décide, d'après des règles, de les laisser passer ou de les bloquer. Il peut s'appuyer sur :

• le port de destination (le service visé : 22 pour SSH, 80 pour le web...) ;
• l'adresse de l'émetteur ou du destinataire ;
• le sens de la connexion (entrante ou sortante) ;
• l'état de la connexion (nouvelle, ou déjà établie).

Un pare-feu peut être matériel (une boîte entre deux réseaux) ou logiciel, installé sur la machine à protéger. Sous Linux, le filtrage est assuré par le noyau, et on le configure avec des outils comme nft (nftables) ou, plus simplement, ufw.

info

Le cours « Firewall » du dossier de sécurité réseau de ce site détaille la mise en œuvre avec UFW. Cette séance se limite à la découverte du principe, avec l'outil que le noyau utilise réellement.

Entrant et sortant

Sens	Ce que l'on contrôle	Exemple
Entrant (input)	Qui peut atteindre un service de la machine	Interdire l'accès à l'interface d'administration
Sortant (output)	Ce que la machine peut atteindre ailleurs	Empêcher une machine compromise de joindre l'attaquant
Transit (forward)	Ce qui traverse la machine (routeur)	Filtrer entre deux sous-réseaux

Dans ce TP, seuls l'entrant et le sortant ont été utilisés.

La politique par défaut

Lorsqu'un paquet ne correspond à aucune règle, la politique par défaut de la chaîne décide de son sort :

Politique	Principe	Avantage	Inconvénient
accept	On interdit ce que l'on connaît (liste noire)	Simple, rien ne casse	Ce qui est inconnu passe
drop	On autorise ce qui est utile (liste blanche)	Ce qui est imprévu est bloqué	Une règle oubliée coupe un service, voire l'accès à distance

C'est le principe du moindre privilège appliqué au réseau : n'ouvrir que ce qui est nécessaire.

Jeter ou refuser

Action	Ce que voit l'émetteur	Usage
drop	Aucune réponse, jusqu'à l'expiration du délai	Ralentir un scan, ne rien révéler
reject	Un refus explicite, immédiat	Faciliter le diagnostic en réseau interne

attention

Dans les deux cas, le service continue de tourner : c'est la connexion qui est bloquée. Un pare-feu ne répare pas un service vulnérable, il en limite seulement l'accès.

Les limites d'un pare-feu

• Il ne protège pas contre une faille d'une application sur un port autorisé.
• Il ne remplace ni les mises à jour, ni les mots de passe solides.
• Il ne voit pas ce qui se passe à l'intérieur (compte compromis, utilisateur malveillant).
• Une règle ajoutée en ligne de commande est temporaire : sans enregistrement dans la configuration, elle est perdue au redémarrage.

Pour aller plus loin

La séance suivante de la progression s'intéressera à ce que voit un attaquant avant même de s'attaquer à un service : un scan de ports. C'est précisément ce que le pare-feu rend plus difficile, par exemple avec drop.

---

Test de mémorisation/compréhension

Quel est le rôle principal d'un pare-feu ?

Chiffrer toutes les données qui circulent entre le serveur et les ordinateurs du réseau local, quelle que soit leur origine

Examiner les paquets réseau et décider, d'après des règles, de les laisser passer ou de les bloquer

Détecter et supprimer les virus présents sur les fichiers stockés sur le disque du serveur

Sauvegarder automatiquement la configuration du serveur pour pouvoir la restaurer en cas de panne

Attribuer une adresse IP à chaque machine qui se connecte au réseau de l'organisation

Quelle différence y a-t-il entre les actions drop et reject d'un pare-feu ?

drop supprime définitivement le service visé, alors que reject se contente de le mettre en pause

drop concerne uniquement les connexions sortantes, alors que reject concerne uniquement les entrantes

drop ne répond rien à l'émetteur, alors que reject lui renvoie un refus explicite et immédiat

drop chiffre le paquet avant de le jeter, alors que reject le jette en clair, sans aucune protection

drop est réservé aux administrateurs, alors que reject peut être utilisé par tout utilisateur du système

Un pare-feu bloque le port 8081 d'un serveur. Que peut-on dire du service qui écoute sur ce port ?

Il a été arrêté automatiquement par le pare-feu, qui désactive tout service dont le port est filtré, pour éviter toute fuite

Il a été supprimé du serveur, et il faudra le réinstaller pour qu'il fonctionne à nouveau

Il continue de tourner, mais les connexions qui lui sont destinées sont bloquées avant de l'atteindre

Il est devenu invisible pour toutes les machines, y compris pour le serveur lui-même

Il est automatiquement déplacé sur un autre port choisi au hasard par le pare-feu du système

Que signifie une politique par défaut « drop » sur la chaîne des paquets entrants ?

Que tous les paquets entrants sont acceptés tant qu'aucune règle ne les interdit explicitement

Que le pare-feu supprime automatiquement toute règle ajoutée par l'administrateur après une heure

Que seuls les paquets destinés à un service installé sur le serveur sont enregistrés dans les journaux

Que tout paquet qui ne correspond à aucune règle d'autorisation est jeté, y compris l'imprévu

Que le pare-feu ne bloque que les paquets envoyés depuis des adresses situées à l'étranger

Un administrateur passe la politique d'entrée en « drop » sur un serveur distant, sans règle pour le port 22. Que risque-t-il ?

De ne plus pouvoir se connecter à distance au serveur, puisque sa propre connexion SSH est jetée

De provoquer l'arrêt immédiat du serveur, qui s'éteint dès qu'une règle de blocage est détectée

De voir tous les mots de passe des utilisateurs du serveur s'afficher dans les journaux système

De réinitialiser la configuration du serveur à son état d'origine, avec la perte de toutes ses données

De bloquer uniquement les connexions du site web, sans conséquence sur les autres services du serveur

Pourquoi filtrer des connexions sortantes sur une machine ?

Pour accélérer le débit de la connexion Internet de la machine, en supprimant les paquets inutiles

Pour empêcher les utilisateurs du réseau local d'atteindre les services hébergés sur cette machine

Pour réduire la consommation électrique de la machine pendant les heures de la nuit et du week-end

Pour vérifier l'identité de chaque utilisateur avant d'autoriser son accès au réseau de l'organisation

Pour empêcher une machine compromise de communiquer avec un serveur de l'attaquant

Que se passe-t-il, par défaut, pour une règle nft ajoutée en ligne de commande au redémarrage du serveur ?

Elle est conservée à l'identique, car le noyau enregistre automatiquement toutes les règles actives

Elle est perdue, sauf si elle a été enregistrée dans la configuration chargée au démarrage

Elle est envoyée par e-mail à l'administrateur, qui doit la valider avant sa réactivation

Elle est transformée en politique par défaut, qui s'applique à l'ensemble du système

Elle est déplacée vers le routeur de l'organisation, qui prend le relais du serveur

---

Bonnes pratiques

• Refuser par défaut, autoriser explicitement : une politique drop et une liste de ports utiles.
• N'ouvrir que les ports nécessaires : une interface d'administration n'a pas à être joignable de partout.
• Ne jamais oublier la règle SSH avant de passer une chaîne en drop sur un serveur distant.
• Filtrer aussi le sortant quand c'est utile, pour limiter ce qu'une machine compromise peut faire.
• Enregistrer les règles dans la configuration pour qu'elles survivent au redémarrage.
• Tester après chaque modification, depuis l'extérieur de la machine quand c'est possible.
• Ne pas se reposer sur le pare-feu seul : il se combine avec les mises à jour, des mots de passe solides et des droits limités.