Locking down a freepbx distro machine - hosted pbx service

I know the best solution is to put the distro machine behind proper hardware firewall. I have my primary one behind a proper firewall. But I was testing a hosted solution. In light of the recent attacks, I was looking for ways to lock down the system more.

For example, can I add (on top of the existing fail2ban rules) an iptables command to reject all http/80 traffic from everything except an approved white list? My users currently get into our freepbx server via VPN, so it is reasonable to request that they access the VPN to get to the hosted server as well.

I generally know how to do that… but not sure if it will mess up the fail2ban configuration. I read the manual/faq on the fail2ban site, but didn’t get a clear answer.

Of course, my bigger concern is that since it is a remote hosted machine (freepbxhosting) I’m a bit afraid I might totally lock myself out… So I am approaching with caution.

BTW - noticing that fail2ban doesn’t detect the main login password fails or the recordings login failures.

Would it be possible to change the code such that ‘recordings/index.php’ would reload ‘recordings/index.php?error=1’ when a bad user/password is detected? Ditto for ‘admin/config.php’?

The value wouldn’t need to be read by the php code at all, but it would show up as a string in the access_log for easy parsing by fail2ban.

In the distro with 12 we do track failures in /var/log/asterisk/freepbx_security.log and we have a fail2ban filter

Nice! Thanks. Not in a position I can move to 12 yet, but looking forward to it! Or maybe perhaps I should just jump on it. I’m currently on 1.810.210.57-1. Trying out freepbxhosting. Like to have my system outside of our flakey internet.

Any web page I can read about adding DROP rules to what already exists in fail2ban? I’d like to block port 80 from everywhere except my home static IP. But don’t want to start running iptables command for fear of breaking fail2ban.

I suggest you do it the other way around, any iptables rules you need should be set BEFORE you start fail2ban, which just adds chains to your existing iptables/firewall rules.

Ahh… I see now that when I stop the intrusion protection in the purchased system administration module the iptables get cleared. Restarting adds the fail2ban rules.


If you feel you need of an easy to setup firewall/ids (most would agree its a not a bad thing) look into CSF/LFD and its ability to simply control the fail2ban service with the scripts /etc/csf/csfpre.sh to stop fail2ban if it is running and /etc/csf/csfpost.sh to start csf after you have a functional iptables firewall in place. IWFM

Good learning day for me :smile:

I’ll read up on CSF/LFD this evening. Will it play well with the fail2ban rules that freepbx already creates?

HeHe, again you are doing it backwards :wink: , start with


to see how it works by dynamically adding rules to iptables,

(this post’s original timestamp was in response to the question you will next ask, It’s an editing thing :slight_smile: )

I’ll read CSF/LFD before I ask any more stupid questions.

In addition to what has been mentioned, you should also look into enabling SSL for the web server, setting a root password for MySQL, using non-standard ports, and double-checking that nothing is using a default password. TLS and SRTP are also things you should consider. Use caution and do a lot of research before doing any of this, though, as you can break any number of things.

Also, as with all security advice, it inherently depends on your own appetite for risk and analysis of the relative merits and costs of security enhancements. In the end you need to evaluate your own level of comfort with any given configuration. Having said that, using a hosted solution that is not behind a proper firewall will never be the proper solution for those who are truly paranoid (in a good way!) about security.