tomcat-users mailing list archives

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


Mime
View raw message