Schutzmaßnahmen – WordPress absichern Teil2

1. WordPress SicherheitSchutzmaßnahmen

Im ersten Teil der Artikelserie »WordPress absichern« habe ich euch Tipps vorgestellt, die jeder mit wenigen Handgriffen umsetzen kann und das Mindestmaß an Sicherheit für WordPress-Installationen darstellt. Damit ist es möglich die Wahrscheinlichkeit eines erfolgreichen Übergriffs deutlich zu reduzieren – sozusagen eine »erste Hilfe Sofortmaßnahmen« gegen böswillige Angriffe.

Neben diesem Basisschutz existieren weitere Maßnahmen und wissenswerte Tipps für einen sicheren WordPress-Betrieb. Denn sobald der Bekanntheitsgrad eines Blogs oder Webseite ansteigt, sind Konkurrenten und Neider nicht weit – plötzlich steht man im Fokus der Aufmerksamkeit.

Die im vorliegenden Beitrag vorgestellten Tipps und Informationen dienen dem erweiterten Schutz und lassen sich mit etwas Zeitaufwand umsetzen. Mit jedem Beitrag der Artikelserie steigert sich der Schwierigkeitsgrad für Angreifer, eure WordPress-Seite zu übernehmen.

Dieser Beitrag ist Teil einer Artikelserie:

Update

März 2016: Die Artikelserie wurde das letzte Mal im März 2016 aktualisiert.

2. Snake-Oil!?

Produkte oder Tipps, die wenig oder gar keine echte Funktion bzw. Nutzen bieten, werden in der IT als Snake-Oil bzw. Schlangenlöl bezeichnet. Insbesondere in der IT-Security ist dies ein häufig verwendeter Begriff, um die Wirkungslosikeit von Schutzmaßnahmen zu brandmarken.

Auch in der WordPress-Szene ist das Snake-Oil-Phänomen zu beobachten. News-Seiten, Blogs und Webseiten geben zahlreiche Tipps, empfehlen Security-Plugins oder abenteuerliche Maßnahmen, die eindeutig der Kategorie Snake-Oil zuzuordnen sind. Ein messbarer oder gar sinnvoller Nutzen für die Absicherung von WordPress lässt sich kaum erkennen – und doch wird es von den Anwendern massenweise umgesetzt, in der Hoffnung etwas für die Sicherheit zu tun. Sie wissen es einfach nicht besser und wiegen sich anschließend in »falsche« Sicherheit.
Snake-Oil

Hilf mit die Spendenziele zu erreichen!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

2.1 Beispiele für Snake-Oil-Tipps

Egal ob ihr folgende Tipps auf Webseiten oder als Bestandteil eines Plugins vorfindet – ignoriert sie. Für den normalen Anwender ergeben sich aus deren Anwendung oftmals mehr Probleme als ein messbarer Nutzen:

  • Die Entfernung der WordPress-Version aus dem Quelltext
  • Den Link zum WordPress-Backend (Admin-Bereich) modifizieren bzw. auf einen anderen Link legen
  • Den Pfad zum »wp-content« Ordner verändern bzw. anpassen
  • Entfernen bzw. Ausblenden des Autor Namens
  • [ … ]

Diese Maßnahmen lösen langfristig gesehen keinerlei Probleme, sondern erschweren dem Anwender die Bedienung und Nutzung von WordPress. Neben Schwierigkeiten mit Updates, können sich Anwender an solche Änderungen oftmals nicht erinnern und sind bei Problemen dann überfordert. Des Weiteren resultiert daraus kein messbarer Nutzen für die Absicherung gegen Angreifer. WordPress Versionsnummern lassen sich beispielsweise anhand des Funktionsumfangs leicht bestimmen – dies zu verstecken oder falsche Angaben zu machen hat wenig Nutzen. Spätestens dann, wenn die Informationsgewinnung nicht mehr automatisiert stattfindet, sondern von einer realen Person durchgeführt wird. Solche Maßnahmen werden Security through obscurity genannt – Sicherheit durch Unklarheit.

Fazit: Verzichtet auf diesen Quatsch. Löscht solche Plugins und ignoriert diese Tipps. Eine nachhaltige Sicherheitsstrategie zur Absicherung von WordPress-Installationen sieht anders aus.

3. Webhosting

