It's basically an Ubuntu 8.04 server on a VMware 6.5 image, running plenty of old and vulnerable services.  Yummy!

It is available to Metasploit Express customers from the Customer Center, and for the rest of us peeps, it's freely available for download via Bittorrent. (a bit slow, but I'll try to seed this for as long as possible when I managed to get it entirely)

More info at the blog post.

[via Metasploit Blog]

Starting to get quite concerned, since there was a lot of stuff that was previously installed, like those that you "need" to install in order to view online videos.

Will start to do some verbose logging to gather more info, but this isn't looking good so far.  How this came up was because of the way the computer tried to connect to the site, apparently it tried to make too many connections at the same time, causing the router to think that there's a SYN flood attack going on lol.

Culprit #1 - 221.238.197.38 [robtex report]

Other culprits: 204.2.160.27 [rb], 61.155.137.7 [rb]

Some (or probably most/all) of your searches might involve public IP addresses, and more often than not we would want to have additional info along with the IP address to work with.

Three of the things that we could do in Splunk automatically would be to get IP-location info, or to reverse lookup an IP to a domain, or to lookup a domain to an IP.

1. Geolocation

There're two ways to do geolocating of IPs: using the iplocation command, or to use the MAXMIND app.

1a. iplocation

The command iplocation is described as:

Finds ips in _raw and looks up the IP location using the hostip.info database. IPs are extracted as ip1, ip2, etc. Cities and Countries are likewise extracted.

What we only need to do is to pipe the search to iplocation and let it do the rest!  The lookups are done from the server on the fly, so make sure that the server is able to do whois/ns lookups on the network.

index=myindex | iplocation

1b. MAXMIND app

Like previously mentioned before: install the MAXMIND app, then pipe the field containing IPs to the lookup (the field name must be clientip, if not this will not work duh)

This can work with the server not having any internet connectivity, but the accuracy is entirely dependant on the cached MAXMIND database.

index=myindex | lookup geoip clientip

or

index=myindex2 | lookup geoip clientip as fieldwithip

2, 3. IP-hostname or hostname-IP

These two items are pretty similar.  Spunk 4 comes with a lookup script called external_lookup.py, and the config is already in the default transforms.conf.  So we only need to use it!

Resolving IPs to hostnames:

index=myindex | lookup dnslookup clientip

Resolving hostnames to IPs:

index=myindex | lookup dnslookup clienthost

(no screenshot, sorry )

Leave a comment if this helped, or if you want to ask anything!

One of the things I encountered when using Splunk was that it didn't seem to be indexing all the log files that it was set to monitor.  After some reading up and experimenting the reason became clear: Splunk will not work properly if you set it to monitor too many files.

How many is too many?  For example, setting it to monitor a logfile directory which only has one active log and 100+++ rotated logs, is too many.  What should be done instead is to set it to monitor the active logfile only, and use oneshot adding of the other logfiles to the index you want.

Gonna do some more sharing/writeups about this crazily great tool.  There's really a lot that this thing can do man.

• Adblock Plus: you know what this is for...  Remember to disable when performing penetration testing.
• CacheViewer: Allows for viewing and sorting of cache files.  Seldom used, but a great tool nonetheless when the need comes for it.
• Domain Details: Displays plenty of information about the server (type, headers, IP, location) that you're accessing.  Good for basic information awareness during normal surfing.
• Download Statusbar: View and manage downloads from a tidy statusbar.
• DownThemAll: For fast grabbing of files from a directory.
• Firebug: Powerful tool for web developers that allows you to freely manipulate/view the loaded objects for a page.  I haven't really figured out how to use this for penetration testing yet though.
• Greasemonkey: Could come in very handy if you want to do some mods to a site's page automatically, remember to enable/disable the scripts that aren't needed when on a penetration testing job.
• IE Tab: Don't really use this, unless I get a site that's coded to work only with "browsers like IE".
• iMacros for Firefox: Another powerful macro editing/playback tool, I don't use this though
• JavaScript Debugger: JS debugger and profiler, more useful for web developers I think.
• Live HTTP headers: Great for showing basic information about the HTTP headers being exchanged.
• NoScript: A MUST-HAVE for Forefox.  Whitelists the scripts and objects that are allowed to load for a domain, amongst other protection features against other nasties out there.  Remember to disable for penetration testing engagements.
• People Search and Public Record Toolbar: Great tool for information gathering, pity I never had the chance to really use it
• ScrapBook: Aids in archiving and organizing pages.  I use it to profile a site's workflow.
• SwitchProxy / FoxyProxy: A must-have for changing between the many proxy tools that I use.
• Tamper Data: I use this to grab extra timeline information about the loading of pages.  Also allows you to do request/response editing.
• User Agent Switcher: Self explanatory.  Useful for certain situations only.
• View Dependencies: A must-have for organizing image/JavaScript/CSS resources for a page in a tidy manner.
• View formatted source: Formats HTML source neatly for viewing.
• View Source Chart: Formats final document DOM (after all the loading/JavaScript events have finished firing) for easy viewing.  Also for when View formatted source isn't available for the version of Firefox that you're using.
• Web Developer: Great for manipulating the forms/cookies/JavaScript/whatnot on a page.  A definite must-have for penetration testing.

