IT Course Directory: VMware, Linux, Networking, and Raspberry Pi

Nmap Online Course: Network Scanning Fundamentals and Practical Usage

Learn Nmap installation, host discovery, TCP and UDP scanning, service and OS detection, Zenmap, result interpretation, troubleshooting, and secure scan reporting in an authorized lab.

Course overview

Nmap is an open-source utility for network discovery and security auditing. It helps authorized administrators and defenders inventory assets, identify reachable hosts, review exposed ports, verify services, investigate connectivity problems, and document changes.

Use Nmap only against systems and networks that you own or are explicitly authorized to assess. Before scanning, define the scope (the approved targets), rate limits, maintenance window, expected scan types, notification contacts, and logging or retention requirements. A private training network such as 192.168.56.0/24 is appropriate when it is isolated and controlled. Scanning public or third-party systems without permission is not an educational exercise; it is unauthorized activity.

Prerequisites and lab safety

You should be comfortable with basic Windows or Linux command-line navigation, IPv4 addresses, simple subnet concepts, and the difference between a host, protocol, service, and port. Build a small lab with your workstation, an isolated virtual network, at least one training VM, and deliberately enabled test services such as a web or SSH service.

Use a virtual machine or dedicated lab system for Kali Linux or other security tooling. Kali Linux is a security-focused Linux environment; it is not a permission bypass. Keep virtual adapters, routing, firewall rules, and snapshots documented so that test traffic cannot reach unintended networks.

Networking foundations for Nmap

OSI and TCP/IP models

The OSI model divides communication into seven conceptual layers. Nmap activity is most visible at the network layer, where IP addresses and routing operate, and the transport layer, where TCP and UDP ports operate. The TCP/IP suite groups these ideas into fewer practical layers.

Addresses, subnets, and routing

An IPv4 address contains 32 bits and is commonly written as four decimal octets, for example 192.168.56.10. A subnet groups addresses that share a network prefix. CIDR notation writes the prefix length after a slash: 192.168.56.0/24 normally represents addresses from 192.168.56.0 through 192.168.56.255, with usable host assignments depending on the network design.

A host is a device or virtual system with a network identity. A default gateway is the router a host uses when the destination is outside its local subnet. Routing determines where packets travel; a correct target address does not guarantee that a route, firewall policy, or return path exists.

A MAC address identifies a network interface at the local data-link network. It is not a substitute for an IP address and normally is not carried across routers. Local discovery can therefore provide different evidence from discovery across a routed network.

TCP, UDP, ports, and sockets

TCP is connection-oriented. A typical connection uses a three-way handshake involving SYN, SYN/ACK, and ACK; a closed TCP port commonly replies with a reset (RST). UDP is connectionless and does not require a handshake, so a silent UDP port may be either open or filtered.

A port is a numbered transport endpoint. A service is the software that listens and responds there. A socket endpoint combines an address, protocol, and port, such as TCP 192.168.56.10:80. Well-known ports are 0–1023, registered ports are 1024–49151, and dynamic or private ports are 49152–65535. Port numbers are conventions, not proof: software can listen on an unusual port, and a program can identify itself inaccurately.

IPv4 packet header

The IPv4 header carries addressing and delivery information. Important fields include version, header length, total length, identification and fragmentation flags, fragment offset, time to live (TTL), protocol (such as TCP, UDP, or ICMP), header checksum, source address, destination address, and optional options. Nmap observes responses shaped by these fields and by the network devices handling them.

Installing Nmap

Windows

1. Obtain the official Nmap installer through the normal Nmap distribution channel.
2. Run the installer with appropriate local permissions and accept the required network components for your lab.
3. Open a new Command Prompt or PowerShell session.
4. Verify the installation with nmap --version.

Linux

Use the package manager for the installed distribution. Examples for Debian-family and Fedora-family systems are:

sudo apt update && sudo apt install nmap
sudo dnf install nmap
nmap --version

Package commands vary by distribution. If the command is not found, confirm that the package is installed, open a new terminal, and check that the executable directory is in the system PATH.

Zenmap and Kali Linux

