Securing a VoIP Network

Now that you have a foundational understanding of the myriad attacks that can target a VoIP network, this section addresses specific VoIP attack mitigations. Specifically, it covers separating voice traffic from data traffic using voice VLANs, using firewalls and VPNs to protect voice traffic, and approaches to harden the security of voice endpoints and servers.

Protecting a VoIP Network with Auxiliary VLANs

A fundamental approach to protecting voice traffic from attackers is to place it in a VLAN separated from data traffic. This voice VLAN is often called an auxiliary VLAN. VLAN separation alone protects voice traffic from a variety of Layer 2 attacks. For example, an attacker would be unable to launch a man-in-the-middle attack against an IP Phone, where the attacker's MAC address claimed to be the MAC address of the IP Phone's next-hop gateway. Such an attack would be mitigated, because the attacker's PC would be connected to a data VLAN while the IP Phone was connected to the auxiliary VLAN.

Many models of Cisco IP Phones include an extra Ethernet port to which a PC can attach. The attached PC communicates through the Cisco IP Phone into a Cisco Catalyst switch at the access layer. Fortunately, the PC and the Cisco IP Phone can transmit traffic in separate VLANs (that is, a data VLAN for the PC's traffic and an auxiliary VLAN for the phone's voice traffic) while still connecting to a single Cisco Catalyst switch port.

In Figure 9-4, notice that the PC communicates on VLAN 110, while the Cisco IP Phone sends voice traffic on VLAN 210. Traffic from both VLANs enters Switchl on port Gigabit 0/1. A single Cisco Catalyst switch port accommodating traffic from two VLANs might seem like a trunk port. Interestingly, Cisco makes an exception on many Cisco Catalyst switch models, allowing the port that accepts traffic from the data VLAN and the auxiliary VLAN to be an access port.

Figure 9-4 Auxiliary VLAN

Protecting a VoIP Network with Security Appliances

Security appliances such as firewalls and VPN termination devices also can be used to protect voice networks. However, one challenge of protecting voice networks with a firewall is that the administrator is unsure what UDP ports will be used to transmit the RTP voice packets. For example, in a Cisco environment, a UDP port for an RTP stream typically is an even-numbered port selected from the range of 16,384 to 32,767. Opening this entire range of potential ports could open unnecessary security holes.

Fortunately, Cisco firewalls (that is, the PIX and Adaptive Security Appliance [ASA] firewalls) can dynamically inspect call setup protocol traffic (for example, H.323 traffic) to learn the UDP ports to be used for RTP flows. The firewall then temporarily opens those UDP ports for the duration of the RTP connection.

To understand this concept, consider Figure 9-5. In the first step, the Cisco IP Phone uses SCCP to initiate a call to the PSTN. SCCP, which uses TCP port 2000, is used to communicate between the Cisco IP Phone and the UCM server. UCM determines, based on the dialed digits, that the call needs to be sent out the H.323 gateway. In the second step, using TCP port 1720, UCM initiates a call setup with the H.323 gateway. The firewall between these devices is configured to permit the H.323 protocol. The firewall is also instructed to inspect H.323 traffic, to dynamically determine which UDP ports are selected for the voice path. In the third step, UDP ports 20,548 and 28,642 were randomly selected. Because an RTP flow is unidirectional, two UDP ports are selected to support bidirectional communication. Because the firewall inspected H.323 and dynamically learned the UDP ports to be used, the firewall permits the bidirectional RTP flow for the duration of the conversation.



IP Phone Voice VLAN = 210

IP Phone Voice VLAN = 210

Key Topic

Figure 9-5 RTP Inspection

Unified Communications Manager

(1) SCCP TCP Port 2000

IP Phone

IP Phone


UDP Ports 20,548 and 28,642 (Randomly Selected)



H.323 Gateway

Aside from permitting or denying specific ports, a firewall can also provide additional protection to a voice network. For example, a firewall can be configured to enforce specific policies, which might block specific phones. As another example, a firewall can determine if too many messages (as configured with a threshold value) of a certain type (for example, SIP requests) occur within a certain period of time.

Although many Cisco IP Phones can encrypt and authenticate traffic within the phone itself, many other IP telephony and VoIP devices lack this capability. To add encryption and authentication support for these devices, consider sending their voice packets over an IPsec-protected VPN tunnel. A variety of devices could be used for VPN termination, including Cisco Unified Communications Manager (version 5.0 and later). Figure 9-6 shows an IPsec tunnel encrypting traffic between a Cisco Unified Communications Manager server and an H.323 gateway.

Figure 9-6 Protecting Voice with an IPSec Tunnel

Unified Communications Manager 5.x

Unified Communications Manager 5.x

IPsec VPN Tunnel

IPsec VPN Tunnel

H.323 P Gateway s

IP Phone

Switch ff

IP Phone



Hardening Voice Endpoints and Application Servers

Endpoints, such as Cisco IP Phones, tend to be less protected than other strategic devices (for example, servers) in a voice network. Therefore, attackers often try to gain control of an endpoint and use that as a jumping-off point to attack other systems. An attacker might be able to gain control of a Cisco IP Phone by modifying the image or configuration file used by the phone.

