邮件系统基本上是所有企业对外或者对内的工作沟通平台，而随着电子邮件的广泛使用，那些漫天的广告邮件和包含钓鱼链接的垃圾邮件成了一个日益严重的问题，所以我们的企业安全人员以往更多关注反垃圾邮件，对数据保密有要求的企业还会对邮件外发做数据防泄露方面的管控。
这些年，SMTP协议没有变，对攻击者而言，邮件仍然是一个非常好的入口，只是随着技术水平的提升和利益的趋动，APT攻击、勒索软件开始流行起来，并不时被媒体报道。美国大选，希拉里邮箱被黑客攻破，大量竞选相关的黑幕被世人知晓；全球四大会计公司之一的Deloitte（德勤）表示其邮件系统被入侵，大量客户邮件被泄露；Locky 勒索软件通过钓鱼邮件方式大量传播，很多企业用户中招导致文档被加密，还有很多的案例，就不一一列举了。
你的企业邮件系统安全吗？你的企业有用户文档被加密吗？我们又该做些什么工作呢？2017年11月10日，党政机关事业单位和国有企业互联网电子邮件系统安全专项整治工作电视电话会议召开。
根据网上的相关解读，电子邮件安全专项整治行动，分为几个工作措施：梳理排查邮件系统基本情况、开展邮件系统集中建设工作、加强邮件系统网络安全等级保护、加强邮件系统建设安全管理、加强邮件系统的应急处置工作，其中关于安全管理中提及了防钓鱼、防窃密、防病毒、反垃圾、内容过滤、安全审计这几个关键安全保护措施，我们可以做一些方向上的参考。
小编所在单位很早就部署了专门的邮件网关，产品属于Gartner领导者象限（为避免广告嫌疑就不提具体产品了），入站启用反垃圾、防钓鱼、防病毒功能，出站启用内容过滤功能，但在实际的运营过程中，还是遇到了不少问题，在解决这些问题的过程中，安全能力不断提升，这里抽象出来分为几个阶段，希望对大家有帮助。
第一个阶段：满足业务需要
邮件网关从上线的第一天开始就是贴合业务需求，比如反垃圾功能。某天，业务人员向我们反馈，大量发给QQ邮箱的通知邮件失败，希望我们能联系QQ邮箱解决。跟腾讯相关同学进行联系后，对方反馈由于前一天收到大量来自我们通知邮箱的垃圾邮件，所以将我们对应的邮箱加入了黑名单。临时处理后，我们开始研究相应的解决方案，SPF、DKIM、DMARC、RDNS等等。
SPF(Sender Policy Framework)是一种以IP地址认证电子邮件发件人身份的技术。当你定义了你域名的SPF记录之后，接收邮件方会首先检查域名的SPF记录，来确定连接过来的IP地址是否被包含在SPF记录里面，如果在，就认为是一封正确的邮件，否则会认为是一封伪造的邮件进行退回或丢弃处理。SPF可以防止别人伪造你来发邮件，是一个反伪造性邮件的解决方案。设置正确的 SPF 记录可以提高邮件系统发送外域邮件的成功率，也可以一定程度上防止别人假冒你的域名发邮件。
DKIM（DomainKeysIdentified Mail）是一种防范电子邮件欺诈的验证技术，通过消息加密认证的方式对邮件发送域名进行验证。在发送邮件时，发送方会利用本域私钥加密生成DKIM签名并将DKIM签名及其相关信息插入邮件头，而邮件接收方接收邮件时，通过 DNS 查询获得公钥并验证邮件DKIM签名的有效性，从而确认在邮件发送的过程中，防止邮件被恶意篡改，保证邮件内容的完整性。其工作原理图如下：
DMARC（Domain-basedMessage Authentication, Reporting & Conformance）是一种基于现有的SPF和DKIM协议的可扩展电子邮件认证协议，在邮件收发双方建立了邮件反馈机制，便于邮件发送方和邮件接收方共同对域名的管理进行完善和监督。DMARC要求域名所有者在DNS记录中设置SPF记录和DKIM记录，并明确声明对验证失败邮件的处理策略。邮件接收方接收邮件时，首先通过DNS获取DMARC记录，再对邮件来源进行SPF验证和DKIM验证，对验证失败的邮件根据DMARC记录进行处理，并将处理结果反馈给发送方。DMARC能够有效识别并拦截欺诈邮件和钓鱼邮件，保障用户个人信息安全。
RDNS就是反向解析，即把IP解析为域名，有时候邮件发出去被退信，做RDNS会好很多，但这个需要找运营商去做。
对比以上技术方案，SPF只需做DNS记录上的调整，DKIM除了DNS设置外还涉及到邮件网关上的密钥生成及配置，DMARC则在SPF和DKIM基础上多了一个反馈共享机制，需要配套的邮箱来接收这些信息。建议从易到难的方式来实施，实际过程中还需多验证、从子域名着手开始部署，最后逐步。
我们看看qq.com的配置：
qq.com text = "v=spf1 include:spf.mail.qq.com-all”
再看spf.mail.qq.com是一长串的内容：
spf.mail.qq.comtext ="v=spf1 include:spf-a.mail.qq.com include:spf-b.mail.qq.cominclude:spf-c.mail.qq.com include:spf-d.mail.qq.com include:spf-e.mail.qq.com"
一直到spf-a.mail.qq.com才能看到真实的IP地址，其主要原因是腾讯邮箱的服务器太多了，IP地址段非常多而include语法有长度的限制，所以这个需要关注。
这里面有个细节需要在运营的时候关注，IP地址过多尤其是写网段的，随着IP地址的分配变化，有些IP已经不属于该业务或者该企业了，但SPF记录如果未更新的话，可能会被有心人利用。
配置好之后，有个在线网站可以帮你评估：www.mail-tester.com，它会出现一个随机的邮箱，你从你的邮箱发一个邮件过去，它就会自动评分，打对勾的表示测试通过，有扣分的会详细告诉你情况，如下图用QQ邮箱测试效果，9分（只扣了1分，很不错了）：
在邮件网关处对来源IP做SPF做检查，可以有效阻断一些伪造的电子邮件，但在我们实际运营过程中，发现有利用知名公司域名的子域来进行投递恶意邮件的，这个需要关注，比如有一天你收到来自xx@support.microsoft.com的邮件，标题是跟hotfix update相关的内容，你会点开吗？
第二阶段：统计分析优化与应急处置阶段
某日，我们对入站邮件的附件进行分析，得到一个很吓人的数据，直接投递可执行文件的邮件占到了恶意邮件的90%，太简单粗暴了！于是我们开始针对exe、dll等可执行文件直接在邮件网关上进行过滤，凡是附件是可执行文件的直接隔离，以暴制暴！猫和老鼠的游戏从这里开始，exe不行了就开始有压缩包，压缩包邮件网关也还是能识别的，exe、dll没了，但还有好多可执行文件格式可以利用，以下是我们遇到的一起案例样本：
邮件附件名是putty.zip，搞运维的同学都不陌生，点进去就是一个src屏保文件，双击就执行了。于是游戏继续，某日我们又发现一个附件是加密压缩包而且将密码写在邮件中的样本：
将这个压缩包下回来，我们输入邮件正文中的密码进去发现是个cpl的文件，如下图：
这个cpl双击也是可以执行的，执行之后会启动Word打开一个doc文档，大约过4分钟后会跟外部通讯，关于这个cpl样本，又是另外一个很长的故事了，有机会我们再单独介绍。带密码的网关默认是没法解密了，不过也还是有办法，如果发现附件是加密了但同时又在邮件正文中出现密码、password等关键字，则可以在邮件网关上做进一步的处理。现在市面上有一些网关号称可以提取邮件中的密码对压缩包进行解密，还没有实际测试过效果和性能，有测试过的同学可以交流。
第三阶段：查漏补缺阶段
邮件网关包含了反垃圾、防病毒、防钓鱼功能，但实际工作中还是会有放进来的情况，我们建议有条件的企业，将邮件网关投递到企业邮件服务器的流量丢到沙箱进行分析，如果前面网关没拦截而沙箱有发现问题，可以针对性的在邮件网关进行加强，如此查漏补缺不断改进，安全能力肯定会越来越强。
在接入沙箱后，我们看到，除了可执行文件外，还有各种各样的脚本文件，比如我们抓到不少的js、jse、vbs、vbe文件。我们以jse为例说明。Jse，全称JScript EncodedScript，为什么jse能双击就可以运行，其实跟操作系统的环境变量设置有关：
从上面可以看出，vbs,vbe,js,jse等文件可以直接被执行。题外话：如果终端机器不需要执行各种脚本，可以直接在这里修改屏蔽。下面是我们从真实环境中抓到的一些样本截图，比如下面这个是jse的勒索病毒样本：
这个jse并非真正被微软加密过的jse文件，而是病毒作者自己用了各种技术写成的一个脚本，仔细分析，可以得知脚本经过混淆和加密，一个是变量加长混淆，一个是关键函数加密。变量加长的前缀为：wololosampsonFROG2或者Wololosampson，针对此类的变种，基本的思路是替换，将wololosampsonFROG2替换为空，然后将Wololosampson替换为空，得到如下：
这个时候余下的就是作者自定义的加密函数了，考验人耐心的时候到了，下面是真正解密后的内容，为了方便看懂加入了注释：
整个脚本的流程就是访问特定URL下载病毒文件并执行，这里下载后的文件是加密的文件，需要解密后再执行，最后的效果是在感染机器上启动浏览器打开如下的页面：
随着powershell的流行，我们也抓到下面这样一个js样本，原始邮件内容如下：
这个附件打开里面是个js，700多行的代码，各种内部加密组合就不说了，丢到虚拟环境直接看效果：
这个js最后的目标是调用powershell去下载后门并执行，不再过多分析。邮件网关上对策依然是过滤，各种可能有危害的可执行文件、脚本基本在这里被收拾的差不多了。
某日又发现漏放进来了几封邮件，居然还是.7z的压缩包，里面赤祼祼的还是个可执行文件。经过不断测试发现，7zip有四种压缩方式，而现版本的邮件网关居然只支持其中一种压缩方式，其它3种都无法正常检测。
这算是一个坑，经过验证，大版本升级后能解决，但这个细节还需要引起大家的关注，针对压缩包进行检测的场景，邮箱入站检测里、后端沙箱里、出站检测里都会涉及到，不支持就意味着有被突破的风险。还有一些产品，默认有一些参数，比如针对大的office、pdf可能不会进行检查，也需要引起关注，在产品测试选型阶段就要搞清楚，以便采取针对性的措施或方案进行弥补。
