Custom URL Category

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Custom URL Category

L7 Applicator

I have a test url category with only one url. i have applied this url category to a test policy, not using a profile but directly in the policy under "service/url category".

 

when i browse to the site it uses the correct policy to allow the request...

 

however... any other traffic that cannot be decrypted is showing in the traffic logs as url category "Any" and this is also allowed via my test policy.

 

am i missing something here?.....

 

Mick.

1 accepted solution

Accepted Solutions

L7 Applicator

Check your traffic log to see if there's any actual bi-directional traffic hitting it. If there are only a few packets, it's not actually matching that policy in a real way.

 

When a TCP connection first starts out, the 3-way handshake can't have the concept of a URL category so that much is allowed on your test rule as it could belong to that custom category. Once the Client Hello (or whatever else the traffic is, like an HTTP GET or some other protocol entirely), then the firewall has enough information to know it doesn't belong to that custom category, marking the session as Discard.

 

Since the initial packets were allowed via your test rule, the firewall logs that as the rule.

View solution in original post

9 REPLIES 9

Cyber Elite
Cyber Elite

If you don't decrypt traffic then HTTP GET goes inside encrypted payload and Palo identifies site based on name on the certificate. So check what name cert has on it.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Raido, thanks for your reply. I was aware of non decrypted procedure on palo and can assure you that the cert name of these sites does not match the url in the custom category.

 

i cannot understand why firstly these allowed sites are catagorised as "url category ANY" and secondly why they are allowed through the policy where the url cat is "test" not "any".

 

mick.

Additional information: rhe firewall does know the exact fqdn (in almost every case), because in the TLS hanshake there is the SNI attribute where the fqdn is sent in cleartext.

L7 Applicator

Check your traffic log to see if there's any actual bi-directional traffic hitting it. If there are only a few packets, it's not actually matching that policy in a real way.

 

When a TCP connection first starts out, the 3-way handshake can't have the concept of a URL category so that much is allowed on your test rule as it could belong to that custom category. Once the Client Hello (or whatever else the traffic is, like an HTTP GET or some other protocol entirely), then the firewall has enough information to know it doesn't belong to that custom category, marking the session as Discard.

 

Since the initial packets were allowed via your test rule, the firewall logs that as the rule.

Gwesson, wow... Thanks.... Good point. I will check in the morning and update.

 

mick.

Gwesson, thankyou for your time and explanation. you are correct in your explanation. I changed the logging to "session end" and now see no traffic passing through the test policy (of course it actually still is but only for the reason that you explained earlier).

 

I can't thank you enough.

 

Mick.

Does this URL category (URL column and URL Profile) match initially on other rules as well, say for instance if you have a couple of rules that allow ssl/web browsing, and are being decrypted, and one has custom URL category column, and one has simply a profile?  

@Sec101 

Traffic will always match only one rule. Even if there could be multiple matches, the first rule that matches will be applied. Only adding the URL category directly into the rule is a matching criteria, not the URL profile.

Great explanation!

MP

Help the community: Like helpful comments and mark solutions.
  • 1 accepted solution
  • 5288 Views
  • 9 replies
  • 0 Likes
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!