泛洪攻击以及防护方法

泛洪攻击种类：

SYN泛洪攻击。

   SYN攻击利用的是TCP的三次握手机制，攻击端利用伪造的IP地址向被攻击端发出请求，而被攻击端发出的响应报文将永远发送不到目的地，那么被攻击端在等待关闭这个连接的过程中消耗了资源，如果有成千上万的这种连接，主机资源将被耗尽，从而达到攻击的目的。我们可以利用路由器的TCP拦截功能，使网络上的主机受到保护(以Cisco路由器为例)。

DHCP报文泛洪攻击

DHCP报文泛洪攻击是指：恶意用户利用工具伪造大量DHCP报文发送到服务器，一方面恶意耗尽了IP资源，使得合法用户无法获得IP资源;另一方面,如果交换机上开启了DHCP Snooping功能，会将接收到的DHCP报文上送到CPU。因此大量的DHCP报文攻击设备会使DHCP服务器高负荷运行，甚至会导致设备瘫痪。

ARP报文泛洪攻击

ARP报文泛洪类似DHCP泛洪，同样是恶意用户发出大量的ARP报文，造成L3设备的ARP表项溢出，影响正常用户的转发

预防方法:（最好的预防措施是使用STCP协议链接）

http://baike.baidu.com/link?url=5rUPIMpUzdkML74mO8FqYycd8NycnyAtsWwK53eUOpkLbypO6HHs8cyqfrgK4CwCiDg6mdOgVKtn3U6gsEmfha）

对于预防SYN洪泛攻击措施如下：

1增加TCP backlog队列

由于其基本攻击原理是依赖于终端主机连接套接字的backlog溢出，因此一个显然的基于终端主机的解决方案是增加backlog队列大小，而且这种方法已经广泛的运用于大多数服务器了。增加backlog队列通常是通过修改应用的listen()函数调用和一个操作系统内核参数SOMAXCONN——它用于设置一个应用程序能够接收的backlog上限值。这种方法本身并不能被完全认为是抵御SYN洪泛的有效方法，即使在一些能够有效支持超大backlog队列分配的操作系统中，因为攻击者能够任意生成比其操作系统支持的backlog还大得多的数据报。

2减少SYN-RECEIVED的时间

另一个基于终端主机的解决方法是缩短一个TCB从进入SYN-RECEIVED状态到因未进入下一个状态而被回收之间的时间。但这个方案的一个明显缺点是攻击可以利用因拥塞而丢包的ACK-SYN或者握手完成的ACK包，这样合法连接的TCB就会由于主机忙于重传这些包(因为SYN-RECEIVED时间减少)而被回收。此外，在管理员减少SYN-RECEIVED状态时间多少和攻击者的发包率之间仅仅是一个线性关系而已。基于上述原因，此方案并不建议采用。

3 SYN缓存

另外两种方案是基于SYN缓存和SYN cookies(见6.4)的，简化因接收SYN而生成TCB时初始化的状态，推迟全状态的实例化[4]。在采用SYN缓存的主机中，一个带有被限制大小的HASH表空间被用于存放那些将被分配给TCB的数据的一个子集。如果当握手完成的ACK接收到了，这些数据将被复制到一个完整的TCB中，否则超出存活时间的HASH值将会在需要时被回收。在Lemon的FreeBSD中，对于一个半开连接的SYN缓存是160字节，而一个完整的TCB是736字节，并且支持15359个SYN缓存空间。

SYN缓存的数据结构对于那些试图让HASH表空间溢出的攻击者是健壮的。因为在其HASH值里面包含了对方的端口号和一些密码比特。由于堆栈相对于链表是一种更加高效的数据结构，因此堆栈被用于SYN缓存以提高速度。在Lemon的测试中，处于活跃攻击下的主机用SYN缓存能够建立连接且仅仅比正常时间延缓了15%的时间。

4 SYN Cookies

对比SYN缓存的方法，SYN Cookies技术做到了接收到一个SYN时完全不需要分配空间。因为构成连接状态的最基本数据都被编码压缩进SYN-ACK的序列号比特位里了。对于一个合法连接，服务器将收到一个带有序列号(其实序列号已经加1)的ACK报文段，然后基本的TCB数据将被重新生成，一个完整的TCB通过解压确认数据将被安全的实例化。这种解压即使在重度攻击下仍然能够成功，因为在主机端根本没有任何存储负载，只有计算编码数据到ACK序列号中的负载。其不足之处就是，不是所有的TCB数据都能添加到32位的序列号段中，所以一些高性能要求的TCP选项将不能被编码。其另一个问题是这样的SYN-ACK报文段将不能被转发(因为转发需要完整的状态数据)。

