Apache-Logs und die Analyse verdächtigen Traffics

Von Zeit zu Zeit treten auf einem unserer Apache-Server ungewöhnliche Spitzen bei der Anzahl der Anfragen auf, verbunden mit einem starken Anstieg der Last. Dann ist die Analyse der Logs gefragt, um die Ursache zu finden und auf etwaige "Scraper" zu reagieren, die außer Kontrolle geraten sind. Dafür nutzen wir mehrere Tools, die wir je nach Bedarf kombinieren – z. B. goaccess, apachetop, iftop, Server Status usw.

Am besten bewährt hat sich für mich jedoch die Verkettung einiger grundlegender Linux-Befehle, mit denen ich ein Log schnell parsen und so verarbeiten kann, dass mir sofort verdächtige IP-Adressen aus einem oder mehreren Logs gleichzeitig angezeigt werden – für einen beliebigen Zeitraum und eine beliebige URL.

IP-Adressen mit den meisten Zugriffen

Die folgende Befehlskette parst alle Apache-Logs in einem Verzeichnis und zeigt die 20 IP-Adressen an, die am aktuellen Tag (in diesem Fall am 22. August 2015) zwischen 13:00 und 13:59:59 Uhr am häufigsten auf den Server zugegriffen haben. Soll ein anderer Tag als der heutige ausgewertet werden, muss das Muster für die ausgegebenen Dateien angepasst werden, da diese am Ende bereits eine Zahl tragen, die ihr Alter angibt – z. B. access.log.2 usw.

cat *-access.log | grep "22/Aug/2015:13" | awk '{ print $1 }' | awk -F "." '{ print $1 "." $2 "." $3 "." $4}' | sort | uniq -c | sort -n | tail -n 20

Der Befehl ließe sich sicher auch einfacher schreiben, diese Form hat aber den Vorteil, dass sie sich leicht zum Filtern ganzer Netzsegmente anpassen lässt. Wenn Sie ihn in dieser Form ausführen, erhalten Sie möglicherweise eine Ausgabe wie diese:

242 195.250.131.154
242 195.250.131.167
251 195.250.131.133
251 195.250.131.169
272 195.250.131.185
279 77.48.246.241
280 195.250.131.150
302 195.250.131.171
321 178.77.233.149
330 94.231.9.72
334 195.250.131.149
345 84.42.146.94
351 207.46.13.24
355 157.55.39.199
383 207.46.13.55
411 195.250.131.172
535 77.75.76.167
949 195.250.131.130
49823 127.0.0.1

Auf den ersten Blick verursacht hier keine externe IP-Adresse deutlich mehr Traffic als die anderen. Passen wir den Befehl jedoch so an, dass er /24-Segmente zusammenfasst (d. h. wir ignorieren den letzten Teil der IP-Adresse):

cat *-access.log | grep "22/Aug/2015:13" | awk '{ print $1 }' | awk -F "." '{ print $1 "." $2 "." $3}' | sort | uniq -c | sort -n | tail -n 20

dann zeigt sich in den neuen Ergebnissen sofort eine deutlich größere Traffic-Quelle:

235 109.81.210 
236 212.79.106 
242 37.48.34 
247 109.81.209 
262 78.108.103 
279 77.48.246 
282 109.81.211 
316 66.249.78 
321 178.77.233 
330 94.231.9 
334 109.81.208 
342 194.228.20 
345 84.42.146 
347 194.228.13 
483 157.55.39 
535 77.75.76 
816 207.46.13 
9448 195.250.131 
49823 127.0.0

Zu diesem Ergebnis sind wir in kürzester Zeit gekommen, und nun können wir prüfen, was genau und wie systematisch heruntergeladen wurde. Unsere Reaktion hängt dann von den Umständen und den weiteren Erkenntnissen ab.

Die am häufigsten aufgerufenen URLs

Die Befehlskette lässt sich ebenso leicht so anpassen, dass sie eine Liste der am häufigsten angeforderten URLs anzeigt. Möchten wir also zum Beispiel sehen, welche URLs aus dem verdächtigen Segment, das wir im vorherigen Schritt entdeckt haben, am häufigsten angefragt wurden, geht das ganz einfach so:

cat host-access.log | grep "195.250.131" | grep "22/Aug/2015:13" | awk '{ print $7 }' | sort | uniq -c | sort -n | tail -n 20

Als Ergebnis erhalten wir dann etwa Folgendes:

42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_offer_pronajem&page=4 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_offer_pronajem&page=5 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_offer_pronajem&page=6 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_offer_spolubydleni&page=2 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_offer_spolubydleni&page=3 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_offer_spolubydleni&page=4 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_offer_spolubydleni&page=5 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_offer_spolubydleni&page=6 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_request_spolubydleni&page=2 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_request_spolubydleni&page=3 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_request_spolubydleni&page=4 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_request_spolubydleni&page=5 
42 /vypis/nabidka-prodej/nebytovy-prostor?aType=estate_request_spolubydleni&page=6 
42 /vypis/nabidka-prodej/rekreacni-objekt?aType=estate_offer_prodej&page=6 
46 /vypis?aType=estate_request_spolubydleni&estatetype=kancelar 
47 /vypis?aType=estate_offer_prodej&estatetype=kancelar 
47 /vypis?aType=estate_offer_pronajem&estatetype=kancelar 
47 /vypis?aType=estate_offer_spolubydleni&estatetype=kancelar 
47 /vypis?aType=estate_request_prodej&estatetype=kancelar 
47 /vypis?aType=estate_request_pronajem&estatetype=kancelar

Wer die einzelnen Teile versteht, kann den gesamten Befehl leicht anpassen und erhält damit ein sehr mächtiges Werkzeug für die Arbeit mit Logs. So lassen sich innerhalb einer Sekunde die gerade wichtigsten Informationen aus gigabytegroßen Logs mit Millionen von Einträgen herausfiltern.