What database ports are
Every service running on a server communicates through a numbered port. Web servers use port 80 for HTTP and port 443 for HTTPS. Email servers use port 25 for SMTP. Database servers have their own default ports, and these are well known to anyone who has spent five minutes reading documentation — including attackers.
Here are the ports that matter most:
- MySQL listens on port 3306
- PostgreSQL listens on port 5432
- MongoDB listens on port 27017
- Microsoft SQL Server listens on port 1433
- Redis listens on port 6379
- Elasticsearch listens on port 9200
These are the defaults. Some administrators change the port numbers to non-standard values, but this is security through obscurity — it slows down a casual scan by seconds, not minutes.
Why exposed database ports are dangerous
A database server that is accessible from the internet is one of the most serious security issues a business can have. To understand why, you need to understand what "accessible from the internet" actually means.
When a database port is open to the public internet, anyone in the world can attempt to connect to it. They do not need to be on your network. They do not need to compromise another system first. They just need to know your server's IP address and the port number — both of which are trivially easy to discover.
A properly configured database server should only accept connections from the application servers that need to talk to it. If your web application runs on server A and your database runs on server B, server B should be configured to accept connections only from server A's IP address. Connections from any other IP address should be refused.
When this restriction is missing, your database is sitting on the open internet waiting for someone to knock on the door.
How attackers find exposed databases
Finding exposed database ports is not a specialized skill. It is automated and it happens constantly.
Internet-wide scanning tools
Services like Shodan continuously scan the entire internet and index every open port they find. Shodan is sometimes described as "a search engine for internet-connected devices." You can search Shodan for every MySQL server in a specific city, every MongoDB instance in a particular country, or every PostgreSQL database running a specific version.
This is not a hacking tool. It is a publicly available service that anyone can use. Security researchers use it to study internet infrastructure. Attackers use it to find targets.
Automated scanners
Beyond services like Shodan, attackers run their own automated scanners that sweep entire IP ranges looking for open database ports. A single attacker can scan millions of IP addresses per hour. When they find an open database port, it gets added to a list for further exploitation.
How fast it happens
Research consistently shows that a new server exposed to the internet with an open database port will receive its first connection attempt within minutes. Not hours, not days — minutes. The scanning is continuous and automated. If your database port is open, it has already been found.
What attackers do once they find an exposed database
Finding the port is step one. What happens next depends on the database configuration, but none of the outcomes are good.
Brute force authentication
If the database requires a username and password, attackers will attempt to brute force the credentials. They use dictionaries of common database passwords and automated tools that can try thousands of combinations per minute. Default credentials are tried first — and a surprising number of databases still use them.
MySQL's default root account, MongoDB instances deployed without authentication enabled, Redis servers with no password — these are not edge cases. They are common findings on real-world scans.
Exploiting known vulnerabilities
Every database engine has had security vulnerabilities over the years. Older versions with unpatched vulnerabilities are especially attractive targets. If your database is running a version with a known remote code execution vulnerability, an attacker does not need your password. They can exploit the vulnerability to gain access directly.
Data exfiltration
Once connected, the attacker can read every table in the database. Customer records, financial data, employee personal information, passwords, session tokens — whatever your application stores, the attacker now has access to it.
In many cases, the attacker copies the entire database and then uses the data for identity theft, financial fraud, or sells it on dark web marketplaces. If the stolen data includes passwords that your users have reused on other services, the damage extends far beyond your organization.
Ransomware and data destruction
A particularly common attack against exposed MongoDB and Elasticsearch instances involves deleting all data and replacing it with a ransom note. The attacker drops every collection or index, creates a single entry with payment instructions, and demands cryptocurrency to return the data. In many cases, they never had the data to return — they simply deleted it.
Using the database as a pivot point
A compromised database server can be used as a launching point for attacks against other systems on the same network. The attacker may be able to access internal network resources, escalate privileges, or move laterally to more valuable targets.
Why shared hosting and cloud setups are especially vulnerable
Small businesses running applications on shared hosting or cloud infrastructure face particular risks with database exposure.
Misconfigured cloud security groups
Cloud platforms like AWS, Azure, and Google Cloud use security groups or firewall rules to control network access. It is remarkably easy to misconfigure these rules — especially if you are not a network engineer. A single rule that allows inbound traffic on port 3306 from 0.0.0.0/0 (meaning "anywhere") opens your database to the world. This is one of the most common cloud security misconfigurations in existence.
Shared hosting defaults
Some shared hosting environments configure database servers to accept connections from any IP address to allow flexibility for customers who need to connect from external tools. If you are on shared hosting, verify that your database is not accessible from outside the hosting environment.
Development settings left in production
Developers frequently configure databases to accept connections from any IP address during development for convenience. When the application moves to production, that configuration sometimes comes along with it. What was a time-saving shortcut during development becomes a critical vulnerability in production.
How to check if your database is exposed
There are several ways to determine whether your database ports are accessible from the internet.
External port scan
The most direct method is to run a port scan against your server's public IP address from an external location. Tools like nmap can check whether specific ports are open and responding. If you scan your server's IP and port 3306 responds, your MySQL database is exposed.
Shodan search
Search for your server's IP address on Shodan. If your database port appears in the results, it is indexed and accessible from the internet. Shodan also shows the database version and banner information, which tells you exactly what an attacker would see.
Cloud provider console
If you are on a cloud platform, review your security groups, firewall rules, and network access control lists. Look for any rule that allows inbound traffic on database ports (3306, 5432, 27017, 1433, 6379, 9200) from 0.0.0.0/0 or ::/0.
Vulnerability scanner
Automated security scanners can detect exposed database ports as part of a broader assessment of your internet-facing infrastructure. This is often the easiest approach because it checks for database exposure alongside other common vulnerabilities.
How to fix it
The fix is conceptually simple, even if the implementation details vary by environment.
Restrict access by IP address
Configure your database to accept connections only from the specific IP addresses that need access — typically your application server. Reject all other connections. This is the single most important change you can make.
Use firewall rules
Whether you are using a cloud security group, a host-based firewall like iptables or ufw, or a hardware firewall, create rules that block inbound traffic on database ports from the public internet. Only allow connections from trusted internal IP addresses.
Disable remote connections if unnecessary
If your application and database run on the same server, configure the database to listen only on localhost (127.0.0.1). This makes it physically impossible for external connections to reach the database.
Change default credentials
If your database is using default usernames or passwords, change them immediately. Use strong, unique credentials stored in a password manager or environment variables — never hardcoded in application source code.
Keep your database software updated
Apply security patches as they are released. Subscribe to security advisories for whatever database engine you use so you are notified when vulnerabilities are discovered.
Enable authentication
This should go without saying, but ensure your database requires authentication. MongoDB versions before 4.0 shipped with authentication disabled by default. Redis still does not require a password by default. Check your configuration and enable authentication if it is not already active.
The bottom line
An exposed database port is not a theoretical risk. It is an active vulnerability that is being scanned for and exploited every day. The fix is well-understood and straightforward to implement. There is no reason for a database to be accessible from the open internet in a production environment.
If you are unsure whether your infrastructure has exposed database ports, find out now — before someone else does.
Check your exposure in minutes. Run a free security assessment to see if your database ports, email security, and other services are exposed to the internet.
