一种新的带宽攻击方式

skipjack

原帖由 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包构造不好，服务器协议栈还是会利用超时重传，而不是快速重传。

skipjack

原帖由 lxdlj 于 2006-5-15 18:11 发表
再发表一点我个人的观点：
虽然你用的是RawSocket,但这并不代表你发送的TCP连接就完全绕过了系统。我看了在xfocus发表的文章，别忘记了，连接建立是靠主进程中的connect函数，而并非你自己处理syn-ack.我想你应该 ...

我承认你对socket编程、系统调用很熟悉。但对协议具体的作用是什么并不十分了解。
socket不是TCP/IP协议的一部分，它是用户和TCP/IP协议的接口。所以你上面提到的什么connect、主进程，都和TCP协议本身无关。你不防换个场境思考一下，防火墙都是工作在IP层次的，为什么可以处理7层数据包的过滤？难道用到了主进程中的connect函数？

撒哈拉里的鱼

楼主，你先别顾着回复，仔细想想。
我今天事情比较多，没时间打太多字，不好意思。

你重放最后一个ACK包，对于静态SYN Cookie的防火墙来说，是可以握手成功，但是你马上更改了IP发请求，这个包防火墙会接受吗？你要知道，你的源IP什么都变了。

lxdlj

原帖由 skipjack 于 2006-5-16 11:45 发表


我承认你对socket编程、系统调用很熟悉。但对协议具体的作用是什么并不十分了解。
socket不是TCP/IP协议的一部分，它是用户和TCP/IP协议的接口。所以你上面提到的什么connect、主进程，都和TCP协议本身无关。 ...

劝楼主先弄明白我的意思再回复，呵呵。不妨把基础知识弄扎实了。我忙去了。

lxdlj

原帖由 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哦，呵呵。因素太多了。拜托了，弄明白再用这些词吧。

lxdlj

原帖由 skipjack 于 2006-5-16 11:45 发表

我承认你对socket编程、系统调用很熟悉。但对协议具体的作用是什么并不十分了解。
...

拜托，请别乱猜测我会什么不会什么，对什么了解，对什么不了解。没必要吧，哈哈，可能是看我在CU上的等级低一点。呵呵，没什么，平时只看不回，这次实在是不吐不快。

rosebush

恩，感觉还行啊！·~~
就是有点不大懂啊！

skipjack

劝楼主先弄明白我的意思再回复，呵呵。不妨把基础知识弄扎实了。我忙去了。

我想我已经弄的很明白了，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 编辑 ]

lxdlj

拜托，技术讨论，又没对你人身攻击，至于嘛，真受不了。唉。。。。你牛，行了吧？成了吧，你提的观点正确成了吧？真受不了了。。。。

lxdlj

唉，前段时间目睹的开源世界的一位鼻祖，人家那风范，好像给人家提点自己的意见也没遇到象skipjack 这位老大的脾气。唉。。