Hardening, access control and network defences

Why this matters

This is the domain 4 capstone, and it is the constructive half of the domain: the previous lesson listed what goes wrong, this one lists what you do about it.

Objective 4.3 is "given a scenario, apply network security features, defense techniques, and solutions", so the questions are applied — a situation, and which control addresses it. Most of the controls here directly answer an attack from the previous lesson, and learning them as pairs is the efficient route.

The lesson

Device hardening

Device hardening means reducing a device's attack surface to the minimum it needs to do its job. Two specific measures are named in the objective, and they are named because they are the two that get skipped.

Change default passwords. Default credentials are published in the vendor's own documentation, and scanning for devices still using them is entirely automated. This is not a theoretical risk — it is how the Mirai botnet assembled hundreds of thousands of devices. Every device, including the ones that seem unimportant: cameras, printers, UPS management cards, access points.

While you are there: use unique passwords per device where possible, so that recovering one does not yield all of them, and prefer centralised authentication (TACACS+ or RADIUS) so credentials are managed in one place and removed in one action.

Disable unused ports and services. Every listening service is something that can be attacked, and every live switch port is somewhere an unauthorised device can be plugged in. Turn off HTTP management in favour of HTTPS, Telnet in favour of SSH, and any protocol the device does not need. Administratively shut down unused switch ports and place them in an unused VLAN, so a cable in a meeting room reaches nothing.

The broader hardening checklist: patch firmware and OS, restrict management access to specific source addresses, enable logging to a central collector, use SNMPv3 rather than v2c, and back up the configuration.

Key management

Key management is the lifecycle of cryptographic keys and certificates — generation, distribution, storage, rotation, revocation and destruction.

It matters because encryption is only as good as the handling of its keys. Common failures are more mundane than any cryptographic weakness: a private key committed to a source repository, a key emailed to a colleague, a certificate nobody renewed, a pre-shared key that has not changed in six years and is known to everyone who has ever worked there.

What good practice looks like: generate keys on the system that will use them so the private key never travels; store them in a hardware security module or dedicated key vault; rotate on a defined schedule; revoke immediately when someone leaves or a key may be exposed; and track expiry dates in the asset inventory, because an expired certificate is an outage with a date you could have known in advance.

Security rules and ACLs

An access control list (ACL) is an ordered list of permit and deny rules matched against traffic — source and destination address, protocol, port.

Two properties decide how ACLs behave, and both are examined:

Order matters. Rules are evaluated top to bottom and the first match wins. A permit-any near the top makes everything below it dead code, and the usual error is placing a broad rule above the specific one that was meant to constrain it.

There is an implicit deny at the end. Anything not explicitly permitted is dropped. That is a safe default, and it is also why an ACL that permits inbound traffic but forgets the return path produces a connection that hangs rather than being refused — the same stateless trap as the cloud network ACLs in domain 1.

Security rules more broadly are firewall policy, and the principles are the same: least privilege, deny by default, specific before general, and every rule documented with a reason and an owner. Undocumented rules are never removed, because nobody dares.

Network access control

Network access control (NAC) decides whether a device may join the network at all, and what it may reach once admitted. Three mechanisms sit under it, in ascending order of strength.

MAC filtering permits only listed MAC addresses. It is the weakest control here and the exam expects you to know why: MAC addresses are trivially spoofed, and they are broadcast in plaintext by every frame, so an attacker simply watches, copies an allowed address, and is admitted. It also creates real administrative work as devices change. Treat it as a speed bump, not a control.

Port security limits which and how many MAC addresses may appear on a switch port, and acts when the limit is exceeded — shutting the port down, restricting it, or simply dropping. It is the direct mitigation for MAC flooding, and it also stops someone unplugging a phone and attaching a laptop in its place.

802.1X is the real answer. It is port-based network access control: the port carries no traffic beyond authentication until the device or user authenticates, usually to a RADIUS server. The three roles are the supplicant, the authenticator and the authentication server, as in the wireless lesson — and the same mechanism works on wired ports.

Modern NAC platforms extend 802.1X with posture assessment: check that the device is patched, running current antivirus, and has disk encryption before admitting it, and place devices that fail into a quarantine VLAN with access only to remediation resources. That is what makes BYOD manageable.

URL and content filtering

Uniform Resource Locator (URL) filtering blocks or permits access by web address, usually by category — gambling, malware distribution, known phishing — using a maintained reputation feed.

Content filtering is broader: inspecting the content itself, blocking file types, scanning downloads for malware, and applying data-loss rules to what leaves the network.

Both are usually implemented on a secure web gateway or next-generation firewall, and they serve two purposes at once — security, by blocking known-bad destinations and malware, and acceptable-use policy enforcement.

The practical limitation worth knowing: most traffic is encrypted, so meaningful content inspection requires TLS interception, where the gateway terminates and re-encrypts the session. That works, and it carries privacy implications, needs its own certificate deployed to every client, and breaks applications that pin certificates. It is a deliberate decision with real costs, not a checkbox.

Zones and the screened subnet

Firewall policy is written between zones — named groups of interfaces or networks that share a trust level — rather than between individual addresses. Zones make policy readable: "guest may reach internet only" is one rule instead of hundreds.

Trusted vs. untrusted is the basic division. The internal network is trusted; the internet is untrusted; traffic from untrusted to trusted is denied by default and permitted only by explicit exception.

That binary is too crude for anything that must be reachable from outside, which is what the third zone is for.

A screened subnet — the term that replaced "DMZ" — is a zone between the untrusted and trusted networks, holding the systems that must be reachable from the internet: web servers, mail gateways, reverse proxies, public DNS.

The rules that define it, and the reason it works:

• The internet may reach the screened subnet, on specific ports only.
• The screened subnet may not freely initiate connections into the internal network.
• Internal systems may reach the screened subnet as needed.

So if a public web server is compromised — the most likely thing to be compromised, because it is the thing exposed — the attacker has gained a foothold in a zone that cannot reach the databases and file servers. The screened subnet is a containment boundary, and that is the answer an exam question about "a server that must be publicly accessible" is looking for.

It is worth noting how this lesson ends where domain 1 began: zones, least privilege and default-deny are the same ideas the zero-trust lesson pushed further, replacing "which zone are you in" with "prove it again for this request".