Qubes OS 100% na RAM: Modo Live Anti-Forense, Amnésico e com Anti Cold Boot Attack

SEGURANÇA AVANÇADA TUTORIAL COMPLETO NÍVEL: AVANÇADO

Neste artigo você aprenderá como tornar o Qubes OS completamente anti-forense, operando 100% na memória RAM, assim como o Tails OS faz. Entenda por que usar o Qubes em modo live na RAM com anti cold boot attack e o que isso representa em termos de segurança real. O script ephemeral.sh, desenvolvido por leandroibov, automatiza toda essa configuração: coloca o dom0 100% na RAM, instala os módulos anti cold boot attack e ainda oferece atalhos de teclado para desligamento de emergência em caso de ataque físico.

O que é o modo live 100% na RAM e por que é a técnica mais eficaz de segurança para operações sensíveis

O acesso físico ao seu dispositivo pode expor rastros e metadados que permanecem acessíveis mesmo após você acreditar ter apagado tudo. Arquivos deletados, históricos de navegação, chaves criptográficas temporárias e metadados de sistema ficam gravados no disco e podem ser recuperados com ferramentas forenses mesmo depois de formatações comuns.

Usando secure erase em HD é possível aniquilar os rastros, mas é um processo demorado. Não há tempo de apagar os rastros com secure erase caso sua casa seja invadida com o objetivo de acessar seu computador. Ao desligar o PC com anti cold boot attack ativado, todos os rastros e metadados são aniquilados imediatamente, pois nunca foram escritos no disco.

Criptografia robusta resolve o problema? Não completamente, e aqui está o motivo mais importante que poucas pessoas consideram:

Por isso, o meio mais eficaz de proteger informações sensíveis é operar tudo: metadados, rastros, arquivos, tudo 100% na memória RAM com sistema anti cold boot. Assim, ao desligar a máquina, não existe absolutamente nada para recuperar.

O problema específico do Qubes OS: O Qubes roda lentamente em HD mesmo em computadores potentes, então o caminho natural é usar SSD. Porém o SSD não garante secure erase, conforme comprovado nas referências abaixo. A melhor tática é usar SSD no Qubes para o desempenho, mas para operações que requerem anti-forense avançada e amnésia total, coloca-se o dom0 100% na memória RAM e as AppVMs, DispVMs e Standalone VMs dentro do dom0, para que tudo fique 100% na RAM assim como o Tails OS faz.

Infelizmente, para colocar um sistema inteiro de 200 GB ou 600 GB na RAM seria necessária uma quantidade absurda de memória. O dom0 por padrão vem com uma partição de 20 GB, mas pode ser aumentada. Com 20 GB é possível colocar muitas AppVMs leves. Você precisará gerenciar isso com cuidado.

Pesquisas que comprovam a falha do secure erase em SSD:

• Artigo completo no USENIX Clique aqui!
• Blog de Bruce Schneier Clique aqui!
• The Register Clique aqui!

Qubes OS é superior ao Tails quando usa o modo ephemeral 100% na RAM

Quando o Qubes OS opera em modo ephemeral, ele herda todas as vantagens do Tails OS em termos de amnésia e anti-forense, mas adiciona camadas de segurança que o Tails simplesmente não possui. Veja a comparação:

Gateway Tor isolado via Whonix: No Qubes com Whonix, o roteamento Tor é feito por uma VM isolada (sys-whonix). Isso impede que um atacante que invada sua VM de trabalho descubra seu IP real, pois o Tor é gerenciado por outra máquina virtual completamente separada.

Anti Cold Boot Attack: por que todo sistema precisa disso e por que apenas desligar não é suficiente

Um ataque cold boot consiste em extrair dados sensíveis diretamente da memória RAM após o desligamento da máquina. Chaves LUKS, senhas, tokens de sessão e qualquer informação que estava na memória durante a sessão podem ser recuperados por um atacante com acesso físico ao equipamento.

A pesquisa da empresa 3mdeb confirmou experimentalmente que chips DDR4 e DDR5 modernos, os mais usados nos computadores atuais, retêm dados legíveis por segundos ou até minutos após a perda de energia. Em alguns módulos testados, os bits permaneceram estáveis por tempo suficiente para um atacante físico congelar os chips com spray de ar comprimido invertido ou nitrogênio líquido, removê-los e transferi-los para outra máquina, recuperando o conteúdo intacto.

