Como limpar o espaço livre em disco no Linux?

132

Quando um arquivo é excluído, seu conteúdo ainda pode ser deixado no sistema de arquivos, a menos que explicitamente sobrescrito por outra coisa. O comando wipe pode apagar arquivos com segurança, mas não parece permitir o espaço livre em disco que não é usado por nenhum arquivo.

O que devo usar para conseguir isso?

    
por Alex B 07.08.2009 / 01:48

16 respostas

100

Aviso: Modern hardware de disco / SSD e sistemas de arquivos modernos podem esquadrinhar dados em lugares onde você não pode apagá-los, então este processo ainda pode deixar dados no disco. As únicas formas seguras de limpar dados são o comando ATA Secure Erase (se implementado corretamente) ou a destruição física. Veja também Como posso apagar de forma confiável todos informações em um disco rígido?

Você pode usar um conjunto de ferramentas chamado secure-delete.

sudo apt-get install secure-delete

Isso tem quatro ferramentas:

srm - exclua com segurança um arquivo existente
smem - exclua com segurança os rastreamentos de um arquivo da RAM
sfill - limpe todo o espaço marcado como vazio no disco rígido
sswap - limpe todos os dados do seu espaço de troca.

Da página do manual de srm

srm is designed to delete data on mediums in a secure manner which can not be recovered by thiefs, law enforcement or other threats. The wipe algorithm is based on the paper "Secure Deletion of Data from Magnetic and Solid-State Memory" presented at the 6th Usenix Security Symposium by Peter Gutmann, one of the leading civilian cryptographers.

The secure data deletion process of srm goes like this:

  • 1 pass with 0xff
  • 5 random passes. /dev/urandom is used for a secure RNG if available.
  • 27 passes with special values defined by Peter Gutmann.
  • 5 random passes. /dev/urandom is used for a secure RNG if available.
  • Rename the file to a random value
  • Truncate the file

As an additional measure of security, the file is opened in O_SYNC mode and after each pass an fsync() call is done. srm writes 32k blocks for the purpose of speed, filling buffers of disk caches to force them to flush and overwriting old data which belonged to the file.

    
por 07.08.2009 / 03:55
67

A maneira mais rápida, se você precisar apenas de um único passo e quiser apenas substituir tudo por zeros, é:

cat /dev/zero > zero.file
sync
rm zero.file

(executado a partir de um diretório no sistema de arquivos que você deseja limpar)
(o comando sync é uma medida de paranoia que garante que todos os dados sejam gravados no disco - um gerenciador de cache inteligente pode pode cancelar gravações para blocos pendentes quando o arquivo é desvinculado)

Haverá um tempo durante esta operação, quando não haverá espaço livre no sistema de arquivos, o que pode ser de dezenas de segundos se o arquivo resultante for grande e fragmentado, portanto, demorará um pouco para ser apagado. Para reduzir o tempo em que o espaço livre é completamente zero:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
cat /dev/zero > zero.file
sync
rm zero.small.file
rm zero.file

Isso deve ser suficiente para impedir que alguém leia o conteúdo antigo do arquivo sem uma operação forense cara. Para uma variante um pouco mais segura, mas mais lenta, substitua /dev/zero por /dev/urandom . Para mais paranóia, execute vários passos com /dev/urandom , mas se você precisar de tanto esforço, o utilitário shred do pacote coreutils é o caminho a seguir:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
shred -z zero.small.file
cat /dev/zero > zero.file
sync
rm zero.small.file
shred -z zero.file
sync
rm zero.file

Note que no arquivo acima o pequeno arquivo é triturado antes de criar o maior, então ele pode ser removido assim que o maior for concluído, em vez de ter que esperar que ele seja triturado deixando o sistema de arquivos com zero de espaço livre durante o tempo isso leva. O processo de fragmentação demora tempo em um arquivo grande e, a menos que você esteja tentando ocultar algo da NSA, não é realmente necessário.

Todos os itens acima devem funcionar em qualquer sistema de arquivos.

Limites de tamanho de arquivo:

Como DanMoulding aponta em um comentário abaixo, isso pode ter problemas com limis de tamanho de arquivo em alguns sistemas de arquivos.

