Criptografar um VPS com LUKS

A criptografia de disco completo responde a uma pergunta e responde a ela por completo: o que acontece quando outra pessoa acaba ficando com o disco enquanto ele está desligado? Em infraestrutura alugada isso não é hipotético. Discos falham e voltam para o fornecedor. Nós são desativados e seu armazenamento é revendido. Volumes são clonados durante uma investigação, ou saem de um prédio dentro de uma caixa.

• Coberto. Um disco desligado, uma imagem offline do seu volume, um disco devolvido em garantia, um nó desativado, um arquivo de snapshot copiado. Em cada um desses casos o atacante tem o texto cifrado e um header, e sem uma frase-senha isso é o fim da história.
• Não coberto: uma máquina em execução. No momento em que o volume é aberto, a chave está na memória do kernel e o sistema de arquivos fica visível para qualquer coisa com root.
• Não coberto: seu tráfego. Bytes no fio são problema do TLS e do WireGuard. O LUKS nunca os vê.
• Não coberto: uma conta root comprometida. Um invasor que já está lá dentro lê seus arquivos pelo mesmo ponto de montagem que você usa. É para isso que serve o hardening, e os dois controles não são intercambiáveis.

A lista é curta de propósito. A criptografia em repouso é um controle barato e de alto valor, com um escopo precisamente delimitado, e quase toda a decepção que as pessoas relatam com ela vem de terem esperado, silenciosamente, que ela cobrisse as outras três linhas também.

Quando o seu volume criptografado está aberto, a chave está na RAM do convidado — e em qualquer VPS, em qualquer lugar, essa RAM vive em uma máquina que o operador controla fisicamente. Um hypervisor pode ler a memória do convidado. Isso não é uma falha do LUKS, nem do KVM, nem deste host em particular; é o que significa alugar um computador, e qualquer provedor que diga o contrário está descrevendo um produto que não existe.

Então a conta é direta: a criptografia em repouso torna o ataque offline impossível e deixa o ataque online exatamente onde estava. Um disco que sai do rack se torna inútil. Um servidor em execução está tão exposto quanto estava ontem. As duas metades dessa frase são verdadeiras ao mesmo tempo, e um guia que conta só a primeira metade não está lhe fazendo um favor.

O que move a segunda agulha é um conjunto diferente de controles, e eles se somam à criptografia em vez de substituí-la. Não há nada registrado para divulgar, porque o cadastro aqui é sem KYC — um e-mail para entrega das credenciais e mais nada. O pagamento é liquidado on chain em vez de por um banco. E a jurisdição onde a máquina está decide quais ordens conseguem exigir alguma coisa. Nosso panorama honesto sobre o que um VPS pago em cripto esconde percorre o resto, e o verbete sobre os Fourteen Eyes cobre o lado do compartilhamento de inteligência. Lida como uma camada entre várias, o LUKS é um ótimo custo-benefício. Lida como um escudo contra o seu próprio host, é um mal-entendido.

Isso pode assumir duas formas, e a escolha é sobre risco, não sobre força.

• Um volume de dados criptografado. Um container LUKS ao lado do sistema operacional. Tudo o que importa — bancos de dados, e-mail, chaves, uploads, backups — vive dentro dele; o sistema operacional em si permanece às claras. Dez minutos de trabalho, nenhum risco de boot, e reversível a qualquer momento. É isso que a maioria dos leitores deveria construir, e é isso que os passos abaixo fazem.
• Um sistema de arquivos raiz criptografado. Tudo fica dentro, incluindo logs, listas de pacotes e o histórico do shell que você esqueceu que existia. Estritamente mais forte, e genuinamente mais difícil de aplicar em uma máquina que já está em execução.

O motivo dessa dificuldade vale a pena declarar, porque nenhum tutorial jamais faz isso: você não consegue criptografar um sistema de arquivos que está atualmente montado em leitura-escrita e servindo sua sessão SSH. Os dois métodos reais — encolher e copiar, ou cryptsetup reencrypt no lugar — precisam que a raiz esteja offline. Em uma máquina com console fora de banda, você inicializa um instalador e isso é rotina. Em um VPS sem console, você primeiro transfere o sistema em execução para um disco em RAM, e se qualquer parte disso der errado a máquina não volta e o caminho de recuperação é uma reinstalação, que apaga o disco.

