Problem with ufwban

[musklor]

Hi, I can't use fail2ban anymore.

Ufw is activated
Modsecurity is activated
I've clean files and made a clean install but always the same issue.
Datadir : external hdd

Ncp-panel :

[ fail2ban ]
System config value loglevel set to string 2
System config value log_type set to string file
Job for fail2ban.service failed because the control process exited with error code.
See "systemctl status fail2ban.service" and "journalctl -xe" for details.
fail2ban enabled

Journal :

Unit fail2ban.service has begun starting up. May 30 15:03:34 nextcloudpi kernel: [UFW BLOCK] IN=eth0 OUT= MAC=01:00:ad SRMay 30 15:03:40 nextcloudpi kernel: [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e: SRMay 30 15:03:44 nextcloudpi fail2ban-client[24290]: WARNING Wrong value for 'dbpurgeage' in 'Definition'. Using default one: '86400' May 30 15:03:44 nextcloudpi fail2ban-client[24290]: WARNING 'backend' not defined in 'ssh'. Using default one: 'auto' May 30 15:03:44 nextcloudpi fail2ban-client[24290]: WARNING 'backend' not defined in 'nextcloud'. Using default one: 'auto' May 30 15:03:44 nextcloudpi fail2ban-client[24290]: ERROR Found no accessible config files for 'filter.d/ufwban' under /etc/fail2ban May 30 15:03:44 nextcloudpi fail2ban-client[24290]: ERROR No section: 'Definition' May 30 15:03:44 nextcloudpi fail2ban-client[24290]: ERROR Unable to read the filter May 30 15:03:44 nextcloudpi fail2ban-client[24290]: ERROR Errors in jail 'ufwban'. Skipping... May 30 15:03:44 nextcloudpi fail2ban-client[24290]: WARNING 'filter' not defined in 'sshd'. Using default one: '' May 30 15:03:44 nextcloudpi fail2ban-client[24290]: WARNING No filter set for jail sshd May 30 15:03:44 nextcloudpi fail2ban-client[24290]: WARNING 'backend' not defined in 'sshd'. Using default one: 'auto' May 30 15:03:44 nextcloudpi fail2ban-client[24290]: WARNING 'filter' not defined in 'sshd'. Using default one: '' May 30 15:03:44 nextcloudpi fail2ban-client[24290]: ERROR Failed during configuration: Bad value substitution: option 'action' in section 'sshd'May 30 15:03:44 nextcloudpi systemd[1]: fail2ban.service: Control process exited, code=exited status=255 May 30 15:03:44 nextcloudpi systemd[1]: Failed to start Fail2Ban Service. -- Subject: Unit fail2ban.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit fail2ban.service has failed. -- -- The result is failed. May 30 15:03:44 nextcloudpi systemd[1]: fail2ban.service: Unit entered failed state. May 30 15:03:44 nextcloudpi systemd[1]: fail2ban.service: Failed with result 'exit-code'

[nachoparker]

Thanks for reporting. Looks like the new jail is having issues

[musklor]

First test : nextcloudpi raspberry image
Second test : raspbian lite and install script

[nachoparker]

Please, run the update to v1.12.10 and let us know if that fixes the issue

[nachoparker]

We'll reopen if this isn't fixed yet

[musklor]

Fixed. Thanks.

[dhiltonp]

I had the same issue on v1.13.6, running on an HC1.

/var/log/syslog shows attempts to restart fail2ban every 10 seconds or so.

`/etc/fail2ban/filter.d/ufwban.conf didn't exist, so I created it based on #704.

After that, fail2ban continued to fail reporting that /var/log/ufw.log didn't exist. I discovered that UFW wasn't enabled.

If fail2ban relies on ufw being active, maybe the wizard should install ufw by default, too?

[nachoparker]

@dhiltonp thanks for reporting. It shouldn't require UFW. If that's the case I'll revert the changes.

Did you find a way of making fail2ban just ignore the rule if the log doesn't exist?

[dhiltonp]

It seems that fail2ban jails must be enabled = true or false, not dependent on another file.

Adding a little code to fail2ban.sh to make that dynamic could work.

UFW could call fail2ban.sh if fail2ban is installed. fail2ban.sh would rebuild the jail.conf with a dynamic enable, based on whether or not UFW is installed...

[nachoparker]

Could use is_active_app UFW to detect this. Feeling brave to send a PR?

[dhiltonp]

Sure. Is there a corresponding 'uninstall UFW' script?

[nachoparker]

no uninstall, but it can be disabled

[dhiltonp]

That PR only enables [ufwban] if both packages are present, which is great.

It is not robust against UFW being removed or disabled afterwards, though.

I guess we could modify /etc/init.d/fail2ban, touching /var/log/ufw.log in addition to /var/log/fail2ban.log in do_start.

It would just be a sed command in our fail2ban.sh. If so, the other PR wouldn't be needed.

[nachoparker]

touching the file sounds better, yes

[dhiltonp]

See #937 for that patch.

The potential downside is if the fail2ban package is upgraded, it likely will replace the init script.

[Haraade]

Filter for ufwban should be:
failregex = UFW BLOCK.* SRC=< HOST >

HOST and <> must be complex. It will not appear on this website!

If not, you get this error message:

ERROR No 'host' group in 'UFW BLOCK.* SRC='
WARNING Command ['set', 'ufwban', 'addfailregex', 'UFW BLOCK.* SRC='] has failed. Received RegexException("No 'host' group in 'UFW BLOCK.* SRC='",)