tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Kerle <>
Subject Re: tomcat performance on static content over SSL/non-SSL
Date Thu, 16 Aug 2007 01:54:14 GMT
good security is hard.

I've seen state governments using the reverse-proxy layered approach 
described below, and that worked extremely well. I've also seen a 
federal government with an open database port to the internet (won't say 
which! lets just say they're not known for prompt security fixes...), 
but who won't allow a proxied http tunnel inside for security reasons. 
just crazy, talk about take the log out of your own eye...

The only *really* safe option (against internal compromise) I've seen is 
to replicate databases into the DMZ, and disallow all connections from 
the DMZ to internal. But then you have problems with replication, and if 
you database is compromised then you risk data exposure. Which means 
there is no final solution, but it helps to raise the difficulty for 
attackers and minimise your risk. then make sure your backups work!!!


* Matthew Kerle
* * IT Consultant *
* Canberra, Australia*

Mobile: +61404 096 863
Email:     Matthew Kerle <>
Web:      Matthew Kerle <>

Leon Rosenberg wrote:
> security by obscurity, that is.
> since the httpd just sends all requests further to the tomcat, if
> there is a security relevant bug in tomcat code, it would be accessed
> by the remote side either way. Further, are your machines, on which
> httpd is running, running under different OS than your tomcat
> machines? Cause if they are the same, the same security issue would be
> present on both, so the attacker could easily reach the tomcat machine
> from the httpd machine via the same hole once he's there.
> It sounds like a good idea to put a firewall between tomcat and a db.
> But your tomcat machine and your webapp will have to access the db
> somehow, so why shouldn't the attacker use the same method to access
> your db, once he's on the tomcat machine?
> Therefore, your security infrastructure sounds like a good idea, but
> in fact it doesn't add any security. Just put a decent firewall
> between the internet and your cluster and that is it. Once its passed
> your security infrastructure wouldn't prevent the attacker to go on
> further.
> just 2 cents.
> leon
> P.S. Btw, some (recently fixed) buffer overflows in mod_jk connector
> (and in httpd itself) will actually reduce your security, since httpd
> is far less secure than java.
> On 8/15/07, Lizak, Ed <> wrote:
>> We use httpd to sit in between firewalls and handle all incoming traffic.
>> Static content is served from there and dynamic content is proxied through
>> to the Tomcat server behind another firewall.  SSL is only needed from the
>> client to the httpd server.
>> The Tomcat server then handles the database access which passes through
>> another firewall to hit our internal network where the database lives.
>> I'm not a security expert but it seems like a good idea having your database
>> connections far removed from the Internet connection.  At the very least it
>> would seem you would have to have multiple layers of server compromised
>> before any data is exposed.
>> Is this not a good reason to use httpd in front of Tomcat?
>> -EJL
>> ---------------------------------------------------------------
>> Matt,
>> Matthew Kerle wrote:
>>> Apart from integration into a larger site or static content, when would
>>> you put httpd in front of tomcat?
>> This might count as "integrating into a larger site", but I use Apache
>> httpd to front multiple instances of Tomcat through a single port number
>> (by mapping webapps individually through mod_jk). This allows me to
>> start and stop a single webapp, upgrade the JVM and/or Tomcat running
>> it, and then bring it back up again without disturbing the other
>> applications.
>> - -chris
>> Version: GnuPG v1.4.7 (MingW32)
>> Comment: Using GnuPG with Mozilla -
>> sn1AKYvbLyk3Bbap+tyIrsE=
>> =Zlq+
>> -----END PGP SIGNATURE-----
>> IMPORTANT CONFIDENTIALITY NOTICE:    This document, and any documents
>> accompanying this transmission, contains confidential, legally protected
>> information and is intended only for the person or entity to which it is
>> addressed. If you are not the intended recipient, any disclosure, copying,
>> distribution or the taking of any action in reliance on the contents of this
>> transmission is strictly prohibited. If you receive this transmission in
>> error, please contact the sender and delete or destroy the
>> material/information.
>> Corporate Headquarters <> 10340 Evendale Dr. <> Cincinnati, OH 45241
>> 513.563.1400
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail:
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message