it-swarm-pt.tech

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

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?

141
Alex B

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

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

Sudo apt-get install secure-delete

Isto tem quatro ferramentas:

srm - apaga com segurança um arquivo existente
smem - exclui com segurança os traços de um arquivo do ram
sfill - limpe todo o espaço marcado como vazio no seu disco rígido
sswap - limpe todos os dados do seu espaço de swap.

Da página do manual de srm

o srm é projetado para excluir dados de mídias de maneira segura, que não podem ser recuperadas por ladrões, autoridades ou outras ameaças. O algoritmo de limpeza baseia-se no documento "Exclusão segura de dados de memória magnética e de estado sólido", apresentado no sexto Simpósio de Segurança Usenix, de Peter Gutmann, um dos principais criptógrafos civis.

O processo seguro de exclusão de dados do srm é assim:

  • 1 passe com 0xff
  • 5 passes aleatórios. /dev/urandom é usado para um RNG seguro, se disponível.
  • 27 passes com valores especiais definidos por Peter Gutmann.
  • 5 passes aleatórios. /dev/urandom é usado para um RNG seguro, se disponível.
  • Renomeie o arquivo para um valor aleatório
  • Truncar o arquivo

Como uma medida adicional de segurança, o arquivo é aberto no modo O_SYNC e após cada passagem uma chamada fsync() é feita. srm escreve 32k blocos para fins de velocidade, preenchendo buffers de caches de disco para forçá-los a limpar e sobrescrever dados antigos que pertenciam ao arquivo.

105
fnord_ix

A maneira mais rápida, se você precisa apenas de uma única passagem e quer 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 paranóia que garante que todos os dados sejam gravados no disco - um gerenciador de cache inteligente pode descobrir que pode cancelar gravações de 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, o que leva um tempo 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árias etapas com /dev/urandom, mas se você precisar de muito 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 pelo tempo que leva. O processo shred com um long tempo em um arquivo grande e a menos que você esteja tentando esconder algo do NSA não é realmente necessário IMO.

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

Limites de tamanho do 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 FAT32, definitivamente seria uma preocupação devido ao limite de arquivo de 2GiB: a maioria dos volumes é maior que isso atualmente (8TiB é o limite de tamanho de volume IIRC). Você pode contornar isso canalizando a saída de saída grande cat /dev/zero 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 é 2TiB, então você teria que ter um volume enorme para que isto seja um problema (o tamanho máximo do volume sob estas condições é 16TiB).

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

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:
http://en.wikipedia.org/wiki/Ext3#Size_limits
http://en.wikipedia.org/wiki/Btrfs
http://en.wikipedia.org/wiki/Ntfs#Scalability

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 que você pode confiar em estar disponível em praticamente 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 physical subjacente, na verdade eu diria que é improvável que - o gerenciador de disco virtual faça o bloco não é mais usado, então pode 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 é o local atual, não qualquer local anterior que o bloco possa ter residido no passado.

  • Para os problemas acima em dispositivos virtuais: a menos que você controle o Host (s) e possa limpar o espaço não alocado depois de limpar os discos no 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 completa do disco desde o início, portanto, nada descriptografado é todo gravado na mídia física. 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 não estão sendo usados. 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 aconteça e discussão sobre isso é uma questão para outros lugares (já estamos chegando perto de estar fora do tópico para a questão original, portanto, se isso despertou seu interesse, algumas questões de experimentação e/ou de acompanhamento podem estar em ordem).

69
David Spillett

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 trituração 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 fragile link neste procedimento é o filesystem . 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 partição home estava reservada. Eu acho que isso é onde photorec encontrou muito das minhas coisas. Conclusão: o método de trituraçã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 após desmontá-la).

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

A única maneira verdadeiramente 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)

Executar 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

Observações: o objetivo do arquivo pequeno é reduzir o tempo em que o espaço livre é completamente zero; o objetivo 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.

Muito lento (louco paranóico)

Até mesmo o autor do seminal paper de 1996 sobre trituração 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 em desperdiçar 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.

44
user39559

Há utilitário zerofree pelo menos no Ubuntu:

http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html

   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: Manter as imagens do sistema de arquivos esparsas - é de seu autor - Ron Yorston (09 de agosto de 2012)

27
osgx

Veja como fazer isso com uma GUI.

  1. Instalar 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 eles sejam a mesma partição, nesse caso, escolha um.
  4. Marque a caixa System - Wipe Free Disk Space.
  5. Clique em Excluir.

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

3
Andrew Z

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

Nesse pacote você pode encontrar a ferramenta sfill, que é 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 pelo seguinte comando:

$ Sudo apt-get install secure-delete

Então para apagar seus dados não têm 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 em http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1.html

2
kenorb

Limpe uma unidade na velocidade máxima.

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 todas as unidades no sistema para serem seguras:

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 chocado com a rapidez com que isso é.

2
Roger Lawhorn

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 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 (eu tenho usado shred ) nos arquivos assim criados.

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


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

2
dmckee

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

2
dkaylor

Mais fácil é usar 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 obter o scrub instalado ( veja os Fóruns do Ubuntu neste ), mas assim que a instalação estiver concluída, você terá uma ferramenta realmente SIMPLES e eficiente na sua mão.

1
FMaz008

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*;

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

1
Enrico

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.

1
fred

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'
1
Czarek Tomczak

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

Em Linux Mint 17.3 você pode usar pv ( pipe view ) 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, recebo uma taxa de dados sobre 13 MB/s usando /dev/urandom e sobre 70 MB/s , ao usar /dev/zero. Isso provavelmente melhoraria ainda mais quando se usasse uma dd ou cat bruta, e não pv.

0
not2qubit

Eu às vezes uso este one-liner bash:

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

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

Ele funciona em qualquer sistema, independentemente dos limites de tamanho de arquivo.
Ignore qualquer erro cat: write error: File too large.

0
Nicolas Raoul