配置和实施

产品配置，方案实施等相关指南

问题 1. 什么是Cortex XDR网关？ 2. 为什么Cortex XDR应用程序在集线器中不再可见？ 3. 如果不通过集线器，现在怎样才能激活Cortex XDR？答案 1. Cortex XDR网关是一个独立的网络应用程序，与Cortex XDR 2.9版本一起设计。它的设计是为了简化入职和租户管理。 2. Cortex XDR应用程序在枢纽中不可见，因为它现在要在Cortex XDR网关上激活。 3. 要激活Cortex XDR，请按照以下链接的步骤进行。激活Cortex XDR 注意：说明中的步骤1。导航到您在电子邮件中收到的激活链接，并登录以开始在Cortex XDR网关中进行激活。 Cortex XDR网关其他信息正在迁移到不再使用集线器的Cortex XDR Gateway APP。迁移应在5月30日前完成。许多客户已经被迁移，那些被迁移的客户应该可以通过这个网址访问网关。https://xdr-gateway.paloaltonetworks.com/accounts 所有被迁移的用户应该已经收到电子邮件的通知，其中有新的访问说明。要求Cortex XDR激活的电子邮件应发到IAD@paloaltonetworks.com，他们可以重新生成电子邮件。

概述在使用第三方供应商配置GlobalProtect MDM时，将发送的有效载荷中的VendorConfig密钥是可配置的。详情用户可以发送的可用的密钥是：只应用层面（OnlyAppLevel）仅用于iOS 7设备，值为'1'意味着VPN配置配置文件仅是Per-App VPN，而值为'0'意味着配置文件支持设备级VPN以及Per-App VPN。在iOS 8中，Per-App VPN和设备级VPN根据配置文件的有效载荷类型被放入设备上独立的VPN配置组，因此不再需要此配置。允许门户配置文件 (AllowPortalProfile) 1'表示允许，'0'表示不允许。参考管理员指南中 "为iOS设备创建GlobalProtect配置 "部分的步骤3 "允许门户配置文件"。 FromAspen 内部使用。表示VPN配置来自GlobalProtect MSM。第三方不需要配置此密钥。

环境 Prisma Cloud Slack Splunk Amazon SQS Amazon GuardDuty AWS Inspector AWS SecurityHub Google SCC Qualys Tenable Jira ServiceNow Qradar Webhooks PagerDuty 答案这里是你需要为Prisma云计算应用程序建立白名单的IP地址列表。 APP 34.199.10.120 34.228.96.118 54.89.145.129 54.145.47.25 APP2 3.16.7.30 13.59.164.228 18.191.115.70 18.218.243.39 18.221.72.80 18.223.141.221 APP3 34.208.190.79 52.24.59.168 52.26.142.61 52.39.60.41 54.213.143.171 54.218.131.166 APP.EU 3.121.64.255 3.121.248.165 3.121.107.154 18.184.105.224 18.185.81.104 52.29.141.235 APP.ANZ 3.104.252.91 13.54.241.27 13.211.100.18 13.239.110.68 52.62.194.176 52.62.231.151 APP.GOV 52.61.112.59 52.61.113.234 52.61.164.254 96.127.90.208 96.127.115.247 160.1.65.168 请检查NAT网关IP地址的最新列表。

问题 Hub上的Prisma 云图标对于新用户不可见环境 Prisma云步骤添加用户访问Prisma云需要在3个地方完成。APP账户管理员只能为用户分配/添加角色。在Prisma Cloud控制台中添加用户，并指定角色和权限。在设置 > 用户，然后设置 > 角色下使用这个链接来分配用户的角色和权限。该应用程序从Prisma云控制台摄取所有活动用户。选择方块，由用户的电子邮件，所以分配角色的按钮将解锁为蓝色。然后，账户管理员将可以为该用户分配角色等。在 "support.paloaltonetworks.com "上添加一个用户，在 "会员">"管理用户 "下，这将使用户能够看到通过枢纽登录的图标。额外信息在云上添加管理员用户给予正确的人访问Prisma Access权限

解决方案目录概述本文件描述了Palo Alto Networks防火墙上安全策略的基本原理。所有穿越Palo Alto Networks防火墙数据平面的流量都与安全策略相匹配。这不包括来自防火墙管理界面的流量，因为在默认情况下，这种流量不会通过防火墙的数据平面。防火墙上的安全策略可以使用各种标准来定义，如区域、应用、IP地址、端口、用户和HIP配置文件。防火墙管理员可以定义安全策略以允许或拒绝流量，从区域作为广泛的标准开始，然后用更细化的选项如端口、应用程序和HIP配置文件来微调策略。两种安全策略防火墙有两种安全策略。显性安全策略由用户定义，在CLI和Web-UI界面上可见。隐式安全策略是用户通过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 拓扑结构在本文中，以下拓扑结构适用于安全策略的使用案例服务 "应用-默认" 在下面的例子中，安全策略允许和拒绝符合以下条件的流量。规则A: 所有从IP子网192.168.1.0/24的信任区发起的、以非信任区为目的地的应用，必须允许任何来自源和目的地端口。规则B：必须允许从信任区的IP 192.168.1.3发起的以非信任区为目的地的应用程序、DNS、Web浏览、FTP流量。这些应用程序应该被限制在 "应用程序默认 "的端口上使用。例如，DNS应用程序，默认情况下，使用目标端口53。因此，DNS应用程序应该只允许在这个端口使用。在其余的目标端口上使用这个应用程序应该被拒绝。规则C: 所有其他从192.168.1.3到Untrust区域的应用程序必须被阻止。规则😧 所有从Untrust区域发起的到任何区域的流量都应该被阻止。安全策略中的服务栏定义了应允许流量的源端口和目的端口。这四个选项是：应用-默认。要允许默认目标端口的流量。关于寻找各种应用所使用的默认目标端口的更多细节，请参考以下文件。请参阅。如何查看一个应用程序的应用默认端口。任何。允许任何源和目的端口的流量。预定义服务。已经在防火墙上定义的服务。自定义服务。管理员可以根据他们的应用端口要求来定义服务。该例子显示了为符合上述标准而创建的规则。当提交上述配置变更时，会显示以下影子警告：接下来将讨论影子警告的影响和避免影子警告的技巧。规则的影子在上述例子中，IP地址192.168.1.3属于信任区，属于子网192.168.1.0/24。由于防火墙从上到下进行安全策略查询，所有来自IP 192.168.1.3的流量都符合规则A，并将被应用于会话。虽然该流量也符合规则B和规则C的标准，但这些规则不会被应用于该流量，因为规则A正在影射规则B和规则C。为了避免阴影的影响，规则B和规则C应该在规则A之前，如下图所示。现在，流量与正确的规则相匹配，并防止在提交过程中出现 "影子警告"。基于用户的安全策略在上面的例子中，策略是基于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被翻译成DMZ区Web服务器的私有IP 10.1.1.2。从非信任区到DMZ区的Web服务器10.1.1.2的入站流量必须只允许使用25、443和8080端口。信任区的所有用户必须被拒绝访问非信任区的 "成人和色情 "类网站。所有其他从信任区到非信任区的流量都必须被允许。下面的规则显示了满足上述标准的配置。所有从非信任区发往Web服务器的流量，其目标公共IP为192.0.2.1，属于非信任区。由于该流量来自非信任区，目的地是非信任区的IP，因此该流量被一个允许相同区域流量的隐含规则所允许。在安全策略查询之后，防火墙做了一个NAT策略查询，确定Web服务器的公共IP应该被翻译成位于DMZ区的私有IP 10.1.1.2。在这个阶段，防火墙有了最终目标区域（DMZ），但是IP从192.0.2.1到10.1.1.2的实际转换还没有发生。在确定NAT后流量的最终目的区信息后，防火墙进行第二次安全策略查询，以找到一个政策，允许以最终目的区DMZ为目的地的流量。因此，上面的规则X被配置为允许后NAT流量。注意，规则X将DMZ（Post-NAT区域）作为目标区域，将192.0.2.1（Pre-NAT IP）作为目标IP地址。在上面的例子中，一个服务 "Web-server_Ports "被配置为允许目标端口25、443和8080。欲了解更多信息，请参考： How to Configure a Policy to Use a Range of Ports. 安全策略中的URL类别在上面的例子中，规则Y被配置为使用安全策略中的URL类别选项阻止成人类网站。在安全策略中使用URL类别选项时，必须在策略中明确提到网络浏览应用程序。否则，不相关的流量将与此规则相匹配。另一种基于URL类别控制网站的方法是使用URL过滤配置文件。应用程序的依赖性和应用程序的转移本节讨论了 "应用依赖性"，并描述了当应用-ID在会话中间改变时，会话会发生什么。在下面的例子中，安全策略被定义为允许和拒绝符合以下条件的流量。应该允许Gotomeeting、Youtube从信任区到非信任区的应用。应该允许应用Facebook、Gmail-base从访客区到非信任区。对于访客区的用户，SSL和网络浏览应该被阻止。这个例子显示了为符合上述标准而创建的规则。在提交配置更改时，可能会看到以下应用程序依赖性警告。像Gotomeeting和YouTube这样的应用最初被识别为SSL、网络浏览和Citrix。随着这些会话的更多数据包通过防火墙，防火墙可以获得更多信息来识别应用程序。然后，防火墙将应用程序转移到Gotomeeting和Youtube等各自的应用程序。每当应用程序转移发生时，防火墙就会进行新的安全策略查询，以找到与新应用程序相匹配的最接近的规则。因此，在上述案例中，SSL和网络浏览被称为Gotomeeting和Youtube的附属应用，因此这些应用也应该在安全策略中被允许。如果流量的应用在会话过程中发生变化，那么第二次安全策略查询就会根据安全策略重新匹配流量，以找到新的最接近的匹配策略。在上面的例子中，创建了一个新的安全策略，"依赖性应用程序规则"，以允许SSL和网络浏览。Youtube的流量最初与此规则相匹配，一旦发生应用转移，第二次安全策略查询就与规则10相匹配。一些协议的应用可以被允许，而不需要明确地允许其依赖性（见： How to Check if an Application Needs to have Explicitly Allowed Dependency Apps ). 在上面的例子中，Facebook和gmail-base就是这样的应用，它们依赖于SSL和网络浏览，不需要明确允许它们的依赖应用。应用程序识别和解密某些应用程序，如Vimeo，使用了SSL并进行了加密，无需SSL解密就能被防火墙识别。然而，像YouTube这样使用SSL的应用，需要由防火墙解密才能识别。由于SSL连接是加密的，因此防火墙无法看到这种流量，以便对其进行识别。防火墙使用证书中的通用名称字段进行应用识别。这是在SSL握手过程中以明文交换的。像Vimeo这样的网站使用网站的URL名称作为通用名称，因此不需要配置SSL解密。一些网站如YouTube使用带有通配符名称的证书作为公共名称。在YouTube的情况下，它是*.google.com。因此，使用该信息进行应用识别是不可能的，必须配置SSL解密以获得网站URL的可见性。请参考以下关于如何实施和测试SSL解密的文件清理规则一些环境要求记录所有被防火墙拒绝和允许的流量。默认情况下，只有防火墙明确允许的流量才会被记录下来。要记录防火墙隐含规则所允许的流量，请参考: 安全策略提示防火墙以相同的顺序检查以下标准，以便根据安全策略匹配流量。源地址和目的地址源端口和目标端口应用程序用户-ID URL类别源区和目的区在上述配置实例中，当TCP端口80上的应用程序 "网络浏览 "从信任区到非信任区通过防火墙时，将以下列方式进行安全查询。源/目的地址 - 因为规则A、B和C有 "任何 "源和目的地址，所以该流量与所有这些规则相匹配。源端口和目的端口 - 因为规则A、B和C有 "任何 "服务，所以流量符合所有这些规则: 应用程序 - 由于规则A和B有 "网络浏览 "应用程序，流量符合这些规则。用户ID--这里不适用。 URL类别 - 此处不适用。源区和目的区 - 因为流量是在信任区和非信任区之间，所以为这个流量选择了规则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 附件

