Network Security

A networked system is under constant, automated attack — port scans, password-guessing bots and malware probes hit any internet-facing server within minutes of it coming online. Network security is the discipline of keeping a system confidential, available and with its data intact in the face of these threats. There is no single magic defence; instead, security professionals layer many overlapping measures so that if one fails, others still stand — a philosophy called defence in depth.

At A-Level you must be able to describe the principal threats to networked systems — including the major categories of malware, SQL injection and denial-of-service attacks — and the countermeasures used against them: firewalls (with packet filtering and stateful inspection), proxy servers, encryption, and user-side protections such as strong authentication and patching. The standout examinable skill is being able to recommend and justify a layered defence for a given scenario — and, for SQL injection specifically, to explain both the attack and its correct fix in code.

---

Spec Mapping

This lesson addresses the Communication and networking area of the AQA A-Level Computer Science (7517) specification, specifically network security threats and defences. It covers categories of malicious software (viruses, worms, Trojans, ransomware, spyware); SQL injection and its prevention; denial-of-service and distributed denial-of-service attacks; firewalls including packet filtering and stateful inspection; proxy servers; encryption as a network defence; and user-side protection (strong passwords, multi-factor authentication, patching, user education). It links closely to encryption and digital signatures (this area), to the databases / SQL area for SQL injection, and to web technologies for the client/server trust boundary.

---

The Threat Landscape

It helps to organise threats by what they target — and to keep in mind the three goals security protects: confidentiality (keeping data secret), integrity (keeping it unaltered) and availability (keeping the service usable).

Threat	What it is	Primary goal attacked
Malware	Malicious software (viruses, worms, Trojans, ransomware, spyware)	Varies — often integrity/availability/confidentiality
SQL injection	Malicious SQL inserted via input fields to manipulate a database	Confidentiality and integrity
Denial of Service (DoS/DDoS)	Flooding a system to exhaust its resources	Availability
Phishing / social engineering	Tricking people into revealing credentials or breaking procedure	Confidentiality
Man-in-the-middle (MITM)	Intercepting/altering communication between two parties	Confidentiality and integrity
Brute force	Systematically trying passwords until one works	Confidentiality (access)
Packet sniffing	Capturing network traffic to read sensitive data	Confidentiality

The crucial conceptual point — examined repeatedly — is that technical defences and human defences are both essential, because many breaches exploit people (phishing, social engineering) rather than software. A firewall cannot stop an employee typing their password into a fake login page.

---

Malware — The Major Categories

Malware ("malicious software") is any program written to harm, disrupt or gain unauthorised access to a system. You must be able to distinguish the main types, because their propagation and behaviour differ:

Type	How it spreads	What it does
Virus	Attaches to a host file/program; spreads when that file is run by a user	Corrupts/deletes data, replicates into other files
Worm	Self-replicating — spreads automatically across networks with no user action, exploiting vulnerabilities	Consumes bandwidth, spreads rapidly, can carry payloads
Trojan	Disguised as legitimate software the user installs willingly	Opens a backdoor, steals data — does not self-replicate
Ransomware	Often via phishing or a Trojan	Encrypts the victim's files and demands payment for the key
Spyware	Bundled with other software, or via a Trojan	Secretly monitors activity (keystrokes, browsing) and exfiltrates it

The exam discriminator is the virus vs worm distinction: a virus needs a user to run an infected file to spread, whereas a worm spreads itself automatically across the network by exploiting vulnerabilities, which is why worms can propagate explosively. A Trojan is defined by deception — it does not replicate at all; it relies on the user being fooled into installing it. Naming the precise propagation mechanism is what separates a top-band answer from a vague "it's a bad program".

The defences against malware are layered: antivirus/anti-malware software (which scans files against signatures and behaviour), prompt patching (worms exploit known, unpatched vulnerabilities), user education (do not run untrusted attachments — the virus/Trojan vector), least privilege (limit what a compromised account can do) and backups (the only reliable recovery from ransomware).

---

