Securing your voice traffic, but how?
Understanding how voice is encapsulated and its vulnerabilities.
Explaining the importance of network security to our clients could be challenging. Two months ago I helped deploy a new Session Border Controller for one of our clients in Jacksonville FL. They were hesitant on adding this piece of equipment to their existing network topology, asking questions, and been very hesitant on allowing us to continue with the implementation.
Their Management team made the decision of buying this SBC Server after explaining to them how important was adding this type of security to their network. Once the decision was made to move forward with the solution, they failed to announce it to the rest of their team here in Jacksonville FL. Unfortunately this is not the first time that I find myself involved in this kind of predicaments. Working here, I deal with lots of remote site deployments.
I decided to write this post “Securing your voice traffic, but how?” to give you the basics of the importance that is to secure any type of network topology.
With customers buying third-party’s services located on remote servers. Services such as email, data storage, voice, and salesforce just to mention a few of them, calling this “the cloud”. It makes the customer’s network more vulnerable to attacks. So how can we secure the voice traffic?.
I came up with these rules that will help you start securing your VoIP Topology:
- 1.- Equipment Failover and Room Security
- 2.- SIP End-points over H.323
- 3.- Understand RTP, SRTP and SRTCP
- 4.- SBC and Firewalls
Equipment Failover and Room Security
Equipment Failover – When dealing with networks, and core servers, failover procedures are a most. From installing backup generators or battery backups, calculating the lifetime of a battery to keep the servers running for x amount of time.
Room Security – Having restricted access to IT Rooms, including Intermediate Distribution Frames (IDFs). These are the intermediate rooms that interconnect multiple floors or building wings (e.g. east wing and west wing).
VLANs – Always good to segregate the voice and data traffic creating VLANs and ACLs.
SIP End-points over H.323
I know that we are not ready to go 100% SIP End-Point with most of the existing solution been deployed, but the fact of the matter is that SIP has the capability that H.323 doesn’t have, and that is been able to secure the voice transmission over network connections, also providing better reliability. For PC’s Soft-phones the technology is here. I suggest you take time, initiative and implement it if possible.
Understanding RTP, SRTP, and SRTCP
Encapsulation – By now you should know that a voice sound is an analog wave/frequency. When a call is made the phone server will convert it to digital then encapsulate it to IP, the process is reversed at the receiving end. I wrote a blog post about voice transcoding which explains how resources are used to help establishing communication.
Instead of painting the entire picture I will focus on data encapsulation portion of the process. The gatekeeper will convert digital into data using Real Time Protocol over UDP. RTP (RFC 3550) is a protocol with the ability carrying media streams (voice, video, and Instant Messaging).
RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of service guarantees, but relies on lower-layer services to do so. It does’t guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender’s packet sequence, but sequence numbers might also be used to determine the proper location of a packet, e.g. in video decoding, without necessarily decoding packets in sequence.
SRTP – is Secure RTP allowing systems to secure the media streams by encrypting the data being transmitted, and only the sender and receiver have the decoding key. If an intruder is trying to use wireshark or any type of network sniffer to capture your conversation, they won’t be able to tell what’s been transmitted or replayed. Using AES (Advanced Encryption Standard) to encrypt the media stream.
SRTCP (Secure Real Time Control Protocol) is used to secure control and reporting information, preventing intruders from sending messages during the media transmission such as “BYE” disconnecting an existing phone call, etc.
Firewalls, SIP-Awared Firewalls, and SBCs
Firewalls – Yes firewalls can protect and in some cases it might work as designed, or you may say the the ALG might be sufficient for securing the connection. The reality is that opening ports or using the Application Level Gateway (ALG) might not be enough. in fact I had multiple cases where having ALG turned on in the firewall causes lots of data transmission issues, resulting on more time spent troubleshooting issues related to undelivered media transmission and dropped packets.
NAT – You might even think of implementing NAT for your remote workers. the issue here is that the transmission will go out from a private network to a public. the SDP body will contain the senders private IP Address information, when the receiver gets the data, it won’t contain the sender’s Private IP info, resulting on dropped packets.
SIP-Aware Firewalls/ALG – These devices will allow the media stream traverse from point A to point B inspecting each SIP packet, and substitute the private IP Address with the public IP Address of the firewall/ALG. This mechanism lets both devices communicate successfully.
Session Border Controller – Is like night and day. SBC is more flexible and easier to configure. The SBC Application gets installed on a blade server. The server will normally connect directly to the ISP’s Router. Depending on the ISP, ports and other settings might need tweaking a bit. Then you have to connect your GateKeeper (PBX) to the server or LAN. For better security and troubleshooting purposes I suggest connecting the SBC directly to the PBX.
The Two Wire-Topology (is also known as in-line) Connecting the SBC Server to the edge of the network (Customer’s LAN) in the DMZ, directly in-line with the Gatekeepers (Call Server). Performing border access control functionality acting as Firewall and NAT put together, providing these services for internal and external access management. Domain policies and intrusion functionality to protect against DoS (Denial-of-Service) attacks, spoofing, etc.
Quick Note: The PBX needs a SIP trunk configured connected to the SBC.
These are some of the features provided by the SBC=
- Topology Hiding – This is a feature that allows to manipulate sip messages parameters to mask how the enterprise network might look to hackers.
- Policies – Create different policies within the SBC Server.
- QoS Settings – To allow for Quality of Service
- And more.
I also include this comparison of a SIP/ALG-Aware Firewall and SBC
Firewall with SIP ALG
- Maintains single SIP session through firewall (FW)
- Is fully state-aware at layers 3 and 4
- Only inspects/modifies SIP and Session Description Protocol (SDP) addresses
- Unable to terminate, initiate, reinitiate, or respond to SIP signaling messages
- Only supports static access control lists (ACLs) and policies
SBC
- Implements SIP B2BUA for complete control
- Is fully state-aware at layers 2 through 7
- Inspects/modifies all SIP and SDP header info
- Can terminate, initiate, reinitiate, and respond to SIP signaling messages
- Supports static and dynamic ACLs and policies
Resources
- Adtran SIP-Aware Firewall Doc
- NIST – Security Considerations for VoIP Doc
- Oracle – Comparing SBC to Firewalls with SIP Application Layer Gateways in Enterprise VoIP and UC Scenarios.
- Cisco VLAN and ACLs.
Please note: I reserve the right to delete comments that are offensive or off-topic.