CheckPoint防火墙状态表.doc

《CheckPoint防火墙状态表.doc》由会员分享，可在线阅读，更多相关《CheckPoint防火墙状态表.doc（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、了解Check Point FW-1状态表 Lance Spitzner ()整理：warning3 (warning3nsfocus.)主页：.nsfocus.日期：2000-08-15 B#系统A联往系统B现在，系统B可以发送任意的包给系统A,只要IP和端口匹配(例如，那些属于这个连接会话的包).然而，如果系统试图发送SYN包建立一个新的连接，即使它使用与已存在的那个连接同样的端口，防火墙仍然会认为这个SYN包是一个新会话的一部分，将它与规则集进行比较。就我的观点来说，这是件好事。在上面的例子中，如果我们只允许来自外部系统A的连接，不允许从部的系统B发往外部的连接。那么系统B与系统A联系的

2、唯一方式就是作为一个已建立的连接的一部分来进行。当系统A连往系统B时，这个连接被加入到防火墙连接检查表中，现在系统B可以发送应答包给系统A了。然而，系统B并不能向A发送任何的SYN包来新建连接，即使IP和端口号是相同的。当防火墙看到SYN包时，它将这个包与规则集进行比较。在上面所说的条件下，这个包将被丢弃，虽然已经存在一个端口和IP都相同的连接。Fastpath: 我学到的另外一些东西就是，如果fastpath被使用，那么TCP回话不会被加入到过程连接表中。这是因为Fastpath仅仅检查SYN包，所以不需要将连接会话增加到连接表中。如果一个包中设置了其它的标志，缺省情况下这个包就不会被过滤而

3、是让其通过了。通常fastpatch用来改进性能。它的思路是：如果一个包没有设置SYN标志，那么它肯定是一个已经建立的连接的一部分，因为只有SYN包才能开始一个连接。既然只检查SYN包，所以性能肯定会大大提高。然而，使用faspatch通常并不是一个好的做法，因为这可能让你暴露在多种攻击方式之下。Fastpath在FW-1 v3.0中存在，并且只能对所有的TCP包同时起作用。在v4.0中，它又被叫做Fastmode,可以有选择的对不同的TCP服务实施。关闭一个连接=根据初步的测试结果，FW-1通过设置连接超时时间来关闭连接。当检查模块看到一个连接会话开始交换FIN或者RST包时，它就将超时时间

4、从3600秒改为50秒。如果50秒没有其它的包发送，连接就被从状态表中删除。如果在超时时间段又有其它的包发送，那么超时时间会再被设置成50秒.这可以阻止别人通过发送假的RST或者FIN包来进行拒绝服务攻击。在关闭TCP连接会话时，在应答了第二个FIN包后进入的TIME_WAIT状态与这种超时有点类似。UDP=维护UDP状态更简单，因为它们是无连接的。当过滤规则允许一个UDP包通过防火墙时，这个连接就被增加到连接表中。在超时时间段(缺省是40秒),只要源/目的地址和端口匹配的UDP包都允许通过。例如，下面是一个DNS请求：Src_IPSrc_Prt Dst_IPDst_Prt IP_prot K

5、bufTypeFlagsTimeout192.168.1.101111136.1.1.205317016386ff01ff0034/40192.168.1.101111136.1.1.20017016386ff01ff0034/40你能看到，系统192.168.1.10正在向136.1.1.20做DSN查询。40秒，那个系统可以返回任意多的UDP包(只要源/目的地址和端口匹配).注意这里有两个表项，区别是目的端口不同，一个是53,另一个是0.我不知道为什么FW-1会创建那个目的端口为0的表项。如果不是过滤所有的UDP数据传输，这种情况很常见。ICMP=FW-1对ICMP的处理很令人失望。缺省情

