Securing Middleware Products

My work is IT architecture, meaning I focus on the early steps of a project. Once the application is in production, I usually leave it to systems and production engineers. For example, for JVM fine tuning, most of the clients I worked for have people that have the right skills to do that.

Nevertheless, I need sometimes to sully my nails. This happens in two cases: when the client is too small to have such dedicated teams or when its production team are not experienced enough to handle the problem at hand. Believe it or not, it happened to me that I had to show WebSphere administrators how to connect JAAC connectors to a LDAP server.

Anyway, I always value information on how to handle cases out of my usual scope: first, it never hurts to know more. Second, it is sometimes handy to sort what production teams tell you: some is real stuff, some is bulls. Likewise, I invite production teams to learn about development so that they may sort what is told to them too. Learning the other’s craft let you increase comprehension between different teams.

Free checklist audits

This week, I learned about a site that propose free benchmarks to audit your infrastructure’s security. This site is the Center for Internet Security. Proposed benchmarks are two-fold: part document about what is audited, part benchmarking tool. The former is freely downloadable; as for the second part, you must register. The rest of this article will focus on the document.

Though many subjects will always be beyond my reach (I will never accept to secure an Oracle Database), one document is of utmost interest to me: the benchmark on Apache  Tomcat.

This file include rules that, once you comply with them, will make your product more secure. Even if most of them are no-nonsense and you could think about it yourself, the document make a nice check-list. Some rules are really interesting in that I am afraid they are seldom enforced, some because of neglect, some because of lack of knowledge of the product.

Enhancements

Checklists provided by the CIS do lack some things though:

• risk correlated to statistics. Some security holes aren’t used by many hackers. How should I prioritize?
• risk correlated to damage. What’s the potential damage of not underdoing this action? For example, session hijacking will compromize users interactions with my application, not my server
• trade-off. Many security features are not always desirable, and most have a trade-off, often in terms of performance. When I browse a merchant site, crypting my communications is overkill. Only during the payment phase is a real need to keep information secret.

Rules examples

For Tomcat, here’s is a sample of the audited rules.

Separate Web content directory from Tomcat’s system files

Tomcat comes with its own file structure, including a webapp directory where webapps should reside. Yet, nothing prevents webapps to be outside this directory, even on another partition. From a security point-of-view, this will avoid directory traversal exploits: if a malicious user gains access to the webapps directory, he will not have access to the server.

Moreover, from a maintenance point-of-view, you are able to upgrade Tomcat without redeploying your applications.

Disable session façade recycling

Tomcat’s model is to use façade on every entity of the HTTP model: request, response, session, etc. By default, Tomcat’s façades over sessions are reused when processing new requests in order to optimize memory use. Thus, this could lead a new request to have access to informations on sessions that are not tied to it. This is a security risk and should be turned off if one’s want to secure the server.

Disable auto-deployment

Tomcat’s default behaviour is to have a running thread that watches the webapps directory. Once a new war is detected by this thread, it deploys it automatically. Such action is very enjoyable in a development environment. In a production environment, users that have access to the directory could potentially put malicious webapps in it and have it deployed automatically. Thus, disabling auto-deployment increases the security of the Tomcat’ server.

Conclusion

Checklists provided by the CIS are very nice to have for production and security engineers. However, one should carefully evaluate the cost of enforcing the rule agains the risk of not enforcing it. Those are either not detailed enough in the documentation, or not provided at all.

From http://blog.frankel.ch