Networking for
Security Practitioners

Before we look at firewalls, encryption, or attack techniques, we need a mental model for what a network actually is and how it moves information. Most networking explanations start with the technical machinery. This one starts with something you've done a thousand times: loading a webpage.

What Actually Happens When You Load a Webpage

You open a browser and type https://example.com. The page appears in about 200 milliseconds. In those 200 milliseconds, an extraordinary chain of events occurs — each one an opportunity for security controls to operate, or for attackers to interfere.

1. Your browser asks "where is example.com?" — It doesn't know the address yet. It sends a query to a DNS server (think of it as a phone book lookup) asking "what's the phone number for example.com?" The DNS server replies with an IP address like 93.184.216.34. This is the address your computer will actually connect to.
2. Your computer opens a connection to that address — It initiates a TCP connection (think of it as making a phone call) to port 443 (the standard HTTPS port) on 93.184.216.34. Three messages are exchanged to establish the connection.
3. Your computer and the server agree on how to encrypt the conversation — A TLS handshake negotiates the encryption that will protect the subsequent communication. This happens before any of the actual webpage content is transferred.
4. Your browser asks for the page — It sends an HTTP GET request: "please give me the content at /". This request travels encrypted through the TLS connection.
5. The server sends the page back — The HTML, CSS, images, and JavaScript files that make up the page are sent back in one or many responses, also encrypted.
6. Your browser renders the page — It assembles everything it received into the visual page you see.

Every one of those steps is a distinct networking action, using distinct protocols, with distinct security implications. DNS lookups can be intercepted and falsified. TCP connections can be hijacked. TLS can be downgraded or impersonated. HTTP requests can reveal sensitive data if the connection isn't encrypted. Understanding networks for security means understanding each of these steps and what can go wrong at each one.

The OSI Model — A Diagnostic Framework, Not an Exam Topic

Every networking curriculum introduces the OSI (Open Systems Interconnection) model — seven layers, memorised by students in every CompTIA study guide. Most practitioners remember the layers but struggle to explain why they matter. Here's the honest answer: the OSI model is not a description of how real networks are built. It's a diagnostic framework — a way of thinking about "where in the stack is this problem?"

For security practitioners, three layers matter most in daily work:

• Layer 3 — Network (IP): addresses and routing. Where IP addresses live, where routing decisions happen, where firewalls filter based on source and destination IP. Most network-level attacks (IP spoofing, route hijacking) operate here.
• Layer 4 — Transport (TCP/UDP): connections, ports, and reliability. Where firewalls filter by port number, where TCP connection state is tracked, where port scanning operates.
• Layer 7 — Application (HTTP, DNS, SMTP, etc.): the actual content and protocol logic. Where SQL injection, XSS, and CSRF live. Where application firewalls (WAFs) operate. Where most modern attacks that aren't pure network-layer attacks occur.

Layers 1 (Physical — the cable or radio wave) and 2 (Data Link — the Ethernet frame moving between directly-connected devices) matter for wireless security and certain physical attacks but are less frequently the focus of application security work. Layers 5 and 6 (Session and Presentation) are largely abstracted into the application layer in real TCP/IP networks.

Packets, Frames, and Why the Distinction Matters

The distinction between packet and frame is about scope. A frame moves between two directly-connected devices — your laptop to your home router, or your router to your ISP's router. Every time a frame crosses a router, it's unwrapped, the IP packet inside is examined, a new frame is wrapped around it with the next-hop's address, and it's sent on its way. The IP packet inside (the actual data with source and destination IP addresses) travels unchanged through the network. The frames wrapping it change at every hop.

For security analysis, this distinction matters because: capturing traffic on your local network shows you frames, which include MAC addresses (Layer 2 physical device identifiers) alongside IP addresses. Traffic captured at a different network segment may show different source addresses even for the same communication, depending on NAT and routing.

IP addresses are the mailing addresses of the internet. Every device that communicates on a network needs one. Understanding how addresses work, how they are divided into groups (subnets), and how to calculate exactly which addresses belong to which subnet is foundational — and it is a skill that security practitioners use constantly. Every firewall rule, every security group, every network diagram references IP ranges. Getting comfortable with subnetting arithmetic removes a daily friction point and makes you faster at almost everything else in network security.

IPv4 Addresses — The Basics

An IPv4 address is 32 bits long, written as four groups of 8 bits (an "octet") in decimal notation separated by dots. The range of each octet is 0–255 because 8 bits can represent 256 values (2⁸ = 256). The total IPv4 address space is 2³² = approximately 4.3 billion unique addresses.

CIDR Notation — What the Slash Really Means

CIDR (Classless Inter-Domain Routing) notation is written as an IP address followed by a slash and a number — for example, 192.168.1.0/24. The number after the slash is called the prefix length. It tells you exactly how many bits from the left side of the address are the network portion. Everything remaining is the host portion.

The Subnet Mask — The Other Way of Writing the Same Thing

Before CIDR became universal, networks described their split using a subnet mask — a 32-bit number where every network bit is a 1 and every host bit is a 0. The /24 in CIDR notation is the same as the subnet mask 255.255.255.0 — because 24 ones followed by 8 zeros, written as four octets, gives 11111111.11111111.11111111.00000000 = 255.255.255.0.

The Four Key Subnet Values — And How to Find Them

Given any IP address and CIDR prefix, you need to be able to find four values: the Network Address, the First Usable Host, the Last Usable Host, and the Broadcast Address. These four define the subnet completely. Let's build a reliable method for finding them without binary arithmetic — using the "block size" shortcut that works for the most common subnets.

The Block Size Method — Quick Subnetting Without Binary

The block size is the number of addresses in a subnet. For subnets that sit entirely within the last octet (prefix /25 through /30), you can calculate the network address quickly:

1. Calculate the block size: 256 − subnet mask's last octet value
   For /26: last octet of 255.255.255.192 is 192. Block size = 256 − 192 = 64
2. Find which block the IP falls in: divide the IP's last octet by the block size (round down to nearest whole multiple)
   IP is .100: 100 ÷ 64 = 1 remainder 36 → nearest multiple below 100 is 1 × 64 = 64
3. Network address: replace the last octet with that multiple → .64
4. Broadcast: network last octet + block size − 1 → 64 + 64 − 1 = 127
5. First usable: network address + 1 → .65
6. Last usable: broadcast − 1 → .126

When the Subnet Boundary Crosses Octets

For prefixes between /17 and /23, the interesting bits are in the third octet. The same block-size method applies — just work on the third octet instead of the fourth.

The /24 Special Case — Always Quick

The /24 is by far the most common subnet in enterprise environments, and it's the easiest to work with. With a /24, the entire fourth octet is the host portion, and the first three octets are fixed as the network. The results are always:

• Network: X.X.X.0
• First usable: X.X.X.1
• Last usable: X.X.X.254
• Broadcast: X.X.X.255
• Usable hosts: 254

Practice Problems

Work through these before moving on. Cover the answers and check your work:

Number of Usable Hosts — The Formula

The formula is simple: 2ʰ − 2, where h is the number of host bits (32 minus the prefix length). We subtract 2 to exclude the network address and the broadcast address.

• /24 → 8 host bits → 2⁸ − 2 = 254 usable hosts
• /25 → 7 host bits → 2⁷ − 2 = 126 usable hosts
• /26 → 6 host bits → 2⁶ − 2 = 62 usable hosts
• /27 → 5 host bits → 2⁵ − 2 = 30 usable hosts
• /28 → 4 host bits → 2⁴ − 2 = 14 usable hosts
• /29 → 3 host bits → 2³ − 2 = 6 usable hosts
• /30 → 2 host bits → 2² − 2 = 2 usable hosts (point-to-point links)

Choosing a Subnet — How Many Hosts Do You Need?

The reverse question is equally common: given a number of hosts you need to support, what prefix length should you use? The answer is: find the smallest power of 2 that is greater than (hosts + 2), then subtract that exponent from 32.

Private Address Ranges (RFC 1918)

Three address ranges are reserved for private use — they are used inside organisations and cloud VPCs but are never routed on the public internet:

• 10.0.0.0/8 — 16,777,216 addresses. Large enterprises and cloud VPCs.
• 172.16.0.0/12 (172.16.x.x through 172.31.x.x) — 1,048,576 addresses. Often used for Docker and Kubernetes networking.
• 192.168.0.0/16 — 65,536 addresses. Almost every home router uses 192.168.1.x or 192.168.0.x.

IPv6 — Why Security Practitioners Need to Know It

IPv6 addresses are 128 bits long, written in eight groups of four hexadecimal digits: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Leading zeros in each group can be compressed, and a single run of consecutive all-zero groups can be replaced with :: — so 2001:db8::1 is a valid compressed IPv6 address.

Three security reasons to care about IPv6:

