Your first security lab, set up safely

A lab lets you test concepts without relying on third-party systems. It can be simple: a virtual machine for learning, a vulnerable application built for training, and an isolated network. The most important thing is to define boundaries before you begin.

This guide shows how to set up that environment, truly isolate it, and record what you learn.

Define the objective

Choose a small question, such as “where do I find access logs?” or “how does a firewall rule change the connection?” Knowing what you want to observe prevents you from installing tools without a purpose.

This is the most common beginner mistake: building a machine full of tools before having a question. The result is an impressive environment and shallow learning. One question per session delivers more than ten installed tools.

Record the environment’s initial state. Note versions, network configuration, and what you expect to see. After the test, compare the result with the hypothesis — the difference between what you expected and what you observed is where learning happens.

Truly isolate the environment

Use training virtual machines or containers and keep the lab network separate from the devices you use every day.

The most common source of accidents is the virtual machine’s network configuration. The common options are not equivalent:

Bridged mode places the virtual machine on the same network as your printer, router, and home computers. A scan run there is no longer just a lab exercise — it reaches real equipment, possibly belonging to other people.

The practical rule: use an internal network by default and enable outbound access only when you need to download something, returning to isolation afterward. NAT does not guarantee isolation from the local network: connectivity depends on the host’s routes and network controls. In host-only mode, the host is also reachable; do not enable forwarding or another external route without assessing its effect. The VirtualBox network modes table details these differences. Check the configuration before running any scan or test, and do not assume a target is yours simply because it responded on the network.

If the lab needs internet access to update packages, do that first and then isolate it. A deliberately vulnerable environment exposed to the internet is a real problem, not an exercise.

Create snapshots or another way to restore the environment. This lets you repeat the exercise, investigate errors, and start over without carrying previous changes forward. Take the snapshot after configuration and before beginning the test — that is the point you will want to return to.

What to build first

A useful starter lab needs very little:

1. A hypervisor — VirtualBox, UTM, Hyper-V, or whatever runs well on your machine.
2. A target machine, with a deliberately vulnerable educational application.
3. A workstation, from which you observe and test.
4. An isolated network connecting only the two.

For the target, prefer projects made for education: OWASP WebGoat and Juice Shop are maintained specifically for this purpose, provide guided exercises, and leave no doubt about authorization. In many cases, they run in a container and remove the need for a complete second virtual machine.

Online learning platforms are a legitimate alternative when setting up a local environment is difficult. Their authorized scope is whatever the platform defines — following its rules is part of the exercise.

Document the experiment

A useful note records the objective, environment, steps, observations, and conclusion. Include what did not work — that is the part you will read again.

A format you can complete in a few minutes:

Date / Objective (the question)
Environment: versions, network, starting snapshot
Hypothesis: what I expect to observe
What I did: steps, in order
What I observed: including the unexpected
Conclusion: the answer to the question
Open questions: what remains unanswered

This history helps you understand the cause of a result and prevents learning from becoming a collection of commands without context. It is also raw material for your portfolio: a well-documented experiment notebook is concrete evidence of reasoning.

Expand gradually

Once you master a small scenario, add log collection, a second machine, or a training application. Every change should have a reason.

A progression that works:

• First: a vulnerable application and a browser. Observe requests.
• Then: add log collection and look, from the defensive side, for the activity you generated.
• Next: a second machine, to observe traffic between hosts.
• Later: a directory service or centralized authentication, to study identity.

The second step is the most educational and the most often skipped. Generating activity and then looking for it in the logs teaches offense, defense, and the limitations of telemetry all at once.

Checklist before you begin

• confirm that all systems and data belong to you or have been authorized for training;
• describe the objective and expected behavior before opening the tool;
• review the network configuration and confirm isolation;
• create a restore point and record how to return to the initial state;
• confirm that no target outside the lab responds within the range you will test;
• when finished, note what you observed, what failed, and what you will test next.

If a step cannot be explained safely or falls outside the lab’s scope, stop and return to the objective. Clear boundaries are part of mature technical practice.

Next step

Build the smallest scenario today — a hypervisor, an educational target, and an isolated network — and answer a single question, documenting it in the format above. A small lab that produces a clear note is worth more than an elaborate environment with no records.

Practice only on systems you own, educational platforms, or with explicit authorization. A target responding on the network is not an invitation: authorized scope is what separates learning from improper access.