Just wanted to share this with the community in hopes that it may prevent one from experiencing the hardship that we did. We use MineMeld with our URL filtering rules. We appended "?v=panosurl" to the end of the end of the URL for our General_Block_List with the assumption that it would just reformat the output essentially removing the "http://" from the URLs in the list. Unfortunately adding ?v=panosurl to the end of the URL caused the list to add three entries for *.com and one for *.it.
Since this EDL was a block list it essentially began blocking everything to those TLDs. This brought the entire network to it's knees and we couldn't get into our Panorama server to revert the change. We were eventually able to access the Panorama server via the CLI and revert the changes.
Just beware and do your due diligence when implementing this on your EDLs.
Thanks for the post; although I found it after I had experienced the same thing; however, my list did not include a *.com or *.it.
name@fw(active)> request system external-list show type ip name edl-phishing-sites
Next update at : Thu Dec 27 16:00:02 2018
Source : https://10.x.x.x/feeds/phishing-url?v=panosurl
Referenced : Yes
Valid : Yes
Auth-Valid : Yes
Total valid entries : 2013
Total invalid entries : 59
Went through the entire text and did not find a string or consecutive wildcards together. Can't figure out why this would have recategorized pretty much every common domain as edl-phishing-sites. Thankfully I deny all traffic to those sites with my policy. We had a connectivity issue for about 5 minutes until I could back everything out. What a pita.
Today I had the same issue and I think I found the reason. I have compared the lists with and without ?v=panosurl and I found some problems with different enties. Entries in minemeld like *domain.tld will be changed to *.tld after adding the parameter to the url. I also found a typo in a manually entered indicator. This one was *:acbay.com and was also changed to *.com after adding panosurl to the url ...
So do you think there is an issue with the parser? What PANOS version are you running? I still have not moved forward in implementing due to the high risk/low payoff and there seems to be a question whether this is really happening. Sorry it happened to you but I'm also glad I'm not crazy.
To me this definately is an issue in the parser. Even if "*abc.com" isn't a valid entry on a paloalto firewall, changing this to "*.com" cannot be right. In my opinion the best would be if ?v=panosurl does the same as a paloalto firewall does (in addition to removing http:// and https://), such entries should simply be ignored.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!