The Internet was built to deliver, not to protect
You have spent this whole ladder admiring how well the Internet delivers. A packet is a postcard with an address; routers forward it hop by hop; TCP turns a lossy path into a clean, ordered byte stream. But notice what every one of those mechanisms quietly assumes: that everyone involved is honest. A postcard is readable by every postal worker who handles it, anyone can write any return address on it, and nothing stops a stranger from dropping a forged postcard into the mailbox. The Internet was designed in a small circle of trusting researchers, and protecting messages from a hostile party was simply not on the original list of jobs.
That is the uncomfortable starting point of this rung. None of the layers you have studied protect you on their own. TCP is reliable but not secure — it guarantees your bytes arrive in order, and encrypts absolutely nothing. IP names a location, not a person, and lets anyone claim to be at any address. DNS, the Internet's phone book, answers questions without proving who is answering or hiding the question. Network security is the discipline of adding protection back on top of a system that was never built with it — bolting locks onto a house whose doors were designed only to open.
What are we even protecting? The CIA triad
Before listing attacks, it helps to name what we want. Security people summarize it as the CIA triad — three goals, and despite the name they have nothing to do with any agency. Confidentiality means only the intended parties can read the message; an eavesdropper learns nothing. Integrity means the message arrives exactly as sent; if even one bit is changed, the receiver can tell. Availability means the service stays usable for legitimate users; nobody can shove you out of your own house.
Two of these are easy to mix up at first, so pin them down with a postcard. Confidentiality is whether a nosy postal worker can read your message — fixed by writing in a code only the recipient can decode. Integrity is whether someone scribbled over your words in transit — fixed not by hiding the message but by attaching a tamper-evident seal that breaks if anyone touches it. You can have one without the other: a message can be perfectly secret yet silently altered, or perfectly verifiable yet readable by all. Different goals need different tools, and a fourth idea — authentication, proving who you are actually talking to — sits alongside the triad and turns out to be the hardest of all.
Eavesdropping: someone is reading your postcards
The simplest attack is also the quietest. Eavesdropping is when an attacker reads traffic that is not meant for them, changing nothing — a passive attack. Recall that a frame on a shared medium reaches every device on the segment, and that data crosses many routers and links you do not control on its way across the world. Anyone sitting on that path — the café next to you on open Wi-Fi, a compromised router, your Internet provider, a government tap on a backbone cable — can copy every byte that flows past, the way a postal worker reads every postcard they sort.
Because eavesdropping touches nothing, you can almost never detect it; the attacker leaves no trace. This is exactly why we cannot rely on catching them in the act. The only real defence is to make the copied bytes useless — encryption, so that what the eavesdropper captures is gibberish without the key. The honest framing for this rung is that confidentiality on the open Internet is achieved not by keeping data off untrusted paths (you usually cannot) but by assuming the path is hostile and encrypting end to end regardless.
Spoofing and replay: lies about who and when
If eavesdropping is reading, spoofing is lying. To spoof is to forge the source of a message so it appears to come from someone it did not. Remember that nothing in IP verifies the return address — a sender simply writes a source IP into the packet header, and routers happily forward it without checking. So an attacker can send packets stamped 'from your bank' or pretend to be a trusted machine on your local network. Spoofing is the raw material of impersonation: it attacks authentication, the question of who you are really talking to.
A vivid local example is ARP spoofing. Recall ARP: when your laptop wants to reach the gateway, it broadcasts 'who has this IP address?' and trusts whoever answers with a MAC address. There is no check at all. An attacker on the same network simply answers first and falsely — 'that IP is at my MAC address' — and now your laptop sends the gateway's traffic to the attacker. One forged reply quietly reroutes your conversations through a machine you never chose to trust. This is spoofing at layer 2, and it is the usual on-ramp to the most dangerous attack of all.
There is a subtler relative worth naming now: the replay attack. Here the attacker does not forge a new message at all — they capture a real, legitimate one and send it again later. Imagine overhearing the genuine command 'unlock the door' and simply re-broadcasting that exact recording tomorrow. The message is authentic, which is what makes replay sneaky: confidentiality and a forge-proof seal alone do not stop it, because nothing in the message says when it was meant to be used. Defending against replay needs freshness — a one-time number or a timestamp — and that is why the cryptography in the next guide cares so much about 'when', not only 'who' and 'what'.
Man-in-the-middle: the attack that hides between you
Combine reading and lying and you get the most dangerous threat in the whole rung: the man-in-the-middle (MITM) attack. Here the attacker sits squarely on the path between two parties — using ARP spoofing, a rogue Wi-Fi access point, or a poisoned DNS answer to get there — and relays messages between them while reading and possibly altering everything that passes. Alice thinks she is talking to Bob; Bob thinks he is talking to Alice; in reality both are talking to the attacker, who quietly forwards their words while keeping a perfect copy and editing at will.
WHAT ALICE BELIEVES: Alice <--------------------> Bob
WHAT IS REALLY HAPPENING: Alice <-----> ATTACKER <-----> Bob
(reads + edits
every message,
relays the rest)Here is the deep and slightly disturbing lesson. Encryption alone does not stop a man-in-the-middle. If the attacker is between you from the very first message, then when you try to set up an encrypted channel, you actually set it up with the attacker — who sets up a second encrypted channel with the real far end, reads everything in the clear in the middle, and re-encrypts it onward. Both halves are perfectly encrypted; the eavesdropper is reading anyway. The missing piece is authentication: you need a way to be sure the key you encrypted to really belongs to the person you meant, not to whoever happens to be in the middle.
That single gap — how do I trust a key really belongs to who I think? — is the thread that ties this whole rung together. It is why we need signatures, certificates, and certificate authorities, and why TLS does so much careful work during a handshake before any real data flows. Keep MITM in mind as the boss-level threat: every later defence is, in part, an answer to 'but what if someone is in the middle?'
When the goal is just to break things
Not every attacker wants to read or impersonate you. Some only want to knock you off the air, attacking the third leg of the triad: availability. A denial-of-service attack floods a target with so much bogus traffic or so many fake requests that legitimate users cannot get through — like a crowd of pranksters jamming a shop's only doorway so real customers can never enter. The attacker is not trying to break in; they are trying to keep everyone else out.
These attacks lean on the same trusting design as the others. A SYN flood abuses the very three-way handshake you studied: the attacker sends a storm of opening SYN packets but never completes them, leaving the server holding thousands of half-open connections until it runs out of room for real ones. A DNS amplification attack spoofs the victim's address on small queries to public servers, which reply with much larger answers all aimed at the victim — a little forged request triggering a giant reply, multiplied across thousands of servers. The truly hard version is the distributed one, DDoS, where the flood comes from a vast army of compromised devices at once, so there is no single source to simply block.
Step back and you can see the shape of the whole field now. Confidentiality is threatened by eavesdropping; integrity and authentication by spoofing, replay, and man-in-the-middle; availability by denial-of-service. Each of the next four guides picks up these threats and builds the answers: cryptography for confidentiality and integrity, certificates and TLS for authentication against MITM, firewalls and VPNs to control and protect what crosses a boundary, and DDoS defence for availability. You now have the map of the battlefield — and the rest of this rung is how we fight back.