Viele WordPress-Sites verwalten: Updates, Backups, Sicherheit

Drei WordPress-Sites zu verwalten ist einfach: Sie melden sich in jedem Dashboard an, klicken auf „Alle aktualisieren“ und machen weiter. Irgendwo zwischen zehn und fünfzig Sites bricht diese Routine zusammen. Updates stauen sich, die Site eines Kunden geht nach einem Plugin-Release kaputt und Sie erfahren es erst von dessen Kunden, und eine vergessene Installation mit einem zwei Jahre alten Slider-Plugin wird still und leise zur Spam-Schleuder. Die Lösung ist nicht, mehr zu arbeiten, sondern eine wiederholbare Routine, die Ihre Sites als Bestand behandelt statt als fünfzig einzelne Pflichten. Hier ist die Routine, die sich in der Praxis bewährt.

Warum WordPress-Bestände aus dem Ruder laufen

• Updates kommen häufig und ungleichmäßig. Der Core liefert mehrmals im Jahr kleinere Sicherheitsreleases, und eine durchschnittliche Site hat 15 bis 30 Plugins, jedes mit eigenem Release-Rhythmus. Multipliziert mit Ihrer Anzahl an Sites gibt es fast täglich etwas zu aktualisieren.
• Die meisten Kompromittierungen kommen von Plugins, nicht vom Core. Jahr für Jahr betrifft die überwältigende Mehrheit der veröffentlichten WordPress-Schwachstellen Plugins und Themes. Gehackt wird meist die Site, die seit Monaten niemand angesehen hat.
• Dashboards skalieren nicht. Sich in fünfzig Admin-Oberflächen einzuloggen ist langsam, man vergisst leicht eine, und es gibt keinen Gesamtüberblick, was wo veraltet ist.

Nutzen Sie wp-cli, nicht das Dashboard

wp-cli ist das offizielle Kommandozeilenwerkzeug für WordPress und die größte Zeitersparnis für alle, die mehr als eine Handvoll Sites betreuen. Jede Routineaufgabe wird zu einem Befehl, den Sie skripten können:

# Welche Core-Version, und gibt es ein Update?
wp core version
wp core check-update

# Welche Plugins und Themes sind veraltet?
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available

# Ein Plugin aktualisieren, oder alles
wp plugin update woocommerce
wp plugin update --all
wp theme update --all
wp core update
wp core update-db

Zwei Regeln machen wp-cli auf einem Server mit vielen Sites sicher:

• Führen Sie es als Benutzer der Site aus, niemals als root. Wenn jede Site einen eigenen Linux-Benutzer hat (und das sollte sie), starten Sie sudo -u siteuser wp --path=/var/www/siteuser/public_html .... Als root gehören die von einem Update geschriebenen Dateien root, was das nächste Update und die Uploads der Site selbst kaputt macht. wp-cli weigert sich sogar, ohne --allow-root als root zu laufen, und diese Warnung hat einen guten Grund.
• Geben Sie immer --path an. In einer Schleife über viele Sites garantiert ein expliziter Pfad, dass jeder Befehl die gemeinte Site trifft.

Damit ist ein Inventar Ihres gesamten Bestands eine kurze Schleife:

for dir in /var/www/*/public_html; do
  user=$(stat -c %U "$dir")
  [ -f "$dir/wp-config.php" ] || continue
  echo "== $dir"
  sudo -u "$user" wp --path="$dir" plugin list --update=available --format=csv
done

Lassen Sie das wöchentlich laufen, und Sie wissen genau, wo das Risiko liegt, bevor Sie irgendetwas anfassen.

Die sichere Update-Reihenfolge

Alles auf allen Sites gleichzeitig zu aktualisieren ist genau der Weg, auf dem ein fehlerhaftes Release zwanzig Kunden an einem Nachmittag lahmlegt. Eine ruhigere Reihenfolge:

1. Zuerst sichern. Dateien und Datenbank, jedes Mal (mehr dazu unten).
2. Plugins vor dem Core aktualisieren, wenn ein großes Core-Release erscheint, damit Plugins, die Kompatibilität mit dem neuen Core nachrüsten, bereits installiert sind. Bei routinemäßigen Minor-Releases spielt die Reihenfolge weniger eine Rolle, aber bleiben Sie konsistent.
3. Themes zuletzt aktualisieren, und bearbeiten Sie nie ein Theme, das Sie auch aktualisieren; Anpassungen gehören in ein Child-Theme.
4. wp core update-db ausführen nach einem Core-Update, damit Datenbankmigrationen nicht auf den nächsten Admin-Login warten.
5. Die Site prüfen. Rufen Sie mindestens die Startseite und eine Unterseite ab und prüfen Sie den HTTP-Status und das PHP-Fehlerlog. Ein weißer Bildschirm, den einen Tag lang niemand bemerkt, ist schlimmer als einer, den Sie in dreißig Sekunden entdecken.

Nach Risiko staffeln. Aktualisieren Sie zuerst Ihre eigenen Sites mit wenig Traffic, warten Sie einen Tag und rollen Sie dann auf Kundensites aus. Bei Shops mit viel Traffic testen Sie auf einer Kopie, bevor es in die Produktion geht.

Vor jedem Update sichern, und woanders aufbewahren

Ein Update ohne Backup ist ein Glücksspiel. Machen Sie das Backup zum Teil des Update-Befehls statt zu einer separaten Gewohnheit:

wp db export /var/backups/siteuser/before-update-$(date +%F).sql
tar -czf /var/backups/siteuser/files-$(date +%F).tar.gz -C /var/www/siteuser public_html

Dann gelten die Grundregeln für Backups, die Sie wirklich retten:

• Weg vom Server. Ein Backup auf derselben Platte stirbt mit der Platte oder mit dem Angreifer. Schieben Sie eine Kopie auf S3-kompatiblen Speicher oder eine andere Maschine. (Ausführlich behandelt in verschlüsselte Website-Backups nach S3.)
• Aufbewahrung, nicht nur eine Kopie. Behalten Sie mehrere Generationen. Malware, die eine Woche lang unbemerkt blieb, steckt auch im Backup von letzter Nacht.
• Testen Sie ab und zu eine Wiederherstellung. Ein Backup, das Sie nie zurückgespielt haben, ist eine Hoffnung, kein Backup.

Plugin-Hygiene: die günstigste Sicherheit, die es gibt

• Löschen Sie, was Sie nicht nutzen. Deaktivierte Plugins liegen weiter auf der Platte und lassen sich weiterhin ausnutzen, wenn ihre Dateien direkt erreichbar sind. wp plugin list --status=inactive, dann wp plugin delete.
• Lieber wenige, gepflegte Plugins. Ein Plugin ohne Update seit zwei Jahren oder eines, das aus dem wordpress.org-Verzeichnis entfernt wurde, ist ein Risiko. Ersetzen Sie es.
• Installieren Sie nie „nulled“ Plugins oder Themes. „Kostenlose“ Kopien von Premium-Plugins sind einer der häufigsten Wege, auf denen Hintertüren auf WordPress-Sites gelangen.
• Sperren Sie die Dateibearbeitung. Fügen Sie define('DISALLOW_FILE_EDIT', true); in wp-config.php ein, damit ein gestohlener Admin-Login nicht über den Theme-Editor zur PHP-Codeausführung wird.
• Isolieren Sie Sites voneinander. Ein Linux-Benutzer und ein PHP-FPM-Pool pro Site, damit eine Kompromittierung auf einer Site die Dateien oder Datenbank-Zugangsdaten der nächsten nicht lesen kann. (Siehe mehrere Kundensites auf einem VPS hosten.)
• Scannen Sie regelmäßig. Lassen Sie einen Malware-Scanner wie ClamAV planmäßig über die Dateien jeder Site laufen, nicht erst, wenn etwas verdächtig aussieht.

Häufige Fallen

• Alles blind automatisch aktualisieren. Die WordPress-Hintergrundupdates für kleinere Core-Releases sind sinnvoll. Jedes Plugin jedes Kundenshops ohne Backup und ohne Prüfung automatisch zu aktualisieren ist es nicht.
• update-db vergessen. Nach manchen Core- und WooCommerce-Updates läuft die Site, aber das Datenbank-Upgrade steht noch aus, und der nächste Admin, der sich anmeldet, löst es zu einem zufälligen Zeitpunkt aus.
• Gemeinsame Benutzer für mehrere Sites. Wenn alle Sites als www-data laufen, legt ein einziges verwundbares Plugin jede Site auf dem Server offen.
• Backups auf demselben Server. Ransomware und Plattenausfälle interessiert es nicht, dass Sie einen Backup-Ordner hatten.
• Kein Inventar. Sie können nicht patchen, wovon Sie nichts wissen. Führen Sie eine Liste jeder Installation, ihres Verantwortlichen und ihrer Plugins.

Wie ShadowPanel Ihnen die Routinearbeit abnimmt

ShadowPanel ist ein selbst gehostetes Hosting-Control-Panel und deckt in den Tarifen Pro und Agency die obige Routine ab, ohne die Isolationsregeln aufzugeben:

• WordPress Toolkit. Jede WordPress-Site bekommt eine Ansicht, die die Installation erkennt und die Core-Version, ein verfügbares Core-Update sowie jedes Plugin und Theme mit installierter und verfügbarer Version auflistet. Sie können den Core, ein einzelnes Plugin oder Theme oder alle Plugins bzw. Themes auf einmal aktualisieren, und das Panel zeigt Ihnen die Ausgabe von wp-cli.
• Läuft als Benutzer der Site. Im Hintergrund nutzt es wp-cli als eigenen Linux-Benutzer der Site, niemals als root, wobei der Zielpfad gegen das Home-Verzeichnis dieses Benutzers geprüft wird. Aktualisierte Dateien behalten den richtigen Besitzer.
• Backups vor Änderungen. Backups von Dateien und Datenbanken auf Abruf gibt es in jedem Tarif; Pro und Agency ergänzen geplante automatische Backups (täglich, wöchentlich oder monatlich), die auf S3-kompatiblen Speicher oder einen SFTP-Server hochgeladen werden, mit frei wählbarer Anzahl aufbewahrter Kopien und einer E-Mail, wenn ein Lauf fehlschlägt. Archive lassen sich per GPG mit AES-256 verschlüsseln.
• Malware-Scans. Pro und Agency können aus dem Panel einen vollständigen ClamAV-Scan einer Site starten und infizierte Dateien optional in Quarantäne verschieben; der Scan-Verlauf wird pro Site gespeichert, und nach Abschluss gibt es eine Benachrichtigung.
• Isolation ab Werk. Jede Site hat ihren eigenen Linux-Benutzer und ihren eigenen PHP-FPM-Pool mit open_basedir, sodass ein veraltetes Plugin das Problem einer einzigen Site bleibt.

Fazit

Fünfzig WordPress-Sites bleiben gesund, wenn die Arbeit zur Routine wird: Inventar mit wp-cli, vor jeder Änderung extern sichern, in fester Reihenfolge aktualisieren, das Ergebnis prüfen und überflüssige Plugins entfernen. Nichts davon ist schwierig; es muss nur jede Woche für jede Site passieren. ShadowPanel bündelt Inventar, Updates, geplante Backups und Malware-Scans an einem Ort und hält dabei jede Site von den anderen abgeschottet.

curl -fsSL https://shadowpanel.de/install.sh | bash

Preise ansehen und herunterladen →