BeginnerTools

Nmap Beginner Tutorial: Mastering Network Scanning

Learn Nmap from scratch covering host discovery, port scanning, service detection, NSE scripts, and practical examples.

#Nmap#Network Scanning#Port Scanning#Reconnaissance#Penetration Testing

Why You Need Nmap

You need to map a network and discover every device, open port, and running service — Nmap is how professionals do it. It sends crafted packets to targets and analyzes responses to identify live hosts, open ports, running services, operating systems, and potential vulnerabilities. Its Nmap Scripting Engine (NSE) extends scanning with automated vulnerability checks and service enumeration.

Installation

Nmap comes pre-installed on Kali Linux. On other systems:

Debian/Ubuntu: `sudo apt install nmap`

RHEL/CentOS: `sudo yum install nmap`

macOS: `brew install nmap`

Windows: Download from nmap.org

Basic Scanning Techniques

Ping Scan (Host Discovery)

Discover which hosts are alive on a network:

nmap -sn 192.168.1.0/24

Purpose: Identify live hosts before investing time in detailed scanning.

How it works: Sends ICMP echo requests, TCP SYN to port 443, and TCP ACK to port 80. A live host responds to at least one probe.

Root required: No, but ICMP responses may be blocked — TCP probes improve reliability.

Expected output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 10:00 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0012s latency).
Nmap scan report for 192.168.1.10
Host is up (0.0025s latency).
Nmap scan report for 192.168.1.50
Host is up (0.0018s latency).
MAC Address: 00:1A:2B:3C:4D:5E (Intel)
Nmap done: 256 IP addresses (3 hosts up) scanned in 4.23s

Key observations:

Only hosts that respond to at least one probe appear

MAC address appears when scanning the local subnet (ARP discovery)

"256 IP addresses" = the /24 subnet size; scan time depends on network size and latency

If zero hosts appear, try `-Pn` to skip host discovery (the target may block all probes)

When to use: Always start with a ping scan to map the attack surface before detailed scanning. Saves hours on large subnets.

{@visual nmap-host-discovery}

TCP SYN Scan (Default)

The most popular scan type, also known as half-open scanning. It sends SYN packets and waits for SYN/ACK responses without completing the TCP handshake.

nmap -sS 192.168.1.1

Purpose: Fast, stealthy port scanning for most TCP services.

How it works: Sends SYN (connection request). Open port replies SYN/ACK. Scanner sends RST (reset) instead of ACK — handshake never completes. Closed port replies RST. Filtered port drops the packet or sends ICMP unreachable.

Root required: Yes — raw packet construction needs privileges. Use sudo.

Expected output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 10:05 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0018s latency).
Not shown: 997 closed tcp ports (reset)
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
443/tcp  open     ssl/http
3306/tcp filtered mysql
MAC Address: 00:1A:2B:3C:4D:5E (Intel)

Nmap done: 1 IP address (1 host up) scanned in 5.67s

Key observations:

**STATE "open"**: Port responded with SYN/ACK — a service is listening

**STATE "closed"**: Port responded with RST — no service, but host is reachable  

**STATE "filtered"**: No response or ICMP unreachable — likely a firewall is blocking the port

"Not shown: 997 closed tcp ports" — abbreviates the full list; use `-v` (verbose) to see all

Scan time increases with the number of ports and network latency

Limitations:

Firewalls may detect and drop SYN packets without response, causing false "filtered" states

Some intrusion detection systems (IDS) flag sequential SYN probes as a port scan

Cannot detect services behind a stateful firewall that permits only established connections

{@visual nmap-syn-scan-output}

{@visual nmap-syn-scan-handshake}

TCP Connect Scan

Completes the full TCP handshake. Used when SYN scan is unavailable.

nmap -sT 192.168.1.1

Purpose: Port scanning without root privileges.

How it works: Calls the OS connect() system call — the kernel completes the full SYN → SYN/ACK → ACK handshake, then Nmap closes with a RST or FIN.

Root required: No. Works without sudo.

Expected output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 10:10 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0015s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
443/tcp  open     ssl/http
3306/tcp filtered mysql

Nmap done: 1 IP address (1 host up) scanned in 10.23s

Key differences from SYN scan:

Output looks nearly identical — the difference is in how the scan is performed, not what it shows

"conn-refused" instead of "reset" in the "Not shown" line — subtle differentiator

Slower than SYN scan (full handshake vs. half-open) — typically 2-3x longer

Leaves connection logs on the target (the OS completed a TCP connection), easier to detect

Use this when `sudo` is unavailable or when SYN scan produces no results

{@visual nmap-connect-handshake}

UDP Scan

Scans UDP ports for services like DNS, DHCP, and SNMP. Slower than TCP scanning.

nmap -sU 192.168.1.1

Purpose: Find UDP services that TCP scans miss entirely.

How it works: Sends UDP probes to each port. Open port may respond with UDP data. Closed port responds with ICMP Port Unreachable. No response = open|filtered (can't distinguish).

Root required: Yes — raw packet construction.

Expected output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 10:15 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0018s latency).
Not shown: 996 open|filtered udp ports (no-response)
PORT     STATE         SERVICE
53/udp   open          domain
67/udp   open|filtered dhcpserver
161/udp  open          snmp
631/udp  closed        ipp
MAC Address: 00:1A:2B:3C:4D:5E (Intel)

Nmap done: 1 IP address (1 host up) scanned in 52.34s

Key observations:

"open|filtered" is the default state — most UDP probes receive no response at all

UDP scanning is **slow** — the 52-second scan above is for only 1000 ports. A full 65535-port UDP scan can take hours

Use `--host-timeout` and `--max-retries` to control scan duration

Critical services to find: DNS (53), DHCP (67), SNMP (161), NTP (123), TFTP (69)

Limitations:

Rate limiting severely impacts UDP scan speed

Many UDP services require a specific probe to elicit a response

ICMP rate limiting (e.g., `iptables --limit`) causes false "open|filtered" states

Combine with `-sV` for service detection, which sends service-specific probes

{@visual nmap-udp-scan-flow}

Scan Type Comparison

|-----------|---------|--------------|-----------|-------|---------|----------|

| TCP Connect | -sT | No | Full (SYN → SYN/ACK → ACK) | Moderate | Low | When sudo is unavailable |

| UDP | -sU | Yes | N/A (stateless) | Very slow | N/A | Finding DNS, SNMP, DHCP services |

How to choose:

Start with `-sn` to find live hosts

Use `-sS` (with sudo) as the default port scan

Fall back to `-sT` when root is unavailable

Add `-sU` only when UDP services are expected

Use NULL/FIN/Xmas scans only for firewall rule analysis

Port Specification

nmap -p 80,443,8080 192.168.1.1      # Specific ports
nmap -p 1-1000 192.168.1.1           # Port range
nmap -p- 192.168.1.1                 # All 65535 ports
nmap --top-ports 100 192.168.1.1     # Most common ports

Expected output (specific ports example):

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 10:20 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0018s latency).

PORT     STATE  SERVICE
22/tcp   open   ssh
80/tcp   open   http
443/tcp  open   ssl/http
8080/tcp closed http-proxy

Nmap done: 1 IP address (1 host up) scanned in 2.34s

Key notes:

Only the requested ports appear in the output — this is the fastest way to check specific services

`-p-` (all 65535 ports) is comprehensive but can take 10+ minutes. Use `-T4` to speed it up

`--top-ports` scans the Nmap Top Ports list ranked by frequency. `--top-ports 1000` covers ~90% of common services

Combine with `--exclude-ports` to skip noisy ports

Service Version Detection

Identify software and version running on each open port:

nmap -sV 192.168.1.1

Purpose: Determine service software and version — critical for vulnerability assessment.

How it works: After port discovery, Nmap sends service-specific probes and matches responses against a signature database.

Root required: No, but probe accuracy improves with root.

