FQDN - Excessive disclosure of information?

[MaciejP]

Scenario:
Self-hosted / in-premise setup, only internal (LAN access)

According to the security audit opinion the current 3CX setup by registering FQDNs in 3cx domains forces redundant disclosure of information such as the public IP address / the very fact of using 3cx...
Such information could be valuable to potential attackers.

There are many lookup tools so potential attacker can get easly get info who is using 3cx and associated public IP used for that installation.
Typically we do register FQDN'S giving our company name - so it even easier to get this info, but even without this, by reading who owns the IP you can easily arrive at the same information.
Eg this tool shows there are 130k+ 3cx.us subdomains, just by looking at the names alone, without delving further - I have the impression that I am able to read the list of your clients with a high degree of probability ...

So my question is:
why 3cx forces to create subdomains of their owned domains and MAINLY why there is a need to register a public FQDN for local installations not publicly exposed?

As I understand it, the IP address associated with the FQDN is automatically assigned to the public IP we use. There is therefore also no way to associate this with, for example, the IP of a local 3cx Partner.

 

[bitn2]

An PBX with only lan access doesnt make any sence... But your not forced to use an 3cx FQDN, you can use your own with the right license.

 

[MaciejP]

An PBX with only lan access doesnt make any sence

Why not make sense?
I meant LAN access for end-users, SIP Trunks are ofc external (public)

Can you please advise what licence is right to do own FQDN registration (no need to be part 3cx-owned domains)

 

[bitn2]

So its not only lan access... You need an fqdn for different things. To make it more secure there are many tutorials for. You need at least the pro licence to use an own fqdn.

 

[MaciejP]

Can you please advise what are those needs to register publicly FQDN for "local" instalation?
I cant find any good reasons if PBX is not publicly exposed.

Again considered scenario:
- PBX on-premise
- User access: LAN only (eg desk phones)
- no access to PBX via Internet / mobile phones apps etc
- SIP Trunks -> s2s links to SIP provider

 

[Alphabetic]

Because the FQDN is tied to a license.

However youre wanting to install 3CX and use it, thats the way its been made.

the purpose of the FQDN is the for benefit of the apps, users, admins, phones. The idea is to make it as easy as possible to deploy and use 3CX.

Im not sure what you're fretting about in regards to the public FQDNs... the keyword here is public. You have to option to choose any subdomain for your install, so if you're putting your customer information there then that is on you.

There are plenty of bots on the internet that search and brute force anything on the WAN. Again, its up to you to protect your network.

Dont want your public IP visible? Purchase another one or use the cloud.

 

[SweetAction]

As pointed out by multiple people in this thread, you don't have to use a 3CX FQDN, you can use your own FQDN on any Pro or Enterprise license (even if using Hosted by 3CX). Custom FQDN is not available on Free/SMB at this time.

You have to have a FQDN for the SSL cert, the SSL cert is required for multiple functions including SMS callbacks, SBC, mobile apps, webclient, and more. Just because you are not using these functions doesn't mean they are not in the system and ready to be used.

P.S. I can find 3CX installs with a custom FQDN just as easily by doing a Shodan search for known parts of the URL or text on page.