防火墙状态检测工作机制

一、状态监测应该如何工作

    无论何时，一个防火墙接收到一个初始化TCP连接的SYN包，这个带有SYN的数据包被防火墙的规则库检查。该包在规则库里依次序比较。如果在检查了所有的规则后，该包都没有被接受，那么拒绝该次连接。一个RST的数据包发送到远端的机器。如果该包被接受，那么本次会话被记录到状态监测表里。该表是位于内核模式中的。随后的数据包(没有带有一个SYN标志)就和该状态监测表的内容进行比较。如果会话是在状态表内，而且该数据包是会话的一部分，该数据包被接受。如果不是会话的一部分，该数据包被丢弃。这种方式提高了系统的性能，因为每一个数据包不是和规则库比较，而是和状态监测表比较。只有在SYN的数据包到来时才和规则库比较。所有的数据包与状态检测表的比较都在内核模式下进行所以应该很快。



二、状态监测表建立？

    那么初始化一个连接时使用ACK行不行？它又会出现什么问题呢？

    如果防火墙的状态检测表使用ACK来建立会话，将会是不正确的。

    如果一个包不在状态检测表中时，那么该包使用规则库来检查，而不考虑它是否是SYN、ACK或其他的什么包。如果规则库通过了这个数据包，本次会话被添加状态检测表中。所有后续的包都会和状态检测表比较而被通过。因为在状态监测表中有入口，后续的数据包就没有进行规则检查。而且我们在做状态监测表项时，也需要考虑时间溢出的问题。使用这种方法，一些简单的DOS攻击将会非常有效地摧毁防火墙系统。

    那么状态检测表建立应该怎么进行呢？

    首先，对于一个会话我们使用什么来区分。从最简单的角度出发，我们可以使用源地址、目的地址和端口号来区分是否是一个会话。

    当通过使用一个SYN包来建立一个会话时，防火墙先将这个数据包和规则库进行比较。如果通过了这个数据连接请求，它被添加到状态检测表里。这时需要设置一个时间溢出值，参考CHECK-POINT FW-1的时间值，将其值设定为60秒。然后防火墙期待一个返回的确认连接的数据包，当接收到如此的包的时候，防火墙将连接的时间溢出值设定为3600秒。对于返回的连接请求的数据包的类型需要做出判断，已确认其含有SYN/ACK标志。（注：对于时间溢出值，应该可以由用户自行设定。）

在进行状态监测时，对于一个会话的确认可以只通过使用源地址、目的地址和端口号来区分，在性能设计上如果能满足要求，也应该考虑对于TCP连接的序列号的维护，虽然这样可能需要消耗比较多的资源

            

三、连接的关闭

    在连接被通讯双方关闭后，状态监测表中的连接应该被维护一段时间。

    下面的处理方法可以作为在连接关闭后状态检测行为的参考。

    当状态监测模块监测到一个FIN或一个RST包的时候，减少时间溢出值从我们缺省设定的值3600秒减少到50秒。如果在这个周期内没有数据包交换，这个状态检测表项将会被删除，如果有数据包交换，这个周期会被重新设置到50秒。如果继续通讯，这个连接状态会被继续地以50秒的周期维持下去。这种设计方式可以避免一些DOS攻击，例如，一些人有意地发送一些FIN或RST包来试图阻断这些连接。



四、UDP的连接维护

    虽然UDP连接是无状态的，但是仍然可以用类似的方法来维护这些连接。当一个完成规则检查的数据包通过防火墙时，这次会话被添加到状态检测表内，并设置一个时间溢出值，任何一个在这个时间值内返回的包都会被允许通过，当然它的SRC/DST的IP地址和SRC/DST的端口号是必须匹配的。



五、ICMP的状态检测问题

    对于一些ICMP包的分析，在许多防火墙系统中都是做的很不够的，在对做状态检测时是需要对ICMP的内容进行分析的。对于什么样的ICMP可以发出和放入在状态监测模块中如何确定是关键。下面只是列出了什么样的ICMP包是安全的，可以作为对状态检测模块ICMP支持的参考。



#define ICMP_ECHOREPLY        0    /* Echo Reply            */



Needed if you want to allow ping, so you can allow that for trusted peers

outgoing and incoming for all to allow them to ping the internet



#define ICMP_DEST_UNREACH    3    /* Destination Unreachable    */