Na parte 2 da pesquisa ficou claro que o comportamento varia muito entre fabricantes e modelos: alguns módulos se degradam em menos de 1 segundo, outros levam vários minutos para atingir 49,5% de bits alterados, que é o limiar mínimo de irrecuperabilidade.

Pesquisas sobre remanencia de dados na RAM:

• Research of RAM data remanence times (Parte 1) Clique aqui!
• Research of RAM data remanence times (Parte 2) Clique aqui!
• Documentacao oficial ram-wipe Kicksecure/Whonix Clique aqui!

Ephemeral: Instalação do Qubes OS 100% em RAM com Anti-Forense e Anti Cold Boot Attack

Este script automatiza a configuração para rodar o dom0 do Qubes inteiramente em RAM, utilizando AppVMs e templates no varlibpool, mantendo um estado anti-forense e amnésico semelhante ao Tails OS. Também permite restaurar o estado original do Qubes com um único comando.

Baixe o script no repositório oficial do desenvolvedor leandroibov: GitHub do projeto Clique aqui!

Qual versão usar:

• Para o Qubes 4.2: use 4.2.ephemeral.sh ou 4.2.ephemeral_old.sh (a versão mais antiga, testada por mais tempo).
• Para o Qubes 4.3: use 4.3.ephemeral.sh.
• Quando lançar novas versões do Qubes, os correspondentes ephemeral.sh scripts estarão no meu github!.

Exemplo de instalação com 4.3.ephemeral.sh:

1. Copie o script 4.3.ephemeral.sh para a AppVM vault, para o usuário user, em /home/user/. O novo caminho será /home/user/4.3.ephemeral.sh.

2. Abra um terminal no dom0 e execute os comandos abaixo:

qvm-run --pass-io vault 'cat "/home/user/4.3.ephemeral.sh"' > /home/user/4.3.ephemeral.sh
sudo chmod +x 4.3.ephemeral.sh
sudo ./4.3.ephemeral.sh

Opção 1: Rodar o Qubes com dom0 100% em RAM

Para usar AppVMs e templates inteiramente em RAM, você deve criá-los no varlibpool dentro do dom0. O ambiente Qubes torna-se híbrido: o dom0 opera 100% em RAM, enquanto as VMs no pool no SSD ou HD funcionam normalmente mas não estão em RAM.

Ao reiniciar, aparecerá uma opção y/n: use y para o modo live (como o Tails) ou n para continuar com o dom0 normal no SSD.

Se você configurou o Qubes para 15 GB de RAM, usar a opção n continuará alocando essa quantidade ao dom0, o que é ineficiente já que apenas 4 GB são necessários para uso normal. A Opção 2 permite restaurar as condições originais, fazendo o dom0 usar 4 GB e liberando o restante para outras VMs.

Opção 2: Restaurar as configurações padrão do Qubes

Para reverter tudo ao estado original, ao reiniciar escolha a opção n e então execute:

sudo ./4.3.ephemeral.sh
# Escolha a opção 2 no menu
reboot

Seu Qubes voltará ao comportamento normal e a opção y/n para o modo live não aparecerá mais na inicialização.

Opção 3: Instalar os Módulos de Proteção contra Cold Boot Attack

Similar ao Tails OS e ao Whonix, usando o mesmo algoritmo de proteção contra cold boot attack desenvolvido pela equipe do Whonix. O usuário precisará configurar um atalho de teclado para acionar rapidamente o desligamento caso um atacante físico invada sua casa para realizar um cold boot attack. O dom0 não permite a conexão de pen drives USB, portanto não é possível programar um dispositivo USB para iniciar a proteção removendo-o e desligando o sistema, como no Tails.

sudo shutdown now

Opção 4: Remover os Módulos de Proteção contra Cold Boot Attack

Para manutenção em caso de problemas. Esta opção verifica os hashes SHA-256 originais dos arquivos usados para criar os módulos do Dracut e indica modificações ou arquivos ausentes para diagnosticar erros de instalação. Após verificação, oferece a opção de remover os módulos e regenerar o initramfs.

Notas Importantes sobre Tamanho do dom0 e RAM necessária

O dom0 tem um tamanho padrão de 20 GB, ocupando inicialmente cerca de 6 GB do sistema. Para adicionar muitos templates e AppVMs grandes totalizando, por exemplo, 40 GB, pode ser necessário:

