VU23213 Utilise basic network concepts and protocols required in cyber security

When you send a message, stream a video, or log in to a work portal, your data crosses a chain of hardware and software that neither you nor the person at the other end ever sees. To make that chain understandable, and buildable by different vendors who have never met, the industry describes networking as a stack of layers. Each layer has one job, talks only to the layer directly above and below it, and hands data across a well defined boundary. This is called a layered model, and it is the single most useful mental map you will carry into cyber security work.

Why bother modelling it at all? Two reasons. First, separation of concerns: the team writing a web browser does not need to know whether the data will travel over fibre, copper or Wi-Fi, and the team building a network card does not need to understand HTTP. Each can work to a defined interface. Second, and this is the reason it matters to a security analyst, layers give you a shared vocabulary for where a problem lives. When someone says "that is a layer 7 attack" or "we filter at layer 3 and 4", they are pointing at a precise place in the stack. If you cannot locate an attack in the stack, you cannot reason about the defence.

Two models dominate. The OSI model is the seven-layer teaching and reference model. The TCP/IP model is the four or five-layer model that the real internet actually runs on. You need both: OSI for talking and thinking, TCP/IP for what is genuinely deployed.

The seven OSI layers

The Open Systems Interconnection (OSI) model was published by the International Organization for Standardization and describes networking as seven stacked layers (Cloudflare Learning Center, "What is the OSI model?", no publication date shown); (Wikipedia, "OSI model", continuously updated). Working from the bottom up:

Physical layer (layer 1). The raw transmission of bits as electrical, optical or radio signals over a medium. It defines cables, connectors, voltages, pin-outs and radio frequencies. Concrete example: the Ethernet copper cable running to your desk, or the Wi-Fi radio signal at 5 GHz carrying ones and zeros as changes in the signal.

Data link layer (layer 2). Moves data between two directly connected nodes on the same local network, and adds physical addressing (MAC addresses) plus basic error detection. Concrete example: an Ethernet switch reading the destination MAC address in a frame and forwarding it out of the correct port.

Network layer (layer 3). Handles logical addressing and routing, so data can cross between separate networks and reach a host anywhere. Concrete example: a router reading a destination IPv4 address and choosing the next hop toward the internet.

Transport layer (layer 4). Provides end-to-end delivery between two applications, with either reliability and ordering (TCP) or speed with no guarantees (UDP), plus port numbers to identify the application. Concrete example: TCP breaking a large file into numbered segments, retransmitting any that are lost, and reassembling them in order.

Session layer (layer 5). Establishes, manages and tears down the conversation (session) between two applications, including dialogue control. Concrete example: keeping a remote login session organised so requests and responses stay matched.

Presentation layer (layer 6). Translates, encrypts and compresses data into a form the application layer can use, so both ends agree on format. Concrete example: character encoding, or the encryption and decryption work associated with TLS sitting here in the classic model.

Application layer (layer 7). The layer the user and the software actually interact with; the protocols that deliver a service. Concrete example: HTTP loading a web page, or SMTP handing off an email.

A common way to remember the order, top to bottom, is the phrase "All People Seem To Need Data Processing" (Application, Presentation, Session, Transport, Network, Data link, Physical) (as a widely used mnemonic).

Where OSI is a simplification

Update, current as at August 2026. The classic seven-layer OSI model is a teaching device, and the neat separation of layers 5, 6 and 7 does not map cleanly onto modern software. TLS encryption, for example, is often described as "presentation layer" work, but in practice it is implemented as a distinct layer between TCP and the application and does not sit tidily in the OSI boxes. Treat OSI as a map, not as the territory; it is excellent for locating problems and poor as a literal description of any real program.

Encapsulation and decapsulation

Data does not teleport from layer 7 on one machine to layer 7 on another. It travels down the sender's stack, across the wire, and up the receiver's stack. As it goes down, each layer wraps the data from the layer above in its own header (and sometimes a trailer). This wrapping is called encapsulation. On the receiving side the reverse happens: each layer reads and strips its own header, then passes the remainder up. That is decapsulation.

Think of it as putting a letter inside an envelope, that envelope inside a courier satchel, that satchel inside a shipping container. Each layer of packaging carries the addressing that layer needs, and each is opened by its counterpart at the destination.

flowchart TD
 subgraph Sender["Sender: data travels DOWN the stack (encapsulation)"]
 A7["L7 Application: Data"] --> A4["L4 Transport: adds TCP/UDP header = Segment"]
 A4 --> A3["L3 Network: adds IP header = Packet"]
 A3 --> A2["L2 Data link: adds MAC header + trailer = Frame"]
 A2 --> A1["L1 Physical: transmitted as Bits"]
 end
 A1 -->|signals across the medium| B1
 subgraph Receiver["Receiver: data travels UP the stack (decapsulation)"]
 B1["L1 Physical: Bits"] --> B2["L2 Data link: reads + strips MAC header"]
 B2 --> B3["L3 Network: reads + strips IP header"]
 B3 --> B4["L4 Transport: reads + strips TCP/UDP header"]
 B4 --> B7["L7 Application: Data delivered"]
 end

Protocol data units: the name changes at each layer

The chunk of data has a different name depending on which layer you are looking at. These names are called protocol data units (PDUs), and using them precisely marks you out as someone who understands the stack:

Bit. The PDU at the physical layer; a single one or zero on the medium.

Frame. The PDU at the data link layer; the payload wrapped in a MAC header and trailer.

Packet. The PDU at the network layer; the payload wrapped in an IP header.

Segment. The PDU at the transport layer under TCP (a datagram under UDP); the application data with a TCP or UDP header.

Notice the direction. When people say a firewall "inspects packets", they are pointing at layer 3; when they say it does "deep packet inspection" up to the application content, they mean it reads well past the layer 3 header into the payload.

The TCP/IP model and how it maps to OSI

The internet does not literally run on OSI; it runs on the TCP/IP model, which predates OSI's formal adoption and is described in the IETF's foundational documents (RFC 1122, "Requirements for Internet Hosts", October 1989). TCP/IP is usually drawn with four layers, and sometimes five when the physical medium is split out from the data link.

The four-layer version, top to bottom: Application, Transport, Internet, and Link (also called Network access). The five-layer teaching variant splits that bottom Link layer into Data link and Physical, which makes the mapping to OSI easier to see.

How they line up:

TCP/IP (four-layer)	TCP/IP (five-layer)	OSI layers it covers
Application	Application	7 Application, 6 Presentation, 5 Session
Transport	Transport	4 Transport
Internet	Internet	3 Network
Link / Network access	Data link + Physical	2 Data link, 1 Physical

The key thing to hold onto: TCP/IP folds OSI's top three layers into one Application layer, because on the real internet the session, presentation and application concerns are handled inside application protocols rather than as separate network layers. When you meet HTTP, DNS, TLS and SMTP later, they all live in this single TCP/IP Application layer even though a purist would scatter them across OSI layers 5 to 7.

Why a cyber analyst thinks in layers

Attacks and defences each sit at a layer, and naming the layer tells you which tool applies and which team owns the problem. A rough map:

• Physical (layer 1). Threats: cable tapping, radio jamming, someone plugging a rogue device into a wall port. Defence: physical access control, port security.
• Data link (layer 2). Threats: MAC spoofing, ARP poisoning, rogue switches, VLAN hopping. Defence: switch port security, dynamic ARP inspection, 802.1X.
• Network (layer 3). Threats: IP spoofing, routing attacks, network-layer denial of service. Defence: router access control lists, IP filtering, anti-spoofing.
• Transport (layer 4). Threats: TCP SYN floods, port scanning. Defence: stateful firewalls, rate limiting, SYN cookies.
• Application (layer 7). Threats: SQL injection, cross-site scripting, application denial of service, credential stuffing. Defence: a web application firewall (WAF), input validation, authentication controls.

This is why you will hear a denial-of-service attack described as "layer 3/4" (flooding the network or transport layer with traffic) versus "layer 7" (exhausting the application with expensive requests); the defence differs completely (Cloudflare Learning Center, "What is a DDoS attack?", no publication date shown). When you can place a threat on the stack, you already know most of what you need to respond to it.

Computers and networks do not count in tens. Underneath everything, a network device stores and moves information as bits, each bit being a single on or off, one or zero. To read addresses, masks and packet captures with any confidence, you need to be comfortable moving between three number systems: decimal (base 10, what humans count in), binary (base 2, what the machine actually uses), and hexadecimal (base 16, a compact shorthand for binary).

Binary, base 2

Binary uses only two digits, 0 and 1. Each position is a power of two, doubling as you step left. For an eight-bit group (one byte, also called an octet), the position values are:

128 64 32 16 8 4 2 1

To read a binary number, add up the position values wherever there is a 1. For example, 1100 0000 has 1s in the 128 and 64 positions, so it equals 128 + 64 = 192. An eight-bit octet can represent 0 (all zeros) through 255 (all ones, 128+64+32+16+8+4+2+1), which is exactly the range you see in each part of an IPv4 address.

Worked example, decimal to binary

To convert 192 to binary, work left to right through the position values, subtracting where you can:

1. Does 128 fit into 192? Yes. Write 1. Remainder 64.
2. Does 64 fit into 64? Yes. Write 1. Remainder 0.
3. 32, 16, 8, 4, 2, 1 all fit into 0? No. Write 0 for each.

Result: 1100 0000. The spacing into groups of four (a "nibble") is only for readability.

Hexadecimal, base 16

Hexadecimal (hex) uses sixteen digits: 0 to 9, then A, B, C, D, E, F for the values ten to fifteen. Its usefulness comes from a clean fit with binary: one hex digit represents exactly four bits, because four bits can hold sixteen values (0000 to 1111). That makes hex a compact way to write long binary strings without losing the bit-level meaning.

The four-bit mapping is worth memorising:

Binary	Hex	Decimal	Binary	Hex	Decimal
0000	0	0	1000	8	8
0001	1	1	1001	9	9
0010	2	2	1010	A	10
0011	3	3	1011	B	11
0100	4	4	1100	C	12
0101	5	5	1101	D	13
0110	6	6	1110	E	14
0111	7	7	1111	F	15

Worked example, binary to hex and back

Take the octet 1100 0000. Split it into two nibbles: 1100 and 0000. From the table, 1100 is C and 0000 is 0, so the byte is C0 in hex. Going back is just as direct: C0 becomes 1100 0000, which we already showed equals decimal 192. So 192 decimal, 1100 0000 binary, and C0 hex are three ways of writing the same value. Hex is often written with a 0x prefix (0xC0) or, in MAC addresses, with colons between byte pairs.

Why networking uses binary and hex

