Comment configurer un pare-feu Linux avec UFW et nftables sur un VPS

17 min de lecture·Matthieu·vpssecuritylinuxfirewallnftablesufw|

Configurez un pare-feu en mode deny-by-default sur votre VPS Linux avec UFW ou nftables. Deux outils, un seul objectif : seuls les ports que vous autorisez restent ouverts.

Un VPS fraîchement provisionné n'a aucune règle de pare-feu. Tous les ports sont ouverts. Les scanners automatisés trouveront votre serveur quelques minutes après sa mise en ligne et commenceront à sonder SSH, tester des identifiants par défaut et chercher des services exposés. Un pare-feu en mode deny-by-default constitue la première couche de défense.

Ce tutoriel couvre deux outils :

  • UFW -- une interface simplifiée qui génère des règles de pare-feu à partir de commandes courtes. Idéal pour obtenir rapidement une base sécurisée.
  • nftables -- le framework natif de pare-feu Linux qui remplace iptables. Idéal pour les opérateurs qui ont besoin d'un contrôle granulaire, de compatibilité Docker ou de limitation de débit par IP.

Choisissez le chemin qui correspond à vos besoins. Les deux aboutissent au même résultat : un pare-feu deny-by-default vérifié où seuls les ports que vous autorisez explicitement sont accessibles.

Faut-il utiliser UFW ou nftables sur votre VPS ?

UFW est une interface simplifiée qui génère des règles iptables/nftables à partir de commandes courtes comme ufw allow 22. nftables est le framework natif de pare-feu Linux qui remplace iptables, avec des tables, des chaînes et des règles dans une syntaxe plus claire. UFW convient aux débutants qui veulent des paramètres par défaut rapides. nftables convient aux opérateurs qui ont besoin de limitation de débit avec des meters, de sets nommés ou de règles compatibles Docker.

Fonctionnalité UFW nftables
Courbe d'apprentissage Faible. Commandes en une ligne. Modérée. Structure table/chaîne/règle.
Installé par défaut sur Ubuntu (installé, inactif) Debian 12 (installé, config minimale)
Support IPv6 Automatique (dual-stack) Règles manuelles requises (famille inet)
Limitation de débit ufw limit (par règle) Meters avec suivi par IP
Compatible Docker Non. Docker contourne les règles UFW. Oui. nftables fonctionne avec la chaîne DOCKER-USER.
Persistance de la config Automatique avec ufw enable /etc/nftables.conf + systemd
Recommandé pour VPS mono-application, premier serveur Multi-services, hôtes Docker, production

Si vous utilisez Docker, évitez UFW ou lisez Docker contourne UFW : 4 solutions testées pour votre VPS pour le contournement. Docker manipule iptables directement et contourne UFW entièrement, exposant les ports des conteneurs sur internet même quand UFW indique qu'ils sont bloqués.

Prérequis

Avant de modifier les règles du pare-feu, vérifiez deux choses :

  1. Vous avez un accès SSH et il fonctionne. Vous êtes connecté à votre VPS en SSH en ce moment.
  2. Vous avez un accès console en secours. Le panneau de contrôle de votre hébergeur propose une console VNC ou série. Si vous perdez l'accès SSH, vous pouvez toujours atteindre le serveur via la console.

Ce tutoriel cible Ubuntu 24.04 et Debian 12. Les commandes fonctionnent sur les deux sauf mention contraire.

Vérifiez votre version d'OS :

cat /etc/os-release | grep PRETTY_NAME

Sortie attendue :

PRETTY_NAME="Ubuntu 24.04.4 LTS"

ou

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

Comment configurer UFW sur Ubuntu 24.04 ?

UFW est installé par défaut sur Ubuntu 24.04 mais inactif. Sur Debian 12, installez-le d'abord :

apt update && apt install -y ufw

Vérifiez le statut actuel :

ufw status

Sortie attendue :

Status: inactive

Comment activer le mode deny-by-default avec UFW ?

Définissez les politiques par défaut pour rejeter tout le trafic entrant, puis autorisez explicitement uniquement les ports dont vos services ont besoin. Avec UFW : définissez les valeurs par défaut, autorisez SSH, puis activez. L'ordre compte. Si vous activez UFW avant d'autoriser SSH, vous vous verrouillez dehors.

Définissez les politiques par défaut :

