Criptografar um disco de VPS com LUKS

Criptografia não é uma configuração de privacidade genérica. Ela responde exatamente a uma pergunta: alguém consegue ler esses blocos sem a chave? Tudo o mais — quem sabe que você alugou o servidor, se o tráfego é atribuível a você, se um tribunal pode obrigar alguma coisa — está em outro lugar.

Em um VPS, o LUKS defende de forma significativa contra:

• Hardware desativado ou com falha. Drives NVMe são substituídos. Um secure-erase em um dispositivo com falha nem sempre é possível — às vezes ele está morto o suficiente para que o controlador não aceite mais comandos, e ainda assim sai do rack.
• Uma imagem offline. Um volume copiado enquanto o servidor está desligado — durante uma apreensão, uma migração, um erro — é texto cifrado e continua sendo texto cifrado.
• Backups e snapshots que saem do servidor. Tudo o que deixa a máquina sai criptografado se for capturado na camada de blocos abaixo do seu controle, e deve ser criptografado do lado do cliente se for capturado acima dela.
• Blocos residuais. Quando você destrói um servidor, os extents subjacentes acabam sendo reaproveitados. A criptografia transforma esses resíduos em ruído em vez de dados.

Ela não defende contra uma máquina em execução. Enquanto o servidor está ligado, a chave mestra fica na memória do kernel, e qualquer um capaz de extrair essa memória lê seu disco independentemente da senha. Em infraestrutura alugada, isso significa o operador do hipervisor. Dizemos isso em nosso aviso de privacidade e diremos aqui: nenhum recurso de criptografia de disco de nenhum provedor muda isso, incluindo o nosso, e qualquer provedor que afirme o contrário está descrevendo marketing, não criptografia.

Antes de tocar em um terminal, escolha o modelo. Eles diferem enormemente em esforço, e a maioria das pessoas precisa do primeiro.

1. Um volume de dados criptografado. O sistema inicializa normalmente e sem criptografia; uma árvore de diretórios — um maildir, um banco de dados, um arquivo — fica dentro de um contêiner LUKS que você abre manualmente após cada boot. Dez minutos de trabalho, sem modo de recuperação, sem risco de ficar trancado para fora. Se o que importa para você é um conjunto de dados específico, e não a máquina inteira, pare por aqui; você obtém a maior parte do benefício com quase nenhuma da fragilidade. Este é o padrão que recomendamos na página do servidor de e-mail anônimo.

2. Um volume raiz criptografado com desbloqueio remoto. Tudo, exceto /boot, é criptografado, e todo boot fica pausado no initramfs até que você entre via SSH e forneça a senha. Este é o modelo que o restante deste guia constrói. Custa uma hora na primeira vez e um comando SSH a cada reinício, e é o único modelo em que logs, caches de pacotes, histórico do shell e swap também ficam cobertos — os lugares para onde os dados vazam sem que ninguém tenha decidido que deveriam.

3. Uma raiz criptografada que se desbloqueia sozinha contra um servidor de chaves que você controla. Igual ao modelo 2, mas o Clevis busca o material de desbloqueio em um servidor Tang em uma máquina de outra jurisdição, de modo que os reinícios ficam sem intervenção. A contrapartida é precisa e vale a pena entender: o servidor agora pode se descriptografar sozinho contanto que o seu servidor de chaves diga sim, o que significa que você moveu o segredo em vez de eliminá-lo — mas também ganhou um interruptor de desligamento remoto. Tratado mais adiante.

Muitos provedores anunciam “criptografia em repouso” como um item de checklist. Vale a pena ser preciso sobre o que essa expressão costuma significar, porque duas coisas bem diferentes se escondem atrás dela.

Criptografia com uma chave que o provedor guarda protege contra um drive roubado e nada além disso. Se o provedor consegue inicializar seu servidor sem perguntar nada a você, o provedor consegue descriptografar seu servidor sem perguntar nada a você — e o mesmo vale para qualquer um que possa obrigar o provedor a fazê-lo. É um controle real contra roubo e puramente decorativo contra processo legal.

Criptografia com uma chave que você guarda é a versão que realmente importa, e ela impede o reinício sem intervenção por construção. Isso não é uma falha a ser corrigida com engenharia; é a propriedade que faz o trabalho.

