Operating System

If the operating system on which MySQL is running isn't secure, the database itself won't be secure. This section outlines a few things you can do to secure the host that MySQL is running on. Obviously a complete lockdown for each OS is beyond the scope of this section, but here are some pointers that will help:

1. Deploy IPTables (Linux), an IPSec filtering rule set (Windows), or some other host-based firewall software on your MySQL servers. This is now a standard precaution. It is still surprising how many organizations have no host-based defenses as part of their standard desktop and server builds. With the firewall built into Windows XP SP2, this is now less of a problem for Windows hosts . Most Linux distributions have IPTables built in; this is a highly configurable framework for packet filtering and manipulation within the Linux kernel. It's not as hard to configure as you might think, and well worth the effort.

2. Use a low-privileged mysql account to run the MySQL daemon. This is the default on some platforms, but not others. By default, MySQL runs as the local system account under Windows. It should be given its own user account (typically named mysql). On Unix hosts in particular it is important not to run MySQL as (for example) "nobody," because other daemons may be running under that account, for example Apache. If multiple daemons share the same account, a compromise of one means that they are all compromised. For instance, if Apache and MySQL are both running as "nobody," anyone who gains control of Apache will also gain control of the MySQL database.

3. Run mysqld with the --chroot option. Although this doesn't work under Windows, on Unix platforms it provides an excellent mitigation to the power of the file privilege. Chroot restricts file access by a process to a given directory, which means that in the case of mysql, you can ensure that an attacker doesn't have the ability to read or write operating system configuration files or configuration files for other daemons on the host. You should bear in mind that even with the chroot option, an attacker that gains file privilege will be able to read all of the MySQL data, and (probably) still be able to create and execute UDFs.

4. Ensure that the MySQL user cannot access files outside of a limited set of directories. Specifically , the MySQL user should be prohibited from reading operating system configuration files. In some cases you might want to prevent the MySQL user from being able to modify the MySQL configuration files. This is an extension of the point above, but it applies to Windows as well. In general, you would achieve this by ensuring that the account that MySQL is running under has file permissions to its own directories and no more. This can be achieved by creating appropriate groups and applying appropriate permissions to the MySQL directories. This measure is designed to stop MySQL from affecting the rest of the operating system.

5. Ensure that MySQL data files (normally residing beneath the MySQL data directory) cannot be read by users other than the root or Administrator account, and the account that MySQL is running under. This is the flip side of the point above. In order to be secure, you have to protect MySQL from other users on the local host, as well as protecting the operating system from MySQL.

6. Plaintext credentials. Ensure that no user other than the MySQL user can read any MySQL configuration and log files. The files my.cnf, my.ini, and master. info commonly have plaintext usernames and passwords in them, and the query log file (if present) is likely to contain passwords. Depending on the level of logging you have configured, and whether or not the host participates in replication, you may have plaintext usernames and passwords in certain MySQL configuration files. In order to protect these credentials, you should ensure specifically that these files are protected from other users on the host.

7. Turn off unnecessary services or daemons. The more components attackers can access on a host, the greater the chance of them finding a component they can use to gain access to the system. Conversely, the more components you have to manage, the greater the effort and thus the greater the likelihood of error. Keeping the host configuration simple will reduce the problem.

8. Make sure you don't have anything in your .mysql_history file. By default on Unix systems you'll find a .mysql_history file in your home directory. It contains a log of all of the queries that you've typed into the mysql command-line client. This should be cleared regularly, or permanently linked to /dev/null.