Firewall Extension

The TYPO3 Firewall extension provides two main possibilities:

1. Use all features of the Phirewall package

This extension integrates the powerful open-source package phirewall and makes its features available in the TYPO3 context. This includes:

Protection against brute-force and other attacks
Flexible pattern and rule definitions (IP, path, header, user agent, etc.)
Support for blacklists, whitelists, rate limiting, and more
Central configuration via PHP array files

Configuration of Phirewall Phirewall itself is configured in the core configuration file:

config/system/phirewall.php

All details and advanced features can be found in the official Phirewall documentation: https://github.com/flowd/phirewall

2. Manage static block patterns in the TYPO3 backend

Via the TYPO3 backend, editors and administrators can create, edit, and delete custom block patterns. These patterns become active immediately and extend the Phirewall configuration.

Easy management of IPs, paths, headers, etc. via the backend module
Overview and management of all active patterns
Support for expiration date (expiresAt) and various pattern types
Immediate enforcement of rules without deployment
Patterns are stored in the file config/system/phirewall.patterns.json.

Backend

The TYPO3 backend provides a dedicated module for managing block patterns easily.

Create, edit, and delete patterns
Select the pattern type (e.g. IP, path, header)
Specify value, target (e.g. header name), and expiration date
Overview of all active patterns
Immediate activation after saving

Patterns are stored in the file config/system/phirewall.patterns.json and are used directly by the firewall.

Examples

Key features of the Firewall extension:

Integration of the Phirewall package (see Phirewall)
Management of static block patterns in the backend
Support for various pattern types (IP, CIDR, path, header, user agent, regex)
Expiration date for patterns (expiresAt)

Configuration overview

Core Phirewall configuration: config/system/phirewall.php
Static custom patterns managed by the firewall backend module: config/system/phirewall.patterns.json

Usage Examples

Below are practical examples of configuring the firewall in a TYPO3 context.

Blocking common scanner requests and known bot IPs

This example blocks requests from known bad IP addresses and certain paths or query strings. It uses InMemoryCache, which is fine for simple blocklists (no rate limiting).

<?php
use Flowd\Phirewall\Config;
use Flowd\Phirewall\Store\InMemoryCache;
use Psr\EventDispatcher\EventDispatcherInterface;

return fn (EventDispatcherInterface $eventDispatcher) =>
    (new Config(new InMemoryCache(), $eventDispatcher))
        ->blocklist(
            name: 'evil-bot-ips',
            callback: fn(ServerRequestInterface $request) => in_array($request->getServerParams()['REMOTE_ADDR'] ?? '', [
                '176.65.149.61',
                '45.13.214.201',
            ], true)
        )
        ->blocklist(
            name: 'blocked-uri-paths',
            callback: fn(ServerRequestInterface $request) => str_starts_with(strtolower($request->getUri()->getPath()), '/wp_admin')
        )
        ->blocklist(
            name: 'blocked-uri-query-strings',
            callback: fn(ServerRequestInterface $request) => str_contains(strtolower($request->getUri()->getQuery()), 'xdebug')
                || str_contains(strtolower($request->getUri()->getQuery()), 'option=com_')
        );

Temporary blocking after repeated abuse (Fail2Ban)

This example blocks users for 1 minute if they access /search more than 5 times in 10 seconds. Requires a persistent cache backend like APCu or Redis.

<?php
use Flowd\Phirewall\Config;
use Flowd\Phirewall\KeyExtractors;
use Flowd\Phirewall\Store\ApcuCache;
use Psr\EventDispatcher\EventDispatcherInterface;

return fn (EventDispatcherInterface $eventDispatcher) =>
    (new Config(new ApcuCache(), $eventDispatcher))
        ->fail2ban(
            name: 'search-page-scrapers',
            threshold: 5,
            period: 10,
            ban: 60,
            filter: fn($request) => str_starts_with($request->getUri()->getPath(), '/search'),
            key: KeyExtractors::ip()
        );

Rate limiting with clear client feedback

This example limits users to 10 requests every 10 seconds (per IP) and sends rate limit headers. Requires a persistent cache backend like APCu or Redis.