Para o FAT32, definitivamente seria uma preocupação devido ao limite de arquivos de 2GiB: a maioria dos volumes é maior do que atualmente (8TiB é o limite de tamanho do volume IIRC). Você pode contornar isso canalizando a grande saída cat /dev/zero de saída através de split para gerar vários arquivos menores e ajustar os estágios de fragmentação e exclusão de acordo.

Com ext2 / 3/4 é menos preocupante: com o bloco padrão / comum de 4K o limite de tamanho de arquivo é de 2TiB, então você precisa ter um volume enorme para que este seja um problema (o tamanho máximo do volume sob essas condições é 16TiB).

Com o (ainda experimental) btrfs, os tamanhos máximos de arquivo e volume são 16EiB.

Em NTFS, o tamanho máximo do arquivo é maior que o tamanho máximo do volume em alguns casos, mesmo.

Pontos de partida para mais informações:
link
link
link

Dispositivos virtuais

Como mencionado nos comentários recentemente, há considerações extras para dispositivos virtuais:

  • Para discos virtuais escassamente alocados, outros métodos, como aqueles usados por zerofree , serão mais rápidos (embora, ao contrário de cat e dd , essa não seja uma ferramenta padrão na qual você pode confiar qualquer sistema operacional unix-a-like).

  • Esteja ciente de que zerar um bloco em um dispositivo virtual esparso pode não apagar o bloqueio no dispositivo físico subjacente, na verdade eu diria que é improvável que - o gerenciador de disco virtual apenas fará com que o bloco não seja mais usado, de modo que possa ser alocado para outra coisa mais tarde.

  • Mesmo para dispositivos virtuais de tamanho fixo, você pode não ter controle de onde o dispositivo mora fisicamente para que possa ser movido em seu local atual ou em um novo conjunto de discos físicos a qualquer momento e o máximo que você pode limpar é a localização atual, não quaisquer localizações anteriores que o bloco possa ter residido no passado.

  • Para os problemas acima em dispositivos virtuais: a menos que você controle o (s) host (s) e possa fazer uma limpeza segura de seu espaço não alocado depois de limpar os discos na VM ou mover o dispositivo virtual, não há nada que você pode fazer sobre isso após o fato. O único recurso é usar a criptografia total de disco desde o início , de modo que nada descriptografado seja todo gravado na mídia física em primeiro lugar. Ainda pode haver uma limpeza no espaço livre dentro da VM, é claro. Note também que o FDE pode tornar os dispositivos virtuais esparsos muito menos úteis, já que a camada de virtualização não pode realmente ver quais blocos estão sem uso. Se a camada do sistema de arquivos do sistema operacional enviar comandos de ajuste para o dispositivo virtual (como se fosse um SSD) e o controlador virtual os interpretar, isso pode resolver isso, mas não sei de nenhuma circunstância em que isso realmente acontece e A discussão sobre isso é uma questão para outros lugares (já estamos chegando perto de estar fora do tópico para a pergunta original, então se isso despertou seu interesse, algumas questões de experimentação e / ou de acompanhamento podem estar em ordem).

por 07.08.2009 / 10:58
41

AVISO

Fiquei chocado com quantos arquivos photorec puderam ser recuperados do meu disco, mesmo após a limpeza.

Se há mais segurança em preencher o "espaço livre" apenas 1 vez com 0x00 ou 38 vezes com diferentes padrões cabalísticos é mais uma discussão acadêmica. O autor do seminal paper de 1996 sobre o shredding escreveu para si mesmo um epílogo dizendo que isso é obsoleto e desnecessário para o hardware moderno. Não há nenhum caso documentado de dados sendo zerados fisicamente e recuperados posteriormente.

O verdadeiro link frágil neste procedimento é o sistema de arquivos . Alguns sistemas de arquivos reservam espaço para uso especial e não são disponibilizados como "espaço livre". Mas seus dados podem estar lá . Isso inclui fotos, e-mails de texto simples, o que for. Acabei de pesquisar no Google + space + ext4 e descobri que 5% da minha home partição estava reservada. Eu acho que é aqui que photorec encontrou muito das minhas coisas. Conclusão: o método de destruição não é o mais importante, mesmo o método multi-pass ainda deixa os dados no lugar .

