File-Level Backup from Remote Backup Server

Installing and Using OpenWrt
1

Hi there!

After it takes a little time I've managed to install and configure my multiple OpenWrt Devices as expected from my side.

That also contains a weekly file-level Backup of the configuration using the sysupgrade option, which is triggered from my Backup Server via a Script using ssh and key-based authentication between the Server and the OpenWrt Devices.

The Script on the Backup Server contains the following commands:

#!/bin/bash

DATE=`date +%Y-%m-%d`
TIME=`date +%H-%M`                                      
DESDIR=/mounted/samba/share/for/Backup/on/remote/server/   # Destination Path of backup file.


# Create directories
# ---------------
mkdir -p $DESDIR


# Run Backup
# ---------------
echo "Start Backup at "`date +%H:%M`
echo "--------------------------"
ssh -i .ssh/Backup_BCKPSRV -p 112 root@192.168.1.1 "umask go=; sysupgrade -k -b /tmp/Backup_GATEWAY_$(date +%F).tar.gz"
scp -r -P 112 -i .ssh/Backup_BCKPSRV root@192.168.1.1:/tmp/Backup* $DESDIR
ssh -i .ssh/Backup_BCKPSRV -p 112 root@192.168.1.1 "rm /tmp/Backup_GATEWAY*.tar.gz"
wait
echo "--------------------------"
echo "Backup finished at "`date +%H:%M`
echo "==============================="

As you can see, the given Script is very simple and works fine. As I'm a bit paranoid about IT-Security, I was wondering, if those commands can also be used in an non-root-user-context on the OpenWrt devices, so that I didn't need to gain full root access from Backup Server to Backup the files.

Can anyone give me an advice how to do that?

Please note: I'd only want to use ssh for that - I know, there are several other ways to do that (mount a samba share, rsync, etc.) but i want to keep the OpenWrt setup small and, due to my aforementioned paranoidness about IT-Security, also keep it less vulnerable to attacks from inside and outside.

I've also tried the ForceCommand option via the authorized_keys file, but that is also not the right way for me as I have to write a script on the OpenWrt device, which is executing the commands and transfers the Backup File to the Backup Server, where also have a few commands to be running, triggered from the Script, to move the Backup to the right Destination.

I hope I was able to present my concern clearly enough :wink:

2

Well, you seem to be asking if files readable by root-only could be remotely read without root access????
(Some config/key/etc. files have root-only read permissions)

To me an easier approach might be to run the backup script weekly in each router as root by cron, and then provide a restricted write access to your backup server for the script.

Or implement a two-step process:

  • run backup itself in router as root by cron, and just create a backup file. Store that file in a directory in the router, where you can allow read access to a new non-root router user.
  • Have the backup server to copy that file from router a few minutes later as that new non-root user.

The backup file could even be encrypted by the script, so that the plain tar.gz would not be offered for download. E.g. ccrypt offers a simple encrypt/decrypt cmdline interface usable by scripts.

3

I don't have a solution for you, but I do have questions/thoughts...

The files on your OpenWrt system will rarely change, assuming it is a typical use-case for the system (i.e. a router). The changes, in those situations, are purely if you or some other administrator actively logs in and changes configuration files. This is by design for a whole bunch of reasons. So, in these cases, your device does not need a periodic backup at all... just a single backup anytime there are changes to the configuration.

If you're doing something less typical but still not uncommon, you may be collecting statistics and log data about the performance of your network and maybe even some basic traffic insights. These can be sent to a syslog server (which is usually done real-time), so again, no periodic backups are necesary.

In the situation where you're using this device as a general purpose data storage system (i.e. a NAS), you would obviously see a lot of changes happening, so periodic backups can be a good idea. But the configuration data itself will rarely change.

So... why do you feel you need to even setup this script for periodic backups? Is there something in your setup that causes changes on a frequent basis?

4

It's more kind of a learning process. I'm employed as an IT-Specialist for Medical IT in a hospital - therefore, there are many aspects to consider regarding to IT-Security on my daily business and it's necessary to continuously expand the knowledge about it and to analyze the existing solutions to get the most secure infrastructure without limitating the applications and devices in their functions we need.

So all aspects that I learn in self-studying these topics at work, I examine accordingly for implementability in my own infrastructure and I try to find the most restricted settings without limitating the function of the applications, too.

Back to your question: I test and apply new settings at least once a week to the configuration of my Servers and devices, so I thought it's not a bad idea to get an automatic Backup in case of forgetting to save the settings before the new would be applied.

5

Thank you for the input!

Sometimes you are just caught in your tunnel vision, hence my question here in the forum.
I will try to find out, whats the best way for me with these new approaches.

In Case there are more idea's i look forward to it.

6

Update: I just implemented the advised two-step process and tested it manually. The next automatic backup is scheduled for Sunday 2:00 am.

A note from my side: I use key-based authentication for ssh - however, the pre-installed dropbear package (ssh) can only handle just one authorized_keys file in it's configuration.
So in my case, the implemented two-step process required the installation of the openssh-server and openssh-client packages to handle multiple user-authentication.

7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.