症状让我为你解决这个问题。数据包捕获- 管理员在完成安全策略的杰作后几分钟遇到的一个典型情况是：为什么自从安装了新的网络设备后，一些不起眼的应用程序表现得很奇怪。这就是故障排除的开始。在过去几期中，我们检查了several aspects of how to configure your firewall 并从头开始设置它。管理员可以使用的更高级的工具之一是执行数据包捕获和查看会话计数器的能力。注意：文章中讨论的一些细节将导致性能影响。如果你不确定，请与Palo Alto支持个人合作，在维护窗口捕获数据包。环境任何PAN-OS Palo Alto 防火墙解决办法第一个要去的地方是GUI上的Packet Capture菜单，在那里你可以管理过滤条件，添加要捕获的阶段，并轻松下载捕获。在我们开始之前，有几件事情你应该知道: 可以添加四个具有各种属性的过滤条件。数据包捕获是基于会话的，所以一个过滤条件能够捕获client2server和server2client。数据包是在数据平面上与接口上捕获的（这解释了下一个子弹）。 Pre-Parse Match是一个功能，可以在数据平面上运行的引擎处理之前捕获所有文件，这可以帮助排除引擎可能没有正确接受入站数据包的问题。这个选项只有在支持部门的指示下才能使用，而且要在一天中的低流量时间使用，因为它将捕获所有的东西。当过滤被启用时，新的会话被标记为过滤，可以被捕获，但现有的会话没有被过滤，可能需要重新启动才能捕获它们。卸载的会话不能被捕获，所以卸载可能需要暂时禁用。卸载的会话将在显示会话细节中显示 "layer7 processing: completed"。注意，由于匹配的数据包由CPU处理，这可能会导致性能影响。在维护窗口中运行这个程序，如果需要的话，请向支持部门寻求帮助。要记住的东西很多，但在你试着对各种协议的数据包进行捕捉后，一切都会变得有意义，我保证！让我们添加几个过滤条件：过滤条件2和4是我的 "备份 "过滤条件。我在前面提到，数据包捕获是可以感知的，但是，万一返回的数据包在上游发生了什么，导致它不能与我的NAT规则相匹配（也许上游设备弄乱了源端口或对序列号做了什么奇怪的事情），我通常会设置一个返回规则来捕捉任何由于不匹配而被丢弃的杂散数据。注意：确保过滤条件尽可能的精确。不要运行与整个子网相匹配的过滤条件，如192.168.0.0/16或0.0.0.0/0，因为这可能导致性能影响和中断。如果我们现在把 "过滤 "按钮切换到 "打开"，过滤条件将被应用于任何符合标准的新会话。检查过滤条件是否工作的一个简单方法是，如果启动一个新的会话，检查全局计数器是否在增加。在CLI中，我执行这个命令： > show counter global filter delta yes packet-filter yes Global counters: Elapsed time since last sampling: 2.647 seconds -------------------------------------------------------------------------------- Total counters shown: 0 -------------------------------------------------------------------------------- 而且没有显示任何计数器。 'delta yes'表示我想查看自我上次执行此命令后增加的计数器。 'packet-filter yes'表示我只想看到符合我的过滤器的全局计数器。如果我现在刷新我的浏览器并再次执行该命令: > show counter global filter packet-filter yes delta yes Global counters: Elapsed time since last sampling: 2.630 seconds name value rate severity category aspect description -------------------------------------------------------------------------------- pkt_sent 22 8 info packet pktproc Packets transmitted pkt_outstanding 22 8 info packet pktproc Outstanding packet to be transmitted session_allocated 4 1 info session resource Sessions allocated session_installed 4 1 info session resource Sessions installed appid_proc 2 0 info appid pktproc The number of packets processed by Application identification appid_use_dfa_1 2 0 info appid pktproc The number of packets using the second DFA table nat_dynamic_port_xlat 4 1 info nat resource The total number of dynamic_ip_port NAT translate called dfa_sw 8 3 info dfa pktproc The total number of dfa match using software ctd_sml_opcode_set_file_type 1 0 info ctd pktproc sml opcode set file type aho_sw 5 1 info aho pktproc The total usage of software for AHO ctd_pkt_slowpath 4 1 info ctd pktproc Packets processed by slowpath -------------------------------------------------------------------------------- Total counters shown: 11 -------------------------------------------------------------------------------- 你会看到有一堆的计数器。我在本文底部添加了一个链接，以获得更多关于全局计数器的信息，我们将在未来的一集中更多地介绍它们。但现在，只要有计数器，我们就应该可以了。接下来你要配置阶段--有4个: 丢弃阶段是数据包被丢弃的地方。原因可能各不相同，对于这一部分，全局计数器可能有助于确定丢弃是由于政策拒绝、检测到的威胁还是其他原因。接收阶段在数据包进入防火墙引擎之前捕捉它们进入防火墙的情况。当配置了NAT时，这些数据包将是预NAT。传输阶段捕捉数据包如何从防火墙引擎中输出。如果配置了NAT，这些将是后NAT。防火墙阶段捕获防火墙阶段的数据包。对于每个阶段，你可以为输出文件指定一个名称，并设置一个最大的数据包或字节数。当所有需要的阶段都设置好后，你可以把捕获按钮切换到ON，或者你可以使用CLI，清除符合指定过滤条件的现有会话。这是为了确保在过滤条件启用之前没有任何会话被激活。然后使用capture on命令，开始捕获，如下图所示。 > show session all =>记下符合配置的过滤条件的会话号码。 > clear session id <id#> => 这是为了清除任何符合配置的过滤条件的现有会话。. Example: > show session all -------------------------------------------------------------------------------- ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port]) Vsys Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 27240 web-browsing ACTIVE FLOW NS 192.168.0.34[61003]/trust/6 (198.51.100.230[31047]) vsys1 198.51.100.97[80]/ISP1 (198.51.100.97[80]) ....(output omitted).... > clear session id 27240session 27240 cleared > debug dataplane packet-diag set capture on Packet capture is enabled 你现在可以启动你想捕捉的会话。要验证会话是否已经开始，使用show session命令。 > show session all -------------------------------------------------------------------------------- ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port]) Vsys Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 32637 web-browsing ACTIVE FLOW NS 192.168.0.34[61903]/trust/6 (198.51.100.230[31547]) vsys1 198.51.100.97[80]/ISP1 (198.51.100.97[80]) 32635 ssh ACTIVE FLOW NS 192.168.0.34[61901]/trust/6 (198.51.100.230[52812]) vsys1 198.51.100.1[22]/ISP1 (198.51.100.1[22]) 当你完成后，可以通过将按钮拨回到OFF位置或使用调试命令来关闭捕获。 > debug dataplane packet-diag set capture off Packet capture is disabled > debug dataplane packet-diag clear filter-marked-session all Unmark All sessions in packet debug 注意：不要忘记在调试后关闭数据包捕获。如果不这样做，可能会对CPU造成负担，并可能导致性能问题。现在将有捕获的文件可供下载，你可以用Wireshark进行分析。在你下载pcaps后，你可能需要将发送和接收文件合并在一起：接收阶段将有客户的私有IP到网络服务器的公共IP，以及从网络服务器公共IP返回的数据包到防火墙的外部IP（接收阶段是预NAT）。发送阶段将有防火墙外部IP（客户端NAT）到服务器公共IP，以及返回的公共IP到客户端私有IP。当你试图跟踪TCP流时，这可能有点令人困惑，你要注意这两个文件之间的重要区别。这两个阶段将确保你能够验证NAT是否被正确应用。你还可以看到从客户和服务器的角度来看，发出和收到的数据包是否有任何不同。合并后的结果应该是这样的，并允许你逐一比较正在发送的数据包和正在接收的数据包。有几篇有用的文章可以帮助你更好地了解数据包如何在系统中流动： What is the Significance of Global Counters? Packet Flow Sequence in PAN-OS Management plane 要排除管理平面的连接问题，可以使用内置的tcpdump命令来捕获有用的信息。 admin@myNGFW> tcpdump filter "port 53" Press Ctrl-C to stop capturing tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes ^C 16 packets captured 32 packets received by filter 0 packets dropped by kernel The resulting output is stored in a mgmt.pcap file on the management plane: admin@myNGFW> view-pcap mgmt-pcap mgmt.pcap 15:24:07.512889 IP 10.0.0.1.36606 > 10.0.0.98.domain: 49243+ PTR? 0.0.0.10.in-addr.arpa. (41) 15:24:07.513106 IP 10.0.0.98.domain > 10.0.0.1.36606: 49243 NXDomain 0/1/0 (100) 15:24:17.196515 IP 10.0.0.1.45455 > 10.0.0.98.domain: 3126+ PTR? 0.0.0.10.in-addr.arpa. (41) 15:24:17.196762 IP 10.0.0.98.domain > 10.0.0.1.45455: 3126 NXDomain 0/1/0 (100) 15:24:31.126186 IP 10.0.0.1.57230 > 10.0.0.98.domain: 2978+ A? panos.wildfire.paloaltonetworks.com. (53) 15:24:31.126196 IP 10.0.0.1.57230 > 10.0.0.98.domain: 55173+ AAAA? panos.wildfire.paloaltonetworks.com. (53) 15:24:31.161436 IP 10.0.0.98.domain > 10.0.0.1.57230: 2978 4/0/0[|domain] 15:24:31.194586 IP 10.0.0.98.domain > 10.0.0.1.57230: 55173 2/0/0[|domain] 15:25:56.746679 IP 10.0.0.1.46048 > 10.0.0.98.domain: 43532+ A? wildfire.paloaltonetworks.com. (47) 15:25:56.746689 IP 10.0.0.1.46048 > 10.0.0.98.domain: 16653+ AAAA? wildfire.paloaltonetworks.com. (47) 15:25:56.794940 IP 10.0.0.98.domain > 10.0.0.1.46048: 43532 1/0/0 (63) 15:25:56.795553 IP 10.0.0.98.domain > 10.0.0.1.46048: 16653 0/1/0 (131) 15:25:59.038459 IP 10.0.0.1.51804 > 10.0.0.98.domain: 23806+ A? panos.wildfire.paloaltonetworks.com. (53) 15:25:59.038471 IP 10.0.0.1.51804 > 10.0.0.98.domain: 31471+ AAAA? panos.wildfire.paloaltonetworks.com. (53) 15:25:59.071431 IP 10.0.0.98.domain > 10.0.0.1.51804: 23806 4/0/0[|domain] 15:25:59.113552 IP 10.0.0.98.domain > 10.0.0.1.51804: 31471 2/0/0[|domain] 请查看这篇文章以了解更多信息 How To Packet Capture (tcpdump) On Management Interface 其他信息为了控制数据包捕获文件的大小，单个文件被限制在 200mb，一旦超过这个大小，就会自动创建第二个文件，然后这两个文件将作为一个环形缓冲区，主 pcap 文件被用来写入活动的捕获数据，*.cap.1 文件被用来作为缓冲区。一旦主 pcap 再次达到其容量，缓冲文件将被丢弃，主文件被重命名为 *.pcap.1，并启动一个新的主文件。更多信息在这里：What is The Limitation of the Packet Capture File Size on PAN-OS? 对于小的捕捉，把所有的东西都捕捉到一个文件中可能会很方便，所以有可能让每个阶段都捕捉到同一个文件名。请注意上述的大小限制，以及每个阶段的可见度降低。推荐的方法是每个阶段都有一个单独的文件。从PAN-OS 8.1.0开始，可以为源网和网络子网添加过滤条件，这只能通过CLI而不是WebGUI获得。 admin@firewall> debug dataplane packet-diag set filter match + destination Destination IP address + destination-netmask Destination netmask <<<< new option for network + destination-port Destination port + ingress-interface Ingress traffic interface name + ipv6-only IPv6 packet only + lacp LACP packet + non-ip Non-IP packet + protocol IP protocol value + source Source IP address + source-netmask Source netmask <<<< new option for network + source-port Source port | Pipe through a command <Enter> Finish input admin@firewall> debug dataplane packet-diag set filter match source 192.168.1.0 source-netmask 24 admin@firewall> debug dataplane packet-diag set filter match destination 192.168.2.0 destination-netmask 24 admin@firewall> debug dataplane packet-diag show setting DP dp0: -------------------------------------------------------------------------------- Packet diagnosis setting: -------------------------------------------------------------------------------- Packet filter Enabled: no Match pre-parsed packet: no Index 1: 192.168.1.0/24[0]->0.0.0.0/0[0], proto 0 <<<<<<<<< network is captured /24 ingress-interface any, egress-interface any, exclude non-IP Index 2: 0.0.0.0/0[0]->192.168.2.0/24[0], proto 0 <<<<<<<<< network is captured /24 ingress-interface any, egress-interface any, exclude non-IP -------------------------------------------------------------------------------- 注意：启用全网捕获时要谨慎，可能会有大量的数据包，导致数据平面CPU的高消耗和可能的流量影响。附件

