About Brandon_Wertz

@CosminM -- Yeah I noticed that.  Thanks for the heads up.  I hear there might be some good news on that front. ... View more

One thing that we already provided feedback to the account team the documentation isn't exactly obvious.  When we tried getting the 5540s up, we couldn't get management online.  Apparently there are "logging" interfaces and "management" interfaces.  We had initially used the SFP ports on the left of slot 7, but that didn't get management to come up.  When we moved the SFP to the right bank of ports the management interfaces came up on the 2 boxes.     So there's a little "ism" that isn't directly obvious for anyone trying to get these new hardware types online.   ... View more

@RajuGK  -- Are you subscribed to SCM email notifications?  These email notifications went out this morning US/Central time.  Maybe your issues were related to this issue?   ... View more

@SanilHande  -- What was the solve?  We've been running Azure CNGFW for about a year now and have 3 regions deployed.  The main issue ended up being we needed to RTFM.  haha  Palo has some pretty solid documentation on deploying CNGFW and we skipped the step about creating the required security policy for the firewall to use the loopback to talk to the correct internal resources for UIA to work. ... View more

@JamesHodge  @kiwi is correct about the DNS sinkhole tracking, but there's a catch to this working.  You will need to have a firewall inline between the client and DNS lookup request for the bad domain.   Just to be clear, the process goes like this:   A:  Client (requests lookup for malicious domain) --> B:  Request sent to internal DNS --> C:  Request sent to internal root forwards (for external domain lookup, usually in your DMZ) --> D : Internet DNS responds to root forwarders   In order for you to be able to identify the actual source of the lookup you need to have the Palo firewall in-between steps A & B.  If your firewall is anywhere after that the Palo will just say the server in step B or C is the "source" of the malware, because from the firewall's perspective that's the server that's actually asking for the domain info.  And if this is the case you'd need to turn on logging on your DNS servers to see the IP client (source) that's requesting that bad domain. ... View more

@HeinzP wrote: The User-ID XML API is a great idea. I have run a few tests with it. Unfortunately, I am struggling with the user-to-group mapping. In my opinion, this is only possible with an LDAP server profile. Does the limit of 2,500 entries per group still exist when using Tag-Based Dynamic Group? eg. <dynamic> <filter>'user contains "label1\\"'</filter> </dynamic> I will run some additional tests. IMO, if you're going to use this XML/EDL process you're going to set yourself up for support issues long term. The only real "enterprise" solution would be the DeviceID route, especially if you have a security policy driving your security architecture.  ... View more

@HeinzP  -- I've done exactly this.  One way was ~12+ years ago via an "unsupported" option and now recently via a Palo supported option (which I've been doing successfully for the past ~2ish years.)   The first way was using an EDL, like you mentioned though, the box has a limit of 30 total EDLs.  So if you have more than 30 device types then an EDL won't ultimately work.   Palo Alto acquired a company about 6 years ago called "Zing Box."  This products' whole purpose was device control.  Prior to the Zing Box acquisition palo couldn't natively use the "what" in security policy, but with this acquisition they could.  This product turned into IoT Security or Device Security, which is a licensed feature of their firewall product.  If you purchase this product you can add "device type" as a field in your security policy and you'll be able to achieve exactly what you're trying to do.       ... View more

@HeinzP wrote: The necessary firewall rules for each application are defined by labels. If a workstation needs access to it, the label is requested and assigned (XML-API), so each Workstation has its own set of firewall rules. I tried implementing this requirement using different approaches, but unfortunately, everything failed due to several limitations. First, custom external dynamic lists (EDLs) are limited to a maximum of 30 lists. Assigning tags to address objects for dynamic address groups is limited to 64. The maximum number of members per Address Group is 2,500. These limitations are documented, and some of them have already been discussed on this portal: https://www.paloaltonetworks.com/products/product-selection Show system state | Match cfg.general.max-address. Why do data center firewalls (not the small boxes) have limitations like this? Have others also reached these limitations? Does anyone have another approach to implementing the requirements? @HeinzP  -- What are you trying to do?  What are you trying to control?     Are you trying to control a specific device from accessing a specific resource (server?)  Or are you trying to control a specific person/account from accessing a specific resource (server?) ... View more

