本文档的Copyleft归yfydz所有,使用GPL发布,可以自由拷贝,转载,转载时请保持文档的完整性,严禁用于任何商业用途。
msn:
[email protected]
来源:http://yfydz.cublog.cn
1. 前言
netifilter最大的优点就在于其扩展性好,可以任意定义新的模块扩展其功能,而且结构比较容易理解,即使是新手也能很快掌握其规则配置方法。
2. 防火墙规则模式
Linux防火墙常见的iptables规则模式:
模式1,状态检测在策略之前:
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
策略规则集...
模式2,状态检测在策略之后:
-A FORWARD -m state --state INVALID -j DROP
策略规则集...
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
模式1的特点是速度快,因为对于符合状态表的数据就可以直接放行而不用再去检查规则集,因此相对模式2就效率高;但是模式1下,对于流量控制、内容过滤、时间控制等功能就会有问题。
3. netfilter不足之处
netfilter的最大不足在于其效率不是很高,规则处理只针对包而不是连接等,表现在以下方面(就算鸡蛋里挑骨头吧,^_^):
1)状态表使用链表结构,虽然是HASH方式,但链接数非常大时,每个HASH表内的参数还是很多的,顺序查找起来就比较慢,能改为二叉树结构最好;(类似的还有路由cache表的实现,Linux内核也是用HASH表实现,而专业路由器大都使用类似二叉树结构实现快速查找)
2)某些目标功能太单一,导致某些情况下效率不高,如要对某类数据进行流量限制,对超过限值的包记录这样的需求,就需要三条规则,一条是家流量限制匹配-j ACCEPT,第二条-j LOG --log-prefix ...,第三条才是-j DROP,同样的规则匹配要匹配三次;当然不过不要求记录的话会简单一些,用一个子链来实现流量限制,就不用重复匹配条件了;但netfilter把日志作为一个目标而不是象2.2的ipchains那样记录日志是个规则选项,效率总是不高;
3)netfilter只有hot_drop(立即丢弃)却没有hot_accept(立即通过),一个hook点上如果挂接了多个操作结构,凡是接受的包就必须经过所有操作点的检查,而没有“短路”的方法,因此某些情况下效率不是很高;
4)NAT和过滤分在不同的链中处理,固然简化了处理,但效率也相对低了下来,转发包同时需要匹配计算PREROUTING、FORWARD、POSTROUTING的规则,而一般经过了目的NAT的包一般不需要进行源NAT,反之亦然;
5)某些功能不太好实现,如SYN代理,SYN代理在freebsd,openbsd等内核都自带,但在linux中却迟迟未能包括,确实在netfilter这个架构下这个功能不太好弄;
6) 对需要进行统计的攻击识别比较困难,如各种flood攻击,无法定义flood模式,只能简单的进行流量限制,限制了非法包的同时也限制了合法包;
7) 很难对一个网段内单个IP的连接数进行限制,这样一台机器染毒疯狂发包时不能把肇事IP挑出来,只能整个网段都限制,一损具损;
8) 流量限制不能自动处理反方向的数据限制(下载速率限制),必须要在状态检查允许规则(即 -m state --state ESTABLISHED,RELATED -j ACCEPT)前明确增加流量限制规则处理;规则效率不高;不能限制某IP的单条连接的传输速率,只能是所有连接同时限制;流量限制也只能使用模式2来实现;没提供流量保障功能,只能配合iproute2使用;不能自动对网段中的单个IP进行流量限制或监测,必须在策略中指定源或目的地址是单个IP,但这样在内网数量较多时处理不现实,通常希望是只在策略中指定是一个网段,告诉防火墙要针对网段内各个IP限制其流量或检测数据异常,而对异常IP单独处理而不影响其他地址的数据;
9)很多目标功能的实现只能使用模式2来实现,如为进行QoS控制而设置TOS的规则必须在状态检查允许规则前,否则只能是对连接开始第一个包设置,后续包就被状态匹配规则匹配而短路了,同样对反方向的包也必须明确处理;也就是说这些参数只是针对包而不能在整个连接中自动处理;
同样如果想对内容进行过滤,如string匹配,也是同样情况;
10)不能区分子连接进行不同处理,如对于相同地址的FTP和H.323服务的子连接,就无法对不同的子连接进行处理,如流量限制,TOS修改等,因为在用户空间无法知道子连接是属于哪种主连接,因此也不能分开处理,只能全部一起处理;
11) 时间控制只能使用模式2来实现,否则时间到期后已经建立的连接不能自动断开;
4. 总结:
netfilter虽然功能已经足够强大,但还是有不少局限性,但作为open source的产品已经算很可以的了。一个防火墙产品,如果完全依靠内核自带的netfilter实现而未进行任何修改的话,上述这些问题是不能很好解决的。如何使用模式1又能解决流量限制、内容过滤、子连接控制等功能是需要对netfilter进行修改的。国内防火墙大部分都是用netfilter来作的,从大面看都差不多,但可以用以下问题作为考察一个防火墙功能水平细节的测试题:
1) 防火墙的状态检测是模式1还是模式2?
2) 如果是模式2,流量限制、内容过滤等如何解决?
3) 是否支持QoS?整个连接的包是否都能修改TOS值?是否能修改子连接的TOS?是否支持流量保障?
4) 是否支持对不同的子连接进行不同的流量限制?
5) 是否能限制单个IP的最大连接数而不是连接率?
6) 是否支持策略中定义的地址是网段,但内部能对网段内的各个IP地址分别检测是否有flood现象,有flood发生是只限制该地址通信数据而不影响其他地址的通信?
7) 是否支持SYN代理或其他SYN防御措施?