The SBC and the Enterprise Firewall

I’ve found over the years that the SBC’s placement and the surrounding network and firewalls is sometimes more important than the SBC configuration itself.

The enterprise firewall has always been a pet peeve of mine. The security teams generally like to use enterprise firewalls to secure and monitor all inbound and outbound traffic to the premises and between the different segments of carrier private networks, perimeter networks, trusted networks and in some cases SIP traffic going out to the Internet such as the new Microsoft Teams Direct Routing.

In general running SIP traffic thru an enterprise general-purpose firewall is not a great idea, even if that firewall has layer 7 features that claim to handle SIP traffic. In most cases these features are designed to alleviate media traversal issues for generic client SIP traffic for remote users registering to on-premises traditional IP-PBX. These features are typically not designed for SIP carrier traffic or vendor specific encrypted SIP traffic.

There is no real advantage to protecting the SBC traffic with an enterprise firewall as it will not provide any additional security over what the built-in firewall and defenses on the SBC already provides. When using enterprise firewalls for SIP carrier and general Skype/Teams traffic it is recommended to turn off all SIP related layer 7 features and open and forward all associated control and media ports.

The SBC is a much better demarcation point for SIP traffic as it is designed from the ground up with the SIP layer 7 protocol in mind and all it entails. It will provide for general ACL based on IP addresses and ports but will also provide for general IP and specific SIP denial of service attacks and spoofs. UDP media ports are being opened and closed dynamically based on the SDP negotiation in the SIP control traffic as opposed to staying open on the enterprise firewall.

Another layer of security on the SBC is that no traffic is routed at Layer 3. All incoming traffic on each network leg is terminated at the SBC and new layer 7 specific traffic is initiated and handled between the different network legs by the SBC engine. This is also called a Back to Back User Agent (B2BUA).

Modern SBCs typically also support the latest TLS and ICE-Lite support, which are requirements when connecting to Microsoft Teams Direct Routing aka “Bring Your Own Trunk”, which adds even more complexity if passing encrypted SIP traffic thru enterprise firewalls.

I always try to educate the security teams as to why we don’t need the additional layer of firewall security as it will add no value in most cases and will introduce a lot more complexity not only when building the solution but also the general operations and the occasional troubleshooting.

If an enterprise firewall is required by corporate policy in the call path, it’s important to understand which layer 7 features should be enabled and which shouldn’t. For Microsoft Teams Direct Routing it is also important to understand than when using NAT for the service as opposed to binding a public IP on the SBC there will be a lot more hair pinning of media happening.

SBC using Public Route-able IP address and WAN/MPLS back-haul

SBC using Network Address Translation (NAT) and WAN/MPLS back-haul

I am not a firewall expert, but I typically run into the same issues over and over and given the popularity of Palo Alto firewalls, which is what I see the most out there, I have a one pager that I provide the customer at the engagement start covering items to be aware of:

• SIP ALG performs NAT on the payload and opens dynamic pinholes for media ports. This may cause issues for some SIP implementations. This document describes how to disable SIP ALG.
  Palo Alto Networks document: How to Disable SIP ALG
• Under some circumstances, the SIP traffic being handled by the Palo Alto Networks firewall, might cause issues such as one-way audio, phones de-registering, etc. This document describes how to do an application override.
  Palo Alto Networks document: SIP Application Override Policy

For additional information on this topic, I have really only found one good white-paper that goes beyond the specific security features themselves and actually speak to this in conception. Orcale/ACME published a white paper: “Communications Security: A Blueprint for Enterprise Session Border Controller Deployments”. Even though this document is from 2015 and each security feature may differ from vendor to vendor, this is still quite relevant regardless of SBC vendor used in your organization.