Firewall version 15.0.13 appears to break custom rules

firewall
Tags: #<Tag:0x00007fb483f78b60>

(Nate) #1

Hello,

Just updated a couple servers to firewall v 15.0.13 this morning and it seems to object to custom rules being loaded at the top of the INPUT chain:

1626357268: There is an invading rule above us: -s 192.159.66.96/27 -j ACCEPT
1626357268: Resetting iptables

The rules are then reloaded without the custom rules in place.

Rolling back to firewall 15.0.8.14 and restarting the firewall has resolved it for now. I will gather some info and create a Jira ticket shortly.

EDIT: Issue created: https://issues.freepbx.org/browse/FREEPBX-22653

Nate


(Jared Busch) #2

I have not updated this yet.
Let me see what happens. This is my normal rules flow on firewall 15.0.8.14

[jbusch@pbx ~]$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-recidive  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-zulu  tcp  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-BadBots  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-FTP  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 21
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     udp  --  52.14.37.123         0.0.0.0/0            udp dpt:161 /* Skyetel SNMP */
fpbxfirewall  all  --  0.0.0.0/0            0.0.0.0/0           

Upgraded to firewall 15.0.13 and now I see this

[jbusch@pbx ~]$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  52.14.37.123         0.0.0.0/0            udp dpt:161 /* Skyetel SNMP */
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-FTP  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 21
fail2ban-BadBots  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-zulu  tcp  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-api  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-recidive  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fpbxfirewall  all  --  0.0.0.0/0            0.0.0.0/0           

The Skyetel rule is a custom rule in the GUI



(Jared Busch) #3

And can confirm things are broke.

@jerrm I made a change on the networks tab.

Now iptables looks like this.

  1. my custom rule is gone.
  2. hello replication…
[jbusch@pbx ~]$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-recidive  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-api  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-zulu  tcp  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-BadBots  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-FTP  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 21
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-recidive  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-api  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-zulu  tcp  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-BadBots  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-FTP  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 21
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fpbxfirewall  all  --  0.0.0.0/0            0.0.0.0/0           

One sudo fwconsole restart later …

[jbusch@pbx ~]$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  52.14.37.123         0.0.0.0/0            udp dpt:161 /* Skyetel SNMP */
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-FTP  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 21
fail2ban-BadBots  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-zulu  tcp  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-api  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-recidive  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-PBX-GUI  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22
fail2ban-apache-auth  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-FTP  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 21
fail2ban-BadBots  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-zulu  tcp  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-api  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-recidive  all  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-SIP  all  --  0.0.0.0/0            0.0.0.0/0           
fpbxfirewall  all  --  0.0.0.0/0            0.0.0.0/0           


(Nate) #4

It looks like a recent update to drivers/Iptables.class.php in the firewall module added some check to ensure that rules created by the firewall module (containing either ‘fpbxfirewall’ or ‘fail2ban’) are at the top of the INPUT chain and this seems to be causing the issue.

This where it was added - starts around #1557 but that function has had some updates prior to 15.0.13.


(Yois) #5

@ngingras - This is my fault, I wrote that change. I updated the JIRA that I’ll try to think of a better way to do this. If you look at older versions of the code, the process of ensuring that we’re “on the top” was listed as a TODO, and it didn’t occur to me that there was a reason this wasn’t done.

@sorvani - the duplication issue was known to me but was supposed to be resolved by flushing iptables. I will take another look.


(Jared Busch) #6

the GUI custom rules also being wiped is an issue since it does get applied with a firewall restart.


#7

I think @yois was the one working on the fail2ban stuff.

I’ve never been a fan of how the module handles fail2ban or restarts in general. I think anything with the current basic structure will be problematic. I don’t use the module myself, I don’t think I’ve done much with it outside the LE related fixes.

INPUT should be three or so static, NEVER changing rules. F2B should be in it’s own chain, custom rules should be in their own chain, the restart unload/reload code has always been bonkers, the call to F2B is likely better placed within the fpbxfirewall chain, we should have a much more current F2B version, I could go on…


(Yois) #8

100% but changes we’re making can’t break things either.


#9

v16 is arguably the place to make more substantial forward only changes.

Even with the current sng-7 based v16 releases, a decision could be made to go ahead and upgrade custom sangoma rpms like the distro’s f2b to the stock RHEL8 version, instead of the ancient version they have, which is older than the stock RHEL7 version. My guess is the current version comes from (or pre-dates) when the distro was centos6 based and they wanted to keep things consistent across FreePBX versions.


(Yois) #10

Pull Request #126: FREEPBX-22653 Firewall custom rules detection - FreePBX GIT


(Simon Telephonics) #11

It turns out that the firewall module takes away custom iptables rules even when it is disabled.

fwconsole firewall disable
fwconsole reload

then,

# iptables -I INPUT -m udp -p udp --dport 69 -j DROP
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       udp  --  anywhere             anywhere             udp dpt:tftp
fail2ban-recidive  all  --  anywhere             anywhere            
...

there’s my custom drop rule at the top of INPUT chain.

About 5 minutes pass, then,

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-recidive  all  --  anywhere             anywhere            
...

It’s gone!

What’s killing the firewall rule with the firewall disabled and no further intervention from me?


(Yois) #12

EDIT: I reread your post and this reply isn’t relevant, but I’m leaving it anyway for posterity

Read the code… I added a check to ensure rogue services wouldn’t break the firewall… I didn’t consider custom rules when writing that check. The PR above will allow rules above fpbxfirewall chain that don’t contain “fail2ban” when custom rules are enabled.


#13

I have always preferred the ‘restrictive’ approach to fire-walling

Chain INPUT (policy DROP)
.
.
.
(static  rules)
.
.
(dynamic rules starting   fail2ban at the end)
.
.
.

That way you can start or stop or otherwise use the fail2ban-client as needed