Preventing Subdomain Exposure on cPanel
Hello everyone,
I've recently discovered that when using tools for domain enumeration (e.g., amass, subfinder, etc.), all subdomains on our cPanel setup become publicly visible. This is concerning for our business, as it exposes our client structure, potentially affecting both privacy and security
Interestingly, competitors who use providers like OVH don’t seem to face this issue. Is there a way to prevent these subdomains from being publicly enumerated while still using cPanel? Any advice or recommended solutions would be greatly appreciated!
Thanks in advance for your help!
-
Hey there! I'm not sure what those tools do - can you get me more information about what is changing and what specific subdomains are visible that you aren't expecting to be?
0 -
Hello @cPRex,
Thanks for responding!
The tools I mentioned, like amass and subfinder, are domain enumeration tools commonly used for reconnaissance in security. They essentially scan public records and databases to identify all associated subdomains under a main domain. These tools are often used in security assessments to ensure there are no unexpected or vulnerable subdomains publicly accessible
In our case, when we run these scans, we’re seeing all subdomains associated with our cPanel setup, including ones we’d expect to be internal or unlisted. For example, we have subdomains set up for internal applications, testing environments, and sometimes even client-specific subdomains that are not intended to be publicly accessible
This visibility is concerning because it exposes our internal infrastructure layout and client-related subdomains, which could be leveraged for unauthorized access or could lead to targeted attacks
I’d like to know if there’s a method to prevent this information from being publicly enumerated—essentially making these subdomains non-discoverable while still using cPanel
I’m open to any configuration advice, whether it involves DNS settings, server-side adjustments, or any other recommendations that could enhance privacy for these subdomains
0 -
What is probably happening is that once the subdomain is setup, the AutoSSL function runs on WHM/cPanel which then sends details of the subdomain to LetsEncrypt to generate the SSL certificate for https://subdomain.... Lets Encrypt then posts the details, as most SSL providers do nowadays, to their the Certificate Transparency logs ( https://letsencrypt.org/docs/ct-logs/ ) so web browsers can then check for revocation. Many security products then harvest these CT logs to find subdomains.
So what can you do? Well, there's three solutions that come to mind:
1) You could disable autossl on the sites (WHM->Manage AutoSSL or cPanel->SSL/TLS Status) but that will stop the certificates being generated and therefore no https/SSL on the site (but this won't remove the historical certificate logs).
2) Ensure the domain name is hosted/controlled by the server. This will allow the server to generate a wildcard "DV Certificate" (basically a wildcard certificate). As long as your subdomains site directly under the domain name (such as subdomain.example.com - but not something.subdomain.example.com ), it will be covered by the DV certificate and the subdomain shouldn't be listed in the certificate details and therefore remain "hidden" (although checking my sites SSL certificate under "Certificate->Extensions->Certificate Subject Alternative Name" it does list some of the subdomains - so you may need to purchase a wildcard certificate and install it BEFORE you setup the subdomain to cover this).
3) You could find an SSL provider who doesn't use certificate logs. I don't know if any still exist and are still trusted by major browsers.
However, "security by obscurity" is a really bad security method and there are many many ways DNS entries like this could be "leaked" (from enumeration - someone just using a "dictionary attack" to work through all potential subdomain names - to 3rd party Javascript on the site, or even the web browser itself reporting the domain to security products, plugins etc). It'll be better to restrict access to the websites to either a username/password combination (cPanel->Files->Directory Privacy) and/or restrict access to the site to just trusted IP blocks (cPanel->Security->IP Blocker will only block ones for you no setup an "allow list" so you may need to set up the .htaccess rule manually via https://httpd.apache.org/docs/2.4/howto/access.html )
As to how OVH is doing this, I'll need an example to be certain but it'll probably be one of the first two options listed above.
0
Please sign in to leave a comment.
Comments
3 comments