Linux Server Management

Rebooting is commonly one of the first thing’s we see someone to when they find out they were compromised. We don’t know why, it doesn’t matter. Don’t do it Here is why:

1.) Any files the attacker uploads to /dev/shm will be removed on boot, which can make the investigation difficult.
2.) Depending if the attacker inserted a rootkit, your server may not come back up on reboot – Binaries may segmentation fault
3.) If the kernel is modified in memory, important forensic data will be removed on boot.
4.) Last but not least – We have seen attackers remove partition tables. On reboot your drive will appear to be wiped clean. We can often recover partition tables, but it will make it appear that worst has happened.

Your best course of action is to have Rack911 investigate your compromise as soon as it becomes known to you.

Logrotate or statistic problems may rotate important logs such as your apache access log, which can make finding the root cause difficult. Cpanel for instance can be configured to delete access logs after web statistics are ran, this happens daily.

We recently migrated a website developed using the kohana framework to a new infrastructure. Originally they were using Rackspace CloudSites and we moved them to a load balanced platform at Rackspace CloudServers. During the transition we migrated them from Apache to Nginx which resulted in an significant performance increase.

During the process of creating their rewrite rules, we had to do some research to find the variable to append the query string to. For your enjoyment, here is the required rewrite:

if (!-e $request_filename) {
rewrite ^/(.+)$ /index.php?kohana_uri=$1 last;
}

Another gotcha you may run into involves SSL. Kohana may not recongize SSL correctly without this set in your fastcgi configuration:

fastcgi_param   HTTPS   on;

There has been a couple recent vulnerabilities that you should patch, if your running the affected software:

Rfxn BFD – Brute Force Detection

http://www.rfxn.com/bfd-1-4-important-security-fix/

Change Log:
[Fix] properly sanitized vars passed to the command line
[Fix] ignore.hosts is now updated with system addresses on each bfd run

Installatron
Several serious security holes
Info: http://webhostsecurity.com/bugs/installatron/index.shtml

Cpanel by default come’s with two really good RBL’s, which are zen.spamhaus.org and rbl.spamcop.net. Junkemail filter provide’s their Hostkarma rbl for public use for non-commercial purposes. You may also use it if you are a small business. Most of Rack911’s customers are web masters with medium to large websites (such as forums), so it is extremely beneficial to them.

They offer multiple blocklist’s to choose from:

• 127.0.0.1 – whilelist – trusted nonspam
• 127.0.0.2 – blacklist – block spam
• 127.0.0.3 – yellowlist – mix of spam and nonspam
• 127.0.0.4 – brownlist – all spam – but not yet enough to blacklist
• 127.0.0.5 – NOBL – This IP is not a spam only source and no blacklists need to be tested

For the scope of this entry, we are going to show you how to utilize the 127.0.0.2 spam blacklist on cpanel servers.

Login to your cpanel machine and gain root access, and run the following commands:

cd /usr/local/cpanel/etc/exim/acls/
wget http://layer1.rack911.com/hostkarma_rbl
/scripts/buildeximconf
service exim restart

Your server now has zen.spamhaus.org,  rbl.spamcop.net and hostkarma rbl’s running.

To remove the rbl, just remove the /usr/local/cpanel/etc/exim/acls/ACL_RBL_BLOCK/hostkarma_rbl file and rebuild the exim configuration file again.