FTP | vsftpd mit MySQL-Userauth und fail2ban

Ein Kollege aus dem lokal vertretenen Eishockey-Hobbyverein hatte eine kleine Page mit HTML gebastelt und wollte diese irgendwo hosten.  Hier würde sich von den Mitgliedern um den Informationsfluss gekümmert und da ich selbst öfters an den Spielen teilnehme, half ich natürlich gerne. Ich benutzte bis dato allerdings nie FTP und hatte auch keinen FTP-Server installiert. “Wenn dann schon richtig” war meine Intention. Über ein How-To auf HowtoForge.com richtete ich einen vsftpd mit mysql-userauth ein. Das war innerhalb 15 Minuten geschafft. FTP-Server lief wunderbar und die (noch dürftige) Site ist auch fast online. Mir gefiel die Auth-Möglichkeit über MySQL.

Nichtsahnend durchforstete ich heute Morgen die Logfiles meiner Zwetschge. vsftpd-Logfiles innerhalb 15 Stunden relativ voll. Irgendwas war faul. Nachdem ich die fehlerhafte Konfiguration des logrotated ausschliessen konnte sah ich mir die Logs mal an.

CONNECT: Client "xxx"
[Administrator] FAIL LOGIN: Client "xxx"
[Administrator] FAIL LOGIN: Client "xxx"
[Administrator] FAIL LOGIN: Client "xxx"
CONNECT: Client "xxx"
[Administrator] FAIL LOGIN: Client "xxx"
[Administrator] FAIL LOGIN: Client "xxx"
[Administrator] FAIL LOGIN: Client "xxx"
…

Ich zählte nicht, wie oft genau. Jedenfalls zu oft um von fehlerfreier Konfiguration meines fail2ban ausgehen zu können. Außerdem ist es beachtlich wie schnell Bots einen existierenden FTP-Server ausmachen können. Was solls. Zur Erinnerung: Fail2ban verbietet (anhand Logfileanalyse) Clients die Verbindung, wenn sie  zu oft abgewiesene Verbindungsversuche gestartet haben. Sprich: Zu viele falsche Passwörter. Stichwort Bruteforce-Attacke

Dies veranstaltet fail2ban mit einem Configfile (/etc/fail2ban/jail.local) und Filtern (/etc/fail2ban/filters.d/*). Ich habe länger überlegt, Config erneuert, fail2ban-server neu gestartet bis mir kam warum die übermäßig vorhandenen failed-logins meines FTP-servers nicht geblockt wurden. Die Ausgabe im Loggingfile hatte sich durch die Umstellung auf MySQL geändert und fail2ban greift nicht mehr:

auth.log(Standard): Jan 23 14:04:14 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=xxx
---
auth.log(mysqlauth): Feb 24 12:33:29 zwetschge vsftpd: pam_mysql - SELECT returned no result.

Nach etwas erfolglosen herumgegoogle und anderem, beschloss ich die RegExp für den neuen Filter selbst zu konfigurieren. Der neue Filter basiert nichtmehr auf dem auth.log sondern auf dem vsftpd.log(im jail.local-File vermerken!). fail2ban bietet eine wunderschöne Möglichkeit selbstgecodete Filter auszuprobieren. Via fail2ban-regexp wird ein zu filternder Logeintrag auf ein regexp geprüft.

fail2ban-regexp 'logeintrag' 'regexp zum logeintrag'
http://zwetschge.org/paste/011

In filters.d: die die Regular-Expression des Zugriffs für das StandardLogfile ersetzen:

alt:auth.log(stdregexp): failregex = vsftpd: \(pam_unix\) authentication failure; .* rhost=<HOST>(?:\s+user=\S*)?\s*$
---
neut:vsftpd.log(mysqlregexp): failregex = .* FAIL LOGIN: Client \"<HOST>\"$


Fail2ban neu starten, glücklich sein.
Um zukünftigen Usern diesen Schritt zu erleichtern habe ich natürlich die Änderungen unter das How-To kommentiert. Awating Moderation btw.

Ubuntu | Twitter Logfile mit Twidge

Ich laß meine TimeLine eine Zeit lang über die Konsole. Twidge hieß der textbasierte Twitterclient meiner Wahl. Die Ausgabe der letzten 10 Tweets erfolgt über den Befehl

twidge lsrecent

Die Syntax ist für jeden etwas erfahrenen Linux-Benutzer leicht verständlich und einleuchtend. Weitere Infos über die ManPage. Jedenfalls verfügt Twidge über eine wunderbare Funktion die (ich nehme an über die Tweet-ID) nur ungelesene Tweets anzeigt. Mit

twidge lsrecent -s
(oder --saveid)

werden gelesene Tweets gespeichert und mit -u (--unseen) nur Tweets angezeigt die neuer sind als der letzte Abruf via --saveid. Das ist sehr schön da ich mir beim erstellen eines LogFiles keine eigene Programmlogik ausdenken musste die die oben genannte Arbeit übernimmt. Das Skript ist durch die Funktionen von Twidge sehr kurz.

LeserLog:

#!/bin/bash
echo " `date +%d-%m-%Y-%H:%M:%S`" >> /var/log/twidge.log
twidge lsrecent -u >> /var/log/twidge.log
twidge lsrecent -s >> /dev/null

Die Ausgabe sieht ziemlich leserlich wie folgt aus:

Detail-greppable-Log

Nach einiger Zeit stieg ich aber auf TweetDeck um. Das Logfile tat aber gute Dienste und ich beschloss es als durchsuchbare Bibliothek für mich weiterzuführen. Um mir das greppen nach Tweets zu erleichtern (Zeilenumbrüche sind da unvorteilhaft) benutze ich allerdings die -l (–long) Ausgabe von Twidge. Einzeilig. Detailiert. TimeStamped.

#!/bin/bash
twidge lsrecent -l -u >> /var/log/twidge.log
twidge lsrecent -s >> /dev/null

Sieht zwar zum lesen nicht ganz so schön aus aber mir gefällt es besser.

Ein CronJob führt das Skript alle 5 oder 10 Minuten aus und so füllt sich das Logfile ;)

Eintrag in der Crontab
*/10 * * * * bash /usr/local/scripts/twidgerotate &> /dev/null

Alle Code-Schnippsel nochmal als Plaintext: http://zwetschge.org/paste/5