网关(HTTP防病毒网关（包括UTM）存在的问题)

收藏HTTP反病毒网关(包括UTM )存在的两个问题2012-11-12 12:42:病毒检测机制：29病毒是代码，最终形式是文件。 要被防病毒扫描引擎检测到，必须将internet上分发的数据流重新配置为文件。 我们浏览网页时，实际上用http协议获取很多html文件、gif图标和脚本文件，最终到达用户的是文件。 杀毒产品要实现http的病毒过滤，必须将http流量的数据重组为文件。 这意味着OSI7层恢复。 为此，目前所有解决方案都使用proxy技术。 无论是自代理方法还是icap方法，当用户提交浏览某个页面的请求时，网关防病毒设备都会首先下载此页面上的所有页面文件和gif，扫描后传递给用户。 我们希望表明，以proxy方式将http流量恢复到文件是一个单独的过程，对该文件进行病毒扫描是另一个过程，这两个过程可以分开进行。 第一个问题是，基于LAN的企业用户不希望在IE浏览器中安装代理以进行http病毒扫描，并且安装代理后，许多不支持代理的APP应用程序无法运行要实现http的病毒扫描，必须对用户透明。 第二个问题直接反映了进入http病毒扫描后，用户会感到非常严重的延迟。 通常，我们可以容忍的页面延迟不超过5秒，http timeout的默认时间为60秒。 还是30秒？ 请参阅。 计算一下进入http扫描后的理论延迟。 假设一家公司的互联网出口为10Mb，理论下载速度为1MB/S以上，则必须考虑通信与互联网的互联，以及网站的限速等其他因素的影响，一般从随机网站的单线下载为100 kb 根据前面介绍的病毒扫描方法，网关防病毒设备必须下载并扫描此文件，然后将其传递给用户。 不考虑ttl延迟。 访问页面上的小gif等几k文件的延迟小于1S，但如果在下载修补程序或文件时文件为10MB，怎么办？ 理论上，10MB的文件以100KB/S秒的速度下载100S，然后对10MB的文件进行病毒扫描。 其中一定需要解冻、代码匹配等扫描时间。 100S相对于http为timeout。 也就是说，连接中断了。 面对这种情况，杀毒厂商提出的折中解决方法是增加病毒扫描文件的大小限制，扫描大文件直接通过，小文件有意义。 不可否认，这确实是个好办法。 可以消除病毒扫描延迟，但无法解决通过代理获取文件的冲突。 此外，在多线程http中下载文件的工具在此代理模式下不可用或不可用。 针对这种代理问题，代理制造商提供了一种新的解决方案：代理在为用户下载文件时持续向用户发送保持连接的分组，从而防止用户的http连接断开这是所有代理面临的问题，这样的解决方案表面上避免了矛盾。 第三个问题看起来很难克服。 随着互联网技术的发展，多协议的APP应用软件越来越多，特别是IM程序可以通过http进行连接和通信，以确保强大的通用性和网络连接性能。 这导致许多msn的聊天数据。 由于使用的是http协议，因此它将被转发到代理并由病毒网关扫描。 不仅msn不可用或无法顺利使用，而且病毒网关的负担也很大。 另外，在当前网络病毒的横行中，很多病毒僵尸在局域网内持续发送大量对外散射的连接请求。 大多数使用的正是80端口访问请求，代理和病毒网关对大量的、对外不存在的地址的80请求不可忽视。 但是，即使花费大量资源来满足这些不存在的要求，也没有任何效果，网络病毒的网络层攻击无法恢复到文件中。 面对这个网关http病毒扫描对此无能为力的突出矛盾，我们能想到什么对策？ 在http通信通过代理并通过防病毒网关之前，它首先在能够检测到网络层网络病毒攻击的设备上过滤一次，drop掉大量异常的http请求，然后是的，这样可以解决所有这些问题，但我们用了多少设备和资金？ 有可以检测网络病毒的设备，http代理网关要做什么？ 即使http页面包含恶意代码，也可以完全检测到客户端上安装的防病毒客户端，或者在黑白列表中阻止不良站点，从而大大降低访问http的风险。 如果将大量资源用于效率非常低的http病毒扫描，几千年来很难检测到一些java病毒，但会大大降低内部员工的工作效率，毫无价值。