【强叔侃墙 内功心法篇5】扫地神僧是怎样练成的----防火墙报文处理流程简介

[复制链接]
发表于 : 2014-8-8 14:32:51 最新回复:2019-09-02 15:13:30
18165 24
强叔侃墙
强叔侃墙 官方号

强叔最近埋头苦功,终于憋出大招。是为题记。

 

强叔被金庸大侠影响甚深,年少时曾手捧老先生各大部头废寝忘食,至今仍对多个经典情节念念不忘。早在十多年前,便与同道兄弟充分讨论过:金庸作品中,最厉害的招式应是独孤九剑,因令狐冲在内力全失情况下,一剑挑瞎十五人眼睛;而最厉害的内功当属扫地僧的内功,秒掉了萧峰父子和慕容父子,算得上前无古人、后无来者。最要命的是,我们无从得知扫地神僧是怎样练成的,这让强叔一直心痒不已。
而回到强叔开讲的防火墙,强叔绝不能让各位小伙伴一直抓耳挠腮--掌握了防火墙报文处理流程,就是掌握了防火墙实现的精髓,就如练成了扫地神僧的内功。表面上看来还是原来的小伙伴,也许貌不惊人,但其实内心那是相当地强大。当你能够娴熟地定位防火墙配置类故障,无论走到哪里,都会如那漆黑中的萤火虫一样,那样的鲜明,那样的出众,那样的拉风~~

 

在《华为防火墙产品一览》中,强叔曾介绍:华为出品低、中、高端共三个系列防火墙,对应当前的主力产品型号分别为USG2000、USG5000和USG9000。<注>2013年8月发布了下一代防火墙USG6000系列,强叔后续针对性详述。这三个系列产品毫无疑问都基于状态检测与会话机制实现,但是中低端防火墙与高端防火墙在架构实现上有些区别:中低端防火墙采用集中式架构,高端防火墙采用分布式架构,这使得它们在对报文处理的实现上,稍有不同。不过这个稍有不同并不影响主线,强叔的思路是单刀直入,先讲大同的报文处理流程(同样会话机制),再强调求同存异(架构差异影响)。

 

华为大同:全系列状态检测防火墙报文处理流程

下面先以USG5500系列产品为例,梳理防火墙报文处理流程。
状态检测与会话机制是华为防火墙对报文处理的关键点:即防火墙收到报文后,何时、如何创建会话、命中会话表的报文被如何转发。那么可以此关键点为界线延伸,我们将报文经防火墙处理分为查询会话表前、中、后三个阶段,参见如下USG5500报文处理全景图。友情提醒:图很复杂,对三个阶段有印象即可,重点看图下的文字拆解吧。

我们来进一步介绍下每个阶段的目的和处理过程。
1、 查询会话之前的处理过程:基础处理。
这个阶段的主要目的是解析出报文的帧头部和IP报文头部,并根据头部当中的信息进行一些基础的安全检测(单包攻击防范)。
2、 查询会话的处理过程:转发处理,关键是会话建立。
这个阶段到了防火墙对报文转发处理的核心。建立会话表,根据会话表转发报文,是状态检测防火墙的精髓。此部分要梳理清楚思路,耗费很多笔墨,还请小伙伴们耐心观看。
报文到此阶段,防火墙最先判断该报文是否要创建会话。
1)OSPF、IGMP组播报文等一些协议报文是不创建会话的,那么这些报文就会去直接查路由和安全策略。
2)而TCP首包、UDP等报文都需要创建会话,那么判断该报文要创建会话后,接下来马上查询会话表中是否已经创建了该报文的会话。

  • A. 对于会话表中不存在匹配任一表项的报文,防火墙判断该报文为某一流量的首包,进行首包处理流程
  • B. 对于会话表中存在匹配表项的报文,防火墙判断该报文为某一流量的后续包,进行后续包处理流程

