Nmap Port Scanning Techniques

Introduction

30 Second Summary

Every server on the internet listens for connections on numbered ports. Knowing which ports are open tells a security professional exactly what services are running and where the attack surface lies.

In this project, you will use Nmap to perform five different port scanning techniques against an authorized target. You will observe how each technique sends packets differently and classifies port states in distinct ways.

What You'll Build

You will conduct a structured reconnaissance engagement against scanme.nmap.org using SYN, connect, UDP, stealth, and ACK scans, saving results in professional reporting formats.

By the end of this project, you'll have:

• Side-by-side scan results from SYN, connect, UDP, NULL/FIN/Xmas, and ACK scans demonstrating how each technique classifies port states differently.
• Professional-format scan output files (normal, XML, grepable) ready for inclusion in a penetration testing report.
• A clear mental model of which scan technique to reach for in different engagement scenarios.
• Secret Mission: Use the Nmap Scripting Engine to run vulnerability detection scripts against discovered services.

Are there any prerequisites?

This project assumes you have a basic understanding of TCP/IP networking (the three-way handshake, ports, protocols) and are comfortable with the Linux command line.

You will also need a Linux system with Nmap installed and sudo access for sending raw packets.

Set Up Your Environment

Before scanning any network, you need to confirm your tools work and your environment is organized. A penetration tester who jumps straight into scanning without verifying their setup wastes time debugging tool issues mid-engagement.

In this step, you will verify that Nmap has raw packet privileges, confirm you can reach the authorized target, and create an organized directory structure for your scan results.

In this step, get ready to:

• Verify Nmap is installed and can reach the target with raw packet privileges.
• Create a working directory with subdirectories for each scan type.
• Review the legal authorization for scanning scanme.nmap.org.

Verify Nmap installation and version

Your Linux system should already have Nmap installed. You need to confirm the installation works and check the version number before moving forward.

• Confirm Nmap is installed by running this command:

nmap --version

You should see a version line that starts with Nmap version 7.99 (or another 7.x version). If you see this, Nmap is ready.

Command not found?

If your terminal says nmap: command not found, Nmap is not installed or not on your PATH. Install it with your package manager (for example, sudo apt install nmap on Debian/Ubuntu or sudo dnf install nmap on Fedora/RHEL).

help me install Nmap on my Linux distribution

Now confirm you have raw packet privileges and can reach the practice target. This command runs a quick TCP SYN scan against a single port on the authorized target.

• Test connectivity and sudo access by running this command:

sudo nmap -sS -p 80 scanme.nmap.org

You should see port 80 listed as open. The target runs a web server on that port, so an open result confirms both network connectivity and raw packet privileges.

What does this command do?

The -sS flag tells Nmap to perform a SYN scan, which sends a SYN packet and waits for a response without completing the full TCP handshake. The -p 80 flag limits the scan to port 80 only.

Running with sudo is required because SYN scans need raw packet privileges. Without sudo on Linux, Nmap falls back to a less stealthy connect scan.

Not seeing port 80 as open?

If you see filtered instead of open, your local firewall or network may be blocking outbound connections. Try temporarily disabling your firewall or check if you are behind a restrictive corporate network.

If you get a DNS resolution error, confirm you have internet access by pinging another host first.

help me troubleshoot why my Nmap scan to scanme.nmap.org is not showing port 80 as open

Create a working directory for scan outputs

Penetration testers organize engagement files into separate folders by scan type. This makes it easy to compare results and locate specific outputs when writing the final report.

• Create your project directory structure by running this command:

mkdir -p ~/nmap-recon/{syn,connect,udp,stealth,acl,reports}

What does this command do?

The -p flag tells mkdir to create parent directories as needed. The curly braces expand into six separate subdirectories inside ~/nmap-recon/.

Each subdirectory will hold the output from a different scan technique: SYN scans, connect scans, UDP scans, stealth scans (NULL/FIN/Xmas), ACL mapping (ACK scan), and final reports.

