Joomla Lockdown Script for Apache

One of the main problems with Joomla is that if you use an old version or a bad component, you open your server up to being hacked. I’ve had to fix this problem time and time again. It’s not fun, it’s an epic waste of time and it makes me want to kill the hacker almost as much as the client usually wants to kill me.

Administering multiple servers is part of my day to day life and I needed a script to lockdown all Joomla installs reliably without messing with non-Joomla sites. Furthermore I needed a script that would iterate through my entire /home directory and recursively set all the permissions for all of my Joomla sites. At work, we had a security expert come in and brief us about some aspects of our current practices that needed to be improved. Based on his feedback I took the liberty of writing my Joomla lockdown script for Apache.

If you are a server admin and want to lockdown bulk Joomla sites in one go, this script might save you some typing. I haven’t tested the script since I made some changes but I’m sure you can do that. DO NOT CUT AND PASTE THIS SCRIPT AND RUN IT BLINDLY! I offer no warranty and if you screw your server up because you ran this without understanding what it does, please don’t come crying to me unless you’re willing to pay by the hour – I’m busy enough already 😛


#!/bin/bash

# Set the Home directory
dir=/home

# Start iterating thru the home directory
for i in $( ls -1 $dir ); do

# Test to see if the public_html exists and there is a folder called components before iterating into it
if [ -d "/home/$i/public_html/components" ]; then

# Rewrite all ownership to be the user account permissions
chown -R $i:$i /home/$i/public_html

# Descend into the public_html folder and begin fixing permissions
cd /home/$i/public_html

echo "--- Setting Generic Permissions ---"

# Indescriminately rewrite all permissions
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

echo "--- Generic Permissions Completed ---"

echo "--- Setting Images Permissions ---"
# Reset permissions for images to be writeable
chmod 1777 /home/$i/public_html/images
cd /home/$i/public_html/images
find . -type d -exec chmod 777 {} ;

echo "Creating .htaccess file..."
# Add an .htaccess file to the images folder so PHP files cant be executed
echo '
Order Allow,Deny
Deny from all
' > /home/$i/public_html/images/.htaccess
# Change the user on the .htaccess file so that it cant be modified by apache due to the sticky bit
chown root:root /home/$i/public_html/images/.htaccess
echo "File created."
echo "--- Image Permissions Completed ---"

# Check for DocMan, if it exists give it write permissions
if [ -d "/home/$i/public_html/dmdocuments" ]; then
echo "--- Setting DocMan Permissions ---"
chmod 1777 /home/$i/public_html/dmdocuments

echo "Creating .htaccess file..."
# Add an .htaccess file to the DocMan folder so PHP files cant be executed
echo '
Order Allow,Deny
Deny from all
' > /home/$i/public_html/dmdocuments/.htaccess
# Change the user on the .htaccess file so that it cant be modified by apache due to the sticky bit
chown root:root /home/$i/public_html/dmdocuments/.htaccess
echo "File created."
echo "--- DocMan Permissions Completed ---"
fi

# Check for Mosets Tree, if it exists give the images folder write permissions
if [ -d "/home/$i/public_html/components/com_mtree" ]; then
echo "--- Setting Mosets Tree Permissions ---"
cd /home/$i/public_html/components/com_mtree
chmod 1777 /home/$i/public_html/components/com_mtree/img
cd /home/$i/public_html/components/com_mtree/img
find . -type d -exec chmod 777 {} ;

echo "Creating .htaccess file..."
# Add an .htaccess file to the Mosets Tree images folder so PHP files cant be executed
echo '
Order Allow,Deny
Deny from all
' > /home/$i/public_html/components/com_mtree/img/.htaccess
chown root:root /home/$i/public_html/components/com_mtree/img/.htaccess
echo "File created."
echo "--- Mosets Tree Permissions Completed ---"
fi
fi
done

Customer Uno

Today was an exciting day, I launched my first hosting customer. I’ve spent a lot of time over the last 12 months working on my server configurations. Ironically, very little has changed from the original script Hone Watson gave me. I’ve update all the tools to latest versions, made the original script much more modular and made post installation configuration scripts as well.

About 90% of the process is completely automated now. I’ve built firewalls, I’ve created numerous crons, I’ve even written automated lockdown scripts for joomla that detect numerous components and configure ownership and permissions in a best practice manner.

Here’s to the future, may it bring many more clients.

Switching on Artio Plugin causes 500 – Unable to load renderer class error in Joomla

I’ve been developing a new hosting environment that uses Nginx and I came across an issue with Artio JoomSEF. Whenever I switched on the plugin the site would die and display:

500 – Unable to load renderer class

This ended up being a problem with Artio itself. Version 3.5.3 of Artio JoomSEF doesn’t work properly. Upgrading Artio solved this issue. Hopefully this will save other people from spending a lot of time trying to find issues in their code or configs.