Web Security Dojo is a turnkey web application security lab with tools, targets, and training materials built into a Virtual Machine(VM). It is ideal for both self-instruction and training classes since everything is pre-configured and no external network connection is needed. All tools and targets are configured to use non-conflicting ports and a Firefox proxy switcher is set up to match.

Web Security Dojo is an open source project built on Ubuntu and hosted at SourceForge. It is available in three flavors: a Virtualbox VM, VMWare VM, and a build script which can be used on a standard Ubuntu 9.10 install to produce the Dojo. Collaboration and contributions are welcomed.

Looks pretty promising, I will be checking this out and writing more (as usual, when my "relaxed" schedule allows me to) later.  But this looks like one of those training tools that I wished existed far earlier: a full environment with the targets and tools to let you learn and train your web application security kung-fu.

So what're you waiting for ?!  Go grab a copy and try it out!  Unless you really really want to see a review from me first.  Heeeyyaaaahhhh!!

Runs in Windows only, though that's not going to stop me from trying to run it under Wine.. heh.

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

Testing RSnake's Slowloris tool against a test nginx setup for myself: Though at first glance nginx is indeed not susceptible to such an attack, but observing the actual behaviour shows up some weird points. Will write more when I have some more answers/observations.

Conclusions can be found at the bottom of this post, if you can't stand reading about experiments and whatnot.

Edit (15 Oct)

It seems that nginx is indeed affected by the Slowloris attack. Whilst the attack is in progress, no other connections can be made to the server (thus causing the DOS situation).

Based on the way Slowloris works (sending headers slooooowly) the reason why this works against nginx is because of the max file descriptors limit. Apparently each network connection to any process uses up one file descriptor, and the OS limits this number (ulimit in linux). By default it is set to 1024, though it can be changed.

I'm not sure whether this is exactly the same as the original Slowloris attack, because Slowloris exhausts a web server specific resource (Apache's max clients for example), whereas hitting max file descriptor limits is a OS/process level "resource".

This is a problem nonetheless, because we could try to raise the max file descriptors limit for the nginx process, and they still can be all taken up by long-lived slow-sending HTTP requests like what Slowloris does.  The only difference is that it would take FAR more connections to Slowloris attack a nginx server successfully as compared to process-cased web servers like Apache.

A problem encountered so far is that nginx seems not to honour the client_header_timeout directive, so it starts returning a "Request time out" status (408) to the Slowloris threads after a while, even when Slowloris is set to a far lower timeout than the nginx server is.  Will need to check up more on this, though with this behaviour nginx automatically recovers from a Slowloris attack after a while

Edit (27 Oct)

After checking out ids and maxims reply in the forums, did some tests with the max file descriptors raised for the nginx process. Did it not by raising the ulimit -n value, but by setting worker_rlimit_nofile to a higher value. As a result nginx was able to take in "more" concurrent incoming connections this time, at least till the new ulimit for the nginx process was hit.

An interesting thing of note is that the client_header_timeout directive determines how much time a connection has to complete sending its headers for the request to be processed, and not how long nginx is willing to wait after receiving a header before it deems a connection as timed out.  This turned out to be the main factor in defending nginx against SlowLoris, when combined with nginxs other characteristics.

Conclusions

1. nginx is able to defend against small-mid scale SlowLoris attacks because it terminates requests that have not completed within a specified time (60 sec by default).  Thus the basic SlowLoris attack WON'T work, since it relies on sending headers one at a time to keep a connection occupied.

2. nginx can be downed by SlowLoris, however, if many attack nodes are used.  We will need a total of file descriptor limit for nginx / 50 SlowLoris threads to successfully mount an attack.  50 because SlowLoris is coded to run 50 connections per thread.  This would (in theory) cause any released connections to be quickly taken up again by new SlowLoris connections.  SlowLoris would also have to be set at <60 secs to work.  This is more like a DDOS attack than a SlowLoris attack though...

3. The problem with (2) above is that we might need a huge number of resources to mount it (DDOS level?).  If nginx was set to 100,000 max files limit, we would then need 100,000 / 50 = 2000 SlowLoris threads!

4. The access logs for nginx show the attack in progress as it kicks out the client connections

So... nginx is a good web server, use it!