会话表是一个记录TCP、UDP、ICMP等协议连接状态,实现报文正常转发的重要环节,是防火墙进行转发的唯一依据。
防火墙采用了基于状态的报文控制机制:只对首包或者少量报文进行检测就确定一条连接状态,大量报文直接根据所述连接的状态进行控制,这种状态检测机制迅速提高了防火墙的检测和转发效率。
而会话表正是为了记录连接的状态而存在的。设备在转发TCP\UDP\ICMP等报文时都需要查询会话表来判断该报文所属的连接以及相应的处理措施。
由于大量会话的存在会对设备资源造成很大的消耗,当超过规格限制时还会导致新会话无法建立,业务不能正常运行。所以必须及时对无用的连接进行清理。当一条会话在长时间没有被任何报文匹配,则说明该条会话所对应的连接可能已经关闭了,这条会话也就没有存在的必要了。所以FW为各种协议设定了会话老化机制。当一条会话在老化时间内没有被任何报文匹配,则会被从会话表中删除。
display firewall session table #显示简要会话表项
Current Total Sessions : NUM
TYPE VPN:SRCVPN --> DSTVPN SRCIP --> DSTIP
display firewall session table verbose #显示简要会话表项
Current Total Sessions : NUM
TYPE VPN:SRCVPN --> DSTVPN ID: ID-NUMBER
Zone: SRCZONE--> DSTZONE Remote TTL: TOTALTIME Left: LEFTTIME
Interface: OUTINTERFACE Nexthop: IP-ADDRESS MAC: MACADDRESS
<-- packets:NUMBER bytes:BYTES --> packets:NUMBER bytes:BYTES
SRCIP --> DSTIP PolicyName: POLICYNAME
TCP State: TCP State
reset firewallfirewall session table#清除系统当前会话表项
TYPE:该会话的协议类型。
VPN:SRCVPN --> DSTVPN
该会话的源VPN实例名称和目的VPN实例名称。PN指的是PN Instance,用在虚拟系统中,没有开启虚拟系统,就只有物理墙,默认都是public--->public,指从物理墙到物理墙。
ID: ID-NUMBER
该会话的ID号。自动生成,唯一确定一条会话。
Zone: SRCZONE--> DSTZONE
该会话的源安全区域名称和目的安全区域名称。
Remote
双机热备场景下,Remote说明当前会话是备份会话,该会话是从对端设备备份过来的。
TTL: TOTALTIME
会话表项总的存活时间。在路由交换中用于防止环路。在防火墙中指的是老化时间。
Left: LEFTTIME
会话表项剩余的存活时间。
老化时间的作用?
控制会话表条目,如果会话表条目太多或者频繁重新建立,都会影响设备转发性能。可以将老化时间理解为导致因为会话表存在而使得安全检查动态更新的原因。
如何查看协议的老化时间?
display firewall session aging-time
tcp:1200s
udp:120s
icmp:20s
syn:5s
fin-rst:10s
dns:30s
http:1200s
https:600s
tcp和udp的老化时间为什么不同?
因为tcp靠谱,需要3次握手才能建立会话,udp不靠谱,不需要建立会话。
老化时间能否修改?
可以。最大修改到65535s,即大约18小时。
firewall session aging-time service-set icmp 20000
老化时间包括系统预定义老化时间和自定义老化时间。
自定义老化时间
ip service-set test type object
service protocol 100
freiwall session aging-time service-set test 2000
display firewall session aging-time type user-defined
什么情况下会老化?
1、Left超时(老化时间到了)
2、内容安全检测到有病毒,会话表直接老化,加入黑名单
3、TCP会话结束,会发送FIN报文,fw收到第一个FIN报文(first-fin),老化时间变成900s,收到第二个FIN报文(fin-rst),老化时间变成10s
如果修改老化时间后,依然不能满足长时间的连接需求(最多18小时),比如ftp长时间下载或者长时间连接数据库。就需要开启长会话。
security-policy
rule name 1
long-link enable#开启长会话
long-link aging-time 1200#默认长会话时间为168小时,可以修改
检查
display firewall session table verbose long-link
在配置安全策略时自定义长连接,最多可以延长到168小时。
注意:在华为fw中,只能针对TCP协议。其他协议不支持
会话表能够承载多少条会话?
看防火墙性能。
Recv Interface:ININTERFACE
收到接口
Interface: OUTINTERFACE
报文出接口的接口号。
Nexthop: IP-ADDRESS
报文下一跳的IP地址。
Nexthop的值:
1、正常的下一跳
2、127.0.0.1:代表流量访问防火墙本身,比如网管。
MAC: MACADDRESS
报文下一跳的MAC地址。
MAC地址全0的情况:
1、流量访问防火墙本身,比如网管。
2、arp解析失败时
3、虚拟系统时,去往虚拟系统的流量下一跳mac地址。
以上四条是防火墙通过会话表快速转发的原因,不用查路由和arp,通过会话表中的出接口和其下一跳地址和对应的mac地址,就可以实现转发。
<-- packets:NUMBER bytes:BYTES
该会话反方向的报文数和字节数统计。
<==表示该会话反方向的报文正在进行硬件快转,<--表示该会话反方向的报文未进行硬件快转。
--> packets:NUMBER bytes:BYTES
该会话正方向的报文数和字节数统计。正常情况下应该与收到的报文数以及字节数相同,如果变少,说明存在丢包的情况。
==>表示该会话正方向的报文正在进行硬件快转,-->表示该会话正方向的报文未进行硬件快转。
+-〉代表开启aspf功能
以上两条信息通常在排错时常用。
SRCIP --> DSTIP
该会话的源IP地址、源端口号、目的IP地址、目的端口号。
地址的格式是x.x.x.x:portx[y.y.y.y:porty],其中portx和porty分别是源和目的端口号。括号内为NAT转换后地址。如果没有进行NAT转换,则不显示括号内的内容
为什么icmp在会话表中也显示端口?
为了统一格式,没有实际意义。适用icmp报文中type和code字段进行计算得出。
PolicyName: POLICYNAME
报文匹配的策略名称。
TCP State: TCP State
TCP连接状态,仅TCP会话显示此字段。
connecting:表示设备收到SYN首包,TCP连接正在建立。
established:表示设备收到ACK包,TCP连接已经建立完成。
fin-1:表示设备收到第一个FIN包,TCP连接正在断开。
close:表示设备收到第二个FIN包,TCP连接已经断开。
会话表是防火墙转发的唯一依据。
两种情况
第一种:命中并匹配会话表
转发,注意此时不需要再查路由表和mac表了,因为会话表中就有出接口和下一跳地址及其mac地址。
第二种:没有命中会话表条目
查会话表为什么快?
第一会话表条目一定小于安全策略条目,因为它是动态增删的。
第二会话表中有指导报文转发出接口的下一跳ip地址和mac地址、出接口。
白名单:匹配到快速转发。
二层---三层----入接口带宽限制---白名单---anti-ddos防御---ip/mac绑定
对于三层接口接收的报文,FW需要根据报文中的目的地址来查找路由表,以决定这个报文的出接口。所以此类报文会在解析和剥离头部信息后,进入后续的处理。
对于二层接口接收的报文,FW需要先判断这个帧是否需要跨VLAN转发。对于同一VLAN内的报文,FW需要根据报文中的目的MAC地址来查询MAC地址转发表,以决定这个报文的出接口。对于需要跨VLAN转发的报文,FW需要获取其VLAN ID,找到对应的子接口或者VLAN-IF接口。子接口和VLAN-IF接口是虚拟的三层接口。所以此时报文就会按照类似三层接口接收一样处理,FW根据报文中的目的地址来查找路由表,以决定这个报文的出接口。
这两类报文在提取到所需的信息后,剥离头部,进入后续的处理。
情况一:不存在匹配的会话表项
执行首包建立会话。
1、状态检测(默认开启):判断该报文是否属于正常的可以建立会话的首包。
2、黑名单:手工配置或由安全机制动态创建,根据报文五元组和始发用户信息快速过滤流量,对匹配到黑名单的报文直接丢弃,无需生成会话表,从而达到保护网络安全的目的。
3、server-map:放宽会话表的五元组限制,临时放行特殊协议的流量引导其建立会话表项,允许外网用户主动发起连接的情况。
产生server-map表有两大类:
3.1、aspf(多通道协议如ftp、stun类型如qq)
3.2、nat(no-pat、nat-server)
由aspf创建了server-map表后不需要再进行安全策略检查直接创建会话表。但是由nat创建的server-map表还需要进行向下进行匹配。
4、在线用户表:由于在线用户的老化时间为30min,用于记录当前在线用户信息的重要表项,包括用户与IP地址的对应关系,用户上线时间和在线时长等。如果报文源IP地址匹配了在线用户表,则直接提取用户信息,不需要对用户进行认证。
5、目的nat:查找目的nat策略,在会话表中记录地址转换信息。
6、应用关联:如果是首包,应用为空。
7、路由表/MAC表:三层接口接收的报文,防火墙根据报文中的目的地址来查询路由表,以决定这个报文的出接口,策略路由也在查询路由这个环节,并且优先于路由表,如果报文匹配策略路由则根据策略路由决定出接口。二层接口接收的报文,防火墙根据报文中的目的mac地址来查询mac表,以决定这个报文的出接口。
8、认证策略:根据报文的IP地址、安全区域信息决定是否要求对该条流量进行认证,以获取用户信息。对于需要认证的用户,设备会重定向该用户的http请求,向其推送web形式的认证页面,要求用户输入用户名和密码
9、用户首包处理:如果使用内置portal认证,就会重定向web认证界面给用户,就需要进行用户首包处理。
10、安全策略:用户通过认证后,设备就获取到了该条流量的用户的信息,根据配置,对这条流量进行包过滤处理。如果匹配成功,首先会根据策略动作是允许还是禁止决定是否放行首包建立会话。如果动作是允许,防火墙会根据安全策略引用的内容安全配置文件对该条流量进行标记,在下一阶段将会进行内容安全的处理。
11、SSL加密流量检测策略:匹配ssl加密流量检测策略的加密流量将被解密,然后才能进行内容安全检查。
12、源NAT策略:查找源nat策略,在会话表中记录地址转换信息。
13、连接数限制:如果此时会话数尚未到达连接数限制阈值,防火墙就会为通过上述检测的首包建立会话。
情况二:存在匹配的会话表项
匹配了会话表的后续报文不再重复首包处理流程,这种机制可以提供防火墙的检测效率。
1、在线用户刷新:保持流量的用户持续在线
2、基于流的攻击(anti-ddos)
3、状态检测
原因:
1)首包安全不代表后续报文安全:所以将对一条流量持续进行安全检测
2)检测具体是什么应用。
4、会话刷新
1)无刷新————匹配转发
2)有刷新:路由表---黑名单----安全策略-----用户重定向
一旦会话表项被刷新,防火墙就会对该条流量的报文重新进行一部分检查和处理,其流程仍然比首包处理流程简单很多,并且会话刷新的情况并非经常出现,所以这种机制在保证了对流量的持续保护的同时,也不会导致处理效率的明显降低。
哪些情况下会刷新?
路由表/mac表发生改变、策略发生改变
这个阶段的主要目的是对流量进行持续的安全防护,同时保证报文被正确发送。
带宽策略:判断当前流量的带宽占用情况,决定是否丢弃这个报文以降低流量速率。
内容安全(UTM.统一威胁管理,安全策略的后半部分)根据安全策略中引用的内容安全配置文件,FW会对报文进行内容安全过滤。
地址转换:根据会话表中的地址转换信息修改报文中的源地址或目的地址。注意:在第二阶段,只是匹配条件,并不会对地址进行转换
PN:根据PN配置,FW对报文进行处理。
如果是接收的PN报文(防火墙为隧道终点),则解封装报文。报文解封装后需要重新走一遍转发流程。
如果是准备进入PN隧道的报文(防火墙为隧道起点),则PN封装报文。
出接口阈值:根据之前的MAC地址转发表或者路由表查询的结果,FW已经得知该报文的出接口。根据出接口配置的带宽阈值限制,FW会再次控制流量的速率。
最后,FW将报文通过出接口发送出去。
应用层包过滤技术(application specific packet filter),高级通信过滤。检查应用层协议信息并且监控连接的应用层协议状态,对于特定应用协议的所有连接,每一个连接状态信息都将被aspf维护并用于动态的决定数据包是否被允许通过防火墙或者丢弃。
可以理解为:通过对协议应用层数据的解析,从协商通道中获取到数据通道要用到的部分参数,生成server-map表项,临时放行数据,并以此建立会话表。这些参数在协商通道未建立之间是不可知的,因此无法限制端口,属于状态检测防火墙的优点,代理防火墙和包过滤防火墙是不具备的。
用到ASPF技术最多的是多通道协议、NAT SERVER、P2P协议、迅雷、QQ等
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表,会对报文中ip和端口进行转换。
server map是一种临时的会话表项,它不够精细(没有预测源端口),但是能够有效支持多通道协议的工作。
查看server-map表项
display firewall
aspf和server-map并不完全对等,通过aspf可以生成server-map表项,通过其他的方式也可以生成server-map表项。可以理解为aspf对多通道协议的支持就是生成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小于报文长度,则会将报文分片后继续发送,理想情况下,各分片报文将按照固定的先后顺序在网络中传输,在实际传输过程中,可能存在首片分片报文不是第一个到达防火墙的现象。此时,防火墙将丢弃该系列分片报文。为保证会话的正常进行,缺省情况下,防火墙支持分片缓存功能。设备会将非首片的分片报文缓存至分片散列表,等待首片到来建立会话后,将所有分片报文进行转发。若在指定的时间内首片分片没有到来,防火墙将丢弃分片缓存中的分片报文。
在应用中(如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)
如果没有办法配置长连接,就需要关闭状态检测机制,非首包也可以建立会话表。