pk.org: Computer Security/Lecture Notes

Network Security

Study Guide

Paul Krzyzanowski – 2026-11-08

The protocols that move data across the Internet were designed without authentication. A router believes what its neighbors announce. A host believes a reply that says which hardware address belongs to an IP address. A name server’s response is believed because it arrived. Replacing the protocols is impractical, so defenses add checks around them. Every attack in this material exploits an unauthenticated claim, unsafe default, or resource that runs out.

How a Packet Reaches Its Destination (Background Info)

A MAC address identifies a network interface on its local network. Software can change it, so it isn’t a reliable identifier. An IP address identifies a host across networks. Addresses are allocated in blocks called prefixes: 128.6.0.0/16 means the first 16 bits identify the network. Private addresses such as 192.168.1.1 are never routed across the Internet.

A local network is a set of devices that can send frames directly to one another through a switch or access point. A switch learns which MAC address is on each port from the source addresses of arriving frames. It forwards a frame only to the port connected to its destination. A router connects a local network to other networks. A host sends packets for other networks to its default gateway.

A host that joins a network obtains its IP address, gateway, and DNS server from any server that responds to its DHCP broadcast. Nothing in the exchange proves the server was authorized. To send to a host on the same network, it obtains that host’s MAC address with ARP: it broadcasts a request and caches whichever reply arrives.

Network software is organized in four layers, each adding its own header:

TCP gives two programs a reliable, ordered stream of bytes over a connection. It numbers every byte with a sequence number so the receiver can order data and acknowledge what arrived. UDP sends individual messages with none of those mechanisms. The Domain Name System translates names into addresses. A host sends its query to a resolver, which asks a chain of servers until it reaches one that is authoritative for the domain.

Loading a web page uses all of these in order:

  1. DHCP for the laptop’s configuration.

  2. ARP for the router’s MAC address.

  3. DNS for the server’s address.

  4. Routes exchanged with BGP for the path between networks.

  5. A TCP handshake.

  6. A TLS handshake.

  7. An HTTP request.

Each step relies on a message the recipient cannot verify, and each is an attack target. Only the TLS handshake includes authentication. It protects the contents of the exchange and the server’s identity, but not against packets being redirected, delayed, or dropped.

Why the Protocols Lack Authentication

The end-to-end principle holds that application-specific functions such as reliability, security, and error recovery belong in the communicating hosts rather than inside the core of the network. Only the endpoints can tell whether a function was performed correctly for the application, so a check inside the network doesn’t remove the need for one at the ends. A function built into the network also imposes its overhead on every application, including those that don’t need it. IP therefore doesn’t guarantee delivery or ordering. TCP at the endpoints provides those guarantees for the applications that want them, and TLS at the endpoints provides security.

ARP, DNS, and BGP were designed for a much smaller Internet and don’t include cryptographic authentication. A message that looks like what a protocol expects is still usually trusted.

Attacks on the Local Network

Most of these attacks require the attacker to be on the victim’s local network, which can mean:

From that position, the attacker exploits the assumption that every device on the local network is telling the truth.

CAM Table Overflow

A switch keeps its table of MAC addresses and ports in content-addressable memory (CAM), memory that is searched by content: the switch presents a destination address and gets back the port in one step. CAM is expensive, so the table is small. The vulnerability is that a switch learns addresses from any frame it receives, and the CAM table has a fixed size. The attacker floods the switch with frames from invented source MAC addresses until the table is full. The switch then copies frames for unknown destinations to every port, so the attacker can read unencrypted traffic among the others.

The defense is port security on a managed switch, a switch an administrator can configure. It limits how many MAC addresses, or which ones, may appear on each port.

ARP Cache Poisoning

The vulnerability is that ARP does not authenticate replies. Hosts update their caches on replies they never asked for. The attack takes three steps:

  1. The attacker sends the victim a forged reply mapping the router’s IP address to the attacker’s MAC address.

  2. The attacker sends the router a forged reply for the victim’s address.

  3. The attacker forwards everything in between, so the victim doesn’t notice.

The attacker can read unencrypted data, modify unauthenticated data, and drop or delay anything. A validated TLS session protects its contents but not its availability.

