Chapter 5

Network Security and Troubleshooting

CompTIA Network+ (N10-009) Study GuideBased on the CompTIA Network+ N10-009 exam objectives

Every network administrator lives at the intersection of two jobs: keeping the bad guys out and keeping the good guys connected. This chapter is about both. The Network+ N10-009 exam treats security and troubleshooting as deeply related disciplines — and rightly so, because the same knowledge that lets you find an attacker on your network is what lets you find a failed switch port at 2 a.m. An attack and an outage often look identical from the user's perspective ("nothing works"), and the technician who can tell the difference is the one who gets hired.

Know Your Enemy: Common Network Attacks

Before you can defend a network, you have to think the way an attacker thinks. Not because you'll ever attack anyone — but because every defensive technique you'll learn exists as an answer to one of these attacks. CompTIA expects you to know not just the names of these attacks but how they work at the protocol level, what damage they cause, and which countermeasure stops each one. The exam loves scenario questions here: "Users report their banking sessions are being intercepted at a coffee shop" — that's a man-in-the-middle attack, and the answer involves encryption, not a firewall rule.

Denial of Service and Distributed Denial of Service

A denial of service (DoS) attack has one goal: make a service unavailable by overwhelming it. The attacker floods a server, a link, or an application with more traffic than it can handle, so legitimate requests can't get through. A distributed denial of service (DDoS) attack does the same thing but from thousands or millions of compromised devices at once — a botnet — making it far harder to stop, because you can't just block one source IP address.

