Warum ich keine All-in-one-Sicherheitsplugins mag

WordPress ist nicht sicher! Gebetsmühlenartig wird diese falsche Aussage wiederholt. Sie wird dadurch aber nicht wahrer. WordPress ist je nach Messmethode gleichauf oder tendenziell sogar sicherer als andere CMS. Das Problem sind viel eher schlechte oder nicht aktualisierte Plugins und Themes, zu einfache Passwörter und veraltete Installationen. Aber mehr Sicherheit, dafür gibt’s doch ein Plugin! Und dann fängt der Ärger an.

Grund #1: Zu wenig Informationen

„Soll ich die XMLRPC-Schnittstelle blockieren?“ – Wer würde nicht mit Ja antworten, wenn ein Sicherheitsplugin danach fragt und ein Ignorieren eine hässliche orangene Warnung zurück lässt? Zu selten wird aufgeklärt, warum diese Schnittstelle ein Problem darstellt und wozu sie genutzt wird. Ist mir der Komfort einer App/eines Offline-Bloggingtool vielleicht das erhöhte Risiko wert, dass dadurch entsteht, das ca. 500 Login-Versuche gleichzeitig über diese Schnittstelle abgefeuert werden können?

Grund #2: Funktionen mit zu wenig Einstellungsmöglichkeiten

Natürlich sind Backups wichtig. Deshalb sollte auch ein richtiges Backup-Plugin genutzt werden. Automatisiert – auf einen anderen Server – im Idealfall. Nur bieten die All-in-one-Tools das selten an. Wenn eine Backup-Funktion jedoch keine Ordner ausschließen kann (z.B. die Backups vom echten Backup-Plugin) oder nicht anständig hinter sich aufräumt und die ganzen Backups sich ansammeln bis der Webspace voll läuft, dann schadet das Feature mehr als es nützt.

Grund #3: Security by Obscurity

Verstecken, Umbenennen, Verschleiern – immer wieder versuchen „Sicherheits“-plugins so einem Sicherheit vorzugaukeln. Bestimmte Funktionen machen aber nur dann Sinn, wenn andere Funktionen auch aktiv sind, da sie sonst die angeblich versteckten Informationen anderswo preisgeben. Gibt es All-in-one-Tools mit einer Konsistenzprüfung der Einstellungen? Ich befürchte nicht …

Grund #4: Performance

Scanner, Web-Application-Firewall, usw. usf. – alles schön und gut, aber wenn am Ende meine Site kaum bedienbar im Backend ist, dann schalte ich das Ganze aus Notwehr doch wieder ab und meine „Sicherheit“ ist im Ar…

Grund #5: Du hast zu wenig Rechte!

Ein automatisierter Test ist nur so gut, wie seine Programmierer. Wenn das Plugin nur testet, ob Ordner die Rechte 755 haben und Dateien 644, dann mag das zwar eine gute Faustregel sein, aber die mit weniger Rechten ausgestattete .htaccess oder wp-config.php mit einer Warnung zu versehen ist dann schon wieder etwas, was den Laien nachhaltig verwirren kann.

Grund #6: Jeder macht mal Fehler

Ja, jedem kann das passieren. Aber bei einem Sicherheitsplugin ist es mehrfach schlimm. Es soll uns beschützen, aber sperrt uns aus, weil versehentlich die eigene IP gesperrt wurde, oder es löscht beim Updaten der .htaccess den WordPress-Block oder Worst-Case-Szenario: es hat selbst eine kritische Sicherheitslücke und stellt so ein Einfallstor dar.

Mein Hinweis an jeden interessierten Laien:
Die meisten Funktionen der All-in-one-Plugins kann man selber umsetzen. Vorteil: Bei der Recherche, wie das genau geht, lernt man viel dazu und hat am Ende eine sichere Website ohne den ganzen Overhead eines All-in-one-Plugins.

Ein All-in-one-Sicherheitsplugin einzusetzen ohne zu verstehen, was es macht oder was das für Konsequenzen hat, ist fahrlässig. Ungefähr zu vergleichen mit einer geladenen, entsicherten Pistole zur Einbrecher-Abwehr, die im Kinderzimmer deponiert wird.

P.S.: Ich mag eigentlich keine Listen. Sicherheitslisten schon gar nicht. Sie erzeugen den Eindruck von Vollständigkeit. Wenn ich diese 10, 12, 20 Dinge abgehakt habe, dann bin ich sicher. Nein, bist du nicht. Sicherheit ist ein stetiger Prozess. Daher ist diese Liste auch bestimmt nicht vollständig. Ergänze sie gerne in den Kommentaren. Oder widerspreche mir 😉

