“开源安全项目- L7 Filter”有60个回复

1. oh 于 2010-02-08 7:49 上午

   偶恨l7-filter

2. 陈怀临 于 2010-02-08 9:34 上午

   阴谋论一哈：PAN的系统与这个有没有什么说不清的关系：-）？例如，提高版，强化版？，商业版：-）咔咔。

3. 陈怀临 于 2010-02-08 9:36 上午

   叶子，你能否去接下来。然后咱们再与Panabit谈谈，通过弯曲评论这个平台，咱们把这个香火传承下去？例如，弯曲评论上host几个open source 项目。。。

4. Panabit 于 2010-02-08 5:32 下午

   L7-filter有几个问题：
   1）正则表达式的描述能力有限，比如不好描述字节和长度之间的关系，正则表达式主要用于描述数据特征；
   2）正则表达式不能描述数据包之间的关系；
   3）正则表达式无法描述链接相关性；

   正式由于上述原因，我开发了PSDL，PSDL是一个基于状态图的协议特征描述语言，并且通过PSDL编译器，可以确保特征库的最坏性能在编译后就可以量化并确定下来，可以做到30种协议特征和300种协议特征具有同样的性能。

5. Panabit 于 2010-02-08 5:52 下午

   首席一直教导我，做工程一定要量化，所以我将这个理念引入到PSDL设计中，对于PSDL中的每个操作或语句，都有特定的V-CYCLES与之对应，我认为这是一个很重要的特性，并且，将这种V-CYCLE量化模式可以映射到真实的CPU CYCLE上。

6. appleleaf 于 2010-02-08 6:19 下午

   老Panabit，你这广告做的，“PSDL,V-CYCLES”，我都没听说过。能公开就公开一下，不过这也是你的核心功能了，不公开我也不会怪你的。

   正则表达式只能识别数据，只是你的PSDL模式描述中的一部分，你的设计归根结底也要有类似的识别描述。

   另外首席的想法挺好，可以号召国内的优秀开源项目在弯曲筑巢。只是我精力有限，而且有panabit这个黄埔一期虎狼于前，我也打不过他。

   另外，我觉得L7-Filter的一个问题就是选型于Linux，作者自己也不厌其烦，内核动不动就改改，接口一变就编译不过去，就连netfilter也一样也有参数变动，换一个linux版本程序就用不了了。估计这也是作者后来又搞了一个用户模式版本的原因之一。

7. 陈怀临 于 2010-02-08 6:20 下午

   这倒是，我一直提倡要有量化的工程作风。。。
   另外，Panabit，你一定要抽时间做一些专利方面的考虑工作。当一个新生事物要壮大的时候，要小心商场上的坏人。

8. Panabit 于 2010-02-08 6:49 下午

   谢谢首席提醒！我目前正在开发第三代PANAOS，其重点是如何在多个核之间自动做“阶段性功能模块”的负载均衡，目前我已经大致定义了所谓的“阶段性功能模块”所需要遵循的原则（包括接口和语义要求），还有些不是很清楚，到时望赐教！

9. Panabit 于 2010-02-08 6:52 下午

   回叶子兄弟：

   1）PSDL是Protocol Signature Description Language的首字母缩写；
   2）V-CYCLE是PSDL里衡量操作时间的单位，比如一个比较操作耗费1个V-CYCLE，这很类似于计算机指令；

10. appleleaf 于 2010-02-08 7:07 下午

    多谢Panabit兄，基本上你的回帖也给了我很多的启发，希望你的产品继续发展，能够大卖。

11. 陈怀临 于 2010-02-08 7:11 下午

    这个动态负载平衡很好。我一直想在某系统上的实现。唉，写了FS，但被认为太fancy，没有做。希望看见PANOS做出来。另外，在锁粒度上，一些基本的QoS上也有有所考虑。把架子搭起来，以后做大系统就很简单了。。。。。。另外，现在不一定考虑HA，但要留点心。。。

12. foxmail 于 2010-02-08 7:31 下午

    Panabit 将匹配逻辑和关键字都编译到目标文件里面了.
    说的神乎其神的…

    PSDL 是类似文法/词法描述的中间脚本.
    PBOS 感觉就是修改了网卡驱动, 接管了数据包处理逻辑, 转发的数据不走OS协议栈, 跑自己的逻辑而已.
    自己有个高优先级的进程不停地检测&处理数据包.

    至于 V-CYCLE, 哈哈, 估计其思路无非是将数据包的处理逻辑做精细的单元化分, 尽可能使得不同类型的数据包处理所需的时间复杂度一致. 避免造成颠簸现象.

