TYPO3 auf Kubernetes unter IT-Grundschutz, Teil 13: TYPO3 selbst härten

01 — Der Zugang zum Backend

Das Backend ist die wertvollste Tür einer TYPO3-Installation. Wer hier hineinkommt, ändert Inhalte, lädt Dateien hoch und legt Benutzer an. APP.3.1.A1 verlangt deshalb eine angemessene Authentisierung und Grenzwerte für fehlgeschlagene Anmeldungen.

Mehr-Faktor-Anmeldung erzwingen

TYPO3 bringt TOTP und Recovery-Codes im Core mit. Mit BE.requireMfa wird die zweite Stufe zur Pflicht. Der Wert 1 gilt für alle Benutzer, der Wert 3 nur für Administratoren. Bei hohem Schutzbedarf ist 1 die ehrliche Wahl. Auch ein Redaktionskonto kann erheblichen Schaden anrichten.

// config/system/additional.php
$GLOBALS['TYPO3_CONF_VARS']['BE']['requireMfa'] = 1;
$GLOBALS['TYPO3_CONF_VARS']['BE']['loginRateLimit'] = 5;
$GLOBALS['TYPO3_CONF_VARS']['BE']['loginRateLimitInterval'] = '15 minutes';
$GLOBALS['TYPO3_CONF_VARS']['BE']['sessionTimeout'] = 3600;
$GLOBALS['TYPO3_CONF_VARS']['BE']['cookieSameSite'] = 'strict';

Das Grenzwert-Paar begrenzt fehlgeschlagene Anmeldungen pro Adresse. Beide Werte entsprechen der Voreinstellung. Wichtig ist, dass niemand sie lockert. Die Sitzung endet nach einer Stunde ohne Aktivität statt nach den voreingestellten acht Stunden.

Anmeldung über den Identity Provider

Noch besser ist ein Backend, das gar keine eigenen Passwörter verwaltet. Eine Anmeldung per OAuth2 oder OpenID Connect verlagert Passwort, MFA und Sperrung zum zentralen Identity Provider. Wer das Unternehmen verlässt, verliert den Backend-Zugang zusammen mit dem Konto.

Ein typischer Stolperstein in TYPO3 14: Manche Erweiterungen bauen die Rückruf-Adresse noch auf /typo3/index.php auf. Diesen Einstiegspunkt gibt es nicht mehr. Die Anmeldung läuft dann ins Leere, oft ohne klare Fehlermeldung. Ein Test des kompletten Anmeldewegs gehört deshalb zu jedem Update.

Den Weg zum Backend verengen

Das Backend muss nicht von überall erreichbar sein. BE.IPmaskList lässt nur Anfragen aus festgelegten Netzen zu. Alternativ sperrt der Reverse Proxy den Backend-Pfad für alle anderen Adressen. Mit BE.entryPoint kann das Backend außerdem auf einem eigenen Host laufen. Dann lassen sich Freigaben, Zertifikate und Grenzwerte für Redaktion und Besucher getrennt steuern.

02 — Rechte, Freigaben und das Install-Tool

Die meisten Redaktionskonten brauchen keine Administratorrechte. Backend-Gruppen mit genau den Tabellen, Feldern und Seitenbäumen einer Rolle begrenzen den Schaden eines übernommenen Kontos. System-Maintainer, also Konten mit Zugriff auf die Systemeinstellungen, sollten sich an einer Hand abzählen lassen.

Bei eigenen Backend-Modulen lohnt ein zweiter Blick. TYPO3 14 kennt für den Modulzugriff nur noch bestimmte Werte. Ein veralteter Eintrag sperrt das Modul still für alle, auch für Administratoren. Das ist sicher, fällt aber erst auf, wenn jemand das Modul braucht.

Vier Augen mit Workspaces

Workspaces trennen Bearbeitung und Veröffentlichung. Änderungen landen zuerst in einem Entwurf, eine zweite Person gibt sie frei. Das schützt die Integrität der Inhalte. Nebenbei entsteht ein Nachweis, wer was wann freigegeben hat.

Dasselbe Prinzip gilt für KI-Agenten, die über MCP auf TYPO3 zugreifen. Sie melden sich pro Person per OAuth an, nicht mit einem geteilten Schlüssel. Sie schreiben nur in den Workspace. Veröffentlichen dürfen sie nur, wenn das ausdrücklich eingeschaltet ist. So bleibt jede Änderung einem Menschen zugeordnet.

Das Install-Tool bleibt zu

Im Betrieb wird das Install-Tool nicht gebraucht. Ist BE.installToolPassword leer, verweigert TYPO3 den Zugang vollständig. Die Admin-Werkzeuge im Backend sehen nur System-Maintainer. Wartungsaufgaben wie Datenbank-Updates laufen über die Konsole im Deployment, wie in Teil 8 beschrieben.

03 — Eine Web Application Firewall vor TYPO3

Bei erhöhtem Schutzbedarf sieht APP.3.1.A20 eine Web Application Firewall vor. Im Cluster sitzt sie am besten im Reverse Proxy des Mandanten. Dort sieht sie jede Anfrage, bevor PHP sie verarbeitet.

Grenzwerte, die Missbrauch bremsen

Rate Limits pro Client setzen die Grenzwerte aus APP.3.1.A1 und A7 schon vor TYPO3 um. In Caddy geht das mit dem Rate-Limit-Modul:

@login path /typo3/login
rate_limit @login {
    zone backend_login {
        key    {client_ip}
        events 5
        window 60s
    }
}

