5、防火墙看家本领状态检测与会话机制

2022-03-08 23:19栏目:物联网
TAG:

状态检测功能

在第一篇文章介绍防火墙的发展史的时候,第三代防火墙一个非常重要的特性出现,包括目前下一代防火墙都一直在用的一个机制那就是状态检测,我们首先回顾下状态检测的产生背景,然后我们在以一个简单的对比来看看会话机制起到什么作用。


早期的防火墙包过滤功能(目前经常在用的ACL)

当我们192.168.1.1需要访问192.168.2.1的WEB服务的时候,先要去精确控制能匹配源目地址,端口号,包括方向。

(1)从PC访问服务器的方向来说,源地址是192.168.1.1,目的地址是192.168.2.1,源端口随机,目的端口号80

(2)从服务器返回数据表的方向来说,源地址是192.168.2.1,目的地址是192.168.1.1,源端口80,目的端口


我们写ACL规则的话(这里以通俗的表达展示,就不纠结格式了)

整体流程就是当PC1(192.168.1.1)去访问Server1(192.168.2.1)经过防火墙的时候,防火墙会进行包过滤检测,来检测当前的源目地址端口号是否匹配,匹配了则放行(这里匹配序列号1),抵达服务器后,服务器会响应,回复的过程中经过防火墙,防火墙再次检查策略(匹配2)放行通过,PC1最终完成数据交互。看似很顺利,但是这里有一个非常严重的问题,就是PC1的源端口号是随机的(因为操作系统会利用一个1024~65535范围内的任意一个端口号),所以我们没办法去精确匹配,为了数据通信正常,只能够全部放行,一旦外部出现一个恶意的攻击者,伪装成WEB服务器就可以随意的穿越防火墙到达内网,只要是192.168.2.1源地址,源端口号80的返回的就放行。其次带来的问题就是配置过于繁琐,不同的端口号以及地址需要写多条策略。


状态检测机制(也可以叫做状态检测机制的包过滤)

状态检测机制的出现怎么就解决了这个问题呢?我们还是以上面的图为例,在防火墙设置序列1的规则,允许PC(192.168.1.1)访问WEB服务器(192.168.2.1)的80端口号通过。

(1)PC开始发起对WEB服务的访问,数据包转发给防火墙处理

(2)防火墙收到数据包后,会检查安全策略,发现有一个序列号1的策略匹配,允许该数据包通过,并且建立了一个会话(包含了报文的源端口号、目的端口号、源地址、目的地址等信息)

(3)WEB服务器收到报文,回应给PC

(4)防火墙收到报文后,第一件事情查询会话表,把报文中的信息与会话信息进行比对,发现报文的信息与会话信息匹配,并且是符合对应协议规范的,则会认为该数据包是PC访问服务器的后续报文,直接允许通过。

(5)PC收到服务器返回的数据报文,整个过程完毕。


可以发现状态机制比之前的处理方式多了几点

(1)只需要首次匹配了安全策略,则直接放行,并且创建维护对应的会话信息表

(2)后续回应报文,只要会话表中存在,则直接匹配成功后通过放行

(3)就算有恶意伪装WEB服务器给PC发起数据,由于该数据报文的信息在会话表中没有,而且防火墙上面没有创建对应的安全策略,直接丢弃。既保证了PC可以正常访问WEB服务器,也同时解决了随机端口带来的一些隐患。


一个小实验来体验状态检测带来的魅力

两个环境,一个是路由器连接客户端与服务器,一个是防火墙连接客户端与服务器,同样的需求,客户端允许访问服务器,而服务器不能主动访问客户端。


路由器的配置

路由器初始化配置很简单,G0/0/0配置了一个192.168.1.254,G0/0/1配置了一个192.168.2.254,PC与服务器配置各个地址与网管。

通信正常,现在来做下访问控制(路由器写ACL)


访问控制ACL配置

#

acl number 3000

rule 5 permit ip source 192.168.1.1 0 destination 192.168.2.1 0

