3CX Server in DMZ, SBC on LAN?

[keebs]

There seem to be a lot of opinions on the placement and use of SBCs, but there is only one configuration that makes sense to me for a local 3CX installation.

If Mobile and 3CX clients do not/cannot use the SBC, and you have to connect to the 3CX server directly, then I don't see how the 3CX server should not be in the DMZ unless you do not use these features? This would also be appropriate if you have one-off remote desk phones connecting through a direct SIP connection.

The SBC should be installed LAN side. LAN Desk phones should communicate through the SBC to the 3CX server and 3CX communication to the LAN should be restricted to the SBC only via firewall rules. This way if 3CX was compromised, they would also need to compromise the SBC to gain access to the LAN. Even though 3CX keeps us informed of phone firmware updates, I trust the security of 1 SBC/target rather than multiple phone firmware.

Additionally, desk phones are the switch for our desktops, so they have to be physically connected to the LAN in some way shape or form. Yes, you can configure then to a VLAN, but that a false sense of security. If the phone is compromised, changing the VLAN configuration on the phone is trivial and now the hacker has potential access to other areas of the network - another reason to keep them behind the SBC. Also, I've read of some using the SBC for phone discovery and moving the phone to communicate with 3CX directly after discovery, but I feel this is a bad idea as I've explained above.

So - aside from security paranoia and a somewhat complex initial setup, why would I not want to configure my network this way?
Is there something I am missing or haven't thought of?
Is there some limitation of the SBC that I should be aware of?

Any help/guidance is appreciated.

Thank you

 

[AWS2P]

SBC use is only when PBX is cloud hosted, if pbx is on premise local LAN then SBC isn't of any use.
Interest of SBC is no pain with NAT traversal, only 5090 tunnel port is used.
SBC is managing Audio for phones behind him.
So first question is where is located PBX?

 

[keebs]

I can put 3CX anywhere I want on the network, but I feel it should be in the DMZ.

Why would an SBC only be used for cloud hosting? You are traversing 2 zones either way; it doesn't matter that they happen to be on the same firewall. A DMZ is no more or less secure than cloud hosting. Same risks apply. An SBC is part firewall. It's not just for NAT traversal.

 

[AWS2P]

if your pbx is on premise, then set it on LAN and not DMZ and no need of an SBC

 

[keebs]

I understand that this configuration will work, but it lacks security which brings me back to my original post.

 

[AWS2P]

which lack of security?
if ports are open as they need (3cx install doc), global IP blacklist is enabled, and 5060 restricted to SIP provider IP , external App are logged in tunnel 5090 encrypted.

 

[keebs]

We can secure against the risks we know of. It's the ones we don't know about that are the largest risks.
I'm not saying 3CX is insecure. They've done a great job to lock things down in the server, but you are still opening ports 5090 and 5001 from the WAN to the LAN. (5090 is proprietary which concerns me less.) You'd also potentially have to open ports 5060/5061 from the WAN to the LAN if you ever need direct SIP connected phones. Any compromise of the server and the hacker is now on your LAN. Why risk it?

 

[cobaltit]

I've not done it, but that configuration should work. But why go through the trouble vs just putting all the voice stuff in it's own VLAN?

 

[keebs]

Primarily VLANs are designed to be organizational and not intended for security. With a VLAN, you are still one configuration away from a compromised server being on your LAN. If you could hard code the VLAN on a physical port at the network hardware level and your firewall allows you to write rules specifically on that VLAN, that would be better than just having the 3CX server on the LAN. But I still think the DMZ is more appropriate. Please understand, I'm not trying to be argumentative. I'm just looking for input to prove me right or wrong.

 

[AWS2P]

It seem to me you have security and network knowledge so not sure to understand what do you expect from 3CX forum .
This is not a security forum. You should do the job with a security engineer if you are really worried by best security scenario to follow

 

[keebs]

Again, I'm just looking for any input/guidance. Positive or negative as to why what I propose is good or bad. I'm trying to make sure there is not an angle here that I haven't considered. I don't think there is, but anyone can make an error or miss a detail. I appreciate your comments.

 

[cobaltit]

Primarily VLANs are designed to be organizational and not intended for security. With a VLAN, you are still one configuration away from a compromised server being on your LAN. If you could hard code the VLAN on a physical port at the network hardware level and your firewall allows you to write rules specifically on that VLAN, that would be better than just having the 3CX server on the LAN. But I still think the DMZ is more appropriate. Please understand, I'm not trying to be argumentative. I'm just looking for input to prove me right or wrong.

I'm confused by your statement. By that token you can say door locks are not designed for security because someone could leave the door open or leave the key in the door and be one step away from being compromised. You seem to have a pretty firm grasp of networking and security, and at the end of the day VoIP, regardless if it's 3CX or any other system boils down to networking. So there really shouldn't be any input needed, as apparently have secured your network before. So implement whatever security you do for any other traffic you don't want touching or affecting your network. If you want to use the DMZ, go ahead. If you want to use a VLAN, go ahead. Packets are packets.

Here is a list of the ports 3CX uses. As long as the trunk and the endpoints can talk to 3CX and vice versa, things will work:

https://www.3cx.com/docs/ports/