WordPress und Sicherheit: kleine Zusammenfassung

21 Kommentare

WordPress-Logo Da mich in den letzten Tagen zwei Kollegen mit Links zum Thema WordPress und Sicherheit beschenkt haben. Dachte ich mir ich poste die Links in diesem Artikel, füge selber welche hinzu und mache am Ende eine kleine Zusammenfassung zu diesem Thema.

Der gute Freund und Kollege Jens Grochtdreis machte mich auf den Link Effective Security Practices and Plugins for WordPress (Link existiert nicht mehr) aufmerksam. Kollege Ralph Segert machte mich wiederum auf seinen Artikel Zur Sicherheit: Leitfaden für WordPress-Kunden aufmerksam.

Die beiden Links möchte ich dann mit dem Verweis auf den Artikel aus WordPress-Buch.de ergänzen: WordPress installieren und sicherer machen. Zur guter Letzt ergänze ich das ganze durch den Artikel von Sergej Müller: Sicherheit in WordPress: 10 Schritte zum Schutz des Admin-Bereichs.

Die einzelnen Schritte

Hier kommt jetzt die Aufzählung einzelner Schritte zur Steigerung der Sicherheitsmaßnahmen, die ich persönlich für sinnvoll halte. Mit sinnvoll meine ich, dass der Aufwand und die Steigerung der Sicherheit in einem guten Verhältnis stehen. Maßnahmen die viel Wissen und Zeit erfordern sollten meiner Meinung nach erst dann angegangen werden, wenn die einfache Maßnahmen schon umgesetzt wurden.

[adrotate group=”5″]

  • Starke Passwörter für den Account beim Hoster und für die Datenbank wählen. Vor ein paar Tagen hatte ich hier einen Artikel zum Thema sichere Passwörter.
  • Besorge dir die Sicherheitsschlüssel für die gesalzenen Passwörter, siehe wp-config.php
  • Ändere bei der Neuinstallation in der wp-config.php das Standard-Präfix für die Datenbanktabellen von wp_ in irgendetwas anderes, zum Beispiel projekt_name_.
  • Wenn du bei der Neuinstallation den Admin-Account erstellst, dann wähle nicht nur ein starkes Passwort sondern auch einen Nutzernamen, der nicht admin ist. Sogar Administrator ist besser, weil alles was vom Standard abweicht, macht dein Weblog ein Stückchen sicherer.
  • Installiere ein Plugin, welches die Anzahl der Loginversuche begrenzt: Limit Login Attempts. Damit schützt du dich vor Brute-Force-Attacken.

  • Sei sparsam mit den Schreibrechten auf dem FTP-Server. Wenn deine Permalinkstruktur steht, dann muss die .htaccess-Datei nicht weiterhin CHMOD 666 haben. Auch muss der Ordner wp-content nicht selber CHMOD 777 haben. Man kann den Ordner für die Uploads manuell erstellen und nur ihm die Schreibrechte zuweisen.
  • Wenn du kostenlose Themes und Plugins nutzt, dann lade die diese nur von der offiziellen WordPress-Seite herunter.
  • Schütze die wp-config.php vor externen Zugriffen (siehe Code weiter unten)

Hier der Code für die .htaccess-Datei um die wp-config.php vor externen Zugriffen zu schützen:

# Schützt die wp-config.php
<files wp-config.php>
Order deny,allow
deny from all
</files>

Wie bereits gesagt. Das sind nicht alle Maßnahmen, diese sind aber auch von weniger erfahrenen Nutzern schnell umsetzbar und entfalten dennoch eine große Wirkung. Wem das alles nicht reicht, der kann sich weiter in das Thema vertiefen und unter anderem die weiterführenden Tipps von Sergej umsetzen.

Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienst­leistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.

Verwandte Beiträge:

Über Vladimir

Vladimir Simović arbeitet seit 2000 mit HTML & CSS und seit Januar 2004 mit WordPress. Im Laufe der Jahre hat er diverse Fachbücher und Fachartikel publiziert.

Schlagwörter:

