TYPO3 Firewall nowa warstwa bezpieczeństwa dla Twojej instalacji
Rozszerzenie flowd/typo3-firewall integruje pakiet Phirewall i dodaje do TYPO3 CMS prawdziwy WAF na poziomie aplikacji — blokady IP, rate limiting, fail2ban i zarządzanie wzorcami z Backend
W skrócie
Co to jest:
TYPO3 Firewall (flowd/typo3-firewall) to nowe rozszerzenie autorstwa Saschy Egerera, które integruje open-source’owy pakiet Phirewall z TYPO3. Daje funkcje Web Application Firewall na poziomie aplikacji PHP — bez serwera dedykowanego, bez Cloudflare’a, bez WAF-a hostingu.
Główne funkcje:
Blokowanie po IP, CIDR, ścieżce URL, nagłówkach i regex. Fail2ban (tymczasowa blokada po nadużyciu). Rate limiting z nagłówkami. Zarządzanie wzorcami z TYPO3 Backend bez deploymentu. Custom odpowiedzi dla zablokowanych żądań.
Dla kogo:
Strony podlegające NIS2 (szpitale, gminy, urzędy), sklepy podlegające PAD/EAA, witryny NGO przetwarzające dane wrażliwe, każda strona TYPO3 bez dostępu do WAF-a na poziomie serwera.
Wymagania:
TYPO3 13+, PHP 8.2+. Dla rate limitingu i fail2ban: persystentny cache (APCu lub Redis — w produkcji rekomendowany Redis).
Wersja:
0.3 (ostatnia aktualizacja: 19 maja 2026). Status: aktywnie rozwijane, kod źródłowy dostępny na GitHub.
Bezpieczeństwo stron internetowych w TYPO3 było tradycyjnie obsługiwane na poziomie serwera lub CDN — Cloudflare, ModSecurity, fail2ban systemowy, reguły nginx. To rozwiązania skuteczne, ale wymagają dostępu do infrastruktury, którego często nie mamy: na shared hostingu, w hostingach zarządzanych, w środowiskach gdzie operacje IT należą do innego zespołu niż zespół redakcyjny.
Nowe rozszerzenie flowd/typo3-firewall zmienia to podejście. Daje administratorowi TYPO3 narzędzia Web Application Firewall na poziomie aplikacji PHP — działające w tym samym środowisku co sam CMS. Bez współpracy z administratorem serwera, bez dodatkowych usług, bez opłat miesięcznych. To jest istotna zmiana, szczególnie w kontekście nowelizacji ustawy o KSC (NIS2) i Polskiego Aktu o Dostępności, które obowiązują od 2025–2026 roku i wymagają wdrożenia konkretnych środków bezpieczeństwa.
Co potrafi TYPO3 Firewall
Rozszerzenie ma dwie główne warstwy: integrację z pakietem Phirewall (silnik wykonawczy) oraz moduł Backend (zarządzanie regułami). Razem dają następujące funkcje.
Blocklists statyczne listy blokowania
Możesz blokować żądania na podstawie kilku kryteriów: adres IP (pojedynczy lub zakres CIDR), ścieżka URL (np. /wp-admin — typowy cel skanerów szukających WordPressa), parametry query string (np. xdebug, option=com_), nagłówki HTTP, dowolne wyrażenia regularne. Reguły działają natychmiast po dodaniu, bez restartowania serwera.
Fail2ban tymczasowa blokada po nadużyciu
Działa tak samo jak klasyczny fail2ban systemowy, ale na poziomie aplikacji. Definiujesz próg (threshold), okno czasowe i długość bana. Przykład: jeśli adres IP wykona ponad 5 żądań do /search w ciągu 10 sekund — jest blokowany na 60 sekund. To eliminuje boty skanujące wyszukiwarkę i brute-force’y na formularze logowania.
Rate limiting (throttles) (throttles)
Globalne ograniczenie liczby żądań z jednego klucza (IP, user, sesja) w danym oknie czasowym. Przykład: 10 żądań co 10 sekund per IP. Można włączyć nagłówki rate limit (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After) — wtedy klient widzi, kiedy może ponowić żądanie. To ważne dla integracji API.
Allow2ban banowanie po śladach pozytywnych
Mniej znana, ale przydatna funkcja — banowanie kluczy, które trafiają w określone „pułapki”. Przykład: każdy bot, który próbuje wejść na /robots-trap-url (link ukryty dla użytkowników, widoczny tylko w źródle HTML), zostaje natychmiast zbanowany. Honeypot na poziomie aplikacji.
Custom responses własne odpowiedzi dla zablokowanych
Standardowo zablokowane żądanie otrzymuje status 403 z minimalnym body. Możesz zdefiniować własną odpowiedź — inny status, JSON, HTML, przekierowanie. Przydatne w scenariuszach API (jednolite formaty błędów) lub gdy chcesz logować zablokowane próby z dodatkowym kontekstem.
Backend module zarządzanie z panelu TYPO3
Najbardziej praktyczna cecha dla redaktorów i administratorów bez dostępu SSH. Moduł w Backend pozwala na: tworzenie, edytowanie i usuwanie wzorców blokowania, wybór typu (IP, ścieżka, nagłówek, regex), ustawienie daty wygaśnięcia (expiresAt — ważne dla tymczasowych blokad), przegląd aktywnych banów fail2ban i możliwość ich ręcznego zdjęcia. Zmiany są aktywne natychmiast, bez deploymentu.
Jak to działa od strony technicznej
Architektura Phirewall jako fundament
TYPO3 Firewall to warstwa integracyjna nad open-source’owym pakietem Phirewall (flowd/phirewall — ten sam autor). Phirewall jest niezależnym pakietem PHP, który można użyć w dowolnej aplikacji opartej na PSR-7 (Symfony, Laravel, Slim, własne frameworki). TYPO3 Firewall dodaje do tego: integrację z systemem middleware TYPO3, moduł Backend, magazyn wzorców w JSON, dokumentację i przykłady dla środowiska TYPO3.
Pliki konfiguracyjne
Konfiguracja jest dwustopniowa:
• config/system/phirewall.php — główna konfiguracja Phirewall (reguły w PHP, cache backend, fail2ban, throttles, custom responses)
• config/system/phirewall.patterns.json — wzorce zarządzane przez Backend module (statyczne blokady IP/path/header z datą wygaśnięcia)
Cache backend wybór ma znaczenie
Phirewall przechowuje stan (liczniki rate limitu, listy banów fail2ban) w cache’u. Wybór backendu cache decyduje, które funkcje są dostępne:
✗ InMemoryCache — tylko do testowania i CLI. Działają wyłącznie blocklisty. Rate limiting i fail2ban nie mają sensu, bo cache nie persystuje między żądaniami HTTP.
✓ ApcuCache — produkcyjny dla pojedynczego serwera. Szybki, in-memory, ale nie współdzielony między serwerami. Wymaga włączonego rozszerzenia APCu w PHP.
✓ RedisCache — rekomendowany dla produkcji i środowisk multi-server. Współdzielony stan między serwerami, persystencja, możliwość ręcznego sprawdzenia stanu w Redis CLI.
W naszej praktyce dla większych klientów (Universitätsmedizin Mannheim, dużze portale) używamy Redis. Dla mniejszych instalacji TYPO3 na jednym serwerze APCu jest wystarczające i nie wymaga dodatkowej infrastruktury.
Praktyczne przykłady konfiguracji
Poniżej trzy realne scenariusze, które możesz wdrożyć od ręki. Wszystkie pochodzą z oficjalnej dokumentacji i nadają się do użycia w polskich realiach.
1. Blokowanie skanerów WordPressa i znanych złośliwych IP
Skanery szukają instalacji WordPressa na każdej domenie (żądania do /wp-admin, /wp-login.php). TYPO3 nie ma tych ścieżek, więc blokada nie ma skutków ubocznych — a usuwa kilkadziesiąt procent botowego ruchu z logów.
<?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 dla wyszukiwarki ochrona przed scrapingiem
Klasyczny atak: bot próbuje wyciągnąć wszystkie produkty/strony przez wyszukiwarkę. Jedno IP wykonuje setki żądań do /search. Konfiguracja: 5 żądań w 10 sekund → ban na 60 sekund.
<?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. Globalny rate limiting z nagłówkami ochrona przed scrapingiem
Limit 10 żądań na 10 sekund per IP, z czytelnymi nagłówkami zwrotnymi. To podstawowa higiena na każdej publicznej stronie — chroni przed boty mającymi opóźniony exploit, agresywnym scrapingiem i „zabłądzeniami” programisty który pomylił się w skrypcie.
<?php
$config->throttles->add(
name: 'global-rate-limit',
limit: 10,
period: 10,
key: KeyExtractors::ip()
);
$config->enableRateLimitHeaders(); Dlaczego to ważne w kontekście NIS2 i PAD
Nowelizacja ustawy o KSC wdrażająca NIS2 obowiązuje od 3 kwietnia 2026 i obejmuje 27 tys. polskich podmiotów publicznych — w tym każdy szpital, gminę i wiele instytucji kultury. NIS2 wymaga, między innymi:
• Wdrożenia konkretnych środków technicznych ochrony przed cyberatakami — firewall aplikacyjny mieści się w tej definicji
• Procedur reagowania na incydenty — fail2ban i rate limiting to automatyzacja pierwszej linii obrony
• Audit trail — logowanie kto, kiedy i co zmienił w konfiguracji bezpieczeństwa. Moduł Backend TYPO3 Firewall daje tu naturalną zaletę wobec konfiguracji ukrytej w plikach na serwerze
• Change management — zmiany reguł zatwierdzane i logowane w Backend, nie wprowadzane ad hoc przez admina SSH
Polski Akt o Dostępności (PAD, ustawa z 26 kwietnia 2024 r.) i RODO art. 32 wymagają „środków technicznych zapewniających bezpieczeństwo przetwarzania”. Firewall na poziomie aplikacji to konkretny, weryfikowalny środek techniczny. Audytor RODO lub NIS2 może zobaczyć konfigurację, logi i listę zablokowanych adresów — to jest dowód na podjęcie działań, którego wymaga prawo.
Kiedy warto wdrożyć TYPO3 Firewall a kiedy nie
Warto wdrożyć, jeśli:
✓ Twoja strona TYPO3 podlega NIS2 (szpital, gmina, urząd, uczelnia) lub PAD (sklep e-commerce powyżej progu)
✓ Hosting nie oferuje WAF-a na poziomie serwera (shared hosting, niektóre VPS)
✓ Nie używasz Cloudflare lub innego CDN-a z WAF-em
✓ Masz duży ruch botowy w logach — skanery WordPressa, brute-force na formularze, scrapery
✓ Chcesz dać redaktorom możliwość zarządzania prostymi blokadami bez wsparcia administratora serwera
✓ Potrzebujesz audit trail dla audytu NIS2 — moduł Backend daje historię zmian
Nie jest konieczne, jeśli:
✗ Masz już dobrze skonfigurowany Cloudflare lub inny CDN z WAF-em (firewall aplikacyjny działa wtedy na innej warstwie i może duplikować funkcje)
✗ Hosting ma właściwie skonfigurowany ModSecurity, fail2ban systemowy i rate limiting na poziomie nginx/Apache
✗ Twoja strona ma minimalny ruch i nie podlega żadnym wymogom prawnym — koszt utrzymania może przewyższać korzyści
✗ Brak persystentnego cache (Redis/APCu) na serwerze — rate limiting i fail2ban nie będą działać, tylko statyczne blocklisty
Najczęstsza praktyka w naszych wdrożeniach: TYPO3 Firewall jest komplementarny wobec WAF-a na poziomie CDN, nie zastępujący. Cloudflare łapie tani, masowy ruch botowy zanim trafi do serwera. TYPO3 Firewall łapie to, co przechodzi przez Cloudflare — zaawansowane ataki, ataki na konkretne endpointy aplikacji, brute-force na formularze, które Cloudflare nie odróżni od ruchu legitymnego.
Najczęściej zadawane pytania
Nie, ale uzupełnia. Cloudflare działa na poziomie sieci i łapie ruch zanim dotrze do serwera — to bardzo skuteczne dla ataków DDoS i prostych botów. TYPO3 Firewall działa w aplikacji i ma dostęp do kontekstu (sesja użytkownika, parametry zapytania, logika biznesowa). W idealnym scenariuszu masz oba — Cloudflare jako pierwsza linia, TYPO3 Firewall jako druga.
Częściowo. Podstawowe blokady (IP, ścieżkę) można zarządzać z TYPO3 Backend bez dotykania kodu — to wystarczy dla 70% scenariuszy. Bardziej zaawansowane reguły (custom callbacks, fail2ban, throttles) wymagają edycji pliku phirewall.php — to PHP, ale prosty i dobrze udokumentowany. Naszym klientom konfigurujemy reguły raz, potem redaktor zarządza wzorcami z Backend.
Phirewall jest zaprojektowany jako lekki middleware. Statyczne blocklisty (sprawdzenie IP) to mikrosekundy. Rate limiting z Redis dodaje 1–3 ms per żądanie. Fail2ban działa tylko gdy reguła jest aktywna — nie obciąża normalnego ruchu. W naszych testach różnica w czasie odpowiedzi była niemierzalna w skali użytkownika końcowego.
Tak, natychmiast po zapisaniu. Wzorce są odczytywane z pliku phirewall.patterns.json przy każdym żądaniu (z cache’owaniem). Nie ma deploymentu, restartu PHP-FPM ani innego działania administracyjnego. To kluczowa zaleta dla incydentów — widzisz atak w logach, dodajesz IP do blokady, atak zatrzymuje się w 30 sekund.
Phirewall obsługuje tryb „dry run” (zalecane przed wdrożeniem rate limitów i fail2ban). Reguła jest ewaluowana, zdarzenie blokady jest emitowane (możesz je złapać event listenerem i zalogować), ale faktyczne żądanie nie jest blokowane. Standardowa praktyka: tydzień dry run, analiza fałszywych alarmów, włączenie produkcyjne.
Rozszerzenie wymaga PHP 8.2+. Jest to standard dla TYPO3 13, ale wciąż wiele instalacji w sektorze publicznym działa na PHP 7.4 lub 8.0 (z TYPO3 v10 lub v11). To dodatkowy argument za aktualizacją — nowoczesne narzędzia bezpieczeństwa wymagają nowoczesnej infrastruktury. NIS2 i tak wymaga aktualnego PHP (zarządzanie podatnościami).
Tak — i to jest jedna z mocnych stron tego rozwiązania. Wszystkie reguły są w plikach pod kontrolą wersji (phirewall.php). Wzorce z Backend są zapisane w phirewall.patterns.json (też w git). Bany fail2ban są logowane i widoczne w Backend module. Audytor NIS2 lub RODO dostaje konkretny zestaw dokumentów: reguły, logi, historię zmian. To różni się od ukrytej konfiguracji ModSecurity na serwerze, której audytor nie zobaczy bez wsparcia administratora.
Status projektu i ekosystem
TYPO3 Firewall jest aktywnie rozwijany przez Saschę Egerera (flowd GmbH) — znanego niemieckiego dewelopera TYPO3, autora wielu rozszerzeń i kontrybutora Core. Wersja 0.3 (ostatnia aktualizacja: 19 maja 2026) jest stabilna, ale numer wersji wskazuje, że projekt jeszcze ewoluuje. Kod źródłowy jest na GitHubie, dokumentacja na docs.typo3.org, kanał wsparcia na TYPO3 Slack.
Phirewall — silnik wykonawczy — jest niezależnym, dojrzalym projektem PHP. Pełna dokumentacja: phirewall.de. To zwiększa zaufanie do rozwiązania — nawet gdyby TYPO3 Firewall przestał być rozwijany, fundament pozostaje aktywny.
Jak możemy pomóc
Specjalizujemy się w TYPO3 z naciskiem na bezpieczeństwo i compliance. W kontekście TYPO3 Firewall oferujemy:
✓ Analiza obecnej powierzchni cyfrowej i potrzeb pod NIS2/PAD/RODO — czy TYPO3 Firewall ma sens w Twoim wdrożeniu
✓ Wdrożenie rozszerzenia z konfiguracją dostosowaną do Twojej infrastruktury (Redis, APCu, dry run, kalibracja reguł)
✓ Konfiguracja reguł dla typowych scenariuszy — blocklisty, fail2ban, throttles — wraz z dokumentacją dla audytora
✓ Szkolenie zespołu redakcyjnego z obsługi modułu Backend (zarządzanie wzorcami, sprawdzanie aktywnych banów)
✓ Integracja z naszymi pozostałymi rekomendacjami bezpieczeństwa: szyfrowanie formularzy Powermail, deklaracja dostępności, hosting w EOG
Jeśli prowadzisz szpital, gminę lub sklep podlegający nowym przepisom — chętnie porozmawiamy.
Telefon: 12 333 44 01. Email: [email protected].