ufw default deny incoming
ufw default allow outgoing

Cela indique à UFW de rejeter toutes les connexions entrantes par défaut et d'autoriser toutes les sortantes. Votre serveur peut toujours accéder à internet (pour les mises à jour, le DNS, etc.) mais rien de l'extérieur n'entre sans règle explicite.

Comment autoriser SSH sans se verrouiller dehors ?

Autorisez SSH avant d'activer UFW. C'est l'étape la plus importante :

ufw allow 22/tcp comment 'SSH'

Si vous avez changé votre port SSH (par ex. en 2222), utilisez ce numéro de port à la place.

Activez maintenant UFW :

ufw enable

Vous verrez :

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Votre session SSH actuelle reste active. UFW ajoute la règle d'autorisation avant l'activation, les connexions existantes ne sont donc pas coupées.

Vérifiez les règles :

ufw status verbose

Sortie attendue :

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                   # SSH
22/tcp (v6)                ALLOW IN    Anywhere (v6)              # SSH

Observez : les règles IPv4 et IPv6 apparaissent toutes les deux. UFW crée automatiquement des règles dual-stack quand IPV6=yes est défini dans /etc/default/ufw (le réglage par défaut sur Ubuntu 24.04).

Comment autoriser le trafic web avec UFW ?

Si votre VPS fait tourner un serveur web, autorisez HTTP et HTTPS :

ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'

Vérification :

ufw status numbered

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere                   # SSH
[ 2] 80/tcp                     ALLOW IN    Anywhere                   # HTTP
[ 3] 443/tcp                    ALLOW IN    Anywhere                   # HTTPS
[ 4] 22/tcp (v6)                ALLOW IN    Anywhere (v6)              # SSH
[ 5] 80/tcp (v6)                ALLOW IN    Anywhere (v6)              # HTTP
[ 6] 443/tcp (v6)               ALLOW IN    Anywhere (v6)              # HTTPS

La vue numérotée est utile quand vous devez supprimer des règles spécifiques plus tard avec ufw delete <number>.

Comment limiter le débit des connexions SSH avec UFW ?

UFW intègre un limiteur de débit. Il refuse les connexions d'une IP qui tente plus de 6 connexions en 30 secondes. Remplacez la règle d'autorisation simple par une règle de limitation :

ufw delete allow 22/tcp
ufw limit 22/tcp comment 'SSH rate-limited'

Vérification :

ufw status verbose

La règle SSH affiche maintenant LIMIT IN au lieu de ALLOW IN. Cela ralentit les tentatives de brute-force sans bloquer les accès légitimes. Pour une protection renforcée, combinez avec Fail2Ban Installer et configurer Fail2Ban sur un VPS Linux.

Comment autoriser des IP ou sous-réseaux spécifiques avec UFW ?

Pour restreindre l'accès à un service par IP source :

ufw allow from 198.51.100.0/24 to any port 22 proto tcp comment 'SSH from office'

Pour autoriser une seule IP à accéder à tous les ports :

ufw allow from 198.51.100.42 comment 'Trusted admin'

C'est utile pour les services d'administration qui ne doivent jamais être exposés sur internet. Combinez l'accès restreint avec la politique deny-by-default.

Comment supprimer des règles UFW ?

Supprimez en spécifiant la règle exacte. C'est la méthode la plus sûre parce qu'elle fonctionne indépendamment de l'ordre des règles :

ufw delete allow 80/tcp

Vous pouvez aussi supprimer par numéro. Listez d'abord les règles avec leurs numéros :

ufw status numbered

Puis supprimez par numéro :

ufw delete 2

Attention avec la suppression par numéro. Les numéros changent à chaque ajout ou suppression de règle. Exécutez toujours ufw status numbered juste avant de supprimer pour confirmer quelle règle correspond à quel numéro. Supprimer le mauvais numéro peut vous verrouiller hors de SSH.

Comment configurer les logs UFW ?

Activez les logs pour voir les connexions bloquées :

ufw logging on

UFW supporte trois niveaux de log : low, medium, high. Le niveau low par défaut journalise les paquets bloqués. Pour le dépannage, augmentez temporairement :

ufw logging medium

Consultez les logs :

journalctl -k -f | grep UFW

Ou vérifiez le fichier de log directement :

