Your Suricata rules read $EXTERNAL_NET -> $HOME_NET, but every employee is now a tunnel client in one address pool. Which attacker traffic is never evaluated, and what does fixing it cost?

## The estate that breaks the assumption The address variables in a signature encode a building. `$HOME_NET` is the estate; `$EXTERNAL_NET`, usually `!$HOME_NET`, is the rest of the world; a rule written `$EXTERNAL_NET any -> $HOME_NET any` asserts that the attack comes from outside and lands inside. Almost every public rule is written that way. An officeless company breaks it. There is no campus, no server VLAN, no perimeter interface. Every employee is a tunnel client, all clients draw from one pool, and the only aggregation point where a sensor can sit is the hub's inside interface. Whatever the pool is, it is `$HOME_NET`, and now two different things collapse into it. ## Failure one: the traffic that is never evaluated When client A attacks client B across the tunnel, the packet is pool-to-pool. It is home-to-home. It does not select any external-to-home rule group, so those rules are not merely failing to match - they are not candidates. There is no alert, no near-miss, nothing in a rule-profiling report. The sensor is inspecting the traffic and the rule set is looking the other way. This matters more here than in a campus estate, because in an officeless company lateral movement between endpoints is not one path among many. It is close to the only path, and it is the path that runs straight through the hub where the sensor sits. A smaller variant of the same failure: a rule written `$HOME_NET -> $EXTERNAL_NET` to catch outbound command-and-control still works, because the destination genuinely is outside. It is the inbound half of the rule set that has gone quiet. ## Failure two: the fix that costs capacity The reflex is to set `$EXTERNAL_NET: any` and `$HOME_NET: any`. Now every rule is a candidate for every packet. The consequences are mechanical: - Grouping stops discriminating, so the number of rules a packet is considered against goes up sharply. - The multi-pattern pre-filter is now the only cheap filter left in the chain. Its quality suddenly matters: rules whose selected fast pattern is short or common now force full evaluation constantly, whereas before the header had already excluded them. - CPU per packet rises. When it exceeds what the sensor has, packets are dropped before inspection. Dropped packets are the dangerous part, because they are a detection gap that produces no alert. The rule set looks broader than it was, the coverage claim goes up, and the actual inspected fraction of traffic goes down. Nobody notices unless someone is watching capture and drop counters. ## What a competent answer proposes instead **Rebuild the variables, do not delete them.** Even without a building, an address plan can carry meaning: assign the internal service estate a distinct range from the client pool, so `$HOME_NET` for a server-facing rule and the client pool are separate sets and the direction assertion is true again. That is address planning done for the sensor's benefit, and it is legitimate to spend on. **Express direction with what still discriminates.** Where addresses no longer separate roles, service ports and `flow:established,to_server` still do. A rule written around the service and the flow direction survives an address plan that says nothing. **Write the peer-to-peer rules that are now the relevant ones.** The inbound rule set was written for a shape you do not have. Client-to-client scanning, service ports where no client should ever listen, and administrative protocols between endpoints are the signatures that fit this estate. **Widen with a measurement, not a hope.** If a group of rules genuinely must run with broad headers, ship it with a before-and-after on CPU per packet and on drop counters, and a stated capacity ceiling. "We widened the address variables" without those numbers is how a sensor quietly stops inspecting a third of the traffic. ## The interview signal The weak answer is "set them to any and move on". The next weakest is "the rules still work, they just alert more" - they do not still work, because the group was never selected. The strong answer names both failures in the same breath: the coverage that vanished because the topology no longer matches the assertion, and the capacity that vanishes if you fix it by deleting the assertion. Then it proposes an address plan and a measurement, because those are the two things that let a rule set stay both correct and affordable.