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. 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? > 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. p > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- [key:62590808] --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org