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!!!
cheers.
* Matthew Kerle
* * IT Consultant *
* Canberra, Australia*
Mobile: +61404 096 863
Email: Matthew Kerle <mailto:[EMAIL PROTECTED]>
Web: Matthew Kerle <http://threebrightlights.blogspot.com/>
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 <[EMAIL PROTECTED]> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGww/r9CaO5/Lv0PARAihDAKCWoVVHxQF0hCTiIsgFLC0bjMrYyACaAvfr
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: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
