URL Filter doesn't work in Deny rule

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

URL Filter doesn't work in Deny rule

L1 Bithead

I have 2 rules for IT group: IT_Deny and IT_Allow as in the picture below. I'm using a same profile group for both rules, in profile group I have a URL_filter that block some websites like bbc.com, cnn.com

But when I access bbc/cnn, I get blocked by URL filter in profile group in IT_Allow rule. I don't understand why I don't get blocked by IT_Deny rule, IT_Deny rule still let me access bbc/cnn??

 

Capture.PNG

1 ACCEPTED SOLUTION

Accepted Solutions

It was mentioned that SYN matches second rule and for that reason block rule does not apply. This is not correct.

Every application shift invokes policy check. If application changes to web-browsing then ruleset is checked again.

 

Your issue is that Security Profiles are checked only if Security Policy permits traffic.

If policy denies traffic then Security Profiles are not checked.

Good example is that there is no reason to look for viruses in traffic that is blocked anyway.

 

If you want to block URL categories then you:

- Block it in URL profile and set policy action Allow.

- Add URL category directly into policy (under Service/URL Category tab) and set rule action to Deny

 

@SeanBui I edited reply a bit.

 

Enterprise Architect, Security @ Cloud Carib Ltd
ACE, PCNSE, PCNSI

View solution in original post

10 REPLIES 10

L4 Transporter

can you please upload a screenshot of the traffic and url logs? (deny and allow case)

L6 Presenter

Most likely you are not matching all security policy criteria (s) (e.g destination ip). Not sure if security profiles even processed for "deny" action in the security policies. 

L5 Sessionator

Hi,

 

It can be explained because your traffic doesn't match your first rule. On ly diff is your app group ITT, which app are embeded ?

 

On which criteria do you want to allow or block access to these URL ?? AD member ? list of IP ?

 

V.

 

@VinceM and @TranceforLife are both correct. 

 

When the first packet arrives, it looks to see if it matches your first rule (IT_Deny). If you're attempting to block sites like bbc.com and cnn.com, the first packet will just be a SYN packet on port 443. That SYN packet is not enough to identify the app as SSL for the app-id engine (even though eventually it will be identified as such). Since that first packet doesn't get denied, it won't match that rule until an app-id shift.

 

When your first TLS packet arrives at the firewall (Client Hello, likely containing the server name) can now identify that it is cnn/bbc, and deny it based on your URL filtering profile. The traffic was being processed on rule 2 (IT_Allow) at the time that information was available, so that's what it matches in your logs.

 

If you're set on having a deny policy for this, add the category to the IT_Deny policy. But it won't give the user a nice category deny page, instead it'll just drop the packet. It's generally much better to allow the traffic and use the URL filtering profile to handle what is denied and allowed.

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!