• Confirm the directories were created by running:

ls ~/nmap-recon

You should see six directories listed: acl, connect, reports, stealth, syn, and udp.

Understand the legal context

Before you scan anything in the real world, you need written authorization from the network owner. Scanning without permission can violate computer fraud laws in many jurisdictions.

Why is scanme.nmap.org safe to scan?

The Nmap project maintains scanme.nmap.org specifically as a practice target. The site explicitly states: "You are authorized to scan this machine with Nmap or other port scanners."

The only restriction is volume. The Nmap documentation asks that you do not initiate more than a dozen scans against the host per day. This project uses approximately 8-10 scans, which stays within that limit.

Never scan without authorization

In a real penetration test engagement, always secure written authorization from the target network representatives before initiating any scanning. This project uses an explicitly authorized target, so you are safe to proceed.

Your environment is ready. Next up, you will run your first full TCP SYN scan and compare it with a connect scan to see the difference in stealth and speed.

Run TCP SYN and Connect Scans

Your environment is verified and your directory structure is ready. Now it is time to run your first real scans.

In this step, you will fire two different TCP scan techniques at the same target ports and watch how they behave at the packet level. By comparing a SYN scan (half-open) with a full connect scan, you will see why penetration testers default to one over the other.

In this step, get ready to:

• Run a TCP SYN scan with packet tracing and save the results.
• Run a TCP connect scan against the same ports and save the results.
• Compare both outputs to understand the speed, stealth, and privilege trade-offs.

Run a SYN scan (half-open) with packet tracing

A SYN scan sends a SYN packet to each target port, just like the first step of the TCP three-way handshake. If the port responds with SYN/ACK, Nmap knows it is open and immediately sends RST to tear down the connection. The handshake never completes, so application-level logs on the target rarely record the connection attempt.

• Run this SYN scan against four ports on the authorized target, with packet tracing enabled so you can see each packet:

sudo nmap -sS -p 22,80,443,9929 --packet-trace scanme.nmap.org -oN ~/nmap-recon/syn/syn-scan.txt

What does this command do?

• -sS tells Nmap to use the SYN scan technique (half-open, never completes the handshake).
• -p 22,80,443,9929 targets those four specific ports instead of the default 1,000.
• --packet-trace prints every packet sent and received so you can observe the SYN/SYN-ACK/RST sequence in real time.
• -oN ~/nmap-recon/syn/syn-scan.txt saves the results in normal (human-readable) format.

• Wait for the scan to complete. It typically finishes within a few seconds.
• Confirm the output file was created by running:

cat ~/nmap-recon/syn/syn-scan.txt

You should see a summary table listing each port with its state (open, closed, or filtered) and the service name.

What should I see in the packet trace?

For an open port (like port 80), you will see: Nmap sends SYN, the target replies with SYN/ACK, then Nmap sends RST. The connection never fully opens.

For a closed port, the target replies with RST/ACK immediately. For a filtered port, you see no response at all (the packet is silently dropped by a firewall).

Seeing "permission denied" or no output?

• SYN scans require raw packet privileges. Make sure you included sudo at the start of the command.
• If you see "Failed to resolve" errors, check your internet connection. The target scanme.nmap.org must be reachable.
• If the output file is empty, confirm the directory exists by running ls ~/nmap-recon/syn/.

Why is my SYN scan failing or showing no results?

Run a TCP connect scan against the same ports

A TCP connect scan uses the operating system's connect() syscall to complete the full three-way handshake (SYN, SYN/ACK, ACK) with each port. Because it works through the normal networking stack, it does not require root privileges.

• Run this connect scan against the same four ports with packet tracing:

nmap -sT -p 22,80,443,9929 --packet-trace scanme.nmap.org -oN ~/nmap-recon/connect/connect-scan.txt

What is different about this command?

