The VoIP Addict’s Guide – VoIP Security Fact and Fiction

VoIP security is a hot topic, and rightfully so. A compromised system can cost you $$$ in phone bills, so how do you prevent a breach? Well, the answer isn’t as complicated as you’d expect. There are a lot of opinions floating around on the subject, so let me address some truths and falsehoods that may be of importance when securing your VoIP system.

Fiction: You NEED a session border controller (SBC)

If you are a small business or are installing a VoIP system in your home, there is no need for an SBC. An SBC is a great device (or virtual appliance) because it masquerades your internal VoIP infrastructure. In basic terms, a SIP trunk from a provider terminates to the SBC, which then connects to your phone system via a SIP trunk.  The SBC acts as the middleman in the transaction. To an outsider, SIP header information sources from the SBC and not your internal equipment. Although an SBC is a great extra layer of security and reduces overall attack vectors, it’s not required to make VoIP reliably secure for the majority of small deployments. Terminating a SIP trunk directly to your phone system behind a hardware-based or virtual firewall provides the security that would be deemed required to keep you incurring fraudulent toll charges.

Fact: You NEED a firewall

On the same topic as above, if you are going to be using SIP trunks to talk to the outside world, you’ll need a hardware or virtual firewall appliance to secure what is allowed in and out. In addition to the basics of protecting SSH, Telnet, and HTTP/HTTPS access to your phone system, you should always restrict what IP addresses can communicate directly to the phone system when it comes to SIP, and IAX (if you use it). What that means is only allowing IP addresses from your SIP provider, any remote extensions, or remote branches. Never ever expose your system directly to the internet without some type of firewall in front of it.

Fiction: Remote extensions MUST use a VPN

This is not true but isn’t a bad idea. A VPN will allow you to bypass NAT, which is the culprit in most one-way audio issues. The trick here is to tell the phone system all of the local IP subnets that it will be talking SIP. You’ll find this to be configurable on just about every Asterisk based phone system. A VPN also allows you to encrypt your session if you’re worried about the NSA listening in. An alternative would be using TLS and SRTP without a VPN, but you’ll just lose the benefit of avoiding NAT. The best way to securely deploy remote extensions is to use either a VPN or TLS. If you’re not using a VPN, make sure to define your inside IP subnets (as mentioned before), as well as your external IP address. These are all also configurable on just about any Asterisk system. Make sure you port forward SIP and RTP in your firewall to your phone system and secure your inbound rules by source IP addresses. Every system is a little different, but most Asterisk systems use 5060 UDP (SIP), and 10000-20000 UDP (RTP).

Fact: VoIP is NOT set it and forget it technology

If you’re going to take on the task of managing an IP phone system in your IT infrastructure, you need to adopt the mindset of monitoring it. Especially if you have port 5060 open to the outside world, you need to be logging and enabling alerts. In the past, phone systems have been bolted to a wall in a closet that no one ever went into except the PBX vendor. Now your system is racked next to your switches and servers. For those of you who are FreePBX users, Sangoma has just started to release their RMS platform, which simplifies centralized remote monitoring of multiple FreePBX and PBXAct systems. Stay tuned for a review on this!

Fiction: Not using port forwarding makes your phone system more secure

This isn’t actually a common belief, but it comes from a post I recently read on Spiceworks. It was claimed that a system has been made more secure by not forwarding port 5060 UDP from the firewall to the actual PBX. If this configuration was actually working, it was a minor miracle. The fact is there are usually two components of sending SIP traffic through your firewall. There is a firewall rule, allowing the traffic, and a fixed NAT association with the protocol and a device within your network. As long as you’ve made appropriate rules allowing SIP to your system, the port forwarding is simply a mechanism to help keep consistent NAT associations. In general, SIP and NAT do not play well with each other. Pro TIP: when you experience one-way audio, always look at NAT first.

Fact: You do not need to restrict RTP traffic to specific source IP addresses

I bet you never thought of this one. If you have, bonus points. While you should ALWAYS restrict SIP traffic by source IP address, it’s not necessary to do so with RTP. RTP is simply a media stream and doesn’t have the capability of initiating a SIP session, or any kind of session. Dare I say, you can leave the RTP port range open on your firewall. However, it doesn’t really hurt anything to place a source IP restriction on it.