It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Web Security Gateway

What are the best practices when implementing blocking/allowing policies on the Barracuda Web Filter?

  • Type: Knowledgebase
  • Date changed: 2 years ago
Solution #00006625

- All Barracuda Web Filters. All firmware versions.

1. Define the types of users that you need to apply rules to.

Most customers have three groups of users

1. The completely unfiltered users (managers, company owners, etc)
- The completely unfiltered could have their policy applied by IP address under IP block/exempt, or as an "All Web Traffic rule" under exceptions.
2. The normal internet users
- The policy applied to normal internet users is the usually done using the Content Filter. Set categories based on the desired policy.

3. The Strictly filtered users.
- Strictly filtered users are usually allowed access to only a handful of sites. To accomplish this:
  1. Create a Custom Category containing the desired domains that these users have access to.
  2. Add the existing category of content server to the custom category.
  3. Save the custom category, then create an exception for the strictly filtered users and apply the custom category to the users in this exception.

2. Decide how users will be group and identified

a. Active directory root level security group (LDAP)-This is for normal desktop users, identifiable by IP address. It is recommended that rules be applied to root level Active Directory security groups, and not OUs wherever possible. It is recommended that you use root level security groups because the web filter cannot identify users residing in nested groups.

b. Citrix/Terminal server users -You would need to use NTLM of Kerberos authentication for these users. These users will still be grouped by root level Activity Directory security group, but will use NTLM or Kerberos instead of LDAP. Rules that can be applied to LDAP users can also be applied to Kerberos/NTLM users.

c. Local Users - This creates a local user database on the web filter. User will have to log into the Barracuda block page.

d. Unauthenticated users - most global policies under content filter, Domains, and URL Patterns can be applied to Authenticated and unauthenticated users.

e. IP Subnet/group- User can be grouped by subnet and even individual IP address, and rules can be applied to this subnet group. These users are still consider to be unauthenticated, but you can be more granular when applying rules to an IP group rather than unauthenticated users as a whole.

3. Set up your policy based on the information identified in the previous two steps.

a. For completely unfiltered users, assign them a static IP address or identify them by username. If the IP exemption is used, the exempted machines will not be logged or filtered. If an all web traffic exception is used, the user will be logged and will be filtered. Please note that even if a rule says "All Web Traffic "allowed, it does not mean that these users may not have issues with problem sites. (See Solution #00004277 for more detailed instructions on how to add an IP exemption)

b. For users defined as "Normal Internet Users," set content filter categories to the desired setting.
It is not recommended that the content filter rules all be set to block (as sites are added, removed, and re-categorized every day). Setting all categories to block, and depending solely on custom categories and exceptions to block traffic, is not recommended due to extra processing required by the rules, administrative overhead, and the increased possibility of human error.

It is also not recommended that more than about 10% of categories are set to monitor at any one time. Traffic from all categories, including those set to allow will be logged in the web log. The monitor option allows you to see desired traffic at a glance in the web log. Allowed traffic shows as green in the log and monitored traffic shows at yellow. This allows for easy identification of the monitored traffic.

Setting a category to warn will display a message before the user is able to proceed to the desired site.
c. Now define rules for the strictly filtered users. Define that custom category for these users. (See Solution # 00003303 for information on defining custom categories). Apply exception rules to allow the custom category for the users, then create another exception rule for this same user group to block them from all other web traffic.

It is not recommended that you include the same domain in several custom categories, as this makes it difficult to track down which rule applies to which group.

It is recommended that you use custom categories to apply exception rules to existing content filter categories, rather than applying them directly in the exceptions page.


It is not recommended to set the Exception rule to the exception type (content filter) sub-category (such as Social Networking).


Create a custom category called Social-Allow including the categories of Content Server and Social Networking

Exception rule = exception type (content filter) sub-category (Social-Allow)

4. Applying rules to other user groups.

a. Local Users and IP Subnet Groups are considered special-use cases.

b. Local Users - If you do not have any authentication servers in your environment, you can create a local user database on the web filter. In order for this to work, you will have to create an exception rule blocking all unauthenticated traffic. Local Users will then have to log into the block page with their credentials. This also becomes a limitation, in that you will no longer be able to allow other unauthenticated traffic.

c. IP Subnet Groups - If you would like to apply more granular rules to unauthenticated users, you can do this by using IP Subnet Groups. You can also create groups containing only one machine. This is done by configuring the IP Group with a subnet mask of Once the group is created, you can apply exception rules to it. IP Subnet groups also work well for applying rules to an entire subnet. This can really come in handy when applying rules to a subnet that is not a part of the domain, like a Guest Wireless subne (please reference Solution #00006312 for further information).

Additional Notes:

where a custom category gets created, is on the content filter page, under the block/accept tab.
Here it is always created as ?allowed?, this is not a concern* as to policy allowing it.
You blocked porn on content filter page but have set a ?block all users? custom category including porn category and clicked to re-categorized, Now porn is actually viewed as ?block all users? and not porn category anymore. So with no rule setup the policy would end up hitting any porn site and now reference the allowed ?block all users? custom category on the content filter page and not be an expected result for you. This would be the scenario to being sure it is set to block for a custom category created.
Reasoning is this:  The most restrictive blocks on the page will take precedence. Meaning if Porn is set to block as a category in general, it is blocked if no policy hits before the content filter page. Now if a rule was to override some URL pattern match to allow certain URLs to pass then the hierarchy would allow by the URL pattern matching page first, so best practice would be to create a block rule for the category to be hit first before anything else ever. The category name created will also be viewed in a domain lookup on the content filter page and in the web log details section for a known category found and any matching custom category names found, per the domain or category referenced.
You may reference Solution# 3303 to help understanding the flow of precedence with a custom category being used also.
The concern would be if you use the re-categorize option for a custom category ? which in turn removes from the original category of listed domains and now makes it your new category name you created.