RimuHosting Blog » Security http://blog.rimuhosting.com Mighty Linux servers, support worth raving about Wed, 01 Feb 2012 01:07:34 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 WordPress mass update script 3.3.1 http://blog.rimuhosting.com/2012/01/05/wordpress-mass-update-script-3-3-1/ http://blog.rimuhosting.com/2012/01/05/wordpress-mass-update-script-3-3-1/#comments Wed, 04 Jan 2012 21:38:02 +0000 Liz Quilty http://blog.rimuhosting.com/?p=1802 Continue reading →]]> This script will search /var/www (changeable in a variable) for any wordpress installs and make sure its upgraded to the latest version.
It will run a backup to /root/wp_upgrade/ of all files and database before doing anything with the site in case of major catastrophe (make sure you have spare disk space if your sites have a lot of uploaded files).

I have now added putting the site into maintenance mode whilst upgrading. This just involves adding a .maintenance in the document root.

It pays to check each site after the upgrade to make sure plugins all worked (and upgrade plugins before the upgrade works also!)

Let me know if you have any bugs at all, or any problems.

Here’s your script to upgrade them all.

wget http://b.ri.mu/files/wordpress-upgrade-3.3.1.sh
bash wordpress-upgrade-3.3.1.sh

MD5
e365a7fa4b69b3ad52e75b4175c1539a wordpress-upgrade-3.3.1.sh

SHA1
653d1a95a89cfc4be3253af96ef915ba3615ad18 wordpress-upgrade-3.3.1.sh

If you find any bugs or problems, just let me know at liz at rimuhosting dot com

]]> http://blog.rimuhosting.com/2012/01/05/wordpress-mass-update-script-3-3-1/feed/ 0 Checking a potentially hacked machine and reinstalling packages when you break things http://blog.rimuhosting.com/2011/10/12/checking-a-potentially-hacked-machine-and-reinstalling-packages-when-you-break-things/ http://blog.rimuhosting.com/2011/10/12/checking-a-potentially-hacked-machine-and-reinstalling-packages-when-you-break-things/#comments Wed, 12 Oct 2011 02:46:58 +0000 Liz Quilty http://blog.rimuhosting.com/?p=1713 Continue reading →]]> Sometimes you may see something odd go past in the logs, on the screen, or something might just seem a bit 'off' somehow. Its a good idea when this happens to just double check that things are as they should be, verify packages, binaries, check logs etc

Here are a few things i find helpful when doing this

Install something like rkhunter or chkrootkit, run it regularly and check the output. These tools are excellent at helping detect oddities that should not be there. I find rkhunter better in that it emails me regularly (every night) and lets me know if there are changes or things happening.

Sometimes the server is not mine (ok, a lot of the time since i work on peoples servers), so these things may not be installed already, and i want to check packages installed are the correct ones, and have not been replaced by a hacker, or some other odd process. I use something like this

For Redhat based systems (Fedora, Centos etc)

apt-get install yum-verify
yum verify-all

For Debian based systems its a little harder, but scriptable

dpkg -l \*|while read s n rest; do if [ "$s" == "ii" ]; then echo $n;
fi; done > ~/tmp.txt
for f in `cat ~/tmp.txt`; do debsums -s -a $f; done

These commands will take some time, and use a fair amount of CPU and disk IO when you run them, so be aware they may slow the VPS/Server down a little.
Also, be aware you may have a fair few false positives, usually on configurations which have changed from the default packages

IF a package appears to be tampered with you can reinstall it like this
Centos/RedHat/Fedora

yum reinstall packagename

Or reinstall all packages

yum reinstall $(yum list installed | awk '{print $1}')

Debian/Ubuntu

apt-get install --reinstall packagename

or reinstall all packages

apt-get install --reinstall $(dpkg --get-selections |grep -v deinstall)

Possibly not such a great idea to reinstall all packages, if its that bad you really should reinstall the server from scratch. Ideally if you have been root exploited in any way you should reinstall from scratch as nothing will be safe (especially your package manager or SSH daemon). The main reason i put these commands here is because they are handy if you break things also :)

Lastly, it pays to regularly run netstat to check for strange open ports or connections, ps for odd running things, and of course all your logs for things (especially apache error log).

]]> http://blog.rimuhosting.com/2011/10/12/checking-a-potentially-hacked-machine-and-reinstalling-packages-when-you-break-things/feed/ 1 DigiNotar and SSL certificates http://blog.rimuhosting.com/2011/09/09/diginotar-and-ssl-certificates/ http://blog.rimuhosting.com/2011/09/09/diginotar-and-ssl-certificates/#comments Fri, 09 Sep 2011 04:12:14 +0000 Glenn Enright http://blog.rimuhosting.com/?p=1694 Continue reading →]]> Great news! We were pretty sure, but a recent notification from our certificate supplier told us that none of the certificates ordered on behalf of our customers are signed by DigiNotar.

