Author’s note: This is the second of a three-part series of posts on Session Border Controllers. You can read the first post, Session Border Controllers – 5 Reasons Why Your Company Needs One.

We all know unified communications (UC) security is important, and perhaps you think your network is secure because you have a firewall. Many people have the perception that their firewall handles most of what a Session Border Controller (SBC) does, so they contemplate whether it is worth purchasing an SBC for their security needs. Well, there is a clear answer to this - a firewall will not properly protect your UC network. An SBC’s ability to dynamically protect an enterprise from SIP-based attacks gives it a huge advantage over the sole use of data firewalls.

Let’s start by examining the differences between a firewall and an SBC. First, by looking at a usual firewall security solution; a router forwards packets through a firewall that connects to the local area networks associated with a server or end point device. The firewall determines what connections and applications go to and from this device. In this setup, enterprises statistically configure firewalls to block or allow specific ports that correspond to IP addresses. This provisioning enables an enterprise to allow or impede access to websites or applications outside of the enterprise. The firewall generally uses static packet filtering and works using a binary system, where the state of a port (open or closed) is determined before a session is started.

Unfortunately for firewalls, SIP-based communications with mid-session additions and changes requires highly stateful tracking and ports to be dynamically opened and closed. Here at Ribbon, we did extensive testing to learn how a next-generation firewall with a SIP Application Level Gateway (ALG) enabled works.   Below are samples of our findings on the UC security holes exposed with a next-gen firewall.  (For an interesting and enlightening exercise, do a google search on “SIP ALG” and the top hits will be how to “disable a SIP ALG”.)

Ribbon’s Findings / Security Impact on UC

• Next-gen firewalls do not police bandwidth on UC Ports
  • Theft of service implication: more data will be passed than negotiated leading to possible data exfiltration exposure
  • Denial of Service (DoS) implication: downstream endpoints can be flooded, which will impact service or crash the SIP stack
• Next-gen firewalls do not close UC Ports upon session termination; they rely on inactivity
  • Theft of service implication: bad actors can maintain a session longer leading to possible toll fraud
  • Service impact: call transfers and one-way audio flows may be broken
• Next-gen firewalls can only parse SIP headers on a limited number of fields
  • Perimeter breach: Bad actors and robo-callers can spoof a SIP call and trigger ALG to open ports
  • Perimeter breach: SIP sessions could pass unknown headers that can carry attack payloads
  • DoS implication: downstream endpoints can be flooded with protocol errors, which will impact service
• Next-gen firewalls do not support real-time communications (RTC) flows over non-User Datagram Protocol (UDP)
  • Service Impact: Transmission Control Protocol (TCP) is used for multiple UC services (file transfer, conference control, etc.), so the UC applications will not function properly
• Next-gen firewalls do not support SIP registration parsing and state caching (SIP-based UC requires knowledge and state of user identity). 
  • Theft of service implication: bad actors could make free UC calls (toll fraud)

The key difference between a next-gen firewall and an SBC, is that the SBC is designed to monitor the SIP signaling messages used between two endpoints, and this is where an SBC has a clear advantage. After authenticating that both devices should have access to communicate, the SBC monitors SIP signaling to understand what ports need to be dynamically opened. Suppose you have a call coming into to your device, the SBC, because it is inspecting the SIP signaling messages, is aware of what ports to open and when to close them. This is important as there are tens of thousands of IP ports that can be used by communication protocols (i.e. RTP), so it would be impossible to have the correct two ports chosen out of that number with a statically provisioned firewall. The SBC uses this information to dynamically open the ports. More importantly, as the call finishes, the SBC automatically closes these ports. Essentially, an SBC provides an overarching, policy-based control layer to dynamically secure your unified communications.

Therefore, you should look for SBCs that are built around these best practices:

• DoS/DDoS Prevention — Denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks can take down an enterprise UC network for minutes or hours by flooding the network with SIP requests. (If you’re wondering what the distinction is, a DoS attack is usually one device generating thousands of these requests, while a DDoS attack involves thousands of devices generating a single request). An SBC, therefore, must be able to identify DoS and DDoS attacks through a mix of end point recognition (e.g., is the request coming from a known attacker?) and pattern analysis (are thousands of devices sending an identical request?).
• Topology Hiding — An SBC should act as a wall that protects the identity of phones, computers and other IP devices behind it. This practice, known as topology hiding, prevents attackers from targeting and/or exploiting a specific device that has an IP address (e.g., an IP-enabled phone or PBX) in order to illegally access voicemail or other services.
• Rogue RTP Protection — RTP stands for Real-Time Transport Protocol, the protocol that is responsible for delivering real-time media like voice and video. In the case of toll fraud, unauthorized (or Rogue) RTP communications enter the network illegally. An SBC should include provisions to detect and block Rogue RTP media streams.
• Media Encryption — Encryption refers to cryptography: a system of using complex digital “keys” to lock and unlock information. Media encryption, therefore, refers to locking the media itself (i.e., voice, video or data) so that prying eyes cannot eavesdrop on private communications. The standard form of media encryption in the world of SIP is called the Secure Real-Time Transport Protocol (or SRTP).
• Signaling Encryption — In addition to media encryption, signaling encryption is recommended to authenticate the end points in any SIP-based communication. There are two accepted signaling encryption standards in SIP: TLS (Transport Layer Security) and IPsec (IP Security). Because some industry standards require different signaling encryption methods (e.g., IPv6 recommends IPsec), it is best to have an SBC that offers both encryption methods.
• NAT Traversal — A NAT firewall “hides” the IP address of end points (phones, PCs, etc.) behind it, which presents a challenge during SIP sessions because it prevents end points beyond the firewall from establishing a direct connection with an end point inside the firewall. As a workaround, SBCs can create a secure pinhole in the firewall by “re-pinging” the NAT-protected end point every few seconds. This allows the two end points to keep a consistent connection for the duration of the SIP session.

Hopefully this provides you with a high-level overview of  why a next-gen firewall will not secure your UC network and users. I encourage you to check out this whitepaper to learn more about the various types of UC attacks and how to best secure your unified communications network with an SBC. 

My next blog will cover how SBCs and policy servers can provide intelligent session control in multi-vendor IP networks.