skip to content

What does an intruder inherit from a decade-old firewall permit that nobody can prove is dead?

level: juniorimportance: should knowfreq 58%

answer

  1. the rule is enforcement, not paperwork
  2. the address outlived the server
  3. permitted traffic raises nothing
  4. who carries the cost of each choice

basics

~20 s

Reach. A permit is an enforced path from a source to a destination and port, so anyone who lands on the source side crosses it without attacking the firewall, filing a change, or raising an alert.

solid answer

~50 s

A firewall rule is not documentation of a system that once existed; it is a path the device enforces every second. The permit names addresses, zones and ports, not the machine somebody had in mind, so when that machine is decommissioned the path stays open and the address may be re-issued to something else entirely. An attacker who gets a foothold on the source side — typically the larger, softer enterprise network — simply uses it. There is no exploit against the firewall, because the firewall is doing exactly what it was told, and permitted traffic normally produces no alert at all. It survives because the asymmetry of blame runs the wrong way: the cost of keeping an unowned permit is invisible today, while the cost of deleting the wrong one is a stopped production line with your name on the change.

go deeper

for a junior

Be ready to say what a permit grants in concrete terms — source, destination, port, direction — and to state that removing the machine does not remove the path.

for a middle

Explain how address re-use and address-object groups quietly re-point an old rule, and why permitted traffic across a boundary produces no signal on its own.

for a senior

Show that you understand the incentive asymmetry that preserves these rules, and be able to name what evidence you would build before proposing any deletion.

for a principal

Own the framing that keeping an unowned permit is an unpriced decision, and be ready to say who in the organisation should be made to carry that cost.

## The rule is enforcement, not a record People who inherit an old rulebase tend to read it as history — a list of what the estate used to need. It is not. Every enabled line is a live grant that the device applies to each packet. The line says something like *source zone `enterprise`, destination `10.20.4.17`, TCP 1433, permit*. It does not say "the historian server that the process-data team ran until 2019". The device has never known that, and it will keep passing traffic that matches the tuple until somebody removes the line. That gap between what the rule **means to people** and what it **grants to packets** is the whole subject. Three consequences follow. **The destination outlives the server.** The host is gone; the address is not. In most estates addresses get re-used — a static address is reassigned by hand, a DHCP scope hands the lease to a new device, or the permit was written against a subnet or an address-object group that still has live members. So the permit now points at whatever occupies that space today, which nobody chose and nobody reviewed. A rule written to let one application talk to one database can end up granting a management interface, a jump host, or a vendor's laptop. **The path is directional and the source side is usually the weak side.** Boundary permits at a plant edge overwhelmingly run inward: enterprise to plant. That is exactly the direction an attacker travels. They do not need to reach the firewall's management plane or find a bug in it. They need a foothold on the source side — a workstation, a jump box, a build server — and then the boundary grants them the destination for free. **Using an old permit generates no signal by default.** Denied traffic is usually logged and often alerted. Permitted traffic is the baseline. Unless someone has separately built visibility on that flow, the day an intruder rides a permit written for a decommissioned system looks identical, at the boundary, to a quiet day. ## Why it is still there The rule has no author who still works here, no ticket that survived the last service-management migration, and no owner the change board can call. Everyone who touches it faces the same asymmetric bet: | Choice | Cost if you are wrong | Who notices | | --- | --- | --- | | Delete it | A business flow stops — a batch, a vendor's remote session, an annual test | Immediately, loudly, with your change number attached | | Keep it | An attacker inherits reach nobody would defend | Possibly never; if ever, long after the fact | A rational individual keeps it. A rulebase full of rational individuals accumulates thousands of them. This is why interviewers ask about it: they want someone who understands that the default is not neutral. Keeping an unowned permit is a decision with a cost, it is just a cost nobody has been made to carry. ## What "nobody can prove is dead" actually means The only cheap evidence the device offers is its own telemetry: a per-rule hit counter and, on most platforms, a last-hit timestamp. Both are weaker than they look — counters are volatile and a rule can read zero while the flow it describes runs every day — so "zero hits" is not proof and everybody involved knows it. That leaves you with an argument rather than a fact, which is why the change board will not sign, and why the honest answer to this question includes what evidence you would go and build. ## The answer an interviewer wants Name the concrete grant: from where, to what, on which ports, in which direction. Say that the machine's disappearance does not close the path, because the rule matches addresses. Say that it crosses without touching the firewall and without generating anything unusual. Then say why it survived — no owner, and an invisible cost on one side of the decision against a visible one on the other. That last sentence is what separates a candidate who has read about rulebase hygiene from one who has actually tried to delete a rule.

  • The server this permit was written for was decommissioned five years ago. Why does that not make the rule harmless?
    Because the rule matches addresses and ports, not machines. The address may have been reassigned by hand or handed out again by DHCP, and many old permits target a subnet or an address-object group whose membership has changed completely since. The grant now applies to whatever occupies that space today — chosen by nobody, reviewed by nobody.
  • Why would an attacker prefer an old permit to any other route across a boundary?
    It costs nothing and looks like nothing. There is no vulnerability to exploit, no configuration to change, no credential to use against the firewall, and no denied-traffic log entry. Permitted flows are the baseline at a boundary, so unless someone has built visibility specifically on that path, riding it is indistinguishable from normal operation.
  • If the permit is that dangerous, why has nobody removed it?
    Because the two outcomes are not weighted equally. A wrong deletion stops a production flow within minutes and is traced straight back to the change; a wrongly kept permit costs nothing visible and may never be attributed to anyone. Without someone deliberately owning the standing exposure, every individual reviewer is right to leave it alone.

It is a key still cut for a lock on a door whose original office was cleared out years ago. The office changed hands; the lock did not, and the key still turns.

saying these in an interview costs you the question

  • Says the rule is harmless because the server is gone
  • Treats the rulebase as documentation of what exists
  • Assumes an unused permit would trigger an alert if used
  • Believes change-board approval means somebody still owns it
  • Claims deleting is obviously safer than keeping, with no evidence

context

resolving links…