The SBC and the Enterprise Firewall

I’ve found over the years that the SBC’s placement and the surrounding network and firewalls are 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 through an enterprise’s 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 legacy IP-PBXs. 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 SBC defenses already provide. 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 firewall and demarcation point for SIP traffic since it is designed from the ground up with the SIP layer 7 protocol, and all it entails, in mind. It will provide for general ACL based on IP addresses, but will also provide for general IP and specific SIP denial of service attacks and spoofs. UDP media ports are 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 the layer 3 level. 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 the Microsoft Teams Direct Routing (aka “Bring Your Own Trunk”). This adds even more complexity if passing encrypted SIP traffic through 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. On the contrary, it will introduce a lot more complexity not only when building the solution but also to general maintenance and occasional troubleshooting.

On a closing note, it will be interesting to see how Microsoft will implement the Media Bypass feature with Teams Direct Routing and how it will be accepted by the security community.