Weblog: Aug 2007

XChat, IRC Security, Privoxy Tunnels

I still use Internet Relay Chat occasionally. Sometimes I need to ask a question on IRC using WiFi in a sketchy area (say, cafe near MIT), or I want to disguise my location from random IRCers (say, when I'm at a client site or a friend's house).

Such security and privacy issues were the main motivation for using text-terminal IRC clients on trusted servers for over a decade. Now that I'm using XChat, I needed to reproduce the various encryption and IP address hiding that I had going on before. I didn't want to mess around with IRC bouncers, IRC-specific proxies, nor VPNs.

The other day, I implemented a 5-minute solution to this for XChat on my laptop, by having a hotkey sequence set up an SSH port-forwarding tunnel from my laptop, through my trusted server, to a server of a certain IRC network:

ssh -L 127.0.0.1:irc-server.foo:6667 -N my-server.foo

I had an XChat network item with only one server 127.0.0.1/6666. The XChat network options for proxy server, SSL, etc. are disabled.

However, I soon needed my old Privoxy-based Web traffic forwarding, so that I could buy something on eBay from a cafe without letting someone hijack my account session. Once I had my Privoxy tunnel again, I realized that I could solve my IRC problem by using HTTP CONNECT through the remote Privoxy, and get rid of the IRC-server-specific SSH tunnel.

To do this, I disabled CONNECT-limiting on the remote Privoxy, by adding this default action rule (which is safe to do, because the remote Privoxy listens only on 127.0.0.1):

+limit-connect{-}

Then I configured XChat to use the HTTP proxy, on XChat Preferences -> Network setup -> Proxy Server. Hostname 127.0.0.1, port 8119, type HTTP, use proxy for all connections. I got rid of the tunnel-specific XChat IRC network entry I created before.

It works fine. The main drawback is that I now need to have my Privoxy tunnel up, even when on my LAN at home. That means a tiny bit of hassle, increased traffic for my remote server, increased latency, and less chance of recovering the IRC connection when a WiFi link is dropped briefly.

Again, the right way to do this would probably be OpenVPN and either a server with a very big pipe (or lots of hassle with routing rules and SPI to VPN only sensitive traffic). I prefer the 5-minute solution for now.

When Wikis Bite Their Owners

Sometimes, your internal-use-only wiki punishes you for being too productive.

MoinMoin "surge protection."

Photo of the Day, NHTSA, Bush Fear of Analysis

Without special permission, officials [at the National Highway Traffic Safety Administration] are no longer allowed to provide information to reporters except on a background basis, which means it cannot be attributed to a spokesman. [...] The administrator is Nicole R. Nason, who took over on May 31, 2006, after she was appointed to the post by President Bush.

—By Christopher Jensen, "What's Off the Record at N.H.T.S.A.? Almost Everything," nytimes.com Wheels blog, 2007-04-22 12:07pm

Someone picked the perfect stock photo for this piece. Who can't face reporters without safety goggles?

It seems like every Federal agency employing scientists, engineers, or analysts of any kind is being gagged by the Bush administration.

Simulating a Web Server Farm Using Linux VServer on a Broken Laptop

I'm working on the architecture for a Web service that scales its dynamic content by clever use of a farm of load-balanced dumb commodity HTTP servers serving static objects. The dumb HTTP servers need only serve via HTTP objects SCP'd or Rsync'd to their local filesystems, and store access logs that be processed via a program that is copied over and invoked via SSH. A separate host (or three) controls the centralized data and coordinates the farm of fast-and-cheap HTTP pawn servers.

While developing this centralized server, I need a small farm of pawn servers for functional testing purposes. What is important is that each pawn server have its own IP address, filesystem, Apache, and SSH server. Performance testing will not be done at this point, so I can simulate the farm of pawns on a single machine, rather than filling my kitchen with old tower PCs.

Rather than power up a single tower or my spare 1U server for this purpose, I decided to use my old IBM ThinkPad X20 laptop (which is no longer useful as a laptop, after its spine-shattering drop to the floor). The ThinkPad is small, quiet, and uses little power.

For the virtualization software, I first looked briefly at Xen and Linux KVM before deciding that Linux VServer enabled the most expedient solution for my pretty straightforward requirements. I could find no correct documentation on the Web for how to do what I need with VServer on Debian, however. Hence this blog entry, which captures what I found worked, for the benefit of myself or others in the future.

I did essentially the following to create a simulated farm of size three:

1. Reserve three static IP addresses, one for each VServer guest. For my laptop, named claire (Keim), the three VServers are named claire1 through claire3, and the IP addresses are 192.168.1.201 through 192.168.1.203. claire, the VServer host, is 192.168.1.200.

2. Install Debian GNU/Linux Etch on the laptop. Just the minimum install, plus packages openssh-server and screen. Get security updates.

3. Install Debian's packaging of the Linux kernel with VServer patches:

   1. Install the package:
      

      apt-get install linux-image-vserver-686
      

   2. Edit /boot/grub/menu.lst to make the VServer kernel the first.

   3. Reboot into the VServer kernel. (Note: It seemed necessary to be running a VServer kernel before attempting to install the VServer userspace tools, to get all the Debian install-time behavior.)

4. Install the VServer userspace tools:
   

   apt-get-install util-vserver vserver-debiantools
   

5. For each VServer guest, do as for the following example of claire1, modifying the hostname, IP address, and Ethernet interface as necessary.

   1. Use the Debian-specific newvserver tool to create the guest:
      

      newvserver --hostname claire1 \
                 --domain neilvandyke.org \
                 --ip 192.168.1.201/24 \
                 --mirror http://http.us.debian.org/debian/
      

      There will be several interactive prompts. Basically:
      

      • Set time zone to U.S. Eastern.

      • Enable shadow passwords.

      • Set root password.

      • Don't create a normal user account.

      • Don't select any additional software.

   2. Configure the guest to use a virtual Ethernet interface based off eth0, so claire1 would have eth0:1; claire2, eth0:2; etc. (Note: with the newvserver in vserver-debiantools version 0.3.4, you cannot give a virtual interface with the --interface command-line option, since that triggers a bug, which is why we set the interface here.)
      

      echo eth0:1 > /etc/vservers/claire1/interfaces/0/dev
      

   3. Start the new guest:
      

      vserver claire1 start
      

   4. Install SSH server and Apache 2:
      

      vserver claire1 exec apt-get install openssh-server apache2
      

   5. Verify that you can SSH to 192.168.1.201 and that you can access the placeholder page at http://192.168.1.201/.

Now that I know what I'm doing, I'd make a script to automate this. I'd also use my own Debian mirror, grabbed via debmirror.

At time of this writing, I've not yet set up vunify.