You cannot avoid these systems in network and security work, because the addressing schemes are built on them:

• IPv4 octets are eight-bit binary numbers shown in decimal. The address 192.168.1.1 is really four octets of binary; you can only understand subnetting once you can see the bits underneath the decimal.
• Subnet masks are binary too. A mask such as 255.255.255.0 is a run of 1s followed by a run of 0s; the boundary between them is what splits the network part of an address from the host part. Reading masks in binary is the whole trick of subnetting.
• MAC addresses are written in hex. A 48-bit hardware address is far more readable as twelve hex digits than as forty-eight ones and zeros.
• IPv6 is written in hex. A 128-bit address would be unreadable in binary or decimal, so IPv6 is grouped into eight blocks of four hex digits.

The practical takeaway for an entry level trainee: when you read 255.255.255.0, train yourself to also see 11111111.11111111.11111111.00000000; and when you read a MAC or IPv6 address, remember each hex digit is standing in for four bits. That habit is what turns addresses from mysterious strings into information you can reason about.

A device needs an address so that data can find it, in the same way a letter needs a street address. But networking uses more than one kind of address at once, at different layers, for different jobs. The two that matter most are the MAC address (layer 2, for the local hop) and the IP address (layer 3, for the end-to-end journey). Understanding which is which, and why both exist, clears up a great deal of confusion.

MAC addresses

A Media Access Control (MAC) address is a 48-bit hardware address assigned to a network interface, operating at layer 2, the data link layer (Wikipedia, "MAC address", continuously updated). It is written as twelve hexadecimal digits, usually in six colon-separated or hyphen-separated pairs, for example 00:1A:2B:3C:4D:5E.

The 48 bits are split into two halves. The first 24 bits are the Organisationally Unique Identifier (OUI), assigned to the manufacturer by the IEEE; the last 24 bits are chosen by that manufacturer to make each interface unique. Because the OUI identifies the vendor, you can often tell from a MAC address whether an interface is made by, say, a particular laptop or phone manufacturer.

The important property for security is that a MAC address has only local significance. It is used to deliver a frame across a single link, from one device to the next switch or router; it does not travel end to end across the internet. As a frame is routed from network to network, the source and destination MAC addresses are rewritten at each hop, while the IP addresses stay the same. This is why a MAC address alone cannot tell you where a remote attacker is; it only ever describes the local segment.

Spoofing risk

A MAC address is assigned in hardware but is not fixed in software; most operating systems let you change the MAC an interface presents. Changing it is called MAC spoofing, and attackers use it to impersonate another device, bypass MAC-based access control lists, or evade filtering (Wikipedia, "MAC spoofing", continuously updated). Because MAC filtering is so easily defeated, it is treated as a weak control and never relied on alone; stronger link-layer defences such as 802.1X port authentication are preferred.

Did you know?

Because a device's Wi-Fi interface broadcasts its MAC address while scanning for networks, that fixed address could once be used to track a phone as it moved between shops and venues. To counter this, Apple, Google and Microsoft now use MAC address randomisation, where the device presents a rotating, randomly generated MAC to networks it has not joined. Update, current as at August 2026: randomised MACs are the default behaviour on current iOS, Android and Windows, so the MAC you capture from a nearby unknown device is often not its real hardware address at all. It is a neat example of a privacy defence being built directly on top of a layer 2 detail.

IPv4 addresses

An Internet Protocol version 4 (IPv4) address is a 32-bit logical address operating at layer 3, the network layer (RFC 791, "Internet Protocol", September 1981). It is written in dotted decimal notation: four octets of eight bits each, separated by dots, such as 192.168.1.10. Each octet ranges from 0 to 255, so the whole space is about 4.3 billion addresses, a number that felt limitless in 1981 and is now exhausted.

Classes, and why they are history

Early IPv4 divided the address space into classes A, B and C by fixed size. Classful addressing was wasteful, because an organisation needing a few hundred addresses had to take a whole class B block of over sixty-five thousand. It was replaced in 1993 by Classless Inter-Domain Routing (CIDR), which lets the network and host boundary fall at any bit position (RFC 4632, "Classless Inter-domain Routing (CIDR)", August 2006). You will still hear "class C" used loosely to mean a /24 network; treat the classes as historical vocabulary, not as how addressing actually works now.

Subnet masks and CIDR notation

A subnet mask marks which part of an address is the network and which is the host. In binary it is a run of 1s (network) followed by a run of 0s (host). The mask 255.255.255.0 is twenty-four 1s then eight 0s, so the first three octets identify the network and the last octet identifies the host. CIDR notation writes this as a slash and the count of network bits: 192.168.1.0/24 means a 24-bit network prefix, leaving 8 bits (256 addresses) for hosts. This is exactly where your binary practice pays off; subnetting is reading the boundary in the mask.

Private ranges and NAT

Not every IPv4 address is reachable from the public internet. Three ranges are reserved for private use inside organisations and homes (RFC 1918, "Address Allocation for Private Internets", February 1996):

• 10.0.0.0/8 (10.0.0.0 to 10.255.255.255)
• 172.16.0.0/12 (172.16.0.0 to 172.31.255.255)
• 192.168.0.0/16 (192.168.0.0 to 192.168.255.255)

These private addresses are not routed on the public internet, so many devices can reuse them behind a single public address. The mechanism that lets them share one public address is Network Address Translation (NAT), performed by the router: it rewrites the private source address to its own public address on the way out, and reverses the mapping on the way back (RFC 3022, "Traditional IP Network Address Translator", January 2001). NAT is a large part of how IPv4 survived address exhaustion, and it is why the address your laptop shows internally is almost never the address a website sees. For an analyst, that distinction between public and private, and the translation between them, matters when reading logs; the private source in an internal log may all sit behind one public IP externally.

IPv6 addresses

Internet Protocol version 6 (IPv6) is the long-term answer to IPv4 exhaustion. It uses a 128-bit address, an address space so large it is effectively inexhaustible for any practical purpose (RFC 8200, "Internet Protocol, Version 6 (IPv6) Specification", July 2017). Because 128 bits would be unreadable in decimal, IPv6 is written in hexadecimal: eight groups of four hex digits separated by colons, for example 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

IPv6 notation allows two shortenings. Leading zeros in a group may be dropped (0db8 becomes db8), and one run of consecutive all-zero groups may be replaced with a double colon :: (used once only). So the address above compresses to 2001:db8:85a3::8a2e:370:7334 (RFC 4291, "IP Version 6 Addressing Architecture", February 2006).

Address types

IPv6 does away with broadcast and organises addresses by scope and purpose. The main types to recognise:

• Global unicast, the publicly routable addresses, roughly the IPv6 equivalent of a public IPv4 address.
• Link-local, beginning fe80::, valid only on the local link and automatically configured on every IPv6 interface.
• Unique local, beginning fd00::/8 in practice, the rough IPv6 counterpart to RFC 1918 private space, for internal use.
• Multicast, beginning ff00::, delivering to a group of interfaces; IPv6 uses multicast where IPv4 used broadcast.

SLAAC and dual stack

A notable IPv6 feature is that a host can configure its own address without a DHCP server, using Stateless Address Autoconfiguration (SLAAC): the router advertises the network prefix, and the host combines it with an interface identifier to build its own global address (RFC 4862, "IPv6 Stateless Address Autoconfiguration", September 2007). Because the internet cannot switch over in one step, most networks run dual stack, carrying IPv4 and IPv6 side by side on the same interfaces, so a device can reach both older IPv4-only and newer IPv6 destinations.