这也是强叔在《状态检测和会话机制》一节中提到的“为数据流的第一个报文建立会话,数据流内的后续报文直接根据会话进行转发,提高了转发效率。”
首包处理流程要点:
(1)先使该报文与黑名单匹配,若报文源地址命中黑名单,则此报文被丢弃,不再继续后续流程。
(2)查询该报文是否命中正反向Server-map表,若报文命中Server-map表,记录Server-map表中的信息。

   防火墙上配置NAT Server、NAT No-pat、三元组NAT、ASPF等功能,会生成Server-map表:
NAT Server:配置完成后防火墙上直接生成Server-map表。若报文匹配该Server-map表,刚记录Server-map表中转换后目的IP地址和端口信息,并根据该记录继续后续流程。
NAT No-pat:匹配该NAT No-pat策略的报文,会触发生成Server-map表。后续报文(这里的后续报文不是首包/后续包概念中的后续包,是这个业务的后续报文)查询该Server-map表,记录转换后目的IP地址和端口信息,并根据该记录继续后续流程。
三元组NAT:匹配该三元组NAT策略的报文,会触发生成Server-map表。后续报文(同上)查询该Server-map表,记录转换后目的IP地址和端口信息,并根据该记录继续后续流程。这块还要分情况对待,匹配Server-map表的报文受不受安全策略控制是由firewall endpoint-independent filter enable命令决定的
ASPF:在安全域间或域内,针对特定业务配置ASPF功能后,防火墙会对业务报文进行检测,检测到的报文会触发生成Server-map表。后续报文(同上)查询该Server-map表,命中该表的报文,不再进行安全策略匹配,直接按该表信息创建新会话。

(3)继续根据(2)的记录结果,查询命中哪条路由,优先查询策略路由。若未命中策略路由,则查询正向路由表,决定报文的下一跳和出接口。

         这里说明下:为什么要强调根据(2)的记录结果呢?因为此时报文未进行实质转换,但查询路由是使用虚拟出来的、命中Server-map表经转换后的报文查询,这是为了最终经过防火墙各种处理完毕的报文能够正确转发。

(4)查询是否命中安全策略,已知报文入接口源地址、判断出报文出接口后,可以查询到该出入接口所在安全区域的安全策略配置,若报文没有匹配到安全策略或匹配到安全策略中定义为“阻断”的规则,则报文被丢弃,不再继续后续流程;若报文匹配安全策略中定义为“允许”的规则,则继续后续流程。
(5)查询是否命中源NAT策略,若报文匹配到一条源NAT策略,则记录NAT转换后的源IP地址和端口信息。
(6)顺利通过安全策略匹配检查后,终于走到这一步:根据上述记录结果,创建会话。

后续包处理流程:

很简单,判断会话是否需要刷新。当为首包创建会话的各表项和策略(如路由表、安全策略)变化时,会话需要刷新。若需要则继续查询路由、查询安全策略,若不需要直接进行后续阶段处理。

 

总结:

  • 强叔在开篇中提到防火墙与路由器的区别,对于路由器来说可说是使出浑身解数(通过路由表)将报文转发出去,而对于防火墙来说要作为守护神坚决阻挡非法报文(只有通过各种安全检查建立会话表才可能被转发)。所以防火墙丢弃一些报文是正常的处理流程,包括第一阶段的解决IP报文头、单包攻击,第二阶段的黑名单、安全策略,第三阶段的UTM处理、限流等等,是报文的主要丢弃点。
  • 进行故障定位时,防火墙上是否创建了指定某条流量的会话,是定位要考虑的关键界线。若未创建会话,则考虑是报文是否到达设备、接口丢包、命中黑名单或安全策略、无路由、或NAT等配置出现问题;而存在会话,则向后续的安全业务处理阶段考虑。

 

3、查询(或创建或刷新)会话的处理过程:进行实质各安全业务处理、及之后的报文去向。

