电子邮件欺诈防护之 SPF+DKIM+DMARC

前言

早在之前,有收到一个白客的邮件,说我们发送电子邮件的域名缺少安全检查,让我们最好补上对应的安全检查:

 I'm an independent cyber security researcher i have found multiple issues in your website.

 Vulnerability : Missing SPF 


 I am just looking at your SPF records then found following. SPF Records missing safe check which can allow me to send mail and phish easily any victim.

 PoC:

 <?php

 $to = "[email protected]";

 $subject = "Password Change";

 $txt = "Change your password by visiting here - [VIRUS LINK HERE]l";

 $headers = "From: https://karve.io";

 mail($to,$subject,$txt,$headers);

 ?>
 SPF record lookup and validation for: xxx.com 

后面检查了一下,发现确实是这样子,我们的电子邮件没有加上对应的安全检查,很容易被别人冒发,从而有可能对我们的用户造成严重的电子邮件欺诈。

发送欺诈电子邮件的危害

举个例子,黑客可以通过这个站点 emkei.cz 来冒充我们的官方 support 邮箱来发送一些钓鱼邮件给用户。如果用户信以为真,那么就会对用户的利益造成损失,这就是电子邮件欺诈

这时候我们的用户就会收到这一封冒充的邮件,如果用户相信了,就很容易被骗子给利用了。

所以电子邮件欺诈的危害性还是很高的。这方面的安全问题,一定要尽快解决。

电子邮件的缺陷

在解决这个问题的时候,我们要了解一下为啥电子邮件会有这个问题?

电子邮件系统的基础是简单邮件传输协议(Simple Mail Transfer Protocol, SMTP), SMTP是发送和中继电子邮件的互联网标准. 但是, 正如1981年最初设想的, SMTP不支持邮件加密、完整性校验和验证发件人身份。

由于这些缺陷, 发送方电子邮件信息可能会被网络传输中的监听者截取流量读取消息内容导致隐私泄漏, 也可能遭受中间人攻击(Man-in-the-Middle attack, MitM)导致邮件消息篡改, 带来网络钓鱼攻击. 为了解决这些安全问题应对日益复杂的网络环境, 邮件社区开发了诸多电子邮件的扩展协议, 例如STARTTLS, S/MIME, SPF, DKIMDMARC等协议。 当前的邮件服务厂商大都也是采用以上扩展协议的一种或几种组合, 辅以应用防火墙、贝叶斯垃圾邮件过滤器等技术, 来弥补电子邮件存在的安全缺陷.

你可以理解为 SMTP 本身有毛病,机密性和安全性都不够,所以就多了几个插件来帮他:

1.提高传输的机密性,包括端对端加密 --> STARTTLS, S/MIME
2.邮件的身份验证 --> SPF, DKIM, DMARC

电子邮件欺诈本质上就是邮件接收端没法判断这一封邮件来源是否合法。所以这边就涉及到了邮件的身份验证这一块。而且虽然STARTTLSSMTP-STS保证了邮件在传输过程中的加密, 防止遭受窃听读取, 但是其仍无法解决发件方身份伪造、消息篡改等问题。 所以邮件的身份验证这一块尤为重要。

所以本节主要讲 SPF, DKIM,DMARC 这三个协议的设置并结合我们的站点来实践。

SPF

SPF 概念

发件人策略框架(Sender Policy Framework, SPF)是一种以IP地址认证电子邮件发件人身份的检测电子邮件欺诈的技术, 是非常高效的垃圾邮件解决方案。SPF允许组织授权一系列为其域发送邮件的主机, 而存储在DNS中的SPF记录则是一种TXT资源记录, 用以识别哪些邮件服务器获允代表本网域发送电子邮件。 SPF阻止垃圾邮件发件人发送假冒本网域中的“发件人”地址的电子邮件, 收件人通过检查域名的SPF记录来确定号称来自该网域的邮件是否来自授权的邮件服务器。 如果是, 就认为是一封正常的邮件, 否则会被认为是一封伪造的邮件而进行退回。 SPF还允许组织将其部分或全部SPF策略委托给另一个组织, 通常是将SPF设置委托给云提供商。

简单的来说,这个协议就是去核实邮箱源IP地址然后匹配它的dns中txt记录的spf信息,如果查找到,那么就是合法的。如果没有查找到,那就邮件的来源有问题。这时候一般邮箱接收端就会有三种处理方式:

1.直接拒绝或者删除
2.认为是垃圾
3.正常的收件箱,但是邮件会有?的等警告,告诉收件者无法验证邮件的真实身份

至于哪一种,不同的邮箱接收端的策略不一样。 下面的图(网络图片)说的很清楚:

SPF 设置

SPF 的设置非常简单,直接在公共的 dns 上进行配置即可。因为我们站点的域名 dns 是在 aws 的 router 53 中设置的。 而且因为我们的发送 mail 的邮箱有两种:

1.发送提醒邮件的 no-reply 邮箱, 这一类邮件是接的 aws 的 ses 服务发送的,是程序自动发送的
2.发送营销邮件的 support 和 sale 邮箱,这一类的邮箱是 gmail 邮箱,是人工发送的

所以 ses 和 google 这两个域名都要配置,所以我们就在 router 53xxx.com 这个二级域名中在原有的 TXT 记录中,添加这一条:

"v=spf1 include:_spf.google.com include:amazonses.com -all" 

这样子 SPF 就配置好了。 是不是非常的简单。

测试 SPF 是否生效

配置之后,我们测一下 SPF 是否真的生效, 同样用 emkei.cz 这个站点发送一封欺诈邮件到 gmail ,这时候可以看到收到了:

邮件收到了,但是好像跟没有配置没啥差别??? 其实不然,我们打开 显示原始邮件 看下

猜你喜欢

转载自blog.csdn.net/javagty6778/article/details/129649676