home > resources > news


Resources

News

Events

Documentation

SIP Security FAQ

Why do I need Security for VoIP and other UM applications?

The short answer is that you need to secure your VoIP and Unified Messaging applications and network components for exactly the same reason that you need to provide security for email, web and other IP applications. VoIP is an IP application which runs on IP networks, in many cases on public IP networks where it is open to attack and misuse.

The slightly longer answer is that VoIP and many other Unified Messaging Applications are more complex than most IP applications and therefore subject to a more complex set of security threats than those other applications. For example VoIP and UM applications using the Session Initiation Protocol (SIP) rely on three different protocols while email and web applications use only one. Also, most IP applications are based on a simple client-server model. For example when you use a web application your web browser (a client) connects to a web browser and requests information. This simple client-server relationship is blurred in VoIP. These factors mean that VoIP and UM applications are subjected to a wider range of threats than other IP applications and that many of those threats are more complex. For these reasons effective security for VoIP and UM requires specialist security products that address these specific threats.

What are the security risks of running VoIP?

The security risks can be categorised into three groups:
  1. IP Network level threats
  2. Protocol and Application threats
  3. Content threats

The first group, IP Network level threats, includes the generic set of threats that face all IP applications.

Protocol and application threats include the set of threats that stem from vulnerabilities in, or misuse of, the protocols and applications that drive VoIP and UM. These are specific to those protocols and applications and include threats ranging from VoIP call flooding, call hijacking and call termination attacks as well as threats that exploit the personal information transferred by presence services.

Content threats directly attack the content of VoIP and UM applications such as audio or video streams or messages sent by an IM service. These content threats include unauthorised call monitoring, injection attacks where an audio or video stream is replaced by a stream generated by an attacker and the transfer of malicious or inappropriate content by an IM service. The consequences of unauthorised call monitoring are obvious; the confidentiality and integrity of a voice or video call is compromised. An injection attack can replace one side of a conversation with an advertising message or other audio or video stream generated by an attacker.

Is the risk of attack real?

Any IP application running on a system with network connections is open to attack. Web and email system administrators are familiar with this problem and deploy firewalls and other specialist security devices to combat the problem. VoIP is no different, if you connect a VoIP system to an IP network it is open to attack. If anything, the risk of attack and the consequences of a successful attack are greater for a VoIP application than for web an email. The reason for this is that VoIP protocols are more complex than those that drive either web or email and therefore are subject to more complex and potentially more damaging vulnerabilities than older applications.

Finally VoIP systems are being targeted today. More than that, potential attackers are actively scanning the Internet to identify potential targets. These scans use correctly formatted VoIP protocol messages to identify systems for a more concerted attack. The fact that the attacks use correctly formatted VoIP requests means that most security systems are powerless to stop the attacks. The attacks range from simple toll-fraud attacks (attempts to make free calls the expense of the targeted organisation) to denial of service attacks aimed at disrupting the VoIP or UM service. One recent example of an attack is documented and discussed at http://www.ipcom.at/index.php?id=565.

Why should I allow external connections to my VoIP network?

VoIP and Unified Messaging are about communication. To provide effective communication services you need external connections. Those connections may be required to link remote offices, roaming users or home workers, or they may be required to allow users from outside of your organisation to make calls over the Internet. Remote connections are also required when a VoIP system is connected to a SIP trunk service.

Some VoIP networks have been installed as direct replacements for a standard phone system and are operated as isolated systems with no external connections in the belief that this approach avoids any security issues.

Firstly, this belief is not well founded, particularly if the operating organisation relies on VLAN technology to maintain this separation (see VLAN question).

Secondly, while the trend is towards Unified Messaging and the integration of voice and data applications it makes no sense to continue to operate a VoIP network in isolation. Finally, even if corporate policy it not to allow Voice or other real-time communications to external end-point over IP networks, users will often find a way around this policy. A good example is the growing use of Skype in corporate networks. Skype is notoriously hard to control as it is able to navigate through most firewalls. It is far better to recognise that users want services of this type and that there is measurable value to be gained from allowing VoIP over IP networks and to provide a fully supported and controlled service.

The bottom line is that all VoIP networks either have or will have links to other networks, either officially sanctioned or informal. Any network link equates to a potential security risk.

I run separate Voice and Data networks, should I be worried about security?

Unless your Voice and Data networks really are completely and physically separated, then you should ensure that an adequate level of security is in place. Complete physical separation of voice and data networks is very rare, simply running voice and data on separate VLANs does not qualify as separation (see VLAN question) . The reality is that most VoIP systems are linked in some way data networks. Possible points of connection include:

  1. Voice and data services using a common user database
  2. Voice and data integration for CRM systems
  3. Simple TAPI links between applications and a desktop phone to enable click-to-dial and other services
  4. Connecting a user's PC via a PC port on a VoIP phone
  5. Permitting the use of soft-phones for local or remote uses
  6. Running a SIP trunk connection via an Internet link
Any link between the voice and data networks have security consequences for both voice and data services.

I use VLANs to separate my Voice and Data networks; do I need any additional security?

The blunt answer is that VLAN technology is not a security technology; it is merely a convenient method of managing traffic separation. If you separate voice and data using VLAN technology the voice and data packets flow over the same network links. Packets from different VLANs are distinguished by tags. VLAN tags are not authenticated or protected in any way. It is extremely easy to fake a VLAN tag and connect an unauthorised device to a VLAN network. Many phones include mini switches that provide a PC port and then run Voice and Data over different VLANs. In this case voice and data separation are completely at the mercy of the security of the phone. Many phones can even be configured to bridge the two networks for diagnostic purposes. There is even an application called VoIP hopper, readily downloadable, that automates the search for Voice VLANs and then connects the voice and data VLANs. All this means that VLANs should not be considered as a security technology. VLANS offer a good solution for managing network connections, but must be supplemented with effective security.

My ISP provides MPLS and assures me this is all the security I need, do I need more?

MPLS is a WAN protocol that it many ways serves the same purpose as VLAN technology on Local Area Networks. For similar reasons it should not be considered to be as security technology. MPLS, or MultiProtocol Label Switching is sometimes used by Service Providers to enable VoIP traffic to be logically separated from other traffic and given priority. When used in this way, MPLS runs between the service provider and a device in the customer's network (normally a router). MPLS does not provide any additional security for traffic to the Service Provider and has no effect at all on traffic to other destinations.

A more detailed discussion on the need for security on MPLS connections can be found on the UM Labs white paper on MPLS.

I run VoIP through my standard firewall, does this not make me secure?

Standard firewalls cannot offer effective protection for VoIP applications. Worse than this, attempting to run VoIP through a standard firewall is likely to reduce the level of security that the firewall can then provide for other applications.

A previous question outlined the three groups of security threats that face VoIP applications. Standard Firewalls are designed to protect against IP Level threats. The other threat groups, Protocol & Application and Content threats, rely mostly on sending valid protocol messages which will not be blocked by a standard firewall.

Blocking Protocol and Application threats requires tracking the state of a call. This means that the security devices must understand the status of each active VoIP call. This status includes the identity of the caller and call recipient and the exact state the call has reached (phone ringing, phone answered, call terminated etc.) This state information is not the same as the state information processed by a stateful inspection firewall.

Effective VoIP security requires that state is tracked at the application level not at the IP network level. Standard Firewalls, even those described as SIP Aware do not track state at the application level and therefore cannot offer effective defences against Protocol and Application threats.

Content threats cannot be controlled with any standard firewall technology. Effective controls require a combination of the call state tracking described for controlling Protocol and Application threats, plus additional services which include authentication, encryption and content analysis.

The reason why running VoIP through a standard firewall may reduce the level of security that the firewall provides for other applications, is that VoIP applications typically use a wide range of network ports. The more calls that are processed, the more ports are used. Configuring the firewall to open the port range needed for VoIP may adversely impact the security controls provided for other applications.

For more information on the limitations of general purpose firewalls for securing VoIP, see the UM Labs technical note Firewalls and VoIP Security.

I use a VPN to secure remote user connections, what are the limitations to this approach?

The formal definition of a Virtual Private Network, or VPN is a network in which some of the links are carried by virtual circuits in a larger network. Most VPNs also provide security by overlaying an encryption technology such as IPSec or SSL on these virtual circuits. It is assumed for the purposes of this answer that VPNs include encryption.

The main limitations of VPN technology when applied to VoIP are that firstly VPNs need some prior configuration before use and secondly VPNs implement a hub and spoke technology. The requirement for prior configuration means that VPNs can typically only be used to secure connections between office locations and users belonging to the same organisation. VPNs are therefore not suitable for securing links to customers or business partners or for securing connections from callers from other organisations.

VPNs connect remote users in a star, or hub and spoke technology, with a virtual link between the user and a central office location. The problem is that not all VoIP calls follow this topology. One of the potential benefits of VoIP is that media connections (the call) can be made peer-to-peer. This means that if a remote user calls another remote used from the same organisation, then the call can be connected directly between the two phones. This can offer a very efficient data path, but will bypass the VPN link that each user has established to their office.

Also standard VPN technologies are not optimised for VoIP. VoIP relies on the efficient delivery of a large number of small data packets. While VPNs can handle this type of traffic, they can introduce delays and add an overhead to the data transmission that can compromise the voice quality.

VPNs are not the optimal solution for VoIP. While they can be used there are better solutions for protecting VoIP calls with encryption and better solutions for managing connections to and from remote users. These solutions do not impose the limitations inherent in most VPN technologies.

I am using a Session Border Controller, why should I consider a UM Labs product?

Session Border Controllers (SBCs) and UM Labs SIP Security Controllers are aimed at different sets of users and meet a different set of requirements. The UM Labs SIP Security Controllers focus on security and service enablement. The goal of the UM Labs products is to interconnect VoIP components and networks as simply as possible while maintaining effective security controls on those interconnections.

Session Border Controllers have a different focus. While they also provide interconnection between networks, they achieve this with services such as protocol conversion and media transcoding which are not offered by the UM Labs products because these services are not needed for the type of connections managed by UM Labs. As SBCs tend to be used in trusted telco networks, they place less emphasis on security than the UM Labs products.

However the biggest difference between a SBC and a UM Labs SIP Security Controller is cost. The UM Labs product line has a much lower entry cost than any SBC product, and for larger networks UM Labs offer a very competitive alternative to a SBC.

The UM Labs product line is compatible with all SIP capable SBCs tested so far. A large organisation running a SBC at the hub of their network should consider running a UM Labs gateway at each of their smaller locations to protect the systems at those locations.

I am concerned about call eavesdropping, how can UM Labs help me?

All UM Labs products include encryption for both SIP signalling and RTP media. SIP signalling handles call setup and other operations such as call transfer and call termination. RTP transports the media streams, the voice call or video conference.

By encrypting both signaling and media the UM Labs SIP Security Controller protects calls from unauthorised monitoring and eavesdropping.

UM Labs implement the recognised standards for encrypting VoIP calls established over the Session Initiation Protocol (SIP). SIP Signalling (call set up) traffic is encrypted using TLS. RTP media (voice or video traffic) is encrypted using SRTP. UM Labs' products support strong symmetric key encryption algorithms, up to 256 bit AES for TLS and the defined standard 128 bit AES algorithm for SRTP.