13.1 Network Attacks and Defense

The previous part covered industrial networking: protocols, topologies, MRP, and Hirschmann switches. The previous content assumed the network carries legitimate traffic. In practice, networks face attacks that exploit protocol weaknesses. Understanding attacks at the packet level enables engineers to build effective defenses and detect attacks in progress.

Why Packet-Level Understanding Matters

A firewall rule blocking “bad traffic” is only as effective as the engineer’s understanding of bad traffic patterns. Knowing how a SYN flood consumes server resources, how ARP poisoning redirects traffic, and how MAC flooding bypasses switch security transforms abstract threats into concrete, detectable patterns.

Security Terminology

Before examining specific attacks, review the core terms that security discussions rely on.

Term	Definition
Vulnerability	A weakness in a system (unpatched software, default password, open port)
Exploit	Code or technique that takes advantage of a vulnerability
Threat	A potential event that exploits a vulnerability (attacker, malware, natural disaster)
Risk	The probability of a threat exploiting a vulnerability multiplied by the impact
CIA Triad	The 3 goals of security: Confidentiality (only authorized access), Integrity (data is accurate and unmodified), Availability (systems are accessible when needed)
Attack surface	The total set of points where an attacker interacts with a system
Zero-day	A vulnerability with no available patch because the vendor is unaware of the vulnerability

Every attack in this chapter targets 1 or more elements of the CIA triad. A SYN flood targets availability. ARP poisoning targets confidentiality and integrity. Understanding which element is at stake guides the choice of defense.

SYN Flood

A SYN flood exploits the TCP 3-way handshake. The attacker sends SYN packets with spoofed source IPs. The server allocates a TCB (Transmission Control Block) for each half-open connection and waits for the ACK that never arrives. The connection table fills up and the server refuses legitimate connections.

SYN cookies (RFC 4987) mitigate SYN floods: the server encodes connection state in the sequence number instead of allocating a TCB. No memory is consumed until the ACK arrives.

The following script detects SYN floods by counting SYN packets per source IP per second.

from scapy.all import sniff, IP, TCP
from collections import defaultdict
import time

syn_counts: dict[str, list[float]] = defaultdict(list)
THRESHOLD = 100

def detect_syn_flood(pkt):
    if not (pkt.haslayer(TCP) and pkt[TCP].flags == "S"):
        return
    src = pkt[IP].src
    now = time.time()
    syn_counts[src].append(now)
    syn_counts[src] = [t for t in syn_counts[src] if now - t < 1.0]
    if len(syn_counts[src]) > THRESHOLD:
        print(f"SYN flood from {src}: {len(syn_counts[src])} SYNs/sec")

sniff(iface="eth0", filter="tcp[tcpflags] & tcp-syn != 0 and "
      "tcp[tcpflags] & tcp-ack == 0",
      prn=detect_syn_flood, store=False)

A source exceeding 100 SYNs per second without completing handshakes indicates an attack. The script makes the attack visible in real time on a mirror port.

SYN floods target servers. ARP poisoning targets the trust model of Layer 2.

ARP Poisoning

ARP has no authentication. Any device sends a gratuitous ARP reply claiming ownership of any IP address. An attacker sends ARP replies mapping the gateway’s IP to the attacker’s MAC. Traffic from the victim then flows through the attacker.

Defend with Dynamic ARP Inspection (DAI) on managed switches. DAI validates ARP packets against the DHCP snooping binding table. On Hirschmann switches, enable DAI on access ports at Security → ARP Inspection.

MAC Flooding

A switch maintains a CAM table (Content Addressable Memory) that maps MAC addresses to ports. The table has a fixed size (8,000 to 32,000 entries on industrial switches). A MAC flooding attack exploits this limit.

The Attack Mechanism

The attacker sends thousands of Ethernet frames per second, each with a random, unique source MAC address. The switch learns each new MAC and adds the MAC to the CAM table. When the table fills, the switch stops learning new addresses. For any frame destined to a MAC outside the table, the switch floods the frame to every port, behaving like a hub. The attacker then sees traffic on the entire segment.

