Blocking access to pages by IP address and client type
Hi,
I am trying to block access to our 6.1SP6 web server from an automated web crawler based on its IP address and client-type header.
I have added the following lines as the first entries at the top ofobj.conf:
<Client match="all" ip="192.168.1.1" browser="*Java/1.4.2_06*">
AuthTrans fn="set-variable" abort="true" error="412"
</Client>
N.b.I need to filter on both attributes as the IP address only refers to a common gateway used by multiple clients and I want to be sure to restrict access to only this instance of the client.
>> Is this the most effective way in which to block this client?
>> What is the syntax to block the client on our legacy v6.0 SP9 server?
Thanks for your help
[950 byte] By [
secEng] at [2007-11-26 9:18:23]

# 1
One wouldn't normally use HTTP status code 412 to deny access. 412 means Precondition Failed, and it is defined in the HTTP/1.1 specification as follows:10.4.13 412 Precondition Failed
The precondition given in one or more of the request-header fields
evaluated to false when it was tested on the server. This response
code allows the client to place preconditions on the current resource
metainformation (header field data) and thus prevent the requested
method from being applied to a resource other than the one intended.
Instead, one would normally use HTTP status code 403. You can use PathCheck fn="deny-existence" to return a 403.
# 2
Hi elving, thanks for replying.
I actually kadged parts of the code from a couple of blog articles written by DZM, which I believe he actually did with yourself:
* Aborting common security 'bot requests in Web Server 6.1, and
* Blocking external image linking with Web Server 6 and 6.1
In these he returns HTTP status code 412 to block or abort the requests.
Anyway, if you think that its more appropriate to return a status code 403 I'll change the directives; thanks.
On my 2nd question:
Is it also possible to block these requests on a v6.0 SP9 server? If so, please could you give some example code; thanks again.