Menu
Separation of Untrusted Network Traffic on AudioCodes SBCs
Introduction
This is the third in a series of articles on hardening AudioCodes Session Border Controllers (SBCs). The series is mostly following the guidance provided by AudioCodes. These articles are listed at the end of this article.
AudioCodes recommends untrusted network traffic be both physically and logically separated on their SBCs and Media Gateways to enhance the device’s security stance. This is the foundation when hardening these devices. This separation also makes configuration and troubleshooting on the device much easier. Your network security people will be happier with this configuration because it will require fewer rules and open ports for individual public IP addresses on the firewall. It will also reduce the attack surface to each interface. If a network interface on the SBC handles both Teams and Contact Center traffic, an attack on the public IP of the Contact Center will affect your Contact Center and Teams traffic. If separated, the attack would only impact the Contact Center.
Can this be achieved in all deployments in all cases with your existing SBC? No. Though your existing SBC may have enough horsepower and SBC capacity licenses to meet your needs, the SBC itself may not have enough physical ports to separate all your untrusted network traffic.
Trusted and Untrusted Network Traffic
AudioCodes defines your Local Area Network (LAN) as a trusted network. The SBC’s interface to your LAN is typically used as the SBCs Management Interface. This interface can be used to interface the SBC to SIP enabled PBXs, Analog Transfer Adapters (ATAs), SIP enabled endpoints, paging interfaces/systems, door access devices, etc. Traffic to these entities is usually not physically separated on SBCs but should be logically separated, not so much for security reasons but for ease of management and troubleshooting. The AudioCodes guidelines presume that customers have their trusted network houses in order as far as security is considered.
All other networks are treated as untrusted networks. It is essential that you take extreme caution with your untrusted networks. The interfaces to Microsoft Teams and your SIP Trunks are untrusted. Connections to Teams Direct Routing Contact Center Solutions, Dynamic 911 Emergency Response Service Providers (ERSPs), etc. would also be untrusted. Each of these entities should be physically and logically separated on your SBCs. If you have SIP Trunks from different vendors, can you set them up on the same physical interface of the SBC? Yes, should you, no!
Physical Separation
The most obvious physical component on an SBC is the number of available physical network interfaces:
And now for the math portion of our show:
Next, a bit more complex:
And even more complex:
It is easy to see that we can quickly run out of physical ports on an SBC.
We worked with a customer with a highly available pair of Mediant 4000s with eight (8) ports each. They had four (4) untrusted networks they needed to contact to:
Since the SBCs were in an HA pair, the decision was made to aggregate two (2) ports for the HA system and use single ports for the trusted network and the four (4) untrusted networks. The logic behind this decision was that because the SBCs were paired, each network has two (2) resilient ports. The client felt that they could abandon the aggregation for the other networks on the SBCs since they were setup as an HA pair:
On the SBC:
We can use the “Topology View” on the SBC and a table to see how these objects are laid out. We can clearly see that we have physically separated the trusted from the untrusted networks and the untrusted networks from each other on the SBC:
What do you do if you do not have enough ports on your SBC?
You have a few options:
Logical Separation of Untrusted Network Traffic
On the SBC:
We can use the “Topology View” on the SBC and a table to see how these objects are laid out. We can clearly see that we have physically separated the trusted from the untrusted networks and the untrusted networks from each other on the SBC:
Logical Separation of Trusted Network Traffic
Physical separation of these various SIP requirements on the SBC in most cases will not be an option. The SBCs will usually not have enough physical ports to support several different SIP entities that need to route calls to/from the SBC from the trusted network. It might be difficult to make multiple physical connections to a single SBC from the same LAN. Generally, it will be impractical and could be impossible to effect physical separation of this traffic on your trusted network. However, you can and should implement logical separation of the traffic.
The same customer, described previously, had a SIP enabled PBX and several AudioCodes MediaPacks that needed to route traffic to/from the SBC. The solution was to create unique sets of the Core Entities for the PBX traffic and the MediaPack traffic. These entities were all associated with the LAN IP interface. We can see these in an updated “Topology View”:
But there is a catch!
Not a big terrible catch but something you need to be aware of:
What about SRDs?
The Bottom Line on SRDs
Summary
Our team is available and ready to answer any questions that you might have about SBC hardening and security as well as overall security for your enterprise. If you need help in implementing a security infrastructure for your organization, please contact us at info@egroup-us.com.
Bibliography
AudioCodes has written documents addressing security on their Session Border Controllers and Gateways. There are versions for the 7.2 and 7.4 firmware in which they discuss the importance of setting up the SBC’s firewall rules:
The AudioCodes SBC user manuals can also be found in the Library section of the AudioCodes website.
Cloud Solutions Architect - eGroup | Enabling Technologies
Last updated on July 31st, 2023 at 01:03 pm
