欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

【转】华为防火墙报文处理流程简介

作者:易隐者 发布于:2014-11-25 22:42 Tuesday 分类:参考资料

【原帖作者】:强叔侃墙

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

【原帖链接】:http://support.huawei.com/ecommunity/bbs/10225529.html

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

 

在《华为防火墙产品一览》中,强叔曾介绍:华为出品低、中、高端共三个系列防火墙,对应当前的主力产品型号分别为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表中的信息。



(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。
某公司分部与总部互联组网和关键配置如下,其中HTTP Server无法访问分部资源,而其他通信完全正常。


分析:防火墙上涉及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不再生效。这个问题的解决办法是,配置NAT Server时增加no-reverse参数,要求不生成反向Server-map表,这样总可以继续查询NAT策略,使该HTTP Server可以正常访问分部资源。
结论:上述报文处理流程第3阶段时已进行提醒,进行源NAT处理时,注意报文在前面流程中是否命中了Server-map表,尤其不要忽略反向Server-map表,如果已经命中,此时源NAT处理不会再生效。

 

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

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

阅读全文>>

标签: 防火墙 报文处理流程 华为防火墙 状态监测 华为

评论(0) 引用(0) 浏览(13951)

【转】交换机端口镜像,如何配置多个观察口

作者:易隐者 发布于:2012-12-27 12:40 Thursday 分类:参考资料

 

【说在之前】:

1,H3C和华为等多系列交换机均不支持多组镜像和多镜像监听口,这给有IDS、审计、网络分析等多种需要通过镜像采集流量的设备环境造成了诸多不便;

2,前段时间刚在用户故障现场发现有人使用交换机内回环巧妙实现了在H3C交换机环境下的多个监听采集需求,回来后一直想把这个方法写下来,只是在网上找了非常多的资料,均未有详细的说明,便耽搁下来,没想到今天就有人把这种方法整理了出来,实在巧合,正好转载于此,供大家参考;

3,这种镜像的方式,是否会导致报文被多次重复捕获?这是一个有待验证的问题,因为我们上次在用户现场发现通过这种方式镜像捕获的报文中有许多是重复捕获的,有试验环境的兄弟可以做一个详细的实验,拿出来供大家分享。

【原文连接】:

   http://support.huawei.com/ecommunity/bbs/10152503.html

【原文作者】:

   huang8880

【原文全文】:

实现原理:将所有端口镜像报文引入一个观察端口,通过观察端口内部环回(配置loopback internal),将报文在vlan内广播道其它若干实际观察端口,报文出端口时剥除vlan id

配置举例:

预留vlan3500for example

#
vlan batch 3 10 20 100 300 to 301 3000 to 3002 3500 4000
#

观察端口

#
observe-port 1 interface GigabitEthernet0/0/21 vlan 3500
#

三个镜像端口:

#
interface GigabitEthernet0/0/3
port-mirroring to observe-port 1 both
#
interface GigabitEthernet0/0/4
port-mirroring to observe-port 1 both
#
interface GigabitEthernet0/0/5
port-mirroring to observe-port 1 both
#

三个观察端口:

#
interface GigabitEthernet0/0/11
port link-type trunk
undo port trunk allow-pass vlan 1
port trunk allow-pass vlan 3500
#
interface GigabitEthernet0/0/12
port link-type trunk
undo port trunk allow-pass vlan 1
port trunk allow-pass vlan 3500
#
interface GigabitEthernet0/0/13
port link-type trunk
undo port trunk allow-pass vlan 1
port trunk allow-pass vlan 3500
#
环回端口:
#
interface GigabitEthernet0/0/21
description neibuhuanhui
loopback internal
mac-address learning disable
port link-type trunk
undo port trunk allow-pass vlan 1
port trunk allow-pass vlan 3500
stp disable


注意:如果交换机全局配置stp enable,需要在环回端口上配置stp disable,否则该端口如果接收到交换机自己发出去的stp报文,会将端口置为discarding状态,环回报文都会在入向被丢弃

阅读全文>>

标签: 端口镜像 交换机 环回接口 loopback

评论(0) 引用(0) 浏览(19595)

H3C IPSEC VPN报文处理流程

作者:易隐者 发布于:2012-11-22 9:21 Thursday 分类:参考资料

       IPSEC VPN报文在设备中的处理流程不同的厂家或许会有些微的差异,但是大致流程应该都差不多,网上找到H3C IPSEC VPN报文的处理流程图两张如下:

点击查看原图

H3C IPSEC VPN入站报文处理流程图

点击查看原图

H3C IPSEC VPN出站报文处理流程图

阅读全文>>

标签: 报文处理流程 H3C IPSEC VPN

评论(2) 引用(0) 浏览(12321)

天融信防火墙报文处理流程

作者:易隐者 发布于:2012-11-21 13:12 Wednesday 分类:参考资料

       天融信作为国内知名的防火墙品牌,其拥有巨大的用户群体,因此天融信防火墙也是在实际工作环境中最为常见的防火墙之一,天融信防火墙的报文处理流程如下图所示:

点击查看原图

阅读全文>>

标签: 天融信 防火墙 报文处理流程

评论(0) 引用(0) 浏览(7227)

交换机内部报文处理流程

作者:易隐者 发布于:2012-11-20 21:05 Tuesday 分类:参考资料

       交换机作为网络基础设施中不可或缺的组成部分,是最为常见的中间设备之一,其内部报文的处理流程如下图所示:

点击查看原图

       此图来自于互联网,仅供大家参考。

阅读全文>>

标签: 交换机 中间设备 报文 报文处理流程

评论(0) 引用(0) 浏览(8055)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1