Web Filtering — Tricks

Trick 1 Agent vs. Proxy/NGFW — The “Off-Network” Trigger

The single most reliable signal in web filtering scenarios is whether the user is always on the corporate network or sometimes off it. The exam uses this to discriminate between deployment models:

Forward proxy / NGFW URL filter — only works when user traffic passes through the corporate perimeter device. A remote employee on home Wi-Fi or a hotel network bypasses it entirely unless also connected via VPN.
Agent-based filtering — installed on the device itself. Policy is enforced locally regardless of which network the user connects to. No VPN, no corporate perimeter needed.

The exam trigger phrases:

“Must work regardless of which network the employee uses” → agent-based
“Remote workers, traveling employees, work-from-home” without a VPN requirement → agent-based
“Centralized control for all users in the office” → forward proxy or NGFW
“Caching to reduce external bandwidth” → forward proxy (agents do not cache)

A common distractor: DNS filtering with a cloud resolver also works off-network — but only if the device is guaranteed to query that specific resolver. Without an agent, a user can simply change their DNS settings. When the exam asks for the most reliable always-on solution, agent-based wins.

Rule: “Works anywhere without VPN” = agent-based. “Caching + bandwidth savings” = forward proxy. A proxy only controls traffic that flows through it; an agent follows the user.

Trick 2 Explicit vs. Transparent Proxy — Look for the Configuration Clue

The exam distinguishes these two proxy types through a single clue: whether client-side configuration is required. Read for it explicitly:

“The browser/application must be configured to use the proxy” → explicit proxy. An unconfigured application bypasses it. IT often pushes this configuration via Group Policy.
“No configuration required on the client” / “users are unaware their traffic is proxied” → transparent proxy. Network infrastructure redirects traffic to the proxy; the application has no knowledge of its existence.

The exam trap: A question describes a proxy that “works silently in the background” or that “intercepts traffic without the user knowing.” Candidates often answer “agent-based” because agents also run silently. The difference: a transparent proxy is a network device the user’s traffic passes through; an agent is software installed on the user’s own device. If the question mentions network infrastructure routing, think transparent proxy, not agent.

Secondary distinction — explicit proxy limitation: If an application is not configured to use the explicit proxy, it communicates directly — bypassing the proxy entirely. Transparent proxies close this gap by intercepting at the network layer before the packet leaves the subnet.

Rule: Configuration in the browser = explicit. No configuration, user unaware = transparent. Silent proxy on the network = transparent. Silent software on the device = agent. Do not confuse the two.

Trick 3 DNS Filtering Is Not Just for Browsers — It Blocks Any DNS Lookup

The most common mistake candidates make with DNS filtering is treating it as a web browsing control. It is not. DNS filtering intercepts DNS lookups, and any application that resolves a domain name — not just a browser — is affected.

The critical exam scenario: Malware installed on an endpoint needs to contact a command-and-control (C2) server. The malware performs a DNS lookup for the C2 domain. If that domain is on the DNS blocklist: the DNS server returns no IP address → the malware cannot initiate a TCP connection → C2 communication fails. This happens even if the malware never opens a browser, uses a non-standard port, or runs entirely in the background.

What DNS filtering stops vs. what it does not:

Stops: connections to known-malicious domains by any application; phishing sites; malware C2 callbacks using domain names; newly registered bad domains added to threat intelligence feeds
Does not stop: connections to malicious IP addresses (no DNS lookup required); encrypted DNS (DoH/DoT) that bypasses the filtering resolver; malware that hardcodes IP addresses instead of using domain names

Exam phrase triggers for DNS filtering: “Before connecting… a DNS lookup is performed” → DNS filtering. “No IP address is returned for the malicious domain” → DNS filtering. “Blocks at the name resolution stage” → DNS filtering.

Rule: DNS filtering = pre-connection blocking at name resolution. Works for ALL DNS lookups (browsers, malware, email, any app). No IP returned = no connection possible. Not limited to HTTP/HTTPS.

Trick 4 Category vs. Reputation — Two Different Dimensions of Blocking

Category filtering and reputation filtering are both URL blocking mechanisms, but they answer different questions. The exam will mix them in scenarios; knowing which dimension is being tested prevents wrong-answer selection.

Category filtering asks: What type of content is on this site? (Gambling, Adult, Educational, Malware, Social Networking…). A site blocked by category is blocked because of its topic, regardless of whether it is safe or dangerous.
Reputation filtering asks: How risky is this site? (Trustworthy → Low Risk → Medium Risk → Suspicious → High Risk). A site blocked by reputation is blocked because of its perceived danger level, regardless of its topic.

Why both are needed together: A legitimate gambling site is blocked by category policy (wrong topic for the workplace) even if it has a Trustworthy reputation. A brand-new phishing site may not yet be in any bad category, but its reputation score will be High Risk immediately — caught by reputation filtering before category rules help.

Exam scenario triggers:

“Blocked because it is categorized as Gambling” → category filtering
“Automated scan assigned a High Risk score” → reputation filtering
“Administrator manually changed the site’s rating” → reputation filtering (manual override)
“Blocked even though no category matched” → reputation filtering

Rule: Category = topic of the site (what it is). Reputation = risk of the site (how dangerous it is). New malicious sites get caught by reputation before category lists are updated. Category enforces policy; reputation enforces safety.

Practice Scenarios

Scenario A: A financial services firm employs 400 people, of whom 120 are fully remote. The CISO asks for a web filtering solution that: (1) enforces the same URL policy for office and remote employees, (2) requires no VPN for remote workers, (3) provides centralized visibility into all browsing activity, and (4) blocks access to Gambling, Adult, and known-Malware categories. The firm currently has an NGFW at the perimeter with URL filtering enabled. What additional technology is needed, why does the existing NGFW solution fall short, and how should the two solutions co-exist?

Answer: The existing NGFW URL filter only processes traffic that physically passes through the corporate perimeter. The 120 remote employees connect to the internet directly from their home networks — their traffic never touches the NGFW. For them, the Gambling, Adult, and Malware category blocks are completely absent. The additional technology needed is agent-based content filtering deployed on all 400 endpoints (office and remote). The agent enforces the same URL policy locally on each device regardless of which network the employee is connected to, satisfying the “no VPN required” and “same policy everywhere” requirements. The central management console provides unified visibility across all endpoints. Co-existence: the NGFW URL filter can remain as a defense-in-depth layer for any unmanaged devices (visitors, contractors) that connect to the office network but do not have the agent installed. For the 400 managed endpoints, the agent is the authoritative policy enforcer. The two solutions complement each other without conflict.

Scenario B: A security analyst notices that a workstation is generating DNS queries for a domain named “c2update-heartbeat-xyz.net” every 30 seconds. The workstation’s user has not opened a browser in six hours. The domain does not appear in any URL category list but has been flagged by a threat intelligence feed as a known malware C2 domain. The organization uses DNS filtering integrated with a real-time threat intelligence feed. What is happening, what will DNS filtering do, and what should the analyst investigate next?

Answer: The workstation is infected with malware that is attempting to check in with its command-and-control server. The regular 30-second DNS query is the malware’s heartbeat — it resolves the domain to get the current IP address of the C2 server. The user not having a browser open is irrelevant: malware runs as a background process and performs DNS lookups independently of any browser activity. DNS filtering will block the lookup: when the malware queries for “c2update-heartbeat-xyz.net,” the DNS filtering server recognizes the domain on the threat intelligence blocklist and returns no IP address. The malware cannot establish a TCP connection to the C2 server. Its ability to receive new commands, exfiltrate data, or update itself is cut off for as long as the domain remains blocked. What the analyst should investigate: (1) Identify the process on the workstation making the DNS requests — this reveals the malware binary or infected process. (2) Check how long the DNS queries have been occurring to determine the infection window. (3) Determine whether any successful DNS resolutions occurred before the threat intelligence feed added the domain to the blocklist — if so, C2 communication may have already happened. (4) Isolate the workstation, acquire a memory image and disk image for forensic analysis, re-image the endpoint, and check for lateral movement to other systems from the infection window.

Scenario C: A company’s URL filter uses both category-based rules and reputation filtering. The category policy allows all “Technology” category sites. The reputation engine is configured to block any site scored “High Risk” or “Suspicious.” An employee reports they cannot access a vendor’s software download page. The IT team investigates and finds: the page is categorized as “Technology” (would be allowed by category), but the automated reputation system scored it “Suspicious” because it was registered two weeks ago and has a low volume of historic traffic. The vendor is a known, legitimate partner. What is the correct resolution, and what does this scenario illustrate about the interaction between category and reputation filtering?

Answer: The correct resolution is a manual reputation override. The IT administrator should access the reputation management interface and manually assign the vendor’s download page domain a reputation of “Low Risk” or “Trustworthy.” The manual assignment takes precedence over the automated score. Once applied, the domain passes the reputation check, the category check (Technology = Allow) also passes, and the employee can access the page. What this illustrates: category filtering and reputation filtering operate as independent enforcement layers. A site can pass one check and fail the other. In this case the site passed the category check (correct topic) but failed the reputation check (new domain, low traffic volume = automated Suspicious score). The automated reputation system uses heuristic signals — young domains are statistically more likely to be malicious, but legitimate new sites are also young. This is the false-positive cost of reputation filtering. The manual override capability exists precisely for this scenario. Rather than disabling reputation filtering for all “Suspicious” sites (which removes a meaningful security layer) or adding the domain to a URL category exception (wrong mechanism), the administrator corrects the specific data point — this site’s reputation — while leaving the broader policy intact. This is the purpose of manual reputation management in the URL filter architecture.

Web Filtering — Exam Tricks