• Aumentar o tamanho da partição do dom0.
• Garantir que você tenha RAM suficiente para comportar tudo isso.
• Mínimo recomendado: 16 GB de RAM para uso confortavel.
• Para sistemas com mais VMs ou templates maiores: 32 GB ou mais.

Análise Técnica Completa do Script 4.3.ephemeral.sh para Usuários Avançados

Script desenvolvido por leandroibov com base nas contribuições da comunidade Qubes OS. Fontes originais:

• Qubes in tmpfs Clique aqui!
• RAM-Wipe in dom0 Clique aqui!

Visão Geral e Arquitetura do Script

O script 4.3.ephemeral.sh transforma o Qubes OS em um sistema operacional efêmero similar ao Tails OS, onde o dom0 (o domínio privilegiado do Xen) opera inteiramente a partir da RAM, sem deixar rastros no disco após o desligamento. O Qubes OS é baseado no hipervisor Xen. O dom0 é o domínio administrativo com acesso direto ao hardware, responsável por gerenciar todos os outros domínios (AppVMs, TemplateVMs, etc.). Comprometer o dom0 equivale a comprometer toda a máquina.

O script é estruturado em cinco funções principais, chamadas por um menu interativo:

Dependencias externas utilizadas pelo script:

• dmidecode : leitura de informações de hardware (memória RAM física)
• findmnt : identificacao do dispositivo montado como /
• df : cálculo do espaço usado em /var/lib/qubes
• dracut : geração do initramfs (imagem de boot inicial)
• grub2-mkconfig : regeneração dos arquivos de configuração do GRUB
• sha256sum : verificação de integridade dos módulos instalados
• dmsetup : gerenciamento de dispositivos mapeados (LUKS/dm-crypt)
• zram : módulo do kernel para disco virtual comprimido em RAM
• mkfs.ext2 : criação do sistema de arquivos no dispositivo ZRAM

check_root_ram(): A Barreira de Segurança Inicial

Esta função é executada ANTES de qualquer operação e serve como proteção contra erros críticos. Ela identifica qual dispositivo de bloco está montado como raiz do sistema e verifica se já é um dispositivo ZRAM.

Se o sistema já está rodando em ZRAM (modo RAM ativo), executar a opção 1 novamente geraria um initramfs incorreto, potencialmente tornando o sistema impossível de bootar. A proteção evita essa catástrofe. O método com findmnt é mais preciso do que verificar a existência de /sys/block/zram0, pois a simples presença do bloco ZRAM não indica necessariamente que o sistema está rodando nele.

ephemeral_qubes(): O Pipeline Completo de Boot em RAM

Esta é a função central do script, operando em sete etapas sequenciais:

Etapa A: Cálculo de RAM disponível

Utiliza dmidecode para ler diretamente as tabelas SMBIOS/DMI do hardware e obter o tamanho físico de cada módulo de RAM instalado. Isso é mais preciso do que usar /proc/meminfo, que mostra a RAM disponível para o sistema operacional já descontando o overhead do kernel.

Etapa B: Cálculo do espaço usado no dom0

Verifica quanto espaço está REALMENTE sendo usado na partição que contém /var/lib/qubes. Esse valor é o mínimo de RAM que o ZRAM precisa ter para comportar uma cópia completa do dom0.

Etapa C: Validação interativa da entrada do usuário

Loop com múltiplas validações: o valor deve ser inteiro positivo, não pode ser maior que a RAM total da máquina e não pode ser menor que o espaço usado no dom0. Isso previne configurações impossíveis que causariam corrupção de dados.

Etapa D: Modificação do GRUB e do Xen

Cria backup do grub antes de qualquer alteração e insere novos parâmetros no hipervisor Xen (detalhados na seção de GRUB abaixo). Regenera os arquivos de configuração para BIOS Legacy e UEFI.

Etapa E: Desativação do swap

Remove a entrada de swap do /etc/fstab e esvazia o serviço [email protected]. Essencial para evitar que dados sensíveis vazem para o disco físico durante a sessão em RAM.

Etapa F: Criação do módulo Dracut 01ramboot

Cria três scripts no diretório /usr/lib/dracut/modules.d/01ramboot/:

