WordPress-Adminbereich absichern

Sergej Müller hat vor mehr als vier Wochen in seinem Weblog einen Artikel mit dem Namen Sicherheit in WordPress: 10 Schritte zum Schutz des Admin-Bereichs verfasst. Nun wurde dieser Artikel ins englische übersetzt und auf smashingmagazine.com veröffentlicht.

Allerdings frage ich mich – der Kommentar Nr. 40 auf smashingmagazine brachte mich drauf – ob die physikalische Verlagerung des WordPress-Ordners überhaupt eine zusätzliche Sicherheit mit sich bringt?

Weil zum einen die Themes im Quelltext referenziert (“verlinkt”) sind und zum anderen sichauch viele Plugins mit dem richtigen Pfad verewigen: zum einen weil sie auf sich selbst verweisen und/oder weil sie auf die verschiedenen Javascripte im wp-Includes-Ordner verweisen.

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:

11 Kommentare

  1. >> ob die physikalische Verlagerung des WordPress-Ordners überhaupt eine zusätzliche Sicherheit mit sich bringt?

    Das tut sie mit Sicherheit. Wie ich im Artikel schrieb, sind das alles Stolpersteine, die einem Angriff auf den Administrationsbereich gelegt werden. Wird der Ordner auf der Platte umbenannt, schon weicht es dem Standard ab – das ist schon der wichtigste Punkt. Klar kann man den Pfad rauskriegen – zudem auch sehr leicht – doch dafür muss der Angreifer einen anderen, umständlicheren, ungeplanten Weg gehen. Wenn der Angriff maschinell geschieht, dann muss ins Script eine zusätzliche Abfrage rein, die falls Systemdateien nicht da, nach dem Pfad fahnden soll. Klar, auch hier kein Hexenwerk, doch nicht viele Hacker werden sich den Aufwand leisten wollen. Darum geht es: Risiko minimieren.

    Ist man aber wirklich im Visier der Räuber, da werden manuelle Handgriffe gezielt eingesetzt und mit professionellen Werkzeugen gearbeitet. Da bringen auch diese 10 Tipps nicht viel. Aber die machen es einem nicht leichter. Und das ist das Ziel.

  2. Hey Perun!
    Wenn Plugins mit dem verschieben des Pfades ein Problem haben, sind sie nicht sauber programmiert…. Das umbenennen des WP-Ordners soll meiner Meinung nach auch keinen Schutz gegen böswillige Menschen, sondern eher gegen suchende Roboter bieten….

    gruß, micha

  3. @micha149,

    mit dem Hinweis auf die Plugins ging es mir nicht darum ob die Erweiterungen Probleme mit der neuen Pfadstruktur haben sondern, dass die Plugins im Quelltexte die neue Pfadstruktur ausgeben.

    @Sergej,

    Darum geht es: Risiko minimieren.

    Ich verstehe. Das wird es auf jeden Fall machen.

    Ich würde deine Liste um eine Kleinigkeit ersetzen und zwar dass man sich einen Autoren-Account einrichtet falls man des öfteren unterwegs von anderen Rechnern schreibt, damit man nicht den Admin-Account einsetzt.

  4. Perun, das mit dem Autor hast du sicherlich Recht. Ich hatte zwar im Artikel erwähnt (#5), dass man sich einen zusätzlichen Autor-Account anlegen soll, allerdings bringe ich diesen Schritt mit dem Separieren von “Beiträgeschreiben” und “Administration” in Verbindung, damit der Nutzername eines Administrators wirklich Inkognito bleibt.

  5. Bei Wohnungstüren hindert ein offensichtliches, zusätzliches Schloss auch nicht immer, den Einbrecher abzuwehren. Es ist aber zusätzlicher Aufwand, der dafür sorgt, dass der Einbrecher einfach mehr oder länger zu tun hat. Wenn er wirklich rein will, schafft er das auch. Braucht aber mehr Zeit und genau die ist ja entscheidend.

    Evtl. denkt er sich “Och, ich will eigentlich nur meine Nase für 10 Euro füllen. Da will ich mir nicht so einen Aufwand betreiben.” 😉

  6. Ich bin immer noch am überlegen ob der Schritt mit dem Adminordner wirklich so nützlich ist für meinen Blog oder meine Blogs im allgemeinen. Hatte bisher noch nie einen Angriff und von daher stellt sich mir die Frage nach der Relevanz für mich.

    Für mich reicht es bisher, wenn ich meine Passwörter schön komplex halte, Wöchtenlich Backups mache und local automatisch per cronjob sichern lasse.

    Dann noch der Schutz durch meinen 1A Hoster, da kann nicht viel passieren, zumindest mir nicht.

  7. Ich danke einfach mal für den Link zum Artikel. Den werde ich auf jeden Fall mal studieren.
    Ob für mich relevant oder nicht … Sicherheit ist nie etwas Schlechtes und der Aufwand hält sich ja nun auch in Grenzen. 🙂

  8. Der wichtigste Punkt ist der letzte: Immer up2date, dann ist man vor den meisten automatisierten Angriffen schon sicher. Dazu .htaccess username/passwort Schutz vor den Adminbereich und regelmäßige Backups. Dann kann man ruhig schlafen. Die anderen Vorschläge halte ich für leicht übertrieben, da sie viel unnötige Arbeit verursachen, die man auf andere Art und Weise wesentlich produktiver verwenden könnte.

  9. Mosche!

    Ich sehe das wie Sergej: Stolpersteine, nicht mehr und nicht weniger, denn nichts ist unhackbar, sondern lediglich eine Frage der Zeit. Diese Erkenntnis ist mir aus C64er-Zeiten lebhaft bekannt, als immer mal wieder vom Superkopierschutz die Rede war. (Und wer hätte damals in den 80ern gedacht, das Günni mal in den Bau gehen müßte nicht nur um Mandanten zu besuchen? :lol:)

    Analog zum WP-Beispiel: Weshalb wirken simple “Was ergibt X+X?”-Abfragen (noch) so hocheffektiv etwa bei vb-Boards wider Spam-Bots? Weil sie abseits der Regel namens Captcha-Schutz laufen und nicht, weil sie unüberwindliche technische Hürden markierten: die Bots sind aufs Geschichten abseits des Standards nicht eingestellt und da zu wenige Foren eine zusätzliche Abfrage eingebaut haben, lohnt es sich wohl auch noch nicht für die Bot-Coder, den Nachbesserungs-Aufwand zu betreiben. Ähnliches gilt auch für Viren-Coder, die sich auf Windows eingeschossen haben, und das Ignorieren von MacOS und Linux.

    Punkt 11 hat Sergej jedoch unterschlagen: Regel Nr. 1 ist und bleibt für mich das gute alte Backup. Geht man davon aus, daß Hacker/Skript-Kiddies den Blog nicht nur um des Hackens willen knacken wollen, hilft am Ende allenfalls noch ein Backup. Hacken ist das eine, eine aktuelle Datensicherung das andere. Für mich ist das wie eine sicher zahlende Versicherung. Diebstahl ist das eine Ärgerliche, zu wissen jedoch, daß man das baugleiche Auto ohne viel Aufhebens wieder erhält das andere.

    Aus Sergejs Posting lese ich auch heraus, daß man als Sicherheits-Freak es nicht unterhalb eines vServers tun sollte. Auch das ist eines meiner Mantras. Man muß kein Linux-Freak sein, um die paar hier genannten Schritte durchzuführen, dazu ist sein Posting schon viel zu DAU-kompatibel und nutzerfreundlich gehalten.

    Abschließend noch mein Punkt 12: Dokumentation. Druckt euch jedesmal das Tutorial samt vorgenommener Änderungen aus, sonst gibt es Monate (Wochen/Tage/Stunden) später ein böses Erwachen wenn es heißt: öhm, was hatte ich hier denn noch mal gemacht? Zu welchem Blog gehört die SQL-Datenbank? Kann ich die bedenkenlos löschen? :mrgreen:

    Maßnahmen abseits des Mainstreams haben nämlich den Nachteil, daß es nur einen gibt, der sie versteht – sofern das Gedächtnis hält (ich halte jede Wette dagegen, denn kryptische Präfix-Änderungen dienen gerade auch dazu, dem Gedächtnis ein Schnippchen zu schlagen) oder eben die Dokumentation stimmt. Bei mir geht kein Blog ohne Dokumentation hoch, nicht einmal ein simpler “Ich muß die Beta unbedingt testen!”-Blog.

    Viele Grüße aus Frankfurt + schönen Tag + danke für den Artikel,

    René

Kommentare sind geschlossen.