Nmap/Short Course/Lecture 2

Main page: Nmap/Short Course

Lab: Nmap/Short Course/Lab 2

Summary and Objective

Summary:

• This 30-minute session will build directly on the host discovery skills from Lecture 1, diving into how to identify what services are listening on discovered hosts.

Objective:

• To enable students to understand and proficiently use Nmap's fundamental TCP and UDP port scanning techniques, accurately interpret port states, and effectively perform service and version detection to identify running applications on target systems.

Notes

Recap & What is Port Scanning?

Quick Recap of Host Discovery

In our last session, we focused on host discovery – the critical first step of figuring out which targets on a network are online and responsive. We explored techniques like Ping Scans (-sn), various ICMP probes (-PE, -PP, -PM), TCP SYN/ACK pings (-PS, -PA), UDP pings (-PU), and ARP scans (-PR) for local networks. Remember, effective host discovery narrows our focus, ensuring we only expend resources on live systems. You should now have lists of active hosts from your initial sweeps of the lab scenarios.

Defining Port Scanning: Knocking on Doors

With a list of live hosts, port scanning is the next logical step. If host discovery tells us which houses in the neighborhood are occupied, port scanning is akin to checking all the doors and windows on those houses to see which ones are open, closed, or perhaps just look suspicious. Technically, a port is a numerical identifier that applications use to differentiate network traffic and services on a host. Port scanning uses Nmap to send specially crafted packets to target ports and analyze the responses (or lack thereof) to determine their status. This helps us identify which services (like web servers, mail servers, databases, etc.) are potentially running on a target machine.

Why Port Scanning is the Next Logical Step

Identifying open ports is crucial because these represent potential entry points into a system. An open port means a service is listening, and that service could be misconfigured, unpatched, or inherently vulnerable. Understanding the "attack surface" presented by these open ports is fundamental for both offensive reconnaissance (finding weaknesses) and defensive auditing (identifying and mitigating risks). Without port scanning, we'd only know a host is alive, not what it's actually doing or offering to the network.

Understanding Ports and Port States

Brief Overview of TCP vs. UDP Ports

Network services use two primary transport protocols: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). TCP is a connection-oriented protocol; it establishes a session (like a phone call) and ensures reliable data delivery with features like acknowledgments and retransmissions. Services like web Browse (HTTP/HTTPS), SSH, and FTP use TCP. UDP, on the other hand, is connectionless and offers faster, low-overhead data delivery but without guarantees of reliability or order. It's like sending a postcard – you send it but don't get confirmation it arrived. Services like DNS, DHCP, SNMP, and many online gaming protocols use UDP. Each host has 65,535 potential TCP ports and another 65,535 potential UDP ports.

Commonly Scanned Ports

Scanning all 65,535 TCP and all 65,535 UDP ports on every host is extremely time-consuming. Nmap helps by focusing on commonly used ports. By default, Nmap scans the 1000 most popular TCP ports. If you want a quicker scan, you can use the -F (Fast scan) option, which scans the 100 most common TCP ports. You can also specify custom port ranges with the -p option (e.g., -p 1-1024, -p U:53,T:80,443, -p- for all ports).

# Scan default 1000 TCP ports (if host is up)
nmap <target_IP>

# Fast scan (top 100 TCP ports)
nmap -F <target_IP>

# Scan specific TCP ports
nmap -p 22,80,443 <target_IP>

# Scan specific UDP ports
nmap -sU -p 53,161 <target_IP>

# Scan all 65,535 TCP ports (can be very slow!)
nmap -p- <target_IP>

Nmap's Six Port States Explained

Nmap categorizes ports into six states, and understanding these is crucial for interpreting scan results:

