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?

asked by x77686d

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.

Using iptables:

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.

answered by pidster on August 19, 2010 08:39 AM

Read More

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).

asked by fealfu

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.

answered by pidster on August 5, 2010 08:40 AM

Read More

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 ?

asked by amin123

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:

• FIPS 140-2 Level 1 is the lowest, imposes very limited requirements; loosely, all components must be "production-grade" and various egregious kinds of insecurity must be absent.
• FIPS 140-2 Level 2 adds requirements for physical tamper-evidence and role-based authentication.
• FIPS 140-2 Level 3 adds requirements for physical tamper-resistance (making it difficult for attackers to gain access to sensitive information contained in the module) and identity-based authentication, and for a physical or logical separation between the interfaces by which "critical security parameters" enter and leave the module, and its other interfaces.
• FIPS 140-2 Level 4 makes the physical security requirements more stringent, and requires robustness against environmental attacks.

Additionally, FIPS 140-2 certification covers eleven software development and production areas:

• Cryptographic module specification (what must be documented)
• Cryptographic module ports and interfaces (what information flows in and out, and how it must be segregated)
• Roles, services and authentication (who can do what with the module, and how this is checked)
• Finite state model (documentation of the high-level states the module can be in, and how transitions occur)
• Physical security (tamper evidence and resistance, and robustness against extreme environmental conditions)
• Operational environment (what sort of operating system the module uses and is used by)
• Cryptographic key management (generation, entry, output, storage and destruction of keys)
• EMI/EMC
• Self-tests (what must be tested and when, and what must be done if a test fails)
• Design assurance (what documentation must be provided to demonstrate that the module has been well designed and implemented)
• Mitigation of other attacks (if a module is designed to mitigate against, say, TEMPEST attacks then its documentation must say how)

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.

.

answered by avanabs on August 5, 2010 08:43 AM

Read More