Während Dir das Thema WP-Sicherheit Schweißperlen auf die Stirn treibt, werde ich bei der Idee eines selbstgebastelten Schutz nervös.
WordPress ist nicht per se unsicher, aber es macht Sinn, das Login-Formular zusätzlich gegen Brute Force-Angriffe zu schützen. Dazu gibt es eine Reihe von Plugins, z.B. Login Lockdown oder Two Factor Auth.
Grundsätzlich gilt, dass Core-Dateien nie verändert werden sollten, zumal diese Änderungen spätestens beim nächsten (automatischen!) Update überschrieben werden und damit mögliche „Sicherheitsmechanismen“ außer Kraft gesetzt werden. Im ungünstigen Fall erhält man einen White Screen of Death, z.B. weil Funktionsnamen doppelt verwendet werden.
Security-Plugins können sinnvoll sein, vorausgesetzt der Anwender kann einschätzen, um was es bei dem zahlreichen Konfigurationsmöglichkeiten überhaupt geht. Oft wiegt sich aber der Anwender in einer trügerischen Sicherheit, die z.B. das Verstecken der WordPress-Version überhaupt nicht bieten. Übrigens haben gerade die Sicherheits-Plugin recht häufig Sicherheitsschwachstellen aufgewiesen.
Für den Einstieg möchte ich Dir gerne den passenden Artikel aus dem Codex empfehlen.
Vielen Dank für deine schnelle Antwort, Bego 🙂
Hab mal in den Artikel geschaut und denke, das dürfte mir etwas weiter helfen. Danke
Hallo zusammen,
meine persönliche Meinung: Installation und Plugins aktuell halten, gutes Passwort und eine Login-Begrenzung (wie bereits o.g Login Lockdown oder ähnliches) reicht für die allermeisten Szenarien.
Wenn man dann auch noch die üblichen Security-News verfolgt, dann ist man ausreichend gerüstet.
Aber eine Garantie gibt es nicht.
Grüße
Lösung: Nicht nur die php-Datei sondern einfach das komplette wp-admin Verzeichnis schützen.
Bei manchen Webhostern kann man das sogar bequem über deren Benutzeroberfläche machen („Verzeichnisschutz“).
Die Behauptung, wordpress sei „per se nicht unsicher“ bedeutet natürlich im Umkehrschluss, dass es auch nicht „per se sicher“ ist und wird durch gleichzeitiges posten eines seitenlangen Artikels zur Absicherung entkräftet.
wordpress sei „per se nicht unsicher“ bedeutet natürlich im Umkehrschluss, dass es auch nicht „per se sicher“ ist …
Hä? – Was für ein Unfug. 🙂
Mit „per ser nicht unsicher“ ist zum Beispiel gemeint, dass das Back End mit einer Nutzer-Anmeldung gesichert ist (sicher), was aber nichts hilft, wenn der Nutzer („Isch hab da eh nix kritisches uf’m Server…“) als Nutzername „admin“ und als Passwort „password“ verwendet (unsicher). Dazu gibt es auch Blogbeiträge, die eindringlich vor solchem Unfug warnen – nur wird durch den Blogbeitrag doch nicht die Sicherheit von WordPress entkräftet?
Bevor du hier behauptest, WordPress sei unsicher, solltest du dich vielleicht mal etwas eingehender mit den Sicherheitsaspekten beschäftigen (für institutionelle Anwender gibt es dafür auch ein Whitepaper) und auch nicht pauschal eine Sicherung vorschlagen, die dann auch noch Websites teilweise unbrauchbar machen kann.
„per se nicht unsicher“ bedeutet nun mal, dass es nicht „per se sicher“ ist.
Die „Lösung“ war keine „pauschale Sicherung“ sondern die Antwort auf die allererste Frage warum das Umbenennen und der Verzeichnisschutz nicht funktioniert.
Wer die Ajax-Funktionen braucht, der trägt einfach folgendes in die .htaccess (im wp-admin Verzeichnis nicht im root-Verzeichnis!) ein:
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
