Gastbeitrag: WordPress-Administration per SSL absichern

Es gibt viele Möglichkeiten, um die WordPress-Administration sicherer gegen Angreifer zu machen. Das fängt bei solch trivialen Dingen wie dem Benutzen von sicheren Passwörtern an und geht hin bis zum Absichern der WordPress-Administration mit einer zusätzlichen Authentifizierung am Webserver.

In dieser Anleitung gehen wir aber noch einen Schritt tiefer und verschlüsseln die WordPress-Administration per SSL. Hierbei wird sämtlicher Datenverkehr der WordPress-Administration über einen sicheren, verschlüsselten Kanal geleitet.

Für diese Anleitung wird ein Webserver mit SSL-Unterstützung benötigt. Wer nicht genau weiß, ob sein Webserver von Haus aus SSL unterstützt, hängt einfach ein https:// anstatt eines http:// vor seine Internetadresse. Wenn keine Verbindung hergestellt werden kann, ist SSL noch nicht verfügbar. Eventuell kann man SSL beim Webhoster gegen einen geringen Aufpreis dazubuchen. Wer einen vServer oder root-Server sein Eigen nennt, sollte sich diese Anleitung zur Einrichtung eines Apache-Webservers mit SSL mal anschauen.

Außerdem muss das Umleiten von URLs per .htaccess-Datei erlaubt sein, was aber bei den meisten Anbietern der Fall ist.

Zunächst öffnest du die Datei wp-config.php im WordPress-Hauptverzeichnis und fügst an das Ende der Datei die Zeile

define('FORCE_SSL_ADMIN', true);

ein. Diese Option veranlasst WordPress, den Login-Prozess nur über eine gesicherte Leitung abzuwickeln.

Das macht das ganze schon ein Stückchen sicherer, allerdings wird noch der Rest der Administration unverschlüsselt übertragen. Deshalb machen wir uns nun an die Anpassung des Webservers. Öffne nun die Datei .htaccess in dem WordPress-Hauptverzeichnis und füge folgende Zeile ein:

RewriteCond %{SERVER_PORT}  ^80$
RewriteRule ^http://(.*?)/wp-admin/(.*) https://$1/wp-admin/$2 [R,L]

Dieser Eintrag muss direkt nach dem Eintrag:

RewriteBase /

platziert werden, wobei der RewriteBase-Eintrag je nach Konfiguration eventuell abweichen kann.

Jetzt solltest du direkt beim Aufrufen der WordPress-Administration auf https umgeleitet werden. Somit ist nun deine ganze Arbeit in der WordPress Administration verschlüsselt.

Der Experte wird unter gewissen Umständen vielleicht bemerken, dass nicht alle Daten verschlüsselt übertragen werden (Firefox zeigt keinen blauen oder grünen Balken hinter dem favicon an). Manche Plugins fordern Daten außerhalb des Ordners wp-admin an. In diesem Fall werden diese Daten nicht verschlüsselt übertragen. Bei mir zum Beispiel hat das Plugin Ajax Edit Comments noch Daten aus anderen Verzeichnissen nachgeladen.

Unter Firefox kann man schnell nachschauen, welche Daten unverschlüsselt geladen werden. Klicke dazu mit der rechten Maustaste irgendwo in die Administration (nur nicht auf einen Link :P) und wähle Seiteninformationen anzeigen.

Unter dem Reiter Medien kannst du dir dann anschauen, woher sämtliche Daten geladen wurden. Diejenigen, bei denen kein https angegeben wird, wurden über einen unverschlüsselte Verbindung übertragen, was aber in der Regel nicht weiter schlimm ist:

Ab sofort ist dein WordPress noch etwas sicherer gegen Angreifer. Diese können aufgrund der Verschlüsselung keine sensiblen Daten mehr abfangen.

Über den Autor dieses Artikels

