Arkendia Classrooms
Lesson 7 of 28 · 17 min

Port Scanning with Nmap

Every network service listens on a port, like a numbered door into a building. Port scanning finds which doors are unlocked, which are shut, and which are hidden behind a guard that does not answer. In this lesson you will learn the principles of scanning with Nmap, the most widely used scanner in the profession, applied only inside your authorised lab.

You now have a list of hosts from DNS enumeration. The next question is: on each host, what is actually listening and reachable?

A quick refresher on ports and protocols

You met TCP and UDP, and the idea of ports, in the second course of this track. In short: a port is a number from 1 to 65535 identifying a specific service on a host, and TCP and UDP are the two main transport protocols, with TCP being connection-oriented (think of a phone call with an explicit handshake) and UDP being connectionless (think of sending a postcard, with no guarantee of delivery or order).

What Nmap actually does

Nmap ("Network Mapper") sends carefully crafted packets to a target and studies the responses to infer the state of each port, and often the software listening behind it. Three states matter most:

  • Open: a service is listening and responds.
  • Closed: the host is reachable, but nothing listens on that specific port.
  • Filtered: no clear answer was received, usually because a firewall is silently dropping the probes.

Legal reminder

Port scanning sends traffic to a target and can be logged, can trigger security alerts, and in rare cases can disturb fragile devices. Only scan hosts that are explicitly listed in your authorised scope, at the pace agreed with the client, and never scan a real organisation "just to see" from your home connection.

The classic TCP connect scan

The simplest scan completes the full TCP handshake with each port, exactly like a normal application would. It is reliable and does not require special privileges, but it is also the easiest for a target to log, because it creates full, ordinary-looking connections.

nmap -sT 192.168.56.21

This command tells Nmap to perform a connect scan (-sT) against the given address, over its most common ports by default.

The SYN scan: faster, more discreet

A SYN scan sends only the first packet of the TCP handshake and reads the reply, without completing the connection. This is faster and leaves less trace in application logs, though it still appears in network-level logs. It requires elevated privileges on the scanning machine.

sudo nmap -sS 192.168.56.21

In professional engagements, this is the default choice for TCP scanning when speed and some discretion matter, always within the agreed scope and schedule.

Scanning UDP ports

UDP services (such as DNS itself, or some monitoring protocols) do not have a handshake, which makes scanning slower and less reliable: a lack of response can mean "open" or "filtered", and Nmap must often wait for a timeout to decide.

sudo nmap -sU -p 53,161 192.168.56.21

UDP scans are usually limited to a short, targeted list of ports rather than the full range, simply because scanning all 65535 UDP ports can take a very long time.

Choosing which ports to scan

By default, Nmap scans the 1000 most common ports, which is a reasonable starting point. For a thorough engagement, a full scan of all ports is common on hosts that matter:

sudo nmap -sS -p- 192.168.56.21

The -p- flag means "all 65535 TCP ports". It takes longer, but it is the only way to be sure you have not missed a service running on an unusual port.

Service and version detection

Knowing that port 22 is open is a start; knowing that it runs a particular, recent SSH server version is much more useful, because it lets you check that version against known public weaknesses later. The -sV flag asks Nmap to probe each open port further and guess the service and its version:

sudo nmap -sS -sV -p 22,80,443 192.168.56.21

Remember the caution from the brief of this course: a scanner's guess about a version is a hypothesis, not a certainty, and must be confirmed, for example through banner grabbing (next lesson) before you rely on it.

Timing and politeness

Nmap offers timing templates from -T0 (extremely slow and stealthy) to -T5 (extremely fast and noisy). In a real engagement, the right speed depends on the agreement with the client: a fragile legacy system may need a slow, careful scan, while a modern, robust infrastructure can usually tolerate a faster one. In your own lab, moderate settings such as -T3 (the default) are a safe, realistic choice.

Reading and saving results

Always save scan output to a file, both for your journal and for later automated processing:

sudo nmap -sS -sV -p- -oA 01-recon/nmap-lab-web01 192.168.56.21

The -oA flag writes the results in three formats at once (plain text, XML and a simple grepable format) with the given file prefix, which is convenient when you later want to search through many scan results at once.

From scan results to a plan

A completed scan produces a list such as: port 22 open (SSH), port 80 open (web server), port 3306 filtered. Translate this into next steps:

  • Open web ports (80, 443) go to banner grabbing (next lesson) and then to web-specific analysis, reusing what you learned in the pentest web course.
  • Open administrative ports (22 for SSH, 3389 for remote desktop) are noted as potential targets for the password-attack chapter later, never attacked immediately without the rest of the plan.
  • Filtered ports suggest a firewall; note this, since it affects how aggressive later testing can be.

Your fil rouge: scanning Lighthouse Labs

Run a SYN scan with service detection against your lab target(s), save the output with -oA into your 01-recon folder, and write a short paragraph in your journal listing the open ports, the guessed services, and your planned next step for each one. Compare it with the subdomain priority list from the previous lesson: does the scan change your priorities?

Your turn: plan a scan

You are authorised to test a single host, 192.168.56.30, within a two-hour window on a Saturday evening, with the agreement explicitly excluding any denial-of-service risk. Write the exact Nmap command you would run first, and explain each flag you chose.

See a solution

A reasonable first command: sudo nmap -sS -sV -p- -T3 -oA recon/host30 192.168.56.30. -sS performs a SYN scan, fast and reasonably discreet; -sV adds service and version detection to prepare the next phase; -p- covers all TCP ports since you have a full two-hour window and want to avoid missing an unusual port; -T3 is the default, moderate timing template, a safe choice when denial-of-service risk must be avoided, since very aggressive timing could overload a fragile host; -oA saves the results for your report. A UDP scan on a short list of likely ports could follow if time allows.

Tip

An "all ports closed" result is still a result. Write it down. It tells the client that their external firewall is doing its job, which is valuable information too.

Key takeaways

  • Port scanning finds open, closed and filtered ports on a host, as a basis for further testing.
  • TCP connect scans are simple and reliable; SYN scans are faster and leave fewer application-level traces, but need privileges.
  • UDP scanning is slower and less certain, and is usually limited to a targeted list of ports.
  • Service and version detection (-sV) produces hypotheses to confirm, not certainties.
  • Always save scan results to a file and translate them into a prioritised list of next steps.
  • Scanning must stay within the authorised scope, schedule and intensity agreed with the client.

Open ports are only half the story. Next, you will learn to look more closely at what is actually running behind them: banner grabbing.

Advertisement
Log in to save your progress. Log in