环境 Global Protect设置解决办法本文介绍了在GlobalProtect设置中配置证书的基本知识。请注意，为GlobalProtect部署证书可能有其他方法，本文没有涉及。 SSL/TLS服务配置文件 - 指定门户/网关服务器证书，每个门户/网关都需要一个。证书配置文件（若有）- 由门户/网关用于请求客户端/机器证书。在终端客户机上安装客户机/机器证书 A. SSL/TLS服务配置文件在GlobalProtect中，该配置文件用于指定GlobalProtect门户/网关的 "服务器证书 "和SSL/TLS "协议版本范围"。如果同一个接口同时作为门户和网关，你可以为门户/网关使用相同的SSL/TLS配置文件。如果门户/网关通过不同的接口提供服务，只要证书中在其主题别名SAN(Subject Alternate Name)中包括门户/网关的IP/FQDN，就可以使用相同的SSL/TLS配置文件，如果没有，根据需要为门户和网关创建不同的配置文件。创建SSL/TLS配置文件的前提是生成/导入门户/网关的 "服务器证书 "及其链(chain)。要导入外部生成的证书，请到设备>证书管理>证书，点击底部的 "导入"。要在防火墙上生成证书，请到设备>证书管理>证书，并点击底部的 "生成"。如果服务器证书是由知名的第三方CA或内部PKI服务器签名的导入Root CA(私钥是可选的) 如果有中间CA(intermediate CAs)，则导入中间CA（私钥是可选的）导入由上述CA签名的服务器证书。（"带 "私钥）重要! 主题别名SAN(Subject Alternate Name)应该至少存在一个条目，用于门户/网关的IP或FQDN "必须 "是该SAN列表中的一个条目。如果SAN没有上述条目，证书验证将在网关上失败，并将导致连接失败。不应该是CA类型的。它必须是终端实体(end-entity)的类型。一种良好的做法，最好使用 FQDN 而不是 IP。在整个配置中保持一致，同时教育终端用户在GlobalProtect客户端的门户字段中使用这个FQDN/IP。例如，如果门户/网关可以通过fqdn 'vpn.xyz.com'或IP 1.1.1.1到达；如果证书引用了fqdn 'vpn.xyz.com'，那么用户 "必须 "使用 "vpn.xyz.com "而不是 "1.1.1.1"。 4. SSL/TLS配置文件 (位置: 设备>证书管理>SSL/TLS服务配置文件) -名称 -为这个配置文件给出任何名称 -证书 - 参考第三步中的服务器证书 -协议设置 - 为客户端和服务器之间的ssl交易(ssl transaction)选择ssl/tls的最小和最大版本 5. 根据需要在门户/网关中参考这个SSL/TLS配置文件。如果服务器证书需要在Palo Alto Networks防火墙上生成 1. 生成一个根证书，其常见名称(Common Name)为任何唯一值。(除门户/网关的IP或FQDN外) (位置: 设备>证书管理>证书，点击屏幕底部的 "生成"）。 2.（可选）生成一个由上述根证书签署的中间证书。指定其常见名称(Common Name)为任何唯一值。(除门户/网关的IP或FQDN外) 3. 生成一个由上述中间证书签署的服务器证书。 a. 如果这个证书中不存在主题别名SAN(Subject Alternate Name)，该证书的常见名称(Common Name) "必须 "与门户/网关的 IP 或 FQDN 匹配。在 PAN 防火墙中，SAN 可以在 " hostname"、"IP "或 " email"类型的可选的"证书属性(certificate attributes)"下创建。 b. 如果SAN至少存在一个条目，那么用于门户/网关的IP或FQDN "必须 "存在于该SAN列表中。 c. 不应该是一个CA。 d. 一个好的做法，最好使用FQDN而不是IP。在整个配置中保持一致，并教育最终用户在GlobalProtect客户端的门户字段中使用这个FQDN/IP。例如，如果可以通过fqdn 'vpn.xyz.com'或IP 1.1.1.1到达门户/网关；证书引用了fqdn 'vpn.xyz.com'，用户 "必须 "使用 "vpn.xyz.com "而不是 "1.1.1.1"。 4. SSL/TLS配置文件 (位置: 设备>证书管理>SSL/TLS服务配置文件) 名称 - 为这个配置文件提供任何名称证书 - 参考第三步中的服务器证书协议设置 - 为客户和服务器之间的ssl交易(ssl transaction)选择ssl/tls的最小和最大版本 5. 根据需要在门户/网关中参考这个SSL/TLS配置文件。 B. 证书配置文件 (位置：设备>证书管理>证书配置文件) 证书配置文件指定了一个CA和中间CA的列表。当这个证书配置文件应用于配置时，门户/网关将向客户端发送一个客户端证书请求，要求获得由证书配置文件中指定的CA/中间CA签署的客户端/机器证书。建议在此配置文件中同时放置根和中间CA，而不是只放置Root CA。重要! -客户端证书是指用户证书，它可以用于 "user-login"/"on-demand"的连接方法。用于验证用户的身份。 -机器证书指的是设备证书，它可以用于 "pre-login"的连接方法。这用于验证设备，而不是用户。 1. 在设备>证书管理>证书中导入签署客户端/机器证书的 "Root CA"（私钥可选）。 2. 将签署了客户端/机器证书的 "中间CA"（如果有）导入到设备 > 证书管理 > 证书中（私钥可选）。 3. 到设备 > 证书管理 > 证书配置文件，点击添加。 4. 给该配置文件起个名称。 5. 添加步骤1和2中的根和中间CA。 6. 注意：用户名字段默认设置为 "None"，在一个典型的设置中，用户名是从LDAP/RADIUS认证中提取的，你可以把它设置为None。另一方面，如果证书是唯一的认证方法，也就是说，如果你没有RADIUS/LDAP作为门户/网关认证，那么你必须把用户名字段从None改为'主题'或'主题Alt'，从客户端证书的common-name或Email/ Principal name中提取用户名。如果不这样做，将导致提交失败。 7.（可选）如果门户/网关需要使用CRL或OCSP来验证客户端/机器证书的废止状态，则检查CRL或OCSP。请谨慎使用，因为如果与 "如果证书状态未知，则阻止会话"一起使用，可能会导致客户端连接失败。 8. 根据需要参考这个证书配置文件门户/网关。 C. 在终端客户机中安装客户端/机器证书当导入客户端/机器证书时，以PKCS格式导入，该格式将包含其私钥。 Windows - 1. 单击 "开始">"运行"，输入mmc以打开Microsoft 管理控制台。 2. 到文件 > 添加/删除管理单元: 重要! 3. 点击证书>添加，选择以下一项或两项: a. 要添加客户端（用户）证书，选择 "我的用户账户"。这用于 "user-login"和 "on-demand"，因为它可以验证用户。 b. 要添加机器（设备）证书，选择"计算机账户"。这将用于 "pre-login"，因为它可以验证机器。 4. 将客户端/机器证书导入mmc。 a. 如果你要导入客户端证书，请将其导入 "我的用户账户 "下的 "个人 "文件夹。 b. 如果你要导入机器证书，请将其导入 "计算机账户 "下的 "个人 "文件夹。 5. 同样地在 "受信任的根证书颁发机构 "中导入Root CA，在 "中间证书颁发机构 "中导入中间CA（如果有）。重要! 6. 一旦导入，双击导入的客户机/机器证书，以确保： a. 它有私钥 b. 它的证书链是完整的，直到其Root CA。如果证书链中缺少Root CA或中间 CA，请按照步骤 5 的说明将它们导入各自的文件夹中。 7. 此时，客户机上的证书已被导入，所以你可以关闭mmc控制台而不保存它。 macOS 1. 打开钥匙串访问，去到系统钥匙串: 2. 确保所有的应用程序能访问设备的私钥和Root CA的证书：

现象：新租户拥有活跃的Prisma云和计算许可证。用户有系统管理权限。然而，用户无法访问Prisma云计算部分，出现错误 "您的Prisma云计算控制台配置失败。请联系您的Palo Alto Networks客户服务团队"。环境： Prisma Cloud Enterprise Edition (SAAS) 原因：这很可能是租户ID在后台的CSP ID问题。解决方案：通过PCSUP（JIRA）与工程团队联系，更新面临该问题的相关租户ID的CSP ID。这将更新后台的计算模块以解决这个问题。

总结：这篇文章描述了BTP警报的情况，它的规则名称如下。 bioc.vulnerable_driver_dropped_$name bioc.sync.vulnerable_driver_loaded_$name bioc.sync.vulnerable_driver_by_original_name_loaded_$name bioc.sync.vulnerable_driver_by_signer_name_loaded_$name bioc.sync.malicious_driver_by_signer_name_loaded_$name bioc.sync.malicious_driver_by_original_name_loaded__$name 环境： Cortex XDR for Windows Behavioral Threat Protection (BTP) 答案：这不是一个假阳性检测。这是一个易受攻击的驱动程序，正在被客户机器上的一个应用程序使用。所以我们阻止了它。这个驱动程序可以被攻击者滥用，以获得权限的提升。注意：如果一个规则名称有这些内容，它不是一个假阳性。它们也是由有漏洞的驱动文件引起的。 bioc.vulnerable_driver_dropped_$name bioc.sync.vulnerable_driver_loaded_$name bioc.sync.vulnerable_driver_by_original_name_loaded_$name bioc.sync.vulnerable_driver_by_signer_name_loaded_$name bioc.sync.malicious_driver_by_signer_name_loaded_$name bioc.sync.malicious_driver_by_original_name_loaded__$name

关于Cortex XDR状态和计划维护活动的信息可以在以下网站找到： https://status.paloaltonetworks.com 该页面提供Palo Alto Networks云服务的状态信息。这意味着你也能找到其他云服务的信息，如Cortex数据湖和云身份引擎。其他信息状态页面的右上角是订阅更新的选项，它将有以下选项。当Palo Alto Networks云服务创建、更新或解决一个事件时，获得电子邮件通知。每当Palo Alto Networks云服务创建或解决一个事件时，获得文本信息通知获取Atom Feed或RSS Feed

现象本文档介绍如何使用反间谍软件、漏洞保护和防病毒的例外设置来更改针对Palo Alto Network防火墙上特定威胁的操作。环境 Palo Alto Network 防火墙 PAN OS 8.1 及更高版本。反间谍软件、漏洞或防病毒的例外设置解决方法反间谍软件或漏洞保护的例外设置例如：将威胁 ID #30003 的反间谍软件例外添加到名为“Threat_exception_test_profile”的现有配置文件转到对象 > 安全配置文件 >“反间谍软件”或“漏洞保护” 选择现有配置文件单击“例外”选项卡。首先，选中配置文件窗口左下方的“显示所有签名”的选框。在搜索栏中，输入字符串“( 例如 'microsoft' )”或直接输入威胁 ID 号本身（例如 30003）。按回车键或单击绿色箭头开始搜索。注意：如果正在搜索的签名是在最新的动态更新操作中应用并且没有在搜索结果中出现，请退出 Web UI 然后重新登录以清除 GUI 缓存。结果将显示“ Microsoft Windows DCOM RPC Interface Buffer Overrun Vulnerability”（就是威胁 ID #30003）。注意：威胁 ID 可以从威胁日志中确定。要启用此例外设置，请选中“启用”选框。更改默认的“动作”值以处理未排除的流量。要允许流量，请选择Allow（允许），或要丢弃流量，请选择Drop（丢弃）。威胁操作详细信息 - 更改默认操作。使用 IP 地址例外项目栏将 IP 地址过滤器添加到威胁的例外中。如果将 IP 地址添加到威胁例外，只有当触发签名是由源 IP 或目标 IP 与例外列表中的 IP 匹配的会话时，该签名的威胁例外操作才会接管规则的操作。每个签名最多可以添加 100 个 IP 地址。使用此选项，无需创建新的策略规则和新的漏洞配置文件来为特定 IP 地址创建例外。为了排除某些 IP 地址，而不是所有流量，请单击“ IP Address Exemptions（IP 地址豁免）”下的空白处，然后单击底部的添加按钮。最多可以向列表中添加 100 个 IP 地址。 IP 地址豁免详细信息。确保将反间谍软件和/或漏洞保护配置文件应用于适当的安全策略。点击提交更改以启用例外设置。防病毒例外设置例如，要将威胁 ID #253879 的防病毒的例外添加到名为“AV_exception_test_profile”的现有配置文件：（注意：请注意，如果您将一个病毒排除在检查范围之外，就只能是是全部或没有，您不能只将一个IP排除在这种保护之外，这将是该规则/防病毒策略所允许的所有内容）。转到 GUI：对象 > 安全配置文件 > 防病毒。在现有配置文件中，单击“病毒例外”选项卡。在页面底部的 Threat Id（威胁号）字段中输入威胁ID（在此示例中为253879 ），然后单击添加和确认。注意：威胁 ID 可以从威胁日志中确定。在此示例中，创建了“ Win32/Virus.Generic.koszy ”的例外设置防病毒 - 病毒异常窗口详细信息。确保将防病毒配置文件应用于适当的安全策略。没有选项可以将某些 IP 地址排除在防病毒的例外设置中。提交更改。

解决方法我应该升级 PAN OS 吗？有哪些建议和风险？有其他人可以分享他们的经验吗？在努力解决有关升级的重要问题时，您并不孤单，升级是本周讨论 (DotW) 中值得特别关注的话题我们的许多社区成员加入了讨论，分享了他们的经验、建议和观点。第一个要问的问题是“我为什么要升级？” 正如用户 Brandon_Wertz 指出的那样。以下是升级的最常见原因：拥有最新的 PAN-OS 版本。使用新的 PAN-OS 版本中提供的一些新功能。获取当前 PAN-OS 版本中不可用的特定修复程序。让我们更详细地看看这些关键原因：拥有最新的 PAN OS 版本尽管一般的思路可能是越新越好，但在做出此假设之前需要考虑一些事项。让我们使用用户 jprovine为示例，他计划从 PAN-OS 6.1.7 升级到 PAN-OS 7.0.3，PAN-OS 上两个不同主要大版本和次要小版本。通常情况下，我们会在主要版本（6.0、6.1、7.0 等）中添加功能和优化。次要版本通常会针对该特定版本之前出现的问题进行错误修复和补丁。使用最新 PAN OS 版本中提供的新功能是一个有效的升级理由。用户 mlinsemier 和 Brandon_Wertz 都分享了他们在该主题上的经验。需要考虑的是新功能是否对业务至关重要，或者只是拥有也不错。此外，您会立即升级还是知道很快就会有更新的版本，所以选择等待一段时间？额外几天的等待可以节省升级两次的需要。这是在几个用户讨论等待 PAN OS 7.0.4 的讨论中提出的。有关 PAN OS 7.0.x 中新功能的一个很好的概述，请参阅PAN-OS 7.0 新功能(PAN-OS 7.0 new features.)。获得特定修复也是升级的正当理由。但是，即使在这种情况下，也有一些注意事项。在当前的 PAN OS 版本中有一个解决方法可能会使您无需立即升级。在某些情况下，如果特定功能不对商业业务造成关键影响，您甚至可以禁用它。那么风险呢？如果您正在升级，目标是尽可能降低和控制风险。以下是一些可帮助您降低与升级相关的风险的建议：如果您计划升级，请查看软件更新随附的发行说明。发行说明中有一个标题为“已知问题”的部分。您可以在PAN-OS 软件更新页面 (PAN-OS Software Updates )上找到发行说明。（需要支持帐户才能访问此页面）拥有这样的讨论论坛很有用，用户可以在其中分享他们的经验。理想情况下，在维护窗口期间计划升级，以尽量减少对生产环境的影响。在开始升级之前，请务必备份您的配置。请注意，提示和指示不限于上面的列表，但它是您升级路径的一个很好的起点。您可以在此处的链接7.0.3 Upgrade (7.0.3 Upgrade)中关注所以相关讨论。欢迎在讨论中添加您的经验和评论。一如既往，我们欢迎在下方提供反馈和意见。谢谢阅读。

目标解决Panorama日志查询不显示任何日志或停止显示从防火墙日志到特定日志收集器的日志的问题。环境 Panorama 日志收集器(Log-collector) 所有PAN-OS 程序 1.确保防火墙正在将日志转发到日志收集器上。而且最新的日志已经被转发了。 show logging-status Log Collector : <log-collector-serial-number> Connection IP : <log-collector-ip> Type Last Log Rcvd Last Seq Num Rcvd Last Log Generated traffic 2019/04/11 11:42:41 2019/04/11 11:42:42 6609236175355591718 6609236175355518694 50331542011 threat 2019/04/11 11:42:33 2019/04/11 11:42:34 6609236125161751868 6609236125161751455 349295414 在日志收集器上确认它已经收到日志。 > show logging-status device <firewall-serial-number> 2. 确保日志收集器有今天的es-indices，而且正在增加。并确保在Panorama上也能看到。这证实并说明了日志已经被索引并存储在日志收集器中。 dmin@Logger> show log-collector-es-indices | match 20190410 green open pan_20190410_trsum_<log-collector-serial-number> 4 0 104857195 0 28.9gb 28.9gb green open pan_20190410_all_<log-collector-serial-number> 8 0 803025297 0 297gb 297gb admin@PANORAMA> show log-collector-es-indices log-collector-grp-name <log-collector-group-name> | match 20190410 green open pan_20190410_trsum_<log-collector-serial-number> 4 0 104857195 0 28.9gb 28.9gb green open pan_20190410_all_<log-collector-serial-number> 8 0 803025297 0 297gb 297gb 3. 检查panorama和日志收集器的网络统计输出。检查日志收集器是否显示panorama连接已建立。而panorama显示日志收集器连接已建立。 admin@Logger> show netstat all yes numeric yes | match <panorama-ip> tcp 0 0 <log-collector-ip>:42795 <panorama-ip>:3978 ESTABLISHED admin@PANORAMA(primary-active)> show netstat all yes numeric yes | match <log-collector-ip> tcp 0 0 <panorama-ip>:3978 <log-collector-ip>:42795 ESTABLISHED 4. 在这时候，当日志从防火墙发送到日志收集器，并且日志收集器已对其进行正确索引，我们需要确保在日志收集器上可以看到panorama发送给日志收集器的日志查询，并且被正确处理。我们可以运行下面的调试来找出全panorama无法从日志收集器获取日志的原因。启用以下调试进行追踪。(注意：管理服务器调试是资源密集型的，在运行它们之前请谨慎行事或联系工程师) > debug management-server tracing set marker test level high type query > debug management-server on debug > debug reportd on debug 在此之后，我们可以在日志收集器中检查reportd的日志，找到在panorama上运行的查询和向日志收集器发出的请求以及日志收集器的响应。 2019-04-11 13:26:48.192 +0530 跟踪：test_6399 pan_handle_logger_dlcq_init(pan_cfg_logmgr_task.c:12436)。Q: INIT. remote_job_id 6399, query_id 12794, rectype traffic, direction 1, num_recs_buffered 1100, num_segments 512, query '(((receive_time leq now)) and (device-group eq 'FW-DG')), query_len 65 调试结束后，确保我们清除了管理-服务器和reportd上的跟踪和调试。这些调试为我们提供了在panorama上运行的日志查询的宝贵信息，并帮助我们理解为什么我们没有得到回应。你可以从panorama和日志收集器中收集技术支持文件，并将其上传到技术案例中，以便进一步调查。

问题 Palo Alto Networks 为新发布的 CVE提供覆盖的时间大约是多久？ CVE 有哪些资格才能成为 IPS（入侵防御系统）签名的良好候选？新创建的 IPS（入侵防御系统）签名的默认操作是什么？环境所有PAN-OS 所有 PAN 产品回答问题 1： Palo Alto Networks 为新发布的 CVE提供覆盖的时间大约是多久？回答：美国国土安全部 (DHS) 网络安全部门和基础设施安全局 (CISA) 追踪保存记录并为常见漏洞和暴露 (CVE) 提供名称（和 ID）。一旦CVE 威胁发布后，Palo Alto Networks 工程师便开始着手创建漏洞签名以保护 CVE威胁。创建漏洞签名有两个主要条件：有效的概念证明 (POC)应该公开供 Palo Alto 工程师创建保护或漏洞签名。工程师和安全研究人员使用 PoC 重新创建漏洞以创建保护；没有 PoC 意味着没有签名。尽管未创建签名，但这并不意味着它没有创建，因为您的网络已暴露。如果没有可用的 PoC，也意味着恶意行为者不知道如何利用它，也无法利用漏洞。第二个条件是CVE 应该是基于网络的，而不是完全基于主机的。防火墙只能看到网络流量，如果恶意流量没有通过它，就无法检测或阻止。问题二：如果没有找到PoC，下一步怎么办？回答：一旦 CVE 发布，我们就会将其放入 Palo Alto Networks 的内部漏洞监控系统。这个自动系统监控所有可用的公共/私人资源，例如 Telus、MAPP、GitHub、google bug、exploit-DB、内部发现的 bug 等等。一旦系统自动找到可用的 PoC，会生成通知告诉工程团队，工程师团队会在可能的情况下开始创建签名。问题三：如果发现PoC，需要多长时间创建IPS签名？回答：创建一个单一的质量漏洞 IPS 签名会经历许多阶段，包括研究、创建、浸泡测试、质量保证以及发布前和发布后的调整。它经过调整以涵盖可能利用的所有途径，同时避免产生误报。有时由于其他因素，如通用漏洞评分系统（CVSS）得分和不被用于攻击的可能性，Palo Alto Networks 内容开发团队可能会决定不使用现有有效的基于网络的 PoC 创建 IPS 签名。问题四：新建IPS签名的默认动作是什么？回答：我们将最开始几天的默认操作设置为“警报（alert）”以进行观察。可以根据严重程度等级进行更改的操作。如果您想要阻止符合IPS签名的严重等级重：最重要（critical）的和重要（high）的流量，可以根据严重等级程度创建一个 IPS 规则来覆盖默认操作。有关详细信息，请查看此处。

解决办法概述本文档可用于验证IPSEC隧道的状态、验证隧道监控、清除隧道和恢复隧道。详细信息 1. 手动启动 VPN ike 1阶段和 2阶段的 SA。 VPN 隧道只有当有有流量发往隧道时才会进行协商。（按需）如果您想手动启动隧道，没有实际流量，您可以使用以下命令。注意：手动启动只能从 CLI进行。 > test vpn ike-sa Start time: Dec.04 00:03:37 Initiate 1 IKE SA. > test vpn ipsec-sa Start time: Dec.04 00:03:41 Initiate 1 IPSec SA. 2. 检查 ike 1阶段的状态（在 ikev1 的情况下） GUI：导航到 Network->IPSec Tunnels 绿色表示打开红色表示关闭您可以单击 IKE 信息以获取一阶段SA 的详细信息。 ike 一阶段 sa 打开：如果 ike phase1 sa 关闭，则 ike 信息将为空 CLI: ike 1阶段 sa 打开 > show vpn ike-sa IKEv1 phase-1 SAs GwID/client IP Peer-Address Gateway Name Role Mode Algorithm Established Expiration V ST Xt Phase2 -------------- ------------ ------------ ---- ---- --------- ----------- ---------- - -- -- ------ 38 203.0.113.100 ike-gw Init Main PSK/DH20/A256/SHA512 Dec.03 22:37:01 Dec.04 06:37:01 v1 13 1 1 Show IKEv1 IKE SA: Total 1 gateways found. 1 ike sa found. IKEv1 phase-2 SAs Gateway Name TnID Tunnel GwID/IP Role Algorithm SPI(in) SPI(out) MsgID ST Xt ------------ ---- ------ ------- ---- --------- ------- -------- ----- -- -- ike-gw 139 ipsec-tunnel:lab-proxy 38 Init ESP/DH20/tunl/ A25ADE56 C79A64B7 B3E9927A 9 1 Show IKEv1 phase2 SA: Total 1 gateways found. 1 ike sa found. There is no IKEv2 SA found. ike 1阶段 sa 关闭： ike phase1 sa down: > show vpn ike-sa There is no IKEv1 phase-1 SA found. 或者 > show vpn ike-sa IKEv1 phase-1 SAs GwID/client IP Peer-Address Gateway Name Role Mode Algorithm Established Expiration V ST Xt Phase2 -------------- ------------ ------------ ---- ---- --------- ----------- ---------- - -- -- ------ 38 203.0.113.100 ike-gw Init Main PSK/ / / v1 3 2 0 Show IKEv1 IKE SA: Total 1 gateways found. 1 ike sa found. 如果1阶段SA 关闭，您将看不到对端 IP 和已建立的连接状态。对于 ikev2，当你点击IKE信息时，IKE信息的细节显示是一样的： GUI: Ikev2 CLI: > show vpn ike-sa There is no IKEv1 phase-1 SA found. There is no IKEv1 phase-2 SA found. IKEv2 SAs Gateway ID Peer-Address Gateway Name Role SN Algorithm Established Expiration Xt Child ST ---------- ------------ ------------ ---- -- --------- ----------- ---------- -- ----- -- 38 203.0.113.100 ike-gw Resp 2 PSK/DH20/A256/SHA512 Dec.04 00:10:58 Dec.04 08:10:58 0 1 Established IKEv2 IPSec Child SAs Gateway Name TnID Tunnel ID Parent Role SPI(in) SPI(out) MsgID ST ------------ ---- ------ -- ------ ---- ------- -------- ----- -- ike-gw 139 ipsec-tunnel:lab-proxyid1 2 2 Resp DA76A187 9E1E9372 00000001 Mature Show IKEv2 SA: Total 1 gateways found. 1 ike sa found. 3. 检查第 2 阶段 ipsec 隧道是否启动： GUI：导航到 Network->IPSec Tunnels 绿色表示向上红色表示向下您可以单击隧道信息以获取 Phase2 SA 的详细信息。 CLI: > show vpn ipsec-sa GwID/client IP TnID Peer-Address Tunnel(Gateway) Algorithm SPI(in) SPI(out) life(Sec/KB) -------------- ---- ------------ --------------- --------- ------- -------- ------------ 38 139 203.0.113.100 ipsec-tunnel:lab-proxyid1(ike-gw) ESP/G256/ F2B7CEF0 F248D17B 2269/0 4. 检查隧道间的加密和解密（encap/decap） > show vpn flow total tunnels configured: 1 filter - type IPSec, state any total IPSec tunnel configured: 1 total IPSec tunnel shown: 1 id name state monitor local-ip peer-ip tunnel-i/f -- ---- ----- ------- -------- ------- ---------- 139 ipsec-tunnel:lab-proxyid1 active off 198.51.100.100 203.0.113.100 tunnel.1 注意：对于隧道监控，监控状态为down表示被监控的目的IP不可达，off表示没有配置隧道监控。请注意隧道 ID，在此示例中 - 隧道 ID 为 139 > show vpn flow tunnel-id 139 tunnel ipsec-tunnel:lab-proxyid1 id: 139 type: IPSec gateway id: 38 local ip: 198.51.100.100 peer ip: 203.0.113.100 inner interface: tunnel.1 outer interface: ethernet1/1 state: active session: 568665 tunnel mtu: 1432 soft lifetime: 3579 hard lifetime: 3600 lifetime remain: 2154 sec lifesize remain: N/A latest rekey: 1446 seconds ago monitor: off monitor packets seen: 0 monitor packets reply:0 en/decap context: 736 local spi: F2B7CEF0 remote spi: F248D17B key type: auto key protocol: ESP auth algorithm: SHA512 enc algorithm: AES256GCM16 proxy-id: local ip: 10.133.133.0/24 remote ip: 10.134.134.0/24 protocol: 0 local port: 0 remote port: 0 anti replay check: yes copy tos: no enable gre encap: no authentication errors: 0 decryption errors: 0 inner packet warnings: 0 replay packets: 0 packets received when lifetime expired:0 when lifesize expired:0 sending sequence: 4280 receive sequence: 4280 encap packets: 8153 decap packets: 8153 encap bytes: 717464 decap bytes: 717464 key acquire requests: 90 owner state: 0 owner cpuid: s1dp0 ownership: 1 多次运行命令 show vpn flow tunnel-id <id>，查看计数器值的趋势。身份验证错误、解密错误、重放数据包的不断增加表明隧道流量存在问题。当隧道中有正常的流量时，encap/decap packets/bytes 会增加。 5. 清除以下命令将拆除 VPN 隧道： > clear vpn ike-sa gateway <gw-name> Delete IKEv1 IKE SA: Total 1 gateways found. > clear vpn ipsec-sa tunnel <tunnel-name> Delete IKEv1 IPSec SA: Total 1 tunnels found.

解决方案在你按照入门系列的前几篇文章设置了你的防火墙后，你可能需要开始设置服务器。除非你拥有一个足够大的公共IP子网来承载你所有的内部主机，下面的详细信息将指导你如何配置网络地址转换（NAT）或端口地址转换（PAT），使主机可以从外部到达，或使用一个特定的IP去到互联网。在这一部分中，我将讨论，在确定如何配置NAT或PAT以最好地满足你的需要时，可能会用到的一些情况，并提出一些需要注意的事项。多对一（Many-to-One），Hide NAT，源NAT（Source NAT） Hide NAT是最常使用的地址转换。它将所有内部子网隐藏在一个单一的外部公共IP后面，与此类似: 这个NAT策略将转换所有来自信任区（trust zone）的会话，去到非信任区（untrust zone），并将源地址改变为分配给外部物理接口的IP。它还将随机化源端口。返回的数据包将自动被反向转换，因为防火墙维护着一个跟踪所有活动会话及其NAT操作的状态表。多对多NAT（Many-to-Many NAT）简单的Hide NAT策略的变体是，如果有更多的源地址可用，就添加更多的源地址。例如，如果你的ISP提供了一个/29或更大的公共子网，你有额外的IP地址可以用于各种事情。如果你的内部网络相当大，可能需要这些额外的地址来防止NAT池的超额订阅。对于这种配置，地址类型从 "接口 "改为 "转换地址"。然后，可用的IP地址被添加为一个IP范围，或一个IP子网：防火墙将根据源IP地址的哈希值，从可用池中选择一个IP。对于来自该源IP的所有会话，该源地址将保持不变。源端口仍将是随机的。如果源端口需要保持不变（一些应用程序可能需要一个特定的源端口），转换类型可以设置为动态IP，这将保留客户端的每个会话的源端口。转换的地址是通过 "下一个可用 "来分配的，意味着有一些注意事项：支持不超过32.000个连续的IP地址转换的地址池需要与你的内部主机数量相同或更大，因为每个内部主机都被分配自己的转换地址。如果上述标准通常都能满足，但有时可能会被打破，可以设置一个备份，以便失败时返回到动态IP和端口。转换地址和接口地址选项都可以使用，默认是没有：一对一NAT, 静态NAT 如果你需要从互联网上提供一个服务器，如本地SMTP或Web服务器，需要创建一个一对一的NAT策略，将传入的连接转发到一个特定的服务器。有几种不同的方法来完成这个任务：双向策略（Bi-directional policy）：在双向策略中，像上述NAT策略一样，创建常规的出站静态NAT策略，并设置双向标志（bi-directional flag），这允许系统创建一个（看不见的）隐含的入站策略。该策略将来自信任区（trust），目的地为非信任区（untrust），源地址设置为服务器的内部IP，源转换为其公共NAT地址。一个隐含的策略将被创建，其源区（source zone）为不信任区（untrust），目的地为任何（Any），目的IP为公共NAT地址，目的转换为服务器的IP地址。这是创建几个一对一转换的简单方法，如果几个服务器都有自己独特的公共IP地址，就能完美地工作，这给我们带来: 单一方向的策略（Uni-directional policy）：单一方向的NAT允许对策略的控制比双向的多一点，它允许PAT/端口地址转换。PAT使你能够在不同的内部服务上共享一个公共IP地址。在接下来的3条规则中，你可以看到3个不同的入站静态NAT的例子：规则#1是一个传统的一对一规则，将所有入站端口转换到内部服务器，并保持目标端口规则#2只将目的端口80的入站连接转换到端口8080的内部服务器上规则#3像规则#2一样，转换同一公共IP地址的入站会话，但目的端口25到不同的内部服务器保持目的端口25 注意事项：为什么目的区域（destination zones）被设置为不信任（untrust），什么是目的接口？ "任何 "（any）可以作为一个入站（非信任到非信任）（untrust to untrust）NAT的目的地址吗？安全策略应该被设置为源区（source zone）是不可信任的，目的区（destination zone）（最终目的区）是信任的，目的地址是公共地址，预NAT（pre-NAT）。源和目的NAT 在某些情况下，可能需要同时执行源和目的NAT。一个常见的例子是U-Turn情况，即内部主机需要连接到一个内部服务器，该服务器与客户端在同一网络上，使用它的公共IP地址。已经有一篇很好的文章和一个教程视频更详细地介绍了U-Turn，但简短的描述是这样的：为了能够在一个公共IP上到达内部资源，需要创建一个新的NAT策略，以适应信任到不信任的（trust to untrust）转换。如果源转换（source translation）不包括在这个策略中，服务器将收到原始源地址的数据包，导致服务器直接向客户发送回复数据包。这就形成了一个不对称的循环：客户端-防火墙-服务器-客户端，防火墙会话将被终止，因为它违反了TCP的完整性检查。解决办法是添加源转换，例如，防火墙IP，因此服务器的回复数据包被发送到防火墙，允许 "有状态（stateful）"会话。额外的：VWire上的NAT 如果您能够编辑路由器上的路由表，也可以在VWire上实现NAT（一个ISP路由器可能不允许这样做）。理想情况下，你在VWire的两端都有一个路由器，以保持事情的简单性，但如果你想挑战一下，你也可以只用一个上游路由器来实现: 在两个路由器之间，你应该创建一个小的点对点子网，例如，10.0.0.0/30。给每个路由器分配一个IP，并在位于转换一侧的路由器上为转换后的IP地址添加路由，例如，在不信任的路由器上为198.51.100.1添加路由，指向信任路由器的IP。防火墙会处理剩下的事情。注意事项区域的解决（Zone resolution）是通过路由查询实现的。当防火墙收到一个数据包时，会进行路由查询，以检查源子网和目标子网的路由位置，并将适当的区域（zone）分配给该会话。在来自互联网的入站流量的情况下，源区（source zone）将是不信任的（untrust），因为默认路由0.0.0.0/0指向不信任的接口，而目的IP地址pre-NAT，也是不信任的，因为它是连接到不信任的接口的IP（上述例子中的198.51.100.0/24）。在NAT策略中使用目的接口（destination interfaces）可以帮助防止在使用类似的NAT策略时发生冲突。例如，如果存在两个外部接口，到两个不同的ISP，保持不同的公共IP地址，可以配置两个相同的出站NAT规则。假如使用的NAT IP没有在接口上进行物理配置（例如，接口198.51.100.1 ，为服务器198.51.100.5做NAT），防火墙将发送无故ARP数据包，通知邻居它承载了一个IP地址，并将回复上游设备的ARP请求。无故ARP也可以手动触发：admin@MyFW> test arp gratuitous interface ethernet1/1 ip 198.51.100.6 发送了1个ARPs 注意：如果一个NAT规则被配置为将转换应用于一个没有配置在接口上的子网，防火墙将为该子网的所有IP地址发送无故ARP。由于防火墙为目的（入站）NAT的目的地址中列出的地址提供代理ARP解析，目的地址子网必须与目的转换子网相匹配。不允许使用 "任何（any）"作为目的地址。当为内部客户端创建NAT策略以通过其公共IP到达dmz或受信任网络（trusted network）中的服务器时，无论如何确保将其置于Hide-NAT策略之上。超额订阅（Oversubscription）当防火墙有多个（两个或更多）并发会话共享同一转换的IP地址和端口对时，就会发生超额订阅，并且当公共 IP 地址对于正在创建的会话数量来说太少时会提供可扩展性。例如，通常情况下，并发会话的最大数量是64K（65.000个源端口减去1024个 "服务器 "端口）。根据平台，超额订阅允许每个IP最多有512K并发会话，超额订阅为8x。一些相关的文章：如何改变NAT超额订阅率（How to Change the NAT Oversubscription Rate）如何检查NAT规则的超额订阅（How to Check the Oversubscription on a NAT Rule）

决议我的防火墙还能做什么？识别用户。让我们仔细看看有哪些选项可以通过用户的用户名来识别用户，以及可以用这些信息做什么。我们将查看User-ID客户端的配置，并将其与无客户端部署进行比较，设置俘虏式门户，并准备在安全策略中使用组映==射。准备Windows 在你开始工作之前，请下载用户识别代理。它可以在Support Portal网站的软件更新下找到。下载完安装程序后，我们建议将其安装在你的活动目录服务器上，但如果你喜欢使用不同的服务器，这并不是严格的要求。由于Windows服务器上的UAC（用户访问控制）设置，我们建议以管理员身份运行安装程序。用 "以管理员身份运行 "选项打开一个命令提示符，导航到包含安装程序文件的文件夹，并从命令行中执行安装程序。安装过程完成后，从开始菜单中打开User-ID Agent，进入设置。点击编辑，开始配置User-ID代理。你需要配置的第一件事是该服务将以何种用户名运行。确保该账户至少被授予以下权限（不正确/不完整的权限可能导致 "启动服务失败，错误1069 "的错误信息），请按照这篇文章一步一步地设置用户权限。How to Install User-ID Agent and Prevent 'Start service failed with error 1069' -事件日志阅读者（在Windows 2003中审计和管理安全日志） -服务器操作员（以服务形式运行） -DCOM用户（用于WMI探测）如果这有点混乱，请暂时将账户设置为管理员。代理人接收到的登录_成功和Auth_ticket_granted/renew事件如下所示 admin guide -Windows Server 2003-所需事件的事件ID是672（验证票授予）、673（服务票授予）和674（票授予更新）。 -Windows Server 2008/2012（包括R2）或MS Exchange--所需事件的事件ID是4768（验证票授予）、4769（服务票授予）、4770（票授予更新）和4624（登录成功）。最后，在ActiveDirectory准备列表中，确保启用成功的审计，以便在AD日志中捕获登录事件。 User-ID代理的配置现在让我们来配置UID代理。如果你还没有专门的用户，请将用户设置为管理员，这可以在以后更改，当你对设置感到满意并有时间阅读进一步的建议时。配置的第一个标签将让你设置用户名。下一个标签将有读取日志的频率。这将设置代理要轮询事件日志的频率，并寻找成功的登录事件，将源IP及其相关的用户账户添加到用户-IP列表中。在大多数情况下，推荐使用1秒的默认设置。可以启用服务器会话来监控客户与服务器的连接。当大多数客户在AD上有一个驱动器映射，用来验证一个用户账户是否仍在登录并连接到其共享。客户端探测选项(Client Probing)让你控制是否以及如何定期探测客户机，以查看一个账户是否仍在登录中。这些探测将能够在机器登录到本地账户或突然从网络中删除用户-ip映射。然而，需要进行一些规划，因为目标机器确实需要支持这些探针。由于防火墙策略导致的探测失败，或者如果客户没有授权wmi到User-ID代理账户，将导致用户-ip映射也被删除。如果你不确定你的客户是否能够支持探测，请暂时禁用这两个探测。缓存选项(Cache)允许对用户-IP映射中的条目设置一个超时时间。特别是当探测功能被禁用时，这很有价值，因为它允许你删除 "陈旧 "的用户-IP映射。如果检测到一个ActiveDirectory成功的日志事件，超时就会被刷新。在一个相当静态的办公环境中，把这个超时设置为600分钟以上是安全的，因为默认的kerberos用户票的寿命是10小时。在一个有许多用户共享工作站的非常动态的环境中，将超时设置为一个较短的时间可能更有利。代理服务标签允许你改变服务对传入防火墙连接的默认监听端口。我们现在先不谈eDirectory和syslog标签，继续点击ok选项。你会看到你刚刚创建的配置的摘要和访问控制列表，你可以设置它来限制哪些IP地址或子网可以连接到User-ID代理。继续并提交新的User-ID代理配置。通过回到代理的主页面，快速确保服务正在运行。（Agent is running) 如果代理还没有启动，你可以从这里手动启动它点Start，或者停止 Stop。接下来，我们将配置代理要连接的ActiveDirectory服务器，以收集用户活动的信息。打开 "发现 "页面，点击 "自动发现"，这将通过使用本地机器信息来填充可用的服务器列表。其他服务器可以手动添加。如果一个服务器是多宿主，必要时可以删除多余的条目。包括/排除（Include/Exclude)列表允许你控制哪些子网应该或不应该被监测到用户登录事件。监控页面现在应该开始填入新的用户-IP映射。当User-ID代理第一次启动时，它将通过ActiveDirectory的最后50.000个日志条目，然后每秒钟监测新的条目。根据一天中的时间和你的服务器上的事件日志的聊天情况，可能需要一段时间才能在列表中填入可靠的活动IP地址数据库（在部署安全策略时考虑到这一点）。现在代理已经准备好了，打开防火墙GUI。在设备选项卡中，在用户识别中，可以使用我们在用户识别代理中使用的相同参数配置无客户端部署。这在一个较小的环境中或当访问ActiveDirectory不允许安装一个软件时，可能非常有用。我们不建议在大型环境中使用无客户端部署，因为这可能会导致大量的开销。为了连接到已安装的User-ID代理，我们需要跳到下一个标签，添加一个新的User-ID代理。为代理分配一个名称以方便识别，设置其IP和我们在代理配置的 "代理服务 "标签中配置的端口。只有当不同的防火墙被用作收集点，并且该防火墙需要从该防火墙收集信息时，才应使用收集器。如果Captive portal被配置为支持浏览器中的NTLM认证，则至少需要设置一个代理来充当代理。现在启用这个选项，因为一旦我们配置了Captive Portal，我将向你展示如何设置NTLM。下一步是为需要 UserID 的区域启用 User Identification。不建议为面向互联网的区域启用该功能，除非用户识别ACL被设置为只为该区域的特定子网执行用户识别。如果没有设置，防火墙将查询User-ID代理，了解连接到防火墙外部接口的每个IP地址的信息。前往 "网络 "标签，打开 "区域"，打开 "信任区"，并启用 "用户识别"。在所有需要的区域都被启用后，提交配置。提交完成后，流量日志将开始显示用户信息。强制门户认证 (Captive Portal) 对于任何不能通过传统的活动目录事件日志方式发现的用户，可以建立一个俘虏式门户系统，在这个系统中，浏览会话被拦截，用户的浏览器通过NTLM查询凭证信息，或者向用户提供一个网页表格，让用户输入用户名和密码。由于用户可能会被重定向到一个请求认证的门户页面，最佳的用户体验是拥有一个整个组织都信任的证书，所以如果有一个证书颁发机构可以创建一个服务器证书，这将使浏览器在用户被重定向时不会弹出错误信息。如果没有本地CA，可以生成一个自签名的证书并手动导入到客户端，以改善用户体验。前往 "Device "选项，生成一个新的自签名证书或导入一个组织证书。我把我的证书创建为一个证书颁发机构，但这并不是严格意义上的必要。作为通用名称，我设置了我的接口的IP地址，因为我将使用它作为重定向IP，但如果你有一个内部DNS服务器，你可以设置一个FQDN，如captiveportal.mycompany.com，并在重定向中使用它。接下来，你需要创建一个SSL/TLS服务配置文件，以便能够使用该证书作为俘虏式门户的服务器证书。选择你希望门户支持的TLS的最小和最大版本。在我们配置强制门户认证之前，还有一个步骤是启用认证。转到LDAP服务器配置文件，为活动目录服务器创建一个新的LDAP配置文件。然后创建一个认证配置文件。请确保为你的环境适当地设置登录属性。对于活动目录，这通常是 "sAMAccountName"。在 "高级 "选项中，你可以限制允许认证的用户组，但现在，我们要将其设置为 "所有"。接下来，强制门户认证。你要启用重定向模式，因为这将把用户重定向到防火墙界面上的一个登陆页面。这将允许在上一步创建的证书向用户展示一个适当的浏览器体验。如果不启用转接模式，防火墙将冒充原始目标URL，调用HTTP 401认证请求。然而，由于这种认证的内联性质，客户端将不会得到适当的证书，并将始终得到一个证书错误。 -设置SSL/TLS服务配置文件设置为Captive Portal证书。 -设置认证配置文件设置为ldap认证配置文件。 -设置重定向主机设置为防火墙的接口IP。如前所述，这可以是一个解析到IP的FQDN，并在证书中设置为通用名称。为了使重定向发挥作用，该接口需要启用响应页。这些可以通过接口管理配置文件来启用。在入门系列的Layer3部分中，我们介绍了添加接口管理配置文件以允许ping--我们可以编辑该配置文件以允许响应页。最后一步是创建Captive Portal策略。创建一个策略，动作设置为浏览器挑战，并在下面创建第二个策略，使用web-form动作。浏览器挑战策略将尝试对浏览器进行NTLM兼容认证。如果失败，第二个策略将向用户提供一个Web表单，让他们填写用户名和密码。组图(Group Mapping) 由于你已经创建了一个LDAP配置文件，一个额外的步骤将允许从活动目录中收集组信息。然后，这些组信息可以用来创建安全策略，根据用户账户和组成员资格允许或拒绝用户。在 "用户识别 "的 "设备 "选项卡上，进入 "group mapping"设置 "并创建一个新的配置文件。将服务器配置文件设置为LDAP配置文件，将用户域设置为NetBios域。更新间隔默认为3600秒（60分钟）。如果你的用户经常在不同的组之间更换，减少这个时间间隔可能是有益的。在 "包括组 "列表中，你可以专门选择哪些组来检索到防火墙。在你选择了你要使用的组之后，提交配置。提交完成后，这些组将在安全策略用户字段中可用。现在你可以根据用户组建立安全策略。 CLI命令有几个CLI命令可以派上用场，以验证所有用户的身份是否正确，组的信息是否准确。 show user group name <groupname> 来查看组的成员 > show user group name "cn=domain users,cn=users,dc=example,dc=com" short name: example.com\domain users source type: ldap source: groupmapping [1 ] example.com\administrator [2 ] example.com\astark [3 ] example.com\bstark [4 ] example.com\cgrimes [5 ] example.com\dtargaryen [6 ] example.com\jlannister [7 ] example.com\jsnow [8 ] example.com\lgrimes [9 ] example.com\rgrimes [10 ] example.com\tlannister [11 ] example.com\varys show user group-mapping state all 查看组映射配置文件的状态，以及刷新/最后一次刷新前的时间。 > show user group-mapping state all Group Mapping(vsys1, type: active-directory): groupmapping Bind DN : administrator@example.com Base : DC=example,DC=com Group Filter: (None) User Filter: (None) Servers : configured 1 servers 10.192.16.98(389) Last Action Time: 3418 secs ago(took 0 secs) Next Action Time: In 182 secs Number of Groups: 3 cn=it staff,cn=users,dc=example,dc=com cn=human resources,cn=users,dc=example,dc=com cn=domain users,cn=users,dc=example,dc=com show user ip-user-mapping all 查看所有当前识别的活跃用户以及他们是如何被识别的。 > show user ip-user-mapping all IP Vsys From User IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 10.0.0.188 vsys1 UIA example\rgrimes 1304 1304 10.0.0.29 vsys1 CP example\administrator 561 2593 Total: 2 users > show user ip-user-mapping all type AD Active Directory CP Captive Portal EDIR eDirectory GP Global Protect SSO SSO SYSLOG Syslog UIA User-ID Agent UNKNOWN Unknown XMLAPI XML API

