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

领测软件测试网
出自[url]http://shidongxue.blogdriver.com/shidongxue/699924.html[/url]
[code:1:521f71e2b6]基于freebsd5.3下 PF synproxy的DDOS防范方案- -
                                       


基于freebsd下 PF synproxy的DDOS防范方案

[摘要]
本文讲述了基于freebsd5.3 下PF synproxy的DDOS防范方案，对于中小型企业抵挡每秒3万个包的攻击不失为一种可用方案。

[环境]
防火墙：台式机P4 2G，512内存。 FREEBSD5.3
WEB服务器：笔记本PIII 700 256m, suse linux enterprise server 9
攻击机器：笔记本：PIII 700 256M， WIN2000 SERVER
攻击工具：HGOD v0.4
测试机：笔记本：PIII 700

拓朴：
=====
防火墙：xl0 外网卡：172.16.0.1; sis0 内网卡：192.168.100.1
WEB服务器：eth0 192.168.100.2
攻击机：172.16.0.194
测试机：172.16.0.195

一、编译内核
#cd /usr/src/sys/i386/conf
#cp GENERIC billy-pf
#vi billy-pf
添加：
device pf
device pflog
device pfsync
options ALTQ
options ALTQ_CBQ # Class Bases Queuing (CBQ)
options ALTQ_RED # Random Early Detection (RED)
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC)
options ALTQ_PRIQ # Priority Queuing (PRIQ)
options ALTQ_NOPCC # Required for SMP build
#config billy-pf
#cd ../compile/billy-pf
#make depend;make make install
二、编辑启动脚本/etc/rc.conf
pf_enable="YES" # Enable PF (load module if required)
pf_rules="/etc/pf.conf" # rules definition file for pf
pf_flags="" # additional flags for pfctl startup
pflog_enable="YES" # start pflogd(8)
pflog_logfile="/var/log/pflog" # where pflogd should store the logfile
pflog_flags="" # additional flags for pflogd startup

gateway_enable="YES"

三、修改/etc/pf.conf
ext_if="xl0"
int_if="sis0"
internal_net="192.168.100.1/24"
external_addr="172.16.0.1"
web_server="192.168.100.2"
nat on ＄ext_if from ＄internal_net to any -> (＄ext_if)
#(＄ext_if) 括起来的原因：如果你使用DHCP还配置外部地址，不括起来会存在问题。如果你分配的IP地址改变了，NAT仍然会使用旧的IP地址转换出去的数据包。这会导致对外的连接停止工作。为解决这个问题，应该给接口名称加上括号，告诉PF自动更新转换地址。
rdr on ＄ext_if proto tcp from any to ＄external_addr/32 port 80 -> ＄web_server port 80
#这一行重定向了TCP端口80（web服务器）流量到内部网络地址＄web_server。因此，即使＄web_server在网关后面的内部网络，外部仍然能够访问它。 
pass in on ＄ext_if proto tcp from any to ＄web_server port 80 flags S/SA synproxy state 
#连到外部地址的80端口，作SYNPROXY，以防DDOS攻击

四、修改192.168.100.2的网关IP为192.168.100.1

五、修改/etc/sysctl.conf
net.inet.ip.forwarding=1
使防火墙进行IP转发

重启

六、测试
攻击前先访问http://172.16.0.1/index.html，正常打开了WEB服务器上的主页 
攻击：
往防火墙的外部IP172.16.0.1的80端口发动DDOS攻击。
hgod 172.16.0.1 80
观察WEB服务器192.168.100.2上的80端口连接情况和收到的包数。
统计防火墙上受攻击强度（包/每秒）。
speed.sh
#!/bin/sh
oldval=0
curval=0
while true
do
curval=`netstat -i | grep xl0 | head -1 | awk '{print ＄5}'
if [ ＄oldval = 0 ]; then
old=＄curval
else
echo `date`" pkg inbound rate on xl0: ＄((＄curval-＄oldval)) pps"
oldval=＄curval
fi
sleep 1
done
`


七、测试结果

DDOS攻击下，防火墙接收到的包速率为：2.6万-2.8万个包每秒
在PF的保护下，仅DDOS攻击时，WEB服务器没有收到一个包，说明防火墙全挡住了非法包。
去掉SYNPROXY的保护，即最后一条规则时，WEB服务器收到的包速成率与防火墙收到的包相当。访问WEB服务器时被拒绝。
在PF保护下，WEB_server的访问正常。

结论：
基于PF的防DDOS攻击对于每秒3万个包以下的攻击抵挡效果出色。对于更大流量的攻击，有待进一步测试。

进一步的工作:

结合ALTQ中RED算法的连接耖尽攻击防范。
尽管对于非法IP的拦截PF可以大显身手，但对于完整TCP连接的消耖攻击，同样非常重要，下一篇将讲述如何利用RED（Random Early Detection)算法来适当保护合法用户。利用二八原则来区分用户的合法性。在表面上区分不了连接的合法性时，只能作适当的牺牲，牺牲突然前来地访问的用户。

作为保护服务器的不停机运行的第三把利剑，还可结合负载均衡来增强WEB服务器的高可用性.[/code:1:521f71e2b6]



##################write by zjzf_1#######################

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上面实现的 效果还不错哈 :) 已经有产品出了

###########加精后修改##################

我上面 只是借转载文章粗略的说了一下pf的synproxy   如果朋友们愿意 深入讨论这个问题

我们可以深入的讨论一下     顺便谢谢斑竹[/url]

ayazero 回复于：2005-07-14 08:58:53

给你精华了，呵呵~

我爱钓鱼 回复于：2005-07-14 09:30:49

[quote:1b568fe105="ayazero"]给你精华了，呵呵~[/quote:1b568fe105] 这个是转贴,楼主已经说明了,不能是原创吧?  :roll:

visualj 回复于：2005-07-14 12:31:31

好文章就行了，顶

zjzf_1 回复于：2005-07-17 02:12:14

没收到预期效果

zjzf_1 回复于：2005-07-17 02:13:16

懂行的看门道  不懂得 帮我 顶

squall1 回复于：2005-07-17 06:00:44

多谢兄弟指教，我加我网站里了。

colddawn 回复于：2005-07-21 07:42:56

楼主，bridge方式下如何实现syn代理？ 既然没有ip，也就无法“代理吧”，只能中途“伪装”一下吧。

剑心通明 回复于：2005-07-21 08:33:59

收藏一下

zjzf_1 回复于：2005-07-21 10:55:46

colddawn     所谓的代理  就是代替原有的服务提供单元 完成服务 可以有tcp 代理 ip代理 arp代理 ipx代理 以太网有arp代理 不一定要用sock代理或者http代理 把你对代理网络服务的认识局限住

4dian 回复于：2005-07-21 13:34:53

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

zjzf_1 回复于：2005-07-22 11:00:46

加精又取消  为什么呀

colddawn 回复于：2005-07-22 21:15:57

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 回复于：2005-07-23 09:51:52

你可以联系我 测试下我的 qq17405718   msn bsder@msn.com pf肯定不是因为麻烦 所以不实现 否则他们就去使用 iptable 或者ipfw了 可能是他们觉得在网络层对运输曾处理 不太合适吧 既然你 认为我也 比较糊涂 那我也不再和你争什么了:) 或许我真得不清楚吧

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/