安全策略的基本原理

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Content translations are temporarily unavailable due to site maintenance. We apologize for any inconvenience. Visit our blog to learn more.

L2 Linker
No ratings

解决方案

目录

 

概述

本文件描述了Palo Alto Networks防火墙上安全策略的基本原理。

 

所有穿越Palo Alto Networks防火墙数据平面的流量都与安全策略相匹配。这不包括来自防火墙管理界面的流量,因为在默认情况下,这种流量不会通过防火墙的数据平面。防火墙上的安全策略可以使用各种标准来定义,如区域、应用、IP地址、端口、用户和HIP配置文件。防火墙管理员可以定义安全策略以允许或拒绝流量,从区域作为广泛的标准开始,然后用更细化的选项如端口、应用程序和HIP配置文件来微调策略。

 

两种安全策略

 

防火墙有两种安全策略。

 

  1. 显性安全策略由用户定义,在CLI和Web-UI界面上可见。
  2. 隐式安全策略是用户通过CLI界面或Web-UI界面不可见的规则。下一节将讨论Palo Alto Networks防火墙的隐性安全策略。

 

隐式安全策略

 

默认情况下,防火墙隐式允许区内(源和目的地在同一区域)流量,隐式拒绝区间(不同区域之间)流量。默认情况下,隐式策略允许或拒绝的流量不在防火墙上记录,所以找不到这种流量的日志。要被防火墙记录,流量必须与防火墙上明确配置的安全策略相匹配。然而,为了排除故障,可以改变默认行为。请参考: How to See Traffic from Default Security Policies in Traffic Logs.

 

会话

 

Palo Alto Networks防火墙是一个有状态的防火墙,这意味着通过防火墙的所有流量都与一个会话相匹配,然后每个会话都与一个安全策略相匹配。

 

一个会话由两个流组成。客户端到服务器流(c2s流)和服务器到客户端流(s2c流)。流量启动的端点始终是客户,而流量目的地的端点是服务器。对于定义安全策略,只需要考虑c2s流向。定义政策,允许或拒绝从始发区到目的区的流量,也就是c2s方向。返回流,s2c,不需要新的规则。防火墙上的安全策略评估在列表中从上到下依次进行,因此与列表中第一个最接近的规则相匹配的流量适用于该会话。

 

下面是一个如何从CLI识别会话中流量的例子:

 

> show session id 107224

Session          107224

   

                    c2s flow:

                source:    172.23.123.5 [Test]

                dst:        172.23.123.1

                proto:      50

                sport:      37018          dport:    37413

                state:      ACTIVE          type:      TUNN

                src user:  unknown

                dst user:  unknown

 

        s2c flow:

                source:    172.23.123.1 [Test]

                dst:        172.23.123.5

                proto:      50

                sport:      37750          dport:    50073

                state:      ACTIVE          type:      TUNN

                src user:  unknown

                dst user:  unknown

 

拓扑结构

 

在本文中,以下拓扑结构适用于安全策略的使用案例

jisun_0-1674186230526.png

服务 "应用-默认"

 

在下面的例子中,安全策略允许和拒绝符合以下条件的流量。

 

  • 规则A: 所有从IP子网192.168.1.0/24的信任区发起的、以非信任区为目的地的应用,必须允许任何来自源和目的地端口。
  • 规则B:必须允许从信任区的IP 192.168.1.3发起的以非信任区为目的地的应用程序、DNSWeb浏览、FTP流量。
  • 这些应用程序应该被限制在 "应用程序默认 "的端口上使用。例如,DNS应用程序,默认情况下,使用目标端口53。因此,DNS应用程序应该只允许在这个端口使用。在其余的目标端口上使用这个应用程序应该被拒绝。
  • 规则C: 所有其他从192.168.1.3Untrust区域的应用程序必须被阻止。
  • 规则😧 所有从Untrust区域发起的到任何区域的流量都应该被阻止。

 

安全策略中的服务栏定义了应允许流量的源端口和目的端口。这四个选项是:

  1. 应用-默认。要允许默认目标端口的流量。

关于寻找各种应用所使用的默认目标端口的更多细节,请参考以下文件。

请参阅。如何查看一个应用程序的应用默认端口。

  1. 任何。允许任何源和目的端口的流量。
  2. 预定义服务。已经在防火墙上定义的服务。
  3. 自定义服务。管理员可以根据他们的应用端口要求来定义服务。

 

