Ldfa

Traduction approuvée. fr.ini

There are new strings to translate in the Maxthon pour Windows project. You were a project participant previously so your help will be appreciated a lot. 2 new strings for translation (8 words).

MAJ du 20/04/2026 avec de nombreuses corrections de bugs.

Un très bon article en français sur le sujet : https://vblog.io/pegaprox-je-suis-bluffe/

C'est quelque chose qui m'attire de plus en plus, même si je suis dans une zone très peu desservie...

Je viens de l'installer sur mon Homelab et ça a l'air vraiment très prometteur.

Korben Publié le 18 avril 2026 Par Korben, Manuel Dorne korben.info Environ 2 minutes de lecture L'interface web de Proxmox (l'outil de virtualisation que tout bon homelabber connaît), c'est bien... pour UN serveur. Dès que vous commencez à empiler les nodes et les clusters, ça devient vite le bazar avec 15 onglets ouverts. PegaProx , c'est tout simplement un dashboard open source qui unifie tout ça dans un seul écran. Et vous allez voir, le truc cool, c'est que ça gère aussi les clusters XCP-ng ! L'interface de PegaProx - une vue unifiée de tous vos clusters Proxmox et XCP-ng Concrètement, vous branchez tous vos hyperviseurs sur cette interface web (port 5000) et hop, vous avez la vue complète. VMs, conteneurs, métriques de perf... tout remonte en temps réel via Server-Sent Events. Du coup, plus besoin de jongler entre les interfaces de chaque node pour savoir quel serveur rame. Côté fonctionnalités, accrochez-vous les amis parce que pour une beta, c'est déjà bien garni ! Migration live de VMs entre nodes, gestion du stockage Ceph, consoles navigateur via noVNC et xterm.js, et même de la migration cross-hypervisor entre ESXi, Proxmox VE 8.0 et XCP-ng (encore expérimental côté ESXi, mais ça avance). Y'a aussi des règles d'affinité pour placer vos VMs, du rolling update avec évacuation automatique, et des alertes sur les seuils CPU/RAM/disque. Pour une beta, c'est assez dingue ce qu'ils ont déjà mis dedans. Côté sécurité, c'est pas en reste non plus. Y'a du RBAC avec 3 rôles (Admin, Operator, Viewer, pas plus pas moins), du TOTP pour le 2FA, de l'intégration LDAP et OIDC compatible Active Directory, Entra ID, Keycloak ou Google Workspace, du chiffrement AES-256-GCM pour stocker les credentials en base, et même du scan de CVE via debsecan. Autrement dit, ils ont pensé aux admins sérieux. Pour ceux qui ont déjà configuré un provider OIDC sur leur homelab , ça se branche directement. Pour l'installer, le plus simple c'est Docker. Un docker compose up -d, 30 secondes d'attente, et c'est plié. Mais y'a aussi un script de déploiement automatique, un repo APT communautaire maintenu par gyptazy, ou le classique git clone + pip pour les puristes. Une fois lancé, vous pointez votre navigateur sur https://votre-ip:5000, et un assistant vous accueille avec les identifiants par défaut (pegaprox/admin, à changer immédiatement bien sûr). L'interface est dispo en 5 langues : français, anglais, allemand, espagnol et portugais. D'ailleurs, si vous utilisez déjà ProxMenux pour administrer votre Proxmox en terminal, les deux sont en fait complémentaires. Disons que ProxMenux couvre l'admin système en ligne de commande, alors que le dashboard apporte la vue unifiée multi-clusters en web. Initialement j'aurais dit que c'était redondant, mais non, ça se marie plutôt bien. Et y'a même un système de plugins avec un portail client pour vos utilisateurs et une page de statut publique à la StatusGator. Attention c'est comme je vous le disais, encore une beta. L'OIDC avec Authentik par exemple, ça fonctionne pour le login mais les groupes ne remontent pas encore correctement (retour d'un lecteur qui l'utilise au quotidien). Par contre si vous n'avez qu'un seul serveur Proxmox, honnêtement c'est un peu overkill, l'interface native suffit largement. Quelques glitchs traînent ici ou là, et l'API Token pour se connecter à la place de root n'est pas super bien documenté. Mais le projet avance vite donc c'est plutôt bon signe ! Bref, ça promet pas mal. Merci à Maxime pour la découverte ! Afficher l’article complet

