Multisite-native Sicherheit: Ein Block, netzwerkweit
Die Sicherheit von WordPress Multisite weist eine strukturelle Schwachstelle auf: Wenn ein Angreifer eine Unterseite per Brute-Force-Angriff angreift, bleibt dies für die anderen Seiten unsichtbar. ReportedIP 2.0 schließt diese Lücke, indem es einen einheitlichen Bedrohungsstatus für das gesamte Netzwerk nutzt – eine Sperrung der IP-Adresse gilt somit überall.
In diesem Leitfaden wird das reine Netzwerkmodell erläutert, wie sich standortübergreifende Angriffe häufen und welche Einstellungen Website-Administratoren ändern können und welche nicht.
Was ist ReportedIP ?
ReportedIP ist ein umfassendes WordPress-Sicherheits-Plugin – mit 12 Angriffssensoren, vier 2FA-Methoden, progressiver Blockierung und opt-in-basierten Bedrohungsinformationen aus der Community – und seit Version 2.0 vollständig Multisite-kompatibel. Der gesamte Funktionsumfang ReportedIP gilt netzwerkweit.
Aktivierung nur über das Netzwerk, ein gemeinsamer Bedrohungsstatus
Bei Multisite wird das Plugin nur netzwerkweit aktiviert – die Aktivierung auf Einzelseitenebene wird von WordPress ausgeblendet. Alle sieben Tabellen werden verschoben nach $wpdb->base_prefix, sodass eine einzige Entscheidung für das gesamte Netzwerk gilt: Website-übergreifende Brute-Force-Versuche werden in einer zentralen Stelle zusammengefasst attempts Zeile und ein Eintrag in der blocked Die Tabelle sperrt die IP-Adresse sofort für alle Unterseiten. Ein Botnetz, das zwischen den Unterseiten hin- und herspringt, wird als eine einzige Kampagne gewertet und nicht als eine Reihe einzelner Störfälle.
Was Super-Administratoren und Website-Administratoren jeweils verwalten
Super-Admins verwalten die Netzwerkeinstellungen und müssen zwingend die 2FA einrichten (die reportedip_hive_2fa_enforce_super_admins (Standardwerte aktivieren). Site-Administratoren einer Unterseite erhalten eine schreibgeschützte Ansicht für „Status“ und „Protokolle“ sowie eine einzige Seite mit 2FA-Site-Einstellungen, auf der genau zwei Einträge bearbeitet werden können: den site-spezifischen Frontend-2FA-Slug und Zusatzstoff Durchsetzungsrollen – Ein Site-Administrator kann eine Rolle zur 2FA-Durchsetzung hinzufügen, darf jedoch keine Rolle entfernen, die vom Netzwerk vorgeschrieben ist.
Das Cookie für vertrauenswürdige Geräte wird erweitert auf SITECOOKIEPATH, sodass eine einzige Entscheidung, „diesem Gerät zu vertrauen“, für das gesamte Netzwerk gilt. Cron wird nur auf der Hauptseite geplant (geschützt durch is_main_site()), um doppelte Durchläufe pro Unterseite zu vermeiden.
Die Migration erfolgt transparent
Bei einer Einzelstandort-Installation, die auf Version 2.0 aktualisiert wird, erfolgt die Migration automatisch beim ersten Besuch des Administrators – die einzige Schemaänderung ist eine ALTER TABLE … ADD COLUMN blog_id Standardwert 1, keine Datenübertragung. Dediziert Schema, Migration_Manager und Option_Routing Service-Klassen vermitteln jeden Multisite-relevanten Zugriff, und die Änderung wird bei jedem Commit durch 435 Single-Site- sowie 19 Multisite-PHPUnit-Tests abgedeckt.
Planbeschränkungen für mehrere Domains
Der Netzwerkschutz ist kostenlos, doch die Funktionen für Managed Relay und das Dashboard für mehrere Standorte sind vom gewählten Tarif abhängig: 3 Domains im Professional-Tarif, 15 im Business und eine individuelle Obergrenze im Enterprise-Tarif. Die lokale Firewall, die Sensoren und die Zwei-Faktor-Authentifizierung (2FA) funktionieren unabhängig vom gewählten Tarif netzwerkweit.
Verwandte Anleitungen
- Lokaler Schutz vs. Community-Netzwerk über ein Netzwerk
- Die progressive Block-Leiter, netzwerkweit angewendet
- Der Einrichtungsassistent und das Dashboard bei Multisite
Die Dokumentation zum WordPress-Plugin behandelt die Netzwerkkonfiguration. Sehen Sie sich die vollständigen AnleitungenReportedIP an oder lesen Sie die Dokumentation zur Routing-Ebene auf GitHub.