Introduction
Now this might seem a bit random, but I’ve always been intrigued by both, the OSI model especially. It really was the first thing I ever learned about networking, more than 25 years ago. I’ve been very busy the last weeks with work, Hacker Holidays, a couple of my own projects, etc. I’ve been writing and will be writing on it for sure.
Back to me working for over 25 years in IT. During this time, I’ve lived inside this stack: writing Kubernetes NetworkPolicies, chasing an MTU mismatch across an overlay network, debugging why one pod couldn’t reach a service three namespaces away, reading iptables chains until they finally made sense. I know how packets move and how to stop them. What I never did was sit on the other side and ask what each of those headers hands to someone trying to get in.
That’s the shift I’m making after the Security+ series: same stack, new lens. Before I open nmap and touch my first TryHackMe (THM) room for the day, I want the model clear enough that a scan result reads like a sentence instead of a wall of ports.
Why layers exist in the first place
Networking is split into layers so each piece of technology solves exactly one problem and stays ignorant of the rest. A switch forwards frames without knowing HTTP exists. Your browser renders a page without caring whether the bytes arrived over fiber or WiFi. Each layer only speaks to the one directly above and below it through a defined interface, and that constraint is the whole point: swap copper for radio at layer 1 and everything above keeps running, because nothing above ever addressed the medium directly.
This isn’t a diagram somebody drew for a slide deck. The ISO/IEC 7498-1 standard formalized OSI in the 1980s, and the abstraction has outlived most of the protocols it was designed to describe. That’s the tell of a good model.
The seven layers
| Layer | Name | What happens | PDU | Examples |
|---|---|---|---|---|
| 7 | Application | The data a user or program works with directly | Data | HTTP, DNS, SSH |
| 6 | Presentation | Formatting, compression, encryption | Data | TLS, JPEG, ASCII |
| 5 | Session | Setting up, maintaining, tearing down conversations | Data | NetBIOS, RPC |
| 4 | Transport | Reliable or fast delivery between endpoints | Segment | TCP, UDP |
| 3 | Network | Routing between networks via IP addresses | Packet | IP, ICMP |
| 2 | Data link | Delivery within one local network via MAC addresses | Frame | Ethernet, ARP |
| 1 | Physical | The cables, radio waves, and voltage levels themselves | Bits | Copper, fiber, WiFi |
The Protocol Data Unit (PDU) column is worth memorizing over the layer numbers. When someone says “segment” they mean layer 4, “packet” means layer 3, “frame” means layer 2; the vocabulary itself tells you where in the stack a conversation is happening. My mnemonic for the names, top down: “All People Seem To Need Data Processing.” Cheesy, but it sticks immediately.
OSI versus TCP/IP
Nobody ships the full 7 layer stack. The real internet runs on the Transmission Control Protocol/Internet Protocol (TCP/IP) model, which folds those seven into four, and layers 5 and 6 mostly evaporate; session and presentation concerns get handled inside the application protocol itself rather than as separate stages on the wire. Cloudflare’s breakdown has the vendor-neutral comparison if you want a second angle.
| TCP/IP layer | Maps to OSI | Role |
|---|---|---|
| Application | 5, 6, 7 | Everything the user or program sees |
| Transport | 4 | TCP for reliability, UDP for speed |
| Internet | 3 | Addressing and routing via IP |
| Link | 1, 2 | Physical delivery and local addressing |
Use OSI as the shared language for reasoning about networking and TCP/IP as the thing actually on the wire. RFC 1122 is the closest thing to a formal spec for TCP/IP host behavior. One caveat: TLS is the layer everyone argues about. OSI purists file it under 6, but it runs on top of TCP and below the application, so in practice it behaves like a session/presentation hybrid bolted onto layer 4. That ambiguity matters later, because it’s exactly the seam a man-in-the-middle attacks.
Following one packet down the stack
Take an HTTP GET from your browser and watch it get dressed on the way out:
- Layer 7 produces the raw HTTP request as application data
- Layer 4 wraps it in a TCP segment: source port, destination port, a 32-bit sequence number, a 32-bit acknowledgment number, and the flag bits
- Layer 3 wraps that in an IP packet: source and destination IP addresses, plus a time-to-live (TTL) counter
- Layer 2 wraps the packet in an Ethernet frame: source and destination MAC addresses, and a trailing frame check sequence for error detection
- Layer 1 turns the frame into voltage, light, or radio
Each layer prepends its own header (Ethernet also appends a trailer) and treats everything handed down to it as an opaque payload it must never inspect or modify. That’s encapsulation, and the strict blindness is deliberate: it’s why a router can forward your packet without ever parsing the TLS session inside it.
On the receiving end, each layer strips its own header in reverse and hands the rest up, until layer 7 sees the original request again. RFC 793 lays out every field in the TCP header, including the six classic control flags (URG, ACK, PSH, RST, SYN, FIN) that turn a passive spec into an attack surface.
Reading the headers an attacker reads
Every header is a small pile of metadata, and every field is something you can read, forge, or lie about. The layer a tool operates on decides what it can even see, so this is where the model stops being trivia:
Nmap lives at layers 3 and 4
It crafts packets aimed at IP addresses and ports and reads what comes back. A SYN scan sends a lone SYN and interprets the reply: a SYN-ACK means open, a RST means closed, silence means filtered. The trick is that nmap answers the SYN-ACK with a RST instead of the final ACK, so the three-way handshake never completes and the connection dies half-open, which historically kept it out of application logs. It works because those flag bits and the handshake state machine live in the header, in the clear.
ARP spoofing lives at layer 2
The Address Resolution Protocol has no authentication and no state; a host caches whatever MAC-to-IP mapping it hears, including unsolicited replies. You send a forged reply binding your MAC to the gateway’s IP and traffic starts flowing through you. The same statelessness that makes it trivial also confines it: ARP never leaves the local segment, so it can’t route across the internet.
TTL leaks more than it should
Routers decrement the TTL at every hop and drop the packet at zero, replying with an ICMP Time Exceeded; that’s the entire mechanism behind traceroute. The starting value also fingerprints the sender, since Linux defaults to 64 and Windows to 128, so a TTL of 121 arriving at your host probably started at 128 seven hops away.
TLS protects the payload, not the envelope
A man-in-the-middle against TLS targets the trust chain, but even a perfect TLS session leaves the layers below it naked: source and destination IPs, ports, packet sizes, and timing all travel unencrypted and feed traffic analysis. Cloudflare’s TLS explainer covers the handshake itself.
Wireshark shows every layer at once
A single capture unfolds the whole onion from Ethernet frame down to application payload, which makes it the fastest way to internalize this model. You stop memorizing seven names and start watching them peel apart in real packets.
Next
The OSI model is the map you read a packet with as it crosses your network, and TCP/IP is the terrain it actually runs on. Knowing which layer a tool touches tells you instantly what it can and can’t see, and that single fact does more work during a scan than reciting the layers ever will.
Anyway, I’m busy vibe coding my awesome cybersecurity dashboard into an iOS and maybe even a Android app. Complete unknown territory, that is why Claude will be helping me. A lot.