-sT tells Nmap to use the TCP connect scan technique. Notice there is no sudo at the start. This scan works as a regular unprivileged user because it relies on the OS networking stack rather than crafting raw packets.

• Wait for the scan to complete and then confirm the output file was created:

cat ~/nmap-recon/connect/connect-scan.txt

You should see the same port/state/service table. The port states will match the SYN scan results, but the packet trace will show a full three-way handshake for every open port.

What should I see in this packet trace?

For an open port, you will see: SYN sent, SYN/ACK received, ACK sent (handshake complete), then the connection is closed. The full connection appears in the target's application logs because the handshake finished.

Scan seems slower than the SYN scan?

• This is expected. The connect scan completes the full handshake for each open port, which takes more round trips.
• If the scan hangs, try adding -T4 to the command to use the aggressive timing template.

Why is my TCP connect scan taking longer than my SYN scan?

Compare results and understand the trade-offs

You now have two scan result files that targeted the exact same ports on the same host. Time to put them side by side.

• View both result files back-to-back by running:

echo "=== SYN SCAN ==="
cat ~/nmap-recon/syn/syn-scan.txt
echo ""
echo "=== CONNECT SCAN ==="
cat ~/nmap-recon/connect/connect-scan.txt

Notice that the port states (open, closed, filtered) are identical between both scans. The difference is in how they got there.

What are the key trade-offs?

• Speed: SYN scan is faster because it sends fewer packets per port (no final ACK, no teardown).
• Stealth: SYN scan is stealthier because it never completes a connection. Target applications (web servers, SSH daemons) typically do not log half-open connections. Connect scan leaves a full connection record.
• Privileges: SYN scan requires root/sudo because it crafts raw packets. Connect scan works as any unprivileged user because it goes through the OS networking stack.
• Proxy compatibility: Connect scan works through SOCKS proxies and certain VPN tunnels. SYN scan does not, because raw packets bypass the proxy layer.

When do pen-testers use each scan?

In a real engagement, SYN scan is the default choice. It is the first thing most testers run because it is fast, quiet, and gives reliable results.

Connect scan is your fallback when you lack raw packet privileges or when you are scanning through certain proxies that do not pass raw traffic. Knowing both means you are never stuck.

You have completed the two foundational TCP scan techniques and can explain when each one is the right tool. Next up, you will explore stealth scans that attempt to bypass firewalls entirely.

Run Stealth Scans (NULL and Xmas)

In the previous step, you compared SYN and TCP connect scans to see how they differ in privilege requirements and stealth.

Both of those scans rely on the TCP handshake to determine port state. But what if a firewall only blocks SYN packets? NULL and Xmas scans exploit a loophole in RFC 793 to slip past non-stateful packet filters entirely. In this step, you will run both scan types and learn why they report ports differently than your SYN scan did.

In this step, get ready to:

• Run a NULL scan that sends TCP packets with zero flags set.
• Run a Xmas scan that lights up the FIN, PSH, and URG flags.
• Compare results with your SYN scan to understand the trade-offs.

Run a NULL scan

A NULL scan sends a TCP packet with no flags set at all. According to RFC 793, a closed port must respond with a RST packet to any segment that does not contain SYN, RST, or ACK. An open port should silently drop it.

This means Nmap classifies ports that respond with RST as closed, and ports that give no response as open|filtered.

• Run the NULL scan against the same four ports you used for your SYN and connect scans:

sudo nmap -sN -p 22,80,443,9929 scanme.nmap.org -oN ~/nmap-recon/stealth/null-scan.txt

What does this command do?

• -sN tells Nmap to perform a NULL scan (TCP flag header is 0, no bits set).
• -p 22,80,443,9929 targets the same ports you scanned earlier so you can compare results directly.
• -oN ~/nmap-recon/stealth/null-scan.txt saves output in normal format to your stealth directory.

• Wait for the scan to complete. You should see ports classified as open|filtered (no response received) or closed (RST received).

