blob: 768e7cf3dd074a8eb7a7007e886085930e969fc2 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
# online-offsite-backup (name to change)
This tool provides a way to offer others a service for backing up important
files automatically.
Problem: Offsite backups could be as easy as a network filesystem - the problem
is however that these usually implement deleting files aswell. In the case where
a user's machine is comprimised by an attacker, these files could just be
deleted in the same way they were created, defeating some of the advantages of
an offsite backup.
Solution: Implement a network "filesystem" that only supports non-destructive
operations. Only implementing upload means that backups will accumulate on the
server. This tool deletes backups after N newer backups (like a ring buffer). To
prevent quick successive uploads as a means of deleting backups a cooldown for
backup uploads is implemented.
Intended Usage: This program is developed to be deployed on a number of servers
that are not under your control like backing up data of your friends. In such a
scenario, everyone in your friend group would run this software on their server
and negotiate keys with every other one.
Possible attacks: This software primarily protects against the exact case
mentioned above especially when been attacked by automated malware on your
machine. Your remote backups servers may still be vulnerable to social
engineering and supply-chain attacks.
Security: This software assumes security (and reliability) of the TCP
connections it makes: You **must** implement protection on this level yourself.
Backups are stored as-is on the remote server: If your backup requires it,
encrypt it!
Alternative Implementations: There are other ways to implement the functionality
of this tool. I specifically considered creating system user accounts whose
login shell is set to something custom for each peer so they can be automatated
over SSH (which would deal with encryption for me) - that idea was discarded
because it feels too much like security layers are not clear-cut when using SSH
for semi-untrusted operations. A read-write network filesystem with a script
copying backups to a safe location outside of the shared FS could work too but
requires some effort to implement for multiple users.
## Usage
1. Intall the CLI with cargo:
`cargo install --path /path/to/online-offsite-backup`
2. Place a configuration file somewhere.
```toml
[storage]
root = "/home/muffin/temp/backuptest"
size = 1_000_000_000 # maximum size of a single backup version
versions = 3 # number of backups to keep
upload_cooldown = 864000 # cooldown in seconds for backup uploads
download_cooldown = 43200 # cooldown in seconds for backup downloads
upload_speed = 3_000_000 # maximum sustained backup upload speed in bytes per second
download_speed = 3_000_000 # maximum sustained backup download speed in bytes per second
[server]
address = "127.0.0.1:29285" # address for the server to listen on
[[peer]]
name = "alice" # only used for peer selection, doesnt really matter
address = "aliceserver.net:29285" # address for outgoing connections to that peer
shared_secret = "hunter2" # secret used to authentificate connections between you and that peer
[[peer]]
name = "bob"
address = "bobserver.net:29285"
shared_secret = "p4ssw0rd"
```
3. Start uploading a backup: `backuptool config.toml upload /path/to/backup`
4. List currently stored backups: `backuptool config.toml list`
5. Restore a remote backup by serial:
`backuptool config.toml download /path/to/restore`
6. See further usage `backuptool --help`
## Protocol
Connect to the server via TCP and follow this simple text-based protocol.
Whenever there is an error the server replies `error,<message>` and then
disconnects you.First send a line with the shared secret, then send commands.
- `list`: Client sends `list` on a line. The server replies with multiple lines
in the format `<mtime>:<size>:<serial>` ended with a single empty line.
- `upload`: Client sends `upload,<size>` on a line. If accepted the server
replies `ready`. The client should now send exactly as many bytes as
announced. Once done the server replies `done` on a line.
- `download`: Client sends `download,<serial>` on a line. If accepted the server
replies `ready,<size>` on a line and then continues sending exactly this many
bytes before concluding with `done` on a line.
## License
AGPL-3.0-only; See [COPYING](./COPYING)
## Todo
- implement upload / download max rate
|
