Thread-Starter
onlaie
(@onlaie)
Funktionieren beide nicht.
Ersters tut gar nichts sperren;
Zweiteres zu viel, sperrt den korrekten Adminzugang!
Ich werde halt noch einige durchtesten …
Thread-Starter
onlaie
(@onlaie)
So, „Limit Login Attempts Reloaded“ ist doch DSGVO-konform (evtl. sogar mehr als andere) und wichtiger: Es tut, was es soll!
Prima, wenn du das finden konntest. Hast du auch eine Quelle dazu (für andere die danach suchen)? Und danke fürs gelöst-markieren 🙂
Thread-Starter
onlaie
(@onlaie)
Eine Quelle … naja, eigentlich stehts eh auf der Site https://de.wordpress.org/plugins/limit-login-attempts-reloaded/ > Funktionen (kostenlose Version), das es DSGVO-konform wäre.
Der Betreiber, für den ich so einen Login Limiter suchte, las aber zuerst den Supportbereich, wo man sich auch mal über deren „Mikro-Cloud“ Gedanken machte: https://wordpress.org/support/topic/gdpr-conformity-3/
Das hat den verunsichert, daher sollte ich ein anderes nehmen. Doch naja, das lief nicht so toll.
Aber: Mir genügte es dann, als ich unter den Einstellungen des Plugins > „Allgemeine Einstellungen“ die Optionen „DSGVO-Konformität“ und „DSGVO-Nachricht“ fand. Das ist schon mal gut so.
Und: Man muss als Betreiber ja nicht bei der „Mikro-Cloud“ mitmachen. Solange man das Plugin als freie Version aktiv hat und sich nicht an diese Cloud hängt, solange passiert mal gar nichts. Denke ich.
Letztlich liegt aber schon ein Interesse vor, dass man die Site vor zu aufdringlichen Leuten/Bots schützt und das man diese Daten (eh ohne Personenbezug) irgendwo speichert. So ähnlich verstehe ich auch die abschließenden Einträge in besagten Kommentar …
Dzt. lassen wir es ohnehin nur auf einer Testsite laufen, bisschen beobachten, was sich so tut und wie das Plugin mit umgeht.
Interessant ist dabei: Trotz das diese Staging-Testsite serverseitig im Wartungsmodus ist und trotz das noch „Password Protected“ läuft – dennoch schlagen Loginversuche auf die wp-login.php auf …
Verstehe 🙂 Ein Wartungsmodus begrenzt sich auf die öffentliche Website. wp-login.php gehört nicht da, schließlich muss man ja noch ins Backend kommen.
Ein effektiverer Schutz wäre übrigens AuthBasic. Das hält die Zugriffe generell ab, da sie ein serverseitiges Passwort vor dem WordPress-Login erfordern. Es muss jedoch serverseitig auch eingerichtet werden um sauber zu funktionieren. Man muss dabei auch die /wp-admin/admin-ajax.php ausklammern vom Schutz, da die auch im öffentlichen Web genutzt wird.
Thread-Starter
onlaie
(@onlaie)
Stimmt.
Und egal wie man alles aussperrt, versteckt – die von außen ansprechbaren Dateien sind ja noch da.
AuthBasic hatte man dort vorher, doch damit war ein reibungsloser Betrieb des Membership-Plugins nicht zu machen. Auch harmlose Abonnenten wurden mit dem serverseitigen Backens-Schutz konfrontiert. Ja, wir habens mit Ausnahmen (für das Plugin) versucht, doch das ging nicht wirklich.
Also kam AuthBasic weg und die evtl. geringere Sicherheit soll nun zT. ein bisschen mit Login Limit (und 2FA/MFA) ausgeglichen werden.
Dazu wurden aber eh auch noch die REST Endpunkte mit den Benutzern, XMLRPC, u. weitere Kleinigkeiten wegversteckt …
Den Rest muss die WAF usw. des Hosters machen …
