Skip to main content

Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Module 7: Network Security

Security is paramount in modern networking. Every packet that crosses a network is a potential attack vector. This module introduces the core security concepts; Module 17 goes much deeper into firewalls, security groups, and zero trust architectures. Think of network security like building security. You have locks on doors (firewalls), security cameras (monitoring), ID badges (authentication), and guards who check visitors (inspection). No single measure is enough — security works in layers, and attackers only need to find one gap.

​
7.1 Firewalls

A Firewall monitors and controls incoming and outgoing network traffic based on predetermined security rules. Think of it as a security guard at a building entrance — checking IDs, verifying visitors against a guest list, and turning away anyone unauthorized.
  • Packet Filtering (Stateless): Inspects each packet’s headers (IP, Port) independently. Fast but cannot understand the context of a conversation. Like a guard who checks every person’s badge but does not remember who already entered. You must explicitly allow return traffic.
  • Stateful Inspection: Tracks connection state. When you initiate an outbound connection, the firewall remembers it and automatically allows the return traffic. Like a guard who notes “Person A left the building at 2 PM to get lunch, so let them back in when they return.” This is what modern firewalls and security groups use.
  • Application Layer (WAF — Web Application Firewall): Inspects the actual application payload (HTTP requests, SQL queries). Can detect and block attacks like SQL injection and cross-site scripting. Like a guard who not only checks your badge but also inspects the contents of your bag.

​
What a firewall actually sees at the packet level

When a packet arrives, a stateful firewall examines: 
Incoming Packet:
  Src IP: 203.0.113.50    -- "Who is knocking?"
  Dst IP: 10.0.1.10       -- "Who are they trying to reach?"
  Protocol: TCP            -- "What type of conversation?"
  Src Port: 54321          -- "Which conversation on the sender's side?"
  Dst Port: 443            -- "Which service are they requesting?"
  TCP Flags: SYN           -- "Is this a new conversation or existing?"

Firewall checks:
  1. Does a rule allow TCP to port 443 from this source? YES
  2. Create connection state entry: 203.0.113.50:54321 <-> 10.0.1.10:443
  3. Future packets matching this state are automatically allowed
Practical tip: The most common firewall misconfiguration is being too permissive. Default to “deny all, then allow specific traffic.” Every open port is an attack surface. If you do not need port 3306 (MySQL) exposed to the internet, do not open it — even if “it is easier for debugging.”

​
7.2 VPN (Virtual Private Network)

A VPN extends a private network across a public network. It creates an encrypted “tunnel” through the internet, so your traffic is protected even on untrusted networks like public Wi-Fi.
  • Tunneling: Encapsulates packets inside another protocol. Your original packet (with private IPs) is wrapped inside a new packet (with public IPs) and encrypted. The receiving end unwraps and decrypts it. It is like putting a sealed letter inside another envelope — postal workers (routers on the internet) can see the outer envelope but cannot read the letter inside.
  • Encryption: Protects data from eavesdropping. Without a VPN, anyone on the same coffee shop Wi-Fi could potentially see your traffic (if it is not already HTTPS-encrypted). A VPN encrypts everything, including DNS queries and the destination of your traffic.

​
What a VPN tunnel looks like at the packet level

Original packet (before VPN):
  Src IP: 192.168.1.10 (your device)
  Dst IP: 93.184.216.34 (website)
  Payload: GET /account HTTP/1.1 ...  (readable!)

After VPN encapsulation:
  Outer Src IP: 203.0.113.50 (your public IP)
  Outer Dst IP: 198.51.100.1 (VPN server)
  Payload: [encrypted blob -- original packet + headers unreadable]

