Firewalls or SBC’s? What’s the difference to you and me?

Seems like this question comes up a lot in our business. Controlling access to a site is critically important for most enterprises and the most common way to enforce policies is a firewall. Why then, do most Voice Operators use Session Border Controllers for access control? The Answer, like most things in VoIP communications, requires a bit of history and a little explaining. Let’s jump right into it!

What does a Firewall do?

Firewalls provide stageful control of interfaces (open or shut) for layers 2-4 of the OSI model (from the frame to the network segment). Newer firewalls have some Layer 7 (application) capabilities, but the majority of control is exercised on layers 2-4. In VoIP, there are two kinds of streams: media and signaling. Signaling is all about call setup and teardown (or any other action you’d like to perform) whereas the media is the actual audio being exchanged. While a firewall has to open only a couple ports for signaling, Media exchange requires opening a lot of ports, sometimes as many as 20,000. For Security Conscious Enterprises, this can be a deal killer, and so there are attempts to place Firewalls into the DMZ which can complicate things even more.

The gist of this is that Firewalls are great at enforcing port policies, but aren’t sensitive to the specifics of a particular application.

How does a Session Border Controller contrast with a Firewall?

If a firewall is a gate, a session border controller is a canal. Whereas a gate can only be opened or shut, canals have a series of trenches which are filled and then released. This buffer allows much more complex checks and adjustments than a simple open or shut gate. A Session Border Controller has some of the layer 2-4 port controls, but where they really shine is in their Layer 7 capabilities. SBC’s control port access based on signaling from the application. Whereas a firewall is either open or shut, an SBC can be adjust its availability based upon authentication and other criteria. Further, in certain circumstances (like NAT’d IP addresses) Session Border Controllers can rewrite SIP headers to private IP addresses, which helps internal to external routing mitigation (it makes it easier to get in/out of the firewall). Some firewalls do this natively in a way that damages the SIP packets (notably the SIP ALG transform on Cisco ASA’s for any Non-Cisco VoIP Packets).

Which one is better in a DDoS?

This is a little trickier. The heuristic analysis necessary to defeat mass packet attacks like a Distributed Denial of Service is different from the kinds of analysis one would want for countering malformed SIP headers. In certain cases (as exposed recently by the application SIP Vicious) a PBX can be attacked by rewriting the SIP address (similar to rewriting an IP Header) into a very long, or abnormal string. A normal Firewall would let such a packet into your system, which, depending on your PBX, could potentially disable the system for an extended period of time. As the firewall has no way of differentiating one SIP packet from another, this would be a case where an SBC’s application sensitivity would come in handy. On the other hand, if someone is pumping 50+ Gbps of traffic at your Public Facing IPs, you’re going to want a way to offload that traffic that an SBC may not be able to provide. For a large enough operation, the answer is that you’re going to want both, but an SBC is a critical portion of the infrastructure stack for VoIP, whereas a Firewall is something that is more general use and usually applied at scale in VoIP deployments.

So what’s the proper way to scale your boxes?

We suggest starting with Session Border Controllers and leveraging your hosting provider to deal with DDoS mitigation. Using Multi-homed DNS you can intelligently provide failover between multiple instances across the country with just a few clicks in an infrastructure like Amazon Web Services. At 2600hz we run Kamailio, which is our pick for best open-source SBC.

If this is interesting to you and distributed systems engineering makes you all warm and fuzzy inside, drop us a line at info@2600hz.com. We’re looking for a few good folks to come help us change the world by innovating Open Cloud Telecom.