垃圾邮件行为分析

垃圾邮件行为分析
科来回溯分析系统最新的3.1版增加了很多新功能，丰富的实时警报功能就是其中之一。

3.1版的实时警报功能与3.0版相比可以说是一次质的飞跃，新版的警报功能即可以基于字节数、数据包数量、平均包长、TCP特征统计等流量统计信息设置警报，还可以设置邮件敏感字、可疑域名检测以及报文特征值的警报。

利用这些灵活的警报功能可以让网管人员及时发现各种故障和安全隐患。

本文就是一个利用科来回溯分析系统3.1版流量警报功能发现内网主机发送垃圾邮件的实例。

背景介绍
本文的网络环境是一家中国教育网用户的网络，内网使用公有IP地址，在其互联网出口部署科来回溯分析服务器，7*24小时捕获互联网入出站流量。

由于内网使用公有IP地址没有做NAT，因此内网主机会直接面对来自互联网的各种威胁，端口扫描就是其中较常见的行为之一。

为了及时监测端口扫描的行为，我们在分析服务器上设置了旨在发现特定端口的主机扫描行为的警报，如下图。

科来回溯分析系统3.1版可以灵活的利用与或逻辑关系设置复杂的警报触发条件。

这个警报就是监测网络中任意应用，如果某应用1秒钟内数据包数量超过100个，并且平均包长小于72字节则触发警报。

通常来自互联网主机扫描会针对特定服务端口（如MSSQL 1433端口），短时间内向一个网段内每个IP发送连接请求，如果发现有某主机有TCP同步确认回应则与该主机建立TCP连接，而后进一步尝试漏洞攻击或弱口令尝试。

由于TCP同步包和同步确认包都没有上层数据，因此这种主机扫描行为的数据包都很小，一般不会超过72字节。

设置这个警报的初衷虽然是发现主机扫描行为，但是在实际使用时意外的发现某台内网主机在发送垃圾邮件时触发了这个警报。

1.1.主机扫描警报的基本效果
在设置案例中的主机扫描警报之前，我们要发现主机扫描行为通常是在“TCP分析”趋势图中找TCP同步包的异常峰值，但是如果流量较大的网络中短短1~3秒的主机扫描行为所触发的TCP同步包增加往往会被忽略。

例如案例中的网络工作时段TCP同步包量在每秒400~600之间，偶尔每秒增加100个并不是非常明显，因而很多主机扫描行为没有被及时发现。

在设置了案例中的警报之后，我们可以在控制台的趋势图中直观的看到每一次主机扫描的警报，同时在警报日志视图看到主机扫描所针对的应用服务，甚至不用切换到“TCP分析”趋势图，如下图所示。

从上图中可以看到选中时段内有两次针对MSSQL应用的疑似主机扫描行为。

3.1系统还增加了针对选中对象的分析功能（如选中某应用或某IP地址），在这里我们选中其中某警报日志条目，点击鼠标右键，选择“分析”菜单项，就可以针对选中时段的MSSQL 应用进行单独分析，这样可以快速判断警报是否误报，如下图。

从上图中可以看出，警报发生的时段某外网IP在短时间内尝试与内网所有主机的TCP 1433端口建立连接，由于内网主机都没有安装SQL Server，所以每个连接请求都没有得到应答，每个会话都只有1个数据包。

可以断定这个外网IP在做全网段的MSSQL 服务主机扫描。

在案例中的网络中，我们利用这个自定义的主机扫描警报发现了大量的类似主机扫描行为。

这些行为的共同特点是发生时间很短（整个扫描过程一般在3秒内完成），一次扫描会触发1~3次警报。

扫描针对的应用主要集中在MSSQL、MySQL、Oracle等数据库端口以及CIFS、NetBios等共享端口，通常这些端口会容易受到漏洞攻击或弱口令攻击。

这些行为在使用3.1版本之前需要非常仔细的观察和分析才能发现，现在我们可以及时的发现并在边缘设备上针对这些扫描的端口或IP地址进行过滤，避免更大的安全问题发生。

1.2.意外的SMTP主机扫描警报
在配置了自定义主机扫描警报之后，偶然发现某个时段有大量的针对SMTP应用的主机扫描报警，报警的频繁程度明显超过了其他的主机扫描行为。

这次意外事件在1分多种的时间里触发了56次主机扫描警报，这明显与其他时段发生的主机扫描行为有区别。

通常主机扫描者不会针对一个应用端口持续很长时间反复扫描。

一般情况下，针对SMTP端口的SYN flood攻击才有可能持续触发我们定制的主机扫描警报，然而这种SYN flood攻击往往会在“TCP分析”趋势图上看到明显的TCP 同步包数量增加，而从上图的“TCP分析”趋势图上却看不到这一现象。

为了进一步分析判断这一事件的原因，我们使用3.1系统的应用统计分析功能，对这一时段的SMTP会话进行了统计分析。

1.3.SMTP会话统计分析
从上图中的流量趋势图上明显看到SMTP流量在警报发生的时段内有明显增加，最大流量超过150Kbps；在TCP会话视图中，我们看到一个内网IP在短时间内与若干个外网IP的TCP 25端口建立了很多TCP会话，这些会话并不像主机扫描行为那样只有很少量的数据包，而是每个会话有几个到几十个不等（截图中碰巧都是11个数据包）。

至此基本排除了这些警报是主机扫描行为的可能性，但可以判断这些TCP会话不是正常的邮件发送，因为正常的邮件发送不会产生如此多的会话，而且正常邮件发送的平均数据包长度不会小于72字节。

要了解些异常会话的真正作用，就需要对这些会话进行数据包级解码分析，于是我们将这一时段的SMTP应用的数据包下载到控制台，利用控制台自带的科来网络分析模块进行解码分析。

1.4.SMTP数据流解码分析
下载SMTP数据包后，定位到“TCP会话”视图，并且选中某个会话，查看其“数据流”信息，能够完整展现一个TCP会话的应用层数据交互信息。

从数据流信息中我们看到59.36.102.51这个外网IP有可能是21CN的邮件服务器，触发警报的内网IP在尝试向的某个不存在的用户发送邮件，21CN的邮件服务器拒绝了这次邮件发送。

继续查看其他与21CN的TCP会话，发现每个会话的发件人都是“tyco110@”，收件人邮箱地址在不断变化，每个会话的收件人都不相同但邮件后缀都是“@”。

说明这个内网IP的主机的邮件发送程序并不知道收件人的真实信息，而是在不断变换邮件前缀尝试向21CN的用户发送邮件。

由于该内网IP在短时间内向21CN的邮件服务器发起了大量SMTP会话，一段时间后21CN的邮件服务器拒绝了该IP的邮件发送请求。

在该内网IP与其他外网IP的SMTP会话中，我们看到了与21CN的会话相似的行为，这些外网IP包括“”、“”、“世纪互联”等多家邮件服务提供商或IDC 的邮件服务器地址，还包括一些中小型ICP的邮件服务器地址。

在下载的全部4000多个SMTP会话中，成功发送邮件的会话不到10个，看来这个垃圾邮件发送程序的效率并不是很高，或者是内置的用户列表已经过时了。

在几个成功发送的邮件会话中我们可以看到明显的垃圾邮件内容，如下图。

至此，我们可以确定一系列的SMTP主机扫描警报是这个持续的效率不是很高的垃圾邮件发送行为引起的。

1.5.案例总结
通过这个案例的分析过程，我们可以总结一下几点经验：
科来回溯分析系统3.1版强化的警报功能可以更加灵活的用来及时发现多种故障隐患和安全隐患，例如可以更加方便的发现主机扫描行为；
警报功能本质上是模式比对，这一点与IDS的警报相似，由于存在行为模式相似的网络行为，这会使得精心设计警报出现误报（包括IDS警报）。

与IDS等常规安全管理产品相比回溯分析系统的优势在于可以对每一次警报进行深入挖掘和分析，以验证警报的真实性，避免误报或漏报对网络管理带来的影响。

尤其是在遇到警报出现频率有明显变化时，对警报相关的流量进行深入分析，往往能够及时发现安全或故障隐患。

在数据包解码分析过程中，我们发现不同的邮件服务器对此次垃圾邮件的处理方式也不尽相同，有些邮件服务器由于配置了SPF（Sender Policy Framework）能够在发送方提交发送者邮件地址时对其IP有效性进行验证，从而更及时的阻止垃圾邮件发送行为，减小这些行为对其邮件服务器带来的性能影响，如下图。