{"id":1517,"date":"2026-10-26T22:12:09","date_gmt":"2026-10-26T22:12:09","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1517"},"modified":"2026-10-26T22:12:09","modified_gmt":"2026-10-26T22:12:09","slug":"fail2ban-jail-regex-tarpit-single-vcpu-cost","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/fail2ban-jail-regex-tarpit-single-vcpu-cost\/","title":{"rendered":"Fail2Ban on a Busy VPS: Jail Regex Cost, Tarpit Behaviour and CPU You Didn’t Budget For"},"content":{"rendered":"
\n

Fail2Ban installations are cheap to add and expensive to keep cheap. The package itself idles at a few megabytes, but each jail you enable spawns a log reader with a regex, and on a single-vCPU VPS a badly written filter can consume more CPU than the service it is protecting. This article is about the running cost of an existing fail2ban setup: which jails earn their cycles, why broad regexes blow up, how ban churn affects the kernel firewall, and where to verify with top<\/code> and pidstat<\/code> before you add another filter. If you’re still picking hardware, the VPS plans sized for small daemons like fail2ban<\/a> matter here \u2014 one vCPU makes every percentage point visible.<\/p>\n

Where the CPU Actually Goes<\/h2>\n

Fail2ban’s architecture is one thread per jail (by default). Each thread tails its logfile, runs the filter’s failregex line by line, and on a match calls into the ban action \u2014 usually iptables<\/code> or nftables<\/code>. Three costs follow from that: parsing volume (lines per second \u00d7 regex cost), match rate (how often a ban fires), and action cost (how expensive the ban\/unban syscall path is). On a quiet VPS the first dominates during log bursts; the third dominates during an attack.<\/p>\n

systemctl status fail2ban --no-pager\nfail2ban-client status\nps -o pid,pcpu,pmem,etime,cmd -C fail2ban-server\npidstat -t -p $(pgrep -f fail2ban-server) 5 12<\/code><\/pre>\n
pidstat -t<\/code> breaks the number out per thread, which is the only way to see which jail is burning cycles. The main thread stays near zero; a jail thread at 8% of a single core is one eighth of your entire machine.<\/p>\n
Log Parsing Cost per Jail<\/h2>\n
Measure it directly instead of guessing. fail2ban-regex<\/code> runs your filter against a sample log and prints timing and match counts:<\/p>\n
fail2ban-regex \/var\/log\/auth.log \/etc\/fail2ban\/filter.d\/sshd.conf --print-all-matched<\/code><\/pre>\n
Expected output shape on a 50 MB auth log:<\/p>\n
Lines: 214833 lines, 0 ignored, 1842 matched, 212991 missed\nDate template hits: 214833\nSuccess, the total number of match is 1842\n\nPerformance:\n============\n  Hits: 1842  [.. ]\n  Misses: 212991\n  ...\n  Total: 3.812 s   (56,350 lines\/s)<\/code><\/pre>\n
56k lines\/sec on a 1 vCPU box sounds fine until you note that auth.log during an SSH brute-force campaign can grow at 2,000 lines\/sec across a handful of IPs. That’s 3.5% of the core just to read the file \u2014 acceptable. Now try a filter with .*<\/code> in the middle of the regex against the same log and the throughput drops by an order of magnitude. The fix is narrowing the regex to the literal prefix the daemon actually emits.<\/p>\n
How Broad Regexes Blow Up<\/h2>\n
Fail2ban’s filter regexes are Python re<\/code> patterns matched against each line, anchored at the start by default. The catastrophic patterns are the ones with nested quantifiers or a wildcard prefix:<\/p>\n
# Bad: matches almost every line, then fails at the end\nfailregex = ^.*Failed password.* from <HOST>\n\n# Better: anchor to the literal the daemon emits first\nfailregex = ^Failed password for (?:invalid user )?\\S+ from <HOST> port \\d+ ssh2$\n\n# For journald-backed units, filter at the source\nbackend = systemd\njournalmatch = _SYSTEMD_UNIT=sshd.service<\/code><\/pre>\n
The bad line does not just match more \u2014 it forces the regex engine to scan the whole line before failing, on every line, including the 200,000 that will never match. The better form fails in the first token. On a busy auth log that is the difference between 2% and 20% of a core. Add journalmatch<\/code> and the kernel hands you only the relevant records, removing most of the parse cost entirely.<\/p>\n
Ban Churn: The iptables Cost Nobody Budgets<\/h2>\n
Every ban and unban writes a rule. With default iptables<\/code> and a linear ruleset, each insert is O(n) in the number of existing rules, and a distributed SSH attack can produce hundreds of rules in minutes. The visible symptom is not fail2ban CPU \u2014 it’s ksoftirqd<\/code> and packet processing time on the forwarding path.<\/p>\n
iptables -L f2b-sshd -n | wc -l\nnft list set inet f2b-table addr-set-sshd 2>\/dev\/null | head\nipset list f2b-sshd 2>\/dev\/null | grep -c '^[0-9]'\n\nwatch -n2 'iptables -L -n | wc -l'<\/code><\/pre>\n
If the rule count climbs past a few thousand, switch the action to an ipset or nftables set:<\/p>\n
# \/etc\/fail2ban\/jail.d\/defaults-debian.conf\n[DEFAULT]\nbanaction = nftables-multiport\nbanaction_allports = nftables-allports<\/code><\/pre>\n
Set membership is O(1) per packet versus a linear walk, and adding a ban no longer rewrites a chain. On a single vCPU serving HTTP, this change is usually worth more than any filter tuning.<\/p>\n
Why sshd Plus recidive Is Usually Enough<\/h2>\n
The default Debian\/Ubuntu install ships a dozen jails: sshd<\/code>, apache-auth<\/code>, nginx-http-auth<\/code>, postfix<\/code>, proftpd<\/code>, vsftpd<\/code> and more. Most of them tail logfiles that do not exist on your box, which is harmless but wasteful \u2014 and a few of them, on a shared log, duplicate work. The pattern that covers real attacks with minimal cost:<\/p>\n
[sshd]\nenabled  = true\nmaxretry = 4\nfindtime = 10m\nbantime  = 1h\nbackend  = systemd\n\n[recidive]\nenabled  = true\nlogpath  = \/var\/log\/fail2ban.log\nbantime  = 1w\nfindtime = 1d\nmaxretry = 3<\/code><\/pre>\n
sshd catches the first attempt; recidive escalates anyone who comes back after three bans to a week. That two-jail setup handles the overwhelming majority of automated SSH traffic. Add nginx-limit-req<\/code> only if you actually see request-rate abuse in your access log, and verify with fail2ban-regex<\/code> that it matches before enabling it \u2014 a jail that matches nothing is pure cost.<\/p>\n
A common mistake is setting maxretry = 1<\/code> with a 1-hour bantime. That produces ban churn from legitimate users with a stale key, fills the ban list with real humans, and hides actual attackers among them. Four retries in ten minutes is enough to stop scripts and forgiving enough to keep people out of the ban list.<\/p>\n
Tarpit and Blackhole: Behaviour and Downside<\/h2>\n
Adding iptables -j TARPIT<\/code> (from xtables-addons) or -j DROP<\/code> changes the failure mode. DROP<\/code> is silent: the attacker’s SYN goes nowhere, they retry, and their timeout is minutes. TARPIT<\/code> accepts the connection and then holds it open with a zero window, which keeps the attacker’s socket occupied \u2014 but each held socket consumes kernel memory and a conntrack entry on your box.<\/p>\n
conntrack -C\ncat \/proc\/sys\/net\/netfilter\/nf_conntrack_count\ncat \/proc\/sys\/net\/netfilter\/nf_conntrack_max<\/code><\/pre>\n
If nf_conntrack_count<\/code> approaches 80% of max<\/code>, you get nf_conntrack: table full, dropping packet<\/code> in dmesg and legitimate connections start failing. A tarpit under a 10k-connection flood will fill the table on a 2 GB VPS long before the attacker gives up. For most single-server setups, REJECT --reject-with tcp-reset<\/code> is the better trade: it ends the connection immediately, costs nothing to hold, and the attacker’s script moves on. Save the tarpit for hosts with conntrack headroom and a reason to waste attacker time.<\/p>\n
Reading status Output Correctly<\/h2>\n
fail2ban-client status sshd<\/code><\/pre>\n
Status for the jail: sshd\n|- Filter\n|  |- Currently failed: 7\n|  |- Total failed:     4183\n|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd\n`- Actions\n   |- Currently banned: 112\n   |- Total banned:     967\n   `- Banned IP list:   45.148.x.x 103.79.x.x ...<\/code><\/pre>\n
Two ratios matter. Total banned<\/code> growing steadily is normal. Currently banned<\/code> close to Total banned<\/code> means bantime is long relative to attack volume and the list is growing without bound \u2014 check whether those IPs ever return. And if Total failed<\/code> is climbing by thousands an hour while Total banned<\/code> barely moves, your findtime<\/code> is too short or maxretry<\/code> too high for the actual pattern.<\/p>\n
Tuning Checklist<\/h2>\n