Veröffentlicht am

WordPress – Datensicherung

WordPress DatensicherungMeine WordPress Daten sind sicher.

Gut, das kann man glauben.
Oder man geht mit einem Konzept an die Sache heran und weiß es dann.

Gleich vorab: Datensicherung und Datensicherheit sind zwei verschiedene Dinge. Also klar gesagt: Es wird hier um die Datensicherung einer vorhandenen WordPress Installation gehen.

Die wichtigste Erfahrung aus der Praxis: Die Datensicherung selbst ist oft nicht das Problem. Die Probleme fangen da an, wenn es um die Frage geht, welche Datensicherung ist aktuell und wo liegt sie eigentlich? Wo sind die Zugangsdaten vom ftp-Server und wieso liegen da eigentlich nur alte Daten?

Das sind typische Schrecksekunden im Leben eines WordPress Administrators.

Aber fangen wir einmal ganz vorne an: Bei der Planung was bei einer WordPress Installation zu sichern ist.

Was muss eine WordPress Datensicherung beinhalten?

WordPress besteht aus zwei Teilen: Den html, php und css Dateien auf dem Webserver, die für die Darstellung und die Funktionalität sorgen und den eigentlichen Daten in einer MySQL Datenbank. Hinzu kommen dann noch die von den Usern auf den Server hoch geladenen Daten im Verzeichnis „wp-content/uploads“. Für eine vollständige Wiederherstellung einer WordPress Installation brauche ich all diese Bestandteile. Nur einzelnen Teile zu sichern, macht keinen Sinn.

Wir brauchen also ein Werkzug oder Plugin, das uns die Datenbank als sogenannten SQL-Dump sichert, ein Dateiübertragungsprogramm und Speicherplatz wo die Sicherung abgelegt wird. Für das Anlegen der  Datenbank Sicherung reicht dann ein Plugin wie XM-Backup oder BackWPup.

Bis hierher ist es auch egal, ob wir nur Webspace bei einem Hostinganbieter oder einen echten „Root“-Server besitzen. Wer einen kompletten Server im Zugriff hat, der hat natürlich viel mehr Möglichkeiten die Daten zu sichern. Sei es ein cron-Job, der automatisch alle Daten zusammen kopiert und danach die Datenbank sichert oder ein explizites Datensicherungstool eines Drittherstellers.

Auf jeden Fall kommt an diesem Punkt aber der Ablageort und damit ein Konzept ins Spiel

Je nach gewählter Hostingvariante unterscheiden sich die Vorgehensweisen ganz erheblich. Bei einigen Hostinganbietern gibt es keinen ausreichenden Platz, wo man den SQL-Dump automatisiert ablegen kann. Oder es sind cron-Jobs einfach nicht erlaubt.
Häufig ist es auch nicht möglich, Daten in einem anderen als dem Webverzeichnis zu sichern.
Bei wieder anderen gibt es nicht einmal eine Trennung zwischen dem ftp-Benutzer und dem Benutzer unter dem der eigentliche Webserver-Prozess läuft.

Es gehört zwingend dazu, Benutzer- und Datensicherungskonzept schon beim Vertragsabschluss mit dem Provider zu berücksichtigen.

Kurzer Einschub zum Thema Datensicherheit:
Die Datensicherung über einen Cloudspeicher wird von einigen PlugIns auch angeboten, hier muss man sich aber die Frage stellen, ob man diesem Anbieter wirklich vertraut. Der Datenbank-Dump enthält auch Zugangsdaten für das Blog. Und eventuell auch die Email-Adressen der registrierten Benutzer. Solche Daten aus dem eigenen Kontrollbereich zu geben, halte ich für grenzwertig.

Das gilt auch schon für die Ablage der Datenbank-Dumps im lokalen Verzeichnis des Webservers. Bei Kenntnis der Dateibenennungs-Konvention ist es durchaus denkbar, diese Daten einfach über den Webserver abzurufen!

Gehen wir einmal davon aus, dass der Provider einen ftp-Zugang und ausreichend Platz bietet, um alles zu sichern und wir daher nicht auf einen Cloudspeicher zurückgreifen müssen.

Meine erste Empfehlung lautet, die Daten nicht in das eigentliche Webserver-Verzeichnis abzulegen, sondern in einen eigens dafür angelegten Ordner mit einer Zugangssperre. Diesen Ordner kann man zum Beispiel über eine „.htaccess“-Datei absichern und so einen unbefugten Abruf verhindern.

