For restic to work, the rclone configuration file must not be encrypted?

[fede]

For restic to work, the rclone configuration file must not be encrypted?

Is this right?

And in that case, isn’t it a security problem that someone accessing the computer can read the rclone configuration file with the info?
Or that no longer matters because it is considered that if someone accesses the computer they already have access to the data. I ask because with the credentials someone could delete the remote repository or would he/she still need to validate with etoken?

[shd2h]

@fede

For restic to work, the rclone configuration file must not be encrypted?

I can’t speak to this, having never used restic alongside rclone. However…

@fede

Or that no longer matters because it is considered that if someone accesses the computer they already have access to the data

If you’ve automated access to your restic repository (such that restic can backup etc without you needing to supply credentials or similar) then an attacker with access to your physical machine can access your repository too, which includes the ability to forget all your snapshots and then “salt the earth” by pruning the repository. This includes when using rclone to serve the repository. The theoretical attacker also will have access to the source data of course, which is a completely separate concern.

If this kind of an attack vector is a concern for you, you can lower the threat by using an append-only repository back-end like rest-server, so the attacker can’t forget or prune snapshots. This of course would mean additional work from your side to run forget/prune operations though. You could also implement additional redundancy at the repository side of things (file versioning, filesystem snapshots, etc) so that even if an attacker is able to wipe the repository, you have the ability to recover.

The security improvements here have obvious trade-offs, and whether they’re worth it or not depends entirely on your threat model. All of the above applies to restic when used by itself as well as when rclone is involved to serve the back-end. I don’t know if rclone adds increased risk really; I suppose it might allow an attacker to mount the repository and wipe the entire repository, rather than having to use restic to forget the snapshots, but the same risk exists with other back-ends too.

For what it’s worth, I’d personally consider someone having access to the source machine to be “game over”, and assume the entire system, and any storage it can access, is a write-off. My method for recovery in that instance is off-site backups, which are not automated or run from the compromised system.

[fede]

Perfect explanation, I really appreciate your time and knowledge.

I think I’ll try using something similar to https://ifttt.com/ so that the repository folder is backed up to another cloud location and save the different versions.

I don’t know if rclone adds increased risk really

If the rclone configuration is not encrypted, then the Google Drive credentials remain in a text file, for example, but I think that without validation of an eToken they are useless.

In other words, if I want to recreate the repository myself, I must then validate the eToken by logging into my Google Drive account or generating an eToken with rclone on a computer that already has access.

For what it’s worth, I’d personally consider someone having access to the source machine to be “game over”, and assume the entire system, and any storage it can access, is a write-off. My method for recovery in that instance is off-site backups, which are not automated or run from the compromised system.

I take note, thank you very much. In this case it is a computer that I only access through remote assistance.

Thanks again

[zer0]

You can use $RCLONE_PASSWORD_COMMAND and $RESTIC_PASSWORD_COMMAND

[Ocelot]

@fede

If the rclone configuration is not encrypted, then the Google Drive credentials remain in a text file, for example, but I think that without validation of an eToken they are useless.

Good and important topic! I am not really sure how it works for Google, but for MS onedrive, the rclone.conf contains an access token, once you have that, you can do whatever you want on the share, no new login etc. required as far as I can tell, unfortunately.

I think you are absolutely right to consider this attack vector and look at possible mitigations, and really, there are only two possible solutions:

1. Configure backend with append-only, immutable mode, object-locks, custome retention policy etc. (not possible with many low-end cloud storage solutions)
2. Require human intervention during the backup process to provide credentials

I went for #2, and documented my approach here, if you are interested:

Ransomware protection without special backend support

Hi all! I am using a onedrive rclone remote included in a basic O365 subscription for my backups. As you know, this does not offer any option of immutability or append-only. As I was worried about ransomware or an attacker also killing my cloud backups, and the other threads I found were more about special backends supporting object locks etc, I would like to create a topic to to discuss this use case, share my simple strategy, and would be happy to read about your opinions, strategies, commen…

[fede]

@Ocelot

I think you are absolutely right to consider this attack vector and look at possible mitigations, and really, there are only two possible solutions:

1. Configure backend with append-only, immutable mode, object-locks, custome retention policy etc. (not possible with many low-end cloud storage solutions)
2. Require human intervention during the backup process to provide credentials

1 I need to research about this
2 Not possible on my case

[fede]

@Ocelot

Good and important topic! I am not really sure how it works for Google, but for MS onedrive, the rclone.conf contains an access token, once you have that, you can do whatever you want on the share, no new login etc. required as far as I can tell, unfortunately.

I understand, thank you. Can anyone confirm if the same thing happens with Google Drive?