We use cookies on our website to ensure we provide you with the best experience on our website. By using our website, you agree to the use of cookies for analytics and personalized content.This website uses cookies. More Information
It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Web Security Gateway

How do I create custom domain categories on the Barracuda Web Filter?

  • Type: Knowledgebase
  • Date changed: 4 months ago
Solution #00003303

Scope:
All Barracuda Web Filters, firmware versions 3.3 and above.

Answer:
If you navigate to the Block/Accept > Custom Categories page, you can build your own custom categories using any specific domains you would like to include, any existing categories you would like to include, or both! All you need to do is this:
  1. Name your category at the top using the Category Name field.
  2. Enter the names of the domains only you would like to include in the Domains field.
    • a. Domains entered in this field should be in the form of domain.com.
    • b. Do not include HTTP, HTTPS, OR :// OR * as a part of the domain entered here.
    • c. Do not include IP addresses in the Domains field.
    • d. Do not add or leave any white space from a copy paste functions or such, as this will cause a failure also
  3. Select the existing categories you would like to include in this category and click the < Add button.
  4. When you've finished and are ready to create this new custom category, click the Add button at the bottom of the page.
Custom categories can be used in the same ways as existing categories.You can apply any rules or exceptions to custom categories in the same way as you would using existing categories.

Additional Notes:
If your Barracuda Web Filter is running on a firmware prior to version 4.0, take care to add no more than 3 existing categories to each of your custom categories; you can create exceptions using existing categories easily. Upon utilizing custom categories with domains or categories only, not URLs. This may help explain the functionality seen and expected.
When you verify a domain on the block/accept tab > Content filter page by navigating to the bottom of the page for category lookup fields.
You can enter your domain to view and click the lookup button,  ie. Kohl.com = Shopping
Now if you created a custom category for HR to go to kohls.com, as a needed domain and as an example, and called it ?HR allowed?, you will also then see the same check above as seeing Kohls.com = Shopping, HR allowed
Now also in the web log you will see these details to this showing as Shopping, HR allowed.
(this is expected to be seen this way, to help with any traffic investigation/concerns. Knowing that it is found in both places, and depending on policy configuration and authentication of users working or failing among other concerns, it will help understand what triggered the block/allow easier.)

See the policy flow here at our tech library site BLOCK/ACCEPT Order of Precedence.

Now with a custom category created, it will show up as a new category near the bottom of the content filter page when saved. These will normally be set to allow.
This is the reasoning:
1.       Say you add google.com to a custom category or add content servers and it is set to allow on the content filter pages.
2.       Users will get both of these if no rules apply, while policy is checked (so there are no rules blocking either of these or any options set to block, if web applications are available and set, or no domain blacklist for google, URL pattern match, or other policy settings for denial of this traffic. Then they finally hit the content filter page lastly and are allowed either item, considering that search engines & portals and content servers are both set to allow as single categories of these items above per content filter pages.
3.       If any settings are set to block for users, they will be blocked once a match is found, if nothing matches any policy page settings, then the content filter page will be verified lastly and look for the most restricted settings.
4.       If an exception rule gives access to certain users, only those items will be allowed per the exception rule.
 
So first to determine the overall policy of your organizations needs is crucial to what will happen, as the most restrictive block or warn settings on the content filter page will block before any allow or monitor settings.
 
Another Example. A category could be made and called POLICY BLOCK CATs, now add all categories to be blocked 100%, for all users to be denied access to.
You can now set both the authenticated page and unauthenticated pages for content filter to block both custom categories.
Bad Idea for most scenarios to do that here on the content filter page, since now if a rule for a URL match was set for something simple like schoolhouserock, to allow your schools URLs, and this would take precedence before the content filter page could block it.
This is Bad why?  because what if a porn site added schoolhouserock to its URL(s) anywhere in it, It would be allowed by a URL pattern match first and never get to the content filter page to be blocked.
Next best reason is this, THE MOST RESTRICTIVE ON any* PAGE WILL BE DENIED FIRST ANYWAY (*WHILE THE EXCEPTIONS/RULES LIST RUNS LIKE AN ACL FROM TOP TO BOTTOM, not most restrictive first) .
So then if the porn category, etc.. is set to block, then it will be blocked by most restrictive, even if the custom category is set to allow on the content filter page!
So if you want to have a 100% best practice, you would make a rule to block all users for the category of junk categories and move it up as a first listed rule to be hit first to block all users.
Flow is like this:

1.       Exceptions > if match > done

2.       IF No match > next policy page and so on, until the content filter page being last, to allow or deny a request made by category.

3.       On the content filter page, the most restrictive settings will be applied first to match! > if no match, then allow traffic per authenticated or unauthenticated page settings.

4.       Settings by most restrictive (1st block, 2nd block/Warn, 3rd monitor(flag)/allow, 4th allow).


Link to This Page:
https://campus.barracuda.com/solution/50160000000H9X2AAK