13.2 Understand Network Attacks and Countermeasures

Understand network attacks and countermeasures

Knowledge Area 6.2 of the ISC2 SSCP outline (effective 1 October 2025) is understand network attacks, with three named examples — distributed denial of service (DDoS), man-in-the-middle (MITM), and Domain Name System (DNS) cache poisoning — and a named countermeasure list: content delivery networks (CDN), firewalls, network access controls, and intrusion detection and prevention systems (IDPS). Related operations you will see in stems are ARP spoofing, on-path interception (the current name for many MITM paths), and amplification. Domain 7 will revisit DDoS as malicious activity; this section is the network view: what is exhausted, who sits on the path, and which named control actually interrupts it.

Distributed denial of service

A denial of service (DoS) makes a resource unavailable to legitimate users. Distributed means many sources — typically a botnet — so you cannot block one address and call it done. Classify the resource that is dying; the countermeasure follows the class.

Amplification is a volumetric trick: the attacker spoofs the victim's source IP in a small UDP request to an open reflector. The reflector sends a much larger response to the victim. Classic reflectors are open DNS resolvers, mis-set NTP monlist, Simple Service Discovery Protocol, and abandoned memcached. The amplifier is not the botnet; the botnet is the set of spoofed queries. Closing your open resolver is how you stop being the amplifier for someone else. Scrubbing your circuit is how you survive being the victim.

Scenario — volumetric flood. Friday afternoon the retail site is unreachable. The edge router shows the handoff saturated inbound; legitimate HTTPS is a rounding error. Packet samples are 4 000-byte DNS responses to queries you never sent, source ports 53, destination the public virtual IP. That is amplified DNS DDoS, not a broken web server. The SSCP countermeasure from the outline is a CDN (or equivalent DDoS service) in front of the origin so the flood dies at anycast edges, plus firewall rate limits and IDPS signatures for the leftover. Unplugging the origin to "save it" just completes the outage.

Man-in-the-middle, on-path, and ARP spoofing

Man-in-the-middle (MITM) means an attacker is on the forwarding path and can read or modify traffic. Current writing often says on-path for the same idea. The path can be a rogue Wi-Fi access point, a compromised proxy, a hijacked route, or — on the switched LAN you actually operate — ARP spoofing (also called ARP cache poisoning, ARP poison routing).

ARP maps IPv4 addresses to MAC addresses on a broadcast domain. It is not authenticated. An attacker on the same VLAN sends gratuitous or forged ARP replies: "I am the default gateway." Hosts (and sometimes the gateway) cache the lie. Frames for 192.0.2.1 now go to the attacker's NIC. The attacker forwards a copy to the real gateway so the session stays up — that forwarding is why it is on-path rather than a noisy outage. TLS still helps if clients validate certificates; SSL stripping, a rogue enterprise CA, or users clicking through warnings undo that help. Knowledge Area 5.3 already told you not to click through; 6.2 asks how the attacker got on the path.

Network access control from the outline is the cheap, correct LAN answer: if the attacker cannot get an authorized port, ARP spoofing has no seat. IDPS may flag duplicate IP/MAC or gratuitous ARP storms. A firewall between VLANs does not see intra-VLAN ARP; do not pick "add a firewall rule for TCP/80" as the ARP answer.

DNS cache poisoning at a branch resolver

DNS cache poisoning (DNS spoofing) is an application-layer lie with network consequences. A recursive resolver asks the hierarchy for a name, then caches the answer for the time-to-live (TTL). If the resolver accepts a forged answer — guessed transaction IDs, a Kaminsky-style flood against a predictable source port, a compromised upstream, or an on-path attacker racing the real reply — every client that uses that resolver is sent to the attacker's IP until the TTL expires or someone flushes the cache.

This is not the same as defacing the authoritative zone. The authoritative servers can be honest. The branch cache is what users trust.

Scenario — branch resolver. You are the security administrator for a manufacturer with a small recursive BIND/Windows DNS cache in each plant, pointed at by DHCP. A plant reports that payroll.example.com loads a convincing login that is not yours. Your laptop on the corporate VPN still reaches the real payroll site. Packet capture on the plant LAN shows the local resolver answering payroll.example.com → 198.51.100.66 (attacker) with a two-hour TTL. Authoritative DNS at headquarters still has the correct A record. The plant resolver accepted a forged response and cached it. Every browser on that star topology is now a MITM without ARP spoofing: the name lied, so TLS to the wrong host either fails (if they check names) or succeeds against a phishing certificate the user clicks through.

Operations response, in order:

1. Stop using the poisoned cache. Point DHCP at a resolver that validates, or at a known-good recursive (headquarters, or a DNS-over-TLS/HTTPS forwarder you control).
2. Flush the plant cache and any stub caches; the TTL is a clock, not a suggestion.
3. Turn on DNSSEC validation on recursors so signed zones fail closed on a bogus answer. Unsigned third-party names still need resolver hardening (random source ports, cookie extensions, restrict who may query).
4. Close the open recursive if the plant box answers the internet — you were an amplifier in the previous subsection as well as a poison target.
5. Treat lingering on-path as a 6.2 MITM: 802.1X, DAI, IDPS. Poisoning and ARP spoofing can be combined; they are not mutually exclusive stories.

A CDN in front of the public website does not protect a plant recursive cache. The CDN is the right tool when the origin is being flooded or when you want to hide origin IPs. Mixing those two "DNS" stories is a common trap.

Countermeasures the outline names

Match the control to the attack. The outline's four examples are not interchangeable decorations.

Placement matters and is Knowledge Area 6.4, but 6.2 already expects you to know inline prevention versus passive detection. A span-port IDS that watches a saturated WAN will report after the outage. A CDN and ISP scrubbing center sit in front of that WAN. An IDPS on the plant LAN is the right tool for ARP anomalies and for command-and-control after a host is on-path; it is the wrong first answer for a volumetric flood that never reaches the LAN.

Network access control in this knowledge area is the concept — unauthorized devices do not get a forwarding seat. Knowledge Area 6.3 will make you configure IEEE 802.1X, RADIUS, and TACACS+. Do not wait for 6.3 to remember that MITM on a conference-room jack is a NAC miss.

Putting the three attacks on one ticket

A realistic week can include all three without being three incidents with three owners:

• Friday: volumetric amplified DNS against the public VIP → CDN/DDoS provider, firewall rate limits, confirm you are not also an open recursive.
• Same plant, Monday: a contractor laptop on an open jack ARPs for the gateway → 802.1X and DAI, IDPS alert on duplicate IP/MAC, firewall between user and server VLANs as defense in depth.
• Tuesday: the plant recursive still answers payroll.example.com from Monday's leftover poison → flush, DNSSEC, stop using an open recursive as "the local cache."

Exam traps in 6.2:

• Calling a SYN flood "layer 7" because the target port is 443.
• Picking CDN for an internal resolver poison.
• Picking a new firewall rule on TCP/80 as the ARP-spoofing fix.
• Treating amplification as "the botnet is large UDP" without the reflector and the spoofed victim source.
• Assuming TLS makes MITM impossible; TLS makes undetected MITM harder when clients validate.

When you sit the CAT item, name the attack class (flood, on-path, poisoned cache), name the layer, then pick the outline countermeasure that operates at that layer.

Section takeaways

DDoS is classified by what it exhausts; amplification needs a spoofed UDP query and a reflector. On-path MITM on a LAN is often ARP spoofing and is a NAC/DAI problem. DNS cache poisoning at a branch resolver is a cache integrity problem until TTL or a flush, and DNSSEC plus a closed recursive are the durable fixes. CDN, firewalls, network access controls, and IDPS each cover a different seat on that map.