Looks like I'll have to look into further automating some of the tasks...

I'm not going to describe how it works here, there's plenty of literature out there that talks about it.  And if that's not enough, Google Is Your Friend.

One of the simpler ways to defend against it is to have the server only serve requests with legit Host headers, which is what Wikipedia says anyway.  (No I didn't edit that portion myself)  This can be simply done with virtual hosts (HTTP/1.1), and can work for servers serving one domain, or two, or three, or many many many.

For nginx, a default catchall virtual host might look like this:

server {
    listen 80 default;
    server_name can-be-anything-not-served;

    access_log /path/to/log/weird/access.log;
    error_log /path/to/log/weird/error.log;

    root /path/with/only/an/empty/index/html/file;
    index index.html;
}

Note that this is configured to be the default listener on port 80 for this virtual host. Make sure your actual virtual host(s) configuration does not have the 'default' option.

The server_name can be anything other than the actual virtual host(s) that the server is serving on port 80.

I usually put nothing (only empty index.html files) in that root folder for this catchall virtual host,but you're free to put other files to serve indicators to your users, or just to taunt them when they get subjected to DNS rebinding attacks unknowingly.  Just kidding about the taunting.

With this default catchall virtual host in place, you have a simple yet effective defense against DNS rebinding attacks!  Now watch the attacks get thwarted like eggs against a steel wall.

Note that this is helpful in situations where you don't expect HTTP/1.0 requests, which is usually the case in today's world.  If you have a case where you have  work with HTTP/1.0 requests, then you really shouldn't use this defense method in the exact same manner.

Lesson learnt: even if tools like WordPress Automatic Upgrade helps you to perform backups, make sure you know everything is backed up before you do a delete!

Even though all the posts have been restored, I think I will not restore any more of the lost images, so there.

Of course, as there could be a root kit/trojan/malicious stuff running in your system as rkhunter's meant to detect, you should NOT fully trust anything running from the machine. But I had to rely on this solution temporarily until I can get it (rebooted and) checked out proper using a tool like Finnix.
Am reposting the script here for reference, but you can get the most recent copy of the script here .

#!/bin/bash
desc="
This script will verify whether files for which rkhunter has logged a
warning for is still valid. It does this by finding which debian package
it came out of, and downloads them, unpacks them, then checks
the checksums.

Run it by supplying a rkhunter log file as first argument
"

HASHER="sha256sum"

IFS="
"
function find_suspect_files
{
	echo "parsing $1 for suspect files" 1>&2
	grep -1 Warning "$1"| grep File | sed 's|.*File: ||'
}

function find_packages
{
	echo "finding packages" 1>&2
	for suspect_file in $1
	do
		package=$(dpkg -S $suspect_file|awk '{print $1}'|sed 's/.$//')
		echo "suspect file $suspect_file found in $package" 1>&2
		echo $package
	done

}

function make_aptitude_args
{
	echo "generating aptitude arguments" 1>&2
	for package in $1
	do
		version=$(dpkg -p $package | grep Version | awk '{print $2}')
		echo $package=$version
	done
}

function cleanup
{
	echo "cleaning up"
	popd
	rm -rf tmp
	exit $1
}

function setup
{
	echo "setting up"
	rm -rf tmp
	mkdir tmp
	pushd tmp
}

if [ $# -ne 1 ];
then
	echo "$desc"
	exit 1
fi

suspect_files=$(find_suspect_files "$1")

packages=$(find_packages "$suspect_files" | sort | uniq)

if [ -z "$packages" ];
then
	echo "***WARNING****"
	echo "No packages contain any of the suspect files!"
	cleanup 1
fi

aptitude_args=$(make_aptitude_args "$packages")

setup

echo "downloading packages"
aptitude download $aptitude_args 1>/dev/null
if [ $? -ne 0 ];
then
	echo "aptitude download failed!"
	echo "args=$aptitude_args"
	cleanup 1
fi

echo "unpacking"
for deb_file in *.deb
do
	ar -x $deb_file
	tar zxf data.tar.gz
	rm -rf data.tar.gz control.tar.gz
done

for suspect_file in $suspect_files
do
	if [ ! -f ".$suspect_file" ]
	then
		echo "***WARNING****"
		echo "For some reason .$suspect_file does not exis!"
		continue
	fi
	echo -n "verifying $suspect_file... "
	suspect_sum=$($HASHER $suspect_file | awk '{print $1}')
	clean_sum=$($HASHER ".$suspect_file" | awk '{print $1}')
	if [ $suspect_sum == $clean_sum ];
	then
		echo "OK"
	else
		echo
		echo "***WARNING****"
		echo "Checksum mistmatch for $suspect_file!!!"
		echo "Should be: $clean_sum"
		echo "Is: $suspect_sum"
	fi
done
cleanup

The code that I used was based from this forum post. This one presumes that your MTA has been setup properly. The original code was for protecting your root account (i.e. when anyone logs into your server's root account, you get the notification).

(Note: it is usually not advisable to login as root. Create a user account and give it sudoer rights instead. I'd say that's advisable even for servers where there is only one person expected to login, which is you.)

 

Protect only the root account

If you want to protect only the root account, edit the file /root/.bash_profile or /root/.profile (the bash profile file takes precedence)

Add this line at the end:
echo 'ALERT - Root Shell Access on:' `date` `who` | mail -s "Alert: Root Login from `who | awk '{print $6}'`" youremailaddresshere
 

Protect all accounts

If you want to protect ALL accounts, which is better for high security requirements, or for paranoid people like me, you edit the /etc/profile file instead. (you will need root priviledges for this)

For me, I used this instead of the previous command:
echo 'ALERT - Shell Access:' `date` `who` | mail -s "Alert: Shell Access from `who | cut -d"(" -f2 | cut -d")" -f1`" youremailaddresshere

With this, you'll get a notification whenever anyone logs in. The downside to this is that you may get too many emails on a server that has plenty of people logging in.