- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-16-2020 05:57 AM
Hi,
PanOS 9.1.0
I need to block traffic to certain websites and domains.
I created a URL Category object and put just one site inside (example.com).
I then created a firewall rule like this:
Source zone: LAN
Source address: any
Dest Zone: WAN
Dest address: any
Application: any
Service/URL Category: my URL Category Object
Action: ALLOW
(I put it on Allow because for at first I just wanted to check what traffic is hitting this rule).
I immediately noticed a very high hit count on the rule and when I viewed the rule logs I noticed it is allowing loads of traffic that doesn't relate to example.com
I'm affraid if I put this rule to Block it will block my outgoing traffic.
What am I missing
11-17-2020 06:28 AM
The URL is defined by website. In the case of an HTTP request to 'sega.com', the website responds with a 301 (Permanently Moved) to 'www.sega.com'. If you are using Chrome, it will hide the 'www.', but if you click on it will show it. If you use Firefox, you will see that you put in 'sega.com' and then it is changed to 'www.sega.com'. You can use Developer tools on either browser to see what the URL should be by following the request URL.
The firewall doesn't attempt to do a reverse DNS lookup on URL categories. The URL is determined by looking by looking at the HTTP headers, the SSL Client Hello SNI, and SSL Server Hello Common Name (CN) of the Server Certificate Subject DN. This behavior changes if SSL decryption is used.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClzlCAC
11-16-2020 07:41 AM
I did some testing in my lab and found that if you have the rule set to action 'Allow', hit count increments for every session that was allowed through the rule, even if the traffic was later proven to not match the URL Category rule.
If you change the action the 'Deny', the hit counter only only shows the sessions that were dropped by the rule.
This should be related to the rule having the action set to 'Allow' and the session being initially allowed on the rule until the URL Category can be determined, so the firewall adds the session to the hit counter.
11-16-2020 08:59 AM
Hi @TravisC
Thanks for your reply.
I'm not talking just about the hit count. I'm also talking about seeing the traffic in the monitor when clicking on the rule and choosing "Log Viewer".
You're saying the session is initially allowed before the URL can be deteremined, so if I change it to DENY, wouldn't it first deny all traffic before detemining the URL Category?
11-16-2020 10:04 AM
So, I tried switching it to Deny but it didn't do anything.
The hit count didn't change and in the monitor I can see it doesn't recognize the URL Category, it's registered as "Any".
I also tried using custom EDL URL List instead of URL Category object, but got same result.
What am I missing?
11-16-2020 10:17 AM
Do you have log at session start enabled? That would explain the logs showing up on your allow rule. I would recommend disabling log at session start.
The initially allowed traffic is for allow rules. When processing traffic, the firewall assumes that the application is set to 'any' until the firewall can determine what they are and processes the traffic under the first security rule that matches L2 - L4 with any application. This is show in the "FW Session setup/Slowpath" in the Day in the Life of a Packet diagram under 'Firewall security policy lookup'.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0
In your example of the allow rule with URL category defined and the action is set to "Allow', the firewall will match all sessions from L2 to L4 to that rule until the application can be defined. Once the application is defined, the firewall will rematch against the policy to determine if there is a rule to allow that traffic. In this example, that would still be the URL category rule since the rule is setup with any application on any service. Once the URL category is defined, the firewall will rematch against the security policy again to find the first rule to match the new information.
If your rule was set to block, the traffic would be initially allowed on another security rule until the URL category was determined 5-9 packets later. Then on the rematch the firewall will show that the traffic was dropped on your URL Category rule.
11-16-2020 10:19 AM
My testing shows that it works as intended. If your traffic was allowed after changing that rule to action 'Deny', I would look into the order of the security policy rules and make sure that another rule didn't allow the traffic.
11-16-2020 10:33 AM
I don't have log at session start, only at session end.
And I checked again, and the traffic is allowed in a rule that is after my block rule.
So that's strange why the fw can't determine the URL category.
11-16-2020 10:36 AM
What are the URL's in the URL category? Can you test with 'example.com'?
11-16-2020 10:39 AM
For testing purposes I tried with 'sega.com' 🙂
11-17-2020 06:12 AM
So I changed it to 'www.sega.com' and it worked! thanks! 🙂
So if I was asked to block domains such as abc.com, def.com, ghe.com etc., I must put 'www' at the begining if it's not actually necessery for normal browsing?
Also, does using URL category in policy rules make the PaloAlto perform a reverse DNS lookup on each packet going through the system? and if so doesn't it have a big impact on performace?
11-17-2020 06:28 AM
The URL is defined by website. In the case of an HTTP request to 'sega.com', the website responds with a 301 (Permanently Moved) to 'www.sega.com'. If you are using Chrome, it will hide the 'www.', but if you click on it will show it. If you use Firefox, you will see that you put in 'sega.com' and then it is changed to 'www.sega.com'. You can use Developer tools on either browser to see what the URL should be by following the request URL.
The firewall doesn't attempt to do a reverse DNS lookup on URL categories. The URL is determined by looking by looking at the HTTP headers, the SSL Client Hello SNI, and SSL Server Hello Common Name (CN) of the Server Certificate Subject DN. This behavior changes if SSL decryption is used.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClzlCAC
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!