First, let's take a look at the major components of your web site - the web server, the database server, the scripting language and your application. Each of those components needs to be 'hardened' for use on the public Internet.
This is really 2 components - the operating system (Windows and Linux are the most common) and the web server software (Apache and IIS)
You will need a good relationship with your web host for securing these components. Things to ask about -
- Which version of web server are they running?
- What operating system are they running?
- What backups do they run and how often?
- What security programs and modules to they run? (mod_security for Apache should be on the list)
- Can you block IP addresses?
- Can you turn of indexes? Anonymous FTP access?
- How can you learn about network outages?
- What kind of control panel access do they provide?
- Can you provide overrides for the server? (htaccess files)
The more easily and openly they answer those questions, the better chance of you have a good relationship with your provider and being able to secure your web site.
The Database Server - MySql
Your content, your users' information and your entire site is based on a database. If someone gains access to that, you can lose everything!
Again, your hosting provider will be instrumental in this area. Be sure get good information about the version of the MySql server they are running and it is properly secured. There is a 'root' user and 'anonymous' user, be sure they don't expose your database to unnecessary threats.
The Script - PHP
This is what pulls everything together and presents your content to your visitors. Because it needs access to the database and the files on your server, it has to have sufficient permissions to act on them, which means there can be malicious use of the script to damage your site and your content. You need to be aware of how to prevent this.
There are different configurations of PHP - suExec is the most secure option available. Find out what version of PHP is used by your host and how it is configured. Learn if you can provide local overrides for their default settings.
Again - your hosting provider needs to be a good resource for this. If they aren't, begin to look at another host.
The Application - XOOPS and Modules
Be sure you are using the latest version of XOOPS on your site (2.0.16, as of August 2007) and have followed the installation instructions for setting permissions on files and have removed the installation directory once you have finished your install.
The Protector module provides additional assistance in preventing malicious attacks on your site - be sure to install the latest version (3.04, as of August 2007) and read the documentation thoroughly.
For more insight into the server and Protector settings, I went to JMorris (James), a past server admin for XOOPS.org and currently maintains several other sites - here is an excerpt from those discussions -
CXR: James, as an experience server administrator, would you offer some advice for securing web sites?
James: I can provide some security info in general, but I'm not a security expert. I'm more of an "overall" web master. You know, "jack of all trades, master of none."
In a nutshell, most hacks are at the server level and not the XOOPS level. They also come from malicious users behind proxy servers. Server configuration and permissions are the 1st line of defense. If your application is properly coded, everything else is bubble gum and duct tape. Proper server configuration, permissions and installation of Protector has kept many users safe for quite some time now.
CXR: What can the average web master do to be sure his server is secure?
James: Too many users are caught up in features and do not take the time to research and learn what the risks are with features. If people want to be a "web master" of their sites, the MUST become students of the risks present online or they will most certainly fall victim to those risks at some point in time. It's not a matter of if, it's a matter of when.
CXR: Where should we start?
1. Turn off Indexes
2. Deny access to folders that should not be directly accessed using an .htaccess file.
3. Insist on suExec on their servers (shared accounts will have a tough time with this).
4. chmod 777 is a bad idea - suExec fixes that. templates_c/ cache/ and uploads/ can all be run with chmod 755 with suExec, mainfile.php can be run at chmod 400.
5. Move your DB details out of mainfile.php and out of the web root.
6. chmod 444 any file that does not need written to.
7. chmod 755 all folders. (some modules will stop working if you use chmod 555).
8. Turn off anonymous ftp access.
9. Be sure all mysql users have a secure password (like: P4s5.w0_rD).
10. Be sure SSH (if enabled) has properly configured permissions and that you have to su - to root.
11. Research security threats on any module before installing it.
12. In addition to the PHP tweaks suggested by Protector, have your host enable open_base_dir and Fork Bomb protection.
13. Never give admin rights to anyone, especially to the XOOPS blocks admin.
14. Never assume you are safe. Regularly audit your site for suspicious files.
15. Backups, Backups, Backups, Backups, Backups!
CXR: That's a lot to be considered!
James: I don't know nearly as much as I want to know about the topic. It's not static by any means! And, it's constantly changing. That's why it is important be proactive and subscibe to security notices.
CXR: After the server is secured, then what?
James: Where XOOPS is most vulnerable is modules - many modules do not properly sanitize URL strings and therefore can be exploited to reveal DB details. That's where Protector comes in.
CXR: Are the default settings in Protector what you use?
James: I set Protector to the most restrictive settings possible, then back them off as needed. Remember, I'm p@r@n0!D and for a darn good reason! "If you're not p@r@n0!D, you're not paying attention."
Banning an attacker's IP is only a temporary fix. Banning their IP will slow them down a little, but not much. Eventually, the attackers will find another proxy with another set of IP addresses and will continue their attacks. The real issue is closing the hole in the application.
One last thing to consider: Your users
Sorry, but that's the truth. XOOPS has a great permissions system, but if you grant the wrong permissions, your users can get access to areas of your site that can cause damage.
In future articles, we will look more closely at the individual components and what you can do to keep your web site running smoothly.
Here are some additional resources -
Xoops-tips : Protecting DB information
Xoops-tips: Protect Admin Login
XOOPS FAQ: Protecting your site
Xoops-tips: Webmaster Security Guide
Starting a New XOOPS Site: Day 21 - Security Checkpoint