Somebody needed to run a report from home, or a contractor needed to look at a table, so somebody ticked the box that gives the database a public address. It worked, the ticket was closed, and the port has answered the internet ever since. This is a very ordinary way for a database to end up somewhere it should never have been, and it is worth knowing why the answer is nearly always no.
Why a database is the wrong thing to put on the internet
A database is designed to trust whoever reaches it. Redis says so outright in its security documentation: “Redis is designed to be accessed by trusted clients inside trusted environments.” It adds that exposing an instance directly to the internet is usually inadvisable and that “the Redis port should be firewalled to prevent access from the outside” on an internet-facing server.
Redis is blunt about it, but the idea applies to every engine. A database sits at the end of the chain. It holds the customer records, the transactions and the credentials your applications use to talk to everything else. An attacker who reaches it is not looking at a login page for a website. They are looking at the contents of the building.
Public exposure also gives away the one thing a private network gives you for free: the attacker has to find a way in first. Once the port answers anyone, the only thing between the internet and your data is the login and the software behind it. We covered how that discovery works in how attackers find open ports: scanners check every port and identify the service by how it responds, so a database port is found by what it is, not by where it hides.
What a strong password does and doesn’t cover
Microsoft’s SQL Server guidance lists brute force and password spray among the common infrastructure threats, and recommends strong, unique passwords and multifactor authentication for accounts with machine-level access. Good advice, and worth following. But it addresses guessing.
It does not address a flaw in the database software, which can be exploited by someone who never reaches a login. It does not stop a reachable port from being hammered with attempts all day. And it does not help with the accounts nobody remembers: a service account left over from a migration, or an account a vendor set up once.
Encryption is similar. Microsoft states plainly that “encryption doesn’t solve access control problems”, although it limits the damage if access controls are bypassed. Turn it on, and keep treating who can connect as a separate question.
What the cloud vendors do by default
Look at how managed services frame the choice. Amazon RDS puts the database in a VPC, a virtual network that is logically isolated from other virtual networks, and its documentation describes the common design: a public-facing web application and a database “that isn’t publicly accessible”. AWS describes a setup where web servers sit in a public subnet, the database sits in a private subnet, and “only the web servers have access to the DB instances.”
Public access is a deliberate extra. Each DB instance has a private address for traffic inside the VPC, and a Public access option decides whether it also gets a public one. Even then, AWS says access “is ultimately controlled by the security group it uses.” That makes the security group the last line, not the first.
If the database isn’t public and you still need to reach it, AWS lists what to use: a Site-to-Site VPN, Direct Connect, or Client VPN for a private network, VPC peering for an instance in another VPC.
When there is a real reason
There are legitimate cases. An application in another data centre may need to reach a database in yours. Two sites may be joined only over the internet. A partner may need to pull data. CISA’s exposure guidance is realistic about this: “internet exposure reduction does not mean disabling necessary remote access.” It asks you to “determine which assets need to be internet-accessible for operational purposes”, and to “close or restrict access to ports that do not have a documented operational need.”
So the test is not “never.” It is whether you can write down who needs this, from where, and why a private path will not do. If you cannot, the port should not be open.
| Option | Who can reach the port | Main risk left |
|---|---|---|
| Public address, password only | Anyone online | Guessing, plus any flaw in the software |
| Public address, firewall allow-list | Listed IP addresses | A listed address changes hands or is compromised |
| Private subnet, app servers only | Your application tier | A compromised app server |
| VPN, peering or private link | Authenticated networks and users | The VPN becomes your internet-facing service |
| Broker with no inbound listener | Authorised identities, outbound only | The broker and its identity controls |
The VPN row deserves its caveat. It is a genuine improvement over a public port, but it moves the exposure to the VPN, which now needs patching, monitoring and MFA.
A short order of work
- 1Find every reachable databaseScan your own address space
- 2Close what has no documented needRemove the public address
- 3Put the rest behind a private pathAllow-list, VPN or link
- 4Remove the inbound portWhere you can
- Look from the outside. Check your public address ranges for database ports. CISA recommends scanning public IP ranges and investigating unexpected open ports.
- Turn off public access for every database without a documented reason, and check security groups and firewall rules for sources open to everyone.
- Keep applications and databases on separate tiers. The web servers face the public; the database accepts connections only from them.
- Give people a controlled way in. Use a VPN, bastion or broker with named identities and MFA, not a shared account on an open port.
- Follow Microsoft’s wider advice on lock-down: firewalls, patching, least privilege, auditing, and surface area reduction.
Where SSHepherd fits
If the awkward case is a person or a partner who needs to reach a database, SSHepherd® is one way to avoid opening a port for them. It closes the listening port on the server. The server and the user each connect outward to a broker, which joins them only for authorised identities, so a scan finds no database port to try. Sessions can be monitored, recorded and ended on demand, and a server can be protected in about ten minutes without re-architecting the network. See the database use case and the SSHepherd page.
The bottom line
A database should not accept connections from the internet unless you can name who needs it and why a private path will not do. Keep it on a private network, let only your application tier reach it, and give people a controlled way in that leaves no open port to scan.