2

This seems like a phishing attack, and it's a disclosure vulnerability to send 404 response in this case. Unfortunately that's just what IIS does.

I would rather these guys not even know my server existed.

Edit: Of course, once a TCP connection has already been established, they know something is on that port. It might be nice if they didn't know it was IIS on the other side

Improve this question
2
  • 1
    Phishing is more a social engineering attack aimed at geting a person to reveal passwords, etc. This is more a port scanning or domain scanning attack.
    – Knox
    Aug 30, 2011 at 12:35
  • 1
    There is no way for them to NOT know that your server exists; it has already opened a TCP connection to their system in order for them to send the hostname.
    – Kevin M
    Aug 30, 2011 at 12:37

1 Answer 1

Reset to default
1

When you say "random domains" you mean hostnames right? Not IP addresses?

If the former, a hostname is, at least in theory, completely disconnected from the actual IP address of the server from the point of view of the server. Every (well, almost every) HTTP request will have a HTTP-Header called 'Host', it's very easy to simulate or "fake" it. Take the following command

curl -H "Host: serverfault.com" http://www.google.com/

(Ignore the output)

That command gets Google's servers to respond to a request for 'serverfault.com' as if it was a normal virtual host, which in the case of Google looks like it's pointing to a file that redirects to the main Google site.

Put simply, there is no way to 'block' these requests without getting your firewall to analize each request and that opens up a whole other world of issues. A 404 or 403 response is correct, 404 means the resource does not exist on the server, although normally this reffers to a file, it could reffer to an entire site too.

Your server choosing to respond or not, is based (simplisticly) solely on the target IP address, not the hostname. By the time the server gets to reading the hostname it's already established a connection. Yes you could get it to just drop the connection but responding with a 404 is a much better option because it officially tells the client the resource does not exist.

Improve this answer
3
  • nginx does have the ability to parse the hostname, and respond based on the results - if it's incorrect (or non-existant), nginx can return a 444 code (not a real code, basically tells nginx to not respond at all to the request, not even a 404). Would IIS have any similar capability?
    – Cyclops
    Aug 30, 2011 at 12:57
  • @Cyclops Yes but it's still returning /a/ response, it can return any response it wants but it has to return something. My best suggestion would be setting up a 'catch all' vhost (All domains without their own VHOSTs) and getting it to 301/302 redirect to your main site. Not an IIS user so not exactly sure how one would do that but Apache will respond to all unknown domains with the first VHOST it finds in it's config. You could even get it to respond with a message telling them to go away, but they probably won't read it =)
    – user80776
    Aug 30, 2011 at 13:07
  • No, when I use the 444 code in an nginx reply, it does not return any response - my browser testing shows that the browser times out waiting for a reply. A server does not have to return any response if it doesn't want to... (granted there may be some HTTP standards it's breaking, but so what :) Nginx Docs: "nonstandard code 444 closes the connection without sending any headers"
    – Cyclops
    Aug 30, 2011 at 13:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .