-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Pid,
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 >>> <ch...@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. 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 server. > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRbDafAAoJEBzwKT+lPKRYt3cQALXO+cRSp+K7a+lyy/pAYKX9 l1dFIAmydt7NUvdNN7VmrGCqIB8L3oUx8DFCOcuuVMtlPOyuyyFMykARD0UX9Gkz wF/jQXHYw+BUTIxpxSGX+9IEqVS0PW3+icFTjNEq7DFvi6T9vR7SzEBBo1I0yBxL udbmHXSrWyp+eR8gDcrT8yeTQ0NIO7gXh/MZTbNYoBhaYfnWXbQRdSSLBAh2qb33 U0hFaQ1nXyhF40FgJJ4H6SniITf/QLRVSOxyXye2HCoPxpfK5hogwmd6uWTT/yxt pGuGsRAscn1ay5RJKLQVlJwgD2fwpEbXTWPwaBPAxX0GzmvP5Wyc+taGDVfArYuS cVwb9fyasgW15N44yzmEPrqjTl5iu0GDz88i7dtEcQgtdjVzkqbiHr3h5EpPaBKo Rv010bxXrpESqjrpjvET9dHCQW8WAsxFbiv+T2EC5dKhXR88TZhiIJRvOYIlTxZF tYCxgCUbJ3ssQZw2YKK+smHbOWZpD2jnTW1XPfU1Gc8A5hGfZDgAIaEXPnPVb5NR 0VGiNpzPWjl3zZMFlDJVzKrXnwOFbiI/vpBhysH+6CiHdTgBMDKlkMMP/Bu+0o6/ qUMKRac0L48Di7n3Mf4sAOBD/1+UOV8PndtI7JcZe8D4dAeCp2ILMGT1b+gkDwye WJvLNrAnam+2f/Sj1I07 =jTiG -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
