Database management systems such as MySQL are prime targets for cyber criminals because these systems are used to store the vast majority of information cyber criminals desire to obtain. Malware and security vulnerabilities cause billions of dollars worth of damage every year in loss of valuable information, theft of personal and private information, and even DoS or Denial of Service (disrupting access to systems), along with the enormous investment organizations must afford to protect information technology and data storage systems through antivirus software, firewalls, intrusion detection systems and more. Unfortunately, even with the deployment of the above countermeasures, in many cases it is still possible for cyber criminals to access valuable information contained within a MySQL database management system. Hence, for those organizations that use MySQL as their data management technology, it is imperitive that they understand and implement the guidelines and procedures recommended in this document to ensure their information remains safe in the event that a data breach which compromises firewalls, and other network and system security countermeasures, does not result in the theft or loss of information contained within their MySQL databases.
MySQL Default Configuration Vulnerabilities
There are a number of common security vulnerabilities associated with databases (MySQL included) that must be addressed prior to going “live” with a new installation. A MySQL database in its default configuration is susceptible to privilege escalation, SQL injection attacks, and granting unintended access to files, directories and even the entire operating system. The DISA (Defense Information Systems Agency) Security Technical Implementation Guide, provides a more universal and granular look into the common configurations that must be applied in order to keep databases secure. Included in the guide are detailed instructions on U.S. Department of Defense expectations and requirements for securing any database. Issues covered by DISA include password length, user accounts, configuration changes from default settings, file system permissions, binary file permissions, database permissions, the presence of test files (usually included with default configurations), and countermeasures that can help prevent SQL injection vulnerabilities (which occur when SQL commands are inserted with malicious intent into requests posted to front end web servers which are serviced by a SQL database). Articles such as the one written by Green SQL , concur with the DISA database security requirements, outlining the specifics of just how to implement DISA database security requirements on an installation of the MySQL database. The article goes on to describe in detail the default anonymous user accounts (with no passwords), user accounts with root permissions, privileged access to the platform file system, SQL Injection vulnerabilities, and more and how each can be mitigated simply through proper secure configuration applying the best practices contained within the DISA database security document. The “bottom line” with regard to database security is that every database has “out of the box” vulnerabilities that are common to most database implementations and should have secure configurations applied in each of the aforementioned areas prior to full deployment on a live network.
Amazon Price: $50.00 $8.34 Buy Now
(price as of Nov 24, 2016)
Harden the Operating System
Although this is true for any DBMS (Data Base Management System), installing and running a MySQL database on an operating system platform that has not been hardened by best practices security measures opens MySQL and all the databases supported by MySQL to potential infiltration by malicious software and hackers. Best practice security measures include physical access, such as placing the database server hardware in a server closet or datacenter that requires authentication before gaining access. Best practices also includes installing or configuring a firewall, disabling all but the most essential services, installing antivirus and anti-spy software that is regularly updated, and ensuring that both MySQL and the operating system platform are up to date with the most current security patches.
Block Remote Access
MySQL runs as a background service rather than an application on port TCP 3306 by default which exposes the database to potential security compromise directly over the network. If there is no requirement for remote access to the MySQL database, then certain countermeasures should be configured to prevent direct access over the network . First, configure the local host firewall to block all network access to port 3306. Next, add the “skip-networking” parameter to the [mysqld] section of the my.ini or my.cnf database engine configuration file to prevent MySQL from listening for network requests. If there are local applications that must access MySQL databases through a TCP socket, MySQL can be configured to bind to the local loopback interface address or 127.0.0.1 rather than listen on an active Ethernet network port by adding the “bind-address-127.0.0.1 to the same [mysqld] section of the my.ini or my.cnf configuration files and then configure the local client applications to connect to the MySQL database on port 3306 at address 127.0.0.1. In this way the MySQL TCP connection is still available but only to local applications as long as the local firewall is also configured to block access to the listening MySQL service (just for additional security). In cases where remote access is required, the platform and database should be configured to limit access only to those hosts that require access. To do so, the firewall should be configured to “deny all” access to the MySQL service, except for the IP addresses of hosts that require access. This can also be accomplished in Unix/Linux platforms by using the TCP Wrappers service and configuring the hosts.deny file to with the “ALL:ALL” parameter so that all network access is denied by default, then configure the hosts.allow file with the IP addresses of network hosts that require access to the database. MySQL can also be configured to allow access to only specific hosts by using the command:
"GRANT SELECT, INSERT ON mydb.* TO 'user'@'host'"
where “user” is the user name of an account that has access to the MySQL database and “host” is the host name from which the user is accessing MySQL .
Disable Use of LOCAL INFILE
By default, MySQL includes a feature that may allow a malicious attacker or malware to access MySQL files and even files outside of the MySQL directories on the platform file system unless the use of LOCAL INFILE is disabled. To disable this feature, add the “set-variable=local-infile=0” parameter to the
[mysqld] section of the my.ini or my.cnf configuration files . This configuration is a very important step in preventing SQL Injection attacks so that attackers cannot access files outside the bounds of user permissions, even when leveraging other vulnerabilities that may exist on the system such as through PHP, Python or anther popular scripting language.
Change Database Root Name and Password
Leaving a MySQL database root name and password at default is one of the most common security vulnerabilities found in vulnerable installations. To prevent attackers from using a default root login, change the root user name using the following MySQL command example:
mysql> use mysql;
mysql> update user set user="new_username" where user="root";
mysql> flush privileges;
Note in the example that “new_username” is the name to replace the default “root” account name. Then configure the password by issuing the following command:
SET PASSWORD FOR 'user_name'@'%hostname' = PASSWORD('password');
Where “user_name” is the new name of the root account and “password” is the new password for the root account . To comply with best practices the password should be at least 14 characters long, include at least one upper case and lower case character, a number and a special character.
Remove the Default Test Database
Leaving default test files such as test databases is another common issue that can enable hackers to access a MySQL installation because these files can be accessed by the default anonymous user account. Use the “drop database test” command on the MySQL terminal command line to remove the default test database.
Remove the Default Anonymous Accounts
Anonymous user accounts with blank passwords are installed with MySQL by default. Obviously if someone with malicious intent knows this fact, these anonymous user accounts will be one of the first methods they will use to access a MySQL database installation. To remove these accounts from a MySQL installation issue the DROP USER “”;” command on the MySQL terminal command line to secure the MySQL database.
Secure System Permissions
When the MySQL DBMS is installed, the MySQL binaries and files reside in very specific directories (depending upon the operating system used for the installation). To secure access to these files and directories the root or administrator account for the operating system and the system specific “mysql” user account (if one is created depending upon the platform) are the only accounts that should be granted access to the MySQL directories and files. So after installation, to ensure secure operation, configure this limited access on all files and directories used by the MySQL DBMS.
Secure Database Permissions
Similar to the platform file system directories and files, the MySQL database itself must also be configured with more restrictive permissions that prevent access to the database and the information stored in the database, to prevent unauthorized access that is possible if the permissions are left at default. To do this, execute the following command for each user account configured to access the database:
select * from users;
show grants for 'root'@'localhost';
This set of commands will reveal all user accounts that essentially have root access to the database. Once the list of user accounts is displayed, either remove the offending accounts or lower permissions of the accounts appropriately. Then to limit database viewing, add the “skip-show-database” parameter to the my.cnf or my.ini configuration file in the [mysqld] section of the file.
Change Database Root Directory from Default
If the MySQL files and directories are not in the default location, this adds another layer of complexity to discourage would be hackers from accessing the database. The default root directory can be changed during the installation process and should be assigned to a chrooted or “jailed” directory on Unix/Linux platforms or a limited access directory on Windows platforms.
Remove Installation History
The MySQL installation history file (.mysql_history) located in the MySQL directory contains many pieces of information (such as user information) an attacker could use to compromise the MySQL database if they can gain access to the file. To prevent this from happening make sure to delete the .mysql_history file once installation and configuration are completed.
Enable Database Logging
Logging should always be enabled both for troubleshooting and also to detect when unauthorized access is being attempted. To do this add the “log=logfile” parameter to the [mysqld] section of the my.cnf or my.ini files where “logfile” is the path and directory where the log files are to be stored. Since excessive log files can cause a DoS or Denial of Service condition, it is important to keep log files on a separate partition from the operating system with permissions set for only root and or mysql service user access.
Network Based IDS/IPS
Aside from firewalls mentioned earlier, network based IDS/IPS systems (Intrusion Detection Systems/Intrusion Prevention Systems) are another essential piece of a secure MySQL environment. IDS/IPS systems should be equipped with both signature-based and anomaly based detection capabilities so they can quickly detect known threats (signature based detection) and unknown threats (anomaly based detection). Additionally, IDS/IPS sensors should optimally be placed at ingress locations relative to the MySQL database(s) where malicious traffic can be detected as well as traffic from a compromised MySQL DBMS (in order to protect the rest of the organization in the event of a MySQL security breach).
Database Security Policies
Database security policy dictates the database configuration, environment and data handling to which an organization must adhere in order to ensure the security of information contained within that database . The security configurations outlined above should be contained within a database security policy along with proper implementation recorded in database security procedures and guidelines that are part of a larger organizational security program that enforces policy compliance. Elements of a database security policy include, but are not limited to the specification of acceptable authentication types and configuration, access controls (authorization), secure database configuration, auditing (includes type and frequency), and countermeasures that must be deployed within the database environment . Database security procedures differ from the security policy in that procedures describe how to implement the elements of the security policy. Elements of a database security procedure include but are not limited to a brief introduction about intended purpose of the procedure, a specification of the database types and versions to which the procedure applies, list of personnel authorized to perform the procedure, and the steps necessary to perform the procedure.
Following database best security practices is the primary way to ensure that a MySQL database installation is secure. Ensuring that all MySQL binaries and the operating system platform is patched and updated is essential to keeping the database protected from security vulnerabilities as they are discovered. A security hardened operating system platform combined with a network environment that employs countermeasures such as IDS/IPS and firewalls will ensure the security of the information managed by vigilant administration and the MySQL DBMS.