挑netfilter的11个不足之处

本文档的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防御措施？