The defense is Dynamic ARP Inspection on a managed switch, which drops ARP replies that do not match the address bindings the switch learned from DHCP traffic. IPv6 replaced ARP with the Neighbor Discovery Protocol, which trusts local messages the same way. The attack and the defense are the same.

DHCP Spoofing and Starvation

The vulnerability is that a DHCP client cannot tell an authorized server from any machine that responds first. The attacker runs a rogue DHCP server that can hand out two kinds of false configuration:

In DHCP starvation, the attacker requests addresses for thousands of invented MAC addresses until the real server has none left, so new devices cannot join.

The defense against spoofing is DHCP snooping on a managed switch. The administrator marks the ports that lead to the real DHCP server as trusted, and the switch drops DHCP server replies that arrive on any other port. Snooping does not stop starvation. Port security and a limit on the rate of DHCP requests per port do.

VLAN Hopping

Organizations divide a physical network into virtual LANs (VLANs), separate logical networks on shared switches. Frames between switches travel over a trunk with a tag naming their VLAN. Traffic between VLANs must pass through a router or firewall.

The vulnerability is a switch configuration that lets an end device act like another switch. In switch spoofing, the attacker’s machine negotiates a trunk link with a switch that allows automatic trunk negotiation, and the switch forwards other VLANs to it. Double tagging exploits the trunk’s untagged native VLAN to inject a frame into another VLAN.

The defenses are:

The Evil Twin

The vulnerability is that a Wi-Fi network name doesn’t prove anything, and on an open network there’s nothing else to check. The attacker runs an access point that broadcasts the name of a legitimate network. A victim who connects gets the attacker’s DHCP and DNS servers, which gives the attacker the same redirection as ARP poisoning. TLS protects validated sessions, but a fake login page on the attacker’s equipment collects whatever the user types.

The defense is a password-protected network, which stops an attacker who does not know the password. Enterprise Wi-Fi authenticates the network to the client, but only if the client validates the authentication server’s certificate.

The protocols in this section don’t authenticate anything, so the switch is configured to verify what they do not. Transport-layer encryption limits what an attacker who gets past those controls can do with the traffic.

Forging Source Addresses

An on-path attacker is somewhere the victim’s packets pass through and can see and alter them. An off-path attacker is anywhere else on the Internet. It can send packets but cannot see the victim’s, so it has to guess anything it needs to know.

IP spoofing is writing a false source address into a packet. The vulnerability is that routers forward on the destination address and most do not check the source, so the packet is delivered with the false address. Replies go to the forged address, not to the attacker. A spoofed packet therefore cannot by itself complete a login or hold a conversation. That limit is why blind TCP attacks have to guess. It is also what makes spoofing useful for reflection attacks, where the attacker wants a server’s reply to go to someone else.

The defense is ingress filtering: each network drops packets leaving it whose source address does not belong to it. Deployment is voluntary and uneven. An attacker needs only one network that forwards spoofed packets.

Routing Between Networks: BGP Attacks

The Internet is a network of networks. Each autonomous system (AS) is a set of prefixes and routers under one administration, and each has a unique number. Autonomous systems exchange routes with BGP. An AS announces each prefix it owns to its neighbors. A neighbor that accepts the route adds its own number to the front and announces it in turn, so an announcement contains the AS path it has traveled. Each AS decides by policy which routes to accept and pass on. Participation requires a BGP session with a neighbor, so an attack requires one of:

A router picks the most specific prefix that matches a destination. A route to a /24 beats a route to the /22 containing it, regardless of path length or who announced it. Among routes to the same prefix, the router applies its policy and then prefers the shortest AS path.

BGP Hijacking

A BGP hijack is an unauthorized announcement of someone else’s addresses. The vulnerability is that BGP does not verify that an AS is authorized to announce a prefix or that the AS path is real. A router that doesn’t filter its neighbors’ announcements passes on what it receives. Announcing exactly the victim’s prefix wins only where the hijacker’s path is shorter. Announcing a more specific prefix wins everywhere the announcement is accepted.

Once traffic arrives, the hijacker can do three things with it:

  1. Drop it, which is denial of service.

  2. Inspect and forward it, which is an adversary-in-the-middle position at the scale of a network. Encrypted traffic passes through unread.

  3. Respond to it with an impostor server.

