An intruder gets a session on your firewall's management console — what does that let them do that evading the firewall never would?

## The console is a control above the controls Every network control — the firewall, the intrusion sensor, the access-control policy engine — enforces a configuration it was handed. That configuration is data, and the console is the interface that writes it. So the console is not in the traffic path at all; it decides what the traffic path *does*. Interviewers on network-defence loops probe this because candidates who can list firewall features often have never thought about who is allowed to change them. ## Evade versus rewrite An adversary in the data path has to beat the rule on every packet: tunnel over a permitted port, fragment, encrypt, stay under whatever threshold provokes a response, and repeat that for every hop of the intrusion. It is work, and it is fragile — one mis-shaped attempt produces a denied session somebody might notice. An adversary on the console does none of that work. Concretely, they can: - add a permit, or widen an address object or group that an existing permit references; - remove a zone pair, or reorder the rule base so a broad permit is evaluated before a narrow deny; - switch an inspection or prevention profile into a mode that only logs; - add an exception in the access-control policy so a device of theirs is admitted to a segment; - change what the device forwards for monitoring, so a copy of the traffic simply stops being taken. After any of these the traffic is *authorised*. This is the direction of the claim that matters and it is the one weak answers get backwards: a permitted flow in a firewall log does not prove the flow was intended, it proves the running configuration allowed it. Flow records (a five-tuple, byte and packet counts and timestamps, and no payload at all) will agree, because they record what moved, not what should have. ## What the console's own records prove A successful console logon proves a credential was accepted from a source the device was willing to answer. It does not prove the named engineer typed it, and it does not prove the change was authorised. If the configuration change record lives only on the device, the account that made the change can usually alter or clear it — evidence about a control should not be produced solely by the thing under question. The practical countermeasure is boring and effective: a configuration copy pulled on a schedule from somewhere the console account cannot write to, diffed against the running policy, and change records landed off the device. That is what lets you say later what the policy actually was on Tuesday, rather than what the device says it was. ## The two questions that actually bound the damage They are both reachability questions, and they are what this subject reduces to: 1. **Which network can open a session to the management interface at all?** If the answer is "the general office LAN", then any workstation foothold is one hop from the policy. 2. **Whose directory does the console believe?** If the answer is "the same directory as email", then a directory account with the right group membership is a firewall administrator, and no network filter was evaded to get there. ## What it costs to answer them well This is the half candidates skip. Removing general reachability means building and funding a separate management path, and something must still reach that path — so you inherit a new question about where it terminates. Separating the directory means a second joiner/mover/leaver process and break-glass local accounts on every device whose passwords have to be vaulted and rotated. Operationally, on-call gets slower: an engineer can no longer fix a device from wherever they are. And someone has to own the failure mode where the separate path is down and nobody can reach anything. Those costs are why the weak posture is so common. The honest answer names them rather than pretending the hardened design is free. ## The wrong answer a competent engineer still gives The common senior-sounding miss is to treat the console as *a host to harden* — strong password, patch it, add MFA, restrict the admin group — and stop there. Hardening lowers the chance of the first foothold; it changes nothing about which network may open a session and whose directory decides who is an admin. A phished directory account with the right group membership walks in through the front door of a fully patched console, and every control that console configures is then only as trustworthy as that one account.