Configurer le pare-feu

Un VPS CloudFive vous donne un accès root : c’est vous qui décidez quels ports sont joignables depuis Internet. Cette page s’adresse à toute personne qui vient de commander un VPS et veut le fermer proprement avant de mettre un service en production, avec UFW sur Debian et Ubuntu, firewalld sur AlmaLinux et Rocky.

Prérequis : un accès SSH en root ou avec sudo (Première connexion SSH), et la liste des ports que vos services utilisent réellement.

Lisez la dernière section avant de commencer

La première cause de VPS injoignable, c’est un pare-feu activé sans avoir autorisé le port SSH. La section Éviter de se verrouiller hors du serveur explique comment travailler sans risque. Lisez-la d’abord.

Principe : tout fermer, puis ouvrir le nécessaire

Un pare-feu bien réglé tient en trois règles :

1. Tout ce qui entre est refusé par défaut.
2. Tout ce qui sort est autorisé — sinon vos mises à jour et vos sauvegardes cassent.
3. On ouvre une par une les portes dont vos services ont besoin, et rien de plus.

Ce qui n’est pas ouvert est injoignable : un service oublié, une base de données exposée par erreur, un panneau d’administration en test. C’est l’intérêt principal de la manœuvre, bien avant la protection contre les attaques.

Note

Le pare-feu et l’anti-DDoS CloudFive ne font pas le même travail. Le filtrage anti-DDoS est permanent, en amont de votre machine, et vous n’avez rien à activer. Le pare-feu, lui, décide quels services de votre VPS répondent. Les deux sont utiles, aucun ne remplace l’autre.

Configurer UFW (Debian, Ubuntu)

UFW est le pare-feu le plus simple à vivre sur Debian et Ubuntu.

1. Installez-le s’il manque :

   apt update && apt install -y ufw

2. Posez la politique par défaut :

   ufw default deny incoming
   ufw default allow outgoing

3. Autorisez SSH avant toute chose. C’est l’étape qu’on oublie :

   ufw allow 22/tcp comment 'SSH'

   Si vous avez changé le port d’écoute de SSH, mettez le vôtre à la place de 22.

4. Activez le pare-feu. Confirmez par y :

   ufw enable

5. Relisez le résultat :

   ufw status verbose

Les commandes utiles ensuite :

ufw allow 443/tcp                  # ouvrir un port
ufw allow 30120                    # TCP et UDP d'un coup
ufw delete allow 443/tcp           # retirer une règle
ufw status numbered                # lister avec un numéro
ufw delete 3                       # supprimer la règle n°3
ufw logging on                     # journaliser les refus

Limiter les tentatives sur SSH

ufw limit 22/tcp remplace allow et bloque temporairement une adresse qui ouvre trop de connexions d’affilée. C’est un réglage à un mot qui fait disparaître l’essentiel du bruit de fond sur le port SSH. Le vrai correctif reste l’authentification par clé.

Configurer firewalld (AlmaLinux, Rocky)

Sur AlmaLinux et Rocky, firewalld est en général déjà présent. Il raisonne par zones et par services nommés, et distingue les règles temporaires des règles permanentes.

1. Vérifiez qu’il tourne :

   systemctl enable --now firewalld
   firewall-cmd --state

2. Regardez la zone active et ce qu’elle autorise :

   firewall-cmd --get-active-zones
   firewall-cmd --list-all

3. Assurez-vous que SSH est bien dans la liste. Si non :

   firewall-cmd --permanent --add-service=ssh

4. Ajoutez vos ports, avec --permanent pour qu’ils survivent au redémarrage :

   firewall-cmd --permanent --add-service=https
   firewall-cmd --permanent --add-port=30120/tcp
   firewall-cmd --permanent --add-port=30120/udp

5. Rechargez pour appliquer, puis relisez :

   firewall-cmd --reload
   firewall-cmd --list-all

Le piège de --permanent

Une règle posée sans --permanent disparaît au prochain redémarrage ou au prochain --reload. Une règle posée avec --permanent ne s’applique qu’après un --reload. Si une ouverture « ne marche pas », c’est presque toujours l’un des deux.

Pour retirer une règle, remplacez --add- par --remove-, puis rechargez :

firewall-cmd --permanent --remove-port=30120/udp
firewall-cmd --reload

Ouvrir les ports de ses services

N’ouvrez que ce qui doit être joignable depuis Internet. Les ports courants :