Expected output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 10:25 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0018s latency).

PORT     STATE  SERVICE    VERSION
22/tcp   open   ssh        OpenSSH 9.2p1 Debian 2 (protocol 2.0)
80/tcp   open   http       Apache httpd 2.4.57
443/tcp  open   ssl/http   Apache httpd 2.4.57
3306/tcp open   mysql      MySQL 8.0.33

Service detection performed. Please report any incorrect results at:
https://nmap.org/submit/
Nmap done: 1 IP address (1 host up) scanned in 25.67s

Key observations:

**VERSION column** shows software name, version number, and sometimes OS or build info

Note "ssl/http" — Nmap detected SSL/TLS encapsulation and probed the underlying HTTP service

Service detection adds significant scan time (25s vs 5s for port-only) because Nmap waits for probe responses

Control intensity with `--version-intensity 0-9` (default 7). Higher = more probes, more accuracy, more time

Use `--version-light` (intensity 2) for faster scans and `--version-all` (intensity 9) for thoroughness

{@visual nmap-version-detection-output}

OS Detection

Identify the operating system running on the target:

nmap -O 192.168.1.1

Purpose: Identify target OS for tailored exploitation and defense strategies.

How it works: Sends crafted TCP/IP probes and analyzes TTL, window size, DF bit, initial sequence numbers, and other TCP/IP stack characteristics against Nmap's OS fingerprint database.

Root required: Yes — raw packet construction required.

Expected output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 10:30 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0018s latency).
Not shown: 997 closed tcp ports (reset)
PORT     STATE  SERVICE
22/tcp   open   ssh
80/tcp   open   http
443/tcp  open   ssl/http
MAC Address: 00:1A:2B:3C:4D:5E (Intel)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.8
Network Distance: 1 hop

Nmap done: 1 IP address (1 host up) scanned in 3.45s

Key observations:

Accuracy is **not guaranteed** — OS detection provides a "best guess" with confidence indicators

Output shows OS family (Linux), kernel range (4.15 - 5.8), and device type (general purpose)

"Network Distance: 1 hop" — confirmed no intermediate routers

Requires at least one open AND one closed TCP port for reliable results

Virtual machines may confuse OS detection because their TCP/IP stacks differ from bare metal

Use `--osscan-guess` to force more aggressive guessing when fingerprints are ambiguous

{@visual nmap-os-detection-output}

Nmap Scripting Engine (NSE)

NSE extends Nmap with pre-written scripts for vulnerability detection, exploitation, and service enumeration.

nmap -sC 192.168.1.1                    # Run default scripts
nmap --script http-headers 192.168.1.1  # Specific script
nmap --script vuln 192.168.1.1         # Vulnerability scan

Expected output (default scripts, abbreviated):

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 10:35 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0018s latency).

PORT     STATE  SERVICE    VERSION
22/tcp   open   ssh        OpenSSH 9.2p1 Debian 2 (protocol 2.0)
| ssh-hostkey: 
|   3072 12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef (RSA)
|   256 ab:cd:ef:12:34:56:78:90:ab:cd:ef:12:34:56:78:90 (ECDSA)
|_  256 12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef (ED25519)
80/tcp   open   http       Apache httpd 2.4.57
|_http-server-header: Apache/2.4.57 (Debian)
|_http-title: Apache2 Debian Default Page: It works
443/tcp  open   ssl/http   Apache httpd 2.4.57
|_http-server-header: Apache/2.4.57 (Debian)
|_ssl-date: TLS randomness does not represent time
| tls-alpn: 
|_  h2
|_http-title: Apache2 Debian Default Page: It works
3306/tcp open   mysql      MySQL 8.0.33
| mysql-info: 
|   Protocol: 10
|   Version: 8.0.33
|_  Thread ID: 42

Nmap done: 1 IP address (1 host up) scanned in 15.78s

Key observations:

NSE results appear as lines prefixed with `|` below each port / service line

`-sC` enables the "default" script category — safe scripts that perform information gathering

