Port scanning with Nmap and its scanning types

Port scanning is the foundation of network reconnaissance. It answers a simple but critical question: which services are reachable on a given host? Nmap supports a wide variety of scan types, each with different trade-offs in speed, stealth, accuracy, and the privileges required to run them. Choosing the right scan type for the right situation is one of the most important skills for anyone working in network security.

This guide breaks down every major Nmap scan type, explains how each one works at the protocol level, provides syntax and examples, and covers when to use which type along with common pitfalls.

How Port Scanning Works (Quick Refresher)

Every network port can be in one of several states as far as Nmap is concerned:

• open: A service is actively listening and accepting connections
• closed: The port is reachable, but no service is listening
• filtered: A firewall or filter is blocking Nmap from determining the port’s true state
• unfiltered: The port is reachable, but Nmap can’t determine if it’s open or closed (mainly seen in ACK scans)
• open|filtered: Nmap can’t tell if the port is open or filtered
• closed|filtered: Nmap can’t tell if the port is closed or filtered

Different scan types determine these states using different underlying mechanisms, which is why results can sometimes vary between scan types against the same target.

TCP SYN Scan (-sS)

Often called a “half-open” scan, this is Nmap’s default and most popular scan type when run with sufficient privileges.

nmap -sS 192.168.1.10

How it works: Nmap sends a SYN packet as if initiating a TCP handshake. If it gets a SYN/ACK back, the port is open, and Nmap immediately sends an RST to tear down the connection instead of completing the handshake. If it gets an RST back, the port is closed.

Pros: Fast, relatively stealthy (never completes a full connection, so it’s less likely to be logged by the target application), works well at scale. Cons: Requires raw socket privileges (root/administrator).

Expected output:

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

TCP Connect Scan (-sT)

nmap -sT 192.168.1.10

How it works: Uses the operating system’s normal connect() system call to complete a full TCP three-way handshake with each port.

Pros: Doesn’t require elevated privileges, works on any user account. Cons: Slower than SYN scan, and because it completes full connections, it’s far more likely to be logged by the target service or an IDS.

This is the scan type Nmap falls back to automatically when SYN scan isn’t possible due to insufficient privileges.

UDP Scan (-sU)

nmap -sU 192.168.1.10

How it works: Sends UDP packets to each target port. Since UDP is connectionless, there’s no handshake to observe. Nmap interprets the port as open if it gets any UDP response, closed if it gets an ICMP “port unreachable” message, and open|filtered if there’s no response at all (which is common, since many services don’t respond to empty probes and many firewalls silently drop UDP).

Pros: Necessary for discovering UDP-based services like DNS (53), SNMP (161), and DHCP (67/68). Cons: Significantly slower than TCP scanning due to rate-limiting on ICMP responses by most operating systems, and results are often ambiguous (open|filtered).

Example combining UDP with version detection for accuracy:

nmap -sU -sV --top-ports 20 192.168.1.10

Limiting to top ports is a common practical adjustment since a full UDP scan (-p-) can take an extremely long time.

TCP ACK Scan (-sA)

nmap -sA 192.168.1.10

How it works: Sends only an ACK packet, which doesn’t attempt to open a connection. This scan type isn’t meant to determine open vs. closed — it’s specifically used to map firewall rule sets, determining whether ports are filtered or unfiltered.

Use case: Understanding whether a firewall is stateful (tracking connections) or simply doing basic packet filtering, which is valuable during firewall rule auditing.

TCP Window Scan (-sW)

nmap -sW 192.168.1.10

Similar mechanics to the ACK scan but examines the TCP window size in the returned RST packets to sometimes distinguish open from closed ports on certain operating systems, since a subset of systems report a nonzero window size for open ports. This scan type is less reliable across modern systems and is mostly of historical/academic interest today.

TCP FIN, Xmas, and Null Scans

These three scan types exploit a quirk in the TCP RFC: closed ports should respond with an RST when they receive unexpected flag combinations, while open ports should simply ignore them (silently drop the packet) on RFC-compliant systems.

FIN Scan (-sF)

nmap -sF 192.168.1.10

Sends a packet with only the FIN flag set.

Xmas Scan (-sX)

