Network Security Basics — Attacks and the Defences That Stop Them

What you'll learn

• The vocabulary of security: assets, threats, vulnerabilities, risk and the CIA triad
• How spoofing works at each layer (IP, MAC, ARP, DNS) and what stops it
• How a man-in-the-middle gets into the path, and why encryption with proper authentication defeats it
• The kinds of denial of service, and defences such as SYN cookies, rate limiting and filtering
• How port scans look in your logs and how to detect them
• The principles every security design is built on: least privilege, segmentation and defence in depth
• You will build three defensive tools: an ARP spoofing monitor, a token-bucket rate limiter and a port-scan detector

⚠️ The line that matters: this lesson explains attacks so you can recognise and stop them. Scanning, spoofing or flooding systems you do not own, or do not have written permission to test, is a crime in most countries, even "just to see". Practise only in your own lab. Every log and address in this lesson is made up.

The castle 🏰

A medieval castle did not rely on one wall. It had a moat, an outer wall, a gate with guards who checked everyone, an inner wall, and a keep where the treasure was. Soldiers could only enter the rooms their duty required. If attackers crossed the moat, the wall stopped them; if they climbed the wall, the guards saw them. That is defence in depth, and it is still the best mental model for network security: no single control is perfect, so you stack several, each one covering the others' gaps.

The vocabulary

• An asset is something worth protecting: customer data, a payment service, the availability of a website.
• A threat is something that could harm it: a criminal group, a careless insider, a flood.
• A vulnerability is a weakness a threat can use: an unpatched service, a weak Wi-Fi password, a flat network.
• Risk combines how likely harm is with how bad it would be. Security work is about reducing risk to an acceptable level, never to zero.

The CIA triad names what you protect: confidentiality (only the right people can read it), integrity (nobody can change it unnoticed) and availability (it works when needed). Each attack in this lesson aims at one or more of them: eavesdropping at confidentiality, spoofing and man-in-the-middle at integrity (and usually confidentiality), denial of service at availability.

Spoofing: lying about who you are

Spoofing means forging an identity field so a packet seems to come from someone else. It exists at every layer because the basic protocols trust what they are told.

• IP spoofing. Anyone can write any source address into a packet they build. Replies go to the forged address, so the attacker never sees them; that is why spoofing is useful for one-way attacks (floods and reflection, below) and hard against TCP from outside the path, where the attacker would have to guess the server's unpredictable initial sequence number (RFC 6528). The defence is ingress and egress filtering at network edges (BCP 38, RFC 2827): an ISP drops customer packets whose source is not the customer's prefix, and a network drops incoming packets that claim to come from its own addresses. Unicast reverse path forwarding (uRPF, BCP 84) automates the check with the routing table.
• MAC spoofing. Changing a network card's MAC address is one command, so "only allow these MAC addresses" is not authentication. Use 802.1X port authentication instead.
• ARP spoofing (ARP poisoning). Because ARP has no authentication, a device on the LAN can send replies saying "the gateway 192.168.1.1 is at my MAC". Victims update their caches and send their Internet traffic to the attacker, who forwards it on: a man-in-the-middle. Defences: switches with Dynamic ARP Inspection (which checks ARP against the DHCP snooping table), static entries for critical hosts, 802.1X, monitoring for changed mappings, and above all encryption, so intercepted traffic is useless.
• DNS spoofing (cache poisoning). An attacker races the real answer with forged ones, hoping a resolver caches the lie. Since the attacks published in 2008, resolvers randomise the query ID and source port, which makes blind guessing far harder; DNSSEC validation lets a resolver reject forged records outright, and DNS over TLS or HTTPS protects the path between you and your resolver.

Man-in-the-middle: getting into the path

A man-in-the-middle (MITM) attacker sits between two parties, reading and possibly changing what they say, while each side believes it talks directly to the other. Ways into the path include ARP spoofing on a LAN, a rogue Wi-Fi access point with a familiar name (an "evil twin"), a rogue DHCP server that hands out the attacker as gateway or DNS server, a compromised home router, and at Internet scale a BGP hijack of someone's prefix.

You cannot always keep attackers out of the path, so the defence is to make the path not matter: end-to-end encryption with authentication.

• TLS with certificate validation. An attacker in the middle can relay bytes but cannot produce a valid certificate for the real name. That only works if clients refuse invalid certificates: never click through a certificate warning on a network you do not trust.
• HSTS (RFC 6797). A site can tell browsers "only ever use HTTPS with me", which defeats SSL stripping, where the attacker quietly downgrades the first plain-HTTP request.
• SSH host keys. The first connection records the server's key in known_hosts; a later warning that the key changed may mean an interception.
• VPNs and WPA3 or 802.1X protect the local hop on networks you do not control, and DHCP snooping on switches stops rogue DHCP servers.

The mindset to take away: assume the network is hostile and protect the data itself.

Denial of service: knocking it over

A denial-of-service (DoS) attack attacks availability. When it comes from many machines at once (usually a botnet of hijacked devices) it is a distributed DoS (DDoS). There are three broad kinds:

