Hetzner Cloud Firewall et sécurité VPS : guide complet 2026

Un VPS public sans firewall en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer), c’est un serveur qui sera scanné dans les 5 minutes suivant sa mise en ligne et tenté pour brute-force SSH dans l’heure. Heureusement, Hetzner Cloud propose un Cloud Firewall gratuit et puissant qui se configure en quelques clics. Couplé à des bonnes pratiques sur le VPS lui-même (UFW, fail2ban, SSH hardening, mises à jour automatiques), vous obtenez une posture de sécurité solide.

Cet article complète notre guide Hetzner Cloud Afrique.

Hetzner Cloud Firewall : pourquoi et comment

• Gratuit et illimité (autant de règles que vous voulez)
• Avant le VPS : économise les ressources kernel/iptables du VPS
• Multi-VPS : un firewall peut être attaché à plusieurs VPS (politique uniforme)
• Configurable via API : Terraform, Ansible, scripts

Étape 1 — Créer un Firewall Cloud

1. Console Hetzner → Firewalls → Create Firewall
2. Nom : web-public
3. Règles entrantes : SSH (TCP 22) limité à votre IP, HTTP (80) et HTTPS (443) ouverts à tous
4. Règles sortantes : Allow All par défaut
5. Apply to Resources → cocher votre VPS

Étape 2 — Hardening SSH

# /etc/ssh/sshd_config
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PermitEmptyPasswords no
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy admin

systemctl restart ssh

Étape 3 — fail2ban

apt install -y fail2ban