Então: construa o volume de dados hoje, coloque nele tudo o que tem consequência, e trate uma raiz criptografada como uma decisão a ser tomada no momento do deploy, em uma máquina que ainda não tem nada a perder. A última seção cobre essa rota, incluindo o dropbear-initramfs para digitar a frase-senha via SSH durante o boot.

Pouca coisa, o que já é parte do motivo pelo qual vale a pena fazer isso.

• Um plano. A criptografia não adiciona exigência de RAM e quase nenhuma de CPU. Cub (1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo) já basta; Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) é o tamanho confortável se a máquina também rodar um serviço de verdade. O único número que importa é o disco, porque é dele que sai o seu volume criptografado.
• Debian 12 ou 13 da biblioteca de templates, ou Ubuntu LTS — os comandos abaixo seguem o estilo Debian, e os nomes de pacotes variam em outras distros. O deploy leva cerca de um minuto, e a virtualização KVM completa significa um kernel de verdade com os módulos dm-crypt presentes, não um container emprestando o de outra pessoa.
• Dez minutos de hardening básico primeiro. Criptografia em uma máquina que ainda aceita login por senha é uma fechadura em uma porta sem batente.
• Uma frase-senha que você não usou em nenhum outro lugar, gerada em vez de inventada, e guardada em algum lugar que sobreviva a você perder esta máquina. Não existe recuperação, não existe reset e não existe chamado de suporte que ajude.
• Um lugar fora da máquina para guardar o backup do header. Snapshots semanais estão incluídos em todos os planos, mas o snapshot de um volume criptografado continua criptografado — útil para rollback, inútil se a frase-senha tiver sumido.

A localização não faz diferença nenhuma para nada disso, então escolha pelo preço ou pela jurisdição: Amsterdam, Paris, Bucharest e Sofia ficam no preço base, enquanto Zurich, Reykjavik, Stockholm e Kuala Lumpur têm um multiplicador.

O LUKS2 mantém até 32 keyslots. Cada um guarda uma cópia da mesma chave mestra, encapsulada com uma frase-senha diferente, e é por isso que você pode adicionar uma segunda frase-senha sem recriptografar nada:

cryptsetup luksAddKey /dev/disk/by-partlabel/secure
cryptsetup luksDump /dev/disk/by-partlabel/secure | grep -A2 '^Keyslots'
cryptsetup luksKillSlot /dev/disk/by-partlabel/secure 1

Ter duas frases-senha desde o início é o padrão certo: uma que você usa, outra anotada e guardada em outro lugar. Perder o único acesso a um volume por causa de um erro de digitação em um gerenciador de senhas é a forma mais comum, disparada, de as pessoas perderem dados do LUKS, muito à frente de qualquer coisa que um adversário faça.

Agora, a armadilha. Um backup do header feito antes de você rotacionar uma frase-senha ainda abre o volume com a frase-senha antiga. Os keyslots vivem no header, então uma cópia antiga do header é uma cópia antiga dos keyslots — a chave mestra por baixo nunca mudou. Se você rotacionar porque uma frase-senha pode ter vazado, precisa destruir todo backup do header feito antes da rotação e tirar um novo. Caso contrário, a rotação não realizou nada além de te fazer sentir melhor.

O mesmo fato torna os backups do header sensíveis por si só: aquele arquivo de 16 MB, somado a qualquer frase-senha que ele já conheceu, é suficiente para decriptar o volume. Guarde-o onde você guardaria a frase-senha, não onde guarda seus snapshots.

cryptsetup benchmark te diz a verdade para a sua vCPU específica em cerca de quinze segundos. Em qualquer CPU com AES-NI — ou seja, qualquer processador de servidor x86-64 da última década — espere vários gigabytes por segundo para aes-xts, folgadamente mais rápido do que o NVMe por baixo dele. O overhead prático em cargas de trabalho reais é de poucos pontos percentuais, e é CPU, não latência.

Duas opções do cryptsetup importam em armazenamento rápido, e só em armazenamento rápido:

cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \
  --allow-discards open /dev/disk/by-partlabel/secure secure

As flags de workqueue contornam as filas internas do dm-crypt e entregam o I/O direto para o dispositivo. Em um disco mecânico elas não mudam nada; em NVMe RAID10 elas removem um gargalo real em profundidade de fila alta. Adicione-as à linha de opções do crypttab como no-read-workqueue,no-write-workqueue para torná-las permanentes.

