(mysql.info.gz) Security against attack
Info Catalog
(mysql.info.gz) Security guidelines
(mysql.info.gz) Security
(mysql.info.gz) Privileges options
5.4.2 Making MySQL Secure Against Attackers
-------------------------------------------
When you connect to a MySQL server, you should use a password. The
password is not transmitted in clear text over the connection. Password
handling during the client connection sequence was upgraded in MySQL
4.1.1 to be very secure. If you are using an older version of MySQL,
or are still using pre-4.1.1-style passwords, the encryption algorithm
is less strong and with some effort a clever attacker who can sniff the
traffic between the client and the server can crack the password. (See
Password hashing for a discussion of the different password
handling methods.) If the connection between the client and the server
goes through an untrusted network, you should use an SSH tunnel to
encrypt the communication.
All other information is transferred as text that can be read by anyone
who is able to watch the connection. If you are concerned about this,
you can use the compressed protocol (in MySQL 3.22 and above) to make
traffic much more difficult to decipher. To make the connection even
more secure, you should use SSH to get an encrypted TCP/IP connection
between a MySQL server and a MySQL client. You can find an Open Source
SSH client at `http://www.openssh.org/', and a commercial SSH client at
`http://www.ssh.com/'.
If you are using MySQL 4.0 or newer, you can also use internal OpenSSL
support. Secure connections.
To make a MySQL system secure, you should strongly consider the
following suggestions:
* Use passwords for all MySQL users. A client program does not
necessarily know the identity of the person running it. It is
common for client/server applications that the user can specify
any username to the client program. For example, anyone can use
the `mysql' program to connect as any other person simply by
invoking it as `mysql -u OTHER_USER DB_NAME' if OTHER_USER has no
password. If all users have a password, connecting using another
user's account becomes much more difficult.
To change the password for a user, use the `SET PASSWORD'
statement. It is also possible to update the `user' table in the
`mysql' database directly. For example, to change the password of
all MySQL accounts that have a username of `root', do this:
shell> mysql -u root
mysql> UPDATE mysql.user SET Password=PASSWORD('NEWPWD')
-> WHERE User='root';
mysql> FLUSH PRIVILEGES;
* Don't run the MySQL server as the Unix `root' user. This is very
dangerous, because any user with the `FILE' privilege will be able
to create files as `root' (for example, `~root/.bashrc'). To
prevent this, `mysqld' refuses to run as `root' unless that is
specified explicitly using a `--user=root' option.
`mysqld' can be run as an ordinary unprivileged user instead. You
can also create a separate Unix account named `mysql' to make
everything even more secure. Use the account only for
administering MySQL. To start `mysqld' as another Unix user, add
a `user' option that specifies the username to the `[mysqld]'
group of the `/etc/my.cnf' option file or the `my.cnf' option file
in the server's data directory. For example:
[mysqld]
user=mysql
This causes the server to start as the designated user whether you
start it manually or by using `mysqld_safe' or `mysql.server'.
For more details, see Changing MySQL user.
Running `mysqld' as a Unix user other than `root' does not mean
that you need to change the `root' username in the `user' table.
Usernames for MySQL accounts have nothing to do with usernames for
Unix accounts.
* Don't allow the use of symlinks to tables. (This can be disabled
with the `--skip-symbolic-links' option.) This is especially
important if you run `mysqld' as `root', because anyone that has
write access to the server's data directory then could delete any
file in the system! Symbolic links to tables.
* Make sure that the only Unix user with read or write privileges in
the database directories is the user that `mysqld' runs as.
* Don't grant the `PROCESS' or `SUPER' privilege to
non-administrative users. The output of `mysqladmin processlist'
shows the text of the currently executing queries, so any user who
is allowed to execute that command might be able to see if another
user issues an `UPDATE user SET password=PASSWORD('not_secure')'
query.
`mysqld' reserves an extra connection for users who have the
`SUPER' privilege (`PROCESS' before MySQL 4.0.2), so that a MySQL
`root' user can log in and check server activity even if all normal
connections are in use.
The `SUPER' privilege can be used to terminate client connections,
change server operation by changing the value of system variables,
and control replication servers.
* Don't grant the `FILE' privilege to non-administrative users. Any
user that has this privilege can write a file anywhere in the
filesystem with the privileges of the `mysqld' daemon! To make
this a bit safer, files generated with `SELECT ... INTO OUTFILE'
will not overwrite existing files and are writable by everyone.
The `FILE' privilege may also be used to read any file that is
world-readable or accessible to the Unix user that the server runs
as. With this privilege, you can read any file into a database
table. This could be abused, for example, by using `LOAD DATA' to
load `/etc/passwd' into a table, which then can be displayed with
`SELECT'.
* If you don't trust your DNS, you should use IP numbers rather than
hostnames in the grant tables. In any case, you should be very
careful about creating grant table entries using hostname values
that contain wildcards!
* If you want to restrict the number of connections allowed to a
single account, you can do so by setting the
`max_user_connections' variable in `mysqld'. The `GRANT'
statement also supports resource control options for limiting the
extent of server use allowed to an account.
Info Catalog
(mysql.info.gz) Security guidelines
(mysql.info.gz) Security
(mysql.info.gz) Privileges options
automatically generated byinfo2html