skip to content

Your user segment can never hold a destination allow-list - what do you still enforce at its border against an implant, and at what price?

level: seniorimportance: should knowfreq 46%

answer

  1. change the question the border is asked
  2. paths and protocols, not destinations
  3. one recorded egress, one identity
  4. attribution is not denial
  5. capacity and failure posture get signed

basics

~20 s

Stop enumerating destinations and enumerate paths instead: deny direct outbound from that segment and permit only the inspected proxy path plus the few internal services it needs. You buy one choke point with identity and a record rather than denial, and you pay in capacity, failure posture and exceptions.

solid answer

~50 s

For a population that must reach the whole internet, the border cannot answer "which destinations", so it answers "which paths". The rule becomes: from that segment, no direct outbound at all; permitted only toward the inspecting forward proxy, the internal resolver, and whatever the mail path requires. That is a real change of posture - anything leaving is on one path where a source identity, a destination name, a time and a size are recorded, and anything that refuses that path simply fails. What it is not is denial: a session to a destination nobody has ever heard of still succeeds if it looks like ordinary web traffic. The prices are concrete. The proxy is now on the critical path for the whole population at peak, so its capacity and its failure posture become design decisions somebody has to sign. And every device that cannot be told about a proxy needs a direct exception, and those exceptions are the residual path.

go deeper

for a junior

Know the shape of the rule: that segment gets no direct outbound, only a permitted path to the proxy plus a couple of internal services. Know that this is about paths, not destinations.

for a middle

Explain what changes when destination filtering becomes path filtering - what the proxy records that a border five-tuple does not, and what the rule still does not decide.

for a senior

Be ready to state the residual out loud in a design review: this gives attribution and a choke point, not denial, and here is exactly what still leaves and who carries it.

for a principal

Own the service commitment. Putting a whole population's internet access behind one inspected path creates an availability target, a capacity budget and a fail-open decision that an executive has to accept in advance.

## The question the border can still answer A destination allow-list answers "where may this segment go". For a staff-and-student population that question has no bounded answer, so asking it produces a list that grows until it permits everything. The move is to change the question the border is asked. Instead of *which destinations*, enforce *which paths and which protocols*. Concretely, the outbound policy for that segment permits: traffic to the inspecting forward proxy or secure web gateway; traffic to the internal resolver; whatever the mail path genuinely requires; and nothing else. Direct outbound on every port, to every address, is denied - including port 443 straight to the internet, which is the rule people forget and the one that carries the whole point. ## What that actually buys **A single path.** Everything that leaves does so through one place, so there is one place to record it, one place to change policy, and one place that fails. **A record with a name in it.** The proxy sees the destination name the client asked for, the time, the size and the direction, even when it does not decrypt the body. That is a far better record than a border five-tuple. **An identity, if you put one there.** A proxy that authenticates the user, or a session mapped to a directory identity when the device joins, turns "a source address in the lecture theatre" into "a person". Without that step you have a shared address after translation and your attribution is a building, not a user. **A hard failure for anything that will not comply.** Software that insists on a direct connection to a fixed address does not degrade quietly - it breaks, visibly, and lands in your exception queue where you can see it. That is a feature. ## What it does not buy, and you must say so It is not default deny for that segment, and calling it that in a design review is the mistake to avoid. A session that presents as ordinary web traffic to a destination nobody has ever heard of goes through, because you have no basis to refuse it - the population is entitled to reach unfamiliar sites. You converted a denial control into an attribution control. Code running on a machine in that segment still has an outbound path; what it no longer has is an *unobserved* one. ## The prices, in order of who complains first **Capacity.** The proxy is now on the critical path for an entire population at its peak - the first week of term, a lecture hall of four hundred devices waking at once. Capacity is no longer an efficiency question, it is an availability commitment. **Failure posture.** When it fills or falls over, there are two options and both are bad. Fail closed takes the population off the internet during the busiest week of the year. Fail open removes, silently and at the moment of highest load, the only visibility you built. The answer is not a preference - it is headroom sized for the known peak, plus a declared, logged, deliberately authorised fail-open rather than one that happens by default because nobody chose. **Latency and breakage.** Every session takes an extra hop. Some things break in ways users experience as "the network is bad": long-lived connections, protocols the proxy does not understand, endpoints that pin certificates. **Exceptions.** Devices that cannot be told about a proxy need a direct permit at the border. Each one is a small hole in the path guarantee, and collectively they are the residual - so they need a named owner and a bounded destination each, not a blanket direct-outbound permit for a whole appliance VLAN. **Non-web egress.** Denying direct outbound breaks real work that is not web traffic - remote shell to a code host, research data transfers on unusual ports, third-party client software. Those become exception requests, and the queue that services them is a permanent cost of this design, not a launch task. ## How to present it The design sentence that earns trust in a review is the honest one: *for this population the border enforces a path, not a destination set; that gives us one recorded egress with an identity on it and it does not deny an adversary an outbound channel; the residual is carried by detection and by endpoint controls, and the proxy is now a funded service with an availability target.* Every clause in that sentence is something somebody else has to agree to, which is exactly why it belongs in writing.

  • The proxy saturates in the first week of term. Fail open or fail closed for a campus user population?
    Price both before choosing. Fail closed removes internet access for the whole population during the busiest week and produces an incident nobody forgives; fail open silently deletes the visibility you built at the moment load is highest. The workable answer is headroom sized for the known peak plus a fail-open that is declared, logged and authorised by the service owner - not a default nobody chose.
  • Does forcing everything through the proxy tell you who sent it?
    Only if the path carries an identity. After address translation a shared source address gives you a building, not a person. You get a name when the proxy authenticates the user or the session is mapped to a directory identity at connection time. Without that step, "attribution" at the border is an address several hundred devices share.
  • Why is denying direct outbound on port 443 the rule people skip, and what happens when they do?
    Because it is the one that breaks things, and leaving it permitted looks harmless since web traffic is allowed anyway. But the whole guarantee is that there is no path around the proxy. If direct 443 to any address is permitted, anything that chooses not to use the proxy simply does not, and the recorded single egress you designed does not exist.

You cannot vet every place a crowd might go, but you can make everyone leave through one door with somebody standing at it - and then that door had better be wide enough for the rush.

saying these in an interview costs you the question

  • Calls a mandatory proxy path default deny for that segment
  • Assumes nothing hostile can use the permitted proxy path
  • Leaves direct outbound on 443 permitted alongside the proxy
  • Ignores that the proxy is now a peak-load single point of failure
  • Promises to allow-list a browsing population eventually

context