Defense: Port Security on HiOS

Configure port security to limit the number of MAC addresses learned per port. On Hirschmann HiOS, navigate to Security → Port Security and set the maximum MAC addresses per port to the expected number of devices (1 for an access port connected to a single device).

The following script detects MAC flooding by counting new MAC addresses per second on a monitored interface.

from scapy.all import sniff, Ether
import time

known_macs: set[str] = set()
new_mac_times: list[float] = []
THRESHOLD = 50  # new MACs per second

def detect_mac_flood(pkt):
    if not pkt.haslayer(Ether):
        return
    src = pkt[Ether].src
    if src in known_macs:
        return
    known_macs.add(src)
    now = time.time()
    new_mac_times.append(now)
    # Keep only the last second
    while new_mac_times and now - new_mac_times[0] > 1.0:
        new_mac_times.pop(0)
    if len(new_mac_times) > THRESHOLD:
        print(f"MAC flood detected: {len(new_mac_times)} new MACs/sec "
              f"(total unique: {len(known_macs)})")

sniff(iface="eth0", prn=detect_mac_flood, store=False)

A normal network learns a few new MACs per minute. 50 new MACs per second indicates a MAC flooding attack.

MAC flooding turns a switch into a hub. VLAN hopping crosses VLAN boundaries that are supposed to be isolated.

VLAN Hopping

VLAN hopping allows an attacker to send traffic to a VLAN the attacker has no access to. 2 techniques exist: double tagging and switch spoofing.

Double-Tagging Attack

The attacker crafts a frame with 2 802.1Q tags. The outer tag matches the native VLAN of the trunk port. The inner tag specifies the target VLAN.

Step by step:

1. The attacker connects to an access port on VLAN 1 (the native VLAN).
2. The attacker sends a frame with 2 802.1Q tags: outer = VLAN 1, inner = VLAN 20.
3. Switch 1 receives the frame on an access port. Switch 1 sees the outer tag matches the native VLAN and strips the outer tag.
4. The frame now has 1 tag: VLAN 20. Switch 1 forwards the frame out the trunk port.
5. Switch 2 receives the frame tagged VLAN 20 and delivers the frame to VLAN 20 ports.
6. The victim receives the frame. The attack is one-way (the victim’s reply stays in VLAN 20).

Switch Spoofing Attack

The attacker configures the NIC to negotiate a trunk link using DTP (Dynamic Trunking Protocol). If the switch port is set to “dynamic auto” or “dynamic desirable,” the port forms a trunk with the attacker. The attacker then has access to every VLAN on the trunk.

Defense

Defend against both attacks:

• Set the native VLAN to an unused VLAN (not VLAN 1) on every trunk port.
• Explicitly tag the native VLAN on trunk ports (vlan trunk native tagged).
• Disable DTP on every port (set ports to static access or static trunk).
• Keep VLAN 1 free of production traffic.

The following script uses Scapy to craft a double-tagged frame, demonstrating the concept for testing purposes.

from scapy.all import Ether, Dot1Q, IP, ICMP, sendp

# Double-tagged frame: outer VLAN 1 (native), inner VLAN 20 (target)
frame = (
    Ether(dst="ff:ff:ff:ff:ff:ff")
    / Dot1Q(vlan=1)       # Outer tag: native VLAN (stripped by first switch)
    / Dot1Q(vlan=20)      # Inner tag: target VLAN (forwarded by second switch)
    / IP(dst="192.168.20.1")
    / ICMP()
)
print(f"Frame size: {len(frame)} bytes")
print(f"Outer VLAN: {frame[Dot1Q].vlan}")
print(f"Inner VLAN: {frame[Dot1Q:2].vlan}")
# sendp(frame, iface="eth0")  # Uncomment to send (lab only)

Tip

VLAN hopping exploits the default native VLAN configuration. Change the native VLAN on every trunk port to an unused VLAN ID. Disable DTP on every port. These 2 changes eliminate both attack vectors.

Rogue DHCP Server