Zenmap is Nmap's graphical front end where supported. Availability depends on the operating system and package set. Command-line Nmap remains important because commands are easier to automate, review, repeat, and store in assessment records.

Kali Linux provides many security tools in a security-focused environment. Run it safely in an isolated virtual machine, a dedicated lab computer, or another explicitly approved setup. Keep the lab network separated from production and public networks.

Command-line basics

The basic structure is a target followed by scan and output options. Options change discovery, protocol, ports, detection, timing, diagnostics, or reporting.

nmap 192.168.56.10
nmap -p 80 192.168.56.10
nmap -p 22,80,443 192.168.56.10
nmap -p 1-1024 192.168.56.10

Standard output usually includes target status, a port table, protocol, state, probable service, optional version information, and a scan summary. Treat “service” as an identification hypothesis unless corroborated.

Accurate target definitions prevent accidental scanning. DNS names may resolve to changing or multiple addresses, while an IP-only target avoids some ambiguity. Confirm that name resolution points into the approved scope before scanning.

Host discovery

Host discovery asks which systems appear reachable; a port scan asks what transport endpoints respond. They are related but different operations.

nmap -sn 192.168.56.0/24
nmap -sn -PS22,80,443 192.168.56.0/24

The first command performs host discovery without a normal port scan. The second adds TCP SYN-based discovery probes for selected ports. A SYN probe requests the beginning of a TCP connection; SYN/ACK suggests a listener, while RST proves that the host's TCP stack responded even if that particular port is closed.

On a local Ethernet network, link-layer discovery can provide strong evidence because the scanner and target share the network segment. Across routed networks, routers may block or transform discovery traffic, so the same method can be less reliable. Firewalls, filtering, routing mistakes, powered-off systems, and rate limiting can all create ambiguous results.

No-ping, written -Pn, disables the preliminary host-discovery assumption and tells Nmap to treat a known target as up:

nmap -Pn 192.168.56.10

Use this only for a confirmed in-scope target. It is useful when a firewall blocks discovery probes, but it can waste time if the address is wrong or the host is actually offline.

Service and operating-system detection

Service/version detection sends additional probes to open or potentially open ports and compares responses with fingerprints:

nmap -sV -p 22,80,443 192.168.56.10

The result is a probable application and version, sometimes with a confidence indication. Banners can be hidden, altered, or misleading, and a service may be running on a nonstandard port. Confirm important findings against local service configuration or authorized administration records.

Operating-system detection estimates the target OS from network-stack characteristics such as response formatting, TCP options, sequencing behavior, and other patterns:

sudo nmap -O 192.168.56.10

OS detection is an estimate, not proof. Virtual machines, NAT, proxies, load balancers, packet filters, and limited responses can make the fingerprint incomplete or inaccurate. Administrative privileges are commonly required for some detection methods.

Zenmap workflow

1. Enter the approved target in the Target field.
2. Select a conservative profile, or review the generated command before running it.
3. Start the scan and inspect the Output view.
4. Use Ports/Hosts and Host Details to relate hosts, ports, services, and guesses.
5. Use Topology only as a visualization aid; it does not replace network documentation.
6. Review Scan Details and record the exact command, date, scope, and interpretation.

Zenmap's command display connects graphical choices to the underlying Nmap syntax. Learning that command is useful for repeatability, scripts, change comparisons, and troubleshooting.

Advanced visibility and control

sudo nmap --packet-trace -p 80 192.168.56.10
nmap --reason -p 22,80,443 192.168.56.10
nmap -T2 -p 1-1024 192.168.56.10
nmap --scan-delay 500ms -p 1-100 192.168.56.10

Timing templates trade speed for reliability and reduced impact. Slower settings are appropriate for fragile systems, high-latency links, rate-limited environments, or assessments with low-impact requirements. Verbosity and debugging are diagnostic aids, not substitutes for authorization.

UDP scanning

UDP has no handshake and many services do not reply to an empty or unexpected datagram. Firewalls may silently drop probes, and ICMP errors may be rate-limited. Consequently, UDP scanning is often slower and less certain than TCP scanning.

sudo nmap -sU -p 53,67,123 192.168.56.10

