26 Jan, 2009 in MySQL by admin

How to Secure MySQL Against Attackers

When you connect to a , 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 still using pre-4.1.1-style passwords, the encryption algorithm is not as strong as the newer algorithm. With some effort, a clever attacker who can sniff the traffic between the client and the server can crack the password.

MySQL Enterprise. The MySQL Enterprise Monitor enforces best practices for maximizing the security of your servers.

All other information is transferred as text, and can be read by anyone who is able to watch the connection. If the connection between the client and the server goes through an untrusted network, and you are concerned about this, you can use the compressed protocol to make traffic much more difficult to decipher. You can also use MySQL’s internal SSL support to make the connection even more secure.  Alternatively, use SSH to get an encrypted TCP/IP connection between a and a MySQL client. You can find an Open Source at http://www.openssh.org/, and a commercial at http://www.ssh.com/.

To make a MySQL system secure, you should strongly consider the following suggestions:

  • Require all MySQL accounts to have a password. 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 user name to the client program. For example, anyone can use the mysql program to connect as any other person simply by invoking it as mysql -uother_user db_name if other_user has no password. If all accounts have a password, connecting using another user’s account becomes much more difficult.
  • Never run the as the root user. This is extremely dangerous, because any user with the FILEprivilege is able to cause the server to create files as root (for example, ~root/.bashrc). To prevent this, mysqldrefuses to run as root unless that is specified explicitly using the --user=root option.mysqld can (and should) be run as an ordinary, unprivileged user instead. You can create a separate account named mysql to make everything even more secure. Use this account only for administering MySQL. To start mysqld as a different user, add a useroption that specifies the user name in the [mysqld] group of the my.cnf option file where you specify server options. 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 ormysql.server.

    Running mysqld as a user other than root does not mean that you need to change the root user name in the user table. User names for MySQL accounts have nothing to do with user names for accounts.

  • Do not allow the use of symlinks to tables. (This capability 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!
  • Make sure that the only user account with read or write privileges in the database directories is the account that is used for running mysqld.
  • Do not grant the PROCESS or SUPER privilege to non-administrative users. The output of mysqladmin processlist andSHOW PROCESSLIST shows the text of any statements currently being executed, so any user who is allowed to see the server process list might be able to see statements issued by other users such as UPDATE user SET password=PASSWORD('not_secure').mysqld reserves an extra connection for users who have the SUPER privilege, 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 servers.

  • Do not grant the FILE privilege to non-administrative users. Any user that has this privilege can write a file anywhere in the file system with the privileges of the mysqld daemon. To make this a bit safer, files generated with SELECT ... INTO OUTFILE do 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 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 do not trust your DNS, you should use IP numbers rather than host names in the grant tables. In any case, you should be very careful about creating grant table entries using values that contain wildcards.
  • If you want to restrict the number of connections allowed to a single account, you can do so by setting themax_user_connections variable in mysqld. The GRANT statement also supports resource control options for limiting the extent of server use allowed to an account.
  • --ssl*Options that begin with --ssl specify whether to allow clients to connect via SSL and indicate where to find SSL keys and certificates.

Bookmark This
Enjoyed this article? Subscribe to the full RSS Feed

Related Posts

One Response so far | Have Your Say!

  1. Alexwebmaster - Gravatar

    Alexwebmaster  |  March 3rd, 2009 at 3:41 am #

    Hello webmaster
    I would like to share with you a link to your site
    write me here preonrelt@mail.ru

Leave a Feedback

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>