Nós entregamos apenas a segunda opção, não configurada, e deixamos você decidir. O que nós de fato guardamos é mais restrito e documentado: as senhas de root dos servidores são armazenadas criptografadas com AES-256-CBC no nível da linha do banco de dados, não retemos logs de fluxo nem capturas de pacotes, e um warrant canary assinado é publicado em cronograma regular. Nada disso substitui sua própria chave — é apenas a parte pela qual podemos ser responsabilizados nesse meio-tempo.

Os padrões são bons. Vale a pena sobrescrever dois deles.

Cifra. aes-xts-plain64 com uma chave de 512 bits é o padrão e a resposta certa — os 512 bits são duas chaves de 256 bits, então isso é AES-256 em modo XTS, e toda CPU que utilizamos tem AES-NI. Em uma máquina sem aceleração de AES, você preferiria xchacha20,aes-adiantum-plain64, mas esse não é o nosso hardware e provavelmente não é o seu.

Derivação de chave. O LUKS2 usa Argon2id por padrão, que é deliberadamente exigente em memória. O cryptsetup faz um benchmark da sua máquina no momento da formatação e escolhe um custo de memória com base na RAM que consegue ver — e aqui está a armadilha que gera a maioria dos relatos de “meu servidor criptografado não inicializa”: o initramfs tem menos memória utilizável do que o sistema em execução, e se você formatou o volume em um ambiente de recuperação com mais RAM do que o plano de destino possui, o desbloqueio pode falhar ou ser interrompido no boot. Fixe o valor explicitamente. Um GiB de memória Argon2 é um custo sério para um atacante e está confortavelmente ao alcance de um S1 com 4 GB:

cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 --key-size 512 --hash sha256 \
  --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 \
  /dev/vda2

--pbkdf-memory é em KiB, então 1048576 equivale a 1 GiB. Verifique depois o que realmente foi gravado no cabeçalho com cryptsetup luksDump /dev/vda2 — a seção do keyslot exibe a memória e o número de iterações que serão usados, e ler isso uma vez sai mais barato do que um boot falho.

A senha. O Argon2 compra tempo contra uma senha fraca; ele não salva uma. Use uma frase diceware de pelo menos seis palavras. Ela é o único segredo do sistema, e nenhuma função de derivação de chave compensa uma senha ruim.

Um boot Linux com raiz criptografada tem um problema do tipo ovo-e-galinha: o kernel e o initramfs precisam carregar antes que qualquer coisa possa pedir uma senha, e eles vivem no disco que você está tentando desbloquear. A resposta padrão é uma pequena partição /boot não criptografada, contendo o kernel, o initramfs e o bootloader. Tudo o mais fica dentro do LUKS.

O initramfs então pausa e pede a senha. Em um laptop, você a digita. Em um servidor a três mil quilômetros de distância, você precisa de uma de duas coisas:

• O console. Todo servidor no seu painel tem um console noVNC, e ele funciona — mas as teclas digitadas atravessam nossa infraestrutura, que é exatamente a parte que sua chave deveria excluir. Serve para uma recuperação pontual, mas é errado como rotina.
• Um servidor SSH dentro do initramfs. O dropbear-initramfs tem cerca de 200 KB, ativa a rede, escuta em uma porta à sua escolha, aceita uma das suas chaves públicas e leva você direto ao prompt de desbloqueio. A senha é criptografada de ponta a ponta, do seu laptop até o initramfs. Essa é a resposta certa.

Dois detalhes costumam pegar as pessoas de surpresa. O Dropbear do initramfs tem sua própria chave de host, então o fingerprint dela difere do fingerprint do seu daemon SSH normal — isso é esperado, não é um ataque man-in-the-middle, e merece seu próprio arquivo known_hosts, em vez do hábito de digitar yes. E o nome da interface precisa estar certo: NICs virtio no Debian 13 costumam aparecer como ens3 ou enp1s0, não eth0. Verifique com ip -br link antes de escrever a configuração, porque errar isso significa um initramfs sem rede e uma viagem ao console.

