Custom URL Category issue

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 issue

L4 Transporter

Hello,

 

We have followed this guide: 

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

 

Decrypt portion is working well. However we are finding the custom category and its contents although set to block, are not blocking https unless its in the block override.

Example url HTTP results in below block: Correct categorisation blockCorrect.jpg

HTTPS version of the same url (although decrypted) gets blocked by the override block-list from the catchall policy I have in place.

Incorrect.jpg

 

 

1 accepted solution

Accepted Solutions

@BPry 

 

Thank you for your help.

Noticing the destination nat port, we modified the security policy to be App-id = web-browsing and Service = custom service group of port 80 and 443.  This appears to have resolve the issue.

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

@FarzanaMustafa,

Look at your system logs and verify that you are actually hitting the proper security policy where the URL category is applied. If you are not, then please post the entry you are actually trying to map on and the URL that isn't being caught. 

Hi @BPry 

 

Thank you for the response. We were able to make it work by changing the Service type to 'any' instead of 'application-default'.

However, this is not good as it allows app-ids to high risk profiles. 

What is the best practice to structure our rules below?

 

Rules.jpg

@FarzanaMustafa,

I'd really need to take a look at your application filters and see what applications they are matching to be sure; but when you start decrypting traffic one of the primary issues you'll run across is that web-browsing will map to tcp-443 (due to decryption) and that doesn't work with application-default policies. 

I would try your same policy, but make a subsequent policy that allows web-browsing on service object service-https and see if that doesn't fix the issues that you were running into without the 'any' policy. 

@BPry 

 

Thank you for your help.

Noticing the destination nat port, we modified the security policy to be App-id = web-browsing and Service = custom service group of port 80 and 443.  This appears to have resolve the issue.

  • 1 accepted solution
  • 5409 Views
  • 4 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!