Mysql Database Security Configuration Introduction 1th/2 page _mysql

1. Preface :

MySQL database is a completely networked Cross-platform relational database system, and a distributed database management system with client/server architecture. The utility model has the advantages of strong function, simple use, convenient management, fast operation speed and strong security and reliability, and can be used in many languages to write programs to access the MySQL database, especially with PHP is a gold combination, which is widely used. MySQL database Security configuration is also necessary, now in the MySQL database security is often threatened, so the security configuration is essential.

Since MySQL is a multi-platform database, its default configuration should be considered applicable in all circumstances, so it should be further secured in our own use environment. As a MySQL system administrator, we are responsible for maintaining the data security and integrity of the MySQL database system.

MySQL database security configuration must start from two aspects, system internal security and external network security, in addition, we will also brief programming to pay attention to some of the problems and some tips.

　2. Internal security of the system

First of all, a brief description of the MySQL database directory structure. MySQL is installed and the Mysql_db_install script is run to create the data directory and initialize the database. If we install with a MySQL source package and the installation directory is/usr/local/mysql, then the data directory will generally be/usr/local/mysql/var. The database system consists of a series of databases, each containing a series of database tables. MySQL is using database name in the data directory to establish a database directory, each database table with the database table name as the file name, the extension is myd, myi, frm three files into the database directory.

MySQL's authorization table provides a flexible access control to the database, but if the local user has read access to the library files, the attacker can simply package the database directory and then copy it to their native data directory to access the stolen database. So MySQL Host security is the most important problem, if the host is not secure, the attacker control, then the security of MySQL can not talk about. The second is the security of data directories and data files, which is the problem of permission setting.

From the MySQL master station some old binary distributions, the 3.21.xx version of the Data directory property is 775, so very dangerous, any local users can read the data directory, so the database file is very insecure. In the 3.22.xx version of the data directory, the property is 770, this property is also a bit dangerous, local users can read and write, so the data file is not secure. 3.23.XX version of the data directory of the property is 700, this is better, only the user to start the database can read and write database files, to ensure the security of local data files.

If the user who started the MySQL database is MySQL, then the directories and files like the following are safe, please note the Data directory and the following attributes:

Shell>ls-l/usr/local/mysql

Total 40

Drwxrwxr-x 2 root root 4096 Feb 20:07 bin

Drwxrwxr-x 3 root root 4096 Feb 20:07 include

Drwxrwxr-x 2 root root 4096 Feb 20:07 info

Drwxrwxr-x 3 root root 4096 Feb 20:07 Lib

Drwxrwxr-x 2 root root 4096 Feb 20:07 libexec

Drwxrwxr-x 3 root root 4096 Feb 20:07 man

Drwxrwxr-x 6 root root 4096 Feb 20:07 mysql-test

Drwxrwxr-x 3 root root 4096 Feb 20:07 share

Drwxrwxr-x 7 root root 4096 Feb 20:07 sql-bench

drwx------4 mysql mysql 4096 Feb 20:07 var

Shell>ls-l/usr/local/mysql/var

Total 8

drwx------2 mysql mysql 4096 Feb 20:08 MySQL

drwx------2 mysql mysql 4096 Feb 20:08 test

Shell>ls-l/usr/local/mysql/var/mysql

Total 104

-RW-------1 mysql mysql 0 Feb 20:08 columns_priv. MyD

-RW-------1 mysql mysql 1024 Feb 20:08 columns_priv. Myi

-RW-------1 mysql mysql 8778 Feb 20:08 columns_priv.frm

-RW-------1 MySQL mysql 302 Feb 20:08 db. MyD

-RW-------1 mysql mysql 3072 Feb 20:08 db. Myi

-RW-------1 mysql mysql 8982 Feb 20:08 db.frm

-RW-------1 mysql mysql 0 Feb 20:08 func. MyD

-RW-------1 mysql mysql 1024 Feb 20:08 func. Myi

-RW-------1 mysql mysql 8641 Feb 20:08 func.frm

-RW-------1 mysql mysql 0 Feb 20:08 host. MyD

-RW-------1 mysql mysql 1024 Feb 20:08 host. Myi

-RW-------1 mysql mysql 8958 Feb 20:08 host.frm

-RW-------1 mysql mysql 0 Feb 20:08 tables_priv. MyD

-RW-------1 mysql mysql 1024 Feb 20:08 tables_priv. Myi

-RW-------1 mysql mysql 8877 Feb 20:08 tables_priv.frm

-RW-------1 mysql mysql 428 Feb 20:08 user. MyD

-RW-------1 mysql mysql 2048 Feb 20:08 user. Myi

-RW-------1 mysql mysql 9148 Feb 20:08 user.frm

If the owner and attributes of these files are not the same, please amend them with the following two commands:

Shell>chown-r Mysql.mysql/usr/local/mysql/var

Shell>chmod-r Go-rwx/usr/local/mysql/var

Starting a remote service with the root user has been a security taboo because remote attackers are most likely to gain full control of the host if there is a problem with the service program. MySQL made a small change at the start of version 3.23.15, and the default installation service is to be started with the MySQL user and not allow the root user to start. If you want to start with the root user, you must add the--user=root parameter (./safe_mysqld--user=root &). Because MySQL has the load DATA infile and select ... into outfile SQL statement, if the root user started the MySQL server, then the database user has the root user write permission. However, MySQL has made some restrictions, such as the load DATA infile can only read the global readable files, SELECT ... into outfile cannot overwrite files that already exist.

Local log files cannot be ignored, including shell logs and MySQL own logs. Some users log on locally or back up the database in order to facilitate the map, sometimes in the command-line parameters directly with the password of the database, such as:

Shell>/usr/local/mysql/bin/mysqldump-uroot-ptest Test>test.sql

Shell>/usr/local/mysql/bin/mysql-uroot-ptest

These commands are recorded in the history file by the shell, such as bash writing to the user directory's. bash_history file, and if the files are inadvertently read, the database password will leak. SQL commands executed after the user logs in to the database are also recorded in the user directory's. mysql_history file by MySQL. If a database user modifies the database password with an SQL statement, it is also compromised by the. mysql_history file. So we in the shell landing and backup when not directly after-p password, but in the prompt and then enter the database password.

In addition to these two files we should also not let it record our operation, just in case.

Shell>rm. Bash_history. mysql_history

Shell>ln-s/dev/null. bash_history

Shell>ln-s/dev/null. mysql_history

The two commands at the door link the two files to the/dev/null, so our operations will not be recorded in these two files.

Current 1/2 page 12 Next read the full text