Se a máquina precisa voltar sozinha — depois de uma atualização de kernel, um reinício do host, um evento de energia — digitar uma senha não é viável. O Clevis vincula um keyslot do LUKS a uma política externa, e o Tang é um pequeno servidor de troca de chaves que implementa a versão mais simples e útil dessa política.

# on a small server you control, elsewhere
apt install -y tang
systemctl enable --now tangd.socket

# on the encrypted VPS
apt install -y clevis clevis-luks clevis-initramfs
clevis luks bind -d /dev/vda2 tang '{"url":"http://tang.internal:7500"}'
update-initramfs -u -k all

No boot, o initramfs realiza uma troca McCallum-Relyea com o Tang e recupera a chave sem que o servidor Tang jamais a conheça ou veja a senha. Vale a pena declarar essas propriedades com precisão:

• O VPS se descriptografa sozinho somente enquanto consegue alcançar o Tang. Desligue o Tang, ou rotacione suas chaves, e o próximo boot trava. Isso é um verdadeiro interruptor de desligamento remoto — incomum e útil.
• O Tang não deve estar na internet pública. Alcance-o via WireGuard ou como um serviço onion do Tor; cobrimos o lado do túnel no guia de WireGuard.
• Coloque o Tang em uma jurisdição diferente da dos dados. Nossas páginas de jurisdição existem exatamente para esse tipo de separação.
• Mantenha uma senha em outro keyslot. O Clevis é uma camada de conveniência, não sua única forma de entrar.

Entenda o que você construiu: uma máquina sem intervenção guarda sua própria chave por procuração, então um adversário que apreenda o VPS enquanto ele está em execução, ou que consiga alcançar seu servidor Tang, obtém os dados. Isso é um enfraquecimento real em comparação com uma senha guardada na sua cabeça. Escolha essa opção quando a disponibilidade importar mais do que o último incremento de sigilo, e não por padrão.

Uma raiz criptografada cobre a maior parte da superfície, mas alguns caminhos escrevem fora dela ou sobrevivem a ela.

• Swap. Qualquer coisa na RAM pode ser paginada para o disco — chaves, corpos de mensagens, buffers descriptografados. Se o swap vive dentro do volume criptografado como um swapfile, ele está coberto. Uma partição de swap separada não está, a menos que você a adicione ao /etc/crypttab com uma chave aleatória que muda a cada boot: cryptswap /dev/vda3 /dev/urandom swap,cipher=aes-xts-plain64,size=256. Em um VPS, o swapfile é mais simples e não há motivo para preferir a partição.
• /tmp. Monte-o como tmpfs (tmpfs /tmp tmpfs defaults,nosuid,nodev,size=512M 0 0) para que ele nunca toque o disco. Também é mais rápido.
• Hibernação. Grava toda a RAM, incluindo sua chave mestra, no dispositivo de swap. Não a ative. Ela vem desativada por padrão em nossas imagens.
• O /boot não criptografado. Kernels, imagens de initramfs e a configuração do GRUB são legíveis e, mais importante, graváveis por qualquer um com acesso offline ao disco. O LUKS dá confidencialidade, não integridade de boot. Se o seu modelo de ameaça inclui alguém adulterando o bootloader, a criptografia sozinha não vai detectar isso — registre os hashes do /boot após cada atualização de kernel e verifique-os a partir de fora, ou aceite essa lacuna conscientemente.
• Snapshots existentes e volumes antigos. Criptografar hoje não faz nada por uma imagem tirada ontem. Se o servidor já rodou sem criptografia com dados que importam para você, trate esses dados como expostos e rotacione tudo o que foi derivado deles.

O overhead é pequeno o suficiente para não ser o fator decisivo, mas não é zero. Meça antes de especular:

cryptsetup benchmark

Em nossos nós EPYC, aes-xts com chave de 512 bits atinge, em benchmark, a casa dos poucos gigabytes por segundo por núcleo — folgadamente acima do que um único volume NVMe vai exigir. O custo que realmente aparece é latência e CPU em pequenas escritas aleatórias, não throughput.

Duas flags do LUKS2 importam em NVMe, onde as filas de trabalho do dm-crypt no kernel adicionam latência em vez de removê-la. Configure-as e faça com que persistam no cabeçalho:

