Fail2ban – serversicherheit fail2ban honeypot – DIY

Warum Fail2ban? Auch “seriöse” Unternehemen benehmen sich manchmal daneben, Informationen sind das neue Gold!

Ein paar aufmerksame Leser haben mich gefragt was der fail2ban-Filter apache_trackback macht und WARUM?

Mir ist in meiner täglichen Arbeit aufgefallen, dass so manche Suchmaschinen uneingeladen auf den Servern stöbern. Was ja nicht schlimm ist, aber wenn es solche Spider sind, welche nur Informationen ungefragt abziehen und auch noch diese Informationen als so eine Art Mehrwert verkaufen, dann hört der Spass bei mir auf. Das Unternehmen für welches ich derzeit tätig bin, gibt allein für GoogleAdwords einen 4stelligen Europreis pro Monat für Keywordskampagnen aus und als erste Stelle steht keine 1,2 oder 3.

Also habe ich mal angefangen die genaueren Aktivitäten der einzelnen Suchmaschinen zu analysieren.
Was Pixray macht ist klar und schon ausführlich im Netz dokumentiert. Dieses Servernetzwerk muss von jedem normal denken Admin ausgesperrt werden. Gut Yandex, wenn man nicht in Russland verkaufen möchte, Zugriff verbieten auch sehr unangenehm, sehr Resourchen hungrig. Aber ein sehr unmöglicher Spider kommt aus dem Netztwerk von baiduspider, mittlerweile habe von denen die komplette IP-Range eingefangen, aber er kommt immer wieder. Naja Katz- und Mausspiel eben.

Was diese Leute mit den Informationen machen, welche sie sammeln ist nirgends dokumentiert und auf Anfrage bekommt man keine Auskunft. (Was sie tatsächlich machen ist, Mail Relays suchen, sitemap abziehen und keywords analysieren)

All diese Spider machen sich aus robots.txt etc. sehr wenig, selbst google und bing benehmen sich manchmal daneben.

Gut jetzt könnte man sagen, ich verbiete alles und erlaube nur google oder bing, also eine WhiteList, aber damit verbaue ich mir auch Chancen, wenn zum eine Spider vorbei kommt, der wirklich Artikelnummer oder positives SEO aufnimmt. Also lieber eine Blacklist, macht zwar etwas mehr Arbeit, aber das automatisierte Logfile lesen, ist ja nun auch keine Raketenwissenschaft.

zum Inhalt des Filters:

[INCLUDES]
# Read common prefixes. If any customizations available — read them from
# common.local
before = common.conf

[Definition]
#failregex = [[]client <HOST>[]] YandexBot
badbots = Yandex|YandexBot|DotBot|Exabot|MJ12bot|SeznamBot|meanpathbot|proximic|Pixray|SemrushBot|
AhrefsBot|Riddler|Genieo|SiteExplorer|Sogou|NetSeer|publiclibraryarchive|360Spider|Baiduspider|
BuiBui|CCBot|coccoc|Finderlein|SurveyBot

failregex = ^<HOST>.*(?:%(badbots)s).*$

ignoreregex =

diese paar Zeilen in das filter.d/apache_trackback.conf kopieren und speichern.

weiter in der jail.conf den Filter aktivieren, damit fail2ban auch weiß, dass er da auch mal schauen soll.

[apache_trackback]
enabled  = true
port     = http,https
filter   = apache_trackback
findtime = 86400
logpath  = /var/www/vhosts/XXX/logs/access_log
/var/www/vhosts/XXX/logs/access_log
/var/www/vhosts/XXX/logs/access_log.processed
maxretry = 1

Ich mache es mir gleich einfach und geben dem Filter alle meine Logdateien aller relevanten Domains.

Speichern, und fail2ban einen reload machen, damit er den neuen Filter aktiviert. Jetzt kann man sich das log aufrufen und staunen, wer so alles Versucht meine Keywords auszulesen oder meine Bilderordner analysiert, ob nicht irgendwo ein Bild schlummert, was urheberrechtlich geschützt ist.

Kleiner Auszug meiner iptables:

