Lars Strand's blog

26 Nov 2009

Network monitoring with MRTG

If you work with any kind of networks, the chances are you've heard of, or even used, MRTG. There are not active development of MRTG today, but bugfix patches are still being added now and then.

So why are we still using it? MRTG just works. It stable and robust. And it does what it is supposed to do and nothing else. This makes MRTG still king of monitoring network equipment over SNMP. Well, that is, until Munin 1.4 is released in a couple of days. Munin 1.4 have (better) SNMP support - they are aiming at MRTG.

So until Munin 1.4 is released and stabilizes, I'll use MRTG in production. I've added some minor wrappers around MRTG so that adding and removing nodes gets dead easy. This way, other people can add/remove equipments without knowing too much about MRTG.

Every Linux distribution out there have MRTG in their repository. If yours don't, change distribution or compile MRTG yourself.

1. First of all, we add all our network equipment in a text file:

$ cat /etc/mrtg/network.cfg
#
# SNMP capable switches goes here
#
# After adding hosts here, run
#
#   /etc/mrtg/mrtgmaker.sh
#   /etc/mrtg/indexer.sh
#
# Format (community is optional) and override default
#
# [community]@IP description
#
# Example:
# 192.168.1.1 Core Network Router 1 (Location A)
# secret@10.0.0.1 Core Network Router 2 (Location B)
10.1.1.1 Cisco 6500 08/09 Core Network Router 1
192.168.1.1 Cisco 4948 09/09

2. I create a small script that reads the network equipment from the text-file and generate mrtg.cfg:

$ cat /etc/mrtg/mrtgmaker.sh
#!/bin/bash
#
# This should be run every time you add a SNMP capable
# switch under /etc/mrtg/network.cfg
#

[ -r /etc/mrtg/network.cfg ] || exit 1

ALL=""

while read switch
do
   if `echo $switch | grep -q ^#` || `echo $switch | grep -q "^$"`; then
        continue
   fi
   HOST=`echo $switch | awk ' { print $1 }'`
   ALL="$ALL $HOST"

done < /etc/mrtg/network.cfg

echo "Harvesting SNMP info from $ALL"

/usr/bin/cfgmaker --snmp-options=:::::2 --show-op-down --global 'AddHead[_]: ' --global 'Options[_]: growright, bits' --global 'HtmlDir: /var/www/html/mrtg' --global 'ImageDir: /var/www/html/mrtg' --global 'LogDir: /var/lib/mrtg' --global 'ThreshDir: /var/lib/mrtg' --community=SECRET --output=/etc/mrtg/mrtg.cfg --subdirs=HOSTNAME $ALL

echo "Config file: /etc/mrtg/mrtg.cfg"
echo "You should now run /etc/mrtg/indexer.sh"

3. Then we need to add a script to update the HTML

$ cat /etc/mrtg/indexer.sh 

#!/bin/bash

#

# This should be run every time you add a SNMP capable

# switch under /etc/mrtg/network.cfg

#

echo '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>

<head>

<title>MRTG @ Company Name</title>

<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">

<meta http-equiv="Refresh" content="300">

<meta http-equiv="Cache-Control" content="no-cache">

<meta http-equiv="Pragma" content="no-cache">

<meta name="robots" content="noarchive">

<link href="favicon.ico" rel="shortcut icon">

<link rel="stylesheet" type="text/css" href="mrtg.css">

</head>

<body bgcolor="#FFFFFF" text="#000000">

<h1>MRTG @ Company Name</h1>

<img src="company_logo.png" height="135" width="130" align="right" alt="Company Name logo"/>

<blockquote>

' > /var/www/html/mrtg/index.html

while read switch

do

if `echo $switch | grep -q ^#` || `echo $switch | grep -q "^$"`; then

continue

fi

IP=$(echo $switch | cut -d" " -f1)

