作者 | 2009-12-29 19:27 | 类型 , , |
|
受首席之托xx一下PAN的产品。该公司产品我没用过，说明书也没有时间看（应该又是数百上千页的英文文档）。但是我不是很相信在应用安全功能上PAN能够开山立派，因为今天的应用安全功能在n年前就有人提出来并描述过，其中也包括PAN借以成名的应用识别。只不过没有市场驱动，没有竞争压力，Cisco和Juniper懒得去做，现在火烧屁股，不得不做了。 PAN的创新我觉得有两点： 1.功能集合的创新 将应用识别首先和FW攒起来，并且达到商用标准，切合应用标准，用户体验更爽。随着DPI以及应用识别功能逐渐成为各家产品的标配，我觉得PAN安全功能上的优势逐渐缩小（我是说功能而非性能）。 2.系统架构的创新（这点是我昨天刚刚悟出来的） 大家都是攒机器，PAN可能攒的更好。 我个人理解应用安全系统的核心组件式“引擎+signature+policy”（当然所有组件包括硬件平台，管理系统，TCP子系统都是核心，但是我的意思是从应用安全功能角度考虑，没有瞧不起其他同仁的意思：-））。其中引擎决定了signature，两者是一体的，因此可以简化为“引擎+policy”。前面我提到过，应用安全主要功能就是visibility+control，这里engine对应visibility，policy决定control。这样说大家是否更明白一些了。 本人在站内偶然搜的首席的一片PAN相关文章“”，且有幸看到了弓总的一篇回帖，如醍醐灌顶，豁然开朗。弓总曰到：“我当时做架构的两个重要理念就是一体化引擎和一体化的策略框架（policy framework). 这在我看来，是保证高性能和易用性的关键。我很高兴，PAN公司一直坚持这点作为和UTM的重要区分线，Gartner 也认可。” 弓总点到为止，这时候就得靠“悟”了。 首先估计一下现有的应用安全系统实现： 应该大体都是接力棒形式的，你干你的，完事把包给我，我再接着干。系统这样实现是有原因的，也是有好处的： 1.兼容遗留系统。系统往往不是一蹴而就的，新feature的加入要以不break已有功能为前提，否则必出血案。除非你能保证： a.被break模块owner的生命安全（Job Security）。 b.引入的新bug你来负责。 2.分割软件复杂度。 这是最重要的优点，一线工程师做起来更容易。 所谓“一体化引擎”，我的猜测如下： 打碎坛坛罐罐，管他{zc}丸散还是秘制膏丹，全部打碎。从全局的角度统一设计engine。这样的一个明显的优点是去除冗余，更加高效，理想的实现是每个报文仅仅parse一遍。{zh0}连signature都统一起来。我本想花张图，但是感觉又不好画，大家也“悟”把。 所谓“一体化策略”，估计也类似。将各个不同模块的policy通盘考虑，分清层次，减少冗余（别存那么多五元组），提高性能（别搞那么多没有的匹配）。 如果是这样，确实比简单的Integration看的更深远。 这样的系统实现，对于架构师要求极高，我粗略的想了一下，头脑有些发晕。感觉有点像功力未到，强练葵花宝典一样。架构这样的系统，架构师本人首先要通晓现今安全需求，还要预知未来，谁也说不定今后是否有新的应用安全功能需要集成到系统中，且同所设计的系统架构冲突。 总之上述都是“我猜，我猜，我猜猜猜”，或许实际情况远不是这么回事。 但如果和我想的一样则： PAN的NGFW同UTM的区别不在于应用安全功能本身，而在于系统架构，也就是白炽灯和节能灯的区别，虽然都能发光，但是前者终将被淘汰。 真的希望弓总茶余饭后能看到这篇东西给个Yes，No。 | |
  (4个打分， 平均：4.5 / 5) |
