tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
Date Mon, 15 Apr 2013 17:19:27 GMT
Hash: SHA256


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

> 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
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message