How to not unban everyone when the service stops

[Foxite]

Currently, when I stop fail2ban, it removes all bans from the firewall, and reinstates them when the service is started again.

Given the amount of bans I have on my server (as all IPs are permanently banned after a single failure, because I'm the only user and I have no chill), it takes about a minute to restart the service. Additionally, I'm concerned that the speed at which it sends notifications for every reinstated ban (which is done via Discord) might get me in trouble for violating the rate limit.

Is there any way to avoid this behaviour? And what is the reason for it?

[sebres]

Is there any way to avoid this behaviour?

As for unban by stop - no, there is no such possibility (excepting the command actionflush, which doing a "bulk" unban if defined in action). If you don't need an unban on stop for some of your custom actions, just define actionflush = true in such an action and fail2ban will stop execution of actionunban for this action.
As for (re)ban by start - at the moment there is no bulk ban (I have only experimental branch inmplemented such thing for several banning actions, work still in progress). Another possibility basically introduced for non-banning actions (like mailing actions) is norestored option, which can avoid repeated notification by restart (see #1669).

Anyway the functionality for reban of active tickets by restart is intended and cannot be avoided at the moment.
But if you need to reload configuration (new or modifying regex, new jail etc pp), you can use fail2ban-client reload instead.

And what is the reason for it?

Well, fail2ban has every ban under its own control and there is no direct back relation between actions and banned tickets, so if it gets stopped it must unban every ticket, to be able to ban it hereafter properly (without possible conflicts in some chains of action) as well as to leave safe state (everything made from fail2ban is reversed after stop).

Also note that fail2ban cannot predict the reason of the stop:

• user want to reban everything (e. g. iptables gets flushed by some other service, for instance iptables-restore or is in an unusable state due to some error of fail2ban, net-filter subsystem or some program manipulating on same subsystem chains);
• user want to reban everything using another banning action (switch from iptables to ipset or nftables, etc);
• user made some another fundamental changes in configuration, so after restart the bans are not the same (e. g. defined different target chain etc);
• user don't want to use fail2ban anymore;

Theoretically we can provide some option for stop signaling an intention to leave the bans by stop, but to make a proper (re)start hereafter fail2ban need some feedback functionality from banning action (e. g. list of currently banned tokens) or a silent ignore for restore tickets, so the banning action can be reimplemented properly to consider such a restart.

But I would prefer to fulfill the bulk ban solution instead.

[sebres]

I tried both commands with the same result (altered config was not reloaded or applied)

What exactly was changed in config? Do you see something in fail2ban.log?

[OpenNya]

What exactly was changed in config?

Indeed there were 2 issues i ran into while trying force fail2ban to work on freshly installed Ubuntu 20.04 LTS server.

I was using a very simple Fail2Ban configuration for years on all my Ubuntu 18.04 server installations.
My installation steps were as follows:

1. Make a fresh install of Ubuntu 20.04 LTS server on a KVM VPS (Vultr, DO)
2. Install and configure UFW (basic config - only ssh allowed with PKI auth)
3. sudo apt update && apt upgrade -y
4. sudo reboot
5. sudo apt install fail2ban -y
6. Start and enable fail2ban service:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

7. Create a local config file:
   sudo nano /etc/fail2ban/jail.local

[DEFAULT]
# Instruct Fail2Ban to use UFW rather than Iptables to modify my firewall
banaction = ufw
banaction_allports = ufw

# List of IPs not to ban
ignoreip = 127.0.0.1/8 ::1/128 10.x.x.x 172.y.y.y 192.z.z.z etc.

[sshd]
enabled = true
maxretry = 2
findtime = 2h
bantime = 1d

9. Apply new configuration
   sudo systemctl reload fail2ban

The first issue I ran into was absolutely identical to the issue described at ServerFault:
https://serverfault.com/questions/1032942/fail2ban-not-banning-ips-on-ubuntu-20-04

In a couple of days after fail2ban installation and configuration I have checked service status via
sudo systemctl status fail2ban
I was very surprised because I saw 'zero' statistics - failed statistics was equal to zeroe, banned statiscics was equal to zero too.
To resolve the issue I have tried to reload config via service reload command and 'fail2ban-client reload' also.
But without any success - statistics staid at zero values.

Then I applied suggestion from ServerFault to change backend to 'systemd'

[sshd]
backend = systemd
sshd_backend = systemd

After reloading config, it seems that fail2ban has began to parse log files!!!
Just in 5-10 minutes I saw many failed IPs in the statistics.

Trying to figure out the cause of the issue I have compared backend used in 18.04 with backend used in 20.04.
cat /var/log/fail2ban.log | grep back
I got the following results:

// On Ubuntu 18.04
Initiated 'polling' backend
// On Ubuntu 20.04
Initiated 'pyinotify' backend

The newer version has switched to 'pyinotify' as a default backend.
Something prevents 'pyinotify' to process log files in the case of a fresh installation from scratch.

The next issue I ran into was the fail2ban inability to ban any failed IP.

Statistics shows me many failed IPs but when I check the list of banned IPS via:
sudo ufw status verbose
I saw that no IP block rules were added to UFW.
Output from 'ufw status numbered' shows only my SSH allow rules and NO IP deny rules added by fail2ban.
That was really strange.

I tried to reload config again but without any positive results - fail2ban was not adding any IP blocking rules to UFW.

And as I wrote yesterday the only solution I found that makes fail2ban to work was to stop and to start service:

sudo systemctl stop fail2ban
sudo systemctl start fail2ban

After restarting the service fail2ban started to add IPs to UFW!

Also I have found that after service restart the 'pyinotify' backend also started to work as it should.
I have removed 'backend = systemd' setting from config reverting it to default log processing engine.

[sebres]

Fail2ban distinguishes restart and reload.
No idea about backend switch (as for reload) at the moment, I've to check that... But switch of the action definitely expects a restart of jail (so fail2ban-client restart instead of fail2ban-client reload).
May be we've to extend fail2ban to use restart by reload (for certain cases) or to throw an error (like restart needed if reload is called).

[OpenNya]

But switch of the action definitely expects a restart of jail

I am complaining because in ver 0.10.x on Ubuntu 18.04 altered config loads flawlessly using RELOAD command.
Or maybe that was a bug in 0.10.x to do more on reload? ;)

[sebres]

(No idea what systemctl reload fail2ban doing internally in your distribution, this is basically matter of maintainer, but...) I guess systemctl reload fail2ban simply did a fail2ban-client restart previously.
BTW, I don't know any difference in reload/restart handling of fail2ban-client/-server between 0.10 and 0.11. Both are fully identical as regards the restart/reload process.

[brianjmurrell]

@Foxite What is your specific use-case?

I have a use-case that seems to have similar, if not identical requirements as you describe. Specifically my use-case is restarting fail2ban after upgrading it. This is such a case where the state after a start should be the same as it was before the stop.

I wonder if this is a use-case that fail2ban ought to handle specifically by, perhaps re-execing itself so that it's running the new code, without unbanning and rebanning. This re-execing, I think can even preserve file-descriptors and such so that re-scanning of sources isn't necessary either. Maybe preserving FDs is not something that can be done in Python. I don't know.

Why do I care if an upgrade/restart unbans and then re-bans? Because my unban/ban process is much more expensive than a local ipset/ipchains transaction. It involves a remote procedure execution that has high overhead. Ultimately running all of these RPCs to unban and then ban just to recreate the existing state is unnecessary and silly as the state through the restart should be the same.