using url categories in security rule base blocks allowed traffic

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.

using url categories in security rule base blocks allowed traffic

L4 Transporter

Hey all,

We have a security rulebase which is causing some bizarre issues.

rule 1:

  • trust to untrust
  • service: tcp-80
  • url category: online-storage
  • url filtering profile: alert-all
  • allow

rule 2:

  • trust to untrust
  • service: tcp-80
  • url category: /
  • url filtering profile: alert-all
  • allow

when we do some web traffic to www.bing.com we get 2 different type of results

A) we hit rule 2

traffic logs show: allow

url filtering logs show: category = search-engines - action: alert

B) we hit rule 1

traffic logs show: allow

url filtering logs show: category = any (??) - action: block

what I think is happening in situation B is: Traffic is hitting rule 1, and because at this stage the PaloAlto does not know the url category it will allow traffic through this rule (zone and service are a hit). After some packets the url category is known as search-engines => this means the traffic is actually not allowed by rule 1 and thus traffic is dropped (even though there is a rule 2 which would have allowed this traffic!). The category = "any" in the url filtering logs is just some strange behaviour of the PaloAlto.

Now I know this rulebase does not make sence, but it's just a recap of what is happening. The actual rules involve different user-groups and allowed applications.

Question is:

Anybody else find this kind of behaviour.

Why is traffic sometimes hitting rule 1, and sometimes rule 2?

1 accepted solution

Accepted Solutions

L4 Transporter

Hey All,

I have been investigating this issue with PaloAlto tech support and we found the issue.

We've been able to track the trigger condition down to safe search enforcement setting on the URL profile. For some reason, the string "FORM=IE" from the URL will trigger this behavior. So for some reason this would make it so search traffic to BING sometimes hit rule 1, and sometimes hit rule 2.

But I do agree that using URL categories in the rulebase is just asking for trouble.

View solution in original post

8 REPLIES 8

L4 Transporter

This may have already been mentioned, but I'd highly suggest you use the URL Filtering profile categories to filter categories instead of putting it into that portion of the rule itself.

using them in the rule is a way to get around paying for the service.

L6 Presenter

What's the intent of using a URL Category in security policy in conjunction with a URL Profile?

I believe that the engine is still active, we just have to create our own custom categories instead of using the pre-defined ones with the purchased license.

Thanks!

I can't keep it straight if using it in security policy either doesn't create a URL log or doesn't allow you to use a URL response page, but I know it's one of them as well.

The only way URL Filtering logs will be created is if we have a URL Filtering Profile attached to the rule passing the traffic and the action is set to anything but Allow. (Alert, Block)

L4 Transporter

Hey All,

I have been investigating this issue with PaloAlto tech support and we found the issue.

We've been able to track the trigger condition down to safe search enforcement setting on the URL profile. For some reason, the string "FORM=IE" from the URL will trigger this behavior. So for some reason this would make it so search traffic to BING sometimes hit rule 1, and sometimes hit rule 2.

But I do agree that using URL categories in the rulebase is just asking for trouble.

Dear

Please note that: using url categories in a security policy, instead of a security profile does NOT work if you do not have a license.

You still need an active license to be able to use url categories.

You do not need a license to use custom url categories, which you can then use in security policies as well as in security profiles.

The use in policy or profile has nothing to do with license.

  • 1 accepted solution
  • 5490 Views
  • 8 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!