tail -20 /var/log/ufw.log

Remettez le niveau à low après le débogage. Les niveaux supérieurs génèrent un trafic disque significatif sur les serveurs chargés.

UFW fonctionne-t-il avec IPv6 ?

Oui. UFW gère IPv4 et IPv6 simultanément quand IPV6=yes est défini dans /etc/default/ufw. C'est activé par défaut sur Ubuntu 24.04. Vérification :

grep IPV6 /etc/default/ufw

Résultat attendu :

IPV6=yes

Chaque règle ufw allow crée automatiquement les entrées IPv4 et IPv6 correspondantes. Aucune étape supplémentaire nécessaire.

Liste de contrôle de vérification UFW

Exécutez ces vérifications pour confirmer que votre pare-feu fonctionne :

  1. Listez toutes les règles : ufw status verbose
  2. Vérifiez qu'UFW est activé au démarrage : systemctl is-enabled ufw
  3. Testez SSH depuis un second terminal (ne fermez pas votre session actuelle)
  4. Testez depuis l'extérieur du serveur -- depuis votre machine locale :
nc -zv YOUR_SERVER_IP 22

Résultat attendu : Connection to YOUR_SERVER_IP 22 port [tcp/ssh] succeeded!

nc -zv YOUR_SERVER_IP 25

Résultat attendu : connexion refusée ou timeout (le port 25 n'est pas autorisé).

Comment configurer nftables sur Debian 12 ?

nftables est le framework de pare-feu par défaut sur Debian 12. Il remplace iptables avec une syntaxe plus claire et de meilleures performances. Sur Ubuntu 24.04, installez-le si vous voulez l'utiliser à la place d'UFW :

apt update && apt install -y nftables

Si UFW est actif, désactivez-le d'abord. Faire tourner les deux crée des règles en conflit :

ufw disable
systemctl disable --now ufw

Que sont les tables, chaînes et règles nftables ?

nftables organise les règles de pare-feu dans une hiérarchie :

  • Table -- un conteneur qui contient des chaînes. La famille inet gère à la fois IPv4 et IPv6 dans une seule table.
  • Chaîne (chain) -- une liste de règles qui s'accroche à un point spécifique du traitement des paquets. Une chaîne input filtre les paquets destinés au serveur. Une chaîne forward filtre les paquets en transit.
  • Règle (rule) -- une paire condition-action. « Si le paquet correspond au port TCP 22, accepter. »

Le concept central : définir la politique de la chaîne à drop, puis ajouter des règles qui font accept sur le trafic spécifique. Tout ce qui n'est pas explicitement autorisé est silencieusement rejeté.

Comment écrire un jeu de règles nftables en deny-by-default ?

Définissez les politiques par défaut pour rejeter tout le trafic entrant, puis ajoutez des règles pour SSH, HTTP et HTTPS. Avec nftables, vous écrivez cela sous forme de fichier de configuration.

Créez la configuration :

cp /etc/nftables.conf /etc/nftables.conf.bak

cat > /etc/nftables.conf << 'NFTEOF'
#!/usr/sbin/nft -f

flush ruleset

table inet firewall {

    set ssh_ratelimit {
        type ipv4_addr
        flags dynamic
        timeout 60s
    }

    set ssh_ratelimit6 {
        type ipv6_addr
        flags dynamic
        timeout 60s
    }

    chain inbound_ipv4 {
        icmp type echo-request limit rate 5/second accept
    }

    chain inbound_ipv6 {
        icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
        icmpv6 type echo-request limit rate 5/second accept
    }

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

        ct state established,related accept
        ct state invalid drop

        iifname "lo" accept

        meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 }

        tcp dport 22 ct state new add @ssh_ratelimit { ip saddr limit rate 3/minute burst 5 packets } accept
        tcp dport 22 ct state new add @ssh_ratelimit6 { ip6 saddr limit rate 3/minute burst 5 packets } accept

        tcp dport { 80, 443 } accept

        log prefix "[nftables] Dropped: " counter drop
    }

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

    chain outbound {
        type filter hook output priority filter; policy accept;
    }
}
NFTEOF

Ce que fait chaque section :

  • flush ruleset -- efface toutes les règles existantes pour repartir de zéro.
  • table inet firewall -- crée une table dans la famille inet (dual-stack IPv4+IPv6).
  • set ssh_ratelimit -- un set dynamique qui suit les IP sources pour la limitation de débit SSH. Les entrées expirent après 60 secondes.
  • chain inbound -- la chaîne d'entrée principale avec policy drop. Tout ce qui ne correspond à aucune règle est rejeté.
  • ct state established,related accept -- autorise le trafic de retour pour les connexions initiées par votre serveur. Sans cela, les connexions sortantes (mises à jour apt, requêtes DNS) casseraient.
  • ct state invalid drop -- rejette les paquets malformés qui n'appartiennent à aucune connexion connue.
  • iifname "lo" accept -- autorise le trafic sur l'interface loopback. De nombreux services communiquent en interne via localhost.
  • meta protocol vmap -- redirige vers les chaînes spécifiques IPv4 ou IPv6 selon le protocole. Cela gère ICMP et ICMPv6 séparément.
  • tcp dport 22 ... limit rate 3/minute -- autorise SSH avec limitation de débit par IP. Chaque IP source a droit à 3 nouvelles connexions par minute avec un burst de 5.
  • tcp dport { 80, 443 } accept -- autorise HTTP et HTTPS.
  • log prefix "[nftables] Dropped: " -- journalise tous les paquets rejetés dans le log du noyau pour le dépannage.

Comment gérer IPv6 avec nftables ?

La famille inet dans la définition de la table gère à la fois IPv4 et IPv6 dans un seul jeu de règles. Mais IPv6 nécessite des types ICMPv6 spécifiques pour que le réseau de base fonctionne.

La chaîne inbound_ipv6 accepte trois types ICMPv6 :

  • nd-neighbor-solicit -- équivalent d'ARP pour IPv6. Sans cela, votre serveur ne peut pas découvrir les voisins sur le réseau local.
  • nd-router-advert -- permet aux routeurs de s'annoncer. Nécessaire pour SLAAC (configuration automatique d'adresse IPv6).
  • nd-neighbor-advert -- réponses aux sollicitations de voisinage. Nécessaire pour la connectivité IPv6.

Bloquer n'importe lequel de ces types casse le réseau IPv6. Le jeu de règles ci-dessus gère cela correctement. Si vous n'avez que de l'IPv4, ces règles sont inoffensives -- elles ne correspondent simplement jamais.

Comment limiter le débit des connexions avec les meters nftables ?

Le jeu de règles ci-dessus utilise des sets dynamiques (anciennement appelés meters) pour la limitation de débit par IP sur SSH. Quand une connexion arrive, voici ce qui se passe :

  1. Une nouvelle connexion TCP sur le port 22 arrive depuis 198.51.100.42.
  2. nftables vérifie @ssh_ratelimit pour une entrée correspondant à cette IP.
  3. Si l'IP a moins de 3 connexions dans la dernière minute, la connexion est acceptée et le compteur se met à jour.
  4. Si l'IP dépasse la limite, la règle ne correspond pas, et le paquet tombe dans la politique drop.

Le paramètre burst 5 packets autorise un pic bref, puis applique le débit constant. Le timeout 60s sur le set signifie que les entrées sont nettoyées automatiquement, empêchant le set de grossir indéfiniment.

Pour inspecter l'état actuel du limiteur de débit :

nft list set inet firewall ssh_ratelimit

Cela montre quelles IP sont actuellement suivies et leurs compteurs.

Comment ajouter des règles pour des services supplémentaires ?

Le jeu de règles ci-dessus autorise SSH, HTTP et HTTPS. Pour ajouter d'autres services, insérez des règles dans la chaîne inbound avant la ligne finale log ... drop.

Par exemple, pour autoriser une application Node.js sur le port 3000 uniquement depuis une IP spécifique :

tcp dport 3000 ip saddr 198.51.100.42 accept

Pour autoriser un service UDP comme WireGuard sur le port 51820 :

udp dport 51820 accept

Pour autoriser une plage de ports (par ex. pour le FTP passif) :

tcp dport 40000-50000 accept

Après modification de /etc/nftables.conf, validez la syntaxe sans appliquer :

nft -c -f /etc/nftables.conf

Le drapeau -c vérifie les erreurs et quitte. Aucune sortie signifie que la syntaxe est valide.

Comment gérer les règles nftables à la volée ?

