基于freebsd5.3下 PF synproxy的DDOS防范方案(转载+评论)

4dian

syncache
统计pps的这个不太准
3w好像也没必要防了
>;我个人实在ethernet bridge上面实现的 效果还不错哈  已经有产品出了
楼主where 用bsd做防火墙？

zjzf_1

加精又取消  为什么呀

colddawn

zjzf_1,不好意思我觉得概念不清的应该是你，所谓“代理”就是两方作通讯时通过一个中间人，甲方把数据交给中间人，中间人处理过后交给乙方。
synproxy基本原理不过是“中间人”使用乙方的ip地址，受到syn包后，代替乙方回syn/ack给甲方，如果甲方有回答，再发送syn给乙方，就避免了甲方用伪造ip作synflood。
普通网关式防火墙，是需要把乙放入内网，防火墙配乙的ip，把经过验证的包nat给乙方，就如楼主所转文章。
现在的问题是工作在桥模式下的话，这个中间人（防火墙）是隐藏的，不管甲还是乙都不知道其存在，优点是不修改现有网络结构，但是对于实现proxy就比较麻烦，所以pf的synproxy目前是不支持bridge方式下的proxy的，但是从原理来讲不是没有可能实现，不过要实现的话考虑的内容就要多很多了，双方的通讯你都要截获、分析、修改，并且需要伪装成某一方来完成握手，即使是实现了，可能效率上也有很大问题。

对于4dian    的解决方案比较感兴趣，如果可以的话，可否讲一下实现机制或者给些代码看看？
3w pps就撑不住了？
按照syn包40字节来算，40*3w=1200000bytes
再*8=9600000bits/sec
也就是9M的流量，好像不少软件防火墙使用的类似syncookie的技术都能在这种流量下基本不影响访问吧？

zjzf_1

你可以联系我 测试下我的 qq17405718   msn bsder@msn.com

pf肯定不是因为麻烦 所以不实现 否则他们就去使用 iptable 或者ipfw了

可能是他们觉得在网络层对运输曾处理 不太合适吧

既然你 认为我也 比较糊涂 那我也不再和你争什么了 或许我真得不清楚吧

qintel

pf的synproxy 实现在nat 上
这可不是 个好的选择    低效呀   而且要改变网络拓扑

我粗略的看了看pf  发表点看法  不当之处希望高手指出

pf对每一个连接要用struct pf_state这个数据结构保存连接状态

pf通过调用RB_FIND RB_INSETR... ...完成对连接状态表的操作(openbsd/src/sys/tree.h)

这是一个树形结构好像叫什么red-black trees

我要说的是 我觉得 对防火墙这种 实时要求比较高的东西上 我觉得这种做法不是很妥当   我建议用hash 分段  来处理这个问题


以上两点 我个人认为 是pf synproxy 不怎么样的关键原因

我个人实在ethernet bridge上面实现的 效果还不错哈  已经有产品出了

好像，粗略，您是懂一点，但也不用忽悠别人，吓别人吧。下次写就写条理清楚的出来，不过估计您写不出来。整个文章就三，4句有关技术的话，其它都是评论性的。

fangjiafu

留个脚印，支持一下！