The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →A sudden Fail2ban memory increase after an attack is usually caused by the size and lifetime of the ban and match state, not by a universal memory leak. Hundreds of thousands of bans, long or permanent retention, recidive jails, an oversized systemd journal replay, or a large SQLite database can all increase resource use. First establish whether the growth is in fail2ban-server, the firewall or kernel, or the logging subsystem; then reduce retained state and verify that bans are being enforced on the traffic path you actually use.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Why Fail2ban can use much more memory after an attack
Fail2ban watches logs, records matches, tracks ban timers, and asks a firewall action to block addresses. A large attack increases several of those workloads at once. The important distinction is between a larger working set that follows your configuration and a process that continues growing after the workload and ban population are stable.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
A very large ban population
Every active ban has to be tracked until it expires or is removed. Historical Fail2ban issue reports describe attempts to maintain approximately 500,000 to 1,000,000 banned IP addresses and another report of a machine using about 2.4 GB of process memory. Those are incident reports, not capacity guarantees, benchmarks, or a memory-per-ban formula. No authoritative Fail2ban source establishes a universal memory ceiling or a fixed number of bytes per ban.
At that scale, the Python process, its in-memory data structures, SQLite activity, and the firewall objects can all become expensive. A smaller host can run into pressure with far fewer addresses, especially when several jails, long ban times, or repeated matches are involved.
Retained matches and database state
Fail2ban keeps state needed to enforce bans and, depending on its configuration and version, stores information in its SQLite database. A long database retention period, repeated matches, or recidive logic can keep substantially more information than the current firewall list suggests. A large /var/lib/fail2ban/fail2ban.sqlite3 file is therefore a useful clue, but its disk size is not a direct measurement of resident memory.
Long, permanent, or duplicated bans
A jail with an unusually long bantime retains addresses for longer. bantime = -1 creates a permanent ban until an operator removes it, so a busy service can accumulate an effectively unbounded list. A recidive jail may intentionally give repeat offenders longer bans, but it also adds another layer of match and ban state. Enabling many overlapping jails can duplicate work and produce multiple records for the same attack.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchLog or journal replay
A systemd backend can process entries from the journal that match its configured service and filters. If the journal is unexpectedly large, has been rotated, or the match scope is too broad, Fail2ban may spend considerable time replaying old entries. The jail manual says rotated journals are ignored by default to avoid too many open files; explicitly enabling rotated-journal processing changes that behavior and should be deliberate.
The memory may not belong to Fail2ban
An nftables set, a long iptables rule list, a conntrack table, the kernel, or journald can consume memory while fail2ban-server remains stable. A growing firewall object can also make bans ineffective even though Fail2ban reports them as active. Attribution must come before tuning.
Measure the right component before changing configuration
Take a snapshot while the problem is visible, and repeat it after several minutes. A single number cannot show whether memory is stabilizing, climbing with every match, or being reclaimed after a scan ends.
Record process and host memory
pgrep -a -f fail2ban-server
ps -o pid,ppid,%mem,rss,vsz,etime,cmd -C fail2ban-server
free -h
cat /proc/meminfo | head -n 20
RSS is the resident memory currently held by the process; VSZ is virtual address space and is not equivalent to RAM consumption. Record the process ID and RSS at regular intervals. If RSS levels off while total memory continues to fall, investigate another component. If RSS grows in proportion to active bans or log replay, continue with the Fail2ban checks.
Free tools Windows power users keep installed
One-click scans. No signup required.
Count jails and bans
sudo fail2ban-client status
sudo fail2ban-client status JAIL_NAME
Run the per-jail command for every enabled jail. Record “Currently banned,” “Total banned,” and the filter and action names. A high current count points to retention and enforcement scale; a high historical total with a small current count points more toward event volume or database history.
Inspect the database, logs, and service journal
sudo stat /var/lib/fail2ban/fail2ban.sqlite3
sudo du -h /var/lib/fail2ban/fail2ban.sqlite3
sudo journalctl -ru fail2ban
sudo tail -n 200 /var/log/fail2ban.log
sudo systemctl status fail2ban --no-pager
The Fail2ban troubleshooting guidance specifically recommends starting with journalctl -ru fail2ban and identifies /var/log/fail2ban.log as a useful error source. Look for repeated startup messages, database errors, action failures, filter exceptions, “too many open files,” and a loop in which the same addresses are repeatedly unbanned and rebanned.
Inspect firewall and kernel objects
sudo iptables -L -n -v
sudo iptables -S
sudo nft list ruleset
sudo firewall-cmd --list-all 2>/dev/null
sudo conntrack -S 2>/dev/null
Use only the commands applicable to the firewall stack installed on the host. Note the number and size of chains, rules, and nftables sets. An iptables command may show only one compatibility layer while the active rules are managed by nftables, so confirm which backend your Fail2ban action uses. Compare these results with process RSS before concluding that the Python process is the source of all memory use.
| Observation | Likely area to investigate | Next check |
|---|---|---|
fail2ban-server RSS rises with current bans |
Ban cardinality or retention | Per-jail counts, bantime, permanent bans, recidive jails |
| RSS is stable but kernel memory or firewall objects grow | nftables, iptables, conntrack, or kernel state | Rule and set counts; action and backend in use |
| RSS rises while old log entries are being processed | Backend replay scope | Backend, journal matches, rotated logs, filter errors |
| SQLite file is large but current bans are modest | Retained match/database history | Database purge settings and historical event volume |
| Memory returns only after a restart | Unreleased working state or a version-specific defect | Logs, version, reproducible growth pattern, and issue history |
Bound ban and database retention
Review the effective configuration, not just the packaged example. Check /etc/fail2ban/jail.local, files under /etc/fail2ban/jail.d/, and any distribution-specific overrides. The jail manual documents the following controls:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
bantime: how long an address remains banned. Very long values and-1permanent bans make the active population accumulate.findtime: the time window in which failures are counted. A very broad window can make matches persist longer than intended.maxretry: the number of matching failures allowed withinfindtimebefore a ban. Setting it too low can turn normal bursts into a large ban list.- Database purge settings: control how old records are removed. Use a finite retention period that supports your incident-response needs rather than keeping every historical match indefinitely.
- Jail count and recidive behavior: remove duplicate coverage and make sure repeat-offender jails are an intentional policy, not an accidental second copy of the same workload.
A conservative starting point for a high-volume public service might look like this, but the values must match your threat model and legitimate-traffic pattern:
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
# Set a finite database purge age appropriate to your incident records.
# dbpurgeage = ...
Do not copy these numbers blindly. Shortening bantime reduces retained bans but may allow an attacker to return sooner. Raising maxretry reduces false positives but gives a noisy attacker more attempts. A recidive policy may reasonably use a longer duration than the ordinary service jail; keep that trade-off explicit.
Clear individual bans first
Remove only the addresses you have identified as safe to release:
sudo fail2ban-client set JAIL_NAME unbanip 203.0.113.25
Repeat for each affected jail when the address appears in more than one jail. Confirm the result with fail2ban-client status JAIL_NAME and by inspecting the corresponding firewall chain or set.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear all bans deliberately
For versions that provide the global unban command, use:
sudo fail2ban-client unban --all
This removes active bans; it does not necessarily erase the SQLite database or historical match records. If your packaged client does not support that syntax, unban addresses per jail with set JAIL_NAME unbanip and verify the installed client’s help output before scripting a bulk operation.
Reset the database only as a controlled recovery action
Deleting the database while Fail2ban is running can corrupt state and discards information that may be useful for investigation. If the database itself is damaged or unmanageably large:
- Save the current configuration, status output, logs, and a copy of the database.
- Arrange console or out-of-band access so a firewall change cannot lock you out.
- Stop Fail2ban using your service manager and confirm the process has exited.
- Move the database to a dated backup name rather than deleting it immediately.
- Start Fail2ban and inspect its journal, jail status, and firewall actions.
- Reapply a finite purge policy and monitor database growth before restoring any old state.
Service stop and start behavior depends on the configured action. Treat a database reset as loss of historical and possibly active state, not as a routine memory-cleaning command.
Check whether the backend is replaying too much journal or log data
Systemd journal backend
When a jail uses backend = systemd, verify that its journal match selects only the intended service and message fields. A broad or missing journalmatch can make the jail inspect unrelated entries. Check the size and age of the journal:
sudo journalctl --disk-usage
sudo journalctl -u SERVICE_NAME --since "24 hours ago" --no-pager
Rotated journals are ignored by default according to the jail manual. If you explicitly set rotated-journal processing on, confirm that the additional files are required and that file-descriptor and replay costs are acceptable. A large journal on disk does not prove that Fail2ban is leaking memory, but it is a reason to inspect the backend’s scope and startup behavior.
Vacuum journal storage with the right expectation
sudo journalctl --vacuum-size=1G
sudo journalctl --vacuum-time=14d
Use one policy that fits your audit requirements; the commands above are examples of the documented operations. Vacuuming reduces stored journal files on disk. It does not guarantee an immediate reduction in Fail2ban’s resident memory, because the process may still hold parsed state or may need to be restarted after configuration changes.
File backends and rotated logs
For file-based jails, inspect the paths in logpath, rotation policy, permissions, and whether a filter is matching an unexpectedly general pattern. Validate a filter against a representative log with:
sudo fail2ban-regex /path/to/logfile /etc/fail2ban/filter.d/FILTER_NAME.conf
Use a bounded sample when testing a very large file. A filter that matches routine success messages or a reverse proxy’s combined log can create far more events than the attack itself.
Verify the firewall action and the actual traffic path
A “banned” result in Fail2ban means the action was requested. It does not, by itself, prove that packets hit the intended rule.
Inspect rule ordering and action compatibility
Look for the Fail2ban chain, jump order, counters, and set membership. An allow rule placed before the Fail2ban jump can bypass the ban. An action designed for iptables may not control a host whose effective rules are nftables-managed, and a firewalld-managed system may require the action that integrates with that service. Resolve conflicts by selecting the netfilter action appropriate to the host and placing the deny path where the packet actually traverses it.
Docker and forwarded traffic
For services published from Docker containers, inbound packets commonly traverse the FORWARD path rather than the host’s INPUT chain. The Fail2ban troubleshooting guidance states that Docker uses the FORWARD chain to send traffic to containers, so INPUT rules can have no effect for that traffic. Inspect the DOCKER-USER chain and the surrounding forwarding rules, then choose an action that inserts the ban where forwarded traffic is evaluated.
sudo iptables -L DOCKER-USER -n -v
sudo iptables -L FORWARD -n -v
sudo nft list ruleset
Reverse proxies and load balancers create a similar issue: the application log may contain a client address while the kernel sees the proxy’s address. Confirm that the filter is extracting the real client address safely and that the firewall rule is applied on the host that receives the hostile connection.
Test enforcement without locking yourself out
Use a controlled test address from a separate administration path. Trigger a test match only in a maintenance window, check the jail’s banned count, inspect the firewall counter or set, and verify that the expected connection is blocked. Keep an out-of-band console and an allow rule for your administration source. Never test by banning the only address from which you can recover the server.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Reload or restart with a recovery plan
Make one reversible change at a time and capture status before and after it. A reload is preferable when the installed version and changed settings support it:
sudo fail2ban-client reload
sudo fail2ban-client status
You can also use the service manager’s reload operation when supported by the unit. Confirm the result in journalctl -ru fail2ban; a command returning successfully does not prove that every jail or action loaded as intended.
The project documentation warns that a restart can unban addresses and then ban them again. Plan for a brief enforcement gap, a burst of new firewall operations, and possible memory growth while the logs are replayed. Before restarting:
- Keep a root shell or console session open.
- Record current bans and the firewall state.
- Confirm that your management address is allowed by an independent recovery rule.
- Schedule the operation when a short interruption is acceptable.
- Watch the service journal, process RSS, ban counts, and firewall counters during startup.
Common symptom-to-fix paths
RSS is high and the active ban count is enormous
First reduce the source of accumulation: remove accidental permanent bans, shorten an excessive bantime, narrow the jail’s log scope, and disable duplicate jails. Clear old bans in a controlled way, then monitor whether RSS falls or merely stops increasing. If the firewall also contains an enormous rule list, migrate to the supported set-based action for the host rather than continuing to append individual rules.
RSS is high but only a few addresses are banned
Inspect the SQLite file, total match volume, filter behavior, and startup logs. A broad filter, repeated database errors, or journal replay can consume resources without leaving a large current ban list. Check whether a recidive jail or historical retention is storing substantially more state than the ordinary jail.
Memory spikes whenever the service starts
Compare the startup timestamp with journal replay and rotated-log settings. Verify the systemd match and test the filter on a limited time range. If startup consistently reads an unexpectedly large history, reduce the backend scope and apply an appropriate journal retention policy before restarting again.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsTraffic continues even though Fail2ban says the address is banned
Inspect the action’s actual chain or nftables set, rule counters, and ordering. For containers, follow the packet through FORWARD and DOCKER-USER instead of checking only INPUT. For a reverse proxy, verify which host sees the connection and which address the filter extracts. A ban record without a matching packet-path rule is an enforcement configuration problem, not evidence that increasing Fail2ban memory will help.
Memory falls after restart but rises again
A restart can temporarily discard working state, so the pattern does not prove a leak. Compare the growth rate with ban count, match count, database size, and journal replay. If the same configuration reproduces unbounded growth at a stable workload, record the Fail2ban version, backend, action, jail count, and a minimal configuration for a version-specific bug investigation.
Design a sustainable configuration after the incident
| Design choice | Benefit | Trade-off to monitor |
|---|---|---|
Short finite ordinary bantime |
Caps active-ban retention | Attackers can return sooner |
| Separate recidive policy | Longer response for repeat offenders without making every ban permanent | Additional match and ban state |
Narrow findtime and precise filters |
Less replay and fewer false matches | Slow, distributed attacks may be harder to catch |
| Finite database purge age | Bounds historical state and disk use | Older forensic detail is removed |
| Systemd backend with explicit service matching | Avoids scanning unrelated journal entries | Requires correct unit and journal fields |
| Firewall-native sets or an appropriate action | Scales better than an unbounded individual-rule list | Backend compatibility and rule-order testing are required |
Monitor at least process RSS, total memory, current and total bans per jail, database file size, journal disk usage, and firewall set or rule counts. Alert on sustained growth rather than a single post-attack peak. Keep configuration changes in version control, document why each jail exists, and review whether an upstream rate limit, reverse proxy, or provider-level control should absorb volumetric abuse before it reaches a host-level log watcher.
A practical incident runbook
- Attribute: record Fail2ban RSS, host memory, per-jail status, database size, service logs, journal usage, and firewall objects.
- Find the multiplier: identify excessive current bans, permanent or recidive policies, duplicate jails, broad filters, or journal replay.
- Confirm enforcement: inspect the action’s chain or set and follow the packet path, including FORWARD and DOCKER-USER for containers.
- Make one bounded change: adjust retention, narrow a filter or backend, remove duplication, or correct the action.
- Clear only what is necessary: unban selected addresses first; reset the database only after backing it up and stopping the service.
- Reload and validate: prefer reload where supported, and verify status, logs, RSS, ban counts, and firewall counters.
- Restart only deliberately: account for the documented unban-and-reban behavior and maintain an emergency access path.
- Observe the trend: continue sampling until memory and state remain bounded under normal traffic.
The key decision is not whether Fail2ban ever used a large amount of RAM; it is whether the retained state, input stream, and firewall implementation are bounded and whether a reported ban reaches the packets you intend to block.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
