Port Scanning Explained: What Open Ports Reveal About Your Attack Surface

Introduction

An open port is not automatically a vulnerability. It is evidence that something on a host is listening for traffic. The risk depends on what service is listening, who can reach it, whether authentication is enforced, and whether the software is current.

That distinction matters because attackers usually do not start with a CVE. They start by finding reachable services. A database port exposed to the internet, an admin interface running on a non-standard web port, or an old remote access service can become the first useful signal in reconnaissance.

Public reporting in early 2017 described tens of thousands of exposed MongoDB databases being wiped and replaced with ransom notes. The common condition was not a sophisticated exploit chain. The databases were reachable from the internet and were not protected with effective access control.

This post explains how port scanning works, what open ports reveal, how exposed services become risk, and how to assess your own infrastructure from a defensive external vantage point.

How port scanning works at the protocol level

A port is a 16-bit number in the TCP or UDP transport layer header. Each protocol has ports from 0 to 65535. Well-known ports such as 22, 53, 80, and 443 are associated with common services, but any service can run on almost any port.

TCP uses a connection handshake. TCP was originally specified in RFC 793 and later consolidated in RFC 9293. A client sends a SYN packet. If the port is open, the server responds with SYN-ACK. If the port is closed, the server usually responds with RST. If packets are dropped or filtered, the scanner may see no response.

That response pattern is enough to classify many TCP ports as open, closed, or filtered. Open means a service is listening. Closed means the host is reachable but nothing is listening on that port. Filtered means a firewall, security group, or network device is preventing the scanner from determining the state cleanly.

UDP is harder because it has no handshake. A UDP service may respond, or it may stay silent even when the port is open. A closed UDP port often returns an ICMP Port Unreachable message, but firewalls and rate limits can suppress that. This is why UDP scanning is slower and less certain than TCP scanning.

What the vulnerable configuration looks like

Port exposure usually comes from two mistakes happening together. First, a service is bound to an address that accepts network traffic. Second, a firewall or cloud security group allows that traffic from the internet.

The service may have been intended for internal use only. The exposure appears when it is deployed on a public host, bound to all interfaces, or placed behind a permissive security group.

• Vulnerable: Redis reachable from the internet — Redis is designed to run in a trusted network. Exposing it to the public internet with weak or missing authentication creates direct data and command exposure risk. The risky pattern is a Redis service reachable on 0.0.0.0 with inbound access allowed from public IP ranges.

  # /etc/redis/redis.conf — vulnerable pattern
  bind 0.0.0.0
  protected-mode no
  
  # Firewall pattern — vulnerable
  # Public inbound access to Redis should not be allowed
  -A INPUT -p tcp --dport 6379 -j ACCEPT

• Secure: Redis restricted to local or trusted networks — A safer configuration binds Redis to localhost or a trusted private interface, requires authentication, and blocks public inbound access at the firewall or cloud security group.

  # /etc/redis/redis.conf — safer pattern
  bind 127.0.0.1
  protected-mode yes
  requirepass CHANGE_TO_A_STRONG_SECRET
  
  # Firewall pattern — safer
  # Allow only trusted private application subnet if network access is required
  -A INPUT -p tcp -s 10.0.1.0/24 --dport 6379 -j ACCEPT
  -A INPUT -p tcp --dport 6379 -j DROP

• Vulnerable: MongoDB reachable with authorization disabled — The risky MongoDB pattern is a database service reachable from the public internet while authentication or authorization is disabled or ineffective. Do not treat public reachability as safe just because the service is not linked from a website.

  # /etc/mongod.conf — vulnerable pattern
  net:
    bindIp: 0.0.0.0
    port: 27017
  security:
    authorization: disabled

• Secure: MongoDB bound privately with authorization enabled — A safer configuration binds MongoDB to localhost or private interfaces, enables authorization, and restricts network access to trusted application hosts.

  # /etc/mongod.conf — safer pattern
  net:
    bindIp: 127.0.0.1
    port: 27017
  security:
    authorization: enabled

• Vulnerable: RDP open to the internet — Remote Desktop Protocol on port 3389 should usually not be reachable from the public internet. Even when patched, internet-facing RDP attracts brute-force, password spraying, and vulnerability scanning.

  # Risky cloud security group pattern
  Protocol: TCP
  Port: 3389
  Source: 0.0.0.0/0

• Secure: RDP behind VPN or trusted access path — A safer pattern is to require VPN, zero-trust access, bastion access, or tightly restricted source IPs. Public 0.0.0.0/0 access should not be used for administrative services.

  # Safer security group pattern
  Protocol: TCP
  Port: 3389
  Source: trusted-vpn-cidr-only
  
  # Better pattern
  No direct public RDP access; require VPN, bastion, or zero-trust access.

Scan types and what each one reveals

Different scan types answer different defensive questions. A fast TCP scan tells you which ports are reachable. A service detection scan tells you what appears to be running. A UDP scan checks services that TCP-only scanning misses.

Run these only against infrastructure you own or have explicit written authorization to test.

• TCP SYN scan — A SYN scan sends SYN packets and records the response without completing a full application session. It is fast and useful for identifying reachable TCP ports on approved targets.

  nmap -sS -p 1-1000 scanme-owned.example.com

• TCP connect scan — A connect scan completes the TCP handshake. It works without raw socket privileges, but it is usually noisier in logs because a full connection is opened.

  nmap -sT -p 22,80,443 scanme-owned.example.com

• Service version detection — After finding open ports, service detection sends protocol-specific probes to identify the service and visible version. Treat version output as evidence, not final patch truth. Some vendors backport fixes without changing the visible version string.

  nmap -sV -p 22,80,443,3306,5432,6379,9200,27017 scanme-owned.example.com

• UDP scan — UDP scanning is slower and less certain because no response can mean open, filtered, or dropped. Still, UDP matters for services such as DNS, NTP, SNMP, VPN, and discovery protocols.

  nmap -sU -p 53,123,161,500,1194 scanme-owned.example.com

• High-speed scan for owned IP ranges — High-speed scanners such as masscan or naabu can check large owned ranges quickly. Use conservative rates, written authorization, and approved network windows. Do not scan third-party networks.

  naabu -list owned-ip-ranges.txt -p 22,80,443,3306,5432,6379,9200,27017,3389 -rate 500 -o exposed-ports.txt

What specific open ports reveal

The port number gives an attacker a first guess. The banner, TLS certificate, protocol response, or web content confirms the service and adds context.

Do not assume a service is safe because it runs on a non-standard port. Attackers routinely scan all ports because hidden admin tools and developer services often live outside 80 and 443.

• Port 22: SSH — SSH exposure reveals that remote administration is reachable. Version banners may reveal OpenSSH or vendor-specific versions, but visible versions do not always prove patch state. The main defensive checks are whether password login is disabled, root login is disabled, MFA or bastion access is used where appropriate, and source IPs are restricted.

• Port 23: Telnet — Telnet sends traffic in plaintext and should not be exposed to the public internet. It still appears on legacy systems, embedded devices, and network equipment. Replace it with SSH or disable remote access entirely.

• Ports 80 and 443: HTTP and HTTPS — Web ports reveal applications, headers, login panels, API endpoints, technologies, redirects, cookies, and TLS posture. The risk is not the port itself. The risk is what the web application exposes through that port.

• Port 3306: MySQL — Public MySQL exposure is usually a mistake. The service may leak version details during handshake, and authentication may be tested by scanners. MySQL should normally be reachable only from trusted application hosts or private networks.

• Port 5432: PostgreSQL — PostgreSQL exposure depends heavily on pg_hba.conf, user roles, authentication method, and network controls. A trust rule for broad source ranges is dangerous, but actual access still depends on the requested user, database, and role configuration.

• Port 6379: Redis — Redis should not be exposed directly to the public internet. Risk increases when authentication is weak or missing, protected mode is disabled, or dangerous commands are available to untrusted clients.

• Port 9200: Elasticsearch — Elasticsearch on port 9200 exposes an HTTP API. If access control is missing or misconfigured, index names, documents, cluster health, and administrative actions may be reachable. Put it behind private networking and enforce authentication.

