Browsed by
Tag: tls

Postfix / Dovecot 配置的一些修改

Postfix / Dovecot 配置的一些修改

email 大概是自互联网洪荒时代就留存下来的技术,有着厚重的历史沉淀,回味且让人困惑。互联网技术往往粗糙、简陋,像有点漏水的瓶,能用,但就是哪哪总有点不对。而 email 更像是漏水的镶金大瓦罐,更漏水、更实用、更异域风情。相比其他互联网服务,例如web,配置 email 总是让人战战兢兢,需要理解极为繁琐的概念、在不同的配置文件左右横跳,然而过了一段时间后,你会发现,原来配置还没完,还有地方能优化,超有精雕细琢的样子。

最近我就雕琢了一下。

事情其实和我们的 email 本身没有关系,和 IPv6 的地址范围有关。数据中心服务商给我们提供了一个比较大范围的 IPv6 地址群,然而不幸的是其他一些用户也在这个地址群内。我们通过自己的 IPv6 地址发送 email 时,由于反垃圾机构已经将这个地址群拉黑了,导致我们的 email 无法送达到客户。这是典型的「殃及池鱼」,我们进行了申诉(拉黑一个大范围的 IPv6 地址群显然过于粗暴、完全不合理),并向数据中心反馈情况(希望能查查是谁在发垃圾邮件)。反垃圾邮件机构不理会我们(有了SPF、DKIM等技术都不能让它们更精确、更理智点),而数据中心只是表示可以将我们划到另一个小点的 IPv6 地址群……

互联网就是这么荡气回肠,到处漏水,到处打补丁,到处都是草台班子。

我们回头重新思考,将 email 系统限制在 IPv4 地址显然是个简单有效的解决方案。IPv4 的主要缺点是地址太少,但在这个问题上反而是优点,估计没有哪家反垃圾邮件机构会疯到拉黑一大段 IPv4 地址。

方案有了,改起来倒是不太复杂。第一步修改 DNS 的 MX 记录绑定 IPv4 地址。进 DNS 服务商的面板里改改就可以。

第二步修改 Postfix 以及 Dovecot 的配置。Postfix 管理邮件的发送和接收,而 Dovecot 管理个人的邮箱,大致功能就是这样,它们共同组成整个 email 系统。

(1)修改 Dovecot

可以直接修改 /etc/dovecot/dovecot.conf 文件,但这样不太好, 如果将来系统升级,可能还要注意保留配置不被覆盖,因此建议将自己的配置存放在 /etc/dovecot/conf.d/ 目录下。例如,在该目录下创建 99-myvoipapp.conf 文件,并设置以下内容绑定 IPv4 地址(本机的实际地址,这里假设是 1.1.1.1):

listen = 1.1.1.1

(2)修改 Postfix

Postfix 不像 Dovecot 那样提供自定义配置的存放目录,因此只能修改 /etc/postfix/main.cf 文件,修改 inet_interfaces 项绑定 IPv4 地址(本机的实际地址,这里假设是 1.1.1.1):

inet_interfaces = 1.1.1.1

(3)启用 SMTPS

完成上述两步操作后,email 系统绑定了 IPv4 地址,重启 Postfix 以及 Dovecot 就可以了。Debian 系统默认配置没有启动 SMTPS,只启动了SMTP。建立 TCP 连接后,客户端收到 STARTTLS 命令才启用 TLS 加密传输过程,这样可以兼容化石级的 email 客户端,但目前主流的 email 客户端(包括我们正在使用的客户端)都支持 SMTPS,完全可以一开始就直接建立 TLS 连接。

修改 /etc/postfix/master.cf 文件,将以下内容的注释去掉即可启动 SMTPS:

smtps     inet  n       -       -       -       -       smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=$mua_client_restrictions
-o smtpd_helo_restrictions=$mua_helo_restrictions
-o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING

(4)相关命令

完成配置后,可以使用以下命令检查是否正确:

sudo postfix check
sudo dovecot -n

使用以下命令重启 Postfix 和 Dovecot:

sudo systemctl restart postfix
sudo systemctl restart dovecot

使用以下命令检查 Postfix 和 Dovecot 的端口占用情况:

sudo netstat -tlnp | grep dovecot
sudo netstat -tlnp | grep tcp | grep :25
sudo netstat -tlnp | grep tcp | grep :465

SMTP 默认采用 TCP 25 端口,而 SMTPS 默认采用 TCP 465 端口。

Postfix 采用 TLS 传输

Postfix 采用 TLS 传输

