Comment configurer en toute sécurité les règles de pare-feu d’un VPS
Publié le 4 septembre 2026
Un pare-feu doit autoriser le trafic dont votre serveur a besoin et refuser discrètement le reste. Pour configurer en toute sécurité les règles de pare-feu d’un VPS, commencez par les services qui doivent rester accessibles, en particulier SSH, puis ajoutez les ports web et applicatifs un par un. Ne commencez pas par tout bloquer depuis la seule session de terminal que vous avez ouverte. C’est ainsi qu’une tâche de maintenance tranquille se transforme en opération de récupération via la console.
Pour la plupart des déploiements de VPS Linux, l’objectif pratique est simple : refuser par défaut le trafic entrant non sollicité, autoriser le trafic sortant requis et créer des règles entrantes restrictives pour les utilisateurs et services de confiance. Cela réduit la surface d’attaque sans compliquer l’administration courante.
Commencez par la cartographie du trafic
Avant de modifier la moindre règle, notez ce que le VPS fait réellement. Un site WordPress public, par exemple, a généralement besoin de SSH pour l’administration et des ports 80 et 443 pour le trafic web. Une API privée peut n’avoir besoin que de HTTPS, tandis qu’un serveur de base de données ne devrait généralement accepter des connexions que depuis un serveur applicatif sur un réseau privé.
Vérifiez d’abord les services à l’écoute. Sur la plupart des distributions Linux, cette commande offre une vue utile :
```bash sudo ss -tulpn ```
N’ouvrez pas automatiquement chaque port affiché. Certains services n’écoutent que sur localhost ou sur une interface privée et n’ont pas besoin d’un accès public via le pare-feu. D’autres peuvent être d’anciens services de test, des agents de supervision ou des logiciels qui ne devraient pas du tout être accessibles depuis Internet.
Pour chaque port exposé au public, répondez à trois questions : qui en a besoin, depuis où et via quel protocole ? Une règle autorisant HTTPS depuis n’importe où est normale pour un site web public. Une règle autorisant un port de base de données depuis n’importe où est généralement un problème qui attend poliment dans les journaux.
Conservez une voie de récupération avant de configurer les règles de pare-feu du VPS
Maintenez deux sessions SSH actives pendant que vous modifiez le pare-feu. Utilisez une session pour appliquer les règles et laissez la seconde intacte. Après avoir appliqué une modification, testez une nouvelle connexion depuis un autre terminal avant de fermer quoi que ce soit. Cela permet de détecter les erreurs dans le chemin de connexion réel au lieu de compter sur l’optimisme.
Vérifiez également que la console de votre fournisseur de VPS est disponible. Une console accessible depuis le navigateur ou un environnement de secours sert de solution de repli si SSH est bloqué. Ce n’est pas un substitut à un travail soigneux, mais c’est une bonne assurance opérationnelle.
Si SSH s’exécute sur un port non standard, vérifiez-le avant de créer des règles :
```bash sudo ss -tulpn | grep ssh ```
Un port SSH non standard peut réduire le bruit de fond des analyses automatisées, mais ce n’est pas une mesure de sécurité réellement significative à lui seul. Une authentification forte, un accès source limité et l’application rapide des correctifs font le vrai travail.
Utilisez une politique entrante de refus par défaut avec UFW
UFW est une interface de pare-feu pratique pour les serveurs VPS Ubuntu et basés sur Debian. Il est facile à relire par la suite, ce qui compte lorsqu’un autre administrateur doit résoudre une panne à 2 h du matin.
Commencez par définir des valeurs par défaut raisonnables :
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Ensuite, autorisez SSH avant d’activer le pare-feu. Si votre serveur utilise le port SSH par défaut, utilisez :
```bash sudo ufw allow OpenSSH ```
Si SSH écoute sur un port personnalisé, indiquez-le explicitement. Cet exemple utilise le port 2222 :
```bash sudo ufw allow 2222/tcp ```
Pour un site web public classique, autorisez HTTP et HTTPS :
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Activez ensuite le pare-feu et vérifiez la politique obtenue :
```bash sudo ufw enable sudo ufw status numbered ```
L’état numéroté est utile, car les règles peuvent ensuite être supprimées avec précision. Évitez de laisser des règles temporaires trop larges en place après le dépannage. Les règles temporaires ont cette drôle d’habitude de devenir du mobilier permanent.
Si le VPS héberge une application web derrière un proxy inverse, il se peut que le port de l’application n’ait pas besoin d’être public. Par exemple, Nginx peut accepter le trafic sur les ports 80 et 443 tandis que l’application écoute sur `127.0.0.1:3000`. Dans cette conception, aucune règle de pare-feu pour le port 3000 n’est nécessaire.
Restreignez l’accès administratif par adresse IP source
SSH ne devrait pas être ouvert à toutes les adresses à moins que votre équipe n’ait réellement besoin de cette souplesse. Si votre bureau, VPN ou hôte de rebond dispose d’une adresse IP publique stable, limitez SSH à celle-ci :
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
Pour une équipe distribuée avec des IP domestiques changeantes, un VPN ou un hôte bastion est souvent une meilleure solution que d’ouvrir SSH globalement. Cela ajoute un peu de travail de configuration, mais vous offre un chemin d’administration unique et contrôlé ainsi qu’une piste d’audit plus propre.
La limitation de débit peut également réduire les tentatives basiques de devinette de mot de passe SSH :
```bash sudo ufw limit 22/tcp ```
Cela ne remplace pas les clés SSH, la désactivation de l’authentification par mot de passe lorsque cela est approprié, ni l’accès multifacteur via votre chemin d’administration. Considérez cela comme un panneau de clôture, pas comme toute la clôture.
Traitez séparément les bases de données, les panneaux et la supervision
Les ports de base de données tels que MySQL sur 3306, PostgreSQL sur 5432, Redis sur 6379 et MongoDB sur 27017 ne devraient presque jamais être accessibles publiquement. Autorisez-les uniquement depuis l’adresse IP privée ou le sous-réseau du serveur applicatif.
Par exemple, pour autoriser les connexions MySQL uniquement depuis un VPS applicatif à `10.10.0.12` :
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
Le service de base de données lui-même devrait également se lier à l’interface privée prévue lorsque c’est possible. Les règles de pare-feu et la liaison du service sont des couches distinctes. Utiliser les deux signifie qu’une modification erronée du pare-feu a moins de chances d’exposer le service.
Les panneaux d’hébergement, les tableaux de bord Grafana et les points de terminaison de supervision méritent la même attention. S’ils sont réservés au personnel, limitez-les à un VPN, à une plage d’IP de bureau ou à un réseau d’administration dédié. Les pages de supervision publiques peuvent exposer davantage de détails sur l’infrastructure que prévu, même lorsqu’elles n’affichent pas de secrets.
Tenez compte du pare-feu du fournisseur et d’IPv6
Votre VPS peut comporter plus d’une couche de pare-feu. Un pare-feu cloud ou au niveau du fournisseur filtre le trafic avant qu’il n’atteigne le serveur, tandis que UFW, firewalld, nftables ou iptables filtrent le trafic sur le VPS lui-même. Utiliser les deux est judicieux, mais les règles doivent concorder.
Si le port 443 est ouvert sur le VPS mais bloqué au niveau du fournisseur, les visiteurs ne parviendront toujours pas à se connecter. Si le fournisseur autorise un port mais que le VPS le refuse, le VPS reste protégé. Lors du dépannage, vérifiez les deux couches dans l’ordre : politique du fournisseur, pare-feu du VPS, adresse d’écoute du service et configuration de l’application. Les journaux racontent généralement la même histoire une fois ces éléments vérifiés.
N’oubliez pas IPv6. Si votre VPS possède une adresse IPv6 publique, des règles IPv6 équivalentes sont requises. UFW peut gérer IPv6 lorsqu’il est activé dans sa configuration, mais vérifiez avec :
```bash sudo ufw status verbose ```
Une adresse IPv4 correctement sécurisée ne sert à rien si le même service est grand ouvert en IPv6.
Testez depuis l’extérieur, puis surveillez le résultat
Après chaque modification significative, testez depuis un réseau extérieur au VPS. Confirmez que les services prévus fonctionnent, puis confirmez que les ports destinés à rester privés ne sont pas accessibles. Les tests dans le navigateur sont utiles pour les sites web, mais les tests en ligne de commande fournissent des réponses plus claires pour des ports spécifiques :
```bash nc -vz your-server-ip 443 ```
Pour les ports bloqués, un délai d’attente ou un refus peut signifier différentes choses selon la règle et l’état du service. Examinez l’état du pare-feu, l’état du service et les journaux système plutôt que de modifier plusieurs paramètres à la fois.
Activez la journalisation avec prudence lors du diagnostic d’un problème :
```bash sudo ufw logging low ```
Un niveau de journalisation faible suffit généralement pour repérer un trafic refusé inattendu sans produire d’activité disque inutile. Sur les serveurs chargés, des journaux de pare-feu à fort volume peuvent devenir une petite nuisance opérationnelle en eux-mêmes.
Réexaminez les règles de pare-feu chaque fois que vous déployez un nouveau service, retirez une ancienne application, changez les adresses IP du bureau ou modifiez l’architecture réseau. Les meilleures règles ne sont pas l’ensemble de règles le plus long. C’est le plus petit ensemble qui décrit précisément la manière dont le serveur doit communiquer.
Si vous préférez ne pas assumer seul ce travail, une équipe VPS infogérée peut examiner les exigences d’accès, appliquer les changements avec un plan de récupération et surveiller ensuite le serveur. Chez kodu.cloud, cela s’intègre naturellement aux opérations infogérées et à la surveillance continue, en particulier pour les équipes qui doivent se concentrer sur les clients et le produit plutôt que sur le filtrage des paquets.
Un pare-feu fait bien son travail lorsque personne ne le remarque. Gardez une politique restrictive, documentez pourquoi chaque exception existe et testez l’accès avant de déclarer à nouveau le service revenu au calme.
Andres Saar Ingénieur du support client