DevOps Zone is brought to you in partnership with:

Armel is the founder of ETAPIX Global - the Big Data Company (founded in 2006). He is an experienced software developer and architect. Based in London United Kingdom, Armel is known in the London startup scene and occasionally speaks at various events. His expertise is in Java, SOA, Business Intelligence, Enterprise Search and Data Warehousing. He has worked at various fortune 100 companies including Nokia Siemens Network, Tata, Barclays Plc, SMBC among others. He's also an Open Source evangelist. Armel has posted 7 posts at DZone. You can read more from them at their website. View Full User Profile

Hacking Liferay – Securing Against Online Vulnerabilities

02.09.2013
| 8287 views |
  • submit to reddit

This post has been posted with permission from etapix.com.

This is a brief post on securing Liferay on Tomcat and MySQL.

Liferay CE is stable enterprise portal, as more companies start to adopt it, therefore security becomes a very important aspect of the deployment. I am not sure if Liferay has been officially tested by a 3rd party security firm but based on my simple security test against OWASP  Top 10 vulnerabilities, I can say that it looks good in that aspect. Some of the recommendations are taken from their respective sites while others are based on our testing. We tested the following on Linux Ubuntu 12.04 LTS.

Here is what I did for a quick test (using default installation of liferay-portal-tomcat-6.1.1-ce-ga2-20120731132656558) :

1-  Download the Zed Attack Proxy (ZAP) from OWASP

2-  Make ZAP is set to run the following attacks:

a.  Path traversal

b.  Remote file Inclusion

c.  URL Redirector Abuse

d.  Server Side Include

e.  Cross Site Scripting

f.  SQL Injection

g.  Directory Browsing

h.  Session ID in URL rewrite

i.  Secure page browser cache

j.  External redirect

k.  CRLF injection

l.  Parameter tampering

3-  Run Liferay with default settings

4-  Now sit back and watch Liferay logs go “CRAZY”

Passing the OSWAP Top 10 vulnerabilities doesn’t mean that you are out of the water yet. This test just focuses on browser based penetration tests.

Here some steps to have an even more secured Liferay deployment on Tomcat.

-  Make sure Tomcat uses SSL to serve Liferay content

-  Make sure that you do not run Tomcat as “root” user

o  Tomcat user should not have remote access to the server

-  Disable auto-deployment of web applications

-  Change the file permissions on the Tomcat folder; all Tomcat files should be owned by “root” user with group Tomcat and whilst owner has read/write privileges, group only has read and world has no permissions. The exceptions are the logs, temp and work directory that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they can't change the Tomcat configuration, deploy new web applications or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.

-  Enable Tomcat Security Manager, this causes web application to be run in a sandbox

-  In Server.xml do the following:

o  Disable the shutdown port by setting its attribute to -1

o  Make sure that Tomcat HTTP connectors only to designated IP address; by default the connectors listen to all configured IP addresses

o  Configure the “ciphers” attribute used for SSL connections. By default, Tomcat uses the default ciphers for the JVM which contains weak export grade ciphers

There are more Tomcat settings which is available online.

You also need to make sure that you secure your Operating System and Network. Now that we have some basic security in place for Tomcat, let’s now tackle the our database. In this test, we used MySQL 5.

Here is some basic MySQL security:

-  Set a root password for MySQL

-  Remove all anonymous accounts

-  Disable non-local root access

-  Remove all test databases and any access rules related to them

-  Reload privilege tables to apply the changes

-  Enable SSL connection for MySQL, the default connection is unencrypted

Now to conclude, let’s secure our Liferay instance. Liferay is configured through portal.properties and you should override those settings in portal-ext.properties. Create the file if it doesn’t exist:

-  Set web.server.host=MY-HOST-NAME so that it is not dynamically set

-  Set the preferred protocol to web.server.protocol=https

-  If you want Liferay to be only accessible from certain IP addresses, set main.servlet.hosts.allowed=<IP-Address-1>,<IP-Address-2>,<IP-Address-n>

-  To make Liferay only accessible through HTTPS, set main.servlet.https.required=true

-  Secure the Axis servlet as follow:

o  axis.servlet.hosts.allowed=127.0.0.1,SERVER_IP

axis.servlet.https.required=true

-  Secure the JSON Tunnel Servlet as follow:

o  json.servlet.hosts.allowed=<LIST-OF-HOSTS>

json.servlet.https.required=true

-  Secure Liferay Tunnel Servlet as follow:

o  tunnel.servlet.hosts.allowed=127.0.0.1,SERVER_IP

tunnel.servlet.https.required=true

-  Secure Spring Remoting Servlet

o  spring.remoting.servlet.hosts.allowed=127.0.0.1,SERVER_IP

spring.remoting.servlet.https.required=true

-  Securing the Webdav Servlet

o  webdav.servlet.hosts.allowed=<LIST-OF-HOSTS>

webdav.servlet.https.required=true

-  Make sure you have configured the Admin portlet by overriding all the default values

-  The IFrame Portlet, when used in a high security environment, should have the following properties set

o  iframe.password.token.role=

-  JAAS security need to have properties set:

o  To stop user from passing in encrypted password: portal.jaas.strict.password=true

-  Passwords: Choose a strong password encryption algorithm to encrypt passwords by setting the following:

o  passwords.encryption.algorithm=<ENCRYPTION-NAME>

I am sure that many other security settings are left out so feel free to share in the comments. I hope this helps someone to secure their Liferay environment.

Published at DZone with permission of its author, Armel Nene.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)