Webhosting bezeichnet die Bereitstellung von Webspace und dessen Unterbringung (Hosting) von Webseiten auf einem Webserver im Internet – irgendwo muss der WordPress-Blog schließlich »laufen«. Die Bandbreite reicht hier von kostenlosen Angeboten, über Angebote für Privatanwender und Firmenkunden, bis hin zu kompletten Servern. Je nach Ausrichtung, Zielgruppe und Budget ist im Normalfall für jeden etwas dabei. Für einen kleinen Privat-Blog ist ein kompletter Server vollkommen überdimensioniert, während ein Unternehmen mit einem kostenlosen Angebot vermutlich nicht die beste Wahl trifft.

Update

04.03.2016: Die Webhosting-Thematik habe ich nochmals ausführlich in einem neuen Teil der Artikelserie aufgegriffen.

Bei einem neuen Angebot oder bereits bestehendes Hosting-Paket solltet ihr in jedem Fall folgende Punkte prüfen:

  • Hat der Anbieter Erfahrung mit WordPress-Hosting bzw. bietet er entsprechende Pakete an?
  • Fragt den Anbieter nach seiner Backupstrategie, Ausfallzeiten aufgrund von Update- oder Wartungsarbeiten und Ausfallsicherheit. Falls er euch diese Fragen nicht beantworten kann – dann klickt zum nächsten Anbieter.
  • Wie steht es um den Support des Anbieters? Antwortet er zügig auf Anfragen oder Probleme? Werden Updates am Server oder der Umgebung transparent kommuniziert?
  • Welche Webserver-Versionen von Apache, Lighttpd oder nginx setzt der Anbieter ein? Und welche Version von MySQL und PHP? Sind diese aktuell oder gnadenlos veraltet und damit anfällig für diverse Angriffstechniken?
  • Wie oft führt der Anbieter Updates vom Webserver bzw. der Software (Apache, MySQL, PHP) durch? Werden kritische Sicherheitslücken nach bekanntwerden zeitnah gepatcht bzw. geschlossen?
  • Unterstützt der Anbieter die Möglichkeit regelmäßig Backups anzulegen? Und wie kann ich als Nutzer darauf zugreifen? Kann ich das Backup auch auf meinen Rechner zu Hause laden?
  • Bietet der Anbieter die Möglichkeit Daten verschlüsselt über SFTP zwischen dem Rechner zu Hause und der Gegenstelle bzw. dem Webserver auszutauschen?

Ein geeignetes Webhosting-Angebot bildet die Grundlage für euer WordPress-Projekt – egal ob Privat- oder Firmenkunde. Daher solltet ihr euren Anbieter genau unter die Lupe nehmen und die Fragen erörtern.

4. Schutzmaßnahmen

Nicht alle Tipps die im Internet vorgestellt werden eigenen sich für die Umsetzung. Die folgenden Kurztipps reduzieren die Wahrscheinlichkeit allerdings, dass ihr Opfer eines Angriffs werdet.

4.1 SFTP

Beim Hoch- bzw. Herunterladen von Daten sollte die Kommunikation zum Webserver bzw. Webspace stets über einen verschlüsselten Kanal erfolgen. Beispielsweise über das SFTP-Protokoll. Somit kann euer Passwort bei der Anmeldung nicht von einem Angreifer mitgeschnitten werden – in einem öffentlichen WLAN-Hotspot habt ihr dann nichts zu befürchten.

Für Windows eignet sich WinSCP oder FileZilla. Für Mac OS und Linux könnt ihr ebenfalls auf FileZilla zurückgreifen. Ebenfalls oft verwendet wird CyberDuck.

4.2 Security through obscurity

Unter Ziffer zwei habe ich solche Maßnahmen noch als Snake-Oil bezeichnet. Diese beiden stellen die einzige Ausnahme dar:

  • Legt wie im ersten Teil beschrieben ein zusätzliches Administrator-Konto an. Verwendet dabei einen Fantasienamen – zum Beispiel »blogmaster3000«. Danach meldet ihr euch ab und mit dem soeben erstellten Administrator wieder an. Anschließend löscht ihr den Standard-Administrator Account mit dem Namen »admin«.
  • Standardmäßig ist das Tabellenpräfix von WordPress »wp_«. Ihr könnt das Prefix bspw. auf 12eeXk98_wp_ ändern. Damit reduziert ihr die Wahrscheinlichkeit einer SQL-Injections, die gezielt auf das »wp_« Tabellenpräfix ausgerichtet ist. Doch Vorsicht bei diesem Eingriff! Am einfachsten ist es, den Wert noch bei der WordPress-Installation anzupassen. Ansonsten sind später Änderungen in der Datenbank und der »wp-config.php« notwendig.

