多条iptables规则，netfilter的连接跟踪（ip_conntack）加速应用程序的识别

lujian19861986

在应用中，用户可能需要设置阻挡或者qos多个应用程序，比如在线视频，bitcomment，esayEmule等，这样就出现iptables有大量进入L7识别规则。
现在用ipp2p模块，若阻挡规则加在filter表的FORWARD链中，则增加的规则如下：
iptables -t filter -I FORWARD -m ipp2p --ipp2p_onlinevedio -j DROP
iptables -t filter -I FORWARD -m ipp2p --ipp2p_emule -j DROP
iptables -t filter -I FORWARD -m ipp2p --ipp2p_bt-j DROP
iptables -t filter -I FORWARD -m ipp2p --ipp2p_XXX-j DROP
...

在模块的match函数中，用printk打印LOG信息到/var/log/message
发现每个封包会遍历规则进入模块match函数，所以进入match函数的次数就过于频繁，影响识别效率！！！
现在可以做到的动作和所需解决的问题如下：
1.只下一条识别规则，在识别模块中将所要的识别app进行识别（循环调用search_XX()），在skb结构体增加一个栏位（类似nfmark），识别就设置其值，match函数默认return 1，保证可以进入规则的-j TARGET(可以新增动作)。如何在return 1前，在连接跟踪中将设置的值存下来（求助各位大神）？？？
2.如何利用netfilter的连接跟踪（ip_conntack）加速应用程序的识别

资料：http://bbs.chinaunix.net/thread-2092412-1-1.html#

lujian19861986

在应用中，用户可能需要设置阻挡或者qos多个应用程序，比如在线视频，bitcomment，esayEmule等，这样就出现 ...
lujian19861986 发表于 2011-07-20 17:45

    求助各位Linux大侠~

lujian19861986

在应用中，用户可能需要设置阻挡或者qos多个应用程序，比如在线视频，bitcomment，esayEmule等，这样就出现 ...
lujian19861986 发表于 2011-07-20 17:45

    参考了资料：http://bbs.chinaunix.net/viewthr ... &extra=page%3D1
分析内核中CONNMARK的实现，同时还包括MARK的match和target模块的实现。CONNMARK模块通常是和MARK模块搭配使用的。多谢~
总结出：应用程序加速识别可以通过POSTROUTING将APPID加入链接跟踪，用-m mark只匹配APPID加速识别并且直接做DROP等动作。
1. iptables -A POSTROUTING -t mangle -j CONNMARK --restore-mark  用链接跟踪里面的APPID设置skb中的nfmark栏位
2.iptables -A POSTROUTING -t mangle -m mark APPID -j DROP  用skb中的mark中快速判断app(qos的话，action可以改为设置skb的另一个栏位，用tc模块去做应用程序流量控制)
3.iptables -A POSTROUTING -m ipp2p --ipp2p_emule -j MARK --set-mark APPID  只有第一个包需要设置APPID，每个app设置唯一的一个mark值，如果需要变为一条规则识别全部app，需要在-m ipp2p中就设置mark值（循环search()且设置skb新栏位值），不能再-j TARGET中设置。
4.iptables -A POSTROUTING 。。。其他app规则 按照匹配选项对符合规则的数据包打上不同的标记
5.iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark  将数据包上的标记记录到链接跟踪上
这样，当属于该链接的下一个数据包走到第1条规则的时候，就会被打上标记，然后就会命中第2条规则

以上是对加速识别app考虑到的步骤，抛砖引玉，若有不妥之处或者更好的做法，请各位大侠提出

lujian19861986

测试L7识别效能结果，CPU的使用率与增加的iptables条数无关，跟模块识别应用层的速度，跟识别算法（hash value与特征一致）和流量有关。

Godbach

回复 1# lujian19861986

如果 iptables 规则匹配消耗的性能，和应用识别消耗的性能相比，一般情况下，规则的数目对系统的影响肯定没有识别的大。

lujian19861986

回复 7# Godbach


    感谢Godbach 兄~

Godbach

回复 6# lujian19861986

应用识别的加速，是一个大的方面，涉及到的技术较多，并非三言两语可以说清楚。

而且，单单使用 l7filter 也是不够的

lujian19861986

回复 7# Godbach


   我们 一开始是一个for循环跑所有的识别函数，直到match特征；现在为了加速，对特征进行分类（在模块的init函数中初始化），将特征转为hash table，查找包对应的识别函数速度可以达到常数（原来为n）；并对同一session的进行快速识别（不进match识别特征模块），对于流量大的app做QOS就不用识别每个包了，大多数是session的前几个包。对于要用DFI识别的app，也适用。还有什么可以改进的地方，或者其他方式可以让识别速度更快？
想问一下，怎么识别emule、迅雷、bt（多协议）？？有些资源下载可以用已知协议特征挡，但有用http get方式从服务端下，或者tcp PSH包（没特征，不知道是不是加密的），有没有基于流等其他实现识别的做法？

godbach

回复 8# lujian19861986
对，就是需要将特征分类，实现不是每个包都要逐个特征的匹配，直到命中为止。

至于迅雷的识别，确实很麻烦，它还可以利用普通 http 下载，也可以用 emule、bt。

简单的识别方式，需要通过抓包发现相关的特征。

kwest

直接限制每IP session数，什么BT都搞定。