[Disclaimer: This article gives some guidance on defending your SIP platform from malicious attacks. It is by no means totally comprehensive, and does not claim to be such. Your results may vary based on many different factors, including the correct installation and configuration of the tools discussed.]

Since the beginning of Telecom, unscrupulous people have been trying to commit fraud or breach privacy restrictions - these things have been issues for a long time.

Even back in the heyday of ISDN connectivity, voicemail hacking (both to listen to private messages and toll fraud via an in-out attack) were both very real threats.

Of course in these more modern times of IP Telephony, attaching your PBX, least cost routing engine, or any other application directly to the Internet has significantly increased the probability of ‘the bad guys’ attempting to compromise your system in one way or another.

I am going to discuss two different tools you can deploy to protect your SIP-based system to a certain degree as well as a combination of the two.  

Fail2ban

Fail2ban (see fail2ban.org) has been around since 2004, and is a good general purpose tool.

Adapted from their main page:
Fail2ban scans log files (e.g. /var/log/freeswitch.log or /var/log/asterisk/messages) and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to REJECT the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email) could also be configured. Out of the box Fail2Ban comes with filters for various services (FreeSWITCH, Asterisk, apache, courier, ssh, etc).

Fail2ban is able to reduce the rate of incorrect authentications attempts, however, it cannot eliminate the risk that weak authentication presents. Configure services to use only two factor or public/private authentication mechanisms if you really want to protect services.

With Fail2ban, you have to give the bad guys ‘house room’ for as long as it takes them to do something that will be caught by the filters.

“It would be nice if we could do something preemptive…”, I hear you say.
Well, my friends, that moment has arrived! Meet APIBAN:

APIBAN

APIBAN (see apiban.org) has been created by Fred Posner at LOD Communications, Inc., and works on the principle of maintaining a list of active ‘bad actor’ IP addresses that have attempted to access resources on various honeypots or systems throughout the globe. This data can be used by clients implemented on a wide variety of VoIP platforms to stop said bad actors from being allowed access to your system, by adding REJECT lines for them in the configuration of your firewall.

LOD has even created an Open Source GO client to do this for you, which can be downloaded from GitHub and it is so easy to install and configure even I could do it!

“We’ve been talking about something like this in the open source community for years…at ClueCon, AstriCon, Kamailio World, etc. And then we all just kind of went back to our normal lives. Finally, last year I just made the time to get it started and integrate with Kamailio. Then building the GO client for linux systems so it can help FreeSWITCH, Fusion, FreePBX, and Asterisk systems as well. We’re loving the feedback and open to suggestions.” said Fred Posner, the creator of APIBAN.

The client initially builds an APIBAN chain in your iptables configuration and fetches all the ‘bad actor’ IP addresses it knows about to be part of that chain. Each time you subsequently run the client, it purely fetches incremental IP addresses that have appeared since last time, so as not to needlessly spend time collecting a list when you have most of that list already.

So with both the newer APIBAN and the more established Fail2ban you can keep the known bad guys out of your system preemptively AND mop up any that do get in and fail to securely register or otherwise interact with your system within 5 attempts (or whatever you have set that number to).

Possible issue when using APIBAN and Fail2ban together

If you are creating a brand new SIP-based comms server of some type, and install APIBAN first, there is a potential issue when you come to install and enable Fail2ban subsequently.

APIBAN will have happily built a chain of the IP addresses to be banned, but when Fail2ban runs for the first time, it has annoying functionality that flushes iptables of existing rules, and therefore deletes the APIBAN chain.

APIBAN continues doing what it does best, pulling in new IP addresses, so these incremental IP addresses are added to iptables, but the list they are incremental to does not exist!

At least that’s the way things were, until I mentioned this issue to the authors of APIBAN, and they stepped in and modified the GO client, so that it checks for the presence of the APIBAN list, and if it finds it has disappeared, it both creates the list AND pulls in the full list of IP addresses, thus solving the problem.

When I enquired as to whether this issue could occur the other way around (with APIBAN removing rules that Fail2ban had put in place), the answer was simple:
No, because we respect the rules that others have already placed in iptables!