O que acontece quando eu uso 'dd' para substituir o disco do qual o Ubuntu está sendo executado?

O que aconteceria se eu usasse

sudo dd if=/dev/zero of=/dev/sda

de uma instalação do Ubuntu em execução /dev/sda ?

Eu tentei em uma VM e parece ter limpado corretamente o disco. Será esse sempre o caso? Esta é uma maneira segura de "limpar" uma instalação do Ubuntu e todos os dados?

Minha pergunta é um pouco inspirada por:

1. Como desinstalo o Ubuntu de um computador?
2. Como o 'rm -rf /' pode excluir todos os arquivos no sistema? .

Na verdade, o sistema de arquivos ainda está montado e algumas gravações são armazenadas em buffer, o que significa que elas ainda estão na RAM esperando para serem gravadas no disco. Digamos que ddsobrescreva tudo corretamente e, logo atrás, os buffers estão sendo liberados e alguns dados potencialmente sensíveis estão sendo gravados de volta no disco. Portanto, não, essa não é uma maneira segura de limpar um disco.

Você pode evitar esse problema remontando primeiro no modo somente leitura o sistema de arquivos raiz e quaisquer outros sistemas de arquivos que estejam no disco (ou desmontando-os completamente, mas não será possível com o sistema de arquivos raiz) e, em seguida, não mais gravações devem ser permitidas nos sistemas de arquivos (para que nenhum buffer seja liberado); portanto, seu comando deve estar seguro agora, mesmo que ainda seja uma má idéia em caso de pânico, porque leva muito tempo.

Se você quiser ter algum tipo de recurso de exclusão de pânico, sugiro criptografar seu disco com LUKS (o instalador do Ubuntu pode fazer isso) e depois seguir minha resposta no Security Stack Exchange . Isso envolve a limpeza do cabeçote de criptografia, que tem apenas 2 MB de tamanho e leva menos de um segundo para substituir. Em seguida, reinicie o sistema e as chaves de criptografia de disco ficarão sem memória, sem maneiras de restaurá-las, pois o próprio cabeçote de criptografia também se foi.

Eu sacrifiquei uma VM usando um uso um pouco mais avançado de ddemprestado e ligeiramente modificado nas páginas do Arch Wiki .

Primeiro instale um bom medidor de progresso:

sudo apt-get install pv

E, em seguida, execute o ddcomando 'aprimorado'

sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null \
| base64)" -nosalt </dev/zero \
| pv -bartpes "$(sudo blockdev --getsize64 /dev/sda)" \
| sudo dd bs=64K of=/dev/sda

Isso deixará o disco preenchido com o texto cifrado AES. Uma limpeza completa e segura do disco? Provavelmente melhor que o seu próprio ddexemplo, mas nada é completamente seguro ou garantido ...

E você me deve uma VM :)

Referências:

• Arco: limpe com segurança o disco
• Arch: dd - Exemplo Avançado

Resposta curta: fará aproximadamente o que você deseja e, em seguida, nada funcionará. Usar ddvocê está operando em um nível abaixo do sistema de arquivos, o que significa que quaisquer restrições que se aplicariam não são mais relevantes (isso não significa que o kernel não possa impedi-lo de fazer isso - mas não o faz). Algum conteúdo do sistema de arquivos já está na memória, por exemplo, o kernel e o ddpróprio programa, e alguns estarão em cache. Existe a possibilidade de que, se o sistema estiver no modo multiusuário, alguns arquivos possam ser gravados de volta enquanto ddestiverem em andamento, supondo que eles realmente tenham sido alterados, e se você estiver com pressão de memória, algumas páginas de lá também poderão ser trocadas (eles devem ser criptografados e, portanto, inutilizáveis ​​após a reinicialização).

A maioria dos comandos que você emitiria após isso - incluindo reboot- não estaria no cache e, portanto, não funcionaria. Portanto, se você estiver no modo de usuário único, ele se sairá extremamente bem; se você estiver no modo multiusuário, ele limpará a grande maioria dos dados. Idealmente, você deve fazer o boot de algum outro meio (até mesmo parar no initrd, talvez) para ter certeza de onde todas as gravações estão vindo.

Se você deseja uma limpeza segura, isso não funcionará porque ainda restarão alguns traços dos dados originais se você apenas zerá-los. Normalmente, você deseja até três gravações aleatórias, o que significa copiar em /dev/urandomvez de /dev/zero- muito mais lento, mas mais seguro. Alguns podem sugerir que você use /dev/randomo dispositivo para dados aleatórios "puros" - não pseudoaleatórios -, mas para esse propósito, a chance de alguém conseguir quebrar a semente do PRNG e mascarar com êxito os dados é essencialmente insignificante.

Se você é realmente paranóico, precisa jogar o dispositivo de armazenamento em um forno para desmagnetizar / descarregar.

Como na sua VM, limpará o disco e tornará seu sistema inutilizável.

No entanto, se você tem um tipo de 'exclusão de pânico' em mente, ddpode não ser rápido o suficiente para isso e não tenho certeza se existem comandos ou programas mais rápidos fornecendo esse recurso nesse caso.

Deve funcionar, o processo em execução é realizado no Ram e não precisa do disco. Eu usaria um sistema ao vivo rodando de CD ou USB de qualquer maneira. Existe até o dban, um linux ativo especializado para limpeza de disco.

A substituição de zeros no disco é salva, mas se você for paranóico o suficiente ou tiver regras legais, poderá sobrescrever dados aleatórios várias vezes.

Tenha cuidado ao usar a substituição de ssd não garante a exclusão de todos os dados devido ao nivelamento do desgaste.

Se você usar a criptografia de disco completo (luks), não precisará excluir o disco completo, excluir o cabeçalho do luks é suficiente.