Month: March 2017

So, I have an old installation of Debian, with postfix, and I don’t remember how I set it up. I should check that it is using sane settings and really using encryption for the transport of mails. This is on my Debian Jessie 8.7 server.
First, I wanted to see what version of postfix I am using.
Issuing postcond -d | grep mail_version yields the version 2.11.3..
So, according to the answers in this question, I should use the newer configuration options smtp_tls_security_level.
In the configuration that existed on the server, I didn’t have anything about smtp, only for smtpd (incoming mail). From logs obtained when running smtp with the options -v -v (Change the settings in /etc/postfix/master.cf and restart postfix):
Mar 2 16:30:17 galerkin postfix/smtp[15196]: > mail.tele2.se[212.247.156.1]:587: EHLO galerkin.hestben.dyndns-ip.com
Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-mailfe09.swip.net host name is unknown galerkin.hestben.dyndns-ip.com Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-DSN Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-SIZE 314572800 Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-STARTTLS Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-AUTH LOGIN PLAIN Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-ETRN Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-TURN Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-ATRN Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-NO-SOLICITING Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-8BITMIME Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-HELP Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250-PIPELINING Mar 2 16:30:17 galerkin postfix/smtp[15196]: < mail.tele2.se[212.247.156.1]:587: 250 EHLO
Then, it looks like it creates a TCP buffer with the login credentials, and then issues AUTH LOGIN:
Mar 2 16:30:17 galerkin postfix/smtp[15196]: smtp_sasl_authenticate: mail.tele2.se[212.247.156.1]:587: SASL mechanisms LOGIN PLAIN
Mar 2 16:30:17 galerkin postfix/smtp[15196]: > mail.tele2.se[212.247.156.1]:587: AUTH LOGIN
I.e. no encryption used, so I added smtp_tls_security_level=may to main.cf (you can also use postconf -e "smtp_tls_security_level=may")
Then reloaded postfix with
postfix reload
You can then verify that the setting is set with
postconf | grep smtp_tls_security_level.
Now the mail.log looks like:
Mar 3 15:11:41 galerkin postfix/pickup[22696]: 98D91232032: uid=0 from=
Mar 3 15:11:41 galerkin postfix/cleanup[22702]: 98D91232032: message-id=<20170303141141.98D91232032@galerkin.hestben.dyndns-ip.com>
Mar 3 15:11:41 galerkin postfix/qmgr[22697]: 98D91232032: from=, size=359, nrcpt=1 (queue active)
Mar 3 15:11:42 galerkin postfix/smtp[22704]: Untrusted TLS connection established to mail.tele2.se[212.247.156.1]:587: TLSv1 with cipher AES256-SHA (256/256 bits)
Mar 3 15:11:43 galerkin postfix/smtp[22704]: 98D91232032: to=, relay=mail.tele2.se[212.247.156.1]:587, delay=2.2, delays=0.31/0.3/0.5/1.1, dsn=2.0.0, status=sent (250 549908680 mailfe03 Message accepted for delivery)
Mar 3 15:11:43 galerkin postfix/qmgr[22697]: 98D91232032: removed
So, now you could hope tele2 would change to a better cipher with perfect forward secrecy (such as ECDHE-RSA-AES256-GCM-SHA384). Reading through the reference below about postfix forward secrecy, it also looks like the server does not support anonymous cipher suites =(.

Now, check incoming mail. The setting for the incoming mail which is called smtpd_tls_security_level. I had previously used smtpd_use_tls=yes so I changed to the newer setting. I sent a mail to my server (there is only a dyndns-ip configured for it, I use an external email provider for my hestben.se-domain).
The log from that looks like this:
Mar 3 15:29:33 galerkin postfix/smtpd[22788]: connect from mx.kolabnow.com[95.128.36.1]
Mar 3 15:29:33 galerkin postfix/smtpd[22788]: Anonymous TLS connection established from mx.kolabnow.com[95.128.36.1]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Mar 3 15:29:33 galerkin postfix/smtpd[22788]: A0EC523202F: client=mx.kolabnow.com[95.128.36.1]
Mar 3 15:29:33 galerkin postfix/cleanup[22793]: A0EC523202F: message-id=<20170303142924.GB4898@debian.hestben.dyndns-ip.com>
Super, it is even using a good cipher.

References : postfix forward secrecy, postfix tls readme, postfix main.cf format.

So, recently, I have been reviewing my systems, to harden them against attack. When I look back at it, I really think I have had quite naive in what security measures I employ.
One thing I have started doing, is have logwatch send a mail to my mail address every day. That way, I am more forced to look into what is happening with the servers each day. This information could be interesting to an attacker, though, so it is important to secure that information. In part, I have been looking into if my MUA uses TLS to send the mail to the outgoing mail server (I will cover this in a different post). Then, you should ensure that connection is secure when downloading and viewing the mail is secure as well (also covered in a different post).
But, in the end, you don’t know how the outgoing mail server sends the mail to the receiving server. Best is then to encrypt the mail. I did some duckduckgoing (the duckduckgo.com equivalent of googling) and found this post:GnuPG-encrypted mail forwarding

Using the steps from that post, I first imported my public gpg-key for the root user with
gpg --import <path/to/public/key>
gpg --edit-key <The key>
And trust the imported key ultimately (gpg will complain otherwise, and you don’t have any way to handle that interaction in an automated script). Thus, in the gpg-promt do:
trust
5
And lastly, quit
quit

Then, I created the mailgate user with
adduser mailgate

On one of my systems, I use Maildir format instead of mbox-format, so I was changing my script to handle this. One con with the script in that post above, is that the mail is not a Content-Type: multipart/encrypted;, instead, the body of the mail, is an encrypted text, that you manually need to decrypt with gpg.

I asked around on the channels #gnupg and #mutt (you can use mutt to send an encrypted mail, that has the correct format, but piping the message into mutt didn’t make it a Content-Type: multipart/encrypted; mail) on freenode, and was tipped by dtw in #gnupg about mime-construct (example usage)

So, I ended up with a script looking like this (beware that wordpress line breaks badly):

#!/bin/bash
#backup this script to /home/robert/scripts
rsync /root/scripts/relay_mailgate_mail_encrypted /home/robert/scripts/
chown robert:robert /home/robert/scripts/relay_mailgate_mail_encrypted
MAILGATE_NEW_MAIL_DIR=/home/mailgate/Maildir/new
MAILGATE_CUR_MAIL_DIR=/home/mailgate/Maildir/cur
if [ ! -z "$(ls -A $MAILGATE_NEW_MAIL_DIR)" ]
then
BACKUP_DIR=/home/mailgate/mailbackup/`date +%y%m%d-%H%M`
mkdir $BACKUP_DIR
echo $BACKUP_DIR
rsync -a $MAILGATE_NEW_MAIL_DIR $BACKUP_DIR
for mail in $MAILGATE_NEW_MAIL_DIR/*
do
echo $mail
cat $mail | mime-construct --subpart \
--type 'text/plain; charset=UTF-8' \
--encoding quoted-printable \
--file - \
| gpg --batch --yes \
--armor --textmode --openpgp \
--recipient "mailaddr@domain.com" \
--encrypt \
| mime-construct --output \
--header "From: root" \
--to "mailaddr@domain.com" \
--subject "Relayed mail" \
--header "Date: $(date --rfc-2822)" \
--multipart 'multipart/encrypted; protocol="application/pgp-encrypted"' \
--type application/pgp-encrypted \
--encoding 7bit \
--string $'Version: 1\n' \
--type application/octet-stream \
--file - | sendmail -i mailaddr@domain.com
mv $mail $MAILGATE_CUR_MAIL_DIR
done
fi
I called this script in a script in /etc/cron.hourly/00mailencrypt.
Lastly, I edited the /etc/cron.daily/00logwatch and /etc/apt/apt.conf.d/50unattended-upgrades scripts to mail to mailgate@localhost instead of to an external address directly.