For those of you not aware, DigiNotar is a Certificate Authority who provided signed SSL Certificates against their own trust chain. Which was recognized by all major browsers (including Internet Explorer, Firefox, Chrome, and Opera) and therefore enhanced the security and browsing experience of many SSL secured sites.

In July 2011– An internal audit discovered an intrusion within DigiNotar’s CA infrastructure indicating a compromise of their cryptographic keys. The breach of these keys resulted in the fraudulent issuance of public key certificates to a several dozen domains including the domain Google.com. Shortly after the incident, DigiNotar revoked all of the certificates in question, conducted an additional external security audit and then attempted to revoke outstanding certificates that were affected.

You can read full details from their official press release

However as analysis continued and the evident scale of the problem increased, many that used DigiNotar as a top level signing CA felt that chain was no longer trustworthy. For those with certificates signed by them this turned into a significant issue  as software developers for the major browsers completely revoked the top level certificate in their browsers, requiring them to purchase new certificates from alternate agencies.

Why is this important to you?

  • This breach highlights the need to be vigilant about your server security
  • SSL enable sites remain one of the most important methods securing browser connections and creating trust to site visitors.
  • You can rest assured that the SSL certificates we provide are secure

If you would like to know more about the SSL certificate options we provide please take a look at our secure SSL Certificate order page, or pop in an email to us directly at support@rimuhosting.com with details on what you would like to know.

]]> http://blog.rimuhosting.com/2011/09/09/diginotar-and-ssl-certificates/feed/ 0 Why is your server sending spam? why does it keep crashing with high load? http://blog.rimuhosting.com/2011/08/31/why-is-your-server-sending-spam-why-does-it-keep-crashing-with-high-load/ http://blog.rimuhosting.com/2011/08/31/why-is-your-server-sending-spam-why-does-it-keep-crashing-with-high-load/#comments Wed, 31 Aug 2011 02:32:11 +0000 Liz Quilty http://blog.rimuhosting.com/?p=1680 Continue reading →]]> We get asked these questions regularly, and 9 out of 10 times it may be because your server may have been hacked, either on a user level, web application, or more.

Here are some ways to quickly check for the most common things we see , and some of the processes we go through to find the culprits


Probably the most common thing we see, is insecure web applications. Either sending spam emails, or sending the load up high by running applications from the apache user (bots or similar).

First of all, check what is listening to external ports using something like

netstat -pant |grep LISTEN

You probably want to look into stopping the processes that seem suspicious, this may involve restarting apache or using the kill command. Next run ps auxf and see if there is anything odd, you should regularly check a ps even if its just to familiarize yourself with what is normal or not.

If you find files that are running, use find to locate where on the filesystem they are

find / -name "filename"

Since most sites use Apache Web Server to serve web pages, check the error.log, you can find it in /var/log/apache2 or /var/log/httpd (depending what distro you use).

Things to look for are outputs from shell commands (ie wget or curl) or anything that just does not look "right". If you can get the time/day from these it helps, even if its an approximate (between log above it and below it).

Once you have that, check the access.log and see what happened on those days. Check for repeated POST entries in a row, or odd file names in image directories.

Checking for larger logs in /var/log will give you hints since 1000 emails is often created with 1000 hits ( ls -sh /var/log/ ). If you have 3 or 4 very large apache and mail logs, then you know they rotate every day, that's 3-4 days ago it happened.

You can check apache logs for what IP address is accessing your website most, this is more often the spammer , this is how

cat access.log | awk '{print $1}' | sort | uniq -c | sort -n | tail

The first number result is the amount of hits, the second is the IP. You can then check the other logs for any instance of that IP, view what pages they were on.

Once you narrow down the time it happened its a lot easier to find out what happened. If you can Narrow that down to an IP address, this is even better, you can check the logs to find exactly what that ip address did, and block it.

If you are dealing with spamming from your server, check the mail queue (run 'mailq') it should give you an idea what has been sent, check /var/spool/postfix/deferred to read the emails in the queue (use less or vi ) to see if they have headers and who they are from.

For postfix users, its easy enough to clear any email queued up in your server, just run something like

postsuper -d ALL

Beware this will also purge any legitimate email at the same time.

Once you have tracked it down to and IP you can then track it down to a file or two. It pays to grep for that file in case the user hacking changed IP several times, and try and track back to the original entry point.

Once found, check what permissions that file/script had access too (read the code, or just check what it could possibly have written to) and replace those things.
If you have a CMS, upgrade that, backup all images and check themes/plugins for back doors. Remove everything else and replace with new ones from the fresh download you do.

