Security

Better SIP Security with Asterisk IP PBX


We recently have seen an increase in the number of Asterisk IP PBX's being hacked for the purposes of placing free phone calls via those hacked IP PBX's, and in turn through the VoIPVoIP account that is used from that IP PBX, causing customers' accounts to be charged without their knowledge.
Please note that VoIP SP is not responsible for preventing unwanted physical or remote access to your Asterisk IP PBX. If your Asterisk IP PBX is compromised then you will be responsible for any damage caused.

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.

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!

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.

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.

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.
Syntax:

permit=<ipaddress>/<network mask>
deny=<ipaddress>/<network mask>


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.

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″)






Fail2Ban with Asterisk

Fail2Ban is a limited intrusion detection/prevention system. It works by scanning log files and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc. Generally Fail2Ban 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, or ejecting CD-ROM tray) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, curier, ssh, etc).

Firewall

Most Asterisk boxes should be located behind a hardware firewall. Configure the firewall to block traffic from anyone that doesn't need to connect to you. Allow your VoIP provider, any remote phones/users, and others that may need to connect, but keep the restrictions as tight as possible. If you do have remote users, lock your firewall down to only allow those users to connect if possible, rather than opening it to the entire internet. If you have mobile users this may not be an option however.


Open inbound ports only for necessary services. (You do have to open a wide range for RTP streams, but this generally isn't an issue since nothing normally listens within that port range.)
- 22/tcp ssh (for management, of course)
- 4520/udp DUNDi (if you are using DUNDi)
- 4569/tcp IAX2 (if you are using IAX)
- 5060/udp SIP registration
- 10000-20000/udp RTP - media transport
Some devices have a much narrower range of ports they use for RTP streams. For instance certain Cisco (formerly Linksys/Sipura; part numbers begin with PAP, SPA or WRP) devices only use 16384-16482 port range.