table_prefix

4.3 Backups

Eure WordPress-Installation wurde von einem Angriff kompromittiert? Ihr habt durch eine kleine Unachtsamkeit wichtige Dateien gelöscht? Ein Plugin hat euch die komplette Webseite zerschossen? Ärgerlich – aber mit einem Backup seid ihr auf der sicheren Seite. Vor jedem Update einer WordPress-Installation und zu festgelegten Zeitpunkten sollten Backups durchgeführt werden. Dazu eignet sich zum Beispiel das Plugin BackUpWordPress oder BackWPup-Plugin. Neben den Seiten, den Konfigurationsdateien, Themes und Plugins wird ebenfalls ein Backup von der Datenbank erstellt.

Backups sind Pflicht! Nach jedem Backup-Durchlauf solltet ihr euch die Daten auf euren Rechner herunterladen und dort sicher verwahren.

4.4 TLS-Verschlüsselung (ehemals SSL)

Es existieren verschiedene Arten von TLS-Zertifikaten. Ein TLS-Zertifikat bzw. die TLS-Verschlüsselung ermöglicht eine verschlüsselte Kommunikation zwischen WordPress und eurem Browser – Passwörter für die Anmeldung im Dashboard lassen sich somit nicht von einem Angreifer mitlesen. Falls euer Anbieter bzw. Hoster TLS-Zertifikate unterstützt, solltet ihr eines beantragen. Je nach Vertragsdauer belaufen sich die Kosten auf ca. 25 – 60 € pro Jahr für eine Domain. Alternativ könnt ihr bei Let’s Encrypt ein kostenloses Zertifikat beantragen – falls dies bei eurem Hoster möglich ist, dann solltet ihr diese Variante wählen.

Um sicherzustellen, dass eure Kommunikation nach der Integration eines TLS-Zertfikats verschlüsselt stattfindet, solltet ihr in der Datei »wp-config.php« folgende Änderung vornehmen:

define('FORCE_SSL_ADMIN', true);

Mit »FORCE_SSL_ADMIN = true« wird neben dem Anmeldeprozess die gesamte Admin-Session verschlüsselt. Dazu zählen neben dem Passwort für die Anmeldung auch die Cookies. Seit WordPress 4.x ist der Paramater »FORCE_SSL_LOGIN = true« übrigens veraltet und wird vollständig durch »FORCE_SSL_ADMIN = true« ersetzt.

4.5 Verschieben der wp_config.php

In der Konfigurationsdatei »wp_config.php« sind einige Werte hinterlegt, die während der Installation definiert wurden. Dazu zählt unter anderem der Datenbankname und der entsprechende Username inklusive das Datenkbank-Passwort. Also jene Informationen, die nicht unbedingt in falsche Hände geraten sollten – ansonsten könnte sich jemand damit Zugang zur Datenbank verschaffen. Um diese Datei zu schützen eignen sich zwei unterschiedliche Varianten. Variante 1 sieht vor die Datei an einen anderen Ort des Webservers zu verschieben, der öffentlich nicht zugänglich ist.

Im Beispiel liegt die »wp_config.php« in folgendem Pfad des Servers:

/var/www/sites/public_html/wp_config.php

WordPress gestattet es dem Anwender die Konfigurationsdatei eine »ebene Höher« abzulegen. Sie liegt nun unter:

/var/www/sites/wp_config.php

WordPress sucht dort übrigens vollkommen automatisch, dafür müsst ihr nichts konfigurieren. Die Idee dahinter sollte klar sein. Durch die Verschiebung aus dem normalen Webroot-Verzeichnis soll ein Angreifer niemals direkten Zugriff auf diese sensible Datei erlangen.

Aus meiner Sicht erhöht sich die Sicherheit durch diese Maßnahme nicht. Warum? In dieser Datei sind lediglich ein paar Konstanten definiert, die niemals auf dem Bildschirm ausgegeben werden. Falls jemand diese Datei ernsthaft auslesen möchte, muss er den PHP-Interpreter auf dem Server so manipulieren, dass *.php Dateien als Text dargestellt werden. Wenn jemand dies schafft hat er in der Regel Zugang zum System bzw. dem Webserver. Einige Hosting-Anbieter verbieten sogar den Schreibzugriff auf eine höhere Dateiebene – damit fällt Variante 1 unter den Tisch.

