How to lock down LAMP + Railo on Ubuntu Linux

  Follow me: Follow Bruce Kirkpatrick by email subscription Bruce Kirkpatrick on Twitter Bruce Kirkpatrick on Facebook
Tue, Apr 08, 2014 at 5:40PM

My Jetendo Server project covers security for the entire operating system plus specifics for the main web applications (Linux, Apache, Nginx, PHP, MariaDB and Railo) using Ubuntu 12.04 LTS minimal as the base install.
Starting from a minimal Linux install is better since you have full knowledge of what you've install and you can reproduce everything and it's all free software.  It's easier to upgrade / understand.   Cpanel/plesk take over too much and lock you in to older software somewhat.
You can go through the project readme step-by-step to build your own system with all of the features or some of them.  This makes it easier to know what you're getting and you don't have to trust me.
There is also a pre-built virtual machine on that makes it easier to work with the same environment on your development machine.  It is preconfigured to let you work off files that are on your host OS, so the guest machine image stays small and replaceable.  Through the use of mounts, symbolic links and install scripts, many of the configuration files are stored in a central directory, which makes it easier to verify the integrity of the system, make backups, and more. 
The use of AppArmor, more strict filesystem permissions and various kinds of monitoring systems like Monit and custom scripts make my solution a bit more thorough then many guides you'll find especially if you use Jetendo CMS instead of other software.
Part of the project tells you how to use SSH tunneling with the virtual machine and your production server.  Essentially, you need to route all administrative access through a non-public port through an SSH tunnel.   And you should use RSA keys with SSH instead of password based authentication.  I use a smart card to store the private key, but you can use key files or other authentication if you wish.   
Once the server software is setup securely, your weakest link becomes your own source code.   You have to make sure you don't allow any of your code to call internal private URLs, upload executable code, or modify the system through CGI parameters in an undesirable way that can bypass your security.  This is something that is less of a concern with Jetendo CMS, since it has so many conventions and features in place to prevent developer mistakes.
In the past, I redesigned my app so that the source code files could be stored in read-only directories/files, and that's enforced by the AppArmor configuration for the following processes: MariaDB/PHP/Nginx/Railo.  This makes it mandatory to have root access to change the source code, which is much more strict compared to most systems which are setup to let FTP users write to those directories.  If an attacker gain partial access, but then can't execute code without root access, it will be harder to compromise the rest of the system.   I wrote a deploy tool to automate deployment to 1 or more servers, clear cache, and fix permissions, so it becomes easier to use this very strict configuration without using FTP.   To take advantage of this, you'd have to install Jetendo CMS according to the Jetendo Server readme instruction and learn how to use it for configuring sites.  Jetendo CMS tries to make server management easier over time by monitoring and repairing the configuration.  Jetendo CMS can also run with the Railo sandbox in the strictest configuration (no cfexecute, no java) and with Railo CFADMIN tag access disabled.  Read more about the Jetendo CMS security features.
I'm trying to automate/document multi-server configurations in the future, so I have some of that in the Jetendo Server project now, but it's incomplete.
Whether you use my project or do your own, I found it is really great if you write down every command line you've executed to change the system configuration.   This makes it easier to start over on a new OS someday.  Writing your own documentation is really important when it comes to making production upgrades safer and more predictable.

Bookmark & Share

Popular tags on this blog

Performance |