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. @+
