Configurer le pare-feu UFW sur un VPS : la liste blanche

UFW, pour Uncomplicated Firewall, est le pare-feu fourni avec Ubuntu et disponible sur Debian. Il pilote le pare-feu du noyau Linux avec des commandes lisibles. Bien réglé, il garantit qu'un service installé par erreur, ou une base de données laissée ouverte, n'est pas joignable depuis Internet.

1. Le principe : tout fermer, puis ouvrir au cas par cas

La seule politique raisonnable sur un serveur exposé est la liste blanche : tout le trafic entrant est refusé par défaut, et vous n'ouvrez que les ports dont vous avez réellement besoin. Le trafic sortant reste autorisé, pour que le serveur puisse faire ses mises à jour.

Avant de commencer, listez ce qui écoute réellement sur le serveur :

ss -tulpn

Tout service qui écoute sur 0.0.0.0 ou [::] est potentiellement accessible depuis Internet. Ceux qui écoutent sur 127.0.0.1 ne le sont pas.

2. Installer et activer

apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable
ufw status verbose

UFW gère l'IPv4 et l'IPv6 en même temps. Vérifiez que la ligne IPV6=yes est présente dans /etc/default/ufw : sinon, vos règles ne s'appliqueraient pas à l'IPv6 du serveur.

3. Les ports à ouvrir selon votre usage

Sans précision de protocole, comme pour FiveM, la règle ouvre TCP et UDP. Précisez-le dès que possible pour ne pas ouvrir plus que nécessaire. Ajoutez un commentaire pour vous y retrouver plus tard :

ufw allow 30120 comment 'FiveM'

4. Restreindre un port à une adresse IP

Pour un panneau d'administration, une base de données ou le RCON d'un serveur de jeu, n'autorisez que votre adresse :

ufw allow from 203.0.113.10 to any port 3306 proto tcp comment 'MariaDB bureau'
ufw allow from 203.0.113.10 to any port 28016 proto tcp comment 'RCON Rust'

Remplacez 203.0.113.10 par votre adresse IP publique. Si elle change régulièrement, comme chez beaucoup de fournisseurs d'accès, préférez un VPN : voir monter un serveur WireGuard.

5. Limiter les connexions SSH

La règle limit refuse une adresse qui ouvre 6 connexions ou plus en 30 secondes. C'est un premier frein efficace contre la force brute :

ufw delete allow OpenSSH
ufw limit OpenSSH

Complétez avec Fail2ban, qui bannit durablement : voir sécuriser SSH.

6. Gérer les règles

ufw status numbered        # règles numérotées
ufw delete 4               # supprime la règle numéro 4
ufw delete allow 80/tcp    # supprime une règle par son contenu
ufw reload                 # recharge après une modification manuelle
ufw logging low            # journalise les paquets bloqués

Les paquets bloqués apparaissent dans /var/log/ufw.log, ou avec journalctl -k | grep UFW. Utile pour comprendre pourquoi un service ne répond pas.

7. Le piège Docker

C'est la surprise la plus fréquente, et elle est dangereuse : les ports publiés par Docker contournent UFW. Docker écrit ses propres règles dans le pare-feu du noyau, avant celles d'UFW. Un conteneur lancé avec -p 3306:3306 est donc joignable depuis Internet, même si ufw status ne l'autorise pas.

La solution la plus simple est de ne publier sur toutes les interfaces que ce qui doit être public, et de lier le reste à l'adresse locale :

ports:
  - "127.0.0.1:3306:3306"   # accessible seulement depuis le serveur
  - "80:80"                 # public, volontairement

Les services qui n'ont besoin d'être joints que par d'autres conteneurs n'ont même pas besoin de section ports : ils communiquent par le réseau interne de Docker. Voir Docker et Docker Compose.

8. UFW et la protection Anti-DDoS

UFW et l'Anti-DDoS ne font pas le même travail. UFW décide quels services sont joignables. Il n'arrête pas une attaque volumétrique : quand des gigabits de trafic arrivent sur votre serveur, le lien est saturé avant même que le pare-feu ne les rejette. Ce filtrage doit se faire en amont, sur le réseau. C'est le rôle de la protection Anti-DDoS incluse sur nos VPS. Les deux se complètent. Pour en savoir plus, voir limiter l'impact d'une attaque DDoS.

Questions fréquentes