>-----Original Message----- >From: André Warnier [mailto:a...@ice-sa.com] >Sent: Wednesday, April 17, 2013 10:28 AM >To: Tomcat Users List >Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html >HTTP/1.0" 404 > >Leo Donahue - RDSA IT wrote: >>> -----Original Message----- >>> From: André Warnier [mailto:a...@ice-sa.com] >>> Subject: Re: Tomcat access log reveals hack attempt: "HEAD >>> /manager/html HTTP/1.0" 404 >>> >>> >>> That's the idea. That is one reason why I brought this discussion >>> here : to check if, if the default factory setting was for example >>> 1000 ms delay for each >>> 404 answer, could anyone think of a severe detrimental side-effect ? >>> >> >> What if I send 10,000 requests to your server for some file that is not >> there? > >Then you will just have to wait 10,000+ seconds in total before you get all >your >corresponding 404 responses. >Which is exactly the point. > >Do you know of a real legitimate scenario in which a HTTP client (or more of >them) would issue lots of requests for resources which they know might not >be there ?
No, I honestly don't. I was thinking like a miscreant in that I would do it intentionally to force your server to queue for the next 2.5 hours to return 404 messages to those 10,000 requests for nothing. Now I would have a new tool for DOS? But you point out something interesting further down... >(this is a real question; it might be that there is, and that would be a real >flaw >to the >scheme) > >More details : > >- legitimate, well-written applications should not normally be returning pages >to the user, which contain lots of links which lead to nothing and result in >404 >errors. >So once a browser got to one of your normal pages, he should be able to >continue navigating your site by clicking on links that work, not links that >result >in 404. >So adding a 1 second delay before returning a (legitimate) 404 response >should not bother legitimate users of legitimate applications too much. >Even genuine legitimate and useful bots (like the Google ones), get your >home page, and then (unless you tell them not to), they follow the links that >they find there to get more pages and index your site. So they too should not >get much inconvenienced by a delay in the 404 responses. > >- on the contrary, the way hacking bots work is that they are purposely trying >to find, on your server, specific links which are known to sometimes >correspond to generic applications which have security flaws. On most >servers, these links do /not/ correspond to real available resources, so they >result in 404 errors. That is what the bots expect, so when they get a 404 for >one such link, they immediately try the next buggy one in their list, etc. If >they get 404's for all of them, then they will give up, and switch to scanning >some other server. >In that case, by returning the 404 response quickly, you are actually helping >them to spend little time on a non-existent flaw and to be able to try the next >one sooner. >But if for each 404 response, you force them to wait 1 second instead of 10 >milliseconds, then you immensely slow them down. They will have to wait >that 1 second, because otherwise they could never be sure if your server (or >the network at that moment) is really slow, or if this is a deliberate delay. >(And if you're really into making this even more annoying for them - hehe - >you could even slightly vary the delay for each 404, say between 0.5 and 3 >seconds, to make it even more unlikely that they will figure out some >pattern). > >A vital part is to design an implementation for this, that from the point of >view >of your own server, is as lightweight as possible. You do not want to force >one >of your real working threads or instances to have to sit there during the 1 s >delay doing nothing. >You'd want to hand off this connection and response to some specialised >lightweight thread, and go handle the next real worthy request. So you are saying it could be possible to know in advance that certain requests are for repeated requests of nothing or being made by a bot, versus regular legitimate requests, in order to move those bot requests off to another thread? >But I am sure that the tomcat gurus here will have some good ideas for that >part. >
