Major facelift to the FreePBX Firewall

Tags: #<Tag:0x00007f7027c4aba0>

(Lorne Gaetz) #1

One of the goals of FreePBX 16 is a review and update for FreePBX security settings. Today, a major aspect of that work has been published to edge for FreePBX 14 and 15 Firewall module. These latest changes are mostly the work of @danardf, and you can read his blog post here:

FreePBX historians (if there be such a thing) will recall that it was right around 5 years ago that the FreePBX firewall made its debut. It was the work product of @xrobau and it came shortly after the merger of Schmoozecom and Sangoma. From a security point of view, the Firewall module was a game changer, I can barely remember the good ol’ days when security was largely delegated to an external firewall or trying to bolt-on third party firewall managers.

Today’s edge version marks the next milestone in the Firewall project. There is now tight integration between the Firewall module and fail2ban. Anyone in a position to do so is strongly encouraged to give it a spin and report back with your findings.

If you want to give the changes a try, you can upgrade using

fwconsole ma upgrade sysadmin firewall --edge

IP address keeps getting banned even when excluded in Firewall
FPBX 15 firewall, hosts being added to zone-trusted without me doing anything

Having seen some discussions about decoupling firewall from the sysadmin module, I was hoping this one was it. Nevertheless, nice work to @danardf on incorporating fail2ban.

(Franck Danard) #3

Thanks Bill :slight_smile:

However, Firewall module is still linked with sysadmin. :wink:


De-coupling Firewall from SysAdmin would not be difficult.


There needs to be a discussion and consensus on a framework that could co-exist with SysAdmin, be deemed secure enough to be accepted by the community, and be merged by Sangoma. If such a framework existed, some of the non-distro community might work on it, but otherwise have no interest in chasing our tail.

I’ve already spent more time than I should have on a Firewall module I don’t use, just because the LetsEncrypt issues annoyed me.

(Lucas Ryan) #5

Great work! Nice to see these things are being synced up and improved.

(Franck Danard) #6

Thanks :slight_smile:

(Daniel Friedman) #7

Hello @danardf,

Would it be still possible to run the intrusion detection settings page without the firewall module being enabled?

I understand that the old location links to the new firewall module page, but it is not clear if you have to enable the firewall module in order to use the intrusion detection settings page or not.

Thank you,

Daniel Friedman
Trixton LTD.

(Lorne Gaetz) #8

No, ID settings have been moved to the firewall module.


Does that mean no more being able to use ipatbles/fail2ban manually? Are we forced to install the firewall module to use ID together with iptables/fail2ban ?


I’m curious, what’s the issue? Sysadmin isn’t the only module that makes system calls. Though it might be the only module that makes privileged system calls.

(Lorne Gaetz) #11

Installing the firewall module is optional as it always has been.


Given your previous comment that ID now only works with the firewall module, my question was whether fail2ban now only works with the firewall module installed.

(Lorne Gaetz) #13

If you want the PBX to configure fail2ban for you, then the firewall module is required.

(Itzik) #14

Nice work @danardf!

Question: I understand that this syncs whitelisted IPs to fail2ban. What about FQDNs? and what happens when the DNS has been updated (there’s a new dynamic IP)?



Any FreePBX distro module needing root privileges passes through sysadmin.

The firewall daemon runs as root, and several firewall functions that change iptables or f2b outside the daemon also need root (or at least elevated) access.

Currently all elevated operations in FreePBX distro are handled via the sysadmin “hooks” functionality. FreePBX (as the asterisk user) drops a file in a monitored folder. A root process (incrond) picks up the file and passes it to /usr/bin/sysadmin_manager to process and ultimately invoke the appropriate FreePBX code as root. Look at all the module scripts under /var/www/html/admin/modules/*/hooks. They all run as root via sysadmin.

Writing a sysadmin stub to handle the hooks would be trivial, but any claims hooks are secure (whether or not valid) are based on sysadmin being zend “secured” along with module signing.

I’d also suspect something in the terms of service we clicked through might be a barrier to reverse engineering and implementing our own open source sysadmin.

So, how do we cross the privilege barrier without the official sysadmin, remain compatible, be secure, and avoid a letter from Sangoma attorneys?


(and nobody with a currently supported PHP version can get Zend, and if you are a poor benighted non SNG OS user, you are ‘doomed’ :wink: . If not AMD64 , even more blighted)

Come on Franck, its just a couple of incron privilege elevations , push your bosses to at least expose them :wink: before you guys have to abandon Zend, just as they abandoned you, anyway.

Every few months, now weeks, starting with the PI there are more and more SBC’s at very reasonable prices, that although running the latest Debian, (they could likely would do RH too, but that will be ‘later’) are orphaned by FreePBX ‘distro’ needlessly because of Zend.

Why do Sangoma still snub that market?


But can we still manually configure iptables and fail2ban and continue using them without the need to install the firewall module? I’m currently managing and using them without the firewall module. Can we keep doing that? Or is the new firewall module a mandatory prerequisite for iptables/fail2ban? I don’t need the firewall or FreePBX to configure them for me.


I cannot see any reason why not, the underlying OS supersedes anything as to networking and IP filtering. If there is no other ‘meddling’ you will be good-to go.

(Franck Danard) #19

All zones selected in the firewall module will be sync to ID (F2B), so FQDNs will be sync to ID as well.

(Franck Danard) #20

You should be able to configure them manually indeed.