Why Port Scanning Matters
Every TCP and UDP port is a door. An open port means a service is listening. A closed port means a firewall or the OS is actively rejecting connections. A filtered port means something — likely a firewall — is silently dropping packets without any response. Knowing which is which changes how you diagnose and secure a system.
Port scanning is not just for attackers. System administrators use it to verify firewall rules, confirm service availability after deployments, and audit what is actually exposed versus what the configuration files claim. Configuration drift is real — a developer opens port 8080 for testing, forgets it, and it stays open for months.
The Three Port States
When you run a port scan, every target port returns one of three states:
- Open: The service accepted the TCP SYN and replied with SYN-ACK. A three-way handshake completed. Something is listening.
- Closed: The target replied with RST (reset). No service, but the host is reachable and the port is not firewalled.
- Filtered: No reply at all. A firewall, packet filter, or IDS is dropping the probe. You cannot tell if a service is behind it.
A full TCP connect scan is the most reliable but also the noisiest — it completes the handshake and shows up in application logs. A SYN scan (half-open) sends SYN, receives SYN-ACK, then sends RST instead of ACK. The application never sees the connection, but firewalls with stateful inspection will still log it.
Common Ports and What They Reveal
Port 22 (SSH) open on a public IP means remote administration is exposed to the internet. That is normal for a VPS but a red flag on a database server that should be behind a VPN. Port 3306 (MySQL) open to 0.0.0.0 is a common misconfiguration — MySQL binds to localhost by default, but a bind-address = 0.0.0.0 in my.cnf exposes it globally.
Port 25 (SMTP) open without proper authentication means an open relay — spammers scan for this constantly. Port 53 (DNS) open on UDP means the server might be usable as a DNS amplification vector in DDoS attacks if recursion is enabled. Port 6379 (Redis) with no password: attackers scan for this, run FLUSHALL, and drop ransomware notes in your database.
Using the OpsCheck Port Scanner
The OpsCheck Port Scanner checks common service ports from an external perspective — the same view an attacker has. It tests TCP connectivity to the most frequently targeted ports and reports open/closed/filtered status.
Run it against any production host before and after firewall changes. If you expect port 443 open and 22 filtered, the scanner confirms it. If port 3306 shows open when it should be filtered, you caught a misconfiguration before an attacker did.
Combine the port scanner with the Ping Test for a complete picture: ping tells you if the host is alive; the port scanner tells you what services are listening.
Scanning from the Command Line
For quick checks, these one-liners beat launching a full nmap scan:
# Test single TCP port
timeout 3 bash -c 'echo >/dev/tcp/10.0.0.1/22' && echo "open" || echo "closed/filtered"
# Test multiple ports with netcat
for port in 22 80 443 3306 8080; do
nc -zv -w2 10.0.0.1 $port 2>&1
done
# Quick nmap SYN scan of top 100 ports
nmap -sS -T4 --top-ports 100 10.0.0.1The bash /dev/tcp trick is built into the shell — no extra tools needed. It attempts a TCP connection and returns immediately. The timeout wrapper prevents hangs on filtered ports. This is the quickest way to check a single port during an SSH session.
UDP Scanning: The Forgotten Half
Most port scanning focuses on TCP. UDP is harder to scan because there is no handshake — the scanner sends a packet and waits for a reply that may never come. An open UDP port might respond with data (DNS on 53) or might stay silent. A closed UDP port usually returns an ICMP Port Unreachable, but many firewalls suppress that.
# UDP scan requires root and is slow
sudo nmap -sU -p 53,123,161,500 10.0.0.1
# Test DNS specifically
dig @10.0.0.1 google.com +shortCommon UDP targets: 53 (DNS), 123 (NTP), 161 (SNMP), 500 (IPsec/IKE). SNMP with default community strings ("public"/"private") is a goldmine for attackers — it leaks system information, running processes, and network interfaces.
Real Scenario: The Hidden Redis Instance
A SaaS company migrated their API servers to a new cloud provider. The migration checklist included firewall rules, security groups, and application configs. Everything passed QA. Three days later, their Redis cache started returning garbage data.
Investigation: they had spun up a new Redis instance but forgot to set a password. Port 6379 was open to the entire VPC, which included a compromised test VM. An attacker found Redis via automated scanning, connected, and overwrote session keys. The existing monitoring did not alert on Redis because the metrics (connections, memory) looked normal — the attacker was using the database just like the application.
A weekly port scan of the entire subnet would have caught port 6379 open on an unexpected host. The OpsCheck Port Scanner run against every server in the fleet, scheduled weekly, is the cheapest security audit you can implement.
Port Scan Checklist for New Servers
# 1. Scan external IP (what the internet sees)
nmap -sS -p- TARGET_IP
# 2. Scan from internal network (what other servers see)
nmap -sS -p 1-65535 TARGET_INTERNAL_IP
# 3. Check UDP on critical ports
sudo nmap -sU -p 53,123,161,500 TARGET_IP
# 4. Compare with expected list
diff <(nmap -sS --open -p- TARGET_IP | grep '^[0-9]' | awk '{print $1}') expected-ports.txt
# 5. Document everything
nmap -sV -p $(cat open-ports.txt) TARGET_IP > service-versions.txtOpen ports tell a story. Learn to read it, and check it regularly.