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
- navigate to http://mahbox:55414/ or whatever your address is
- click on "Settings" at the top middle of the page
- click "Users" down a bit and to the left
- "Create user"
- make an admin with a unique password. This is going to be sent in the clear, until you finish this poorly written tutorial.
- 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.
No comments:
Post a Comment