fail2ban-clientInspect and control fail2ban's brute-force bans
fail2ban watches logs for repeated failures (SSH password guesses, bad HTTP auth) and bans the offending IPs in the firewall for a while. fail2ban-client is how you talk to it: list jails, see who is banned, unban a colleague, ban an attacker by hand and check its settings.
fail2ban-client [ping | status [JAIL] | banned | set JAIL banip|unbanip IP... | get JAIL maxretry|bantime|findtime | reload [JAIL]]A new server shows thousands of SSH login attempts in its logs and you want to check what fail2ban is doing about it.
sudoThe server's control socket is root-only, so every fail2ban-client command needs root.
fail2ban-server is a Python daemon. Each jail follows one log source: a file such as /var/log/auth.log, or the systemd journal (the default for sshd on Ubuntu 24.04, matching _SYSTEMD_UNIT=sshd.service + _COMM=sshd). Every new line is tested against the filter's failregex patterns from /etc/fail2ban/filter.d; a match records a failure for the captured <HOST>. When one IP reaches maxretry failures within findtime, the jail runs its ban action, which on Ubuntu 24.04 adds the IP to an nftables set (older setups use iptables chains like f2b-sshd), so the kernel drops or rejects its packets before sshd ever sees them. After bantime the action removes the IP again. Ban state is kept in a SQLite database so bans survive restarts. fail2ban-client sends commands to the server over /run/fail2ban/fail2ban.sock. Configuration lives in jail.conf (don't edit) and your overrides in jail.local or jail.d/*.local.
fail2ban reads sshd's log, counts failures per IP, and adds repeat offenders to a firewall set until the ban expires.
A bot tries passwords. Nothing blocks it yet: the firewall lets port 22 through and sshd rejects each wrong password.
pingIs the server alive? Replies 'pong'statusNumber of jails and their namesstatus JAILFailures counted, currently and total banned, banned IP listbanned [IP]All banned IPs per jail, or which jails ban one IPset JAIL unbanip IPUnban an address nowset JAIL banip IPBan an address by handunban --allUnban every IP in every jailget JAIL maxretry|findtime|bantimeRead a jail's live settings (times in seconds)reload [JAIL]Re-read configuration (all or one jail)fail2ban-regex LOG FILTERTest a filter against a log before trusting itEditing /etc/fail2ban/jail.conf directlyIt's the package's file: an upgrade can overwrite it and your changes vanish.
Put overrides in /etc/fail2ban/jail.local or /etc/fail2ban/jail.d/NAME.localNot setting ignoreip for your own office or VPN rangeA few typos from a shared NAT address bans the whole team, and you may lose your only way in.
ignoreip = 127.0.0.1/8 ::1 <office and VPN CIDRs>Assuming the sshd jail works after switching sshd logging or moving to a containerIf the jail reads a log file or journal unit that no longer receives the messages, it silently counts nothing.
Check that 'Total failed' grows, and test with fail2ban-regex against the real logRelying on fail2ban as the main SSH defenceIt only slows down password guessing; distributed attacks from many IPs stay under maxretry.
Disable password auth (keys only), restrict port 22 by source IP or VPN, keep fail2ban as an extra layerTry these on a Linux machine of your own. Each task has a hint and a solution.
Check whether the fail2ban server is running and responding.
Write a jail override that bans after 3 failures within 5 minutes for 2 hours, and never bans 10.0.0.0/8.
Count the failed SSH password attempts in a log by source IP, to see what fail2ban would be fed.
fail2ban-clientInspect and control fail2ban's brute-force bans
fail2ban watches logs for repeated failures (SSH password guesses, bad HTTP auth) and bans the offending IPs in the firewall for a while. fail2ban-client is how you talk to it: list jails, see who is banned, unban a colleague, ban an attacker by hand and check its settings.
fail2ban-client [ping | status [JAIL] | banned | set JAIL banip|unbanip IP... | get JAIL maxretry|bantime|findtime | reload [JAIL]]A new server shows thousands of SSH login attempts in its logs and you want to check what fail2ban is doing about it.
sudoThe server's control socket is root-only, so every fail2ban-client command needs root.
fail2ban-server is a Python daemon. Each jail follows one log source: a file such as /var/log/auth.log, or the systemd journal (the default for sshd on Ubuntu 24.04, matching _SYSTEMD_UNIT=sshd.service + _COMM=sshd). Every new line is tested against the filter's failregex patterns from /etc/fail2ban/filter.d; a match records a failure for the captured <HOST>. When one IP reaches maxretry failures within findtime, the jail runs its ban action, which on Ubuntu 24.04 adds the IP to an nftables set (older setups use iptables chains like f2b-sshd), so the kernel drops or rejects its packets before sshd ever sees them. After bantime the action removes the IP again. Ban state is kept in a SQLite database so bans survive restarts. fail2ban-client sends commands to the server over /run/fail2ban/fail2ban.sock. Configuration lives in jail.conf (don't edit) and your overrides in jail.local or jail.d/*.local.
fail2ban reads sshd's log, counts failures per IP, and adds repeat offenders to a firewall set until the ban expires.
A bot tries passwords. Nothing blocks it yet: the firewall lets port 22 through and sshd rejects each wrong password.
pingIs the server alive? Replies 'pong'statusNumber of jails and their namesstatus JAILFailures counted, currently and total banned, banned IP listbanned [IP]All banned IPs per jail, or which jails ban one IPset JAIL unbanip IPUnban an address nowset JAIL banip IPBan an address by handunban --allUnban every IP in every jailget JAIL maxretry|findtime|bantimeRead a jail's live settings (times in seconds)reload [JAIL]Re-read configuration (all or one jail)fail2ban-regex LOG FILTERTest a filter against a log before trusting itEditing /etc/fail2ban/jail.conf directlyIt's the package's file: an upgrade can overwrite it and your changes vanish.
Put overrides in /etc/fail2ban/jail.local or /etc/fail2ban/jail.d/NAME.localNot setting ignoreip for your own office or VPN rangeA few typos from a shared NAT address bans the whole team, and you may lose your only way in.
ignoreip = 127.0.0.1/8 ::1 <office and VPN CIDRs>Assuming the sshd jail works after switching sshd logging or moving to a containerIf the jail reads a log file or journal unit that no longer receives the messages, it silently counts nothing.
Check that 'Total failed' grows, and test with fail2ban-regex against the real logRelying on fail2ban as the main SSH defenceIt only slows down password guessing; distributed attacks from many IPs stay under maxretry.
Disable password auth (keys only), restrict port 22 by source IP or VPN, keep fail2ban as an extra layerTry these on a Linux machine of your own. Each task has a hint and a solution.
Check whether the fail2ban server is running and responding.
Write a jail override that bans after 3 failures within 5 minutes for 2 hours, and never bans 10.0.0.0/8.
Count the failed SSH password attempts in a log by source IP, to see what fail2ban would be fed.