Learning Restic - Backend & Transport Security

#Introduction

Episode 13 secured the contents of the data. This episode secures the path and storage location. Strong encryption is useless if credentials are sent in plaintext, or if ransomware succeeds in deleting the entire snapshot history.

The three layers we build: encrypted transport, a restricting firewall, and immutable storage — untouchable even by an admin.

#Transport: SFTP/HTTPS, Not Bare Rsync

#SFTP Is Always Encrypted

The SFTP backend runs over SSH — all traffic is encrypted from the start. Unlike older rsync versions that could run over a plaintext rsync:// without an SSH layer. The rule is simple: backup data must never cross the network without transport-layer encryption, whatever application-layer encryption from episode 13 already does.

#HTTPS for S3 and rest-server

• S3: use an https:// endpoint — for MinIO make sure TLS is enabled on the server side.
• rest-server: must be behind TLS (Caddy/nginx) or the built-in --tls.

A quick check whether the connection is encrypted:

restic -r s3:https://minio.example.com/bucket snapshots
restic -r rest:https://backup.example.com/repo snapshots

If an http:// endpoint is used and restic does not complain, you are sending credentials and blobs over plaintext.

#Firewall: Restricting Who Can Access

Basic rules for backup backends:

• S3/MinIO: restrict access to the backup server's IP only, via security group/firewall.
• rest-server: open port 443/8000 only to the legitimate host IPs.
• SFTP: restrict in sshd_config with AllowUsers backup and a forced command so the user can only run restic.

/etc/ssh/sshd_config.d/restic.conf

Match User restic-backup
    ForceCommand restic -r sftp:/srv/backup --backend-sftp-restore-relevant
    AllowAgentForwarding no
    AllowTcpForwarding no

ForceCommand forces that user to run only the allowed command — minimizing the attack surface if credentials leak.

#Immutability: Anti-Ransomware Defense

Ransomware encrypts files, then deletes or overwrites backups so victims cannot recover. Two immutability mechanisms:

#1. --append-only on rest-server

When a client connects to a rest-server running with --append-only, it can only add — it cannot delete or overwrite. Even an infected host cannot poison the history:

ExecStart=/usr/local/bin/rest-server --path /srv/restic --append-only

The trade-off: restic forget and prune cannot be run from an append-only client. Run maintenance (forget/prune) from a separate machine with direct server access.

#2. Bucket Object Lock (WORM)

For S3-compatible storage that supports it (AWS S3, MinIO, B2), enable object lock / WORM at the bucket level. Every object has a Compliance or Governance retention — data cannot be deleted before the retention period expires:

mc mb minio/backup-bucket --with-lock
mc retention set compliance 180d minio/backup-bucket

Compliance retention even refuses deletion by root — full anti-ransomware power.

#Conclusion

• Transport must be encrypted: SFTP/HTTPS; never plaintext.
• Verify TLS is active; don't disable tls.insecure without a strong reason.
• A firewall restricts access sources; SSH ForceCommand narrows the surface.
• --append-only prevents clients from deleting/overwriting — separate maintenance.
• Bucket object lock (WORM) resists deletion even by admins.
• Anti-ransomware = append-only + object lock + a second off-site location.

In the next episode, episode 15, we apply defense at multi-team scale: hardening & multi-tenant — one repository per tenant, one key per repo, credential isolation, least-privilege storage, and periodic access audits.