Bewährt haben sich drei Zonen mit unterschiedlicher Strenge. Die Anmeldung bekommt wenige Versuche pro Minute. Das Backend bekommt mehr Spielraum, weil Redakteure viele Anfragen erzeugen. Das Frontend bekommt so viel, dass Feeds, Suchmaschinen und legitime Crawler nicht leiden. Genau diese Abwägung verlangt A7 ausdrücklich.

Die echte Client-IP

Hinter einem Ingress sieht der Proxy zunächst nur dessen Adresse. Dann gelten alle Besucher als ein einziger Client. Die erste Rate-Limit-Regel sperrt die ganze Website, oft auch die eigene Redaktion. Die Lösung ist trusted_proxies für das Pod-Netz. Erst dann übernimmt der Proxy die echte Adresse aus X-Forwarded-For, und nur von dort.

Verhalten statt Signaturen

CrowdSec ergänzt die Grenzwerte. Es wertet die Zugriffsprotokolle aus, erkennt Muster wie Scans oder Brute Force und sperrt die Quelle. Offensichtliche Scanner-Pfade wie wp-login.php beantwortet der Proxy direkt mit 404, ohne PHP zu starten. Nicht benötigte HTTP-Methoden lehnt er ab. Ein PURGE für den Cache ist nur aus dem internen Netz erlaubt.

Eine Eigenheit sollte man kennen. Hängt die Verbindung zwischen Proxy und CrowdSec still, lässt der Proxy je nach Einstellung alles durch oder nichts. Beides fällt ohne eigene Prüfung erst spät auf. Ein Alarm auf den Zustand des Bouncers macht den Ausfall sichtbar. Eine Liveness-Probe wäre hier falsch: Fiele CrowdSec aus, starteten alle Proxy-Pods gleichzeitig neu. Nach jedem größeren TYPO3-Update gehören die Regeln außerdem auf den Prüfstand, wie es A20 verlangt.

04 — Header, Fehlerseiten und Updates

HTTP-Header nach APP.3.1.A21

Der Baustein nennt die Header ausdrücklich: Content-Security-Policy, Strict-Transport-Security, Content-Type, X-Content-Type-Options und Cache-Control. Die meisten setzt der Proxy für alle Mandanten gleich. Die Content-Security-Policy kennt dagegen nur die Anwendung selbst. TYPO3 bringt dafür eine eigene API mit. Pro Site beschreibt eine csp.yaml, welche Quellen erlaubt sind. Das Feature security.frontend.enforceContentSecurityPolicy setzt die Policy im Frontend durch.

Auch Cookies gehören dazu. A21 verlangt secure, httponly und SameSite. TYPO3 setzt das Backend-Cookie standardmäßig mit SameSite=strict. Eigene Cookies aus Extensions verdienen dieselbe Prüfung.

Weder Produkt noch Version verraten

APP.3.2.A12 verlangt Antworten ohne Produktnamen und Versionsnummer. Der Proxy entfernt den Server-Header, der generator-Meta-Tag nennt keine Version. Fehlerseiten zeigen nur eine allgemeine Meldung mit einer eindeutigen Kennung. TYPO3 liefert genau das: eine kurze Fehlerseite mit Request-ID. Über diese ID findet der Betrieb den Fehler im zentralen Log aus Teil 11. Der Besucher sieht keine Details, solange SYS.displayErrors in Produktion auf 0 steht.

Updates als fester Ablauf

Die TYPO3 Security Advisories erscheinen gebündelt und angekündigt. Wer sie abonniert und das CVE-Gate aus Teil 4 nutzt, weiß am selben Tag, ob eine Installation betroffen ist. Extensions verdienen dabei besondere Aufmerksamkeit, denn nicht jede ist so gepflegt wie der Core. Ungenutzte Extensions fliegen raus. Code, der nicht installiert ist, hat keine Lücken. Einmal im Jahr und nach größeren Umbauten kommt ein Penetrationstest dazu, wie ihn APP.3.1.A22 vorsieht.

Bezug zum IT-Grundschutz

• APP.3.1.A1 Authentisierung: MFA, Anmeldung über den Identity Provider, Grenzwerte für Fehlversuche.
• APP.3.1.A7 Schutz vor unerlaubter automatisierter Nutzung: Rate Limits mit Rücksicht auf Feeds und Crawler.
• APP.3.1.A12 Sichere Konfiguration: nicht benötigte Methoden und Funktionen abgeschaltet, Install-Tool geschlossen.
• APP.3.1.A21 Sichere HTTP-Konfiguration: Header und Cookie-Attribute.
• APP.3.1.A22 Penetrationstest und Revision.
• APP.3.1.A20 Einsatz von Web Application Firewalls bei erhöhtem Schutzbedarf.
• APP.3.2.A12 Umgang mit Fehlern und Fehlermeldungen sowie APP.3.2.A18 Schutz vor Denial-of-Service-Angriffen.

Fazit

Die Plattform schützt TYPO3, ersetzt aber nicht den Schutz der Anwendung selbst. MFA und ein Identity Provider sichern das Backend. Rollen und Workspaces begrenzen jedes Konto, auch das eines KI-Agenten. Eine WAF mit Grenzwerten fängt Missbrauch ab, bevor PHP startet. Header, Fehlerseiten und ein fester Update-Ablauf schließen, was übrig bleibt. Damit sind die Anforderungen aus APP.3.1 belegbar, bis hin zur WAF für hohen Schutzbedarf.

Weiter mit Teil 14: Das Referenz-Chart, das alle Bausteine der Serie in einem offenen Helm-Chart zusammenführt. Die Übersicht aller Teile und die Einordnung in die Grundschutz-Bausteine stehen in Teil 1: Welche Bausteine wirklich greifen. Zurück zu Teil 12: Verfügbarkeit bei hohem Schutzbedarf.