The Rest of the Voice Security Story...

When I left off in my last post, we had been discussing a myriad of bad things that can happen to Voice traffic in an IP network. Now we need to turn our attention to what we need to know to help protect it. Again, you might not be all that familiar with VoIP but like certain areas in the new CCNA, the CCNA Security, pushes a little past the general comfort zone for most folks on track for the CCNP. So what can we do to better protect our voice traffic? Well first, we can separate it from data traffic using VLANs, also we can employ firewalls and VPNs to better protect our voice traffic, and finally, we need to make sure that we are taking the right steps to harden the voice endpoints and servers as well. VLANs and Voice One of the most basic, yet most important steps you can take when it comes to helping secure your voice traffic is to place it in a VLAN where it is separated from common data traffic. Generally, we refer to this voice VLAN as an “auxiliary VLAN”. So what do we gain in doing this? The main defense here is to guard our voice traffic against layer 2 attacks such as a man-in-the-middle attack against a Cisco IP Phone. I can almost hear you asking, “so what’s with that extra Ethernet port on a lot of Cisco IP phones? What happens when I connect my phone to my PC?”. The good news is that in cases such as these the PC actually communicates through the phone to, for instance, a Cisco Catalyst switch at the access layer. Even though this connection comes through the IP phone, the PC and the Cisco IP Phone transmit their traffic in separate VLANs even though they are connected to a single Catalyst switch. Calling the Maytag Man Ok….so I am not actually talking about that kind of appliance, rather, we can effectively secure voice traffic using Cisco Security appliances. Let’s see how… Whether you chose a firewall or something like a VPN termination device, these Cisco Security appliances can help you add a layer of defense beyond just the separation of voice and data traffic. Of course, one of the challenges when it comes to using a firewall to secure your voice traffic is how do we know what UDP ports will be used to transmit the RTP voice packets? In case you are not as familiar with VoIP, it might be good to discuss this port issue for a moment. In a Cisco VoIP environment, an even numbered UDP port from the range 16,384-32,767 is chosen to transmit the RTP stream (voice packets). Of course the trick is- which one? We could open that full range of ports- yeah, right! OK, so if you get that little joke, then you also likely see the challenge we are up against. We aren’t sure which port will be used to transmit these packets but opening a broad range of ports to accommodate this selection is a potential security nightmare, so what do we do? Ready for the good news? If you have a Cisco firewall, such as a PIX or perhaps an Adaptive Security Appliance (ASA) you can dynamically inspect the call setup protocol traffic. In doing this, you can learn what UDP ports will be used for the RTP flows. Once we have this knowledge, the firewall can then temporarily open just those UDP ports while the RTP connection is in place. Of course, firewalls can also assist your voice network in other ways as well. For instance, we might want to enforce specific policies which might block specific phones. In another case, we might want our firewall to watch a given threshold value. We could have our firewall determine if too many messages of a certain type have occurred within a specified period of time. In this case, we might set a threshold value for SIP requests that we have the firewall track. Even though many Cisco IP Phones have the ability to encrypt and authenticate traffic within the phone itself, other IP phones and various VoIP devices may lack this ability. In these cases, we can send their voice packets over an IPsec –protected VPN tunnel as a way to secure the traffic. For instance, we might choose to encrypt voice traffic sent between a Cisco Unified Communications Manager server and an H.323 gateway. Last but Not Least The final area to consider with regard to securing voice traffic on your network are the endpoint devices, such as Cisco IP Phones, and servers such as the Cisco Unified Communications Manager server. As we discussed when we considered different attacks, an attacker could launch a DoS attack against a Cisco Unified Communications Manager server or try to gain control of an endpoint and use it as a jumping-off point to attack other systems. Attacks such as these can come in a variety of ways. For instance an attacker might try to gain control of an endpoint by modifying the image or configuration file the phone uses, or they might try and capture packets from the PC switch port on the Cisco IP Phone, or from the network by launching a man-in-the-middle attack. To help in securing endpoints and combating attacks such as these, beginning in Cisco Unified Communications Manager (UCM) 3.3(3), Cisco introduced support for phone image authentication. With phone image authentication, Cisco Manufacturing digitally signs the image file. Adding to image file authentication, beginning with UCM 4.0, Cisco supports configuration file authentication. One of the wekanesses we need to combat is the fact that Cisco IP Phones make the collection of configuration file information freely available by simply pointing a web browser at the IP address of the phone. To combat this weakness, we need to change the Web Access parameter from Enabled to Disabled. Another key step is to change the Gratuitous ARP setting to Disabled as well. This will serve to prevent man-in-the-middle attacks. These settings can be changed in the Cisco Unified Communications Manager Administration interface on the phone’s configuration page. As for protecting the Cisco Unified Communications Manager server itself, the hard work has already been done for you. Cisco provides an already hardened version of the operating system that runs on the UCM server. This hardening serves to disable a number of unused services and depending on the UCM version you are working with, many default usernames such as “root” are disabled as well. Additionally, the Cisco Security Agent (CSA) and Host-based Intrusion Prevention System (HIPS) are installed as well. In addition to these steps taken by Cisco, you might also chose to disable additional services depending on how you use the server in your own network. Finally, beginning with UCM 5.0, IPsec is supported for added security. Wrapping up… You may not be quite ready to sit for your CCVP certification but I hope that this two-part primer on Voice security has been helpful. Remember, the CCNA Security certification, in my opinion, is more broad than it is deep. Be sure to look over each of the topic areas and if there is one that is a little outside of your comfort zone, like voice security perhaps, be sure to spend a little extra time there when you are preparing to sit the exam.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2009 IDG Communications, Inc.