SQL Injection — Attack and Fix

SQL injection is one of the most important attacks at A-Level because it directly connects networking, web technologies and databases. It exploits applications that build SQL queries by concatenating untrusted user input directly into the query string. An attacker supplies input crafted so that it is interpreted as SQL code rather than mere data, manipulating the database.

The Vulnerable Code

Consider a login form whose server-side code builds a query by string concatenation — the classic mistake:

-- The application intends this query, filling in the user's input:
SELECT * FROM users
WHERE username = '[input]' AND password = '[input]';

Suppose the server builds the query by directly inserting whatever the user typed. A normal user entering alice and secret produces the safe, intended query:

SELECT * FROM users
WHERE username = 'alice' AND password = 'secret';

The Attack

Now an attacker enters, as the username, the string ' OR '1'='1 and leaves the password as anything. The concatenated query becomes:

SELECT * FROM users
WHERE username = '' OR '1'='1' AND password = 'anything';

The injected OR '1'='1' is always true, so the WHERE clause matches every row — the attacker is logged in (often as the first user, frequently an administrator) without knowing any password. A more destructive variant uses a statement terminator and a second command:

-- Attacker enters as username:   '; DROP TABLE users; --
SELECT * FROM users
WHERE username = ''; DROP TABLE users; --' AND password = 'anything';

Here the ; ends the intended query, DROP TABLE users is executed as a second command (destroying the table), and -- comments out the rest of the line so it does not cause a syntax error. The root cause in every case is the same: user input was treated as executable code instead of inert data.

The Fix: Parameterised Queries (Prepared Statements)

The correct, robust defence is the parameterised query (also called a prepared statement). The SQL is written with placeholders, and the user input is passed separately as parameters. The database engine then treats the parameters strictly as data values — never as SQL syntax — so an injected ' OR '1'='1 is searched for as a literal username and simply matches nothing.

// SAFE — parameterised query (pseudocode; same idea in every language)
query = "SELECT * FROM users WHERE username = ? AND password = ?"
prepared = database.prepare(query)
prepared.bind(1, enteredUsername)   // bound strictly as DATA
prepared.bind(2, enteredPassword)   // bound strictly as DATA
result = prepared.execute()

Because the placeholders ? are bound as data, the malicious string ' OR '1'='1 is now interpreted as a username literally containing those characters — which matches no real account — and the attack fails. Parameterised queries are the primary, recommended defence. Two supporting measures help in depth: input validation/sanitisation (rejecting or escaping unexpected characters) and the principle of least privilege (the database account the web app uses should have only the permissions it needs — for example, no right to DROP tables — so even a successful injection is limited). Note that client-side validation alone is useless here, because an attacker bypasses the browser entirely and sends crafted requests straight to the server — which is exactly the client/server trust point from the web-technologies lesson.

Exam Tip: For SQL injection, the markable points are: (1) the cause — user input concatenated into a query and executed as code; (2) a worked example such as ' OR '1'='1 making the WHERE clause always true; (3) the primary fix — parameterised queries/prepared statements that treat input as data; (4) supporting fixes — input sanitisation and least-privilege database accounts. Naming "parameterised queries" specifically is what earns the top mark.

---

Denial-of-Service Attacks

A Denial-of-Service (DoS) attack aims not to steal data but to make a service unavailable to legitimate users, by overwhelming it with more requests or traffic than it can handle, exhausting its bandwidth, connections, memory or CPU. A Distributed Denial-of-Service (DDoS) attack does the same thing from many compromised machines at once — a botnet of malware-infected devices all flooding the target simultaneously.

flowchart LR
    A["Attacker"] --> BN["Botnet<br/>(thousands of<br/>infected devices)"]
    BN --> Z1["Zombie"] --> T["Target server<br/>(overwhelmed -<br/>denies legitimate users)"]
    BN --> Z2["Zombie"] --> T
    BN --> Z3["Zombie"] --> T

