IIS6 Directory Security IP Restrictions (Windows 2003)

PHP site log recording banned IPs

[dstiles]

Most of the sites on my web server block the same IP ranges - eg some Amazon, US servers, Chinese etc ranges. These bans are specific, mostly as /17 to /14 ranges. As far as I can tell I've never had a "breakthrough" from these IPs, at least nothing that has shown up in logs. All of these sites are ASP coded.

I recently set up a mail server's PHP WebMail interface on the same server. It has its own IP and its own sub-domain (eg: wm.example.com) and has, for practical purposes, only an https port enabled.

In the IIS control panel I have set up the IP ranges for this "site" to "Allow Only..." instead of "Allow All Except...", the IP ranges being mostly UK broadband ranges so my customers can use the interface whilst keeping out the world at large.

I was expecting the log for this site to show nothing for any IP that wasn't enabled. In fact, I'm getting approx one hit per day (eg fake google UAs, attempted hacks etc) from blocked IPs. Has anyone else seen this sort of thing? (It is possible, of course, that my statement re: not seeing ANY blocked IPs on the other sites is slightly innacurate.)

The log format is W3 extended (same as all the others, with the same fields enabled). An oddity is that sometimes the log shows the rDNS value instead of the raw IP - is this some feature of PHP? I wouldn't have expected there to be any difference.

Anyone have anything helpful on this, please?

[Ocean10000]

In the log file what is the status code that it is reporting, for the fake ua's. The status code might be of a rejection, and being recorded for tracking purposes.

I do not know much about php on iis so i am not sure if it is reporting something different then a normal asp site would in the logs.

[dstiles]

Sorry, forgot to say. The rejection code is 403 but that may be internally generated due to bad path/page names - I do not know the processing code used but all accesses are to non-existent pages, as with most php exploits.

I see no reason for recording for "tracking" purposes: it should not, in my experience, be let anywhere into the IIS web service at all. The security command says specifically: "Keep out".

[Ocean10000]

Based on that I am assuming the server processed the requested but refused to respond. This looks like the standard way to reply to a request that is blocked to me.

I am going to quote the definition of the 403 status code from the rfc for http 1.1 [w3.org] for reference.

403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

[dstiles]

If it got to the server, yes. As I understand "directory security", the request should never get to the server at all but be rejected as if at a firewall.

[haggul]

No that sounds fine to me - it's what I'd expect anyway - try and ban your own IP and you'll get a similar message.

Look at IPSec if you want an easy way to block certain traffic completely, or of course some sort of firewall.

[dstiles]

Difficult to block / allow ranges of IPs in IPSec for a given service (in this case https on a specific IP with port 443 but ALSO a full range of mail ports on the same IP but blocking a different range of input IPs).

[haggul]

True - if you need that granular a level of control then it sounds like firewall software / hardware is the way to go.