Firewall / iptables are incorrect, again

FreePBX Security
1

I reported this problem a few weeks ago here hackers

I reordered the iptables rules and tested, it was blocking correctly. I thought i was done with it.

Checked the logs again today, hackers are back at it. I checked iptables, and sure enough the rules are out of order AGAIN, all by themselves.

There is definately a bug here.

Chain INPUT (policy ACCEPT)
target prot opt source destination
fpbxfirewall all – 0.0.0.0/0 0.0.0.0/0
fail2ban-SIP all – 0.0.0.0/0 0.0.0.0/0 <-- wrong

fail2ban-SIP should be first in the list.
If I move it to first, it stays there a few days? Then it moves again and hackers flood back in.

Am I the only person this is happening to?

2

Confirmed bug.
I just went to firewall settings, clicked SUBMIT.
Then applied changes.

Checked iptables and they are scrambled again.

3

Might want to mention your FPBX version…
Verified don’t see this issue on my FPBX boxes, was this occurring before your hacker incident?

4

Freepbx version is 15.0.17.38.
There is no hacker “incident”. I’m saying that the iptables rules are not blocking people from attempting rogue connections to my server.

The source of the iptables misconfiguration is confirmed to be the Freepbx dashboard. Submitting a change causes the rules to be messed up.

5

There was an open JIRA for this here:
https://issues.freepbx.org/browse/FREEPBX-22543

I pushed a patch for this that was accepted, and firewall v15.0.11 has many fixes including one for this.

1 Like
6

Isn’t this the way Responsive Firewall works?

List out the fpbxfirewall chain.

7

As @dicko correctly pointed out, the order of the rules is wrong.
The fail2ban-SIP rule is never executed because the first rule does an ACCEPT.

8

No… it’s not wrong. List out the chain.

When you see the name of a chain it does not mean that there is an overall ACCEPT. It means that the rules of that chain are executed. At the end of the chain there should be a RETURN rule that comes back and causes the next chain of rules to be executed. This way you build up a chain of chains until you get to the very end of INPUT and execute the default action.

9

@billsimon - It seems that the initial way RFW worked was to be in front of Fail2Ban (RFW is NOT fail2ban, it’s xt_recent), there are actually a bunch of places within the code of RFW that prove that. So theoretically, you’re right that it was designed to work this way, but this was a bad idea.

This only really came to light once there was more work at including Intrusion Prevention (which uses fail2ban) as part of Firewall instead of Sysadmin.

@Basildane - Try the newest patch of firewall:
fwconsole ma downloadinstall http://mirror1.freepbx.org/modules/packages/firewall/firewall-15.0.11.tgz fwconsole chown fwconsole r

10

If its not wrong, then why are hackers freely playing in my system even though their IP’s were banned 24 hours ago?
And when I reordered the input chain, they immediately dropped.

Chain INPUT (policy ACCEPT)
target prot opt source destination
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

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain fail2ban-SIP (1 references)
target prot opt source destination
REJECT all – 89.163.146.164 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all – 146.0.74.108 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all – 0.0.0.0/0 0.0.0.0/0

Chain fpbx-rtp (1 references)
target prot opt source destination
ACCEPT udp – 0.0.0.0/0 0.0.0.0/0 udp dpts:10010:10200
ACCEPT udp – 0.0.0.0/0 0.0.0.0/0 udp dpts:4000:4999

Chain fpbxattacker (6 references)
target prot opt source destination
all – 0.0.0.0/0 0.0.0.0/0 recent: SET name: ATTACKER side: source mask: 255.255.255.255
DROP all – 0.0.0.0/0 0.0.0.0/0

Chain fpbxblacklist (1 references)
target prot opt source destination
REJECT all – 163.0.0.0/8 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all – 23.0.0.0/8 0.0.0.0/0 reject-with icmp-port-unreachable

Chain fpbxchecktempwhitelist (1 references)
target prot opt source destination
fpbxtempwhitelist all – 0.0.0.0/0 0.0.0.0/0 ! recent: CHECK name: REPEAT side: source mask: 255.255.255.255

Chain fpbxfirewall (1 references)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 connmark match ! 0x20 state RELATED,ESTABLISHED
ACCEPT icmp – 0.0.0.0/0 0.0.0.0/0
ACCEPT all – 0.0.0.0/0 255.255.255.255
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 PKTTYPE = multicast
ACCEPT udp – 0.0.0.0/0 0.0.0.0/0 udp spts:67:68 dpts:67:68
fpbx-rtp all – 0.0.0.0/0 0.0.0.0/0
fpbxblacklist all – 0.0.0.0/0 0.0.0.0/0
fpbxsignalling all – 0.0.0.0/0 0.0.0.0/0
fpbxsmarthosts all – 0.0.0.0/0 0.0.0.0/0
fpbxregistrations all – 0.0.0.0/0 0.0.0.0/0
fpbxnets all – 0.0.0.0/0 0.0.0.0/0
fpbxhosts all – 0.0.0.0/0 0.0.0.0/0
fpbxinterfaces all – 0.0.0.0/0 0.0.0.0/0
fpbxreject all – 0.0.0.0/0 0.0.0.0/0
fpbxrfw all – 0.0.0.0/0 0.0.0.0/0 mark match 0x2/0x2
ACCEPT udp – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
lefilter tcp – 0.0.0.0/0 0.0.0.0/0 match-set lefilter dst
fpbxlogdrop all – 0.0.0.0/0 0.0.0.0/0

11

I see, thanks for your contributions!

1 Like
12

I wonder if there isn’t another rule wrong, perhaps a command to completely rebuild the iptables tree would be the next step.

13

Thanks, I will do this. I cannot right this second as it is in critical use right now.

14

It will not bring down anything in your system, it will just fix the firewall.
No need to keep harping on this issue - it’s a confirmed bug and has been fixed.

2 Likes
15

I responded to several questions and supplied the information requested. I didn’t realize I was harping.

1 Like
16

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