Traffic hitting policy rule it shouldn't

[Jonathanct]

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 

[TravisC]

@Jonathanct 

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.

[Jonathanct]

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?

[Jonathanct]

@TravisC 

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?

[TravisC]

@Jonathanct 

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.

[TravisC]

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.

[Jonathanct]

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.

[TravisC]

What are the URL's in the URL category? Can you test with 'example.com'?

[Jonathanct]

For testing purposes I tried with 'sega.com' 🙂

[TravisC]

@Jonathanct 

The URL should be 'www.sega.com'.

[Jonathanct]

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?

[TravisC · Accepted solution]

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

[SecNaterr]

Searching for an unrelated topic but stumbled on this, and it's fairly old, but would "*.sega.com/" solve this issue?