Jetzt wird es trotzdem spannend

Wir haben die Daten erfolgreich lokal auf dem Server gesichert. Und nur wir selbst haben Zugriff darauf. Aber was passiert, wenn der gesamte Server ein Problem hat? Einfachster Fall: Ein Festplattendefekt.

Auch hier sollte wieder bei Vertragsabschluss nachgefragt werden, wie der Server physikalisch gegen so etwas abgesichert ist. Gibt es eine Spiegelung der Festplatte? Oder wird der Server vom Anbieter 1:1 in ein Backup gesichert, welches dann automatisiert den letzten wieder herstellt? Und das zuverlässig? Oder mietet man nur ein Stück virtuelle Hard- und Software um deren Sicherung man sich selbst kümmern muss?

Wenn das so sein sollte, ist ein klares Kriterium für mich:
Der direkte Zugriff auf die Datensicherung ist unabdingbar, sonst kann ich mir die Arbeit auch sparen.

Ein schlüssiges Sicherungskonzept sieht so aus:

  • Die Daten werden täglich automatisiert lokal auf dem Server in ein separates Sicherungsverzeichnis gespeichert..
  • Dieses Verzeichnis wird aus dem Rechenzentrum jeden Tag auf ein zweites Laufwerk im Büro oder Zuhause gespiegelt. (rsync ist zum Beispiel unter Linux und MacOS ein kostenlose Möglichkeit Daten per SSL-Tunnel direkt zu synchronisieren.)
  • Die Daten im Büro/Zuhause gehen auf eine im Wochenturnus getauschte USB-Festplatte. (Bewährt hat sich eine Rotation auf vier Medien. Damit komme ich vier Wochen in die Vergangenheit und verliere maximal eine Woche Arbeit.)
  • Bis auf eine sind ein bis drei dieser USB-Festplatten an einem anderen Ort. (Freund, Familie, Bank)

Ein ziemlicher Aufwand für ein simples Blog?

Einerseits ja, denn ich brauche Zeit so etwas einzurichten und auch die entsprechende Hardware. Andererseits spart so ein Konzept unglaublich viel Zeit, wenn ich das Blog nach einem Fehler wieder herstellen möchte.

Mit der obigen Routine decke ich die folgenden Fehler ab:

  • Lokale Sicherung:
    • Hilft bei einem versehentlichen Löschen von Dateien oder der Datenbank.
    • Die Rücksicherung kann aus den lokal vorhandenen Daten sehr schnell erfolgen.
  • Gespiegelte Sicherung auf einem Server im Büro:
    • Bei einem kompletten Serverausfall oder einer Kompromittierung habe ich eine Kopie der Daten im direkten Zugriff im Büro.
    • Im Fall einer Infektion mit Malware kann ich offline im Büro prüfen, welche Dateien betroffen sind und diese bereinigen oder ersetzen ohne Dritte zu gefährden.
  • USB-Festplatte:
    • Bei einem Ausfall des primären Sicherungsziels im Büro existieren noch immer Sicherungen auf einem externen Medium.
    • Bei Benutzung von mehreren externen Laufwerken und der Lagerung bei einem Freund, der Familie oder dem Bankschließfach kann sogar das Haus und der Server gleichzeitig abbrennen und das Blog ist immer noch zu retten.

Kern bei allem ist eine realistische Risikoabschätzung und die Bewertung wie wichtig einem das eigene Blog ist. Wer auch nur ein wenig an den geschriebenen Artikeln hängt, sollte sich Gedanken zum Thema Datensicherung machen.

Es muss aber klar sein, dass dieses Datensicherungskonzept nur funktioniert, wenn es regelmäßig und mit Konsequenz umgesetzt wird, Sonst kommt nämlich irgendwann der Punkt, dass nicht mehr klar ist, wo die aktuellen Daten liegen.

Veröffentlicht am

WordPress – Safety first!

WordPressWordPress wird als Content Management System (CMS) immer beliebter. Es kann ohne weitreichende technische Kenntnisse aufgesetzt und betrieben werden.

Das sollte auch so sein, denn warum sollte sich ein Autor mit der Technik herumschlagen?

