SECURITY CHECKLIST FOR VOIP PROVIDERS

Security Checklist For Voip Service Providers
It is often said that understanding the problem is 90% of the solution, and VoIP security is no exception. It is fear of the unknown which is likely to elicit a knee-jerk reaction of panic, so the first step is to understand the threats and then classify them. We also have to ask the question: what does security mean to me and what does it mean to my customers?
Security to the customer means protecting their device and identity and the continuity of their service. Security to the service provider means protecting their network their revenue and their customers. In this feature we will look at service disruption and service theft.
Disruption
A service can be disrupted by breaking the user's device, flooding the IP network with traffic or breaking the service provider's infrastructure. Disruption is usually achieved through either Logic Attacks or Flood Attacks or Application Layer Attacks.
• Logic attacks exploit vulnerabilities in protocols or their implementations, e.g. Ping of death, Teardrop, Land etc.
• Flood attacks disable targets through traffic volume; a flood attack can originate from a single platform or from multiple platforms.
• Application Layer Attacks include: SIP-SPAM, and identity forging.
We can also divide the attacks into IP layer and SIP layer thus:
IP Logic Attack / IP Flood AttackSIP Logic Attack / SIP Flood Attack Application Layer attack
IP Logic Attacks
IP Logic attacks on SIP devices are no different to any other IP device; these include well known exploits such as: Ping of death, Teardrop, Land, Chargen and Out of sequence packets. All of these can disable a device which has not been fully tested to protect itself against these exploits.
IP Flood Attacks
IP Flood attacks include: SYN flood attack (TCP SYN Floods are one of the oldest DoS attacks in existence), Smurf Attack, Fraggle attack and the list goes on... These attacks are designed either to overcome the device by tying up resources or to simply overwhelm the network through shear weight of traffic.
SIP Logic Attacks
SIP logic attacks exploit weaknesses in SIP signalling implementations. Incomplete or incorrect fields, invalid message types can disable not only client devices but also core network devices. This type of attack can be countered by thorough testing of any devices against suites such at the IETF SIP Torture test developed through the SIPiT Events or the PROTOS Test-Suite, developed by the University of Oulu.
A more sophisticated attack can be to inject messages into a call to terminate it prematurely. This type of attack can be largely avoided by the use of strong authentication techniques, thus, the injected packet would not be authenticated and therefore would be rejected.
SIP Flood Attacks
SIP flood attacks exploit weaknesses higher up the communications stack that require more processing resources. As a consequence, it takes a much smaller flood to cause disruption. For example, one or more devices may send multiple registrations or call requests to a server.
Countering this type of disruption requires network based devices like Session Border Controllers (SBCs) to police the signalling stream and rate limit registrations and calls to Softswitches to predetermined limits. Acting as a proxy in the signalling stream the SBC can also filter inappropriate protocols, IP DoS attacks and invalid SIP messages. This helps compartmentalise the network and restricts any disruption to just one network segment.
Protect the User Device
These devices will typically be incapable of rate limiting and may be overrun by flood attacks. This means they are subject to both logic and flood attacks. Again the user device will benefit from the protection afforded by network based SBCs blocking DoS attacks and invalid SIP messages.
Service Theft
A simple example of service theft is to signal that a voice call it being made but exchange video data. This hits the service provider on two fronts: a) loss of revenue by billing for only a voice call and b) potential degradation in service quality for other users resulting in dissatisfaction.
The structure of a VoIP call with separate media and signalling streams has lead to some innovative ploys. For example, a rogue PC client which transports media in the RTCP quality monitoring stream, this is not policed in most networks. Another ploy is to transport media in the call signalling then failing the call before billing commences. Not only does this mean a free call but repeated call set can cause huge signalling rates which are a DoS attack in themselves.
The solution is to police all components of the call. SBCs police the signalling and the media to ensure that the call is executed as requested and that RTCP traffic is within expected bounds.
Conclusion
Security is a vast subject and needs to be ubiquitous in its implementation. Take care of the fundamentals first:
Test, authenticate, protect, block, limit and police.
• Test network elements against standard IP and SIP test suites to ensure they can survive IP and SIP logic attacks
• Implement strong authentication, identifying your users protects their identity, protect their service and combats disruption.
• Protect the Network by compartmentalizing it to restrict the range of any disruption.
• Block malicious or inappropriate traffic – do not propagate the problem.
• Limit the rate of traffic to core elements to ensure the survivability of the service.
• Police all aspects of the traffic flowing across the network to prevent fraudulent or inappropriate use.
A secure and dependable service brings with it benefits to users and provider alike. It will build user confidence which in turn creates dependable revenue for the service provider and by addressing the basics from day one, need not be complex or expensive.