FreePBX Firewall Alpha test - 2019-04-07

Well, after messing around, I’ve finally released the alpha of FreePBX Firewall with the couple of bugfixes that I want to submit back here.

Details are on the Forums, with links and stuff there. Please test to make sure I haven’t broken anything!


I’m hoping SOMEONE has tried it - I’m using CloudFlare as the CDN, and I have to pay money to them to get reasonable stats, so I don’t ACTUALLY know if people have downloaded it!

So, any feedback? At all? Even ‘Yep, didn’t set my system on fire’ is good 8)

1 Like
[[email protected] ~]# fwconsole ma list | grep fire
| firewall             | 13.0.58      | Enabled                           | AGPLv3+    |
[[email protected] ~]# cat /etc/schmooze/pbx-version

Zero conflagrations nor discernible issues that I can see. Any specific stress tests you want me to do?


Well, nope. As long as it’s working, that’s a great start. How about rate limiting of the provisioning ports? This should have been in the original firewall, but I messed up and it wasn’t working. It uses the same rate limiting as the responsive firewall.

So, if you were to wander off to a non-trusted PC, expose your provisioning ports to the internet, it should rate-limit them, without any further configuration - simply hammer a wget 30 or 40 times and you should be in the blacklist.

1 Like

Set http provisioning to internet zone, and hammered away at it from an untrusted IP. Initial testing was tainted by fail2ban, but once I whitelisted the IP in Int Detection, I think I could see the effect of rate limiting, but the host never showed up in the GUI as rate limited under “Status”. If I kept hammering then a full block happens and the IP finally does show up as blocked under “Status”.

So at first when I start hammering, I get 401 back from Apache. Continuing on, I start to get ‘connection refused’ and then continuing on after that the curls start to time out. When I’m getting the ‘connection refused’, is that a result of rate limiting?

1 Like

Yeah, the rate limiting doesn’t REALLY work that well with TCP connections, because TCP just backs off when a packet is dropped. But, as it did get blocked, I’ll consider that good enough.

The thing that worries me is that I’m TOO sensitive with the provisioning port, but if it took you a significant effort to get blocked, I feel that’ll work.

That’s when it’s in the ‘you’re probably naughty’ table. It does that to encourage the phone to report an error.

If you still keep going, it’ll then just drop your packets because you’re OBVIOUSLY a bad guy.

It’s pretty easy to trigger a ban, even if you are doing legit http requests with valid creds. I feel like if the power were to bounce a few times at a location with only a few phones, and they all provisioned a few times in quick succession it might be enough to trigger a ban from just the provisioning requests. Sangoma phones do 14 file requests on provision, and other phones do more than that.

And in case I wasn’t clear, rate limiting on prov port appears to be working, but the host doesn’t show up in the list of rate limited hosts in the GUI. It only shows up once it’s completely blocked.

Well they’d ALREADY be registered, you’d hope they wouldn’t time out… Hmm. You have a bunch of phones. Any chance you can spare some time to see if I need to tweak some knobs?

Once an IP address is discovered as ‘registered’, it’s not removed from the knownreg table for 90 seconds AFTER it’s disappeared from Asterisk, because network flaps happen. So even if all the phones went off and rebooted, it would take asterisk 3 mins to drop the reg, and then you’d have ANOTHER 90 secs after that - so around 5 minutes before clients start hitting the ratelimit table.

Things that make you go hmm. It won’t be any time soon, but will put it on the list.

Are you thinking to put http/https provisioning on the responsive tab and manage access similar to how it’s currently done for sip/pjsip/iax? I think you should, otherwise people might be reluctant to expose prov http/https to internet thinking it’s unprotected OR might not even want Firewall to protect these services and instead rely on credentials only.

After sleeping on it, I am agreeing with @lgaetz - I can’t use the same rate limits that I use for SIP traffic, for provisioning scanning. I’ll have a play with a bunch of phones and work out a better scheme.

However, I am still adamant that this should not be a user-fiddleable knob. I need to figure out what the worst possible amount of data a phone needs to pull before it can register, multiply it by three, and then put that in - hopefully.

I have a Polycom here, which is UNDENIABLY the worst phone to provision (with Cisco phones coming a VERY close second), so I’ll see how confused I can make it, and base the rate limiting off that.

I also agree that the rate limiting needs to be optional, so it can be turned off for EXTRA SPECIALLY STUPID phones.

I have to pull apart my car this weekend as I’ve been putting it off for so long, but when I get sick of that I’ll throw some brain sweat into fixing this.

Thanks again Lorne - and if anyone else has any OTHER suggestions or requests, now is the time to ask about them!

1 Like

I’ve done both - I think you have worst and less-worst backwards. :slight_smile:

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