• Enabled by default on every modern OS — a network that "doesn't use IPv6" still has IPv6 traffic from hosts that have configured it automatically. Monitoring only IPv4 leaves you blind to IPv6 communications.
• IPv6 tunnelling — IPv6 can travel inside IPv4 packets through mechanisms like Teredo and 6in4, traversing networks that don't natively carry IPv6 and bypassing controls that only inspect IPv4.
• Dual-stack attack surface — a host with both IPv4 and IPv6 addresses has two network stacks. Firewall rules for IPv4 may not be mirrored for IPv6 unless explicitly configured.

Routing — How Packets Find Their Way

BGP — The Internet's Routing Protocol

BGP (Border Gateway Protocol) is how the thousands of independent networks (Autonomous Systems) that make up the internet tell each other which address ranges they can reach. BGP is relevant to security because it is vulnerable to BGP hijacking — where a network falsely announces that it can reach address ranges it doesn't own. Traffic gets rerouted to the attacker. The 2010 China Telecom incident routed significant US internet traffic through China for 18 minutes; the 2019 Rostelecom incident briefly captured routes for Google, Amazon, and Cloudflare.

NAT — Network Address Translation

NAT is widely — and incorrectly — described as a security control. It is not a firewall. It provides incidental protection from unsolicited inbound connections (because the router doesn't know which device to forward them to) but provides zero protection against outbound malware reaching C2, application-layer attacks in permitted traffic, or attacks on the NAT device itself. Design your security architecture accordingly — don't rely on NAT as a defensive layer.

DNS (Domain Name System) is one of the most consequential protocols in all of networking — and one of the most consistently underestimated by practitioners who are new to security. It is the mechanism by which human-readable names (like example.com) are translated into the IP addresses that computers actually use. It is also a critical visibility point, an attack vector, a C2 communication channel, and a forensic goldmine. Understanding DNS thoroughly is a force multiplier for everything else in network security work.

How DNS Resolution Actually Works

When your browser needs to resolve www.example.com, here's the full journey:

1. Check the local cache first — your OS checks if it already resolved this name recently (and the answer hasn't expired). If yes, done. No network request needed.
2. Ask your recursive resolver — typically your ISP's DNS server, or a public resolver (8.8.8.8, 1.1.1.1, 9.9.9.9). This is the DNS server configured on your device.
3. The resolver asks a Root Nameserver — if the resolver doesn't have the answer cached, it asks one of 13 root nameserver clusters. The root doesn't know where www.example.com is, but it knows who manages the .com top-level domain (TLD). It replies: "ask the .com TLD nameservers."
4. The resolver asks the .com TLD nameserver — which knows who is authoritative for example.com. It replies: "ask the nameservers at ns1.example.com and ns2.example.com."
5. The resolver asks example.com's authoritative nameserver — which has the actual answer: "www.example.com resolves to 93.184.216.34." This is the final, authoritative answer.
6. The resolver caches the answer and returns it to your device — the cache duration is determined by the TTL (Time to Live) value in the DNS response.

This entire process typically completes in under 50 milliseconds. The caching at every step is what makes the system scale — the root nameservers would be overwhelmed if every DNS query required them to answer. Most queries are answered from cache long before reaching the root.

DNS Record Types and Their Security Relevance

TTL and Its Security Implications

The TTL (Time to Live) on a DNS record tells resolvers how long to cache the answer before asking again. A TTL of 3600 means "cache this for one hour." A TTL of 60 means "check again in one minute."

TTL matters for security investigations in two ways:

• Short TTLs signal rapid infrastructure changes — attackers who operate fast-flux infrastructure (constantly changing IP addresses to evade blocking) set very short TTLs, sometimes as low as 60 seconds. When you see a domain with a TTL of 60–300 seconds returning different IP addresses from different queries, you're likely looking at fast-flux.
• What you see in a DNS log is not necessarily what a user saw — if a user resolved a domain 2 hours ago with a 1-hour TTL, the cached answer they received may differ from what you'd see resolving it now. DNS logs from the recursive resolver show the actual answer at the time of resolution.

DNS Attack Techniques

DNS Cache Poisoning

DNS cache poisoning tricks a recursive resolver into caching a false answer — associating a legitimate domain name with an attacker-controlled IP address. Anyone who queries that resolver for the poisoned domain gets directed to the attacker's server, which may serve a phishing page, intercept credentials, or deliver malware — while displaying the legitimate domain name in the browser's address bar.

The Kaminsky attack (2008) demonstrated a practical method to poison resolvers at scale by exploiting predictable transaction IDs in DNS queries. Modern DNS implementations use randomised source ports and transaction IDs to make poisoning significantly harder, but it remains a relevant threat in environments running outdated resolver software.

DNS Tunnelling

Detection signatures for DNS tunnelling: very long subdomain labels (legitimate domains rarely have subdomains longer than 30 characters; tunnelled data is often 50–200 characters), high query volume to a single domain with varying subdomains, high-entropy (random-looking) subdomain names, unusual record types (TXT, NULL, MX) in queries from workstations, and queries at times inconsistent with user activity.

DNS Amplification (DDoS)

DNS is a protocol that can return a response much larger than the query. An attacker sends a small DNS query (60 bytes) to many open DNS resolvers, spoofing the source IP to be the victim's address. Each resolver sends its response (potentially 4,000 bytes for a carefully chosen query) to the victim. A small amount of attack bandwidth gets amplified into a massive DDoS flood directed at the victim. The amplification factor can be up to 70:1 — meaning 1 Gbps of attack traffic generates 70 Gbps of traffic hitting the victim.

DNS as a Security Control

The same properties that make DNS dangerous also make it a powerful place to deploy security controls. Since almost every internet connection begins with a DNS lookup, blocking a domain at the DNS layer prevents the connection from ever being established — regardless of what the application is trying to do.

• DNS filtering — blocking queries for known-malicious domains at the resolver level. Cloudflare Gateway, Cisco Umbrella, and Quad9 (9.9.9.9) block malicious domains based on threat intelligence. This stops malware from reaching C2 before any TCP connection is made.
• DNS sinkholes — resolving known-malicious domains to an internal IP address rather than NXDOMAIN (domain not found). The sinkhole server logs every connection attempt, revealing which internal hosts have malware that is attempting to reach C2.
• RPZ (Response Policy Zones) — a DNS server feature that allows custom override responses for specified domains, enabling local DNS filtering without a commercial product.

Passive DNS — The Forensic Time Machine

Passive DNS is the practice of recording all DNS responses observed in traffic — building a historical database of "at time T, domain D resolved to IP X." Commercial services (Farsight DNSDB, RiskIQ, VirusTotal passive DNS) aggregate this data from sensors around the internet.

For security investigators, passive DNS answers questions that are otherwise unanswerable: "What IP was this malicious domain resolving to six months ago when the victim first got infected?" "What other domains share this IP address?" "How long has this domain existed?" "Has this domain changed its IP addresses frequently?" These questions are the foundation of infrastructure analysis — connecting disparate attack indicators to a common attacker infrastructure.

The transport layer is where individual packets get organised into conversations. Without it, the internet would be chaos — packets arriving in random order, with no way to know which ones belong to which application, and no mechanism for confirming they all arrived. TCP (Transmission Control Protocol) brings order. UDP (User Datagram Protocol) deliberately doesn't — trading reliability for speed. Understanding both is essential for reading packet captures, understanding scanning techniques, and recognising anomalous network behaviour.

TCP — The Reliable Conversation

The Three-Way Handshake

Every TCP connection begins with a three-way handshake — three packets exchanged to establish a connection before any data is sent:

The sequence numbers are critically important — they allow both sides to track which data has been received and request retransmission of anything that was lost. They also have a security implication: in the early days of the internet, sequence numbers were predictable, allowing attackers to inject data into TCP connections they weren't party to. Modern TCP implementations use randomly initialised sequence numbers to prevent this.

TCP Flags

TCP packets carry flags — single-bit values that convey the purpose of the packet. The six most relevant:

TCP Scanning Techniques

Network scanning — determining which ports on a host are open — uses TCP flags deliberately to elicit responses that reveal port state. Understanding these helps you both use scanning tools effectively and recognise scanning activity in network captures.

• SYN scan (half-open scan) — sends a SYN. If the port is open, the target responds with SYN-ACK. The scanner immediately sends RST without completing the handshake. Faster and quieter than a full connect scan; doesn't create a full connection that would appear in application logs.
• Connect scan — completes the full three-way handshake. Slower, noisier, but more reliable and doesn't require raw socket access (so it works from unprivileged user accounts).
• FIN/NULL/XMAS scans — send packets with unusual flag combinations to closed ports, which should respond with RST. Open ports typically ignore such packets. These scans attempt to bypass simple packet filters that only look for SYN packets.

UDP — The Fast, Unreliable Protocol

UDP has no handshake, no acknowledgement, no guaranteed delivery, and no ordering. It is a thin wrapper that adds only port numbers and a checksum to an IP packet. Because there's no connection state, UDP is also harder to track in firewall state tables — a significant consideration for stateless firewall rules.

Security-critical UDP services: DNS (port 53), DHCP (ports 67/68 — automatic IP address assignment), NTP (port 123 — network time synchronisation), SNMP (port 161 — network device management, notorious for community string vulnerabilities), TFTP (port 69 — trivial file transfer, no authentication).

ICMP — The Network's Diagnostic Protocol

ICMP (Internet Control Message Protocol) carries network diagnostic and error messages. The most familiar: the ping command sends ICMP Echo Request packets and expects ICMP Echo Reply responses — confirming that a host is reachable and measuring round-trip time.

ICMP security relevance:

• ICMP ping sweep — sending ping to every address in a range to discover which hosts are alive. A legitimate admin technique and a common attacker reconnaissance step.
• ICMP redirect — a legitimate ICMP message type that tells a host to use a different router for certain destinations. An attacker on the same network can send forged ICMP redirects to redirect traffic through their machine.
• ICMP tunnelling — data can be hidden in ICMP Echo payloads. Since many firewalls allow ICMP through, ICMP tunnelling can be used as a covert C2 channel (ptunnel and similar tools implement this).
• Blocking all ICMP is counterproductive — a common misconfiguration. ICMP carries important diagnostic messages including "destination unreachable" and "fragmentation needed" (the latter is essential for PMTUD — Path MTU Discovery — and blocking it can cause silent connection failures for certain traffic).

Ports — What They Mean for Analysis

Ports are 16-bit numbers (0–65535) that identify specific services or applications on a host. When a packet arrives at a server, the OS uses the destination port number to determine which application should handle it — port 80 goes to the web server, port 22 goes to SSH, port 25 goes to the mail server.

Non-standard port usage is a significant analyst signal:

• Web traffic on port 8080 or 8443 is common for development and testing servers — or for attackers running C2 infrastructure on non-standard ports to avoid port-based blocking
• SSH on port 2222 or another non-standard port is common for reducing automated SSH brute-force attempts against internet-facing servers
• Any application running on ports below 1024 from a non-root process is anomalous on Linux (low ports require root/administrative privileges)
• High-numbered ephemeral ports (49152–65535) used as source ports in outbound connections are normal; the same ports appearing as destination ports in outbound connections may indicate C2

A security practitioner encounters the same set of protocols repeatedly across investigations, detections, and incident responses. Rather than a comprehensive protocol reference (RFCs do that better than any textbook), this chapter covers the security-relevant mechanics of the protocols you'll see most often — what they do, how they work at just enough depth to reason about attacks, and where they are commonly abused.

HTTP and HTTPS

HTTP is the protocol of the web. An HTTP request is a text message from a client to a server, and the response is another text message back. That simplicity is what made the web explode — and it's also what makes HTTP an extremely rich attack surface.

Security-relevant HTTP components for analysts:

• Request methods — GET (retrieve a resource), POST (submit data), PUT (create/replace), DELETE, PATCH, OPTIONS. In investigations, POST requests to unusual paths are often the C2 channel; GET requests with long query strings may be SQL injection or path traversal attempts.
• Status codes — 200 (OK), 301/302 (redirect), 401 (authentication required), 403 (forbidden), 404 (not found), 500 (server error). A flood of 404s from a single IP is a web scanner or attacker probing for vulnerable paths. A spike in 500 errors may indicate a successful injection.
• Security headers — HSTS (HTTP Strict Transport Security) tells browsers to only connect over HTTPS; CSP (Content Security Policy) restricts which scripts can execute; X-Frame-Options prevents clickjacking; CORS controls cross-origin requests. These are defensive headers — their absence is a vulnerability indicator.

HTTPS wraps HTTP inside TLS. The HTTP content is encrypted — but the IP address being connected to, the TLS certificate, and the SNI (Server Name Indication in the handshake) are visible in unencrypted form. This is why network analysts can see which domains a host is communicating with even over HTTPS, without decrypting the traffic.

SSH — Secure Shell

SSH provides an encrypted terminal connection to remote systems. It replaced Telnet (which transmitted everything including passwords in cleartext) and is now the standard for remote administration of Linux servers and network devices.

SSH authentication can use passwords (vulnerable to brute force) or public key cryptography. Key-based authentication works like a lock and key: you generate a key pair (public key + private key), put the public key on the server, and authenticate by proving you have the corresponding private key — without ever sending the private key across the network.

Security concerns with SSH:

• SSH brute force — internet-facing SSH servers receive continuous automated password attempts. Any server with port 22 open to the internet will see thousands of login attempts per day. Mitigations: key-only authentication (disable password auth), fail2ban (block IPs after repeated failures), non-standard port (reduces noise, not a real security control).
• SSH tunnelling as an attack vector — SSH port forwarding can create encrypted tunnels through firewalls. Local forwarding (ssh -L 8080:internal-server:80 bastion) routes traffic from your local port through an SSH connection to an internal host. An attacker with SSH access to any host on your network can use this to bypass network segmentation — reaching systems they shouldn't be able to reach by tunnelling through the SSH connection.
• known_hosts and host key verification — SSH stores the fingerprint of every server's host key in ~/.ssh/known_hosts. If the fingerprint changes on your next connection, SSH warns you — because this could indicate a man-in-the-middle attack where someone is intercepting the connection. The common response of adding StrictHostKeyChecking no to avoid this warning is a serious security mistake in automated scripts.

SMB — The Windows File Sharing Protocol

SMB (Server Message Block) is how Windows systems share files, printers, and named pipes on a network. It's the protocol behind the \\server\share path you see in Windows environments. It is also one of the most historically exploited protocols in the Windows ecosystem.

SMB relay attacks are a persistent concern even with modern SMBv2/v3. In an SMB relay attack, an attacker on the same network intercepts an authentication attempt (typically by triggering a Windows machine to connect to an attacker-controlled share, which happens automatically through various mechanisms) and relays those credentials to another server, authenticating as the victim without ever cracking the password. Mitigations: SMB signing (prevents relay by requiring all packets to be signed with the session key), network segmentation, disabling LLMNR and NBT-NS (which enable the initial credential capture).

Kerberos — The Active Directory Authentication Protocol

Security relevance: understanding Kerberos is essential for understanding most Active Directory attack techniques. Kerberoasting requests service tickets for service accounts and then attempts to crack the ticket offline (the ticket is encrypted with the service account's password hash — if the password is weak, it can be cracked). Pass-the-ticket steals a valid Kerberos ticket from memory and reuses it to authenticate without knowing the password. Golden Ticket forges TGTs by using the KRBTGT account's password hash — providing indefinite, persistent access to all services in the domain.

RDP — Remote Desktop Protocol

RDP provides a graphical remote desktop session to Windows systems over TCP port 3389. It is essential for Windows server administration and is one of the most attacked services on the internet. Any system with port 3389 exposed to the internet will receive continuous brute-force attempts.

BlueKeep (CVE-2019-0708) was a pre-authentication RDP vulnerability that allowed remote code execution without any credentials — purely by sending specially crafted packets to port 3389. It was patched in 2019 but unpatched systems remain in many environments. RDP should never be directly exposed to the internet; if remote access is needed, it should be via VPN or Zero Trust access gateway, or restricted to specific source IP addresses.

Email is the primary initial access vector for the vast majority of security incidents — phishing, business email compromise, malware delivery, and credential theft all arrive predominantly via email. Understanding the protocols designed to secure email is therefore not academic groundwork; it is daily practitioner knowledge. This chapter covers SPF, DKIM, and DMARC in enough depth to configure them, to explain why misconfigurations create risk, and to investigate phishing incidents using email header analysis.

SPF — Sender Policy Framework

SPF allows a domain owner to publish a list of mail servers authorised to send email on their behalf. The receiving mail server checks whether the sending IP address is in that list. If it isn't, the message fails SPF.

SPF is published as a DNS TXT record. A typical SPF record:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:mailchimp.com -all

Reading this: "SPF version 1. Authorised senders are: the 192.0.2.x range, plus whatever Google's SPF record says, plus Mailchimp's SPF record. All others: hard fail (-all)."

SPF's Critical Limitation

SPF validates the envelope sender — the MAIL FROM address used in the SMTP conversation, which is invisible to end users. It does not validate the From: header that appears in the email client. An attacker can pass SPF for [email protected] while displaying From: CEO <[email protected]> to the recipient. The display name spoofing attack works precisely because SPF doesn't protect the visible From header.

DKIM — DomainKeys Identified Mail

DKIM uses public-key cryptography to sign outgoing email. When a mail server sends a message, it generates a cryptographic signature of specific email headers (From, To, Subject, Date) and the message body, signs it with the domain's private key, and includes the signature in a DKIM-Signature header. The receiving server retrieves the public key from DNS and verifies the signature.

DKIM public keys are published in DNS as TXT records at selector._domainkey.domain.com. The selector is specified in the DKIM-Signature header — allowing a domain to have multiple keys (one per service, for easy rotation):

# Look up a DKIM public key
dig TXT google._domainkey.example.com

# A DKIM-Signature header looks like:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=google;
  h=from:to:subject:date;
  bh=base64-hash-of-body;
  b=base64-signature-value

DMARC — Domain-based Message Authentication, Reporting & Conformance

DMARC ties SPF and DKIM together through the concept of alignment — requiring that the domain in the From header matches the domain validated by SPF or DKIM. DMARC also specifies what happens when messages fail: deliver (p=none), quarantine (p=quarantine), or reject (p=reject). And it enables reporting — receiving servers send aggregate and forensic reports back to the domain owner about messages that pass and fail.

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100

The p=none Trap

Many organisations publish DMARC records with p=none — meaning "monitor but don't reject." This is correct as a starting point (you need to identify all legitimate sending sources before enforcing), but organisations frequently get stuck at p=none forever, providing no actual protection. The deployment path should be: p=none (collect reports, understand your sending landscape) → p=quarantine with pct=25 (gradually enforce) → p=reject with pct=100 (full enforcement). Each step should take weeks, not years.

What DMARC Stops vs What It Doesn't

Reading Email Headers for Forensic Investigation

Every email carries a chain of Received: headers — one added by each mail server the message passed through, in reverse chronological order (newest at the top). Reading them from bottom to top reconstructs the message's actual journey.

How a network is designed determines how much damage an attacker can do after they've established their initial foothold. A flat network — where every device can reach every other device — means that one compromised laptop gives an attacker access to every server, every printer, and every IP camera in the building. A well-segmented network means a compromised laptop can only reach what it legitimately needs to reach, and lateral movement requires overcoming additional barriers at each step.

The Traditional DMZ Model

The DMZ (Demilitarised Zone) is a network architecture pattern that isolates internet-facing servers from the internal network. Named after the military concept of a buffer zone between opposing forces, the DMZ sits between two firewalls:

The outer firewall allows traffic from the internet to reach DMZ servers (on specific ports — 80, 443, 25). The inner firewall prevents DMZ servers from initiating connections to the internal network (they can receive requests from internal systems, but cannot reach internal resources unprompted). If an internet-facing web server in the DMZ is compromised, the attacker is in the DMZ — not on the internal network. They must then overcome the inner firewall to progress.

VLANs — Virtual Network Segmentation

VLANs are implemented through 802.1Q tagging — a 4-byte tag added to Ethernet frames that tells switches which VLAN the frame belongs to. Security practitioners need to know two things about VLANs:

• VLANs are not a substitute for firewalling — VLANs separate broadcast domains and require traffic to pass through a router to cross VLANs, but unless there's a firewall on that router interface, all inter-VLAN traffic may be permitted by default.
• VLAN hopping attacks — in environments where switch ports are misconfigured, an attacker can potentially send traffic tagged for a different VLAN and have it processed as if it belonged to that VLAN. The fix is disabling auto-trunking (DTP — Dynamic Trunking Protocol) on all access ports and ensuring trunk ports only carry the VLANs they need to carry.

Network Zones and Security Policy

A mature network is divided into zones with defined security policies between them. Common zone model:

Zero Trust Network Architecture

Traditional network security assumes that everything inside the network perimeter is trustworthy and everything outside isn't. Zero Trust rejects this assumption entirely — the name comes from the principle "never trust, always verify."

Zero Trust architecture means: every access request is authenticated and authorised regardless of network origin (even users already "inside" the network have to prove their identity and have permission for each specific resource); access is granted with minimum necessary permissions and for the minimum necessary time; and every access is logged.

A firewall is a device or software that controls which network traffic is allowed to pass between network segments. It is the most fundamental network security control and the one most practitioners encounter first. Understanding how firewalls actually work — not just that they "block bad traffic" — is essential for writing rules that do what you intend, diagnosing why traffic is or isn't flowing, and recognising misconfigurations that leave gaps an attacker can exploit.

Firewall Generations

• First generation — Packet filtering: examines each packet in isolation based on source IP, destination IP, source port, destination port, and protocol. Very fast. Very simple. The problem: it has no memory — it can't tell whether a packet is part of a legitimate established connection or a crafted attack packet that looks like one.
• Second generation — Stateful inspection: tracks the state of network connections — remembering that a TCP SYN was sent from A to B, and therefore allowing the SYN-ACK response from B back to A. Blocks packets that don't correspond to legitimate connection state. Still doesn't inspect the application-layer content of the traffic.
• Third generation — Application layer (NGFW): understands application protocols. Can identify traffic by application (Skype, BitTorrent, Salesforce) regardless of what port it uses. Can enforce user-based policies ("finance team can access the finance portal"). Can perform TLS inspection. Can apply threat prevention (IPS signatures, malware detection) inline.

Stateful vs Stateless Firewalls

Most modern firewalls are stateful. Stateless firewalls (simple ACLs on routers) are still used at high-throughput points where the performance overhead of connection tracking is unacceptable.

Firewall Rule Evaluation

Understanding rule evaluation is the difference between a firewall that does what you intend and one that silently permits traffic you meant to block.

• First-match wins (most firewalls) — rules are evaluated top to bottom. The first rule that matches the packet determines the action. This means more specific rules must come before more general ones. A rule allowing "all traffic from 10.0.0.0/8" before a rule blocking "10.0.0.50 specifically" means the block rule is never evaluated — 10.0.0.50 matches the allow rule first.
• Implicit deny at the end — most firewalls have an implicit "deny all" at the bottom of every ruleset. Traffic that matches no explicit rule is dropped. This is the correct default — network security should be "everything is denied unless explicitly permitted," not "everything is permitted unless explicitly denied."
• Shadow rules — a rule that is never evaluated because a preceding rule always matches first. Security teams often discover shadow rules during audits — they were added at some point to address a specific concern, but due to rule ordering, they've never actually applied to any traffic.

Common Firewall Misconfigurations

• Overly permissive egress rules — many firewalls are configured with strict inbound rules and permissive (or no) outbound rules. This allows malware on internal systems to reach C2 infrastructure freely. Outbound traffic should be filtered to permit only what is required.
• Management interfaces exposed — the firewall's own management interface (SSH, HTTPS, SNMP) accessible from the internet. The device you use to protect your network should not itself be accessible from the internet. Management access should be restricted to a dedicated management network or specific trusted IP addresses.
• "Any, Any, Allow" rules — rules that allow all traffic from any source to any destination. Often added during troubleshooting ("let me remove restrictions and see if it works") and never removed. Common finding in firewall audits of organisations that have grown without a dedicated network security function.
• Stale rules for decommissioned systems — rules that were added for systems that no longer exist, creating open paths to IP addresses that may now be reassigned to different (potentially less trusted) systems.

Next-Generation Firewalls (NGFW)

NGFWs add application-layer capabilities to traditional stateful inspection. Key capabilities for security practitioners:

• Application identification — identifies traffic by application signature regardless of port. Skype may use port 443 (to bypass firewalls), but an NGFW can identify it as Skype and apply Skype-specific policies.
• TLS inspection (SSL decryption) — decrypts TLS traffic, inspects the cleartext content for threats, then re-encrypts and forwards it. This is how enterprise NGFWs can detect malware hidden in HTTPS traffic. Privacy implications: users' encrypted communications are decrypted and inspected by the enterprise. Corporate policy and disclosure to users is required.
• User-identity integration — policies based on Active Directory user or group, not just IP address. "Block social media for the sales team" is a policy that requires knowing which IPs belong to which users — something that changes as users move between desks or log in from different machines.

iptables — The Linux Firewall

iptables is the Linux kernel's firewall interface, used directly on Linux servers and underlying most container networking and cloud security groups. Understanding its structure explains many things that seem mysterious about how Linux networking controls work.

# List all rules with line numbers
iptables -L -n -v --line-numbers

# Allow established/related connections (stateful tracking)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH from specific IP only
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACCEPT

# Allow HTTP and HTTPS from anywhere
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Drop everything else inbound (implicit deny)
iptables -A INPUT -j DROP

# Allow DNS queries outbound
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

VPNs (Virtual Private Networks) solve a real problem: how do you securely extend a private network over an untrusted public network? How does a remote employee access internal company resources as securely as if they were sitting at their desk in the office? The answer, for the past 30 years, has largely been the VPN. But VPNs have become one of the most critical attack surfaces in enterprise networks — and the industry is in the middle of a transition toward a better model.

VPN Types

• Remote access VPN — an individual user connects from a remote location (home, coffee shop, airport) to the corporate network. Their device gets a private IP address on the corporate network, and all traffic (or some traffic) is routed through the corporate VPN gateway. This is the type most people experience as "connecting to the VPN."
• Site-to-site VPN — connects two networks together permanently. A branch office network and a headquarters network, for example, connected via a VPN tunnel between their respective routers. Users at the branch office can access headquarters resources as if they were on the same local network.

IPsec — The Foundation

IPsec (Internet Protocol Security) is the protocol suite underlying most enterprise VPNs. It operates at Layer 3 — encrypting IP packets themselves — which means it's transparent to applications above it. IPsec consists of two main protocols:

• ESP (Encapsulating Security Payload) — encrypts the payload and optionally authenticates the entire packet. This is what actually provides confidentiality. Used in virtually all IPsec VPN deployments.
• AH (Authentication Header) — provides authentication but not encryption. Rarely used in modern deployments.

The key exchange and security parameter negotiation happens via IKE (Internet Key Exchange), in two phases. Phase 1 establishes a secure channel for the negotiation itself. Phase 2 establishes the actual IPsec tunnel parameters. The complexity of this two-phase process, combined with extensive configuration options, makes IPsec notoriously difficult to deploy correctly — and misconfigured IPsec implementations are a recurring finding in security assessments.

SSL/TLS VPNs

SSL/TLS VPNs (like Cisco AnyConnect, Pulse Secure, FortiClient, GlobalProtect) use TLS — the same protocol that secures HTTPS — as the tunnel mechanism. This makes them much easier to deploy through firewalls than IPsec (they run on port 443, which is almost never blocked) and easier to configure on client devices. For remote access, SSL/TLS VPNs have largely replaced IPsec in enterprise environments.

WireGuard — The Modern Alternative

WireGuard is a modern VPN protocol designed to be simpler, faster, and more auditable than IPsec. Its codebase is approximately 4,000 lines (compared to tens of thousands for OpenVPN and hundreds of thousands for IPsec implementations). Simpler code means smaller attack surface and easier security auditing. WireGuard uses modern cryptographic primitives (ChaCha20, Poly1305, Curve25519, BLAKE2) with no configuration options for cipher suites — removing the possibility of negotiating down to weak cryptography. It is the protocol used by NordVPN, Mullvad, and Cloudflare WARP.

Split Tunnelling — The Security Trade-off

When you're connected to a VPN, there are two options for where your traffic goes:

• Full tunnel — all traffic, including regular internet browsing, goes through the VPN gateway. The company can monitor and filter all traffic. The user's internet browsing goes through the corporate firewall and proxy. Provides maximum visibility and control; adds latency for non-corporate traffic.
• Split tunnel — only traffic destined for the corporate network goes through the VPN. Regular internet traffic goes directly out the user's local internet connection. Reduces latency and bandwidth load on the VPN gateway.

Split tunnelling is a security concern because while the user is connected to the corporate VPN, their device simultaneously has an unmonitored path to the internet. Malware on the device can reach C2 via the split-tunnel internet path even while the user is "connected to the VPN." Corporate monitoring and DLP controls apply only to the traffic routed through the tunnel.

VPN as an Attack Surface

VPN gateways have become the most commonly exploited initial access vector in enterprise attacks — consistently appearing at the top of CISA and threat intelligence reports. The reason: they are internet-facing, they often run complex software, and many organisations are slow to patch them because downtime disrupts remote workers.

Critical vulnerabilities in VPN products have affected every major vendor: CVE-2019-11510 (Pulse Secure — unauthenticated file read allowing credential theft), CVE-2018-13379 (Fortinet FortiGate — path traversal exposing session files), CVE-2021-20016 (SonicWall — SQL injection in the management interface). These vulnerabilities are actively exploited by ransomware groups and nation-state actors within days of disclosure.

Zero Trust Network Access — Replacing the VPN

ZTNA (Zero Trust Network Access) is the architectural successor to the VPN for remote access. Where a VPN grants network-level access (once connected, you're on the corporate network), ZTNA grants application-level access (you can reach this specific application, on this specific port, from this specific device with this specific security posture). Each access request is evaluated individually. Network access to systems other than the specific approved applications is never granted.

The security benefit: a compromised device connected via ZTNA can only reach the specific approved applications — it cannot pivot to other internal systems, cannot scan the internal network, and cannot establish lateral movement paths. The blast radius of any single compromise is dramatically reduced.

Wireless networking removes the physical constraint that wired networks rely on — you can't easily eavesdrop on a wired network without physically tapping the cable. A wireless network broadcasts traffic through the air within range of any device that can receive it. This fundamentally changes the threat model: an attacker sitting in the car park outside your office can attempt to access your Wi-Fi without ever touching a physical cable.

The Evolution of Wi-Fi Security

WEP — Broken Beyond Repair

WEP (Wired Equivalent Privacy) was introduced with the original 802.11 standard in 1997. Its cryptographic design had fundamental flaws — the same key was used for all traffic, and the way it generated key streams made it statistically possible to recover the key from captured packets. Tools like Aircrack-ng can crack a WEP key in under a minute given enough captured traffic. WEP should be treated as the equivalent of no security. If any devices in your environment are still using WEP, it needs immediate remediation.

WPA2 — The Current Minimum Standard

WPA2 (Wi-Fi Protected Access 2), introduced in 2004 and mandated by 2006, replaced WEP with AES-CCMP encryption — a fundamentally sound cryptographic design that has held up to scrutiny for two decades. WPA2 comes in two variants:

• WPA2-Personal (PSK) — uses a pre-shared key (the Wi-Fi password). Everyone on the network uses the same key. This is appropriate for home networks and small offices, but has a significant enterprise security problem: if the password is shared with a contractor, a visitor, or a departing employee, it cannot be easily revoked for just that person. Changing the password requires updating every device.
• WPA2-Enterprise (802.1X) — each user authenticates with their own credentials (typically via RADIUS, backed by Active Directory or LDAP). Each user has a unique session key. Revoking one user's access is a single change in Active Directory. This is the required model for any corporate Wi-Fi network.

WPA2 Attack Techniques

The 4-Way Handshake Capture

When a device connects to a WPA2-PSK network, a 4-way handshake is exchanged that derives session keys from the pre-shared key. This handshake can be captured passively (by listening when a client connects) or actively (by sending a deauthentication frame to force a client to reconnect, triggering a new handshake). The captured handshake doesn't contain the password directly, but it can be used for offline brute-force attacks — comparing the handshake against hashed guesses to find the password. If the Wi-Fi password is weak or is a dictionary word, this attack succeeds quickly.

PMKID Attack

Discovered in 2018, the PMKID attack allows cracking WPA2-PSK without capturing a 4-way handshake from a client. A single packet from the access point contains a PMKID value derived from the pre-shared key and known values. This enables offline brute-force without requiring any client to connect — making it significantly more practical for attackers who can reach the access point but haven't observed any client connections.

Evil Twin / Rogue Access Point

WPA3 — Improvements and New Vulnerabilities

WPA3, introduced in 2018, brings significant security improvements: Simultaneous Authentication of Equals (SAE) replaces the PSK handshake with a Diffie-Hellman-based protocol that provides forward secrecy (captured handshakes cannot be used to decrypt previously captured traffic, even if the password is later discovered) and resistance to offline dictionary attacks. WPA3-Enterprise adds 192-bit security mode for more sensitive environments.

However, WPA3's SAE protocol was found to have vulnerabilities — dubbed "Dragonblood" — that allowed timing side-channel attacks and could leak information about the password. These were patched, but the discovery illustrates the general principle: new security protocols should be expected to have vulnerabilities discovered in the years after their release.

Bluetooth Security

Bluetooth connects devices wirelessly over short ranges (typically 10 metres for Class 2 devices, up to 100 metres for Class 1). The BlueBorne vulnerability class (2017) allowed remote code execution on Bluetooth-enabled devices without any user interaction and without the device being in discoverable mode — just having Bluetooth on was sufficient. The attack spread to nearby devices airborne, with no pairing required.

Key Bluetooth security practices: keep Bluetooth firmware updated; disable Bluetooth when not in use; be cautious of unexplained Bluetooth connection requests; use Bluetooth LE (Low Energy) for IoT devices where possible as it has a reduced attack surface.

Packet analysis is where networking theory meets security practice. Reading a packet capture (PCAP) is the forensic equivalent of reading a transaction log — it tells you exactly what happened on a network, in what order, with what content. The analyst who can fluently read network captures has a forensic capability that no log-based tool can fully replicate: the complete, unambiguous record of every byte that crossed the wire.

tcpdump — The Essential Command-Line Tool

tcpdump captures network packets from a live interface or reads them from a PCAP file. It's available on virtually every Unix-like system and is the standard tool for quick capture and filtering. The syntax is based on BPF (Berkeley Packet Filter) — a compact language for specifying which packets you want to see.

# Capture on a specific interface, write to file
tcpdump -i eth0 -w capture.pcap

# Read from a capture file
tcpdump -r capture.pcap

# Verbose output with timestamps
tcpdump -r capture.pcap -tttt -v

# Filter: only traffic to/from a specific host
tcpdump host 192.168.1.50

# Filter: only DNS traffic (UDP port 53)
tcpdump udp port 53

# Filter: only HTTP traffic from a specific subnet
tcpdump src net 10.0.0.0/8 and tcp dst port 80

# Don't resolve hostnames or ports (faster, shows IPs and port numbers)
tcpdump -nn -r capture.pcap

# Show packet contents in hex and ASCII
tcpdump -XX -r capture.pcap host 10.1.1.1

BPF Filter Syntax

BPF (Berkeley Packet Filter) is the filter language used by tcpdump, Wireshark, and most network monitoring tools. Understanding its syntax is one of those skills that pays dividends constantly — you'll use it to capture exactly what you need rather than everything.

Wireshark — Interactive Analysis

Wireshark provides a graphical interface for packet analysis with protocol dissection, conversation reconstruction, and statistics. Three workflows security analysts use most:

Following Streams

Right-click any packet in a TCP conversation → Follow → TCP Stream. Wireshark reconstructs the entire conversation in human-readable form, with client data in red and server data in blue. This is how you read the content of HTTP conversations, SMTP exchanges, or FTP sessions — seeing exactly what was transmitted, including credentials if the session was unencrypted.

Display Filters (different from BPF capture filters)

http.request.method == "POST"          # POST requests only
http.response.code == 200              # successful HTTP responses
dns.qry.name contains "suspicious"     # DNS queries for specific names
tls.handshake.type == 1                # TLS Client Hello packets
tcp.flags.syn == 1 && tcp.flags.ack == 0  # SYN packets (connection attempts)
ip.src == 10.1.1.50                    # traffic from specific IP
frame.len > 10000                      # large packets (potential data transfer)
!(arp || icmp || dns)                  # exclude common noise

Statistics → Conversations

The Statistics menu provides conversation-level views: which pairs of IP addresses communicated, how many packets, how many bytes, over what time period. This is the starting point for finding anomalous conversations in a capture — sorting by byte count reveals large data transfers, sorting by duration reveals persistent connections.

Detecting C2 Beacons in Network Captures

C2 (command and control) beacons make periodic, regular connections from a compromised host to the attacker's infrastructure. In a packet capture or NetFlow data, beaconing appears as:

• Connections from a single internal IP to a single external IP, repeating at regular intervals (every 30, 60, 120, or 300 seconds)
• Each connection is similar in size — a heartbeat with no active tasking sends a consistent small payload
• Connections continue outside business hours, including overnight and weekends
• The external IP has no associated hostname (or a newly-registered domain with no reputation history)
• The user-agent in HTTP beacons may not match any browser installed on the host

NetFlow — Traffic Metadata at Scale

Full packet capture generates enormous storage requirements. NetFlow provides traffic metadata — source and destination IP/port, protocol, byte and packet counts, start/end time — at roughly 1/500th the storage cost of full PCAP. For most detection use cases, this metadata is sufficient. Questions that NetFlow answers: which hosts communicated with each other? How much data moved? Over what time period? What ports were used?

NetFlow is where organisations store months of traffic metadata for investigation, compared to the 24–72 hours of full PCAP that storage budgets typically allow. A breach discovered 45 days after initial access can still be investigated via NetFlow — the PCAP from day one is long gone.

Firewalls control what traffic is allowed on a network based on a set of rules you define. Intrusion detection and prevention systems watch what actually happens and flag or block behaviour that matches known attack signatures or statistical anomalies — even if that traffic was technically allowed through the firewall. They are the difference between a locked door (firewall) and a security camera with motion detection (IDS/IPS) — the camera notices when something unusual happens even inside the perimeter.

IDS vs IPS

The distinction between IDS (Intrusion Detection System) and IPS (Intrusion Prevention System) is about response capability:

• IDS — monitors traffic and generates alerts when suspicious activity is detected. It does not take action to stop the traffic. An analyst reviews the alerts and decides whether to respond. Deployed out-of-band (on a mirror or tap, not inline), meaning it can observe traffic without affecting it — no latency, no single point of failure.
• IPS — like IDS but deployed inline (traffic flows through it). When a rule fires, it can drop the packet before it reaches its destination. Provides active prevention but introduces latency and creates a single point of failure — if the IPS fails, traffic is affected.

Most modern deployments start in IDS mode — building confidence in rule accuracy before enabling blocking. A rule with a 20% false positive rate should generate alerts for analyst review, not drop production traffic. Once a rule is well-tuned and trusted, it can be promoted to prevention mode.

NIDS vs HIDS

• NIDS (Network-based IDS) — deployed on the network, observing traffic passing through a capture point. Sees all traffic on the segment it monitors. Cannot see encrypted content of TLS connections. Cannot correlate network activity with process-level information from individual hosts.
• HIDS (Host-based IDS) — deployed as an agent on individual hosts. Can see application-level activity, process creation, file modifications, and log entries that are invisible to NIDS. Cannot see traffic between other hosts on the network. Examples: OSSEC, Wazuh, Samhain.

NIDS and HIDS are complementary. A network-level compromise (port scan, lateral movement via the network) is visible to NIDS. A host-level compromise (malware execution, file modification) is visible to HIDS. The investigation that combines both data sources produces the clearest picture.

Suricata — Signature Detection and NSM

Suricata is the leading open-source IDS/IPS engine. It supports both inline IPS mode and passive IDS mode (from PCAP or live capture on a tap/span). It parses dozens of protocols and generates both alert logs and rich protocol logs — similar to Zeek.

# Format: action protocol src_ip src_port direction dst_ip dst_port (options)

alert tcp $HOME_NET any -> $EXTERNAL_NET any (
  msg:"ET MALWARE Cobalt Strike Beacon CnC Checkin";
  flow:established,to_server;
  content:"Accept:"; http_header;
  content:"Accept-Language:"; http_header;
  content:!"Referer:"; http_header;
  content:!"User-Agent:"; http_header;
  classtype:trojan-activity;
  sid:2019439; rev:5;
)

# Breakdown:
# alert     = generate an alert (vs drop, reject, pass)
# tcp       = protocol
# $HOME_NET = source IP variable (your internal network range)
# any       = any source port
# ->        = direction (unidirectional)
# $EXTERNAL_NET = destination variable
# flow:established,to_server = only match established connections
# content:  = look for this string in the packet
# sid:      = unique rule identifier

Network Security Monitoring (NSM) as a Discipline

NSM is the practice of collecting and analysing network data for security purposes. The NSM stack typically consists of three layers:

1. Full content data (PCAP) — every packet, retained for 24–72 hours at high-traffic networks
2. Extracted content / protocol logs (Zeek logs) — structured records of every network transaction: DNS queries, HTTP requests, TLS handshakes, file transfers
3. Alert data (Suricata / Snort alerts) — specific triggered detections for known attack signatures

The disciplined NSM analyst doesn't just look at alerts. They use the alert as the starting point, then pivot to the Zeek protocol logs for context (what else was this host doing around the same time?), and to the PCAP for confirmation (what did the actual packets look like?). This three-layer investigation produces findings with much higher confidence than alert-only analysis.

Understanding how network attacks work — not just their names — is what separates practitioners who can design effective defences from those who can only apply vendor recommendations. Each attack in this chapter exploits a specific property of a network protocol. Once you understand the property being exploited, the defence becomes intuitive rather than prescriptive.

ARP Spoofing — The Local Network Impersonator

ARP spoofing is the foundation of most man-in-the-middle attacks on local networks. The attacker configures their machine to forward traffic after inspection (so the victim doesn't notice connectivity issues), capturing and potentially modifying everything in transit. Tools like Bettercap automate ARP spoofing. Detection: passive ARP monitoring tools (like arpwatch) alert when the MAC address associated with a known IP changes unexpectedly — a reliable indicator of spoofing.

SSL Stripping — Downgrading Encryption

SSL stripping is a man-in-the-middle attack that downgrades HTTPS connections to HTTP. It exploits the fact that users typically initiate connections by typing just a domain name (like example.com) rather than explicitly typing https://. The first request may be HTTP, and the server responds with a redirect to HTTPS.

In an SSL stripping attack (positioned between the victim and the server, via ARP spoofing or a rogue Wi-Fi AP), the attacker intercepts this redirect. They maintain an HTTPS connection to the server on the victim's behalf, but present an HTTP connection to the victim. The victim sees HTTP in their browser. Their credentials are transmitted unencrypted to the attacker.

The defence is HSTS (HTTP Strict Transport Security) — a response header that tells the browser to always use HTTPS for this domain for a specified period, refusing to connect over HTTP even if instructed. When a browser has an HSTS entry for a domain, SSL stripping fails because the browser won't initiate an HTTP connection in the first place.

DHCP Attacks

DHCP (Dynamic Host Configuration Protocol) automatically assigns IP addresses, subnet masks, default gateways, and DNS servers to devices when they join a network. Two DHCP attacks matter:

• DHCP starvation — an attacker sends thousands of DHCP requests with spoofed MAC addresses, exhausting the DHCP server's address pool. Legitimate new devices can't get IP addresses. This is a denial-of-service attack against network availability.
• Rogue DHCP server — an attacker runs a DHCP server that responds faster than the legitimate server. Devices that receive the attacker's DHCP response will be configured with the attacker's gateway and DNS server — routing all their traffic through the attacker and using the attacker's DNS for name resolution. Defence: DHCP snooping on managed switches — a feature that allows DHCP responses only from ports connected to authorised DHCP servers.

DDoS — Distributed Denial of Service

Three DDoS categories:

• Volumetric — flood the target with raw traffic volume, consuming all available bandwidth. Measured in Gbps. DNS amplification, NTP amplification, and direct UDP floods are common techniques. Mitigation requires upstream scrubbing — the volume must be absorbed or deflected before it reaches the target.
• Protocol / state exhaustion — consume the target's connection state table or processing capacity, rather than its bandwidth. A SYN flood falls here — not generating enormous traffic volume but filling the server's half-open connection table.
• Application layer (Layer 7) — send requests that are expensive for the server to process. A flood of search queries or resource-intensive database lookups can overwhelm an application even at relatively low traffic volumes. Harder to filter because individual requests look legitimate.

SYN Flood — The State Exhaustion Attack

In a SYN flood, the attacker sends a large number of TCP SYN packets to the target, spoofing the source IP address. The server replies with SYN-ACK to the spoofed addresses (which either don't exist or don't respond). The server stores a half-open connection state for each unanswered SYN-ACK, waiting for the ACK that will never come. These half-open connections accumulate until the server's connection state table is exhausted. New legitimate connection attempts fail.

SYN cookies defeat this attack. Instead of storing state for the half-open connection, the server encodes the connection parameters in the sequence number of the SYN-ACK. When (and if) the ACK arrives, the server reconstructs the state from the sequence number. An attacker sending SYNs with spoofed source IPs will never send the ACK to complete the handshake — so no state is wasted on them. Legitimate connections, which do send the ACK, complete normally.

nmap — Network Reconnaissance

nmap (Network Mapper) is the standard tool for network reconnaissance — discovering which hosts are reachable, which ports are open, what services are running, and what OS is likely installed. Understanding nmap is essential both for using it in legitimate security assessments and for recognising its characteristic traffic patterns in network captures.

# Ping sweep — discover live hosts in a range
nmap -sn 192.168.1.0/24

# SYN scan (fast, requires root/admin)
nmap -sS 192.168.1.50

# Connect scan (no root required, slower, noisier)
nmap -sT 192.168.1.50

# Service version detection
nmap -sV 192.168.1.50

# OS detection
nmap -O 192.168.1.50

# Full comprehensive scan
nmap -A -T4 192.168.1.50

# Scan common ports only (fast)
nmap -F 192.168.1.0/24

# Scan specific ports
nmap -p 22,80,443,3389 192.168.1.50

In network captures, nmap SYN scans appear as: a source sending SYN packets to consecutive ports on a target, receiving RST responses for closed ports and SYN-ACK for open ports. The pattern — rapid sequential SYN packets to many ports from a single source — is the unmistakable signature of a port scan.

Network forensics is the discipline of reconstructing what happened on a network after the fact — using packet captures, flow data, protocol logs, and DNS records to answer the questions an investigation demands: when did the attacker arrive, how did they move, what did they access, and how did they leave? This chapter covers the investigative workflow that turns a collection of network evidence into a coherent, evidenced attack narrative.

The Network Forensics Investigation Workflow

1. Preserve what you have. Network evidence is ephemeral. PCAPs are retained for 24–72 hours at most networks. DNS cache entries expire. DHCP lease logs roll over. When an investigation starts, immediately identify all relevant log sources and ensure they are not overwritten before you've extracted what you need. Extend retention, copy to investigation storage, and note exactly what time ranges are available.
2. Establish the timeline anchor. Every investigation needs a starting point — the first confirmed malicious event. This might be a GuardDuty alert, a SIEM correlation, an EDR detection, or a user report. The anchor event's timestamp becomes the centre of your timeline: what happened before (reconnaissance, access establishment) and what happened after (lateral movement, exfiltration).
3. Expand backward from the anchor. How did the attacker arrive? Trace the inbound connection backward through the network — proxy logs for web-delivered payload, email gateway logs for phishing, VPN authentication logs for stolen credentials. The initial access is often hours or days before the first detection.
4. Map lateral movement forward. After establishing a foothold, attackers typically probe and move. Look for east-west traffic from the compromised host: SMB connections to other internal hosts, LDAP queries to domain controllers, Kerberos ticket requests, authentication events in Windows security logs correlated with network events.
5. Identify the objective. What was the attacker after? Data exfiltration shows in outbound large transfers. Ransomware deployment shows in widespread file access patterns. Persistence establishment shows in new scheduled tasks and registry modifications corroborated by authentication anomalies.
6. Build the timeline. Merge all evidence sources into a single chronological narrative, with timestamps normalised to UTC, each event sourced to a specific log line or PCAP frame.

Extracting Files from Packet Captures

One of the most powerful network forensics capabilities is recovering files transmitted over unencrypted protocols — or over TLS where inspection is configured. Malware downloaded over HTTP, documents exfiltrated over FTP, credentials submitted in a web form — all are recoverable from a PCAP if captured.

Using Wireshark Export Objects

Wireshark can reconstruct and export files from HTTP, SMB, FTP, TFTP, and DICOM streams: File → Export Objects → HTTP shows every file transferred over HTTP in the capture. Select all and export — then hash each exported file against VirusTotal.

Using NetworkMiner

NetworkMiner provides automatic file and credential extraction from PCAPs without manual stream analysis. Load a PCAP and it automatically populates tabs for: Hosts (all hosts observed), Files (all files extracted), Messages (emails, chat), Credentials (cleartext usernames and passwords), DNS, and Parameters (form data submitted in HTTP POST requests). For rapid triage of a capture file, NetworkMiner is faster than Wireshark.

Using tshark for Scripted Extraction

# Extract all HTTP objects from a PCAP
tshark -r capture.pcap --export-objects http,/tmp/http-objects/

# Extract DNS queries and answers
tshark -r capture.pcap -Y dns -T fields \
  -e frame.time -e ip.src -e dns.qry.name -e dns.a

# Extract all SMB file transfers
tshark -r capture.pcap -Y "smb2.cmd == 9" -T fields \
  -e frame.time -e ip.src -e ip.dst -e smb2.filename

Identifying Lateral Movement in Network Captures

Each lateral movement technique leaves a characteristic network signature. Knowing what to look for in flow data or PCAPs dramatically accelerates scope determination.

Host Attribution — Who Was at That IP?

Network logs give you IP addresses. Investigations need user identities. Connecting an IP address to a person requires correlating multiple log sources:

• DHCP logs — which MAC address held that IP at the relevant time? DHCP logs give you IP → MAC → hostname
• Active Directory authentication logs — Event ID 4624 on the domain controller includes the source IP and the authenticated username
• Proxy logs — web proxy logs typically record the authenticated username alongside the source IP and timestamp
• Wi-Fi controller logs — wireless clients: MAC address → user identity through 802.1X authentication records

TLS (Transport Layer Security) is the encryption protocol that protects the vast majority of internet traffic — every HTTPS website, every encrypted API call, every secure email. Understanding how it works, what can go wrong with it, and how analysts extract useful information from TLS traffic even without decrypting it is one of the most practically valuable skills in network security.

The TLS Handshake

The TLS handshake establishes an encrypted connection in a sequence of messages:

Critical security note: the ClientHello packet is sent in cleartext. This is by design — the encryption hasn't been established yet. It contains the Server Name Indication (SNI) field — the domain name the client wants to connect to. This is visible to any network observer. It's why security analysts can see which domains a host is communicating with even in encrypted HTTPS traffic — the SNI reveals the destination without decrypting the payload.

TLS Versions — The Deprecation Ladder

X.509 Certificates

A TLS certificate is an X.509 digital document that binds a public key to an identity. The fields that matter most for security analysis:

• Subject — who the certificate was issued to (domain name or organisation)
• Subject Alternative Names (SAN) — additional hostnames the certificate is valid for. A certificate issued to example.com may also cover www.example.com and api.example.com via SANs. Attackers occasionally obtain certificates with SANs that allow lookalike phishing domains.
• Validity period — not before / not after. Expired certificates don't automatically mean a problem (many legitimate systems run with expired certificates) but they warrant investigation.
• Issuer — the Certificate Authority that signed the certificate. Self-signed certificates (where the issuer is the same as the subject) are not trusted by browsers and often indicate development environments, internal infrastructure, or misconfigured/malicious servers.
• Key usage and Extended Key Usage — what the certificate can be used for. A certificate with EKU for "Server Authentication" should only be used by servers. A certificate with EKU for "Code Signing" should only be used to sign code.

PKI — Certificate Authorities and Trust Chains

Certificate Transparency — The Public Log

Certificate Transparency (CT) requires every publicly-trusted certificate to be logged in public, append-only CT logs before browsers will trust it. This means that every certificate issued by a trusted CA is publicly visible in CT logs — including certificates issued for your domains without your knowledge.

Security teams monitor CT logs for certificates issued for their domains. Services like crt.sh allow searching CT logs by domain name. A certificate issued for mail.yourdomain.com that you didn't request may indicate: a misconfigured system in your environment, a subdomain takeover, or an attacker preparing for a phishing campaign against your users. Monitoring CT logs for your domains costs nothing and can provide early warning of these scenarios.

What Analysts Can See Without Decrypting TLS

Despite TLS encryption, significant information is available to network analysts:

• SNI in ClientHello — the target domain name (visible in TLS 1.2; partially encrypted in TLS 1.3 with ECH but widely available)
• Server certificate — the certificate, including subject, SAN, issuer, and validity period (transmitted in plaintext during handshake)
• JA3 client fingerprint — a hash of TLS ClientHello parameters (cipher suites offered, extensions, elliptic curves) that fingerprints the TLS implementation. Different software produces different JA3 hashes. Cobalt Strike has known JA3 hashes; browsers have their own. Matching a JA3 to known malware without decrypting the payload is a detection technique.
• Traffic patterns — packet sizes, timing, connection duration, and byte counts remain visible. These can reveal communication patterns even without content inspection.

The networking concepts in the previous chapters describe how traditional networks are built. Modern cloud and containerised environments use those same fundamental concepts — IP addresses, routing, TCP/IP — but implement them in ways that look dramatically different. This chapter bridges the gap between the foundational knowledge you've built and the architectures you'll encounter in cloud-native environments.

Software-Defined Networking (SDN)

SDN separates the control plane (the "thinking" — routing decisions, policy enforcement) from the data plane (the "doing" — packet forwarding). A centralised SDN controller programs all network devices with forwarding rules via a standard protocol (OpenFlow). This enables: network-wide visibility from a single point, dynamic reprogramming of traffic paths in milliseconds, and consistent policy enforcement across the entire network without manually configuring each device.

Security implications: the SDN controller is a high-value target — compromising it means compromising the routing logic for the entire network. The controller must be secured, access-controlled, and monitored with the same rigour as a domain controller.

Overlay Networks — How Containers Talk

Overlay networks create a virtual network on top of an existing physical or virtual network. This is how Docker, Kubernetes, and cloud VPCs work — virtual IP addresses and virtual switches implemented in software, running on top of whatever physical network exists beneath them.

VXLAN (Virtual Extensible LAN) encapsulates Ethernet frames inside UDP packets, allowing a flat Layer 2 network to span multiple physical hosts, data centres, or cloud regions. Container orchestration (Docker Swarm, Kubernetes) and cloud VPCs all rely on overlay networking. Security relevance: traffic analysis tools that don't understand VXLAN will see only the outer UDP headers — missing the inner Layer 2 frame that carries the actual communication. Security monitoring in containerised environments must be VXLAN-aware.

Service Meshes — Zero Trust Between Microservices

A service mesh is infrastructure that manages service-to-service communication in a microservices architecture. Instead of each service implementing its own TLS, authentication, and retry logic, a service mesh handles this transparently via a sidecar proxy running alongside each service.

Istio and Linkerd are the leading service mesh implementations. Their key security capability: mutual TLS (mTLS) — both sides of every service-to-service connection authenticate each other with certificates. Not just "the server proves its identity to the client" (standard TLS), but "each service proves its identity to the other." This creates a Zero Trust network inside the cluster: no service can talk to another service unless both have valid certificates and the mesh policy explicitly permits the communication.

East-West Traffic — The Internal Visibility Problem

Network monitoring traditionally focuses on north-south traffic — traffic entering and leaving the network perimeter (internet-facing connections). East-west traffic is traffic between systems within the network — server to server, microservice to microservice, container to container.

Lateral movement — an attacker who has compromised one internal system moving to other internal systems — is entirely east-west traffic. It never touches the internet-facing perimeter where most monitoring tools are focused. This is why endpoint detection (EDR) and host-based monitoring are essential complements to network monitoring — they can see what's happening on the internal network even when that traffic never reaches the perimeter.

In cloud and container environments, east-west visibility requires sensors at the cluster level (Falco for containers, VPC Flow Logs for cloud instances) because the overlay network means that traditional network monitoring tools can't see the actual inter-container communication without VXLAN-awareness.

Connecting Cloud Networking to Fundamentals

Everything in AWS, Azure, and GCP networking rests on the fundamentals covered in this module:

• Security Groups are stateful packet filters — the same concept as a stateful firewall, implemented in software. Rules specify source/destination IP (in CIDR notation), port, and protocol — exactly the same concepts as iptables.
• VPCs are subnets — virtual networks carved from the provider's IP space using CIDR notation, with routing tables that determine how traffic flows between them.
• CloudTrail and flow logs are NetFlow equivalents — traffic metadata recording which addresses communicated, on which ports, for how long.
• GuardDuty is a managed IDS — signature-based detection applied to cloud traffic logs, generating alerts for known threat patterns.

Knowledge without practice is theory. Networking knowledge solidifies through doing — capturing packets, reading protocol exchanges, building lab environments, and solving challenges that put the concepts from this module to use. This final chapter provides the practical resources for turning what you've read into usable skill.

The Essential Toolkit

Setting Up a Home Lab

A home network security lab doesn't require expensive hardware. A practical setup:

1. A managed switch with a mirror/SPAN port — many consumer switches (Netgear, TP-Link managed switches) support port mirroring. Configure one port to mirror all traffic on the switch, connect a monitoring host to it. Now you can capture everything your lab generates.
2. A security monitoring VM — install Security Onion (a Linux distribution that bundles Zeek, Suricata, Elasticsearch, and Kibana into a turnkey NSM platform) on a VM connected to the mirror port. Point your browser at its IP and you have a full NSM stack generating Zeek logs and Suricata alerts for your home network.
3. A few virtual machines for targets — Metasploitable3 (intentionally vulnerable Linux VM), DVWA (Damn Vulnerable Web Application), or any Windows VM for protocol experimentation.
4. A capture host — even just a Raspberry Pi running tcpdump at strategic points on your network creates continuous traffic recording.

Practice Resources

• Malware Traffic Analysis (malware-traffic-analysis.net) — a remarkable resource: real PCAP files from actual malware infections with detailed write-ups. Analysing these teaches you to recognise malicious traffic patterns faster than almost any other exercise.
• Wireshark Sample Captures (wiki.wireshark.org/SampleCaptures) — extensive library of protocol-specific captures for learning protocol analysis
• NETRESEC (netresec.com) — curated collection of public PCAP files including network forensics challenges
• CyberDefenders — DFIR and network forensics challenges with PCAP-based investigations
• PicoCTF / CTFtime — Capture the Flag competitions frequently include network forensics challenges
• TryHackMe / HackTheBox — structured learning paths with hands-on labs including network security topics

Certifications

Career Paths in Network Security

• Network Security Engineer — designs, implements, and maintains network security controls: firewalls, IDS/IPS, VPNs, network segmentation. Requires deep networking knowledge alongside security principles.
• SOC Analyst (Network-focused) — monitors network traffic for threats, investigates alerts, performs initial triage on network-based detections. PCAP analysis and Zeek/Suricata proficiency are core skills.
• Network Forensic Analyst — investigates security incidents using network evidence. Reconstructs attack timelines from PCAPs, flow data, and protocol logs. The role most directly built on the skills in this module.
• Network Penetration Tester — assesses the security of networks by attempting to exploit vulnerabilities. Requires deep knowledge of both the attack techniques covered here and the defensive architectures they target.
• Threat Intelligence Analyst (Network-focused) — tracks adversary infrastructure using passive DNS, certificate transparency logs, and network indicators. Connects current attack indicators to historical infrastructure and threat actor patterns.