All-Ports Scanning with Nmap — TCP, UDP and Quieter Tactics

Safety first. Port scanning can be intrusive and is regulated: only scan systems and networks you own or have explicit authorization to test. Misuse can be illegal and unethical. This article explains how to use nmap for legitimate security testing and how to make scans less noisy for operational reasons (avoid disrupting services, reduce false positives in monitoring). It does not endorse unauthorized access. Check our Practice page for more information abot safe environments.

Port scanning is the process of probing a host or range of hosts to discover which TCP and UDP ports are open, closed, or filtered. nmap is the go-to open-source tool for this: flexible, extensible, and well documented. This guide explains how to:

  • scan all ports (1-65,535) for TCP and UDP,
  • practical nmap command examples,
  • tactics to make scans quieter and less disruptive (rate/timing control, targeting strategies),
  • how to read results and combine scans for useful intelligence,
  • defensive notes for detecting/handling scanning activity.

Quick refresher: ports and port ranges

  • TCP and UDP ports range from 1 to 65535.
  • Common short-cuts:
    • -p 1-65535 or -p- (the latter means "all TCP ports").
    • For UDP, same -p- but UDP scanning is slower and less reliable.

Basic nmap commands to scan all ports

Replace target below with a single IP, a hostname, or a CIDR range (e.g., 192.0.2.0/24). Always get permission. If you would like to practice do it in safe environments, check our Practice page for more information.

TCP — full port range, connect scan (reliable)

A straightforward, always-works TCP scan using the OS network stack:

nmap -sT -p- target
  • -sT — TCP connect() scan (no raw packets; uses OS connect). Works without elevated privileges.
  • -p- — scan ports 1–65535.

TCP — SYN "stealth" scan (fast & common)

sudo nmap -sS -p- target
  • -sS — SYN scan (sends SYN, waits for SYN/ACK). Requires raw sockets (root/Administrator).
  • Generally faster and less resource-intensive on the scanner.

UDP — scan all UDP ports (slow)

sudo nmap -sU -p- target
  • -sU — UDP scan. Much slower; UDP is connectionless so nmap sends probes and waits for ICMP or UDP responses. Expect long runtimes for full port ranges.

Combine TCP & UDP (careful — heavy)

sudo nmap -sS -sU -p- target
  • Scans both TCP SYN and UDP. This is comprehensive but can take a long time and may produce lots of noise.

Add service/version detection and scripts

sudo nmap -sS -sU -p- -sV -A --version-intensity 5 target
  • -sV — service/version detection.
  • -A — aggressive: OS detection, version detection, script scanning, traceroute.
  • Caution: -A and NSE scripts can be intrusive; avoid on production systems without permission.

Practical notes on UDP scanning

  • UDP is inherently slow and unreliable: many services do not reply; nmap relies on ICMP unreachable responses to mark closed.
  • Use --top-ports N or --top-ports 1000 to scan the most common UDP ports first.
  • Increase timeouts and retries if you need more accuracy: --host-timeout, --max-retries.
  • If scanning a host you control, run services that respond to probes (or run a UDP banner service) for faster, clearer results.

Example: scan top 200 UDP ports first:

sudo nmap -sU --top-ports 200 -sV target

Ways to scan quietly (less noisy / less disruptive)

Important: “quiet” here means less likely to overload the target and less likely to trigger noisy alert thresholds. It is not a guarantee of stealth, and network defenders can still see and log scanning. Always test with authorization (get written permission before scanning).

Reduce parallelism and rate

Use timing templates (-T0 to -T5). Lower numbers are slower/more polite.

-T0 or -T1 are the slowest (polite), -T4/-T5 are fast/noisy.

sudo nmap -sS -p- -T1 target
  • Control packet rate: --min-rate / --max-rate (set low to be gentle).
  • Reduce parallel probes: --min-parallelism / --max-parallelism.

Add delays between probes

--scan-delay <time> introduces a delay between probes to reduce burstiness:

sudo nmap -sS -p- --scan-delay 200ms -T2 target

Alternatively, use --min-rate 10 to enforce a low continuous rate.

Randomize host/port order

