安全域

特性简介

安全域

安全域是一个逻辑概念，用于管理设备上安全需求相同的多个接口。管理员将安全需求相同的接口进行分类，并划分到不同的安全域，统一应用安全策略，简化配置，方便管理。

管理员创建安全域后，可以给安全域添加多个成员，成员的类型包括：二层物理接口加VLAN、三层物理接口/三层以太网子接口/其它三层逻辑接口。

配置安全域后，设备上各接口的报文转发遵循以下规则：

一个安全域中的接口与一个不属于任何安全域的接口之间的报文，会被丢弃。

属于同一个安全域的各接口之间的报文缺省会被丢弃。

安全域之间的报文由安全策略进行安全检查，并根据检查结果放行或丢弃。若安全策略不存在或不生效，则报文会被丢弃。

非安全域的接口之间的报文会被丢弃。

目的地址或源地址为本机的报文，缺省会被丢弃，若该报文与安全策略匹配，则由安全策略进行安全检查，并根据检查结果放行或丢弃。

攻击防范

攻击防范是一个重要的网络安全特性，它通过分析经过设备的报文的内容和行为，判断报文是否具有攻击特征，并根据配置对具有攻击特征的报文执行一定的防范措施。

攻击防范策略用于定义一个或多个用于检测攻击的特征项，以及对检测到的攻击报文所采取的防范措施，例如输出告警日志、丢弃报文、加入黑名单或进行客户端验证。设备可以支持定义用于扫描攻击防范、泛洪攻击防范和单包攻击防范的策略。

攻击防范策略应用在安全域上，对安全域上收到的报文生效。

威胁防护

客户端验证功能用来防御服务器受到的TCP、HTTP、SIP、DNS、HTTPS类型的泛洪攻击。启动了客户端验证功能的设备，位于客户端和服务器之间，能够对客户端发起的连接进行验证，当检测到服务器受到攻击时，将服务器的IP地址添加为动态受保护的IP地址，并对所有向该服务器发起的报文进行验证，从而达到保护服务器免受各种泛洪攻击的目的。

uRPF

uRPF简介

uRPF（unicast Reverse Path Forwarding，单播反向路径转发）是一种单播逆向路由查找技术，用来防范基于源地址欺骗的攻击手段，例如基于源地址欺骗的DoS（Denial of Service，拒绝服务）攻击和DDoS（Distributed Denial of Service，分布式拒绝服务）攻击。

对于使用基于IP地址验证的应用来说，基于源地址欺骗的攻击手段可能导致未被授权用户以他人身份获得访问系统的权限。因此即使响应报文没有发送给攻击者或其它主机，此攻击方法也可能会造成对被攻击对象的破坏。

图-1 源地址欺骗攻击示意图

如图-1所示，攻击者在Device A上伪造并向Device B发送大量源地址为2.2.2.1的报文，Device B响应这些报文并向真正的“2.2.2.1”（Device C）回复报文。因此这种非法报文对Device B和Device C都造成了攻击。如果此时网络管理员错误地切断了Device C的连接，可能会导致网络业务中断甚至更严重的后果。

攻击者也可以同时伪造不同源地址的攻击报文或者同时攻击多个服务器，从而造成网络阻塞甚至网络瘫痪。

uRPF可以有效防范上述攻击。一般情况下，设备在收到报文后会根据报文的目的地址对报文进行转发或丢弃。而uRPF可以在转发表中查找报文源地址对应的接口是否与报文的入接口相匹配，如果不匹配则认为源地址是伪装的并丢弃该报文，从而有效地防范网络中基于源地址欺骗的恶意攻击行为的发生。

uRPF检查方式

uRPF检查方式有严格型和松散型两种。

• 严格型uRPF检查

不仅检查报文的源地址是否在转发表中存在，而且检查报文的入接口与转发表是否匹配。

在一些特殊情况下（如非对称路由，即设备上行流量的入接口和下行流量的出接口不相同），严格型uRPF检查会错误地丢弃非攻击报文。

一般将严格型uRPF检查布置在ISP的用户端和ISP端之间。

• 松散型uRPF检查

仅检查报文的源地址是否在转发表中存在，而不再检查报文的入接口与转发表是否匹配。

