How to Secure MariaDB After Installation on Ubuntu

You have just installed MariaDB on Ubuntu. However, if the default configuration is left unchanged, the database is exposed to serious security risks. Anonymous users may be able to log in, the root account may have no password, and unrestricted network access can allow unauthorized connections. In such a state, compromise can occur very quickly.

This guide walks through the critical security hardening steps required for every MariaDB installation. By the end, anonymous access will be disabled, strong password policies will be enforced, network access will be restricted, data in transit will be encrypted, and user privileges will be properly configured. These are practical, production-proven steps that distinguish a secure database from a security liability.

These hardening measures apply to MariaDB versions 10.5, 10.6, and 11.0. The entire process typically takes about thirty minutes to complete.

Table of Contents

1. Why MariaDB Security Matters
2. The Default Security Problem
3. Step 1: Disable Anonymous User Access
4. Step 2: Remove Root Password Vulnerability
5. Step 3: Enforce Strong Password Policies
6. Step 4: Lock Down Remote Access
7. Step 5: Configure Firewall Rules
8. Step 6: Enable Secure Sockets Layer and Transport Layer Security Encryption
9. Step 7: Implement Least Privilege Access
10. Step 8: Enable Binary Logging and Audit Logs
11. Post-Hardening Security Checklist
12. Common Security Mistakes
13. Ongoing Monitoring and Maintenance
14. Next Steps

Why MariaDB Security Matters

Databases store the most sensitive data in an environment, including customer information, financial records, and personal details. A single breach can expose all of this data at once. MariaDB listens for network connections by design, and default installations prioritize ease of use rather than security.

Most database breaches occur because of default credentials, missing authentication, or unencrypted data in transit. Each of these weaknesses is preventable with proper hardening.

The Default Security Problem

A standard MariaDB installation on Ubuntu includes insecure defaults:

• Anonymous users that allow passwordless access.
• Root account without a password.
• Remote access enabled on all interfaces.
• No encryption for network traffic.
• No password policy enforcement.
• Verbose error output that leaks internal details.

These defaults are acceptable for development environments but are inappropriate for production systems.

Step 1: Disable Anonymous User Access

Anonymous users allow anyone to connect without authentication and must be removed immediately.

Connect to MariaDB as root:

sudo mariadb -u root

List current users:

SELECT user, host FROM mysql.user;

Anonymous users appear as empty usernames.

+-----------+-----------+
| user      | host      |
+-----------+-----------+
| root      | localhost |
|           | localhost |
| root      | %         |
|           | %         |
+-----------+-----------+

Remove anonymous users:

DELETE FROM mysql.user WHERE user = '';
FLUSH PRIVILEGES;

Verify removal:

SELECT user, host FROM mysql.user;

Only named accounts should remain.

Step 2: Remove Root Password Vulnerability

The root account has unrestricted privileges. If it has no password, the database is completely exposed.

Set a strong root password:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'your_strong_password_here';
ALTER USER 'root'@'%' IDENTIFIED BY 'your_strong_password_here';
FLUSH PRIVILEGES;

Test authentication:

sudo mariadb -u root -p

Restrict remote root access:

DELETE FROM mysql.user WHERE user = 'root' AND host = '%';
FLUSH PRIVILEGES;

This ensures root can only connect from the local system.

Step 3: Enforce Strong Password Policies

MariaDB does not enforce password complexity by default. Enabling password validation ensures weak credentials cannot be created.

Install the password validation plugin:

INSTALL PLUGIN simple_password_check SONAME 'simple_password_check.so';

Configure password rules:

SET GLOBAL simple_password_check_digits = 1;
SET GLOBAL simple_password_check_letters_same_case = 1;
SET GLOBAL simple_password_check_letters_mixed_case = 1;
SET GLOBAL simple_password_check_minimal_length = 12;
SET GLOBAL simple_password_check_other_characters = 1;

Persist configuration by editing the MariaDB server configuration file:

File Location Guide: You're about to edit /etc/mysql/mariadb.conf.d/50-server.cnf. This is the main configuration file for MariaDB on Ubuntu. Follow the steps below carefully. You will be logged in as the root user (via sudo), so all changes are made with proper permissions.

Step-by-step file editing instructions:

1. Open the file as root:

   sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

2. Locate the [mysqld] section near the top of the file. If it doesn't exist, create it.
3. Add the following lines under [mysqld]:

   [mysqld]
   simple_password_check_digits = 1
   simple_password_check_letters_same_case = 1
   simple_password_check_letters_mixed_case = 1
   simple_password_check_minimal_length = 12
   simple_password_check_other_characters = 1

4. Save and exit:
   • Press CTRL + X
   • Press Y to confirm
   • Press ENTER to save with the same filename
5. Verify your changes by viewing the file:

   grep -A 5 "simple_password_check" /etc/mysql/mariadb.conf.d/50-server.cnf

   You should see all five password policy lines you just added.

Restart MariaDB to apply the changes:

sudo systemctl restart mariadb

Verify the service restarted successfully:

sudo systemctl status mariadb