Vous pouvez ajouter et supprimer des règles sans modifier le fichier de configuration. Ces changements sont temporaires et perdus au redémarrage sauf si vous les sauvegardez.

Ajouter une règle à la volée :

nft add rule inet firewall inbound tcp dport 8080 accept

Lister le jeu de règles actuel :

nft list ruleset

Supprimer une règle par son numéro de handle. D'abord, listez les règles avec les handles :

nft -a list chain inet firewall inbound

Chaque règle affiche un suffixe # handle N. Supprimez par handle :

nft delete rule inet firewall inbound handle 15

Pour sauvegarder les changements à la volée dans le fichier de configuration :

nft list ruleset > /etc/nftables.conf

Rajoutez la ligne shebang en haut du fichier :

sed -i '1i #!/usr/sbin/nft -f' /etc/nftables.conf

Comment appliquer et persister les règles nftables ?

Appliquez la configuration :

nft -f /etc/nftables.conf

Vérifiez que les règles sont chargées :

nft list ruleset

Vous devriez voir la table complète avec toutes les chaînes et règles. S'il y a des erreurs de syntaxe, nft -f affichera le numéro de ligne et l'erreur.

Activez nftables au démarrage :

systemctl enable --now nftables

enable le fait survivre aux redémarrages. --now le démarre immédiatement. Vérifiez que le service tourne :

systemctl status nftables

La sortie attendue inclut Active: active (exited). Le statut exited est normal. nftables charge les règles dans le noyau puis se termine. Les règles restent actives dans l'espace noyau.

Confirmez qu'il est activé pour le prochain démarrage :

systemctl is-enabled nftables

Résultat attendu : enabled.

Comment lire les logs nftables ?

Le jeu de règles inclut une instruction log avant le drop final. Les paquets rejetés apparaissent dans le log du noyau avec le préfixe [nftables] Dropped:.

Voir les paquets rejetés en temps réel :

journalctl -k -f | grep nftables

Une entrée de log typique :

Mar 19 14:23:01 vps kernel: [nftables] Dropped: IN=eth0 OUT= SRC=203.0.113.55 DST=198.51.100.1 PROTO=TCP SPT=44521 DPT=3389

Cela vous indique : une IP externe (203.0.113.55) a tenté d'atteindre le port 3389 (RDP) sur votre serveur et a été rejetée. C'est du trafic de scan normal. Si vous voyez votre propre IP dans le champ SRC, vous avez un problème de règle.

Pour éviter le spam de logs sur les serveurs fortement scannés, la section dépannage ci-dessous explique comment ajouter une limite de débit à la règle de log.

Liste de contrôle de vérification nftables

  1. Listez le jeu de règles complet : nft list ruleset
  2. Vérifiez le service : systemctl is-enabled nftables
  3. Testez SSH depuis un second terminal (gardez votre session actuelle ouverte)
  4. Testez depuis votre machine locale :
nc -zv YOUR_SERVER_IP 22

Résultat attendu : connexion réussie.

nc -zv YOUR_SERVER_IP 25

Résultat attendu : connexion refusée ou timeout.

  1. Vérifiez les paquets rejetés dans les logs :
journalctl -k | grep "nftables"

Comment éviter le verrouillage SSH lors de la modification des règles de pare-feu ?

Se verrouiller hors de SSH est le risque principal lors de la configuration d'un pare-feu. Deux garde-fous préviennent cela.

Garde-fou 1 : toujours tester dans un second terminal

Avant de fermer votre session SSH après avoir modifié les règles de pare-feu, ouvrez un nouveau terminal et connectez-vous en SSH à votre serveur. Si la nouvelle connexion fonctionne, vos règles sont correctes. Si elle échoue, retournez dans votre session d'origine et corrigez les règles.

Ne fermez jamais votre session SSH active tant que vous n'avez pas confirmé qu'une seconde connexion fonctionne.

Garde-fou 2 : sécurité temporisée avec at

Quand vous testez des changements nftables, planifiez une tâche qui efface automatiquement toutes les règles après 5 minutes. Si vos nouvelles règles vous verrouillent dehors, attendez 5 minutes et réessayez.

at now + 5 minutes <<< 'nft flush ruleset'

Si at n'est pas installé :

apt install -y at
systemctl enable --now atd
at now + 5 minutes <<< 'nft flush ruleset'