下面的步骤描述了如何对Palo Alto Networks设备进行出厂重置。注意：如果运行的是PAN-OS 8.1.x及以上版本，请查看以下链接来执行SSH进入维护模式。 How to SSH into Maintenance Mode 步骤 1）将Palo Alto Networks提供的console（控制台）电缆从 "控制台 "端口连接到计算机，并使用终端程序（9600,8,n,1）连接到Palo Alto Networks设备。注意：如果电脑没有9针串口的端口，就必须使用USB转串口的端口。 2) 打开电源，重新启动设备。 3) 在启动程序时，屏幕应该是下面这样的。 1) 输入 maint，进入维护模式。 2) PAN-OS 7.1 注意：在PAN-OS 7.1上执行这个操作时，你会看到一个 "选择PANOS "的屏幕，有以下选项。PANOS (maint-other), PANOS (maint) 或 PANOS (sysroot0)。请选择PANOS(maint)。按回车键继续。 PAN-OS 7.1 GNU GRUB启动菜单。 3) 进入维护模式后，会显示以下内容，请按回车键继续。 4) 按向下箭头移动到 "Factory Reset出厂重置"，然后按回车键显示菜单。 5) 你将看到如下用于执行出厂重置的界面。选择 "出厂重置"，并再次按回车键。 6) 出厂重置完成后，设备将重新启动。请注意，自动提交可能需要几分钟时间才能完成，然后管理员/管理人才可以正常登录。另请参见 Admin-Admin not Working After Factory Reset

