База на знаења

Fail2Ban's built-in filters cover common services like SSH, but you can write custom filters to protect your own application from brute-force login attempts, scraping, or abusive request patterns not covered by default.

Prerequisites

• Fail2Ban already installed — see How to Install and Configure Fail2Ban on Ubuntu & Debian
• Your application logs failed attempts in a parseable format

Understanding Fail2Ban Filters

A filter is a regular expression pattern matched against your log file, identifying lines that represent a failed/suspicious attempt worth counting toward a ban.

Example Scenario: Protecting a Custom Application Login

Assume your application logs failed logins like:

2026-08-12 14:32:01 Failed login attempt for user admin from 203.0.113.50

Step 1 — Create the Filter

sudo nano /etc/fail2ban/filter.d/myapp-auth.conf

[Definition]
failregex = ^.*Failed login attempt for user .* from <HOST>$
ignoreregex =

<HOST> is a Fail2Ban placeholder that matches an IP address.

Step 2 — Test the Filter Against Existing Logs

sudo fail2ban-regex /var/log/myapp/auth.log /etc/fail2ban/filter.d/myapp-auth.conf

This shows how many existing log lines match, letting you verify the regex is correct before deploying it.

Step 3 — Create the Jail

sudo nano /etc/fail2ban/jail.local

[myapp-auth]
enabled = true
filter = myapp-auth
logpath = /var/log/myapp/auth.log
maxretry = 5
findtime = 10m
bantime = 1h
action = iptables[name=MyApp, port=443, protocol=tcp]

Step 4 — Restart Fail2Ban

sudo systemctl restart fail2ban

Step 5 — Verify the Jail Is Active

sudo fail2ban-client status myapp-auth

Example: Protecting Nginx-Based Applications from Excessive Scraping

sudo nano /etc/fail2ban/filter.d/nginx-scraping.conf

[Definition]
failregex = ^<HOST> .* "(GET|POST).*" (404|403) .*$
ignoreregex =

[nginx-scraping]
enabled = true
filter = nginx-scraping
logpath = /var/log/nginx/access.log
maxretry = 20
findtime = 1m
bantime = 30m

Bans IPs generating an unusually high rate of 404/403 responses in a short window — often a sign of scanning or scraping.

Example: Protecting a REST API's Login Endpoint

[Definition]
failregex = ^<HOST> .* "POST /api/login.*" 401 .*$
ignoreregex =

Testing Regex Patterns Before Deploying

Always validate with fail2ban-regex against real log samples before trusting a new filter in production — an incorrect regex either bans nothing (useless) or bans too aggressively (locks out legitimate users).

Common Errors

Filter matches nothing — verify the exact log format with tail -f on the real log file; log formats often differ slightly from documentation examples.

Legitimate users getting banned — the maxretry/findtime thresholds may be too aggressive for genuine usage patterns; adjust based on observed legitimate traffic.

Best Practices

• Always test new filters with fail2ban-regex before enabling the jail
• Set reasonable thresholds that distinguish genuine attacks from normal usage variance
• Whitelist your own known IPs to avoid accidentally locking yourself out while testing

Continue Reading

• How to Install and Configure Fail2Ban on Ubuntu & Debian
• How to Secure a VPS Against DDoS Attacks
• How to Monitor Auth Logs and Detect Intrusion Attempts

Browse more articles in Advanced Security & Compliance.