松散型uRPF检查可以避免错误的拦截合法用户的报文，但是也容易忽略一些攻击报文。

一般将松散型uRPF检查布置在ISP-ISP端。另外，如果用户无法保证路由对称，可以使用松散型uRPF检查。

uRPF技术优点

• 与缺省路由的配合使用

  当设备上配置了缺省路由后，会导致uRPF根据转发表检查源地址时，所有源地址都能查到下一跳。针对这种情况，支持用户配置uRPF是否允许匹配缺省路由。如果允许匹配缺省路由，则当uRPF查询转发表得到的结果是缺省路由时，认为查到了匹配的表项；如果不允许匹配缺省路由，则当uRPF查询转发表得到的结果是缺省路由时，认为没有查到匹配的表项。

  缺省情况下，如果uRPF查询转发表得到的结果是缺省路由，则按没有查到表项处理，丢弃报文。

  运营商网络边缘位置一般不会有缺省路由指向客户侧设备，所以一般不需要配置“允许匹配缺省路由”。如果在客户侧边缘设备接口上面启用uRPF，这时往往会有缺省路由指向运营商，此时需要配置“允许匹配缺省路由”。

• 与链路层检查配合使用（仅IPv4 uRPF支持）

  严格型uRPF检查中还可以进一步进行链路层检查，即用源地址查转发表得到的下一跳地址再查一次ARP表，确保报文的源MAC地址和查到的ARP表项中的MAC地址一样才允许报文通过。

  链路层检查功能对于运营商用一个三层以太网接口接入大量PC机用户时部署非常合适。

  松散型uRPF检查不支持链路层检查功能。

• 与ACL的配合使用

  如果用户确认具有某些特征的报文是合法报文，则可以在ACL中指定这些报文，那么这些报文在逆向路由不存在的情况下，不做丢弃处理，按正常报文进行转发。

IPv4 uRPF处理流程

图-2 IPv4 uRPF处理流程图

1. 检查地址合法性：

   • 对于目的地址是组播地址的报文，直接放行。

   • 对于源地址是全零地址的报文，如果目的地址是广播，则放行（源地址为0.0.0.0，目的地址为255.255.255.255的报文，可能是DHCP或者BOOTP报文，不做丢弃处理）；如果目的地址不是广播，则进入步骤7。

   • 对于不是上述情况的报文，则进入步骤2。

2. 检查报文的源地址在转发表中是否存在匹配的单播路由：如果在转发表中查找失败（源地址是非单播地址则会匹配到非单播路由），则进入步骤7，否则进入步骤3；

3. 如果转发表中匹配的是上送本机路由，即查到InLoop接口，则检查报文入接口是否是InLoop接口：如果是，则直接放行，否则进入步骤7；如果转发表中匹配的不是上送本机路由则继续步骤4；

4. 如果转发表中匹配的是缺省路由，则检查用户是否配置了允许匹配缺省路由：如果没有配置，则进入步骤7，否则进入步骤5；如果转发表中匹配的不是缺省路由，则进入步骤5；

5. 检查报文源地址与入接口是否匹配。反向查找报文出接口（反向查找是指查找以该报文源IP地址为目的IP地址的报文的出接口）或者缺省路由的出接口：如果其中至少有一个出接口和报文的入接口相匹配，则进入步骤6；如果不匹配，则查看是否是松散型检查，如果是，则报文检查通过，进入步骤7；否则说明是严格型检查，进入步骤6；

6. 检查用户是否配置了对链路层信息进行检查：如果没有配置，则认为报文通过检查，进行正常的转发。如果已经配置，则根据转发表中的下一跳查询ARP表，并比较IP报文源MAC地址与ARP表中的MAC地址是否一致。如果两者一致，则报文通过检查；如果查询失败或两者不一致，则进入步骤7；

7. ACL检查流程。如果报文符合ACL，则报文继续进行正常的转发（此类报文称为被抑制丢弃的报文）；否则报文被丢弃。

IPv6 uRPF处理流程

图-3 IPv6 uRPF处理流程图

1. 检查地址合法性：对于目的地址是组播地址的报文直接放行。否则，进入步骤2；

2. 检查报文的源地址在IPv6转发表中是否存在匹配的单播路由：如果在IPv6转发表中查找失败（源地址是非单播地址则会匹配到非单播路由），则进入步骤6，否则进入步骤3；

