Auf der Angriffskarte liegt ein dichter Fleck über einem Land, und die Regel „das Land komplett sperren“ liegt nahe. Sie bringt fast nichts: das Austrittsland zu wechseln kostet den Angreifer einige Minuten, unter die Sperre geraten aber Ihre eigenen Besucher und Sie selbst auf Reisen. Schlimmer noch: ein sichtbarer Crawler aus einer einzelnen Cloud zieht nach der Sperre auf Privatanschlüsse um und ist dann von Menschen nicht mehr zu unterscheiden.

Es folgen fünf Schritte, die auf demselben Server tatsächlich etwas bringen: Scanner abschneiden, das Tempo begrenzen, das Nötige nicht mit abschneiden und, falls es doch nötig ist, richtig sperren. Alles lässt sich in einem Durchgang prüfen und einrichten.

Schritt 1. Sehen, wer den Fleck tatsächlich erzeugt

Suchen Sie zuerst das Zugriffsprotokoll. Auf einem Server mit mehreren Websites ist access.log oft leer, während die Einträge in das Protokoll des jeweiligen virtuellen Hosts laufen:

sudo ls -lS /var/log/apache2/*access*.log /var/log/apache2/*requests*.log 2>/dev/null

In allen weiteren Befehlen setzen Sie die Datei ein, die dabei oben steht. Zuerst die führenden Adressen des Tages, dann, was der oberste in der Liste eigentlich anfragt:

sudo awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20
sudo grep '^203\.0\.113\.' /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Der zweite Befehl beantwortet die Hauptfrage. Stehen in der Ausgabe Dutzende verschiedener Seiten Ihrer eigenen Website, ist das ein Inhaltssammler: harmlos, und es genügt, ihn nicht als Besucher zu zählen. Steht dort /wp-login.php, /.env, /phpmyadmin und anderes, was Sie gar nicht haben, ist das ein Scanner, und damit befasst sich Schritt 2. Bei nginx liegen die Protokolle in /var/log/nginx/, die Felder sind dieselben.

Schritt 2. Ein Jail für Anfragen nach etwas, das Sie nicht haben

Der angefragte Pfad lässt sich nicht fälschen — er ist die Absicht selbst, anders als Adresse und User-Agent. Der Filter /etc/fail2ban/filter.d/web-probes.local:

[Definition]
failregex = ^<HOST> .* "(GET|POST|HEAD) /(wp-login\.php|wp-admin|xmlrpc\.php|\.env|\.git/|phpmyadmin|administrator/)
ignoreregex =

Das Jail /etc/fail2ban/jail.d/web-probes.local:

[web-probes]
enabled  = true
port     = http,https
filter   = web-probes
logpath  = /var/log/apache2/*access.log
maxretry = 1
findtime = 1h
bantime  = 1d

Hier ist maxretry = 1 berechtigt: zufällige Zugriffe auf eine fremde Admin-Oberfläche gibt es nicht. Anwenden und sich überzeugen, dass der Filter Einträge in Ihrem Protokoll erfasst:

sudo fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/web-probes.local
sudo systemctl reload fail2ban && sudo fail2ban-client status web-probes

Schritt 3. Das Tempo begrenzen

Scanner und Crawler verraten sich durch Geschwindigkeit, unabhängig davon, aus welchem Land sie kommen. Dreißig Seiten pro Minute von einer Adresse sind eine Schwelle, die einen Menschen beim Durchblättern eines Katalogs nicht trifft:

[http-flood]
enabled  = true
port     = http,https
filter   = apache-overflows
logpath  = /var/log/apache2/site_access.log
maxretry = 30
findtime = 60
bantime  = 1h

Entscheidend ist, welches Protokoll in logpath steht. Fällt das Protokoll der Verwaltungsoberfläche oder des Admin-Bereichs selbst unter die Maske, sperren Sie sich selbst aus: eine einzige Seite dort zieht ein Dutzend Anfragen nach Stilen und Skripten nach sich, und dreißig sind mit zwei Klicks erreicht. Deshalb gibt man der Oberfläche eine eigene Protokolldatei, die nicht auf die Maske des Jails passt, und statischen Dateien eine lange Zwischenspeicherdauer, damit der Browser sie nicht bei jedem Seitenwechsel neu anfragt. Das Anzeichen, wenn es doch passiert ist: das HTML kommt an, die Gestaltung nicht, die Seite hängt. Sperre aufheben:

sudo fail2ban-client set http-flood unbanip 203.0.113.10

Schritt 4. Schützen, was nicht abgeschnitten werden darf

Bevor Sie Sperren einschalten, tragen Sie die Ausnahmen ein — sonst trifft es als Erstes das Nötige:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24 66.249.64.0/19

Was unbedingt in diese Zeile gehört und warum:

  • Ihre eigene Adresse oder das Subnetz des Büros. Die häufigste Ursache für verlorenen Zugang zum Server ist die eigene Regel, nicht ein Angriff;
  • Der Bereich 66.249.64.0/19. Der Suchroboter von Google weist sich über den User-Agent aus, aber jener Teil von ihm, der JavaScript ausführt, kommt als gewöhnlicher Chrome/Linux und nennt sich nicht. Jede Regel der Art „Verkehr aus Rechenzentren sperren“ trifft genau ihn, woraufhin Seiten still aus dem Index fallen. Eine verdächtige Adresse lässt sich über eine Rückwärtsabfrage prüfen: dig -x 66.249.66.1 +short muss einen Namen in der Zone googlebot.com zurückgeben;
  • Die Adressen der Zahlungsbenachrichtigungen. Webhooks der Zahlungsdienste kommen von AWS- und Azure-Servern. Sperren Sie diese Clouds vollständig, erreichen Sie Zahlungsbestätigungen nicht mehr, und Sie erfahren davon erst, wenn ein Kunde schreibt, das Geld sei abgebucht, der Zugang aber nicht da. Die Bereiche stehen in der Dokumentation Ihres Zahlungsanbieters.

Schritt 5. Wenn eine Sperre doch nötig ist — sperren Sie ein Subnetz, kein Land

Eine beständige Verdichtung aus einem einzigen Netz, die sich über Tage hält und mit gleichartigen Anfragen einhergeht, ist ein einzelner Ausführender, der eine Liste abarbeitet. Dieser Fall wird punktgenau und befristet gesperrt:

sudo ufw deny from 198.51.100.0/22 to any
sudo ufw status numbered

Merken Sie sich mit dem zweiten Befehl die Regelnummer: die Sperre muss später über sie aufgehoben werden, sudo ufw delete <Nummer>. Legen Sie mit sich selbst eine Frist fest — etwa einen Monat — und tragen Sie die Aufhebung in den Kalender ein. Regeln, die „für immer“ gesetzt wurden, werden nach einem Jahr zu einer Liste, die niemand anzutasten wagt, weil sich niemand erinnert, wofür diese Adressen dort hineingeraten sind.

Welches Subnetz zu sperren ist, lässt sich über die Adresse aus dem ersten Schritt herausfinden: whois 198.51.100.17 | grep -iE 'route|cidr|netname'.

Was sich nach diesen fünf Schritten ändert

Scanner werden nach Absicht abgeschnitten, nicht nach Herkunft, und schon bei der ersten Anfrage erfasst. Crawler stoßen an die Temposchranke. Suchroboter und Zahlungsbenachrichtigungen kommen weiterhin durch. Die einzige Sperre, die breit geblieben ist, ist punktgenau, mit bekannter Frist und nachvollziehbarem Grund.

Die Karte verschwindet dabei nicht, aber ihre Rolle verändert sich: sie ist nicht dafür da, Länder zu schließen, sondern um die Verdichtung überhaupt zu bemerken und sie mit dem zu vergleichen, was vor einer Woche war. Dafür braucht es einen Verlauf und nicht eine Momentaufnahme des laufenden Tages. Wie eine solche Karte zusammen mit dem Sperrprotokoll und der Liste offener Ports aussieht, zeigen die Demoseiten unten.