Keep the port list and target scope small while learning. A service response is strong evidence of an open UDP port. An ICMP port-unreachable response commonly indicates closed. No response often produces open|filtered, meaning Nmap cannot distinguish an open service from filtering.

Port states and interpretation

A state describes observed reachability and response behavior, not a complete security verdict. “Host down” means discovery did not obtain expected evidence; it does not prove the system is powered off. A host whose status cannot be confirmed may be blocked, misrouted, rate-limited, or incorrectly addressed.

Before reporting a finding, confirm scope, repeat a limited scan, check the local service listener, verify TCP versus UDP, and review host and network firewall rules. Record uncertainty instead of converting an ambiguous state into a definite claim.

Saving, comparing, and reporting results

nmap -oN lab-scan.txt -oX lab-scan.xml -p 22,80,443 192.168.56.10
nmap -oA lab-scan -p 22,80,443 192.168.56.10

Use consistent names containing a target identifier, date, and purpose where organizational policy permits. Record the exact command, target scope, scanner identity, time zone, timing settings, and interpretation. Scan artifacts can reveal addresses, ports, software versions, and topology, so store them with access control and an appropriate retention period.

Practical lab workflow

1. Document the isolated subnet, target addresses, enabled test services, and authorization.
2. Verify Nmap locally with nmap --version.
3. Discover lab hosts using nmap -sn 192.168.56.0/24.
4. Select one known target and scan a narrow TCP set such as 22,80,443.
5. Compare open, closed, and filtered results with the target's service and firewall configuration.
6. Run -sV on the selected ports and compare probable versions with the known configuration.
7. Attempt -O on the authorized target and label the result as an estimate.
8. Change a documented firewall rule, compare ordinary discovery with -Pn, and explain the difference.
9. Test a small UDP set, such as DNS, DHCP, or NTP ports, and investigate an open|filtered result.
10. Use --reason, packet tracing, or slower timing only when they answer a specific troubleshooting question.
11. Save normal and XML output, then write a short report containing scope, command, observations, uncertainty, and validation evidence.

Troubleshooting checklist

Nmap is not recognized

Confirm that Nmap is installed, open a new terminal, and check the executable's directory in PATH. On Windows, verify the installation through the operating system's application management tools.

A known host appears down

Check the VM power state, IP address, adapter mode, subnet, route, and firewall. For a confirmed in-scope host that blocks discovery, compare the result with nmap -Pn and document that discovery was filtered.

Expected ports are closed or filtered

Verify that the service is running and listening on the expected interface, not only on localhost. Confirm the address, port, protocol, NAT or forwarding design, and firewall rules. Use --reason and a focused packet trace in the lab.

Detection is inaccurate

Insufficient response data, NAT, proxies, load balancers, virtualization, filtering, and hidden banners can reduce confidence. Treat service and OS results as estimates and corroborate them with authorized system records.

UDP is slow or ambiguous

Reduce the port list, use conservative timing, allow for ICMP rate limiting, and validate the service and firewall configuration. Do not treat open|filtered as proof that a service is exposed.

Privileges are required

Raw-packet methods and OS detection commonly require elevated privileges. Use them only on your own system or an approved assessment workstation. If appropriate, use supported unprivileged scan methods and follow endpoint-security policy.

Knowledge review

1. Why is host discovery different from port scanning?
2. What does 192.168.56.0/24 describe, and why should the learner verify that the subnet is isolated?
3. A TCP port returns RST. Which state is usually reported, and what does that state prove?
4. Why can UDP produce open|filtered when TCP produces a clearer result?
5. When is -Pn appropriate, and what risk does it introduce if the target address is wrong?
6. Why should an OS-detection result be described as an estimate?
7. Which output format is best suited to structured automation, and which is easiest for human reading?
8. What information should accompany a scan so another administrator can repeat it?
9. A service is expected on TCP 443 but appears filtered. List two validation steps before reporting an exposure problem.
10. What authorization and operational controls should be agreed before scanning?

Further study

Continue with Nmap course activities and the Nmap Online Course. Related study includes Linux fundamentals, networking fundamentals, and security log analysis.