Is it safe to set up IP address to domain name redirection?

Question

We recieved the following e-mail with from one of the UI developers

When we browser site with IP: http://x.x.x.x/, it doesn’t redirect to http://www.our_website_name.com. This could cause duplicate content problems if a search engine indexes site under both its IP and domain name.

Can we set redirection from IP to domain?

Now, I don't see that any of the search engines have indexed our IP address and I believe that the chances of a search engine indexing an IP address is close to nil if there are no links floating around in the internet with the IP address instead of the domain name. My question is:

From a security point of view, is it safe to redirect an http request for direct IP address to the domain name?

I know how to deny/block or redirect if the request is for direct IP address and I see dozens of instructions online how to do it, but why do people do that? Can I go ahead and set up this redirection (IP address to domain name) with no security concerns?

Answer 1

From a security point of view, is it safe to redirect an http request for direct IP address to the domain name?

yes, usually it is no problem. if you are in super-paranoid mode you might follow the approach below.

Traffic that goes to the IP directly, even if there are domain names registered, are usually scanners and bots, and maybe, every now and again, a developer. Search engines don't access IPs directly, except when you have no domain names configured.

This is a quite legitimate catch-all setup for nginx that defines a response to any access that is not defined through a virtual-server-conf (it just returns HTTP Status 400):

server {

    listen 80 default_server;

    access_log off;
    error_log off;

    # basically just return an error
    return 400;

}

Answer 2

It's not a security problem, but it's a bit of a strange thing to do. It complicates your configuration, and is prone to errors if the IP address were to change, or you wanted to move to cloud based services. AFAIK this it isn't standard practice to redirect IP address lookups to a domain.

Answer 3

You are asking for an answer from a security point of view. However there is more than one security point of view depending on which threat model you have in mind.

If your threat model is an attacker attempting to compromise your server by making requests to your server, I would say it doesn't make any difference how you handle requests specifying an IP address in the host header rather than a domain name.

It is very unlikely that your updated handling of requests with an IP address in the host header would open you up to any new ways of compromising the server. And compromising attacks against the full application on your primary domain name would work regardless, since the attacker can just put that domain name in the host header.

If your threat model is an attacker trying to lure your users into a trap by giving them links to unofficial domain names pointing to your server, then remember that an attacker could achieve the same by setting up a proxy on their own IP, which modifies the host header before passing the request to you, and they could making any changes to the replies before passing them back to the user.

As such there is no significant risk in this area either. Unless the attacker is attempting to perform a phishing attack. The best you can do to ensure that users don't fall for a phishing attack is to only have one legitimate domain name they need to be able to recognize. Redirecting all requests with an IP or a secondary domain name in the host header to the legitimate domain is a user friendly approach to this.

However it may be a tad too user friendly. After all, the users aren't supposed to be coming through a URL using IP or secondary domain name in the first place. So the redirection might lead to a situation where insufficient attention is given to URLs not using the proper domain - because they "just work". If users get used to a variety of domains and IP addresses being used in URLs, those users will be an easier target for phishing.

Having the secondary domains and IPs all produce an error message which includes a link to the proper domain may help ensure that both users and developers remain aware that URLs are supposed to contain the primary domain and nothing else. Serving the error pages with a proper 4xx error code would produce more predictable results if any automated software is accessing improper URLs. However serving the error pages with a 200 code might make it easier for search engines to find the content in case of external links outside of your control, which happen to point to the IP or secondary domains.

Regardless of whether you go with 2xx, 3xx, or 4xx code for those responses, the cleanest configuration to achieve it would be a separate vhost in your webserver configuration. A previous answer gives an example of how this could be achieved. Other webservers can do it as well.

Another threat model to keep in mind is requests to your application trying to trick your application into using an incorrect domain name passed through the host header in dynamically generated content. If the domain name from the host header is only used for generating an answer to the request which used incorrect host header in the first place, then this is not a major concern. However if your application use the host header for generating URLs that will later show up in emails or in your database, then this is reason for concern.

Answer 4

As an employee of a company that does hosting I can tell you we do the following for our hosting servers.

We have a 'base' (or catch-all) (virtual-) host configurations that refer to a quick to load page without any real content. (like a banner with our logo and a link to our corporate website). This approach has several advantages.

• if a end-user enters the wrong url name he/she gets a fast loading website. Anyone harvesting URL's will not take to much of the servers resources
• Attackers that try to harvest usign just the IP will get nowhere since the site beeing hosted is not a CMS/web app (that could be vulnerable).