使用Omnipeek分析SSH端口攻击案例

2012-10-07 · 网络分析 · 网络安全 · 19549 次阅读

在某用户网络环境下发现攻击的实例，为了让大家对omnipeek有个初步直观的了解，此次我使用omnipeek作为分析的工具。

1，我们使用omnipeek打开数据包文件，通过omnipeek的“统计”功能，我们发现，在1分47秒的时间内，共产生了近119万个数据包，如下图所示：

并且绝大部分都是小于127字节的小包，这是基本上可以判断网内存在明显的异常发包行为。

2，我们再看omnipeek的“IP Analysis”的统计情况，如下图：

TCP SYN报文 25631个，TCP RST报文19247个，这说明基本上绝大部分的SYN连接都被RST了，网内可能存在基于TCP的大规模的扫描行为；

3，我们在查看omnipeek的“节点”统计功能，通过“总字节”参数排序，如下图所示：

我们可以清楚的看到绝大部分的流量和数据包都来自于排名前三的IP地址。并且这三个IP地址的发送数据包个数和接收数据包个数都非常巨大。

4，我们可以通告“过滤器”功能来看一下排名第一的IP交互的具体情况，
我们在omnipeek的“专家-层次”功能界面，使用排序功能，针对服务器地址进行排序，如下图所示：

我们可以明显的看到IP地址为X.X.28.134的主机与68.120.23.0-68.120.236.0网段的大量主机进行了交互，我们查看其交互的报文，如下图所示：

发现其都是向68.120.23.0-68.120.236.0网段主机的SSH 应用TCP 22端口发送SYN报文。

由此可得出结论：
主机X.X.28.134在针对68.120.23.0-68.120.236.0网段进行大规模的SSH端口扫描行为（实际的扫描网段范围很可能更大，因为我们抓包的时间有限，只有1分47秒）。

与此同时的ACK flood攻击

我们在分析的过程中还发现，与X.X.28.134与 68.71.59.244与68.71.59.247两个IP之间存在巨大的交互报文，如下图所示：

为什么这两个IP与扫描主机交互的报文如此巨大？我们来具体的看一下这两个IP与扫描主机之间交互的报文：

这两个IP向扫描主机发送数量巨大的ACK报文（无应用数据，SYN/FIN标志位未置一的报文）。
扫描主机在收到这些ACK报文后的处理方式如下图所示：

扫描主机向68.71.59.244的SSH端口发送RST报文。

我们来看一下具体 的ACK报文解码和RST报文解码，先看ACK报文的，如下图所示：

仅ACK标志位置一，源主机IP为68.71.59.247，端口为SSH的22端口，针对X.X.28.134主机的60502端口。

我们再看看“数据包”视图：

在极短的时间间隔内，同一个TCP会话中，68.71.59.247向X.X.28.134发送大量的ACK报文，这些ACK报文的序列号、确认号等信息完全一致，IP标识逐步递增，这些足以说明这些ACK报文不是简单的快速重传报文，也不是在网内被不断重复捕获的同一数据报文。
我们再看一下X.X.28.134对这些ACK报文回应的RST报文的解码，如下图所示：

RST标志位置一，ACK Number为0，说明该连接并不在X.X.28.134的连接表中，或者X.X.28.134并未开放60502端口。

难道这就是传说的“ACK flood”攻击吗 ？

忽然想起数年前，我在组织内部培训时，小鲍似乎在准备某个攻击话题时，提到ACK Flood攻击，记得当时我反问小鲍，实施这种攻击的意义何在？它不会像SYN flood攻击那样对防火墙、目的主机造成非常明显的资源消耗的影响，如果有人使用ACK Flood攻击目标主机并不会获得良好的拒绝服务效果，并且固执的认为这种攻击应该不会有人会用的。但是看到这个报文并分析至此，我不得不收回我以前的话，并承认我们遇到的的确就是一个ACK Flood攻击！

源主机在针对大网段扫描SSH端口，同时被来自互联网的其他两个IP针对其执行扫描的源端口发送大量的ACK报文，实施ACK flood攻击？这是为什么呢？难道是源主机扫描攻击别人，被别人发现，别人就来个复仇计划，用两台高性能服务器对其发其反击？

真实用户网络环境的各种凌乱，若非亲见，又怎会相信。