--allow-discards é a que tem um trade-off. Ela repassa o TRIM para o NVMe, o que mantém a performance de escrita ao longo do tempo — e também revela para quem estiver com o disco desligado em mãos quais blocos estão em uso e quais estão livres. Isso é um vazamento de informação genuíno, ainda que modesto: expõe aproximadamente o quanto o volume está cheio e pode sugerir a estrutura do sistema de arquivos. Em um servidor de uso geral, vale a pena ficar com a performance. Se o conteúdo do volume é do tipo em que o próprio tamanho é sensível, deixe os discards desligados.

Se você quiser tudo criptografado, faça isso em uma máquina que ainda não tem nada nela — implante, converta, depois construa. A conversão em si é padrão: encolher o sistema de arquivos raiz enquanto ele está offline, criar um container LUKS2 no espaço liberado, copiar o sistema inteiro com rsync -aHAX, apontar /etc/fstab e /etc/crypttab para o dispositivo mapper, depois update-initramfs -u -k all e reinstalar o GRUB. A parte que torna isso um problema específico de VPS sem console são as palavras enquanto ele está offline: chegar lá sem um console significa primeiro transferir o sistema em execução para uma raiz em RAM, e esse é o passo que termina em reinstalação quando dá errado.

O que torna uma raiz criptografada sequer utilizável em uma máquina remota é o dropbear-initramfs — um servidor SSH de cerca de 200 KB embutido na imagem de boot, escutando enquanto o kernel espera pela frase-senha:

apt install dropbear-initramfs cryptsetup-initramfs

# Debian 12/13: /etc/dropbear/initramfs/
cp ~/.ssh/unlock_key.pub /etc/dropbear/initramfs/authorized_keys
chmod 600 /etc/dropbear/initramfs/authorized_keys

echo 'DROPBEAR_OPTIONS="-I 300 -j -k -p 2222 -s -c cryptroot-unlock"' \
  >> /etc/dropbear/initramfs/dropbear.conf

echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
update-initramfs -u -k all

Você então usa ssh -p 2222 root@your-ip durante o boot, e o comando forçado cryptroot-unlock pede a frase-senha. Vale saber três coisas sobre isso antes de confiar nele. O initramfs tem sua própria host key, então seu cliente vai avisar sobre uma divergência na porta 2222 — isso é esperado, e é o motivo para dar a ela uma porta dedicada. Essa host key e o seu authorized_keys ficam em uma partição de boot não criptografada, legível por qualquer um que tenha o disco em mãos, então use uma chave de desbloqueio que não sirva para mais nada. E -s desativa logins por senha no initramfs, o que não é opcional.

O outro detalhe que morde em planos pequenos é o mesmo do passo três, e é aqui que ele morde mais forte. O initramfs roda antes que a maior parte da sua RAM esteja disponível para qualquer coisa confortável, então um header formatado com um custo de memória do Argon2id muito alto pode falhar ao desbloquear justamente na máquina que o criou. Formate com o --pbkdf-memory limitado, e teste o reboot enquanto você ainda não tem nada a perder.

Muito pouco, e esse é o ponto. Um volume LUKS aberto é um dispositivo de bloco comum; fsck, rsync, df e sua ferramenta de backup se comportam exatamente como antes. Upgrades de kernel não são afetados porque o dm-crypt é in-tree. Expandir o volume depois de um upgrade de plano são dois comandos — cryptsetup resize e depois o resize do próprio sistema de arquivos — e não precisa de recriptografia.

Três hábitos valem a pena construir. Ensaie o reboot em uma programação regular, em vez de descobrir às 3 da manhã que uma frase-senha que você nunca anotou é a única cópia. Mantenha os backups criptografados de forma independente — restic ou borg para um destino fora do local, o que é um controle separado do volume e sobrevive à perda total da máquina; o add-on de backup diário fora do local sai por $2.00/mo se você preferir não construir isso sozinho. E feche o volume antes de parar de se importar com a máquina: cryptsetup close secure antes de um desligamento planejado, migração ou reinstalação significa que a chave sai da memória antes de o disco deixar de ser seu.

Em termos de política, não há nada a negociar. Você tem root completo em um convidado KVM, e o que você faz com a camada de bloco é problema seu; criptografar o seu próprio volume é administração de sistemas comum, não um caso extremo. A política de uso aceitável trata de conduta — o piso inegociável é nada de CSAM e nada de terrorismo — e não tem nada a dizer sobre dm-crypt. O que a criptografia muda é o formato de um dia ruim hipotético: um volume desligado que sai deste prédio é ruído, e isso vale os seus dez minutos.