Part 1: Link Layer Attacks
Part 2: Network Layer Attacks
Part 3: Transport Layer Attacks
Part 4: DNS Attacks
Part 5: DDoS Attacks

The Trust Problem: Networks Without Authentication

The Internet and local networks were built to make communication easy, not to make it secure. A core problem is the lack of built-in authentication in the protocols that run the network. When your computer sends a packet, there is no cryptographic proof of who sent it. When a router says it can reach a network, there is no built-in check that the claim is true. When a device claims to own a particular IP address, other devices usually believe it.

This design wasn’t an oversight. It follows the end-to-end principle: keep the network core simple and put intelligence at the edges. The network’s job is to deliver packets from one host to another as efficiently as possible. Reliability, ordering, and security are left to the endpoints that use the network.

This idea has proven remarkably successful. For example:

• The Internet Protocol (IP) does not guarantee reliable delivery, but TCP adds reliability at the endpoints.

• IP does not ensure packet order, but TCP reorders them.

• Even the original end-to-end paper suggested that encryption and security should be done at the endpoints rather than inside the network.

The problem is that many of the application-level protocols we still rely on weren't designed with security in mind. Protocols like ARP (for mapping IP addresses to hardware addresses), BGP (for internet routing), and DNS (for translating domain names to IP addresses) were created when the internet was a small, trusted community of academic and research institutions. These protocols assumed honest participants. Adding authentication seemed unnecessary and would have introduced complexity.

As the Internet grew to billions of users, those assumptions no longer held. Replacing these protocols is extremely difficult because the global Internet depends on them, and they are implemented in millions of devices and software systems.

Security has been added as extensions and overlays: TLS for encrypted web traffic, IPsec (along with IKEv2, OpenVPN, IKEv2, and others) for encrypted network traffic, and DNSSEC for authenticated DNS.

These help, but the base protocols still trust others by default. Attacks exploit that trust. Defenses rely on configuration, monitoring, and multiple security layers to reduce the impact of unauthenticated protocols.

Introduction: Layers of Vulnerability

Networks connect almost everything—from laptops and phones to data centers and industrial systems.
To manage such diversity, network communication is organized in layers. Each layer handles a different part of the job and introduces its own security risks.

We will focus on three critical layers of the network stack:

1. Data Link layer
This layer covers communication between devices on the same local network, like your laptop talking to your Wi-Fi router or two computers on the same Ethernet switch. Attacks here usually exploit the built-in trust local devices have for each other.

2. Network layer
This layer moves packets across networks: how your data travels from your local network through multiple routers across the Internet to reach a remote server. Attacks at this level can misdirect, intercept, or block traffic.

3. Transport layer
This layer handles end-to-end communication between applications. It ensures that data arrives in order, without loss or duplication. Attacks here often exploit the way connections are created and managed.

Each of these layers depends on the one below it. A weakness at one layer can often be used to attack higher layers. Understanding how these layers work -- and where they make unsafe assumptions -- helps explain how attackers can intercept traffic, hijack sessions, or take down services.

Data Link Layer: Exploiting Local Network Trust

The Data Link layer operates within your local network: the subnet where your computer, nearby devices, and your router all communicate directly through an Ethernet switch or Wi-Fi access point.

At this level, devices assume that all other devices on the network are legitimate. This assumption creates several opportunities for attack.

CAM Table Overflow: Turning Switches into Hubs

Modern networks use switches to connect devices. A switch keeps track of which device is on which port by maintaining a Content Addressable Memory (CAM)¹ table that maps each device’s MAC address (a hardware identifier) to the switch port where that device is connected.

When a switch receives a frame from a new device, it learns that device’s MAC address and adds it to its CAM table. This allows the switch to forward future traffic for that address only to the correct port instead of broadcasting it to everyone. That behavior makes switched networks faster and more private than the older hub technology, which sent every frame to every device.

A CAM table overflow attack takes advantage of the fact that this table has a limited size -- typically a few thousand entries. The attacker sends a rapid stream of frames using many random, fake MAC addresses. These fake entries crowd out legitimate ones, leaving the switch unable to remember which real addresses belong to which ports. When the switch receives a frame for a destination that no longer has a valid entry, it must send that frame out all ports so that the correct device can respond. This broadcast-like behavior makes the switch act more like a hub, allowing the attacker to see traffic that should have remained private.

