Fail2Ban eigenen Filter für Loginfehler

Ich nutze Fail2Ban wie es „Out of the Box“ kommt, habe es nicht angepasst und nutze keine eigenen Filter oder Actions. Nun hatte ich den Fall, dass eine Webseite angegriffen wurde und das Log falsche Anmeldungen anzeigte, ganz offensichtlich ein Brute-Force Angriff. An sich ist das nicht wild, aber es wurden unnötig Systemressourcen verbraucht.

Um den Angriff einzugrenzen, habe ich als erstes Routen von Hand gesetzt und die IP-Adresse des Angreifers geblockt. Hier der Code-Snipe zum filtern des Logs auf IP Adresse:

cat /.../log/error.log |grep "denied to user"|awk '{print $11}'
XXX.XXX.XXX.XXX

Der Befehl zum zurückweisen der IP-Adresse sieht dann wie folgt aus:

route add -host <IP-Adresse> reject

Da jedoch immer neuere IP-Adressen dazu kamen, wurde es irgendwann zu viel um die Routen per Hand zu blocken, also habe ich ein Script geschrieben, dass die Aufgabe für mich übernahm:

#!/bin/bash
search="."
command=`cat /.../log/error.log |grep 'Datenbank-Fehler UPDATE command denied to user'|awk '{print $11}'`
white="111.111.111.111"
for val in $command;do
	if [[ "$val" == *"$search"* ]]; then
		# extract ipv6 and get ipv4
		ip=$(echo $val |awk -F ':' '{print $1}')
		echo "### Route Host: $ip reject ###"
			if [[ "$ip" != "$white" ]]; then
				message=`route add -host $ip reject`
				if [[ "$message" != *"bereits"* ]]; then
					echo $message
				fi
			fi
	fi
done

Da mir das aber irgendwie suboptimal erschien, dachte ich an Fail2Ban. Also machte ich mich an die Arbeit und kam zu folgender Lösung:

Ich habe zu erst denneuen Filter „websiteXY.conf“ erstellt. Entscheidend ist der passende failregex der zur Erkennung des Angriffes und der IP, führt:

# cat filter.d/websiteXY.conf 
# WebsiteXY Log File

[INCLUDES]
# nothing

[DEFAULT]
# nothing

[Definition]

# Option: failregex
# Notes: regex to match the password DB Login failures

failregex = client <HOST>:.*Datenbank-Fehler UPDATE command denied to user

# Option: ignoreregex
# Notes: regex to ignore, if this regex matches, the line is ignored
# Values: TEXT
#
ignoreregex =

Als nächstes habe ich obigen failregex aus der Konfiguration wie folgt geprüft. Man kann diesen auch direkt mit dem Befehl prüfen.

# fail2ban-regex /var/www/taste-of-it.de/log/error.log /etc/fail2ban/filter.d/apache-taste-of-it.conf

Um Fail2Ban zu sagen, was er bei einer Erkennung tun soll, habe ich eine neue Action-Config, die bei der Erkennung, die Route blockieren soll erstellt. Wichtig hier ist, dass der Abschnitt den gleichen Namen wie die Filter-Config, ohne .conf, hat. Ich hatte gelesen, dass man wohl auch nur die selben Dateinamen verwenden kann, wollte es aber aus Zeitmangel nicht testen und fand es so schlüssiger. Als „ignoreip“ habe ich die IP-Adresse des Servers eingetragen, zur Sicherheit.

# cat jail.d/websiteXY.conf 
# Block Hack attemps on WebsiteXY

[Definition]

[websiteXY]
enable=true
# Home-IP, Server IP,
ignoreip=<Server-IP>
#port=
filter=websiteXY
logpath=/.../log/error.log
#banaction=%(banaction_allports)s
# Bann by route command
banaction=route
# Bann at first attack
maxretry=1
# 6h reset retry
findtime=21600
# 1day
bantime=86400

In meinem System musste ich die defaults-debian.conf um meinen Filter wie folgt erweitern:

# cat jail.d/defaults-debian.conf
[sshd]
enabled = true
[websiteXY]
enabled = true

Danach habe ich den Fail2Ban Service neugestartet: service fail2ban restart und die IP-Adressen wurden automatisch geblockt. Um den Status zu prüfen kann man diesen Befehl eingeben:

fail2ban-client status
fail2ban-client status websiteXY

Thats it … Have Fun!