Scan sur une adresse IP fraîche : port 6379 Redis ouvert, port 3306 MySQL répond. Le VPS avait nginx correctement configuré — et aucun pare-feu en refus par défaut. L'attaquant n'a pas hacké nginx ; il a parlé directement à Redis. Ce scénario se produit en minutes sur toute IP publique non filtrée — pas en semaines.
Configurer le pare-feu d'un VPS, c'est définir qui a le droit de parler à quels services. Pas installer dix outils — commencer par refuser tout le trafic entrant sauf l'essentiel, puis n'ouvrir que ce que le site respire vraiment. Le pare-feu ne crée pas la vulnérabilité ; il rend visible votre négligence d'écoute réseau.
Beaucoup d'équipes configurent nginx, déploient l'application, puis « feront le pare-feu plus tard ». Plus tard arrive souvent après le premier scan — ou après une compromission Redis laissée ouverte « temporairement ».
Ports à autoriser en entrée pour un site web classique
| Port | Service | Note |
|---|---|---|
| 22/tcp | SSH | Restreindre à l'IP administrateur si possible |
| 80/tcp | HTTP | Redirection ACME et vers HTTPS |
| 443/tcp | HTTPS | Site public |
| ICMP | ping | Optionnel ; certains outils de supervision l'utilisent |
Tout le reste fermé par défaut : MySQL 3306, Redis 6379, Postgres 5432, SMTP 25, panneau d'administration 8080. Les services internes écoutent sur 127.0.0.1 ou réseau privé — pas sur 0.0.0.0 exposé à Internet.
Avant d'écrire la première règle, listez ce qui écoute réellement :
ss -tlnp
Comparez la sortie à ce que vous pensiez avoir installé. Docker, par exemple, peut publier des ports sans que ufw les filtre selon la configuration — voir les pièges ci-dessous.
ufw : séquence sûre pour ne pas vous enfermer
Avant ufw enable, gardez une session SSH ouverte et testez depuis une seconde fenêtre :
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose
Si vous administrez depuis une IP fixe, restreignez SSH :
ufw allow from VOTRE.IP.BUREAU to any port 22 proto tcp
IPv6 : une règle ufw allow 443/tcp doit couvrir v6 ou une règle explicite — oublier v6 crée un trou que les scans exploitent. Vérifiez avec ufw status verbose que les règues v6 sont alignées.
Beaucoup d'hébergeurs — Hetzner Cloud Firewall, OVH Network Security — filtrent avant le VPS. Double couche recommandée : panel restrictif plus ufw local aligné. Voir Hetzner firewall cloud pour un exemple concret de règles panel.
Compléments : fail2ban, clés SSH, erreurs classiques
fail2ban bannit les adresses après échecs SSH répétés — voir SSH sécurisé. Pas de mot de passe SSH : clés uniquement. Le pare-feu ne corrige pas les failles non corrigées (CVE) ; il réduit la surface d'attaque exposée.
Erreurs qui reviennent :
- Autoriser 3306 « temporairement » pendant des mois ;
- Docker
-p 6379:6379qui publie Redis sans filtre ufw selon la configuration ; - Désactiver ufw « pour debug » sans date de remise en service ;
- SSH ouvert au monde entier avec authentification par mot de passe faible.
Pour un bastion d'accès, voir SSH bastion — alternative à l'exposition directe de SSH depuis n'importe quelle IP.
Le sommet : le pare-feu révèle ce que vous exposez par habitude
Listez ss -tlnp avant d'écrire la première règle. Comparez les VPS avec pare-feu panel via l'annuaire et le comparateur — certains hébergeurs européens incluent un pare-feu cloud gratuit, d'autres le facturent séparément.
Décider et avancer sans angle mort
Sur une demi-journée, vous pouvez sécuriser un VPS neuf ou auditer un existant :
- Inventoriez les ports ouverts avec
ss -tlnpet un scan depuis l'extérieur — ne vous fiez pas à votre mémoire de l'installation. - Configurez le pare-feu cloud restrictif en premier : SSH depuis l'IP bureau, 80 et 443 publics, tout le reste fermé.
- Activez ufw en refus par défaut avec les mêmes règles — gardez une session SSH ouverte pendant le test.
- Liez bases de données et cache sur localhost ou réseau privé uniquement ; jamais sur 0.0.0.0 sans tunnel ou VPN.
- Couplez fail2ban et authentification par clé SSH — le pare-feu seul ne suffit pas contre les attaques par force brute.
- Revérifiez IPv6 et conteneurs Docker qui publient des ports sans filtre après chaque déploiement.
Questions fréquentes
ufw ou nftables directement ?
ufw pour démarrer vite sur Ubuntu ou Debian — abstraction lisible. nftables ou iptables si règles complexes ou scripts d'infrastructure. Les deux peuvent coexister ; évitez les doublons contradictoires qui bloquent le trafic légitime.
Faut-il changer le port SSH 22 ?
Obscurité faible bénéfice seule. Clés SSH sans mot de passe plus fail2ban valent plus. Port personnalisé en bonus pour réduire le bruit des scans, pas en remplacement de l'authentification forte.
Pare-feu cloud hébergeur + ufw local ?
Recommandé en défense en profondeur : pare-feu panel en première barrière, ufw sur l'instance. Alignez les règles pour ne pas vous bloquer — surtout sur SSH depuis une IP fixe.
Ouvrir MySQL au bureau pour phpMyAdmin ?
Non en direct sur Internet. Tunnel SSH, VPN, ou administration via localhost uniquement. Exposer 3306 attire les scans en minutes.
Un pare-feu VPS efficace ne commence pas par autoriser tout — il commence par refuser tout, puis n'ouvrir que ce sans quoi le site ne respire pas.