Why do open ports show as open|filtered?

When a port is truly open, it silently drops the NULL packet and sends nothing back. A firewall filtering that port would also send nothing back. Nmap cannot tell the difference, so it reports open|filtered.

This is the fundamental trade-off of NULL scans. You gain stealth against simple packet filters, but you lose the ability to definitively confirm a port is open.

All ports showing as closed?

If every port comes back as closed, the target might be running a non-RFC-compliant stack (like Windows) that sends RST regardless of port state. Since scanme.nmap.org runs Linux, you should see open|filtered for at least some ports.

Make sure you ran the command with sudo. NULL scans require raw packet privileges.

Help me troubleshoot my NULL scan results.

Run a Xmas scan

A Xmas scan sets the FIN, PSH, and URG flags simultaneously. It is called "Xmas" because these flags light up the packet header like a Christmas tree. The classification logic is identical to the NULL scan.

• Run the Xmas scan against the same ports:

sudo nmap -sX -p 22,80,443,9929 scanme.nmap.org -oN ~/nmap-recon/stealth/xmas-scan.txt

What does this command do?

• -sX tells Nmap to perform a Xmas scan (FIN, PSH, and URG flags all set).
• The response interpretation is the same as the NULL scan: RST means closed, no response means open|filtered, and ICMP unreachable means filtered.
• Results are saved to ~/nmap-recon/stealth/xmas-scan.txt.

• Wait for the scan to finish. Your results should look very similar to the NULL scan output.

Scan taking a long time?

NULL and Xmas scans wait for responses that may never arrive (since open ports stay silent). Nmap retransmits probes before giving up on each port. Four ports should still finish within a few seconds.

If it stalls, confirm your network connection is stable and that scanme.nmap.org is reachable.

Help me figure out why my Xmas scan is hanging.

• Confirm both scan files exist by running:

ls ~/nmap-recon/stealth/

• You should see null-scan.txt and xmas-scan.txt listed in the output.

Compare with your SYN scan results

You now have three different scans of the same four ports. Comparing them reveals why penetration testers keep multiple scan techniques in their toolkit.

• View your SYN scan results for reference by running:

grep -E "open|closed|filtered" ~/nmap-recon/syn/syn-scan.txt

• Now view your NULL scan results by running:

grep -E "open|closed|filtered" ~/nmap-recon/stealth/null-scan.txt

Notice the difference. Your SYN scan clearly labelled ports as open, closed, or filtered. Your NULL scan can only say open|filtered or closed.

Why can't NULL/Xmas scans tell open from filtered?

Both open ports and firewall-filtered ports produce the same result: silence. An open port drops the weird packet and says nothing. A filtering firewall also drops it and says nothing. Nmap has no way to distinguish these two cases.

SYN scans do not have this problem because open ports actively respond with SYN/ACK. That positive confirmation is what makes SYN scans the default choice.

When would a pen-tester choose these scans?

NULL and Xmas scans exist to bypass non-stateful firewalls. A simple packet filter that only blocks incoming SYN packets will let NULL and Xmas probes through, because those probes contain no SYN flag.

Modern stateful firewalls track connection state and block any packet that does not belong to an established session. Against these firewalls, NULL and Xmas scans are unreliable. Many OS stacks (especially Windows, Cisco devices, and BSDI) also respond with RST regardless of port state, making every port look closed.

These scans are still important to understand for certification exams (OSCP, CEH, CompTIA Security+) and for engagements against legacy environments with simple packet filters.

You now understand how stealth scans trade accuracy for evasion. Next up, you will use an ACK scan to map firewall rules and a UDP scan to find services that TCP scans miss entirely.

Run ACK and UDP Scans

You now have results from SYN, connect, NULL, and Xmas scans. Each of those scans answered the same question: is this port open or closed?