At VPN server (decapsulated):
  Src IP: 198.51.100.1 (VPN server's IP -- your real IP hidden)
  Dst IP: 93.184.216.34
  Payload: GET /account HTTP/1.1 ...
Anyone snooping on the coffee shop Wi-Fi sees traffic going to the VPN server but cannot see the destination or content. The website sees traffic from the VPN server, not your real IP.
When do you actually need a VPN? For corporate access to internal resources (the primary use case), for site-to-site connectivity between offices, and when working on untrusted networks. Consumer VPN services for “privacy” are often oversold — they shift trust from your ISP to the VPN provider, who can still see your traffic. Module 15 covers VPN protocols (IPsec, WireGuard, OpenVPN) in detail.

​
7.3 TLS / SSL

Transport Layer Security (TLS) encrypts communication over a computer network. SSL is the predecessor to TLS and is now deprecated — when people say “SSL certificate,” they almost always mean a TLS certificate. TLS is what puts the “S” in HTTPS.
  • Handshake: Before any encrypted data flows, the client and server negotiate which encryption algorithms to use (cipher suite) and exchange keys. The TLS handshake adds roughly one round-trip time (RTT) of latency to the initial connection — which is why TLS 1.3 was designed to reduce this to a single round trip (and even zero round trips for repeat visitors with session resumption).
  • Certificates: The server presents a digital certificate that proves “I really am google.com.” Your browser verifies this certificate against a list of trusted Certificate Authorities (CAs). If the certificate is expired, self-signed, or issued for the wrong domain, your browser shows a warning. This is PKI (Public Key Infrastructure) — a chain of trust from CAs to individual certificates.

​
What happens during a TLS handshake (simplified)

1. Client → Server: "Hello, I support TLS 1.3 with these ciphers"
2. Server → Client: "Let's use TLS 1.3 with AES-256-GCM. Here's my certificate."
3. Client verifies: "Is this certificate signed by a trusted CA? Is it for this domain? Has it expired?"
4. Both sides: Exchange keys using Diffie-Hellman → derive shared secret
5. All subsequent data is encrypted with the shared secret
TLS does not mean the server is trustworthy — only that the connection is encrypted and the server is who it claims to be. A phishing site at secure-bank-login.evil.com can have a perfectly valid TLS certificate. The padlock icon means encryption, not trust.

​
7.4 Common Attacks

  • DDoS (Distributed Denial of Service): Overwhelming a target with traffic from thousands or millions of compromised machines (botnets). The target’s servers, bandwidth, or firewall capacity are exhausted, making the service unavailable to legitimate users. In 2016, the Dyn DNS DDoS attack (using IoT devices in the Mirai botnet) took down Twitter, GitHub, Netflix, and Reddit simultaneously. Defense: rate limiting, CDN/DDoS protection services (Cloudflare, AWS Shield), and traffic scrubbing.
  • MITM (Man-in-the-Middle): An attacker positions themselves between two communicating parties, intercepting and potentially modifying traffic. On an unprotected Wi-Fi network, an attacker could intercept unencrypted HTTP traffic and steal login credentials. TLS/HTTPS prevents this — even if traffic is intercepted, it is encrypted and the attacker cannot read or modify it without breaking the encryption. This is the single biggest reason why HTTPS everywhere matters.
  • ARP Spoofing: An attacker on the local network sends fake ARP (Address Resolution Protocol) messages, associating their MAC address with the default gateway’s IP. All traffic from victims now routes through the attacker. Defense: static ARP entries, dynamic ARP inspection on managed switches.
  • DNS Spoofing / Cache Poisoning: Feeding a DNS resolver fake records so that bank.com resolves to the attacker’s IP instead of the real bank’s server. Defense: DNSSEC (cryptographic signatures on DNS records), DNS over HTTPS (DoH).
  • Phishing: Deceptive emails or websites designed to steal credentials. Not technically a network attack (it is social engineering), but it is the most common vector for network breaches. Defense: user education, MFA (multi-factor authentication), email filtering.
Troubleshooting a suspected attack: If you suspect your network is under attack, start with these steps: (1) Check firewall logs for unusual inbound traffic patterns — a DDoS will show thousands of connections from diverse IPs. (2) Run netstat -an or ss -tuln to see active connections — unexpected ESTABLISHED connections to unknown IPs are a red flag. (3) Check DNS resolution with dig to verify you are reaching the real servers, not spoofed ones. (4) Review recent authentication logs for failed login spikes (brute force). The goal is to identify the attack vector before reacting — blocking the wrong thing can cause more damage than the attack itself.
The uncomfortable truth: Most real-world breaches start with phishing or compromised credentials, not sophisticated network attacks. The best firewall in the world cannot protect you if an employee clicks a malicious link and enters their password. This is why Zero Trust architecture (Module 17) assumes the network is already compromised and verifies every request.

​
Next Module

Module 8: Advanced Networking

SDN and the Cloud.

​
Interview Deep-Dive

Strong Answer:
  • TLS 1.3 completes the handshake in a single round trip (1-RTT) compared to TLS 1.2’s two round trips (2-RTT). The client sends a ClientHello with supported cipher suites and its key share (Diffie-Hellman public value) in the very first message. The server responds with ServerHello, its key share, and the certificate — all in one response. Both sides can derive the session key immediately.
  • For repeat connections, TLS 1.3 supports 0-RTT resumption. The client stores a pre-shared key from a previous session and includes encrypted early data in the first ClientHello. The trade-off is that 0-RTT data is vulnerable to replay attacks, so it should only be used for idempotent requests (GET, not POST).
  • TLS 1.3 removed all weak cipher suites. No more RSA key exchange (lacks forward secrecy), no more CBC mode ciphers (padding oracle vulnerabilities), no more MD5 or SHA-1. Only AEAD ciphers (AES-GCM, ChaCha20-Poly1305) and ephemeral Diffie-Hellman key exchange. Every connection has forward secrecy — even if the server’s private key is compromised in the future, past sessions cannot be decrypted.
  • The security guarantees: confidentiality (data is encrypted), integrity (data cannot be tampered with), authentication (server identity verified via certificate chain), and forward secrecy (unique ephemeral keys per session).
Follow-up: What does ‘forward secrecy’ mean in practice, and why is it critical now that some governments record encrypted traffic?Forward secrecy means each TLS session generates unique encryption keys using ephemeral Diffie-Hellman key exchange. The server’s long-term private key is used only for authentication (signing), not for key derivation. If an attacker records encrypted traffic today and obtains the server’s private key years later, they still cannot decrypt the recorded sessions because the ephemeral keys were never stored and cannot be derived from the long-term key. Without forward secrecy, the same private key decrypts every past session. TLS 1.3 mandates forward secrecy by removing RSA key exchange entirely, making the “record now, decrypt later” strategy infeasible for any TLS 1.3 traffic.
Strong Answer:
  • A regular overload is legitimate traffic exceeding capacity — a viral campaign, Black Friday spike, or a bad database query slowing everything down. A DDoS is malicious traffic from thousands of compromised machines designed to exhaust your resources: bandwidth, CPU, memory, or connection table capacity.
  • Detection involves looking for anomalies: sudden traffic spikes from unusual geographic distributions, thousands of connections from never-before-seen IPs, high SYN rates without corresponding established connections, and traffic patterns that do not match normal user behavior (no cookies, no JavaScript execution, identical User-Agent strings). If traffic jumps 100x in 60 seconds and 95% is from new IPs, that is almost certainly an attack.
  • Mitigation works in layers. At the edge, CDN providers like Cloudflare and AWS Shield absorb volumetric attacks across their global network. At the application layer, WAFs detect and block HTTP floods and slowloris attacks via request pattern analysis and rate limiting. At the infrastructure layer, auto-scaling absorbs some traffic, and AWS Shield Advanced provides cost protection against scaling bills from attack traffic.
  • The architecture decision that matters most is hiding your origin IP behind a CDN proxy. If attackers know your origin IP, they bypass the CDN and attack directly.
Follow-up: What is a SYN flood specifically, and how do SYN cookies defend against it?A SYN flood sends millions of SYN packets with spoofed source IPs. The server sends SYN-ACK and allocates memory for each half-open connection, waiting for a final ACK that never comes. The connection table fills up and the server cannot accept legitimate connections. SYN cookies eliminate the need to store state for half-open connections. Instead of saving connection parameters, the server encodes them (MSS, timestamp, source IP hash) into the initial sequence number of the SYN-ACK using a cryptographic function. If a legitimate final ACK arrives, the server reconstructs the connection state from the acknowledged sequence number. If no ACK comes, no resources were consumed. Linux enables SYN cookies automatically when the SYN backlog is full via net.ipv4.tcp_syncookies.
Strong Answer:
  • Defense in depth layers multiple independent security controls so that failure of any single control does not compromise the system. It assumes every control can be bypassed — the question is how many an attacker must defeat.
  • A concrete example for a web application on AWS, outermost to innermost: (1) Route 53 with DNSSEC to prevent DNS spoofing. (2) CloudFront CDN with AWS WAF — absorbs DDoS, blocks SQL injection and XSS, hides origin IP. (3) AWS Shield Advanced for volumetric DDoS protection. (4) Application Load Balancer in a public subnet performing SSL termination. (5) NACLs on subnets denying traffic from known bad CIDR ranges. (6) Security groups on instances — allowing only the ALB’s security group on port 8080, SSH only from the bastion. (7) iptables on the host as a final backstop. (8) Application-level input validation, parameterized queries, authentication, and rate limiting.
  • Each layer protects against different attack vectors. WAF stops application-layer attacks. NACLs stop network-level attacks. Security groups stop lateral movement. Even if an attacker bypasses the WAF via a zero-day, they still face security groups, NACLs, and application defenses.
Follow-up: What is the difference between the ‘castle and moat’ model and Zero Trust?The castle and moat model treats everything inside the network perimeter as trusted. Once you pass the firewall, you have free reign. This breaks with remote work, cloud deployments, and BYOD — the perimeter is everywhere. Zero Trust assumes the network is already compromised. Every request is authenticated, authorized, and encrypted regardless of source. Access is per-request with minimum privileges. Google’s BeyondCorp is the canonical example — employees access internal apps through an identity-aware proxy whether in the office or a coffee shop. There is no VPN, no “inside the network” privilege. The shift is from securing the network perimeter to securing individual identities and workloads.