A route leak is an AS passing on routes it learned from one neighbor to another that should not have received them, usually by mistake. Traffic then flows through a network never meant to transport it.

A hijack combined with forged DNS responses defeats everything except certificate validation. A hijacker who also obtains a certificate for the hijacked name defeats that too, which is possible because certificate authorities verify domain ownership by connecting to the domain’s addresses.

Defending Routing

Prefix filters on each neighbor connection list the prefixes a customer may announce and reject anything else. They stop most accidental hijacks at the first hop. Monitoring services alert a prefix owner when someone else announces its addresses.

The Resource Public Key Infrastructure (RPKI) adds signed statements of who may announce a prefix. The registries that allocate address blocks act as certificate authorities. A block’s holder signs a Route Origin Authorization (ROA), which says that one AS may announce a prefix and may not announce anything more specific than a given length.

A router that validates routes compares each announcement with the published ROAs. The check has three outcomes:

The operator’s routing policy determines which routes to accept or drop. Three conditions have to hold for this to stop a hijack:

  1. The holder has published an ROA.

  2. No covering ROA authorizes the announcement.

  3. The receiving network drops routes marked invalid.

Origin validation checks only the claimed origin AS, which the announcer writes. A hijacker who forges a path ending in the legitimate origin AS, and announces a length the ROA allows, passes validation. Stopping that requires verifying the path itself. BGPsec has each AS sign the announcement as it forwards it. It requires every AS on the path to participate, and it is almost entirely undeployed. Path verification is still rare.

Routers as Targets

A router is a computer, and its vulnerabilities are those of any exposed computer:

Compromising a router gives an on-path position for everything that passes through it. The attacker can redirect, delay, or drop traffic and read anything unencrypted, but cannot decrypt a TLS session. The defenses are:

Transport Layer Attacks

The transport layer’s identifiers are the addresses and ports in each packet and, for TCP, the sequence numbers. The vulnerability shared by the attacks in this section is that an attacker who knows or can guess those numbers can inject segments the receiver accepts. Injection does not defeat TLS, because the attacker cannot produce the authentication code that TLS attaches to its data. Password login alone doesn’t provide that protection.

A TCP connection begins with a three-way handshake:

  1. The client sends a SYN with a random initial sequence number.

  2. The server replies with a SYN-ACK that acknowledges it and supplies its own.

  3. The client sends an ACK.

Each side maintains a receive window and discards a segment whose sequence number falls outside it. Sequence numbers were designed to order data, not to authenticate it.

Sequence Number Prediction

The attack lets an off-path attacker complete a handshake while claiming to be another host. It requires two vulnerabilities: a server that trusts clients by address, and initial sequence numbers that are predictable. The attack takes three steps:

  1. The attacker opens a connection to learn the server’s current sequence number.

  2. The attacker forges a SYN from the trusted host and never sees the SYN-ACK.

  3. The attacker sends a correctly guessed ACK followed by a command.

The defense computes each initial sequence number from a secret combined with the connection’s addresses and ports, so numbers cannot be predicted from one connection to another. An on-path attacker can still read the real numbers, so services no longer trust a client by its address.

SYN Flooding

A SYN flood fills a server’s table of pending connections. The vulnerability is an imbalance in the handshake. Each SYN makes the server allocate memory and wait for an ACK that never comes. The sender spends one packet, usually with a forged source address.

The defense is SYN cookies, which remove the allocation. The server encodes what it needs in the sequence number of its SYN-ACK. It allocates the connection only when a matching ACK arrives. A cookie proves only that the client can receive packets at the address it claims. It protects the pending-connection table, not bandwidth or processing.

Forged Resets

A forged TCP reset terminates a connection. The vulnerability is that a segment with the RST flag tells the receiver to abandon the connection, and the receiver cannot tell a forged one from a real one. An on-path attacker has everything needed. An off-path attacker must guess a sequence number.

The defense against the off-path attacker is the rule that a receiver accepts an RST only if its number exactly matches the next expected one, which makes blind guessing impractical. TLS doesn’t help against either attacker, because encryption protects a connection’s content, not its availability.

UDP

UDP has no handshake, sequence numbers, or connection state. The vulnerability is that a UDP service that responds to any request will respond to a forged one. If the reply is larger than the request, the attacker has amplified the traffic.

