Sniffing is easy when you have access to the intermediate router, but that isn’t always the case. What if you’re just another PC on the same switch? That’s impossible, right?

I’m not the first person to write about this. Switches are not immune to sniffing. There are three techniques for sniffing traffic on an Ethernet switch:

1. Use a monitor port. With a managed switch, configure one port to receive copies of data sent to other port(s). Useful if you have administrator access to a managed switch.
2. MAC flooding. Fill up the switch’s MAC table with false entries, causing it to failover into broadcast mode. All packets will be sent to all ports. Easy to detect and hard to do on modern switches.
3. ARP poisoning. Send unsolicited ARP responses to the target devices (for instance, a PC and its default gateway), telling them to direct traffic to you. Silently route their traffic so they don’t notice an interruption.

It is the last technique that I want to discuss. Many tools exist to poison ARP, from simple command line utilities like arpspoof (part of dsniff), seringe, and arp-sk, to full-featured man-in-the-middle attack suites like Ettercap. Ettercap can poison ARP caches, sniff packets and write them to files, route traffic, and filter/change traffic content. You can find a very helpful step-by-step Ettercap tutorial here, so I won’t cover the same ground. I’d rather explain what these tools do.

ARP poisoning attacks work by sending gratuitous ARP replies to two targets, informing each of them that the attacker’s PC is the opposite target. For instance, suppose I have three devices:

1. gateway, a router on 192.168.0.1, with MAC 00:1d:73:36:ad:0c
2. alice, a PC on 192.168.0.101, with MAC 00:13:02:02:56:da
3. My PC on 192.168.0.102, with MAC 00:17:09:d2:30:25

Alice knows Gateway’s MAC address:

user@alice:~$ ip neigh show
192.168.0.1 dev wlan0 lladdr 00:1d:73:36:ad:0c REACHABLE

Gateway knows Alice’s MAC address:

user@gateway:~$ ip neigh show
192.168.0.101 dev eth1 lladdr 00:13:02:02:56:da REACHABLE

When I start the ARP poisoning attack, both Alice and Gateway learn different MAC addresses for each other:

user@alice:~$ ip neigh show
192.168.0.1 dev wlan0 lladdr 00:17:09:d2:30:25 REACHABLE

user@gateway:~$ ip neigh show
192.168.0.101 dev eth1 lladdr 00:17:09:d2:30:25 REACHABLE

Now Alice will send traffic for Gateway (probably all Internet traffic) to my PC, and Gateway will do the same for traffic intended for Alice. If we stop here, we’ll be able to see what Alice is trying to do, but Alice will quickly realise something is wrong because traffic will stop without explanation.

This is the second part of ARP poisoning (and of any Man-in-the-Middle attack): silently routing traffic onward. You can use the kernel’s IP forwarding to do this:

echo 1 > /proc/sys/net/ipv4/ip_forward

But if you do, you’ll appear in Alice’s traceroute path:

 1  192.168.0.102   2.580 ms  2.754 ms  3.312 ms
 2  192.168.0.1  1.530 ms  2.321 ms  2.964 ms
 3  192.168.1.254  60.537 ms  60.028 ms  59.573 ms
 4  79.86.25.1  19.854 ms  16.007 ms  17.413 ms
 5  ....

If you use “unified sniffing” with Ettercap, it will silently route traffic in software. Other tools, such as fragrouter (also part of dsniff), can do the same thing from the command line. Both of these tools forward traffic without decrementing the TTL, which makes them invisible to traceroute.

ARP poisoning is not silent. It can be detected by both hosts, because you are manipulating their ARP tables. These gratuitous ARP replies are easily visible with a sniffer:

 0.636848 00:17:09:d2:30:25 -> 00:1d:73:36:ad:0c ARP 192.168.0.1 is at 00:17:09:d2:30:25
 0.637622 00:17:09:d2:30:25 -> 00:13:02:02:56:da ARP 192.168.0.101 is at 00:17:09:d2:30:25
 10.680712 00:17:09:d2:30:25 -> 00:1d:73:36:ad:0c ARP 192.168.0.1 is at 00:17:09:d2:30:25
 10.684618 00:17:09:d2:30:25 -> 00:13:02:02:56:da ARP 192.168.0.101 is at 00:17:09:d2:30:25