@RezhoPsq wrote: Hello, We are experiencing a high number of aged-out connections from our Cortex agents and brokers on 35.244.133.254. When the connection is successful, the app-id traps-management-service is detected by our firewall. Do you also encounter this behavior? Thanks !   @RezhoPsq My guess that address 35.244.133.254 is a part of Cortex's infra.  That IP space is registered to GPC and Palo uses GPC for a lot of their services.  Also, if you look through your system logs you'll see other services like URL and others connecting to "35" addresses registered to GPC. ... View more

@JayGolf  / @L.Yalezo  -- I've updated my post with the FR. ... View more

@JayGolf wrote: Hi @L.Yalezo ,   Currently, there is no code-level resolution for automatically updating this list outside of major PAN-OS releases nor is there a "feature request" for this.  You can manually import it as a trusted root CA to ensure that your firewall trusts the new Sectigo root certs.  There is a FR for this, (which is NSFR-I-21203)...At least I'm told there was and that my company was added to the FR.  I'll look for it and share it here. That said this is something that Palo know about for years and something I've been complaining about to palo for the past 5+ years.  It's so bad that a whole repo process was setup to solve this issue Palo has ignored.   https://github.com/PaloAltoNetworks/pan-chainguard     There is partial good news.  In 12.1.2 Palo is trying to solve the missing intermediate cert issue as PAN-OS will attempt to dynamically download missing intermediate certificates (No current solve for roots, other than the code upgrade.) Automatic Retrieval of Intermediate Certificates Using AIA "We introduced a mechanism to fetch intermediate certificates via the AIA extension. This mechanism can be toggled on/off by a new Decryption Profile setting: “Automatically Fetch Intermediate Certificates” As part of decryption, when we encounter a server certificate with an incomplete chain, and the AIA CA Issuers extension is present (RFC5280), we will attempt to download an Intermediate CA certificate from the specified URL. If successful, we cache the intermediate certificate for up to 1 week and use it to validate future traffic."  *Caveats: The first session will show untrusted until the intermediate certificate(s) have been fetched*   Note: This feature must be enabled on a Decryption Profile (“Automatically Fetch Intermediate Certificates”) The intermediate certificate cache itself is only present on firewalls (not Panorama or SCM) Panorama and SCM can only enable/disable the feature   https://docs.paloaltonetworks.com/ngfw/release-notes/12-1/features-introduced-in-pan-os/decryption-features ... View more

@emr_1 wrote: I agree with you, and TAC is wrong. If I configured a rule as below:   The rule on the box is recognized as below: )> show running security-policy "test; index: 1" { from any; source any; source-region none; to any; destination any; destination-region none; user any; source-device any; destination-device any; source-advanced-device any; destination-advanced-device any; category any; application/service [0:windows-remote-ma/tcp/any/5985 1:windows-remote-ma/tcp/any/5986 ]; application/service(implicit) [0:web-browsing/tcp/any/5985 1:web-browsing/tcp/any/5986 ]; action allow; icmp-unreachable: no terminal yes; }   As you know, "web-browsing/tcp/any/5985" is "application/protocol/source-port/dest-port".   By the way, I found issue from release note. === PAN-194408 Fixed an issue where, when policy rules had the apps that implicitly depended on web browsing configured with the service application default , traffic did not match the rule correctly. ===   Even I don't know which version you are using, you should check you are hitting this or not. I can find this bug-id on 10.1.6-h3, 10.1.7,10.2.3 release note @emr_1 -- thank you for this confirmation.  I'll be following up with our TAC team today and share the results.  Also appreciate the bug info.  FYI we're running 11.1.6h19. ... View more

@M.vyas  -- Follow these steps to convert from market place to private offer:   https://docs.paloaltonetworks.com/cloud-ngfw-azure/reference/cloud-ngfw-for-azure-credit-distribution-and-management  ... View more