Git-daemon | Anti-DOS mit fail2ban

Seit gestern versuche ich mittels Fail2ban zu vermeiden, dass mein git-daemon “geDOSt” wird. Also bei ca 10 Downloads die Klappe für die IP schliessen.
unter:

$ git clone git://zwetschge.org/roborobo.git

lässt sich über den Daemon ein Repo auschecken. Der Logeintrag bei Access sieht folgendermaßen aus:

2010-04-20_11:37:52.05907 [16810] Connection from 200.200.200.200:54283

Nun lässt sich über ein einfaches Script, beispielsweise:

$ for i in $(seq 1 100) ; do git clone git://zwetschge.org/roborobo.git gitrepodos$i ; done

den Server total auslasten. Gerade bei grossen Repos wäre das fatal.
Über RegExp und fail2ban-regexp lässt sich der Ausdruck im Logfile auch filtern und testen:

fail2ban-regex '2010-04-20_19:52:01.41131 [26818] Connection from 200.200.200.200:54283' '.*Connection from <HOST>:.{4,5}$'

gibt zurück der Ausdruck würde matchen. Meine Filterregel sieht auch dementsprechend aus:

failregex = .*Connection from <HOST>:.{4,5}$

und der Eintrag in der jail.local (damit als jail erkannt wird):

[git-daemon]
enabled  = true
port     = git
filter   = git-daemon
logpath  = /var/log/git-daemon/current
maxretry = 5

ist eingerichtet. Keine Fehler im Fail2ban-Log. Alles erfolgreich gestartet. Aber der Filter matched einfach nicht wenn ich das Script ausprobiere.

Statusabfrage des Jails:

$ fail2ban-client status git-daemon

Status for the jail: git-daemon
|- filter
|  |- File list:    /var/log/git-daemon/current
|  |- Currently failed:    0
|  `- Total failed:    0
`- action
|- Currently banned:    0
|  `- IP list:
`- Total banned:    0

Ich weiss mir gerade nicht zu helfen. Obwohl ich das selbe Spiel mit vsftp auch gemacht habe. LINK

roborobo | selfmade robot

Auf dem Weg durch die Filesysteme meiner Rechner/Laptops/Server kam ich immer wieder in Situationen, in denen ich gerne Files (die mir wichtig waren) an einer bestimmten Stelle aufheben wollte. Ich hab über die Monate bzw. fast schon Jahre hin immer andere Systeme, Praktiken und Plätze entwickelt in denen ich diese Configs und ähnliches ablege. Über kurz oder lang ist aber jede dieser Methoden zu aufwändig oder zu unstrukturiert. Wenn ich Konfigurationsdateien von Daemons editierte, kopierte ich vorher die alten Files an eine bestimmte Stelle. Ziemlich Standart. Der Vorgang ist an sich ziemlich mühsam. Wirr liegen irgendwo irgendwelche Files rum.

Vor ein paar Wochen habe ich dann angefangen mir ein kleines Helferlein zu coden. Anfangs war dieses Helferlein nur für mich gedacht und demnach relativ speziell. Ich nannte ihn “roborobo”.

Was er tut ? Ich gebe meinem Helfer einfach das File “in die Hand”. Alles andere erledigt er.

File hinzufügen
$ roborobo /etc/postfix/main.cf

Alle bekannten Files updaten:
$ roborobo

Er nimmt das File an, ordnet es ein und sichert es in seinem Verzeichnis mit dem kompletten Verzeichnispfad nach Baumstruktur-Art. Außerdem prüft roborobo jetzt jede Stunde anhand der sha1sum ob sich in dem File seit der letzten Prüfung etwas getan hat. Falls Veränderungen da sind, wird das File mit neuem Datum wieder abgespeichert. Das sieht ungefähr so aus:

.roborobo/
|-- etc
|   |-- hosts
|   |   |-- hosts-20100409-1348
|   |   `-- hosts-20100409-1651
|   `-- network
|       `-- interfaces
|           |-- interfaces-20100409-1654
|           `-- interfaces-20100409-1655

Ich brauche mich somit um _nichts_ mehr kümmern. Gebe dem “kleinen” die Files die mir wichtig sind und er passt darauf auf. Fühlt sich irgendwie an wie ein Backup-Daemon ;)

Jedenfalls, habe ich roborobo jetzt für den Einsatz auf jedem beliebigen System umgebaut und in ein Debianpaket gebastelt. Dokumentation erstellt, Config-Dateien ausreichend selbsterklärend gestaltet usw.

Wer sich dafür interessiert oder mal testen mag:

roborobo-Debianpaket bei Github
roborobo-Projekt auf Github
Alles nochmal bei meinem privaten Git-Server auf git.zwetschge.org

Content:

roborobo
|-- DEBIAN
|   `-- control
|-- etc
|   |-- cron.d
|   |   `-- roborobo
|   `-- roborobo
|       |-- roborobo.conf
|       `-- roborobo.path
`-- usr
    |-- bin
    |   `-- roborobo
    `-- share
        |-- doc
        |   `-- roborobo
        |       |-- changelog
        |       `-- copyright
        `-- man
            `-- man1
                `-- roborobo.1

Das ganze wie alles was ich tue, unter GPLv3. Viel Spass damit ;)

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.