We closed Module 2 with a prioritized attack-surface map and an nmap -sn that told us which hosts on 10.10.10.0/24 are alive. Module 3 begins now, and it's time to really look: we move from "these hosts exist" to "these ports are open on them". An open port is a door that's listening; behind each one sits a service that, in the coming lessons, we'll identify (03-02) and cross-reference against known vulnerabilities (03-03).

This lesson centers on a single question, answered well: which ports are open on the authorized targets? We'll cover the theory of TCP/UDP and port states, the scan types (SYN, connect, UDP, FIN/NULL/Xmas, ACK), speed control and basic noise evasion —always within scope—, and how to squeeze Nmap to discover ports without yet interrogating the services in depth. Before touching anything, let's recall the framing: we scan only the IPs and ranges in the contract, we know that an aggressive scan can take services down and that's why windows are agreed on, and we document every command we launch.

1. Scope reminder: scanning is not harmless
2. TCP and UDP: how a port is discovered
3. Nmap's port states
4. TCP and UDP scan types
5. Selecting ports and targets
6. Timing, speed, and noise evasion
7. Output formats and documentation
8. Scanning TechNova end to end
9. Fast alternatives: masscan and RustScan
10. Defensive counterpart: how a scan is detected
11. Common mistakes and tips
12. Exercises
13. Conclusion

A port scan generates real traffic against production systems. It's not a passive lookup like whois: you're sending thousands of packets to the client's infrastructure. Before the first command, three non-negotiable rules:

• Strict scope. Scan only the IPs and ranges written into the contract. At TechNova: the store and its exposed environments, and the internal network 10.10.10.0/24. An nmap against an unauthorized neighboring IP is, quite simply, illegal.
• Agreed impact. An aggressive scan (-T5, mass UDP scanning, many hosts at once) can saturate a firewall, trip alarms, or take fragile services down. Scan windows are agreed on (e.g. overnight) and the technical contact is notified.
• Document everything. Every command, with its timestamp and its output, is saved. If a service goes down during your window, you must be able to prove exactly what you launched.

Golden rule: if you're unsure whether an IP is in scope, don't scan it and check the RoE.

Discovering ports means sending packets and reading the responses. The two transport protocols behave very differently, and that's why they're scanned differently.

TCP is connection-oriented: it uses the three-way handshake (SYN → SYN/ACK → ACK). That handshake is exactly what scanners exploit:

If the port is open, it responds SYN/ACK; if it's closed, it responds RST (reset); if a firewall filters the packet, it usually sends nothing back (or returns an ICMP prohibited message).

UDP has no handshake: it's "fire and forget". You send a datagram and:

• If the port is closed, the system usually returns an ICMP port unreachable (type 3, code 3).
• If it's open, it often sends nothing back (unless the service answers), which looks just like "filtered". That's why UDP scanning is slow and ambiguous: Nmap has to wait and retry.

Nmap doesn't just say "open/closed". It distinguishes six states, and understanding them prevents wrong conclusions:

The key day-to-day distinction is filtered vs closed: closed means "the host responded, but that port has no service"; filtered means "something (a firewall) ate my packet". Confusing them leads to discarding ports that are actually protected, not absent.

Each technique manipulates the TCP flags differently to extract information. A comparison of the main ones:

A few practical notes:

• -sS (SYN) is the default when run as root. It never completes the connection (it sends RST after the SYN/ACK), so many applications never even log it. It's fast and relatively discreet.
• -sT (connect) uses the connect() system call; it needs no privileges, but it completes the connection, so it almost always shows up in the service's logs. It's the option when you're not root.
• FIN/NULL/Xmas rely on a detail of RFC 793: a closed port replies RST to these "odd" packets and an open one ignores them. They only work against TCP stacks that follow the RFC (not modern Windows) and serve to sneak past stateless firewalls. In an audit, they're used when the SYN scan comes back filtered.
• -sA (ACK) doesn't look for open ports: it aims to learn what the firewall filters. If an ACK gets a RST, the port is unfiltered (the firewall lets it through); if there's no response, it's filtered. It's reconnaissance of rules, not of services.

By default Nmap scans the 1000 most common ports, not all 65535. Controlling which ports and which targets you touch is essential to be efficient and respect scope.

For targets, Nmap accepts single IPs, ranges, CIDR notation, and files:

The file live_hosts.txt is precisely the deliverable from the nmap -sn we closed Module 2 with: the hosts that responded to the ping sweep. Here we reuse it as input.

Scan speed is a balance between speed, stealth, and not breaking anything. Nmap offers timing templates from -T0 to -T5:

In a professional audit, -T3 or -T4 with an agreed window is usually the sensible choice. -T5 can drop packets and take weak devices down; -T0/-T1 are reserved for explicitly agreed IDS evasion tests.

Basic noise evasion —always within the authorized framework, as a technique to measure the client's detection capability— includes:

Important: evasion is not for "scanning without permission without being noticed". It's used to assess whether the client's IDS/IPS detects evasive techniques, and it's always in the contract. Hiding unauthorized activity is a crime, not a technique.

Documenting is mandatory. Nmap saves results in several formats; the most useful for a report is to save to all of them at once with -oA:

• .nmap: human-readable output, to read and paste into the report.
• .gnmap: one line per host, easy to filter with grep (e.g. extract only hosts with 445 open).
• .xml: input for other tools (Metasploit, automated reports).

With a timestamp in the name and these three files per scan, you have the traceability a serious audit demands.

Let's apply all of this to the prioritized list. We start with dev (10.10.10.15), which recon flagged as a poorly secured pre-production environment. First a quick sweep of the most common ports:

Line by line:

