detect loop redirection?

[anewday]

ERROR	[66.x.x.x:60600-0#APVH_forum.mywebsites.com] detect loop redirection

I saw this on the log for my forum, what does it mean?

 

[mistwang]

that means that somehow LSWS received a internal redirection request the same URL.
You can check your access log for URL causing this problem.

 

[anewday]

error_log file only shows that same line, I know the url causiing it but doesn't give any clues why it's doing that. There are only 3 instances in the log, all from today and it's coming from a google IP.

 

[brrr]

I got the same error today. A visitor or bot from Shanghai on 61.152.244.44 came probing against the direct IP of the server, searching for vulnerable code, using a user agent that was blocked by a LSWS server rule.

This is from the access log:

61.152.244.44 - - [19/Jul/2008:11:20:42 ] "GET /manager/html HTTP/1.1" 403 381 "-" "Mozilla/3.0 (compatible; Indy Library)"

This is from the error log:

2008-07-19 11:20:42.160 [NOTICE] [61.152.244.44:1513-0#Example] [client 61.152.244.44] mod_security: Access denied with code 403, [Rule: 'HEADER_USER_AGENT' 'Indy Library']
 [Msg: Badbot blocked]
2008-07-19 11:20:42.179 [NOTICE] [61.152.244.44:1513-0#Example] Content len: 0, Request line: 
GET /manager/html HTTP/1.1
2008-07-19 11:20:42.179 [NOTICE] [61.152.244.44:1513-0#Example] Redirect: #1, URL: /error404.html
2008-07-19 11:20:42.179 [ERROR] [61.152.244.44:1513-0#Example] detect loop redirection.

In the code above, you will also note that I have set a custom page for 403 errors, which redirects them to use the same page as 404 errors.

Is this 'detect loop redirection' anything to worry about? It seems that somehow an error has been generated, but I can't understand why. The LSWS is still running fine.

I think the 'manager/html' page they were looking for relates to several potential vulnerabilities in a variety of web applications.

 

[mistwang]

No worry unless something broken.

 

[brrr]

And again:

2008-07-24 02:40:45.357 [NOTICE] [218.58.226.13:4455-0#Example] [client 218.58.226.13] mod_security: Access denied with code 403, [Rule: 'HEADER_USER_AGENT' 'Indy Library']
 [Msg: Badbot blocked]
2008-07-24 02:40:45.378 [NOTICE] [218.58.226.13:4455-0#Example] Content len: 0, Request line: 
GET /manager/html HTTP/1.1
2008-07-24 02:40:45.378 [NOTICE] [218.58.226.13:4455-0#Example] Redirect: #1, URL: /error404.html
2008-07-24 02:40:45.378 [ERROR] [218.58.226.13:4455-0#Example] detect loop redirection.

I know it isn't a fatal error, so I am not worried about it, but it keeps coming up.

 

[mistwang]

Maybe add a /error403.html page will fix this.

 

[brrr]

The /error404.html page is a custom static page that I have all my 404 and 403 etc errors point to, with the idea that by pointing all error codes to one standard response page I will give [unsophisticated] attackers minimal information about how the server responds to various types of problems.

Perhaps the issue may be that when LSWS is asked to deal with a 403 response, it's default behaviour is to respond with zero bytes of nothing, and also not log its response (as discussed previously in this forum).

And yet the security rule here is telling LSWS to explicitly record the error as a 403, and other server settings are also telling LSWS to serve up a custom page when it is asked to process a 403.

Maybe that causes some issues for the internal logic of the LSWS code.

 

[mistwang]

It is because the request has been redirect to /error404.html twice.

Does /error404.html exist?

Maybe create a /error403.html exactly same as the 404 page, and set 403 error page to that one.

 

[brrr]

It is because the request has been redirect to /error404.html twice.

Does /error404.html exist?

All server errors except 401 were being pointed to a custom static file called error404.html, which does exist as an actual file in the server default root.

Maybe create a /error403.html exactly same as the 404 page, and set 403 error page to that one.

What I've done instead is modify the BadBot blocking security rule to just deliver a 404 response if it gets a match, and not deliver a 403 response.

If that doesn't work, I'll try your suggestion next.