4 Antworten auf Warum ich keine All-in-one-Sicherheitsplugins mag

  1. Im Juli hat Andrey “Rarst” Savchenko einen sehr lesenswerten Beitrag über „WordPress‘ Kreuzzug gegen technische Verantwortung“ veröffentlicht (https://www.rarst.net/wordpress/technical-responsibility/). Mit dem von WordPress sehr vage formulierten Claim „Democratize Publishing“ würde gegenwärtig ein schiefes Bild erzeugt, dass sich der Anwender nicht weiter mit technischen Details auseinandersetzen müsse. Dadurch würde zwar das rasante Wachstum des World Wide Web befeuert, aber es entstünden auch mehr Websites, die langsam, fehlerhaft, schwer lesbar, nicht barrierefrei und unsicher seien. Andrey kommt zu dem Schluss, das es völlig OK sei, sich nicht mit technischen Aspekten beschäftigen zu wollen – nur solle man sich dann besser ein Account bei Medium.com holen.

    „Ein All-in-one-Sicherheitsplugin einzusetzen ohne zu verstehen, was es macht oder was das für Konsequenzen hat, ist fahrlässig.“ – völlig richtig. Nur entspricht es nicht dem schiefen Bild, alle könnten, auch ohne technische Vorkenntnisse, ganz einfach eine Website (oder gleich „einen kleinen Webshop“) betreiben.

    Den Rat, sich doch erst einmal ausgiebiger mit WordPress zu beschäftigen oder einen Dienstleister zu beauftragen (der dafür auch noch Geld haben möchte, oh weh), mag nach meiner Erfahrung niemand hören. Warum auch? WordPress ist dank One-Click-Installation beim Webhoster in wenigen Minuten installiert und für alle Lebenslagen stehen tausende Plugins zur Verfügung. Contact Form 7, Yoast SEO, W3 Total Cache und eben auch Wordfence sind weltweit millionenfach installiert und haben beste Bewertungen. Was soll daran verkehrt sein? 😉

    Joost de Valk, der Entwickler des Yoast SEO-Plugins, erzählte in einem Vortrag, dass die meisten Anwender sich nicht die Mühe machen würden, sich mit den Einstellungsmöglichkeiten eines Plugins näher zu beschäftigen. Anwender würden davon ausgehen, dass ein Plugin „Out of the Box“ funktionieren würde (was bei einem SEO-Plugin ziemlich illusorisch ist).
    Das Sicherheits-Plugin WordFence bietet im Backend 12 Seiten mit Einstellungsmöglichkeiten, die Seite „Options“ über 80 Eingabefelder. Wieviele Nutzer sich die Zeit nehmen und wirklich jede Einstellung durchgehen und hinterfragen, kann sich jeder selbst ausmalen.

    „Sicherheit ist ein stetiger Prozess.“ Richtig. Das setzt aber voraus, dass sich Anwender überhaupt mit Sicherheitsaspekten beschäftigen (oder jemand, der sich damit auskennt, beauftragen) wollen. In der Praxis sieht es aber wohl in vielen Fällen anders aus. Da ist dann das Sicherheits-Plugin die bequemere Lösung. „Und schaden kann das doch nicht.“ – Oder doch?

  2. Vielen Dank für deinen großartigen Kommentar! Eigentlich könnte das genau so im Artikel stehen. Wir stehen genau in diesem Spannungsfeld: Zum einen sollte alles einfach sein und out-of-the-box funktionieren und zum anderen verlieren wir dadurch aber immer mehr Wissen über die Zusammenhänge dahinter. WordPress ist halt leicht zu lernen, aber scher zu meistern … eine allgemeingültige Lösung habe ich auch nicht, aber ich habe so stetig dazugelernt und bin so zu meinem Wissen von heute gekommen.

  3. Das Ganze ist ein schwieriges Feld. WordPress ist nunmal ein System, das durch seine simple Installation, Bedienbarkeit und nicht zuletzt den unschlagbaren Preis Laien anzieht.
    Nun kann aber niemand realistisch gedacht erwarten, dass diese sich mit Dingen auskennen oder auseinandersetzen, die noch nicht mal alle Webentwickler im Detail verstehen. Sei es nun SEO oder Sicherheit in allen seinen Nuancen.
    Letztendlich sehe ich daher WordPress selbst in der Pflicht, gewisse Sicherheitsstandards selbst einzuführen. So fände ich die Limitierung der Login-Versuche eine sinnvolle Erweiterung, die meiner Meinung nach in den Core gehört.
    Denn ja, WordPress ist an sich nicht unsicherer als andere CMS. Aber es ist dank seiner Popularität übermäßig vielen (automatisierten) Hackerangriffen ausgesetzt.

    • Im Prinzip stimme ich dir zu: WordPress zieht Laien an und möchte ja auch laut Philosophie die technische Komplexität möglichst vom Anwender verbergen, aber die Einführung von Sicherheitsstandards wurde schon mehrfach versucht und es ist nicht so leicht sich da auf eine gemeinsame Linie zu einigen. Das Sperren vom Login basiert auf IP-Adressen und das ist nicht problemfrei. Ich habe mal für einen großen Kunden hier in Hamburg eine Site aufgesetzt und so ein Plugin genutzt. Da die Zählung der fehlgeschlagenen Versuche pro IP passiert, war nach drei Fehlversuchen im gesamten Haus (bei hunderten/tausenden Mitarbeitern nicht ungewöhnlich) dann Schluss und die Site hat niemanden mehr reingelassen. Das ist technisch schnell gelöst, aber nur für jemanden, der weiß was passiert. Für einen Laien wäre hier auch Schluss. Daher glaube ich nicht, dass so ein Loginschutz standardmäßig kommen wird.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.