KategorieWordPress

Wie kann ich eine WordPress-Installation möglichst schnell und elegant umziehen?

Neben der „klassischen“ Methode (Dateien einzeln per FTP herunterladen, DB-Backup per PHPMyAdmin erstellen) gibt es auch noch den etwas eleganteren Umweg über die Kommandozeile.

Oftmals hat man jedoch in einfacheren Hostingpaketen keinen Zugriff per Telnet oder SSH. Allerdings lassen sich fast immer trotzdem Systembefehle absetzen.

Diesen Umstand kann man sich für eine schnelle Erstellung von Backups von Code und DB zu nutze machen.

Backup DB:
system("mysqldump --opt -Q -h DB-ALT-HOST -u DB-ALT-USER -p DB-ALT-NAME --password=\"DB-ALT-PASSWORT\" > ./dbdump.sql",$ret);

Backup Code:
system("tar -zcf ./backup.tar.gz ./*",$ret);

Anschließend werden die beiden erzeugten Dateien per (S)FTP heruntergeladen und auf den neuen Server hochgeladen.

DB einspielen:
system("mysql -h DB-NEU-HOST -u DB-NEU-USER --password=\"DB-NEU-PASSWORT\" DB-NEU-NAME < ./dbdump.sql");

Code entpacken:
system("tar -xvzf ./backup.tar.gz ",$ret);

Anschließend müssen in der Datei "wp-config.php" noch die neuen DB-Daten eingetragen werden.

Hinter den DB-Daten müssen dann noch die beiden Zeilen für die neue Domain eingetragen werden:
define('WP_SITEURL', 'http://www.neue-adresse.de');
define('WP_HOME', 'http://www.neue-adresse.de');

Weiterhin sollte noch folgende Zeile eigefügt werden:
define('RELOCATE', true);

Anschließend muss die Login-Seite aufgerufen werden:
http://www.neue-adresse.de/wp-login.php

Diese Zeile wird noch vor dem Ausfüllen des Login-Formulars wieder entfernt.

WordPress per PHP direkt von wordpress.org als Zip-Datei auf Server herunterladen und entpacken

Um Prototypen für Kunden zu bauen oder auch für eigene Bastelprojekte muss ich immer mal wieder WordPress neu aufsetzen.

Bei vielen Hostern geht das heute auch als App oder Service relativ vollautomatisch, aber oftmals hat man dann nicht volle Schreibrechte in den WordPress-Verzeichnissen. Also installiere ich lieber selbst.

Da das Herunterladen auf den eigenen Rechner, das lokale Entpacken der Zip-Datei und der anschließende Upload der Daten relativ unspannend und zumindest im FTP-Transfer auch zeitaufwändig ist, lässt sich dieser Vorgang mit einem kleinen Skript weitestgehend automatisieren.

  1. aktuelle deutsche Version von WordPress als Zip-Datei mit cURL direkt auf den Server ziehen
  2. Zip-Datei entpacken
  3. Verzeichnisse und Dateien aus dem Unterordner „wordpress“ auf die aktuelle Verzeichnisebene verschieben
  4. WordPress-Installation anstoßen

Als Skript sieht das dann so aus:

Noch ein paar Worte zur Erläuterung:

  • Die Klasse ZipArchive sollte ab PHP 5.2 zur Verfügung stehen.
  • Das exec-Kommando kann bei anderen Hostern anders heißen, bspw. system etc.

 

Wie kann ich ein php-basiertes Content-Management-System (bspw. WordPress, Joomla, Typo3 etc.) nach einem Hackerangriff von Malware befreien?

Nach einem Hackerangriff und entsprechendem Malware-Befall ist guter Rat meist teuer. Oftmals wird der eigene Webauftritt durch den Provider gesperrt, so dass man nicht irgendein Plugin installieren kann, um die Probleme zu beheben.

Es bleibt nur die gute alte Handarbeit, falls es nicht ein garantiert Malware-freies Backup gibt. Und auch dieses Backup ist nur die halbe Miete, da der Angreifer diese Version ja offensichtlich problemlos infiltrieren konnte.

Variante A – Ihr habt ein aktuelles, garantiert sauberes Backup

Wenn Ihr diesbezüglich sicher seid, dann löscht den gesamten Webauftritt per FTP und leert die zugehörigen DB-Tabellen bspw. per PHPMyAdmin.

Anschließend kopiert Ihr das saubere Backup per FTP auf den Server, legt per .htaccess einen Verzeichnisschutz auf den gesamten Auftritt und spielt dann das DB-Backup ein.

Ihr habe jetzt wieder eine laufende Installtion Eures CMS, auch wenn diese von außen nicht für Andere zugänglich ist. Installiert nunmehr sämtliche Updates für Euer CMS, die Plugins, Themes / Templates etc.

Härtet Eurer CMS durch die Installation eines entsprechenden Plugins (bei WordPress bspw. Sucuri Scan). Überlegt Euch weiterhin, ob Ihr Kommentarfunktionen benötigt und insbesondere, ob Eure Besucher Dateien uploaden müssen. Falls nicht, deaktiviert diese Funktionen und schützt entsprechende Verzeichnisse durch eine .htaccess.