Each script result starts with a script name (e.g., `http-title`, `ssh-hostkey`)

Script output can be extensive — use `--script-trace` for debugging and `--script-updatedb` to update the script database

{@visual nmap-nse-script-output}

NSE Script Categories

|----------|-----------|------|-----------------|----------|

Safety guidelines:

Use `--script safe` (or `-sC`) on production systems — never intrusive or exploit categories

The `vuln` category is safe but may send application-level payloads (e.g., SQL injection test strings)

Always test new scripts in a lab environment first

Practical Examples

Quick all-in-one scan:

nmap -sS -sV -O -p- 192.168.1.1

Expected output (abbreviated — full output is several screens):

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 11:00 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0012s latency).
Not shown: 65531 closed tcp ports (reset)
PORT     STATE  SERVICE    VERSION
22/tcp   open   ssh        OpenSSH 9.2p1 Debian 2 (protocol 2.0)
80/tcp   open   http       Apache httpd 2.4.57
443/tcp  open   ssl/http   Apache httpd 2.4.57
3306/tcp open   mysql      MySQL 8.0.33
Device type: general purpose
Running: Linux 4.X|5.X
OS details: Linux 4.15 - 5.8

Nmap done: 1 IP address (1 host up) scanned in 12m 34s

*Note: This scan scans ALL 65535 TCP ports, performs service version detection, AND OS detection. Expect it to run for several minutes to tens of minutes depending on network conditions.

Find web servers on network:

nmap -p 80,443,8080,8443 --open 192.168.1.0/24

Expected output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-07-28 11:15 EDT
Nmap scan report for 192.168.1.1
Host is up (0.0018s latency).

PORT    STATE  SERVICE
80/tcp  open   http
443/tcp open   ssl/http

Nmap scan report for 192.168.1.50
Host is up (0.0025s latency).

PORT    STATE  SERVICE
8080/tcp open  http-proxy

Nmap done: 256 IP addresses (2 hosts up) scanned in 15.23s

Key observations:

`--open` suppresses filtered and closed ports — only shows actionable targets

This is one of the most common real-world Nmap use cases: finding web servers

Add `-sV` to identify the web server software (Apache vs Nginx vs IIS)

Timing Templates

Nmap provides six timing templates that control scan speed and stealth.

nmap -T4 192.168.1.1   # Aggressive — fast LAN
nmap -T2 192.168.1.1   # Polite — production network
nmap -T0 192.168.1.1   # Paranoid — IDS evasion

|----------|------|-------|-------------|----------|

How to choose:

Start with `-T4` on local lab networks for speed

Use `-T3` (default) or `-T2` on production or WAN targets

`-T0` and `-T1` are primarily for IDS evasion — each probe sends with delays measured in seconds

`-T5` is rarely used in practice — it sets extremely aggressive timeouts and can produce incomplete results

Timing can also be fine-tuned with `--min-rate`, `--max-rate`, `--min-hostgroup`, and `--host-timeout`

Practical Lab: Network Scanning with Nmap

Prerequisites

A computer with VirtualBox installed

Kali Linux VM (attacker)

Metasploitable 2 VM (target) — download from SourceForge, or use any Ubuntu VM

Both VMs on the same host-only network

Lab Setup

{@visual nmap-lab-architecture}

**Create host-only network** in VirtualBox: File → Tools → Network Manager → Host-only Networks → Create

**Configure both VMs** to use the host-only adapter (in addition to NAT for internet access)

**Boot both VMs** and log into Kali (default credentials: `kali`/`kali`)

**Find your Kali IP**:

```bash

ip a

```

Look for the enp0s8 or similar interface — note the IP (e.g., 192.168.56.101)

**Verify connectivity**:

```bash

ping -c 3 192.168.56.10 # Replace with your target IP

```

Step-by-Step Lab

Step 1: Discover the target

nmap -sn 192.168.56.0/24

Expected: At least two hosts respond — your Kali box and the target VM. Note the target's IP.

Step 2: Quick port scan

