Tag Archives: exim

Posted on
by

We all know how important it is to secure web servers with encryption. As I’ve mentioned before, port 80 HTTP should be considered deprecated at this point!

Just as important (potentially more so), but often overlooked, is to ensure that your email server is also secure.

STARTTLS is a technology that lets you start an encrypted session during a standard SMTP connection. In the same way as HTTPS secures web, STARTTLS will secure email in transit from your mail client to the server, and from server to server. This makes it much harder to passively read the traffic, and having more encrypted traffic on the internet is only ever a good thing.

This only protects email in transit from server to server of course, so this is not a replacement for end to end encryption methods like PGP, but it does complement it… and since most email is still sent insecurely, this adds extra security without requiring your users do any extra work.

It’s easy to set up (for Exim at least), and it transparently runs on port 25, so there’s no reason not to!

Generate your keys

As with web, you’ll need a server key and certificate file.

For my public mail and MX relay servers, I decided to use valid certificate authority certificates. Clients, and some relaying servers, will throw a certificate error for self signed certificates, but others will not. Better safe than sorry, and since I already had a valid certificate on my site for the server in question, I simply recycled the certificate.

If this is your internal server, you can use a certificate signed by your own certificate authority, supported by the machines in your organisation.

The default exim configuration expects to find certificates in /etc/exim4/exim.key and /etc/exim4/exim.crt.

Enable TLS

The basic STARTTLS configuration by simply editing exim4.conf.template and setting MAIN_TLS_ENABLE = yes in the tlsoptions section. Restart exim and you should have STARTTLS support enabled.

As with a web server, you can configure ciphers etc at this stage. On my server at least, the defaults seemed reasonably strong, but as we learn which ciphers have been compromised by GCHQ and the NSA, we might need to tweak these.

Test your configuration

Next, you should test your configuration.

To do this, the simplest way is to use a program called swaks, which you should find in your distro’s package library.

swaks -a -tls -q HELO -s mail.example.com -au test -ap '<>'

Should produce a result something like…

=== Trying mail.example.com:25...
=== Connected to mail.example.com.
.
.
.
 -> STARTTLS
<-  220 TLS go ahead
=== TLS started w/ cipher ECDHE-RSA-AES256-GCM-SHA384
=== TLS peer subject DN="/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.example.com"
.
.
.
 ~> QUIT
<~  221 mail.example.com closing connection
=== Connection closed with remote host.

If you get an error when starting TLS examine your exim log for the cause.

Posted on
by

exim-blue-ldFollowing on from last week’s w00tw00t block, here’s another quick fail2ban rule, this time to handle some Exim DOS/mail bombing problems.

I already use Fail2Ban to block unauthorised users who attempt to use my mail server as a relay to send spam, and this works very well. Recently, I’ve started seeing messages like this one start to appear in my exim logs:

2013-05-21 01:01:52 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)
2013-05-21 01:01:53 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)
2013-05-21 01:01:58 Connection from [2.38.90.63] refused: too many connections: 2 Time(s)
2013-05-21 01:01:59 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)
2013-05-21 01:02:00 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)
2013-05-21 01:02:11 Connection from [2.38.90.63] refused: too many connections: 1 Time(s)

In each case, the IP address originates from somewhere I’d not expect to receive email from, so it looks like some spammers are trying to mail bomb/DOS me.

In jail.local

[exim-dos]
enabled = true
filter = exim-dos
port = all
logpath = /var/log/exim*/mainlog
maxretry = 1
bantime = 3600

In filter.d/exim-dos.conf

# Fail2Ban Exim DOS configuration file.
# Checks for DOS/Flooding attempts.
#
# Author: Marcus Povey
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P[\w\-.^_]+)
# Values: TEXT
#
failregex = \[\] .*refused: too many connections

# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =

Some potential gotchas

You may notice that I’ve set the bantime to quite a low value, this is because this rule has the potential of some false positives or collateral damage in certain situations.

Most likely you’ll get the too many connections error when some naughty fellow starts mailbombing you, but sometimes connections will be refused for legitimate users while an attack is in progress, which would result in the good guys being banned as well as the bad.

Setting bantime to something relatively short (one hour in my example) should limit fallout, since legitimate email servers will retry later, while most script kiddies will have moved on.

» Visit the project on Github…

Posted on
by

I have previously written about using Git to add revision history to existing rsync backups. Having performed a number of configuration changes and system upgrades recently, I have found another use of Git which has proven invaluable.

It’s a fairly obvious hack, but it turns out that turning selected configuration directories (for example /etc/apache2/ and /etc/exim4/) into in situ Git repositories is a very handy thing to do.

The revision log you get in a Git repo gives you a very handy place to note down the reasons behind a certain configuration change. This provides a very handy historical context for a change, meaning you’re less likely to remove something odd that turns out later on to have been important.

Having configuration under version control also means that even if you do accidentally remove or change something that later causes problems you can easily roll them back.

Another handy feature is the ability to easily branch, so you can very quickly experiment with some wild configuration settings and very quickly revert them to the original working configuration should they turn out to be problematic or if you run out of time to complete them.

So, give it a try!