报文在首包处理流程中经一通查询、创建会话后,就与后续包处理流程殊途同归了,即都进入第3阶段。
此阶段首先进行基于IP的限流、IPS等UTM业务处理,报文顺利通过检查之后,到了实质性的地址转换:根据已创建的会话表,进行目的地址转换、源地址转换。
这个目的地址转换、源地址转换对应配置就是NAT Server、源NAT策略等NAT功能,对应报文则是在第2阶段首包流程中已经经过一通查询并创建了会话表。
那么,如果想要在此阶段能够准确地对报文进行源地址转换,有两个常见的points需要关注:

  • 一是报文在前面流程中是否命中了Server-map表,尤其是反向Server-map表,若已经命中,那么报文会根据反向Servermap表进行源地址转换,不会再往后匹配源NAT策略了。
  • 一是报文在后续流程中是否计划要进行VPN加封装,如果在此时定义该条数据流进行了NAT转换,那么后续就无法进入VPN协商流程了。

而按计划进行目的地址转换问题不大,一般是配置NAT Server,其报文处理优先级很高,报文走入歧途可能性就小。

最后,该转换转换,该过滤过滤,一切安全业务流程顺利通过后,报文终于到了分发十字路口:
A. 如ping、OSPF等路由协议报文是要到防火墙本身,会被上送至管理层面处理;
B. 如VPN报文(防火墙为隧道终点,收到VPN报文)就会被解封装、并在解封装后重走一次上述1、2、3流程;
C. 如准备进入VPN隧道的报文(防火墙为VPN隧道起点)就会被进行VPN封装等等。

 

求同存异:集中式与分布式防火墙差异对报文处理流程影响 

 防火墙大同的报文处理流程介绍完毕,我们来看一下集中式与分布式架构的区别会导致哪些差异。

  • 对于集中式低端防火墙,来往报文会被上送至一个集中的CPU模块(可能由多个CPU组成)进行处理。
    集中式防火墙一般为盒式设备,可以插接多种扩展接口卡,但设备的总机性能恒定,即取决于该设备配置的CPU模块处理能力。上述介绍的USG5500产品报文处理流程即为其全部流程。
  • 对于分布式高端防火墙,对报文的处理就会比较复杂,有多种情况,上述介绍的报文处理流程是其中一个最核心的子集―SPU板业务处理流程。

分布式防火墙一般为框式设备,以USG9000来说,由两块标配主控板MPU、交换网板SFU、接口板LPU、业务板SPU组成,其中LPU与SPU的槽位可混插,客户按需购买。相比集中式防火墙,分布式防火墙由各种单板组成,每种单板各司其责。

  • 主控板MPU:主要负责系统的控制和管理工作,包括路由计算、设备管理和维护、设备监控等。
  • 交换网板SFU:主要负责各板之间数据交换。
  • 接口板LPU:主要负责接收和发送报文,以及QoS处理等。
  • 业务板SPU:主要负责防火墙的安全业务处理,包括安全策略、NAT、攻击防范、VPN等。设备总机性能随插接SPU板的数量增加而线性增加,这是分布式防火墙的特性和价值所在。

那么我们来看一下,各类报文在分布式高端防火墙上是如何被处理的:


已经提到①②是防火墙业务处理的核心,也正是防火墙的安全防护价值所在。③④多用于设备管理、定位故障;⑤⑥多用于网络互联如路由学习。

 

还有一个更复杂的问题:当一台分布式防火墙配置多个业务板时,报文经过接口板处理后,会被送至哪个业务板呢?如上图中的①②③④报文都会经业务板处理,那么会被送至SPU1还是SPU2呢?
这时会有选择“由哪块SPU板进行业务处理”的动作,即USG9000产品文档中提到的hash选板。默认配置是根据报文的源+目地址经过运算选择。----由于配置了多个SPU板,业务可能在防火墙多个业务板分别建立会话。
例如,以PC访问Web服务器来说,假设PC发往Web服务器在业务板SPU1上建立了会话,而Web服务器的回应报文可能会由业务板SPU2处理。一句话就是请求报文与回应报文有可能被分配到防火墙的不同业务板处理。那么可能会产生一个问题:由于请求报文基于业务板SPU1建立了会话,而回应报文查不到反向会话被丢弃。实际上,USG9000在建立业务板的会话表时,同时会进行hash预测,准确预测回应报文会被哪块业务板处理,在该业务板上同步建立起一条反向会话,保证回应报文能够被正确转发。当然,正反向会话间会定时同步,保证同步老化、统计报文信息等等。

