Backend module

The extension adds a backend module under System > Firewall. It is available to administrators only.

The module has three views. Switch between them with the View dropdown in the module's doc-header:

Patterns manages the static block patterns.
Blocked keys lists the clients that rules have banned automatically.
Statistics shows how much traffic the firewall blocked over time.

Patterns

This view manages the static block patterns. The extension always adds them to the firewall as the blocklist rule typo3-blocklist, so they take effect even when no configuration file exists (see Configuration). Patterns are stored in the file config/system/phirewall.patterns.json (classic installation: typo3conf/system/phirewall.patterns.json).

Every change takes effect on the next request. No deployment and no cache flush are needed.

The pattern list

The Active Patterns list shows one row per pattern with its kind, value, target, expiry date, creation date, and last change. A pattern that has passed its expiry date is highlighted and no longer blocks requests, until you remove it or run a prune (see below).

Add and edit patterns

The form next to the list creates a new pattern. Pick a kind, enter the value, and save. To change a pattern, open it from the list, edit the fields, and save. The form checks the value before it stores the pattern and shows a clear message when something is wrong, for example an invalid IP address or a broken regular expression.

Pattern kinds

A pattern's kind decides what part of the request it compares against.

ip: Blocks one exact client IP address, for example 203.0.113.10.
cidr: Blocks a whole IP range in CIDR notation, for example 203.0.113.0/24.
path_exact: Blocks requests whose path is exactly this value, for example /old-login.
path_prefix: Blocks requests whose path starts with this value, for example /wp-admin.
path_regex: Blocks requests whose path matches this regular expression, for example #^/(wp-admin|xmlrpc\.php)#.
header_exact: Blocks requests where a header has exactly this value. Put the header name in the target field, for example target User-Agent and value BadBot/1.0.
header_regex: Blocks requests where a header matches this regular expression. Put the header name in the target field, for example target User-Agent and value #(sqlmap|nikto)#i.
request_regex: Blocks requests where the regular expression matches a combined string of the path, the query string, and the request headers, for example #(union\s+select|<script)#i.

The target field is only used by the two header kinds. For every other kind you can leave it empty.

Expiry and prune

The expiry date is optional. When set, it must lie in the future. An expired pattern stops blocking at once, but its row stays in the list so you can see it. The Prune button deletes all expired patterns in one step.

Integrity check

The view checks the pattern file on every visit. When the file is broken, for example because it holds invalid data or a pattern with an unknown kind, a warning banner appears. The firewall silently skips the affected entries during request handling, so the banner is your signal to open the patterns file and fix or remove them.

Blocked keys

This view lists the keys that fail2ban and allow2ban rules have banned automatically. A key is usually a client IP address. The bans are read live from the store that your configuration uses (see Storage), so the view is empty when you use the InMemoryCache, which keeps no state between requests.

Bans are grouped by the rule that created them. Each group carries a badge that shows the rule type, fail2ban or allow2ban. Inside a group every ban shows the key, the remaining time, and the exact time the ban ends. The bans with the least time left are listed first. Use the search field to find a single key across all groups.

The Unban button removes a single ban after a confirmation dialog and lets the key through again right away. When the behavior that triggered the ban continues, the rule bans the key again on the next matching request.

Blocklist matches do not appear here. A blocklist rule answers each matching request with a 403 response on the spot and keeps no ban, so there is nothing to list. To see blocklist activity, use the event log and the Statistics view.

Statistics

This view answers one question: how much unwanted traffic the firewall blocked. It shows the number of attackers blocked today, a chart over time, and the rules and paths that triggered most often. For the full description of the recorded data, the privacy model, and the extension settings, see Statistics.