Egress Proxy Lab
The firewall decides what can connect; the proxy decides where your users can go. Build an egress policy by domain and category over a default posture, replay outbound requests, and learn the three things that actually make or break web filtering: default-deny vs. default-allow, whether you are doing TLS inspection, and whether "allowed" is quietly letting data walk out the door.
Goal
Default-deny egress. Allow the SaaS tools and software updates the business runs on, and block the C2 channel, the data exfil to a paste site, and the malware download.
Egress policy (first match wins)
Score vs goal
Edit the policy, then replay to grade it.
Why TLS inspection matters
With inspection off, a category rule can't classify an HTTPS request — only domain rules and plaintext HTTP match. Turn it off and watch category blocks silently stop firing on HTTPS traffic.
Live now
4 on this scenariousers coming online…
What this lab is
- A free web-proxy / egress-filtering lab: write a domain- and category-based allow/block policy and replay labelled outbound requests through it.
- Policy is first-match-wins over a default posture (default-allow or default-block), exactly like a forward proxy or secure web gateway.
- A TLS-inspection toggle shows the real trade-off: with inspection off, category rules cannot classify HTTPS traffic and silently stop firing.
- A data-loss signal flags large POST uploads to non-business destinations as possible exfiltration.
- Scenarios cover egress lockdown, AI governance and shadow IT — scored on threats blocked vs. business traffic kept.
Frequently asked questions
What is the Egress Proxy Lab?
A free, in-browser exercise where you build a forward-proxy / secure-web-gateway egress policy — allow or block by domain (including wildcards) or by category (SaaS, AI, file-sharing, malware, anonymizer) over a default posture — and replay a set of labelled outbound requests through it first-match-wins. You see which rule decided each request and whether you met the scenario goal.
Why does TLS inspection change the result?
Without TLS interception a proxy sees only the destination (SNI/host), not the payload or application category, for HTTPS traffic. So category rules can only be enforced on HTTPS when inspection is on. The lab models this: turn inspection off and category blocks stop applying to HTTPS requests, which is exactly why unsanctioned-AI or file-sharing controls leak without it.
What is the exfiltration signal?
A large POST (hundreds of KB or more) to a destination that is not a sanctioned business service is a classic data-loss pattern. When such a request is allowed by your policy, the lab flags it as possible exfiltration — a reminder that "allowed" and "safe" are not the same, and that data-movement monitoring complements the allow/block decision.
Is this a real proxy?
No. It is a teaching model of egress decision-making. It ignores authentication, caching, ICAP and real TLS mechanics so the lessons — default posture, rule order, domain vs. category, and the inspection trade-off — are clear. Destinations and requests are invented.