Fail2ban sur une passerelle VPN : ce qu'il corrige et ce qu'il ne corrige pas

Chaque service exposé reçoit le même conseil : mettez fail2ban dessus. Pour une passerelle VPN, ce conseil n'est ni faux ni suffisant, et le traiter comme une case à cocher de durcissement est précisément ce qui laisse les gens avec une prison (jail) qui ne bloque rien d'utile. Fail2ban lit les enregistrements d'échec vers lesquels vous le pointez et demande à un backend d'application de bannir les sources correspondantes. Toute sa valeur dépend de la surface d'authentification qui a produit l'enregistrement, de savoir si l'adresse qu'il contient est le vrai client, et de ce qui arrive à tous les autres derrière cette adresse.

Ce qu'est fail2ban, mécaniquement

Un filtre fait correspondre des lignes d'un journal, une prison compte les correspondances par source, et une action applique un bannissement via un backend de pare-feu. Trois pièces mobiles, et chacune peut être fausse indépendamment.

Aucune des trois ne touche au chemin d'authentification : fail2ban réagit à des preuves après coup et ne valide jamais lui-même un identifiant. Une prison peut donc tourner proprement pendant que la surface qu'elle nomme reste exactement aussi exposée qu'avant.

L'écouteur de tunnel n'est pas un formulaire de connexion

Un écouteur OpenVPN protégé par tls-auth ou tls-crypt rejette les paquets dépourvus de la protection du canal de contrôle avant que le traitement TLS ordinaire ne commence. Un scanner qui n'a jamais la clé ne génère rien que votre filtre puisse compter. L'authentification par certificat ajoute une autre porte, car il n'y a pas de mot de passe à deviner. Le projet Fail2ban documente un modèle général piloté par les journaux, et un filtre VPN générique ne transforme pas un paquet non authentifié en événement d'échec significatif.

Si la passerelle n'accepte que des certificats, l'histoire de force brute contre laquelle vous vous défendez n'existe peut-être pas du tout sur ce port.

Alors, quelle surface protégez-vous ?

Le même hôte expose souvent trois choses différentes : l'écouteur de tunnel, un portail de profils clients ou en libre-service, et une page d'administration. Le portail et la page d'admin ont des formulaires de mot de passe et produisent des lignes de journal qu'un filtre peut compter. Le tunnel ne produit peut-être que des erreurs de poignée de main qui signifient tout autre chose. Faites correspondre la prison à la surface, pas au nom du produit.

Une prison qui surveille le mauvais journal est pire qu'aucune, car elle crée de la confiance sans couverture. Pointez un filtre de connexion vers les erreurs de poignée de main du tunnel : le compteur se déclenchera sur des scanners qui n'ont jamais eu de clé, tandis qu'une attaque par mot de passe contre le portail restera non comptée. Lisez la ligne de journal que le filtre fait correspondre avant de faire confiance au chiffre de la prison.

L'attribution de la source est le maillon faible

Un bannissement ne vaut que ce que vaut l'adresse qu'il vise. Quand le service se trouve derrière un proxy inverse local, l'adresse du client dans le journal peut être celle du proxy, et le bannir supprime tout le monde. Faire confiance à un en-tête transmis depuis une source non fiable donne à un attaquant la capacité de bannir des adresses arbitraires. Sur UDP, les adresses source peuvent être usurpées, donc les compter mérite plus de soin que compter une connexion TCP aboutie.

Consignez la méthode d'attribution de la source dans le README de la prison, car un en-tête transmis depuis un saut non fiable transforme un bannissement en arme.

Le coût collatéral, ce sont les autres

Plusieurs employés derrière un NAT de bureau partagent une adresse, si bien qu'un seul mot de passe enregistré obsolète peut verrouiller tout le site une fois le seuil franchi. Le journal montre une source et un compte qui ont échoué, pas une panne de tout le site.

Des bannissements courts et des seuils modestes réduisent cela, et un chemin de débannissement documenté réduit la charge de support quand cela arrive quand même. L'adresse est un signal grossier plutôt qu'une identité, et la personne qui ouvre le ticket décrira la panne, pas le seuil.

Quand l'adopter, et quand corriger autre chose

Adoptez-le quand il existe un échec de connexion en ligne réel, attribuable et répété sur une surface que vous contrôlez, et quand le backend d'application couvre réellement cette surface. Corrigez autre chose quand le problème est une politique d'identifiants faible, une page d'administration exposée à internet, ou un compte qui se connecte avec succès parce qu'il a été compromis. Un bannissement ne peut réparer aucun de ces points et ne peut pas absorber le trafic qui a déjà saturé votre liaison montante. Ce dernier problème appartient à l'amont, à quelqu'un qui peut filtrer avant que les paquets ne vous atteignent.

Gardez chaque prison liée à une seule surface, examinez les faux positifs, et mesurez le travail d'authentification évité plutôt que le nombre d'adresses bannies.