智能安全策略技术白皮书
Copyright © 2022 新华三技术有限公司 版权所有,保留一切权利。
非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。
除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。
本文中的内容为通用性技术信息,某些信息可能不适用于您所购买的产品。
传统的防火墙的包过滤防护策略配置通常都是基于报文入接口、出接口配置,在复杂的组网环境中,基于接口的策略配置方式需要为每一个接口配置防护策略,给网络管理员带来了极大的负担,防护策略的维护工作量成倍增加,从而也增加了因为配置不当引入安全风险的概率。
图1 基于接口的包过滤
引入安全域的概念之后,安全管理员将安全需求相同的接口或IP地址进行分类(划分到不同的安全域),从而实现策略的分层管理,管理员只需要部署各安全域之间的防护策略即可。如果后续网络变化,只需要调整相关安全域内的接口,而防护策略不需要修改,不但简化了策略的维护复杂度,同时也实现了网络业务和安全业务的分离。
图2 安全域的划分
随着网络逐渐复杂,安全域的数量随着不同安全需求的出现越来越多,在每两个安全域间配置防护策略的工作量也变得庞大起来。此时智能安全策略(以下简称安全策略)的出现解决了该问题,它基于全局进行配置并立即生效,不需要再手动应用在某两个安全域间或某个接口上。从全局视角识别报文属性,通过多种维度过滤条件精准匹配报文,精细化全局管控报文转发。从而不仅大大降低了防护策略的配置难度,还可支持识别更多类型的报文属性并可引用DPI业务实现对报文内容的深度检测。
图3 基于全局应用的一体化智能安全策略
与包过滤、对象策略相比,安全策略具有如下优势:
· 与包过滤相比,安全策略不仅可以通过五元组对报文进行控制,还可以有效区分协议(如HTTP协议)上承载的不同应用(如基于网页的游戏、视频和购物),使网络管理更加精细和准确。
· 与对象策略相比,安全策略可以基于用户、终端、地区、URL过滤分类等属性对报文进行控制,使网络管理更加灵活。
· 可以通过在安全策略中引用DPI业务,实现对报文内容的深度检测,有效阻止病毒和黑客的入侵。
· 安全策略基于全局配置并生效,无需应用到域间或接口,配置灵活简洁。
· 安全策略扩展了丰富的易用性功能,如冗余分析、命中分析、宽泛策略分析等,帮助管理员更快速配置精细、合理的安全策略。
· 安全策略支持应用风险调优,对已配置的安全策略进行风险分析并支持一键自动调优消除风险。
安全策略对报文的控制是通过安全策略规则实现的,规则中可以设置匹配报文的过滤条件、处理报文的动作和对报文内容进行深度检测等功能。
每条规则中均可以配置多种过滤条件,具体包括:源安全域、目的安全域、源IP地址、源MAC地址、目的IP地址、用户、用户组、应用、应用组、终端、终端组、地区、地区组、URL过滤分类、VPN和服务。每种过滤条件中(除VPN外)均可以配置多个匹配项,比如源安全域过滤条件中可以指定多个源安全域等。
当报文与某条安全策略规则的过滤条件匹配成功后,将执行该规则所配置的动作,包括:放行和丢弃。
当报文与某条配置了DPI业务的安全策略规则匹配成功后,并且执行动作为放行,则需要对报文进行DPI深度报文检测,支持的DPI业务类型包括:Web应用防护、入侵防御、URL过滤、数据过滤、文件过滤、APT防御和防病毒。
安全策略组可以实现对安全策略规则的批量操作,例如批量启用、禁用、删除和移动安全策略规则。只有当安全策略规则及其所属的安全策略组均处于启用状态时,安全策略规则才能生效。
安全策略加速功能用来提高安全策略规则的匹配速度。当有大量用户同时通过设备新建连接时,若安全策略内包含大量规则,此功能可以提高规则的匹配速度,保证网络通畅。
每条安全策略规则均可配置其生效的时间段,仅当处于时间段指定的时间范围内时,该安全策略才会生效。
安全策略对报文的处理过程如下:
(1) 将报文的属性信息与过滤条件中的匹配项进行匹配。每种过滤条件的多个匹配项之间是或的关系,即报文与某一个过滤条件中的任意一项匹配成功,则报文与此过滤条件匹配成功;若报文与某一个过滤条件中的所有项都匹配失败,则报文与此过滤条件匹配失败。
(2) 若报文与某条规则中的所有过滤条件都匹配成功(用户与用户组匹配一项即可,应用与应用组匹配一项即可,终端与终端组匹配一项即可,源地区、源地区组、源IP地址与源MAC地址匹配一项即可,目的地区、目的地区组、目的IP地址匹配一项即可),则报文与此条规则匹配成功。若有一个过滤条件不匹配,则报文与此条规则匹配失败,报文继续匹配下一条规则。以此类推,直到最后一条规则,若报文还未与规则匹配成功,则设备会丢弃此报文。
(3) 若报文与某条规则匹配成功,则结束此匹配过程,并对此报文执行规则中配置的动作。
¡ 若规则的动作为“丢弃”,则设备会丢弃此报文;
¡ 若规则的动作为“允许”,则设备继续对报文做第4步处理;
(4) 若引用了DPI业务,则会对此报文进行DPI深度安全检测;若未引用DPI业务,则直接允许此报文通过。
安全策略对报文的处理流程如图4所示:
安全策略支持识别丰富的报文属性类型,具体包括:源/目的安全域、源/目的IP地址、源MAC地址、用户/用户组、应用/应用组、终端/终端组、地区/地区组、URL过滤分类、VPN和服务。
对于这些丰富的报文属性类型,安全策略是如何进行识别的呢?下面将对其进行一一介绍。
首先我们要知道,安全域是一个逻辑概念,是对一类具有共同特点的网络区域进行的逻辑划分。例如,我们可以将设备的某些接口划分到一个安全域,或者将某些网段划分到一个安全域。安全域的成员类型包括:
· 三层接口:包括三层以太网接口、三层以太网子接口和其它三层逻辑接口。在某个安全域下添加三层接口类型成员后,接口连接的网络区域将属于该安全域。
· 二层接口和VLAN:在某个安全域下添加二层接口和VLAN类型成员后,接口连接的并属于指定VLAN的网络区域将属于该安全域。
· VLAN:在某个安全域下添加VLAN类型成员后,指定VLAN的网络区域将属于该安全域。
· IPv4子网:在某个安全域下添加IPv4子网类型成员后,指定IPv4子网的网络区域将属于该安全域。
· IPv6子网:在某个安全域下添加IPv6子网类型成员后,指定IPv6子网的网络区域将属于该安全域。
· 服务链:在某个安全域下添加服务链类型成员后,指定服务链的网络区域将属于该安全域。
当报文根据不同成员类型,匹配到不同安全域时,匹配优先顺序从高到低依次为服务链->IP子网->接口及VLAN,匹配过程中,当匹配到某一成员类型后,将不再继续往下匹配。
当报文的源或目的属于某个安全域时,就可以在安全策略规则中配置源/目的安全域对该报文进行匹配和控制。需要注意的是配置安全域成员的属性仅在本设备上生效,设备本身属于Local安全域,且Local安全域不能添加成员。
报文的源/目的IP地址在对报文进行解封装时直接从报文中获取。
源MAC地址即报文发送端的MAC地址。根据不同情况,设备获知报文源MAC的方式如下:
· 若发送端和设备处于同一广播域,则设备上会存在发送端的ARP表项,从而根据报文源IP地址对比ARP表项获知报文源MAC地址。
· 若发送端和设备处于不同广播域,跨越三层网关相连,在需要在设备上配置跨三层MAC学习功能,向发送端的网关设备获取ARP表项,从而根据报文源IP地址对比ARP表项获知报文源MAC地址。
设备识别报文所属的用户有两种方式:
· 当网络接入用户完成身份验证,并成为在线用户,设备会记录在线用户的用户名和IP地址、MAC地址等信息,并与本地的身份识别用户账户和身份识别用户组进行关联,实现IP地址或MAC地址和用户的映射,即动态在线身份识别用户。
· 管理员也可以直接配置用户和IP地址或MAC地址的映射关系,便于无需认证的网络接入用户使用,即静态在线身份识别用户。
总结两种方式,即设备首先需要建立用户和IP地址或MAC地址的映射关系,然后再通过报文的源IP的地址或MAC地址查找报文所属的用户。
用户组即用户的集合,管理员可以将多个用户加入到一个用户组中进行批量配置和层级式管理。
由此可知IP地址、用户与用户组之间的关系如图5所示。
图5 IP地址与用户/用户组关系图
当安全策略配置了用户/用户组过滤条件,则会根据用户/用户组与IP地址的映射关系,匹配报文的源IP地址,从而基于用户/用户组对报文进行控制。
设备对应用的识别支持两种方式:PBAR(Port Based Application Recognition,基于端口的应用识别)和NBAR(Network Based Application Recognition,基于内容特征的应用识别)。
PBAR根据端口与应用的映射关系识别出报文所属的应用,并支持以下类型的映射关系:
· 预定义的端口与应用的映射关系:由系统预先定义,管理员可以根据实际需求进行修改。
· 自定义的端口与应用的映射关系:由管理员进行创建。
根据与应用进行映射的对象范围的不同,PBAR提供以下映射机制来维护和使用自定义的端口与应用映射关系:
· 通用端口映射:对于所有报文,建立自定义端口号和应用建立映射关系。例如:将53222端口映射为BitTorrent应用,这样所有目的端口是53222的报文将被识别为BitTorrent应用。
· 主机端口映射:对去往某些特定范围内主机的报文建立自定义端口号和应用的映射。例如:将目的地址为10.110.0.0/16网段的、使用53222端口的报文映射为BitTorrent应用报文。主机范围可以通过配置ACL或者指定主机地址、网段来确定。
主机端口映射还可以细分为如下类型:
¡ 基于ACL的主机端口映射:对于匹配指定ACL的报文,建立端口号与应用的映射关系;
¡ 基于网段的主机端口映射:对于目的地址为指定网段的报文,建立端口号与应用的映射关系;
¡ 基于IP地址的主机端口映射:对于目的地址为指定IP地址的报文,建立端口号与应用的映射关系。
以上端口映射配置对于同一个报文的生效优先级从高到低依次为:基于IP地址、基于网段、基于ACL、通用。而对于其中的每一类,指定传输层协议名称的配置优先级高于不指定传输层协议名称的配置。
NBAR提取应用报文的特征,通过将报文的内容与特征库中的规则进行匹配来识别报文所属的应用。
NBAR支持两种类型的应用:
· 预定义应用:由设备上的APR特征库中的NBAR规则定义。
· 自定义应用:由管理员手工配置的NBAR规则定义。
当终端流量(例如摄像头和各类传感器等向管理端发送采集到的数据)流经设备时,设备可以提取出终端信息(例如终端的厂商、型号、MAC地址等)与特征库进行比对,以识别发送报文的终端,进而通过安全策略对指定终端发送的报文进行控制。
终端组即终端的集合,管理员可以将多个终端加入到一个终端组中进行批量管理。
报文经过设备时,设备将通过报文中的源/目的IP地址获知该报文的来源地区和目的地区。IP地址与地区的映射关系支持从特征库获取也支持管理员手动配置。
地区包括预定义地区、自定义地区和未知地区:
· 预定义地区:通过设备中的地区特征库定义,包括国家、省和城市。
· 自定义地区:用户手动创建的地区,可用于表示预定义地区之外的其他地区范围,如某县/区、乡镇、街道等。通过将对应的IP地址加入自定义地区视图的方式实现。
· 未知地区:是特征库中一种特殊的地区类型,用于存放不确定所属地区的IP地址。
地区组即地区的集合,管理员可以将多个地区加入到一个地区组中进行批量管理。
图6 地区识别
URL过滤分类可以通过文本或正则表达式对URL中的主机名和URI进行匹配,从而将具有相似特征的URL进行归类。URL过滤分类的来源有两种:
· 预定义分类:根据设备中的URL过滤特征库自动生成,包含一些常见类型的URL类别。
· 自定义分类:由管理员手动配置,并添加URL匹配规则。
若用户访问的URL属于某个URL过滤分类,则可通过配置安全策略匹配该URL过滤分类对相应报文进行控制。
VPN实例又称为VRF(Virtual Routing and Forwarding,虚拟路由和转发)实例。安全策略可根据报文入接口VPN实例对报文进行控制。
安全策略可通过报文中的协议号、TCP/UDP/SCTP协议的源端口/目的端口、ICMP协议的消息类型/消息码等字段确定报文所对应的服务。
当其他设备与本设备的非管理接口连接(管理口默认放通流量,无需配置安全策略),并需要访问该设备(如对本设备进行Ping、Telnet、访问Web页面或FTP服务等),或者由其他设备首先发起连接请求的各类协议报文交互(如动态路由协议、VPN隧道建立等)。则必须配置安全策略,放行访问本设备的相应报文,否则将无法成功建立连接。如图7所示。
以位于Trust安全域的PC(10.1.1.10)通过HTTPS协议访问设备(10.1.1.1)的Web管理界面为例,需要配置如下安全策略规则。
表1 允许PC访问本设备Web的安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
服务 |
动作 |
httpslocalin |
Trust |
Local |
10.1.1.10 |
10.1.1.1 |
https |
pass |
需要配置安全策略放行设备本身流量的常见业务(关于这部分业务的支持情况,请以设备实际情况为准)及其方法如表2所示。
业务名称 |
Local安全域 |
OSPF/IS-IS/RIP/BGP |
作为源安全域和目的安全域分别配置安全策略规则 |
IPsec/SSL/L2TP/MPLS/GRE |
作为源安全域和目的安全域分别配置安全策略规则 |
DNS/DHCP/FTP(客户端) |
仅作为源安全域配置安全策略规则 |
DNS/DHCP/FTP(服务器) |
仅作为目的安全域配置安全策略规则 |
SSH/Telnet/Ping/Tracet(本机发起) |
仅作为源安全域配置安全策略规则 |
SSH/Telnet/SNMP/HTTP/HTTPS(访问本机) |
仅作为目的安全域配置安全策略规则 |
BFD |
作为源安全域和目的安全域分别配置安全策略规则 |
LB |
作为源安全域和目的安全域分别配置安全策略规则 |
当本设备的非管理接口与其他设备连接,并需要主动访问其他设备(如对其他设备进行Ping、Telnet、访问FTP服务等),或者由本设备首先发起连接的各类协议交互(如动态路由协议、VPN隧道建立等)。则必须配置安全策略,放行本设备发出的相应报文,否则将无法成功建立连接。如图8所示。
以本设备(10.1.1.1)访问位于Trust安全域的FTP Server(10.1.1.20)的FTP服务为例,需要配置如下安全策略规则。
表3 允许本设备访问FTP Server的安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
服务 |
动作 |
ftplocalout |
Local |
Trust |
10.1.1.1 |
10.1.1.20 |
ftp |
pass |
对于仅需要本设备进行转发的流量,即经过本设备报文的源和目的均非设备本身,则必须配置安全策略,放行经过本设备的相应报文,否则将无法成功转发报文。如图9所示。
以位于Trust安全域的PC(10.1.1.10)通过HTTP协议访问位于Untrust安全域的外网网站为例,需要配置如下安全策略规则。
表4 允许PC访问外网网站的安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
服务 |
动作 |
trust-untrust |
Trust |
Untrust |
10.1.1.10 |
http |
pass |
安全策略冗余分析可以通过分析安全策略中的过滤条件识别出冗余的规则,从而有利于达到精简策略的目的。
设备会将高优先级的规则依次与低优先级的规则进行遍历比较,只要符合以下两种情况的任意一种,则认定为冗余:
· 所有过滤条件完全相同的安全策略规则,则低优先级的安全策略规则会被认定为冗余。
· 安全策略规则A的所有过滤条件被安全策略规则B完全包含,且安全策略规则A的优先级低于安全策略规则B,则安全策略规则A会被认定为冗余。
策略冗余分析可以在没有流量经过设备时进行分析,因此该功能可以在安全策略配置完成后立即进行。在冗余分析结果中修改安全策略配置后,设备会自动再次进行策略冗余分析,以便使冗余分析结果更加准确。
图10 策略冗余分析
安全策略命中分析功能可以分析出指定时间段内的安全策略规则是否被命中过,以帮助管理员对设备上的安全策略进行深度分析和处理。
安全策略规则未被命中的原因有如下两种:
· 流量不符合安全策略规则的过滤条件,即过滤条件配置不正确或不合理。
· 安全策略规则之间存在深度冗余,例如IP地址和用户的冗余、应用和服务的冗余等。这样会由于高优先级的策略被命中,而导致低优先级的策略未命中。
图11 策略命中分析
应用风险调优功能通过应用层检测引擎智能分析安全策略允许通过的流量中存在的潜在风险,为设备中所有安全策略的安全系数进行总体评估。总体安全评分越高表示安全策略的安全系数越高,相反评分越低表示存在的风险越大。
管理员可以根据应用风险分析结果对安全策略中的应用配置相应的防护,以此调优安全策略,设备支持如下两种调优方式:
· 自动批量调优:会将设备中所有待调优的安全策略,按照设备默认的安全策略调优规则进行策略调优,此方式比较方便快捷。
· 手工逐条调优:可以对设备中待调优的每条安全策略进行单独调优,此方式适用于对安全策略进行灵活调优。
图12 应用风险调优
在配置安全策略时,一般建议配置严谨、细粒度的安全策略规则,以达到报文的精细化控制。但当无法确定需要放行或阻断的报文属性时,只能先配置较宽泛的报文匹配规则以保证业务的正常转发。此时可以通过宽泛策略分析功能,对匹配安全策略规则的报文进行学习并记录报文属性。然后查看学习结果,从而根据学习结果筛选、分析需要放行或阻断的报文属性,制定更精细化的安全策略。
图13 宽泛策略分析
如图14所示,某公司共包括President、Market和Finance三个部门,各部门之间通过Device实现互连,同时也通过Device作为网关连接Internet。通过配置安全策略,实现如下需求:
· 允许President访问所有网络资源。
· 允许Finance部门的员工仅能访问Internet的优酷视频应用。
· 允许Market部门的员工访问Internet的具体限制如下:
¡ 即时通讯类型的资源仅允许使用微信。
¡ 不能玩游戏、不能访问流媒体类型的资源。
¡ 除了以上几条具体限制需求之外的资源都允许访问。
首先将Device的GE1/0/1接口连接的Internet区域划分至Untrust安全域,将GE1/0/2接口连接的President部门划分至President安全域,将GE1/0/3接口连接的Finance部门划分至Finance安全域,将GE1/0/4接口连接的Market部门划分至Market安全域。
然后配置放行President访问所有网络资源的安全策略。具体策略为:
表5 President部门报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
动作 |
president-any |
Trust |
Any |
10.0.12.0/24 |
Any |
pass |
配置放行Finance部门的员工访问Internet上优酷视频应用的安全策略,以及阻断访问其他资源的安全策略。具体策略为:
表6 Finance部门报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
应用 |
动作 |
finance-youku |
Finance |
Untrust |
10.0.11.0/24 |
YouKu |
pass |
finance-other |
Finance |
Any |
10.0.11.0/24 |
Any |
drop |
创建通讯类、游戏类、流媒体类应用组,并将相应的应用加入应用组中。
配置放行Market部门的员工访问Internet上微信应用的安全策略,再配置阻断访问其他通讯类、游戏类、流媒体类应用的安全策略,最后配置放行访问其他所有应用的安全策略。具体策略为:
表7 Market部门报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
应用/应用组 |
动作 |
market-wechat |
Market |
Untrust |
10.0.10.0/24 |
|
pass |
market-untrust |
Market |
Untrust |
10.0.10.0/24 |
通讯类、游戏类、流媒体类 |
drop |
market-other |
Market |
Untrust |
10.0.10.0/24 |
Any |
pass |
如图15所示,Device A和Device B运行OSPF路由协议,并将整个自治系统划分为3个区域:Area 0、Area 1和Area 2。Device A和Device B作为ABR转发区域之间的路由。在该组网场景下,需要规划安全域和安全策略,保证Device A和Device B两台设备OSPF邻居关系的正常建立、路由正常学习,以及Area 1区域和Area 2区域网络的互相访问,并最大程度保证安全策略放行报文的严谨性。
首先规划网络的安全域:
· Device A将GE1/0/1接口连接的区域划分至Untrust安全域,将GE1/0/2接口连接的区域划分至Trust安全域。
· Device B将GE1/0/1接口连接的区域划分至Untrust安全域,将GE1/0/2接口连接的区域划分至Trust安全域。
然后配置保证Device A和Device B两台设备OSPF邻居关系正常建立、路由正常学习的安全策略:
· 在Device A上,要保证与Device B之间OSPF协议报文的互通,即放行Device A向Device B发送的OSPF协议报文以及Device A从Device B接收的OSPF协议报文。具体策略为:
表8 Device A放行OSPF协议报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
服务 |
动作 |
ospflocalout |
Local |
Untrust |
1.1.1.1 |
1.1.1.2 |
ospf |
pass |
ospflocalin |
Untrust |
Local |
1.1.1.2 |
1.1.1.1 |
ospf |
pass |
· 在Device B上,则同样要保证与Device A之间OSPF协议报文的互通,即放行Device B向Device A发送的OSPF协议报文以及Device B从Device A接收的OSPF协议报文。具体策略为:
表9 Device B放行OSPF协议报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
服务 |
动作 |
ospflocalout |
Local |
Untrust |
1.1.1.2 |
1.1.1.1 |
ospf |
pass |
ospflocalin |
Untrust |
Local |
1.1.1.1 |
1.1.1.2 |
ospf |
pass |
最后需要配置保证Area 1区域和Area 2区域网络互相访问的安全策略:
· 在Device A上,需要放行由Area 1区域发往Area 2区域的报文,也需要放行由Area 2区域发往Area 1区域的报文。具体策略为:
表10 Device A放行业务报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
动作 |
trust-untrust |
Trust |
Untrust |
2.2.2.0 |
3.3.3.0 |
pass |
untrust-trust |
Untrust |
Trust |
3.3.3.0 |
2.2.2.0 |
pass |
· 在Device B上,则同样需要放行由Area 1区域发往Area 2区域的报文,也需要放行由Area 2区域发往Area 1区域的报文。具体策略为:
表11 Device B放行业务报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
动作 |
untrust-trust |
Untrust |
Trust |
2.2.2.0 |
3.3.3.0 |
pass |
trust-untrust |
Trust |
Untrust |
3.3.3.0 |
2.2.2.0 |
pass |
如图16所示,内部网络用户10.110.10.8/24使用外网地址202.38.1.100访问Internet中的地址为201.20.1.1/24的 Server,Device需要在转发报文时将源内网地址转换为外网地址。在该组网场景下,需要配置安全策略保证IP地址的正常转换和报文正常转发。
图16 NAT源地址转换组网
首先将Device的GE1/0/1接口连接的区域划分至Trust安全域,将GE1/0/2接口连接的区域划分至Untrust安全域。
然后配置安全策略,放行内网主机访问外网Server的安全策略。由于源地址转换在安全策略处理后完成,所以配置安全策略时,指定的源地址应为转换前的内网地址。具体策略为:
表12 Device放行业务报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
动作 |
trust-untrust |
Trust |
Untrust |
10.110.10.8 |
201.20.1.1 |
pass |
如图16所示,公司内部对外提供Web服务,Web服务器地址为10.110.10.2/24。外网主机需要通过外网地址202.38.1.2访问内网的Web服务器。在该组网场景下,需要配置安全策略保证IP地址的正常转换和报文正常转发。
图17 NAT目的地址转换组网
首先将Device的GE1/0/1接口连接的区域划分至Trust安全域,将GE1/0/2接口连接的区域划分至Untrust安全域。
然后配置安全策略,放外网主机访问内网Web server的安全策略。由于目的地址转换在安全策略处理前完成,所以配置安全策略时,指定的目的地址应为转换后的内网地址。具体策略为:
表13 Device放行业务报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
动作 |
untrust-trust |
Untrust |
Trust |
200.1.1.3 |
10.110.10.2 |
pass |
如图18所示,在Device A和Device B之间建立一条IPsec隧道,对Host A所在的子网(10.1.1.0/24)与Host B所在的子网(10.1.2.0/24)之间的数据流进行安全保护。在该组网场景下,需要配置安全策略保证IPsec隧道正常建立以及数据流正常转发。
首先规划网络的安全域:
· Device A将GE1/0/1接口连接的区域划分至Trust安全域,将GE1/0/2接口连接的区域划分至Untrust安全域。
· Device B将GE1/0/1接口连接的区域划分至Trust安全域,将GE1/0/2接口连接的区域划分至Untrust安全域。
然后配置保证Device A和Device B两台设备IPsec隧道正常建立的安全策略:
· 在Device A上,要保证与Device B之间IPsec协商报文的互通,即放行Device A向Device B发送的IPsec协商报文以及Device A从Device B接收的IPsec协商报文。具体策略为:
表14 Device A放行IPsec协商报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
服务 |
动作 |
ipseclocalout |
Local |
Untrust |
2.2.2.1 |
2.2.3.1 |
ike、ipsec-ah、ipsec-esp |
pass |
ipseclocalin |
Untrust |
Local |
2.2.3.1 |
2.2.2.1 |
ike、ipsec-ah、ipsec-esp |
pass |
· 在Device B上,则同样要保证与Device A之间IPsec协商报文的互通,即放行Device B向Device A发送的IPsec协商报文以及Device B从Device A接收的IPsec协商报文。具体策略为:
表15 Device B放行IPsec协商报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
服务 |
动作 |
ipseclocalout |
Local |
Untrust |
2.2.3.1 |
2.2.2.1 |
ike、ipsec-ah、ipsec-esp |
pass |
ipseclocalin |
Untrust |
Local |
2.2.2.1 |
2.2.3.1 |
ike、ipsec-ah、ipsec-esp |
pass |
最后需要配置保证Host A所在子网和Host B所在子网互相访问的安全策略:
· 在Device A上,需要放行由Host A所在子网发往Host B所在子网的报文,也需要放行由Host B所在子网发往Host A所在子网的报文。具体策略为:
表16 Device A放行业务报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
动作 |
trust-untrust |
Trust |
Untrust |
10.1.1.0/24 |
10.1.2.0/24 |
pass |
untrust-trust |
Untrust |
Trust |
10.1.2.0/24 |
10.1.1.0/24 |
pass |
· 在Device B上,则同样需要放行由Host A所在子网发往Host B所在子网的报文,也需要放行由Host B所在子网发往Host A所在子网的报文。具体策略为:
表17 Device B放行业务报文安全策略规则
规则名称 |
源安全域 |
目的安全域 |
源IP地址 |
目的IP地址 |
动作 |
untrust-trust |
Untrust |
Trust |
10.1.1.0/24 |
10.1.2.0/24 |
pass |
trust-untrust |
Trust |
Untrust |
10.1.2.0/24 |
10.1.1.0/24 |
pass |