All free tools Generated in your browser

Fail2Ban Jail Generator

Set your ban policy, pick the services you run, and generate a complete jail.local file for fail2ban.

BAN POLICY

Build a jail.local file

jail.local

Never edit jail.conf. That file belongs to the fail2ban package and is replaced on every upgrade. Put your settings in /etc/fail2ban/jail.local or in a file under /etc/fail2ban/jail.d/ ending in .local, which fail2ban reads after jail.conf and which upgrades leave alone.

[DEFAULT] section
How long an address stays blocked after it is banned.
Fail2ban accepts the short forms m, h and d.
The window in which failures are counted. Reaching the retry limit inside this window triggers a ban.
Keep this short. A long window bans slow, low-volume attempts as well.
Failures allowed inside the find time before the address is banned.
Use systemd when the service writes to journald instead of a log file.
One IPv4 address, IPv6 address or CIDR range per line. Keep 127.0.0.1/8 and ::1, and add the public address you administer the server from so a mistake cannot lock you out.
Match this to the firewall the server already uses. Mixing iptables and nftables rules on the same host creates confusing results.
Notifications
Where ban notices are sent. Leave empty to keep the value from jail.conf.
The From address fail2ban uses. Use a domain the server is allowed to send for.
Only relevant when the action sends email. The chosen command must exist on the server.
In plain English: action_ simply blocks the address. action_mw also emails you who the address belongs to. action_mwl adds the log lines that caused the ban, which is the most useful for diagnosis but also the most likely to place visitor data in your inbox.
Jails

    Add your own IP to ignoreip before you restart fail2ban. A low maxretry combined with a long bantime can ban you out of your own server after a handful of mistyped passwords, and the ban is enforced by the firewall rather than by SSH. Keep a second session or a provider console open while you test.

    We do not store your data. Addresses, log paths and email addresses are validated and assembled into the file entirely in your browser and are never submitted to VPSLake.

    HOW TO USE IT

    Generate and apply in four steps

    You need fail2ban installed on the server and a shell session with sudo access.

    1. 1

      Set the global policy

      Choose the ban time, find time and retry limit that suit the server, pick the ban action that matches your firewall, and list every address that must never be banned in ignoreip. Include the public address you administer from.

    2. 2

      Add a jail for each service

      Select a preset such as sshd, nginx-http-auth or postfix-sasl. The port, filter and default log path are filled in for you. Adjust the log path if your distribution stores it elsewhere, and set per-jail overrides where a service needs a stricter or looser limit.

    3. 3

      Generate and install the file

      Select generate, review the output, then copy or download it and save it as /etc/fail2ban/jail.local. Verify it with sudo fail2ban-client -t before restarting anything.

    4. 4

      Restart and confirm

      Run sudo systemctl restart fail2ban, then sudo fail2ban-client status to confirm the jails started and sudo fail2ban-client status sshd to see the log path, failure count and banned addresses for one jail.

    How fail2ban reads its configuration

    Fail2ban loads jail.conf first, then every .local file that sits beside it, then everything in jail.d/. Later values win, so a jail.local only needs the settings you want to change. Anything you leave out keeps the packaged default.

    That layering is why editing jail.conf is a mistake: the package manager replaces that file on upgrade and your changes disappear without warning. The same rule applies to filters and actions, where you override filter.d/sshd.conf with filter.d/sshd.local.

    The [DEFAULT] section in the generated file sets the policy every jail inherits. Each jail section then names its filter, its log source and any value that should differ.

    What the generated file contains

    The output is a plain INI file with a comment header, one [DEFAULT] block and one block per jail. Per-jail keys are written only when they differ from the defaults, which keeps the file short and makes the intent obvious to the next person who reads it.

    • Ban time, find time, retry limit and backend
    • An ignoreip list validated as IPv4, IPv6 or CIDR
    • A ban action matched to iptables, nftables or ufw
    • Optional email notification settings
    • Per-service jails with the correct filter and log path

    What it does not contain is any filter definition. The presets reference filters that ship with fail2ban; a custom jail needs a matching file in /etc/fail2ban/filter.d/ before it will start.

    Test the configuration before you rely on it

    This file is a reviewed starting point, not an audited security control. It has not been tested against your log formats, your firewall or your distribution. Run sudo fail2ban-client -t first, keep a second administrative session or a provider console open while you restart the service, and confirm with sudo fail2ban-client status <jail> that each jail found its log file. A jail that points at a missing log path will fail to start, and an aggressive retry limit combined with a long ban time can block legitimate users, including you.

    FREQUENTLY ASKED QUESTIONS

    Fail2Ban Jail Generator FAQ

    Save it as /etc/fail2ban/jail.local, owned by root and readable by root. If you prefer one file per service, split the sections into files such as /etc/fail2ban/jail.d/sshd.local. Do not paste the content into jail.conf, because a package upgrade will overwrite it.
    Recent Ubuntu releases do not ship rsyslog by default, so sshd messages go to systemd-journald and /var/log/auth.log never appears. Clear the log path for that jail and set the backend to systemd, or install rsyslog if you would rather keep a text log. The error in /var/log/fail2ban.log usually reads that the log path was not found.
    %(action_)s bans the address and does nothing else. %(action_mw)s also emails you a whois lookup of the address. %(action_mwl)s adds the log lines that triggered the ban. The email variants need a working mail transport on the server and a valid destemail, otherwise the action fails and the ban may not be applied.
    Open your provider console or VNC session and run sudo fail2ban-client set sshd unbanip 203.0.113.10 with your own address. To clear a whole jail use sudo fail2ban-client unban --all. Then add your address to ignoreip and reload with sudo fail2ban-client reload so it cannot happen again.
    Use whatever already manages the firewall. On a server running ufw, choose ufw so bans appear in sudo ufw status. On a plain nftables host choose nftables-multiport. On older systems using legacy iptables rules, choose iptables-multiport. Fail2ban will still work if the choice is wrong, but the rules end up in a table nobody is looking at.
    It watches fail2ban's own log and bans addresses that keep coming back after earlier bans expire. Because a repeat offender has already proved itself, the preset uses a long ban time, a long find time and an all-ports ban action. It only works when /var/log/fail2ban.log exists and the log level records bans, which is the default.
    No, and that is deliberate. Every preset here references a filter that fail2ban already installs in /etc/fail2ban/filter.d/. If you add a custom jail you must supply the matching filter yourself; fail2ban will refuse to start a jail whose filter does not exist.
    No. The page makes no network requests after it loads. Validation, file assembly, copying and downloading all happen in your browser, and nothing you enter is stored or transmitted.