A very popular Topology for Direct Routing is to deploy a certified Session Border Controller into Microsoft Azure with SIP Trunks to Teams Phone System and SIP Trunks to a PSTN provider. There are Azure Datacentres all over the world, SBCs are rapid to deploy from Marketplace templates and SBC>Teams traffic effectively stays on the Microsoft CDN. Big carriers may have direct peering with Microsofts network, others will meet the Microsoft Network at Internet Exchanges (i.e. LINX in London). There’s no need to buy expensive WAN circuits and Compute costs for the SBCs are minimal, especially if on 3 year pricing. It’s just an awesome solution!
I have noticed something and it appears to be getting worse. As soon as you deploy an SBC from the Azure marketplace within hours you will start to see SSH attempts and even SIP call attempts. These must be automated bots looking for insecure services in Azure IP address ranges. It used to take a day or two before you would see this but my last few deployments it’s happened within a couple of hours. The screenshots below are from an AudioCodes SBC less than two hours have I deployed the template.
Some SBCs like AudioCodes have an inbuilt Firewall, but this means the SBC itself is doing the heavy lifting. That particular Firewall can also be challenging to configure. Top tip – If you do use the inbuilt Firewall, always configure your Trusted Management rule before adding your default 0.0.0.0 block rule :). There is an alternative option in Azure with Network Security Groups (NSGs). An NSG is a basic Firewall at the network layer in Azure that allows inbound and outbound filtering based on port, source and destination.
When you deploy an AudioCodes SBC from the Azure Marketplace it comes with a default NSG configuration as below (Other vendors may vary slightly).
As you can see there are some SSH, HTTP, HTTPS and SIP rules in place already, but they allow any source. This means that anyone on the internet can connect to your SBC on these ports (including those pesky Bots).
A recommended NSG logically would look like this:
Traffic is allowed to and from the PSTN Provider, Microsoft Teams and Trusted Management IP addresses. All other traffic is blocked. This is how I typically configure an NSG:
As a minimum you should configure the Inbound NSG:
1) Disable HTTP, only manage the SBC over SSH and HTTPS which are encrypted
2) Specify source IP Addresses for Management. (i.e Jump Box or your Office/Datacentre public IP)
3) Configure a Teams ACL for SIP and Media. Ensure source ports are locked down to Teams Signalling and Media IPs which are available here. Note the Ports are the local SIP interface and Media Realm on your SBC.
4) Configure a Carrier ACL for SIP and Media. Again the ports reflect what is configured locally on your SBC, ensure the source is your PSTN providers IP addresses (Signalling & Media may be the same or different IPs)
At this point if you try to do a Port Scan against your SBC from an untrustred IP address it will appear dead. You will also notice the SSH and SIP attempts stop immediately.
You can go even further and set Destination on the NSG to your SBC IP. Certainly with the AudioCodes VE template, the SBC is the only device that lives behind that NSG so not explicitly required. You can of course configure an Outbound NSG to restrict the destinations your SBC can get to if you think that will give you extra security. Don’t forget services like NTP!
For belt and braces you can also configure the SBC inbuilt Firewall if it has one. I love AudioCodes SBCs but the Firewall isn’t for the faint hearted. In my opinion it’s better to let the NSG do the heavy lifting and don’t even let those packets get to the SBC. I have had customers where their Security Requirements dictated the device Firewall must be configured in addition to the NSG/Perimeter Firewall. This is fine and what they are comfortable with, but I would always ensure in Azure the NSG is configured even if the device has it’s own Firewall.
Disclaimer – I am not a security expert, but I have been around long enough to know when something is completely insecure and the minimum you should do to mitigate those risks. I would always recommend you verify with a Security Consultant that your solution meets the Security Standards for your organisation.
Technical Architect at Symity