Most tools send these ARP replies regularly, to keep ARP table entries from timing out. For instance, Ettercap sends them every 10 seconds. This is suspicious, as ARP requests are normally only seen when a host is first discovering another one. It is necessary to prevent true ARP requests from briefly changing the ARP table back to its correct state. Several tools exist to detect or prevent ARP poisoning, like ArpON, arpwatch, and DHCP snooping.

I’ve used traditional security terms like “victim” and “attacker” in this post, and of course ARP poisoning is a useful technique for unauthorised spying. However, it has legitimate uses. I’ve used it a number of times in situations where I had to sniff but couldn’t interrupt the physical cabling or didn’t have a managed switch. Whatever the problem, there is no faster way to understand a network problem than sniffing the raw data.

Nothing in this process is specific to KDE, so Ubuntu or Xubuntu users can use this as well. Steps:

1. Choose a strong password
2. Create an encrypted ~/Private directory
3. Copy home directory files into ~/Private
4. Move ~/Private to $HOME
5. Encrypt swap
6. Make /tmp a tmpfs

Caveat emptor: If you encrypt your home directory, then later forget your password and fail to write down the mount passphrase, you are screwed. There is no practical chance that you will recover your files. As always, make a backup.

Step 1: Choose a strong password

If you aren’t already doing this, you’re not likely to use this guide. Security is a mindset, not a tool. Get used to keeping strong passwords in your head. Ubuntu makes using encryption really easy, but it is only as effective as the strength of the password you choose.

My recommendation is to use pwgen with -B or even -By:

pwgen -By

Ohz:ah7s aiT7gex% AhNae)Z3 Ohph*i9e va9eZuo[ Mei7ieZ~ Ohb7Za]o Piek+ai3
fa!m3Sho ua~ch7Wa tom?oh9U do{i4Aep tuF4oof} Na#a4eiH epe\G3oh aR3ahp^i
...
Aip$aim9 Eph%a3pu gae7aY`a Ie^cah4t sha+uY3v ove3aeZ= Wie4yei| Oc\aeb9e

The -B option tends to generate passwords that are balanced between hands and at least partly pronouncible, so this isn’t as hard as you think. If you do use -y (special characters like +), consider the keyboards you might have to use. If you use both British and American keyboards, don’t use £, @, “, `, #, ~, \, or |, as all of these are in different locations.

Pick one and and make a mnemonic to help you remember it. Write it on a piece of paper, put it in your wallet, and burn it once you memorise it. Write it on your belly with a sharpie; whatever it takes. Change your password now:

passwd

Your password will later become the passphrase that protects the encryption keys to your home directory. ecryptfs includes excellent PAM support, so if you change your password later it will update the key too.

Step 2: Create an encrypted ~/Private directory

Since I upgraded from an earlier install without an encrypted home or ~/Private directory, I had to create one. If you are about to install 9.10 from a CD, the installer has an option to encrypt your home directory. Just use that. Or create a new user:

adduser --encrypt-home username

If you’ve already got an encrypted home, congratulations! The hardest part is done. Skip to step 5.

If not, let’s get started. Linux Mag’s Dustin Kirkland has written an excellent guide to this process. Much of my process is based on his, but I include a few corrections. For most of this you can remain logged in to your Desktop, but the process is simpler from the Linux console. The initial copy process will make you want to get up and do something else while it finishes anyway.

Logout from the Desktop, which should return you to the login screen. If your login screen is configured to log you in automatically, cancel it. Then press Ctrl+Alt+F1 to go to the first Linux virtual console.

Login at the prompt, and create an encrypted $HOME/Private directory:

ecryptfs-setup-private

Enter your login passphrase:
Enter your mount passphrase [leave blank to generate one]:

At the first prompt enter your user password. At the second, press Enter. Now record the mount passphrase which was just generated:

ecryptfs-unwrap-passphrase $HOME/.ecryptfs/wrapped-passphrase

Print it out and put it with your birth certificate in your fire-proof document safe. You do have one, right? If something goes wrong you will need this later.

Log out, and log in again.

Step 3: Copy home directory files into ~/Private

