Skip to the content
Documentation
Help Start
Reading in:
  • German: 9,090 of 9,090 pages
About the help in other languages
All help pages

Runbook: kompromittierte Website

Was ein Hoster tut, wenn eine Exponential-Website kompromittiert sein könnte - eindämmen, ohne Beweise zu zerstören, das Prüfprotokoll und seine Hash-Kette, das Sicherheitslog und geänderte Dateien prüfen, Zugangsdaten…

Download as PDF

Address: https://doc.exponential.earth/exphelp/viewer/help/hosting/runbooks/compromised-site.md

On this page

This page is a translation. Read the English original

Runbook: kompromittierte Website

Für die Sicherheitsverantwortlichen und Systemadministratoren des Hosters, wenn es Anzeichen gibt, dass ein Angreifer die Exponential-Website eines Kunden verändert hat: verunstaltete Seiten, unbekannte Administratorkonten, Dateien, die es nicht geben sollte, von der Website versandter Spam oder ein Alarm aus dem Prüfprotokoll. Das ist ein Vorfall mit Schweregrad 1 (Support-Stufen).

Warnung Ein Einbruch kann rechtliche Pflichten nach sich ziehen: den Kunden zu benachrichtigen und in vielen Rechtsordnungen Behörden und die Personen, deren Daten betroffen sind, innerhalb fester Fristen. Beziehen Sie den Kunden und Ihren rechtlichen Berater früh ein. Diese Seite ist keine Rechtsberatung.

Inhalt

  1. Eindämmen
  2. Beweise sichern
  3. Untersuchen
  4. Beseitigen und neu aufbauen
  5. Wiederherstellen
  6. Berichten und benachrichtigen
  7. Eine Wiederholung verhindern

Eindämmen

  1. Nehmen Sie die öffentliche Website mit dem Wartungsmodus vom Netz und lassen Sie nur Ihre eigenen Adressen hinein:

    php bin/php/maintenance.php on --message="Maintenance" --allow-ip=<your address> --allow-root-user

  2. Wenn der Angreifer ein Administratorkonto oder eine Sitzung halten könnte, schränken Sie die Administration jetzt auf Netzwerkebene ein (Die Administration einschränken).

  3. Wenn die Maschine selbst kompromittiert sein könnte (unbekannte Prozesse, geänderte Systemdateien), isolieren Sie sie auf Netzwerkebene und arbeiten Sie mit einer Kopie.

  4. Löschen Sie noch nichts.

Beweise sichern

  • Kopieren Sie die aktuellen Dateien und einen Datenbank-Dump an einen Ort, den der Benutzer der Website nicht schreiben kann.
  • Kopieren Sie die Logs: var/log/ (mit error.log, security.log, auth.log, audit/), var/vc/qbix/log/ von Velocity und die Logs von Webserver und PHP-FPM.
  • Notieren Sie die Uhrzeit jeder Handlung, die Sie vornehmen.

Untersuchen

FrageWo Sie nachsehen
Wer hat sich angemeldet, Rollen, Einstellungen oder Passwörter geändert?das Prüfprotokoll: Audit in der Administration, ./console exp:audit tail (Prüfprotokoll)
Wurde das Prüfprotokoll selbst manipuliert?./console exp:audit verify (oder php bin/php/audit.php verify --allow-root-user): Exit-Status 0, wenn die Kette jedes Kanals unversehrt ist, 1, wenn gebrochen; vergleichen Sie mit der von der Maschine weitergeleiteten Kopie, falls eine Senke konfiguriert war
Welche Anfragen sahen wie Angriffe aus, und hat eine ein 200 bekommen?var/log/security.log (Sicherheitslog)
Welche Dateien haben sich geändert?vergleichen Sie den Code mit seinem Git-Tag: git status und git diff in einem Git-Checkout; bei Installationen mit Composer vergleichen Sie mit einem frischen composer install derselben Lock-Datei
Wurden Dateien dort abgelegt, wo PHP schreiben konnte?var/, settings/ und design/ oder extension/, wenn sie beschreibbar waren; jede .php-Datei unter var/storage ist verdächtig
Hat die Website Mail versandt?die Mail-Logs des Servers
Welche Version lief?die Seite Über oder composer show se7enxweb/exponential; vergleichen Sie mit den Korrekturen in späteren Release Notes