A UDP application can add its own checks, such as a token the client must echo before the server does any real work. Networks use ingress filtering and rate-limit replies.

DNS

A domain name is read from right to left. The namespace is divided into zones, each served by its own servers. A zone’s servers know where to find the servers for any part that has been delegated. Three kinds of servers make up the hierarchy:

A domain is created by registering it with a registrar, which tells the top-level domain which name servers are authoritative for it. A host sends its query to a recursive resolver, which performs the full lookup on its behalf and caches everything it learns. Each record has a time to live that says how long a resolver may cache it. Caching speeds up DNS. It also lets a forged record persist until its TTL expires.

Three record types come up in the attacks:

A query is a UDP message carrying the name, record type, and a 16-bit transaction ID. A resolver accepts a reply that comes from the server’s address to the port the query was sent from, repeats the transaction ID, and asks about the same name and type. Those fields match replies to queries. They are not authentication. The query and reply both travel in the clear.

Pharming

Pharming sends a user who typed the correct name to a server the attacker runs. The vulnerability is that a host asks whatever name server it was configured to ask. Each place that configuration can be changed needs a different kind of access:

The defenses follow the access points:

Cache Poisoning

Cache poisoning plants a forged record in a resolver, so that every client of that resolver is affected for as long as the record stays cached. The vulnerability is that a resolver accepts any reply that matches the fields it can see. An off-path attacker beats the real reply:

  1. The attacker triggers a lookup at the resolver.

  2. The attacker floods the resolver with forged replies that use the authoritative server’s source address and different guesses at the fields the resolver checks.

  3. If a matching forgery arrives before the real reply, the resolver caches it.

In early resolvers, the only unpredictable field was the transaction ID, and the cache was the obstacle, since a resolver with a cached record stopped asking until the TTL expired. The Kaminsky attack bypasses the cache by querying non-existent names, each a fresh chance to win. The forged reply is a referral that names a server at the attacker’s address as authoritative for the domain. The resolver caches that, so one forged reply that arrives first poisons the whole domain.

The defense is source port randomization. Each query is sent from a random port, so the attacker must guess both the port and the transaction ID. That raises the possibilities from about 65,000 to several billion. It defends only against a blind attacker. An attacker on the path between the resolver and the authoritative server sees everything and doesn’t need to guess. Against that attacker, only a signed reply helps.

DNSSEC

DNSSEC is the defense that signs the data. A resolver can verify that a record was published by the zone’s administrator and not modified. It does not encrypt anything, and it doesn’t say who sent a reply.

A zone’s administrator signs each set of records and publishes the signatures with the zone’s public key. The parent zone authenticates the key by publishing a signed hash of it, and so on up to the root. The root’s key is the trust anchor that ships with the resolver.

A validating resolver handles a reply in one of three ways:

The client then gets an error rather than a forged address, which stops cache poisoning for signed zones and means a signing mistake makes the domain unreachable.

Validation usually happens at the resolver, not on the user’s machine, so the resolver’s reply to the host is an ordinary unsigned message that an attacker on that hop can forge. DNSSEC also authenticates whatever a zone’s owner published, so a malicious domain can sign its own records.

Adoption is low because a signing mistake takes the domain offline for every validating resolver, and the owner who signs bears that risk while the benefit reaches only users whose resolvers validate.

DNS Rebinding

DNS rebinding lets a script on a web page send requests to devices on the victim’s private network, such as a home router or a development server. The vulnerability is in the browser’s same-origin policy, which keeps a script from reading responses from other sites. The policy compares hostnames, not addresses. The attack uses that rule:

  1. The attacker’s name server returns the attacker’s web server with a very short TTL, and the page loads with its script.

  2. When the page’s script requests the same name again, the name server returns a private address.

  3. The request is to the same origin, so the script may read the reply. It is now talking to a device that accepts unauthenticated requests from inside the network.

The durable defense is on the local service: require authentication and check the Host header. Resolvers can refuse to return private addresses for public names. Browsers have begun asking permission before a public page may reach a private address.

Abandoned Delegations

