本文档的Copyleft归skipjack所有，使用GPL发布，可以自由拷贝，转载，转载时请保持文档的完整性，严禁用于任何商业用途。
邮箱: [email]skipjack@163.com[/email]
来源：http://skipjack.cublog.cn
本思路是对
http://www.xfocus.net/articles/200505/796.html
攻击思路的整理与提高，无意开发新的攻击器。如利用此原理的攻击软件问世，与我本人skipjack无关。
引文章第一段（呵呵...有这一段足够了）
[color=Red]
在TCP三次握手后插入伪造的TCP包
一、说明 用Socket的API Connect完成TCP建立连接的三次握手，同时子进程抓包，抓完三次握手的包后，插入第四个包即可，从对端返回的第五个包来看插入成功了，但因为插入了一个TCP包，之后的连接将发生混乱。可以将插入的那个包Data设置为HTTP Request，向 WEB服务器提交请求。又如果目标系统的TCP序列号是可预计算的，那么是否可以做带伪源地址的Blind TCP three- time handshakes和插入，值得试验！
[/color]
作者所做的实验其实什么也说明不了，只是验证了一下TCP协议序号和检验和计算函数而已。
我想作者八成是受了CC攻击原理的启发，想不通过代理的方式以达到CC攻击效果。但在序号预测这个步骤上，说实话没有可行性。正常TCP协议采用的同步序号是随机值，在43亿的可选空间中，以百兆带宽的速度进行预测也将是杯水车薪。但是……
为了防御ddos，不少厂商的安全设备中都实现了无状态的syn cookie算法，这种算法在大量syn冲击下利用cookie序号在ack包回传的方式判断连接请求的合法性。所以他们的TCP协议握手部分不是一个健康的实现，本思路经修改后用于攻击此类设备将会取得不错的效果。下面简单介绍攻击者如何以64字节ACK包换取服务器1518大数据包重传，如果源IP伪造成功，攻击者从理论上将获得20余倍的带宽放大攻击效果 。如果有两个目标网站，本方法将一箭双雕。
攻击原理：利用TCP协议收到ACK后的快速重传机制
序号乱刀之一：攻击正常TCP/IP协议栈示意图
当我们获得http response回应后，立即回复一个ack数据包，此ack数据包的seq值是http response数据包中的 ack seq值，而ack seq值为http response数据包的seq序号值。这样当server收到此ack数据包后，会认为是自己刚才发送的http response包在网络中已丢失，会利用快速重传机制加以重传。如果我们拼命发送大量的ack包，则服务器就会不断进行重传。Ack数据包的大小只需64字节，但http response通常都在512字节左右，最长可达1518字节。
因为正常tcp协议序号的不可预测性，所以我们在这次攻击中暴露了自己的真实IP。
序号乱刀之二：攻击采用静态syn cookie的ddos设备防护下的服务器
所谓静态syn cookie就是以客户端请求之syn包为参数计算回复syn ack中的seq值，并在ack包回传时判断连接合法性的方法，这种方法被ddos厂商大量采用，并且获得数量可观的国家发明专利，呵呵….。你经常会听到ddos厂商的人说他们的设备比防火墙“牛”多了，可轻松达到百兆线速 syn防御，但百兆防火墙30M攻击流量就可以干掉，说这种话的ddos厂商，我可以打赌他们的设备80%采用了这种syn cookie算法。
Syn cookie算法的好处是只在synflood攻击时消耗CPU资源，这对于X86下强悍的通用CPU来说，正适用。
读者可能会感到很奇怪，为什么如此成熟的技术防火墙不采用，而让ddos厂商成天挤对？这有如下几个方面的原因：
1:防火墙也用syn cookie进行synflood防御的，但大多不是静态syn cookie，而是严格记录连接状态采用动态 syn cookie，所以当syn flood攻击时不光消耗CPU，还要消耗大量内存。这也就是我本文开头提及的本方法可以攻击大部分ddos厂商和小部分防火墙厂商的原因。
2:syn cookie/syn proxy是bsd系统内核源码的一部分，在Linux最新版的2.6内核中syn proxy还没有被包含。所以ddos设备也大多由bsd系统组成。当然bsd是开源的，移植也不是什么大问题喽。
3:防火墙大多以Linux下的开源软件netfilter为基础，但netfilter中hash算法和连接表设计不是很优秀，防火墙转发性能的瓶颈就在于此，如果再加入syn proxy表项，会进一步降低对数据包的处理能力或加大连接表体积。高端防火墙大都支持数百万的连接数，这百万的表项就够防火墙喝一壶的了，再加一个syn proxy表项，性能还不得掉的稀里哗拉的？
4:防火墙很重要的一个网络功能就是DNAT，在没有DNAT操作前，防火墙不知道这些syn包的最终目的地是自身还是DMZ区的服务器，所以 syn包必须DNAT后才知道是否要进行syn cookie保护。但这时就已经进入到netfilter处理框架了，性能当然就跟不上了。你见过几个 ddos设备支持NAT的？如果支持了，他的性能也会下降不少。如果防火墙工作在桥模式下，不经过netfilter处理框架，防火墙就可以摇身一变成为性能卓越的抗ddos设备了，吗功能都没有，当然一身轻松了。呵呵…但您买的是防火墙，会这么大材小用吗？
言归正传，采用静态syn cookie的ddos设备，我们只需要重放一个ack包就可以达到与服务器的三次握手效果，因此可以做到源IP地址伪装。（这个伪装的源IP地址是你以前用过的，并且与ddos设备通讯过，并保存下来的，现在将它重放而己。如果你看不懂我在说什么，参照我写的《对国内ddos厂商技术点评》一文，抓包分析一下就知道了）。第二步就是发送一个正常的http request请求，随后就是大量的虚假ack请求重传。
天知道，谁在用我们伪装的源IP地址，做为一个连带的牺牲品。
你可能会认为受害服务器B会回复rst包给受害服务器A。这是有可能，但如果服务器B前面加装了一个“状态检测”防火墙，就会直接丢弃这个反射的http response数据包。
文章收录到本人blog中了，欢迎大家讨论。
2006-05-12 15:50
skipjack
2006-05-16 9:09
[color=Red]
本思路有价值的地方：
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中关于Fast Retransmit/Fast Recovery的说明部分。
2.你的ack包构造不好，服务器协议栈还是会利用超时重传，而不是快速重传。
[/color]
[ 本帖最后由 skipjack 于 2006-5-16 11:27 编辑 ]
回复于：2006-05-12 16:49:52
关注~！
在详细些吧
回复于：2006-05-13 01:20:04
引用：原帖由 Jambo 于 2006-5-12 16:49 发表
关注~！
在详细些吧
补齐原理部分的说明了，累死了:(
回复于：2006-05-15 11:35:49
有人看没人回，为什么？
这是一种可以穿过防火墙对保护服务器进行的带宽攻击方式，原理上对ddos保护下的服务器威害更大。
大家是感觉可行性不高，还是没看懂啥意思呢？
回复于：2006-05-15 11:51:04
那么是否可以做带伪源地址的Blind TCP three-time handshakes和插入
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
我觉得不太可能吧，服务器端会对没有记录的ip进行这种操作？
看了第一段描述，好像是告诉服务器数据没有到达，让其重发，这样似乎还是蛮力，虽然以小数据包换得大数据包，但似乎不太有用，先去吃饭，回来再仔细看看。
回复于：2006-05-15 12:37:29
引用：原帖由 skipjack 于 2006-5-15 11:35 发表
有人看没人回，为什么？
这是一种可以穿过防火墙对保护服务器进行的带宽攻击方式，原理上对ddos保护下的服务器威害更大。
大家是感觉可行性不高，还是没看懂啥意思呢？
没看懂 惭愧:em06:
回复于：2006-05-15 13:06:43
重新看了一遍，和上面看的差不多。
感觉没什么实用价值。
回复于：2006-05-15 13:10:31
syn flood的价值在于服务器端的timeout消耗的资源，和伪造source address.她发一个包过去，你那边就要等，就要消耗资源，而攻击方则轻松多了。
回复于：2006-05-15 13:11:49
引用：原帖由 teczm 于 2006-5-15 12:37 发表
没看懂 惭愧:em06:
:em17:
其实ack包的作用就是发送错误的TCP确认序号，这就是为什么管它叫“序号乱刀”的原因。
呵呵...举个例子，两个人打招乎：
A君：你好
B君：你也好
A君：你吃了吗？
B君：吃了呀
A君：你能把昨天的工作以流水账的形式给我口述一遍吗？
B君：当然可以喽，我：“早晨8点起床...9点到公司...10点写文档...11点吃饭...下午....晚上17:30回家”（共说了千八百字）
A君：不好意思，没听清楚，再来一遍。
B君：OK，我：“早晨8点起床...9点到公司...10点写文档...11点吃饭...下午....晚上17:30回家”（又说了千八百字）
A君：没听清楚，再来一遍。
B君：OK，我....8点
A君：没听清楚，再来一遍。
B君：OK，我....9点
A君：没听清楚，再来一遍。
B君：OK，我....10点
A君：没听清楚，再来一遍。
B君：OK，我....11点
A君：没听清楚，再来一遍。
B君：OK，我....12点
A君：没听清楚，再来一遍。
B君：OK，我....13点
A君：没听清楚，再来一遍。
B君：OK，我....14点
A君：没听清楚，再来一遍。
B君：OK，我....15点
A君：没听清楚，再来一遍。
B君：OK，我....16点
A君：还是没清楚，再来一遍。（真是个傻冒啊）
B君：.......（冒烟中ing）
回复于：2006-05-15 13:25:24
引用：原帖由 playmud 于 2006-5-15 13:10 发表
syn flood的价值在于服务器端的timeout消耗的资源，和伪造source address.她发一个包过去，你那边就要等，就要消耗资源，而攻击方则轻松多了。
我这个和syn flood没有任何相似性，syn flood对于ddos设备来说威害和ping flood差不多。它们同属1:1的资源消耗。而作者文章本意也不是这个意思。作者想通过猜测序号的方式来劫持TCP会话，然后再利用CC原理进行1:N的CPU资源消耗。
我的修改建议是：不猜序号仅利用握手的ACK包重放，而轻松做到1:N的带宽消耗。威力虽然减小了，但可行性已大幅提高。
回复于：2006-05-15 13:32:51
引用：原帖由 skipjack 于 2006-5-15 13:25 发表
我这个和syn flood没有任何相似性，syn flood对于ddos设备来说威害和ping flood差不多。它们同属1:1的资源消耗。而作者文章本意也不是这个意思。作者想通过猜测序号的方式来劫持TCP会话，然后再利用CC原理进行 ...
syn和ping的flood怎么能同日而语呢？ddos设备怎么防？消耗怎么成了1:1呢？
这是一个问题，再者：
你的方式可行马？是在怎么样一个网络环境下的？劫持的是第三方还是如何的？她消耗了N,这个N是否要返回给你呢？
回复于：2006-05-15 13:47:11
pingflood和synflood用在ddos设备上现在就是可以同日而语啊～，ddos设备收到一个syn包后回复一个syn ack包，这和收到一个echo request和回复一个echo reply有什么本质区别吗？
两幅图，第1个的N返回了，但第2个的N没有返回。这就是意思所在。
回复于：2006-05-15 14:08:25
ddos设备返回ack以后是不是保持这个请求的信息呢？syn flood拼的不是网络带宽，消耗的是目的主机的内存等资源，怎么和ping类似呢？相反你说的这种看上去更像ping,类似于在ie里面狂按f5进行刷新。
你的第二个图说的是时间1用ip1建立了连接，然后时间2用ip2发起攻击对吧？
如果这样ip2不用3次握手验证的话，那用了ddos设备反而不安全了。
回复于：2006-05-15 14:27:59
>>ddos设备返回ack以后是不是保持这个请求的信息呢？syn flood拼的不是网络带宽，
>>消耗的是目的主机的内存等资源，怎么和ping类似呢？相反你说的这种看上去更像ping,
>>类似于在ie里面狂按f5进行刷新。
我贴子里说过了，大部分ddos设备和小部分防火墙设备不会保持这个请求信息。我没说syn flood拼的是带宽呀。类似IE里狂按f5，但你的手肯定不会有我的程序快。另外按F5键服务器是可以感知的，但我的方法服务器是感知不到的，因为我的ack包不会上送到应用层，就算有基于流量的限制，也必须在IP层才可以检测到。
>>你的第二个图说的是时间1用ip1建立了连接，然后时间2用ip2发起攻击对吧？
>>如果这样ip2不用3次握手验证的话，那用了ddos设备反而不安全了。
Yes～就是利用了ddos设备这个漏洞。当然重放的时间很重要，过期就无效了。但这个方案的可性能比原文中的要高很多。
[ 本帖最后由 skipjack 于 2006-5-15 14:29 编辑 ]
回复于：2006-05-15 14:32:50
不保留请求信息的话那是如何和服务器进行数据交互的呢？偶对ddos设备没有了解，只觉的服务器端需要保留这个信息。
回复于：2006-05-15 14:38:51
你怎么为一个blind IP计算这个重放的ack包？那不等于要hack掉协议站中使用的加密算法吗？
回复于：2006-05-15 14:42:14
引用：原帖由 JohnBull 于 2006-5-15 14:38 发表
你怎么为一个blind IP计算这个重放的ack包？那不等于要hack掉协议站中使用的加密算法吗？
重放的ack包不是计算出来的，是我以前用过保存下来的。所以叫重放的ack，不叫猜测的ack。就是这一点把原作者思路的可行性大幅提高。
另外、协议栈中有加密算法吗，就算有会在三次握手时体现吗？
回复于：2006-05-15 14:45:08
引用：原帖由 playmud 于 2006-5-15 14:32 发表
不保留请求信息的话那是如何和服务器进行数据交互的呢？偶对ddos设备没有了解，只觉的服务器端需要保留这个信息。
我图二画的很清楚了，一个重放的ack包，会被ddos转化为syn包与服务器建立三次握手。
回复于：2006-05-15 14:53:45
引用：原帖由 skipjack 于 2006-5-15 14:42 发表
重放的ack包不是计算出来的，是我以前用过保存下来的。所以叫重放的ack，不叫猜测的ack。就是这一点把原作者思路的可行性大幅提高。
另外、协议栈中有加密算法吗，就算有会在三次握手时体现吗？
可是你以前记录的ACK分段的源地址不是受害服务器的源地址，而是你自己的源地址啊。
你不知道服务器里面的secret值，无法伪造任意服务器的ACK(除非你hack掉协议站中使用的加密算法)。
就算事先取得被害服务器的权限，抓包得到一个ACK分段也没有用，服务器里的secret值是变化的啊。
也许是我没看懂，我觉得你的推理靠不住，老兄还是编出一个东西让大家看看吧。
[ 本帖最后由 JohnBull 于 2006-5-15 15:00 编辑 ]
回复于：2006-05-15 15:07:20
引用：原帖由 JohnBull 于 2006-5-15 14:53 发表
可是你以前记录的ACK分段是你自己的源地址，不是受害服务器的啊，你又不知道服务器里面的secret值，不能求出伪造的ACK（除非你能hack掉他的加密算法）。
你是不是说事先已经得到了受害服务器的权限，在上面 ...
没有你想像的那么复杂，过程是这样的：
1.用ADSL拨一次号，与ddos防护的服务器进行一次http访问，把此次三次握手的ack包保存起来。当然如果服务器用cookie认证也把http get这个数据包保存。
2.再用ADSL拨一次号，把保存的ack包重放给服务器，把保存的http get request包重放给服务器（当然，这个包你可以自己造，CC就是这么干的）。
3.发送大量的ack，请求服务器重传http response这个大数据包。
http response不会回给我现在的IP地址，而回复给了上一个ADSL获得的IP地址:)
操作性不复杂吧？
回复于：2006-05-15 15:14:02
引用：原帖由 skipjack 于 2006-5-15 15:07 发表
没有你想像的那么复杂，过程是这样的：
1.用ADSL拨一次号，与ddos防护的服务器进行一次http访问，把此次三次握手的ack包保存起来。当然如果服务器用cookie认证也把http get这个数据包保存。
2.再用ADSL拨一 ...
我不知道你看过Linux的syncookie实现没有，反正你的方法肯定不会通过Linux的cookie检查。
saddr和sport不一样的话根本不行。
static __u32 check_tcp_syn_cookie(__u32 cookie, __u32 saddr, __u32 daddr,
__u16 sport, __u16 dport, __u32 sseq,
__u32 count, __u32 maxdiff)
{
__u32 diff;
/* Strip away the layers from the cookie */
cookie -= cookie_hash(saddr, daddr, sport, dport, 0, 0) + sseq;
/* Cookie is now reduced to (count * 2^24) ^ (hash % 2^24) */
diff = (count - (cookie >> COOKIEBITS)) & ((__u32) - 1 >> COOKIEBITS);
if (diff >= maxdiff)
return (__u32)-1;
return (cookie -
cookie_hash(saddr, daddr, sport, dport, count - diff, 1))
& COOKIEMASK; /* Leaving the data behind */
}
static u32 cookie_hash(u32 saddr, u32 daddr, u32 sport, u32 dport,
u32 count, int c)
{
__u32 tmp[16 + 5 + SHA_WORKSPACE_WORDS];
memcpy(tmp + 3, syncookie_secret[c], sizeof(syncookie_secret[c]));
tmp[0] = saddr;
tmp[1] = daddr;
tmp[2] = (sport << 16) + dport;
tmp[3] = count;
sha_transform(tmp + 16, (__u8 *)tmp, tmp + 16 + 5);
return tmp[17];
}
回复于：2006-05-15 15:30:43
引用：原帖由 JohnBull 于 2006-5-15 15:14 发表
我不知道你看过Linux的syncookie实现没有，反正你的方法肯定不会通过Linux的cookie检查。
saddr和sport不一样的话根本不行。
static __u32 check_tcp_syn_cookie(__u32 cookie, __u32 saddr, __u ...
重放的saddr和sport为什么不一样？攻击对象是采用静态cookie的ddos设备，如果是动态的cookie就又回到猜序号的老路上去了。你贴的源码中有SHA关键字，呵呵...我想性能是个大问题。等一会儿，我仔细看看。
回复于：2006-05-15 15:34:59
引用：原帖由 skipjack 于 2006-5-15 15:30 发表
重放的saddr和sport为什么不一样？攻击对象是采用静态cookie的ddos设备，如果是动态的cookie就又回到猜序号的老路上去了。你贴的源码中有SHA关键字，呵呵...我想性能是个大问题。等一会儿，我仔细看看。
sorry,犯晕了，不是saddr和sport不同，而是secret不同。所以你的攻击方法对于Linux而言理论上还是可以持续2分钟的。
但是按我前面所说，你描述的攻击方法还是等于变相“取得了被攻击主机的权限”了啊，你要是想攻击任意服务器还是不现实。
[ 本帖最后由 JohnBull 于 2006-5-15 15:44 编辑 ]
回复于：2006-05-15 16:00:13
我现在有些质疑想在此提出：
你即使程序自己发送重复的ACK，但你的操作系统协议栈在接收到回应数据报后会给服务器端发送正确真是的ACK包，因此滑动窗口会自动对于接收端来讲，TCP滑动窗口会向前移动，一旦移动后就无法后退，因此你的重复ACK也无用了。这是我的一点看法。
回复于：2006-05-15 16:08:10
说得再明白点就是：服务器端一旦收到来自你操作系统协议栈的ACK包（非你程序发出的），就会自动将服务器端的滑动窗口向前移动。一旦移动后就无法后退。使得攻击无效。有不同意见的话，欢迎发表。
回复于：2006-05-15 16:13:01
引用：原帖由 lxdlj 于 2006-5-15 16:00 发表
我现在有些质疑想在此提出：
你即使程序自己发送重复的ACK，但你的操作系统协议栈在接收到回应数据报后会给服务器端发送正确真是的ACK包，因此滑动窗口会自动对于接收端来讲，TCP滑动窗口会向前移动，一旦移动后 ...
Mmmm....
>>你的操作系统协议栈在接收到回应数据报后会给服务器端发送正确真是的ACK包，
>>因此滑动窗口会自动对于接收端来讲，TCP滑动窗口会向前移动...
我的协议栈没有此次通讯的sock句柄，为什么会给服务器端发送正确真的ACK包？？？？
回复于：2006-05-15 16:17:08
引用：原帖由 lxdlj 于 2006-5-15 16:08 发表
说得再明白点就是：服务器端一旦收到来自你操作系统协议栈的ACK包（非你程序发出的），就会自动将服务器端的滑动窗口向前移动。一旦移动后就无法后退。使得攻击无效。有不同意见的话，欢迎发表。
你把攻击程序想的层次太高了，它们都是raw socket直接封装，直接发送。作者原文那只是一个实验，实验的结论成立后，真正的攻击程序就不会那么温柔了。呵呵...TCP协议到是挺了解的，但对攻击程序就是破坏协议这一点了解不足:)
回复于：2006-05-15 16:27:32
引用：原帖由 JohnBull 于 2006-5-15 15:34 发表
sorry,犯晕了，不是saddr和sport不同，而是secret不同。所以你的攻击方法对于Linux而言理论上还是可以持续2分钟的。
但是按我前面所说，你描述的攻击方法还是等于变相“取得了被攻击主机的权限”了啊，你要 ...
>>所以你的攻击方法对于Linux而言理论上还是可以持续2分钟的
错了吧，应该说我有两分钟的时间可以用重放的ack包和服务器建立连接，一旦连接建立，如果我不发fin rst之类的数据包，他就只能靠超时删除。但我会始终制造流量，所以可以说我控制了这条连接。
回复于：2006-05-15 16:36:03
看了，那么这个应用在什么地方啊~~~
回复于：2006-05-15 17:00:46
引用：原帖由 大大狗 于 2006-5-15 16:36 发表
看了，那么这个应用在什么地方啊~~~
我也不知道，只是对原文的一点改进建议。
因为原文我读了好几遍才明白是啥意思
回复于：2006-05-15 17:47:50
引用：原帖由 lxdlj 于 2006-5-15 17:36 发表
这个我不同意你的观点。我指的是被攻击服务器端的发送窗口。
你发送方是采用raw socket,但对 于被攻击服务器来讲，不会区别这一点的。被攻击服务器只知道收到一个tcp报文段，因此会走协议栈，如果不走协议栈 ...
你说的好像是“糊涂窗口综合症”的表现，窗口刚打开一点，立即被对方填充，以致TCP性能就降低了，带宽利用不起来。
但我想本问题和滑动窗口无关呀:)
滑动窗口是给对方发送数据用的，OK？
你指的服务器的发送窗口，应该就是我的接收窗口吧？
我ack包的seq会紧随get request的seq+数据长度，进行填充。所以必定会落在服务器的滑动窗口内部。又因为这个ack没有数据，所以不会导致窗口左边缘移动。
攻击的效果，最终就是对耗，窗口的大小那时都僵住了。
[ 本帖最后由 skipjack 于 2006-5-15 17:50 编辑 ]
回复于：2006-05-15 18:00:17
那不是糊涂窗口综合症。
回复于：2006-05-15 18:11:01
再发表一点我个人的观点：
虽然你用的是RawSocket,但这并不代表你发送的TCP连接就完全绕过了系统。我看了在xfocus发表的文章，别忘记了，连接建立是靠主进程中的connect函数，而并非你自己处理syn-ack.我想你应该清楚connect之后，系统内部会有相关的文件描述符等信息。因此对于tcp的处理，系统还是会参与的。
回复于：2006-05-15 23:42:38
楼主，发帖子前仔细多想想，要是想不明白的话，自己写个程序试试。
回复于：2006-05-16 03:06:45
观望 关注 精彩
回复于：2006-05-16 09:08:56
引用：原帖由 撒哈拉里的鱼 于 2006-5-15 23:42 发表
楼主，发帖子前仔细多想想，要是想不明白的话，自己写个程序试试。
你想到了什么，不防直说。没必要卖关子
回复于：2006-05-16 10:15:05
引用：原帖由 大大狗 于 2006-5-15 16:36 发表
看了，那么这个应用在什么地方啊~~~
引用：
1.用ADSL拨一次号，与ddos防护的服务器进行一次http访问，把此次三次握手的ack包保存起来。当然如果服务器用cookie认证也把http get这个数据包保存。
2.再用ADSL拨一次号，把保存的ack包重放给服务器，把保存的http get request包重放给服务器（当然，这个包你可以自己造，CC就是这么干的）。
3.发送大量的ack，请求服务器重传http response这个大数据包。
“攻击”一个无辜的宽带用户。仅此而已。
回复于：2006-05-16 11:05:22
我来啦
回复于：2006-05-16 11:14:22
引用：原帖由 lxdlj 于 2006-5-15 18:11 发表
再发表一点我个人的观点：
虽然你用的是RawSocket,但这并不代表你发送的TCP连接就完全绕过了系统。我看了在xfocus发表的文章，别忘记了，连接建立是靠主进程中的connect函数，而并非你自己处理syn-ack.我想你应该 ...
不怎么赞同，这个和connect无关，两个世界的事情。显然可以绕过系统建立tcp连接。
回复于：2006-05-16 11:16:38
还是觉得不可行，是否能模拟一下？从理论的高度想实践过渡一下，看看。
回复于：2006-05-16 11:31:22
引用：原帖由 JohnBull 于 2006-5-16 10:15 发表
“攻击”一个无辜的宽带用户。仅此而已。
应该多考滤将来，而不是现在。
本思路有价值的地方：
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中关于Fast Retransmit/Fast Recovery的说明部分。
2.你的ack包构造不好，服务器协议栈还是会利用超时重传，而不是快速重传。
回复于：2006-05-16 11:45:41
引用：原帖由 lxdlj 于 2006-5-15 18:11 发表
再发表一点我个人的观点：
虽然你用的是RawSocket,但这并不代表你发送的TCP连接就完全绕过了系统。我看了在xfocus发表的文章，别忘记了，连接建立是靠主进程中的connect函数，而并非你自己处理syn-ack.我想你应该 ...
我承认你对socket编程、系统调用很熟悉。但对协议具体的作用是什么并不十分了解。
socket不是TCP/IP协议的一部分，它是用户和TCP/IP协议的接口。所以你上面提到的什么connect、主进程，都和TCP协议本身无关。你不防换个场境思考一下，防火墙都是工作在IP层次的，为什么可以处理7层数据包的过滤？难道用到了主进程中的connect函数？
回复于：2006-05-16 12:25:01
楼主，你先别顾着回复，仔细想想。
我今天事情比较多，没时间打太多字，不好意思。
你重放最后一个ACK包，对于静态SYN Cookie的防火墙来说，是可以握手成功，但是你马上更改了IP发请求，这个包防火墙会接受吗？你要知道，你的源IP什么都变了。
回复于：2006-05-16 13:49:43
引用：原帖由 skipjack 于 2006-5-16 11:45 发表
我承认你对socket编程、系统调用很熟悉。但对协议具体的作用是什么并不十分了解。
socket不是TCP/IP协议的一部分，它是用户和TCP/IP协议的接口。所以你上面提到的什么connect、主进程，都和TCP协议本身无关。 ...
劝楼主先弄明白我的意思再回复，呵呵。不妨把基础知识弄扎实了。我忙去了。
回复于：2006-05-16 13:58:28
引用：原帖由 skipjack 于 2006-5-16 11:31 发表
. 真正的威胁不在现在，而是在对“长肥管道”的攻击效果。对方下行带宽越宽，攻击效果越明显。TCP会禁用分片，所以重传数据包大小依靠你与服务器之间最小的那个设备的MTU值，所以你见到的TCP协议的IP首部中的长度字段不会超时1518。但在“长肥管道”中，IP首部的长度字段会达到65535的极大值，对这些数据包的重传攻击，会达到令人吃惊的1:1024的放大效果。
1M对1G
1G对1T
明白？就是因为这点，我才会提供本思路，否则1:25的消耗也是蛮力。
...
楼主啊，先把TCP、IP协议搞清楚再说吧，那些名词的含义弄清楚了再用也不迟。TCP重传数据报的大小可不仅仅简单依赖于MTU哦，呵呵。因素太多了。拜托了，弄明白再用这些词吧。
回复于：2006-05-16 14:11:42
引用：原帖由 skipjack 于 2006-5-16 11:45 发表
我承认你对socket编程、系统调用很熟悉。但对协议具体的作用是什么并不十分了解。
...
拜托，请别乱猜测我会什么不会什么，对什么了解，对什么不了解。没必要吧，哈哈，可能是看我在CU上的等级低一点。呵呵，没什么，平时只看不回，这次实在是不吐不快。
回复于：2006-05-16 14:15:04
恩，感觉还行啊！·~~
就是有点不大懂啊！
回复于：2006-05-16 16:43:42
引用：劝楼主先弄明白我的意思再回复，呵呵。不妨把基础知识弄扎实了。我忙去了。
我想我已经弄的很明白了，playmud也回复了你的看法。如果你感觉系统的tcp协议栈会打扰你对数据包的操作。你可以从dev.c源文件的netif_rx()接口处直接做收包处理。再利用dev_queue_xmit()函数直接发送。应用层程序我工作中涉及的很少，不知道你所指的基础知识是什么？
引用：楼主啊，先把TCP、IP协议搞清楚再说吧，那些名词的含义弄清楚了再用也不迟。TCP重传数据报的大小可不仅仅简单依赖于MTU哦，呵呵。因素太多了。拜托了，弄明白再用这些词吧。
大概有两年时间没有摸协议实现部分了，除非遇到很很细节的地方，否则我想我的知识和阅读源代码的能力，比查阅资源更能找到问题所在。我并没有说重传大小依赖MTU之类的话。而是指明在TCP通讯中一个数据包的大小不会大于路径MTU值，也就限制了利用重传攻击放大的效果。重传的是以前发送过的数据包，这个数据包的大小和以前第一次传输时的大小是一样的。你说的因素太多，不防说出来听听。
引用：拜托，请别乱猜测我会什么不会什么，对什么了解，对什么不了解。没必要吧，哈哈，可能是看我在CU上的等级低一点。呵呵，没什么，平时只看不回，这次实在是不吐不快。
呵呵...积分能说明什么问题呢？我的积分就很高吗？
我称呼了五年的老师(当然不是学校里硬压在我身上的)在CU上的积分也只不过18分。但水平远远高过我。他的blog就在CU上。我每天上来的第一件事，就是看他今天又写了什么文章。
对于“长肥管道”，你说我不能乱讲。不知道你指的又是什么概念。从字面上讲它当然就是那种又长又肥的通讯链路了。2003年人们做过X86平台下Linux的10Gb吐吞测试，把MTU从1500提高到9000时，TCP的性能提高了40-60%，CPU占用率下降一倍，吞吐峰值从1.8Gb/s提升到2.7Gb/s。测试链路全长10037公里。我想这就是书本上说的“长肥管道”了吧。当然，你可能有更好的见解，但从上面的贴子中我没有找到。
我的言语无意挑起争端，相反你的词汇应当润色一下吧。
[ 本帖最后由 skipjack 于 2006-5-16 16:52 编辑 ]
回复于：2006-05-16 16:52:55
拜托，技术讨论，又没对你人身攻击，至于嘛，真受不了。唉。。。。你牛，行了吧？成了吧，你提的观点正确成了吧？真受不了了。。。。
回复于：2006-05-16 16:56:43
唉，前段时间目睹的开源世界的一位鼻祖，人家那风范，好像给人家提点自己的意见也没遇到象skipjack 这位老大的脾气。唉。。
回复于：2006-05-16 17:01:22
引用：原帖由 lxdlj 于 2006-5-16 16:52 发表
拜托，技术讨论，又没对你人身攻击，至于嘛，真受不了。唉。。。。你牛，行了吧？成了吧，你提的观点正确成了吧？真受不了了。。。。
真搞不明白，我怎么说都会被你曲解吗？
回复于：2006-05-16 17:13:26
我始终都是求同存异，你有你的观点，我有我的观点，对吧？大家在技术上有争议是正常的，但何必要对人家会什么不会什么做出评价呢？
我在前几份帖子里也只是写出我个人的认识，如果你不认同我的观点，那就从技术上说出原因，但何必要对我的技术加以评论呢。你自己看看你对我贴子的回复吧，受不了。。。。。
来梳理一下：
你看，我是这样说的："我现在有些质疑想在此提出：....这是我的一点看法。"
然后你看你回答里就有：“呵呵...TCP协议到是挺了解的，但对攻击程序就是破坏协议这一点了解不足”
后来我又说：“再发表一点我个人的观点：”
你回答：“我承认你对socket编程、系统调用很熟悉。但对协议具体的作用是什么并不十分了解。”
为了让你也体验一下你这样说别人的感受，我就发了后面几个帖子，你受不了了。但你那样说别人，我可没你那么大的脾气啊
＝＝＝＝＝＝＝＝＝
我始终都是在说明我的观点，又没非要向你证明我会什么，不会什么。你干吗非要说我对这了解对那不了解。我好不明白啊
[ 本帖最后由 lxdlj 于 2006-5-16 17:24 编辑 ]
回复于：2006-05-16 17:27:36
引用：原帖由 lxdlj 于 2006-5-16 17:13 发表
我始终都是求同存异，你有你的观点，我有我的观点，对吧？大家在技术上有争议是正常的，但何必要对人家会什么不会什么做出评价呢？
我在前几份帖子里也只是写出我个人的认识，如果你不认同我的观点，那就从技术上 ...
论坛发言有一定的规则，但有时甚至一两句粗口，如果没有恶意，大家彼此也是可以接受的。是吧？
如果真的很过份，版主第一个就不会放过偶了，对不对？
每个人的心理承受能力是不同的，呵呵...如果你认为我说过份了，我下次注意就是了。
[ 本帖最后由 skipjack 于 2006-5-16 17:33 编辑 ]
回复于：2006-05-16 17:42:53
引用：原帖由 lxdlj 于 2006-5-16 17:13 发表
我始终都是求同存异，你有你的观点，我有我的观点，对吧？大家在技术上有争议是正常的，但何必要对人家会什么不会什么做出评价呢？
我在前几份帖子里也只是写出我个人的认识，如果你不认同我的观点，那就从技术上 ...
呵呵......我说的好像是有点过份 :)
对不起，不好意思，下次注意:mrgreen:
回复于：2006-05-16 17:43:07
希望大家以后还能在技术方面互相讨论交流
[ 本帖最后由 lxdlj 于 2006-5-16 18:15 编辑 ]
回复于：2006-05-17 00:15:36
引用：原帖由 skipjack 于 2006-5-16 11:31 发表
应该多考滤将来，而不是现在。
本思路有价值的地方：
1. 利用一条合法连接，对服务器进行下行带宽攻击，现在的“状态检测”设备不一定可以发现
2. 目标服务器应用层程序感知不到这种攻击，可以逃避基于应 ...
我已经明白你的意思了，你的方案技术上是成立的，你后来提出的两次ADSL拨号的手段也是成立的。
但问题是如果你要攻击[color=Red]某一台特定的靶机[/color]，而不是一个随机的无辜者的话，一切又回到了我一开始的问题上：你如何得到靶机的一个合法的ACK分段？除非你hack掉syncookie使用的加密算法反推出secret(对Linux而言几乎不可能，用的是sha)。
又如果你能直接拿到靶机的本地权限或者能拿到他的上游路由器，那么还用得着flood吗？直接该干嘛干嘛了，何必兜这么大圈子呢。:mrgreen:
你的方案有点象：“如果我是国家主席，我就可以xxx，然后xxx，再然后xxx...”
每步都符合逻辑，但问题是你怎么当国家主席呢？而且你如果真的当了国家主席，你那时候还会在乎那些xxx吗？
:)
回复于：2006-05-17 09:26:06
楼上的看看原文章
回复于：2006-05-17 18:52:04
还没细看...但要先留名!
强贴!!
回复于：2006-05-19 08:53:15
个人觉得没有实用价值
回复于：2006-05-19 12:52:15
这种可以归到 “包”欺骗这一类型 我感觉利用的价值不是很大！ 劝你不要浪费时间！ 还是搞点其他的吧！中国 还没有出现这样黑客的土壤！！
回复于：2006-05-21 10:34:15
发表一下我的看法，和大家讨论。
建议修改一下攻击过程，由程序自动完成整个攻击过程。首先声明，我不编程已经很多年，事实上大学毕业以后就几乎没有写过程序，这里不讨论实现，只讨论一个思路。
我们假设我们有一条ADSL线路，ok，现在我们来利用ADSL可以同时打电话和上网的特性来实现这个攻击。首先进行ADSL拨号，然后利用其电话接口再利用PSTN拨号建立第二条互联网连接，注意这两个连接不要在一个网段，比如你在上海用ADSL上，然后拨01095963，至于电话费嘛，嘿嘿，自己付吧，谁说当黑客没有成本。
根据一般的原则，第二个连接的默认网关会作为系统的默认网关，此时用第二个IP地址，自己构造正常的SYN向目标发起连接请求，当收到SYN+ACK包以后，断开PSTN的拨号连接。继续利用刚才PSTN拨号的IP地址，根据刚才收到SYN+ACK包，构造ACK包，完成三次握手。然后都利用PSTN拨号的IP地址不断的发起错位的ACK包，让对方的服务器不断的重发。
以上过程应该可以用程序自动实现，至于攻击效果嘛，我这里无法判断，这和对方的设计方式有关，比如对方如果发一个很小的包过来，然后等待确认包以后再发送大包的话，恐怕效果就会很差！
回复于：2006-05-21 20:12:35
引用：原帖由 zeroflag 于 2006-5-21 10:34 发表
发表一下我的看法，和大家讨论。
建议修改一下攻击过程，由程序自动完成整个攻击过程。首先声明，我不编程已经很多年，事实上大学毕业以后就几乎没有写过程序，这里不讨论实现，只讨论一个思路。
我们假设我们有 ...
思路不错,省得猜序号了
回复于：2006-05-21 21:05:34
引用：原帖由 keelee 于 2006-5-19 12:52 发表
这种可以归到 “包”欺骗这一类型 我感觉利用的价值不是很大！ 劝你不要浪费时间！ 还是搞点其他的吧！中国 还没有出现这样黑客的土壤！！
我的工作就是这个,所以谈不上是浪费时间.
以前做程序的时候,因为TCP序号乱序,引起双方大量数据包重传,CPU连续高负载.BUG最终找到了,但那时没有注意到利用价值.
看了我引用的原文文章后,突然想通了点什么.呵呵......
BUG场境我试图恢复.但没有成功,所以贴出来供大家讨论.
"包"欺骗的范围实在是太广了.所以你这么一说,我还真不知道怎么反驳你了.呵呵......所以只能引一段<<黑客张大民>>中的文字了.我想我指的这个问题应该细化在[color=Red]"逻辑运行攻击"[/color]这一类中.
引用：
对没有状态的网络协议的异常报文攻击是比较简单的。你构建好了异常报文，只管发就是了．但对于有状态的网络协议来说，如果它当前不在某一个状态，而你给它发布一个报文，它根本就不会处理这个报文，也就根本不会达到攻击的效果．你需要先送几个有效的报文，驱动网络协议到达某个状态，然后再送一个在这个状态内被网络协议接收的异常报文，才能达到攻击的效果”，老头说， “每一个协议的有限状态机都是不要一样的，BGP有BGP自己的状态转换，TCP有TCP自己的状态
转换．所以如果你想攻击有状态的协议，要对协议如何运行非常了解才行”．
“啊”，张大民点头， “看样子还是很难”。
“当然”，老头说，“如果容易的话，就不是高层次黑客追求的目标了”．老头笑
这说， “但异常报文和低速洪水攻击还不是攻击网络协议中最麻烦的方法”．
“啊?”，张大民道，还有什么别的，比这两个还麻烦?”。张大民问．
[color=Red]“逻辑运行攻击”[/color]，老头说．
“什么是逻辑运行攻击?”，张大民问．
“就是对网络协议算法的攻击”，老头说， “也就是说，能利用网络协议实现中逻辑算法的漏洞，找到逻辑算法中的弱点．能达到这一个阶段，需要对一个协议有很深的理解，不仅包括数据报文格式，还有协议具体的运行过程和可能出现的各种异常情况。”
“呕”，张大民一脸不解的问， “哪要怎么看?”。
“给你举个例子”，老头说． “知道前一阵TCP窗口大小的重至攻吧。”老头问．
“啊，知道，就是一个美国的小子发现，他发现了TCP算法中一个问题，可以用和少的攻击报文来切断一个TCP的联系”，张大民说。
“正是”，这是比较高级的协议攻击方法了，[color=Red]为此TCP的RFC还要修改一下[/color]”，老头说， “当然，如果你能发现这样的一个漏洞，那么你也可以出名了”．
“那有没有系统的方法可以发现一个网络协议中的逻辑运行漏洞呢?”，张大民问．
“呵呵，你还真的是很好问”，老头笑道． “[color=Red]在这个问题上是没有捷径可走的，唯有专下心来，刻苦钻研一个网络协议，成为这个协议的专家，才能在这上面有所作为．[/color]但一旦你达到了这个层次，恐怕网络安全界不知道你的人就没几个了．”。
“是这样”，张大民感慨的说．心想：但是网络协议这一块，就有这么多的难度，每一个层次都有不同的方法和窍门。关键是不要被问题的表明所吓倒，要看清问题的本质，找到问题的共同点，摸索出发现漏洞的方法。 “那按照攻击的难度来说，对于网络协议的攻击方法应该按照这样来排序喽”，张大民说． “
． 量简单的是无状态的异常报文攻击．
． 然后是有状态的异常报文攻击．
． 然后是低速洪水攻击来远程攻击数据结构
． [color=Red]最难的就是对网络协议逻辑和算法的攻击．[/color]
“是”，老头赞许的看了张大民一眼， “你的悟性还是不错的．”．
[ 本帖最后由 skipjack 于 2006-5-21 22:15 编辑 ]
回复于：2006-05-23 00:19:03
字都懂,就是不知道什么意思.
回复于：2006-05-23 09:13:48
……为啥要换个机器回放？
回复于：2006-05-24 15:31:01
引用：原帖由 skipjack 于 2006-5-15 13:11 发表
:em17:
其实ack包的作用就是发送错误的TCP确认序号，这就是为什么管它叫“序号乱刀”的原因。
呵呵...举个例子，两个人打招乎：
A君：你好
B君：你也好
A君：你吃了吗？
B君：吃了呀
A君：你能把 ...
哈哈，这个有意思。
回复于：2006-05-24 21:45:09
这两天我的测试系统出了怪问题，跟网管PK了一下午
我有一个测试客户端，模拟浏览器发送请求到测试服务器，
客户端和服务器都是自己编写的TCP程序，两个程序都是相同的编程框架
单进程多线程，线程池上限是1000，
被测对象是个代理服务器程序
客户端IP是10.0.0.13，代理服务器是10.0.0.10，测试服务器是11.0.0.13
客户端访问代理服务器，代理服务器从测试服务器取HTTP响应返回给客户端
客户端和代理服务器在内网，测试服务器在代理服务器屁股后头与其他任何网络不连接
客户端开了800个线程去访问代理服务器
昨天网管就找我，说我的屋子有台10.0.0.13的机器狂发包，防火墙都快被整死了
然后我和网管分别用自己的机器开ethereal抓包，果然10.0.0.13发疯了，
每秒广播将近3500个TCP的ACK包
这些包的内容全都是: TCP 源地址10.0.0.13 端口随机 目的地址 10.0.0.10 目的端口是被测的
代理服务器端口 类型是ACK
我就想到了这个贴
ACK应该是TCP三步握手的最后一步，按理说不可能被广播，
而且我编程序从来不去动协议栈，不可能是我的程序具有广播ACK的功能
那为什么ACK会跑到整个局域网中去呢？
从tcpdump看数量是随机的，某些时刻一个都不出现，某些时刻tcpdump输出信息翻屏象飞一样
我曾经怀疑二层交换机是不是死掉了变成了HUB，但抓包程序看不到同在一起的二层交换机的非二层
广播包，而且10.0.0.13的ACK包的目的MAC也确实是10.0.0.10的网卡MAC地址
网管已经把防火墙上的10.0.0.0/24网段一律drop掉（防火墙内网地址是192.168.x.0/24）
我现在头疼的是：ACK为什么被广播出来了？
如果ACK是TCP重传导致的，它也不该被广播啊
不久我要修改程序，需要将持续并发升到10000左右
跟网管PK的结果是，我的机器装2块网卡，一块专门和测试网10.0.0.0/24连接，
另一块接内网，严禁路由测试网络的包到内网
附：
所有的连接都是百兆，所有的网卡都是i82559，交换机都是二层的（有TP-LINK也有D-LINK），
防火墙负责NAT内网到公网
回复于：2006-05-25 10:38:32
楼上能不能把包抓下来分析一下？
不知道你说的ack广播是什么？
抓包的机器ip是多少？
回复于：2006-05-25 10:50:50
注释了一下:) 最好贴出抓包数据
引用：原帖由 safedead 于 2006-5-24 21:45 发表
这两天我的测试系统出了怪问题，跟网管PK了一下午
我有一个测试客户端，模拟浏览器发送请求到测试服务器，
客户端和服务器都是自己编写的TCP程序，两个程序都是相同的编程框架
单进程多线程，线程池上限是1000，
被测对象是个代理服务器程序
客户端IP是10.0.0.13，代理服务器是10.0.0.10，测试服务器是11.0.0.13
客户端访问代理服务器，代理服务器从测试服务器取HTTP响应返回给客户端
客户端和代理服务器在内网，测试服务器在代理服务器屁股后头与其他任何网络不连接
客户端开了800个线程去访问代理服务器
昨天网管就找我，说我的屋子有台10.0.0.13的机器狂发包，防火墙都快被整死了
然后我和网管分别用自己的机器开ethereal抓包，果然10.0.0.13发疯了，
每秒广播将近3500个TCP的ACK包
这些包的内容全都是: TCP 源地址10.0.0.13 [color=Red]端口随机[/color] [color=Green]（不在同一连接上，肯定不是重传的数据包）[/color]目的地址 10.0.0.10 目的端口是被测的
代理服务器端口 类型是ACK
我就想到了这个贴
[color=Red]ACK应该是TCP三步握手的最后一步[/color][color=Green]（握手最后一个ACK是所有ACK包的充分条件，而不是必要条件）[/color]，按理说不可能被广播，
而且我编程序从来[color=Red]不去动协议栈[/color][color=Green]（协议本身应该不会出现过度重传的可能）[/color]，不可能是我的程序具有广播ACK的功能
那为什么ACK会跑到整个局域网中去呢？
从tcpdump看数量是随机的，某些时刻一个都不出现，某些时刻tcpdump输出信息翻屏象飞一样
我曾经怀疑二层交换机是不是死掉了变成了HUB，但抓包程序看不到同在一起的二层交换机的非二层
广播包，而且10.0.0.13的ACK包的目的MAC也确实是10.0.0.10的网卡MAC地址
网管已经把防火墙上的10.0.0.0/24网段一律drop掉（防火墙内网地址是192.168.x.0/24）
我现在头疼的是：[color=Red]ACK为什么被广播出来了[/color]？[color=Green]（TCP是点到点通讯，所以你所指的广播，应该是被大量发送的意思吧？）[/color]
如果ACK是TCP重传导致的，它也不该被广播啊
不久我要修改程序，需要将持续并发升到10000左右
跟网管PK的结果是，我的机器装2块网卡，一块专门和测试网10.0.0.0/24连接，
另一块接内网，严禁路由测试网络的包到内网
附：
所有的连接都是百兆，所有的网卡都是i82559，交换机都是二层的（有TP-LINK也有D-LINK），
防火墙负责NAT内网到公网
[ 本帖最后由 skipjack 于 2006-5-25 10:53 编辑 ]
回复于：2006-05-25 10:55:35
引用：原帖由 cnadl 于 2006-5-23 09:13 发表
……为啥要换个机器回放？
避免包反弹回来
回复于：2006-05-25 11:05:10
也参一脚,
前面有位仁兄说了,你重发ACK包时使用的另一个IP了吧,这时发送的IP源址不同了,接受的服务器自然会DROP掉的.你要用另一个IP地址目的是不接受目标机器的回复以达到低成本来消耗对方资源吧?
而要伪装IP则要修改ACK包的数据了,这就涉及了加密问题,一般是公私密钥对称加密吧,如果没有目标服务器的私钥,你能解读却不能改写.
鉴于要求同IP的原因,因此只能用同一个IP地址不断发请求,然后抢在系统接收之前DROP掉目标系统的回复,继续发ACK以达到消耗对方,但这跟完整的请求有什么大的区别吗?只是类似单机DoS吧.
回复于：2006-05-25 11:23:11
引用：原帖由 crazysoul 于 2006-5-25 11:05 发表
也参一脚,
前面有位仁兄说了,你重发ACK包时使用的另一个IP了吧,这时发送的IP源址不同了,接受的服务器自然会DROP掉的.你要用另一个IP地址目的是不接受目标机器的回复以达到低成本来消耗对方资源吧?[color=Red]是[/color]
而要伪装IP则要修改ACK包的数据了,这就涉及了[color=Red]加密???[/color]问题,一般是[color=Red]公私密钥对称加密???[/color]吧,如果没有目标服务器的私钥,你能解读却不能改写[color=Red]电子签名啥时成了IPV4的一部分了???[/color].
[color=Red]鉴于要求同IP的原因,因此只能[/color]用同一个IP地址不断发请求,然后抢在系统接收之前DROP掉目标系统的回复,继续发ACK以达到消耗对方,但这跟完整的请求有什么大的区别吗?只是类似单机DoS吧.
[color=Green]看来，我上面写了那么多东西，我都白写了呀:([/color]
[ 本帖最后由 skipjack 于 2006-5-25 11:27 编辑 ]
回复于：2006-05-25 11:32:10
哈,那些是我想当然的,所以有错不奇,见笑了.
想请教下,用不同IP能重发ACK包,而目标服务器不会DROP掉?
回复于：2006-05-25 11:37:50
引用：原帖由 crazysoul 于 2006-5-25 11:32 发表
哈,那些是我想当然的,所以有错不奇,见笑了.
想请教下,用不同IP能重发ACK包,而目标服务器不会DROP掉?
用IP地址为A的主机，发送IP地址为B的ACK数据包，目标服务器分辩不出来。协议部分没有这方面的认证机制
|
