编者按：某金融公司突遭ISP投诉：说该用户正在大量发送垃圾邮件，事关重大，该金融公司的网络工程师展开了追查垃圾邮件发送源行动……

事件描述：某金融公司被告发送垃圾邮件
锁定嫌疑范围：员工作乱？还是病毒搞鬼？
走入死路？重新从协议细节入手
水落石出：垃圾邮件免费转发代理是原凶

    事件描述：某金融公司被告发送垃圾邮件

    故障现象：某金融公司拥有Internet链路，但是遭到ISP投诉说该用户正在大量发送垃圾邮件
    详细描述：

 某金融用户拥有Internet专线，然而最近内部通过这条专线访问Internet速度持续下降，内网经过监测似乎一切正常。最近更是进一步被ISP警告，ISP警告曾经数次遭到国外抗议信提及这个金融用户的网关IP地址正在不断向外发送垃圾邮件。 该金融用户的网络管理人员仔细检查了内部用户主机，并没有发现垃圾邮件发送源，而Internet链路上也已经部署某知名品牌的垃圾邮件/病毒邮件过滤设备，但这一问题不断恶化。

   用户经过较长时间诊断未果，因此寻求协议分析人员支持，寻找可能发送垃圾邮件的内部人员或内部主机。

锁定嫌疑范围：员工作乱？还是病毒搞鬼？

　　协议分析人员到达现场，了解基本状况后，初步经验性问题判断为：
　　
1）内部员工故意作乱，但是由于在网管人员检查的时候停止发送垃圾电子邮件，因此网管人员无法检查出这个问题。
 2）某种病毒感染内网用户，造成局部/定时垃圾邮件传输
    3）其他非常见性原因

   需要获取的进一步信息是，1) Internet链路通讯情况  2) 内网用户通讯情况 
   用户互联网连接拓扑比较简单：内部用户不能直接穿越网关，所有用户通过边界代理服务器进行互联网连接， 代理服务器主要提供HTTP服务的通道。
  
 采用OmniPeek连接Internet链路进行捕获分析，发现所有流量状况比较普通，没有特异现象。
图1：

 我们对Internet链路上的SMTP协议通讯进行捕获，过滤出一个单独邮件通讯以后，我们看到：
图2：

    
     发件人和收件人都不是这个用户的域名范围之内，而且尤其奇怪的是，这些垃圾邮件并非从Internet流入用户网络，反而是从用户网关（代理服务器）10.99.1.4往互联网地址进行传输。因为事先确认了代理服务器不对任何外部用户开放SMTP 25端口服务，所以似乎只可能是内部用户正在向外发送垃圾邮件。
    
     但是用户网络管理人员提出，所有内部用户邮件传输均必须通过内部邮件服务器发送，并不能直接通过代理服务器，仅仅邮件服务器能够直接对外以SMTP方式连接，同时基于之前用户排除故障过程中特别加入了防中继保护和内部用户发件人地址身份的限制，内部邮件服务器也不会发送发件人非本域名的邮件。经过协议分析人员现场的分析检验，实际情况确实如此。
    
     那么这些垃圾邮件的来源就成了奇怪的现象，既不能从外部进入SMTP，也不会从内部出去不合法的SMTP，代理服务器自身经过病毒/进程检查也没有任何问题。那么这封垃圾邮件源头到底是在哪里呢？
    

     走入死路？重新从协议细节入手
    
     问题似乎走入了死路。由于一时没有了头绪，于是决定从协议细节入手理解这个问题。
    
     从协议通讯角度而言，由于用户使用的是代理服务器，那么所有起始建立的通讯要么通过类似透明的方式被代理服务器进行中转，要么就要用一条显式的指令（应用代理）进行指向，或者用特别组合的协议包（Socks代理）进行指向。针对此用户使用的应用代理的特点，那么任何代理服务器起始建立的连接通讯都会有另外的连接去指定它发起这个连接。
    
     言下之意就是如果排除掉这条发送垃圾邮件的SMTP连接本身，一定应该有另外的连接中包含了对象连接的目标地址信息，以便指令代理服务器发起这条连接。那么究竟谁指令发起了那个SMTP连接呢？
    
     很简单，我们把捕获下来的内容中排除那条SMTP的所有数据，然后再进行查找，查找的目标内容就是那条SMTP连接的目标IP地址。
    
　　查找之前SMTP连接的目标IP 198.185.2.67（按照ASCII方式查找），获得以下结果：
　　图3：

让我们仔细看看这个包，这居然是个HTTP包，发送的HTTP内容为
“CONNECT 192.185.2.67:25 HTTP/1.0”

哦，事实恍然若现，CONNECT是HTTP Proxy协议中用来指令代理服务器发起向目标连接的命令，但是不一般的是，这个HTTP Proxy请求是发送到某台主机的25端口！

接下来进一步的情况是怎么样呢？
利用OmniPeek的Visual Expert中的应用负载分析功能，
图4：

　　水落石出：垃圾邮件免费转发代理是原凶
　　
　　
　　顿时可以发现，原来事实如此，这个特殊构造的HTTP连接通过用户的HTTP Proxy直接下达Connect命令连接受害主机的25（SMTP）端口，然后在这个伪HTTP Proxy连接中继续发送SMTP命令，完成验证、发送邮件。代理服务器天真地认为这个连接是通过其代理到一个运行在25端口的远程HTTP服务器上，因此非常尽职地在两端转发响应数据。结果这个发起连接的垃圾邮件发送端通过与代理服务器的80?端口伪HTTP Proxy连接，间接的发送了这封邮件。
　　
　　如果我们在最终的邮件服务器上看待整个过程，会误以为该金融用户的代理服务器的IP是一个邮件的客户端，正在连接上来发送邮件，而且发送的又正是垃圾邮件，因此该无辜邮件服务器的管理员会投诉代理服务器IP地址所属的ISP，并可能直接封锁来自于这个IP的通讯。
　　
起始连接部分示意图如下：
图5：

   这个垃圾邮件发送端A既找到了一个免费的转发代理，又针对目标邮件服务器隐藏了自身的IP地址。通过HTTP Proxy和SMTP协议的转换，达到了很隐蔽的使用效果。可以看得出来这个垃圾邮件发送端的设计者拥有深厚的协议分析背景，深入掌握了HTTP以及HTTP Proxy和SMTP协议。这种技术手段被Vader称为SMTP over HTTP。
  
   对于用户这里呢，这个代理服务软件也有一定的问题，没有预料到会被这样利用，而且也没有对HTTP协议命令做深入的合法性判别。
  
   这个问题到此已经水落石出，用户可以设置代理服务器禁止接受转发到远端的25端口的连接，也可以设置外部用户禁止连接HTTP 80端口的Proxy，只允许内部用户访问。这样都可以很好的临时处理这个问题。那为了更进一步深入杜绝此类问题的产生，可能还需要更换更加的代理软件系统或者向厂商提出这个问题要求从核心上进行修改，或者对代理服务器加入使用验证的要求。
  
   在协议分析人员到场大约1个半小时后，这个问题得到了确切的结果，并且得到了圆满的解决。