[{"data":1,"prerenderedAt":212},["ShallowReactive",2],{"seo-verification":3,"blog-proteger-vps-fail2ban-ma-fr":6,"promo-bar-likely":211},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-proteger-vps-fail2ban-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":152,"ctaBody":153,"ctaButton":154,"ctaUrl":155,"relatedPosts":156},109,"proteger-vps-fail2ban",{"fr":10,"en":12,"ar":13,"es":14},"fail2ban-enhanced-on-vps-blocking-repeated-attacks","fail2ban-enhanced-على-خادم-vps-حجب-الهجمات-المتكررة","fail2ban-en-vps-bloquear-ataques-repetidos","Fail2Ban Enhanced sur VPS : bloquer les attaques répétées","Reliez Fail2Ban Enhanced au catalogue ServOrbit : bannissement SSH\u002FNginx, logs lisibles et documentation officielle.",11,1,false,"2026-03-03T00:00:00+00:00","2026-11-01T14:14:36+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fproteger-vps-fail2ban-poster.svg",{"categorySlug":34,"appSlug":35},"securite","fail2ban-enhanced","Dès qu'un VPS expose SSH ou une application web, les tentatives automatisées arrivent vite. Fail2Ban Enhanced donne un filet simple : lire les journaux, détecter les échecs répétés et bannir les IP qui insistent. Ce guide va du réglage initial à l'exploitation au quotidien : jails et seuils, choix du backend, vérification que le jail surveille encore, dépannage avec les vrais messages d'erreur, articulation avec le pare-feu du VPS et sauvegarde de la configuration. Les options citées viennent de la documentation amont de Fail2Ban.",[38,42,52,55,80,83,87,90,114,117,132,135,146,149],{"type":39,"title":40,"body":41},"h2","Pourquoi auto-héberger Fail2ban sur un VPS","Fail2ban est l'un des outils de protection les plus simples et les plus répandus pour un serveur exposé : il lit en continu vos journaux, applique des expressions régulières (les filtres) pour repérer les tentatives d'intrusion, et bannit l'IP fautive en l'ajoutant à nftables ou iptables pour une durée configurable. Sur un VPS, c'est une première ligne de défense à poser avant le reste, parce qu'il ne dépend d'aucun service externe, consomme peu et protège SSH contre le bruteforce dès l'activation du jail. Au-delà de SSH, vous pouvez l'étendre à Nginx (tentatives d'authentification, scans d'URL), Postfix, WordPress ou tout service qui écrit des journaux. Tout fonctionne en local sur votre machine : aucune donnée ne sort, aucun service tiers n'intervient. C'est une solution autonome et facile à auditer, à condition de la vérifier de temps en temps, comme nous le verrons plus bas.",{"type":43,"title":44,"items":45},"ul","Les bénéfices concrets de ce template",[46,47,48,49,50,51],"**Bannissement automatique** — les IP qui forcent SSH sont bannies dès que le seuil `maxretry` est atteint dans la fenêtre `findtime`.","**Filtres pour de nombreux services** — SSH, Nginx, Apache, Postfix, WordPress, et filtres personnalisés écrits dans `filter.d`.","**Empreinte minimale** — il tourne sans souci sur le plus petit des VPS.","**Bannissement progressif (récidive)** — plus une IP récidive, plus le bannissement est long.","**Notifications par e-mail** — possibles à chaque bannissement, avec les actions `action_mw` ou `action_mwl` de `jail.conf`.","**Autonome et local** — aucune dépendance réseau au quotidien, simple à auditer et à versionner.",{"type":39,"title":53,"body":54},"Prérequis chiffrés pour l'héberger","Fail2ban est frugal : un VPS de 1 vCPU et 512 Mo de RAM suffit pour l'exécuter, sans impact perceptible (recommandation éditoriale, à mesurer sur votre charge). Côté logiciel, le README amont de la version 1.1.1 demande Python 3.5 ou plus. Deux composants sont optionnels : pyinotify 0.8.3 ou plus pour surveiller les fichiers (noyau Linux 2.6.13 ou plus), et systemd 204 ou plus avec le paquet python-systemd pour lire le journal. Fail2ban s'installe directement sur le système (pas besoin de Docker) et exige un accès root, un backend de pare-feu (nftables ou iptables) et l'accès aux journaux des services à protéger : le journal systemd ou `\u002Fvar\u002Flog\u002Fauth.log` pour SSH selon la distribution, les journaux access et error de Nginx. Il garde son état dans une base SQLite, `\u002Fvar\u002Flib\u002Ffail2ban\u002Ffail2ban.sqlite3` par défaut. Aucun domaine ni port supplémentaire n'est nécessaire. La règle d'or : renseignez `ignoreip` avec votre IP avant d'activer le bannissement, pour ne pas vous verrouiller hors de votre propre serveur.",{"type":56,"title":57,"steps":58},"steps","Installer et configurer Fail2ban sur votre VPS",[59,62,65,68,71,74,77],{"title":60,"body":61},"Installer Fail2ban","Sur Debian ou Ubuntu : `sudo apt update && sudo apt install fail2ban`. Le service démarre automatiquement. Vérifiez avec `sudo systemctl status fail2ban`.",{"title":63,"body":64},"Créer un jail.local","Ne modifiez jamais `jail.conf` directement. Écrivez vos réglages dans `\u002Fetc\u002Ffail2ban\u002Fjail.local`, qui les surcharge : c'est là que se définissent `bantime`, `findtime`, `maxretry` et surtout `ignoreip = 127.0.0.1\u002F8 ::1 VOTRE_IP` pour vous protéger d'un auto-bannissement. Les valeurs par défaut de `jail.conf` sont `bantime = 10m`, `findtime = 10m` et `maxretry = 5`.",{"title":66,"body":67},"Activer la protection SSH","Tous les jails sont désactivés par défaut dans `jail.conf` : activez explicitement `[sshd]` dans `jail.local` avec `enabled = true`, par exemple `maxretry = 3` et `bantime = 1h`. Après 3 échecs dans la fenêtre `findtime`, l'IP est bannie une heure au niveau du pare-feu.",{"title":69,"body":70},"Ajouter un jail pour Nginx","Activez les jails `[nginx-http-auth]` et `[nginx-botsearch]`, fournis par `jail.conf`, en vérifiant que `logpath` pointe vers vos journaux Nginx. Cela bloque les tentatives d'authentification répétées et les scans d'URL malveillants.",{"title":72,"body":73},"Tester la configuration puis la recharger","Contrôlez d'abord la syntaxe : `sudo fail2ban-client -t`. Puis appliquez-la : `sudo fail2ban-client reload` (ou `sudo systemctl restart fail2ban`). `sudo fail2ban-client status` liste les jails actifs et `sudo fail2ban-client status sshd` montre les IP actuellement bannies.",{"title":75,"body":76},"Tester un bannissement et le débannissement","Vérifiez le filtre sur votre propre journal avec `sudo fail2ban-regex systemd-journal sshd`. Pour simuler un bannissement sans attaquer personne : `sudo fail2ban-client set sshd banip 203.0.113.10`, puis lisez `sudo fail2ban-client status sshd`. Pour libérer une IP légitime bloquée par erreur : `sudo fail2ban-client set sshd unbanip X.X.X.X`.",{"title":78,"body":79},"Se connecter la première fois","Il n'y a aucune interface web ni compte à créer : fail2ban est un démon système qui, avec le réglage du template, bannit les IP après 4 échecs SSH en 10 minutes. En SSH : `fail2ban-client status sshd` (IP bannies), `fail2ban-client set sshd unbanip \u003CIP>` (débannir). Ajustez ces seuils dans `jail.local`.",{"type":39,"title":81,"body":82},"ignoreip, durée de bannissement et récidive","`ignoreip` accepte des adresses IP, des masques CIDR ou des noms d'hôte DNS, séparés par des espaces ou des virgules. Par défaut, `ignoreself = true` : les adresses locales du serveur ne sont jamais bannies, mais votre IP de bureau ou de domicile ne l'est pas pour autant. Si elle change souvent, déclarez un nom d'hôte dynamique ou utilisez `ignorecommand`, une commande externe qui reçoit l'IP et répond si elle doit être ignorée. Gardez aussi un accès de secours indépendant de SSH, comme la console de votre fournisseur de VPS : un auto-bannissement se règle alors sans intervention extérieure. La durée se règle avec `bantime`, en secondes ou avec les suffixes `m`, `h`, `d`, `w`, `mo` et `y`. Elle sert de durée initiale quand le bannissement progressif est activé. Pour les récidivistes, `jail.conf` fournit aussi un jail `recidive`, qui relit le journal de fail2ban lui-même.",{"type":84,"title":85,"body":86},"tip","Bannissement progressif : formule, plafond et mémoire","Activez le bannissement progressif dans `jail.local` avec `bantime.increment = true`. La formule par défaut multiplie `bantime` par 1, 2, 4, 8, 16 et ainsi de suite à chaque récidive ; `bantime.factor` (1 par défaut) est un multiplicateur commun, et `bantime.maxtime` plafonne la durée en secondes, par exemple `bantime.maxtime = 604800` pour sept jours. Un point se rate souvent : fail2ban retrouve les anciens bannissements dans sa base, purgée selon `dbpurgeage` (un jour par défaut dans `fail2ban.conf`). Pour que des récidives espacées soient retrouvées, relevez-le ; le commentaire du jail `recidive` dans `jail.conf` cite 648000 secondes. Couplez le tout à la désactivation de l'authentification par mot de passe (clés SSH uniquement) : Fail2ban devient alors un filet de sécurité plutôt que votre unique rempart.",{"type":39,"title":88,"body":89},"Choisir le backend : auto, pyinotify, polling ou systemd","Le backend est la façon dont un jail lit ses journaux. La valeur par défaut de `jail.conf` est `backend = auto`, que chaque jail peut surcharger. Sur Debian et Ubuntu, le fichier `paths-debian.conf` de l'archive amont 1.1.1 fixe `sshd_backend = systemd` : sshd est alors lu dans le journal systemd, pas dans `\u002Fvar\u002Flog\u002Fauth.log`. Lisez `sudo fail2ban-client status sshd` pour savoir ce qui est réellement surveillé : la ligne `File list` indique des fichiers, la ligne `Journal matches` indique le journal. Une distribution peut modifier ces valeurs, donc ne présumez rien : constatez. Changer de backend se fait jail par jail, dans `jail.local`, puis `sudo fail2ban-client reload`.",{"type":91,"title":92,"headers":93,"rows":97},"comparison","Les quatre backends de Fail2ban",[94,95,96],"Backend","Ce qu'il surveille","À retenir",[98,102,106,110],[99,100,101],"auto","Des fichiers (pyinotify puis polling) ; bascule vers systemd si aucun fichier de `logpath` n'existe et que le filtre définit `journalmatch`","Valeur par défaut de `jail.conf`",[103,104,105],"pyinotify","Des fichiers, via les événements inotify du noyau","Linux seulement, module Python pyinotify requis ; mieux adapté aux fichiers que polling selon la documentation",[107,108,109],"polling","Des fichiers, par relecture à intervalle régulier","Aucune bibliothèque externe, repli le plus simple",[111,112,113],"systemd","Le journal systemd, via python-systemd","`logpath` n'est pas valide ; le filtre passe par `journalmatch` ; réglages `journalflags` et `rotated`",{"type":39,"title":115,"body":116},"Vérifier que le jail surveille encore","Un jail démarré n'est pas forcément un jail qui lit. Signalement rapporté, non confirmé par la maintenance : dans le \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffail2ban\u002Ffail2ban\u002Fissues\u002F4250\" target=\"_blank\" rel=\"noopener noreferrer\">ticket fail2ban n° 4250\u003C\u002Fa>, ouvert en octobre 2026, un administrateur sous Debian avec fail2ban 1.1.1 décrit un jail `sshd` en backend `systemd` qui cesse de bannir un à deux jours après le démarrage, alors que ses jails Nginx et Postfix continuent de fonctionner. Deux autres administrateurs, tous deux sous FreeBSD d'après leurs messages, rapportent un symptôme voisin avec le backend `pyinotify` ; l'un dit être revenu à la stabilité en passant en `polling`. Un mainteneur a fait remarquer que le ticket d'origine portait sur le backend `systemd` et que les deux symptômes ne sont peut-être pas liés. Un dernier participant, sous Arch avec le backend `systemd`, décrit le même arrêt après une rotation du journal et avance une hypothèse sur le réglage `rotated` : elle reste non confirmée. La cause n'est pas établie à ce jour, et rien ne permet de généraliser à votre serveur. Le contrôle, lui, coûte une minute.",{"type":56,"title":118,"steps":119},"Contrôler en quatre gestes que le jail lit toujours",[120,123,126,129],{"title":121,"body":122},"Lire l'état du jail","`sudo fail2ban-client status sshd` affiche `Currently failed` et `Total failed` pour le filtre, `File list` ou `Journal matches` pour la source, puis `Currently banned`, `Total banned` et `Banned IP list` pour l'action. Notez `Total failed`.",{"title":124,"body":125},"Comparer avec le journal","Comptez les échecs réels sur la même période : `sudo journalctl _COMM=sshd --since \"1 hour ago\" | grep -c \"Failed password\"`, ou `sudo grep -c \"Failed password\" \u002Fvar\u002Flog\u002Fauth.log` si le jail lit ce fichier. Relisez ensuite `Total failed` : il doit avoir progressé. Comparez la tendance, pas l'égalité exacte, car les IP de `ignoreip` ne comptent pas.",{"title":127,"body":128},"Lire le journal de fail2ban","`sudo tail -n 50 \u002Fvar\u002Flog\u002Ffail2ban.log` : un jail en bonne santé écrit des lignes `Found` puis `Ban`. Plusieurs jours de lignes `Unban` seules, alors que le journal d'authentification montre des tentatives, désignent un jail aveugle.",{"title":130,"body":131},"Relancer et changer de backend si besoin","`sudo systemctl restart fail2ban` relance la lecture ; le ticket décrit un fonctionnement normal pendant un à deux jours après chaque démarrage. Pour un jail de fichiers, `backend = polling` est le repli le plus simple. Planifiez ce contrôle (cron ou outil de supervision) plutôt que de compter sur l'absence d'alerte.",{"type":39,"title":133,"body":134},"Dépannage : les messages d'erreur réels","Ces messages viennent du code source de Fail2ban 1.1.1 (clients et lecteurs de configuration) ; le niveau de journalisation par défaut est `INFO`. Pour chaque cas, la commande de départ est la même : `sudo fail2ban-client -t` teste la configuration, `sudo journalctl -u fail2ban` donne le début de l'histoire.",{"type":43,"title":136,"items":137},"Messages d'erreur courants et remèdes",[138,139,140,141,142,143,144,145],"**`Have not found any log file for 'sshd' jail.`** — le `logpath` du jail ne désigne aucun fichier existant et le démarrage échoue, sauf si `skip_if_nologs = true`. En backend `auto`, un jail dont le filtre définit `journalmatch` bascule sur systemd à la place. Corrigez le chemin ou fixez `backend = systemd`.","**`No file(s) found for glob \u002Fvar\u002Flog\u002Fnginx\u002Ferror.log`** — un motif de `logpath` ne correspond à rien. Vérifiez l'emplacement réel des journaux Nginx avec `ls \u002Fvar\u002Flog\u002Fnginx`.","**`Unable to read the filter 'nginx-xyz'`** — le nom donné à `filter =` n'existe pas dans `filter.d`. Corrigez la faute de frappe ou ajoutez votre fichier de filtre.","**`Failed to access socket path: \u002Fvar\u002Frun\u002Ffail2ban\u002Ffail2ban.sock. Is fail2ban running?`** — le client ne trouve pas le socket du serveur. Le service est arrêté ou en échec : `sudo systemctl status fail2ban`, puis le journal.","**`Permission denied to socket: ... (you must be root)`** — la commande `fail2ban-client` a été lancée sans les droits suffisants. Relancez-la avec `sudo`.","**`Unable to contact server. Is it running?`** — le socket existe mais le serveur ne répond pas. Redémarrez le service puis relisez son journal de démarrage.","**`[sshd] Journal reader seems to be offline, reopen journal`** — fail2ban a détecté que sa lecture du journal systemd s'était interrompue (rotation) et la rouvre. Ce message est de niveau `MSG`, sous `INFO` : son absence dans un journal normal ne prouve rien, d'où le contrôle de la section précédente.","**`Error reading line from systemd journal`** — erreur de lecture du journal systemd, suivie de la cause système. Vérifiez les droits du service et l'état du journal avec `journalctl --verify`.",{"type":39,"title":147,"body":148},"nftables ou iptables, pare-feu du VPS et sauvegarde","L'action de bannissement se choisit avec `banaction`. `jail.conf` propose `iptables-multiport` en exemple commenté ; le fichier `paths-debian.conf` de l'archive 1.1.1 fixe `banaction = nftables` et `banaction_allports = nftables[type=allports]`. L'action nftables crée par défaut la table `f2b-table` (famille `inet`) et la chaîne `f2b-chain`, accrochée à l'entrée avec la priorité -1 ; `sudo nft list table inet f2b-table` montre les IP bannies. Choisissez une seule famille d'actions, la même que le reste de votre pare-feu, sinon vous cherchez vos règles dans la mauvaise table. Le pare-feu du VPS agit en amont : il filtre ce qui atteint la machine, par exemple en limitant SSH à vos adresses, tandis que Fail2ban réagit à ce que les journaux racontent. Les deux se complètent, mais veillez à ce que `ignoreip` reste cohérent avec vos règles. Derrière un proxy ou un CDN, les journaux affichent l'IP du proxy : restituez la vraie IP avant de bannir, faute de quoi vous bannissez le proxy. Côté sauvegarde, archivez la configuration (`sudo tar czf fail2ban-config.tar.gz \u002Fetc\u002Ffail2ban`) et la sortie de `sudo fail2ban-client --dp`, qui documente la configuration effective. La base `\u002Fvar\u002Flib\u002Ffail2ban\u002Ffail2ban.sqlite3` conserve la mémoire des bannissements.",{"type":84,"title":150,"body":151},"La documentation officielle","Pour la configuration avancée, les options propres à l’outil et les changements de version, référez-vous à la \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ffail2ban\u002Ffail2ban\u002Fwiki\" target=\"_blank\" rel=\"noopener noreferrer\">documentation officielle de Fail2Ban\u003C\u002Fa>. Ce guide couvre la mise en ligne sur VPS ServOrbit ; la documentation éditeur reste la référence pour les réglages fins.","Blindez l'acces a votre VPS","Le VPS Cloud ServOrbit vous donne l'acces root et un pare-feu pret a l'emploi pour configurer Fail2ban en quelques minutes et stopper net les attaques par bruteforce.","Obtenir mon VPS Cloud","\u002Fvps-cloud",[157,176,193],{"id":158,"slug":159,"slugs":160,"title":164,"excerpt":165,"readTime":23,"views":166,"isPinned":19,"noindex":19,"publishedAt":167,"updatedAt":168,"category":169,"categories":170,"featuredImage":30,"bgImage":31,"posterImage":172,"relatedSolution":173},105,"superviser-vps-uptime-kuma",{"fr":159,"en":161,"ar":162,"es":163},"monitoring-your-vps-with-uptime-kuma","مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma","supervisar-vps-con-uptime-kuma","Superviser votre VPS avec Uptime Kuma","Déployez Uptime Kuma sur votre VPS pour surveiller vos sites et services en self-hosted, avec alertes et page de statut publique.",0,"2026-03-07T00:00:00+00:00","2026-11-09T20:55:19+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[171],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsuperviser-vps-uptime-kuma-poster.svg",{"categorySlug":174,"appSlug":175},"monitoring","uptime-kuma",{"id":177,"slug":178,"slugs":179,"title":183,"excerpt":184,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":185,"updatedAt":186,"category":187,"categories":188,"featuredImage":30,"bgImage":31,"posterImage":190,"relatedSolution":191},106,"monitoring-vps-grafana-prometheus",{"fr":178,"en":180,"ar":181,"es":182},"vps-monitoring-with-grafana-and-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","monitorizacion-vps-grafana-prometheus","Monitoring VPS avec Grafana et Prometheus","Déployez Prometheus 3.x, Grafana 13.x, Node Exporter et Alertmanager sur votre VPS avec Docker Compose. Dashboards, alertes et durcissement.","2026-03-06T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[189],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-vps-grafana-prometheus-poster.svg",{"categorySlug":174,"appSlug":192},"grafana",{"id":194,"slug":195,"slugs":196,"title":200,"excerpt":201,"readTime":202,"views":18,"isPinned":19,"noindex":19,"publishedAt":203,"updatedAt":204,"category":205,"categories":206,"featuredImage":30,"bgImage":31,"posterImage":208,"relatedSolution":209},107,"monitorer-vps-netdata",{"fr":195,"en":197,"ar":198,"es":199},"monitor-your-vps-in-real-time-with-netdata","راقب-خادمك-الافتراضي-vps-في-الوقت-الفعلي-باستخدام-netdata","monitorizar-vps-en-tiempo-real-con-netdata","Monitorer votre VPS en temps réel avec Netdata","Installez Netdata sur votre VPS pour un monitoring temps réel par seconde : milliers de métriques, zéro configuration, alertes incluses.",3,"2026-03-05T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[207],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitorer-vps-netdata-poster.svg",{"categorySlug":174,"appSlug":210},"netdata",true,1794270775999]