Service	Port	Protocole	À ouvrir publiquement ?
SSH	22	TCP	Oui, ou restreint à votre IP
HTTP	80	TCP	Oui si vous servez un site
HTTPS	443	TCP	Oui si vous servez un site
MySQL / MariaDB	3306	TCP	Non en général
FiveM	30120	TCP et UDP	Oui pour un serveur de jeu
Minecraft	25565	TCP	Oui pour un serveur de jeu

La liste complète par produit est sur Ports et protocoles par service. Pour un serveur de jeu hébergé sur le panel plutôt que sur un VPS, c’est Ports et allocations qui s’applique — vous n’avez pas de pare-feu à régler.

Une base de données n’a presque jamais besoin d’être ouverte au monde : si l’application tourne sur le même VPS, elle passe par 127.0.0.1. Si vous devez vraiment y accéder depuis l’extérieur, restreignez à une adresse source :

UFW

ufw allow from 203.0.113.10 to any port 3306 proto tcp

firewalld

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port port="3306" protocol="tcp" accept'
firewall-cmd --reload

Vérifiez d’abord ce qui écoute

Avant d’ouvrir quoi que ce soit, demandez à votre VPS ce qui attend des connexions :

ss -tulpn

Une ligne en 0.0.0.0:* écoute sur toutes les interfaces, donc sur Internet dès que le port est ouvert. Une ligne en 127.0.0.1 n’est joignable que depuis la machine elle-même. Souvent, la bonne correction n’est pas une règle de pare-feu : c’est reconfigurer le service pour qu’il n’écoute qu’en local.

Le cas du VPS Windows

Sur un VPS Windows, le pare-feu de Windows est déjà actif et c’est lui qui décide. Les règles se créent dans la console de gestion du pare-feu, en règle de trafic entrant, port par port. Le raisonnement est identique : refus par défaut, et surtout ne touchez pas à la règle qui autorise le Bureau à distance, sous peine de perdre l’accès.

Éviter de se verrouiller hors du serveur

Trois précautions, à prendre dans cet ordre :

1. Gardez une deuxième session SSH ouverte pendant toute la manipulation. Si la session de travail se coupe, l’autre reste en vie et vous laisse corriger.

2. Posez un filet de sécurité : programmez la désactivation du pare-feu dans dix minutes, et annulez-la quand vous avez confirmé que tout fonctionne.

   apt install -y at          # ou dnf install -y at
   echo "ufw disable" | at now + 10 minutes
   atq                        # affiche la tâche et son numéro
   atrm 1                     # annule la tâche n°1 si tout va bien

3. Testez depuis une autre machine, pas depuis le VPS : ouvrez une nouvelle connexion SSH et un accès à votre service.

Danger

Ne videz jamais vos règles à l’aveugle avec iptables -F ou nft flush ruleset sur une machine distante, et n’activez pas firewall-cmd --panic-on : vous coupez la connexion en cours, y compris la vôtre, sans moyen de revenir par le réseau.

Si malgré tout vous êtes dehors, l’accès de secours est la console VNC : elle passe par l’espace client, pas par le réseau du VPS, et vous permet de désactiver le pare-feu.

Si ça ne marche pas

Le port est ouvert mais le service ne répond pas. Vérifiez d’abord que le service écoute vraiment, avec ss -tulpn. Un service arrêté, ou qui n’écoute que sur 127.0.0.1, reste injoignable quelles que soient vos règles.

La règle existe mais n’est pas prise en compte. Sur firewalld, vous avez probablement oublié firewall-cmd --reload après un --permanent. Sur UFW, contrôlez que le pare-feu est bien actif (ufw status) et que l’ordre des règles ne place pas un refus avant votre autorisation (ufw status numbered).

UFW ou firewalld refuse de démarrer, avec une erreur de module ou de permission. Selon la virtualisation de votre offre, une partie du filtrage dépend du noyau de l’hôte. N’insistez pas : ouvrez un ticket de support en collant le message d’erreur exact et le nom de votre distribution.

Je ne sais plus quelle règle a cassé quoi. Repartez de zéro : ufw reset sur Debian et Ubuntu, ou firewall-cmd --permanent --zone=public --remove-port=... port par port, puis refaites la procédure en autorisant SSH en premier. Si le VPS est déjà injoignable, passez par la console VNC, et en dernier recours par le dépannage complet.

Je confonds blocage pare-feu et blocage réseau. Un port fermé par le pare-feu refuse la connexion ou l’ignore ; un incident réseau rend toute la machine muette, ping compris. Consultez status.cloudfive.xyz avant de chercher chez vous.