Mein Name ist Patrick Gotthard und in meinem Blog beschäftige ich mich vor allem mit HTPCs (auch MediaPCs oder Wohnzimmer-PCs genannt) und diversen Software-Themen (Programmierung in PHP und Java, Webdesign, WordPress, Linux- und Windows-Betriebssysteme, Softwarevorstellungen). Außerdem berichte ich über interessante Fundstücke aus dem Netz. Ich würde mich freuen, wenn ihr mir auch mal einen Besuch abstattet.

Gefällt dir der Artikel? Dann teile ihn mit deinen Freunden.

Hallo, ich bin Carsten! Baujahr 1977, Dortmunder im Norden, BVB-Getaufter und Gründer dieses Blogs. Auch zu finden bei Twitter, Google+, Facebook, Instagram und YouTube. PayPal-Kaffeespende. Mail: carsten@caschys.blog

57 Kommentare

  1. Hä?

  2. Der Link im ersten absatz „Absichern der WordPress-Administration mit einer zusätzlichen Authentifizierung am Webserver“ hat „file:///“ als Ziel. Glaube, das ist so nicht gewollt 😛

  3. Interessanter Artikel! Leider kann ich auf keinen meiner Blogs SSL verwenden. 🙁 Ich werde beim nächsten Mal aber darauf achten 😉

    BTW: Bekommt Patrick nun eigentlich mein theoretischen Flattr? 😀

  4. Danke caschy, für das tolle Geburtstagsgeschenk 🙂 Hmm der Link muss in der Tat angepasst werde, ich hatte nur einen relativen Link-Pfad auf einen Artikel von dir gesetzt.

    Korrekte URL: http://stadt-bremerhaven.de/wordpress-sicherer-machen-ohne-plugins/

  5. Vielleicht erklärt auch noch jemand den leuten die es Toll finden das SSL total sinnlos ist wenn man nicht grade mit einem unverschlüsselten und öffentlichen Wlan drinne Rummacht.

    Die Chance das unterwegs jemand mitliest ist um den Faktor 1000 kleiner als die Gefahr über ne Sicherheitslücke ins Backend zu kommen.

  6. Ich wollte das bei mir auch schon in die WP-Config einbauen, doch bei mir besteht leider das Problem, dass die SSL-Zertifikate in der Firma durch die Firewall überprüft werden. Da ich nur ein kostenloses Zertifikat habe, wird das von der Firewall geblockt.

    Bezüglich WordPress Login-Sicherheit ist das Plugin „Semisecure Login Reimagined“ noch empfehlenswert!

  7. Anscheinend kennst du dich mit Netzwerktechnik nicht besonders gut aus. Daten kann man mit diversen Methoden abfangen, MITM-Attacken per z.B. ARP-Poisoning, unverschlüsselte oder schlecht verschlüsselte WLANs, unsichere Leitungen über das Internet etc pp. Auch wenn du z.B. an einem Hub hängst, musst du nur einmal Wireshark anschmeißen und kannst alles mitlesen, vorrausgesetzt, du kannst dein NIC in einen Listen-Mode versetzen…

    Da fällt mir grad spontan dieser Artikel von gestern ein: http://stadt-bremerhaven.de/woher-kommt-der-hass/

  8. Super Beitrag. Danke Patrick!

  9. Der Kommentar eben galt übrigens @sonyon, hab ich vergessesn anzugeben und editieren war nicht mehr möglich.

  10. Eine unverschlüsselte Datenübertragung im Internet ist immer unsicher. Da würde ich empfehlen sich mal mit dem Aufbau des Internets zu beschäftigen, dann versteht man es auch. Man braucht nur grob zu wissen wie das Internet funktioniert und dann sollte jeden klar sein, dass eine unverschlüsselte Datenübertragung einer Postkarte gleicht.

  11. Ich bekomme hier die Editiermöglichkeit erst garnicht zu sehen. Ich habe anscheinend nicht alle Einstellungen so gesetzt, dass mir die Editiermöglichkeit angezeit werden könnte. Wie wird hier die Editiermöglichkeit bereitgestellt und was muss alles an sein, damit man die Funktion auch nutzen kann? Danke im Voraus.

    P.S.: Mein Kommentar galt auch @sonyon.

  12. Hallo und danke für diesen interessanten Artikel. Bei den meisten Providern wird es wohl so sein, dass das Zertifikat des Providers auf dem Server installiert ist.

    Hier muss man dann dem Browser eine Ausnahmeregel hinzufügen.

    Gruß
    Thomas

  13. @Adam: Du musst JavaScript aktiviert haben. Dann sollte nachdem du einen Kommentar abgegeben hast und bevor ein neuer Kommentar eingetragen wurde unter deinem Kommentar ein Editieren-Button erscheinen.

    Das gleiche kannst du sonst auch bei mir im Blog testen 😉

  14. @Thomas: Jupp für solche Dinge ist das ja noch ok, die Administration sollten ja eigentlich nicht viele Leute benutzen.

    Wenn man einen öffentlichen Bereich verschlüsseln möchte, sollte man natürlich auf ein signiertes Zertifikat von einer bekannten CA setzen, damit nicht jeder Benutzer eine Ausnahme hinzufügen muss. Solche Zertifikate können aber auch recht teuer sein…

  15. Auf meinem Server habe ich ein richtiges Zertifikat, allerdings nur für einen Hostnamen. Und auch nur eine IP-Adresse. Allerdings laufen verschiedene WordPress-Blogs unter unterschiedlichen Domains auf diesem Server.

    Wäre es möglich, dass sämtliche Blogs über den gesicherten Hostnamen administriert werden können?

    Also z.B.
    Zertifikat für http://sicheredomain/ vorhanden,
    Blog1 unter http://blog1/ -> Admin unter z.B. http://sicheredomain/blog1/wp-admin/
    Blog2 unter http://blog2/ -> Admin unter z.B. http://sicheredomain/blog2/wp-admin/

    Wäre das auch irgendwie möglich?

  16. @Tobias: Möglich ist das, ich würde es persönlich allerdings über Subdomains statt über Aliase lösen… aber das ist Geschmackssache 🙂

  17. Subdomains geht ja auch nicht, weil ich nur genau ein Zertifikat für genau einen Hostnamen habe.

  18. Achso sorry… ich bin aus meinem Unternehmen Wildcard-Zertifikate gewohnt. OK, dann musst du das natürlich über Aliase regeln.

  19. Ich frage mich, warum sollte man auf die Idee kommen, den kompletten Admin-Bereich via SSL abdichten? Die Login-Seite ist verständlich, das hat auch WordPress per Konstante vorgesehen.

    Welche Daten sind nach dem Login so sensibel, dass man diese schützen sollte? Löschung der Spam-Kommentare? Verfassung der Beiträge? Ich könnte mir nur den Benutzer-Bereich mit der Möglichkeit Zugangsdaten zuzuweisen als einen Kandidaten vorstellen. Aber der Rest?

    Man soll auch immer bedenken: SSL = langsamer. Je nach Verbindung kann dann die Übertragung von Bildern gleich zu einer Geduldsprobe werden.

  20. @Sergej: Gute, berechtigte Frage. Die Benutzerverwaltung ist schonmal ein Grund. Aber auch wenn du z.B. Plugins einrichtest, gibst du z.B. deine Twitter- oder Google-Daten ein.

    Wenn man es mal auf die Spitze treibt, könntest du auch verhindern, dass dich Leute beim Verfassen von neuen Artikeln „belauschen“ – das ist wohl aber ein Grund für echt hartgesottene Sicherheitsfanatiker 😛

    Und dann würde mir noch einfallen, dass Benutzerdaten in der Admin wie z.B. E-Mail-Adressen deiner Kommentatoren abgreifbar wären.

  21. Das ist aber wirklich für paranoide Sicherheitsjunkies 😉

    Hast du mal selbst probiert, den kompletten Admin-Bereich zu „verschlüsseln“? Funktioniert dann der Flash-Uploader? Das Ding ist extrem pingelig, was Änderung der Pfade angeht.

  22. Oh du hast recht… der funzt nicht mehr, hab’s grad ausgetestet (erst gestern hab ich die Admin verschlüsselt und seitdem keinen Beitrag verfasst). Ich werd‘ mich mal nach einer Lösung umschauen… Du hast nicht zufällig im Kopf, an welches Script der Flashuploader die Daten schickt?

  23. So aus dem Kopf nicht, müsste man sniffen.

  24. Sehr interessanter Artikel. Aber ich bin Anwender. Mir ist das alles doch zu technisch. Gut, wer täglich damit beschäftigt ist, dem ist das alles sehr vertraut, das sieht man an den Kommentaren. Aber ich mag nicht stundenlang etwas ändern, hinzufügen, löschen, wo ich nichts von verstehe. Dann nehme ich Patricks sicherlich guten „Fahrplan“ arbeite das alles ab und weiß doch nicht, was ich eigentlich getan habe.

  25. Ach so technisch ist der Artikel doch nicht und Verschlüsselung sollte doch jedem was sagen 😉 Wer kennt nicht aus Kindertagen noch die Caesar-Verschlüsselung 😛

  26. Kann man das auch mit dem kostenloasen WordPress-Account ohne eigene Adresse — also mit .wordpress.com hintendran — machen? Und wenn ja — wie? Erlaubt wordpress eigentlich ftp zugriff für den eigenen Bereich?

    Ansich eine schöne Sache — würde ich sofort machen, wenn es möglich ist…

  27. @paradonym: Hast du mal versucht, https vor die URL zu schreiben. Wenn deine Seite dann noch angezeigt wird, sollte das klappen.

  28. https://paradonym.wordpress.com/ – ja aber ich arbeite ja nicht mit einem eigenen Programm oder so — https geht zwar, aber hier beschreibt WordPress selbst, dass es keinen FTP zugriff gewährt — deswegen fragte ich…

  29. stoiberjugend says:

    bei all-inkl schonmal jmd angetestet?

  30. Haben Apache-Server wenn von einem Webhoster angeboten normalerweise mod_rewrite installiert und existiert da auch meist ein Engine On?

    Sehr schöner Beitrag, aber für unwissende, interessierte Nutzer wäre es u.U. sinnvoll einen Link zu Erklärungen für mod_rewrite und co. zu geben, damit auch jeder weiss was er da tut (ist dann auch für Fehlersuche einfacher).

    Habe erst gestern in ähnlicher Weise den phpMyAdmin abgesichert. Den Artikel nen Tag eher und ich hätte die Informationen nicht so zusammen suchen müssen 😉

  31. Nur den Login-Prozess zu verschlüsseln bringt nicht viel, da man aus dem unverschlüsselten Webinterface nur noch das Cookie auslesen muss, und hat dann Vollzugriff. Das Verschlüsseln des Login-Prozesses verhindert nur, dass das Passwort ausgelesen wird und ist insofern nur ein Problem, wenn man das gleiche Passwort an mehreren Stellen verwendet.

  32. @tobias:

    Wenn man den Admin-Bereich (oder zumindest Teile davon) zusätzlich per .htaccess schützt dann kann man auch dem recht gut aus dem Weg gehen 🙂

  33. @Jeffrey
    Mein Schüler 😉

  34. @Sergej:

    Japp, von dir habe ich bereits schon einiges gelernt 🙂

  35. @paradonym: Also wie es aussieht, kannst du auf https-Verschlüsselung zurückgreifen. Demnach sollte das ganze klappen. Muss ich nurnoch nen Fix für das Problem mit dem Uploader finden.

    @Najtrok: Die meinsten Provider erlauben mod_rewrite, man muss es nur per .htaccess aktivieren.

  36. Sorry Jungs, ich hab oben einen Fehler gemacht.

    @caschy: Bitte passe die RewriteRule wie folgt an:
    RewriteRule (.*)wp-admin(.*) https://%{SERVER_NAME}/$1wp-admin$2 [R,L]

    Diese RewriteRule sollte allgemeingültig sein, auch wenn man WordPress in einem Unterverzeichnis benutzt. Habe leider eben erst bemerkt, dass man das http:// am Anfang der URL nicht so einfach per mod_rewrite auslesen kann.

    P.S.: Ich bin dran am FlashUploader Problem. Mit dem HTTP-Uploader läuft es einwandfrei bei mir. In diesem Artikel wird detailliert auf das Problem mit SSL + FlashUploader eingegangen, bei mir hat das von demjenigen erstellte Plugin allerdings nur teilweise geholfen (Bild lädt hoch, aber WordPress bleibt beim „Crunching…“ hängen).

  37. Sorry Jungs, ich hab oben einen Fehler gemacht. Die RewriteRule oben ist nicht funktionsfähig, da hab ich etwas gepatzt.

    @caschy: Bitte passe die RewriteRule wie folgt an: http://nopaste.info/bc1dee61f8.html (konnte den Code so nicht hier posten)

    Die neue RewriteRule sollte allgemeingültig sein, auch wenn man WordPress in einem Unterverzeichnis benutzt. Habe leider eben erst bemerkt, dass man das http:// am Anfang der URL nicht so einfach per mod_rewrite auslesen kann. Bei mir hatte ich die Abfrage mit http weggelassen, weil ich WordPress nicht in einem Unterordner betreibe.

    P.S.: Ich bin dran am FlashUploader Problem. Mit dem HTTP-Uploader läuft es einwandfrei bei mir. In diesem Artikel wird detailliert auf das Problem mit SSL + FlashUploader eingegangen, bei mir hat das von demjenigen erstellte Plugin allerdings nicht geholfen (Bild lädt hoch, aber WordPress bleibt beim „Crunching…“ hängen).

  38. Sorry Jungs, ich hab oben einen Fehler gemacht. Die RewriteRule oben ist nicht funktionsfähig, da hab ich etwas gepatzt.

    @caschy: Bitte passe die RewriteRule wie folgt an:
    RewriteRule (.*)wp-admin(.*) https://%{SERVER_NAME}/$1wp-admin$2 [R,L]

    Die neue RewriteRule sollte allgemeingültig sein, auch wenn man WordPress in einem Unterverzeichnis benutzt. Habe leider eben erst bemerkt, dass man das http:// am Anfang der URL nicht so einfach per mod_rewrite auslesen kann. Bei mir hatte ich die Abfrage mit http weggelassen, weil ich WordPress nicht in einem Unterordner betreibe.

    P.S.: Ich bin dran am FlashUploader Problem. Mit dem HTTP-Uploader läuft es einwandfrei bei mir. In diesem Artikel wird detailliert auf das Problem mit SSL und FlashUploader eingegangen, bei mir hat das von demjenigen erstellte Plugin allerdings nicht geholfen (Bild lädt hoch, aber WordPress bleibt beim Crunching… hängen).

  39. Oh sorry caschy, bitte lösche den mehrfachen Kommentar. Ich hab den Kommentar eben öfters abgeschickt, weil die Seite nicht reagiert hat bzw. kurzzeitig garnicht mehr erreichbar war.

  40. Ahoi, Patrik.

    Ja, der Uploader. Deswegen sage ich in Artikeln meiner Sicherheitsreihe: Schützt nie den kompletten wp-admin Ordner mit Zugangsdaten via .htaccess. Nur die Login-Seite, praktisch die Eingangstür deiner Burg. Weil WordPress eben nicht konsequent genug mit der Trennung Backend/Frontend umgeht und Dateien aus dem Backend auch im Frontend einbindet. Oder halt den Flash-Uploader dabei killt. Daher ist beim Manipulieren des kompletten Admin-Verzeichnisses oberste Vorsicht geboten.

    Und bis du einen Workaround für das Problem gefunden hast, würde ich einen Hinweis oben im Artikel vorschlagen. Denn Blogger, die dem Blog durch SSL etwas Gutes verpassen wollen, sollen ja nicht die zweit genutzte Funktion (Flash-Upload) unbewusst lahmlegen.

  41. @Sergej: „[…]die zweit genutzte Funktion[…]“ welches ist denn die meistgenutzte Funktion? 😛

    Ja oben muss die RewriteRule auch nochmal angepasst werden, da hab ich leider etwas geschlampt. Und den Hinweis kann ebenso auch nur caschy einpflegen :-/

  42. @Patrick
    Ich hoffe, Beiträge verfassen ist die meist genutzte.

  43. Achso, ich hatte nun irgendein anderes Feature erwartet. Macht natürlich Sinn, dass die Leute auch Content auf ihr Blog bringen 😀

  44. Welchen sehr preisgünstigen Hoster empfiehlt ihr, wenn man SSL nutzen will? (Ich war vorher bei strato und war SSL-mäßig enttäuscht gewesen). Mir geht es nur um 1-2 wordpress-Skripte und sagen wir mal ca. 500mb Webspace. Traffic soll jetzt mal kein Kriterium sein, da alles im Rahmen liegt.

    Danke schonmal. 🙂

  45. Ich musste leider eben feststellen, dass meine in den Kommentaren geschriebene Regel nicht greift, wenn WordPress in einem Unterverzeichnis liegt, deshalb hier nun die hoffentlich für alle WordPress-Installationen passende RewriteRule:

    RewriteCond %{HTTPS} !=on
    RewriteRule wp-admin https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

    Das Problem mit dem Flash-Uploader besteht leider nach wie vor. Als Workaround muss man derzeit noch auf den HTTP-Uploader umsteigen.

  46. WordPress 3.0 soll übrigens voraussichtlich Mitte Juni erscheinen, der erste Release Candidate sollte kommende Woche erscheinen, so die neueste Meldung im WordPress Deutschland-Blog.

    http://blog.wordpress-deutschland.org/2010/05/22/wordpress-3-0-vorraussichtlich-mitte-juni.html/comment-page-1#comment-122309

    Ich kann es kaum erwarten.

  47. Heute ist der erste Release Candidate von WordPress 3.0 erschienen, das ist eine gute Nachricht. 🙂

  48. @paradonym: Ich hab mir eben nochmal alle Kommentare durchgelesen. Also wenn du keinen Zugriff per FTP hast, musst du irgendwie anders deine .htaccess editieren – falls das bei wordpress.com überhaupt irgendwie möglich ist. Ich meine, dass ich irgendwann mal einem WordPress-Plugin über den Weg gelaufen bin, mit dem man die .htaccess-Datei aus der Administration heraus anpassen konnte.

  49. @Patrick & Paradonym

    Mit dem WordPress-Plugin FileBrowser von Daniel Hüsken sollte man die .htaccess über den Browser bearbeiten können.

    Ob Worpress.com das unterstützt ist die andere Frage 🙂

  50. Ich bin jetzt ein Tarif höher bei meinem Webhoster, aber https spuckt weiterhin eine Fehlermeldung aus. Ich glaube kaum, dass es in einem Tarif eines Webhosters standardmäßig drin ist. Schade, dass es nicht geht.

  51. Auch wenn der Artikel schon etwas älter ist…

    Wofür soll man denn die Rewrite in die htaccess schreiben? Über FORCE_SSL_ADMIN wird man doch automatisch per https in den Admin-Bereich gelotst. Oder habe ich da was übersehen?

    Und wegen dem Flash-Uploader, die aktuelle Version 1.07 von diesen NO SSL Flash Uploader PlugIn funktioniert bei mir:
    http://wordpress.org/extend/plugins/aarons-no-ssl-flash-upload/

    Und gibt es einen Trick, die Dateien wirklich über https abzurufen? Denn im Backend von WordPress bekomme ich immer das Symbol dafür, dass die Verbindung ja nur teilweise verschlüsselt ist (ist zwar halb so wild aber dennoch ärgerlich).

  52. Ich bedanke mich für den Beitrag!

  53. Hi, habe vor einigen Tagen einen Blog-Post zum Thema „WordPress Sicherheit“ geschrieben, ggf. hilft es ja jemandem weiter 🙂

    -> http://suckup.de/blog/2010/10/09/wordpress-sicherheit-erhoehen/

    Mfg Voku