nmap -sX 192.168.1.10

Sends a packet with the FIN, PSH, and URG flags all set simultaneously (lighting it up like a Christmas tree, hence the name).

Null Scan (-sN)

nmap -sN 192.168.1.10

Sends a packet with no flags set at all.

Pros of all three: Can sometimes bypass simple stateless firewalls or packet filters that only look for SYN packets. Cons: Doesn’t work reliably against Windows systems, which don’t follow this part of the RFC consistently; results can be ambiguous (open|filtered).

TCP Maimon Scan (-sM)

nmap -sM 192.168.1.10

A lesser-used scan type that sends FIN/ACK packets, exploiting a specific BSD-derived networking stack quirk. Rarely used in modern assessments since most target systems no longer exhibit the specific behavior this scan relies on, but it remains available for completeness and legacy compatibility testing.

Idle/Zombie Scan (-sI)

nmap -sI zombie_host 192.168.1.10

How it works: One of the most advanced (and stealthiest) scan types. It uses a third-party “zombie” host with predictable IP ID sequence numbers to indirectly scan a target — the attacker never sends packets directly from their own IP to the target, making it extremely difficult to trace the scan back to its true origin.

Requirements: A suitable zombie host with predictable, incremental IP ID generation, which is increasingly rare on modern operating systems, making this scan type largely a demonstration of TCP/IP protocol design flaws rather than a routinely practical tool today.

SCTP INIT Scan (-sY) and COOKIE ECHO Scan (-sZ)

nmap -sY 192.168.1.10
nmap -sZ 192.168.1.10

These target the SCTP protocol (used in telecom and some VoIP infrastructure) rather than TCP or UDP, following similar half-open logic to the SYN scan but adapted to SCTP’s INIT/INIT-ACK handshake.

IP Protocol Scan (-sO)

nmap -sO 192.168.1.10

Rather than scanning ports, this scan type determines which IP protocols (TCP, UDP, ICMP, GRE, etc.) are supported by a target host, which is useful for understanding what protocol-level filtering exists on a network boundary.

Ping Scan / Host Discovery Only (-sn)

nmap -sn 192.168.1.0/24

Skips port scanning entirely and just determines which hosts are alive, making it the fastest way to inventory a subnet before running deeper, targeted scans against individual hosts.

Comparing Scan Types

Combining Scan Types with Timing and Output

nmap -sS -sV -p 1-1000 -T4 -oA scan_results 192.168.1.10

• -T4: A faster timing template (0-5 scale, where 5 is fastest but noisiest)
• -oA scan_results: Saves output in normal, XML, and grepable formats simultaneously

Troubleshooting Common Issues

“You requested a scan type which requires root privileges” Cause: Attempting -sS, -sU, or other raw-socket scan types without administrator/root access. Fix: Run with sudo (Linux/macOS) or as an administrator (Windows), or fall back to -sT.

All ports show as filtered Cause: A firewall between the scanner and target is dropping packets rather than rejecting them. Fix: Try -Pn to skip host discovery, adjust timing (-T2), or try a different scan type like ACK to better understand the filtering behavior.

UDP scan takes an extremely long time Cause: UDP scanning is inherently slow due to ICMP rate-limiting on most systems. Fix: Limit scope with --top-ports or specific port lists rather than scanning the full UDP range.

FIN/Xmas/Null scans show everything as open|filtered Cause: Target is a Windows host, which doesn’t follow the relevant RFC behavior these scans depend on. Fix: Use SYN or Connect scans against Windows targets instead.

Security Best Practices

• Always obtain explicit written authorization before scanning any network you don’t own.
• Use less noisy scan types (SYN over Connect) and slower timing templates when stealth or minimal network disruption matters.
• Be aware that some scan types (FIN, Xmas, Null, Idle) can trigger IDS/IPS alerts specifically because they’re unusual traffic patterns, even though they’re designed to be “stealthy” against simple filters.
• Document exactly which scan types were used during any professional engagement, since different scan types can produce different results against the same target, and this affects the interpretation of scan reports.
• Combine port scanning with proper scoping agreements — scanning IP protocol ranges (-sO) or SCTP scans against unfamiliar infrastructure can have unpredictable effects on specialized systems like telecom equipment.

