Renforcement de SSH : Fail2Ban, Nftables et pare-feu cloud

Introduction

Renforcement SSH signifie réduire la surface d'attaque de votre service SSH grâce à la configuration, la limitation des taux et les contrôles réseau afin que les attaques par force brute et les accès non autorisés soient atténués. Fail2Ban seul ne suffit pas : il réagit après des tentatives de connexion échouées et modifie le pare-feu de l'hôte. Il ne remplace pas un pare-feu, ne restreint pas les adresses IP pouvant accéder à SSH dès le départ, et ne protège pas plusieurs serveurs via un point d'entrée unique. La défense en profondeur pour SSH combine le renforcement au niveau de l'hôte (configuration SSH, Fail2Ban, nftables) avec les contrôles au niveau du réseau (pare-feu Cloud Linux-Console.net) et un hôte bastion afin que SSH ne soit exposé que là où vous le souhaitez. Ce tutoriel s'appuie sur le contenu existant de Linux-Console.net : pour la protection SSH uniquement avec Fail2Ban, voir Comment protéger SSH avec Fail2Ban sur Ubuntu ; ici, vous obtenez l'ensemble complet : SSH renforcé, Fail2Ban, nftables, pare-feu Cloud et bastion sur Linux-Console.net.

Points clés

• Edge Cloud Firewall restreint qui peut accéder à SSH à la périphérie du réseau ; nftables limite le débit et filtre le trafic sur l'hôte ; Fail2Ban bannit les adresses IP après des échecs d'authentification répétés en ajoutant des règles au pare-feu. Ensemble, ils vous offrent un contrôle à la périphérie, une limitation au niveau du noyau et une prévention réactive des intrusions.
• Les combiner vous donne une défense en profondeur: les IP inconnues sont bloquées par le pare-feu cloud, celles abusives sont limitées en débit ou supprimées par nftables, et les récidivistes sont bannis par Fail2Ban, de sorte qu'aucune couche unique ne supporte toute la charge.
• Utilisez sshd_config pour désactiver les connexions root et par mot de passe et pour imposer l'authentification par clé SSH ; utilisez nftables pour limiter les nouvelles connexions SSH par source et bloquer les paquets invalides ; utilisez Fail2Ban pour surveiller les journaux d'authentification et insérer des règles de bannissement ; utilisez le pare-feu cloud pour autoriser SSH uniquement depuis des IP ou CIDR de confiance.
• Ce modèle convient aux serveurs de production, aux environnements multi-hôtes et à tout système qui expose SSH à Internet et doit résister aux attaques par force brute et réduire la surface d'attaque.
• Pour la production, utilisez un hôte bastion avec ProxyJump sur un VPC afin qu'un seul hôte ait un SSH public ; associez-le aux pare-feux Cloud de Linux-Console.net pour la liste blanche des périphériques et maintenez le port SSH cohérent dans sshd_config, Fail2Ban, nftables et les règles de pare-feu.

Prérequis

Avant de commencer, vous avez besoin de :

• Deux Droplets Ubuntu 22.04 avec au moins 1 Go de RAM chacun, créés à l'intérieur du même VPC. Créez un VPC via le panneau de contrôle (Networking → VPC → Create VPC Network) ou suivez la procédure Comment créer un VPC. Un Droplet servira de serveur bastion et l'autre de serveur d'application. Si vous souhaitez uniquement sécuriser un seul serveur sans la configuration bastion de l'étape 5, un Droplet suffit.
• Un utilisateur non-root avec des privilèges sudo sur chaque Droplet. Suivez la configuration initiale du serveur avec Ubuntu 22.04 pour créer cet utilisateur.
• Authentification par clé SSH configurée pour votre utilisateur non root sur chaque Droplet. Suivez Comment Configurer les Clés SSH sur Ubuntu 22.04. Vous désactiverez l'authentification par mot de passe à l'Étape 1, donc la connexion par clé doit fonctionner avant de commencer.
• Un compte Linux-Console.net avec accès à la documentation du pare-feu cloud de Linux-Console.net.

Défense en profondeur pour la sécurité SSH

La défense en profondeur pour SSH signifie superposer des contrôles afin qu'une seule défaillance n'accorde pas l'accès : démon SSH renforcé (clés seulement, pas de root), prévention d'intrusion (Fail2Ban), pare-feu hôte (nftables) et pare-feu cloud. La protection contre les attaques par force brute seule est insuffisante : les attaquants peuvent faire tourner les IP sur des centaines de fournisseurs cloud et de proxys résidentiels, contournant ainsi les interdictions sur une seule IP. La sécurité SSH en couches combine la robustesse de l'authentification, la limitation du débit, l'interdiction réactive et la segmentation réseau.

Comment fonctionne Fail2Ban

Fail2Ban analyse les journaux de services (par exemple, auth.log pour SSH), correspond les lignes avec un filtre (regex dans filter.d/sshd), et lorsque les échecs dépassent un seuil dans une fenêtre temporelle, il exécute une action. Consultez notre guide de configuration Fail2Ban pour SSH pour plus de détails ; pour une configuration étape par étape de Fail2Ban sur SSH, consultez le guide de configuration Fail2Ban SSH sur Ubuntu. L'action consiste typiquement à ajouter une règle au pare-feu de l'hôte (le backend pour les actions de bannissement est iptables ou nftables). Donc : analyse des journaux → correspondance du filtre → compteur de prison → action (par exemple, bannir l'IP dans le pare-feu). Le port protégé est celui que vous configurez pour la prison (par exemple, 22 pour SSH). Fail2Ban ne remplace pas le pare-feu ; il pilote les règles du pare-feu en fonction des événements du journal.

nftables contre iptables

Utilisez nftables pour les nouvelles installations sur Ubuntu lorsque vous souhaitez un seul jeu de règles et une limitation de débit intégrée. Pour des informations de base sur le fonctionnement des pare-feu hôtes (règles, chaînes, politiques), voir Comment fonctionne le pare-feu Iptables et Choisir une politique de pare-feu efficace pour sécuriser vos serveurs. Pour un pare-feu hôte basé sur UFW au lieu de nftables, voir Comment configurer un pare-feu avec UFW sur Ubuntu.

Pare-feu Cloud vs Pare-feu Hôte

Un pare-feu cloud (par exemple, Linux-Console.net) est appliqué à la périphérie du réseau avant que le trafic n'atteigne le Droplet. Il peut autoriser SSH uniquement depuis des IP de confiance et bloquer tout le reste. Un pare-feu hôte (nftables/iptables) fonctionne sur le Droplet et peut limiter le taux et bloquer le trafic par connexion. Le pare-feu cloud bloque les scans à la périphérie du réseau avant qu'ils n'utilisent les ressources du Droplet ; le pare-feu hôte applique des limites de taux par connexion et des blocages réactifs.

Hôtes Bastion pour l'accès SSH

Utilisez un hôte bastion (serveur jump) lorsque vous avez plusieurs serveurs et souhaitez un point d'entrée SSH renforcé. Le bastion dispose d'un SSH public ; les serveurs internes sont accessibles via ProxyJump. Cela réduit la surface d'attaque et simplifie les pare-feu Cloud : seul le bastion permet le SSH depuis Internet.

Maintenant que vous comprenez chaque composant et quand utiliser une architecture bastion, examinons comment ces couches fonctionnent ensemble dans un déploiement en production.

Aperçu de l'architecture

Un modèle en couches prêt pour la production ressemble à ceci :

Internet
   ↓
Linux-Console.net Cloud Firewall (SSH only from trusted IPs)
   ↓
Bastion Host (Public SSH)
   ↓
Private VPC Network
   ↓
Application Droplets (No public SSH; access via ProxyJump)

• Segmentation VPC : Seul le bastion dispose d'une IP publique pour SSH ; les Droplets de l'application utilisent des IP privées.
• Sécurité du bastion : Renforcer SSH, Fail2Ban et nftables sur le bastion ; restreindre le pare-feu Cloud aux IP de confiance.
• Routage IP privé : SSH vers le bastion, puis ProxyJump vers des IP privées.
• Accès zéro-confiance : Seuls les clients disposant de clés SSH valides qui atteignent le bastion peuvent accéder aux hôtes internes.

Avec l'architecture en tête, voyons comment cette approche de défense en profondeur protège contre de réelles attaques.

Scénario de sécurité réel

Lorsqu'une attaque par force brute cible votre serveur, le Cloud Firewall bloque d'abord le trafic provenant de plages d'IP non fiables au niveau du réseau. Si le trafic atteint le bastion, nftables applique des limites de taux de connexion au niveau du noyau. Si des échecs d'authentification répétés se produisent, Fail2Ban insère dynamiquement des règles de pare-feu pour bannir l'IP source. Les serveurs d'application restent inaccessibles depuis l'internet public car SSH n'est exposé que sur le bastion. Chaque couche contrôle une frontière différente : le Cloud Firewall contrôle quelles IP peuvent atteindre le port 22, nftables contrôle le taux de connexion par source, Fail2Ban contrôle les échecs d'authentification répétés et la configuration SSH contrôle la méthode d'authentification. Une seule mauvaise configuration dans une couche n'expose pas les autres.

Avec l'architecture en tête, implémentons chaque couche étape par étape, en commençant par la base : le durcissement du démon SSH lui-même.

Étape 1 — Renforcer la configuration SSH

Sur le serveur (bastion ou hôte unique), éditez /etc/ssh/sshd_config :

Ajoutez les lignes de configuration explicites suivantes :

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
PubkeyAuthentication yes

Avant de redémarrer SSH, validez la configuration :

sudo sshd -t

Cette commande ne devrait produire aucune sortie. Si elle affiche une erreur, corrigez la configuration avant de redémarrer le service.

• Définissez PermitRootLogin no pour désactiver la connexion root.
• Définissez PasswordAuthentication no pour imposer uniquement l'authentification par clé SSH.
• Optionnellement, définissez Port sur un port non par défaut (par exemple, 2222).

L'utilisation d'un port SSH non par défaut peut réduire le nombre de scans automatisés contre votre serveur. Cependant, vous devrez ouvrir le nouveau port à la fois dans le pare-feu cloud et dans nftables. De nombreux administrateurs choisissent de conserver le port 22 et de compter sur les clés SSH et les pare-feu pour la sécurité à la place.

Si vous changez le port SSH, mettez-le à jour dans les quatre endroits :

1. /etc/ssh/sshd_config (Port 2222)
2. Prison Fail2Ban (port=2222)
3. règle nftables (tcp dport 2222 ...)
4. Règle entrante du pare-feu cloud Linux-Console.net (TCP 2222 depuis des IP fiables)

Redémarrez SSH et vérifiez dans une seconde session avant de fermer la première :

sudo systemctl restart ssh   # on some distros: sudo systemctl restart sshd

En cas de succès, il n'y a pas de sortie (ou un bref « Job for ssh.service has finished »). Si la commande échoue, corrigez sshd_config avant de vous déconnecter.

Vérifiez que l'authentification par mot de passe est désactivée en tentant une connexion avec mot de passe depuis une autre machine. La connexion devrait échouer avec une erreur d'autorisation refusée. Gardez votre session originale ouverte jusqu'à ce que la connexion par clé soit confirmée.

Si vous utilisez un port non par défaut, connectez-vous avec ssh -p 2222 user@host. Assurez-vous que votre utilisateur sudo peut se connecter avec des clés avant de désactiver les mots de passe.

Étape 2 — Installer et configurer Fail2Ban

Installer Fail2Ban :

sudo apt update && sudo apt install -y fail2ban

Exemple de sortie (abrégé) :

Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  fail2ban python3-systemd
...
Setting up fail2ban ...

Créez un fichier de remplacement de prison locale afin que les mises à jour puissent toujours améliorer les paramètres par défaut :

sudo nano /etc/fail2ban/jail.local

Sous [DEFAULT], définissez ou ajustez :

• bantime : durée du bannissement (par ex., 1h).
• findtime : fenêtre dans laquelle les échecs sont comptés (par exemple, 10m).
• maxretry : échecs dans cette fenêtre qui déclenchent une interdiction (par exemple, 5).
• ignoreip : IP/CIDR jamais bannis (par exemple, l'adresse IP de votre bureau).

Activez la prison SSH et définissez le port si vous l'avez modifié :

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 1h

Si SSH fonctionne sur un port non standard, définissez port=2222 (ou votre port). Redémarrez et vérifiez le statut :

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Exemple de sortie lorsque la prison est active et qu'aucune IP n'est encore bannie :

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

Provoquez une interdiction depuis un autre hôte et confirmez l'IP dans fail2ban-client status sshd. Fail2Ban n'est pas un pare-feu : il utilise un backend (iptables ou nftables) pour insérer des règles ; le port protégé est le port de la prison (par exemple, ssh ou 2222).

Vérification de l'intégration de Fail2Ban avec nftables

Confirmez quel backend Fail2Ban utilise :

sudo fail2ban-client get sshd banaction

Si vous utilisez nftables, assurez-vous que l'action de bannissement est compatible (par exemple, nftables-multiport). Ensuite, vérifiez que les IP interdites apparaissent dans l'ensemble de règles actif :

sudo nft list ruleset

Si les interdictions fonctionnent, vous devriez voir une chaîne Fail2Ban référencée dans le jeu de règles (souvent nommée comme f2b-sshd) et l'IP bannie listée dans cette chaîne.

Si vous ne voyez aucune chaîne Fail2Ban dans nft list ruleset, définissez une action de bannissement compatible et redémarrez Fail2Ban :

[sshd]
banaction = nftables-multiport

Puis redémarrez et vérifiez à nouveau :

sudo systemctl restart fail2ban
sudo nft list ruleset

Étape 3 — Configurer nftables pour la limitation de débit et le filtrage

Installez nftables et désactivez les pare-feux conflictuels (par exemple, ufw) si présents :

sudo apt install -y nftables
sudo systemctl enable --now nftables

Pour renforcer la sécurité SSH et protéger votre serveur contre les attaques par force brute et le trafic indésirable, vous pouvez utiliser nftables pour le filtrage des paquets au niveau du noyau et la limitation du débit. L'ensemble de règles ci-dessous, placé dans /etc/nftables.conf, permet tout le trafic établi et local, supprime les paquets invalides, applique une limitation du débit sur les nouvelles connexions SSH, et peut éventuellement autoriser ICMP (ping). Remplacez <SSH_PORT> par votre port SSH si celui-ci est différent du port par défaut (22).

#!/usr/sbin/nft -f
flush ruleset

table inet filter {

  chain input {
    type filter hook input priority 0; policy drop;

    iif lo accept
    ct state established,related accept
    ct state invalid drop

    # Allow SSH with per-source rate limiting (IPv4)
    ip protocol tcp tcp dport <SSH_PORT> ct state new meter ssh4_per_src { ip saddr limit rate 5/minute burst 10 packets } accept

    # Allow SSH with per-source rate limiting (IPv6)
    ip6 nexthdr tcp tcp dport <SSH_PORT> ct state new meter ssh6_per_src { ip6 saddr limit rate 5/minute burst 10 packets } accept
    # Optional: allow ICMP (ping)
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
  }

  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Charger et persister :

sudo nft -f /etc/nftables.conf

Aucune sortie en cas de succès. Ensuite, vérifiez le jeu de règles actif :

sudo nft list ruleset

Exemple de sortie (abrégé) :

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop
    iif "lo" accept
    ct state established,related accept
    ct state invalid drop
    tcp dport 22 ct state new limit rate 5/minute burst 10 packets accept
    ...
  }
  ...
}

Vous devriez voir policy drop sur la chaîne d'entrée et une règle d'acceptation explicite tcp dport <SSH_PORT>. Si vous avez changé le SSH pour 2222, mettez à jour <SSH_PORT> en conséquence avant de charger l'ensemble de règles.

Test depuis un autre hôte pour confirmer que les connexions SSH au-dessus du taux défini sont supprimées. Si vous perdez l'accès, utilisez la console du fournisseur pour vider temporairement les règles :

sudo nft flush ruleset

Sur Ubuntu, nftables charge généralement /etc/nftables.conf au démarrage. Si Fail2Ban utilise nftables, assurez-vous que ses chaînes s'intègrent à cette table afin que les interdictions et la limitation de débit fonctionnent ensemble.

Mesures de sécurité (À quoi s'attendre)

En pratique, chaque couche se comporte approximativement de la manière suivante afin que vous puissiez vérifier et ajuster :

• Fail2Ban : Ajoute généralement une règle de blocage en 2 à 5 secondes après le nombre de tentatives échouées configuré dans findtime. L'adresse IP bannie est bloquée par le pare-feu de l'hôte pendant bantime.
• Limite de débit nftables : Avec une limite de 5/minute et un burst de 10, une seule source peut ouvrir au maximum environ 10 nouvelles connexions SSH dans une courte période avant que les nouvelles connexions soient rejetées jusqu'à ce que la fenêtre de débit se réinitialise. Cela réduit le nombre de tentatives de connexion qu'une adresse IP peut effectuer avant que Fail2Ban ne détecte les échecs.
• Pare-feu Cloud : Le trafic provenant d’IP non autorisées est bloqué à la périphérie ; il n’atteint jamais le Droplet, il ne consomme donc pas de CPU et n’apparaît pas dans les journaux de l’hôte. Seules les IP figurant dans votre liste d’autorisations peuvent tenter une connexion SSH.

Ce sont des comportements typiques ; le moment exact dépend de vos paramètres findtime, maxretry et de limitation de débit.

Étape 4 — Configurer le pare-feu cloud de Linux-Console.net

Créez un pare-feu Cloud via le panneau de contrôle (Créer → Pare-feux Cloud), l'API ou le CLI ; consultez Comment créer des pare-feux pour toutes les options. Pour le scripting ou de nombreux Droplets, vous pouvez utiliser doctl ou l'API pour gérer les règles. Ensuite, attachez le pare-feu à votre bastion (ou Droplet unique) :

• Entrant : Autoriser SSH (TCP 22, ou votre port personnalisé) uniquement à partir de IPs ou plages de confiance. Refuser tout autre trafic entrant.
• Sortant : Autoriser ce dont l'hôte a besoin (par exemple, HTTP/HTTPS, trafic VPC).

Attachez le pare-feu uniquement au bastion afin que SSH ne soit exposé qu'à un seul point. Le pare-feu cloud est appliqué à la frontière du réseau avant que le trafic n'atteigne le Droplet. Utilisez-le pour autoriser SSH uniquement depuis le bureau/VPN afin que les adresses IP inconnues n'atteignent jamais le port 22.

Modèle de règle recommandé

Pour l'hôte bastion :

• SSH entrant : Autoriser TCP 22 (ou votre port personnalisé) uniquement depuis votre adresse IP publique ou le CIDR de votre VPN.
• Trafic entrant autre : Refuser.
• Sortant : Autoriser l'accès Internet requis et le trafic VPC.

Pour les Droplets d'application :

• SSH entrant : Autoriser uniquement depuis l'adresse IP privée du bastion ou la plage CIDR du VPC.
• Aucun accès SSH public depuis Internet.

• Sortant : Autoriser le trafic des services requis (par exemple, accès à la base de données ou à l'API).

  

Après avoir appliqué le pare-feu, confirmez la connectivité :

1. Depuis une IP autorisée, SSH devrait réussir.
2. Depuis une IP non autorisée, la connexion TCP devrait expirer (ne pas demander d'identifiants).

Cela confirme que le filtrage est appliqué à la périphérie du réseau.

Étape 5 — Tester la défense en couches

Exécutez ces vérifications afin de confirmer que chaque couche applique des contrôles :

1. Pare-feu cloud (filtrage en périphérie) : Depuis une IP non autorisée, tentez un SSH vers le bastion. La connexion TCP devrait expirer (pas de bannière SSH).
2. Renforcement SSH (clé uniquement) : Depuis une IP autorisée, tentez une connexion par mot de passe. Cela devrait échouer avec Permission denied.
3. nftables (limitation du débit) : Depuis une IP autorisée, ouvrir rapidement de nombreuses nouvelles connexions SSH. Après la rafale, les nouvelles connexions doivent être rejetées ou retardées.

4. Fail2Ban (interdictions réactives) : Depuis une IP autorisée, échouez délibérément l'authentification jusqu'à ce que maxretry soit dépassé, puis confirmez l'interdiction :

   • sudo fail2ban-client status sshd montre l'adresse IP parmi les adresses bannies
   • sudo nft list ruleset affiche l'IP dans la chaîne Fail2Ban (pour les backends nftables)

Si une étape ne correspond pas au comportement attendu, utilisez la section Dépannage pour isoler la couche qui n’applique pas correctement.

Étape 6 — Mettre en œuvre le modèle Bastion (serveur de saut)

Pour la production, supprimez l'exposition des IP publiques des serveurs d'application. Placez-les dans un VPC avec uniquement des IP privées (ou avec un pare-feu Cloud qui n'autorise aucun SSH entrant depuis Internet). Utilisez le bastion comme serveur de saut.

Sur votre machine locale, ajoutez à ~/.ssh/config :

Host bastion
  HostName <BASTION_PUBLIC_IP>
  User your_bastion_user
  IdentityFile ~/.ssh/id_ed25519

Host app-server-1
  HostName 10.0.0.5
  User app_user
  ProxyJump bastion
  IdentityFile ~/.ssh/id_ed25519

Ensuite, ssh app-server-1 se connecte via le bastion à l’IP privée du serveur d’application. Seul le bastion a SSH ouvert sur Internet ; le serveur d’application ne l’a pas. Cela réduit la surface d’attaque et est standard en production et dans les environnements réglementés.

Dépannage

• Fail2Ban ne bloque pas : Vérifiez logpath et filter=sshd ; assurez-vous que la prison est activée et que fail2ban-client status sshd affiche la prison. Utilisez backend=systemd avec logpath provenant de journalctl si les logs sont dans le journal.
• Mauvaise configuration de la prison : Exécutez fail2ban-client -t ; assurez-vous que port correspond à SSH et que le backend (iptables/nftables) est installé.
• nftables ne persiste pas : Mettez les règles dans /etc/nftables.conf et activez le service nftables.
• Blocage SSH : Gardez une deuxième session ouverte jusqu'à ce que la connexion par clé fonctionne. Utilisez la console de récupération du fournisseur pour corriger sshd_config ou le pare-feu.
• Le pare-feu cloud vous bloque : Ajoutez votre IP ou VPN aux sources SSH autorisées du pare-feu.
• Échec de ProxyJump : Confirmez que le bastion est accessible et peut atteindre l’IP privée de la cible (le routage VPC et le pare-feu le permettent).

Questions Fréquemment Posées

Qu'est-ce que la défense en profondeur pour la sécurité SSH ?
Combiner plusieurs contrôles : SSH renforcé (uniquement avec des clés, pas de root), Fail2Ban, pare-feu hôte (nftables) et pare-feu Cloud. Aucune couche unique n'est utilisée seule.

Fail2Ban est-il un pare-feu ?
Non. Fail2Ban surveille les journaux et demande au pare-feu de l'hôte (iptables ou nftables) d'ajouter ou de supprimer des règles. Il ne filtre pas les paquets lui-même ; c'est le pare-feu qui le fait. Vous avez donc besoin à la fois d'un pare-feu et de Fail2Ban (ou d'un outil similaire) pour des interdictions réactives.

Fail2Ban suffit-il à sécuriser SSH ?
Non. Fail2Ban réagit aux tentatives de connexion échouées et ajoute des règles de pare-feu ; il ne remplace pas un pare-feu ni ne limite qui peut accéder au port 22. Utilisez-le avec le renforcement de SSH, un pare-feu sur l’hôte, et (en production) un pare-feu Cloud et une bastion.

Devrais-je utiliser un hôte bastion pour l'accès SSH ?
Oui pour la production lorsque vous avez plusieurs serveurs. Un serveur de saut unique avec SSH public réduit la surface d'attaque et vous permet de restreindre les pare-feux Cloud à un seul hôte ; les serveurs internes sont accessibles via ProxyJump sur le VPC.

Quelle est la différence entre nftables et iptables ?
nftables est le filtre de paquets moderne avec un seul ensemble de règles et une limitation native du débit ; iptables est hérité. Les deux fonctionnent comme backend de Fail2Ban ; nftables est préféré sur Ubuntu et les systèmes similaires.

Comment les pare-feu cloud Linux-Console.net améliorent-ils la sécurité SSH ?
Ils permettent le SSH uniquement à partir d'IPs de confiance à la périphérie du réseau ; le reste du trafic est bloqué avant d'atteindre le Droplet, réduisant ainsi les attaques par force brute et les scans.

Puis-je désactiver l'authentification par mot de passe SSH en toute sécurité ?
Oui, après avoir configuré l'authentification par clé SSH et vérifié la connexion dans une deuxième session. Ensuite, définissez PasswordAuthentication no et redémarrez SSH pour empêcher les attaques par force brute sur les mots de passe.

Quels ports doivent être ouverts pour un accès SSH sécurisé ?
TCP 22 (ou le port de votre choix). Ouvrez-le uniquement aux IP fiables dans le pare-feu Cloud ; sur l'hôte, nftables limite le débit et Fail2Ban bannit les IP abusives.

Comment un VPC améliore-t-il la sécurité des serveurs ?
Les serveurs d'application se trouvent sur un réseau privé sans SSH public ; seul le bastion dispose d'un SSH public. L'accès interne se fait via le bastion sur des IP privées, réduisant l'exposition et permettant un accès zéro confiance.

Conclusion

La sécurité SSH en couches (configuration renforcée, Fail2Ban, nftables, pare-feu Cloud et bastion) offre une défense en profondeur prête pour la production. Traitez SSH comme une infrastructure critique : utilisez le modèle bastion avec des pare-feu hôte et cloud, et maintenez l'authentification par clé et l'absence de connexion root comme base.

Prochaines étapes et ressources connexes

Tutoriels Communautaires de Linux-Console.net :

• Comment protéger SSH avec Fail2Ban sur Ubuntu 20.04 : protection SSH uniquement avec Fail2Ban ; ce tutoriel ajoute nftables, Cloud Firewall et bastion.
• Comment Fail2Ban fonctionne pour protéger les services sur un serveur Linux : comment Fail2Ban filtre les journaux et déclenche des actions.
• Comment fonctionne le pare-feu Iptables : Concepts de pare-feu (règles, chaînes, politiques) ; s'applique à nftables.
• Comment choisir une politique de pare-feu efficace pour sécuriser vos serveurs : rejet par défaut vs acceptation, abandon vs rejet.
• Comment sécuriser l'infrastructure de serveur Web avec les pare-feu cloud de Linux-Console.net en utilisant Doctl : créer et gérer des pare-feu cloud depuis la ligne de commande.
• Comment configurer un pare-feu avec UFW sur Ubuntu : Pare-feu hôte avec UFW (alternative à nftables).

Documentation Linux-Console.net :

• Comment créer des pare-feu : panneau de contrôle, CLI et API.
• Comment créer un VPC : création de VPC pour les serveurs bastion et les serveurs d'applications privés.

Configuration du serveur et SSH :

• Configuration initiale du serveur avec Ubuntu 22.04
• Comment configurer l'authentification par clé SSH sur un serveur Linux
• Comment configurer des clés SSH sur Ubuntu 22.04

Merci d'apprendre avec la communauté Linux-Console.net.