3. 如果IPv6转发表中匹配的是上送本机路由，则检查报文入接口是否是InLoop接口：如果是，则直接放行，否则进入步骤6；如果IPv6转发表中匹配的不是上送本机路由则继续步骤4；如果源地址是Link-Local地址，倘若这个地址是入接口的地址，并且入接口不是InLoop接口则进入步骤6，否则直接放行；

4. 检查报文源地址与入接口是否匹配：反向查找报文出接口（反向查找是指查找以该报文源IPv6地址为目的IPv6地址的报文的出接口）或者缺省路由的出接口，如果其中至少有一个出接口和报文的入接口相匹配，则进入步骤5；如果不匹配，则查看是否是松散型检查，如果是，则进入步骤5，否则说明是严格型检查，进入步骤6；

5. 如果IPv6转发表中匹配的是缺省路由，则检查用户是否配置了允许匹配缺省路由，如果没有配置，则进入步骤6，否则处理结束报文正常转发；如果IPv6转发表中匹配的不是缺省路由，则处理结束报文正常转发；

6. IPv6 ACL检查流程。如果报文符合IPv6 ACL，则报文继续进行正常的转发（此类报文称为被抑制丢弃的报文）；否则报文被丢弃。

uRPF典型组网应用

图-4 uRPF典型组网应用

通常在ISP上配置uRPF，在ISP与用户端，配置严格型uRPF检查，在ISP与ISP端，配置松散型uRPF检查。

如果有特殊用户，或者具有一定特征，需要特殊处理的报文，可以配置ACL规则。

白名单

白名单功能即将特定的源IP地址加入白名单后，设备对于该地址发送的报文会跳过安全检查，而直接按照正常的转发流程进行处理，从而实现了报文的高速转发。

白名单不能直接指定IP地址，而需要通过引用地址对象组将IP地址加入白名单。白名单只能引用一个地址对象组，且只能由用户手工添加或删除。

使用限制和注意事项

• 设备管理口缺省属于Management安全域，用户可以通过该接口登录Web管理页面管理设备，若移出Management安全域，则会立即断开Web访问，无法远程管理设备。

• 同一个三层接口只允许加入一个安全域。

• 同一个“二层接口和VLAN”的组合只能加入到一个安全域中。

• 当报文未匹配对应安全域间实例时，若存在any到any的安全域间实例，则匹配any到any安全域间实例，否则直接丢弃报文。

• Management和Local安全域间之间的报文缺省会被允许。

• Management和Local安全域间之间的报文只能匹配Management与Local之间的安全域间实例，不会匹配any到any的安全域间实例。

配置指南

配置思路

安全域的配置思路如下图所示。

图-5 安全域配置指导图

创建安全域

安全域是一个逻辑概念，管理员将安全需求相同的接口进行分类，并划分到不同的安全域，能够实现域间策略的统一管理。可以通过域间策略实现对报文流的检查，并根据检查结果对报文执行相应动作。

1. 单击“网络 > 安全域”。

2. 在“安全域”页面单击<新建>按钮，进入新建安全域页面。

3. 新建安全域，具体配置内容如下：

   图-6 新建安全策略

   

   表-1 安全域配置

   参数	说明
   安全域名称	表示安全域的名称
   VLAN成员列表	配置安全域的VLAN成员
   二层成员列表	配置安全域的二层接口成员
   三层成员列表	配置安全域的三层接口成员
   攻击防范策略	配置安全域执行的攻击防范策略
   白名单	配置安全域是否开启白名单功能
   TCP客户端验证	在指定安全域上开启/关闭TCP客户端验证功能，包括： 关闭：关闭TCP客户端验证 SYN Cookie：开启双向代理模式的TCP客户端验证 Safe Reset：开启单向代理模式的TCP客户端验证
   DNS客户端验证	在指定安全域上开启/关闭DNS客户端验证功能
   DNS reply验证	在指定安全域上开启/关闭DNS reply验证功能
   HTTP客户端验证	在指定安全域上开启/关闭HTTP客户端验证功能
   HTTPS客户端验证	在指定安全域上开启/关闭HTTPS客户端验证功能
   SIP客户端验证	在指定安全域上开启/关闭SIP客户端验证功能
   IPv4 uRPF	滑动开启，并进行IPv4 uRPF配置
   IPv6 uRPF	滑动开启，并进行IPv6 uRPF配置
   检查方式	严格方式：不仅检查报文的源地址是否在转发表中存在，而且检查报文的入接口与转发表是否匹配 松散方式：仅检查报文的源地址是否在转发表中存在，而不再检查报文的入接口与转发表是否匹配
   例外规则	访问控制列表，用来抑制报文丢弃 可选择已创建的IPv4 ACL，也可以新创建IPv4 ACL。此处新建的IPv4 ACL，可在“对象 > ACL > IPv4”页面查看
   允许匹配缺省路由	允许源地址查转发表时匹配缺省路由表项
   开启链路层检查功能	允许对链路信息进行检查

