Wednesday, 30 December 2009

Getting Debian to email with exim4 and Google Mail

There are may reasons why would might like to run a headless Debian server on your home network. I have mine primarily as as file-store, serving video, music and pictures to my Windows MCE PC (you see I'm not one of these Windows hating Linux nerds, use the right tool for the right job I say!).

Being headless and tucked away in a dark corner it's important to be able to manage the system with little fuss, and I use ssh to login and administer the system remotely. The question here though is 'When do I know that I need login and do something?'. I ideally want to know asap if there are some important security updates (apticron), or that the raid (mdadm) has run into some trouble or if some important cron job has spewed some helpful output.

Lucky for me is was fairly straightforward to configure the server to email my google mail (gmail) account whenever it has something important to say, and here's how I did it! I have this working on both Lenny and Squeeze.

First off your server is going to need a gmail account; now it could use your own but I would rather not have my personal account details lingering around on my server (even if they are secured properly). I actually use my own domain with Google Apps, but this should work just as well with any old gmail account.

Now that you have an account you will need a Mail Transport Agent (MTA). You probably already have exim4 installed for this as it's a requirement for many packages. Check this and if not install it, something similar to the following should do the trick;
# apt-get install exim4-daemon-light

Now we'll generate the base of our configuration using dpkg-reconfigure;
# dpkg-reconfigure  exim4-config

This will launch you into a series of question, the answers to which are;
General type of mail configuration: mail sent by smarthost; no local mail
System mail name: [hostname].[domain]
IP-addresses to listen on for incoming SMTP connections:  127.0.0.1
Other destinations for which mail is accepted: [left blank]
Visible domain name for local users: [hostname].[domain]
IP address or host name of the outgoing smarthost: smtp.gmail.com::587
Keep number of DNS-queries minimal (Dial-on-Demand)? No
Split configuration into small files? yes 

This setup ensures that the server will be able to send mail, but will not receive or relay mail. Pay attention to the double :: separating out the host (smtp.gmail.com) and port (587) for the smarthost.

This will have populated our basic configuration which is contained in /etc/exim4/update-exim4.conf.conf which should now resemble;
# Some Debian help-text at the top here, omitted to save space

dc_eximconfig_configtype='satellite'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1'
dc_readhost='gabbro.mrverrall.co.uk'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='smtp.gmail.com::587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

Next up is the authentication details which are contained in /etc/exim4/passwd.client. Following the example provided by Debian in the file two lines are required. This is because smtp.gmail.com does not always resolve to the same hostname, hence configure the auth details in the following fashion, where your login is the full email address for the account;
# Example:
### target.mail.server.example:login:password

*.google.com:login:password
*.gmail.com:login:password

As this file contains some sensitive account details we should give it appropriate permissions;
$ chmod 0640 /etc/exim4/passwd.client

To ensure we get all the mail we're after, and to save us having to configure every daemon with our email address, the next step is to configure some aliases. using your favorite editor, open; /etc/aliases. You'll see a list of system users which are all mapped to 'root'. Now add an alias for root, pointing to your username and one for your username pointing to your email address. Here is an example;
# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: myusername
myusername: myaccount@gmail.com

Now we'll get all the emails we're after! Now to test that what we have done actually works, the easiest way is to send an email to root from your user account like this;
$ mail root

Set a subject and some body text (end the email with a single . on its own line) and go check your exim logs...
# tail -f /var/log/exim4/mainlog

With any luck you should see something like;
2009-12-30 16:40:15 1NQ1ap-0001rN-Pj <= root@host.domain U=root P=local S=384 2009-12-30 16:40:17 1NQ1ap-0001rN-Pj => myaccount@gmail.com  R=smarthost T=remote_smtp_smarthost H=gmail-smtp-msa.l.google.com [74.125.77.109] X=TLS1.0:RSA_ARCFOUR_MD5:16 DN="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com"
2009-12-30 16:40:17 1NQ1ap-0001rN-Pj Completed

If not, one of us has made a mistake and I suggest you go look at the following websites:

Wednesday, 23 December 2009

USB Flash Drive Encryption

Securing data on a USB pendrive can allow you to carry around useful, yet sensitive data with very few concerns. This post outlines a way of cryptographically securing a USB pendrive using crypsetup and LUKS in such a way that a drive may be unlocked on most Linux system without the addition of extra software (e.g. TruCrypt). As an added bonus it's possible to mount the drive in a Windows environment as well. Hurrah!

The first thing to decide is how you are going to partition your drive. I find it useful to have an unencrypted partition as well as the encrypted as this affords the convenience and functionality as well as offering security. The primary consideration here is that natively Widows will only recognise the first partition on the pendrive, so if you wish to have an open data partition let it be the first.

Below shows how an 8GB pendrive (in this case the device is /dev/sdh) is split roughly is half with an ~4GB FAT32 partition at the front. Use you favorite partitioning program to achieve your desired affect.
Disk /dev/sdh: 8086 MB, 8086618112 bytes
249 heads, 62 sectors/track, 1023 cylinders
Units = cylinders of 15438 * 512 = 7904256 bytes
Disk identifier: 0x6f20736b

   Device Boot   Start    End     Blocks   Id  System
/dev/sdh1   *        1    518    3998411    c  W95 FAT32 (LBA)
/dev/sdh2          519   1023    3898095    c  W95 FAT32 (LBA)

So from now on we're working with /dev/sdh2 for our encrypted partition. using cryptsetup we can now setup the encryptedness:

# cryptsetup luksFormat /dev/sdh2

Now you'll be prompted for a passphrase. Be sure to choose something nice and long here as this will be all that's protecting your data (try running 'pwgen 20' if you are having trouble thinking of one).
WARNING!
========
This will overwrite data on /dev/sdh2 irrevocably. 
Are you sure? 
(Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

Now we can open the encrypted drive and map as a device:

# cryptsetup luksOpen /dev/sdh2 usb_crypt

The 'usb_crypt' in the above command will become the name of your device in /dev/mapper and can be anything you like it to be. Here you'll be prompted for the password we set above.

Next the drive will need a file system on it, here I've opted for a FAT32, but this could be whatever you prefer.

# mkfs.vfat /dev/mapper/usb_crypt

And all that's left to do is mount it!

# mount -t vfat /dev/mapper/usb-crypt /mnt

If you are using a friendly distribution like Ubuntu you should now be able to eject your drive the same way you would any other USB pendrive. The OS should also detect the encrypted partition on insertion, prompting you for the password. If however you are in a position where you need/prefer to do things the manual way you will need to close the encrypted volume manually before ejecting the drive, unsurprisingly this is done as follows:

# cryptsetup luksClose /dev/sdh2 usb_crypt

You may now open and mount your partition as above whenever it's required in future using the methods above.

If you wish to be able to mount your encrypted partition under a windows OS you will need to take a look at FreeOTFE. At this time I have not tried it yet; updates to come.

Inspiration for this post was drawn from
ww.debian-administration.org
www.saout.de/tikiwiki/
www.freeotfe.org