The vulnerability is a lame delegation: a domain’s NS records point to a DNS hosting provider where the zone no longer exists. If the provider lets a new customer claim any zone without verifying ownership, an attacker can create the zone there and respond to queries for the domain. The registrar’s records stay untouched, and the domain keeps its reputation.

Defenses include owners removing name servers that no longer serve the domain and providers verifying control of a domain before serving it.

Encrypting DNS

DNSSEC leaves queries readable, so anyone along the path can see every name a user looks up. DNS over TLS and DNS over HTTPS encrypt the connection between the host and its resolver, which is the hop DNSSEC does not cover. They don’t go further: the resolver still sees every query, and an encrypted connection to a dishonest resolver delivers dishonest responses securely.

Denial of Service (DoS, DDoS)

A denial-of-service (DoS) attack makes a system unavailable to the people who are supposed to use it. A distributed denial-of-service (DDoS) attack is one whose traffic comes from many sources at once. Nearly every large attack is a DDoS attack, because one machine on one connection cannot produce enough traffic to hurt a large service. There are two ways to deny service:

  1. Exploit a flaw that crashes the software, which is fixed once found.

  2. Overload the service, its link, or something it depends on, which doesn’t require a flaw and is how most large attacks work.

A flaw in how a service limits its work can make overloading it far easier.

The arithmetic favors the attacker because handling a request usually takes more work than sending it. The attacker looks for the request with the highest ratio of receiver effort to sender effort. Saturating a large service’s link is harder because one machine has one connection. An attacker can generate traffic at scale through reflection, amplification, or a botnet.

Reflection and Amplification

A reflection attack sends requests to ordinary public servers with the victim’s address as the source, so that their replies go to the victim. It requires a network that forwards spoofed packets and servers that reply to unauthenticated requests, typically UDP services. The reflectors are not compromised. Reflection hides the attacker from the victim, but by itself it doesn’t increase volume. The smurf attack sent a ping to a network’s broadcast address so that every host replied to the victim.

An amplification attack chooses a reflector whose reply is much larger than the request. The amplification factor is the reply size divided by the request size. It depends on the protocol, request, and server’s configuration. DNS gives factors of several dozen. An exposed cache server that returned hundreds of kilobytes for a 15-byte request gave a factor in the tens of thousands.

Three things must be true for amplification to work, and each is a point of defense:

  1. The attacker’s network forwards spoofed packets (ingress filtering).

  2. The service is reachable from the Internet (firewalls).

  3. The service sends a large reply to a small request (rate limiting and protocol changes).

Botnets

A botnet is a group of compromised devices that an attacker controls. Those devices can flood a victim directly or send forged requests to reflectors. They are the usual source of DDoS traffic. The largest botnets are built from devices that stay on, rarely update, and sit on fast home links, often compromised through default passwords. Traffic sent directly from real devices is hard to filter because none of it is forged. Botnets are rented: booter or stresser services sell attacks by the hour. An attack on a shared dependency, such as a DNS provider, can make every site that depends on it unreachable.

Attacks on Applications

An application-layer attack exhausts a server’s processing rather than its link, with requests that are individually valid and hard to tell from real users. The most effective target the requests that take the server the most work, such as search and pages built from several database queries. A flaw in how a server limits work makes such an attack far easier. In the Rapid Reset attack, a client sends an HTTP/2 request and cancels it, over and over, so the server’s limit on open requests never applies while it keeps paying the startup overhead of each one.

An attack is measured by whatever it exhausts:

Defenses

Every defense absorbs the traffic, filters it, or reduces the work each request causes. One rule governs the network-level defenses: filter before the bottleneck. A firewall behind an already-full link discards attack packets after legitimate ones were dropped upstream, so the provider, or a facility with far more capacity than the target, must remove the traffic.

The network-level defenses differ in what they protect:

The application-level defenses keep requests from reaching the origin or reduce the work each one causes:

An organization also keeps itself from becoming part of an attack:

The last two mostly benefit other networks, which is why they remain incompletely deployed.

What You Don’t Need to Study

These exclusions apply to the network security material. VPNs, email authentication, and web security are covered by later lectures and their own study guides. The background section on how a packet reaches its destination is a review for anyone who has not studied IP networking, not exam material in itself.

The following are not required for the exam:

Terms we covered