解决方案概述本文介绍了如何创建自定义URL分类列表，在URL过滤配置文件中使用该列表，然后应用在安全策略的步骤。操作步骤 1.PAN-OS 8.1及以上版本，进入“OBJECTS” > “自定义对象”>“URL类别”并点击“添加”。 2.填写名称、说明并选择类型。类型分为URL list和Category Match。每行输入一个条目。注意：URL的列表也可以从文件中导入。将自定义类别应用于URL过滤配置文件。 1.进入 "Objects">"安全配置文件">"URL过滤"，然后点击 "添加"。 2.命名配置文件。注意：自定义URL类别条目，旁边有一个星号。在安全策略中应用URL过滤配置文件。 1.转到“POLICIES”> “安全”。 2.选择或创建一个安全策略。 3.“操作”在“配置文件设置”下，为“URL过滤”选择创建好的自定义配置文件。 4.提交变更。派拓网络防火墙将按以下优先顺序处理URL列表。阻止列表允许列表自定义类别预先定义的类别

关键词 RMA 开发设备管理初始配置安装硬件 PAN-OS 标题如何配置RMA防火墙环境在Panorama 管理下的 Palo Alto 防火墙 PAN-OS 解决方案概述：要更换或维修防火墙，请向授权的支持供应商开立一个请求RMA的案件。本文件讨论了如何为生产环境准备RMA防火墙。如果您需要更换HA设备，可以参考以下链接如何配置一个 High Availability RMA设备步骤：注册新的防火墙并转移许可证。收到RMA设备后，注册新设备，并从旧设备转移许可证。在Palo Alto Networks收到故障设备后，旧的许可是被剥离的状态，所以立即转移许可是很重要的。关于如何转让许可证，请参考以下说明：如何将许可证转移到备用设备上。配置管理接口默认的管理界面IP是192.168.1.1，默认的登录/密码是admin/admin。配置NTP (Device > Setup > Services) 或日期和时间 (Device > Setup > Management > General Settings)。配置管理端口，使其能够访问互联网，并在Device > Setup > Services下配置DNS服务器。此界面应能访问 updates.paloaltonetworks.com。或者，配置service route，以启用一个具有互联网访问权限的第3层接口进行管理。必须在设备上配置对应的接口、路由和策略。进入Device > Setup > Service Route配置，为paloalto-updates和dns选择适当的接口IP地址。下面提供一个例子注意：请参考如何配置管理口IP来设置管理界面的IP地址。检索以前转移到设备的许可证。Device > Licenses > Retrieve license keys from license server。每个功能的许可证显示在同一页上。请确保有一个URL filtering license，URL filtering被激活，并且数据库已被成功下载。如果显示的是"Download Now" 的链接，那么数据库就没有被下载。一个成功激活和下载的PAN-DB URL filtering 数据库如下图所示。设备现在已经准备好升级了。从 Device > Dynamic Updates > Applications and Threats > Check Now下载并安装可用的应用程序或Apps+Threats。设备会列出要下载和安装包。要更新PAN-OS，请进入Device > Software > Refresh。关于PAN-OS升级的其他信息： How to Upgrade PAN-OS and Panorama 采用与旧防火墙相同的multi-vsys或jumbo-frames（如果适用）。: > set system setting multi-vsys on > set system setting jumbo-frame on 要在RMA设备上加载先前备份的配置，请遵循以下使用案例。注意：在恢复配置之前，如果主密钥已被更改，请将更改后的主密钥添加到防火墙上。否则，你将无法将配置提交给防火墙。案例1：旧设备仍然连接在网络上，防火墙没有使用Panorama管理。假设新防火墙上只有管理平台被连接。在旧设备上，保存Device > Setup > Save Named Configuration Snapshot，然后导出Device > Setup > Export Named Configuration Snapshot。在新设备上，进入Device > Setup > Import Named Configuration Snapshot，将备份的配置导入到设备上。在配置被导入后，加载导入的配置，进入Device > Setup > Load Named Configuration Snapshot。更改管理IP和主机名，这样在连接到同一管理网络时就不会与现有设备产生冲突。如果需要的话，之后可以把它改回来。解决可能存在的commit错误并commit配置。移除旧设备，将网线移到新设备上。案例2：旧设备仍然连接在网络上，防火墙使用Panorama管理。假设只有新设备的管理平台被连接，进入旧设备并导出设备状态：Device > Setup > Export Device State. 转到新设备，进入 Device > Setup > Import Device State，将备份的设备状态导入到新设备上。这样的话，防火墙将获得与旧设备完全相同的设置（也是相同的IP和主机名）。不需要加载任何配置。这时，已经可以删除旧防火墙。在Panorama CLI上，用新的序列号替换旧的序列号：replace device old <old SN#> new <new SN#> 同时 commit local and push commit to firewall，也能够同步成功。案例3：旧设备不能再进行备份，防火墙不能从Panorama管理。当不再能访问设备时，需要寻找曾经储存的配置。包括寻找tech support files，这些文件可以在旧的case或你的环境中找到，可能被保存在某个地方。永远记得备份配置。从旧的防火墙中寻找旧的tech support。你可以从/opt/pancfg/mgmt/saved-config/running-config.xml获得配置文件。如果没有以前的技术支持，那么也可以使用防火墙的维护模式来备份旧的配置：如何在维护模式下提取Palo Alto Networks防火墙配置一旦找到tech support file，使用running-config.xml文件并将其导入新的防火墙。进入Device > Setup > Import Named Configuration Snapshot。Commit并确保设备已启动并运行。案例4：旧设备不再可以进行备份，防火墙由Panorama管理。假设只有新设备的管理平台被连接，进入旧设备并导出设备状态：Device > Setup > Export Device State. 从Panorama备份配置包。Panorama > Setup > Operations > Export Panorama and Devices config bundle。在这个文件中，有一个.xml文件，其名称包含旧防火墙的序列号。该配置可用于在新设备上加载。然而，这只是防火墙本地配置的副本，不包含 Panorama推送的配置。将IP分配给新的防火墙管理端口，并commit，以便在以下步骤中导入配置后将其连接到Panorama。在Panorama上用新的S/N替换旧的S/N: replace device old <old SN#> new <new SN#> and commit locally。不要将配置推送到新的防火墙上。从Panorama和设备配置包中，使用对应于旧设备S/N的配置，将其导入并加载到新的防火墙上。先不要commit。现在从Panorama推送一个DG和Template，commit到新防火墙上。这个commit应该合并candidate设备并从Panorama推送配置。如果没有commit error，设备应该已经启动并运行。案例5：旧的设备不再可用来进行备份，防火墙使用Panorama进行管理，但防火墙使用数据平面端口与Panorama进行通信，要求防火墙有完整的配置才能与之通信。完整配置包括 Panorama 管理的集中配置和防火墙的本地配置。这些防火墙的设备状态可以从管理的 Panorama 中生成和导出。 Panorama可以根据最后提交的本地配置加上Panorama配置来生成设备状态。请参考这篇文章如何从Panorama导出管理的防火墙的设备状态通过替换序列号和导入防火墙状态，我们可以恢复使用 Panorama 来管理防火墙。在Panorama CLI中使用命令：tftp export device-state device <serial number> to <server-ip> or scp export device-state device <serial number> to pantac@<scp-server-ip>:/home/ 下一步，使用设备状态将其导入新设备并使其恢复与Panorama的通信。在Panorama上用新的S/N替换旧的S/N： replace device old <old SN#> new >new SN#> and commit local。 Panorama现在应该显示新设备为 "connected"。进入 Panorama > Managed Devices > Summary 现在从Panorama推送一个DG和Template commit到新的防火墙。这个commit应该合并candidate设备并从Panorama推送配置。如果没有commit error，设备应该已经启动并运行。如果在源和目的NAT上使用任何NAT IP，这些IP与NAT接口在同一个子网中（除了接口本身的IP），将需要从防火墙上做一个手动的Gratuitous ARP来更新对等体的ARP表。例如，接口IP是198.51.100.1/24，而使用198.51.100.2做NAT，可能需要发送GARP到198.51.100.2。 > test arp gratuitous ip <ip> interface <interface> 返厂有缺陷的设备。要在送回前恢复出厂默认值，请参考如何对Palo Alto Networks设备进行出厂重置，如果运行PAN-OS 6.0及更高版本，请查看如何使用SSH进入维护模式，因为可以通过SSH进入维护模式。支持订阅包括提前更换故障防火墙的客户必须在收到更换的设备后将有问题的设备退回给Palo Alto Networks。美国客户--退货标签将与替换件一起放在纸箱中。将该标签贴在纸箱上，以退回有缺陷的设备。国际客户--请参考退货说明和替换件包装箱中的文件。其他：注意：在auto-commit过程中可能会有5-15个等待期，以便commit过程能够彻底完成。请参阅以下文章以了解更多细节: 如何确定自动提交完成的时间。