Andre Oppermann最近的一些研究是运用TCP时间戳选项结合序列号字段编码更多的状态信息，保存那些高性能选项的应用，比如TCP窗口大小,TCP选择性确认选项(TCP Selective Acknowledgment Options )以及TCP MD5摘要对SYN cookies的支持。这使SYN Cookies向前迈进了一步，他消除了之前SYN cooikes实现不能支持这些功能的缺陷。

TCP SYN cookies 的规范格式并不涉及互操作性问题，因为它们仅在本地被处理，对于生成和验证的规范和过程在不同实现中会稍有不同。

4.1 SYN cookies的生成

为了在使用SYN cookies时计算出SYN-ACK序列号(就是SYN cookies)，主机首先要结合一些本机的密码比特，一个包括IP地址和TCP端口号的数据结构，SYN初始序列号，和一些标识密码比特的索引数据。在所有上述字节之上生成一个MD5摘要，然后一些比特位从hash值里被截断以便将其放入到SYN-ACK序列号中。由于序列号的大小大约是全部hash值的四分之一，因此这种截断是必要的，但是通常验证的时候至少要用3字节大小的hash比特位，这意味着在不知道密码比特位的情况下仍然有将近2^24种可能性去猜测验证cookies。为了将hash值发送出去，cookies的一些比特位将使SYN包含的MSS(最大报文段长度)的上限值变小，并影响在hash值中标识本机密码位的索引位。

4.2 SYN cookies的验证

为了验证SYN cookies，首先要将收到的ACK报文段中的确认号减1以便重新生成SYN cookies。对于这些已被截断过的hash位验证值的计算是基于双方IP地址，端口号，序列号减1和与cookie中索引号对应的密码池中的值。如果被计算出来的这些值与cookie中的值相同，此时TCB才初始化并开始建立连接。被编码的MSS上界被用来设置一个不超过最初值的合理大小的MSS值。MSS通常由3个比特位来实现，这三个比特位对应8个由一般链路的MTU(最大传输单元)和以太网头部计算出的MSS值。

5混合方式

混合方式将上述的两种或更多防御方法联合起来使用。例如，一些终端机操作系统同时实现了一个超大backlog队列和SYN cookies，但是仅仅当backlog的大小超过一定阈值时SYN cookies才被使用，这样就能在不涉及SYN cookies缺点的情况下正常使用，也允许在遭受攻击时转移到SYN-cookies防御。

6基于网络的对策

6.1过滤

网络层最基本的防御是RFC 2827[3]里描述的过滤应用。采用输入源过滤，ISP拒绝将一个源IP地址不属于其来源子网的包进行更远的路由。输入源过滤能够有效地阻止用IP伪装的SYN洪泛攻击。然而这种方法在目前是没用的，因为其很难大规模部署。而且输入源过滤同样不能抵御分布式攻击。

6.2防火墙与代理

一个有防火墙或者代理的设备在网络中就能够通过两种方法缓冲SYN洪泛攻击，一种是对连接发起人伪装SYN-ACK包，另一种是对服务器伪装ACK包。

如果连接发起人是合法的，防火墙/代理就会收到ACK，然后在它自己和服务器之间建立连接并伪装连接发起人的地址。防火墙/代理将连接双方分割开。这种分割能够抵御SYN洪泛攻击，因为服务器方根本没接受收过攻击者的SYN。只要防火墙/代理实现了一些基于TCP的防御策略，比如SYN cookies或SYN 缓存，他就能够保护所有在其后面的服务器免于SYN洪泛攻击。

另一种是响应SYN-ACK的伪装ACK包通过防火墙/代理到达服务器。这种伪装防止服务器的TCB一直停留在SYN-RECEIVED状态，因此保证了backlog队列中的空余空间。防火墙/代理将会停留等待一段时间，如果连接发起人正确的ACK没有被检测到，它将会通过伪装的TCP RET报文使服务器释放TCB。对合法的连接，数据包流能够在没有防火墙/代理的影响下继续进行。这种方法相比于上面伪装SYN-ACK的方法更具吸引力，因为当合法连接建立以后防火墙/代理不需要直接参与到连接中去。

对于ARP泛洪攻击预防措施如下：

给个链接自己看：

http://www.h3c.com.cn/Solution/Base_Network_Secrity/Dummy_Garden_Solutions/ARP_Noattack_Solutions/How_Do_I_Do_It/White_Paper/200712/327111_30004_0.htm