Geeek.org Publié le 16 avril 2026 Par Ludovic Toinel geeek.org Environ 4 minutes de lecture Impossible de se connecter en zone blanche, festival bondé, coupure réseau, rando en montagne... Dans tous ces cas, votre smartphone se transforme en brique. Et si une technologie radio open source, un appareil à 30 €, et un développeur normand passionné avaient la solution ? C'est exactement l'histoire de meshnetwork.fr. C'est quoi Meshtastic ? Meshtastic, c'est un réseau de communication décentralisé qui fonctionne sans internet, sans opérateur, sans infrastructure. Il repose sur la technologie LoRa (Long Range), une radio basse consommation capable d'envoyer des messages sur des kilomètres avec un matériel minuscule. Le principe du "mesh" est simple mais puissant : chaque nœud du réseau relaie automatiquement les messages des autres. Plus il y a d'appareils dans la zone, plus la portée s'étend et plus le réseau devient résilient. Résultat : Portée jusqu'à plusieurs dizaines de kilomètres en milieu dégagé Chiffrement AES-256 de bout en bout sur chaque message Zéro abonnement, zéro opérateur, zéro serveur central 100 % open source — firmware, appli, protocole Les usages sont concrets : rando, événements, situations dégradées, communication hors-réseau entre équipes... ou juste le plaisir de bidouiller un réseau parallèle à Internet. Se lancer : du matériel accessible et une config en quelques minutes Bonne nouvelle : pas besoin d'un labo d'ingénieur. Des appareils comme le LilyGO T-Beam ou le Wio Tracker L1 Pro font très bien l'affaire pour commencer. Budget : entre 15 € et 80 €, certains avec écran OLED intégré et batterie autonome. La mise en route se fait en 3 étapes : Acheter un appareil LoRa compatible (Heltec, LilyGo, RAK Wireless, Seeed Studio...). Le détail des appareils compatibles est disponible sur le site de meshtastic. Flasher le firmware Meshtastic via flasher.meshtastic.org, configurer la région 'EU_868' en France Connecter l'appli mobile (iOS / Android / Web) en Bluetooth et c'est parti Une fois allumé, votre noeud rejoint le réseau et commence déjà à relayer les messages autour de lui. L'expérience est étonnamment fluide pour quelque chose d'aussi "low-tech" en apparence. Des communautés actives mais dispersées L'écosystème Meshtastic est porté par des communautés locales très engagées, chacune avec ses canaux, ses fréquences, ses conventions. En France, la référence s'appelle Gaulix. Le revers de la médaille : l'information est fragmentée. Pas toujours évident de savoir qui est actif près de chez soi, comment se connecter efficacement, ou quels paramètres utiliser pour rejoindre le réseau national. C'est exactement le problème qu'a décidé de résoudre Yohann Ciurlik, développeur fullstack normand et bidouilleur de la première heure. Meshnetwork.fr : l'agrégateur qui manquait Yohann a d'abord plongé dans Meshtastic pour son propre setup dans l'Eure, avec deux appareils : Un LilyGO T-Beam configuré en passerelle fixe, connecté en continu au réseau Gaulix Un Wio Tracker L1 Pro en nœud mobile pour tester la portée sur le terrain L'objectif derrière : contribuer à densifier le réseau en Normandie. Plus il y a de nœuds, plus le mesh est intéressant en portée, en fiabilité, en usages possibles. De ce constat est né meshnetwork.fr. Le site ne réinvente pas l'écosystème, il le rend lisible. Au programme : 🗺️ Une carte temps réel des nœuds Meshtastic en France, agrégée depuis MeshMap.net, Liam Cottle et Gaulix — plus de 1 849 nœuds français référencés ⚙️ Un guide de configuration complet pour le firmware 2.5.x, avec les valeurs recommandées par la communauté (canal Fr_Balise, fréquence 869.4625 MHz, etc.) 🤝 Les communautés locales pour trouver facilement des gens actifs près de chez soi 📱 Les applications sur toutes les plateformes pour démarrer sans friction 💡 Côté stack technique : Yohann a construit le site en mode vibe coding avec Claude Sonnet et GitHub Copilot, hébergé sur Render. Pour qui c'est intéressant ? Les randonneurs et aventuriers qui veulent rester joignables hors réseau Les makers et bidouilleurs attirés par la radio et les réseaux décentralisés Les geeks de la résilience soucieux de communication en cas de crise ou de black-out Ceux qui veulent juste explorer un réseau parallèle à Internet pour le fun Les limites à connaître avant de se lancer Meshtastic n'est pas WhatsApp. LoRa sacrifie le débit pour la portée, chaque message est limité à 228 caractères, et le canal tourne à 3–5 messages par minute avec le preset par défaut. En France, la bande 868 MHz impose en plus un duty cycle légal de 10% : votre nœud ne peut émettre que 6 minutes par heure maximum. La bonne nouvelle ? C'est exactement pour ça que meshnetwork.fr et Gaulix publient leurs recommandations de config : hop limit à 3, annonces de position toutes les 6h, duty cycle non surchargé. Suivez le guide pour optimiser l'utilisation du réseau. En résumé Meshtastic, c'est l'une de ces technos qui fascinent parce qu'elles font quelque chose de concret, de simple et de souverain. Meshnetwork.fr est le portail qui manquait pour s'y mettre sans se perdre dans la doc éparpillée des différentes communautés. Cette initiative ressemble aux réseaux Wifi communautaires du début des années 2000 que l'on mettait en place avec le protocole de routage dynamique OLSR pour permettre de faire transiter des messages sur un réseau mesh Wifi. Bravo à Yohann pour le boulot et si vous êtes en Normandie, vous savez maintenant qu'il y a un noeud actif dans l'Eure qui n'attend que des voisins. Demain, j'installe mon noeud à Nantes ! Et vous, vous avez déjà un setup Meshtastic ? On en discute dans les commentaires ou sur le serveur Discord Geeek ! Quelques Liens utiles : 💡L'article de Yohann qui présente son projet 🌐 meshnetwork.fr 📖 meshtastic.org 🇫🇷 gaulix.fr 🗺️ meshmap.net Lire d'autres articles de cet auteur Ludovic Toinel Geeek.org est un blog 100% indépendant depuis 21 ans. Passionné de web, dev et tech, il réunit plus de 20k lecteurs sur le feed RSS et 90k visites mensuelles. Abonnez-vous ! Afficher l’article complet

Korben Publié le 17 avril 2026 Par Korben, Manuel Dorne korben.info Environ 3 minutes de lecture Quand on fait du self-hosting, y'a toujours ce moment où on se dit "tiens, y'aurait pas un truc open source pour ça". Tenez par exemple, là je suis en train de chercher un machin open source pour un mariage qui permet aux invités de balancer leurs photos sur un serveur en scannant un QR Code. Et donc je me retrouve à scroller awesome-selfhosted sur GitHub, qui est une liste fleuve de +1500 projets, en essayant de deviner lesquels sont encore vivants. Et c'est exactement ce problème qu'a voulu résoudre Ethan Sholly en lançant selfh.st/apps en 2024. En gros, c'est un annuaire d'applications auto-hébergées avec des vrais filtres, du tri, et surtout des indicateurs d'activité. Le mec est aussi derrière la newsletter Self-Host Weekly. L'interface de selfh.st/apps, avec fiches, filtres et indicateurs d'activité Comme ça, au lieu de vous taper une liste brute, vous avez des fiches pour chaque app avec le nombre d'étoiles GitHub, la licence, le langage, les tags, et surtout un code couleur sur la date de dernière activité. Vert si le projet a reçu un commit dans les 6 derniers mois, jaune entre 6 et 12 mois, rouge au-delà d'un an. Pratique pour éviter d'installer un truc que plus personne ne maintient, genre un serveur Plex alternatif mort depuis 2022 ! Et le tri par défaut, c'est pas juste les étoiles GitHub sinon les gros projets à 50 000 étoiles écraseraient tout. L'algo prend en compte l'âge du repo, la date du dernier commit, et même l'intérêt Google Trends pour les projets non-GitHub. Du coup un outil avec 200 stars mais hyper actif peut remonter devant un dinosaure à 30k stars qui dort depuis 18 mois. J'ai trouvé ça pas bête comme filtrage. D'ailleurs, chaque projet a son propre flux RSS filtré qui ne remonte que les releases stables. Pas de bêtas, pas de RC... juste les versions prêtes pour la prod. Comme ça, vous branchez ça dans votre FreshRSS ou Miniflux et vous êtes au courant des mises à jour sans checker chaque repo GitHub à la main ! Par contre, si vous aimez vivre dangereusement sur les nightly, là faudra passer par les flux officiels GitHub. Le site va également plus loin que la simple liste d'apps puisqu'il propose aussi une section "companions", contenant des apps compagnons qui étendent d'autres logiciels auto-hébérgés (genre les extensions navigateur pour Linkedin ou les clients tiers pour Immich...etc). La collection d'icônes pour personnaliser votre Homarr ou Dashy Et surtout, y'a selfh.st/icons avec des milliers d'icônes de dashboard en SVG, PNG et WebP, toutes en 512x512 ratio 1:1, indispensable pour personnaliser votre page d'accueil sur Homarr ou Dashy ! Le catalogue d'apps est sous licence CC0-1.0 (domaine public) et mis à jour tous les matins à 5h du mat' heure de New York (les icônes, elles, sont en CC-BY-4.0, donc pensez à créditer si vous les réutilisez). En 2 minutes de fouille j'y ai trouvé trois projets que je connaissais pas. Et si vous voulez ajouter le vôtre, le repo est ouvert sur https://github.com/selfhst . Et si vous connaissez un outil pour mon projet de QR Code d'upload de photo de mariage, n'hésitez pas à me contacter. Voilà, pour ceux qui font de l'auto-hébergement au quotidien, c'est clairement un bookmark à garder sous le coude. Que vous cherchiez une alternative à Notion, un dashboard pour votre homelab, ou juste un truc pour remplacer un service cloud qui vous gonfle, y'a de quoi fouiller ! Et si vous cherchez des pistes pour commencer, OpenCloud ou Pocket ID sont de bons points de départ. Bref, une mine d'or pour les homelabbers. Merci à Maxime pour le lien ! Afficher l’article complet

