天天看点

HCIE-Security Day5:安全策略(二)

HCIE-Security Day5:安全策略(二)
HCIE-Security Day5:安全策略(二)
HCIE-Security Day5:安全策略(二)

用到ASPF技术最多的是多通道协议、NAT SERVER、P2P协议、迅雷、QQ等

aspf的优点

1、性能依然可以保持

2、安全策略只需要放行协商通道,第二通道由ASPF生成的server map临时放行,后续产生详细的会话表后,将server map表删除。

3、安全性更高。

多通道协议

通信过程中,使用多个端口的协议。会由客户端和服务器之间的控制通道动态协商出数据通道,即通信双方的端口号是不固定的。而在配置aspf功能后,设备检测到控制通道的协商,根据关键报文载荷中的地址信息动态创建server-map表项,用于数据通道发起连接时进行查找。这个server-map表项包含了多通道协议报文中协商的数据通道的信息。

比较知名的多通道协议有FTP,FTP有两个通道,占用两个端口,一个21号端口和一个随机端口,分别是控制通道和数据通道,控制通道负责FTP相关指令的传递,数据通道负责数据的上载下载。

典型的多通道协议FTP

FTP的工作模式

控制通道总是由client发起。具体的工作方式是:

server有两个进程 一个主进程 负责接收新的请求 若干从进程 负责处理单个请求 

主进程的工作步骤

监听21号端口 等待client发来的连接请求

启动从属进程 处理client发来的连接请求 

client向server的21号端口发起连接请求时 还会携带一个随机端口 作为建立数据传送的端口 

server使用20号端口与client的提供端口建立数据传送连接

ftp有两种工作模式:主动模式和被动模式,不管哪种模式,控制连接总是由client主动发起的。而主动模式下,由server主动发起数据连接,被动模式下,由client主动发起数据连接。

1、主动模式

数据通道由server发起,认为工作在主动模式。

主动模式 (2步):server主动连接client 

1、client使用随机端口N 向server的21号端口建立控制连接 发送port命令 通告自己的数据传送端口M

2、server通过自己的20号端口主动向client的M端口建立数据连接 

2、被动模式

数据通道由client发起,认为工作在被动模式。

被动模式(3步):client主动连接server

1、client使用随机端口N 向server的21号端口建立控制连接 (组成TCP会话)发送pasv命令 

2、server随机打开一个高端端口P作为自己的数据传送端口 发送pasv命令 通告client自己的数据传送端口是P 

3、client使用随机端口N+1连接P端口 建立数据连接

因为ASPF的存在,在主动模式下,尽管只是做了控制通道的从trust到untrust的ftp的放行,却依然可以从untrust的server主动建立数据通道,产生了会话表项,且该表项依赖的安全策略是控制通道的。

因此我们可以再次理解ASPF,ASPF实现了对多通道协议的应用层信息的解析,比如ftp协议在协商时的某些数据。预测第二个通道建立时的特征,形成server map表项(服务器映射表)。

aspf的开启

firewall detect ftp//默认开启
undo firewall detect ftp      

aspf关闭后,控制通道的会话依然可以建立,但是数据通道无法建立了。

server-map表项

server-map是一种映射关系,当数据连接匹配了动态server-map表项时,不需要再查找包过滤策略,保证了某些特殊应用的正常转发。另一种情况,当数据连接匹配server-map表,会对报文中ip和端口进行转换。

server map是一种临时的会话表项,它不够精细(没有预测源端口),但是能够有效支持多通道协议的工作。

查看server-map表项

display firewall      
HCIE-Security Day5:安全策略(二)
HCIE-Security Day5:安全策略(二)

aspf和server-map并不完全对等,通过aspf可以生成server-map表项,通过其他的方式也可以生成server-map表项。可以理解为aspf对多通道协议的支持就是生成server-map表项。

server-map的产生

配置aspf后,转发多通道协议数据时动态生成

配置aspf后,转发stun协议数据时动态生成

配置nat-server后,静态生成

配置nat no-pat后,转发nat协议数据时动态生成

端口识别

防火墙具有端口识别功能,端口识别对多通道协议的支持

需求&场景

为什么会开发这个功能?

有一些多通道协议可以自定义端口,比如ftp就可以修改默认的21端口或者20端口。为了安防需要,需要关闭知名端口,那么对于一些协议,就需要修改默认端口号。

默认情况下,防火墙是通过报文携带的端口号来判断数据是什么协议或者应用产生的。那么如果不进行额外配置,就会导致防火墙无法识别流量,从而无法对流量进行控制。这时候,我们就需要配置端口识别或者叫做端口映射。

端口识别是把非标准协议端口映射成可以识别的应用协议端口。

