- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
07-23-2015 07:02 AM
Hey all,
We have a security rulebase which is causing some bizarre issues.
rule 1:
rule 2:
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?
08-03-2015 01:05 AM
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.
07-23-2015 02:37 PM
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.
07-25-2015 03:03 PM
using them in the rule is a way to get around paying for the service.
07-25-2015 03:05 PM
What's the intent of using a URL Category in security policy in conjunction with a URL Profile?
07-25-2015 04:22 PM
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!
07-25-2015 07:11 PM
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.
07-26-2015 07:57 PM
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)
08-03-2015 01:05 AM
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.
08-04-2015 01:25 AM
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.
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!