• module-setup.sh: Registra o módulo no Dracut e instala o hook de boot com prioridade 00 (executado muito cedo, antes da maioria dos outros scripts).
• pass.sh: Exibe o prompt interativo Boot to RAM? (y/n) durante o boot usando a função ask_for_password da biblioteca dracut-crypt-lib.sh, com suporte a Plymouth (gráfico) e TTY (texto).
• tmpfs.sh: O coração do sistema. Quando o usuário responde y, desmonta /sysroot, carrega o módulo ZRAM, cria um dispositivo ZRAM do tamanho configurado, formata como ext2, monta como novo sistema raiz e copia TODO o conteúdo do dom0 do LVM para o ZRAM com cp -a.

Etapa G: Verificação de integridade pós-instalação

Calcula os hashes SHA-256 dos arquivos gerados e compara com valores esperados gravados no script. Qualquer divergência é reportada ao usuário.

Dracut e o initramfs: como funciona a cadeia de boot

O Dracut é o framework usado pelo Qubes OS (baseado em Fedora) para gerar o initramfs, a imagem de boot inicial carregada pelo bootloader. O ciclo de vida completo:

ZRAM: O Disco Virtual Comprimido Inteiramente na RAM

ZRAM é um módulo do kernel Linux que cria dispositivos de bloco comprimidos inteiramente na memória RAM. Originalmente projetado para swap comprimido em dispositivos com pouca RAM, aqui é usado para criar um disco raiz volátil.

• Compressão transparente (LZ4 ou ZSTD por padrão): um sistema de 10 GB pode ocupar apenas 3 a 5 GB de RAM após compressão.
• Acesso extremamente rápido: latência de RAM, não de disco.
• Completamente volátil: desaparece ao desligar.

O sistema de arquivos escolhido é ext2 por ser simples e sem journaling. Para uso em RAM onde a consistência em caso de falha de energia não é uma preocupação (o sistema é amnésico de qualquer forma), ext2 é a escolha mais eficiente.

Após a cópia com cp -a, o sistema raiz real do boot passa a ser o ZRAM. O LVM original no SSD permanece montado apenas em /mnt como referência, ficando efetivamente inativo para o restante da sessão. A partir desse momento, TODAS as escritas vão para o ZRAM (RAM) e o SSD não recebe nenhum dado novo da sessão atual.

Módulo Anti Cold Boot Attack (40ram-wipe): Como Funciona

O módulo opera em dois momentos distintos do ciclo de shutdown do Dracut:

wipe-ram-needshutdown.sh (hook: cleanup, prioridade 80): Executado DURANTE o boot normal. Registra que o sistema precisa voltar ao initramfs durante o shutdown, chamando need_shutdown. Isso permite executar código de limpeza ANTES da memória ser liberada. Se o parâmetro de kernel wiperam=skip for detectado, o módulo se desativa graciosamente, útil para manutenção.

wipe-ram.sh (hook: shutdown, prioridade 40): Executado NO SHUTDOWN, dentro do initramfs. Executa a função drop_caches() seguida de ram_wipe():

Após o drop_caches, o script verifica via dmsetup ls --target crypt se ainda existem volumes LUKS montados. Volumes LUKS mantêm as chaves de descriptografia na RAM enquanto estão ativos. Se ainda houver volumes montados no shutdown, as chaves ainda estão na memória, representando risco para ataques cold boot. O Dracut deve fechar automaticamente os volumes LUKS durante o shutdown, mas o script verifica explicitamente e reporta qualquer anomalia via force_echo() no kernel log.

Modificações no GRUB e no Xen Hypervisor

A cadeia de boot do Qubes OS é: UEFI/BIOS, depois GRUB, depois Xen Hypervisor, depois Kernel dom0, depois initramfs, depois dom0. Os parâmetros adicionados ao GRUB_CMDLINE_XEN_DEFAULT afetam o Xen, não diretamente o kernel Linux:

• console=none: Desativa o console serial. Reduz a superfície de ataque e evita logging desnecessário.
• dom0_mem=min:1096M e dom0_mem=max:Xm: Define os limites de memória do dom0. Crítico para que o dom0 tenha RAM suficiente para o ZRAM configurado.
• ucode=scan: Força o Xen a escanear o initramfs por atualizações de microcódigo do processador. Essencial para aplicar mitigações de Spectre e Meltdown o mais cedo possível no boot.
• smt=off: Desativa o Hyper-Threading (SMT) no nível do hipervisor. Mitiga ataques de canal lateral como MDS, TAA, RIDL, Fallout e ZombieLoad. O custo é perda de desempenho de aproximadamente 20 a 30% em cargas de trabalho paralelas.
• gnttab_max_frames=2048 e gnttab_max_maptrack_frames=4096: Aumentam os limites da grant table do Xen, necessário para suportar mais VMs e operações de I/O com o dom0 expandido em RAM.

