|
Have you ever heard the expression, closing the blast-shield doors after the Tonton is out? Youll have to get into Star Wars mode with me here, but just go with it because this expression, unfortunately, describes security efforts in todays converged enterprise. Because hackers use every means necessary to exploit network vulnerabilities, it is the responsibility of enterprise IT to be one step ahead, not one step behind. Since IP telephony brings with it a new layer of vulnerability to the network, traditional network security is no longer an effective way to protect the network.
To begin with, VoIP (define - news -alerts) has a very different architecture than traditional TDM-based PBXs; it uses some of the same components as TDM as well as the architectural underpinnings of a traditional IP network, and these differences can result in significant security issues if not implemented correctly.
You must unlearn what you have learned...
For networks that use VoIP technology, they must protect both voice and data. Many administrators assume that, since digitized voice travels in IP packets and that their IP network is already secure for transmitting traditional data traffic, they merely need to plug the VoIP components into their IP networks and these calls will remain safe. However, packets sent from a users computer may pass through anywhere from 15 to 20 different systems that are not under the control of the users ISP, making them an easy target to intercept. An attacker can compromise a VoIP gateway, exploit the vulnerabilities of a vendors SIP protocol implementation, or hijack calls through TCP hijacking or application manipulation.
Understanding and mitigating the security risks associated with a VoIP network are becoming increasingly more important in todays communications arena. An IP telephony deployment presents a variety of threats from different networking layers, as well as from different areas in the network. It is important for IT personnel to understand the various threats and how to mitigate each one. But first, one needs to understand VoIP specifically the devices, protocols, and configurations of typical VoIP deployments.
VoIP building blocks aint exactly Legos, Kid.
PC-based softphones. IP phones. Traditional phones. These are a few of the huge variety of devices used in a typical enterprise VoIP deployment. Therefore, a number of physical elements must be present. A suitable phone used by an end user to make a call, software that runs on a dedicated server platform and offers the functionality of call control and call signaling, a gateway device that connects the IP network and the carrier network, and multi-point control units for optional elements such as conferencing, all must be in place to optimize the VoIP network.
Having each of these elements on top of the implementation of various security measures can wreak havoc on the Quality of Service (QoS), a factor crucial to the operation of a VoIP network. Complications can be caused by anything from a firewall delaying or blocking call setup to encryption-produced latency and jitter. And because of performance restraints placed on many networks, most security measures implemented in traditional data networks are not specific to a VoIP environment. Not to mention the complications that can arise from the VoIP protocol selected.
I sense something... a presence...
There are a number of VoIP-specific attacks that can be performed at the application level in order to disrupt or manipulate service, which means anyone could secretly be acting as a third wheel and eavesdropping on your call. All an attacker needs is access to the VoIP LAN to eavesdrop the network traffic and decipher the voice conversations. A simple tool called VOMIT (Voice Over Misconfigured Internet Telephones) can be downloaded to easily perform this attack. Worse yet, the attacker may even be able to conduct a man-in-the-middle attack and modify the original communication.
Still worse is that by spoofing his or her identity, a savvy attacker can cause a denial of service in SIP-based VoIP networks by sending a CANCEL or BYE message to either of the parties involved and end the call. The attacker also can spoof a SIP response, which indicates to the caller that the called party has moved to a rogue SIP address, and hijack the call. The same attacker could even impersonate a valid user/IP phone and use the VoIP network to make free long distance phone calls.
It is time you learned the ways of the Force...
Since VoIP is not a stagnant technology and will continue to evolve it is crucial that the network administrators understand there are a number of vulnerabilities yet to be discovered. As VoIP continues to evolve, it will become even more important to prevent these as yet undiscovered vulnerabilities from being exploited. Until then, it is highly likely attacks will come from the application level as attackers become more knowledgeable about the technology and will gain easier access to test the infrastructure as it becomes more prevalent.
Fortunately, there are several proactive techniques that exist in order to combat the numerous risks of attack associated with IP telephony. One course of action is to develop the appropriate IP network architecture, separating the voice and data on logically different networks via VPN or tagging technology. If it is possible, different subnets with separate address blocks should be used for data and voice traffic. Separate DHCP servers should also be used for each in order to simplify the incorporation of intrusion detection. Strong authentication and access control should be used at the voice gateway, which interfaces with the PSTN or other traditional voice networks. Perhaps the key to creating a secure IP telephony network is strong authentication of VoIP endpoints and all IP telephony components through access control mechanisms and policy enforcement.
Using a static firewall, as is the case with most traditional data networks, will not work in a VoIP environment because the protocols make processing VoIP traffic more complicated. To address this problem in the VoIP environment, a separate add-on to the firewall should be put in place to offload VoIP traffic from the main firewall. This process is recommended particularly in environments with a high volume of VoIP traffic. Because components of H.323 call signaling may not be supported, the benefits of stateful packet filters that can track the state of connections and deny packets that are not part of a properly originated call may not be completely realized. Furthermore, if TLS is used to protect SIP signaling, stateful packet filters may not work. IPsec or Secure Shell (SSH) ought to be used for any remote management functions.
Great weakness do I sense in your configuration...
VoIP devices are particularly vulnerable to attacks due to the very nature of their default configuration. Typically, VoIP devices are defaulted to a mixture of exposed TCP and UDP ports. When the devices are put in place and begin to run on the network, they are open to Distributed Denial of Service (DDoS) attacks, problems with buffer overflows, and weak passwords all of which may result in a compromised VoIP device. Whats more, if the administrator wants to manage the device remotely and place the device on a Web server, that particular device opens the network up for even more trouble. Using our Star Wars reference again, these devices have effectively left the blast doors open and the network is vulnerable to Imperial attack.
However, the default configuration is not the only aspect of a VoIP device that makes it vulnerable. The Simple Network Management Protocol (SNMP) services offered by these devices may also be vulnerable to reconnaissance attacks or buffer overflows. In a pretty diabolical process, an attacker simply exploits a VoIP device that periodically downloads a configuration file from a server through Trivial File Transfer Protocol (TFTP) or other mechanism. The attacker then diverts or spoofs this connection, tricking the device into downloading a malicious configuration file instead.
I sense a tremor in the Force...
Fuzzing, or functional protocol testing, is a technique for finding vulnerabilities within the VoIP network. Fuzzing works by creating many different types of packets that contain data that pushes that protocols specifications to the point of breaking them. The packets are then sent to an application, hardware device, or operating system capable of processing that particular protocol. The results are monitored for any abnormal behavior including crashes or irregular resource consumption. In a short amount of time, fuzzing has already led to an array of denial of service and buffer overflow vulnerability discoveries in vendor implementations of IP telephony products that use H.323 and SIP. Of course, this is just a process to test these protocols and administrators should not rely just testing alone. It is crucial that network administrators pay particular attention to how they are using the technology within their networks, before, during, and after implementation.
A New Hope
Yes, traditional telephone lines can be monitored when physical access is obtained; but in most offices, there are many more points that connect with a LAN and therefore must be configured in your overall security plan. You dont want to give unauthorized users the opportunity to hack into existing phone conversations, which is exactly what will happen if an attacker possesses physical access to your LAN and there is no encryption in place. Thus, physical controls are extremely important in an IP telephony environment. However, even with encryption in place, an attacker could still perform traffic analysis if he or she gains physical access to VoIP servers and gateways. So, that too needs to be taken into consideration when designing a proactive defense strategy.
Today, given the volatile nature of an IT environment, you should already have a security policy in place. However, before enterprises make the transition to IP telephony, they must again perform a thorough periodic assessment to assure themselves they are conforming to the defined policies, procedures, and guidelines for securing the IT infrastructure. This extends to assessing the overall quality of the IP network and can determine if it is strong enough to handle the increased security risk that IP telephony brings. Even after the implementation is complete, network assessments should be completed periodically to monitor network security, adherence to security policy, and network performance.
Given that every IP network and VoIP deployment has its own unique characteristics, which specific tools and techniques will prove to be the best to prevent security issues that threaten IP telephony only can be discovered over time. IT
Bob Decker is Director, Managed and Professional Services Sales Overlay, NextiraOne (news -alerts). For more information, please visit the company online at www.nextiraone.com.
If you are interested in purchasing reprints of this article (in either print or PDF format), please visit Reprint Management Services online at www.reprintbuyer.com or contact a representative via e-mail at [email protected] or by phone at 800-290-5460.
|
SUBSCRIPTIONS
TMCnet LOGIN
WEBINARS
