Contents
|
Now we can setup some
rules to only allow Authenticated hosts to relay mail using SMTP Auth and TLS.
TThis is good for a couple reasons:
SSo, now that you've seen
why this is a good idea lets get down to the implementation. At this point,
we're assuming you have a working postfix installation, and are using Debian.
Don't muck with this until postfix works as you expect!
HHere is a list of the
Debian packages involved:
IInstall as necessary.
WWe need to do a little
setup for the ssl stuff. That means that we need a certificate file, its
corresponding key file, and the Certification Authority certificate file. To
make a self-signed key, just follow these easy steps:
server:/etc/ssl/certs# openssl req -new -x509 -nodes -days 365 -out /etc/postfix/postfix.pem -keyout /etc/postfix/postfix.pem
That's it! Pretty easy,
eh? Note that your common name is the name you will be entering into clients to
connect to your server, so make sure that it is not mismatched. For example, if
you put in the machine name "machine", but when you connect over the internet to
domain.com and use NAT forwarding to make the connection to "machine", the name
mismatch will make your mail client complain, every time. In that case, use "domain.com"
as your common name.
TThe first thing you need
to do open
master.cf
and add the following lines if they dont exist (they are most likely present and
commented out):
# only used by postfix-tls
tlsmgr fifo - - n 300 1 tlsmgr
smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
587 inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
That's going to tell postfix that we want to listen on port 465 for ssmtp.
Now we need to edit
/etc/postfix/main.cf
and add:
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination, permit
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/postfix/postfix.pem
smtpd_tls_key_file = /etc/postfix/postfix.pem
smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = yes
NNext, we need to set up
our authentication mechanism. There are two routes here: we can either use PAM
to query the password database on the server, or we can set up a seperate
database of username:password pairs. The first route (pam) seems much more
logical to me, as then you don't have to jump through a bunch of hoops to change
a password, but you may want to go the other way.
TTo set up SASL with PAM, first edit /etc/default/saslauthd, and uncomment lines so it looks like: o:p>
## This needs to be uncommented before saslauthd will be run automatically
START=yes
# You must specify the authentication mechanisms you wish to use.
# This defaults to "pam" for PAM support, but may also include
# "shadow" or "sasldb", like this:
# MECHANISMS="pam shadow"
MECHANISMS="pam"
Now we need to set up pam
(not sure if this is necessary, YMMV), so create/edit
/etc/pam.d/smtp
as follows:
authspan style="mso-spacerun: yes"> required pam_unix.so
account required pam_unix.so
session required pam_unix.so
The other way to go is to
setup a sasl database. This is going to store the login and password information
for our users that will be allowed to relay mail once they authenticate. Note
that this is different than what courier uses for authentication (PAM by default
I believe). The reason behind this is that we want to run postfix in a chroot
just in case it gets hacked. Now part of the chroot involves having access to
the files that store the authentication information. Now if we weren't going to
use the sasldb then we would have to copy
/etc/passwd
and
/etc/shadow into
the chroot with us, and that wouldn't do us much good now would it? So now we
need to add our user to the sasldb:
saslpasswd -c -u [your mailserver's hostname] -a smtpauth [userid]
That will ask you for a
password for the user that you are adding to the sasldb. This works just like
adding a new user anywhere and will ask for a confirmation. You can confirm that
everything is in order by doing the following:
[root@mail ssl]# sasldblistusers
user: user realm: chong.idlegames.com mech: PLAIN
user: bofh realm: chong.idlegames.com mech: PLAIN
user: user realm: chong.idlegames.com mech: CRAM-MD5
user: bofh realm: chong.idlegames.com mech: CRAM-MD5
user: user realm: chong.idlegames.com mech: DIGEST-MD5
user: bofh realm: chong.idlegames.com mech: DIGEST-MD5
That says that I have 2
users to accept relaying for and their authentication types (PLAIN, CRAM-MD5,
and DIGEST-MD5). After you have all the users you want in the sasldb then you
need to copy it to the chroot environment. Copy
/etc/sasldb
to
/var/spool/postfix/etc/
and make sure both are owned by the postfix user.
Now that we have all of
the users setup how we like it we need to tell postfix to use the sasldb. This
part is a little tricky as when I was doing it I found conflicting information
on where to put these files so I put them in both places and they worked. If
anyone can shed some light onto which location is being used it would be
appreciated. Now we need to edit
/usr/lib/sasl/smtpd.conf.
We need a single line:
[root@mail sasl]# cat /usr/lib/sasl/smtpd.conf
pwcheck_method:sasldb
This is the file where
I found conflicting information about. One piece of information said that it
goes in /usr/lib/sasl/ and the other said that it goes in /etc/postfix/sasl/. I
just put it in both places to be sure and it works so lets move on.
AAt this point, everything
should be good to go! Restart postfix, and saslauthd, and give it a try. Note
that you should be connecting on port 465 (ssmtp).
This page has much info
from pervious submitters. You may want to poke through this to try and fix
problems you encounter.
...
WeWe are almost done with the configuration. The last bit of configuration comes
with the
main.cf
file. Here is what I added to mine:
#------tls auth stuff------
#use sasl for auth
smtpd_sasl_auth_enable = yes
#turn off anon access as it provides for open relays
smtpd_sasl_security_options = noanonymous
#this corresponds to the sasldb (we put the hostname in as part of saslpasswd)
smtpd_sasl_local_domain = $myhostname
#allow busted ass clients like Outlook Express to connect
broken_sasl_auth_clients = yes
#this part allows us to relay
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
#turn on tls
smtpd_use_tls = yes
#only use tls for auth
smtpd_tls_auth_only = yes
#ssl certificate stuff that we already setup
smtpd_tls_key_file = /etc/postfix/ssl/postfix.key
smtpd_tls_cert_file = /etc/postfix/ssl/postfix.crt
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.crt
#logging stuff
smtpd_tls_loglevel = 3
#other needed stuff
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
Ok that should be it for
configuration. Restart postfix and lets test it out. We're going to use telnet
and smtp lingo to talk to the server. First thing is to encode your
login/password so that it can be sent to the server. This is in plain text on
your terminal window so just make sure no one is looking over your shoulder or
something. This will be the login and password that you used when you did
saslpasswd. Here's how we encode it:
[user@mail ~]$ printf "\0%s\0%s" username password | base64-encode ; echo KDFwi65dADd8bmCgktbz
Since all of this stuff
will be encrypted we are going to need to test this using something that can
speak crypto for us. OpenSSL provides for this:
[user@remote ~]$ openssl s_client -starttls smtp -crlf -connect mail.example.com:2525
Since my ISP blocks
outgoing SMTP, my server redirects port 2525 to 25 via iptables. You would want
to try on port 25 first. Here is the output from the session:
The following is a
formatting problem that I would like to be fixed. A lot of this stuff needs to
be in the CA section instead of here.span>
CONNECTED(00000003)
dedepth=1 /C=US/ST=Michigan/L=Flint/O=chong.idlegames.com/OU=Certificate Authority/CN=Mentat CA/emailAddress=admin@chong.idlegames.com
verify error:num=19:self signed certificate in certificate chain
verify return:0:p>
---
Certificate chain
0 0 s:/C=US/ST=Michigan/L=Flint/O=chong.idlegames.com/OU=Secure IMAP/CN=chong.idlegames.com/emailAddress=admin@chong.idlegames.com
i:/C=US/ST=Michigan/L=Flint/O=chong.idlegames.com/OU=Certificate Authority/CN=Mentat CA/emailAddress=admin@chong.idlegames.com
1 s:/C=US/ST=Michigan/L=Flint/O=chong.idlegames.com/OU=Certificate Authority/CN=Mentat CA/emailAddress=admin@chong.idlegames.com
i:/C=US/ST=Michigan/L=Flint/O=chong.idlegames.com/OU=Certificate Authority/CN=Mentat CA/emailAddress=admin@chong.idlegames.com
---:p>
Server certificate
-----BEGIN CERTIFICATE-----
MIIECjCCA3OgAwIBAgIBAjANBgkqhkiG9w0BAQQFADCBrDELMAkGA1UEBhMCVVMx
ETAPBgNVBAgTCE1pY2hpZ2FuMQ4wDAYDVQQHEwVGbGludDEcMBoGA1UEChMTY2hv
bmcuaWRsZWdhbWVzLmNvbTEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRIwEAYDVQQDEwlNZW50YXQgQ0ExKDAmBgkqhkiG9w0BCQEWGWFkbWluQGNob25n
LmlkbGVnYW1lcy5jb20wHhcNMDMxMTE2MDEzMTIxWhcNMDQxMTE1MDEzMTIxWjCB
rDELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1pY2hpZ2FuMQ4wDAYDVQQHEwVGbGlu
dDEcMBoGA1UEChMTY2hvbmcuaWRsZWdhbWVzLmNvbTEUMBIGA1UECxMLU2VjdXJl
IElNQVAxHDAaBgNVBAMTE2Nob25nLmlkbGVnYW1lcy5jb20xKDAmBgkqhkiG9w0B
CQEWGWFkbWluQGNob25nLmlkbGVnYW1lcy5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAK5LhzP9oefHPNqDZgb2NmpFmmYFjJTgF5FqOOxnr4uQ8r2XKG2m
E3AjTqcr8O P7n/pwGZRjxM6vXE8R6Th7C6OR5Oz8iKMjmSOaHPjM6g/ziZUNe3A
L940prH4OrdvVfgZoUxHwNjWg1zUf8JzNrtXF1MTyePGCRQrcr0yVWH7AgMBAAGj
ggE4MIIBNDAJBgNVHRMEAjAAMCwGCWCGSAGG EIBDQQfFh1PcGVuU1NMIEdlbmVy
YXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUrKVZEL e2c5ulytemsBt5RJJZJkw
gdkGA1UdIwSB0TCBzoAUkVT18NQ1twCP8hhYH3vAubx2AyqhgbKkga8wgawxCzAJ
BgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjEOMAwGA1UEBxMFRmxpbnQxHDAa
BgNVBAoTE2Nob25nLmlkbGVnYW1lcy5jb20xHjAcBgNVBAsTFUNlcnRpZmljYXRl
IEF1dGhvcml0eTESMBAGA1UEAxMJTWVudGF0IENBMSgwJgYJKoZIhvcNAQkBFhlh
ZG1pbkBjaG9uZy5pZGxlZ2FtZXMuY29tggEAMA0GCSqGSIb3DQEBBAUAA4GBADoM
4wk/snws2 HqzRPHRZ6n82DkttywKBeebgQCD cl2vXxudyJs2FjO41gtBcpBvgl
8f8fP37zYY0SN5Me/Hx3AUZqPsxWf1jKbqHrk2vu/HOH/mRnhdOrlOeVzCYtROvEeA
Fkw fHYvOKAj1lbBZ4iWgsW5ghcTVEUZS3tlNeDd
-----END CERTIFICATE-----
subject=/C=US/ST=Michigan/L=Flint/O=chong.idlegames.com/OU=Secure IMAP/CN=chong.idlegames.com/emailAddress=admin@chong.idlegames.com
issuer=/C=US/ST=Michigan/L=Flint/O=chong.idlegames.com/OU=Certificate Authority/CN=Mentat CA/emailAddress=admin@chong.idlegames.com
---:p>
No client certificate CA names sent
---
SSL handshake has read 2592 bytes and written 332 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : EDH-RSA-DES-CBC3-SHA
Session-ID: 40AD8DAAC2108E3E805179D48125816CCD1818F66B443B5D47ED8AC023E1A5CC
Session-ID-ctx:
Master-Key: 284B4D5B8DEE30EB6AAFB46459E2AE8612B255A158CB807CC5656F2D8B480516B0F5875933034E4C02352FDFBBD7FAED
Key-Arg : None
Start Time: 1087439536
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
220 chong.idlegames.com ESMTP Postfix (Debian/GNU)
ehlo chong.idlegames.com
250-chong.idlegames.com:p>
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH DIGEST-MD5 LOGIN PLAIN CRAM-MD5
250-AUTH=DIGEST-MD5 LOGIN PLAIN CRAM-MD5
250-XVERP
250 8BITMIME
auth plain KDFwi65dADd8bmCgktbz
23235 Authentication successful
mail from:< chong@chong.idlegames.com >
250 Ok:p>
rcpt to:< pie31337@yahoo.com >
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
To: pie31337@yahoo.com
FrFrom: chong@chong.idlegames.com
Subject: Testing relaying with tls
Ok so we are trying to see if we can relay using tls authentication.
Since we've gotten this far it looks like its working.:p>
.
250 Ok: queued as EC1F34806C
quit
22221 Bye
read:errno=0
250-chong.idlegames.com:p>
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH DIGEST-MD5 LOGIN PLAIN CRAM-MD5
250-AUTH=DIGEST-MD5 LOGIN PLAIN CRAM-MD5
250-XVERP
250 8BITMIME
&n mail from:< chong@chong.idlegames.com >
250 Ok:p>
rcpt to:< pie31337@yahoo.com >
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
To: pie31337@yahoo.com
FrFrom: chong@chong.idlegames.com
Subject: Testing relaying with tls
Ok so we are trying to see if we can relay using tls authentication.
Since we've gotten this far it looks like its working.:p>
.
250 Ok: queued as EC1F34806C
quit
221 Bye
read:errno=0
Ok lets break this down.
First off we have a lot of stuff before we even see the banner from postfix.
This is all of the OpenSSL handshaking and whatnot. It basically means that our
conversation with the server is being encrypted (that's good). After all that
crypto stuff we get the server banner message:
220 chong.idlegames.com ESMTP Postfix (Debian/GNU)
We initiate a
conversation:
ehlo chong.idlegames.com
It tells us some more
stuff about it:
--
Note the lines starting
with "250-AUTH". The first one tells us that our server is capable of doing smtp
auth. The second one tells broken clients (Outlook Express) the same thing. Now
we need to log in:
auth plain KDFwi65dADd8bmCgktbz
If it works we'll see
this:
235 Authentication successful
Now let's try and relay
some email (this has client and server messages combined since we are pretty
much done):
--
Ok now the only thing
thats left is to check the account that you put in the "rcpt to" line. If it
shows up there then we are good to go. If it doesn't then check your logs and
try and figure out what went wrong, or post them on the [http://episteme.arstechnica.com/eve/ubb.x?a=frm
<
Retrieved from "Mail Server FAQ/TLS and Postfix"