An example would be the changing of private services (e.g. SSH) to run on non-standard ports (I see this frequently recommended as part of hardening guides anyway; there's port knocking too which could be even better, but that's not the point of this post).

In the example of hiding SSH ports, the question then comes: what port to use? One of the many ways is to make use of nmap's frequently used ports list to help make a decision.  Nmap scans using the top 1000 frequently used ports in a normal scan (although we change the scan to scan based on any top n used ports too).  So we run this in a shell to list the top 1000 (or n of your fancy) used ports:

cat /usr/share/nmap/nmap-services | \
awk '{print $3 "\t" $2 "\t\t" $1}' | \
sort -nr | head -n1000 | less

 
Let's break this command down:

cat /usr/share/nmap/nmap-services prints out the contents of the nmap-services file (used to track the probabilities of the ports used) to STDOUT.

awk '{print $3 "\t" $2 "\t\t" $1}' formats the contents of the nmap-services for the sort command to work on.

sort -nr sorts the entries by reverse numerical order.

head -n1000 shows only the top 1000 lines of output (change to any number you wish, or remove altogether to see the full list)

less displays the output in a scrollable, searchable manner.

On an ending note, it probably would be a bad idea to go straight for the last entries in the sorted list for your port selections.  Remember: we want to be unpredictable, and not simply different.

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.

Some might say that a SSH blacklist daemon might help, but it only increases the time taken for a brute force attempt, and is of no use against a botnet trying to brute force the ssh login.

There are plenty of things that can be done to lock down the ssh server, and restricting it to only publickey is by far one of the most effective, counting that the resource (the server) you're protecting is pretty important.

Plenty of interesting IPs/hosts in this list, take a look if you're really interested, heh.

reverse mapping checking getaddrinfo for 93.184.69.3.vnet.sk [93.184.69.3] failed - POSSIBLE BREAK-IN ATTEMPT! : 237 time(s)
reverse mapping checking getaddrinfo for 95-128-245-59.wiseweb.ru [95.128.245.59] failed - POSSIBLE BREAK-IN ATTEMPT! : 567 time(s)
reverse mapping checking getaddrinfo for h-69-3-215-11-static.lsanca54.covad.net [69.3.215.11] failed - POSSIBLE BREAK-IN ATTEMPT! : 543 time(s)
reverse mapping checking getaddrinfo for iodc-74-206-96-142.ioconnect.net [74.206.96.142] failed - POSSIBLE BREAK-IN ATTEMPT! : 6 time(s)
reverse mapping checking getaddrinfo for 202-153-191-246-static.unigate.net.tw [202.153.191.246] failed - POSSIBLE BREAK-IN ATTEMPT! : 5 time(s)
reverse mapping checking getaddrinfo for corporat065-167059038.sta.etb.net.co [65.167.59.38] failed - POSSIBLE BREAK-IN ATTEMPT! : 19 time(s)
reverse mapping checking getaddrinfo for ev1s-75-125-43-50.theplanet.com [75.125.43.50] failed - POSSIBLE BREAK-IN ATTEMPT! : 46 time(s)
reverse mapping checking getaddrinfo for hst13.migrateplans.com [72.46.131.181] failed - POSSIBLE BREAK-IN ATTEMPT! : 68 time(s)
reverse mapping checking getaddrinfo for bzq-179-135-183.static.bezeqint.net [212.179.135.183] failed - POSSIBLE BREAK-IN ATTEMPT! : 298 time(s)
reverse mapping checking getaddrinfo for host112163.metrored.net.mx [200.77.249.163] failed - POSSIBLE BREAK-IN ATTEMPT! : 8 time(s)
Address 98.126.208.50 maps to customer.krypt.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! : 50 time(s)
reverse mapping checking getaddrinfo for corporat200-7543230.sta.etb.net.co [200.75.43.230] failed - POSSIBLE BREAK-IN ATTEMPT! : 97 time(s)
Address 61.168.44.5 maps to pc5.zz.ha.cn, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! : 50 time(s)
reverse mapping checking getaddrinfo for ip36.70.inetmar.com [92.42.36.70] failed - POSSIBLE BREAK-IN ATTEMPT! : 50 time(s)
Address 218.28.20.135 maps to pc0.zz.ha.cn, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! : 168 time(s)
reverse mapping checking getaddrinfo for 187-5-142-129.bnut3700.e.brasiltelecom.net.br [187.5.142.129] failed - POSSIBLE BREAK-IN ATTEMPT! : 478 time(s)
reverse mapping checking getaddrinfo for cliente-13108.iberbanda.es [82.198.115.50] failed - POSSIBLE BREAK-IN ATTEMPT! : 324 time(s)
reverse mapping checking getaddrinfo for host-203-92-76-19.lga.net.sg [203.92.76.19] failed - POSSIBLE BREAK-IN ATTEMPT! : 5 time(s)
reverse mapping checking getaddrinfo for 229.1.163.220.broad.km.yn.dynamic.163data.com.cn [220.163.1.229] failed - POSSIBLE BREAK-IN ATTEMPT! : 240 time(s)
reverse mapping checking getaddrinfo for 56h29.xjtu.edu.cn [202.117.56.29] failed - POSSIBLE BREAK-IN ATTEMPT! : 54 time(s)
reverse mapping checking getaddrinfo for 202.53.76.24.nettlinx.com [202.53.76.24] failed - POSSIBLE BREAK-IN ATTEMPT! : 45 time(s)
Address 218.28.103.202 maps to pc0.zz.ha.cn, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! : 373 time(s)
Address 72.9.228.73 maps to marisil.org, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! : 6 time(s)
Address 72.9.228.73 maps to marisil.org, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! : 6 time(s)
reverse mapping checking getaddrinfo for 74.126.30.110.static.a2webhosting.com [74.126.30.110] failed - POSSIBLE BREAK-IN ATTEMPT! : 15 time(s)
reverse mapping checking getaddrinfo for 74.126.30.110.static.a2webhosting.com [74.126.30.110] failed - POSSIBLE BREAK-IN ATTEMPT! : 15 time(s)

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

Out of the 20 challenges, the only two on application flaws were pretty easy to figure out (since I've been in that field for a while), but I still had no experience/idea in figuring out those with the network/human related flaws.

Gonna start by trying out some of the tools and log analyses mentioned in the book, but I think I'm going to need some hands-on practise (white-hat, of course) in order to learn faster.

You can't know what to protect, if you don't know how they might attack.
You probably won't know how they might attack, unless you've really tried it yourself.

Note to self: don't borrow more than two books at a time, you probably can't finish one within the first borrowing time period that they give you anyway...

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.

Hacking Linux Exposed (Second Edition)

Hacker's Challenge 3 (Forensics Scenarios & Solutions)

But hey, stop wasting your time and giving me entertainment like this already, you MUST have the correct private key in order to connect via SSH. Slightly more inconvenient than using passwords, but it takes a load off my mind knowing that brute forcing passwords is simply impossible, and it would take the SSH keys to be compromised in order to get in (which won't be worth the cost/effort anyway).

Maybe I will start listing these jokers in a wall of shame or something. Maybe.