42 IT Pro September ❘ October 2007 1520-9202/07/$25.00 © 2007 IEEEP u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

V O I P N E T W O R K S E C U R I T Y

Strategies to KeepYour VoIP NetworkSecure

Wesley Chou

A s VoIP technology matures, more ITdepartments have made the jump tointegrate VoIP into their enterprisecommunication systems.But,before an

organization fully commits to the technology, itshould perform a risk assessment, paying closeattention to any security measures needed to pro-tect these IP-based voice networks.For telephonesystems where controlled access throughout thecommunications infrastructure isn’t necessary,services that leverage machines on the publicInternet could be a cost-effective choice.However, for systems where secured networkcontrol is critical,VoIP networks based on privateenterprise infrastructures should be considered.

This article focuses on the security measuresassociated with private-enterprise-based VoIPnetworks. (See the “Skype—An Example PublicInternet-Based VoIP” sidebar for a short discus-sion on the issues associated with using publicInternet-based VoIP service providers.) Certainmeasures extend traditional network securitypractices. Other measures address specific vul-nerabilities unique to the VoIP realm.

VOIP INFRASTRUCTUREVoIP is simply application

traffic over the IP-based Inter-net. However, by understandinghow to address the securityissues involved in a voice net-work, you can perform any pro-tective measures and proce-dures prior to embarking on alarge-scale deployment.

A VoIP network has its own infrastructure for traf-fic control and management. Figure 1 (on page 44)shows a simple VoIP network’s components.The firstcomponent is the IP phone itself.The second com-ponent is a call session manager that runs one of theVoIP signaling protocols.The two standards-basedprotocols used in the enterprise network space areSession Initiation Protocol (SIP) defined by theInternet community; and H.323, defined by thetelecommunications community. (Skype and otherpublic Internet-based VoIP providers typically useproprietary signaling and messaging protocols.) Thesession manager handles call control and manage-ment, including its setup and tear down.The thirdcomponent,an authentication server,authenticatessystem users.The fourth component—required if theIP network is to interact with a traditional publicswitched telephone network—is a gateway to con-vert VoIP data into traditional phone signals.Although such gateways are often simple protocoltranslators,some might require controllers to admin-istrate calls. Each component in the VoIP networkhas its own vulnerabilities.

Beyond the network infrastructure, VoIP traf-fic itself is an application that needs security. Notonly does the voice stream need protection fromeavesdroppers, but the voice mail database needsto be secured and the gateways must be moni-tored to prevent toll fraud.

Thus,vulnerabilities faced by the VoIP networkcan be categorized as those related to the

• VoIP-specific network infrastructure,• VoIP-specific application, and• underlying IP network.

VoIP enterprise deploymentsneed strategies to help providea balance between security andease of use.

Skype—An ExamplePublic Internet-

Based VoIP

Further Reading

Inside

September ❘ October 2007 IT Pro 43

VOIP NETWORK INFRASTRUCTUREVULNERABILITIES

From a network layer perspective, a VoIPinfrastructure is just a data network with a par-ticular type of application traffic. Thus, stan-dard data encryption and authenticationtechniques apply. However, relying on preex-isting mechanisms is not enough. Administra-tors need to address a VoIP network’s specificcomponents and unique network designs.

Issue: standard VoIP signaling protocols might be incompatiblewith existing firewalls

A VoIP call using SIP and H.323 is initiatedin two phases: a call setup, or signaling phase,and the voice call itself. The signaling phaselocates the intended callee, negotiates callparameters, and dynamically allocates IP portsfor the call’s voice portion.

Consequently, it is only at this point that VoIPendpoints are aware of the IP ports they willuse to communicate. However, firewalls onlyallow specific, known port traffic to pass. So,unless the firewall is aware of the ports thatshould be allowed through, it will block thevoice traffic.Strategy 1: use firewalls that recognize signal-ing protocols. A firewall with the ability tounderstand and interpret the signaling proto-cols would recognize voice traffic and allow it to pass. The firewall can then parse any sig-naling control messages and extract the appropriate ports. All major vendors offerenterprise-class firewalls capable of parsingVoIP signaling protocols. However, a softwareupgrade might be required or a license paid togain this functionality.Strategy 2: use a proxy server to send and for-ward VoIP traffic. Instead of an end-to-endconnection, a voice call can pass through aproxy server sitting outside the secure regionof both caller and callee firewalls. Each fire-wall-protected user can then connect to thisproxy server and send all voice calls throughthe server. It’s imperative that the proxyserver itself is secured, as it sits outside thefirewall. This is an appropriate approach fororganizations with firewalls that can’t beupgraded to VoIP protocol aware, or if theorganization doesn’t wish to modify orupgrade its firewalls. This approach woulddeviate from models using SIP or H.323because they don’t follow the proxy-servermodel.

