MySQL tends not to be the problem so much as the PHP files that interact with it.
Nonetheless, seeing as the database contains what we can least afford to lose – our content – it would be foolish not to take whatever steps we can to reduce its risk of exploitation.
Here are some best practices and, if all else fails, damage containment strategies:
- Setup a fool-proof, off-server backup system
- Delete unneeded databases (ie, sample_test) and database users
- Have individual databases for individual WordPress installations
- For WordPress Multisite, share the database, sites having their own tables (the default option)
- Grant database users the minimum possible privileges
- Give any db a unique administrator – not root – with a unique passphrase
- Give MySQL's root user a unique passphrase
- Change the root administrator's username
Checking for empty passwords
Run this statement from your MySQL root account:
If there are any gaps then create the necessary passwords or, if they're redundant, delete the database users.
Deleting the test database
MySQL comes shipped with a database, sample_test, that poses a small risk. You can look for it and other irrelevant databases with this command, again from MySQL's shell:
Remove it like so, in this case referring to the default-installed sample_test db:
Remote db connections with an SSH tunnel
If your web server connects to MySQL remotely, machine to machine, or for that matter if you connect to it remotely for development or administration purposes, then you must protect what is otherwise a dangerously insecure non-encrypted dataflow.
This is best achieved using an SSH tunnel very similarly to the way we connect local-to-remote using hardened, keyset-authenticating SSH as is set out in wpCop's WordPress Administration Using SSL and Harden SSH for Safe Server Access.
This fun topic is out of the scope of wpCop (for now) but here's a gaggle of mega-great guides:
The common problem with this method, though, is that of dropped connections and the resulting white screen of death. The best tool I've found for keeping such sessions alive, else kicking failed ones back up super-fast, is autossh and you can check that out over here:
phpMyAdmin: friend or foe?
Actually, we covered this in the Cop's phpMyAdmin guide. Just making sure you were still awake. 😉
… Whatever control panels you connect to remotely, for SQL or otherwise, the points raised back there are pretty key so, if you did miss them, take a look.