Re: Securing Tomcat Article for Review
Hi Marcus, On 1/10/07, Markus Schönhaber [EMAIL PROTECTED] wrote: Gregor Schneider wrote: OTOH there a very good reasons to use a httpd-Tomcat combination. Alas, the only reason there usually is, as you said, I wouldn't count amongst the good reasons. Tomcat serves static content just fine. In combination with APR even finer. I don't understand what you define as just fine and finer, however, we have a heavy-load web-app here that is accessed world-wide with about 30.000 static html-pages plus some servlets. We conducted tests with different load-runners and the results where quite clear: We had an improvement Tomcat - Apache/Tomcat of about 20%. To be fair, I have to say that we modified the headers within Apache what we didn't when running Tomcat only. See, i believe in statistics only when created by myself :) . I've read this claim (httpd is superior for static content) many times, but I've never seen the one making that claim also providing facts that back up it's truth. Well, if you don't consider the benchmarks we did here in our company trustworthy (which I do understand), maybe you'd like to look at some benchmarks on the Apache-website: http://tomcat.apache.org/articles/benchmark_summary.pdf Summary of the charts in the last paragraph: = [snip] = For those who wonder can tomcat handle static files? My opinion is yes. If you only have a single server co-located at an ISP and can't afford a dedicated image server, Tomcat will work just fine. For sites that need high performance/high availability, the best option is to setup dedicated Apache2 for the static files. = [snap] = Of course, YMMV. Right, and as I stated: Having a high-load-web-app with mostly static content served, for us there was no other option after our own performance-tests (BTW, we used JMeter and LoadRunner). Top of *my* list of good reasons for using httpd and Tomcat together is a httpd that acts as load-balancer for multiple Tomcat instances. If you have limited ressources, that might be an option, in our case that's just not enough and that's why we are using hardware-lb's. that's definately not the case. Definitely? Hm, again such an absolute claim of yours for which you provide no facts to back it up. Markus: As I stated above: I presume you *know* what you*re doing and you *know* your ways around Tomcat and Apache httpd. That provided, again, it is *definately* not the case that you decrease security, full stop. And he might think right. If you're adding complexity to the system you should be aware that there's the need to add even more sensible care to the system. If you fail to do that, the overall security will very propably be lower. As I see it, the chain of security is just as strong as it's weakest link. See above: You have to know what you're doing. If you don't, get help from a professional and get a security-audit. Although we *believe* to know our ways round, we're doing both (hey, we're moving slowly back to the topic... ;) My point is: one should worry about every piece of software installed. Even more so if it is accessible from an untrusted network. The more software, the more there is to worry about. Agreed, however, usually there's a need to install a certain software. I absolutely agree with you that, if you don't really need it, leave it OTOH, i'd rather have apache in front than running tomcat on port 80 via jsvc or as a service. I'd like to repeat Chuck's question: why? Plain and simple: You also can misconfigure jsvc (ok, chances are pretty small...) In *our* scenario I rather have Apache http in front because - it performs better - I got a lot of handy tools which either don't exists in Vanilla Tomcat (like URL-rewriting, Header-modification etc.) Sure, I could write my own filters and pass the static content through them first, but that'd slow down the whole app (tested). Cheers Greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
On 1/10/07, Gregor Schneider [EMAIL PROTECTED] wrote: OTOH, i'd rather have apache in front than running tomcat on port 80 via jsvc or as a service. I'd like to repeat Chuck's question: why? Plain and simple: You also can misconfigure jsvc (ok, chances are pretty small...) In *our* scenario I rather have Apache http in front because - it performs better What? You can argue that httpd doesn't decrease security, but talking about it being fast??? Come'on you're kidding :-) - I got a lot of handy tools which either don't exists in Vanilla Tomcat (like URL-rewriting, Header-modification etc.) Sure, I could write my own filters and pass the static content through them first, but that'd slow down the whole app (tested). Could you explain this a little more? How can it be that if you write out something from memory it's slower than ask the filesystem which could eventually have it in cache and be comparable fast in _best_ case? Or do you use DefaultServlet??? Also, if you care about static performance so much, why don't you use something fast? lighttpd? squid? I mean it's not a secret that apache httpd is NOT fast. regards Leon Cheers Greg -- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Hi Leon, On 1/10/07, Leon Rosenberg [EMAIL PROTECTED] wrote: In *our* scenario I rather have Apache http in front because - it performs better What? You can argue that httpd doesn't decrease security, but talking about it being fast??? Come'on you're kidding :-) Sorry, but I don't get you here: How refers speed to security? Could you pls explain what you mean here? Could you explain this a little more? How can it be that if you write out something from memory it's slower than ask the filesystem which could eventually have it in cache and be comparable fast in _best_ case? Simple: Since our static html doesn't change too often, we could reach significant perfomance-optimizations with optimized headers telling the client how to cache. Well, and mod_headers did a better job regarding performance than using plain Tomcat with a filter modifying the headers of static html. Or do you use DefaultServlet??? Now you must be kidding ;) Also, if you care about static performance so much, why don't you use something fast? lighttpd? squid? I mean it's not a secret that apache httpd is NOT fast. I can't explain our whole web-app in detail here, just that much: We've developed our own SSO-procedure (since the whole wep-app contains protected content served over SSL to authenticated users only). It was just easier for us to use the combination of Apache httpd and Tomcat since there's quite some stuff available. Since now the performance meets our expectations, there's no need to use other web-servers like squid. besides, we got quite some knowledge regarding Apache here, so why should we dump that (a matter of cost)? Cheers Greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Leon Rosenberg wrote: Sure, I could write my own filters and pass the static content through them first, but that'd slow down the whole app (tested). Could you explain this a little more? How can it be that if you write out something from memory it's slower than ask the filesystem which could eventually have it in cache and be comparable fast in _best_ case? Ever heard about sendfile()? http://builder.com.com/5100-6372-1044112.html http://www.freebsd.org/cgi/man.cgi?query=sendfilesektion=2 How could you expect a few system calls (when apache processes the request) be slower than hundreds of calls when JVM processes the request? -- Mikolaj Rydzewski [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Securing Tomcat Article for Review
On 1/10/07, Gregor Schneider [EMAIL PROTECTED] wrote:
Hi Leon,
On 1/10/07, Leon Rosenberg [EMAIL PROTECTED] wrote:
In *our* scenario I rather have Apache http in front because
- it performs better
What?
You can argue that httpd doesn't decrease security, but talking about
it being fast??? Come'on you're kidding :-)
Sorry, but I don't get you here: How refers speed to security? Could
you pls explain what you mean here?
Aehm,
the original thread was about security, and now you wrote performs
better, which I assumed referred to performance. If not - my fault
:-)
Could you explain this a little more? How can it be that if you write
out something from memory it's slower than ask the filesystem which
could eventually have it in cache and be comparable fast in _best_
case?
Simple:
Since our static html doesn't change too often, we could reach
significant perfomance-optimizations with optimized headers telling
the client how to cache.
Well, and mod_headers did a better job regarding performance than
using plain Tomcat with a filter modifying the headers of static html.
Or do you use DefaultServlet???
Now you must be kidding ;)
Do you hold the content of the pages in memory and stream them out
from your servlet?
Maybe I'm getting it completely wrong, but imo your servlet is a 3
liner (simplified version):
doGet(req,res){
res.setHeader();
res.getOutputStream().write(Cache.getFileContent(getFileName(req)));
res.getOutputStream().close();
}
Also, if you care about static performance so much, why don't you use
something fast? lighttpd? squid? I mean it's not a secret that apache
httpd is NOT fast.
I can't explain our whole web-app in detail here, just that much:
We've developed our own SSO-procedure (since the whole wep-app
contains protected content served over SSL to authenticated users
only). It was just easier for us to use the combination of Apache
httpd and Tomcat since there's quite some stuff available.
Since now the performance meets our expectations, there's no need to
use other web-servers like squid.
besides, we got quite some knowledge regarding Apache here, so why
should we dump that (a matter of cost)?
That's an argument I'm buying :-)
Cheers
Greg
regards
Leon
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Hmm, interesting reading. Still, since you can guarantee that everything is in memory if you customize your webapp, and apache httpd simply relies on the file system cache which has it's own behaviour, not designed for your webapp, a single filesystem miss will cost more time than you'll ever win by maybe saving some system calls. I also assume that a modern server will never reach its cpu limit before reaching the bandwith limit by simply writing out data. Correct me if I'm wrong. regards Leon On 1/10/07, Mikolaj Rydzewski [EMAIL PROTECTED] wrote: Leon Rosenberg wrote: Sure, I could write my own filters and pass the static content through them first, but that'd slow down the whole app (tested). Could you explain this a little more? How can it be that if you write out something from memory it's slower than ask the filesystem which could eventually have it in cache and be comparable fast in _best_ case? Ever heard about sendfile()? http://builder.com.com/5100-6372-1044112.html http://www.freebsd.org/cgi/man.cgi?query=sendfilesektion=2 How could you expect a few system calls (when apache processes the request) be slower than hundreds of calls when JVM processes the request? -- Mikolaj Rydzewski [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]
Re: Securing Tomcat Article for Review
Hi Leon,
On 1/10/07, Leon Rosenberg [EMAIL PROTECTED] wrote:
Aehm,
the original thread was about security, and now you wrote performs
better, which I assumed referred to performance. If not - my fault
:-)
Well, we moved kinda of-topic here, sou you got me right.
What I actually wanted to say was:
- I absolutely agree to Markus who said
* don't use software if there's no need for it
* don't try to use Apache httpd to enhance Tomcat's security
However, I just wanted to emphesize that Apache/httpd / Tomcat is
quite a common real-world-scenario and due to this nobody should worry
that Apache httpd is BREAKING Tomcat's security AS LONG YOU KNOW YOUR
WAYS ROUND.
After that, I was asked why using Apache httpd anyways, and I tried to
explain why (because *here* it performs faster)
Do you hold the content of the pages in memory and stream them out
from your servlet?
Maybe I'm getting it completely wrong, but imo your servlet is a 3
liner (simplified version):
doGet(req,res){
res.setHeader();
res.getOutputStream().write(Cache.getFileContent(getFileName(req)));
res.getOutputStream().close();
}
Due to the number of our html/js-files we cannot hold them completely
in memory. With the principle of the filter you're right.
We tested this version (Tomcat/HeaderFilter) against
Apache/mod_headers, and Apache simply performed faster
That's an argument I'm buying :-)
I know, this is a Tomcat mailing-list here, and I shouted Jehova,
but guys, believe me, sometimes it's quite enlightening taking a look
over the fence ;)
Cheers
greg
--
what's puzzlin' you, is the nature of my game
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Leon Rosenberg wrote: Still, since you can guarantee that everything is in memory if you customize your webapp, and apache httpd simply relies on the file system cache which has it's own behaviour, not designed for your webapp, a single filesystem miss will cost more time than you'll ever win by maybe saving some system calls. Using sendfile() system call you win by not copying data through FS - IO cache - user space - JVM streams - network sockets, system 'just' copies data from FS/IO cache to network socket. Much, much more faster. You don't want to keep all static content in memory, for JVM to send it? ;-) I also assume that a modern server will never reach its cpu limit before reaching the bandwith limit by simply writing out data. The less resource expensive your solution is, the more apps/servers/etc you can run on single machine. That means less money you have to spend, or more bussiness you can run. -- Mikolaj Rydzewski [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Securing Tomcat Article for Review
Gregor Schneider wrote: On 1/10/07, Markus Schönhaber [EMAIL PROTECTED] wrote: Gregor Schneider wrote: that's definately not the case. Definitely? Hm, again such an absolute claim of yours for which you provide no facts to back it up. Markus: As I stated above: I presume you *know* what you*re doing and you *know* your ways around Tomcat and Apache httpd. That provided, again, it is *definately* not the case that you decrease security, full stop. It might be the case that in your usage scenario (and maybe even in mine) httpd doesn't have any negative impact on the overall security. But you know nothing about other people's usage scenarios. Therefore - IMO - a claim like i'm just saying that nobody should worry about this combination is useless (maybe even dangerous) without the ifs you've come up with now, full stop. Regards mks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Mikolaj Rydzewski wrote: Leon Rosenberg wrote: Sure, I could write my own filters and pass the static content through them first, but that'd slow down the whole app (tested). Could you explain this a little more? How can it be that if you write out something from memory it's slower than ask the filesystem which could eventually have it in cache and be comparable fast in _best_ case? Ever heard about sendfile()? http://builder.com.com/5100-6372-1044112.html http://www.freebsd.org/cgi/man.cgi?query=sendfilesektion=2 How could you expect a few system calls (when apache processes the request) be slower than hundreds of calls when JVM processes the request? Very few people will propably expect that. OTOH there is no need to let the JVM do all the work. As mentioned before, there's an interface to APR. Look for the useSendfile attribute of the APR Connector: http://tomcat.apache.org/tomcat-5.5-doc/apr.html#HTTP Regards mks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
On 1/10/07, Gregor Schneider [EMAIL PROTECTED] wrote:
Hi Leon,
On 1/10/07, Leon Rosenberg [EMAIL PROTECTED] wrote:
Aehm,
the original thread was about security, and now you wrote performs
better, which I assumed referred to performance. If not - my fault
:-)
Well, we moved kinda of-topic here, sou you got me right.
kind of :-)
What I actually wanted to say was:
- I absolutely agree to Markus who said
* don't use software if there's no need for it
* don't try to use Apache httpd to enhance Tomcat's security
However, I just wanted to emphesize that Apache/httpd / Tomcat is
quite a common real-world-scenario and due to this nobody should worry
that Apache httpd is BREAKING Tomcat's security AS LONG YOU KNOW YOUR
WAYS ROUND.
After that, I was asked why using Apache httpd anyways, and I tried to
explain why (because *here* it performs faster)
Actually, on my private server I do use an apache in front of 3
webcontainers (2 of them resin, one tomcat), but I have my reasons :-)
Mainly because I wanted all three to be accessable at port 80. And
because my sysadmin knows how to configure httpd, but not tomcat, and
his rate are lower than mine are, so its effectively cheaper:-)
So I'm not saying (and wasn't saying either) that there are NO REASONS
to run apache httpd with tomcat, but if you remember how this thread
started, the author of the article and OP suggested in his article to
put an apache / iis in front of tomcat to INCREASE security, and this
was imo a false thought.
I think we both now can agree that there are millions of absolutely
valid reasons
to run a httpd-tomcat combination, but that security isn't among them :-)
Ok?
Do you hold the content of the pages in memory and stream them out
from your servlet?
Maybe I'm getting it completely wrong, but imo your servlet is a 3
liner (simplified version):
doGet(req,res){
res.setHeader();
res.getOutputStream().write(Cache.getFileContent(getFileName(req)));
res.getOutputStream().close();
}
Due to the number of our html/js-files we cannot hold them completely
in memory. With the principle of the filter you're right.
We tested this version (Tomcat/HeaderFilter) against
Apache/mod_headers, and Apache simply performed faster
hmm, haven't you said you have 300.000 files? I don't know how large
your files actually are, but assuming 100K a fairly large size you 'll
need ~30 Gb of RAM to cache them all. Now a machine with 32 Gb of RAM
is pretty cheap nowerdays, so why not cache them?
That's an argument I'm buying :-)
I know, this is a Tomcat mailing-list here, and I shouted Jehova,
but guys, believe me, sometimes it's quite enlightening taking a look
over the fence ;)
Cheers
greg
Regards
Leon
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
On 1/10/07, Mikolaj Rydzewski [EMAIL PROTECTED] wrote: Leon Rosenberg wrote: Still, since you can guarantee that everything is in memory if you customize your webapp, and apache httpd simply relies on the file system cache which has it's own behaviour, not designed for your webapp, a single filesystem miss will cost more time than you'll ever win by maybe saving some system calls. Using sendfile() system call you win by not copying data through FS - IO cache - user space - JVM streams - network sockets, system 'just' copies data from FS/IO cache to network socket. Much, much more faster. As long as its in the io cache and haven't to be read from disk, right? You don't want to keep all static content in memory, for JVM to send it? ;-) Why not? If my sole purpose is to serve this content I would surely do this. I also assume that a modern server will never reach its cpu limit before reaching the bandwith limit by simply writing out data. The less resource expensive your solution is, the more apps/servers/etc you can run on single machine. That means less money you have to spend, or more bussiness you can run. Irrelevant if the bandwidth is your limit. I don't care whether my server has 50% idle time or 20% if it just simply not able to send more because of the bandwidth limitation. And if the concurrency is your problem (meaning you have far too many clients) than I think context switches will be more of a problem than copying. At least that was the problem we had with apache serving static content (long time ago). However this is completely off-topic by now, so lets just abandon this branch :-) regards Leon -- Mikolaj Rydzewski [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]
Re: Securing Tomcat Article for Review
Hi Leon, I think we both now can agree that there are millions of absolutely valid reasons to run a httpd-tomcat combination, but that security isn't among them :-) Ok? Absolutely! hmm, haven't you said you have 300.000 files? I don't know how large your files actually are, but assuming 100K a fairly large size you 'll need ~30 Gb of RAM to cache them all. Now a machine with 32 Gb of RAM is pretty cheap nowerdays, so why not cache them? Nope, I said 30.000. However, most of those pages do contain images, and our servers have merely 4 GB of RAM each. Besides, I wouldn't consider a machine that can handle 32 GB of RAM as cheap, but that depends on everyone's personal (or the company's) wallet *cough* Cheers Greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Markus, Therefore - IMO - a claim like i'm just saying that nobody should worry about this combination is useless (maybe even dangerous) without the ifs you've come up with now, full stop. OK, we absolutely disagree on that one - so can we leave it at that? You got the honor of the final word: A simple yes will do Cheers Greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
but if you remember how this thread started, the author of the article and OP suggested in his article to put an apache / iis in front of tomcat to INCREASE security No I didn't, but if that's how you interpreted the section on 'running on port 80' then it needs to be reworded accordingly. http://www.owasp.org/index.php/Securing_tomcat#Using_Port_80 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
On 1/10/07, Gregor Schneider [EMAIL PROTECTED] wrote: hmm, haven't you said you have 300.000 files? I don't know how large your files actually are, but assuming 100K a fairly large size you 'll need ~30 Gb of RAM to cache them all. Now a machine with 32 Gb of RAM is pretty cheap nowerdays, so why not cache them? Nope, I said 30.000. However, most of those pages do contain images, and our servers have merely 4 GB of RAM each. Besides, I wouldn't consider a machine that can handle 32 GB of RAM as cheap, but that depends on everyone's personal (or the company's) wallet *cough* :-) HP sells 2 double-cored xeons machines with 16 GB ram for ~10.000 USD LISTPRICE. Cheap? Cheers Greg -- Leon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
On 1/10/07, Darren [EMAIL PROTECTED] wrote: but if you remember how this thread started, the author of the article and OP suggested in his article to put an apache / iis in front of tomcat to INCREASE security No I didn't, but if that's how you interpreted the section on 'running on port 80' then it needs to be reworded accordingly. Sorry, my fault, that was probably the conclusion of the overall direction of the article towards security. But you know - perception is reality :-) regards Leon http://www.owasp.org/index.php/Securing_tomcat#Using_Port_80 - 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]
Re: Securing Tomcat Article for Review
That's 16GB, and I wouldn't consider it cheap. Besides, our company is renting the servers since we don't just put some machines down in our private bunker ;) Bute Leaon, we#re eally getting off-topic here, so if you want to discuss this isse further, feel free to drop me a line on my private email-adress. Cheers! Greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/01/2007, at 11:50 AM, Mikolaj Rydzewski wrote: Leon Rosenberg wrote: Sure, I could write my own filters and pass the static content through them first, but that'd slow down the whole app (tested). Could you explain this a little more? How can it be that if you write out something from memory it's slower than ask the filesystem which could eventually have it in cache and be comparable fast in _best_ case? Ever heard about sendfile()? http://builder.com.com/5100-6372-1044112.html http://www.freebsd.org/cgi/man.cgi?query=sendfilesektion=2 sendfile is only interesting if you are delivering static content. If 90% of your content is dynamic/ being created by tomcat you will end up with a significant performance decrease if you stream every request through Apache. What I ended up doing on a customer site to separate images from content is using .domain.com from dynamic content and image.domain.com for static content. Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFpRw2W126qUNSzvURAumeAJ9hru9xSbfeM4MttBRaSIuTwmo0TgCgjMg2 hakZka0QpvLjaVv3JAEKHQc= =MxXj -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Securing Tomcat Article for Review
I've been working on an article about securing tomcat for the Open Web Application Security Project (OWASP). The article details some quick and easy ways to improve the 'out of the box' security of tomcat from the perspective of a sysadmin. It's written with tomcat 5.5 in mind, but almost everything will apply to 6.0 when it is released. A lot of it will also apply to older versions of tomcat, but no specific testing has been done to establish this. Have a read of the article at https://www.owasp.org/index.php/ Securing_tomcat and reply to the list with any comments - good or bad!. Thanks, Darren - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Who's the target audience? Things like: Change files in CATALINA_HOME/conf to be readonly (400) ... Rename CATALINA_HOME/conf/server.xml to CATALINA_HOME/conf/server-original.xml and rename CATALINA_HOME/conf/server-minimal.xml to CATALINA_HOME/conf/server.xml. The minimal configuration provides the same basic configuration, but without the nested comments is much easier to maintain and understand. Do not delete the original file as the comments make it useful for reference if you ever need to make changes - e.g. enable SSL. won't work for dummies (due to missing rights) if they'll follow the guide step by step. Make sure tomcat user has read/write access to /tmp and write (300 - yes, only write/execute) access to CATALINA_HOME/logs What is the sense of it? I mean if the tomcat user owns this directory why remove read access to it? If you are on a Windows machine you will be able to change the port attribute of the connector within the Catalina service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider; * Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat Using IIS in front, are you kidding ?:-)) It's like open your arms and welcome every single intruder on the net :-) Also by using apache in front of tomcat you rather loose security than gain it. At least this is my personal opinion :-) Overall a nice article which I think provides a good quick-start. regards Leon On 1/9/07, Darren [EMAIL PROTECTED] wrote: I've been working on an article about securing tomcat for the Open Web Application Security Project (OWASP). The article details some quick and easy ways to improve the 'out of the box' security of tomcat from the perspective of a sysadmin. It's written with tomcat 5.5 in mind, but almost everything will apply to 6.0 when it is released. A lot of it will also apply to older versions of tomcat, but no specific testing has been done to establish this. Have a read of the article at https://www.owasp.org/index.php/ Securing_tomcat and reply to the list with any comments - good or bad!. Thanks, Darren - 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]
Re: Securing Tomcat Article for Review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leon, Leon Rosenberg wrote: Also by using apache in front of tomcat you rather loose[sic] security than gain it. At least this is my personal opinion :-) Would you care to defend that argument? Security in layers is typically an advantage. One could argue that more moving parts equals more complexity, and that complexity is an enemy of security (and I agree). However, there must be a balance. If good security requires layers, and each layer adds more complexity, then there is a paradox. I would argue that Apache httpd is quite mature and is trustworthy. Sure, you're not likely to run into a buffer overflow bug in Tomcat, but a bad configuration can open any server to attack. Is a bad Tomcat configuration alone any better than a bad Tomcat configuration sitting behind Apache httpd? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo8C89CaO5/Lv0PARAnX2AJ0Vs2I9FE00UIjQ6jVCtgO6lvKE4ACgmZzJ nXtOo4PTAvDjtuwNwOHuNbk= =biDW -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
On 09/01/2007, at 5:20 PM, Christopher Schultz wrote: Leon Rosenberg wrote: Also by using apache in front of tomcat you rather loose[sic] security than gain it. At least this is my personal opinion :-) Would you care to defend that argument? Security in layers is typically an advantage. One could argue that more moving parts equals more complexity, and that complexity is an enemy of security (and I agree). However, there must be a balance. If good security requires layers, and each layer adds more complexity, then there is a paradox. With Apache HTTPD you have the advantage of being able to do fine grained url/ IP access control. It also brings with it however all the bugs that are in Apache HTTPD. What are your trying to protect by adding in Apache HTTPD? The IP Stack ? - Nope kernel issue - have this problem with both... Tomcats connection handling ? Nope - not protected as mod_proxy and mod_jk blindly forward all traffic towards the backend tomcat. So unless you want protect certain paths, hiding tomcat behind an apache will not bring any security benefits. Regards Andrew - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Securing Tomcat Article for Review
From: Christopher Schultz [mailto:[EMAIL PROTECTED] I would argue that Apache httpd is quite mature and is trustworthy. Sure, you're not likely to run into a buffer overflow bug in Tomcat, but a bad configuration can open any server to attack. Is a bad Tomcat configuration alone any better than a bad Tomcat configuration sitting behind Apache httpd? Depends on the quality of the httpd configuration, which is then another thing for a new administrator (presumably the person this document is aimed at) to get wrong, or at least not completely right. Setting up the httpd-jk-Tomcat link is also somewhat ticklish, and debug steps taken during this process (which may grant wider access than required in order to eliminate security concerns from the list of possibilities) may not always be reversed, leaving holes in the final system. For myself, I'd rather configure a good firewall in front of Tomcat than use httpd solely for the purpose of security. That's using a tool for a purpose for which it was not designed. - Peter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Christopher Schultz wrote: Leon Rosenberg wrote: Also by using apache in front of tomcat you rather loose[sic] security than gain it. At least this is my personal opinion :-) Would you care to defend that argument? You defend it yourself in the next paragraph you've written. One could argue that more moving parts equals more complexity, and that complexity is an enemy of security (and I agree). However, there must be a balance. If good security requires layers, and each layer adds more complexity, then there is a paradox. Exactly. I would argue that Apache httpd is quite mature and is trustworthy. Sure, you're not likely to run into a buffer overflow bug in Tomcat, but a bad configuration can open any server to attack. Is a bad Tomcat configuration alone any better than a bad Tomcat configuration sitting behind Apache httpd? IMO you're missing the point. If your Tomcat configuration is bad then what I would consider the right measure to be taken is change the Tomcat configuration so that it becomes good. I wouldn't consider it a wise idea to put a httpd in front of a badly configured Tomcat and thereby hope to improve things. httpd may be mature and trustworthy but whether it's secure largely depends on how skillful and careful httpd's configuration is crafted. And if someone isn't able to build a good configuration for Tomcat, I doubt that he'll be able to come up with really, really good configuration for httpd, this way compensating the former with the latter . Anyway: AFAIR (can't reach owasp.org atm) the Article mentions putting httpd in front of Tomcat as one means among others to work around the fact that on Unix-like systems Tomcat alone can't bind to port 80 if running under a restricted account. No question, this is one possible solution. But whether or not it's the right solution to chose is a entirely different question. If someone asks: I've a server running Tomcat. Tomcat is all I need and it's working fine. The only thing that bugs me is: How can I make Tomcat accessible via port 80 without running it as root? In this case answering Easy! Just install httpd, install mod_jk, configure httpd, configure mod_jk, configure Tomcat to accept requests via AJP and voilá, you're set, I would call completely brain-dead. OTOH: in an environment where there's already an httpd installed that can't be replaced by Tomcat, using this httpd as a frontend to Tomcat might be exactly the way to go. Maybe the article could provide some hints on how to decide which of the possible solutions might be the best for a given circumstance. Regards mks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
well, putting up apache in front of tomcat usually is not done due to security-reasons. however, doing so won't do any harm if you know what you're doing... ;) the only reason putting up apache in front usually is to serve static content when running a high-load-web-app. besides, you can do quite some tricky stuff regarding url-rewriting and so on which is quite difficult to accomplish when using tomcat only. however, if somebody wants to run tomcat on port 80, on unix, this can easily be achieved with the jsvc-tool (see http://tomcat.apache.org/tomcat-5.5-doc/setup.html), on windows it's not an issue anyway. btw., a word to andrew: and mod_jk blindly forward all traffic towards the backend tomcat. you know about apache httpd and you read and understood the options about how to configure mod_jk (http://tomcat.apache.org/connectors-doc/reference/apache.html)? cheers greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Things like: Change files in CATALINA_HOME/conf to be readonly (400) ... Rename CATALINA_HOME/conf/server.xml to ... won't work for dummies (due to missing rights) if they'll follow the guide step by step. You're right, the ordering is perhaps a little confusing. The article is not aimed specifically at people who are new to sysadmin work, rather those who are new to (or just in doubt of how to secure) tomcat. I'd hope these people would realise they have to make a file writable before they try to edit it. Anyway: AFAIR (can't reach owasp.org atm) the Article mentions putting httpd in front of Tomcat as one means among others to work around the fact that on Unix-like systems Tomcat alone can't bind to port 80 if running under a restricted account. I think the 'running on port 80' section needs some rewording as I'm not advocating that putting IIS or apache infront of your tomcat installation will make it any more secure. As a sysadmin you may be asked to serve tomcat based pages on port 80 so it is presenting the options without bias towards any of them. Perhaps I need to add some bias, from a security perspective, to prevent misunderstanding ... - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Did you read the article that is subject to this thread? Gregor Schneider wrote: putting up apache in front of tomcat usually is not done due to security-reasons. however, doing so won't do any harm if you know what you're doing... ;) Whatever you're doing, it's always a good idea to know what you're doing. The question why someone usually puts httpd in front of Tomcat wasn't subject of this sub-thread. the only reason putting up apache in front usually is to serve static content when running a high-load-web-app. besides, you can do quite some tricky stuff regarding url-rewriting and so on which is quite difficult to accomplish when using tomcat only. Usually the only reason? How do you know? As I said before, what answers might be given to the question why wasn't what I was talking about. however, if somebody wants to run tomcat on port 80, on unix, this can easily be achieved with the jsvc-tool (see http://tomcat.apache.org/tomcat-5.5-doc/setup.html), on windows it's not an issue anyway. Which is another among multiple ways the article presents as possibilities to make Tomcat accessible via port 80. Nobody doubted that. I don't think I understand how your post relates to mine. Regards mks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Hi Markus, On 1/9/07, Markus Schönhaber [EMAIL PROTECTED] wrote: Did you read the article that is subject to this thread? yep I don't think I understand how your post relates to mine. My post relates to yours and to some other posts here in that sense that you (and others) stated that putting apache httpd in front of tomcat would decrease security. that's definately not the case. when reading those posts, somebody might think that putting apache in front might even break security. since it's a real-world-scenario having apache httpd in front of tomcat, i'm just saying that nobody should worry about this combination. however, to make it clear: you are right, putting apache in front TO IMPROVE SECURITY doesn't make sense. OTOH, i'd rather have apache in front than running tomcat on port 80 via jsvc or as a service. cheers greg -- what's puzzlin' you, is the nature of my game gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Securing Tomcat Article for Review
From: Gregor Schneider [mailto:[EMAIL PROTECTED] Subject: Re: Securing Tomcat Article for Review OTOH, i'd rather have apache in front than running tomcat on port 80 via jsvc or as a service. Why? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew, Andrew Miehs wrote: With Apache HTTPD you have the advantage of being able to do fine grained url/ IP access control. I believe that Tomcat also has that capability. Am I wrong? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo++Z9CaO5/Lv0PARAn/SAJ9ndaX70Z5AkiN0OegwxoKKM40FSQCgmK8X JD9SROlWMCBBVxmW3YWC2NQ= =Q066 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus, Markus Schönhaber wrote: You defend it yourself in the next paragraph you've written. One could argue that more moving parts equals more complexity, and that complexity is an enemy of security (and I agree). However, there must be a balance. If good security requires layers, and each layer adds more complexity, then there is a paradox. Exactly. I believe I raised a question, rather than defending a point. I'm suggesting that things are more complicated than the sound bites that some people like to drop. I would appreciate my FUD to come with a side order of empirical evidence. For instance, if Leon had said I've had bad security experiences with Apache httpd, well, then at least he would have actually been making a statement. As much as I think that MS IIS is a steaming pile of crap, it is not a foregone conclusion that running MS IIS implies that you will be hacked to bits by tomorrow morning. The same is true with Apache httpd, except that I'm guessing that most members on this list are less likely to jump all over Apache httpd than they are to do so with MS IIS. I would just urge posters to the list to post something more than product X sucks or . I hate having wasted my time to read a message that does not move the dialog forward (not that I'm saying that Leon's message was a waste of time). Let's all endeavor to provide proper context and be precise in what message we are trying to communicate. Leon's message says flat out that adding Apache httpd reduces security, and provides no basis for that statement. A more appropriate statement might have been that Apache does not add any appreciable measure of security as Tomcat provides the same kinds of protections against unauthorized access, etc. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo/KZ9CaO5/Lv0PARAuWEAJ46lQOQ91ln8VgHBTT42z5RM9HP1ACgg4BO vchsGJ0tN6oSIw7CYq/MoVE= =zkQ5 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darren, Darren wrote: I think the 'running on port 80' section needs some rewording as I'm not advocating that putting IIS or apache infront of your tomcat installation will make it any more secure. As a sysadmin you may be asked to serve tomcat based pages on port 80 so it is presenting the options without bias towards any of them. Perhaps I need to add some bias, from a security perspective, to prevent misunderstanding ... Perhaps you should have a section on related questions. You could include a discussion of the reasons why Tomcat cannot bind to port 80 on many operating systems, and what options are available. It is good for admins to understand that it's not the fault of Tomcat or Java; it's the OS's restriction on user rights. Apache httpd has the exact same restrictions, although it comes with the capability to startup as root and then drop privileges. I don't believe the same is true for Tomcat. If security concerns are something to be raised for a particular option (for instance, use of some well-known bad version of a web server), then you should definitely point those out. One thing that you should mention is that running Tomcat (or any other service for that matter) as root is probably not the best answer. Encourage your readers to consider other options such as jsvc, Apache, IIS or whatever. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo/P/9CaO5/Lv0PARAo+8AKC2Q7fUU1FWSABZn3FE3ITx/yrurwCgnDXj PiVW+DMYQNWBj3re0VOzk8M= =s9Kj -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
On 1/9/07, Christopher Schultz [EMAIL PROTECTED] wrote: Leon's message says flat out that adding Apache httpd reduces security, and provides no basis for that statement. A more appropriate statement might have been that Apache does not add any appreciable measure of security as Tomcat provides the same kinds of protections against unauthorized access, etc. Allow to explain this. As other posters already explained puting a httpd in front of tomcat doesn't increase security. The only way it could increase it, would be if it could handle known security issues and protects the tomcat from the usage of such exploits. Personally I don't know of any, and even I did, I would doubt that putting httpd in front would be the best solution, or that httpd can protect something better than a firewall, which is actually desinged to protect. Httpd is not. Can we agree that httpd doesn't increase security now? Now, moving on, if httpd doesn't increase security, it has a) zero impact or b) decreases it. As for option a) (despite I don't believe it) even if it would have zero effect, there is always a possibility for human factor (mistakenly released configs or something). So even with the option a) the solely presence of httpd wouldn't reduce security, it's presence would give more opportunity for the human to fail, and therefor reduce security indirectly. As for option b): httpd is a lot of code. Any contains bugs. So chances are good that httpd will add own bugs to the existing tomcat bugs without hiding some of them. So the overall bug count will increase therefor increasing the number of possbile security-relevant bugs. Therefore decreased security. q.e.d :-) However, puting a firewall in front of any webserver to protect it the host and the server from attacks he can't deal with, seems a very good idea to me :-) best regards Leon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Gregor Schneider wrote: On 1/9/07, Markus Schönhaber [EMAIL PROTECTED] wrote: Did you read the article that is subject to this thread? yep I don't think I understand how your post relates to mine. My post relates to yours and to some other posts here in that sense that you (and others) stated that putting apache httpd in front of tomcat would decrease security. Wrong. I never stated that an httpd in front of Tomcat would *always* decrease security. Please read again what I wrote. Indeed, I do think that putting an httpd in front of Tomcat *without need* is dumb, needlessly adds al level of complexity to the system and potentially decreases the overall security of the system. OTOH there a very good reasons to use a httpd-Tomcat combination. Alas, the only reason there usually is, as you said, I wouldn't count amongst the good reasons. Tomcat serves static content just fine. In combination with APR even finer. I've never seen it necessary to use httpd just because of static content. I've read this claim (httpd is superior for static content) many times, but I've never seen the one making that claim also providing facts that back up it's truth. Of course, YMMV. Top of *my* list of good reasons for using httpd and Tomcat together is a httpd that acts as load-balancer for multiple Tomcat instances. Second comes the httpd that's already there and isn't going away. This one obviously is already part of the system's complexity and therefore won't add to it. that's definately not the case. Definitely? Hm, again such an absolute claim of yours for which you provide no facts to back it up. when reading those posts, somebody might think that putting apache in front might even break security. And he might think right. If you're adding complexity to the system you should be aware that there's the need to add even more sensible care to the system. If you fail to do that, the overall security will very propably be lower. As I see it, the chain of security is just as strong as it's weakest link. Likewise a httpd that is configured perfectly secure won't help if the Tomcat it handles requests to can be bugged into starting a root shell. since it's a real-world-scenario having apache httpd in front of tomcat, i'm just saying that nobody should worry about this combination. My point is: one should worry about every piece of software installed. Even more so if it is accessible from an untrusted network. The more software, the more there is to worry about. however, to make it clear: you are right, putting apache in front TO IMPROVE SECURITY doesn't make sense. OK, at least wrt this point we see things the same way. OTOH, i'd rather have apache in front than running tomcat on port 80 via jsvc or as a service. I'd like to repeat Chuck's question: why? Regards mks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Securing Tomcat Article for Review
Christopher Schultz wrote: Markus Schönhaber wrote: You defend it yourself in the next paragraph you've written. One could argue that more moving parts equals more complexity, and that complexity is an enemy of security (and I agree). However, there must be a balance. If good security requires layers, and each layer adds more complexity, then there is a paradox. Exactly. I believe I raised a question, rather than defending a point. Hm. In this case, I obviously missed your point - and I didn't understand your question either. I'm suggesting that things are more complicated than the sound bites that some people like to drop. I would appreciate my FUD to come with a side order of empirical evidence. For instance, if Leon had said I've had bad security experiences with Apache httpd, well, then at least he would have actually been making a statement. OK, we can agree on that. I also consider absolute statements like Don't install httpd! It will always breach the system's security! as useless as statements like You know nothing about httpd? Pah! Just go ahead and install it. There's absolutely nothing to worry about. I would just urge posters to the list to post something more than product X sucks or . I hate having wasted my time to read a message that does not move the dialog forward (not that I'm saying that Leon's message was a waste of time). Let's all endeavor to provide proper context and be precise in what message we are trying to communicate. Agreed. Leon's message says flat out that adding Apache httpd reduces security, and provides no basis for that statement. A more appropriate statement might have been that Apache does not add any appreciable measure of security as Tomcat provides the same kinds of protections against unauthorized access, etc. True. Nevertheless, Leon has elaborated what he meant to say in his answer to your post (the one I'm also replying to atm). And the opinion he expresses there is quite similar to mine. To repeat once again: I'm not bashing httpd, Tomcat, IIS or whatever. I'm simply saying: if there is a good reason to install a particular piece of software, go ahead, install it *and* take care of it. If you don't see this good reason, don't install it. And I consider installing httpd *only* to make Tomcat accessible via port 80 not a good reason. I consider this plain dumb. Regards mks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
