This is what’s being logged on honeynor.no when I (84.215.x.y) google the word “honeynor“.

84.215.x.y - - [18/May/2010:23:42:55 +0200] "GET / HTTP/1.1" 200 17832 "http://www.google.com/ \
search?hl=en&source=hp&q=honeynor&aq=f&aqi=g-s1g-sx7&aql=&oq=&gs_rfai=&fp=64bbd6d9727d98e0" \
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) \
Firefox/3.6.3"

I haven’t left google yet!, but my very intelligent browser thinks I might click on the first link (www.honeynor.no) so it goes ahead and access the site, way before my puny brain has had any chance on processing the search output. In true PKD-style, I hereby accuse firefox of a precrime!

Why is this action bad? Let me answer the question with a question; Do you always want to access the sites presented to you when you search the web? I can think of several cases where I’m not keen on letting some third party know of my interest in them; either that’s during an analysis or in case of possible repercussions against me for accessing a site in an unexpected or socially engineered manner.

It seems google is in cahoots with firefox on this one, because I’m unable to reproduce the same result using bing, yahoo or alltheweb. Only on google is the prefetch mechanism activated.

So, how can you disable this feature? Luckily it very easy; go to about:config in your firefox/mozilla browser and set the parameter network.prefetch-next to false. That’s it!

On your vmware server, go to the following directory:
/usr/lib/vmware/webAccess/tomcat/ \
apache-tomcat-6.0.16/webapps/ui/plugin/

Copy the appropriate vmrc plugin for your client platform (mine was a 32 bit Ubuntu 10.04 Desktop, so I grabbed vmware-vmrc-linux-x86.xpi).

On your client, unzip the xpi-file:

$ unzip vmware-vmrc-linux-x86.xpi

Run the vmrc executable (it’s actually just a wrapper script) manually by specifying the absolute path (I extracted the contents to /tmp):

$ /tmp/vmrc/plugins/vmware-vmrc

The vmrc UI starts, and you can connect to your vmware server by either specifying it’s hostname or it’s IP-address, together with your username and password (I also had to specify the port, e.g. <IP>:8333). When a connection has been established with the server, you will be presented with a selection of virtual machines you may connect to.

Nmap was one of the first tools to implement this. Lets try it out!

Download the latest development release from http://download.insecure.org/nmap-dist/ (at the time of writing: 4.85BETA6) and the usual configure, make, sudo make install should to the trick, but in case you run into compile- or run-time errors you may want to check out this page. (If you face run-time complaints about openssl, you should follow this link). There’s also binaries available for Windows and OSX.

The following is an example of a basic scan for conficker

nmap -sC -PN -d -p445 --script=smb-check-vulns \
--script-args=safe=1 192.168.1.1

For large-scale scans, you may invoke nmap with some optimisations parameters as recommended here.

nmap -sC -PN -d -p445 -n -T4 --min-hostgroup 256 \
--min-parallelism 64 --script=smb-check-vulns \
--script-args=safe=1 10.0.0.0/8

In addition to the no-ping (PN) and port specific scan (p) we added no-dns-resolution (n), more aggressive timing controls (T) and parallel scanning with group of 256 hosts (with at least 64 simultaneously). The two latter parameters may be tuned even further for increased performance. The recommendation is to maintain a 4:1 ratio between the two values, and keep the upper limit to 4096/1024.

Using safe=1 as an argument sent to the script, the MS08-067 vulnerability is not really checked. Using unsafe=1 and it will be checked, however be aware of a possibility that the vulnerable server service may crash.

Here are some examples of the output from the script smb-check-vulns (with MS08-067 check enabled):

|  MS08-067: LIKELY VULNERABLE (host stopped responding)
|  Conficker: Likely INFECTED

|  MS08-067: FIXED
|  Conficker: Likely CLEAN

…So, scan your network now, while it’s still possible.

In many situations I like to use the -t option to partition the log files based on time, e.g. -t 1h to get one pcap file each hour (aligned on the hour). Also, I usually create a dedicated disk partition for pcap storage. In these situations I think Daemonlogger doesn’t quite “cut the mustard”. It’s missing an easy way to have it utilize most of the dedicated disk space and rotating the pcap files based on time intervals whilst maintaining an active ring-buffer. Of course, you may use the -s option to rotate based on the size of the log file (in bytes) and also set a count limit with -m. But, as I mentioned, I’m more of a time guy.

This is why I made a small patch to Daemonlogger which implements the missing feature. The added option (-x) lets you specify the amount of free space you want to have on the disk where the pcap files are stored.

daemonlogger -i eth0 -d -l /var/log/pcap -S 0 -t 1h -x 500 -r

In the above example, daemonlogger sniffs on eth0 interface, runs in daemon mode, logs to /var/log/pcap with a max snap length and creates a new file every hour on the hour. When there is less than 500 MiB of free space on the disk device that holds /var/log/pcap, the ring-buffer will activate and delete the oldest file in that directory.

Download file: daemonlogger.honeynor.patch

Disclamer: I’m by no means an experienced C-programmer, so you’re on your own pal if you apply this patch :)

Below you can find my very first screencast, showing how this sample was unpacked. Enjoy! :)

(will open in new window)