Update 2021:
I dont like my old answer. I am not changing it. But I don't like it.
Before update 2010:
What would make Tomcat + Apache less secure?
- Larger surface of attack. More code
is parsing the request. So there is
larger chance that a security bug is
encountered/exploited.
- More fixes to install, More configuration files to get correct and more security setting to get right. Greater chance to human error.
What would make Tomcat + Apache more secure?
Don't know.
I don't see any php or java process taking up extra resources
That you think is worth checking at all, suggests you either know an awful lot about CGI vulnerabilities or very little about web serving / process management.
Ultimately, I'd like to see what kind of request is causing these issues
That's a sensible place to start. The easiest solution would be to install mod_security and configure it to log incoming requests (Apache only logs at the point where the response is dispatched). There are other approaches, such as sniffing the traffic (pastMon, Wireshark) or logging on a reverse proxy.
Is there a way to limit the amount of resources a single httpd child process may consume
Not directly, but you should set LimitInternalRecursion, LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, MaxKeepAliveRequests, MaxRequestsPerChild and Timeout to sensible values.
could I perhaps configure the oom-daemon to be more trigger-happy on the httpd processes
Messing the OOM Killer is nearly always a bad idea. Even if you think you know what you're doing. Does you java do anythiong useful in the absence of a webserver? If so then maybe you should think about running them on seperate machines.
Best Answer
The password is currently stored in plaintext in the config file. The alternative, which is often used in, say, DES-encrypted SSL private keys, is to use a symmetric algorithm to encrypt the sensitive data.
This would be no more secure than just storing the password in plaintext in the .xml file. The service would be configured with the encryption key of the encrypted secret (unless you require someone to be at the keyboard to enter the password every time the service starts), which can be used by an attacker to get at the encrypted data. This provides a layer of obscurity, but not a layer of security.