解决办法：我的防火墙还能做什么？自定义应用程序和应用程序覆盖! 根据你的环境，你可能有自定义创建的专有应用程序或你只想用自定义名称识别的流量。你可能正在运行一个通常被Palo Alto Networks防火墙识别为网络浏览的网络服务，使你更难创建报告，或者你可能想将QoS应用于使用共同App-ID的一组特定连接。为了解决这些问题，你可以创建与流量中的某个签名相匹配的自定义App-ID，或者使用应用程序覆盖来简单地强迫某些会话被识别为你配置的应用程序。基于签名的自定义应用程序依赖于App-ID引擎来积极地识别通过防火墙的数据包中的签名。如果你试图识别一个使用可预测或容易识别的签名的专有应用程序，你可以使用regex创建一个自定义应用程序来帮助识别签名。基于签名的自定义应用程序ID 当我们仔细观察从前往服务器的流量中捕获的数据包时，一个可识别的签名可以是主机名。要创建一个自定义应用程序，请前往应用程序并创建一个新的应用程序。设置应用程序属性，如果适用，设置父应用程序：当流量目前已经被识别为一个应用程序时，父应用程序被使用。这将有助于App-ID正确报告定制的应用程序。如果是目前没有被App-ID识别的专有应用程序，父应用程序可以保留为'无'。在 "高级 "选项卡中，你可以设置该应用程序将使用的端口或协议，还可以设置该应用程序是否可以被扫描以获取威胁。然而，有一些注意事项是需要考虑的。如果自定义应用程序的扫描选项未被选中，威胁引擎将在自定义应用程序被识别后立即停止检查流量。如果自定义应用程序没有可以通过常规App-ID识别的父应用程序，或用于应用程序覆盖（见下文），则不能对其进行威胁扫描。在签名标签中，你可以添加识别应用程序所需的所有签名。可以指示App-ID引擎在单个交易（从客户端到服务器或从服务器到客户端的单个数据包）或整个会话（一个或多个签名可能分布在任一方向的几个数据包中）中寻找潜在的签名。在哪里寻找签名以及在哪种情况下寻找签名，有很多选项可用。多个签名集也可以在 "AND "或 "OR "条件下添加。如果这一切看起来有点令人困惑，不要担心--我在最后添加了几篇有用的文章，将更深入地解释自定义签名可以实现什么。现在，我们将保持简单，在http请求主机头中寻找签名。我的签名将仅仅是主机名称的regex友好格式。这意味着在点的前面需要有一个反斜杠，以表示点是一个字符而不是通配符。我还将把限定符设置为http-method GET，以表明签名可以在GET请求中找到。一旦这个自定义应用程序被提交，防火墙将开始识别所有连接到我的网络服务器的新应用程序。我们现在可以根据定制的应用程序创建报告，并具体监测什么样的流量正在冲击我们的网站。如果应用程序可以很容易地被识别，上述步骤将完美地工作，但有时可能没有必要甚至不可能查看数据流并识别某个签名。应用覆盖应用程序覆盖强行绕过AppID过程，并设置会话以匹配手动配置的应用程序名称。任何像这样处理的会话都不会被并行处理所扫描，而会被卸载到fastpath。对于大多数使用情况，我们建议创建一个简单的自定义应用程序，属性尽可能少，因为应用程序覆盖将绕过扫描或签名检测。它将简单地将一个会话识别为自定义应用程序，并不采取进一步的行动。这可能是一个非常简单但强大的工具，有助于识别内部应用程序，并提高吞吐量，因为会话被立即卸载到硬件，但请考虑安全影响。

