So in my previous post we talked about some low hanging fruit in terms of securing your web applications MySQL server. Many of the items we discussed are based on the Principal of Least Privilege. This principal guides us as we secure out applications. Quite simply it means to restrict functionality, users and programs to fit the task that they are supposed to do. For example in our previous post we discussed creating an application db user that the application will use to access the app data in the schema. This user is limited in to only have access to the web app schema. In addition, we restrict this ID to only have CREATE, UPDATE, and DELETE on the tables in this schema. This is the Principal of Least Privilege in action.
This Principal can be applied across IT and business in many different ways. Users within this application should be restricted to be able to perform only the functions we want to allow and no more. The security officer that rekeys the application encryption should have an id that will only be able to do that specific task. The UNIX permission system is a another example if configured correctly. A user has read, write execute over his files and can set others so they only have read. UNIX sudo is really a violation of this principal, however, it's usage is logged so that is a mitigating control.
Tuesday, June 28, 2011
Thursday, June 2, 2011
Securing MySQL
Just a quick running list of the techniques needed to secure a MySQL server. If you have comments or other techniques, post them!
1. Do not use the MySQL root pass as the application password. Do not use the root user as your application user.
2. Setup an application specific id and only give it SELECT, UPDATE, DELETE for the specific tables of the application or to the application schema only.
3. Passwords for these ids must be 15 chars long
4. DB Passwords stored in application files must have the correct ACLs.
5. Learn how to use the creation of the user id to lock the db for access only from the application server. For example if your app server is at 192.168.0.4 then the application user would be applicationuser@192.168.0.4. This 'locks' the db from only accepting traffic from the server listed. If the db is colocated with the app server, then specify the user like this - applicationuser@localhost. Also assuming you need to login to the DB server to do maint then your root user would be root@localhost. This would force you to have localhost access before you could login as root.
6. Use a Object Relational Mapping technology to front the DB, thus preventing SQL injection attacks. If you must script, NEVER EVER concatenate SQL. If no ORM is availble, use whatever languages parameterized SQL scheme.
1. Do not use the MySQL root pass as the application password. Do not use the root user as your application user.
2. Setup an application specific id and only give it SELECT, UPDATE, DELETE for the specific tables of the application or to the application schema only.
3. Passwords for these ids must be 15 chars long
4. DB Passwords stored in application files must have the correct ACLs.
5. Learn how to use the creation of the user id to lock the db for access only from the application server. For example if your app server is at 192.168.0.4 then the application user would be applicationuser@192.168.0.4. This 'locks' the db from only accepting traffic from the server listed. If the db is colocated with the app server, then specify the user like this - applicationuser@localhost. Also assuming you need to login to the DB server to do maint then your root user would be root@localhost. This would force you to have localhost access before you could login as root.
6. Use a Object Relational Mapping technology to front the DB, thus preventing SQL injection attacks. If you must script, NEVER EVER concatenate SQL. If no ORM is availble, use whatever languages parameterized SQL scheme.
Subscribe to:
Posts (Atom)