<?php
use Flowd\Phirewall\Config;
use Flowd\Phirewall\KeyExtractors;
use Flowd\Phirewall\Store\ApcuCache;
use Psr\EventDispatcher\EventDispatcherInterface;

return fn (EventDispatcherInterface $eventDispatcher) =>
    (new Config(new ApcuCache(), $eventDispatcher))
        ->throttle(
            name: 'slow-down-to-10-requests-in-10-seconds',
            limit: 10,
            period: 10,
            key: KeyExtractors::ip()
        )
        ->enableRateLimitHeaders();

Using APCu as a cache backend

This example shows how to use APCu as a cache backend. Use this for single-server setups.

<?php
use Flowd\Phirewall\Config;
use Flowd\Phirewall\Store\ApcuCache;
use Psr\EventDispatcher\EventDispatcherInterface;

return fn (EventDispatcherInterface $eventDispatcher) =>
    (new Config(new ApcuCache(), $eventDispatcher))
        ->blocklist(
            name: 'blocked-uri-paths',
            callback: fn($request) => str_starts_with(strtolower($request->getUri()->getPath()), '/wp_admin')
        );

Using Redis as a cache backend

This example uses Redis for the cache backend, which is recommended for production and multi-server setups.

<?php
use Flowd\Phirewall\Config;
use Flowd\Phirewall\Store\RedisCache;
use Predis\Client;
use Psr\EventDispatcher\EventDispatcherInterface;

return fn (EventDispatcherInterface $eventDispatcher) =>
    (new Config(new RedisCache(new Client('redis://localhost:6379')), $eventDispatcher))
        ->blocklist(
            name: 'blocked-uri-paths',
            callback: fn($request) => str_starts_with(strtolower($request->getUri()->getPath()), '/wp_admin')
        );

Using InMemoryCache as a cache backend (not recommended for production)

This example uses InMemoryCache, which is only suitable for testing or CLI environments. Only block rules work; rate limiting and Fail2Ban do not persist between requests.

<?php
use Flowd\Phirewall\Config;
use Flowd\Phirewall\Store\InMemoryCache;
use Psr\EventDispatcher\EventDispatcherInterface;

return fn (EventDispatcherInterface $eventDispatcher) =>
    (new Config(new InMemoryCache(), $eventDispatcher))
        ->blocklist(
            name: 'blocked-uri-paths',
            callback: fn($request) => str_starts_with(strtolower($request->getUri()->getPath()), '/wp_admin')
        );

Note

When using InMemoryCache, only block rules work. Throttling and Fail2Ban do not work as request counts cannot be stored between requests. This backend is only suitable for testing or CLI environments, not for production use.

Using a custom response for blocked requests

This example shows how to return a custom message and status code when a request is blocked.

<?php
use Flowd\Phirewall\Config;
use Flowd\Phirewall\Store\ApcuCache;
use Psr\EventDispatcher\EventDispatcherInterface;
use TYPO3\CMS\Core\Http\ResponseFactory;
use TYPO3\CMS\Core\Http\StreamFactory;

return fn (EventDispatcherInterface $eventDispatcher) =>
    (new Config(new ApcuCache(), $eventDispatcher))
        ->blocklist(
            name: 'blocked-uri-paths',
            callback: fn($request) => str_starts_with(strtolower($request->getUri()->getPath()), '/wp_admin')
        )
        ->blocklistedResponse(function ($rule, $type, $request) {
            return (new ResponseFactory())
                ->createResponse()
                ->withBody((new StreamFactory())->createStream('Access denied by firewall rule: ' . $rule . ' (type: ' . $type . ')'))
                ->withHeader('Content-Type', 'text/plain')
                ->withStatus(403);
        });

Phirewall

This extension uses the open-source package flowd/phirewall as its technical foundation. The full documentation and all features can be found at:

https://github.com/flowd/phirewall

Core configuration

Phirewall itself is configured via a PHP configuration file:

config/system/phirewall.php

This file controls the global behaviour of Phirewall (rules, backends, etc.).

Key notes

Configuration is done via PHP array files.
The pattern logic is identical to the standalone Phirewall package.
Advanced features such as rate limiting, dynamic rules, etc. are also available.