In a previous post about the four crucial functions that a Session Border Controller performs in a UC network, we made passing reference to how an SBC is different from a firewall. But it left me looking for some additional details.
So I caught up with Thomas Negron, senior systems engineer for Sonus Networks, which makes SBCs. He proved to be a fountain of information on the topic and, as it turns out, the list of differences between firewalls and SBCs is long.
Before we jump in, Negron is quick to point out that Session Border Controllers do not replace firewalls. Rather, an SBC complements firewalls, providing functions that firewalls don’t, but not all of those that firewalls do.
SBCs: Providing Security for SIP-enabled Traffic
To get nerdy right out of the gate, a firewall looks at traffic at Layers 3 and 4 of the OSI stack, including IP and TCP/UDP traffic. SBCs, on the other hand, can deal with any layer of the stack, up to applications at Layer 7. The Session Initiation Protocol (SIP), for example, which is used to set up and tear down real-time communications sessions such as those in a UC network, works at Layer 7.
Normally firewalls have fairly static configurations. They allow traffic from certain points to flow through specific ports to a defined destination, subject to certain thresholds, such as to prevent traffic overloads. And it can stop traffic from any end points that are not allowed.
Dig Deeper: Download Session Border Controllers for Dummies for Free
Some firewalls go a step further and have limited awareness of SIP, Negron says. Maybe they’re able to dynamically open and close known SIP ports, rather than leaving them pegged open as a normal firewall would.
An SBC, on the other hand, has full awareness of the SIP stack and the Real-time Transport Protocol (RTP), which is used to carry traffic such as voice and video. As such, it can “peel the onion and have an inherent awareness of where packets are coming from and going to, how they should be formed and how to identify malformed packets,” Negron says. Those malformed packets may be legitimate packets or could be malicious; with its awareness of the larger picture, an SBC can tell the difference whereas even a SIP-aware firewall could not.
That capability enables an SBC to police against attacks that occur at higher layers, such as on video or audio streams. An SBC could detect and prevent a denial of service attack targeting a video port, for example.
With its application layer awareness, an SBC also understands what kind of bandwidth rates and packet sequencing are required to prevent a flood of RTP packets from inundating the network, a capability that is beyond the scope of a firewall.
Likewise, an SBC can detect when someone is trying to spoof caller ID numbers or hack into a PBX. The hackers can then force the PBX to dial out to numbers that no one in the company would normally dial, such as costly 900 numbers whose owners give the hackers a cut of the profits. The New York Times recently ran a story detailing how a seven-person architecture firm fell victim to the scheme:
Hackers had broken into the phone network of the company, Foreman Seeley Fountain Architecture, and routed $166,000 worth of calls from the firm to premium-rate telephone numbers in Gambia, Somalia and the Maldives. It would have taken 34 years for the firm to run up those charges legitimately, based on its typical phone bill, according to a complaint it filed with the Federal Communications Commission.
An SBC would have been able to thwart such an attack because it would have identified all those calls as out of the norm. That’s because SBCs understand the state of call sessions - including number from and number to, user name and company policies around time of day routing, least cost routing and such – and can police all of these aspects to ensure adherence to policies.
SBCs can also encrypt sessions when required, which is a best practice on Microsoft Lync networks, Negron says. “So if someone gets access to a switch they can’t just tap in and hear your credit card number over the phone.”
Beyond Security: How SBCs Provide Interoperability
SBCs also diverge from firewalls by providing a number of functions that go well beyond the security focus of firewalls.
One significant capability is providing interworking that enables different flavors of SIP to work with one another. “SIP was purposely written to be very broad, which means everybody’s SIP variant is a little different,” Negron says. “An SBC knows about these variants and can interwork between them.” That enables a Microsoft Lync UC implementation to work with Cisco UC applications, for example. “It lifts the burden of interoperability off the customer,” he says.
Similarly, an SBC can provide transcoding between different protocols, such as the older H.323 for voice and video and SIP.
In a future post, we’ll dive deeper into that toll fraud scenario, as it’s a great example of the value of an SBC.