A lab you can break safely, and why your laptop is not it

This lesson maps to no SY0-801 objective. CompTIA does not examine "build a lab", and nothing here will be asked of you. It exists because the hands-on labs attached to almost every objective in this course (most heavily 1.3, 2.5, 3.2, 3.4, 4.1 and 4.4, whose monitoring tooling is installed here) change settings, break things on purpose and read the logs afterwards, and there has to be somewhere to do that which is not the machine you need working tomorrow.

Why this matters

Security+ is not a hands-on exam. You can pass it having never hardened anything. You will be worse at the job, and (this is the part people underestimate) you will also be worse at the exam, because a large share of SY0-801's questions are scenarios that assume you have seen the thing being described. "The baseline was applied but the service failed to start" means something concrete to someone who has applied a baseline and had a service fail to start. To everyone else it is a sentence to be guessed at.

The other reason is blunter. Several labs in this course tell you to turn things off, open ports, generate failed logins until an account locks, and restore from a backup you deliberately corrupted. Doing any of that to your own working machine is how a study session turns into an evening of recovery.

CompTIA publishes a sample list of the equipment and software a training lab might contain, and the SY0-801 version names virtual machines, Windows and Linux, a SIEM, packet capture, a vulnerability scanner, a network mapper and sample logs. It also names a penetration-testing distribution and penetration-testing software. This course's labs stay on the defensive side of that list: everything you build here is configured, hardened, monitored and recovered, and nothing in any lab points a tool at a system you do not own.

The lesson

Two virtual machines, one network, no route to anything you did not build

The whole lab is two guests on an internal-only virtual network.

Any hypervisor will do: VirtualBox, VMware Workstation, Hyper-V on Windows Pro, or KVM. What matters is the network mode. Use the one your hypervisor calls internal, host-only or private: the guests can see each other and nothing else. Do not use bridged. Do not leave NAT enabled once you have finished installing packages.

There is a real reason beyond tidiness. Several of the later labs generate traffic that looks exactly like an attack: repeated failed authentications, a port scan of a host you own, a burst of DNS queries against your own resolver. On an isolated segment that is a lesson. On your home network it is noise your ISP's abuse desk may eventually ask you about, and on a corporate network it is a conversation with your employer.

Give each guest a fixed address in a range you will recognise later. The labs assume 10.99.0.10 for the Linux guest and 10.99.0.20 for the Windows guest. When you are reading a firewall log in Domain 4, addresses you chose yourself are far easier to reason about than whatever DHCP handed out.

A Windows target and a Linux target, because the exam assumes both

SY0-801 is vendor-neutral but it is not platform-blind. Group Policy appears in it by name, and so does SELinux; syslog is named as a monitoring protocol, and permission assignments are an identity topic that looks different on each platform. Questions about logs, accounts and baselines are easier when you have seen a Windows event and a Linux log line side by side. You need one of each to have seen both.

For Windows, an evaluation copy of Windows Server or a Windows 10/11 evaluation image is enough; Microsoft publishes time-limited evaluation images for exactly this purpose. For Linux, take a current long-term-support Ubuntu Server or a Rocky or AlmaLinux minimal install. Server editions, not desktop: you want the command line, and you want the smaller default footprint so that when you harden it you can see what changed.

Two gigabytes of RAM each and 20GB of disk is plenty. This lab runs comfortably on a machine with 8GB.

Snapshots, so a broken hardening experiment costs thirty seconds

Take a snapshot of each guest the moment the install finishes, before you change anything, and name it installed. You will take one more, named clean, once the tooling is in and the isolation has been proven at the end of this lesson. clean is the state every later lab starts from.

This single habit is what makes the rest of the course usable. Hardening is iterative and most of the learning is in the failures: you disable a service and something unrelated stops working, you apply a permissions change and lock yourself out of your own shell, you turn on a firewall default-deny and lose the session you were typing in. All of those are good outcomes to have had, and all of them cost half a minute to undo if there is a snapshot and most of an evening if there is not.

Revert to clean between labs unless a lab says otherwise. Carrying the wreckage of one exercise into the next makes it impossible to tell which change caused what, which is the same reason change management in Domain 1 insists on one recorded change at a time.

Installing the log and monitoring tooling the later lessons measure with

Install these once, while the guests still have a temporary route out for package downloads:

• On the Linux guest: auditd, rsyslog (usually already present), nmap, tcpdump, openssl and curl. The decoy-file lab wires an auditd rule to a file and reads what it records; the alerting and monitoring lab forwards rsyslog to a collector.
• On the Windows guest: nothing extra is strictly required. Event Viewer, Get-WinEvent, Windows Defender Firewall and Local Security Policy ship with it. Install Sysmon if you want the Domain 4 logging labs to be considerably more interesting; the lessons work without it.
• Optionally, on the Linux guest, a small log-collection stack. The labs are written to work with plain files so that nobody is blocked on getting a SIEM running, but if you already know one, point it at both guests.

Everything above is free and none of it requires a licence you do not already have. When the installs finish, remove the NAT adapter or switch it back to the internal network. The next section is how you prove you did.

Proving the isolation before the first lesson that changes a setting

Do not take the hypervisor's word for it. From the Linux guest:

ping -c 2 10.99.0.20        # the other guest: should succeed
ping -c 2 1.1.1.1           # the internet: should fail
curl -s -m 5 https://example.com    # should time out, not return HTML
ip route                    # there should be no default route

The last one is the real test. A guest with no default route cannot reach anything off its own subnet regardless of what the hypervisor claims about network modes, and it is a single line to verify.

From the Windows guest, Test-NetConnection 10.99.0.10 should succeed and Test-NetConnection example.com -Port 443 should fail.

If the internet checks succeed, your network mode is wrong. Fix it before you continue. A lab that is "mostly isolated" is not isolated, and the first time it matters will be the time you generate something you would rather had stayed inside.

Once both guests pass, snapshot them and name the snapshot clean. Repeat the checks after any change to the hypervisor's networking and after any lab that touches a firewall. Isolation is a control, and like every control in this course it needs verifying again, not just designing once.

What to take into the exam

Nothing here is examinable. What the lab buys you is the ability to answer scenario questions from memory of having done the thing rather than from a definition, and that is worth more marks in Domain 4 than any single fact in this lesson. Two habits carry straight into the exam anyway: a change you cannot undo is a change you should not make without a rollback, and a control you have not tested is a control you are only assuming works.