Alternatively, the attacker could capture packets from the PC switch port on the Cisco IP Phone, or from the network (in a man-in-the-middle attack). Interestingly, an attacker could get the IP addresses of other servers (for example, DNS, DHCP, and TFTP servers) by simply pointing a web browser to the Cisco IP Phone's IP address.

Figure 9-7 shows some of the information that can be gleaned by pointing a web browser to the IP address of a Cisco IP Phone. Access to this web page, made possible by the web access feature enabled on the phone (which is a default setting), does not require any login credentials. The information is freely available.

Figure 9-7 Web Access to Cisco IP Phone Configuration Information

^^vCyf » Ig] http: 1/ v11^t X [Tr

Favorites Tools Help

5Cisco Systemsj Inc.

^^vCyf » Ig] http: 1/ v11^t X [Tr

Favorites Tools Help

5Cisco Systemsj Inc.


Network Configuration

Cisco IP Phone Cisco Communicator ( SEP00I143A839A2 )

Device Information

DHCP Server

Network Configuration

Host Name


Network Statistics

LP Address

Device Logs

TTTP Server 1

Status Messages

Default Ronter 1

Debug Display

Default Ronter 2

Streaming Statistics

Default Ronter 3

Stream 1

Default Ronter 4

Stream 2

Default Ronter 5

Stream 3

CalLManager 1 Active

CalLManager 2

CalLManager 3

CalLManager 4

CalLManager 5

Information URL

http: 7192.168.0.28:8080.'ccmcip.'GetTelecasterHelpText.jsp

Directories URL

Messages URL

To help tighten the security of a Cisco IP Phone, beginning in Cisco Unified Communications Manager (UCM) 3.3(3), Cisco introduced support for phone image authentication, in which Cisco Manufacturing digitally signs the image file. As of UCM 4.0 and later, Cisco supports configuration file authentication in addition to image file authentication.

Several proactive steps can be taken by navigating to a phone's configuration page within the Cisco Unified Communications Manager Administration interface, as shown in Figure 9-8, and changing some of the default settings.

Recall that a Cisco IP Phone makes a collection of configuration information freely available by pointing a web browser to the IP address of the Cisco IP Phone. This potential weakness can be mitigated by changing the Web Access parameter from Enabled to Disabled. Also, to prevent a man-in-the-middle attack, you could change the Gratuitous ARP setting from Enabled to Disabled. By disabling the gratuitous ARP feature, you are preventing a Cisco IP Phone from believing unsolicited Address Resolution Protocol (ARP) replies, which potentially could have come from an attacker claiming to be the next-hop gateway for the Cisco IP Phone.

Figure 9-8 Cisco IP Phone Configuration Screen


Figure 9-8 Cisco IP Phone Configuration Screen

Aside from voice endpoints, other popular attack targets on voice networks include application servers, such as a Cisco UCM server. Fortunately, Cisco provides an already hardened version of the operating system that runs on a UCM server.

NOTE In UCM versions 3.x and 4.x, the underlying operating system is Microsoft Windows 2000. In UCM versions 5.x and 6.x, the underlying operating system is based on RedHat Linux.

The UCM server's operating system already has several unneeded services disabled. Depending on the UCM version, many default usernames (such as "root") are disabled, and the Cisco Security Agent (CSA) Host-based Intrusion Prevention System (HIPS) product is installed. Also, beginning in UCM 5.0, UCM supports IPsec.

However, depending on the role of a particular application server, you might decide to turn off additional services that are unneeded. Therefore, by effectively combining a collection of security solutions Cisco makes available for IP telephony networks, you can prevent and/ or defeat the vast majority of attacks that could be launched against your voice network.

Summary of Voice Attack Mitigation Techniques

Table 9-6 summarizes some of the methods of mitigating attacks that were described in this section.

— Table 9-6 Methods of Mitigating Attacks Targeting Voice Networks



Using auxiliary VLANs

Auxiliary VLANs carry voice traffic in a different VLAN from data traffic. This helps improve the quality of the voice transmission and helps secure the voice traffic from Layer 2 attacks.

Using firewalls

Firewalls can be used to prevent potentially malicious traffic from entering a voice network while dynamically opening appropriate UDP port numbers for individual RTP flows.

Using IPsec-protected VPNs

IPsec-protected VPNs can be used to secure the transmission of voice signaling and media packets, which might otherwise be intercepted and interpreted or modified by an attacker.

Disabling web access

Disabling web access to a Cisco IP Phone, which is enabled by default, prevents an attacker from pointing his web browser to the IP address of a Cisco IP Phone. If the attacker did this, he could learn the IP addresses of other servers, which could become potential attack targets (for example, DNS, DHCP, or Unified Communications Manager servers).

Disabling gratuitous ARP

Disabling gratuitous ARP (GARP) can mitigate a man-in-the-middle attack. In this kind of attack, the attacker sends unsolicited ARP replies to a Cisco IP Phone, claiming that the MAC address of the Cisco IP Phone's next-hop gateway is the MAC address of the attacker's PC.

Disabling unneeded services

Disabling unneeded services (for example, the TFTP service on a UCM server not acting as a TFTP server) can close potential security holes in a system.

0 0

Post a comment