You may remember the Home Virtualization Project from last year.  In that project, I converted my existing server, based on a Shuttle XPC (SP35P2 Pro, to be more precise) from a Linux server running VMware Server 2.0 to a VMware ESXi 3.5 server.  It worked well, but left a few things to be desired, such as..

1. No RAID
2. Onboard NIC required significant fiddling to get working under ESXi 3.5u4
3. No onboard video, so I needed a video card, plus a network card to get going (the real root cause of #1 above).
4. A bit loud.  The system wasn’t terribly loud, but for something that’s on full-time in the background in my office, it could be distracting at times.

So here we are, it’s a brand-new year, so the big project was an upgrade, inspired by some requirements I found with a project at work.  In the end, the old server was converted into a workstation and now has a happy home.  So what’s the current system?  Another Shuttle XPC.  This time, it’s the SG45H7.  This is a slightly smaller chassis than the already small SP35P2 Pro.  The SP line has space for 2 hard drives up top, above the optical drive that the SG line lacks, resulting in a shorter case.  The SG45H7 is targeted as an HTPC, and includes onboard video with both SVGA and HDMI outputs.  Further, it includes 2 expansion slots, one PCIe x16 and one PCI. Continue reading »

As some of you may know, though may or may not actually care, I was previously running my home server on Ubuntu Jaunty x86_64, and ran VMware Server 2.0 on it.  I had VMs for my SSL VPN and some occasionally used VMs for other things.

I was tired of performance that VMware Server offered, along with its baggage.  For instance, the Web UI suffered from frequent crashes, and it was also fairly slow.  Having had great success in the lab at the office with VMware ESXi, I decided that was the way to go.  ESXi 4.0 is still fairly new, and I’ve had some trouble with my SSL VM on it, so I decided to sit that one out for a bit, leaving me with 3.5u4.

Next hurdle – my hardware.  I use a Shuttle XPC for my server.  It’s small, and doesn’t inhale too much power, so I found it to be a good choice as a Linux server, what it’s spent most of its time as.  Unfortunately, as it uses a Marvell Ethernet chipset (the sky2 driver), and that’s not on the VMware HCL, there wasn’t a driver for it.  But then, KernelCrash to the rescue.  The author gives very nice build instructions to get a mod_sky2.0 driver that works on ESXi 3.5u4.  It’s been good enough that I haven’t noticed any problems with performance or functionality.

I did have to give up my Linux software raid, so at the moment, I’m sort of running without a net.  My plan is to add an external RAID box, either connected via eSATA or 1GbE NAS.  Obviously eSATA will perform better, but I’m not yet convinced I’ll see much of a practical performance difference.  I’ll add a new Intel e1000 NIC to the system dedicated to storage if I do that.  Anyone have thoughts on VMware iSCSI vs NFS performance?

Now I’ve got VMs for my SSL VPN, my File/Pri DNS/DHCP/kitchen sink server, a secondary DNS, and a FreeNAS, as well as some assorted client systems to test various things.  All in all, it’s worked very well.

If you want to go straight to ESXi 4.0, KernelCrash has you covered there as well.

IDS Install with Tap

I wanted to install a small network ids on my home network using Snort.  I wanted to stick the nids outside of my firewall, so it would be able to examine all Internet traffic coming in & out of the network.  Of course, putting a device online outside my firewall without any protection isn’t terribly attractive, so I decided to install using a tap.  Ignoring the fact that this is really the only possible configuration, given my home ISP (FiOS), it allows me to do a completely stealthed deployment of a nids.  Unfortunately, this type of deployment also precludes the ability to interact with any traffic seen on the wire, so flexresp is out of the question.

Construction of a passive tap

The other bad part about using a tap is that simply by the nature of the tap, you need to have 2 Ethernet ports to sniff on.  Why?  Check out the Snort docs on the subject.  When you setup a tap, you can only push one direction’s worth of traffic onto a single port.  This means you have to combine the traffic on the sniffing device.  Since you can only receive traffic and can’t send on these ports, you must have a third Ethernet port to connect to your internal network, or if you’ve got a larger network, a management LAN.

So, building your tap is pretty simple, when you’ve got the picture here on the right to work from.  Need the parts?  Head over to Home Depot and grab yourself the following parts:

1. A plastic electric box (get one marked for “Old Work”).  An 8 cubic inch box will probably not be deep enough, so go for the one of the 14 cubic inch ones.  Unscrew the little anchor flaps and toss them in the trash.
2. A 4-jack faceplate.  Whatever color you like.  I used white.
3. 4 Cat 5e Ethernet jacks.  I got 2 white and 2 blue.  The white jacks are the Host jacks, and the blue ones are Tap A & B, as shown in the figure at the right.
4. About 6 inches of Ethernet cable.

Strip off the jacket and remove the 8 wires.  Wire up the jacks as shown in the figure.  I found it easiest to wire up one of the host jacks, then run the wires through the tap jacks and finally up to the other host jack.  Try to keep the twists in the wire as much as possible, to prevent NEXT (Near End Crosstalk).  Cap off the jacks and screw the thing into the electric box.

I made two, one to use for the NIDS, and another to carry around for work if I need a tap.

I’m not going to go into how to install Snort, ACID, or any of that stuff.  There are already enough guides out there on that topic.  I will, however, address the need to join the two sniffing interfaces into a single full-duplex interface for Snort to sniff on.  You’ll be using the Linux kernel’s bonding module for this.  I’m going to assume Debian or Ubuntu here.  Add the bonding module to your /etc/modules file, then execute the command modprobe bonding.  In the /etc/network/interfaces file, you’ll need something like this:

auto bond0
iface bond0 inet manual
  up ifconfig $IFACE 0.0.0.0 up
  down ifconfig $IFACE down
  post-up ifenslave bond0 eth0 eth1
  pre-down ifenslave -d bond0 eth0 eth1

Obviously, you’ll need to configure Snort to sniff on the bond0 interface.  Don’t forget to install the ifenslave package.  It’s not installed by default on Ubuntu.

The biggest concern lots of tap novices have is accidentally introducing traffic onto the wire via the tap.  Let’s be clear.  This is simply impossible.  Can’t happen.  At all.  Why?  The only pins that are live on the tap ports are 3 and 6.  Guess what happens on those pins?  It’s only RX, not TX, so you can’t transmit on the tap ports.

Bookmarklets

Bookmarklets rock.  They’re great timesavers, and a worthy addition to your browser’s bookmark bar.

So, what’s a bookmarklet?  In short, a bookmark, typically constructed with JavaScript that does a specific task.  For example, emailing some data via your favorite webmail provider, or checking Bugmenot for a login to a site you don’t really want to register for, or generating a shorter URL for a site.  Here are the ones I keep around.  Hopefully you’ll use some of them.  To grab them, mouse over the link and drag to your browser’s bookmark bar.  I recommend you make a folder on your bookmark bar and toss your bookmarklets in that folder (that’s what I do).

Here’s the breakdown of my favorite bookmarklets…

Google Services

Google This: Select some text on a page, click the bookmarlet, blammo – you’ve got a Google search for the selected text.

Google Images: Select some text on a page, click the bookmarlet and you’ve got a Google Image search for the selected text.

GAppMail This: Send the selected text via Google Apps for Your Domain Mail. You’ll need to edit this one to change out yourdomain.com for what your domain name actually is.

Gmail This: Send the selected text via Gmail.

Google Cache: Pull up the Google Cache version of the currently loaded page.

Google Map This: Select an address, get a Google map of it.

Geocode: Get the Latitude & Longitude for the center of a Google map.

Google Translate: Translate the currently loaded page into English

Web Development

Show Divs: Show the <div> areas on the currently loaded page.

ReCSS: Reload CSS for the currently loaded page.

W3C HTML Validator: Run the currently loaded page through the W3C’s HTML Validator.

W3C CSS Validator: Run the currently loaded page’s CSS through the W3C’s CSS Validator.

References

Acronym Lookup: Lookup an acronym in the Internet Acronym Database

Urban Dictionary Lookup: Lookup a selected word in the Urban Dictionary.

Social Networking

Del.icio.us Linkbacks: Show del.icio.us links to the current page.

Compulsory Login Bypass

BugMeNot: Lookup usernames & passwords for various sites.

URL Shorteners

DiggBar: Uses the new DiggBar for URL shortening.

Cli.gs: Uses the Cli.gs shortening service.

Yesterday, I hopped in my car (a 2005 Honda Civic that I picked up back in 2004), and went to the Wawa about a mile away to pick up a bit of lunch.  The car started fine, drove just fine, and all seemed, well, fine.  That is, until I got in the car to come back home.  The car wouldn’t turn over, no power, no nothing.  Just a very faint clicking noise that lasted about 5 seconds after turning the key off.

Yup, it was a dead battery.  Fortunately, as it was only a mile, I walked home, ate my lunch, then as Heather & the kids had arrived back at home, we hopped in the van to go back over.  I could have avoided this if I’d simply left the jumper cables in my trunk.  For some unknown reason, I took them out and left them in the garage after I’d last used them.

One jump start later, I was able to drive the car back home.  I grabbed the van keys, ran to Pep Boys and grabbed a new battery, as the old one was the original, now nearly 4 years old, and had a dark eye – i.e. It’s Dead Jim.  Swapping out the battery was easy enough, and then I found a new problem.  My radio has the anti-theft feature that requires a 5-digit code to unlock it.  Fortunately, after a bit of googling, I found that if you sit in the driver’s seat, open the glove box and look at the little sticker on the left side of the outer shell of the glove box, you’ll find two numbers.  The one on top is 5 digits.  Guess what?  It’s your radio code.

Wildly convenient for situations like this, but what if my radio were stolen?  Someone smart enough to steal a radio is probably also smart enough to look at a sticker that’s less than a foot away from the radio, right?

My latest project with the eee 1000 was to get some better wifi range, possibly saving some battery life in the process.  My first thought was to go for a replacement antenna.  I ordered one on eBay, and was prepared to do a bit of mod work to get it done.  Just then, the seller didn’t send me my antenna parts, but instead sent me an Intel Wifi Link 5300 MiniPCIe card.  We agreed to just call it even at that point.  I bought a different antenna at that point.  You’ll see why.

Conventional wisdom calls for (as many others have done previously) an Intel 4965 MiniPCIe card. The 5300 seems to be the successor to the 4965, boasting up to 450 Mbps of 802.11n performance.  Not having any 802.11n APs, I wouldn’t know about that just yet.  We’ll see.  Unfortunately, this card doesn’t have drivers in the mainline Linux kernel until version 2.6.27.  As I’m running Ubuntu Hardy (until Intrepid Ibex rolls out), and on kernel 2.6.24, no drivers exist, outside of the backported ones from compat-wireless guys.  Well, since the drivers exist, I decided to give it a go.

First up, grab the firmware and the drivers package.  Unpack the firmware and drop it in /lib/firmware.  Next, you’ll need to install the “build-essential” package, as well as the linux-headers packages appropriate for your kernel.  Unpack the drivers, check the config.mk file.  You should probably (as I did) uncomment the lines that enable support for the RFKILL code.  This is what gives you the ability to toggle the wifi on & off.  Do a make & make install (as root) to load the drivers up.  It will not overwrite existing mac80211 modules, and that’s a good thing.  Halt your machine and do the card swap.

Installing the card was pretty easy.  Pull the battery and unplug first.  After all, you don’t want to short things out, right? Ok, now remove the two screws that hold down the existing Ralink wifi card and pop the two antenna leads off.  Now install the Intel card and put the screws back.  Connect the white wire to terminal 1, and the black to terminal 2.  Terminal 3 is where you’ll need to connect the extra antenna.  I opted for a small antenna, typically used for a bluetooth radio, but since it’s a 2.4 Ghz antenna, it also works fine here. I snaked the wire through one of the small gaps in the plastic housing adjacent to the wifi card, and used the adhesive backing on the antenna to stick it in the hole where the hard drive goes on a 1000h.  Not sure where you’d want to put the antenna on a 1000h, but then again, that’s not my chief concern, as I’m working on a 1000.  Put back all the screws and you’re done.

Boot the system, and you should be all done.  The card should be automagically detected and have the iwlagn module loaded.  You’ll likely want to gently massage your /etc/acpi/eeepc-wifi-toggle.sh script to work with the proper modules.  Removing the module and echoing a 0 into /proc/acpi/asus/wlan (to power down the card) results in the card going into “deep sleep”.  My last bit is to figure out how to wake it from deep sleep, other than a reboot.