tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Thu, 18 Apr 2013 16:26:50 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message