tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Mon, 15 Apr 2013 15:48:03 GMT
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 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 [] 
>> 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, 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:
For additional commands, e-mail:

View raw message