Local区域的安全策略 在学习安全区域的时候,提到过防火墙有一个特殊的区域为Local区域,Local区域的作用是管理防火墙自身的流量的,包括去往防火墙自身的流量,以及防火墙自身发出去的流量,别小看这个Local,很多技术都依赖防火墙自身去建立,如果策略没有得到放行,那么这些技术都实现不起来,工作中最常见的 (1)管理防火墙的流量,比如TELENT、SSH、HTTPS、Ping (2)VPN的流量,不管站点到站点还是远程拨入,都需要与防火墙建立通道 (3)路由协议,防火墙除了支持静态路由以外,OSPF、BGP、RIP这些都是支持的 上述提到的就是工作中比较常见的需要防火墙来处理的数据,之前我们介绍的安全策略都是针对穿越防火墙的数据进行安全策略的配置,这里来了解了解防火墙自身报文处理应该如何做安全策略。 防火墙狠起来自己都限制!(实验来感受Local区域的存在感) 整个环境很简单,三个区域,分别连接了PC以及路由器,并且配置好了对接地址,加入了安全区域,我们来看看默认情况下防火墙Local区域流量的限制是怎么样的。 防火墙就简单的配置了三个对接地址 接口分别加入了安全区域 (1)感受下Ping防火墙,以及防火墙Ping直连地址 测试下来,不管是Trust、DMZ、Untrust 双方都不通。 这里博主讲解一个比较实用的拍错命令,displayfirewall statistics system discard ,在遇到问题的时候还是非常有帮助的,能够提供一些提示帮助。 提示里面显示了,三种类型,第一个暂时不看,我们来看第二个与第三个 (1)IPv4 service-manage deny packets discarded:指的是IPV4管理服务被丢弃的包 (2)Packet default filter packets discarded:指的是默认策略过滤的数据包数量。 显然,我们的数据包是发出去了,或者防火墙收到了,只是安全规则没有做,导致不通,下面我们先来做下Local区域的安全策略,看看做完后的结果,在做之前首先得分析下区域流量的方向性,这样才好去配置。 有了这个图是不是变的很清晰了,Local代表防火墙本身,那么PC1去ping防火墙,流量方向是Trust到Local,反之,防火墙主动去Ping PC1,那么流量方向是Local到trust(DMZ与untrust同样的分析方式)。 (1)当某些区域访问防火墙的流量时,安全策略放行区域到Local的流量 security-policy rule name Trust_local source-zone trust destination-zone local source-address 192.168.1.0 mask 255.255.255.0 destination-address 192.168.1.254 mask255.255.255.255 service http service https service icmp service ssh service telnet action permit rule name DMZ_local source-zone dmz destination-zone local source-address 192.168.2.0 mask 255.255.255.0 destination-address 192.168.2.254 mask255.255.255.255 service http service https service icmp service ssh service telnet action permit rule nameUntrust_local source-zone untrust destination-zone local source-address 100.100.0.0 mask 255.255.255.0 destination-address 100.100.0.254 mask255.255.255.255 service http service https service icmp service ssh service telnet action permit (2)当防火墙访问其他区域的时候,安全策略放行Local到区域的流量 rule nameLocal_trust source-zone local destination-zone trust source-address 192.168.1.254 mask255.255.255.255 destination-address 192.168.1.0 mask255.255.255.0 service icmp action permit rule nameLocal_DMZ source-zone local destination-zone dmz source-address 192.168.2.254 mask255.255.255.255 destination-address 192.168.2.0 mask255.255.255.0 service icmp action permit rule name Local_untrust source-zone local destination-zone untrust source-address 100.100.0.254 mask255.255.255.255 destination-address 100.100.0.0 mask255.255.255.0 service icmp action permit # (3)诡异的结果 发现结果是不是很诡异,防火墙出去的流量已经通了,而访问防火墙的流量一个都没通!! 这个时候在用这个排查命令来看,发现只有一个提示了,IPV4管理服务拒绝的统计,那么可以判断其他访问防火墙的包给这个给拒绝了。 从安全策略的匹配数也可以看出来问题,去往防火墙的流量一个匹配数都没有,而防火墙发出去的都有匹配。 博主经验分享:在下一代防火墙中,默认所有接口都开了一个功能,叫做service-manage的功能,其实这个我们在之前讲解安全区域的时候看见过,只是博主那时候没介绍它的功能,这里来详细说说。先看看这个功能有什么参数。 在新版本中还支持更多的内容,可以看出来这个功能主要控制的抵达该接口的管理流量(这里http、https、ping、ssh等都是管理用的),并且它的优先级高于安全策略,也就是说该功能开启后,不受安全策略配置的影响,最主要的是默认是开启的,开启的同时,不允许任何管理流量通过,这一点很容易被忽略掉。(管理接口除外,管理接口默认允许了HTTP、HTTPS、Ping) 解决办法:(1)关闭这个功能,通过安全策略来放行 (2)加入允许的管理流量通过(默认什么都不允许) 可以选择关闭该功能 也可以开启某个管理功能,协议后面加permit即可,如果加入all permit,则所有管理协议都允许 这个时候就全通了,后续博主来分享下实际中应该如何操作。 (2)路由协议的控制 在这个拓扑里面,我们把防火墙与路由器建立一个OSPF看看。 最基本的配置了,就验证下OSPF的流量能否抵达防火墙或者防火墙能够发出去建立 在USG下一代V5版本是可以了的,可能大家在看强叔的技术漫谈里面看到说OSPF的流量需要放行,那是基于UTM时代的产品,下一代防火墙是直接默认允许的,UTM的产品开启了一个功能firewall packet-filter basic-protocolenable,而下一代防火墙里面默认没开启这个功能,这个功能的作用是控制常见的协议的单播包需要安全策略明确放行,而组播跟广播则默认不受安全策略控制。(在实验中就可以发现了,我们配置了DHCP的情况下,没有放行任何安全策略客户端就获取到了地址。)可能大家说OSPF不是依靠组播建立吗,但是注意在广播或者非广播类型里面,DD报文以及Link StateRequest这些都是单播发送的,只要开启了firewall packet-filter basic-protocol enable,那么会发现OSPF会卡在Exstart状态。 协议多通道的处理 对于安全策略的常见配置已经有了一定的了解了,那是不是我们把安全策略配置以及测试下,就可以保存走人了,这里博主说下,如果是UTM的产品那还不行!!但是到了下一代防火墙里面,确实可以保存后就走人了,但还是希望大家了解了解有这么一个功能,能够解决某些协议多通道的问题,工作中UTM的产品还是能遇到的。 在实际中,其实存在很多多通道的应用,比较经典的就是FTP了,在下一代防火墙中默认是解决了FTP带来的问题了,这里要想了解多通道带来的问题,先把这个功能去掉,了解后,在来看看它为什么能够解决。 [USG6000V1]undo firewall detect ftp 基础环境很简单,接口配置了网关地址,G1/0/0为(192.168.1.254) G1/0/1(192.168.2.254),然后加入了zone,配置了一个安全策略,允许Trust 192.168.1.1访问Untrust 192.168.2.1的FTP流量。 rule name trust_untrust_ftp source-zone trust destination-zone untrust source-address 192.168.1.1 mask255.255.255.255 destination-address 192.168.2.1 mask255.255.255.255 service ftp action permit # 测试下 在使用pasv模式的时候,卡在那了,登录失败,而防火墙上面看状态会话信息一切正常,也识别到了应用协议是FTP,并且来回也有数据包,但就是FTP登录失败!!我们在试试port模式。 改成port也是一样登录失败了。这个就要从FTP协议的工作原理说起了,FTP是一个典型的多通道协议,FTP客户端跟服务器会建立两条连接,一个连接为控制连接:用来传输FTP的指令和参数,一个连接为数据连接:获取目录以及传输数据等,数据连接又分为两种模式,一种是主动模式(port模式,FTP服务器主动向FTP客户端发起数据连接)一种是被动模式(PASV模式,FTP服务器被动等待客户端来发起连接) 抓包分析PASV模式 PASV是FTP被动等待客户端发起连接,来看看为什么通过不了防火墙 这里说下 不管是PASV还是port模式,都是针对的第二阶段数据通道来说的,前面的TCP建立以及FTP 第一阶段会话通道都是没什么变化的,从抓包也可以看出来前面就是客户端与服务器建立TCP连接(三次握手),然后登录的用户名密码等交互完成第一阶段会话建立,客户端数据通道请求PASV,服务器回应了一个参数(192,168,2,1,8,5),就是这个参数导致最终建立不起来。PASV之前说过,是服务器被动等待客户端去连接,但是这个连接就不在是FTP的标准端口号了,而是服务器告诉客户端一个临时的端口号,那这个端口号怎么来,就是(192,168,2,1,8,5)服务器告诉客户端的这个参数,192,168,2,1表示服务器的地址,你来连这个地址,端口号8,5(计算方式是8*256+5)也就是2053, 综合起来就是告诉客户端 你要想跟我建立数据通道,那就来连 192.168.2.1的2053端口号 那显然是通不过了,因为安全策略之放行了FTP标准端口号的流量,可能大家想到了,放行any不就行了,或者放行2053,我们来试试。 # ipservice-set 2053 type object service 0 protocol tcp destination-port 2053 # rule nametrust_untrust_ftp source-zone trust destination-zone untrust source-address 192.168.1.1 mask255.255.255.255 destination-address 192.168.2.1 mask255.255.255.255 service 2053 service ftp action permit # 这里涉及到了一个新配置,定义一个非标准的端口号,这个我们在下一篇会详细讲解,这里的作用就是匹配目的端口号2053,然后调用到安全策略。 比较糟糕的是,这个服务器告诉客户端的是个临时端口号,会不断变化的,这里变成了8,6了,那么可行的就只能是any了。 rule nametrust_untrust_ftp source-zone trust destination-zone untrust source-address 192.168.1.1 mask255.255.255.255 destination-address 192.168.2.1 mask255.255.255.255 service any(这个不显示在配置里面,因为默认就是any) action permit 这个时候就通了,这次又变成了8,7(8*256+7=2055),可以看出来这个临时通道是不可控的,完全猜不到端口号是多少,只能用any去匹配,Pasv的暂时算解决了,那么port的又会怎么样呢? 抓包分析PORT模式 port模式也叫做主动模式,服务器主动向客户端来发起连接数据通道建立。 会发现port也有一个类似于PASV模式的临时端口号,但是这里一定要注意,告诉它这个端口号的不是服务器了,而是客户端,也就是说当第一阶段会话建立完成后,客户端会告诉服务器你来连接我的 192.168.1.1:2070端口号(8*256+22),客户端会一直侦听这个端口号,可惜的是服务器回应了一个cannot open date(192.168.1.12070),这个肯定是显然不通的了!,因为防火墙的安全策略里面只允许了Client访问服务器的流量,而去客户端与服务器重新协商了临时通道,根本就匹配不上会话表的内容,那么防火墙会认为这是一个新的数据包,来查看是否有配置安全策略,这里并没有配置untrust到trust的安全策略,所以最终导致不通。 security-policy rule name trust_untrust_ftp source-zone trust destination-zone untrust source-address 192.168.1.1 mask255.255.255.255 destination-address 192.168.2.1 mask255.255.255.255 action permit rule name untrust_trust source-zone untrust destination-zone trust source-address 192.168.2.1 mask255.255.255.255 destination-address 192.168.1.1 mask255.255.255.255 action permit 新加入了一个untrust_trust的流量放行,再来看看能不能通。 建立成功了,这个能建立成功过程是牺牲了安全策略的某些条件才来实现成功的,PASV模式(需要把安全策略Trust到Untrust的servcie改成any)而port模式就更加危险了(需要放行Untrust到Trust的流量,实际中这样做那防火墙就没什么用了),不过不用担心,防火墙肯定是考虑到了这个问题出现的,也有解决办法。 ASPF(应用层报文过滤) ASPF的出现主要是针对应用层一些多通道的协议,只有防火墙能够去“读懂”它们这些协议的交互过程,才能够来临时的发行对应的流量通过,这些应用层记录的关键数据,防火墙会建立一个单独的表项,这个表项叫做 server-map,先来感受下ASPF的神奇之处。 [USG6000V1] firewall detect ftp (最开始把该功能关闭了),下一代防火墙中默认开启了对FTP的ASPF监控 # security-policy rule name trust_untrust_ftp source-zone trust destination-zone untrust source-address 192.168.1.1 mask255.255.255.255 destination-address 192.168.2.1 mask255.255.255.255 service ftp action permit # 再把策略恢复到最初的模样,再来测试下。 测试是成功的,并且通过会话表以及server-map表都能看到表项。 server-map表 可以发现server-map表里面记录的就是防火墙监控FTP应用交互中的关键数据,它监控到了FTP的数据通道临时协商了一个新的端口号,所以记录在了表里面,这个server-map表的作用就是当某个数据报文匹配上这个表现里面的内容后,则不再受安全策略的控制!也就是说防火墙只要通过ASPF分析出来了应用层信息之后,知晓了后续的报文建立信息,就会生成一个server-map表,为这个应用信息开启一条“隐形的通道”。 博主这里在强调下,怕有的朋友把会话表跟server-map表搞懵了。 会话表:是记录通信双方在防火墙上面的具体连接状态,防火墙在匹配了某个数据包连接的首包开始生成会话,后续连接的数据包匹配即可直接通过,不在受安全策略的控制。 Server-map表:它不记录当前连接的信息情况,它只关心当前信息中应用层协议是否需要有多通道或者其他特征的出现,如果有,它会把这些信息通过分析后记录在Server-map表,为后续报文通过提供了一个“临时的通道”,说临时是因为它有一个老化时间,避免永久开启,带来安全隐患,以及占用设备的资源。 整体下来防火墙的处理流程就是,防火墙收到报文后,先检查是否匹配会话表信息,如果匹配则直接通过,不匹配还会检查server-map表是否有该内容的信息,匹配了直接通过,不在受安全策略的控制,如果最后都不匹配,就检查是否有默认安全策略能否匹配。(这里有一点注意,数据包匹配了server-map表,但是防火墙还是为其创建了会话信息的,这样的好处就是后续报文过来只需要匹配会话表就可以通过了,而不需要在创建server-map)。 更多应用:在实际环境中,防火墙可以为更多的应用提供检测,默认情况下只开启了FTP,其余的协议需要我们手动去启用,比如网络中有语音的h323、sip等,那么则需要开启这些应用的监控,为其能够正常的通过防火墙,配置很简单,firewall detect后面加参数即可。 博主经验分享与总结 Local区域涉及到了防火墙自身流量的进入与发出,对于有时候排错非常有用的。 (1)常见环境可以放行Local到any的流量,这样防火墙自身发出的流量不受限制,这样可以在防火墙测试ping、以及协议特征库更新都需要防火墙主动发起,放行了才能通过。 (2)对安全性要求比较高的环境,Local到某某区域的流量,根据实际情况严格匹配进行放行。 (3)常见环境对于防火墙管理的Ping/http/https/ssh/telnet,可以通过service-manage来放行,放行后就所有地址都能够来访问这些了,常见的是内网接口基本是service-manage all permit即可,而面向互联网的接口则是放行Ping/https/ssh或者telnet即可。 (4)对于安全性要求比较严格的环境,不管是管理流量还是抵达防火墙的其他(比如IPSEC、L2TP、GRE)都由安全策略来控制,需要在接口关闭管理功能undo service-manageenable,对于任何抵达Local的流量,通过安全策略明确匹配放行。 (5)对于多通道的应用,在下一代防火墙中其实无需太多的去配置,对于常见的FTP,默认就已经开启了,其余的工作中需要在通过firewall detect 加入即可 “承上启下” 通过两篇文章已经对安全策略的了解更加深入了,那么安全策略还可以匹配哪些条件呢?我们知道的有IP地址,那么MAC地址以及域名是否能够匹配,如果条件比较多该怎么办?可以先想想哦~答案下面一篇认真学,可以解决这个疑问!~ |
|