Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

In my log watch records there has been a steadily growing progression of these:

  408 Request Timeout
      null: 694 Time(s)

On my webserver.

Here are some of what look like the contributing requests from the /var/log/apache2/access.log access log:

ip - - date requestsfor"-"? httpcode bytes referrer useragent
75.149.117.146 - - [28/Jan/2013:17:49:47 -0500] "-" 408 0 "-" "-"
65.55.215.247 - - [28/Jan/2013:17:57:40 -0500] "-" 408 0 "-" "-"
205.157.206.75 - - [28/Jan/2013:18:00:21 -0500] "-" 408 0 "-" "-"

Normal access request examples of course have a lot more relevant info like this:

ip - - date request-for httpcode bytes referrer useragent
66.251.23.171 - - [28/Jan/2013:17:45:41 -0500] "GET /images/al/al-mb0608tn.jpg HTTP/1.1" 200 4085 "http://example.com/brands.php?F=S&BrandCode=AL" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"

See a larger sampling of my access log here (with a few normal get requests that 408 in with the rest)

I did reverse IP lookups on the ips, and they seem to come from diverse locations in the US and Canada. That could just mean that there is a proxy involved, I suppose? There is a large block from:

96.42.74.117 - - [18/Feb/2013:02:55:58 -0500] "-" 408 0 "-" "-"

That repeats frequently.

I hesitate to jump to conclusions that this is an attack as opposed to a fault, but the number of probes recorded has been steadily increasing at around the same time, e.g. logwatch also says

 A total of 125 sites probed the server
    107.22.9.89
    108.132.76.100
    108.172.60.59
    108.226.133.142
    12.166.56.82
    12.54.94.24

.... on and on with a list of various ips that used detected probes against the server. There is some overlap of the ips listing as "probing" the server and the ips that hit the access log with nulls, so that may suggest an attack, but since the server has to serve requests, it'll be hard to tell a legit timeout from a DOS request timeout attack if that's what is going on here.

How do I debug this problem, or if it is an attack, deal with this attack?

share|improve this question
    
What is that? An apache error log? More details please –  Mathias R. Jessen Feb 13 '13 at 13:46
    
The "408 request timeout null: 694 times" and "a total of 125 sites probed the server" messages are from the logwatch log summarizing app, which emails me out info about the server logs on a daily basis. The others are entries from a grep of /var/log/apache2/access.log I also clarified in my question now. –  Kzqai Feb 13 '13 at 17:51
    
what is your value for Timeout in httpd.conf? –  mt_ Feb 13 '13 at 17:55
    
Looks like it is the rediculously high number of 300 seconds: # # Timeout: The number of seconds before receives and sends time out. # Timeout 300 –  Kzqai Feb 13 '13 at 18:38
    
I've lowered it to 150 seconds, though I guess that will only increase the number of timeouts, of course, but I guess at least the requests that timeout wont hold onto resources. –  Kzqai Feb 13 '13 at 18:43

1 Answer 1

up vote 4 down vote accepted
+50

From some researching I did, these are some possibilities leading to 408 message. You can test each to identify the relevant one for your case.

1) Very low Apache TIMEOUT value - your web server could be ending the session before the client even get the chance to send a request.

too many 408 error codes in access log

2) browser predictive optimization - you can easily test this with different browsers. Simply do tail -f /var/log/apache2/access.log, while using relevant key words which would bring up your site on first search page, hover over the link pointing to your site, check if the site preview appears.....all these without clicking on the link which opens your website.

http://forum.linode.com/viewtopic.php?f=10&t=8048

3) denial of service attack - ddos warms such as slow loris can open too many connections to the server without sending a single bye tying up all the Apache processes.

http://blog.spiderlabs.com/2011/07/advanced-topic-of-the-week-mitigating-slow-http-dos-attacks.html

A quote from above linke -

"The trick is to open a connection to the server but not send a single byte. Opening the connection and waiting requires almost no resources by the attacker, but it permanently ties up one Apache process to wait patiently for a request. Apache will wait until the timeout expires, and then close the connection. As of Apache 1.3.31, request-line timeouts are logged to the access log (with status code 408). Request line timeout messages appear in the error log with the level info. Apache 2 does not log such messages to the error log, but efforts are underway to add the same functionality as is present in the 1.x branch."

share|improve this answer
    
Fair enough, the browser predictive optimization one seems like it may well fit the situation, especially since the error logs match. So I'll have to verify that myself later. Thanks. –  Kzqai Feb 20 '13 at 16:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.