Step 4: Lock Down Remote Access

MariaDB listens on all network interfaces by default. Restricting this reduces exposure.

Step-by-step file editing instructions:

1. Open the configuration file:

   sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

2. Locate the [mysqld] section (you may have already added password policy settings here).
3. Find the existing bind-address line (it may say bind-address = 0.0.0.0 or similar). If it doesn't exist, add a new line.
4. Replace or add the bind-address setting:

   [mysqld]
   bind-address = 127.0.0.1

   This restricts connections to localhost only. If you need remote access from a specific server, use its IP address instead (e.g., bind-address = 127.0.0.1,10.0.1.10).

5. Save and exit:
   • Press CTRL + X
   • Press Y to confirm
   • Press ENTER to save
6. Verify the change:

   grep "bind-address" /etc/mysql/mariadb.conf.d/50-server.cnf

Restart MariaDB:

sudo systemctl restart mariadb

Verify the binding:

sudo netstat -tlnp | grep mariadb

You should see MariaDB listening only on the configured address or addresses and not on 0.0.0.0.

Step 5: Configure Firewall Rules

Even with network binding restricted, firewall rules provide an essential second layer of defense. Ubuntu includes Uncomplicated Firewall for this purpose.

Check whether Uncomplicated Firewall is enabled:

sudo ufw status

If Uncomplicated Firewall is active, restrict MariaDB access:

# Allow MariaDB access from a specific host
sudo ufw allow from 10.0.1.10 to any port 3306

# Allow MariaDB access from a subnet
sudo ufw allow from 10.0.1.0/24 to any port 3306

# Verify firewall rules
sudo ufw status numbered

Uncomplicated Firewall denies all other incoming traffic by default. If only specific addresses are allowed, all other MariaDB connections are blocked.

IMPORTANT: When managing the server remotely, never block Secure Shell access before validating firewall rules. Always test connectivity from a remote client before finalizing changes.

Step 6: Enable SSL/TLS Encryption

Unencrypted database connections transmit credentials and data in plain text. Any system with network access can intercept queries and passwords. Secure connections with SSL/TLS encryption.

Verify SSL support:

sudo mariadb -u root -p -e "SHOW VARIABLES LIKE '%ssl%';"

You should see:

have_ssl: YES

If SSL support is disabled, reinstall MariaDB with SSL enabled or verify your distribution packages.

Generate self-signed certificates:

sudo mkdir -p /etc/mysql/certs
cd /etc/mysql/certs

sudo openssl genrsa -out ca-key.pem 4096
sudo openssl req -new -x509 -days 365 -key ca-key.pem -out ca-cert.pem \
  -subj "/CN=MariaDB-CA"

sudo openssl genrsa -out server-key.pem 4096
sudo openssl req -new -key server-key.pem -out server.csr \
  -subj "/CN=mariadb.internal"

sudo openssl x509 -req -days 365 -in server.csr \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem

sudo openssl genrsa -out client-key.pem 4096
sudo openssl req -new -key client-key.pem -out client.csr \
  -subj "/CN=mariadb-client"

sudo openssl x509 -req -days 365 -in client.csr \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem

sudo chown -R mysql:mysql /etc/mysql/certs
sudo chmod 644 /etc/mysql/certs/*.pem
sudo chmod 600 /etc/mysql/certs/*-key.pem

Configure MariaDB to use SSL:

1. Open the configuration file:

   sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

2. Add the following SSL configuration under [mysqld]:

   [mysqld]
   ssl-ca = /etc/mysql/certs/ca-cert.pem
   ssl-cert = /etc/mysql/certs/server-cert.pem
   ssl-key = /etc/mysql/certs/server-key.pem

3. Save and exit:
   • Press CTRL + X
   • Press Y to confirm
   • Press ENTER to save
4. Verify the changes:

   grep "ssl-" /etc/mysql/mariadb.conf.d/50-server.cnf

Restart MariaDB:

sudo systemctl restart mariadb

Require SSL for users:

ALTER USER 'appuser'@'10.0.1.10' REQUIRE SSL;
FLUSH PRIVILEGES;

Test encrypted connections:

sudo mariadb -u root -p --ssl-ca=/etc/mysql/certs/ca-cert.pem

Verify encryption status:

SHOW SESSION STATUS LIKE '%ssl%';

You should see an active cipher in use.

Ssl_cipher: TLS_AES_256_GCM_SHA384

Step 7: Implement Least Privilege Access

Every database user must have only the permissions required for its function. Excess privileges increase the impact of compromise.

Create an application user:

CREATE USER 'appuser'@'10.0.1.10'
IDENTIFIED BY 'P@ssw0rd!2024'
REQUIRE SSL;

GRANT SELECT, INSERT, UPDATE, DELETE
ON production_db.*
TO 'appuser'@'10.0.1.10';

FLUSH PRIVILEGES;

Create a backup user:

CREATE USER 'backup_user'@'10.0.1.20'
IDENTIFIED BY 'B@ckup!2024'
REQUIRE SSL;

GRANT SELECT, LOCK TABLES, SHOW VIEW
ON *.*
TO 'backup_user'@'10.0.1.20';

FLUSH PRIVILEGES;

Create a replication user:

CREATE USER 'repl'@'10.0.1.30'
IDENTIFIED BY 'Repl!2024'
REQUIRE SSL;

GRANT REPLICATION SLAVE, REPLICATION CLIENT
ON *.*
TO 'repl'@'10.0.1.30';

FLUSH PRIVILEGES;

Audit existing users:

SELECT user, host
FROM mysql.user
WHERE user NOT IN ('mysql.sys', 'mysql', 'root', 'mariadb.sys');

SHOW GRANTS FOR 'appuser'@'10.0.1.10';

Remove any accounts that do not have a documented and justified purpose.

Step 8: Enable Binary Logging & Audit Logs

Binary logs track all database changes and are essential for replication, point-in-time recovery, and forensic analysis. Audit logs capture user activity and help detect unauthorized access.

Enable binary logging:

1. Open the configuration file:

   sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

2. Add the following binary logging configuration under [mysqld]:

   [mysqld]
   server-id = 1
   log_bin = /var/log/mysql/mariadb-bin
   binlog_format = MIXED
   binlog_row_image = FULL
   expire_logs_days = 7
   max_binlog_size = 100M

3. Save and exit:
   • Press CTRL + X
   • Press Y to confirm
   • Press ENTER to save
4. Verify the changes:

   grep -E "server-id|log_bin|binlog_format" /etc/mysql/mariadb.conf.d/50-server.cnf

The expire_logs_days setting automatically removes logs older than seven days to prevent disk exhaustion.

Enable the audit plugin:

sudo mariadb -u root -p -e "INSTALL PLUGIN server_audit SONAME 'server_audit.so';"

Configure audit logging:

1. Open the configuration file:

   sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

2. Add the following audit logging configuration under [mysqld]:

   [mysqld]
   server_audit_logging = ON
   server_audit_events = 'CONNECT,QUERY_DCL,QUERY_DDL'
   server_audit_log_file = /var/log/mysql/audit.log

3. Save and exit:
   • Press CTRL + X
   • Press Y to confirm
   • Press ENTER to save

Connection attempts, privilege changes, and schema modifications are logged. Avoid enabling QUERY_DML unless absolutely required, as it generates very large log files.

Restart MariaDB to apply all changes:

sudo systemctl restart mariadb

Verify logs are being written:

ls -lh /var/log/mysql/mariadb-bin.*
ls -lh /var/log/mysql/audit.log

Both files should exist and show recent timestamps.

Post-Hardening Security Checklist

Before declaring the system production-ready, verify the following:

• Anonymous users removed
• Root account has a strong password
• Remote root access disabled
• Password validation plugin enabled
• Bind address restricted to specific IPs
• Firewall rules restrict port 3306 access
• SSL/TLS enabled and supported
• All users require encrypted connections
• Least-privilege users configured
• Binary logging enabled
• Audit logging active and writing to disk
• MariaDB fully patched

This checklist takes minutes to complete and prevents the most common security oversights.

Common Security Mistakes

Using identical passwords for all users. A single compromised credential exposes everything. Use unique passwords per account.

Granting global privileges unnecessarily. Avoid wildcard grants. Scope access to specific databases.

Ignoring human behavior. Strong passwords alone are not enough. Use secrets management tools.

Enabling SSL without enforcing it. Certificates are useless unless users are required to use them.

Leaving root accessible remotely. Root should be local-only whenever possible.

Embedding credentials in source code. Use environment variables or secrets managers.

Never rotating passwords. Rotate credentials every 90 days or automate rotation.

Ongoing Monitoring & Maintenance

Database security requires continuous monitoring.

Review failed login attempts:

sudo grep "Access denied" /var/log/mysql/error.log | tail -20

Monitor disk usage:

du -sh /var/log/mysql/

Inspect audit logs:

sudo tail -100 /var/log/mysql/audit.log | grep "QUERY_DDL\|CONNECT"

Apply updates regularly:

sudo apt-get update && sudo apt-get upgrade mariadb-server

Stay informed by following official MariaDB security advisories.

More resources

• Installing MariaDB on Ubuntu
• MariaDB Official Security Documentation
• Securing MariaDB (Official Knowledge Base)
• CIS MariaDB Benchmark
• MariaDB Security Best Practices (Percona)

Conclusion

A hardened MariaDB installation is the foundation of database security. By removing insecure defaults, enforcing encryption, limiting access, and enabling logging, you eliminate the most common attack vectors.

The process takes less than an hour but delivers long-term protection, visibility, and confidence. Security is not a one-time task—monitor continuously, update frequently, and refine as your environment evolves.

Your data is only as secure as the system protecting it.

Need professional help with your database or infrastructure? Our team at Technoroots Limited specializes in enterprise database solutions.

Contact us at Technoroots for expert guidance on MySQL migrations, PostgreSQL optimization, Oracle Database setup, or any database infrastructure challenges.