Você pode tentar # tune2fs -m 0 /dev/sdn0 antes de montá-lo. (Se esta for a partição raiz após a reinicialização, certifique-se de executar -m 5 ou -m 1 depois de desmontá-la).

Mas ainda assim, de um jeito ou de outro, pode haver algum espaço sobrando.

A única maneira realmente segura é apagar toda a partição, criar um sistema de arquivos novamente e restaurar seus arquivos a partir de um backup.

Caminho rápido (recomendado)

Execute a partir de um diretório no sistema de arquivos que você deseja limpar:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file

Notas: o objetivo do arquivo pequeno é reduzir o tempo em que o espaço livre é completamente zero; a finalidade da sincronização é garantir que os dados estejam realmente gravados.

Isso deve ser bom o suficiente para a maioria das pessoas.

Caminho lento (paranóico)

Não há nenhum caso documentado de dados sendo recuperados após a limpeza acima. Seria caro e exigiria recursos, se possível.

No entanto, se você tem uma razão para pensar que as agências secretas gastariam muitos recursos para recuperar seus arquivos, isso seria suficiente:

dd if=/dev/urandom of=random.small.file bs=1024 count=102400
dd if=/dev/urandom of=random.file bs=1024
sync ; sleep 60 ; sync
rm random.small.file
rm random.file

Demora muito mais tempo.

Aviso. Se você escolheu o caminho paranóico, depois disso você ainda quer fazer a limpeza rápida, e isso não é paranóia. A presença de dados puramente aleatórios é fácil e barata de detectar, e levanta a suspeita de que são dados realmente criptografados. Você pode morrer sob tortura por não revelar a chave de decodificação.

Caminho muito lento (louco paranóico)

Até mesmo o autor do seminal paper de 1996 sobre o shredding escreveu um epílogo dizendo que isso é obsoleto e desnecessário para o hardware moderno.

Mas se você ainda tem muito tempo livre e não se importa de gastar seu disco com muita sobrescrita, lá vai:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
sync ; sleep 60 ; sync
shred -z zero.small.file
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
shred -z zero.file
sync ; sleep 60 ; sync
rm zero.file

Nota: isto é essencialmente equivalente ao uso da ferramenta secure-delete.

Antes da edição, este post foi uma reescrita de David Spillett. O comando "cat" produz uma mensagem de erro, mas não consigo escrever comentários nos posts de outras pessoas.

    
por 09.06.2010 / 19:40
24

Existe o utilitário zerofree pelo menos no Ubuntu:

link

   zerofree — zero free blocks from ext2/3 file-systems

   zerofree  finds  the  unallocated, non-zeroed blocks in an ext2 or ext3
   filesystem (e.g. /dev/hda1) and fills them with zeroes. This is  useful
   if  the  device  on  which this file-system resides is a disk image. In
   this case, depending on the type of disk image, a secondary utility may
   be  able  to  reduce the size of the disk image after zerofree has been
   run.

   The usual way to achieve  the  same  result  (zeroing  the  unallocated
   blocks)  is to run dd (1) to create a file full of zeroes that takes up
   the entire free space on the drive, and then delete this file. This has
   many disadvantages, which zerofree alleviates:

      ·  it is slow;

      ·  it makes the disk image (temporarily) grow to its maximal extent;

      ·  it  (temporarily)  uses  all  free  space  on  the disk, so other
         concurrent write actions may fail.

   filesystem has to be unmounted or mounted  read-only  for  zerofree  to
   work.  It  will exit with an error message if the filesystem is mounted
   writable. To remount the  root  file-system  readonly,  you  can  first
   switch to single user runlevel (telinit 1) then use mount -o remount,ro
   filesystem.

Também verifique este link sobre zerofree: Mantendo as imagens do sistema de arquivos esparsas - é de seu autor - Ron Yorston (9 de agosto de 2012)

    
por 05.01.2013 / 15:51
3