Tools such as macof (part of the dsniff suite) can generate thousands of fake MAC addresses per second, making this attack easy to launch.

Defending Against CAM Overflow

Defense requires managed switches, which provide configuration controls that basic, unmanaged switches lack. Typical protections include:

• Port security: limit how many MAC addresses can appear on a single port.

• MAC address limits: set a maximum number of addresses per port (for example, five).

• Sticky MAC addresses: lock each port to specific, trusted addresses.

• Violation actions: define what happens when limits are exceeded, such as disabling the port, dropping packets, or sending an alert.

These controls stop CAM table overflow attacks by preventing any one device from filling the table with fake addresses.

VLAN Hopping: Breaking Network Segmentation

Organizations often divide their networks into Virtual LANs (VLANs) for both security and organization. VLANs create separate logical networks on the same physical hardware. For example, accounting might be on VLAN 10, engineering on VLAN 20, and guests on VLAN 30. Devices on different VLANs are isolated from one another unless traffic passes through a router or firewall that enforces access rules.

VLANs work by adding small tags to Ethernet frames that indicate which VLAN each frame belongs to. Switches use these tags to forward traffic only to ports that are part of the same VLAN. This logical separation is meant to prevent one group of users from directly accessing another.

A VLAN hopping attack allows an attacker on one VLAN to send or receive traffic belonging to another VLAN. There are two common techniques.

Switch Spoofing

Many switches use a protocol called Dynamic Trunking Protocol (DTP) to automatically negotiate trunk links with other switches. A trunk is a connection that carries traffic for multiple VLANs. In a switch spoofing attack, the attacker’s computer pretends to be another switch by sending DTP messages. The legitimate switch then converts that port into a trunk and starts sending traffic for all VLANs to the attacker’s machine. The attacker can then capture or inject packets for any VLAN.

Double Tagging

A second technique is the double tagging attack. The attacker crafts Ethernet frames that contain two VLAN tags. The first (outer) tag corresponds to the VLAN the attacker is on; the second (inner) tag is for the target VLAN. The first switch removes the outer tag before forwarding the frame. If the frame is then sent out a trunk port, the next switch sees only the inner tag and forwards the frame into the attacker’s chosen VLAN.

This only works if the attacker’s access port uses the same “native” VLAN as the first trunk port because traffic on the native VLAN is sent untagged. Double tagging cannot be used to capture return traffic, but it can be used to inject packets into another VLAN.

Defending Against VLAN Hopping

Defense again relies on configuring managed switches:

• Disable automatic trunk negotiation on all user-facing ports.

• Manually configure which ports are trunks and restrict them to only the VLANs that need to be carried.

• Assign an unused VLAN as the native VLAN on all trunk links to prevent mixing user traffic with untagged traffic.

• Place unused switch ports in a dedicated, isolated VLAN so that connecting a rogue device does not provide access to production networks.

Many VLAN hopping attacks succeed because default switch settings favor convenience over security.

ARP Cache Poisoning: Redirecting Local Traffic

When devices on a local network want to talk, they need to know each other’s hardware (MAC) addresses. The Address Resolution Protocol (ARP) provides that mapping for IPv4. A host that wants to send to an IP address broadcasts an ARP request: “Who has IP address 128.6.13.4?” The device with that IP address sends an ARP reply with its MAC address (b4:96:91:cf:f4:a4).

Devices cache these ARP responses to avoid the overhead of repeatedly broadcasting requests and waiting for responses. The problem is that ARP has no authentication. Devices accept ARP replies whether they asked for them or not.

An attacker can exploit this trust with ARP cache poisoning, also called ARP spoofing. The attacker sends forged ARP replies claiming ownership of an IP address that actually belongs to another machine, for example the local router. If hosts accept the false mapping, their traffic intended for the router goes to the attacker instead.

This enables a man-in-the-middle (MITM) attack. The attacker can forward the intercepted packets on to the real router so users notice little or no disruption, while reading or modifying the traffic. To avoid detection and keep traffic flowing, attackers usually enable IP forwarding or run a transparent bridge so the victim’s packets continue to reach their destination after interception.