Es gibt aber in der Planungs- und Installationsphase einige Dinge zu beachten, damit das neu aufgesetzte Blog nicht binnen kürzester Zeit zur „Malware-Schleuder“ wird.

Fangen wir da an, wo es eigentlich schon zu spät ist.

Eigentlich sollte die Installation damit starten, dass man sich Gedanken um die Sicherheit des Blogs macht. Das bedeutet aber den direkten Einstieg in die Themen „Dateirechte“, „Datenbankverwaltung“ und „Fehlerlog“. Ein erster Beitrag dazu findet sich an anderer Stelle hier im Blog.

Die meisten Blogbetreiber machen sich nach dem Aufsetzen des Blogs aber erfahrungsgemäß erst einmal Gedanken um das Design der Website. Das verwundert nicht, denn es wird ja um Inhalte und deren Wahrnehmung gehen.

Ich setze daher erst einmal an diesem Punkt an. Denn auch an dieser Stelle gibt es einige Möglichkeiten ein Mehr an Sicherheit zu bekommen.

Daher stelle ich hier ein paar Plugins vor, die hierbei einen guten Dienst verrichten und sofort nach der Grundinstallation hinzugefügt werden sollten.

 

Simple Login Lockdown

Dieses Plugin sorgt dafür, dass nach einer zu definierenden Anzahl fehlgeschlagener Login-Versuche der Zugang zur Administrationsoberfläche für die betreffende IP gesperrt wird. Keine Angst, nicht für immer, sondern nur für eine bestimmte Zeit. Angreifer warten nicht, ob nicht sie in einer Stunde erneut versuchen können, sondern ziehen weiter. Zeit ist Geld.

Antispam Bee

Die fleißige Biene gegen SPAM. Seit es Email und Blog-Kommentare gibt, gibt es auch SPAM. Also unerwünschte Zusendungen oder Einträge unter Blogbeiträgen. Zumindest im Bereich der WordPress Installationen gibt es dieses Plugin, das eine Menge SPAM abfängt, ohne das man sich als Autor damit herum plagen muss.
Passend dazu gibt es noch einen „Blacklist Updater“, mit dem eine automatische Liste von Spammern für Antispam Bee abonniert werden kann.

Stop Spammers Registration

Eine schöne Ergänzung zur kleinen Biene. Dieses Plugin verhindert, dass sich jedermann/jederfrau/jederbot als Benutzer an der Seite anmelden kann. In den Basiseinstellungen von WordPress kann man sich nach Eingabe seiner Mail nämlich ohne viel Aufwand registrieren lassen und kann dann nahezu automatisch Kommentare mit SPAM einstellen.

WP Author Slug

Eine oft gesehene Angriffsmethode sind „Brute-Force“ Angriffe, bei denen einfach willkürliche Loginname/Passwort Kombinationen benutzt werden. Da es bei WordPress in der Standardinstallation der Loginname dem Autorennamen entspricht, ersetzt dieses Plugin den sichtbaren Namen.

XM-Backup

Wie der Name schon sagt, macht dieses Plugin nichts anderes, als Backups. Und zwar von der Datenbank und den Inhalten. Wohin, kann man sich aussuchen. Für mich hat sich bewährt, die Daten auf dem lokalen Host in einem eigens dafür vorgesehenen Verzeichnis per ftp abzulegen. Dieses Verzeichnis wird dann nachts über eine VPN-Verbindung auf einen lokalen Server im Büro kopiert. Damit existiert neben dem lokalen Backup auf dem Webserver auch noch ein weiteres im direkten Zugriff. Sehr nützlich um eine saubere Neuinstallation vorzunehmen, falls der Server doch einmal kompromittiert ist.

 

Mit diesen fünf Plugins sind schon einmal ein paar Angriffsmöglichkeiten entschärft.

Das ist aber noch längst nicht alles, was getan werden sollte.

Ein wichtiger Punkt ist immer auch die technische Absicherung einer WordPress-Installation. Hierzu gehört zum Beispiel die Absicherung des Administrationsbereiches per .htaccess-Datei. Oder eben die Prüfung der Dateirechte im System. Sobald jeder von außen etwas hochladen kann, wird das ein echtes Risiko.

Ebenso sollte es heute selbstverständlich sein, den Zugang zum Adminstrationsbereich mit einem SSL-Zertifikat abzusichern, damit ein Lauscher an der Leitung keine Login-Daten abfangen kann.

