- Blocked website categories: Select the categories you wish to block.
- URL category list size: Select "Top sites only" for higher performance or "Full list" for better coverage. When "Top sites only" is selected, the list of top sites in each of the blocked categories will be cached locally on the appliance. In this mode, client requests for URLs that are not in the top sites list will always be permitted (as long as they are not in the blocklist). If "Full list" is selected, a request for a URL that is not in the list of top sites will cause the appliance to look the URL up in a cloud-hosted database. This may have a noticeable impact on browsing speed when visiting a site for the first time. But the result will be cached locally. Over time, the "Full list" performance should approach the speed of "Top sites" option.
- Web search filtering: Enable this setting to enforce Safesearch for Google, Yahoo!, and Bing for all users in your network. This will not affect SSL/HTTPS searches.
- Restricted YouTube content: Enables restricted YouTube content functionality which leverages DNS-based enforcement. Once enabled, the YouTube restriction level option appears which provides a drop-down where either Moderate or Strict can be chosen. More details about restriction levels can be found here.
- Blocked URL patterns: Enter specific URL patterns you wish to block, one per line. See below for details on pattern matching.
- Allow listed URL patterns: Enter specific URL patterns you wish to explicitly allow, one per line. See below for details on pattern matching.
If communication to the cloud hosted lookup server is blocked or disrupted upstream while utilizing the "Full list" option the security appliance will default to block the URL that was submitted. Inversely if communication to the cloud hosted lookup server is blocked or disrupted upstream while utilizing the 'Top lists' option the security appliance will allow the URL that was to be categorized.
IP addresses are a supported option in Block/Allow listed URL pattern fields. When you enter an IP into that field, it's interpreted as a URL because as it turns out, http://192.168.1.1 is a perfectly valid URL, regardless of the fact that it's also an IP address. Note that this is not the same as an IP block - it'll just block/allow list someone who types in 192.168.1.1 into their web browser. In addition, that would also mean if abc.com resolves to 192.168.1.1, content filtering will not block/allow list abc.com explicitly. You will need to enter abc.com as an URL in Blocked/Allow listed URL patterns as well.
Using the Catch-All Wildcard (*) in URLs
The asterisk symbol has two primary uses in URLs for content filtering.
- Standalone Catch-All Wildcard
- The " * " (asterisk) symbol when used on its own line is an all-inclusive wildcard which represents all possible entries
- When used on its own line in allow listed URL patterns, ALL URL patterns are allow listed
- When used on its own line in blocked URL patterns, ALL URL patterns are blocked, except those that are explicitly allow listed
- In-URL Asterisk Character
- The " * " (asterisk) symbol when used as part of a URL or in line with a URL is simply a regular asterisk symbol and is interpreted as part of the URL, NOT as a wildcard
- Note that this is very rarely useful, except in URLs that actually require asterisk symbols, such as https://web.archive.org/web/*/meraki.com
Patterns for Blocking or Allow Listing Specific URLs
Whenever a device on the network accesses a web page, the requested URL is checked against the configured lists to determine if the request will be allowed or blocked.
Pattern matching follows these steps in order:
- Try to match the full URL against either list (blocked vs allow listed patterns list)
- Remove the protocol and leading "www" from the URL, and check again:
- e.g., foo.bar.com/qux/baz/lol?abc=123&true=false
- Remove any "parameters" (everything following a question mark) and check again:
- e,g., foo.bar.com/qux/baz/lol
- Remove paths one by one, and check each:
- e,g., foo.bar.com/qux/baz, then foo.bar.com/qux, then foo.bar.com
- Cut off subdomains one by one and check again:
- e.g., bar.com, and then .com
- Finally, check for the special catch-all wildcard, *, in either list.
If any of the above steps produces a match, then the request will be blocked or allow listed as appropriate. The allow list always takes precedence over the blocklist, so a request that matches both lists will be allowed. If there is no match, the request is subject to the category filtering settings above.
In the example above, the specific (longer) URL is allowed because it is the longest match, whereas any other access to foo.bar.com domain will be blocked.
Blocking all Websites Using Content Filtering
An MX Security Appliance can be used to block all web content then configured for specific websites only. This can be specifically important when needing to be in a very controlled environment such as a school.
1. Navigate to Security & SD-WAN > Configure > Content filtering
2. Place an asterisk (*) in the Blocked URL patterns section
HTTPS requests can also be blocked, but because the URL in an HTTPS request is encrypted, only the domain URL checks will be performed in the following order:
- * (the special character for catch-all URL)
Once your Active Directory server settings are entered into Dashboard, you can click Refresh LDAP Groups to populate a list of user groups in your domain. You can then select individual groups and apply configured Group policies to them. For information about configuring Group policies, see the Group policies page.
Content Filtering Rule Priority
There are a number of different ways on the MX to use content filtering to block or allow access to websites. In circumstances where different filtering options contradict one another, the following priority applies (from highest to lowest priority):
Blocked and allow listed URL patterns.
Content filtering rules applied via Group Policy (using Active Directory or otherwise).
Global content filtering rules.
Practically speaking, with these rules in mind, consider the following best practices for content filtering design:
- Global content filtering rules should be designed as the "default" network experience.
- Group Policies should be used to create a "custom" network experience for users, which can be made either more or less restrictive than the default.
- URL patterns should be used to append or allow list a specific URL from the configured blocked categories.