Python · SQL · Web Dev · Java · AI/ML tracks launching soon — your one platform for all of IT
Cybersecurity — Module 02

How the Internet Works — A Security Engineer's View

TCP/IP, DNS, HTTP, TLS — every layer's attack surfaces explained from first principles. What happens in the network when you type a URL.

28 min May 2026

// Part 01

Why Every Security Engineer Must Understand the Network

Security tools — firewalls, IDS systems, packet capture, network monitoring — all operate at the network layer. An attacker who understands TCP/IP can craft packets that evade detection. A defender who does not understand TCP/IP cannot interpret what those tools are telling them. Network literacy is not optional background knowledge for a security engineer. It is the foundation everything else is built on.

This module answers one question from first principles: what happens when you type https://bank.example.com into a browser? Every step in that journey — DNS resolution, TCP connection, TLS handshake, HTTP request, HTTP response — is an attack surface. By the end, you will know exactly where attackers intercept, redirect, forge, and eavesdrop on network traffic.

The internet is not a single network. It is a collection of autonomous systems — networks owned by ISPs, universities, governments, and companies — that agree to route packets between each other using a shared set of protocols. Those protocols were designed in the 1970s and 1980s with trust, not security, as the primary design goal. Security was retrofitted on top. This is why so many fundamental attacks still work.

// Part 02

The TCP/IP Model — Every Layer Is an Attack Surface

The TCP/IP model describes how data moves from one machine to another by breaking the problem into layers. Each layer adds its own header information, passes the data to the layer below it, and the receiving end strips each layer in reverse. Understanding which layer each attack targets makes security architecture comprehensible.

LayerWhat It DoesKey ProtocolsAttack Examples
ApplicationThe data the user sees — web pages, emails, files. This is where browsers, email clients, and APIs live.HTTP, HTTPS, DNS, SMTP, FTP, SSHSQL injection, XSS, phishing, DNS poisoning, credential theft
TransportBreaks application data into segments and ensures reliable delivery (TCP) or fast fire-and-forget delivery (UDP).TCP, UDPSYN flood, port scanning, session hijacking, TCP reset attacks
InternetRoutes packets between networks using IP addresses. Does not guarantee delivery — best effort.IP, ICMPIP spoofing, ICMP redirect attacks, BGP hijacking, fragmentation attacks
Network AccessMoves data between devices on the same physical network using MAC addresses. Also called the Link layer.Ethernet, ARP, Wi-Fi (802.11)ARP poisoning, MAC flooding, rogue Wi-Fi access points, VLAN hopping

The key security insight: each layer trusts the layer above and below it. The Transport layer does not verify whether the IP address it received from the Internet layer is the legitimate origin. The Application layer does not verify that the TCP connection it received is not being proxied by an attacker. This trust model is where most network attacks live.

🎯 Pro Tip

When analysing a network attack, always identify which layer it operates at first. ARP poisoning is a Layer 2 (Network Access) attack — a firewall operating at Layer 3 (Internet) will not stop it because the firewall never sees ARP traffic. Understanding layers prevents you from applying the wrong defence to the right problem.

// Part 03

IP Addresses and Routing — What Actually Moves a Packet

IP Addresses

Every device on the internet has an IP address — a number that identifies its location on the network. IPv4 uses 32-bit addresses written in dotted-decimal notation: 192.168.1.1. IPv6 uses 128-bit addresses: 2001:0db8:85a3::8a2e:0370:7334. The internet ran out of IPv4 addresses in 2011, which is why Network Address Translation (NAT) is ubiquitous — multiple devices share one public IP behind a router.

IP spoofing — setting a false source IP on a packet — is trivially easy. The Internet Protocol does not authenticate source addresses. A packet claiming to come from 1.2.3.4 may actually come from 99.99.99.99. This is the foundation of many attacks: reflection attacks that use spoofed source IPs to direct responses at a victim, and it is why you cannot trust an IP address as proof of identity.

Routing — How Packets Find Their Destination

Routers are the post offices of the internet. Each router maintains a routing table — a list of network prefixes and which direction to send packets matching each prefix. Packets hop from router to router, each making a local forwarding decision, until they reach the destination. The traceroute (or tracert on Windows) command shows every hop a packet takes.