--randomize-hosts shuffles target order for ranges; spreads load over time and reduces banked bursts.

nmap -p- --randomize-hosts --min-rate 20 192.0.2.0/24

Scan subsets or high-value ports first

  • Instead of scanning all 65k ports at once, target:
    • --top-ports 1000 (most common ports),
    • or common services lists (-p 1-1024,1433,3306,8000-8100).
  • Stagger full-port scans during maintenance windows.

Use host discovery carefully

Using -Pn (skip host discovery/ping) avoids noisy ICMP/ARP pings but will cause Nmap to probe every host you list — which can be more intrusive. Use when you know hosts are up.

sudo nmap -sS -p- -T2 -Pn target

Limit scripting and intense checks

  • Avoid -A or heavy NSE scripts unless needed. Use targeted scripts instead: --script banner rather than --script vuln.

Respect time windows and service impact

  • Schedule scans during low usage periods.
  • Notify operations/network teams in advance.

Example combined (careful) — slower, broad TCP scan with version detection

sudo nmap -sS -p- -T2 --scan-delay 150ms --min-rate 20 --max-retries 2 -sV --version-intensity 2 target

This balances thoroughness and gentleness: SYN scan of all ports, modest version checks, low timing.

Interpreting results: open, closed, filtered, unfiltered

  • open — service responded; likely usable.
  • closed — port reachable but no application listening.
  • filtered — probes did not get responses; could be blocked by firewall/IPS or dropped.
  • unfiltered — port is reachable but Nmap cannot determine open/closed (TCP scans with weird replies).
  • UDP often shows open|filtered because lack of response is ambiguous.

Combining TCP and UDP intelligently

  • First run --top-ports for both families to triage:
    • sudo nmap -sS --top-ports 1000 target
    • sudo nmap -sU --top-ports 200 target
  • Reserve full -p- UDP scans for when you must and when you have patience and permission.

Logging, reporting and reproducibility

Use -oA <basename> to save nmap output in all formats:

sudo nmap -sS -p- -sV -oA scan-results target

scan-results.nmap, .xml, and .gnmap are produced for detailed reporting and parsing.

Defensive perspective — how network defenders detect scans

If you're planning scans as an admin, it's also useful to know how defenders detect them:

  • Threshold-based IDS/IPS rules detect unusual connection rates to many ports.
  • Honeypots and tarpit systems flag multi-port connection attempts.
  • Correlating failed connection attempts across many ports/hosts is a red flag.
  • Logging and alerting on uncommon protocol behavior (e.g., many UDP probes) helps detection.

If you are defending a network, tune your IDS to differentiate benign scheduled scans (authorized) from malicious ones by organizing internal scanning programs and whitelisting authorized scan sources.

Best practices checklist

  • ✓ Obtain written authorization before scanning.
  • ✓ Start with --top-ports to identify quick wins.
  • ✓ Use reduced timing (-T1/-T2), --scan-delay, and low rates when scanning production.
  • ✓ Limit NSE scripts and avoid -A on production without permission.
  • ✓ Save results with -oA for reporting and repeatability.
  • ✓ Coordinate with ops/network teams and schedule scans during maintenance windows.
  • ✓ Use authentication (when available) for deeper checks (e.g., authenticated service checks) rather than blind probing.

Example quick reference commands

Scan all TCP ports (SYN):

sudo nmap -sS -p- target

Scan top 1000 TCP ports, version detect:

sudo nmap -sS --top-ports 1000 -sV target

Scan selected UDP ports (top 200) with version detection:

sudo nmap -sU --top-ports 200 -sV target

Polite full TCP scan (slower, gentler):

sudo nmap -sS -p- -T1 --scan-delay 200ms --min-rate 10 -sV target

Save all output formats:

sudo nmap -sS -p- -sV -oA all-ports-scan target

Closing notes

nmap is powerful. Use it responsibly:

  • Prefer targeted scans and staged approaches rather than brute force full-port sweeps on production.
  • When in doubt, consult with your network operations and security teams; keep scans documented.
  • For learning and testing, use lab environments or intentionally vulnerable VMs (e.g., your own test hosts).

Love it? Share this article: