Prévention d'intrusion

Prévention d'intrusion à la fail2ban : Gately repère les attaques par force brute dans les journaux, pose des pièges sur les ports inutilisés, compte les scans de ports, ajoute les IP malveillantes à une liste de bannissement et la synchronise avec le pare-feu du système (nftables), qui rejette tout leur trafic dans le noyau.

Fonctionnalités

• Règles de journaux : lisent des fichiers journaux, le journal systemd, la sortie d'une commande (comme logread -f sur OpenWrt) ou les journaux d'un conteneur Docker, repèrent les échecs avec des expressions régulières et bannissent l'IP qui atteint le nombre d'échecs dans la fenêtre de temps. Des modèles sont fournis pour SSH, Dropbear, Nginx, Vaultwarden, Home Assistant, Proxmox VE et d'autres, et l'éditeur permet de coller des lignes d'exemple pour tester les filtres ;
• Événements Gately : les échecs de connexion à la console et les blocages du WAF peuvent aussi alimenter une règle, sans expression régulière ;
• Ports pièges : pièges sur des ports que cet hôte n'utilise pas (23, 135, 1433, 3389, 5900, 6379 et d'autres par défaut). Toute source qui s'y connecte est bannie ;
• Détection de scan de ports : une source qui se connecte à des ports fermés de cet hôte plus souvent que le seuil par minute est bannie ;
• Une seule liste de bannissement : les bannissements manuels (réseaux CIDR et bannissements permanents compris) et ceux déclenchés par les échecs d'authentification du service web sont gérés ici. Les bannissements sont enregistrés et restaurés après un redémarrage ;
• Bannissements progressifs : si une adresse est de nouveau bannie dans les 30 jours, la durée double jusqu'à un maximum ;
• Liste blanche : les adresses du LAN, de bouclage, de 100.64.0.0/10 (Tailscale) et les réseaux IPv6 /64 des interfaces de cet hôte sont ignorés par défaut (les bannissements portent sur le /64, ce qui évite de bannir avec le fautif les appareils du LAN en IPv6 publique), et vous pouvez ajouter des IP ou des réseaux. Une seule adresse IPv6 en liste blanche protège tout son /64.

Portée des bannissements

Environnement	Effet d'un bannissement	Ports pièges	Détection de scan
Linux (root ou CAP_NET_ADMIN, nftables installé)	Tout le trafic est rejeté dans le noyau, y compris SSH, les autres programmes et le trafic redirigé vers des conteneurs Docker et des appareils du LAN	Gérés par le noyau, repèrent les scans qui n'envoient que des SYN	Disponible
Docker (réseau host + cap_add: NET_ADMIN)	Comme ci-dessus, les règles sont écrites sur l'hôte	Idem	Disponible
Paquet fnOS, OpenWrt 22.03 et versions ultérieures	Comme ci-dessus (exécution en root, nftables inclus)	Idem	Disponible
Autres cas (Windows, macOS, FreeBSD, Linux sans nftables ou sans autorisation)	Uniquement les services de Gately : redirection de ports, service web, STUN, WebDAV, FTP et console d'administration	Gately écoute lui-même, ne repère que les connexions qui terminent la poignée de main	Indisponible

Le haut de la page affiche l'état de la synchronisation du pare-feu et, si elle est indisponible, la raison et la marche à suivre.

Règles du pare-feu

Avec « Synchroniser avec le pare-feu » activé, Gately crée sa propre table inet gately dans nftables et ne touche pas aux règles du système (fw4, Docker, ufw, etc.) :

• La chaîne prerouting (priorité -190, après le suivi de connexion et avant le NAT de destination) rejette les paquets venant des adresses bannies, qu'ils soient destinés à cet hôte ou redirigés vers un conteneur ou un appareil du LAN. Les réponses aux connexions que cet hôte ouvre lui-même (DNS, miroirs de paquets, etc.) passent toujours, même si l'autre extrémité est bannie. En IPv6, le bannissement porte sur le /64 ;
• La chaîne input ne regarde que les nouvelles connexions vers cet hôte, pour les ports pièges et la détection de scan. Les adresses en liste blanche sont ignorées ;
• Toute la table est supprimée quand la synchronisation est désactivée ou que Gately s'arrête. Si un autre programme la supprime, Gately la réécrit en moins de 10 secondes.

