安全策略篇 ASPF：隐形通道

大家好，强叔又来了！经过前两期的介绍大家对安全策略应该比较了解了，本期强叔要给大家带来一个神秘人物。

在请出神秘人物之前，我们先来使用eNSP实战一把安全策略的配置。通过eNSP搭建如下环境，FTP客户端经过防火墙访问FTP服务器，安全策略怎么配置呢？

这还不容易，在Trust到Untrust配置安全策略，指定源/目的IP、指定协议为FTP不就好了。

然后我们看看FTP客户端能否成功访问？

咦？怎么看不到服务器文件，看日志信息发现用户认证已经通过了，但是数据连接建立失败。

再检查一下配置吧：

Trust和Untrust的域间缺省包过滤关闭，在Outbound方向配置了允许PC访问FTP服务器的一条安全策略。

查看会话表也成功建立了会话：

看起来应该没问题啊，不是说在首包的方向上应用安全策略，后续包直接匹配会话转发吗？

那我们分析一下FTP协议是否有什么特殊之处呢？

FTP协议是一个典型的多通道协议，在其工作过程中，FTP Client和FTP Server之间将会建立两条连接：控制连接和数据连接。控制连接用来传输FTP指令和参数，其中就包括建立数据连接所需要的信息；数据连接用来获取目录及传输数据。数据连接使用的端口号是在控制连接中临时协商的。

根据数据连接的发起方式FTP协议分为两种工作模式：主动模式（PORT模式）和被动模式（PASV模式）。主动模式中，FTP Server主动向FTP Client发起数据连接；被动模式中，FTP Server被动接收FTP Client发起的数据连接。

模式在一般的FTP客户端中都是可以设置的，这里我们以主动模式为例进行讲解，主动模式的协议交互流程如下：

首先FTP客户端向FTP服务器的21端口发起连接建立控制通道，然后通过PORT命令协商客户端使用的数据传输端口号。协商成功后，服务器主动向客户端的这个端口号发起数据连接。 而且每次数据传输都会协商不同的端口号。

而我们配置的安全策略仅开放了FTP协议，也就是21端口。当FTP客户端向服务器发起控制连接时建立了如下会话。

而服务器向客户端发起数据连接的源/目的端口号分别是20和临时协商的端口号yyyy，显然不是这条连接的后续报文，无法命中此会话转发。因此会出现可以验证用户密码，但是无法获取目录列表的现象。

有同学可能想到了，在服务器到客户端的方向也配置安全策略就行了吧？对，这是一种方法，但是这样必须开放客户端的所有端口有安全隐患。要是有一种方法可以自动记录数据连接就好了！

别急，万能的防火墙都能实现。这就是本期要出场的神秘人物ASPF（Application Specific Packet Filter）。ASPF是针对应用层的包过滤，其原理是检测通过设备的报文的应用层协议信息，记录临时协商的数据连接，使得某些在安全策略中没有明确定义要放行的报文也能够得到正常转发。

记录临时协商的数据连接的表项称为Server-map表¹，这相当于在防火墙上开通了“隐形通道”，使得像FTP这样的特殊应用的报文可以正常转发。当然这个通道不是随意开的，是防火墙分析了报文的应用层信息之后，提前预测到后面报文的行为方式，所以才打开了这样的一个通道。

1：Server-map表在防火墙转发中非常重要，不只是ASPF会生成，NAT Server、SLB等特性也会生成Server-map表，后续在其他帖子中强叔还会提及。

说了这么多ASPF怎么配置呢，很简单，在域间配置一条命令即可detect protocol。

FTP访问成功：

此时查看Server-map，可以看到已经自动生成了维护FTP数据连接的表项：

Server-map表中记录了FTP服务器向FTP客户端的2071端口号发起的数据连接，服务器向客户端发起数据连接时将匹配这个Server-map表转发，而无需再配置反向安全策略。

数据连接的第一个报文匹配Server-map表转发后，防火墙将生成这条数据连接的会话，该数据连接的后续报文匹配会话表转发，不再需要重新匹配Server-map表项。

Server-map表项由于一直没有报文匹配，经过一定老化时间后就会被删除。这种机制保证了Server-map表项这种较为宽松的通道能够及时被删除，保证了网络的安全性。当后续发起新的数据连接时会重新触发建立Server-map表项。

本期以FTP协议的主动模式为例做了讲解，FTP的被动模式、其他多通道协议类似，不再一一讲解。总之就是配置了ASPF可以生成动态维护临时协商的数据连接的表项，既简化了安全策略的配置又确保了安全性。最后以一张图作为结束。