You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Howard W. Smith, Jr." <sm...@gmail.com> on 2013/04/10 13:32:09 UTC
Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Every now and then, I like to review localhost_access_log files, just to
see who might be trying to access my web app, running on TomEE 1.6.0
snapshot (Tomcat 7.0.39). So, a few minutes ago, I saw the following in the
log:
113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
HTTP/1.0" 404 -
This is an unfamiliar ip address to me, and I have already prepared the
app/tomcat for these type of attacks. How? by removing any/all tomee/tomcat
(manager/web) apps. I did that some time ago, when I first migrated from
glassfish to tomee/tomcat, and that was the best/easiest way I knew how to
prevent these type of attacks.
Can someone please give/share some background on this type of attack?
Thanks,
Howard
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Kolinko wrote:
> 2013/4/10 Howard W. Smith, Jr. <sm...@gmail.com>:
>> Every now and then, I like to review localhost_access_log files, just to
>> see who might be trying to access my web app, running on TomEE 1.6.0
>> snapshot (Tomcat 7.0.39). So, a few minutes ago, I saw the following in the
>> log:
>>
>> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
>> HTTP/1.0" 404 -
>>
>
> By the way
> 1) I think just feeding the default ROOT webapp to a Google bot or
> Baidu will result in such requests coming from search bots for
> awhile. That is because ROOT/index.jsp has links to the Manager
> application.
>
> It looks like a good idea to add "noindex,nofollow" meta element to
> that page, or at least to those links.
>
> 2) Bots may send HEAD requests to check whether the page has been
> created or modified since the last scan. A HEAD request is usually
> served faster than a GET one.
But a HEAD request will also result in a 404 response if the requested resource does not
exist. And the bot will have to wait for that one too.
>
> Regarding a new feature of introducing a delay,
> 3) If you add a response delay it means that you are tying resources
> of your server for that period of time. In the worst case you will be
> tying a request processing thread.
> Though it may be that your load is low and you have some free
> resources for that.
>
> Usually I would prefer to answer faster to to be ready to serve the
> next request from a valid user.
>
Konstantin,
thanks for your response.
About tying up a valuable Tomcat thread, see Chuck's response (or mine, if you like to
read more lines).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/4/10 Howard W. Smith, Jr. <sm...@gmail.com>:
> Every now and then, I like to review localhost_access_log files, just to
> see who might be trying to access my web app, running on TomEE 1.6.0
> snapshot (Tomcat 7.0.39). So, a few minutes ago, I saw the following in the
> log:
>
> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
>
By the way
1) I think just feeding the default ROOT webapp to a Google bot or
Baidu will result in such requests coming from search bots for
awhile. That is because ROOT/index.jsp has links to the Manager
application.
It looks like a good idea to add "noindex,nofollow" meta element to
that page, or at least to those links.
2) Bots may send HEAD requests to check whether the page has been
created or modified since the last scan. A HEAD request is usually
served faster than a GET one.
Regarding a new feature of introducing a delay,
3) If you add a response delay it means that you are tying resources
of your server for that period of time. In the worst case you will be
tying a request processing thread.
Though it may be that your load is low and you have some free
resources for that.
Usually I would prefer to answer faster to to be ready to serve the
next request from a valid user.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Apr 13, 2013 3:55 PM, "Mark Eggers" <it...@yahoo.com> wrote:
>
> On 4/10/2013 5:47 PM, Howard W. Smith, Jr. wrote:
>>
>> Some legit 404s definitely show up for every enduser that access the
webapp
>> via mobile device, because PrimeFaces has 2 files that no longer exist in
>> the JAR file, and I just reported this in their Issue Tracker.
>>
>> 127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET
>> /apple-touch-icon-precomposed.png HTTP/1.1" 404 -
>> 127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET /apple-touch-icon.png
>> HTTP/1.1" 404 -
>>
>> Also, netbeans IDE and start-stop-tomcat implementation results in the
>> following:
>>
>> 127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD
>> /netbeans-tomcat-status-test HTTP/1.1" 404 -
>> 127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD
>> /netbeans-tomcat-status-test HTTP/1.1" 404 -
>> 127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD
>> /netbeans-tomcat-status-test HTTP/1.1" 404 -
>>
>
> A little off-topic here . . .
>
> This is analogous to the favicon.ico file. Mobile devices (Android and
iOS at least) use these so you can create a bookmark on the desktop (or
whatever the mobile devices call it).
>
> So, make a nice icon (png, 100x100) for your site. Then users can
bookmark the site and put the link on the desktop.
>
Correct. I learned about this a few days ago, when I posted this as a
primefaces issue in primefaces mobile forum and issue tracker, a few days
ago. Someone responded with some URLs to blogs that discuss this. Now, I
know how to handle this and now I know this is not an issue. :-)
> And yes, NetBeans seems to do that in order to figure out when Tomcat
starts up (even if it's already started). It also issues a start command to
the manager application for your web application (even if autoDeploy=true).
>
> . . . . just my two cents.
> /mde/
>
Thanks!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Mark Eggers <it...@yahoo.com>.
On 4/10/2013 5:47 PM, Howard W. Smith, Jr. wrote:
> Some legit 404s definitely show up for every enduser that access the webapp
> via mobile device, because PrimeFaces has 2 files that no longer exist in
> the JAR file, and I just reported this in their Issue Tracker.
>
> 127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET
> /apple-touch-icon-precomposed.png HTTP/1.1" 404 -
> 127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET /apple-touch-icon.png
> HTTP/1.1" 404 -
>
> Also, netbeans IDE and start-stop-tomcat implementation results in the
> following:
>
> 127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD
> /netbeans-tomcat-status-test HTTP/1.1" 404 -
> 127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD
> /netbeans-tomcat-status-test HTTP/1.1" 404 -
> 127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD
> /netbeans-tomcat-status-test HTTP/1.1" 404 -
>
A little off-topic here . . .
This is analogous to the favicon.ico file. Mobile devices (Android and
iOS at least) use these so you can create a bookmark on the desktop (or
whatever the mobile devices call it).
So, make a nice icon (png, 100x100) for your site. Then users can
bookmark the site and put the link on the desktop.
And yes, NetBeans seems to do that in order to figure out when Tomcat
starts up (even if it's already started). It also issues a start command
to the manager application for your web application (even if
autoDeploy=true).
. . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 10, 2013 at 4:32 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Howard,
>
> On 4/10/13 1:23 PM, Howard W. Smith, Jr. wrote:
> >> As others have mentioned, I wouldn't give this too much thought:
> >> someone is scanning you for vulnerabilities. I'll bet if you log
> >> the full headers of those requests, you'll see something like
> >> "admin/admin" or "scott/tiger" in the WWW-Authenticate headers.
> >> Just someone knocking on your door to see if the latch works. Can
> >> you mostly ignore them.
> >>
> >
> > Nice analogy, and definitely, I can ignore and have been ignoring
> > them. Just thought I might ask the list, and see if my current
> > securing-tomcat approach is common and/or sufficient. :)
>
> There is a free utility for *NIX systems called fail2ban which can be
> configured to scan log files (and other data sources) for certain
> patterns. You can do things like say "if we get 10 or more failed
> requests from a certain IP address, update the firewall to drop all
> packets from that IP for a while". I wonder if there exists something
> like that for the Windows world.
>
Don't know if there exists anything like that in Windows world.
>
> You can have fail2ban watch things like failed attempts to login to
> ssh, and I think you could probably do something like that with 404
> responses from your web-service logs, too. Of course, you have to make
> sure that your site doesn't have too many "legit" 404s on it that
> people will trigger this rather draconian response, but you can always
> un-ban them fairly easily :)
>
Some legit 404s definitely show up for every enduser that access the webapp
via mobile device, because PrimeFaces has 2 files that no longer exist in
the JAR file, and I just reported this in their Issue Tracker.
127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET
/apple-touch-icon-precomposed.png HTTP/1.1" 404 -
127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET /apple-touch-icon.png
HTTP/1.1" 404 -
Also, netbeans IDE and start-stop-tomcat implementation results in the
following:
127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD
/netbeans-tomcat-status-test HTTP/1.1" 404 -
127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD
/netbeans-tomcat-status-test HTTP/1.1" 404 -
127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD
/netbeans-tomcat-status-test HTTP/1.1" 404 -
Ummm, I replaced my IP address with localhost address above. :)
> >> On the other hand, I wonder why you are seeing these requests in
> >> your Tomcat logs, since you:
> >>
> >>> I mentioned earlier that I removed the manager apps. The server
> >>> is behind a firewall router, port 8080 is port-forwarded from
> >>> the router to the server, the web app has login page (and
> >>> login servlet/filter in place), but SSL is not configured just
> >>> yet. That is definitely on my to-do list to complete, ASAP, as
> >>> the CEO has given me the go-ahead.
> >>
> >> Are you not filtering by URL anywhere?
> >
> >
> > Good question. not filtering any IP addresses at the firewall
> > level, and really don't have a need unless some
> > really-serious-harmful infiltration occurred. Looking at the
> > localhost access logs, I am able to develop a reliable list of IP
> > addresses to add to a 'safe list', but i have not found that
> > necessary to do...just yet.
>
> If you find that you are getting lots of penetration attempts from a
> small set of IP addresses, just firewall them out.
>
Our organization just went with Cox@Business internet connection, and the
tech guy connected to our cable modem or network (at point of
installation), and informed us that we need to configure the router to not
respond to PING, so I did that, and honestly, the only hack attempts that I
'see' are the hack attempts against port 8080. I would assume that they do
the same on port 80, too. Right?
It's interesting that apache httpd port 80 seem to not show/reveal hack
attempts against port 80...as mentioned by Esmond Pitt in his response to
this thread.
I would only firewall-out/block IP addresses, if I seen multiple/repeated
attempts from the same IP address(es), but how many 'bots' exhibit the same
IP address. I definitely don't know much about 'bots' implementation, but I
would assume bots derive random-generated IP addresses. right?
> >> If you don't expect anyone in Asia to be legitimately accessing
> >> your site, you could do something drastic like close your site to
> >> some CIDR pattern that blocks all that stuff.
> >
> > Interesting. Earlier, Chuck mentioned, "GIYF", and agreed on that
> > point, and that would be my first step, if I needed to learn a bit
> > more about CIDR. :)
>
> 192.168.1.223/17
>
> It allows you to specify a bit pattern and bitmask at the same time.
>
Interesting.
>
> - -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/
>
> iQIcBAEBCAAGBQJRZcx2AAoJEBzwKT+lPKRYIaIP/iuhaVAkSUzpT17vIcPYipow
> SIHqIo291znp7kedMDsg3Md8uPw3hfREM/aRmbcFmFYIMPbja0YcM3AukeLHNRxu
> wY+YhzFxCkaBP+blxCheQXHGWV2YM3hWlPigHhmhHvx/e382mGBqJl/YhasdVh3b
> vE1gmbpIPbhr2lUjX+Kp8k27Pf1fNFIgUEh0rqlGZ0F1WxNizr9uGnk/qQyXwSd5
> 6AjEiWufODbzSEOBTX1DkL8ixaH5tisHOBicsesuDt0dZaW2JfoDoqJn+Qa+lEsa
> c8O2DHw1hlXT+T7IEjpVcvC36HnfC5uUHBAFiXyqQJuJhbtgUJRuR69DHCUDKzx8
> +4HULQ5t40BKP/xw4eFtiObEH2vkwUEmLXwe74mcWWrb5BzyuZurJygqFyWFlIwV
> KLMIHrqsgDdxImFqJBbE627xnANQVa6C+nkAjSs9sqqJC1InL/rbuE0ZFccdEjIz
> JfUR4/yXlySzaVxBdOHdFD7cOTf0AR/hLnTf5aiASHxL8eV7y/n07tmda7+KJ4HK
> QCP0LvXu/cP2atoY40qHkn9kCIjaEZgj0dnBtgZHw0nu7YsTkMAs5fBsUXU/Fb35
> rPNcHwKJWwdc4J0RXsdXOTbYkeVZNxMrDETxb37hZva3UeNrs8dWXgfVe1SGwhWY
> hug9wCMjxUKNhh+3lSly
> =TBia
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Howard,
On 4/10/13 1:23 PM, Howard W. Smith, Jr. wrote:
>> As others have mentioned, I wouldn't give this too much thought:
>> someone is scanning you for vulnerabilities. I'll bet if you log
>> the full headers of those requests, you'll see something like
>> "admin/admin" or "scott/tiger" in the WWW-Authenticate headers.
>> Just someone knocking on your door to see if the latch works. Can
>> you mostly ignore them.
>>
>
> Nice analogy, and definitely, I can ignore and have been ignoring
> them. Just thought I might ask the list, and see if my current
> securing-tomcat approach is common and/or sufficient. :)
There is a free utility for *NIX systems called fail2ban which can be
configured to scan log files (and other data sources) for certain
patterns. You can do things like say "if we get 10 or more failed
requests from a certain IP address, update the firewall to drop all
packets from that IP for a while". I wonder if there exists something
like that for the Windows world.
You can have fail2ban watch things like failed attempts to login to
ssh, and I think you could probably do something like that with 404
responses from your web-service logs, too. Of course, you have to make
sure that your site doesn't have too many "legit" 404s on it that
people will trigger this rather draconian response, but you can always
un-ban them fairly easily :)
>> On the other hand, I wonder why you are seeing these requests in
>> your Tomcat logs, since you:
>>
>>> I mentioned earlier that I removed the manager apps. The server
>>> is behind a firewall router, port 8080 is port-forwarded from
>>> the router to the server, the web app has login page (and
>>> login servlet/filter in place), but SSL is not configured just
>>> yet. That is definitely on my to-do list to complete, ASAP, as
>>> the CEO has given me the go-ahead.
>>
>> Are you not filtering by URL anywhere?
>
>
> Good question. not filtering any IP addresses at the firewall
> level, and really don't have a need unless some
> really-serious-harmful infiltration occurred. Looking at the
> localhost access logs, I am able to develop a reliable list of IP
> addresses to add to a 'safe list', but i have not found that
> necessary to do...just yet.
If you find that you are getting lots of penetration attempts from a
small set of IP addresses, just firewall them out.
>> If you don't expect anyone in Asia to be legitimately accessing
>> your site, you could do something drastic like close your site to
>> some CIDR pattern that blocks all that stuff.
>
> Interesting. Earlier, Chuck mentioned, "GIYF", and agreed on that
> point, and that would be my first step, if I needed to learn a bit
> more about CIDR. :)
192.168.1.223/17
It allows you to specify a bit pattern and bitmask at the same time.
- -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/
iQIcBAEBCAAGBQJRZcx2AAoJEBzwKT+lPKRYIaIP/iuhaVAkSUzpT17vIcPYipow
SIHqIo291znp7kedMDsg3Md8uPw3hfREM/aRmbcFmFYIMPbja0YcM3AukeLHNRxu
wY+YhzFxCkaBP+blxCheQXHGWV2YM3hWlPigHhmhHvx/e382mGBqJl/YhasdVh3b
vE1gmbpIPbhr2lUjX+Kp8k27Pf1fNFIgUEh0rqlGZ0F1WxNizr9uGnk/qQyXwSd5
6AjEiWufODbzSEOBTX1DkL8ixaH5tisHOBicsesuDt0dZaW2JfoDoqJn+Qa+lEsa
c8O2DHw1hlXT+T7IEjpVcvC36HnfC5uUHBAFiXyqQJuJhbtgUJRuR69DHCUDKzx8
+4HULQ5t40BKP/xw4eFtiObEH2vkwUEmLXwe74mcWWrb5BzyuZurJygqFyWFlIwV
KLMIHrqsgDdxImFqJBbE627xnANQVa6C+nkAjSs9sqqJC1InL/rbuE0ZFccdEjIz
JfUR4/yXlySzaVxBdOHdFD7cOTf0AR/hLnTf5aiASHxL8eV7y/n07tmda7+KJ4HK
QCP0LvXu/cP2atoY40qHkn9kCIjaEZgj0dnBtgZHw0nu7YsTkMAs5fBsUXU/Fb35
rPNcHwKJWwdc4J0RXsdXOTbYkeVZNxMrDETxb37hZva3UeNrs8dWXgfVe1SGwhWY
hug9wCMjxUKNhh+3lSly
=TBia
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Chris,
> As others have mentioned, I wouldn't give this too much thought:
> someone is scanning you for vulnerabilities. I'll bet if you log the
> full headers of those requests, you'll see something like
> "admin/admin" or "scott/tiger" in the WWW-Authenticate headers. Just
> someone knocking on your door to see if the latch works. Can you
> mostly ignore them.
>
Nice analogy, and definitely, I can ignore and have been ignoring them.
Just thought I might ask the list, and see if my current securing-tomcat
approach is common and/or sufficient. :)
>
> On the other hand, I wonder why you are seeing these requests in your
> Tomcat logs, since you:
>
> > I mentioned earlier that I removed the manager apps. The server is
> > behind a firewall router, port 8080 is port-forwarded from the
> > router to the server, the web app has login page (and login
> > servlet/filter in place), but SSL is not configured just yet. That
> > is definitely on my to-do list to complete, ASAP, as the CEO has
> > given me the go-ahead.
>
> Are you not filtering by URL anywhere?
Good question. not filtering any IP addresses at the firewall level, and
really don't have a need unless some really-serious-harmful infiltration
occurred. Looking at the localhost access logs, I am able to develop a
reliable list of IP addresses to add to a 'safe list', but i have not found
that necessary to do...just yet.
>
> If you don't expect anyone in Asia to be legitimately accessing your
> site, you could do something drastic like close your site to some CIDR
> pattern that blocks all that stuff.
>
Interesting. Earlier, Chuck mentioned, "GIYF", and agreed on that point,
and that would be my first step, if I needed to learn a bit more about
CIDR. :)
>
> On the other hand, we actually have some customers in China and blocking
> them is neither acceptable nor necessary.
Agreed, and I am satisfied with the current configuration I have in place
to 'block China'...and others. :)
> It's just log noise.
>
log noise = details, and i love details, and I'm loving my tomcat (tomee)
experience. Learning a lot more 'here', on a higher level, while using
tomcat/tomee. I was amazed, when I saw the logs folder, and the different
log files available, by default. I didn't have all that when I was using
glassfish. Okay okay, NetBeans/Glassfish (reference implementation) helped
me learn Java EE and JSF, and helped me develop Java, java EE, and JSF
(web) applications. Now, tomcat/tomee is allowing me to have an app that
performs well, etc..., and life, deploying app-or-software-updates, is much
more endurable and no need of any 'patience', since tomcat starts sooo
fast. Plenty of good to say about tomcat/tomee...i'm getting off-topic
here. haha :)
Thanks,
Howard
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Howard,
On 4/10/13 7:32 AM, Howard W. Smith, Jr. wrote:
> Every now and then, I like to review localhost_access_log files,
> just to see who might be trying to access my web app, running on
> TomEE 1.6.0 snapshot (Tomcat 7.0.39). So, a few minutes ago, I saw
> the following in the log:
>
> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
>
> This is an unfamiliar ip address to me, and I have already prepared
> the app/tomcat for these type of attacks. How? by removing any/all
> tomee/tomcat (manager/web) apps. I did that some time ago, when I
> first migrated from glassfish to tomee/tomcat, and that was the
> best/easiest way I knew how to prevent these type of attacks.
>
> Can someone please give/share some background on this type of
> attack?
As others have mentioned, I wouldn't give this too much thought:
someone is scanning you for vulnerabilities. I'll bet if you log the
full headers of those requests, you'll see something like
"admin/admin" or "scott/tiger" in the WWW-Authenticate headers. Just
someone knocking on your door to see if the latch works. Can you
mostly ignore them.
On the other hand, I wonder why you are seeing these requests in your
Tomcat logs, since you:
> I mentioned earlier that I removed the manager apps. The server is
> behind a firewall router, port 8080 is port-forwarded from the
> router to the server, the web app has login page (and login
> servlet/filter in place), but SSL is not configured just yet. That
> is definitely on my to-do list to complete, ASAP, as the CEO has
> given me the go-ahead.
Are you not filtering by URL anywhere? I guess it's uncommon to do
content-filtering at the firewall level (unless you are talking about
porno filters or whatever) but there are ways to block these requests
before they even get to your web server.
If you don't expect anyone in Asia to be legitimately accessing your
site, you could do something drastic like close your site to some CIDR
pattern that blocks all that stuff.
Most of the traffic we get from China is of the type you describe:
requests for /manager/html or various commonly poorly-configured PHP
or IIS apps, etc. None of them make any difference to us because they
will all fail. On the other hand, we actually have some customers in
China and blocking them is neither acceptable nor necessary. It's just
log noise.
- -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/
iQIcBAEBCAAGBQJRZZrYAAoJEBzwKT+lPKRYpS8P/AlNfy7I60ixXNleF3IJGD62
Ey/jRyfOgPnEfS4J/rt8007qhpxTXeuXqmY20nrWr+dIsQVsllXTrhasKqsQR6Ba
CAlSkTUHRFMFjHnFmH/uzGCS/LB0iFqdxWf/2HrGJevinPt10J1O5j1TsmmIIqiK
d6wNpbAh0+jNgTsgKduEvJxNo+7QDWs3qJuAdUFDBeQCGIofpSvfzj68W1mY2kvS
iuZ24MWW+wuU3DgNjAWmnctcC8CDnXHB9YwNoQM5jKzaldelukQ3CFzBCEDa7utp
jVYFAGI16OOjwqV/fbzTcVAqWp4AOjcFhv2u9vAPkJXSZujkbD/9x+5mNwqts6LX
5MoqlFnAatGgOEKKQMa5IWhXlo+kGjR+kIbdPeklTnDSRUpKplpo/NSVLv3TvezZ
t+lz1Ya07/03mMTbiepHTR3PjeXXQP1VNSjdVyyNLirgdmW7pfcXq+uTzw/dJHyQ
WzWtbKz2U1B3kySWx8mNaK5i2T2hr8oN8yCtfoGMlGKJujvUjU9vgVRjRZR4cfCk
BRKhZsJ3nENoixg8FPZNA6jXMI6j8YW/8ZEJYVLe9gL0gHHriZu1xAOYNXNcmpsI
00OffGtR7Cao0Q7kwgVnfPxdUJ/I7PUsJWgFBEzxZ+dUOZUqYI6sik+MsHVlhVoh
gC43QxSpD7NMnqhdC7bU
=WYC0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Esmond,
On 4/11/13 8:43 PM, Esmond Pitt wrote:
> I referred to the OpenLDAP lockout mechanism, which is not at all
> primitive.
How does OpenLDAP do better than Tomcat? If I make repeated (failed)
login attempts against a single user, can I cause them to be
locked-out? DOS. Does OpenLDAP track the IP address(es) of the
authentication attempts? (Tomcat would have to furnish that
information via LDAP, which I don't believe it does). If it does cache
them, I can hit you from many different IP addresses. D/DOS. If it's
got a limited cache, I can game the cache by making of attempts, get
locked-out, then purge myself from your cache by hitting you with
other requests.
Tomcat does an adequate job of mitigating casual break-in attempts.
Really good protection is difficult and often still not sufficient
because the bad guys always have the advantage.
>> Would you be willing to review the Tomcat documentation on
>> "securing Tomcat" and make a few comments? It could always use
>> some additional tips:
>
> Sure, will do.
Great!
- -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/
iQIcBAEBCAAGBQJRazRqAAoJEBzwKT+lPKRYRzIQAIJddWW2I/B5iYu9O2gx8oIQ
EJj8gR6ZptF3E6GqOwJJPQ3YtE5dtocyRNLKc3as6Iw1slp1o/N9LZvxkuGZ5AJY
iFzVUowRtGusf7xFcIT6Ld50MbK1fQkfHnBCi5HCawoQ+gaIcscqLHPBMjBqutjA
dLu+7lIvCHpdeJ6y1EK6mtJXtgGvvi1iDOWSLHWIcLzvWaS8E83K/ydA3SRc2SAY
C2q/ac7p5Luy74AGPkAyxP2FDjFBAtRFKmusUR9MJKEOFuz8eVo79Mq5nrrAfI0g
h63ItO3n8jkqe0wzSC1ZBsaggcEMulAU5N3g5VvBWImQpQ2pL8IYAVfOK8wrqK27
Z1OqwgeY4gKdv/1NtAQg0sQ3i8AZ3ibzd+s3+dd8udj5nD9AmxtN2bC1AWnO37I3
YJp3MePLPxHemDS9wq75SMj+gq591xWXcCw3H1SgtCX8nKAkyZJraBMcDhrP3Qyd
EcAAszdpAILvfLmzHl6AjQ4v6gOTYxxBIuv4PaIOx/UM3wYL/YUtovmGiU4AeL6V
qVZrIa/CkM70LzvaGdbMSNXlT6pS79Bpfg1ER0jMuRGdECay31yGqn0F6lRR+pQn
akqQNj3i1NCOJM3lc804g6P4jP6JohoUBGOIF7i7QA7ikqseA3Ndp/R8dZ5jhIWu
ursp7X5nazb/05Ls91B5
=vf2o
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Posted by Esmond Pitt <es...@bigpond.com>.
> You would have had to intentionally enable the "default" password.
I had clearly done that.
> The attacker installed a viral servlet application that killed the
> server completely, we had to rebuild it.
I -- like most people I would guess -- don't run under a SecurityManager,
but doing so can significantly limit the damage that a rogue webapp can do.
Thanks, I don't think that's feasible given our webapps.
> Did you also remove manager webapp access through httpd? Otherwise, this
doesn't actually do anything to help.
No I didn't, I *access-controlled it,* as I went on to describe.
> +2 -- both good ideas: central access control (LDAP) and enabling
> lockout mechanism. Note that Tomcat's lockout mechanism is fairly
primitive and easy to game.
I referred to the OpenLDAP lockout mechanism, which is not at all primitive.
> Would you be willing to review the Tomcat documentation on "securing
Tomcat" and make a few comments? It could always use some additional tips:
Sure, will do.
http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html
http://wiki.apache.org/tomcat/FAQ/Security
You can sign-up for the wiki yourself and make any changes you want.
If you want to modify the "official" documentation, create a Bugzilla
enhancement request and (please!) include a patch. I'm sure it will go right
in.
Thanks,
- -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/
iQIcBAEBCAAGBQJRZx7AAAoJEBzwKT+lPKRY+3MP/3c8kZZU43cMaxkXTi/ELXha
Hv6rAeGz4nnpMNn2C002cTRgZ39vomUXYdsLMnNIshn05JDVIZmLLoUXk6UzY9go
uH0QdAubBxhvwC/CWeLjUuSjy/Ei4vKeB7xJNw/FQ2xXEt47FWv36e0vgxOyluX+
gbkB3KQlN6PXtQENGvkOGT5oWLK9M7WUydGSWq9lXR+akwWeL3jWRAlLl6bHYybQ
n70c5wq/rJbEj+k9yCHsMZvPabYs5ejsz6wHvvw4Emrxcp4LVVjCuY2Z87Yhdtb4
B43tF48be9GUZCXDvtIjiS5phHMhpqyJakHuZ7GSvzDIeuiNZ96XuoDkIG1bwWjf
Z5SMCSjkSPqDKJ1cXcd8AaSYgI2C3KQnuFrbTD7bVqQHOeq7RJZp3+xE0IUNPl+V
H2PNpUfXD9BDbPiiDt8bcgvcrImejW0RDumQ2fwbTVvt4OaybVsMUsVFW8lUtw3A
YhvFn/WCEdR8VaY9PkqYm84BVMsQJBbBdb5clYiAtVQRky1NPS+hcIihnf85DkNU
vr6rv/oK0aMXAamwUagmRe5OjTHuHczERPYgEUMpppnlXuNV1mLxBib8+HInGg3/
Y5i28tTd7fS5uo7/CZv+9uEZdDUO7utWGT0W+gBaIkh35/yZI5a1l5wi0szYduQe
t3nftQXUTCYtK1QNwKND
=3s6Q
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Mark Eggers <it...@yahoo.com>.
On 4/15/2013 10:15 AM, André Warnier wrote:
> Neven Cvetkovic wrote:
>> How about creating a fake manager application :)))
>>
>> That takes X minutes/seconds to get back a 404 ;)))
>>
>
> Just for the sake of the discussion :
> - a fake manager application would apply to just the /manager webapp,
> not to other potential hacking targets, no ? (or you would have to "map"
> it to any potential hacking URL, which may be inconvenient). Also,
> you'd have to duplicate this webapp in any configured <Host>.
> - the fact that it is a genuine webapp would mean that during the delay
> before the 404 response, at least one tomcat thread remains blocked
> executing that application, for each such request. I was thinking more
> in the direction of off-loading such 404 responses to some specialised
> lightweight thread, using as little resources as possible. It wouldn't
> really matter if there is a queue of such responses waiting to happen,
> as they just delay the eventual response to the (miscreant) client(s).
>
> More ideas ?
>
> P.S. I'd love to see this as a standard Tomcat feature, because it would
> mean that within a certain time period, thousands and thousands of
> Tomcat servers on the Internet would become annoying for these hacking
> programs. If it was a webapp that everyone has to deploy on individual
> tomcat servers optionally, it would be much less effective, I think.
>
> Of course at the moment I am just fishing here for potential negative
> side-effects.
>
> Provided the idea makes sense however, I believe that I would also post
> it on the Apache httpd list. If it was adopted there also somehow, that
> could have quite a global impact.
>
>
> One potential negative side-effect that I can see, is on one of my own
> programs (or similar ones) : for some customers, I created a "URL
> checker" program, which goes through their databases looking for
> third-party links, and gives them a list of the ones that are not
> working (so that they can correct their data). Of course if all
> webservers on the web implemented my idea, then it would take much
> longer for this genuine utility program to run, because it would
> experience an extra delay for each incorrect URL (in case the host is
> correct, but the URL on that server is not).
> I'm also quite sure that Google won't really like the idea..
Google mod_security honeypot for ideas similar to this.
Couple that with a mod_security exec to add IP addresses to firewalls or
iptables, and I think you have a real chance at being annoying to many
script-driven attacks.
The cracking / botnet tools used today are really quite sophisticated.
Here's an article touching the edge of what's going on:
http://arstechnica.com/security/2013/04/a-beginners-guide-to-building-botnets-with-little-assembly-required/
Fun and games.
. . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
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.
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.
For example, the probability is high that the bot pauses between URLs, so that as you say
it will not be locked-out or detected by some kinds of tools.
If it is smart, it could use the pauses between scans on this server, to scan several
other ones at the same time, in an interleaved fashion, so that on none of the scanned
servers it will be issuing more than 3-4 requests per second, but in total it will be
issuing many more.
Well, no matter how you put this, if some relatively small proportion of these servers
delay their 404 responses, the bot will still experience a dramatic slowdown in scanning
any given number of URLs on any given number of servers.
Unless the bot is really smart enough to detect in advance that this server is going to
artificially slow down its 404 responses, and in consequence avoids scanning it, I do not
see how it could possibly avoid this slowdown, if scanning URLs is what it does.
So, there are 2 possibilities :
- if the bot is not so smart and scans nevertheless, then within any given period of time,
it will be able to scan only a small fraction of the URLs that it was planning to scan. In
which case the WWW at large benefits.
- if the bot is so smart and avoids scanning my server, then the WWW at large does not
benefit, but my server does.
Please, prove to me that I am wrong. It would at least save me the energy to continue
trying to convince people to try this out.
Access log sample :
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 "-" "-"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRdaj2AAoJEBzwKT+lPKRY/GYP/2N0gjRMkbwiHJBWtRQQUulG
h4+/c5hGJLUIGx6FZuxQ9VYEz36bU65PecmMSXsxTx1fjkiVDUCb8j4BtBlZrxX8
rWIe8e/GcPaG0XLKBfzq47tFuIwP5F93faSLNQg8BDR3Db2kgpPj6DGfq1XO4r1a
km8GevkCWtCsoSXdYcCyTZcZFZ4YtlJ2gUM7UvTDL8f1Hm+AwTFOuXUXark2Zcsg
d2Gz2i7b49Qtr4on9e+iaNLI87NdyOiKBUOK8qM3suDY1+431cHEhPdfNMCtTcKI
3PEf7qZJaM6DqgjOwuwJGJxgNNPiwyfjYusIfYNHTuC5rnUFHpHW4XhbEghsM+Wi
qKEbAb6JFXo9RGi4ths6h/1EeN76PX3Kjs9cO0ZnOTvEOEsUuI5siKbxFPskqYMS
v4uicF5QmFoVOh1HE7hC2jV1hmpegVGLOmQ+ocpf3ZmDzZPsOkDn9iFtaGBIV51q
FVH6WO3voJ484N6vyFGlUOJy3trSOl+QpzWKRJwPIqcRg4+ugriLSOvFV7PgDley
ICoBZ+VxQwvjtUVe0DsVPLqfpMnslxELg5hDYoAGQh29nhojUzT/l75+hDBLvXt9
WIqD+8oGnpu6p4/8BJTg4fV122m6pPbc/GEn1VvuCwYk0gad1bxeyIvV4UoB6bUm
g+NTExtExQqLKfGsl657
=4chQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
chris derham wrote:
>> But honestly, I am also a bit at a loss now as to how to continue. There is
>> of course no way for me to prove the validity of the scheme by installing it
>> on 31 million (20%) of webservers on the Internet and looking at the
>> resulting bot activity patterns to confirm my suspicions.
>
> Try to enter into contact with Fyodor (http://insecure.org/fyodor/).
> He wrote nmap - an open source scanner. It isn't a botnet, but he
> might have some interesting thoughts on your proposal. I'd be
> interested to hear what he has to say
>
Thanks. Did that.
I do know nmap, just didn't know the author.
Also have a look at "www.abuse.ch". Quite an eye-opener, botnet-wise.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by chris derham <ch...@derham.me.uk>.
> But honestly, I am also a bit at a loss now as to how to continue. There is
> of course no way for me to prove the validity of the scheme by installing it
> on 31 million (20%) of webservers on the Internet and looking at the
> resulting bot activity patterns to confirm my suspicions.
Try to enter into contact with Fyodor (http://insecure.org/fyodor/).
He wrote nmap - an open source scanner. It isn't a botnet, but he
might have some interesting thoughts on your proposal. I'd be
interested to hear what he has to say
HTH
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
chris derham wrote:
>> Let me just summarise my arguments then :
>> 1) These scans are a burden for all webservers, not just for the vulnerable
>> ones. Whether we want to or not, we currently all have to invest resources
>> into countering (or simply responding to) these scans. Obviously, just
>> ignoring them doesn't stop them, and just protecting one's own servers
>> against them doesn't stop them in a general sense.
>> 2) there is a fundamental asymmetry between how bots access a server (and
>> most of the responses that they get), and how "normal" clients access a
>> server : "normal" clients receive mostly non-404 responses, while bots - by
>> the very nature of what they are looking for - receive many 404 responses.
>> So anything that would in some way "penalise" 404 responses with respect to
>> other ones, should impact bots much more than normal clients
>> 3) setting up a bot to perform such a scanning operation has a cost; if the
>> expected benefit does not cover the cost, it makes no sense to do it.
>> Assuming that botmasters are rational, they should stop doing it then. It is
>> debatable what proportion of servers would need to implement this proposal
>> in order for this kind of bot-scanning to become uneconomical in a general
>> sense. What is certain is that, if none do and no better general scheme is
>> found, the scans will continue. It is also fairly certain that if all
>> servers did, this particular type of scan would stop.
>> 4) it is not obvious right now which method bots could use to circumvent
>> this in order to continue scanning HTTP servers for these known potentially
>> vulnerable URLs. I do not discount that these people are smart, and that
>> they could find a way.
>> But so far it would seem that any scheme thought of by people commenting on
>> this idea, have their own costs in some way and do not invalidate the basic
>> idea.
>> 5) if the scheme works, and it does the effect of making this type of
>> server-scanning uneconomical, bot developers will look for other ways to
>> find vulnerable targets.
>> It is just not obvious to me where they would move their focus, HTTP-wise.
>> If their aim is to find vulnerable URLs on webservers, what else can they do
>> but try them ?
>> 6) intuitively, it seems that implementing this would not be very
>> complicated, and that the foreseeable cost per server, in terms of
>> complexity and performance, would be quite low. The burden imposed on
>> normal clients would also seem to be small.
>> Maybe this should be evaluated in terms of a comparison with any other
>> method that could provide some similar benefit at lower costs.
>> 7) once implemented, it would be something which does not require any
>> special skills or and special effort on the part of the vast majority of
>> people that download and install tomcat. Which means that it has a real
>> chance to automatically spread over time to a large proportion of servers.
>> This is quite unlike any other bot-fighting measure that I have seen
>> mentioned so far in this thread.
>> 8) an obvious drawback to this scheme, is that if it works, it would take a
>> long time to show its effects, because
>> a) it would take a long time before a significant proportion of active
>> servers implement the scheme
>> b) even then, it would probably take an even longer time for the bots to
>> adapt their behaviour (the time for the current generation to die out)
>> So in politics, this would be a no-no, and I will probably never get a Nobel
>> prize for it either. Damn. I would welcome any idea to spread this faster
>> and allow me to gain a just recognition for my insights however.
>
> So a miscreant decides that they want to hack into a computer. Like
> most things in computing, they break the task down into smaller more
> manageable tasks. Step 1 to find targets. Easiest step would seem to
> be to enumerate every ip4 address possible, and sent a tcp/ip packet
> to some known ports. If you get a response, its a live IP address. You
> don't need to map every port, just establish if the host is listening
> to the internet. This will allow you to build up a list of live IP
> addresses and feed into step 2
>
> Step 2 fingerprint those IP addresses. To do this, use a scanning
> tool. These send packets to ports of a given IP address, looking at
> the responses. They don't just look for positive responses, they also
> send badly formed/invalid packets. They use many techniques to do
> this. My favorite is the xmas tree packet. The low level TCP protocol
> defines several fields as control fields - the xmas tree packet flags
> all control fields as true. The packet is completely invalid at a TCP
> level, but different os'es will respond differently. The results of
> all of these responses provide a fingerprint, which should provide a
> identification of what os the server is running. Using similar
> techniques it is generally possible to identify the software stack
> running on each port. Sometime there will be 100% confidence in the
> results, sometimes less. Sometimes the software can't tell what the
> software stack on the server is. However the aim of the game is to
> work out which os and which software is running on the port. The
> miscreants are after the low hanging fruit anyway right? So they build
> up a list of IP addresses with software running on each port, and feed
> to step 3
>
> Step 3 If all has gone well in steps 1 and 2, you now you a list of Ip
> addresses with names and versions of os and the server side software
> running, and in some cases patch level. Combine this with any of the
> publicly available exploit databases, and you can cherry pick which of
> the low hanging fruit you wish to attack using known exploits that
> haven't been patched yet.
>
> Step 4 is if you don't have any targets with known exploits, then you
> have to start looking for holes manually. The value varies, but they
> say that there is one exploitable defect per thousand lines of code.
> With this in mind, and an os/server stack/app stack combining to
> contain many millions of lines of code, there should be ample scope
> for finding a hole. Most os'es and app servers are reviewed by
> security experts, and have been battle hardened. Most apps have not.
> Apps seem to be the common weak point, second only to users and weak,
> reused passwords. The scanners are getting better and better each day.
> Some are now capable of detecting SQL injection defects in forms, and
> flagging a site as ripe for targeting.
>
> So coming back to your proposal. My first point is that step 1 uses
> TCP/IP connections, so the probing occurs lower down the stack. Hence
> delaying 404 responses will not stop or affect them. Some of step 2
> can occur just looking for normal headers, or by using malformed
> packets against pages that exist, i.e. will not result in 404 packets.
> My second point is that once they have finger printed your server,
> they may be able to launch an exploit. For badly un-patched systems,
> they may never even see a 404 in their logs, as the miscreants may
> break in without triggering one. In short I believe that making
> requests that result in 404 are not the things admins should be
> worried about. There may be some script kiddies out there, probing all
> web sites they find on google for tomcat manager apps. If that is
> their skill level, then I would suggest that you shouldn't worry too
> much about them.
>
> If your approach was successfully implemented across all
> patched/updated web servers, then the miscreants would still carry on
> probing as their would still be many 1,000's/1,000,000s of servers out
> there that are not patched, and hence not running the delay 404
> software. I know that your argument is that over time, this would
> reduce. However there are still millions of users out there running
> Windows XP (20% according to
> http://www.w3schools.com/browsers/browsers_os.asp). Whilst I know that
> this shouldn't reflect the os used server side, my point is that for
> ~10 years, there will still be badly patched app servers out there not
> running the delay 404 patch. So for the next 5 years (at conservative
> estimate), it will still be worth searching out these old servers. I
> know your argument is that after a percentage of web servers have the
> 404 delay software in place, scanners will slow. My points are a) the
> scanners will fingerprint the newer releases and not scan them b) most
> scans from real hackers will not result in 404s. There may be some,
> but most of their probing will not return these responses.
>
> 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. However since I seem to be the only voice of dissent, I will
> stop now. I would like to hear some other list members to voice in
> with their thoughts - PID it is not like you to be shy of coming
> forward. What are your thoughts?
>
> Personally end-user/developer/administrator education would seem a
> prudent avenue to reduce the problems on the modern internet.
>
Thank you for your thoughtful responses and comments.
The above should be required reading for would-be botmasters.
I feel that I have to add a couple of comments still.
I am totally aware of the fact that bots nowadays are sophisticated beasts, and that they
are using a lot of ways to spread and infect new hosts, sometimes astonishingly broadly
and quickly. And I know that finding and breaking into webservers that have "vulnerable"
URLs is only one tiny facet of how they operate, and probably by far not the main one
(which seems to remain email attachments opened carelessly by users themselves).
If I led anyone to think that I thought that implementing a delay in webservers 404
responses would kill bots in general, I apologise for such misrepresentation.
The proposed 404 delay is meant only to discourage bots from scanning for vulnerable URLs
in the way in which they (or some of them) seem to be doing it currently.
The origin of my proposal is in fact my personal annoyance at seeing these scans appear
relentlessly since years now in the logs of all those of my servers which are
internet-facing. I had been thinking for a long time (and probably not alone) of some way
to get rid of them, which would not require additional resources to be spent by my own
infrastructure, nor require a major investment in terms of configuration and setup, nor
make life more unpleasant for legitimate users, and thus be potentially usable on a
majority of webservers on the Internet. Like, squaring the circle.
Then I hit on this idea, which seems to have at least the potential to annoy bots in this
particular case.
Bots are sophisticated and multi-faceted. So it is futile to look for one definitive
weapon to get rid of them, and the approach has to be also multi-faceted. This could be
one of these facets, no more and no less.
Following your comments above, I have done some additional back-of-the-envelope
calculations, which seem to show that even applying your bot-efficiency principles above,
adding a 404 delay of 1 s on less than 20% of Internet webservers, would already slow down
this particular line of enquiry/attack by this particular kind of bot by at least 50%
(details on request). Independently of everything else, I believe that this is already
something worth having, and unless someone can prove that the approach is wrong-headed, I
will thus continue to advocate it.
But honestly, I am also a bit at a loss now as to how to continue. There is of course no
way for me to prove the validity of the scheme by installing it on 31 million (20%) of
webservers on the Internet and looking at the resulting bot activity patterns to confirm
my suspicions.
The Wikipedia article on botnets mentions the following :
"Researchers at Sandia National Laboratories are analyzing botnets behavior by
simultaneously running one million Linux kernels as virtual machines on a 4,480-node
high-performance computer cluster.[12]"
Maybe I should get in touch with them ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by chris derham <ch...@derham.me.uk>.
> Let me just summarise my arguments then :
> 1) These scans are a burden for all webservers, not just for the vulnerable
> ones. Whether we want to or not, we currently all have to invest resources
> into countering (or simply responding to) these scans. Obviously, just
> ignoring them doesn't stop them, and just protecting one's own servers
> against them doesn't stop them in a general sense.
> 2) there is a fundamental asymmetry between how bots access a server (and
> most of the responses that they get), and how "normal" clients access a
> server : "normal" clients receive mostly non-404 responses, while bots - by
> the very nature of what they are looking for - receive many 404 responses.
> So anything that would in some way "penalise" 404 responses with respect to
> other ones, should impact bots much more than normal clients
> 3) setting up a bot to perform such a scanning operation has a cost; if the
> expected benefit does not cover the cost, it makes no sense to do it.
> Assuming that botmasters are rational, they should stop doing it then. It is
> debatable what proportion of servers would need to implement this proposal
> in order for this kind of bot-scanning to become uneconomical in a general
> sense. What is certain is that, if none do and no better general scheme is
> found, the scans will continue. It is also fairly certain that if all
> servers did, this particular type of scan would stop.
> 4) it is not obvious right now which method bots could use to circumvent
> this in order to continue scanning HTTP servers for these known potentially
> vulnerable URLs. I do not discount that these people are smart, and that
> they could find a way.
> But so far it would seem that any scheme thought of by people commenting on
> this idea, have their own costs in some way and do not invalidate the basic
> idea.
> 5) if the scheme works, and it does the effect of making this type of
> server-scanning uneconomical, bot developers will look for other ways to
> find vulnerable targets.
> It is just not obvious to me where they would move their focus, HTTP-wise.
> If their aim is to find vulnerable URLs on webservers, what else can they do
> but try them ?
> 6) intuitively, it seems that implementing this would not be very
> complicated, and that the foreseeable cost per server, in terms of
> complexity and performance, would be quite low. The burden imposed on
> normal clients would also seem to be small.
> Maybe this should be evaluated in terms of a comparison with any other
> method that could provide some similar benefit at lower costs.
> 7) once implemented, it would be something which does not require any
> special skills or and special effort on the part of the vast majority of
> people that download and install tomcat. Which means that it has a real
> chance to automatically spread over time to a large proportion of servers.
> This is quite unlike any other bot-fighting measure that I have seen
> mentioned so far in this thread.
> 8) an obvious drawback to this scheme, is that if it works, it would take a
> long time to show its effects, because
> a) it would take a long time before a significant proportion of active
> servers implement the scheme
> b) even then, it would probably take an even longer time for the bots to
> adapt their behaviour (the time for the current generation to die out)
> So in politics, this would be a no-no, and I will probably never get a Nobel
> prize for it either. Damn. I would welcome any idea to spread this faster
> and allow me to gain a just recognition for my insights however.
So a miscreant decides that they want to hack into a computer. Like
most things in computing, they break the task down into smaller more
manageable tasks. Step 1 to find targets. Easiest step would seem to
be to enumerate every ip4 address possible, and sent a tcp/ip packet
to some known ports. If you get a response, its a live IP address. You
don't need to map every port, just establish if the host is listening
to the internet. This will allow you to build up a list of live IP
addresses and feed into step 2
Step 2 fingerprint those IP addresses. To do this, use a scanning
tool. These send packets to ports of a given IP address, looking at
the responses. They don't just look for positive responses, they also
send badly formed/invalid packets. They use many techniques to do
this. My favorite is the xmas tree packet. The low level TCP protocol
defines several fields as control fields - the xmas tree packet flags
all control fields as true. The packet is completely invalid at a TCP
level, but different os'es will respond differently. The results of
all of these responses provide a fingerprint, which should provide a
identification of what os the server is running. Using similar
techniques it is generally possible to identify the software stack
running on each port. Sometime there will be 100% confidence in the
results, sometimes less. Sometimes the software can't tell what the
software stack on the server is. However the aim of the game is to
work out which os and which software is running on the port. The
miscreants are after the low hanging fruit anyway right? So they build
up a list of IP addresses with software running on each port, and feed
to step 3
Step 3 If all has gone well in steps 1 and 2, you now you a list of Ip
addresses with names and versions of os and the server side software
running, and in some cases patch level. Combine this with any of the
publicly available exploit databases, and you can cherry pick which of
the low hanging fruit you wish to attack using known exploits that
haven't been patched yet.
Step 4 is if you don't have any targets with known exploits, then you
have to start looking for holes manually. The value varies, but they
say that there is one exploitable defect per thousand lines of code.
With this in mind, and an os/server stack/app stack combining to
contain many millions of lines of code, there should be ample scope
for finding a hole. Most os'es and app servers are reviewed by
security experts, and have been battle hardened. Most apps have not.
Apps seem to be the common weak point, second only to users and weak,
reused passwords. The scanners are getting better and better each day.
Some are now capable of detecting SQL injection defects in forms, and
flagging a site as ripe for targeting.
So coming back to your proposal. My first point is that step 1 uses
TCP/IP connections, so the probing occurs lower down the stack. Hence
delaying 404 responses will not stop or affect them. Some of step 2
can occur just looking for normal headers, or by using malformed
packets against pages that exist, i.e. will not result in 404 packets.
My second point is that once they have finger printed your server,
they may be able to launch an exploit. For badly un-patched systems,
they may never even see a 404 in their logs, as the miscreants may
break in without triggering one. In short I believe that making
requests that result in 404 are not the things admins should be
worried about. There may be some script kiddies out there, probing all
web sites they find on google for tomcat manager apps. If that is
their skill level, then I would suggest that you shouldn't worry too
much about them.
If your approach was successfully implemented across all
patched/updated web servers, then the miscreants would still carry on
probing as their would still be many 1,000's/1,000,000s of servers out
there that are not patched, and hence not running the delay 404
software. I know that your argument is that over time, this would
reduce. However there are still millions of users out there running
Windows XP (20% according to
http://www.w3schools.com/browsers/browsers_os.asp). Whilst I know that
this shouldn't reflect the os used server side, my point is that for
~10 years, there will still be badly patched app servers out there not
running the delay 404 patch. So for the next 5 years (at conservative
estimate), it will still be worth searching out these old servers. I
know your argument is that after a percentage of web servers have the
404 delay software in place, scanners will slow. My points are a) the
scanners will fingerprint the newer releases and not scan them b) most
scans from real hackers will not result in 404s. There may be some,
but most of their probing will not return these responses.
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. However since I seem to be the only voice of dissent, I will
stop now. I would like to hear some other list members to voice in
with their thoughts - PID it is not like you to be shy of coming
forward. What are your thoughts?
Personally end-user/developer/administrator education would seem a
prudent avenue to reduce the problems on the modern internet.
Whatever happens, I wish you all the best with your efforts for your proposal.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
>> Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>> HTTP/1.0" 404
>>
>>
>> also, if an 'ANN' email was sent, where /expert tomcat/ users can derive/develop a list of the popular/frequent URLs that bots use when attempting to compromise /tomcat/ servers.
>>
> Wouldn't this depend on what user applications are deployed on the Tomcat server? By default, I thought we concluded that Tomcat "out of the box" is not compromised? Did I mis-read something?
>
I don't think you did.
And I believe that if there was any knowledge that Tomcat "out of the box" was
compromised, the Tomcat developers would instantly set everything else aside and plug the
hole.
About this "/manager" access which started this thread : a long time ago, maybe as far
back as Tomcat 4.0 or Tomcat 5.0, I believe that the manager application was by default
enabled, and the tomcat-users.xml file that was shipped with it, also enabled the default
user-id and password that allowed to login to it and run it.
Then someone found a way to use this, to inject a rogue application into running and
web-accessible Tomcats. That hole was soon plugged, and hasn't been part of the default
distributed Tomcat for years. But apparently, there are still some bots on the www which
try it out, just in case there would still be one of these vulnerable old versions still
in activity (as there probably are; "never fix a running system", he ?).
That's all there is to it, as far as I know.
Now if you are running Tomcat as an internet-facing webserver on port 80, that Tomcat is
likely to be submitted to regular bot scans which are really targeting vulnerabilities in
applications which are relatively widespread on Apache httpd and IIS. These correspond to
URLs like "/phpadmin", "/mysqladmin", "/vti_bin" and the like, which do sometimes exist
under Apache httpd and/or IIS and sometimes do have security weaknesses, but which are
very unlikely to be installed in a Tomcat webserver (because they are not Java
applications, for one).
Thus you would see these accesses also in Tomcat access logs, because the bots are not
always discriminating enough to first check the type of webserver that they scan. But
under Tomcat, it would be very unlikely that you would have a webapp which actually
responds to one of these URLs, and consequently most of these attempted accesses would be
met with a 404 "Not Found" response.
Do not take the above as a recommendation to forget about it and to not regularly inspect
your webserver logs though. It is perfectly possible to create a Tomcat webapp which will
open up a huge security hole, and give it a context name that will be irresistible to the
first bot that notices it ("/secret" and "/private" come to mind).
If you set up an Apache httpd as a front-end to Tomcat (with an Apache/Tomcat Connector
such as mod_jk or mod_proxy), it is also quite easy to configure Apache httpd so badly
that it will provide access to files within Tomcat, which contain things that you would
never want an external client to see. The main example of this kind of bad configuration
consists of making the Apache httpd DocumentRoot and the Tomcat webapps directory overlap,
as mentioned here, in red characters :
http://tomcat.apache.org/connectors-doc/reference/apache.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
>Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>HTTP/1.0" 404
>
>
>also, if an 'ANN' email was sent, where /expert tomcat/ users can derive/develop a list of the popular/frequent URLs that bots use when attempting to compromise /tomcat/ servers.
>
Wouldn't this depend on what user applications are deployed on the Tomcat server? By default, I thought we concluded that Tomcat "out of the box" is not compromised? Did I mis-read something?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Sat, Apr 20, 2013 at 7:22 AM, André Warnier <aw...@ice-sa.com> wrote:
>
> 5) if the scheme works, and it does the effect of making this type of
> server-scanning uneconomical, bot developers will look for other ways to
> find vulnerable targets.
>
IMHO, I don't see why bots will get 'turned off' by having to wait longer
for a response from (potentially vulnerable) targets. I know that we are
talking a 'numbers game', and the more vulnerable targets that are
compromised, then I'm sure the developers of these bots "+1 Like" that, or
"mission accomplished". It is my assumption that these bots are automated
and can run 'for life', why would they stop doing what they are doing just
because of a delayed response. I'm sure these bots are already facing a
delayed response. I'm quite sure many web servers and/or web applications
do not respond that well/fast.
6) intuitively, it seems that implementing this would not be very
> complicated, and that the foreseeable cost per server, in terms of
> complexity and performance, would be quite low. The burden imposed on
> normal clients would also seem to be small.
> Maybe this should be evaluated in terms of a comparison with any other
> method that could provide some similar benefit at lower costs.
> 7) once implemented, it would be something which does not require any
> special skills or and special effort on the part of the vast majority of
> people that download and install tomcat. Which means that it has a real
> chance to automatically spread over time to a large proportion of servers.
> This is quite unlike any other bot-fighting measure that I have seen
> mentioned so far in this thread.
>
+1 I like the fact that a scheme is proposed that would require 'no
learning curve' and no required 'standard procedure' to be implemented when
attempting to adapt or take advantage of the solution/scheme.
But I still think that if all /tomcat/ users were informed via an 'ANN'
(announcement) email to deactivate or remove /tomcat/ manager app(s), and
somehow a survey is made available a few weeks/months /later/, where
cooperative /tomcat/ users can report-on how many 'attempted attacks'
showed up in their access logs after removing /tomcat/ manager app(s), and
then somehow publicize the survey results to the world, especially, in a
way that bot-developers can see that they are wasting their time, because
/tomcat/ users have made a concerted effort to /declare war against/ these
bots /and bot developers/.
also, if an 'ANN' email was sent, where /expert tomcat/ users can
derive/develop a list of the popular/frequent URLs that bots use when
attempting to compromise /tomcat/ servers.
also, for a certain amount of time, /immediate/ future releases of tomcat
should have manager app(s) as a separate download /available/, and 'ANN'
email will inform them that this is a change as we are attempting to ward
off the ongoing/obvious bot attacks against /tomcat/.
Yes, I know this will require additional steps and probably be rejected by
some/many tomcat users, especially those that are very very 'dependent' on
tomcat manager apps. manager apps are probably the 'primary' target, so
remove it from the install package, and make it a separate install, and ask
users for an honest effort to participate in this effort for the reason(s)
discussed in this thread.
we are a village, we have to start with tomcat, first, and then other app
servers can adapt 'schemes' that work...especially after it become a known
fact that bots are 'not' compromising tomcat servers anymore, /or/ they are
compromising less tomcat servers, because tomcat users are tired of these
bot attacks, and have made a concerted effort to stop/end
tomcat-bot-attacks.
Whatever scheme is implemented, if the survey results are positive and the
implementation meets the requirement/goal, then other servers will hear of
this good news, and adapt the scheme/solution, accordingly.
/my two cents/
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Mark H. Wood wrote:
> On Wed, Apr 17, 2013 at 01:45:22PM -0400, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> André,
>>
>> On 4/17/13 1:27 PM, André Warnier wrote:
>>> Leo Donahue - RDSA IT wrote:
>>>>> -----Original Message----- From: André Warnier
>>>>> [mailto:aw@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.
>> Sounds like a DOS to me. What you really want to do is detect an
>> attacker (or annoying client) and block them without having to use
>> your own resources. Maintaining a socket connection for an extra
>> second you don't otherwise have to do is using a resource, even if the
>> CPU is entirely idle, and even if you can return the
>> request-processing thread to the thread-pool before you wait that 1
>> second to respond.
>
> Good advice in general, but "what you want to do" depends on what you
> intend to accomplish. If your objective is to carry on with
> legitimate business without too much interference from the bots, then
> the thing to do is to detect bots and stop listening to them.
>
> I think that André's argument is that we might prefer a different
> objective: to spend (a reasonable amount of) resources to harm bot
> performance so that people stop deploying the nasty things. This is
> worth pondering. It fits nicely with the view that "there are two
> classes of threats: those properly dealt with, and those still
> alive."
>
> The problem with active resistance is, of course, that when the bad
> guys stop deploying bots they'll start doing something else. To be
> effective for more than a moment, we need to surround all the enemy's
> tactical options. At that point a smart enemy will give up and go
> home, while a stupid (or desperate) one will come on and be destroyed.
> Either way, you win. But this is very hard to arrange.
>
> So we have to consider what going active will cost, and how the
> enemy's behavior will change. The reward is still there for him if he
> can grasp it. What's the next soft spot, and can we defend or harden
> it? Can we afford to win the bot battle, or is it better to just
> shrug them off?
>
Thank you Mark for expressing this better than I could do it myself.
I do realise that my proposal tackles only one small aspect of the general "battle against
bots". It would be nice if someone could come up with the absolute all-encompassing
defense, passive or active. But I do not believe that this is going to happen, for the
simple reason that no matter what, for a server to be useful for something, it needs to be
accessible in some way, so some avenues will always be open.
I was just reading a book in which the author quoted the 3 basic principles of computer
security :
1. don't own a computer
2. don't connect it to the power
3. don't use it
(and lest anyone take this seriously, that was a jest; but like all good jests, it has a
bit of truth in it)
And I have also often wished that when my server detects such a malicious scan, there
would be some way by which it could retrace the origin (which it can) and go drop
something there that would go "boom" (which is unfortunately problematic in several ways).
So we are left with just a few ways to make our servers - and HTTP servers in general -
more secure against the malicious amd smart miscreants that are behind these bots.
Securing one's server individually will always be the best method.
My proposal does not in any way secure any server individually against bot attacks.
And from an individual server point of view, it is not the best nor the most efficient way
of fighting the scanning bots.
But so are many other measures on the WWW. For example, why do HTTP servers generally not
enable PUT requests by default, or act as forward proxies by default ? Or why do standard
browsers not accept cookies that are for a domain different from the domain which sends them ?
My proposal is not about providing an absolute weapon, nor about winning the final battle
against bots. It is only about "chipping away" at one avenue by wich bots can currently,
at low cost, scan millions of servers in the hope of finding a few that can then be used
to do additional nefarious things (for example, mounting a DoS attack against /your/ server).
It would (hopefully) raise the cost for bots of using this particular method of attack.
Whether it raises the cost enough that they will abandon it, I wish so but I really don't
know. Whether it actually costs something to the server which would implement it, I don't
know either.
But even if it has some (reasonable) cost for a server, I would nevertheless advocate this
as something for the public good, which is after all what open source is all about.
Let me just summarise my arguments then :
1) These scans are a burden for all webservers, not just for the vulnerable ones. Whether
we want to or not, we currently all have to invest resources into countering (or simply
responding to) these scans. Obviously, just ignoring them doesn't stop them, and just
protecting one's own servers against them doesn't stop them in a general sense.
2) there is a fundamental asymmetry between how bots access a server (and most of the
responses that they get), and how "normal" clients access a server : "normal" clients
receive mostly non-404 responses, while bots - by the very nature of what they are looking
for - receive many 404 responses. So anything that would in some way "penalise" 404
responses with respect to other ones, should impact bots much more than normal clients
3) setting up a bot to perform such a scanning operation has a cost; if the expected
benefit does not cover the cost, it makes no sense to do it. Assuming that botmasters are
rational, they should stop doing it then. It is debatable what proportion of servers would
need to implement this proposal in order for this kind of bot-scanning to become
uneconomical in a general sense. What is certain is that, if none do and no better
general scheme is found, the scans will continue. It is also fairly certain that if all
servers did, this particular type of scan would stop.
4) it is not obvious right now which method bots could use to circumvent this in order to
continue scanning HTTP servers for these known potentially vulnerable URLs. I do not
discount that these people are smart, and that they could find a way.
But so far it would seem that any scheme thought of by people commenting on this idea,
have their own costs in some way and do not invalidate the basic idea.
5) if the scheme works, and it does the effect of making this type of server-scanning
uneconomical, bot developers will look for other ways to find vulnerable targets.
It is just not obvious to me where they would move their focus, HTTP-wise. If their aim is
to find vulnerable URLs on webservers, what else can they do but try them ?
6) intuitively, it seems that implementing this would not be very complicated, and that
the foreseeable cost per server, in terms of complexity and performance, would be quite
low. The burden imposed on normal clients would also seem to be small.
Maybe this should be evaluated in terms of a comparison with any other method that could
provide some similar benefit at lower costs.
7) once implemented, it would be something which does not require any special skills or
and special effort on the part of the vast majority of people that download and install
tomcat. Which means that it has a real chance to automatically spread over time to a
large proportion of servers. This is quite unlike any other bot-fighting measure that I
have seen mentioned so far in this thread.
8) an obvious drawback to this scheme, is that if it works, it would take a long time to
show its effects, because
a) it would take a long time before a significant proportion of active servers implement
the scheme
b) even then, it would probably take an even longer time for the bots to adapt their
behaviour (the time for the current generation to die out)
So in politics, this would be a no-no, and I will probably never get a Nobel prize for it
either. Damn. I would welcome any idea to spread this faster and allow me to gain a just
recognition for my insights however.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Wed, Apr 17, 2013 at 01:45:22PM -0400, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> On 4/17/13 1:27 PM, André Warnier wrote:
> > Leo Donahue - RDSA IT wrote:
> >>> -----Original Message----- From: André Warnier
> >>> [mailto:aw@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.
>
> Sounds like a DOS to me. What you really want to do is detect an
> attacker (or annoying client) and block them without having to use
> your own resources. Maintaining a socket connection for an extra
> second you don't otherwise have to do is using a resource, even if the
> CPU is entirely idle, and even if you can return the
> request-processing thread to the thread-pool before you wait that 1
> second to respond.
Good advice in general, but "what you want to do" depends on what you
intend to accomplish. If your objective is to carry on with
legitimate business without too much interference from the bots, then
the thing to do is to detect bots and stop listening to them.
I think that André's argument is that we might prefer a different
objective: to spend (a reasonable amount of) resources to harm bot
performance so that people stop deploying the nasty things. This is
worth pondering. It fits nicely with the view that "there are two
classes of threats: those properly dealt with, and those still
alive."
The problem with active resistance is, of course, that when the bad
guys stop deploying bots they'll start doing something else. To be
effective for more than a moment, we need to surround all the enemy's
tactical options. At that point a smart enemy will give up and go
home, while a stupid (or desperate) one will come on and be destroyed.
Either way, you win. But this is very hard to arrange.
So we have to consider what going active will cost, and how the
enemy's behavior will change. The reward is still there for him if he
can grasp it. What's the next soft spot, and can we defend or harden
it? Can we afford to win the bot battle, or is it better to just
shrug them off?
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Machines should not be friendly. Machines should be obedient.
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Esmond Pitt wrote:
> The hack attempts that started this thread aren't denial of service attacks
> at all.
Who said that they were ?
They are attempted penetration attempts which if successful lead to
> installation of a viral servlet.
They were HEAD requests, which just indicate whether this URL actually responds.
And installing an application via the Tomcat manager requires additional steps, and is not
possible (since at least Tomcat 5.5) unless you have explicitly allowed it by providing
access to it without properly securing it, which is not the default Tomcat configuration.
The way I fixed them was to put an Apache
> HTTPD in front with a whitelist so that only known management IP addresses
> can even connect to /manager, let alone access it.
Good for you, and that will undoubtedly work if done correctly.
But if that was the only reason to install httpd in front of Tomcat, that's like using a
B-52 to kill a mouse. Why not just properly shielding the manager application at the
Tomcat level ?
Apache HTTPD doesn't give
> a 404, it just closes the connection.
Would you kindly explain how you got Apache httpd to do that ?
Off the top of my head, I do not know of any standard way in which one can configure
Apache httpd to close a connection in response to a request.
No exposure, no wasted threads, no
> wasted sockets, nothing.
That is conveniently skipping the fact that you installed a 50 MB footprint webserver in
front of Tomcat, plus (presumably) an Apache/Tomcat connector, which is adding 2 sockets
and two protocol stacks to the configuration.
And again if this was only to shield the manager application of Tomcat, then for all the
other Tomcat applications you are now executing a few thousand additional CPU instructions
for every other access to Tomcat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Posted by Esmond Pitt <es...@bigpond.com>.
The hack attempts that started this thread aren't denial of service attacks
at all. They are attempted penetration attempts which if successful lead to
installation of a viral servlet. The way I fixed them was to put an Apache
HTTPD in front with a whitelist so that only known management IP addresses
can even connect to /manager, let alone access it. Apache HTTPD doesn't give
a 404, it just closes the connection. No exposure, no wasted threads, no
wasted sockets, nothing.
EJP
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt:
"HEAD /manager/html HTTP/1.0" 404
Posted by David Kerber <dc...@verizon.net>.
On 4/20/2013 7:29 AM, André Warnier wrote:
...
> Addendum : actually, as far as 4xx codes go, a bit more discrimination
> is needed. A 401 response (Auth required) for example, should not be
> slowed down, as it is part of a normal authentication cycle. There may
> be others like that.
Well, Java SELECT CASE statements are fast, so sorting out different
things that need to be done for different types of responses isn't much
of a performance hit.
I like your idea; I've been reading your posts about it all along.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
André Warnier wrote:
> Mark H. Wood wrote:
>> On Wed, Apr 17, 2013 at 01:24:04PM -0500, Caldarale, Charles R wrote:
>>>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>>>> Subject: RE: Tomcat access log reveals hack attempt: "HEAD
>>>> /manager/html HTTP/1.0" 404
>>>> 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?
>>> Nothing of the sort. You simply put each 404 response on queue, and
>>> have an existing timer thread send it out when the appropriate delay
>>> has been achieved. No threads are tied up during the delaying action.
>>
>> However, sockets *are* tied up. We don't get this benefit for free;
>> it costs both kernel and application memory. Even if the limits on
>> these are infinitely adjustable, we might not want to adjust them that
>> high because they are doing another job for us.
>>
>
> True, but returning a 404 is something that needs to be done anyway, for
> legitimate requests as well as for the bots.
> As a matter of fact, returning any of the 4xx or 5xx error codes, which
> are fairly "standard" things (by which I mean that in most cases, the
> returned message is the same, no matter which application sends it and
> no matter what the request was).
> So why tie up a really valuable application thread to do that ?
> If any application, once it is determined that such an error message has
> to be sent back, could offload the actual work of doing it to some
> less-valuable process/logic, might this not be of general benefit to the
> server ?
> In such a case, the special handling of a 404 with an additional delay
> (or not), would only be a marginal thing.
>
> It is dangerous to make assumptions like this without actually testing
> it in the real world, with a real server submitted to a real load. And
> I understand that this would require someone to actually make the
> changes in the server code (I don't have the skills to do that). On the
> other hand, without actually testing it, we will never know.
>
>
Addendum : actually, as far as 4xx codes go, a bit more discrimination is needed. A 401
response (Auth required) for example, should not be slowed down, as it is part of a normal
authentication cycle. There may be others like that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Mark H. Wood wrote:
> On Wed, Apr 17, 2013 at 01:24:04PM -0500, Caldarale, Charles R wrote:
>>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>>> Subject: RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
>>> 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?
>> Nothing of the sort. You simply put each 404 response on queue, and have an existing timer thread send it out when the appropriate delay has been achieved. No threads are tied up during the delaying action.
>
> However, sockets *are* tied up. We don't get this benefit for free;
> it costs both kernel and application memory. Even if the limits on
> these are infinitely adjustable, we might not want to adjust them that
> high because they are doing another job for us.
>
True, but returning a 404 is something that needs to be done anyway, for legitimate
requests as well as for the bots.
As a matter of fact, returning any of the 4xx or 5xx error codes, which are fairly
"standard" things (by which I mean that in most cases, the returned message is the same,
no matter which application sends it and no matter what the request was).
So why tie up a really valuable application thread to do that ?
If any application, once it is determined that such an error message has to be sent back,
could offload the actual work of doing it to some less-valuable process/logic, might this
not be of general benefit to the server ?
In such a case, the special handling of a 404 with an additional delay (or not), would
only be a marginal thing.
It is dangerous to make assumptions like this without actually testing it in the real
world, with a real server submitted to a real load. And I understand that this would
require someone to actually make the changes in the server code (I don't have the skills
to do that). On the other hand, without actually testing it, we will never know.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Wed, Apr 17, 2013 at 01:24:04PM -0500, Caldarale, Charles R wrote:
> > From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
> > Subject: RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
>
> > 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?
>
> Nothing of the sort. You simply put each 404 response on queue, and have an existing timer thread send it out when the appropriate delay has been achieved. No threads are tied up during the delaying action.
However, sockets *are* tied up. We don't get this benefit for free;
it costs both kernel and application memory. Even if the limits on
these are infinitely adjustable, we might not want to adjust them that
high because they are doing another job for us.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Machines should not be friendly. Machines should be obedient.
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 17, 2013 at 10:45 AM, chris derham <ch...@derham.me.uk> wrote:
> The OWASP recommendations for securing tomcat suggest removing all items
> under
> catalina_home/webapps as a first step. Just a thought.
>
> The first step an attacker performs when conducting a focused attack,
> is to map out the server. The presence of a response to
> http://server:8080/manager/html/ would seem to indicate a default
> install of tomcat. Once that have this initial reconnaissance
> performed, they will move onto using known exploits against it. By
> removing manager app from the default install, this would be made one
> step harder. You can't really prevent a dedicated attacker, but making
> it one step harder to attack your server, might make the
> not-bothered-which-server-I-attack guy move on to easier pickings
>
+1 Chris! When I migrated from Glassfish 3.1.2.2 to Tomcat/tomee late last
year, this is really what I wanted. I forgot the default port (since I'm no
longer a Glassfish user), but I liked how Glassfish defaulted home-grown
web apps on port 8080, and Glassfish Admin web application was on port 4848
(just remembered that).
When I experienced my first 'attack' on my development server, that is what
I wanted. it would be nice to know how to re-configure my tomcat/tomee, so
the manager app will be on port 4848, or something like that, but being the
novice that I am, I did not know how to do it, and I honestly confess that
I did not read the tomcat documentation on how to do it. :)
Trying to catch up on all the responses. I wanted to respond to a few other
posts, but thought I might keep reading. Now, I will go back to reading
more of the responses.
> If you deliberately delay 404 by a known amount of time, it will still
> stick out, and they can use this just as much as a positive
> indication.
>
I agree with this. 'delay 404' sounds like a good idea, but how many of
those botnet developers are on this list 'today', reading this discussion?
In no time, and IMHO, I'm sure they can/will develop a botnet that is
'tolerant' of delay 404, or something similar.
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Thu, Apr 18, 2013 at 12:26 PM, André Warnier <aw...@ice-sa.com> wrote:
>
> My contention is that this would be self-defeating for the bots.
>
>
> 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)"
>
>
I definitely saw this in my local access log last night. I was working
with someone's test-case that they sent me, and I stumbled on the 404 error
(see below) in my browser, which clearly shows that this is a tomcat/tomee
server. do the bots read the 404 error HTTP response and check if the
response includes the string lowercase('tomcat') ?
HTTP Status 404 - /prova_fileupload_primefaces/
type Status report
message /prova_fileupload_primefaces/
description The requested resource is not available.
Apache Tomcat (TomEE)/7.0.39
-------
it really showed up like this, below; i copied the text to text editor and
copied the text above.
HTTP Status 404 - /prova_fileupload_primefaces/
------------------------------
*type* Status report
*message* */prova_fileupload_primefaces/*
*description* *The requested resource is not available.*
------------------------------
Apache Tomcat (TomEE)/7.0.39
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
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
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by chris derham <ch...@derham.me.uk>.
> 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.
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.
> 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™.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 17, 2013 at 2:39 PM, André Warnier <aw...@ice-sa.com> wrote:
>
> Some other calculations :
> According to the same Netcraft site, of the 600 million websites, 60% are
> "Apache" (I guess that this includes httpd and Tomcat (or else Tomcat is in
> "others").
>
>
This is good to know, and honestly, I'm glad to see/know this. I recently
learned that the webhost of my family business 'public' website is using
Apache as well. I recognized this while looking at some specs in the admin
console, provided by the web host on the admin console pages of their
website.
Anyway, again, I like the idea that you're proposing, but a friendly
reminder... something I have recognized (even being new to the list) is
that a *huge* *majority* of *tomcat* endusers are using *older* tomcat
versions, and even though you all recommend them to update their tomcat
version for security reasons, how many of them do their best to 'always'
have the latest-n-greatest version of tomcat.
So, even if 'delay 404' was added, I don't think many of the
already-existing apache/tomcat websites will have this new 'delay 404'
feature. :)
Also, the 'delay 404' basically requires a possible change or release note
that says, undeploy or delete manager app (etc...), so this 'delay 404'
feature can be used, since tomcat's manager app is one of the popular URLs
that hackers or bots, target.
just my two cents...
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
chris derham wrote:
>> Yes. But someone *does* own the botted computers, and their own
>> operations are slightly affected. I have wondered if there is some
>> way to make a bot so intrusive that many more owners will ask
>> themselves, "why is my computer so slow/weird/whatever? I'd better
>> get it looked at. Maybe I should install a virus scanner."
>
> Somebody said earlier in the thread (sorry but I can't be bothered to
> find the exact quote and attribute it) something along the lines of
> "this is an arms race". The current bot software may not be there yet,
> but it is easy to see how the bot-net developers would like to have
> the job of probing IPs distributed over the botnet, so each target
> only receives a single call from each distinct IP, but together the
> 10,000 members of the bot-net each send one probe creating a full
> probe of known weak points in the server. The net result would be a)
> very hard to detect/defend against b) the proposal would not have a
> negative effect - you only add 1 second (or whatever value is agreed)
> to the async call time for each botnet member.
Hi.
Long and thoughtful post. Thanks.
Let me just respond to the above for now.
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
Now, you can optimise this for either elapsed time, or CPU time, or memory, or bandwidth
using various designs. But you cannot optimise for everything at the same time.
(If this was possible, then they would already have done it even now, no ?)
For example, you could have each bot opening 100 connections to 100 different servers,
issue one request on each as quickly as possible, and then start polling the 100 sockets
for a response, instead of going to sleep (or a blocking read) on each request until a
response comes.
But then, you are using a lot more CPU time to do your polling, and you have 100
connections open to 100 servers, so you use up more memory (and file descriptors etc).
Or you can decide to just wait, but then it is taking your botnet of 100 bots 100 times as
long to finish its complete scan of the 100,000 servers.
Without changing your footprint on each bot host, the only way to get your scan complete
within the same time would be to increase your botnet by the same factor 100, to 10,000
bots. But then the 99,900 additional bots cannot do something else of course.
Some other calculations :
According to the same Netcraft site, of the 600 million websites, 60% are "Apache" (I
guess that this includes httpd and Tomcat (or else Tomcat is in "others").
So let's imagine that among the 100,000 sites above, 60,000 run an Apache server, and that
50% of these (30,000) implement the delay scheme.
The time to scan the 100,000 would then be of the order of (30 URLs x 30,000 hosts x 1 s)
= 90,000 s ~ 250 hours (to simplify I am ignoring the other 70,000 "fast 404" ones).
That is still ~240 hours more than the baseline, and may still be enough to make the
scanning uneconomical.
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.
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. This means that no matter how well 100 million servers are well-configured, there
will still be 500 million that are not well-configured, and that among these there are
enough potential bot targets to justify the scanning. And as long as this is the case,
the scanning will continue and it will bother *everybody* (even the 100 million servers
which are well-configured). That's because the bots, a priori, don't know that your
server is well-configured, so you'll still be scanned.
(*) According to Netcraft
(http://news.netcraft.com/archives/2012/09/10/september-2012-web-server-survey.html)
In the September 2012 survey we received responses from 620,132,319 sites, a decrease of
8M sites since last month's survey.
80% of that is about 500 million.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by chris derham <ch...@derham.me.uk>.
> Yes. But someone *does* own the botted computers, and their own
> operations are slightly affected. I have wondered if there is some
> way to make a bot so intrusive that many more owners will ask
> themselves, "why is my computer so slow/weird/whatever? I'd better
> get it looked at. Maybe I should install a virus scanner."
Somebody said earlier in the thread (sorry but I can't be bothered to
find the exact quote and attribute it) something along the lines of
"this is an arms race". The current bot software may not be there yet,
but it is easy to see how the bot-net developers would like to have
the job of probing IPs distributed over the botnet, so each target
only receives a single call from each distinct IP, but together the
10,000 members of the bot-net each send one probe creating a full
probe of known weak points in the server. The net result would be a)
very hard to detect/defend against b) the proposal would not have a
negative effect - you only add 1 second (or whatever value is agreed)
to the async call time for each botnet member.
I agree that currently if an attacker compromises a server, and then
runs probes against the whole internet from that one host, your idea
would slow the assault. However it will just encourage the next
evolutionary step described above. However the bad guys are quite
clever. The scanning software already has rate limiting switches to
stop network intrusion detection systems from detecting probes. They
would just use these to slow the attack and the computer user would
not notice. As long as you have many bots in the whole net, it isn't a
problem.
I used to work in agrochemical research. They tried 1,000,000
different pseudo-random chemicals a year against plants, watching for
a reaction. If something reacted in a "positive" manner, then they
investigated what was going on. This is the same as the bad-guys are
doing globally - probe every IP, and look for interesting responses.
Yes the approach to slowing down these responses should in theory
work, but if the clever guys distribute the load over a bot-net, and
the bot-net is large enough, then it is just a numbers game. Enough
bots sending probes, and then get a new target each day, that will be
enough for them to abuse that target to send out that days mailshot of
spam.
The key security recommendation is to not have anything running unless
required. The manager app has no users defined by default - perhaps
the default install for tomcat could be such that it is a bare bones
install? I do not know of any weaknesses in the manager app, but if it
isn't even there, their presence/absence doesn't really matter. Same
with the other default parts, e.g. help etc. As long as they can be
installed easily if required, shouldn't be a problem. The OWASP
recommendations for securing tomcat suggest removing all items under
catalina_home/webapps as a first step. Just a thought.
The first step an attacker performs when conducting a focused attack,
is to map out the server. The presence of a response to
http://server:8080/manager/html/ would seem to indicate a default
install of tomcat. Once that have this initial reconnaissance
performed, they will move onto using known exploits against it. By
removing manager app from the default install, this would be made one
step harder. You can't really prevent a dedicated attacker, but making
it one step harder to attack your server, might make the
not-bothered-which-server-I-attack guy move on to easier pickings
Also one thing worth mentioning. There is an attack called a blind sql
injection attack. The crux of it is that by timing the response from a
sql injection, you can detect if your query was a success or a
failure. Typically some processing occurs upon success, hence the
response takes longer. During testing (obviously not against a real db
:-)), I have used manged to download the whole contents of a db after
a little scripting of a sql injection and some perusal of the results.
If you deliberately delay 404 by a known amount of time, it will still
stick out, and they can use this just as much as a positive
indication.
HTH somebody
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 17, 2013 at 1:59 PM, Leo Donahue - RDSA IT <
LeoDonahue@mail.maricopa.gov> wrote:
> >-----Original Message-----
> >From: Christopher Schultz [mailto:chris@christopherschultz.net]
> >Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
> >HTTP/1.0" 404
> >
> >
> >People *do* do this (notice their computer sucking) but mostly (at least
> >Americans) will just go out and buy another one, assuming that their
> >computer just isn't fast enough to "work well" after owning it for a few
> years.
> >
> ><soapbox>It's sad that most of us have more computing resources beneath
> >our fingertips than spacecraft do, yet we upgrade every few years because
> >MS Office has gotten fatter. </soapbox>
>
> And no one ever uses (or knows about) the restore partition when their pc
> becomes full of junk.
>
> However, the old P4 laptop I have running XP with 2GB of RAM and dedicated
> video RAM doesn't do much for websites these days running a lot of
> graphics.. ahem Silverlight, flash, etc... The web is also getting fat.
>
>
[OT] response to previous [OT] chatter above. :)
You all get me laughing a lot by listening in on discussions/threads.
Anyway, I have definitely recognized what Chris is talking about, and
honestly, I have been the one that have 'supported' friends and
family...telling them to 'restore-to-factory' their Windows laptop/desktop,
whenever it gets slow; I got 'tired' of trying to go through Windows
registry and startup folders, trying to figure out what malware was
maliciously installed, etc....
Quite a few times, I have had to bring home PCs, belonging to friends, and
do this restore-to-factory, and I have had to 'remind' family to
'restore-to-factory'. Finally, and recently, I restored my 2005 Dell
Windows XP laptop, last year (maybe), and gave it to my 9-year-old
daughter. It definitely could not meet my requirements to develop/test
software. :)
>
> >- -chris
>
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Christopher Schultz [mailto:chris@christopherschultz.net]
>Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>HTTP/1.0" 404
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Mark,
>
>On 4/17/13 8:49 AM, Mark H. Wood wrote:
>> Yes. But someone *does* own the botted computers, and their own
>> operations are slightly affected. I have wondered if there is some
>> way to make a bot so intrusive that many more owners will ask
>> themselves, "why is my computer so slow/weird/whatever? I'd better
>> get it looked at. Maybe I should install a virus scanner."
>
>People *do* do this (notice their computer sucking) but mostly (at least
>Americans) will just go out and buy another one, assuming that their
>computer just isn't fast enough to "work well" after owning it for a few years.
>
><soapbox>It's sad that most of us have more computing resources beneath
>our fingertips than spacecraft do, yet we upgrade every few years because
>MS Office has gotten fatter. </soapbox>
And no one ever uses (or knows about) the restore partition when their pc becomes full of junk.
However, the old P4 laptop I have running XP with 2GB of RAM and dedicated video RAM doesn't do much for websites these days running a lot of graphics.. ahem Silverlight, flash, etc... The web is also getting fat.
>
>- -chris
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 4/17/13 8:49 AM, Mark H. Wood wrote:
> Yes. But someone *does* own the botted computers, and their own
> operations are slightly affected. I have wondered if there is
> some way to make a bot so intrusive that many more owners will ask
> themselves, "why is my computer so slow/weird/whatever? I'd
> better get it looked at. Maybe I should install a virus scanner."
People *do* do this (notice their computer sucking) but mostly (at
least Americans) will just go out and buy another one, assuming that
their computer just isn't fast enough to "work well" after owning it
for a few years.
<soapbox>It's sad that most of us have more computing resources
beneath our fingertips than spacecraft do, yet we upgrade every few
years because MS Office has gotten fatter. </soapbox>
- -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/
iQIcBAEBCAAGBQJRbuBwAAoJEBzwKT+lPKRY/SsQAK3l3RAxAzhW0fVBLCHlvsm3
KpV8/KztwCwJzoS6ZrsKTvMWCq8PpKsjiGFZNRTjKY60b2UAPwBEq6a5LOti1Jp+
XqTvAJGtUtNsECnO9ztxhQsXT01Ta6Jr5KcuYZTjLgBoPdkPAqKtjrdlD8qG5brz
eaSJ60zz2omRJBxn6WackMvoZhp7fivrx5zvR3RfgDX5tolqChJOeiXp9zVg2d53
cUgbCIga7oSul4GmrMYwsQepPnurwQa3ZRywXmzqjQTvEc+K9ITwn0zEC5U4D4Vi
CvStqUbXIJf/9q23xy33ExWOkO6eSMP3BLbtQ1IUlOnV11/o6tLrP9o1Nb9c3h1a
Zpb1AGqHzY8vJaD4YSybmK8UAUQ/cSbBFsbxWFGFFp53KO7o6oV3Nmr5hxU+y5xR
uetvvqs8eqyYO7ktcBui/uIunADz5eJ6eHD3JxQoFQ13lby5kOMYGWMFYdOKXjOT
uMyFOGm1G/FeC6TwSSkCQiGmvGCf0k36HYFc+AaUpKcIaG52yyswlIhJnvZO069O
BiagSbi04tkL+gQRfyT2x2h7ewTqcAwB1uYoG+kSBeAb5n0AJyFuVYslhnCySrQ2
zGCr/w/lWoImM6myiYtL1LwgP2zwG+Gur9RhWdoATbQgoFXncVT29u4ItUhxAar3
e91tWwraTmrjwhjOBNvo
=WlUO
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Tue, Apr 16, 2013 at 01:57:55PM -0300, chris derham 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.
Yes. But someone *does* own the botted computers, and their own
operations are slightly affected. I have wondered if there is some
way to make a bot so intrusive that many more owners will ask
themselves, "why is my computer so slow/weird/whatever? I'd better
get it looked at. Maybe I should install a virus scanner." If bots
were killed at a much higher rate, that *would* affect the botnet
masters. I have no idea how to make bots more visible by messing with
their attacks, just wondering.
Then again, my experience shows that when a computer slows down most
people either just live with the problem or buy a faster machine. Ugh.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Machines should not be friendly. Machines should be obedient.
Re: Tomcat access log reveals hack attempt:
"HEAD /manager/html HTTP/1.0" 404
Posted by David kerber <dc...@verizon.net>.
On 4/16/2013 12:57 PM, chris derham 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.
They might go parallel async, but that would require more sophistication
on the part of the hacker, and more hardware and bandwidth as well,
again reducing the economic return of such scans.
>
> 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.
Except time. And slowing down the rate at which they can find
vulnerable hosts helps every honest web host, as well as the ones which
actually implement this.
>
> Sorry but those are my thoughts
>
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> David,
>
> On 4/16/13 2:53 PM, David kerber wrote:
>> On 4/16/2013 2:26 PM, André Warnier wrote:
>>
>> ...
>>
>>> The trick is to make the vaccine cheap enough and easy enough to
>>> administer, so that there will be a significant enough proportion
>>> of "vaccinated servers" to make the virus statistically
>>> ineffective. Maybe if we find a simple patch to Tomcat to
>>> introduce this 404-delay, we could hire a botnet to distribute
>>> the patch ?
>>>
>>> Mmmm, maybe there is another idea there : how about an
>>> anti-botnet botnet ?
>> Microsoft already works with the DOJ and DHS occasionally doing
>> something like this. It has been a while, but I have seen
>> articles referring to it.
>
> There are lots of ethical concerns with writing a virus or worm that
> goes around patching systems to make them more secure. I'm fairly sure
> that idea was invented a few minutes after the first Internet worm was
> discovered and mostly discarded as being a bit too devious to implement.
As a matter of fact, the ideas of "worm" and "counter-worm" (and Internet) were invented
years before the Internet itself became a reality.
Check this out : http://en.wikipedia.org/wiki/The_Shockwave_Rider
This was written in the 70's, and I have always been amazed at that particular author's
prescience. You can read this book now, and it feels a lot less outdated than many more
contemporary pundit blurbs.
This is getting more OT, and diluting the original message. Yes, I know, my own fault.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 4/16/13 2:53 PM, David kerber wrote:
> On 4/16/2013 2:26 PM, André Warnier wrote:
>
> ...
>
>> The trick is to make the vaccine cheap enough and easy enough to
>> administer, so that there will be a significant enough proportion
>> of "vaccinated servers" to make the virus statistically
>> ineffective. Maybe if we find a simple patch to Tomcat to
>> introduce this 404-delay, we could hire a botnet to distribute
>> the patch ?
>>
>> Mmmm, maybe there is another idea there : how about an
>> anti-botnet botnet ?
>
> Microsoft already works with the DOJ and DHS occasionally doing
> something like this. It has been a while, but I have seen
> articles referring to it.
There are lots of ethical concerns with writing a virus or worm that
goes around patching systems to make them more secure. I'm fairly sure
that idea was invented a few minutes after the first Internet worm was
discovered and mostly discarded as being a bit too devious to implement.
- -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/
iQIcBAEBCAAGBQJRbaulAAoJEBzwKT+lPKRYFeEQAKAtih4yjf2Eo9GjjkMv+Ep9
qkCijwXvBD2M1PcIRuJ4+aSyT6Xlslgz0sbHlkV/6XxLtRmVJrWoMh9v9lF9foCm
chCHoHcvNJpHfsFOLArhvnFwlZKtAwQYKvpjhZMTZHUog+7Da3f1oFaW/3SNdG/3
0cttkF7F5GsMvko5awxEZZcckcFaDyX3gd/4xXKxNl2Rx4J4YKwrpimTSRAXIiH5
Tc2g9+Q1cVq/XsOkSwoLMZaVrCXq2/TUj8CP2xhn06dooOj3fFItzdcB1CtKH8ZG
MIKwsoCgbFvM0vCUWp+NJc+O2RCiiAgI6LMRSm36CQSLGFJthb+0kikgPto+XEJJ
CqJbeq6+db7esuHKeJbDD8mF50AHhBiHtS0F6YWz9kekHv1l0xtorQCfM8Nj/OH/
AzseO19TAEUyFPxHKTawpSoCKBw/psou15ii47Saeo5vKFtIrO/Vl4ty7eT2KEOe
AvXIU86gYI3F5VaZuOZLmfBNS4rz5Zz+d9z6613HwP6eRCR/q9ynx6tfLEPJqKRr
v189T1zdRXany5qW+vRQzfnJ1NWX9luAnyjo4dvMrah1bjRkXc1uiILOrxjqq9jl
MuTStz21SCLnO/yNNWOfIKM1xweSrWFKTlUTcaocWNB48635llQdOK5KoT6v1LO1
8nHdAe3ft9Q82EZ/a+Cg
=DGXS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt:
"HEAD /manager/html HTTP/1.0" 404
Posted by David kerber <dc...@verizon.net>.
On 4/16/2013 2:26 PM, André Warnier wrote:
...
> The trick is to make the vaccine cheap enough and easy enough to
> administer, so that there will be a significant enough proportion of
> "vaccinated servers" to make the virus statistically ineffective.
> Maybe if we find a simple patch to Tomcat to introduce this 404-delay,
> we could hire a botnet to distribute the patch ?
>
> Mmmm, maybe there is another idea there : how about an anti-botnet botnet ?
Microsoft already works with the DOJ and DHS occasionally doing
something like this. It has been a while, but I have seen articles
referring to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
chris derham 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
>
Don't feel sorry at all. The purpose of flating this idea here on the list, is to get as
many reactions (and objections) as possible. I am not quite sure either that the idea is
really practical, just that it might be.
Let me tackle the objections that you mention above :
First, the zero-cost one.
I have to imagine that there are some costs into creating, maintaining and deploying a
botnet. First, there is the cost of possibly getting caught doing it, and possibly paying
a big penalty. That must be compensated by some possible benefit, but if at some point
the possible cost outweighs the possible benefits, there will be less botnets.
Second, although when the botnet is deployed, it does not cost much to the deployer to
actually run it, it does cost something to the system hosting it (bandwidth, cpu cycles
etc), so the likelihood is that at some point it will be discovered and eliminated. So it
will have costs in terms of re-deployment. To prove this ad-absurdum, if it did not cost
anything, then there would also not be a market for selling botnets or botnet code for
money; and there is. See the article mentioned in an earlier message in this thread.
Second, the concurrent async requests :
What I am seeing on my servers at the moment are sequential requests, separated by a few
seconds each. I'll get some 30 requests in a row like that, then nothing for a while, then
again a batch of sequential requests originating from another IP, etc.. And this all day
long. On 20 servers, this amounts to several thousand requests per day in total.
But even if the requests were made simultaneously, the cost *per request*, for the "botnet
host" issuing the requests, would be the same. And the more resources are consumed by the
botnet on its host (cpu time, connections, memory, bandwidth), the more noticeable it
becomes. Even if this is a criminal botnet server dedicated to this task instead of being
an infected third-party server, there is a limit as to how many requests one server can
issue, whether they are simultaneous or not.
Also on the target host, if there is a batch of 30 simultaneous requests for 30 different
URLs, all coming from the same client IP, it becomes more noticeable, and easier to
distinguish from genuine client requests.
So all in all, I think you have a point, but I believe that it is not overwhelming, and
that the basic assumptions that I made still hold up.
I will another possible objection of my own (and my answer), to save someone the task (or
the pleasure) of doing it : if we block this avenue for infecting webservers and make it
uneconomical, then the botnet authors will re-direct their infrastructure to other
targets. For example, they would re-target their botnets to trying to connect via SSH and
try more userid/password combinations, like here :
http://www.bbc.co.uk/news/technology-22152296
But in my egotistical view, that's fine. In this particular case, it bothers me to see a
part of my webserver's resources being wasted by these scans, so it they disappear and go
somewhere else, that's good enough for me at the moment.
(And maybe I'll think of something for SSH next..)
What we are facing is something like a (biological) virus : each new infected host can
scan for more victims, which then become infected in turn and help spread the epidemic.
So we are looking for something like a vaccine : if enough servers become resistant, then
the virus cannot spread as easily anymore, and eventually it dies out. Not all webservers
need to implement this, just enough of them.
The trick is to make the vaccine cheap enough and easy enough to administer, so that there
will be a significant enough proportion of "vaccinated servers" to make the virus
statistically ineffective.
Maybe if we find a simple patch to Tomcat to introduce this 404-delay, we could hire a
botnet to distribute the patch ?
Mmmm, maybe there is another idea there : how about an anti-botnet botnet ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> On 4/16/13 2:37 PM, André Warnier wrote:
>> 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..")).
>
> Aren't we just back to mod_security at that point?
No. mod_security is certainly a great tool, much more capable and flexible and effective
than what I am proposing.
But it suffers from the same issues as the one I mentioned earlier.
Have a look at :
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Introduction
It requires a whole setup in Apache to even start to do something.
In the practice, that means that only a small percentage of all webservers on the www will
ever install and use it, which greatly reduces any impact it will have on the www at
large. It will totally protect the 10% of WWW servers on which it is installed, and do
nothing to protect the remaining 90%.
So the botnets will still have 90% of the WWW webservers to scan, and this will keep them
in business. Because for the exploiters of a botnet, the "quality" of the servers into
which they break does not really matter. A poorly-protected Linux server running only one
personal website, is just about as valuable as your high-powered 32 GB RAM 8-core monster,
when it comes to using it as a platform to attack other sites.
And most of these small, low-budget webservers will precisely be the ones which install
the standard Tomcat or Apache via apt-get or the Windows Installer, and never change a
standard setting.
So it should be a standard feature, and the option should be to turn it off.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 4/16/13 2:37 PM, André Warnier wrote:
> 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..")).
Aren't we just back to mod_security at that point?
- -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/
iQIcBAEBCAAGBQJRbar4AAoJEBzwKT+lPKRYQTUP/1kZ9LxB7isaBzQWF0ZUHqh2
oDVIYvtLb8gvn1nvVuXRSKIjKMVl4BKtkxSg6G/XntmiCF0HmGECSwkQNn3KjjA7
LNBO2pKQOOZsx3XsrzHcCNXQ9cxxefzTJNvmjgDgC6MThxx3UB0lVcYv5Wfa8v0n
2GC/PotDBMGId5jGPSJZaFKPLR1d5z+0st7pyjuASmzz3qU8iqPgkb20h5aDlDx9
Gp89NdHP3rvUoWvdd/c5LO/g5CTboXMoOZYrfLANYtW2X7PmVLjKgKmVyO4qRnsl
JyXFl1cregWLMP+x+dh8UhzALFeS0R+HiRsF6Sx9/kXbijgmaKC88D8V6Xgngseg
Xvu5oiuLFFJLneLBHhmEtVuXi3Ys4H/PO0dgz1zTfONLLK7ZYl2e6cw5Vans90h2
QzD8RWTx7X3UQG8TrcsDKsle0Bb6A2ciJOOAili7YtI2M1ycIP4BB8v8Hz74ooth
69FQClLmOfIWJsFCzdqa4JHPyk2Afltq2pLYvg9RyLNM4rQq/i8dN6R8BE+/ILKk
taALJY7Nk5yy8tRi7W8NNqkE2g/KMbanhhFdRfmBRkxwbN/j2LYApu2vaRfGk+vn
/YpU2cfcYg6q4hYrTBzhXC7Ea8CW9kPo6A5/k8/AW/A5izdTNl3vXeUCaogOSIK7
wieja8giVMLcWxjOTQ/O
=ZJJT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
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 ?
Alternatively of course, still if there are no definite arguments against it, but the
Tomcat developers are not interested, I could go to the Apache list anyway. And then they
might be the first to introduce this great feature.
Or maybe I'll just patent it, and then sell the patent to the makers of the third
most-popular webserver..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
> Subject: RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
> 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?
Nothing of the sort. You simply put each 404 response on queue, and have an existing timer thread send it out when the appropriate delay has been achieved. No threads are tied up during the delaying action.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 17, 2013 at 3:45 PM, Leo Donahue - RDSA IT <
LeoDonahue@mail.maricopa.gov> wrote:
>
> Not knowing anything about the history of the HTTP 404 method, if a server
> does not find a matching request URI, why was it decided that the protocol
> would even respond at all? Seems like the request could have just been
> ignored or dropped.
>
> [Way OT...]
> If you get this to work, then the next place you can take this idea is to
> the phone company. Why should my phone even ring at all if I know the
> caller is from an 800 number... or from some other list of people I don't
> care to talk to ... I would love it if those guys had to wait 10 or 20
> seconds between rings... that would be great!!
>
+1 being facetious here, but IMHO, when André proposed the 'delay 404' (or
at least when I started reading this thread earlier this afternoon), I
thought, wow, it would be nice to respond to these bots with a 2GB-size
html page instead of returning 404. I know such an idea will ever be
implemented, but was just a thought. That will surely rock their world and
the web server's world (which we don't want, of course).
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>> HTTP/1.0" 404
>>
>>> 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?
>> No, not at all. It would be nice but no.
>> What I mean is that any 404 response should be handed off to one of these
>> lightweight processes, so that the real useful process doesn't have to handle
>> it.
>> Of course some processing has already taken place to find out that the target
>> resource of this URL does not exist and that responding with a 404 code is
>> appropriate.
>> But as soon as this is determined, the rest should be "sub-contracted" to a
>> simple sidekick, which will do the 1 second wait and then send back the
>> response on the connection and then close the connection.
>> In the meantime, the real useful webserver process can be available to
>> process the next request (which can be bogus again, but nothing to do about
>> this). No need for this real valuable complex process to spend his own time
>> waiting for 1 second, sending the 404, closing the connection etc..
>> And we do not really care if this sidekick, 404-sending-only process has a
>> backlog at some times, and sometimes takes longer than 1 second to finish off
>> this 404 response, do we ?
>
> No, I guess not.
>
>> And..
>>
>
> If I'm understanding the point you are making, you're saying that delaying the 404 response slows down the ability of the bots to collect
information. The bots will *still* collect data, it will just take them longer to get the
list of possible exploits?
>
Yes. /much/ longer. Hopefully so much longer that it would no longer be worthwhile for
them to try to collect it this way, and that in the end they will just stop trying.
Which would be to the ultimate benefit of /all/ websites on the web, which currently have
all to deal with these unsollicited requests.
> Not knowing anything about the history of the HTTP 404 method, if a server does not find a matching request URI, why was it decided that the protocol would even respond at all? Seems like the request could have just been ignored or dropped.
>
Because a legitimate client would then be severely inconvenienced, if a page that he got
before contained a link which (for whatever reason, probably an error from the site
designer) really does not lead to a real resource on the server.
This legitimate client (or rather the user using it) would click on a link; the browser
would issue the corresponding request to the server; and then the server would never
answer. But the client does not know if this is because the server is temporarily a bit
slower, or if the response is really taking a long time to be prepared by the server
(think of a heavy database request), or if this is just a bad request. So it would be
forced to wait, as long as is "reasonable" (10 seconds, 30 seconds, 2 minutes, ..?),
before it finally gives up. That would make navigating the web a painful experience.
Browsers do that; if they can connect to the server and send the request, but then they do
not get a response to the request (but the connection stays alive), they will generally
wait up to 5 minutes before giving up. Then you will get a message like "The server is
taking too long to respond. etc..".
So when the server receives a request, and it knows that this resource does not exist, it
responds right away with the appropriate response code, to be nice to the user and not
force him to wait. This is dictated by the HTTP protocol as being a response with a status
code "404", meaning in human terms "the requested resource is not available on this server".
> [Way OT...]
> If you get this to work, then the next place you can take this idea is to the phone company. Why should my phone even ring at all if I know the caller is from an 800 number... or from some other list of people I don't care to talk to ... I would love it if those guys had to wait 10 or 20 seconds between rings... that would be great!!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Tomcat access log reveals hack attempt: "HEAD
/manager/html HTTP/1.0" 404
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: André Warnier [mailto:aw@ice-sa.com]
>Subject: Re: [OT] Tomcat access log reveals hack attempt: "HEAD
>/manager/html HTTP/1.0" 404
>
>Leo Donahue - RDSA IT wrote:
>...
>
>>
>> [Way OT...]
>> If you get this to work, then the next place you can take this idea is to the
>phone company. Why should my phone even ring at all if I know the caller is
>from an 800 number... or from some other list of people I don't care to talk to
>... I would love it if those guys had to wait 10 or 20 seconds between rings...
>that would be great!!
>>
>
>You know, you may just have stumbled upon the idea for the next "killer app" there.
>The Phone-URLRewrite-App :
>
><if>currentCall.caller.phoneNumber.matches(/^800.*/)</if>
> <then>currentCall.redirect(agenda.entry("mother-in-law").phoneNumber)</then>
>
I don't think she would mind. On the other hand, she could be volunteer to much info by being chatty. (good thing no one in my family reads this list...)
Re: [OT] Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
...
>
> [Way OT...]
> If you get this to work, then the next place you can take this idea is to the phone company. Why should my phone even ring at all if I know the caller is from an 800 number... or from some other list of people I don't care to talk to ... I would love it if those guys had to wait 10 or 20 seconds between rings... that would be great!!
>
You know, you may just have stumbled upon the idea for the next "killer app" there.
The Phone-URLRewrite-App :
<if>currentCall.caller.phoneNumber.matches(/^800.*/)</if>
<then>currentCall.redirect(agenda.entry("mother-in-law").phoneNumber)</then>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: André Warnier [mailto:aw@ice-sa.com]
>Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>HTTP/1.0" 404
>
>>
>> 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?
>>
>
>No, not at all. It would be nice but no.
>What I mean is that any 404 response should be handed off to one of these
>lightweight processes, so that the real useful process doesn't have to handle
>it.
>Of course some processing has already taken place to find out that the target
>resource of this URL does not exist and that responding with a 404 code is
>appropriate.
>But as soon as this is determined, the rest should be "sub-contracted" to a
>simple sidekick, which will do the 1 second wait and then send back the
>response on the connection and then close the connection.
>In the meantime, the real useful webserver process can be available to
>process the next request (which can be bogus again, but nothing to do about
>this). No need for this real valuable complex process to spend his own time
>waiting for 1 second, sending the 404, closing the connection etc..
>And we do not really care if this sidekick, 404-sending-only process has a
>backlog at some times, and sometimes takes longer than 1 second to finish off
>this 404 response, do we ?
No, I guess not.
>
>And..
>
If I'm understanding the point you are making, you're saying that delaying the 404 response slows down the ability of the bots to collect information. The bots will *still* collect data, it will just take them longer to get the list of possible exploits?
Not knowing anything about the history of the HTTP 404 method, if a server does not find a matching request URI, why was it decided that the protocol would even respond at all? Seems like the request could have just been ignored or dropped.
[Way OT...]
If you get this to work, then the next place you can take this idea is to the phone company. Why should my phone even ring at all if I know the caller is from an 800 number... or from some other list of people I don't care to talk to ... I would love it if those guys had to wait 10 or 20 seconds between rings... that would be great!!
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: André Warnier [mailto:aw@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:aw@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?
>
No, not at all. It would be nice but no.
What I mean is that any 404 response should be handed off to one of these lightweight
processes, so that the real useful process doesn't have to handle it.
Of course some processing has already taken place to find out that the target resource of
this URL does not exist and that responding with a 404 code is appropriate.
But as soon as this is determined, the rest should be "sub-contracted" to a simple
sidekick, which will do the 1 second wait and then send back the response on the
connection and then close the connection.
In the meantime, the real useful webserver process can be available to process the next
request (which can be bogus again, but nothing to do about this). No need for this real
valuable complex process to spend his own time waiting for 1 second, sending the 404,
closing the connection etc..
And we do not really care if this sidekick, 404-sending-only process has a backlog at some
times, and sometimes takes longer than 1 second to finish off this 404 response, do we ?
And..
>> But I am sure that the tomcat gurus here will have some good ideas for that
>> part.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: André Warnier [mailto:aw@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:aw@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.
>
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> On 4/17/13 1:27 PM, André Warnier wrote:
>> Leo Donahue - RDSA IT wrote:
>>>> -----Original Message----- From: André Warnier
>>>> [mailto:aw@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.
>
> Sounds like a DOS to me. What you really want to do is detect an
> attacker (or annoying client) and block them without having to use
> your own resources. Maintaining a socket connection for an extra
> second you don't otherwise have to do is using a resource, even if the
> CPU is entirely idle, and even if you can return the
> request-processing thread to the thread-pool before you wait that 1
> second to respond.
>
> What I describe above is a great case for using fail2ban (not sure if
> it exists in the Windows world): you watch a log file (e.g. access
> log) and lots of 404s coming from a single place and then ban them at
> the firewall-level. That's much more efficient than sleeping for a
> second for each 404.
>
> I'm sure you'll lock-out most web spiders pretty quickly, though ;)
>
Chris,
like the other people here who have pointed out better ways to protect their servers,
*you are right, and I agree with all you are saying*.
But one point that I am trying to make, in different ways because obviously it isn't
getting through, so I'll try again, is the following :
All the better ways and software and configurations that you point out are effective, and
better than just delaying 404 responses by 1 second.
*But they all require expertise, time and resources* to set up.
Which means that out of the 600 million webservers which are currently on-line, only a
small proportion will ever implement them.
Let's say that 20% of those webservers (100 million) implement one of these professional
schemes. That leaves 500 million webservers which don't, among which say 1% (5 million)
are really open to bot attacks via such URLs.
So right now, with a reasonable number of bots (100), I can scan 100,000 servers in 8
hours, and collect 1000 future break-in candidates and future bots for my net.
And this, *no matter how well the "professional" sites are configured*.
That is worth it, so I will run my 100 bots, and bother 100,000 servers (among which
yours, which is well-protected and doesn't care).
And then I will go to bed and when I wake up tomorrow morning, my list of 1000 real
targets will be ready to start probing further.
On the other hand, if 50% of the 500 million non-professional webservers, *because it is
simple and cheap and doesn't require any expertise or time or resources*, do delay each
404 by 1 s, then it takes my 100 bots 250 hours (12 days) to collect these 1000 targets.
And each day of these 12 days, instead 100,000 servers being bothered, 90,000 will have
been left alone, because I can only scan 10000 per 24h.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 4/17/13 1:27 PM, André Warnier wrote:
> Leo Donahue - RDSA IT wrote:
>>> -----Original Message----- From: André Warnier
>>> [mailto:aw@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.
Sounds like a DOS to me. What you really want to do is detect an
attacker (or annoying client) and block them without having to use
your own resources. Maintaining a socket connection for an extra
second you don't otherwise have to do is using a resource, even if the
CPU is entirely idle, and even if you can return the
request-processing thread to the thread-pool before you wait that 1
second to respond.
What I describe above is a great case for using fail2ban (not sure if
it exists in the Windows world): you watch a log file (e.g. access
log) and lots of 404s coming from a single place and then ban them at
the firewall-level. That's much more efficient than sleeping for a
second for each 404.
I'm sure you'll lock-out most web spiders pretty quickly, though ;)
- -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/
iQIcBAEBCAAGBQJRbt+yAAoJEBzwKT+lPKRY1+8P/3inLMorUT8mA2jG0u9whRVm
h20ypC+zDLAxEWM75IKkQCwGZKpAvhBbrasXVOEi+aBYLO7sSBW9PRn1PQibsWlW
taILaKnBf9dF5/ZX9yxjiYx+15WAhz5i7PnaQpPaebYqPa1Bm5S+UQsOQ6jEzAM2
eWouNmYL+3qpYlw0akR12b2fZ+x0l0NLbLRYvKi2ttKNwpX86yQOZ/xjuY6XMFfK
FOhzPMZ9NvoYLvnrA31w6gj+EFHkC1anaSpap2hAGTI5JSSIAk9vQyShH9jJd/yY
9agodQBkS4Z4qthD5WKOWvhsQoEKDufaFikPme70TwGnpB4URlRIl3O5h5UeQIHc
ktPiU7+N0kMMU5GS184dyMf99N1ILjxEM6Yp/56Iiy7Hahral1THNjlAz84kfUCA
7v5X3AkxffZmRrEzCOfYn3SZ971ylJnoNMtQ2acEFO6mCAvvoNur1yz0ZCDb7T+k
g96d/5MbXpbm64P+31fgce1w2iLQg+BogGgZzodvrzyZ1NA3i7EEPffUoRnGxw3x
bmf7ylqGD5cOHBal11BozTfOPkZfZmhvy2bVsys5jv6uZePXPA+7ijzJFCeIh2zC
xQNQLc8WxaXGlT8qUVDoTYBWw6DalE435wJPDmHik5j6FNlwDINfsda6IvJMYCgu
1Yfz70ESuJ8SwjH8iJhF
=C6iu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: André Warnier [mailto:aw@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 ?
(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.
But I am sure that the tomcat gurus here will have some good ideas for that part.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: André Warnier [mailto:aw@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?
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Pïd stèr wrote:
> On 16 Apr 2013, at 19:38, "André Warnier" <aw...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Pïd stèr <pi...@pidster.com>.
On 16 Apr 2013, at 19:38, "André Warnier" <aw...@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.
And only if the default setting is 'on'.
p
> Alternatively of course, still if there are no definite arguments against it, but the
> Tomcat developers are not interested, I could go to the Apache list anyway. And then they
> might be the first to introduce this great feature.
>
> Or maybe I'll just patent it, and then sell the patent to the makers of the third
> most-popular webserver..
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Pïd stèr <pi...@pidster.com>.
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.
p
>
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by chris derham <ch...@derham.me.uk>.
> 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
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Mark H. Wood wrote:
> On Mon, Apr 15, 2013 at 07:15:11PM +0200, André Warnier wrote:
>> Neven Cvetkovic wrote:
>>> How about creating a fake manager application :)))
>>>
>>> That takes X minutes/seconds to get back a 404 ;)))
> [snip]
>> Of course at the moment I am just fishing here for potential negative side-effects.
>
> Search for "tarpit". There should be a lot of discussion.
>
Thanks, that was a good tip. Amd me thinking I had an original idea here...
However, I will keep insisting on my main point : all the tools which I have read about so
far are great, and much more sophisticated than my crude 404-delay proposal. But they all
require additional components, and quite a bit of dedication and expertise, in order to
take advantage of them. And, when installed somewhere, they only protect the systems on
which they are installed.
Which, given the relative complexity of doing so, is likely to remain a small proportion
of webservers on the www.
Which still leaves it "economical" for these scanning bots to keep scanning, because they
will still find enough vulnerable servers within a reasonable amount of time spent scanning.
After all, these tools have existed for a while already, and my servers are still being
scanned every day, so it must still be worthwhile to do so, right ?
My point is that if this were really simple to install (such as installed by default, and
optionally disabled) then over time a large proportion of webservers would implement the
scheme, and this would make it uneconomical for these bot scanners to scan, because it
would take a prohibitive amount of time and/or resources, compared to the number of
vulnerable servers to be discovered.
And then, because it would be uneconomical, one might hope that this line of attack would
just disappear. And then *all* servers would benefit, even the ones which have never been
"vaccinated" in the first place.
In order to determine the potential benefits or pitfalls of something like this, it is
often useful to make some back-of-the-envelope calculations, to get a rough idea.
I have done so, and although there is probably much to criticise in my methodology, the
results tend to suggest something like this :
- given a bot that scans 100,000 IP addresses to try to find servers running webservers
which have one of these vulnerabilities, with a guessed 2500 such vulnerable servers among
them :
- without a delay on the 404 responses, it would take this bot about 2 1/2 hours to
find the 2500 vulnerable servers among the original 100,000 IP addresses
- with a 1 s delay for 404 responses, it would take that same bot 93 hours for the same
result
That is 40 times longer.
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.
In other words, now 39 of each 40 servers would be left alone, whether they implement the
404 delay or not.
I am willing to submit my calculations for criticism or demolition. But it seems to me
that the kind of numbers above should at least warrant some interest from the
powers-that-be, for a parameter that might be as simple as
<Connector delay404="1000" ...>
(of course, I am not talking about the implementation)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Mon, Apr 15, 2013 at 07:15:11PM +0200, André Warnier wrote:
> Neven Cvetkovic wrote:
> > How about creating a fake manager application :)))
> >
> > That takes X minutes/seconds to get back a 404 ;)))
[snip]
> Of course at the moment I am just fishing here for potential negative side-effects.
Search for "tarpit". There should be a lot of discussion.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Machines should not be friendly. Machines should be obedient.
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Neven Cvetkovic wrote:
> How about creating a fake manager application :)))
>
> That takes X minutes/seconds to get back a 404 ;)))
>
Just for the sake of the discussion :
- a fake manager application would apply to just the /manager webapp, not to other
potential hacking targets, no ? (or you would have to "map" it to any potential hacking
URL, which may be inconvenient). Also, you'd have to duplicate this webapp in any
configured <Host>.
- the fact that it is a genuine webapp would mean that during the delay before the 404
response, at least one tomcat thread remains blocked executing that application, for each
such request. I was thinking more in the direction of off-loading such 404 responses to
some specialised lightweight thread, using as little resources as possible. It wouldn't
really matter if there is a queue of such responses waiting to happen, as they just delay
the eventual response to the (miscreant) client(s).
More ideas ?
P.S. I'd love to see this as a standard Tomcat feature, because it would mean that within
a certain time period, thousands and thousands of Tomcat servers on the Internet would
become annoying for these hacking programs. If it was a webapp that everyone has to
deploy on individual tomcat servers optionally, it would be much less effective, I think.
Of course at the moment I am just fishing here for potential negative side-effects.
Provided the idea makes sense however, I believe that I would also post it on the Apache
httpd list. If it was adopted there also somehow, that could have quite a global impact.
One potential negative side-effect that I can see, is on one of my own programs (or
similar ones) : for some customers, I created a "URL checker" program, which goes through
their databases looking for third-party links, and gives them a list of the ones that are
not working (so that they can correct their data). Of course if all webservers on the web
implemented my idea, then it would take much longer for this genuine utility program to
run, because it would experience an extra delay for each incorrect URL (in case the host
is correct, but the URL on that server is not).
I'm also quite sure that Google won't really like the idea..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Neven Cvetkovic <ne...@gmail.com>.
How about creating a fake manager application :)))
That takes X minutes/seconds to get back a 404 ;)))
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
In what I believe to be related anough to the subject of the original post, I would like
to float a proposal, to make life a bit harder for these automated hackers.
By personal observation, I note that many such attempts (the large majority in fact) end
up requesting URLs which do not exist on properly-configured servers, and thus ultimately
result in a "404 Not Found" response.
It is also the interest of these annoying tools to be able to scan as many IP addresses
and ports as possible, within as short a time as possible, in order to locate vulnerable
targets faster.
But nevertheless, they cannot use too short a timeout for each of these URLs that they
request, otherwise they would end up neglecting a lot of juicy targets whenever their own
network connection (or the target's) is a bit slow.
On the other hand, I would suppose that legitimate well-written applications rarely
deliver responses containing links that will, when used, result in 404 responses.
So why not insert an optional parameter into Tomcat somewhere, which would have the effect
of delaying any "404 Not Found" response by a few (configurable) seconds ?
I am quite sure that if this was done cleverly, its impact on the server's own load could
be minimised, and it would greatly annoy those miscreants, by forcing them to wait n times
longer for each unsuccesful attempt. No ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by André Warnier <aw...@ice-sa.com>.
Pid wrote:
> On 15/04/2013 11:36, Esmond Pitt wrote:
>> When you quote me in refutation, kindly quote *all* and *only* the parts
>> that are relevant. You have now made both mistakes in succession. I hid the
>> Tomcat behind an HTTPD on port 80, closed port 8080, and made the Tomcat
>> listen on 127.0.0.x only. A TCP socket that listens on 127.0.0.1 cannot be
>> connected to from outside the localhost. That's not 'security by obscurity',
>> that's security via a well-known feature of TCP.
>
>
> Kindly don't top post.
>
> I replied to a thread, it's quite normal to use context from prior
> messages in the thread. I am clearly replying in the context of the thread.
>
>
>> It is in effect a firewall.
>
> It is not a firewall. It is a reverse proxy.
>
>
>> 127.0.0.x for Tomcat protects it completely.
>
> No it doesn't, for a number of reasons, not least of which being that
> you're still sending traffic to it from the network.
>
>
>
> I believe you are missing my point, or choosing not to address it.
>
> A client makes a connection to a server through a succession of devices,
> each of which is forwarding the TCP traffic to the next device. Simply
> adding another entry to that pipeline that only performs the same job of
> forwarding traffic onto another port (local or otherwise) does not
> provide an improvement in security.
>
> So even if Tomcat only listens on a localhost socket, when you provide a
> means for other devices to connect to it from the network without
> intercepting that traffic to check it is safe, you are entirely negating
> the security benefit you postulate.
>
>
> I think that the attack you referred to would still have occurred even
> with your new 'security' if a) the manager app remained visible to the
> outside world and b) you left the password as it was.
>
> You fixed your problem by either preventing access to the Manager from
> the outside world (perhaps by a mod_jk/mod_proxy_ajp mapping) or by
> changing the noddy password you were using; You did not fix it by
> 'hiding' Tomcat itself or removing traffic from port 8080.
>
>
> I'm persisting in this point because I don't want other users to
> continue believing the fallacy that 'hiding' Tomcat behind Apache HTTPD
> alone improves their security.
>
>
> p
>
>
>> EJP
>> -----Original Message-----
>> From: Pid [mailto:pid@pidster.com]
>> Sent: Monday, 15 April 2013 8:25 PM
>> To: Esmond Pitt
>> Cc: 'Tomcat Users List'
>> Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>> HTTP/1.0" 404
>>
>> On 15/04/2013 03:51, Esmond Pitt wrote:
>>>>> I agree with your comment. Adding a second box for Tomcat only means
>>>>> I also have to configure a firewall between them, whereas using
>>>>> 127.0.0.x for Tomcat protects it completely.
>>>> No it doesn't!
>>>> Obfuscation or indirection != security.
>>>> HTTPD doesn't magically provide you with some extra security capability.
>>> I don't know what you're talking about. I didn't mention HTTPD in the
>>> message you quoted. I mentioned 127.0.0.x, and it does exactly what I
>>> said it does. There is no 'security via obscurity' here, just a
>>> well-known TCP mechanism.
>> I quote:
>>
>>> We:
>>>
>>> - Hid the Tomcat behind an Apache HTTPD on port 80.
>> You used the word 'hid'.
>>
>> ob.scure
>> Adjective
>> Not discovered or known about; uncertain.
>> Verb
>> Keep from being seen; conceal.
>>
>> Security via obscurity.
>>
>>
>>> - Closed port 8080, indeed removed all the HTTP Connectors from Tomcat
>>> and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on
>>> the same port for simplicity, so there is no zero direct access to
>>> Tomcat from the outside
>> I am objecting to the above as being an improvement on two counts:
>>
>> 1. the phrase 'direct access' has no meaning here
>>
>> 2. Tomcat still processes the bytes received from the client with no prior
>> inspection or validation of their safety.
>>
>>
>>> - Configured Apache HTTPD for LDAP authentication via an OpenLDAP
>>> server that in turn is configured via the Password Policy overlay for
>>> finite (5 I
>>> think) password retries before locking out the account
>>> - required a very restricted LDAP group membership for access to
>>> /manager (and the other Tomcat builtins).
>> So you secured the Manager app, rather than use a password that could be
>> guessed.
>>
>>
>>> No recurrence, not even an attempt. I think actually closing port 8080
>>> may have played the biggest part in all this.
>> No it didn't. Using a password that couldn't be guessed did.
>>
>>
Maybe to bridge both interpretations here, and smooth the discussion a bit :
In his original post, Esmond listed 5 points which *together* increased security for the
access to the Manager application. And, as explained, they do.
However, in subsequent comments he also seemed to imply that putting httpd in front of
Tomcat, and restricting Tomcat access so that it could only be accessed through httpd, was
in itself a security feature and a "firewall". That is not the case, and that was what
Pid objected to, as potentially able to confuse naive readers on this list.
Esmond also mentioned that simply changing the port through which Tomcat was being
accessed, also helped.
That is not in itself strictly true, but there is an element of truth in it : many of
those "automatic hacking tools" seem to work as follows :
- try some random (or less random) IP address, to see if it answers a "ping"
- if it does, then they will try to connect to a range of "well-know ports" on that IP
address, and on each of these well-known ports (corresponding to the standard setup of a
range of "well-know servers"), try for a series of "well-known weaknesses".
- if none of that works, they will give up and go look for more promising targets
So for example,
- port 22 will be tried for an SSH connection, using a range of "well-known
userid/password combinations" (root/root,root/admin,admin/admin,phpadmin/admin,etc..)
- port 23 will be tried similarly for a telnet connection
- port 80 will be tried with a series of HTTP requests to URLs such as /vti_bin/*,
/phpmyadmin, /sqladmin, /cgi-bin/admin, etc.. (about 50 more of those)
- port 8080 (which happens to be the standard port for HTTP in the tomcat
"factory-standard" server.xml) will be tried for the URL /manager.html (because at some
distant moment in the past, there used to be a weakness there in the factory-standard
tomcat distribution)(it was plugged a long time ago, but hey there are probably still lots
of sites running very outdated versions of tomcat, so why not try ?)
(note that generally port 80 will not be tried for the same URL, because usually port 80
is occupied by Apache httpd or IIS, which do not have a "manager" application).
There are millions of IP addresses, and each one has potentially thousands of ports open.
So these scanning programs cannot spend a lot of time on each combination, and they do at
least a first pass on the most promising ones, and if that doesn't work, they give up and
try the next IP address in their list, after putting this one on some "black-list" of
their own, so that they will not spend valuable time scanning it again.
(Unless of course this IP address is particularly attractive for some reason..)
So, in a way, having Tomcat /not/ answering directly on the Internet on port 8080
diminishes the hacking attempts, and /can/ contribute to the server's security, if only by
making these automated hacking programs give up faster.
The above is not a definitive or complete set of guidelines; it is merely some behaviour
that I have observed in my own job as a sysadmin for a few internet servers. None of
these servers is in principle a very attractive hacking target (I mean, I do not run
banking servers or Facebook or anything like it). But nevertheless, each of these servers
is submitted daily to dozens of such "hacking attempts". That's because gaining control
of even a by-itself unattractive server would allow someone to use it afterward to try to
hack into more attractive servers and disguise where the attack comes from.
What I am trying to say with all of that, is
- there is nothing very special about noticing such hacking attempts in your webserver log
files. They are just a fact of life on the Internet.
- you should make sure that you regularly look at your logs, to detect new forms of such
attempts. Remember also that the really dangerous ones are the ones that succeed, not the
ones that fail.
- you should always consider *all* the web applications that you allow access to, in terms
of security. No URL request should ever be considered as "safe" per se. Any of them can be
coming from one of these programs, not just from a standard browser. So whatever things
that a standard browser won't do, one of these programs just will ("invalid" URLs,
weirdly-encoded URLs, extra-long URLs, etc.). In other words : "/manager.html" is
certainly a hacking target, but it is a well-know one, and one that a lot of people have
given careful attention to, to make it secure. But what about your "/myapp" or your "/demo" ?
- there is not only HTTP accesses to worry about. Any port that is open to the Internet
is potentially an entry for these programs. So all that stuff about choosing non-obvious
passwords is annoying, but important. Over time, the "root" account will be tried with
hundreds of different passwords (so do not use root123, qwerty, azerty, secret, etc..
unless you really want to be hacked).
- as soon as someone gains entry into your server in any of the ways above, their first
task will probably be to discretely install another dozen of alternative entry points into
your system, just in case you noticed and plugged this one.
It is all fairly frustrating, particularly when you think that you are ultimately paying
for the bandwidth and CPU cycles consumed by these hacking attempts.
But at the same time, a relatively simple set of measures can greatly diminish these
attempts, and there is certainly no reason to make life easier for them.
I hope that the above already gives someone some ideas about this.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Mon, Apr 15, 2013 at 7:49 AM, Pid <pi...@pidster.com> wrote:
>
> I'm persisting in this point because I don't want other users to
> continue believing the fallacy that 'hiding' Tomcat behind Apache HTTPD
> alone improves their security.
>
>
And your persistence is appreciated, and I definitely appreciate all the
responses/discussion. :)
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Pid <pi...@pidster.com>.
On 15/04/2013 11:36, Esmond Pitt wrote:
> When you quote me in refutation, kindly quote *all* and *only* the parts
> that are relevant. You have now made both mistakes in succession. I hid the
> Tomcat behind an HTTPD on port 80, closed port 8080, and made the Tomcat
> listen on 127.0.0.x only. A TCP socket that listens on 127.0.0.1 cannot be
> connected to from outside the localhost. That's not 'security by obscurity',
> that's security via a well-known feature of TCP.
Kindly don't top post.
I replied to a thread, it's quite normal to use context from prior
messages in the thread. I am clearly replying in the context of the thread.
> It is in effect a firewall.
It is not a firewall. It is a reverse proxy.
> 127.0.0.x for Tomcat protects it completely.
No it doesn't, for a number of reasons, not least of which being that
you're still sending traffic to it from the network.
I believe you are missing my point, or choosing not to address it.
A client makes a connection to a server through a succession of devices,
each of which is forwarding the TCP traffic to the next device. Simply
adding another entry to that pipeline that only performs the same job of
forwarding traffic onto another port (local or otherwise) does not
provide an improvement in security.
So even if Tomcat only listens on a localhost socket, when you provide a
means for other devices to connect to it from the network without
intercepting that traffic to check it is safe, you are entirely negating
the security benefit you postulate.
I think that the attack you referred to would still have occurred even
with your new 'security' if a) the manager app remained visible to the
outside world and b) you left the password as it was.
You fixed your problem by either preventing access to the Manager from
the outside world (perhaps by a mod_jk/mod_proxy_ajp mapping) or by
changing the noddy password you were using; You did not fix it by
'hiding' Tomcat itself or removing traffic from port 8080.
I'm persisting in this point because I don't want other users to
continue believing the fallacy that 'hiding' Tomcat behind Apache HTTPD
alone improves their security.
p
> EJP
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Monday, 15 April 2013 8:25 PM
> To: Esmond Pitt
> Cc: 'Tomcat Users List'
> Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
> HTTP/1.0" 404
>
> On 15/04/2013 03:51, Esmond Pitt wrote:
>>
>>>> I agree with your comment. Adding a second box for Tomcat only means
>>>> I also have to configure a firewall between them, whereas using
>>>> 127.0.0.x for Tomcat protects it completely.
>>
>>> No it doesn't!
>>> Obfuscation or indirection != security.
>>> HTTPD doesn't magically provide you with some extra security capability.
>>
>> I don't know what you're talking about. I didn't mention HTTPD in the
>> message you quoted. I mentioned 127.0.0.x, and it does exactly what I
>> said it does. There is no 'security via obscurity' here, just a
>> well-known TCP mechanism.
>
> I quote:
>
>> We:
>>
>> - Hid the Tomcat behind an Apache HTTPD on port 80.
>
> You used the word 'hid'.
>
> ob.scure
> Adjective
> Not discovered or known about; uncertain.
> Verb
> Keep from being seen; conceal.
>
> Security via obscurity.
>
>
>> - Closed port 8080, indeed removed all the HTTP Connectors from Tomcat
>> and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on
>> the same port for simplicity, so there is no zero direct access to
>> Tomcat from the outside
>
> I am objecting to the above as being an improvement on two counts:
>
> 1. the phrase 'direct access' has no meaning here
>
> 2. Tomcat still processes the bytes received from the client with no prior
> inspection or validation of their safety.
>
>
>> - Configured Apache HTTPD for LDAP authentication via an OpenLDAP
>> server that in turn is configured via the Password Policy overlay for
>> finite (5 I
>> think) password retries before locking out the account
>> - required a very restricted LDAP group membership for access to
>> /manager (and the other Tomcat builtins).
>
> So you secured the Manager app, rather than use a password that could be
> guessed.
>
>
>> No recurrence, not even an attempt. I think actually closing port 8080
>> may have played the biggest part in all this.
>
> No it didn't. Using a password that couldn't be guessed did.
>
>
> p
>
>
>
>
>
--
[key:62590808]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Posted by Esmond Pitt <es...@bigpond.com>.
When you quote me in refutation, kindly quote *all* and *only* the parts
that are relevant. You have now made both mistakes in succession. I hid the
Tomcat behind an HTTPD on port 80, closed port 8080, and made the Tomcat
listen on 127.0.0.x only. A TCP socket that listens on 127.0.0.1 cannot be
connected to from outside the localhost. That's not 'security by obscurity',
that's security via a well-known feature of TCP. It is in effect a firewall.
EJP
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Monday, 15 April 2013 8:25 PM
To: Esmond Pitt
Cc: 'Tomcat Users List'
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
On 15/04/2013 03:51, Esmond Pitt wrote:
>
>>> I agree with your comment. Adding a second box for Tomcat only means
>>> I also have to configure a firewall between them, whereas using
>>> 127.0.0.x for Tomcat protects it completely.
>
>> No it doesn't!
>> Obfuscation or indirection != security.
>> HTTPD doesn't magically provide you with some extra security capability.
>
> I don't know what you're talking about. I didn't mention HTTPD in the
> message you quoted. I mentioned 127.0.0.x, and it does exactly what I
> said it does. There is no 'security via obscurity' here, just a
> well-known TCP mechanism.
I quote:
> We:
>
> - Hid the Tomcat behind an Apache HTTPD on port 80.
You used the word 'hid'.
ob.scure
Adjective
Not discovered or known about; uncertain.
Verb
Keep from being seen; conceal.
Security via obscurity.
> - Closed port 8080, indeed removed all the HTTP Connectors from Tomcat
> and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on
> the same port for simplicity, so there is no zero direct access to
> Tomcat from the outside
I am objecting to the above as being an improvement on two counts:
1. the phrase 'direct access' has no meaning here
2. Tomcat still processes the bytes received from the client with no prior
inspection or validation of their safety.
> - Configured Apache HTTPD for LDAP authentication via an OpenLDAP
> server that in turn is configured via the Password Policy overlay for
> finite (5 I
> think) password retries before locking out the account
> - required a very restricted LDAP group membership for access to
> /manager (and the other Tomcat builtins).
So you secured the Manager app, rather than use a password that could be
guessed.
> No recurrence, not even an attempt. I think actually closing port 8080
> may have played the biggest part in all this.
No it didn't. Using a password that couldn't be guessed did.
p
--
[key:62590808]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Pid <pi...@pidster.com>.
On 15/04/2013 03:51, Esmond Pitt wrote:
>
>>> I agree with your comment. Adding a second box for Tomcat only means I
>>> also have to configure a firewall between them, whereas using
>>> 127.0.0.x for Tomcat protects it completely.
>
>> No it doesn't!
>> Obfuscation or indirection != security.
>> HTTPD doesn't magically provide you with some extra security capability.
>
> I don't know what you're talking about. I didn't mention HTTPD in the
> message you quoted. I mentioned 127.0.0.x, and it does exactly what I said
> it does. There is no 'security via obscurity' here, just a well-known TCP
> mechanism.
I quote:
> We:
>
> - Hid the Tomcat behind an Apache HTTPD on port 80.
You used the word 'hid'.
ob·scure
Adjective
Not discovered or known about; uncertain.
Verb
Keep from being seen; conceal.
Security via obscurity.
> - Closed port 8080, indeed removed all the HTTP Connectors from Tomcat and
> just used AJP connectors running on 127.0.0.1/2/3/4/..., all on the same
> port for simplicity, so there is no zero direct access to Tomcat from the
> outside
I am objecting to the above as being an improvement on two counts:
1. the phrase 'direct access' has no meaning here
2. Tomcat still processes the bytes received from the client with no
prior inspection or validation of their safety.
> - Configured Apache HTTPD for LDAP authentication via an OpenLDAP server
> that in turn is configured via the Password Policy overlay for finite (5 I
> think) password retries before locking out the account
> - required a very restricted LDAP group membership for access to /manager
> (and the other Tomcat builtins).
So you secured the Manager app, rather than use a password that could be
guessed.
> No recurrence, not even an attempt. I think actually closing port 8080 may
> have played the biggest part in all this.
No it didn't. Using a password that couldn't be guessed did.
p
--
[key:62590808]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Posted by Esmond Pitt <es...@bigpond.com>.
>> I agree with your comment. Adding a second box for Tomcat only means I
>> also have to configure a firewall between them, whereas using
>> 127.0.0.x for Tomcat protects it completely.
> No it doesn't!
> Obfuscation or indirection != security.
> HTTPD doesn't magically provide you with some extra security capability.
I don't know what you're talking about. I didn't mention HTTPD in the
message you quoted. I mentioned 127.0.0.x, and it does exactly what I said
it does. There is no 'security via obscurity' here, just a well-known TCP
mechanism.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Pïd stèr <pi...@pidster.com>.
On 13 Apr 2013, at 03:33, Esmond Pitt <es...@bigpond.com> wrote:
> I agree with your comment. Adding a second box for Tomcat only means I also
> have to configure a firewall between them, whereas using 127.0.0.x for
> Tomcat protects it completely.
No it doesn't!
Obfuscation or indirection != security.
HTTPD doesn't magically provide you with some extra security capability.
p
>
> -----Original Message-----
> From: Pïd stèr [mailto:pid@pidster.com]
> Sent: Saturday, 13 April 2013 3:54 AM
> To: Tomcat Users List
> Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
> HTTP/1.0" 404
>
> On 11 Apr 2013, at 21:36, Christopher Schultz <ch...@christopherschultz.net>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Esmond,
>>
>> On 4/10/13 8:21 PM, Esmond Pitt wrote:
>>> We had lots of these and finally an attack last year on a Tomcat
>>> where the manager password somehow hadn't been changed.
>>
>> Note that the manager webapp has no default passwords, so I wonder
>> what you mean when you say it "hadn't been changed". There are
>> examples in conf/tomcat-users.xml but they are all commented-out.
>>
>> You would have had to intentionally enable the "default" password.
>>
>>> The attacker installed a viral servlet application that killed the
>>> server completely, we had to rebuild it.
>>
>> I -- like most people I would guess -- don't run under a
>> SecurityManager, but doing so can significantly limit the damage that
>> a rogue webapp can do.
>>
>>> We:
>>>
>>> - Hid the Tomcat behind an Apache HTTPD on port 80.
>>
>> Did you also remove manager webapp access through httpd? Otherwise,
>> this doesn't actually do anything to help.
>>
>>> - Closed port 8080, indeed removed all the HTTP Connectors from
>>> Tomcat and just used AJP connectors running on 127.0.0.1/2/3/4/...,
>>> all on the same port for simplicity, so there is no zero direct
>>> access to Tomcat from the outside
>>
>> +1, though I would run Apache httpd and Tomcat on different hosts, so
>> localhost-binding is not possible unless you are doing something like
>> stunnel (which also might be a good idea if you are traversing an
>> untrusted network).
>
> Respectfully, I have to disagree. Unless the Apache HTTPD is loaded with IDS
> that can sniff the inbound traffic, you've not achieved much, and now you
> have two boxes that have to be maintained, secured & patched. HTTPD !=
> firewall.
>
>
> p
>
>
>>
>>> - Configured Apache HTTPD for LDAP authentication via an OpenLDAP
>>> server that in turn is configured via the Password Policy overlay for
>>> finite (5 I think) password retries before locking out the account
>>
>> +2 -- both good ideas: central access control (LDAP) and enabling
>> lockout mechanism. Note that Tomcat's lockout mechanism is fairly
>> primitive and easy to game.
>>
>>> - required a very restricted LDAP group membership for access to
>>> /manager (and the other Tomcat builtins).
>>
>> +1 hooray for role-based permissions!
>>
>>> No recurrence, not even an attempt. I think actually closing port
>>> 8080 may have played the biggest part in all this.
>>
>> Would you be willing to review the Tomcat documentation on "securing
>> Tomcat" and make a few comments? It could always use some additional tips:
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html
>> http://wiki.apache.org/tomcat/FAQ/Security
>>
>> You can sign-up for the wiki yourself and make any changes you want.
>> If you want to modify the "official" documentation, create a Bugzilla
>> enhancement request and (please!) include a patch. I'm sure it will go
>> right in.
>>
>> Thanks,
>> - -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/
>>
>> iQIcBAEBCAAGBQJRZx7AAAoJEBzwKT+lPKRY+3MP/3c8kZZU43cMaxkXTi/ELXha
>> Hv6rAeGz4nnpMNn2C002cTRgZ39vomUXYdsLMnNIshn05JDVIZmLLoUXk6UzY9go
>> uH0QdAubBxhvwC/CWeLjUuSjy/Ei4vKeB7xJNw/FQ2xXEt47FWv36e0vgxOyluX+
>> gbkB3KQlN6PXtQENGvkOGT5oWLK9M7WUydGSWq9lXR+akwWeL3jWRAlLl6bHYybQ
>> n70c5wq/rJbEj+k9yCHsMZvPabYs5ejsz6wHvvw4Emrxcp4LVVjCuY2Z87Yhdtb4
>> B43tF48be9GUZCXDvtIjiS5phHMhpqyJakHuZ7GSvzDIeuiNZ96XuoDkIG1bwWjf
>> Z5SMCSjkSPqDKJ1cXcd8AaSYgI2C3KQnuFrbTD7bVqQHOeq7RJZp3+xE0IUNPl+V
>> H2PNpUfXD9BDbPiiDt8bcgvcrImejW0RDumQ2fwbTVvt4OaybVsMUsVFW8lUtw3A
>> YhvFn/WCEdR8VaY9PkqYm84BVMsQJBbBdb5clYiAtVQRky1NPS+hcIihnf85DkNU
>> vr6rv/oK0aMXAamwUagmRe5OjTHuHczERPYgEUMpppnlXuNV1mLxBib8+HInGg3/
>> Y5i28tTd7fS5uo7/CZv+9uEZdDUO7utWGT0W+gBaIkh35/yZI5a1l5wi0szYduQe
>> t3nftQXUTCYtK1QNwKND
>> =3s6Q
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Pid <pi...@pidster.com>.
On 15/04/2013 16:11, Mark Eggers wrote:
> On 4/15/2013 3:19 AM, Pid wrote:
>> On 15/04/2013 00:03, Christopher Schultz wrote:
>>> Pid,
>>>
>>> On 4/12/13 1:54 PM, Pïd stèr wrote:
>>>> On 11 Apr 2013, at 21:36, Christopher Schultz
>>>> <ch...@christopherschultz.net> wrote:
>>>>> [...] though I would run Apache httpd and Tomcat on different
>>>>> hosts, so localhost-binding is not possible unless you are doing
>>>>> something like stunnel (which also might be a good idea if you
>>>>> are traversing an untrusted network).
>>>
>>>> Respectfully, I have to disagree. Unless the Apache HTTPD is
>>>> loaded with IDS that can sniff the inbound traffic, you've not
>>>> achieved much, and now you have two boxes that have to be
>>>> maintained, secured & patched. HTTPD != firewall.
>>>
>>> While httpd != firewall, it's traditional to allow external-access to
>>> your web server but not your app servers (databases, etc.). That means
>>> that external threats can only directly-attack the web server.
>>
>> Respectfully, this is clearly not true if you are just passing traffic
>> to the app server. An attack that compromises the application server in
>> the way described above would still be effective regardless of the
>> presence of HTTPD.
>>
>> The risk I perceive is that users think that simply installing HTTPD
>> somehow improves their security, when it does not.
>>
>
> I guess we first need to agree what is meant by compromised. If you mean
> application-level compromise, then absolutely. Simply adding Apache
> HTTPD, multiple systems, firewalls with carefully crafted holes to allow
> proxying does little (possibly nothing?) to improve security.
>
> If you mean OS-level compromise (administrative access on a target
> machine), then these techniques can improve security.
> Of course, the
> security that this provides depends almost entirely on the underlying
> architecture and little on the fact that you're fronting Tomcat with HTTPD.
>
> One possible improvement in security afforded by running Tomcat behind
> HTTPD is the use of mod_security. While mod_security impacts performance
> and doesn't catch everything (currently JSON support is not at all
> good), it will help as a part of a systems security architecture.
>
> This turns Apache HTTPD into an IDS, which was mentioned a bit ago in
> this thread.
(By me!)
Agreed, adding mod_security could provide a reason to use HTTPD in front.
>> The 'traditional' approach in these matters needs close scrutiny IMO.
>> People can't afford to rely on received wisdom for security and forget
>> more important basics such as regular patching.
>>
>
> Regular patching, regular auditing of logs, regular testing, keep up on
> the relevant technology mailing lists. I really do not like the
> (prevalent?) attitude of "if it aint broke, don't patch it".
> Well-architected systems don't (shouldn't) break when you patch
> components. If you find a lot of breakage, then you're looking at
> tightly coupled systems - in almost every case this is a Bad Thing (IMHO).
>
>> I regularly debate this with customers and we usually agree/find a
>> better approach.
>>
>>
>>> Obviously, suffering a web server break-in sucks, but at least the
>>> attacker then needs to break-into the application server after that.
>>
>> Why would they bother if they can attack the applications directly
>> anyway?
>>
>
> Again, this depends on the target. If by breaking the application you
> gain control of the application server or obtain PII (personally
> identifiable information), then this may be all that's desired.
Look at the typical attack patterns described as being prevalent today,
they are mass-produced, automated scripts probing IP after IP. They are
not a single guy in a dark room working a keyboard.
They are going for the LCD, for which the most part is unpatched
systems. The zero-day vulnerabilities are saved for high-value targets
and the occasional publicity generating show off.
Most frequently they are just probing IP ranges and it's not *you*
that's being targeted specifically, the attacker just wants to add
another machine for their botnet.
> If you desire a beachhead to investigate / crack the target further,
> then usually OS-level access (and often, a privileged account) is needed.
Yes, (assuming they are attacking you deliberately), to get this they
will not attack your website, they will attempt to compromise your
employees, starting with someone who is not IT literate & getting them
to open an email attachment that looks like it comes from a colleague.
p
>>> If it's a one-box wonder, you've been owned in a one fell swoop.
>>
>> A bit like this one, then.
>>
>>
>>> Also, running a heterogeneous environment can thwart attackers who
>>> have some kind of zero-day that got them into the web server (e.g.
>>> running httpd on Linux). Then they try the app server and surprise!
>>> It's NetBSD and they have to stop and find another attack to proceed.
>>
>> This is of course possible, but in practice quite rare.
>>
>
> Agreed, operations likes same-ol', same-ol'. Running completely
> different architectures on different layers is usually not seen, unless
> the architecture has grown organically. If the infrastructure
> architecture has been grown organically, then there are likely other
> systemic problems.
>
>>
>> p
>>
>>
>>
>>> -chris
>
> As mentioned earlier in this thread, I don't see the penchant for making
> the manager application internet-accessible. Sooner or later this can
> bite you hard.
>
> Setting up a VPN using OpenVPN is not that difficult. It's a little more
> difficult using two-factor authentication (PIN card plus certificate),
> but still doable.
>
> Then, set up a limited second connector HTTP connector (not many
> threads) to serve your manager application.
>
> Now you have a little more security.
>
> 1. Something you have (certificate)
> 2. Something you know (possible PIN, possible password on certificate)
> 3. Another something you know (how to access the manager application)
> 4. Reasonably secure (depending on how you set up OpenVPN) access
> 5. Audit trail (OpenVPN logs, manager logs)
> 6. Revocation ability (revoke OpenVPN certs, change manager access)
>
> Add Apache HTTPD in front with mod_security (or another IDS
> environment), and you've probably made life measurably more difficult
> for the would-be cracker.
>
> Would I manage a Tomcat from a coffee shop with this set up? Probably
> not. Is this a reasonable approach for the telecommute person? Probably so.
>
> Please note that I am NOT a security architect (nor do I play one on the
> Internet). I'm just a beleaguered systems architect that tries to find a
> balance between the security-by-formula people versus ease-of-use versus
> operations versus end user functionality. I feel that it's probably a
> zero-sum game, but I guess I like hitting my head against brick walls.
>
> . . . off to go find more brick walls
> /mde/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
[key:62590808]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Mark Eggers <it...@yahoo.com>.
On 4/15/2013 3:19 AM, Pid wrote:
> On 15/04/2013 00:03, Christopher Schultz wrote:
>> Pid,
>>
>> On 4/12/13 1:54 PM, Pïd stèr wrote:
>>> On 11 Apr 2013, at 21:36, Christopher Schultz
>>> <ch...@christopherschultz.net> wrote:
>>>> [...] though I would run Apache httpd and Tomcat on different
>>>> hosts, so localhost-binding is not possible unless you are doing
>>>> something like stunnel (which also might be a good idea if you
>>>> are traversing an untrusted network).
>>
>>> Respectfully, I have to disagree. Unless the Apache HTTPD is
>>> loaded with IDS that can sniff the inbound traffic, you've not
>>> achieved much, and now you have two boxes that have to be
>>> maintained, secured & patched. HTTPD != firewall.
>>
>> While httpd != firewall, it's traditional to allow external-access to
>> your web server but not your app servers (databases, etc.). That means
>> that external threats can only directly-attack the web server.
>
> Respectfully, this is clearly not true if you are just passing traffic
> to the app server. An attack that compromises the application server in
> the way described above would still be effective regardless of the
> presence of HTTPD.
>
> The risk I perceive is that users think that simply installing HTTPD
> somehow improves their security, when it does not.
>
I guess we first need to agree what is meant by compromised. If you mean
application-level compromise, then absolutely. Simply adding Apache
HTTPD, multiple systems, firewalls with carefully crafted holes to allow
proxying does little (possibly nothing?) to improve security.
If you mean OS-level compromise (administrative access on a target
machine), then these techniques can improve security. Of course, the
security that this provides depends almost entirely on the underlying
architecture and little on the fact that you're fronting Tomcat with HTTPD.
One possible improvement in security afforded by running Tomcat behind
HTTPD is the use of mod_security. While mod_security impacts performance
and doesn't catch everything (currently JSON support is not at all
good), it will help as a part of a systems security architecture.
This turns Apache HTTPD into an IDS, which was mentioned a bit ago in
this thread.
> The 'traditional' approach in these matters needs close scrutiny IMO.
> People can't afford to rely on received wisdom for security and forget
> more important basics such as regular patching.
>
Regular patching, regular auditing of logs, regular testing, keep up on
the relevant technology mailing lists. I really do not like the
(prevalent?) attitude of "if it aint broke, don't patch it".
Well-architected systems don't (shouldn't) break when you patch
components. If you find a lot of breakage, then you're looking at
tightly coupled systems - in almost every case this is a Bad Thing (IMHO).
> I regularly debate this with customers and we usually agree/find a
> better approach.
>
>
>> Obviously, suffering a web server break-in sucks, but at least the
>> attacker then needs to break-into the application server after that.
>
> Why would they bother if they can attack the applications directly anyway?
>
Again, this depends on the target. If by breaking the application you
gain control of the application server or obtain PII (personally
identifiable information), then this may be all that's desired.
If you desire a beachhead to investigate / crack the target further,
then usually OS-level access (and often, a privileged account) is needed.
>
>> If it's a one-box wonder, you've been owned in a one fell swoop.
>
> A bit like this one, then.
>
>
>> Also, running a heterogeneous environment can thwart attackers who
>> have some kind of zero-day that got them into the web server (e.g.
>> running httpd on Linux). Then they try the app server and surprise!
>> It's NetBSD and they have to stop and find another attack to proceed.
>
> This is of course possible, but in practice quite rare.
>
Agreed, operations likes same-ol', same-ol'. Running completely
different architectures on different layers is usually not seen, unless
the architecture has grown organically. If the infrastructure
architecture has been grown organically, then there are likely other
systemic problems.
>
> p
>
>
>
>> -chris
As mentioned earlier in this thread, I don't see the penchant for making
the manager application internet-accessible. Sooner or later this can
bite you hard.
Setting up a VPN using OpenVPN is not that difficult. It's a little more
difficult using two-factor authentication (PIN card plus certificate),
but still doable.
Then, set up a limited second connector HTTP connector (not many
threads) to serve your manager application.
Now you have a little more security.
1. Something you have (certificate)
2. Something you know (possible PIN, possible password on certificate)
3. Another something you know (how to access the manager application)
4. Reasonably secure (depending on how you set up OpenVPN) access
5. Audit trail (OpenVPN logs, manager logs)
6. Revocation ability (revoke OpenVPN certs, change manager access)
Add Apache HTTPD in front with mod_security (or another IDS
environment), and you've probably made life measurably more difficult
for the would-be cracker.
Would I manage a Tomcat from a coffee shop with this set up? Probably
not. Is this a reasonable approach for the telecommute person? Probably so.
Please note that I am NOT a security architect (nor do I play one on the
Internet). I'm just a beleaguered systems architect that tries to find a
balance between the security-by-formula people versus ease-of-use versus
operations versus end user functionality. I feel that it's probably a
zero-sum game, but I guess I like hitting my head against brick walls.
. . . off to go find more brick walls
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Pid,
On 4/15/13 6:19 AM, Pid wrote:
> On 15/04/2013 00:03, Christopher Schultz wrote:
>> Pid,
>>
>> On 4/12/13 1:54 PM, Pïd stèr wrote:
>>> On 11 Apr 2013, at 21:36, Christopher Schultz
>>> <ch...@christopherschultz.net> wrote:
>>>> [...] though I would run Apache httpd and Tomcat on
>>>> different hosts, so localhost-binding is not possible unless
>>>> you are doing something like stunnel (which also might be a
>>>> good idea if you are traversing an untrusted network).
>>
>>> Respectfully, I have to disagree. Unless the Apache HTTPD is
>>> loaded with IDS that can sniff the inbound traffic, you've not
>>> achieved much, and now you have two boxes that have to be
>>> maintained, secured & patched. HTTPD != firewall.
>>
>> While httpd != firewall, it's traditional to allow
>> external-access to your web server but not your app servers
>> (databases, etc.). That means that external threats can only
>> directly-attack the web server.
>
> Respectfully, this is clearly not true if you are just passing
> traffic to the app server. An attack that compromises the
> application server in the way described above would still be
> effective regardless of the presence of HTTPD.
>
> The risk I perceive is that users think that simply installing
> HTTPD somehow improves their security, when it does not.
Agreed. Having a physical server (running httpd) between the wild
Internet and the application server does improve a certain type of
security (not via HTTP -- if I have an SQL injection vulnerability,
adding httpd does not help). However, if you break-into my web server
but there's nothing else running there (yes, you can sniff traffic,
etc. which is very bad) you still haven't broken-into my application
server.
> The 'traditional' approach in these matters needs close scrutiny
> IMO. People can't afford to rely on received wisdom for security
> and forget more important basics such as regular patching.
>
> I regularly debate this with customers and we usually agree/find a
> better approach.
>
>
>> Obviously, suffering a web server break-in sucks, but at least
>> the attacker then needs to break-into the application server
>> after that.
>
> Why would they bother if they can attack the applications directly
> anyway?
Agreed. I was focusing less on application-security and more on
environmental-security for this discussion. I think that is why we may
not be seeing eye-to-eye.
Obviously, a layered-approach to security is critical, and operational
security is just one of those layers.
>> If it's a one-box wonder, you've been owned in a one fell swoop.
>
> A bit like this one, then.
;)
>> Also, running a heterogeneous environment can thwart attackers
>> who have some kind of zero-day that got them into the web server
>> (e.g. running httpd on Linux). Then they try the app server and
>> surprise! It's NetBSD and they have to stop and find another
>> attack to proceed.
>
> This is of course possible, but in practice quite rare.
Yup: it costs more because you have to have a wider range of expertise
on your ops team.
- -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/
iQIcBAEBCAAGBQJRbDafAAoJEBzwKT+lPKRYt3cQALXO+cRSp+K7a+lyy/pAYKX9
l1dFIAmydt7NUvdNN7VmrGCqIB8L3oUx8DFCOcuuVMtlPOyuyyFMykARD0UX9Gkz
wF/jQXHYw+BUTIxpxSGX+9IEqVS0PW3+icFTjNEq7DFvi6T9vR7SzEBBo1I0yBxL
udbmHXSrWyp+eR8gDcrT8yeTQ0NIO7gXh/MZTbNYoBhaYfnWXbQRdSSLBAh2qb33
U0hFaQ1nXyhF40FgJJ4H6SniITf/QLRVSOxyXye2HCoPxpfK5hogwmd6uWTT/yxt
pGuGsRAscn1ay5RJKLQVlJwgD2fwpEbXTWPwaBPAxX0GzmvP5Wyc+taGDVfArYuS
cVwb9fyasgW15N44yzmEPrqjTl5iu0GDz88i7dtEcQgtdjVzkqbiHr3h5EpPaBKo
Rv010bxXrpESqjrpjvET9dHCQW8WAsxFbiv+T2EC5dKhXR88TZhiIJRvOYIlTxZF
tYCxgCUbJ3ssQZw2YKK+smHbOWZpD2jnTW1XPfU1Gc8A5hGfZDgAIaEXPnPVb5NR
0VGiNpzPWjl3zZMFlDJVzKrXnwOFbiI/vpBhysH+6CiHdTgBMDKlkMMP/Bu+0o6/
qUMKRac0L48Di7n3Mf4sAOBD/1+UOV8PndtI7JcZe8D4dAeCp2ILMGT1b+gkDwye
WJvLNrAnam+2f/Sj1I07
=jTiG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Pid <pi...@pidster.com>.
On 15/04/2013 00:03, Christopher Schultz wrote:
> Pid,
>
> On 4/12/13 1:54 PM, Pïd stèr wrote:
>> On 11 Apr 2013, at 21:36, Christopher Schultz
>> <ch...@christopherschultz.net> wrote:
>>> [...] though I would run Apache httpd and Tomcat on different
>>> hosts, so localhost-binding is not possible unless you are doing
>>> something like stunnel (which also might be a good idea if you
>>> are traversing an untrusted network).
>
>> Respectfully, I have to disagree. Unless the Apache HTTPD is
>> loaded with IDS that can sniff the inbound traffic, you've not
>> achieved much, and now you have two boxes that have to be
>> maintained, secured & patched. HTTPD != firewall.
>
> While httpd != firewall, it's traditional to allow external-access to
> your web server but not your app servers (databases, etc.). That means
> that external threats can only directly-attack the web server.
Respectfully, this is clearly not true if you are just passing traffic
to the app server. An attack that compromises the application server in
the way described above would still be effective regardless of the
presence of HTTPD.
The risk I perceive is that users think that simply installing HTTPD
somehow improves their security, when it does not.
The 'traditional' approach in these matters needs close scrutiny IMO.
People can't afford to rely on received wisdom for security and forget
more important basics such as regular patching.
I regularly debate this with customers and we usually agree/find a
better approach.
> Obviously, suffering a web server break-in sucks, but at least the
> attacker then needs to break-into the application server after that.
Why would they bother if they can attack the applications directly anyway?
> If it's a one-box wonder, you've been owned in a one fell swoop.
A bit like this one, then.
> Also, running a heterogeneous environment can thwart attackers who
> have some kind of zero-day that got them into the web server (e.g.
> running httpd on Linux). Then they try the app server and surprise!
> It's NetBSD and they have to stop and find another attack to proceed.
This is of course possible, but in practice quite rare.
p
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
[key:62590808]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Pid,
On 4/12/13 1:54 PM, Pïd stèr wrote:
> On 11 Apr 2013, at 21:36, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> [...] though I would run Apache httpd and Tomcat on different
>> hosts, so localhost-binding is not possible unless you are doing
>> something like stunnel (which also might be a good idea if you
>> are traversing an untrusted network).
>
> Respectfully, I have to disagree. Unless the Apache HTTPD is
> loaded with IDS that can sniff the inbound traffic, you've not
> achieved much, and now you have two boxes that have to be
> maintained, secured & patched. HTTPD != firewall.
While httpd != firewall, it's traditional to allow external-access to
your web server but not your app servers (databases, etc.). That means
that external threats can only directly-attack the web server.
Obviously, suffering a web server break-in sucks, but at least the
attacker then needs to break-into the application server after that.
If it's a one-box wonder, you've been owned in a one fell swoop.
Also, running a heterogeneous environment can thwart attackers who
have some kind of zero-day that got them into the web server (e.g.
running httpd on Linux). Then they try the app server and surprise!
It's NetBSD and they have to stop and find another attack to proceed.
- -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/
iQIcBAEBCAAGBQJRazW0AAoJEBzwKT+lPKRYCW0QAIV46+zOy9OQkn/gWhN0JyQF
4KdCXv/TCeItAKLNwcx5cmWFwIOT8HgpTS9Z0Zuj0taUOFM4Rnw2b/ODafhvyRsn
d8Xfh8q5voz5GtXeirXYC4qDLEKVUFifZNj1FCF3ZnX0zIjBxErXQCiRSsD7SWSH
6UMMXUADbvNo4A9KJiQZgM0gX/4IAGJp9DKil5Wx23pJn+poPXIP1FfT87wn/E5b
xpbtjd6yUq0hmJ8dStxxzMlAtVp6EXeAdjODTpoWrDQRzo7CLf0FJ/x72PtbHrTd
ozQ5zUlmEIZEW3DlMbwoJYuXXIlJs/RW+WMMgtJ1YnUjFXsHNBbm7VwMr7SyMom2
ByVDJHCjzEfKmojgYSIOBB9oajg5XFdflzyqhE89X115zpDRHUYYq2ExT4uh8kXv
/Du01Mqo7X8+GBO1vAklESm0P9ejd1OUxeE1dlnNcDtji+pZPZgSdnHKWlZkBpie
p5grsttRMAd/a4J00yKlWSZNbG8ufhIl4fi4zX572bLjc4A/vUX0G6CDWop/U/8Y
MD701ou2pUPPI8opzRc8Vu4bwu+dfBYwIWuId6eczfkxHagN0v3grYUOLiuVTsH0
aDGONfxS27QEUvMKDF1cdZ1+T2L90PW6uk7LTmiy7eXQCgKqCyPLEsIlijyn3chE
pebh9gxK12hQlQzYUsCz
=yDKl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Pïd stèr <pi...@pidster.com>.
On 11 Apr 2013, at 21:36, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Esmond,
>
> On 4/10/13 8:21 PM, Esmond Pitt wrote:
>> We had lots of these and finally an attack last year on a Tomcat
>> where the manager password somehow hadn't been changed.
>
> Note that the manager webapp has no default passwords, so I wonder
> what you mean when you say it "hadn't been changed". There are
> examples in conf/tomcat-users.xml but they are all commented-out.
>
> You would have had to intentionally enable the "default" password.
>
>> The attacker installed a viral servlet application that killed the
>> server completely, we had to rebuild it.
>
> I -- like most people I would guess -- don't run under a
> SecurityManager, but doing so can significantly limit the damage that
> a rogue webapp can do.
>
>> We:
>>
>> - Hid the Tomcat behind an Apache HTTPD on port 80.
>
> Did you also remove manager webapp access through httpd? Otherwise,
> this doesn't actually do anything to help.
>
>> - Closed port 8080, indeed removed all the HTTP Connectors from
>> Tomcat and just used AJP connectors running on 127.0.0.1/2/3/4/...,
>> all on the same port for simplicity, so there is no zero direct
>> access to Tomcat from the outside
>
> +1, though I would run Apache httpd and Tomcat on different hosts, so
> localhost-binding is not possible unless you are doing something like
> stunnel (which also might be a good idea if you are traversing an
> untrusted network).
Respectfully, I have to disagree. Unless the Apache HTTPD is loaded
with IDS that can sniff the inbound traffic, you've not achieved much,
and now you have two boxes that have to be maintained, secured &
patched. HTTPD != firewall.
p
>
>> - Configured Apache HTTPD for LDAP authentication via an OpenLDAP
>> server that in turn is configured via the Password Policy overlay
>> for finite (5 I think) password retries before locking out the
>> account
>
> +2 -- both good ideas: central access control (LDAP) and enabling
> lockout mechanism. Note that Tomcat's lockout mechanism is fairly
> primitive and easy to game.
>
>> - required a very restricted LDAP group membership for access to
>> /manager (and the other Tomcat builtins).
>
> +1 hooray for role-based permissions!
>
>> No recurrence, not even an attempt. I think actually closing port
>> 8080 may have played the biggest part in all this.
>
> Would you be willing to review the Tomcat documentation on "securing
> Tomcat" and make a few comments? It could always use some additional tips:
>
> http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html
> http://wiki.apache.org/tomcat/FAQ/Security
>
> You can sign-up for the wiki yourself and make any changes you want.
> If you want to modify the "official" documentation, create a Bugzilla
> enhancement request and (please!) include a patch. I'm sure it will go
> right in.
>
> Thanks,
> - -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/
>
> iQIcBAEBCAAGBQJRZx7AAAoJEBzwKT+lPKRY+3MP/3c8kZZU43cMaxkXTi/ELXha
> Hv6rAeGz4nnpMNn2C002cTRgZ39vomUXYdsLMnNIshn05JDVIZmLLoUXk6UzY9go
> uH0QdAubBxhvwC/CWeLjUuSjy/Ei4vKeB7xJNw/FQ2xXEt47FWv36e0vgxOyluX+
> gbkB3KQlN6PXtQENGvkOGT5oWLK9M7WUydGSWq9lXR+akwWeL3jWRAlLl6bHYybQ
> n70c5wq/rJbEj+k9yCHsMZvPabYs5ejsz6wHvvw4Emrxcp4LVVjCuY2Z87Yhdtb4
> B43tF48be9GUZCXDvtIjiS5phHMhpqyJakHuZ7GSvzDIeuiNZ96XuoDkIG1bwWjf
> Z5SMCSjkSPqDKJ1cXcd8AaSYgI2C3KQnuFrbTD7bVqQHOeq7RJZp3+xE0IUNPl+V
> H2PNpUfXD9BDbPiiDt8bcgvcrImejW0RDumQ2fwbTVvt4OaybVsMUsVFW8lUtw3A
> YhvFn/WCEdR8VaY9PkqYm84BVMsQJBbBdb5clYiAtVQRky1NPS+hcIihnf85DkNU
> vr6rv/oK0aMXAamwUagmRe5OjTHuHczERPYgEUMpppnlXuNV1mLxBib8+HInGg3/
> Y5i28tTd7fS5uo7/CZv+9uEZdDUO7utWGT0W+gBaIkh35/yZI5a1l5wi0szYduQe
> t3nftQXUTCYtK1QNwKND
> =3s6Q
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/4/12 Christopher Schultz <ch...@christopherschultz.net>:
>
>> The attacker installed a viral servlet application that killed the
>> server completely, we had to rebuild it.
>
> I -- like most people I would guess -- don't run under a
> SecurityManager, but doing so can significantly limit the damage that
> a rogue webapp can do.
>
If you do not trust your applications then it is recommended to run
with <Host deployXML="false">.
http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#Host
I think there are not enough checks in place to avoid abuse if webapp
is able to provide its own context.xml file, even if you run with a
SecurityManager.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Esmond,
On 4/10/13 8:21 PM, Esmond Pitt wrote:
> We had lots of these and finally an attack last year on a Tomcat
> where the manager password somehow hadn't been changed.
Note that the manager webapp has no default passwords, so I wonder
what you mean when you say it "hadn't been changed". There are
examples in conf/tomcat-users.xml but they are all commented-out.
You would have had to intentionally enable the "default" password.
> The attacker installed a viral servlet application that killed the
> server completely, we had to rebuild it.
I -- like most people I would guess -- don't run under a
SecurityManager, but doing so can significantly limit the damage that
a rogue webapp can do.
> We:
>
> - Hid the Tomcat behind an Apache HTTPD on port 80.
Did you also remove manager webapp access through httpd? Otherwise,
this doesn't actually do anything to help.
> - Closed port 8080, indeed removed all the HTTP Connectors from
> Tomcat and just used AJP connectors running on 127.0.0.1/2/3/4/...,
> all on the same port for simplicity, so there is no zero direct
> access to Tomcat from the outside
+1, though I would run Apache httpd and Tomcat on different hosts, so
localhost-binding is not possible unless you are doing something like
stunnel (which also might be a good idea if you are traversing an
untrusted network).
> - Configured Apache HTTPD for LDAP authentication via an OpenLDAP
> server that in turn is configured via the Password Policy overlay
> for finite (5 I think) password retries before locking out the
> account
+2 -- both good ideas: central access control (LDAP) and enabling
lockout mechanism. Note that Tomcat's lockout mechanism is fairly
primitive and easy to game.
> - required a very restricted LDAP group membership for access to
> /manager (and the other Tomcat builtins).
+1 hooray for role-based permissions!
> No recurrence, not even an attempt. I think actually closing port
> 8080 may have played the biggest part in all this.
Would you be willing to review the Tomcat documentation on "securing
Tomcat" and make a few comments? It could always use some additional tips:
http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html
http://wiki.apache.org/tomcat/FAQ/Security
You can sign-up for the wiki yourself and make any changes you want.
If you want to modify the "official" documentation, create a Bugzilla
enhancement request and (please!) include a patch. I'm sure it will go
right in.
Thanks,
- -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/
iQIcBAEBCAAGBQJRZx7AAAoJEBzwKT+lPKRY+3MP/3c8kZZU43cMaxkXTi/ELXha
Hv6rAeGz4nnpMNn2C002cTRgZ39vomUXYdsLMnNIshn05JDVIZmLLoUXk6UzY9go
uH0QdAubBxhvwC/CWeLjUuSjy/Ei4vKeB7xJNw/FQ2xXEt47FWv36e0vgxOyluX+
gbkB3KQlN6PXtQENGvkOGT5oWLK9M7WUydGSWq9lXR+akwWeL3jWRAlLl6bHYybQ
n70c5wq/rJbEj+k9yCHsMZvPabYs5ejsz6wHvvw4Emrxcp4LVVjCuY2Z87Yhdtb4
B43tF48be9GUZCXDvtIjiS5phHMhpqyJakHuZ7GSvzDIeuiNZ96XuoDkIG1bwWjf
Z5SMCSjkSPqDKJ1cXcd8AaSYgI2C3KQnuFrbTD7bVqQHOeq7RJZp3+xE0IUNPl+V
H2PNpUfXD9BDbPiiDt8bcgvcrImejW0RDumQ2fwbTVvt4OaybVsMUsVFW8lUtw3A
YhvFn/WCEdR8VaY9PkqYm84BVMsQJBbBdb5clYiAtVQRky1NPS+hcIihnf85DkNU
vr6rv/oK0aMXAamwUagmRe5OjTHuHczERPYgEUMpppnlXuNV1mLxBib8+HInGg3/
Y5i28tTd7fS5uo7/CZv+9uEZdDUO7utWGT0W+gBaIkh35/yZI5a1l5wi0szYduQe
t3nftQXUTCYtK1QNwKND
=3s6Q
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Thu, Apr 11, 2013 at 9:47 AM, Jeffrey Janner <Jeffrey.Janner@polydyne.com
> wrote:
> > -----Original Message-----
> > From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
> > Sent: Wednesday, April 10, 2013 7:35 PM
> > To: Esmond Pitt
> > Cc: Tomcat Users List
> > Subject: Re: Tomcat access log reveals hack attempt: "HEAD
> > /manager/html HTTP/1.0" 404
> >
> > On Wed, Apr 10, 2013 at 8:21 PM, Esmond Pitt
> > <es...@bigpond.com>wrote:
> >
> > > We had lots of these and finally an attack last year on a Tomcat
> > where
> > > the manager password somehow hadn't been changed. The attacker
> > > installed a viral servlet application that killed the server
> > > completely, we had to rebuild it.
> > >
> > > We:
> > >
> > > - Hid the Tomcat behind an Apache HTTPD on port 80.
> > > - Closed port 8080, indeed removed all the HTTP Connectors from
> > Tomcat
> > > and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on
> > > the same port for simplicity, so there is no zero direct access to
> > > Tomcat from the outside
> > > - Configured Apache HTTPD for LDAP authentication via an OpenLDAP
> > > server that in turn is configured via the Password Policy overlay for
> > > finite (5 I
> > > think) password retries before locking out the account
> > > - required a very restricted LDAP group membership for access to
> > > /manager (and the other Tomcat builtins).
> > >
> > > No recurrence, not even an attempt. I think actually closing port
> > 8080
> > > may have played the biggest part in all this.
> > >
> > > EJP
> > >
> > >
> > +1 I like what you all did! I'm currently not using Apache HTTPD,
> > 'yet'.
> >
> > Before I start TomEE/tomcat, I always copy my edited version of
> > tomee/tomcat's user file, and I have a strong password in place. when I
> > first started using TomEE, and when I had port 3389 open on my Windows
> > Server 2008 'development server', I saw someone connect to the tomee
> > and tomcat manager apps, and they tried 'many' times to login to those
> > manager app pages.
> >
> > I LOL at them, because even though the manager apps were available, i
> > already beat them to the punch, because I secured tomee/tomcat by
> > commenting out users and/or user groups in the user file, and created
> > my own custom user that had a strong password. So, after I saw those
> > blatent-and-sorry-hacker attempts, I resolved that by removing manager
> > apps whenever I install new version of tomee/tomcat. Problem solved!!!
> > :) And yes, i eventually, closed port 3389 on my router, since I
> > really don't need it since I am in the office 99.99999% of the time
> > doing my work.
> > Sometimes, if I have to travel somewhere or sit in waiting room, while
> > my vehicle is being service, I do get tempted to open 3389 port on my
> > router and do some work at that time. :)
> >
>
> FYI, Howard, this is why they invented VPN technology.
>
>
True/agreed! Tried it years ago (when, evidently, our network was slower),
and we were completely turned off by the really really really slow
connection. Honestly, we've been managing well, for years, without VPN.
Thanks Jeffrey!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Thu, Apr 11, 2013 at 4:39 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jeffrey,
>
> On 4/11/13 9:47 AM, Jeffrey Janner wrote:
> >> -----Original Message----- From: Howard W. Smith, Jr.
> >> [mailto:smithh032772@gmail.com] Sent: Wednesday, April 10, 2013
> >> 7:35 PM To: Esmond Pitt Cc: Tomcat Users List Subject: Re: Tomcat
> >> access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
> >> 404
> >>
> >> On Wed, Apr 10, 2013 at 8:21 PM, Esmond Pitt
> >> <es...@bigpond.com>wrote:
> >>
> >>> We had lots of these and finally an attack last year on a
> >>> Tomcat
> >> where
> >>> the manager password somehow hadn't been changed. The attacker
> >>> installed a viral servlet application that killed the server
> >>> completely, we had to rebuild it.
> >>>
> >>> We:
> >>>
> >>> - Hid the Tomcat behind an Apache HTTPD on port 80. - Closed
> >>> port 8080, indeed removed all the HTTP Connectors from
> >> Tomcat
> >>> and just used AJP connectors running on 127.0.0.1/2/3/4/...,
> >>> all on the same port for simplicity, so there is no zero direct
> >>> access to Tomcat from the outside - Configured Apache HTTPD for
> >>> LDAP authentication via an OpenLDAP server that in turn is
> >>> configured via the Password Policy overlay for finite (5 I
> >>> think) password retries before locking out the account -
> >>> required a very restricted LDAP group membership for access to
> >>> /manager (and the other Tomcat builtins).
> >>>
> >>> No recurrence, not even an attempt. I think actually closing
> >>> port
> >> 8080
> >>> may have played the biggest part in all this.
> >>>
> >>> EJP
> >>>
> >>>
> >> +1 I like what you all did! I'm currently not using Apache
> >> HTTPD, 'yet'.
> >>
> >> Before I start TomEE/tomcat, I always copy my edited version of
> >> tomee/tomcat's user file, and I have a strong password in place.
> >> when I first started using TomEE, and when I had port 3389 open
> >> on my Windows Server 2008 'development server', I saw someone
> >> connect to the tomee and tomcat manager apps, and they tried
> >> 'many' times to login to those manager app pages.
> >>
> >> I LOL at them, because even though the manager apps were
> >> available, i already beat them to the punch, because I secured
> >> tomee/tomcat by commenting out users and/or user groups in the
> >> user file, and created my own custom user that had a strong
> >> password. So, after I saw those blatent-and-sorry-hacker
> >> attempts, I resolved that by removing manager apps whenever I
> >> install new version of tomee/tomcat. Problem solved!!! :) And
> >> yes, i eventually, closed port 3389 on my router, since I really
> >> don't need it since I am in the office 99.99999% of the time
> >> doing my work. Sometimes, if I have to travel somewhere or sit in
> >> waiting room, while my vehicle is being service, I do get tempted
> >> to open 3389 port on my router and do some work at that time. :)
> >>
> >
> > FYI, Howard, this is why they invented VPN technology.
>
> +1
>
> OpenVPN is cheap and relatively easy to set up.
>
Interesting. Thanks Chris.
>
> - -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/
>
> iQIcBAEBCAAGBQJRZx+eAAoJEBzwKT+lPKRYTD8P/RYPp4fq476XkWWnBQ+Z5hQn
> sGNkos89wTDvMWDTSaDclZ3zcc8RDGDBq4Mv/iN6TXev9ztZAiw5iQIbWqg1TiMx
> sEgaL++mtvC825epomP8vzxrc7EmAlM/iTLsnUxIxJSFXp93/ntLWy4drPPERxNr
> nXoRBNL9pdwAMln4e693I2TUsezH3zr+bppjfe3pzKWk0JU/Y1+Cp/XycwPKklwK
> qNhtgztqrL7URx28r/GPQ6/yUEoXzEe4PFBB+rZ7XyDqPlH30XmnUBXAU+B0Lr1D
> wekhHVSjVzl4UhgiAFxm1VF4FAuAG/Lvuia7Z4Jt074H7UaGVfsyauurWFn5JC0l
> 8NDVlBqRufHHmUPgZSIctR8vyqp4vbRKCcdL5CdXQ9TgScEWI+cVYzi4VjVz4kyR
> FRKhMZXC4K8lqvMkecLNjNLISp8KhAaGkM9sffzOLzWyqxPG8u7us26MScBKoAaJ
> 60gTJcDZ5jU0mywhJrGBK+X9ceKEIX0fafSiPbQ64Rb/MNxgkD9r92AiE4Ycslbg
> cAEHxioCrrTumCVeFCb9b9a+ZMXVw0LlBtUUeo8V5q/9KXTfQ5WFhXKPadN6tbP3
> ERGTFXZUU+8Kbe5ziv5m/039RUaOXnAFLUN46JcNfT2sKn/KkirV9DifxmnP3roh
> E/MwnaE4+YWdG5WSdvRa
> =28Nh
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
404
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
On 4/11/13 9:47 AM, Jeffrey Janner wrote:
>> -----Original Message----- From: Howard W. Smith, Jr.
>> [mailto:smithh032772@gmail.com] Sent: Wednesday, April 10, 2013
>> 7:35 PM To: Esmond Pitt Cc: Tomcat Users List Subject: Re: Tomcat
>> access log reveals hack attempt: "HEAD /manager/html HTTP/1.0"
>> 404
>>
>> On Wed, Apr 10, 2013 at 8:21 PM, Esmond Pitt
>> <es...@bigpond.com>wrote:
>>
>>> We had lots of these and finally an attack last year on a
>>> Tomcat
>> where
>>> the manager password somehow hadn't been changed. The attacker
>>> installed a viral servlet application that killed the server
>>> completely, we had to rebuild it.
>>>
>>> We:
>>>
>>> - Hid the Tomcat behind an Apache HTTPD on port 80. - Closed
>>> port 8080, indeed removed all the HTTP Connectors from
>> Tomcat
>>> and just used AJP connectors running on 127.0.0.1/2/3/4/...,
>>> all on the same port for simplicity, so there is no zero direct
>>> access to Tomcat from the outside - Configured Apache HTTPD for
>>> LDAP authentication via an OpenLDAP server that in turn is
>>> configured via the Password Policy overlay for finite (5 I
>>> think) password retries before locking out the account -
>>> required a very restricted LDAP group membership for access to
>>> /manager (and the other Tomcat builtins).
>>>
>>> No recurrence, not even an attempt. I think actually closing
>>> port
>> 8080
>>> may have played the biggest part in all this.
>>>
>>> EJP
>>>
>>>
>> +1 I like what you all did! I'm currently not using Apache
>> HTTPD, 'yet'.
>>
>> Before I start TomEE/tomcat, I always copy my edited version of
>> tomee/tomcat's user file, and I have a strong password in place.
>> when I first started using TomEE, and when I had port 3389 open
>> on my Windows Server 2008 'development server', I saw someone
>> connect to the tomee and tomcat manager apps, and they tried
>> 'many' times to login to those manager app pages.
>>
>> I LOL at them, because even though the manager apps were
>> available, i already beat them to the punch, because I secured
>> tomee/tomcat by commenting out users and/or user groups in the
>> user file, and created my own custom user that had a strong
>> password. So, after I saw those blatent-and-sorry-hacker
>> attempts, I resolved that by removing manager apps whenever I
>> install new version of tomee/tomcat. Problem solved!!! :) And
>> yes, i eventually, closed port 3389 on my router, since I really
>> don't need it since I am in the office 99.99999% of the time
>> doing my work. Sometimes, if I have to travel somewhere or sit in
>> waiting room, while my vehicle is being service, I do get tempted
>> to open 3389 port on my router and do some work at that time. :)
>>
>
> FYI, Howard, this is why they invented VPN technology.
+1
OpenVPN is cheap and relatively easy to set up.
- -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/
iQIcBAEBCAAGBQJRZx+eAAoJEBzwKT+lPKRYTD8P/RYPp4fq476XkWWnBQ+Z5hQn
sGNkos89wTDvMWDTSaDclZ3zcc8RDGDBq4Mv/iN6TXev9ztZAiw5iQIbWqg1TiMx
sEgaL++mtvC825epomP8vzxrc7EmAlM/iTLsnUxIxJSFXp93/ntLWy4drPPERxNr
nXoRBNL9pdwAMln4e693I2TUsezH3zr+bppjfe3pzKWk0JU/Y1+Cp/XycwPKklwK
qNhtgztqrL7URx28r/GPQ6/yUEoXzEe4PFBB+rZ7XyDqPlH30XmnUBXAU+B0Lr1D
wekhHVSjVzl4UhgiAFxm1VF4FAuAG/Lvuia7Z4Jt074H7UaGVfsyauurWFn5JC0l
8NDVlBqRufHHmUPgZSIctR8vyqp4vbRKCcdL5CdXQ9TgScEWI+cVYzi4VjVz4kyR
FRKhMZXC4K8lqvMkecLNjNLISp8KhAaGkM9sffzOLzWyqxPG8u7us26MScBKoAaJ
60gTJcDZ5jU0mywhJrGBK+X9ceKEIX0fafSiPbQ64Rb/MNxgkD9r92AiE4Ycslbg
cAEHxioCrrTumCVeFCb9b9a+ZMXVw0LlBtUUeo8V5q/9KXTfQ5WFhXKPadN6tbP3
ERGTFXZUU+8Kbe5ziv5m/039RUaOXnAFLUN46JcNfT2sKn/KkirV9DifxmnP3roh
E/MwnaE4+YWdG5WSdvRa
=28Nh
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
> Sent: Wednesday, April 10, 2013 7:35 PM
> To: Esmond Pitt
> Cc: Tomcat Users List
> Subject: Re: Tomcat access log reveals hack attempt: "HEAD
> /manager/html HTTP/1.0" 404
>
> On Wed, Apr 10, 2013 at 8:21 PM, Esmond Pitt
> <es...@bigpond.com>wrote:
>
> > We had lots of these and finally an attack last year on a Tomcat
> where
> > the manager password somehow hadn't been changed. The attacker
> > installed a viral servlet application that killed the server
> > completely, we had to rebuild it.
> >
> > We:
> >
> > - Hid the Tomcat behind an Apache HTTPD on port 80.
> > - Closed port 8080, indeed removed all the HTTP Connectors from
> Tomcat
> > and just used AJP connectors running on 127.0.0.1/2/3/4/..., all on
> > the same port for simplicity, so there is no zero direct access to
> > Tomcat from the outside
> > - Configured Apache HTTPD for LDAP authentication via an OpenLDAP
> > server that in turn is configured via the Password Policy overlay for
> > finite (5 I
> > think) password retries before locking out the account
> > - required a very restricted LDAP group membership for access to
> > /manager (and the other Tomcat builtins).
> >
> > No recurrence, not even an attempt. I think actually closing port
> 8080
> > may have played the biggest part in all this.
> >
> > EJP
> >
> >
> +1 I like what you all did! I'm currently not using Apache HTTPD,
> 'yet'.
>
> Before I start TomEE/tomcat, I always copy my edited version of
> tomee/tomcat's user file, and I have a strong password in place. when I
> first started using TomEE, and when I had port 3389 open on my Windows
> Server 2008 'development server', I saw someone connect to the tomee
> and tomcat manager apps, and they tried 'many' times to login to those
> manager app pages.
>
> I LOL at them, because even though the manager apps were available, i
> already beat them to the punch, because I secured tomee/tomcat by
> commenting out users and/or user groups in the user file, and created
> my own custom user that had a strong password. So, after I saw those
> blatent-and-sorry-hacker attempts, I resolved that by removing manager
> apps whenever I install new version of tomee/tomcat. Problem solved!!!
> :) And yes, i eventually, closed port 3389 on my router, since I
> really don't need it since I am in the office 99.99999% of the time
> doing my work.
> Sometimes, if I have to travel somewhere or sit in waiting room, while
> my vehicle is being service, I do get tempted to open 3389 port on my
> router and do some work at that time. :)
>
FYI, Howard, this is why they invented VPN technology.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 10, 2013 at 8:21 PM, Esmond Pitt <es...@bigpond.com>wrote:
> We had lots of these and finally an attack last year on a Tomcat where the
> manager password somehow hadn't been changed. The attacker installed a
> viral
> servlet application that killed the server completely, we had to rebuild
> it.
>
> We:
>
> - Hid the Tomcat behind an Apache HTTPD on port 80.
> - Closed port 8080, indeed removed all the HTTP Connectors from Tomcat and
> just used AJP connectors running on 127.0.0.1/2/3/4/..., all on the same
> port for simplicity, so there is no zero direct access to Tomcat from the
> outside
> - Configured Apache HTTPD for LDAP authentication via an OpenLDAP server
> that in turn is configured via the Password Policy overlay for finite (5 I
> think) password retries before locking out the account
> - required a very restricted LDAP group membership for access to /manager
> (and the other Tomcat builtins).
>
> No recurrence, not even an attempt. I think actually closing port 8080 may
> have played the biggest part in all this.
>
> EJP
>
>
+1 I like what you all did! I'm currently not using Apache HTTPD, 'yet'.
Before I start TomEE/tomcat, I always copy my edited version of
tomee/tomcat's user file, and I have a strong password in place. when I
first started using TomEE, and when I had port 3389 open on my Windows
Server 2008 'development server', I saw someone connect to the tomee and
tomcat manager apps, and they tried 'many' times to login to those manager
app pages.
I LOL at them, because even though the manager apps were available, i
already beat them to the punch, because I secured tomee/tomcat by
commenting out users and/or user groups in the user file, and created my
own custom user that had a strong password. So, after I saw those
blatent-and-sorry-hacker attempts, I resolved that by removing manager apps
whenever I install new version of tomee/tomcat. Problem solved!!! :) And
yes, i eventually, closed port 3389 on my router, since I really don't
need it since I am in the office 99.99999% of the time doing my work.
Sometimes, if I have to travel somewhere or sit in waiting room, while my
vehicle is being service, I do get tempted to open 3389 port on my router
and do some work at that time. :)
I really like the idea of LDAP, but honestly, I have no need for that,
since endusers of the app connect to the web app via mobile devices, from
laptop/PCs (via their home ISPs), etc...
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Posted by Esmond Pitt <es...@bigpond.com>.
We had lots of these and finally an attack last year on a Tomcat where the
manager password somehow hadn't been changed. The attacker installed a viral
servlet application that killed the server completely, we had to rebuild it.
We:
- Hid the Tomcat behind an Apache HTTPD on port 80.
- Closed port 8080, indeed removed all the HTTP Connectors from Tomcat and
just used AJP connectors running on 127.0.0.1/2/3/4/..., all on the same
port for simplicity, so there is no zero direct access to Tomcat from the
outside
- Configured Apache HTTPD for LDAP authentication via an OpenLDAP server
that in turn is configured via the Password Policy overlay for finite (5 I
think) password retries before locking out the account
- required a very restricted LDAP group membership for access to /manager
(and the other Tomcat builtins).
No recurrence, not even an attempt. I think actually closing port 8080 may
have played the biggest part in all this.
EJP
-----Original Message-----
From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
Sent: Wednesday, 10 April 2013 10:18 PM
To: Tomcat Users List
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
On Wed, Apr 10, 2013 at 8:00 AM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:
> > From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
> > Subject: Tomcat access log reveals hack attempt: "HEAD /manager/html
> HTTP/1.0" 404
>
> > a few minutes ago, I saw the following in the log:
>
> > 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
>
> > This is an unfamiliar ip address to me
>
> > Can someone please give/share some background on this type of attack?
>
> Another one from China. GIYF.
>
>
> http://www.economist.com/news/leaders/21572200-if-china-wants-respect-
> abroad-it-must-rein-its-hackers-getting-ugly
>
> - Chuck
>
>
Thanks Chuck.
I kinda thought that was the reason for the attack, especially, when I went
to https://ipdb.at/, and did a lookup of the IP address. Also, I just used
TextPad (text editor) to do a couple of multiple file searches to see how
often these type of attacks have been occurring in the past.
I mentioned earlier that I removed the manager apps. The server is behind a
firewall router, port 8080 is port-forwarded from the router to the server,
the web app has login page (and login servlet/filter in place), but SSL is
not configured just yet. That is definitely on my to-do list to complete,
ASAP, as the CEO has given me the go-ahead.
Is it (very) possible that any of these hackers are sniffing-or-snooping any
of the web app's HTTP requests/responses?
Honestly, based on the list of access log search results below (all are
unfamiliar/unwanted ip addresses), it doesn't seem as though my
server/tomcat/webapp is all that 'popular', but I am waiting to be
corrected. :)
Searching for: HEAD /manager/html
151.97.16.39 - - [20/Jan/2013:23:40:09 -0500] "HEAD /manager/html HTTP/1.0"
404 -
54.243.1.46 - - [23/Jan/2013:00:16:30 -0500] "HEAD /manager/html HTTP/1.0"
404 -
184.22.232.18 - - [25/Jan/2013:04:09:00 -0500] "HEAD /manager/html HTTP/1.0"
404 -
148.241.188.62 - - [08/Feb/2013:21:34:19 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
116.1.249.3 - - [09/Feb/2013:05:02:33 -0500] "HEAD /manager/html HTTP/1.0"
404 -
72.44.38.139 - - [11/Feb/2013:16:25:02 -0500] "HEAD /manager/html HTTP/1.0"
404 -
176.34.219.177 - - [12/Feb/2013:03:27:21 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
163.28.16.49 - - [14/Feb/2013:04:32:46 -0500] "HEAD /manager/html HTTP/1.0"
404 -
65.61.202.159 - - [14/Feb/2013:05:14:39 -0500] "HEAD /manager/html HTTP/1.0"
404 - 24.248.215.60 - - [14/Feb/2013:05:51:41 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
87.249.106.69 - - [14/Feb/2013:07:34:53 -0500] "HEAD /manager/html HTTP/1.0"
404 -
31.169.105.59 - - [14/Feb/2013:14:46:40 -0500] "HEAD /manager/html HTTP/1.0"
404 -
190.6.20.69 - - [17/Feb/2013:15:56:20 -0500] "HEAD /manager/html HTTP/1.0"
404 -
177.1.202.45 - - [18/Feb/2013:04:40:42 -0500] "HEAD /manager/html HTTP/1.0"
404 -
50.18.148.126 - - [20/Feb/2013:15:03:42 -0500] "HEAD /manager/html HTTP/1.0"
404 -
117.6.64.168 - - [23/Feb/2013:20:40:38 -0500] "HEAD /manager/html HTTP/1.0"
404 -
122.225.96.215 - - [26/Feb/2013:16:47:03 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
187.188.175.49 - - [26/Feb/2013:18:07:10 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
192.248.80.9 - - [28/Feb/2013:04:10:42 -0500] "HEAD /manager/html HTTP/1.0"
404 -
82.165.140.189 - - [03/Mar/2013:12:08:10 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
187.188.175.49 - - [05/Mar/2013:13:51:44 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
122.225.96.215 - - [07/Mar/2013:01:34:56 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
184.169.214.34 - - [10/Mar/2013:23:46:53 -0400] "HEAD /manager/html
HTTP/1.0" 404 -
70.34.195.106 - - [17/Mar/2013:16:59:43 -0400] "HEAD /manager/html HTTP/1.0"
404 - 63.218.12.130 - - [19/Mar/2013:17:29:20 -0400] "HEAD /manager/html
HTTP/1.0" 404 - 67.55.2.40 - - [31/Mar/2013:02:57:39 -0400] "HEAD
/manager/html HTTP/1.0"
404 -
141.11.254.77 - - [31/Mar/2013:15:32:49 -0400] "HEAD /manager/html HTTP/1.0"
404 -
74.216.195.99 - - [04/Apr/2013:21:21:20 -0400] "HEAD /manager/html HTTP/1.0"
404 - 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
HTTP/1.0" 404 - Found 29 occurrence(s) in 23 file(s)
Searching for: HEAD /
62.219.119.176 - - [21/Jan/2013:22:16:13 -0500] "HEAD / HTTP/1.0" 404 -
68.87.82.214 - - [23/Jan/2013:16:14:22 -0500] "HEAD / HTTP/1.0" 404 -
75.140.255.62 - - [28/Jan/2013:20:33:33 -0500] "HEAD / HTTP/1.0" 404 -
198.107.142.2 - - [07/Mar/2013:04:15:13 -0500] "HEAD / HTTP/1.0" 404 -
188.40.129.204 - - [08/Mar/2013:11:46:50 -0500] "HEAD / HTTP/1.0" 404 -
50.17.48.249 - - [09/Mar/2013:07:41:36 -0500] "HEAD / HTTP/1.0" 404 -
137.110.160.35 - - [12/Mar/2013:18:13:24 -0400] "HEAD / HTTP/1.0" 404 -
200.105.228.106 - - [17/Mar/2013:22:04:07 -0400] "HEAD / HTTP/1.0" 404 -
128.173.98.158 - - [20/Mar/2013:00:08:39 -0400] "HEAD / HTTP/1.0" 404 -
200.116.127.81 - - [27/Mar/2013:20:37:04 -0400] "HEAD / HTTP/1.0" 404 -
84.22.192.8 - - [31/Mar/2013:13:29:53 -0400] "HEAD / HTTP/1.0" 404 - Found
11 occurrence(s) in 11 file(s)
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY MATERIAL and is thus for use only by the intended
> recipient. If you received this in error, please contact the sender
> and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 10, 2013 at 8:48 AM, Daniel Mikusa <dm...@vmware.com> wrote:
> On Apr 10, 2013, at 8:17 AM, Howard W. Smith, Jr. wrote:
>
>
> This looks like a bot or automated script, checking to see if the Manager
> app is available. If it found the app, you'd probably see it try some
> exploit. Since you've removed it, there shouldn't be anything to worry
> about.
>
> Dan
>
>
Thanks Dan!
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Posted by Daniel Mikusa <dm...@vmware.com>.
On Apr 10, 2013, at 8:17 AM, Howard W. Smith, Jr. wrote:
> On Wed, Apr 10, 2013 at 8:00 AM, Caldarale, Charles R <
> Chuck.Caldarale@unisys.com> wrote:
>
>>> From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
>>> Subject: Tomcat access log reveals hack attempt: "HEAD /manager/html
>> HTTP/1.0" 404
>>
>>> a few minutes ago, I saw the following in the log:
>>
>>> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
>> HTTP/1.0" 404 -
>>
>>> This is an unfamiliar ip address to me
>>
>>> Can someone please give/share some background on this type of attack?
>>
>> Another one from China. GIYF.
>>
>>
>> http://www.economist.com/news/leaders/21572200-if-china-wants-respect-abroad-it-must-rein-its-hackers-getting-ugly
>>
>> - Chuck
>>
>>
> Thanks Chuck.
>
> I kinda thought that was the reason for the attack, especially, when I went
> to https://ipdb.at/, and did a lookup of the IP address. Also, I just used
> TextPad (text editor) to do a couple of multiple file searches to see how
> often these type of attacks have been occurring in the past.
This looks like a bot or automated script, checking to see if the Manager app is available. If it found the app, you'd probably see it try some exploit. Since you've removed it, there shouldn't be anything to worry about.
Dan
>
> I mentioned earlier that I removed the manager apps. The server is behind a
> firewall router, port 8080 is port-forwarded from the router to the server,
> the web app has login page (and login servlet/filter in place), but SSL is
> not configured just yet. That is definitely on my to-do list to complete,
> ASAP, as the CEO has given me the go-ahead.
>
> Is it (very) possible that any of these hackers are sniffing-or-snooping
> any of the web app's HTTP requests/responses?
>
> Honestly, based on the list of access log search results below (all are
> unfamiliar/unwanted ip addresses), it doesn't seem as though my
> server/tomcat/webapp is all that 'popular', but I am waiting to be
> corrected. :)
>
>
> Searching for: HEAD /manager/html
> 151.97.16.39 - - [20/Jan/2013:23:40:09 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 54.243.1.46 - - [23/Jan/2013:00:16:30 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 184.22.232.18 - - [25/Jan/2013:04:09:00 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 148.241.188.62 - - [08/Feb/2013:21:34:19 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 116.1.249.3 - - [09/Feb/2013:05:02:33 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 72.44.38.139 - - [11/Feb/2013:16:25:02 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 176.34.219.177 - - [12/Feb/2013:03:27:21 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 163.28.16.49 - - [14/Feb/2013:04:32:46 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 65.61.202.159 - - [14/Feb/2013:05:14:39 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 24.248.215.60 - - [14/Feb/2013:05:51:41 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 87.249.106.69 - - [14/Feb/2013:07:34:53 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 31.169.105.59 - - [14/Feb/2013:14:46:40 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 190.6.20.69 - - [17/Feb/2013:15:56:20 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 177.1.202.45 - - [18/Feb/2013:04:40:42 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 50.18.148.126 - - [20/Feb/2013:15:03:42 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 117.6.64.168 - - [23/Feb/2013:20:40:38 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 122.225.96.215 - - [26/Feb/2013:16:47:03 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 187.188.175.49 - - [26/Feb/2013:18:07:10 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 192.248.80.9 - - [28/Feb/2013:04:10:42 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 82.165.140.189 - - [03/Mar/2013:12:08:10 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 187.188.175.49 - - [05/Mar/2013:13:51:44 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 122.225.96.215 - - [07/Mar/2013:01:34:56 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 184.169.214.34 - - [10/Mar/2013:23:46:53 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 70.34.195.106 - - [17/Mar/2013:16:59:43 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 63.218.12.130 - - [19/Mar/2013:17:29:20 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 67.55.2.40 - - [31/Mar/2013:02:57:39 -0400] "HEAD /manager/html HTTP/1.0"
> 404 -
> 141.11.254.77 - - [31/Mar/2013:15:32:49 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 74.216.195.99 - - [04/Apr/2013:21:21:20 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> Found 29 occurrence(s) in 23 file(s)
>
> Searching for: HEAD /
> 62.219.119.176 - - [21/Jan/2013:22:16:13 -0500] "HEAD / HTTP/1.0" 404 -
> 68.87.82.214 - - [23/Jan/2013:16:14:22 -0500] "HEAD / HTTP/1.0" 404 -
> 75.140.255.62 - - [28/Jan/2013:20:33:33 -0500] "HEAD / HTTP/1.0" 404 -
> 198.107.142.2 - - [07/Mar/2013:04:15:13 -0500] "HEAD / HTTP/1.0" 404 -
> 188.40.129.204 - - [08/Mar/2013:11:46:50 -0500] "HEAD / HTTP/1.0" 404 -
> 50.17.48.249 - - [09/Mar/2013:07:41:36 -0500] "HEAD / HTTP/1.0" 404 -
> 137.110.160.35 - - [12/Mar/2013:18:13:24 -0400] "HEAD / HTTP/1.0" 404 -
> 200.105.228.106 - - [17/Mar/2013:22:04:07 -0400] "HEAD / HTTP/1.0" 404 -
> 128.173.98.158 - - [20/Mar/2013:00:08:39 -0400] "HEAD / HTTP/1.0" 404 -
> 200.116.127.81 - - [27/Mar/2013:20:37:04 -0400] "HEAD / HTTP/1.0" 404 -
> 84.22.192.8 - - [31/Mar/2013:13:29:53 -0400] "HEAD / HTTP/1.0" 404 -
> Found 11 occurrence(s) in 11 file(s)
>
>
>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is thus for use only by the intended recipient. If you
>> received this in error, please contact the sender and delete the e-mail and
>> its attachments from all computers.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 10, 2013 at 10:35 AM, David kerber <dc...@verizon.net> wrote:
> On 4/10/2013 10:24 AM, Howard W. Smith, Jr. wrote:
>
>> On Wed, Apr 10, 2013 at 9:44 AM, David kerber<dc...@verizon.net>
>> wrote:
>>
>> On 4/10/2013 8:17 AM, Howard W. Smith, Jr. wrote:
>>>
>>> On Wed, Apr 10, 2013 at 8:00 AM, Caldarale, Charles R<
>>>> Chuck.Caldarale@unisys.com> wrote:
>>>>
>>>> From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com****]
>>>>
>>>>> Subject: Tomcat access log reveals hack attempt: "HEAD /manager/html
>>>>>>
>>>>>> HTTP/1.0" 404
>>>>>
>>>>> a few minutes ago, I saw the following in the log:
>>>>>
>>>>>>
>>>>>>
>>>>> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
>>>>>
>>>>>>
>>>>>> HTTP/1.0" 404 -
>>>>>
>>>>> This is an unfamiliar ip address to me
>>>>>
>>>>>>
>>>>>>
>>>>> Can someone please give/share some background on this type of attack?
>>>>>
>>>>>>
>>>>>>
>>>>> Another one from China. GIYF.
>>>>>
>>>>>
>>>>> http://www.economist.com/news/****leaders/21572200-if-china-**<http://www.economist.com/news/**leaders/21572200-if-china-**>
>>>>> wants-respect-abroad-it-must-****rein-its-hackers-getting-**ugly<
>>>>> http://www.economist.com/**news/leaders/21572200-if-**
>>>>> china-wants-respect-abroad-it-**must-rein-its-hackers-getting-**ugly<http://www.economist.com/news/leaders/21572200-if-china-wants-respect-abroad-it-must-rein-its-hackers-getting-ugly>
>>>>> >
>>>>>
>>>>> - Chuck
>>>>>
>>>>>
>>>>> Thanks Chuck.
>>>>>
>>>>
>>>> I kinda thought that was the reason for the attack, especially, when I
>>>> went
>>>> to https://ipdb.at/, and did a lookup of the IP address. Also, I just
>>>> used
>>>> TextPad (text editor) to do a couple of multiple file searches to see
>>>> how
>>>> often these type of attacks have been occurring in the past.
>>>>
>>>> I mentioned earlier that I removed the manager apps. The server is
>>>> behind
>>>> a
>>>> firewall router, port 8080 is port-forwarded from the router to the
>>>> server,
>>>> the web app has login page (and login servlet/filter in place), but SSL
>>>> is
>>>> not configured just yet. That is definitely on my to-do list to
>>>> complete,
>>>> ASAP, as the CEO has given me the go-ahead.
>>>>
>>>> Is it (very) possible that any of these hackers are sniffing-or-snooping
>>>> any of the web app's HTTP requests/responses?
>>>>
>>>>
>>> Very unlikely. Sniffing/snooping requires that they have some kind of
>>> visibility into the link between the client and the server, so they'd
>>> either have to have a piece of malware installed in one of the ISPs
>>> between
>>> your client and your server (extremely difficult), or in your network or
>>> server, or the client's machines or network (not as difficult, but
>>> probably
>>> still unlikely). And if they had that, why would they call attention to
>>> themselves by letting their bot do automated searching for a manager app?
>>>
>>>
>>> Wow, good (and funny) question, David, and thanks for the info/response!
>>
>> I have actually seen some malware installed on the Windows Server 2003 R2,
>> that I was using to host the web-app months ago; IIRC, the malware
>> recorded
>> keystrokes; i think I caught that in the C:\Temp folder or something like
>> that, and I think I deleted the file(s) related to that on that server; i
>> think i scanned the list of processes as well via Task manager, and
>> searched the internet for processes that were listed in task manager, to
>> see if any of the processes were malware.
>>
>> Also, the CEO of my organization is somewhat concerned about some of the
>> personnel that may access that Windows Server 2003 R2, because he feels
>> that they browse the internet often and may have been infected on their
>> computers and/or mobile devices. :)
>>
>
> That's my biggest concern about my network security too. I'm under no
> illusions about my network not being hackable from outside by a determined
> attacker, but that's not as big of a concern to me as my users getting
> infected from their internet browsing habits and that infection spreading
> to my servers. I do have one advantage in that my users are few in number
> and are quite sharp, so it's easy to do training and to explain to them
> what kinds of behaviors are risky. I have already convinced them to only
> use IE as a last resort if none of the standard browsers work for what
> they're doing.
>
>
Interesting. Training (via email) is what I revert to as well, as I have a
small number of endusers accessing the app, and I need to take it a step
further, and warn them about risky (browsing) behavior. We already have our
email discussions about Google/Android products/releases/software-updates,
and I have asked them all to use Google Chrome when accessing the app (even
Google Chrome for iPad). :)
>
>
>
>> The servers have been accessed, by trusted-and-a-very-limited-**number-of
>> personnel, via Remote Desktop, in the past, but that server is rarely
>> accessed anymore. I am the only one that access the new Windows Server
>> 2008
>> R2 64bit server (opened a 'different' port in router, which is forwarded
>> to
>> remote desktop port of the server), and I have did some checking around on
>> the server for malware (possibly installed) and netstat, to ensure myself
>> and personnel are the only people connecting to the server. The tomcat
>> localhost access log files are now the only resource I check to see if
>> anyone is trying to hack the server/tomcat/web-app.
>>
>>
>>
>>
>>>
>>>
>>> Honestly, based on the list of access log search results below (all are
>>>> unfamiliar/unwanted ip addresses), it doesn't seem as though my
>>>> server/tomcat/webapp is all that 'popular', but I am waiting to be
>>>> corrected. :)
>>>>
>>>>
>>>> Searching for: HEAD /manager/html
>>>> 151.97.16.39 - - [20/Jan/2013:23:40:09 -0500] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 54.243.1.46 - - [23/Jan/2013:00:16:30 -0500] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 184.22.232.18 - - [25/Jan/2013:04:09:00 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 148.241.188.62 - - [08/Feb/2013:21:34:19 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 116.1.249.3 - - [09/Feb/2013:05:02:33 -0500] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 72.44.38.139 - - [11/Feb/2013:16:25:02 -0500] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 176.34.219.177 - - [12/Feb/2013:03:27:21 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 163.28.16.49 - - [14/Feb/2013:04:32:46 -0500] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 65.61.202.159 - - [14/Feb/2013:05:14:39 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 24.248.215.60 - - [14/Feb/2013:05:51:41 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 87.249.106.69 - - [14/Feb/2013:07:34:53 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 31.169.105.59 - - [14/Feb/2013:14:46:40 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 190.6.20.69 - - [17/Feb/2013:15:56:20 -0500] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 177.1.202.45 - - [18/Feb/2013:04:40:42 -0500] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 50.18.148.126 - - [20/Feb/2013:15:03:42 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 117.6.64.168 - - [23/Feb/2013:20:40:38 -0500] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 122.225.96.215 - - [26/Feb/2013:16:47:03 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 187.188.175.49 - - [26/Feb/2013:18:07:10 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 192.248.80.9 - - [28/Feb/2013:04:10:42 -0500] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 82.165.140.189 - - [03/Mar/2013:12:08:10 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 187.188.175.49 - - [05/Mar/2013:13:51:44 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 122.225.96.215 - - [07/Mar/2013:01:34:56 -0500] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 184.169.214.34 - - [10/Mar/2013:23:46:53 -0400] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 70.34.195.106 - - [17/Mar/2013:16:59:43 -0400] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 63.218.12.130 - - [19/Mar/2013:17:29:20 -0400] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 67.55.2.40 - - [31/Mar/2013:02:57:39 -0400] "HEAD /manager/html
>>>> HTTP/1.0"
>>>> 404 -
>>>> 141.11.254.77 - - [31/Mar/2013:15:32:49 -0400] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 74.216.195.99 - - [04/Apr/2013:21:21:20 -0400] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
>>>> HTTP/1.0" 404 -
>>>> Found 29 occurrence(s) in 23 file(s)
>>>>
>>>> Searching for: HEAD /
>>>> 62.219.119.176 - - [21/Jan/2013:22:16:13 -0500] "HEAD / HTTP/1.0" 404 -
>>>> 68.87.82.214 - - [23/Jan/2013:16:14:22 -0500] "HEAD / HTTP/1.0" 404 -
>>>> 75.140.255.62 - - [28/Jan/2013:20:33:33 -0500] "HEAD / HTTP/1.0" 404 -
>>>> 198.107.142.2 - - [07/Mar/2013:04:15:13 -0500] "HEAD / HTTP/1.0" 404 -
>>>> 188.40.129.204 - - [08/Mar/2013:11:46:50 -0500] "HEAD / HTTP/1.0" 404 -
>>>> 50.17.48.249 - - [09/Mar/2013:07:41:36 -0500] "HEAD / HTTP/1.0" 404 -
>>>> 137.110.160.35 - - [12/Mar/2013:18:13:24 -0400] "HEAD / HTTP/1.0" 404 -
>>>> 200.105.228.106 - - [17/Mar/2013:22:04:07 -0400] "HEAD / HTTP/1.0" 404 -
>>>> 128.173.98.158 - - [20/Mar/2013:00:08:39 -0400] "HEAD / HTTP/1.0" 404 -
>>>> 200.116.127.81 - - [27/Mar/2013:20:37:04 -0400] "HEAD / HTTP/1.0" 404 -
>>>> 84.22.192.8 - - [31/Mar/2013:13:29:53 -0400] "HEAD / HTTP/1.0" 404 -
>>>> Found 11 occurrence(s) in 11 file(s)
>>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat access log reveals hack attempt:
"HEAD /manager/html HTTP/1.0" 404
Posted by David kerber <dc...@verizon.net>.
On 4/10/2013 10:24 AM, Howard W. Smith, Jr. wrote:
> On Wed, Apr 10, 2013 at 9:44 AM, David kerber<dc...@verizon.net> wrote:
>
>> On 4/10/2013 8:17 AM, Howard W. Smith, Jr. wrote:
>>
>>> On Wed, Apr 10, 2013 at 8:00 AM, Caldarale, Charles R<
>>> Chuck.Caldarale@unisys.com> wrote:
>>>
>>> From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com**]
>>>>> Subject: Tomcat access log reveals hack attempt: "HEAD /manager/html
>>>>>
>>>> HTTP/1.0" 404
>>>>
>>>> a few minutes ago, I saw the following in the log:
>>>>>
>>>>
>>>> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
>>>>>
>>>> HTTP/1.0" 404 -
>>>>
>>>> This is an unfamiliar ip address to me
>>>>>
>>>>
>>>> Can someone please give/share some background on this type of attack?
>>>>>
>>>>
>>>> Another one from China. GIYF.
>>>>
>>>>
>>>> http://www.economist.com/news/**leaders/21572200-if-china-**
>>>> wants-respect-abroad-it-must-**rein-its-hackers-getting-ugly<http://www.economist.com/news/leaders/21572200-if-china-wants-respect-abroad-it-must-rein-its-hackers-getting-ugly>
>>>>
>>>> - Chuck
>>>>
>>>>
>>>> Thanks Chuck.
>>>
>>> I kinda thought that was the reason for the attack, especially, when I
>>> went
>>> to https://ipdb.at/, and did a lookup of the IP address. Also, I just
>>> used
>>> TextPad (text editor) to do a couple of multiple file searches to see how
>>> often these type of attacks have been occurring in the past.
>>>
>>> I mentioned earlier that I removed the manager apps. The server is behind
>>> a
>>> firewall router, port 8080 is port-forwarded from the router to the
>>> server,
>>> the web app has login page (and login servlet/filter in place), but SSL is
>>> not configured just yet. That is definitely on my to-do list to complete,
>>> ASAP, as the CEO has given me the go-ahead.
>>>
>>> Is it (very) possible that any of these hackers are sniffing-or-snooping
>>> any of the web app's HTTP requests/responses?
>>>
>>
>> Very unlikely. Sniffing/snooping requires that they have some kind of
>> visibility into the link between the client and the server, so they'd
>> either have to have a piece of malware installed in one of the ISPs between
>> your client and your server (extremely difficult), or in your network or
>> server, or the client's machines or network (not as difficult, but probably
>> still unlikely). And if they had that, why would they call attention to
>> themselves by letting their bot do automated searching for a manager app?
>>
>>
> Wow, good (and funny) question, David, and thanks for the info/response!
>
> I have actually seen some malware installed on the Windows Server 2003 R2,
> that I was using to host the web-app months ago; IIRC, the malware recorded
> keystrokes; i think I caught that in the C:\Temp folder or something like
> that, and I think I deleted the file(s) related to that on that server; i
> think i scanned the list of processes as well via Task manager, and
> searched the internet for processes that were listed in task manager, to
> see if any of the processes were malware.
>
> Also, the CEO of my organization is somewhat concerned about some of the
> personnel that may access that Windows Server 2003 R2, because he feels
> that they browse the internet often and may have been infected on their
> computers and/or mobile devices. :)
That's my biggest concern about my network security too. I'm under no
illusions about my network not being hackable from outside by a
determined attacker, but that's not as big of a concern to me as my
users getting infected from their internet browsing habits and that
infection spreading to my servers. I do have one advantage in that my
users are few in number and are quite sharp, so it's easy to do training
and to explain to them what kinds of behaviors are risky. I have
already convinced them to only use IE as a last resort if none of the
standard browsers work for what they're doing.
>
> The servers have been accessed, by trusted-and-a-very-limited-number-of
> personnel, via Remote Desktop, in the past, but that server is rarely
> accessed anymore. I am the only one that access the new Windows Server 2008
> R2 64bit server (opened a 'different' port in router, which is forwarded to
> remote desktop port of the server), and I have did some checking around on
> the server for malware (possibly installed) and netstat, to ensure myself
> and personnel are the only people connecting to the server. The tomcat
> localhost access log files are now the only resource I check to see if
> anyone is trying to hack the server/tomcat/web-app.
>
>
>
>>
>>
>>
>>> Honestly, based on the list of access log search results below (all are
>>> unfamiliar/unwanted ip addresses), it doesn't seem as though my
>>> server/tomcat/webapp is all that 'popular', but I am waiting to be
>>> corrected. :)
>>>
>>>
>>> Searching for: HEAD /manager/html
>>> 151.97.16.39 - - [20/Jan/2013:23:40:09 -0500] "HEAD /manager/html
>>> HTTP/1.0"
>>> 404 -
>>> 54.243.1.46 - - [23/Jan/2013:00:16:30 -0500] "HEAD /manager/html HTTP/1.0"
>>> 404 -
>>> 184.22.232.18 - - [25/Jan/2013:04:09:00 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 148.241.188.62 - - [08/Feb/2013:21:34:19 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 116.1.249.3 - - [09/Feb/2013:05:02:33 -0500] "HEAD /manager/html HTTP/1.0"
>>> 404 -
>>> 72.44.38.139 - - [11/Feb/2013:16:25:02 -0500] "HEAD /manager/html
>>> HTTP/1.0"
>>> 404 -
>>> 176.34.219.177 - - [12/Feb/2013:03:27:21 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 163.28.16.49 - - [14/Feb/2013:04:32:46 -0500] "HEAD /manager/html
>>> HTTP/1.0"
>>> 404 -
>>> 65.61.202.159 - - [14/Feb/2013:05:14:39 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 24.248.215.60 - - [14/Feb/2013:05:51:41 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 87.249.106.69 - - [14/Feb/2013:07:34:53 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 31.169.105.59 - - [14/Feb/2013:14:46:40 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 190.6.20.69 - - [17/Feb/2013:15:56:20 -0500] "HEAD /manager/html HTTP/1.0"
>>> 404 -
>>> 177.1.202.45 - - [18/Feb/2013:04:40:42 -0500] "HEAD /manager/html
>>> HTTP/1.0"
>>> 404 -
>>> 50.18.148.126 - - [20/Feb/2013:15:03:42 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 117.6.64.168 - - [23/Feb/2013:20:40:38 -0500] "HEAD /manager/html
>>> HTTP/1.0"
>>> 404 -
>>> 122.225.96.215 - - [26/Feb/2013:16:47:03 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 187.188.175.49 - - [26/Feb/2013:18:07:10 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 192.248.80.9 - - [28/Feb/2013:04:10:42 -0500] "HEAD /manager/html
>>> HTTP/1.0"
>>> 404 -
>>> 82.165.140.189 - - [03/Mar/2013:12:08:10 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 187.188.175.49 - - [05/Mar/2013:13:51:44 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 122.225.96.215 - - [07/Mar/2013:01:34:56 -0500] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 184.169.214.34 - - [10/Mar/2013:23:46:53 -0400] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 70.34.195.106 - - [17/Mar/2013:16:59:43 -0400] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 63.218.12.130 - - [19/Mar/2013:17:29:20 -0400] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 67.55.2.40 - - [31/Mar/2013:02:57:39 -0400] "HEAD /manager/html HTTP/1.0"
>>> 404 -
>>> 141.11.254.77 - - [31/Mar/2013:15:32:49 -0400] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 74.216.195.99 - - [04/Apr/2013:21:21:20 -0400] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
>>> HTTP/1.0" 404 -
>>> Found 29 occurrence(s) in 23 file(s)
>>>
>>> Searching for: HEAD /
>>> 62.219.119.176 - - [21/Jan/2013:22:16:13 -0500] "HEAD / HTTP/1.0" 404 -
>>> 68.87.82.214 - - [23/Jan/2013:16:14:22 -0500] "HEAD / HTTP/1.0" 404 -
>>> 75.140.255.62 - - [28/Jan/2013:20:33:33 -0500] "HEAD / HTTP/1.0" 404 -
>>> 198.107.142.2 - - [07/Mar/2013:04:15:13 -0500] "HEAD / HTTP/1.0" 404 -
>>> 188.40.129.204 - - [08/Mar/2013:11:46:50 -0500] "HEAD / HTTP/1.0" 404 -
>>> 50.17.48.249 - - [09/Mar/2013:07:41:36 -0500] "HEAD / HTTP/1.0" 404 -
>>> 137.110.160.35 - - [12/Mar/2013:18:13:24 -0400] "HEAD / HTTP/1.0" 404 -
>>> 200.105.228.106 - - [17/Mar/2013:22:04:07 -0400] "HEAD / HTTP/1.0" 404 -
>>> 128.173.98.158 - - [20/Mar/2013:00:08:39 -0400] "HEAD / HTTP/1.0" 404 -
>>> 200.116.127.81 - - [27/Mar/2013:20:37:04 -0400] "HEAD / HTTP/1.0" 404 -
>>> 84.22.192.8 - - [31/Mar/2013:13:29:53 -0400] "HEAD / HTTP/1.0" 404 -
>>> Found 11 occurrence(s) in 11 file(s)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 10, 2013 at 9:44 AM, David kerber <dc...@verizon.net> wrote:
> On 4/10/2013 8:17 AM, Howard W. Smith, Jr. wrote:
>
>> On Wed, Apr 10, 2013 at 8:00 AM, Caldarale, Charles R<
>> Chuck.Caldarale@unisys.com> wrote:
>>
>> From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com**]
>>>> Subject: Tomcat access log reveals hack attempt: "HEAD /manager/html
>>>>
>>> HTTP/1.0" 404
>>>
>>> a few minutes ago, I saw the following in the log:
>>>>
>>>
>>> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
>>>>
>>> HTTP/1.0" 404 -
>>>
>>> This is an unfamiliar ip address to me
>>>>
>>>
>>> Can someone please give/share some background on this type of attack?
>>>>
>>>
>>> Another one from China. GIYF.
>>>
>>>
>>> http://www.economist.com/news/**leaders/21572200-if-china-**
>>> wants-respect-abroad-it-must-**rein-its-hackers-getting-ugly<http://www.economist.com/news/leaders/21572200-if-china-wants-respect-abroad-it-must-rein-its-hackers-getting-ugly>
>>>
>>> - Chuck
>>>
>>>
>>> Thanks Chuck.
>>
>> I kinda thought that was the reason for the attack, especially, when I
>> went
>> to https://ipdb.at/, and did a lookup of the IP address. Also, I just
>> used
>> TextPad (text editor) to do a couple of multiple file searches to see how
>> often these type of attacks have been occurring in the past.
>>
>> I mentioned earlier that I removed the manager apps. The server is behind
>> a
>> firewall router, port 8080 is port-forwarded from the router to the
>> server,
>> the web app has login page (and login servlet/filter in place), but SSL is
>> not configured just yet. That is definitely on my to-do list to complete,
>> ASAP, as the CEO has given me the go-ahead.
>>
>> Is it (very) possible that any of these hackers are sniffing-or-snooping
>> any of the web app's HTTP requests/responses?
>>
>
> Very unlikely. Sniffing/snooping requires that they have some kind of
> visibility into the link between the client and the server, so they'd
> either have to have a piece of malware installed in one of the ISPs between
> your client and your server (extremely difficult), or in your network or
> server, or the client's machines or network (not as difficult, but probably
> still unlikely). And if they had that, why would they call attention to
> themselves by letting their bot do automated searching for a manager app?
>
>
Wow, good (and funny) question, David, and thanks for the info/response!
I have actually seen some malware installed on the Windows Server 2003 R2,
that I was using to host the web-app months ago; IIRC, the malware recorded
keystrokes; i think I caught that in the C:\Temp folder or something like
that, and I think I deleted the file(s) related to that on that server; i
think i scanned the list of processes as well via Task manager, and
searched the internet for processes that were listed in task manager, to
see if any of the processes were malware.
Also, the CEO of my organization is somewhat concerned about some of the
personnel that may access that Windows Server 2003 R2, because he feels
that they browse the internet often and may have been infected on their
computers and/or mobile devices. :)
The servers have been accessed, by trusted-and-a-very-limited-number-of
personnel, via Remote Desktop, in the past, but that server is rarely
accessed anymore. I am the only one that access the new Windows Server 2008
R2 64bit server (opened a 'different' port in router, which is forwarded to
remote desktop port of the server), and I have did some checking around on
the server for malware (possibly installed) and netstat, to ensure myself
and personnel are the only people connecting to the server. The tomcat
localhost access log files are now the only resource I check to see if
anyone is trying to hack the server/tomcat/web-app.
>
>
>
>> Honestly, based on the list of access log search results below (all are
>> unfamiliar/unwanted ip addresses), it doesn't seem as though my
>> server/tomcat/webapp is all that 'popular', but I am waiting to be
>> corrected. :)
>>
>>
>> Searching for: HEAD /manager/html
>> 151.97.16.39 - - [20/Jan/2013:23:40:09 -0500] "HEAD /manager/html
>> HTTP/1.0"
>> 404 -
>> 54.243.1.46 - - [23/Jan/2013:00:16:30 -0500] "HEAD /manager/html HTTP/1.0"
>> 404 -
>> 184.22.232.18 - - [25/Jan/2013:04:09:00 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 148.241.188.62 - - [08/Feb/2013:21:34:19 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 116.1.249.3 - - [09/Feb/2013:05:02:33 -0500] "HEAD /manager/html HTTP/1.0"
>> 404 -
>> 72.44.38.139 - - [11/Feb/2013:16:25:02 -0500] "HEAD /manager/html
>> HTTP/1.0"
>> 404 -
>> 176.34.219.177 - - [12/Feb/2013:03:27:21 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 163.28.16.49 - - [14/Feb/2013:04:32:46 -0500] "HEAD /manager/html
>> HTTP/1.0"
>> 404 -
>> 65.61.202.159 - - [14/Feb/2013:05:14:39 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 24.248.215.60 - - [14/Feb/2013:05:51:41 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 87.249.106.69 - - [14/Feb/2013:07:34:53 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 31.169.105.59 - - [14/Feb/2013:14:46:40 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 190.6.20.69 - - [17/Feb/2013:15:56:20 -0500] "HEAD /manager/html HTTP/1.0"
>> 404 -
>> 177.1.202.45 - - [18/Feb/2013:04:40:42 -0500] "HEAD /manager/html
>> HTTP/1.0"
>> 404 -
>> 50.18.148.126 - - [20/Feb/2013:15:03:42 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 117.6.64.168 - - [23/Feb/2013:20:40:38 -0500] "HEAD /manager/html
>> HTTP/1.0"
>> 404 -
>> 122.225.96.215 - - [26/Feb/2013:16:47:03 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 187.188.175.49 - - [26/Feb/2013:18:07:10 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 192.248.80.9 - - [28/Feb/2013:04:10:42 -0500] "HEAD /manager/html
>> HTTP/1.0"
>> 404 -
>> 82.165.140.189 - - [03/Mar/2013:12:08:10 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 187.188.175.49 - - [05/Mar/2013:13:51:44 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 122.225.96.215 - - [07/Mar/2013:01:34:56 -0500] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 184.169.214.34 - - [10/Mar/2013:23:46:53 -0400] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 70.34.195.106 - - [17/Mar/2013:16:59:43 -0400] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 63.218.12.130 - - [19/Mar/2013:17:29:20 -0400] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 67.55.2.40 - - [31/Mar/2013:02:57:39 -0400] "HEAD /manager/html HTTP/1.0"
>> 404 -
>> 141.11.254.77 - - [31/Mar/2013:15:32:49 -0400] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 74.216.195.99 - - [04/Apr/2013:21:21:20 -0400] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
>> HTTP/1.0" 404 -
>> Found 29 occurrence(s) in 23 file(s)
>>
>> Searching for: HEAD /
>> 62.219.119.176 - - [21/Jan/2013:22:16:13 -0500] "HEAD / HTTP/1.0" 404 -
>> 68.87.82.214 - - [23/Jan/2013:16:14:22 -0500] "HEAD / HTTP/1.0" 404 -
>> 75.140.255.62 - - [28/Jan/2013:20:33:33 -0500] "HEAD / HTTP/1.0" 404 -
>> 198.107.142.2 - - [07/Mar/2013:04:15:13 -0500] "HEAD / HTTP/1.0" 404 -
>> 188.40.129.204 - - [08/Mar/2013:11:46:50 -0500] "HEAD / HTTP/1.0" 404 -
>> 50.17.48.249 - - [09/Mar/2013:07:41:36 -0500] "HEAD / HTTP/1.0" 404 -
>> 137.110.160.35 - - [12/Mar/2013:18:13:24 -0400] "HEAD / HTTP/1.0" 404 -
>> 200.105.228.106 - - [17/Mar/2013:22:04:07 -0400] "HEAD / HTTP/1.0" 404 -
>> 128.173.98.158 - - [20/Mar/2013:00:08:39 -0400] "HEAD / HTTP/1.0" 404 -
>> 200.116.127.81 - - [27/Mar/2013:20:37:04 -0400] "HEAD / HTTP/1.0" 404 -
>> 84.22.192.8 - - [31/Mar/2013:13:29:53 -0400] "HEAD / HTTP/1.0" 404 -
>> Found 11 occurrence(s) in 11 file(s)
>>
>>
>>
>>
>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>>> MATERIAL and is thus for use only by the intended recipient. If you
>>> received this in error, please contact the sender and delete the e-mail
>>> and
>>> its attachments from all computers.
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat access log reveals hack attempt:
"HEAD /manager/html HTTP/1.0" 404
Posted by David kerber <dc...@verizon.net>.
On 4/10/2013 8:17 AM, Howard W. Smith, Jr. wrote:
> On Wed, Apr 10, 2013 at 8:00 AM, Caldarale, Charles R<
> Chuck.Caldarale@unisys.com> wrote:
>
>>> From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
>>> Subject: Tomcat access log reveals hack attempt: "HEAD /manager/html
>> HTTP/1.0" 404
>>
>>> a few minutes ago, I saw the following in the log:
>>
>>> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
>> HTTP/1.0" 404 -
>>
>>> This is an unfamiliar ip address to me
>>
>>> Can someone please give/share some background on this type of attack?
>>
>> Another one from China. GIYF.
>>
>>
>> http://www.economist.com/news/leaders/21572200-if-china-wants-respect-abroad-it-must-rein-its-hackers-getting-ugly
>>
>> - Chuck
>>
>>
> Thanks Chuck.
>
> I kinda thought that was the reason for the attack, especially, when I went
> to https://ipdb.at/, and did a lookup of the IP address. Also, I just used
> TextPad (text editor) to do a couple of multiple file searches to see how
> often these type of attacks have been occurring in the past.
>
> I mentioned earlier that I removed the manager apps. The server is behind a
> firewall router, port 8080 is port-forwarded from the router to the server,
> the web app has login page (and login servlet/filter in place), but SSL is
> not configured just yet. That is definitely on my to-do list to complete,
> ASAP, as the CEO has given me the go-ahead.
>
> Is it (very) possible that any of these hackers are sniffing-or-snooping
> any of the web app's HTTP requests/responses?
Very unlikely. Sniffing/snooping requires that they have some kind of
visibility into the link between the client and the server, so they'd
either have to have a piece of malware installed in one of the ISPs
between your client and your server (extremely difficult), or in your
network or server, or the client's machines or network (not as
difficult, but probably still unlikely). And if they had that, why
would they call attention to themselves by letting their bot do
automated searching for a manager app?
>
> Honestly, based on the list of access log search results below (all are
> unfamiliar/unwanted ip addresses), it doesn't seem as though my
> server/tomcat/webapp is all that 'popular', but I am waiting to be
> corrected. :)
>
>
> Searching for: HEAD /manager/html
> 151.97.16.39 - - [20/Jan/2013:23:40:09 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 54.243.1.46 - - [23/Jan/2013:00:16:30 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 184.22.232.18 - - [25/Jan/2013:04:09:00 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 148.241.188.62 - - [08/Feb/2013:21:34:19 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 116.1.249.3 - - [09/Feb/2013:05:02:33 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 72.44.38.139 - - [11/Feb/2013:16:25:02 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 176.34.219.177 - - [12/Feb/2013:03:27:21 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 163.28.16.49 - - [14/Feb/2013:04:32:46 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 65.61.202.159 - - [14/Feb/2013:05:14:39 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 24.248.215.60 - - [14/Feb/2013:05:51:41 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 87.249.106.69 - - [14/Feb/2013:07:34:53 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 31.169.105.59 - - [14/Feb/2013:14:46:40 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 190.6.20.69 - - [17/Feb/2013:15:56:20 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 177.1.202.45 - - [18/Feb/2013:04:40:42 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 50.18.148.126 - - [20/Feb/2013:15:03:42 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 117.6.64.168 - - [23/Feb/2013:20:40:38 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 122.225.96.215 - - [26/Feb/2013:16:47:03 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 187.188.175.49 - - [26/Feb/2013:18:07:10 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 192.248.80.9 - - [28/Feb/2013:04:10:42 -0500] "HEAD /manager/html HTTP/1.0"
> 404 -
> 82.165.140.189 - - [03/Mar/2013:12:08:10 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 187.188.175.49 - - [05/Mar/2013:13:51:44 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 122.225.96.215 - - [07/Mar/2013:01:34:56 -0500] "HEAD /manager/html
> HTTP/1.0" 404 -
> 184.169.214.34 - - [10/Mar/2013:23:46:53 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 70.34.195.106 - - [17/Mar/2013:16:59:43 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 63.218.12.130 - - [19/Mar/2013:17:29:20 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 67.55.2.40 - - [31/Mar/2013:02:57:39 -0400] "HEAD /manager/html HTTP/1.0"
> 404 -
> 141.11.254.77 - - [31/Mar/2013:15:32:49 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 74.216.195.99 - - [04/Apr/2013:21:21:20 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
> Found 29 occurrence(s) in 23 file(s)
>
> Searching for: HEAD /
> 62.219.119.176 - - [21/Jan/2013:22:16:13 -0500] "HEAD / HTTP/1.0" 404 -
> 68.87.82.214 - - [23/Jan/2013:16:14:22 -0500] "HEAD / HTTP/1.0" 404 -
> 75.140.255.62 - - [28/Jan/2013:20:33:33 -0500] "HEAD / HTTP/1.0" 404 -
> 198.107.142.2 - - [07/Mar/2013:04:15:13 -0500] "HEAD / HTTP/1.0" 404 -
> 188.40.129.204 - - [08/Mar/2013:11:46:50 -0500] "HEAD / HTTP/1.0" 404 -
> 50.17.48.249 - - [09/Mar/2013:07:41:36 -0500] "HEAD / HTTP/1.0" 404 -
> 137.110.160.35 - - [12/Mar/2013:18:13:24 -0400] "HEAD / HTTP/1.0" 404 -
> 200.105.228.106 - - [17/Mar/2013:22:04:07 -0400] "HEAD / HTTP/1.0" 404 -
> 128.173.98.158 - - [20/Mar/2013:00:08:39 -0400] "HEAD / HTTP/1.0" 404 -
> 200.116.127.81 - - [27/Mar/2013:20:37:04 -0400] "HEAD / HTTP/1.0" 404 -
> 84.22.192.8 - - [31/Mar/2013:13:29:53 -0400] "HEAD / HTTP/1.0" 404 -
> Found 11 occurrence(s) in 11 file(s)
>
>
>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is thus for use only by the intended recipient. If you
>> received this in error, please contact the sender and delete the e-mail and
>> its attachments from all computers.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Apr 10, 2013 at 8:00 AM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:
> > From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
> > Subject: Tomcat access log reveals hack attempt: "HEAD /manager/html
> HTTP/1.0" 404
>
> > a few minutes ago, I saw the following in the log:
>
> > 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
>
> > This is an unfamiliar ip address to me
>
> > Can someone please give/share some background on this type of attack?
>
> Another one from China. GIYF.
>
>
> http://www.economist.com/news/leaders/21572200-if-china-wants-respect-abroad-it-must-rein-its-hackers-getting-ugly
>
> - Chuck
>
>
Thanks Chuck.
I kinda thought that was the reason for the attack, especially, when I went
to https://ipdb.at/, and did a lookup of the IP address. Also, I just used
TextPad (text editor) to do a couple of multiple file searches to see how
often these type of attacks have been occurring in the past.
I mentioned earlier that I removed the manager apps. The server is behind a
firewall router, port 8080 is port-forwarded from the router to the server,
the web app has login page (and login servlet/filter in place), but SSL is
not configured just yet. That is definitely on my to-do list to complete,
ASAP, as the CEO has given me the go-ahead.
Is it (very) possible that any of these hackers are sniffing-or-snooping
any of the web app's HTTP requests/responses?
Honestly, based on the list of access log search results below (all are
unfamiliar/unwanted ip addresses), it doesn't seem as though my
server/tomcat/webapp is all that 'popular', but I am waiting to be
corrected. :)
Searching for: HEAD /manager/html
151.97.16.39 - - [20/Jan/2013:23:40:09 -0500] "HEAD /manager/html HTTP/1.0"
404 -
54.243.1.46 - - [23/Jan/2013:00:16:30 -0500] "HEAD /manager/html HTTP/1.0"
404 -
184.22.232.18 - - [25/Jan/2013:04:09:00 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
148.241.188.62 - - [08/Feb/2013:21:34:19 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
116.1.249.3 - - [09/Feb/2013:05:02:33 -0500] "HEAD /manager/html HTTP/1.0"
404 -
72.44.38.139 - - [11/Feb/2013:16:25:02 -0500] "HEAD /manager/html HTTP/1.0"
404 -
176.34.219.177 - - [12/Feb/2013:03:27:21 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
163.28.16.49 - - [14/Feb/2013:04:32:46 -0500] "HEAD /manager/html HTTP/1.0"
404 -
65.61.202.159 - - [14/Feb/2013:05:14:39 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
24.248.215.60 - - [14/Feb/2013:05:51:41 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
87.249.106.69 - - [14/Feb/2013:07:34:53 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
31.169.105.59 - - [14/Feb/2013:14:46:40 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
190.6.20.69 - - [17/Feb/2013:15:56:20 -0500] "HEAD /manager/html HTTP/1.0"
404 -
177.1.202.45 - - [18/Feb/2013:04:40:42 -0500] "HEAD /manager/html HTTP/1.0"
404 -
50.18.148.126 - - [20/Feb/2013:15:03:42 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
117.6.64.168 - - [23/Feb/2013:20:40:38 -0500] "HEAD /manager/html HTTP/1.0"
404 -
122.225.96.215 - - [26/Feb/2013:16:47:03 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
187.188.175.49 - - [26/Feb/2013:18:07:10 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
192.248.80.9 - - [28/Feb/2013:04:10:42 -0500] "HEAD /manager/html HTTP/1.0"
404 -
82.165.140.189 - - [03/Mar/2013:12:08:10 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
187.188.175.49 - - [05/Mar/2013:13:51:44 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
122.225.96.215 - - [07/Mar/2013:01:34:56 -0500] "HEAD /manager/html
HTTP/1.0" 404 -
184.169.214.34 - - [10/Mar/2013:23:46:53 -0400] "HEAD /manager/html
HTTP/1.0" 404 -
70.34.195.106 - - [17/Mar/2013:16:59:43 -0400] "HEAD /manager/html
HTTP/1.0" 404 -
63.218.12.130 - - [19/Mar/2013:17:29:20 -0400] "HEAD /manager/html
HTTP/1.0" 404 -
67.55.2.40 - - [31/Mar/2013:02:57:39 -0400] "HEAD /manager/html HTTP/1.0"
404 -
141.11.254.77 - - [31/Mar/2013:15:32:49 -0400] "HEAD /manager/html
HTTP/1.0" 404 -
74.216.195.99 - - [04/Apr/2013:21:21:20 -0400] "HEAD /manager/html
HTTP/1.0" 404 -
113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
HTTP/1.0" 404 -
Found 29 occurrence(s) in 23 file(s)
Searching for: HEAD /
62.219.119.176 - - [21/Jan/2013:22:16:13 -0500] "HEAD / HTTP/1.0" 404 -
68.87.82.214 - - [23/Jan/2013:16:14:22 -0500] "HEAD / HTTP/1.0" 404 -
75.140.255.62 - - [28/Jan/2013:20:33:33 -0500] "HEAD / HTTP/1.0" 404 -
198.107.142.2 - - [07/Mar/2013:04:15:13 -0500] "HEAD / HTTP/1.0" 404 -
188.40.129.204 - - [08/Mar/2013:11:46:50 -0500] "HEAD / HTTP/1.0" 404 -
50.17.48.249 - - [09/Mar/2013:07:41:36 -0500] "HEAD / HTTP/1.0" 404 -
137.110.160.35 - - [12/Mar/2013:18:13:24 -0400] "HEAD / HTTP/1.0" 404 -
200.105.228.106 - - [17/Mar/2013:22:04:07 -0400] "HEAD / HTTP/1.0" 404 -
128.173.98.158 - - [20/Mar/2013:00:08:39 -0400] "HEAD / HTTP/1.0" 404 -
200.116.127.81 - - [27/Mar/2013:20:37:04 -0400] "HEAD / HTTP/1.0" 404 -
84.22.192.8 - - [31/Mar/2013:13:29:53 -0400] "HEAD / HTTP/1.0" 404 -
Found 11 occurrence(s) in 11 file(s)
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Howard W. Smith, Jr. [mailto:smithh032772@gmail.com]
> Subject: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
> a few minutes ago, I saw the following in the log:
> 113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html HTTP/1.0" 404 -
> This is an unfamiliar ip address to me
> Can someone please give/share some background on this type of attack?
Another one from China. GIYF.
http://www.economist.com/news/leaders/21572200-if-china-wants-respect-abroad-it-must-rein-its-hackers-getting-ugly
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org