Ändert sämtliche Zugangsdaten – auch das FTP-Passwort!

Theoretisch müsstet Ihr jetzt noch die Logfiles durchsuchen und schauen, ob Ihr nachvollziehen könnt, wie der Angriff zustande kam. Oftmals endet diese Suche – nicht zuletzt mangels hinreichendem Hintergrundwissen – ergebnislos. Ihr könnt aber vorsichtshalber trotzdem Euren Provider fragen, ob er in den Logfiles Hinweise auf den Angriff gefunden hat.

Entfernt nun den Verzeichnisschutz für Euren Auftritt und beobachtet für die nächsten Tage und Wochen Euren Auftritt sehr aufmerksam. Regelmäßige Backups und Updates verstehen sich von selbst.

Variante B – Ihr habe kein sauberes Backup und Ihr traut Euch auch nicht, einfach eine frische Version des CMS einzuspielen

Trauriger Weise dürfte das der Normalzustand sein. Da Lamentieren nicht hilft, ist es dann an der Zeit, in die virtuellen Hände zu spucken.

Achtet darauf, dass Euer Virenscanner aktuell und eingeschaltet ist. Zieht dann per FTP ein vollständiges Backup Eures CMS. Wenn das Backup vollständig ist, lasst Ihr mindestens einen Virenscanner und einen Malware-Checker (bspw. Malwarebytes Anti-Malware) über den Backup-Ordner laufen. Etwaige Funde behebt Ihr sowohl im Backup als auch direkt auf dem Server.

Nehmt jetzt ein Tool, welches Dateien inhaltlich durchsuchen kann (bspw. Agent Ransack) und lasst alle Dateien des Backups nach

durchsuchen. Insbesondere Funde von „eval(base64_encode(“ und „eval(gzinflate(“ guckt Ihr Euch genauer an. Wenn diese von kryptischen Zeichenfolgen gefolgt werden, handelt es sich mit großer Wahrscheinlichkeit um Malware. Aber auch alle anderen Funde solltet Ihr gewissenhaft prüfen. Behebt die jeweiligen Befälle jedoch nur auf dem Server, so dass Ihr im Worst Case ein Backup habt.

Wenn Ihr alle Dateien gesäubert habt, werft auch noch einen Blick auf die Datenbank und durchsucht diese komplett nach „%<iframe%“, und „%<noscript%“. Löscht verdächtige Inhalte, nachdem Ihr ein DB-Backup erstellt habt.

Legt per .htaccess einen Verzeichnisschutz auf den gesamten Auftritt und bittet Euren Provider ggfls., den Zugriff auf die Seite wieder zu erlauben..

Ihr habe jetzt wieder eine laufende Installtion Eures CMS, auch wenn diese von außen nicht für Andere zugänglich ist. Installiert nunmehr sämtliche Updates für Euer CMS, die Plugins, Themes / Templates etc.

Härtet Eurer CMS durch die Installation eines entsprechenden Plugins (bei WordPress bspw. Sucuri Scan). Überlegt Euch weiterhin, ob Ihr Kommentarfunktionen benötigt und insbesondere, ob Eure Besucher Dateien uploaden müssen. Falls nicht, deaktiviert diese Funktionen und schützt entsprechende Verzeichnisse durch eine .htaccess.

Ändert sämtliche Zugangsdaten – auch das FTP-Passwort!

Theoretisch müsstet Ihr jetzt noch die Logfiles durchsuchen und schauen, ob Ihr nachvollziehen könnt, wie der Angriff zustande kam. Oftmals endet diese Suche – nicht zuletzt mangels hinreichendem Hintergrundwissen – ergebnislos. Ihr könnt aber vorsichtshalber trotzdem Euren Provider fragen, ob er in den Logfiles Hinweise auf den Angriff gefunden hat.

Entfernt nun den Verzeichnisschutz für Euren Auftritt und beobachtet für die nächsten Tage und Wochen Euren Auftritt sehr aufmerksam. Regelmäßige Backups und Updates verstehen sich von selbst.

 

Das WordPress-Plugin Sucuri zeigt nach dem Einschalten zusätzlicher Scanner auf der Settings-Seite nur noch einen Serverfehler 500

Ja nach Konfiguration Eures Webservers laufen nicht alle Scanner von Sucuri problemlos durch. Das wäre nicht so tragisch, wenn man die jeweilige Scan-Engine einfach wieder über die Settings abschalten könnte.

Leider funktioniert das nicht immer, denn bereits beim Aufruf der Settings bekommt man einen 500er geworfen.

Um trotzdem an die Einstellungen über Settings zu gelangen, reicht es, an die URL „&no_scan=1“ (ohne Anführungszeichen) anzuhängen. Schon gibt es wieder Zugriff auf die Settings.

© 2017 StableWeb / CMS-EDV

Theme von Anders Norén↑ ↑