WordPress-Multisite-Sicherheit: ein ganzes Netzwerk härten
WordPress-Multisite-Sicherheit scheitert an anderen Stellen als die Sicherheit einer einzelnen Website: Eine gemeinsame Codebasis, eine Datenbank und eine globale Benutzertabelle bedeuten, dass eine einzige schwache Unterseite einem Angreifer das ganze Netzwerk öffnen kann. Diese Anleitung erklärt das Bedrohungsmodell von Multisite, gibt eine Checkliste mit 10 Punkten zur Härtung und zeigt, warum netzwerkweites Sperren die Lücke schließt, die Sicherheitswerkzeuge pro Website offen lassen.
Warum ein Multisite-Netzwerk anders abgesichert wird als eine einzelne Website
Ein WordPress-Multisite-Netzwerk sieht aus wie viele Websites, technisch ist es aber eine einzige Installation. Fünf Eigenschaften bestimmen sein Bedrohungsmodell:
- Eine Codebasis. Jede Unterseite nutzt denselben WordPress-Core, dieselben Plugin-Dateien und dieselben Theme-Dateien aus einem Verzeichnis. Eine Schwachstelle in einem einzigen Plugin ist auf jeder Unterseite ausnutzbar, auf der dieses Plugin aktiv ist.
- Eine Datenbank. Unterseiten bekommen eigene Tabellen, aber zwischen ihnen gibt es keine Rechtegrenze. Eine SQL-Injection auf irgendeiner Unterseite erreicht jede Tabelle der Datenbank, auch die Netzwerktabellen.
- Globale Benutzer. Die Benutzertabelle gilt für das ganze Netzwerk. Ein Konto, das auf einer Unterseite registriert wurde, existiert überall, und ein Passwort, das auf der unwichtigsten Unterseite gestohlen wurde, funktioniert auch auf der wichtigsten.
- Ein PHP-Prozess. Alle Unterseiten laufen auf demselben Anwendungsserver mit denselben Dateirechten. Codeausführung auf einer Unterseite ist Codeausführung im Netzwerk.
- Die Rolle Super-Admin. Super-Admins bestehen jede Rechteprüfung auf jeder Unterseite. Ein Super-Admin-Konto lässt sich nicht teilweise kompromittieren: Wird eines davon gephisht, ist das ganze Netzwerk verloren.
Die praktische Folge: Ein Multisite-Netzwerk ist genau so sicher wie seine schwächste Unterseite. Eine vergessene Testseite mit einem veralteten Plugin ist kein kleines Risiko in einer Ecke, sie ist eine Tür zu allem.
Welche Teile eines Multisite-Netzwerks Angreifer zuerst abtasten
Zwischen Mai und Juli 2026 hat das ReportedIP-Community-Netzwerk 1,69 Millionen Angriffe auf WordPress-Websites erfasst, und Login-Endpunkte waren das häufigste Ziel. Auf Multisite vervielfachen sich mehrere dieser Angriffsflächen mit der Zahl der Unterseiten:
| Angriffsfläche | Warum sie auf Multisite schwerer wiegt | Erste Gegenmaßnahme |
|---|---|---|
wp-signup.php | Eine offene Registrierung erlaubt Bots, Konten oder ganze Unterseiten im gesamten Netzwerk anzulegen. | Registrierung in den Netzwerkeinstellungen deaktivieren oder auf Benutzerkonten beschränken. |
| Login-Seiten | Jede Unterseite hat ein eigenes Login-Formular, und alle prüfen gegen dieselbe gemeinsame Benutzertabelle. | Netzwerkweite Login-Überwachung mit gemeinsamen Zählern. |
xmlrpc.php | Existiert einmal pro Unterseite; jede Kopie nimmt Anmeldeversuche und verstärkte Multicall-Anfragen an. | Netzwerkweit abschalten oder zentral drosseln. |
| Benutzer-Auflistung per REST | Der Users-Endpunkt kann globale Benutzernamen verraten; eine Abfrage kartiert die Konten des ganzen Netzwerks. | Benutzer-Auflistung für nicht angemeldete Anfragen blockieren. |
| Verwaiste Unterseiten | Aufgegebene Unterseiten führen weiter die komplette Codebasis aus, aber niemand liest ihre Logs. | Nicht mehr gepflegte Unterseiten löschen oder archivieren. |
| Zugeordnete Domains | Eine zugeordnete Domain ohne gültiges TLS legt die gemeinsamen Anmelde-Cookies des Netzwerks offen. | Jede Unterseite und jede zugeordnete Domain mit gültigem Zertifikat ausliefern. |
Checkliste mit 10 Punkten zur Härtung von WordPress Multisite
Arbeiten Sie die Punkte der Reihe nach ab. Die Punkte 1 bis 3 beseitigen die Risiken mit der größten Wirkung, die Punkte 4 bis 9 verkleinern die Angriffsfläche, Punkt 10 betrifft die Erkennung.
- Registrierung schließen oder einschränken. Die Einstellung Registrierung in der Netzwerkverwaltung entscheidet, ob Fremde Konten oder Unterseiten anlegen können. Muss die Registrierung offen bleiben, ergänzen Sie eine Sperre für Wegwerf-Adressen und einen Honeypot im Registrierungsformular, damit Bot-Anmeldungen scheitern, bevor sie Last erzeugen.
- Liste der Super-Admins klein halten. Jedes Super-Admin-Konto bedeutet bei erfolgreichem Phishing den Verlust des ganzen Netzwerks. Zwei oder drei namentlich bekannte Personen reichen; Dienstkonten und Agenturen bekommen Administratorrollen auf einzelnen Unterseiten.
- Zwei-Faktor-Authentifizierung für privilegierte Rollen erzwingen. Zuerst die Super-Admins, dann die Administratoren der Unterseiten. Phishing-resistente Verfahren wie Passkeys und Hardware-Sicherheitsschlüssel schützen die Konten, deren Verlust am teuersten ist.
- Plugins und Themes zentral steuern. WordPress hindert Administratoren von Unterseiten bereits daran, Plugins zu installieren. Dabei sollte es bleiben. Prüfen Sie, welche Plugins netzwerkweit und welche nur auf einzelnen Unterseiten aktiv sind, und entfernen Sie alles, was keine Unterseite mehr nutzt: Auch deaktivierte Plugin-Dateien sind erreichbarer Code.
- Dateibearbeitung im Dashboard abschalten. Definieren Sie
DISALLOW_FILE_EDITin der Konfigurationsdatei, damit eine gekaperte Admin-Sitzung den Theme-Editor nicht in eine PHP-Shell verwandeln kann. In verwalteten Netzwerken mit Deployment-Pipeline sperrtDISALLOW_FILE_MODSzusätzlich Installationen und Updates über den Browser ganz. - Uploads einschränken. Die Netzwerkeinstellungen legen die erlaubten Dateitypen und ein Speicherkontingent pro Unterseite fest. Je kürzer die Liste der erlaubten Typen, desto weniger Wege gibt es, ausführbare Inhalte in das Upload-Verzeichnis zu schmuggeln.
- Verwaiste Unterseiten entfernen. Jede Unterseite ist eine Login-Seite, ein XML-RPC-Endpunkt und ein REST-API-Namensraum. Pflegt niemand mehr eine Unterseite, archivieren oder löschen Sie sie. Mit ihr verschwindet die Angriffsfläche.
- Überall gültiges TLS ausliefern. Installationen mit Subdomains brauchen ein Wildcard-Zertifikat, zugeordnete eigene Domains brauchen jeweils eigene Abdeckung. Eine einzige Unterseite auf reinem HTTP legt Sitzungs-Cookies offen, die im ganzen Netzwerk gelten.
- Vollständig über die Netzwerkverwaltung aktualisieren. Es gibt kein Update „nur für die wichtigen Unterseiten“. Alle nutzen dieselben Dateien. Ein Plugin, das veraltet bleibt, weil eine Unterseite die alte Version braucht, hält den verwundbaren Code für alle geladen.
- Erkennung und Sperren zentralisieren. Verteilte Angriffe sind in den Logs einzelner Websites unsichtbar. Eine gemeinsame Sicht auf Versuche, Sperren und Sensor-Ereignisse aller Unterseiten ist der Unterschied zwischen dem Erkennen einer Kampagne und dreißig scheinbar unzusammenhängenden Störungen.
Die offizielle WordPress-Dokumentation zur Härtung beschreibt die Grundlagen zu Dateirechten und Konfiguration, die für jede Installation gelten. Die Punkte oben ergänzen, was bei Multisite hinzukommt.
Wie Sie ein bestehendes Netzwerk mit fünf Befehlen prüfen
Messen Sie den aktuellen Stand, bevor Sie etwas ändern. Auf einem Server mit WP-CLI beantworten fünf Befehle die Fragen, mit denen jede Sicherheitsprüfung eines WordPress-Multisite-Netzwerks beginnt:
wp site list --fields=blog_id,url,last_updated: jede Unterseite mit ihrer letzten Inhaltsänderung. Unterseiten, die seit einem Jahr unverändert sind, sind Kandidaten für Punkt 7 der Checkliste.wp super-admin list: die Konten, die alles überall dürfen. Überrascht Sie diese Liste, korrigieren Sie sie heute.wp plugin list --fields=name,status,update: netzwerkweit aktive Plugins, einzeln aktive Plugins und ausstehende Updates in einer Ansicht. Alles, was als inaktiv erscheint, liegt trotzdem als Code auf der Festplatte.wp user list --role=administrator --url=SUBSITE-URL: pro Unterseite, wer die Administratorrolle hat. Führen Sie den Befehl für jede Unterseite aus und vergleichen Sie das Ergebnis mit den Personen, die dort tatsächlich arbeiten.wp core verify-checksums: vergleicht jede Core-Datei mit den offiziellen WordPress-Prüfsummen und meldet hinzugefügte oder veränderte Dateien. Ein sauberes Ergebnis schließt den häufigsten Weg aus, sich nach einem Einbruch dauerhaft einzunisten.
Wiederholen Sie die Prüfung nach jeder strukturellen Änderung am Netzwerk: eine neue Unterseite, eine neue Agentur mit Admin-Zugang, eine neue zugeordnete Domain. Die Liste der Super-Admins und die Liste der verwaisten Unterseiten ändern sich zwischen zwei Prüfungen am häufigsten.
Warum Sicherheits-Plugins pro Website in einem Netzwerk versagen
Die meisten WordPress-Sicherheits-Plugins wurden für einzelne Websites gebaut. Auf Multisite speichern sie ihre Zähler, Sperrlisten und Logs meist in Tabellen pro Unterseite. Jede Unterseite verteidigt sich allein.
Dieses Modell bricht beim billigsten denkbaren Angriff. Ein Brute-Force-Angreifer, der vier Login-Versuche auf jede von zehn Unterseiten verteilt, bleibt unter jeder Schwelle pro Website und rät dabei vierzig Mal gegen dieselbe gemeinsame Benutzertabelle. Keine einzelne Unterseite sieht genug Aktivität, um zu reagieren, also wird nirgends gesperrt.
Das zweite Versagen ist organisatorisch: Dreißig Unterseiten bedeuten dreißig getrennte Log-Ansichten. In der Praxis liest sie niemand. Deshalb entdecken bei großen Netzwerken so oft Außenstehende eine kompromittierte Unterseite und nicht der Betreiber.
Wie ReportedIP Hive einen gemeinsamen Bedrohungsstand für das ganze Netzwerk führt
ReportedIP Hive vereint 16 Angriffssensoren, vier 2FA-Methoden, stufenweises Sperren und optionale Bedrohungsdaten aus der Community. Seit Version 2.0 unterstützt es Multisite vollständig, die aktuelle Version ist 2.1.67. In einem Netzwerk lässt sich das Plugin nur netzwerkweit aktivieren; WordPress blendet den Link zur Aktivierung pro Website aus. Die Screenshots in dieser Anleitung zeigen die englische Oberfläche der Netzwerkseiten.
Hive speichert seine Daten einmal für das ganze Netzwerk statt einmal pro Unterseite, und das Ereignisprotokoll hält fest, von welcher Unterseite ein Ereignis kam. Das Ergebnis ist ein gemeinsamer Bedrohungsstand: Fehlgeschlagene Logins derselben IP auf verschiedenen Unterseiten laufen in einem zentralen Zähler zusammen, und eine einzige Sperre schließt die IP auf allen Unterseiten zugleich aus. Der verteilte Angreifer aus dem Beispiel oben erreicht die netzwerkweite Schwelle nach wenigen Versuchen, statt nie.
Dieselbe Zusammenführung gilt für die anderen Sensoren: XML-RPC-Missbrauch, REST-Drosselung, Schutz gegen Benutzer-Auflistung, Erkennung von 404-Scannern und die Web Application Firewall für Anfragen zählen pro IP im Netzwerk, nicht pro Unterseite. Sperrantworten sind cache-sicher, ein Caching-Plugin kann einer gesperrten Adresse auf geschützten Pfaden also kein gespeichertes HTML ausliefern.
Netzwerke im Modus Community Network prüfen Besucher zusätzlich gegen gemeinsame Bedrohungsdaten: Stand 26. September 2026 führt die ReportedIP-Blacklist 30.926 IPs mit hoher Konfidenz. Eine Adresse, die andere Community-Websites angegriffen hat, kann so schon vor ihrem ersten Passwortversuch abgewiesen werden. Netzwerke, die vollständig ohne Verbindung nach außen bleiben müssen, nutzen den Modus Local Shield und behalten jeden hier beschriebenen Mechanismus, nur ohne die gemeinsamen Reputationsdaten.
Was Super-Admins und Website-Administratoren jeweils steuern
Super-Admins verwalten die Netzwerkeinstellungen in der Netzwerkverwaltung, und Hive verlangt von ihnen standardmäßig die Einrichtung von 2FA. Administratoren einer Unterseite bekommen eine schreibgeschützte Ansicht von Status und Logs (im Tarif Business zusätzlich den Audit-Trail ihrer eigenen Website) sowie eine bearbeitbare Einstellungsseite mit zwei Übersteuerungen: den Slugs der 2FA-Seiten im WooCommerce-Frontend und zusätzlichen Rollen für die 2FA-Pflicht. Ein Website-Administrator kann eine Rolle zur 2FA-Pflicht hinzufügen, aber keine entfernen, die das Netzwerk verlangt. Der Komfort einer Unterseite kann die Richtlinie verschärfen, nie lockern.
Das Cookie für vertrauenswürdige Geräte gilt für den Cookie-Pfad des Netzwerks. Eine einzige Bestätigung „diesem Gerät vertrauen“ wirkt deshalb auf allen Unterseiten, statt auf jeder erneut nachzufragen. Geplante Aufgaben laufen nur auf der Hauptseite, ein Netzwerk mit fünfzig Unterseiten führt also nicht fünfzig Bereinigungsjobs aus.
Eine bestehende Einzelsite in ein geschütztes Netzwerk überführen
Die Plugin-Tabellen einer Einzelsite nutzen bereits das Netzwerk-Präfix, der Ereignisverlauf bleibt also erhalten, wenn aus der Website ein Netzwerk wird. Aktivieren Sie Hive nach der Umstellung netzwerkweit und prüfen Sie die Einstellungen einmal in der Netzwerkverwaltung. Das Verhalten als Einzelsite und als Multisite ist jeweils durch PHPUnit-Testreihen abgedeckt, die bei jedem Commit laufen.
Was netzwerkweiter Schutz kostet
Der Erkennungskern ist in jedem Tarif kostenlos: Sensoren, Firewall-Grundschutz, stufenweises Sperren und die zentralen 2FA-Methoden funktionieren netzwerkweit ohne Kosten. Bezahlte Tarife ergänzen die verwalteten Relays und den Komfort mehrerer Domains im Dashboard: 3 Domains im Tarif Professional, 15 im Tarif Business und ein individuelles Limit im Tarif Enterprise; ein ganzes Multisite-Netzwerk zählt als eine Domain. Details zu den Tarifen stehen auf der Produktseite des Plugins.
Häufige Fragen
Gefährdet eine gehackte Unterseite das ganze WordPress-Netzwerk?
Eine gehackte Unterseite bedeutet meist ein gehacktes Netzwerk. Alle Unterseiten teilen sich eine Codebasis, eine Datenbank und eine Benutzertabelle und laufen im selben PHP-Prozess. Codeausführung oder SQL-Injection auf irgendeiner Unterseite erreicht die Daten des Netzwerks. Deshalb behandelt die Härtung von Multisite jede Unterseite als Teil eines einzigen Perimeters.
Sollten Sicherheits-Plugins auf Multisite netzwerkweit aktiviert werden?
Ein Schutz, den einzelne Website-Administratoren abschalten können, ist keine Netzwerkrichtlinie, deshalb gehört ein Sicherheits-Plugin in die Netzwerkaktivierung. ReportedIP Hive setzt das konstruktiv durch: Auf Multisite lässt es sich nur netzwerkweit aktivieren, keine Unterseite kann sich von Überwachung oder Sperren abmelden.
Wie viele Super-Admins sollte ein Multisite-Netzwerk haben?
So wenige, wie der Betrieb zulässt, meist zwei oder drei namentlich bekannte Personen. Jeder Super-Admin besteht jede Rechteprüfung auf jeder Unterseite, jedes weitere Konto vervielfacht also das Phishing-Risiko für das ganze Netzwerk. Alle sollten eine phishing-resistente Zwei-Faktor-Authentifizierung nutzen.
Gilt eine IP-Sperre für alle Unterseiten?
Eine Sperre gilt netzwerkweit, wenn das Sicherheits-Plugin sie einmal für das Netzwerk speichert. In ReportedIP Hive schließt eine einzige Sperre die IP auf jeder Unterseite gleichzeitig aus, und Versuche gegen verschiedene Unterseiten laufen in einem Zähler zusammen. Ein Botnetz, das zwischen Unterseiten springt, zählt als eine Kampagne.
Weitere Anleitungen
- Local Shield und Community Network im Netzwerk
- Stufenweises Sperren, netzwerkweit angewandt
- Schnellstart mit dem Einrichtungsassistenten
Die Hive-Dokumentation beschreibt Multisite-Netzwerke und die Zwei-Faktor-Authentifizierung im Detail. Alle weiteren Funktionen finden Sie in den Anleitungen zu ReportedIP Hive.