« Voir les règles » sur la page affiche l'ensemble des règles en place.

Docker

Utilisez network_mode: host et accordez NET_ADMIN pour que les règles soient écrites sur l'hôte :

    network_mode: host
    cap_add:
      - NET_ADMIN

Sans cela, les bannissements s'appliquent toujours aux services de Gately. Pour lire les journaux de l'hôte, montez le répertoire des journaux dans le conteneur, par exemple - /var/log:/var/log/host:ro, et indiquez /var/log/host/auth.log dans la règle. La source « journal systemd » n'est pas disponible dans un conteneur.

Règles de journaux

Source	À indiquer	Remarques
Fichier journal	Chemins de fichiers, un par ligne	Lit les nouvelles lignes depuis la fin du fichier et suit la rotation (renommage ou troncature)
Journal systemd	Unités de service comme ssh.service	Lu via journalctl -f
Sortie de commande	Une commande comme logread -f	Relancée si elle s'arrête
Conteneur Docker	Nom du conteneur	Lu via la connexion Docker du module Docker
Événement Gately	Échec de connexion / blocage WAF	Les événements contiennent l'IP source, aucun filtre n'est nécessaire

Les filtres sont des expressions régulières Go (syntaxe RE2), une par ligne, où <HOST> représente l'adresse source, par exemple :

Failed password for (?:invalid user )?\S* ?from <HOST>

Les lignes correspondant à une « Exclusion » ne sont pas comptées. La fenêtre de temps, le nombre d'échecs et la durée du bannissement se règlent par règle ; la durée peut être celle par défaut, personnalisée ou permanente.

Compromis de la détection de scan

La détection compte les nouvelles connexions vers des ports sur lesquels cet hôte n'écoute pas. Les ports TCP en écoute sont actualisés toutes les 10 secondes et comptent comme ouverts ; les ports redirigés ailleurs par d'autres règles de pare-feu ne passent pas par la chaîne input et ne sont pas comptés. Le seuil par défaut est de 12 par minute. Un client normal réessaie un port fermé environ 5 fois par minute, donc ne descendez pas sous 10.

Les ports pièges en cours d'utilisation sont exclus automatiquement pour ne pas bannir de visiteurs légitimes.

Lien avec le service web

Les bannissements de « Bannir après des échecs d'authentification » du service web vont dans la même liste ; avec la synchronisation activée, ils s'appliquent donc à tout l'hôte et plus seulement aux sites web. Avec « Ignorer les adresses du LAN » activé, les adresses du LAN ne sont jamais bannies automatiquement.

Le service web et le WAF ne connaissent l'adresse réelle du client que par le protocole PROXY. Pour les sites derrière un CDN qui transmet l'IP réelle dans un en-tête, les bannissements après échec d'authentification et la règle « Blocages du WAF » banniraient les nœuds du CDN : ne les activez pas pour ces sites.

Notifications

Les bannissements déclenchent l'événement Prévention d'intrusion : IP bannie, auquel vous pouvez vous abonner dans le Centre de notifications. Les adresses bannies par les ports pièges et la détection de scan lors d'une même vérification sont regroupées en une seule notification.

Vérification

Vérifié dans des espaces de noms réseau isolés sur fnOS (Debian 12, nftables 1.0.6) et iStoreOS 24.10 (nftables 1.1.1) : les ports pièges et la détection de scan (IPv4 et IPv6) bannissent dans le noyau et sont importés dans la liste ; les fichiers journaux (rotation comprise), le journal systemd, les journaux de conteneurs Docker et les échecs de connexion à la console déclenchent des bannissements ; les bannissements manuels de réseaux et permanents, le débannissement, les durées progressives, la restauration après redémarrage, la réécriture après suppression externe de la table et le nettoyage à l'arrêt fonctionnent comme prévu ; un conteneur Docker sans NET_ADMIN est signalé comme manquant d'autorisation et passe aux ports pièges en espace utilisateur.