应用状态防火墙技术介绍

前面讲到了包过滤防火墙的一些细节东西，大家可以发现我一直强调包过滤的核心在于ＡＣＬ，ＡＣＬ起源于防火墙的需要，但是应用远远不止于防火墙。ＡＣＬ需要提前定义分类数据包，然后跟ｐａｃｋｅｔ filtering进行接口绑定然后对流经接口的数据包进行ＡＣＬ匹配，如果匹配便根据ｆｉｒｅｗａｌｌ定义的ｐｅｒｍｉｔ还是ｄｅｎｙ对数据包进行允许还是拒绝（丢弃）处理，如果不匹配ＡＣＬ那么就将数据包丢给全局防火墙默认策略处理，对于默认策略各家厂商定义不同，也可以自定义．

那么从包过滤技术的分析中大家可以看到，包过滤是静态的，静态的原因在于提前需要定义ＡＣＬ及策略，而且包过滤关注协议的ＩＰ层，也就是三层以下．这样来说她的处理就显的简单而单一．熟悉网络技术的人都知道，其实我们的业务应用更加复杂，除了复杂的协议状态机转换，许多的协议都是多通道的，这样来说这些状态及应用层信息一般来说都非静态的，会根据报文的交互进行状态机转换．所以包过滤将显的心有余而力不足．在这样的需求下基于应用状态的防火墙技术（ＡＳＰＦ）诞生了．

那么ＡＳＰＦ采用什么样的方式来处理数据包呢？首先ＡＳＰＦ所关心的对象已经发生变化，不再是ＩＰ包头，不再是单纯的五元组信息，而是关心技术ＩＰ层的连接的数据流信息，当然这个数据流信息包括如ＴＣＰ的三次握手建连接，四次握手终结连接的状态机ＦＳＭ变化，还包括应用层如ＦＴＰ协议的控制与数据通道的建立及解除等等．那么在这个过程中有这样几个问题需要注意：

１）ＡＳＰＦ关注数据流，那么如何识别一条数据流？

ＡＳＰＦ的处理一般是基于ｓｅｓｓｉｏｎ（会话）的，所有属于同一会话的所有数据包都被堪称一条流并统一对待．那么会话是一个什么的东西呢？会话一般包括如下这样信息：

协议 状态（老化时间） 源ＩＰ（源端口）－－＞目的ＩＰ（目的端口）

目的ＩＰ（目的端口）＜－－源ＩＰ（源端口）

如上所示一条会话是有如上七元组来标示的，如果一个数据包可以匹配会话的话就称为同一数据流．

２）如何确定一应用性连接的正确性？

所谓的状态防火墙就是对协议的状态进行动态监控，如果状态转化不符合协议定义，那么这样的报文将被ＤＲＯＰ掉．只有那些完全匹配符合协议状态机的报文将会呗正确投递到相应的模块进行处理．那么如何来确定一条应用性连接的正确性呢？答案就是状态转换表，也就是所谓的状态机（ＦＳＭ）．下面来举个例子说明：

ＴＣＰ的ＦＳＭ：

ＮＯＮＥ－－－＞ＳＹＮ＿ＳＥＮＴ，receiveｄ ＴＣＰ＿ＳＹＮ

ＴＣＰ＿ＳＥＮＴ－－－＞ＳＹＮ＿ＲＣＶ，receiveｄ ＴＣＰ＿ＳＹＮ＿ＡＣＫ

ＳＹＮ＿ＲＣＶ－－－＞ＥＳＴＡＢＬＩＳＨ，receiveｄ ＴＣＰ＿ＡＣＫ

ＥＳＴＡＢＬＩＳＨ－－－＞ＥＳＴＡＢＬＩＳＨ，receiveｄ ＴＣＰ＿ＡＣＫ

ＥＳＴＡＢＬＩＳＨ－－－＞ＴＩＮ＿ＷＡＩＴ，receiveｄ ＴＣＰ＿ＦＩＮ

ＦＩＮ＿ＷＡＩＴ－－－＞ＦＩＮ＿ＷＡＩＴ，receiveｄ ＴＣＰ＿ＡＣＫ

ＦＩＮ＿ＷＡＩＴ－－－＞ＦＩＮ＿ＷＡＩＴ，receiveｄ ＴＣＰ＿ＦＩＮ

ＦＩＮ＿ＷＡＩＴ－－－＞ＣＬＯＳＥＤ，receiveｄ ＴＣＰ＿ＡＣＫ

上面就详细的表述了ＴＣＰ的ＦＳＭ状态机转换及触发条件，会话会维护每种支持协议的状态机，ＡＳＰＦ会依赖会话管理模块进行状态动态监控以实现动态防火墙处理．还有一点需要注意的是，不同的系统可能对如ＵＤＰ，ＩＣＭＰ这样的无状态的协议的定义是不同的，处理上也有一些差异，在这里不再详细讲述，轻关注会话管理详细讲解．

３）如何检测应用层内容的合法性（如Ｊａｖａ ａｐｐｌｅｔｓ）？

ＡＳＰＦ还可以对应用层的报文的内容加以检测，如Ｊava ｂｌｏｃｋｉｎｇ等，对不信任站点的ｊａｖａ阻断功能，当然这方面的ＡＳＰＦ检测是有限的，对于应用层数据的合法性的检测更多的依赖ＷＥＢ过滤技术进行．Java Blocking是对通过HTTP协议传输的Java Applets程序进行阻断。当配置了Java Blocking后，用户为试图在Web页面中获取包含Java Applets程序而发送的请求指令将会被阻断。

４）如何保证传输层（应用层）数据通道的正确建立？

传输层协议检测一般指通用的ＴＣＰ／ＵＤＰ检测，与应用层数据不同，传输层协议检测主要关注传输层数据（插口地址）．对于ＡＳＰＦ要求返回ａｓｐｆ外部接口的报文要跟出ＡＳＰＦ接口报文完全匹配，也就是说五元组要完全匹配。否则返回的数据报文将被丢弃处理。

至此介绍了一些ＡＳＰＦ实现需要的一些概念，准备，那么下面将详细的介绍ＡＳＰＦ的细节．

（未完待续，尽请关注防火墙技术之－－状态防火墙２）