This just illustrates one of Microsoft’s 10 Immutable Laws of Security:

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

So how to do this?

1. Upload DD-wrt’s latest ‘VPN’ firmware build for the WRT 54G
2. Generate certificates for the WRT router on the central server (a linux box at my home network in this case which hosts the PKI)
3. Add the following to the central server OpenVPN conf file: route 192.168.10.0 255.255.255.0
4. Create a ccd file with the same filename as the name you chose for the WRT during certificate setup and put the following in the file: iroute 192.168.10.0 255.255.255.0
5. Make sure the WRT syncs its time through NTP. Otherwise certs might be detected as invalid!
6. Paste these certs in the web interface of the DD-WRT and do the basic configuration through the webinterface.
7. Adapt openvpn.conf to my specific setup by enabling the following in the DD-WRT startupscript:

   sleep 20
   echo "auth SHA1" >> /tmp/openvpn/openvpn.conf
   echo "cipher AES-256-CBC" >> /tmp/openvpn/openvpn.conf
   killall openvpn
   openvpn --config /tmp/openvpn/openvpn.conf --route-up /tmp/openvpn/route-up.sh \\
   --down /tmp/openvpn/route-down.sh --daemon

8. Adapt the firewall script to disable natting and accept traffic for the OpenVPN interface on the WRT. Real firewalling will be done on the central linux box

   iptables -t filter -I FORWARD -i tun0 -j ACCEPT
   iptables -t filter -I FORWARD -o tun0 -j ACCEPT
   iptables -t filter -I INPUT -i tun0 -j ACCEPT
   iptables -t filter -I OUTPUT -o tun0 -j ACCEPT
   iptables -t nat -I POSTROUTING -o tun0 -j ACCEPT
   iptables -t nat -I PREROUTING -o tun0 -j ACCEPT

9. Done! Both networks are now interconnected!

It took me some time to get it up and running Saturday but I think that the little hangover I had from a fine party I attended Friday night in Leuven was to blame for that (damn you Cristal beer )

I run a VMware server @home on my Core 2 Duo machine to test some OS/configurations without the need of physical machines. In the beginning of this year I needed to replace the hard drive of this machine and since it is a Core 2 Duo I chose to install a 64 bit Debian on the machine as main OS.

Ever since then, I was having strange problems with the VMware server on that machine. It was able to run a windows guest (except if the guest was under high load) but unable to run a linux guest. When I booted a linux guest OS on the server it simply crashed the host. And I do mean crashed, the system was totally unresponsive and nothing was to be seen on the screen or in the logs pointing to a cause of the error. I blamed it on the ‘experimental’ 64 bit support in VMware server although it seemed to run fine on some Xeon systems @work. Anyhow, a virtual machine crashing the host machine is not good! It means that there are some very serious issues in the software which could possibly be exploited for bad.

With the new release out today, I checked the release notes hoping for a clue that my issue was finally resolved. A lot of issues were fixed but my specific issue was not mentioned. A little disappointed, I started the upgrade process from my 1.0.3 to 1.0.4 anyway and it appears to be that I am lucky today because I am now able to run windows, linux and other guests without problems! So the issue must have been resolved by one of the fixes they implemented in 1.0.4!

Apart from some sleeping in, squash, hanging out in the pub, going out, catching up on my favorite feeds, watching some TV (I have refound my old love for South Park ), assembling a new gas barbecue (and eating food from it ), I have been playing with sguil.

Sguil is an open source framework to practice network security monitoring (NSM). It uses SANCP and barnyard to analyze Snort data. It seems like a good framework but the documentation is, in my opinion, not the best I have ever seen. After some compilation issues, I have managed to get all the needed software compiled now on my Linux box. The only thing left to do is to configure it to match my needs.

But, that will be something for later. Right now, Jack Bauer is eager to get his nephew back from the Chinese.

Although not as easy as just running ‘apt-get dist-upgrade’, the upgrade went very smooth. I just had to follow the release notes and after a reboot both servers ran the newly released version fine. Well, actually one server did not came up right away but that had nothing to do with the upgrade. A manual file system check was needed. Thanks to the quick support from the techies at serverpronto, the server was back up within the hour.

If it takes as long as it took Etch to become a stable release, the next major upgrade will be somewhere 22 months from now.

For those interested, these were the steps taken to upgrade from Debian 3.1 (sarge) to Debian 4.0 (etch):

• aptitude update
• aptitude -y -s -f –with-recommends dist-upgrade
• aptitude upgrade
• aptitude install initrd-tools
• aptitude install linux-image-2.6-686
• aptitude dist-upgrade
• aptitude update
• reran ‘aptitude upgrade’ and ‘aptitude dist-upgrade’ until no packages were kept back and nothing remained to be done.
• reboot
• removed obsolete packages from old sarge.
• recompiled home-built soft. (This was not really necessary but I liked to have the soft compiled with the new gcc4)

If, for some reason, you would like to know more about the steps taken, just drop me an email.

Fortunately, I had setup an rsync which synced all my data and most of the server configuration to an external USB disk every night. Not much data was lost.
But, even then, restoring the server took more time than I expected. This is mostly because I learnt the hard way that having all the config files on a backup is not a guarantee for a fast restore. Installing all the apps (with dependencies), compiling some soft, compiling a custom kernel for the motherboard takes a LOT of time.

Therefore I have taken my precautions in case the replacement disk should decide to go on permanent leave in the near future. I googled a bit and found mkCDrec. This neat tool allows one to create a bootable recovery CD set from the entire system including installed applications. When necessary, you can boot with the CD set and quickly restore the system in the state when you created the disks.

So from now on, whenever I make big changes to the system. I just run mkCDrec, save the ISO images to my external disk and that’s it: I am a little better prepared for when Murphy strikes once more.

Next on the improvement list: buy a small UPS for when lightning strikes