采用 postfix 发送邮件,默认没有采用 TLS 加密传输,对方的服务器有可能会提示告警(例如 gmail)。另外,邮件传输采用明文,如果不加密,也存在被人窥视的风险。因此建议修改 postfix 的配置,默认采用 TLS 加密。当然,这需要对方的服务器也支持加密,目前绝大多数邮件服务器都支持 TLS 传输。

修改 /etc/postfix/main.cf 文件,增加以下一行配置即可:

smtp_tls_security_level = may

修改了配置文件,使用命令重启 postfix:

sudo systemctl restart postfix
Bitbucket/Mercurial在Debain8上的一点小问题

Bitbucket/Mercurial在Debain8上的一点小问题

由于Debian 7已经被无情地终结了生命周期,因此不得不将部分生产环境升级到Debian 8。总体上还比较顺利,在mercurial库方面遇到点问题,记录如下:

问题1:UnicodeDecodeError: ‘ascii’ codec can’t decode

这是Python脚本编码的问题。一个好的py脚本,应该在脚本起始处就标明编码方式,可惜mercurial的很多脚本没有这么做。Debian 8采用Python 2.7.9,默认是ascii编码,需要修改为默认utf-8编码。注意,Debian 8安装了多个Python版本,首先要确认默认版本号:

python -V

接着修改“/etc/python2.7/sitecustomize.py”文件(如果没有的话,可以手工创建一个),在文件起始处添加以下代码:

import sys
reload(sys)
sys.setdefaultencoding('utf-8')

问题2: [SSL: WRONG_VERSION_NUMBER] wrong version number

Bitbucket网站禁止了有缺陷的TLSv1,TLSv1.1加密方式,奇怪的是mercurial为什么没有根据协商采用SSL或者TLSv1.2? 修改方式也简单,强制mercurial禁止掉TLS。修改“/etc/mercurial/hgrc”,增加以下内容:

[ui]
tls=False
解决DNS污染

解决DNS污染

DNS污染可能是一个比较普遍的问题,主要表现在:(1)DNS查询返回的IP地址根本是错误的。“错误”意思是IP地址要么根本不存在,要么就是个和域名完全无关系的地址。(2)IP地址虽然可能是对的,但是其他参数被莫名修改,例如TTL参数等。

测试了各类DNS服务器,例如阿里DNS、DNSPod(鹅厂)、Google DNS等。无一例外,最终的结果都或多或少被一些看不见的手给修改、甚至屏蔽了。从技术角度上讲,DNS协议本身非常随意、非常粗糙,是典型的互联网蛮荒时代的产物,比如面向UDP、无加密、无鉴权等,因此网络上任何一只手都有可能修改DNS的查询结果。网络进化到IPv6阶段,当然能解决这个问题,不过既然目前绝大部分设备还只支持IPv4协议栈,因此我们还是不得不修修补补来解决这个污染问题。

最根本的解决方法就是加密DNS查询。目前有些DNS服务商提供了私有的加密DNS方式,不过不太通用,需要私有的客户端程序配合。实际上可以不用搞这么复杂,自己建立加密通道,传递DNS消息即可。例如,参考下图的拓扑逻辑:

实现简单DNS透传的逻辑单元
实现简单DNS透传的逻辑单元

在这个网络中,有两个关键程序:dnsProxy和dnsAgent。

dnsProxy顾名思义就是个Proxy,本身并不负责DNS协议的解析,也不保存DNS的查询结果等信息,只是单纯地将DNS消息传递给真正的DNS服务器,并返回相应的结果即可。dnsProxy另一个功能是对外提供加密的数据连接,例如TLS、SSL加密等,甚至可以只是简单地对数据包进行自定义的异或运算即可。另外就是对外提供非标准连接接口,这点非常重要。DNS采用标准UDP53接口作为DNS服务器接口,网络上那些看不见的手,往往就是扫描并篡改53接口的数据包。这个小程序跑在境外(大家都懂的)的一台VPS设备上,推荐采用DigitalOcean,专业的云计算服务商,采用SSD硬盘,价格公道,我们一直用TA,如果你有兴趣的话,请点击这里自行了解细节。

dnsAgent是另一个小程序,主要负责建立与dnsProxy的加密连接,接收普通设备的DNS请求并将其传递给dnsProxy,同时返回DNS结果给普通计算设备。对于网内设备而言,dnsAgent就是个伪装的DNS服务器。同样,dnsAgent其实也不需要关心、也不需要解析DNS协议细节。在我的网络中,dnsAgent跑在一台常年吃灰的树莓派上(还是第一代的)。