acl number 3001

rule 5 deny ip source 192.168.2.1 0 destination 192.168.1.1 0

#

interface GigabitEthernet0/0/0

ip address 192.168.1.254 255.255.255.0

traffic-filter inbound acl 3000

#

interface GigabitEthernet0/0/1

ip address 192.168.2.254 255.255.255.0

traffic-filter inbound acl 3001

可以发现,访问控制ACL配置上去后流量都不通了!!虽然服务器的流量是被阻断了,不能访问客户端,但是这样客户端也访问不了服务器了。


防火墙的配置

接口配置了两个网关地址

G1/0/0(接PC的口)加入了trust,G1/0/1(接服务器的口)加入了DMZ


安全配置(后面会详细讲解)

security-policy

rule name pc_server_permit

source-zone trust

destination-zone dmz

source-address 192.168.1.1 mask 255.255.255.255

destination-address 192.168.2.1 mask 255.255.255.255

action permit

#这条策略的简单意思是当从trust的192.168.1.1访问DMZ的192.168.2.1的时候放行


rule name server_pc_deny

source-zone dmz

destination-zone trust

source-address 192.168.2.1 mask 255.255.255.255

destination-address 192.168.1.1 mask 255.255.255.255

action deny

#这条策略的简单意思是当从DMZ的192.168.2.1访问192.168.1.1的时候拒绝。


客户端与服务器的地址设置

客户端访问服务器正常,ping也正常

服务器访问PC不能访问,这样实现了我们的需求,那路由器为什么不行呢?防火墙就可以,下面来对比下两种方式在处理数据过程中对于数据控制的流程是怎么样的。


路由器处理数据转发与访问控制的整个流程

(1)PC发起对服务器的WEB访问,丢给路由器处理

(2)路由器接口调用了访问控制,源地址192.168.1.1的去往192.168.2.1的任意流量,直接允许通过,查询路由表交给服务器

(3)服务器收到报文进行回应,抵达路由器的时候,由G0/0/1口调用了一个访问控制,来自于192.168.2.1去往192.168.1.1的流量任意流量全部拒绝,最终PC收不到这个包的回应

(4)最终服务器主动访问pc的流量也是通过不了的。


防火墙处理数据转发与访问控制的整个流程

(1)PC发起对服务器的WEB访问,丢给防火墙处理

(2)防火墙检测安全策略,发现数据报文是从Trust到DMZ、源目地址都匹配,直接通过,并且创建这个访问的会话信息

(3)服务器收到并且响应PC的报文,丢给防火墙处理,如果是路由器它会检测接口的访问控制,然后来执行,防火墙则不一样,它会优先看是否有这个报文的会话信息没,有这个报文对应的会话信息,匹配成功则直接通过,不在查看安全策略。

(4)最终PC收到服务器的回应数据,完成了访问

(5)当服务器主动向对PC访问的时候,流量抵达防火墙,防火墙发现这个报文跟会话信息的内容不匹配,则继续查找安全策略,安全策略有一条来自于DMZ(图表格DZM写错了)到Trust源是192.168.2.1,目的是192.168.1.1,执行动作是拒绝,那么该报文就被丢弃了。


传统包过滤与状态检测包过滤的总结

传统包过滤它只能根据静态设置的规则来判断报文通过与否,不会去关心报文的关联性(比如上面的PC访问服务器,服务器回应的包,其实跟之前发起的包是有联系的,但是传统包过滤会认为报文都是独立的),每个报文根据策略的检测,导致管理员在实施规划的时候要考虑数据包每一个方向的规则该如何配置,在配置上显得很繁琐,转发效率也很低(每个数据包都需要进行检查匹配策略,随着策略一多,那延迟就更大了)


