新兴web安全公司-铱迅信息

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




           铱迅信息是一家专业做web安全的新兴公司,总经理是来自华为,研发总监来自摩托罗拉,此人在美国做了多年协议,对底层驱动研究异常透彻,web攻击检测引擎研发由10多名拥有10多年web安全研究的国内顶尖人员构成。人员配置都非常年轻,是一个很有青春活力的团队。

        既然是web安全公司,当然就是做web安全,铱迅主要产品就是“web应用防护系统”,先普及下web应用防火墙跟传统防火墙的区别,看下图:

传统的防火墙、IPS不能真正解决应用层的攻击问题,因为它工作的OSI 1-4层,基于IP报文的进行状态检测、地址转换、网络层访问控制等功能,但是对于报文中的具体内容不具备检测能力,因此,对于web应用而言,传统的网络防火墙仅提供IP及端口的防护,对于web应用攻击缺乏防御能力。web应用防护系统主要致力于提供应用层保护,通过对http/https及应用层数据的深入检测分析,识别及阻断各类传统防火墙无法识别的web应用攻击。铱迅具有完全自主研发的协议栈全状态检测引擎,还具有针对变形编码攻击的防护,可以有效的防止“IP碎片攻击”、“TCP碎片攻击”、“变形编码攻击”等,众多网络设备都存在被绕过的风险,但是铱迅的检测引擎真正体现了它的强大。

 弯曲的高手众多,应该知道国内非常多的厂商用美国开源的IDS Snort的机制做组包,它的组包机制是不会超过1.5k的数据,但是铱迅的waf可以做到全组包。这个也是其的一大优势。

另外铱迅的web漏洞挖掘能力具有一定的实力,像常见的Discuz、Phpwind用得非常广泛的论坛程序,铱迅挖出了几十个,还定期给国家漏洞库提交漏洞。

其千兆产品每秒HTTP请求叔率达到56000,性能也非常有优势。铱迅拥有攻击检测引擎和性能强大俩大优势,公司web安全技术能力可见不一般。

铱迅是华为系的公司,走研发路线,市场做得有点欠缺。在2011年web安全防护的市场越来越成熟,希望铱迅有自己的一席之地。祝愿铱迅越来越好,弯曲越来越好,首席身体健康,各位万事如意。

(18个打分, 平均:4.17 / 5)

雁过留声

