鱼叉式网络钓鱼和网络钓鱼_您需要了解的反网络钓鱼标准–第1部分

鱼叉式网络钓鱼和网络钓鱼

*This article by Marc Laliberte was originally published in the October edition of Cyber Defense Magazine. 

*马克·拉里伯特（Marc Laliberte）的这篇文章最初发表在《 网络防御》杂志的10月版中。

Phishing emails are a popular malware delivery vehicle for attackers. In fact, according to Verizon’s 2017 Data Breach Investigations Report, two-thirds of all malware in 2016 was installed via email attachments. Often the most difficult part in crafting a phishing email is designing it in such a way that the victim will believe it and follow the instructions.

网络钓鱼电子邮件是攻击者流行的恶意软件传递工具。 实际上，根据Verizon的《 2017年数据泄露调查报告》，2016年所有恶意软件中有三分之二是通过电子邮件附件安装的。 通常，在设计仿冒电子邮件时，最困难的部分是以使受害者相信并遵循说明的方式进行设计。

While there are many ways for an attacker to increase the chances of success for their phishing emails, one of the most effective methods involves spoofing the message to appear to come from a trusted source. Before we can dive in to how the attackers spoof the sender and how to protect against it, we first need to go over some email message basics.

尽管攻击者可以通过多种方法来增加其仿冒电子邮件的成功机会，但最有效的方法之一是对邮件进行欺骗，使其看起来似乎来自受信任的来源。 在深入研究攻击者如何欺骗发送者以及如何防止发送者之前，我们首先需要了解一些电子邮件基础知识。

The Basics

基础

The format and process for most email messages is actually very similar to a traditional snail mail message. An email message includes an envelope with routing address information, and a message letter that sits inside the envelope. The envelope address headers are just like what you would expect to see in a traditional mail envelope. There is a header for the sender, called MAIL FROM, and a header for the recipient, called RCPT TO. In the case of a CC or BCC recipient, the sending mail server simply adds more RCPT TO headers to send digital copies of the message to the other recipients. Email servers use these envelope headers when deciding where to route a message and where to send delivery failure messages if any issues are encountered along the way.

实际上，大多数电子邮件的格式和过程与传统的蜗牛邮件非常相似。 电子邮件包括带有路由地址信息的信封以及位于信封内部的一封信。 信封地址标头与您期望在传统邮件信封中看到的一样。 发送者有一个头，称为MAIL FROM，接收者有一个头，称为RCPT TO。 对于CC或BCC收件人，发送邮件服务器只需添加更多RCPT TO标头，即可将邮件的数字副本发送给其他收件人。 电子邮件服务器在确定路由消息的位置以及在传递过程中遇到任何问题时向何处发送传递失败消息时使用这些信封头。

Inside the message envelope sits the email message itself. The message also uses several headers, including separate headers for the sender (FROM header), recipient (TO header), a header for the message subject (Subject header), and a timestamp for the message (Date header), among others. Your email client uses these message headers, not the envelope headers, when displaying details like the sender, recipients, and subject of a message.

邮件信封内是电子邮件本身。 该消息还使用多个标头，包括发送者的单独标头（FROM标头），接收者的（TO标头），消息主题的标头（主题标头）和消息的时间戳（日期标头）等。 当显示诸如发件人，收件人和邮件主题之类的详细信息时，您的电子邮件客户端将使用这些邮件头，而不是信封头。

Most email clients trust these message headers as-is. This means an attacker can spoof a message’s FROM header to be any address they want, whether it be your company’s CEO, your best friend, or your bank. By spoofing the sender address in their phishing emails, attackers make the context of their message more convincing, increasing the chances that the victim will fall for it. In fact, nearly all malicious e-mail messages use a spoofed sender address. Luckily, there are technologies and standards available to protect yourself and your users from sender address forgery.

大多数电子邮件客户端原样信任这些邮件头。 这意味着攻击者可以将邮件的FROM头标欺骗为他们想要的任何地址，无论是您公司的CEO，您最好的朋友还是您的银行。 通过在网络钓鱼电子邮件中欺骗发件人地址，攻击者使他们的邮件上下文更具说服力，从而增加了受害者被其欺骗的可能性。 实际上，几乎所有恶意电子邮件都使用欺骗的发件人地址。 幸运的是，有可用的技术和标准来保护您自己和您的用户免遭发件人地址伪造。

SPF

SPF

Sender Policy Framework (SPF) is an open standard developed by the Internet Engineering Task Force (IETF), designed to combat sender address forgery in envelope MAIL FROM headers. SPF enables organizations to specify what servers are allowed to send emails with an envelope MAIL FROM address in their domain by using DNS records. Recipient mail servers can then use these special DNS records to confirm that a message from any given domain truly came from that domain.

发件人策略框架（SPF）是由Internet工程任务组（IETF）开发的开放标准，旨在与信封MAIL FROM标头中的发件人地址伪造作斗争。 SPF使组织可以使用DNS记录指定允许哪些服务器使用其域中的信封MAIL FROM地址发送电子邮件。 然后，收件人邮件服务器可以使用这些特殊的DNS记录来确认来自任何给定域的邮件确实来自该域。

To implement SPF in the simplest way, domain administrators must create a DNS TXT record in their domain that specifies which IP addresses or hostnames are allowed to send mail for that domain. An example SPF record for the domain “example.com” might be “v=spf1 ip4:11.0.0.1 A:mail.example.com” which means the IP address 11.0.0.1 and the server located at mail.example.com are allowed to send email for the domain.

为了以最简单的方式实现SPF，域管理员必须在其域中创建DNS TXT记录，该记录指定允许哪些IP地址或主机名发送该域的邮件。 域“ example.com”的示例SPF记录可能是“ v = spf1 ip4：11.0.0.1 A：mail.example.com”，这意味着IP地址11.0.0.1和位于mail.example.com上的服务器是允许发送该域的电子邮件。

When a recipient mail server with SPF record validation enabled receives a message, it uses a DNS query to check the SPF records for the sender’s domain. If an SPF record is found, the mail server will compare the allowed source addresses with the address of the actual server which sent the email. The admin in charge of the recipient mail server is given control over what to do when a message fails SPF checking. They can configure the mail server to drop the email entirely, or they can configure it to tag the message as possibly spam, but accept it anyway.

当启用了SPF记录验证的收件人邮件服务器收到邮件时，它将使用DNS查询来检查发件人域的SPF记录。 如果找到SPF记录，则邮件服务器会将允许的源地址与发送电子邮件的实际服务器的地址进行比较。 当邮件未通过SPF检查时，将控制收件人邮件服务器的管理员该做什么。 他们可以将邮件服务器配置为完全删除电子邮件，也可以将其配置为将邮件标记为垃圾邮件，但无论如何都可以接受。

A major drawback of SPF is that it only cares about the envelope MAIL FROM header, it doesn’t check the message FROM header contained in the email itself. Because email clients typically use the message FROM header to display the sender of an email, an attacker can still spoof this header while providing valid address for the envelope header.

SPF的主要缺点是它只关心信封MAIL FROM头，而不检查电子邮件本身中包含的消息FROM头。 因为电子邮件客户端通常使用消息FROM头来显示电子邮件的发件人，所以攻击者仍然可以欺骗该头，同时为信封头提供有效地址。

DKIM

DKIM

Another technology available to combat spoofing is DomainKeys Identified Mail (DKIM). DKIM is the combination of Enhanced DomainKeys from Yahoo and Identified Internet Mail from Cisco. In a nutshell, DKIM uses cryptographic digital signatures to authenticate email messages, allowing recipient mail servers to verify the authenticity of the message sender and even the message contents. DKIM is similar to SPF in that it uses DNS TXT records to house important information, in this case RSA public keys for digital signature verification.

可以用来对抗欺骗的另一种技术是DomainKeys Identified Mail（DKIM）。 DKIM是Yahoo的Enhanced DomainKeys和Cisco的Identified Internet Mail的组合。 简而言之，DKIM使用加密数字签名对电子邮件进行身份验证，从而使收件人邮件服务器可以验证邮件发送者甚至邮件内容的真实性。 DKIM与SPF相似，因为它使用DNS TXT记录来存储重要信息，在这种情况下，是用于数字签名验证的RSA公钥。

DKIM works by first naming a few important parts of the message to protect, usually including the FROM and TO headers, the subject header, the date header, and even the message body itself. The sending mail server then computes a cryptographic hash of the chosen sections and then encrypts it using a private key, creating a digital signature. The digital signature and a few informational fields are added back to the message as a special DKIM-Signature message header before he message is sent. Because the corresponding public key is published in a DNS TXT record for the sending domain, recipient mail servers can decrypt the hash and verify it, confirming the protected fields were not spoofed or modified in message transit.

DKIM的工作方式是首先命名要保护的消息的几个重要部分，通常包括FROM和TO头，主题头，日期头，甚至是消息主体本身。 然后，发送邮件服务器计算所选部分的加密哈希，然后使用私钥对其进行加密，从而创建数字签名。 在发送消息之前，数字签名和一些信息字段将作为特殊的DKIM-Signature消息标头添加回消息中。 由于相应的公用密钥已发布在发送域的DNS TXT记录中，因此收件人邮件服务器可以解密哈希并进行验证，从而确认在邮件传输过程中未对受保护的字段进行欺骗或修改。

DKIM unfortunately has its own limitations. While header fields protected by a DKIM signature can be confirmed as valid, a message without any DKIM signature at all causes problems. The DKIM standard does not provide a mechanism to confirm if a message should have a DKIM header when no header is present. This means, without other protections in place, an attacker can simple omit a DKIM header from their phishing email to bypass DKIM protections.

不幸的是，DKIM有其自身的局限性。 虽然可以确认受DKIM签名保护的标头字段有效，但是完全没有任何DKIM签名的消息会导致问题。 DKIM标准没有提供一种机制来确认没有标题时消息是否应具有DKIM标题。 这意味着，如果没有其他保护措施，攻击者可以简单地从网络钓鱼电子邮件中省略DKIM标头，以绕过DKIM保护。

DMARC

DMARC

Back in 2011, a group of organizations including AOL, Comcast, Google, and Yahoo, among others, came together to create an even more comprehensive technology standard to address email spoofing called Domain-based Message Authentication, Reporting and Conformance or “DMARC” for short. Within its first year, 60% of internet mailboxes used DMARC verification for anti-spam and anti-phishing.

早在2011年，包括AOL，Comcast，Google和Yahoo在内的一组组织就共同创建了一种更为全面的技术标准，以解决称为基于域的消息身份验证，报告和一致性或“ DMARC”的电子邮件欺骗行为。短。 在成立的第一年，60％的互联网邮箱就使用DMARC验证来反垃圾邮件和反网络钓鱼。

DMARC allows a message sender’s domain to advertise if their messages should be protected by SPF and/or DKIM, and provides instructions to recipient mail servers for what to do if a message fails these checks. Along with the normal SPF and DKIM checks, DMARC also checks if the envelope MAIL FROM header matches the message’s FROM header.

DMARC允许邮件发件人的域进行广告，如果它们的邮件应受SPF和/或DKIM保护，并向收件人邮件服务器提供指令，以指示如果邮件未通过这些检查，该怎么办。 除了常规的SPF和DKIM检查外，DMARC还检查信封MAIL FROM头是否与邮件的FROM头匹配。

DMARC assumes that the domain administrator has already configured DKIM and SPF for their sending domain. DMARC then uses a DNS TXT record, just like SPF and DKIM, to verify important information for the sending domain. The DMARC DNS record includes a policy for the recipient mail server to apply when DKIM and/or SPF records fail, such as rejecting the message, quarantining it, or allowing it through, and an email address to send reports to for non-compliant messages.

DMARC假定域管理员已经为其发送域配置了DKIM和SPF。 然后，DMARC使用DNS TXT记录（如SPF和DKIM）来验证发送域的重要信息。 DMARC DNS记录包括当DKIM和/或SPF记录失败（例如拒绝邮件，隔离邮件或允许其通过）时适用于收件人邮件服务器的策略，以及用于向不符合要求的邮件发送报告的电子邮件地址。 。

DMARC fills in the gaps left over from SPF and DKIM, providing additional anti-spoofing protections and directions for recipient mail servers on how to handle potentially spoofed messages. A recent report by ValiMail and the Global Cyber Alliance found 76% of email inboxes now support DMARC verification. Unfortunately, according to a recent report by Return Path, DMARC implementation is still very low in most verticals, ranging from 16% (Healthcare) at worst to 61% (Payment Services) at best.

DMARC填补了SPF和DKIM留下的空白，为收件人邮件服务器提供了额外的反欺骗保护以及有关如何处理潜在欺骗邮件的指导。 ValiMail和全球网络联盟的最新报告发现，现在有76％的电子邮件收件箱支持DMARC验证。 不幸的是，根据Return Path的最新报告，在大多数垂直行业中，DMARC的实施率仍然很低，范围从最坏的16％（医疗保健）到最好的61％（支付服务）。

To find out why these anti-phishing standards aren’t more widely used and what might be done to increase their adoption, check back for Part II next month.

要了解为什么这些反网络钓鱼标准没有得到更广泛的使用以及如何提高其使用率，请查看下个月的第二部分。

翻译自: https://www.experts-exchange.com/articles/31138/What-You-Need-To-Know-About-Anti-Phishing-Standards-Part-1.html

鱼叉式网络钓鱼和网络钓鱼