Chain fail2ban-apache_trackback (1 references)
target     prot opt source               destination
DROP       all  —  baiduspider-123-125-71-46.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-180-76-5-146.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-180-76-5-150.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-103.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-86.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-105.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-180-76-5-193.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-220-181-108-106.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-74.crawl.baidu.com  anywhere
DROP       all  —  static.23.94.46.78.clients.your-server.de  anywhere
DROP       all  —  baiduspider-123-125-71-92.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-220-181-108-110.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-220-181-108-113.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-24.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-43.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-220-181-108-76.crawl.baidu.com  anywhere
DROP       all  —  101.226.166.216      anywhere
DROP       all  —  baiduspider-220-181-108-109.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-220-181-108-121.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-220-181-108-107.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-58.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-17.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-55.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-54.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-180-76-5-149.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-220-181-108-93.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-220-181-108-116.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-22.crawl.baidu.com  anywhere
DROP       all  —  180.76.6.131         anywhere
DROP       all  —  baiduspider-180-76-5-171.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-123-125-71-108.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-180-76-5-152.crawl.baidu.com  anywhere
DROP       all  —  baiduspider-180-76-5-151.crawl.baidu.com  anywhere
DROP       all  —  72.55.168.89         anywhere

Unerwünschte Besucher, oder warum sind meine Server ständig so genervt (ausgelastet)

Als Systemadministrator bin ich verantwortlich für den reibungslosen Betrieb der IT im Allgemeinen, speziell der Server. Ständig fällt auf, dass der Server (obwohl er recht großzügig dimensioniert ist) ständig bei 80% bis 90% seiner CPU-Leistung fährst. Sowas nervt, weil auf dem Server keine weiteren großartigen oder Ressourcen fressende Dienste laufen.

