New Firewall features

FreePBX
1

This has been on my (and lots of other peoples!) wishlist for a while, and you’ll all be happy to hear that I finally figured out a way to make Responsive firewall a lot more responsive!

A minor, but niggly, issue has been that it can be a bit too enthusiastic with chatty clients, and preemptively ban then before it’s realised they’re legitimate.

I’ve been mentally throwing around some ideas for a while, but I finally figured it all out over the weekend, and I present to you Firewall 13.0.53.2 (or higher!)

The only thing that may be slightly unexpected is that you really have to click ‘Reload’ after it’s installed. It’ll yell about it if you don’t, and until you do that, you won’t get the monitoring features.

After you’ve done that, you will see a new process:

root      8458  0.3  0.2 417288 21608 ?        S    00:50   0:04 php /usr/src/freepbx/firewall/hooks/voipfirewalld
root      8478  0.0  0.1 417004 10776 ?        S    00:50   0:00 voipfirewalld (Monitor thread)

(If you’re not on 14, you’ll just see two ‘voipfirewalld’ processes, but that is the only difference).

You’ll also see a bunch of new entries in /tmp/firewall.log:

Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.22.152.191 detected
Firewall-Monitoring - Auth failure from 185.40.4.126 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.22.152.68 detected
Firewall-Monitoring - Auth failure from 185.40.4.126 detected

A valid entry looks like this:

Firewall-Monitoring - 10.5.108.76 reported as good, adding to whitelist.
1524541732: /sbin/iptables -w5 -W10000 -A fpbxregistrations -s 10.5.108.76/32 -j fpbxknownreg

The ‘-A’ will happen within 30 seconds of the Monitoring process picking it up.

I’ve tested it, and it’s currently in Edge. I’d love for other people to test, as it’s one of the biggest changes to firewall since it was originally written. Feel free to leave feedback here, or open tickets if you have any issues.

Thanks!

3 Likes
2

Thank you, Rob!

If possible to add the whitelist to be displayed in the GUI. (and what services/ports each IP is using) this will help us keep an better eye on things…
Of course email alerting would also be nice :slight_smile:

Thanks again for your work!

1 Like
3

Hello @xrobau ,
Responsive Firewall is the best Open Source Voip Firewall, integrated into a PBX i have ever seen. Thank you!

I have one thing which the Firewall cannot Handle.

Floating (Failover) IP Adresses do not work out of the Box with Responsive firewall.

Most cloud Providers just route the Failover ip to the customers Server. To use the IP you have to set an ip route

/sbin/ip route change default via IP-DEFAULT-GW dev eth0 src FLOATING-IP

If you have a Warm Spare Setup with 2 VMs which share 1 Floating ip then this does not work with Responsive Firewall.

Responsive Firewall already Masquerades the Default GW IP and so the IP route gets ignored once the Firewall hast started. The Problem then is that you have no sound anymore on Voip Calls.

1 Like
5

That’s not a firewall thing. That’s an Asterisk thing. For those situations, you should be using FreePBX HA, which manages all those sort of things for you.

1 Like
6

The reason why it does not work is because Firewall Masquerades my eth0.

So if i curl checkip.dyndns.org then the Machine uses the original IP for outgoing connections and not the Failover IP. The Destination NAT Route only works with a disabled firewall.

Except this we are happy with a warm spare setup and dont need ha module.

7

Your last firewall update (the one that “prevents infinite loops”) is somehow bugged, and fails at my distro install within 1s to about 10 minutes after yet another restart with a wall message, and as a result, new registrations are not allowed past iptables (and even not allowed to try registering). As a remedy I disabled responsive firewall. Faulty module version 13.0.53.3 (maybe try not to break features? 13.0.49.x works on another freepbx instance without any issues).

8

Did you report an issue on the tracker?

Also @xrobau

9

What does that mean?

There’s a new check in the active monitoring that will just restart the monitoring thread (not the firewall) if something is wrong with its communications with Asterisk. A couple of people have reported it’s a bit TOO sensitive, but that doesn’t effect firewall itself.

Edit: Firewall 13.0.53.4 has the sensitivity turned down. It’s still possible to false trigger, so if you DO see it happen, I’d love to know.

10

Yes, was going to report the issue, but stopped halfway to test whether disabling IPv6 was triggering this, ran out of time and went home. :slight_smile: Still I don’t exactly know what happened with that module, but responsive firewall stopped opening new IPs into iptables’ fpbxregistrations chain, while there were events in firewall stating that “IP is good, allowing” for already registered IPs. Now as the update came, I’m testing it first before reporting the issue.

11

Hmmmmm. For some reason chan_sip protocol mark rules went missing, and on “responsive firewall” chan_sip switch somehow went disabled while the module was updated. Fixed by re-enabling chan_sip in responsive firewall.

12

Hi Rob. I’m still experiencing loop notices after updating to 13.0.53.4
Let me know of any info I can provide or if you would prefer I open a ticket.
Thanks!

A ticket has been created. Vote/watch here.

13

Still seeing the Loop Errors after upgrading to 53.4

Loop detected in monitoring script. Issue with Asterisk? Restarting!
Apr 30 10:29:49 sip journal: voipfirewalld (Monitor thread): Wall: ‘Loop detected in monitoring script. Issue with Asterisk? Restarting!’ returned 0
Apr 30 10:29:54 sip php: Monitor process 13598 missing - restarting!
Apr 30 10:30:16 sip systemd: Removed slice user-995.slice.
Apr 30 10:30:16 sip systemd: Stopping user-995.slice.

14

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