1. Drop the Test database
The test database installed by the MySQL Server package as part of the mysql_install_db process can be fully accessed by all users by default, making it a common target for attackers. It should therefore be removed during post-installation hardening.
2. Remove all anonymous accounts
MySQL by default creates several anonymous users that essentially serve no purpose after installation. These accounts should therefore be removed, as their presence on the system give attackers an entry point in the database.
3. Change default port mappings
MySQL by default runs on port 3306. This should be changed after installation to obfuscate what critical services are running on which ports, as attackers will initially attempt to exploit default values.
4. Alter which hosts have access to MySQL
If set up as a standalone server, (i.e., if application and web servers query the database from another server) the MySQL instance should be configured to only allow access to permitted hosts. This can be accomplished by making the appropriate changes in the hosts.deny and hosts.allow files.
5.Do not run MySQL with root level privileges
MySQL should be run under a specific, newly-created user account with the necessary permissions to run the service, as opposed to directly as the root user. This adds some auditing and logging benefits while preventing attackers from gaining access by hijacking the root user account.
6. Remove and disable the MySQL history file
Like the Test database, the MySQL history file located at ~/.mysql_history is created by default during installation. This file should be deleted, as it contains historical details regarding installation and configuration steps performed. This could potentially result in the inadvertent exposure of passwords for critical database users. Additionally, a softlink for .mysql_history file to the null device should be created to stop logging to file.
7. Disable remote logins
If the MySQL database is only used by local applications, remote access to the server should be disabled. This is done by opening up the /etc/my.cnf file and adding a skip-networking entry under the [mysqld] section. Configuring MySQL to stop listening on all TCP/IP ports including 127.0.0.1 will effectively restrict database access to local, MySQL socket-based communications.
8. Limit or disable SHOW DATABASES
Again, stripping remote attackers of their information gathering capabilities is critical to a secure security posture. For this reason, the SHOW DATABASES command should be limited or removed entirely by adding skip-show-database to the [mysqld] section of the MySQL configuration file at /etc/my.cnf.
9. Disable the use of LOAD DATA LOCAL INFILE command
The LOAD DATA LOCAL INFILE command allows users to read local files and even access other files on the operating system, which could be exploited by attackers using methods such as SQL injection. The command should therefore be disabled by inserting set-variable=local-infile=0 to the [mysqld] section of my.cnf.
10. Obfuscate the root account
Changing the mysql root user account to a hard-to-guess name adds another layer of security, as attackers must determine the new account name before attempting to brute force the password values.
11. Set the proper file permissions
Make sure that my.cnf is only root writeable. Also, be sure that the default location for data at /usr/local/mysql/data is properly secured with the appropriate permissions.
These are just 11 out of a myriad of hardening tasks for a more secure MySQL deployment. Looking for a way to perform these checks and more automatically across your whole MySQL environment? ScriptRock can automatically monitor your infrastructure for deviations from policy, alerting you on an ongoing basis if any vulnerabilities or security gaps are detected. Give it a test drive—it’s free for up to 10 nodes.