Viele WordPress-Admins reagieren falsch. Daher: eine Anleitung in wenigen Schritten.

Schritt 1: Don’t panic!

Dieser Schritt wird am häufigsten falsch gemacht. Es werden schnell irgendwelche Backups eingespielt, Dateien verändert und andere Änderungen gemacht. Diese Veränderungen vernichten wichtige Daten, welche man in Schritt 4 benötigt, um den Angriffsweg zu rekonstruieren und dauerhaft etwas gegen das Problem zu unternehmen. Denn was hilft es, wenn die Seite nach 30 Minuten wieder läuft, 3 Tage später aber schon wieder infiziert ist? Deswegen: don’t panic. Keine Schnellschüsse. Wenn die Seite bereits infiziert ist, muss man gründlich vorgehen, auf 30 Minuten kommt es dann nicht mehr an.

Schritt 2: Seite offline nehmen

Die meisten Admin-Panel von Webhostern bieten die Möglichkeit die Seite offline zu nehmen. Nutze dies. Oder willst du wirklich, dass Google deine Seite als Schädlingsverteiler identifiziert und deine Kunden infiziert werden? Also. Nimm die Seite offline und schreibe eine kleine Entschuldigung.

Schritt 2 ist auch der Punkt wo du dich entscheiden solltest – lässt du einen Profi dran oder willst du das selbst machen? Wenn du einen Profi dranlassen willst: tu das nach diesem Punkt, z.B. biete ich das Befreien von WordPress-Installationen von Viren an. Wenn du es selbst machen willst: lies weiter.

Schritt 3: Backup machen

Wenn Du kein sehr zeitnahes Backup hast: mach jetzt eines. Das heisst ein Download aller Daten via FTP und ein Export der gesamten SQL-Datenbank.

Schritt 4: WordPress Virus finden und Angriffsweg identifizieren

Irgendwie ist der Angreifer ja reingekommen. Herauszufinden wie das geschehen ist ist wichtig – wie willst du sonst verhindern, dass das 3 Tage später wieder geschieht?

Zwei verschiedene Sachen können infiziert sein: Dateien oder SQL-Datenbank. Grob gesagt gibt es dazu vier verschiedene Angriffswege:

1. Sicherheitslücken, die Angreifer es ermöglichen, Dateien auf den Webspace zu schreiben
2. Sicherheitslücken, die via SQL-Injections  Zugriff auf die Datenbank ermöglichen
3. Abgreifen von Logindaten und / oder Mechanismen, die das Login übergehen und dem Angriff alle Möglichkeiten des Admin-Backends geben
4. Abgreifen von FTP-Zugangsdaten

Bei der Analyse helfen können folgende weitere Informationen helfen:

• access.log und error.log, zwei Logdateien, welche es oft im Admin-Bereich des Hosters gibt und welche alles beinhalten, was auf dem Webserver (Web, nicht FTP!) geschehen ist.
• FTP Transfer Log: dieses Log beinhaltet jedes Login und jede Dateiübertragung via FTP und gibt es bei vielen Hostern nur auf Anfrage, kann aber sehr dabei helfen festzustellen, ob Angriffsweg 4 genutzt wurde.
• Erstellungsdatum und Datum der letzten Änderung einer Datei auf dem Webspace. Beide Daten können zwar manipuliert werden, Angreifer vergessen dies aber oft, so dass man über das letzte Änderungsdatum oft den exakten Zeitpunkt des Angriffs festlegen kann. Hat man Schritt 1 nicht befolgt und ein Backup eingespielt fehlt einem diese wichtige Information.
• Suche nach den Begriffen „eval“, „base64“, „curl“, „gzinflate“, „rot13“, … in Dateien und Datenbank. Dies sind typische Funktionen, mit denen Viren arbeiten. Die gibt es ab und an zwar auch in WordPress selbst oder in Plugins / Themes, in Dateien oder Datensätzen mit diesen Begriffen sollte man aber mal genauer schauen. Gerade wenn die infizierte Datei eher selten genutzt wird ist sie eine gute Basis für die Suche eben dieser Datei in den Logdateien.