• Host is up (0.0012s latency): the host responds; the low latency confirms it's local.
• Not shown: 96 closed tcp ports (reset): of the 100 ports in the quick sweep, 96 returned RST (closed). The host is alive and doesn't filter by default.
• 22/tcp open ssh: SSH open, remote access.
• 80/tcp open http and 8080/tcp open http-proxy: two web services (the app and probably a panel or proxy).
• 3306/tcp open mysql: a MySQL database exposed on a development host! A juicy finding that fits the db-interno we prioritized.

The quick sweep can miss high ports. We confirm with a full scan of all 65535 ports, saving the output:

A 54321/tcp open unknown appears that the quick sweep didn't cover: a non-standard port, possibly a backdoor or a custom administration service. Exactly the kind of finding that justifies -p-. We still don't know what it is: identifying it is the job of 03-02.

Since the store uses DNS and there's a network controller, it's worth a look at UDP on the key ports (not all of them, that would be painfully slow):

The 161/udp open snmp is highly relevant: misconfigured SNMP is a goldmine of internal information (we'll enumerate it in 03-02). The open|filtered on NTP shows the typical UDP ambiguity.

The outcome of this lesson is a table of open ports per host, the raw material for the rest of the module:

For very large ranges, Nmap can be slow. Two complementary tools, useful as a first sweep that you then refine with Nmap:

Impact caution: masscan without --rate can fire millions of packets per second and saturate the client's network or firewall. Always cap the rate and agree on the window. The professional pattern is: masscan/RustScan to discover fast which ports are open, and Nmap for the detail in the following lessons.

Scanning leaves a trace, and a good pentester understands how the defender will see it (this also helps when writing the detection part of the report):

• An IDS/IPS (Snort, Suricata) detects scans by pattern: many SYNs to different ports from a single IP in a short time trips portscan rules. The SYN scan is discreet to the application, but not to a network IDS.
• Stateful firewalls log and can rate-limit connections per IP; a -T5 is noticed immediately.
• NULL/FIN/Xmas scans are anomalous by definition (packets no legitimate client sends), so a modern IDS flags them as suspicious.

Hardening we'll recommend: close everything non-essential (reduces the surface your scan finds), segment the network, expose only what's needed to the Internet, and configure the IDS/IPS to alert and rate-limit scans. The best defense against port discovery is not having open ports you don't need.

• Scanning out of scope. The gravest mistake, with legal consequences. Verify every IP against the RoE before launching.
• Trusting only the default sweep. The top 1000 ports miss services on high ports (dev's 54321). For priority hosts, launch -p-.
• Forgetting UDP. Many scans are TCP-only and miss DNS, SNMP, NTP, or TFTP. Scan at least the UDP --top-ports on key hosts.
• Confusing filtered with closed. filtered isn't "there's nothing here": it's "there's a firewall". Read it as the presence of a defense, not the absence of a service.
• Using -T5 in production. It can take fragile devices down and lose results to dropped packets. -T3/-T4 with an agreed window.
• Not saving the output. Without -oA there's no traceability. Always save, with a timestamp.
• Tip: start fast and broad (-F or masscan), identify the interesting hosts, and go deep only on those with -p-. It saves time and noise.

Exercise 1. You want the most complete possible sweep of TCP ports on TechNova's dev host (10.10.10.15), saving the output in all three formats with the base name dev_full, at aggressive speed. Write the command and explain each option.

Exercise 2. A SYN scan (-sS) against tienda.technova.lab returns every port as filtered, except 80 and 443. What does that tell you about the machine and its network? Which scan would you try to understand the firewall rules, and why?

Exercise 3. Your client asks you to assess whether their IDS detects "stealthy" scans and gives you an overnight window. Propose two Nmap commands aimed at low noise / evasion and explain what each one measures. State which ethical/legal limit you must not cross.

Solution 1.

• -sS: SYN scan (half-open), fast and discreet, needs root.
• -p-: all 65535 TCP ports, not just the default 1000 (so 54321 doesn't slip through).
• -T4: aggressive timing, suitable for a robust local network and an agreed window.
• -oA dev_full: saves to dev_full.nmap, dev_full.gnmap and dev_full.xml (full traceability).

Solution 2. That almost everything is filtered and only 80/443 show open indicates a machine behind a stateful firewall that only allows inbound web traffic: the firewall is "eating" the SYNs to the other ports (hence filtered, not closed). To understand the rules you'd try an ACK scan (-sA): it doesn't look for open ports, but rather distinguishes which ports are filtered (no response) from unfiltered (they return RST), which lets you map what the firewall lets through. It's reconnaissance of the firewall policy, not of services.

Solution 3. Two valid examples:

The first assesses detection of slow scans (below rate thresholds); the second, whether the IDS reassembles fragments to see the scan pattern. The line you cannot cross: all of this is valid only because the client authorized it in writing and within the agreed window. Evasion is never for scanning systems without permission "without being detected": that would be illegal activity, not a test.

We've turned the recon's list of live hosts into something far more concrete: an inventory of open ports per host, obtained in a controlled, documented way and within scope. Along the way we understood how TCP and UDP reveal their ports, the six states Nmap distinguishes (with the crucial filtered/closed distinction), the scan types and when to use each, and how to tune speed and noise without breaking anything or crossing legal lines.

Notice what we still don't know: we've seen that on dev the 3306/tcp is open and labeled mysql, but that's just Nmap's guess based on the port number. We don't know which MySQL version is running, nor what's really behind 54321, nor which web server serves port 80. That leap —from "the port is open" to "this is exactly service X version Y with this information"— is the work of the next lesson.

In 03-02 Service Enumeration we'll take this table of open ports and, with version detection (-sV), operating system detection and per-protocol enumeration (HTTP, SMB, SNMP, MySQL…), build an inventory of services with versions. We'll know not only where it's knocking, but who opens the door.