Contao Security Suite

Contao-native Sicherheitsüberwachung, ‑Audit und ‑Härtung mit einer modernen Backend-Sicherheitskonsole.

Deutsch (primär) · English version

Projektübersicht

Die Contao Security Suite ist ein Contao-Bundle, das eine Backend-Sicherheitskonsole für eine Contao-Installation bereitstellt. Sie beantwortet zwei Fragen gleichzeitig:

1. Sicherheitslage – ist diese Installation sicher konfiguriert?
2. Sicherheitsaktivität – ist etwas Auffälliges geschehen?

Dazu führt sie einen Satz lokaler Sicherheitsprüfungen aus, berechnet daraus einen Sicherheitsscore, verwaltet Feststellungen („Findings") über ihren gesamten Lebenszyklus, zeichnet Sicherheitsereignisse auf, wertet die Backend-Anmeldeaktivität aus und korrigiert – in der Pro-Edition – was sie sicher selbst korrigieren kann: Ein-Klick-Behebung mit Vorschau, Verifizierung und Rollback, automatische IP-Sperrung für die Backend-Anmeldung (Aktiver Schutz) und Quarantäne für exponierte oder verdächtige Dateien, plus Pfadsondierungserkennung, Quellenreputation, ausgewählte Frontend-Drosselung, Upload-Prävention und gebündelte Sicherheitsbenachrichtigungen in Stage 2. Stage 3 ergänzt adaptive lokale Anmelde-Challenges, sicherheitsbewusste Backend-Sitzungen und einen vertrauensnetz-basierten Notfall-Sperrmodus. Stage 4 ergänzt optionale externe Durchsetzung (Cloudflare), Fail2ban-Signale, gecachte Bedrohungsdaten, Pfad-Härtung, TLS-/Zertifikatsprüfung und sichere Vorfallnachweise. Diese Funktionen ersetzen keine Server- oder Netzwerk-Firewall.

Aktueller Implementierungsstatus

Alle zwölf Bereiche der Suite sind als echte, funktionsfähige Module umgesetzt. Der Sicherheitsscore, die Findings, die Ereignisse, die Login-Auswertung und die Dashboard-Kacheln stammen aus tatsächlich erhobenen Daten – nicht aus Beispieldaten. Die Analyse-Engine ist in der Free- und in der Pro-Edition aktiv; die Lizenzierung schaltet den Zugriff auf die Bereiche außer dem Dashboard sowie sämtliche verändernden Aktionen frei, nicht die Analyse selbst.

Das Repository trägt die Version dev-main und ist nicht getaggt. Es wird als Git- bzw. Pfad-Repository oder über den Contao Manager aus dem V‑T.ONE-Paketkanal installiert.

Unterstützte Versionen

Systemvoraussetzungen

• Eine lauffähige Contao-Installation (^5.3; das Lizenzfeld unter Contao → Einstellungen ist gegen die Quellen von Contao 5.7.12 geprüft, die Test-Suite läuft auf diesem Release; 5.3 ist durch die deklarierte Constraint abgedeckt, wurde hier aber nicht erneut ausgeführt) mit Datenbankzugriff.
• Composer für die Installation und Aktualisierung des Bundles.
• Schreibrechte auf das Contao-Projektverzeichnis var/ – insbesondere var/contao_security_suite/, wo die Suite private Laufzeitdaten außerhalb des öffentlichen Web-Roots ablegt.
• Für geplante Scans: ein eingerichteter Contao-Cron (contao:cron, per System-Cron oder Weblauf).
• Für die Schwachstellenprüfung der Erweiterungen: das PHP-Kommando composer muss auf dem Server ausführbar sein (die Suite ruft composer audit über einen Unterprozess auf).
• Optional ein Symfony-HTTP-Client. Fehlt er, funktioniert die Suite weiter; Lizenz-Operationen, die den Anbieter kontaktieren, melden dann „Dienst nicht erreichbar", ohne den gespeicherten Zustand zu verändern.

Installation

Anschließend die Datenbank aktualisieren und den Cache leeren:

Über den Contao Manager wird das Paket wie jedes andere Bundle hinzugefügt; der Manager führt Migration und Cache-Leerung selbst aus. Die Backend-Assets (CSS/JS) werden bei der Paketinstallation nach public/bundles/vtinnovationscontaosecuritysuite/ kopiert.

Es sind keine Einträge in config/config.yaml, keine manuelle Bundle-Registrierung und keine Änderungen an .htaccess oder an der Server-Konfiguration erforderlich. Die Bundle- und Routen-Registrierung übernimmt das mitgelieferte Contao-Manager-Plugin.

Backend-Zugriff und Berechtigungen

Die Suite wird über einen einzigen Einstiegspunkt erreicht: Einstellungen → Security Suite in der linken Backend-Navigation (Contao-Kerngruppe „System"). Dieser Eintrag öffnet das Security-Dashboard. Alle weiteren Bereiche werden über die horizontale Registerkartenleiste innerhalb jeder Seite angesteuert; sie sind aus der linken Navigation ausgeblendet, aber einzeln als Backend-Module registriert und werden von Contao einzeln rechtlich geprüft.

• Administratoren haben Zugriff auf alle Bereiche.
• Nicht-Administratoren benötigen die jeweiligen Backend-Modulrechte (security_suite_dashboard, security_suite_issues, …), die in der Benutzergruppe freigegeben werden. Zusätzlich entscheidet die Edition (siehe unten), ob ein Pro-Bereich überhaupt geöffnet werden kann.
• Jede verändernde Aktion ist ausschließlich per POST erreichbar, im Backend-Scope, mit Prüfung des Contao-Request-Tokens und einer erneuten serverseitigen Rechteprüfung.

Editionen: Nicht lizenziert, Free und Pro

Die Lizenz wird nicht im Einstellungen-Bereich der Suite eingetragen, sondern im normalen Contao-Backend unter Einstellungen → „V‑T.ONE Licence management". Dieser Abschnitt ist die gemeinsame Lizenzverwaltung aller V‑T.ONE-Produkte; die Contao Security Suite fügt dort ihr eigenes Feld hinzu, ohne die Felder anderer V‑T.ONE-Pakete zu verändern.

Die Lizenzprüfung erfolgt lokal und ohne Netzwerkaufruf. Schlägt die Auswertung aus irgendeinem Grund fehl, ist das Ergebnis nicht lizenziert (restriktiv bei Fehlern) – nie stillschweigend Free und nie ein defektes Backend. Ein abgelaufener oder widerrufener Pro-Datensatz fällt nur dann auf Free zurück, wenn die wirksame Lizenz dies ausdrücklich erlaubt. Beim Entfernen oder Ablaufen der Lizenz bleiben alle gespeicherten Findings, Ereignisse, Scans, Baselines, Konfigurationen und Verläufe erhalten.

Details – Lizenzzustände, Aktivierung, Aktualisierung, Entfernung und die vollständige Berechtigungsmatrix – stehen in Documentation/Lizenzierung.md.

Navigationsbereiche

Reihenfolge wie in der Registerkartenleiste der Suite:

Verifizierte Modulfunktionen

• Dashboard – rendert ausschließlich aus persistierten Scan-, Finding- und Ereignisdaten; Diagramme werden als Inline-SVG aus in PHP berechneter Geometrie erzeugt (keine Diagrammbibliothek, kein CDN, kein Frontend-Framework). Der Sichtbereich („24 h / 7 Tage / 30 Tage") und die Website-Auswahl bei mehreren Roots werden serverseitig ausgewertet.
• Sicherheitsprobleme – jede offene Feststellung erhält je nach Behebungsklasse eine Aktion: Problem beheben (automatisch), 2FA einrichten (Verweis auf die Contao-Benutzerverwaltung) oder einen geführten Hinweis mit Direktlink. Manuelle Entscheidungen (ignorieren, Risiko akzeptieren, wieder öffnen) sind reine Statusübergänge und ersetzen nie eine echte Behebung.
• Ereignisse – wiederholte identische Fehlversuchssignaturen (gleicher Typ, Ausgang, Benutzername, IP) innerhalb eines rollierenden Ein-Stunden-Fensters erhöhen einen Zähler auf einer Zeile, statt neue Zeilen anzulegen; das begrenzt das Zeilenwachstum unter Dauerlast.
• Login-Sicherheit – die Erkennungsschwellen (Zeitfenster, Mindestversuche je Benutzername und je IP, verteilte Angriffe, Password-Spraying, Erfolg nach Fehlversuchen) sind in den Einstellungen konfigurierbar.
• Aktiver Schutz (Pro) – eine Entscheidungs-Engine vor der Backend-Anmeldung von Contao. Sie nutzt die aufgezeichneten Fehlanmeldungs-Ereignisse (kein zweites Zählsystem) und wirkt auf die Quell-IP bzw. die Kombination aus IP und Benutzername – nie auf eine tl_user-Zeile: Ein angegriffener Benutzername erhöht den Schweregrad, sperrt das Konto aber nie. Eine bestehende Sperre – manuell oder automatisch, exakte IPv4/IPv6 oder CIDR – automatische Sperren werden bei jeder Backend-Anfrage durchgesetzt, einschließlich des Anmeldeformulars (GET), mit 429 und einer allgemeinen Meldung. Eine ausdrückliche manuelle Sperre wird zusätzlich auf Anwendungsebene bei jeder Contao/PHP-Anfrage durchgesetzt: Website-Frontend und Backend erhalten 403 bzw. die bestehende Backend-Schutzantwort; der Webserver kann direkt ausgelieferte statische Dateien weiterhin vor PHP bedienen. Die automatische Erkennung lässt sich abschalten, ohne von Hand gesetzte Sperren aufzuheben. Vorrang: Eine vertrauenswürdige Quelle umgeht automatische Sperren, eine ausdrückliche manuelle Sperre gewinnt immer (das Sperren einer vertrauenswürdigen Quelle verlangt eine Bestätigung). Quellen über dem Schwellwert werden mit 429 + Retry-After gedrosselt und – bei eingeschalteter automatischer Sperrung – temporär mit eskalierender Dauer gesperrt (erste, wiederholte, schwere Sperre). Administratoren können Quellen sperren, entsperren und als vertrauenswürdig markieren (exakte IPs oder CIDR-Bereiche, je eine Adresse oder ein Bereich pro Zeile) und den Angriffsmodus ein- und ausschalten – strengere Schwellen und längere Sperren, bis er ausgeschaltet wird. Vertrauenswürdige Quellen umgehen jeden automatischen Schutz. Solange eine Quelle gesperrt ist, erhöhen wiederholte Versuche nur einen Zähler auf ihrer Sperrzeile. Der Schutz ist ausfallsicher: Sind Lizenz, Einstellungen oder Sperrtabelle nicht verfügbar, wird die Anfrage zugelassen. Er vertraut nie eine beliebige IP, hebt nie eine Angriffssperre auf und schaltet den Angriffsmodus nie von selbst ab; der Aktive Schutz erzeugt keine Feststellungen, die Behebung schaltet ihn daher weder ein noch aus. Die Sperren liegen in tl_secsuite_ip_block.
• Korrelation verteilter Angriffe (Pro) – Feindliche Backend-Fehlversuche und sensible Frontend-Beobachtungen werden in gemeinsam genutzten Datenbank-Buckets über wechselnde IPv4/IPv6-Quellen, Kontoziele, kanonische Pfadfamilien, /24- bzw. /64-Netzwerksignale und siteweite Geschwindigkeit aggregiert. Das Standard-Korrelationsfenster beträgt 60 Sekunden und ist in den Einstellungen konfigurierbar. So werden verteilte Brute-Force-, Password-Spraying- und Credential-Angriffsmuster erkannt, ohne das Zielkonto zu deaktivieren; der Schutz bleibt auf Anwendungsebene und behauptet weder eine universelle Botnet-Abwehr noch Firewall-Durchsetzung.
• Stage 3: adaptive Challenge und Sitzungen (Pro) – Quellen mit erhöhtem, aber noch nicht blockwürdigem Risiko erhalten eine kurzlebige, sitzungsgebundene lokale Rechenaufgabe. Sie wird nicht bei normalen Administratoren oder vertrauenswürdigen Quellen angezeigt und ist kein dauerhafter IP-Vertrauensbeweis. Erfolgreiche Backend-Sitzungen speichern nur gehashte Sitzungs-/Browsermerkmale, IP, Zeitpunkte und ein nachvollziehbares Risikosignal. Ein IP-Wechsel allein beendet keine Sitzung; mehrere Signale erzeugen ein Ereignis „Verdächtige Sitzung“. Administratoren können andere Sitzungen beenden. Der Pro-Backend-Sperrmodus untersagt neue Backend-Anmeldungen von nicht vertrauenswürdigen Netzen, lässt bestehende Sitzungen und das öffentliche Frontend jedoch bestehen. Attack Mode verschärft die adaptive Prüfung, ist aber nicht dasselbe wie der Sperrmodus. Beides bleibt Anwendungsschutz und ersetzt keine Firewall.
• CSP – die vom Administrator gewählten Presets und Eigenregeln werden zu einer Policy kompiliert, gegen Contaos eigenen CSP-Parser validiert und in das native Feld tl_page.csp geschrieben (erzwungen; cspReportOnly und cspReportLog bleiben aus). Vor jeder Änderung wird der vorherige native Zustand in tl_secsuite_csp_backup gesichert. Nonces für Inline- Skripte bleiben vollständig Contao-nativ. „Auf Website-Root anwenden“ aktiviert Contaos eigene CSP auf der Wurzel selbst (enableCsp, csp, cspReportOnly, cspReportLog – kein manuelles Anhaken nötig), schreibt genau die zuvor angezeigte Richtlinie und liest die native Zeile innerhalb der Transaktion erneut; bei Abweichung wird alles zurückgerollt und kein Erfolg gemeldet.
• HTTP-Header – die konfigurierten Header werden über einen kernel.response-Listener (niemals über .htaccess) und nur dann gesetzt, wenn sie nicht bereits auf der Antwort vorhanden sind – ein von Webserver, Proxy oder anderem Bundle gesetzter Header bleibt unangetastet. HSTS sendet Contaos eigene Einstellung contao.security.hsts; ist sie aus, kann die Suite selbst ein zurückhaltendes Strict-Transport-Security senden (nur bei sicheren Anfragen, nur mit Nachweis, dass HTTPS funktioniert).
• Benutzer & Zugriff – ändert nie ein Konto oder die Contao-Authentifizierung; jeder Aktionslink zeigt auf den genauen Datensatz in Contaos eigener Benutzer- bzw. Gruppenverwaltung.
• Dateien – der Scan-Bereich ist begrenzt (public/, config/, templates/, die Projekt-Manifestdateien und die Bundle-Quelle) und in den Einstellungen erweiterbar bzw. einschränkbar. Die Integritäts-Baseline (tl_secsuite_file_baseline) speichert SHA-256-Hash, Größe und Änderungszeit – nie Dateiinhalte. Das Anlegen oder Aktualisieren der Baseline ist eine bewusste, bestätigte Backend-Aktion und wird als Ereignis protokolliert; ein Scan überschreibt die Baseline nie von selbst, und eine Behebung aktualisiert sie nie. Exponierte und verdächtige Dateien lassen sich nach var/contao_security_suite/quarantine/ verschieben (außerhalb jedes Document-Roots, mit Manifest, wiederherstellbar) oder löschen – Löschen ist immer eine eigene, ausdrücklich bestätigte Aktion je Datei und nie Teil von „Alle beheben“. Eine Datei wird nie geöffnet oder ausgeführt.
• Erweiterungen – „Advisory-Daten nicht verfügbar" wird deutlich von „keine Schwachstellen" unterschieden. Die Netzwerknutzung von composer audit und die Einbeziehung transitiver Abhängigkeiten sind in den Einstellungen abschaltbar.
• System – die Anwendung schreibt nur projektlokale Dateien: die .user.ini im Document-Root (unabhängige Direktiven bleiben erhalten, nur wo PHP sie beachtet – FPM / FastCGI) und .env.local. Eine globale php.ini, die Webserver-Konfiguration und Zertifikate werden nie angefasst. Für Werte, die sich aus der Anwendung heraus nicht ändern lassen (allow_url_include, expose_php selbst – PHP_INI_SYSTEM), nennt der Bereich die konkrete serverseitige Änderung; eine Änderung, die erst später wirkt, wird als „Behebung ausstehend“ gezeigt und behauptet keinen Erfolg, bis die Laufzeit sie beim nächsten Scan bestätigt.
• Berichte – jeder Export wird als Sicherheitsereignis protokolliert; CSV-Ausgaben sind gegen Formelinjektion abgesichert; die Druckansicht enthält keine Geheimnisse.
• Einstellungen – alle Schlüssel sind zentral in einem Schema deklariert und typisiert; ein Wert außerhalb seiner Grenzen wird abgewiesen. Sicherheitsrelevante Änderungen werden in tl_secsuite_setting_log protokolliert (Werte als kurze Zeichenketten, nie Geheimnisse). Ein fehlender Schlüssel bedeutet „codierter Standardwert", sodass eine frische Installation sich wie zuvor verhält.

Aktiver Schutz — Stage 2

Die Pro-Edition erkennt zentral bekannte Sondierungspfade wie /.env, /.git/, wp-login.php, phpmyadmin, Datenbank-Dumps, Backup-Archive, Shell-Dateien, Composer-Dateien und Editor-Backups. Ein einzelner normaler 404 wird nicht als Angriff gewertet; wiederholte unterschiedliche Signaturen erhöhen eine lokale, deterministische Quellenreputation mit 24-Stunden-Halbwertszeit. Backend-Fehler, Password-Spraying, Frontend-Missbrauch, geblockte Versuche und gefährliche Uploads werden in einem begrenzten Quellenprofil aggregiert statt als eine Datenbankzeile je Request gespeichert.

Passwort-Reset, Mitglieder-Login, Registrierung und identifizierbare Contao-Formulare erhalten getrennte konfigurierbare Kurzzeitfenster. Gefährliche Erweiterungen, doppelte Erweiterungen und offensichtlicher serverseitiger Inhalt werden aus dem temporären Multipart-Upload vor der Contao- Speicherung abgewiesen. Benachrichtigungen verwenden Contao's/Symfonys konfigurierten Mailer und werden mit persistentem Cooldown dedupliziert; ein Mailfehler unterbricht nie den Schutz.

Anwendungsseitiger Schutz sieht nur Requests, die PHP/Contao erreichen. Eine von nginx/Apache direkt ausgelieferte statische .zip, .env oder Backup-Datei kann nicht nachträglich abgefangen werden; dafür bleibt der Files-Scanner zuständig. Stage 2 ersetzt keine Netzwerk- oder Webserver-Firewall und vertraut nicht auf User-Agent-Namen. Details stehen in Documentation/Aktiver-Schutz-Stage2.md.

Sicherheitsprüfungen und Score

Die Suite registriert 27 unabhängige Sicherheitsprüfungen in zehn Sicherheitsdomänen. Jede Prüfung wertet ausschließlich lokalen Contao-/Anwendungszustand aus, läuft isoliert (eine fehlschlagende Prüfung stoppt die übrigen nicht) und liefert ein einzelnes Ergebnis. Der Score wird je Domäne aggregiert und daraus ein Gesamtwert von 0–100 gebildet, der ausdrücklich nur die bisher implementierten Prüfungen widerspiegelt.

Die vollständige Referenz aller 27 Prüfungen – erkannter Zustand, Sicherheitsdomäne, Behebungsklasse, Verifikation und Rollback – steht in Documentation/Sicherheitspruefungen.md.

Einen Scan auslösen

Ein Scan liest nur Konfiguration und zeichnet Findings auf. Er ändert nichts an der Website. Er braucht eine gültige signierte Free- oder Pro-Lizenz; die Prüfung gilt für jeden Einstiegspunkt (Dashboard, Befehlszeile, geplante Scans).

Behebung von Sicherheitsproblemen (Pro)

Das Prinzip: Wenn die Security Suite den zugrunde liegenden Zustand sicher korrigieren kann, bietet Pro eine echte Aktion in der Suite. Manuell bleibt nur, was wirklich einen Menschen oder eine Infrastruktur erfordert, die die Anwendung nicht erreicht – und selbst dann nennt die Suite die genauen Schritte. Die Free-Edition hat die Analyse und keine Behebung; jeder Fix-Endpunkt erzwingt Pro auf dem Server.

Eine Klasse ist nie ein Versprechen, das der Code nicht halten kann: Eine Prüfung zählt nur dann als „behebbar“, wenn ein registrierter Handler existiert und in dieser Umgebung gerade ausgeführt werden kann (seine Voraussetzungen gelten). Andernfalls wird sie ehrlich als „Prüfung erforderlich“ mit Begründung gemeldet.

Was jede Prüfung kann

Abdeckung nach Klasse: 27 Prüfungen – 1 AutoSafe, 14 AutoConfirm, 7 Assisted, 4 Manual, 1 None. Ein Test zählt jede registrierte Prüfung auf und schlägt fehl, wenn eine ohne ausdrückliche Behebungsentscheidung hinzukommt.

Wie eine Behebung abläuft

• Einzel-Fix – eine Schaltfläche je offener Feststellung, benannt nach dem, was sie wirklich tut (Header korrigieren, CSP anwenden, Datei sichern, Rechte korrigieren, Paket aktualisieren, Paket auflösen, 2FA einrichten, Berechtigungen prüfen, Anleitung ansehen, …). Die Detailansicht zeigt das erkannte Problem, warum es wichtig ist, was sich ändert, die Auswirkung auf die Kompatibilität, ob ein Rollback möglich ist und wie es verifiziert wird.
• Bereichs-„Alle beheben“ – oben in jedem Bereich, der Feststellungen besitzt, vom selben Koordinator wie alles andere gesteuert. Es enthält die sicheren und (nach einer Bestätigung) die bestätigungspflichtigen Behebungen und führt „Prüfung erforderlich“ und manuelle Punkte getrennt.
• Globales „Alle beheben“ auf dem Dashboard – ein Dialog mit vier Gruppen: automatisch behoben, nach Ihrer Bestätigung hier behoben, Prüfung erforderlich und manueller Eingriff erforderlich. Eine Bestätigung autorisiert den ganzen Lauf – nie ein Dialog je Feststellung. Die Zwei-Faktor-Authentifizierung ist immer ausgenommen.
• Jede Behebung durchläuft Vorschau → Anwenden → Verifizieren → erneuter Scan → Auflösen. Ein Schreibvorgang ist nie ein Beweis. Ein Handler beweist die Behebung entweder selbst (Live-Antwort neu abrufen, Dateien zurücklesen, ein frisches composer audit) oder die Prüfung hinter der Feststellung wird wiederholt. Wird eine Änderung korrekt geschrieben und zurückgelesen, wirkt aber erst später (.user.ini, .env.local), wechselt die Feststellung auf „Behebung ausstehend“ – sie ist nicht behoben –, und der nächste Scan löst sie auf oder öffnet sie nach 24 Stunden wieder, falls die Wirkung nie eintrat.
• Fehlerbehandlung – eine fehlgeschlagene oder nicht verifizierte Behebung hält die Feststellung offen, behält einen kurzen Fehlerkontext, erzeugt ein Sicherheitsereignis und bricht die unabhängigen Behebungen eines Sammellaufs nie ab. Weder Stack-Trace noch Geheimnis erreichen die Oberfläche.
• Rollback wird nur angeboten, wo die Suite den vorherigen Zustand besitzt (CSP, Header-Konfiguration, Suite-Einstellungen, projektlokale PHP-Konfiguration, .env.local, Quarantäne-Dateien, Dateimodi, Composer-Dateien). Der Verlauf steht in tl_secsuite_remediation; der Schnappschuss enthält nie Geheimnisse.
• Nie eine Behebung: Ignorieren, Risiko akzeptieren, Schweregrad ändern, eine Prüfung deaktivieren, die Integritäts-Baseline automatisch aktualisieren, eine Warnung unterdrücken oder eine Feststellung von Hand als behoben markieren ändern nur den Status – sie ändern nicht den zugrunde liegenden Zustand und zählen nie als Behebung.
• Jede Meldung, Vorschau, Warnung, Bestätigung, Anleitung und jeder Fehlertext ist übersetzt (EN/DE); kein sichtbarer Text ist in JavaScript fest hinterlegt.

Was bei einem Menschen bleibt – und warum

• 2FA-Einrichtung – jeder Kontoinhaber muss sich selbst einrichten; die Suite erzeugt nie ein Geheimnis.
• Administratorrechte und Gruppenberechtigungen – eine Entscheidung über Menschen, keine Konfiguration.
• Änderungen der Dateiintegrität – von Natur aus mehrdeutig; die Baseline hält Hashes, keine Kopien.
• Aufgegebene Pakete und Composer-Migrationen, deren Kompatibilität die Suite nicht beweisen kann.
• Externe TLS-/Webserver-/CDN-Konfiguration – Zertifikate, Weiterleitungen und Header-Regeln außerhalb der Anwendung; die Suite zeigt genau, was zu ändern ist.
• PHP- und Contao-Upgrades sowie ein fehlender CSRF-Token-Manager.

Kommandozeilenbefehle

security-suite:scan braucht eine gültige signierte Free- oder Pro-Lizenz (sonst Exit-Code 5); security-suite:purge-events ist Datenpflege und läuft unabhängig davon. Verändernde Aktionen (Behebung, Konfiguration, Export) gibt es nicht als CLI-Pfad.

Geplante Aufgaben (Cron)

Beide setzen einen laufenden Contao-Cron voraus (contao:cron). Wird der Cron auf dem Server nicht ausgelöst, geschieht nichts – und der Einstellungen-Bereich sagt das offen und verweist auf den direkten Befehl security-suite:scan.

Laufzeitverzeichnisse

Datenbanktabellen

tl_secsuite_scan, tl_secsuite_finding, tl_secsuite_finding_history, tl_secsuite_event, tl_secsuite_remediation, tl_secsuite_snapshot, tl_secsuite_csp_config, tl_secsuite_csp_backup, tl_secsuite_header_config, tl_secsuite_file_baseline, tl_secsuite_setting, tl_secsuite_setting_log, tl_secsuite_ip_block, tl_secsuite_source, tl_secsuite_request_window, tl_secsuite_notification, tl_secsuite_session, tl_secsuite_external_block, tl_secsuite_intelligence und tl_secsuite_lockdown (Zustand des Aktiven Schutzes, der Sitzungen, der Edge-Durchsetzung und der Intelligence). Alle sind reine Speicher-Tabellen (keine BE_MOD-Tabellen, keine Bearbeitung von Hand). Abgelaufene/alte Betriebszeilen werden täglich bereinigt; Einstellungen, Schnappschüsse und CSP-Backups bleiben Konfigurations- bzw. Rollback-Zustand.

Externe Kommunikation

Die lokale Analyse benötigt keine fremde externe Abhängigkeit. Optionale externe Kommunikation ist standardmäßig deaktiviert und findet nur in diesen klar abgegrenzten Fällen statt:

• Lizenzaktivierung und „Lizenz aktualisieren" – definierte Operationen, ausgelöst durch einen Administrator im Contao-Einstellungen-Bereich, gerichtet an den vertrauenswürdigen V‑T.ONE-HTTPS-Dienst. Der Browser kommuniziert nie direkt mit dem Anbieter.
• Anbieter-initiierte Lizenzzustellung – ein einziger nicht im Backend liegender Endpunkt, über den der Anbieter ein vollständiges, signiertes Lizenzpaket zustellt. Die Zustellung ist authentifiziert und integritätsgeschützt.
• composer audit – wird bei der Schwachstellenprüfung der Erweiterungen als Unterprozess aufgerufen und kann dabei den Composer-Advisory-Dienst kontaktieren. In den Einstellungen abschaltbar (advisory_network_enabled).
• Live-Prüfungen (effektive HTTP-Header, öffentliche Erreichbarkeit sensibler Dateien) – senden HTTP-Anfragen an die eigene Website dieser Installation, nur während eines Scans oder einer manuellen Aktion. Die Ergebnisse werden in tl_secsuite_snapshot zwischengespeichert.
• Paketbehebung – ein vom Administrator bestätigtes „Paket aktualisieren“ / „Paket auflösen“ startet Composer als Unterprozess (composer update <Paket> / composer install, ohne Skripte, ohne Plugins), der die konfigurierten Composer-Repositories kontaktiert.

Protokollierung

Die Suite protokolliert über den eigenen Monolog-Kanal contao_security_suite (sofern Monolog verfügbar ist). In Ereignissen, im Behebungsverlauf und in Protokollen stehen keine Geheimnisse: Der Lizenzschlüssel wird nie zurückgegeben (nur seine letzten Zeichen werden angezeigt), Header-/CSP-Snapshots enthalten Konfigurationswerte, aber keine Zugangsdaten, und Einstellungswerte werden als kurze Zeichenketten geführt. IP-Adressen können über die Einstellung privacy_mask_ips maskiert werden; Berichte können Benutzernamen maskieren und IP-Adressen ausschließen.

Sicherheitsmodell

Verifizierte Kontrollen:

• Zugriffssteuerung – jeder Bereich ist ein einzeln rechtlich geprüftes Contao-Backend-Modul.
• Serverseitige Berechtigungsdurchsetzung – jede Pro-Fähigkeit wird an ihrer eigenen Grenze geprüft (Backend-Bereiche, verändernde Aktionen, Behebung, Befehlszeile und Hintergrundaufgaben).
• Authentifizierte Anfragen – jede verändernde Aktion ist POST-only, im Backend-Scope, mit Contao-Request-Token; kein GET-Pfad verändert Zustand.
• Restriktiv bei Fehlern – ein Lizenzproblem entlizenziert (kein Scan, keine Pro-Funktionen); es macht das Backend nie defekt und löscht nie Daten.
• Private Ablage – der Lizenzdatensatz liegt unter var/, außerhalb des Web-Roots.
• Integritäts- und Authentizitätsprüfung – ausgetauschte Lizenzdaten werden authentifiziert und integritätsgeschützt übertragen; ein nicht verifizierbares Paket wird verworfen und der installierte Zustand bleibt unverändert.
• Sicheres Fehlverhalten – der CSP-Writer schreibt eine ungültige Policy nie; der tl_page-Schreibvorgang, das Backup und die Konfigurationsaktualisierung laufen in einer Transaktion; die Baseline wird von einem Scan nie überschrieben.
• Geschwärzte Protokollierung – siehe oben.

Unterscheiden Sie:

• Garantiertes Verhalten – durch Code festgelegt (z. B. „ein Scan ändert nichts", „POST + Token für jede Aktion", „ungültige CSP wird nie geschrieben").
• Bedingtes Verhalten – hängt von der Umgebung ab (z. B. geplante Scans brauchen einen laufenden Contao-Cron; composer audit braucht ein ausführbares composer).
• Best-effort – z. B. das Invalidieren des Seiten-Cache-Tags nach einer CSP-Änderung.
• Bekannte Grenzen – siehe unten.

Die Suite trifft keine Aussage darüber, dass ein Lizenz- oder Sicherheitssystem nicht umgangen werden könne.

Deployment und Cache

Nach jeder Aktualisierung des Bundles:

Über den Contao Manager werden beide Schritte automatisch ausgeführt. Ein separater Build-Schritt für die Backend-Assets ist nicht nötig; sie werden bei der Paketinstallation nach public/bundles/ kopiert.

Tests

Die Testsuiten sind in phpunit.xml.dist definiert (unit und integration).

php tools/remediation-coverage.php gibt die Behebungsklassifizierung jeder registrierten Prüfung mit dem sie stützenden Handler bzw. der Anleitung aus (gesamt / AUTO_SAFE / AUTO_CONFIRM / ASSISTED / MANUAL / NONE); tests/Remediation/RemediationCoverageTest.php schlägt fehl, wenn eine Prüfung ohne ausdrückliche Behebungsentscheidung hinzukommt oder ein Behebungssatz in EN oder DE fehlt.

Fehlerbehebung

Tatsächliche bekannte Einschränkungen

• Die SSL/TLS-Domäne nutzt eine begrenzte HTTPS-Zertifikatsprüfung. Sie kann Erreichbarkeit, Ablauf und Hostnamenabweichungen melden, ist aber kein vollständiger TLS-Scanner, prüft keine Cipher-Suiten und behauptet keinen SSL-Labs-Score.
• contao.version und server.php_version melden die installierten Versionen, vergleichen sie aber noch nicht gegen eine gepflegte Advisory-Quelle; die Zusammenfassung sagt das offen.
• headers.https_context wertet das Anfrageschema und das „SSL verwenden“-Flag je Root aus; es prüft weder Zertifikate noch Weiterleitungen. Das sind Angelegenheiten von Webserver / CDN, die die Suite nicht ändern kann – die Anleitung sagt das.
• expose_php und allow_url_include (PHP_INI_SYSTEM) lassen sich aus der Anwendung heraus nicht ändern. Die Suite entfernt den X-Powered-By-Header und leitet den Rest an; sie behauptet keinen Erfolg ohne Laufzeitbestätigung.
• Die .user.ini wird nur unter FPM / FastCGI / CGI und nur alle user_ini.cache_ttl Sekunden gelesen; Behebungen von PHP-Laufzeit und Session-Cookies sind daher bis zum nächsten Scan „Behebung ausstehend“. Eine echte Server-Umgebungsvariable überschreibt .env.local.
• Die Paketbehebung braucht ein ausführbares composer und ein beschreibbares vendor/; ohne beides wird der genaue Composer-Befehl gezeigt. Die Nacharbeiten von Contao (Cache-Aufwärmen, Datenbankprüfung) führt die Suite nicht aus.
• Bewusst nie automatisiert: 2FA-Einrichtung, Administratorrechte, Akzeptieren der Integritäts-Baseline, Ersatz aufgegebener Pakete, PHP-/Contao-Upgrades, TLS- und Webserver-Konfiguration.
• Geplante Scans hängen von einem laufenden Contao-Cron ab.
• Anwendungsschutz kann eine statische Datei nicht abfangen, die nginx/Apache vor PHP ausliefert; dafür sind Server-Hinweise und die Files-Findings vorgesehen.
• Cloudflare und Threat Intelligence sind optional, ergänzend und ausfallsicher. Externe Aufrufe werden eingeplant oder ausdrücklich ausgelöst; der lokale Schutz wartet nicht darauf.

Lizenz und Urheberrecht

Proprietär. © V&T Innovations Team. Siehe https://www.v-t.one.

Diese Software ist kein Open-Source-Produkt. Die Nutzung des Pro-Funktionsumfangs setzt eine gültige, an die Installationsdomäne gebundene Lizenz voraus.

Weiterführende Dokumentation

• README.en.md – englische Fassung dieses Dokuments.
• Documentation/Sicherheitspruefungen.md – vollständige Referenz der 27 Sicherheitsprüfungen.
• Documentation/Lizenzierung.md – Editionen, Lizenzzustände, Aktivierung und Berechtigungsmatrix.
• Documentation/Konfiguration.md – alle Einstellungen, Aufbewahrung, geplante Scans, CSP- und Header-Arbeitsablauf.
• Documentation/Aktiver-Schutz-Stage2.md, Stage4 – Aktiver Schutz im Detail; Abnahmeprotokolle: Abnahmetest, Stage-4-Abnahmetest.
• Documentation/Release-Bereitschaft.md – Release-Audit und Lizenzmatrix (PASS / TEILWEISE / NICHT LIVE GETESTET).