Filtre Fail2ban pour OpenVPN Access Server : real_ip et jails

Vous avez copié un OpenVPN jail depuis un billet de la communauté, redémarré fail2ban, et aucune adresse n'est jamais bannie. La cause est presque toujours le format du journal : l'Access Server n'écrit pas les lignes d'échec d'authentification qu'attend un filtre standard. Avant de toucher au filtre, confirmez que les enregistrements existent, car un motif ne peut pas correspondre à ce que le service n'a jamais journalisé.

Voici la procédure que je suis sur un hôte Access Server : confirmer la forme de l'enregistrement, écrire une expression ancrée, la tester contre le journal réel, puis séparer les jails selon la surface attaquée et vérifier que le bannissement atteint le pare-feu.

Confirmez que l'enregistrement d'échec existe

L'Access Server écrit ses propres lignes structurées dans /var/log/openvpnas.log, et l'adresse du client se trouve dans un champ real_ip entre guillemets, pas au début d'une ligne syslog. Cherchez une connexion échouée dont vous savez qu'elle a eu lieu avant d'écrire le moindre motif :

grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20

Si rien n'apparaît, le niveau de journalisation est le suspect suivant. L'Access Server dispose d'un commutateur de débogage de la base de journaux dans /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), et le service doit être redémarré après l'avoir modifié. Traitez ce commutateur comme un réglage de diagnostic à redescendre une fois votre motif obtenu, et non comme une configuration permanente.

Pendant que vous êtes dans le fichier, notez quelles surfaces y écrivent. Les échecs du portail client, de l'interface d'administration et de l'authentification du tunnel arrivent dans le même fichier avec des marqueurs différents, et ce détail décide plus tard de la disposition des jails.

Ancrez un filtre sur real_ip

Gardez l'expression étroite. Un filtre qui revendique toute ligne contenant une adresse IP bannira des gens pour de simples déconnexions, et sur un serveur chargé le seul symptôme est que les utilisateurs se plaignent d'avoir été bloqués pour avoir fermé un portable. Revendiquez l'enregistrement d'erreur et capturez l'adresse entre guillemets :

# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =

L'espace de tête n'est pas cosmétique. L'Access Server indente ses enregistrements, et s'y ancrer empêche le motif de revendiquer aussi des lignes émises par des services sans rapport qui écrivent dans le même fichier. Si vos enregistrements portent plutôt un horodatage en tête, faites correspondre ce préfixe, mais ancrez-vous sur quelque chose réellement présent dans chaque enregistrement que vous comptez revendiquer.

Lorsque vous avez besoin de précision par surface, restreignez encore en exigeant le marqueur de surface (WEB_CLIENT, WEB_ADMIN ou VPN) sur la même ligne. Un seul filtre à trois motifs est plus facile à auditer que trois filtres qui diffèrent d'un mot.

Testez l'expression avant d'activer un jail

N'activez jamais un filtre que vous n'avez pas exécuté contre le journal de production. Le test documenté passe le filtre deux fois, une fois pour le charger et une fois pour l'appliquer, et le rapport des lignes manquées est la partie qui vaut la lecture :

fail2ban-regex --print-all-missed /var/log/openvpnas.log \
  /etc/fail2ban/filter.d/openvpnaccess.local \
  /etc/fail2ban/filter.d/openvpnaccess.local > missed.txt

Comparez le nombre de correspondances avec les échecs que vous avez vérifiés à la première étape. Aucune correspondance signifie que le motif est faux ; des correspondances sur des lignes qui ne sont pas des échecs d'authentification signifient qu'il est trop large. Lisez missed.txt jusqu'à pouvoir expliquer chaque ligne que vous avez choisi de ne pas revendiquer.

Faites ce test sur une copie si le journal est volumineux, et refaites-le après toute mise à jour de l'Access Server. Le format du journal est l'interface contre laquelle vous faites correspondre, et ce n'est pas une API stable.

Séparez les jails par surface, pas par démon

Un Access Server présente plusieurs surfaces d'authentification : les interfaces web client et d'administration sur 943/tcp, et le tunnel sur 1194/udp ou 443/tcp dans la plupart des déploiements. Un jail unique qui les couvre toutes permet aux tentatives de deviner sur le tunnel de bannir une adresse qui est aussi votre voie d'administration, et il masque quelle surface est réellement attaquée. Donnez à chaque surface son propre jail avec son port et ses seuils :

# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled  = true
port     = 943
protocol = tcp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime  = 1h
[openvpnas-tunnel]
enabled  = true
port     = 443
protocol = udp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime  = 1h

Commencez avec de petits compteurs et un bannissement court, puis augmentez-les une fois une semaine de trafic réel observée. Un seuil généreux sur une adresse de bureau partagée punit tous les utilisateurs derrière un seul NAT, et un bannissement agressif sur la surface du tunnel déconnecte des clients légitimes dont les identifiants stockés ont expiré pendant la nuit.

Vérifiez le bannissement, le backend et les dégâts collatéraux

Après un redémarrage, la sortie de statut est la confirmation la plus rapide que le jail existe et compte :

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Confirmez ensuite que le bannissement atteint le pare-feu que vous exploitez réellement, car un jail configuré pour un backend que personne n'applique ne protège rien. Avec l'action iptables, les adresses apparaissent dans une chaîne portant le nom du jail (f2b-openvpnas-tunnel) ; avec l'action nftables, elles atterrissent dans un ensemble de la table propre à fail2ban. Vérifiez celle que votre hôte utilise au lieu de la supposer.

Deux vérifications collatérales comptent plus que le bannissement lui-même. D'abord, vérifiez que real_ip est l'adresse du client et non un répartiteur de charge ou un proxy inverse ; derrière un proxy, chaque bannissement tombe sur le proxy et emporte tout le service avec lui. Ensuite, écrivez la procédure de débannissement, car l'adresse qui franchit le seuil à 02:00 appartient généralement à l'ingénieur d'astreinte : fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Gardez la limite en tête pendant le réglage. Fail2ban est un limiteur de débit sur une surface d'authentification, pas une couche de contrôle d'accès. Il ne remplace ni le MFA, ni les restrictions par compte, ni le maintien de l'interface d'administration hors d'Internet, et l'Access Server a ses propres réglages d'autoban qu'il vaut la peine de vérifier avant d'empiler deux limiteurs de débit sur le même port.