Sinnvoller erscheint mir Variante 2. Dort wird die »wp_config.php« mit einem Zugriffsschutz versehen. Welche Variante jetzt die Bessere darstellt – darüber kann man sich streiten. Ich bleibe bei Variante 2 und habe dies ausführlich im fünften Teil der Serie beschrieben.

WordPress auf Schwachstellen und Konfigurationsfehler prüfen

Für Deine WordPress-Installation habe ich ein spezielles Leistungspaket im Angebot:
  • Scan Deiner WordPress-Installation auf Schwachstellen
  • Auswertung und Beurteilung der gefundenen Schwachstellen
  • Auf Basis der Ergebnisse erhälst Du von mir individuelle Maßnahmenempfehlungen zur Behebung und Absicherung

Wenn du Deine WordPress-Installation nachhaltig absichern möchtest, kannst Du mich gerne kontaktieren.

Gut zu wissen: Sicherheit erlangst Du nicht durch die Installation unzähliger Security-Plugins, sondern durch eine saubere Konfiguration, stetige Updates und proaktive Maßnahmen zur Absicherung. Kontakt aufnehmen

5. Ein (warnendes) Wort zu Plugins und Themes

Mittels Plugins und Themes lässt sich WordPress ganz nach der Vorstellung des Anwenders individualisieren. Jedes zusätzliche Plugin erhöht allerdings auch die Wahrscheinlichkeit für einen erfolgreichen Angriff. Dafür kann es mehrere Gründe geben:

  • Jedes Plugin bedeutet weitere Zeilen an Code, die von jemandem geschrieben wurden. In jedem Code befinden sich Fehler. Fehler, die oft dazu ausgenutzt werden können, um die WordPress-Installation anzugreifen, um bspw. erhöhte Rechte zu erlangen. Ist der Plugin-Entwickler also in der Lage seinen Code einigermaßen sicher zu schreiben?
  • Wann wurde das Plugin das letzte Mal einem Update unterzogen? Sind die verwendeten Bibliotheken noch aktuell oder schon veraltet? Findet regelmäßig eine Anpassung für neue WordPress-Versionen statt?
  • Ist das eingesetzte Plugin überhaupt vertrauenswürdig? Wer hat es programmiert und zu welchem Zweck? Haben sich Benutzer schon den Quellcode angeschaut bzw. eine Bewertung dazu abgegeben?

Auch WordPress-Themes unterliegen ähnlichen Fragen bzw. Risiken. Wird das Theme gepflegt, an neue WordPress-Versionen angepasst und wie qualitativ ist dessen Programmierung?

Ihr solltet eure WordPress-Installation auf ein Minimum an Plugins reduzieren. Also wirklich nur jene Plugins einsetzen, die ihr wirklich benötigt und auch einen Mehrwert bieten. Des Weiteren solltet ihr nach der »Ausmistaktion« prüfen, ob die oben genannten Kriterien von den verbleibenden Plugins erfüllt werden oder ob vielleicht bereits Alternativen existieren, deren Code schlanker, sicherer und performanter ist. Denn trotzt aller bisher vorgestellten Maßnahmen bieten schlechte oder alte Plugins bzw. Themes noch immer eine beliebte Angriffsfläche, die es zu minimieren gilt.

6. Fazit

Mit den vorgestellten Tipps und Informationen könnt ihr die Wahrscheinlichkeit Opfer eines Übergriffs zu werden weiterhin reduzieren. Snake-Oil-Maßnahmen solltet ihr meiden – damit erhöht sich die Sicherheit nicht, sondern trägt lediglich zur Kaschierung der Probleme bei.

Es ist an der Zeit etwas auszumisten. Alte Plugins entrümpeln, einfache Funktionen eventuell selbst über die functions.php zu implementieren oder unnötige Themes endgültig zu löschen. Neben Geschwindigkeit erhaltet ihr dadurch auch gleichzeitig etwas mehr Sicherheit.

Im nächsten Teil der Artikelserie widme ich mich den sogenannten Security-Plugins. Viele davon versprechen eine Steigerung der Sicherheit – sind allerdings nichts anderes als Snake-Oil. Beispielsweise werde ich euch zeigen, weshalb das Plugin Limit Login Attempts und ähnliche seiner Zunft gegen gezielte Angriffswellen keinen Mehrwert bieten.

Bildquellen:

Pile of Books: „#49330890“, https://de.fotolia.com/id/49330890

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

