Tweaking apache web server

1) Remove version information from Apache (check Security by Obscurity part)

2) Activate the Php open_basedir Tweak (go to Tweak Security in WHM)

3) Install Modsecurity

Mod security allows filtering the incoming requests. There are already filters available on the web to use straight away and they are updated regularly.

Check out the to keep your rules updated.

Another usual issue is the use of the PCRE regular expression in mod security. The current version available with cPanel does not support it, so you will need to download and install the latest version manually, with some simple procedures. It is really worth it especially in terms of performance. More details to come.


Go to the “Addon Modules” in WHM and check the Modsecurity module

You now have to edit your Apache httpd.conf file (usually resides in /usr/local/apache/conf/httpd.conf)

cPanel should have added this line in there already for you, but double check anyway:

Include "/usr/local/apache/conf/modsec.conf"

Now, edit the modsec.conf file.
This is how my modsec.conf file looks like. You might want to change some settings. Notice the inclusion of the rules for the modsecurity module:

SecFilterEngine On
SecFilterCheckURLEncoding On
SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log
SecFilterDebugLog logs/modsec_debug_log
SecFilterDebugLevel 0
SecFilterDefaultAction "deny,log,status:406"
SecFilterSelective REMOTE_ADDR "^$" nolog,allow
Include "/usr/local/apache/conf/modsec.user.conf"
#And now, the rules
#Remove any of these Include lines you do not use or have rules for.

#First, add in your exclusion rules:
#These MUST come first!
Include /etc/modsecurity/exclude.conf

#Application protection rules
#Include /etc/modsecurity/rules.conf

#Comment spam rules
Include /etc/modsecurity/blacklist.conf

#Bad hosts, bad proxies and other bad players
Include /etc/modsecurity/blacklist2.conf

#Bad clients, known bogus useragents and other signs of malware
#Include /etc/modsecurity/useragents.conf

#Known bad software, rootkits and other malware
Include /etc/modsecurity/rootkits.conf

#Signatures to prevent proxying through your server
#only rule these rules if your server is NOT a proxy
Include /etc/modsecurity/proxy.conf

#Additional rules for Apache 2.x ONLY! Do not add this line if you use Apache 1.x
#Include /etc/modsecurity/apache2-rules.conf

The reason I don't use all rules is because some where crashing my apache. Anyway, you see the /etc/modsecurity needs to exist and the rules need to be there. So go ahead and mkdir /etc/modsecurity

Now, you need the rules. You can download them from website. I have, however, made a script to auto-update these rules, based on a existing script from I was informed they will include my script on their page soon, but meanwhile you can download it here.

Here's the direct link to rules page:

If you use my script, just put it in /etc/modsecurity and run it. It should download the rules if you don't have them yet or update them if you have an old version. It also tries to restart apache, so no need to do that manually. You'll get an error if apache doesn't load.

In case some web pages do not work properly with mod security, the best approach is to include an .htaccess file in the same directory allowing the file in question to be ignored by mod security. To do an entire directory, simply put this in the .htaccess file:

SecFilterInheritance Off

4) Enable PHP suEXEC support

This is an essential part of your webserver security. suEXEC makes your users php scripts run under their own usernames instead of the user "nobody". This has two major advantages: forces all scripts to only do what is permitted for that username keeping track of the user who ran it (like in the case of sending e-mails from a script) and allows includes the cpu used in the execution of php scripts for each user in the CPU utilization chart from WHM, which would otherwise be under "nobody" making it very hard to track down cpu intensive scripts.

Now that you know why you should use it, here's how:

- Rebuild apache with the PHP suEXEC support

You should already know how to do this...

- Fix your user's files permissions
Basically I found most of my users had some files under the user "nobody" (uploaded files from a php script for example). This was fine until suEXEC was enabled, since then those files were not accessible from php scripts (depending on file permissions).

As usual, I've put a simple solution in a script to fix this, here you go:

#this changes all files from the user "nobody" to the real user of the area
find /home -user nobody > list_of_nobodies
exec < list_of_nobodies while read line do fileOwner=`echo $line | sed "s/\// /g" | awk '{print$2}'` chown ${fileOwner}:${fileOwner} "$line" #report it echo "Changing owner to ${fileOwner}:${fileOwner}" echo $line done

Change /home to your home directory. Alternatively you might want to keep the group "nobody" for those files, if so change the line:

chown ${fileOwner}:${fileOwner} "$line"


chown ${fileOwner}:nobody "$line"

5) Installing Zend Optimizer and IonCube in the same server

Taken from by Punk

1. SSH login/su as root

2. make sure ioncube is installed at your server

3. edit /scripts/installzendopt : >> pico /scripts/installzendopt

4. under " my %urls = ( " line, change to

Linux => '',
Linux64 => '',

5. save changes and install zend : >> /scripts/installzendopt

6. follow the instruction at the installation proccess

7. after installation, edit your php.ini : >> pico /usr/local/Zend/etc/php.ini

8. find the zend configuration zone

9. move your ioncube line (at my server: zend_extension=/usr/local/cpanel/3rdparty/etc/ioncube/ before zend_extension

example at my server :




10. save changes and restart httpd >> /etc/init.d/httpd restart