18

Someone told me that showing your IP address in a URL (like http://192.0.2.34/default.html) is easier to hack. Is that true? I could trace any domain name and get its IP number as well.

user
  • 7,670
  • 2
  • 30
  • 54
Delmonte
  • 423
  • 1
  • 4
  • 7
  • 1
    I cant think why would this happen except that it just erases the DNS reconnaissance step ... – Novice User May 09 '13 at 14:34
  • 14
    Showing the IP address in the URL should make no difference to the security of the site. – AndyMac May 09 '13 at 14:39
  • 7
    Using an IP as a URL is bad. Not in terms of security; but from a usability standpoint. If your IP changes all your users bookmarks/links will break (especially bad for a server whose path is baked into numerous config files). It's harder for the user to remember how to get to your site if they lose their bookmark/link. If the user forgets what their bookmark is for an IP doesn't give any hint about it. – Dan Is Fiddling By Firelight May 09 '13 at 18:53
  • 1
    What you have been told is 100% false it's trivial to get the address of any domain. Of course there are other security concerns. – Ramhound May 10 '13 at 03:15

6 Answers6

45

Easier to hack? No. Easier to DoS? Potentially. Using an IP address instead of a host name with a DNS entry means you're giving up a layer of routing flexibility that can be very beneficial.

For example, if malware targets your IP address in a DoS attack, if you're using a domain name, you switch the IP address of the site and in the DNS record, and the attack is over without your users knowing the difference. If your users are making requests directly to your IP, however, that isn't an option. You're tied to that IP unless you want to inconvenience (and possibly lose) your users along the way.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • 1
    This. Plus you could add a front-end cache or load balancer or combo (using Varnish, HAProxy, Nginx, etc) where the public DNS hits the load balancer which opaquely re-directs traffic to the actual backend boxes without the end user knowing. – Suman May 09 '13 at 17:44
  • 9
    @Suman To be fair, you can do this using an IP as well. There will be a public IP for the site functioning as the VIP in any case, so it's just a matter of whether the users access the site directly via the VIP, or a DNS entry pointed at the VIP. It's goofy for sure, but it is possible. – Xander May 09 '13 at 17:53
  • 1
    good point. Didn't think of that. – Suman May 09 '13 at 17:55
  • But browsers/routers/OSes usually cache DNS queries for hours; so there's effectively no difference. Also, unless you were using DNS round-robin/load balancing, its not like you could actively prevent an attack. That said, I avoid linking via IP addresses when possible as (1) IP addresses are typically harder to remember, (2) if you have (or ever want) more than one server running at the same IP browsers need to specify a domain name (to put in the `Host:` header of the HTTP request) and (3) if your server moves/changes IP addresses, you can keep the same domain name at the new IP. – dr jimbob May 09 '13 at 21:05
  • @drjimbob It is a tactic that has been used practice to thwart at least one DDoS attack a few years back that targeted a website by IP address. That said, it's just an example. The point remains that you less flexibility if you're exposing your IP Address rather than a domain name. I completely agree with your other points. – Xander May 09 '13 at 21:12
  • @Xander - Agree that you have less flexibility by exposing an IP address. However, if you have a domain name its trivial to find the underlying IP address (`dig www.example.com`). The DNS record often has a TTL of a 10000+ seconds during which time you can attack a specific IP. Load balancing will help, but again if you are using a load balancer you wouldn't be pointing people to a specific IP. – dr jimbob May 10 '13 at 03:08
  • @drjimbob: I don't know about you, but I can adjust the TTL of my DNS records. I can also create round robins to distribute load across multiple instances. I can't force ISPs to not cache it for longer, but if they do, it's *their* problem. – Sébastien Renauld May 10 '13 at 15:13
17

Typically if your site is accessible as http://1.2.3.4/ that would imply that it is not enforcing any limitations on the Host: header. That would mean that you could access it not just through IP address, but any hostname that happened to resolve to that address - including a domain an attacker registered and pointed at it.

This opens up DNS rebinding attacks, where an attacker circumvents Same-Origin-Policy by switching the IP address of a hostname between their own server and yours, and cookie attacks where they point attacker.com to your service and then sub.attacker.com to their own, allowing the cookie to be read from the subdomain.

Quite how much of a risk those are depends on the design and purpose of your application. It's most likely to be exploitable on non-public applications, where you have implicit authorisation based on private IP address range or SSO (Windows auth et al); in that case an application might produce sensitive data without user interaction, and that data could become visible to such an attacker.

Without knowing that, the safest route is to put limitations on what the Host: header can contain for HTTP requests. That usually means setting up host-based virtual servers and allowing only known-good hostnames to hit your web apps, in which case attacker hostnames and direct-to-IP-address access alike would hit an error page.

But you could certainly come up with a custom check that permitted only an IP address and not any other hostname, if you really wanted - so no, it's not the IP address that's a problem in itself.

And/or just use HTTPS, which offers more watertight assurance that you're hitting the right server.

bobince
  • 12,494
  • 1
  • 26
  • 42
6

Contrary to the other answers, I consider that using ip-addresses instead of hostnames is bad practice for a number of reasons. Most notably:

  1. It is considerable harder for average users to verify that they are talking with the correct service and not with a phishing site: They have to remember a large number instead of a name.

  2. Using ip-adresses implies that you cannot use https with a valid certificate.

  3. IP-addresses may be reassigned for a number of reasons, and not all of them are under your control. Thus someone else may get your current ip-address.

  4. A common way to handle huge amounts of traffic (e. g. a DDoS attack) is to point the dns entry to a huge distributed caching network. By using an ip-address you are ruling out this effective and relatively inexpensive option.

Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
1

Using the IP address instead of the domain is not a security bad practice, as an attacker could get it trivially.

A simple terminal command like nslookup can check for any IP address resolved by the given domain. Furthermore, if the domain is connected to a single IP address, ping does the job just as well.

Giving your [web site's] address one way or the other doesn't make it any more "hackable" then it already might be.

Gurzo
  • 1,117
  • 6
  • 18
0

It can't be a security concern because everyone can find out the domain IP address.
for example check this out: ip-lookup

Siamak Motlagh
  • 149
  • 7
-1

Along with the good reasons that bobince mentioned, there is also that you cannot create a properly trusted SSL/TLS certificate for a site that doesn't use a DNS domain name. Thus making all browsers trying to connect to your HTTPS:// version of your IP addressed site complain that they cannot trust it.

Rod MacPherson
  • 1,057
  • 7
  • 11
  • 3
    You actually can get a valid SSL certificate for an IP address. See this answer: http://serverfault.com/a/226193/57060 – Xander May 10 '13 at 16:08
  • Interesting. I've never used GlobalSign before and never heard of any officially sanctioned CAs issuing certs for IP addresses instead of FQDNs. You learn something new every day. :) – Rod MacPherson May 16 '13 at 20:55