FreePBX 17 - Fail to Ban not starting after updates

Beta Program Issues
1

When I installed the FreePBX 17 Beta, fail2ban was started without issues. I have been keeping up on all updates and noticed after the last round of updates fail2ban is not starting. IE:

systemctl -l status fail2ban

× fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Wed 2024-06-05 16:23:11 UTC; 48s ago
Duration: 56ms
Docs: man:fail2ban(1)
Process: 7040 ExecStart=/usr/bin/fail2ban-server -xf start (code=exited, status=255/EXCEPTION)
Main PID: 7040 (code=exited, status=255/EXCEPTION)
CPU: 49ms

Jun 05 16:23:11 FreePBXDebian systemd[1]: Started fail2ban.service - Fail2Ban Service.
Jun 05 16:23:11 FreePBXDebian fail2ban-server[7040]: 2024-06-05 16:23:11,741 fail2ban.configreader [7040]: WARNING ‘allowipv6’ not defined in ‘Definition’. Using default one: ‘auto’
Jun 05 16:23:11 FreePBXDebian fail2ban-server[7040]: 2024-06-05 16:23:11,751 fail2ban [7040]: ERROR Failed during configuration: Have not found any log file for ssh-iptables jail
Jun 05 16:23:11 FreePBXDebian fail2ban-server[7040]: 2024-06-05 16:23:11,756 fail2ban [7040]: ERROR Async configuration of server failed
Jun 05 16:23:11 FreePBXDebian systemd[1]: fail2ban.service: Main process exited, code=exited, status=255/EXCEPTION
Jun 05 16:23:11 FreePBXDebian systemd[1]: fail2ban.service: Failed with result ‘exit-code’.
Jun 05 16:23:11 FreePBXDebian systemd[1]: fail2ban.service: Failed with result ‘exit-code’.

Is anyone else having this issue after the last round of updates?

2

found this so far:

3

Okay yep, I fixed it with that post. Others may want to know about that. Seems to be a specific Maintainer issue with Debian 12 and fail2ban. I imagine fail2ban was updated, and for some reason that was removed. Specifically, I did this:

It looks to me like a pretty maintainer issue. @fail2ban/maintainers, @sylvestre Any idea?

From other point of view it is a configuration issue and can be surely simply fixed using:

  • echo -e “[sshd]\nenabled=true” | sudo tee /etc/fail2ban/jail.local
  • echo -e “[sshd]\nbackend=systemd\nenabled=true” | sudo tee /etc/fail2ban/jail.local

In other words:

$ sudo cat /etc/fail2ban/jail.local
[sshd]

  • backend=systemd
    enabled = true

I corrected this, and now intrusion detection is started. Adding to my testing notes.

4

Nope, the problem is back; it looks like something is re-writing the file, probably by design Does anyone know how I can permanently write this?

5

make it ‘immutable’ after it works
But, if you only allow key logins ,and perhaps change port from 22 you wouldn’t need that jail in the first place

6

Hi Dicko, when you say,“Key Logins,” do you mean only certain people log into the interface? Was I supposed to do some extended Debian configuration for fail2ban? You mention port 22. I don’t want to make it immutable if the sysadmin module needs to rewrite the file for some purpose. I don’t know what I’ve done wrong for the file not to be written correctly and start. This line edition seems to be a suggestion from the post. That does indeed allow fail2ban to start, but as soon as the file is rewritten, it is rewritten buy the sysadmin module without:
backend=systemd

Have I done something wrong to need the addition of:
backend=systemd

Pretty much I just used the FreePBX 17 Beta install script. Loaded my backup config. fail2ban was working for 2 weeks. I did a series of updates, just the standard Debian and FreePBX updates, and now fail2ban requires this line to start…I believe I need some context for the refernce to port 22 (ssh). I could change the ssh port yes…would that solve my issues? Change the default SSH. How would system admin module know to not include that jail?

7

After adding ‘authorized keys’ for trusted users (man ssh-copy-id) disable password logins in /etc/ssh/sshd_config.

BUT

enabled=true
is probably NOT what you want

# "enabled" enables the jails.                                                                                            
#  By default all jails are disabled, and it should stay this way.                                                        
#  Enable only relevant to your setup jails in your .local or jail.d/*.conf                                               
#                                                                                                                         
# true:  jail will be enabled and log files will get monitored for changes                                                
# false: jail is not enabled                                                                                              
enabled = false
8

I understand from a security perspective the default is probably to be avoided, but I don’t let anyone SSH through my edge firewall; yes, someone on the local network could probably cause some havoc. Agreed on that. But I guess I’m still at a loss. The defaults with Fail2Ban work on all my other CentOS installs and did with the initial install of FreePBX beta. I don’t understand what has gone wrong after the updates, for it did not start with SSH being on port 22. Even though I’ve been using Linux for a while now, apparently, I’m not as up to speed as you, and I probably don’t understand how the Sysmodule and fail2ban are related to cause this. Thanks for your patience in advance.

9

As I just said, if you have

enabled=true

in jail.conf but don’t have

enabled=false

in every jail that you don’t want to start, in your case including sshd, then you might well experience ‘strangeness-es’ .

I have used every fail2ban version on every debian since 5, I have used pyinotify and systemd if available as back-ends, the unmodified default fail2ban (from fail2ban.org) have always started and behaved as expected.

IMHO firewalling 22 is pretty lame, authed keys work well unless you have a rogue MITM identity stealing them

10

I understand what you are saying. However, besides making it immutable, is there any permanent way to have the system admin module rewrite jail.local since it seems to want to? Do you make yours immutable? (I have never had to) I also still don’t understand why I didn’t need this before the updates, but I do now. I think what you are saying is you make yours immutable and customize it how you want. You’ve done that for a while on Debian? (I know you’ve been using the Vanialla Debian version for quite sometime)

11

I’ve made it immutable for now. I still don’t understand why I need these changes to jail.local after the updates. Even with the defaults before the updates the way the SysAdmin module rewrote the jail.local file worked until this last round of updates.

12

I don’t need to make it immutable, In my case I don’t use system admin It was never available on debian so was never missed also I believe it is obfuscated so not open to review or modification.

13

Gotcha. That makes more sense too. Not too big of a deal anyways just not something I had to deal with before. Jails should stay the same for the most part, with Intrusion detection. So I can make it immutable, back it up, and restore it if needed on updates.

14

Okay, I will preface this: “I used the install script For FreePBX 17 Beta.” I looked at the logs because some things were still bothering me. Fail2ban was not starting with that one change, I thought. I noticed it was starting only when I had SSH as a jail (from that forum’s post). So I let the System Admin module rebuild the jail.local file. I then ran:

systemctl start fail2ban
journalctl -xe

I noticed that many of the jails were looking for log files for the jails in fail2ban. I created the log files; now everything starts as it should. Did the install script miss something, I don’t know…I know it’s working now, even when the Sysadmin module re-creates or re-writes the jail.local file.

15

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.