In this step, you will run two scans that answer completely different questions. The ACK scan reveals whether a firewall is filtering a port, without caring if the port is open or closed. The UDP scan discovers services that every TCP scan you have run so far misses entirely.

In this step, get ready to:

• Run an ACK scan to map firewall rules on the target.
• Run a UDP scan to find services invisible to TCP scans.
• Understand when each scan type matters during a real engagement.

Run an ACK scan to map firewall rules

Every scan you have run so far tells you whether a port is open or closed. The ACK scan asks a different question: is a firewall sitting between you and this port?

It works by sending a packet with only the ACK flag set. A port behind no firewall responds with RST (classified as unfiltered). A port blocked by a firewall gives no response or an ICMP error (classified as filtered).

• Run the ACK scan against the same four ports you used in previous steps by running this command:

sudo nmap -sA -p 22,80,443,9929 scanme.nmap.org -oN ~/nmap-recon/acl/ack-scan.txt

What does this command do?

• -sA tells Nmap to perform a TCP ACK scan. It sends packets with only the ACK flag set to each target port.
• Ports that respond with RST are classified as unfiltered. This means traffic reaches the port without a firewall blocking it.
• Ports with no response or an ICMP error are classified as filtered. A firewall is actively dropping or rejecting the probe.
• -oN ~/nmap-recon/acl/ack-scan.txt saves the results in normal (human-readable) format.

• Wait for the scan to complete. It should finish within a few seconds.
• Look at the output in your terminal. You should see each port listed as either unfiltered or filtered.

Why does the ACK scan not show open or closed?

The ACK scan cannot tell you if a port is open or closed. It only reveals whether a firewall is filtering traffic to that port.

Penetration testers use this to map firewall rulesets before choosing their attack vector. If you know port 443 is unfiltered while port 22 is filtered, you know to focus your efforts on 443.

• Confirm the output file was saved by running:

ls ~/nmap-recon/acl/

You should see ack-scan.txt listed in the output.

All ports showing as filtered?

If every port shows as filtered, your local network firewall may be blocking outbound ACK-only packets. Try running the scan from a different network or check if your ISP uses strict egress filtering.

Make sure you included sudo at the start. The ACK scan requires raw packet privileges just like the SYN scan.

Still stuck? Help me troubleshoot why my ACK scan shows all ports as filtered.

Run a UDP scan on common service ports

Every scan you have run in this project uses TCP. But many critical network services run exclusively on UDP: DNS (port 53), NTP (port 123), SNMP (port 161), and VPN services (port 500).

UDP has no handshake, so Nmap cannot rely on SYN/ACK responses. Instead, it sends UDP probes and listens for ICMP "port unreachable" errors (meaning closed) or silence (meaning open|filtered).

• Run a UDP scan against four common UDP service ports by running this command:

sudo nmap -sU -p 53,123,161,500 scanme.nmap.org -oN ~/nmap-recon/udp/udp-scan.txt

What does this command do?

• -sU tells Nmap to perform a UDP scan instead of TCP.
• -p 53,123,161,500 targets DNS (53), NTP (123), SNMP (161), and IKE/VPN (500).
• Ports that respond with an ICMP "port unreachable" error are classified as closed.
• Ports with no response are classified as open|filtered because Nmap cannot tell the difference between a port that accepted the packet silently and one filtered by a firewall.

• Wait for the scan to complete. UDP scans are significantly slower than TCP scans because Nmap must wait for timeout periods on each port.
• Look at the output in your terminal. You should see ports classified as open, closed, or open|filtered.

• Confirm the output file was saved by running:

ls ~/nmap-recon/udp/

You should see udp-scan.txt listed in the output.

Scan taking a very long time?

UDP scans are inherently slow because there is no handshake to confirm delivery. Nmap waits for ICMP errors or timeouts on each port. Four ports should complete within 30-60 seconds, but network conditions can stretch this.

If it hangs for more than two minutes, press Enter to see Nmap's progress indicator. Do not press Ctrl+C unless you want to abort.

