You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
A network connects valuable data and services to the wider world, and everything that makes a network useful also makes it a target. This lesson surveys the principal threats to a network — the malicious software, deceptions and attacks that adversaries use — and the defences that counter them. We classify the main forms of malware; explain phishing and social engineering (attacks on people rather than machines); describe denial-of-service and distributed denial-of-service attacks; work through SQL injection with a concrete example; and explain the man-in-the-middle attack. Against these we set the defensive toolkit: firewalls, proxy servers, encryption, MAC address filtering, intrusion detection systems and user access levels, drawing them together under the principle of defence in depth.
A guiding idea runs throughout: there is no single security control that protects against everything. A firewall does nothing against a duped employee; staff training does nothing against a software flaw; encryption protects confidentiality but not availability. Effective security therefore layers complementary controls so that the failure of one does not expose the whole system — and the strongest answers always match each defence to the specific threat it addresses rather than listing controls in the abstract. Note that encryption and hashing themselves are derived in full in the Encryption lesson of the OCR A-Level CS: Data Representation course; here we use them as security tools and cross-reference that lesson rather than re-deriving the ciphers.
This lesson covers the OCR H446 1.3.4 material on network security threats and defences, specifically:
Examiners reward candidates who can explain how an attack works (its mechanism, not just its name) and who can pair each defence with the threat it mitigates and explain why it helps.
Attackers pursue three broad goals, often summarised as the CIA triad of what security protects:
| Goal under threat | What the attacker wants | Example attack |
|---|---|---|
| Confidentiality | To read data they should not see | Packet sniffing, man-in-the-middle |
| Integrity | To alter data or behaviour | SQL injection, malware tampering |
| Availability | To deny the service to legitimate users | DoS / DDoS |
Keeping these three in mind helps organise both threats and defences: confidentiality is protected mainly by encryption and access control, integrity by validation and authentication, and availability by firewalls, filtering and resilient infrastructure. A breach of any one can be costly — stolen personal data, corrupted records, or an online service knocked offline — which is why organisations invest in layered protection.
Malware (malicious software) is any program written to damage, disrupt, spy on, or gain unauthorised access to a system. The categories differ chiefly in how they spread and what they do:
| Type | How it behaves |
|---|---|
| Virus | Attaches itself to a legitimate file or program and spreads when that host is run by a user — it needs a host and a trigger |
| Worm | Self-replicating malware that spreads across networks on its own, exploiting vulnerabilities, with no user action needed |
| Trojan | Disguised as legitimate, desirable software; performs hidden malicious actions once the user installs it — it does not self-replicate, it relies on deception |
| Ransomware | Encrypts the victim's files and demands payment for the decryption key — an attack on availability and the victim's data |
| Spyware | Secretly monitors activity (keystrokes, browsing) and exfiltrates it to the attacker — an attack on confidentiality |
| Adware | Forces unwanted advertisements, often bundled with free software; less harmful but invasive |
| Rootkit | Buries itself deep in the operating system to give an attacker persistent, privileged, hidden access |
The distinction between virus, worm and trojan is a favourite exam discriminator: a virus needs a host file and a user to run it; a worm spreads itself across networks autonomously; a trojan tricks the user into installing it and does not self-replicate. Confusing these three is the commonest malware error.
It is worth seeing how these categories combine in a real incident, because attacks rarely use just one. A typical modern compromise might begin with a phishing email carrying a trojan attachment; once an unwary user opens it, the trojan installs a rootkit to hide itself and grant persistent privileged access, then downloads ransomware that encrypts the organisation's files and demands payment, while perhaps also dropping spyware to harvest credentials for later use. The lesson for defence is that controls must overlap: anti-malware might catch the trojan, staff training might stop the phishing click, least-privilege access would limit what the rootkit could reach, and backups would allow recovery from the ransomware without paying. No single one of these would have stopped the whole chain, which is exactly the argument for defence in depth made later. Ransomware in particular illustrates why backups are a security control and not merely an IT convenience: if good, recent, offline backups exist, an organisation can restore its data and refuse the ransom, whereas without them it faces either paying criminals or losing everything.
Not all attacks are technical. Social engineering manipulates people into breaking security — revealing a password, clicking a link, or granting access — by exploiting trust, fear, curiosity or helpfulness. Because it targets the human rather than the system, no firewall or patch can stop it; the defence is awareness and training. The most common form is phishing:
| Form | Description |
|---|---|
| Email phishing | Mass fake emails impersonating a trusted source (bank, employer) to harvest credentials |
| Spear phishing | Phishing targeted at a specific individual, using personal details to be more convincing |
| Whaling | Spear phishing aimed at senior figures (executives) for higher-value access |
| Smishing | Phishing delivered by SMS text message |
| Vishing | Phishing by voice call, impersonating support or authority |
| Pharming | Redirecting users to a fake site by corrupting DNS or a hosts file, even when they type the correct address |
Other people-centred or low-tech threats worth knowing include shoulder surfing (watching someone enter a PIN or password), brute-force attacks (trying every possible password until one works) and insider threats (misuse by an employee or contractor, whether malicious or merely careless).
A Denial of Service (DoS) attack aims not to steal but to deny — it overwhelms a server with so much traffic or so many requests that it can no longer respond to legitimate users, attacking availability.
graph TD
Bot1["Compromised PC"] --> C["Attacker's botnet<br/>command & control"]
Bot2["Compromised router"] --> C
Bot3["Compromised IoT device"] --> C
C -->|flood of requests| S["Target server<br/>overwhelmed — cannot serve<br/>legitimate users"]
User["Real user"] -.->|request times out| S
| Variant | Description |
|---|---|
| DoS | Flood originating from a single source |
| DDoS | Flood from many sources at once — typically a botnet of thousands of compromised devices controlled by the attacker |
| Effect | The server's bandwidth, connections or processing are exhausted, so genuine requests are dropped or time out |
A DDoS is far harder to defend against than a plain DoS precisely because the traffic comes from many scattered machines, so simply blocking one source achieves nothing. Defences include firewalls and rate-limiting, traffic-filtering services that absorb or scrub the flood, and over-provisioning capacity — but a large DDoS remains one of the hardest attacks to stop.
SQL injection targets web applications that build database queries from user input without sanitising it. By entering crafted text into an input field (such as a login box), an attacker can change the meaning of the SQL the application runs.
-- The application intends this query:
SELECT * FROM users WHERE username = 'alice' AND password = 'pass123';
-- But the attacker types ' OR 1=1 -- into the username field, producing:
SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '';
The injected condition OR 1=1 is always true, so the WHERE clause matches every row, and the -- turns the rest of the line (including the password check) into a comment that is ignored. The query therefore returns all users and the attacker logs in without a valid password — and more damaging injections can read, alter or delete data. The crucial point is why it works: the application mixed untrusted data into trusted code, letting input be interpreted as instructions.
The defences follow directly from that diagnosis:
| Defence | How it prevents the attack |
|---|---|
| Parameterised queries (prepared statements) | Input is passed as a separate parameter, never concatenated into the SQL, so it can only ever be data and never code — the primary, decisive defence |
| Input validation | Reject input that does not match the expected pattern (length, allowed characters) before it is used |
| Escaping special characters | Neutralise characters such as ' so they cannot break out of a string literal |
| Least privilege | The database account the app uses has only the minimum rights, limiting the damage if injection succeeds |
This connects straight to the web-technologies lesson's rule: never trust client-side validation — because an attacker can bypass the page entirely, the server must validate and use parameterised queries.
In a man-in-the-middle attack, the adversary secretly positions themselves between two communicating parties, who believe they are talking directly to each other. The attacker can then eavesdrop on the traffic (breaking confidentiality) and may alter or inject messages (breaking integrity).
graph LR
A["Victim"] -->|thinks it talks to B| M["Attacker<br/>(in the middle)"]
M -->|relays, having read/altered| B["Server"]
B -->|reply| M
M -->|relays back| A
A classic setting is an open Wi-Fi network where an attacker intercepts unencrypted traffic, or an evil-twin access point. The decisive defence is encryption: with HTTPS (HTTP over TLS) the traffic is encrypted and the server's identity is verified by a certificate, so an interceptor sees only ciphertext and cannot impersonate the server. VPNs similarly encrypt all traffic across an untrusted network. This is exactly why entering credentials on plain HTTP is dangerous and why browsers insist on HTTPS — the encryption that defeats MITM is the symmetric/asymmetric machinery derived in the Encryption lesson of the Data Representation course.
The threats above motivate a complementary set of controls. The skill is matching defence to threat.
A firewall monitors and filters traffic crossing a network boundary, allowing or blocking it according to a set of rules (based on IP address, port number and protocol). It is the gatekeeper between an internal network and the outside.
| Firewall capability | What it does |
|---|---|
| Packet filtering | Inspects each packet's header against rules and permits or drops it |
| Stateful inspection | Tracks the state of active connections, so replies to legitimate outgoing requests are allowed while unsolicited inbound traffic is blocked |
| Application-level gateway | Inspects traffic at the application layer, understanding the content of specific protocols |
Firewalls chiefly defend availability and access — blocking unauthorised connections, unwanted ports and some flooding — but they cannot stop a user being phished or a flaw being exploited through an allowed port.
To see a firewall working, recall the ports from the TCP/IP lesson. A web server's firewall might be configured to permit inbound traffic only on port 443 (HTTPS) and to drop everything else, so an attacker probing for an exposed database service on port 3306 or a remote-desktop service finds those doors firmly shut. Stateful inspection adds a vital refinement: when an internal machine initiates a connection to a website, the firewall records that outgoing connection and automatically permits the matching reply to return — but an unsolicited inbound packet that does not correspond to any established connection is blocked. This lets users browse freely while preventing outsiders from starting connections into the network. A firewall may be a dedicated hardware appliance at the network boundary, a software firewall on each host, or both, and the two together form complementary rings of filtering — another small instance of layering.
A proxy server sits between clients and the wider Internet, forwarding requests on the clients' behalf. Because all traffic passes through it, a proxy can filter content (blocking disallowed sites), cache frequently-requested pages (improving speed and reducing bandwidth), log and monitor usage, and hide the clients' internal addresses from the outside (since requests appear to come from the proxy). This anonymising and filtering role makes a proxy a useful security and management control, often working alongside a firewall.
It is worth distinguishing the two directions a proxy can face. A forward proxy stands in front of the clients, so that a school or company's machines reach the Internet through it — this is what enforces an acceptable-use policy (blocking inappropriate sites), caches popular pages for the whole organisation, and conceals individual users behind the one proxy address. A reverse proxy, by contrast, stands in front of the servers: incoming requests from the Internet hit the reverse proxy first, which can hide the real servers' addresses, distribute load across several back-end servers, cache responses, and absorb or filter hostile traffic before it reaches them — making a reverse proxy a useful first line of defence against attacks, including helping to soak up some flooding. In both cases the security value comes from the same property: nothing reaches the protected machines directly, so the proxy becomes a controllable choke-point where filtering, logging and concealment can be applied.
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.