Freepbx 12 - Ban IP forever


I have an IP address which is trying to break into both my Freepbx systems (the same IP which I wont put on here just in case they themselves have been hacked). Is there an easy way to ban IP addresses forever (I can use the Freepbx fail to ban interface but this just blocks on a temp basis). In these days on what seems like a never ending barage of people trying to hack systems, maybe freepbx could do with an easier way to ban IP addresses forever? (or better still, once an address has been temp banned, an easy way to click on the IP to ban it for good…)

Cheers for a brillaint piece of work, Freepbx 12 is the bee’s knee’s and I wont be without it…


Admin -> System Admin -> Intrusion Detection -> Ban Time - Set it to a negative number (like -1) for a permanent ban. Documentation here:



Cheers for this. Perhaps the little help question mark beside ban time should maybe make reference to this?

Take care


That doesn’t work over a fail2ban restart with the version you have, the lastest version of fail2ban uses a persistent sqlite3 database and maintains bans over a reload/restart but it doesn’t work on Centos yet (it’s a python thing) either way fail2ban has a jail called “recidive” for handling that situation. properly

I would say that permanent denies belong on your firewall you have iptables but manually adding per host rules will eventually be tiresome., if you don’t have a firewall then you need one (preferably a sofware one on your PBX, and a hardware one on your point of ingress/egress ) , you can easily add a software one, my preference is CSF.


I have now set the ban time to be 86400 - 24 hours, and then the retry attempts to 1… I

Is it OK to install CSF on my PBX? - they are fast machines, SSD, icore 5, 16GB mem (mini ASUS ITX machines I made for the job so plenty of spare umph).

I will now Google CSF and see whats invloved…

Cheers again for all the help…


I install it along with rkhunter and fail2ban 0.9.1 which is much faster and less resource-needy to every one of my FreePBX instances as a matter of course, the fact that you can cluster the LFD part of it over many boxes (not just your PBI) and fail2ban’s chains can be properly included in the right place makes it very easy to keep the knuckledraggers out


Cheers again for the info. I am looking at the documentation for CSF now and will have a go at putting it on my test machine the weekend (if the suns not shining ;-). If you have any pointers to setting it up (or what pitfalls I may encounter) I would be very grateful…

Is there a reason that the distro doesnt come with these already install? It seems like everyone and his/her mum is getting grief now with hackers, and although Freepbx is getting so much more easy to use (interface/help/layout/etc.) the secuirty doesnt seem to be keeping up with its good looks and functionality.

Maybe it should be a paid for option (secuirty module that is bought like the other modules). I am sure it would sell like hot cakes… What do you think?

Take care


CSF was looked at awhile back, but if I remember correctly at the time there was some sort of license issue with including it in a distribution. I don’t remember the specific details.


Cheers for getting back…

Do you have any pointers to the install (or know of a web page that expains how to do this for Freepbx 12 on Centos)? I am sure there are many a folk out there who are having the same issues as me… Any help would be much appreciated. I am no Linux expert, but happy to work with my system unit via SSH (I am a Raspberry Pi fan and these things chuck you in at the deep end with Linux if you dont want the GUI it comes with)…

Many thanks


No @dicko would be the expert on CSF, I’m pretty sure it is cross platform and they do seem to have instructions on their site. I don’t believe you can run it and iptables at the same time so depending on what you have installed you may need to makes some modifications. For your raspberry pi you may need to run UFW or GUFW, not really sure if they have the horsepower to do too much.

As Preston said it’s all on

In the links at the bottom of the page, read the readme, particularly :-1:

  1. csf Principles

The idea with csf, as with most iptables firewall configurations, is to block
everything and then allow through only those connections that you want. This is
done in iptables by DROPPING all connections in and out of the server on all
protocols. Then allow traffic in and out from existing connections. Then open
ports up in and outgoing for both TCP and UDP individually.

This way we can control exactly what traffic is allowed in and out of the
server and helps protect the server from malicious attack.

In particular it prevents unauthorised access to network daemons that we want
to restrict access by IP address, and also should a service suffer a
compromise, it can help prevent access to compromise networks daemons, a
typical example being a hackers sshd daemon running on a random open port.
Perhaps the greatest of reasons is to help mitigate the effects of suffering a
root compromise where often they only way to take advantage of such a failure
is to open a daemon for the hacker to access the server on. While this won’t
prevent root compromises, it can help slow them down enough for you to notice
and react.