该例子显示了为符合上述标准而创建的规则。

jisun_1-1674186255883.png

 

当提交上述配置变更时,会显示以下影子警告:

jisun_2-1674186276409.png

 

接下来将讨论影子警告的影响和避免影子警告的技巧。

 

规则的影子

 

在上述例子中,IP地址192.168.1.3属于信任区,属于子网192.168.1.0/24。由于防火墙从上到下进行安全策略查询,所有来自IP 192.168.1.3的流量都符合规则A,并将被应用于会话。虽然该流量也符合规则B和规则C的标准,但这些规则不会被应用于该流量,因为规则A正在影射规则B和规则C

 

为了避免阴影的影响,规则B和规则C应该在规则A之前,如下图所示。现在,流量与正确的规则相匹配,并防止在提交过程中出现 "影子警告"

jisun_3-1674186289960.png

 

基于用户的安全策略

 

在上面的例子中,策略是基于IP地址编写的。 以同样的方式,LDAP用户、LDAP组和防火墙上的本地定义用户也可以在安全策略中使用。关于如何配置User-ID和将用户添加到安全策略中的更多细节,请参考以下文件。

 

Getting Started: User-ID

How to Add Groups to Security Policy

 

带有NAT的IP地址的安全策略

 

本节讨论了在涉及到IP地址转换时如何编写安全策略,以及如何在安全策略中使用URL类别来控制各种网站。

 

在下面的例子中,安全策略被定义为与以下标准相匹配:

 

非信任区的公共IP 192.0.2.1被翻译成DMZWeb服务器的私有IP 10.1.1.2

  1. 从非信任区到DMZ区的Web服务器10.1.1.2的入站流量必须只允许使用254438080端口。
  2. 信任区的所有用户必须被拒绝访问非信任区的 "成人和色情 "类网站。
  3. 所有其他从信任区到非信任区的流量都必须被允许。

 

下面的规则显示了满足上述标准的配置。

 

jisun_4-1674186301989.png

 

所有从非信任区发往Web服务器的流量,其目标公共IP192.0.2.1,属于非信任区。由于该流量来自非信任区,目的地是非信任区的IP,因此该流量被一个允许相同区域流量的隐含规则所允许。在安全策略查询之后,防火墙做了一个NAT策略查询,确定Web服务器的公共IP应该被翻译成位于DMZ区的私有IP 10.1.1.2。在这个阶段,防火墙有了最终目标区域(DMZ),但是IP192.0.2.110.1.1.2的实际转换还没有发生。在确定NAT后流量的最终目的区信息后,防火墙进行第二次安全策略查询,以找到一个政策,允许以最终目的区DMZ为目的地的流量。因此,上面的规则X被配置为允许后NAT流量。注意,规则XDMZPost-NAT区域)作为目标区域,将192.0.2.1Pre-NAT IP)作为目标IP地址。在上面的例子中,一个服务 "Web-server_Ports "被配置为允许目标端口254438080。欲了解更多信息,请参考: How to Configure a Policy to Use a Range of Ports.

 

安全策略中的URL类别

 

在上面的例子中,规则Y被配置为使用安全策略中的URL类别选项阻止成人类网站。在安全策略中使用URL类别选项时,必须在策略中明确提到网络浏览应用程序。否则,不相关的流量将与此规则相匹配。另一种基于URL类别控制网站的方法是使用URL过滤配置文件。

 

应用程序的依赖性和应用程序的转移

 

本节讨论了 "应用依赖性",并描述了当应用-ID在会话中间改变时,会话会发生什么。

 

在下面的例子中,安全策略被定义为允许和拒绝符合以下条件的流量。

 

  1. 应该允许GotomeetingYoutube从信任区到非信任区的应用。
  2. 应该允许应用FacebookGmail-base从访客区到非信任区。
  3. 对于访客区的用户,SSL和网络浏览应该被阻止。

 

这个例子显示了为符合上述标准而创建的规则。

jisun_5-1674186315218.png

 

 

在提交配置更改时,可能会看到以下应用程序依赖性警告。

 

jisun_6-1674186330365.png

 

