CompTIA Network+ guideOperations and security
CompTIA Network+ Network Attacks: VLAN Hopping, ARP Poisoning, Rogue DHCP, and Defenses
Each attack in N10-009 objective 4.2, paired with what it looks like on the network and the objective 4.3 control that interrupts it, with rogue DHCP and port security worked step by step.
Short answer
Objective 4.2 of CompTIA Network+ N10-009 lists the attacks: DoS and DDoS, VLAN hopping, MAC flooding, ARP and DNS poisoning and spoofing, rogue DHCP servers and access points, evil twin, on-path attacks, social engineering, and malware. Objective 4.3 lists the defenses you apply in a scenario, including device hardening, port security, 802.1X, MAC filtering, ACLs, URL and content filtering, and trusted, untrusted, and screened-subnet zones. Scenarios usually start from a symptom, so learn each attack by what it looks like on the network and which control interrupts it.
How N10-009 pairs attacks (4.2) with defenses (4.3)
CompTIA Network+ N10-009 (V9) gives Network Security 14% of the exam. Two of its objectives work as a pair. Objective 4.2 asks you to summarize attacks and their impact, so you need to recognize each one. Objective 4.3 starts with "given a scenario," so the defenses are what a scenario asks you to apply.
The habit that helps is to read every attack as three things: how it works, what you would see, and which control breaks it. This page stays at the network layer. Passy's Security+ guide to threats, vulnerabilities, and mitigations covers the wider SY0-701 material.
Network+ attack table: what you see and what stops it
Every scenario below is original. The controls column uses defenses the N10-009 objectives name. The objectives' lists are examples, not complete lists, so a real network may add more.
| Attack | Scenario | What you see | Controls from the objectives |
|---|---|---|---|
| DoS or DDoS | A college's registration site stops answering in its busiest week | A saturated link or server. Flow data shows a flood toward one address, from one source (DoS) or many (DDoS) | Edge ACLs can drop a small flood. If the flood fills the internet link itself, filtering behind that link cannot free it, so protection has to sit upstream |
| VLAN hopping | Frames sent from a lobby kiosk port show up in the finance VLAN | Traffic in a VLAN the port was never assigned to | User ports as access ports, a native VLAN that no user port uses, and unused ports disabled |
| MAC flooding | A device on a conference-room port sends frames from thousands of made-up source MAC addresses | The table may stop learning legitimate addresses; unknown unicast frames may then be flooded within that VLAN | Port security that limits how many MAC addresses a port may learn |
| ARP poisoning and spoofing | A compromised PC keeps answering ARP requests for the gateway's IP address | Hosts map the gateway's IP to the wrong MAC, or one MAC appears for two IPs | NAC and 802.1X to control who connects, segmentation to limit reach, and encryption in transit |
| DNS poisoning and spoofing | Staff who type the payroll site's name land on a look-alike login page | A name resolves to an address the real zone does not publish | DNSSEC validation (objective 3.4), URL and content filtering, and certificate checks |
| Rogue DHCP server | Worked in the next section | Clients get an address, gateway, or DNS server from an unexpected source | Port security, 802.1X, NAC, and unused ports disabled |
| Rogue access point | An employee plugs a home access point into a desk jack for better Wi-Fi | An unknown wireless network bridged into the wired LAN | 802.1X on wired ports, wireless surveys, and unused ports disabled |
| Evil twin | A device in the lobby broadcasts the company's guest network name | Clients join a network with the right name but an unknown BSSID | Enterprise authentication with clients that check the server's certificate, plus surveys |
| On-path attack | Often the result of ARP poisoning, a rogue DHCP gateway, or an evil twin | Traffic passes through a device that should not be in the path | Encryption in transit, such as TLS, SSH, or an IPsec VPN, and certificates from a PKI |
| Social engineering | A caller claiming to be the ISP asks the help desk for the router password. A visitor follows staff through a badge door | Requests that skip the normal process, or people where they should not be | Training, MFA, call-back verification, locks, and cameras |
| Malware | An infected laptop starts scanning its subnet | Unusual connections from one host | Segmentation, content filtering, and device hardening |
Rogue DHCP, worked from symptom to source
Northgate Insurance (a fictional office) uses a central DHCP server for its 10.30.0.0/16 network. One Tuesday, some laptops in the fifth-floor training rooms get normal 10.30.x.x addresses while others get 172.16.99.x addresses with a gateway of 172.16.99.1 that leads nowhere. A contractor had connected a test appliance, with its DHCP server switched on, to a spare jack.
Here is how a technician gets from the symptom to the port:
- Read the lease. On an affected Windows laptop,
ipconfig /alllists the DHCP server that issued the lease. It shows 172.16.99.1, not the corporate server. - Get the MAC address. Ping 172.16.99.1 from that laptop, then run
arp -ato see the MAC address answering for it. - Find the port. On the floor's access switch, look the MAC up in
show mac-address-tableto find the port it was learned on. - Contain it. Shut that port according to your change policy and remove the appliance.
- Fix the clients. Affected laptops release and renew their leases to get correct settings from the real server.
- Prevent the repeat. Disable unused jacks, and require 802.1X or another NAC check before a port passes traffic, to reduce unauthorized access. Also use DHCP snooping on supported switches, trusting only ports toward legitimate DHCP servers; an authenticated device can still run a rogue DHCP service.
Notice that nobody meant harm. Objective 4.2 lists rogue DHCP under rogue devices and services, and an unauthorized server does the same damage either way, because clients usually take the first offer they receive.
The free mixed set of 20 Network+ questions includes a version of this problem set in a meeting room. To see how the distractors differ, try the meeting-room rogue DHCP item in the free Network+ set.
VLAN hopping and native VLAN hygiene
VLAN hopping lets traffic escape the VLAN its port belongs to. Two forms are commonly taught:
- Switch spoofing. A port that is willing to negotiate a trunk becomes one, and the attacker's device now sees every VLAN the trunk carries.
- Double tagging. The attacker sits in the trunk's native VLAN and sends a frame with two 802.1Q tags. The first switch removes the outer tag, because native-VLAN traffic crosses the trunk untagged. The next switch reads the inner tag and delivers the frame into the target VLAN. Replies do not come back the same way, so this works in one direction only.
Both depend on configuration choices you control. Set user ports as access ports and do not let them negotiate trunking. On trunks, use a native VLAN that no user port belongs to, and allow only the VLANs each trunk needs. Disable unused ports. The Network+ switching guide shows the trunk and native VLAN settings on a two-switch office.
MAC flooding, port security, and the err-disabled port
A switch learns which MAC address lives on which port and keeps that list in a table of limited size. MAC flooding fills the table with fake entries. If legitimate destination addresses cannot be learned, unknown unicast frames may be flooded to other forwarding ports in the same VLAN, allowing an attacker there to observe some traffic. Known unicast frames are not automatically all flooded; behavior and protections depend on the switch.
Port security answers this by limiting how many MAC addresses a port may learn and by setting what happens when a frame breaks the limit. Cisco's IOS documentation, updated October 7, 2026, describes one common action. When the secure MAC limit is reached and a frame arrives from an unknown source MAC, the port is shut and shows as err-disabled. Cisco says to fix the cause first, or the port will error-disable again, and then recover it with shutdown followed by no shutdown. Automatic recovery is off by default. Other vendors use different commands and names.
Worked case. A desk port allows two MAC addresses, one for the IP phone and one for the PC behind it. A contractor adds a small unmanaged switch behind the phone to connect a second laptop. The third source MAC triggers a violation, and the port goes err-disabled. Replacing the cable would change nothing. The fix is to remove the extra switch, then re-enable the port under the site's policy.
MAC filtering, also in 4.3, is a list of allowed or blocked addresses. Because MAC addresses can be changed in software, a filter alone is weak, which is why the objectives also list 802.1X, where a device must authenticate before its port passes traffic.
The free set's err-disabled item turns on the same recovery order. When you are ready, check your port-security reasoning on the err-disabled item. Err-disabled, administratively down, and suspended are compared side by side in the cable and interface troubleshooting guide.
ARP and DNS: poisoning versus spoofing
The objectives list ARP poisoning and ARP spoofing separately, and the same for DNS. A common way to separate them is that spoofing is sending the forged message, and poisoning is the corrupted cache that results. A host that answers ARP requests for the gateway is spoofing. Every PC that stores the false mapping has a poisoned ARP cache.
You recognize them by the evidence. For ARP, arp -a on a client, or show arp on the router, shows the gateway's IP with a MAC that does not belong to the gateway, or an unexpected mapping compared with the verified baseline. Two IPs sharing a MAC alone is not proof of poisoning: proxy ARP and legitimate virtual interfaces can produce that pattern. For DNS, compare the suspicious answer with what the zone's authoritative server returns. DNSSEC lets a validating resolver check that answers were signed for the zone. DNSSEC checks authenticity and integrity of signed DNS data; it does not encrypt the query or prove that the named site is safe.
Rogue access point versus evil twin on Network+
The two are easy to swap. A rogue access point is an unauthorized device connected to your network. It opens a wireless door into the wired LAN, often by accident. An evil twin may never touch your network at all. It imitates your network's name so that clients connect to it instead. The first is stopped mainly at the wired port. The second is stopped by authentication that clients can verify and by surveys that spot the unknown BSSID. For zones, ACLs and remote access, see security concepts.
Trust the source
Official sources
Exam policies can change. Use these primary sources for the most current details.