Create an authorised asset inventory with Nmap
Scan a tiny lab subnet, compare discovered services with the expected inventory, and document ownership before assessing risk.
Scope
For learners scanning only their isolated lab network or systems covered by written authorisation.
Start with the situation, not the slogan
This lab is designed to produce evidence and judgement, not a ceremonial screenshot of a tool running. Create an authorised asset inventory with Nmap is successful when you can explain the question, predict the expected observation, collect it safely and distinguish a useful result from noise. The commands are the least interesting part, although they are traditionally the part everyone photographs.
Use systems you own or have explicit permission to test. Keep the exercise isolated from household, client and production networks, take a snapshot before deliberate breakage, and write the rollback step before the first change. A lab without a reset path is simply a future troubleshooting appointment.
A port scan is an observation, not a vulnerability finding. Its first defensive value is discovering which hosts and services exist and whether the inventory is accurate.
Composite scenario
How this usually reaches the desk
Set one modest objective for the session. Begin with the expected clue: The target range, owner, maintenance window, rate limit, and allowed techniques are documented. Then create or collect only enough benign activity to make that clue visible. If the observation does not appear, investigate the data path before adding more tools. Instrumentation that cannot see a known test event will not become more perceptive during a real incident.
This scenario combines common operational patterns; it is not presented as a report of one named incident.
What to look for
Begin with preserved, comparable evidence. One signal is rarely proof; use independent observations and a reliable timeline before declaring scope or intent.
The target range, owner, maintenance window, rate limit, and allowed techniques are documented.
Write the expected observation before the exercise. Include the source, destination, time and field that should carry it; this turns an interesting screen into a falsifiable test.
Expected hosts and services are listed before the scan to make differences visible.
Confirm that clocks, names and identifiers line up across the lab. Time drift and ambiguous hostnames can turn three tidy events into an accidental detective novel.
Output is saved in a parseable format with time, tool version, and command context.
Keep a known-good comparison. The aim is not merely to produce an alert or packet, but to explain how the test differs from ordinary activity and where false positives would arise.
Working examples
Run it, read it, decide what changes
These examples use documentation addresses, test identities and bounded targets. Replace placeholders only inside systems you own or are explicitly authorised to operate. Read the expected result and next action before running the command; a successful command is evidence, not yet a conclusion.
Run a bounded authorised TCP baseline
- Prerequisites
- One public IP you own, written scope, and an external network; replace the documentation IP only after verifying ownership.
nmap -Pn -sT --top-ports 1000 --reason -oA perimeter-baseline 203.0.113.25Nmap classifies common TCP ports as open, closed or filtered and saves normal, XML and grepable output.
Open means a listener answered; it does not mean vulnerable. Filtered means the scan could not decide. Compare every open port with the intended inventory.
Run focused version detection only on expected or unexplained open ports, then confirm the process and package locally.
Identify one exposed service carefully
- Prerequisites
- A port found open in the baseline and permission for service probes.
nmap -Pn -sV --version-all -p 443 --reason -oA service-443 203.0.113.25Nmap reports a service fingerprint or best-effort product/version lead for TCP/443.
A banner can be hidden, proxied or backported. Never equate the printed string directly with a CVE match.
Confirm the product and package version on the server, then check the vendor advisory, supported version and CISA KEV/NVD record where applicable.
Check a web endpoint passively
- Prerequisites
- A website you own and approval for spidering; the baseline scan is passive after a short spider.
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://www.example.com -r zap-report.htmlZAP writes a report of passively observed warnings; by default alerts are warnings rather than automatic failures.
A warning is a configuration or application lead, not proof of exploitability. The baseline does not perform a full active security test.
Review each alert against the application, fix confirmed issues, rerun the same command, and retain both dated reports.
Lab procedure
Read the whole sequence before starting. Several workstreams may run in parallel, but their evidence, authority and expected outcomes still need to be explicit. Every step below points back to a concrete example; use the example as implementation evidence, not as permission to operate outside the stated scope.
Operational judgement
Keep a lab notebook with four columns: time, action, expected evidence and observed evidence. Add screenshots only when they preserve information that text cannot. The notebook should allow another person to repeat the exercise without inheriting your browser history, shell history and particular relationship with luck.
The transfer-to-production question matters more than the demo. For Nmap, Asset inventory and Network, consider data volume, retention, credentials, privacy, performance, ownership and failure behaviour. A successful lab proves that a mechanism can work under stated conditions; it does not prove that it can be deployed everywhere before lunch.
Handover
Make the result useful to the next person
Turn the exercise into a reusable lab card. Record the learning objective, isolation boundary, diagram, versions, seed data, expected observations, exact queries, screenshots that add real information, and the reset procedure. Mark which evidence was generated and which was supplied. If the lab uses a deliberately vulnerable image or sample, store its provenance and checksum. Future-you is a different operator and deserves better documentation than “it worked after I restarted something”.
End with a short teach-back. Explain why “Confirm written scope and use only the small lab subnet; exclude every external, home, and production address.” matters, demonstrate the observation that supports the conclusion, and show how the environment returns to baseline after “Assign each difference to an owner and record whether it is expected, misconfigured, obsolete, or unknown.” Then name one production assumption the lab did not test. That last sentence keeps a useful experiment from turning into unjustified confidence and gives the next exercise a sensible place to begin.
Validate before you close
Repeat the scan after corrections and confirm the inventory explains every discovered host and service without causing availability or alerting problems.
Capture the test, the expected result and the observed result. Where a person or business owner must accept restored service, name them in the record. A green dashboard can confirm that a component is answering; it cannot confirm that invoices, identities or restored data are trustworthy.
Finish with a compact closure note: the original trigger, confirmed scope, evidence retained, controls changed, tests passed, known gaps, residual risk, and the people responsible for the remaining work. Schedule a review while the timeline is still fresh enough to challenge. The purpose is not to find a person to blame; computers already perform blame with admirable efficiency. The purpose is to make the next response faster, safer and less dependent on one person remembering where the useful log was hidden.
Common mistakes
- Connecting an intentionally weak lab directly to a home or production network.
- Copying commands without recording the expected evidence and rollback step.
- Calling a test successful without comparing the result to a known-good baseline.
These errors usually come from haste, unclear ownership or misplaced confidence. Build the safeguard into the runbook: a required evidence field, a second-person review, a rollback test or a specific exit criterion.
Questions people ask when the clock is running
Can I run this against a public target for practice?
No. Keep the work to systems you own or are explicitly authorised to assess. An educational intention is not an access-control mechanism and will not improve the conversation with a provider or solicitor.
What should I save from the exercise?
Keep the topology, versions, raw evidence, exact filters or rules, expected result, observed result and rollback notes. Remove real secrets and personal data before sharing the notebook.
How do I know the lab worked?
Repeat the scan after corrections and confirm the inventory explains every discovered host and service without causing availability or alerting problems. Repeat the key observation from a clean snapshot; repeatability is a stronger result than a single attractive screenshot.
Safety boundary
Use these steps only on systems you own or are explicitly authorised to assess. Preserve evidence, follow your organisation’s legal and regulatory obligations, and prefer reversible actions when the situation is not yet understood.
Primary references
- Nmap Reference GuideNmap Project
- Service and Application Version DetectionNmap Project
- ZAP Baseline ScanOWASP ZAP
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.