How to Troubleshoot Secure Web Filtering (Webroot) - How-to-troubleshoot-CP-Secure-Web-Filtering-Webroot/How-to-Troubleshoot-Secure-Web-Filtering-Webroot

How to Troubleshoot Secure Web Filtering (Webroot)
NetCloud Feature
Security
ft:locale
en-US
ft:sourceName
Salesforce
allViewCount
3221
Document Type
Article
  • Effectively troubleshoot CP Secure Web Filtering (Webroot) 
  • Understand logs from CP Secure Web Filtering (Webroot) 
CP Secure Web Filtering (Webroot) Most commonly, issues with Webroot are related to cached entries or misconfiguration. If you suspect Webroot is not filtering traffic as expected, there are multiple ways to better understand how/if the service is functioning.
  1. Ensure the service is running:
    1. Webroot proxies connections to port 53531. Via the CLI, run "netstat -a | grep 53531"
  2. Ensure the Cradlepoint can reach bcap15.brightcloud.com (7.2.60 and older) or api.bcti.brightcloud.com (7.2.70 or newer) over TCP port 443 to perform category/reputation lookups.
  3. Clear caches:
    1. System - this can be done on a Windows machine by running the following command in the CLI - ipconfig /flushdns
    2. Browser
    3. Webroot - How to clear the CP-Secure Web Filter (Webroot) local cache
  4. Use the "Log Only" option
    1. When the Log Only option is selected, CP Secure Web Filter will create an INFO level log message describing which policy or policies would have blocked the target URL. 
      1. In this example, indeed.com could be blocked by the pre-defined cateogory "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.
  5. Check debug logs (example in Additional Information):
    1. Set system logging to debug level
    2. Enable verbose webfilter logging (this will not persist through reboot):
      1. In the CLI, type "set control/webfilter/enable_verbose_logging true
    3. Generate traffic that should be filtered and review the logs
  6. tcpdump on port 53 (example in Additional Information):
    1. If Webroot is blocking traffic, it will respond to a DNS request with a 198.51.100.91 IP address
  7. Ensure the correct rules are being hit in the firewall:
    1. netfilter -s will show 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:
      1. [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)
      2. [admin@AER2200-abc: /]$ ipset list lan_wr
        set lan_wr:
          0.0.0.0/0,primarylan1

        set lan_wr6:
          ::/0,primarylan1
  • CP Secure Web Filter interacts with the dnsmasq service
    • You may not see traffic going out the WAN because dnsmasq caches
    • dnsmasq does have a limit to how many requests it can service. When it hits that limit it will just start dropping requests
  • The Webroot queue can fill up although this typically occurs due to an issue unrelated to Webroot (e.g. WAN interface is down)

In the example below, Webroot blocks a request for indeed.com because the Job Search category is blocked:

[admin@AER2200-abc: /]$ log -f
04:48:20 PM DEBUG wf-webroot handle_udp_connection : client ('192.168.22.28', 55082)
04:48:20 PM DEBUG wf-webroot handle_udp_connection: que request for indeed.com from 192.168.22.28:55082
04:48:20 PM DEBUG wf-webroot process_queue_data - client: ('192.168.22.28', 55082)
04:48:20 PM DEBUG wf-webroot dns_req_urlname: indeed.com []
04:48:20 PM DEBUG wf-webroot is_special_dns_domain - split DNS match: [] known_host match []
04:48:20 PM DEBUG wf-webroot is_special_dns_domain - returning: False
04:48:20 PM DEBUG wf-webroot Lookup w/Rep: indeed.com for 192.168.22.28:55082
04:48:20 PM DEBUG wf-webroot Lookup cache miss on: indeed.com - Not Found
04:48:20 PM DEBUG wf-webroot lookup_callback: sending resp back ('indeed.com', 'indeed.com', [(26, 83)], 81, 1)
04:48:20 PM DEBUG wf-webroot uncat: False defblk: False lookup_results: ('indeed.com', 'indeed.com', [(26, 83)], 81, 1)
04:48:20 PM DEBUG wf-webroot lookup_results : ('indeed.com', 'indeed.com', [(26, 83)], 81, 1) blocked : True reason : policy reason_val 26
04:48:20 PM INFO wf-webroot 192.168.22.28 blocked requesting indeed.com reason is policy (test) category (Job Search)
04:48:20 PM DEBUG wf-webroot DNS Response (b'\xber\x81\x80\x00\x01\x00\x01\x00\x00\x00\x00\x06indeed\x03com\x00\x00\x01\x00\x01\xc0\x0c\x00\x01\x00\x01\x00\x00\x00\x1e\x00\x04\xc63d[')
 
[admin@AER2200-abc: /]$ tcpdump -i any port 53 -n
16:48:20.256555 ethertype IPv4, IP 192.168.22.28.55082 > 192.168.22.1.53: 48754+ A? indeed.com. (28)
16:48:20.256555 IP 192.168.22.28.55082 > 192.168.22.1.53: 48754+ A? indeed.com. (28)
16:48:20.256555 IP 192.168.22.28.55082 > 192.168.22.1.53: 48754+ A? indeed.com. (28)
16:48:20.338442 IP 192.168.22.1.53 > 192.168.22.28.55082: 48754 1/0/0 A 198.51.100.91 (44)
16:48:20.338732 IP 192.168.22.1.53 > 192.168.22.28.55082: 48754 1/0/0 A 198.51.100.91 (44)
16:48:20.338996 ethertype IPv4, IP 192.168.22.1.53 > 192.168.22.28.55082: 48754 1/0/0 A 198.51.100.91 (44)