Egress Control: Why Outbound Traffic Is the Blind Spot

Ask a network team about their firewall and they will describe what it blocks coming in. Ask what it allows going out, and the honest answer is usually 'almost everything'. That asymmetry is the attacker's favourite feature of the modern enterprise. Every stage of a breach after initial access — calling home to a command-and-control server, pulling down tooling, exfiltrating the data — is outbound traffic. Egress control is the neglected half of the firewall, and it is the half that catches the theft.

The historical logic made sense: the threat was outside, the assets inside, so you built a wall facing out. But once an attacker is inside — and modern attacks assume they will get inside — the wall is behind them. Their malware needs to reach the internet to receive commands and to ship out what it steals. If outbound is unrestricted, it does both trivially, over ports that look ordinary. Controlling egress reintroduces friction at exactly the stage where the attacker has the most to lose.

What 'controlling egress' actually means

It does not mean blocking the internet. It means that outbound traffic passes through a policy instead of a gap. Servers, in particular, should reach a short, known list of destinations — the package repositories, APIs and update endpoints they genuinely need — and nothing else. A database server has no legitimate reason to open a connection to an arbitrary host in another country. When it tries to, that is not noise; that is the signal, and an egress policy is what turns the attempt into an alert instead of a silent success. The reason this works as detection is that a compromised workload's first outbound call to attacker infrastructure is, almost by definition, to a destination it has never legitimately needed.

• Default-deny egress for servers. Workloads should reach an allowlist of destinations through a proxy or filtering gateway. This is far more tractable for servers than for user laptops — start there.
• Force outbound through a chokepoint you can see. Traffic that bypasses the proxy is traffic you cannot inspect; ensure there is no direct route to the internet that skips the control.
• Watch DNS as an egress channel. Even 'blocked' hosts can smuggle data out through DNS queries; monitor for the high-volume, high-entropy lookups that signal tunnelling.
• Alert on new and rare destinations. A workload suddenly talking to a domain it has never contacted — registered last week, in an unusual location — is a classic C2 tell.
• Do not trust the port. Attackers hide C2 in traffic that looks like ordinary web traffic; inspect where you can rather than assuming a common port is benign.

The cloud makes this both harder and easier

In cloud environments, egress is often wide open by default — a workload can reach the entire internet unless you deliberately constrain it with egress security groups, NAT policies or a firewall service. That default has enabled real cryptomining and data-theft incidents that a simple outbound allowlist would have strangled. The upside is that cloud gives you the primitives to define egress declaratively, per workload, as code — so the allowlist becomes a reviewable artifact rather than a pile of hand-edited rules. The tools are there; the default is against you.

You can only allowlist egress once you know what each workload legitimately talks to — which means inventorying your systems and their real dependencies first. The blind spot is outbound, and you can't control the traffic you haven't discovered.