关于postfix的smtp认证
以下内容是对<<The Book of Postfix>> written by Ralf Hildebrandt and Patrick Koetter 的学习笔记
为什么需要SMTP验证?
对于一个邮件服务器,应该避免“open relay”的情况,也就是不能为所有的邮件客户端和其他的smtp服务器来转发邮件,所以它需要验证为哪些客户端来转发邮件。MTA提供了基于IP的验证方法,也就是说邮件服务器只转发它指定IP范围内的客户端发送的邮件。但这种基于IP验证的方式在很大的分布式网络环境中实现起来是比较困难的,特别是对于一些移动用户,因为他们使用的IP是不确定的。对于这种情况,可以有以下四种方法来解决:
在POP或者IMAP之后再SMTP,客户端在发信之前先要通过POP/IMAP服务器验证,在通过验证后,POP/IMAP服务器会把这个客户端的IP地址放在一个和SMTP服务器共享的数据库里保存一段时间,然后客户端向SMTP发信时,SMTP服务器会在这个数据库里查询。这种方法本质上还是基于IP的验证,它的缺陷在于:
设计上除了需要SMTP 的实现,还需要考虑同样复杂的POP/IMAP,而且需要二者协同才能完成验证。
它也会安全问题:因为攻击者可以利用被信任的IP在数据库里停留的时间内来发送邮件
由SMTP服务器本身完成验证,后面会具体说明
基于证书的验证(使用TLS),这种方法是最为安全的,它的问题在于一些邮件的客户端还没有支持这种方式,而且客户端和服务器的证书管理都是比较麻烦的
基于VPN的实现,这种方式主要是通过配置VPN来实现,对于SMTP服务器来说,还是原来的基于IP的验证
上面的几种方法中,由SMTP服务器本身来完成验证实现起来是最为简单的。
Postfix中SMTP认证实现的依赖
Postfix使用SASL (Simple Authentication and Security Layer)框架来实现验证,具体地说是由Cyrus-SASL实现的SASL库,Cyrus-SASL是SASL的一种实现。可以通过下面的命令来验证这件事情:
[root@localhost ~]# ldd /usr/sbin/postfix
linux-gate.so.1 => (0x00738000)
libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0x00f01000)
liblber-2.3.so.0 => /usr/lib/liblber-2.3.so.0 (0x00586000)
libpcre.so.0 => /lib/libpcre.so.0 (0x009db000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00892000)
libssl.so.6 => /lib/libssl.so.6 (0x00650000)
libcrypto.so.6 => /lib/libcrypto.so.6 (0x00b53000)
libdl.so.2 => /lib/libdl.so.2 (0x00779000)
libz.so.1 => /usr/lib/libz.so.1 (0x0019f000)
libdb-4.3.so => /lib/libdb-4.3.so (0x001b2000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00947000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00d49000)
libc.so.6 => /lib/libc.so.6 (0x002a9000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00110000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x0013e000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x003e6000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x00f44000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x004a3000)
/lib/ld-linux.so.2 (0x0052e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00169000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00a4e000)
[root@localhost ~]# rpm -qf /usr/lib/libsasl2.so.2
cyrus-sasl-lib-2.1.22-4
SASL的验证框架
SASL的验证框架大致如下:
支持SASL的服务器端(比如postfix的smtpd这个daemon)监听网络连接
客户端连接应用并发起认证过程:客户端选择一个SMTP AUTH的机制,并根据这个机制准备相应的凭证,然后把它选择的机制和相应的凭证发给服务器
服务器方保存客户端的验证机制和相应的凭证,并把它交给一个真正完成这种密码验证的后服务,比如saslauthd
验证服务根据客户的凭证和验证的后端数据(比如/etc/shadow文件)来确定是否通过验证,并把验证结果返回给smtpd
smtpd根据验证的结果做出相应的动作
SASL的验证接口
在验证的过程中服务器和客户之间需要一个验证接口来告诉客户端需要验证以及哪些验证机制是可用的。SASL本身并没有
对这个接口做出规定,而是由具体的服务和协议自己来确定这个接口。比如在ESMTP协议中,在客户端敲入EHLO时,服务器端
会提示支持的验证机制:
250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
SASL的验证机制
PLAIN
The PLAIN mechanism is the simplest to use, but it does not include any encryption of authentication credentials. You may want to use TLS (see TLS information in Chapter 13) in conjunction with the PLAIN mechanism. The login and password are passed to the mail server as a base64 encoded string.
LOGIN
The LOGIN mechanism is not an officially registered or supported mechanism. Certain older email clients were developed using LOGIN as their authentication mechanism. The SASL libraries support it in case you have to support such clients. If you need it, you must specify support for it when you compile the libraries and Postfix. See Appendix C if you are building your own Postfix. If you are using a packaged distribution and you need LOGIN support, check the documentation with your distribution to make sure it includes it. If it is used, the authentication exchange works the same as the PLAIN mechanism.
OTP
OTP is an authentication mechanism using one-time passwords (formerly S/Key). The mechanism does not provide for any encryption, but that may not be necessary since any captured password is good for only a single session. SMTP clients must be able to generate OTP authentication credentials.
DIGEST-MD5
With the DIGEST-MD5 mechanism, both the client and server share a secret password, but it's never sent over the network. The authentication exchange starts with a challenge from the server. The client uses the challenge and the secret password to generate a unique response that could be created only by somebody who has the secret password. The server uses the same two pieces, the challenge and secret password, to generate its own copy, and compares the two. Since the actual secret password is never sent across the network, it's not vulnerable to network eavesdropping.
KERBEROS
Kerberos is a network-wide authentication protocol. Unless you are already using Kerberos on your network, you probably don't need to support the KERBEROS mechanism. If you are using Kerberos, using SASL is a nice way to fit SMTP authentication into your existing infrastructure.
ANONYMOUS
SASL includes an ANONYMOUS mechanism, which might make sense for some protocols, but has no benefit for SMTP. An open relay is essentially using an anonymous mechanism, and the purpose of SMTP authentication is to eliminate open relays.
提供认证的服务
saslauthd 它是一个独立运行的daemon,它是基于系统密码来验证的,可以读取很多种后端的认证数据,包括:getpwent(/etc/passwd), kerberos,pam,rimap(remote IMAP server),shadow,ldap,其中一些是需要root权限的,而saslauthd就是以root身份来运行的,它可以帮助postfix来验证密码,因为postfix本身在设计的时候就避开了特权身份。saslauthd只支持和PLAIN和LOGIN两种验证机制。
auxprop 它提供了一种独立于系统密码的验证方法,它的含义是Auxiliary Property Plug-ins,它的作用是调用外部程序来验证,它可以读取sasldb2和sql server的验证数据,支持上面提到的各种验证机制。
简单应用
修改/usr/lib/sasl/smtpd.conf文件,告诉postfix使用saslauthd作为后台认证程序: pwcheck_method: saslauthd
修改/etc/sysconfig/saslauthd文件,使saslauthd采用shadow作为验证数据源 MECH=shadow
启动saslauthd:/etc/init.d/saslauthd start
验证saslauthd /usr/sbin/testsaslauthd -u haha -p'123456' 0: OK "Success."
编辑/etc/postfix/main.cf,增加: smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,check_relay_domains
smtpd_client_restrictions = permit_sasl_authenticated
postfix reload
完成以上设置以后,在客户端发信的时候就需要验证了。











文章评论
共有 0 位网友发表了评论 此处只显示部分留言 点击查看完整评论页面