Firewall: Custom Rules and Fail2Ban

[yois]

There is currently a JIRA open:
[FREEPBX-22682] Firewall vrtsopm 15.0.8.14 and after foesd not process Advanced Custom Rules properly - Sangoma Issue Tracker
that is addressing a known issue with 15.0.13 and higher.

In that ticket, we are discussing the fact that fail2ban supersedes custom rules whenever the former is restarted. I don’t know how this used to work in the past (fail2ban wasn’t working for a while anyway). Did custom rules stay above fail2ban in the INPUT chain of iptables? Does it make a difference to those of you using custom rules? Keep in mind that as long as a packet doesn’t reach the underlying service, fail2ban won’t be triggered since it doesn’t end up in the logs.

I’m asking because I’m writing a patch, and I don’t think it’s possible to put rules above fail2ban and have them stay there, since Fail2Ban will always INSERT it’s rules into INPUT. especially in Fail2Ban >0.8

Tagging @dicko

[dicko]

I always start f2b after my firewall. Never had a problem with that.

[jerrm]

@yois

I’m asking because I’m writing a patch, and I don’t think it’s possible to put rules above fail2ban and have them stay there

I’ve always thought f2b should be pointed to a custom chain, and then jump to that chain from INPUT (or the fpbxfirewall chain). The call to f2b would then be completely under the firewall module’s control.

v16 would be a good time to consider the change.

[yois]

OK. But without any major code rewrites or design changes, all 3 of us agree that as fail2ban operates now, we can’t reliably modify Custom Rules to take precedence over Fail2Ban rules, correct?

I’m pushing this because I want that JIRA closed… This is operating as designed.

[jerrm]

@yois

we can’t reliably modify Custom Rules to take precedence over Fail2Ban rules, correct?

Agree.

Without mucking with config files, I don’t think there is any way to guarantee knowing when/if f2b might be restarted

Best you could do is hack something with incrond or have the module daemon periodically check for f2b being re-inserted at the top of INPUT. That would still be doing any processing after the fact, and probably not a good use of resources.

[dicko]

The service file that controls my firewall controls fail2ban as follows:-

[Service]                                                                                           
ExecStartPre=/bin/systemctl stop fail2ban                                                           
ExecStartPost=/bin/systemctl start fail2ban                                                         
ExecStopPost=/bin/systemctl stop fail2ban   
.
.
.

that way you have a predictable rule order

(current versions of fail2ban include a systemd service file in the distribution, the fail2ban service is ‘disabled’ in the system)

[yois]

Right. The problem is that here Sysadmin controls Fail2Ban and Firewall module controls IPTables. Like the old saying: There are too many cooks in the kitchen…

This really deserves another thread, but I’d love to get a group of us together to ask that Intrusion Detection be open sourced and merged into the firewall module. It’s silly that fail2ban is being screwed with and none of us know what’s going on under the hood, and when it really belongs as part of a different module called FIREWALL for goodness sake.

[dicko]

Have to agree with that, but would also add that the “Firewall” module depends on the “Sysadmin” module which depends on the “Zend” module , which depends on the “OS” module as yet

[jerrm]

@yois

The problem is that here Sysadmin controls Fail2Ban and Firewall module controls IPTables.

Agree too many cooks. F2B needs to reside 100% one place or the other. In the firewall module makes the most sense.

v16 is the best place to make a structural change. It’s the type of thing that might interest me - If I actually used the firewall. Unfortunately that probably won’t happen unless we get some sort of sanctioned way to run hooks on a non-distro system.