13. 陈怀临 于 2010-02-08 7:35 下午

    得，有人要PK Panabit的baby了：-）。一生气，Panabit把系统设计就发表出来了：-）

14. appleleaf 于 2010-02-08 7:42 下午

    engine的code本来就不大，逻辑上也不会多么复杂，但是这个东西需要大匠之工，寻常的开发人员确实做不好。

15. appleleaf 于 2010-02-08 7:45 下午

    我看来一个好的应用系统就是“大匠之工+人月积累”，前者对应一个高水平的engine，后者对应于积累下来的signature库，概莫能外。

16. Panabit 于 2010-02-08 7:46 下午

    回foxmail，你说的很对，我从来没有将这些说得“神乎其神”，你要知道，首席在这里呢:)。我们做工程的，不可能弄全新的理论性的东西，所以无非就是将不同的知识组合，用在适合的场所，呵呵。诚心忘赐教！

17. vincentxu 于 2010-02-08 10:28 下午

    To Panabit:
    请问Pan系统也是基于正则表达式？我的意思是是否也是利用正则表达式的特征库？如果是，能不能解释一下正则表达式和PSDL的关系？或者PSDL本身就是一种特征描述语言（那么是不是已经将现有公开的模式集合转换成了PSDL？）？那么请问是表达能力如何，介于字符串，正则表达式，上下无关文法，上下有关文法的哪一个层次？另外，如果做到机器编译，具有确定处理时常的机器格式对正则表达式来说是DFA，请问PSDL对应的机器格式是什么，是不是也是类似于DFA的状态图？对不起，一下子这么多问题？确实很好奇，不过如果不方便公开就算了。

18. spike 于 2010-02-08 10:57 下午

    “我看来一个好的应用系统就是“大匠之工+人月积累”，前者对应一个高水平的engine，后者对应于积累下来的signature库，概莫能外。”

    我能不能这么理解并扩展到绝大部分软件系统？
    engine –》 framework
    signature –》 application

    所以“大匠之工+人月积累”就是“several architect + lots of man power”

19. appleleaf 于 2010-02-08 11:00 下午

    spike，我写的不全，应该是“应用安全系统”不是“应用系统”

20. Panabit 于 2010-02-08 11:14 下午

    To 17楼vincentxu兄弟：

    1）正则表达式会局部用到
    2）DFA也有（同正则表达式有关）

    我本人并不喜欢上述两个东西，我喜欢简洁的东西。上面两个可能属于通用的数据描述范畴，但是我们在做工程的时候，往往碰到的是数据的子集，所以这也意味着我们可以做针对这些子集的特殊优化。PSDL是在不断的总结协议特征的过程中得出的东西，它的工程性多余理论性。从思维角度看，我们经常碰到的两种形式是归纳和演绎，你可以看着这是归纳性思维的结果，呵呵；当然，我本人也希望它能逐步表现出演绎性的一面，这也是下一步最求的目标之一。我本人说白了，就是一CODER，不能同首席这样的高手比，所以我只能不断的归纳再归纳了（非谦虚，的确如此）。

21. spike 于 2010-02-08 11:26 下午

    呵呵，我对安全系统不了解，胡乱对应了一下。不过感觉稍微有规模的软件系统都可以这么划分。在竞争力上，架构的好坏和编码的质量会影响性能，但做产品更重要的是对application的理解和创新。我想对于安全系统，engine决定性能，而signature库的更新能力，扩充能力甚至预计的能力，则是个更重要的core competency吧

22. 小杨 于 2010-02-09 12:32 上午

    To Panabit:
    弯曲看的人太多了，慎言慎言。PanaOS我也了解了一些。Em的驱动也改过一些。加上12楼foxmail兄的发言，让人联想偏偏。

    To Foxmail:
    你的发言让我想到了另一家公司，呵呵。

    言多必失，继续潜水。

23. vincentxu 于 2010-02-09 1:21 上午

    赫赫，大家开心就好。
    只是曾经也认真研究过深度报检测的东西。看到这个文和大家的顶贴勾起了战斗欲，不小心擦枪走火啦。
    正则表达式这个东西还是功能强大的，可以很大程度的提高模式库的表达能力。这样一些应用想简单的隐藏身份就不可能了。同叶子说的，这个模式库需要长期积累，且精心优化。简单的拉几个组件堆在一起自然效果不好。正则表达式语义强大，针对灵活的东西提出通用有效的处理方法那是太难啦。