cryptsetup refresh cryptroot \
  --perf-no_read_workqueue --perf-no_write_workqueue --persistent

A terceira flag, --allow-discards, repassa o TRIM para o dispositivo subjacente. Isso reduz a amplificação de escrita ao longo da vida do volume, ao custo de revelar quais blocos estão livres — o que vaza o tamanho e o formato aproximados dos seus dados para quem lê o dispositivo bruto. Ative-a em um servidor de uso geral; deixe-a desativada se o fato de um volume estar 3% cheio já for, em si, sensível. Não existe uma resposta universalmente certa, apenas uma decisão que você deve tomar de propósito.

O cabeçalho LUKS tem cerca de 16 MB na frente da partição, e guarda as cópias criptografadas da chave mestra. Danifique-o — um dd digitado errado, uma ferramenta de particionamento que “gentilmente” reescreve o início do dispositivo — e cada byte atrás dele se vai. Não existe serviço de recuperação. Nós não temos uma cópia.

# back it up, off the server, before you put data on the volume
cryptsetup luksHeaderBackup /dev/vda2 \
  --header-backup-file luks-header-$(date +%F).img

# add a second passphrase while you still have the first
cryptsetup luksAddKey /dev/vda2

# see what is in the header
cryptsetup luksDump /dev/vda2

Duas coisas sobre esse backup. Ele é tão sensível quanto o disco: contém keyslots, então um cabeçalho antigo restaurado depois que você trocou sua senha vai aceitar de bom grado a senha antiga. Guarde-o do mesmo jeito que guarda a senha, e destrua cópias obsoletas quando fizer a rotação. Segundo, o LUKS2 oferece 32 keyslots — use pelo menos dois, sendo o reserva uma senha longa e aleatória guardada em algum lugar onde a sua senha do dia a dia não está. O modo de falha que isso evita é chato e comum: você rotaciona a senha, digita errado de forma idêntica duas vezes, e só descobre no reinício seguinte, em vez de no próximo login.

Tenha também uma forma de voltar a entrar. O modo de recuperação inicializa o servidor a partir da nossa ISO com suas chaves SSH injetadas e o volume criptografado intocado, o que significa que você pode rodar cryptsetup open /dev/vda2 rescue && mount /dev/mapper/rescue /mnt e consertar um crypttab quebrado ou um initramfs com problema sem perder os dados. Teste isso uma vez, deliberadamente, enquanto nada está errado.

A coisa mais útil que um guia como este pode fazer é marcar seus próprios limites.

• Não protege um servidor em execução. A chave mestra fica na memória do kernel desde o desbloqueio até o desligamento. Acesso à memória no nível do hypervisor derrota essa proteção. Criptografia de memória — AMD SEV-SNP e equivalentes — é a única tecnologia que muda isso de forma material, e não a oferecemos hoje; um provedor que afirma que sua VM em execução é opaca a esse acesso, sem usar SEV, está enganado ou mentindo.
• Não torna você anônimo. Um disco criptografado em Zürich ainda tem um IP, um rastro de cobrança e uma sessão SSH que começou em algum lugar. Esse é um problema diferente, e detalhamos as formas como isso dá errado em os erros que te desanonimizam.
• Não muda o que um tribunal pode ordenar. Jurisdição governa a coação; criptografia governa a legibilidade. Em algumas jurisdições, você pode ser obrigado a divulgar uma senha pessoalmente. Nosso guia sobre processos legais cobre o que fazemos e o que não fazemos.
• Não sobrevive a uma senha perdida. Por design, e vale a pena repetir, porque o chamado de suporte pedindo nossa ajuda chega cerca de uma vez por mês, e a resposta é sempre a mesma.
• Não autentica a cadeia de boot. Confidencialidade não é integridade. O /boot é legível e modificável offline.

O que ela realmente faz é eliminar uma classe inteira de exposição — tudo o que acontece a um disco quando ele não está em execução, que é a maior parte do que acontece aos discos. Isso vale a hora investida. Combine isso com um cadastro no-KYC, pagamento em Monero e uma jurisdição escolhida de propósito, e cada camada cobre uma falha diferente. Nenhuma delas cobre todas.