Pïd stèr wrote:
On 16 Apr 2013, at 19:38, "André Warnier" <a...@ice-sa.com> wrote:
Pïd stèr wrote:
On 16 Apr 2013, at 17:58, chris derham <ch...@derham.me.uk> wrote:
Or, another way of looking at this would be that for every 40 servers
scanned without a 404 delay, the same bot infrastructure within the same
time would only be able to scan 1 server if a 1 s 404 delay was implemented
by 50% of the webservers.
This assumes that the scanning software makes sequential requests.
Assuming your suggestion was rolled out (which I think is a good idea
in principal), wouldn't the scanners be updated to make concurrent
async requests? At which point, you only end up adding 1 second to the
total original time? Which kind of defeats it.
Again I'd like to state that I think you are onto a good idea, but the
other important point is that some (most?) of these scans are run from
botnets. These have zero cost (well for the bot farmers anyway). My
point is even if the proposal worked, they don't care if their herd is
held up a little longer - they are abusing other people
computers/connections so it doesn't cost them anything directly.
Sorry but those are my thoughts
I tend to agree. Effort will just be expended elsewhere, and that's
assuming this would have enough of an impact to be noticed.
Say that it would be easy to implement this in Tomcat, and that we do not
collectively
find good reasons not to do so, and that it does get implemented.
Then I pledge that my next move would be to bring this similarly onto the
Apache httpd
list (using the Tomcat precedent as an introduction of course (à la "hey guys ?
those
smart Tomcat developers have just had a great idea etc..")).
I haven't checked the actual numbers yet, but I would imagine that between
Apache httpd
and Tomcat, we're talking of a significant proportion of the overall
webservers, no ?
Only if you can get them updated in a timely fashion.
I'd say that one has to start somewhere. Obviously, individually getting in touch with
each Tomcat sysadmin on the planet is not going to be practical.
But implementing this in the next released version of Tomcat would at least make it so
that any new installation implements it by default.
And only if the default setting is 'on'.
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 ? (other than for the botnet industry of
course)
A drawback of the scheme, for which I do not have a good solution at the moment, is that
it is a bit like a telephone network : the more people have one, the more useful it
becomes, and the more will want it. Conversely, the slower it spreads, the longer it will
take for any effect to be felt. So how could one go about making sure that it spreads as
quickly as possible ?
That's one problem of open-source/free software : you cannot offer a discount to early
adopters.
Incidentally, nobody has commented yet on how easy/difficult it would be to actually
implement this technically, in an efficient way.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