nmap -F 192.168.56.10

Expected: Fast scan of top 100 ports. Should show 5-10 open ports including FTP (21), SSH (22), Telnet (23), HTTP (80).

Step 3: Full service enumeration

nmap -sV 192.168.56.10

Expected: Version detection on all open ports. Note the specific software versions (e.g., "vsftpd 2.3.4", "Apache httpd 2.2.8").

Step 4: Run vulnerability scripts

nmap --script vuln 192.168.56.10

Expected: NSE vulnerability checks. Metasploitable 2 will trigger multiple findings (e.g., vsftpd backdoor, Samba usermap script).

Step 5: OS detection

sudo nmap -O 192.168.56.10

Expected: OS fingerprint shows Linux 2.6.X — the correct OS for Metasploitable 2.

Step 6: Save results

sudo nmap -sS -sV -O -oA metasploitable-scan 192.168.56.10

Expected: Three output files created: metasploitable-scan.nmap, metasploitable-scan.gnmap, metasploitable-scan.xml.

Step 7: Output format exploration

cat metasploitable-scan.nmap              # Normal format
nmap -oX metasploitable-scan.xml 192...   # XML for programmatic parsing
nmap -oG - 192.168.56.10                  # Greppable format (stdout)

Cleanup

Power off both VMs after the lab

The host-only network can be deleted from VirtualBox Network Manager

All scan result files are contained within the Kali VM

Learning Outcomes

After completing this lab you should be able to:

Use ping sweeps to discover live hosts on a subnet

Perform port scanning with SYN, Connect, and UDP methods

Identify service software and versions

Run NSE vulnerability scripts safely

Interpret scan output accurately

Choose the right scan type for each scenario

Difficulty: Beginner

Estimated time: 45-60 minutes

Safety note: This lab uses an isolated host-only network. No external systems are scanned. Never run these scans against networks you do not own or have written authorization to test.

Common Beginner Mistakes

1. Running SYN Scan Without sudo

Problem: nmap -sS target fails.

Why: SYN scan requires raw packet privileges.

Symptoms: You requested a scan type which is not root — QUITTING!

Solution: Use sudo nmap -sS target or switch to nmap -sT target (connect scan).

Prevention: Always run sudo nmap for SYN, UDP, OS detection, and ping sweeps.

2. Scanning the Wrong CIDR Notation

Problem: Typing nmap -sn 192.168.1.0/0 thinking it scans one subnet.

Why: /0 means "all IPv4 addresses" — 4 billion IPs.

Symptoms: Scan appears to hang forever and eventually fails.

Solution: Ctrl+C to cancel, then use /24 (256 IPs) for a typical subnet.

Prevention: Double-check your CIDR notation. /24 = one Class C subnet, /16 = 65536 IPs, /8 = 16 million IPs.

3. Expecting All 65535 Ports by Default

Problem: Assumes nmap target scans all ports.

Why: Default scan covers only the top 1000 ports.

Symptoms: Important services on high ports (e.g., 8080, 8443, 27017) are missed entirely.

Solution: Use nmap -p- target (all 65535) or nmap --top-ports 10000 target.

Prevention: Know Nmap's defaults. Specify ports explicitly when coverage matters.

4. Misinterpreting "filtered" Port State

Problem: Assumes "filtered" means "blocked by firewall" in a simple way.

Why: "filtered" can mean firewall, host-based firewall, network ACL, or no route.

Symptoms: Misleading security assessments — a "filtered" port may still be accessible through a different path.

Solution: Run multiple scan types (-sS, -sT, -sA) and compare results. Use -sA to distinguish stateful vs stateless filtering.

Prevention: Always verify filtered ports from multiple angles before drawing conclusions.

5. Running Vulnerability Scripts on Production Without Permission

Problem: nmap --script vuln production-server sends exploit payloads.

Why: The vuln category sends application-level attack strings (SQL injection, path traversal) to test for vulnerabilities — these can crash services.

Symptoms: Service disruption, WAF blocks, legal liability.

