Following up on this entry, here are some more best practices to secure MySQL in a production environment.

But before moving forward, let me pay credit to Lenz Grimmer who helped me to put this information together.

After setting a password for the MySQL root account and removing the test database and anonymous account you can also limit the remote access to MySQL to a specific host. You do this by setting the bind-address attribute in the /etc/mysql/my.cnf file to the host ip-address:

bind-address=ip-address

If you set bind-address to 127.0.0.1, which is the loopback address, then  MySQL only accepts connections from the host where it runs.

If you uncomment skip-networking in my.cnf MySQL only …

Following up on this entry, here are some more best practices to secure MySQL in a production environment.

But before moving forward, let me pay credit to Lenz Grimmer who helped me to put this information together.

After setting a password for the MySQL root account and removing the test database and anonymous account you can also limit the remote access to MySQL to a specific host. You do this by setting the bind-address attribute in the /etc/mysql/my.cnf file to the host ip-address:

bind-address=ip-address

If you set bind-address to 127.0.0.1, which is the loopback address, then  MySQL only accepts connections from the host where it runs.

If you uncomment skip-networking in my.cnf MySQL …

Following up on this entry, here are some more best practices to secure MySQL in a production environment.

But before moving forward, let me pay credit to Lenz Grimmer who helped me to put this information together.

After setting a password for the MySQL root account and removing the test database and anonymous account you can also limit the remote access to MySQL to a specific host. You do this by setting the bind-address attribute in the /etc/mysql/my.cnf file to the host ip-address:

bind-address=ip-address

If you set bind-address to 127.0.0.1, which is the loopback address, then  MySQL only accepts connections from the host where it runs.

If you uncomment skip-networking in my.cnf MySQL …

You finished the development phase of your Web project, and you are now heading to production. This means that your web-site will be soon on-line, visible on the Internet, and may become a potential target for attacks.

During development, you have been using MySQL on your laptop, and since you are the only one accessing your laptop you used the default configuration as-is. You are perfectly right in doing that, in fact MySQL is pretty secure by default, but here are a set of post-installation best practices to bring MySQL security to the next level.

1) Set a password for the root account. Note that by "root account" I don't mean the super-user of the operating system, but the super-user of MySQL itself:
$ mysql ­-u root mysql
mysql> SET PASSWORD FOR root@localhost=PASSWORD('new_password');

2) If they exist, remove the MySQL anonymous account - or assign a password to it - and …

I want to highlight the importance of reviewing mysql’s initial set of accounts.
Say you have a mysql on abc.def.ghi.jkl running on port 3306 anonymous account with privileges without a password, then:
1. mysql (if issued on localhost)
2. mysql -h abc.def.ghi.jkl
3. mysql -u ” -h abc.def.ghi.jkl
4. mysql -u ” -h abc.def.ghi.jkl -P 3306
5. mysql -u user_which_does_not_exist -h abc.def.ghi.jkl

will all manage to get into mysql given the way mysql authenticates users is against your username and client host from where you are connecting.

This verification is done versus the following columns in the mysql.user table, i.e., User,Host and Password columns.
An entry in the mysql.user table with the following values User=”, Host=’%’ will accept ANY user connecting from ANYWHERE in the world, thus disabling ANY security. Hence the reason for this blog post highlighting the importance …

I am publishing my MySQL related bookmark collection http://www.mysqlpreacher.com/bookmarks/.

Feel free to send me links you think might be good to add in order to help others.

Remember, SHARING IS CARING!!! …. we get so much for free, why shouldn’t we give some back?

Cheers,
Darren

We just had a booboo in one of our internal systems, causing it to not come up properly on reboot. The actual mishap occurred several weeks ago (simple case of human error) and was in itself a valid change so monitoring didn’t raise any concerns. So, as always, it’s interesting and useful to think about such events and see what we can learn.

Years ago, but for some now still, one objective is to see long uptime for a server, sometimes years. It means the sysadmin is doing everything right, and thus some serious pride is attached to this number. As described only last week in Modern Uptime on the Standalone Sysadmin blog, security patches are a serious issue these days, and so (except if you’re using ksplice sysadmin quality has become more a question of when you …

… You are full of shit.

I don’t know how effective your scare-mongering cash-extortion tactics are, but they don’t really help neither your users, nor vendors, nor anyone else.

It all starts when major vulnerability databases start authoritatively spouting out crap like this:

A vulnerability has been reported in MySQL, which can be exploited to compromise a vulnerable system.
The vulnerability is caused due to an unspecified error and can be exploited to cause a buffer overflow. (Secunia)

Or crap like this:

MySQL is prone to a buffer-overflow vulnerability because if fails to perform adequate boundary checks on user-supplied data.
An attacker can leverage this issue to execute arbitrary code within the context of the vulnerable application. Failed exploit attempts will result in a denial-of-service condition. ( …

Just a small note to advise that Securich reached 0.1.4.
Some new tools include:
* Added Password complexity
* Enhanced `set_password` – Old password is now necessary to replace it by a new one
* Enhanced Revoke privileges to accept regexp
* Added Block user@hostname on a database level
* Added Creation of reserved usernames
* Added Help stored procedure displays help for each stored proc
* Enhanced `create_update_role` to include the removal of privilages from roles
* Enhanced `grant_priveleges` on `alltables` for a database without tables would terminate with an error instead of gracefully (now fixed)
* Added Restore user@hostname on a database level
* Removed ’show warnings’ from sql installation

The database design using workbench is also available in the db folder (for easier understanding of what lies …

1. Defragging the Stimulus -- each [recovery] site has its own silo of data, and no site is complete. What we need is a unified point of access to all sources of information: firsthand reports from Recovery.gov and state portals, commentary from StimulusWatch and MetaCarta, and more. Suggests that Recovery.gov should be the hub for this presently-decentralised pile of recovery data.
2. Memetracker -- site accompanying the research written up by the New York Times as Researchers at Cornell, using powerful computers and clever algorithms, studied the news cycle by looking for repeated phrases and tracking their appearances on 1.6 million …