$ traceroute google.com
traceroute to google.com (142.250.80.46), 30 hops max
 1  192.168.1.1 (your home router)          1.2 ms
 2  10.10.0.1 (your ISP's first router)     5.8 ms
 3  72.14.232.1 (Google's network edge)    18.4 ms
 4  142.250.80.46 (google.com)             19.1 ms

The Border Gateway Protocol (BGP) is the routing protocol that determines how these inter-network routes are chosen. BGP hijacking — announcing false routes to attract traffic meant for another network — has been used to redirect internet traffic, intercept communications, and conduct surveillance. A BGP error in 2010 briefly redirected 15% of internet traffic through China Telecom. BGP has no authentication built in; this is a known design flaw with no universal fix deployed.

Private vs Public Addresses

Three IP ranges are reserved for private networks: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These addresses are not routed on the public internet — they are used inside corporate networks, data centres, and home networks. Network Address Translation (NAT) maps private addresses to a public IP at the network boundary. This matters for security: when a scanner finds 192.168.x.x addresses in a web response or DNS record, it has learned about internal network structure — information that should never be exposed.

// Part 04

TCP — Reliable Delivery and Its Attack Surface

The Three-Way Handshake

TCP (Transmission Control Protocol) provides reliable, ordered delivery. Before any data is exchanged, TCP establishes a connection using a three-way handshake:

Client → Server: SYN    (I want to connect, my sequence number starts at X)
Server → Client: SYN-ACK (Acknowledged. My sequence number starts at Y)
Client → Server: ACK    (Acknowledged. Connection established.)

[DATA TRANSFER BEGINS]

Either party → FIN → FIN-ACK → ACK (connection teardown)

Every web request, SSH session, and email starts with this handshake. The handshake creates state on the server — the server must remember every half-open connection (SYN received, SYN-ACK sent, ACK not yet received).

SYN Flood — Exhausting Server State

A SYN flood attack exploits the three-way handshake by sending massive numbers of SYN packets with spoofed source IPs. The server sends SYN-ACK responses to addresses that never complete the handshake, maintaining state for each half-open connection. When the connection table fills up, the server cannot accept legitimate connections. This is a Denial of Service attack at the Transport layer.

SYN cookies are the standard mitigation — the server encodes connection state into the sequence number rather than storing it in memory, so spoofed SYNs do not exhaust resources. Most modern operating systems enable SYN cookies automatically.

Port Scanning — Mapping the Attack Surface

TCP ports range from 0 to 65535. Services listen on specific ports: HTTP on 80, HTTPS on 443, SSH on 22, FTP on 21. Port scanning sends connection attempts to every port to discover which services are running. nmap is the standard tool:

$ nmap -sV -p 1-65535 192.168.1.1

PORT     STATE  SERVICE    VERSION
22/tcp   open   ssh        OpenSSH 8.9
80/tcp   open   http       nginx 1.22.1
443/tcp  open   https      nginx 1.22.1
3306/tcp open   mysql      MySQL 8.0.32    ← database exposed to network
6379/tcp open   redis      Redis 7.0        ← unauthenticated by default

Every open port is a potential entry point. A Redis instance exposed on port 6379 with default (no authentication) configuration has been used to compromise systems by overwriting SSH authorized_keys files. The attack is trivial once the port scan reveals the exposure.

Session Hijacking

TCP connections are identified by source IP, source port, destination IP, and destination port, plus sequence numbers. If an attacker can predict or observe the sequence numbers and has a position on the network path, they can inject packets into an existing TCP session — session hijacking. Before HTTPS was ubiquitous, this was used to steal authenticated web sessions over public Wi-Fi.

// Part 05

DNS — How Names Become Addresses and How Attackers Abuse It

The Domain Name System (DNS) translates human-readable domain names (google.com) into IP addresses (142.250.80.46). It is the phone book of the internet, and it is involved in almost every internet communication.

How DNS Resolution Works

You type: https://bank.example.com

Step 1: Check local cache — has your computer looked this up recently?
Step 2: Ask your configured DNS resolver (usually your ISP or 8.8.8.8)
Step 3: Resolver asks a Root DNS server: "Who handles .com?"
Step 4: Root server: "Ask the .com TLD servers"
Step 5: Resolver asks .com TLD: "Who handles example.com?"
Step 6: TLD server: "Ask ns1.example.com"
Step 7: Resolver asks ns1.example.com: "What is bank.example.com?"
Step 8: ns1.example.com: "It is 93.184.216.34"
Step 9: Resolver caches the answer for the TTL duration, returns to you

Total time: 10-100ms on first lookup, <1ms from cache

DNS Record Types

DNS stores more than IP addresses. The common record types each serve a different purpose:

A
Maps a hostname to an IPv4 address. The most common record.
⚠ DNS hijacking — change this record and all traffic goes to attacker
AAAA
Maps a hostname to an IPv6 address.
⚠ Same as A record — IPv6 DNS hijacking is often overlooked in defences
CNAME
Canonical name — an alias. example.com CNAME points to cdn.provider.com.
⚠ Subdomain takeover — dangling CNAME to deprovisioned services
MX
Mail exchange — which servers receive email for this domain.
⚠ MX record manipulation redirects email, enabling credential interception
TXT
Arbitrary text — used for SPF, DKIM, domain verification.
⚠ Missing SPF/DKIM records enable email spoofing
NS
Nameserver — which servers are authoritative for this domain.
⚠ NS hijacking gives full control over all DNS records for the domain
PTR
Reverse lookup — IP address to hostname mapping.
⚠ Missing PTR records often indicate shadow IT or unknown infrastructure

DNS Attack Types

DNS Cache Poisoning: A resolver caches DNS responses for the TTL (time-to-live) duration. If an attacker can inject a forged DNS response into the resolver's cache — either by predicting the transaction ID or exploiting an unpatched resolver — all users of that resolver will receive the false IP address until the TTL expires. The Kaminsky attack (2008) demonstrated this at scale against every major DNS resolver. DNSSEC (DNS Security Extensions) cryptographically signs DNS records to prevent this, but adoption remains incomplete.

DNS Hijacking: Rather than poisoning a cache, the attacker modifies the authoritative DNS record itself. This requires compromising the domain registrar account or the authoritative DNS server. In 2019, a wave of DNS hijacking attacks targeted government and corporate domains by compromising registrar accounts with weak credentials, redirecting traffic to attacker-controlled infrastructure where valid TLS certificates were obtained via ACME/Let's Encrypt.

Subdomain Takeover: An organisation uses a CNAME record pointing api.example.com to a third-party service (myapp.service.io). The organisation stops using the service but forgets to remove the CNAME record. The subdomain on the third-party service is now unregistered — anyone can claim it. An attacker registers the same subdomain on the provider and now controls api.example.com. This enables cookie theft if the main domain shares cookies with subdomains, phishing, and content injection.

DNS over HTTPS (DoH) and DNS over TLS (DoT): Traditional DNS is sent in plaintext — anyone between you and your resolver can see every domain you visit. DoH and DoT encrypt DNS queries. This protects user privacy but also means network defenders lose visibility into DNS-based threat intelligence (blocking malicious domains at the DNS layer). This is the privacy vs security trade-off inherent in DNS encryption.

🎯 Pro Tip

DNS is involved in almost every cyberattack. Malware calls home via DNS. C2 servers use domain generation algorithms that register new domains daily. Data exfiltration encodes stolen data in DNS query subdomains. Every security platform — SIEM, threat intelligence, firewalls — does DNS-based detection. Understanding DNS is not optional networking knowledge; it is a core security skill.

// Part 06

HTTP — The Protocol That Powers the Web (and Leaks Everything)

HTTP (Hypertext Transfer Protocol) is the application-layer protocol that web browsers use to request pages and APIs use to exchange data. It is a text-based, stateless request-response protocol. Stateless means each request is independent — the server does not remember the previous request. Cookies exist specifically to add state on top of this stateless protocol.

Anatomy of an HTTP Request

GET /account/dashboard HTTP/1.1
Host: bank.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: session_id=abc123def456; user_pref=dark_mode
Referer: https://bank.example.com/login
Connection: keep-alive

Security-relevant information visible in this single request: the exact browser and operating system (User-Agent), the previous page visited (Referer), the session identifier (Cookie), and the requested resource path. In HTTP (not HTTPS), this is all visible to anyone on the network path.

HTTP Methods and Their Security Implications

GET
Retrieve a resource. Should have no side effects — no state changes on the server. Parameters in the URL are logged by default in web server logs, proxies, and browser history.
⚠ Sensitive data in URL parameters (tokens, search terms) leaked to logs
POST
Submit data to the server. Body is not logged by default. Used for login forms, API calls, file uploads.
⚠ CSRF attacks submit POST requests from attacker-controlled pages
PUT / PATCH
Update a resource. Should be idempotent (same result if called multiple times). Often used in REST APIs.
⚠ Mass assignment — submitting extra fields that update unintended properties
DELETE
Delete a resource. Requires proper authorisation — without it, any authenticated user can delete any resource.
⚠ Missing authorisation checks — DELETE /api/posts/123 deletes another user's post
OPTIONS
Query which methods are supported. Used in CORS preflight requests.
⚠ Overly permissive CORS headers enable cross-origin data theft

HTTP Response Headers — Your Security Configuration

HTTP response headers sent by the server tell the browser how to behave. Security-relevant headers prevent common web attacks:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Strict-Transport-Security: max-age=31536000; includeSubDomains  ← force HTTPS
Content-Security-Policy: default-src 'self'; script-src 'self'  ← prevent XSS
X-Frame-Options: DENY                                            ← prevent clickjacking
X-Content-Type-Options: nosniff                                  ← prevent MIME sniffing
Referrer-Policy: strict-origin-when-cross-origin                 ← control Referer header
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict    ← protect cookies

A server missing Strict-Transport-Security allows downgrade attacks — an attacker who intercepts the first HTTP request can prevent the HTTPS upgrade. Missing Content-Security-Policy means any injected script runs with the page's full permissions. Missing HttpOnly on cookies means JavaScript can steal them. These headers are a five-minute configuration that prevents entire classes of attack.

// Part 07

TLS — What HTTPS Actually Does and What It Does Not

TLS (Transport Layer Security) is the protocol that encrypts HTTP traffic to create HTTPS. When you see the padlock icon in a browser, TLS is active. Understanding what TLS actually provides — and what it does not — is critical because a surprising number of attacks work against HTTPS targets.

The TLS Handshake — Step by Step

1. Client Hello
   Client → Server
   "I support TLS 1.2 and 1.3. Here are the cipher suites I support.
   My random value: [32 random bytes]"

2. Server Hello + Certificate
   Server → Client
   "We will use TLS 1.3 with AES-256-GCM-SHA384.
   My random value: [32 random bytes]
   Here is my certificate (signed by DigiCert, proves I am bank.example.com)"

3. Client Verifies Certificate
   Client checks:
   - Is the certificate signed by a trusted Certificate Authority?
   - Does the domain on the cert match the domain I requested?
   - Is the certificate expired?
   - Has it been revoked? (OCSP check)

4. Key Exchange (Elliptic Curve Diffie-Hellman)
   Client and server exchange key material.
   Each derives the same session keys independently.
   A passive eavesdropper cannot derive the keys even if they captured all traffic.
   (This is Perfect Forward Secrecy — keys are ephemeral, not reused)

5. Client Finished / Server Finished
   Both sides confirm the handshake succeeded.
   All subsequent traffic is encrypted with the derived session keys.

What TLS Protects

TLS provides three security properties when functioning correctly:

Confidentiality
The content of requests and responses is encrypted. An attacker who intercepts network traffic sees only encrypted bytes, not the HTML, JSON, passwords, or cookies being transmitted.
Integrity
TLS uses message authentication codes (MACs) to detect tampering. If an attacker modifies a single byte in transit, the receiver detects the mismatch and drops the connection.
Authentication
The certificate proves the server is who it claims to be — that this is actually bank.example.com and not an impostor. The certificate is signed by a Certificate Authority that your browser trusts.

What TLS Does NOT Protect

⚠️ Important
TLS encrypts data in transit. It does not protect data at rest, once it reaches the server. A server that stores passwords in plaintext, has a SQL injection vulnerability, or is compromised by an attacker still loses data — despite HTTPS. The padlock means "the network path is encrypted." It does not mean "this website is secure."

Additionally, TLS does not protect against:

• Malicious servers with valid certificates: Let's Encrypt will issue a free certificate to any domain — including phishing sites. A perfect HTTPS padlock on bank-secure-login.com means only that the connection to the fake site is encrypted, not that the site is legitimate.

• TLS interception (SSL inspection): Corporate networks and security appliances often perform "man-in-the-middle" TLS inspection — the appliance terminates the TLS connection, inspects the plaintext, then re-encrypts to the destination. From the browser's perspective, TLS looks valid because the corporate CA is trusted. This is legal on corporate equipment but breaks the privacy guarantee for employees.

• Client-side attacks: Malware on the endpoint can read data after decryption, before it reaches the network. The network is encrypted; the browser's memory is not.

Certificate Transparency

Every TLS certificate issued by a public CA must be logged in a public Certificate Transparency (CT) log. This means you can see every certificate ever issued for any domain — including certificates issued for subdomains you did not know existed. Tools like crt.sh and censys.io query CT logs and are standard reconnaissance tools for both attackers discovering attack surface and defenders auditing their certificate inventory.

// Part 08

Putting It Together — The Full Journey of an HTTPS Request

Here is the complete sequence of events when a user types https://bank.example.com/login and presses Enter — with every attack vector annotated:

1
DNS Resolution
The browser checks its local DNS cache, then queries the configured DNS resolver for the IP address of bank.example.com.
⚠ Attack: DNS cache poisoning, DNS hijacking, or DNS-over-HTTP interception returns a malicious IP
2
TCP Connection
The browser initiates a three-way handshake with the server at the resolved IP on port 443.
⚠ Attack: TCP reset injection terminates the connection; SYN flood blocks access entirely
3
TLS Handshake
The browser and server negotiate cipher suites, exchange certificates, and derive session keys.
⚠ Attack: MITM with rogue certificate (requires CA compromise or user accepting invalid cert); TLS downgrade to weaker protocol version
4
HTTP Request
The browser sends the encrypted GET /login HTTP/1.1 request with headers, cookies, and any query parameters.
⚠ Attack: CSRF (forged cross-origin request); cookie theft if HttpOnly not set; Referer header leaks sensitive URL parameters
5
Server Processing
The web server receives the decrypted request, processes it (database queries, business logic), and generates a response.
⚠ Attack: SQL injection, command injection, authentication bypass, server-side request forgery (SSRF) — all happen here
6
HTTP Response
The server sends back the encrypted response — HTML, cookies, security headers.
⚠ Attack: Missing security headers enable XSS, clickjacking; insecure cookie flags enable theft; sensitive data in response body
7
Browser Rendering
The browser decrypts, parses HTML, executes JavaScript, loads sub-resources (CSS, images, fonts, scripts).
⚠ Attack: XSS in page content executes attacker JavaScript; malicious CDN script; clickjacking via iframe overlay

// Part 09

What This Looks Like at Work — Reading a Packet Capture

Scenario — Investigating suspicious outbound traffic
09:15
SIEM alert: unusual DNS activity from workstation WKSTN-0042
The alert shows WKSTN-0042 making 800+ DNS queries per hour to domains with high entropy names — a10b3c.xyz, 7f2k9p.net, q8r2m5.io. Normal workstations make 10-50 DNS queries per hour, mostly to known CDN domains. High entropy, newly registered domains are a strong indicator of Domain Generation Algorithm (DGA) malware.
09:22
Capturing traffic with Wireshark
The analyst captures traffic from WKSTN-0042 using the corporate network tap. Filtering for DNS (port 53) confirms: the workstation is making DNS queries for seemingly random domains. The queries include subdomains like: dGhpcyBpcyBhIHRlc3Q.a10b3c.xyz — that subdomain is base64 encoded. The malware is exfiltrating data via DNS queries.
09:35
Decoding the DNS exfiltration
The analyst decodes the subdomain: echo "dGhpcyBpcyBhIHRlc3Q" | base64 --decode → "this is a test". The malware encodes stolen data as DNS subdomains. Each query sends a chunk of data to an attacker-controlled DNS server. DNS exfiltration is effective against organisations that do not inspect DNS content, only filter known-malicious domains.
09:50
Correlating with HTTP traffic
Looking at HTTPS traffic from WKSTN-0042: there is no TLS decryption on this network segment, so the content is encrypted. But the SNI (Server Name Indication) field in the TLS handshake — which is sent in plaintext before encryption — reveals the destination domain. SNI shows connections to the same suspicious domains. The C2 communication uses both DNS and HTTPS for redundancy.
10:15
Containment and root cause
WKSTN-0042 is isolated from the network. Memory forensics reveals the malware process. The infection vector: a phishing email with a malicious Excel macro three days prior. The malware has been exfiltrating data for 72 hours. Network-level detection caught it only when the DNS query volume exceeded the threshold. Endpoint detection missed it because the macro ran inside a trusted Office process.
🎯 Pro Tip
DNS exfiltration is harder to detect than HTTP exfiltration because DNS is a necessary protocol that cannot be blocked. The defences are: DNS query rate monitoring (unusual volume), entropy analysis of queried domain names (random-looking names are suspicious), and DNS sinkholing — returning false responses for known DGA domains to break C2 communication while preserving the ability to track infected machines.

// Part 10

Interview Prep — 5 Questions With Complete Answers

Q: Explain what happens when you type https://google.com into a browser and hit Enter.
This is one of the most famous technical interview questions across all engineering disciplines. For a security role, the expectation is that you articulate the attack surfaces at each step, not just the mechanics. First, DNS resolution: the browser checks its local cache, then queries the configured resolver (typically the ISP or 8.8.8.8) for google.com's IP address. The resolver performs a recursive lookup through the root servers, TLD servers, and google.com's authoritative nameservers. The result is cached for the TTL duration. Attack surface: DNS cache poisoning returns a malicious IP; DNS hijacking modifies the authoritative record. Second, TCP connection: the browser initiates a three-way handshake (SYN, SYN-ACK, ACK) with the resolved IP on port 443. This establishes a reliable, ordered delivery channel. Attack surface: TCP reset injection terminates the session; SYN flood exhausts server connection state. Third, TLS handshake: the browser and server negotiate a cipher suite, the server presents its certificate, the browser verifies the certificate chain against trusted root CAs, and both sides derive session keys via Diffie-Hellman key exchange. All subsequent traffic is encrypted. Attack surface: MITM with a rogue certificate (requires CA compromise or user accepting an invalid cert); TLS downgrade forces a weaker protocol version. Fourth, HTTP request: the browser sends the encrypted GET / HTTP/1.1 request with headers including cookies, Accept, and User-Agent. Attack surface: CSRF submits forged requests; cookie theft if HttpOnly is absent. Fifth, server processing and response: the server processes the request, queries databases, generates HTML, and returns it with response headers including security controls like HSTS, CSP, and X-Frame-Options. Attack surface: SQL injection, XSS, SSRF, missing security headers. Sixth, rendering: the browser parses HTML, executes JavaScript, and loads subresources. Attack surface: stored XSS executes attacker JavaScript; malicious third-party scripts included via CDN.
Q: What is DNS cache poisoning and how does DNSSEC prevent it?
DNS cache poisoning injects false DNS records into a resolver's cache so that clients using that resolver receive incorrect IP addresses — directing them to attacker-controlled servers rather than the legitimate destination. The attack works because DNS was designed without authentication. When a resolver queries an authoritative nameserver and receives a response, it has historically had no way to verify the response actually came from the legitimate nameserver rather than a forged response. The original Kaminsky attack (2008) exploited the fact that DNS uses UDP (easily spoofed) and transaction IDs are only 16 bits (65,535 possible values, feasibly brute-forced). An attacker sending many forged responses with guessed transaction IDs could win the race against the legitimate response and poison the cache. DNSSEC (DNS Security Extensions) prevents this by adding cryptographic signatures to DNS records. Each zone signs its records with a private key. The public key is published in a DNSKEY record. Resolvers retrieve the DNSKEY and verify that every DNS record they receive has a valid signature from the zone's signing key. A forged response cannot have a valid signature because the attacker does not have the private key. The limitation of DNSSEC is deployment: it requires every zone in the delegation chain to be signed, and the resolver must enforce validation. Many zones are not DNSSEC-signed, and many resolvers do not enforce validation. Additionally, DNSSEC prevents content tampering but does not encrypt DNS queries — DNS-over-HTTPS and DNS-over-TLS address the privacy concern separately.
Q: What is the difference between HTTP and HTTPS? What does the padlock actually guarantee?
HTTP (Hypertext Transfer Protocol) sends all data in plaintext — anyone on the network path between client and server can read the full request and response, including cookies, passwords, and page content. An attacker on the same Wi-Fi network can capture this with a packet sniffer. HTTPS is HTTP over TLS (Transport Layer Security). TLS adds three security properties: confidentiality (content is encrypted and cannot be read by network observers), integrity (content cannot be modified in transit without detection), and authentication (the server's certificate proves it is the legitimate owner of the domain). What the padlock guarantees: the connection to the server is encrypted, and the certificate was signed by a Certificate Authority that the browser trusts, for the domain in the address bar. This means a passive observer on the network cannot read the content, and the server is who the domain name says it is. What the padlock does NOT guarantee: the website is safe, legitimate, or trustworthy. Let's Encrypt issues free certificates to any domain owner — phishing sites routinely have valid HTTPS certificates. The padlock means "my connection to this site is encrypted," not "this site is not malicious." A phishing site at https://bank0famerica-secure-login.com will have a padlock. The padlock does not protect against server-side vulnerabilities (SQL injection, XSS), data breaches once data reaches the server, or malware on the client device that reads data before encryption.
Q: What is ARP poisoning and what layer of the network does it operate at?
ARP (Address Resolution Protocol) poisoning is a Layer 2 (Network Access / Data Link layer) attack that allows an attacker on the same local network segment to intercept, modify, or stop traffic between two other hosts. ARP is the protocol that maps IP addresses to MAC addresses on a local network. When device A wants to send a packet to device B at IP 192.168.1.2, it broadcasts an ARP request: "Who has 192.168.1.2? Tell me your MAC address." Device B responds with its MAC. Device A caches this mapping in its ARP table and sends packets directly to that MAC address. Crucially, ARP is completely unauthenticated — any device can send an ARP reply claiming to have any IP address. In an ARP poisoning attack, the attacker sends unsolicited (gratuitous) ARP replies to both device A and the router, claiming that the attacker's MAC address is associated with both the router's IP and device A's IP. Both devices update their ARP tables with the false mapping. Now, traffic from A to the router goes to the attacker, who can read it, modify it, or drop it before optionally forwarding it to the real router. This is a classic man-in-the-middle position at Layer 2. Mitigations: Dynamic ARP Inspection (DAI) on managed switches validates ARP packets against a DHCP snooping binding table; static ARP entries for critical hosts; network segmentation that limits who shares a Layer 2 broadcast domain; detection tools like arpwatch that monitor for ARP table changes. ARP poisoning is only possible if the attacker is already on the local network segment — it cannot be performed from the internet.
Q: What are security-relevant HTTP headers and what attacks does each one prevent?
Security-relevant HTTP response headers instruct the browser how to handle the page content and impose restrictions that prevent common web attacks. They are one of the highest-ROI security controls for web applications because they require only server configuration, not code changes. Strict-Transport-Security (HSTS): instructs the browser to only connect to this domain over HTTPS for a specified duration, even if the user types http://. Prevents SSL stripping attacks that downgrade HTTPS connections to HTTP by intercepting the initial unencrypted redirect. Content-Security-Policy (CSP): defines which sources of content (scripts, styles, images, fonts) the browser is permitted to load. A strict CSP like script-src 'self' prevents execution of injected scripts that are not served from the same origin — the primary defence against Cross-Site Scripting (XSS) in modern browsers. X-Frame-Options or frame-ancestors CSP directive: prevents the page from being embedded in an iframe on another site. Stops clickjacking attacks where attackers overlay transparent iframes over their pages to trick users into clicking buttons on the target site. X-Content-Type-Options: nosniff — prevents the browser from interpreting files as a different MIME type than declared. Stops attacks where an attacker uploads an image file containing HTML/JavaScript and forces the browser to execute it. Set-Cookie with HttpOnly, Secure, and SameSite attributes: HttpOnly prevents JavaScript from reading the cookie (stops XSS from stealing session cookies). Secure ensures the cookie is only sent over HTTPS connections. SameSite=Strict prevents the cookie from being sent with cross-origin requests — the primary CSRF mitigation in modern web development. Referrer-Policy: controls what URL is included in the Referer header when users navigate away. Prevents sensitive URL parameters (tokens, IDs) from leaking to third-party analytics and advertisement domains.

// Part 11

Common Network Misunderstandings That Create Vulnerabilities

HTTPS means the website is secure — I can trust any site with a padlock

Cause: The padlock icon indicates that the TLS connection to the server is encrypted and that the certificate was signed by a trusted CA for the domain name shown. It says nothing about what the server does with your data, whether the site is legitimate, or whether the server has security vulnerabilities. Certificate Authorities issue certificates to any domain owner who can prove domain control — phishing sites and malware distribution sites routinely use HTTPS with valid certificates. In 2022, over 80% of phishing sites used HTTPS.

Fix: Train users that HTTPS only means 'my connection to this specific domain is encrypted.' Evaluate trust based on the domain name (is it the real domain?), the site's reputation, and what you are being asked to provide. Security awareness training must explicitly break the padlock = safe mental model. For technical defences: HSTS preloading, Certificate Transparency monitoring, and browser extensions that validate certificate history.

Our internal services do not need HTTPS — they are on the internal network and attackers cannot reach them

Cause: The assumption that the internal network is a trusted environment has been the premise of the now-obsolete perimeter security model. Modern attacks routinely begin with a compromised endpoint or user on the internal network. Once an attacker is inside, plaintext internal HTTP traffic is trivially intercepted via ARP poisoning or by compromising a network device. Internal credentials, session tokens, and sensitive data transmitted over HTTP are accessible to any attacker with internal network access.

Fix: TLS everywhere, including internal services. Certificate management tooling like HashiCorp Vault or cert-manager in Kubernetes makes internal TLS certificates manageable at scale. mTLS (mutual TLS) provides bidirectional authentication — not only does the client verify the server's certificate, but the server verifies the client's — preventing lateral movement via impersonating internal services. Zero Trust architecture explicitly rejects the 'internal = trusted' assumption.

Closing port 80 will prevent attacks — if a port is closed, it is safe

Cause: Closing unused ports reduces attack surface, but port closure is not a security strategy by itself. Most modern attacks exploit open ports that serve legitimate traffic. Port 443 (HTTPS) is open and necessary — but SQL injection, XSS, authentication bypass, and SSRF all operate through legitimate HTTPS traffic. Port 22 (SSH) is open and necessary — but brute force, credential stuffing, and key theft all attack it. The attack surface is the application running on the open port, not the port itself.

Fix: Close ports that have no legitimate purpose (defence-in-depth, reduces scanner noise). But never mistake port closure for security of the applications behind open ports. Security testing must exercise the applications through the ports they legitimately use. A web application firewall (WAF) inspects traffic on port 443; an IDS inspects traffic on port 22. Port closure is a starting condition, not a destination.

DNS is just infrastructure — attackers do not target DNS

Cause: DNS is infrastructure, which is precisely why attackers target it — a single DNS hijack gives an attacker redirection capability for every service under the affected domain. Notable DNS attacks: the 2019 Sea Turtle campaign hijacked DNS for government and commercial targets in 13 countries by compromising registrar accounts; BGP route hijacking combined with DNS manipulation redirected cryptocurrency transactions; DNS cache poisoning at ISP level redirects all customers to phishing pages; DNS-based data exfiltration evades many perimeter controls because DNS is a permitted protocol.

Fix: Treat DNS as security-critical infrastructure. Enable registrar-level account MFA. Enable DNSSEC for your domains. Monitor Certificate Transparency logs for unexpected certificates issued for your domains (this detects DNS hijacking via certificate issuance). Monitor DNS records for your domains daily — change alerts on A, MX, and NS records are a free early warning system. Log and monitor internal DNS resolution for DGA indicators and data exfiltration patterns.

TLS 1.0 / 1.1 should be fine — older clients need to connect

Cause: TLS 1.0 (1999) and TLS 1.1 (2006) have known cryptographic weaknesses: the BEAST, POODLE, and CRIME attacks exploit specific weaknesses in how older TLS versions implement cipher block chaining. These are not theoretical vulnerabilities — exploit code is publicly available. Major browsers deprecated TLS 1.0 and 1.1 in 2020. PCI-DSS 3.1 prohibited TLS 1.0 for payment data. Supporting old TLS versions for 'compatibility' exposes any modern client to forced downgrade attacks.

Fix: Disable TLS 1.0 and 1.1 entirely. Require TLS 1.2 as a minimum and prefer TLS 1.3. TLS 1.3 removes all insecure cipher suites, mandates perfect forward secrecy, and reduces handshake round trips from 2 to 1. Any client still requiring TLS 1.0 is itself a security risk that needs replacement, not an accommodation that should weaken your server configuration. Use SSL Labs (ssllabs.com/ssltest/) to verify your TLS configuration against current best practices.

🎯 Key Takeaways

  • ✓The TCP/IP model has four layers (Application, Transport, Internet, Network Access) and each layer is an independent attack surface. A firewall at Layer 3 does not stop ARP poisoning at Layer 2. Match the defence to the layer of the attack.
  • ✓IP spoofing — forging the source IP address on packets — is trivially easy because the Internet Protocol has no authentication for source addresses. IP addresses cannot be used as proof of identity. BGP hijacking exploits routing protocol trust to redirect internet traffic at scale.
  • ✓The TCP three-way handshake establishes state on the server. SYN flood attacks exhaust this state by sending SYNs without completing the handshake. Port scanning maps attack surfaces by probing which ports have services listening.
  • ✓DNS translates names to IP addresses through a chain of resolvers and authoritative servers. DNS cache poisoning injects false records; DNS hijacking modifies authoritative records; subdomain takeover claims abandoned CNAME destinations; DNS exfiltration encodes stolen data as subdomain labels. DNS is involved in almost every attack chain.
  • ✓TLS provides confidentiality (encryption), integrity (tamper detection), and authentication (certificate verification) for data in transit. It does not protect data at the server, does not validate that the site is legitimate, and does not protect against server-side vulnerabilities. The padlock means the connection is encrypted, not that the site is safe.
  • ✓HTTP exposes significant information in headers — User-Agent, Referer, cookies, and request paths are all visible to network observers in plaintext HTTP. Security-relevant response headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, SameSite cookies) prevent entire classes of attack with simple server configuration.
  • ✓The TLS handshake uses Diffie-Hellman key exchange to derive session keys that are never transmitted — even a passive observer who recorded the full handshake cannot decrypt the session without the private key. Perfect Forward Secrecy means ephemeral keys are used per session, so compromise of the server private key does not decrypt past sessions.
  • ✓The complete journey of an HTTPS request crosses seven distinct attack surfaces: DNS resolution, TCP connection, TLS handshake, HTTP request, server processing, HTTP response, and browser rendering. Attackers choose the weakest link — understanding all seven is what separates a security engineer from someone who just knows HTTPS exists.
  • ✓Certificate Transparency logs record every TLS certificate issued by public CAs. Monitoring CT logs for your domain detects DNS hijacking (new certificates issued for your domain you did not request), shadow IT (subdomains you did not know existed), and certificate misuse.
  • ✓Network literacy is not optional for security engineers. Firewalls, IDS/IPS, SIEM, packet capture, network-based threat detection — all require understanding what you are looking at. An analyst who cannot read a packet capture cannot do incident response at the network layer.

What comes next

In Module 03, you get hands-on with the operating system every security professional lives in — Linux. File permissions, processes, users, logs, and the specific commands that appear on every incident response and penetration test engagement.

Module 03 → Linux for Security Engineers
Share

Discussion

0

Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.

Continue with GitHub
Loading...