Desativação do Swap: Por que é Obrigatória em Modo Ephemeral

O script realiza duas operações relacionadas ao swap. Primeira: remove entradas de swap do /etc/fstab usando expressão regular que captura linhas contendo a palavra swap entre espaços e tabs. Segunda: esvazia o serviço [email protected], que é o swap baseado em ZRAM do próprio Qubes OS.

Se o sistema usasse swap no SSD durante a sessão em RAM, dados sensíveis poderiam vazar para o disco físico, quebrando a propriedade amnésica do sistema. Além disso, manter o serviço de ZRAM-swap ativo criaria um segundo dispositivo ZRAM em paralelo com o usado para boot em RAM, gerando conflito.

Verificação de Integridade via SHA-256

Após criar todos os arquivos dos módulos, o script calcula os hashes SHA-256 e compara com valores esperados gravados diretamente no código. Isso serve para três propósitos: verificar que os arquivos foram escritos sem corrupção, detectar adulterações (se um adversário modificar os scripts de boot para inserir backdoors o hash divergirá) e diagnosticar erros de instalação.

Restauração do Sistema Original: Como Funciona

O script cria backups (.bak) de TODOS os arquivos modificados antes de qualquer alteração:

• /etc/default/grub passa a ter backup em /etc/default/grub.bak
• /etc/fstab passa a ter backup em /etc/fstab.bak
• O serviço systemd-zram-setup passa a ter backup com extensão .bak

A restauração segue esta ordem crítica:

1. Remove os módulos Dracut (01ramboot)
2. Regenera o initramfs (sem os módulos efêmeros)
3. Restaura o grub a partir do .bak e regenera o GRUB
4. Restaura o fstab (swap volta a funcionar)
5. Restaura o serviço zram-swap

Limitações e Considerações de Segurança

• Cópia completa via cp -a: A cópia do sistema para ZRAM pode levar vários minutos em sistemas com dom0 maior. Durante esse tempo o sistema está parado na fase de initramfs sem timeout configurado.
• AppVMs no SSD não são amnésicas: Apenas o dom0 é efêmero. AppVMs e Templates no pool padrão, o vm-pool (SSD), continuam persistentes. Para uso anti-forense completo o usuário deve criar VMs exclusivamente em dispositivos efêmeros.
• Atalho de shutdown anti-cold-boot: O comando sudo shutdown now pode não acionar o hook de cleanup do Dracut imediatamente em todos os cenários. Comandos como systemctl poweroff ou halt -p podem ser mais confiáveis para garantir que o wipe-ram seja executado.
• ZRAM sem criptografia: O dispositivo ZRAM em si não é criptografado. Um atacante com acesso a memória física via DMA poderia ler o conteúdo do ZRAM. O módulo anti-cold-boot mitiga isso, mas não elimina completamente o risco.
• Ausência de Secure Boot Integration: O script não configura nem verifica Secure Boot. Em sistemas com Secure Boot ativo, modificações no initramfs podem exigir reassinatura dos binários.
• Integridade do script original: O script deve ser transferido do vault para o dom0 via qvm-run --pass-io. O usuário deve verificar o hash do script original antes de executá-lo como root no dom0.

Diagrama Geral do Fluxo

Fluxo de Boot em Modo Ephemeral (resposta y):

Fluxo de Shutdown com Anti Cold Boot:

Fluxo de Restauração ao Estado Original:

Referências Técnicas

• Documentação oficial do Dracut Clique aqui!
• Xen Project: parâmetros de memória do dom0 Clique aqui!
• Whonix RAM Wipe no forum Qubes OS Clique aqui!
• Qubes OS: objetivos de design de segurança Clique aqui!
• Pesquisa de remanência de dados na RAM parte 1 - 3mdeb Clique aqui!
• Pesquisa de remanência de dados na RAM parte 2 - 3mdeb Clique aqui!
• Kicksecure ram-wipe: documentação oficial Clique aqui!
• Repositório GitHub ram-wipe Kicksecure Clique aqui!
• Bruce Schneier sobre falhas do secure erase em SSD Clique aqui!