Então, resumindo a história, eu tenho alguns, er,confidencialdados que gostaria de proteger de pessoas que tentam bisbilhotar. Digamos que esteja em uma pasta na minha área de trabalho chamada My Secrets.
No entanto, eu gostaria de manter algum tipo de método para destruir esses dados para torná-los irrecuperáveis, de tal forma que seja impossível recuperá-los e que não haja nenhuma prova de que esses dados existissem.
Eu gostaria de poder preservar minha instalação do Ubuntu e todos/todos os dados não confidenciais, então uma bomba nuclear completa (infelizmente) não é uma opção.
Como posso conseguir isso no Ubuntu?
Idealmente, eu também gostaria de poder acionar essa exclusão com a queda de um alfinete, a partir do qual não há como impedir a destruição (pelo menos parcial) dos meus dados. Também estou disposto a usar uma solução que exija configuração (para, digamos, quaisquer dados futuros que precisem de armazenamento).
Responder1
shreddo GNU coreutilsfoi projetado especificamente para esse propósito.
De man shred:
Substitua o(s) ARQUIVO(s) especificado(s) repetidamente, para dificultar a recuperação dos dados, até mesmo para testes de hardware muito caros.
shredna verdade, lê bytes aleatórios /dev/urandome substitui o conteúdo dos arquivos por eles; no final, opcionalmente, substitui o conteúdo por zeros (de /dev/zero). Então se você quiser reinventar a roda, você pode fazer isso manualmente, mas é melhor usar shredo que já está otimizado para a tarefa.
Por exemplo, para qualquer arquivo my_secured_file.txt, você pode fazer:
shred my_secured_file.txt
Aqui:
-vpor verbosidade-zpara substituir o arquivo com zeros posteriormente, para ocultar a destruição-n 5é para o número de iterações, o padrão é 3
Você pode aumentar o número de iterações se quiser embora o padrão seja suficiente ou até mesmo remover o arquivo ( -u, --remove).
Verificar man shred.
As shredopera em arquivos, para fazer a operação em todos os arquivos de um diretório (recursivamente), por exemplo my_secret_dir:
shopt -s globstar
for f in my_secret_dir/**/*; do shred -vzn 5 -- "$f"; done
Ou find:
find my_secret_dir -type f -exec shred -vzn 5 -- {} +
Observação:
shredtem a ressalva de que não pode funcionar corretamente em sistemas de registro em diário, cache, RAID e arquivos compactados. Citando man shred:
CUIDADO: Observe que o fragmento depende de uma suposição muito importante: que o sistema de arquivos sobrescreve os dados no local. Essa é a maneira tradicional de fazer as coisas, mas muitos projetos modernos de sistemas de arquivos não atendem a essa suposição. A seguir estão exemplos de sistemas de arquivos nos quais o fragmento não é eficaz ou não tem garantia de eficácia em todos os modos do sistema de arquivos:
sistemas de arquivos estruturados em log ou registrados em diário, como aqueles fornecidos com AIX e Solaris (e JFS, ReiserFS, XFS, Ext3, etc.)
sistemas de arquivos que gravam dados redundantes e continuam mesmo se algumas gravações falharem, como sistemas de arquivos baseados em RAID
sistemas de arquivos que fazem instantâneos, como o servidor NFS do Network Appliance
sistemas de arquivos que armazenam cache em locais temporários, como clientes NFS versão 3
sistemas de arquivos compactados
No caso de sistemas de arquivos ext3, a isenção de responsabilidade acima se aplica (e o fragmento é, portanto, de eficácia limitada) apenas no modo data=journal, no qual os diários arquivam dados além de apenas metadados. Nos modos data=ordered (padrão) e data=writeback, o fragmento funciona normalmente. Os modos de registro em diário Ext3 podem ser alterados adicionando a opção data=something às opções de montagem para um sistema de arquivos específico no arquivo /etc/fstab, conforme documentado na página man mount (man mount).
Além disso, os backups do sistema de arquivos e os espelhos remotos podem conter cópias do arquivo que não podem ser removidas e que permitirão que um arquivo fragmentado seja recuperado posteriormente.
No Ubuntu, se você estiver usando ext4um sistema de arquivos que também é um sistema de arquivos com registro em diário, o modo de diário é o padrão para metadados, não para dados ( data=orderedé o padrão), portanto você deve obter o resultado esperado com shred-ing, a menos que altere o padrão.
Como observação lateral, você pode encontrar as opções padrão do sistema de arquivos:
sudo dumpe2fs -h /partition |& grep 'Filesystem features'
Exemplo:
% sudo dumpe2fs -h /dev/sda3 |& grep 'Filesystem features'
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
O has_journalindica que este é um FS de registro no diário e as opções de diário padrão são:
% sudo dumpe2fs -h /dev/sda3 |& grep 'Journal features'
Journal features: journal_incompat_revoke
Ambos ao mesmo tempo:
% sudo dumpe2fs -h /dev/sda3 |& grep 'features'
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Journal features: journal_incompat_revoke
Responder2
Aqui está uma sugestão improvisada: armazene os dados confidenciaisapenasem um armazenamento em nuvem criptografado e bloqueado por senha, comnenhuma pasta de atalhono seu computador (ou seja, não instale o Dropbox ou similar, que cria um espelho local do armazenamento remoto) - apenas um marcador no seu navegador. Quando você quiser remover evidências de dados confidenciais em seu sistema local, exclua o marcador e limpe o histórico do navegador (ou, idealmente, use uma variante ou configuração de navegador de alta segurança que limpe automaticamente o histórico sempre que você fechá-lo). Dez segundos ou mais, e ninguém saberá por onde começar a procurar, a não ser uma pesquisa completa do sistema em nível forense (extremamente improvável, a menos que você seja um espião internacional ou traficante de pornografia infantil).