There is another argument. Once upon a time it was standard recommended advice to put a conventional web service like Apache's Httpd in front of tomcat. All the static resources get served up by the conventional web service and only the dynamic content would come from tomcat. That was a loooong time ago and the performance and stability of tomcat has increased dramatically, but there are still a lot of poorly maintained websites and old programming books out there still spouting obsolete advice.
I personally subscribe to the KISS philosophy. If it's just static resources and java webapp content, by all means just put up a tomcat service on port 80, stripped down to what's actually needed, and forget about Apache Httpd. Your life get's simplified and response times are on par with Apache Httpd. However, if you have a site that is a fusion of a lot of different technologies like PHP, Perl, Python, etc., ... then a service in front like Apache Httpd makes loads of sense. I don't see any security advantage to putting Apache Httpd in front of tomcat that wouldn't be mitigated by some defensive programming. The servlet spec is loaded with stuff designed to help webapp programmers with security. --David Robin Wilson wrote: > I like how your argument presumes the most foolish configuration for Apache > vs. the ideal configuration if you only use tomcat. If you want to go that > route, the default tomcat install includes a bunch of 'examples' and other > exploitable stuff - why not assume that they left all that at the default > values as well? > > -- > Robin D. Wilson > Director of Web Development > KingsIsle Entertainment, Inc. > WORK: 512-623-5913 > CELL: 512-426-3929 > www.KingsIsle.com > > > > -----Original Message----- > From: George Sexton [mailto:geor...@mhsoftware.com] > Sent: Tuesday, April 28, 2009 10:30 AM > To: Tomcat Users List > Subject: Re: Why we need two servers (httpd and tomcat) > > > > Robin Wilson wrote: > >> As for your assertion that 2 layers of security is just complexity >> and not more secure - you obviously haven't run many enterprise >> production systems. Security in an enterprise system is all about >> 'layers' of protection. And sure, if they hack one layer - they are >> probably good enough to hack the next layer. But that's where >> intrusion detection and a variety of other system come into play. >> It's all about slowing down the advance of the attack until you can >> do something about it. >> >> > > In theory, you're right. Defense in depth is a sound and established > practice. I remember as a Marine, reading company level tactics books > that laid out how to set up a rifle company for defense in depth. > > In this particular instance you're just wrong. Putting apache in front > of Tomcat makes the visible surface for attack about 10 times bigger. If > you're running Apache httpd, you've probably got PHP running which is a > huge security attack area, and then there are probably 20 other modules > that are loaded by default. Instead of having a small gate to defend, > you now have 10 gates to defend. > > You believe that to get your system, they have to get through httpd, and > then through tomcat. This is your defense in depth theory. It's just > wrong. If there's a buffer overflow in httpd, then they just have to > exploit that to get on your machine. > > Layers of protection in an Enterprise security system would be firewalls > protecting the perimeter, intrusion detection systems monitoring network > traffic, monitoring systems that detect changes in the host systems. > > So, by all means do defense in depth. Just don't delude yourself into > thinking that putting httpd in front of tomcat adds a layer of security. > It doesn't. > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
