在TCP三次握手后插入伪造的TCP包
一、说明用Socket的APIConnect完成TCP建立连接的三次握手，同时子进程抓包，抓完三次握手的包后，插入第四个包即可，从对端返回的第五个包来看插入成功了，但因为插入了一个TCP包，之后的连接将发生混乱。可以将插入的那个包Data 设置为HTTPRequest，向WEB服务器提交请求。又如果目标系统的TCP序列号是可预计算的，那么是否可以做带伪源地址的 BlindTCPthree-timehandshakes和插入，值得试验！


作者所做的实验其实什么也说明不了，只是验证了一下TCP协议序号和检验和计算函数而已。

我想作者八成是受了CC攻击原理的启发，想不通过代理的方式以达到CC攻击效果。但在序号预测这个步骤上，说实话没有可行性。正常TCP协议采用的同步序号是随机值，在43亿的可选空间中，以百兆带宽的速度进行预测也将是杯水车薪。但是……
为了防御ddos，不少厂商的安全设备中都实现了无状态的syncookie算法，这种算法在大量syn冲击下利用cookie序号在ack包回传的方式判断连接请求的合法性。所以他们的TCP协议握手部分不是一个健康的实现，本思路经修改后用于攻击此类设备将会取得不错的效果。下面简单介绍攻击者如何以 64字节ACK包换取服务器1518大数据包重传，如果源IP伪造成功，攻击者从理论上将获得20余倍的带宽放大攻击效果。如果有两个目标网站，本方法将一箭双雕。
攻击原理：利用TCP协议收到ACK后的快速重传机制

序号乱刀之一：攻击正常TCP/IP协议栈示意图
       当我们获得httpresponse回应后，立即回复一个ack数据包，此 ack数据包的seq值是httpresponse数据包中的ackseq值，而ackseq值为httpresponse数据包的seq序号值。这样当 server收到此ack数据包后，会认为是自己刚才发送的httpresponse包在网络中已丢失，会利用快速重传机制加以重传。如果我们拼命发送大量的ack包，则服务器就会不断进行重传。Ack数据包的大小只需64字节，但httpresponse通常都在512字节左右，最长可达1518字节。
       因为正常tcp协议序号的不可预测性，所以我们在这次攻击中暴露了自己的真实IP。

screen.width*0.7){this.resized=true;this.width=screen.width*0.7;this.style.cursor='hand';this.alt='Clickheretoopennewwindow\nCTRL+Mousewheeltozoomin/out';}"onclick="if(!this.resized){returntrue;}else{window.open('/UpLoadFiles/NewsPhoto/13003749.jpg');}"alt="Clickheretoopennewwindow CTRL+Mousewheeltozoomin/out"src="http://hackbase.com/UpLoadFiles/NewsPhoto/13003749.jpg"width=560onload="if(this.width>screen.width*0.7){this.resized=true;this.width=screen.width*0.7;this.alt='Clickheretoopennewwindow\nCTRL+Mousewheeltozoomin/out';}"border=0pop="Clickheretoopennewwindow CTRL+Mousewheeltozoomin/out"resized="true">

序号乱刀之二：攻击采用静态syncookie的ddos设备防护下的服务器

       所谓静态syncookie就是以客户端请求之syn包为参数计算回复 synack中的seq值，并在ack包回传时判断连接合法性的方法，这种方法被ddos厂商大量采用，并且获得数量可观的国家发明专利，呵呵….。你经常会听到ddos厂商的人说他们的设备比防火墙“牛”多了，可轻松达到百兆线速syn防御，但百兆防火墙30M攻击流量就可以干掉，说这种话的ddos厂商，我可以打赌他们的设备80%采用了这种syncookie算法。
