Traversing the FirewallWhen configuring an organization's network boundary in a typical data network, a logical first step is inserting the proverbial 5-tuple information (source IP address, destination IP address, source port number, destination port number and protocol type) into a packet filtering firewall. Most packet filtering firewalls examine the 5-tuple data, and if certain criteria is met, the packet is either accepted or rejected. So far so good, right? Not so fast.
Most VoIP implementations utilize a concept known as dynamic port trafficking. In a nutshell, most VoIP protocols use a specific port for signaling purposes. For example, SIP uses TCP/UDP port 5060, but they invariably use whatever port can be successfully negotiated between two end devices for media traffic. So, in this case, simply configuring a stateless firewall to deny or accept traffic bound for a certain port number is similar to using an umbrella during a hurricane. You might block some of the rain from landing on you, but ultimately, that just isn’t enough (Kuhn, Walsh & Fries, 2005).
What if an enterprising system administrator decides that the workaround to the dynamic port trafficking problem is allowing connections to all possible ports utilized by VoIP? Not only will that system administrator be in for a long night of parsing through thousands of possible ports, but the moment his network is breached, he will likely be searching for another source of employment.
What is the answer? According to Kuhn, et al., a major first step in securing an organization’s VoIP infrastructure is proper implementation of a stateful firewall. A stateful firewall differs from a stateless firewall in that it retains some sort of memory of past events, whereas a stateless firewall retains absolutely no memory of past events. The reasoning behind using a stateful firewall centers on its ability to not only examine the above mentioned 5-tuple information, but also examine application data. The ability to examine application data heuristics is what allows the firewall to differentiate between voice and data traffic.
With an established stateful firewall, voice infrastructure is secure, correct? If only network security were that simple. Security administrators must remain mindful of an ever-lurking concept: Firewall configuration. Decisions, such as whether or not to allow ICMP packets through a firewall, or if a certain packet size should be permitted, are absolutely crucial when determining configuration.
VoIP Conflicts with Network Address TranslationNetwork Address Translation (NAT) is the process that allows for the deployment of multiple private IP addresses behind one global IP address. So, if an administrator’s network has 10 nodes behind a router, each node would have an IP address that corresponds to whatever internal subnet has been configured. However, all traffic leaving the network would appear to be coming from one IP address - most likely, the router.
The practice of implementing NAT is extremely popular, as it allows an organization to conserve IP address space. However, it poses no small problem when VoIP is being implemented on the NAT’d network. These problems do not necessarily arise when VoIP calls are made in an internal network. However, problems do arise when calls are made from outside of the network. The primary complication arises when a NAT enabled router receives an internal request to communicate via VoIP to points outside of the network; it initiates a scan of its NAT tables. When the router looks for an IP address/port number combination to map to the incoming IP address/port number combination, the router is unable to make the connection because of the dynamic port allocation practiced by both the router and VoIP protocol.
Confusing? No doubt. It is this confusion that prompted Tucker (2004) to recommend doing away with NAT whenever VoIP is deployed. What about NAT's address space conservation benefits, you ask? Such is the give-and-take involved with introducing new technology to your network.
Open Source VoIP Hacking ToolsIf an aspiring system administrator prefers to assess his network's security posture rather than have a hacker do it for him, he might try some of the following open source tools. Of the available open-source VoIP hacking tools, some of the more popular are SiVuS, TFTP-Bruteforce and SIPVicious. SiVuS is like a Swiss Army knife when it comes to VoIP hacking. Among one of its more useful purposes is SIP scanning, where a network is scanned and all SIP enabled devices are located. TFTP is a VoIP protocol specific to Cisco, and, as you may have guessed, TFTP-Bruteforce is a tool used to guess a TFTP server's possible usernames and passwords. Finally, SIPVicious is a toolkit used to enumerate possible SIP users within a network (McClure, Scambray & Kurtz, 2009).
Rather than individually downloading all of the above mentioned tools, one might try the latest distribution of BackTrack Linux. These tools, as well as others, may be found there.