有时候我们会存在误解,即防火墙不是通过ASPF直接解析应用层数据吗?那么通过对应用层数据的分析,就可以知道是什么类型的流量了呀?但是这样一来数据就进行应用层分析的工作量太大了,如果真的这么做,防火墙的过滤效率会很差,实际上,在进行ASPF动作前,防火墙还会过一遍初筛,即对报文头(srcip srcport dstip dstport protocol)进行初步分析,判断好它是不是某种类型的流量,再去针对该种类型的流量进行相应的ASPF分析。(所以其实我们在配置ASPF的时候也是针对某一类协议配置的嘛)

配置方法

acl 2000rule permit source 20.0.0.1 0//ftp server的ip地址,这里的0是0.0.0.0的缩写,表示唯一的一台主机port-mapping FTP port 31 acl 2000      

这个配置我们可以理解为:如果有数据要去访问ftp server 的31号端口的时候,就把这个数据映射为ftp数据。并由防火墙针对该数据进行进一步的ASPF解析。

会对原始报文内容进行修改吗?比如说将数据包头的dst port 修改为20?

不会

单通道协议有必要做端口识别吗?

没有必要,因为我们在配置的时候就已经知道需要开放哪些端口了。只需要我们自定义一个服务就好了。

ip service-set weboa type object service protocol tcp destination-port 8900//自定义在防火墙是创建了weboa的服务,匹配的是目标端口8900
security-policy
rule name r1service weboa action permit      

分片缓存

用来缓存先于首片到达设备的报文分片。

网络设备在传输报文时,如果设备上配置的MTU小于报文长度,则会将报文分片后继续发送,理想情况下,各分片报文将按照固定的先后顺序在网络中传输,在实际传输过程中,可能存在首片分片报文不是第一个到达防火墙的现象。此时,防火墙将丢弃该系列分片报文。为保证会话的正常进行,缺省情况下,防火墙支持分片缓存功能。设备会将非首片的分片报文缓存至分片散列表,等待首片到来建立会话后,将所有分片报文进行转发。若在指定的时间内首片分片没有到来,防火墙将丢弃分片缓存中的分片报文。

在vpn应用中(如IPSEC和GRE),由于需要设备对分片报文进行重组后解密或者解封装,设备才能进行后续处理,所以必须将设备配置成分片缓存状态,完成原始报文的分片缓存状态,才可以正常进行NAT。

分片报文直接转发功能一般用在不进行nat转换的情况下,开启该功能后防火墙将收到的分片报文直接转发出去,不创建会话表。

开启分片缓存的问题

如果网络中存在攻*击者,会发送大量的乱序分片报文,防火墙由于没有收全,就会进行缓存,如果量太大,就会堵塞防火墙的分片散列表,从而对正常的报文分片无法进行缓存,导致分片丢弃,tcp重传,网络出现大量丢包和延迟。

有4种办法解决这个问题。

配置分片缓存老化时间(之前版本的方法)

firewall session aging-time fragment interval (1-40000),默认5s      

如果报文分片缓存时间过长,直接老化丢弃。(我可以缓存,但是我不会长时间缓存)

配置分片缓存数量(当前版本的方法)

firewall fragment-cache-maximum //ipv4最大32个,ipv6 32-255个      

当一个报文的分片数量超过配置的最大分片缓存数目时,报文将被丢弃。

开启/关闭分片报文直接转发功能

firewall fragment-forward enable/disable      

开启后,收到分片报文会直接转发,如果收到的分片是首片报文的话,会走正常的会话流程,如果首先收到的分片报文是后续分片报文时,不会走会话流程,直接透传。只要是分片,我就放行(非常危险)。

开启/关闭分片报文直接丢弃功能

firewall fragment-discard enable/disable      

只要是分片,我就丢弃,不会缓存和转发。

长连接

很多应用没有对tcp进行保活机制,因为用户特别多,如果有1000个client周期性发送包活报文,就会对server的性能产生影响。

另一方面,即使如果某个时间没有数据需要发,不会释放连接。

但是防火墙存在会话表的老化机制(10min),如果这段时间内没有收到新的tcp报文来刷新会话表时,就会将该会话表老化掉。

这时候,client和server认为会话仍然保持建立,但是防火墙认为会话已经释放,所以再有client和server之间的数据的交互,第一不是首包,第二会话表中不存在表项,防火墙就会根据状态检测机制丢弃掉。导致大量丢包。

为了解决这个问题,就需要使用防火墙的长连接功能,这个时间默认情况下是1周(7*24)。

防火墙仅支持对TCP协议报文配置域间长连接功能

配置方法

security-policyrule name r1long-link enablelong-link aging-time 168(0-24000)