This article is based on a discussion, URL set to allow Ransomware,  posted by @Schneur_Feldman and answered by @Astardzhiev, @BPry and @Adrian_Jensen. Read on to see the discussion and solution!   Can anyone please explain why Palo Alto Networks would release a Ransomware URL Category and put the default to allow?    It's going to be a pain logging into every single client of ours that uses Palo and changing Ransomware URL Category to block. Is there a way to automate it? What would the CLI command be? Palo Alto Networks doesn't have visibility into how, why and where you are using your URL filtering profiles. They give you the tools, it is your decision how to use them.   The CLI command would be: - Locally managed firewall   set profiles url-filtering <profile-name> block ransomware   - Panorama managed firewall   set device-group <device-group-name> profiles url-filtering <profile-name> block ransomware   There are couple of ways to automate such change and depending on your environment: - Export firewall running config; search and edit the XML defining any URL filtering profile; import, load and commit the edited config - Similar as above but for Panorama config, modifying any URL filtering in all available device-groups From your comment it seems you support multiple different clients, which probably require different ways to connect and different credentials. So you are probably better using the XML API. You may want to check python framework, which could save you some time (connecting and authenticating to the device).   To further expand on this, Palo Alto Networks can't identify what you're using a profile for. If I have devices segmented off into a malware research zone and utilize a subset of my machines for those purposes, I absolutely wouldn't want Palo Alto Networks to modify my profiles to block a newly introduced category for a subset of machines where I would actually want to allow the traffic.    If you're managing multiple clients I'd really recommend looking at the benefits of utilizing Panorama to manage all of them, or better yet managing them directly through the XML configuration file and templating some of the configuration yourself if you can't get approved to purchase Panorama. The API here can also be a major help, but if you're not comfortable with it it's not going to be a quick fix since you'll need to be parsing results and using that information in additional changes.    NOTE: The new "ransomware" category is blocked in the "default" URL Filtering category. But as you pointed out correctly it is not blocked by default in custom URL Filtering categories because Palo Alto Networks doesn't know what you are using custom categories for.   Default URL Filtering Profile   Custom URL Filtering Profile    

   

This article is based on a discussion, Best practice to allow Internet IPs,  posted by @Metgatz and answered by @OtakarKlier . Read on to see the discussion and solution!     Best practices - Multi large upgrades pan-os Firewall HA   Good afternoon, as usual, thank you very much for your support and collaboration. We have the possibility with a customer to perform multiple upgrades in one day, maintenance window. We need to move from 8.1 to 9.1, i.e. 8.1.x to 9.0.x and from 9.0.x to 9.1.x.   So the question is the following: 1.- What is the best practice when it comes to make that jump, that intermediate upgrade from 9.0, for example when going from 8.1.x to ""9.0.x"" ( PAN-OS Intermediate, transitive ) final 9.1.x. That intermediate jump, what is the best practice: I mean, for example, the current version 8.1.5, download and install the base 9.0.0? or is it recommended to download the base (9.0.0) and download and install (the recommended version of 9.0.x (9.0.16-h2), although it is say the intermediate transition version? to reach the recommended version 9.1.   2.- Also in relation to the same, the recommendation is still, in each jump, for example when moving to the same intermediate version 9.0, love or reassemble the HA and then continue with the upgrade ? or is it possible to apply both upgrades to a node and then on the other node ? I would understand that the best practice is to re-amplify the HA at each stage of the upgrade.   Please give me your comments, advice, recommendations and suggestions.   Thank you very much   Best regards Solution:   Hello, First backup the config. This doc should step you through the process. I forget when they allowed the base release download only and install the preferred release, i.e. just download 9.0 and download and install the latest version of the 9.0.x release. But you can do it with the 9.1, eg download 9.1.0 code but download and install the preferred release 9.1.x.   https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-upgrade/upgrade-pan-os/upgrade-the-firewall-pan-os/upgrade-an-ha-firewall-pair#id062f1ad5-adb3-4d25-b4a4-529bde5dc96a https://live.paloaltonetworks.com/t5/customer-resources/support-pan-os-software-release-guidance/ta-p/258304   With an HA pair, do it all on the standby unit first. I when doing large jumps as these, it might be wise to go slow. What I mean is do the first jump on the standby, fail over, then upgrade the other one to the same version. Then keep going until you are up to the version you want to be at. Also make sure you dynamic updates are up to date as well, otherwise the PAN wont let you upgrade the OS.   Cheers!  

   

   

This article is based on a discussion,  Best practice to allow Internet IPs,  posted by @thanawat_l and answered by @PavelK . Read on to see the discussion and solution!    I want to optimize my security policy. I have many rules that allow any, but I want to change from any to internet IP. Does PaloAlto have an Internet IP object by default? or how can I define internet IP space in address?   Solution: You can do it reverse by using "negate" in policy to allow anything except reserved RFC1918 addresses that are not routable on the internet.    For these ranges there are Palo Alto built-in objects including class D IP ranges that you can exclude from policy and allow anything also on internet.