Website Design West Midlands

This article describes one way to limit incoming SMTP connections for specific domains to a list of specific safe relay IP addresses. Let’s suppose that you have a domain, mydomain.com – and you want to filter all email for this domain via an external host – lets call it filtermail.com.

You would typically set the MX records for mydomain.com to point to in.filtermail.com as follows:

mydomain.com. 14400 IN MX 10 in.filtermail.com.

And, presumably, you would configure filtermail.com to send your sanitised, cleaned mail back to mail.yourdomain.com and set your exim config to accept all mail locally for your domain. Great, so now you are happily filtering your mail for spam – but wait… some sneaky monkey decides to try sending spam directly to mail.mydomain.com, and your exim happily receives it, because exim isn’t aware of the DNS settings, and doesn’t know any better.

So, we need to tell exim NOT to accept any mail for mydomain.com UNLESS it is coming from, lets say for the sake of argument, out.filtermail.com. Let’s say that out.filtermail.com has an IP address of 194.189.242.1. Read some more…

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 some more…

This script will run through all Cpanel user account home directories and recursively do the following:

• check for directories that have the write bit set for group(g) or other(o) – and reset any found to 755 permissions.
• check for any files with the .php extension and that have any access bits at all allowed for other (o), write/execute bits set for group(g), or execute bit set for user(u) – and reset any found to 640 permissions.

It is quite easy to modify for your own purposes, but these permissions are generally a good starting point when on a server running PHP with the suPHP module (THIS WILL BREAK EVERYTHING IF YOU ARE RUNNING PHP AS DSO). Read some more…

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!

To get an instant view of the diskspace being used by each Cpanel user account home directory, I created this little script. Thanks to Spiral for some pointers on getting the cleaned account list.

Code block
   
#!/bin/bash
#
CPUSERS=`/bin/ls -- /var/cpanel/users | /bin/grep -v "\.\|cpanel\|root\|mysql\|nobody"`
TOT=1
for CPUSER in $CPUSERS; do
   CPHOME="$(/bin/grep "${CPUSER}:" /etc/passwd | cut -d':' -f6)"
   NEWACC="`/usr/bin/du -m --summarize $CPHOME`"
   S="`printf \"%03d\" $(echo $NEWACC | awk '{print $1}')`"
   let "TOT=$TOT+$(echo $NEWACC | awk '{print $1}')/1"
   ACCSUM=$ACCSUM"\n"$S" "$CPHOME
done
echo -e $ACCSUM | sort
echo $TOT

As always, do not test in a production environment!

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.

Code block
   
#!/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!