接上《详解TCP/IP协议栈面临的五大网络安全问题（一）》

（2）地址状态监控的解决方法

地址状态监控的解决方法是利用监控工具对网络中的有关TCP连接的数据包进行监控，并对监听到的数据包进行处理。处理的主要依据是连接请求的源地址。

每个源地址都有一个状态与之对应，总共有四种状态：

· 初态：任何源地址刚开始的状态；
· NEW状态：第一次出现或出现多次也不能断定存在的源地址的状态；
· GOOD状态：断定存在的源地址所处的状态；
· BAD状态：源地址不存在或不可达时所处的状态。

具体的动作和状态转换根据TCP头中的位码值决定。

① 监听到SYN包，如果源地址是第一次出现，则置该源地址的状态为NEW状态；如果是NEW状态或BAD状态；则将该包的RST位置1然后重新发出去，如果是GOOD状态不作任何处理。
② 监听到ACK或RST包，如果源地址的状态为NEW状态，则转为GOOD状态；如果是GOOD状态则不变；如果是BAD状态则转为NEW状态；如果是BAD状态则转为NEW状态。
③ 监听到从服务器来的SYN ACK报文（目的地址为addr），表明服务器已经为从addr发来的连接请求建立了一个半连接，为防止建立的半连接过多，向服务器发送一个ACK包，建立连接，同时，开始计时，如果超时，还未收到ACK报文，证明addr不可达，如果此时addr的状态为GOOD则转为NEW状态；如果addr的状态为NEW状态则转为BAD状态；如果为addr的状态为BAD状态则不变。

地址状态的转换图如图2所示。

图2  地址状态转换图

下面分析一下基于地址状态监控的方法如何能够防御SYN Flooding攻击。

对于一个伪造源地址的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，当监听到服务器的SYN+ACK报文，表明服务器已经为该源地址的连接请求建立了半连接。此时，监控程序代源地址发送一个ACK报文完成连接。这样，半连接队列中的半连接数不是很多。计时器开始计时，由于源地址是伪造的，所以不会收到ACK报文，超时后，监控程序发送RST数据包，服务器释放该连接，该源地址的状态转为BAD状态。之后，对于每一个来自该源地址的SYN报文，监控程序都会主动发送一个RST报文。

对于一个合法的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，服务器响应请求，发送SYN＋ACK报文，监控程序发送ACK报文，连接建立完毕。之后，来自客户端的ACK很快会到达，该源地址的状态转为GOOD状态。服务器可以很好地处理重复到达的ACK包。

3. ACK Flooding

ACK Flooding攻击是在TCP连接建立之后，所有的数据传输TCP报文都是带有ACK标志位的，主机在接收到一个带有ACK标志位的数据包的时候，需要检查该数据包所表示的连接四元组是否存在，如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包。如果在检查中发现该数据包不合法，例如该数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应RST包告诉对方此端口不存在。

这里，服务器要做两个动作：查表、回应ACK/RST。这种攻击方式显然没有SYN Flooding给服务器带来的冲击大，因此攻击者一定要用大流量ACK小包冲击才会对服务器造成影响。按照我们对TCP协议的理解，随机源IP的ACK小包应该会被Server很快丢弃，因为在服务器的TCP堆栈中没有这些ACK包的状态信息。但是实际上通过测试，发现有一些TCP服务会对ACK Flooding比较敏感，比如说JSP Server，在数量并不多的ACK小包的打击下，JSP Server就很难处理正常的连接请求。对于Apache或者IIS来说，10kbps的ACK Flooding不会构成危胁，但是更高数量的ACK Flooding会造成服务器网卡中断频率过高，负载过重而停止响应。可以肯定的是，ACK Flooding不但可以危害路由器等网络设备，而且对服务器上的应用有不小的影响。

如果没有开放端口，服务器将直接丢弃，这将会耗费服务器的CPU资源。如果端口开放，服务器回应RST。

利用对称性判断来分析出是否有攻击存在。所谓对称性判断，就是收包异常大于发包，因为攻击者通常会采用大量ACK包，并且为了提高攻击速度，一般采用内容基本一致的小包发送。这可以作为判断是否发生ACK Flooding的依据，但是目前已知情况来看，很少有单纯使用ACK Flooding攻击，通常都会和其他攻击方法混合使用，因此，很容易产生误判。

