企业中的邮件安全(1)

下一页 1 2 3 4 

　　 

自从电子邮件大大降低了信息的传播成本，垃圾邮件便随之而产生。

笔者作为国内互联网的较早的用户，使用的是自己注册的域名的电子邮件地址，从一开始使用至今一直没有变过，而该邮件地址在国内互联网发展初期曾注册过许多网站服务，因此成为垃圾邮件的目标。

笔者的邮件地址在2000年即每天收到近百封垃圾邮件，因此从那时即开始关注垃圾邮件的控制方法。

2004年1月底，国家四部委联合发文整治垃圾邮件和不良信息，快速启动了国内反垃圾邮件的市场，反垃圾邮件产品厂商风起云涌，但笔者认为许多宣传仅从邮件安全的某个局部出发，失于片面。反垃圾邮件仅仅是邮件安全的一部分技术，邮件安全至少应当包括反垃圾邮件、反邮件病毒、内容过滤等功能，还可能包括邮件溯源、邮件审计等功能。本文由于篇幅所限，只说明反垃圾邮件的技术。

1. SMTP安全漏洞与垃圾分析

1.1 SMTP起源

在互联网上使用的邮件传输协议称为SMTP(Simple Mail Transfer Protocol简单邮件传输协议，RFC-821)，也许有很多初次了解SMTP协议的人会奇怪为什么称为简单邮件传输协议，那么复杂邮件传输协议在哪里？如果这样考虑，可以理解1984年ISO(国际标准化组织)和ITU(国际电信联盟)发布的X.400信件传递标准就是复杂邮件传输协议(当然，其相关协议早在近十年前就在讨论、完善，只是直到1984年才发布标准)。1982年由互联网协会发布了基于TCP/IP的SMTP(RFC821)后，随即发布了RFC822 ASCII纯文本邮件结构，这样就满足了人们发送纯文本邮件的需求，随着需求的增长，1996年发布了一系列MIME(Multipurpos Internet Mail Extensions)格式定义，使电子邮件可以传递任意格式的文件，大家发送邮件时会发现，邮件的大小比附件的大小要大很多，原因就是附件可能经过了MIME编码，导致变大。MIME满足了人们发送任意格式邮件的需求，也同时导致了恶意代码通过电子邮件传递。

1.2 邮件发送过程

一封邮件从发件人编辑邮件到收件人接收邮件一般要通过如下四步：

1. 发送客户端‘(smtp)‘发送邮件服务器：发件人在发送客户端(~MUA~，~Mail User Agent~)编辑邮件后发出，MUA向他定义的发送邮件服务器(~MTA~，~Mail Transport Agent~)发出SMTP请求并握手，发送邮件服务器将邮件接收下来放在相关的邮件队列中。一般来说，MUA在和发件MTA握手时，使用的是用户在MUA该帐号上注册的邮件帐号信息作为信封Mail From和信头From的参数，是相同的；

2. 发送邮件服务器-->(smtp)-->接收邮件服务器：发送邮件服务器根据邮件的目的地址，如果目的地址不是本地，则会将邮件转而放到相应的发送队列中，MTA将邮件从等候的发送队列中取出，向接收邮件服务器发起SMTP请求并握手，接收邮件服务器将邮件接收下来，放入相关的邮件队列中。一般来说，发送MTA会把邮件的信封部分和邮件部分(data，包括信头和信体)分开保存，这样在与接收MTA通信时，Mail From依然使用原来的信息不变；

3. 接收邮件服务器dispatch到邮箱：接收邮件服务器根据邮件的目的地址(当然是本地了)，将邮件由MDA(Mail Deliver Agent)放到用户的邮箱中。接收MTA在和发送MTA握手时，得到的Mail From数据仍然是发件MUA给出的信息。

4. 邮箱服务器-->(pop/imap)-->接收客户端：最后，接收客户端使用POP或IMAP协议将邮件下载、阅读。

1.3 模拟收发过程

SMTP协议是TCP/IP协议的应用层协议，其传递的数据都是人可读的数据，因此可以使用Telnet来仿真、观察SMTP协议的握手过程(假设邮件服务器IP是192.168.100.100)。

Telnet 192.168.100.100 25 ; 25是TCP/IP协议给SMTP定义的端口号

<<< 220 smtp.my.com ESMTP Service (SMTP server) ready at 日期、时间 +0800

>>> helo haha.com

<<< 250 smtp.my.com Hello haha.com ([192.168.100.50]), pleased to meet you

>>> mail from:abc@abc.com

<<< 250 abc@abc.com... Sender OK

>>> rcpt to:realname@my.com

<<< 250 realname@my.com... Recipient OK

>>> data

<<< 354 Enter message, end with "." on a line by itself

>>> Reply-to:clearcase/" target="_blank" >ccc@ccc.com

>>> From:aaa@aaa.com

>>> To:bbb@bbb.com

>>> Subject:testest

>>>

>>> This is a Test Email.

>>> .

<<< 250 Message accepted for delivery

>>> quit

<<< 221 smtp.my.com SMTP Service closing transmission channel

这样就用Telnet直接向smtp.my.com送入了一封给realname用户的邮件。

让我们来看一下收到的这封邮件的源文件：

Received: from haha.com ([192.168.100.50])

by smtp.my.com (SMTP server)

with SMTP id 2004062314152297-16576 ;

Wed, 23 Jun 2004 14:15:22 +0800

Reply-to:ccc@ccc.com

From:aaa@aaa.com

To:bbb@bbb.com

Subject:testest

X-MIMETrack: Itemize by SMTP Server on Mail/my() at 2004-06-23 14:17:10,

Serialize by POP3 Server on Mail/my() at 2004-06-23 14:18:45,

Serialize complete at 2004-06-23 14:18:45

Date: Wed, 23 Jun 2004 14:17:10 +0800

Message-ID: <OF39FF5AC9.A74F14E2-ON48256EBC.00228835@my.com>

This is a Test Email.

从上面的模拟过程可以看出，该邮件在邮件头中声称邮件来自~aaa@aaa.com~，要发给bbb@bbb.com；而在SMTP握手中声称使用计算机haha.com，邮件来自abc@abc.com，要发给realname@my.com(这是真正收到该邮件的用户)。邮件头的说法和SMTP握手中的说法完全不同，而当用户(~realname@my.com~)收到此邮件时，他所能看到的只是邮件头中所声称的内容和发送该邮件所声称的机器名和IP。然而，要使用户realname收到这封邮件，除了SMTP握手中rcpt to必须是真实的以外，其他所有东西都可以伪造，From:和To:都可以不写。尤其不幸的是：为了返回错误提示邮件，SMTP协议甚至允许mail from:后面是空白。

上面data后的内容是真正的邮件，data之前的内容是SMTP握手，或称信封。用户收到的邮件已没有信封，但SMTP服务器可能会根据信封内容在data的信头部分增加Received数据保存一些信封的内容。

在邮件客户端，用户将看到邮件来自aaa@aaa.com，而回复时，自动将ccc@ccc.com作为目的地址。

上述邮件模拟发送过程中，只有收件人地址是真实的(呵呵，否则谁收啊？)；收到的邮件看到的源文件，只有最后一个发件IP是真实的(前面如果还有，也可能是伪造的)。

原文转自：http://www.ltesting.net