《概述》本文件描述了Palo Alto Networks防火墙上安全策略的基本原理。所有穿越Palo Alto Networks防火墙的数据平面的流量都与安全策略相匹配。这不包括来自防火墙管理界面的流量，因为在默认情况下，这种流量不会通过防火墙的数据平面。防火墙上的安全策略可以使用各种标准来定义，如区域、应用、IP地址、端口、用户和HIP配置文件。防火墙管理员可以定义安全策略，以允许或拒绝流量，从区域作为广泛的标准开始，然后用更细的选项（如端口、应用程序和HIP配置文件）对策略进行微调。《两种安全策略》防火墙有两种安全策略。 1）明安全策略由用户定义，在CLI和Web-UI界面上可见。 2）隐式安全策略是用户通过CLI界面或Web-UI界面不可见的规则。下一节将讨论Palo Alto Networks防火墙的隐性安全策略。《隐式安全策略》（Implicit security policies）默认情况下，防火墙隐式允许区内（发端和目的地在同一区域）流量，隐式拒绝区间（不同区域之间）流量。默认情况下，隐式策略允许或拒绝的流量不在防火墙上记录，所以找不到这种流量的日志。要被防火墙记录，流量必须与防火墙上明确配置的安全策略相匹配。然而，为了排除故障，可以改变默认行为。请参考：How to See Traffic from Default Security Policies in Traffic Logs: http://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-See-Traffic-from-Default-Security-Policies-in-Traffic/ta-p/57393 《会话》（Sessions） 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 《拓扑结构》在本文中，使用了以下拓扑作为安全策略案例：《服务 "应用-默认"》（application-default) 在下面的例子中，安全策略允许和拒绝符合以下条件的流量。策略A: 所有从IP子网192.168.1.0/24的信任区发起的、以非信任区为目的地的应用，必须允许任何来源和目的地端口。策略B：必须允许从信任区的IP 192.168.1.3发起的以非信任区为目的地的应用程序、DNS、Web浏览、FTP流量。这些应用程序应该被限制在 "应用程序默认 "的端口上使用。例如，DNS应用程序，默认情况下，使用目标端口53。因此， DNS应用程序应该只允许在这个端口使用。在其余的目标端口上使用这个应用程序应该被拒绝。策略C: 所有其他从192.168.1.3到Untrust区域的应用程序必须被阻止。策略D: 所有从Untrust区域发起的到任何区域的流量都应该被阻止。安全策略中的服务栏定义了应允许流量的源端口和目的端口。这四个选项是： 1）应用-默认（Application-default）。允许默认目标端口的流量。关于寻找各种应用，所使用的默认目标端口的更多细节，请参考以下文件。请参阅：How to view Application-default ports for an application. 2）任何（Any）允许任何源和目的端口的流量。 3）预定义服务（Predefined services）已经在防火墙上定义的服务。 4）自定义服务（Custom services）管理员可以根据他们的应用端口要求来定义服务。该例子显示了为符合上述标准而创建的规则。提交上述配置变更时，会显示以下跟随策略警告：接下来将讨论跟随策略警告的影响和避免影子警告的技巧。《规则的跟随》 (Shadowing of rules) 在上面的例子中，IP地址192.168.1.3属于信任区，属于子网192.168.1.0/24。由于防火墙从上到下进行安全策略查询，所有来自IP 192.168.1.3的流量都与规则A相匹配，并将被应用到会话。尽管该流量也符合规则B和规则C的标准，但这些规则不会被应用于该流量，因为规则A正在影射规则B和规则C。为了避免跟随策略影响，规则B和规则C应该在规则A之前，如下图所示。现在，流量与正确的规则相匹配，并防止在提交commit过程中出现 "跟随策略警告"。《基于用户的安全策略》 (security policies based on users) 在上面的例子中，策略是基于IP地址编写的。以同样的方式，LDAP用户、LDAP组和防火墙上的本地定义用户也可以在安全策略中使用。关于如何配置User-ID和将用户添加到安全策略中的更多细节，请参考以下文件：配置User-ID Getting Started: User-ID 《带有NAT的IP地址的安全策略》 (Security policies with NATed IP addresses) 本节讨论了在涉及到IP地址转换时如何编写安全策略，以及如何在安全策略中使用URL类别来控制各种网站。在下面的例子中，安全策略被定义为与以下条件相匹配: 非信任区(Untrust)的公共IP 192.0.2.1被翻译成DMZ区Web服务器的私有IP 10.1.1.2。从非信任区(Untrust)到DMZ区的Web服务器10.1.1.2的入站流量必须只允许使用25、443和8080端口。信任区(Trust)的所有用户必须被拒绝访问非信任区的 "成人和色情 "类网站。所有其他从信任区到非信任区的流量都必须被允许。下面的规则显示了满足上述标准的配置。所有从非信任区发往Web服务器的流量，其目标公共IP为192.0.2.1，属于非信任区。由于该流量来自非信任区，目的地是非信任区的IP，因此该流量被一个允许相同区域流量的隐含规则所允许。在安全策略查询之后，防火墙做了一个NAT策略查询，确定Web服务器的公共IP应该被翻译成位于DMZ区的私有IP 10.1.1.2。在这个阶段，防火墙有了最终目标区域（DMZ），但是IP从192.0.2.1到10.1.1.2的实际转换还没有发生。在确定NAT后流量的最终目的区信息后，防火墙进行第二次安全策略查询，以找到一个政策，允许以最终目的区DMZ为目的地的流量。因此，上面的规则X被配置为允许后NAT流量。注意，规则X将DMZ（Post-NAT区域）作为目标区域，将192.0.2.1（Pre-NAT IP）作为目标IP地址。在上面的例子中，一个服务 "Web-server_Ports "被配置为允许目标端口25、443和8080。欲了解更多信息，请参阅。如何配置一个策略以使用一个端口范围。《安全策略中的URL类别》 (URL categories in security policies) 在上面的例子中，规则Y被配置为使用安全策略中的URL类别选项阻止成人类别网站。在安全策略中使用URL类别选项时，必须在策略中明确提到网络浏览应用程序。否则，不相关的流量将与此规则相匹配。另一种基于URL类别控制网站的方法是使用URL过滤配置文件。《应用程序的依赖性和应用程序的转移》 (Application dependencies and application shifts) 本节讨论了 "应用依赖性"，并描述了当应用-ID在会话中间改变时，会话会发生什么。在下面的例子中，安全策略被定义为允许和拒绝符合以下条件的流量。应该允许Gotomeeting、Youtube从信任区到非信任区的应用。应该允许应用Facebook、Gmail-base从访客区到非信任区。对于访客区的用户，SSL和网络浏览应该被阻止。以下案例能看出符合上述标准而创建的规则。在提交配置更改时，可能会看到以下应用程序依赖性警告。像Gotomeeting和YouTube这样的应用最初被识别为SSL、网络浏览和Citrix。随着这些会话的更多数据包通过防火墙，防火墙可以获得更多信息来识别应用程序。然后，防火墙将应用程序转移到Gotomeeting和Youtube等各自的应用程序。每当应用程序转移发生时，防火墙就会进行新的安全策略查询，以找到与新应用程序相匹配的最接近的规则。因此，在上述案例中，SSL和网络浏览被称为Gotomeeting和Youtube的附属应用，因此这些应用也应该在安全策略中被允许。如果流量的应用在会话过程中发生变化，那么第二次安全策略查询就会根据安全策略重新匹配流量，以找到新的最接近的匹配策略。在上面的例子中，创建了一个新的安全策略，"依赖性应用程序规则"，以允许SSL和网络浏览。Youtube的流量最初与此规则相匹配，一旦发生应用转移，第二次安全策略查询就与规则10相匹配。一些协议的应用程序可以被允许，而不需要明确地允许其依赖性（文档：http://live.paloaltonetworks.com/t5/Management-Articles/How-to-Check-if-an-Application-Needs-Explicitly-Allowed/ta-p/61893）。在上面的例子中，Facebook和gmail-base就是这样的应用，它们依赖于SSL和网络浏览，不需要明确允许它们的依赖性应用。《应用程序识别和解密》（Application identification and decryption）某些像Vimeo这样的应用，使用SSL并且是加密的，不需要SSL解密就可以被防火墙识别。然而，像YouTube这样使用SSL的应用程序，需要由防火墙解密来识别。由于SSL连接是加密的，因此防火墙无法看到这种流量，以便对其进行识别。防火墙使用证书中的通用名称字段进行应用识别。这是在SSL握手过程中以明文交换的。像Vimeo这样的网站使用网站的URL名称作为通用名称，因此不需要配置SSL解密。一些网站如YouTube使用带有通配符名称的证书作为公共名称。在YouTube的情况下，它是*.google.com。因此，使用这一信息进行应用识别是不可能的，必须配置SSL解密以获得对网站URL的可见性。请参考以下关于如何实施和测试SSL解密的文件 http://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Implement-and-Test-SSL-Decryption/ta-p/59719 。《清理规则》（Clean-up rule）些环境要求记录所有被防火墙拒绝和允许的流量。默认情况下，只有防火墙明确允许的流量才会被记录下来。要记录防火墙隐含规则所允许的流量，请参考： - 任何/任何/拒绝安全规则改变默认行为 http://live.paloaltonetworks.com/t5/Learning-Articles/Any-Any-Deny-Security-Rule-Changes-Default-Behavior/ta-p/54248） - 如何在流量日志中看到来自默认安全策略的流量 http://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-See-Traffic-from-Default-Security-Policies-in-Traffic/ta-p/57393 《安全策略提示》（Security policy tips）防火墙以相同的顺序检查以下标准，以便根据安全策略匹配流量。 1）源地址和目标地址（Source and destination address） 2）源端口和目标端口（Source ports and destination ports） 3）应用程序（Applications) 4）用户-ID (User-ID) 5）URL类别 (URL Category) 6）源区和目的区 (Source and destination zones) 在上述配置实例中，当TCP端口80上的应用程序 "网络浏览 "从信任区到非信任区通过防火墙时，将以下列方式进行安全查询。 1) 源地址和目标地址（Source and destination address） - 因为规则A、B和C有 "任何 "源和目的地址，所以该流量与所有这些规则相匹配。 2) 源端口和目标端口（Source ports and destination ports） - 因为规则A、B和C有 "任何 "服务，所以流量符合所有这些规则。 3) 应用程序（Applications) - 由于规则A和B有 "网络浏览 "应用程序，流量符合这些规则。 4) 用户-ID (User-ID) - 这里不适用。 5) URL类别 (URL Category) - 此处不适用。 6) 源区和目的区 (Source and destination zones) - 因为流量是在信任区和非信任区之间，所以为这个流量选择了规则A。配置安全策略的最佳方式是尽量减少 "任何 "的使用，并在可能的情况下使用具体的值。这可以减少Palo Alto Networks设备进行的不必要的安全策略查询。

概述本文介绍了如何在CLI（命令行界面）中查看、创建和删除安全策略。详细介绍从CLI创建一个新的安全策略： > configure （按回车键） # set rulebase security rules <name> from <source zone> to <destination zone> destination <ip> application <application> service <any/application-default/service name> action <allow/deny> （按回车键） # exit 例子： # set rulebase security rules Generic-Security from Outside-L3 to Inside-L3 destination 63.63.63.63 application web-browsing service application-default action allow （按回车键）注意：对于所有CLI命令的输入帮助，使用"?"或[tab]来获得可用命令的列表。从CLI查看Palo Alto Networks安全策略： > show running security-policy Rule From Source To Dest. User Proto Port Range Application Action ---------- ------------ ------------- ------------ --------------- ------------------- ----- ---------- ------------ ------ Doms DLP untrust-vwir 10.16.0.92 Untrust-vwir any any any any any allow trust-vwire trust-vwire rule4 untrust-vwir any untrust-vwir 10.16.0.92 any any any any allow trust-vwire trust-vwire rule3 trust-vwire any untrust-vwir any any any any any allow 下面的命令将输出整个配置： > show config running 设定格式输出为set： > set cli config-output-format set > configure Entering configuration mode [edit] # edit rulebase security [edit rulebase security] # show set rulebase security rules rashi from trust-vwire set rulebase security rules rashi from untrust-vwire set rulebase security rules rashi to trust-vwire set rulebase security rules rashi to untrust-vwire set rulebase security rules rashi source 10.16.0.21 set rulebase security rules rashi destination any set rulebase security rules rashi service any set rulebase security rules rashi application adobe-meeting-remote-control set rulebase security rules rashi application adobe-meeting set rulebase security rules rashi application adobe-online-office set rulebase security rules rashi action deny set rulebase security rules rashi source-user any set rulebase security rules rashi option disable-server-response-inspection no set rulebase security rules rashi negate-source no set rulebase security rules rashi negate-destination no set rulebase security rules rashi disabled yes set rulebase security rules rashi log-start no set rulebase security rules rashi log-end yes 切换为默认输出格式：从配置模式： # run set cli config-output-format default [edit rulebase security] # show security { rules { rashi { from [ trust-vwire untrust-vwire]; to [ trust-vwire untrust-vwire]; source 10.16.0.21; destination any; service any; application [ adobe-meeting-remote-control adobe-meeting adobe-online-office]; action deny; source-user any; option { disable-server-response-inspection no; } negate-source no; negate-destination no; disabled yes; log-start no; log-end yes; profile-setting { profiles { file-blocking rashi_file_alert; data-filtering rashi_dlp; } 使用XML格式查看配置：从配置模式： # run set cli config-output-format xml [edit rulebase security] # show <response status="success" code="19"> <result total-count="1" count="1"> <security> <rules> <entry name="rashi"> <from> <member>trust-vwire</member> <member>untrust-vwire</member> </from> <to> <member>trust-vwire</member> <member>untrust-vwire</member> </to> <source> <member>10.16.0.21</member> </source> <destination> <member>any</member> </destination> <service> <member>any</member> </service> <application> <member>adobe-meeting-remote-control</member> <member>adobe-meeting</member> <member>adobe-online-office</member> </application> <action>deny</action> <source-user> <member>any</member> </source-user> <option> <disable-server-response-inspection>no</disable-server-response-inspection> </option> <negate-source>no</negate-source> <negate-destination>no</negate-destination> <disabled>yes</disabled> <log-start>no</log-start> <log-end>yes</log-end> <profile-setting> <profiles> <file-blocking> <member>rashi_file_alert</member> </file-blocking> <data-filtering> 另外，如果你想用更短的方式在配置模式下查看和删除安全规则，你可以使用这两条命令：查找一条规则： show rulebase security rules <rulename> 删除一条规则： delete rulebase security rules <rulename>

在防火墙上，防病毒配置文件阻止恶意文件。如果你怀疑被阻止的文件是良性的，你可以向PaloAlto支持部门申请改变该文件的判决。将文件判决改为良性将使签名失效。环境所有PAN-OS版本。原因一个良性的文件模式与一个恶意软件文件的模式相匹配。解决方法我们需要一些必要的项目来快速解决。请通过开案主动收集以下数据，以便我们能快速工作。所需的信息 1. 防病毒和野火签名包的当前版本。 1）CLI的 "显示系统信息 "的输出。 2）或从 PA 防火墙的 "仪表板小工具-->一般信息 "显示当前版本信息。 2. 文件信息。 1）我们需要关于文件的信息；以下任何信息都足够好。触发每个AV签名的实际样本文件，用密码 "已感染 "进行压缩（zip）。你可以使用任何简单的zip或压缩工具。保护ZIP文件的密码将确保附件在上传支持系统时不会被任何主机或基于网络的安全设备所剥离。同时添加sha256哈希值以确保文件的完整性。 2）如果它是一个众所周知的应用程序，请提供一个可公开访问的URL。请注意，"公共应用程序 "是指无需创建账户即可下载的文件。 3）如果该文件有敏感信息，并且你不想分享它，请提供该文件的sha256哈希值。如果不提供实际样本，我们可能无法确认假阳性。 3.威胁日志。请以CSV格式导出这些事件的威胁日志，并上传至案件。必须过滤掉并只收集相关的日志；不必要的日志会使文件变大，难以上传。 4.围绕你为什么怀疑这些AV警报的背景是不真实的。 -这是你的应用程序，由你的内部团队开发？ -这个文件或应用程序是来自一个受信任的第三方吗？ -这个文件是由受信任的一方签署的吗？ -使用时的协议是什么？虽然这些信息可以通过威胁日志来识别，但是，如果能加上这些信息就更好了。 -这个文件是否经过内部分析？你是否检查过任何其他声誉来源，如VirusTotal的判决？ -重要提示：如果文件的哈希值不在VirusTotal中，我们不建议将样本上传到VT。在VT中，任何人都可以看到并下载它，这意味着你与公众分享你的信息。 5.请提供触发的威胁警报的名称和线程ID。从威胁日志中获取触发的威胁警报的屏幕截图/文本输出。监控 > 威胁 -> 点击放大镜图标将为您提供更多细节，如下图所示。即，威胁ID为377248044，威胁名称：Virus/Win32.WGeneric.aplnvy

