Hi,

The packets may not be malformed - it may be that the end client is using a
DNS server that is incorrectly configured (so that even though you are
hosting site1.com, the remote DNS has site2.com pointing to your IP address
rather than correct IP address).

In the case that a request comes in with a host header that matches none of
the websites on your machine, then IIS will look for a site that is
listening with no host header value *and* specifically bound to the IP
address that the request came in on.

If there is no matching site, then IIS will look for a site that has no host
header, and is listening on "all unassigned" IP addresses.

And then, if there are no matching sites, a 400 Bad Request will be sent
back to the client.

So the pattern would be (assuming all sites listening on port 80 - otherwise
we'd also need to add a check for the port being used):

Is there a site that matches Host Header + IP address?
Is there a site that maches IP address?
Is there a site that is listening on "all unassigned"?

Cheers
Ken

"asmizer" <asmizer@discussions.microsoft.com> wrote in message
news:794BB815-30BA-480F-BDE7-8244D454AFB5@microsoft.com...
>
>
> "Ken Schaefer" wrote:
> 
>
> The incomming packet is intentionaly malformed. Why? I assume it is an
> attempt to probe for some vulnerability in the web server or to learn if
> the
> server is configured for host header checking (an inteligence gathering
> probe?).
>
> So the incomming packet which is addressed by IP to the server has a host
> header which will essenntially be ignored by the default IIS
> configuration.
> Is it then safe to assume that IIS treats this connection request tha same
> as
> if it had come in with mysite.com instead of yourstie.com?  The server
> result
> being to hand back the "default" home page for mysite.com?

[ Post a follow-up to this message ]