Question

在完成了 tcpdump 抓包和 Wireshark 的配置后，现在来看看如何使用这两个工具分析和定位问题。

案例一　定位时间戳问题

1.问题描述

公司近 2000 个员工电脑上网，少数 Windows 7 系统电脑不能访问自己公司的网站（ www.woyo.com ），有时重置一下 IE8 又可以访问几次；但同样环境下（同网络端口、同 IP 地址等）更换成 Windows XP 系统的机器即可访问。

2.抓包方法

在网站 Linux 服务器使用如下命令进行抓包：

tcpdump -i eth0 -nnn -s 0 -w tcpdump.pcap tcp port 80

其中，eth0 为外网网卡，指定抓取端口为 80 的数据通信。

3.分析方法

使用如下过滤器进行筛选：

tcp.analysis.retransmission or tcp.analysis.fast_retransmission or tcp.flags.reset == 1

如图 14-10 所示，可以看到来自客户端的请求在建立 TCP 三次握手时，服务器端没有应答 SYN+ACK，也就是说服务器端忽略了来自客户端的 SYN 包。

图 14-10　服务器忽略客户端 SYN 包

通过分析这一类数据包的特点，可以看到，在客户端发过来的 SYN 包中，含有类似 Timestamps：TSval 3598166009，TSecr 0 这样的 TCP 选项。这个是什么含义呢？

在 RFC 1323（ https://www.ietf.org/rfc/rfc1323.txt ）中，提出了 TCP 的扩展选项，来实现以下的目的。

- 提高高带宽延时积（bandwidth*delay）的性能。

- 增加极大传输速率链路的可靠性。

其中，“提高高带宽延时积（bandwidth*delay）的性能”使用到了以下两种技术。

- 窗口扩大选项（Window Scale）。默认 TCP 的窗口只有 2*16＝65KB，也就是最大只能一次性传输 65KB 的数据后，必须等待对端的确认。在高带宽延时积的链路上，这样会导致大量的时间等待，传输效率不高。通过窗口扩大选项，可以突破 65KB 的限制，此时得在计算对端窗口大小为对端宣告的窗口大小（字节）*2*Shift Count。

- 有选择的确认技术（Selective Acknowledgments）。这种机制，使得对端可以一次确认多个非连续的 TCP 接收片段。对于已确认的数据，不再进行发送；仅仅重新发送未确认部分即可。

“增加极大传输速率链路的可靠性”使用到了时间戳（Timestamps）选项。通过对每个 TCP 包加入时间戳，可以知道该次会话（TCP 连接）上的数据包是否是过期需要丢弃的。

通过以上分析，结合本次环境的因素如下。

- 大量用户（2000 台电脑）在一个 NAT 设备后面。

- 访问同一个网站（同一个目的 IP 和端口）。

- 不同用户的电脑，时间可能不一致，有的时间相对标准时间慢，有的时间相对标准时间快。

- Windows 7 用户经常出现问题（Windows 7 用过 Tcp1323Opts 注册表选项启用了窗口扩大选项和时间戳选项，Windows XP 中默认未启用）。

基本可以推断是不同大量用户经过 NAT 设备访问同一个网站时，如果 NAT 上端口重用了，而后一个用户的客户端时钟早于前一个用户的客户端时钟，那必然导致 Linux 服务器把 SYN 包丢掉，因为它认为后一个连接的请求（SYN）是在网络上前一个连接后达到的，需要丢弃。

4.解决方法

1）Linux 服务器检查，在/etc/sysctl.conf 文件中加入下列行（以便下次服务器重启生效）：

net.ipv4.tcp_timestamps = 0

同时在 shell 命令行中，以 root 身份运行：

sysctl -w net.ipv4.tcp_timestamps=0

上述代码用于即时生效该配置。

2）某些 Windows 7 系统客户端修改注册表中下面这个键值：

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters 的 cp1323Opts 值，将其改为 0（十进制）。注意，Windows XP 系统不存在这个键值。

修改后需重启机器。

案例二　定位非正常发包问题

1.问题描述

我们在查看一台虚拟机时，发现其带宽形态存在异常，如图 14-11 所示。

图 14-11　虚拟机带宽异常

从图 14-11 中可以看到以下问题。

- 该虚拟机的出流量带宽达到了给它限制的 100Mbps，而入流量带宽接近于零，出和入的比例非常大。

- 该虚拟机的出流量带宽一直维持在高位，没有任何变化。

通过以上两点的分析，我们怀疑这个虚拟机的网络行为存在异常。

2.抓包方法

在宿主机上，使用如下命令确认该虚拟机的名称：

# virsh list
 Id    Name                           State
----------------------------------------------------
 2     r2-6683                        running
 3     r2-5261                        running
 4     r2-4482                        running #确认是这个虚拟机
 5     r2-5388                        running
 6     r2-5255                        running
 7     r2-5969                        running
 8     r2-5171                        running

使用如下命令查看当前该虚拟机对应宿主机上的网卡（vnet9）：

# virsh dumpxml r2-4482
    <interface type='bridge'>
      <mac address='02:00:0a:2e:00:07'/>
      <source bridge='br3.2000'/>
      <target dev='vnet4'/>
      <model type='virtio'/>
      <filterref filter='clean-traffic'>
        <parameter name='IP' value='10.46.0.7'/>
      </filterref>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='02:00:75:79:27:0d'/>
      <source bridge='br0'/>
      <bandwidth>
        <inbound average='256' peak='256' burst='256'/>
        <outbound average='256' peak='256' burst='256'/>
      </bandwidth>
      <target dev='vnet9'/> #vnet9
      <model type='virtio'/>
      <filterref filter='r2-4482'>
        <parameter name='IP' value='xxx.yyy.39.13'/>
      </filterref>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </interface>

现在看 vnet9 的网络数据情况，如下所示：

# ifconfig vnet9
vnet9     Link encap:Ethernet  HWaddr FE:00:75:79:27:0D  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets: 352703579277 errors:0 dropped:0 overruns:0 frame:0
          TX packets:121474302 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:360385917234000 (327.7 TiB)  TX bytes:8432409427 (7.8 GiB)

我们注意到，vnet9 RX（接收）的数据包 352703579277 远远大于 TX（发送）的数据包 121474302（接收和发送比：352703579277/121474302=2903.5）。

使用如下命令，在宿主机上抓包，看看到底发生了什么：

# tcpdump -i vnet1 -nnn -c 50000 -s 0 -w r2-4482.pcap

3.分析方法

在获取了 r2-4482.pcap 后，使用 Wireshark 进行分析，如图 14-12 所示。

图 14-12　虚拟机非正常发包

可以看到这个虚拟机发出的前 10 个数据帧都是 SYN 包，有以下 2 个特点。

- SYN 包连续发送，间隔时间较短，不符合正常 TCP 重传的时间控制。

- SYN 包中包含了 970 个字节的数据，如所示。在正常 TCP 三次握手的 SYN 包中，不会携带任何数据。

通过进一步分析可以看到，所有 SYN 包中的 970 字节的内容完全相同，如图 14-13 所示。

图 14-13　非正常数据包内容

可以看到，这些非正常数据包的内容都是无意义的数字 0。由此可以推断，这个虚拟机是被用作了 SYN 携带数据的 DDOS 攻击源。

4.解决方法

通过联系该虚拟机的使用方，查到确实有一个程序，使用了构造的发包接口，大量发送攻击数据。我们安排用户果断停止了这样一个有安全风险的程序，然后进行相应的安全加固。