4. 单击<确定>按钮，新建安全域成功，并会在安全域页面中显示。

（可选）创建白名单

通过配置白名单功能可以使来自指定IP地址的报文跳过设备的安全检查。

白名单只能通过引用地址对象组进行添加，当一个IP地址加入白名单后，直到用户手工将其删除，否则一直存在。地址对象组在“对象 > 对象组”页面配置。

1. 单击“网络 > 安全域 > 白名单”。

2. 在“白名单”页面单击<新建>按钮。

3. 手工添加白名单，具体配置内容如下：

   图-7 新建白名单

   

   表-2 白名单配置

   参数	说明
   对象组类型	IPv4 IPv6
   对象组名称	可以选择已创建的地址对象组，也可以新创建地址对象组。此处新建的地址对象组，可在“对象 > 对象组”页面查看

4. 单击<确定>按钮，新建的白名单会在“白名单”页面显示。

（可选）配置客户端验证功能

通过手工添加受客户端验证保护的IP地址，对向该目的地址发送的连接请求进行代理。

受保护IP除了可以手工添加之外，还可以通过泛洪攻击防范自动添加。具体来讲就是，在客户端验证功能使能的前提下，若配置了泛洪攻击防范策略及相应的客户端验证功能，则设备检测到某服务器受到了指定类型的攻击时，设备会将该服务器IP地址添加到受保护IP列表中，并对后续指定类型的报文进行合法性检查。

1. 单击“网络 > 安全域 > 客户端验证”。

2. 在“客户端验证”页面单击<新建>按钮。

3. 新建客户端验证，具体配置内容如下：

   图-8 新建客户端验证

   

   表-3 受保护IP配置

   参数	说明
   协议类型	客户端验证的协议类型，包括： TCP：TCP客户端验证功能 DNS：DNS客户端验证功能 DNS reply：DNS reply验证功能 HTTP：HTTP客户端验证功能 HTTPS：HTTPS客户端验证功能 SIP：SIP客户端验证功能
   VRF	受客户端验证保护的IP地址所属的VPN实例 可选择已创建的VRF，也可以新创建VRF。此处新建的VRF，可在“网络 > VRF”页面查看
   IP地址类型	IPv4 IPv6
   IP地址	受客户端验证保护的IP地址，即会对向该目的地址发送的连接请求进行代理 对于受TCP客户端验证保护的IP地址，发送的是TCP连接请求；对于受DNS客户端验证保护的IP地址，发送的是DNS query请求；对于受HTTP客户端验证保护的IP地址，发送的是HTTP GET/POST连接请求；对于受HTTPS客户端验证保护的IP地址，发送的是HTTPS请求；对于受SIP客户端验证保护的IP地址，发送的是UDP类型的INVITE请求
   端口号	受客户端验证保护的端口号。缺省情况下，对于DNS客户端验证的受保护IP，则表示对端口53的DNS query连接请求做代理；对于HTTP客户端验证的受保护IP，则表示对端口80的HTTP GET/POST连接请求做代理；对于HTTPS客户端验证的受保护IP，则表示对端口443的HTTPS请求做代理；对于SIP客户端验证的受保护IP，则表示对端口5060的INVITE连接请求进行代理；对于TCP客户端验证的受保护IP，则表示对所有端口的TCP连接请求做代理

4. 单击<确定>按钮，新建的客户端验证会在“客户端验证”页面显示，该页面还会显示泛洪攻击防范自动添加的客户端验证。