《CSNA网络分析认证专家实战案例》课件-第22章

第22章垃圾邮件行为分析22.1故障描述22.2分析过程22.3SMTP数据流解码分析22.4案例总结

22.1.1故障背景

科来回溯分析系统3.1版增加了很多新功能，丰富的实时警报功能就是其中之一，这与3.0版相比可以说是一次质的飞跃。新版的警报功能可以基于字节数、数据包数量、平均包长、TCP特征统计等流量统计信息设置警报，还可以设置邮件敏感字、可疑域名检测以及报文特征值的警报。利用这些灵活的警报功能可以让网管人员及时发现各种故障和安全隐患。22.1故障描述本章就是一个利用科来回溯分析系统3.1版流量警报功能发现内网主机发送垃圾邮件的实例。22.1.2故障环境

本文的网络环境是一家中国教育网用户的网络，内网使用公有IP地址，在其互联网出口部署科来回溯分析服务器，7

×

24小时捕获互联网出入站流量。由于内网使用公有IP地址没有做NAT(NetworkAddressTranslation，网络地址转换)，因此内网主机会直接面对来自互联网的各种威胁，端口扫描就是其中较常见的行为之一。为了及时监测端口扫描的行为，我们在分析服务器上设置了旨在发现特定端口的主机扫描行为的警报，如图22-1所示。

图22-1科来回溯分析系统3.1版可以灵活地利用与或逻辑关系设置复杂的警报触发条件。对于监测网络中任意应用，如果某应用1秒钟内数据包数量超过100个，并且平均包长小于72B，便触发警报。

通常来自互联网的主机扫描会针对特定的服务端口(如MSSQL1433端口)，短时间内向一个网段内每个IP发送连接请求，如果发现某主机有TCP同步确认回应，则与该主机建立TCP连接，而后进一步尝试漏洞攻击或弱口令尝试。由于TCP同步包和同步确认包都没有上层数据，因此这种主机扫描行为的数据包都很小，一般不会超过72B。设置这个警报的初衷虽然是发现主机扫描行为，但是在实际使用时意外地发现某台内网主机在发送垃圾邮件时触发了这个警报。

22.2.1主机扫描警报的基本效果

在设置案例中的主机扫描警报之前，我们要发现主机扫描行为通常是在“TCP分析”趋势图中找TCP同步包的异常峰值，但是如果是在流量较大的网络中，短短1～3秒的主机扫描行为所触发的TCP同步包增加往往会被忽略。例如案例中的网络工作时段，TCP同步包量在每秒400～600个之间，偶尔每秒增加100个并不是非常明显，因而很多主机扫描行为没有被及时发现。22.2分析过程在设置了案例中的警报之后，我们可以在控制台的趋势图中直观地看到每一次主机扫描的警报，同时在“警报日志”视图看到主机扫描所针对的应用服务，甚至不用切换到“TCP分析”趋势图，如图22-2所示。

图22-2从图22-2中可以看到，选中时段内有两次针对MSSQL应用的疑似主机扫描行为。3.1系统还增加了针对选中对象的分析功能(如选中某应用或某IP地址)，在这里我们选中其中某警报日志条目，点击鼠标右键，选择“分析”菜单项，就可以针对选中时段的MSSQL应用进行单独分析，这样可以快速判断警报是否误报，如图22-3所示。

图22-3从图22-3中可以看出，警报发生的时段，某外网IP在短时间内尝试与内网所有主机的TCP1433端口建立连接，由于内网主机都没有安装SQLServer，所以每个连接请求都没有得到应答，每个会话都只有1个数据包。可以断定这个外网IP在做全网段的MSSQL服务主机扫描。

在案例的网络中，我们利用这个自定义的主机扫描警报发现了大量的类似主机扫描行为。这些行为的共同特点是发生时间很短(整个扫描过程一般在3秒内完成)，一次扫描会触发1～3次警报。扫描针对的应用主要集中在MSSQL、MySQL、Oracle等数据库端口以及CIFS、NetBios等共享端口，通常这些端口会容易受到漏洞攻击或弱口令攻击。这些行为在使用3.1版本之前需要非常仔细的观察和分析才能发现，现在我们可以及时地发现，并在边缘设备上针对这些扫描的端口或IP地址进行过滤，避免更大的安全问题发生。22.2.2意外的SMTP主机扫描警报

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

这次意外事件在1分多钟的时间里触发了56次主机扫描警报，这明显与其他时段发生的主机扫描行为有区别。通常主机扫描者不会针对一个应用端口持续很长时间的反复扫描。一般情况下，针对SMTP端口的SYNFlood攻击才有可能持续触发我们定制的主机扫描警报，然而这种SYNFlood攻击往往会在“TCP分析”趋势图上看到明显的TCP同步包数量增加，而从图22-4的“TCP分析”趋势图上却看不到这一现象。为了进一步分析判断这一事件的原因，我们使用3.1系统的应用统计分析功能，对这一时段的SMTP会话进行了统计分析。

图22-422.2.3SMTP会话统计分析

从图22-5所示的流量趋势图上明显看到，SMTP流量在警报发生的时段内有明显增加，最大流量超过150kbps。在“TCP会话”视图中我们看到，一个内网IP在短时间内与若干个外网IP的TCP25端口建立了很多TCP会话，这些会话并不像主机扫描行为那样只有很少量的数据包，而是每个会话有几个到几十个不等(截图中碰巧都是11个数据包)。

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

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

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

从数据流信息中我们看到，1这个外网IP有可能是21CN的邮件服务器，触发警报的内网IP在尝试向21的某个不存在的用户发送邮件，21CN的邮件服务器拒绝了这次邮件发送，如图22-6所示。22.3SMTP数据流解码分析

图22-6继续查看其他与21CN的TCP会话，发现每个会话的发件人都是“tyco110@163.com”，收件人邮箱地址在不断变化，每个会话的收件人都不相同，但邮件后缀都是“@12”，说明这个内网IP主机的邮件发送程序并不知道收件人的真实信息，而是在不断变换邮件前缀尝试向21CN的用户发送邮件，如图22-7所示。

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

在该内网IP与其他外网IP的SMTP会话中，我们看到了与21CN的会话相似的行为，这些外网IP包括“263.net”、“126.com”、“世纪互联”等多家邮件服务提供商或IDC的邮件服务器地址，还包括一些中小型ICP的邮件服务器地址。在下载的全部4000多个SMTP会话中，成功发送邮件的会话不到10个。看来这个垃圾邮件发送程序的效率并不是很高，或者是内置的用户列表已经过时了。在几个成功发送的邮件会话中我们可以看到明显的垃圾邮件内容，如图22-8所示。

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

通过这个案例的分析过程，我们可以总结以下几点经验：

(1)科来回溯分析系统3.1版强化的警报功能可以更加灵活地用来及时发现多种故障隐患和安全隐患，例如可以更加方便地发现主机扫描行为。22.4案例总结

(2)警报功能本质上是模式比对，这一点与IDS的警报相似，由于存在行为模式相似的网络行为，这会使得精心设计的警报出现误报(包括IDS警报)。与IDS等常规安全管理产品相比，回溯分析系统的优势在于可以对每一次警报进行深入的挖掘和分析，以验证警报的真实性，避免误报或漏报对网络管理带来的影响。

(3)在遇到警报出现频率有明显变化的时候，对警报相关的流量进行深入分析，