Ich betreibe einen Ubuntu 12.04 x64 VPS mit Vesta und eine Site in PHP. Sie wurde mehrmals mit eingeschleustem Code gehackt, der so aussieht:
<?php $KoDgalxVvsZfidVcEOTJDeMX='ba'.'se6'.'4_deco'.'de';eval($KoDgalxVvsZfidVcEOTJDeMX("cHJlZ19yZXBsYWNlKCIvN0xna0xnND1IR2JEOGs2WDht....
Um das Problem zu beheben, habe ich beschlossen, die Berechtigungen und den Besitzer aller Dateien auf 555 und Root zu ändern, damit kein Benutzer die Dateien ändern kann. Ich habe den FTP-Zugriff entfernt und SSH gesichert, sodass nur die Schlüssel, die ich im VPS habe, eine Verbindung herstellen können.
Trotz all dieser Änderungen ist es einem anderen Benutzer immer möglich, Dateien zu ändern, Ordner umzubenennen und eine andere gehackte Datei hochzuladen.
Was übersehe ich Ihrer Meinung nach? Irgendwelche Vorschläge? Danke! Wenn Sie weitere Informationen zu diesem Thema benötigen, gebe ich diese gerne weiter, um anderen zu helfen, die unter demselben Übel leiden!
Antwort1
Ein Angreifer hat sich Rootzugriff auf Ihr System verschafft. Sie können NICHTS auf dem System vertrauen. Die Möglichkeiten eines Rootkits sind enorm.
Wenn Sie irgendwo Backups Ihrer Inhalte haben, verwenden Sie diese. Andernfalls können Sie hoffen, dass der Angreifer Ihre Daten nicht durcheinandergebracht hat. Sichern Sie Ihre SQL-Tabellen und kopieren Sie diese zusammen mit Ihren anderen Sachen (JPGs, PDFs, HTML, aber KEINE Skripte/PHP/alles andere, das ausgeführt wird). Kopieren Sie sie auf ein anderes System oder laden Sie sie auf Ihren Heimcomputer herunter, wenn sie klein genug ist, damit Sie sie erneut hochladen können.
Stellen Sie mit allen Mitteln sicher, dass das, was Sie kopiert haben, noch in Ordnung ist. (Überprüfen Sie beispielsweise zur Sicherheit, ob alle JPGs noch gültig sind. Führen Sie ggf. einen Virenscanner aus.)
Beseitigen Sie die kompromittierte Installation. Wenn Ihr Server auf einem typischen Hosting-Dienst gehostet wird, ist dieser hoffentlich so eingerichtet, dass Sie ein Bedienfeld haben, das selbst von Root-Benutzern auf dem Host nicht durcheinandergebracht werden kann. Sie können also hoffen, dass der Angreifer nichts außerhalb der kompromittierten Maschine erreichen konnte. (Wenn Sie jedoch passwortlosen Zugriff auf andere Dinge auf dieser Maschine hatten, überprüfen Sie dies.)
Führen Sie alles durch, was für eine Neuinstallation erforderlich ist. Sie können auch gleich auf Ubuntu 14.04 LTS umsteigen, da Sie ohnehin neu installieren müssen.
Kopieren Sie KEINEN Code vom infizierten System auf das neue System. Alle Daten, die vom infizierten System stammen, sollten wie potenzielle Seuchenüberträger behandelt werden.
Die Semantik des Unix-Dateisystems erfordert Schreibberechtigung für das Verzeichnis, damit Sie Dateien entfernen können. (Dateinamen sind Links von einem Namen zu einem Inode. Der Systemaufruf zum Erstellen von Hardlinks (andere Namen für eine Datei) lautetlink(2), und der Aufruf zum Entfernen einer Datei istunlink(2).)
Wenn das Sticky Bit für ein Verzeichnis gesetzt ist ( chmod +t), muss der Aufrufer unlink(2)auch rename(2)Eigentümer der Datei sein, deren Verknüpfung aufgehoben oder umbenannt werden soll (unabhängig von der Schreibberechtigung für die Datei). Standardmäßig ist für und /tmp( allgemein beschreibbar mit gesetztem Sticky Bit) festgelegt./var/tmp1777
rm, der Shell-Befehl, wird benötigt vonPOSIXvor dem Aufheben der Verknüpfung schreibgeschützter Dateien eine Abfrage durchführen, aber es muss diesen Fall überprüfen. Es muss eigentlich nicht mehr tun, als unlink(2)es für jede andere Datei tun würde. Lassen Sie sich also nicht täuschen und denken, dass dies überhaupt irgendeinen Effekt auf einen Angreifer hat.
Nichts davon ist für die Abwehr von Angriffen besonders relevant, da der wahrscheinlichste Fall die Erlangung der Kontrolle über Ihren Webserverprozess oder etwas anderes ist, das mit einer Benutzer-ID ausgeführt wird, die Schreibzugriff auf viele Dinge hat.
Je mehr Sie einschränken können, was von Prozessen geschrieben werden kann, die mit Daten aus dem Internet umgehen müssen, desto geringer ist die Chance eines Angreifers, von der Kontrolle über Ihren httpd zur Änderung Ihrer Daten oder zur Kontrolle über Ihren gesamten Computer überzugehen.
Aus diesem Grund sollten Sie Apache nicht als Root ausführen.
Antwort2
Wenn Sie es vermeiden können, sollten Sie die Webserverprozesse nicht als Root-Benutzer ausführen, da dies bedeutet, dass die Ausnutzung einer Sicherheitslücke im Webdienst den gesamten Server kompromittiert.
Angesichts Ihrer aktuellen Situation würde ich empfehlen, auf einem neuen Server von vorne zu beginnen. Der Angreifer hätte sich auf unterschiedliche Weise dauerhaften Root-Zugriff verschaffen können. SieheHierfür mehr Informationen.
Antwort3
Trotz all dieser Änderungen ist es einem anderen Benutzer immer möglich, Dateien zu ändern, Ordner umzubenennen und eine andere gehackte Datei hochzuladen.
Wenn das übergeordnete Verzeichnis Ihres Webstammverzeichnisses demselben Benutzer gehört, der den Webserver betreibt, überschreiben diese Berechtigungen für das übergeordnete Verzeichnis alle für untergeordnete Dateien und Verzeichnisse festgelegten Berechtigungen.
Öffnen Sie beispielsweise einen „Terminal“-Prozess in einem beliebigen Verzeichnis. Erstellen Sie nun eine Datei mit zzz_test.txtfolgendem Namen:
touch zzz_foo.txt
Überprüfen Sie nun die Datei wie folgt:
ls -la zzz_foo.txt
Berechtigungen sehen in meinem Fall folgendermaßen aus:
-rw-r--r-- 1 jake staff 0 Feb 23 19:11 zzz_foo.txt
Dann laufe ich chmodso:
chmod 555 zzz_foo.txt
Führen Sie es nun ls -laerneut aus. Das Ergebnis sieht folgendermaßen aus:
-r-xr-xr-x 1 jake staff 0 Feb 23 19:11 zzz_foo.txt
Okay, die Berechtigungen wurden geändert. Also machen wir etwas „Verrücktes“, wie den Versuch, sie zu löschen:
rm zzz_foo.txt
Die Antwort wäre:
override r-xr-xr-x jack/staff for zzz_foo.txt?
Und dann einfach draufdrücken yund returnvoilà! Die Datei ist weg.
Aus diesem Grund ist das einfache Ändern der Dateiberechtigungen nie eine effektive Methode, um einen Webserver zu sichern. Die einfache Funktionsweise von Webservern – insbesondere wenn sie auf PHP basieren – bedeutet, dass der Webserverbenutzer immer Lese- und Schreibzugriff auf die Dateien hat, auf die er zugreifen muss. Daher chmod 555 [some files]ist das einfache Ändern der Dateiberechtigungen keine effektive Methode, sich gegen Malware und Hackerangriffe zu „schützen“.
Und was können Sie jetzt tun? Nun, das einfache Ändern von Berechtigungen und Eigentümerschaft bringt nichts. Das größere Problem ist, dass Ihre PHP-Codebasis anfällig für Angriffe ist. Die einzige effektive Möglichkeit, solche Dinge zu bereinigen, ist also, Ihren PHP-Code zu bereinigen. Wenn diese Site auf einem vorgefertigten Framework wie Joomla!, WordPress oder CakePHP basiert, besteht die beste Vorgehensweise darin, das Kern-Framework von Joomla!, WordPress oder CakePHP zu aktualisieren, um die Sicherheitslücke zu schließen. Wenn es ein Joomla!-, WordPress- oder CakePHP-Plugin gibt, das anfällig für Angriffe ist, sollte dieses Plugin aktualisiert/gepatcht werden, um die Lücke zu schließen.
Und darüber hinaus sollte Ihre zentrale Systemsoftware (vorausgesetzt, es handelt sich um einen LAMP-Stack (Linux Apache MySQL PHP)) auf dem neuesten Stand gehalten und ebenfalls gepatcht werden.
Letzten Endes ist Website-Sicherheit keine einmalige Sache. Es ist eine allgemeine Mentalität und ein Wartungsprozess, der eingehalten werden muss. Andernfalls werden Sie nach einem Hack Ihrer Website kopflos versuchen, das Chaos zu beseitigen, das tatsächlich mehr Schaden anrichten kann als der ursprüngliche Malware-Einbruch selbst.
Antwort4
Ich bin damit einverstanden, mit der Serveroption neu anzufangen, aber wenn Sie mehr Sicherheit und Kontrolle wünschen, ist ein dedizierter Server eine bessere Idee.
Was Ihre Situation betrifft, schlage ich als Erstes vor, alle laufenden Dienste außer dem Shell-Zugriff zu deaktivieren. Das bedeutet, den FTP-Dienst, den Webserver (HTTP), E-Mail usw. zu stoppen. Gehen Sie als Nächstes in die Shell und navigieren Sie zu den Ordnern, die die Elemente enthalten, von denen Sie behaupten, dass sie gehackt werden. Geben Sie dann Folgendes ein:
ls -al
In den Ergebnissen sollten Sie ungefähr Folgendes sehen:
drwxrwxrwx 2 root root 4096 2014-10-10 00:31 ./
Wenn das vierte (oder insbesondere das dritte) Element tatsächlich „root“ ist, dann stecken Sie in großen Schwierigkeiten und müssen die Konfiguration Ihres Webservers so überarbeiten, dass er die Dinge je nach Ordner als unterschiedliche Benutzer ausführt. Sie sollten sich mod_rewrite (oder ähnliches) für Apache ansehen und dann Ihre Apache-Konfigurationsdatei (httpd.conf) entsprechend anpassen, damit das System den Benutzernamen ändert, wenn jede Anfrage an den Ordner gestellt wird. Ändern Sie dann den Benutzernamen und den Gruppennamen des Ordners entsprechend.
Sobald dies behoben ist, navigieren Sie zum Stammordner des Dokuments (wahrscheinlich public_html), verwenden Sie einen Editor (Pico funktioniert) und geben Sie Folgendes ein:
<?php
echo shell_exec("whoami");
?>
dann speichern Sie es als who.php. Schalten Sie als nächstes den Webserver ein und rufen Sie in einem beliebigen Browser die Homepage Ihrer Website auf, fügen Sie jedoch who.php am Ende hinzu, und Sie sollten nur ein Wort auf dem Bildschirm sehen. Wenn dieses Wort root ist, dann stecken Sie in großen Schwierigkeiten und müssen die obigen Schritte erneut ausführen. Wenn das Wort nobody ist, dann stecken Sie in Schwierigkeiten, weil Hacker diesen Benutzernamen sehr gut kennen.