Nmap Explained: Complete Guide to Network Discovery, Port Scanning, Service Detection, NSE and Defensive Security
What Is Nmap?
Nmap, short for Network Mapper, is a free and open-source utility for network discovery, administration and security auditing.
The official Nmap project describes it as a network exploration and security auditing tool capable of discovering hosts, identifying open ports, detecting services and versions, and performing a range of additional network-analysis tasks. (Nmap Official Guide)
At its simplest:
nmap 192.168.1.10
can investigate a target and report discovered ports.
But Nmap is considerably more than a simple port scanner.
Its capabilities include:
Host Discovery
↓
Port Scanning
↓
Service Detection
↓
Version Detection
↓
OS Detection
↓
Scripted Enumeration
↓
Output / Reporting
The official Nmap reference groups its capabilities into target specification, host discovery, port scanning, service/version detection, OS detection, the Nmap Scripting Engine, timing/performance, output and related functions. (Nmap Reference Guide)
Nmap is therefore useful to:
- Network administrators
- System administrators
- Security engineers
- DevOps teams
- Penetration testers
- SOC analysts
- Infrastructure engineers
- Security auditors
It is also an excellent learning tool because its output reveals how systems appear from a network perspective.
For networking fundamentals, continue with Computer Networking Explained and TCP/IP Explained.
What Nmap Actually Does
A common misconception is:
Nmap simply checks whether a port is open.
That is only one part of its functionality.
A more accurate model is:
Target
|
v
Host discovery
|
v
Port scanning
|
v
Service detection
|
v
Version detection
|
v
OS detection
|
v
NSE scripts
|
v
Analysis / reporting
Different Nmap options enable different portions of this workflow.
The official guide explains that Nmap’s scanning process consists of multiple phases, and that advanced users can combine discovery, scanning, detection and scripting according to the task. (Nmap Network Scanning)
This is important because the correct Nmap command depends on the question being asked.
Nmap Architecture and Scan Workflow
A useful abstraction is:
NMAP
|
+-----------+-----------+
| | |
v v v
Discovery Scanning Scripts
| | |
+-----------+-----------+
|
v
Responses
|
v
Analysis
|
v
Report
Nmap sends probes and interprets responses.
This means its results are observations from a particular:
Source
+
Time
+
Network path
+
Scan technique
+
Target behavior
Therefore:
An Nmap result is a view of the target from the scanner’s location.
The official documentation explicitly notes that port states describe how Nmap sees a port, rather than being absolute properties of the port itself. (Port Scanning Basics)
Host Discovery
Before scanning ports across a network, you may first want to determine which hosts are alive.
For example:
nmap -sn 192.168.1.0/24
This performs host discovery without a normal port scan.
A conceptual result is:
192.168.1.1 Up
192.168.1.10 Up
192.168.1.25 Up
192.168.1.50 Down / not detected
The official Nmap guide calls this host discovery or ping scanning and describes it as the phase used to determine which hosts are available on a network. (Host Discovery)
Why Host Discovery Matters
Suppose you need to inventory:
192.168.1.0/24
There may be 254 possible IPv4 addresses.
Scanning every possible port against every address can be unnecessary.
Instead:
Network
↓
Host Discovery
↓
Active Hosts
↓
Port Scan
This can reduce scanning time.
However, a host that does not respond to a particular discovery probe is not necessarily offline.
Firewalls and host policies may block discovery probes.
Therefore:
No discovery response
≠
Definitely offline
This is one of the most important concepts when interpreting Nmap.
-sn: Ping Scan
Example:
nmap -sn 192.168.1.0/24
The -sn option disables port scanning and performs host discovery.
On a local Ethernet segment, Nmap can use appropriate Layer-2 discovery mechanisms in addition to IP-based probes where available.
The precise probes used depend on network conditions and privileges.
Use this when the question is:
Which hosts appear to be reachable?
not:
Which ports are open?
Scan Your Own Systems
Nmap can generate active network traffic.
Therefore scanning should be limited to:
Hosts you own
Networks you administer
Lab environments
Systems for which you have explicit authorization
A safe learning target is:
nmap 127.0.0.1
or a deliberately created local virtual machine.
Nmap’s own official guide includes a section discussing the legal issues associated with port scanning. (Nmap Network Scanning)
Port Scanning
Port scanning asks:
What network services are exposed by this host?
A basic scan:
nmap 192.168.1.10
The Nmap documentation states that this basic form scans the most commonly used 1,000 TCP ports by default. (Port Scanning Basics)
Example output:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
This gives three important pieces of information:
Port
State
Service
What Is a Network Port?
A port is a transport-layer abstraction used to distinguish communication endpoints associated with applications.
For TCP:
IP address
+
TCP port
identifies a transport endpoint.
For example:
192.168.1.10:443
typically represents HTTPS.
For UDP:
192.168.1.10:53
may represent a DNS service.
The Nmap documentation explains ports as software abstractions that distinguish communication channels and notes that TCP and UDP use ports for their transport endpoints. (Port Scanning Overview)
Understanding Nmap Port States
One of Nmap’s strengths is that it does not reduce everything to:
Open
Closed
Nmap recognizes six states:
open
closed
filtered
unfiltered
open|filtered
closed|filtered
The official Nmap guide defines these states and emphasizes that they describe what Nmap can infer from the responses it receives. (Port Scanning Basics)
This distinction is essential.
open
An open port means Nmap has evidence that an application is accepting communication on that port.
For TCP:
TCP connection behavior
↓
Evidence of listening service
For example:
443/tcp
open
https
means Nmap detected evidence consistent with an HTTPS service listening on TCP/443.
closed
A closed port means Nmap received a response showing that the port is reachable but no application appears to be listening.
Conceptually:
Scanner
|
| Probe
v
Host
|
| "Port unavailable"
v
Scanner
A closed port is therefore different from a filtered port.
filtered
A filtered port means a filtering mechanism prevented Nmap from determining whether the port is open.
Potential causes include:
Firewall
ACL
Security Group
Packet filtering
Network policy
The Nmap guide explicitly states that a filtered port indicates that filtering is preventing Nmap from determining whether the port is open. (Port Scanning Basics)
unfiltered
unfiltered means Nmap can reach the port but cannot determine whether it is open or closed with the particular scan being used.
This state is most associated with certain scan techniques, especially ACK scanning.
Therefore:
unfiltered
≠
open
It means:
The probe reached the destination, but this scan cannot establish the port’s open/closed status.
open|filtered
This combined state means Nmap cannot determine whether the port is open or filtered.
This can occur when the scan type expects a response from a closed port but receives no useful response.
The official Nmap documentation specifically describes UDP, FIN, NULL and Xmas scans as examples where this ambiguity can occur. (Port Scanning Overview)
closed|filtered
Nmap uses closed|filtered in specific situations where the scan cannot distinguish those two states.
This illustrates a broader lesson:
Network scanning is inference.
Nmap is not looking inside the target’s kernel.
It is observing network behavior and drawing conclusions.
TCP SYN Scan
One of Nmap’s most important scan types is:
nmap -sS 192.168.1.10
This is the TCP SYN scan.
Nmap’s official documentation identifies SYN scan as a major TCP scanning technique. (Port Scanning Techniques)
The basic conceptual sequence for an open TCP port is:
Scanner Target
| ---- SYN ----------> |
| <--- SYN/ACK --------|
Nmap can infer that the port is open from this response.
A normal full connection may not need to be completed for the purpose of determining the port state.
The exact packet behavior depends on the target OS and network conditions.
TCP Connect Scan
Use:
nmap -sT 192.168.1.10
The TCP Connect scan relies on the operating system’s normal connection mechanism rather than the raw-packet approach used by SYN scanning.
It can be useful when the scanner does not have the privileges required for raw packet scanning.
The official Nmap documentation identifies -sT as the TCP connect scan and explains when it is used. (Port Scanning Techniques)
SYN Scan vs Connect Scan
| Feature | -sS |
-sT |
|---|---|---|
| Technique | TCP SYN | TCP connect |
| Raw packet use | Commonly required | Not required |
| Typical privilege requirement | Elevated on Unix | Lower |
| TCP handshake behavior | Uses SYN probing | Uses OS connection |
| Common use | Standard privileged scan | Unprivileged TCP scanning |
The official Nmap documentation notes that SYN scanning and many other scan techniques require privileges for raw packet operations on Unix systems, while connect scanning is available without those privileges. (Port Scanning Techniques)
UDP Scanning
UDP is more complicated than TCP.
Use:
nmap -sU 192.168.1.10
A UDP scan may produce:
53/udp open
161/udp open|filtered
The lack of a response from UDP services can make open and filtered states difficult to distinguish.
The official Nmap guide explains that UDP scanning presents unique challenges because open UDP ports often do not respond to generic probes. (Port Scanning Techniques)
Why UDP Scanning Takes Longer
TCP provides connection-oriented behavior that can make port-state inference relatively straightforward.
UDP does not.
For example:
TCP:
SYN → SYN/ACK
can provide strong evidence.
UDP may simply produce:
Probe
|
| no response
which could mean:
Open service
or
Firewall
or
Packet loss
or
Service-specific behavior
That ambiguity can make UDP scans slower and harder to interpret.
Selecting Ports
You do not always need the default port set.
Scan one port:
nmap -p 443 192.168.1.10
Scan several:
nmap -p 22,80,443 192.168.1.10
Scan a range:
nmap -p 1-1024 192.168.1.10
Scan all TCP ports:
nmap -p- 192.168.1.10
The exact scan size should match the question being asked.
For routine inventory, scanning every possible port may be unnecessary.
For a controlled audit, a full-port assessment may be appropriate.
Service and Version Detection
Finding:
443/tcp open
is useful.
But finding:
443/tcp open
nginx 1.x
can be significantly more informative.
Use:
nmap -sV 192.168.1.10
The official Nmap documentation explains that version detection probes open or potentially open ports to determine what service and application version is actually running rather than relying only on the port number. (Version Scanning Technique)
Why Port Number Alone Is Not Enough
Imagine:
8080/tcp
open
You cannot safely conclude:
HTTP
merely from the number.
Another application might be listening there.
Service detection asks the target service itself:
"What protocol are you?"
through Nmap’s version-probing mechanisms.
Thus:
Port number
+
Probe response
=
Service identification
Nmap Version Detection
A version scan:
nmap -sV 192.168.1.10
may produce:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH ...
80/tcp open http nginx ...
The exact results depend on:
Service
Version
Network conditions
Probe support
Target behavior
Nmap maintains service-probe definitions used by its version-detection engine. The official guide explains the underlying version-detection process. (Version Scanning Technique)
Operating System Detection
Nmap can attempt to infer the target operating system.
Use:
nmap -O 192.168.1.10
Nmap’s OS detection works by analyzing characteristics of network responses and comparing them with its OS fingerprint database. The official reference provides a dedicated OS-detection mechanism and options. (Nmap Reference Guide)
A result might resemble:
OS details:
Linux
or provide a family and confidence estimate.
OS Detection Is an Inference
This distinction is critical.
Nmap does not receive a field saying:
Operating System = Linux
Instead, it analyzes network behavior.
Therefore:
OS detection
=
Fingerprint inference
and accuracy can be affected by:
Firewalls
Proxies
NAT
Virtualization
Unusual TCP stacks
Network paths
Target changes
Do not treat OS detection as absolute truth.
-A: Aggressive Scan
Nmap provides:
nmap -A 192.168.1.10
This enables a collection of advanced detection features.
Depending on Nmap’s capabilities and the target, an aggressive scan can combine:
OS detection
Version detection
Script scanning
Traceroute
The exact behavior is documented in Nmap’s current reference guide. (Nmap Reference Guide)
Because this is a more intensive scan, it should be used deliberately rather than automatically against every host.
Nmap Scripting Engine — NSE
The Nmap Scripting Engine (NSE) extends Nmap beyond basic scanning.
NSE scripts can perform tasks such as:
Service enumeration
Protocol discovery
Configuration checks
Information gathering
Security checks
Automation
The official Nmap guide dedicates an entire section to NSE and its script categories. (Nmap Reference Guide)
NSE Script Categories
Nmap scripts are organized into categories.
Common categories include:
auth
broadcast
brute
default
discovery
dos
exploit
external
fuzzer
intrusive
malware
safe
version
vuln
Not every script is appropriate for every environment.
Some scripts can generate significant traffic or interact more aggressively with the target.
Therefore script selection should be deliberate.
Safe NSE Use
For a controlled environment, inspect available script documentation before executing it.
You can query a script:
nmap --script-help <script-name>
Then run an appropriate script against a system you are authorized to test.
For example, general discovery can be performed using selected discovery-oriented scripts.
The Nmap official guide documents script categories, script discovery and script execution in detail. (Nmap NSE Documentation)
--script-help
Before running a script:
nmap --script-help http-title
This can provide information about:
Purpose
Category
Arguments
Requirements
This is a good operational habit.
Do not treat:
--script default
or:
--script vuln
as a harmless universal command.
Scripts have different behaviors.
Nmap Default Scripts
The -sC option enables the default NSE script set:
nmap -sC 192.168.1.10
This is commonly combined with service detection:
nmap -sC -sV 192.168.1.10
This can provide substantially more information than a basic port scan.
Use it only against systems you are authorized to assess.
Nmap Vulnerability Scripts
NSE includes scripts categorized for vulnerability-related checks.
A common syntax is:
nmap --script vuln 192.168.1.10
This should be treated as an active security assessment, not simply passive monitoring.
A vulnerability-oriented scan may generate traffic that:
Triggers IDS/IPS
Creates logs
Exercises application functionality
Consumes resources
Therefore it requires stronger authorization and testing discipline.
The Nmap project documents dedicated NSE script categories, including vuln, and provides warnings and legal guidance around scanning. (Nmap NSE)
Nmap and IPv4
IPv4 scanning is the most familiar use case.
Example:
nmap 192.168.1.10
Network range:
nmap 192.168.1.0/24
Multiple targets:
nmap 192.168.1.10 192.168.1.20
Nmap’s target specification system supports individual IP addresses, ranges, CIDR blocks and hostnames.
Nmap and IPv6
Nmap also supports IPv6 scanning through:
nmap -6 2001:db8::10
The Nmap reference explicitly documents IPv6 scanning using -6. (Nmap Reference Guide)
This matters because a host can expose services over IPv6 even when the IPv4 configuration appears secure.
A modern security inventory should therefore consider:
IPv4
+
IPv6
where IPv6 is deployed.
Target Specification
Nmap supports several target forms.
One IP
nmap 192.168.1.10
Multiple IPs
nmap 192.168.1.10 192.168.1.20
CIDR
nmap 192.168.1.0/24
Hostname
nmap server.example.com
Range
nmap 192.168.1.1-50
The target specification system is documented in the official reference guide. (Nmap Reference Guide)
Excluding Targets
For controlled environments, you may want to exclude systems.
Conceptually:
nmap 192.168.1.0/24 --exclude 192.168.1.1
This is especially useful when:
Network range
+
Sensitive device
+
Authorized scan
coexist.
The exact target-specification and exclusion options are documented in Nmap’s reference guide.
Timing and Performance
Nmap must balance:
Speed
Accuracy
Network load
Target response
The official Nmap documentation has a dedicated section on timing and performance because large scans can be affected by latency, packet loss, congestion and target behavior. (Nmap Network Scanning)
Timing Templates
Nmap provides timing templates:
-T0
-T1
-T2
-T3
-T4
-T5
The templates represent increasingly aggressive timing behavior.
For example:
nmap -T4 192.168.1.10
is commonly used in controlled environments.
However, faster does not necessarily mean better.
Aggressive timing can:
Increase packet volume
Trigger security controls
Produce more timeouts
Reduce reliability on unstable networks
The official guide discusses timing optimization and adaptive scanning behavior. (Scan Methods)
Large-Scale Scanning
Consider:
10 hosts
versus:
10,000 hosts
The same scan strategy may not be appropriate.
Large-scale scanning requires attention to:
Parallelism
Timeouts
Retransmissions
Network capacity
Poller capacity
Target behavior
Output size
Nmap’s internal algorithms include host and port parallelization, round-trip-time estimation, congestion control and adaptive retransmission. (Port Scanning Techniques)
Nmap Output
A scan result should be treated as operational data.
For example:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
But professional workflows often need more than terminal output.
Nmap supports multiple output formats.
Common options include:
-oN
-oX
-oG
-oA
The Nmap reference documents these output mechanisms and the generation of normal, XML, grepable and combined output. (Nmap Reference Guide)
Normal Output
Save a human-readable report:
nmap -oN scan.txt 192.168.1.10
This is useful for:
Documentation
Manual review
Evidence
Change comparison
XML Output
For automation:
nmap -oX scan.xml 192.168.1.10
XML is useful for:
Parsers
Security platforms
Asset-management systems
Custom scripts
Data pipelines
A powerful architecture is:
Nmap
|
XML
|
Parser
|
Database
|
Dashboard
Combined Output
Use:
nmap -oA audit-2026 192.168.1.10
This creates output in several useful formats.
For repeated assessments, consistent filenames are extremely useful.
Example:
audit-2026.nmap
audit-2026.xml
audit-2026.gnmap
Ndiff
The Nmap ecosystem includes Ndiff, a utility designed to compare Nmap XML output from different scans.
This allows workflows such as:
Monday
↓
Scan A
Friday
↓
Scan B
A + B
↓
Ndiff
↓
Changed services
This is highly useful for security and infrastructure change detection.
Nmap’s official guide includes Ndiff documentation alongside the Nmap reference. (Nmap Documentation)
Nmap for Network Inventory
A network inventory process can look like:
CIDR Range
↓
Host Discovery
↓
Active Hosts
↓
Port Scan
↓
Service Detection
↓
Version Detection
↓
Export
↓
Asset Inventory
Example:
nmap -sn 192.168.1.0/24
then, for selected hosts:
nmap -sV 192.168.1.10
This provides a network-centered inventory.
It does not replace an authoritative CMDB or cloud inventory system, but it can reveal what is actually exposed on the network.
Nmap for Attack Surface Management
An organization may know it owns:
100 servers
but discover:
110 reachable hosts
or:
An expected server
+
Unexpected port
This is where Nmap can support attack-surface validation.
For example:
Expected:
443/tcp
Observed:
22/tcp
80/tcp
443/tcp
8080/tcp
The additional port may require investigation.
An important distinction:
Discovery is not proof of vulnerability.
An open port simply means a service appears reachable.
Nmap and Firewalls
Consider:
Internet
|
Firewall
|
Server
The same port may produce different Nmap states from different locations.
From inside:
443/tcp open
From outside:
443/tcp open
and perhaps:
22/tcp filtered
This is expected if the firewall restricts SSH.
The Nmap project explicitly notes that port state is dependent on the scanner’s vantage point and the filtering path. (Port Scanning Basics)
Nmap and Security Groups
Cloud security groups can produce results similar to traditional firewall filtering.
For example:
Application:
TCP/443 allowed
SSH:
TCP/22 blocked
Nmap from outside the permitted network may show:
443/tcp open
22/tcp filtered
This is why Nmap is useful for validating the effective exposure of cloud-hosted systems.
For the broader cloud networking architecture, see Cloud Networking Explained.
Nmap and Firewalls Explained
Firewalls may:
Allow
Deny
Drop
Reject
Rate-limit
Different behaviors produce different observable results.
This is why Nmap output should be interpreted together with firewall configuration.
See Firewalls Explained for the networking-security foundation behind these behaviors.
Nmap and Network Segmentation
Consider:
User VLAN
|
X
Database VLAN
From the user network:
Database port
filtered
From the application network:
Database port
open
That is not necessarily contradictory.
It can demonstrate that segmentation is working as intended.
Nmap can therefore be useful for validating network policy from different authorized vantage points.
Nmap and NAC
Network Access Control determines which devices can gain network access.
Nmap can complement NAC by validating what becomes reachable after access is granted.
The relationship is:
NAC
↓
Who can connect?
Nmap
↓
What can they reach?
This complements the concepts in Network Access Control (NAC).
Nmap and SIEM
Nmap can produce valuable security inventory data, but it is not itself a SIEM.
A workflow can look like:
Scheduled Nmap Scan
↓
XML Result
↓
Parser
↓
Asset Database
↓
Change Detection
↓
Security Alert
For example:
Previously:
443/tcp open
Now:
443/tcp open
8080/tcp open
A change-management system can flag this for investigation.
The broader security-event architecture is covered in SIEM Explained.
Nmap and Intrusion Detection
Large or aggressive scans may be visible to IDS/IPS systems.
A conceptual workflow:
Nmap Scanner
|
v
Network
|
+--> IDS
|
+--> Firewall
|
v
Target
Defenders can therefore use Nmap in a controlled lab to validate whether their monitoring systems recognize scanning activity.
This connects naturally to Intrusion Detection and Prevention Systems.
Nmap for Defensive Security
A blue-team workflow might be:
Inventory
↓
Authorized Scan
↓
Unexpected Ports
↓
Service Identification
↓
Configuration Review
↓
Firewall Validation
↓
Remediation
↓
Rescan
For example:
Scan 1:
22 open
80 open
443 open
8080 open
Review:
8080 should not be public
Remediation:
Firewall rule changed
Scan 2:
22 open
80 open
443 open
8080 filtered
This creates measurable evidence that a security change had the intended effect.
Nmap and Vulnerability Management
Nmap is not a full vulnerability-management platform.
However, it can provide important discovery information:
Host
Port
Service
Version
Script findings
That information can feed vulnerability-management workflows.
Example:
Nmap
↓
OpenSSH version detected
↓
Asset inventory
↓
Version comparison
↓
Vulnerability management system
↓
Patch decision
A version match alone should not be treated as definitive proof of exploitability.
Nmap and Linux
On Linux, Nmap integrates naturally with command-line workflows.
Example:
nmap -sV 127.0.0.1
Then combine with:
ss -lntup
This is powerful because:
Nmap:
What does the network see?
ss:
What is the host actually listening on?
If both disagree, investigate why.
Nmap vs ss
Suppose:
ss -lntup
shows:
0.0.0.0:8080
but:
nmap -p 8080 server
shows:
8080/tcp filtered
The two results are not contradictory.
They answer different questions.
ss:
The process is listening locally.
Nmap:
The port is not reachable from the scanner.
Possible reason:
Firewall
Security group
ACL
Routing
Network segmentation
This is an excellent example of layered troubleshooting.
Nmap vs Wireshark
These tools are complementary.
Nmap asks:
What hosts and services appear to be reachable?
Wireshark asks:
What packets and protocols are actually being exchanged?
Conceptually:
Nmap
↓
Discovery / Exposure
Wireshark
↓
Packet / Protocol Evidence
That makes Nmap + Wireshark a powerful combination in authorized network troubleshooting.
Nmap and Linux Network Tools
The broader Linux network toolkit from the CorgiNetwork ecosystem includes:
ip
ss
ping
traceroute
mtr
dig
curl
tcpdump
nmcli
ethtool
A strong workflow can become:
Nmap
↓
Find exposed service
ss
↓
Identify local listener
curl
↓
Test application
tcpdump / Wireshark
↓
Inspect packet exchange
This is a much more complete diagnostic process than relying on one utility.
Practical End-to-End Nmap Lab
Now build a safe local lab.
The objective is to discover a service on your own machine.
Use:
127.0.0.1
or a deliberately configured local virtual machine.
Step 1: Check Listening Services
On Linux:
ss -lntup
Look for something such as:
LISTEN
0.0.0.0:80
or:
127.0.0.1:8080
Step 2: Run a Basic Nmap Scan
nmap 127.0.0.1
You may see:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
The result shows what Nmap can observe through the network stack.
Step 3: Scan One Specific Port
nmap -p 80 127.0.0.1
This narrows the question:
Is TCP/80 reachable?
Step 4: Identify the Service
nmap -sV -p 80 127.0.0.1
Possible result:
80/tcp
open
http
nginx
The exact service/version depends on your local environment.
Step 5: Compare with ss
Run:
ss -lntp | grep ':80'
Now compare:
Nmap:
Externally observable state
ss:
Local socket state
If the server is listening only on:
127.0.0.1:80
remote hosts may not be able to reach it.
Step 6: Test with curl
Run:
curl -I http://127.0.0.1
Now you have three layers:
Nmap
↓
Port exposure
ss
↓
Socket
curl
↓
Application
Step 7: Capture the Traffic
Start:
sudo tcpdump -ni lo 'tcp port 80'
Then:
nmap -p 80 127.0.0.1
You can now observe the packets involved in the scan.
This is where the CorgiNetwork workflow connects:
Nmap
↓
What is happening?
tcpdump
↓
How is it happening?
Open the resulting capture in Wireshark for deeper analysis.
Step 8: Compare Nmap and Wireshark
Run:
nmap -sS -p 80 127.0.0.1
Then inspect the capture.
You should be able to connect the scan behavior with TCP packets such as:
SYN
SYN/ACK
depending on the target and operating environment.
This is an excellent exercise for understanding TCP.
See TCP/IP Explained for the underlying protocol model.
Step 9: Add Service Detection
Run:
nmap -sV -sC -p 80 127.0.0.1
You are now combining:
Port scanning
+
Version detection
+
Default NSE scripts
This produces substantially more information than a basic scan.
Step 10: Save the Result
nmap -sV -oA local-web-audit 127.0.0.1
You now have a repeatable baseline.
Save the results under a controlled directory.
Step 11: Change the Configuration
For a lab experiment, start or stop a local service.
Then rerun:
nmap -sV -oA local-web-audit-2 127.0.0.1
Compare the results.
You have now demonstrated:
Configuration change
↓
Network exposure change
↓
Nmap detects difference
This is one of the most valuable ways to learn network security.
Practical Lab: Web Server Exposure
A simple test architecture:
Local Host
|
+-----+-----+
| |
SSH Nginx
:22 :80
| |
+-----+-----+
|
Nmap
Run:
nmap -p 22,80,443 127.0.0.1
Then:
nmap -sV -p 22,80,443 127.0.0.1
Now compare the result to:
ss -lntup
This teaches the important difference between:
Listening locally
and:
Reachable through the network
Practical Lab: Firewall Validation
Suppose your Linux machine runs:
HTTP :80
SSH :22
but the firewall should allow:
80
and block:
22
From an authorized testing host:
nmap -p 22,80 TARGET
Expected conceptual result:
22/tcp filtered
80/tcp open
This is a measurable validation of policy.
Then compare with the firewall configuration and server socket state.
Practical Lab: Network Inventory
For a small authorized lab network:
nmap -sn 192.168.56.0/24
Identify active hosts.
Then select appropriate lab hosts and run:
nmap -sV 192.168.56.10
The workflow becomes:
Subnet
↓
Discovery
↓
Host list
↓
Service scan
↓
Inventory
Do not automatically run intensive scans against devices you do not administer.
Troubleshooting Nmap Results
Nmap says:
Host seems down
but you know the machine is running.
Possible causes:
ICMP filtering
Discovery filtering
Routing
Firewall
Wrong address
You can use a controlled scan option such as:
nmap -Pn 192.168.1.10
-Pn tells Nmap to skip host discovery and treat the target as online for the subsequent scan.
This can be useful when discovery packets are blocked.
-Pn Must Be Used Carefully
Skipping host discovery means Nmap may attempt scanning against hosts that are actually unavailable.
For large networks this can:
Increase scan time
Increase traffic
Create unnecessary probes
Therefore:
Known reachable host
→ -Pn can be useful
Large unknown network
→ host discovery is usually more efficient
Nmap Shows filtered
Possible reasons:
Firewall
Security Group
ACL
Packet filtering
IDS/IPS behavior
Network routing
Compare:
Nmap
+
Firewall configuration
+
tcpdump
A packet capture can help determine whether probes:
Leave scanner
Reach firewall
Reach destination
Receive response
Nmap Shows closed
A closed result usually means Nmap received a response indicating the port is reachable but no service appears to be listening.
On Linux, verify:
ss -lntup
If the application has stopped:
Nmap:
closed
ss:
no listener
The results agree.
Nmap Shows open
Verify locally:
ss -lntup
Then identify the process.
For example:
443/tcp
might correspond to:
nginx
apache
application server
reverse proxy
Nmap tells you the network-facing observation.
Local tools tell you which process created it.
Nmap Shows an Unexpected Service
Suppose:
8080/tcp open
and this service was not expected.
Investigate:
ss -lntp | grep ':8080'
Then:
ps aux
or inspect the relevant service-management system.
The workflow is:
Nmap
↓
Unexpected exposure
↓
ss
↓
Socket owner
↓
Process
↓
Configuration
This is a strong defensive workflow.
Nmap Results Depend on the Scanner Location
Consider:
Client Network A
|
v
Firewall
|
v
Server
From Network A:
443 open
From Network B:
443 filtered
This can happen because the network policies differ.
Therefore a security assessment should document:
Scanner IP
Scanner network
Network path
Date/time
Scan options
Target
Without this context, comparing scan results can be misleading.
Nmap and NAT
NAT can also affect interpretation.
The address visible to the scanner may be:
203.0.113.10
while the internal server is:
10.0.0.10
A scan from outside measures the public-facing NAT behavior, not necessarily the server’s direct internal exposure.
Therefore:
External scan
≠
Internal scan
They answer different security questions.
Nmap and Containers
Containers may expose:
Host port
↓
NAT / Port publishing
↓
Container port
For example:
Host:
0.0.0.0:8080
Container:
80/tcp
Nmap from outside sees:
8080/tcp open
while container inspection may show:
80/tcp
This illustrates why network exposure must be analyzed at the host and container layers.
Nmap and Kubernetes
Kubernetes can expose services through:
ClusterIP
NodePort
LoadBalancer
Ingress
An Nmap scan from outside might see:
443/tcp open
but that does not reveal the entire internal service topology.
A full investigation requires:
Nmap
+
Kubernetes service configuration
+
Ingress
+
Network policies
+
Cloud load balancer
Nmap is the external-observation component.
Nmap and Cloud Infrastructure
Cloud applications can have multiple security layers:
Internet
|
Cloud Load Balancer
|
Firewall / WAF
|
Security Group
|
VM
|
Application
An external Nmap scan tells you what is observable from the internet.
An internal scan can answer a different question:
What can workloads inside the network reach?
This is especially useful when validating segmentation.
For the broader cloud architecture, see Cloud Networking Explained.
Nmap and VPNs
A VPN can change the scanner’s network position.
For example:
Laptop
|
VPN
|
Corporate Network
|
Internal Server
Running Nmap through the VPN can provide a different view than running the same scan from the public internet.
This is another example of:
Vantage point matters.
For VPN architecture, see VPNs Explained.
Nmap and Network Security Architecture
Nmap is particularly useful when validating the interaction between:
Firewall
+
NAC
+
Segmentation
+
Services
+
Monitoring
For example:
Firewall policy
↓
Application port allowed
↓
Nmap verifies exposure
↓
SIEM records events
↓
IDS/IPS analyzes traffic
This creates a practical validation loop.
Nmap and Incident Response
During incident response, Nmap may help identify:
Unexpected hosts
Unexpected ports
Unexpected services
Network exposure changes
However, active scanning during an incident must be coordinated carefully because scanning can alter the environment or interact with compromised systems.
In many cases:
Passive evidence first
is preferable before active probing.
That distinction matters in formal incident-response workflows.
Nmap for Change Management
One practical use is scheduled baseline scanning.
For example:
Day 1
Scan
↓
Baseline
Day 7
Scan
↓
Compare
Day 14
Scan
↓
Compare
A change such as:
443 open
becoming:
443 open
8443 open
can trigger an investigation.
This is especially useful when configuration changes happen across many systems.
Nmap and Asset Drift
Security teams often face:
Known inventory
≠
Actual network
Nmap can help expose discrepancies:
CMDB:
100 hosts
Nmap:
104 responsive hosts
The four additional systems should be investigated.
Possible explanations include:
Temporary systems
New deployment
IoT device
Shadow IT
Scanner false positive
NAT / infrastructure
Nmap provides the observation; asset management provides the organizational context.
Nmap Performance Best Practices
For authorized scanning:
Start small
↓
Validate results
↓
Increase scope
↓
Tune timing
↓
Export results
↓
Automate comparison
Avoid starting with:
All hosts
+
All ports
+
All scripts
A controlled progression is more reliable and easier to troubleshoot.
Nmap Security Best Practices
Know the target
Maintain an explicit scope.
Start with discovery
Do not unnecessarily scan every port of every address.
Use least intrusive scans first
Only increase intensity when necessary.
Document scan parameters
Record:
Target
Date
Source network
Options
Nmap version
Review NSE scripts
Understand what a script does before executing it.
Protect results
Scan results can reveal sensitive infrastructure details.
Do not expose reports publicly
XML and text reports may contain:
Host addresses
Service versions
Security findings
Network structure
These should be handled as sensitive operational information.
Nmap Output Security
A report such as:
server.example.com
22/tcp open ssh OpenSSH ...
443/tcp open https nginx ...
reveals significant information.
Do not publish an internal scan without considering:
Asset exposure
Internal addresses
Software versions
Hostname information
Security findings
A scan report can itself become an attack-surface document.
Nmap Cheat Sheet
| Objective | Command |
|---|---|
| Basic scan | nmap TARGET |
| Host discovery | nmap -sn TARGET |
| Skip discovery | nmap -Pn TARGET |
| Specific ports | nmap -p 22,80,443 TARGET |
| Port range | nmap -p 1-1024 TARGET |
| All TCP ports | nmap -p- TARGET |
| SYN scan | nmap -sS TARGET |
| TCP connect | nmap -sT TARGET |
| UDP scan | nmap -sU TARGET |
| Service detection | nmap -sV TARGET |
| OS detection | nmap -O TARGET |
| Default NSE scripts | nmap -sC TARGET |
| Combined detection | nmap -sC -sV TARGET |
| Aggressive scan | nmap -A TARGET |
| IPv6 | nmap -6 TARGET |
| Save normal output | nmap -oN file.txt TARGET |
| Save XML | nmap -oX file.xml TARGET |
| Save multiple formats | nmap -oA basename TARGET |
| Script help | nmap --script-help SCRIPT |
| Faster timing template | nmap -T4 TARGET |
The official Nmap Reference Guide is the authoritative source for the full option set and exact behavior because Nmap contains substantially more functionality than the commands shown here. (Nmap Reference Guide)
Recommended Nmap Workflows
Basic inventory
nmap -sn 192.168.1.0/24
Then:
nmap -sV 192.168.1.10
Web-server assessment
nmap -sV -p 80,443 192.168.1.10
Local Linux audit
nmap -sV 127.0.0.1
Then:
ss -lntup
Controlled application analysis
nmap -sC -sV -p 80,443 192.168.1.10
IPv6 service check
nmap -6 -sV 2001:db8::10
Save a repeatable baseline
nmap -sV -oA baseline-server01 192.168.1.10
Nmap + Linux + Wireshark Workflow
A particularly powerful CorgiNetwork workflow is:
NETWORK PROBLEM
|
v
Nmap
|
What is exposed?
|
v
ss
|
What is listening?
|
v
curl
|
Does the application work?
|
v
tcpdump
|
What packets move?
|
v
Wireshark
|
What does the protocol do?
Each tool answers a different question.
This avoids trying to use one tool for everything.
Nmap vs Wireshark: The Key Difference
The distinction can be summarized as:
Nmap:
Active observation
versus:
Wireshark:
Packet-level observation
Nmap actively sends probes.
Wireshark primarily captures and analyzes packets.
That makes them complementary rather than competing tools.
The official Nmap guide explains Nmap’s role in network discovery, administration and security auditing, while the Wireshark workflow in the accompanying CorgiNetwork article focuses on packet capture and protocol analysis.
Nmap vs Netcat
nc can test one particular connection:
nc -vz 192.168.1.10 443
Nmap can systematically investigate many ports and apply service-detection logic.
Conceptually:
nc
↓
Can I connect here?
Nmap
↓
What is exposed across this target?
The tools can therefore be used together.
Nmap vs ss
Again:
ss:
Local state
Nmap:
Remote observation
This distinction is extremely important in troubleshooting.
Example:
ss:
0.0.0.0:8080 LISTEN
does not necessarily mean:
Internet:
8080 reachable
A firewall may block it.
Nmap can test the external observation point.
Nmap and Network Security Testing
Nmap occupies an important position between:
Network Administration
and:
Security Assessment
The same scan can be useful for:
Inventory
or:
Attack-surface validation
The difference is the purpose, scope and authorization.
The Nmap project itself presents the tool as useful for network discovery, administration and security auditing. (Nmap Official Guide)
Nmap Learning Roadmap
A practical learning sequence is:
Networking Fundamentals
↓
TCP/IP
↓
Ports
↓
Host Discovery
↓
Basic Port Scan
↓
Port States
↓
SYN / Connect Scans
↓
UDP
↓
Service Detection
↓
OS Detection
↓
NSE
↓
Output / XML
↓
Automation
↓
Security Validation
↓
Large-Scale Inventory
The official Nmap book follows a similar progression from introductory scanning through discovery, port-scanning techniques, service detection, OS detection, scripting and performance. (Nmap Book Organization)
Frequently Asked Questions
What is Nmap?
Nmap is a free and open-source network discovery and security-auditing tool used to identify hosts, ports, services and other characteristics of networked systems. (Nmap Official Guide)
Is Nmap a port scanner?
Yes, port scanning is one of its core functions, but Nmap also supports host discovery, service/version detection, OS detection, scripting and reporting. (Nmap Reference Guide)
What does nmap TARGET do?
By default, Nmap performs a basic TCP scan against the target; the official documentation states that the simple command scans the most commonly used 1,000 TCP ports. (Port Scanning Basics)
What does -sS mean?
It requests a TCP SYN scan, one of Nmap’s principal TCP scanning techniques. (Port Scanning Techniques)
What does -sV do?
It enables service and version detection, allowing Nmap to probe open or potentially open ports to identify the actual service rather than relying solely on port-number conventions. (Version Scanning Technique)
What does -O do?
It enables OS detection, which attempts to infer the target operating-system characteristics from network responses.
What does -A do?
It enables a collection of advanced detection functions, including OS detection, version detection, default scripting and traceroute-related functionality. Consult the current reference guide for exact behavior. (Nmap Reference Guide)
What is NSE?
NSE is the Nmap Scripting Engine, which extends Nmap with scripts for discovery, enumeration, security checks and other automation tasks. (Nmap NSE)
What does filtered mean?
It means Nmap believes filtering is preventing it from determining whether the port is open. (Port Scanning Basics)
Does open mean the service is vulnerable?
No. open means Nmap has evidence of an accessible service. Vulnerability requires separate analysis.
Does closed mean the host is offline?
No. A closed port can indicate that the host is reachable but no service is listening on that port.
Can Nmap scan UDP?
Yes. Nmap supports UDP scanning through -sU, although UDP results can be more ambiguous and scans can take longer. (Port Scanning Techniques)
Can Nmap scan IPv6?
Yes. Nmap supports IPv6 with -6. (Nmap Reference Guide)
Can Nmap detect services?
Yes. -sV enables service and version detection. (Version Scanning Technique)
Can Nmap detect operating systems?
Yes, through its OS-detection functionality, although the result is an inference based on network behavior.
Is Nmap the same as Wireshark?
No. Nmap actively probes targets for network discovery and assessment, while Wireshark captures and analyzes packets.
Can Nmap replace a SIEM?
No. Nmap is a scanning and discovery tool, while a SIEM is designed for centralized security-event collection, correlation and analysis.
Can Nmap replace vulnerability scanners?
Not completely. Nmap can provide valuable service/version information and NSE-based checks, but comprehensive vulnerability management involves broader asset, vulnerability, risk and remediation workflows.
Should Nmap be used against public systems without permission?
No. Only scan systems and networks you are authorized to test.
Professional Nmap Assessment Checklist
[ ] Define authorized scope
[ ] Record scanner IP / network
[ ] Record date and time
[ ] Start with host discovery
[ ] Identify required ports
[ ] Use appropriate scan technique
[ ] Add service detection when necessary
[ ] Add OS detection when useful
[ ] Review NSE scripts before execution
[ ] Avoid unnecessarily aggressive scans
[ ] Save output
[ ] Protect scan reports
[ ] Compare against baseline
[ ] Investigate unexpected services
[ ] Validate firewall policy
[ ] Correlate findings with local tools
[ ] Rescan after remediation
Complete Nmap Assessment Architecture
AUTHORIZED SCOPE
|
v
Target Definition
|
v
Host Discovery
|
+-----------+-----------+
| |
v v
Host Up Unknown
|
v
Port Scan
|
+--------------+--------------+
| | |
v v v
Open Closed Filtered
|
v
Service Detection
|
v
Version Detection
|
v
OS Detection
|
v
NSE
|
v
Results / XML
|
+-----+------+
| |
v v
Inventory Security Review
| |
+-----+------+
|
v
Remediation
|
v
Rescan
This is the real value of Nmap:
Discovery
↓
Measurement
↓
Identification
↓
Validation
↓
Change Detection
Conclusion
Nmap is one of the most important tools in the network-engineering and security toolbox because it provides an active view of what a system or network exposes.
It can answer questions such as:
Which hosts appear to be reachable?
Which ports are exposed?
Which services are running?
Which versions appear to be installed?
What operating system characteristics are visible?
Which network changes occurred?
Does the firewall expose what it was supposed to expose?
Its architecture extends far beyond simple port scanning:
Host Discovery
↓
Port Scanning
↓
Service Detection
↓
Version Detection
↓
OS Detection
↓
NSE
↓
Reporting
↓
Automation
The official Nmap documentation identifies network discovery, administration and security auditing as core uses and provides detailed documentation for host discovery, multiple port-scanning techniques, service/version detection, OS detection, NSE, performance optimization and output. (Nmap Official Guide; Nmap Reference Guide)
The most important concept to understand is that Nmap results are observations from a specific network vantage point.
An:
open
port is different from:
closed
which is different from:
filtered
and the exact meaning depends on the scan technique and the network responses observed. (Port Scanning Basics)
For this reason, Nmap becomes significantly more powerful when combined with other tools.
A professional troubleshooting stack can be:
Nmap
↓
Exposure
ss
↓
Local sockets
curl
↓
Application behavior
tcpdump
↓
Packets
Wireshark
↓
Protocol analysis
SIEM
↓
Security correlation
This creates a complete chain from network exposure to packet-level evidence.
For CorgiNetwork, Nmap also fits naturally with the existing articles on Computer Networking Explained, TCP/IP Explained, DNS Explained, Firewalls Explained, VPNs Explained, Network Security Basics, Network Access Control (NAC), SIEM Explained, and Intrusion Detection and Prevention Systems.
The next article in Tools & Software can build directly on this foundation:
OpenSSH Explained: SSH Architecture, Keys, Authentication, Port Forwarding, Hardening and Secure Remote Administration
That article will connect Nmap’s exposure discovery with the actual technology behind one of the most important Linux management services.