Data security in a converged network: Part 2
By Joel A. Pogar, Siemens Information and Communication Networks Inc.
JULY 23, 2003

In Part 1 of this series, I introduced some of the fundamental security issues of voice over Internet Protocol (VOIP) (see story). In this installment, I examine some of the specific issues of IP phones and their effect on enterprise firewalls.
Do the endpoints, or IP phones, have any specific vulnerabilities to be aware of?

Such phones are intelligent devices with a processor, memory, an operating system and communication capability. The good news is that they have a relatively limited input scheme from the 12-position touch pad for dialing and a few programmable buttons.

The most significant vulnerability, and this varies by vendor, is the ability to reset the IP phone to factory defaults via a reset button or function. When the device is reset, some vendors provide a greater level of access to the VOIP system for when the phone was configured for the first time. A malicious user could compromise or reset administrator-level passwords during the configuration process. The best solution is to limit the deployment of IP phones in public environments such as lobbies or public phone banks. Also, ensure that phones used in these locations can't be reset. Other than this small possibility, the IP phones of today don't represent a significant security threat. As the phones get more intelligent, this may change.

Is it easy to intercept or monitor a VOIP conversation?

It's not that difficult, considering that most of the tools used are available for free download on the Internet. Consider the following hypothetical scenario: An attacker who has physical access to the LAN, such as an employee, could plug into the network and identify a target phone he wanted to monitor. With a network monitoring tool, such as tcpdump, it would be easy to identify the IP and Media Access Control address of the phone to be attacked.

By using an Address Resolution Protocol (ARP) spoofing tool, the attacker could impersonate the local gateway and the IP phone on the network. This would allow IP traffic to and from the target IP phone to be monitored by the attacking workstation. FragRouter or IP forwarding would have to be enabled on the attacking machine so the data packets could reach their ultimate destination. Next, using tcpdump again, the attacker could capture VOIP packets and save them to a file. Once the attacker has captured the amount of data desired, it can be played back using one of the more popular tools, such as Vomit (voice over misconfigured Internet telephones), and the appropriate codec (audio coder/decoder).

This example represents a simplified scenario, but it would work. The risk of experiencing this attack is somewhat limited because it would require physical access to the local network or remote access to a compromised host on the local network. In addition, ARP spoofing doesn't work across the Internet or on a WAN.

What tools are available to monitor or manage the security of a VOIP environment?

VOIP is just now becoming a mainstream technology. Many of the available VOIP tools are designed for performance management and enhancement, not security. Since VOIP isn't a unique vulnerability in a data environment, traditional data security tools would be sufficient to monitor and manage your VOIP network. Some components, such as intrusion-detection systems, may have specific tuning needs, but they should still be effective.

Can my firewall/Network Address Translation (NAT) infrastructure handle VOIP traffic?

First of all, you will need to examine the topology of your network. Most VOIP traffic, except for virtual private networks, doesn't traverse a public network such as the Internet. The availability and use of the Internet as a carrier for VOIP isn't a reality today. This can and most certainly will change in the future as the technologies evolve and mature.

If your environment has layers of internal firewalls between networks and VOIP will traverse these devices, it's doubtful your firewall can efficiently support VOIP traffic. Most conventional firewalls today can't natively support Session Initiation Protocol (SIP) or H.323, the two primary VOIP protocols. Native support doesn't mean opening the ports that SIP or H.323 would use. Native support means the firewall has a predefined service type for VOIP and the capability to open and inspect these packets. While there are some commercial firewalls capable of doing this, this feature isn't yet pervasive in the firewall industry.

A second problem with conventional firewalls is their inability to efficiently handle large amounts of small packets. Most VOIP traffic consists of large amounts of small data packets. On average, VOIP conversations generate 70 to 210 packets per second and packets that are 50 to 200 bytes in size. If this were a file transfer protocol download, the network could handle the same volume of data content in fewer, larger packets, yielding much less information for the firewall to inspect.

A good analogy for this concept is a shipyard. If you had 100 crates to inspect and ship, would you rather put them on a single boat that can handle all 100 crates, or would you want to put them on 10 boats that can handle only 10 crates each? It would obviously take more work and effort to ship your crates on 10 different boats. The small packet size allows low latency and better performance for the VOIP system but not for the firewall, which is used to handling larger ships. Because firewalls can't efficiently handle large amounts of small packets, the throughput capability of the firewall begins to degrade, along with the quality of service. Therefore, the voice conversation may begin to falter or other data traffic will be delayed or dropped, based on a variety of configuration options in your network.

Finally, most firewalls use some type of NAT to conserve IP address space. However, many VOIP systems won't work properly with complex NAT environments. Depending on the firewall vendor and product, some NAT implementations embed IP address information in the payload portion of the packet. When the VOIP system receives the IP address data instead of voice data, it doesn't know how to handle it. Thus, another opportunity for a dropped call, poor voice quality or the complete inability to make a call on a VOIP system due to firewall or NAT problems.

If firewalls can't efficiently handle voice traffic today, what technology should I have at my network perimeter?

For security and performance issues, it's best to offload your real-time or VOIP protocols from your data network. If your VOIP data is going to traverse a public network, I recommend using a reverse proxy or multimedia gateway designed to handle real-time communications. There are several vendors now making these gateways to act as firewalls. They offer the advantage of better security for real-time communications and the performance to handle large amounts of small packets.

Joel A. Pogar is national practice manager, Information Security, Siemens Information and Communication Networks Inc.

CW Part2