Need help? My UDP scan is taking too long. What can I do?

Understand when each scan matters

You now have results from two scans that serve fundamentally different purposes than the port-state scans from earlier steps.

• Compare your ACK scan results with your SYN scan results by running:

cat ~/nmap-recon/acl/ack-scan.txt
cat ~/nmap-recon/syn/syn-scan.txt

What's the difference between these results?

The SYN scan tells you "this port is open" or "this port is closed." The ACK scan tells you "a firewall is (or is not) blocking traffic to this port." They answer completely different questions about the same target.

In a real penetration test, you use the ACK scan to answer "is a firewall filtering this port?" before deciding which attack vector to pursue.

When does each scan type matter in a real engagement?

• ACK scan: use it to map firewall rulesets. If you know which ports are unfiltered, you know where to focus exploitation attempts.
• UDP scan: critical for finding DNS, SNMP, NTP, and VPN services that TCP scans miss entirely. Many junior pen-testers skip UDP scanning. Senior testers know that SNMP (161) and DNS (53) on UDP are often the path of least resistance into a network.

You have now mapped firewall rules with ACK and discovered UDP services that TCP scans would have missed completely. Next up, you will pull everything together into professional reporting formats that pen-test teams actually deliver to clients.

Save Professional Scan Output

You've mapped firewall rules with ACK scanning and uncovered UDP services that TCP scans miss entirely. Your ~/nmap-recon/ directory now holds results from five distinct scanning techniques.

In a real penetration test, raw terminal output alone is not enough. Clients, teammates, and reporting frameworks all need scan data in specific machine-parseable formats. In this step, you'll run a comprehensive scan that saves results in three professional formats simultaneously.

In this step, get ready to:

• Run a comprehensive SYN scan with service version detection and save output in three formats.
• Parse grepable output to quickly extract open port findings.
• Review XML output structure used by reporting frameworks.

Run a comprehensive scan with all three output formats

The -oA flag tells Nmap to save results in three formats at once: normal text, XML, and grepable. Combined with -sV for service version detection, this produces the complete output that pen-test reporting tools expect.

• Run a comprehensive scan with service version detection against scanme.nmap.org by running this command:

sudo nmap -sS -sV -p- --top-ports 1000 -T4 -oA ~/nmap-recon/reports/full-scan scanme.nmap.org

What does this command do?

• -sS performs a TCP SYN scan (the fast, stealthy half-open technique you practiced in Step 2).
• -sV probes open ports to determine what service software and version is running on each one.
• --top-ports 1000 targets the 1000 most commonly used ports based on Nmap's empirical frequency data.
• -T4 uses the aggressive timing template for faster results on a reliable network.
• -oA ~/nmap-recon/reports/full-scan saves results in all three output formats simultaneously, using full-scan as the base filename.

Why three output formats?

The .nmap file is human-readable (normal format). The .xml file integrates with tools like Metasploit, Dradis, and other reporting frameworks. The .gnmap file is designed for scripting and automation with tools like grep and awk.

• Wait for the scan to complete. This may take a few minutes because version detection (-sV) sends additional probes to each open port.
• Confirm the three output files were created by running:

ls ~/nmap-recon/reports/

You should see three files: full-scan.nmap, full-scan.xml, and full-scan.gnmap.

Only seeing one or two files?

• Make sure you used -oA (all formats), not -oN (normal only) or -oX (XML only).
• Check that the ~/nmap-recon/reports/ directory exists. If it does not, create it with mkdir -p ~/nmap-recon/reports and rerun the scan.
• If the scan is still running, wait for it to finish. Version detection adds time. Help me troubleshoot missing output files

Parse the grepable output

Penetration testers often deal with scans of hundreds or thousands of hosts. The grepable format lets you quickly extract specific findings without reading through pages of output.

• Extract all open port entries from the grepable output by running:

grep "open" ~/nmap-recon/reports/full-scan.gnmap