Another way that a port filtering firewall can help is when a user level
compromise occurs and a hacker installs DOS tools to effect other servers. A
firewall configured to block outgoing connections except on specific ports can
help prevent DOS attacks from working and make it immediately apparent to you
from the system logs.

csf has been designed to keep this configuration simple, but still flexible
enough to give you options to suit your server environment. Often firewall
scripts can become cumbersome of complex making it impossible to identify where
problems lie and to easily fix them.

To take advantage of kernel logging of iptables dropped connections you should
ensure that kernel logging daemon (klogd) is enabled. Typically, VPS servers
have this disabled and you should check /etc/init.d/syslog and make sure that
any klogd lines are not commented out. If you change the file, remember to
restart syslog.

  1. lfd Principles

One of the best ways to protect the server from inbound attack against network
daemons is to monitor their authentication logs. Invalid login attempts which
happen in a short space of time from the same source can often mean someone is
attempting to brute-force their way into the server, usually by guessing
usernames and passwords and therefore generating authentication and login

lfd can monitor the most commonly abused protocols, SSHD, POP3, IMAP, FTP and
HTTP password protection. Unlike other applications, lfd is a daemon process
that monitors logs continuously and so can react within seconds of detecting
such attempts. It also monitors across protocols, so if attempts are made on
different protocols in a short space of time, all those attempts will be
counted against the threshold.

Once the number of failed login attempts is reached, lfd immediately forks a
sub-process and uses csf to block the offending IP address from both in and
outgoing connections. Stopping the attack in its tracks in a quick and timely
manner. Other applications that use cron job timings to run usually completely
miss brute force attacks as they run usually every 5 minutes or by which time
the attack could be over, or simply biding its time. In the meantime lfd will
have block the offenders IP address.

By running the block and alert email actions in a sub-process, the main daemon
can continue monitoring the logs without delay.

If you want to know when lfd blocks an IP address you can enable the email
alert (which is on by default) and you should watch the log file in
/var/log/lfd.log. If you use logcheck, you can add it to your log monitoring
by editing and adding the line:

$LOGTAIL /var/log/lfd.log >> $TMPDIR/check.$$

Add it in amongst the other logs that you have selected.

Then the License to possibly understand why it is not included in many commercial products (Presumably 3. SCOPE OF LICENCE)

After installing with

cd /usr/src
rm -fv csf.tgz
tar -xzf csf.tgz
cd csf

/etc/csf/csf.conf is pretty well all you need to read and modify it is very well self documented.

There is an included Webmin module csfwebmin.tgz that gives you a simple to use GUI to manage it within Webmin for the bash bashful, if that is your desire then install Webmin before CSF. If you install Webmin later make sure to change the Webmin port and enable the fail2ban webmin jail, and edit your csf.conf as necessary.

CSF/LFD is a front end to iptables much like UFW or GUFW but far more “complicated” :wink: , basically a set of perl scripts that builds and dynamically maintains a complete iptables ruleset complete with rate limiting and MITM attack detection/prevention, plus detection/prevention of MANY other attacks, make sure you stop any other iptables based services in your (like fail2ban) and start them again in the right pecking order in

There are several scripts documented in the readme to make sure your kernel fully supports some of the more powerful features, so it will underperform on many hosted situations. There is also an audit script to prompt you to tighten up some of the more blatant security flaws in many setups.

Other than that it really takes no brain-surgery, just a bit of RTFM.

As an addendum, Fully configure fail2ban as it is likely far more capable than you think, it can seamlessly add “on the fly” rules to iptables from many services you have or care add to keep the knuckledraggers out.

As to The Raspberry particularly the RasPBX distro, it will have no trouble with iptables, but the newer UCP stuff can bring it to its knees, maybe a $50 upgrade to a Pi2 but the advantage is that it is Debian based so you can use the latest fail2ban with a supported python and a supported PHP (It bitches about the security problems of the EOL PHP 5.3)


Brillaint, cheers for sending this over. I have my weekend planned (sun or no sun ;-). The Raspberry Pi’s I use are for my weather station and home control (in for a penny - in for a pound) so not part of my Pbx system. The Pbx’s use much quicker icore 5-ssd machines (ASUS M/B) which I upgraded to from Pika Warp machines… The good thing about the Pi’s is that you can easily start from scratch when learning linux - I reckon a must for all those ready to take the Linux plunge.

Again, your advice has been very valuable, without this forum I think I would have not thrown away my Panasonic PBX two years ago, and been able to make cheap if not free calls worldwide…

Have lovely weekend’s - and if you hear a cry in the far distant on sat/sun, you know I have mucked things up :wink: