Procedure - How-to-troubleshoot-CP-Secure-Web-Filtering-Webroot/Procedure

How to Troubleshoot Secure Web Filtering (Webroot)
NetCloud Feature
Security
ft:locale
en-US
ft:sourceName
Salesforce
allViewCount
3221
Document Type
Article
  1. Ensure the device can reach one of the following locations over T port 443 to perform category/reputation lookups.
  • bcap15.brightcloud.com (NetCloud OS 7.2.60 and older), or
  • api.bcti.brightcloud.com (NetCloud OS 7.2.70 or newer)
  1. Review the Secure Web Filter configuration using NetCloud Manager to determine the following: 
  • If the Secure Web Filter service is enabled.
  • Which networks the Secure Web Filter applies to.
  • What content the Secure Web Filter will filter based on policies and custom categories.
Refer to Enabling and Configuring Secure Web Filter for more information.
 
Run the following command from the CLI to verify the service is running: 
get /status/system/services/webfilter
Run the following command from the CLI to verify the Secure Web Filter rules are installed in the firewall:
netfilter | grep 53531
  1. Verify the licensing is applied correctly for Secure Web Filter. 
From NetCloud Manager: 

  1. Login to NetCloud Manager.

  2. Click DEVICES and then select a router. 

  3. Click the Remote Connect menu, and then select Connect to Device UI.

  4. Click System > Administration > Feature Licenses.
OR 

Run the following command from the CLI:
feature show
  1. Clear the following caches.
  • System caches - on a Windows machine by running the following command in the CLI:
- ipconfig /flushdns
  1. Use the "Log Only" option

When the Log Only option is selected, Secure Web Filter creates an INFO level log message describing which policy or policies would have blocked the target URL. 

In this example, indeed.com could be blocked by the pre-defined category "Job Search" as well as a Custom Category (in this example named "BLOCK_INDEED.COM"):

  • "05:01:23 PM INFO wf-webroot 192.168.22.28" would be blocked requesting indeed.com policy (test) category (BLOCK_INDEED.COM), but 'log only mode' is enabled for this network, using default behavior.

  • "05:01:23 PM INFO wf-webroot 192.168.22.28" would be blocked requesting indeed.com policy (test) category (Job Search), but 'log only mode' is enabled for this network, using default behavior.

  1. Check debug logs. See Additional Information for an example.

    1. Set system logging to DEBUG level.

    2. Enable verbose webfilter logging (this will not persist through reboot). Type the following command in the CLI.

      set control/webfilter/enable_verbose_logging true

    3. Generate traffic that should be filtered and review the logs.

  2. Perform a tcpdump on port 53. See Additional Information for an example. If Webroot is blocking traffic, it will respond to a DNS request with a 198.51.100.91 IP address

  3. Ensure the correct rules are being evaluated in the firewall.

The "netfilter -s" command shows hit counts on specific rules. In the following output, we see that traffic matching the lan_wr ipset with a destination of port 53 is proxied to port 53531.

[admin@AER2200-abc: /]$ netfilter -s

7: --protocol tcp -m tcp  --dport 53 -m set  --match-set lan_wr src,src -j REDIRECT  --to-port 53531 (packets: 0, bytes: 0)

8: --protocol tcp -m tcp  --dport 53 -m set  --match-set lan_all src,src -m set ! --match-set lan_router dst -j REDIRECT  (packets: 0, bytes: 0)

9: --protocol udp -m udp  --dport 53 -m set  --match-set lan_wr src,src -j REDIRECT  --to-port 53531 (packets: 0, bytes: 0)

10: --protocol udp -m udp  --dport 53 -m set  --match-set lan_all src,src -m set ! --match-set lan_router dst -j REDIRECT  (packets: 0, bytes: 0)

[admin@AER2200-abc: /]$ ipset list lan_wr

set lan_wr:

0.0.0.0/0,primarylan1

set lan_wr6:

  ::/0,primarylan1