Hier wird es dann aber sehr schnell technisch. Zu technisch für die meisten Betreiber.

Sprechen Sie mich an, ich prüfe ihr WordPress-System und gebe Tipps zur sinnvollen Absicherung.

 

Veröffentlicht am

WordPress und der Admin

20140729-_IMG0028Ich lese seit einer ganzen Weile bei Facebook in einer Gruppe mit, bei der es um WordPress und SEO geht. Bei der Lektüre erstaunt mich immer wieder, wie viele WordPress-Installationen im Internet aktiv sind, ohne dass deren Administratoren sich um grundlegende Dinge der IT-Sicherheit Gedanken machen.

Leider hat sich in der Szene nämlich ein Denken breit gemacht, das es zu hinterfragen gilt.

Sicherheitsfunktionen werden im WordPress Bereich oft über einfach zu installierende Plugins realisiert, die aus Sicht des (Unix-/Linux) Serveradmins eigentlich schon auf einer Ebene weit unter WordPress abzufangen wären. Und das vielfach auch noch ohne jedes Verständnis, was eigentlich dahinter steckt. Für mich ist das manchmal, als wenn jemand auf Basis seiner Erfahrung aus Lego-Technik-Bausätzen anfängt Sportwagen in Serie zu produzieren.

Der erste Dankanstoß: Warum soll sich ein http-Dienst um Dateirechte kümmern?

Das kann er auf einem vernünftig aufgesetzten System ja nicht einmal. Der httpd läuft aus Sicherheitsgründen gar nicht als root und hat im Normalfall nicht einmal das Recht, das eigene Installationsverzeichnis zu verlassen. Wer seine Installation per ftp-Client oder manuell rekursiv auf 777 (rwxrwxrwx) setzt, nur damit alles läuft, hat einfach den falschen Ansatz gewählt.

Eine .htaccess mit Zugriffssperren macht auch wenig Sinn, wenn diese die falschen Rechte hat. Gleiches gilt für die htpasswd. Also nach Möglichkeit die Zugangsbeschränkungen direkt in die Apache-Konfiguration. Da kommt so leicht niemand hin.

Der zweite Denkanstoß: Der eigentliche Server.

Die Krux: Ganz viele Betreiber entscheiden sich aus Kostengründen für einen vServer. Die kann man in der Regel mit so einem schönen grafischen Werkzeug konfigurieren. Außerdem maximiert diese Wahl ja den eigenen Rohgewinn.

Wie oft habe ich schon verzweifelte Hilferufe gelesen, wenn dann doch ein Server kompromittiert wurde. Konfigurationstools haben meist alle Rechte ins System. Und wie viele andere Installationen noch auf der gleichen Hardware laufen ist bei so einer Wahl meist auch nicht so ganz klar. Wenn bei einem was schief läuft, nimmt es oft andere Installationen mit.

Der eigentliche Denkanstoß muss also sein: Hört auf zu basteln und lasst Spezialisten ran!

Das gilt nicht nur für Hard- und Software! Mir ist bei alledem klar, dass nicht jeder WordPress-Admin auch ein Unix-Spezialist ist. Genau deswegen sollte zumindest jeder Webserverbetrieber einen echten Systemadmin kennen und den in die Installation einbinden und regelmäßig die Logs checken lassen.

Bleiben wir im Bild: Das Auto. Die Funktionen gibt der Hersteller (Systemadmin) vor, schon das Design wird zugekauft (Webdesigner). Auch die Sicherheitseinrichtungen wie Bremsen oder ABS werden in der Regel zugekauft so wie sie am besten passen. So etwas kommt nicht vom Hersteller selbst. Das wird exakt auf das jeweilige Modell abgestimmt oder nach Vorgabe passend gemacht (Systemadmin).

Der Designer wird in der Regel nicht wissen wissen wie die Bremse oder ABS und ESP funktioniert. Es gibt nämlich Spezialisten, die sich damit auskennen. Und die nimmt man mit in so ein Projekt.

Dieser Ansatz sollte sich beim Betrieb von Servern im Netz auch etwas mehr herumsprechen.
Ein Webdesigner ist ein Webdesigner ist ein Webdesigner. Und eben KEIN Server-Admin!