配置实例:与防火墙报文处理流程相关的配置技巧

下面我们以实例来说明,熟悉防火墙报文处理流程,不需要再死记配置限制,而是根据逻辑直接判断如何正确配置。
例1,当安全策略遇上NAT Server。
在eNSP模拟器上,PC1(1.1.1.2)----防火墙USG5500----FTP服务器(192.168.1.2)简单组网,在防火墙上配置NAT Server,将FTP服务器地址转化为与PC同一网段的地址,配置如下:

[USG5500] nat server 0 global 1.1.1.5 inside 192.168.1.2

若希望PC1及其他多个PC能且只能访问该FTP服务器,应该如何配置严格的安全策略?实际是基于固定的目的地址配置安全策略问题。

分析:根据防火墙报文处理流程,先进行NAT Server转换、查询Server-Map表,再进行安全策略处理。那么,该固定的目的地址,应配置为该FTP服务器的真实地址(即inside地址)。


[USG5500] dis cu | include policy                          

policy interzone trust untrust inbound                      

 policy 0                                               

  policy destination 192.168.1.2 0.0.0.0    

验证如下:
1)关闭防火墙所有域间缺省包过滤,只保留上述在trust与untrust域间配置的该条安全策略。
2)在PC***问FTP服务器,可以成功看到FTP服务器的文件列表。 

 

 

3)查看防火墙USG5500会话表,可以看到FTP服务器已经做了NAT Server,且FTP控制通道与数据通道均已建立。


结论:根据防火墙报文处理流程,先查询Server-Map表,根据查询的记录结果再进行安全策略处理。当需求为允许多个外网客户端访问经过NAT Server转换的服务器时,安全策略配置允许到达的目的地址为该服务器的内网真实地址,而非NAT Server的global地址。

 

例2,当源NAT遇上NAT Server。
某公司分部与总部通过Internet进行IPSec互联:

  • 总部用户(192.168.1.0/24)访问Internet时经过源NAT转换、而与分部通信时不进行源NAT转换
  • 总部部署了一台HTTP Server(192.168.1.2)对外提供服务时配置了NAT Server

分部可以访问总部HTTP Server的私网地址,总部192.168.1.0/24网段也能正常和分部的10.0.0.0/24网段通信。总部HTTP Server却无法访问分部10.0.0.0/24网段的资源,删除NAT Server后就能正常访问。

【强叔侃墙 内功心法篇5】扫地神僧是怎样练成的----防火墙报文处理流程简介-1323367-5

FW(总部)关键配置如下:
#
acl number 3000
  rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 10.0.0.0 0.0.0.255
#                                                                             
ipsec policy map1 10 manual
security acl 3000
proposal tran1
#
nat-policy interzone trust untrust outbound
  policy 0      //访问分部的流量不做源地址转换//
  action no-nat
  policy source 192.168.1.0 mask 24
  policy destination 10.0.0.0 mask 24     
 
policy 5      //总部员工上网进行源NAT转换//
  action source-nat
  policy source 192.168.1.0 mask 24
  easy-ip GigabitEthernet0/0/1
#
nat server protocol tcp global 1.1.1.1 9980 inside 192.168.1.2 80

分析:防火墙上涉及HTTP Server的配置如下:
① NAT Server,将HTTP Server的私网192.168.1.2:80映射成为1.1.1.1:9980
②源NAT,策略定义192.168.1.0网段去往分部不进行源NAT转换
查看防火墙的Server-map表:


NAT Server转换成功,生成正反向Server-map表。且按照反向Server-map表含义,当该HTTP Server主动访问网络时,亦进行NAT Server转换。根据防火墙报文处理流程,优先查询正反向Server-map表,命中反向Server-map表后,不再匹配源NAT策略。因此总部HTTP Server却无法访问分部10.0.0.0/24网段的资源。
这个问题的解决办法是,配置NAT Server时增加no-reverse参数,要求不生成反向Server-map表,这样总可以继续查询NAT策略,使该HTTP Server可以正常访问分部资源。
结论:上述报文处理流程第3阶段时已进行提醒,进行源NAT处理时,注意报文在前面流程中是否命中了Server-map表,尤其不要忽略反向Server-map表,如果已经命中,此时源NAT处理不会再生效。

 