Oft muss man ein wenig Kreativität mitbringen, um den tatsächlichen Angriffsweg zu finden. Aber es lohnt sich – denn wenn wir den Angriffsweg nicht abdichten, ist der Angreifer bald wieder drin. Und das will niemand.

Es kommt vor, dass man diesen Schritt nicht erfolgreich abschließen kann. Dies ist besonders häufig der Fall, wenn man Schritt 1 nicht beachtet hat. Dann muss man besonders viel Wert auf Schritt 8 legen.

Schritt 5: Alles neu hochladen

Dein System ist nicht mehr vertrauenswürdig. Lade also alles ausser der wp-config.php und dem Upload-Ordner neu hoch. Die neu hochgeladenen Dateien nimmst du selbstverständlich nicht aus einem Backup, sondern original von der Quelle wordpress.org bzw. der Seite, wo du das Plugin / Theme gekauft hast. Wenn du das nicht machst, lädst du dir ggf. einen Virus aus einem Backup wieder mit hoch und all die Arbeit war umsonst. Bedenke auch, dass wenn Angriffsmethode 1, 3 oder 4 verwendet wurde, nicht nur dein WordPress-Ordner, sondern dein gesamter Webspace infiziert sein dürfte. Liegen dort mehrere WordPress / Shops / CMS, darfst du diese also alle neu hochladen.

Durchsuche zudem den Upload-Ordner nach Dateien, die darin nichts zu suchen haben und bereinige ggf. auch die wp-config.php. Denke auch dran, die .htaccess neu hochzuladen / zu bereinigen / neu generieren zu lassen.

Wenn du schon dabei bist, kannst du übrigens auch bei jedem Theme und jedem Plugin noch einmal ganz genau überlegen, wieso du das überhaupt nutzt. Je weniger Plugins und Themes du einsetzt, desto weniger Angriffsfläche bietest du – also reduziere beides auf das absolute Minimum.

Schritt 6: ändere alle Passwörter

Der Angreifer hat vermutlich jedes verwendete Passwort abfangen können. Ob er das wirklich gemacht hat weisst du nicht, aber auf dieses Unwissen kannst du nicht vertauen. Also ändere:

• FTP-Zugangsdaten (alle, falls du mehrere Zugänge hast!)
• MySQL-Zugangdaten
• Logins für WordPress selbst (auch alle!)

Schritt 7: das System abdichten

Dieser Schritt wird gern vergessen. In Schritt 4 hast du herausbekommen, wie der Angreifer reingekommen ist, also tust du nun was dagegen. Angriffsweg 1-3 erfordern oft das dauerhafte Entfernen von Plugins / Themes bzw. ein manuelles patchen der Sicherheitslücke (dafür musst du aber PHP können). Angriffsweg 4 erfordert meist eine Windows-Neuinstallation, da FTP Daten meist über einen lokalen Virus abgegriffen werden (diese sollte ganz am Anfang – also vor Schritt 2 – geschehen). Alternativ werden FTP-Daten auch bei der Übertragung selbst abgegriffen, dagegen hilft die Aktivierung von TLS / SSL (also: FTPS statt FTP).

Wenn man die exakte Sicherheitslücke nicht gefunden hat, so sollte man sich um so mehr Gedanken in dem letzten Schritt 8 machen.

Schritt 8: Sicherheitskonzept überdenken

Dieser sehr wichtige Schritt wird ebenfalls oft vergessen. Sicherheit ist ein Konzept, welches aus mehreren Lagen besteht. Du kannst nicht darauf vertrauen, dass deine Plugins und Themes immer sicher sind – das weißt du nämlich schlicht nicht. Und du kannst auch nicht den meist sehr leeren Versprechen der vielen Sicherheitsplugins trauen – diese greifen eh meist erst dann, wenn alles zu spät ist, und dienen nicht viel mehr als für ein Frühwarnsystem. Verabschiede dich von dem Gedanken, dass Sicherheit etwas ist, wo man ein Häkchen bei „mach WordPress sicher“ anklickt – und alles ist gut.

Basierend auf dem, was du bei Schritt 4 herausgefunden hast, solltest du dir verschiedene Maßnahmen überlegen. Hier eine unvollständige Liste:

• Dateirechte helfen gegen Angriffsweg 1 und partiell gegen 3, aber nicht gegen 2 und 4.
• Die Änderung des Datenbankprefix hilft meist gegen Schritt 2, aber nicht gegen 1, 3 und 4.
• Schutz mit .htaccess und .htpassword hilft zum Beispiel gegen Angriffsweg 3, aber nicht gegen 1, 2 und 4. Dies gilt auch für Zwei-Faktor-Authentifizierung und Plugins, die Angreifer nach einer bestimmten Anzahl von Loginversuchen sperren.
• Ein Virenscanner auf dem Rechner des Admins hilft gegen Angriffsweg 4, aber nicht gegen 1-3.
• Updates helfen gegen alles und sollten immer schnell eingespielt werden, ersetzen aber nicht das Nachdenken über ein Sicherheitskonzept, was greift, wenn die Updates ein Problem nicht behoben haben.

Noch ein paar Kommentare zu weiteren bekannten Sicherheitsvorschlägen:

• Der spezielle Schutz von einzelnen Dateien wie wp-config.php bringt für sich genommen gar nichts. Wenn, dann muss man alle Dateien schützen.
• Das Umbenennen von Pfaden wie wp-admin und wp-content bringt meist ebenfalls nichts, eine durch Angriffsweg 1 installierte Remote Shell interessiert sich nicht für Namen, die geht einfach überall durch, egal, wie die Ordner heißen.
• Unter den zahlreichen angebotenen Ergänzungen für die .htaccess ist ebenfalls viel Mist dabei, das Meiste davon ist bestenfalls wirkungslos und schlimmstenfalls schädlich, nur selten gibt es tatsächlich eine Wirkung.

Fertig!

Wenn du alle Schritte befolgt hast, dürftest du nun ein virenfreies WordPress haben und es auch behalten. Du kannst also Schritt 2 rückgängig machen und deine Seite wieder online stellen – und einen besonders tollen Blogpost schreiben um dich bei deinen Lesern zu entschuldigen.

Denk aber dran: das muss nicht so bleiben. Kümmere dich um dein WordPress. Vergleiche es mit deinem Körper – der will auch immer wieder Aufmerksamkeit und nicht andauernd Junkfood. Ansonsten wird er auch anfällig und bekommt Viren ab. Und ich glaube nicht, dass du es besonders toll findest, wenn dein Körper eine Vireninfektion hat und du im Bett liegst deswegen. Also – tu was dagegen.

Disclaimer: Wortdefinitionen

Wie vielleicht beim Lesen aufgefallen ist, verwende ich hier konsequent das Wort „Virus“. Das ist technisch eigentlich nicht so korrekt. Eigentlich geht es um Angreifer, welche wie auch immer gearteten Schadcode plazieren. Schadcode kann auch ein iFrame oder ein JavaScript als Eintrag in der Datenbank sein. Das wäre schädlicher weil unerwünschter Code, aber sicher kein Virus. Das Wort Virus ist nur derart populär geworden im Zusammenhang mit WordPress, so dass ich es am Ende als ungenaue Vereinheitlichung verwendet habe.

Ausserdem ist vielleicht aufgefallen, dass ich nirgends wo das Wort hacken / Hacker / Hack verwendet habe. Das wäre sicher sinnvoll, weil „hacken“ noch viel häufiger verwendet wird im Zusammenhang mit WordPress. Da sträubt sich bei mir aber schlicht alles gegen. Hacker sind nicht böse. Hacker greifen auch keine Websites zum Eigennutz an. Das, was eure WordPress-Seiten angreift sind Cracker, welche eine Vielzahl an PCs / Servern infiziert haben und dort automatisch Angriffe laufen lassen. Hacker dagegen haben eine Ethik. Hacker sind konstruktiv. Hacker sind am Ende nur verdammt gute Programmierer, die Informationstechnologie gestalten wollen. Hacker würden niemals irgendwelche Wordressinstallationen angreifen. Und: als Mitglied des CCC werde ich auch in zukünftigen Artikeln Hacker und Cracker sauber voneinander trennen. 🙂