Introducing "integrity" feature
Opened this issue · 0 comments
I was thinking about a new feature that could help identify if your repository is gradually being encrypted by ransomware.
Depending on your backup medium, it could take some time for ransomware to encrypt your files to make sure all previous versions of your files are also encrypted (with a medium providing file versioning).
The idea is to define a file that shouldn't change much (like /etc/hosts
something like that) and resticprofile could pick a random (preferably older) snapshot and compare the files. It could allow for some changes but not the whole file.
An alert could be triggered if the files are too different.
Eventually, if the attacker can rewrite files in your repo, it would have access to the configuration, so it could leave this file intact.
It would only work if you're using a completely different honeypot file from another machine which hopefully hasn't been compromised (yet).
That makes for a lot of if right?
Do you think that would be a useful feature?
I would see the configuration like that:
profile:
backup:
source: /
integrity:
- source: /etc/hosts
target: /etc/hosts
snapshot:
from: 1 month old
to: 1 week old
allow-diff: 2 lines
- source-from-command: /bin/load another/file
target: /another/file
snapshot: last sunday
contains: "some text"
- target: /big/file
snapshot: 3 weeks ago
contains: "some important text"
- we could have multiple files for checking integrity
- the reference file could be a local file or a stream from
stdin
. - the snapshot could be fixed or selected randomly between a range.
- a
diff
could be done on text files, otherwise byte by byte comparison on binary files - we could check for some string inside the file instead
Would that actually help?
Am I missing something?