I've just noticed several entries in my "trap" logs that show the site's IP instead of its domain name (HTTP_HOST). It appears the actual page is appended to the IP but I'm not certain about that.
All instances I've seen, from two IPs (one italian, one UK) have been blocked: they had no valid headers so were blocked anyway. The UAs are common bad-bot ones:
Mozilla/4.0 (compatible; MSIE 7.0; WIndows NT 6.0)
Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.1) Opera 7.01 [en]
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.
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?
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?
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?
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.