• Port 27017: MongoDB — MongoDB on port 27017 should not be publicly reachable unless intentionally designed, authenticated, encrypted, and restricted. The dangerous pattern is public reachability combined with disabled or ineffective authorization.

• Port 3389: RDP — RDP exposure is high-risk because it supports interactive remote access and has a long history of brute-force targeting and critical vulnerabilities. BlueKeep, CVE-2019-0708, showed how serious pre-authentication RDP flaws can be when RDP is reachable from the internet.

• Ports 8080 and 8443: development and admin web interfaces — These ports commonly host development servers, reverse proxies, dashboards, admin tools, Jenkins, Tomcat, staging apps, or internal panels. Many are deployed with weaker controls because they were assumed to be internal.

How exposed ports become risk

Port scanning alone does not compromise a system. It gives the defender or attacker a list of reachable services to investigate.

A safe defensive workflow starts with reachability. Identify which ports respond from an external vantage point. Then fingerprint the service enough to understand what it is and who owns it.

Next, verify exposure intent. Ask whether the service should be reachable from the public internet at all. If the answer is no, block it before spending time on deeper testing.

If the service must be public, validate the controls. Check authentication, access restrictions, TLS configuration, patch status, logging, and ownership. Use approved vulnerability scanning or host-level evidence to confirm patch state rather than relying only on banners.

The output should be a remediation queue: close unnecessary ports, restrict administrative services, enforce authentication, validate patch status, and retest from outside.

• Defensive workflow from discovery to remediation — Use this as a safe sequence for owned infrastructure.

  # 1. Identify reachable ports on an owned target
  nmap -Pn -p 1-1000 owned-host.example.com
  
  # 2. Fingerprint only the ports that are open
  nmap -sV -sC -p 22,80,443 owned-host.example.com
  
  # 3. Check whether risky database ports are reachable
  nmap -Pn -p 3306,5432,6379,9200,27017 owned-host.example.com
  
  # 4. Save results for review
  nmap -sV -p 22,80,443,3306,5432,6379,9200,27017 -oN owned-host-port-review.txt owned-host.example.com
  
  # 5. After remediation, retest from an external network
  nmap -Pn -p 3306,5432,6379,9200,27017 owned-host.example.com

How to detect port exposure in your environment

Run scans from a network that is not allowlisted. If you scan from a corporate VPN or internal jump box, you may see a different exposure profile than the public internet sees.

Use more than one data source. Active scans show current reachability. Search indexes such as Shodan or Censys show what has recently been observed from internet-wide scanning. Cloud security groups show intended policy. The gap between these sources is where mistakes hide.

• External scan with nmap — Start with common ports, then expand if the host is in scope and approved for testing.

  # Common ports
  nmap -Pn --top-ports 1000 owned-host.example.com
  
  # Full TCP port range when approved
  nmap -Pn -p- --min-rate 1000 owned-host.example.com

• Scan an approved list with naabu — For many known domains or IPs, use a list-based scanner and keep the rate conservative.

  naabu -list owned-assets.txt -top-ports 1000 -rate 500 -o open-ports.txt

• Fingerprint discovered ports — Do service detection only on ports already identified as open. This reduces scan noise and produces more actionable results.

  nmap -sV -sC -iL hosts-with-open-ports.txt -oN service-fingerprints.txt

• Check public search indexes — Use search indexes as a passive cross-check. Results may be stale, but they can reveal exposure your internal records missed.

  # Shodan CLI example for an owned netblock
  shodan search 'net:192.0.2.0/24' --fields ip_str,port,hostnames,org
  
  # Shodan web query pattern
  net:192.0.2.0/24 port:6379 OR port:27017 OR port:9200

• Check cloud security groups — Cloud controls show intended exposure. Compare them with external scan results.

  # AWS example: find security group rules exposing high-risk ports
  aws ec2 describe-security-groups \
    --query "SecurityGroups[*].{GroupId:GroupId,Ingress:IpPermissions}" \
    --output json
  
  # Review for public sources such as 0.0.0.0/0 or ::/0 on admin and database ports.

