Blocking Access for a User in a Specific AD Group

[jsalmans]

So I'm looking for the best way to block a user in a specific AD group but get them a response page while I do it.  These users are going to be students who violated network policy and are being blocked to everything except some of the educational/homework sites we run.

Initially I thought of just doing two security policies... a permit with FQDN objects for the sites we want to allow, and then a deny for everything else right under it.  Each would have the AD user group specified.

I'm not sure though if there is a way to present a page to them indicating why they're being blocked.  Even if there was, I don't want everyone on the network to see it when they get a block.

What I'm thinking now is a single permit security policy with a specially created URL Filter rule attached that would have everything blocked with either exceptions to the sites or a custom URL Cateogry for the sites we want to allow.  This would get them to a response page but I'm not sure how I'd give them a separate message than what people normally get when hitting the response page for other reasons... I'd want to give them a message that they're getting blocked due to being in the policy violator group no matter which category they hit.

Am I on the right track with either of these or is there something else I should look at?

Thanks!

[Remo]

Hi @jsalmans

Do you already have the application block page enabled? If not, one possobility would be to use this response page and change this one to the specific content you want to show these students. With this method you should - as you proposed - two security rules: one with either addressobjects or a custom URL category attached directly to the rule and another rule that blocks everything else for these stutents and where it is possible (http traffic) the firewall will show the application block page.

The other possibility would be to dynamically change the URL block page based on the sourceuser. The big disadvantage of this solution is, that you need to specify the sourceusers in the block page in a little part with javascript to be able to change the content for different users.

And another possibility I can think of is, if you specify a custom URL category with *.* as content. This custom category you add to a dedicated URL profile for these users with the action block and allow for all other categories. This way you should be able to change the content with javascript ob the blockpage based on this custom URL category and this will allow you to "easily" achieve what you want without changing the block page every time when there is a userchange in the AD group. 

So I personally would try the last possibility in my post and this does not work for you the first one. The second one works but is ... not so good 😛

[jsalmans]

@Remo

I believe the application block page is already enabled.

The URL response page already has some javascript added to give custom messages based on category being blocked (i.e. a message for malware, a message for phishing, etc).

That's an interesting idea to do a custom URL category with just a wildcard in it essentially.  The question is, if I have a category like that, which one is it going to match if a website fits into say Educational but also matches the Custom Category with the wildcard?  So for my normal URL profile, I have malware, phishing, and some others blocked but if I allow the wildcard category which one will it match?

[Remo]

@jsalmans

Thats the point where I am not 100% sure if the wildcard behaves the same as "normal" entries. I am pretty sure that it will be like that but I haven't done this so far. We only use a custom category shared over multiple firewalls when we want to block something in general. At least there it works that the custom category has always the higher priority than builtin categories.

[jsalmans]

@Remo

That actually may be an issue if it takes priority.  Since my other URL Profiles will show that category as well, if I permit it I would think it would override the built-in categories I'm blocking.

If the wildcard is set to block in a profile and then so is Malware for instance, if I go to a Malware website I wonder what category would show up in the variable on the response page?

This would be so much easier if you could assign a custom Response Page for each URL Filter Profile instead of having a global one.  Heck, if I could get the name of the URL Profile as a variable on the response page that would work too since you could then write javascript to do conditional code.

*edit* So the application block page might still work for this.  It's arleady enabled anyways and I found some older documentation that indicates "<rulename/>" is a variable that can be used.  If I do some more javascript to check on the Application Blocked page if the rule name matches the deny rule with this specific user group associated with it, I would think that would allow me to display the specific content just for them.  If a policy is only a deny any application policy, will it still trigger a blocked application response page or will I need a rule specifically denying web-browsing and then another rule denying anything else?

*edit2* It's also unclear if that "<rulename/>" variable is there for all response pages or just the application block one.  If it works for the ULR Filtering response page too I might be able to use this in the conditional javascript to determine whether the user was blocked for the policy violation.

[Remo]

@jsalmans

If there is a rulename variable, even better. Good to know 😉

But regarding the other possibility with the wildcard custom category: Just make sure that the action of this category is set to "none" in your other profiles, so that this category will have no effect there.

[jsalmans]

@Remo

Ah I completely forgot about the ability to set None for the categories.

I can confirm the rulename variable does work in the URL response page.

So at this point it seems like there may be several potential ways to do it in URL filtering and maybe a way to do it through standard security policy with application blocks.  I wonder which way might be considered best practice?

[Remo]

@jsalmans

If there is a way to avoid *.* URL entries then you should. So definately go with the way that you change the URL block page based on the <rulename/> variable.

In addition I would recommend you to create 3 rules:

1. Allow rule with the allowed destinations for these students
2. Allow rule with a URL filtering profile applied where you set everything to block
3. (Depending on the rest of your policy) Deny all rule to make sure that these students cannot use something else to somehow pass traffic through the firewall

[jsalmans]

@Remo

Thanks for the reply.

I'm assuming the 3 rules would mainly be less confusing instead of having 2 with the permit having block on everything and permit only on a custom category containing the websites we want them to be able to access?

[Remo · Accepted solution]

@jsalmans

I wrote about 3 rules because you said something about allowing specific destinations with FQDN objects. If you are talking about external websites then of course add them to a custom URL category and allow these websites in the URL Profile for these students. As you said, this way you need 2 rules and you're done 😉

[jsalmans]

For anyone that wonders about this later, I have not implemented the full solution discussed here since I'm waiting on administration to settle on some policy but I did utilize the rulename variable in the URL Filtering response page to give a message about some content filtering we're doing on our Guest wireless network.

I've got an inline Javascript switch that looks for URL category matches for some of our custom Phishing lists, Malware, etc. with custom messages for each.  The default switch case then goes in to another switch that looks for whether the Guest rule was hit.

This seems to have accomplished the desired effect for the Guest filtering... if they hit a malicious website they'll get a specific message about that but any other URL category that they hit that is blocked on that network should trigger the more general message about filtered content on the Guest network.