21 Kommentare

  1. Mit “Ordner wp-config.php” bei den Rechten meinst du sicher “wp-content”, oder? 😉
    Ansonsten habe ich noch die Login-Seite per .htaccess mit einem Passwort versehen.

    1. Hallo Tom,

      danke für den Hinweis.

      Ansonsten habe ich noch die Login-Seite per .htaccess mit einem Passwort versehen.

      Ich denke wenn man z. B. Limit Login Attempts einsetzt, dann ist das nicht mehr notwendig. Per .htaccess hat man zwar ein zusätzliches Passwort, aber das Plugin kann noch mehr: z. B. die IP sperren wenn zu viele Loginversuche stattfinden.

  2. Was soll der Tipp mit der htaccess? Das ist verlorene Energie. Wenn man auf PHP-Ebene kommt (z.B. Plugins), dann kann man die – ob sie per hta “geschützt” ist oder nicht – require’n… Wobei das nicht wirklich gebraucht wird, weil die ganzen wichtigen Daten Konstanten sind, also bräuchts in einem Plugin oder Template nur ein
    echo DB_NAME;

    Und wenn man die config im Browser aufruft, kommt eine weisse Seite. Und zwar immer.
    Das sind verschenkte Ressourcen, die der Server bei jedem verdammten Seitenaufruf verschwendet.

    Ansonsten sollte man lieber drauf hinweisen, dass bei PHP als (F)CGI-Modul 777 oder 666 überhaupt tödlich ist. 777 oder 666 ist nur bei PHP als Apache-Modul überhaupt sinnvoll und hat schwere Nebenwirkungen bei (F)CGI-Systemen.
    Davon abgesehen, wer es hinbekommt, ohne Content-Prüfung eine (PHP-) Datei im wp-contents-Ordner abzulegen, der hat auch andere Probleme auf seinem Server als die Schreibrechte. Da sollte man mal schön die Kirche im Dorf lassen, sonst wird aus dem Wunsch nach Sicherheit schnell mal Paranoia.

  3. Als Alternative zu dem Schutz mit .htaccess kann man seit WordPress 2.6 die Datei wp-config.php wo anders ablegen, z. B. eine Ebene höher (wenn man die Möglichkeit dazu hat). WP findet sie dort selbständig.

  4. @spielverderber: dein letzter Absatz relativiert deine ersten Absätze. wenn jemand Dateien auf deinen Server laden kann, um deine Variablen auszulösen, ist es eh zu spät. die .htaccess ist eh vorhanden, warum sie nicht nutzen?

  5. @Tom
    Weil alles, was in der htaccess steht, bei *jedem* Seitenaufruf abgearbeitet wird. Spätestens, wenn man viele viele viele Besucher hat, ist da jede Zeile, die man sparen kann, Gold wert. Zumal der direkte Aufruf der wp-config.php keinerlei Nutzen hat; es werden ein paar Konstanten definiert und ein paar weniger Variablen bestückt – keine Chance etwas auszugeben. Kein eval() drin, kein Echo, kein $_GET, kein $_POST, kein $_COOKIE, nichtmal ein $_SERVER. Es wird definitiv eine weiße Seite kommen beim Aufruf.

    Der Bug, bei dem eine SuSE-Build des Apaches manchmal PHP-Dateien herunterlud anstatt sie auszuführen, ist 2004 gewesen – auf einer so alten Konfiguration würde WP gar nicht mehr laufen (PHP 5.2?, MySQL 5.0).

  6. […] Die von Perun dargestellten Tipps gehen von der Wahl eines sicheren Passworts bis hin zur Änderung des Standard-Präfixes der WordPress-Datenbanktabellen. Plugins die die Anzahl der Login-Versuche begrenzen tragen ebenso zur Sicherheit bei, wie die Wahl vertrauenswürdiger Quellen für kostenlose Plugins und Themes sowie die Nutzung eines alternativen Admin-Account Namens. Zusätzlich zeigt Perun, wie man seine wp-config.php-Datei vor externen Zugriffen schützt und er erklärt, in welcher Form Schreibrechte zugeteilt werden sollten. Wie macht man WordPress sicher? Vladimir Simovic stellt auf seiner Website perun.net eine Kurzzusammenfassung der wichtigsten Sicherheitsaspekte zusammen. (Foto: Nikolay Bachiyski / flickr.com, Lizenz: CC-BY) […]

  7. Der vierte Punkt macht aber auch nur Sinn, wenn der Administrator, z.B. namens JohnDoe, nicht gleichzeitig derjenige ist, der als Autor eines Artikels angezeigt wird.

    Wenn man sich also nun einen anderen Login-Namen anstelle von admin gibt, dann sollte dieser Name entweder nicht als Artikelverfasser für alle sichtbar erscheinen oder ein anderer als der Artikelverfasser selbst sein. Kann man im Backend unter Benutzer > Bearbeiten > öffentlicher Name abändern. Alternativ kann man auch den User admin in der Datenbank durch einen anderen Namen ersetzen.

    1. @Marek,

      wenn man z. B. Limit Login Attempts installiert, dann kann man schon ab und an Versuche registrieren, die versuchen sich mit dem Nutzernamen admin einzuloggen.

  9. @spielverderber: Die htaccess liegt aber im wp-admin Ordner und wird daher nicht bei jedem Seitenaufruf überprüft. Erste wenn Inhalt aus den admin-Ordner geladen werden, wir auch das Skript geladen. Außerdem wird ein “normaler vps” sicherlich nicht wegen einer zusätzlichen htaccess in die Knie gehen. Es sei denn du hast 10000+ Besucher pro Tag – dann würde ich aufrüsten.

    Zudem ist es auch ein Schutz gegen Bruteforcing.

  10. @not
    lies bitte richtig. Der letzte Tipp will dass die wp-config.php geschützt wird. Meine liegt – ich verwende WP wohl schon zu lange? – im root der WP-Install. Würde ich diese htaccess anpassen um den Passus mit der wp-config, wäre es genau so.

    VPS stinken eh, aber das nur am Rande.

    Irgendwann, es sei mal dahingestellt, wie viele Besucher es dafür braucht, kommt man mit “einem” Server nicht mehr weiter – will man dennoch keinen zweiten, muss man optimieren. Es würde ja z.b. schon helfen, Rewrites aus der htaccess in die vhosts zu packen.

    Und dass die wp-config mit einem 403 zu versehen (nichts anderes macht der Dreizeiler) gegen Bruteforce hilft… ich lach mich gleich tot 😉

  11. @spielverderber ich rede vom wp-admin Ordner, worauf der login von wp-login.php zugreift. Wer labert was von wp-config?

    und nicht jeder hat die 100€ um einen dezidierten Server zu mieten (auch wenn ich mich recht glücklich schätzen kann: Dell PowerEdge™ R710, 12 Cores (2 × Hexa-Core-CPUs), 6 SATA/SAS HDDs a 1000GB, 124 GB RAM) Es geht hier immer noch um private WordPress Blogs und nicht um WordPress.org selber. zudem sorgen gut konfigurierte ip tables gegen zuviele requests und damit auch gegen bruteforce.

  12. Guter Hinweis von Marek (#8):
    In diesem Zusammenhang verwende ich gerne das Plugin Edit Author Slug, denn damit läßt sich der Login-Name auf jeden Fall verstecken (wenn denn das Theme direkt auf die Profilseite des Autors verlinkt).

    Und natürlich sollte der User admin – wenn er denn überhaupt aktiv bleibt – nach der Anlage eines echten Administrators höchstens noch Abonenntenrechte haben.

  13. @ not & spielverderber:
    um Missverständnisse zu vermeiden:
    meine .htaccess liegt im WP-Verzeichnis. Ist doch für entsprechende Permalinks notwendig. Und schützen tue ich die wp-login.php, nicht die wp-config.php, was in der Tat Unsinn wäre.
    Die Performanceeinbußen stimmen sicher, aber darüber brauche ich mir bei meinem “Ansturm” keine Gedanken machen. 😉
    gibt aber wie immer mehrere Wege sein Blog abzusichern.

  14. @not
    der Artikel tut das:

    # Schützt die wp-config.php
    Order deny,allow
    deny from all

    Wer keinen Dedi-Server braucht, der wird mit Webspace glücklich. Ist pflegeleicht und performt besser. VServer haben eigentlich ausschliesslich Nachteile.

  17. […] WordPress und Sicherheit: kleine Zusammenfassung – Eine aktuelle Zusammenstellung von Plugins, Tipps und Code-Snippets. […]

  18. Schöner Artikel mit vielen wertvollen Tipps, auch in den Kommentaren!

    Mir leuchtet nicht ein, warum die Änderung der Tabellen Präfixe WordPress sicherer machen soll. Die Tabellen sind doch nur relevant, wenn man Zugriff auf die Datenbank hat und dann ist es eh schon zu spät. Dann helfen auch geänderte Präfixe nicht. Die entscheidenden Tabellen findet dann jeder. Oder sehe ich das falsch?

    Grundsätzlich machen natürlich geänderte Präfixe Sinn. Vor allem wenn man den Webspace und WordPress als Multi Site CMS nutzen möchte.

  19. […] fertig installiertes und mit Plugins erweitertes WordPress-Blog ist ein komplexes System, das aus Sicherheitsgründen immer auf dem neuesten Stand gehalten werden sollte. Wer kein gemanagtes Weblog-System mieten möchte, kann entweder Kapazität auf einem […]

Kommentare sind geschlossen.