Close this search box.

AudioCodes SBC – Security

Security is a top priority in IT environments today, and this also goes for telephony deployment. This article will give you an overview of the security needed for your AudioCodes SBCs to be solidly locked down for the purpose they are supposed to fulfill.

Throughout my career with Telephony, I have witnessed how fast and effective people with bad intentions can be. Plug your SBC into the public internet, and within minutes, you will start to see the first port scans. If holes are found, you will begin to see SIP calls coming in, trying to expose weaknesses in your configuration. If a weakness is found, the final step is to initiate calls, and the toll fraud machinery has begun.

What is toll fraud?

Maybe you have heard of a company that suffered from Toll Fraud and how they ended up paying thousands and thousands of dollars.

In short, toll fraud is when people with bad intentions use your phone system to do fake long-distance and premium calls. These fraudsters find the weakness in your configuration and start doing these fraud calls.

So how do we prevent these toll fraud scenarios and ensure the company telephony system is not abused?

We need to understand where on the network the SBC is. Some prefer to put it on the LAN, while others want to lock it down in a demilitarized zone or DMZ. No matter what configuration and where the SBC is located, we need to pay close attention to the vendors firewall requirements. I will focus on Microsoft port/protocol requirements as I work with Microsoft products. But you can use these guidelines and implement them with your vendor requirements.

I see many companies using public IP addresses directly on the SBC. There is nothing wrong with that, but there are some rules we need to make sure we follow.

Here are some quick rules you can go by when you configure the SBC equipment.

  1. Only expose the SBC to the internet with a configured SBC firewall. We want to lock the SBC down to only communicate with the IP addresses we want and the port/protocols needed.
  2. Use certificate encryption on signaling, especially if you connect the SIP trunk directly to the SBC via a public IP address.
  3. Enable Mutual Transaction Layer Security (MTLS)
  4. Use either classification by proxy set(Only allow communication with IP addresses defined in the proxy server address list) or classification filters.

Firewall configuration

Considerations around the firewall, especially on the WAN interface, should block everything and allow only the connections we want. Here is a list of regular firewall port openings for Microsoft Teams Direct Routing.


Media Traffic

DNS – Specified and locked down to single IP addresses
MS Teams IP ranges – and
SIP trunk signaling port – locked on port/protocol and IP address

Certificate encryption (TLS)

If the SIP trunk is configured directly on the WAN interface, we should always use TLS as a protocol. Some providers (still??!) do not support this. That is a risk, as you would have to open a port sending unencrypted data, which can be exploited to manipulate SIP headers by adding lines in the header, and that way open up for rerouting calls and so on.

Enable Mutual Transaction Layer Security (MTLS)

In Microsoft Teams direct routing, it is default to use one-way TLS authentication. You can enable two-way authentication, or MTLS by adding the following certificates.

  1. Baltimore Cybertrust Root – Valid until 2025
  2. DigiCert Global Root G2 – Valid until 2038

Link to Microsoft certificates

Import these certificates to the Trusted Root certificate store on the SBC, and remember either PEM or PFX format for the certificates. MTLS is enabled in the SIP Interface under security, as shown in this picture.

Classification by proxy set and Classification filters

Let’s add another security layer before the call is processed. We do that by adding Classification filters of the call to the equation. Classification by proxy set is an IP group parameter, which will classify the incoming SIP requests, such as invites, and ensure that only IP addresses specified in the proxy set are allowed to proceed for call initiation.

Classification filters look at calls coming in on specific SIP interfaces and source IP groups and will classify the call on the parameters specified. Typically we classify the call on the destination hostname and the source IP address. But we can also classify the call based on the source IP address alone, ports, and protocols.

Classification failures can be logged in the syslog and will be registered as an error code 500 classification failure.

SBC administration access

Next, I want to describe some of the options available to secure the login to the SBC itself. What use do we have of a fully secure SBC that uses the default Admin/Admin username and password?

The first suggestion is to create a new user account with admin privileges and then downgrade the Admin account, which is the default entry point on the AudioCodes SBC after unboxing and installation. This account and its default password are also documented in AudioCodes publicly available documentation. Funny enough, I still see AudioCodes SBCs with default password configurations.

Create new local administrator user(s)

create a new user with administrator rights and with a complex password. Make sure this is changed regularly. Degrade the Admin account to a user account, give it a password and lock that away in a password vault. You can configure the password complexity policy in the SBC.

You can activate the weak password detection feature if you are an IT administrator. This feature allows you to configure up to 150 weak passwords in a list. If any user is created with one of these passwords, it will raise a SNMP alarm which can only be cleared by reconfiguring the user’s password. The weak password list has a number of preconfigured passwords such as, yes you guessed it. Password, password, 123456 etc.

To configure the list, Log into the SBC, and go to Setup –> Administration –> WEB & CLI and Weak Password List.

The feature itself is activated in Setup –> Administration –> Web & CLI –> WEB Settings and under security, you have the Check Weak Passwords. Please be aware that this is a newer 7.4 feature(added with version 7.40A.260.007), so you might have to do a minor firmware upgrade. Here is what AudioCodes write in terms of upgrading from 7.2 to 7.4. Also be aware of hardware support if you are running a cloud SBC in either Azure, AWS, or Google Cloud.

Securing connections to the command line interface (CLI)

Unsecure telnet sessions should be disabled right away. If you insist on using telnet as your connection method to the CLI interface, you should consider using Secure Telnet, which will use TLS encryption. I don’t see any need for telnet, as the Secure Shell (SSH) has built-in security and is easy to set up and use. Go download Putty; it’s free and an excellent SSH connection tool.

If SSH needs to be more secure, consider enabling SSH public key authentication. I will write a how-to article on this later, as the subject is worth an article.

Securing the web access administration

By default, AudioCodes allow HTTP and HTTPS connections to the Web interface of the SBC. This can be narrowed down to only HTTPS and tightened up using MTLS and X.509 certificates for authentication.

To do this properly, you need a client certificate on the PC / Server you want to use for SBC Web access(assuming you have a PKI installed in your server infrastructure) and the certificate authority certificate chain installed on the SBC.

Cross-Site request forgery (CSRF Protection) is another layer of security you can add to your Web administration of the SBC. This feature prevents unauthorized commands from being run by a logged-in user. After a user has authenticated with the website via login with the correct credentials and starts browsing, a CSRF token is generated. When the user performs an action or a change to the website, this token is included to verify that the authenticated user made the change. This prevents people from “sneaking in” and making changes independently.


This sums up the security features we should configure on our AudioCodes SBCs. While some of the security features presented here are “nice to have,” there still are many “need to have” features that companies owning AudioCodes SBCs need to pay more attention to. With this article, I hope to bring more clarity on the subject. If you have any questions, please use the comments.

Leave a Comment