Close the network first. Turn off public access (on AWS RDS it's a single setting), and set the firewall so only your app's own servers can connect. Make sure the database requires a login with a strong, unique password. Then check its logs for connections you don't recognise, because an open database may already have been read or copied, and that may mean telling your customers.
What's the problem
Your database can be reached from anywhere on the internet, not just from your app. Maybe a scanner or a security email told you, or you've just realised the setting is on. Anyone who finds it can try to log in, and if there's no password or a weak one, they're in.
Why it happens
- It was opened for convenience. Public access was switched on so a developer could connect from their laptop with a database tool, and never switched off.
- The firewall allows everyone. The rule says "any address" (
0.0.0.0/0) instead of only your app's servers. - The database listens everywhere. PostgreSQL listens only on the local machine by default, and MongoDB recommends allowing only trusted clients. Changing that to listen on every network interface is a common shortcut.
- No login, or a default one. Some self-hosted databases were set up without access control, or with a password from a tutorial.
How to fix it
- Turn off public access. On AWS RDS, set Public access to "No". On other providers, look for public networking or a public IP setting.
- Lock the firewall. Allow connections only from your app's servers or private network. Remove any "allow all" rule.
- Require authentication with a strong, unique password, and an app user that has only the permissions the app needs.
- Developers connect privately, through a VPN, a bastion host or the provider's secure tunnel, not by opening the database to the internet.
- Rotate the database password if it was ever weak, shared, or in the code.
- Check the logs for logins and connections you don't recognise during the time it was open, and look for missing, changed or ransom-note data.
- If personal information may have been accessed, see do I have to report a data breach.
When to call Preventionlabs
Turn off public access today; it takes minutes. Call us when the app breaks once the database is private, because it was built to connect from wherever it happened to run, or when nobody knows what else is exposed. Data exposure is on the MVP-level protection checklist in every resurrection, checked from the outside the way an attacker would find it, then fixed.
Submit your project for a free assessmentFree assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.
Sources
- Amazon Web Services: Working with a DB instance in a VPCcloud platform docs
You can use the Public access option to designate whether the DB instance also has a public IP address in addition to the private IP address.
- Amazon Web Services: Working with a DB instance in a VPCcloud platform docs
Access to the DB instance is ultimately controlled by the security group it uses.
- MongoDB: Security Checklist for Self-Managed Deploymentsdatabase docs
Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available.
- MongoDB: Security Checklist for Self-Managed Deploymentsdatabase docs
Enable access control and specify an authentication mechanism.
- PostgreSQL: Connections and Authentication: listen_addressesdatabase docs
The default value is localhost, which allows only local TCP/IP “loopback” connections to be made.