24. vincentxu 于 2010-02-09 1:32 上午

    To Panabit：
    过分谦虚了也不好，知易行难，练练嘴皮子都很容易，但是想真正做成一件事，那就不容易了。

    Coder们，勇敢站起来……..

    这个顶贴会不会太水？试试首席的底线，哈哈。

25. 陈怀临 于 2010-02-09 7:07 上午

    很好的讨论。对panabit系统也是一种鼓励。

26. Multithreaded 于 2010-03-09 8:00 上午

    L7-filter已经可以被并行化了， 用4个核可以达到5-6Gbps的线速。

    具体作法是把L7-filter的规则变成FLEX, 然后并行FLEX生成的C代码。基本上是用了source-2-source的编译变换技术。这样一遍扫描就知道那条规则匹配了。

    难点是当规则太大时（〉100），DFA的状太空间就爆炸了。

    Is panabit a DFA or NFA based system?

27. Daniel 于 2010-05-07 1:40 上午

    PSDL不是早就有了么, 怎么会是Panabit开发的?

28. Panabit 于 2010-05-07 1:50 上午

    我们的PSDL是Protocol Signature Description Language的缩写，这个缩写不是我们专用:)。另外，PSDL编译器里有DFA成分，但那只是一个补充。

29. Daniel 于 2010-05-07 1:53 上午

    不好意思首席, 挖了个老帖…Google指引我来这里的.

30. Panabit 于 2010-05-07 1:56 上午

    坦白的讲，协议识别无论采取什么技术，是DFA好，是REGX也罢，其实最终的目的就是识别，哪种方式有效，就采取哪种方式，不必拘泥于特定的实现。心中无刀，杀人才能无形。关键的有两点，一是数据包的来源是否足够广泛，二是能不能耐下性子分析数据包。

31. 陈怀临 于 2010-05-07 5:25 上午

    Panabit确实已经成为世界级高手了。这一番话基本上也是我对系统的理解了。

    解决问题是根本。其他都是手段和表象。

    Panabit确实是具有慧根之人。也难怪Panabit现在名声大震与江湖。。。

    十年磨一剑，霜刃不曾试；
    一日把示君，天下不平事。

32. 黄岩 于 2010-05-07 5:35 上午

    panabit的确做得不错，不要小富即安哈。

33. Panabit 于 2010-05-07 7:56 上午

    首席，你可要折杀我了！

34. Panabit 于 2010-05-07 7:58 上午

    黄岩兄，希望我能够将事情做得更好一些。以后的事情谁也不知道，只能将当前的事情尽量做好了。BTW，上次去成都，没有去找你，我食言了，忘海涵！（主要是要陪老婆:)）

35. Daniel 于 2010-05-19 7:27 上午

    弄错了, 我认识的那是PDL, 不是PSDL. Panabit还是申请个专利吧, 哈哈.

36. Panabit 于 2010-05-19 8:45 上午

    呵呵。

37. siegfried 于 2010-05-19 6:54 下午

    PSDL应该不是三型文法吧？
    因为这需要保留之前的上下文，并供给后面的谓词进行演算。
    这样就需要使用Stack，因此至少应该是二型以上。
    正则应该是其中的辅助模块。

38. kakawolf 于 2010-05-22 4:28 上午

    请教下26楼Multithreaded：

    一定要用flex转换后才并行的原因是什么？

    不能直接使用正则表达式么？

39. Multithreaded 于 2010-06-10 1:11 下午

    to38楼：

    flex转换后的C/C++程序容易并行化。 正则表达式只是个描述语言， 需要转化器把它转化成可执行的代码。 一般来说有两种方法，

    1。生成中间表达式，解释执行
    2。编译后执行

    想在多核上执行，必须把1）或 2）并行化。

40. kakawolf 于 2010-06-12 4:01 上午

    谢谢Multithreaded 的讲解。

    不过小弟还有另外一些疑问，可否赐邮件交流下？

    先留下我的：

    fdetertxw@126.com

    静候佳音:)

41. 陈怀临 于 2010-06-12 9:12 上午

    我对Implicit 并行编译确实不看好。。。特别是对于多核。业务之间的耦合性太大。都是case by case。编译器很难理解业务。。。。。。