Check all tmp dirs for files that should not be there, /tmp and /var/tmp are often used. Make sure you use ls -al and check for directories named as " " (as in a space) or any oddities and extra line feeds for hidden directories. Another one often used is naming a directory " ." so it looks like a . rather than a space dot etc.

If your server has been root exploited then re-install and wipe as much data as you possibly can, only migrate what you must. Often if its root exploited you will find problems with package management being unable to write to some files, or similar.
Usually if a server is root exploited they can replace binaries (ie your mailserver) and you will not notice, they intercept everything, and its safe to assume they have all your passwords logged as clear text somewhere.

]]> http://blog.rimuhosting.com/2011/08/31/why-is-your-server-sending-spam-why-does-it-keep-crashing-with-high-load/feed/ 0 Apache exploit may crash your server – heres how to fix it http://blog.rimuhosting.com/2011/08/26/apache-exploit-may-crash-your-server-heres-how-to-fix-it/ http://blog.rimuhosting.com/2011/08/26/apache-exploit-may-crash-your-server-heres-how-to-fix-it/#comments Fri, 26 Aug 2011 04:35:26 +0000 Liz Quilty http://blog.rimuhosting.com/?p=1648 Continue reading →]]> We have picked up that there was an exploit in Apache which can result in your server running out of memory. the discovery was noticed quiet some time ago, but never fixed, and it seems to have reared its head publicly resulting in some people actively attacking.

There is no patch for apache as yet, however you can do a few things to stop it affecting you.

1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.

Option 1: (Apache 2.0 and 2.2)

# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range

Option 2: (Also for Apache 1.3)

# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]

The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.

2) Limit the size of the request field to a few hundred bytes. Note that while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.

LimitRequestFieldSize 200

Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.

See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3) Use mod_headers to completely dis-allow the use of Range headers:

RequestHeader unset Range

Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
4) Deploy a Range header count module as a temporary stopgap measure: http://people.apache.org/~dirkx/mod_rangecnt.c

Precompiled binaries for some platforms are available at: http://people.apache.org/~dirkx/BINARIES.txt

Because each system is different, and the requirements for each system vary, there is no one sure way to fix each system. If you are unsure what one to use, or need help fixing that, just drop us an email and we can sort that out for you.

]]> http://blog.rimuhosting.com/2011/08/26/apache-exploit-may-crash-your-server-heres-how-to-fix-it/feed/ 1 WordPress mass update script 3.2.1 http://blog.rimuhosting.com/2011/07/13/wordpress-mass-update-script-3-2-1/ http://blog.rimuhosting.com/2011/07/13/wordpress-mass-update-script-3-2-1/#comments Wed, 13 Jul 2011 01:27:20 +0000 Liz Quilty http://blog.rimuhosting.com/?p=1580 Continue reading →]]> This script will search /var/www (changeable in a variable) for any wordpress installs and make sure its upgraded to the latest version.
It will run a backup to /root/wp_upgrade/ of all files and database before doing anything with the site in case of major catastrophe (make sure you have spare disk space if your sites have a lot of uploaded files).


I have now added putting the site into maintenance mode whilst upgrading. This just involves adding a .maintenance in the document root.

It pays to check each site after the upgrade to make sure plugins all worked (and upgrade plugins before the upgrade works also!)

Let me know if you have any bugs at all, or any problems.

Here’s your script to upgrade them all.

wget http://b.ri.mu/files/wordpress-upgrade-3.2.1.sh
bash wordpress-upgrade-3.2.1.sh

MD5SUM
26eb9d2d2d7ece52764888fe62f5b5e4 wordpress-upgrade-3.2.1.sh

SHA1SUM
6219bd3953ae89ce13428e9f3333843d9dfc09de wordpress-upgrade-3.2.1.sh

]]> http://blog.rimuhosting.com/2011/07/13/wordpress-mass-update-script-3-2-1/feed/ 0 WordPress mass update script 3.2 http://blog.rimuhosting.com/2011/07/05/wordpress-mass-update-script-3-2/ http://blog.rimuhosting.com/2011/07/05/wordpress-mass-update-script-3-2/#comments Mon, 04 Jul 2011 22:19:10 +0000 Liz Quilty http://blog.rimuhosting.com/?p=1537 Continue reading →]]> This script will search /var/www (changeable in a variable) for any wordpress installs and make sure its upgraded to the latest version.
It will run a backup to /root/wp_upgrade/ of all files and database before doing anything with the site in case of major catastrophe (make sure you have spare disk space if your sites have a lot of uploaded files).


I have now added putting the site into maintenance mode whilst upgrading. This just involves adding a .maintenance in the document root.

It pays to check each site after the upgrade to make sure plugins all worked (and upgrade plugins before the upgrade works also!)

Let me know if you have any bugs at all, or any problems.

