Securing VoIP
VoIP security played a major role in this year's iLabs testing. Because there's currently no authentication or encryption in most multivendor VoIP networks, it's simple to intercept VoIP conversations. The iLabs team demonstrates this point using the WildPackets OmniPeek analyzer to capture and replay conversations.
To demonstrate the risk of denial-of-service (DoS) and man-in-the-middle attacks, the team set up five "enterprises," each subject to increasingly sophisticated intruders. The VoIP-aware intrusion detection/prevention systems at each "enterprise" came from Check Point's UTM-1; Cisco IDS code on a 7204 router; Fortinet's FortiGate appliance; Juniper's IDS 200; and the open source Snort project. To simulate network conditions, the team used InterWorking Labs' mini-Maxwell impairment generator and monitored conditions using Network Physics' NP-2000 system.
In the simplest scenario, a remote attacker with no knowledge of the enterprise network used Mu Networks' Mu-4000, Tenable Networks' Nessus, and other attack tools to try to gain access. At worst, these attacks might succeed in causing a denial of service.
A DoS attack was also the goal of the second, slightly more sophisticated intruder. Here, the intruder was still remote but had some knowledge of the VoIP network, such as uniform resource identifiers (URIs) or phone extensions. This attack involved malformed packets generated by the Mu-4000 and open-source tools such as sipp, sipsak, and SipBomber.
Next up was a remote attacker with detailed knowledge of the target VoIP network. This attacker's goal might be denial of service, or it could be to eavesdrop or redirect calls.
The final two categories of attacks involved intruders with local access. In these scenarios the potential for mayhem was far more serious than simple DoS attacks. In the first internal scenario, an attacker attempted to delete selected sounds from a media stream; for example, a disgruntled employee might delete or delay purchase orders. In the other scenario, an attack might insert selected words into a an RTP media stream; think of a CEO saying "buy company X" and then having an attacker alter the message to say "don't buy company X." The applications for corporate espionage are obvious.
Setting up these attack scenarios, yielded three lessons. First, IDS/IPS may be configured in "fail closed" mode, meaning they stop forwarding packets if real or perceived attacks outrun the ability of the IDS/IPS device to report on them. A shutdown may be desirable from a security standpoint, but network managers with high availability requirements might instead prefer a "fail open" configuration.
Second, IDS/IPS devices are useful in thwarting some classes of VoIP attacks but not others. For example, an IDS/IPS device should be able to block basic SIP flooding attacks or transmission of malformed packets. But attacks that mess with the media stream -- such as the deletion and insertion attacks -- look like benign traffic if they're done properly.
That raises the final lesson: Strong authentication and encryption of VoIP traffic would have prevented all these attacks. To that end, another group of engineers on this iLabs team focused on the available mechanisms for securing voice traffic.