Breaking Through IP Telephony

Network World - Editor's note: This review originally ran in Network World in May 2004.
Can you hacker-proof your IP telephony network? The short answer -- as demonstrated in the first-ever public test on this topic -- is, yes, pretty much. But it strongly depends on whose IP PBX you use, and more important, whether you're willing to spend the dollars and the time it takes in terms of network security planning, network and personnel resources, and extra security gear.
In our tests, we developed a plan for realistically assessing how secure vendors' IP telephony packages are -- or aren't -- against a determined, malicious attacker. We invited the top five vendors by VoIP market share to participate, but only Cisco and Avaya stepped up to the challenge.
Cisco's "maximum-security" VoIP configuration -- a midsize CallManager-based system, with call control, voice mail, gateway; a Catalyst 4500- and 6500-based Layer 2/Layer 3 infrastructure; a copious supply of intrusion-detection system (IDS) and PIX firewall security add-ons; plus a half-dozen Cisco security gurus supporting the test -- earned our highest rating, Secure (see rating criteria, QuickLink 51591). Our attack team couldn't disrupt, or even disturb, Cisco's phone operations after three days of trying.
Avaya submitted two configurations: A no-frills, out-of-the-box Avaya IP telephony deployment with no extra-priced security options; and a maximum-security alternative featuring the same VoIP gear but with an added firewall and Layer 2/Layer 3 infrastructure switches from Extreme Networks. Security weaknesses earned the basic Avaya configuration a so-so Vulnerable rating, while the hardened package fared better with an overall rating of Resistant.
The ground rules (see QuickLink 51592) imposed some limitations on the four-member assault team. For example, only hacker tools and attacks that were available on the Internet could be used. Attacks had to be launched via an end-user data port or IP phone connection, as if the hacker had access to a standard office cube; attackers could not disassemble or dissect the vendor's IP phone, and so on.
The objective was to disrupt phone communications. Via the data and IP phone connections, the attack team used scanning tools and other techniques to see and learn what they could of the topology. The attack team was told nothing of the vendor's configuration beforehand. After discerning and identifying "targets," the hackers then systematically launched dozens of attacks, at times in combinations concurrently.
Given the limits set by our ground rules and the duration of the tests, it's important to note that the attacks launched against these products were not as severe as those