Make sure you have at least 50% free on /home, or this may fail.

rsync -aP --exclude=.Private --exclude=Private --exclude=.ecryptfs $HOME/ $HOME/Private/

If you don’t have 50% free, first move some files from $HOME to $HOME/Private, and rsync the rest.

cd
mv -v Videos Music Pictures DirectoryOfBigFiles $HOME/Private/
rsync -aP --exclude=.Private --exclude=Private --exclude=.ecryptfs $HOME/ $HOME/Private/

This will take a long time to complete. Every file is being encrypted as it is copied or moved. If you have a lot of files and an under-powered CPU (such as on a netbook), it will take even longer. I moved 178 GB of data on my Dell Vostro 1500 (Intel Core2 Duo 2 GHz, 4GB RAM) in about 5 hours. Get a coffee, walk the plants, shave the cat, come back later.

When done, logout to sync any remaining changes to disk.

Step 4: Move ~/Private to $HOME

Now we need to do some things with sudo. Still on console, login again. Unmount $HOME/Private:

ecryptfs-umount-private
cd /
sudo mkdir -p /home/.ecryptfs/$USER
sudo chown $USER:$USER /home/.ecryptfs/$USER
sudo mv $HOME/.ecryptfs /home/.ecryptfs/$USER/

Create a new home and populate it with the ecryptfs files:

sudo mkdir -p -m 700 /home/$USER.new
sudo chown $USER:$USER /home/$USER.new
sudo mv $HOME/.Private /home/.ecryptfs/$USER/
sudo ln -s /home/.ecryptfs/$USER/.ecryptfs /home/$USER.new/.ecryptfs
sudo ln -s /home/.ecryptfs/$USER/.Private /home/$USER.new/.Private
sudo ln -s /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt /home/$USER.new/README.txt


Switch to the new home, tell ecryptfs that we’ll mount it at login, and make it read-only (until it is mounted):

sudo mv $HOME $HOME.old
sudo mv $HOME.new $HOME
echo $HOME > $HOME/.ecryptfs/Private.mnt
sudo chmod 500 $HOME

Now for the moment of truth. Still on console, logout, and login again. Your home directory should mount:

mount | grep ecryptfs