IP=${IP#*@}

DESC=$(echo $switch | cut -d" " -f2-40)

DATE=$(date)

DNSNAME=$(dig +short -x $IP 2> /dev/null)

echo "Indexing $IP"

/usr/bin/indexmaker --nolegend --subtitle='<h2><a href="../">Back home</a></h2>' \ 

--pageend="<em>MRTG @ Company Name - generated on $HOSTNAME</em>" \ 

--addhead='<link rel="stylesheet" type="text/css" href="/mrtg.css">' \ 

--output /var/www/html/mrtg/$IP.html  --filter name=~$IP \ 

--title="Network utilitization for $DNSNAME ($IP)" /etc/mrtg/mrtg.cfg

if [ -z $DNSNAME ]

then

echo "<font size="+1">⇒ <a href="$IP.html">$IP</a> — $DESC</font> <br>" >> /var/www/html/mrtg/index.html

else

echo "<font size="+1">⇒ <a href="$IP.html">$IP</a>, $DNSNAME — $DESC</font> <br>" >> /var/www/html/mrtg/index.html

fi

done < /etc/mrtg/network.cfg

echo "

</blockquote> 

<p>MRTG is also used as datasource for our Network Weathermap — <a href="http://weathermap/">http://weathermap</a>

<hr>

<em><font size=\"-1\">More info: <a href=\"http://wiki/mediawiki/index.php/MRTG\">

http://wiki/mediawiki/index.php/MRTG</a></font><br></em>

<em><font size=\"-1\">Generated by $HOSTNAME:$0</font></em>

</body>

</html>" >>  /var/www/html/mrtg/index.html

4. We add a stylesheet to make thing a little prettier:

$ cat /var/www/html/mrtg/mrtg.css
body {
background-color: #EFEFEF;
color: #000000;
font-family: sans-serif;
font-size: 12px;
}

h1 {
background-color: #CCCCCC;
font-family: sans-serif;
font-size: 18px;
font-weight: bold;
}

h2 {
font-family: sans-serif;
font-size: 16px;
font-weight: bold;
}

a {
text-decoration: none;
}

5. We test:

# /etc/mrtg/mrtgmaker.sh
Harvesting SNMP info from 10.1.1.1 192.168.1.1
Config file: /etc/mrtg/mrtg.cfg
You should now run /etc/mrtg/indexer.sh
# /etc/mrtg/indexer.sh
Indexing 10.1.1.1
Indexing 192.168.1.1

We are then presented with an overview page then takes us to each switch/router:

27 Aug 2009

Slackware 13 released!

Slackware 13 was released yesterday. It's the oldest currently maintained Linux distribution out there, and with good reason. It is clean, simple and without the "bells and whistles" that clobbers up so many other distributions.

Slackware was for myself (and for many of my friends and colleagues) my first encounter with Linux. I used Slackware for many years, and still do on occasions. Its a great distribution to really learn Linux and not learn a Linux distribution. I will say that if you really know Linux (and Slackware), you will know most Linux distributions as well.

You would think Slackware was abandoned for other more popular distributions nowadays, but there is still a large active Slackware community and user base out there. It is in fact, one of the most downloaded Linux distributions (in both MB and number of hits) for Norway's largest ftp-site:

http://ftp.uio.no/stats/usage_200907.html#TOPURLS

16 Jun 2009

Quick and strong file-encryption with OpenSSL

To quickly encrypt a file with a password of your choice you can use OpenSSL. OpenSSL supports a whole range of ciphers, including government approved encryption algorithms. The encryption algorithm AES is the only accepted open confidentiality algorithm here in Norway (read more here). AES is the new algorithm replacing DES. You can read all about AES and DES elsewhere.

To encrypt a file using AES with a 256 bit key-length:

$ openssl enc -e -aes-256-cbc -salt -in filename.odp -out filename.odp.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

The encrypted file is now found as filename.odp.enc

Since symmetric block ciphers process one block of data at the time (AES uses a block length of 128 bits), it is important that we use CBC mode. CBC prevents repeating plaintext to create the same (repeating) ciphertext. Use option -p to have OpenSSL print out the salt, key and IV used:

$ openssl enc -e -aes-256-cbc -salt -p -in filename.odp -out filename.odp.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
salt=92BCA2EA0EABCA62
key=1BCE6E251E86A6379066B634FD20CD3090981B50CDF3FF5634C49DCF4A1812A5
iv =9604DF84236BB3965083830396277636

To decrypt the file: Note! If you type in the wrong password, you'll get garbled output since there is no way to check if the password is correct.
$ openssl enc -d -aes-256-cbc -in filename.odp.enc -out filename.odp
enter aes-256-cbc decryption password:

And the decrypted file is found as filename.odp

For example: You can encrypt a file with a password of your choice. Send the file to the receiver, and then communicate to him over another secure communication channel what the password is (and that you've used "aes-256-cbc").

19 May 2009

Encrypted swap, tmp and home partition in Ubuntu 9.04

I really would like to have an encrypted swap, tmp and home partition on my laptop. In case it gets stolen or if I should forget it somewhere, I can be sure that no-one would be able to read my private files. In this mini-howto I set my home partition using LVM, but using a regular partition should work just fine. This howto should also work, with minor modification, if you use another distribution than Ubuntu.

Updated:
May 2009: Updated for Ubuntu 9.04. Added encrypted /tmp.
May 2008: Init for Ubuntu 8.04.

Note! Both the "server" and "alternate" Ubuntu ISO-images provide the option to encrypt your home directory (but in a different way using eCryptfs. Swap and /tmp are not encrypted). It might be an easier solution if you find this page too hard to follow. The difference? They are two different implementations. eCryptfs is file level encryption, LUKS is block device (/dev/sda3). Think of it like SSL vs. IPSec. Both have their advantages and drawbacks. Read more here and here

By using Linux Unified Key Setup (LUKS) setting up encrypted partition in Linux is done in no time.

Prerequisites

Install required packages:

# apt-get install lvm2 cryptsetup libpam-mount

The device-mapper should be active (if not, reboot):

$ ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 61 2009-05-19 15:39 control

..with support for crypto:

# dmsetup targets | grep crypt
crypt            v1.6.0

Good. Now we're ready.

Part I: Setting up encrypted swap

Step 1: Disable your current swap partition.

# swapoff /dev/sda2

Step 2: Fill your swap with random data.

# dd if=/dev/urandom of=/dev/sda2 bs=1M
1954+0 records in
1953+0 records out
2048094208 bytes (2.0 GB) copied, 529.177 s, 3.9 MB/s

As you see, this might take some time depending on your swap size. So go grab a coffe.

Step 3: Configure encrypted swap.

Add this to your /etc/crypttab

# cat /etc/crypttab
...
cryptoswap /dev/sda2 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,swap

Why /dev/urandom and not /dev/random? The latter blocks until it got enough entropy to continue, urandom don't. So if you use random instead urandom you might have to wait during boot until enough entropy is collected. (It does help to type your keyboard and move the mouse.) Use /dev/random if you're really paranoid.

Next, change your swap entry in /etc/fstab to this:

# cat /etc/fstab
...
/dev/mapper/cryptoswap swap swap sw 0 0

For every time we boot, swap will be encrypted with a different encryption key.

Step 4: Test it.

Reboot to test.

We now have an encrypted swap:

# cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/mapper/cryptoswap                  partition    2000084    0    -1

# cryptsetup status cryptoswap
/dev/mapper/cryptoswap is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/sda2
offset: 0 sectors
size:    4000185 sectors
mode:    read/write

Good. Now we're safe right?

Part II: Dealing with /tmp

To protect /tmp, we have two choices. 1) we can encrypt it like we did with swap or 2) we can create a ramdisk. The content of a ramdisk don't survive a reboot and /tmp rarely is used for any big files, its is also a good option. But, paranoid as we are, we choose option 1)