Solution: Use nmap --script safe (or -sC) on production. Reserve vuln and exploit categories for lab environments.

Prevention: Know your script categories. "safe" = informational only. "vuln" = active testing. "exploit" = actual exploitation.

6. Ignoring Scan Speed for WAN Targets

Problem: Default timing (-T3) on a high-latency WAN target.

Why: Default timing is conservatively balanced but slow over WAN links.

Symptoms: A full port scan can take 30+ minutes when you expect 5.

Solution: Use -T4 for WAN, increase --min-rate to 100-500, and limit ports with -p or --top-ports.

Prevention: Adjust timing based on network conditions. Start fast (-T4) and back off if results are unreliable.

7. Forgetting -sV and Wondering Why No Version Info

Problem: Runs nmap -sS target and looks for version information.

Why: Service detection is a separate feature — -sV must be explicitly added.

Symptoms: "I see open ports but no software versions."

Solution: Use nmap -sS -sV target to get ports + versions in one scan.

Prevention: Remember: -sS = ports, -sV = versions, -O = OS. Combine them as needed.

Troubleshooting

|---------|-------|-----------|-----|-------------|

| "Failed to resolve hostname" | DNS resolution fails for target name | Run nslookup target.com separately | Use IP directly, or check DNS config in /etc/resolv.conf | nmap 8.8.8.8 (Google DNS) should work immediately |

| All ports show "filtered" | Firewall blocking probes; host may not be reachable | ping target fails or shows high loss | Try -sT (different probe type), check network path with traceroute, verify host is online | nmap -sT -Pn target — -Pn skips host discovery |

| "You requested a scan type which is not root" | -sS, -sU, -O run without sudo | Check if running as root: whoami | Prepend sudo: sudo nmap -sS target; or use -sT | sudo nmap -sS 127.0.0.1 — localhost should work |

| Host shows "down" but is online | Target blocks ICMP and TCP probes used by host discovery | Ping the target directly — if ICMP is blocked, ping fails too | Use -Pn to skip host discovery and begin port scanning immediately | nmap -Pn target — forces scan regardless of host status |

| Scan is extremely slow | Large port range + conservative timing + high latency | Check round-trip with ping target; note that -p- covers 65535 ports | Use -T4, limit ports with --top-ports 1000, set --min-rate 100 | Compare scan time before and after: time nmap -T4 --top-ports 1000 target |

| OS detection returns no results | Too few open (or closed) ports for fingerprinting | Check ports — need at least one open and one closed TCP port | Ensure both open and filtered/closed ports appear; -O alone does not port scan | sudo nmap -sS -O target — combines port scan + OS detection |

| NSE scripts return no output | Scripts didn't match any service, or no scripts in selected category | Run with -v (verbose) to see which scripts were attempted | Try explicit script: --script http-title; update database: --script-updatedb | nmap --script http-title -p 80 target — only tries HTTP title on port 80 |

| Output is truncated or unreadable | Terminal width too narrow for Nmap's columnar output | Check terminal width: tput cols | Use -oA outputname to save to files; view with cat outputname.nmap or xsltproc outputname.xml | nmap -oA scan 192.168.1.1 — generates .nmap, .gnmap, .xml files |

| "Failed to open device" in Windows | WinPcap or Npcap not installed; no raw packet access | Check installed programs for Npcap | Download and install Npcap from nmap.org; select "WinPcap API-compatible Mode" | Open cmd as Administrator and retry nmap -sS 127.0.0.1 |

| Results change between runs | Dynamic services, load balancers, or firewall state changes | Run scan multiple times; vary timing: -T2, -T4 | Compare multiple scan results with ndiff; document timing and network conditions | ndiff scan1.xml scan2.xml — shows differences between two scans |

Detection and Defense

Understanding how defenders detect Nmap scans is essential for both offensive practitioners (to avoid detection) and defenders (to build monitoring).

How Defenders Detect Port Scans

SYN scan detection:

