Every Open Port Is an Invitation

An open port on a server is a network service actively listening for connections. Every open port is a potential entry point for an attacker. Most organizations have no idea how many ports are open on their internet-facing infrastructure, and that ignorance is exactly what attackers exploit. Automated scanners sweep the entire IPv4 address space continuously, cataloging every open port on every publicly reachable IP address. Services like Shodan, Censys, and BinaryEdge index this data and make it searchable. If you have an open port, it is already indexed. Attackers do not need to scan you. They just need to search. The principle of least privilege applies directly to ports: if a service does not need to be accessible from the internet, its port should not be open to the internet. Yet every day, we find databases, administration panels, and development tools exposed directly to the public internet with no authentication or outdated software. This article covers the most dangerous commonly exposed ports, what runs on them, why they are risky, and how to lock them down.

SSH, Telnet, and Remote Access Ports

Port 22 (SSH) is the primary remote administration protocol for Linux and Unix servers. While SSH itself is encrypted and reasonably secure, an exposed SSH port is a constant target for brute-force attacks. Automated botnets hammer port 22 with username and password combinations around the clock. If you have a weak password or a default account enabled, it is only a matter of time before an attacker gets in. Mitigations include disabling password authentication entirely and requiring key-based authentication, implementing fail2ban or similar rate-limiting tools, and running SSH on a non-standard port to reduce automated scanning noise. Port 23 (Telnet) is far worse. Telnet transmits everything, including passwords, in plaintext. There is no legitimate reason to have Telnet exposed to the internet in 2025. Yet Shodan shows millions of devices with port 23 open, mostly IoT devices, legacy systems, and network equipment. If you find Telnet open on any system, disable it immediately and replace it with SSH. Port 3389 (RDP, Remote Desktop Protocol) is the Windows equivalent of SSH, and it is arguably more dangerous. RDP has a long history of critical vulnerabilities, including BlueKeep (CVE-2019-0708) which allowed unauthenticated remote code execution. RDP should never be exposed directly to the internet. Use a VPN or a remote access gateway instead.

Web Ports and Proxy Services

Ports 80 (HTTP) and 443 (HTTPS) are expected to be open on web servers, but they still carry risk. An open port 80 without a redirect to HTTPS means unencrypted traffic is possible, exposing session cookies and credentials to network-level interception. Port 8080 is the more concerning find. It is commonly used for proxy servers, development environments, application server admin consoles (Tomcat Manager, Jenkins), and secondary web services. Unlike port 443, services on port 8080 are frequently deployed without TLS encryption and with default or weak credentials. We regularly find Jenkins instances on port 8080 with no authentication, giving an attacker full control over CI/CD pipelines and, through them, production deployments. Other high-numbered web ports to watch for include 8443 (alternative HTTPS), 8888 (common for development servers and Jupyter notebooks), 9090 (Prometheus, Cockpit), and 3000 (Grafana, Node.js development servers). Each of these can expose administration interfaces or development tools that were never meant to be publicly accessible.

Database Ports: The Crown Jewels

Exposed database ports are among the most critical findings in any port scan. Port 3306 (MySQL/MariaDB), port 5432 (PostgreSQL), port 27017 (MongoDB), and port 6379 (Redis) should never be accessible from the public internet. Full stop. When a database port is exposed, an attacker can attempt authentication directly. MySQL and PostgreSQL at least require credentials, though brute-force attacks against them are common. MongoDB historically defaulted to no authentication at all, which led to mass compromise of tens of thousands of databases in 2017 when attackers automated scanning for open port 27017 and wiped databases for ransom. Redis is even worse. By default, Redis has no authentication and binds to all interfaces. An exposed Redis instance gives an attacker the ability to read and write arbitrary data, and in many configurations, to write SSH keys to the server's authorized_keys file, achieving full remote code execution. Port 445 (SMB, Server Message Block) rounds out the most dangerous database and file-sharing ports. SMB vulnerabilities like EternalBlue (CVE-2017-0144) powered the WannaCry ransomware outbreak that crippled hospitals, telecom companies, and government agencies worldwide.

Email Port 25 and Legacy Services

Port 25 (SMTP) is necessary for mail servers to receive email, but an open relay on port 25 allows anyone to send email through your server. Open relays are actively exploited for spam campaigns and phishing attacks. If your server is not specifically a mail server, port 25 should be closed. Even if it is a mail server, ensure relay restrictions are properly configured. Legacy services on ports like 21 (FTP), 69 (TFTP), and 161 (SNMP) present similar risks. FTP transmits credentials in plaintext and has numerous protocol-level vulnerabilities. TFTP requires no authentication at all. SNMP version 1 and 2 use community strings (essentially plaintext passwords), and default community strings like "public" and "private" are tried by every scanner. If you need file transfer, use SFTP over SSH. If you need device monitoring, use SNMP v3 with proper authentication and encryption. Every legacy protocol you keep running is an attack surface you are maintaining unnecessarily.

Network Segmentation and Firewall Rules

The most effective defense against port-based attacks is network segmentation combined with strict firewall rules. Segment your network so that databases are on a private subnet with no direct internet access. Application servers should communicate with databases through internal network interfaces only. Management interfaces like SSH and RDP should be accessible only through a VPN or bastion host. Implement firewall rules using a default-deny approach: block everything, then explicitly allow only the traffic that is necessary. For cloud infrastructure, security groups and network ACLs provide this functionality. Every cloud provider, whether AWS, GCP, Azure, or Linode, offers security groups that act as virtual firewalls. Configure them to allow only the minimum required inbound traffic. A common mistake is allowing 0.0.0.0/0 (all IP addresses) on non-web ports during development and forgetting to restrict it before deployment. Review your security group rules regularly and treat them as code, storing them in version control and applying them through infrastructure-as-code tools.

Shodan and Why You Are Already Indexed

Shodan, often called the search engine for the internet of things, continuously scans the entire IPv4 address space and indexes every service it finds. It records the port number, service banner, SSL certificate details, geographic location, and hosting provider for every open port on every reachable IP address. This means your exposed ports are not a secret. They are already cataloged and searchable. An attacker can query Shodan for your organization's IP range and instantly see every open port, the software version running on each one, and known vulnerabilities for those versions. This is free and requires no technical skill. Censys and BinaryEdge provide similar capabilities. Rather than viewing this as a threat, use it as a defensive tool. Search for your own IP ranges on Shodan regularly. Compare what Shodan sees from the outside with what your internal asset inventory says should be exposed. Any discrepancy is either a misconfiguration or a rogue service that needs immediate attention.

Regular Port Auditing

Port security is not a one-time configuration. It requires ongoing auditing. New services get deployed, firewall rules get modified, cloud instances get provisioned, and each change can expose new ports. Establish a regular port scanning schedule, at minimum monthly, for all of your internet-facing infrastructure. Use nmap for comprehensive scanning. A basic scan of the top 1000 ports covers the most common services, but a full 65535-port scan occasionally is important for catching services running on non-standard ports. At BlackSight, our port scanner runs nmap against your infrastructure on a recurring schedule and alerts you when new ports appear or when known-dangerous ports are detected as open. Combine external scanning with internal auditing using tools like ss or netstat to check what ports are listening on each server. Compare external and internal results to verify that your firewall rules are working as intended. Every open port you find should be documented: what service runs on it, why it needs to be externally accessible, and what authentication and encryption protects it. If you cannot answer all three questions, that port should be closed.