von php-hacker gesendete daten ueberwachen

[seth]

gudn tach!

danke fuer die ausfuehrliche allgemeine antwort. in meinem speziellen fall sind (gluecklicherweise) die meisten der von dir genannten bedenken zwar leicht ausraeumbar. aber im sinne einer allgemeinen anleitung/checklist stimme ich deiner antwort vollkommen zu (und bewerte sie deshalb auch als hilfreich). :-)

> . var_export($_REQUEST, true)

1. Enthält aber bei Standard-Voreinstellungen (in variables_order, request_order)

$_REQUEST = array();
$_REQUEST = $_GET;
$_REQUEST = $_POST;
$_REQUEST = $_COOKIE;

2. Du kannst also nicht unterscheiden was wie gesendet wurde.

ob POST oder GET ist mir nicht so wichtig. und ueber das apache-access-log wuerde ich ja den query-string im falle von GET ohnehin sehen. _COOKIE spielt hier, glaube ich, keine rolle.

Achte darauf, dass Dir das schreiben eines großen Logfiles ggf. das Dateisystem "zerfeilen" kann. Nämlich wenn es vollgeschrieben wird. Am besten nicht auf dem root-Dateisystem machen denn manche wissen nicht wie man das repariert (oder dass es dann zwingend zu einer gewissen Downtime kommt).

guter punkt. zwar hatte der boesewicht bisher jeweils nur ein paar megabyte drueber gesendet, aber das wuerde er ja vielleicht zum test mehrfach wiederholen, wenn er feststellt, das irgendwas nicht ganz klappt.

3. Nach 24h kommen die Angreifer meist nicht wieder.

naja, vielleicht nicht mehr die originalen, aber dann vielleicht deren kunden. in unserem fall kam jemand alle paar wochen mal, um die neuen scripts zu nutzen. immer aus der gleichen dynamischen ip-range aus karlsruhe.

4. Du musst noch tagelang Logfiles beobachten und nach POST suchen

ja, auf jeden fall.

was ja nicht mal reicht. Falls Du auch nur ein Skript übersehen hast: Die schreiben neue, harmlos klingende Skripte wie "helper.php" und eine Webshell IN eine Vielzahl (gemeint: hunderte) der vorhandenen Skripte hinein. Es kann sein, dass die Angreifer sich schneller neue Skripte installieren als Du löschen kannst. Alles zu löschen, was der Webserver beschreiben durfte ist auch faktisch der einige Weg das Zeug loszuwerden.

grundsaetzlich richtig. ich hatte in diesem fall noch aeltere sicherungen (von vor dem angriff) und konnte anhand eines grossen diffs sehr genau sehen, wo die aenderungen waren. es waren genau drei dateien betroffen.

5. In der Phase ist Dein Server meist schon verkauft. Also der eigentliche Hacker ist weg und hat den Nutzern (oft Spammer) den Server (genauer den Zugang) verkauft.

ja, so wird es vermutlich auch in unserem fall sein.

6. Kann Joomla sein, kann Wordpress sein, kann sonstwas sein - was Du zeigst ist nicht der Einbruch, sondern das Ergebnis.

ja, der erst spaet bemerkte einbruch selbst ist leider nicht mehr im log, weil das aus datenschutzgruenden leider nicht so lange gespeichert werden darf. andererseits ist es vermutlich fast egal, weil's vermutlich wegen so einer bagatelle keine grosse strafverfolgung gaebe -- erst recht, wenn der angreifer aus dem ausland kaeme. da fuer den account nur genau eine joomla-instanz lokal installiert war und sonst nix, sehe ich die wahrscheinlichkeit als sehr hoch ein, dass diese joomla-instanz gehackt wurde. es war ja eine bekanntermassen sehr unsichere version. andere domain-verzeichnisse auf demselben server wurden nicht manipuliert.

Es gilt aber: Nur wenn Joomla und Wordpress gemeinsam installiert ist würde ich bei "Wer wird Millionär" kurz schwanken.

wordpress ist fuer diesen account nicht installiert.

7. Auch die Datenbank kann "beschädigt" sein. Du hast das Datum des Einbruchs und ein Backup von einem Zeitpunkt davor? Dann weist Du was zu tun ist. Alle in der DB gespeicherten Passwörter (inklusive der für den Zugang zur DB) sind als verletzt anzusehen.

ja, die passwoerter sind bereits alle ersetzt. beim diff der db (von der ich auch ein backup habe), war auch nichts boeses drin. insofern denke ich, dass ich die instanz nicht neu installieren muss.

prost

seth