The Perimeter Model and Its Limits

Classic network security is a perimeter: defend the edge (firewall) and trust everything inside. The model worked when the network was a room of servers; it’s dangerous now because the edge is porous (cloud, mobile, SaaS, APIs) and compromise is assumed to be a matter of when, not if — a single lateral move from a VPN or an insider means the trusted interior is an attack surface. This topic covers the layers you still deploy and the zero-trust mindset that replaces the perimeter assumption.

Firewalls: Stateful vs Stateless

A firewall filters traffic by rules. The two implementations differ fundamentally:

• Stateless — inspects each packet in isolation: source IP, dest IP, port, protocol. It can’t tell “this is the reply to my outbound request” from “this is an unsolicited inbound packet.” Rule sets get ugly (open return ranges) and permissive.
• Stateful — tracks the connection state: it remembers that the server initiated outbound traffic and automatically allows the return traffic while blocking unsolicited inbound. This is the default for modern firewalls and cloud security groups — you express “outbound to the internet is allowed,” and responses come back without opening inbound holes.

The practical consequence: with a stateful firewall you only ever write outbound rules; with stateless you must think in both directions and manage the return path explicitly.

Cloud Security Groups vs Network ACLs

The cloud splits the firewall into two complementary layers (terminology is consistent across AWS/GCP/Azure):

• Security groups are the day-to-day tool: “allow 443 from 0.0.0.0/0 to the LB,” “allow 3306 from only the app tier’s security group.” Default is deny; you open the minimum.
• Network ACLs are the coarse subnet-level backstop (stateless, so they need both inbound and outbound return rules) — a second layer behind the security-group logic.

The rule that prevents most cloud compromises: never expose a database to the internet — a DB security group that allows 0.0.0.0/0 on 3306/5432 is the #1 cloud misconfiguration, and it’s exactly what a scanner finds in minutes.

Web Application Firewalls (WAF)

A firewall at L3/L4 filters packets; it can’t understand HTTP. A WAF sits in front of web applications and inspects requests — filtering for the application-layer attacks in the OWASP Top 10:

• SQL injection (' OR 1=1 --)
• XSS payloads (<script>...)
• Path traversal (../../etc/passwd)
• Bad bots / credential stuffing

WAFs (AWS WAF, Cloudflare, ModSecurity) use managed rule sets tuned for the OWASP Top 10 and can be updated without touching application code — valuable as a defense in depth layer. But a WAF is not a substitute for fixing the vulnerability: it’s a shield, not a vaccine. The app must still validate input and parameterize queries (see AppSec); the WAF raises the attacker’s cost and buys remediation time.

DDoS Mitigation

A DDoS (Distributed Denial of Service) overwhelms a service with traffic. The mitigation ladder, in order of escalation:

1. Rate limiting — per-IP/per-client caps absorb the tail of flash traffic and simple floods.
2. Anycast / CDN absorption — a CDN (you met it in Caching) absorbs volumetric attacks at the edge before they reach origin; the origin’s real IP is hidden behind it.
3. Scrubbing / DDoS protection services — cloud providers (Cloudflare, AWS Shield, Azure DDoS Protection) route traffic through scrubbers that filter attack traffic algorithmically and forward only clean traffic.
4. Auto-scaling + edge caching — absorb by raw capacity: cacheable content served from edge, compute that scales.

The honest engineering truth: you cannot out-crunch a determined volumetric attack with a single origin server. DDoS is won at the network edge (anycast, scrubbing) — which is why “behind a CDN with rate limiting” is the default production posture, not an option.

Zero Trust: Assume Breach

Zero Trust is the security model that abandons the trusted-interior assumption:

Never trust, always verify. Every request — from any client, at any location — must be authenticated, authorized, and encrypted, as if it came from the open internet.

Concrete practices:

• ZTNA (Zero Trust Network Access) — instead of a wide VPN granting network access, users/apps get per-application, per-session access (BeyondCorp, Cloudflare Access, Tailscale-based designs): authenticated, device-checked, least-privilege.
• Micro-segmentation — services authenticate to each other (mTLS) rather than trusting “same network.” Service meshes (Istio, Linkerd) implement this: every pod-to-pod call is mutually authenticated with certificates.
• Identity is the new perimeter — the boundary moves from the network edge to the identity layer: strong MFA, conditional access, and continuous verification.

The zero-trust shift isn’t theoretical — it’s how Google runs production (BeyondCorp), and it’s the direction every cloud vendor’s security features now push.

Defense in Depth

Network security is never one control; it’s layers that each raise the attacker’s cost:

1. Edge: DDoS protection, WAF, rate limiting.
2. Network: security groups, network ACLs, private subnets, no exposed DBs.
3. Transport: TLS everywhere (HTTPS, mTLS for service-to-service).
4. Identity: MFA, least privilege, ZTNA.
5. App: input validation, secure coding (the AppSec topic).

A failure at any single layer is survivable because the next layer catches it — that’s the entire point.

Practice Trajectory

1. Design the security groups for a 3-tier app (LB → app → DB) and write the inbound rules for each tier — keeping the DB private.
2. Contrast stateful vs stateless rules for the same policy: what return-path rule does the stateless NACL need that the stateful SG doesn’t?
3. Throw a parameterized-vs-injected request at a WAF rule set and observe the block.
4. Sketch a DDoS response for an e-commerce site: what absorbs at the edge, what rate-limits, what autoscales.
5. Redesign a “VPN + trusted network” architecture to zero trust: who authenticates to whom, and how (mTLS, ZTNA)?

When It’s the Right Tool