skip to content

Why does an interior poller pulling from a partner exchange tier move data inward without giving a compromised tier host an inward socket?

level: middleimportance: should knowfreq 50%

answer

  1. who dials is not who talks
  2. the permit is interior to tier
  3. return traffic matches existing state
  4. the interval is the price
  5. the collector now eats hostile input

basics

~20 s

Because the host that opens the connection is not the host that sends the payload. The interior opens the socket outward; the response carries the data inward on that same permitted flow, so no rule ever allows a tier-initiated connection.

solid answer

~50 s

A stateful filter makes its decision on the packet that opens a flow, and the permit says interior-to-tier. The interior job connects out to a queue or drop location, and the bytes it collects travel inward as the reply on a connection the tier never opened — return traffic the firewall associates with an existing entry rather than a second, inward-facing rule. So connection direction and data direction come apart: the tier can send you gigabytes without ever being allowed to dial you. What you pay is a collection interval on every transaction, a drop location whose integrity is now yours, and one more thing to keep available. And the risk has changed shape rather than vanished: an intruder on a tier host cannot reach in, but they can write what the interior faithfully collects, so the collector must treat everything it fetches as hostile — fixed schema, size ceilings, filenames that cannot become paths.

code

text · 12 lines
text
flowStartMilliseconds  = 2026-03-04T09:15:02.114Z
sourceIPv4Address      = 10.20.4.9        destinationIPv4Address   = 203.0.113.20
sourceTransportPort    = 51442            destinationTransportPort = 8443
octetDeltaCount        = 1240             packetDeltaCount         = 14
# interior -> tier: the interior opened it; this is the request

flowStartMilliseconds  = 2026-03-04T09:15:02.147Z
sourceIPv4Address      = 203.0.113.20     destinationIPv4Address   = 10.20.4.9
sourceTransportPort    = 8443             destinationTransportPort = 51442
octetDeltaCount        = 48910336         packetDeltaCount         = 33218
# tier -> interior: 48 MB of payload, on a connection the tier never opened
...

go deeper

for a junior

Know that the side that opens a connection is not necessarily the side that sends most of the data, and that a firewall decides on the opening packet.

for a middle

Explain the mechanics: the permit is interior-to-tier, the reply is matched to existing connection state, and the drop-and-collect or queue pattern is what turns an inward need into an outward connection.

for a senior

Be ready to price it. Give the collection interval, the state left sitting in the untrusted zone, the quiet failure when collection stalls, and the fact that the collector is now interior code parsing input from a zone you distrust.

for a principal

Own the trade between direction control and content authentication: decide when end-to-end signing by the true producer is required, and what you tell a counterparty whose contract wants a synchronous answer the pull cannot give.

