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 …

Funktionieren beide nicht.
Ersters tut gar nichts sperren;
Zweiteres zu viel, sperrt den korrekten Adminzugang!

Ich werde halt noch einige durchtesten …

Danke, das liest sich sehr sicher!

Danke auch bez. der Hinweise im anderen Thema zu ?author=1 und der REST API (s. Eingangspost „… Ebenso habe ich den REST API Endpunkt users blockiert …“)

Also wenn man die ID der Benutzer unfallfrei ändern kann, dann würde ich das sogar noch vor dem Einsatz von diesem Script, eigentlich MU Plugin, machen.
Darf man das echt direkt in der DB machen? Wenn ja, reicht es die users Tabelle, Feld ID zu ändern, oder sollte man das noch wo berücksichtigen?
Eigenantwort: Leider reicht das nicht, danach ist dem geänderten Benutzer nichts mehr möglich …

• Diese Antwort wurde vor 3 Monaten von onlaie geändert.

Nach einigen Maßnahmen und Beobachtung der Lage, folgender Nachtrag:

Also honeypot hilft hier nichts; auch weil es, wie vermutet, den Link nicht verändert.
Ebenso erfolgt kein Logging der Zugriffsversuche oder was auch immer dieses Plugin loggen sollte.

Die XML-RPC Schnittstelle ist seit vielen Jahren serverseitig deaktiviert

Der AuthBasic-Schutz half nichts

Im SEO-Plugins ist nichts bez. Sozial-Media hinterlegt.
Auch taucht keiner der Benutzenamen im Quelltext keiner Seite auf.

Sicherheitsplugins haben wir 3 probiert, doch keins konnte die Flut von Passwort zurücksetzen eindämmen.
Auch eine temp. Abschottung mittels „Password Protected“ brachte nichts. Wie auch?

Inzwischen gehen den Redakteuren und mir schon die Ideen aus, wie wir die Benutzer umbenennen sollen.
Aber es hilft eh nichts, irgendeine Lücke verrät die nach einigen Stunden Ruhe gleich wieder …

Somit kann man da scheinbar nichts gegen machen, außer ignorieren.

Markiere als gelöst, weil WP selbst können wir nicht reparieren, selbst wenn man die Lücke finden würde.

Danke für die umfangreiche Info!

In wie weit hilft es, „das öffentlich sichtbare „Passwort vergessen“-Formular “ zu verstecken? Wird damit auch wp-login.php?action=lostpassword verändert?

XMLRPC-Schnittstelle:
Dzt. ist folgender Code in der functions.php:

add_filter( 'xmlrpc_enabled', '__return_false' );
   /* Den HTTP-Header vom XMLRPC-Eintrag bereinigen */
   add_filter( 'wp_headers', 'AH_remove_x_pingback' );
    function AH_remove_x_pingback( $headers )
    {
    unset( $headers['X-Pingback'] );
    return $headers;
    }

Ob das überhaupt was hilft?
Weiters hat auch der Hoster (Site ist auf Nginx) etwas bez. XML deaktivieren in die Serverkonfiguration eingetragen.

AuthBasic-Schutz: Gute Idee, das mache ich aber auch mithilfe des Hosters (das kann der einfach machen, hatten wir schon mal bei einem anderen Projekt – wobei: Gegen den Passwort rücksetzen Terror hilft das nichts.). Aber ansonsten ist es schon eine ratsame Sache – Danke!

SEO-Plugins tragen z.B. den Autor gerne in Meta-Daten ein:
Ah, das hatte ich nicht am Schirm, das prüfe ich noch nach!

PS: Nein, es ist kein Sicherheitsplugin installiert. Ua. weil man oft liest, dass diese riesigen Dinger nicht einfach automatisch schützen, nur weil man alles anklickt. Und die bisher angesehenen überfordern einem echt.
Daher setzte ich bisher gerne auf kleine Lösungen wie eben das Thema XML RPC zeigt.

Bei 6.8.3 ist „6.8“ die Hauptversion, die „.3“ steht für die Bugfix-Version.

Genauso habe ich das bisher verstanden.

Aber dann verstehe ich den Satz noch weniger:

Wenn WordPress 6.8.3 genutzt wird, findet kein Update auf 6.9.1 statt. Würde es eine 6.8.4 geben, würde dieses eingespielt werden.

Egal, wir werden alles wieder auf manuell stellen. Dann gibts kein Ratespiel, was wer automatisch oder nicht macht.

define( ‚WP_AUTO_UPDATE_CORE‘, false );

ist nicht drin.

Hier die Plugins einer der Sites, wo noch immer kein Update durchgeführt wurde:

# Must-Use Plugins
- Keine Daten verfügbar

# Aktive Plugins
- Advanced Database Cleaner - 4.0.6
- Advanced iFrame - 2025.10
- Category Posts Widget - 4.9.22
- Complianz - Terms and Conditions - 1.2.8
- Disable & Remove Google Fonts - 1.8.2
- Disable Gutenberg - 3.3
- Download Monitor - 5.1.7
- FooGallery - 3.1.11
- My Sticky Bar - 2.8.6
- Real Cookie Banner - 5.2.14
- Regenerate Thumbnails - 3.1.6
- SEOPress - 9.5
- Solid Mail - 2.2.2
- Supaz Easy Background - Easy way to add parallax image or video backgr - 1.0.2

# Inaktive Plugins
- Advanced iFrame custom folder - 1.0

Die anderen Instanzen nutzen nicht WordPress 6.9 sondern sind noch bei einer älteren Version.

Ja, stimmt! Die eine hier ist noch auf 6.8.3. Dh. es sind schon frühere Updates nicht erfolgt.
Dh. hier liegt irgendwo das Problem …

Die Updates werden vom Hosting gesteuert

Nein, definitiv nicht.