Update, current as at August 2026. IPv6 adoption continues to climb but is far from total; a large share of global traffic reaching major providers now arrives over IPv6, while plenty of networks remain IPv4-only or dual stack (adoption figures move over time, see Google's IPv6 statistics for the current number). For a security analyst the practical warning is this: a control, a firewall rule or a log filter written only for IPv4 can silently miss IPv6 traffic on a dual-stack host, leaving a gap an attacker can use. Treat both stacks as in scope.

Once the network layer (IP) has worked out how to get a packet from one machine to another, something has to decide what happens to that data when it arrives, whether it arrived at all, and which program on the receiving machine should get it. That is the job of the transport layer, the fourth layer in the OSI model and the layer just above IP in the TCP/IP model. Two protocols do almost all of this work on the modern internet: TCP and UDP.

Transport layer: the layer responsible for host-to-host communication between applications, providing either a reliable ordered stream (TCP) or a lightweight best-effort datagram service (UDP), and using port numbers to direct traffic to the correct application.

For an entry level trainee, this is one of the most useful layers to understand well, because so much of what a security analyst reads in a packet capture, a firewall log or an intrusion detection alert is expressed in the language of TCP and UDP: ports, flags, sequence numbers and connection state.

TCP: the reliable, connection-oriented protocol

TCP (Transmission Control Protocol) is defined originally in RFC 793 and updated and consolidated in RFC 9293 (2022). It is described as connection-oriented, which means the two ends agree to talk before any application data is sent, and reliable, which means TCP will detect lost or corrupted segments and arrange for them to be sent again.

TCP gives the application several guarantees:

• Reliability. Every byte sent is acknowledged; anything not acknowledged is retransmitted.
• Ordering. Data is delivered to the application in the order it was sent, even if the underlying packets arrive out of order.
• Flow control. The receiver advertises a "window" telling the sender how much it can accept, so a fast sender does not overwhelm a slow receiver.
• Congestion control. TCP backs off when the network shows signs of congestion (loss or delay), which is a large part of why the internet does not collapse under load.

To provide ordering and reliability, TCP numbers every byte with a sequence number, and the receiver returns acknowledgement (ACK) numbers to say "I have received everything up to here". These numbers, and the connection state, are why TCP is sometimes called a stateful protocol.

The three-way handshake

Before any data flows, the two ends establish a connection with a three-way handshake, using the SYN and ACK control flags in the TCP header. The client sends a SYN (synchronise) with its starting sequence number; the server replies with a SYN-ACK (its own SYN plus an acknowledgement of the client's); the client replies with an ACK. After that exchange the connection is open and data can flow in both directions.

sequenceDiagram
 participant C as Client
 participant S as Server
 C->>S: SYN (seq = x)
 S->>C: SYN-ACK (seq = y, ack = x + 1)
 C->>S: ACK (ack = y + 1)
 Note over C,S: Connection established; data can now flow

Why should a security analyst care about the exact steps? Because the handshake is where several classic attacks live, and because the state of a connection (half-open, established, closing) is exactly what firewalls and detection tools track. If you understand that the server allocates resources when it sends the SYN-ACK and then waits for the final ACK, you already understand the mechanism of a SYN flood: an attacker sends many SYNs, never completes the handshake, and tries to exhaust the server's table of half-open connections. SYN floods and related denial-of-service techniques are examined in the attacks section later on; for now the point is that the handshake itself is the thing being abused.

Tearing the connection down

TCP closes as deliberately as it opens. Each side sends a FIN (finish) flag when it has no more data to send, and the other side acknowledges it, so a normal close is a four-step exchange (FIN, ACK, FIN, ACK). A connection can also be cut abruptly with an RST (reset) flag, which says "discard this connection now"; unexpected RSTs in a capture are often worth a second look, because both firewalls and attackers use them to tear connections down.

UDP: the lightweight, connectionless protocol

UDP (User Datagram Protocol), defined in the short and readable RFC 768 (1980), is the opposite trade-off. It is connectionless: there is no handshake, no sequence numbers, no acknowledgements, no retransmission and no built-in ordering. A UDP datagram is sent and the sender simply hopes it arrives. In exchange for giving up reliability, UDP is lightweight and fast, with a tiny eight-byte header and no connection state to set up or maintain.

Why would anyone want an unreliable protocol? Because for some traffic, speed and low overhead matter more than guaranteed delivery, and the application can handle any loss itself. Common uses include:

• DNS lookups, where a query and reply are usually a single small exchange and it is cheaper to just ask again than to hold a connection open.
• Voice over IP (VoIP) and real-time video, where a retransmitted packet would arrive too late to be useful; a brief glitch is better than a stall.
• Online gaming, for the same real-time reason.
• Some logging and telemetry, and protocols such as DHCP that need to work before a device even has an IP configuration.

Ports and sockets

Both TCP and UDP use port numbers, 16-bit numbers (0 to 65535) that identify which application or service the traffic belongs to. An IP address gets you to the right machine; the port gets you to the right program on that machine. A web server typically listens on TCP port 443 (HTTPS), an email submission service on 587, DNS on port 53 (usually UDP, sometimes TCP).

The combination of an IP address and a port number is called a socket, and a TCP connection is uniquely identified by the four values of source IP, source port, destination IP and destination port (the "four-tuple"). This is worth internalising, because it is exactly how a firewall or a NAT device tells one connection apart from another.

Port numbers are administered by IANA. The range 0 to 1023 is the well-known ports, assigned to common services; 1024 to 49151 are registered ports; and 49152 to 65535 are the dynamic or ephemeral ports that clients use as their own source port. The authoritative list is the IANA Service Name and Transport Protocol Port Number Registry.

A short table of ports worth knowing on sight:

Port	Protocol	Service
20, 21	TCP	FTP (data, control)
22	TCP	SSH
25	TCP	SMTP (mail transfer)
53	UDP/TCP	DNS
67, 68	UDP	DHCP (server, client)
80	TCP	HTTP
123	UDP	NTP (time)
443	TCP/UDP	HTTPS (UDP for HTTP/3 over QUIC)
445	TCP	SMB
3389	TCP	RDP (remote desktop)

Did you know?

The difference a security analyst cares about most between TCP and UDP is not reliability; it is visibility and spoofability. Because TCP requires a completed handshake, it is hard to fully spoof a source address over TCP: the attacker would need to receive the SYN-ACK to reply with a valid ACK. UDP has no such barrier, so it is trivial to forge a source address on a single UDP datagram. That is why so many reflection and amplification denial-of-service attacks (DNS, NTP, memcached) are built on UDP: the attacker spoofs the victim's address as the source, and the innocent server sends a much larger reply to the victim. Knowing which services run over UDP tells you where that risk lives.

TCP, UDP and IP all talk in terms of IP addresses, but on a local network (a single Ethernet or Wi-Fi segment) devices do not actually deliver frames to an IP address. They deliver to a MAC address, the hardware address burned into (or assigned to) each network interface. So there has to be something that answers the question, "I want to send to IP 192.168.1.10; which MAC address is that, right here on this segment?" That something is ARP.

ARP (Address Resolution Protocol): the protocol that maps a known IPv4 address to the MAC (hardware) address of a device on the same local network segment, so that frames can be delivered at the data link layer. Defined in RFC 826 (1982).

How ARP works

The mechanism is simple, which is both its strength and its weakness. When a device needs the MAC address for an IPv4 address on its own segment, it broadcasts an ARP request: a frame sent to every device on the segment asking, in effect, "Who has 192.168.1.10? Tell 192.168.1.5." Every device sees the broadcast, but only the device that owns that IP is expected to answer, with a unicast ARP reply: "192.168.1.10 is at MAC aa:bb:cc:dd:ee:ff." The requester stores that mapping and can now send frames directly.

To avoid asking every single time, each device keeps an ARP cache (also called the ARP table), a short-lived list of recently learned IP-to-MAC mappings. Entries time out after a while, so the cache stays reasonably current. On Windows, macOS and Linux you can view it with arp -a, which is a quick and genuinely useful command for an entry level trainee to try on their own machine.

There is also gratuitous ARP: an ARP reply (or request) that a device sends without being asked, announcing its own IP-to-MAC mapping to the whole segment. Legitimately this is used to update everyone's cache after a change, for example when a device boots, when an IP is reassigned, or when a failover pair swaps which physical machine holds a shared address. Every other device that hears it updates its cache accordingly.

sequenceDiagram
 participant A as Host A (192.168.1.5)
 participant N as All hosts on segment (broadcast)
 participant B as Host B (192.168.1.10)
 A->>N: ARP request (broadcast): Who has 192.168.1.10?
 B->>A: ARP reply (unicast): 192.168.1.10 is at aa:bb:cc:dd:ee:ff
 Note over A: A caches the mapping and sends frames to B

Why ARP is a security problem

Here is the question that matters. When a device receives an ARP reply, how does it check that the reply is true? It does not. ARP has no authentication of any kind. There is nothing in the protocol that ties an IP-to-MAC claim to any proof, and most implementations will happily accept and cache an ARP reply, or a gratuitous ARP, even if they never sent a matching request. ARP is entirely trust-based; it assumes everyone on the local segment is honest.

That assumption is the whole basis of ARP poisoning (also called ARP spoofing). An attacker on the same segment sends forged ARP replies that claim, for example, that the router's IP belongs to the attacker's MAC address. Devices update their caches with the lie, and start sending the attacker traffic they meant to send to the router. If the attacker also poisons the router's cache the other way, the attacker sits invisibly in the middle of the conversation, a machine-in-the-middle position from which they can read, record or alter traffic that is not encrypted. Because it operates at the local segment level, ARP poisoning is a launch pad for further attacks (session interception, DNS manipulation, credential capture).

The mechanism is described here at concept level; the ARP poisoning attack itself, along with defences such as dynamic ARP inspection, DHCP snooping and encrypted transport, is picked up in the attacks section later. The single idea to carry forward is that ARP was designed in 1982 for a small, trusted network, and it has no way to tell a true answer from a forged one.

Did you know?

ARP is IPv4 only. IPv6 does not use ARP at all; it replaces it with Neighbour Discovery Protocol (NDP), which runs over ICMPv6 and provides similar functions (finding neighbours, discovering routers) plus optional security extensions. As networks move to IPv6 the vocabulary changes, but the underlying trust problem on a local segment does not disappear on its own; NDP has its own spoofing concerns unless features such as RA Guard are enabled.

Two services quietly make everyday networking usable. One lets you type a name instead of memorising a number; the other hands a new device everything it needs to join a network without anyone touching a keyboard. Neither was designed with much security in mind, and both are regular targets, so an entry level trainee should understand how they work and where they are weak.

DNS: the internet's directory

DNS (Domain Name System): the distributed, hierarchical naming system that translates human-readable domain names such as cyber.gov.au into the IP addresses that machines route to. The foundational specifications are RFC 1034 and RFC 1035 (1987).

DNS is a hierarchy, best read from right to left. At the top sits the root, represented by an implied trailing dot. Below the root are the top-level domains (TLDs) such as .com, .org and .au. Below those are the domains that organisations register, and below those any subdomains they create. The authoritative server for a domain is the server that holds the real, definitive records for it; it is the source of truth for that zone.

Most devices do not walk this hierarchy themselves. They ask a resolver (also called a recursive resolver), often run by the ISP or a public provider such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8, to do the work and return an answer. There are two styles of lookup involved:

• Recursive resolution. The client asks the resolver for the final answer and expects the resolver to chase it down and return it.
• Iterative resolution. The resolver queries the hierarchy step by step: it asks a root server, which refers it to the correct TLD server, which refers it to the authoritative server, which gives the answer. Each server returns the best referral it has rather than the final answer.

A helpful way to explain caching and TTL: every answer comes with a time to live (TTL), a number of seconds the resolver is allowed to remember it. Until the TTL expires, repeat questions are answered from cache, which makes DNS fast and keeps load off the authoritative servers. When you change a DNS record, the old value can linger in caches around the world until its TTL runs out, which is why DNS changes are not instant.

DNS stores different record types for different purposes. The common ones:

Record	Purpose
A	Maps a name to an IPv4 address
AAAA	Maps a name to an IPv6 address
CNAME	Alias; points one name at another name
MX	Mail exchange; where email for the domain should be delivered
NS	Names the authoritative name servers for the zone
TXT	Arbitrary text; used for domain verification and email security records such as SPF, DKIM and DMARC
PTR	Reverse lookup; maps an IP address back to a name

flowchart TD
 A["Client asks resolver:<br/>where is www.example.com?"] --> B["Recursive resolver"]
 B -->|"1. ask root"| C["Root server"]
 C -->|"referral to.com"| B
 B -->|"2. ask.com TLD"| D["TLD server (.com)"]
 D -->|"referral to authoritative"| B
 B -->|"3. ask authoritative"| E["Authoritative server<br/>for example.com"]
 E -->|"A record: 93.184.x.x"| B
 B -->|"answer (cached with TTL)"| A

Where is DNS weak? Because a resolver caches whatever answer it accepts, an attacker who can inject a forged reply can poison the cache, so the resolver hands out a wrong (attacker-controlled) IP address to everyone who asks, until the TTL expires. This is DNS spoofing or cache poisoning, and it can silently redirect users to a malicious server. The concept is introduced here; the attack and its defence, DNSSEC (which signs records so forgeries can be detected) and encrypted DNS such as DNS over HTTPS and DNS over TLS, are examined in the later sections. Cloudflare has an accessible explainer on how DNS works at the Cloudflare Learning Center (no publication date shown on the page).

DHCP: automatic configuration

When a laptop joins a Wi-Fi network, how does it get an IP address, a subnet mask, a default gateway and a DNS server to use, without anyone configuring it by hand? DHCP does that.

DHCP (Dynamic Host Configuration Protocol): the protocol that automatically assigns IP addresses and related network configuration to devices as they join a network. Defined in RFC 2131 (1997).

DHCP works through a four-step exchange remembered by the acronym DORA:

1. Discover. The new client, with no address yet, broadcasts a DHCPDISCOVER asking any DHCP server on the segment to offer it a configuration.
2. Offer. A DHCP server replies with a DHCPOFFER, proposing an available IP address and the accompanying settings.
3. Request. The client broadcasts a DHCPREQUEST formally asking for the offered address (broadcast, so that any other servers that also made offers know their offer was declined).
4. Acknowledge. The server confirms with a DHCPACK, and the client may now use the address.

sequenceDiagram
 participant C as New client (no IP yet)
 participant S as DHCP server
 C->>S: DHCPDISCOVER (broadcast)
 S->>C: DHCPOFFER (here is an address)
 C->>S: DHCPREQUEST (I will take it)
 S->>C: DHCPACK (confirmed; here are your settings)

An assigned address is not permanent; it is a lease, valid for a set time. The client renews the lease before it expires, and if a device leaves, its address eventually returns to the pool for reuse. This is why the same laptop can get a different address on different days.

Why does DHCP matter to security? Because it too is unauthenticated, a client will accept configuration from whichever DHCP server answers first. A rogue DHCP server, planted by an attacker or connected by accident, can hand out a configuration that points the victim's default gateway or DNS server at the attacker, quietly routing traffic through attacker-controlled infrastructure. This is another machine-in-the-middle foothold, and the switch feature that defends against it, DHCP snooping, is noted in the later sections. For now, register that "the network told my device where to send its traffic" is a trust decision made automatically, dozens of times a day, with no verification.

The protocols above move bytes and resolve names; the protocols in this section are what applications actually speak. For a security analyst these are where a great deal of both legitimate traffic and attacker traffic lives, so it pays to know them well.

HTTP: the language of the web

HTTP (Hypertext Transfer Protocol): the request-response protocol that web browsers and servers use to exchange web pages, images, API data and more. The current core specifications are the HTTP semantics in RFC 9110 (2022).

HTTP follows a simple request-response pattern: the client (usually a browser) sends a request, and the server returns a response. A request names a method, a path and a set of headers; a response carries a status code, headers and usually a body.

The common methods describe what the client wants to do:

• GET retrieves a resource.
• POST submits data to the server (a form, an API call).
• PUT and PATCH create or update a resource.
• DELETE removes one.
• HEAD asks for just the headers, no body.

Status codes, grouped by their first digit, tell the client how the request went: 1xx informational, 2xx success (200 OK), 3xx redirection (301 moved permanently), 4xx client error (404 not found, 403 forbidden), 5xx server error (500 internal server error). Mozilla's MDN keeps a thorough, current reference of HTTP response status codes (MDN is continuously updated).

A property worth understanding is that HTTP is stateless: each request is independent, and the protocol itself remembers nothing between them. Anything that feels like a continuous session (being logged in, a shopping cart) is layered on top using headers, most often cookies that the browser sends back with each request. Headers carry a great deal besides cookies: the content type, caching instructions, authentication tokens and a growing set of security headers such as Strict-Transport-Security and Content-Security-Policy.

The catch is that plain HTTP sends everything in clear text. Anyone positioned to read the traffic (recall the ARP and DHCP footholds above) can see every page, form field and cookie. That is the problem HTTPS solves.

HTTPS and TLS

HTTPS is not a separate protocol so much as HTTP carried inside an encrypted channel. That channel is provided by TLS.

TLS (Transport Layer Security): the cryptographic protocol that secures data in transit, providing confidentiality, integrity and authentication for protocols layered on top of it. The current version is defined in RFC 8446 (2018) for TLS 1.3.

TLS gives three things, worth naming precisely because they map to the core security goals:

• Confidentiality. The data is encrypted, so an eavesdropper sees only ciphertext.
• Integrity. Tampering with the data in transit is detected.
• Authentication. The client can verify it is really talking to the server it intended, using a certificate.

At a conceptual level, the TLS handshake does three jobs before any application data flows: the two ends agree on which cryptographic algorithms to use, the server proves its identity with a certificate, and they establish shared secret keys (using public-key cryptography to bootstrap, then fast symmetric keys for the actual data). Once the handshake completes, the HTTP request and response travel encrypted.

Authentication rests on certificates and certificate authorities (CAs). A server presents a digital certificate that binds its domain name to a public key; that certificate is signed by a CA that browsers already trust. Your browser checks the signature chain up to a trusted root, and checks that the certificate matches the site name and has not expired or been revoked. If the chain does not check out, you see the familiar certificate warning. This trust model, and modern additions such as Certificate Transparency logs, is the reason a padlock means something.

On versions: TLS 1.2 (RFC 5246, 2008) is still widely used and considered acceptable when well configured; TLS 1.3 (2018) is faster (a shorter handshake) and drops a range of older, weaker options, and is now the preferred version. Its predecessor, SSL (Secure Sockets Layer), is obsolete: SSL 2.0 and SSL 3.0 are deprecated and insecure, and should not be used; the name "SSL" survives only in casual speech and product names. The IETF formally deprecated TLS 1.0 and 1.1 in RFC 8996 (2021) as well.

Did you know?

People still say "SSL certificate", but there has been no SSL for years; the certificates are X.509 certificates used by TLS. The habit is harmless in conversation, but in a report or a configuration it is worth being precise, because "we still allow SSLv3" and "we still allow TLS 1.3" are opposite statements about a system's safety.

SMB: file and printer sharing

Not everything runs over the web. On corporate and home networks, one of the most important protocols is SMB.

SMB (Server Message Block): the protocol used mainly on Windows networks for sharing files, printers and other resources between machines. It typically runs over TCP port 445.

SMB is what lets you open a shared drive such as \\server\finance or print to a networked printer. It has gone through several versions: SMBv1 is the original, dating from the late 1980s; SMBv2 arrived with Windows Vista; and SMBv3, the current generation, added meaningful security including encryption of SMB traffic.

Why is SMBv1 singled out as dangerous? Because it is old, complex and full of weaknesses, has no support for the modern protections in SMBv3, and has been the vehicle for some of the most damaging attacks on record. Microsoft now disables or removes SMBv1 by default on current Windows, and its own long-standing guidance is to stop using SMBv1 (Microsoft Learn, last updated 11 March 2025).

The most vivid reason is WannaCry. In May 2017 the WannaCry ransomware spread worldwide, including into the UK's National Health Service, by exploiting a vulnerability in SMBv1 using an exploit known as EternalBlue. Machines that had not applied Microsoft's patch, or that still exposed SMBv1, were infected and could infect their neighbours automatically, with no user action. WannaCry and EternalBlue are used as a case study in the attacks section later; the pointer here is simply that a stale file-sharing protocol left enabled is not a harmless convenience, it is an exposure.

Update, current as at August 2026.

The training package treats the transport layer as TCP and UDP, full stop, and treats the web as HTTP over TCP. That picture is now out of date, and this is exactly the kind of current-practice gap this study journal exists to fill. A large and growing share of web traffic no longer uses TCP at all; it uses QUIC. If you look at a modern packet capture and wonder why the connections to Google, YouTube, Facebook, Cloudflare-fronted sites and much of the rest of the web look like UDP rather than the familiar TCP handshake, QUIC is the answer.

QUIC: a modern, general-purpose transport protocol that runs over UDP, with encryption built in, designed to replace the TCP-plus-TLS combination for web traffic. Standardised by the IETF in RFC 9000 (2021).

What QUIC is and why it exists

QUIC does not sit beside TCP as a small tweak; it re-imagines the transport layer for a web that is now almost entirely encrypted. Several design choices are worth understanding:

• It runs over UDP. Rather than build a brand-new protocol that every router and firewall on the internet would have to be taught to pass, QUIC's designers built it on top of UDP, which existing networks already carry. All the reliability, ordering and congestion control that TCP would normally provide are rebuilt inside QUIC itself, in user space, on top of UDP's bare datagrams.
• TLS 1.3 is built in, not bolted on. With TCP, you first complete the TCP handshake and then complete a separate TLS handshake on top. QUIC integrates TLS 1.3 into the transport, so establishing a connection and securing it happen together. Encryption is not optional in QUIC; it is part of the protocol.
• Faster connection setup. Because the transport and cryptographic handshakes are combined, a new QUIC connection can be ready in fewer round trips than TCP-plus-TLS, and a resumed connection can sometimes send data on the very first packet (0-RTT). On a high-latency link, such as mobile, this is a noticeable saving.
• It solves head-of-line blocking. Over TCP, a web browser using HTTP/2 multiplexes many requests down one TCP connection, but because TCP delivers a single ordered byte stream, one lost packet stalls every stream behind it until it is retransmitted. That is head-of-line blocking. QUIC carries independent streams that are delivered separately, so a loss affecting one stream does not hold up the others.
• Connection migration. A TCP connection is bound to the four-tuple of source and destination IP and port, so if your phone changes network (Wi-Fi to mobile) the connection breaks and must be rebuilt. QUIC identifies a connection by a connection ID rather than by the IP and port, so it can survive a change of network and carry on. This is a genuine improvement for mobile devices that TCP simply cannot offer.

HTTP/3 is HTTP running over QUIC, and it is the current top of the stack for the web: the same HTTP semantics you already know (methods, status codes, headers), carried over QUIC instead of TCP. The IETF's HTTP/3 specification is RFC 9114 (2022).

Why QUIC matters for security and monitoring

This is where QUIC becomes directly relevant to a cyber security role rather than a curiosity for network engineers. QUIC encrypts far more than TCP-plus-TLS ever did. With traditional HTTPS, the TLS payload is encrypted, but the underlying TCP headers, and a good deal of the TLS handshake itself, travel in clear text, which is what many monitoring and inspection tools quietly rely on to see what is going on. QUIC encrypts most of its transport-layer metadata as well, including much of the handshake, so a passive observer on the network sees far less.

The practical implications:

• Passive inspection is harder. Security tools that infer information from TCP behaviour, or that read the unencrypted parts of a TLS handshake (such as the server name), lose much of that visibility with QUIC. Some information that used to be readable on the wire is now encrypted.
• It looks like UDP, and some organisations block it. Because QUIC rides on UDP port 443, and because browsers fall back to ordinary HTTPS over TCP if QUIC is blocked, some enterprises simply block UDP 443 at the firewall so that traffic reverts to inspectable TCP. That is a real, current design decision an entry level trainee may encounter, and understanding why it is made requires understanding what QUIC hides.
• It changes where inspection has to happen. Visibility increasingly has to be gained at the endpoint or at a controlled proxy, rather than by passively sniffing the network in the middle, because the middle now sees mostly ciphertext.

The single idea to carry away is that the move to QUIC and HTTP/3 continues a long trend: more of the network is encrypted, more of the time, by default. That is good for user privacy and good against eavesdropping attackers, and it also reshapes the defender's job, pushing detection toward endpoints and logs and away from passive network inspection. A protocol chapter that stopped at TCP and UDP would miss the most consequential change to internet transport in a generation.

Every network is built from a small set of boxes that each do one job well. If you can name the job and name the OSI layer it works at, most of the confusion falls away. This section walks the boxes in the order they grew up, because the history explains the security.

The hub, and why it died

The oldest shared-wire device was the hub. A hub is a "dumb" repeater: a frame arriving on one port is copied out of every other port, so every device on the hub hears every conversation. That made hubs cheap in the 1990s and hopeless for security; anyone on the segment could run a packet sniffer and read the lot. Hubs also forced every device to share one collision domain, so performance collapsed as you added machines. Hubs are effectively extinct; you will meet them in exam questions and museums, not in a wiring cupboard.

Frame: the unit of data at layer 2 (the data link layer). It carries source and destination MAC addresses. A "packet" is the layer 3 unit inside it, carrying IP addresses.

The switch (layer 2)

The switch replaced the hub and is the workhorse of any wired network. A switch operates at the data link layer, layer 2, and it is intelligent: it learns which MAC address lives on which physical port and records that in a MAC address table (also called a CAM table). Once it has learned, it forwards a frame only to the single port where the destination sits, so conversations are no longer broadcast to everyone. Each switch port is its own collision domain, which is why switching restored performance.

Why does this matter for defence? Because the switch's intelligence is also its weak point. Two classic attacks target it:

• MAC flooding, or CAM table overflow. An attacker floods the switch with thousands of fake source MAC addresses until the table fills. Some switches then "fail open" and behave like a hub, broadcasting frames the attacker can sniff.
• MAC spoofing. An attacker sets their interface to impersonate another device's MAC to intercept traffic or bypass a filter.

The main control here is port security: configuring a switch port to accept only a set number of MAC addresses, or only specific known ones, and to shut down or alarm if that is breached (Cisco and other vendors call this feature "port security").

VLANs

A single physical switch can be carved into several logical networks using VLANs (virtual LANs). Devices in VLAN 10 cannot talk directly to devices in VLAN 20 even though they share the same switch; traffic between them has to pass up to a router or layer 3 switch, where a firewall or access list can inspect it. VLANs are how you keep the guest Wi-Fi, the point-of-sale tills and the office PCs apart on one piece of hardware. The matching attack to know is VLAN hopping, where a misconfigured trunk port lets an attacker reach a VLAN they should not (the defence is disabling dynamic trunking and pruning unused VLANs).

The router (layer 3)

The router works one layer up, at layer 3, the network layer. Where a switch moves frames by MAC address inside one network, a router moves packets between different networks by IP address, consulting a routing table to choose the next hop toward the destination. Your device's default gateway is simply the router it sends any packet bound for outside its own subnet.

Two router jobs matter for a small network:

• NAT (Network Address Translation). Home and small-business routers translate many internal private addresses (the 192.168.x.x range you will recognise) onto one public address from the internet provider. NAT was invented to conserve scarce IPv4 addresses, and as a side effect it hides internal hosts behind one public address. Useful, but note the caution below.
• Routing decisions and access control lists. A router can carry basic filtering rules, though serious inspection is the firewall's job.

Did you know? NAT is often described as a security feature. It is better to call it a helpful side effect. NAT hides internal addresses, but it is not a firewall and it inspects nothing; treating "we have NAT" as "we are protected" is a common beginner error. IPv6 networks frequently give every device a globally routable address and rely on the firewall, not NAT, to keep them safe.

The firewall

A firewall is the policy enforcement point that decides which traffic may cross a boundary (Cloudflare Learning Center, undated reference page). Firewalls have matured through three broad generations, and the names come up constantly in cyber security:

• Packet-filtering firewall. The oldest style. It checks each packet in isolation against static rules: source and destination IP, port, protocol. It is fast but has no memory, so it cannot tell whether a packet belongs to a conversation you started.
• Stateful firewall. It keeps a state table of active connections, so it can allow return traffic for a session your side opened while blocking unsolicited inbound traffic. This has been the baseline for two decades.
• Next-generation firewall (NGFW). A stateful firewall plus deeper features: application awareness (recognising that traffic on port 443 is a particular app, not just "HTTPS"), an integrated intrusion prevention system, and often TLS inspection and threat-intelligence feeds. Most current commercial firewalls from vendors such as Palo Alto, Fortinet and Cisco are marketed as NGFWs.

Where does a firewall sit? At the boundary between zones of different trust: classically between the internal network and the internet, and around a DMZ (demilitarised zone), a semi-trusted segment where internet-facing servers such as a web or mail server live so that a compromise there does not immediately reach the internal LAN.

Wireless access points

A wireless access point (AP) bridges Wi-Fi clients onto the wired network; it is, in effect, a layer 2 device that speaks radio on one side and Ethernet on the other. Two distinctions to keep straight:

• Access point versus wireless router. The all-in-one box the internet provider ships to a home is a wireless router: it combines a router, a switch, a firewall and an access point in one case. A standalone access point does only the Wi-Fi bridging and plugs into a separate switch; this is what you see in offices and schools.
• SSID and controllers. The SSID is the network name a client sees. In any site larger than a single room, multiple APs advertise the same SSID and are managed centrally by a wireless LAN controller (a physical appliance or, increasingly, a cloud service) so that clients roam seamlessly and policy is set once.

A small business network, drawn

flowchart TB
 Internet((Internet)) --- RF["Router / Firewall<br/>(NAT, stateful/NGFW)"]
 RF --- DMZ["DMZ switch"]
 DMZ --- Web["Web / mail server"]
 RF --- SW["Core switch<br/>(VLANs, port security)"]
 SW --- PC1["Office PC (VLAN 10)"]
 SW --- PC2["Office PC (VLAN 10)"]
 SW --- AP["Wireless access point"]
 AP -. Wi-Fi.- Laptop["Staff laptop (VLAN 20)"]
 AP -. Guest SSID.- Guest["Guest device (VLAN 30)"]

The shape to remember: untrusted internet on the outside, the firewall as the gate, public-facing servers isolated in the DMZ, and the internal network split into VLANs behind the switch.

Update, current as at August 2026

Two shifts have changed what a "network device" looks like since the training package was written. First, in homes and small offices the separate boxes have collapsed into one SOHO all-in-one unit, and mesh Wi-Fi kits now blur where the router ends and the AP begins. Second, business networking has moved to cloud-managed models, where the switches, firewalls and access points are configured through a web dashboard (Cisco Meraki, Ubiquiti UniFi, Aruba Central and similar) rather than by plugging a console cable into each device. The OSI-layer jobs are unchanged; the management plane has moved to the browser, which itself becomes something to secure with strong authentication.

Wireless is the boundary an attacker does not have to walk through a door to reach; the radio waves leak into the car park. That is why wireless security carries its own topic.

The 802.11 family, in plain terms

"Wi-Fi" is a set of standards from the IEEE 802.11 family (the working group's own site is at ieee802.org/11). The letters after 802.11 mark generations of speed and radio technique. The Wi-Fi Alliance introduced friendlier generation numbers a few years ago, so both naming systems are in use:

• 802.11b/g (the Wi-Fi 1 to 3 era): the early standards on the crowded 2.4 GHz band.
• 802.11n (Wi-Fi 4): dual-band, 2.4 GHz and 5 GHz.
• 802.11ac (Wi-Fi 5): 5 GHz, faster.
• 802.11ax (Wi-Fi 6, and Wi-Fi 6E which adds the 6 GHz band): the current mainstream, better in crowded environments. Wi-Fi 7 (802.11be) is arriving in new hardware as at 2026.

The bands trade range against speed and congestion: 2.4 GHz travels further and through walls better but is slower and shared with microwaves, Bluetooth and every neighbour; 5 GHz is faster with more channels but shorter range; 6 GHz (Wi-Fi 6E and 7) is clean and fast but shortest in range.

The encryption story, oldest to newest

This is the part to know cold, because the wrong choice on one setting undoes everything else.

• WEP (Wired Equivalent Privacy). The original 1997 scheme. It is broken and has been for two decades; flaws in how it uses the RC4 cipher let an attacker recover the key from captured traffic in minutes with free tools. Never use it; treat seeing it as a finding.
• WPA (Wi-Fi Protected Access). A 2003 stopgap that patched WEP's worst faults using TKIP while hardware caught up. Also now considered insecure.
• WPA2. The 2004 standard that ruled for over a decade. It uses AES-CCMP, strong symmetric encryption based on the AES cipher, and remains acceptable for a home network if the passphrase is long and random. Its known weakness is the KRACK key-reinstallation attack of 2017, largely closed by patches, and its vulnerability to offline brute-forcing of a captured handshake when the passphrase is weak.
• WPA3. The current standard, introduced by the Wi-Fi Alliance in 2018. Its central improvement is SAE (Simultaneous Authentication of Equals), also called Dragonfly, which replaces the WPA2 handshake. SAE gives forward secrecy and resists the offline dictionary attack: an attacker who captures the handshake cannot take it away and brute-force it at leisure, because each guess needs a fresh live interaction with the network. WPA3 also improves protection on open networks. Use WPA3, or WPA3/WPA2 mixed mode where old devices still need to connect (Wi-Fi Alliance security overview at wi-fi.org/discover-wi-fi/security, undated reference page).

Definition, SAE: a password-based key exchange in which both the client and the access point prove they know the passphrase without ever sending it or a crackable derivative across the air, and derive a fresh session key each time. It is what makes WPA3 resistant to the capture-and-crack-later attack that troubles WPA2.

The danger of open networks

An open network has no encryption at all; anyone in range can read the traffic in clear. The old free cafe Wi-Fi is the classic example. The mitigation you already carry is the padlock in the browser: HTTPS encrypts the content of a web session regardless of the Wi-Fi, so a modern web login is not exposed the way it was in 2010. Even so, open networks leak metadata and invite the attacks below, which is why WPA3's "Enhanced Open" (OWE) was added to encrypt even guest Wi-Fi without a password.

Evil twin and rogue AP

Two related threats every entry level trainee should recognise:

• Rogue access point. An unauthorised AP plugged into the organisation's network, sometimes by a well-meaning staff member wanting better coverage, sometimes by an attacker. It creates an unmanaged way in, behind the firewall.
• Evil twin. An attacker stands up a fake AP broadcasting the same SSID as a network you trust, often with a stronger signal, so your device or you connect to it. The attacker then sits in the middle of your traffic. This is a form of man-in-the-middle attack and is a favourite for harvesting credentials via a fake login page (Cloudflare Learning Center, undated).

MAC filtering is theatre

A tempting-looking control is MAC filtering: telling the AP to admit only a list of known device MAC addresses. It feels like a whitelist, but a MAC address is broadcast in the clear in every wireless frame, so an attacker only has to sniff the air, read an allowed MAC, and spoof it. MAC filtering stops a curious neighbour and nobody with a laptop and free tools; do not count it as a security control. The same goes for hiding the SSID; the network name still leaks in client probe requests.

What the ACSC advises

Australia's national authority, the Australian Cyber Security Centre (ACSC), publishes practical guidance for securing wireless, both for home users and for organisations (cyber.gov.au, the ACSC's current site). The through-line of its advice matches this section: use WPA3 or at least WPA2 with AES, set a long unique passphrase, change default administrator credentials on the router, keep firmware updated, and separate guest and untrusted devices onto their own network. For organisations the ACSC's hardening guidance and the Essential Eight sit alongside this (the Essential Eight is maintained at cyber.gov.au, current as at 2026).

Update, current as at August 2026

WPA3 is now the expected default on new consumer and business equipment, and Wi-Fi 6E and Wi-Fi 7 gear ships with it by default. The realistic weak points in 2026 are not the encryption itself but the surrounding hygiene: unpatched router firmware, default admin passwords, and old client devices forcing a network back into WPA2 mixed mode.

Most networking teaching assumes a laptop with mains power and plenty of bandwidth. The Internet of Things breaks all three assumptions, and that is why it has its own protocols. This is a beyond-TAFE topic; the training package barely touches it, yet it is where a great deal of current real-world risk sits.

Why IoT connectivity is different

Picture a soil-moisture sensor in a paddock, or a water meter in a pit, or a parking bay sensor in the road. Such a device has to run for years on a small battery, sit kilometres from the nearest tower, and send only a trickle of data. It needs the opposite of Wi-Fi: low power, long range, low bandwidth. That combination is served by a class of networks called LPWAN (Low-Power Wide-Area Network). Two LPWAN technologies dominate the syllabus and the market: NB-IoT and LoRaWAN. They sit at opposite ends of one design choice, licensed versus unlicensed radio.

NB-IoT, the carrier's LPWAN

NB-IoT (Narrowband IoT) is a cellular standard defined by 3GPP, the same body that standardises 4G and 5G. Its key traits:

• It runs in licensed spectrum, the same regulated bands the mobile carriers own, so it is carrier-run. You buy NB-IoT connectivity from Telstra, Optus or another operator much as you buy a mobile plan, and you do not build any radio infrastructure yourself.
• It reuses existing mobile tower sites, giving broad coverage and good penetration into basements and pits where a device might sit.
• Typical use cases: smart water and gas metering, environmental sensors, asset tracking, smart-city devices where the operator wants managed, reliable connectivity and is happy to pay a per-device subscription.

The trade is dependence on a carrier and a recurring fee per device, in exchange for coverage and managed operation.

LoRa and LoRaWAN, the private LPWAN

LoRa is the physical radio technique (a chirp-spread-spectrum modulation, proprietary to Semtech), and LoRaWAN is the open networking standard built on top of it, maintained by the LoRa Alliance. Its traits are almost the mirror image of NB-IoT:

• It runs in unlicensed sub-GHz spectrum (around 915 MHz in Australia), so anyone may operate it without a spectrum licence.
• It offers very long range, several kilometres and more in open country, at very low data rates.
• Crucially, an organisation can build its own private network by installing its own gateways; there is no carrier and no per-device subscription. That makes LoRaWAN attractive for farms, campuses, mines and councils that want to own their infrastructure.

The LoRaWAN architecture

LoRaWAN traffic flows through four roles, worth learning as a chain (described in the LoRa Alliance technical materials at lora-alliance.org):

flowchart LR
 ED["End device<br/>(sensor)"] -- LoRa radio --> GW["Gateway<br/>(concentrator)"]
 GW -- IP backhaul --> NS["Network server"]
 NS --> AS["Application server"]

• End device. The battery sensor or actuator in the field.
• Gateway. A concentrator that hears the LoRa radio and forwards messages over an ordinary IP backhaul (Ethernet, Wi-Fi or cellular) to the network server. A gateway is not tied to one application; it relays for any device it hears.
• Network server. The brain: it de-duplicates messages heard by several gateways, manages the radio, checks message integrity, and routes each message to the right application.
• Application server. Where the sensor data is decrypted for use and turned into something the business sees, a dashboard reading or an alert.

A useful detail for security: LoRaWAN uses two separate AES-128 session keys, a network session key and an application session key, so the network operator can route traffic without being able to read the payload; only the application server holds the key to the data itself.

Security considerations for LPWAN and IoT

The appeal of these devices, cheap, numerous, unattended, is exactly what makes them a security problem. Points an entry level trainee should carry:

• Device provisioning and key management. LoRaWAN devices join a network by one of two methods: OTAA (Over-the-Air Activation), which negotiates fresh session keys on each join and is the recommended approach, or ABP (Activation by Personalisation), which hard-codes static keys into the device and is weaker because a leaked key cannot easily be rotated. The root keys baked into thousands of field devices are a real management burden; if they are shared, default, or extracted from a stolen device, the network's confidentiality is undermined.
• An expanded attack surface. Every sensor is an internet-adjacent computer that is rarely patched, physically reachable, and often forgotten. Thousands of them multiply the ways into an organisation, and they frequently ship with default passwords and open management interfaces.
• Botnets. The consequence at scale is the IoT botnet. The Mirai malware of 2016 is the pointer to keep: it scanned the internet for IoT devices such as cameras and home routers still using factory-default credentials, enrolled them by the hundreds of thousands, and used them to launch some of the largest distributed denial-of-service attacks then seen, including the October 2016 attack on the DNS provider Dyn that took large parts of the web offline (Cloudflare Learning Center, undated reference pages, event dated 2016). Mirai is the standing lesson that unchanged default credentials on cheap devices are a systemic, not just a local, risk.

Did you know? The Mirai source code was published online after the first attacks, which spawned a long line of variants that are still active years later. An insecure IoT device is not only your problem; it can be conscripted to attack someone else.

Update, current as at August 2026

LPWAN has settled into a two-camp market: NB-IoT for carrier-managed, wide-coverage deployments, and LoRaWAN for private, self-operated ones, with many organisations running both. Regulatory attention on IoT security has grown; consumer IoT security baselines and "secure by default" expectations, such as banning universal default passwords, are now law or guidance in several jurisdictions, which is the policy answer to the Mirai lesson (the specifics vary by country and are worth checking against current ACSC and overseas guidance).

Before you can defend a network you have to be able to interrogate one. A handful of small command line tools answer the everyday questions: is this host alive, what path does traffic take to reach it, is this port open, and what is actually listening on it. Every one of them ships with, or installs easily on, Windows, macOS and Linux, and every serious analyst reaches for them daily.

One rule frames this whole section. Run these tools against systems you own or have written authorisation to test. Unauthorised scanning or probing of someone else's network can be an offence under the Commonwealth Criminal Code Act 1995 (unauthorised access to, or modification of, restricted data); see the VU23223 legislation notes on this site for the detail. Diagnostics on your own lab are fair game; the same commands aimed at a stranger's infrastructure are not.

ping: is anything home?

ping sends an ICMP Echo Request and waits for an Echo Reply.

ICMP (Internet Control Message Protocol) is the network layer's messaging and error-reporting protocol. It does not carry application data; it carries control and diagnostic messages such as "echo", "destination unreachable" and "time exceeded".

A reply proves three things at once: the target is powered on and reachable, a path exists in both directions, and you get a round-trip time in milliseconds that hints at distance and congestion. Sample output on Windows:

> ping cyber.gov.au

Pinging cyber.gov.au [104.18.x.x] with 32 bytes of data:
Reply from 104.18.x.x: bytes=32 time=14ms TTL=57
Reply from 104.18.x.x: bytes=32 time=13ms TTL=57

The time field is latency. The TTL (Time To Live) field is a countdown counter set by the sender and decremented by one at each router it passes; here a value of 57 suggests the packet started near 64 and crossed roughly seven hops. TTL exists to stop packets circling a misconfigured network forever; when it hits zero the packet is discarded and an ICMP "time exceeded" message is returned, which is exactly the behaviour traceroute exploits below.

A common trap for the entry level trainee: no reply does not always mean the host is down. Many firewalls and hardened servers deliberately drop inbound ICMP, so the host is alive but silent. Absence of a ping reply is weak evidence; treat it as "unknown", not "offline".

traceroute and tracert: mapping the path

traceroute (Linux and macOS) and tracert (Windows) reveal the sequence of routers between you and a destination. The trick is elegant: send packets with a TTL of 1, then 2, then 3, and so on. The first router decrements TTL 1 to zero, discards the packet and reports back with an ICMP "time exceeded"; its address is hop one. The next packet, with TTL 2, expires at the second router; that is hop two. Increment until the destination itself replies.

> tracert cyber.gov.au

 1 2 ms router.home [192.168.1.1]
 2 11 ms isp-gateway [10.20.30.1]
 3 12 ms * request timed out
 4 14 ms core.isp.net [203.0.113.9]
...

Read it top to bottom as the journey outward. Rising latency across hops is normal as distance grows. A * request timed out at one hop usually means that router is configured not to answer, not that the path is broken, because later hops still respond. A trace that dies partway and never recovers points to a genuine break or a filtering firewall at that boundary.

netcat: the TCP/IP swiss army knife (benign uses only)

netcat (nc) reads and writes raw data across TCP and UDP connections. Its nickname, "the TCP/IP swiss army knife", reflects how many small jobs it covers. Everything below is diagnostic and assumes systems you own or are authorised to test.

Testing whether a port is open, without sending any payload:

$ nc -vz scanme.example.internal 443
Connection to scanme.example.internal 443 port [tcp/https] succeeded!

The -z flag means "zero-I/O", so just check connectivity; -v means verbose. "Succeeded" tells you a service accepted the TCP handshake on that port; a refusal or timeout tells you it did not. This is how you confirm a firewall change or a newly deployed service on your own host is reachable.

Banner grabbing a service you own, to confirm what version is running:

$ nc mail.mylab.internal 25
220 mail.mylab.internal ESMTP Postfix

The 220 line is the banner the mail server volunteers on connection. Knowing exactly what version answers on a port is the same information a defender needs for patch tracking and an attacker wants for target selection, which is why banners are often trimmed on hardened systems.

A simple file transfer inside a closed lab, receiver first then sender:

# on the receiving lab VM
$ nc -l 9000 > received.bin

# on the sending lab VM
$ nc target-vm 9000 < tosend.bin

Handy for shifting a file between two virtual machines that share an isolated network. Keep this to your own lab; netcat listeners are exactly the sort of thing intrusion detection is tuned to flag on a production network.

The rest of the everyday kit

• ipconfig (Windows) and ifconfig or the newer ip addr (Linux and macOS) show your own interfaces: IP address, subnet mask, default gateway and MAC address. Start here when your own connectivity is the question.
• nslookup and the more capable dig query DNS: they turn a name into an address and back, and let you interrogate specific record types. dig +short cyber.gov.au returns just the address; dig cyber.gov.au MX returns the mail servers.
• nmap is the next step up from netcat when you need to scan a range of hosts or ports systematically, fingerprint services and detect operating systems. It is a defender's inventory and audit tool as much as an attacker's reconnaissance tool. This page introduces it as a concept only; run it solely against your own lab, and re-read the authorisation reminder above before you point it at anything.

Did you know?

The TTL value your operating system sets on outgoing packets is a rough fingerprint of the operating system. Windows tends to start at 128, many Linux and macOS builds at 64, and some network gear at 255. When you ping a host and see a returned TTL of 128 minus a few, you can often guess Windows at the far end. It is a small illustration of how much a defender can infer from fields most people never look at.

Diagnostic tools tell you whether traffic flows. Packet capture tells you what the traffic actually contains. For a cyber analyst this is the difference between "the connection works" and "the connection is leaking a password in clear text". Packet capture is how you confirm an incident, understand malware's network behaviour, prove data was or was not exfiltrated, and learn how protocols really behave rather than how the textbook says they do.

A packet capture, often shortened to "pcap", is a recorded copy of the raw frames observed on a network interface, saved for inspection. Each captured packet keeps its full set of headers and, on unencrypted traffic, its payload.

The two standard tools

Wireshark is the graphical packet analyser most analysts learn on; it is free and open source, decodes hundreds of protocols, and colour-codes and dissects each packet down through the layers. Its command line sibling for headless capture is tcpdump on Linux and macOS (from tcpdump.org), which is ideal on a server with no desktop; you capture to a .pcap file with tcpdump and open it later in Wireshark.

Capture filters versus display filters

This distinction trips up beginners, so hold it clearly. A capture filter is applied before recording and decides what gets written to disk; anything it excludes is gone forever. A display filter is applied after the fact and only changes what you see on screen, while the full capture stays intact underneath. In practice you capture broadly with a light capture filter, then narrow down with display filters as you investigate.

The two use different syntaxes, which is a frequent source of confusion. Capture filters use the BPF syntax, for example port 80. Display filters use Wireshark's own syntax, for example http or ip.addr == 192.168.1.50 && tcp.port == 443.

Reading a packet down the layers

Select a single packet and Wireshark's middle pane expands it as a stack of layers, outermost first, mirroring the encapsulation model:

• Frame and Ethernet: source and destination MAC addresses, the local hop.
• IP: source and destination IP addresses, TTL, protocol.
• TCP or UDP: source and destination ports, sequence numbers, flags.
• The application protocol: HTTP, DNS, TLS and so on, decoded into readable fields.

Learning to open that stack and recognise which layer holds which fact is one of the most useful habits this unit can build.

Recognising the TCP handshake

Filter on a conversation and you will see TCP open with its three-way handshake: a packet with the SYN flag set, a reply with SYN and ACK set, and a final ACK. Wireshark labels these in the Info column. Spotting the handshake tells you a connection was genuinely established; a flood of SYN packets with no completing ACKs is the signature of the SYN flood attack described in the next section.

Following a stream and spotting plaintext credentials

Right-click a TCP packet and choose "Follow TCP Stream" and Wireshark reassembles the whole conversation into one readable transcript, request and response interleaved. On an unencrypted protocol this is where the lesson lands hard.

A small worked example of what you would see. Suppose a test client logs in to a lab server over plain FTP while you capture. Following the stream shows something close to:

220 lab-ftp ready
USER trainee
331 Password required for trainee
PASS Summer2026!
230 Login successful

The username and password sit there in clear text, readable by anyone capturing on that segment. The same is true of plain HTTP form posts, Telnet and unencrypted POP3 or IMAP. Do the same experiment against an HTTPS or FTPS service and the stream is an unreadable block of TLS ciphertext. That contrast, the identical login visible one way and opaque the other, is the single most persuasive argument for encryption in transit, and worth reproducing once in your own lab so you never forget it.

Promiscuous mode, and where you may capture

By default a network card ignores frames not addressed to it. Promiscuous mode tells the card to hand every frame it hears to the capture tool, which is how you observe more than your own traffic. On old shared-hub or wireless networks that could mean a lot of other people's traffic; on a modern switched network a switch only forwards frames to the port that needs them, so an analyst on one port sees mostly their own conversations unless the switch is configured with a mirror or SPAN port.

The ethics and legality follow directly. Capture on networks you own or are authorised to monitor; your own home lab is the safe place to practise. Capturing other people's traffic without authorisation can constitute unlawful interception under Australian law and is squarely the territory of the VU23223 legislation notes. Even where capture is lawful, packets can contain personal information, so handle and store pcap files with the same care you would give any sensitive record.

Did you know?

The very first thing many analysts do with a fresh Wireshark capture is type http.request or dns into the display filter to see who a machine is talking to. Malware frequently gives itself away not by its payload, which may be encrypted, but by the pattern of its connections: regular "beaconing" back to a command server at fixed intervals, or DNS lookups for domains that look machine-generated. You can spot suspicious behaviour from metadata alone, without reading a single byte of content.

The principle for this whole section is "know your enemy to defend". You need to understand how these attacks work well enough to recognise them in logs and captures and to put the right countermeasures in place. What follows is conceptual and defensive; there is no operational how-to and no tooling walk-through, by design.

Denial of service and distributed denial of service

A denial-of-service (DoS) attack aims to make a system or service unavailable to its legitimate users, by exhausting a resource such as bandwidth, connection state or server processing.

A plain DoS comes from one source. A distributed denial-of-service (DDoS) comes from many sources at once, typically a botnet of thousands of compromised devices acting on command, which makes it far harder to block by address and far larger in volume. Cloudflare's Learning Center has a clear, vendor-neutral primer at What is a DDoS attack? (undated reference page).

DDoS attacks are usually grouped by the layer they target:

• Volumetric attacks aim to saturate the target's bandwidth with sheer traffic volume, measured in bits per second.
• Protocol attacks exhaust connection-tracking resources on servers, firewalls and load balancers. The classic is the SYN flood, which sends a torrent of TCP SYN packets and never completes the handshake, leaving the target holding thousands of half-open connections until its connection table fills. Cloudflare explains it at SYN flood attack (undated).
• Application-layer attacks (sometimes called Layer 7) mimic legitimate requests, for example a flood of requests to an expensive search page, so they are low in volume but costly per request and hard to distinguish from real users.

Amplification and reflection deserve a note because they explain how a modest attacker generates enormous traffic. The attacker sends small requests to third-party servers (DNS resolvers, NTP servers, memcached) while forging the source address to be the victim's; the servers send their much larger replies to the victim. A small query producing a large reply "amplifies" the traffic, and the reflection off innocent third parties hides the origin. See Cloudflare's DNS amplification attack (undated).

How organisations defend:

• Rate limiting and traffic shaping to cap how much any one source can demand.
• Upstream scrubbing services and specialist DDoS mitigation providers that absorb and filter attack traffic before it reaches the origin.
• Content delivery networks (CDNs) that spread load across many global points of presence, so no single site is the sole target.
• Provider-level filtering and anti-spoofing (the industry guidance known as BCP 38) to reduce forged-source traffic at the edge.

The Australian Cyber Security Centre publishes guidance on preparing for and responding to denial-of-service attacks at cyber.gov.au (ACSC guidance, exact publication date varies by document). The practical message for a defender is that DDoS is rarely stopped by the target alone; it is handled upstream, with a plan agreed before the attack, not during it.

ARP poisoning and spoofing

The Address Resolution Protocol (ARP) maps an IP address to a MAC address on a local network segment. It has no authentication; a host simply trusts ARP replies it receives.

That missing authentication is the weakness. In ARP poisoning (also called ARP spoofing) an attacker already on the local segment sends forged ARP replies so that other hosts associate the attacker's MAC address with the gateway's IP, or with another host's IP. Traffic that should go to the gateway is then delivered to the attacker first, placing them in the middle of the conversation where they can read, alter or relay it. It is a local-segment attack; it does not cross routers, which is one reason network segmentation limits its blast radius.

Detection and mitigation:

• Dynamic ARP Inspection (DAI) on managed switches validates ARP messages against a trusted binding table and drops forged ones.
• Static ARP entries for critical hosts such as gateways, so a forged reply cannot overwrite the mapping.
• Segmentation and VLANs to shrink each broadcast domain, reducing how many hosts an attacker can reach from one foothold.
• Monitoring for the tell-tale sign: a single MAC address suddenly claiming several IP addresses, or a gateway's MAC appearing to change.

Man-in-the-middle

A man-in-the-middle (MITM) attack is any attack where the adversary secretly sits between two parties, relaying and possibly altering traffic while each party believes it is talking directly to the other.

ARP poisoning is one way to achieve the position; a rogue Wi-Fi access point or a compromised router is another. Once in the middle, the attacker can read anything unencrypted, which loops straight back to the Wireshark plaintext lesson above.

A concept worth naming is SSL stripping: rather than break encryption, the attacker prevents it. When a user visits a site by typing a bare address, the attacker quietly keeps the connection to the victim on plain HTTP while talking to the real site over HTTPS, so the victim never gets the encrypted session they should have. The defences are exactly why modern web security looks as it does:

• TLS everywhere, so intercepted traffic is ciphertext, not readable content.
• HSTS (HTTP Strict Transport Security), a policy that tells browsers to only ever connect to a site over HTTPS, which closes the plain-HTTP gap that SSL stripping relies on.
• Preloaded HSTS lists and browsers defaulting to HTTPS, which have made the classic stripping attack far harder than it was a decade ago.

Cloudflare's overview at What is an on-path attacker? covers this well (undated reference page; Cloudflare now uses the term "on-path attacker" for the same idea).

Did you know?

The reason a browser shows a loud warning, rather than a quiet note, when a certificate does not validate is that certificate validation is the main automated defence against man-in-the-middle attacks on the web. An invalid or mismatched certificate is often the only outward sign that something is sitting in the middle, so the warning is deliberately hard to click past. Teaching users not to bypass those warnings is a genuine security control, not just tidiness.

Ransomware is malware that encrypts a victim's files, and increasingly steals them first, then demands payment for their return. It matters in a networking unit because its damage is a network story: how it gets in, how it spreads from one machine to many, and why network design decides whether one infected laptop is a bad afternoon or an organisation-wide crisis. This section is concept and defence only.

Ransomware is malicious software that denies access to data or systems, usually by encrypting files, until a ransom is paid. Modern strains add extortion by threatening to publish stolen data.

Gaining a foothold

Most ransomware starts small and human. Common entry routes:

• Phishing emails carrying a malicious attachment or link, still the most common opening.
• Exposed Remote Desktop Protocol (RDP), where an internet-facing RDP service with a weak or reused password is brute-forced or bought as stolen access.
• Unpatched internet-facing services, where a known vulnerability in a VPN gateway, mail server or web application is exploited to get a first foothold.

Moving laterally across the network

Getting onto one machine is rarely the goal; the payoff comes from reaching many. Ransomware operators spread sideways using:

• SMB (Server Message Block), the Windows file-sharing protocol, to reach and write to other machines. The obsolete SMBv1 is a particular liability.
• Stolen credentials harvested from the first machine, especially if a local or domain administrator account is reused across many hosts.
• Living-off-the-land, meaning the abuse of legitimate built-in administration tools such as PowerShell, PsExec and Windows Management Instrumentation, so the activity blends in with normal administrative traffic and evades simple malware signatures.

This is where network design decides the outcome. A flat network, where every device can reach every other device, lets an attacker who compromises one host reach all of them. A segmented network, where sensitive systems sit behind internal controls and machines cannot freely talk to one another, forces the attacker to break through each boundary and gives defenders time and choke points to detect and stop the spread.

flowchart LR
 A[Phishing email or exposed RDP] --> B[First host compromised]
 B --> C[Steal credentials, run built-in tools]
 C --> D{Network design?}
 D -->|Flat network| E[Reaches every host, encrypts widely]
 D -->|Segmented network| F[Blocked at boundary, contained]

Encryption and extortion

Once positioned, the ransomware encrypts files across every machine it can reach and presents a ransom note. Since around 2019 the dominant model has been double extortion: the operators exfiltrate a copy of the data before encrypting, then threaten to publish or sell it if the ransom is unpaid. That change matters for defence, because good backups solve the availability problem but do nothing about stolen data already in an attacker's hands; prevention and early detection carry more weight than they used to.

Case study: WannaCry, May 2017

WannaCry is the textbook example of ransomware as a network worm. It spread using EternalBlue, an exploit of a vulnerability in the outdated SMBv1 protocol, and required no user interaction to jump from an infected machine to unpatched neighbours; it self-propagated across flat networks and the wider internet. Within days it had affected an estimated hundreds of thousands of machines across many countries, with the United Kingdom's National Health Service among the most visible casualties. Microsoft had released a patch for the underlying vulnerability roughly two months earlier, so the incident is remembered as much for the cost of unpatched, flat, SMBv1-enabled networks as for the malware itself. Every defence in the next paragraph maps directly onto something WannaCry exploited.

Defending against ransomware

• Network segmentation, so a single compromise cannot reach everything.
• Least privilege, so ordinary users and their machines cannot administer others, which starves lateral movement of the credentials it needs.
• Prompt patching of operating systems and internet-facing services, which would have blunted WannaCry entirely.
• Reliable, tested backups following the 3-2-1 rule: three copies of the data, on two different media, with one kept off-site and offline, so an encrypted primary can be restored without paying. Backups an attacker can reach and encrypt are not backups.
• Multi-factor authentication (MFA), especially on remote access such as VPN and RDP, so a stolen password alone is not enough.
• Disabling SMBv1 and closing or gating remote-access services that do not need to face the internet.
• Monitoring and logging, so lateral movement and unusual administrative activity are noticed while there is still time to respond.

The Australian Cyber Security Centre treats ransomware as one of the most significant threats to Australian organisations and publishes prevention and response advice, including its ransomware guidance and the Essential Eight mitigation strategies, at cyber.gov.au (ACSC, current guidance as at 2026). The United States equivalent consolidates practical resources at stopransomware.gov (run by CISA).

Did you know?

WannaCry was halted less by defenders patching and more by accident. A researcher analysing the malware noticed it checked whether a particular unregistered domain name existed before encrypting, and registered it; that "kill switch" domain caused many samples to stop. It bought time, but it was luck standing in for the patching and segmentation that should have prevented the spread in the first place, which is exactly why those controls, not good fortune, are the lesson to take from 2017.

You cannot learn defensive security safely on production systems or on the open internet, and you should never practise techniques against machines you do not own. A virtual lab solves this: it is a small, self-contained network of virtual machines on your own computer where you can break things, observe attacks, capture traffic and recover instantly. Safe, isolated and reversible is the whole point.

A virtual machine (VM) is a complete computer implemented in software, running its own operating system inside a window on your real "host" machine. Several VMs can run at once, each behaving as though it were a physical computer.

Why a virtual lab

• It is safe: activity stays inside the VMs and, if you configure the networking correctly, cannot reach your real network or the internet.
• It is isolated: you can run and observe malicious or fragile software without risking your everyday computer.
• It is reversible: a snapshot lets you roll a VM back to an earlier clean state in seconds, undoing whatever an experiment did.

A snapshot is a saved point-in-time image of a VM's disk and state. You take one before an experiment and restore it afterwards, returning the machine to exactly how it was.

Hypervisors: type 1 and type 2

A hypervisor is the software layer that creates and runs virtual machines, sharing the host's real CPU, memory and storage among them.

Hypervisors come in two kinds. A type 1, or "bare-metal", hypervisor runs directly on the hardware with no host operating system beneath it; these run data-centre and cloud infrastructure, and Microsoft's Hyper-V and VMware ESXi are examples. A type 2, or "hosted", hypervisor runs as an application on top of your normal operating system, which is what you use for a learning lab on a laptop.

Common choices for a home lab:

• Oracle VirtualBox, free and cross-platform, the usual starting point.
• VMware Workstation, long the mainstream commercial option on Windows and Linux (note that VMware's product packaging and licensing have changed under Broadcom, so check current availability).
• Microsoft Hyper-V, built in to Windows Pro and Enterprise.

VM images and how you get a target

You build a VM from an installation image (an ISO) of an operating system, or you download a ready-made VM image. For an attacker-side workstation, Kali Linux ships as a prepared VM image with security tooling already installed. For a target, you might run a spare Windows evaluation VM or a deliberately vulnerable training image. The point of a target is to have something to observe and defend that is not a real system belonging to anyone.

Virtual networking modes, and why they matter for safety

This is the setting that decides whether your lab is safe, so understand the three common modes:

• NAT: the VM shares the host's internet connection through address translation. Convenient for downloading updates, but the VM can reach the internet, so it is not suitable for handling anything malicious.
• Host-only: the VM can talk to the host and to other VMs on the same host-only network, but not to the internet or the wider LAN. Useful when you want to reach the lab from your host.
• Internal or isolated: the VMs can talk only to each other, with no path to the host, the LAN or the internet. This is the mode for a malware-safe lab, because nothing can escape.

The rule to internalise: if a VM will run or be exposed to anything malicious, put it on an internal, isolated network with no route out. Convenience networking and dangerous experiments do not belong on the same virtual switch.

A small starter lab

A minimal, safe layout is two VMs on one isolated internal network: an attacker box such as Kali and a single target VM, with no connection to your real network or the internet. On that closed segment you can practise reading traffic with Wireshark, watch how a scan looks from the defender's side, and see the attacks from earlier sections behave in a controlled setting, all without touching a system you are not authorised to test. Take a snapshot of each VM in its clean state first, so you can always roll back.

flowchart LR
 K[Kali attacker VM] --- N[Isolated internal network<br/>no route to LAN or internet]
 T[Target VM] --- N

Where to go next

Once your own lab feels comfortable, structured practice ranges let you test skills legally against machines built for the purpose. Capture-the-flag (CTF) events set security puzzles where you find hidden "flags" by solving challenges. Guided platforms such as TryHackMe and Hack The Box provide authorised, intentionally vulnerable targets with lessons attached, so you can keep building skills without ever pointing a tool at a system you do not own. The authorisation principle from the diagnostic-tools section never lapses: your lab and these sanctioned ranges are where practice belongs.

Did you know?

The isolation that makes a virtual lab safe is the same property that malware authors try to defeat. Some malware checks whether it is running inside a VM (looking for tell-tale virtual hardware or drivers) and stays dormant if it thinks it is being watched, precisely to frustrate analysts studying it in a lab. It is a neat reminder that the analyst's sandbox and the attacker's evasion are two sides of the same idea.

These notes were built for personal professional development from current, authoritative sources rather than transcribed from the training package. The protocol and addressing material is grounded in the IETF Request for Comments series at rfc-editor.org (RFC 791, 793, 826, 1034, 1035, 1122, 1918, 2131, 3022, 4291, 4632, 4862, 768, 8200, 8446, 5246, 8996, 9000, 9110, 9114, 9293), the IANA port number registry (iana.org) and Mozilla MDN (developer.mozilla.org); all read or cross-checked on 20 August 2026. Concept explainers were drawn from the Cloudflare Learning Center (cloudflare.com/learning) for the OSI model, DDoS, SYN flood, DNS amplification, DNS, firewalls, the Mirai botnet and on-path (man-in-the-middle) attacks, each verified as live on 20 August 2026; Cloudflare pages do not show a fixed publication date. Australian guidance is from the Australian Cyber Security Centre (cyber.gov.au). Wireless material draws on the Wi-Fi Alliance (wi-fi.org) and IEEE 802.11 (ieee802.org); IoT material on the LoRa Alliance (lora-alliance.org) and 3GPP (3gpp.org). The SMBv1 guidance is Microsoft Learn's "Detect, enable, and disable SMBv1, SMBv2, and SMBv3 in Windows" (learn.microsoft.com), last updated 11 March 2025. Tool and lab references point to the projects' own sites: wireshark.org, tcpdump.org, nmap.org, virtualbox.org, vmware.com, kali.org, tryhackme.com and hackthebox.com, plus the United States government's stopransomware.gov (run by CISA). The unit scope block draws on the Victoria University published unit page for VU23213 (vu.edu.au), read 20 August 2026. Stable background concepts (collision domains, VLANs, NAT, IPv6, RC4, AES, KRACK, LPWAN, NB-IoT, LoRa, DMZ, 802.11 service sets) are linked to Wikipedia for reference.