VoIP Security

With the rise in VoIP usage, so too comes the rise in security breaches and risks. While the only secure server is one disconnected and buried ten feet into the ground, there are several steps you can take to mitigate the destruction and frequency of these security breaches.

First, we need to go over where most of your "break-ins" occur, and how you ensure that you're doing everything you can to prevent them. We do not attempt to explain how to specifically configure your system and firewall to become immune to security threats. This article is meant to get you looking at these aspects and making sure you're doing everything you can to secure your server.

User Extensions/Resources
One of the more common ways of breaking into a switch is also the simplest; namely, attacking a user extension on the phone system. The 'hacker' somehow gets the username and password of a user/extension on your switch, and begins sending traffic. The most prevalent root cause is insecure passwords. The great thing about SIP user passwords is that you should only need to type it in once (during the customer setup). Using passwords that you can remember is typically not the best thing to do. Especially if the password is the same as, or like the extension or username (for example, extension 1000 has username=1000/password=1000). The best thing to do is use an online random password generator (or let your pet or children walk on the keyboard). Using randomly generated passwords greatly decreases the chance of the password being "guessed" by either a brute force attack or possible social engineering attack.

If you would like to try an online random password generator click here. It would be near impossible for a hacker to guess a password of _Y;`vJGN but fairly easy to "crack" a password set as 1000. That particular online random password generator also allows you to choose between upper case, lower case, numbers, and punctuation which can be helpful if your phone or pbx stipulates what is allowed in passwords. Additionally, you may need to remove or escape certain characters depending on what your system allows, although most modern VoIP phones and switches have allowances for special characters, letters, and numbers. Another way of getting around this issue is to do IP based authentication. It's much harder to correctly "spoof" an IP address to get service than it is to "guess" a username/password combination.
Once you have secured your User Extensions, you will want to regularly review the registration logs. Reviewing registration logs adds a layer of personal security in that you are proactively looking for potential harm. If you see a sizable amount of failed registration attempts coming
 

from a certain IP address, it's best to block that IP address until you've spoken to the customer and confirmed whether those attempts were theirs or not (just because registration is failing repeatedly does not necessarily guarantee a breach). Here is an example of an Asterisk log that would throw a red flag as you manually review them:
[Apr 4 08:04:16] NOTICE[16717] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16651] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16706] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16753] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16735] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16675] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16698] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16722] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16722] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16673] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16673] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16696] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16696] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16737] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16737] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16785] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16708] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16708] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16708] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16708] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16775] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16770] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16770] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16770] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16735] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16727] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16772] chan_iax2.c: No registration for peer 'username' (from ip address)
[Apr 4 08:04:17] NOTICE[16727] chan_iax2.c: No registration for peer 'username' (from ip address)

As you can see, there are repeated attempts to register a peer that are unsuccessful.

Note: an actual Asterisk log will show the username attempting to register as well as the IP address
the registration attempt came from. Unless you are reviewing your logs consistently, you may miss this type of information. If you do discover repeated attempts from the same unauthorized IP address, you should be able to ban that IP address from hitting your system. You could also easily view this information in real time by watching the cli in the Asterisk console. Consult your PBX documentation for specific information regarding your own switch.

Administrative Interfaces and Shell Access
Other areas you will want to lock down are Administrative Interfaces and Shell Access.
 

Administrative interfaces (such as Webmin or FreePBX/Trixbox GUIs) as well as direct shell access (SSH or telnet) are potential security holes that need attention. The easiest way of handling security for these is to block all outside traffic from getting to them (or disable them completely if they're not used). Whether that's through interface binding or firewall/ACL is up to you. Be aware, this can cause issues whenever attempting to manage/fix issues from remote locations but you should be able to work around this by setting up a VPN to your internal network. At the very least, you should block everything except specific IP addresses that you frequently manage your system from into an "allow list." Regardless of whether you are blocking these interfaces, you should also have a secure username/password for everything. These should include the standard uppercase, lowercase, numbers, and symbols. Since you may need to type these in multiple times, it will most likely have to be something that you can recall. Keeping a note on your phone, or a text message with the password (preferably with no label) is more secure than "password123". Additionally, you should guard these passwords by only giving them to those who are required to have them. You would not want to give access to these passwords to anyone in your organization who are not required to have them for operations. Always remember to change these passwords if an employee ends up leaving or is terminated.

Business Fraud
One of the overlooked issues in VoIP comes from actual business fraud. These are companies or people that sign up for service, use it, and file chargebacks or never pay for services rendered. Even the most secure system in the world can still fall prey to someone "skipping out on the bill." The best advice we can offer for this is simply: observe good business practices. Offer prepaid services, or do credit checks for customers asking for terms. There are websites available that have company lists of customers that have outstanding debt that they're refusing to pay, such as http://www.voipfraud.net/. These are typically one-sided accusations, so use caution when reading the claims.

Your Customers
A chain is only as strong as its weakest link. Chances are, if you're actively securing your network, that link is your customer. All the security in the world won't help whenever your customer's extension 100 (password: 100) gets hacked and makes 50 calls to some satellite phone in the pacific at $5/minute. How do you mitigate this security threat? The best advice here is: know what's normal. This involves understanding your customer and being proactive. Does your customer normally call to international destinations? If not, give them routing that prevents them from doing so. If the customer doesn't need to call international destinations, giving them the ability to do so is high risk with no return. If your customer does call international destinations, try to limit the potential risk by only giving them the destinations they need.

Set up their dial plan so that they can call the required destinations but their calls would fail if they dialed areas out of the ordinary. You can always go back and adjust these setting later if you learn they need additional rules set up. Finally, once you learn what is normal for your customer(s), you'll need to know what's going on. Find a way to monitor your traffic always. Creating something that will email you traffic abnormalities, or just something simple like a list of your customers and the number of minutes they've used today will go far in catching security breaches and mitigating their impact on both you and them.

Summary
Security is always in a struggle with convenience. Many changes that make systems more secure also make them less convenient. You'll need to find a happy medium between secure and convenient; always keep in mind what that convenience could cost you. As stated at the outset of this article, even if you take every precaution, your server is still susceptible to attacks. We hope this article helped give you direction to prevent the majority of attacks and mitigate loss if your security does fail for some reason. There are some pentesting (short for "penetration testing") programs and program suites that allow you to test your network and servers (including SIP specific ones) available on the internet. These could help you find exactly where you're most vulnerable and help direct your focus when attempting to secure your network. Using these programs on servers that are not yours can be construed as a break-in attempt; this is at the very least discourteous but could attract legal trouble so be aware.

Once your security is set, knowing what's going on in your network is the next big part of the battle. At the very least, daily reporting on usage will give you an idea of what is going on and will save you a lot of headaches in the future. This usage report does not have to be granular but can be a snapshot to guide you in understanding your security holes. VoIP security must have a proactive approach to be successful.