In my previous post, Part 1 - NAS setup and local backup, I discussed how I set up my new Unraid NAS and configured my Windows PC to back up to the NAS. However, while this protected my data against hard drive failure, both sets of data were stored inside my house - I had no protection against disasters such as fire, lightning, etc. In this post, I will outline the steps I took to set up a remote server ready to recieve the backup data from my NAS. In the next post, Part 3 - Back up NAS to offsite server, I will cover the actual backup process between the two servers.
Choose a VPS Provider
The most important (and obvious) part of operating an offsite backup is that you need a server to back up to. There are plenty of service providers out there, and choosing one will come down to your individual requirements and preferences.
I chose Time4VPS, largely because they offered a Linux virtual private server (VPS) package with 1 TB storage and 8 TB/month bandwidth for €5.99 per month. Since I only planned to use this server for backup storage, I wasn't particularly interested in CPU / RAM specifications.
Once you've purchased a VPS package, you'll want to log in and do stuff with it! SSH (Secure SHell) is the de-facto standard for remote access to a Linux box, and modern major operating systems ship with an SSH client in the box.
Your provider will have given you a username (probably
root) and password when you went through the initial purchase procedure. They will also give you an IP address or hostname that the server can be reached at.
From a Windows, Linux or Mac box, you can run:
Substituting your own details as required.
One of the reasons I chose to run my own backup server was that all-in-one backup providers (e.g. Backblaze) seemed to top out at a few hundred kilobits per second - signficantly below the capabilities of my internet connection. At the speeds I was seeing, my backups were likely to take months!
I tested the upload speed using
iperf3. This can be installed via the package manager on most popular Linux distros.
Because my VPS is running CentOS 6, I first needed to enable the
EPEL (Extra Packages for Enterprise Linux) repository:
# CentOS 6 only yum install epel-release yum install iperf3
iperf3 server is then started using:
Extract this to a convenient folder, and then run:
iperf3 -c backup.example.com
The output of this will show the transfer speeds achieved, for example:
Connecting to host backup.example.com, port 5201 [ 4] local 192.168.1.2 port 51838 connected to 126.96.36.199 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 1.12 MBytes 9.43 Mbits/sec [ 4] 1.00-2.00 sec 1.50 MBytes 12.6 Mbits/sec [ 4] 2.00-3.00 sec 1.62 MBytes 13.6 Mbits/sec [ 4] 3.00-4.00 sec 1.75 MBytes 14.7 Mbits/sec [ 4] 4.00-5.00 sec 1.88 MBytes 15.7 Mbits/sec [ 4] 5.00-6.00 sec 2.12 MBytes 17.8 Mbits/sec [ 4] 6.00-7.00 sec 2.12 MBytes 17.8 Mbits/sec [ 4] 7.00-8.00 sec 2.25 MBytes 18.9 Mbits/sec [ 4] 8.00-9.00 sec 2.25 MBytes 18.9 Mbits/sec [ 4] 9.00-10.00 sec 2.12 MBytes 17.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 18.8 MBytes 15.7 Mbits/sec sender [ 4] 0.00-10.00 sec 18.7 MBytes 15.7 Mbits/sec receiver iperf Done.
Since I pay for 20 Mbps upload on my fibre connection, I'm fairly happy with an average of 15.7 Mbps up.
Setting Up an
rsync to mirror the contents of my NAS onto the VPS. In order to minimize the surface area exposed to the internet, I set up a new user for the
rsync job which can only log in from my home IP address.
- Create a new user group - this will be used to manage SSH permissions
- Create a new user in this group
useradd -g rsync -d /backup remoteuser
/etc/ssh/sshd_configand add the following lines
# Deny rsync users password authentication (i.e. require public key) Match Group rsync PasswordAuthentication no # Deny rsync users login from all IP addresses except the remote site (i.e. my house) Match Group rsync Address *,!188.8.131.52 DenyGroups rsync
Protecting SSH Access with Fail2ban
A public-facing SSH server is a tempting target for attackers. Although SSH itself is secure when correctly configured, exposing any network service increases the surface area that an attacker can try to take advantage of. A public SSH service that has been running for any amount of time will start to attract the attention of botnets and other nasties:
Slightly concerning... pic.twitter.com/1uQZVXo6L5— Ben Owen (@_benjaminowen) February 25, 2019
Fail2ban helps to protect against these brute force attacks by automatically implementing firewall restrictions based on failed login attempts. This means that any single attacker has a smaller window of opportunity to break in to your server.
Like iperf3, Fail2ban is part of the EPEL repository on CentOS. So first, this repository needs to be enabled (if it hasn't been already):
sudo yum install epel-release
The package can then be installed:
sudo yum install fail2ban
Once insrtalled, start the Fail2ban service with:
sudo systemctl enable fail2ban
/etc/fail2ban/jail.local and add the following configuration:
[DEFAULT] # Allow 5 login attempts before banning maxretry = 5 # Ban for 1 hour once all retries have been used up bantime = 3600 # Use iptables for firewall configuration banaction = iptables-multiport # Don't ban the following IP addresses (list your own IP here) ignoreip = 184.108.40.206/8 # Enable jail for SSH daemon [sshd] enabled = true
After making configuration changes, restart the service with:
sudo systemctl restart fail2ban
Once Fail2ban is up and running, you can check the current status of the
sshd jail using:
$ sudo fail2ban-client status sshd
This will give output such as
Status for the jail: sshd |- Filter | |- Currently failed: 0 | |- Total failed: 510 | `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd `- Actions |- Currently banned: 1 |- Total banned: 74 `- Banned IP list: 220.127.116.11
Which indicates that 74 IP address have been banned, but all but one of those bans have since expired. There is a single IP address still on the ban list.
Continue reading: Part 3 - Back up NAS to offsite server