URL Category behavior with rule match condition question

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

URL Category behavior with rule match condition question

L0 Member

I came across behavior that confused and concerned me recently. I had a test rule with the following conditions set:

Source Zone (LAN)

Source user 

Destination Zone (WAN)

Application (ANY)

URL Category (not in Profile/Action section, but in Service/URL section)

 

I was under the understanding that the URL Category is part of the match condition when placed in the Service/URL section (and therefore impacts logging visibility), however when testing this the actual behavior showed otherwise. Traffic logs for this rule showed it was matching ANY application and web traffic without regard to the URL Category.

 

I then looked up and found this KB article with the following comment:

URL categories in security policies

In the above example, Rule Y is configured to block adult category websites using the URL category option present in the security policies. Web-browsing application must be explicitly mentioned in the policies when using the URL category option in the security policies. Otherwise, irrelevant traffic with match this rule. Another way of controlling websites based on URL categories is to use URL filtering profiles.

 

I tested this by setting the application to web-browsing only, and web-browsing & SSL. This appears to be correct where if there's any application traffic that is allowed other than just web-browsing, the URL Category in the security rule is essentially useless and the rule allows all traffic. 

 

Can anyone explain how this is the case? Even if SSL was allowed in Application (which most web browsing traffic is these days), that renders the ability to have a rule match condition using a custom URL Category useless! I'm at a loss here as to how this can be. 

 

1 REPLY 1

L4 Transporter

Hello @Josh_Morris,

 

I assume you've configured the security policy actions, setting them to 'log at session start' and 'log at session end'.

When dealing with a security policy where the application is set to 'any', it's possible that a higher volume of traffic will initially hit this policy during session setup. This traffic will be logged based on your security policy's specified log settings. Subsequently, as the application becomes identified (due to application-shift), a policy lookup occurs again to match the traffic against a more specific policy. If no policy is defined to allow the specific application at this point, the traffic will be denied.

In your particular scenario, you've included a custom URL profile in the security policy's service/URL section. This inclusion permits traffic toward the specific URL you've defined within the service/URL section. The logs you're observing might be somewhat misleading due to the way Palo Alto firewall policy lookup functions. To address this, you could consider reconfiguring the security policy to log traffic solely at 'session end'. This approach would display only the logs that successfully matched the security policy by the end of the session.

 

These security policy logs will appear in URL filtering logs if the security policy action is set to 'deny'.

I've provided a link below for further reference:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClKvCAK

 

I hope this explanation proves helpful

 

Anoopkumar
Network Security Engineer
  • 1425 Views
  • 1 replies
  • 0 Likes
  • 38 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!