Deny HTTP/1.0

want to deny http/1.0 request totally

[debajit kataki]

Hi All,

I am trying to implement a Deny for HTTP/1.0 like this, but this is not helping me.
1/ Via SetEnvIf i am unable to

Ex.
<VirtualHost *:80>
ServerAdmin
DocumentRoot "<someDir>"
ServerName website.com
ServerAlias www.website.com
SetEnvIf Request_Method . bad_http_req=y
SetEnvIf Request_Protocol HTTP\/1\.0$ !bad_http_req
SetEnvIf bad_http_req y BadReq=y

<Directory "<someDir>">
Options Indexes FollowSymLinks
AllowOverride None
Order deny,allow
Deny from env=BadReq
</Directory>

2/ Can a Rewrite Rule also help me?

Please help.

~Debajit Kataki

[jdMorgan]

1) Denying requests that "claim" to be using HTTP/1.0 is a bad idea: Many legitimate search engine robots (for example, Yahoo's Slurp) claim to use HTTP/1.0, although they're really using an "enhanced" version which adds the HTTP "Host" header to the request... Sort of an "HTTP/1.01".

2) If you are on a name-based virtual host (and each virtual server does *not* have its own separate IP address), then it is technically impossible to connect to your virtual host using HTTP/1.0; Only the default server --the first virtual server defined-- will be accessible. This is because HTTP/1.0 does not support the HTTP "Host" request header, and the Host header is required on name-based virtual hosts in order to "pick" which virtual host the request is being addressed to. In most cases, the response to a true HTTP/1.0 request will be a 400-Bad Request.

3) If you did manage to get that code working, but you later tried to use custom error documents (see Apache core ErrorDocument directive), then the result of blocking a request would be an 'infinite' loop: The server would try to respond with a 403-Forbidden response code, and to serve the custom 403 error document. But this would result in another 403 error because access to *all* resources --including the custom 403 page-- is denied. So the server would generate another 403 error and then try to respond to it, creating another 403, and another, and another... This would continue until either the client or the server gave up.

Your code does not appear to do what you say you want. In fact, it appears that it will reset the tested variable instead of setting it for HTTP/1.0. Showing only the relevant lines, I'd suggest something like:

SetEnvIf Request_Protocol HTTP/1\.0$ Bad_Req
SetEnvIf Request_URI ^/path-to-your-custom-403-error-page\.html$ Allow_Bad_Req
#
Order Deny,Allow
Deny from env=BadReq
Allow from env=Allow_Bad_Req

In mod_rewrite, something like:

RewriteCond %{THE_REQUEST} HTTP/1\.0$
RewriteCond %{REQUEST_URI} !^/path-to-your-custom-403-error-page\.html$
RewriteRule .? - [F]

Would do the same thing.

However, because of the fact that you'll block major search engines with either of these approaches, I cannot recommend them at all. So what is the actual problem that you are trying to solve?

Jim

[debajit kataki]

Thanks Jim,

I was aware of the point that, HTTP/1.0 can reach out only my first VHOST, but what i saw was that in my almost all 15 Vhost i have some HTTP/1.0 calls.

May be some WGET calls from my apps engineer was causing the issue, which we changed to libcurl. They do so, activate caching instead of waiting for users calls to do the same ;-) Now, when again i see the same, i digged out and it was not some genuine search engines which is doing so, by looking at the query being fired.

So hence decided to drop them. I would test today your suggestions and will surely let you the outcome.

Thanks once again for such a detail reply

~Debajit Kataki

[jdMorgan]

> I was aware of the point that, HTTP/1.0 can reach out only my first VHOST, but what i saw was that in my almost all 15 Vhost i have some HTTP/1.0 calls.

So that means these are not true HTTP/1.0 requests, because if they were true HTTP/1.0 requests, they would not contain the HTTP "Host" header, and would therefore not be able to reach your non-default vHosts -- They would have no way to send the Host header used to match your "ServerName" directives in httpd.conf.

Look at the IP addresses, user-agent names, reverse-DNS hostnames, and all HTTP headers sent with these requests -- You may be able to selectively block them based on a combination of these factors, and so avoid blocking desirable accesses.

Jim