User Rating: 5 / 5

Star Active Star Active Star Active Star Active Star Active

If you have installed FusionPBX from the installation scripts you will notice it has already some fail2ban configurations. If you are using my RPM's, it doe not include any kind of this configuration as my philosophy is to specialize in the package to do one thing, not a do-it-all. Anyway, if you are only using FusionPBX with FreeSWITCH as a personal PBX those rules should be more than enough.

I recommend you do a quick reading of my previous fail2ban post where I describe the gap between Layer 7 exposures versus Layer 3 controls. You will understand my thinking.

If you are being more serious about your PBX or you are running a business you will find at one point those rules are not enough. I will explain myself a little more. As a commercial service, your exposure to the world is bigger; your domain is advertised, telephones do DNS, HTTP and SIP request to your servers and sooner than later you will start getting your first kiddy scripts targeting your servers. As you grow, you will find your customers are far to be technical; they do many dumb things (wrong password because they changed something on the service or inside jobs from tech staff are some examples) which leads to fail2ban rule applications.

There is nothing more harmful than a bad review from an ignorant customer. They do not know why they are being blocked. So, here is where we need to tun fail2ban and add some important information to pre-block offending IP's.

Basic IPTable Rules

There are some TCP attacks that you can not stop with Fail2ban, they are layer-4 specific such as an invalid combination of the TCP flags. Here there are some rules you should add.

iptables -I INPUT -p tcp ! --syn -m state --state NEW -j DROP
iptables -I INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -I INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -I INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
iptables -I INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
iptables -I INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -I INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

The Security Due Diligence Logic

The logic is easy as follows,

fusionpbx freeswitch iptables fail2ban logic

  1. The IP is checked against fail2ban, if fail2ban finds an offending IP that it is not white-listed then the connection is dropped, otherwise, it continues the evaluation
  2. The IP is then checked against a semi-static white-list, if the IP is listed then the connection is accepted, otherwise, it continues the evaluation
  3. The IP is then checked against a semi-static black-list, if the IP is listed then the connection is dropped, otherwise, the connection is accepted

Fail2ban will review constantly the logs, and if a rule is fired, then it will review if the offending IP is auto-whitelisted. I will use this capability to prevent the customer to harm himself. This scenario is very common with customers with multiple extensions behind a single link (remember the NAT, one public IP serving many private ones). Fail2ban and FreeSWITCH will only see the public IP reported by the logs, therefore I highly recommend to accept the risk of having an offending device in a customer network than cancelling the service. The problem is when fail2ban acts, it is hard to realize why as there is not any evidence to find the reason. There are other ways to find an offending device within a white-listed network. I will write another article about that.

Dynamic Whitelists & Fail2ban Configuration

Whitelisting Registered Users' IP's

Dynamic whitelists, as explained before it is the capability of fail2ban to auto-include or auto-exclude an IP from the whitelist. This feature is very handy these days where the NAT is used.

You will need to get the FreeSWITCH filters. The best way to get them is from the GitHub website of FusionPBX. You will need to enable systemd journal support and add the ignorecommand parameter pointing to the customized script.

In order to make this, you need to write a customized script to get the answer. I share with you mine:

(4 votes)

The auto-whitelist script that allows fail2ban to interact with FreeSWITCH

Date  2018-01-25
System   Linux
File Size  933 B
Download  1,221

Modify your fail2ban jails to call this script.

UPDATE: This opens to a question: how to handle misconfigured extensions or inside jobs? I have addressed that in my article that talks about how to handle attacks to your FreeSWITCH/FusionPBX behind NAT's.

Unhandled Incoming Calls

If your FusionPBX deployment is not brand new and you have been updating it from older releases, it is very likely you are missing the not-found dial plan. Add a dial plan in the public context with the following characteristics:

  • order 999
  • context public
  • log action WARNING [inbound routes] 404 not found ${sip_network_ip}

This will allow the FusionPBX / FreeSWITCH 404 filter to work properly.

Let's pre-screen using the VoIP Black List

The diagram talks about some semi-static whitelists and blacklists. This is archived using the VoIP Blacklist service. A service which it is free, without guaranty but it helps us to pre-screen some offending IP's reported by other users.

The whitelist will help us to prevent any service cut from an IP that could be assigned to any customer. For example, if your service is targetting Australia, you would like to whitelist all Australia IP's, later you will need to put another kind of control, but for now, you will no block any Australian source.

The blacklist works with inverse logic, if the IP is listed, the connection is dropped automatically.

You can download the script I have modified from the original published in

(4 votes)

This is a modified version of the download script from that adds support to whitelists and makes itself compatible with fail2ban

Date  2018-01-17
Language   English
System   Linux
File Size  1.21 KB
Download  1,310

Install it, I recommend you to put a crontab that reloads every four hours.

What's next?

At this point, your FusionPBX (FreeSWITCH) should be hardened enough allowing your customers to always have service. But, if you want to close more any open door, you can do the following:

  1. Block port 5060 to allow only incoming connections from countries your customers are from. If you do not have anyone from Korea, there is no point allowing IP's from that country
  2. Block port 5080 to allow only incoming connections from your upstream carrier. If you are not using any eNUM technique, it is smart to block all but trust IP's. I am pretty sure your upstream carrier can give you the signalling IP's.

Remember you can always contact me if you need this done for you.

Good luck!

blog comments powered by Disqus