The setup is almost identical as for swap:

Step 1: Setting up a tmp partition using LVM.

If you use a regular partition, you can easily skip this step.

# pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created
# vgcreate vg_storage /dev/sda3
Volume group "vg_storage" successfully created
# vgchange -a y vg_storage
0 logical volume(s) in volume group "vg_storage" now active
# lvcreate -L500M -nlv_tmp vg_storage
Logical volume "lv_tmp" created

For more details on how to use LVM, please check out the excellent LVM HOWTO.

Step 2: Fill the partition with random data.

# dd if=/dev/urandom of=/dev/vg_storage/lv_tmp
1024001+0 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 139.983 s, 3.7 MB/s

Step 3: Add entry in /etc/crypttab

# cat /etc/crypttab
...
cryptotmp /dev/vg_storage/lv_tmp /dev/random cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,tmp

Now, since /tmp is encrypted with a new key every time, the filsystem must be created every time as well. The option "tmp" fixes that for us and calls mkfs before mount. Since it is created with filesystem ext2, we add in fstab:

# cat /etc/fstab
...
/dev/mapper/cryptotmp /tmp ext2 defaults 0 0

Step 4: Test it.

Reboot to test.

We now have an encrypted /tmp partition as well. Great!

# cryptsetup status cryptotmp
/dev/mapper/cryptotmp is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/mapper/vg_storage-lv_tmp
offset: 0 sectors
size:    1024000 sectors
mode:    read/write

Part III: Creating and setting up an encrypted home partition

Step 1: Setting up a home partition using LVM.

If you use a regular partition, you can easily skip this step.

# lvcreate -L20G -nlv_home vg_storage
Logical volume "lv_home" created

Step 2: Fill your soon-to-be home partition with random data.

# dd if=/dev/urandom of=/dev/vg_storage/lv_home
20481+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 5554.23 s, 3.9 MB/s

This will take even longer than the swap partition. So go for lunch or something.

Step 3: Initialize the partition and set initial key.

Remember, if you use a weak password, your screwed. If you forget the password, its game over.

# cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/vg_storage/lv_home

WARNING!
========
This will overwrite data on /dev/vg_storage/lv_home irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

We use cipher "aes-cbc-essi", since the default is vulnerable to Watermarking attack.

Step 4: Create a device mapping.

# cryptsetup luksOpen /dev/vg_storage/lv_home cryptohome
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

This will create a device mapping, as can bee see under:

$ ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 61 2009-05-19 15:39 control
brw-rw---- 1 root disk 252, 4 2009-05-19 15:52 cryptohome
brw-rw---- 1 root disk 252, 1 2009-05-19 15:39 cryptoswap
brw-rw---- 1 root disk 252, 2 2009-05-19 15:39 cryptotmp
brw-rw---- 1 root disk 252, 3 2009-05-19 15:52 vg_storage-lv_home
brw-rw---- 1 root disk 252, 0 2009-05-19 15:39 vg_storage-lv_tmp

Note that LVM also uses the device-mapper (that is why LVM volumes also are listed).

Or, you can use the command "dmsetup ls" to list the mapped devices:

$ dmsetup ls
cryptoswap    (252, 1)
vg_storage-lv_tmp    (252, 0)
cryptotmp    (252, 2)
vg_storage-lv_home    (252, 3)
cryptohome    (252, 4)

Step 5: Create a filesystem.

We now have an encrypted partition. To use it, we need to create a filesystem on it:

# mkfs.ext4 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/cryptohome
mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1310720 inodes, 5242623 blocks
52426 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
160 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
      32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
      4096000

Writing inode tables: done
Creating journal (32768 blocks): done

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Step 6: Testing!

We start by closing and reopen the encrypted partition before we mount it:

# cryptsetup luksClose cryptohome
# cryptsetup luksOpen /dev/vg_storage/lv_home cryptohome
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
# mkdir -p /mnt/cryptohome
# mount /dev/mapper/cryptohome /mnt/cryptohome
# touch /mnt/cryptohome/testfile
# ls /mnt/cryptohome/
lost+found   testfile

We can also confirm that it works by issuing the command:

# cryptsetup status cryptohome
/dev/mapper/cryptohome is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/mapper/vg_storage-lv_home
offset: 2056 sectors
size:    41940984 sectors
mode:    read/write

Now would be a good time to move your current home to this partition.

Finally we umount:

# umount /mnt/cryptohome
# cryptsetup luksClose cryptohome

Step 7: Cryptohome mounted at boot or at login?

Now you have to take a choice. A) You can enable the partition at boot time, but then the boot sequence is interrupted asking you for the LUKS password. B) If you want the partition automatically mounted when you login, skip to the next section.

Instead of manually typing in password, you can have the key stored externally - for instance on a usb-stick. Read more about that here.

You want to enable mounting at boot time? Then update /etc/crypttab:

# cat /etc/crypttab
...
cryptohome /dev/vg_storage/lv_home none luks

And /etc/fstab:

# cat /etc/fstab
...
/dev/mapper/cryptohome    /home/ ext4 relatime,errors=remount-ro 0 2

When you now reboot, the boot process is interrupted asking you for the LUKS password. If you type it correctly, the home partition is mounted. When you now log in, you will have an encrypted home partition ready waiting for you.

Part IV: Automatically mount when logging in.

A more elegant solution would be to automatically mount the home partition the same time you log in. This require that you use the same password for login as for the encrypted partition. (Actually that is not entirely true. You may have the password stored on file somewhere. But in this howto, we assume you have the same password for both.)

Step 1: Remove home partition from /etc/fstab

If there is an entry to your (encrypted) home partition in /etc/fstab, remove it

# cat /etc/fstab
...
/dev/mapper/cryptohome    /home ext4 relatime,errors=remount-ro 0 2 # this gotta go

Step 2: Update /etc/crypttab

Make sure the you have a line in /etc/crypttab that reads as follows:

# cat /etc/crypttab
...
cryptohome /dev/vg_storage/lv_home noauto luks

Step 3: Configure pam_mount

Add the following entry in /etc/security/pam_mount.conf.xml. This file is heavily commented, and it may be useful to read the comments.

# cat /etc/security/pam_mount.conf.xml
...

Step 4: Configure PAM

No longer necessary. As of 9.04 all options already included.

Step 5: Test!

Log out and back in. You should now have an encrypted home:

$ df -h
...
/dev/mapper/_dev_mapper_vg_storage-lv_home
                       20G 296M   20G   2% /home

Congratulation, you now have an encrypted swap, tmp and home partition!

A final advice: Take regular backups.

Useful links:

"dm-crypt: a device-mapper crypto target": http://www.saout.de/misc/dm-crypt/
"dm-crypt HOWTO for Debian unstable and testing": http://www.saout.de/tikiwiki/tiki-index.php?page=HOWTO

23 Apr 2009

Sharing Internet connection over bluetooth in Ubuntu

Me and my girlfriend are staying in a hotel here in Sha Tin, Hong Kong. Since the hotel only allow one computer per room connected to the Internet at the time - I found out it would be a nice time to look into Internet connection sharing over bluetooth. There are some documentation on how to set up PAN in Linux, so the prosess should be pretty straightforward. One posting I found mention some software called "Blueman". Turns out Blueman can do all the work for me with the click of a button.

It's even in Launchpad, so I can install it using apt. I start the applet, go into "Local Services", enable NAP, and.. it just works! This is getting too easy!

Mass EXIF date and time manipulation

I'm out traveling and I forgot to change the timezone on my camera again. So the EXIF time stored in the pictures are all wrong. My first though was to write another Perl script to fix this (se earlier post). But I found out that the program jhead can do all sort of magic EXIF manipulation. To mass change EXIF dates, just do a:

$ jhead -ta+7:00 *.JPG
Modified: IMG_1708.JPG
Modified: IMG_1709.JPG
Modified: IMG_1710.JPG
...

This add seven hours to the EXIF stored time. Nice and easy.

8 Apr 2009

Memory usage by user

A short little script I stumbled across when cleaning my $HOME. I do not think I wrote it myself - at least I can't recall that I did. Quite handy and it's small and compact using the commands ps, awk, sort and head:

ps aux --no-headers | awk '
        {
                name[$1] += $1;
                pros[$1] += $4;
                mem[$1] += $5
        }
        END {
                for (var in name) {
                        print mem[var]" "var" "pros[var]
                }
        }' | sort -nr | head

The result is a top ten list of the users that consume the most memory:

741012 root 9.3
238152 bjorn 3.8
119380 thomasez 1.2
105332 krav 1.9
100804 lars 0.6
95916 ingvar 1.6
89720 kjetilho 1.5
78044 jo 1
74232 espen 0.8
73460 michael 0.4

There I am - at number five...

7 Apr 2009

First RFC 40 years old

The first request for comments (RFC 1) was published 40 years ago today (7. April 2009). RFCs are standard documents published by the Internet Engineering Task Force (IETF). Today over 5000 RFCs have been published by IETF. Stephen Crocker, the author of RFC1, recollect some thoughts of the early days:

http://www.nytimes.com/2009/04/07/opinion/07crocker.html

1 Feb 2009

Secure password management using CPM

There are numerous articles on the importance of creating strong secure passwords that are hard to guess and break. However, the harder the password, the harder it is to memorize. Another problem arises when we have several different passwords, usually one for each device or service. How can we store and manage the increasing number of passwords? Console Password Management (CPM), created by Harry Brueckner, does a great job for exactly that.

I worked as a system administrator for a medium sized Norwegian company. Our department was administering a large number of network devices and Unix/Linux servers. The company had two international offices each with different network security zones. This complex network topology combined with a severe strict password policy, made it impossible to memorize all different passwords.

We solved this by equipping each administrator with their own Palm with an approved secure password application. These Palms had to be manually fed, which meant in practice that they never were in sync. The authoritative password "database" was a green folder with sheets upon sheets of paper combined with post-it notes scribbled all over. In other words, it was a mess. The only up-turn was that this folder was stored in a huge fire-proof safe.

We decided to clean this up. First, we wanted an online central password database, stored as secure as possible, and running on Linux. I found dozens upon dozens of password applications. However, most of these could be placed in one of two categories (and in some cases both):

The application is designed for one user. Many of these applications are pretty usable, some even with a nice graphical user interface. A familiar example; both Firefox and Thunderbird allow you to save username and passwords. When enabling the Master password, you should, these passwords are encrypted on disk. However, these passwords are only available to the user of the application. The desktop managers GNOME and KDE both have the ability to save passwords securely.
The application is fundamentally flawed. For example, the application allows core dumps or being swapped to disk. One password application I found even stored the passwords in clear(!) text in a SQL database. Really dumb.

Fortnunately, there was one application that caught my eye. It did not fit any of these conditions above.

Console Password Management

CPM is one of those rare applications that have done many things right when it comes to secure passwords storage. At startup it checks

whether core dumps are disabled,
whether memory is locked from paging,
whether the application is protected from ptrace spying,
whether the application has environment checks enabled, and
whether it's running without root privileges.

The database of CPM is just a XML file, compressed with zlib (gzip), and encrypted with GPG. CPM is command line based, which I consider an advantage. That way I can access it through a login window or a terminal. Most of the work of a network or Linux administrator is in a shell anyway. Also, should I be stuck down in the server room and need that password, all I need to do is log in to the correct server and access CPM. Handy.

Installation

Installing CPM from source can be a little hassle unless you are familiar with compiling your own software. On Debian, you can just add CPM's apt source and install it using Debian's own package manager. You'll find instructions on CPM's homepage. Unfortunately, I did not find updated packages for Fedora/Red Hat Enterprise. I know that the developer is busy updating CPM and that a static binary is high on his priority list. A static binary would ease the installation tremendously.

Note that CPM is installed SUID root (mode 4755), meaning that CPM will be executed with root privileges regardless whether root executes the application or the user. This is necessary to enable memory locking and protection from strace/ptrace attacks. The root privilege is dropped right after memory locking.

GnuPG

Before we start using CPM, we need to have an asymmetric keypair generated by GnuPG. GnuPG is a free implementation of the commercial PGP and is included in most Linux distributions. Since CPM relies so heavily on GPG, it is imperative that you and your co-users have a grip on GnuPG. If you plan to have more than one user accessing the same CPM database, you need to create a GnuPG "web-of-trust", which basically is signing each others keys. If you are the only users of CPM, this is not necessarily.

If you don't already have a GnuPG keypair, you can create one:

$ gpg --gen-key

You'll be asked some questions, where you safely can choose the default options. Be sure to type in your name and email address when asked so. Choose a really good passphrase! This will be the only password you'll have to remember. But do remember it! If you forget this, there is no way to recover the password database.

You can now list your newly created key:

$ gpg --list-keys

Good! Lets get started using CPM.

Configuration and usage

First, we need to configure CPM. Copy /etc/cpm/cpmrc to ~/.cpmrc

$ cp /etc/cpm/cpmrc ~/.cpmrc

Open this file with the editor of your choice. In this file, you need to set the "EncryptionKey" variable. Its value would be the GnuPG email-address you typed in when you generated the GnuPG keys. So for me, that would be:

EncryptionKey "lars.strand@linpro.no"

Save and exit. Start CPM with a security test:

$ cpm --security

You should now get an output like the one in the image above. It looks like we're secure enough. The first time we start CPM, we get an error telling us that it can't find any database. That's ok, since we haven't created one yet. There is no host added, so you'll be greeted with an empty CPM as shown in the image below.

You populate the database by pressing Ctrl-A. Enter the hostname, and press enter. Selecting the host and pressing enter, enables you to add one or more services for this host. Each service can have one or more username/password pairs linked to it. Every host, service or username/password can have a comment associated with it. See the image below.

Install the password checker cracklib, and CPM also warns you if you enter a weak password. See figure:

Every entry has a timestamp indicating when it was updated and by which GnuPG key. This way, we can see which user has updated this particular entry.

Finally, save by pressing Ctrl-W. If this is the first time you run CPM, we'll be prompted for our GnuPG password. Otherwise we're asked for the password at startup - else CPM is not able to read our database. Quit by pressing ESC. The database is now saved in ~/.cpmdb in our home directory:

$ file ~/.cpmdb
/home/lars/.cpmdb: PGP armored data message

This file is just an encrypted and compressed XML-file. We can easily decrypt the content by issuing the command:

$ gpg --decrypt ~/.cpmdb | gzip -cd > cpm-decrypted.xml
$ file cpm-decrypted.xml
cpm-decrypted.xml: XML document text

CPM also provides command line search. Here I search for every entry containing "trinity:

