Allow Remote Domains - why is it a security problem?
Hello,
I would like to let my cPanel users to create parked/addon domains without being forced to use my VPS nameservers.
I understand I can do this by turning on: "WHM > Server Configuration > Tweak Settings > Allow Remote Domains"
But the help caption says it's not recommended: "This can be a major security problem. If you must have it enabled, be sure not to allow users to park common Internet domains."
I don't understand, could someone please make a simple example of a potential risk?
What's a "common internet domain"? And what happens if a user parks a "common internet domain"?
Thanks
-
Hello @Gino Viroli, The primary risk for remote domains and common domains (e.g. gmail.com, hotmail.com) is that it can allow a malicious user to intercept emails sent from other users on your cPanel server to remote destinations. Exim assumes that domains existing in the /etc/localdomains file are hosted by the local cPanel server. Let's say a user adds gmail.com as an addon domain or alias in their cPanel account. If that were to happen, gmail.com would automatically be added to the /etc/localdomains file. If the person that added gmail.com creates a test1@gmail email account in cPanel, and another domain hosted locally on your cPanel server sends an email to test1@gmail, then the email would be delivered to the person that created the gmail.com domain in cPanel as opposed to the actual Gmail servers. If you need to temporarily add a domain name that resolves to another server, then instead of enabling "Allow Remote Domains" in WHM >> Tweak Settings, you can instead temporarily add the IP addresses of the remote name servers utilized for that domain in the WHM >> IP Functions >> Configure Remote Service IPs >> Remote Name Server IPs interface. Users are permitted to add addon or parked domains only with nameserver IPs in this list. Thank you. 0 -
It might be worth mentioning that gmail.com, hotmail.com, google.com, aol.com, yahoo.com and others cannot be added even if "Remote Domains" are allowed. cPanel maintains a list of "blacklisted" domains in /usr/local/cpanel/etc/commondomains and you're able to add additional domains in /var/cpanel/commondomains (you need to create the file). So there's a few security measures in place to prevent obvious domains from being added (such as gmail.com), but you really have to use the Remote Domains with care, because it can very well result in bad things. 0 -
Hello @MajorLancelot, Please, how can we get this to work for customers when they are using dynamic name-servers and without enabling Allow Remote Domains?
By "dynamic", do you mean their name server IP addresses are always changing? Do the name server IP addresses share a C-Class or rotate from a fixed list of IP addresses? How common do you face this issue, and is there a common registrar or DNS service provider with this setup?And explanatory sentence said, "Users are permitted to add addon or parked domains only with nameserver IPs in this list." Shouldn't this be "Users are permitted to also add addon or parked domains with the nameserver IPs in this list."?
Yes, or also stated as: Users are only permitted to add addon or alias domains that utilize nameservers registered with IPs in this list or IPs added to this cPanel & WHM server and cluster. Thank you.0 -
Sorry for the delayed response to this. Hello @MajorLancelot, By "dynamic", do you mean their name server IP addresses are always changing? Do the name server IP addresses share a C-Class or rotate from a fixed list of IP addresses? How common do you face this issue, and is there a common registrar or DNS service provider with this setup?
Not really. Route 53 and Google Domain often tend to change the IP addresses associated with the name-servers they give to their customers. It doesn't necessarily affect the "4" in one go but it might affect "2" at a time.Hello @MajorLancelot, Users are only permitted to add addon or alias domains that utilize nameservers registered with IPs in this list or IPs added to this cPanel & WHM server and cluster.
This would make more sense and would be more explanatory if it is what is available. I have attached a screenshot of what is there now. Thanks for being there for us every time!0 -
We do not want to enable "Allow Remote Domains" and we asked the customer to change the domain IP address and nameservers to point to our DNS cluster.
And what was their response? I mean... this is kind of the order of things - "if you want to use addon domains... use the nameservers we designated for you" - I'm perplexed at the institution that not following that order... and still expecting things to work. Why have rules then? The purpose of forcing a domain name to use designated nameservers for your server is to validate that the person owning the domain name (capable of changing the nameservers for it) is the same one that is requesting hosting via an addon domain. Without that validation, then any low level user could create an addon domain, set up a default collection email address, and effectively steal all mail sent by users on the server to that (non-validated) domain name. Perhaps you can argue that the list of common Internet domains is sufficient... but are you really going to bank on that list (which is rather subjective) to be complete? What about amazon.com? walmart.com? usbank.com? I mean, there's a huge potential list and I don't believe it's cPanel's place to insure that that list is kept current because it's always going to be subjective. If you really, really want to get around this... create a subdomain off of the main account with the DocumentRoot set to the intended addon domain's DocumentRoot. Then using the root's WHM's park a domain function, park the addon domain name on top of the created subdomain. The WHM's park a domain function does not have the remote domain validation check. ... Of course... there's no API call for using WHM's park a domain function... which has been begged for since the dawn of time, so it makes any sense of streamlining this process impossible.0 -
Hello Everyone, I believe what could help here is a feature that allows customers to validate ownership of a domain name without actually changing the name servers. For example, take this scenario: 1. "Allow Remote Domains" is turned off. 2. A customer owns a domain, but prefers to use a remote provider to manage the DNS for the domain. 3. The customer wants to add the domain as an addon domain or alias. Currently, the hosting provider must turn on "Allow Remote Domains", add the remote name server IP addresses to WHM >> IP Functions >> Configure Remote Service IPs >> Remote Name Server IPs, or ask the customer to change their name servers. Otherwise, the third step above will fail. As an alternative, a new feature that allows the customer to validate ownership of the remote domain name themselves (i.e. perhaps by adding a DNS record for the domain via their DNS provider's interface to prove ownership) would make for a smoother process and avoid the need for manual intervention from the hosting provider. Does this sound like the right approach? Let me know of any feedback, and I'll proceed to create a feature request and check internally to see how feasible it is to implement a feature like this in the product. Thank you. 0 -
Hi Folks, Just wondering if you could provide a status update on this? I have read the thread and fully understand the reason for this existing however from an end user experience perspective it is kind of silly. End user signs up for a hosting account. In all major billing platforms they are asked if they want to register a domain or update their own nameservers etc, they choose the latter as they already have a domain. Everything is setup, they like the hosting provided so they go to add another domain... CLANG! this setting hist them. They perhaps what to use cloudflare which is obviously significant and increasingly common, they have to point the domain at my nameservers then back again to add a domain? kind of silly from an end user (paying customer) perspective. So yes the ability to prove ownership probably through a text record is the right way forward as a middle ground and as a side note, there should already be a second 'greylist' that contains all domains already existing on the server to prevent anyone from adding a domain that already exists. my 2c, look forward to the update. 0 -
Hello @InceptionHosting, The following feature request is now open: Remote domain verification I recommend voting and adding feedback to this feature request if you'd like to see it implemented in the future. Thank you. 0 -
Following up on: Cloudflare doesn't disclose their IPs for their nameservers and they're constantly changing. So users have to TEMPORARILY set their nameservers to ours and then point them back. There should be other ways to verify domains, file verification would be the easiest and best. Features have been suggested for this (vote for it to get in core ^_-). Has anyone found a temporary workaround for Cloudflare users except for the one I listed above? 0 -
Hello @JoelStickney, There's currently no workaround beyond the solutions documented on the link below: Configure Remote Service IPs - Version 78 Documentation - cPanel Documentation If you are able to develop a custom bash script, you could configure it up to automatically (on a cron job) add the updated IP address from the "host name.ns.cloudflare.com" command output into the /etc/ips.remotedns file as a line-separated list. Thank you. 0
Please sign in to leave a comment.
Comments
11 comments