What does this show you?

The grep command filters the grepable file down to only the lines containing open ports. Each line lists a host and all its open ports in a single parseable string.

In a real engagement with hundreds of targets, you would pipe this output into scripts that automatically feed open ports into further tools. This is how pen-testers scale from manual reconnaissance to automated engagement pipelines.

You should see output lines containing port numbers followed by their state and service name, all on a single line per host.

No output from grep?

• Verify the file exists by running ls ~/nmap-recon/reports/full-scan.gnmap. If it does not exist, your scan may not have completed.
• Check that the file has content by running cat ~/nmap-recon/reports/full-scan.gnmap. An empty file means the scan was interrupted.
• Help me figure out why my grepable file is empty

Review the XML output structure

The XML format is what professional reporting frameworks ingest. Tools like Metasploit and Dradis parse this structured data to auto-populate vulnerability reports.

• View the first 50 lines of the XML output to see its structure by running:

head -50 ~/nmap-recon/reports/full-scan.xml

What does the XML structure tell you?

The XML output wraps every scan detail in structured tags: host addresses, port states, service names, and version strings all have their own elements. This makes it trivial for other tools to parse specific data points programmatically.

Employers expect penetration testers to produce machine-parseable output. Manual-only scanning with no structured exports is a red flag in interviews and client engagements.

You should see XML tags like <host>, <ports>, <port>, and <service> organizing the scan data into a parseable hierarchy.

Seeing an empty or very short XML file?

• If the file contains only an XML header and no <host> elements, the scan may have failed to reach the target. Rerun the scan and confirm you can reach scanme.nmap.org first.
• Check that the scan completed fully. An interrupted scan may produce a partial XML file missing its closing tags.
• Help me troubleshoot my incomplete XML output

Secret mission

NSE Vulnerability Detection

You've mastered five scanning techniques for discovering open ports and mapping firewall rules. But knowing a port is open is only the beginning. The Nmap Scripting Engine (NSE) lets you actively probe those services for known vulnerabilities, extracting the kind of findings that turn a scan report into actionable intelligence.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally, so there are no ongoing costs. Decide whether to keep your scan output files for future reference or delete them entirely.

Resources you used:

• Local scan output directory: ~/nmap-recon/ (contains SYN, connect, UDP, stealth, ACL, and report output files).

Keep everything running

No action needed. Choose this if you plan to revisit the scan results for study, exam prep, or to compare with future scans.

• Your scan files stay in ~/nmap-recon/ and take up minimal disk space.
• You can re-read any output file with cat or open them in a text editor whenever you need them.

Pause - I'll come back to this later

Since these are local text files with no running processes, there is nothing to pause. Your files remain on disk until you choose to delete them.

• No services or daemons were started during this project.
• The files consume negligible disk space and have no ongoing resource usage.

Delete - I don't want to use this again

Remove all project files and start fresh. This permanently deletes every scan output you generated.

• Delete the entire scan output directory by running:

rm -rf ~/nmap-recon/

• Confirm deletion by running:

ls ~/nmap-recon/

You should see a "No such file or directory" message confirming the folder is gone.

Nice Work!

Nice Work!

You just completed a structured port scanning engagement using five distinct Nmap techniques against a live target. You now have a working directory of professional scan reports that demonstrate real penetration testing methodology.

You've learned how to:

• Conduct TCP SYN, connect, NULL/Xmas, ACK, and UDP scans and identify when each technique is the right choice during a penetration test.
• Interpret Nmap's six port states (open, closed, filtered, unfiltered, open|filtered, closed|filtered) and understand what each reveals about a target's security posture.
• Save scan results in all three professional reporting formats (normal, XML, grepable) ready for integration with tools like Metasploit and Dradis.
• Secret Mission: Used the Nmap Scripting Engine to probe for vulnerabilities and extract service information beyond basic port states.

Ready to quiz yourself?