Fremdes SCript versucht PHP Datei aufzurufen

[naxort]

Guten Tag zusammen,

ich hatte vor einigen Tagen einen Hacker auf einer meiner Kundenwebseiten, es wurde ein Ordner Journal erstellt und darin ein PHP Script v59cq.php, welches von außen immer aufgerufen wurde und den Apache Speicher total ausgelastet hat. Anschließend ist Apache abgestürzt und keine Seite mehr hat funktioniert.

Nun habe ich Sicherheitsvorkehrungen getroffen und alle schädlichen Dateien gelöscht sowie die Passwörter geändert, geupdatet etc.

Aber nun wird immer noch versucht, das Script von außen aufzurufen, obwohl es nicht mehr existiert, die Auslastung bei Apache geht aber immer noch weiter hoch und irgendwann wird der Server deswegen wird abstürzen..Was kann ich dagegen tun ?

Bild:

MOD: Bilder bitte immer als Anhang. Danke!


Vielen Dank im Voraus

 

[Cyperghost]

Ich würde ein älteres Backup einspielen(bei dem du dir zu 100% sicher bist das der Hacker dort nicht eingeschleust hat). Anschließend das System wo durch er rein gekommen ist(sofern bekannt) absichern und die Firewall anpassen.

Ggfs. einfach den ganzen Pfad als nicht erlaubt deklarieren und somit das Skript hintern weiter auszuführen, hilft natürlich nur wenn dies ein automatisiertes System ist und dort nicht ein variabler Pfad ggfs. verwendet wird

 

[danton]

Da du schon fleissig gelöscht hast, wird die Analyse schwierig werden. Du musst davon ausgehen, dass dein System weiterhin vom Eindringling kontrolliert werden kann.
Bedeutet im Prinzip: Sicherheitslücke ermitteln und von da aus alle Schritte, die der Eindringling durchgeführt hat, nachvollziehen (das wird schwierig, da du vieles gelöscht hast, was dir da Hinweise bietet). Entsprechend ist der sicherste Weg, das System neu zu installieren. Dann benötigst du ein Backup, von dem zu zu 100% weißt, dass es sauber ist. Die Sicherheitslücke musst du natürlich immer noch finden und schließen.

 

[naxort]

Okay dann versuche ich zunächst ein altes Backup einzuspielen und anschließend gehe ich noch mal jeden einzelnen Schritt durch.

Das Problem fing wohl erst so vor 10 Tagen an, brauchte erstmal lange, um herauszufinden, woher die Auslastung überhaupt kam, da half mir auch der Error log von apache oder nginx nicht weiter.

Auf jeden Fall versuche ich mal ein Backup ein Monat zuvor einzuspielen und melde mich dann noch mal. Monitoring ist auch aktiv und fail2ban warnt vor jedem Eindringling.

Gibt es irgendeine Möglichkeit, solche Zugriffe auf PHP Dateien zu verhindern ?

Viele Grüße und Danke !

 

[marce]

ein altes Backup in das bestehende System einzuspielen ist nicht ausreichend.

Du weißt nicht, was derjenige sonst noch alles auf dem Server gemacht hat. Sprich - an komplett neu aufsetzen und dann ein vertrauenswürdiges Backup einspielen (was z.B. heißt, es vorher auf einem ded. Testsystem einzuspielen und zu komplett prüfen, ...) kommst Du nicht vorbei.

 

[danton]

Monitoring ist auch aktiv und fail2ban warnt vor jedem Eindringling.

Nein, macht fail2ban nicht. Der kann nur auf die Angriffsvektoren reagieren, die sich auch in Logdateien verewigen und bei denen er auch entsprechende Logzeilen angesetzt wurde.
Wenn dein Eindringling über eine Lücke in einem PHP-Script eingestiegen ist, bekommst du das nicht sofort mit. Du siehst dann nur irgendwann das Resultat, z.B. wie hier eine Datei, die auf deinen Server übertragen wurde. Wenn ein Eindringling erst mal auf dem Server drauf ist, kann er sich darüber dann z.B. über eine lokal ausnutzbare Lücke Root-Rechte verschaffen und eine Backdoor o.ä. installieren. Deshalb sagte ich ja auch: Neuinstallation des Servers.

