Primer

VoIP security primer

The issue of VoIP security is, in some ways, a sleeper issue: compared to the problems of botnets and malware, it has a low profile. Only when a story about breaches grabs headlines do people think more generally about whether their VoIP environment is secure.

In the coming weeks, SearchSecurity ANZ will look in greater detail at discrete parts of the VoIP environment, and where security might need to be tightened, but this week, let’s start with a VoIP security primer.

To start looking at VoIP security, you first need to understand the components of your VoIP system. Each of these is visible in some way to your data network, and that means if someone can compromise the data network, your VoIP system is also exposed.

The basic components of the business VoIP system are:

  1. The LAN – since your VoIP environment is on the LAN, that’s where security has to start. If your LAN isn’t protected against external threats, securing the VoIP system will be that much more difficult.
  2. The VoIP phones.
  3. The VoIP server.
  4. Supporting applications – for example, the unified communications system that integrates your VoIP server with your Outlook address book.
  5. The VoIP provider connection.

Today, we’ll focus on the outlining the first three of these. This isn’t the place

Requires Free Membership to View

for a full primer on LAN security, but there is one aspect that is directly associated with overall VoIP security: the way your firewall handles requests to Port 5060.

The reason I’m highlighting this one is that it’s the entry-point for the kinds of attacks that have become recent news (such as the company in Perth reported to have lost $12,000 in stolen phone calls).

The SANS Institute last month reported a rise in attempts to make UDP connections over port 5060. “This port is typically used for connections using the SIP protocol. The activity is indicative of attempts to locate weakly-configured IP PBX systems, probably to brute-force SIP passwords.”

There are two points to make here.

The first goes to how you are using your VoIP system. If, like most Australian companies, the VoIP system is a simple PSTN replacement system, you should ask yourself who the VoIP server needs to communicate with.

Imagine, for example, that you’re using a system like Internode’s Nodefone, and that’s the only service you connect to. Your calls should all be coming from one place only – the Nodefone address that your VoIP server logs into. If another IP address tries to tap on Port 5060 to see if anybody’s home, your firewall can ignore it.

So the core question your firewall has to answer is “who needs access to Port 5060”?

VoIP phones

As you might have noticed, the VoIP phone is far removed from the PBX phone: it has much more processing power, and that processing power is used to run applications.

For example, most VoIP phones have a built-in micro Web server providing the admin interface; many of them have call recording capabilities; lots of them have phone books either as standalone applications or as something designed to integrate with other systems; and many can be remote controlled (for example, allowing you to make hands-free calls from your computer’s address book).

Each of these features is, in its own way, a vulnerability.

Take the remote control capability, for example. If an attacker has penetrated your network, the phones are exposed. If they’re unprotected, the attacker doesn’t need to compromise the VoIP server to make calls: he or she need only start telling the phones.

So to protect the phones, you need at least a strong password on the Web server; you need to lock down the phone’s configuration capabilities; the phone should probably only accept commands from authorized machines; and a strong password should be required to access the address book.

The VoIP server

The problem with a weakly-secured VoIP server is simple: once it’s presented its credentials to your VoIP provider, it’s trusted to make phone calls.

It may sound obvious, but you should not leave the VoIP server using its default password.

The problem is that the first thing anyone wants to know when they’re configuring a VoIP server is “is it working?” Instead of changing the password as soon as the server it live, people tend to leave it with a weak password during configuration to make it easy to test – and they forget to come back and change the password later.

Worse, they decide that since the VoIP server is behind a firewall, it doesn’t need to be configured for good security.

At the very least, both the VoIP software and the server platform should be protected.

Remember that if someone has access to the VoIP server, they don’t just get the ability to make phone calls. They can also read the server logs (which records the details of calls in and out), access any recordings made by the server (as distinct from those that may be made by the phones), make configuration changes and plenty more.

If the VoIP system is one that stores its passwords as clear text, someone with access to the server can also get the passwords the server presents to your VoIP provider.

The underlying problem is that VoIP is much more than just a telephone: it’s become a fully-featured – and extensible – set of applications that touches many parts of your network and your business.

As is so often the case, the “most secure” way to run a VoIP server is also the least attractive. You could put it on a secured Ethernet virtual LAN, so that only the phones can talk to the server and only the server can talk to the phones.

That’s much more secure, much less convenient, and much less functional. To preserve the convenience and power of a business VoIP system, you need instead to try to solve the challenges of VoIP security.

This was first published in October 2010

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.