While firewalls and SSH keys protect the perimeter of your server, the most valuable asset you host is almost always your data. Whether you are running a relational database like PostgreSQL or a NoSQL environment like MongoDB to handle thousands of active users, databases are prime targets for automated scanners and malicious actors.

Out-of-the-box database installations prioritize ease of setup over strict security, often leaving default ports open or authentication disabled. Securing your database ensures that your application data remains private, untampered, and protected from unauthorized extraction.

Restrict Network Access (Bind IP)

The single most effective way to secure a database on a VPS is to ensure it is not directly accessible from the public internet. If your application (like a Node.js backend) and your database are hosted on the exact same server, your database should only listen to local traffic.

• Locate your database configuration file (e.g., mongod.conf for MongoDB or postgresql.conf for PostgreSQL).

• Find the binding address configuration, usually labeled as bindIp or listen_addresses.

• Change this value strictly to 127.0.0.1 (localhost).

• Restart the database service. This guarantees that only applications running internally on that specific server can even attempt to connect to the database.

Enforce Strict Authentication and Roles

Many database systems, particularly in older or default configurations, allow connections without a password. You must explicitly enable authentication and apply the principle of least privilege.

• Enable Authentication: Modify your configuration file to require a password for every connection. In MongoDB, this means enabling authorization: enabled under the security settings.

• Avoid Root Usage: Never connect your web application to your database using the default root or postgres superuser account.

• Role-Based Access: Create a dedicated database user specifically for your application. Grant this user only the permissions it needs to function—such as readWrite access to a single specific database, rather than administrative rights over the entire server.

Encrypt Data in Transit (TLS/SSL)

If your architecture requires your database to be hosted on a separate server from your application backend, you cannot rely on local binding. In this scenario, traffic must travel across a network, making it vulnerable to interception.

• Configure your database to enforce TLS/SSL encryption for all incoming connections.

• Generate and install SSL certificates on the database server.

• Update your application's connection string to explicitly require an encrypted connection, preventing fallback to plain text.

Change Default Ports

While changing ports is not a replacement for strong authentication or firewalls, it is a highly effective method for reducing noise and log clutter from automated botnets that blindly scan the internet for default database ports.

• Identify the default port for your service (e.g., 27017 for MongoDB, 5432 for PostgreSQL, 3306 for MySQL).

• Update the configuration file to listen on a non-standard, high-number port (e.g., 48291).

• Update your server's UFW firewall rules to allow traffic through the new port and explicitly block the old default port.

• Ensure your application’s environment variables are updated to target the new custom port.