Gibt es irgendeine Möglichkeit, solche Zugriffe auf PHP Dateien zu verhindern ?

Falscher Ansatz: Du musst verhindern, dass solche PHP-Scripte überhaupt auf dem Server landen, nicht erst reagieren, wenn das Kind schon in den Brunnen gefallen ist.

 

[naxort]

Das ist mir Klar, dass ich auch verhindern möchte, dass so etwas grundlegend passieren kann. Allerdings verwenden viele meiner Kunden Wordpress. Und wenn dann so eine Sicherheitslücke entdeckt wird wie z.B. von WPGDR, mit welcher einfach so Adminkonten erstellt werden können, lässt sich das nicht sofort verhindern.

Ich muss mal schauen, wie groß der Aufwand ist, den Server einfach so neu zu installieren und Plesk wieder inkl. Backup auf den Server zu bekommen. Und am besten so, dass Kundendomains nicht langfristig eine größere Downtime in Kauf nehmen müssen.

VG

 

[danton]

Das Problem ist, gute von bösen PHP-Scripts zu unterscheiden. Das ist meiner Meinung nach mit vertretbarem Aufwand nicht möglich. Beispiel: Wenn sich jemand in Wordpress über eine Lücke Adminrechte verschafft, kann er ja auch ein z.B. ein legitimes Newsletter-Addon installieren und dieses dann zum Spammen missbrauchen.
Ansonsten kannst du natürlich z.B. mit Addons wie Apaches mod_security und einem entsprechenden Regelwerk einige Angriffsvektoren abschwächen. Aber du musst auch darauf achten, dass du deinen Server nicht zu sehr abdichtest und damit deine Kunden zu sehr gängelst.

 

[Joe User]

Kunden? Diese musst Du umgehend und umfassend über den Hack informieren, sonst wird es teuer.
Ausserdem kannst Du nicht einfach ein altes Backup einspielen und damit Daten Deiner Kunden vernichten, das ist dann so gar strafbar.

Besorg Dir dauerhaft einen professionellen Admin, das bist Du Deinen Kunden und dem Rest des Internets schuldig.



Was Du da gerade tust, ist grob fahrlässig und somit rechtlich sehr kritisch bis strafbar...

 

[d4f]

Vorweg, die Wahrscheinlichkeit dass der Server als Ganzes infiziert ist sehe ich von dem Geschriebenen als sehr gering an. Art und Umfang der Infektion deuten auf ein Sicherheitsloch in einer Webanwendung über welche der Code eingeschleust wurde.

Es kann Tage oder Wochen dauern bis die nicht mehr vorhandenen Dateien nicht mehr referenziert werden wenn es in Spam/Scam-EMails zum Einsatz kam, die drauf reinfallende Oma liest ihre Emails halt nicht so oft...

Generell hilft es schon viel über htaccess die entsprechende Seite mit 403 aus zu liefern statt den Error-Handlern von Apache oder der Webseite die Auslieferung zu überlassen.

Ich will hier nicht laxe Praktiken vertreten, aber man muss auch nicht direkt den Teufel an die Wand malen. Trotz guter Sicherheitsvorkehrungen auf Host-Seite tritt ein solcher Vorfall viel zu oft auf. Spätestens wenn es am Telefon mal wieder geht "Guten Tag, hier ist die Gerichtspolizei" ist man als Hoster über den Vorfall informiert wenn das eigene Monitoring es noch nicht anzeigte.
Die Praxis zeigt folgende Schritte sind -unter Annahme dass der Server nicht selber infiziert ist- generell ausreichend und sinnvoll
- Webseite mit Passwortschutz versehen so dass Kunde sie reparieren kann
- Bei Auftrag des Kunden Backup einspielen oder kostenpflichtig reparieren (ob ein Backup der Infektion angelegt wird ist dem Kunden zu überlassen)
- Webseite mit Scanner überprüfen ob der Kunde seine Arbeit gemacht hat
- Freischalten

Generell sind bis auf wenige schwarze Schafe die Kunden dann vom Update-Verschleppen geheilt. Eine Abuse-Meldung von Pfitzer oder Europol-Kontakt kann echte Wunder wirken.