Securing Liferay Chapter 4: More lockdown

You probably know the basic installation instructions for Liferay Bundles: „unzip and run“ - with this you get to a working Liferay installation in a minute. It will run with all defaults - which might not be what you want in production.

This is part 4 of a series. Start with part 1 for "Introduction, Basics and Operating System Level", continue with part 2, "Liferay's configuration", part 3, "Port issues and http/https" and come back here. You might also want to check if more chapters are already available.

What to have in production

Browsing around the web, I see recommendations for tomcat's "manager" application all over. Yes, it's convenient. It also opens you up to attacks if that's available from the web. Whatever administrative UI you have installed on your production server, you might want to uninstall - or at least firewall to be available from specific networks only. This not only includes tomcat's manager (or related interfaces) but also phpmyadmin or whatever you use to maintain your database. I'd expect that this is not necessary to mention, but sadly it is.

If you rely on these components to be available, at least protect them with Apache (see chapter 3) and block access unless it's coming from trusted networks.

File access

In chapter 1 we set up Tomcat and changed the owner and permissions on the various files. You can extend this and look at the "soften" and "harden" options of the service starter script. As long as you don't expect any new deployments, it's good practice to have nothing but tomcat's temp, log and work directory writable by tomcat. Keep in mind that some of Liferay's "data" folder also needs to be writable, if you didn't change the locations of document library or lucene search index.

In addition, you might want to run your server within a java sandbox. For the server this will be really hard to achieve. As far as I know there's no policy file template that you could use as a starting point. However, there's help: You can run Liferay with a security manager, so that it runs plugins within a security manager. The plugins will have to be prepared for this, but you can mandate it for the applications that run on your server. See the Marketplace Developer Guides for more information on enabling security manager in plugins, called PACL.

Updates to tomcat

Patrick Wolf commented on chapter 1: Why not use your Linux distribution version of tomcat and install Liferay as a WAR archive on top of it? This will give you all updates to the appserver, while you have to maintain Liferay on your own. It will also solve logrotate issues, run as an unprivileged user by default etc. - And he's right. I've documented how to use the bundle just because it looks like everybody is using it and thought that these instructions are understood as "relevant" for this situation. The proper way to do it is what he suggests. You'll get your distribution's updates to tomcat with this. And as a side effect, Logrotation typically has also been implemented. Keeping your filesystems from overflowing is somewhat security related.

For EE customers, there's also an option to get a supported version of Tomcat. For users of other application servers: Keep an eye on your product. As this is outside of Liferay, we kindly ask you to keep overview over your platform yourself.

The installation of a WAR distribution of Liferay is well documented in the User's Guide (here for tomcat)

Updates to Liferay

if you're on Liferay EE, Liferay Cloud Services has some nice UI to keep you informed about updates that you can install. This way you're not missing out on any available fix - general improvement or security issue. Administering a web application should always mandate to keep it up to date. On EE you will get security advisories automatically. On CE you should subscribe to the Community Security Updates.


You might wonder why I'm listing SSO under security, not under general installation tipps. Well, there's one really neat aspect on a system composed from SSO, LDAP and Liferay: The user's passwords are never known by Liferay, thus they can't get lost in case any appserver or Liferay security issue would allow access to the underlying hash values.

Network and beyond-scope

I think IDS (Intrusion Detection Systems) and similar firewalls are out of scope for this blog series. You'll know if you need them - and then it's typically not because of Liferay but because of your overall security policy. I'll not cover all aspects of your security - still: pay attention to who has physical access to your server

Future Plans

Will there be more? The more input I get, the more I can add and update this series. Security isn't a state, it's a process. Potentially there's no limit to how long this can go. Watch out for future Radio Liferay episodes on DevOps and other related topics.