A special kind of ARP reply is the gratuitous ARP. When a device boots up, reassigns an IP address, or wants to announce its presence, it broadcasts an unsolicited ARP reply (i.e., a reply that is not associated with a request) telling the network its IP–MAC mapping. Gratuitous ARPs are normal, which makes it easier for attackers to send unsolicited ARP replies to poison caches.

The attack is particularly effective because most devices have no way of verifying ARP information. If you receive an ARP response, you believe it, even if you didn't ask for it and even if you already had correct information in your cache.

Defending Against ARP Poisoning

Defenses against this attack include:

• Static ARP entries: For critical systems such as routers, servers, or management consoles, configure fixed IP-to-MAC bindings so they cannot be overwritten by ARP replies. Static entries do not scale for large dynamic networks as it becomes a hassle to manage this data, especially when devices join and leave the network or get IP addresses assigned dynamically.

• Dynamic ARP Inspection (DAI): On managed switches, enable DAI. The switch checks ARP packets against a trusted database of IP–MAC bindings and drops suspicious ARP traffic. DAI typically uses DHCP snooping data to build its binding table.

• Port security: Restrict which MAC addresses can appear on each switch port to prevent an attacker from using a single port to claim many addresses.

• Monitoring and alerts: Use tools that detect sudden changes, such as multiple hosts claiming the same IP or a single MAC claiming multiple IPs, and produce alerts for operator investigation.

• Encryption and authentication at higher layers: Even if an attacker can intercept traffic, protocols like TLS that authenticate and encrypt a communication session protect the contents and prevent trivial credential theft or session hijacking. Encrypted protocols reduce the value of an ARP-based man-in-the-middle attacks.

Note that CAM overflow, VLAN hopping, and ARP poisoning attacks require local network access: the attacker must be on the same broadcast domain as the victim. That means Wi-Fi access, a compromised machine on the LAN, or a physical connection. ARP attacks are powerful in that context, but they do not work from across the Internet unless other compromises exist.

IPv6 Neighbor Discovery: The Same Attack, Different Protocol

IPv6, the newer version of the Internet Protocol designed to solve IPv4's address exhaustion problem, replaced ARP with the Neighbor Discovery Protocol (NDP).

Unfortunately, NDP has similar security weaknesses to ARP. The protocol sends Neighbor Solicitation messages to ask “Who has this IPv6 address?” and Neighbor Advertisement messages to reply. It also includes Router Advertisements, which inform hosts about default gateways and network settings.

Like ARP, NDP trusts that all devices on the local network are honest. There is no authentication or message validation. An attacker on the same LAN can send forged NDP messages to:

• Claim another host’s IPv6 address and receive its traffic, creating a man-in-the-middle situation.

• Advertise a fake default router so that all outbound traffic goes through the attacker’s system.

• Send bogus network prefix information that confuses other hosts or disrupts connectivity.

These attacks are the IPv6 equivalents of ARP poisoning and rely on the same basic problem: trusting unauthenticated messages on the local network.

Defending Against NDP Poisoning

• Static neighbor entries: For important devices such as routers or servers, configure fixed IPv6-to-MAC address mappings so hosts ignore forged advertisements.

• Switch-based validation: On managed switches, enable features that check NDP messages against known bindings to block invalid ones.

• Monitoring and alerts: Watch for unusual behavior, such as a new router suddenly appearing or one MAC address claiming many IPv6 addresses.

• Higher-layer protection: Encryption protocols such as TLS and IPsec limit the damage of interception by hiding or authenticating the contents of packets.

• Secure Neighbor Discovery (SEND): NDP has an optional extension that adds cryptographic authentication, but SEND is rarely used because it is complex to deploy.

While the details differ, for this class, think of NDP as “ARP for IPv6.” It performs the same role and suffers from the same trust problems, and the same kinds of defenses apply: verification, monitoring, and limiting who can send these messages.

DHCP Spoofing: Controlling Network Configuration

