Ich wurde heute von DigitalOcean darüber informiert, dass die Verbindung zu meinem Droplet dort getrennt wurde, weil es einen DDoS-Angriff durchgeführt hat.
Sie haben mich gebeten, die Ursache zu untersuchen und herauszufinden.
Dies war Ubuntu 14 und ich hatte 6 Apache VirtualHosts darauf. Alle waren live.
Eine meiner Sites war eine WordPress-Installation mit einigen Plugins.
Eine andere Site enthielt Google Maps API-Code.
Der Rest enthielt nur meinen Originalcode.
Ich habe den Server noch nicht aufgerufen. Wenn ich das getan habe, wie gehe ich dann vor, um die Software zu finden, die das verursacht?
Ich vermute, dass dies passiert ist, weil ich keinen SSH-Schlüssel mit meinem Passwort verwendet habe.
Antwort1
Zunächst einmal mein Beileid, dass Sie sich mit so etwas herumschlagen müssen. Aber Sie können das in Ordnung bringen. 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% sicher, dass das nicht der Fall ist. So ziemlich jeder Webserver-Kompromitt, mit dem ich mich in meinen über 20 Jahren Erfahrung persönlich befasst und bereinigt habe, kam von Fehlern auf Anwendungsebene undnichtalles, was mit SSH oder SFTP zu tun hat. Tatsächlich werden die meisten Webentwickler/-administratoren nie mit Kompromittierungen auf SSH-/SFTP-Ebene zu tun haben; Fehler im Front-End-Code sind der Haupteinfallspunkt für viele Schadsoftwareteile und ungerechtfertigte Eindringlinge in öffentliche Websysteme.
Und in Ihrem Fall geben Sie Folgendes an:
Dies war Ubuntu 14 und ich hatte 6 Apache VirtualHosts darauf. Alle waren live.
Eine meiner Sites war eine WordPress-Installation mit einigen Plugins.
Eine andere Site enthielt Google Maps API-Code.
Ich vermute, dass Ihre WordPress-Installationen anfällig waren – sofern Sie nicht über aktuelle WordPress-Updates/-Patches verfügen. Und zwar nicht nur der WordPress-Kern, sondern auch die Plugins.
Sichern Sie den vorhandenen Code, die Datenbank und die Konfigurationen.
Als allererstes würde ich die virtuellen Apache-Hosts neutralisieren, indem ich index.phpin jedem der Stammindizes dieser Sites ein Häkchen mit der Aufschrift „Wegen Wartungsarbeiten nicht erreichbar“ setze. Ich würde auch eine Kopie der Installation jedes virtuellen Hosts über ein TAR/Gzip-Archiv erstellen und diese für mögliche forensische Untersuchungen herunterladen. Dies sollte für alle virtuellen Apache-Server durchgeführt werden, einschließlich der Dumps der MySQL-Datenbanken und der relevanten Konfigurationsdateien.
Überprüfen Sie das /tmp/Verzeichnis auf Anzeichen einer Infektion und blasen Sie es gegebenenfalls weg.
Als nächstes würde ich Ihnen empfehlen, das /tmp/Verzeichnis auf dem Server zu sichern und neu zu erstellen. Der Grund dafür ist, dass viele Malware-Infektionen auf Linux-Webservern einen großen Teil ihrer Nutzlast in diesem /tmp/Verzeichnis platzieren. Ich gehe näher darauf einin dieser Antwort hieraber es läuft darauf hinaus, Folgendes zu tun.
Sehen Sie sich also zunächst das /tmp/Verzeichnis an und prüfen Sie, ob dort etwas vorhanden ist, das dort nicht hingehört. In 90 % der Fälle kann sich Malware auf Linux-Systemen installieren /tmp/.
Wenn Sie sich nicht sicher sind, was drin sein sollte/nicht drin sein sollte, /tmp/gibt es eine einfache – aber extreme – Möglichkeit, die schlechten Sachen zu entfernen. Führen Sie einfach das hier 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 das Problem dadurch behoben wird. Wenn ja, herzlichen Glückwunsch! Aber Sie sind noch nicht über den Berg, denn was auch immer das ursprüngliche System verursacht hat, kann immer noch in Ihr System eindringen. Es ist nur eine Frage der Zeit, bis es Sie erneut infiziert. Das heißt, dies beseitigt das Chaos, das durch eine Schwachstelle in Ihrem System verursacht wurde, aber Sie müssen herausfinden, was diese Schwachstelle sein könnte, und sie absichern.
Bash „Shellshock“-Schwachstellenprüfungen.
Und in dieser anderen Antwort gebe ich Tipps zur Überprüfung auf bash„Shellshock“-Sicherheitslücken.Diese Site bietet gute Testtoolsum zu sehen, ob Ihr Server anfällig für bash„Shellshock“-Exploits ist. Ehrlich gesagt war dies eine der häufigsten Sicherheitslücken, die ich seit ihrer Entdeckung patchen musste. Es besteht also eine gute Chance, dass dies auch eine Schwachstelle auf dem Server sein könnte. Informationen zum Beheben bashgefundener Schwachstellen finden Sie im folgenden Abschnitt zum Aktualisieren/Patchen aller Komponenten auf Betriebssystemebene. Wenn Sie dies tun, bashsollten auch Upgrades/Patches durchgeführt werden.
Aktualisieren/patchen Sie alle Komponenten auf Betriebssystemebene.
Das klingt vielleicht entmutigend, aber in Wirklichkeit werden ständig Sicherheitspatches für Linux-Systeme veröffentlicht. Und wenn Sie eine standardisierte Linux-Installation wie Ubuntu oder CentOS verwenden, können Sie ein Update/Upgrade einfach wie folgt über Ihr Paketinstallationsprogramm ausführen. Unter Ubuntu gehen Sie einfach wie folgt vor:
sudo apt-get update
sudo apt-get upgrade
Wenn Sie das System nun eine Weile nicht aktualisiert haben, sehen Sie möglicherweise eine große Anzahl von Patches und Updates, die bearbeitet werden müssen. Keine Panik! Das ist normal. Führen Sie einfach das aus updateund upgradewarten Sie. Möglicherweise müssen Sie anschließend neu starten, aber wenn dies erledigt ist, sollte Ihr Kernbetriebssystem vollständig gepatcht und auf dem neuesten Stand sein.
Bewerten Sie die Codebasis Ihrer virtuellen Apache-Server-Codesysteme; WordPress- und Google-API-Sachen.
Machen Sie sich bereit: Dies ist der hässlichere Teil. Sie sollten die Codebasis herunterladen und bewerten, diemöglicherweiseinfiziert. Hoffentlich wurden nur eine oder zwei Websites kompromittiert. Wie man dabei vorgeht, ist bei jeder Konfiguration anders, aber im Allgemeinen sollten Sie jede Website in eine Entwicklungsumgebung laden, den WordPress-Kern aktualisieren, die Plug-Ins aktualisieren, prüfen, ob alles einwandfrei funktioniert, und den Code dann als sauber/stabil betrachten.
Jetzt habe ich diesen Schritt stark vereinfacht. Aber die Realität ist, dass selbst nach Patches und Upgrades immer noch Malware-Code in Ihrem WordPress-Kern vorhanden sein kann. Sie können also auch jede WordPress-Site von Grund auf neu erstellen. Behalten Sie die Datenbanken und Vorlagen und erstellen Sie die Site im Grunde genommen aus einem neuen, sauberen WordPress-Kern neu.
Ja, das klingt nach viel Arbeit, aber wenn Sie so viele virtuelle Server mit unterschiedlichen Codebasen haben, haben Sie keine andere Wahl.
Post-mortem-Beratung.
Das funktioniert nicht bei allen, aber eines sage ich Ihnen: Backups und vielleicht sogar ein GitHub-Repository für die saubere Codebasis sind die beste Möglichkeit, das Chaos zu beseitigen, ohne den chaotischen letzten „Bewertungs“-Schritt, den ich oben beschrieben habe.
Ich führe regelmäßig MySQL-Dumps auf allen Datenbank-basierten Websites aus, an denen ich arbeite, und stelle sicher, dass sich eine saubere Kerncodebasis auf GitHub befindet. 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 unglaublich beschimpft wurde? Nun, ich lösche einfach das infizierte System, baue ein neues Linux-System auf, stelle den Code bereit, importiere die Datenbanken, passe die Konfigurationen an und fertig.
Denken Sie daran, dass 99 % aller Websites nur aus einer Datenbank, einer Codebasis und einer Reihe von Konfigurationen bestehen. Wenn Sie eine saubere Möglichkeit haben, nicht infizierten Code und ein Backup der MySQL-Datenbanken „einzufrieren“ oder zu sichern, müssen Sie sich nur noch um die Konfiguration kümmern. Was im Vergleich dazu, den Code von Grund auf zu bereinigen, ein kleiner Aufwand ist.