Tools such as ZMap and masscan can probe every IPv4 address on the internet for a single open port in under an hour. Search engines such as Shodan and Censys scan continuously and index whatever answers, so a remote desktop port or an admin page put online this morning can show up in their results within days. Attackers don't need to know your company exists; they search for the service and find you.
On the CompTIA Security+ SY0-801 exam this sits under objective 2.4, which expects you to recognize the kinds of vulnerabilities organizations carry and the places attackers find them. This lesson covers open ports and the services behind them, how to read a service scan, default credentials, and the misconfigurations that leave secure products exposed.
Every open port is a running program that anyone who can reach it can talk to
A port is open when a program is listening on it and accepting connections. That program, whether a web server, a file-sharing service or a remote desktop listener, will parse whatever a stranger sends it, and it may also ask for credentials that can be guessed. Every open port therefore adds two things to the attack surface: the bugs in the listening software and the strength of whatever authentication it uses.
Port scanners report three main states. Open means something answered and accepted the connection. Closed means the host answered but nothing is listening. Filtered means no useful answer came back, usually because a firewall dropped the probe. Closed and filtered ports aren't exposures by themselves. Open ones are, and the question for each is whether it needs to be open, and to whom.
Unnecessary services are the easiest exposures to remove. Operating systems and appliances ship with features turned on for convenience, administrators install tools for one task and forget them, and vendors leave diagnostic services running. A service that isn't needed should be disabled or uninstalled, not just blocked at the firewall. A firewall rule can be changed by mistake, and a service that isn't running can't be exploited.
You can list what a host is listening on from the host itself:
$ ss -tlnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1044,fd=6))
LISTEN 0 244 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=990,fd=5))
On Windows, netstat -ano shows the same information. An address of 0.0.0.0 means the service listens on every network interface. The PostgreSQL line is a good sign: bound to 127.0.0.1, the database accepts connections only from the server itself.
A version scan shows what a host is really exposing
From the network side, nmap with the -sV option connects to each open port and compares the responses with a database of service fingerprints to identify the software and often its version. Here is a scan of a workstation that controls a laboratory instrument:
$ sudo nmap -sV 10.20.30.15
Nmap scan report for lab-pc07.corp.example (10.20.30.15)
Host is up (0.00048s latency).
Not shown: 994 closed tcp ports (reset)
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
23/tcp open telnet Microsoft Windows XP telnetd
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Windows XP microsoft-ds
3389/tcp open ms-wbt-server Microsoft Terminal Services
Service Info: OSs: Windows, Windows XP; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_xp