chris derham wrote:
Hi.
Long and thoughtful post. Thanks.
just hope it helps move the discussion forward
Say you have a botnet composed of 100 bots, and you want (collectively) to
have them scan 100,000 hosts in total, each one for 30 known "buggy" URLs.
These 30 URLs are unrelated to eachother; each one of them probes for some
known vulnerability, but it is not so that if one URL results in a 404, any
of the others would, or vice-versa.
So this is 3,000,000 URLs to try, no matter what.
And say that by a stroke of bad luck, all of these 100,000 hosts have been
well-configured, and that none of these buggy URLs corresponds to a real
resource on any of these servers.
Then no matter how you distribute this by bot or in time, collectively and
in elapsed time, it is going to cost the botnet :
- 3,000,000 X 10 ms (~ 8.3 hours) if each of these URLs responds by a 404
within 10 ms
- 3,000,000 X 1000 ms (~ 833 hours) if each of these URLs responds by a 404
delayed by 1 s
So if a bot sends a request for http://server/, it will presumably get
a 302 response back redirecting to say http://server/index.html, and
to use your figures lets say this takes 10 ms - call this
goodResponseTime. Now the bot sends a request to the server for
http://server/manager/html. If the server has implemented "delay 404"
(as it seems to have been christened), the server will delay response
for say 1s. The scanner writers can just abort the connection after
say 2*goodResponseTime or 3 if they want to reduce false positives.
Perhaps spider the links in the good page returned initially and get a
feel for average response times for say 10 valid calls, then start
making probing calls to reduce false positives. Simply abort any that
take "too long" and carry on to the next host and/or the next url on
the same host.
My contention is that this would be self-defeating for the bots.
I have to admit that my calculations are of the back-of-the-envelope type, as I have
neither the skills nor the time to do a real mathematical/statistical analysis.
But having written - and regularly running for customers - a few instances of "URL
checkers" kind of programs (similar to a bot, when you think about it), I can tell you
that if you are going to access say 3000 real URL links, distributed over say 500
webservers, then if you do not give your program a timeout of at least 5 seconds before it
declares a link to be "dead", you are going to end up with a multitude of "false
negatives" (links which the program thinks are dead, but which are in reality not, just
happen to be a bit slow that day).
If I scan the same 3000 URLs and I set a timeout of (for example) 2 seconds, I will get
about 500 "dead" links, of which upon inspection more than half will turn out not to be
dead after all. In my case, that is unacceptable, because it means that someone must go
manually check 500 links, to eliminate from the database *only* those which are really
dead (otherwise after a few days, there would not be any link left in the database).
Admittedly, it is a bit of a different case, because here I am checking for real links
which were at some point working - otherwise they would not be in the database. And also
because in this case I do care deeply about not mis-labeling as not working, a link which
does.
But what I am saying is that if instead I set a timeout of anything as low as 100ms, I am
quite sure that I would be considering as "dead" maybe up to half of the URLs that I am
scanning. (Actually, to prove this I just did an experiment, described below (*))
So if we take 10 ms as being the goodResponseTime, and 3*goodresponseTime as being the
timeout after which the bot gives up, the bot is going to "mis-label" a lot of links as
"not working", while in reality they are.
Taking the point of view of the bot, what does this mean ?
The bot is looking for URLs known to (potentially) correspond to vulnerabilities. To be
such a vulnerability, the first condition is that the link would actually respond, by
other than a 404 (if the link returns a 404, or does not respond at all, it cannot be used
to break into the system, so it is of no interest). To ascertain that, the bot has to wait
for the response, at least a "reasonable" time. If it does not wait at least for this
reasonable time, then it is potentially going to miss out on a large proportion of
potential vulnerability candidates. Which means that in order to collect the same amount
of potential break-in targets, it will have to scan more systems.
(Which, considering that there are 600 million webservers in total, may not be a bad
strategy; but maybe I'm not thinking straight here. It does sound like throwing out the
baby along with the water though).
So it all hinges on what in this case is a "reasonable" time.
Now when a bot scans systems for such vulnerable URLs, I tend to believe that the vast
majority of attempts fail, and that it is only a tiny minority of systems on which those
links do respond in a way that is interesting for the bot. So if it starts by throwing
away already a significant portion of its potential targets, that must be self-defeating.
Incidentally someone suggested that the work to delay the response
could be farmed off to a side-kick thread. It is true that this would
minimize CPU over head server end. However at the low os level, you
are still keeping a socket open for a second (or whatever the 404
delay is configured to be). If scanners use the above technique, they
will end up creating say 30 connections to the server each of which
then has to stay open for 1 second. 30 additional connections won't
bring the server down, but it is still consuming more resources than
normal. Enough concurrent scanners and the server will suffer DOS. A
few pages with bad links that return 404 - maybe due to
miss-configuration - and google bots and their friends querying the
site could kick off the DOS.
You are talking here about 1 targeted server being submitted to a simultaneous scanning by
30 different bots (or more). That is more like a DoS attack than a real scan. If I look
at the pattern of these scans on any of my 20-odd servers, at the moment what I see is 1
bot (from one client IP address), trying 30 URLs sequentially, at a rate of about 3-4
accesses per second. Then the bot goes away. And then some time later (1 hour or two
maybe, sometimes a whole day), another bot from another IP address will come and scan for
another set of URLs (some the same, some different ones).
(All in all, not a very sophisticated strategy so far).
So we assume that as a result of such a 404-delay strategy, bots change their modus
operandi, and that instead of one bot scanning 30 different URLs in a row on one server,
we'll have 30 bots, each trying only 1 URL at a time on one server among 30.
To make sense, this would require that the individual bots are coordinated with eachother,
to avoid re-scanning the same host for the same URL from more than 1 bot of the set.
To do that, they must somehow be communicating either with eachother or with some central
coordinating authority. That looks to me like quite a quantum jump in complexity, and in
detectability (at least regarding that central authority).
But even if they do that, it is unlikely that all of these 30 bots would happen to be
scanning the same server (for a different URL) just at the same time.
So at the targeted server level it is quite unlikely that it would see a sudden bunch of
30 additional connections kept open for 1 s each. More likely, this is going to be a lot
more random and distributed.
As for the other points in your post : you are right of course, in
everything that you say about how to better configure your server to avoid
vulnerabilities.
And I am sure that everyone following this thread is now busy scanning his
own servers and implementing these tips.
I guess the point I was trying to make is that the whole idea is to
make the default install as secure as possible. So the sensible steps
included in http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html
would not be necessary, if they were already present in the default
install. Then if people want to open the server up, that's their
problem. I know that this potentially means that it may be harder for
noobs to get started with tomcat. It is a fine line to walk.
But my point is that, over the WWW at large (*), I am willing to bet that
less than 20% are, and will ever be, so carefully configured and verified.
And that is not going to change.
agreed. What we really need is a big carrot and a big stick to
encourage people to Do The Right Thing™.
Or the kind of thing which I am proposing : an internal change to the default Tomcat, not
too complicated to achieve (I think), minimally intrusive and having a minimal impact on
any normal use of Tomcat, and whose effect /may/ be to make life at least partially harder
for these scum-of-the-earth HTTP bots. If as a result, the bots must become incrementally
more sophisticated, more expensive, harder to set up and/or to run, I would feel that we
have achieved something already, at very low cost overall.
(*) under (**) below is a sample of bot scans taken from one of my servers.
I used a couple of the client IP addresses shown, to run a simple "traceroute" to the
origin. It turns out that it shows that just a "ping" to their IP address takes more than
100ms to return. (which tends to make sense, even if this is an ad-hoc explanation
after-the-fact : these bots are more likely to be running from some infected workstation
than from a server, and more likely also to be running from some out-of-the-way place
difficult to track down. So maybe their internet connection is not the best available).
Anyway, if the bot sends a request to the server, and then doesn't wait more than 100ms
before giving up, it is going to miss most of its targets only because of the network
latency. Never mind the HTTP server's response time.
This makes me think that, from the bot's point of view, opportunities for optimisation in
the ways that you indicated above may be limited.
(**) The following shows sample scans, over a few days, on one server. Actually, it is
just from the access log of the "default server", which basically processes only HTTP
requests which are made to the server's IP address instead of a real DNS hostname.
That same server hosts approximately 20 Virtual Hosts with different hostnames. If the
scans were made to these hostnames, they would appear in the respective access logs of
these hosts. But these hosts' logs show a lot less of those scans, which tends to indicate
that most HTTP bots scan per IP address, not per hostname.
Which does suggest another way of annoying them. Unfortunately, like most other ways, it
requires configuration that cannot be done by noobs.
209.212.145.91 - - [03/Apr/2013:00:52:32 +0200] "GET /muieblackcat HTTP/1.1" 404 362 "-"
"-"
209.212.145.91 - - [03/Apr/2013:00:52:36 +0200] "GET //admin/index.php HTTP/1.1" 404 365
"-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:36 +0200] "GET //admin/pma/index.php HTTP/1.1" 404
369 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:36 +0200] "GET //admin/phpmyadmin/index.php
HTTP/1.1" 404 376 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:37 +0200] "GET //db/index.php HTTP/1.1" 404 362 "-"
"-"
209.212.145.91 - - [03/Apr/2013:00:52:37 +0200] "GET //dbadmin/index.php HTTP/1.1" 404 367
"-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:37 +0200] "GET //myadmin/index.php HTTP/1.1" 404 367
"-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:37 +0200] "GET //mysql/index.php HTTP/1.1" 404 365
"-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:38 +0200] "GET //mysqladmin/index.php HTTP/1.1" 404
370 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:38 +0200] "GET //typo3/phpmyadmin/index.php
HTTP/1.1" 404 376 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:38 +0200] "GET //phpadmin/index.php HTTP/1.1" 404
368 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:39 +0200] "GET //phpMyAdmin/index.php HTTP/1.1" 404
370 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:39 +0200] "GET //phpmyadmin/index.php HTTP/1.1" 404
370 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:39 +0200] "GET //phpmyadmin1/index.php HTTP/1.1" 404
371 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:40 +0200] "GET //phpmyadmin2/index.php HTTP/1.1" 404
371 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:40 +0200] "GET //pma/index.php HTTP/1.1" 404 363
"-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:40 +0200] "GET //web/phpMyAdmin/index.php HTTP/1.1"
404 374 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:40 +0200] "GET //xampp/phpmyadmin/index.php
HTTP/1.1" 404 376 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:44 +0200] "GET //php-my-admin/index.php HTTP/1.1"
404 372 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:44 +0200] "GET //websql/index.php HTTP/1.1" 404 366
"-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:44 +0200] "GET //phpmyadmin/index.php HTTP/1.1" 404
370 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:45 +0200] "GET //phpMyAdmin/index.php HTTP/1.1" 404
370 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:45 +0200] "GET //phpMyAdmin-2/index.php HTTP/1.1"
404 372 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:45 +0200] "GET //php-my-admin/index.php HTTP/1.1"
404 372 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:46 +0200] "GET //phpMyAdmin-2.2.3/index.php
HTTP/1.1" 404 376 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:46 +0200] "GET //phpMyAdmin-2.2.6/index.php
HTTP/1.1" 404 376 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:46 +0200] "GET //phpMyAdmin-2.5.1/index.php
HTTP/1.1" 404 376 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:47 +0200] "GET //phpMyAdmin-2.5.4/index.php
HTTP/1.1" 404 376 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:47 +0200] "GET //phpMyAdmin-2.5.5-rc1/index.php
HTTP/1.1" 404 380 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:47 +0200] "GET //phpMyAdmin-2.5.5-rc2/index.php
HTTP/1.1" 404 380 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:47 +0200] "GET //phpMyAdmin-2.5.5/index.php
HTTP/1.1" 404 376 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:48 +0200] "GET //phpMyAdmin-2.5.5-pl1/index.php
HTTP/1.1" 404 380 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:48 +0200] "GET //phpMyAdmin-2.5.6-rc1/index.php
HTTP/1.1" 404 380 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:48 +0200] "GET //phpMyAdmin-2.5.6-rc2/index.php
HTTP/1.1" 404 380 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:49 +0200] "GET //phpMyAdmin-2.5.6/index.php
HTTP/1.1" 404 376 "-" "-"
209.212.145.91 - - [03/Apr/2013:00:52:49 +0200] "GET //phpMyAdmin-2.5.7/index.php
HTTP/1.1" 404 376 "-" "-"
....
91.121.172.164 - - [03/Apr/2013:08:19:50 +0200] "GET / HTTP/1.1" 200 45 "-" "Mozilla/5.0
(Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:08:19:50 +0200] "GET /robots.txt HTTP/1.1" 404 360 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:08:19:50 +0200] "GET /admin HTTP/1.1" 404 355 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:08:19:51 +0200] "GET /owa HTTP/1.1" 404 353 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:08:19:51 +0200] "GET /console HTTP/1.1" 404 357 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:08:19:51 +0200] "GET /manager HTTP/1.1" 404 357 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:08:19:51 +0200] "GET /old HTTP/1.1" 404 353 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:08:19:51 +0200] "GET /backup HTTP/1.1" 404 356 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
...
91.121.172.164 - - [03/Apr/2013:11:17:48 +0200] "GET / HTTP/1.1" 200 45 "-" "Mozilla/5.0
(Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:11:17:48 +0200] "GET /robots.txt HTTP/1.1" 404 360 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:11:17:48 +0200] "GET /admin HTTP/1.1" 404 355 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:11:17:48 +0200] "GET /owa HTTP/1.1" 404 353 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:11:17:48 +0200] "GET /console HTTP/1.1" 404 357 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:11:17:49 +0200] "GET /manager HTTP/1.1" 404 357 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:11:17:49 +0200] "GET /old HTTP/1.1" 404 353 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
91.121.172.164 - - [03/Apr/2013:11:17:49 +0200] "GET /backup HTTP/1.1" 404 356 "-"
"Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)"
...
151.12.11.2 - - [03/Apr/2013:17:20:38 +0200] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1"
400 385 "-" "-"
151.12.11.2 - - [03/Apr/2013:17:24:08 +0200] "GET /admin/main.php HTTP/1.0" 404 364 "-"
"-"
151.12.11.2 - - [03/Apr/2013:17:24:08 +0200] "GET /phpmyadmin/main.php HTTP/1.0" 404 369
"-" "-"
151.12.11.2 - - [03/Apr/2013:17:24:08 +0200] "GET /phpMyAdmin/main.php HTTP/1.0" 404 369
"-" "-"
151.12.11.2 - - [03/Apr/2013:17:24:09 +0200] "GET /db/main.php HTTP/1.0" 404 361 "-"
"-"
151.12.11.2 - - [03/Apr/2013:17:24:09 +0200] "GET /PMA/main.php HTTP/1.0" 404 362 "-"
"-"
151.12.11.2 - - [03/Apr/2013:17:24:09 +0200] "GET /pma/main.php HTTP/1.0" 404 362 "-"
"-"
151.12.11.2 - - [03/Apr/2013:17:24:09 +0200] "GET /admin/main.php HTTP/1.0" 404 364 "-"
"-"
151.12.11.2 - - [03/Apr/2013:17:24:09 +0200] "GET /mysql/main.php HTTP/1.0" 404 364 "-"
"-"
151.12.11.2 - - [03/Apr/2013:17:24:10 +0200] "GET /myadmin/main.php HTTP/1.0" 404 366 "-"
"-"
151.12.11.2 - - [03/Apr/2013:17:24:10 +0200] "GET /phpadmin/main.php HTTP/1.0" 404 367
"-" "-"
151.12.11.2 - - [03/Apr/2013:17:24:10 +0200] "GET /webadmin/main.php HTTP/1.0" 404 367
"-" "-"
...
46.118.129.224 - - [04/Apr/2013:19:28:30 +0200] "GET
/administrator/components/com_kunena/kunena.xml HTTP/1.1" 404 405 "-" "Mozilla/5.0
(Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3"
...
168.61.16.153 - - [04/Apr/2013:22:55:06 +0200] "HEAD /manager/status HTTP/1.1" 404 - "-"
"Java/1.7.0_09"
...
37.15.255.187 - - [10/Apr/2013:04:35:52 +0200] "GET / HTTP/1.1" 200 45 "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:35:53 +0200] "GET /favicon.ico HTTP/1.1" 404 368 "-"
"Mozilla/5.0 (compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:35:53 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:36:50 +0200] "GET / HTTP/1.0" 200 45 "-" "-"
37.15.255.187 - - [10/Apr/2013:04:37:15 +0200] "GET / HTTP/1.1" 200 45 "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:23 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:24 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:24 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:24 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:24 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:25 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:25 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:25 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:25 +0200] "OPTIONS / HTTP/1.1" 200 - "-" "Mozilla/5.0
(compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:37:55 +0200] "GET /.git/HEAD HTTP/1.1" 404 366 "-"
"Mozilla/5.0 (compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
37.15.255.187 - - [10/Apr/2013:04:38:00 +0200] "GET /robots.txt HTTP/1.1" 404 367 "-"
"Mozilla/5.0 (compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
...
50.22.129.2 - - [11/Apr/2013:11:17:23 +0200] "GET /webcalendar/install/index.php HTTP/1.1"
404 379 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:23 +0200] "GET /calendar/install/index.php HTTP/1.1"
404 376 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:24 +0200] "GET /webcal/install/index.php HTTP/1.1" 404
374 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:24 +0200] "GET /cal/install/index.php HTTP/1.1" 404 371
"-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:24 +0200] "GET /install/index.php HTTP/1.1" 404 367 "-"
"libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:25 +0200] "GET /kalender/install/index.php HTTP/1.1"
404 376 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:25 +0200] "GET /schedule/install/index.php HTTP/1.1"
404 376 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:26 +0200] "GET /planen/install/index.php HTTP/1.1" 404
374 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:26 +0200] "GET /zeit/install/index.php HTTP/1.1" 404
372 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:26 +0200] "GET /web/install/index.php HTTP/1.1" 404 371
"-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:27 +0200] "GET /calendario/install/index.php HTTP/1.1"
404 378 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:27 +0200] "GET /time/install/index.php HTTP/1.1" 404
372 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:28 +0200] "GET /events/install/index.php HTTP/1.1" 404
374 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:28 +0200] "GET /event/install/index.php HTTP/1.1" 404
373 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:28 +0200] "GET /veranstaltungen/install/index.php
HTTP/1.1" 404 383 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:29 +0200] "GET /ical/install/index.php HTTP/1.1" 404
372 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:29 +0200] "GET /fbcalendar/install/index.php HTTP/1.1"
404 378 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:30 +0200] "GET /agenda/install/index.php HTTP/1.1" 404
374 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:30 +0200] "GET /menu/install/index.php HTTP/1.1" 404
372 "-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:30 +0200] "GET /new/install/index.php HTTP/1.1" 404 371
"-" "libwww-perl/6.04"
50.22.129.2 - - [11/Apr/2013:11:17:31 +0200] "GET /novo/install/index.php HTTP/1.1" 404
372 "-" "libwww-perl/6.04"
...
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:08 +0200] "GET <title>phpMyAdmin HTTP/1.1" 400 378
"-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:08 +0200] "GET /phpmyadmin/ HTTP/1.1" 404 361 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:08 +0200] "GET /phpMyAdmin/ HTTP/1.1" 404 361 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:08 +0200] "GET /PMA/ HTTP/1.1" 404 354 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:08 +0200] "GET /pma/ HTTP/1.1" 404 354 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:08 +0200] "GET /admin/ HTTP/1.1" 404 356 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:08 +0200] "GET /dbadmin/ HTTP/1.1" 404 358 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:08 +0200] "GET /sql/ HTTP/1.1" 404 354 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:08 +0200] "GET /mysql/ HTTP/1.1" 404 356 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:09 +0200] "GET /myadmin/ HTTP/1.1" 404 358 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:09 +0200] "GET /phpmyadmin2/ HTTP/1.1" 404 362 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:09 +0200] "GET /phpMyAdmin2/ HTTP/1.1" 404 362 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:09 +0200] "GET /phpMyAdmin-2/ HTTP/1.1" 404 363 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:09 +0200] "GET /php-my-admin/ HTTP/1.1" 404 363 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:09 +0200] "GET /sqlmanager/ HTTP/1.1" 404 361 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:09 +0200] "GET /mysqlmanager/ HTTP/1.1" 404 363 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:09 +0200] "GET /p/m/a/ HTTP/1.1" 404 356 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:10 +0200] "GET /php-myadmin/ HTTP/1.1" 404 362 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:10 +0200] "GET /phpmy-admin/ HTTP/1.1" 404 362 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:10 +0200] "GET /webadmin/ HTTP/1.1" 404 359 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:10 +0200] "GET /sqlweb/ HTTP/1.1" 404 357 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:10 +0200] "GET /websql/ HTTP/1.1" 404 357 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:10 +0200] "GET /webdb/ HTTP/1.1" 404 356 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:10 +0200] "GET /mysqladmin/ HTTP/1.1" 404 361 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
aa.bbb.ccc.ddd - - [12/Apr/2013:12:44:10 +0200] "GET /mysql-admin/ HTTP/1.1" 404 362 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
...
(incidentally, this last looked very much like coming from someone's infected mail server.
That's why I scrambled the Ip address. I also let the host admins know about it.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org