Anatomie eines Eintrags in die Log-Datei
Der Webserver speichert die IP-Adresse des Browsers / Besuchers, denn sonst könnte er keine Antwort an den Browser senden. In Hinsicht auf die gesetzliche Datenschutz / Privatsphäre könnte die IP-Adresse auch anonymisierten werden, aber ein Besucher kann nicht erkennen, ob der Webserver die IP tatsächlich anonymisiert und kann sich solche Angaben nicht verlassen. Wer ohne IP-Verfolgung surfen will, benutzt einen Thor-Browser oder einen Proxy-Server.
Monitoring: Schutz, Fehlersuche und Statistik
Um die GDPR-Regeln einzuhalten, löschen regelkonforme Webserver die Logdateien nach wenigen Tagen und die Datenschutzhinweise der Webseiten erklären, warum die Log-Informationen gespeichert werden: zum Schutz vor Angreifern, zur Fehlersuche, Lastenverteilung und für die Statistik.
In der klassischen Konfiguration eines Apache-Webservers bringt die Logdatei nur die nötigsten Informationen mit, die vor allem bei der Sicherung gegen Angriffe zu den ersten Anlaufstellen gehören.
Im Log-Verzeichnis, das meist über dem root-Verzeichnis (httpdocs, html, web, … ) des Webspace liegt, liegt eine Sammlung unterschiedlicher Logdateien – z.B.:
access.log
access-ssl.log
error.log
proxy_access_ssl_log
proxy_error_log
und davon meist noch ältere, gepackte Logdateien der vergangenen Tage. Die Einträge der access.log-Datei folgen dem Schema
%h %l %u %t \%r\ %s %b
12.345.67.89 - - [21/Feb/2020:04:24:26 +0000] "GET /wordpress-shortcuts HTTP/1.0" 200 53975 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
%h ("12.345.67.89") ist i.d.R. die IP-Adresse des Remote Host. Wenn der Client hinter einem Proxy-Server liegt, ist hier nur die IP des Proxy-Servers zu sehen.
%l ("-") ist der Remote Log Name. Der wird von den meisten Browsern nicht unterstützt und ist fast immer leer , ein Relikt der frühen 90er Jahre.
%u ("-") ist der Benutzername eines authentifizierten Benutzers – also auch mehr oder minder immer leer -
%t [21/Feb/2020:04:24:26 +0000] – die Zeit des Zugriffs. Der Eintrag wird erst sichtbar, wenn eine Response gesendet wurde. Es kann also passieren, dass ein aufwändiger Request erst nach späteren Anfragen in der Logdatei auftaucht.
%r ("GET /wordpress-shortcuts HTTP/1.0") ist die Beschreibung des Requests in der Form Method URI Protocol, z.B.
Das ist ein Request mit der Methode GET zur Datei /wordpress-shortcuts und dem Protokoll HTTP/1.0
%s (200) ist der Status der Antwort. Bei normalen Zugriffen auf eine URL der Webseite ist der Code 200 (Seite gefunden und geliefert, 404 Seite nicht gefunden, 500 ist der Antwort-Code bei einem Fehler des Servers).
%b (53975)Ankündigung der Bytes im Response Header, z.B. die Bytes einer Seite index.html. Keine genaue bzw. verläßliche Angabe.
Zusätzlich zu diesen Standard-Informationen geben die Log-Dateien u.U. auch den Referer (woher kommt die Anfrage). Der Referer kommt vom Client / Browser und ist alles andere als verläßlich.
"Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
Und noch eine unzuverläßige Information: User Agent. Wird ebenfalls vom Client gesendet, im Regelfall also vom Browser. Allerdings können einige Clients viele Informationen mitliefern, von der Version über die Rendering Machine und die Kompatibilität zu anderen Browsern und installierte Plugins. Mit derart individuellen Angaben kann ein individueller Besucher tatsächlich identifiziert und verfolgt werden.
123.456.789.123 - - [24/Feb/2020:06:38:06 +0100] "GET /shop/wp-login.php HTTP/1.1" 403 135 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 123.456.789.123 - - [24/Feb/2020:06:38:06 +0100] "POST /wp/wp-login.php HTTP/1.1" 403 135 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 123.456.789.123 - - [24/Feb/2020:06:38:06 +0100] "GET /blog/wp-login.php HTTP/1.1" 403 135 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 123.456.789.123 - - [24/Feb/2020:06:38:06 +0100] "GET /site/wp-login.php HTTP/1.1" 403 135 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 123.456.789.123 - - [24/Feb/2020:06:38:06 +0100] "GET /wordpress/wp-login.php HTTP/1.1" 403 135 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 123.456.789.123 - - [24/Feb/2020:06:38:07 +0100] "GET /wp/wp-login.php HTTP/1.1" 403 135 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 123.456.789.123 - - [24/Feb/2020:06:38:07 +0100] "POST /shop/wp-login.php HTTP/1.1" 403 135 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 123.456.789.123 - - [24/Feb/2020:06:38:07 +0100] "POST /blog/wp-login.php HTTP/1.1" 403 135 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
Das ist eines der Angriffsmuster, die wir in den Logdateien vieler Internet-Auftritte finden: Mit einem leeren Referer und dem Browser-String Gecko/20100101 Firefox/62.0 flutet ein Botnetz von mehr als 3000 IP-Adressen die Seiten mit Login-Versuchen.
if ($http_referer = "") { return 403; }Um beide Bedingungen zusammenzubringen
if ($http_referer = "") {
set $test A;
}
if ($host ~* teambox.com) {
set $test "${test}B";
}
if ($http_cookie !~* "auth_token") {
set $test "${test}C";
}
if ($test = ABC) {
proxy_pass http://teambox-cms.heroku.com;
break;
}