1. Open: An application is actively accepting TCP connections, UDP datagrams, or SCTP associations on this port. These are often the primary interest as they indicate running services.
2. Closed: A port is accessible (it receives and responds to Nmap's probe packets), but there is no application listening on it. Useful for showing that a host is up but not offering a particular service. They can also be helpful in OS detection.
3. Filtered: Nmap cannot determine whether the port is open or closed because packet filtering (e.g., a firewall, router rule, or host-based firewall software) prevents its probes from reaching the port. Nmap often retries several times if it suspects filtering. These can be frustrating but indicate a hardened target.
4. Unfiltered: This state means that a port is accessible, but Nmap is unable to determine whether it is open or closed. Only the ACK scan (-sA) classifies ports this way. It indicates that the port responded to Nmap's probes in a way that doesn't differentiate between open or closed, often meaning a firewall is present but not blocking the ACK packet itself.
5. Open|filtered: Nmap is unable to determine whether a port is open or filtered. This happens for scan types where open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. This is common for UDP scans and some advanced TCP scans.
6. Closed|filtered: Nmap is unable to determine whether a port is closed or filtered. This state is only used by the IP ID Idle Scan (-sI).

Core TCP Scanning Techniques

These are the workhorses for TCP port scanning.

TCP SYN Scan (-sS) - The Stealthy Default

The TCP SYN scan (-sS) is Nmap's default scan type when run by a privileged user (e.g., root on Linux/macOS, Administrator on Windows) and is often the most popular scan. It's sometimes called "half-open" scanning because it doesn't complete the full TCP three-way handshake. Nmap sends a TCP packet with the SYN (synchronize) flag set to the target port.

• If the port is open, the target responds with a SYN/ACK (synchronize/acknowledge) packet. Nmap then sends an RST (reset) packet to tear down the connection before it's fully established, often preventing the application from logging the connection.
• If the port is closed, the target responds with an RST packet.
• If no response is received after retransmissions, or an ICMP unreachable error is received, the port is marked as filtered. Pros: Relatively stealthy (less likely to be logged by applications), efficient, and differentiates well between open, closed, and filtered states. Cons: Requires raw packet privileges. Some sophisticated IDS/IPS systems can still detect SYN scans.

# Perform a TCP SYN scan (requires sudo/root)
sudo nmap -sS <target_IP>

# SYN scan specific ports
sudo nmap -sS -p 21,22,23,25,80,443 <target_IP>

[Instructor: Run 'sudo nmap -sS <your_lab_target_IP_with_known_open_closed_filtered_ports>' and show output]
Starting Nmap X.XX ( https://nmap.org ) at YYYY-MM-DD HH:MM ZONE
Nmap scan report for <target_IP>
Host is up (0.0XXs latency).
Not shown: XXX closed ports
PORT    STATE    SERVICE
22/tcp  open     ssh
80/tcp  open     http
135/tcp filtered msrpc
Nmap done: 1 IP address (1 host up) scanned in X.XX seconds

TCP Connect Scan (-sT) - The Reliable Alternative

The TCP Connect scan (-sT) is the default scan type if a user lacks raw packet privileges or is scanning IPv6 targets. Instead of crafting raw SYN packets, Nmap asks the underlying operating system to establish a connection with the target host and port by using the connect() system call. This is the same call most network applications use to initiate a TCP connection.

• If connect() succeeds, the port is open, and Nmap immediately closes the connection.
• If connect() fails with an error like "Connection refused," the port is closed.
• If connect() fails due to a timeout or an ICMP unreachable error, the port is marked as filtered. Pros: Works for unprivileged users, very reliable in determining port states. Cons: Slower than a SYN scan because it completes the full three-way handshake, and it's easily detected and logged by target applications as a full connection attempt.

# Perform a TCP Connect scan (can be run by any user)
nmap -sT <target_IP>

# Connect scan a range of ports
nmap -sT -p 1-1024 <target_IP>

[Instructor: Run 'nmap -sT <your_lab_target_IP_with_known_open_closed_filtered_ports>' and show output, compare to -sS if possible]
Starting Nmap X.XX ( https://nmap.org ) at YYYY-MM-DD HH:MM ZONE
Nmap scan report for <target_IP>
Host is up (0.0YYs latency).
Not shown: XXX closed ports
PORT   STATE    SERVICE
22/tcp open     ssh
80/tcp open     http
Nmap done: 1 IP address (1 host up) scanned in Y.YY seconds

Other TCP Scans (Firewall Evasion/Probing)

While we'll cover advanced scan types in a later lecture, it's good to be aware that Nmap offers more nuanced TCP scans, primarily used for trying to understand firewall rule sets or evade simple IDS:

• ACK Scan (-sA): Sends TCP ACK packets. Used to map out firewall rule sets and determine if they are stateful or stateless by seeing which ports return RSTs (unfiltered) versus those that don't respond (filtered). It doesn't determine if a port is open.

• Window Scan (-sW): Similar to ACK scan but can sometimes differentiate open/closed ports on some systems due to anomalies in TCP window size reporting. Rarely effective today.

• FIN (-sF), Xmas (-sX), Null (-sN) Scans: These "stealth" scans send TCP packets with only FIN, FIN+PSH+URG (Xmas), or no flags set (Null). RFC 793 states that closed ports should reply with an RST, while open ports should ignore these packets. However, not all systems are RFC-compliant (e.g., Windows systems typically send RSTs for both open and closed ports to these probes). These are less reliable but can sometimes sneak past non-stateful firewalls or simple IDS.

# Example of an ACK scan (often used to probe firewalls)
sudo nmap -sA <target_IP>

(More details forthcoming in Lecture 3...)

UDP Scanning

The Challenges of UDP Scanning

UDP scanning is generally slower and more difficult than TCP scanning. UDP is connectionless, so there's no equivalent to a TCP three-way handshake. When a UDP packet is sent to an open UDP port, the service may or may not send a response. Many UDP services only respond to correctly formatted application-specific data. However, if a UDP packet is sent to a closed UDP port, the target system should (per RFC) respond with an ICMP "Port Unreachable" (Type 3, Code 3) message. This ICMP error is what Nmap primarily listens for to determine a port is closed.

How Nmap's UDP Scan Works

Nmap sends UDP datagrams (often empty, unless a payload is specified for a specific probe) to each target UDP port.

• If an ICMP Port Unreachable error is received, the port is marked closed.
• If a UDP response is received (from some services like DNS, NTP, or SNMP if Nmap sends a valid probe), the port is marked open.
• If no response is received after several retransmissions, the port is marked open|filtered. This ambiguity arises because the lack of response could mean the port is open and the service isn't responding to an empty/generic probe, or a firewall is dropping the probe.
• If other ICMP unreachable errors are received (like host unreachable, network unreachable), the port is marked filtered.

Reliability, Speed, and When to Use

UDP scans can be very slow because operating systems often rate-limit ICMP error messages. Nmap tries to detect this and slow down accordingly to avoid missing responses, but this significantly increases scan time. Despite the challenges, UDP scanning is essential because many critical and often vulnerable services run over UDP (e.g., DNS (port 53), SNMP (port 161), TFTP (port 69), some VPNs, and various gaming protocols).

# Perform a UDP scan on default common UDP ports (can be slow)
sudo nmap -sU <target_IP>

# UDP scan specific common UDP ports
sudo nmap -sU -p 53,123,161,162 <target_IP>

[Instructor: Run 'sudo nmap -sU -F <your_lab_target_IP_with_known_UDP_ports>' and show output. This might take a while.]
Starting Nmap X.XX ( https://nmap.org ) at YYYY-MM-DD HH:MM ZONE
Nmap scan report for <target_IP>
Host is up (0.0XXs latency).
PORT    STATE         SERVICE
53/udp  open          domain
123/udp open|filtered ntp
161/udp closed        snmp
Nmap done: 1 IP address (1 host up) scanned in XX.YY seconds

Explain the common open|filtered state for UDP and why it occurs.

Service and Version Detection

Why Port Numbers Aren't Enough

While standard port numbers often suggest the service running (e.g., TCP port 80 usually means HTTP), administrators can configure services to run on non-standard ports for obscurity or other reasons. For example, an SSH server (typically on port 22) could be running on port 443. Relying solely on the port number can be misleading. This is where service and version detection comes in.

How Nmap's Version Detection (-sV) Works

When Nmap performs service and version detection (using the -sV option), it doesn't just trust the port number. For every open (or open|filtered for UDP) port, Nmap sends a series of probes from its nmap-service-probes database. These probes are designed to elicit responses that help identify the specific application (e.g., Apache, Microsoft IIS, OpenSSH, vsftpd) and, crucially, its version number. Nmap compares the responses against a database of known service signatures. This process is more intensive than a simple port scan but provides far more valuable information.

Importance and Options

Knowing the exact software and version is critical for security assessments. A specific version of Apache might have a known vulnerability, while a newer version might be patched. This information helps prioritize patching efforts (for defenders) or identify potential exploits (for attackers).

• -sV: Enables version detection.
• --version-intensity [0-9]: Controls the aggressiveness of version detection. Higher numbers use more probes and are more likely to identify services but take longer and are noisier. The default intensity is 7. Intensity 0 is very light, 9 tries all probes.
• --version-light: Alias for --version-intensity 2.
• --version-all: Alias for --version-intensity 9.
• --version-trace: Shows detailed version scanning activity, useful for debugging.

# Perform a SYN scan with service and version detection
sudo nmap -sS -sV <target_IP>

# Perform a more intense version scan on specific ports
sudo nmap -sV --version-intensity 9 -p 80,443 <target_IP>

[Instructor: Run 'sudo nmap -sS -sV -F <your_lab_target_IP>' and show output focusing on the SERVICE and VERSION columns]
Starting Nmap X.XX ( https://nmap.org ) at YYYY-MM-DD HH:MM ZONE
Nmap scan report for <target_IP>
Host is up (0.0XXs latency).
Not shown: XX closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
Nmap done: 1 IP address (1 host up) scanned in X.XX seconds

The VERSION column provides much richer detail than just the port number and SERVICE name.

The lab for this lecture will involve using these scan types to identify services on the lab target hosts and begin enumerating their versions.

Lab

Conduct detailed TCP and UDP port scans on discovered live hosts in all three scenarios. Focus on interpreting port states (open, closed, filtered) and begin detailed service/version enumeration.

Nmap/Short Course/Lab 2