# /etc/fail2ban/jail.local
[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5
backend  = systemd

[sshd]
enabled = true
port    = 22
maxretry = 3

systemctl restart fail2ban
fail2ban-client status sshd

Étape 4 — UFW comme deuxième barrière

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable
ufw status verbose

Étape 5 — Mises à jour automatiques

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# Décommenter la ligne security dans
# /etc/apt/apt.conf.d/50unattended-upgrades

systemctl status unattended-upgrades

Étape 6 — Audit Lynis

apt install -y lynis
lynis audit system

# Voir les recommandations dans le rapport
ss -tulpn | grep LISTEN
ps aux | awk '$1=="root"'

Étape 7 — Surveillance et alertes

• fail2ban envoie des emails sur ban
• Hetzner Cloud Monitoring avec alertes email
• Uptime Kuma auto-hébergé pour HTTP checks
• auditd sur fichiers sensibles si conformité requise

Configuration Terraform

resource "hcloud_firewall" "web_public" {
  name = "web-public"

  rule {
    direction  = "in"
    protocol   = "tcp"
    port       = "22"
    source_ips = ["MA_IP_FIXE/32", "10.0.0.0/8"]
  }

  rule {
    direction  = "in"
    protocol   = "tcp"
    port       = "80"
    source_ips = ["0.0.0.0/0", "::/0"]
  }

  rule {
    direction  = "in"
    protocol   = "tcp"
    port       = "443"
    source_ips = ["0.0.0.0/0", "::/0"]
  }
}

Erreurs fréquentes

Sur le même thème

• Guide Hetzner Cloud Afrique
• Snapshots Hetzner
• Tailscale VPN
• Documentation Hetzner Firewall : docs.hetzner.com/cloud/firewalls

Etape 1 : Comprendre la difference entre firewall Cloud et iptables sur le VPS

Hetzner Cloud Firewall est un firewall stateless applique en amont du VPS, au niveau de l’hyperviseur. Il bloque le trafic AVANT qu’il atteigne votre instance, ce qui economise CPU et bande passante par rapport a iptables ou ufw qui filtrent une fois le paquet recu. Pour un freelance basant son infra a Helsinki ou Falkenstein, c’est la premiere ligne de defense, gratuite et incluse dans tous les plans Hetzner Cloud.

Le firewall iptables/ufw reste utile en complement pour des regles fines (rate limiting, blocage IP precis, journalisation), mais ne remplace pas le firewall Hetzner. Activez les deux en defense en profondeur, jamais l’un OU l’autre, sauf cas tres specifique de developpement local.

Etape 2 : Acceder a la console Hetzner Cloud et creer un firewall

Connectez-vous sur console.hetzner.cloud avec votre compte. Selectionnez votre projet, puis le menu lateral ‘Firewalls’. Cliquez ‘Create Firewall’, donnez-lui un nom parlant comme fw-prod-dakar-web. Hetzner ne facture pas le firewall lui-meme, vous pouvez en creer autant que vous voulez sans surcout sur la facture mensuelle.

Le nom doit refleter l’environnement (prod/staging) et le role (web/db/mail). Sur un projet a 10 VPS pour 3 clients differents, cette nomenclature evite les erreurs de routage qui ouvriraient une base de donnees au public par accident.

Etape 3 : Definir les regles inbound minimales pour un serveur web

Un serveur web public a besoin de seulement 3 ports ouverts en entree : SSH (22 ou un port custom), HTTP (80) et HTTPS (443). Tout le reste doit rester ferme par defaut. C’est la regle d’or qui ferme 90 % des vecteurs d’attaque automatises.

SSH: TCP 22 source 0.0.0.0/0 (ou mieux: votre IP fixe seulement) HTTP: TCP 80 source 0.0.0.0/0 HTTPS: TCP 443 source 0.0.0.0/0

Si votre IP residentielle est statique (verifiez avec curl ifconfig.me), restreignez SSH a cette IP unique. Si vous travaillez en deplacement entre Dakar et Abidjan avec une IP dynamique, gardez 0.0.0.0/0 mais activez fail2ban et passez le SSH sur un port haut comme 2222 pour reduire le bruit des scanners.

Etape 4 : Bloquer ICMP ou pas, le faux debat

Beaucoup de tutoriels recommandent de bloquer ICMP pour ‘masquer’ le serveur. C’est une fausse bonne idee : Shodan et Censys decouvrent votre IP via les scans de ports, pas via ping. Bloquer ICMP casse les outils de debug legitimes (traceroute, MTU discovery) sans gagner en securite. Laissez ICMP autorise en entree depuis 0.0.0.0/0.

ICMP: source 0.0.0.0/0 description 'Allow ping for debug'

Cette regle vous permet de tester depuis n’importe ou si le serveur repond. Si vous constatez du flood ICMP, traitez-le avec un rate limit iptables sur le VPS plutot que de tout bloquer au niveau Hetzner.

Etape 5 : Configurer les regles outbound pour limiter l exfiltration

Par defaut le firewall Hetzner autorise tout en sortie. Pour un serveur de production qui ne devrait jamais initier de connexion vers l’exterieur en dehors des updates et des appels API, restreignez les regles outbound :

TCP 80, 443 destination 0.0.0.0/0 (updates apt, npm, composer) TCP 25, 587 destination smtp.votre-relay.com (envoi mail) UDP 53 destination 0.0.0.0/0 (DNS) UDP 123 destination 0.0.0.0/0 (NTP)

Bloquez le reste. Si une faille type CVE-Log4Shell tente d’ouvrir une reverse shell sur le port 4444 vers une IP attaquante, le firewall Hetzner coupe la connexion AVANT qu’elle quitte votre VPS. Cette regle a sauve plusieurs PME ouest-africaines de fuites de donnees clients pendant les vagues d’exploitation 2024-2025.

Etape 6 : Appliquer le firewall a un ou plusieurs serveurs

Une fois les regles definies, allez dans l’onglet ‘Resources’ du firewall et cliquez ‘Apply to’. Selectionnez vos VPS un par un, ou utilisez les Labels Hetzner pour appliquer en masse. Sur un parc de 10 VPS, taggez chaque serveur avec un label role=web ou role=db, puis appliquez le firewall correspondant via le selecteur de labels.

hcloud server add-label web-01 role=web environment=prod

Sortie attendue : ‘Label added’. Le firewall associe au label role=web s’applique automatiquement. Si vous ajoutez un nouveau VPS avec ce label demain, il herite immediatement des regles sans manipulation supplementaire dans la console.

Etape 7 : Tester les regles depuis l exterieur

Apres application, testez chaque port depuis une machine externe (votre laptop a Dakar, ou un autre VPS de test). Utilisez nmap pour scanner les ports communs et verifier que seuls les ports autorises repondent.

nmap -p 22,80,443,3306,5432,6379,9200 IP_DU_VPS

Sortie attendue : SEULS 22, 80, 443 doivent apparaitre en ‘open’. Si vous voyez 3306 (MySQL), 5432 (Postgres), 6379 (Redis) ou 9200 (Elasticsearch) en ‘open’, vous avez une fuite : ces services doivent ecouter sur 127.0.0.1 ou etre derriere un VPN, jamais exposes publiquement.

Etape 8 : Surveiller les tentatives bloquees et ajuster

Hetzner ne fournit pas de logs detailles du firewall Cloud (limitation connue). Pour traquer les tentatives bloquees, activez les logs iptables sur le VPS en parallele : meme si le paquet a ete drop par Hetzner avant d’arriver, vos applications sur les ports ouverts loggeront les requetes anormales.

tail -f /var/log/auth.log | grep 'Failed password'

Cette commande montre en temps reel les tentatives d’authentification SSH echouees. Si vous voyez plus de 10 tentatives par minute depuis une meme IP, ajoutez-la a une regle inbound deny dans le firewall Hetzner pour la bloquer en amont, ce qui economise CPU sur fail2ban.

Etape 9 : Cas pratique : firewall pour un cluster WordPress + base de donnees

Pour une stack WordPress sur 2 VPS (web + db), creez 2 firewalls distincts. Le firewall web autorise 22, 80, 443 depuis Internet. Le firewall db autorise UNIQUEMENT 22 depuis votre IP admin et le port MySQL/Postgres depuis l’IP privee du VPS web (via le reseau prive Hetzner). Cette segmentation empeche un compromis du serveur web de pivoter directement vers la base.

Voir aussi notre categorie Securite et la section DevOps dans la continuité sur le hardening Linux et la mise en place de bastions SSH.

Etape 10 : Automatiser la gestion via le CLI hcloud

Pour un usage avance, le CLI hcloud permet de scripter creation, modification et application des firewalls. Versionnez les regles dans un repo Git et appliquez-les via un job CI : vous ne risquez plus la regression d’une modification manuelle a 22h sur la console web qui ouvre par erreur un port critique.

hcloud firewall create --name fw-prod --rules-file rules.json; hcloud firewall apply-to-resource fw-prod --type label_selector --label-selector role=web

Sortie attendue : ‘Firewall created’ puis ‘Firewall applied’. Conservez le fichier rules.json dans Git, taggez chaque modification, et imposez une review obligatoire avant merge sur la branche main qui declenche le deploiement.

Etape 11 : Combiner Hetzner Firewall avec un bastion SSH

Pour un parc multi-VPS, deployez un VPS bastion minimal (CX11 a 3,29 EUR/mois soit 2 158 FCFA) qui sert de point d’entree SSH unique. Le firewall Hetzner des autres VPS autorise SSH UNIQUEMENT depuis l’IP du bastion. Vous reduisez la surface d’attaque a une seule machine durcie au lieu de 10, et vous pouvez activer MFA SSH (TOTP via google-authenticator-libpam) sur le seul bastion.

SSH inbound rule: TCP 22 source IP_BASTION/32 description 'Bastion only'

Cette configuration impose le passage par le bastion via ssh -J bastion user@target. Si quelqu’un trouve un 0-day sur OpenSSH demain, le scanner cherchera a se connecter sur 0.0.0.0/0 mais ne touchera que le bastion, vous gagnez du temps pour patcher.

Etape 12 : Recap et erreurs frequentes a eviter

Trois erreurs reviennent regulierement. Premiere : oublier d’autoriser ICMP en sortie, ce qui casse les health checks Hetzner Load Balancer. Deuxieme : restreindre SSH a une IP residentielle dynamique sans plan B, et se bloquer dehors apres un changement d’IP du FAI. Troisieme : croire que le firewall Hetzner suffit et negliger les regles iptables sur le VPS, qui restent indispensables pour le rate limiting fin et le blocage applicatif.

Reprenez la checklist : firewall cree, regles inbound minimales (22, 80, 443, ICMP), regles outbound restrictives, labels appliques, tests nmap depuis l’exterieur, fail2ban actif sur le VPS, IP residentielle de secours documentee. Cette routine en 7 points vous met au-dessus de 95 % des deploiements VPS qu’on audite chez nos clients ouest-africains.

Etape 13 : Migrer un parc OVH vers Hetzner Firewall sans coupure

Si vous quittez OVH (dont le firewall Network reste payant en option) pour Hetzner Cloud, planifiez la migration en deux temps. D’abord recreez les VPS chez Hetzner avec firewall preconfigure et basculez le DNS avec un TTL court (300 secondes) pour propager rapidement. Ensuite testez le trafic reel pendant 48 heures sur la nouvelle infrastructure avant de couper definitivement les anciens serveurs OVH. Cette approche protege les visiteurs ouest-africains sans subir de fenetre d’indisponibilite, particulierement critique pour un site e-commerce qui encaisse via Wave ou Mixx by Yas.

Etape 14 : Documenter les regles pour un audit ou une passation

Tenez un document partage (Notion, GitBook, README dans le repo Terraform) qui liste pour chaque firewall : son nom, ses regles, les VPS associes, la justification metier de chaque port ouvert, et la date de derniere revue. Lorsqu’un nouveau collaborateur reprend l’infrastructure ou qu’un audit RGPD vous demande la liste des controles d’acces, vous avez la reponse en 5 minutes au lieu de 5 jours de retro-ingenierie de la console Hetzner.

Etape 15 : Revue trimestrielle des regles

Bloquez 30 minutes chaque trimestre pour relire les regles firewall. Supprimez les autorisations devenues obsoletes (anciens IPs developpeur, ports d’un service deprecate), resserrez celles qui peuvent l’etre, et testez a nouveau avec nmap. Cette discipline simple maintient la posture de securite dans le temps et evite la derive entropique qui transforme un firewall propre en passoire en 18 mois.