My problem is: how does this access get through in the first place? The (IIS) server itself returns a 400 before it ever gets near the page, yet my traps require a page to be accessed before the trap can work.

I've now added a specific trap for this and added environment logging to see what's happening.

vrtlw

1:06 am on Feb 27, 2010 (gmt 0)

I'm struggling to understand why this would concern you, sure it may not be a demonstration of normal traffic but it doesn't elude to "illegal access". I'm assuming you have a dedicated IP address for the site. Obviously if that's the case then it could represent a network scanner scanning the network you are on but if you are patched up (which you should be) then it really isn't an issue. Am I missing something?

dstiles

8:52 pm on Feb 27, 2010 (gmt 0)

The implication is that there is something weird and probably (from experience of other things) probably illegal going on. I block on several features but if this kind of access gets through with a genuine browser header the server is likely to be scraped.

And since several of the IPs run more than one site it could return any of them or simply a 404. The whole access is wrong and I want to know how it's getting through the IIS server's access-by-IP block.

The real issue is: how is it getting past the server's block?

caribguy

10:26 pm on Feb 27, 2010 (gmt 0)

you are patched up (which you should be) then it really isn't an issue

/pontificate mode on

I think it's wise to monitor and pre-empt abnormal traffic. When the next 0day hits, it may just make all the difference between damage control (including restoring your server) or applying a patch to remove the vulnerability.

/pontificate mode off

dstiles, have you been able to replicate the issue yourself? If so: does your accessrule that blocks this kind of traffic work as intended when on its own or when slowly adding back other rulesets?

dstiles

2:44 am on Feb 28, 2010 (gmt 0)

There are no conventional rulesets as such. The 400 code I mentioned is produced by the IIS server itself.

The IIS server itself rejects anything with an IP. You need to add the IP as a host if you want to accept an IP Host access (or, of course, set it to accept all Hosts on the IP).

In place of htaccess I use "home made" trap software. It picks up most things that most sites experience plus a few that are unique to some of my own sites. It's currently undergoing a major re-write, the fourth in eight years, to streamline it.

The 400 code plus a few lines of header was returned to me when I accessed it through Sam Spade. Through a web browser the page shows "Bad Request (Invalid Hostname)".

Unwanted activity is down a bit during weekends. Hopefully (if the attacker is still out there) my addition to the trapping software will show something in a few days time.