6、况下，FW-1不对ICMP进行状态检查。它永远不会被放到状态连接表中。因此，用户被迫盲目地允许特定的ICMP传输(例如入站ECHO_REPLIES）或者不得不自己修改检查代码(.phoneboy./fw1).我认为这是FW-1最大的不足。报文分组=最近我一直在看报文分组，特别是FW-1如何处理分组报文。尽管报文分组并没有直接应用到状态表中，但我认为它也很重要，值得加入到这篇文章中。我不会详细地将报文分组的原理，我假设读者已经具备了IP报文分组的基本知识。我首先会大体上讲一下FW-1是如何处理报文分组的，然后我会再针对TCP,UDP,ICMP协议讲一下。首先，FW-1将接收到的分组报文再发出去。

7、就是说如果FW-1收到一个分组的报文，过滤规则也允许它通过的话，它会将这个分组再转发出去。但是，我认为FW-1在检查分组的报文之前肯定进行了某种形式的报文重组。这个结论是在下列测试的基础上得出的。当我用一个完整的分组报文发起TCP连接的时候，报文被防火墙接受并加入到了状态表中，然后再以分组的形式发送给目的主机。现在我的状态表里有了一个会话表项，然后我试图发送更多的分组报文,它们属于同一个连接会话，这些报文也被接受，超时时间被重置。然而，如果我发送一个不完整的TCP分组(也属于同一个连接会话)，这个分组就不被接受，而且它也不会被记录。这让我相信当FW-1第一次收到一个分组报文时，它并不进行规则检

8、查，而是要等到所有的分组均被收到并且完成报文重组后，才进行规则检查。一旦重组完成，防火墙才开始决定如何处理这个报文，是接受还是丢弃，记录等等。另一个例子是使用jolt2，它是一个用来攻击Window系统的工具。它发送100个不完整的ICMP或者UDP分组给选定的目标主机。当用来攻击Fw-1后面的主机时,这些包不会通过防火墙，也不会被防火墙所记录。我认为这是由于这些ICMP分组是不完整的，它们不能被重组为一个完整的ICMP报文，因此也就不会被检查和记录。事实上，对于一个包含状态检查的防火墙，常常要进行某种形式的报文重组。很多检查连接状态防的火墙(包括FW-1)检查包都是基于源/目的地址和源/目的

9、端口的(TCP头).然而，对于分组报文，只有第一个分组包含这些信息，所有其它的分组都只有IP地址信息。如果不进行某种形式的报文重组，防火墙就不能确定后续分组是属于哪个连接会话的（除了第一个分组).通过对分组报文进行重组，防火墙就可以确定这些分组到底是属于哪个连接会话的。然而，在重组之前不进行报文检查也有一个问题，防火墙就可能遭受不完整或者是非法的分组报文的攻击.既然这些报文是不完整的或者非法的，就不可能被正确重组，它们也不会被检查和记录。所以，防火墙会继续接收这样的包并尝试重组它们，尽管重组是不可能的。因此处理大量的这样的分组将占用系统资源，导致拒绝服务攻击。这种攻击不能通过设置防火墙过滤规则

10、来防止，也不会被记录。为了得到这个漏洞更为详尽的消息，可以看CheckPoint的安全公告(.checkpoint./techsupport/alerts/ipfrag_dos.html).如果你是Unix用户，可以在命令行用fw ctl pstat来看你的防火墙处理了多少分组。到phoneboy 可以得到更多的相关资料。下面我们来看看特定的协议。首先，来看TCP.对于数据长度少于24字节的分组报文，FW-1将会丢弃其第一个分组，并且记录下这个报文:TCP packet too short.(注意：记住，这里我们讨论的数据长度不包括20字节的IP头).例如，用网络扫描工具namp的-f选项将会

11、产生一个分组报文，第一个分组数据长度为16个字节，第二个分组为8字节，因此缺省这些分组检测会被FW-1丢弃（不管你的过滤规则如何设置)并被记录。ICMP和UDP则又有不同。首先，标准的分组长度(8,16,32字节等等)都是可以的(不象TCP,要求至少24字节).然而，奇数字节的分组大小是不允许的(这里的奇数是指不是8字节的整数倍)。例如,试图发送一个数据长度为12字节的分组，这就不会被接受，也不会被记录。这些看法都是基于我个人的研究，并不是所谓官方资料。如果你发现我的逻辑，测试方法或者使用的技术有任何问题，请提醒我！附录：测试使用的工具：fwtable.pl可以帮你更好的理解Check Point FW-1的状态检查表。hping2允许你自己构造TCP/ICMP/UDP包Nemesis与hping2类似，也有自己一些不同的功能。使用libpcap和libnet.它允许你自己构造各种类型的报文，包括TCP,UDP,ICMP,DNS,OSPF等等libnet它封装了一些网络函数.9 / 9