Tag Archives: apache

Mod_userdir URLs no longer work since Mod_ruid added

Just a quick one for today. I found that after recompiling apache with mod_ruid that mod_userdir is broken and would no longer serve pages from the customer’s vhost domain, and would only serve them from the server’s main URL.

http://customerdomain/~customerusername will no longer work

http://defaultserverhostname/~customerusername continues to work normally

This is due to permissions issues since the requests are now being served by the nobody account.

Search engine friendly URLs using apache mod_rewrite

As promised, here is a brief technical overview of how to get those nice search friendly URLs using Apache mod_rewrite and .htaccess files. I have already discussed why human readable URLs are a good idea, but it really should be obvious to anyone who has a basic understanding of the way Google views page URLs when calculating page rank.

What are we trying to achieve?

We are going to take the example of a fictitious website that has a database driven catalogue. We will assume for a moment, that the page that handles the navigation of the catalogue is /catalog.php and that it accepts a category and a page number parameter. So, for example, a typical URL might be:

/catalog.php?cat=34&page=2

This would show page 2 of the results for products in the category with id=34. This is a pretty common situation. Read More…

Hardening WordPress – Password Protected Directory causing 404 errors

Securing WordPress Guide

WordPress SecuritySecuring your WordPress blog is quite important, especially once you start to get any attention – the hackers and script kiddies won’t be far behind! It’s not hard to take a number of steps to make life much harder for people who want to spoil your blog.

I’m going to document “timeless” techniques first, then look at some plugins. There are dozens of plugins for securing WordPress that can help with security, but plugins come and go (apart from a few), so I’m sticking to solid security measures.

Because there are always bug fixes, and new security exploits being patched, I won’t insult your intelligence by stating that you should keep your copy of WordPress up to date on your server  – oops, I just did!

Seriously, though, installing WordPress is the easy bit – you must keep it current to be secure. I could show you excerpts from our application firewall logs, and your toes would curl if you were aware of how many times your blog gets probed for various weaknesses and exploits. Read More…

Bash Script to place 404.shtml and favicon.ico in home directories

OK, so you’ve noticed how your error_log files are just full to busting with 404 errors for favicon.ico and 404.shtml? Annoying isn’t it, especially when you have a lot of activity on a server, as these files can mushroom out of control.

This script will go through each user account’s home directory, and where it doesn’t find then, it will place a copy of 404.shtml and favicon.ico for you. Read More…

Prevent Modsec_Audit.log filling up with HTTP 200 OK

Modsec is an enormous benefit in terms of catching many of the security holes created by bad php programming in your user accounts. However, on a busy server, you will find that the majority of the audit log (and the bulk of the entries it dumps into mysql) will be for things that you really don’t want to see. These logs, particularly the MySQL table, can grow to gigabytes in size, so it’s something I like to keep in check.

Obviously, there ARE some attacks which may still result in a 200 response, and therefore won’t be logged, so be warned. However, this measure is easy to implement and remove at will. I suspect that if an attack managed to penetrate your server, regardless of it only triggering 200 responses, then the least of your worries is going to be looking through the modsec logs (if you have a server left at all!)

In the modsec2.conf file, usually found in /usr/local/apache/conf/modsec2.conf you need to make sure the following directives are in place. You will likely have many more directives in your conf file, but here I am just showing the ones you need to control the logging levels.

<IfModule mod_security2.c>
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^[345]"
</IfModule>

Basically SecAuditEngine RelevantOnly tells us to only audit things that modsec deems relevant. The ^[345] is just a little regex that says “only match anything that starts with 3, 4 or 5” – so this would only log anything in the 300 – 599 range.

This can drastically reduce the amount of unwanted material in the log.

As always, do not test this in a production environment!

Simple change detector for cpanel template files

OK, in answer to requests, here is a simple bash script to check any file for changes. It could have been done with MD5 hashes, but it’s probably not necessary (overkill).

Just copy the file you want to check and rename it with a different extension (e.g. .check)

Then just run the following script under a crontab entry – probably best a short while after upcp is run.

#!/bin/bash
COMPARE="`diff --brief /usr/local/cpanel/etc/httptemplates/apache2_2/default /usr/local/cpanel/etc/httptemplates/apache2_2/default.check`"
if [ ${#COMPARE} -gt 0 ]; then
   echo "There was a change found in /usr/local/cpanel/etc/httptemplates/apache2_2/default" | /bin/mail -s "Changes in Cpanel Templates Detected `date`" santfiles@mac.com
fi

If the files are the same then diff should return nothing, so we just check for a return value that is greater than 0.

Of course, if you happen to have CSF and LFD installed, then there is no need for any of this – just set up a File watch. (making sure you set LF_DIRWATCH_FILE to a value other than zero to make sure your watched files and directories are actually being watched!)

As always – test test, and test again before using anything here in a production environment!