We’re not sure exactly how but we believe our old vmin server, with about 1000 users, got hacked and defaced so it was decided it was best to take it offline and reinstall vmin from scratch.
Last week we started installing and configuring our new vmin server. Like the previous one, it is running Ubuntu 22.04 in an Azure VM but this time we are installing with a different networking config plus additional security software and hardening. Some of this security software doesn’t like ZFS so we’ve been forced to downgrade to using btrfs instead
I have only ever installed virtualmin once before and I’ve never had to transfer hundreds of users/domains from one virtuamin install to another which is the thrilling prospect I am faced with now. We need to transfer most of the users files and their databases from the compromised machine to the new one in the safest and hopefully the easiest way. Some users use mysql, some postgres and some might use them both. They’re all using apache.
What is the easiest way to transfer several hundred users virtualmin user accounts from one vmin install to another? I suppose one way would be to create a script to archive all of the accounts, scp/sftp or whatever them over and then restore them all but is there a better way?
Of course things are not that simple. I’m wondering about a few other things on top of this:
The old server used mysql and postgres but vmin seems to default to using mariadb these days. Maybe I should migrate to mariadb for this new server? I don’t suppose its possible to restore a load of vmin accounts that were using mysql on a vmin server thats only got mariadb installed is it? I presume I’ll have to install mysql on the new server to restore any vmin accounts that are using mysql databases or does the account restore process support restoring mysql dbs to mariadb?
Does vmin have a feature to import databases from backups in a safer way when you’re in this sort of situation, rather than just blindly importing every db as they were on the old server?
On the old vmin server I mostly stuck with the defaults for a lot of things including storing users mysql databases under /var/… On this new server I would prefer to store users mysql/mariadb and postgres databases within their home dirs instead. Can I have my new vmin server configured to store databases in users home dirs or will I have to use the same db storage config as on the old server when I’m importing the databases to the new server?
The new server will be using the same domain as the old one but we plan to use different usernames for new users to help reduce password reuse.
The quick answer is Virtualmin’s own backup and restore. It offers granular control over what can be restored. Since your old server still works (yeah, I know you have taken it offline after it was hacked) you could nevertheless use it to create a backup and then quickly restore on your new server. Obviously this will have to be done in a planned and iterative manner so that the hacker does not continue to have access to your new server.
not sure what defaced means but I don’t think I would trust any backup that was taken after your server got defaced, if you have a backup that predates this event use that instead
I would agree with that. However Virtualmin’s backup offers granular control over what can be restored and in the absence of a known good backup, it is possible to selectively restore (as against a full restore) from a compromised server to a new one without carrying over the exploit that the hacker had used to gain unauthorised access.
This is much better than manually creating domains and users.
I don’t think I would trust any backup that was taken after your server got defaced
This will be down to how your server got hacks, did multiple sites get hacked? Probably one got hacked, gave access to your server via an exploit and then they went sideways.
This means that the entry point might still be there.
You could scan with ClamAV the public directories for an obvious exploits or just manually have a look in the public HTML
Old CMS software is a usual cause or a very outdated OS.
What I would do
Backup all of the sites before doing anything
Check for virus/exploits on old server before moving, if via the websites you can usually see some dodgy files in the public_html
Update software where possible
Move the sites over in batches and check each one
Do you have a known good backup of the server/websites? You could restore from this to the new server but you still need to check for exploits as sometimes they lay dormant on purpose.
What about mysql to mariadb? Would you recommend that we just stick to mysql or should we attempt to switch to mariadb, if we can do that in a pretty automated manner.
I expect that won’t be an option tbh but if it is then we might consider doing that.
A dump from an old-ish version of MySQL restored to a new-ish version of MariaDB should work fine. New versions of MySQL have begun to diverge in incompatible ways, making it harder to automatically dump/restore without some manual intervention (which is a good reason to get TF out of MySQL ASAP, and avoid it in the future).
