Fail2ban sur wazo-ui

Salut à tous,

J’ai besoin de mettre un wazo-ui sur le web du coup je voudrais le protéger avec du f2b.

Mon problème est que que je ne trouve pas les logs où je peux récupérer les IPs. Si j’ai bien compris tout fonctionne autour de wazo-auth mais je ne trouve pas d’ip.

Est-ce que quelqu’un a une idée ?

Merci d’avance :wink:

Je te déconseille de mettre wazo-ui directement sur le net sur le port 443 par défaut. Si possible, installe un VPN, un tunnel SSH ou une restriction d’IP pour être sur que personne d’autre ne peut y accéder. Sinon, au moins expose-le sur un autre port que 443, ou sur un autre nom de domaine “secret”, pour qu’il soit moins inondé de requêtes.

Pour fail2ban, les logs de wazo-auth sont dans /var/log/wazo-auth.log, il devrait contenir l’IP de chaque requête. Sinon dans /var/log/nginx/wazo.access.log, tu auras aussi les requêtes à wazo-ui.

Salut @sduthil,

Merci pour ton retour et effectivement, c’est pas le top mais je n’ai pas le choix :confused:

Le f2b vient en complément de certaines des préco que tu me donnes, c’est justement pour renforcer au maximum.

J’ai déjà trouvé les logs que tu m’as donné mais dans l’un j’ai l’auht fail mais pas l’ip et dans l’autre j’ai l’ip mais pas l’auth fail, je te colle les logs d’une tentative infructueuse que tu vois ce que je veux dire :

==> /var/log/wazo-auth.log <==
2025-07-04 17:55:20,030 [1220] (INFO) (wazo-auth): request: POST http://localhost:9497/0.1/token {'Host': 'localhost:9497', 'Accept-Encoding': 'identity', 'Connection': 'close', 'User-Agent': 'Wazo Python auth client', 'Accept': 'application/json', 'Authorization': 'Basic <hidden>', 'Content-Type': 'application/json', 'Content-Length': '21'} with data {"expiration": 43200}
2025-07-04 17:55:20,246 [1220] (INFO) (wazo_auth.plugins.http.tokens.http): Failed login: unknown username or password for login root from 127.0.0.1 using agent "Wazo Python auth client"
2025-07-04 17:55:20,247 [1220] (INFO) (wazo-auth): response to 127.0.0.1 in 0.22s: POST http://localhost:9497/0.1/token 401
==> /var/log/nginx/wazo.access.log <==
xxx.xxx.xxx.xxx - - [04/Jul/2025:17:55:20 +0200] "POST /login/ HTTP/1.1" 200 6634 "https://FQDN/login/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0" "-" 885 1751644520.343 0.334 127.0.0.1:9296 6634 0.332 200

xxx.xxx.xxx.xxx correspond bien à l’ip à bloquer mais je ne sais pas comment faire le filtre f2b ou faire la corrélation entre les 2 logs

Je pourrais faire un script qui sniff les 2 logs pour n’en fait qu’un et faire le lien par le timestamp mais il suffit que j’ai 2 connexions en même temps ou que le script déconne et ça ne fonctionne plus.
Je voudrais quelque chose de plus “standard” :wink:

Je n’ai pas de meilleure solution, malheureusement… Pour faire ce que tu veux, il faut changer le code: Il faudrait modifier wazo-ui pour envoyer l’adresse originale à wazo-auth ou bien changer le code de statut du POST /login sur wazo-ui pour pouvoir l’interpréter comme un échec d’authentification.

Salut @sduthil

ça marche, c’est bien ce que je craignais :pensive_face:

Merci en tout cas pour ton aide et tes explications :wink:

Bonne continuation

Bastien

Salut @sduthil , Salut @Tous,

J’ai trouvé une solution pour le filtrage si jamais ça intéresse quelqu’un.

Il faut donc :
1. Définir une jail dans f2b

vi /etc/fail2ban/jail.d/wazo-ui.conf
[wazo-ui]

enabled  = true
filter   = wazo-ui
logpath  = /var/log/nginx/wazo.access.log

2. Définir le filtre correspondant

vi /etc/fail2ban/filter.d/wazo-ui.conf
[Definition]

failregex = ^<HOST> - - \[.*?\] "POST /login/ HTTP/1\.1" 200
ignoreregex =

3. Optionnel : Si wazo derrière un proxy

vi /etc/nginx/nginx.conf
http {

        ....

        ##
        # Proxy settings
        ##
        # Fait confiance à l'en-tête X-Forwarded-For envoyé par le proxy
        real_ip_header X-Forwarded-For;

        # Autorise la prise en compte de cet en-tête seulement depuis le proxy (ex : réseau local 192.168.5.0/24)
        set_real_ip_from 192.168.5.0/24;

        # Pour utiliser le plus “profond” X-Forwarded-For trouvé
        real_ip_recursive on;
}

Pour les explications : le tout est de filtrer sur le code de retour du POST de l’appel à /login pour l’authentification.
Si l’authentification se passe bien, le code 302 est retourné et une redirection vers les autres pages est lancée.
Sinon, en cas de login incorrect, le code 200 est renvoyé puis plus rien.
Il faut donc filtrer sur le code 200 mais uniquement sur une requête POST car lors de l’accès à la page de login le même code 200 est envoyé mais sur une méthode GET cette fois-ci.

Voilà tout, je sais pas si c’est la meilleure méthode mais elle me semble viable si jamais ça interesse quelqu’un sinon je suis ouvert à toutes améliorations :grin: