Erstens mein Beileid, dass ich mich mit so etwas befassen muss. Aber du kannst das aufräumen. Zunächst muss ich nur Folgendes ansprechen:
Ich vermute, dass dies passiert ist, weil ich keinen SSH-Schlüssel mit meinem Passwort verwendet habe.
99% sind sich sicher, dass dies nicht der Fall ist. Nahezu jeder Webserver-Kompromiss, mit dem ich über 20 Jahre lang persönlich zu tun hatte - und den ich bereinigte -, stammte von Fehlern auf Anwendungsebene und nicht von irgendetwas, das mit SSH oder SFTP zu tun hatte. Tatsächlich werden die meisten Webentwickler / -administratoren niemals mit Kompromissen auf SSH- / SFTP-Ebene fertig werden. Fehler im Front-Facing-Code sind der Haupteinstiegspunkt für viele Malware-Teile und ungerechtfertigte Einbrüche in öffentliche Web-Systeme.
Und in Ihrem Fall geben Sie Folgendes an:
Dies war Ubuntu 14, und ich hatte dort 6 Apache VirtualHosts. Alle lebten.
Eine meiner Sites war eine WordPress-Installation mit einigen Plugins.
Auf einer anderen Website war Google Maps API-Code enthalten.
Ich vermute, dass Ihre WordPress-Installationen anfällig waren, es sei denn, Sie halten sich über WordPress-Updates / Patches auf dem Laufenden. Und nicht nur Core WordPress, sondern auch die Plugins.
Sichern Sie vorhandene Codebasis, Datenbank und Konfigurationen.
Das allererste, was ich tun würde, wäre, die virtuellen Apache-Hosts zu neutralisieren, indem ich index.phpin jedem der Stammindizes dieser Sites möglicherweise einen Eintrag mit der Aufschrift "Down for Maintenance" setze. Ich würde auch eine Kopie jeder virtuellen Host-Installation über ein TAR / Gzip-Archiv erstellen und diese für potenzielle Forensik herunterladen. Dies sollte für alle virtuellen Apache-Server durchgeführt werden, einschließlich der Speicherauszüge der MySQL-Datenbanken sowie der relevanten Konfigurationsdateien.
Überprüfen Sie das /tmp/Verzeichnis auf Anzeichen einer Infektion. blase es weg, wenn es sein muss.
Als nächstes würde ich empfehlen, dass Sie das /tmp/Verzeichnis auf dem Server sichern und neu erstellen . Der Grund dafür ist, dass viele Malware-Infektionen auf Linux-Webservern einen guten Teil ihrer Nutzlast in das /tmp/Verzeichnis stellen. Ich gehe hier auf diese Antwort näher ein, aber es läuft darauf hinaus, Folgendes zu tun.
Schauen Sie also zuerst in das /tmp/Verzeichnis und sehen Sie, ob etwas vorhanden ist, das nicht vorhanden sein sollte. 9 Mal von 10 Schadprogrammen auf Linux-Systemen können sich selbst installieren /tmp/.
Wenn Sie sich nicht sicher sind, was sich darin /tmp/befinden soll oder nicht, können Sie die schlechten Dinge auf einfache, aber extreme Weise beseitigen. Führen Sie dies einfach online in der Befehlszeile aus:
rm -rf /tmp && mkdir /tmp && chown root:root /tmp && chmod 1777 /tmp
Oder führen Sie jeden Befehl einzeln wie folgt aus:
sudo rm -rf /tmp
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp
Starten Sie dann den Server neu, um zu sehen, ob dies Abhilfe schafft. Wenn doch, herzlichen Glückwunsch! Aber Sie sind noch nicht aus dem Wald, da das ursprüngliche System immer noch in Ihr System eindringen kann. Es ist nur eine Frage der Zeit, bis Sie erneut infiziert werden. Das heißt, dies räumt die Unordnung auf, die durch eine Schwäche in Ihrem System verursacht wird, aber Sie müssen herausfinden, was diese Schwachstelle sein könnte, und sie härten.
Bash "Shellshock" -Anfälligkeitsprüfungen.
Und in dieser anderen Antwort gebe ich Tipps, wie Sie die bashSicherheitsanfälligkeit "Shellshock" überprüfen können . Diese Website bietet gute Testtools, mit denen Sie feststellen können, ob Ihr Server für bash"Shellshock" -Exploits anfällig ist . Ehrlich gesagt war dies eine der häufigsten Sicherheitslücken, die ich seit der Entdeckung beheben musste. Es besteht also eine gute Chance, dass dies auch eine Schwachstelle auf dem Server ist. Informationen zum Beheben von bashSicherheitslücken finden Sie im folgenden Abschnitt zum Aktualisieren / Patchen aller Komponenten auf Betriebssystemebene. Tun Sie das und bashsollten Sie auch upgraden / patchen.
Aktualisieren / Patchen aller Komponenten auf Betriebssystemebene.
Das klingt vielleicht einschüchternd, aber die Realität ist, dass für Linux-Systeme ständig Sicherheitspatches veröffentlicht werden. Und wenn Sie eine standardisierte Linux-Installation wie Ubuntu oder CentOS verwenden, können Sie einfach ein Update / Upgrade über Ihr Paketinstallationsprogramm wie dieses ausführen. Gehen Sie unter Ubuntu folgendermaßen vor:
sudo apt-get update
sudo apt-get upgrade
Wenn Sie das System längere Zeit nicht aktualisiert haben, sehen Sie möglicherweise eine große Anzahl von Patches und Updates, die behandelt werden müssen. Keine Panik! Das ist normal. Führen Sie einfach das updateund upgradeund warten Sie. Es könnte sein, dass Sie danach einen Neustart durchführen müssen, aber wenn dies erledigt ist, sollte Ihr Kernbetriebssystem vollständig gepatcht und auf dem neuesten Stand sein.
Bewerten Sie die Codebasis Ihrer Apache Virtual Server-Codesysteme. WordPress und Google API Zeug.
Machen Sie sich bereit: Dies ist der hässlichere Teil. Sie sollten die potenziell infizierte Codebasis herunterladen und bewerten . Hoffentlich wurden nur ein oder zwei Standorte kompromittiert. Die Vorgehensweise ist für jedes Setup eigenwillig. Im Allgemeinen sollten Sie jedoch jede Site in eine Entwicklungsumgebung laden, den WordPress-Kern aktualisieren, die Plug-Ins aktualisieren, prüfen, ob alles einwandfrei funktioniert, und dann den Code als sauber betrachten /stabil.
Jetzt habe ich diesen Schritt stark vereinfacht. Aber die Realität ist, dass Sie auch nach dem Ausführen von Patches und Upgrades immer noch Malware-Code in Ihrem WordPress-Kern haben können. Das andere, was Sie tun können, ist, jede WordPress-Site von Grund auf neu zu erstellen. Behalten Sie die Datenbanken, die Vorlagen und erstellen Sie die Site im Grunde genommen aus einem neuen, sauberen WordPress-Kern heraus neu.
Ja, das hört sich nach viel Arbeit an, aber wenn Sie so viele virtuelle Server mit unterschiedlichen Codebasen haben, gibt es keine andere Wahl.
Post-mortem-Beratung.
Das funktioniert nicht bei allen, aber ich sage es: Backups und vielleicht sogar ein GitHub-Repository für die saubere Codebasis sind der Weg, um das Durcheinander ohne den letzten unordentlichen "Bewertungs" -Schritt zu bereinigen, den ich oben ausgeführt habe.
Ich führe regelmäßig MySQL-Dumps auf jeder Datenbank-Site aus, an der ich arbeite, und stelle sicher, dass eine saubere Core-Codebasis in GitHub vorhanden ist. Wenn dann eine Malware-Infektion auftritt, kann ich die MySQL-Backups durchsuchen und sogar sauberen Code von GitHub erneut bereitstellen, um sicherzustellen, dass die Codebasis sauber ist. Und wenn der Server selbst einfach über den Tellerrand geschleudert wird? Nun, werfen Sie einfach das infizierte System aus, erstellen Sie ein neues Linux-System, stellen Sie den Code bereit, importieren Sie die Datenbanken, passen Sie die Konfigurationen an und rufen Sie es täglich auf.
Denken Sie daran, 99% aller Websites bestehen nur aus einer Datenbank, einer Codebasis und einer Reihe von Konfigurationen. Wenn Sie eine saubere Möglichkeit haben, nicht infizierten Code einzufrieren oder zu sichern, und eine Sicherung von MySQL-Datenbanken, müssen Sie sich nur um die Konfiguration kümmern. Das ist ein kleiner Schmerz im Vergleich dazu, Code von Grund auf aufzuräumen.