Here’s your script to upgrade them all.

wget http://b.ri.mu/files/wordpress-upgrade-3.2.sh
bash wordpress-upgrade-3.2.sh

MD5SUM
f441261fdcb09ac64f98ab9a28f743a6 wordpress-upgrade-3.2.sh

SHA1SUM
61794bdacc4223fa88bb6737552bb8a7cf8f432f wordpress-upgrade-3.2.sh

]]> http://blog.rimuhosting.com/2011/07/05/wordpress-mass-update-script-3-2/feed/ 5 WordPress mass update script 3.1.4 http://blog.rimuhosting.com/2011/07/01/wordpress-mass-update-script-3-1-4/ http://blog.rimuhosting.com/2011/07/01/wordpress-mass-update-script-3-1-4/#comments Thu, 30 Jun 2011 22:24:47 +0000 Liz Quilty http://blog.rimuhosting.com/?p=1460 Continue reading →]]> This script will search /var/www (changeable in a variable) for any wordpress installs and make sure its upgraded to the latest version.
It will run a backup to /root/wp_upgrade/ of all files and database before doing anything with the site in case of major catastrophe (make sure you have spare disk space if your sites have a lot of uploaded files).


I have now added putting the site into maintenance mode whilst upgrading. This just involves adding a .maintenance in the document root.

It pays to check each site after the upgrade to make sure plugins all worked (and upgrade plugins before the upgrade works also!)

Let me know if you have any bugs at all, or any problems.

Here’s your script to upgrade them all.

wget http://b.ri.mu/files/wordpress-upgrade-3.1.4.sh
bash wordpress-upgrade-3.1.4.sh

MD5SUM
4c160ca05744a52965f4a42006e3f6ad wordpress-upgrade-3.1.4.sh

SHA1SUM
21db4b5683b4f57471272fb92cdb0f1eff299d0d wordpress-upgrade-3.1.4.sh

]]> http://blog.rimuhosting.com/2011/07/01/wordpress-mass-update-script-3-1-4/feed/ 0 WordPress mass update script 3.1.3 http://blog.rimuhosting.com/2011/05/26/wordpress-mass-update-script-3-1-3/ http://blog.rimuhosting.com/2011/05/26/wordpress-mass-update-script-3-1-3/#comments Thu, 26 May 2011 00:09:43 +0000 Liz Quilty http://blog.rimuhosting.com/?p=1268 Continue reading →]]> This script will search /var/www (changeable in a variable) for any wordpress installs and make sure its upgraded to the latest version.
It will run a backup to /root/wp_upgrade/ of all files and database before doing anything with the site in case of major catastrophe (make sure you have spare disk space if your sites have a lot of uploaded files).

It pays to check each site after the upgrade to make sure plugins all worked (and upgrade plugins before the upgrade works also!)

Let me know if you have any bugs at all, or any problems.

Here’s your script to upgrade them all.

wget http://b.ri.mu/files/wordpress-upgrade-3.1.3.sh
bash wordpress-upgrade-3.1.3.sh

MD5SUM
c028cf28b839513d9202ea331ef5558f wordpress-upgrade-3.1.3.sh

SHA1SUM
1d82f357ce6acdffb0d4293a47ac153b7510a243 wordpress-upgrade-3.1.3.sh

]]> http://blog.rimuhosting.com/2011/05/26/wordpress-mass-update-script-3-1-3/feed/ 0 WordPress mass update script 3.1.2 http://blog.rimuhosting.com/2011/05/02/wordpress-mass-update-script-3-1-2/ http://blog.rimuhosting.com/2011/05/02/wordpress-mass-update-script-3-1-2/#comments Sun, 01 May 2011 22:01:37 +0000 Liz Quilty http://blog.rimuhosting.com/?p=1155 Continue reading →]]> This script will search /var/www (changeable in a variable) for any wordpress installs and make sure its upgraded to the latest version.
It will run a backup to /root/wp_upgrade/ of all files and database before doing anything with the site in case of major catastrophe (make sure you have spare disk space if your sites have a lot of uploaded files).

It pays to check each site after the upgrade to make sure plugins all worked (and upgrade plugins before the upgrade works also!)

Let me know if you have any bugs at all, or any problems.

Here’s your script to upgrade them all.

wget http://b.ri.mu/files/wordpress-upgrade-3.1.2.sh
bash wordpress-upgrade-3.1.2.sh

MD5SUM
61b4bacda7060e3f40cb5c40a5a30821 wordpress-upgrade-3.1.2.sh

SHA1SUM
b55d9e69056e93610b0288f816ec9858d2756ca8 wordpress-upgrade-3.1.2.sh

]]> http://blog.rimuhosting.com/2011/05/02/wordpress-mass-update-script-3-1-2/feed/ 0