In section 2.1 of "Tomcat: The Definitive Guide" 2nd edition, the authors write, "...we have not heard even a single reported incident where a machine's security was compromised because Tomcat was running as root."
Does anybody know if that claim still stands?
I am not aware of a case, but that doesn't mean it hasn't happened.
Running as root is discouraged because an attacker who manages to compromise a server will then have substantially increased ability to further attack the system.
The nature of the question indicates that a Unix-like system is in use, which also means that iptables or ipfw are likely to be available - making it possible, trivial even, to run Tomcat on a port higher than 1024 under a dedicated user.
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 127.0.0.1:8080
or ipfw (BSD / OS X):
ipfw add 100 fwd 127.0.0.1,8080 tcp from any to any 80 in
The jsvc (called tomcat-native in Tomcat 7.0) unix daemon is shipped with each release, starts as root, but runs Tomcat under a specified user, also making it simple to place a service control script in /etc/init.d/.
Security and hardening aren't just a matter of protecting a single server - one compromised server inside a network can easily lead to more machines being attacked and compromised both inside an enterprise and outside.
When it's this easy to run Tomcat with it's own user account, there's really no reason not to.
Hi, I have Tomcat 5.0.28 running on more than one client with a SSL connector that allows identification with spanish certificates FNMT, DNIe and Camerfirma (among others).
The first thing to note is that you are currently running an unsupported version of Tomcat, which in Apache terms means that it's extremely unlikely to get any more upgrades or patches. It's in beta now, but a stable release of Tomcat 7.0 is likely to happen towards the end of this year, which will put you a full 3 versions behind the current release.
A detailed answer to the question requires more information, such as the exact versions of the server operating system, the JVM type and version, how you've configured the SSL connector and whether you're using APR or not.
This type of problem most often appears when a client has unexpectedly terminated the request, or disconnected before the request has completed, implying that the source is at the client end of the connection - it's often an unintended consequence of a user deciding to view a different page before a previous request has finished.
In your case, you state that some clients are not having the same problem; in order to track down the source you should monitor the access, error and application logs and match individual requests to the log entries. Look for commonalities between source IP address, User-agent and try to get exact details of the environment of the client which has identified the problem. If there is definitely only one client experiencing the problem, then you'll need to determine what's different about their configuration. It's possible that there's nothing wrong with your application, but that a server or network misconfiguration is the cause of the fault.
Even recent releases of the Sun JDK/JRE don't have all of the Certificate Authorities in use currently, which is another possibility for the cause - though I wouldn't expect to see a connection reset event as a symptom - but still, check the client isn't using a certificate from a new CA.
I can't guarantee it would make any difference, but I'd strongly recommend putting a testing and deployment plan together to bring your environment up to reasonably current versions, particularly as there are vulnerabilities in SSL which are likely to unpatched in the setup you describe. Tomcat 5.5 should be the minimum version you're running on, if upgrading the JVM to a recent version is a problem.
You've spent a lot of time setting up a private cloud of servers. Everything's virtualized and you have it organized by function. Your messaging VMs run on these hosts and your web servers run on those hosts. You've tested it extensively and you're happy with how everything talks to each other. The worst is over, right? Wrong. Now you have to move past the theoretical and actually use this thing in production. It's time to start deploying the applications you're building into this cloud of virtualized resources. It's time to develop some scheme to keep your applications updated when changes are made. Keep in mind, whatever mistakes you inject at this point will be multiplied by the number of machines that deploys to.
Don't be! It's really not that hard. In this article, I'll introduce you to some concepts I used in developing the fairly simple system of messages and scripts that deploy artifacts into our private cloud. This won't be a technical HOWTO so much as it will be a casual dinner conversation about the pitfalls and rewards. Above all, I want to get across that having a bunch of virtual machines that do the same thing doesn't have to keep you up at night.
A little under 18 months since work started on Tomcat 7 I am delighted to be able to say that the first Tomcat 7 release, Tomcat 7.0.0 beta, is now available from the Tomcat 7 download page at the Apache Software Foundation.
Over the years there have been a number of connectors developed to enable Apache httpd to communicate with Tomcat that have used a variety of protocols. When searching the web for information on how to do this, it isn't unusual to stumble across some really bad, out of date advice. So first of all the only options you should consider for this are:
All of the other other options have not been supported for a number of years so you should avoid mod_jk2, mod_jserv, mod_webapp and any other module that isn't discussed here.
My experience with providing support to SpringSource customers is that a typical customer is more likely to hit a bug in mod_proxy_ajp than they are in mod_jk or mod_proxy_http. It isn't that mod_proxy_ajp is particularly buggy, I used it myself for 18 months on a production system without a single issue, but that it has a few more bugs than the other two modules. The situation is improving but at the time of writing I would rank mod_jk and mod_proxy_http above mod_proxy_ajp.
Security Audits may identify issues with 500 errors, and require the stack traces to be suppressed.
By default when a 500 error (Internal Server Error) occurs in Tomcat it will display a full stack trace on the error page. This can give a hacker information about what technology is being used within the application. To control the error response, it is recommended to customize your own error reporting valve. The current error reporting valve is a good starting point and can be modified to meet your needs. To remove the stack trace element alone will mean removing two lines of code.
Here is the source to the current valve:
Is Tomcat be made FIPS complaint ? Or changing the Crypto Provider to a FIPS complaint Provider enough ? Because When starting up it needs to invoke the self tests in FIPS mode , how can tomcat achieve this ? Is there a Tomcat Start up configuration file that can achieve this ?
Since this question usually is about FIPS 140-2 ("Security"), we'll assume that is the focus of this question.
FIPS is primarily focused on Encryption and targets the development and production processes, although FIPS 140 at higher levels also includes several other security areas. FIPS certification may not be necessary in all cases. It is sometimes sufficient to be able to run Tomcat with a FIPS compliant JSSE provider. It all depends on the FIPS Level and specific requirements of the procurement. At higher levels, and in many more sensitive projects, not only does the encryption have to be FIPS compliant, but so does much of the invoking application.
There are a couple of commercial Encryption options, including ones from SpringSource that have successfully tested Tomcat 4, 5 & 6 with a FIPS certified JSSE provider on 1.5 and 1.6 JVMs.
FIPS comes in hierarchical layers, each assuming the Level below is met. These are:
Additionally, FIPS 140-2 certification covers eleven software development and production areas:
I am not aware of anyone who has taken Tomcat through FIPS, which is an ongoing process, not an event. FIPS certification requires extensive documentation of development and test processes and must be (partially) re-done each time a new version of the software is released. At higher levels, third party (there are a VERY limited number of authorized certification agencies) auditing and certification becomes part of the process, adding additional cost and product delay.
As such, it's inherently quite costly (high hundreds of thousands of dollars to low millions each time), so it requires a very significant commitment in time and third party fees on the part of the software provider. It also dramatically slows new releases, since FIPS certification adds months to development schedules, so it's generally only appropriate for relatively static software.
For development and operations teams, a presentation that covers various security configuration options available in Apache Tomcat and SpringSource tc Server.
A default Apache Tomcat installation is secure but each installation environment is different and may have additional security requirements. This presentation will examine the security configuration options available in Apache Tomcat and SpringSource tc Server, when to use them (and when not to use them) and the threats they might help mitigate. The rationale behind having resource passwords (e.g. for database access) in clear text in server.xml will also be discussed.
Moving a running service from HTTP to HTTPS involves creating a certificate keystore and editing the Tomcat configuration file.
Taking a service from running on an HTTP protocol on port 8080 to run on the HTTPS protocol on port 443 requires you to have a private key and signed certificate in place in order for the HTTPS connector to work. You will need to prepare the certificate keystore, edit the Tomcat configuration file and install the certificate on the target machine.
I am interested in becoming a contributor to TomcatExpert. What do I have to do to get Contributors status?
Contributors on TomcatExpert.com have editorial access to publish blogs, answers, and knowledge base items. Contributors also have the ability to moderate comments and dole out karma. In order to become a Contributor on this site, it is really best to simply contribute regularly! Comment on blogs, knowledge base articles and Ask the Expert questions. You can even submit content for blogs or the knowledge base which will score you even more points with the Contributors. You will get all the credit for the post, just a Contributor will have to review and publish it for you. Comments are also a good way to prove your mettle as a Tomcat Expert. If your comments are good, the current Contributors will recognize your post by doling out (or, if they're bad taking away!) karma. Same for submissions, except they are “worth” far more as it is original content and generally a lot more in depth work. Under the covers, it is a point system, although we only publish the levels so it doesn’t become too much of a numbers game. We’ve seen that behave badly in other communities. You’ll see yourself move up through the levels, and will eventually be formally asked if you want to be a permanent Contributor. It is also possible to "fast track" the contributor status if you are already a committer on the Apache Tomcat project. If you think you qualify for this, and are interested in contributing content and helping to moderate this site, please submit a question using this Ask The Experts forum stating your case to be considered as a Contributor and we'll review your case and get back to you with an answer.