What's the difference between custom URL filtering in security policy and in URL filtering Security Profile?

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

What's the difference between custom URL filtering in security policy and in URL filtering Security Profile?

Not applicable

Hello, Guys, I have one question.

First below is the packet flow from "Packet Flow.pdf" document. According to this document ...

1.jpg

In the red square, before PA make session table, it checks packet's ip and port (like the legacy L4 firewall), and then after the session created, it check Content, APP-ID.


So I made this rule(URL Block).

2.jpg

According to packet flow.pdf, 'URL Block' rule should check packet's ip and port first and then should block those packet. >> Am I right?

That means that the packet would never go Contents-ID, and APP-ID process. And URL filtering happens in Content ID process.

According to the document ,the session should never be created.

But in my lab test, it worked fine as the rule made (It worked like as if I used URL filtering profile.If I use URL filtering profile, the action should be 'allow' in security rule, and 'block that category' in url filtering profile.)

I just wondering, then what's the difference between in Security policy and Security Profile URL filtering.

And I want to hear your opinion. It would be very appreciated if you point out what's my mis-understading.

Thank you very much.

9 REPLIES 9

L4 Transporter

Hello JTR,

When you use a URL category in a security rule you are applying various security profiles (URL, Spyware, FIle Blocking, Vulnerability, Antivirus and Data) against websites that are categorized based on the categories that you have selected in the security policy.  An example of this might be to apply a stronger set of profiles when visiting social media sites.   In some ways it is just a matter of what approach you want to take.   The other approach may be to have stricter security profiles applied to all traffic originating from certain parts of your network regardless of the type of website (category).

I hope this adds some clarity.

Phil

Really Thanks Phil.

Actually I'm very confused. Do you mean that I shouldn't use URL category in security policy just for blocking some specific URL?

Let say I want to block 'www.google.co.kr' URL with custom category in security policy. Are you saying that this is not a good example?

googleblock.jpg

It worked just like I make some url profile with google site blocked in black list.

Regards,

You should better use custom url list for that.Make your list, choose block in url filtering profile for that custom list, make this profile to be used in security rule.

Also a deny rule will never use security profile.so category3 rule's profiles will not work.

url category

used in policy

only matches pre-defined or custom category

Action is related to policy

Logged as traffic log

URL filtering

Apllied to allowed security policy

can match pre-defined,custom category and

also allow/block list

action can be configured individual by URLS

Logged in URL filtering log

Hi

It's related application based on HTTP and SSL protocol only and used in policy with action of security policy. It's a very useful feature to control URLs on HTTP and SSL and Administrator can be understanding definitely with watching only security policy (not to check URL filter profile in another window) when he try to control the URLs to be allowed or denied.


I believe that most of Admins requested to control URLs definitely in security policy so PANW created that URL control in policy. I've liked that feature for creating security policy with controlling few URLs.

Smiley Happy Have a good Korean Holyday called HanGeulNal.

Thanks.

Regards,

Roh

L4 Transporter

HI

here URL Filtering feature can be used by placing categories directly in policies or attaching a URL Filtering profile to a security rule. URL filtering only affects HTTP and HTTPS traffic.

The URL Category field can be used as a match condition for security, QoS, decryption, and Captive Portal policies. Both pre-defined and custom categories can be matched when using the URL category field. The URL category itself does not have an associated action – traffic behavior is controlled by the policy.

The URL Filtering security profile provides granular control for traffic allowed by a security policy. As with other profiles, the URL filtering profile is only applied if the associated policy allows traffic. The profile can match URL categories, as well as individual URLs. Each category can be assigned a different action for more focused management. For example, a security policy could be created to allow all web browsing but have a policy which blocks all access to file sharing websites and logs all access to social networks.



Really thank you for your kind reply.

I have one more question about flow logic. Below red square area.

flow.jpg

Does this red square means....

1. PA ignore application category in security policy by setting the app category value from 'something' to 'any'.

In the below picture, PA set rule1's application category from 'web-browsing' to 'any', and then do security policy lookup and find out rule2.

After PA find out rule2 , PA makes session table , then do the application-ID, then block the 'web-browsing' by using rule1.

rule1.jpg

OR

2. PA checks whether there's any security rule which has 'any' value in app category.

In below picture, PA do security rule lookup which has 'any' value in its Application category and find rule2, then setup the session table,and do the App-ID, finally block 'web-browsing'.

rule1.jpg

What does the PA exactly do in the red square process?

L2 Linker

Does Palo alto lookup source and destination zones and IP addresses before matching a URL category?we have a scenario in which we have created a Custom URL category and applied it in one security policy but Palo alto is matching that Custom URL category to many Security Policies regardless of the Source and Destination zones and IP addresses.Is this an expected behavior?

Traffic will match the first Security Policy that fits the available information at the time of the initial connection (which is usually only the source/destination and possibly IP protocol), and will be re-evaluated to match later Security Policies if new information from the connection no longer matches the existing policy. If you have a Security Policy based on IP/destination zone, then all traffic to that destination will match, even if there is a more specific Application/URL policy later on. If you have a Security Policy with only custom URL Category as a matching filter, then the PaloAlto will match all potential traffic to that Security Policy until the URL can be determined not to match (as a HTTP URL request doesn't come until multiple packets into a TCP session). The same applies for Application/Service matching. So generally you want to make your initial Security Policies as specific as possible, and have more general rules afterward to catch non-specific traffic.

 

So if you have Security Policy that has filters for:

1) Destination IP:

    --> matches all traffic to that destination, regardless of any other factor

2) URL Category:

    --> matches all traffic (not necessarily port 80/443) until the URL can be determined not to match

3) Application/Service, URL Category

    --> matches all corresponding Application/Service traffic until URL can be determined not to match

4) Destination IP/range, Application/Service, URL Category

    --> matches all corresponding destination IP and Application/Service specific traffic until URL can be determined not to match

  • 10546 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!