Comodo与卡巴试验的疑问

lapulas

上次发贴问问题，得到打磨师斑竹的热情回答，小弟非常谢谢。

我对比了卡巴和Comodo的包过滤规则默认设置，做了点小试验，发现Comodo只要是出站，然后得到响应的入站包它都认为是安全的，并允许通过？或者应用程序规则高于包过滤规则？

试验是这样的：
       在Comodo的包过滤规则里第一条是Allow TCP/UDP Out  any any 那表明TCP/UDP任何出站是允许的。我认为访问一个网站必然会得到入站的包吧？（这个观点对吧？）   在顶层加入规则Block IP In any any并且做记录，却仍然能访问网站。阻止的入站包没有记录。   但是在卡巴里这样设置的话会不断提示阻止了包进入，网站也无法访问，按道理讲应该阻止的啊！Comodo应用程序规则高于包过滤规则？

上次问到ICMP那个问题（我的帖子：Comodo的两个疑问）也是这样，Comodo对出站后得到的响应ICMP包不阻止，默认规则却是阻止的。但是卡巴默认允许ICMP0（ICMP0入站），一旦卡巴设置成Comodo默认的ICMP0入站阻止的话，ping外部就没有响应了。难道防火墙在包过滤规则制定上因防火墙运行机制而差异？

如果Comodo真的是应用程序规则高于包过滤规则，那Comodo的安全性不是大打折扣？ 其svchost.exe默认是全部允许，但卡巴不是的。

以上的疑问困饶了我好久，实在不知道为什么？？？？

星之梦

应用程序规则低于包过滤规则，不过只Block IP In 确实还能收包。
------------------------------
原来应用程序控制规则和网络控制规则平行的。

[ 本帖最后由 星之梦 于 2007-1-29 16:33 编辑 ]

ubuntu

我对比了卡巴和Comodo的包过滤规则默认设置，做了点小试验，发现Comodo只要是出站，然后得到响应的入站包它都认为是安全的，并允许通过？或者应用程序规则高于包过滤规则？

纯粹的包过滤问题，和应用程序规则没关系，Comodo 对出站连接的响应数据包是允许通过的，并且也是安全的。
全状态检测 (Stateful Packet Inspection SPI) 防火墙本来就是这样，没什么奇怪的。Comodo 完全实现了 TCP/UDP SPI , 和传统的包过滤防火墙当然有区别。

每个网络连接包括以下信息：源地址、目的地址、源端口和目的端口，叫作套接字对(socket pairs)；协议类型、连接状态(TCP协议)和超时时间等。防火墙把这些信息叫作状态(stateful)，能够检测每个连接状态的防火墙叫作状态包过滤防火墙。它除了能够完成简单包过滤防火墙的包过滤工作外，还在自己的内存中维护一个跟踪连接状态的表，比简单包过滤防火墙具有更大的安全性。

状态检测的工作机制，可以 Google 到，没必要多讲，简单介绍一下：
对于初始化 TCP 连接的数据包 (SYN Flags) ，先对静态规则表进行匹配，如果在检查了所有的规则后，该包都没有被接受，那么拒绝该次连接。如果该包被接受，那么本次会话被记录到状态检测表 (Stateful Table) 里。该表是位于内核模式中的。随后的数据包(没有带有一个SYN标志)就和该状态检测表的内容进行比较。如果会话是在状态表内，而且该数据包是会话的一部分，该数据包被接受。如果不是会话的一部分，该数据包被丢弃。这种方式提高了系统的性能，因为每一个数据包不是和规则库比较，而是和状态检测表比较。只有在SYN的数据包到来时才和规则库比较。所有的数据包与状态检测表的比较都在内核模式下进行所以应该很快。

试验是这样的：
       在Comodo的包过滤规则里第一条是Allow TCP/UDP Out  any any 那表明TCP/UDP任何出站是允许的。我认为访问一个网站必然会得到入站的包吧？（这个观点对吧？）   在顶层加入规则Block IP In any any并且做记录，却仍然能访问网站。阻止的入站包没有记录。   但是在卡巴里这样设置的话会不断提示阻止了包进入，网站也无法访问，按道理讲应该阻止的啊！Comodo应用程序规则高于包过滤规则？

