电子邮件安全指南：NIST SP800-45v2解析

需积分: 7 193 浏览量更新于2024-07-16 收藏 988KB PDF 举报

"NIST SP800-45v2.pdf" 是一份由美国国家标准与技术研究所（NIST）发布的关于电子邮件安全的指南，旨在详细阐述邮件服务器和邮件客户端的安全问题，以及如何应对网络攻击。正文：电子邮件是互联网上最常用的商务信息交流工具。其核心流程包括两个主要部分：一是邮件服务器，负责传递、转发和存储电子邮件；二是邮件客户端，它为用户提供读取、编写、发送和存储邮件的接口。这份文档特别关注邮件服务器和邮件客户端的安全，包括通过Web访问邮件时的安全问题。邮件服务器和运行邮件客户端的工作站经常成为攻击者的攻击目标。由于电子邮件相关的计算和网络技术普及且被广泛理解，攻击者能够开发利用安全漏洞的方法。此外，邮件服务器因其必须与不可信的第三方进行一定程度的通信，而成为攻击的焦点。同时，邮件客户端也因为能有效植入恶意软件并传播到其他机器而受到攻击。因此，对邮件服务器、邮件客户端及其支撑的网络基础设施的保护至关重要。 NIST SP800-45v2提供了关于电子邮件安全的推荐措施，可能涵盖以下几个方面： 1. **安全策略和管理**：制定和执行严格的电子邮件使用政策，包括密码策略、访问控制和用户教育，以增强员工的安全意识。 2. **邮件服务器安全**：实施安全配置，如防火墙规则、安全更新和补丁管理，以防止未经授权的访问和恶意软件传播。此外，应启用邮件过滤功能，如垃圾邮件过滤和病毒扫描。 3. **邮件客户端保护**：确保客户端软件保持最新，安装必要的安全软件，例如防病毒软件和恶意软件防护。限制用户执行可能引入风险的行为，比如打开未知附件或点击可疑链接。 4. **加密通信**：使用SSL/TLS等加密协议保护邮件在传输过程中的机密性，防止数据在传输过程中被窃取。 5. **备份和恢复**：定期备份邮件数据，并确保在系统遭受攻击或故障时，可以恢复重要信息。 6. **审计和监控**：实施日志记录和监控机制，以便检测异常活动和潜在的攻击行为。 7. **Web邮件安全**：对于通过Web访问邮件的情况，确保Web服务器的安全性，并采用多因素认证来增加用户验证的复杂性。 8. **持续监测和响应**：持续监视电子邮件系统的安全状况，快速响应发现的威胁，及时修复漏洞。 9. **灾难恢复计划**：建立全面的灾难恢复计划，以防邮件服务中断，确保业务连续性。 NIST的这份指南为组织提供了保护电子邮件系统免受网络攻击的框架，强调了从多个层面进行防御的重要性，包括技术、管理和操作层面。遵循这些推荐措施，可以显著提高电子邮件系统的安全性，减少因电子邮件系统被攻破而导致的数据泄露和业务损失。

GUIDELINES ON ELECTRONIC MAIL SECURITY

1.3 Audience and Assumptions

The document, while technical in nature, provides the background information to help readers understand

the topics that are discussed. The intended audience for this document includes the following:

 Users when setting up mail clients and accessing email

 System engineers and architects when designing and implementing mail systems

 System administrators when administering or upgrading mail systems

 Program managers and information technology (IT) security officers to ensure that adequate security

measures have been considered for all phases of the system’s life cycle.

The practices recommended in this document are designed to help mitigate the risks associated with email

and other known security problems. They build on and assume the implementation of practices described

in other NIST guidelines listed in Appendix E.

1.4 Document Organization

The remainder of this document is organized into the following eight major sections:

 Section 2 includes background information and standards relating to email.

 Section 3 contains information on protecting email messages by signing and encrypting them.

 Section 4 discusses the planning and management of a mail server.

 Section 5 presents an overview of securing the underlying operating system of a mail server.

 Section 6 discusses securing a mail server application, protecting messages traversing the server, and

securing access to mailboxes.

 Section 7 addresses protecting a mail server through the supporting network infrastructure.

 Section 8 provides information regarding mail client security.

 Section 9 discusses the basics of securely administering a mail server on a daily basis.

The document also contains several appendices with supporting material:

 Appendix A defines terms used in this document.

 Appendix B lists relevant Request for Comment (RFC) documents.

 Appendix C lists references used in this document.

 Appendix D identifies email security tools and applications.

 Appendix E lists online email security resources.

 Appendix F presents a set of mail server and client security checklists.

 Appendix G lists the acronyms used throughout the document.

 Appendix H contains the index for the document.

1-2

GUIDELINES ON ELECTRONIC MAIL SECURITY

2. Background and Standards

As of January 2007, the estimated number of Internet users worldwide exceeded one billion.

Most of

these users have electronic mail (email) accounts on one or more mail systems, which is a huge leap from

its inception in 1971, when Ray Tomlinson, a Department of Defense (DoD) researcher, sent the first

ARPANET email message to himself. The ARPANET, precursor to the Internet, was a United States

(U.S.) Advanced Research Project Agency (ARPA) project intended to develop a set of communications

protocols to transparently connect computing resources in various geographical locations. Messaging

applications were available on ARPANET systems; however, they could only be used for sending

messages to users with local system accounts. Tomlinson modified the existing messaging system so that

users could send messages to users on other ARPANET connected systems. After Tomlinson’s

modification was available to other researchers, email quickly became the most heavily used application

on the ARPANET.

As the ARPANET evolved into the Internet, email remained one of the most heavily used applications for

personal and business users. Since the ARPANET was initially a small and trusted community, there was

little need for security. The growth in the popularity of the Internet greatly increased the need for

security. Unfortunately, the needed security was lacking because early email standards and

implementations placed little emphasis on security. Maintaining compatibility with these standards

presents a great challenge in securing email today.

2.1 Background

An understanding of how email messages are composed, delivered, and stored is helpful in understanding

email security. For most email users, once a message is composed and sent, it leaves the computer and

magically appears in the intended recipient’s inbox. This may seem simple but the handling and delivery

of an email message can be as complex as that involving physical mail, with processing and sorting

occurring at several intermediary locations before arriving at the final destination.

The process starts with message composition. The most basic mail clients typically ask the user to

provide the following: subject line, message content, and intended recipients. When these fields are

completed and the user sends the message, the message is transformed into a specific standard format

specified by Request for Comments (RFC) 2822, Internet Message Format. At the most basic level, the

two primary message sections are the header and the body. The header section contains the vital

information about the message including origination date, sender, recipient(s), delivery path, subject, and

format information. The body of the message contains the actual content of the message.

Once the message is translated into an RFC 2822 formatted message, it can be transmitted. Using a

network connection, the mail client, referred to as a mail user agent (MUA), connects to a mail transfer

agent (MTA) operating on the mail server. After initiating communication, the mail client provides the

sender’s identity to the server. Next, using the mail server commands, the client tells the server who the

intended recipients are. Although the message contains a list of intended recipients, the mail server does

not examine the message for this information. Only after the complete recipient list is sent to the server

does the client supply the message. From this point, message delivery is under control of the mail server.

World Internet Usage and Population Statistics, http://www.internetworldstats.com/stats.htm.

Refer to RFC 2822 for additional information on message headers. Appendix B contains a comprehensive list of email-

related RFCs that includes the URLs for many mail-related RFCs. It also indicates which RFCs are considered standards

and which are informational, standards in progress, or best current practices (BCP).

2-1

GUIDELINES ON ELECTRONIC MAIL SECURITY

Once the mail server is processing the message, several events occur: recipient server identification,

connection establishment, and message transmission. Using Domain Name System (DNS) services, the

sender’s mail server determines the mail server(s) for the recipient(s). Then, the server opens up a

connection(s) to the recipient mail server(s) and sends the message employing a process similar to that

used by the originating client. At this point, one of two events could occur. If the sender’s and

recipient’s mailboxes are located on the same mail server, the message is delivered using a local delivery

agent (LDA). If the sender’s and recipient’s mailboxes are located on different mail servers, the send

process is repeated from one MTA to another until the message reaches the recipient’s mailbox.

When the LDA has control of the message, a number of possible events may occur. Depending on the

configuration, the LDA could deliver the message or process the message based on a predefined message

filter before delivery (filtering can be based on a number of message properties and is discussed in detail

in Section 6.2.2). Once the message is delivered, it is placed in the recipient’s mailbox where it is stored

until the recipient performs some action on it (e.g., read, delete) using the MUA. Figure 2.1 illustrates the

flow of the message through the various mail components discussed previously. This is the general

process of sending an email.

Figure 2.1: Example of Message Flow

2.2 Multipurpose Internet Mail Extensions

RFC 2822 provides a standard for transmitting messages containing textual content; however, it does not

address messages that contain attachments, such as a mail message with a word processing document or

photo included. Making use of the headers in an RFC 2822 message, the Multipurpose Internet Mail

Extensions (MIME) provide almost endless possibilities to describe the structure of rich message content.

MIME uses the convention of content-type/subtype pairs to specify the native representation or encoding

of associated data. Examples of content types include the following:

 Audio – for transmitting audio or voice data.

 Application – used to transmit application data or binary data.

 Image – for transmitting still image (picture) data.

 Message – for encapsulating another mail message.

 Multipart – used to combine several message body parts, possibly of differing types of data, into a

single message.

2-2

GUIDELINES ON ELECTRONIC MAIL SECURITY

 Text – used to represent textual information in a number of character sets and formatted text

description languages in a standardized manner.

 Video – for transmitting video or moving image data, possibly with audio as part of the composite

video data format.

The current MIME standards include five parts: RFCs 2045, 2046, 2047, 4289 (which replaced 2048),

and 2049 (see Appendix B). They address message body format, media types, non-American Standard

Code for Information Interchange (non-ASCII) message header extensions, registration procedures, and

conformance criteria, respectively. With this added functionality, email features such as message

attachments and inline hypertext markup language (HTML) are possible. Although MIME extensions

allow for binary message content, such content is incorporated into an RFC 2822 message using Base64

encoding, which provides a textual representation of binary data.

2.3 Mail Transport Standards

To ensure reliability and interoperability among various mail applications, mail transport standards were

established. In the simplest scenario, an email message is sent from one local user to another local user.

For this case, an LDA is responsible for placing the message in the appropriate mailbox. When a message

is sent to non-local recipients, an MTA is needed to send the message from the local mail server to the

remote mail server. Depending on the type of systems involved, different MTAs may be used, which in

turn may support different implementations of a particular message transfer protocol or more than one

distinct transfer protocol.

The most common MTA transfer protocol is the Simple Mail Transfer Protocol (SMTP). SMTP is the

de-facto Internet standard for sending email messages. Thus, any Internet messaging system must support

SMTP to facilitate communication with other email messaging applications. Other messaging systems

exist that use different MTA transfer protocols between similar or clustered messaging systems. For the

most part, these MTAs are proprietary and work only with specific systems. Sections 2.3.1 and 2.3.2

provide background information on SMTP and SMTP extensions, while Section 2.3.3 discusses

proprietary MTAs.

2.3.1 Simple Mail Transfer Protocol

Jon Postel of the University of Southern California developed SMTP in August 1982. As RFC 821,

Simple Mail Transfer Protocol, states, “SMTP was developed to ensure a more reliable and efficient way

to transport messages.” At the most basic level, SMTP is a minimal language that defines a

communications protocol for delivering email messages. Figure 2.2 lists the SMTP commands and

syntax as defined in RFC 2821, Simple Mail Transfer Protocol, which replaced RFC 821.

Base64 encoding was originally derived from RFC 1421 for Privacy Enhanced Mail (PEM).

2-3

GUIDELINES ON ELECTRONIC MAIL SECURITY

Figure 2.2: SMTP Commands

When a user sends an email, the client contacts its SMTP server and conducts a “conversation” using the

SMTP language. A MUA is typically part of the mail client application (e.g., Outlook, Eudora). If an

MUA is unavailable, email messages can be sent using a Telnet client connected to the SMTP service.

Figure 2.3 depicts a sample SMTP conversation using Telnet. The Telnet and SMTP commands entered

by the user for this session are shown in bold. During a manual SMTP Telnet session, the HELP

command can be used to determine which of the SMTP commands are enabled on the server.

HELO <domain> (Hello) Connect to the server as specified in <domain>

MAIL FROM:<reverse-path> Tell the server the sender’s identity as specified in <reverse-path>

[Mail-parameters]

RCPT TO:<forward-path> (Recipient) Tell the server the intended recipient’s identity as specified in

[Rcpt-parameters] <forward-path>

DATA Convey the message body to the server

RSET (Reset) Reset the server connection

VRFY <string> (Verify) Ask the receiver to confirm that a user has been identified

EXPN <string> (Expand) Ask the receiver to confirm that a mailing list has been identified

HELP [<string>] Obtain help information

NOOP [<string>] (No operation) Indicate no operation, but signify the sender is still connected

(i.e.,“alive”)

QUIT Close the server connection

telnet mail.nowhere.com 25

Connected to mail.nowhere.com.

Escape character is '^]'.

220 test.mail.com SMTP Service (Sample Mail Server String)

HELO

250 test.mail.com

MAIL FROM: jdoe@nowhere.com

250 Sender <jdoe@nowhere.com> Ok

RCPT TO: jsmith@somewhere.com

250 Recipient <jsmith@somwhere.com> Ok

DATA

354 Ok Send data ending with <CRLF>.<CRLF>

Hello World!

250 Message received: GM1BAR00.F4M

QUIT

221 mail.nowhere.com SMTP server closing connection.

Connection closed by foreign host.

Figure 2.3: Sample SMTP Conversation

2.3.2 Simple Mail Transfer Protocol Extensions

As the number of email users grew, additional functionality was sought in mail clients and SMTP servers.

For SMTP servers to support this additional functionality, extensions were added to SMTP. In 1993,

RFC 1425 introduced the concept of SMTP service extensions. Subsequently, RFC 1425 was superseded

by RFC 1651 in 1994, RFC 1869 in 1995, and RFC 2821 in 2001. These RFCs added three pieces to the

SMTP framework:

2-4

剩余138页未读，继续阅读

艾米的爸爸

粉丝: 798
资源: 314

电子邮件安全指南：NIST SP800-45v2解析

NIST SP800-28v2：Web浏览器安全与移动代码指南

NIST SP800-53安全控制措施标准中英文版发布

NIST SP800-53A：联邦信息系统安全控制评估指南

NIST SP800-28v2.pdf

NIST SP800-44v2.pdf

NIST SP800-45.pdf

NIST SP800-111.pdf

NIST SP800-168.pdf

NIST SP800-21.pdf

NIST SP800-120.pdf

最新资源