Site Health hilft Site Ownern zu prüfen, ob die Dateien von Jyavani Core und Erweiterungen weiterhin mit vertrauenswürdigen Baselines übereinstimmen. Gleichzeitig bewertet es die Sicherheit von Medien und siteeigenen Dateien. Das Ergebnis ist eine diagnostische Momentaufnahme des letzten Scans, kein Virenschutz und keine Echtzeit-Sicherheitsüberwachung.
Scan öffnen und ausführen
Öffnen Sie Einstellungen > Site Health. Die Schaltfläche Vollständigen Scan ausführen startet eine manuelle Prüfung und zeigt nach Abschluss einen neuen Bericht an. Führen Sie den Scan nicht während eines Core-, Plugin- oder Theme-Updates aus.
Das Dashboard kann außerdem einen automatischen Scan anfordern, wenn noch kein Bericht vorhanden ist, der Bericht zu einer anderen Core-Version gehört oder mindestens eine Stunde alt ist. Die Anforderung verwendet einen separaten POST-Endpunkt nach der Prüfung von Berechtigung, Site Owner und CSRF. Dashboard und Widget bleiben beim Rendern schreibgeschützt; das Hashing läuft nicht innerhalb einer normalen Seitenanfrage.
Automatische Anforderungen werden im Browser gedrosselt. Nach dem Erhalt des Scan-Locks wird die Aktualität erneut geprüft, damit gleichzeitig geöffnete Dashboards keine Scan-Warteschlange erzeugen. Dieser Mechanismus ist opportunistisch und kein Server-Scheduler: Eine Website ohne Aktivität eines Site Owners benötigt weiterhin Host-Monitoring oder einen separat verwalteten Zeitplan.
Zusammenfassung lesen
- Prüfen Sie Scan-Zeitpunkt, Version und Quelle der Baseline sowie den fehlerfreien Abschluss des Berichts.
- Vergleichen Sie die Status von Core-Dateien, Plugins und Themes sowie Medien und Dateien getrennt.
- Öffnen Sie einen Befundbereich, um relative Pfade, Gründe und gegebenenfalls erwartete und beobachtete Hashes zu prüfen.
- Nutzen Sie Statusfilter und Suche, um veränderte Dateien von unerwarteten Artefakten zu unterscheiden.
Das Site-Health-Widget auf der Dashboard-Startseite liest ausschließlich den gespeicherten Bericht. Es zeigt den Anteil sauberer Core-Dateien, die Anzahl der Integritätsbefunde, den Status der Komponenten und den Zeitpunkt des letzten Scans. Integritätsbefunde sind keine Anzahl bestätigter Schwachstellen.
Die fünf Status verstehen
clean: Alle von einer vertrauenswürdigen Baseline geforderten Dateien stimmen überein und im Bereich der Komponente befindet sich kein verbotenes Artefakt.unverified: Es ist keine vertrauenswürdige Baseline verfügbar, die Herkunft ist nicht belegbar, der Scan wurde nicht abgeschlossen oder eine Ressource war nicht lesbar.modified: Eine Manifestdatei fehlt, ihr Hash weicht ab oder ihr sicherer Dateityp entspricht nicht der Release-Identität.contaminated: Ein verwalteter Bereich enthält ein unerwartetes oder verbotenes Artefakt, etwa ausführbaren Code, einen symbolischen Link, eine Spezialdatei oder eine Datei außerhalb ihrer Eigentumsgrenze.infected: Ein Detektor mit hoher Zuverlässigkeit identifiziert schädliche Inhalte und nennt seine Identität sowie die Beweiskategorie.
Der Status modified beweist keine Schadsoftware; auch eine legitime lokale Änderung unterscheidet sich vom Release-Paket. contaminated erfordert eine Prüfung, bedeutet aber nicht automatisch infected. Jyavani hat derzeit keine Malware-Engine konfiguriert; infected ist für einen zukünftigen Detektor mit hoher Zuverlässigkeit reserviert.
Core-Integrität und Release-Baselines
Core Integrity vergleicht verwaltete Dateien mit dem HTTPS-Manifest der exakt installierten Jyavani-Version. Der Scanner validiert Pfade, Dateianzahl und SHA-256-Hashes und meldet fehlende, veränderte oder unerwartete Dateien. Das lokale Manifest ist als Installationsmetadatum nützlich, darf aber nicht die einzige Vertrauensquelle sein, da ein Akteur mit Schreibzugriff auf Core möglicherweise auch dieses Manifest ändern kann.
Der Scanner vergleicht eine ältere Installation nicht mit dem neuesten Release-Manifest. Update-Status und Dateiintegrität sind getrennte Aspekte. Ist das kanonische Manifest der installierten Version nicht verfügbar, ungültig oder unpassend, bleibt die Core-Komponente unverified; andere Befunde bleiben zur Prüfung sichtbar.
Ein Deployment kann erwartete, nicht ausführbare öffentliche Assets und lokale Tools der Website in cfg/site-files.json erfassen. Übereinstimmende Hashes definieren eine Eigentumsgrenze, sodass diese Dateien nicht als fremde Core-Dateien gelten. Dieses Manifest ist keine Release-Vertrauensquelle: geänderte Hashes, symbolische Links, Spezialdateien, Core-Laufzeitpfade und öffentlich ausführbare Dateien schlagen weiterhin sicher fehl.
Plugins und Themes
Die Nutzung eines offiziellen Plugin-Hooks verändert keine Core-Dateien. Kanonische Store-Plugins und Nicht-System-Themes werden gegen das HTTPS-Manifest ihrer exakt installierten Version geprüft. Ein übereinstimmender Verzeichnisbaum kann clean sein; fehlende oder veränderte Release-Dateien werden modified; unerwartete oder unsichere Artefakte werden contaminated.
Eine lokale Erweiterung ohne Store-Herkunft kann ein vom Betreiber installiertes, mit Ed25519 signiertes Deployment-Manifest verwenden. Die Store-Baseline hat immer Vorrang; eine Erweiterung mit Store-Identität darf bei einem Fehler des kanonischen Manifests nicht auf eine lokale Baseline zurückfallen. .store.json ist nur Updater-Metadatum und schafft kein Vertrauen, während .git-Dateien und -Verzeichnisse im Erweiterungsbaum stets verboten sind.
Ein Plugin darf bis zu acht Verzeichnisse für zur Laufzeit erzeugte öffentliche Bilder innerhalb von static/plugins/{folder}/ deklarieren. Diese Bilder werden nicht mit Release-Hashes verglichen, bleiben jedoch durch Anzahl, Größe, Erweiterung, MIME-Typ, ausführbar wirkende Namen, Dateityp und Symlink-Prüfungen begrenzt. Paketdateien und kopierte statische Assets müssen weiterhin mit dem Store-Manifest übereinstimmen.
Medien und siteeigene Dateien
Medien und siteeigene Dateien werden nicht mit dem Core-Manifest verglichen. Der Scanner prüft Eingrenzung, Dateityp, symbolische Links, ausführbare Inhalte oder Serverkonfigurationen in Upload-Verzeichnissen, doppelte Erweiterungen und die Übereinstimmung des Bild-MIME-Typs. Normale Dateien können den Status scanned erhalten; dies bedeutet, dass die verfügbaren Prüfungen abgeschlossen wurden, nicht dass die Dateien garantiert frei von Schadsoftware sind.
Der Bericht darf keine Inhalte privater Dateien, absoluten Deployment-Pfade, verborgenen Administrationsrouten, Zugangsdaten oder Benutzerdaten offenlegen. Angezeigt werden dürfen nur relative Pfade und die für die Diagnose erforderlichen Befundmetadaten.
Befunde weiterverfolgen
- Vergleichen Sie den Scan-Zeitpunkt mit der letzten geplanten Änderung oder Aktualisierung.
- Verwenden Sie bei veränderten Core-Dateien nach einem Backup ein verifiziertes Paket und den offiziellen Update- oder Neuinstallationsablauf.
- Verwalten Sie Plugins und Themes über deren Lifecycle-Vorgänge; löschen Sie Dateien nicht direkt aus der Befundtabelle.
- Prüfen Sie deployment-eigene Dateien gegen einen freigegebenen Hash, bevor Sie
cfg/site-files.jsonaktualisieren. - Bewahren Sie verdächtige Artefakte für die Prüfung durch einen Operator oder einen eigens entwickelten Quarantäneprozess auf.
- Führen Sie nach der Behebung einen weiteren Scan aus, um eine neue Momentaufnahme zu erzeugen.
Grenzen eines sauberen Ergebnisses
Ein clean-Ergebnis bedeutet, dass verifizierte Dateien mit vertrauenswürdigen Manifesten übereinstimmen und im gescannten Bereich kein bekannter verdächtiger Zustand gefunden wurde. Es beweist nicht, dass Code, Datenbank, Server, Abhängigkeiten, Netzwerk oder Website frei von Schwachstellen oder Kompromittierungen sind. Dateien können sich nach einem Scan ändern, und Scanner können falsch-positive oder falsch-negative Ergebnisse liefern.
Site Health speichert derzeit einen Bericht; Verlauf, Export, Benachrichtigungen, geplante Scans, Umgebungsbereiche und ein Quarantäne-Workflow sind noch nicht verfügbar. Ergänzen Sie Site Health durch getestete Backups, minimale Berechtigungen, zeitnahe Updates, Server-Monitoring, Dateisystem-Auditing, Malware-Scans auf dem Host und unabhängige Sicherheitsprüfungen.