📘 Network Security

This page covers how networks are attacked and defended, at the level an application or platform engineer needs. For application-layer security (authentication, OWASP, injection) see Authentication and Security.

Table of Contents

1. Security Goals
2. Firewalls
3. Segmentation and Zero Trust
4. VPNs
5. Attacks by Layer
6. Man in the Middle
7. DDoS
8. SSRF and Internal Network Exposure
9. Monitoring and Detection
10. Hardening Checklist
11. Questions

1. Security Goals

Defense in depth: assume every single control will fail sometime, and layer them so one failure is not a breach.

2. Firewalls

Rule design:

• Default deny, then allow what is needed.
• Filter egress too: a compromised server that cannot call out cannot exfiltrate data or reach a command and control server easily.
• Rules are evaluated in order in ACLs; the first match wins.
• Reference groups or tags, not IPs, in cloud rules (a security group can allow traffic "from the app tier security group").

Linux example with nftables:

nft add table inet filter
nft add chain inet filter input '{ type filter hook input priority 0; policy drop; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iif lo accept
nft add rule inet filter input tcp dport { 22, 443 } accept

3. Segmentation and Zero Trust

Perimeter model: a hard shell (firewall) around a soft inside where everything trusts everything. One phished laptop or one vulnerable server gives the attacker the whole network (lateral movement).

Segmentation limits the blast radius:

Zero trust (Google's BeyondCorp, NIST SP 800-207): network location grants no trust.

• Every request is authenticated and authorized, based on user identity, device health, and context.
• Service-to-service traffic uses mTLS with workload identities (SPIFFE).
• Access is least privilege and short lived.
• Everything is logged.

Practical zero trust replaces "VPN into the office network" with an identity-aware proxy in front of each internal app (Cloudflare Access, Google IAP, Tailscale with ACLs).

4. VPNs

A VPN creates an encrypted tunnel so remote traffic behaves as if it were on a private network.

Consumer VPNs move trust from your ISP to the VPN provider; they do not make you anonymous.

5. Attacks by Layer

6. Man in the Middle

A MITM sits between two parties and can read or modify traffic.

Getting in the middle is often easy on a shared network. What stops the attack is authentication of the endpoint:

• TLS certificate validation (and never disabling it with verify=False or InsecureSkipVerify).
• SSH host key verification (the "authenticity of host can't be established" prompt exists for this).
• HSTS so the browser never tries plain HTTP.
• mTLS inside the network.

Corporate TLS inspection is a deliberate MITM: the company installs its own root CA on devices so a proxy can decrypt traffic. It breaks certificate pinning and mTLS, and is why some tools fail with "self-signed certificate in certificate chain" on work laptops.

7. DDoS

A distributed denial of service attack floods a target from many sources, often botnets of compromised IoT devices.

Amplification: the attacker sends small requests with the victim's IP as the (spoofed) source to open servers that reply with much larger responses. Amplification factors range from tens (DNS) to tens of thousands (memcached). Record attacks have passed 20 Tbps and billions of packets per second, mostly absorbed by large CDN and cloud networks.

Mitigation layers:

1. Absorb: anycast CDN or scrubbing service with more capacity than the attack (Cloudflare, AWS Shield, Akamai).
2. Filter: drop obviously bad traffic at the edge (unused ports, malformed packets, known reflector protocols).
3. Rate limit: per IP, per token, per route; challenge suspicious clients.
4. Protect the origin: only accept traffic from the CDN's IP ranges, hide the origin IP.
5. Design for it: autoscaling with limits, caching, cheap rejection paths, expensive endpoints behind auth.

8. SSRF and Internal Network Exposure

Server-side request forgery: the attacker makes your server fetch a URL they choose, reaching things only the server can reach.

Defenses: allowlist destinations, resolve DNS once and block private and link-local ranges (watch for DNS rebinding and redirects), disable unused URL schemes, send outbound fetches through an egress proxy, and enforce IMDSv2 (token required, hop limit 1) on AWS.

Other exposure to avoid:

• Databases, Redis, Elasticsearch, Docker API (2375), and Kubernetes kubelet ports reachable from the Internet; scanners find them within minutes.
• Management interfaces (SSH, RDP) open to 0.0.0.0/0.
• Debug endpoints (/actuator, /debug/pprof) exposed publicly.

9. Monitoring and Detection

10. Hardening Checklist

• Encrypt everything in transit, including internal traffic (TLS 1.2+ or mTLS).
• Default-deny ingress and restrict egress.
• Expose only 80 and 443 publicly, behind a CDN or WAF; nothing else.
• Admin access through identity-aware proxies or SSH with keys and MFA, never passwords.
• Private subnets for apps and data; no public IPs on databases.
• Segment by environment (prod, staging) and by tier.
• Enable DDoS protection and rate limiting on public endpoints.
• Enforce IMDSv2 and block metadata access from containers that do not need it.
• Rotate certificates automatically and alert on upcoming expiry.
• Turn on flow logs and DNS logs, and keep them long enough to investigate.
• Patch network devices and VPN appliances fast; they are prime targets for exploits.
• Run periodic external scans of your own address space.

11. Questions

Next: Troubleshooting and Tools.