Common Network Attacks
Every protocol covered so far trusts something: that a MAC reply came from its rightful owner, that a DNS answer is genuine, that a route announcement is truthful. Network attacks exploit that trust. Knowing what each attack abuses, what it looks like on the wire, and the standard countermeasure is what lets you recognize an incident instead of just seeing "the network is acting weird." This is a defensive survey, not a how-to - the firewalls and IDS/IPS lesson that follows covers the mitigations in more depth.
| Attack | Exploits | Symptom | Mitigation |
|---|---|---|---|
| IP/MAC spoofing | No authentication of source addresses | Traffic appears to come from a trusted host that never sent it | Ingress/egress filtering, port security |
| ARP spoofing | ARP has no authentication | Duplicate/incorrect entries in the ARP cache | Dynamic ARP inspection, static entries |
| DNS cache poisoning | Resolvers cache unauthenticated answers | Domain resolves to the wrong IP | DNSSEC, source-port randomization |
| MITM | Traffic quietly rerouted through an attacker | Certificate warnings, unexpected latency | TLS, certificate pinning |
| SYN flood | TCP's half-open handshake state | Backlog full, legitimate connections time out | SYN cookies, rate limiting |
| Volumetric DDoS | Sheer traffic volume overwhelms capacity | Bandwidth saturated, service unreachable | Scrubbing, anycast, upstream filtering |
| BGP hijacking | BGP announcements are unauthenticated | Traffic for a prefix routed through an unexpected AS | RPKI, route filtering |
IP and MAC address spoofing
Both IP and Ethernet headers carry a source address the sender fills in itself - there is no built-in check that it is telling the truth. IP spoofing forges the source IP in a packet; MAC spoofing does the same at the link layer. Neither is an attack on its own, but both are the building block underneath several attacks below: a forged source address hides who really sent the traffic, or lets a reply be misdirected to somewhere the attacker can read it.
The observable symptom is usually indirect: traffic that claims to originate from an address that could not actually have sent it (an internal address arriving on the external interface, for example). The standard mitigation is ingress/egress filtering at network boundaries - drop packets whose source address could not legitimately appear on that link - plus port security on switches to bind a MAC to a specific physical port.
ARP spoofing (ARP poisoning)
The ARP lesson noted that ARP has no authentication: any host on the link can reply to a request, and nothing checks that the reply came from the address it claims to be. ARP spoofing abuses exactly this - an attacker sends unsolicited ARP replies claiming to own an IP (often the default gateway's), and every host that caches the lie now sends that traffic to the attacker instead.
The symptom is a poisoned ARP cache: arp -a shows the gateway's IP mapped to
the wrong MAC, or the mapping flips unexpectedly. The standard mitigation is
dynamic ARP inspection on switches, which validates ARP replies against a
trusted binding table, or static ARP entries for critical hosts like the
gateway.
DNS cache poisoning
DNS resolvers cache answers to avoid re-querying
authoritative servers on every lookup - but a resolver has no way to verify
that a cached answer is genuine unless it explicitly checks. DNS cache
poisoning injects a forged answer into that cache, so every client asking
that resolver for example.com gets the attacker's IP instead of the real one,
until the entry expires.
The symptom is a domain resolving somewhere it should not: a name that suddenly points to an unfamiliar IP, or wildly inconsistent answers between resolvers. The standard mitigation is DNSSEC, which cryptographically signs DNS records so a resolver can verify an answer's authenticity, alongside source-port and query-ID randomization to make forged replies harder to guess.
Man-in-the-middle (MITM)
A MITM attack sits the attacker on the path between two parties who believe they are talking directly to each other, letting them read or alter traffic in transit. ARP spoofing is one way to get there on a LAN (reroute a victim's traffic through the attacker); a rogue access point does the same on Wi-Fi, luring clients to associate with an attacker-controlled AP instead of the real one.
The symptom is often a certificate warning - the connection is being intercepted somewhere that cannot present a valid certificate for the real site - or subtle signs like unexpected latency and TLS renegotiation. The standard mitigation is exactly what the TLS lesson covers: certificate validation stops an attacker without the private key from impersonating the server, and certificate pinning tightens that check further for high-value connections.
SYN flood
The TCP three-way handshake leaves a
connection half-open after the server sends SYN-ACK and is waiting for
the client's final ACK. A SYN flood sends a stream of SYN packets
(often with spoofed source IPs, so replies go nowhere) and never completes the
handshake, filling the server's backlog of half-open connections until it has
no room left for legitimate clients.
The symptom is new connections timing out or being refused while the server
otherwise looks healthy. The standard mitigation is SYN cookies: instead of
storing state for a half-open connection, the server encodes the state into the
SYN-ACK's sequence number itself and only allocates a real connection once a
valid final ACK proves the handshake completed.
Volumetric / DDoS
Where a SYN flood exhausts a specific piece of connection state, a volumetric DDoS attack just aims to exhaust raw capacity - bandwidth, packet-processing rate - by sending traffic from many sources at once (the "distributed" in DDoS), often amplified by reflecting requests off third-party servers that send a much larger reply than the request that triggered it.
The symptom is straightforward: bandwidth or request rate saturates well beyond normal levels and the service becomes slow or entirely unreachable for everyone, not just one target. The standard mitigation is traffic scrubbing (routing traffic through a service that filters attack traffic before it reaches you), anycast (spreading load across many points of presence so no single link absorbs it all), and rate limiting upstream, closer to the source than the target.
BGP route hijacking
BGP routes the entire Internet by autonomous systems announcing "I can reach this prefix," and other ASes largely trust those announcements. A BGP hijack is an AS announcing a prefix it does not actually own, and if that announcement looks more specific or otherwise more attractive, other routers start sending it traffic for addresses it has no right to.
The symptom is traffic for a prefix suddenly routing through an unexpected AS - visible in routing tables or via services that monitor global BGP announcements - sometimes with the traffic quietly forwarded onward (invisible to end users) and sometimes just dropped (an outage). The standard mitigation is RPKI (Resource Public Key Infrastructure), which lets a prefix owner cryptographically sign which AS is authorized to originate it, and route filtering by providers that reject announcements failing that check.
Every mitigation above is a special case of a general principle: don't trust an unauthenticated claim about identity, address, or route. The next lesson, firewalls and IDS/IPS, covers the boundary devices that enforce this in practice - filtering what is allowed to pass at all, and watching what does get through for exactly these patterns.