如何进行SYN攻击防范(2)
如何进行SYN攻击防范(2)
如何进行SYN攻击防范(2)
作者：冰盾防火墙　网站：　日期：
& SYN cookies技术
我们知道，TCP协议开辟了一个比较大的内存空间backlog队列来存储半连接条目，当SYN请求不断增加，并这个空间，致使系统丢弃SYN连接。为使半连接队列被塞满的情况下，服务器仍能处理新到的SYN请求，SYN cookies技术被设计出来。
SYN cookies应用于linux、FreeBSD等操作系统，当半连接队列满时，SYNcookies并不丢弃SYN请求，而是通过加密技术来标识半连接状态。
在TCP实现中，当收到客户端的SYN请求时，服务器需要回复SYN＋ACK包给客户端，客户端也要发送确认包给服务器。通常，服务器的初始序列号由服务器按照一定的规律计算得到或采用随机数，但在SYN cookies中，服务器的初始序列号是通过对客户端IP地址、客户端端囗、服务器IP地址和服务器端囗以及其他一些安全数值等要素进行hash运算，加密得到的，称之为cookie。当服务器遭受SYN攻击使得backlog队列满时，服务器并不拒绝新的SYN请求，而是回复cookie（回复包的SYN序列号）给客户端， 如果收到客户端的ACK包，服务器将客户端的ACK序列号减去1得到cookie比较值，并将上述要素进行一次hash运算，看看是否等于此cookie。如果相等，直接完成三次握手（注意：此时并不用查看此连接是否属于backlog队列）。
在RedHat linux中，启用SYN cookies是通过在启动环境中设置以下命令来完成：
# echo 1 ?? /proc/sys/net/ipv4/tcp_syncookies
& 增加最大半连接数
大量的SYN请求导致未连接队列被塞满，使正常的TCP连接无法顺利完成三次握手，通过增大未连接队列空间可以缓解这种压力。当然backlog队列需要占用大量的内存资源，不能被无限的扩大。
Windows2000：除了上面介绍的TcpMaxHalfOpen, TcpMaxHalfOpenRetried参数外，Windows2000操作系统可以通过设置动态backlog(dynamic backlog)来增大系统所能容纳的最大半连接数，配置动态backlog由AFD.SYS驱动完成，AFD.SYS是一种内核级的驱动，用于支持基于window socket的应用程序，比如ftp、telnet等。AFD.SYS在注册表的位置：
HKLM\System\CurrentControlSet\Services\AFD\Parameters\EnableDynamicBacklog值为1时，表示启用动态backlog，可以修改最大半连接数。
MinimumDynamicBacklog表示半连接队列为单个TCP端囗分配的最小空闲连接数，当该TCP端囗在backlog队列的空闲连接小于此临界值时，系统为此端囗自动启用扩展的空闲连接（DynamicBacklogGrowthDelta），Microsoft推荐该值为20。
MaximumDynamicBacklog是当前活动的半连接和空闲连接的和，当此和超过某个临界值时，系统拒绝SYN包，Microsoft推荐MaximumDynamicBacklog值不得超过2000。
DynamicBacklogGrowthDelta值是指扩展的空闲连接数，此连接数并不计算在MaximumDynamicBacklog内，当半连接队列为某个TCP端囗分配的空闲连接小于MinimumDynamicBacklog时，系统自动分配DynamicBacklogGrowthDelta所定义的空闲连接空间，以使该TCP端囗能处理更多的半连接。Microsoft推荐该值为10。
LINUX：Linux用变量tcp_max_syn_backlog定义backlog队列容纳的最大半连接数。在Redhat 7.3中，该变量的值默认为256，这个值是远远不够的，一次强度不大的SYN攻击就能使半连接队列占满。我们可以通过以下命令修改此变量的值：
# sysctl -w net.ipv4.tcp_max_syn_backlog=`2048`
Sun Solaris Sun Solaris用变量tcp_conn_req_max_q0来定义最大半连接数，在Sun Solaris 8中，该值默认为1024，可以通过add命令改变这个值：
# ndd -set /dev/tcp tcp_conn_req_max_q0 2048
HP-UX：HP-UX用变量tcp_syn_rcvd_max来定义最大半连接数，在HP-UX　11.00中，该值默认为500，可以通过ndd命令改变默认值：
＃ndd -set /dev/tcp tcp_syn_rcvd_max 2048
&缩短超时时间
上文提到，通过增大backlog队列能防范SYN攻击；另外减少超时时间也使系统能处理更多的SYN请求。我们知道，timeout超时时间，也即半连接存活时间，是系统所有重传次数等待的超时时间总和，这个值越大，半连接数占用backlog队列的时间就越长，系统能处理的SYN请求就越少。为缩短超时时间，可以通过缩短重传超时时间（一般是第一次重传超时时间）和减少重传次数来实现。
Windows2000第一次重传之前等待时间默认为3秒，为改变此默认值，可以通过修改网络接囗在注册表里的TcpInitialRtt注册值来完成。重传次数由TcpMaxConnectResponseRetransmissions 来定义，注册表的位置是：
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters registry key
当然我们也可以把重传次数设置为0次，这样服务器如果在3秒内还未收到ack确认包就自动从backlog队列中删除该连接条目。
LINUX：Redhat使用变量tcp_synack_retries定义重传次数，其默认值是5次，总超时时间需要3分钟。
Sun Solaris Solaris　默认的重传次数是3次，总超时时间为3分钟，可以通过ndd命令修改这些默认值。&
最新内容：
相关内容：
合作伙伴：如何防御TCP SYN泛洪攻击 | 百度企业安全播报now_fly 的BLOG
用户名：now_fly
文章数：87
评论数：27
访问量：211797
注册日期：
阅读量：5863
阅读量：12276
阅读量：381378
阅读量：1073435
[匿名]51cto游客：
[匿名]LY：
51CTO推荐博文
650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" small="0" class="blogimg" src="/jianqiucheng/pic/item/f08ccb10fbe2f.jpg" style="line-height: " />        SYN洪水攻击是DOS(这个DOS不是操作系统.别搞混了)和DDOS的一种.也就是拒绝服务和分布式拒绝服务攻击首先我们来看这种攻击的原理.要想明白这种原理.还得先知道TCP连接建立的过程       TCP与UDP不同,它是基于连接的,也就是说:为了在服务端和客户端之间传送TCP数据,必须先建立一个虚拟电路,也就是TCP连接,标准过程是这样的：      首先,客户端发送一个包含SYN标志的TCP报文,SYN即同步(Synchronize),同步报文会指明客户端使用的端口以及TCP连接的初始序号;      第二步,服务器在收到客户端的SYN报文后,将返回一个SYN+ACK的报文,表示客户端的请求被接受,同时TCP序号被加一,ACK即确认(Acknowledgement).      第三步,客户端也返回一个确认报文ACK给服务器端,同样TCP序列号被加一,到此一个TCP连接完成.这个过程被称为三次握手(Three-way Handshake)而SYN攻击的问题就出在了第三步:客户端不返回确认报文给服务器~这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接--(SYN半连接攻击)      而如果大量的这种半连接出现.服务器就会有大量的资源被消耗在了重试发送SYN+ACK给客户端上.而没有资源来处理正常的连接请求了.因此.碰到这种攻击.可以查看路由器状态的.就会发现路由器CPU使用率相当高~!让我们再深入理解一下TCP的报文格式是这样的IP首部--TCP首部--TCP数据段IP首部就是IP地址.SYN攻击软件或者是病毒.会在这里写入随机的IP举个例子.更形象的理解:你的网吧.内部机器的IP地址是192.168.0.1-254.如果这个软件(病毒)在IP首部写的是192.168.0.23 而这个IP正好有人在使用.服务器发SYN+ACK报文后.它会返回通知服务器不需要等待这个空连接.但是如果写入的IP是75.12.23.9呢?你网吧内有这个IP吗?没有.那么服务器就会重试并等待这个过程了.因为没有任何机器会通知服务器这个连接是无效的.这正是TCP/IP协议的缺陷所在到了这里.我们可以很遗憾的明白.对付这类攻击.目前没有很好的防御方法.这种基于TCP/IP协议缺陷所做出的攻击.只要是你用TCP/IP协议.就会有可能受到攻击的.-_-!当然.也不是悲观到坐以待毙.我们还是应该尽自己所能的.来防范和处理这类攻击.不过.如果这类攻击来自外网的话.的确是非常让人头疼的事情我自己装的是MikroTik Routes OS做路由器.配置很低(现在有些后悔)CIII-1.1G CPU.20G硬盘.815EP 英特网卡以我的来实际说明一下我做的防范及思路吧.前提是防范来自内部的攻击.因为如果是来自外网的攻击的话.非常少见.而且.说实话...外网攻击够强的话...会让人感觉无力...并且.在我的观念里.外网的问题.交给电信.我们是付了光纤使用费的.不是吗?从上面.我们可以知道.第三次握手没有成立时.服务会重试并等待.直到TIME OUT.既丢弃.那么我们可以首先可以从SYN Timeout时间上着手.也就是常有人说的SYN响应时间.这个值越小.服务器等待的时间就越少.也就会越快的丢弃这个半连接.(所以做路由器的机器配置越强劲.对付这种攻击的能力会越强.因为它能处理和保存这种SYN列表的能力强)在ROS上.这个选项位于WINBOX里的左边工具条:IP--Firewall--Connections里. 在这一项有个Tracking650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
src="/skins/default/filetype/jpg.gif" border="0" style="line-height: " />此主题相关图片如下：650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" small="0" class="blogimg" src="/jianqiucheng/pic/item/.jpg" style="line-height: " />需要注意的是.这个值不要太小.如果拼命减少这个值的话.会影响正常的SYN连接的.具体多少合适.你可以自己试一下.网盟兄弟guiwu发了一个ROS的防火墙规则.这个思路很好.目的也是减少服务器的这种负荷注意了.这样做只是能尽量减少路由的负荷.不是完全防止了这种攻击.如果攻击的强度足够.你的路由还是要挂~!减少了负荷.就能为我们争取足够的时间.网盟另一个贴子发过通过ROS查找SYN攻击源的录像.作者是谁我记不清了.因为我自己也知道.所以只是粗略看了一下.地址我也没有.(-_-)不知道的朋友.去翻贴子吧INPUT链上的SYN新连接可以丢弃.在FORWARD链上的可就不行了.除非你不让你的客人上网了.所以我们只能限制下它的连接数.FORWARD链上.要限制连接数.把连接数改小来. 我这里改到15.我现在这家网吧的是2.8.22版的.而2.9.6的版本.距离我十个站的路.不想过去了.也就是一点点不同而已.仔细看一下其实都一样的.将就看吧FORWARD链上设置规则的时候小心一点.最后做下备份.设置不当会让客户机上不了网的650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
src="/skins/default/filetype/jpg.gif" border="0" style="line-height: " />此主题相关图片如下：650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" small="0" class="blogimg" src="/jianqiucheng/pic/item/aac21fee8e86ecfcb3fb952d.jpg" style="line-height: " />650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" small="0" class="blogimg" src="/jianqiucheng/pic/item/8f1a3ef081da16c47831aa2e.jpg" style="line-height: " />650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" small="0" class="blogimg" src="/jianqiucheng/pic/item/274dd12bb4f68cfde7cd402a.jpg" style="line-height: " />650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" small="0" class="blogimg" src="/jianqiucheng/pic/item/3ee296a2fc0588aacaefd02b.jpg" style="line-height: " />截的图只是一些粗略的说明.不要照着我的填.最大连接数量可以适当浮动.你最好自己根据自己网吧的情况来处理这些数值.单独用一条规则.让超过总连接数的包都被丢弃.这样路由器比较不容易挂.你也可以把这规则作用与单个IP.也就是你的每个IP配一条规则.规则具体应用到自己怎么写.最好自己多试一下.不要拿到一条规则就用.那样对自己没好处.没有最好的.只有最合适的.参考一下官方防火墙规则.看看它在哪条链上做了哪些设置.对自己了解防火墙规则的设置会很有好处另外我曾想过把那些稀松的IP范围排出一个范围.在此范围内的IP所发出的SYN连接.都丢弃.这样攻击在TCP报文里做假的IP基本上都在这个范围里就好了.只不过还没有具体的实验过.因为没有什么时间.最近不想动手.有条件和想法的朋友.愿意的话帮验证一下这个想法.毕竟网吧经常连接的IP.还是有能力确定出大概的范围的.就是比较累人.我自己现在没时间去试.也不知道这个想法有多少可行性规则具体应用到自己怎么写.最好自己多试一下.不要拿到一条规则就用.那样对自己没好处.没有最好的.只有最合适的.参考一下官方防火墙规则.看看它在哪条链上做了哪些设置.对自己了解防火墙规则的设置会很有好处我对防范这类攻击的想法.其实就是尽量的.在不影响正常使用情况下.增强路由器处理SYN半连接的能力.减少路由器的负荷.TCP/IP的缺陷让我们没有什么好办法去主动的对付它.想防外网的攻击的话.如果你能知道攻击的真实IP.你可以把这个IP发来的包全部丢弃.当然.前提是你查出它的真实IP.如果你有能力.可以加防火墙.那样是再好不过了.抗打击力强好多倍下面是我某次被攻击时的截图.650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" small="0" class="blogimg" src="/jianqiucheng/pic/item/ba2f9cb4c41e9.jpg" style="line-height: " />TIME OUT时间在14-19秒之间.DST这个地址.我查了一下是江西省抚州市 (南丰县)电信. 我怀疑这是个伪造地址.此时路由器的丢包相当的严重.不过还没有挂.出事之前的十分钟.有一个人说QQ掉了.我那时还没注意.再坐了一会.整个网吧就开始丢包了....有条件的最好经常查看网络情况.出现征兆立刻抓包.找出源头.是外网的话.交给电信吧.....-.-
了这篇文章
类别：┆阅读(0)┆评论(0)8013人阅读
网络协议（2）
尽管这种攻击已经出现了十四年，但它的变种至今仍能看到。虽然能有效对抗SYN洪泛的技术已经存在，但是没有对于TCP实现的一个标准的补救方法出现。你可以在如今的操作系统和设备中找到保护应用层和网络层的不同解决方案的不同实现。本篇论文详细描述这种攻击并展望和评估现在应用于终端主机和网络设备的对抗SYN洪泛方法。
1&基本的漏洞
SYN洪泛攻击首次出现在1996年。当时Phrack杂志中描述了这种攻击并用代码实现了它[1]。这些信息被迅速应用于攻击一个网络服务提供商(ISP)的邮件和Telnet服务，并造成了停机。CERT(Computer&Emergency&Response&Team)不久就发布了对于这种攻击技术的初步评估与解决方案[2]。
SYN洪泛攻击的基础是依靠TCP建立连接时三次握手的设计。第三个数据包验证连接发起人在第一次请求中使用的源IP地址上具有接受数据包的能力，即其返回是可达的。图1显示了一次普通的TCP连接开始时交换数据包的过程。
TCB(TCP&传输控制块)是一种包含一个连接所有信息的传输协议数据结构(实际上在许多操作系统中它是用于处理进站(inbound)连接请求的一个队列,该队列保存那些处于半开放(half-open)状态的TCP连接项目，和已建立完整连接但仍未由应用程序通过accept()调用提取的项目)。一个单一的TCB所占内存大小取决于连接中所用的TCP选项和其他一些功能的实现。通常一个TCB至少280字节，在某些操作系统中已经超过了1300字节。TCP的SYN-RECEIVED状态用于指出这个连接仅仅是半开连接，请求是否合法仍被质疑。这里值得注意的一个重要方面就是TCB分配空间的大小取决于接收的SYN包——在连接被完全建立或者说连接发起人的返回可达性被证实之前。
这就导致了一个明显潜在的DoS攻击，到达的SYN包将被分配过多的TCB而导致主机的内核内存被耗尽。为了避免这种内存耗尽，操作系统通常给监听接口关联了一个&backlog&队列参数，它同时维护连接的TCB上限数量和SYN-RECEIVED状态。尽管这种方案使主机的可用内存免遭攻击，但是backlog队列本身就带来了一个(小的)受攻击源。当backlog中没有空间时，就不可能再响应新的连接请求，除非TCB能被回收或者从SYN-RECIEVE状态中移除。
试图发送足够多的SYN包而耗尽backlog是TCP&SYN洪泛的目的。攻击者在SYN包中加入源IP地址，这样就不会导致主机将已分配的TCB从SYN-RECEVIED状态队列中移除(因为主机将响应SYN-ACK)。因为TCP是可靠的，目的主机在断开半开连接并在SYN-RECIEVED队列中移除TCB之前将等待相当长的时间。在此期间，服务器将不能响应其他应用程序合法的新TCP连接请求。图2显示了简单的TCP&SYN洪泛攻击的过程。
图3显示了目前网络中检测到的一些SYN攻击变种。
2&直接攻击
如果攻击者用他们自己的没有经过伪装的IP地址快速地发送SYN数据包，这就是所谓的直接攻击。这种攻击非常容易实现，因为它并不涉及攻击者操作系统用户层以下的欺骗或修改数据包。例如，他可以简单地发送很多的TCP连接请求来实现这种攻击。然而，这种攻击要想奏效攻击者还必须阻止他的系统响应SYN-ACK包，因为任何ACK、RST或ICMP(Internet&Control&Message&Protocol)包都将让服务器跳过SYN-RECEIVED状态(进入下一个状态)而移除TCB(因为连接已经建立成功或被回收了)。攻击者可以通过设置防火墙规则来实现，让防火墙阻止一切要到达服务器的数据包(SYN除外)，或者让防火墙阻止一切进来的包来使SYN-ACK包在到达本地TCP处理程序之前就被丢弃了。
一旦被检测到，这种攻击非常容易抵御，用一个简单的防火墙规则阻止带有攻击者IP地址的数据包就可以了。这种方法在如今的防火墙软件中通常都是自动执行的。
3&欺骗式攻击
SYN洪泛攻击的另一种方式是IP地址欺骗。它比直接攻击方式更复杂一点，攻击者还必须能够用有效的IP和TCP报文头去替换和重新生成原始IP报文。如今，有很多代码库能够帮助攻击者替换和重新生成原始IP报文。
对于欺骗式攻击，首先需要考虑的就是选择地址。要使攻击成功，位于伪装IP地址上的主机必须不能响应任何发送给它们的SYN-ACK包。攻击者可以用的一个非常简单的方法，就是仅需伪装一个源IP地址，而这个IP地址将不能响应SYN-ACK包，或许因为这个IP地址上根本就没有主机，或许因为对主机的地址或网络属性进行了某些配置。另一种选择是伪装许多源地址，攻击者会假想其中的一些伪装地址上的主机将不会响应SYN-ACK包。要实现这种方法就需要循环使用服务器希望连接的源IP地址列表上的地址，或者对一个子网内主机做相同的修改。
如果一个源地址被重复地伪装，这个地址将很快被检测出来并被过滤掉。在大多数情况下运用许多不同源地址伪装将使防御变得更加困难。在这种情况下最好的防御方法就是尽可能地阻塞源地址相近的欺骗数据包。
假设攻击者是在一个“互联”的网络中(例如一个自治系统(Autonomous&System))，由其ISP限制攻击者所在网络流量的输入输出过滤将能够制止这种欺骗攻击——如果这种方法能被机构部署到正确位置的话。这种流量输入输出过滤的防御方式将限制一些合法的通信，比如移动IP三角路由运作模式，因此不可能被普遍部署。IP安全协议(IPsec)同样也提供了一种抵御欺骗包的优秀方式，但是这协议因为部署限制还不能被使用。由于对于服务器方通常不可能要求链接发起人的ISP去实施地址过滤或者要求其使用IP安全协议，因此抵御这种用多地址伪装的欺骗攻击还需要更加复杂的解决方案，将在后文讨论到。
4&分布式攻击
对于单个运用欺骗式攻击的攻击者真正的限制因素是如果这些伪装数据包能够以某种方式被回溯到其真正的地址，攻击者将被简单地击败。尽管回溯过程需要一些时间和ISP之间的配合，但它并不是不可能的。但是攻击者运用在网络中主机数量上的优势而发动的分布式SYN洪泛攻击将更加难以被阻止。如图3所示，这些主机群可以用直接攻击，也可以更进一步让每台主机都运用欺骗攻击。
如今，分布式攻击才是真正可行的，因为罪犯拥有数以千计的主机供他来进行拒绝服务(DoS)攻击。由于这些大量的主机能够不断地增加或减少，而且能够改变他们的IP地址和其连接，因此要阻止这类攻击目前还是一个挑战。
5&攻击的一些参数
SYN洪泛攻击能够比一般的仅仅是向目标网络发送大量数据包的蛮力DoS攻击用更少的数据包进行攻击。但是这需要对服务器的操作系统有一定了解，比如它分配了多少的backlog队列空间，在超时并丢弃TCB前它会将TCB在SYN-RECIEVED状态里保持多久。例如，攻击者可以发送刚好是backlog队列大小的一定数量的SYN包，并且其周期刚好是TCB被回收的时间，这样就可以让服务器永远不可用。
最近的一些系统基本都是默认backlog大小为1024字节，但是网络上的很多服务器都将其配置为128字节或更少。通常重传SYN-ACK的时间阈值时5秒，是通常成功接收时间的两倍，默认超时时间是3秒，在第一个SYN-ACK发出到其TCB被回收的时间是189秒。
6&网络终端的对策
6.1增加TCP&backlog队列
由于其基本攻击原理是依赖于终端主机连接套接字的backlog溢出，因此一个显然的基于终端主机的解决方案是增加backlog队列大小，而且这种方法已经广泛的运用于大多数服务器了。增加backlog队列通常是通过修改应用的listen()函数调用和一个操作系统内核参数SOMAXCONN——它用于设置一个应用程序能够接收的backlog上限值。这种方法本身并不能被完全认为是抵御SYN洪泛的有效方法，即使在一些能够有效支持超大backlog队列分配的操作系统中，因为攻击者能够任意生成比其操作系统支持的backlog还大得多的数据报。
6.2减少SYN-RECEIVED的时间
另一个基于终端主机的解决方法是缩短一个TCB从进入SYN-RECEIVED状态到因未进入下一个状态而被回收之间的时间。但这个方案的一个明显缺点是攻击可以利用因拥塞而丢包的ACK-SYN或者握手完成的ACK包，这样合法连接的TCB就会由于主机忙于重传这些包(因为SYN-RECEIVED时间减少)而被回收。此外，在管理员减少SYN-RECEIVED状态时间多少和攻击者的发包率之间仅仅是一个线性关系而已。基于上述原因，此方案并不建议采用。
6.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%的时间。
6.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&的规范格式并不涉及互操作性问题，因为它们仅在本地被处理，对于生成和验证的规范和过程在不同实现中会稍有不同。
6.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值中标识本机密码位的索引位。
6.4.2&SYN&cookies的验证
为了验证SYN&cookies，首先要将收到的ACK报文段中的确认号减1以便重新生成SYN&cookies。对于这些已被截断过的hash位验证值的计算是基于双方IP地址，端口号，序列号减1和与cookie中索引号对应的密码池中的值。如果被计算出来的这些值与cookie中的值相同，此时TCB才初始化并开始建立连接。被编码的MSS上界被用来设置一个不超过最初值的合理大小的MSS值。MSS通常由3个比特位来实现，这三个比特位对应8个由一般链路的MTU(最大传输单元)和以太网头部计算出的MSS值。
6.5混合方式
混合方式将上述的两种或更多防御方法联合起来使用。例如，一些终端机操作系统同时实现了一个超大backlog队列和SYN&cookies，但是仅仅当backlog的大小超过一定阈值时SYN&cookies才被使用，这样就能在不涉及SYN&cookies缺点的情况下正常使用，也允许在遭受攻击时转移到SYN-cookies防御。
7&基于网络的对策
网络层最基本的防御是RFC&2827[3]里描述的过滤应用。采用输入源过滤，ISP拒绝将一个源IP地址不属于其来源子网的包进行更远的路由。输入源过滤能够有效地阻止用IP伪装的SYN洪泛攻击。然而这种方法在目前是没用的，因为其很难大规模部署。而且输入源过滤同样不能抵御分布式攻击。
7.2防火墙与代理
一个有防火墙或者代理的设备在网络中就能够通过两种方法缓冲SYN洪泛攻击，一种是对连接发起人伪装SYN-ACK包，另一种是对服务器伪装ACK包[5]。
如果连接发起人是合法的，防火墙/代理就会收到ACK，然后在它自己和服务器之间建立连接并伪装连接发起人的地址。防火墙/代理将连接双方分割开。这种分割能够抵御SYN洪泛攻击，因为服务器方根本没接受收过攻击者的SYN。只要防火墙/代理实现了一些基于TCP的防御策略，比如SYN&cookies或SYN&缓存，他就能够保护所有在其后面的服务器免于SYN洪泛攻击。
另一种是响应SYN-ACK的伪装ACK包通过防火墙/代理到达服务器。这种伪装防止服务器的TCB一直停留在SYN-RECEIVED状态，因此保证了backlog队列中的空余空间。防火墙/代理将会停留等待一段时间，如果连接发起人正确的ACK没有被检测到，它将会通过伪装的TCP&RET报文使服务器释放TCB。对合法的连接，数据包流能够在没有防火墙/代理的影响下继续进行。这种方法相比于上面伪装SYN-ACK的方法更具吸引力，因为当合法连接建立以后防火墙/代理不需要直接参与到连接中去。
8&活动监视器
活动监视器是一种能够检测并干预发往服务器的流量的设备，跟像防火墙一样，它并不是网络路由中必须的设备。一种典型的监视器会像7中的ACK伪装的防火墙/代理一样，拥有一个附加的能力，就是如果它发现SYN包来源于它知道的攻击者源地址就会立刻发送伪装RST包给服务器。活动监视器因其便宜容易部署(相比于基于防火墙和输入源过滤的方案)而具有实用性，而且仍然能够保护整个服务器网络而不需要每台服务器操作系统都实现一个基于终端的解决方案。
9&SYN洪泛与相关一些攻击的比较
除了SYN洪泛，通过在TCP已建立的连接中伪装源IP地址和连接参数的一些其他攻击也是可能的。如果攻击者能够推测到双方的IP地址，TCP端口号和合法的序列号，就能通过重置或修改恶意数据而破坏连接。除了伪装TCP报文段，伪装ICMP数据包同样也能终止一个TCP连接。
不管是这些攻击还是SYN洪泛，其目标都是受害者的TCP应用程序，而且能够用比蛮力洪泛数据包方法小的多的代价来中断受害者的服务。然而，SYN洪泛与其他TCP欺骗攻击相比有很大的不同。SYN洪泛攻击新连接的服务而不影响已建立的连接，然而其他欺骗攻击却是打断已建立的连接不能从开始阻止新的连接。SYN攻击仅仅通过修改初始握手程序就能被制止，然而其他的欺骗攻击需要整个连接生命周期中检查每一段数据。SYN洪泛和其他TCP欺骗攻击之间的共同之处是他们都是取决于攻击者发送伪装源地址IP数据包的能力，而防御它们的相同方法都是部署更多的地址过滤或使用IP安全协议(IPsec)。
在我看来，一些SYN缓存技术的变体应该作为固化功能将其植入到服务器操作系统中去，而且这些变体可以适当的情况下结合其他解决方案(基于地址的过滤，ACK伪装防火墙，IP安全协议等等)一起部署。目前也有许多专家正在致力于研究健壮性更强的TCP协议，也希望这些补充协议能够早日部署。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：359743次
积分：4238
积分：4238
排名：第5777名
原创：106篇
转载：51篇
评论：35条
(11)(7)(1)(13)(18)(4)(10)(1)(6)(22)(5)(15)(4)(3)(18)(14)(6)}