One of the most frustrating things that can happen to shared hosting provider is to find that one or more of their servers have been compromised.   As a shared hosting provider we are responsible for maintaining the integrity of our servers and the client data residing on the server.   Not always an easy task.

What makes securing a shared server such a challenge?  Well, the intrinsic problems that come with having dozens, if not hundreds, of individual users accessing a single server should be obvious.  Each client has the ability to upload any scripts they desire which are rift with security holes due to poor design, coding errors, or just plain laziness on the part of the programmer.  (A good example is the continued use of “register_globals” by many PHP scripts…a sure guarantee of an injection attack.)  On top of that, a majority of shared hosting clients are not that entirely (if at all) well versed in how to maintain their sites and fail to keep their scripts updated.

But don’t be discouraged as there are some simple steps you can take to help make your servers more secure against many of the more common hacks.    I’ll be outlining the security steps I take when setting up new servers.  Note that I have a few tricks that I won’t be sharing since I don’t want to give the script-kiddies too much info.    Also, I’m only going to give you a brief overview of the steps.  In future articles I’ll get into the details of each step and how to implement them.

• Disable dangerous PHP functions.   These include exec(), passthru(), shell_exec(), system(), proc_open(), popen(), and show_source().   Some clients might complain that some of their scripts no longer work, but the security this one step provides far outweighs a few broken scripts.
• Secure your /tmp folder.   The latest versions of cPanel do this by default now, but it’s always good to go back and check.  And while you’re at it, make sure your /usr/tmpDSK file is large enough.   It defaults to 512K, but personally, I’d resize it to 1GB or better.
• Recompile Apache and PHP to add additional security features.   cPanel makes recompiling and enabling most Apache and PHP features very simple via the EasyApache configuration tool.  At minimum, security wise, enable Mod_suPHP and Mod_Security.
• Disable php.ini overrides in suPHP.    suPHP forces all users scripts to run as their username.  This prevents users from running any scripts as root or nobody.  It also disables the ability to override php.ini settings in the .htaccess file.  Unfortunately, by default, users can still create custom php.ini files that will override the system-wide version.  Thus, if left in this state, they can reactivate the disabled functions from above.  You can easily fix this by editing the /opt/suphp/etc/suphp.conf file and uncommenting the three lines in the [phprc_paths] section.
• Configure mod_security.  Now that you have mod_security compiled in, you need to configure it.  I suggest using the GotRoot rules (http://www.gotroot.com/mod_security+rules) and ConfigServer ModSecurity Control  (http://www.configserver.com/cp/cmc.html).   Be prepared to spend some time tweaking the rules, but in the end, well worth the effort.
• Install ConfigServer Firewall.    CSF w/LFD (http://www.configserver.com/cp/csf.html) is probably the best free firewall protection I’ve used.  Easy to install and manage and it works right out of the box.
• Install Rack911.com’s Symlink Patch.   By default, Apache allows you to symlink to ANY file on the server.   This means a malicious user or hacker can symlink to system configuration file and other users commonly known scripts config files and read them.  While you could simply disable symlink altogether, that would almost certainly break many system functions.  Rack991 generously released a patch that simply prevents the system from creating a symlink to files that are not owned by the user.
• Secure SSH.   You can change the SSH port, but I’ve found that it’s not really all that beneficial as port scanners can eventually find the port and it just makes our job harder as admins.  Instead,  simply don’t allow SSH for ANY cPanel user, not even jailed.  And add “PermitRootLogin without-password” to your sshd_config file.  This will only allow you to SSH into the server is if you have a valid SSH key in the authorized_keys file (Be sure to add that BEFORE you change the sshd_config file).
• Install Maldetect.  Install Linux Malware Detect from R-fx Networks (http://www.rfxn.com/projects/linux-malware-detect/).  While not perfect, it does give that extra layer of detection.
• Review your Tweak Settings.   Under Mail, set your Emails per hour limits to a low number (100);  enable prevent NOBODY from sending mail; enable Add X-PopBeforeSMTP.    These settings will put a strangle hold to mass-mail spamming and if you do have a spammer, quickly find who it is.

While implementing these steps will not 100% guarantee that your server will never be compromised, it does put you on good footing to prevent a vast majority of the types of attacks that you might see.  I’ll touch more on each of these points in later articles and on other things that can be done to give you that balance of security vs. usability that shared hosting clients require.