Server Security Audit with Nmap Port Scanning
A hands-on guide to identifying open ports on production servers using Nmap, detecting service versions, and auditing security vulnerabilities through NSE scripts.
Problem
Required Tools
An open-source network exploration and security auditing tool. Supports TCP/UDP port scanning, OS detection, and service version identification.
A Lua-based Nmap scripting engine that provides advanced scanning capabilities including vulnerability detection, brute force attacks, and service information gathering.
Solution Steps
Quick open port detection with basic TCP connect scan
First, perform the most basic TCP connect scan against the target server. This scan completes the full TCP 3-way handshake, so it does not require root privileges, but it is easily logged. The -T4 option speeds up the scan, and --top-ports targets the most commonly used top 1000 ports.
# Basic TCP connect scan (top 1000 ports)
nmap -sT -T4 --top-ports 1000 192.168.1.100
# Scan a specific port range only
nmap -sT -p 1-65535 192.168.1.100
# Scan multiple hosts at once (CIDR notation)
nmap -sT -T4 192.168.1.0/24Precise port detection with SYN scan (stealth scan)
A SYN scan does not complete the TCP handshake and only checks for SYN-ACK responses, which is why it is also called a "half-open" scan. It is faster than a connect scan and less likely to be logged, making it widely used for security audits. It requires root privileges and is specified with the -sS flag.
# SYN scan (requires root privileges)
sudo nmap -sS -T4 -p- 192.168.1.100
# Save results to XML file (for later analysis)
sudo nmap -sS -T4 -p- -oX scan_result.xml 192.168.1.100
# Save in grep-friendly format as well
sudo nmap -sS -T4 -p- -oA full_scan 192.168.1.100Service version and banner detection
After identifying open ports, determine the exact version of services running on each port. Use the -sV option to detect service versions, and adjust the detection depth with --version-intensity level (0-9). This information is essential for cross-referencing with known CVEs to determine vulnerabilities.
# Service version detection
sudo nmap -sS -sV --version-intensity 5 -p 22,80,443,3306,8080 192.168.1.100
# Example output:
# PORT STATE SERVICE VERSION
# 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.6
# 80/tcp open http nginx 1.18.0
# 443/tcp open ssl OpenSSL 3.0.2
# 3306/tcp open mysql MySQL 8.0.35
# 8080/tcp open http Apache Tomcat 9.0.83OS detection to identify operating system information
Identifying the target system's operating system can be leveraged for OS-level vulnerability audits. Use the -O option to perform OS detection, and adding --osscan-guess will show estimated results even when an exact match is not found. OS detection accuracy may decrease when firewalls or IDS/IPS are present.
# OS detection (requires root privileges)
sudo nmap -O --osscan-guess 192.168.1.100
# Perform service version + OS detection at once
sudo nmap -sS -sV -O -T4 -p- 192.168.1.100
# Aggressive scan (OS + version + scripts + traceroute)
sudo nmap -A -T4 192.168.1.100Automated vulnerability scanning with NSE scripts
The Nmap Scripting Engine (NSE) provides hundreds of built-in scripts, and the vuln category scripts can automatically check for known vulnerabilities. Use the --script option to specify individual scripts or categories. Script execution can place load on the target server, so make sure you have prior authorization before proceeding.
# Run basic vuln category scripts
sudo nmap -sV --script=vuln 192.168.1.100
# SSL/TLS vulnerability checks (Heartbleed, POODLE, etc.)
sudo nmap -sV --script=ssl-heartbleed,ssl-poodle,ssl-enum-ciphers -p 443 192.168.1.100
# HTTP vulnerability checks
sudo nmap --script=http-vuln*,http-enum,http-headers -p 80,443,8080 192.168.1.100
# SMB vulnerability checks (EternalBlue, etc.)
sudo nmap --script=smb-vuln* -p 445 192.168.1.100
# Specific CVE checking script
sudo nmap --script=vulners -sV -p 22,80,443 192.168.1.100Core Code
A Bash script that automates the entire process from full port scanning to vulnerability auditing. Each step saves its results to a separate file for later comparative analysis.
#!/bin/bash
# === Server Security Audit Automation Script ===
# Usage: ./security_scan.sh <target_IP> [output_directory]
TARGET=${1:?"Please provide a target IP"}
OUTDIR=${2:-"./scan_results/$(date +%Y%m%d_%H%M%S)"}
mkdir -p "$OUTDIR"
echo "[1/5] SYN scan - Full port detection..."
sudo nmap -sS -T4 -p- --open -oA "$OUTDIR/syn_scan" "$TARGET"
echo "[2/5] Service version detection..."
OPEN_PORTS=$(grep "open" "$OUTDIR/syn_scan.gnmap" | \
grep -oP '\d+/open' | cut -d/ -f1 | tr '\n' ',' | sed 's/,$//')
sudo nmap -sV --version-intensity 7 -p "$OPEN_PORTS" \
-oA "$OUTDIR/version_scan" "$TARGET"
echo "[3/5] OS detection..."
sudo nmap -O --osscan-guess -oA "$OUTDIR/os_scan" "$TARGET"
echo "[4/5] NSE vulnerability script execution..."
sudo nmap -sV --script=vuln -p "$OPEN_PORTS" \
-oA "$OUTDIR/vuln_scan" "$TARGET"
echo "[5/5] UDP major port scan..."
sudo nmap -sU -T4 --top-ports 100 -oA "$OUTDIR/udp_scan" "$TARGET"
echo "=== Scan complete ==="
echo "Results saved to: $OUTDIR"
echo "Open TCP ports: $OPEN_PORTS"
echo ""
echo "Generate report: xsltproc $OUTDIR/vuln_scan.xml -o report.html"Common Mistakes
Scanning external servers without authorization
Port scanning can be legally problematic. Always obtain written authorization (Penetration Test Agreement) before scanning, and only perform scans on your own or your client's servers. In cloud environments, also check the penetration testing policies of AWS/GCP/Azure and other providers.
Skipping UDP scans and only checking TCP
Important services like DNS (53), SNMP (161/162), NTP (123), and TFTP (69) run on UDP. Always check UDP ports using the -sU option. Since UDP scanning takes a long time, it is practical to limit the range with --top-ports 100.
Not cross-referencing firewall/security group rules with scan results
A "filtered" state in Nmap results means the firewall is dropping packets. Verify whether this is an intentional block or an incorrect rule. Also compare the open ports from scan results with the actual firewall allow list to cross-verify there are no discrepancies.
Scanning with -T5 (Insane) timing and causing service disruptions
When scanning production servers, use -T3 (Normal) or -T4 (Aggressive). -T5 causes packet loss and false positives, and may be blocked by IDS/IPS. It is also a good practice to schedule scans outside of critical service operation hours.