Remediation — exact fixes for exposed ports

For every open port, answer three questions. Does this service need to be public? Is access restricted to the right source? Is authentication and patch status verified?

If the service does not need to be public, close it. If it does need to be public, restrict it as much as possible and validate the application-layer controls.

• Block database ports from the public internet — Database ports should usually be reachable only from application subnets or private networks.

  # iptables example: allow Redis only from a trusted private subnet
  -A INPUT -p tcp -s 10.0.1.0/24 --dport 6379 -j ACCEPT
  -A INPUT -p tcp --dport 6379 -j DROP
  
  # Block common database ports publicly
  -A INPUT -p tcp --dport 3306 -j DROP
  -A INPUT -p tcp --dport 5432 -j DROP
  -A INPUT -p tcp --dport 9200 -j DROP
  -A INPUT -p tcp --dport 27017 -j DROP

• Restrict cloud security groups — Remove public inbound rules for administration and database services. Replace them with VPN, bastion, private subnet, or zero-trust access patterns.

  # Risky pattern
  Source: 0.0.0.0/0
  Port: 22, 3389, 3306, 5432, 6379, 9200, 27017
  
  # Safer pattern
  Source: trusted-vpn-cidr
  Port: 22 or 3389
  
  Source: private-app-subnet
  Port: database-service-port

• Bind internal services to private interfaces — A service that only needs local access should bind to 127.0.0.1. A service that needs internal network access should bind to a private interface, not all interfaces.

  # Redis
  bind 127.0.0.1
  
  # MongoDB
  net:
    bindIp: 127.0.0.1
  
  # MySQL
  bind-address = 127.0.0.1
  
  # Restart services after changing bind settings.

• Harden SSH — If SSH must be reachable, require key-based access, disable root login, restrict users, and limit source IPs.

  # /etc/ssh/sshd_config
  PasswordAuthentication no
  PermitRootLogin no
  PubkeyAuthentication yes
  AllowUsers deploy
  
  # Restart SSH after validating configuration
  sshd -t && systemctl restart sshd

• Retest from outside — Always verify the fix from an external network. Do not rely only on cloud console rules or local host configuration.

  # Before remediation: service appears open
  nmap -Pn -p 6379 owned-host.example.com
  
  # After remediation: expected state is closed or filtered
  nmap -Pn -p 6379 owned-host.example.com
  
  # Acceptable outcomes after closing exposure:
  # 6379/tcp closed redis
  # 6379/tcp filtered redis

Real-world incidents

The 2016–2017 MongoDB ransom campaigns showed how exposed database services can become mass targets. Public reporting described large numbers of MongoDB instances reachable from the internet, wiped, and replaced with ransom notes. The defensive lesson is simple: a database port exposed publicly with weak or missing access control can become a target even without a new CVE.

BlueKeep, CVE-2019-0708, showed the other side of port exposure. The issue was a critical pre-authentication remote code execution vulnerability in Remote Desktop Services. A reachable RDP service on port 3389 combined with an unpatched affected Windows system created serious risk.

These examples are different, but the entry condition is similar. A service was reachable from the internet. Port scanning does not prove exploitability by itself, but it reveals the exposed service and gives defenders a starting point for authentication checks, version validation, patch verification, and access-control fixes.

Where ExternalSight fits

ExternalSight includes port scanning as part of a broader external attack surface monitoring workflow for internet-facing domains. It also includes exposed service checks, subdomain discovery, DNS checks, TLS and HTTP posture checks, admin panel detection, cloud exposure checks, sensitive file checks, credential and secret exposure checks, and attack-chain evaluation.

That matters because open ports are rarely isolated findings. An exposed admin panel, weak DNS posture, missing TLS hardening, leaked endpoint, and open service can combine into a more serious external risk path.

ExternalSight also tracks scan coverage. If a module or external source is unavailable, the report can preserve partial results instead of pretending every check succeeded.

Continuous monitoring is available for verified domains on supported plans. That keeps the workflow tied to assets the organization controls.