Limitations

• No scan type is perfectly accurate against all firewall/IDS configurations — filtered results are inherently ambiguous by design.
• Idle scanning requires a compatible zombie host, which is increasingly hard to find on modern networks due to randomized IP ID implementations.
• UDP scanning accuracy is fundamentally limited by the protocol’s connectionless nature and inconsistent ICMP responses across different systems.
• Some scan types (Window, Maimon) are largely legacy and unreliable against modern operating systems.

Choosing a Scan Type: A Decision Framework

For beginners, deciding which scan type to reach for can feel overwhelming given the sheer number of options. A simple decision process helps:

1. Do you have root/administrator privileges? If not, -sT (Connect scan) is your only real option for TCP scanning.
2. Do you need to check UDP services (DNS, SNMP, DHCP)? Use -sU, ideally scoped to specific ports rather than the full range.
3. Is stealth or evading a basic stateless firewall a priority? Consider -sF, -sX, or -sN, keeping in mind their unreliability against Windows targets.
4. Do you need to understand firewall rule behavior rather than just port state? Use -sA to distinguish filtered from unfiltered.
5. Is this a routine, general-purpose scan with adequate privileges? -sS (SYN scan) is the sensible default in the vast majority of cases.

This kind of structured thinking is more useful long-term than memorizing flags in isolation, since it ties each scan type back to the actual problem it solves.

Timing Templates and Their Interaction with Scan Types

Nmap’s timing templates (-T0 through -T5) control how aggressively packets are sent and how long Nmap waits for responses, and they interact meaningfully with scan type choice:

Example combining a stealthier scan type with slower timing for a sensitive production system:

nmap -sS -T2 192.168.1.10

Compare this to a fast internal lab scan where speed matters more than subtlety:

nmap -sS -T4 192.168.1.0/24

Scan Type Detection by Defenders

It’s worth understanding how these scan types appear from the defender’s side, since this context clarifies why certain types are described as “stealthy”:

• SYN scans appear as incomplete TCP handshakes in firewall/IDS logs — suspicious but often not logged by the destination application itself since no full connection was made.
• Connect scans complete full handshakes, meaning they’re far more likely to appear in application-level logs (e.g., a web server access log) in addition to network-level logs.
• FIN/Xmas/Null scans produce unusual flag combinations that most modern IDS/IPS systems specifically signature and alert on, somewhat ironically making them easier to detect at the network level even though they can bypass simplistic legacy filters.
• Idle scans are the hardest to attribute since the traffic appears to originate from the zombie host rather than the actual scanner.

Frequently Asked Questions

What’s the default scan type if I don’t specify one? If run with sufficient privileges, Nmap defaults to a TCP SYN scan (-sS). Without elevated privileges, it automatically falls back to a TCP Connect scan (-sT).

Why do UDP scans take so much longer than TCP scans? Most operating systems rate-limit ICMP “port unreachable” responses to a small number per second, and Nmap has to wait for these responses (or their absence) to determine port states, which fundamentally caps how fast a UDP scan can run regardless of network speed.

Can I combine multiple scan types in a single Nmap command? Yes, for example nmap -sS -sU runs both a TCP SYN scan and a UDP scan in the same invocation, scanning both protocols against the specified ports.

Are FIN, Xmas, and Null scans still useful today? They’re less broadly useful than they once were, since both modern firewalls and Windows systems largely defeat their core assumption, but they remain relevant in specific scenarios involving simple legacy stateless packet filters.

Is idle scanning still practical on modern networks? Rarely, since it depends on finding a host with predictable, sequential IP ID generation, and most modern operating systems randomize IP IDs specifically to prevent this technique. It remains valuable to understand conceptually, even if practical opportunities to use it are increasingly uncommon.

Conclusion

Nmap’s variety of scan types exists because no single technique works optimally in every situation — speed, stealth, protocol coverage, and privilege requirements all trade off against each other. Understanding what each scan type actually does at the packet level, rather than just memorizing flags, makes it possible to choose the right approach for a given target and situation, interpret ambiguous results correctly, and avoid wasting time on scan types that won’t work reliably against a particular kind of system.