When devices join a network without manual configuration, they typically use the Dynamic Host Configuration Protocol (DHCP) to obtain their network settings. A new device broadcasts a request asking for configuration information, and a DHCP server responds with:

• an IP address to use

• the subnet mask

• the default gateway (router)

• addresses of DNS servers

• the period of time (lease) for which the data is valid

This process is automatic and trust-based: the client simply accepts the first DHCP reply it receives. This creates an opportunity for an attack.

A DHCP spoofing attack occurs when an attacker runs a rogue DHCP server on the same local network and responds before the legitimate DHCP server does. If the victim accepts the attacker’s reply first, it configures its network settings according to the attacker's specifications.

There are three main attack goals:

• Man-in-the-middle (gateway redirection):
  The attacker sets its own IP address as the default gateway. All of the victim’s traffic to other networks is then routed through the attacker, who can inspect, modify, or drop it.

• Traffic redirection via DNS:
  The attacker provides a malicious DNS server address that resolves legitimate domain names to attacker-controlled IP addresses. Legitimate domain names now resolve to attacker-controlled IP addresses, sending victims to fraudulent websites or other network services without altering the URLs they typed.

• Denial of service or DHCP starvation:
  The attacker requests many leases or hands out conflicting or unusable addresses, exhausting the DHCP pool and preventing legitimate devices from obtaining addresses.

Attackers sometimes combine DHCP spoofing with other techniques, such as ARP poisoning, to make interception transparent and resilient.

Defenses Against DHCP Spoofing

Effective defenses rely on network infrastructure, especially managed switches, because end hosts cannot verify whether a DHCP reply is legitimate.

• DHCP snooping:
  This protection has two components:

  1. Trusted ports: The switch is configured so that only specific ports are allowed to send DHCP server replies. DHCP responses from any other port are dropped.

  2. DHCP binding table: The switch monitors DHCP traffic and records which IP address was assigned to which MAC address on which port. This table becomes a source of truth for validating future traffic, such as ARP messages, and prevents a wide range of impersonation attacks.

• Port security:
  Restrict how many MAC addresses may appear on each port. This limits an attacker’s ability to impersonate many devices or flood the network with fake requests.

• Rate limiting:
  Limit how many DHCP requests or replies a port can send. This reduces the impact of DHCP starvation attacks.

• Network isolation:
  Place unknown or guest devices on separate VLANs with restricted access. This prevents untrusted machines from reaching management interfaces or internal systems.

• Logging and monitoring:
  Abnormal patterns such as repeated leases on a single port or bursts of DHCP requests can indicate an attack and should generate alerts.

Practical notes

• Only trusted devices should hand out network addresses. Switches can enforce this by accepting DHCP server replies only from approved ports.

• Address assignments can be monitored. The DHCP binding table allows administrators to identify misuse, such as a single device requesting many addresses.

• Wireless networks are easier to abuse. Open or poorly secured Wi-Fi allows attackers to connect and try DHCP spoofing. Using authenticated Wi-Fi (such as WPA2-Enterprise or WPA3-Enterprise) and separating guest traffic into its own network limits the damage a rogue device can do.

DHCP spoofing is simple for attackers and highly effective because DHCP is foundational to network connectivity. Strong switch-level controls, especially DHCP snooping and validation of client assignments, are essential for preventing these attacks before they affect end hosts.

Common Threads in Data Link Attacks

Several patterns appear across all attacks at the Data Link layer:

• Trust without verification: Local network protocols such as ARP, NDP, and DHCP assume that devices tell the truth. They have no built-in authentication, so any device on the same network can send false information.

• Broadcast communication: Many of these protocols use broadcasts to discover devices or services. Attackers can listen to these broadcasts and reply faster than the real devices.

• Local scope: These attacks only work if the attacker is connected to the same local network, either physically or through Wi-Fi. They cannot be launched directly from the Internet.

• Man-in-the-middle positioning: Most of the attacks aim to place the attacker between victims and legitimate network resources, allowing interception or modification of traffic.

The main defense is to replace trust with verification. Managed switches can limit what devices can do, validate protocol messages, and detect suspicious behavior. Even though these protections require careful configuration, they are effective in stopping attacks that depend on a network’s default trust.

Next: Network Layer Attacks