Powered by eUKhost®


No announcement yet.

Securing MySQL database servers !

  • Filter
  • Time
  • Show
Clear All
new posts

  • Securing MySQL database servers !

    MySQL is a multi-threaded, multi-user database management system which is available for both, Linux and Windows..
    It's a is a free, open source product commonly used by thousands of hosting providers with various web applications using it as their default database.

    It's commonly employed with most of the popular server-side scripting languages including PHP, JSP, and ASP as well as C, C++, Java, Perl and Python.
    Some of these applications are written with keeping security in mind, and some are not which is a pity thing..

    Here are few steps that should be taken into consideration when using a MySQL database with proper security...
    • First of all, any MySQL user account which is setup on a server, should compulsorily have a password.. specially a hard to guess stronger one
    • Check the permissions & ownerships of configuration files, make sure that per-user configuration files , if any, are not viewable by other users of the system, stored in non-public locations & with the permissions of 600.
    • MySQL database must be executed in a 'Chrooted environment': We can achieve that by chrooting MySQL's main daemon (mysqld).. Chrooting means creating a new root directory structure, moving all daemon files to it, and running the proper daemon and all child processes in that new environment. This way the daemon will have access only to the new directory structure & not to any other area on the filesystem. In short; chrooting changes the root directory and restricts a process to an isolated subset of the file system..
    • MySQL processes should be run under a unique UID/GID that is not used by any other system process: MySQL server & non-administrative users should never be run as the Unix root user.. This is extremely dangerous, because any user with the FILE privilege would be able to cause the server to create files anywhere in the filesystem with the privileges of the mysqld daemon or as root (for example, ~root/.bashrc). To prevent this, mysqld refuses to run as root unless that is specified explicitly using the --user=root option.
    • Don't allow the use of symlinks to tables, especially when running mysqld as root, because anyone having write access to the server's data directory then could delete any file in the system.. This capability can be disabled with the --skip-symbolic-links option.
    • Further more you can change the standard MySQL port from 3306 to something else, ie: 48347 or any random number from 0 to 65536 but unused ports only, or else you may cause port conflicts stopping the services falling under those specific ports..
    • MySQL root's account must be protected by a hard to guess password & the administrator's [root] account will be renamed to something else. 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...
    • We have to make sure that the only Unix user with read or write privileges in the database directories is the user that mysqld runs as.. Only local access to MySQL should be allowed.
    • If you aren't going to access the DB remotely, disable the remote access by using the --skip-networking option in the my.cnf file. We can also add the variable bind-address= in your my.cnf file to force the server to bind locally rather than to any particular IP thus blocking the remote connections.
    • Anonymous accesses to the database (by using the nobody account) must be strictly disabled..
    • Do not grant the PROCESS or SUPER privilege to non-administrative users. The output of mysqladmin processlist and SHOW 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. The SUPER privilege can be used to terminate client connections, change server operation by changing the value of system variables, and control replication servers.
    • Use IPs 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.
    • Restricting the number of connections allowed to a single account by setting the max_user_connections variable in mysqld can also make the DB server stable & easily manageable. The GRANT statement also supports resource control options for limiting the extent of server use allowed to an account.
    • Finally remove all sample & test databases and tables, they are unnecessary & can lead into creation of security holes in the MySQL DB server.
    Running database servers in a chrooted environment, applying several restrictions from within the configuration, disabling listening on 3306/TCP port and applying strong passwords to users' accounts we can make the database immune to a many of the attacks that would be possible with the default installation. Although no method will let us achieve 100% security, applying the above mentioned methods will at least limit attack possibilities from those who visit the servers with unfair intentions...

    ####______________________________________________ ####
    No software installation is secure until you add that particular layer of protection...
    Rock _a.k.a._ Jack Daniel

    Follow eUKhost on Twitter || Join eUKhost Community on Facebook

  • #2

    I wonder if you would be kind enough to explain how to chroot a program, and the consequences of it..

    It confuses me because the program will need access to libraries outside of its new root directory... will it still be able to get to them?