Some Sub Types are needed in and out, see below



#define ICMP_SOURCE_QUENCH    4    /* Source Quench        */



Allow it outbound anyway, inbound is less likely to be a problem, unless you

are doing some streaming or multicast feeding to the internet.



#define ICMP_REDIRECT        5    /* Redirect (change route)    */



block!



#define ICMP_ECHO        8    /* Echo Request            */



you might allow it incoming for trusted addresses (note some NICs will

require you to make your primary DNS Server pingable!)



#define ICMP_TIME_EXCEEDED    11    /* Time Exceeded        */



helpfull if you allow it incoming, could allow exploring your network if you

allow it outbound.



#define ICMP_PARAMETERPROB    12    /* Parameter Problem        */



helpfull if you allow it incoming, could allow exploring your network if you

allow it outbound.



#define ICMP_TIMESTAMP        13    /* Timestamp Request        */

#define ICMP_TIMESTAMPREPLY    14    /* Timestamp Reply        */

#define ICMP_INFO_REQUEST    15    /* Information Request        */

#define ICMP_INFO_REPLY        16    /* Information Reply        */

#define ICMP_ADDRESS        17    /* Address Mask Request        */

#define ICMP_ADDRESSREPLY    18    /* Address Mask Reply        */



Block those on the external interface





/* Codes for UNREACH. */

#define ICMP_NET_UNREACH    0    /* Network Unreachable        */



ignored, so block it



#define ICMP_HOST_UNREACH    1    /* Host Unreachable        */



allow it at least inbound, best would be if you can do that stateful



#define ICMP_PROT_UNREACH    2    /* Protocol Unreachable        */



you can block that



#define ICMP_PORT_UNREACH    3    /* Port Unreachable        */



you should allow that at least inbound. Be aware that some filter rules

should send PORT_UNREACH on connection request (at least 137,139 and auth),

so make sure not to block those ICMP packetes which are generated by your

reject rule.



#define ICMP_FRAG_NEEDED    4    /* Fragmentation Needed/DF set    */



Allow it in, and possible out if you have different MTUs inside your

network.



#define ICMP_SR_FAILED        5    /* Source Route failed        */



Not strictly needed. Nobody should asume SR works anywhere, anyway.



#define ICMP_NET_UNKNOWN    6



block, its ignored



#define ICMP_HOST_UNKNOWN    7



allow it at least inbound.



#define ICMP_HOST_ISOLATED    8



block.



#define ICMP_NET_ANO        9

#define ICMP_HOST_ANO        10



those are the new types returned by ipfilters. You may let them pass in and

out.



#define ICMP_NET_UNR_TOS    11

#define ICMP_HOST_UNR_TOS    12



block



#define ICMP_PKT_FILTERED    13    /* Packet filtered */



block, depricated



#define ICMP_PREC_VIOLATION    14    /* Precedence violation */

#define ICMP_PREC_CUTOFF    15    /* Precedence cut off */



block.



六、IP分帧的问题

    在路由时，如果IP数据包的内容大于MTU的大小，数据包将会被分帧，被分成几个更小的IP数据包。虽然分帧没有直接地应用于状态检测表，但是它仍然是非常重要的。

    那么是否在截获数据包后，发向系统的TCP/IP协议站之前，对收到的分帧后的数据包进行组装呢？

    在大多数情况下，作为一个状态检测防火墙，对于一些类型的分帧的IP数据包进行重组是需要的。防火墙都监测TCP的头部信息作为对一次会话的监测。然而，在所有被分帧后的IP数据包中只有第一个分帧包含了完整的信息，其他分帧只有IP地址信息。如果一些分帧没有被重组，那么状态监测模块将没有办法识别后续的分帧的数据包是否属于一个会话的一部分。通过重组，防火墙的状态检测模块就能识别整个的被分帧的数据包。

    然而，如果是重组完成后才对数据包进行检查，那么防火墙对于使用分帧攻击（使用不完整的或者是非法的）就表现出很大的弱点。因为它们可能根本不会被重组完成。当然它们也不会被日志记录下来。防火墙系统很快就会由于试图继续重组这些根本不可能完成的数据包，而将系统的资源耗尽。那么对于如果需要实现分帧重组，那就必须采用十分好的重组方式。对于具体应用来说，过小的分帧包应该被丢弃。