Fail2ban pour Splunk avec une basic Auth Nginx

Fail2ban

Salut tous, aujourd’hui on continue dans la série des articles sur fail2ban et Splunk en regardant comment mettre en place et protéger une BasicAuth HTTP devant Splunk avec Fail2ban. En effet, un « petit » défaut de la version free de Splunk est l’absence d’authentification… Wait What ??? Oui oui, vous avez bien lu, d’ailleurs je cite la doc : « There is no login. The command line or browser can access and control all aspects of Splunk Free with no user and password prompt.« . C’est bien traitre de la part de Splunk car lorsque vous installez la version d’essai, vous avez bien la mire de login pendant 60j et c’est seulement lorsque vous repasser en free que celle-ci disparait…

Shame on you Splunk ! que vous ne fournissiez pas l’authentification, pourquoi pas, mais la faire sauter à la fin de la période de trial : c’est franchement criminel de votre part.

Bref, ceci étant dit, le plus simple pour remettre une authentification en place c’est de configurer votre serveur web pour ajouter une auth basic, et on verra comment la protéger avec fail2ban.

Prérequis

Du coup cet article fait appel à pas mal de truc qu’on a déjà vu : l’installation de Splunk, la mise en place de HTTPS avec let’s encrypt et un proxy NGINX, l’intégration des logs nginx dans Splunk, et un petit peu ce que je vous avais déjà montré sur fail2ban avec WordPress ou ssh.

AuthBasic HTTP et proxy Nginx pour Splunk

Pour cette partie vous devez avoir mis en œuvre HTTPS tel que décrit ici, vous devriez donc avoir un fichier de conf pour Nginx qui ressemble à ça :

server {
  listen 80;
  listen [::]:80;
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  
  server_name splunk.site.tld;
  
  access_log /var/log/nginx/splunk-access.log;
  error_log /var/log/nginx/splunk-error.log;
  
  root /usr/share/nginx/splunk;
  
  # SSL confiiguration
  # certbot webroot : .well-known doit rester accessible pour tous, pour que le serveur cerbot puisse y accéder
  location ~ /\.well-known/acme-challenge {
    allow all;
  }
  ssl_certificate /etc/letsencrypt/live/splunk.site.tld/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/splunk.site.tld/privkey.pem; # managed by Certbot
  
  location / {
    proxy_pass http://127.0.0.1:8000;
  }
}

Du coup pour ajouter une « authentification basic » HTTP, il suffit de rajouter les deux lignes ci-dessous dans le fichier de config :

auth_basic "Message pour dire de vous authentifier, merci.";
auth_basic_user_file "/etc/nginx/passwd/splunk_passwd";

Il vous reste simplement à créer le fichier splunk_passwd en question à l’aide de la commande suivante :

htpasswd -cs /etc/nginx/passwd/splunk_passwd admin 
# ne pas oublier le '-s' pour stocker le hash en SHA1, et pas en MD5 (utilisé par défaut sinon),
# certes SHA1 est 'deprecated' mais il reste plus robuste que MD5,
# et Bcrypt n'est pas compatible avec les paquets standard de Nginx.

Un petit reload (ou restart) de Nginx et vous ne devriez plus pouvoir rentrer sans saisir des credentials.

Surveiller les logs d’authentification de Nginx avec fail2ban

Un des problèmes de l’Auth Basic, c’est qu’elle est très simple à bruteforcer. Je vous invite donc à faire un test d’authentification en échec et jeter un œil dans vos logs d’erreur, vous devriez trouver une ligne du genre :

2018/12/03 15:31:40 [error] 14804#14804: *1720 user "test" was not found in "/etc/nginx/passwd/splunk_passwd", client: <ip-source>, server: splunk.site.tld, request: "GET / HTTP/2.0", host: "splunk.site.tld"

Alors en théorie, on pourrait écrire notre propre filtre pour fail2ban à partir de ça, mais pour en fait fail2ban propose nativement le support de ces logs d’erreur dans le filtre nginx-http-auth (voir dans /etc/fail2ban/filter.d/nginx-http-auth.conf). Il suffit donc de l’activer en ajoutant les lignes suivantes dans votre fichier jail.local (présent dans /etc/fail2ban/) :

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/splunk-error.log

Et voir le dernier TP sur Fail2ban si vous ne comprenez pas de quoi je parle. Ensuite un petit restart de fail2ban

service fail2ban restart

Vous pourrez vérifier que le nouveau filtre est bien chargé avec la commande suivante.

fail2ban-client status nginx-http-auth

Et le tour est joué, votre authentification HTTP est désormais protégée par fail2ban et les tentatives en échec se feront bannir par iptables au bout de quelques essais.

Conclusion

Souvenez-vous que la version free de Splunk en fourni pas d’authentification ! mais qu’il est simple d’en protéger l’accès à l’interface à l’aide d’une auth basic et d’éviter les bruteforce de celle-ci à l’aide de fail2ban. @+

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.