Como limpar espaço livre em disco no Linux?

Aviso: O hardware moderno do disco/SSD e os sistemas de ficheiros modernos podem desviar os dados em locais onde não é possível apagá-los, pelo que este processo pode ainda deixar dados no disco. As únicas formas seguras de apagar dados são o comando ATA Secure Erase (se implementado correctamente), ou a destruição física. Veja também Como posso apagar de forma fiável todas as informações num disco rígido?

Pode utilizar um conjunto de ferramentas chamado secure-delete.

sudo apt-get install secure-delete

Este tem quatro ferramentas:

srm - apagar de forma segura um ficheiro existente smem - apagar de forma segura vestígios de um ficheiro da ram sfill - limpar todo o espaço marcado como vazio no seu disco rígido sswap - limpar todos os dados do seu espaço de troca.

A partir da página de manual de srm

srm foi concebido para apagar dados em suportes de forma segura que não possam ser recuperados por ladrões, agentes da lei ou outras ameaças. O algoritmo de limpeza é baseado no papel “Secure Deletion of Data from Magnetic and Solid-State Memory” apresentado no 6º Simpósio de Segurança da Usenix por Peter Gutmann, um dos principais criptógrafos civis.

O processo seguro de eliminação de dados da 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.
• Renomear o ficheiro para um valor aleatório
• Truncar o ficheiro

Como medida adicional de segurança, o ficheiro é aberto no modo O_SYNC e após cada passe é feita uma chamada fsync(). srm escreve 32k blocos com o propósito de velocidade, preenchendo buffers de caches de disco para forçá-los a descarregar e escrever por cima de dados antigos que pertenciam ao ficheiro.

A forma mais rápida, se precisar apenas de um único passe e quiser apenas substituir tudo por zeros, é:

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

(correr a partir de um directório no sistema de ficheiros que pretende apagar) (o comando sync é uma medida de paranóia que assegura que todos os dados são gravados no disco - um gestor de cache inteligente pode funcionar de forma a cancelar as gravações para qualquer bloco pendente quando o ficheiro estiver desvinculado)

Haverá um tempo durante esta operação em que não haverá espaço livre no sistema de ficheiros, que pode ser de dezenas de segundos se o ficheiro resultante for grande e fragmentado, pelo que demora algum tempo a apagar. Para reduzir o tempo quando 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

Isto deve ser suficiente para impedir alguém de ler o conteúdo do ficheiro antigo sem uma dispendiosa operação forense. Para uma variante um pouco mais segura, mas mais lenta, substitua /dev/zero por /dev/urandom. Para mais paranóia corra vários passos com /dev/urandom, embora se 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 acima indicado o ficheiro pequeno é desfiado antes de criar o maior, pelo que pode ser removido assim que o maior estiver completo em vez de ter de esperar que seja desfiado deixando o sistema de ficheiros com espaço livre zero durante o tempo que demorar. O processo de trituração com demora long tempo sobre um ficheiro grande e a menos que esteja a tentar esconder algo da NSA não é realmente necessário IMO.

Todos os anteriores devem funcionar em qualquer sistema de ficheiros.

** Limites de tamanho de ficheiro:**

Como a DanMoulding salienta num comentário abaixo, isto pode ter problemas com limis de tamanho de ficheiro em alguns sistemas de ficheiros.

Para FAT32 seria definidamente uma preocupação devido ao limite de ficheiro 2GiB: a maioria dos volumes são maiores do que este actualmente (8TiB é o limite de volume IIRC). Pode contornar esta situação, canalizando a saída dos grandes cat /dev/zero através dos split para gerar múltiplos ficheiros mais pequenos e ajustar as fases de fragmentação e eliminação em conformidade.

Com ext2/3/4 é menos preocupante: com o bloco padrão/comum de 4K o limite do tamanho do ficheiro é de 2TiB, pelo que teria de ter um volume de huge para que isto fosse um problema (o tamanho máximo do volume nestas condições é de 16TiB).

Com os btrfs (ainda experimentais) tanto o tamanho máximo do ficheiro como o volume são um enorme 16EiB.

Sob NTFS o comprimento máximo do ficheiro é maior do que o comprimento máximo do volume em alguns casos até.

Pontos de partida para mais informações: http://en.wikipedia.org/wiki/Ext3#Size_limites http://en.wikipedia.org/wiki/Btrfs http://en.wikipedia.org/wiki/Ntfs#Scalability

** Dispositivos Virtuais**

Como mencionado nos comentários recentes, existem considerações adicionais para dispositivos virtuais:

• Para discos virtuais pouco utilizados, outros métodos como os utilizados por zerofree serão mais rápidos (embora ao contrário de cat e dd, esta não é uma ferramenta padrão que se pode confiar em estar disponível em praticamente qualquer sistema operativo unix-a-like).

• Tenha em atenção que a zeragem de um bloco num dispositivo virtual esparso pode não limpar o bloco no dispositivo físico subjacente, na verdade eu diria até que é improvável que o faça - o gestor do disco virtual apenas fará com que o bloco deixe de ser utilizado para que possa ser atribuído a outra coisa mais tarde.

• Mesmo para dispositivos virtuais de tamanho fixo, pode não ter qualquer controlo sobre a localização física do dispositivo para que este possa ser movido em torno da sua localização actual ou para um novo conjunto de discos físicos em qualquer altura e o máximo que pode limpar é a localização actual e não quaisquer localizações anteriores que o bloco possa ter residido no passado.

• Para os problemas acima referidos em dispositivos virtuais: a menos que controle o(s) anfitrião(s) e possa fazer uma limpeza segura do seu espaço não alocado depois de limpar os discos no VM ou movimentar o dispositivo virtual, não há nada que possa fazer a este respeito depois do facto. O único recurso é utilizar a encriptação completa do disco desde o início, pelo que nada que não esteja encriptado é tudo o que está escrito no suporte físico em primeiro lugar. Pode ainda haver a necessidade de uma limpeza de espaço livre dentro do VM, claro. Note também que o FDE pode tornar os dispositivos virtuais esparsos muito menos úteis, uma vez que a camada de virtualização não consegue realmente ver quais os blocos que não são utilizados. Se a camada de sistema de ficheiros do sistema operativo enviar comandos de aparar para o dispositivo virtual (como se fosse um SSD), e o controlador virtual os interpretar, isso pode resolver o problema, mas não conheço nenhuma circunstância em que isso aconteça e uma discussão mais alargada sobre isso é um assunto para outro lado (já estamos perto de estar fora do tópico para a pergunta original, por isso, se isto despertou o seu interesse, algumas questões experimentais e/ou de seguimento podem estar em ordem).

Fiquei chocado com a quantidade de ficheiros photorec que consegui recuperar do meu disco, mesmo depois de limpar.

Se há mais segurança em preencher o “espaço livre” apenas 1 vez com 0x00 ou 38 vezes com padrões cabalísticos diferentes é mais uma discussão académica. O autor do artigo seminal de 1996 sobre trituração escreveu ele próprio um epílogo dizendo que isto é obsoleto e desnecessário para o hardware moderno. Não há nenhum caso documentado de substituição física de zeros e recuperação posterior de dados.

A verdadeira fragile link* neste procedimento é o filesystem. Alguns sistemas de ficheiros reservam espaço para utilização especial e não é disponibilizado como “espaço livre”. *Mas os seus dados podem estar lá. Isso inclui fotos, e-mails pessoais em texto simples, o que quer que seja. Acabei de pesquisar no Google o espaço reservado+espaço+ext4 e soube que 5% da minha partição home foi reservada. Acho que foi aqui que a photorec encontrou tanto do meu material. 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.

Pode tentar o # tune2fs -m 0 /dev/sdn0 antes de o montar. (Se esta será a partição raiz após reiniciar, certifique-se que corre o -m 5 ou o -m 1 depois de o desmontar).

Mas mesmo assim, de uma forma ou de outra, pode sobrar algum espaço.

A única forma verdadeiramente segura é limpar toda a partição, criar novamente um sistema de ficheiros e depois restaurar os seus ficheiros a partir de uma cópia de segurança.

Modo rápido (recomendado)

Execute a partir de um directório no sistema de ficheiros que pretende 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

_Notações: o objectivo do pequeno ficheiro é reduzir o tempo quando o espaço livre é completamente zero; o objectivo da sincronização é garantir que os dados são realmente escritos.

Isto deve ser suficientemente bom para a maioria das pessoas.

Modo pouco (paranóico)

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

No entanto, se tem razões para pensar que as agências secretas gastariam muitos recursos para recuperar os seus ficheiros, isto deve ser 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 escolheu a forma paranóica, depois disto ainda vai querer 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 realmente dados encriptados. Pode morrer sob tortura por não revelar a chave de decifração.

Muito lento (paranóia louca)

Até o autor do artigo seminal de 1996 sobre trituração escreveu um epílogo dizendo que isto é obsoleto e desnecessário para o hardware moderno.

Mas se ainda tem muito tempo livre e não se importa de desperdiçar o seu disco com muita sobrescrita, aí 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

Note: isto é essencialmente equivalente a usar a ferramenta secure-delete.

• *

Antes da edição, este post foi uma reescrita do David Spillett. O comando “cat” produz uma mensagem de erro, mas eu não posso escrever comentários sobre as mensagens de outras pessoas.

Existe utilidade 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.

Verifique também este link sobre zerofree: Mantendo imagens esparsas do sistema de ficheiros - é do seu autor - Ron Yorston (9 de Agosto de 2012)

Limpe um drive à velocidade máxima.

As instruções típicas para encriptar um drive hoje em dia dir-lhe-ão para primeiro WIPE o drive.

O comando abaixo irá preencher o seu drive com AES ciphertext.

Utilize um CD ao vivo se precisar de limpar o seu drive de arranque principal.

Abra um terminal e eleve os seus privilégios:

sudo bash

Deixe-nos listar todas as drives do sistema para ser seguro:

cat /proc/partitions

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

AVISO: Isto não é para amadores! Pode tornar o seu sistema inutilizá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 atordoado com a rapidez com que isto é feito.

Eu uso o dd para atribuir um ou mais ficheiros grandes para preencher o espaço livre, depois uso um utilitário de eliminação seguro.

Para atribuir ficheiros com dd tente:

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

Isto irá gerar um ficheiro chamado delete_me que tem 100 MB de tamanho. (Aqui bs é o “tamanho do bloco” definido para 1k, e count é o número de blocos a alocar.)

Depois use o seu utilitário de eliminação seguro favorito (tenho usado shred ) nos ficheiros assim criados.

But NOTE THIS: buffering significa que mesmo que você faça o whole disk, você pode não obter absolutamente tudo!

Este link recomenda scrub para limpeza de espaço livre. Ainda não o experimentei.

Pode limpar o seu espaço livre utilizando um pacote de eliminação seguro.

Nesse pacote pode encontrar a ferramenta sfill, que foi concebida para eliminar dados que se encontram no espaço em disco disponível em suportes de forma segura e que não podem ser recuperados por ladrões, agentes da lei ou outras ameaças.

Para instalar o pacote de eliminação segura no Linux (Ubuntu), instale-o através do seguinte comando:

$ sudo apt-get install secure-delete

Depois para erase os 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 directório para limpar o espaço livre.

Leia o manual em http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1 .html

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

Mais fácil é utilizar scrub :

scrub -X dump

Isto irá criar uma pasta dump na localização actual e criar um ficheiro até o disco estar cheio. Pode escolher um padrão com a opção -p (nnsa|dod|bsi|old|fastold|gutmann).

Não é fácil instalar o scrub ver os Fóruns Ubuntu neste ), mas uma vez feita a instalação, tem uma ferramenta realmente SIMPLES e eficiente na sua mão.

Aqui está o guião “sdelete.sh” que eu uso. Ver comentários para mais 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'

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.

é um mito os dados precisam ser escritos várias vezes (basta perguntar ao peter guntmann) e dados aleatórios , ao contrário de 1’s e depois 0’s implica uma actividade não natural. depois o resultado final é um disco limpo com muito menos tempo de escrita. além disso, programas de apagamento seguros não podem garantir que eles até sobregravam o ficheiro real em sistemas de ficheiros modernos (registados). faça um favor a si próprio e obtenha o photorec, digitalize a sua unidade para ver a confusão, limpe-a com 1’s e opcionalmente com zeros para a fazer parecer intocada. se o photorec ainda encontrar coisas, lembre-se que está a digitalizar tudo o que está disponível, por isso faça isto cuidadosamente novamente com o utilizador root.

lembre-se, o cia/fbi/nsa não tem uma máquina chique que consiga ler o estado real dos seus pedaços de suportes magnéticos. tudo isto foi apenas um papel escrito há muito tempo. um “what-if”. só precisa de limpar 1 vez.

Isto não é uma resposta!_ Apenas um comentário para aqueles que desejam usar pv…por isso não se incomode a votar.

Em Linux Mint 17.3* 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 uma taxa de dados continuamente actualizada. A desvantagem é que esta é escrita numa linha e quando o disco está cheio (devolvendo um erro) desaparece. Isto acontece porque o tamanho total é aproximado, uma vez que o SO irá provavelmente utilizar o disco durante esta operação muito longa, especialmente no volume do SO.

Num HD muito antigo, obtenho uma taxa de dados de cerca de 13 MB/s* utilizando /dev/urandom, e cerca de 70 MB/s* , quando utilizo /dev/zero. Isto provavelmente melhoraria ainda mais quando se utiliza um dd ou cat em bruto, e não pv.

Por vezes utilizo este bash one-liner:

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

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

Funciona em qualquer sistema, independentemente dos limites de tamanho do ficheiro. Ignorar quaisquer erros cat: write error: File too large.

Uma vez que o ficheiro tenha saído do registo do sistema de ficheiros, os dados que são deixados no disco rígido são sequências sem sentido de 1’s e 0’s. Se pretende substituir essa sequência sem sentido por outra sequência sem sentido, posso aconselhar alguns produtos comerciais para apagar unidades em segurança, como os arconis.