Which additional securities do you add to your open source cms installations?

5 comments

1. Using something like the mod_security or mod_evasive Apache’s modules can be an idea too — I suppose they require some configuration, though ; and you should test you website still works OK before using those on your production server.
   
   As they are Apache’s modules, it also requires you can install new Apache’s module — which means you have to be admin of the server.

   On a pure PHP-level, there is a tool called PHP-IDS ; quoting its website :

   PHPIDS (PHP-Intrusion Detection
   System) is a simple to use, well
   structured, fast and state-of-the-art
   security layer for your PHP based web
   application. The IDS neither strips,
   sanitizes nor filters any malicious
   input, it simply recognizes when an
   attacker tries to break your site and
   reacts in exactly the way you want it
   to. Based on a set of approved and
   heavily tested filter rules any attack
   is given a numerical impact rating
   which makes it easy to decide what
   kind of action should follow the
   hacking attempt. This could range from
   simple logging to sending out an
   emergency mail to the development
   team, displaying a warning message for
   the attacker or even ending the user’s
   session.

   I suppose you could “plug” it in front of the CMS you are using, by adding a couple of lines to its entry point — if there is a common entry point you can identify, or some file that’s included once at the beginning of each page.
   
   There is a “How to use it in my application?” entry in the FAQ.

   And, like you said, securing your server is nice : no remote SQL access, for instance ; checking the provileges of each user on the system, too ; keeping your software up to date, …

   Log in to Reply

2. If you’re super paranoid, would be to setup the application in a sandbox and have apache proxy over to it. But that’s pretty much over-kill unless you have a lot of sensitive data and/or are truly paranoid and/or have been broken into before.

   If the application allows it changing the admin path is generally a good idea too. For example, it’s pretty easy with a search-replace to change WordPresses default admin from /wp-admin to something else entirely (like /my-admin for example). This isn’t always possible though.

   You’ll also want to thoroughly check any user roles and permissions that can be set with in the application its self. For example, Drupal has a pretty robust user access system. But you need to make sure you don’t give any users access they don’t

   Other things include disabling, or deleting, any modules/extensions/plugins that are not 100% necessary to the operation of the system. Personally checking all MySQL users to make sure no one can connect to the server remotely. You can also setup a chroot jail for all users on the server (except root of course) so they’re locked into a directory and can’t get out of it.

   Log in to Reply

3. See Hardening WordPress and Hardening WordPress with htaccess at the wordpress.org codex.

   In WordPress, put this

   function remove_header_info() {
   
   remove_action('wp_head', 'wp_generator');
   }
   
   add_action('init', 'remove_header_info');
   

   in the theme’s functions.php file to remove the WP version from being output by wp_head in header.php.

   Log in to Reply

4. In Joomla, I would change the database prefix to something different to jos_ .

   Log in to Reply

5. I’ve found two interesting links that can add information about WordPress.

   This first one is from WordPress blog itself, saying that you should always keep your installation up to date with all the security fixes.

   The second one is a great list from a lot of steps (from configuration to pugins) that I believe is really well written and with a lot of interesting advices (it’s divided in two parts).

   Log in to Reply