• Volumetric: more traffic than the links can carry. Reflection and amplification make this cheap: the attacker sends small UDP requests to open servers (DNS, NTP, memcached and others) with the victim's address spoofed as the source, and the servers send much larger replies to the victim. CISA's alert TA14-017A lists the amplification factors per protocol. Defences sit upstream: ISP filtering, scrubbing services, CDNs and anycast networks that spread the flood over many sites, plus BCP 38 everywhere and closing open resolvers.
• Protocol / state exhaustion: using up a table rather than bandwidth. A SYN flood sends many SYNs (often spoofed) and never completes the handshake, so the server's queue of half-open connections fills and real clients are refused. SYN cookies (RFC 4987) answer by encoding the connection details in the server's initial sequence number, so no state is stored until the client's final ACK proves it is real.
• Application layer: expensive requests (search pages, logins) or deliberately slow ones that tie up workers. Defences include rate limiting per client, caching, timeouts and challenge pages.

Rate limiting is usually done with a token bucket: each client has a bucket that holds up to burst tokens and refills at rate tokens per second; every request spends one token, and a request that finds the bucket empty is dropped (or delayed). Short bursts are allowed, sustained floods are not.

Port scanning and how to see it

Before an attack comes reconnaissance: finding which hosts are up and which services they run. A port scan tries many ports and classifies them by the reply, using exactly what you learned in the TCP and troubleshooting lessons. A tool such as nmap reports:

• open: a SYN-ACK came back, so a service is listening;
• closed: a RST came back, so the host is up but nothing listens there;
• filtered: no answer, or an ICMP unreachable, so a firewall is in the way.

Scanning someone else's network without permission can be illegal and often breaks the provider's terms of service. Scanning your own network regularly is good practice: it shows you what an attacker would see, and ss -tlnp on each server tells you which program is behind each open port.

To detect scans, look at connection logs from a firewall or an IDS (Snort, Suricata) or a network monitor (Zeek). A normal client talks to a few services; a scanner touches many distinct targets in a short time:

• a vertical scan probes many ports on one host;
• a horizontal scan (a sweep) probes one port, say 22 or 3389, on many hosts;
• a mixed scan does both.

Counting distinct (host, port) pairs per source in a sliding time window catches most of this. It also has blind spots: a slow scan that sends one probe a minute stays under any short-window threshold, and some legitimate systems (monitoring servers, vulnerability scanners you run yourself) look exactly like scanners, so they need an allow list. Detection only helps if someone acts on it: block or rate-limit the source, check what it reached, and close ports that never needed to be open.

The principles behind every defence

Individual attacks change every year; these principles do not.

• Least privilege. Every user, program and network flow gets only the access its job needs, and nothing more. A web server can reach the database port, not SSH on every machine. Administrators use separate accounts with multi-factor authentication, and management interfaces are reachable only from a management network or through a VPN.
• Segmentation. Divide the network into zones (users, servers, guests, IoT, management, the DMZ) and allow only the flows between them that are needed. A compromised printer should not be able to talk to the finance server. Taken further, zero trust (NIST SP 800-207) stops granting trust because of network location at all: every request is authenticated and authorised, wherever it comes from.
• Defence in depth. Layer independent controls so that one failure is not a disaster:

perimeter      firewall, DDoS protection, filtering (BCP 38)
network        segmentation, VLANs, 802.1X, WPA3, DHCP snooping, DAI
host           patching, host firewall, closed unused ports, endpoint protection
application    TLS everywhere, authentication, input validation, rate limiting
data           encryption at rest, backups you have tested
people         training, least privilege, multi-factor authentication
detection      logs, IDS, alerts that someone actually reads, an incident plan

Add secure defaults (deny unless allowed, services off unless needed), attack surface reduction (every open port and every installed service is something to defend) and monitoring with a response plan, because prevention eventually fails and the question becomes how fast you notice. With this vocabulary you are ready for any security specialty; the Cyber Security track on this site builds on exactly these ideas.

Recap

• Security protects confidentiality, integrity and availability; risk is likelihood times impact, reduced, never zero.
• Spoofing forges identities: IP (stopped by BCP 38 filtering and uRPF), MAC (use 802.1X), ARP (Dynamic ARP Inspection, monitoring, encryption) and DNS (randomised IDs and ports, DNSSEC).
• Man-in-the-middle attacks are defeated by end-to-end encryption with authentication: TLS with certificate validation, HSTS, SSH host keys, VPNs.
• DoS/DDoS: volumetric floods and amplification (filter upstream, CDNs, anycast), state exhaustion (SYN cookies), application floods (rate limiting with token buckets).
• Port scans show up as many distinct targets per source in a short window; slow scans and legitimate scanners are the blind spots.
• Build on least privilege, segmentation and defence in depth, with secure defaults and monitoring that someone acts on.

Practice next: in a lab you own (two virtual machines are enough), scan one from the other with nmap and find the scan in the target's firewall log, then enable rate limiting and see it in action. You have finished the core of the networking track; cloud networking (VPCs, subnets and security groups) is the natural next step, and the Cloud Networking lesson of the Cloud Computing track on this site covers it.