Taking the Hardening of FusionPBX / FreeSWITCH further
- Details
- Category: Technology
User Rating: 5 / 5
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,
- 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
- 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
- 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:
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 www.voipbl.org.
This is a modified version of the download script from www.voipbl.org that adds support to whitelists and makes itself compatible with fail2ban
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:
- 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
- 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 DisqusMost Read Posts in Technology
About
Read about IT, Migration, Business, Money, Marketing and other subjects.
Some subjects: FusionPBX, FreeSWITCH, Linux, Security, Canada, Cryptocurrency, Trading.