TYPO3-Firewall Eine neue Sicherheitsebene für Ihre Anlage
Die Erweiterung „flowd/typo3-firewall“ integriert das Phirewall-Paket und erweitert das TYPO3-CMS um eine echte WAF auf Anwendungsebene – IP-Sperren, Ratenbegrenzung, Fail2ban und die Verwaltung von Mustern über das Backend
Kurz gesagt
Was ist das:
TYPO3 Firewall (flowd/typo3-firewall) ist eine neue Erweiterung von Sascha Egerer, die das Open-Source-Paket Phirewall in TYPO3 integriert. Es bietet Web-Application-Firewall-Funktionen auf PHP-Anwendungsebene – ohne dedizierten Server, ohne Cloudflare, ohne WAF-Hosting.
Hauptfunktionen:
Blockierung nach IP, CIDR, URL-Pfad, Headern und Regex. Fail2ban (vorübergehende Sperre nach Missbrauch). Rate Limiting mit Headern. Verwaltung von Mustern über das TYPO3-Backend ohne Deployment. Benutzerdefinierte Antworten für blockierte Anfragen.
Für wen:
Websites, die der NIS2 unterliegen (Krankenhäuser, Gemeinden, Behörden), Shops, die der PAD/EAA unterliegen, NGO-Websites, die sensible Daten verarbeiten, jede TYPO3-Website ohne Zugriff auf WAF auf Serverebene.
Anforderungen:
TYPO3 13+, PHP 8.2+. Für Rate Limiting und Fail2Ban: persistenter Cache (APCu oder Redis – in der Produktion wird Redis empfohlen).
Version:
0.3 (letzte Aktualisierung: 19. Mai 2026). Status: aktiv weiterentwickelt, Quellcode auf GitHub verfügbar.
Die Sicherheit von Websites in TYPO3 wurde traditionell auf Serverebene oder über ein CDN gewährleistet – Cloudflare, ModSecurity, das systemeigene fail2ban sowie Nginx-Regeln. Das sind zwar effektive Lösungen, erfordern jedoch Zugriff auf die Infrastruktur, über den wir oft nicht verfügen: bei Shared Hosting, bei Managed Hosting und in Umgebungen, in denen der IT-Betrieb einem anderen Team als dem Redaktionsteam obliegt.
Die neue Erweiterung flowd/typo3-firewall ändert diesen Ansatz. Sie stellt dem TYPO3-Administrator Web Application Firewall-Tools auf PHP-Anwendungsebene zur Verfügung – die in derselben Umgebung wie das CMS selbst laufen. Ohne Zusammenarbeit mit dem Serveradministrator, ohne zusätzliche Dienste, ohne monatliche Gebühren. Dies ist eine wesentliche Änderung, insbesondere im Zusammenhang mit der Novellierung des Gesetzes über die Sicherheit kritischer Infrastrukturen (NIS2) und des polnischen Gesetzes über Barrierefreiheit, die ab 2025–2026 in Kraft treten und die Umsetzung konkreter Sicherheitsmaßnahmen erfordern.
Was kann die TYPO3-Firewall?
Die Erweiterung besteht aus zwei Hauptkomponenten: der Integration in das Phirewall-Paket (Ausführungsmodul) und dem Backend-Modul (Regelverwaltung). Zusammen bieten sie folgende Funktionen.
Sperrlisten statische Sperrlisten
Du kannst Anfragen anhand verschiedener Kriterien blockieren: IP-Adresse (einzelne Adresse oder CIDR-Bereich), URL-Pfad (z. B. /wp-admin – ein typisches Ziel von Scannern, die nach WordPress suchen), Query-String-Parameter (z. B. xdebug, option=com_), HTTP-Header, beliebige reguläre Ausdrücke. Die Regeln werden sofort nach dem Hinzufügen wirksam, ohne dass ein Neustart des Servers erforderlich ist.
Fail2ban vorübergehende Sperre nach Missbrauch
Es funktioniert genauso wie das klassische systemweite Fail2ban, jedoch auf Anwendungsebene. Du legst den Schwellenwert (Threshold), das Zeitfenster und die Dauer der Sperre fest. Beispiel: Wenn eine IP-Adresse innerhalb von 10 Sekunden mehr als 5 Anfragen an /search sendet, wird sie für 60 Sekunden gesperrt. Dies verhindert, dass Bots die Suchmaschine scannen und Brute-Force-Angriffe auf Anmeldeformulare durchführen.
Ratenbegrenzung (Drosselung) (Drosselklappen)
Globale Begrenzung der Anzahl von Anfragen pro Schlüssel (IP, Benutzer, Sitzung) innerhalb eines bestimmten Zeitfensters. Beispiel: 10 Anfragen alle 10 Sekunden pro IP. Es können Rate-Limit-Header (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After) aktivieren – dann sieht der Client, wann er die Anfrage wiederholen kann. Dies ist wichtig für die API-Integration.
Allow2ban auf den Spuren des Positiven wandeln
Eine weniger bekannte, aber nützliche Funktion – das Sperren von Keys, die in bestimmte „Fallen“ tappen. Beispiel: Jeder Bot, der versucht, auf /robots-trap-url zuzugreifen (ein für Benutzer versteckter Link, der nur im HTML-Quellcode sichtbar ist), wird sofort gesperrt. Ein Honeypot auf Anwendungsebene.
Benutzerdefinierte Antworten Eigene Antworten für gesperrte Nutzer
Standardmäßig erhält eine blockierte Anfrage den Status 403 mit einem minimalen Body. Du kannst eine eigene Antwort definieren – einen anderen Status, JSON, HTML oder eine Weiterleitung. Dies ist nützlich in API-Szenarien (einheitliche Fehlerformate) oder wenn du blockierte Versuche mit zusätzlichem Kontext protokollieren möchtest.
Backend-Modul Verwaltung über das TYPO3-Admin-Panel
Die praktischste Funktion für Redakteure und Administratoren ohne SSH-Zugriff. Das Backend-Modul ermöglicht: das Erstellen, Bearbeiten und Löschen von Sperrmustern, die Auswahl des Typs (IP, Pfad, Header, Regex), das Festlegen des Ablaufdatums (expiresAt – wichtig für temporäre Sperren), die Übersicht über aktive Fail2ban-Sperren und die Möglichkeit, diese manuell aufzuheben. Änderungen werden sofort wirksam, ohne Deployment.
Wie funktioniert das technisch gesehen?
Architektur Die Firewall als Grundlage
TYPO3 Firewall ist eine Integrationsschicht über dem Open-Source-Paket Phirewall (flowd/phirewall – vom selben Autor). Phirewall ist ein eigenständiges PHP-Paket, das in jeder auf PSR-7 basierenden Anwendung (Symfony, Laravel, Slim, eigene Frameworks) verwendet werden kann. TYPO3 Firewall ergänzt dies um: Integration in das TYPO3-Middleware-System, ein Backend-Modul, eine JSON-Vorlagensammlung sowie Dokumentation und Beispiele für die TYPO3-Umgebung.
Konfigurationsdateien
Die Konfiguration erfolgt in zwei Schritten:
• config/system/phirewall.php — Hauptkonfiguration von Phirewall (Regeln in PHP, Backend-Cache, fail2ban, Drosselungen, benutzerdefinierte Antworten)
• config/system/phirewall.patterns.json — vom Backend-Modul verwaltete Muster (statische IP-/Pfad-/Header-Sperren mit Ablaufdatum)
Cache-Backend Die Wahl ist entscheidend
Phirewall speichert den Status (Rate-Limit-Zähler, Fail2ban-Sperrlisten) im Cache. Die Wahl des Cache-Backends bestimmt, welche Funktionen verfügbar sind:
✗ InMemoryCache — nur für Testzwecke und die CLI. Es funktionieren ausschließlich Blocklisten. Rate Limiting und Fail2ban machen keinen Sinn, da der Cache zwischen den HTTP-Anfragen nicht erhalten bleibt.
✓ ApcuCache — für den Produktivbetrieb auf einem einzelnen Server. Schnell, im Arbeitsspeicher, aber nicht serverübergreifend gemeinsam genutzt. Erfordert die aktivierte APCu-Erweiterung in PHP.
✓ RedisCache — empfohlen für den Produktivbetrieb und Multi-Server-Umgebungen. Gemeinsamer Status zwischen den Servern, Persistenz, Möglichkeit zur manuellen Statusüberprüfung in der Redis-CLI.
In unserer Praxis verwenden wir für größere Kunden (Universitätsmedizin Mannheim, große Portale) Redis. Für kleinere TYPO3-Installationen auf einem einzelnen Server ist APCu ausreichend und erfordert keine zusätzliche Infrastruktur.
Praktische Konfigurationsbeispiele
Im Folgenden findest du drei konkrete Szenarien, die du sofort umsetzen kannst. Sie stammen alle aus der offiziellen Dokumentation und lassen sich auf die polnischen Gegebenheiten übertragen.
1. Blockieren von WordPress-Scannern und bekannten bösartigen IP-Adressen
Die Scanner suchen auf jeder Domain nach einer WordPress-Installation (Anfragen an /wp-admin, /wp-login.php). TYPO3 verfügt nicht über diese Pfade, sodass die Sperre keine Nebenwirkungen hat – und mehrere Dutzend Prozent des Bot-Traffics aus den Logs entfernt.
<?php
$config->blocklists->add(
name: 'evil-bot-ips',
callback: fn(\$request) => in_array(
\$request->getServerParams()['REMOTE_ADDR'] ?? '',
['176.65.149.61', '45.13.214.201'],
true
)
);
$config->blocklists->add(
name: 'wordpress-scanner-paths',
callback: fn(\$request) => str_starts_with(
strtolower(\$request->getUri()->getPath()),
'/wp-admin'
)
); 2. Fail2ban für die Suchmaschine Schutz vor Webscraping
Ein klassischer Angriff: Ein Bot versucht, alle Produkte/Seiten über die Suchfunktion abzurufen. Eine IP-Adresse sendet Hunderte von Anfragen an /search. Konfiguration: 5 Anfragen in 10 Sekunden → Sperre für 60 Sekunden.
<?php
$config->fail2ban->add(
name: 'search-page-scrapers',
threshold: 5,
period: 10,
ban: 60,
filter: fn(\$request) => str_starts_with(
\$request->getUri()->getPath(),
'/search'
),
key: KeyExtractors::ip()
); 3. Globale Ratenbegrenzung über Header Schutz vor Webscraping
Limit von 10 Anfragen pro 10 Sekunden pro IP-Adresse, mit aussagekräftigen Antwort-Headern. Das ist grundlegende Sicherheit auf jeder öffentlichen Website – sie schützt vor Bots mit verzögertem Exploit, aggressivem Scraping und „Fehlern“ von Programmierern, die sich im Skript vertan haben.
<?php
$config->throttles->add(
name: 'global-rate-limit',
limit: 10,
period: 10,
key: KeyExtractors::ip()
);
$config->enableRateLimitHeaders(); Warum ist dies im Zusammenhang mit NIS2 und PAD wichtig?
Die Novelle des Gesetzes über das KSC zur Umsetzung von NIS2 tritt am 3. April 2026 in Kraft und betrifft 27.000 öffentliche Einrichtungen in Polen – darunter jedes Krankenhaus, jede Gemeinde und zahlreiche Kultureinrichtungen. NIS2 verlangt unter anderem:
• die Umsetzung konkreter technischer Maßnahmen zum Schutz vor Cyberangriffen – eine Anwendungs-Firewall fällt unter diese Definition
• Verfahren zur Reaktion auf Vorfälle – fail2ban und Rate Limiting sind die automatisierte erste Verteidigungslinie
• Audit-Trail – Protokollierung, wer wann welche Änderungen an der Sicherheitskonfiguration vorgenommen hat. Das TYPO3-Backend-Firewall-Modul bietet hier einen natürlichen Vorteil gegenüber einer in Serverdateien versteckten Konfiguration
• Änderungsmanagement – Regeländerungen werden im Backend genehmigt und protokolliert, nicht ad hoc vom SSH-Administrator vorgenommen
Das polnische Gesetz über Barrierefreiheit (PAD, Gesetz vom 26. April 2024) und Art. 32 der DSGVO verlangen „technische Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung“. Eine Firewall auf Anwendungsebene ist eine konkrete, überprüfbare technische Maßnahme. Ein DSGVO- oder NIS2-Auditor kann die Konfiguration, die Protokolle und die Liste der gesperrten Adressen einsehen – dies ist der Nachweis für die Ergreifung der gesetzlich vorgeschriebenen Maßnahmen.
Wann lohnt es sich, die TYPO3-Firewall zu implementieren? und wenn nicht
Es lohnt sich, dies umzusetzen, wenn:
✓ Ihre TYPO3-Website unterliegt NIS2 (Krankenhaus, Gemeinde, Behörde, Hochschule) oder PAD (E-Commerce-Shop über dem Schwellenwert)
✓ Ihr Hosting-Anbieter bietet keine WAF auf Serverebene an (Shared Hosting, einige VPS)
✓ Sie nutzen kein Cloudflare oder ein anderes CDN mit WAF
✓ Sie haben viel Bot-Traffic in Ihren Logs – WordPress-Scanner, Brute-Force-Angriffe auf Formulare, Scraper
✓ Sie möchten Redakteuren die Möglichkeit geben, einfache Sperren ohne Unterstützung des Serveradministrators zu verwalten ✓ Sie benötigen einen Audit-Trail für das NIS2-Audit – das Backend-Modul bietet einen Änderungsverlauf
Das ist nicht erforderlich, wenn:
✗ Du hast bereits Cloudflare oder ein anderes CDN mit WAF richtig konfiguriert (die Anwendungsfirewall läuft dann auf einer anderen Ebene und kann zu Funktionsüberschneidungen führen)
✗ Das Hosting verfügt über korrekt konfiguriertes ModSecurity, systemseitiges Fail2ban und Ratenbegrenzung auf Nginx-/Apache-Ebene
✗ Deine Website hat nur minimalen Traffic und unterliegt keinen gesetzlichen Anforderungen – die Wartungskosten könnten den Nutzen übersteigen ✗ Kein persistenter Cache (Redis/APCu) auf dem Server – Rate Limiting und Fail2ban funktionieren nicht, nur statische Blocklisten
Die gängigste Vorgehensweise bei unseren Implementierungen: Die TYPO3-Firewall ergänzt die WAF auf CDN-Ebene, ersetzt sie jedoch nicht. Cloudflare fängt kostengünstigen, massiven Bot-Traffic ab, bevor er den Server erreicht. Die TYPO3-Firewall fängt das ab, was durch Cloudflare hindurchkommt – komplexe Angriffe, Angriffe auf bestimmte Endpunkte der Anwendung, Brute-Force-Angriffe auf Formulare, die Cloudflare nicht von legitimem Datenverkehr unterscheiden kann.
Häufig gestellte Fragen
Nein, aber es ergänzt es. Cloudflare arbeitet auf Netzwerkebene und fängt den Datenverkehr ab, bevor er den Server erreicht – das ist sehr effektiv bei DDoS-Angriffen und einfachen Bots. Die TYPO3-Firewall arbeitet auf Anwendungsebene und hat Zugriff auf den Kontext (Benutzersitzung, Abfrageparameter, Geschäftslogik). Im Idealfall hast du beides – Cloudflare als erste Verteidigungslinie, die TYPO3-Firewall als zweite.
Teilweise. Grundlegende Sperren (IP, Pfad) lassen sich über das TYPO3-Backend verwalten, ohne den Code anzufassen – das reicht für 70 % der Anwendungsfälle aus. Fortgeschrittenere Regeln (benutzerdefinierte Callbacks, Fail2Ban, Throttles) erfordern die Bearbeitung der Datei phirewall.php – das ist PHP, aber einfach und gut dokumentiert. Wir konfigurieren die Regeln einmalig für unsere Kunden, danach verwaltet der Redakteur die Muster über das Backend.
Phirewall ist als leichtgewichtige Middleware konzipiert. Die Überprüfung statischer Blocklisten (IP-Prüfung) dauert nur Mikrosekunden. Die Ratenbegrenzung mit Redis fügt pro Anfrage 1–3 ms hinzu. Fail2ban wird nur ausgeführt, wenn eine Regel aktiv ist – es belastet den normalen Datenverkehr nicht. In unseren Tests war der Unterschied in der Antwortzeit für den Endnutzer nicht messbar.
Ja, unmittelbar nach dem Speichern. Die Muster werden bei jeder Anfrage aus der Datei `phirewall.patterns.json` geladen (mit Caching). Es ist kein Deployment, kein Neustart von PHP-FPM und keine andere administrative Maßnahme erforderlich. Das ist ein entscheidender Vorteil bei Sicherheitsvorfällen – du siehst den Angriff in den Logs, fügst die IP zur Sperrliste hinzu, und der Angriff wird innerhalb von 30 Sekunden gestoppt.
Phirewall unterstützt den „Dry-Run“-Modus (empfohlen vor der Implementierung von Ratenbegrenzungen und Fail2ban). Die Regel wird ausgewertet, ein Blockierevent wird ausgelöst (du kannst es mit einem Event-Listener abfangen und protokollieren), aber die eigentliche Anfrage wird nicht blockiert. Standardvorgehensweise: eine Woche Dry Run, Analyse der Fehlalarme, Produktivschaltung.
Das Extension erfordert PHP 8.2+. Dies ist der Standard für TYPO3 13, doch viele Installationen im öffentlichen Sektor laufen noch unter PHP 7.4 oder 8.0 (mit TYPO3 v10 oder v11). Dies ist ein weiteres Argument für ein Update – moderne Sicherheitstools erfordern eine moderne Infrastruktur. NIS2 erfordert ohnehin ein aktuelles PHP (Schwachstellenmanagement).
Ja – und das ist eine der Stärken dieser Lösung. Alle Regeln befinden sich in versionierten Dateien (phirewall.php). Die Muster aus dem Backend sind in phirewall.patterns.json gespeichert (ebenfalls in Git). Fail2ban-Sperren werden protokolliert und sind im Backend-Modul einsehbar. Ein NIS2- oder DSGVO-Auditor erhält einen konkreten Satz an Dokumenten: Regeln, Protokolle, Änderungshistorie. Dies unterscheidet sich von der versteckten ModSecurity-Konfiguration auf dem Server, die der Auditor ohne Unterstützung des Administrators nicht einsehen kann.
Projektstatus und Ökosystem
TYPO3 Firewall wird aktiv von Sascha Egerer (flowd GmbH) weiterentwickelt – einem bekannten deutschen TYPO3-Entwickler, Autor zahlreicher Erweiterungen und Core-Mitwirkenden. Die Version 0.3 (letzte Aktualisierung: 19. Mai 2026) ist stabil, doch die Versionsnummer zeigt, dass sich das Projekt noch weiterentwickelt. Der Quellcode ist auf GitHub, die Dokumentation auf docs.typo3.org und der Support-Kanal auf TYPO3 Slack zu finden.
Phirewall – die Ausführungsengine – ist ein eigenständiges, ausgereiftes PHP-Projekt. Vollständige Dokumentation: phirewall.de. Dies stärkt das Vertrauen in die Lösung – selbst wenn die Entwicklung der TYPO3-Firewall eingestellt würde, bleibt die Grundlage aktiv.
Wie können wir helfen?
Wir sind auf TYPO3 spezialisiert, wobei der Schwerpunkt auf Sicherheit und Compliance liegt. Im Zusammenhang mit der TYPO3-Firewall bieten wir Folgendes an:
✓ Analyse Ihrer aktuellen digitalen Präsenz und Ihrer Anforderungen gemäß NIS2/PAD/DSGVO – ist TYPO3 Firewall für Ihre Implementierung sinnvoll? ✓ Implementierung der Erweiterung mit einer auf Ihre Infrastruktur abgestimmten Konfiguration (Redis, APCu, Dry Run, Regelkalibrierung)
✓ Konfiguration von Regeln für typische Szenarien – Blocklisten, Fail2ban, Throttles – inklusive Dokumentation für den Auditor
✓ Schulung des Redaktionsteams im Umgang mit dem Backend-Modul (Verwaltung von Vorlagen, Überprüfung aktiver Sperren)
✓ Integration mit unseren übrigen Sicherheitsempfehlungen: Verschlüsselung von Powermail-Formularen, Datenschutzerklärung, Hosting im EWR
Wenn Sie ein Krankenhaus, eine Gemeinde oder ein Geschäft betreiben, das den neuen Vorschriften unterliegt – wir stehen Ihnen gerne für ein Gespräch zur Verfügung.
Telefon: 12 333 44 01. E-Mail: [email protected].
