I am surrounded by religious zealots. No, I am not talking about Christians, Jews, Muslims, or any other form of organized religion. I am talking about the secular zealots who approach technology as if it was religion. You know the type. Mac vs. Windows. Firefox vs. Chrome. Android vs. iPhone.
My latest struggle has to do with those who proselytize their views on Session Border Controller (SBC) placement. Does it belong on the network edge or within the DMZ behind an enterprise firewall? You might think that this would be a fairly straightforward decision, but I’ve found that the “experts” fall into two different camps.
Camp One – Sitting on the network edge
The argument employed by these folks is that an SBC is a standalone security device. It was designed to keep the bad guys out and let the good guys in. An SBC is a Back-to-Back User Agent that does a deep packet inspection of every SIP packet that enters or leaves an enterprise’s network. It can detect and reject badly formed or suspicious SIP messages. It can stop denial of service (DOS) and distributed denial of service (DDOS) attacks. It can detect bad login attempts and block hackers. An SBC maintains a blacklist of malicious IP addresses and prevents rogue users from accessing your communications system.
In other words, an SBC is a SIP firewall. It does not need a traditional data firewall to pre-process packets before it sees them.
How the SIP messages get to the SBC depends on the network topology. If the SIP packets arrive on a dedicated WAN connection then you simply send everything straight to the SBC. However, if SIP packets share the same WAN connection as other data packets (e.g. HTTP) then some sort of VLAN separation is necessary. One VLAN would be dedicated to SIP and the SBC and the other VLAN would be used by the data firewall.
Camp Two – Behind an enterprise firewall
In this case, SIP traffic hits the data firewall before being passed to the SBC. It’s important that any and all SIP processing be disabled within the firewall. By this I mean that all “SIP detection,” “SIP inspection,” and “SIP ALG” must be turned off. Anything that arrives on ports 5060 (SIP) or 5061 (TLS) will be sent directly to the SBC for processing. The SBC will direct the firewall to send all subsequent RTP and SRTCP traffic to the SBC.
Once the SIP traffic has been handed off to the SBC, all the “Camp One” benefits are realized. A data firewall does not inhibit an SBC from performing its role as a security agent.
There are multiple arguments employed by the Camp Two people to state their case.
First, most modern enterprises already employ a DMZ flanked by internal and external firewalls. A session border controller should fit into a standard security architecture and not be treated as an anomaly.
Second, security should be applied in layers and SBC features are just another layer in a comprehensive and cohesive security process.
Lastly, as enterprises move from basic SIP trunks to remote SIP users, protocols beyond SIP become necessary. The data firewall will handle the non-SIP protocols and the SBC will deal with the SIP aspects. The remote user sends all its packets to a single IP address and the firewall acts as the traffic cop.
My thoughts
I understand the arguments on both sides and appreciate their thoughts and concerns. To me it comes down this:
- If an enterprise’s policy is to send everything through the DMZ and corporate firewall(s), then do so. Firewalls and SBCs can be configured to play together nicely.
- If you are using remote users that require more than SIP to function properly, put the SBC behind the firewall. Let each security element deal with what it knows how to deal with.
- If you are only looking at SIP trunks and have no strict DMZ policy, put the SBC where it makes sense. Separated SIP and non-SIP data circuits make it easy to decouple an SBC from the data firewall. A single data circuit requires you to either implement VLAN separation or configure the SBC and firewall to work together. Pick the configuration that works best for you.
Let Us Pray
As I said in the beginning, some of this is religious, but there are also practical reasons as to why you would go one way or the other. Like most things in life, don’t approach this blindly. Think about what you are trying to accomplish, adhere to existing policies, and make an intelligent choice.
Can I get a witness?
Tao, Zen, and Tomorrow 
Very helpful Andrew
Thank you!
I SOOOO… agree… I got the same question of where does it go. I smiled, you know… the smile that tells them were it goes… yea that one. They didn’t get it. |o(
I know security is a big concern and when it finally dawned on the security folks of just what this was did… They told me to put it anywhere I wanted. The still didn’t get ‘the smile’.
IMO, where it goes depends on what people know. If you educate people from the various discipline, which could mean using references from their own discipline, they should get it and make informed choices. Then again, they may ask you where you want it.
I don’t understand why the laugh at me, when I answer… the wall.
Alan
an SBC is much more that a SIP firewall. Besides SSL/TLS, NAT, STUN, back to back user agent, it provides SIP message processing and translation to the enterprise PBX, billing data, rtp and QoS logs, SIP logs, codec translation, etc… Since it does more than a firewall, ans since most enterprise already have a firewall, why spend more on SBC hardware to process trafic that has nothong to do with SIP. The same principle aplies to SBC than IPS/ IDS and DDOS. first layer, DDOS, then IPS/IDS, then firewall, then SIP to deal with only SIP messages. If you are a SIP service provider, you might want to simply your architecture with a one-box-does-all type SBC. As a general principal keep edge functions in the firewall : SSL/TLS and NAT. Then leave the SIP feature processes in the SBC an save on hardware purchase.
Got a lot of value out of your blog post Andrew.
It answered all the queries i had in my head. Cheers