Syncookie算法的好处是只在synflood攻击时消耗CPU资源，这对于X86下强悍的通用CPU来说，正适用。
读者可能会感到很奇怪，为什么如此成熟的技术防火墙不采用，而让ddos厂商成天挤对？这有如下几个方面的原因：
1: 防火墙也用syncookie进行synflood防御的，但大多不是静态syncookie，而是严格记录连接状态采用动态syncookie，所以当 synflood攻击时不光消耗CPU，还要消耗大量内存。这也就是我本文开头提及的本方法可以攻击大部分ddos厂商和小部分防火墙厂商的原因。
2:syncookie/synproxy是bsd系统内核源码的一部分，在Linux最新版的2.6内核中synproxy还没有被包含。所以ddos设备也大多由bsd系统组成。当然bsd是开源的，移植也不是什么大问题喽。
3: 防火墙大多以Linux下的开源软件netfilter为基础，但netfilter中hash算法和连接表设计不是很优秀，防火墙转发性能的瓶颈就在于此，如果再加入synproxy表项，会进一步降低对数据包的处理能力或加大连接表体积。高端防火墙大都支持数百万的连接数，这百万的表项就够防火墙喝一壶的了，再加一个synproxy表项，性能还不得掉的稀里哗拉的？
4:防火墙很重要的一个网络功能就是DNAT，在没有DNAT操作前，防火墙不知道这些syn包的最终目的地是自身还是DMZ区的服务器，所以syn包必须DNAT后才知道是否要进行syncookie保护。但这时就已经进入到 netfilter处理框架了，性能当然就跟不上了。你见过几个ddos设备支持NAT的？如果支持了，他的性能也会下降不少。如果防火墙工作在桥模式下，不经过netfilter处理框架，防火墙就可以摇身一变成为性能卓越的抗ddos设备了，吗功能都没有，当然一身轻松了。呵呵…但您买的是防火墙，会这么大材小用吗？
言归正传，采用静态syncookie的ddos设备，我们只需要重放一个ack包就可以达到与服务器的三次握手效果，因此可以做到源IP地址伪装。（这个伪装的源IP地址是你以前用过的，并且与ddos设备通讯过，并保存下来的，现在将它重放而己。如果你看不懂我在说什么，参照我写的《对国内ddos厂商技术点评》一文，抓包分析一下就知道了）。第二步就是发送一个正常的httprequest请求，随后就是大量的虚假ack 请求重传。
天知道，谁在用我们伪装的源IP地址，做为一个连带的牺牲品。
你可能会认为受害服务器B会回复rst包给受害服务器A。这是有可能，但如果服务器B前面加装了一个“状态检测”防火墙，就会直接丢弃这个反射的httpresponse数据包。

screen.width*0.7){this.resized=true;this.width=screen.width*0.7;this.style.cursor='hand';this.alt='Clickheretoopennewwindow\nCTRL+Mousewheeltozoomin/out';}"onclick="if(!this.resized){returntrue;}else{window.open('/UpLoadFiles/NewsPhoto/13004207.jpg');}"alt="Clickheretoopennewwindow CTRL+Mousewheeltozoomin/out"src="http://hackbase.com/UpLoadFiles/NewsPhoto/13004207.jpg"width=560onload="if(this.width>screen.width*0.7){this.resized=true;this.width=screen.width*0.7;this.alt='Clickheretoopennewwindow\nCTRL+Mousewheeltozoomin/out';}"border=0pop="Clickheretoopennewwindow CTRL+Mousewheeltozoomin/out"resized="true">

文章收录到本人blog中了，欢迎大家讨论。
                                            2006-05-1215:50
                                                                        skipjack
2006-05-169:09


本思路有价值的地方：
1.利用一条合法连接，对服务器进行下行带宽攻击，现在的“状态检测”设备不一定可以发现
2.目标服务器应用层程序感知不到这种攻击，可以逃避基于应用层流量统计的防御方式，因为重传是TCP协议特性，TCP协议自动完成。重传的数据包，对应用层来说是透明的。
3.现在只是一种思路，不局限于TCP协议。UDP加入重传机制后，也可以保证通讯可靠性。并且这是私人或公司独立开发的协议，漏洞会比TCP协议更大。
4.drdos的带宽放大效果也只不过是6倍而己，并且消耗的是上行带宽。
5. 真正的威胁不在现在，而是在对“长肥管道”的攻击效果。对方下行带宽越宽，攻击效果越明显。TCP会禁用分片，所以重传数据包大小依靠你与服务器之间最小的那个设备的MTU值，所以你见到的TCP协议的IP首部中的长度字段不会超时1518。但在“长肥管道”中，IP首部的长度字段会达到65535的极大值，对这些数据包的重传攻击，会达到令人吃惊的1:1024的放大效果。
1M对1G
1G对1T
明白？就是因为这点，我才会提供本思路，否则1:25的消耗也是蛮力。

攻击完善的TCP协议其实是很困难的：
1.具体可以参见RFC2581中关于FastRetransmit/FastRecovery的说明部分。
2.你的ack包构造不好，服务器协议栈还是会利用超时重传，而不是快速重传。