Wir hatten in der letzten Zeit immer wiedermal Thread/Posts wo es um den Autoblock von Synology geht. Oft geht es darum, dass bestimmte Sachen nicht überwacht werden, die man gerne überwacht hätte. Drum hier mal die Alternative: fail2ban

Bei fail2ban handelt es sich um einen Parser für Logfiles, der sie nach bestimmten Mustern durchsuchen kann. Die Muster werden in regulären Ausdrücken angegeben und sind daher ziemlich mächtig. Bei „Verstössen“ gegen die Muster kann fail2ban die betreffenden IPs durch iptables sperren.

Grundsätzlich erfordert fail2ban nicht mehr als Python (>=2.3). Allerdings gibt es bei fail2ban auf einer DS eine wichtige Einschränkung: Leider hat Synology wichtige Teile nicht in den Logs resp nur in „ihrem“ Format in Binärform. So z.B. alles was ein Linux normalerweise in auth.log resp sshd.log hat. Ich weiss nicht ob man den Syno Log durch irgendeine Konfiguration dazu zu bringen kann, dass „normal“ (als Textfiles) geloggt wird. Ich habe daher bei meinen Test mit fail2ban auf der DS erstmal den syslog der Firmware stillgelegt und danach den ipkg syslog-ng installiert. Mit diesen Logfiles kann dann fail2ban arbeiten.

Wie gesagt, um fail2ban sinnvoll auf der DS nutzen zu können muss den syslog der Firmware lahmlegen. Wer das nicht will sollte besser beim Autoblock der Firmware bleiben und hier nicht weitermachen!

Sobald python installiert ist und man den syslog-ng drauf hat kann man sich die Source von fail2ban runterladen. Ich habe bei mir die aktuellste Version der Firmware und darauf die Version 0.8.4. von fail2ban. Nach dem entpacken in ein beliebiges Verzeichnis dort hineinwechseln und danach ein

python ./setup.py install --root /opt

das sollte alles unterhalb von /opt installieren, also die Konfig in /opt/etc/fail2ban/ und die Binaries in /opt/bin/ resp /opt/sbin/

Danach habe ich bei mir in /opt/etc/fail2ban/fail2ban.conf noch diese beiden Parameter so angepasst

logtarget = /opt/var/log/fail2ban.log
socket = /opt/var/run/fail2ban/fail2ban.socket

sodass alles einheitlich unter /opt liegt.

Das wichtigste bei fail2ban sind die Filter (reguläre Ausdrücke) und die Konfig der sogeannten jails in /opt/etc/fail2ban/jail.conf Diese Datei definiert welche jails vorhanden sind. Die jails definieren was überwacht wird, welche Filter verwendet werden und mit welchen Parametern fail2ban agieren soll, falls Verletzungen entdeckt werden. So schaut bei mir die ssh Jail aus:

[ssh-iptables]


enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
logpath  = /opt/var/log/auth.log
maxretry = 5

filter definiert welche regulären Audrücke verwendet werden sollten. In diesem Fall würde das File /opt/etc/fail2ban/filter.d/sshd.conf verwendet werden
action definiert was getan werden soll. Hier wird iptables verwendet. name definiert den Namen der iptables Chain für dieses Jail. Port definiert den zu sperrenden Port und protocol das verwendete Protokoll
logpath gibt den Pfad zum Logfile an welches mit den Filtern überwacht werden soll. maxretry gibt an, dass maximal 5 „Verletzungen“ pro Client erlaubt sind, dann wird gesperrt.

Es gibt noch weitere wichtige Parameter in jail.conf. Die wichtigsten wären
ignoreip definiert IPs welche nie geblockt werden
bantime deiniert wieviele Sekunden eine IP gesperrt werden soll
findtime definiert den Intervall in Sekunden in dem ein Client ein maxretry von Versuchen zusteht

Tipp: solange man mit fail2ban am testen ist sollte man die bantime nicht zu hoch setzen

Unter /opt/etc/fail2ban/filter.d/ liegen die Files mit den regulären Ausdrücken. Es sind bereits viele Filter für unterschiedlichste Sachen vorhanden. Die sshd.conf konnte ich bei mir ohne Anpassung verwenden. Grundsätzlich legt man in einem Filter File fest wie eine Logzeile ausschauen muss, damit sie als Verstoss gesehen wird. Dabei ist wichtig, dass man pro Ausdruck dem fail2ban „sagt“ was die Client-IP ist. Dazu dient das Tag <HOST> im filter File z.B. für ssh und Usern welche nicht in AllowedUser eingetragen sind

^%(__prefix_line)sUser \S+ from <HOST> not allowed because not listed in AllowUsers$

\\^ Steht für den Anfang einer Zeile und $ für das Ende d.h. dieses Muster muss von Anfang bis Ende auf eine Logzeile passen. Zu %(__prefix_line) konnte ich nichts in der Doku finden, aber scheinbar matched dies den „typischen“ Anfang von Logzeilen z.B Datum und Uhrzeit. Danach steht s für ein Lerrzeichen. Dann der String User und nach einem Leerzeichen wird alles bis zum nächsten Leerzeichen gematched d.h. das ist der beim SSH verwendete Loginname. Danach wird der String from erwartet und dann das Macro <HOST>, welches letztlich dafür steht für die Client-IP und den Hostnamen