An exposed Samba share on file1 at 10.0.0.30 can reveal files to someone who reaches the service without needing to break a password or install malware. That outcome is useful in our lab because it shows why security testing needs limits before any test begins. We will inspect only systems we own or are authorized in writing to test, and we will record what the service exposed so its owner can close the gap.
Our fixed environment is the private 10.0.0.0/24 network. Kali at 10.0.0.10 is the testing workstation. web1 at 10.0.0.20 is a Metasploitable 2 target with services on ports 21, 22, and 80, while file1 at 10.0.0.30 exposes Samba on ports 139 and 445. No address outside this subnet belongs to the exercise, and the lab has no internet-facing target. We show the shape of a weakness and its observable effect, not weaponized steps that could be reused against another system. Let’s inspect the boundary that keeps every later exercise contained:
This diagram establishes one allowed direction, from Kali toward the two named lab targets. A request to 10.0.0.30 is in scope because file1 is an assigned target; the same request to an unfamiliar address is prohibited even if the service appears identical.
Because the network boundary alone does not define acceptable behavior, we need a Rules of Engagement agreement, a written contract that limits who may test, which assets may be tested, when testing may occur, and which methods are allowed. For this course, the agreement names web1 and file1, restricts activity to 10.0.0.0/24, and treats Kali as the only testing origin. Written authorization distinguishes a controlled assessment from unauthorized access under laws such as the United States Computer Fraud and Abuse Act and the United Kingdom Computer Misuse Act 1990. This course provides technical education, not legal advice.
The agreement also prevents a beginner exercise from becoming harmful. We may identify exposed services and safely observe whether an anonymous Samba listing reveals a file name. We do not tune payloads, evade monitoring, create persistence, disrupt availability, launch high-volume password guessing, or place real credentials in notes. A test should create evidence that a defender can check, not create an uncontrolled change that the lab owner must recover from.
Safe boundary
If an action changes access, availability, or persistence beyond the agreed observation, stop and record the condition rather than proceeding.
Every permitted step produces a small evidence trail. The notebook records the command as typed, a timestamp, the target address, and the relevant output. If a share listing shows backup.zip, we record that name and the access condition, then ask what defender log would show the connection and which configuration would prevent anonymous access. The table separates useful observations from actions that exceed our agreement: