Forcing urBackup through HTTPS

UrBackup is an open source top-notch server software for making live, bare-metal backups and storing those backups as VHDs. These VHDs can then be instantly virtualized by Hyper-V, KVM, and maybe VirtualBox too. These VHDs could also be slowly imported into XenServer or vSphere and virtualized there

The point is: not only do you get scheduled, self-cleaning, differential backups of running machines, but you can instantly restore them to a VM even if their original hardware recently exploded (also you can just restore one file out of a whole backup, because you accidentally deleted something). Actually getting backups of Windows machines to boot may require a lot of work, but Linux is robust enough to get right back up in a VM without any additional work. urBackup is an excellent, self-hosted service that everyone should be running all the time.

However: it's not super secure by default.

Create an Admin Password

1. navigate to http://mahbox:55414/ or whatever your address is
2. click on "Settings" at the top middle of the page
3. click "Users" down a bit and to the left
4. "Create user"
5. make an admin with a unique password. This is going to be sent in the clear, until you finish this poorly written tutorial.
6. Hit save and test your new password.

Block Random Data Dumps

Any machine on your local network at any time can claim to (or actually) be a urBackup client and start sending any data to your server at any time without so much as a forged invitation--anyone for any reason can send you any files (like a virus) at any time by default. Let's clamp down on that.

This I'm not so sure about, and I'm probably not doing it right or still leaving stuff exposed. In most repos you'll find an Uncomplicated Fire Wall program that's secretly just a front-end to iptables. Let's use that, because it's uncomplicated and probably already installed on your server.

sudo ufw allow ssh
sudo ufw allow https
sudo ufw deny 55414
sudo ufw deny 55413
sudo ufw enable
sudo ufw status

SSH and HTTPS we'll use now and later respectively, so we want to allow those through the firewall. 55414 is the unsecured web UI port which we're going to reverse proxy through HTTPS later, and 55413 is the port I think urBackup uses to scan for any client that wants to send it data. We want to discourage that behavior, and so are blocking that port. On the main urBackup page there's a little plus button at the bottom right where you can manually add names or IPs of machines you want to manually invite to back up to you.

Forcing urBackup through HTTPS

NGINX is designed exactly for this purpose, but we're going to use Apache2 instead because I at least have a passing understanding of Apach2 and how to manipulate it. Also it's the most popular web server on the planet so you'll be able to find a lot of guides on how to use it, you know: like this one right here. Install Apache2 from your distro repos, and then run this code on your freshly installed urBackup box:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod ssl
sudo a2dissite 000-default.conf
sudo a2ensite default-ssl.conf
sudoedit /etc/apache2/sites-available/default-ssl.conf

We're not going to pointing to a folder full of HTML files like a traditional web server, so comment out the DocumentRoot declaration. While you're at it, fill out the ServerAdmin email address to where ever you want human visitors to be able to contact you at.
The rest of the config is fine as default, but let's add a few lines near the bottom, but still inside the VirtualHost definition.

ProxyPreserveHost On
ProxyPass / http://127.0.0.1:55414/
ProxyPassReverse / http://127.0.0.1:55414/

Save and close the text file, and finally restart the service to see the new changes:

sudo systemctl restart apache2

Like I said: we're not serving HTML files out a folder like usual, we're instead going to reverse-proxy to an existing HTTP service--specifically the one on the same box at port 55414. Now check out the fruits of your labor. navigate to https://yourbox or whatever your address is and you should be presented with a sell-signed cert protecting the familiar urBackup web UI. Feel free to type in your password, knowing that it's being encrypted over the wire.

More and better information about this reverse-proxy stuff we just did is available here.

Hyper-V: The operation failed because the file was not found.

TL;DR: Give permission for the local user named SERVICE to access the files in question.



The long version:

Hyper-V is a powerful hypervisor. It's a shame it has to run on such a stupid OS with so loosely defined user accounts. The Hyper-V service (as it exists by default on Windows Server Core 2012r2, and probably everywhere else) runs as the user "Local System". As is the case on all OSs, a user must be given permission to access and manipulate a file (in this case, VHD files). You'd think that giving access to "Everyone" or "LOCAL SERVICE" would do the trick, but you'd be wrong. Apparently, the real name of "Local System" is "SERVICE", and I don't know why services.msc doesn't just say that.

Since I first set up Hyper-V, I've been getting an error message that looks like this:

Window Title: Virtual Machine Connection
Main Instruction: The application encountered an error while attempting to change the state of 'VM name'.
Content: 'VM Name' failed to change state.
The operation failed because the file was not found. 

Searching the great and powerful Google lead me nowhere. Thankfully, I was able to solve it pretty easily. In my case, I'm using a Core install so I don't waste any more resources on the big stupid Windows than I have to. This means I have to do everything remotely. Obviously you'll need a machine with the permission and ability to manipulate the permissions of these files. I did it from an SMB/CIFS share of the VHD repo, but you can remote in and do it locally, or temporarily enable Admin Shares, or better yet: SSH in and run chmod or chown--just kidding, that would be too easy.

1. From any machine with a full Windows installation (I haven't tried doing this from any other OS) navigate to the folder holding the "file not found" files. I used Windows 7 to fix my 2012r2 Core, but you can use whatever is handy.
2. Right-click on their parent folder (or several grand-parents down, whatever) and go to Properties. 
3. Click the "Security" tab.
4. Click "Edit..."
5. Click "Add..."
6. Click "Advanced"
7. Click "Locations..."
8. Select the actual host of this folder, not your local computer, not a Domain Controller. It should be the top-most item on the Location tree.
9. Click "OK"
10. Click "Find Now"
11. This should show every single user, group, and security principal local to that machine. Press the S key to be brought to the 'S' section of this alphabetically sorted list.
12. Look for a group called "SERVICE".
13. Double-Click the "SERVICE" group to choose it.
14. Click "OK"
15. Now back at the "Permissions for [folder]" window, give the "SERVICE" group full control.
16. Click "OK" a bunch, and you're done.

Start up your VM and cross your fingers.

This worked for me, and I didn't see it posted anywhere else, so I figured I'd share it. As with anything, Your Mileage May Vary.