tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Mon, 15 Apr 2013 11:49:37 GMT
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.


> -----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.
> p



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message