Also macht man sich auf die Suche, waran es liegen könnte. Der erste Anlaufpunkt sind immer die Logfiles.
Nach dem durch greppen der Logfiles war mir das sogenannte “Grundrauschen des Internets” etwas zu heftig geworden. Neben den bekannten Sicherheitsmaßnahmen eines jeden Servers iptables (URL https://wiki.debian.org/iptables) etc. gehört auch fail2ban zu den Grundsicherungsmaßnahmen meiner Server.

Serverauslastung ohne fail2ban:

Fail2ban ist ein kleiner, lustiger Dämon, welcher im Zusammenspiel mit iptables auf meinen Debian’s in Echtzeit IP-Sperren aussprechen und Einbruchversuche so im Vorfeld schon erkennen und entsprechende Maßnahmen ergreifen kann. Denn selbst das ständige Anklopfen per SSH mit root (LOGIN per root muss immer deaktiviert sein) frißt Resourcen auf.

Eine Installationsanleitung findet man auf den Projektseiten (http://www.fail2ban.org/).

Die Grundinstallation kommt schon mit diversen Filtern, welche man sofort einsetzen kann.
Die wichtigsten Bereiche, welche man absichern sollte ist, der SSH Zugang (auf das unsicher FTP sollte man gänzlich verzichten) und alles was mit Email zu tun hat.

Schaut man sich die Struktur nach der Installation von fail2ban an:

cd /etc/fail2ban/

sieht man die fail2ban.conf, eine jail.conf und ein Verzeichnis filter.d/
Im Verzeichnis filter.d/ findet man diverse definierte Filter.

Am Beispiel des ssh-Filter filter.d/sshd.conf erkennt man, dass fail2ban nach Mustern, welche mit regulären Ausdrücken gebildet werden, in den Logdateien stöbert. (Hinweis: mitunter sind einige logs von Ereignissen von System zu System verschieden. Man sollte die Filter vor dem Einsatz händisch prüfen. siehe grep etc.)

Als nächstes sollte man fail2ban sagen, wie er mit dem Filter umgehen soll. Das wird wiederum in der jail.conf erledigt. Die Grundeinstellungen sind in meinem Falle:

[ssh]
enabled  = true (Damit wird er Filter aktiviert)
port     = ssh (Port 22, erklärt sich von selbst)
filter   = sshd (der Name der Filterdatei in filter.d/sshd.conf)
logpath  = /var/log/auth.log (dies ist wichtig, weil hier kann ich bestimmen, WO nach Ereignissen gesucht werden soll)
maxretry = 3 (die maximalen Versuche, welche ein Besucher ausführen kann, bevor reagiert wird)
findtime = 86400 (die findtime bestimmt, wie weit rückwärts fail2ban in den Logdateien schauen soll, bei mir eine Woche, ???obwohl???, tägliches Logrotation, egal schadet auch nichts)

Kleiner Hinweis:
Um mehrere Logdateien in einem Filter anzubieten kann man auch nach dem YAML-Format schreiben:
logpath  = /var/www/vhosts/XXXXXX*/logs/access_log
/var/www/vhosts/XXXXXX*/logs/access_log
/var/www/vhosts/XXXXXX*/logs/access_log.processed

somit bin ich in der Lage mehrere Logdateien unterschiedlicher/aller Domains in meinem vhosts mit einem Filter zu überwachen.

Interessant ist auch die banaction, hier bestimmt man, was getan werden soll, wenn ein Attack entdeckt wird.
banaction = iptables-allports  — damit fährt man ganz gut.
Nochmal zum testen eines Filters, in meinem Fall werden alle Login-Vorgänge in der auth.log registriert,
also wäre jetzt der Testaufrug auf konsole:

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Hier eine schöne Übersicht aller Commands: http://www.fail2ban.org/wiki/index.php/Commands

Als Ergebnis bekommt man dann ein schöne Liste mit getroffenen Ereignissen: “Success, the total number of match is 228”

Um jetzt mit dem Filter live zu gehen, kopiert man den definierten Aufruf des Filters in die jail.conf, startet /etc/init.d/fail2ban restart neu, Fertig. Da ich mit Livelog-Dateien teste und fail2ban beim testen meinte, dass in der auth.log 228 Einbruchversuche statt gefunden haben. Also schau ich mir das log von fail2ban an tail -f /var/log/fail2ban.log,

kleiner Auszug:

2015-01-27 06:34:57,040 fail2ban.actions: WARNING [apache_trackback] Ban 220.181.108.91
2015-01-27 06:34:57,044 fail2ban.actions: WARNING [apache_trackback] Ban 123.125.71.60
2015-01-27 06:34:57,047 fail2ban.actions: WARNING [apache_trackback] Ban 123.125.71.34
2015-01-27 06:34:57,050 fail2ban.actions: WARNING [apache_trackback] Ban 123.125.71.57
2015-01-27 06:34:57,053 fail2ban.actions: WARNING [apache_trackback] Ban 101.226.167.214
2015-01-27 06:34:57,056 fail2ban.actions: WARNING [apache_trackback] Ban 46.4.12.20

Und zu Guter Letzt kann man mit iptables -L auf konsole sich die DROP anschauen.

kleiner Auszug:
Chain fail2ban-ssh (1 references)
target     prot opt source               destination
DROP       all  —  212.51.174.61.dial.wz.zj.dynamic.163data.com.cn  anywhere
DROP       all  —  103.41.124.104       anywhere
DROP       all  —  216.50.174.61.dial.wz.zj.dynamic.163data.com.cn  anywhere
DROP       all  —  ec2-54-83-11-62.compute-1.amazonaws.com  anywhere
DROP       all  —  122.225.109.194      anywhere
DROP       all  —  103.41.124.56        anywhere
DROP       all  —  60.173.82.156        anywhere
DROP       all  —  huzhou.ctc.mx.fund123.cn  anywhere
DROP       all  —  103.41.124.31        anywhere
DROP       all  —  103.41.124.41        anywhere
DROP       all  —  251.50.174.61.dial.wz.zj.dynamic.163data.com.cn  anywhere
DROP       all  —  103.41.124.45        anywhere
DROP       all  —  208.51.174.61.dial.wz.zj.dynamic.163data.com.cn  anywhere
DROP       all  —  s15371346.onlinehome-server.info  anywhere
DROP       all  —  122.225.97.97        anywhere
DROP       all  —  server109-228-5-36.live-servers.net  anywhere

Serverauslastung mit fail2ban:

Mit dieser recht banalen Maßnahme, habe ich meine Server von permanter 80% Auslastung auf unter 20% gedrückt. Ein netter Nebeneffekt ist, dass dadurch meine Lüfter zur Kühlung auch nicht mehr so stark beansprucht werden, was wiederum die CO2-Bilanz positiv aufwertet.

Wenn Sie Interesse haben an ähnlichen Filtern, dann sprechen Sie mich an.

Filter Beispiel:

Please rate this