Following in the footstep of a Solusvm database leak in November 2012, Damian Harouff from IPXcore LLC decided that it was time to make some changes to their database if something like that would happen to them.

The Solusvm database does not contain much personal information that would be of interest to anyone who gets their hands on it. What the database do have, are IP and root passwords (if it has been set from Solusvm) for all created VPS.

As Damian puts it “Even if the passwords are encrypted/hashed/salted/voodoo magic/something! If the software can decrypt a password, so can an attacker.”

The only reason for Solus to save the root password in the database it will attempt to reset the root password after a reinstall from the Solus Control Panel. I have never experienced a reinstall where the password failed to reset to the one I set when I bought the VPS in the first place but at the same time there has been reported occasions where this has failed, causing problems both for the customer and for the provider.

The solution to this is in its simplicity, pure geniality, namely taking advantage of a MySQL feature to automatically empty the “rootpassword” column every 5 minutes.

[alert style=”green”]An event is similar to a trigger. However, rather than running in response to a data change, events can be scheduled to run any number of times during a specific period. In effect, it’s a database-only cron job. Events have been supported in MySQL since version 5.1. They are ideal for maintenance tasks such as data archiving or report generation which can be scheduled during off-peak times. From http://www.sitepoint.com/how-to-create-mysql-events/ [/alert]

Because Solus is using Mysql 5.1, events are available, you will need to explicitly set the events engine to on (also from http://www.sitepoint.com/how-to-create-mysql-events/ ):

MySQL events are executed by a special event scheduler thread. It’s disabled by default so use the following MySQL command can determine whether it’s running:

[precode]SHOW PROCESSLIST;[/precode]

If the scheduler is running, at least two rows will be shown and one will have its user field set to “event_scheduler”. If only one row is returned, the scheduler is disabled and events will not run. You can ensure the scheduler starts when MySQL is launched with the command-line option –event-scheduler=ON or setting event_scheduler=ON in your MySQL configuration file (my.cnf or my.ini on Windows). Alternatively, you can start the scheduler from the MySQL command line:

[precode]SET GLOBAL event_scheduler = ON;[/precode]

If you decide to enable it in your configuration file you probably need to reload/restart mysqld. Enabling it from the mySQL commandline and you are good to go.

[alert style=”green”]NOTICE: This information is being offered for utilization on your own good judgement. This site, Damian, IPXcore, or anyone else for that matter are not responsible for possible data loss, angry clients, your dog being killed, etc. It can not be said enough times: Make proper backups, and test the event handler on a separate databases before committing it to your live database.[/alert]

After, and only after you have made backups (perhaps even backups of the backups and a test-restore of the backups) execute this code on a mySQL commandline:

[precode]CREATE EVENT ClearPWColumn ON SCHEDULE EVERY 5 MINUTE STARTS ‘2013-03-01 00:00:01’ ON COMPLETION PRESERVE ENABLE DO UPDATE vservers SET rootpassword = NULL [/precode]

Every 5 minutes, MySQL will automatically set the content of every row of the “rootpassword” column in the vservers table to NULL.

This will try to, when the client reinstalls their OS, set the root password to an empty value, which is not allowed.

Since I personally don’t have a Solus installation I will show the demonstration that Damian gave:

[precode][root@sapphire ~]# vzctl set 106 –userpasswd root: Running container script: /etc/vz/dists/scripts/set_userpass.sh Password change failed[/precode]

Damian adds these final words as a disclaimer:
Please note that on our installation, this does not result in containers with blank root passwords.
Please add a step into your verification after implementation to ensure that on your installation, client containers aren’t being installed with blank passwords.
The user will need to set their root password after reinstalling their OS, using the existing functionality in Solus.
This method ensures that the client’s selected root password only lives in the database for 5 minutes.

 

If a 5 minute interval is too long you can reduce the interval to SECONDS
[precode]CREATE EVENT ClearPWColumn ON SCHEDULE EVERY 300 SECONDS STARTS ‘2013-03-01 00:00:01’ ON COMPLETION PRESERVE ENABLE DO UPDATE vservers SET rootpassword = NULL [/precode]

As a third option, instead of using EVENT, one could use the TRIGGER. Read more about triggers here. Please post in the comments section your solution if it differs from this.

Running this EVENT in a very short intervall will put more stress on your mySQL Server. Make sure you can handle it.