Msg#: 4088160 posted 12:00 am on Feb 27, 2010 (gmt 0)
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.
Msg#: 4088160 posted 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?
Msg#: 4088160 posted 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?
Msg#: 4088160 posted 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?
Msg#: 4088160 posted 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.