-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 4/22/13 6:44 PM, André Warnier wrote: > Christopher Schultz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Chris, >> >> On 4/20/13 6:08 PM, chris derham wrote: >>> I think that you have articulated your suggestion very well. I >>> think you have weighed the pros well and been open to debate. >>> Personally I just don't think what you propose will have the >>> effect that you desire. >> >> I agree. Most of these scanners only scan a few URLs every few >> seconds in order to avoid being branded as >> vulnerability-scanners, so adding a delay to them won't really >> change anything. >> > Chris, with respect, I believe that you are mistaken. My own > server logs, over a quite long period of time, show that the > majority of these scans happen according to a rather systematic > pattern like the one I posted earlier in this thread, with a > relevant portion re-posted below. > > That is : - one origin IP per scan - approximately 3-4 requests per > second - 10 to 30 URLs per "session" > > The particular scan shown below started at 00:52:32 and ended at > 00:52:49, after scanning 36 different URLs. In elapsed time, > including the pauses that it undeniably makes, that is 17 seconds. > The server in question normally responds to such requests in less > that 10 ms. Excluding the pauses thus, it took this bot 36 x 10 ms > = 0.36 s "real time" to scan the 36 URLs (excluding network > latency, which is probably about 50 ms per URL). If the server > added an average 1 s pause to each 404 response, it would have > taken the bot 36 seconds "real time" to make the same scan. That > is 100 times more. Yes, but the attacker has more source ports than you have destination ports, can run in parallel, and doesn't really care if you delay him. Your proposal, while interesting in an academic sense, is IMO unlikely to deter anyone. > Now, no matter how smart the bot is in doing this kind of scan, if > the 404's are delayed, the fact of the matter is that it will > always cost the bot these extra 36 seconds to finish the same job. If an infinite number of monkeys continues typing, Macbeth will eventually emerge... infinite time times 4 seconds is still infinite time. As for your solution, it sounds (relatively) easy to implement, but of course requires all those people out there you are talking about (lazy system administrators) to upgrade to the latest Tomcat, etc. Doesn't it mean that only the admins who are really proactive about this kind of thing will actually benefit? Those are the ones who don't really need it because they are being proactive in other ways. Yes, maybe in 10 years everyone will have upgraded to a version that stymies the attacks you propose, but by then (if not now), the mitigation will be irrelevant. Feel free to give this kind of implementation a shot. I won't stand in your way, but I still don't think it's going to be at all effective. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRdegAAAoJEBzwKT+lPKRYV28P/jwIi21KlF2QVPvVerJYiqph 3aL+eueDAiJLPdUWfNwFcHv2iHG++ad5UHUkS0Agam+AW+m3gyLkJlrCpyYrDdfO WA66ju/NcWYEhOsEtnqghNAzdtj8QuQo0Gl050hy+zUlT8UBPEwxpbNfxaN7cHBX kO0oy6xZ4uxTWMCkYJYOUIN4a0BDOrTUJXf1Wh1EjuFYxCWXd+pgx6JfOTvL6cHQ DKoV8ShI93ugxIfI8ZEOEqwArubp+kIOkiPJ+y1iBljmL5KMxTqv1D6b69jmNZZA jHO9Q419+ZkzoWultQT8vJgcz3vUtF+tYgwr1X/lm+wYqNIxGZF+ORcS6DWZTKZ8 3rusrUm+tqgC4khmrWdn+7TaOyV8rXO9eQztpkuosgdnzyWa+blegO0VGK3AHLns I5crrZ2BTuL6KVR23nss1LDH4UxGAyvHcCYQ0x1K7tc9QtO9czXfzfUKQP7F9IhN M7QV+1GFAil9rQ1Xa4+eMWMw3Ny+FIHWUxofvi3NO3T6PgY480JvbIFtIX0OGtD+ pVtKCb8hTvcWGCKGPHGXAROA3mnUWLYBXEDzHi84JjYA/SxiH8GDy8KuvggmaL2k vhAA/ePr/IZhm13Nf+c/MEoCGm/+2XPw76HOSpvTfizGZ0ncxJlQrwKu+oWlXxl3 l8Umz215WtNX8wvDl71J =gd26 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
