A possible way to thwart SIP hack attempts on your Asterisk (or other) PBX server

If you’ve had the problem of hackers trying to break into your Asterisk server, you probably know that you can use tools like Fail2ban to at least slow them down.  But why let them know you even have an Asterisk server in the first place?  Maybe you need to leave port 5060 open so that remote users (not on your local network) can connect to the server, but that doesn’t mean that you have to advertise to the bad guys that you might have something of interest.  With that in mind, we direct your attention to this post in the DSLReports VoIP forum:

The Linux netfilter/iptables firewall is capable of stopping these attacks before they even start.

At a bare minimum, this stops 99% of the attacks when added to your iptables ruleset:

-A INPUT -p udp --dport 5060 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:your.pbx.dns.name" --algo bm -j ACCEPT
-A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:" --algo bm -j DROP
-A INPUT -p udp --dport 5060 -m string --string "OPTIONS sip:" --algo bm -j DROP
-A INPUT -p udp --dport 5060 -j ACCEPT

Warning
IMPORTANT: Be sure to have a separate iptables rule (higher on the list than those above) that allows connections to port 5060 from devices on your local network. Otherwise, you may find that new extensions that you are adding for the first time will not register with your Asterisk server, or that after a system reboot, none of your local extensions will register!

To understand how this works, read the original post by DSLReports user espaeth.

For another line of defense against such attacks, see the article Stop SOME SipVicious attacks from reaching your Asterisk, FreeSwitch, YATE, etc. PBX server.

3 thoughts on “A possible way to thwart SIP hack attempts on your Asterisk (or other) PBX server”

  1. Ward Mundy, over at nerdvittles.com came up with a scrip-automated way to do something similar
    http://nerdvittles.com/?p=815

    The idea is that you whitelist all your known static IPs, then use dynamic DNS to have a FQDN for each dynamic IP; periodically check your list of dynamic FQDNs and their associated IPs; if one or more has changed, look them all up again, reload iptables. For a bad guy to even try to break in he’d have to be at one of the IPs one of your dynamic FQDNs had just moved away in, and he’d have to be able to break in within the periodic recheck time. Pretty unlikely if you have decent passwords.

    Reply

    1. Bob, I asked a friend to comment on this and this was his response:

      What Bob has suggested is nothing like what is being suggested in the article you sent me [the original article posted above]. I personally discourage anyone from using the security model suggested on the Nerd Vittles site if you have ANY offsite users that are not at a fixed IP address, because their model will cause your remote users no end of grief. Nobody wants to have to pull up a web browser before they can make or receiver phone calls. There are ways to do something similar without the direct involvement of the end user, for example by replacing the user ID on the end SIP client or VoIP adapter with a specific “knock” string that acts as a secondary password. See http://tech.iprock.com/?p=2478 for a discussion of this technique.

      The thing you have to remember about security advice on certain sites is that the people behind them seem to have a tendency to freak out a bit whenever they read an article where someone’s phone system got hacked, even if that system was not running Asterisk (or any of the commonly available software PBX’s) and did not include the security features already built into Asterisk and FreePBX. I have no problem with increasing security as a general rule, because that is normally a good thing, but I do have a problem when it inconveniences end users. And the solution offered on the page Bob mentioned is, in my opinion, just about the worst approach to increasing security on an Asterisk-based system that I have seen. People will just give up and use their cell phones before they will go thorough the hassle of dealing with that software.

      Reply

      1. Yeah, on re-read, I completely missed the point of this iptables bit – which is to only enable inbound requests that are to your FQDN.

        Good idea, although at least some VOIP providers want an IP, not a FQDN. I think most of those are for the firewall that their end, but you might want to be sure to whitelist their IP blocks just in case.

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.