Kurz notiert: Einfacheres Debugging von CDN-Setups mit TYPO3

Kennt ihr das? Eine Website läuft hinter einem CDN oder Reverse Proxy, und irgendwann fällt der Satz: „Bei mir kommt aber die falsche IP an.“ Dann beginnt die Suche: Header im Access-Log prüfen, per curl nachstellen, die Proxy-Konfiguration von TYPO3 durchblättern und sich dabei fragen, welche Adresse TYPO3 am Ende eigentlich als Client-IP betrachtet.

Genau dafür habe ich eine kleine Extension gebaut: mfd/cdn-utils. Sie zeigt direkt im TYPO3-Backend an, welche Client-IP TYPO3 ermittelt hat und welche Proxies laut X-Forwarded-For-Header an der Anfrage beteiligt waren.

Entstanden ist die Extension aus einem konkreten Projektbedarf: Wir haben begonnen, Phirewall und die zugehörige TYPO3-Extension flowd/typo3-firewall in unsere Projekte zu integrieren. Phirewall ist eine in PHP geschriebene Application-Firewall, die als PSR-15-Middleware arbeitet. Sie bietet Safelists und Blocklists, Rate Limiting sowie Fail2Ban-artige temporäre Sperren.

Die TYPO3-Extension bindet das in TYPO3 ein: Die Regeln werden in einer PHP-Datei unter config/system/phirewall.php gepflegt. Zusätzlich gibt es ein Backend-Modul, über das sich einfache Block-Muster (IP, CIDR, Pfad, Header, Regex) verwalten lassen, sowie Unterstützung für das OWASP ModSecurity Core Rule Set. Unerwünschte Anfragen werden so abgewiesen, bevor TYPO3 mit der aufwendigen Verarbeitung beginnt.

So nützlich das ist, es gibt eine Voraussetzung, an der alles hängt: Viele Regeln arbeiten mit der Client-IP, etwa „maximal zehn Anfragen in zehn Sekunden pro IP“ oder „IP nach wiederholtem Fehlverhalten temporär sperren“. Die Extension übernimmt die Client-IP standardmäßig von TYPO3, und zwar über den Mechanismus des Cores, der die Reverse-Proxy-Konfiguration berücksichtigt. Ob die Firewall sinnvoll arbeitet, hängt damit direkt daran, dass TYPO3 die richtigen Adressen kennt.

Hinter einem CDN gibt es dabei zwei typische Fehlerbilder:

• TYPO3 sieht für alle Besucher die IP des CDN. Dann teilen sich sämtliche Besucher einen einzigen Zähler. Das Rate Limit ist schnell erreicht, und im schlimmsten Fall sperrt eine Fail2Ban-Regel den Proxy und damit alle Besucher auf einmal.
• TYPO3 vertraut einem Header, dem es nicht vertrauen sollte. Dann kann jeder Client über einen gefälschten X-Forwarded-For-Header beliebige Absenderadressen vorgeben. Rate Limits lassen sich so umgehen, und im Extremfall landen fremde Adressen auf der Sperrliste.

Bevor wir also Firewall-Regeln schreiben, wollen wir sicher sein, dass TYPO3 mit korrekten Client-IPs arbeitet. Genau diese Prüfung soll cdn-utils einfacher machen.

Sobald ein CDN oder Reverse Proxy vor TYPO3 sitzt, sieht der Webserver als Absender zunächst nur den Proxy. Die Adresse des eigentlichen Besuchers steht, wenn alles richtig konfiguriert ist, im Header X-Forwarded-For. Jeder weitere Proxy auf dem Weg hängt seine eigene Adresse an, es entsteht eine ganze Kette.

TYPO3 kann diese Information auswerten. Über die Einstellungen reverseProxyIP und reverseProxyHeaderMultiValue in $GLOBALS['TYPO3_CONF_VARS']['SYS'] legt man fest, welchen Proxies vertraut wird und welcher Eintrag der Kette als Client-IP gilt. Ob dabei am Ende das Richtige herauskommt, lässt sich aber nicht auf einen Blick erkennen. Und weil X-Forwarded-For von jedem Client frei mitgeschickt werden kann, ist blindes Vertrauen in den Header ebenfalls keine Lösung. 😉

Auch der Blick in die Access-Logs führt nicht immer weiter. Sie sind nur dann aussagekräftig, wenn der Webserver die Proxy-Header korrekt auswertet, denn welche Client-IP dort steht, hängt allein von seiner Konfiguration ab. Ob das der Fall ist, kann TYPO3 nicht überprüfen: Die Anwendung sieht nur, was der Webserver ihr übergibt, und weiß nichts darüber, was er selbst ins Log schreibt. Ein Log-Eintrag mit der IP des Proxys statt der des Besuchers kann also genauso gut ein Konfigurationsproblem im Webserver sein wie eines in TYPO3.

Die Extension unterstützt TYPO3 13.4 LTS und TYPO3 14, benötigt außer dem TYPO3-Core keine weiteren Pakete und steht unter der GPL. Das Paket ist auf Packagist verfügbar, der Quellcode liegt im GitHub-Repository der Marketing Factory. Die Installation per Composer sieht so aus:

composer require mfd/cdn-utils

Nach der Installation erscheinen die beiden neuen Einträge ohne weitere Konfiguration in der Systeminformation der Backend-Toolbar.

Kein großer Wurf, aber genau die Art von Werkzeug, die im Alltag Zeit spart: Wer TYPO3 hinter einem CDN betreibt, sieht jetzt ohne Umwege, was auf dem Weg vom Besucher bis zur Anwendung mit der IP-Adresse passiert. Wie wir CDNs in unseren Projekten einsetzen, erfahrt ihr auf unserer Seite zu Content Delivery Networks, weitere Erweiterungen findet ihr unter Unsere TYPO3 Extensions.

Feedback, Issues und Pull Requests sind im Repository jederzeit willkommen.