"Turner, John" wrote: > What's the ramification of tomcat failing? Can it even fail > into a critical mode?
I have not researched into Tomcat failure modes. My guess follows... 1) It may have different consequences on different platforms. On Unix/related platforms, it may be just a denial of service (assuming it is not run as root). 2) Folks may get access to stuff in WEB-INF. This can be a business loss... > Tomcat is not a "web server" per se...that is, it isn't a > general purpose webserver. So, assuming someone sends a > malformed URL to tomcat...so what? Agreed that Tomcat is NOT a general purpose webserver (also I am not trying to knock Apache as a webserver either...) If one's content is mostly dynamic, Tomcat seems to do a very good job. Vaguely recall that malformed URLs could be used to access protected information in WEB-INF in some 3.x version of Tomcat. In my mind, that information is far more valuable than somebody getting access to the hardware. > I'm not saying that you can assume tomcat is invulnerable, I'm just trying > to understand how much effort should be expended "hardening" tomcat when > it's default configuration is pretty good as is, when used in conjunction > with overall best-practices from a systems administration point of view > (firewalls, logging, etc.). Agreed that overall best practices are important. In big companies, probably there will be teams who can guarantee a clean and safe Internet connection and one worries only about Tomcat. For smaller efforts, that luxury is generally not available. Looking at "hardening" does not imply that there are vulnerabilities. The fact that everyday I get malformed URLs seem to imply that some exploit or other does exist (may be not in the latest version). das > > John Turner > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 25, 2002 2:14 PM > To: Tomcat Users List > Subject: Re: Hardening Tomcat 3.2.4 > > I run Tomcat standalone. The rationale is that by eliminating > Apache from the equation, another layer of complex code is > eliminated increasing the security. It makes life easier also! > (one less thing to configure) > > das > > "Turner, John" wrote: > > Is it possible to configure tomcat to listen only on the connector ports, > > and not any other port, such as 8080? Seems to me you could just delete > the > > HTTP connector from port 8080 and that would make tomcat pretty hard to > mess > > with. Any malformed requests at that point would go through apache first, > > assuming an apache+connector+tomcat configuration. > > > > John Turner > > [EMAIL PROTECTED] > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, July 25, 2002 2:01 PM > > To: Tomcat Users List > > Subject: Re: Hardening Tomcat 3.2.4 > > > > Mike Jackson wrote: > > > A firewall is probably the best way to harden tomcat. Or any web server > > > for that matter, however for a one good you're going to probably end up > > > paying a large sum of money. You could go on the cheaper side and only > > use > > > a stateful port blocking firewall, but really to do it right you'll need > > > a firewall that looks at data being sent to the server and then blocks > > > on types of data rather than just the port. > > > > Is iptables on Linux generally good enough(?), assuming the data > > is not all that critical. Other than its basic functions, haven't > > really looked at iptables to see whether it can interface with > > any IDS... > > > > das > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