状态检测包过滤它的工作原理则不一样,它能够去关联数据包的关联性(比如上面的PC访问服务器通过防火墙的时候会建立会话表,然后服务器回应的包,发现跟之前发出去的有关联,匹配了会话信息直接通过),这种就把通信双方属于同一个会话连接的报文看作看了一个整体的数据流,而不跟传统包过滤一样是一个独立的。转发效率随着第一个报文建立会话信息后,该报文后续就直接通过会话转发通过,不在进行策略匹配检测,自然提高了。(总结下来就是首次匹配安全策略,建立会话信息,后续同一数据报文流量通过直接匹配会话通过)


博主经验分享:在工作中不知道大家遇到没遇到客户有这样的需求,比如有多个部门,划分了多个VLAN,客户希望说高管部门能够访问所有部门,而其他部门不能访问高管这个部门,那么通过交换机路由器很难实现这样的需求的,原因就是上面总结里面提到的,传统包过滤(ACL)它不会去关联数据报文的是否为同一个,来一个查看策略,然后执行,那么高管访问其他部门的流量,返回的时候就会被丢弃(因为其他部门不能访问高管,当然如果说只是ping,可以通过ECHO类型控制,像上面的HTTP这些应用就没辙了),所以遇到这种需求的时候,我就会跟客户说目前的路由器交换机不支持这种功能,都是双向控制,没法做到单向控制,这种只有防火墙才行。(路由器交换机高端的确实支持反向ACL,跟防火墙的状态检测机制类似,它会在数据包通过的时候,自动的在返回的接口的列表里面添加一个通过的ACL,来达到放行的目的,并且这个通过的ACL优先级高于拒绝的。)


会话机制

上面提到状态检测功能在数据报文首次匹配安全策略后会建立会话信息,会话是通信双方建立的连接在防火墙上体现出来的一种具体状态,一条会话标识通信双方的一个连接,那么实际网络中,防火墙处理成千上万的会话连接信息,我们把多条会话的合集叫做会话表。

还是以上面的案例拓扑(配置参考上面),实际用client访问server的WWW服务,来感受下会话表项是什么样的。

访问成功后,通过display firewall session table 查看会话表内容,看看包含了什么


http VPN: public --> public 192.168.1.1:2052 --> 192.168.2.1:80


(1)http表示当前的协议(协议不单单说TCP、UDP,防火墙可以识别出应用层具体的协议,比如HTTP、、迅雷等)

(2)192.168.1.1表示源地址

(3)2052 表示源端口

(4)192.168.2.1表示目的地址

(5)80表示目的端口号


可以发现,在会话表里面协议、源地址、目的地址、源端口、目的端口这5个元素是会话中的核心内容,我们将这个五个元素称之为“五元组”。有了这个五元组的存在,数据报文在穿越防火墙的时候,只要五元组信息匹配,则认为是同一条流,防火墙可以通过五元组信息来唯一确定一条连接会话。比如这里的client(192.168.1.1)发起访问使用源端口号2052,访问服务器目的地址192.168.2.1 目的端口80端口,协议是http,当防火墙返回包的时候,以192.168.2.1源地址,源端口号是80,发送给client 目的地址是192.168.1.1,目的端口号是2052,协议HTTP,在经过防火墙的时候,匹配了五元组信息,也就是目前防火墙存在的会话信息,直接就通过了。

看过简单的会话表信息了,在来看看详细的会话表信息

display firewall session tableverbose:通过加入了一个verbose可以查看更加详细信息

http VPN: public --> public ID: c487f26ec64f3bfa8aaa7

Zone: trust --> dmz TTL: 00:00:10 Left: 00:00:02

Recv Interface: GigabitEthernet1/0/0

Interface: GigabitEthernet1/0/1 NextHop: 192.168.2.1 MAC: 5489-98dc-44cf

<--packets: 5 bytes: 511 --> packets: 6 bytes: 401

192.168.1.1:2053 --> 192.168.2.1:80 PolicyName: pc_server_permit

TCP State: close


在来看看一些在上面除了五元组信息之外的其他没有见过的信息。

public ID: 用于标识唯一一个会话信息的ID,防火墙能够快速查找(比如会话几万条的时候)