“有关“一体化引擎和一体化的策略””有47个回复
发表评论
×相信弓老师会很快看到，期待弓老师的点评…
×
1.兼容遗留系统。系统往往不是一蹴而就的，新feature的加入要以不break已有功能为前提，否则必出血案。除非你能保证：
a.被break模块owner的生命安全（Job Security）。
b.引入的新bug你来负责。
One JunOS, One World…One Wow…
2.分割软件复杂度。
复杂度…
×上帝让我们用自由意志决定我们的未来
你相信上帝么？
我相信
你相信上帝{wn}么？
我相信
如果上帝是{wn}的，那么它一定知道未来，也知道我们的选择是什么？
是的
那么我们的自由意志还存在么？
……
据我所知，PAN自己做了一个FPGA。但是，Cavium Octane已经有了不少的DFA Lookup Engine。所以我目前不知道这个FPGA是做什么用的。我不认为是做VPN和FW Session的。I mean， after first packet。为啥？NS的ASIC Enginer并没有在PAN。
我哪天琢磨一下PAN吧。。。
听说PAN与Hillstone里以前NetScreen的高手都很多。没接触过。不知道哪拨人更牛叉一些。。。：-）
嵌入式的软件还是比较简单。比如Jave, .net之类的企业应用软件，可以做到即插即用。面向对象的设计模式很多了，也没见哪个人在c里面用用。OSGi的plugin model，如何用到嵌入式软件里面，或者在这个领域，有没有人在做这些东西？
一体化是没错，但是什么东西都自己搞是不现实的，那么，自己做一个plugin framework，让别人的东西很容易加进来，又不损失功能和性能。不知道嵌入式领域有没有这样的实力和决心？
工程师比较实在，不会瞎忽悠，懂就是懂，不懂就是不懂，不懂装懂的人，其实没啥意思。
路由器软件的复杂性主要是IP的变化太多太快导致，而IP的这个变化又是因为ALL OVER IP导致，所以根本原因是业务变化太快太多导致路由器系统复杂，这方面，AL/J做得比C/H可能要好一些
从硬件来说，对NP/ASIC/FPGA/MULTI-CORE/TM/TCAM/VALUE-ADDED CARD等多种核心芯片的同步支持，带来系统架构设计的复杂度,从这个角度看,xx路由器的门槛其实是越来越高了,这和中低端安全产品的趋势有点相反,多核的成熟使此类安全产品的基础系统获得大大简化,设备商可以把精力主要放在软件上.xx路由器的的这个趋势也符合主流供应商的利益,太简单了就不值钱了,不值钱了怎么能有好的利润率,之前BT提出的PBT标准{zh1}不得不选择xx,这也是其中的一个原因
PBT：Provider BackBone Traffic engineer就是用基于MAC IN MAC的纯以太转发，不做任何L2/3路由协议，集中式计算路由并下发到各个转发节点。基本技术上是可行的，但是在处理all services over IP/ETH时，包括组播等等并不成熟和完善，当然如果大家都支持，加以时日，也许可以成功。政治上，如果PBT成功拓展，则意味路由器将成为一种简单的傻瓜式转发设备，失去门槛的路由器很多人都可以做，那么思科将失去设备复杂带来的利润空间，所以思科是不可能支持PTB的，只有北电这个没落贵族才会支持，作为可以翻身的一个可能点。所以抛开技术问题，PBT本事是对社会有利的，但是在涉及利益问题上，大家都会站在自己的立场做动作，如果PBT成功的可能越来越大，当然大家也都会与时俱进，给予更多的xx和支持，商场对技术的态度是很势利和现实。当然PBT没能重演当年IP和ATM PK的结果，技术上应该也有很大的问题，这个东西复生的可能性很小，所以没有去仔细研究其中的细节
PBT的东西其实不是太懂，但是挺过一个老大评论过这个东西，他认为这就是一帮子搞传输的人死抱着传输体系不放搞出来的东西，除了还是IP的报头，整个转发都是传输的思路。
顺便说说安全，通用的安全产品其实没什么技术，无非是两条：状态转发＋特征匹配，这两个技术的组合应用几乎可以把网络上部署的所有安全产品（除抗DOS/DDOS的以外的）做出来。从这个角度说，安全产品比网络产品做起来简单多了。
至于说多功能融合，根本上的问题还是性能。至于体系架构，L4～7层的架构是比较好设计的，复杂的是对交换和路由的处理，加上这两层就很麻烦了。
其实都挺简单的. 做到balance很难. forwarding做高速, 找几个ASIC就行了. Routing要做好, 控制平面CPU快点多几个核就行了, 然后转发平面上也同样加快provision的速度. 安全, 加密解密Nitrox 作为协处理器放几块…
但{zh1}呢, 要么做出一个功耗大的吓死人的东西, 要么做出一个价格高的吓死人的东西. 所以做好都不简单.
另外关于PTN的问题, MPLS-TP实际上已经成为标准, 中移动已经开始部署在RAN上了, MAN上的部署估计也会很快. 主要是1588和Sync-E的功劳. 当然OAM也功不可没. 数通相对于原来的传输网而言, 总体来说是更难维护. 2000个MPLS VPN 估计得花10多个人来维护, 而2万条TDM专线, 估计2~3个人就能搞的定.
ASR1000研发过程中， 从RP1用Freescale 8548转到RP2 用Intel CPU, 技术， 功能和性能的考虑只是一部分，Freescale 当时在频率性能和多核roadmap的不明朗，是决策过程中的一个重要因素。 思科供应链对Freescale从来不是那么感冒，设计团队内部的政治斗争也是选用Intel的一个因素。
8548的IO集成度非常高， 功耗低， 而且内部数据总线是SPI4, 与思科内部交换背板芯片的连接非常顺畅。
Intel CPU用三片芯片， 加上PCI-E到SPI4 Bridge 芯片, 对IO系统， 供电， 热散的冲击蛮大。 软件上从big endian 到little endian的转换， 也造了不多不少的麻烦， 更别提schedule一再的延后。
不过总的来说我认为选用Intel还是正确的。从思科内部看来， xx控制平面用Freescale越来越少， 用intel越来越多。
多谢老韩提醒。你们有这麽多的有意思的话题（谢谢陈首席：），有那麽多好的见解。新环境下很多杂事却忙得我晕头转向，真是惭愧。
苹果叶子地分析很准确。UTM 的引入是冲着低设备购买费，易部署 （单箱和多箱之差），以及易用性，来的。这是对的，但是他实现的方法仅停留在公用硬件平台+统一用户界面的层次上。这就是原定义的UTM后患所在。
我谨对利弊分析方面做几点补充。
1。引擎一体化的目的是高性能，低时延为主，同时提供一体化策略的有效基础。 对架构设计的要求确实比较高，要有网流处理，协议分析，威胁检测，各种恶意软佳绩动向的积累。同时要有对用户管控需求有清楚地了解和判断。话又说回来，你无法预言所有的需求，但是出一个好的产品也不需要这莫做。 另外，不要忘了，引擎不光是支持signature的，或者用句玩笑话，外婆的引擎和外孙的引擎可不一样。寿命就不一样喽。
2。统一的策略更重要的是为了提供更好的可用性。举几个例子就清楚了。有些设备HTTP的检测，URL过虑是通过代理模块做的，而其他协议的入侵检测是用另外的引擎。 用户必须明白这些模块间的依耐关系，分别做出正确的购置才能达到需要的功能。 另外，在NAT和IPS共存的盒子上，不同的UTM风格的耦合，IPS模块看到的包的IP地址可能是NAT之前或者之后，用户要面对这层复杂性才可能正确设置自定义的使用IPxx的规则。 这些事同一策略框架的用途。当然，在没有一体化引擎得了件下，是可以再UTM上提供统一策略框架的，所不能达到的是效率。
3。关于模块切割，实现复杂性等，如果你是从零开始，这不是个问题。你的架构{zh1}还是落实到不同的模块，所不同的是每个模块做什麽，它们的接口是啥样的。
Billy,你的自由意志不能因为上帝可以预测而不再是自由意志啊。如果你相信上帝，就不能那样和他比啦。你一定看过Matrix.不然的话，更让你费脑筋的可能是 “上帝让我们觉得我们在用自由意志决定我们的未来” ：-）
多谢弓总百忙之中的回复。
“引擎不光是支持signature的，或者用句玩笑话，外婆的引擎和外孙的引擎可不一样。寿命就不一样喽。”
我的理解是引擎的主要功能是模式匹配，为了达到该功能的前置功能就是Normalization，这包括协议解析，各种编码方式的标准化，文件解码，解压缩，嵌套文件提取等等。这些概念应该适用于AV,Anti-Spam,应用识别, DLP, IDS,以及URL filter等web安全功能。其他还有不少辅助的和模式匹配并列的检测手段，例如按照协议或标准的异常检测，但大多重要程度还无法和模式匹配相提并论。
“在NAT和IPS共存的盒子上,不同的UTM风格的耦合，IPS模块看到的包的IP地址可能是NAT之前或者之后，用户要面对这层复杂性才可能正确设置自定义的使用IPxx的规则。”.这一点我从未想到，我觉得应用安全同NAT基本无关系，UTM设备在设计机构上就应该保证IP对于应用安全是透明的，也就是说应用安全模块仅仅需要看到一侧的IP。我还真的无法想象出在什么情况下要看到两侧的IP。
“关于模块切割，实现复杂性等，如果你是从零开始，这不是个问题。”我的理解是对于PAN这样从零开始建构系统不是问题。对于One Junos这样的也不是问题，因为已经“病入膏肓了”根本无法实现NGFW了:-)
真是希望看看PAN的设计实现，估计功力可以提高好几年。
没有工程经验的不会随便乱说的。
老韩的测试我见过，他的虚心求索精神，和探索真谛的理念确实值得赞赏。摸过的盒子，老韩应当在众人之上了，虚心的精神，更是少见。
融合处理，真正提出来的是方院士吧，协议分析和signature的统一处理，实现起来，就要靠session的融合了。
ASIC这种东西，名字吓人，但电路集成度就那样了，除了L2~L4的处理，走个L7试试？
测评是最容易发现问题的，国内很多厂家的问题都显而易见，只是没说罢了。测评的难度，深不可测，只有高手来为之，只有高手敢为之。
主张实践，讨论拿出数字，谢谢
只讨论技术行么？
老韩的测试我经历过的，实打实的数据。
他的郁闷也源于实打实。。。
媒体和众人没啥区别，真正的理论，谁能知多少？
弄个计算几何出来解决session creation? 是人都行么？
关于弓的回复，国内的，e.g.启明，都做到了罢：
1）一体化处理：这个方院士反复强调过，IPS和AV的处理要在一起进行。不难实现，但取决于规则。自己制定的规则我可以一体化，换个第三方的，ok，测评吧！
2)统一策略：相关问题是管理问题，这个没人能解决。你说防火墙管理员权限大还是IDS的人权限大？这个有明确答案么？策略融合的前提是明晰了从属关系，UTM是个整体没错，但整体就有等级制度，需要明确的。
3）modular的问题，取决于系统工程师，软件架构师。芯片的任何改进，都有可能改变module的部署。比如PAN，真的需要ezchip和fpga么？multicore不能解决么？增强版的PIP/PKO不能解决么？Octeon2不能解决么？
时势造英雄，英雄亦须趋于时势。。。
欢迎来搞。
在工程技术里面，媒体{zh0}的就是陈叔了:-). 另外，谁是方院长?共青团员从不怕不知道，就怕不虚心。我应该比较八卦了，但还真不知道谁是方院士。
>昨天刚给客户部的人发过陈老师归纳的思科各业务部门介绍的文章，大家都受益匪浅啊。
那可是我自己靠一个Google，靠一个脑袋。利用黎曼积分，求极限，整出来的。花了不少时间。基本上是倒退，反证。
很高兴对你们（社会）有帮助。这就是我{zd0}的selfish。我可不是脑残：–）。我所有的文章都是GNU License。你们自己考虑好了。。。：-）
提前抱歉,有些细节和对具体产品的评价,我将不便参与.
Appleleaf 和我对引擎的解释都是超出模式匹配的，这点我们有共识， 不过仅仅协议异常检测确实是不够的。应该想急于内容的启发式的检测，行为模拟， 等等。没有这些方法的辅助，许多当今的威胁都难以检测。 有效地融合多个方法是好的引擎的一个重要标志。
说安全或者应用安全和NAT没有关系真有些不妥，尤其是在UTM构架讨论的前提下。我们不能排除有些IDS/IPS产品可能非常单一，但是，好地IPS都支持用户定义规则，去实现基于内容匹配的ACL功能。例如，block 从a.b.c.d 的 WEBDAV HTTP 访问。如果用户不清楚NAT购置与a.b.c.d的关系，ACL的效果无法预测。还有，当一个公司关心对外的攻击/泄漏时，日志里拿到的是哪个IP地址就有关了。
我的提法是有些不妥，任何{jd1}的提法都是不妥的，以后接受教训：-）
“例如，block 从a.b.c.d 的 WEBDAV HTTP 访问。如果用户不清楚NAT购置与a.b.c.d的关系，ACL的效果无法预测。”我的理解是，这个例子是Applicaition FW的概念。要做的事情是APP ACL。对于APP FW，我总是习惯分层的考虑policy，对于Network层部分的policy以及相关的NAT，我没有把他当做UTM的policy：-）。不过，如果真的需要过滤应用层payload的IP，那NAT就要考虑了。这种例子较少，ALG中需要单独care这个问题。
“还有，当一个公司关心对外的攻击/泄漏时，日志里拿到的是哪个IP地址就有关了”
日志中确实要考虑NAT的问题，NAT前后的地址信息都要记录，尽量全面的反应现场信息。