This has nothing to do with the server's ability to serve the content. Heck, I can even reproduce the effect myself. If I simply run "telnet localhost 80" from the server, a line like: 2-2 14313 0/3/52 R 0.02 4 3 0.0 0.01 0.09 ? ? ..reading.. is added to Apache Status, and stays there until it either times out (error 408!) or I close it. Clearly, apache doesn't even try to determine the IP that the connection is originating from until an actual request is made. It stands to reason that the origin IP isn't being passed to modules like mod_choke, so they can't block the connections. This means that I could easily DoS myself by running the "telnet localhost 80" command MaxClients times, leaving each one open until it times out several minutes later, and re-running. This is very wrong. I can't figure out why Apache doesn't have any defense against such an obvious attack -- even the connection limiting modules can't help because they have no way of knowing that all the requests are coming from the same IP. On 5/28/06, Graham Frank <gfrank@xxxxxxxxxxxxxx> wrote:
Error 408 means request timeout. Make sure your server isn't having an issue serving the content. If you can verify that it is an attack, then read the following; otherwise, skip it. While I will leave the Apache modding suggestions to the people here who are sure to do so ... let me give you the iptables command to get rid of this issue (assuming you use linux). iptables -A INPUT -s 87.10.176.44 -j DROP iptables -A OUTPUT -s 87.10.176.44 -j DROP Look into getting a firewall so that you can easily defend against other types of DOS attacks. As for why it doesn't list the IP is exactly because of what server-status says: It's still reading the request, and that includes the IP. --Graham Frank -----Original Message----- From: Sergey Tsalkov [mailto:flightsimguy@xxxxxxxxx] Sent: Sunday, May 28, 2006 12:50 PM To: users@xxxxxxxxxxxxxxxx Subject: [users@httpd] need help fighting DoS attack on Apache Hey guys.. My Apache was hit with a DoS attack, where the attacker was opening connections to the server and not sending any data. It quickly reached the MaxClients limit and prevented any further connections to the server. The Server Status was filled with lines like this: 7-2 4039 0/8/8 R 0.01 3 25 0.0 0.01 0.01 ? ? ..reading.. ..and the apache log with lines like this: 87.10.176.44 - - [28/May/2006:17:26:24 +0000] "-" 408 - "-" "-" For some reason, Apache isn't listing the IP of the connection in Server Status until that connection actually makes a request. Anyone know why? Anyways, I tried mod_choke's functionality for limiting multiple connections from the same IP. That didn't help.. I suspect mod_choke doesn't activate until a request is received through the connection, so this script can dodge it by opening connections, not requesting anything, and keeping them open until they time out. mod_evasive was similarly unhelpful. I managed to stop the attack by setting IP bans at the firewall, but that doesn't actually solve the core problem. Anyone have any suggestions? --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|