Fail2ban Jail Generator

Fail2ban jail.local generator for SSH and web servers

Fail2ban Jail Generator creates a safe starting point for /etc/fail2ban/jail.local. It combines a filter, port, log source, retry threshold, observation window, ban duration, and trusted addresses. The tool only builds text: it writes nothing to the operating system, reloads no firewall, and executes no server command.

How a jail connects logs, filters, and actions

Fail2ban watches events from logpath or a journal backend. A filter recognizes failed attempts, and the jail counts them per address during findtime. Reaching maxretry invokes the configured ban action for bantime. Every part must match the target distribution, service, and log format.

SSH, Nginx, and bot presets

The SSH preset selects the sshd filter, the ssh service, and a common /var/log/auth.log path. Some systems use /var/log/secure, while a systemd backend can interpret log sourcing differently. Nginx auth starts with the error log; botsearch examines requests in the access log. Confirm the real paths and the Fail2ban process permissions.

The strict preset lowers the threshold and extends observation and ban periods, but stricter is not automatically safer. Mobile users, offices behind shared NAT, and automation can create many legitimate failures from one address. Observe current logs and compare mistakes with attack patterns before increasing enforcement.

Validation that protects configuration structure

Jail and filter names are limited to safe characters. A port accepts service names or numbers separated by commas, and a log path must be absolute without newlines or .. segments. A modified Livewire request therefore cannot append another directive. The retry count is restricted to an integer from 1 through 100.

Durations accept a positive number with seconds, minutes, hours, days, weeks, months, or years; -1 is available for a permanent ban. Trusted entries must be valid IPv4, IPv6, or CIDR networks, with at most 50 entries. Hostnames are deliberately rejected because their resolution can change independently from this reviewed configuration.

Using ignoreip without removing protection

Adding an administrator address reduces self-lockout risk, but trusting an entire provider range creates a lasting gap. Use the narrowest justified prefix and document who owns it. Dynamic addresses need an emergency access procedure, not progressively broader exceptions.

Fail2ban supplements rather than replaces key authentication, disabled password login, and restricted privileged accounts. Keep client and host declarations organized in a separate SSH configuration file with reviewed host names, users, and identity keys. Administrative access and service ports must remain consistent with the host firewall.

Log backends and ban mechanisms

auto lets Fail2ban choose a method for following files. systemd reads service journal events, polling periodically checks files, and pyinotify responds to file-system events when its library is installed. Not every filter provides a useful journal match, so systemd mode must be tested on the actual host.

The selected UFW, iptables, nftables, or firewalld action must match the firewall that really controls traffic. An installed command does not prove that its rules are active. Infrastructure checks can be represented in a workflow made with the GitHub Actions Generator, but credentials and privileged command output must not leak to public CI logs.

Safe deployment and testing

1. Test the filter with fail2ban-regex against a representative log sample that contains no secrets.
2. Back up the active configuration and keep a second administrative session available.
3. Save the reviewed result as /etc/fail2ban/jail.local with restricted write permissions.
4. Run fail2ban-client -t and do not reload the service while it reports an error.
5. Reload Fail2ban, then inspect jail status, its log, and the resulting firewall rules.

Deploy this change separately from operating-system upgrades. Preserve a rollback route through the hosting console. Keep configuration and runbooks free of secrets, and exclude unnecessary local copies with a policy from the Gitignore Generator.

Monitoring after activation

An active status alone does not prove protection. Inspect filter matches, current bans, and log growth. No bans can mean a quiet service or a broken filter. A sudden flood can indicate an attack, a false match, or a threshold that is too low. Read metrics together with service and firewall logs.

Review ignoreip exceptions, filter versions, and log rotation regularly. Retest expressions after an application changes its log format. Fail2ban is reactive; patching, reducing exposed services, and using strong authentication remain the primary controls.

Frequently asked questions