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.
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 logic is easy as follows,
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, 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.
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:
This will allow the FusionPBX / FreeSWITCH 404 filter to work properly.
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.
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:
Remember you can always contact me if you need this done for you.
Good luck!blog comments powered by Disqus
Most Read Posts in Technology
Read about IT, Migration, Business, Money, Marketing and other subjects.
Some subjects: FusionPBX, FreeSWITCH, Linux, Security, Canada, Cryptocurrency, Trading.