Taking the threat out of IP voice
- 10 June, 2003 13:48
Once corporate users have tested voice over IP and proven that it works, they face one last hurdle: making sure it's secure.
But users who have taken the plunge into VoIP say they're not worried about security. "If you configure it properly and treat it as you would any other mission-critical server and application on the network, voice over IP is as secure as any other data," says Doug Haluza, director of engineering and new technologies at Lexent, a New York electrical services firm that has run VoIP on its corporate network since January 2002.
Analysts agree, saying that safeguarding VoIP comes down to typical procedures for ensuring the security of networked servers, applications and voice. But, special care is required when choosing firewalls, intrusion-detection systems (IDS) and other security tools.
Firewalls are tricky
Securing VoIP data at the firewall is tricky. VoIP sessions use H.323 or Session Initiation Protocol (SIP). Firewalls in a VoIP deployment must be able to handle these fairly complex real-time communications protocols. H.323 and SIP have separate control and media transfer connections, which means they typically make a connection on one IP port to set up a call and then pick a random, high-numbered IP port, usually above Port 1024, for the data connection. You can't simply configure a firewall with certain ports opened and blocked because the device can never know which port will be used for the connection.
"You need a firewall that understands those protocols well enough to only open data connections when they've been negotiated and authenticated in the control fields," says Mark Kraynak, strategic marketing manager at Check Point Software Technologies Ltd., which markets stateful SIP- and H.323-compliant firewalls. "And it needs to know to close them when (the sessions are) over."
The firewall also has to do all of this stateful packet inspection without affecting the performance of the voice stream.
Based on International Telecommunication Union recommendations, the voice stream should be subject to no more than 100 millisec of delay end to end. Because voice uses smaller packets than data and transmits more packets per second (about 50 packet/sec per voice stream, nearly twice the number of packets in a typical data stream), processing voice can quickly bog down a firewall.
"A lot of software firewalls can meet the demands of data traffic, but when you start to initiate 50 packets per second per call, that really ups the amount of packets they have to inspect and some can't keep up," says John Truetken, senior architect for MCI Advantage, a converged IP service for enterprise users. He says dedicated _pconnect("user=ls tend to perform better.
The same is true of VPNs, he says. "Some low-end VPN encryptors have a problem when you get up to 20 or so voice streams," he says. "The number of packets per second they have to deal with sometimes can overwhelm them."
That's a problem Lexent's Haluza experienced firsthand. The company had implemented an IP Security (IPSec)-based VPN among various sites before deciding to run VoIP over it.
"Initially, we had built up the network with routers at the remote sites and terminated the IPSec tunnels on the firewall at headquarters. We quickly found out that was a dead-end decision for VoIP," he says. The Cisco Systems Inc. PIX firewalls Lexent uses don't have hardware accelerators, only software encryption. "That's no good for voice because there's too much jitter," Haluza says, noting that callers experienced voice dropouts whenever the processor on the firewall became busy.
"The other thing we found out is that we couldn't place calls from remote site to remote site because the firewall wouldn't let the packets in and out through the same port," he says. Lexent got around both problems by terminating the IPSec tunnels on routers at both ends, because the routers had hardware acceleration and could route between the sites. "That way, we get the encryption with high performance," he says.
Safeguarding the server
The VoIP server needs special attention, too. The operating system of most IP PBXs must be stripped of unnecessary services that can lead to security breaches.
"The server should be dedicated to voice serving," says James Coffman, director of architecture and planning for Avaya Inc. Describing Avaya's MultiVantage IP PBX, which runs on a stripped-down version of Linux, he says: "There's no Web browser, no mail reader, no finger daemon. We disable a lot of standard network capabilities that you get on a server out of the box."
Such operating system hardening helps keep the platform safe from viruses and worms, such as the recent Slapper and Nimda exploits. "Some IP telephony core servers were just running plain vanilla Windows NT software, and they got hit by Nimda," says Fred Weiler, director of security solutions marketing at Nortel. "Our platforms are based on embedded NT that's hardened, tested and stripped of unused services, and none of our IP telephony platforms got hit."
All of which points a finger at Cisco, which had some of its NT-based CallManager VoIP servers taking Nimda hits. Cisco quickly issued patches for the systems and also has progressively hardened its platform. The company plans to offer non-NT platform choices by year-end, although it says that if users are diligent about following best practices with vulnerability assessments and patch management, the VoIP server will be no more vulnerable than any other on the network.
Many users dismiss IP PBXs based on Windows, citing security reasons. "When we look at major applications, we take into account whether their platforms attract more viruses or hackers, and I think that Windows is by far the biggest target," says Brian Young, CIO at Hobart and William Smith Colleges in Geneva, N.Y., which is running VoIP on one internal test LAN. "We need to do more for less, and that means having a system that's stable and doesn't take a lot of added security and features to protect it and run it. So for now, we're focusing on Linux and Unix platforms for voice over IP."
But Lexent's Haluza contends the Windows vs. Linux/Unix argument is basically religious. "We pick the best tool, no matter the platform," he says.
Still, he takes precautions, chiefly not exposing his voice server to the Internet. It has a private IP address, and voice traffic travels only on the secure LAN under the VPN, he says. Instead of sending VoIP traffic over the Internet, Lexent buys voice links from a single carrier to handle traffic beyond the LAN.
"From our company out, we use traditional ISDN (Primary Rate Interface) voice circuits, but we terminate the PRI circuit from the carrier on the router, and then it's IP on our LAN side,"Haluza says.
Some start-ups are beginning to address the Internet security issue, primarily through firewall technology (see story, below).
A voice-specific IDS can provide more VoIP server protection, yet users say such devices aren't ready for deployment yet. "I won't bring VoIP into production at the school until we have some kind of voice-specific IDS in place, and we haven't seen that many so far," Hobart and William Smith's Young says.
MCI's Truetken explains that most IDSs are hamstrung by their propensity for false alarms, a factor that might inhibit their performance, especially in a voice environment. "You'd have to set their thresholds higher to accommodate the higher number of packets for voice," he says. "Otherwise, you'll just have limitless false positives."
Cisco says it has solved this problem through technology gained in two recent acquisitions. From Psionic, it gained the ability to automate alarm investigation, and from Okena, intrusion prevention and detection.
Eavesdropping is overblown
Another consideration is securing the application so that a hacker can't eavesdrop on a voice call or hijack voice service. One way to avoid eavesdropping is to encrypt the call, which current VPN technology easily handles. However, be sure that the end device has the processing power to support a VPN client. Many IP phones don't have that power, Avaya's Coffman notes.
In such cases, a user would implement a VPN client on a workstation or laptop and connect the phone to the PC. "That works, but you need to ensure that the laptop doesn't interfere with the VoIP call," Truetken says. "If it's running XP, you're probably fine. But if it's Windows 98, you can run into problems. For example, DSL has 256K bits per second of bandwidth, which is fine to support a voice call. But if you're running Outlook at the same time, you can run out of processing power."
Others question the necessity of encrypting VoIP over the LAN at all. "The need to encrypt here is not that huge," Young says. "Just look at how many people use cell phones today, and they're far easier to capture and listen in on than a VoIP voice stream. It's not a priority."
Lexent's Haluza agrees. "I'm more worried about people getting into back-office applications than VoIP," he says. "It's a case of overblown risk."