Is Your VoIP Phone System a Security Risk?

Updated: August 25, 2012

1. Internet telephony MUST be part of an overall information systems security policy and plan. There is an old saying: "If you don't know where you're going, any road will take you there." That is especially true when it comes to anticipating threats and protecting information systems. If your organization does not have an information systems security policy, you need to create one. This policy identifies what is being protected (e.g., financial information, trade secrets, personnel records, regulatory requirements, potential insider trading information, etc.), from whom it is being protected (internal or external miscreants) and how much it is worth to protect it.

With the answers to these questions as a base, your company can create policies that determine how systems are to be deployed, who can access them, how they can be accessed (i.e., internal only, remotely), when they can be accessed and so forth. Once the policy is created, your organization can then develop a plan that identifies the specific components that are to be used to implement the policy, and the procedures that are required to continually safeguard the organization's intellectual property. Implementing firewalls, access control lists, or other tools without a carefully considered policy and overarching plan is worse than no plan at all because it can create a false sense of confidence. Internet telephony brings its own unique set of threats and must be fully incorporated into the overall information systems security policy and plan.

2. Start from the ground up: Is the server platform housing your Internet telephony system properly hardened? Internet telephony solutions — hosted or premise-based IP PBX systems — are nothing more than complex computer applications that ride on top of a server such as a UNIX, Linux or Windows platform. One of the most common mistakes is failing to "harden" the underlying platform before loading the Internet telephony application on top of it, thus leaving security holes and potential attack vectors.

Make sure that the servers hosting your IP telephony services have been stripped down to bare bones, eliminating all unnecessary tools and applications, before they are rebuilt to house only those functions needed for your requirements. All too often, default passwords, anonymous FTP or other such avenues for attack go unnoticed.

3. Ensure that bug fixes and patches to the server operating system are implemented in a timely fashion. This may seem obvious but represents one of the easiest vectors of attack for intruders. Vulnerabilities are identified and patched for all operating systems on an almost daily basis. Unfortunately, many systems administrators may be too busy or delay implementing these patches. Hackers can read the same notices as system administrators and simply look for sites where the fixes have been tardy. Security Focus is one source for staying up to date on threats to your specific operating systems.

4. Ensure that bug fixes and patches to the Internet telephony software are also implemented in a timely fashion. As mentioned previously, IP telephony is an application that runs on a server. As such, Internet telephony systems must be monitored and when bugs or vulnerabilities are identified, these issues should be immediately addressed. For example, as reported on December 2, 2009, the RTP (Real-Time Protocol) comfort noise processing function in Asterisk systems is vulnerable to remote DoS (Denial of Service) attacks because they improperly handle these packets. There are solutions available, but administrators must first be aware of the vulnerabilities and then promptly patch them. All systems have occasional bugs or vulnerabilities. If you think that your system is impervious, please think again.

5. Make sure the remote admin function is properly secured to avoid unauthorized access. Most operating systems and applications such as Internet telephony are shipped with remote access for systems administrators. This is both a useful function for corporate administrators that are not collocated with servers or for contracted technical experts. Unfortunately, it also represents an attack vector that is often overlooked.

For example, Sun initially shipped its Solaris UNIX-based operating system with its SNMP (Simple Network Monitoring Protocol), DMI (Desktop Management Interface), and the sadmind (Distributed System Administrator Daemon) features active. SNMP has known vulnerabilities, especially in a Sun environment, that require patching before going live. In addition, strong passwords are critical to protecting the remote admin function and should be changed on a regular basis. This may seem a "blinding flash of the obvious," but also make sure all access passwords are changed when your system administrators leave the organization! For larger organizations, there are even stronger methods of protection, including two-factor authentication.

6. Create a baseline and then monitor the systems to identify anomalous activity. This is one of the basic principles for any information systems security plan. It is important to record a baseline of activity so that the systems administrator becomes aware when deviations have occurred within your Internet telephony environment.

For example, calling patterns for most businesses will be relatively regular. Usage will start to ramp up in the morning and then tail off until a similar "busy hour" occurs during the afternoon. High volumes of calling traffic are not normal during evenings or weekends. Should the monitors detect such anomalous activity, the administrator can immediately investigate to determine if the traffic is legitimate or a symptom of an attack. Without a baseline (and one that changes with company activities, such as adding employees, opening new branches, introducing new services, etc.), it may be impossible to detect unusual activity before it is too late.

7. Protect the telephones, too. IP telephones are not really "telephones" as in the past but rather small computers that have password access. Are your telephone instrument passwords sufficiently strong? Are they changed on a regular basis? These telephones themselves can be the targets of attack such as the Grandstream HandyTone-488 in the past. Because the instrument performed insufficient checks on user data, it was vulnerable to crashing from attackers causing a denial of service (DoS) condition for that individual phone.

8. Implement active protections. Measures such as Intrusion Detection Systems (IDSs) and Intrusion Prevention Systems (IPSs) trigger alerts when suspicious activity occurs. There are several forms of IDS and IPS. These include those that are network-based (NIDS), host-based (HIDS), and applications-specific. There are a variety of good NIDS available for free such as Snort and Sax2 (www.ids-sax2.com). You may also want to ask your IP PBX provider about an IDS specific to their application. These tools will help you become aware as soon as a threat has occurred and respond appropriately before significant damage has been done.

9. Identify and educate personnel or areas within the company that utilize sensitive information and need to ensure confidentiality, authenticity, and message integrity. As part of the policy and plan, it is important to identify how much effort is worthwhile regarding voice confidentiality. Some users, such as executives, finance, or regulatory compliance personnel, may be engaging in voice communications that must be protected. This includes standard telephone calls using an IP PBX but it may also include using a "softphone" on a computer, a VoIP application on a smartphone, or even a standard cell phone.

A basic component of your Internet security policy and plan is education of your users regarding potential risks, followed by enforcement steps defined in your plan. Do we allow the use of Skype within the company network? Do we allow personnel to install softphones on their laptops and use them outside of the company LAN?

There is much to consider when preparing your policies and plans. Social engineering is one of the easiest forms of attack. Unscrupulous people frequently capture information needed to launch attacks just by asking or finding access information that has not been properly secured. The movie "Wargames" showed a perfect example where a written list of passwords was kept in an insecure location. Anyone could find that information and have free reign to enter systems and do whatever they wanted. Tools available to the bad guys have become much more sophisticated, and the best way to combat security breaches in an Internet telephony system is by making your users aware of their responsibilities.

Passwords for company resources should not be stored in laptops. Anyone stealing a laptop may then be able to bring up an application and, if the password has been saved for convenience, can steal, compromise, or delete information resources. If a softphone or IP telephone is compromised, intruders can place calls and run up large bills (toll fraud). Personnel must be taught about the importance of strong passwords and how not to inadvertently share them with unauthorized people. Systems can be implemented that automate much of these functions but nothing prevents giving out a legitimate password to a potential hacker other than education.

10. Implement an IP-enabled firewall. Firewalls are traditionally part of a network security plan. Unfortunately, most firewalls are not designed for Session Initiation Protocol (SIP) or the nuances of IP telephony. This may result in ports remaining open and offering an entry point into a network for attackers. Network Address Translation (NAT) and traditional firewalls may also create interoperability problems with some IP PBX systems. SIP-aware or IP-enabled firewalls or VoIP security controllers are available from companies such as InGate (www.ingate.com), UM Labs (www.um-labs.com), and others. In addition to providing an elegant and protected path for Internet telephony, these systems also can help resolve interoperability and quality of service challenges.