Database Security

Database Security

Databases are high-value targets because they contain everything worth stealing: user credentials, payment data, PII, business data. Database compromises often happen not through sophisticated exploits but through basic misconfigurations: databases listening on public interfaces, default root passwords, application users with excessive privileges, or SQL injection through application code. These are all preventable. This guide covers the practical steps to harden MySQL/MariaDB and PostgreSQL on Ubuntu.

Minimizing network exposure

# MySQL/MariaDB: restrict to localhost (default on Ubuntu):
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Restricting MySQL to localhost

[mysqld]
bind-address = 127.0.0.1     # Only accept connections from localhost
# If you need remote access, specify the private network interface IP:
# bind-address = 192.168.1.10

# PostgreSQL: restrict listening address:
sudo nano /etc/postgresql/16/main/postgresql.conf
# listen_addresses = 'localhost'   ← default, most secure

# Verify no database is listening on 0.0.0.0:
sudo ss -tlnp | grep -E "3306|5432"

Expected output — databases only on localhost

LISTEN 0 80 127.0.0.1:3306  0.0.0.0:*  users:(("mysqld",pid=1234))
LISTEN 0 244 127.0.0.1:5432 0.0.0.0:*  users:(("postgres",pid=5678))

Principle of least privilege

# MySQL: audit what privileges each user has:
SELECT user, host, Select_priv, Insert_priv, Update_priv, Delete_priv,
       Super_priv, Grant_priv FROM mysql.user WHERE user NOT IN ('root', 'mysql.sys');

# Revoke excessive privileges:
REVOKE SUPER ON *.* FROM 'appuser'@'localhost';
REVOKE FILE ON *.* FROM 'appuser'@'localhost';     # Prevents reading files from disk

# PostgreSQL: audit role privileges:
\du+    -- in psql, shows all roles with attributes

# Revoke public schema default privileges (PostgreSQL security best practice):
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON DATABASE mydb FROM PUBLIC;

📝 NOTE: The FILE privilege in MySQL allows a user to read files from the server's filesystem using LOAD DATA INFILE. Even application users should not have this privilege — it's a common lateral movement technique after an SQL injection.

Encrypting connections

# MySQL: check if SSL is enabled:
sudo mysql -e "SHOW VARIABLES LIKE '%ssl%';"

MySQL SSL variables

have_ssl      | YES
ssl_cert      | /var/lib/mysql/server-cert.pem
ssl_key       | /var/lib/mysql/server-key.pem

# Require SSL for a specific user:
ALTER USER 'remoteapp'@'192.168.1.%' REQUIRE SSL;

# PostgreSQL: SSL is enabled by default in Ubuntu packages
# Force SSL in pg_hba.conf by using 'hostssl' instead of 'host':
# hostssl   mydb   appuser   192.168.1.0/24   scram-sha-256

# Test SSL connection:
psql "sslmode=require host=dbserver dbname=mydb user=appuser"

Audit logging

# MySQL: enable general query log for audit (high overhead — use sparingly):
sudo mysql -e "SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file='/var/log/mysql/general.log';"

# Better: enable audit plugin (MySQL) or pgaudit extension (PostgreSQL)
# PostgreSQL pgaudit:
sudo apt install -y postgresql-16-pgaudit
# In postgresql.conf:
# shared_preload_libraries = 'pgaudit'
# pgaudit.log = 'ddl, write'    ← log CREATE/DROP and INSERT/UPDATE/DELETE

sudo systemctl restart postgresql

Conclusion

Database security checklist: (1) bind to localhost or internal IP only, never 0.0.0.0; (2) run mysql_secure_installation/postgres_secure_installation equivalent steps; (3) create per-application users with minimal privileges — no SUPER, no FILE, only their own database; (4) require SSL for any remote connections; (5) enable audit logging for compliance environments. Most database breaches involve one of these five items being misconfigured — fix all five and you eliminate the vast majority of risk.