NOTE: For some reason WordPress absolutely hates it when I try to edit this post, and turns links and other things into piles of steaming poo. If things don’t look right here please e-mail me or leave a comment and I’ll check it out. WordPress, I KNOW how I want my articles to look, why can’t you just leave them alone?
One problem faced by some SIP-based VoIP PBX administrators is the issue of security when you have external extensions (that is, extensions located anywhere in the world that’s not a part of your local network). You want to allow those extensions (the ones you’ve authorized) to connect to your system, but you prefer to keep everyone else out, and preferably not even tip them off that there’s a PBX there. The idea is, if the bad guys that would like to break into PBX’s don’t even realize that there is a PBX at your IP address, they won’t waste any time trying to crack into your system.
There have been other suggestions for how to handle this but many of them require your users to take some additional action(s) that they would not normally have to take, and users hate having to lift a finger to do anything to enhance their security. Which brings us to a rather clever technique that doesn’t require user to do anything other than use their phones as they normally would. It might be a tiny bit of a pain to set up initially, but the results may be worth it. I would call this medium level security because if someone is sniffing your packets, this alone may not keep them out, but most of the lowlifes that try to break into PBX’s don’t actually have sufficient access to sniff your packet stream (and also, they’d have to know the exact technique you’re using to be able to crack this). So without further ado…
Secure your VoIP server with the SunshineNetworks knock
Note that while the article recommends changing the SIP port to something other than 5060, their basic technique (the “knock”) should still work even if you feel you need to stay on 5060. My only fear about changing the SIP port would be the possibility of losing communications with VoIP providers and with other systems I legitimately send/receive voice traffic to/from. They’re probably going to keep using 5060 even if I don’t. EDIT: My concern here may be unfounded — note the comment below from Alex of Sunshine Networks, who said that “changing the SIP port is quite safe. Your SIP server will send this SIP port along in it’s first SIP invite registration to the VoIP provider. So unless your VoIP provider is actively blocking out anything else than port 5060, it should work fine. We use this technique with 3 different major SIP providers in Australia and never had problems. So far we haven’t seen any unintended consequences.”
I haven’t personally tested this, so if you do, please consider leaving a comment to let me know how it worked for you. The two things I wonder are, do these rules survive a reboot, and can you have more than one secret phrase that would let people in (in case you want to use a different one for each external extension)? EDIT: Those questions are also addressed in Alex’s comment below. Also, those of you running PBX in a Flash should take note of Ward Mundy’s comment about changing an entry in /etc/sysconfig/iptables in this thread. In that same thread, there appears a method to view the “knock” each extension is currently sending — just do “sip debug” from the Asterisk CLI for an hour or so (long enough for all your endpoints to register, after which you can use “sip no debug” to turn it off), then run this at the Linux command prompt (not from the CLI!):
grep "From: " /var/log/asterisk/full|cut -f1 --delimiter=\; | sort -u
For each of your remote extensions, you’ll see a line that looks something like this:
From: The Knock <sip:234@nn.nn.nn.nn>
“The Knock” may or may not be enclosed in quotation marks, but it apparently doesn’t matter (you don’t include them in the iptables rules). If you haven’t used a specific “knock”, it could be the actual user’s name, if you set that up when you first set up the endpoint. Anyway, I’d suggest running this BEFORE you actually implement the iptables rules, so you know ahead of time what each endpoint is sending.
EDIT (Added January 8, 2012): I am now using a slight variation on this technique on one of the systems I administer. Without going into too many specifics, I will just note that some SIP devices and VoIP adapters actually already send a unique string that you can use as a “knock” – you do not have to configure a new one, you just need to find out what the device is already sending and use that. For example, let’s say you have an Obihai device (such as an OBi100 or OBi110) connecting to your Asterisk server as extension 234. All you have to do is go to the Asterisk CLI (NOT the Linux command prompt) and enter this:
sip set debug peer 234
(Replace 234 with the actual extension number). Now, assuming that the device is connecting to your server, you will start to see SIP packets scroll across your screen. Within a few minutes you should see one like this (IP addresses have been xx’ed out):
<--- SIP read from UDP:xx.xx.xx.xx:5061 --->
REGISTER sip:xx.xx.xx.xx:5060 SIP/2.0
Call-ID: e10700c2@xx.xx.xx.xx
Content-Length: 0
CSeq: 56790 REGISTER
From: <sip:234@xx.xx.xx.xx>;tag=SP8f427e45f1e19cb24
Max-Forwards: 70
To: <sip:234@xx.xx.xx.xx>
Via: SIP/2.0/UDP xx.xx.xx.xx:5061;branch=z4b9hGK-4f0473a8;rport
Authorization: DIGEST algorithm=MD5,nonce="37cd169d",realm="asterisk",response="a726bfed5db321a7bc967b997b5157c2",uri="sip:xx.xx.xx.xx:5060",username="234"
User-Agent: OBIHAI/OBi110-1.3.0.2651
Contact: <sip:234@xx.xx.xx.xx:5061>;expires=60;+sip.instance="<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>"
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces
<------------->
If you don’t see this you may need to increase the debug level. After you see a packet like this, you can turn off sip debugging:
sip set debug off
The string you are looking for is in the Contact: string above (the nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn is replaced by a unique string). So, where in the instructions for the “knock” they show a sample string such as:
iptables -I door 1 -p udp --dport 5060 -m string --string "mysecretpass" --algo bm -m recent --set --name portisnowopen
I would change the --dport parameter to 5060:5061 (since an Obihai device sometimes uses port 5061 for the SP2 provider — for an OBi202 use 5060:5063 because it goes up to SP4) and the --string parameter to “<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>”, but using the actual string sent by the device, of course. I know the Sunshine Network people recommend using something other than port 5060 but I just can’t bring myself to go quite that far, and even their examples show 5060.
Some other SIP-compliant devices also send unique strings in their REGISTER packets. One that does NOT do so, as far as I am aware, is the venerable Linksys PAP2. And I also do not believe that any of the Sipura line of devices send such a unique string.
Naturally, if an intruder KNOWS you are using that technique, they could try a brute-force attack on the unique string. So I recommend only using this with “uncommon” extension numbers (not 200 or 1000, for example) and with a VERY strong secret/password on the SIP connection. But it is another line of defense against would-be intruders!
Alex said
Hi MichiganTelephone,
Thanks for your questions, and here are the answers to your questions about this security technique :
1) changing the SIP port is quite safe. Your SIP server will send this SIP port along in it’s first SIP invite registration to the VoIP provider. So unless your VoIP provider is actively blocking out anything else than port 5060, it should work fine. We use this technique with 3 different major SIP providers in Australia and never had problems. So far we haven’t seen any unintended consequences.
2) I now added “service iptables save” , which saves the iptables config. I have added the command to the article, thanks for spotting this.
3) Yes there is, I have amended the iptables rule in the article to show how you can add additional passwords.
4) This technique will work on Elastix / PiAF / AsteriskNow / Trixbox and all other well known Asterisk distros. Most of them use CentOS which comes with the iptables package by default.
5) This technique should never be used alone. It’s intended to be one of many layers of security for your system. By using a layered security approach, chances of being cracked diminish dramatically.
michigantelephone said
Alex, thanks for your reply. While I tend to agree that this technique probably shouldn’t be your only line of defense, I think it’s superior to those methods that inconvenience users by requiring them to go to a web site before using their phones, or enduring some other inconvenience. To mind this is brilliant in its simplicity, both in how easy it is to implement and the fact that it requires zero additional effort on the part of users. So, thank you for publishing it!
Alex said
I fixed the problem with “Some browsers (or more specifically, certain browser add-ons, such as the Firefox Linkification add-on), may render certain lines incorrectly”. I also added a .txt version of the code in case the code still does not display correctly. Thanks for the feedback.
michigantelephone said
You’re welcome, Alex, and thanks for fixing that. I removed that comment from my original article, so it wouldn’t confuse anyone.
Anonymous said
Hello i have tried this solution with iax. It work pretty well for my extensions but i have also an iax trunk for inter office communication and i cannot figure out how i can pass the “knock” through the trunk to establish a communication between the two servers. I tried the fromuser directive on my peer details (i am using elastix 2.0.3) but that didn’t do the trick.