42. multithreaded 于 2010-06-12 3:27 下午

    完全同意。 我讲的并行是做人工指导下的并性转换， 不是编译器的自动并行。

43. mjj 于 2010-11-29 3:26 上午

    我是绝对的菜鸟，有幸能够来到这里，三生有幸。Panabit 我用过，但对PANOS和PSDL不懂，只看识别率和控制效果，确实不错。

44. 镁铝 于 2011-07-07 8:19 上午

    好久不见苹果叶子了，偶想死你了。

45. zhutou 于 2011-07-07 8:51 上午

    如果PANOS还在考虑模块动态负载，那么说明PANOS有些重要的功能是实现在应用态的啊，我看过PANOS的说明书，似乎没有这种功能啊？

    难道PAN的data plane的架构是有调度存在的？这个可不是最优解啊？

46. 外行 于 2011-07-12 5:10 上午

    说来残愧,我做的agine,只是个半成品,
    有个判别树,开消挺大.
    等我学习完编译原理,应该能做个更好的.

47. 外行 于 2011-07-12 5:21 上午

    最近看计算理论的书,书上讲到 DFA与正则表达式是等价的.我不明百,为啥会有DFA和正则表达式两种方法….
    我只接把特征写到一个xml文件,然后内存中生成一颗树,来进行判别了.效率确实不高,但是跟据协义的分布情况,
    对树进行特殊处理,问题也减少了很多.

    Protocol Signature Description Language
    這个我去研究下,改进下我的引擎.

    ”
    flex转换后的C/C++程序容易并行化。 正则表达式只是个描述语言， 需要转化器把它转化成可执行的代码。 一般来说有两种方法，”

    直接每个核处理一条连接得了.

48. 小青年 于 2012-05-07 6:51 下午

    偶也恨l7-filter,当初公司主管不买上网行为管理，防火墙，为了省钱，在centos5.4搭建的公司网关上让我编译l7－filter，从新下载了兼容的linux kernel让我编译，太苦逼了

49. anonymous 于 2012-05-09 12:58 上午

    #48 小青年: 有什么可恨l7的，你想如果你能编译出l7能工作替代公司去采购专门的设备，你就是帮公司省钱了，从而创造出了价值；
    如果你啥活儿都不想干，那公司是干啥给你发薪水哪

50. 瀚云 于 2012-05-09 11:06 下午

    直接上PANABIT就可以了，我们公司就这么干的~~

51. 小青年 于 2012-05-10 6:32 下午

    关键是那个网关就是一台装了centos5.4的pc，还不是服务器，根本达不到性能的要求，对网络过滤一层后，速度超慢，其他部门就投诉，结果还是换回了没有装l7的原来的内核，让我干的是我们运维的主管，结果他还凶我一顿

52. aaa 于 2012-05-26 4:26 上午

    使用专门语言开发识别引擎已经是一个很正常的想法，关键是能力有多强，识别能有多精确，能做parser么

53. 二大妈 于 2012-05-27 12:15 上午

    ３０个和３００个性能一样不就是ＤＦＡ算法保证的吗？
    都是O(N)的复杂度，只是取决与输入。不明白PSDL比DFA高在什么地方？是否PSDL需要对每种协议做decode? 如果是这样，又和binpac比较如何？希望panabit赐教？

54. aaa 于 2012-05-31 7:23 上午

    如果只是应用识别 没有必要所有协议做decode psdl应该就是一种专用描述语言而已

55. xiaoyu 于 2012-05-31 7:51 下午

    我们把L7-filter硬件化了，不知道有没有应用前景？

56. jie 于 2012-06-12 1:06 上午

    硬件有啥做的？
    并行？FPGA？都已经有人做了吧

57. 们 于 2012-07-07 10:43 下午

    To Panabit: 并发256个IP数怎么看当前环境中已经超过这个数了，如果超过并发256IP，用户是否会感觉到网速变慢。 有知道的兄弟麻烦告诉下。

58. Panabit 于 2012-07-08 6:04 下午

    回楼上：256IP限制只对单IP限速和单IP统计有用。如果不需要单IP限速或单IP统计，则可以忽略这个限制。真正影响分析的是连接数控制。

59. aaa 于 2012-09-12 6:46 上午

    不知道panabit有没提供sdk之类的啊，方便整合的

60. aaa 于 2012-09-12 7:03 上午

    我敢确信：至少有个4-5个人在用aaa，有程序员，有产品经理，有研发经理，有混混。。。