There are several flavors worth knowing. Volumetric attacks saturate the pipe itself — a SYN flood, for example, sends a barrage of TCP SYN packets and never completes the handshake, filling the server's connection table with half-open connections until it can't accept real ones. Protocol attacks exploit weaknesses in how protocols work — a Smurf attack, for instance, pings a broadcast address with a spoofed source IP (the victim's), so every host on that network replies to the victim and drowns it. Application-layer attacks are the sneakiest: they send seemingly legitimate requests, like thousands of HTTP GET requests to a login page, exhausting the application's resources without ever tripping a simple traffic-volume alarm.

The defense is layered: rate limiting, SYN cookies (the server responds to SYN packets without allocating resources until the handshake completes), upstream filtering by the ISP, content delivery networks and scrubbing centers that absorb attack traffic before it reaches you, and anycast DNS that spreads the target across many servers.

Man-in-the-Middle (MITM)

A man-in-the-middle attack places the attacker silently between two communicating parties. You think you're talking to your bank; you're actually talking to the attacker, who relays your traffic to the bank and back — reading, and possibly modifying, everything in transit. The classic setup is a compromised or fake Wi-Fi network: you connect to "Free_Coffee_Shop_WiFi," the attacker sees every unencrypted packet, and captures session cookies, credentials, and anything else sent in the clear.

The reason MITM works is that most network communication is built on trust: your computer trusts that the gateway it ARPs for is the real router, that the DNS answer it receives is genuine, that the certificate presented by a website is legitimate. Attackers exploit each of these trust points — which is why ARP spoofing and DNS poisoning (covered below) are really just specific techniques for achieving a man-in-the-middle position.

The countermeasures are cryptographic: HTTPS/TLS encrypts the session so the attacker sees only ciphertext, certificate validation catches impostor sites, and VPNs create an encrypted tunnel that protects everything inside it even on a hostile network.

Rogue Access Points and Evil Twins

A rogue access point is any unauthorized wireless access point on your network. Sometimes it's innocent — an employee plugs in a $30 home router so their phone gets better signal, unknowingly punching a hole through every firewall rule the company owns. Sometimes it's malicious — an attacker sets up an access point with the same SSID as the corporate network, an evil twin, and waits for devices to connect automatically.

Evil twins work because of how Wi-Fi clients behave: your phone remembers network names, not access points. If you've ever connected to "CorpWiFi," your phone will happily join any access point broadcasting "CorpWiFi" — including the attacker's laptop in the parking lot. Once connected, the attacker is in a perfect man-in-the-middle position.

The defense starts with a wireless intrusion detection/prevention system (WIDS/WIPS) that continuously scans the airwaves and alerts on (or automatically deauthenticates clients from) unauthorized access points. Equally important are the unglamorous controls: 802.1X authentication (covered below) means that even if a rogue AP exists, clients can't authenticate to it without valid credentials; and mutual authentication (EAP-TLS, for example) means the client verifies the network too, not just the other way around.

VLAN Hopping

VLANs segment a switched network into separate broadcast domains — the sales team can't see the engineering team's traffic. VLAN hopping is an attack that defeats this segmentation, letting an attacker on one VLAN reach another.

The most common technique is switch spoofing: the attacker configures their machine to speak DTP (Dynamic Trunking Protocol), the protocol switches use to negotiate trunk links, and tricks the switch into treating the attacker's port as a trunk. Once the port is a trunk, it carries traffic for all VLANs, and the attacker can see everything. The second technique is double tagging: the attacker crafts a frame with two 802.1Q VLAN tags. The first switch strips the outer tag (thinking it's the frame's VLAN) and forwards the frame — with the inner tag now exposed — to the victim VLAN.

The fixes are straightforward and heavily tested: disable DTP and set all access ports to a fixed access mode (never leave ports in dynamic auto/desirable), never use VLAN 1 (the default native VLAN) for user traffic, and explicitly tag the native VLAN or change it to an unused VLAN ID.

ARP Spoofing (ARP Poisoning)

ARP — the Address Resolution Protocol — maps IP addresses to MAC addresses on a local network, and it has a fatal flaw: it trusts everyone. When your computer needs to send a packet to the gateway at 192.168.1.1, it broadcasts "Who has 192.168.1.1?" and believes whoever answers. An attacker running ARP spoofing software answers every ARP request with their own MAC address, poisoning the ARP caches of victims so that traffic meant for the gateway flows through the attacker's machine first. Congratulations: the attacker now has a man-in-the-middle position on a wired network, no fake Wi-Fi required.

You'll notice this attack has the same shape as several others — exploiting unauthenticated trust. The countermeasures: Dynamic ARP Inspection (DAI), a switch feature that validates ARP packets against the DHCP snooping binding table and drops spoofed ones, and static ARP entries for critical hosts (impractical at scale but bulletproof for a gateway).

DNS Poisoning (DNS Spoofing)

DNS translates names to IP addresses, and like ARP, classic DNS trusts too easily. In DNS poisoning, the attacker injects false DNS records into a resolver's cache — so when your computer asks "where is mybank.com?", the poisoned resolver answers with the attacker's IP address. You type the correct URL, your browser shows the correct URL, and you're on the attacker's server. Combined with a convincing fake login page, this is one of the most effective credential-theft techniques in existence.

The Kaminsky attack of 2008 famously showed how predictable DNS transaction IDs made cache poisoning practical at scale, and the industry responded with source port randomization and, more fundamentally, DNSSEC — cryptographic signatures on DNS records that let resolvers verify an answer actually came from the authoritative server.

Building the Fortress: Network Hardening Techniques

Knowing the attacks is half the battle. The other half is the set of techniques — collectively called hardening — that make those attacks fail. Hardening is never one product; it's the combination of segmentation, access control, authentication, and encryption, each covering the gaps the others leave.

Network Segmentation

Segmentation is the single most powerful defensive concept in networking: divide the network into isolated zones so that a compromise in one zone can't spread to the others. If the guest Wi-Fi, the point-of-sale terminals, the servers, and the workstations all live on one flat network, one infected laptop can reach everything. Segment them — with VLANs, with separate subnets, with firewall rules between zones — and the blast radius of any incident shrinks dramatically.

Segmentation serves two masters: security and performance. Security, because east-west traffic (between zones) can be inspected and filtered. Performance, because broadcast domains stay small and a broadcast storm in one segment doesn't take down the whole building.

Access Control Lists (ACLs)

An access control list is a set of ordered rules applied to a router or firewall interface that permits or denies traffic based on source and destination addresses, protocols, and ports. ACLs are the bouncers of the network: "traffic from the guest VLAN to the server VLAN on port 3380? Denied. Traffic from the workstation VLAN to the internet on port 443? Permitted."

The critical detail — and the source of half the exam questions on this topic — is that ACLs are processed top-down, first match wins, and there is an implicit deny at the end. That means rule order matters enormously: a broad "deny" placed above a specific "permit" will block traffic you intended to allow. The standard practice is to write specific rules first and general rules last, and to always account for the invisible "deny everything not explicitly permitted" at the bottom.

Port Security and 802.1X

A switch port in a lobby or conference room is a physical invitation: plug in, get on the network. Port security is the switch's answer — it restricts which MAC addresses may use a port. You can configure a port to learn and lock to the first MAC it sees (sticky MAC), to allow only a manually specified MAC, and to define a maximum number of MAC addresses. When a violation occurs, you choose the response: protect (drop the offending traffic silently), restrict (drop it and log/SNMP-trap the event), or shutdown (disable the port entirely until an administrator re-enables it — the err-disable state).

Port security stops casual intruders, but MAC addresses can be spoofed, so for real authentication the industry uses 802.1X — port-based network access control. With 802.1X, a port starts in an unauthorized state and only opens after the connecting device authenticates, typically against a RADIUS server, using an EAP method. The three roles are worth memorizing: the supplicant (the device trying to connect), the authenticator (the switch or access point enforcing the decision), and the authentication server (usually RADIUS, which checks the credentials).

Firewalls: Stateful vs. Stateless, and Security Zones

A firewall filters traffic between networks according to a rule set — but not all firewalls think the same way. A stateless firewall examines each packet in isolation: source, destination, port, protocol — permit or deny, no memory of what came before. It's fast and simple, and it's how basic ACLs on routers work. A stateful firewall keeps a state table of active connections: when your workstation initiates an outbound HTTPS session, the firewall records it and automatically permits the return traffic, even though no explicit inbound rule allows it. Stateful inspection understands context — it knows that an inbound packet on port 443 is the legitimate reply to your request, not an unsolicited probe.

Modern networks organize firewalls around security zones: the untrusted internet (WAN/outside), a DMZ (demilitarized zone) for public-facing servers like web and mail, and the trusted internal LAN. Traffic rules flow from the zone model — internet to DMZ is permitted for specific services, internet to LAN is denied, LAN to internet is permitted, and DMZ to LAN is denied or tightly restricted. The DMZ exists for a painful historical reason: public servers get compromised, and when they do, you don't want the attacker one hop from your database.

VPNs: IPsec vs. SSL/TLS

A virtual private network extends a private network across a public one by encrypting a tunnel between two endpoints. The two dominant technologies work at different layers and serve different use cases.

IPsec operates at the network layer (Layer 3). It can run in transport mode (encrypting only the payload, host to host) or tunnel mode (encrypting the entire original packet, gateway to gateway — the classic site-to-site VPN between two offices). IPsec uses two core protocols: AH (Authentication Header), which provides integrity and authentication but no encryption, and ESP (Encapsulating Security Payload), which provides encryption plus integrity and authentication. In practice, ESP in tunnel mode is the workhorse of site-to-site VPNs. IPsec typically requires client software and pre-shared keys or certificates, and it can struggle with NAT — which is why NAT traversal (NAT-T, UDP port 4500) exists.

SSL/TLS VPNs operate higher up the stack and are the technology behind the "VPN portal" remote workers use: open a browser, log in, and get access to internal resources — often with no dedicated client software at all (clientless) or a lightweight agent. Because TLS runs over TCP 443, it sails through firewalls and NAT that would block IPsec's protocols.

The comparison the exam wants: IPsec is the choice for site-to-site tunnels (always-on, gateway to gateway); SSL/TLS VPN is the choice for remote-access/client-to-site scenarios (a traveling employee connecting from a hotel).

The Six Steps That Fix Everything: Troubleshooting Methodology

CompTIA's troubleshooting methodology has six steps, and the exam treats them as doctrine — not suggestions. Memorize them in order, because the exam will describe a technician's actions and ask which step they're on, or present the steps out of order and ask you to fix the sequence:

1. Identify the problem. Gather information, question users, identify symptoms, determine if anything changed recently. The most skipped step and the most important one — half of all "network outages" turn out to be a user who can't remember their password or a cable someone kicked loose during cleaning.
2. Establish a theory of probable cause. Based on the symptoms, form a hypothesis. Question the obvious first: is it plugged in? Is the link light on? Then work up the OSI model — physical, then data link, then network, and so on.
3. Test the theory to determine the cause. Don't just start changing things. If you suspect a bad cable, test with a known-good cable or a cable tester. If you suspect DNS, try pinging by IP address — if the IP works but the name doesn't, your theory is confirmed.
4. Establish a plan of action and identify potential effects. Before you implement the fix, think about what could go wrong. Rebooting the core switch at noon will fix the hung process — and disconnect four hundred people. Schedule it, warn people, have a rollback plan.
5. Implement the solution or escalate. Apply the fix — or escalate to the next tier if it's beyond your authority or expertise. Escalation isn't failure; it's the process working.
6. Verify full system functionality and implement preventive measures. Confirm the fix actually worked (have the user test, don't just assume), and then make sure it doesn't happen again: document the incident, update the runbook, replace the failing hardware, add monitoring.

Notice what's embedded in this process: change management (step 4), humility (step 5 — escalate when stuck), and institutional learning (step 6 — document). The exam loves step 4 in particular: scenarios where a technician "fixed" something but caused a bigger outage almost always trace back to skipping the plan-of-action step.

Your Toolbox: The Commands That Diagnose Everything

Theory is necessary; tools are what actually find the problem. The Network+ exam expects hands-on familiarity with these utilities — what each one does, what its output means, and which to reach for first in a given scenario.

ping and traceroute (tracert)

ping uses ICMP echo requests to test basic connectivity: can I reach this host, and how long does the round trip take? It's always the first tool you reach for. But ping's real diagnostic power is in what its failures tell you: "Request timed out" means no reply at all (host down, or ICMP blocked); "Destination host unreachable" means a router along the path couldn't deliver it; high or wildly varying latency points to congestion or a failing link.

traceroute (tracert on Windows) maps the path packets take by manipulating the TTL field — sending packets with TTL 1, 2, 3, and so on, and recording which router's "time exceeded" message comes back at each hop. When users say "the internet is slow," traceroute shows you exactly which hop the latency appears at.

nslookup and dig

When ping by IP works but ping by name fails, the problem is DNS — and nslookup (Windows and Unix) is how you interrogate it. nslookup queries a DNS server directly: nslookup certcrack.com shows you which server answered and what IP it returned. dig (Unix/Linux) does the same with more detail — query time, which server responded, the full answer section. Both let you query a SPECIFIC DNS server (nslookup certcrack.com 8.8.8.8), which is how you determine whether the problem is your local resolver or DNS in general.

netstat and ss

netstat shows active connections, listening ports, and the routing table — it's how you answer "what is this machine actually talking to?" Seeing an unexpected listening port is often the first sign of malware; seeing hundreds of connections in SYN_SENT state points to a SYN flood or a misbehaving application. On modern Linux systems, ss has largely replaced netstat (same information, faster), but the exam still says netstat.

ipconfig and ifconfig/ip

ipconfig (Windows) and ifconfig or the modern ip command (Linux) show a host's network configuration: IP address, subnet mask, default gateway, DNS servers. The variants matter: ipconfig /all shows everything including MAC addresses and DHCP lease details; ipconfig /release and /renew force a fresh DHCP lease (the classic fix for an APIPA 169.254.x.x address, which means DHCP failed); ipconfig /flushdns clears the resolver cache. When a user "can't get on the network," ipconfig is step one — a 169.254 address tells you the whole story in three seconds.

Wireshark: Seeing the Invisible

Wireshark is a packet analyzer — it captures the actual frames flowing across a network interface and lets you inspect them protocol by protocol, byte by byte. It's the ultimate diagnostic tool and the ultimate privacy lesson: on an unencrypted network, Wireshark shows you everything — usernames, passwords, emails — which is exactly why encryption matters.

For the exam, know the fundamentals: Wireshark captures packets (you need to be in the traffic path — via port mirroring/SPAN or a tap — because switches don't forward other ports' traffic to you by default), it applies capture filters (limit what gets recorded, using BPF syntax) and display filters (limit what's shown from an existing capture), and it can follow TCP streams to reconstruct a full conversation.

Wired Troubleshooting: When the Cable Is the Suspect

Wired problems live mostly at Layers 1 and 2, and they have a distinctive smell: one user down, one port down, one run of cable down. The methodology says start at the physical layer, and wired troubleshooting is where that advice pays off most.

No link light is the purest Layer 1 symptom. Check the obvious: is the cable plugged in at both ends? Is the switch port enabled (not err-disabled from a port-security violation)? Try a known-good cable, try a different port. If the link light comes on with a different cable, you've found it — and you've also learned to distrust every cable in that batch.

Intermittent connectivity — works, drops, works — usually means a marginal cable (a kink, a staple through the jacket, a run that's 120 meters instead of the 100-meter limit), a duplex mismatch (one side auto-negotiated to half duplex while the other is full — the classic cause of terrible performance on a link that "works"), or a failing NIC. Check the interface error counters: CRC errors point to the cable or interference; collisions on a full-duplex link point to a duplex mismatch.

"Connected but no internet" on a wired client moves you to Layer 3: check ipconfig — APIPA address means DHCP failed (is the DHCP server up? is the helper address configured on the router?); correct IP but no gateway means a misconfiguration; correct everything but no name resolution means DNS. The pattern is always the same: verify each layer before moving up.

Wireless Troubleshooting: When the Air Is the Problem

Wireless adds a physical medium you can't see, which makes troubleshooting feel like guesswork until you learn the patterns. The exam concentrates on a handful of scenarios:

Can't connect at all: Is the SSID correct (and is it hidden, requiring manual entry)? Is the security type right — WPA2 vs. WPA3, and is the client old enough to lack WPA3 support? Wrong passphrase is the number one cause, and it's case-sensitive. On enterprise networks, check whether the client's certificate for 802.1X authentication has expired.

Connected but slow or dropping: This is the interference chapter. The 2.4 GHz band has only three non-overlapping channels (1, 6, 11) — neighboring access points on overlapping channels degrade everyone. Microwaves, Bluetooth, baby monitors, and cordless phones all live in 2.4 GHz. The fix is a site survey and proper channel planning, moving clients to 5 GHz or 6 GHz where there's more spectrum, and checking for channel overlap and signal-to-noise ratio. Also consider capacity: one access point serving fifty streaming users will be slow no matter how clean the spectrum is.

Connected to the wrong network / keeps disconnecting: Devices aggressively roam and sometimes cling to a distant AP with a weak signal instead of roaming to a closer one (the "sticky client" problem). Wrong SSID selection, band steering misconfiguration, or an evil twin (see the security section — wireless troubleshooting and wireless security overlap constantly) are all in play.

End-of-Chapter Test

1. An administrator notices thousands of devices sending traffic to the company's web server simultaneously, making it unavailable to legitimate users. This is BEST described as:

• A. A man-in-the-middle attack
• B. A distributed denial of service attack
• C. ARP spoofing
• D. DNS poisoning

2. Users report that when they type the correct URL for their bank, they are taken to a fraudulent login page. The issue affects the entire office network. This MOST likely indicates:

• A. A rogue access point
• B. DNS poisoning
• C. VLAN hopping
• D. A duplex mismatch

3. Which of the following is the BEST defense against VLAN hopping via switch spoofing?

• A. Enabling DHCP snooping
• B. Disabling DTP and configuring ports as static access ports
• C. Implementing DNSSEC
• D. Enabling port mirroring

4. A company needs an always-on encrypted connection between its headquarters and a branch office. Which VPN solution is MOST appropriate?

• A. SSL/TLS remote-access VPN
• B. IPsec site-to-site VPN in tunnel mode
• C. Point-to-point T1 line
• D. Split-tunnel VPN client

5. A technician wants to ensure that only authenticated users — not just recognized devices — can connect to the wired corporate network. Which technology should be implemented?

• A. Port security with sticky MAC addresses
• B. 802.1X with a RADIUS server
• C. A stateless packet-filtering firewall
• D. Dynamic ARP Inspection

6. A network administrator adds a "permit" rule to an ACL, but the traffic is still being blocked. Which of the following is the MOST likely cause?

• A. The firewall is stateful instead of stateless
• B. An earlier "deny" rule matches the traffic first, or the implicit deny is blocking it
• C. The VPN tunnel is down
• D. The DNS cache needs to be flushed

7. During troubleshooting, a technician determines that pinging a server by IP address works, but pinging it by hostname fails. Which tool should the technician use NEXT to diagnose the issue?

• A. traceroute
• B. netstat
• C. nslookup
• D. ipconfig /release

8. A user on a wired connection reports very slow network performance even though the link shows as connected. The workstation's NIC was recently set to 100 Mbps full duplex manually. What is the MOST likely cause?

• A. DNS poisoning
• B. A duplex mismatch from auto-negotiation failure on the switch side
• C. An evil twin access point
• D. A DHCP scope exhaustion

9. Following the CompTIA troubleshooting methodology, what should a technician do AFTER testing a theory but BEFORE implementing the solution?

• A. Escalate to the next tier
• B. Establish a plan of action and identify potential effects
• C. Verify full system functionality
• D. Document the findings

10. Users complain that the office Wi-Fi is slow, but wired connections are fast. A scan shows several neighboring access points using channels 2, 3, and 4 near the office AP on channel 1. What is the BEST next step?

• A. Replace the internet router
• B. Move the office AP to channel 6 or 11 and plan for 5 GHz migration
• C. Disable WPA3 on the access point
• D. Increase the DHCP lease time

---

Answer Key

1. B — Traffic from thousands of devices simultaneously overwhelming a server is the definition of a distributed denial of service (DDoS) attack. A single-source flood would be a DoS; the botnet scale makes it distributed.

2. B — Correct URL but wrong destination across an entire network points to DNS poisoning — the resolver's cache has been corrupted with the attacker's IP. A rogue AP would affect wireless clients joining it, not the whole office.

3. B — Switch spoofing relies on DTP negotiation to turn an access port into a trunk. Disabling DTP and hard-setting ports to access mode removes the attack vector entirely.

4. B — Always-on, gateway-to-gateway connectivity between sites is the textbook use case for an IPsec site-to-site VPN in tunnel mode. SSL/TLS VPNs are for remote-access scenarios with individual users.

5. B — 802.1X authenticates users (via credentials or certificates against RADIUS) before opening the port. Port security only checks MAC addresses, which identify devices — and MACs can be spoofed.

6. B — ACLs are processed top-down with first-match-wins, plus an implicit deny at the end. Either an earlier deny rule is catching the traffic, or no rule permits it and the implicit deny drops it.

7. C — IP works but name fails means DNS is the problem. nslookup (or dig) queries DNS servers directly and will reveal whether the resolver is returning bad answers or not answering at all.

8. B — Manually setting one side to full duplex while the other side auto-negotiates typically results in the auto side falling back to half duplex — a duplex mismatch that causes collisions, retransmissions, and terrible performance on a "working" link.

9. B — The methodology order is Identify, Theory, Test, Plan, Implement, Verify. Establishing a plan of action (including potential effects and rollback) comes after testing the theory and before implementing the solution.

10. B — Channels 2, 3, and 4 overlap with channel 1, causing interference. The 2.4 GHz non-overlapping channels are 1, 6, and 11 — moving to 6 or 11 (and planning 5 GHz migration for more spectrum) resolves the congestion.