All URLs from certain users are categorized as “Uncategorized” and getting blocked when they should be allowed

book

Article ID: 225309

calendar_today

Updated On:

Products

Web Security Service - WSS

Issue/Introduction

Users accessing WSS services via WSS agents

All users appear to be working fine and malware detection, policy execution returns expected status

A group of users that have recently rolled out the WSS agent however keep getting blocked and the custom error page rendered would indicate that

 - every blocked URL is 'uncategorized' and

 - every target is an IP address and not a domain name

WSS Admin has force deny rule enabled when match detected

They do have a valid DNS server and all blocked URLs can be successfully via nslookup.

Cause

A negate policy rule triggered all requests for the group of users to be blocked at the TCP layer before the HTTPS proxy can validate the request.

The TCP layer check failed based on the destination IP address not being categorised (which is often the case) 

Environment

WSS Agent

Force_deny rule implemented when matching rule found

Resolution

Took existing single policy with negate logic and split it into two seperate policies.

The original policy checked to see if 'source' user was a member of group X and was NOT accessing any of the defined categories in a category list. This was turned into two rules:

  - rule 1: if 'source' user was a member of group X and was accessing any of the defined categories in a category list user was entitled to access, ALLOW and

  - rule 2: if 'source' user was a member of group X, force deny 

 

We could not reproduce this in a test environment.

Additional Information

HTTP logs showed that all blocked users were accessing IP addresses at the time at TCP level, even though it should have gone up to HTTPS level 

1234 2021-09-30 15:40:50 "DP2-GIEDU1_proxysg2" 12 77.97.97.97 BCOM\ncash "Domain Users, BCOM-Sitel-Webfiltering-Users" Global_Cloud_Proxy_Denied DENIED "Uncategorized" - 0 TCP_ACCELERATED TUNNEL - tcp 36.156.128.138 443 / - - - 192.168.2.85 0 0 - - - - 0 "client" client_connector "none" "none" 35.165.128.138 "United States" - - - - - none - - - - none - - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - - "None" - "Ireland" 5 - wss-agent architecture=x86_64%20name=Windows%2010%20Enterprise%20version=10.0.18363 7.3.1.14939 02bfd900-62c1-4622-b81c-4858e26a3287 ENLLH5CG1182SW9 - - - - - - - - - - 944fd17988c9a4c4-000000004a9e0676-000000006155da82

 

Policy trace showed force deny for TUNNELED (TCP) requests:

connection: service.name=HTTPS client.address=77.97.97.97 (NAT address=10.242.0.8) (effective address=77.97.97.97) proxy.port=443 source.port=15750 dest.port=443
  location-id=0 access_type=client_connector
time: 2021-09-30 16:16:46 UTC
TUNNEL tcp://36.156.128.138:443/
  RDNS lookup was restricted
user: name="BCOM\ncash" realm=cloud_realm group-bitset=00000001000000100001100000011 goi-version=145
user: name="BCOM\ncash" realm=cloud_realm
authentication start 1 elapsed 0 ms
authorization start 1 elapsed 0 ms
authentication status='none' authorization status='none'
te_user address='F373A2220' te_session address='F373A20A0'
user: authenticated=true authorized=true relative username='NCASH'
supplier.allowed_countries: all
supplier.failures: -
EXCEPTION(Global_Cloud_Proxy_Denied): Either 'force_deny' or 'force_exception' was matched in policy
bypass_cache(yes)
  url.category: [email protected];[email protected] Coat
    total categorization time: 0
    static categorization time: 0
outbound source IP: 36.156.128.138