实现这些仅仅需要一点UDP、TCP的网络知识,甚至不需要了解DNS协议的细节,无需对DNS数据包做修改。完成后可以愉快地打开很多以前打不开的网站。当然,有些网站始终是打不开的,这是另一个与DNS无关的话题了。

pure-ftp over TLS

pure-ftp over TLS

最近查看log,感觉有些无聊人士尝试干扰或者攻击FTP服务器,因此有必要将FTP服务修改为加密方式。最简单的方法就是采用TLS进行传输(即FTPS),确保传输过程是加密的。

目前系统为Debian7,已部署pureFTPd作为FTP服务器。打开TLS支持方法比较简单,请参考pureFTP over TLS文档。主要步骤如下(假定pureFTPd已经部署):

步骤1:打开pureFTP的TLS支持

执行命令:

echo 1 > /etc/pure-ftpd/conf/TLS

设置TLS为1,运行采用overTLS以及普通不加密方式。如果要求必须使用TLS加密方式,则应设置TLS为2。实际部署中,建议设置为2。

步骤2:创建TLS加密密钥

使用openssl创建即可:

openssl req -x509 -nodes -days 7200 -newkey rsa:2048 -keyout /etc/ssl/private/pure-ftpd.pem -out /etc/ssl/private/pure-ftpd.pem

会提示各项信息输入,照着填写即可。同时,修改pem文件的属性:

chmod 600 /etc/ssl/private/pure-ftpd.pem

完成上述配置后,重启pureFTPd即可:

service pure-ftpd restart

步骤3:FileZilla采用显式加密

在FileZilla的站点管理配置中,“通用 – 加密”项必须配置为“要求显式的FTP over TLS”,如附图所示即可。

FTP over TLS
配置FileZilla采用FTP over TLS

Apache自动输入密钥文件密码

Apache自动输入密钥文件密码

从startSSL申请了证书并成功加载到apache,这些都是通用步骤,具体可以直接参考startSSL的说明文档:http://www.startssl.com/?app=21

然而由于密钥文件是采用访问密码保护,因此重启apache时,读取密钥文件会要求手工输入密码,例如以下提示信息:

Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.
Enter pass phrase:

这样非常不方便,因此需要将密钥的访问密码告诉apache,并自动输入该密码。

以下步骤都是以root身份进行,系统为Debian 7。

创建shell文件:vi /etc/ssl/apache_pass.sh,并输入以下内容,用于输出访问密码:

#!/bin/sh
echo "1234" <-- 这个是密钥文件的访问密码

出于安全的考虑,将这个文件设置为可执行,并且只能由root访问:

chmod 400 apache_pass.sh
chmod +x apache_pass.sh

接下来就是修改/etc/apache2/mods-available/ssl.conf文件,将SSLPassPhraseDialog由默认的builtin修改为以下值(其实就是执行上述shell文件):

SSLPassPhraseDialog exec:/etc/ssl/apache_pass.sh

完成上述步骤后,重启apache2,将自动输入密钥文件的访问密码,不再需要手工操作。

openssl一二事

openssl一二事

由于工作上的需要,最近两天折腾openssl来实现一些信令加密解密的事情。总体来说,openssl是个很不错的库,也是个很不错的工具。使用openssl做tls客户端编程没有太大问题,而实现tls服务器端则有些地方需要注意。

首先要注意的一点就是:在握手之前(SSL_accept),绝对不能采用非阻塞方式。握手成功之后,才可以将socket修改为非阻塞方式,否则握手不会成功,服务器总是会向客户端返回“Engypted alert”消息并结束握手。

如果是在windows环境生成证书和密钥,建议使用SimpleCA工具,很好用。同时要注意:(1)客户端应安装或者使用该工具生成的根证书,例如ca.crt。(2)服务端需要使用生成的服务端证书和密钥,即.crt和.key文件。(3)生成证书时(无论是根证书还是服务端证书),Common Name都必须要设置为当前服务器的IP地址或者主机名,否则双方握手时,可能产生”certificate name mismatch”等错误。(4)如果需要将证书导入windows系统,必须导入为“受信任的根证书颁发机构”类型。

如果是Ubuntu等linux系统,可以直接安装使用openssl生成证书,如以下命令:

生成根证书:
openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

生成服务端证书和密钥
openssl genrsa -out server.key 1024
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

理论上来说,可以将.crt和.key文件合并在一起,设置为.pem文件。不过实践证明,openssl的API是要求SSL_CTX_use_PrivateKey_file函数来加载密钥文件的,否则握手还是会出问题(当然,也可能是需要另外单独的设置)。