Veja como fazer isso com uma GUI.

  1. Instale o BleachBit
  2. Executar como root clicando em Aplicativos - Ferramentas do sistema - BleachBit como administrador.
  3. Nas preferências, diga quais caminhos você deseja. Geralmente adivinha-os bem. Você deseja incluir um caminho gravável para cada partição. Geralmente, isso é / home / username e / tmp, a menos que sejam a mesma partição, nesse caso, basta escolher uma.
  4. Marque a caixa Sistema - Limpe o espaço livre em disco.
  5. Clique em Excluir.

O avanço do BleachBit pelo dd (que de outra forma é muito bom) é quando o disco está finalmente cheio, o BleachBit cria pequenos arquivos para limpar os inodes (que contém metadados como nomes de arquivos, etc).

    
por 06.11.2009 / 13:40
2

Eu uso dd para alocar um ou mais arquivos grandes para preencher o espaço livre e, em seguida, usar um utilitário de exclusão segura.

Para alocar arquivos com o dd tente:

dd if=/dev/zero of=delete_me bs=1024 count=102400

Isso gerará um arquivo chamado delete_me com 100 MB de tamanho. (Aqui bs é o "tamanho do bloco" definido como 1k e count é o número de blocos a serem alocados.)

Em seguida, use seu utilitário de exclusão segura favorito (estou usando shred ) na arquivos assim criados.

Mas NOTE ISTO: bufferizar significa que mesmo se você fizer o disco inteiro , você pode não ter absolutamente tudo!

Este link recomenda scrub para limpeza de espaço livre. Não tentei isso.

    
por 07.08.2009 / 03:04
2

Limpe uma unidade na velocidade máxima.

As instruções típicas para criptografar uma unidade hoje em dia dirão que você primeiro limpe a unidade.

O comando abaixo preencherá sua unidade com o texto cifrado AES.

Use um CD ao vivo se precisar limpar sua unidade de inicialização principal.

Abra um terminal e eleve seus privilégios:

sudo bash

Vamos listar todos os drives no sistema para garantir:

cat /proc/partitions

NOTA: Substitua /dev/sd{x} pelo dispositivo que você deseja limpar.

AVISO: Isto não é para amadores! Você poderia tornar seu sistema não inicializável !!!

sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > /dev/sd{x}

Estou surpreso com a rapidez com que isso acontece.

    
por 08.09.2015 / 21:27
2

Você provavelmente já tem o pacote GNU coreutils instalado em seu sistema. Ele fornece o comando shred .

    
por 07.08.2009 / 03:58
2

Você pode limpar seu espaço livre usando o pacote de exclusão segura.

Nesse pacote, você pode encontrar a ferramenta sfill , que foi projetada para excluir dados que estão no espaço disponível em mídias de maneira segura e que não podem ser recuperados por ladrões, autoridades ou outras ameaças.

Para instalar o pacote de exclusão segura no Linux (Ubuntu), instale-o com o seguinte comando:

$ sudo apt-get install secure-delete

Em seguida, para apagar seus dados sem espaço livre, tente o seguinte comando:

sfill -f -v -ll /YOUR_MOUNTPOINT/OR_DIRECTORY

Onde / YOUR_MOUNTPOINT / OR_DIRECTORY é o seu ponto de montagem ( df -h , mount ) ou diretório para limpar o espaço livre.

Leia o manual no link

    
por 04.07.2013 / 23:22
1

use dd e apenas zere o espaço livre. é um mito que os dados precisam ser escritos várias vezes (é só pedir peter guntmann) e dados aleatórios, ao contrário de 1 e, em seguida, 0 implica atividade antinatural. então o resultado final é uma unidade limpa com menos tempo gasto escrevendo. além disso, os programas de exclusão segura não garantem a substituição do arquivo real em sistemas de arquivos modernos (registrados em diário). faça um favor a si mesmo e obtenha o photorec, examine seu disco para ver a bagunça, limpe-o com 1s e, opcionalmente, com zeros para fazê-lo parecer intocado. Se o photorec ainda encontrar coisas, lembre-se de que está digitalizando tudo o que está disponível, então faça isso cuidadosamente novamente com o usuário root.

lembre-se, o cia / fbi / nsa não possui uma máquina sofisticada que possa ler o estado atual dos seus bits de mídia magnética. tudo isso foi apenas um artigo escrito há muito tempo. um "e se". você só precisa limpar 1 vez.

    
por 25.05.2013 / 22:40
1

É mais fácil usar o scrub :

scrub -X dump

Isso criará uma pasta dump no local atual e criará o arquivo até que o disco esteja cheio. Você pode escolher um padrão com a opção -p ( nnsa|dod|bsi|old|fastold|gutmann ).

Não é fácil instalar o scrub ( veja os Fóruns do Ubuntu neste ), mas uma vez que a instalação é pronto, você tem uma ferramenta realmente SIMPLES e eficiente na sua mão.

    
por 26.11.2011 / 04:38
1

Aqui está o script "sdelete.sh" que eu uso. Veja os comentários para detalhes.

# Install the secure-delete package (sfill command).

# To see progress type in new terminal:
# watch -n 1 df -hm

# Assuming that there is one partition (/dev/sda1). sfill writes to /.
# The second pass writes in current directory and synchronizes data.
# If you have a swap partition then disable it by editing /etc/fstab
# and use "sswap" or similar to wipe it out.

# Some filesystems such as ext4 reserve 5% of disk space
# for special use, for example for the /home directory.
# In such case sfill won't wipe out that free space. You
# can remove that reserved space with the tune2fs command.
# See http://superuser.com/a/150757
# and https://www.google.com/search?q=reserved+space+ext4+sfill

sudo tune2fs -m 0 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'

sudo sfill -vfllz /

# sfill with the -f (fast) option won't synchronize the data to
# make sure that all was actually written. Without the fast option
# it is way too slow, so doing another pass in some other way with
# synchronization. Unfortunately this does not seem to be perfect,
# as I've watched free space by running the "watch -n 1 df -hm"
# command and I could see that there was still some available space
# left (tested on a SSD drive).

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file

sudo tune2fs -m 5 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'
    
por 27.09.2015 / 20:29
1

Eu encontrei uma solução simples que funciona no Linux e no MacOS. Mova-se na pasta raiz do seu disco e inicie este comando:

for i in $(seq 1 //DISKSPACE//); do dd if=/dev/zero of=emptyfile${i} bs=1024 count=1048576; done; rm emptyfile*;

em que // DISKSPACE // é o tamanho em GB do seu disco rígido.

    
por 30.09.2015 / 11:27
0

Eu às vezes uso essa frase de efeito:

while :; do cat /dev/zero > zero.$RANDOM; done

Quando começar a dizer que o disco está cheio, basta pressionar Ctrl + C e remover os arquivos zero.* criados.

Funciona em qualquer sistema, independentemente dos limites de tamanho de arquivo.
Ignore os erros cat: write error: File too large .

    
por 30.07.2015 / 11:30
0

Esta não é uma resposta! Apenas um comentário para aqueles que desejam usar pv ... então não se preocupe em votar.

No Linux Mint 17.3 você pode usar pv ( exibição de tubos ) para obter o progresso da escrita. Por exemplo:

# Install pv (pipe view)
sudo apt-get install pv

# Write huge file of approximate size of /dev/sdb, using urandom data:
pv --timer --average-rate --progress --numeric --eta --interval 5 --size "$(blockdev --getsize64 /dev/sda )" /dev/urandom >rand.file

A vantagem aqui é que você obtém uma barra de progresso, ETA e taxa de dados continuamente atualizada. A desvantagem é que isso é escrito em uma linha e quando o disco está cheio (retornando um erro) ele desaparece. Isso acontece porque o tamanho total é aproximado, já que o sistema operacional provavelmente usará o disco enquanto essa operação muito longa estiver ocorrendo, especialmente no volume do sistema operacional.

Em um HD muito antigo, obtenho uma taxa de dados de 13 MB / s usando /dev/urandom e cerca de 70 MB / s ao usar /dev/zero . Isso provavelmente melhoraria ainda mais quando se usasse um dd ou cat em bruto, e não pv .

    
por 11.05.2016 / 18:59
-13

Quando o arquivo é retirado do registro do sistema de arquivos, os dados deixados no disco rígido são sequências sem sentido de 1 e 0. Se você quiser substituir essa sequência sem sentido por outra sequência sem sentido, posso aconselhar alguns produtos comerciais para apagar unidades com segurança, como o arconis.

    
por 07.08.2009 / 01:59