Après avoir confirmé que vos règles fonctionnent, annulez la sécurité :

atrm $(atq | awk '{print $1}')

Pour UFW, la sécurité équivalente :

at now + 5 minutes <<< 'ufw disable'

Et Docker avec le pare-feu ?

Docker manipule iptables directement pour configurer le réseau des conteneurs. Quand vous publiez un port avec -p 8080:80, Docker crée des règles NAT qui contournent entièrement UFW. Vos règles ufw deny n'ont aucun effet sur les ports publiés par Docker.

C'est la surprise de pare-feu la plus fréquente sur un VPS Linux. Un port que vous pensiez bloqué est grand ouvert parce que Docker a routé le trafic autour de votre pare-feu.

Deux solutions :

  1. Utilisez nftables au lieu d'UFW. nftables n'a pas le même problème de contournement parce que vous contrôlez la totalité du jeu de règles.
  2. Appliquez le correctif de la chaîne DOCKER-USER. Voir Docker contourne UFW : 4 solutions testées pour votre VPS pour le guide pas à pas qui force le trafic Docker à passer par UFW.

Si vous faites tourner Docker en production, nftables est le choix le plus sûr.

Référence des ports courants

Service Port Protocole Commande UFW Règle nftables
SSH 22 TCP ufw allow 22/tcp tcp dport 22 accept
HTTP 80 TCP ufw allow 80/tcp tcp dport 80 accept
HTTPS 443 TCP ufw allow 443/tcp tcp dport 443 accept
DNS 53 TCP/UDP ufw allow 53 tcp dport 53 accept; udp dport 53 accept
PostgreSQL 5432 TCP ufw allow 5432/tcp tcp dport 5432 accept
MySQL 3306 TCP ufw allow 3306/tcp tcp dport 3306 accept

N'exposez pas les ports de base de données sur internet. Si vous avez besoin d'un accès distant à la base de données, utilisez un tunnel SSH ou restreignez à des IP spécifiques :

UFW :

ufw allow from 198.51.100.0/24 to any port 5432 proto tcp comment 'PostgreSQL from trusted network'

nftables (ajoutez avant le drop final dans la chaîne inbound) :

tcp dport 5432 ip saddr 198.51.100.0/24 accept

Dépannage

Quelque chose ne va pas ?

Verrouillé hors de SSH : Utilisez la console VNC/série de votre hébergeur pour vous connecter. Puis soit ufw disable soit nft flush ruleset pour effacer toutes les règles. Ré-ajoutez votre règle SSH avant de réactiver le pare-feu.

Les règles ne persistent pas après redémarrage (nftables) : Vérifiez que le service est activé : systemctl is-enabled nftables. S'il affiche disabled, exécutez systemctl enable nftables. Vérifiez aussi que /etc/nftables.conf est syntaxiquement valide : nft -c -f /etc/nftables.conf (le drapeau -c vérifie la syntaxe sans appliquer).

UFW affiche des règles mais le trafic est toujours bloqué : Vérifiez s'il y a des règles nftables ou iptables en conflit : nft list ruleset et iptables -L -n. Deux outils de pare-feu actifs simultanément produisent des résultats imprévisibles.

Les logs remplissent le disque : Si vous avez activé les logs et que le serveur reçoit beaucoup de trafic de scan, les logs peuvent grossir vite. Baissez le niveau de log (ufw logging low) ou ajoutez une limite de débit à la règle de log nftables :

log prefix "[nftables] Dropped: " limit rate 10/minute counter drop

Connexion impossible après activation de la limitation de débit : Le limiteur est peut-être trop strict. Pour nftables, inspectez le set dynamique : nft list set inet firewall ssh_ratelimit. Pour UFW, ufw limit utilise un seuil fixe de 6 connexions/30 secondes qui n'est pas configurable. Si c'est trop strict, utilisez un simple ufw allow et appuyez-vous sur Fail2Ban à la place Installer et configurer Fail2Ban sur un VPS Linux.

Prochaines étapes

Un pare-feu bloque les ports indésirables. Il ne détecte pas les tentatives de connexion échouées répétées ni les attaques au niveau applicatif. Pour compléter votre base de sécurité VPS :

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.

Prêt à essayer ?

Déployez votre serveur en quelques secondes. Linux, Windows ou FreeBSD. →