“新兴web安全公司-铱迅信息”有215个回复

  1. tom 于 2011-01-25 7:16 下午

    请问和wedge相比,有多大优势??

  2. 段山独桥 于 2011-01-25 7:19 下午

    很看好web安全这一市场,希望有机会能加入到铱迅这样的公司,能否提供联系方式?多谢

    一个多年来受弯曲滋润成长的青年

  3. anony 于 2011-01-25 7:23 下午

    软文性质过重,群众们需要的是真相。

  4. 陈怀临 于 2011-01-25 7:25 下午

    评论之,“揭发“之:-)弯曲不怕裸奔。就怕评论:-)

  5. 十分八卦 于 2011-01-25 7:46 下午

    如文中所说,市场欠缺,宣传做的不专业啊

    1. “HTTP请求叔率达到56000” 起码不该有错别字吧。

    2. “传统的防火墙、IPS不能真正解决应用层的攻击问题,因为它工作的OSI 1-4层,基于IP报文的进行状态检测、地址转换、网络层访问控制等功能,但是对于报文中的具体内容不具备检测能力,因此,对于web应用而言,传统的网络防火墙仅提供IP及端口的防护,对于web应用攻击缺乏防御能力。”

    这样措辞批判防火墙是可以地,连带批判IPS神马的,这个说法就有点娱乐精神了。你可以批判IPS对https的无奈,可以批判IPS逻辑上对WEB防护的先天缺陷,可以批判IPS不会带防篡改,都行都行。

    3. 那个1.5k重组,以后别宣传了,这个事情不会做不好意思出来混啊。

    4. 56000如果是proxy-based的新建,值得祝贺,如果不是,那就是浮云浮云。

    ======华丽的分割线 下面都是好话了======

    听过你们产品,据说不错,web是个好市场,加油啊!

  6. aguai 于 2011-01-25 8:16 下午

    欢迎加入我们共同创造美好的明天。

    联系方式:
    QQ: 621065672
    Email:yangzhiwei@yxlink.com

  7. tom 于 2011-01-25 8:18 下午

    铱迅拥有攻击检测引擎和性能强大俩大优势。
    把干货多晒晒是正道理。

  8. aguai 于 2011-01-25 8:20 下午

    to tom
    稳捷的是web安全网关,跟web应用防火墙有所不同。web安全网关有AV,有防垃圾,有网址过滤,一个集大成者,目前安全市场越来越细分,咱的waf就做一件事,还是希望UTM等产品能突破性能的瓶颈。

  9. Will Chie 于 2011-01-25 8:23 下午

    先褒奖一下,个人觉得的确是有技术实力的公司,看下面这两点还是比较赞的:

    “另外铱迅的web漏洞挖掘能力具有一定的实力,像常见的Discuz、Phpwind用得非常广泛的论坛程序,铱迅挖出了几十个,还定期给国家漏洞库提交漏洞。
    其千兆产品每秒HTTP请求叔率达到56000,性能也非常有优势。铱迅拥有攻击检测引擎和性能强大俩大优势,公司web安全技术能力可见不一般”

    但其中第二条有个前提条件,就是测试方法。

  10. aguai 于 2011-01-25 8:24 下午

    to 首席大人
    非常感谢首席大大通过我的这篇文章,万分感谢,祝弯曲越办越好,首席大人阖家欢乐,当然大家也一样。新年快乐。
    附上Demo地址,欢迎大家批评指正,当然希望得到大家的建议,一个产品的不断完善,还需更多的改进。
    yxlink-waf的SSL登录地址:
    https://demo.yxlink.com
    用户名:demo
    密码:123456

  11. aguai 于 2011-01-25 8:31 下午

    to 十分八卦
    1,咱都是从技术转过来搞市场的,所以不专业这个是事实。
    2,这个只是想说明IPS跟WAF的区别,没想到弄巧成拙了。
    3,snor的组包最高只能达到1.5k,而yxlink能做到全组包。
    4,56000只是个保守值,实测峰值能达到:82000
    谢谢您的评论,谢谢您听过我们的产品,有机会可以实测一下。

  12. Will Chie 于 2011-01-25 8:36 下午

    刚看了下yxlink的官网,提到:

    “采用正则匹配技术,精确匹配”

    个人始终觉得正则表达式的逻辑描述能力太弱,会不会造成误报率较高(和snort一样)?

    将来的HTML5中的web socket,里面也会产生数据流,这样的话,正则表达式的描述又有所欠缺了,就是对当前包的识别依赖于之前的包的信息的时候。

    另外现有的WAF是否考虑了HTML5?

  13. aguai 于 2011-01-25 8:39 下午

    to Will Chie
    测试方法:
    发包机(WAS)->WAF->Web服务器(IIS,首页放一个网页)

    WAS设置为135线程

    测试时间10分钟

    结束后看report

  14. aguai 于 2011-01-25 8:45 下午

    to Will Chie
    我们的引擎是完全自己写的,不是snort,snort的当然误报高。
    我们一开始是做软件,有4000多个服务器用着我们的软件产品,那个是用来测试,优化我们的检测引擎的,所以基本不存在误报的可能性。
    关键是正则前面的解码和归一化,然后再用正则,还有就是正则写的水平了。
    HTML5的web socket,目前没有waf能防护的,我们可以针对其进行开发,非常感谢您的建议。

  15. Will Chie 于 2011-01-25 8:48 下午

    “采用内核驱动技术,而非传统的ISAPI Filter模式,CPU占用更低、支持所有的Web服务器,如:IIS、Apache、Websphere”

    个人觉得这个技术不好,不如做到用户态,灵活性更好,更好开发调试,很多资源不需要移植到内核就可以用,这方面个人建议向首席咨询一下。长远来看,做到内核的产品特性发展往往要比做到用户态的慢。我觉得就在国内来讲,yxlink的技术是很不错的,别因为架构影响了前程,早该早好。

    另外不知道现有的WAF是如何处理SSL的问题的,WAF和SSL VPN产品将来是否能够紧密的结合起来呢?

  16. Will Chie 于 2011-01-25 8:50 下午

    “我们一开始是做软件,有4000多个服务器用着我们的软件产品,那个是用来测试,优化我们的检测引擎的,所以基本不存在误报的可能性。
    关键是正则前面的解码和归一化,然后再用正则,还有就是正则写的水平了。”

    受教了。

  17. aguai 于 2011-01-25 9:11 下午

    to Will Chie
    我们那个内核驱动性能挺高的,IIS的数据是用驱动来收,相对的提升了性能,减少资源占用。跟首席大大请教,咱辈份不够。
    关于SSL,我们现在SSL直接由WAF中的代理服务器完成SSL的加密、解密。。。
    WAF跟SSL VPN这个结合起来,这个要调研分析分析。
    务实点比较好,先做软件测试,修复,优化,再做硬件,这样产品一般不会出现什么设计缺陷啥的问题了。另非常感谢。

  18. Will Chie 于 2011-01-25 9:18 下午

    呵呵,受教受教。

  19. 陈怀临 于 2011-01-25 9:35 下午

    不客气。弯曲评论和首席我对初创公司的支持是永无止境的。弯曲上许多年轻人,快要毕业的学生。希望你们能找到志同道合的同学们加盟。为高端人才找到工作,也是弯曲的社会贡献:-)另外,很感谢你们贡献你们在技术的想法。这才是大商为儒呀。。。。。。

  20. Will Chie 于 2011-01-25 9:42 下午

    刚看了下demo,默认把http协议的connect请求deny了,这样会和思科的anyconnect vpn产生冲突,建议放行,否则部署过程中出了问题比较难搞。

  21. tom 于 2011-01-25 9:53 下午

    to aguai,看demo才想起来,去年底我一个朋友就是oem你们的,当时感觉产品还不错,节后我我联系你,节后有机会测试一下,呵呵

  22. aguai 于 2011-01-25 9:56 下午

    to 首席大人
    再次感谢首席的支持,研究web安全的,或者做销售人才我们都特别需要。
    to Will Chie
    缺省是拒绝的,如果有冲突,入侵记录上会有记录,这样用户可以自己放行。出厂时必须最大程度上保证安全可靠,但是用户网络环境混杂不一,还需管理加强,毕竟三分技术,七分管理嘛。

  23. 老韩 于 2011-01-25 9:59 下午

    越来越多的事实表明,弯曲评论正在成为国内IT行业中初创企业和技术型公司的展示窗口,对推动本土创新有着越来越重要的意义。

  24. 房地产商 于 2011-01-25 11:17 下午

    想给公司买个安全监控网关,不知有没有?

  25. bigrong 于 2011-01-25 11:24 下午

    24楼评论最给力。
    年终奖什么情况?

  26. aguai 于 2011-01-25 11:48 下午

    to 房地产商
    暂时没有这个东西。
    年终奖应该不错吧?
    话说朋友的邻居,中石化的年终奖,买了一套200多万的房子。这个是事实。

  27. 理客 于 2011-01-26 12:12 上午

    如果说H不是技术路线的公司,可能许多人反对,但如果承认H是市场强于技术,H在技术和市场的双路线上,市场是不是说要大一点?
    实际上,一个公司的正确路线很多时候是其公司的位置决定的,即使到现在,H和业界leading比,也没有多少强于对手的技术,而在此前的创业发展其,无论如何市场要在技术前面一点,以后一段时间也很难说,技术是市场里的一个核心工具,在H,这个工具的地位和高技术行业的startup是不同的。
    如果说微软是技术核心路线,比尔可能要笑了,如果说微软帝国不是靠技术称霸江湖的,盖茨也可能笑了。实事求是的说,微软从来没有靠技术领先过,这个帝国靠的是比尔远高于当事人的市场眼光和运作才最终登顶的
    这里可能更多是做技术的,如果有多发一点财的远大志向,最好把技术作为市场和管理的一个重要工具来考虑个人的职业生涯,这个秘密,LD是不会告诉你的,我只告诉弯曲的guys

  28. aguai 于 2011-01-26 12:23 上午

    to 理客
    人才,再来点猛的。

  29. 理客 于 2011-01-26 12:58 上午

    过讲,我是比较蠢材的一个,有钱途的人是不会经常在论坛里瞎逛的,所以有志者如果不是做媒体、网站、有自己目的等等类似的状况,最好把精力多放在本职工作上,收益的性价比更高,这样说,可能以华人技术,唯我弯曲为己任的首席会有一点小小的不高兴:)

  30. hanx 于 2011-01-26 1:32 上午

    这个产品的主要方向是保护客户上网还是保护服务器安全?

    目前看好像是面向保护服务器安全,提一个小建议,最好能考虑针对常见的应用场景和web应用提供配置模板,在那么多项目里面要求一个个配置超过了很多网站管理员的能力,也不易用。

    另外保护服务器和保护客户端有一个显著的不同,客户端面临的主要安全威胁一般都是自动过程,比如一个挂马网站一旦一般不会为了一个客户端不停的变换攻击方式,所以保护客户端的设备一般只要拦截已经掌握的攻击方式即可,不用太多考虑攻击者实时不停变换攻击绕过保护的问题。

    但服务器可能更多的面临人工攻击,攻击者会不停的变换可能的攻击方案进行常识,以demo里面入侵日志里面拦截了上传的脚本木马来说,不知道是怎么检测的,是根据url中的文件名拦截,还是根据重组后的文件进行特征检测,前者太容易被绕过了,但采用后者的话,脚本是相当难以检测的东西,因为变形手段太多了,另一方便对抗变形就算做到极致,就会面临严重的性能问题,而且作为攻击阻止设备还面临一个问题,即什么时候放行这个脚本,想请教一下你们在这方面是如何考虑的?

  31. tt 于 2011-01-26 3:19 上午

    现在的WEB应用很多,而且不断增加,每新出一个WEB应用都可能会产生新的漏洞。

    请问WAF是怎么解决这类问题的呢?

    是不是WAF需要同时卖服务呢?

  32. aguai 于 2011-01-26 4:29 上午

    to hanx
    WAF-WEB Application Firewall,顾明思意就是web应用防火墙,是保护网站的,而不是保护客户上网,是保护网站不被黑客攻击,因为现在网站攻击越来越容易和繁多,加上每个网站程序员,很难关注到网站程序的安全,并且代码审查不容易,代码审查工具忒贵,So….
    脚本木马,无论是加密还是不加密,还是变形的,都有特征的,一个web安全研究人员,10多年的时间写过太多的webshell,对这方面还是游刃有余的。
    另外我们是这样的:Http报头过来,设备先缓存,等到整个数据包发送结束完毕,再通过检测引擎进行检测,这样更大程度上防护起来。至于性能,是我们优势之一,所以没有多大问题。
    to tt
    waf跟应用程序没有关系,是一个独立的东西,新漏洞,新威胁,任何0day,他的攻击手法是一样的,像我们手上有一个dz的0day,远程包含,但是它一样要执行sql语句,这样解释希望您能明白。WAF不需要什么服务,也就升级下规则库。大概就这样。

  33. anony 于 2011-01-26 4:38 上午

    杭州某公司的是否也应该出来晒晒呢?
    别总是藏着,掖着啊

  34. aguai 于 2011-01-26 4:42 上午

    to anony
    话说准备上市了。
    审计非常不错。
    WAF用开源modsecurity做的。

  35. 匿名 于 2011-01-26 4:54 上午

    启明星辰和卫士通都做安全产品的,最近在A股市场被当做云计算概念股炒得热火朝天的,有高手能评价下?

  36. 理客 于 2011-01-26 5:44 上午

    缓存的方法,再考虑检测时间,平均对一个HTTP request带来的delay是多少?是只对首包delay,还是每个包都delay?

  37. Will Chie 于 2011-01-26 5:56 上午

    对HTTP谈首包意义不大,

    HTTP头部的Connection如果是close,response后就关掉连接了,下次重新建,如果是keepalive,那么要看超时时间,实际情况根据浏览器的实现更复杂,但即使是在一个Connection中,几个HTTP的交互也不见得有什么关联。

  38. kernelchina 于 2011-01-26 6:52 上午

    TCP层也有fragment,它的边界不是一个包,而是字节流里面的\r\n之类的,或者是协议边界。延迟还好说了,但是工具并不全部在http header里面,更多是在http body里面。所以说缓存http首包之类的,估计是做得不够深入,或者是对技术还不够了解的市场人员。

  39. hanx 于 2011-01-26 8:19 上午

    to aguai
    俺觉得这也太离谱了吧,按照你上面的意思是在包这一级别进行特征检测,还可以对抗变形,加密?

    举个最简单的例子,我解密的密钥就假设在第二个包的一个常量里,你怎么处理这个流后面的包?

  40. Will Chie 于 2011-01-26 9:10 上午

    个人觉得它所说的加密有可能是SSL的。

  41. liang 于 2011-01-26 4:55 下午

    udp/icmp flood防护也忒猛了吧。尤其是现在很多应用都是UDP协议的,况且部署在网关位置。

    另:单IP虚拟化部署的模式倒是蛮有意思的。

  42. aguai 于 2011-01-26 4:56 下午

    webshell检测是根据它脚本的加密,而不是您说的其他加密,SSL用反向代理部署,直接进行加密,解密。我的意思是:首包+body+尾部,这样才是一个完整的包,完整的包进行检测,才能更加精确的判断是否含有攻击。
    正如kernelchina所说,对于内核驱动,这个技术是真不深入,或者说根本不了解,在这里就不多班门弄斧了。

  43. aguai 于 2011-01-26 4:59 下午

    to liang
    那个flood的值可以自己设定,部署方式可以根据不同的网络环境部署。
    单一IP虚拟化这个,明年11月ipv4不是快用完了嘛,又能减少IP地址费用,还能针对虚拟化出来的服务器进行防护,当然这个主意针对企业等,而不是宋朝政府。

  44. tt 于 2011-01-26 5:49 下午

    单IP的虚拟化,是如何进行分流的呢?是前段加交换机,然后根据vlan tag么?

  45. dsfdsfdsfd 于 2011-01-26 6:38 下午

    to 理客
    说微软不靠技术靠市场扯淡。 微软只是把技术隐藏在用户后面,不像其他公司用技术作为卖点宣传,这才是真的实力。就比如微软做NT内核,用五年时间15亿美元,请的都是当时最好的专家做,这个大手笔,又有哪家公司能做到。其后, 花了上百亿美元,到winxp系统才完善。现在公司就是apple也不敢在微软面前用技术来作为卖点宣传了。现在只要问问顶尖大学的计算机教授,他们认为从技术角度上讲,微软操作系统实际上比其他操作系统不知道好到哪去了。当然做为一个程序员,开源操作系统可以让你更好的理解计算机体系结构, windows操作系统由于不开源,看他的结构,反编译看汇编代码太晦涩罢了。总之微软操作系统对于用户来说,仅仅从技术角度就绝对是不可替代(举例,能把图形放到核心,稳定且速度还不太损失,这一点任何系统都做不到,因为最好的体系结构专家和图形系统专家都在微软)。

    不要误导学计算机的人员

  46. 嗣同老乡 于 2011-01-26 6:49 下午

    这个针对小企业?规模大一点的data center是不是还需要load balance功能?

  47. 徐鹤军 于 2011-01-26 7:03 下午

    支持依讯公司,希望国内出现更多有技术特色的网络安全公司。

  48. shuyong 于 2011-01-26 7:59 下午

    to 45楼:

    刚开始看了点微软的技术和宣传资料,好像天下都是微软的了。其实没有必要这么激动。理客说的是技术型的公司,技术的原创从哪里来的问题。你有兴趣可以从DOS来源看起,一直看到Windows3.1/Windows95技术的变迁,再到上面热门软件的变迁,比如编译器/浏览器这类的。这期间微软的竞争对手是怎么兴起,怎么失败。这情形和现在的腾讯的手段很是相像。

    WindowsNT 3.1从一开始就是一个相当精美的微内核OS。这可是资料上说的。但资料上从来不解释从3.1->3.5->4.0以及之后系统是怎么退变为一个大内核的。这是一个明智的决定,但做为一个例子也从另外一个方面说明微软不想在OS方面有突破了。Apple从来不用技术点做宣传,因为JOBS更聪明,他知道这个世界上不懂电脑的人远远多过懂电脑的人。他知道要把电脑卖给不懂电脑的人,他该怎么设计产品,他该怎么宣传。“他们认为从技术角度上讲,微软操作系统实际上比其他操作系统不知道好到哪去了。”这又从何说起呢?做技术的就要用技术说话,你一条条地摆摆出来嘛。这事情其实不需要“问问顶尖大学的计算机教授“,问问这里顶尖的首席就可以知道,由需求决定系统,只有合适需求的次优系统,没有最优系统。

    最后补充一个,“把图形放到核心”,不完全是一个技术的决定,这是性能/稳定性/安全性的综合考量,还有一个原有系统的继承问题。别的系统不是不能做到,侧重点不同罢了。再补充一个,”因为最好的体系结构专家和图形系统专家都在微软“,别人的宣传片没有必要成为自己的信条。我相信“微软有最好的体系结构专家和图形系统专家“。但要都在微软。不知道有多少个IT公司要笑了。

  49. 陈怀临 于 2011-01-26 8:06 下午

    “问问顶尖大学的计算机教授“,问问这里顶尖的首席就可以知道,由需求决定系统,只有合适需求的次优系统,没有最优系统。”

    首席看了这个,甚欢,取酒,小酌了一杯。。。

  50. kevin 于 2011-01-26 8:34 下午

    插一杠子,apple好像在industry兜售他的GCD的说

  51. playmud 于 2011-01-26 9:40 下午

    有两点疑问:
    1,全组包是为了匹配更精确?最后一个包发现威胁丢弃还是rst?会不会导致防火墙本身这种机制被ddos?
    2,用正则匹配?什么配置的机器禁得起正则匹配检测威胁的霍霍?

  52. tom 于 2011-01-26 9:41 下午

    to 34楼,据说那家公司审计产品也是oem的,听说明年要上市

  53. Unknown 于 2011-01-26 10:30 下午

    1 全组包的目的有两个,对抗规避和细粒度协议解码;发现威胁之后的动作一般都是可选的,丢弃/RST/回应特定页面(”你Y再攻击我翻脸了!“),一般现代 WAF很少直接包层面上匹配的了,所以针对这种机制的ddos基本不用担心

    2 正则匹配是最常用的做法,匹配引擎是可以做到很高效的,只不过大多数人用pcre用的太久导致对这方面的业界进展不太敏感而已

  54. frank 于 2011-01-26 11:50 下午

    52楼,你怎么知道的?OEM很丢人吗?

  55. anon 于 2011-01-27 12:42 上午

    此frank想必非彼frank吧!

  56. aguai 于 2011-01-27 1:03 上午

    Unknown回答得非常好,有机会还希望能请教请教。

  57. hanx 于 2011-01-27 5:25 下午

    to unknown

    全组包是什么意思?重组整个tcp流?还是需要分片重组吧,或者仅重组特定长度,

    检测发生在重组后?那么重组完成之前,流里面的包放行不放行?不放行的话,会不会严重影响延迟和一些应用超时?放行一部分的话,攻击载荷是不是已经有可能已经放行过去了?

    现在您知道的正则能作多高效?有没有具体数据?在很多场合下对正则的引入效能会有数量级的下降。大量使用的ac,wm这些都是不优的办法

  58. Unknown 于 2011-01-27 8:21 下午

    to hanx

    全组包是多个层面上的重组,ip分片重组是最下面的一层,也是基础层,包括分片的重组,重叠的处理等等,上面就是tcp的流重组,重点在重叠的处理方式,最上面则是应用层的处理,也包括重组(layer7的应用也是可以分片的),总之,一层层来,每层都可以作检测,检测和重组是交错的,不是很多人想象中的那种层次分明的结构;

    正则可以作很高效,至少在几百条情况下1G吞吐没任何问题,重点在于算法优化和正则表达式写法优化,这块是要有点功力的

  59. 阿峰 于 2011-01-27 9:12 下午

    WEB安全有需要啊,俺的大客户gzpcc.com就迫切需要解决,内部上了N多的WEB服务,恨不得财务系统也WEB化~~~问题是安全问题没底,前几个月曝出某领导的密钥盘被儿子拿去外面登陆系统,目前正在做风险评估和责任鉴定~~~

  60. zeroflag 于 2011-01-27 9:32 下午

    to Unkown:

    考虑一个特殊情况,全组包要求大缓存。如果攻击者发大量未结束的HTTP/HTTPS请求,你的设备会不会由于缓存被占满而被DOS?

    如故意将GET请求拆分到多个TCP包中,然后将最后一个包延迟2s发送,同时配合进行大量的并发。这其实就类似于syn flood攻击。

    另外,如果对方是在上传大附件(比如100M含有恶意代码的视频)的话,你又如何处理?还是你的设备根本不理上传操作?

  61. ganggang 于 2011-01-27 9:54 下午

    上去看了下,基本逃不出IDS的影子,根据内置的检测规则分析,也是简单的字符串或者正则匹配。
    按理来说用户手工添加的规则,应该和内置的规则是一个复杂级别,所以从手工添加规则的界面来看,还没开源的MOD_SECURITY检查的彻底和针对性强呢。

  62. 阿权 于 2011-01-27 9:56 下午

    铱迅具有完全自主研发的协议栈全状态检测引擎,还具有针对变形编码攻击的防护,可以有效的防止“IP碎片攻击”、“TCP碎片攻击”、“变形编码攻击”等,众多网络设备都存在被绕过的风险,但是铱迅的检测引擎真正体现了它的强大。
    —一般稍微专业点的国内安全公司都会有这些,请问贵公司的和其他公司区别在哪里,愿闻其详。

  63. ganggang 于 2011-01-27 10:06 下午

    在WAF设备上用FTP/SFTP远程轮询,检测文件变化的防篡改,都是一个蛮好的思路。虽然也一样会面临网页发布等的问题。但是比绿盟的单纯基于CACHE只能防护完全静态的文件有了进步。赞一下。

  64. tom 于 2011-01-27 10:09 下午

    to 54楼frank,oem一点也不丢人,都是混江湖的吗,明年我们有很多产品也要oem,所以更不丢人,江湖啊

  65. kernelchina 于 2011-01-27 10:46 下午

    如果是轮询,不会自己成为一个攻击点吧,多长时间去轮询一次,粒度多大,能支撑多大的网站?

  66. Will Chie 于 2011-01-27 11:27 下午

    “一般稍微专业点的国内安全公司”
    其实这个已经够他们拽的了,市场做的好的话,足以生存了,不需要有啥别的特色,特色以后可以慢慢发展。

  67. aguai 于 2011-01-27 11:54 下午

    to ganggang
    内置规则已经相对来说非常完善了,自定义规则只是用于用户体验,扩展,针对不同的web程序,进行灵活性的改变而已。
    to 阿权
    列举一个判断sql注入的语句
    正常编码:and 1=1
    ASCII编码:%61nd 1=1
    Unicode编码:%u0061nd 1=1
    只是一个列举,但愿您能明白,web攻击手段多种多样,变换方式多种多样,产品没点实力,我可不敢来弯曲这个大牛众多的地方裸奔。
    to Will Chie
    公司生存是没有任何问题,但是要发展起来,还有很长的路要走,另有兄弟要跳槽,可以跟我联系。销售,售前。

  68. 天外有天 于 2011-01-28 1:17 上午

    web里面带文件的那种就不能考虑了,
    文件还可能压缩,这种情况复杂度不是一点半点。

    我想产品做的是流检测。。

    应该也不是缓存http里面的全部数据,
    而是检测需要的数据包而已。

    否则http连续模式,几个G的数据。设备自己就缓存死翘翘了。

  69. 天外有天 于 2011-01-28 1:25 上午

    Http报头过来,设备先缓存,等到整个数据包发送结束完毕,再通过检测引擎进行检测,这样更大程度上防护起来。至于性能,是我们优势之一,所以没有多大问题。
    ————————————–
    这个说法挺难理解。。

    基于多模式匹配的检测算法本身是带状态的,
    不用把数据包都缓存起来,一个http传输到一半,截止就行了。

    只不过流检测对http里面带文件的方式不管用。
    压缩过的文本已经失去了特征字段,
    或者前面的一半数据已经把带毒文件传完了,
    这种情况必须缓存,解压,扫描。
    不过这带来的开销太大了,真正实用化的产品,俺没见到。

  70. Unknown 于 2011-01-28 2:11 上午

    to zeroflag

    全组包未必大缓存,现代的商用应用安全防护产品(包括IPS/WAF/EAF/DF/DLP……)的一个高级特性就是尽量避免使用缓存,有缓存就意味着内存的分配,意味着指针很可能指飞,意味着工程师必须作好和内存bug肉搏的准备……总之是一件非常痛苦的事情,所以,大家都在尽量避免使用缓存,而实际上这也是可以做到的

  71. 理客 于 2011-01-28 2:30 上午

    请教:不缓存的方案有哪些理论支撑和商用实践?

  72. hanx 于 2011-01-28 2:40 上午

    to unknown 及其他各位老师,专家:

    我们举个实例来谈吧,以webshell木马检测为例,

    1、假设已有木马样本,并成功提取特征
    2、木马被阻止后,攻击者尝试用编码方式绕过,攻击者采用了如下两种方式尝试,
    a、用混淆器对代码进行混淆,请问这时候的检测策略是什么?性能上有何影响。不全缓存如何检测?
    b、攻击在脚本里面内嵌了一个编码函数,并利用放在同文件不同位置的参数进行编码(不考虑放在不同文件的情况,因为这时候是网关不可能对抗的),攻击代码是被这个编码函数进行编码的(也不要考虑加密),由于编码函数可以随意更换,被编码后的攻击代码不存在不动点,请问这时候如何检测? 请问这个时候不大部分缓存还有没有检测可能性?

    请注意,以上两个方法都是没有太多技术含量的,普通的脚本小子即可采用。

    另外前面提到,服务器保护产品必然面临攻击者尝试绕过保护措施的攻击,和面向上网网关(utm等)等并不同,所以这种例子应该是相对实际会发生的。

    3、据我所知确实有部分产品内嵌了脚本虚拟机,但是webshell类木马有各种语言,不可能一一解释,即使专门对抗js脚本的,性能一般也很难接受,这个方案下老师们有没有见过高性能的检测方案?

  73. Unknown 于 2011-01-28 2:49 上午

    to 理克
    不是完全避免缓存,而是尽量避免缓存,简单地说是流式检测,protocol analysis base on state machine,可以基于硬件也可以基于软件来做
    具体的商业实现不是太多,但你可以看看gartner领导者象限里面最右上的那几个……

  74. Unknown 于 2011-01-28 3:10 上午

    to hanx
    必须说,兄弟,你问到点上了,首席会很高兴的
    1 很多厂商在宣传产品的时候会尽量避免把这块说透,对抗这种变形/混淆/加密对于内容安全厂商来说是一个非常非常非常有难度的挑战,很不好搞,只有少量厂商可以在一定程度上解决这个问题,这也是催生云安全的一个重要因素,想想桌面老牌杀毒厂商的困境就明白了
    2 规避和反规避是一对矛和盾,你知道我怎么检测的自然可以找到方法反检测,这个任何人都没办法,例如有人知道他的网关处有台行为监控系统可以解压文件99层,那么他把敏感文件压缩100遍,设备自然没招
    3 即使不能从理论上完备地解决问题,能部分解决问题也是可以接受的,就好比GXX,懂点IT的都会翻X,能说GXX没用吗?至少它提高了你访问xx网站的成本,那么从百分比上说可能就有百分之70-80的人不再去访问xx网站了,这也是有意义的

  75. Unknown 于 2011-01-28 3:12 上午

    安全防护的目标不在于百分之百安全,而在于提高攻击者的攻击成本到一个他觉得不太值得的程度

  76. 理客 于 2011-01-28 3:31 上午

    多谢指教
    不同的用户,有不同级别的安全需求,需要的方案从成本到技术也是有差别的,这些差别,也是新老供应商的机会
    级别越高的安全系统,越是需要一套系统的方案,单个设备的能力是有限的,比如100层问题,实际就是超异常行为的处理问题,当发现这种问题的时候,处理方法可以选择:直接丢弃/通过;镜像后丢弃/通过;后台清洗等等。
    从道的角度看,最高技术境界是追求最全面的防护
    而从魔的角度,最高境界不一定是做到变态的100层,而是如何在最普通的报文行文里隐藏最大的祸心,这才是最可怕的敌人,如最可怕的人既不是小人,也不是君子,而是如披着完美羊皮一样的狼样的伪君子

  77. kernelchina 于 2011-01-28 5:00 上午

    延迟太大,用户也没法忍受吧,先要搞清楚要保护的对象,这是前提。WAF部署在什么地方?企业出口,用来保护进入内网的数据;还是部署在服务器前端,避免受到攻击?

  78. Icefrog1900 于 2011-01-28 9:02 上午

    1)绕过检测其实很简单
    2)没用用户态,难道是NDIS?
    3)特征码如何生成? 应该多少用了(大部分)snort的signature

    欢迎交流, icefrog1900@gmail.com

  79. Anon 于 2011-01-28 9:52 上午

    hanx很给力!求解答。

  80. 晕倒 于 2011-01-28 5:25 下午

    NDIS是windows驱动

  81. A8 于 2011-01-28 8:06 下午

    是南京的公司啊?

  82. tt 于 2011-01-28 8:44 下午

    说实话,公司在南京是个很失败的事情,技术的交流是靠人才的,南京在这方面比北京差太多了,技术一但出现更新,南京很难跟进。

  83. 吴朱华 于 2011-01-28 9:07 下午

    to tt:
    在这个时代,公司地点没有过去重要:)

  84. anonymous 于 2011-01-28 10:55 下午

    “web攻击检测引擎研发由10多名拥有10多年web安全研究的国内顶尖人员构成。”
    这个,有个1-2个牛人就够了吧,是不是把测试也算上了?依讯现在有多少人?

  85. anonymous 于 2011-01-28 11:03 下午

    “web攻击检测引擎研发由10多名拥有10多年web安全研究的国内顶尖人员构成。人员配置都非常年轻,是一个很有青春活力的团队。”

    在国内,10多年的安全经验的团队也叫年轻,看不懂了。过分谦虚?

    “千兆产品每秒HTTP请求叔率达到56000”
    看看工作在应用层的开源反向代理HAPROXY,首页上的news:Oct 23th, 2010 : new httperf results : 572000 reqs/s
    “The load reached a max of 572000 requests/s with an average around 450000 requests per second. ”
    差不多刚好是10倍,

    唉,软文就是经不起推敲

  86. multi-core 于 2011-01-28 11:58 下午

    的确如此,弯曲上高手很多,而且都是偏向技术类的,很多软文过分强调市场。如WAF中的两个参数CPS和TPS,国内只要是WAF厂商都会往高处写指标,如果到真实环境中测试很多都挂了。

  87. ganggang 于 2011-01-29 12:47 上午

    5楼和85楼不是说他写的性能参数太高了,
    而是这么低也好意思说出来。

  88. baalchina 于 2011-01-29 3:14 上午

    依讯的web防护软件版一直在用,关键是免费…

  89. aguai 于 2011-01-29 5:36 上午

    to anonymous
    一个团队的年轻,活力不是用年龄来衡量的。还有牛人,不是大家看到的那些啥专家专家的,他们都很低调,只是我啥本事也没有,在弯曲牛人众多的地方,还请见谅。
    to 多核哥
    是的,大家都往高的性能指标报,然后铱迅却却相反,往低处报。说个上海的高校案例,500多个网站,10个G的出口,多家过去测试,真的很多都挂了,然而用的我们的产品,放在出口,一点问题都没有。说我吹嘘也好,啥都行,但是事实胜于雄辩。欢迎大家测试。ps:我最喜欢客户测试我们的东西了。
    to baalchina
    软件版的话,后期可能完全免费。还会增加一些功能,软件版最大的功能,是用来测试我们的检测引擎和新规则,最大程度上保证硬件设备不会出现问题,客户买的东西经过众多人测试过的产品,这个是我们理念之一。
    另外:今天回家,广东不太平,一群小偷,大家注意防盗。平平安安回家,高高兴兴工作。

  90. aguai 于 2011-01-29 5:49 上午

    to A8和tt
    正如吴总所说,公司地点跟以前的重要性已经相册很大了。南京是个学术氛围非常好的地方,当然比不上京城。但是也有她的优势。
    还有tt说的技术更新的问题,北京比国外的快?不可能吧,言下之意是技术更新我们要与国外看齐,正如首席大人所说:跟辽国看齐不丢人!

  91. 吴朱华 于 2011-01-29 6:19 上午

    to aguai:
    不要叫吴总,我只是一个干活的:)

  92. tt 于 2011-01-29 6:30 上午

    回到文化大革命时代了?想种出多大萝卜就能种出多大萝卜?

    通过什么途径和国外看起?

  93. IT工程师 于 2011-01-29 10:26 上午

    了解过WAF一段时间,铱迅的WAF还没看过,有机会可以见识一下,如果铱迅的没有虚标的话,应该在WAF实用领域,这里强调的是实用,实验室产品不说,应该还是蛮高的。
    实验室产品我们都能做出上百万次的(性价比不考虑),但一到真实环境就不行了。
    目前国内、国外真正在市场上卖的,大多对http请求的响应在1-2万次左右。很多产品低于1万次。

  94. IT工程师 于 2011-01-29 10:29 上午

    to:tt
    不能老拿老眼光看中国,现在美国看着中国发展不也是恨的牙痒痒,以前文化大革命的时代,老美能象现在这样?

  95. IT工程师 于 2011-01-29 10:51 上午

    另:国内很多产品都是用snort改的,并且很多都用的snort的规则,如不出意外,铱迅也是这样的吧,所以还是对性能有所怀疑。

  96. Icefrog1900 于 2011-01-29 2:52 下午

    有对安全(网络,OS或malware)方面感兴趣的朋友,请邮件联系我。More technical details can be disscussed

  97. tt 于 2011-01-29 3:27 下午

    是嘛?大宋现在都这么牛掰了?我现在就去设计个跟ipone一样牛的手机去。

  98. 天外有天 于 2011-01-29 7:01 下午

    还是从基本概念说起吧,否则太混淆了。

    检测无非两种,流检测和文件检测。

    流检测的原理是特征码匹配,
    用的是多模式匹配,dfa-nfa状态机这些。
    流检测的好处是快,不用缓存数据包,很多可以做到很高的吞吐。
    坏处是特征码如果压缩或者变形,是没办法处理的。
    当然特征码如何写也是很考验功力的。。。

    文件检测是全部收下来再检测,
    基本原理也是特征匹配,dfa-nfa状态机这些。
    因为全部收下来了,是可以解决某些压缩,变形处理的。
    坏处是这种情况是必须保存所有数据包的,吞吐上不去。而且延迟很大,很多时间敏感的业务不能支持。如果是处理多重压缩,更是慢的不行。。

  99. 天外有天 于 2011-01-29 7:04 下午

    不是完全避免缓存,而是尽量避免缓存,简单地说是流式检测,protocol analysis base on state machine,可以基于硬件也可以基于软件来做
    具体的商业实现不是太多,但你可以看看gartner领导者象限里面最右上的那几个……

    ————————————–
    看不下去了。

    流检测,最普通的大路货了。
    开源的snort就是流检测,基于状态机的。怎么成了具体的商业实现不太多了?我还没见过不是状态机的流检测。。

    支持模式匹配的芯片也有不少了。。
    这个芯片也可以做DPI,都是一回事。。

  100. WAF 于 2011-01-29 7:13 下午

    不知道你们的产品技术指标和imperva\F5\FortiWeb相比有没有特别的优势?我只是问问啊

  101. 天外有天 于 2011-01-29 7:14 下午

    国内厂家就这点不好。
    软文喜欢随便吹。。

    业界使用了十几年的技术,
    最基本的特征码和多模式匹配(多模式匹配基于dfa-nfa状态机),
    也搞的好像啥独创一样。。。

    另外补充一点,多模式匹配和特征码多少无关的。
    100条特征码和1000条的检测效率一样的。
    别把这个也吹成什么创新了。。

  102. IT工程师 于 2011-01-29 8:21 下午

    TO:天外有天:
    本人不太懂,请教下,文件检测用在WAF上合适吗?如果用在mail上感觉还可以接受。

    TO:tt
    非常期待你设计个iphone的手机,当然不知你有意无意,把”h”丢了,”h”是HOME的开头第一个字母。

  103. 天外有天 于 2011-01-29 9:32 下午

    文件检测用在WAF上合适吗?如果用在mail上感觉还可以接受。
    ————————————–
    文件检测是防病毒,流检测是入侵防护。场合不一样。

    合适不合适,哪就是一篇大文章了。
    自从厂家忽悠出来UTM的概念,防病毒也慢慢成了个忽悠指标了,但是实际上网关防毒不实用,
    所以市场慢慢就演变成现在这个一件事情各自表述的局面。。

  104. 没有任何技术可言 于 2011-01-29 9:43 下午

    评论立场就有问题。
    熟人之间的吹捧而已。
    技术领先???
    哪个RFC是其定义的呢?
    没有的话就是手熟尔….

  105. 的确没有技术可言 于 2011-01-29 10:28 下午

    感觉的确没有什么技术可言,但对于实用产品来说,能满足市场需求就已经非常不错了。

  106. Will Chie 于 2011-01-29 11:16 下午

    TO IT工程师:
    国内早就有搞出IPONE的了,你知道人家管那叫啥不?“山寨”。
    还有山寨NOKIA的叫HOKIA见过没?

    给你们的产品推荐个名字呗?梭于鱼。

    先要自己对自己定位准确,才能做出正确的决策。

  107. zeroflag 于 2011-01-30 1:24 上午

    BlackHat DC 2011中的一个叫Ryan Barnett黑客做的XSS Street-Fight!的演讲,里面有一段JSP的代码:

    ($=[$=[]][(__=!$+$)[_=-~-~-~$]+({}+$)[_/_]+
    ($$=($_=!”+$)[_/_]+$_[+$])])()[__[_/_]+__
    [_+~$]+$_[_]+$$](_/_)

    其实,这段代码可以分成两个部分,第一个部分其实就是sort(),第二个部分是alert()

    看了这样的代码,我觉得从解码角度要解决XSS真的就是浮云了。

  108. 中间人 于 2011-01-30 2:45 上午

    很看不惯一些人,从头到尾看到后面,越看心越凉,别人东西好不好,你们用过吗?大家互相攻击,有什么意思呢?弯曲是讨论技术的地方,不要掺杂这么多公司的因素在这里,这里不是娱乐圈!况且弯曲大部分人都是为别人打工的吧,你不是老板,你指点什么?说啥没技术可言?还是老老实实研究技术去吧。

  109. Panabit 于 2011-01-30 7:15 上午

    窃以为,作为一个技术人,时刻要知道“技术是用来解决实际问题的”,解决了实际问题的技术,就是好技术。国人老有一种同行相轻的意识,做技术的互相之间也相轻,的确是不太好。与其大家互相拆台,还不如互相敬重,多一条路,这有什么不好?我想首席会欢迎任何一个初创公司来此宣传的,无论大家认为它技术怎么“不行”,大家还是多体谅一点比较好。另外,楼上的,你也不要生气,弯曲藏龙卧虎,在宣传的时候,还是尽量避免一些太市场化的东西,要不然,肯定会招到很多“砖头”的,呵呵。这个帖子里我知道像zeroflag,will chie等,都是业内老鸟。马上过年了,兄弟我先祝大家新年快乐,更祝首席青春永驻,弯曲新年更上一层楼!:)

  110. IT工程师 于 2011-01-30 5:44 下午

    马上要过年了,在这里祝大家新年快乐,献给像我这样还战斗在第一线的弟兄们^_^。祝大家阖家欢乐,献给幸福回家团员的弟兄们!!!
    祝弯曲明年越做越好,祝铱迅明年也能越做越好。

  111. 没有任何技术可言 于 2011-01-30 6:41 下午

    总经理是来自华为—华为很不错么?
    就算不错的话怎么不再华为继续和高手一起促进发展了?
    研发总监来自摩托罗拉,此人在美国做了多年协议,对底层驱动研究异常透彻—那还继续在美国混多好?怕是连基本宗教都没搞定,始终在美国是下等人吧…
    web攻击检测引擎研发由10多名拥有10多年web安全研究的国内顶尖人员构成—国内的web也就有10年多的市场,这帮子无非也就是做个人主页的出身也许还当过半吊子红客啥的,顶尖不顶尖要业界认可的标准文档说话…….

  112. 陈怀临 于 2011-01-30 7:31 下午

    都过年了。弟兄们说话要peaceful一点。其实网上做人也网下做人没区别。Tolerate the difference. 世界上的事情,许多与你的眼睛和心灵的观察不一致。但要能够宽容和理解这些不同。这才是度量和智慧。

  113. zeroflag 于 2011-01-30 11:08 下午

    其实楼主挺冤的,这篇文章挨骂的原因在于文风,而非大家对这家公司本身有什么意见。如果Panabit的东东也是用这种文风发上来,估计也是骂声一片。其实不排除他们产品本身其实做的可能还不错。

    算是一点忠告吧,文章上弯曲的前提是要做好把自己扒光的心理准备的,否则还是在评论区里面混混吧,比如我这样的。

  114. 老韩 于 2011-01-30 11:32 下午

    楼上说的没错,我和很多厂商的朋友聊起过在弯曲评论做推广的方法,基本上大家都认为此事不能由Marketing负责,除非公司产品过硬(至少有自己的东西)、部门强势、部门领导是技术出身且部门里有专门的市场产品人才。满足条件的不多啊。

  115. aguai 于 2011-01-31 6:13 下午

    各位大牛新年好啊。就快过年了还不忘关注铱迅公司,非常值得高兴。谢谢大伙了。
    zeroflag兄说得是,写类似这样的“软文”,咱不拿手,您如果说让俺写个渗透测试报告,这咱还是能拿得出手的,这不一直在改变,一直在提升自己。其实啊,做任何事情,都是跟做人有关,这做人也是种学问,很久前跟首席大人这类型的教授聊天,感受良多,大家互相竞争攻击,都是为了生活,要放好自己的心态,做好自己,赢得尊重。

  116. 天外有天 于 2011-01-31 11:27 下午

    首席和了一把伟大的稀泥。。。

    俺上弯曲,就是因为这里够尖锐,
    否则,看厂商广告得了。

    新年到了,和谐一些,
    祝奋斗在大公司,小公司,初创公司的技术人员
    钱途光明》》》

  117. error.right 于 2011-02-01 1:56 下午

    纯洁快乐!

  118. IT工程师 于 2011-02-02 1:21 上午

    明天就过节了,先给大家拜个早年!

  119. Unknown 于 2011-02-03 12:49 上午

    to 天外有天
    下面说的东西可能是我一家之见,基于我自己见识的浅薄,一定会有些疏漏,请大家指教:
    1 对于流检测的理解:流检测是个什么概念?从入侵检测领域理解可能有很多不同的意见,我理解为流检测就是流式检测,这个流式体现在现代入侵检测及防御系统的各个层面上,而不是仅仅在tcp层做个流式缓存处理下特征分包和分片的问题,具体可以理解为在tcp层之上的所有处理都是流式的,协议解码器是流式的,文件还原器是流式的,检测模块也是流式的,整个处理过程是还算有点复杂性的,例如,现在有个gzip压缩的pdf文件,pdf文件里面有个恶意的script脚本,按照通常的流程来的话,要解压缩,还原文件,提取script后进入检测模块检测,那么现代IPS中以上的所有步骤都是流式的,pdf文件解压缩一点就还原一点,就检测一点,还原完了就检测完了,整个过程中缓存的使用降低到最低,时延也最低,目前只有有数的几家可以做到,这是现代IPS和snort移植品最大的区别,具体大家自己去想二者的区别

  120. Unknown 于 2011-02-03 1:03 上午

    2 正则表达式: 在这方面有过经验的人会知道,正则表达式要想在安全产品中用并不难,但要用好还是有点技术含量的,需要解决几个问题:
    大量正则表达式在dfa实现时的状态膨胀问题,例如在静态页面中搜索上千个正则表达式,怎么来解决状态膨胀是需要很好考虑的问题
    必须要有非常强悍的检测引擎来和正则表达式搭档,我们都知道,检测其实就是定义逻辑来描述数据特性,正则表达式不是万能的,遇到写不了正则表达式的情况下还是要依靠一个能进行复杂逻辑检测的引擎
    不要轻视正则表达式……

  121. 华龙 于 2011-02-03 1:19 上午

    首席,有传言你离开华为了,真的假的?

  122. aguai 于 2011-02-03 4:48 上午

    Unknown大牛,春节快乐啊。
    华龙大牛,欢迎爆料啊。
    有请8卦哥。
    哈哈。

  123. Ji 于 2011-02-07 10:52 下午

    软件这块貌似也用了开源玩意

  124. Will Chie 于 2011-02-07 11:06 下午

    用开源不是问题,思科,juniper,华为,我知道的通信类的公司几乎都用了开源的东东,只要注意license就OK,freebsd、apache和麻省理工的license都可以直接用代码,也不用开源,GPL的你只需要把改动的部分开源即可。

  125. 天外有天 于 2011-02-08 8:34 下午

    1 对于流检测的理解:流检测是个什么概念?从入侵检测领域理解可能有很多不同的意见,我理解为流检测就是流式检测,这个流式体现在现代入侵检测及防御系统的各个层面上,而不是仅仅在tcp层做个流式缓存处理下特征分包和分片的问题,具体可以理解为在tcp层之上的所有处理都是流式的,
    —————————————

    流检测是指不用把数据都收完全的检测。倒不是你说的tcp层什么的。

    压缩或者变形后的文件是没办法解压一点,检测一点的,这一块是空白区。你这个想法不错,但是存在很多技术难题。如果能突破的化,那倒是一种新的产品啦。。

    正则表达式基本同意你的意见,不用正则,效率快一些。不过很多特征码,不用正则真是非常难啊。

  126. 十分八卦 于 2011-02-11 6:02 下午

    To 天外有天
    “压缩或者变形后的文件是没办法解压一点,检测一点的,这一块是空白区。”

    流检测和文件检测也没有无法逾越的鸿沟,其实质就在cache的长度和处理的频率。不做cache,包到即处理,就是极端的流处理了; cache全部,收完再处理,就是文件咯。这里显然是有中间状态的,比如cache一个固定的block长度,再处理。这个block定义的长度取决于你要做的应用特性,比如重排序,比如解压缩等等。有一些压缩算法,是可以收到一部分后就进行解压的,而有一些不可以。稍微做的完善一点的streaming-based方案,都会对这些压缩算法做区别处理,所以,他不是个空白。

  127. aguai 于 2011-02-11 7:04 下午

    天外有天说得如是,当初选择规则正则匹配这个技术也是很慎重的,经过之前软件版的多种规则匹配,已经解决正则匹配速率问题。大伙做公司也可以借鉴一下,先弄个软件版免费给人用(白老鼠),测试技术实现是否正确,多重选择,这样做出来的产品才是完善,基本没啥问题。
    另外铱迅信息正在开发自学习功能,国际厂商搞出来的东西,实话说这个是个鸡肋,但是人家是鼻祖,别人有的我们要有,别人没有的我们也要有。总之还得一步一步来,安全本身就是一个持续的过程,2011加油各位。

  128. aguai 于 2011-02-11 7:06 下午

    另外八卦一下:小道消息山石收购网康可能性很大……可见2011是安全厂商收购合并,资本融合,安全产品白菜价竞争激烈的一年。这一切的缘由都来自某上市大哥….好吧,我多嘴了。。

  129. 天外有天 于 2011-02-11 7:40 下午

    稍微做的完善一点的streaming-based方案,都会对这些压缩算法做区别处理,所以,他不是个空白。
    ————————————–
    道理说起来容易,实际的产品就千难万难。
    太多的文件是不能边接收边处理然后检测的
    (不只是压缩,还有变形,扰乱等等)

    不明白你说的稍微完善一点的是那些。
    我知道mcafee,TP,symantec都没实现这个。
    实际上,针对文件的叫做防病毒,这个和ips是两个概念了。产品形态更是差的远。

  130. 十分八卦 于 2011-02-11 8:39 下午

    我说了,是“有一些”压缩算法,没说全部。解压解码这一系列东西,都是只能做try best而已,千难万难都要试着解,解多少算多少,所以才说是区别处理。要做文件解压缩,应该主要是AV的工作(个例:IPS中网站挂马处理需要处理gz,这个恰好就可以分block解压:),symantec我记得是proxy-based av,TP应该不做AV,关心个gz差不多了,卖咖啡的没注意研究过,不评论。

  131. nick 于 2011-03-03 6:57 上午

    我们单位已经购买了铱迅的产品了,非常不错。之前测试了国内有名的公司的同类产品,都满足不了我们现在单位的网站流量,铱迅的性能真不错。推荐一下,很赞。

  132. bbb 于 2011-03-23 4:02 下午

    web攻击检测引擎研发由10多名拥有10多年web安全研究的国内顶尖人员构成

    ————-
    果然是亮点 hoho

  133. aguai 于 2011-03-23 11:59 下午

    bbb,大家都转型了,一切尽在不言中。

  134. marsaber 于 2011-04-20 7:54 下午

    听说,你们高端的web应用防火墙的最大并发连接数能到800万?

  135. marsaber 于 2011-04-20 7:56 下午

    web攻击检测引擎研发由10多名拥有10多年web安全研究的国内顶尖人员构成

    ——————–
    不知道绿盟的10多年安全经验的大牛有几个。

  136. fiction 于 2011-04-22 7:30 下午

    aguai,
    “天外有天”说的dpi的匹配芯片,你们为啥不用尼,不符合要求,还是太贵,还是开发困难,还是太牛刀杀鸡。。

  137. aguai 于 2011-05-11 1:00 上午

    to marsaber

    最大并发连接800万那个是旧了产品了,现在最新的是这个:
    HTTP请求速率320000,并发TCP连接数1000万,最大网络总吞吐量10Gbps,清洗流量8Gbps

    很多人有误区,其实WAF这个东西不是看TCP的并发数的,跟他毫无关系,注意是看HTTP的新建速率,这个才是决定WAF性能的关键因素,并发联系那个写多少都无所谓,怎么吹都行啊。

  138. tom 于 2011-05-16 1:00 上午

    HTTP请求速率320000这个性能确实不低了。。。。
    想请教下aguai,你们的waf能检测内部僵尸的流量吗?

  139. Will Chie 于 2011-05-16 1:06 上午

    这个好像不是WAF的需求啊?个人觉得WAF应该专注于保护由外到内的流量,而不是由内到外的。

  140. aguai 于 2011-05-16 1:13 上午

    tom,是内部的机器被人控制了,变成别人的僵尸网络的一部分是吧?这个东西不是WAF做的,而是防病毒,防DDOS做的事情。不知道这样回答是否可以。
    willchie大牛,您好,很多人都觉得WAF是防护由外到内的攻击,但是由内到外的也相当重要,返回的数据包也需要进行坚持,这样才能做到万无一失,不能做成短板,也就是常说的双向检测。很多人控制了这台服务器,或者上传了个webshell,去控制另外的服务器,比如传一个PHP的DOS页面,只要有人访问这个网站,就对某个网站D一下,如果流量大的话,对方肯定被D挂,比如在弯曲挂一个,D百度都不是问题,啊哈哈。

  141. Will Chie 于 2011-05-16 1:22 上午

    @aguai, 受教了

  142. aguai 于 2011-05-16 1:24 上午

    Will Chie大牛,不敢当,大家交流交流。还请多多指教。

  143. Will Chie 于 2011-05-16 1:27 上午

    :)

  144. tom 于 2011-05-16 8:39 下午

    to aguai,虽然说waf主要防外到内,但是现在也有一些产品把内部的僵尸检测放在waf上了,所以我才有这么一问

  145. aguai 于 2011-05-18 2:32 上午

    to tom
    你说的可是某研发中心在硅谷某公司?不多打探,咱谈技术,WAF应该做的事情,是防护web攻击,他才叫WAF的,如果把太多的外围的东西,加上WAF上,性能如何保证,主要的作用怎么体现出来,难不成叫他是WUTM?一家之言。。。。不过,是否有资料,我学习下。发我mail:yangzhiwei@yxlink.com

  146. Len 于 2011-05-18 2:45 上午

    确实如此,现在好多功能就是有的没的都往里加,最后用户也不用。

  147. skybase 于 2011-05-19 7:53 下午

    HTTP请求速率320000,并发TCP连接数1000万,最大网络总吞吐量10Gbps,清洗流量8Gbps

    讨论了这么多流检测,还是文件检测,
    想知道你们到底是stream based or Proxy based?

    如果stream based,觉得这个性能不是太难达到; 如果是proxybase, 所谓的清洗流量8G,是指8G的流量都进行你们的所谓的正则匹配的流量吗?还是仅仅扫描一下http head,其实绝大多数(90%)的流量只是一个bypass?

  148. aguai 于 2011-05-19 10:06 下午

    to skybase
    吞吐能力就是说数据包只从我们设备过一下,不检查任何内容。这个确实非常简单就能达到。
    清洗流量的话,当然是带上规则的,是全组包,而不是单一的http头,很多人没解决全组包的性能瓶颈,还有正则匹配的快速的匹配,快速的检测上。如果不是目前规则集越来越多,这个性能还能提上去。欢迎探讨。

  149. tom 于 2011-05-19 11:32 下午

    aguai,这个性能你们用加速卡了么?

  150. 网路游侠 于 2011-05-19 11:44 下午

    话说铱迅的WAF还是不错的,但是搞技术的人,太低调了,得学会包装。包装公司、包装产品、包装员工。

  151. skybase 于 2011-05-20 12:03 上午

    to aguai:
    能不能理解实际上你们是proxy base,即使网络中多层压缩也可以正常识别处理?
    按理说WAF的规则数量应该不会太大,你们大概有多少条? 与AV的signature数量相比应该是相差几个数量级,如果设计得好的话,不应该随特征上涨而导致太大的性能差别。

  152. aguai 于 2011-05-20 6:28 上午

    to tom,我们自己研发了web加速功能,gizp等压缩功能,SSL加速卡等,但是作用不大,真正的还在处理流上提升性能。
    to 百川,没法包装啊,咱去跟客户交流都是实打实的,加上我本人最讨厌啥专家专家的了,虽然我们也有一个,但是他自己本人也不喜欢。有空跟你请教下包装的事情,比如像某人在什么世界黑客大会演讲啥的,得学习下。
    to skybase 正如您说的确实是负载的,多少层压缩都可以处理,我们是规则集,具体多少条可没法数,当然没有AV的那么多,但是我们特有的针对webshell检测,阻断这块,就我电脑上的webshell样本就上万个,这个也是需要定位特征码的,如果不加上webshell检测的话,那么规则负载跟不负载的性能情况,都相差不大。
    另外,谢谢各位的关注和支持。真心感谢。

  153. old_peter 于 2011-05-20 8:43 下午

    楼上的,黑帽子大会演讲一下啥的,也不是那么特别容易的。还是有点料的。我支持你们也去演讲。说实话这种东西对于忽悠国内的很多客户还是有点用处的。

  154. 有点疑问 于 2011-05-21 1:33 上午

    1)如果按照aguai的解释,你们的tcp吞吐是裸奔转发吞吐,这种情况下如果是10G,那么http规则全开的吞吐理论上是做不到8G的,解码和匹配工作太多了。不知道这个的测试条件是什么(http 协议版本,页面大小,是否持续链接等),用哪种测试仪表?
    2)对于其中的并发,个人觉得转发并发是没意义的,你是专注于http的设备,公布你的http并发比较有说服力。
    3) 新建这个数据,就更让我觉得有点不能理解,你确实是用测试仪的数据吗? 这里Juniper的人不少,麻烦大家说确认一下顶级防火墙的新建速率的数量级,我记得也就是double一下aguai这个数据。

  155. aguai 于 2011-05-21 2:48 上午

    to old_peter 咱可没这个闲情去演讲,浪费这个时间去忽悠,还不如多花点时间钻研技术,提高产品质量。
    to 有点疑问,WAF这个东西其实跟TCP没任何关系,主要还是您说的看HTTP的新建速率,咱是实在的人,我们没有任何测试仪表,没这个钱去买,也没必要,自己测的是用微软的WATS测的,送过一台设备给弯曲的朋友,用某中外合资的安全实验室测的,性能跟我们标示出来的一样。如果有juniper的哥们要真正的确定我这个数据是否真的有假,可以跟我联系,我发设备给你们测试。还有些哥们说过,实验室产品要到真实客户上测试才能体现,那么公司成立到现在,我们设备从来没有搞挂过客户的网络,设备也没挂过,国内的WAF产品,自己扪心自问,是不是都挂过。

  156. multithreaded 于 2011-05-21 8:34 上午

    〉最大并发连接800万那个是旧了产品了,现在最新的是这个:
    HTTP请求速率320000,并发TCP连接数1000万,最大网络总吞吐量10Gbps,清洗流量8Gbps

    这些都不重要。能否讲一下:
    1。 TCP 同时活跃的数量?
    2。 平均包长 或者速度用MPPS来衡量。

  157. metal1011 于 2011-05-21 8:45 上午

    把WEB的TCP加速 流控 负载 和安全 搞到一起 做成一个整套的东西 像路由交换那样的基础设施

  158. g 于 2011-05-22 1:59 上午

    to aguai: HTTP请求速度是在一个TCP session里的吗?

  159. 111 于 2011-05-22 2:28 上午

    waf很多也是旁路很多也有asic加速

  160. skybase 于 2011-05-22 7:01 下午
  161. aguai 于 2011-05-22 7:18 下午
  162. aguai 于 2011-05-22 7:24 下午

    to g HTTP请求速度是在一个TCP session里的吗?
    回答:是的。

  163. multithreaded 于 2011-05-24 4:29 下午

    http://www.nshield.org/

    请你们的老总看一下,这里面的 HTTP Vulnerability Signature 是否能处理?

  164. aguai 于 2011-05-25 10:16 下午

    to multithreaded
    看了一下,个人感觉是翻译了snort的规则,没什么价值,这个规则大部分都是针对ids§ips的,每条规则针对的内容过于单一,通用性不好。还不如我们通过10多年的web安全经验和7千多台服务器实战,测试出来的规则好。

  165. multithreaded 于 2011-05-26 7:10 上午

    你丫很,枪毙了一篇SIGCOMM’10文章 :-(

    他们的idea是: 正规表达式无法描述多字段的规则,比如:

    if (protocol==http) && (method==POST) && (URL_has_file_name==header.php) then …

    来点真的把,你们如何表示?

  166. kernelchina 于 2011-05-26 7:26 上午

    同问

  167. aguai 于 2011-05-26 10:26 下午

    to multithreaded
    学术上的,没有实际应用,实际的测试和众多用户的使用,他就是纸上谈兵。
    if (protocol==http) && (method==POST) && (URL_has_file_name==header.php) then …
    这个可以看出,他是同时匹配protocol、method、URL_has_file_name三个东西,理念确实不错,但是像上面这三个再程序中判断就可以了,我上面说的意思是,他的规则内容没啥价值,防的都是一些垃圾漏洞,而铱迅的是高精确性,通用性的防护。

  168. 老韩 于 2011-05-27 12:26 上午

    发案例在媒体本身就要小心谨慎,发在弯曲更要慎之又慎。粗略地讲,会被扒光,用户大多也不满意;细致地讲,很多事怕是讲不清楚,用户恐怕也更不满意。aguai兄,以后多注意。(代表用户惩罚你)

  169. aguai 于 2011-05-27 12:36 上午

    受教了.真诚的致歉.希望能原谅一个口无遮拦的年轻人.

  170. ll 于 2011-05-27 1:50 上午

    从产品DEMO上看这个产品界面也没有什么太多优势功能.

    策略配置比较简单,完成依赖特征库被动防御.

    主动的HTTP协议过滤功能基本没有.

    如果产品采用透明或路由部署方式则性能应该会很高(和IPS产品性能应该没有区别)

    目前主流的WAF应该是采用透明代理的接入方式,将HTTP请求数据完成解析,过滤违规请求,这种部署方式性能就会下降..

    :) 又胡说了,欢迎拍砖!!

  171. multithreaded 于 2011-05-27 7:29 上午

    #167, 发这个贴子,你们的CTO看过吗? 呵呵,无知者无畏也 :-(

    看样子,你没有看懂人家讲得state-less streaming analysis.

  172. ganggang 于 2011-05-29 4:15 上午

    呵呵,还是multithreaded说的好, 无知者无畏也

    啊乖竟然说WAF和TCP没任何关系,管中窥豹,那基本就不需要再讨论下去了。

    个人经验,非代理的WAF,似乎在处理HTTP 1.1的keep alive的HTTP请求时会有些问题。

    从我个人到DEMO里去体验的感觉,确实和前面 LL 同学的感觉差不多。

  173. aguai 于 2011-05-29 6:09 下午

    to LL
    规则库是“集”而不是条,这可要看清楚。透明的处理数据包确实会降低性能,那是没解决性能瓶颈而已,铱迅的WAF可以透明的处理30M的HTTP包。您怎么看?
    to multithreaded
    他们没看,我只代表我自己的观点,本人确实无知,您跟我讨论渗透还行,研发不在行。多多指教啊。
    to ganggang
    我说的意思是WAF的性能是看http新建连接速率,而不是看TCP。可能是我的表达有问题。个人经验,非代理的WAF,似乎在处理HTTP 1.1的keep alive的HTTP请求时会有些问题。有啥问题?欢迎指教。

  174. willchen 于 2011-05-29 6:49 下午

    我有几个很浅薄的问题想请教一下各位专家:WAF相对所谓的下一代防火墙或者说应用层防火墙到底有啥区别?其核心不都是基于深度的内容检测么?是不是只是针对WEB应用做的更完整一些?
    我总觉得现在的网关安全设备无外乎还是基于“包”这个最小单位。只不过把这个东西捏来揉去,变幻出不同花样而已。不知道这种看法是否正确?

  175. ll 于 2011-05-29 6:51 下午

    to aguai

    我说的是”透明代理”方式会降低性能,,而不是透明方式..

    30M的HTTP包括哪些内容?

    规则库是”集”和”条”,本质没有太大的区别,大家都可以说是集而不是条,,个人认为完全依赖规则库来保护Web服务器安全,本身就会有问题..

    HTTP服务器的安全关键在于HTTP请求过滤,通过过滤HTTP请求来规范访问者的请求行为,实现Web服务器的安全访问.

    通过WAF来实现修复代码漏洞的目的

  176. Panabit 于 2011-05-29 6:54 下午

    “30M的HTTP包”,是30Mpps吗?

  177. aguai 于 2011-05-29 9:28 下午

    to Panabit 大牛
    是的。

  178. Panabit 于 2011-05-29 9:42 下午

    是基于X86,还是有专用的硬件?如果是X86,是什么配置?

  179. Panabit 于 2011-05-29 9:55 下午

    30M的HTTP包,按照最小包(14 + 20 + 20 + “GET / HTTP/1.1\r\nHost: x\r\n\r\n) = 71 bytes。30Mpps,肯定要超过20Gbps了。另外,71bytes在非CAVIUM架构下,最少需要touch 2个cache line,你们用的是什么硬件,说出来让大家探讨一下。

  180. tom 于 2011-05-29 10:03 下午

    aguai,30M的pps,你确信没搞错?

  181. ll 于 2011-05-29 10:33 下午

    呵呵,学习ING!!!!

  182. aguai 于 2011-05-30 2:38 上午

    没有搞错,出厂默认是10M,但是可以自己设定值,当然这个值越高处理性能就会相应降低。有些东西你不行不代表别人不行。

  183. 公道人士 于 2011-05-30 4:21 上午

    说句公道话吧,首先感谢aguai送台设备给我们测试,上面LL说功能没有优势,依循的URL自学习功能,国内厂商也只有他们有,这不是优势是什么?依循的WAF确实做得不错,性能高得不用说,不测不知道!很难得国内居然有这么牛的公司,而且还在南京,佩服!另外替aguai回答下!他们架构也是X86的!

  184. Panabit 于 2011-05-30 4:30 上午

    aguai,你182帖子是指? 你这个30Mpps的X86硬件是什么配置?

  185. Panabit 于 2011-05-30 4:36 上午

    “出厂默认是10M,但是可以自己设定值,当然这个值越高处理性能就会相应降低”。“默认是10M”,这个10M是指10Mpps吗?“当然这个值越高处理性能就会相应降低”,这个又作何解释?

  186. 老韩 于 2011-05-30 8:41 上午

    我也被搞糊涂了……

  187. Multithreaded 于 2011-05-30 1:28 下午

    》接156:
    》现在最新的是这个:HTTP请求速率320,000,并发TCP连接数1000万,最大网络总吞吐量10Gbps,清洗流量8Gbps

    根据以上陈述, 我认为30MMPS是不可能的。

    我们先把输入搞清楚!

    1. 系统带1个10G口,假定用了Intel 82599的一个口,最小包(64 + 20(gap))时最大速率是14.8MPPS, 离30MPPS差的老远的那!

    2。按照10M的TCP flows, 每个TCB一般来说要512B, 少算一点, 256B, 光TCP就需要2。56GB内存。这远远大于X86上的LLC 24MB,cache-miss-rate应该是很高的。 估计同时活跃的TCP flows 也就几十万条,这跟HTTP请求速率320,000是吻合的。

    老韩如果有空,以每秒256K的TCP flows的syn attack测一下, 看看系统的反应。 如果能抗得住,就是很好的系统了!

  188. ll 于 2011-05-30 6:55 下午

    URL自学习这个功能,国内厂商是大多数都不具备此功能,国外的WAF具有安全模型功能说的就是这个功能..

    但从用户实用的角度来争析,这个功能使用中会有很多问题:

    1.静态页面学习了也没意义.
    2.动态页面因为存在不断更新,这个学习功能使用会比较麻烦.
    3.URL学习到什么程序,只到页面文件级还是到动态参数级,请说明一下.

  189. ll 于 2011-05-30 6:57 下午

    TO Multithreaded

    这个问题分析得太专业了,,我们都是等着更专业的解释..

  190. Panabit 于 2011-05-30 8:00 下午

    To aguai: “HTTP请求速率320,000″,这个是每秒可以同时处理的HTTP请求数,还是等同连接新建速率?

  191. 老韩 于 2011-05-31 1:10 上午

    TO 187:我目前还没见过他们的产品。

  192. aguai 于 2011-05-31 1:27 上午

    to All
    感谢大伙对我们的东西那么关注,倍感荣幸。至于性能上的一些技术手段,我本人可没有Multithreaded这哥们那么专业,没有干货啊。LL哥们说的动态建模,这个可以参照imperva的,用过他们设备你就知道了。最后是panabit大牛了,320000这个是连接新建速率,新建的一般是折半。好了,我听老韩的慎之慎之。

  193. tom 于 2011-05-31 2:11 上午

    aguai应该正面回答Multithreaded 的推测,是不是你们不仅仅有一个10G口?14.8Mpps X 2 =30M?不靠加速卡,但靠x86真能这么强悍?

  194. ttt 于 2011-05-31 5:35 上午

    aguai的数据直接吧panabit秒杀了。 panabit兄费那劲coding出来,还不如aguai一张嘴。

  195. kernelchina 于 2011-05-31 6:10 上午

    320000CPS,这个数字也是非常牛,不知道policy是怎么样的。

  196. 天外有天 于 2011-05-31 6:49 上午

    肯定用什么加速卡了,不一定是X86吧,如果是X86那么panabit兄不气死啊,光靠一张嘴可不行,来点干货,不过人家有商业机密也不好说,aguai你还是悠着点吧。弯曲可都是牛人。。。。。。。。。

  197. Panabit 于 2011-05-31 7:06 上午

    Aguai,“出厂默认是10M,但是可以自己设定值,当然这个值越高处理性能就会相应降低”。“默认是10M”,这个10M是指10Mpps吗?“当然这个值越高处理性能就会相应降低”,这个我想破脑袋,也没想明白,能否指明一下?拜托,要不然我晚上睡不着觉。谢谢先!

  198. 有趣 于 2011-05-31 7:07 上午

    X86做到30Mpps没见过,不过在城域网看过一个流控设备,放在BRAS和CR之间,是万兆链路,当时看的时候,下行9.4G,下行7G,做策略的情况下CPU是30%。

    据说网卡芯片是Intel 82598,操作系统是FreeBSD 7.0 AMD64,里面的CPU是什么型号就不知道了

  199. Panabit 于 2011-05-31 7:10 上午

    如果是30Mpps的性能,3200000的新建是小了,最少可以超过8000000。

  200. Panabit 于 2011-05-31 7:10 上午

    如果是30Mpps的性能,320,000的新建是小了,最少可以超过800,000。

  201. Panabit 于 2011-05-31 7:21 上午

    aguai,今天听一个朋友分析,说你可能将10M那个搞错了,你那个10M可能是指最多分析一条会话前10Mbytes,这样你说的“30M理论性能会下降”的说法就make sense了。是这样理解吗?

  202. kernelchina 于 2011-05-31 8:48 下午

    CPS对不同的系统,做的事情可能不太一样,800K这个数字,就目前来说,做firewall,绝对可以秒杀一大批高端产品。
    CPS考验的是first path的能力,诸如route/policy/session management等等。如果这个WAF是透明接入,而且是个透明代理,就创建一个tcp connection也需要花很多时间。一个10G的server,每秒新建连接,达到800K,不太可能吧。

  203. Panabit 于 2011-05-31 10:03 下午

    按照30Mpps的处理能力,800K只是0.8/30 = 0.026 = 2.6%。这个比例已经是相当的低了。作为一个透明的代理而言,其SLOW PATH的负担和传统的FW实际上差别不大。

  204. Panabit 于 2011-05-31 10:14 下午

    经过仔细思考,我个人认为aguai说的30M估计不是指pps,否则综合他的言论,实在没法理解其前后一致性。aguai,如果我说错了,恳请指正;若如我所述,望以后在弯曲发言时慎重一些(包括你说的交大的那番话,我刚好也和交大的几个老师有过交流)。X86硬件的性能没有最高,只有更高!我在这段时间测试中充分明白了这一点,所以X86潜力极大,继续“给力吧,X86“。:)

  205. tom 于 2011-05-31 11:07 下午

    to 198楼:X86 10G的串在骨干上,我所知道的是用了加速的,而且现在运营商业逐渐接受了这种串接,冗余做的不错,实在不行了就直通
    aguai 童鞋,你在干什么呢?你的30M,让俺的小心脏扑腾了好几天

  206. 根本不相干 于 2011-06-01 7:44 上午

    我也认为30M不应该是PPS。web安全性能谈packet级别的PPS毫无意义。

    如果是谈攻击性的短HTTP链接,看CPU处理能力,HTTP新建数目是最好的表达。

    如果是谈长的活动流,看IO能力,那都是大包来着,PPS更没有意义

  207. tom 于 2011-06-03 1:51 上午

    aguai,组织考验你的时候到了,快出来坦白吧

  208. aguai 于 2011-06-03 10:29 上午

    进场了,没法上网,我的表述有问题,是30M的组包能力,而不是30Mpps,大家都知道我们是做全组包的,这下大伙应该都明白了吧,完全是我个人的原因,说话直来直去,没考虑弯曲牛人众多,大伙误解了,“根本不相干”这个哥们说对了。给大伙带来不便恳请见谅,大家多讨论,这样技术才能进步,在大伙的评论中俺也学到不少东西,非常感谢大伙,感谢大伙的关注。如果哪里做得,说得不对的地方恳请指出,我好改正,俺一直相信只有通过不断的讨论辩论才能出真知。做产品如此,做人亦如此。

  209. g 于 2011-06-04 7:59 下午

    agui:
    我前面的问题没问清楚。HTTP新建的测试结果要看测试方法,有很多种(WAF功能开启情况下),
    1)Tcp dst port 80,建立连接后Reset
    2)Tcp dst port 80,建立连接后两边Fin
    3)在1)的基础上GET并得到一个短响应负载
    4) 在2)的基础上GET并得到一个短响应负载
    5) 在一个或少数几个TCP连接里,反复GET…response…
    这个3200000是上述中的哪个?

  210. aguai 于 2011-06-05 7:57 下午

    to g
    是按照您的方法3)“在1)的基础上GET并得到一个短响应负载”测出来的。我们也用过您说的方法5)测试过,方法5测试出来的性能还要高很多,具体我记不得了。对于您所说的2和4的情况,建立连接后两边Fin断开连接的效率不如Reset的效率高。这个我们reset测试过的。

  211. test3 于 2011-10-20 9:19 下午
  212. 匿名 于 2012-06-14 4:04 下午

    https怎么办,没有 cavecreek 加速恐怕不行

  213. 网络迷途少年 于 2012-07-24 5:46 下午

    To 34
    你说的是杭州安恒吧,呵呵

  214. 理客 于 2012-07-27 8:15 下午

    一边是open和free让你native,一边是security和encrpytion保护privacy,internet的江湖一样是黑白红道各个老大多股势力博弈的江湖。

  215. 城管局 于 2012-10-26 2:54 上午

    to Unkown:
    分片重组,重点在重叠的处理方式 ~~
    snort 实现了target-based 的重叠处理,不同OS的协议栈(不管是ip碎片,还是tcp碎片)在重组碎片的时候,对重叠区域的取舍不一样,简单说,就是出现重叠了,是要取先到的数据还是后到的数据。作为一个安全设备,如果是实现一种,那么重组这块就可以绕过。
    然而要绕过有一个前提,就是攻击者要能控制碎片到达检测设备和目标机器的顺序,而这点是非常困难的,所以,感觉snort的target-based 其实起不了什么作用?
    不知道有哪位高人研究过这个问题