多线程SYN攻击工具0.2版,加了MAC伪装

daniel2000

是这样用吗？
./awl -d 192.168.0.200 -p 80
192.168.0.200是目标的IP

但的我这样做以后，效果是局域网中所有的windows机器都收到攻击（天网防火墙的报警），但是这台目标主机（linux开着apache）好象没有受到攻击，netstat -na里看不到有连接
这是怎么回事？？

ssffzz1

要加－m参数指定被攻击机器的ＭＡＣ地址，并且ＭＡＣ和ＩＰ要对应正确．

上面的用法在０．１版本可以的．这是加了源ＭＡＣ伪装的版本．

独孤九贱

最近正好在Linux 上实现一个基于Syn Cookie的网关型的防御，空了可以试试矛尖还是盾钝

ssffzz1

等你好结果，等你好结果，

colddawn

原帖由 独孤九贱 于 2007-2-5 19:34 发表于 53楼  
最近正好在Linux 上实现一个基于Syn Cookie的网关型的防御，空了可以试试矛尖还是盾钝

从上次你提问的问题就发觉你在做的很像syncookie firewall，现在看看果然是，哈哈。
是基于netfilter的吗？是的话建议别用conntrack跟踪连接，连接状态表的效率是最关系到效率的东西。
另外如果做网关式的，顺便也看看能不能跑网桥。
最后就是期待大作了，当然是如果没有什么商业上的保密限制的话。

独孤九贱

原帖由 colddawn 于 2007-2-5 22:37 发表于 55楼  


从上次你提问的问题就发觉你在做的很像syncookie firewall，现在看看果然是，哈哈。
是基于netfilter的吗？是的话建议别用conntrack跟踪连接，连接状态表的效率是最关系到效率的东西。
另外如果做网关式的 ...

大哥，偶也没有办法呀……要自己实现一个TCP协议的状态跟踪有些难度，偶现在一个人，第一个版本是利用了Netfilter的连接跟踪……并不能在网桥下跑，目前可以跑起来了，呵呵，近期优化算法和代码，以后再考虑自己实现一个TCP的状态跟踪，无论怎么说，先跨出从无到有的第一步吧……

colddawn

原帖由 独孤九贱 于 2007-2-6 12:33 发表于 56楼  


大哥，偶也没有办法呀……要自己实现一个TCP协议的状态跟踪有些难度，偶现在一个人，第一个版本是利用了Netfilter的连接跟踪……并不能在网桥下跑，目前可以跑起来了，呵呵，近期优化算法和代码，以后再考虑 ...

个人感觉conntrack是个超复杂的东西，如果是用于syncookie firewall的话，只需要区分NEW，ESTABLISH两种状态，并在后者中进行seq/ack的调整就可以，而conntrack本身远比这个复杂，所以我认为自己实现状态表可能更简单一些。
然而我记得你似乎已经全面分析过conntrack了，可能你用它来实现会更得心应手吧，不管怎样先作出来才是，支持这种思路。

独孤九贱

原帖由 colddawn 于 2007-2-6 12:38 发表于 57楼  


个人感觉conntrack是个超复杂的东西，如果是用于syncookie firewall的话，只需要区分NEW，ESTABLISH两种状态，并在后者中进行seq/ack的调整就可以，而conntrack本身远比这个复杂，所以我认为自己实现状态表 ...

呵呵，没得那么简单的，syncookie中需要对TCP的状态，要处理一系列的问题，不过Netfilter中Conntrack TCP倒是一个完整的示例，我想我以后要移植到网桥下，也得参考它来实现的

其实，SynCookie和SynProxy都存在一个致命的弱点，就是网关的伪装应答包，会造成上级网关的双倍流量，如果攻击流量达到50Mb，也就是说上级网关要收50Mb的攻击，转发50Mb的攻击包出来，然后，再收到50Mb的应答，再转发……所以，当以小搏大不能实现时，那么就做50Mb的流量攻击，可以挤占满100Mb的带宽，也可以的

事实上，从另一个角度来讲，Syn flooding的攻击，很大程序上取决于发包的效率，以达到最短时间发出最大流量的包，由于缓存方面、系统调用上下文切换的开销等因素，我一向不喜欢在应用层做这个事情。另一方面，算法也相当重要，将数据包做得线性分布，没有规律，让试图利用包过滤的想法彻底XX。

[ 本帖最后由 独孤九贱 于 2007-2-6 13:00 编辑 ]

platinum

真不错，多向九贱学习！

colddawn

原帖由 独孤九贱 于 2007-2-6 12:52 发表于 58楼  


呵呵，没得那么简单的，syncookie中需要对TCP的状态，要处理一系列的问题，不过Netfilter中Conntrack TCP倒是一个完整的示例，我想我以后要移植到网桥下，也得参考它来实现的

其实，SynCookie和SynProxy ...

前一阵子我本有自己写一个这方面的项目的计划来的，后来因为时间原因作罢，但思路我已经考虑过了，关键点不过是以下几点，看看咱们的想法是否相同:

1，fw接到syn后，计算cookie写入回发的ack中，往回发synack，丢弃此syn。
2.1，flooding伪造的syn包因为不会对synack有响应，所以不会有接下来的包到达防火墙，即使有，cookie应该也是不对的，可以判断cookie并直接丢弃。
2.2，正常连接的机器收到带有cookie的synack后回应synack，fw判断此回应包发现cookie正确，予以保留，同时继续下一步处理。
3，fw发syn给受保护的服务器，服务器有响应synack包则保留此包，则建立状态表，记录的内容基本上只有连接双方的IP/端口，状态，以及seq的校正值。
4，fw将保留的synack通过校正值后发往服务器，连接完成建立。
5，以后连接双方的包经由fw后只需修正seq校正值即可放行。

其中有几个难点和要注意事项：
1，一定要在收到synack后再填充状态表，在初始就建立则很快会造成状态表填满，这方面不知conntrack是否能保证。
2，cookie算法选择，使破坏者很难摸清seq规律构造synack包。
3，syn包很可能带有option和timestamp，这个很难处理。
4，不能每逢syn必synack，就像你说的这样很容易把下行带宽堵塞，需要加上一定的机制来分辨出哪些源IP一定是伪造的，例如通过icmp host unreachable统计IP段等等。