Firewall logs show SYN packets to multiple ports from the same source IP within milliseconds — a pattern that does not occur in normal traffic

The scanner never sends the final ACK, leaving incomplete connections in the target's connection table

`iptables` can log SYN-only packets: `iptables -A INPUT -p tcp --syn -j LOG --log-prefix "SCAN:"`

Connect scan detection:

Web server access logs show connections from the same IP across multiple ports in rapid succession

Connection logs show completed TCP handshakes followed by immediate RST (no data exchange)

Easier to detect than SYN scans because the full handshake is logged by the target OS

Tools defenders use:

**psad** (Port Scan Attack Detector): Analyzes iptables logs in real time, identifies scan patterns, and can auto-block source IPs after configurable thresholds

**Snort/Suricata**: IDS rules like `alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN NMAP -sS"; ...)` detect sequential port probes

**Fail2ban**: Can be configured with custom filters to block IPs that exceed port scan thresholds

**Security Onion**: Full network visibility platform that correlates scan events from multiple sensors

Sample Logs

iptables LOG output (SYN scan detected):

Jul 28 10:05:01 host kernel: SCAN: IN=enp0s3 OUT= MAC=... SRC=192.168.1.100 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=54321 PROTO=TCP SPT=54321 DPT=22 WINDOW=1024 RES=0x00 SYN URGP=0
Jul 28 10:05:01 host kernel: SCAN: IN=enp0s3 OUT=... SRC=192.168.1.100 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=54322 PROTO=TCP SPT=54322 DPT=80 WINDOW=1024 RES=0x00 SYN URGP=0

Mitigation Strategies

| Defense | Implementation | Effectiveness |

|---------|---------------|--------------|

| Default-deny firewall | Only allow specific ports from specific source IPs | High — filtered ports reveal no information |

| Rate limiting | Limit connections per second per source IP using iptables --limit | Medium — slows but doesn't prevent scans |

| Port knocking | Require connection sequence to "open" SSH or other sensitive ports | High — port scanners see all ports as closed or filtered |

| Move sensitive services | Change SSH from 22 to a high port (trade-off: convenience vs obscurity) | Low — not security, but reduces automated scan noise |

| IDS/IPS deployment | Snort/Suricata rules that alert on and optionally block scan patterns | High — provides detection + automated response |

| Network segmentation | Isolate sensitive systems on separate VLANs with strict ACLs | Very high — limits what a scanner can reach |

Best Practices for Defenders

**Monitor outbound scanning** — an internal host scanning outward may indicate compromise

**Correlate scans with other events** — a port scan followed by exploitation attempts is a real incident

**Honeypots** — deploy decoy services on unusual ports to detect reconnaissance

**Baseline normal traffic** — know which external IPs routinely connect to which services; flag deviations

**Log retention** — retain firewall logs for at least 90 days for post-incident analysis

Glossary

| Term | Definition |

|------|------------|

| SYN | Synchronize flag — the first packet in TCP three-way handshake, initiates a connection request |

| SYN-ACK | Synchronize-Acknowledgment — the second packet, sent by the server to confirm it received the SYN and is willing to connect |

| RST | Reset flag — terminates a TCP connection immediately, used when a host receives a packet for a non-listening port |

| ACK | Acknowledgment flag — confirms receipt of data; the final step in the TCP handshake |

| Half-open scan | A SYN scan that never completes the handshake (SYN sent, SYN/ACK received, RST sent instead of ACK) — the connection is never fully established |

| Host discovery | The Nmap phase that determines which IPs are alive before port scanning |

| Port state: open | A service is actively listening on this port and responded to our probe |

| Port state: closed | No service is listening; the host responded with RST, confirming reachability |

| Port state: filtered | No response received — likely a firewall, ACL, or network issue is blocking the probe |

| Port state: open|filtered | Nmap cannot distinguish between open (responding) and filtered (blocked) — common in UDP scans |

| Service fingerprinting | Matching service probe responses against Nmap's signature database to identify software name and version |

