3 ms·
While domain registrants should certainly be careful that their DNS records point to trusted servers only and should definitely remove any stale DNS entries, we
by susam 6y ago
While domain registrants should certainly be careful that their DNS records point to trusted servers only and should definitely remove any stale DNS entries, we should also configure our web-servers to return successful response for specific hostnames only and error/no response for everything else. Here is roughly how the configuration for, say, https://example.com/ https://example.com/, would look like:
sudo mkdir /etc/nginx/ssl
sudo openssl req -x509 -newkey rsa:4096 -nodes -keyout /etc/nginx/ssl/key.pem -out /etc/nginx/ssl/cert.pem -days 365 -subj "/CN=localhost"
echo "server {
listen 80 default_server;
listen [::]:80 default_server;
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/key.pem;
return 444;
}" > /etc/nginx/sites-enabled/default
echo "server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/example.com;
}
server {
listen 80;
listen [::]:80;
server_name example.com;
return 301 https://example.com$request_uri;
}" > /etc/nginx/sites-enabled/example.com
The self-signed certificate for the default_server is okay. The client will get a TLS certificate issue. That's fine because we don't anyone to be using the default_server anyway. If the client decides to proceed despite the TLS certificate issue, then the 'return 444' directive would close the connection without response.
- karmakaze 6y agoThis is a great suggestion and I'll set up servers this way from now on rather than allow default fallback content to be served. Others are quick to point out this only fixes half the problem, well that's 50% more than nothing. For the other 50% you have control of your own DNS records, keep them up to date. And if everyone did this mismatching hostname/content would be a thing of the past.
- awestroke 6y agoThe reverse is the problem here: your domain, somebody elses server
- susam 6y ago> The reverse is the problem here: your domain, somebody elses server Why would my domain point to somebody else's server? The original post says, "It seems that the owner had it pointed to a Linode instance/IP which was then abandoned and was subsequently "inherited" by me." As per my reading of this, it sounds like the domain name is owned by someone else that points to an IP address of the poster's server. My comment was meant for a scenario like this where if someone else's domain name points to my server's IP address and a visitor visits my web server via that domain name, then my server will close the connection without response.
- sleepydog 6y agoThe OP is putting himself in the domain owner's shoes. It's a mild inconvenience for the OP, but what if the OP was a bad guy? He could have setup a site that looked like the old one saying "unstoppable is back! Log in and update your payment info!" but stole credit card info or passwords. The owner of the domain should have been more careful to delete their A records once they no longer owned the IP address. IPv4 addresses are finite and it's not surprising for a housing provider to recycle them.
- susam 6y agoThank you for clarifying the OP's intention. It indeed makes sense to advise the domain registrants to be careful about cleaning up stale DNS entries. Yes, if a domain points to IP addresses of servers we do not control, many bad things can happen. Here is a really interesting security disclosure related to stale DNS entries that comes to my mind: https://thehackernews.com/2019/04/subdomain-microsoft-azure.html https://thehackernews.com/2019/04/subdomain-microsoft-azure.... .
- detaro 6y ago> "It seems that the owner had it pointed to a Linode instance/IP which was then abandoned and was subsequently "inherited" by me." answers the "Why would my domain point to somebody else's server?", doesn't it?
- mrits 6y agoThat fixes a web-server from serving HTTP responses to other hostnames but none of the other thousand problems
- Denvercoder9 6y agoYou can't: the web server has to accept the connection to know the hostname. The best you can do is close the connection immediately without sending a response if it's an unknown hostname. I believe that at least with Apache and nginx doing this requires using a non-default module.
- icedchai 6y agoI think you are over complicating things. You just need a default virtual host that displays a "domain not configured" page. This is what we did when I ran a hosting company.
- Denvercoder9 6y agoThe parent comment originally said "just don't accept HTTP connections for unknown hostnames".
- susam 6y agoIndeed the web server has to accept the connection, check the hostname, and return an error or close the connection without response.
- detaro 6y agothat doesn't prevent the "a domain you own points at someone elses server and they can do unsavory things with it". (Especially bad if it's a subdomain, or a domain linked to one of your others.) it's not for OPs sake, but for the domain owners sake.
- susam 6y agoMy domain name is under my control and therefore should not point to servers I do not trust. If one's domain name points to an untrusted server, a very fundamental mistake has been made and no amount of configuration can fix the issues associated with it. Webmasters we have two things in control: 1. Their domain name. It should point to trusted servers only. 2. Their web server. It should be configured to return successful responses only for domain names they care about and no response/error for everything else.
- detaro 6y agoThe configuration fixing it for the domain owner is very simple: update your DNS so it doesn't point to a server you don't control anymore. OP observed someone made that mistake and is posting a PSA "hey, remember that that's a thing and don't do it because it's bad". If that's obvious to you and you never make that mistake, great, you are not the target, but real-world experience shows that it happens all the time.
- harikb 6y agoJust curious - can you explain #2 ? I get that someone can register some freebitcoin.xyz and point to your IP, but the content is still controlled by you, right? What is the security angle here if your host returned a static index.html to any host? Some CSRF? Edit: only asking for cases where #1 does not apply - that is you don’t have domains or sub-domains pointing at rogue IPs
- detaro 6y agoIf it's just an empty placeholder, not much. if it's your actual site or app there could be various issues, e.g. with search engines, people actually using/being tricked into using the app through the wrong domain and having cookies associated wrongly, bad content on subdomains being associated with you, ...