Ist eine WordPress-Installation nach einem erfolgreichen Angriff kompromittiert, gibt es zwei Möglichkeiten – entweder man löscht alles und fängt von vorne an, importiert später die Datenbank und die eigenen Dateien und hat (hoffentlich) wieder eine saubere Installation. Die andere Möglichkeit ist an der aktiven Installation zu arbeiten, nach Backdoors und Shells zu suchen. In meinen Augen sind beide Methoden gleich gut und enden recht schnell im gleichen Dilemma – dazu aber später mehr.
Wichtig: Diese Anleitung richtet sich an technisch versierte Personen, die entsprechende Zugänge (SSH) zu ihrem Webspace haben und bei denen der Standardfall vorliegt – eben der, das ein altes Plugin bzw. eine Sicherheitslücke in einem Bestandteil der WP Installation ausgenutzt wurde, um Zugang zum Webspace zu bekommen. Die Fälle, wo der Webmaster selbst mit einem Trojaner infiziert ist und so immer wieder seine Daten verliert, sind seltene kompliziertere Fälle bei denen ganz anderes Vorgehen nötig ist.
Zur schnellen Übersicht:
- Einleitung & Gründe für erfolgreiche Angriffe
- Seite nach außen sperren
- Wichtige Zugangsdaten ändern (SSH, FTP, Webhoster)
- Backups von Dateien und Datenbank machen
- Nicht relevante Dateien und Ordner löschen
- Updates von Core, Theme und Plugins via SSH machen
- Analyse von Hand: wp-content-Ordner, languages-Ordner, eigene Ordner, …
- Datenbank durchsuchen, Adminpasswörter ändern
- Thema: Plugins und Themes, die Einbinden von PHP, JS oder CSS erlauben
- Thema: Sicherheitslücken
- Thema: Prävention
- Thema: Überwachung
Einleitung & Gründe für erfolgreiche Angriffe
WordPress hat einen atemberaubend hohen Anteil im Netz. Rund 25% der Websites im Internet basieren auf WordPress – wer also in WordPress oder einem bekannten Plugin eine Sicherheitslücke findet, der kann sich zu einer großen Anzahl an Websites Zugriff verschaffen und von dort aus dann weitere Seiten infizieren, Malware an die Besucher verteilen, Warez speichern, Blackhat SEO in Form von schlechtem Linkbuilding betreiben oder einfach nur bei großen Websites Daten stehlen. Am Ende ist es in irgendeiner Form die Bereicherung und Geld als Grund für allerhand Angriffe im Netz.
Ist so ein Angriff erfolgreich, hat man mit einem Schlag diverse Probleme – jemand hat Zugang zum eigenen Server, die eigenen Daten wurden entwendet, Malware verteilt sich oder der Server dient als Spamverteiler. Wer hier schnell handelt, kann sich viel Ärger ersparen.
Im Folgenden findest du eine Anleitung, wie man recht effizient solche Seiten sauber bekommt, um weiter dran arbeiten zu können. Ich empfehle den Artikel bis zum Ende zu lesen – oft reicht einfach nur das Ersetzen befallener Dateien durch die Originaldateien nicht aus – spätestens hier muss man sich auskennen oder einen Profi beauftragen!
Seite nach außen sperren
Im ersten Schritt solltest du die befallene Seite – oder den Server – nach außen abschotten. Es kann auch sein, dass dein Webhoster das schon automatisch aus Sicherheitsgründen macht. Dann können Backdoors nämlich nicht aktiv verwendet werden und während du die Seite/den Server sauber machst, kann nichts neues dazu kommen. Anfänger machen den Fehler, dass sie Seiten gerne online lassen, anfangen Shells und Backdoors zu entfernen und merken, dass sie 10 davon entfernt haben, parallel aber 2-3 neue dazu gekommen sind. Malware in Form von Backdoors neigt dazu sich zu vervielfältigen.
Die einfachste Variante eine Seite nach außen hin abzuschotten ist es der .htaccess einfach ein „deny from all“ hinzuzufügen. Oder einfach eine simple htaccess-Loginabfrage davor zu schalten, die nur du kennst. Je nach Server/Webhosting-Anbieter gibt es natürlich weitere Möglichkeiten – einfach nachfragen!
Deine Seite sollte nun NUR für dich erreichbar sein – wie ich oben schrieb gehe ich davon aus , dass dein Webhoster SSH Zugang zu deinem Webspace erlaubt. Das vereinfacht dein Leben ungemein. Du kannst damit quasi direkt auf dem Server arbeiten, musst die Seite also nicht herunterladen. Die Alternative ist natürlich die Seite entweder herunterzuladen und lokal in einer virtuellen Umgebung (nie auf deinem PC selbst!) zu installieren. Hierzu nutze ich z.B. virtualbox.org.
Wichtige Zugangsdaten ändern (SSH, FTP, Webhoster)
Deine Seite ist jetzt für niemanden erreichbar. Jetzt änderst du alle wichtigen Zugangsdaten – das bedeutet: FTP-Zugangsdaten, SSH-Zugangsdaten, Datenbank-Zugangsdaten und Schlussendlich die Zugangsdaten zu deinem Webhoster. Das meiste davon wird nicht nötig sein, weil wir davon ausgehen, dass nur deine Seite gehackt wurde und nicht unbedingt du oder dein Hoster, so dass der Angreifer normalerweise nur in den Besitz der Zugangsdaten für die Datenbank gekommen ist. Wer die FTP-Daten in der wp-config.php gespeichert hat – was nicht zu empfehlen ist – der sollte nat. dann auch diese Daten ändern.
Um weiter zu arbeiten solltest du via FTP oder SSH zumindest die neuen Datenbank-Daten in der wp-config.php hinterlassen. Da die Seite nach außen nicht erreichbar ist, brauchst du keine Sorgen haben, dass jemand diese Daten auslesen kann.
Backups von Dateien und Datenbank machen
Bevor du irgendetwas an der Seite veränderst oder „sauber“ machst, empfiehlt es sich ein komplettes Backup deiner Seite zu machen. Da ich davon ausgehe, du SSH Zugang hast, kannst du das in zwei Befehlen erledigen. Einloggen und in das Verzeichnis wechseln, wo die Installation liegt:
Datenbank-Backup erstellen:
mysqldump -h localhost -u USERNAME -p DATENBANKNAME > sql-dump-ds.IRGENDWASZUFÄLLIGES.sql
Das Passwort zur Datenbank eingeben, und dann wird ein Datenbank-Backup erstellt. Du musst natürlich die Angaben anpassen.
Alle Dateien (inklusive des DB Backups) per zip zusammenfassen:
zip -r backupn0w.zip . --exclude *.zip --exclude *.tmp --exclude *.bck --exclude *.tar --exclude */cache/*
Dieser Befehl komprimiert alle Dateien im aktuellen Ordner – unter Ausschluss bestimmter Dateien. Die backupn0w.zip kannst du dann entweder intern verschieben oder per sftp/ftp herunterladen. Damit hast du ein komplettes Backup deiner Seite. Einfach und effizient gelöst.
Nicht relevante Dateien und Ordner löschen
Bevor du an die eigentliche Säuberung gehst, lohnt es sich alte Dateien, die du nicht brauchst zu löschen – das heißt so etwas wie cache-Ordner, vielleicht private Ordner und Dateien – eben alles, was nicht zu WordPress gehört. Der Sinn dahinter ist zum einen die Menge an zu analysierenden Dateien und Ordnern zu minimieren und zum anderen potentielle Versteckorte für Backdoors und Shells direkt zu löschen. Malware ist da recht gut im Verstecken! Hab das also im Hinterkopf.
Der Schritt kann natürlich übersprungen werden, wenn man meint, es gibt nichts bzw. das ist nicht nötig
Updates von Core, Theme und Plugins via SSH machen
WordPress besteht im Grunde aus den Kerndateien (Core), Themes und Plugins. Shells verstecken sich in aller Regel irgendwo in den Ordnern innerhalb deiner Installation. Damit du nicht jedes Theme und jede Datei von Hand absuchen musst – empfiehlt sich die Verwendung von wp-cli. Mit wp-cli kannst du diverse Aktionen an deiner Installation über die Konsole (SSH) durchführen. Das beginnt beim Installieren von Plugins oder Themes und endet beim Ersetzen von Strings in der Datenbank. Du kannst mit wp-cli quasi innerhalb von Sekunden ein ganzes WP samt Wunschplugins, Content und Theme installieren. wp-cli kann aber noch mehr. Einige wichtige Befehle stelle ich dir vor und zeige, wie du damit umgehst:
WP Core auf Veränderungen untersuchen
php wp-cli.phar core verify-checksums
Dieser Befehl erlaubt es die Prüfsummen jeder Datei des WP Kerns zu berechnen. So erkennst du schnell, ob der WP Core von einer Dritten Partei modifiziert wurde. Das ist im Fall von Malware der Fall.
Hier ist offensichtlich die erste Datei kein Bestandteil von WordPress und gehört da nicht hin. Der Blick in so eine Datei verrät, ob es eine Shell ist oder nicht. Das gleiche gilt für die wp-config.bak.php – könnte eine Shell sein – oder eben nur ein Backup der wp-config.php. Ich lasse diesen Schritt meist direkt aus – mich interessiert nicht, was im Core alles ist. Ich lösche die Core-Dateien direkt und ersetze sie mit einer frischen Installation. Damit wären wir beim nächsten Befehl:
Für Plugins gibt es einen analogen Befehl:
php wp-cli.phar plugin verify-checksums
Core Dateien mit einem Befehl ersetzen
php wp-cli.phar core update --version=5.0.3 --force
Der Befehl ist recht einfach erklärt – der aktuelle Kern wird gelöscht und durch den Kern von WordPress 5.0.3 ersetzt. WENN dort irgendwo Malware war, ist sie jetzt weg.
Das gleiche machen wir jetzt für die Plugins und das Theme:
Plugins & Theme ersetzen mit wp-cli
php wp-cli.phar plugin install $(php wp-cli.phar plugin list --field=name) --force
Dieser Befehl löscht jedes Plugin und installiert es anschließend wieder. Auch hier – wenn sich in irgendeinem Ordner eine Shell oder ein Backdoor versteckt hat, ist er jetzt weg. Hierbei wird direkt auf die aktuelle Version des Plugins aktualisiert. Am Ende gibt es einen kurzen Bericht, den man sich GENAU anschauen muss! D as Ergebnis sieht in etwa so aus:
Was sagt uns das? Von 17 Plugins konnten 15 erfolgreich entfernt werden und durch die Originalversion ersetzt werden. Wir können annehmen, dass diese Plugins jetzt sauber sind. Dort dürfte sich nichts mehr verstecken!
15 von 17 bedeutet aber, dass es 2 Plugins gibt, die nicht ersetzt werden konnten. Das kann mehrere Gründe haben. Es können Eigenentwicklungen sein oder Plugins die aus Sicherheitsgründen aus dem offiziellen Repo entfernt worden sind. Oder es sind Plugins, die man aus Drittquellen bezieht (envato.com, …) – und dort hat man vergessen die Token einzutragen, der Updates ermöglichen würde. Im Fall der externen Pluginanbieter kann man entweder die Tokens nachtragen und oft so direkt Updates via wp-cli machen oder man entfernt das Plugin, lädt es wieder von der Originalquelle herunter, um es dann wieder hochzuladen.
Hier kommen wir zum ersten Dilemma. Das sind Plugins bzw. Ordner in denen sich Malware verstecken kann. Diese müssen wir von Hand prüfen. Das Thema „Von Hand prüfen“ ist komplex, erfordert Wissen im Bereich PHP und vor allem IT Sicherheit. Ich kenne nur wenig Menschen, die wirklich eine Sicherheitslücke erkennen würden. Die einfache Lösung ist einfach so ein Plugin zu löschen, das geht aber nicht immer. In dem Sinne: aufpassen!
Der Befehl für Plugins ist analog auch für Themes verfügbar:
php wp-cli.phar theme install $(php wp-cli.phar theme list --field=name) --force
Auch hier gilt – wer eine Eigenentwicklung einsetzt, wird sie von Hand prüfen müssen! Ich empfehle außerdem Plugins und Themes die nicht aktiv verwendet werden, nicht nur zu deaktivieren sondern wirklich vom Server zu löschen. Es gibt damit weniger Angriffsvektoren und zum anderen weniger Möglichkeiten sich zu verstecken.
Es gibt Serveranbieter, die haben WP Cli bereits integriert. Bei anderen muss man es erst herunterladen. Außerdem muss man schauen mit welcher Datei php-cli ausgeführt werden kann. Bei mir ist es „php“. Im Fall von z.B. All Inkl ist es so etwas wie: php7.0.2-cli. Wenn ihr nicht genau wisst, fragt beim Anbieter nach und schildert ihm, was ihr vorhabt – nämlich WP CLI verwenden.
Der aktuelle Stand
Wir haben jetzt einen Großteil der Seite durch saubere Versionen von Core, Themes und Plugins ersetzt. Das WordPress System hat allerdings auch Ordner, die man IMMER von Hand prüfen muss. Eine kurze und sicherlich unvollständige Liste findet man im Folgenden:
- allgemein plugin-spezifische Ordner innerhalb von wp-content (cache/, ewww/, nfwlogs/, pomo-editor/, …)
- Upload-Ordner: wp-content/uploads
- Multi Site Plugins: wp-content/mu-plugins
- Temporärer Upgrade Ordner: wp-content/upgrades
- Sprachdateien: wp-content/languages
- Hauptordner für Plugins und Themes
- Child Themes
Dazu kommt die Datenbank, die wir uns noch gar nicht angeschaut haben.
Analyse von Hand: wp-content-Ordner, languages-Ordner, eigene Ordner, …
In jedem dieser Ordner können sich Backdoors befinden. Im Fall von wp-content/languages muss es im übrigen nicht nur eine php-Datei sein. Man kann in Sprachdateien Backdoors verstecken, die man nicht mal eben einfach so findet. Das ist ein klassischer Anfängerfehler von Menschen, die versuchen im Bereich „WordPress gehackt“ etwas Geld dazu zuverdienen. Zu dem Thema habe ich mich in meinem Artikel „ Schützt WordFence meine WordPress-Seite so gut, wie alle behaupten?“ bereits geäußert. Dort findest du z.B. eine .mo-Datei, die du hochladen und als Sprache einbinden kannst. Bekannte Pseudoschutzplugins, wie etwa WordFence, werden diesen Backdoor nicht erkennen – und die meisten Dienstleister ebenfalls nicht.
Im Fall von Multi Site Plugins ist es so, dass der oben erwähnte Befehl zum Ersetzen aller Plugins auch auf Multi Site Plugins Auswirkungen hat – entsprechend würde ein valides Plugin auch da ersetzt werden und ggf. nur das alte Zeug voller Malware übrig bleiben. Da muss man also einen Blick drauf haben.
Beim uploads-Ordner ist es so, dass dort allgemein keine PHP-Dateien hingehören. Einige Plugins haben dummerweise angefangen dort PHP-Dateien abzulegen. Da muss man also vorsichtig sein, wenn man dort etwas löscht.
Allgemein lassen sich Shells und Backdoors in solchen Ordner recht leicht finden, am Beispiel des uploads-Ordners:
find wp-content/uploads/ -name "*.ph*" -print
Hier sei der Hinweis erlaubt, dass es neben normalen php-Dateien auch ausführbare Dateien mit Endungen, wie php7 oder pht oder phtml gibt. Allgemein müssen sich Shells aber nicht unbedingt in diesen Dateien verstecken – man kann PHP Code u.a. z.B. in Bilddateien verstecken. Da lohnt sich also der Scan ebenfalls – das ist allerdings nicht trivial, da in vielen solcher Fälle, der Angreifer eine Möglichkeit hat die Bilddatei via PHP einzubinden und so den Code auszuführen – im Endeffekt ist also im System irgendwo eine „Local File Inclusion„.
Trotzdem – du hast an der Stelle meist einen Haufen Plugins und Dateien, die man als Laie schwer bewerten können wird. Das ist der Moment, wo man besagte Datei einfach löscht - nach dem Prinzip sicher ist sicher. Die Alternative ist hier im Ansatz gut beschrieben: Backdoors und Sicherheitslücken per grep finden. Das ist allerdings purer Einstieg in die Materie mit den 10 wichtigsten Befehlen – das ganze ist in Realität noch durchaus komplexer. Man muss wissen, wie Angriffe ablaufen, wissen wie Sicherheitslücken entstehen, wie sie aussehen und wie man sie findet und schließt. Spätestens hier ist es einfach so, dass der Laie und teilweise auch Programmierer passen muss.
Datenbank durchsuchen, Adminpasswörter ändern
Wenn auf Dateiebene alles sauber ist, lohnt der Blick in die Datenbank. Hier muss man zumindest grundlegend den Umgang mit MySQL beherrschen und wissen, wie die Datenbankstruktur von WordPress aufgebaut ist. In der Datenbank kann sich auch allerhand Mist verstecken. Auf die speziellen und sehr seltenen Fälle von serialisierten Backdoors gehe ich hier nicht ein. Viel häufiger hat man den Fall, dass versteckte Administratoren über eine Shell angelegt wurden. Innerhalb von phpMyAdmin (oder dem DB Tool der Wahl) sieht das dann häufig so aus, wenn man sich die wp_users-Tabelle anschaut:
Auffällig ist das Registrierdatum „0000-00-00 00:00:00“ – daran erkennt man recht zuverlässig, hier etwas nicht stimmt. Ein 100%iges Zeichen ist das allerdings nicht. Admin-Accounts, die via XSS angelegt wurden, sehen ganz normal aus. Die einfachste Regel ist hier folgenden: Lösch alle Accounts, die dir nicht bekannt vorkommen – über die wp_usermeta kann man zu jeder user ID rausfinden, welche Rechte sie hat. Auffällig sind die, die das „user level“ 10 haben – das entspricht einem Administrator. Das ist allerdings kein ausreichendes Kriterium – noch genauer ist der prefix_capabilities-Wert:
Was außerdem häufig vorkommt: In der wp_posts – also der Tabelle, wo der Content zu finden ist, werden zusätzliche Einträge hinterlassen, die meist dem Blackhat SEO dienen. Diese kann man einfach löschen. Man muss sie allerdings von Hand durchgehen. Ein gutes Instrument ist da natürlich MySQL und die LIKE %%-Abfrage, um die Suchergebnisse einzugrenzen.
Des Weiteren lohnt die Suche nach „<script“ und den verdächtigen Schmuddelbegriffen – da sieht man dann in der Spalte post_content oft dirket, dass jemand Mist hinterlassen hat. Dieser lässt sich entweder von Hand oder automatisiert entfernen. Der entsprechende MySQL Befehl hierfür wäre REPLACE.
Adminpasswörter ändern – die schnelle Variante
Vergesst nicht das Passwort aller validen Administratoraccounts zu ändern. Ich gebe mir da wenig Mühe und ändere innerhalb der wp_users die Spalte user_pass zufällig ab und zwinge die Personen sich ihr Passwort später selbst wieder zurückzusetzen – natürlich mit dem Hinweis nicht unbedingt das alte Passwort zu verwenden. Im schlechtesten Fall hat der Angreifer dieses Passwort und wird bald wieder vorbeischauen!
Eigentlich sind wir fertig, …
Im Grunde war es das. Die gewählte Installation ist jetzt vermutlich sauber. Vermutlich… das Thema ist komplex und wer etwas falsch macht oder nicht die Erfahrung hat wirklich Backdoors zu finden, wird vor allem, wenn er viele eigene Dateien und Eigenentwicklungen hat, etwas übersehen. Dann war die Arbeit umsonst. Man sollte sich also immer überlegen, ob man so etwas wirklich selbst machen will und kann. Das reine „Sauber machen“ ist ein super schneller Prozess, wenn vor allem SSH zur Verfügung steht.
Die wahren Zeitfresser in solchen Prozessen
Steht kein SSH zur Verfügung muss man wohl oder übel via FTP gehen. Selbst wenn der Server viele parallele Verbindungen erlaubt, dauert es bis so eine Seite heruntergeladen, bereinigt und wieder hochgeladen ist. Wer nicht warten kann, der kann einfach alle Dateien via PHP oder Hosting zippen, die zip-Datei herunterladen, lokal arbeiten. Anschließend wird die nun saubere Instanz wieder in zip verpackt und hochgeladen. Per PHP lässt sie sich dann entpacken. Dafür eignen sich zum Beispiel Bibliotheken, wie unzipper. Vergesst aber nicht vorher alles auf dem Server zu löschen und erst dann die Datei zu entpacken. Ich bin daher allgemein Fan von Hosting-Anbietern, die SSH anbieten. Das vereinfacht alles ungemein.
Ein weiteres Problem sind Updates. Der Grund für erfolgreiche Angriffe sind meist ungepflegte Installationen, die Sicherheitslücken haben. Die muss man schließen, man macht also alle Updates – ob der Kunde will oder nicht. Meist geht alles gut, die Seite wird schneller und sicherer. Es gibt aber Fälle, wo das eben nicht der Fall ist. Plugins harmonieren nicht mehr oder werden nicht weiterentwickelt und sorgen dann für Probleme, um die man sich kümmern muss.
Entsprechend schwer ist eine zeitliche Einschätzung, wie lange das „Sauber machen“ wirklich dauert. Im besten Fall ist man in 30 Minuten fertig, im schlechtesten Fall dauert es Stunden oder Tage. Letzteres vor allem bei großen Seiten mit viel eigenem Code.
Thema: Spezielle Plugins, die Einbinden von PHP, JS oder CSS erlauben
Vor allem die tollen Multi Purpose Themes von Envato erlauben es CSS und JS Code einzubinden. Diese Funktionen werden von Angreifern liebend gern dazu verwendet einfach eigenen Code ins Frontend zu schaufen, der dann bei dem Nutzer ausgeführt wird. Das Schöne an der Methode ist, dass man so etwas nicht direkt sieht, weil man zu aller erst irgendwelche Backdoors, Shells oder Malware-Plugins vermutet. Das gleiche gilt für Plugins – hier gibt es auch diverse, die solche Funktionen anbietet. Der schnelle Blick auf die Inhalte der relevanten Felder im Backend oder besser via MySQL lohnt sich immer.
Hier wird man dann meist Code finden, der den Besuchern falsche Werbung einblendet oder der sie auf irgendwelche Glücksspielseiten im Ausland umleitet.
Thema: Sicherheitslücken
Für mich persönlich gehört neben dem halbautomatisierten Bereinigen einer WordPress Instanz auch das Suchen nach Sicherheitslücken, die trotz aktueller Plugins nach wie vor dort vorhanden sind – beispielsweise weil Plugins verwendet werden, die schon lange nicht gewartet werden, auf die der Kunde aber nicht verzichten mag. Die Bereinigung allgemein bringt euch absolut nichts, wenn es irgendwo in der eigentlich sauberen Installation trotzdem noch die ein oder andere Sicherheitslücke gibt. Das Suchen und Finden von Lücken ist eine Kunst für sich und im Allgemeinen ein zeitaufwendiger Prozess. Ich bin auf u.a. hackerone.com aktiv – dort suche ich aktiv nach Lücken und bekomme so genannte Bug Bounties. Wer zum Beispiel auf twitter.com schafft Code auszuführen, bekommt etwa 20.000 US Dollar.
Viele Anbieter verzichten auf diesen Schritt. Find ich nicht gut – am Ende will der Kunde eine saubere und sichere WordPress Instanz. Wenn das nicht gegeben ist, sorgt das nur für Kundenfrust.
Niemand verlangt hier, dass man 10 Stunden vor 15 WP Plugins sitzt. Aber es lohnt sich sich 1 Stunden zu nehmen und den Quellcode der kleineren installierten ggf. ungepflegten Plugins und des Themes näher anzuschauen. Das ist bei weitem nicht vergleichbar mit einem kompletten Source Code Audit oder Pentest, es erlaubt aber recht schnell dem Kunden zu sagen, ob ein Plugin gut oder schlecht entwickelt wurde. Stupide und einfache Sicherheitslücken findet man dabei meist nebenbei, wenn man ein Auge dafür hat.
Thema: Prävention
Instanz ist sauber und alle Sicherheitslücken geschlossen? Dann geht da auf jeden Fall noch was. Je nach Case und Machbarkeit auf dem Server der Wahl, lohnt es sich Datei- und Nutzerrechte auf dem Server zu implementieren. Vor allem bei Agenturen mit Reseller-Servern sehe ich immer wieder das alle Kunden als ein Nutzer laufen. Wird also eine Seite gehackt, sind alle anderen zwangsläufig ebenfalls penetriert und per se gehackt. Hier können tausende von Euro für die Bereinigung drauf gehen.
Datei- und Nutzerrechte
Entsprechend: Implementiert Nutzer und Dateirechte. Ernesto Ruge hat hierzu einen schönen Artikel. Ein weiterer Vorteil von Dateirechten, wenn richtig gemacht, ist, dass ein erfolgreicher Angreifer auf einen Großteil der Ordner und Dateien nicht schreiben kann. Die Malware kann sich nicht ausbreiten. Das ist extrem viel wert – vor allem im Hinblick darauf, dass die meiste Malware vollautomatisiert stupide verteilt wird.
Deaktiviert stellenweise PHP
Es gibt bei WordPress natürlich immer beschreibbare Ordner (uploads z.B.) – hier ist der einfache Trick genau in diesen Ordnern die Ausführung von PHP zu verbieten. Dazu legt man einfach eine .htaccess in den jeweiligen Ordner. Der Inhalt der .htaccess kann folgendermaßen aussehen:
RemoveHandler .php .php2 .php3 .php4 .php5 .php6 .php7 .pht .phtml
RemoveType .php .php2 .php3 .php4 .php5 .php6 .php7 .pht .phtml
php_flag engine off
Selbst wenn dort jemand einen Backdoor hochlädt, wird er ihn nicht ausführen können. Das verschafft euch die nötige Zeit zu reagieren.
System immer up to date halten
Außerdem: Updates um jeden Preis einspielen! Je schneller, desto besser!
Schützt wichtige Verzeichnisse
Des Weiteren – vor allem wenn ihr der einzige Admin seid: Legt einen htaccess-Schutz mit Login/Passwort in den wp-admin-Ordner. Das ist ein einfacher und wirkungsvoller Schutz vor fremden Zugriff! So eine htaccess kann folgendermaßen aussehen:
AuthType Basic
AuthName "My Protected Area"
AuthUserFile /var/............/httpdocs/.htpasswd
Require valid-user
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
<Files admin-post.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
<Files "\.(css|gif|png|js)$">
Order allow,deny
Allow from all
Satisfy any
</Files>
Thema: Überwachung
Hab ihr ohnehin Zugang via SSH lohnt es sich die Änderungen an Dateien regelmäßig zu beobachten. Hierzu sei der folgenden Befehl empfohlen:
find $1 -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head
Sobald eine Shell geschrieben wird, würde sie oben erscheinen. Des Weiteren gibt es für alle, die z.B. eigene Server betreiben Programme, die diese Aufgabe automatisieren. Ich empfehle an der Stelle außerdem die PHP Firewall „NinjaFirewall (WP Edition)„. Als konkreter Schutz ist dieses WordPress Plugin ganz gut zu gebrauchen. Es schützt euch extrem gut vor einer Vielzahl von Angriffen – auch im Backend. Das ist z.B. bei WordFence nicht der Fall.
Thema: Altes Backup einspielen
Wenn du dir sicher bist, dass du ein Backup hast, das wirklich sauber ist, dann kannst du den gesamten Prozess natürlich abkürzen und einfach ein Backup einspielen, aktualisieren und hoffen, dass alles gut geht. Die Realität sieht aber so aus, dass erfolgreiche Angriffe sich erst nach Monaten bemerkbar machen. Das bedeutet, dass alle älteren Backups bereits infiziert sind. Oft dreht man sich hier also im Kreis und das ist nur selten eine Möglichkeit. Davon abgesehen bedeutet es oft, dass man Daten verliert.
Fazit
Das reine Säubern einer zuvor gehackten WordPress Instanz ist – wenn der Server und die Möglichkeiten stimmen – mit Hilfe spezieller Tools, wie wp-cli, ein Kinderspiel und schnell gemacht. Der Teufel steckt aber bekanntlich im Detail – man kann nicht alles automatisiert und schnell erledigen. Will man auf Nummer sicher gehen, muss man sich grundlegend anschauen, welche Plugins verwendet werden und wie der aktuelle Entwicklungsstand dieser Plugins ist. Prävention und anschließende Überwachung sind ebenfalls wichtige Themen, an denen viele Dienstleister gerne scheitern.