| OS fingerprinting | TCP/IP stack analysis that identifies the operating system by analyzing TTL, window size, DF bit, and initial sequence number patterns |

| NSE | Nmap Scripting Engine — Lua-based scripting system bundled with Nmap for automated scanning, enumeration, and vulnerability detection |

| Timing template | Predefined scan speed and stealth profile (T0 Paranoid through T5 Insane) that controls probe delay, parallelism, and timeouts |

| ICMP | Internet Control Message Protocol — used by ping for network diagnostics; carries port unreachable messages during UDP scans |

| TTL | Time To Live — IP header field that limits packet lifetime; different operating systems use different default TTL values |

| CIDR | Classless Inter-Domain Routing — notation for subnet size (e.g., /24 = 256 addresses, /16 = 65536 addresses) |

| Npcap | Windows packet capture library required by Nmap for raw packet operations (SYN scans, OS detection) |

References

{@ref nmap-docs}

{@ref nmap-man-page}

{@ref nmap-book}

{@ref nmap-nse}

{@ref nmap-port-scanning}

{@ref kali-tools}

{@ref nist-sp800-115}

{@ref rfc793}

{@ref mitre-attack-discovery}

Frequently Asked Questions

What is Nmap used for?

Nmap (Network Mapper) is used for network discovery, port scanning, service detection, OS fingerprinting, and vulnerability assessment. Security professionals use it to map networks, identify open ports, determine running services, and detect potential vulnerabilities on target systems.

What is the difference between a SYN scan and a connect scan?

A SYN scan (-sS) sends SYN packets without completing the TCP handshake (half-open), making it faster and stealthier. A connect scan (-sT) completes the full handshake and is more reliable but easier to detect. SYN scan requires root privileges.

How do I scan all 65535 ports on a target?

Use `nmap -p- target` to scan all TCP ports. This is comprehensive but slow. For faster scans, use `--top-ports 1000` for the most common ports, or combine with timing templates like `-T4` for speed. See our [networking basics](/learn/networking-basics) for port fundamentals.

Why is my Nmap scan so slow?

Scanning all ports, using OS detection, or running on unreliable networks causes slowness. Use `-T4` for faster scans, limit ports with `-p`, skip OS detection (`-O`) if not needed, and use `--min-rate` to set a minimum packet send rate. Network latency and firewall filtering also slow scans.

What are Nmap NSE scripts?

The Nmap Scripting Engine (NSE) extends Nmap with pre-written scripts for vulnerability detection, brute forcing, and service enumeration. Use `-sC` for default scripts, `--script vuln` for vulnerability scanning, and `--script http-headers` for specific scripts. Categories include safe, intrusive, and exploit.

Do I need root privileges to use Nmap?

Some features require root: SYN scans (-sS), OS detection (-O), and ICMP ping sweeps. Non-privileged users can still run connect scans (-sT) and basic port scans. Use `sudo` on Linux for full functionality.

How do I discover live hosts on a network?

Use `nmap -sn 192.168.1.0/24` for a ping scan that discovers active hosts without port scanning. This sends ICMP echo requests, TCP SYN to port 443, and TCP ACK to port 80. It is fast and identifies which IP addresses are online.

Is Nmap legal to use?

Nmap is a legitimate security tool, but scanning networks without authorization is illegal in most jurisdictions. Always get written permission before scanning any network you do not own. Practice in your own lab environment or on authorized platforms like [Hack The Box](/tools/hackthebox).

What is the difference between service version detection and OS detection?

Service version detection (-sV) identifies the specific version of services running on open ports (e.g., Apache 2.4.41). OS detection (-O) fingerprints the target's operating system using TCP/IP stack analysis. Use both together for comprehensive reconnaissance.

How do I find web servers on a network?

Use `nmap -p 80,443,8080,8443 --open 192.168.1.0/24` to find hosts with HTTP/HTTPS ports open. Add `-sV` to identify the web server software (Apache, Nginx, IIS). This is the first step in [web application security](/learn/web-security-fundamentals) testing.