Hardening MySQL and MariaDB

MySQL and MariaDB share a config language, most of their variables, and nearly every hardening decision. They diverge on exactly one thing that matters here — authentication — and they diverge sharply enough that generic “MySQL hardening” advice is wrong for roughly half the people reading it.

7 controls

• Bind MySQL to a private interfaceA listener on every interface is reachable from anywhere routableSeverity: critical
• Choose the right MySQL or MariaDB authentication pluginUnsalted SHA-1 password hashes, and a plugin being removedSeverity: high
• Remove anonymous users and the test databaseAn account with no username and no passwordSeverity: high
• Enable and require TLS for MySQLCredentials and query results cross the network in plaintextSeverity: high
• Grant least privilege in MySQLThe app account can read files and drop every databaseSeverity: medium
• Restrict MySQL file privilegesSQL access becomes filesystem read and writeSeverity: medium
• Secure MySQL config files and credentialsAny local user can read the database passwordSeverity: low

First: which one do you actually have?

This is not a pedantic question. On Debian, apt install mysql-server installs MariaDB. Debian, Ubuntu and the RHEL family all made MariaDB their default “MySQL” package years ago, so a server someone set up with the obvious command is very likely not running MySQL at all.

Find out:

SELECT VERSION();

8.4.6            -- MySQL
11.8.6-MariaDB   -- MariaDB

	MySQL	MariaDB
Config	/etc/mysql/mysql.conf.d/mysqld.cnf	/etc/mysql/mariadb.conf.d/50-server.cnf
Current	8.4 LTS (to 2032); 9.x is Innovation, ~8 months support each	11.8 / 12.x
Default auth	caching_sha2_password	mysql_native_password
mysql_native_password	Disabled by default in 8.4, removed in 9.0	Still the default
caching_sha2_password	Default since 8.0	Community 12.1+ only
unix_socket for root	No	Yes, by default on Debian/Ubuntu

Everything on this list applies to both except authentication, which has separate instructions for each. Where a page says /etc/mysql/mysql.conf.d/mysqld.cnf, substitute the MariaDB path if that’s what you have.

If you are on MySQL 8.0, you are on an EOL release

MySQL 8.0 reached end of life in April 2026 with 8.0.46. It receives no further security fixes.

MySQL now runs two tracks, and picking the wrong one is a slow-motion version of this same problem:

• LTS (8.4) — supported to 2032. This is what a server should run.
• Innovation (9.x) — new features, but roughly 8 months of support per release. Running 9.x means committing to an upgrade treadmill three times a year, forever. It is not a “newer is better” choice.

Upgrading 8.0 → 8.4 is the single highest-value thing on this page if it applies to you, and it is not a config change. Note it also crosses the mysql_native_password cutover, which is covered on the authentication page — read that before you upgrade, not after.

Where the config lives

SHOW VARIABLES LIKE 'bind_address';

Ask the server rather than reading a file. MySQL and MariaDB both read a chain of files (/etc/mysql/my.cnf, then conf.d/, then mysql.conf.d/ or mariadb.conf.d/), and the last value read wins — so the setting you edited may be overridden by a file later in the chain. To see the actual chain:

mysqld --verbose --help | grep -A1 'Default options'

Reloading

Most variables here need a restart:

sudo systemctl restart mysql        # MySQL on Debian/Ubuntu
sudo systemctl restart mariadb      # MariaDB

Some can be set at runtime with SET GLOBAL, which takes effect immediately but is lost on restart unless you also write it to the config file. That split — running value versus file value — is why every verification here uses SHOW VARIABLES against the live server.

Before you start

No lockout risk in the SSH sense. The risk is that these changes break applications, and MySQL’s connection errors are famously unhelpful about why. Have your connection strings ready, and prefer a maintenance window.