GotomeetingYouTube这样的应用最初被识别为SSL、网络浏览和Citrix。随着这些会话的更多数据包通过防火墙,防火墙可以获得更多信息来识别应用程序。然后,防火墙将应用程序转移到GotomeetingYoutube等各自的应用程序。

 

每当应用程序转移发生时,防火墙就会进行新的安全策略查询,以找到与新应用程序相匹配的最接近的规则。因此,在上述案例中,SSL和网络浏览被称为GotomeetingYoutube的附属应用,因此这些应用也应该在安全策略中被允许。如果流量的应用在会话过程中发生变化,那么第二次安全策略查询就会根据安全策略重新匹配流量,以找到新的最接近的匹配策略。

 

jisun_7-1674186342518.png

 

在上面的例子中,创建了一个新的安全策略,"依赖性应用程序规则",以允许SSL和网络浏览。Youtube的流量最初与此规则相匹配,一旦发生应用转移,第二次安全策略查询就与规则10相匹配。

 

一些协议的应用可以被允许,而不需要明确地允许其依赖性(见: How to Check if an Application Needs to have Explicitly Allowed Dependency Apps ). 在上面的例子中,Facebookgmail-base就是这样的应用,它们依赖于SSL和网络浏览,不需要明确允许它们的依赖应用。

 

应用程序识别和解密

 

某些应用程序,如Vimeo,使用了SSL并进行了加密,无需SSL解密就能被防火墙识别。然而,像YouTube这样使用SSL的应用,需要由防火墙解密才能识别。由于SSL连接是加密的,因此防火墙无法看到这种流量,以便对其进行识别。防火墙使用证书中的通用名称字段进行应用识别。这是在SSL握手过程中以明文交换的。

 

Vimeo这样的网站使用网站的URL名称作为通用名称,因此不需要配置SSL解密。一些网站如YouTube使用带有通配符名称的证书作为公共名称。在YouTube的情况下,它是*.google.com。因此,使用该信息进行应用识别是不可能的,必须配置SSL解密以获得网站URL的可见性。请参考以下关于如何实施和测试SSL解密的文件

 

清理规则

 

一些环境要求记录所有被防火墙拒绝和允许的流量。默认情况下,只有防火墙明确允许的流量才会被记录下来。要记录防火墙隐含规则所允许的流量,请参考:

 

安全策略提示

 

防火墙以相同的顺序检查以下标准,以便根据安全策略匹配流量。

 

  1. 源地址和目的地址
  2. 源端口和目标端口
  3. 应用程序
  4. 用户-ID
  1. URL类别
  2. 源区和目的区

 

jisun_9-1674186409876.png

 

在上述配置实例中,当TCP端口80上的应用程序 "网络浏览 "从信任区到非信任区通过防火墙时,将以下列方式进行安全查询。

  1. /目的地址 - 因为规则ABC "任何 "源和目的地址,所以该流量与所有这些规则相匹配。
  2. 源端口和目的端口 - 因为规则ABC "任何 "服务,所以流量符合所有这些规则:
  3. 应用程序 - 由于规则AB "网络浏览 "应用程序,流量符合这些规则。
  4. 用户ID--这里不适用。
  1. URL类别 - 此处不适用。
  1. 源区和目的区 - 因为流量是在信任区和非信任区之间,所以为这个流量选择了规则A

 

配置安全策略的最佳方式是尽量减少 "任何 "的使用,并在可能的情况下使用具体的值。这可以减少Palo Alto Networks设备进行的不必要的安全策略查询。

 

相关文件

Is there a Limit to the Number of Security Profiles and Policies per Device?

How to Identify Unused Policies on a Palo Alto Networks Device

How to Test Which Security Policy will Apply to a Traffic Flow.

Why are Rules Denying Applications Allowing Some Packets?

Why Does "Not-applicable" Appear in Traffic Logs?

How to Identify Unused Policies on a Palo Alto Networks Device

How Session Rematch Works

How to Restrict a Security Policy to Windows and MAC Machines Using GlobalProtect HIP Profiles

How Application-Default in the Rulebase Changes the Way Traffic is Matched

How to Schedule Policy Actions

Security Policy Management with Panorama

Session Log Best Practice

 

附件

Rate this article:
  • 2593 Views
  • 0 comments
  • 0 Likes
Register or Sign-in
Contributors
Labels
Article Dashboard
Version history
Last Updated:
‎01-19-2023 07:51 PM
Updated by: