VoIPtel Blog

We have been using different types of Asterisk based IP PBX’s for almost three years now, and with the exceptions of problems created by our ISP, VoIP provider or our own staff it has been smooth sailing. But just over a week ago I was really %¤##”& off; I was invited to attend a conference with the CEO of a reputable Canadian company and their UK based EMEA manager. Everything was prepared, I dialed the UK number to attend the conference and got busy line! Tried again, same result. OK, breath slowly, I had a US number for the same conference. BUSY LINE! Try again, same result, what the ¤%#& was going on?? A couple of emails later the conference was rescheduled for next day, hopefully the problems with the conference server would be solved by then.

New day, new chances. I dialed the UK number again and got … BUSY LINE! US number, same result! This couldn’t be right, I decided that we better check our own equipment before we attempted to attend the conference once more! A new conference was scheduled after the weekend, at least we would have enough time to find out what was going on.

Bruce logged in to our PBX and checked the config after which he tried to call an international number, do I need to mention that he got busy line? He tried another number watching the progress of the call and discovered that the call appeared to be denied by our VoIP supplier! Strange, to my knowledge all our bills was paid, was there really any reason why a VoIP provider would block international calls from a corporate customer?

We called up their support department and explained the problem, I prefer not to describe my reaction when I was informed that they had indeed blocked our international access! The reason; we were using Asterisk and one of their customers using a very old Asterisk distribution had been hacked and his account abused for more than $30 000. And our provider had forgotten to include a statement leaving the responsibility for such incidents with the subscriber. Needless to say they panicked, closed down international calls for all Asterisk users and “forgot” to inform their customers leaving us all in the dark! It took some time to convince them that our PBX was secure, but finally we were able to get full functionality restored.

I can understand their reaction (no, not their “customer support”, it sucks!), so I have decided to point your attention to a blog post titled Seven Steps to Better SIP Security with Asterisk. Please visit it and read it all, I have only published the seven steps here:

Seven Easy Steps to Better SIP Security on Asterisk:

1) Don’t accept SIP authentication requests from all IP addresses. Use the “permit=” and “deny=” lines in sip.conf to only allow a reasonable subset of IP addresess to reach each listed extension/user in your sip.conf file. Even if you accept inbound calls from “anywhere” (via [default]) don’t let those users reach authenticated elements!

2) Set “alwaysauthreject=yes” in your sip.conf file. This option has been around for a while (since 1.2?) but the default is “no”, which allows extension information leakage. Setting this to “yes” will reject bad authentication requests on valid usernames with the same rejection information as with invalid usernames, denying remote attackers the ability to detect existing extensions with brute-force guessing attacks.

3) Use STRONG passwords for SIP entities. This is probably the most important step you can take. Don’t just concatenate two words together and suffix it with “1″ – if you’ve seen how sophisticated the tools are that guess passwords, you’d understand that trivial obfuscation like that is a minor hinderance to a modern CPU. Use symbols, numbers, and a mix of upper and lowercase letters at least 12 digits long.

4) Block your AMI manager ports. Use “permit=” and “deny=” lines in manager.conf to reduce inbound connections to known hosts only. Use strong passwords here, again at least 12 characters with a complex mix of symbols, numbers, and letters.

5) Allow only one or two calls at a time per SIP entity, where possible. At the worst, limiting your exposure to toll fraud is a wise thing to do. This also limits your exposure when legitimate password holders on your system lose control of their passphrase – writing it on the bottom of the SIP phone, for instance, which I’ve seen.

6) Make your SIP usernames different than your extensions. While it is convenient to have extension “1234″ map to SIP entry “1234″ which is also SIP user “1234″, this is an easy target for attackers to guess SIP authentication names. Use the MAC address of the device, or some sort of combination of a common phrase + extension MD5 hash (example: from a shell prompt, try “md5 -s ThePassword5000″)

7) Ensure your [default] context is secure. Don’t allow unauthenticated callers to reach any contexts that allow toll calls. Permit only a limited number of active calls through your default context (use the “GROUP” function as a counter.) Prohibit unauthenticated calls entirely (if you don’t want them) by setting “allowguest=no” in the [general] part of sip.conf.