fren
Connexion

Comprendre le pare-feu

3 min de lecture07 novembre 2026

Un pare-feu décide quels paquets peuvent entrer et sortir d'une machine. Sur un VPS NeoHeberg, il réduit la surface exposée aux scans, mais il ne corrige ni une application vulnérable ni un mot de passe faible. Le configurer consiste surtout à choisir ce que vous acceptez d'exposer.

Entrant, sortant et connexions établies

Un pare-feu à états suit les connexions. Si vous autorisez SSH en entrée, la réponse sortante est acceptée parce qu'elle appartient à une connexion déjà établie : inutile d'ouvrir un port de retour. La politique par défaut fait le reste.

Sens Politique de départ Cas typique
Entrant refuser SSH, HTTP, HTTPS explicitement autorisés
Sortant autoriser mises à jour, dépôts, API
Transfert refuser sauf machine faisant routeur

Refuser tout l'entrant est plus sûr que d'ouvrir largement puis de fermer au cas par cas. Commencez par inventorier ce qui écoute réellement :

Bash
sudo ss -tulpn

Un service lié à 127.0.0.1 n'est pas joignable depuis Internet, même si son port est autorisé. À l'inverse, un service lié à 0.0.0.0 est exposé si le pare-feu l'autorise. Les deux réglages doivent être cohérents : base de données en local, reverse proxy pour l'application.

Configurer UFW

Debian 13 utilise nftables ; UFW reste une interface simple et lisible. Autorisez SSH avant d'activer le pare-feu, sinon la session suivante sera coupée.

Bash
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

Ces commandes définissent les politiques par défaut, ouvrent les trois ports utiles et affichent les règles actives. UFW gère IPv4 et IPv6 ensemble : vérifiez que IPV6=yes figure dans /etc/default/ufw, ce qui est le cas par défaut sur Debian.

Si vous changez le port SSH, adaptez la règle avant de redémarrer le service. Pour retirer une règle, utilisez son numéro :

Bash
sudo ufw status numbered
sudo ufw delete 3

Ce qu'un pare-feu ne fait pas

  • Il n'authentifie personne : une application sans mot de passe reste ouverte sur le port autorisé.
  • Il ne filtre pas le contenu : une injection SQL ou un XSS passe par HTTP et HTTPS.
  • Il ne bloque pas une exfiltration initiée par un processus compromis si la sortie est autorisée.
  • Dans un conteneur système, il filtre le trafic du conteneur, pas celui de la plateforme ; l'infrastructure peut appliquer ses propres règles en amont.

Pour une base de données ou Redis, l'écoute locale est plus efficace qu'une règle de pare-feu : le port n'est jamais joignable de l'extérieur, même par erreur de configuration.

Vérifier et dépanner

  • sudo ufw status verbose montre les politiques et les règles, IPv4 comme IPv6.
  • sudo nft list ruleset affiche les règles réellement chargées.
  • sudo ss -tulpn confirme l'adresse d'écoute de chaque service.
  • Depuis une autre machine, testez uniquement votre propre VPS : nc -vz VOTRE_IPV6 443.

Si vous perdez SSH, la console noVNC du dashboard reste accessible : connectez-vous en root et exécutez sudo ufw disable le temps de corriger la règle. Docker publie ses ports via ses propres règles et peut contourner UFW ; testez depuis l'extérieur et liez les conteneurs à 127.0.0.1 quand ils ne doivent pas être publics.

Publicité

Cet article vous a-t-il aidé ?

À lire aussi