A rogue DHCP server responds to DHCPDISCOVER messages with incorrect configuration: a wrong gateway (routing traffic through the attacker), wrong DNS servers (redirecting name resolution to attacker-controlled servers), or a short lease time (causing frequent renewals that disrupt connectivity).

Detection

The following script monitors DHCP traffic and alerts when the script detects DHCPOFFER messages from unauthorized server IPs.

from scapy.all import sniff, DHCP, BOOTP, IP

AUTHORIZED_SERVERS = {"192.168.1.1", "192.168.1.2"}

def detect_rogue_dhcp(pkt):
    if not pkt.haslayer(DHCP):
        return
    options = {opt[0]: opt[1] for opt in pkt[DHCP].options if isinstance(opt, tuple)}
    msg_type = options.get("message-type", 0)
    if msg_type != 2:  # DHCPOFFER
        return
    server_ip = pkt[IP].src
    server_id = str(options.get("server_id", server_ip))
    if server_id not in AUTHORIZED_SERVERS:
        offered = pkt[BOOTP].yiaddr
        print(f"ROGUE DHCP SERVER: {server_id} offering {offered}")
        print(f"  gateway={options.get('router', 'none')} "
              f"dns={options.get('name_server', 'none')}")

sniff(iface="eth0", filter="udp port 67 or udp port 68",
      prn=detect_rogue_dhcp, store=False)

Defend with DHCP snooping on managed switches. DHCP snooping designates specific ports as trusted (connected to the legitimate DHCP server) and drops DHCPOFFER messages from untrusted ports.

DNS Poisoning

DNS cache poisoning injects false records into a recursive resolver’s cache. The attacker sends forged DNS responses with a spoofed source IP (matching the authoritative server) and a guessed transaction ID. If the forged response arrives before the legitimate response, the resolver caches the false record and serves the false record to every client.

The Attack

Defense: DNSSEC

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. The resolver validates the signature against the zone’s public key. A forged response without a valid signature is rejected. Deploy DNSSEC on internal zones and configure resolvers to validate signatures.

Additional defenses: use randomized source ports for DNS queries (making transaction ID guessing harder), restrict recursive resolvers to internal clients only, and monitor for unexpected changes in DNS responses.

Social Engineering

Social engineering attacks target people, not protocols. Social engineering bypasses technical controls by manipulating human behavior.

Attack	Method	Defense
Phishing	Fraudulent email with malicious link or attachment	Security awareness training, email filtering
Spear phishing	Targeted phishing aimed at a specific individual	Verify requests through a separate channel
Vishing	Voice phishing via phone call	Never give credentials over the phone
Tailgating	Following an authorized person through a secured door	Badge-only access, security awareness
Shoulder surfing	Watching someone enter a password or PIN	Privacy screens, awareness of surroundings
Pretexting	Creating a fabricated scenario to extract information	Verify identity before sharing information

In OT environments, social engineering is particularly dangerous because operators have physical access to control systems. An attacker posing as a vendor technician who gains physical access to the control room plugs a USB drive into an engineering workstation or connects a laptop to the OT network.

Key Takeaways

MAC flooding turns switches into hubs

Limit MAC addresses per port with port security. Monitor for sudden spikes in new MAC addresses.

VLAN hopping requires 2 changes to block

Change the native VLAN to an unused ID and disable DTP on every port. These 2 changes eliminate both double-tagging and switch spoofing.

Social engineering bypasses technical controls

Security awareness training is a technical control. Conduct training annually and test with simulated phishing campaigns.

What Comes Next

This chapter covered general network attacks. OT networks face additional, specialized threats: malware targeting PLCs, attacks on industrial protocols, and the unique challenges of securing systems that are inoperable during patching. The next chapter covers OT-specific threats and the IEC 62443 framework for defending against OT-specific threats.

References

• RFC 4987 — TCP SYN Flooding Attacks and Common Mitigations (IETF, 2007)
• RFC 4033 — DNS Security Introduction and Requirements (IETF, 2005)
• CompTIA Network+ N10-009 Exam Objectives, Domain 4: Network Security
• Tanenbaum, A. S., & Wetherall, D. J. (2011). Computer Networks (5th ed.). Pearson.