With the amount of websites which are hosted across ForLinux managed servers we see at least one or two script level compromises a week, these are hacks where the points of entry is a script such as a third party CMS or Shopping Cart which has been targeted by bots using known vulnerabilities with the script itself.
Often we find that the script is only a version or two out of date and that a simple update is needed to secure the site, however there have been occasions when updating the script is not possible because external developers have changed files which are core to the third party script, so any updates to the core will overwrite these changes.
As the developers normally have full FTP access to the site how can you remove the temptation to hack the core files? One common way would be to segregate the core files away from the from the main public_html directory, so for a site running Drupal this would look something like ….
> ls -lha
total 180K
drwxr-xr-x 15 user user 4.0K Jun 6 00:41 .
drwxr-xr-x 33 root root 4.0K Apr 1 13:28 ..
drwxr-x— 2 user user 4.0K Jan 17 2008 cgi-bin
drwxr-xr-x 6 user user 4.0K Jul 28 2010 domains
drwxr-xr-x 9 root root 4.0K May 25 2011 drupal-6.21
lrwxrwxrwx 1 root root 11 Jun 15 2011 drupalbase -> drupal-6.21
drwxr-xr-x 8 root root 4.0K Sep 6 2010 drupalbase-6.17
drwxr-xr-x 10 root root 4.0K Jun 15 2011 drupalbase-6.19
drwxr-xr-x 1 root root 11 Jun 15 2011 dumps
drwxr-x— 2 user user 4.0K Sep 15 2009 logs
drwxr-x— 16 user user 4.0K May 29 16:41 public_html
drwxr-xr-x 3 root root 4.0K Sep 6 2010 tmp
root@ForLinux-NEW [user]>
…. and the public_html directory would look like ….
> ls -lha
total 200K
drwxr-x— 16 user user 4.0K May 29 16:41 .
drwxr-xr-x 15 user user 4.0K Jun 6 00:41 ..
lrwxrwxrwx 1 user user 33 Aug 26 2010 chrome -> sites/all/themes/userueprint/chrome
lrwxrwxrwx 1 root root 22 Sep 6 2010 cron.php -> ../drupalbase/cron.php
lrwxrwxrwx 1 user user 20 Aug 26 2010 files -> sites/default/files/
-rw-r–r– 1 root root 5.5K May 16 15:46 .htaccess
lrwxrwxrwx 1 root root 26 Aug 26 2010 images -> sites/default/files/images
lrwxrwxrwx 1 root root 22 Sep 6 2010 includes -> ../drupalbase/includes
lrwxrwxrwx 1 root root 23 Sep 6 2010 index.php -> ../drupalbase/index.php
lrwxrwxrwx 1 root root 18 Sep 6 2010 misc -> ../drupalbase/misc
lrwxrwxrwx 1 root root 21 Sep 6 2010 modules -> ../drupalbase/modules
lrwxrwxrwx 1 root root 22 Sep 6 2010 profiles -> ../drupalbase/profiles
-rw-r–r– 1 user user 1.7K Sep 28 2011 robots.txt
lrwxrwxrwx 1 root root 21 Sep 6 2010 scripts -> ../drupalbase/scripts
-rw-r–r– 1 apache root 70K Oct 10 2011 sitemap.xml
drwxr-xr-x 4 user user 4.0K Aug 12 2010 sites
lrwxrwxrwx 1 root root 20 Sep 6 2010 themes -> ../drupalbase/themes
lrwxrwxrwx 1 root root 24 Sep 6 2010 update.php -> ../drupalbase/update.php
lrwxrwxrwx 1 root root 24 Sep 6 2010 xmlrpc.php -> ../drupalbase/xmlrpc.php
This fully separates all of CMS’s core files away from any custom files, Drupal stores all it’s customisations in /sites which is not sym-linked, in a way which allows you easily update the site and also the core files are a little more protected as they have a different owner and group to the customised files.
As you can see from the first directory listing this installation of Drupal has been upgraded from 6.17 to 6.21 by uploading the new version of the script outside of the public_html directory and then changing which release the “drupalbase” sym-link is pointing to rather than overwriting any files, this means assuming that a database dump was made (some updates make changes to the database which are not backward compatible) then you can quickly roll back without having to overwrite / re-upload any files.
This method is probably not suitable for all scripts or sites but help demonstrate ways files which shouldn’t really be changed can be isolated from those which do to help remove the temptation of putting a quick hack in place to fix a problem.