Enterprise-level VoIP systems in use today predominantly useinfrastructures based on Session Initiation Protocol (SIP) orH.323. However, small organizations might find public Internet-based VoIP systems, such as Skype (see http://www.skype.com/security/guide-for-network-admins.pdf), useful without havingto use a dedicated IT environment.

Skype is a software-based solution that, when installed, makesthe host machine a softphone.The Skype software performs dis-covery techniques to determine if the host is behind a firewalland/or a network address translation (NAT) device. Even if oneof these is the case, the host can still initiate and receive calls (seehttp://www.cs.columbia.edu/techreports/cucs-039-04.pdf).

Skype security is thorough in the respect that it uses standard,acknowledged encryption protocols to protect the data stream.However, in terms of secure use within an enterprise network,you need to consider a few issues.

Skype relies on the entire Internet, not a corporate intranet,for efficient use. It uses a network of supernodes, all runningSkype, which can act as proxy servers for hosts that are behindfirewalls. Note that any host running Skype can be promoted tosupernode status without prompting the user. While this allowsfor efficient use of the Internet’s bandwidth and processing power,it implies that a voice call can go through an unpredictable anddynamic path and through an insecure, uncontrolled proxy server.In addition, if an enterprise does not use a firewall itself, it couldfind that all of the hosts with Skype have become supernodes.

Skype as a host program scans ports and IP addresses to iden-tify if it’s behind a firewall or NAT devices. Although its inten-tions are benign, this action deliberately attempts to punch holesthrough firewalls intended to provide network security.Attackerscould exploit these holes.

As a proprietary protocol, it’s difficult to determine with cer-tainty what is going on behind the scenes. It’s true that publicprotocols such as SIP and H.323 have the drawback of being tooopen and thus vulnerable to attack. However, hosts runningSkype should treat the software like an OS and aggressively applyany security patches (see http://www.eWEEK.com/article2/0,1895, 1877000,00.asp).

As noted in the main portion of this article, the use of soft-phones prevents the best practice segregation of the voice anddata networks.

With its ease of use and quick installation, Skype can providea cost-effective solution for a small enterprise that is primarilyconcerned with the call integrity and has no need to secure alarge enterprise network. However, enterprises requiring totalcontrol and administration of its network might find it a lessdesirable choice.

Skype–An Example PublicInternet-Based VoIP Service

Provider

44 IT Pro September ❘ October 2007

V O I P N E T W O R K S E C U R I T Y

Issue: vulnerabilities of processing VoIP signaling protocols

There is a twist to the aforementioned practice of usinga firewall that understands VoIP signaling protocols. Sinceboth SIP and H.323 are published, well-documented stan-dards, some attacks might be generated with the intent ofidentifying and exploiting common errors in a protocolimplementation.Armed with public and well-defined mes-sage formats, attackers can generate malformed messagesin an attempt to disrupt a signaling device. In fact, a studyperformed by the University of Oulu, Finland, on VoIPsignaling products found that almost all vendors’ productshad vulnerabilities in their mechanisms to parse the well-known protocol packets (see http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/).Strategy: keep firewalls up to date with security patchesand upgrades.After the University of Oulu study, all ven-dors immediately responded with security patches to closesystem holes. IT staff should perform benchmarks and neg-ative tests on VoIP-protocol-aware firewalls to ensure thatthey have the most up-to-date patches.

Issue: vulnerabilities due to PC-based controllers and gateways

Most traditional network devices either run a propri-etary OS or a standard, real-time OS that is less scrutinizedthan the widespread OSs found on PCs. In a VoIP deploy-ment however, the gateway and controller components

frequently run on PCs with well-known OSs.An attackerwho has learned the IP address of the signaling controldevice or gateway might target it with a virus that couldeffectively halt all VoIP calls on the network.Strategy: vigilance in keeping antivirus and antimalwarecurrent. The best practice of keeping the most recentantivirus and antimalware software on such managementworkstations is the same as general workstation security.In other words, standard techniques—such as monitoringuser logins, keeping up to date with OS security patches,and restricting system access—should be employed.

Issue: increase in network accessibilityOne obvious component of network security is physi-

cal accessibility to the network.Although the actual net-work equipment in a data center can be secured in aprotected room or even a cage, the various wall jacks tothat central location need to spread freely throughout anenterprise campus. Each jack represents another entrypoint to the entire network.When deploying desktops orstationary workstations, physical access to the data net-work can be controlled by restricting the number of walljacks enabled.A VoIP deployment dramatically increasesthe number of such active ports. At a minimum, assum-ing at least one IP phone per desk, the number of activeports doubles. Even if there is not an IP phone at everydesk, the active port number is likely to increase. Afterall, one of the advantages of IP phone deployments isthat the phone can be located anywhere on the networkwhile the phone number stays the same. To accommo-date this feature, almost all wall jacks to the VoIP net-work should be enabled.This means the sudden creationof many more entry points to the network exposed topotentially malicious attacks. The use of wireless IPphones might reduce the requirement of enabled physi-cal jacks. However, the basic concept is still the same.Any security policy that attempts to control or limitaccess to the network will need modification to allownew devices access.Strategy: harden the IP phone. If the network is hardenedso that it performs access control before allowing a deviceonto the network, then the risk of having live wall jacks isreduced.A hardened IP phone contains a security certifi-cate that validates the phone’s integrity and ensures thatonly trusted devices have network access. For scaling pur-poses, it’s imperative to implement such hardening effortsprior to widespread IP phone deployment.

Issue: voice and data network crossover access

If voice and data networks share subnets, then the vul-nerability of open ports applies to both the voice and datanetwork. In other words, if intruders gain access to thevoice network, then they have by default gained access tothe data network.

Public switchedtelephonenetwork

IPnetwork

PBXgateway

Gatewaycontroller

IP phone IP phone

Callmanager

Authenticationserver

Figure 1. Components of a simple VoIP network.

September ❘ October 2007 IT Pro 45

Strategy: segregate data and voice networks. A good prac-tice is to segregate the data and voice networks so theyexist on different IP subnets. In this case, an increase innetwork accessibility is isolated to the voice networkalone.Thus, an attack on one network does not necessar-ily result in an attack on the other network.

Issue: softphone weaknessesSoftphones, another major attraction of VoIP technol-

ogy, are software solutions that run on standard PCs tomake those PCs act like an IP phone.

Similar to issues faced by hardwired IP phones and net-work-based firewalls, a softphone operation might not becompatible with traditional software-based firewalls run-ning on the same host. In addition, like VoIP controllersand gateways, softphones are software applications thatreside on a PC host and are thus subject to the same vul-nerabilities as that host. I’ve addressed these two issuespreviously; however, an additional problem faced by soft-phones is the difficulty in segregating softphone voice traf-fic from the data traffic. With a softphone, the voicenetwork must share the same subnet as the data traffic.Consequently, any attack to the voice network can poten-tially cause disruptions to the data network and vice versa.Strategy: use softphones only in select environments. Toprotect against unauthorized host access to the network,a VoIP network can require that specific softphoneinstances access the network from registered PCs. Theassumption is that a registered PC can be more diligentlyprotected from OS or application viruses. However, theproblems involving lack of network segregation aren’t easily avoided. In fact, the National Institute of Scienceand Technology recommends disabling softphones (seehttp://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf).

VOIP APPLICATION VULNERABILITIESAside from the network infrastructure component of

VoIP deployments, you must remember that VoIP itselfis an application. Not only is a VoIP network attractiveto an attacker whose mission is to disrupt network oper-ations, but it’s also an attractive target to an intruder hop-ing for personal gain, such as access to voice mail ortoll-free calling. Thus, VoIP security encompasses boththe network domain as well as the host applicationdomain.

Issue: toll fraud and voice mail accessThe lure of toll-free calls can motivate an intruder to

hack into the gateway controller. Once inside, the hackerwill then initiate and authorize long distance calls.

The digital voice mail repository sitting on the VoIP net-work is another target that intruders might find too tempt-ing to pass up.Access to this data depends largely on boththe network’s and the database’s security.

Strategy: use network access and PC-based security guide-lines. Hardening IP phones so that they contain securitycertificates and using tight password protection can miti-gate unauthorized access to both gateway and voice mailservers. In addition, the use of up-to-date antispyware soft-ware and the general reduction of open IP ports on theservers reduces the risk of unauthorized access to specificserver machines. General database encryption techniquescan also help protect the voice mail system’s integrity.

UNDERLYING IP NETWORK VULNERABILITIESFor all its unique qualities, certain aspects of VoIP

security do fall under the umbrella of data network secu-rity. The use of encryption protocols—such as SecureSockets Layer (SSL), Transport Layer Security (TLS),and Internet Protocol security (IPSec)—can securetransfers in both data and voice networks. However, thedelay introduced by such encryption is tolerated less ina voice network than in a standard data network. Inaddition, the end-to-end encryption of a voice streamcan hide the details of the underlying signaling proto-cols. Without this information, a firewall scanning forVoIP ports will be unable to determine which ports toallow through.

Issue: latency and jitter from the IP network’s security architecture

The actual performance impact of SSL,TLS, and IPSecencryption and decryption varies based on the exact algo-rithm used. However, latency or jitter cannot be avoidedas the cryptodevice performs the mathematical operationsrequired to manipulate the data stream. Since a voicedelay of 150 milliseconds is noticeable and therefore unac-ceptable (see http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf), administrators must ensurecryptodevices on the network can operate within thesedelay constraints at peak load.

➤ Session Initiation Protocol: http://www.cisco.com/univercd/cc/td/doc/product/voice/sipsols/biggulp/bgsipcf.htm

➤ VoIP tutorial: http://www.juniper.net/solutions/literature/white_papers/200087.pdf

➤ VoIP security report: http://csrc.nist.gov/ispab/2004-06/kuhn_2004_06_ispab.pdf

➤ VoIP Security Alliance: http://www.voipsa.org/➤ RFC on Session Initiation Protocol: http://www.

ietf.org/rfc/rfc3261.txt➤ H.323 specification: http://www.itu.int/rec/T-REC-

H.323/en

Further Reading

46 IT Pro September ❘ October 2007

V O I P N E T W O R K S E C U R I T Y

Strategy: conduct performance benchmarking. Perform-ing benchmarks will determine if an existing data net-work’s firewalls, configurations, and security architecturecan handle the expected peak voice load.The end-to-endlatency should be no more than 150 ms. Most major ven-dors’ encryption and decryption devices meet theserequirements.

Issue: end-to-end encryption of signalingprotocols prevents firewalls from learningdynamic ports

As mentioned earlier,firewalls need to understand VoIPsignaling protocols.To do this, they must parse and inter-pret the signaling traffic. If this traffic is encrypted, thenthey will not know which ports to allow through.Note thatthe firewall’s ability to operate is unaffected by end-to-end encryption of the voice data stream.Strategy: configure the firewall to operate as a signalingproxy server. If the firewall can act as a signaling proxyserver, then it can actually decrypt the setup messages andextract the necessary ports. In this case, the firewall will

have to be benchmarked to ensure that it can decrypt andencrypt traffic, examine the messages for dynamic ports,and set up and tear down those ports at peak load. If thefirewall in use does not have this capability, then a networkdesign that incorporates a signaling proxy server can beused. In this case, some communication needs to occurbetween the proxy server and the firewall to update whichports are allowed.

S ecurity in a VoIP network is key due to the specific vul-nerabilities of both the network infrastructure and theapplication architecture. While simple extensions to

data network security can help mitigate these vulnerabili-ties,performance implications might require upgrading anyexisting components to higher-performance devices. ■

Wesley Chou is an engineering manager within the Appli-cation Delivery Business Unit at Cisco. Contact him atwschou@gmail.com.

■ Monthly updates highlight the latest additions to the digital library from all 23 peer-reviewed Computer Society periodicals.

■ New links access recent Computer Society conference publications.

■ Sponsors offer readers special deals on products and events.

Available for FREE to members, students, and computing professionals.

Visit http://www.computer.org/services/csdl_subscribe

For the IEEE Computer Society Digital Library E-Mail Newsletter

Sig

n U

p T

oday