Network hardening
Default-deny networking blocks everything and allows only named flows — including egress, the direction most teams forget. Combined with segmentation and killing plaintext protocols, it turns one compromised box from a launchpad into a dead end.
An attacker pops a single image-resize worker through a dependency CVE. It’s an internal box — no public ingress, nobody panics. Within ninety seconds it has connected outbound to 45.9.x.x:443, pulled a second-stage payload, scanned the 10.0.0.0/8 flat network, found an unauthenticated Redis on a neighboring host, and dumped session tokens. Every one of those steps crossed a network boundary that allowed it. The ingress firewall everyone obsessed over never fired once: the worker initiated all of it. This is what an un-hardened network costs — not the breach of one box, but the free movement after it.
By the end of this lesson you’ll know why default-deny has to cover egress, how segmentation contains the blast radius, and why killing plaintext protocols is non-negotiable.
Default-deny is the only firewall posture that scales
A firewall rule set is a policy about what may happen on the wire. There are exactly two ways to write it. Default-allow permits everything and enumerates what to block — you are listing the attacks you’ve thought of, and every attack you haven’t thought of gets through. Default-deny drops everything and enumerates what to allow — you are listing the flows your application actually needs, and everything else, known and unknown, is denied by the absence of a rule.
The asymmetry is the whole point. A default-allow list is a blocklist, and a blocklist is only ever as complete as your imagination on the day you wrote it. A default-deny list is an allowlist, and an allowlist fails closed: a new service, a new port, a forgotten debug endpoint, a freshly published CVE that opens an unexpected listener — none of them work until someone deliberately writes a rule. This is the same deny-by-default reflex that governs application authorization, applied one layer down at the network. CIS Benchmarks and NIST SP 800-123 both make the implicit-deny final rule the baseline for exactly this reason: it converts “did we remember to block this?” into “did we remember to allow this?”, and the second question is one a reviewer can actually answer by reading the rule set.
The reason teams still ship default-allow is operational, not architectural: deny-by-default breaks things loudly until every legitimate flow is enumerated, and that enumeration is real work. But that pain is the feature — it forces you to know your own traffic.
Egress is the half of the firewall everyone forgets
Walk into most networks and the ingress rules are tight and the egress rules are a single line: allow all outbound. That single line is what made the Hook scenario possible. Almost every modern attack chain depends on outbound connections the defender permitted: pulling a second-stage payload, beaconing to a command-and-control server, and exfiltrating the stolen data back out. An ingress-only firewall is a door with a deadbolt on the outside and the inside knob removed — it stops people walking in, and does nothing about someone already inside walking out with the silverware.
Egress filtering applies default-deny to the outbound direction: a workload may only initiate connections to the specific destinations its job requires. A payment worker that talks to one bank API and your database has no business opening a TLS connection to an arbitrary internet IP — so it can’t, and the moment it tries, the attempt is denied and logged, which is often your earliest signal of compromise. The single highest-value egress rule on a cloud host is blocking outbound access to the instance metadata endpoint (169.254.169.254) from anything that doesn’t need it: that one link-local address is what turns an SSRF or a popped container into stolen cloud credentials.
Segmentation decides the blast radius
A flat network — one big 10.0.0.0/8 where every host can reach every other host on every port — means the blast radius of any compromise is the entire estate. Segmentation breaks the network into zones (subnets, VLANs, security groups, Kubernetes NetworkPolicies, service-mesh authorization) and enforces default-deny between them. East-west traffic — server-to-server, the direction lateral movement travels — now has to cross a boundary that, by default, says no.
The win is concrete: put the database tier in its own segment that only the application tier may reach on port 5432, and a compromised front-end web box cannot touch the database directly even though both live in “the network.” Put each microservice in its own policy and a popped image-resizer cannot scan its neighbors. The classic worst case — one machine compromised, then unauthenticated internal services (a Redis, an Elasticsearch, an admin panel) reachable flat across the whole subnet — is precisely what segmentation removes. You are not preventing the first breach here; you are making sure the first breach is also the last box.
▸Why this works
Why isn’t “we have a perimeter firewall” enough? Because the perimeter is a single eggshell: hard on the outside, soft everywhere within. The moment one thing inside is compromised — a phished laptop, a vulnerable dependency, a leaked credential — a flat interior offers zero friction to lateral movement. Segmentation plus internal default-deny is what zero trust operationalizes: stop treating “inside the network” as a trust boundary, and authenticate and authorize every hop as if it came from the open internet. The perimeter still matters; it’s just no longer allowed to be the only control.
Killing plaintext protocols
Every plaintext protocol on your network is a credential leak and a tamper vector waiting for anyone who can see the wire — and on a shared or cloud network, “see the wire” is cheaper than teams assume. The hardening rule is blunt: no cleartext for anything that carries credentials, data, or control. Replace the unencrypted protocol with its authenticated, encrypted successor, and then disable the old one at the server — not just “prefer” the new one, because a protocol still listening is a protocol an attacker can downgrade you onto.
| Kill this | Port | Why it’s dangerous | Use instead |
|---|---|---|---|
| Telnet | 23 | Login + every keystroke in cleartext | SSH (22), key-based auth |
| FTP | 21 | Credentials + files in cleartext | SFTP / FTPS |
| HTTP (internal) | 80 | Tokens, cookies, data readable + tamperable | HTTPS / mTLS, HSTS |
| SNMP v1/v2c | 161 | Community string is a plaintext password | SNMPv3 (auth + privacy) |
| LDAP | 389 | Bind credentials in cleartext | LDAPS / StartTLS |
| TLS 1.0 / 1.1, SSLv3 | — | Known-broken ciphers, downgrade-able | TLS 1.2+ (prefer 1.3) |
“Internal HTTP is fine, it never leaves our network” is the dangerous half-truth: once you accept that an attacker can already be inside the network (the entire premise of segmentation), internal cleartext is exactly as exposed as external cleartext. Encrypt east-west traffic too — mutual TLS between services is the service-mesh answer — so that a foothold on one box doesn’t hand the attacker a tap on everyone else’s traffic.
A payment-processing service runs in a flat cloud VPC with allow-all egress. You can ship one change this sprint to most reduce the blast radius if that service is compromised. Pick the highest-leverage move.
Why is a default-deny (allowlist) firewall fundamentally safer than a default-allow (blocklist) one?
A service still has TLS 1.0 enabled 'for an old client' alongside TLS 1.3. Why is leaving the old version listening a real risk, not just legacy clutter?
Order these network-hardening moves from broadest blast-radius reduction to most local, as you'd phase them in:
- 1 Default-deny ingress AND egress as the firewall baseline (allow only named flows)
- 2 Segment the network into zones with default-deny between them (contain east-west)
- 3 Lock down the cloud metadata endpoint and per-service egress destinations
- 4 Disable plaintext protocols and weak TLS on each service's listeners
- 01Explain why egress filtering matters as much as ingress filtering, and give the single highest-value egress rule on a cloud host.
- 02How do segmentation and killing plaintext protocols together contain a single-box compromise, and why is 'internal HTTP is fine' wrong?
Network hardening is the discipline of deciding the blast radius of a compromise before it happens. The foundation is default-deny: a firewall that drops everything and allows only the named flows your application needs, so unknown and future attacks are denied by the absence of a rule rather than slipping past an incomplete blocklist. Crucially, default-deny has to cover egress, not just ingress — post-compromise movement (second-stage payloads, C2 beaconing, data exfiltration, stealing cloud credentials from 169.254.169.254) is all outbound, so a blanket “allow all outbound” rule is the gap most teams leave open. Segmentation enforces default-deny between zones so east-west lateral movement hits a boundary, turning one popped box into a dead end instead of a launchpad across a flat network. And every plaintext protocol — Telnet, FTP, internal HTTP, SNMPv1/2c, plain LDAP — plus weak TLS versions must be disabled at the server, not merely deprecated, because a protocol still listening can be downgraded onto. Now when you see a service with allow-all egress on a flat network, your first question is: when this box is popped, can it reach anything but the two destinations it actually needs?
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.