Das Prinzip hinter der Prüfung der Dateien, aus 13.11: Wenn der PHP-Prozess nur var/ und settings/ ändern kann und der Webserver sich weigert, irgendetwas unterhalb der Wurzel auszuführen, kann eine Schwachstelle in einer Erweiterung keinen Code einschleusen.

Beseitigen und neu aufbauen

  1. Code aus einer bekannt guten Quelle: ein frischer Checkout des Tags der Version und composer install, dazu die eigenen Erweiterungen aus ihren Repositories. Vertrauen Sie keinen Dateien aus dem kompromittierten Baum.
  2. Daten aus einem sauberen Backup: das neueste Backup von vor der ersten Änderung des Angreifers, bei der Untersuchung gefunden (Aus einem Backup wiederherstellen). Wenn es kein sauberes Backup gibt, prüfen Sie die aktuelle Datenbank auf unbekannte Konten, Rollen und Inhalte, bevor Sie sie behalten.
  3. Aktualisieren Sie Exponential und Erweiterungen vor dem Wiederöffnen auf das neueste 6.0.x, wenn die Lücke eine bekannte sein könnte (Kunden-Websites aktualisieren).

Wiederherstellen

  1. Zugangsdaten: Ändern Sie die Administratorpasswörter; das Datenbankpasswort (und aktualisieren Sie settings/override/site.ini.append.php); API-Schlüssel und Tokens, die die Website hält; Passwörter für SFTP und Panel.
  2. Sitzungen: Eine Passwortänderung meldet jede andere Sitzung dieses Benutzers ab ([PasswordSettings] EndOtherSessions=enabled); nach einem vermuteten Einbruch entfernen Sie außerdem alle Sitzungen (Setup > Sitzungen, mit dem Session-Handler für die Datenbank) (Sicherheitshärtung).
  3. Konten: Entfernen Sie Konten und Rollenzuweisungen, die der Angreifer angelegt hat.
  4. Caches: Leeren Sie alles, damit keine zwischengespeicherte Seite aus dem kompromittierten Zustand ausgeliefert wird: php bin/php/ezcache.php --clear-all --allow-root-user, und mit Velocity starten Sie ihn neu und leeren seinen Antwort-Cache.
  5. Prüfen Sie, und schalten Sie dann den Wartungsmodus aus.

Berichten und benachrichtigen

  • An den Kunden: was geschehen ist, welche Daten betroffen sein könnten, was Sie getan haben.
  • An das Projekt, wenn eine Schwachstelle in Exponential oder einer seiner Erweiterungen die Ursache war: vertraulich, wie SECURITY.md es beschreibt, nie in einem öffentlichen Issue (Sicherheitsupdates und Offenlegung).
  • An Behörden und betroffene Personen, wo das Gesetz es verlangt: Der Kunde ist meist der Verantwortliche für die personenbezogenen Daten und entscheidet mit seinem rechtlichen Berater; Sie unterstützen ihn mit Fakten und Logs (Compliance und DSGVO).

Eine Wiederholung verhindern

  • Gehen Sie die Checkliste für die Sicherheitsprüfung durch.
  • Machen Sie den Code für den Benutzer der Website schreibgeschützt (13.11).
  • Leiten Sie das Prüfprotokoll mit einer Senke von der Maschine weg ([AuditSink_syslog], [AuditSink_webhook]), damit eine kompromittierte Maschine ihre eigene Geschichte nicht stillschweigend umschreiben kann (Sicherheitshärtung).
  • Prüfen Sie, ob Request Shield davor läuft (Setup > Request Shield; einer aktualisierten Installation kann die Hook-Zeile in config.php fehlen), und sehen Sie sein Log an (request-shield und Request-Regeln).

Verwandte Seiten

Werden Sie Exponential-Partner

Partner teilen ihre Informationen, stellen Mittel bereit, geben Beiträge zurück und entwickeln die Produkte mit uns, und so wächst Exponential. Eine Partner-Website und ein Dashboard sind für Mitte 2027 geplant: Werden Sie noch heute Partner, damit wir schneller wachsen und neue Funktionen früher liefern.

Partner: hier beginnen Wie Sie sich bewerben

Something wrong on this page? Report an error

Documentation license

This documentation is free documentation, licensed under the GNU Free Documentation License 1.3 or later.

Exponential Copyright © 1998-2026 Exponential Foundation and 7x