$ cpm valhall
enter your passphrase (try #1)
Lars Strand
login root@valhall secretpassword3
1 match found.

This is quite useful when I'm in a hurry.

More than one user

If you plan to use CPM with several users, be sure that everyone has grip on GnuPG and how to proper handle their keys. You also want to store the database somewhere else. Your home directory is not a good place! Create a directory /var/lib/cpm/ and call the database cpmdb. Create a group called "cpm" and populate it with users of CPM. Then make sure the directory is (only) readable by that group. If CPM is running on a high trusted host, you've come a long way to see the security officer in your company smile.

You need to consult the GnuPG documentation on how to sign each others GnuPG keys to create a "web-of-trust".

If there is more than one user accessing CPM at the same time. Only the first user has read-write access. All other users will have read-only.

Conclusion

CPM does one thing, and it does it really well. It stores passwords securely. If you and your co-workers know how to handle GnuPG, it is way better than most other solutions out there.

This article originally appeared in Linux+DVD magazine in the January 2009 issue.

3 Dec 2008

Paint that IDS

A friend of mine, Espen Grøndahl, has created his very own IDS. To be precise, it is not a IDS per se, but a tool to visualize firewall logs. It's written in Perl and visualizes OpenBSD's pf firewall log. The IDS is called Fireplot and can be downloaded here. It is really easy to identify port scans, like this plot shows.

Two friends of Espen decided they wanted to test Fireplot, so they crafted and launched a nice "attack":

"WTF are these pictures doing in my IDS log?!?"

The original Fireplot log can be seen here:

http://espen.mine.nu/cgi-bin/fireplot3/showimg.cgi?date=2005-10-28

They even got some Star Wars in there. Quite funny.

26 Oct 2008

Google video on your phone

I have a Nokia N73 "Music Edition" mobile phone. The "Music Edition" part isn't important to me, since I never listen to music when I'm on the run. I read. But sometimes I'm too tired to read, especially when I'm on my way home from work. But the subway takes 30 minutes so I'll have to do something.

Google releases a lot of technical video documentaries ("tech talks") that I hardly ever have time to watch. TED also have lots of interesting talks. My phone do support playing video - at least 3GP. The screen resolution is not that bad either, with 240x320 pixels. It also has a 2GB miniSD memory card, so storage shouldn't be a problem. You can download most of the Google videos (for "iPod/PSP") and TED talks. What you then get is a MPEG4 file. My phone does not play MPEG4, so how can I fix that?

There is some web-services that can convert video for you. Like zamzar.com, but in Zamazars case, it has a 100MB size-limit.

Luckily, ffmpeg can convert to and from anything.

1. Install:

$ sudo aptitude install ffmpeg

2. Then, make sure the restricted codecs are installed. Follow the instruction from:

http://ubuntuguide.org/wiki/Ubuntu:Feisty#How_to_install_Multimedia_Codecs

3. Download your favorite Google/TED video.

4. Convert:

$ ffmpeg -i downloaded-google-video.mp4 -s qcif -vcodec h263 -acodec aac \
-ac 1 -ar 44100 -r 25 -ab 64 -y converted-google-video.3gp

5. Upload to your phone using bluetooth. Just one quick note: I had to configure my phone to use the miniSD for saving incoming messages. The internal storage is too small for the video file(s).

6. Play! Works great.

11 May 2008

Proper paper formatting with Latex and IEEEtran

Many scientific papers use Latex for formatting. There exists a Latex class called IEEEtran which "produce high quality typeset papers" (example here). Besides from being nice, it is also a requirement for many conferences/journals to submit papers using this class. But how do we install it on Ubuntu/Debian?

I re-installed one of my workstation with Ubuntu 8.04 here the other day. On it, I also need Latex with the IEEEtran class. To my surprise, installing it was easier than I though:

First we install the required Latex packages:

# apt-get install texlive-latex-base texlive-latex-recommended texlive-fonts-recommended texlive-pictures texlive-science texlive-science texlive-latex-extra

Now, instead of manually installing the IEEEtran class, its already available in apt:

# apt-get install texlive-publishers texlive-publishers-doc

Installed with documentation! Full read here:

$ evince /usr/share/doc/texlive-publishers-doc/latex/IEEEtran/IEEEtran_HOWTO.pdf

and

$ evince /usr/share/doc/texlive-publishers-doc/latex/IEEEtran/IEEEtran_bst_HOWTO.pdf

Now its just to install Emacs with my favorite Latex-mode:

# apt-get install emacs23 auctex emacs23-el

Ready for writing!

5 Mar 2008

Triple boot OSX Leopard, Ubuntu 8.04 and Widows Vista

I received a Mac Mini today. We plan to use it as part of our lab setup here at work. The box is pretty small and compact. It's quite cheap too.

It will primarily be running some flavor of Linux, but I plan to install Windows Vista ("Business" version) and OSX Leopard on it as well. This way I can quickly test all three OSes if needed. So how do we set up triple boot on this box? It turns out to be quite easy.

1. Installing OSX Leopard

First, install OSX. Use the whole disk. After installation is complete, do a "software update" if needed.

2. Installing Windows Vista

Next, we need to split our OSX partition in two. One for OSX, which will be resized, and another for Windows. The program "Boot Camp" does all that for us. Start it from:

"Finder" → "Applications" → "Utilities" → "Boot Camp Assistant"

Boot Camp presents us with a nice slider to resize the OSX and Windows partition. I allocate 25GB to Windows Vista:

After the resize is complete, you'll be asked to insert the Vista DVD and choose "start installation". OSX reboots and boots from the Vista DVD. The last partition is for Vista, so we format it (using NTFS).

After a couple of reboots later, Vista is installed

At startup, Vista boots as default. To change this press and hold the "Alt" key startup boot. Boot into OSX.

3. Re-partition and install rEFIt

In OSX, start "Disk utility" from "Utilities". Under "Partitions", choose the OSX partition and click the "+" button. This splits our OSX partition in two. The new partition will be our Linux partition. Don't worry about the name or format (HPFS), we'll re-create it using ext3 later.

Next, we need to download a boot-manager that manages both EFI (which Mac uses) and (old) MBR (required by Windows). Head over and download rEFIt. After you've installed rEFIt, open a "Terminal" and type (yes, still in OSX):

$ cd /efi/refit
$ ./enable.sh
+ sudo bless --folder /efi/refit --file /efi/refit/refit.efi --labelfile /efi/refit/refit.vollabel

Great! Now we have a nice graphical boot manager.

4. Installing Ubuntu 8.10

Download Ubuntu 8.04 (i386) from here and burn it to a CD. (Actually, since 8.04 isn't released yet, I'm using the alpha5-release fetched from here). Boot the installation CD from the rEFIt menu.

When installing Ubuntu, there are two important steps:

When choosing partition be sure to manually partition the disk. Then delete the third (sda3) partition. Re-create it using ext3 and set the mount point to "/". Do NOT create a swap partition. We'll create swap later.
Grub: Be sure to install grub on sda3 and NOT sda (hd0). You can change this by choosing "Advanced" under the last installation step.

At the next reboot, we're presented with a nice boot screen:

We're not quite done yet. Since Mac uses GPT, which don't allow logical partitions, and MBR, which Windows require, - we're stuck with four (primary) partitions. That's the reason why we can't have dedicated swap partition. So we create a swap file (in Ubuntu):

$ sudo dd if=/dev/zero of=/swapfile bs=1024 count=2097152
2097152+0 records in
2097152+0 records out
2147483648 bytes (2.1 GB) copied, 80.0314 s, 26.8 MB/s
$ ls -lh /swapfile
-rw-r--r-- 1 root root 2.0G 2008-03-05 18:34 /swapfile
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 2147479 kB
no label, UUID=819c205d-b3de-4ed0-ae4c-17e8b7e81443
$ sudo swapon /swapfile
$ free -m
               total       used       free     shared    buffers     cached
Mem:          1996        569       1426          0         12        196
-/+ buffers/cache:        360       1635
Swap:         2047          0       2047
$ cat /etc/fstab
...
/swapfile       swap    swap    defaults        0       0

That's it. Our partition layout now has the first (sda1) partition occupied by EFI, next (sda2) is OSX, third (sda3) Linux and the last (sda4) Vista. A graphical layout (using gparted) listed below:

16 Feb 2008

Balcony server

At my last place, I had a dedicated room full of servers. It was lovely mix of cra^Wold hardware running various flavors of Linux, BSD and Solaris. At my new place, we didn't have that much space so I was forced to do a cleanup. I bought a powerful server with sufficient RAM, CPU and disk. Now I have one server and a whole bunch of virtual machines running on it. (Throw in a couple of Linksys devices running openwrt and dd-wrt and I was happy.) There was one "problem" - the server had to be placed out on the balcony. It has been running out there for over a year now - how did that go?

When I started, I had two challenges: First, I had to build some kind of box to protect the machine from wind, rain and snow. Next, since we use the balcony a lot during summertime, the machine had to be fairly quiet.

Also, since the server is running at all time, I had to get some decent disks. I bought four "Western Digital Caviar RE2 500GB SATA2 16MB 7200RPM (WDC WD5000YS-01M)" which has a pretty high MTBF. They've been running in RAID 5 and have not failed me yet.

Since it is a sunny balcony and it can get pretty hot during the summer, the box had to have some kind of ventilation. But the ventilation could not allow snow drifting into to box during winter. After my carpenter work and a paint job, the box fit nicely into the corner of the balcony.

Neither drifting snow, wind or rain have been any problem. A bigger problem have actually been pollen grains during spring and summer. The box and chassis get full of it and have to be cleaned at least once during the summer.

I often get questions about humidity - isn't that a problem? The answer is no. I've had no problem with it at all. But keep in mind that the server is running at all time - if I turn it off, wait until it cools, and then turn it back on again, we can have condensation which can be catastrophic.

We all know that the operating temperature is really important for hard drives. So I do get a little worried when it's really hot during the summer. So I monitor the hard drives using Munin, and so far I've been within the temperature limits for the disks (5°C - 60°C).

During wintertime, the server is running happier (nice and cold) than ever: