VLANs, Security Feature or Small Speed Bump?

As a security expert, primarily involved in UC implementations, I have been requiring VLANs for all VoIP/UC implementations. This was primarily based on a security best practice that has been viewed that this creates separation between the voice and data networks. While this is favored for various reasons, which we will discuss later, does this truly create separation?

There are countless articles on the security implications and potential attacks on VoIP/UC VLANs, which is a somewhat pertinent to here. However, we are not going to go into great details on this. Jason Ostrom and John Kindervag have a great write-up on VLAN Hopping and the Voiphooper tool here VoIP Hopping: A Method of Testing VoIP security or Voice VLANs. Overall, the concept is simple, the attacker sniffs for CDP (Cisco Discovery Protocol) packets to obtain the VLAN ID. The next step in this attack is to set your PC to that VLAN ID and gain access to the Voice VLAN.

As we all know, for the most part, at this point all bets are off. Most people are not deploying VoIP/UC with   encryption  or, if they do, it is the first thing disabled during call quality troubleshooting.

Ultimately it is never re-enabled.

In an attempt to mitigate this risk, many people have begun utilizing port security, which relies upon Mac address filtering to protect the VLAN. As we all know, this is pretty much a joke. In all honesty, anyone, even those with little technical abilities, can find information on how to change their MAC address. Additionally, 802.1x has been proposed as another mitigation, which can still be worked around.

Additionally, in most current deployments, soft phones are becoming more and more common. This convolutes the issue even more! Soft phones are installed on the local PCs and the required SIP and UDP ports must be accessible from the data network. This makes life much easier for an attacker, as we mentioned earlier  encryption  is seldom enabled. Thus, this traffic is very easy to intercept.

As we can see, with these few risks on the Voice VLAN, I come back to my original questions; does this truly create separation? Also, I come to another questions; is this truly a security requirement?

So, as we can see from the information mentioned earlier, no, in fact, VLANs do not truly create separation. This is especially true as soft clients are deployed. As we can see the core Voice servers are separate, to a point. However, there is a definite convergence of data and voice due to the soft clients.

In reference to the second question; is this truly a security requirement? I do not think so. Originally, from what I have read and can gather, it was being push by the vendors to create QoS. This is fantastic! With voice call quality being is very important, as we know. Additionally, I think that this was, to some extent, a security requirement due to the lack of buy-in for  encryption  requirements or availability of  encryption  from vendor’s years ago. Thus, it has been perpetuated as a security requirement and feature for quite a while.

So, this is all fine and dandy! VLANs are NOT a security requirement? They are great for performance and QoS? However, what do we do now? If we are to no longer require the utilization of VLANs for VoIP/UC, what protections can we put in place to maintain or surpass the status quo of risk mitigation?

I think the short answer to this is requiring the utilization of  encryption  on both signaling and media sessions. As we have seen the primary concern and issues within VoIP/UC are interception and manipulation of the voice/video stream over the wire. Also, authentication of the endpoints must be utilized and we must ensure that the requirements on this authentication are in compliance with today’s standard security best practices.

This is a short list and I am sure there are other things that can be utilized to protect the VoIP/UC traffic if it is not within a VLAN. I welcome any additional ideas/comments.

Source by Nicholas G Grant