Traduction approuvée. fr.ini

Je viens de recevoir ma carte NM-RF-HAT, une carte qui se connecte au ESP32-2432S028 (CYD) et qui lui rajoute des modules RF multibandes sur une seule PCB : CC1101 : émetteur-récepteur sub-1 GHz pour des applications telles que les télécommandes. nRF24L01 : émetteur-récepteur 2,4 GHz prenant en charge les protocoles personnalisés et la communication sans fil. PN532 : module NFC/RFID pour la lecture et l'écriture de balises NFC. IR : émetteur et récepteur infrarouge pour les applications de télécommande infrarouge. RF433 : module émetteur/récepteur ASK (modulation par déplacement d'amplitude) à 433 MHz. Gestion de l'alimentation : fonctions de gestion de l'alimentation intégrées pour garantir une alimentation stable. Interface d'extension GNSS : fournit une interface pour connecter des modules GNSS (Global Navigation Satellite System), prenant en charge les fonctions de positionnement. Emplacement pour carte TF : pour l'enregistrement et le stockage des données, facilitant la gestion des données de projet. Conçu pour CYD : s'intègre de manière transparente à l'ESP32-2432S028 (CYD) via une simple connexion par câble. On, trouve de nombreux Firmware exploitant pleinement ces 2 cartes (CYD + NM-RF-HAT) : Bruce : https://github.com/BruceDevices/firmware HaleHound-CYD : https://github.com/JesseCHale/HaleHound-CYD ESP32 Marauder CYD : https://github.com/Fr4nkFletcher/ESP32-Marauder-Cheap-Yellow-Display Launcher : https://github.com/bmorcelli/Launcher De quoi passer des heures à découvrir toutes les nouvelles fonctionnalités offertes.

There are new strings to translate in the Maxthon pour Windows project. You were a project participant previously so your help will be appreciated a lot. 2 new strings for translation (4 words).

Changements principaux : + Nouvel écran de MAJ à l'adresse URL : mx://mxupdate + Ajout des abonnements « Maxthon Media Plus » et « Maxthon Pro ». * Affichage de la page des membres Maxthon. * Fenêtre contextuelle de paiement pour le téléchargement de vidéos. - Correction d'un problème où le menu du champ de saisie du mot de passe de la page ne comportait pas d'options liées à l'enregistrement du mot de passe - Correction d'un problème où un clic droit sur la barre Super favoris pour gérer les signets ouvrait la page de gestion des signets mais ne permettait pas de localiser le signet. - Correction d'un problème d'erreurs d'interaction de l'interface utilisateur lors de la réinitialisation d'un téléchargement. - Correction d'un problème où les tâches de téléchargement multithread n'étaient pas affichées. - Correction d'un problème où la suppression d'une tâche de téléchargement pouvait également supprimer le fichier. - Correction d'un problème où le mode IE affichait un écran blanc.

Une MAJ de Maxthon 7.5.2.7000 Bêta pour Windows est sorti aujourd'hui, il apporte son lot de nouvelles fonctionnalités, d'améliorations et de corrections de bugs. MAJ du 20/04/2026 - Téléchargement : https://github.com/maxthon/Maxthon/releases/ Les changements en français sont là. Vous pouvez également vous abonner au groupe Telegram NBdomain & MX6 pour faire remonter vos demandes d'améliorations et bugs rencontrés. Source : https://forum.maxthon.com/d/4445-maxthon-7527000-beta-release

Bonne question.

Je termine encore Platine cette semaine ici aussi.

Je termine encore Platine cette semaine.

Changements principaux : * Optimisation de la vitesse de chargement du fond d'écran Nouvel onglet. * Optimisation du style des séparateurs de thèmes dans le menu principal. - Correction d'un problème lié au comportement anormal de la logique de téléchargement de vidéos en mode invité. - Correction d'un problème empêchant la création de tâches de téléchargement multithread. - Correction d'un problème où un clic droit sur la barre « Super Bookmarks » ouvrait le gestionnaire de signets avec un positionnement incorrect. - Correction d'un problème lié au style de la ligne d'invite de téléchargement.