防火墙配置类问题与报文处理流程相关的,可能还有很多,本文难以穷尽,只捡两个实际常用NAT功能的例子抛砖,供小伙伴参考。本文笔墨颇多,逻辑难免有不严谨之处,请小伙伴琢磨指证。

强叔研习金庸多年,可只见一个扫地神僧往来无古今,亦只闻一曲笑傲江湖流传千百年。世上没有什么捷径,掌握防火墙的转发精髓仍需在处理问题实践锻炼中不断琢磨,在参考材料字里行间中不断思考,本文仅提供神功练成的入门之法,强叔与小伙伴们一同继续修行吧。

 

 更多好文,更多精彩,尽在强叔汇总贴:http://forum.huawei.com/enterprise/thread-331003.html

本帖被以下专题推荐:

  • x
  • 常规:

点评 回复

跳转到指定楼层
cxinman
cxinman   发表于 2014-8-11 23:11:56 已赞(0) 赞(0)

非常精彩,收藏细读。
  • x
  • 常规:

点评 回复

l00738227
l00738227   发表于 2014-8-19 14:45:11 已赞(0) 赞(0)

请问,在查server-map时候,是查静态表,还是动态表?还是两者都查?
  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2014-8-19 17:00:51 已赞(0) 赞(0)

回复 6 楼

静态Server-map和动态Server-map的生成方式虽然不同,但查询的时候两者都会查。

  • x
  • 常规:

点评 回复

l00738227
l00738227   发表于 2014-8-19 17:27:59 已赞(0) 赞(0)

那么,当配置nat server,为什么还要配置安全策略? 因为以我所知,配置nat server, 会生成静态server-map. 根据上面的规则,不需要安全策略都可以过。
  • x
  • 常规:

点评 回复

跃秀
跃秀  精英 发表于 2014-8-19 19:16:22 已赞(0) 赞(0)

引用 8 楼

兄弟,你好像看反了,静态server-map配置就会生成,但是记录匹配结果后,会继续走安全策略流程。

动态Server-map是由流量触发,一旦触发,后续的流量匹配都不走安全策略了。

 

那么,当配置nat server,为什么还要配置安全策略? 因为以我所知,配置nat server, 会生成静态server-map. 根据上面的规则,不需要安全策略都可以过。

l00738227 发表于 2014-08-19 17:27

  • x
  • 常规:

点评 回复

DoubleDong
DoubleDong   发表于 2014-9-18 15:32:45 已赞(0) 赞(0)

看完了,做标记!支持强叔,感觉又学到了好多东西!
  • x
  • 常规:

点评 回复

Y_GH
Y_GH   发表于 2014-8-8 16:13:23 已赞(0) 赞(0)

读完此文顿觉内功增进不少,任督二脉几近打通,难道离我练成如来神掌只差最后一步?

希望强叔助我一臂之力,早日练成神功!

  • x
  • 常规:

点评 回复

shadowboy
shadowboy   发表于 2014-8-8 16:21:26 已赞(0) 赞(0)

顶 强叔。。。。。。。。。

  • x
  • 常规:

点评 回复

wangbenlie
wangbenlie   发表于 2014-8-8 20:30:48 已赞(0) 赞(0)

感谢分享!
  • x
  • 常规:

点评 回复

123
返回列表
发表回复
您需要登录后才可以回帖 登录 | 注册

警告 内容安全提示:尊敬的用户您好,为了保障您、社区及第三方的合法权益,请勿发布可能给各方带来法律风险的内容,包括但不限于政治敏感内容,涉黄赌毒内容,泄露、侵犯他人商业秘密的内容,侵犯他人商标、版本、专利等知识产权的内容,侵犯个人隐私的内容等。也请勿向他人共享您的账号及密码,通过您的账号执行的所有操作,将视同您本人的行为,由您本人承担操作后果。详情请参看“隐私声明
如果附件按钮无法使用,请将Adobe Flash Player 更新到最新版本!
登录参与交流分享

登录参与交流分享

登录