Zone:表示报文在安全区域之间流动的放行,这里Trust-->dmz,说明报文是从trust到dmz区域

TTL:会话的老化时间,这个时间一过,会话就被清除(如果中间有对应流量继续匹配了会话,TTL会刷新)

Left:标识该会话的剩余时间,相当于倒计时,比如这里还剩下两秒,过了这个时间就清楚会话

Recv Interface:报文的入接口,也就是从哪个接口收到该报文

Interface:报文的出接口,从哪个口发出去

NextHop:发出去后该报文交给谁处理的具体地址(这个案例里面WEB服务器就是最终的下一跳地址)

MAC:发送出去后下一跳的MAC地址(这个案例里面的下一跳MAC地址就是WEB服务器)

--> packets:表示会话正方向上的报文统计信息(Client向WEB服务器发送的报文个数与字节数)

<--packets:标识会话反方向上的报文统计信息(WEB服务器向PC返回报文的个数和字节数)

192.168.1.1:2053 --> 192.168.2.1:80:源目地址与端口号

PolicyName: 匹配的安全策略名字

TCP State:如果是TCP会话则会显示一个TCP状态。


可以发现除了五元组信息以外,包括安全区域流动的方向记录、匹配的安全策略记录、TTL、入与出的接口、下一跳地址与MAC地址等,这些信息共同的组成了一个完整的会话表信息,这些信息了解了,对于我们后续排错非常重要,防火墙哪不通,可以直接看会话表来找出问题的,这里讲解几个会话中比较重要的内容。


1、报文统计

在会话表中“<--”和“-->”这个两个标识的报文统计信息非常重要,对于我们排错定位非常有帮助

<--packets: 5 bytes: 511 --> packets: 6 bytes: 401


参考上面的案例,client访问服务器的WEB应用,数据包有去有回,都会有统计,那么实际环境中会遇到的各种各样的情况,讲解下比较常见的状况。


<---packters:0 bytes:0 --->packets :5 bytesr:66


(1)数据包已经通过防火墙发出去了,但是服务器没有收到,这种可能就是防火墙发出去了,互联网丢弃了或者是服务器正好坏了。(测试方法可以ping防火墙,或者叫服务器运维人员检查核对)

(2)数据包已经通过防火墙发出去了,服务器收到了,但是回来的时候中间被丢弃了,可能中间运营商做了某些策略(这种可以ping通,某些应用访问不了,或者直接也ping不通,跨运营商的场景比较常见)

(3)数据包已经通过防火墙出去了,服务器收到了,但是回来的时候走的其他路径。(异步路由)

“承上启下”

前面两种情况比较好理解,防火墙把数据包发出去了,中间网络出现了故障或者是WEB服务器本身出现了故障,可以一一排查,缩小故障的范围,定位问题所在,但是第三种情况就比较特殊,它属于来回路径不一样的组网,导致防火墙没办法处理该数据包,那么防火墙为什么要丢弃这样的数据包?如果遇到这样的组网该如何处理? 可以先想想哦~答案下面一篇认真学,可以解决这个疑问!~

介绍

《华为下一代USG防火墙(由浅入深实际案例系列)》是博主原创的针对华为厂商下一代USG防火墙组网系列应用部署为主的系列课程,结合实际环境出发,加上了博主部署经验以及会遇到哪些问题等进行综合,做到学以致用,给各位看官朋友一个不一样的学习体验。


如果大家有任何疑问或者文中有错误跟疏忽的地方,欢迎大家留言指出,博主看到后会第一时间修改,谢谢大家的支持,更多技术文章尽在网络之路Blog,版权归网络之路Blog所有,原创不易,侵权必究,觉得有帮助的,关注、转发、点赞支持下!~。


上一篇回顾

24、基于无线场景的内置portal匿名登录与接入码功能


下一篇学习

26、基于爱快网关自带的认证功能打造一个低成本的网页认证网络

本文来自网络,不代表山斋月平台立场,转载请注明出处: https://www.shanzhaiyue.top