John offers a broad overview of MySQL security. He does not cover everything, but provides a good intro for someone new to MySQL. Here are some notes from his talk:
Security Priorities:
– Data not stolen or tampered with.
– only access data that you’re authorized to access
– secure passwords
– host level security
– obviously dont run MySQL as a privledged user.
– patch system regularly
– net security
– bind to localhost or skipnetworking unless you have remote clients
– firewalls
– use ssl
– what kind of load does ths add
– authentication in mysql
– 4.1 includes a new auth scheme with more secure password hashes.
– 4.1 supports old protocols, but new protocol is highly recomended.
– SSL support from slaves to marster, clieent to server, etc.
– grant can now allow you to require certs, issuers, specific ciphers, etc.
– limit connections, qeuries, reads, writes, etc per hour.
views:
– you can create views so that a specific user only sees rows that meet his privs / restrictions.
– Groups / Roles, are recognized as necessary by MySQL developers. They hope to include them in 5.1, but make no guarantees.
– ideas for web app users:
– give each script/object/method a user name so that for security and logging reasons which scripts did what, see who is connected,
– interactive help now included in MySQL!
– ex: help grant types
– MySQL “worm” of Jan ’05
The MySQL work would scan tcp port 3306 on the public net and then attept to brute force root. It had a very small list of common passwords and managed to sucessfully connect to an alarming number of servers. The worm would then create a table with a blob column where it would insert the words code. It would then dump itself to a DLL file and drop the table. Then by creating a function it can run itself via mysql.
The worm did not last long as the connecting zombies caused a DOS attack on the IRC servers where the zombied nodes were managed,
– MySQL 4.1 now includesfeatures to make this more difficult:
– User defined functions must define and meet certain criteria or they will be considered “suspicious” and not run.
– root@ accounts were reomved from windows, no other distros ever had them.
– wont let you use .. or other pathname info in the name of a shared object