Maxthon 7.5.2.6800 Bêta pour Windows est sorti aujourd'hui, il apporte son lot de nouvelles fonctionnalités, d'améliorations et de corrections de bugs. Téléchargement : https://github.com/maxthon/Maxthon/releases/ Les changements en français sont là. Vous pouvez également vous abonner au groupe Telegram NBdomain & MX6 pour faire remonter vos demandes d'améliorations et bugs rencontrés. Source : https://forum.maxthon.com/d/4375-maxthon-7526800-beta-release (L'agent IA a du retard à l'allumage !!!)

Le support sur le Forum International était assuré jusqu'à aujourd'hui par des humains avec un pseudo commençant par BugSir et des chiffres. Ils ont été remplacés par un agent IA qui tente de répondre aux demandes et aux rapports de bug... Voici son message de présentation : https://forum.maxthon.com/d/4329-meet-tomhardy-your-proactive-forum-assistant- La fréquentation avait fortement baissé après le changement de Forum, mais là, j'ai bien peur que ce soit la fin...

IT-Connect Publié le 1 décembre 2025 Par Mickael Dorigny it-connect.fr Environ 12 minutes de lecture Vous souhaitez apprendre à utiliser Fail2ban ? Cet article est là pour vous guider dans l'installation et la configuration de Fail2ban pour protéger vos services contre certaines attaques et comportements malveillants. Fail2ban est un outil open source conçu pour protéger vos serveurs de certaines attaques en se basant sur les journaux d’évènements. Très simple à installer et configurer, il est aussi hautement personnalisable, ce qui permet de l’intégrer à de nombreux projets, contextes et infrastructures. Son principe est simple : il surveille en temps réel les logs locaux de vos services (SSH, Apache, FTP, etc.), détecte les tentatives d’intrusion répétées, et bloque automatiquement les adresses IP suspectes. Il permet donc d’exposer plus sereinement des services sur le réseau ou Internet. Version originale de cet article : 26 août 2013. Surface d’attaque : pourquoi utiliser Fail2ban ? La surface d’attaque des services exposés Chaque service accessible depuis un réseau, et encore plus sur Internet (SSH, web, FTP, etc.), représente une porte d’entrée potentielle pour un attaquant. Par exemple : Un serveur SSH exposé peut être ciblé par des bots tentant des milliers de combinaisons de mots de passe. Un formulaire de connexion web mal sécurisé peut être la cible de tentatives de brute-force. Un service FTP ouvert peut attirer des scans automatisés à la recherche de vulnérabilités connues. Sans protection, ces attaques augmentent considérablement le risque de compromission de votre système. Imaginez une porte d’entrée avec une serrure basique. Si quelqu’un essaie 100 clés différentes, il finira par entrer. Fail2ban agit comme un système d’alarme qui verrouille la porte après 3 tentatives infructueuses. Si vous souhaitez aller plus loin dans cette notion de surface d’attaque et de tentatives répétées (brute force), je vous invite à consulter nos différents articles : IT-Connect.fr - Analyse et réduction de la surface d’attaque IT-Connect.fr - L’essentiel sur les attaques brute force : principes, types d’attaques et mesures de protection Fail2ban fonctionne de la manière suivante : Fonctionnement de Fail2ban. Ainsi, même si un attaquant dispose d’un dictionnaire de mots de passe, il ne pourra pas les tester indéfiniment, car son adresse IP sera bannie rapidement. Nous allons aussi voir que les actions réalisables par Fail2ban vont au-delà d’un simple bannissement. Fail2ban en pratique : comprendre les principaux concepts Pour comprendre rapidement et facilement Fail2ban, nous allons maintenant aborder quelques-uns des principaux concepts liés à son fonctionnement et sa configuration. Les "prisons" (jails) Une prison (ou jail en anglais) est une règle de surveillance appliquée à un service spécifique (SSH, Apache, etc.). Chaque prison définit : Le service à protéger (ex : SSH, port TCP/22). Le fichier de log à surveiller (ex : /var/log/auth.log pour SSH). Le nombre maximal de tentatives autorisées avant blocage (ex : 5 échecs). La durée du blocage (ex : 10 minutes). Nous allons détailler l’installation et la configuration de fail2ban un peu plus tard dans ce tutoriel, mais pour vous donner une idée, voici un exemple de configuration d’une prison : # Exemple de prison (jail) Fail2ban pour le service SSH [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5 bantime = 600 Les filtres (filters) Les filtres sont des règles de détection écrites en expressions régulières. Elles permettent à Fail2ban d’identifier les lignes suspectes dans les logs. Exemple : une ligne comme Failed password for root from 192.168.1.100 dans /var/log/auth.log déclenchera le filtre sshd. Heureusement, Fail2ban est installé par défaut avec une grande quantité de filtres prêts à l’emploi, notamment pour les services les plus courants. Les actions Lorsqu’une IP est bloquée, Fail2ban peut : Ajouter une règle de pare-feu (iptables/nftables) pour interdire tout trafic depuis cette IP. Envoyer une alerte par e-mail à l’administrateur. Exécuter un script personnalisé (ex : notifier un système de monitoring). Vous êtes libres de créer toutes les actions que vous souhaitez, il faudra alors passer par du scripting bash. Cela rend l'outil hautement personnalisable. Maintenant que nous connaissons ces différents éléments, nous pouvons passer à la pratique. Installation et configuration de Fail2ban Installation du paquet Fail2ban Le paquet Fail2ban est présent dans tous les dépôts des principales distributions UNIX. Nous pouvons donc l’installer via les gestionnaires de paquets habituels : # Sous Debian et dérivés sudo apt update sudo apt install fail2ban # Pour Fedora/RHEL 8+ sudo dnf update sudo dnf install fail2ban # ou pour les anciennes versions (CentOS 7, RHEL 7) sudo yum update sudo yum install fail2ban Cette commande vous permettra de confirmer que le service est bien installé et lancé : # Vérifié l'état du service fail2ban $ systemctl status fail2ban ● fail2ban.service - Fail2Ban Service Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; preset:> Active: active (running) since Fri 2025-11-21 20:18:59 CET; 29s ago Docs: man:fail2ban(1) Main PID: 1162 (fail2ban-server) Tasks: 5 (limit: 4603) Memory: 33.5M (peak: 34.0M) CPU: 261ms CGroup: /system.slice/fail2ban.service └─1162 /usr/bin/python3 /usr/bin/fail2ban-server -xf start Passons à présent à la prise en main de la configuration de Fail2Ban. Configuration initiale de Fail2ban Les fichiers de configuration de Fail2Ban se trouvent dans le dossier /etc/fail2ban/ : # Arborescence de la configuration fail2ban $ tree . ├── action.d │ ├── abuseipdb.conf │ ├── apf.conf │ ├── apprise.conf │ ├── blocklist_de.conf │ ├── [...] ├── fail2ban.conf ├── fail2ban.d ├── filter.d │ ├── 3proxy.conf │ ├── apache-auth.conf │ ├── apache-badbots.conf │ ├── apache-botsearch.conf │ ├── apache-common.conf │ ├── [...] ├── jail.conf ├── jail.d │ └── defaults-debian.conf ├── paths-arch.conf ├── paths-common.conf ├── paths-debian.conf └── paths-opensuse.conf Son organisation est assez claire et gérée de façon modulaire. Chaque fichier .conf situé dans les dossiers jail.d, filter.d et action.d sera lu et interprété au lancement de Fail2ban. Vous pourrez donc y rajouter vos propres configurations. Le fichier de configuration principal de Fail2ban est le suivant : /etc/fail2ban/jail.conf. Il s’agit d’un fichier d’une taille assez conséquente qui est déjà bien rempli. Je vous encourage à prendre le temps de parcourir ses différentes directives pour vous familiariser avec l’outil. Comme son nom l’indique, son rôle est de faire le lien entre les filtres et actions pour créer des prisons (jail) : Extrait du fichier /etc/fail2ban/jail.conf Par défaut, nous voyons par exemple une pré-configuration pour différents services SSH/HTTP qui pointent vers leurs fichiers de logs respectifs. Prenez notamment le temps de consulter les paramètres par défaut définis dans ce fichier, comme le temps de ban par défaut, qui peut être surchargé pour chaque prison que nous allons créer : Paramètres par défaut importants du fichier /etc/fail2ban/jail.conf Non voyons, par exemple, le bantime, findtime et maxretry. Quel que soit le service lié à une prison, Fail2ban cherchera 5 occurrences d'une même expression régulière pour une même IP dans un créneau de 10 minutes. Il déclenchera ensuite un bannissement de cette adresse IP pour 10 minutes. Bonnes pratiques : ne modifiez pas ce fichier directement. Créez plutôt un fichier /etc/fail2ban/jail.d/myconf.conf pour surcharger les paramètres ou les prisons souhaitées. Nous allons, dans ce fichier de configuration personnalisé, créer une prison pour le service SSH avec les caractéristiques suivantes : Service SSH (fichier /var/log/auth.log) Nombre d’essais pour déclencher l’action : 3 authentifications infructueuses Action : bannissement de l’IP pendant 1 heure Exemple de configuration personnalisée (/etc/fail2ban/jail.d/myconf.conf) : # Jail SSH [ssh] enabled = true bantime = 1h maxretry = 3 port = ssh filter = sshd logpath = /var/log/auth.log Notre prison sera identifiée par son nom [ssh]. Nous spécifions ensuite le temps de bannissement, le nombre d’essais maximal toléré, le port (abrégé ici par le nom du service), le filtre associé (ici, un filtre par défaut que vous retrouverez dans /etc/fail2ban/filter.d/sshd.conf) et le chemin vers le fichier de log. Si le port d'écoute de votre service n'est pas celui par défaut, il peut être précisé directement en étant précédé d'une virgule (ex: "port =ssh, 2569,..."). Cela sera utile pour la mise en place des règles de bannissement via nftables/iptables. Pourquoi nous ne spécifions pas d’action ? Dans Fail2ban, l’action par défaut est déjà définie globalement dans le fichier /etc/fail2ban/jail.conf. Cette action est généralement iptables-multiport qui bloque l’IP via le pare-feu : Action par défaut paramétrée dans le fichier /etc/fail2ban/jail.conf Lorsque vous maitriserez pleinement la configuration de Fail2ban, vous pourrez modifier cette action, voir en créer de nouvelles. Si vous êtes curieux et souhaitez savoir exactement comment sont configurées les actions et filtres par défaut auxquels nous faisons ici appel, je vous encourage à consulter le contenu des fichiers suivants : /etc/fail2ban/filter.d/sshd.conf /etc/fail2ban/action.d/iptables-multiport.conf /etc/fail2ban/action.d/iptables.conf Redémarrons à présent Fail2Ban pour appliquer notre nouvelle prison : # Redémarrage du service fail2ban sudo systemctl restart fail2ban Vérifier l’état des prisons Pour savoir quelles sont les prisons actives et opérationnelles, il nous faut utiliser la commande suivante : # Récupérer la liste des prisons actives $ sudo fail2ban-client status Status |- Number of jail: 2 `- Jail list: ssh, sshd Ici, nous en avons 2 : la prison sshd par défaut, et la nôtre ssh. Pour que cela soit plus propre, nous pourrons ensuite désactiver la prison par défaut [sshd] dans le fichier /etc/fail2ban/jail.d/defaults-debian.conf : $ cat jail.d/defaults-debian.conf [DEFAULT] banaction = nftables banaction_allports = nftables[type=allports] backend = systemd [sshd] enabled = false Nous pourrons ensuite à nouveau redémarrer notre service Fail2ban. Tester et valider la protection Simuler une attaque À présent, nous allons simuler un comportement malveillant en lançant 5 tentatives de connexion SSH sur notre serveur avec un mot de passe incorrect. Cela peut être fait manuellement depuis une autre machine du réseau local (ou VM) : # "bruteforce" manuel de notre machine d'attaque vers notre machine protégée ssh root@votre_serveur # <saisie d’un mauvais mot de passe> ssh root@votre_serveur # <saisie d’un mauvais mot de passe> ssh root@votre_serveur # <saisie d’un mauvais mot de passe> ssh root@votre_serveur # <saisie d’un mauvais mot de passe> ssh root@votre_serveur # <saisie d’un mauvais mot de passe> Mais sachez que lors d’une cyberattaque réelle, un attaquant va utiliser des outils automatisés pour effectuer des milliers de tentatives par minute ! Par exemple via l’outil nmap : # Utilisation de nmap pour réaliser un attaque par bruteforce automatisée sur le service SSH $ nmap -p 22 --script ssh-brute --script-args userdb=$USERDB,passdb=$PASSDB 192.168.1.17 Starting Nmap 7.93 ( https://nmap.org ) at 2025-11-21 21:23 CET NSE: [ssh-brute] Trying username/password pair: root:root NSE: [ssh-brute] Trying username/password pair: admin:admin NSE: [ssh-brute] Trying username/password pair: test:test NSE: [ssh-brute] Trying username/password pair: guest:guest NSE: [ssh-brute] Trying username/password pair: info:info Si vous souhaitez apprendre à maitriser l’outil de scan réseau et de recherche de vulnérabilités nmap, je vous oriente vers mon livre (papier ou ebook) dédié à son sujet : Constater le blocage De retour sur notre serveur protégé par Fail2ban, nous pouvons à présent vérifier que l’adresse IP de notre système d’attaque est bloquée. D’abord par ce que vos 4ᵉ et 5ᵉ tentatives n’ont certainement pas abouties : $ ssh [email protected] ssh: connect to host 192.168.1.17 port 22: Connection refused $ ssh [email protected] ssh: connect to host 192.168.1.17 port 22: Connection refused Puis, via la commande Fail2ban nous permettant d'obtenir le statut de notre prison : # Récupérer le status d'une prison Fail2ban précise $ sudo fail2ban-client status ssh Status for the jail: ssh |- Filter | |- Currently failed: 0 | |- Total failed: 3 | `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd `- Actions |- Currently banned: 1 |- Total banned: 1 `- Banned IP list: 192.168.1.16 Nous savons ici que le service SSH a reçu trois tentatives infructueuses d’authentification, et que l’adresse IP 192.168.1.16 a été bannie. Enfin, nous pouvons aussi consulter les journaux d’évènements de Fail2ban afin d’avoir un suivi plus détaillé, et même en temps réel, des évènements : /var/log/fail2ban.log # Contenu récent des journaux d'évènements de fail2ban $ sudo tail -f /var/log/fail2ban.log 2025-11-21 20:38:46,590 fail2ban.jail [18682]: INFO Jail 'ssh' started 2025-11-21 20:38:46,590 fail2ban.filtersystemd [18682]: INFO [ssh] Jail is in operation now (process new journal entries) 2025-11-21 21:08:16,452 fail2ban.filter [18682]: INFO [ssh] Found 192.168.1.16 - 2025-11-21 21:08:16 2025-11-21 21:08:21,129 fail2ban.filter [18682]: INFO [ssh] Found 192.168.1.16 - 2025-11-21 21:08:20 2025-11-21 21:08:24,433 fail2ban.filter [18682]: INFO [ssh] Found 192.168.1.16 - 2025-11-21 21:08:24 2025-11-21 21:08:25,225 fail2ban.actions [18682]: NOTICE [ssh] Ban 192.168.1.16 Le comportement de Fail2ban est ici bien visible : il a trouvé trois matchs pour son filtre pour les logs SSH (expression régulière), tous liés à une même adresse IP, qu'il a ensuite décidé de bannir. Nous avons ici les détails de l’attaque, heure, adresse IP, service, puis la décision de Fail2ban concernant le bannissement de l’adresse IP. Lorsqu’une adresse IP est retirée du pool des adresses bloquées, cette décision est également journalisée : 2025-11-21 21:24:28,409 fail2ban.actions [19341]: NOTICE [ssh] Unban 192.168.1.16 Nous venons ici de voir la configuration simple d’une prison SSH avec travers les principaux paramètres utiles. Mais Fail2ban est très complet etpeut couvrir de nombreux services, même avec ses règles et ses filtres par défaut. Je vous encourage à consulter toute sa configuration et notamment les différentes actions possibles (/etc/fail2ban/action.d/). Vous pourrez aussi constater la présence de la règle de blocage sur votre gestion de règles de pare-feu (iptables -L ou nft list ruleset). Attention ! Même si votre configuration Fail2Ban mentionne iptables, il est probable que ce soit nft (nftables) qui soit en fait utilisé en arrière-plan, notamment sur les systèmes récents. Conclusion Fail2ban est un outil simple mais puissant pour automatiser la protection de vos services exposés. En quelques minutes, vous réduisez significativement le risque d’intrusion par force brute, sans effort manuel. Il faut cependant aussi être conscient des limites de cet outil, il ne s’agit pas d’un système qui va bloquer 100% des attaques possibles. On parle notamment des failles 0-Day ou de tout autre type d’attaque qui, soit ne génère pas les logs nécessaires à leur blocage, soit ne se base pas sur des patterns connus. Égarement, la génération d’actions et de filtres qui n’existent pas déjà dans l’outil nécessite de bonnes compétences système et réseau, mais aussi des compétences en scripting. Et vous, utilisez-vous déjà Fail2ban ? Quelles prisons avez-vous configurées ? Partagez vos retours en commentaires ! FAQ Peut-on utiliser Fail2ban sur Windows ? Non, Fail2ban est conçu pour les systèmes UNIX/Linux (Debian, Ubuntu, CentOS, etc.) et dépend d’outils comme iptables/nftables, absents sur Windows. Fail2ban est-il efficace contre les attaques DDoS ? Non, Fail2ban n’est pas conçu pour les DDoS (Distributed Denial of Service). Il bloque des IP individuellement, pas des flux massifs. Solutions complémentaires : Utilise un CDN (Cloudflare, Akamai) pour absorber le trafic. Configure des règles de rate-limiting côté pare-feu ou load balancer. Quelles sont les alternatives à Fail2ban ? Fail2ban est l’outil le plus connu pour bloquer les attaques par force brute, mais il existe d’autres solutions : DenyHosts : similaire à Fail2ban, mais spécifique à SSH. CrowdSec : outil moderne, collaboratif et open source, qui partage des listes d’IP malveillantes entre utilisateurs (consultez nos articles sur CrowdSec) Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense. Afficher l’article complet