症状漏洞假阳性，即良性网络流量被识别为漏洞并触发漏洞签名。环境问题所有PAN-OS版本。原因流量可能被误认为是漏洞之一。解决方法漏洞签名是以网络流量为基础的，因此，重点在于签名启动时在网络上看到的数据，并怀疑它是一个假阳性。提供以下内容是最重要的: 1.一个完整的解密数据包，包括完整的TCP/UDP交易和包括一个触发签名的合适的关闭。 2.你的防火墙上的当前应用和威胁数据包。 3.签名的名称和威胁的ID 4.威胁日志。为什么是解密的数据包捕获？ 1.我们需要解密的 pcap。解密的 pcap 可以用来在实验室环境中重放，以重现问题，同时解密的数据包也可以显示流量模式。 2.这可以通过各种方式进行，如通过防火墙与解密端口镜像或在Windows和MacOS上的终端本身。 3.请注意，对于间谍软件签名类型，有时扩展的数据包捕获就足够了，但对于漏洞签名，最好是完整的数据包捕获。为什么要进行完整的数据包捕获？ 1.漏洞签名假阳性调查需要客户提供的数据包捕获。PaloAlto的技术支持通过在实验室重放数据包捕获来重现这个问题。 2.完整的数据包捕获也提供了额外的 "背景"，当确定警报是否是假阳性。 3.针对特定威胁特征ID的扩展数据包捕获不是解决假阳性的理想方案，因为数据包捕获将在违规会话的中途开始捕获。这将导致缺乏会话创建（SYN / SYN-ACK / ACK）的数据包捕获，在没有被篡改的情况下无法正确重放。操作步骤 1.当前的应用程序和威胁版本。从防火墙的CLI中收集 "显示系统信息 "的输出，或从WebGUI的Dashboard中复制 "一般信息 "窗格。这将显示当前的应用程序和威胁版本。 2.威胁日志。确定问题的再现方法。这可能涉及到与产生触发签名的流量的主机或服务器的互动，或者用不太直接的方法确定签名定期触发的共同来源/目的地/时间。这可以通过评估威胁日志中的可用数据来实现。转到WebGUI > 监控 > 威胁。 3.一旦确定了违规流量的可靠来源和/或目的地，就可以创建数据包捕获。这可以通过网络管理员认为合适的任何方式进行。在客户端/服务器上基于主机的数据包捕获是可以的，只要它们包括完整的会话创建和产生签名的流量（Wireshark和TCPDUMP是两个例子）。从PAN-OS设备上抓取数据包也是一种可能! 完整的数据包捕获可以通过过滤特定的流量来产生。 4.威胁ID：请提供被触发的威胁ID号，以及被触发的威胁名称。或者，触发的威胁日志截图也够了。 5.提供背景资料，说明为什么认为该签名触发是假阳性。一些例子可能包括: 1)漏洞签名中对目标操作系统/产品的描述与环境中使用的产品或应用程序不一致。例如，看到一个漏洞签名触发器指定了一个供应商名称、操作系统或应用程序，而众所周知，这个供应商名称、操作系统或应用程序并没有在网络上使用（并且已经被确认为没有在使用）。 2)该流量在被报告之前经过了内部分析，是安全的。 6. 一旦所有这些数据都被收集起来并放入支持案例中，就可以对数据包捕获进行分析，并得出判决和可能的修复. 其他信息: 在SSL/TLS加密流量的情况下，需要对数据包的捕获进行解密。这可以通过各种方式完成，如通过防火墙与解密端口镜像或在Windows和MacOS上的终端本身。

环境 PAN-OS 8.1及以上版本 Palo Alto Firewall或Panorama 解决方法 1，管理服务器进程可以用下面的cli命令重新启动。 FW-> debug software restart process management-server 2，几分钟后，请重新登录CLI。 3，通过运行CLI命令show system resources | match mgmtsrvr，检查管理服务器进程。 FW-> show system resources | match mgmt 2140 20 0 708m 484m 9828 S 2 12.9 8:13.06 mgmtsrvr 这个过程应该显示如上，并且CLI和WebUI的功能都正常。注意: cli命令 "debug software restart process management-server "将重启"mgmtsrvr "进程。如果发生这种情况时有登录的管理员，他们将从WebGUI以及CLI中被踢出。通常情况下，重启管理服务器进程并不影响数据包的转发，只是管理员会被踢出。我们一直鼓励在非高峰期或维护窗口期间执行任何进程重启。其他信息一般来说，管理重启是在以下一种或多种情况下进行的。如果遇到以下情况并且在与TAC合作之前急需解决，那么重启管理服务器 "可能 "有帮助。 WebGUI迟缓或无反应显示陈旧的admin会话已输入授权码，但没有激活或更新许可证日志没有显示在WebGUI中 CLI命令show system resources 显示mgmtsrvr进程消耗了过多的内存

症状一些常见的root分区满了的症状有：无法登录或访问Web UI 某些daemons进程不能启动不完整的tech support bundle 系统日志提示："/的磁盘使用量超过限制，使用了X%，正在清理文件系统" Root 分区很高 > show system disk-space Filesystem Size Used Avail Use% Mounted on /dev/md2 3.8G 3.1G 581M 85% / <----- root 分区 /dev/md5 7.6G 4.2G 3.0G 59% /opt/pancfg . /dev/md6 3.8G 3.0G 666M 82% /opt/panrepo tmpfs 2.0G 210M 1.8G 11% /dev/shm cgroup_root 2.0G 0 2.0G 0% /cgroup /dev/md8 88G 2.4G 81G 3% /opt/panlogs tmpfs 12M 0 12M 0% /opt/pancfg/mgmt/lcaas/ssl/private 环境 PAN-OS Palo Alto Firewall Panorama 原因导致分区被占满的一些常见原因: 管理员对某些进程进行故障排除，并创建了Core文件。这些文件存储在根目录下，直到被管理员删除。启用数据平面的诊断日志（packet diags）也会占用根分区的空间。解决办法启用积极的清理(PAN-OS 7.1.14+, 8.0.7+, 8.1.0+) 如果95%的占用率警报被触发，这将自动截断所有旧的日志文件（所有*var/log/pan目录下的条目，匹配*.1, ... *.4, *.log.old)。 > debug software disk-usage aggressive-cleaning <enable|disable> 注意: 启用积极的清理可能会清除日志，使日志无法用于故障排除。要验证这些变化，或者如果它已经被启用，请使用下面的命令。 > show system state | match aggressive-cleaning cfg.debug-sw-du.config: { 'aggressive-cleaning': True, } 运行磁盘使用量清理命令 (PAN-OS 8.1.0+) 磁盘使用率的清理可以通过下面的命令手动完成: > debug software disk-usage cleanup ? + 深度清理删除备份日志文件 *阈值系统分区大小的阈值百分比，启动清理工作 > debug software disk-usage cleanup deep threshold 90 请注意，这个命令必须每次手动运行，以使磁盘使用率低于90%，并且在重启后不会持续。注意：启用积极的清理可能会清除日志，使日志无法用于分析检查并删除不必要的Core文件通过检查 > show system files 的输出，以查看占用大量磁盘空间的Core文件。. > show system files /opt/dpfs/var/cores/: total 4.0K drwxrwxrwx 2 root root 4.0K Jun 10 20:05 crashinfo /opt/dpfs/var/cores/crashinfo: total 0 /var/cores/: total 115M drwxrwxrwx 2 root root 4.0K Jun 10 20:15 crashinfo -rw-rw-rw- 1 root root 867M Jun 12 13:38 devsrvr_4.0.3-c37_1.gz -rw-rw-rw- 1 root root 51M Jun 12 13:39 core.20053 /var/cores/crashinfo: total 16K -rw-rw-rw- 1 root root 15K Jun 10 20:15 devsrvr_4.0.3-c37_0.info 删除不必要的Core文件。如果围Core文件的调查已经完成，或者它们是非常老的文件，可以认为是不必要的Core文件。 > delete core management-plane file devsrvr_4.0.3-c37_1.gz 这些文件可以用scp或tftp导出命令导出，然后删除以释放防火墙上的空间 > scp export core-file management-plane from mgmtsrvr_7.0.3_0.tgz to user@10.0.0.10:/home/ user@10.0.0.10 's password: ******** mgmtsrvr_7.0.3_0.tgz 100% 453MB 46.4MB/s 00:12 删除旋转的文件和扩展名为.old的文件这些文件包含监控细节和防火墙上的服务相关日志。如果你不需要它们，可以安全地删除它们。如果TAC调查一个正在发生的问题，你可能更愿意保留它们，直到将tech support file上传到案例管理器。 . > delete debug-log ? cp-log Remove cp-log at /opt/var.cp/log/pan/ dp0-log Remove dp0-log at /opt/var.dp0/log/pan/ dp1-log Remove dp1-log at /opt/var.dp1/log/pan/ dp2-log Remove dp2-log at /opt/var.dp2/log/pan/ mp-global Remove mp-global at /opt/mp-global/ mp-log Remove mp-log at /var/log/pan/ <--- 面是 mp-log 的例子 > delete debug-log mp-log file *.1 > delete debug-log mp-log file *.2 > delete debug-log mp-log file *.3 > delete debug-log mp-log file *.4 > delete debug-log mp-log file *.old 清除任何已启用的数据包-diag记录运行 > debug dataplane packet-diag show setting 检查是否启用了 packet-diag > debug dataplane packet-diag show setting DP dp0: -------------------------------------------------------------------------------- Packet diagnosis setting: -------------------------------------------------------------------------------- Packet filter Enabled: no Match pre-parsed packet: no -------------------------------------------------------------------------------- Logging Enabled: no <-- No是默认值，意味着不启用 > debug dataplane packet-diag show setting DP dp0: -------------------------------------------------------------------------------- Packet diagnosis setting: -------------------------------------------------------------------------------- Packet filter Enabled: no Match pre-parsed packet: no -------------------------------------------------------------------------------- Logging Enabled: yes <--- 意味着启用了数据包分析要清除packet-diag设置和日志，请运行以下命令: > debug dataplane packet-diag clear all 包诊断设置为默认 > debug dataplane packet-diag clear log log Dataplane调试日志已清除删除任何Debug pcaps或Debug-filter pcapsc > delete debug-filter file <file-name> > delete pcap directory * 如果上述修复步骤都不能解决问题，建议收集以下的故障诊断数据，并创建技术支持的case。收集 Tech Support File (GUI: Device > Support Click Generate Tech Support File) 收集CLI show system disk-space的输出。

目标如何确认Prisma云计算中特定CVE的覆盖范围？环境 Prisma Cloud Compute 步骤你可以通过使用 Console 中的搜索界面来确定 Prisma Cloud 是否为特定的 CVE 提供覆盖。 CVE ID的语法是。CVE-YYYY-NNNN 在哪里？ CVE -- CVE-ID前缀。 YYYY -- 日历年份。 NNNN-- 数字位数。这个字段的长度是可变的，但最小长度是四位数要搜索一个特定的漏洞。打开控制台，进入 "监控">"漏洞">"CVE Viewer"。(Monitor > Vulnerabilities > CVE Viewer) 在右上方的查询文本框中，输入CVE ID（例如CVE-2021-44228）。如果Prisma Cloud覆盖了所查询的漏洞，细节将在结果列表中列出。 I.Prisma云计算版（Self-Hosted）控制台。如：要查看Coverage，请进入 "监控">"漏洞">"CVE Viewer">输入 "CVE-2021-44228"。（Monitor > Vulnerabilities > CVE Viewer > Input "CVE-2021-44228"） II.Prisma云企业版（SaaS）控制台。如：要查看Coverage，请进入计算 > 监控 > 漏洞 > CVE Viewer > 输入 "CVE-2021-44228"（Compute > Monitor > Vulnerabilities > CVE Viewer > Input "CVE-2021-44228"）注意：一旦供应商评估他们自己的暴露程度（exposure），执行他们的分析并发布建议，他们就会在他们自己的安全反馈中发布这些攻击响应，然后流入我们的情报流（Intelligence Stream），再由Prisma Cloud Console处理。建议删除为该漏洞添加的任何自定义反馈规则（Custom Feed Rules），以便为您的环境获得最佳结果。额外信息：如果你在Prisma云计算中没有看到特定CVE的覆盖范围，请在TAC开一个支持案例。更多信息请参考https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/vulnerability_management/search_cves.html 关于漏洞浏览器的更多信息，请参考https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000004MfoCAE

目标如何避免Prisma Cloud中Investigate标签的RQL查询超时？环境 Prisma cloud 步骤当在 "调查 "标签（Investigate tab）中运行RQL查询时，可能会遇到以下信息 "没有结果"（"No Results Available" ）。这在以下情况下发生： 1.Onboard的云账户中没有可用的资源来匹配查询。 2. RQL查询超时。为了确认上述情况，请考虑以下例子。在RQL查询1中，我们只看到 "没有可用的结果 "（"No Results Available"）信息，这表明没有可用的云资源来匹配这个查询。然而，在RQL查询2中，随着 "无结果 "（"No Results Available"）信息的出现，我们还看到查询下方与 "搜索 "有关的3个标签，这表明RQL查询超时。 RQL查询1：识别在"particular onboarded cloud account"中所有正在运行的实例，这些实例使用不属于被管理账户的AMI。 RQL查询2 :识别 "all onboarded cloud accounts "中所有正在运行的实例，这些实例正在使用不属于管理账户的AMI。原因当在Investigate标签中运行RQL查询时，后端将查询数据库中与我们输入的过滤器相匹配的结果。在RQL查询2中，后端在数据库中查询符合查询的所有onboard云账户的资源。在3分钟内有太多的资源需要整理的情况下，RQL查询可能会超时，如上面的例子中看到。解决办法为了避免RQL查询超时，以扫描一个较小的分段去过滤它，即一个特定的账户或账户组。在下面的例子中， cloud.account = 'RDS AWS Test' 被添加到RQL查询中，以过滤到一个特定的帐户。