Jump to content

Securing a cloud install, SBC


mcbsys

Recommended Posts

I'm running Vodia 68.0.26 on Azure. I like to use the Azure firewall to protect the PBX as much as possible. For 3CX, this meant:

  1. Allow SIP (5060 TCP/UDP) _only_ to/from the the trunk provider. This means no one else can send SIP traffic. (I also set up the trunk provider to restrict SIP traffic to only the PBX's IP address.)
  2. Allow RTP media (UDP) from anywhere.
  3. Allow 3CX tunnel (5090 TCP/UDP) from anywhere. This is used by the on-premises Session Border Controller client, running on a Windows computer, and by the various apps (Windows, cell phones).
  4. Allow the web app (443 or 5001 TCP) from anywhere. Used by the admin interface and web client.

I'm trying to wrap my head around how this is going to work in Vodia without #3 to tunnel SIP and media from the customer site to the server. I assume that I need to additionally open 5060 to the customer's IP address for their desk phones? And the phones will automatically negotiate and connect whatever audio ports they need without additional configuration on my side? The apps don't need 5060? I've already configured "private public" at System > Settings > SIP > Settings > IP routing list, which I guess is what Vodia calls an SBC? Or do I need to set up a VPN?

Thanks,

Mark

 

Link to comment
Share on other sites

Hello mcbsys,

First of all, here you will find a table, To ensure proper functioning, you should also set the releases as described in the table.

https://doc.vodia.com/docs/vodiaports

Basically, you will also find the descriptions for provisioning the phones in the docs. Various provisioning options are offered.

Since you had previously provided with 3CX via SBC,  I would like to recommend provisioning them via the MAC. Personally,

I think this is the safest option anyway. Here you can find the instructions for e.g. Snom (Syncing All MACs on the System):

https://doc.vodia.com/docs/pnp-snom

If you are doing it for the first time, I recommend you start with the SIP Transport Protocol setting (Tenant/Settings/General

Settings/Provisioning Parameters), default. For this purpose, the entry in e.g. Snom (point 2), http must be made. 

If everything is completed successfully, this setting can be changed to TLS (I would recommend).

 

With kind regards

 

 

 

Link to comment
Share on other sites

As for port numbers, you need only HTTPS to be on the standard port (443). If you are using LetsEncrypt you'll also need to use port 80 for HTTP. All other ports can and probably should be on random ports.

RTP (UDP) needs to be open in any case. Make sure to pick a reasonable large range of ports so that the risk of someone hitting your RTP is lower. 

If you are using VoIP phones, you should try to stay away from UDP. Most VoIP phones today are able to do this properly. If you are using LDAP or LDAPS, you will also have to make those ports accessible for the VoIP phones. 

I would try to keep SIP/UDP really just for the SIP trunk provider. That means you can allow traffic only between the SIP trunk provider and the PBX.

And if you are using the apps, you need to open HTTPS for the apps in addition to the RTP ports. The apps don't need SIP or LDAP ports. 

Link to comment
Share on other sites

Thank you both.

@Vodia Support EU, I don't see any "releases" described in the ports table? I am using Pro 68.0.26 so I think that's pretty current. I've successfully provisioned a Yealink T42G phone by manually assigning the MAC address and manually provisioning. (Automatic MAC detection only works on a LAN I believe.)

@Vodia PBX, good tips, thanks. You're recommending TCP but not necessarily TLS for the SIP traffic from the phones? My thought was to get things working on default ports and protocols, then start tweaking.

Link to comment
Share on other sites

14 minutes ago, mcbsys said:

@Vodia PBX, good tips, thanks. You're recommending TCP but not necessarily TLS for the SIP traffic from the phones? My thought was to get things working on default ports and protocols, then start tweaking.

TCP and TLS... If the phones support TLS, this is much better than TCP. Some firewalls start messing with the packet with their application layer gateways, which are usually completely useless for SIP. This makes troubleshooting very difficult and frustrating and this is another reason to use TLS.

The problem with default ports is that you attract scanners. Choosing a different port just reduces the amount of junk traffic typically by a magnitude. For example there is no reason to use a default LPAP port because they are always automatically provisioned anyway and so are the SIP ports unless you choose to manually provision phones.

Link to comment
Share on other sites

Okay will look into TLS, though I turn off SIP ALG in my UniFi routers so rewriting hasn't been an issue.

I was planning to just use the Azure firewall to lock down SIP and I guess LPAP (which I'm not using yet) to the customer's IP and trunk's IP addresses. Seems that should eliminate all junk traffic, no? In other words, why change default ports if the only IPs that can reach the system are known and trusted?

Link to comment
Share on other sites

7 minutes ago, mcbsys said:

I was planning to just use the Azure firewall to lock down SIP and I guess LPAP (which I'm not using yet) to the customer's IP and trunk's IP addresses. Seems that should eliminate all junk traffic, no? In other words, why change default ports if the only IPs that can reach the system are known and trusted?

If your customers have fixed addresses, you can actually really cut off most of the junk. This is almost like a SD-WAN or VPN then.

The problem are the mobile phone apps and people working from home, where you simply cannot catch up with the changing addresses. 

Link to comment
Share on other sites

1 minute ago, Vodia PBX said:

The problem are the mobile phone apps and people working from home, where you simply cannot catch up with the changing addresses. 

I could see the issue for hard phones taken home, if that were ever to happen. From what you said earlier, as long as they just use phone/desktop apps, no need to open SIP to the world, right? Just HTTPS and RTP?

BTW I'm curious why you say, "you need only HTTPS to be on the standard port (443)." Is is it just to simplify so users don't have add the custom port, e.g. https://pbx.domain.com:8443 ?

Link to comment
Share on other sites

57 minutes ago, mcbsys said:

I could see the issue for hard phones taken home, if that were ever to happen. From what you said earlier, as long as they just use phone/desktop apps, no need to open SIP to the world, right? Just HTTPS and RTP?

BTW I'm curious why you say, "you need only HTTPS to be on the standard port (443)." Is is it just to simplify so users don't have add the custom port, e.g. https://pbx.domain.com:8443 ?

Yes the apps only need HTTPS and RTP.

The question is if the user will ever enter or see the PBX URL. In the browser they do, and in that case I would for the sake of simplicity use the standard HTTPS port. If they are exclusively using the apps where you don't really see the port, you can as well just use a random port.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...