« May 2005 | Main | December 2005 »

August 2005 Archives

August 24, 2005

Useful layers of indirection

Recently, I've been building systems using Linux's Logical Volume Manager (LVM) and XFS filesystems. While LVM adds a layer of indirection to disk access, it has offers significant benefits. Primarily, I've been taking advantage of this combination to back up filesystems on production servers. Using xfs_freeze to suspend disk activity, then quickly creating a snapshot of the filesystem with LVM, I can then resume activity on the production server while I copy the snapshot filesystem to a remote backup location. LVM has a large number of other features, but its snapshot abilitity has been the largest win for me.

I'm using the same mapping code in the 2.6 Linux kernels to encrypt all the partitions on my laptop. The Debian cryptsetup package uses dmsetup to provide encrypted partitions. Compared to using cryptoloop (deprecated) or loop-aes (requires modified losetup and mount), dmsetup is nearly trivial to use. In a very short period of time, I've converted my Debian laptop to use an encrypted root partition, encrypted swap partition, and encrypted LVM physical volume. I created my local data partitions as logical volumes on the encrypted LVM physicial volume. All this was quite painless to setup. Operation is similarly simple: the cryptdisk init script asks for the passphrases of the encrypted partitions upon booting.

While it's been 14 years since my last laptop was stolen, I'm reassured knowing my system is strongly encrypted if such misfortune recurs.

Encrypted root filesystem question

François-René ÐVB Rideau asked:

Interesting. Can you publish your configuration files and the list of packages used? Do you carry the key on a floppy? On a USB key? Or do you type a long key at boot up? Is all of the disk encrypted, or only the user partition? etc.

The configuration files are minimal. The important Debian package to install is cryptsetup. In the /usr/share/doc/cryptsetup directory are HOWTOs for setting up encryption on root and swap partitions. Those files are short and the instructions worked perfectly for me. I compiled my own kernel using make-kpkg from the kernel-package package. You'll need a 2.6.4 or later kernel with cryptographic routines and LVM enabled. While I use a monolithic kernel, using modules and mkinitrd works fine as well.

My key is a fairly long passphrase. It can be whatever length you want, but you need to type it into the prompt at boot time. Reading from USB keys is not supported by the startup script, but I imagine you can hack it without much difficulty if you wanted to read from a USB mount at boot time.

You setup encryption by partition. My laptop partition structure is:

/dev/hda1/boot200MBext3unencrypted
/dev/hda2/19GBxfsAES encrypted
/dev/hda3swap1GBswapAES encrypted
/dev/hda4LVM60GBLVM PVAES encrypted

I created several logical volumes on the encrypted /dev/hda4 while leaving 5GB available for temporary snapshots volumes.

My /etc/crypttab looks like this:
root /dev/hda2
cswap /dev/hda3 /dev/random swap
mainpv /dev/hda4

Besides the very helpful HOWTOs in the Debian package, I also referred to this useful guide.

I hope that helps, let me know if you have more questions.

August 28, 2005

Return of the backup MX host

Last year I wrote about the death of the backup mx host for my domains. In the arms race against spam, I've found a very helpful tool allowing the return of my backup MX hosts.

Recapping the history, one of my domains has been under a persistant SMTP dictionary attack for over a year. I get 3-10 emails a second with guessed destination email address. Sendmail on the primary MX host is rather efficient at rejecting these so the only real effect is my 200MB of email logs a day. However, spammers often target the backup MX host since they usually have less spam filtering. Last year, the attack took down my backup MX host. The backup host will kindly accept a message for any username in the appropriate domain. Then, it will try to deliver them to the primary MX host. If the primary MX host rejects the username as invalid, the backup MX host tries to send a reject message back to the sender. The breaks down when the sender is a spam zombie that is not running a SMTP server. The backup MX host queues the reject message while it attemps redelivery for a number of days. My backup MX host has 500,000 reject messages in its queue before the load average become too great.

A great piece of software fixes this problem. SnertSoft's no-cost milter-ahead sendmail filter handles this sort of attack very well. The author is very responsive. I found only one issue with the software: it wouldn't compile or run on AMD64 platforms [typical issue of the C long type varying between 32 and 64-bit platforms]. In just a few hours, the author updated his code and milter-ahead is now running very well on my Debian AMD64 servers.

milter-ahead runs on a gateway or backup mail server and checks the RCPT during the SMTP connection with the a designated MX host. If that "look-ahead" host is down, milter-ahead will accept any email, which is the right thing to due. If the designated host is up, then milter-ahead can do one of several things. But, it's primary use is to query the designated host and verify that the receipient address is valid. If it is not, then the milter rejects the RCPT and avoids queueing the message. If the receipient is valid, then milter-ahead allows the backup MX host to accept the message for forwarding.

Now that my backup MX host won't be queueing email for invalid email addresses, I've brought that system back online. If you're running a gateway or backup mail server, you'll likely find milter-ahead a useful tool.

About August 2005

This page contains all entries posted to Kevin Rosenberg in August 2005. They are listed from oldest to newest.

May 2005 is the previous archive.

December 2005 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.