DDoS is far harder to defend against than simple DoS precisely because the flood comes from thousands of distinct IP addresses, so you cannot simply block one source. Countermeasures include rate limiting (capping requests per source), firewalls and traffic filtering to drop obviously malicious traffic, load balancing and over-provisioning so the system can absorb surges, and specialist DDoS-mitigation/scrubbing services (and CDNs) that absorb and filter attack traffic before it reaches the origin server. The defining exam point is that a DoS attacks availability, not confidentiality or integrity — it does not break in or steal anything; it simply denies service.

---

Firewalls

A firewall is a hardware or software barrier that monitors and controls traffic crossing a network boundary, allowing or blocking it according to a set of configured rules. It is typically placed between a trusted internal network and the untrusted internet.

flowchart LR
    INT["Untrusted<br/>Internet"] <--> FW["Firewall<br/>(applies rules to<br/>traffic crossing the boundary)"]
    FW <--> LAN["Trusted<br/>internal network"]

Packet Filtering

The most basic firewall is a packet filter. It inspects each packet's header fields — source and destination IP address, port and protocol — and applies allow/deny rules. It is stateless: it judges each packet in isolation, with no memory of previous packets. This makes it fast and simple, but limited: it cannot tell whether an incoming packet is a legitimate reply to something the inside requested or an unsolicited attack, because it does not track connections, and it never looks inside the packet at the payload.

A simplified rule table, processed top to bottom, applying the first match:

Rule	Source IP	Dest port	Protocol	Action
1	Any	80	TCP	Allow (HTTP)
2	Any	443	TCP	Allow (HTTPS)
3	Any	22	TCP	Allow (SSH)
4	Any	Any	Any	Deny (default)

The final catch-all default-deny rule embodies a key security principle: block everything except what is explicitly permitted, rather than allowing everything except known-bad — because you can never enumerate all the bad things.

Stateful Inspection

A stateful inspection firewall is more capable: it tracks the state of active connections in a connection table, so it can judge a packet in the context of the conversation it belongs to. For example, it can allow an incoming packet only if it is part of a connection that an internal host initiated — so replies to your web requests get in, but unsolicited inbound connection attempts are blocked. This understanding of connection state (e.g. that a TCP connection has completed its three-way handshake) makes stateful firewalls substantially more secure than stateless packet filters, at the cost of more processing and memory to maintain the state table.

Feature	Packet-filtering (stateless)	Stateful inspection
Decision basis	Each packet's header, in isolation	Header plus the connection's state/context
Tracks connections?	No	Yes (connection table)
Can allow only solicited replies?	No	Yes
Speed / resource use	Faster, lighter	More processing and memory
Security	Basic	Stronger

Exam Tip: Distinguish the two precisely. A packet filter is stateless and decides on headers (IP/port/protocol) alone. A stateful firewall tracks connection state, so it can permit, say, only inbound traffic that is a reply to an outbound request. Avoid the vague "a firewall blocks hackers" — describe what it inspects and give an example rule.

---

Proxy Servers

A proxy server is an intermediary that sits between clients and the wider internet: clients send their requests to the proxy, which forwards them on, receives the responses, and relays them back. Because all traffic flows through this single point, the proxy can do several useful security and performance jobs:

Function	Detail
Anonymity	The destination sees the proxy's IP, hiding the individual clients behind it
Content filtering	Block access to disallowed sites (common in schools and workplaces)
Caching	Store frequently requested pages, reducing bandwidth and speeding repeat access
Logging / monitoring	Record requests for auditing and to detect misuse
Malware scanning	Inspect content for threats before it reaches internal users

A reverse proxy sits in front of servers rather than clients. It distributes incoming requests across several back-end servers (load balancing), hides the real servers' addresses (a security layer), and caches content — the same intermediary idea applied in the opposite direction, and a direct link to the horizontal-scaling and load-balancing concepts from the client-server lesson.

---

Intrusion Detection and Prevention

Firewalls decide what traffic may cross a boundary, but they do not deeply analyse the behaviour of traffic that is allowed through. That job falls to intrusion systems: