Next up is Aaron Poffenberger:
Road Warrior Disaster Recovery: Secure, Synchronized, and Backed-up

Motivation:

Consider the disasters. Consider what you might have that someone else want.

Follow

Full disk encryption gives peace of mind if your computer goes missing and reduces anxiety about throwing out old hard drives or computers.

Ensure nobody can benefit from the disaster.

Synchronization is not a backup strategy, but it is useful.

ProxyJump is wonderful thing, see -J on ssh.

This ssh_congfig option is useful when fw is a defined value when on your home network. Otherwise, it gets filled in with a static value.

For disaster recovery - an OS install drive.

@dvl also recommend it on every server. Never worry about what happens with your company's data when you RMA a disk. Also saves your butt when reusing drives that were improperly wiped and might have traces of an old ZFS label with the zpool name "zroot" or "tank".... fixing that can lead to dangerous mistakes.
@hirojin @dvl with a passphrase of course, but that's what gets tricky.

Every physical box should be fully encrypted. and you should NEVER remotely reboot a server without known working console/serial console/ipmi/whatever access.

Instead of storing the crypto passwords write a tool for your team that auto-generates the FDE passphrase based on system hostname and the service tag and some salt that only your team members know. This way it should be easy to write the script from memory if you lost access to it.

$ /tmp/fdepass.sh -h bikeshed.party
Generating password for bikeshed.party
Please enter the service tag: abc123
YTFk-MWEy-MGFk

This is what i did @ a previous job but i don't know if the team kept up with it. Made it super easy to have FDE passphrases without a password manager that can be compromised. It requires an awful lot of information that an attacker would need to know to decrypt the drive AND they'd need physical access to the server anyway.

If somehow one drive was brute forced it doesn't let them decrypt any drives from your other servers.

Remember, you don't need to encrypt the VMs or containers themselves, just the physical hardware they're running on -- whether that be the server itself or the SAN/NAS where the data storage lies.

@hirojin @feld @dvl On Linux you can use dropbear. It'll start really early in the boot process and allow you to enter the passphrase over SSH.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!