9 Ergänzungen zu “Schutzmaßnahmen – WordPress absichern Teil2”

  1. Comment Avatar Lukas Blatter sagt:

    Ein Kommentar zu Punkt 4.5 „Verschieben der wp_config.php“.

    Ein .htaccess Zugriffschutz ist auf jedenfall zu empfehlen. Allerdings ist dieser weder besser noch schlechter als ein verschieben der wp_config.php. Wenn ein Angreifer ein eigenes PHP Script hochladen konnte, spielt es keine Rolle mehr ob die Datei eine Ebene höher oder per .htaccess geschützt ist. In beiden Fällen lässt sich die Datei per PHP auslesen.

  2. Comment Avatar Thomas Will sagt:

    *****
    Backup von FTP-Inhalt UND der Datenbank nach großen Updates sind absolute Pflicht!
    *****

    Alles unterschiedliche Paßwörter für das WordPress-Login, die Datenbank, FTP und den Kundenbereich sind ebenso empfehlenswert (dafür macht dann tatsächlich ein Paßwort-Manager Sinn).

    Ich verwende infinitewp.com , eine Admin- und Update-Oberfläche für meherere WP-Installationen, diese sitzt auf einem eigenen Webspace, der eine andere IP hat als meine WP-Seiten.

    infinitewp.com bietet auf seiner Oberflöche eine Backup-Möglichkeiten von FTP und MYSQL zusammen an, das wird auf dem Webspace in eine ZIP-Datei gepackt und kann nach dem Erstellen heruntergeladen werden.

    Bei den WP-Seiten habe ich in die .htaccess im Root-Folder dann die IP-Adresse der InfiniteWP-Installation eingegeben, so daß ein Einloggen nur von dort möglich ist.
    Man kann dann auf wp-login nur von eben dieser Adresse drauf zugreifen, alle anderen „Direkt-Zugreifer“ auf „meineseite.tld/wp-login“ bekommen eine Fehlermeldung.
    Dann noch die Berechtigung der .htaccess Datei auf 0604 oder besser 0404 runtersetzen.

    # Allow login only from IWP

    order deny,allow
    deny from all
    allow from xxx.xxx.xxx.xxx

  3. Comment Avatar Jens sagt:

    Danke für die Tipps!

    Wie sieht es denn mit dieser Maßnahme aus? Ist die eher sinnfrei oder vielleicht inzwischen sogar hinfällig?

    „Die Autor CSS-Klasse aus den Kommentaren entfernen“
    https://www.drweb.de/wordpress-installation-korrekt-absichern/

  4. Comment Avatar Guido sagt:

    Hallo Mike,

    ich hätte noch eine Frage zu 4.5.!
    Standardmäßig liegt die wp_config.php im Installationspfad von WordPress. Hier ist auch schon eine .htaccess vorhanden. Wie hast du das gemeint? Wie kann die wp_config.php zusätzlich durch ein .htaccess abgesichert werden?

    Viele Grüße
    Guido

    • Comment Avatar Mike Kuketz sagt:

      Hallo Guido,

      die bereits bestehende .htaccess Datei kann mit den oben dargestellten Code-Snippets einfach erweitert werden. Damit ist dann ein Schutz der wp-config.php möglich.

  5. Comment Avatar Marcus sagt:

    Hallo Mike

    Ich bin gerade mit dem Säubern einer WP installation beschäftigt die im Root Verzeichnis installiert wurde. Es gibt einige Unterverzeichnisse von denen niemand genau weiß wozu sie da sind. Teilweise sind dort andere CMS Installiert (die auch infiziert wurden).
    Meine Frage: Wäre es nicht sinnvoll WP in ein Unterverzeichnis zu verschieben und die Domain nur auf dieses Verzeichnis verweisen zu lassen?
    Bzw. wenn es zu einer Infektion von WP kommt, dann wären nicht direkt alle anderen Verzeichnisse auch in Gefahr, oder?

  6. Comment Avatar Ribiku_Sith sagt:

    Hallo erstmal,

    bin gerade am lesen Deines Artikel, dafür schon mal vielen Dank für die Tipps und die Zeit von Dir. Der Tipp mit Filezilla sollte ggf. noch darauf eingehen, die Passwörter nicht in Filezilla zu speichern. Leider legt das Programm, so gut es auch sein mag, die Passwörter im Klartext ab.

    Hier sollte man einfach auf einen PWD Manager setzen. Da spielt es letztlich auch keine rolle das ganze über SSH/SFTP gemacht zu haben.

    Wie schon geschrieben, vielen Dank für den Artikel und viele Grüße!

    Ribiku

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.