Introduction
Reconnaissance begins with a clear target and scope. A port number, a port state, an application fingerprint, and a vulnerability conclusion describe different things and should not be treated as interchangeable.
You will use the prepared local DNS and HTTP services to practice a small Nmap workflow. Resolve the target, scan only its assigned ports, identify the services, and retain the output for analysis.
Resolve the Target and Scan Selected Ports
In this step, you will resolve an explicitly supplied training target and use a TCP connect scan against a small port set.
Enter Kali and choose the shared workspace:
kali
cd /home/labex/project
The authorized target is training-target.test, served by the local training DNS server. Resolve its A record using the DNS workflow from the preceding lab:
dig @127.0.0.1 -p 5353 +short training-target.test A
The answer is 127.0.0.1, the container's loopback address. Only ports 8000, 8081, and 9999 on that address are in scope. Do not scan the host, gateway, or any public system.
Nmap discovers host and service information. Its -sT option uses normal TCP connection attempts, so this scan works as the ordinary learner. -p limits the requested port set; commas separate port numbers. -oN saves normal, human-readable output to the following filename:
nmap -sT -p 8000,8081,9999 -oN ports.txt 127.0.0.1
Wait for the scan to finish. It should report ports 8000 and 8081 as open, while port 9999 is closed. Open means a service accepts TCP connections; closed means the target responded but no service accepts connections at that port. A filtered result instead means Nmap could not determine the state because probes or responses were obstructed.
Read the saved report:
cat ports.txt
It should identify the target and contain the requested port rows. Without version detection, a SERVICE label may come from Nmap's conventional port-name table. Treat it as a hint rather than proof of the application actually listening.
Identify Services and Extract Open-Port Records
In this step, you will use service-version probes and save a concise set of findings.
The -sV option asks Nmap to probe open services for application information. It is service/version detection, not the Nmap Scripting Engine (NSE), and it does not by itself confirm a vulnerability. Limit the probes to the two open training ports:
nmap -sT -sV -p 8000,8081 -oN services.txt 127.0.0.1
The supplied services are Python HTTP servers. The results should identify HTTP and may include Python or server-version details. Exact tool and interpreter versions can change with environment maintenance.
Read the saved version report:
cat services.txt
Compare its service evidence with the conventional names in ports.txt. A non-default port can still run HTTP; the port number is not the application identity.
Extract the open-port rows using the text-filtering workflow already taught. The spaces around open keep the match focused on the state column:
grep ' open ' services.txt > open-services.txt
cat open-services.txt
You should see one row for each of the two open ports. These rows record observed exposure and service information, not proof that either service is exploitable. Keep the full report alongside the concise findings so you can revisit the original context.
Summary
You resolved an authorized target, performed a focused TCP connect scan, interpreted open and closed states, and used service-version probes. You preserved the full reports and extracted concise open-service rows without confusing discovery with vulnerability confirmation.
