VoIP Tech Chat

John Todd (with Digium) sent a great email on SIP Security. Although written towards the Asterisk audience, this email provides a very good guideline towards increasing your VoIP SIP Security. It’s a must read and reprinted here for your easy viewing.

In case any of you were wondering why there has been a fairly notable upswing in the attacks happening on SIP endpoints, the answer is “script kiddies.”  In the last few months, a number of new tools have made it easy for knuckle-draggers to attack and defraud SIP endpoints, Asterisk-based systems included.  There are easily-available tools that scan networks looking for SIP hosts, and then scan hosts looking for valid extensions, and then scan valid extensions looking for passwords.  You can take steps, NOW, to eliminate many of these problems.  I think the community is interested in coming up with an integrated Asterisk-based solution that is much wider in scope for dynamic protection (community-shared blacklists is the current thinking) but that doesn’t mean you should wait for some new tool to defend your systems.  You can IMMEDIATELY take fairly common-sense measures to protect your Asterisk server from the bulk of the scans and attacks that are on the increase. The methods and tools for protection already exists – just apply them, and you’ll be able to sleep more soundly at night.

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.

These 7 basics will protect most people, but there are certainly other steps you can take that are more complex and reactive.  Here is a fail2ban recipe ( http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk ) which might allow you to ban endpoints based on volume of requests.

If you’d like to see an example of the tools that you’re up against, see this demo video (http://enablesecurity.com/products/enablesecurity-voippack-sipautohack-demo/) of an automated attack tool that does scan, guess, and crack methods via a click-and-drool interface.

In summary: basic security measures will protect you against the vast majority of SIP-based brute-force attacks.  Most of the SIP attackers are fools with tools – they are opportunists who see an easy way to defraud people who have not considered the costs of insecure methods. Asterisk has some methods to prevent the most obvious attacks from succeeding at the network level, but the most effective method of protection are the administrative issues of password robustness and username obscurity.

JT

Check out John Todd’s blog post at Digium.

About Digium

Digium, Inc., the Asterisk Company, created, owns and is the innovative force behind Asterisk, the most widely used open source telephony software. Since its founding in 1999, Digium has become the open source alternative to proprietary communication providers, with offerings that cost as much as 80 percent less. Digium offers Asterisk software free to the open source community and offers Asterisk Business Edition and Switchvox IP PBX Software to power a broad family of products for small, medium and large businesses. The company’s product line includes a wide range of hardware to enable resellers and customers to implement turnkey solutions or to design their own voice over IP (VoIP) systems. More information is available at www.digium.com.