~~~php > . var_export($_REQUEST, true) ~~~ 1. Enthält aber bei Standard-Voreinstellungen (in variables_order, request_order) ~~~php $_REQUEST = array(); $_REQUEST = $_GET; $_REQUEST = $_POST; $_REQUEST = $_COOKIE; ~~~ 2. Du kannst also nicht unterscheiden was wie gesendet wurde. 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). 3. Nach 24h kommen die Angreifer meist nicht wieder. 4. Du musst noch tagelang Logfiles beobachten und nach POST suchen - 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. 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. 6. Kann Joomla sein, kann Wordpress sein, kann sonstwas sein - was Du zeigst ist nicht der Einbruch, sondern das Ergebnis. Es gilt aber: Nur wenn Joomla und Wordpress gemeinsam installiert ist würde ich bei "Wer wird Millionär" kurz schwanken. 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.

~~~php > . var_export($_REQUEST, true) ~~~ 1. Enthält aber bei Standard-Voreinstellungen (in variables_order, request_order) ~~~php $_REQUEST = array(); $_REQUEST = $_GET; $_REQUEST = $_POST; $_REQUEST = $_COOKIE; ~~~ 2. Du kannst also nicht unterscheiden was wie gesendet wurde. 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). 3. Nach 24h kommen die Angreifer meist nicht wieder. 4. Du musst noch tagelang Logfiles beobachten und nach POST suchen - 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. 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. 6. Kann Joomla sein, kann Wordpress sein, kann sonstwas sein - was Du zeigst ist nicht der Einbruch, sondern das Ergebnis. 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.

~~~php > . var_export($_REQUEST, true) ~~~ 1. Enthält aber bei Standard-Voreinstellungen (in variables_order, request_order) ~~~php $_REQUEST = array(); $_REQUEST = $_GET; $_REQUEST = $_POST; $_REQUEST = $_COOKIE; ~~~ 2. Du kannst also nicht unterscheiden was wie gesendet wurde. Achte darauf, dass Dir das 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). 3. Nach 24h kommen die Angreifer meist nicht wieder. 4. Du musst noch tagelang Logfiles beobachten und nach POST suchen - 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. 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. 6. Kann Joomla sein, kann Wordpress sein, kann sonstwas sein - was Du zeigst ist nicht der Einbruch, sondern das Ergebnis. 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.

~~~php > . var_export($_REQUEST, true) ~~~ 1. Enthält aber bei Standard-Voreinstellungen (in variables_order, request_order) ~~~php $_REQUEST = array(); $_REQUEST = $_GET; $_REQUEST = $_POST; $_REQUEST = $_COOKIE; ~~~ 2. Du kannst also nicht unterscheiden was wie gesendet wurde. Achte darauf, dass Dir das 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). 3. Nach 24h kommen die Angreifer meist nicht wieder. 4. Du musst noch tagelang Logfiles beobachten und nach POST suchen - 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. 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. 6. Kann Joomla sein, kann Wordpress sein, kann sonstwas sein - was Du zeigst ist nicht der Einbruch, sondern das Ergebnis. 7. Auch die Datenbank kann "beschädigt" sein. Du hast das Datum vor dem 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.

~~~php > . var_export($_REQUEST, true) ~~~ 1. Enthält aber bei Standard-Voreinstellungen (in variables_order, request_order) ~~~php $_REQUEST = array(); $_REQUEST = $_GET; $_REQUEST = $_POST; $_REQUEST = $_COOKIE; ~~~ 2. Du kannst also nicht unterscheiden was wie gesendet wurde. Achte darauf, dass Dir das 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). 3. Nach 24h kommen die Angreifer meist nicht wieder. 4. Du musst noch tagelang Logfiles beobachten und nach POST suchen - 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. Die komplette Joomla-Installation zu löschen ist auch faktisch der einige Weg das Zeug loszuwerden. 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. 6. Kann Joomla sein, kann Wordpress sein, kann sonstwas sein - was Du zeigst ist nicht der Einbruch, sondern das Ergebnis. 7. Auch die Datenbank kann "beschädigt" sein. Du hast das Datum vor dem 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.

~~~php > . var_export($_REQUEST, true) ~~~ 1. Enthält aber bei Standard-Voreinstellungen (in variables_order, request_order) ~~~php $_REQUEST = array(); $_REQUEST = $_GET; $_REQUEST = $_POST; $_REQUEST = $_COOKIE; ~~~ 2. Du kannst also nicht unterscheiden was wie gesendet wurde. Achte darauf, dass Dir das 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). 3. Nach 24h kommen die Angreifer meist nicht wieder. 4. Du musst noch tagelang Logfiles beobachten und nach POST suchen - 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 sein, dass die Angreifer sich schneller neue Skripte installieren als Du löschen kannst. Die komplette Joomla-Installation zu löschen ist auch faktisch der einige Weg das zeug loszuwerden. 5. Kann Joomla sein, kann Wordpress sein, kann sonstwas sein - was Du zeigst ist nicht der Einbruch, sondern das Ergebnis. 6. Auch die Datenbank kann kaputt sein. Du hast das Datum vor dem 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.