## The distinction the question turns on A rule that says *the exchange tier may not initiate a connection toward the interior* is enforced on one packet: the one that opens the flow. Everything about the direction of the **data** is a separate matter. Who dials is not who talks. That is why the inside-out pull works. An interior job — a collector, a queue consumer, a scheduled fetch — opens a connection outward to a drop location or message broker that lives in the tier. The permit it needs is *interior source, tier destination*, which is a direction the rule always allowed. The payload then travels inward as the response on that flow. A stateful filter matches the returning packets to the flow entry it created when it permitted the first packet, so nothing needs an inward-initiated rule and nothing about the boundary has been relaxed. The flow records make it concrete. Two unidirectional records describe one session: the request record has the interior address as source with an ephemeral port, the response record has the tier address as source on the service port and carries tens of megabytes. Read carelessly, the second record looks like the tier sending data inward — which it is. Read correctly, the ephemeral/service port pairing and the timestamps say the interior opened it. Note also what those records do **not** contain: a flow record carries the five-tuple, byte and packet counts and timestamps, and no payload at all. It can tell you 48 MB moved inward and can never tell you what was in it. ## The patterns this licenses - **Drop and collect.** The tier writes files into a location; an interior job connects out, lists, fetches and deletes. Simple, auditable, and the whole interface is one directory and one file format. - **Message queue in the tier.** The tier enqueues; an interior consumer connects out and dequeues. Better than files for ordering and acknowledgement, and the queue's schema is a natural place to constrain what can be said. - **Replicated read-only copy.** Where the tier needs interior *reference* data (a product catalogue, a partner list), the interior **pushes** a copy out to a store in the tier on its own schedule. Again interior-initiated, again no inward permit, and the tier gets a local read with no latency at all. All three share the property that the interior is always the party that dials. ## What it costs 1. **Latency, on every transaction.** A synchronous lookup that took milliseconds becomes a wait for the next collection cycle. Shorten the interval and you trade it for constant connection churn and load; lengthen it and a partner sees a slower service. If a counterparty's contract promises a live answer within a request, the pull pattern is what makes that hard, and that tension is where exception requests are born. 2. **A component you now own.** The drop location or queue is infrastructure in the tier: it needs capacity, cleanup, backup, availability and monitoring, and when it fills or stalls the integration stops silently rather than loudly. Collection failures are quiet failures — build in an age alarm on the oldest uncollected item. 3. **State on the wrong side.** Data waiting to be collected sits in the untrusted zone for the length of the interval. If it is sensitive, it needs to be protected at rest there, and the interval is now also an exposure window. 4. **Ordering and duplication.** Fetch-and-delete is not atomic on every store; collectors crash mid-fetch. You inherit at-least-once semantics and the idempotency work that follows. ## What it does not fix The pull removes the *path* and leaves the *data*. An intruder who owns a tier host cannot reach inward, but they can write into the drop location, and the interior will come and get it — the collector is now the most exposed interior component you have, reached by design from a zone you declared untrusted. So the collector must be built as if the source were hostile, because it may be: - Accept one fixed schema or format, and refuse anything else without attempting to be helpful. - Cap size and count, and refuse rather than truncate. - Never derive a filesystem path, a command, or a destination from a value inside the collected item. - Parse with the narrowest reader available; do not deserialise into arbitrary objects. - Authenticate the content where you can — a signature applied by the true producer before it ever reaches the tier is worth more than any check the tier can make about itself, because it survives the tier being owned. That last point is the mature version of this answer. If the partner or the interior signs the payload end to end, a compromised tier can delay, delete or observe messages, but it cannot forge one that the interior accepts. Direction control buys you the network; content authentication buys you the data. Interviewers ask this question to find out whether a candidate knows they are two different purchases.

  • If the tier needs interior reference data, how do you supply it without an inward permit?
    Push it outward. The interior replicates a read-only copy of the reference data into a store in the tier on its own schedule, on an interior-initiated connection. The tier then reads locally with no latency and no permit, and you accept that the copy is as stale as the replication interval — which is why you replicate only data that tolerates being minutes old.
  • What can a flow record showing 48 MB from the tier to the interior actually prove?
    That bytes moved in that direction on that flow, and nothing more. It carries the five-tuple, counts and timestamps, with no payload, so it cannot say what the data was or whether it was legitimate. Port pairing and timing tell you which side opened the connection; only the collector's own logs and the content itself say what arrived.
  • How do you keep a compromised tier from forging messages the interior accepts?
    Authenticate the content, not just the channel. Have the true producer sign the payload before it reaches the tier and verify that signature on the interior side after collection. A compromised tier can then still delay, delete or read messages, but it cannot manufacture one that verifies — the tier is reduced to a transport it cannot speak on.

A one-way turnstile at the interior wall: only people inside may push through it to fetch a parcel, yet parcels keep arriving inside — because the parcel never had to walk.

saying these in an interview costs you the question

  • Says data can only travel the way the connection was opened
  • Believes return traffic needs its own inward rule
  • Claims the pull removes the risk rather than reshaping it
  • Treats collected files as trusted because they came from our own tier
  • Thinks flow records show what was transferred
  • Ignores the collection interval as a real latency cost

context

resolving links…