WordPress & Webwork

WordPress und Sicherheit: kleine Zusammenfassung

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.

21 Reaktion(en)

  1. Tom

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

    1. Perun

      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. spielverderber

    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. Acky

    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. Tom

    @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. spielverderber

    @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. Pingback: WordPress Security-Tipps: So machst Du das CMS sicher » t3n News

  7. Marek

    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. Perun

      @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.

  8. Pingback: Webseiten mit eingebauter Sicherheit ~ BizBlog

  9. not

    @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. spielverderber

    @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. not

    @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. MB

    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. Tom

    @ 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. :wink:
    gibt aber wie immer mehrere Wege sein Blog abzusichern.

  14. spielverderber

    @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.

  15. Pingback: Linkhub – Woche 29-2011 | PehBehBeh

  16. Pingback: WordPress und Sicherheit: warum man Standardadmin löschen sollte | WordPress & Webwork

  17. Pingback: metafakten // metalinks am 14. Oktober 2011

  18. Andreas

    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. Pingback: Wordpress Hosting-Server - WP-Zone

Die Kommentare in diesem Beitrag sind geschlossen.