Die herkömmliche Health-Prüfung arbeitet von der Protokollschicht aus: 'Port offen', 'liefert HTTP 200', vielleicht 'Seiteninhalt enthält dieses Wort'. Diese Antworten sagen, dass der Server bedient, aber nicht, MIT WELCHEM Inhalt er bedient.
Moderne Probleme leben genau in dieser Lücke. Hat ein Angreifer das WAAP überwunden und eine Webshell auf dem Server hinterlassen, sagt die Health-Probe weiterhin 'der Server ist gesund'. Ist ein Deployment fehlerhaft ausgefallen, antwortet der Server mit dem alten Binary, aber für die Protokoll-Probe ist es wieder 200 OK. Hat ein Operator manuell die Config-Datei geändert, läuft die Abweichung von der Baseline stillschweigend weiter.
Im Cluster-Maßstab ist die Lage noch schlimmer. Auf 9 von 10 Servern ist die neue Version, auf 1 nicht; die Health-Probe sieht alle als gesund, die Benutzeranfrage fällt unglücklicherweise auf den veralteten Server. Oder umgekehrt: Auf 1 Server hat ein Angreifer eine neue Datei hinterlassen; der Rest des Clusters ist sauber, aber von diesem einen Server wird kein Verkehr abgezogen, weil niemand hinschaut.
ETM Server Integrity & Deployment Intelligence füllt diese Lücke: Datei-, Verzeichnis-, Binary- und Config-Status auf dem Server werden kontinuierlich überwacht; Änderungen fließen als Ereignis an den ADC und ans SOC; die Routing-Entscheidung geht über die äußere Hülle hinaus.
Der Agent auf dem Server führt eine kontinuierliche Prüfung auf Dateiebene durch; er erkennt Änderungen und bindet sie live an die ADC-Routing-Entscheidung und das SOC-Ereignissystem.
Für ausgewählte kritische Dateien (Webroot-Inhalt, Application Binary, Config-Dateien, TLS-Zertifikate) wird periodisch ein Hash berechnet. Für Verzeichnisbäume wird ein Merkle-artiger aggregierter Hash erzeugt. Eine Änderung wird durch Hash-Vergleich sofort erkannt.
Das Hinzufügen einer neuen Datei außerhalb der erwarteten Baseline, die Änderung einer bestehenden Datei oder das Löschen einer erwarteten Datei erzeugt ein sofortiges Ereignis. Eine neue .aspx/.php/.jsp-Datei, die im Webroot abgelegt wird, wird als Webshell-Verdacht markiert.
Zwischen Servern, die denselben Anwendungsdienst bereitstellen, wird ein Hash-Vergleich durchgeführt. Ein einzelner Server außerhalb der erwarteten Verteilung (Drift oder kompromittiert) wird aus dem Cluster ausgegliedert; der Verkehr wird auf konsistente Server geleitet.
Wird eine Änderung erkannt, kann die ADC-Verkehrsrichtlinie automatisch reagieren: Warm-up-Periode, schrittweises Routing, temporäre Isolation. Wird ein neues Deployment erkannt, geht der Verkehr sanft über; wird eine unautorisierte Änderung erkannt, wird der Verkehr unterbrochen.
Dateiintegrität und Deployment Intelligence sind nicht nur Sicherheit, sondern ein Teil des operativen Entscheidungsmechanismus.
Für die in den vhost-Wurzeln des Webservers gehaltenen Inhaltsdateien (HTML, ASP, ASPX, PHP, JSP, JS, CSS, Bilder) werden periodischer Hash und Verzeichnisbaum-Integrität berechnet. Der Operator definiert über die Richtlinie, welche Verzeichnisse überwacht und welche Erweiterungen als sensibel gelten. Eine unerwartete Änderung spiegelt sich als sofortiges Ereignis wider.
Wenn ein Angreifer das WAAP überwindet und versucht, eine Webshell auf dem Server zu platzieren, erfasst ETM die im Webroot abgelegte neue ausführbare Erweiterung (z. B. .aspx, .php, .jsp) sofort. Der Server kann automatisch unter Quarantäne gestellt, der Verkehr unterbrochen werden, das SOC erhält einen Alarm. Es ist die letzte Schicht der Verteidigung NACH dem WAAP.
Eine Hash-Änderung von Application Binary oder Artefakt wird als Deployment-Ereignis interpretiert. Der ADC erwartet dieses Ereignis: Bis die Gesundheitsindikatoren stabil sind, wird wenig Verkehr auf den Server geleitet, bei abgeschlossenem Warm-up wird der volle Verkehr geöffnet. Manuelle Schritte 'aus dem Load Balancer nehmen, deployen, zurückgeben' werden automatisiert.
Wenn Konfigurationsdateien wie Apache-Config, Nginx-Config, IIS Application Config, systemd-Units, cron-Definitionen von der Baseline abweichen, wird ein Alarm erzeugt. Der Operator kann vor einer unautorisierten Änderung eingreifen; reguläre Änderungen werden mit einer Baseline-Aktualisierung abgedeckt.
Der Hash kritischer System-Binaries, Bibliotheksdateien und Hilfstools wird mit der Baseline verglichen. Eine Binary-Änderung infolge von Rootkit, Supply-Chain-Compromise oder manuellem Eingriff wird sofort erkannt; der Server wird isoliert, bleibt für Forensik offen.
Wenn Eigentümer, Berechtigungen oder ACL-Einträge kritischer Dateien und Verzeichnisse geändert werden, wird ein Ereignis erzeugt. Unautorisierte Privilegienerweiterung, Änderung des Dateieigentums oder das Öffnen von Schreibrechten auf sensible Konfiguration werden sofort sichtbar.
Zwischen Servern, die denselben Anwendungsdienst bereitstellen, wird ein Baseline-Hash-Vergleich durchgeführt. Stimmen 9 von 10 Servern überein und ist 1 anders, ist der abweichende ein Drift- oder Kompromittierungsverdächtiger. Es kann automatische Quarantäne oder Isolation mit Operator-Genehmigung angewendet werden.
Öffnet der Operator ein Wartungsfenster, erzeugen die Änderungen innerhalb dieses Fensters keinen Alarm; die Baseline wird gemäß Richtlinie aktualisiert. Ein erwartetes Deployment-Ereignis wird nicht als 'echte Änderung' interpretiert; eine überraschende Änderung löst einen Alarm aus.
Zeigt die ETM-Telemetrie nach einer neuen Version (GC-Dauer, Error Rate, Restart-Häufigkeit) eine Verschlechterung, verknüpft ETM dies mit dem Deployment-Ereignis. Das ADC-Routing kann Servern mit der vorherigen Version Priorität geben; das Rollback-Team wird automatisch informiert.
Jede Datei-/Konfigurations-/Binary-Änderung wird in die Audit-Aufzeichnung geschrieben; sie wird an ein SIEM übermittelt. Auf welchem Server, wann, welche Datei von welchem Hash zu welchem Hash geändert wurde — für Audits ist eine vollständige Beweiskette bereit. Live-Unterstützung für GDPR Art. 32 und sektorale Audit-Anforderungen.
Integritätsüberwachung ist nicht nur eine technische Funktion, sondern die Live-Verwaltungsschicht der Deployment- und Sicherheitsprozesse des Unternehmens.
Welche Verzeichnisse überwacht, welche Dateierweiterungen als sensibel gelten, welche Dateien ignoriert werden (Log, Cache, temporäre Dateien), wird über die Richtlinie definiert. Für Webserver, Anwendungsserver und Datenbankserver können unterschiedliche Profile definiert werden.
Kritische Dateien (System Binary, TLS-Zert) können im Sekundenbereich; mittel-priorisierte (Config-Dateien) im Minutenbereich; niedrig-priorisierte (statischer Inhalt) in stündlichen Intervallen gehasht werden. Die Disk-IO-Last wird unter Kontrolle gehalten.
Integritätsereignisse werden live an die ADC-Routing-Richtlinie gebunden. Policy-Regeln wie 'Neue Datei erkannt + WAAP-Angriffskontext vorhanden → Isolation', 'Hash-Drift erkannt → niedrige Priorität', 'Deployment erkannt → Warm-up' werden vom Operator definiert.
Die CI/CD-Pipeline kann der ETM-API ein Deployment-Ereignis melden; ETM interpretiert dieses Ereignis als erwartete Änderung, löst statt eines Alarms eine Routing-Koordination aus. Nach Abschluss des Deployments signiert ETM die neue Baseline.
Hoch-priorisierte Ereignisse wie Webshell-Verdacht, Binary Tampering, Cluster Drift werden direkt mit Alarm ans SOC übermittelt. Das Ereignis wird angereichert: welcher Server, welche Datei, Hash-Vergleichsergebnis, letzte Änderungszeit, Aktionsempfehlung.
Jedes Integritätsereignis wird in die Audit-Aufzeichnung eingetragen. Fragt der Auditor 'Auf welchem Server hat sich in den letzten 30 Tagen welche Datei geändert?', wird live geantwortet. Für PCI DSS, GDPR Art. 32 und sektorale Audit-Anforderungen wird die Beweiskette automatisiert.
Selbst wenn das WAAP den Angriff nicht erkannt hat, wird die im IIS-vhost-Verzeichnis auf dem Server platzierte neue ausführbare Datei von ETM sofort erfasst. Der Server wird automatisch aus dem Cluster gezogen, der Verkehr unterbrochen, das SOC erhält einen sofortigen Alarm; das Gerät bleibt für Forensik offen.
Wenn das DevOps-Team eine neue Version deployt, erkennt ETM die Hash-Änderung des Application Binary; der ADC führt ein schrittweises Routing auf den Server durch. Wenn die Gesundheitsmetriken (CPU, GC-Dauer, Error Rate) stabil bleiben, wird der volle Verkehr geöffnet. Manuelle Prozesse 'aus dem Load Balancer nehmen, deployen, zurückgeben' entfallen.
9 von 10 Servern im Produktions-Cluster stimmen mit dem Baseline-Hash überein; 1 zeigt einen anderen Hash. Veraltete Version, manueller Eingriff oder kompromittiert? ETM stellt diesen Server automatisch unter Quarantäne; der Operator untersucht die Ursache. Die Benutzeranfrage fällt nicht unglücklicherweise auf die falsche Version.
Nach der neuen Version zeigt die ETM-Telemetrie, dass sich die GC-Dauer verlängert, die Error Rate erhöht und die Restart-Häufigkeit gestiegen ist. ETM verknüpft dies mit dem Deployment-Ereignis; das ADC-Routing gibt Servern mit dem Hash der vorherigen Version Priorität. Das Rollback-Team wird automatisch informiert; die Deployment-Entscheidung wird mit Daten gestützt.
Wenn der Hash eines kritischen System-Binary auf einem Server von der Baseline abweicht — Verdacht auf Rootkit, Supply-Chain-Compromise oder unautorisierte Änderung — wird der Server aus dem Cluster getrennt, der Internetzugang unterbrochen, nur der ETM-Verwaltungskanal bleibt offen. Das SOC führt für Forensik eine Remote-Untersuchung durch.
Sehen wir uns ETM Server Integrity in Ihrem eigenen Backend live an — planen wir eine Setup-Sitzung, die Baseline-Definition, ADC-Bindung und SIEM-Stream über einer Pilot-Servergruppe umfasst.