Log Dejargonizer

fail2ban · Event NOTICE [jail] Ban

fail2ban: an address was banned

fail2ban read enough failed attempts from one address in its time window and inserted a firewall rule to drop it. The ban is temporary by design, and the log line tells you which jail decided — which is more informative than the address itself.

Also written as fail2ban Ban noticefail2ban.actions Banfail2ban banned ip logNOTICE [sshd] Ban

What it means for you

On a personal computer

Your server blocked an address that was repeatedly failing to log in. This is exactly what fail2ban is for, and on any machine reachable from the internet it will happen many times a day. It does not mean anyone got in — it means they were stopped before they could keep trying.

For an analyst

Treat the ban stream as a scanner census, not as alerts. Two things are worth wiring up: an alert when the banned address is inside your own ranges, because that is either a misconfigured service or a compromised internal host, and an alert on repeated bans of the same address across many hosts, which is one actor rather than background noise. Also remember bans do not survive a restart unless persistence is configured, so a rebooted host starts from an empty table.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
2026-09-07 14:07:19,231 fail2ban.actions        [1180]: NOTICE  [sshd] Ban 198.51.100.77
2026-09-07 14:17:20,884 fail2ban.actions        [1180]: NOTICE  [sshd] Unban 198.51.100.77

The fields that decide it

Everything else in the log line is context.

Jail name
Which jail matched, in brackets. This is the field that says what the address was doing.
  • [sshd]Failed SSH authentication. The overwhelming majority on any internet-facing host.
  • [recidive]The address has already been banned by other jails repeatedly. Recidive bans are much longer and mean a persistent actor rather than a passing scan.
  • [nginx-http-auth] / [apache-auth]Web authentication failures, which are more likely to be aimed at you specifically than SSH noise is.
  • [postfix-sasl]Mail authentication attempts, usually credential stuffing against mailboxes.
Action
Ban, Unban, or Found. Found is a matched line that has not yet reached the threshold, and it is logged at a lower level — if you only collect NOTICE, you see bans and not the attempts behind them.
Address
The banned source. Compare it against your own ranges before anything else; a ban of an internal address is a different event entirely.
Timing
Bans are temporary. The default bantime is measured in minutes, so an address reappearing later has not evaded anything — it simply waited, or the ban expired.

Ordinary reasons this happens

Most of the time it is one of these.

  • Internet background scanning. Any exposed SSH port attracts continuous automated login attempts, and the bans are the expected result.
  • A user or a device with a stale saved password retrying automatically until it crosses the threshold — this is how people ban themselves.
  • A monitoring probe or health check authenticating incorrectly against a service.
  • A backup or synchronisation job with an expired credential, hammering from a known internal address.
  • A NAT gateway or corporate proxy, where one address represents many people and one person's typos ban everyone behind it.

When it is not ordinary

Credential guessing against an exposed service.

What gives it awayBans clustering by jail and by target account. The ban itself is routine; a matching successful authentication before the threshold was reached is the finding.

ATT&CK T1110.001

Password spraying tuned to stay below the threshold.

What gives it awayVery few bans despite heavy authentication failure volume, and many distinct source addresses each making one or two attempts. Spraying is designed to avoid producing this event, so an absence of bans alongside high failure counts is itself the signal.

ATT&CK T1110.003

A compromised internal host being used to attack others.

What gives it awayA ban for an address inside your own network. There is no benign version of this that does not also need fixing.

ATT&CK T1021.004

What to do next

  1. Check whether the address is one of yours. An internal ban is either a broken service or a compromised host, and both need action; an external ban usually needs none.
  2. Read the jail name to find out what the address was actually doing. An [sshd] ban and an [nginx-http-auth] ban warrant different amounts of interest.
  3. Look at the service's own log for that address before the ban: `grep <address> /var/log/auth.log`. The question is whether anything succeeded, not how many failed.
  4. Confirm the ban is actually in force: `fail2ban-client status sshd` lists currently banned addresses, and the firewall table shows the rules.
  5. If you banned yourself or a colleague, `fail2ban-client set sshd unbanip <address>` removes it immediately. Then fix the stale credential rather than raising the threshold.
  6. For a persistent actor, check whether the [recidive] jail is enabled. It exists precisely so that repeat offenders get long bans without you lowering the thresholds everywhere else.
  7. Remember that bans are lost on restart unless you have persistence configured, so a host that reboots nightly effectively starts clean each morning.

Queries to run

grep The most-banned addresses. Repeat entries mean the ban expired and the source came back. 
grep 'Ban' /var/log/fail2ban.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20
grep Which jails are active and what is currently banned. Faster and more accurate than reading the log. 
fail2ban-client status && fail2ban-client status sshd
grep Bans grouped by jail, which tells you what is actually being attacked rather than by whom. 
grep 'Ban' /var/log/fail2ban.log | grep -oP '\[\K[^\]]+' | sort | uniq -c | sort -rn
grep Bans of private addresses. This should be empty; anything here is either a misconfiguration or an internal host behaving badly. 
grep -E 'Ban (10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)' /var/log/fail2ban.log

Common questions

Does a fail2ban ban mean someone was trying to hack me?

In the sense that somebody was making repeated failed login attempts, yes. In the sense that you were targeted, almost never. Every publicly reachable SSH port receives continuous automated guessing from compromised machines worldwide, and bans are simply the tool doing its job. What matters is whether anything succeeded — check the service log for that address, not the ban count.

How long does a fail2ban ban last?

As long as the jail's bantime, which defaults to ten minutes in a stock configuration and is very often raised. The ban is temporary on purpose: permanent bans grow a firewall table without bound and eventually cost more than they save. If you want repeat offenders held longer, enable the recidive jail, which watches the ban log itself and applies much longer bans to addresses that keep coming back.

I banned myself. How do I get back in?

From a console or another machine that is not banned, run `fail2ban-client set <jail> unbanip <your address>` — for example `fail2ban-client set sshd unbanip 198.51.100.5`. Then fix the cause rather than the symptom: it is almost always a saved password on a phone, a backup job, or a script still offering an old credential. Adding your management range to `ignoreip` prevents a repeat.

Why do I see the same address banned again and again?

Because bans expire. When the bantime runs out the firewall rule is removed, and if the source is still scanning it will trip the threshold again within minutes. That is normal and not a failure of the tool. If it bothers you, the recidive jail exists exactly for this — it bans addresses that have already been banned several times, for far longer.

Read next

Vendor documentation

Last reviewed 7 September 2026