/home/username/.Private on /home/username type ecryptfs (ecryptfs_sig=9cec4d81c9bcb6e0,ecryptfs_fnek_sig=c735e6facb299611,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

Create some convenient links:

ln -s /home/.ecryptfs/$USER/.ecryptfs $HOME/.ecryptfs
ln -s /home/.ecryptfs/$USER/.Private $HOME/.Private

Once you verify that all your user data is there, securely wipe any files that have important data, and then remove the old home.

cd $HOME.old
find .kde .gnupg .ssh PathsToDirectoriesOfImportantFiles -print -exec shred -u {} \;
rm -rf $HOME.old

Step 5: Encrypt swap

Your home directory isn’t the only place your private data may be written to disk. When your computer doesn’t have enough RAM for everything it wants to have open, it swaps. This means some RAM is written to disk to be read back later. Thus, swap can contain anything you have ever have open. Swap does not need normally to survive reboots *, so we’ll encrypt this with a random key every time we boot up.

* The one exception to this is hibernate mode (suspend to disk). If you want to use hibernate, don’t encrypt swap, or use a (less secure) static key. Encrypting swap has no impact on sleep mode (suspend to RAM). I never use hibernate.

Thankfully, this is a very easy process with Ubuntu. Despite the misleading name, this uses cryptsetup, not ecryptfs:

sudo apt-get install cryptsetup
sudo ecryptfs-setup-swap

Step 6: Make /tmp a tmpfs

The last place your private data is commonly written is the temp directory, /tmp. The contents of this directory don’t need to survive reboot either, and are commonly cleared at bootup. It is possible to encrypt it using cryptsetup just as with swap, but we don’t need to. Instead we’ll make this a tmpfs. This means /tmp will be an auto-resizing virtual RAM disk. By default it is allowed to grow to up to 50% of RAM.

Don’t worry about this consuming your RAM. If the contents of RAM is swapped to disk, static content like /tmp will be the first to go. And it isn’t much data anyway; my /tmp rarely grows beyond 200 MB. Plus, using a tmpfs will save power when in battery mode.

Add one line to your /etc/fstab:

echo "tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0" >> /etc/fstab

If you are logged in to the desktop, log out completely. Then login on console one last time, and run:

sudo rm -rf /tmp/*
reboot

That’s it! You are now running a cryptographically secure laptop, protected against all but the rubber-hose attack.

Why is this bad? For several reasons. One, it makes cross-site scripting attacks easier. Once you login to a web site that uses HTTP authentication, you’ll stay logged in. If you leave Firefox running for days, you’re vulnerable for days.

Two, suppose you want to login to the same site with different credentials. Perhaps you have both an admin account and a regular user account, and you want to switch between them. Or perhaps you are setting up a site and need to test another user’s login. The only way to do this with Firefox now (as of 3.0.13) is to completely quit the browser and restart.

Enter: the Web Developer extension. This is a great extension, but it has far more features than you’re likely to need. On the other hand, it is great for dissecting web sites, viewing table borders, and eliminating annoying CSS themes. And it has a way to clear HTTP authentication tokens.

Install the extension. If you prefer, hide the “Web Developer” tool bar. Now to log out of HTTP auth, navigate through the menus Tools -> Web Developer -> Miscellaneous -> Clear Private Data -> HTTP Authentication.

Warning: basic HTTP authentication is not secure. Digest HTTP authentication is better. You should only use either of these with HTTPS, so your transport is encrypted end to end.

Update 2009-11-25: Since upgrading to Firefox 3.5, you no longer need this extension to log out of HTTP auth. As noted in the comments below, go to Tools -> Clear Recent History -> Details, check only “Active Logins”, and then press “Clear Now”.

Jul 12 14:15:26 mailserver.example.com postfix/smtpd[19885]: NOQUEUE: reject: RCPT from 206.12.0.10.in-addr.arpa[10.0.12.206]: 554 5.7.1 <symons@yahoo.co.uk>: Relay access denied; from=<yyjaqveh@lpsb.com> to=<symons@yahoo.co.uk> proto=ESMTP helo=<206.12.0.10.in-addr.arpa>

IP addresses have been obscured to protect the guilty (or ignorant, as this is certainly a botnet). Unfortunately, a large number of the IP addresses in question belonged to my own satellite customers. Mail servers for our other domains were almost entirely unaffected. Which tells me that some bastard has written a botnet spam client that looks up its own public IP, finds the reverse DNS entry, looks up the MX record of the corresponding domain, and then attempts to relay mail through that server. This is particularly mean, as it will encourage your own ISP to shut you down.

I ignored these attempts at first. The server was rejecting them and the botnet didn’t appear to be trying to relay through anyone else (according to traffic logs). With our Postfix settings it was unlikely they’d ever succeed. Then the log entries moved from “annoying” to “problematical”:

Jul 13 20:34:50 mailserver.example.com postfix/master[18904]: warning: service “smtp” (25) has reached its process limit “200″: new clients may experience noticeable delays
Jul 13 20:34:50 mailserver.example.com postfix/master[18904]: warning: to avoid this condition, increase the process count in master.cf or reduce the service time per client
Jul 13 20:34:50 mailserver.example.com postfix/master[18904]: warning: see http://www.postfix.org/STRESS_README.html for examples of stress-adapting configuration settings

Time to do something about it. We already use fail2ban to protect other services, so I enabled the postfix rules. In /etc/fail2ban/jail.local:

[postfix]
enabled  = true
ignoreip = 127.0.0.1/8   # suggest listing your valid server IP ranges here
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/mail.log
bantime  = 3600

I then reloaded fail2ban, and waited for results. Within a few minutes (fail2ban takes time to parse existing logs), 65 IP addresses were banned. Here are my results 24 hours later, edited for brevity:

root@mailserver:/etc/fail2ban# fail2ban-client status postfix

Status for the jail: postfix
|- filter
|  |- File list:        /var/log/mail.log
|  |- Currently failed: 49
|  `- Total failed:     58171
`- action
   |- Currently banned: 68
   |  `- IP list: ...
   `- Total banned:     3883

Now to hunt down the customers with botnet infections and start sending “violation of terms of service” warnings.