实现 SPI 的防火墙，只是允许允许属于出站连接的返回数据包通过，而不会允许外部主动连接通过，这是两种类型的数据包。
在顶层加入规则Block IP In any any并且做记录，这条规则当然是起作用的，因为它阻止了入站连接。

那么为什么在顶层加入规则Block IP In any any 不阻止一个客户端连接的返回数据包，因为这样做不符合 SPI 防火墙的工作机制，我前面已经介绍过了。

当我们访问一个 Internet 上的网站，初始化连接的数据包通过 Allow TCP/UDP Out  any any 放行，然后在状态检测表 (Stateful Table)里添加这个会话连接，所有后续的包都会和状态检测表比较而被通过。因为在状态监测表中有入口，后续的数据包就没有进行规则检查。在顶层加入规则Block IP In any any，显然对于已建立的客户端连接是无效的，所有后续的包都会和状态检测表比较而被通过，当然不会有记录。

上次问到ICMP那个问题（我的帖子：Comodo的两个疑问）也是这样，Comodo对出站后得到的响应ICMP包不阻止，默认规则却是阻止的。但是卡巴默认允许ICMP0（ICMP0入站），一旦卡巴设置成Comodo默认的ICMP0入站阻止的话，ping外部就没有响应了。难道防火墙在包过滤规则制定上因防火墙运行机制而差异？

Comodo 没有实现 ICMP SPI，所以还不会对出站后得到的响应特定 ICMP 包不阻止，唯一的例外是 ICMP Ping的响应数据包 ICMP 0 是放行的，这有点 ICMP SPI 的意思。
对 KAH 这种没有 ICMP SPI 并且没有对 Ping 进行特殊处理的防火墙，阻止 ICMP 0 入站，也就是阻止了本机 Ping 外部。

如果Comodo真的是应用程序规则高于包过滤规则，那Comodo的安全性不是大打折扣？ 其svchost.exe默认是全部允许，但卡巴不是的。

svchost.exe 只要打开应用程序行为分析，没有什么安全问题。当然可以进一步收紧到只访问特定IP和端口。

最简单的理解，Comodo 分为应用程序防火墙和网络防火墙两层，规则在效力上都是平行的，没什么优先，一个程序要联网，必须通过所有的检测。
具体一点：
对于入站连接： Network Monitor -> Application Monitor -> Component Monitor/Application Behavior Analysis
对于出站连接： Application Monitor -> Component Monitor/Application Behavior Analysis -> Network Monitor

还有一点，程序规则只对应于特定的程序，网络规则是具有全局性的，所有程序适用。

嘿嘿，综上所述，Comodo 具有一个很棒的，超出一般人想象的，强大的数据包过滤引擎。

[ 本帖最后由 ubuntu 于 2007-1-29 09:42 编辑 ]

Oceanzd

光是ICMP0是不够的。。。Ping其它机器时请求回显需要ICMP8。。。

ubuntu

原帖由 jzhhh 于 2007-1-29 09:43 发表
光是ICMP0是不够的。。。Ping其它机器时请求回显需要ICMP8。。。

如果仔细看过他另一个帖子的问题，就会知道允许 ICMP 8 早就是个前提条件，我没有必要再写出来。
Ping 需要什么样的规则，对我来说是个小儿科的问题，在这上面我不会犯错误的。

原帖由 lapulas 于 2007-1-25 22:25 发表
另外在Comodo里禁止ICMP0允许ICMP8的话可以有效阻止ping入侵，但卡巴防火墙这样做的话ping入侵是阻止了，但ping出站却丢包严重，Comodo没有这样的问题。

星之梦

COMODO的状态检测厉害啊，又简化了规则、又避免了开放端口的危险。
学习了。

就算反弹木马通过了状态检测，还有Application Behavior Analysis 和Do Protocol Analysis。

DJ

太专业了,偶看不懂呀.

lapulas

打磨师版主真是厉害，小弟佩服万分，实在是感谢！！　呵呵

亮

在Comodo的包过滤规则里第一条是Allow TCP/UDP Out  any any 那表明TCP/UDP任何出站是允许的。我认为访问一个网站必然会得到入站的包吧？（这个观点对吧？）   在顶层加入规则Block IP In any any并且做记录，却仍然能访问网站。阻止的入站包没有记录                      我也有同感

伯夷叔齐

完全可以开三节课了.斑竹讲得好.