Since spying on citizens’ daily communication has shifted from being a rumour for paranoids to being a proven fact, some people think a lot harder about what they can do to preserve their privacy. With E-Mail still being the number one form of communication at the internet, this is one of the most obvious starting points. Due to the nature of the SMTP protocol, spying cannot be shut-down completely, even with content encryption. However, one aspect that can be worked on, is mail storage. Spying on each mail transferred via SMTP is quite expensive for an attacker while just fetching information from a multi-GB mailbox with years worth of social links and information is very cheap.
When relying on secure physical storage, most hosted mail services are not acceptable. They either make money from user data, closely work together with intelligence agencies, cannot provide an acceptable privacy policy - or simply are too expensive for personal usage. A possible solution is to use a local “at home” mail storage. Sadly, just putting some machine as a IMAP/SMTP host to a residential internet line means a couple of drawbacks. For one, most consumer internet connections will use dynamic IP addresses and force regular reconnections/assignments. Second, most telcos don’t offer proper reverse-resolution of the IP, many SMTP hosts use that to identify spammers as well as blocking whole IP ranges which are known for consumer internet connections.
Dynamic IP addressing could be worked around by using popular DynDNS services. However, a DNS MX entry must not be a CNAME but a “real” address. Some mail providers (e.g. GMX) check for this and deny taking mail from such hosts. The issue regarding reverse-resolution can be tackled by buying some mail re-direction services (e.g. dnsexit, dnsmadeeasy) that will relay your mail, but will set you back at least $25 a year with limited confidence to the “privacy” concern and limitations to mail throughput/features.
For me, the best solution has been using a small virtual server (VPS) as a SMTP relay. This gives full control on mail services, features and security. At home, i use a Synology DS214 for IMAP storage and SMTP submission. This box sends all mail to my VPS which then relays that mail to the destination recipient. The other way around it works the same way: incoming mail for my domain is relayed to the DS214 at home. The VPS costs me about €3 a month and of course allows more than just relaying mail. I’d like to share the configuration details with you.
Network hosts
client The clients mail application uses “ds214.example.com” as IMAP and SMTP server.
ds214.example.com This host is located at home and uses a residential ADSL line. It uses a dynamic DNS service to update its dynamic IP for “ds214.example.com”. Ports 25 and 993 are forwarded by the ADSL router to allow access by the client and the mail relay (vps.example.com).
vps.example.com This host does the mail relaying. It is added as DNS MX entry for “example.com”, it’s static IP address reversely resolves to example.com
mx.otherhost.com Other mail providers hosts just communicate with “vps.example.com”, not knowing anything about it’s relay functionality.
DS214 configuration
This is Synology specific, but may easily be achieved with other MTAs as well.
Postfix configuration
The MTA is running Postfix and Postgrey at vps.example.com is configured like this:
Relay domains and target hosts are configured at /etc/postfix/transport. In this case, all mail to “example.com” is relayed to ds214.example.com.
1
example.com smtp:[ds214.example.com]
Valid recipients for this domain are configured at /etc/postfix/recipients. In this case, only mail to any “example.com” address is allowed to get relayed.
1
@example.com OK
Make sure these files are converted to a binary format. relayed.
When relaying outgoing mail (from ds214.example.com), SMTP authentication is used to make sure no unprivileged users use this server as mail relay. In this case, i’ve used saslauthd for authentication. Postfix is advised to use saslauthd and accept “PLAIN” password authentication at /etc/postfix/sasl/smtpd.conf.
1 2
pwcheck_method: saslauthd mech_list: PLAIN LOGIN
Restart Postfix after applying this configuration
1
service postfix restart
saslauthd also needs to be configured to accept PLAIN authentication. As the user/pass database, sasldb should be used. This can be done at /etc/default/saslauthd:
Restart saslauthd and make sure the path specified with the -m option can be accessed. This is required since Postfix is supposed to run in a “chroot” environment.
1 2
service saslauthd restart dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd
Now we create a user within sasldb which is used to authenticate a client which is relaying mail through this MTA.
1
saslpasswd2 -u example.com -a smtpauth mailrelay
Make sure the user “mailrelay” and the given password is used at the SMTP client, which is ds214.example.com in this case.
At work, we run a lot of automated integration, unit and system tests. This requires virtual machines that can be started up, get deployed with the software we want to test, run tests against it, shut it down and reset to a non-tainted state for the next test. While we’re working on a OpenStack based solution for that kind of internal deployment, i’ve had the joy of working with a, by all means, legacy Xen paravirtual hypervisor setup. It basically runs on a old machine with old debian and old XEN. The XEN guests (aka. domU’s) are stored within LVM on an old storage system.
The requirement in my case is, that all partitions exist as raw LVs without a partition table, so i can continue using existing tools for backup/restore. Sadly virt-install does not allow that (from what i found out at least) so i needed quite a workaround. To start with, i used virt-install to install the domain to a temporary image file.
Hint: virt-install requires a valid locale, just in case there is none set:
1
$ export LC_ALL=C
When installing, i’m not using a separate /boot or SWAP partition, just for the sake of ease. However, the provided steps may be used for more complex partition setups as well. When installing, do NOT create a LVM based storage setup within the VM.
In this case, i’m going to use Debian Wheezy, but when following some tricks, it’s possible to install every Linux Distro using this workflow. See “Other Distros” for more details. Since the old hardware does not support Hardware-assisted virtualization (HVM) either provided by AMD-V or Intel VT-x, i’ve to stick with “paravirt”.
Virt-install may print some error output, however in most cases it still succeeds. Just jump into the domU. For SLES, please see the “Other Distros” section.
1
$ xm console debian7-install
Observe the image partition table, sector size and starting block of a partition
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
$ fdisk -lu debian7-install.img You must set cylinders You can do this from the extra functions menu. Disk debian7-install.img: 0 MB, 0 bytes 181 heads, 40 sectors/track, 0 cylinders, total 0 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000b3bee
Device Boot Start End Blocks Id System debian7-install.img * 2048 10483711 5240832 83 Linux Partition 1 has different physical/logical beginnings (non-Linux?): phys=(0, 32, 33) logical=(0, 51, 9) Partition 1 has different physical/logical endings: phys=(652, 180, 40) logical=(1448, 55, 40)
In this case, the sector size is 512b and the primary (only) partition starts at block 2048.
Now mount the image file to a loop device, starting at the offset calculated based on sector size and start block.
The image has been successfully restored to LVM, so the hard work is done. Next, some modifications within the image need to be performed, to make the system bootable.
For that, just mount the LV to an arbitrary mount point.
1 2
$ mkdir /mnt/debian7-install $ mount /dev/vg/debian7-install-disk /mnt/debian7-install/
XEN will use pygrub to boot the machine. Pygrub only understands the menu.lst style GRUB configuration files, not the more recent grub.cfg files. Therefor we have to create a new menu.lst file based on the new partition settings. The UUID value for the / disk is used here.
1 2 3 4 5 6 7 8 9 10 11 12 13
$ vim /mnt/debian7-install/boot/grub/menu.lst default 0 timeout 2
Note that the default text-mode CentOS installer is somewhat limited. It does not allow to modify the partition table, for example not using LVM but just a plain partition. If that’s the case for you, use the VNC (launched from the text-mode installer) or virt-viewer to launch the more sophisticated (GTK’ish) installer of CentOS. This will allow you to work around LVM.
RHEL6
For this, you need the binary DVD images of RHEL6 and make them accessible via HTTP (aka. create your own installation mirror). Therefor, you require a HTTP server and need to mount it to a directory which gets served:
1
$ mount -o loop /root/rhel-server-6.4-x86_64-dvd.iso /var/www/rhel/
Then, use virt-install to start the installation process from this HTTP site:
Note that the default text-mode RHEL6 installer is somewhat limited. It does not allow to modify the partition table, for example not using LVM but just a plain partition. If that’s the case for you, use the VNC (launched from the text-mode installer) or virt-viewer to launch the more sophisticated (GTK’ish) installer of RHEL6. This will allow you to work around LVM.
When booting, this errors tend to show up, however they won’t keep the domU from booting
1 2 3 4
PCI: Fatal: No config space access function found Could not set up I/O space Could not set up I/O space Could not set up I/O space
SLES11
For SLES, the process is similar to the one used at RHEL, but enhanced by the pitfall of SLES requiring some kind of “real” graphical interface rather than just a XEN console. In my case i had no X running at the XEN dom0, so i had to improvise quite a bit.
xm console just stopped responding at:
1 2 3 4 5 6
[ 9.479067] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 9.479084] EDD information not available. [ 9.646300] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 9.646317] EDD information not available. [ 9.813624] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 9.813641] EDD information not available.
For this, you need the binary DVD images of SLES11 and make them accessible via HTTP (aka. create your own installation mirror). Therefor, you require a HTTP server and need to mount it to a directory which gets served:
1
$ mount -o loop SLES-11-SP3-DVD-x86_64-GM-DVD1.iso /var/www/sles/
Then, use virt-install to start the installation process from this HTTP site:
Now the fun part starts. Usually there is a VNC console available from virt-install. This did not work for me when using a “real” remote VNC client. However, using “virt-viewer” did the trick. To use any kind of VNC, i’ve added the “vnc” parameter to the virt-install command.
Right after executing virt-install, call virt-viewer to jump into the installation process. In my case, i had to use a client computer running X, install xserver-xorg, xauth at the dom0 to run “virt-viewer”:
1
$ apt-get install xauth xserver-xorg
Check that SSHd on dom0 allows X forwards:
1 2 3 4 5
$ vim /etc/ssh/sshd_config [...] X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost no
Connect to the dom0 machine from a client using X and enable forwarding:
When installing SLES, make sure to install the bootloader to MBR (the default is the “root” partition!) and select the option to install within a paravirtualizied environment. After installation, you’ll also need vnc to boot the machine since SLES uses an awkward “graphical” boot console. You can do that by adding this to your domU config file:
1
vfb = [ 'type=vnc' ]
Later on, modify the /boot/grub/menu.lst file and set