一些防火墙应对的方法是：建立一个hash表，用来存放TCP连接“状态”，相对于主机的TCP协议栈实现来说，状态检查的过程相对简化。例如，不作sequence number的检查，不作包乱序的处理，只是统计一定时间内是否有ACK包在该“连接”（即四元组）上通过，从而“大致”确定该“连接”是否是“活动的”。

4. UDP Flooding

UDP Flooding是日渐猖厥的流量型DoS攻击，原理也很简单。常见的情况是利用大量UDP小包冲击DNS服务器，或Radius认证服务器、流媒体视频服务器。100kbps的UDP Flooding经常将线路上的骨干设备例如防火墙打瘫，造成整个网段的瘫痪。由于UDP协议是一种无连接的服务，在UDP Flooding攻击中，攻击者可发送大量伪造源IP地址的小UDP包。但是，由于UDP协议是无连接性的，所以只要开了一个UDP的端口提供相关服务的话，那么就可针对相关的服务进行攻击。

正常应用情况下，UDP包双向流量会基本相等，而且大小和内容都是随机的，变化很大。出现UDP Flooding的情况下，针对同一目标IP的UDP包在一侧大量出现，并且内容和大小都比较固定。

UDP协议与TCP 协议不同，是无连接状态的协议，并且UDP应用协议五花八门，差异极大，因此针对UDP Flooding的防护非常困难。其防护要根据具体情况对待。

· 判断包大小：如果是大包攻击则使用防止UDP碎片方法。根据攻击包大小设定包碎片重组大小，通常不小于1500。在极端情况下，可以考虑丢弃所有UDP碎片。
· 攻击端口为业务端口：根据该业务UDP最大包的长度设置检测UDP最大包以过滤异常流量。
· 攻击端口为非业务端口：一个是丢弃所有UDP包，可能会误伤正常业务；另一个是建立UDP连接规则，要求所有去往该端口的UDP包，必须首先与TCP端口建立TCP连接。不过这种方法需要很专业的防火墙或其他防护设备支持。

在网络的关键之处使用防火墙对来源不明的有害数据进行过滤，可以有效减轻UDP Flooding攻击。此外，在用户的网络中还应采取如下的措施。

· 禁用或过滤监控和响应服务。

· 禁用或过滤其他的 UDP 服务。

· 如果用户必须提供一些 UDP 服务的外部访问，那么需要使用代理机制来保护那种服务，保证它不会被滥用。

· 对用户的网络进行监控以了解哪些系统在使用这些服务，并对滥用的迹象进行监控。

· 对于一些小型的服务器，可以直接用防火墙添加规则的方法屏蔽掉。

5. Connection Flooding

Connection Flooding是典型的并且非常的有效的利用小流量冲击大带宽网络服务的攻击方式，这种攻击方式目前已经越来越猖獗。这种攻击的原理是利用真实的IP地址向服务器发起大量的连接，并且建立连接之后很长时间不释放，占用服务器的资源，造成服务器上残余连接（WAIT状态）过多，效率降低，甚至资源耗尽，无法响应其他客户所发起的连接。

其中一种攻击方法是每秒钟向服务器发起大量的连接请求，这类似于固定源IP的SYN Flooding攻击，不同的是采用了真实的源IP地址。通常这可以在防火墙上限制每个源IP地址每秒钟的连接数来达到防护目的。但现在已有工具采用慢速连接的方式，也即几秒钟才和服务器建立一个连接，连接建立成功之后并不释放并定时发送垃圾数据包给服务器使连接得以长时间保持。这样一个IP地址就可以和服务器建立成百上千的连接，而服务器可以承受的连接数是有限的，这就达到了拒绝服务的效果。

另外，蠕虫大规模爆发的时候，由于蠕虫代码比较简单，传播过程中会出现大量源IP地址相同的包，对于 TCP 蠕虫，则表现为大范围扫描行为。这是在判断Connection Flooding时需要注意的。
该攻击的一般表现形式是：在受攻击的服务器上使用netstat –an命令来查看，会发现大量连接状态来自少数的几个源。如果统计的话，可以看到连接数对比平时出现异常。并且增长到某一阈值之后开始波动，说明此时可能已经接近性能极限。因此，对这种攻击的判断原则为：在流量上体现并不大，甚至可能会很小；出现大量的ESTABLISH状态；新建的ESTABLISH状态总数有波动。
防范该攻击主要有如下方法。

· 主动清除残余连接。
· 对恶意连接的IP进行封禁。
· 限制每个源IP的连接数。
· 可以对特定的URL进行防护。
· 反查Proxy后面发起HTTP Get Flood的源。