Maneira rápida de randomizar HD?

14

Eu li sobre como tornar os discos rígidos seguros para criptografia, e uma das etapas é gravar bits aleatórios na unidade, a fim de tornar os dados criptografados indistinguíveis dos demais dados no disco rígido.

No entanto, quando tentei usar dd if=/dev/urandom of=/dev/sdano passado, o ETA estava na ordem dos dias. Eu vi algo sobre o uso badblocksno lugar do urandom, mas isso não pareceu ajudar muito. Gostaria apenas de saber se existem maneiras que possam me ajudar a acelerar isso, como opções para ddou algo mais que possa estar faltando, ou se a velocidade é apenas uma limitação do HD.

bitflips
fonte
Altere o tamanho do bloco para algo mais amigável em relação aos discos rígidos. dd bs=1Mpor exemplo.
12133 Patrick
Que velocidade você estava recebendo? Demora um tempo para gravar um disco rígido inteiro de 3 TB (por exemplo). Verifique também iostat -kx 10o percentual ocupado na unidade.
derobert
5
shred -v -n 1 /dev/overwritethisé rápido. É o único caso em que shredé realmente útil para alguma coisa.
Frostschutz
@derobert: Não sei dizer com certeza o quão rápido foi, mas saí por algumas horas, voltei e estava cerca de 10% completo para o meu HD interno de 500G na primeira vez que tentei isso. Obrigado pela "iostat" ponta btw
bitflips
@ Patrick: Eu tentei cs = 4M meio que às cegas, pois vi isso no guia de como colocar o CD do Arch em um usb. Ajudou um pouco, mas ainda era bem lento.
bitflips

Respostas:

14

dd if=/dev/urandom of=/dev/sda, ou simplesmente cat /dev/urandom >/dev/sda , não é a maneira mais rápida de preencher um disco com dados aleatórios. O Linux /dev/urandomnão é o RNG criptográfico mais rápido do mercado. Existe uma alternativa para / dev / urandom? tem algumas sugestões. Em particular, o OpenSSL contém um PRNG criptográfico mais rápido:

openssl rand $(</proc/partitions awk '$4=="sda" {print $3*1024}') >/dev/sda

Observe que, no final, se há uma melhoria ou não, depende de qual parte é o gargalo: a CPU ou o disco.

A boa notícia é que o preenchimento do disco com dados aleatórios é praticamente inútil. Primeiro, para dissipar um mito comum, limpar com zeros é tão bom quanto o hardware atual . Com a tecnologia de disco rígido da década de 1980, a substituição de um disco rígido com zeros deixou uma pequena carga residual que poderia ser recuperada com um hardware um pouco caro; foram necessárias várias passagens de substituição com dados aleatórios (a “limpeza de Gutmann”). Hoje, mesmo uma única passagem de substituição com zeros deixa dados que não podem ser recuperados realisticamente, mesmo em condições de laboratório.

Ao criptografar uma partição, o preenchimento do disco com dados aleatórios não é necessário para a confidencialidade dos dados criptografados. Só é útil se você precisar tornar o espaço usado pelos dados criptografados indistinguíveis do espaço não utilizado. Construir um volume criptografado em cima de um contêiner não aleatório revela quais blocos de disco já foram usados ​​pelo volume criptografado. Isso fornece uma boa dica sobre o tamanho máximo do sistema de arquivos (embora, com o tempo, ele se torne uma aproximação cada vez pior) e pouco mais.

Gilles 'SO- parar de ser mau'
fonte
4
Gutmann é um mito na sua totalidade, acho que também nunca foi feito para um disco rígido dos anos 80. A ironia é que, com as unidades ficando mais inteligentes, você realmente deve usar dados aleatórios hoje em dia para garantir que a unidade seja forçada a gravar, em vez de setor livre (aparar) ou compactar dados. Os zeros são bons apenas se forem realmente escritos.
Frostschutz
1
@mellowmaroon Sim, cat /dev/zeroquase sempre é suficiente. Isso não é suficiente se você deseja ocultar a quantidade de espaço livre no volume criptografado.
Gilles 'SO- stop be evil' -
1
@mellowmaroon É praticamente inútil. Um bisbilhoteiro saberá que você tem no máximo X MB de dados (e possivelmente muito menos, porque o espaço usado anteriormente, mas agora livre é indistinguível do espaço usado), e daí? Além disso, a localização do espaço livre pode revelar o tipo de sistema de arquivos (cópias de superbloco); isso raramente é uma preocupação (normalmente é exposta no texto /etc/fstabnão criptografado , a menos que você tenha criptografado a partição raiz e mesmo assim não haja um número tão grande de opções plausíveis).
Gilles 'SO- stop be evil'
2
@ Gilles O problema que encontrei no Ubuntu 13.10 é que openssl randparece ter um limite superior no número de bytes que ele gerará. Se você exceder esse limite, por exemplo, 'openssl rand 810000000000 , then no random output is generated. Only a brief "help" text is printed. I'm trying to random (pretty much) fill a 3TB hard drive. Not sure if there is a way to get openssl` para produzir tantos bytes aleatórios.
irracional John
1
Para o problema irracional do limite superior de John, 810 bilhões de bytes chegam a cerca de 754 GB. Que tal particionar seu disco em várias partições de 700 GB e, em seguida, executar o openssl randcomando em cada partição em sentido inverso a partir do sda5 ou qualquer outra coisa e trabalhar de volta para sda1 e finalmente sda?
jia103
6

O openssl não parecia funcionar para mim. Recebi "opções desconhecidas" e outros problemas com as soluções fornecidas. Então eu acabei indo com o programa fio.

fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0

O que parece levar 3 horas para fazer 19 TB em 24 HDDs. Então, aproximadamente 1.800 MB / s

smp-016:~ # fdisk -l /dev/md0
Disk /dev/md0: 18890.1 GB, 18890060464128 bytes

smp-016:~ # fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0
fill: (g=0): rw=write, bs=512M-512M/512M-512M/512M-512M, ioengine=libaio, iodepth=4
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [2.7% done] [0KB/1536MB/0KB /s] [0/3/0 iops] [eta 03h:01m:11s]

Espero que esses dados sejam realmente aleatórios. A página do manual diz "Padrão: preencha buffers com dados aleatórios." http://linux.die.net/man/1/fio

Não estou fazendo isso para fins de segurança / criptografia, apenas tentando garantir que meus testes de leitura posteriores sejam dados reais e não apenas zeros. Esse mesmo comando pode ser usado para o pré-condicionamento SSD / NVMe. Como o simples uso de / dev / zero pode levar à compactação no nível do disco "trapaça" quanto está realmente escrito. Embora eu adicione um -loops=2sinalizador a ele, se for um SSD novo para benchmarking.

Se você quisesse que ele fosse seguro, poderá usar a -randrepeat=bool opção, pois isso alternará "Semear o gerador de números aleatórios de maneira previsível, para que os resultados sejam repetíveis entre as execuções. Padrão: true.", Mas ainda não estou certo como isso seria seguro.

Além disso, alguns HDDs de classe empresarial existentes no mercado são SED (unidades de criptografia automática) e permitem que você gire a chave de criptografia para apagar instantaneamente e com segurança todos os dados gravados.

Por fim, no passado, usei o DBAN (também conhecido como Darik's Boot and Nuke), que possui opções de inicialização por CD e USB e "é um projeto de código aberto hospedado no SourceForge. O programa foi projetado para apagar com segurança um disco rígido até que seus dados sejam permanentemente removido e não mais recuperável "

TaylorSanchez
fonte
1
O tamanho = 100% não funcionou para mim, mas fill_device = 1 (ou fill_fs = 1) funcionou.
precisa saber é o seguinte
Eu acho que isso seria dependente se você desse a ele um dispositivo de nível de bloco ou um sistema de arquivos para preencher. Com o dispositivo no nível do bloco, ele sabe o tamanho e o tamanho é uma porcentagem do tamanho do dispositivo. Onde como o fill_device vai até obter um erro total do dispositivo. Eu acho que o sinalizador fill_device pode não substituir nenhum arquivo, apenas espaço não utilizado. Eu não testei isso, pois normalmente evito os sistemas de arquivos, a menos que seja necessário quando faço o teste do dispositivo.
TaylorSanchez
6

Você pode fazer o OpenSSL criptografar /dev/zerocom uma senha aleatória, fornecendo dados pseudo-aleatórios decentes muito rapidamente (se sua CPU suportar acelerá-los).

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

Você pode canalizar isso pvpara obter progresso / ETA. Os comandos que estou executando agora (em um shell raiz) são:

DISK="sda"
DISKSIZE=$(</proc/partitions awk '$4=="'"$DISK"'" {print sprintf("%.0f",$3*1024)}')
apt-get install pv
openssl enc -aes-256-ctr -nosalt \
  -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
  < /dev/zero |
  pv --progress --eta --rate --bytes --size "$DISKSIZE" |
  dd of=/dev/"$DISK" bs=2M

Tive essa idéia com essa resposta , depois de ter o mesmo problema que John irracional , que comentou a resposta de Gilles acima. Isso aumentou minha velocidade de limpeza para minha nova matriz RAID de 11 MB / s para cerca de 300 MB / s, levando o que levaria uma semana para 10 horas.

Acrescentarei que você deve poder usar, em vez da declaração mais complicada acima, mas há um erro que permitirá produzir apenas 16 MB de saída. (Este bug foi arquivado, janeiro de 2016.)openssl rand #of_bytesopenssl enc ...ssl

E, de acordo com a resposta a esta pergunta , e continuando a supor que a CPU é o gargalo, pode ser possível aumentar ainda mais a velocidade executando vários opensslprocessos paralelos em núcleos separados, combinando-os usando um FIFO.

tremer
fonte
Não tenho certeza se a edição foi necessária. Outras respostas a esta pergunta sugerem openssl rand.
tremby
2
Referência: dd if=/dev/urandom18MiB / s openssl enc,: ~ 180MiB / s fio,: 169MiB / s, openssl randsem suporte> 754GB. Note que se você também quiser cálculo auto-size, usar: openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt </dev/zero | pv --progress --eta --rate --bytes --size $(</proc/partitions awk '$4=="sda" {print sprintf("%.0f",$3*1024)}') | dd of=/dev/sda bs=2M. Cuidado, sdaestá presente duas vezes neste comando.
KrisWebDev
0

Completando a resposta de Marco, você precisa de um gerador de números aleatórios mais rápido.

Você usa um programa simples que reproduz números aleatórios de uma boa biblioteca boost::randome usa esse dd.

Se você escolher aumentar, poderá usar este exemplo, alterando a experimentfunção de acordo com suas necessidades.

RSFalcon7
fonte
Quanto mais rápida é a solução de reforço no seu sistema? Uma referência rápida e não científica na minha máquina produz exatamente a mesma velocidade que /dev/urandom.
12133 Marco
boost::randomnão oferece um RNG de criptografia, oferece? Se você usar um RNG sem criptografia, poderá usar zeros: pelo menos não terá uma ilusão de segurança.
Gilles 'SO- stop be evil' -
Eu não posso ser específico sobre o quão rápido os boost::randomgeradores são, a única maneira de saber com certeza é medir o algoritmo mais rápido deles/dev/urandom
delas #
0

O gargalo se não o tamanho do bloco nem o disco rígido, mas a lenta geração de números pseudo-aleatórios. /dev/urandomé por magnitudes mais rápidas em comparação com o /dev/randomfato de não estar bloqueando um pool de baixa entropia.

Você pode confirmar isso medindo a saída bruta de seus números pseudo-aleatórios:

pv /dev/urandom >/dev/null

Essa taxa será muito mais lenta que a taxa de gravação do seu disco rígido. Uma solução correta depende totalmente do seu nível de segurança necessário. Se você precisar de alta segurança, use um gerador aleatório de hardware rápido ou aceite a velocidade lenta. Se suas necessidades de segurança não forem tão altas, você poderá capturar algumas dezenas de MiB de dados e gravar essa sequência repetidamente na unidade. Ou talvez até escrever zeros de /dev/zeroseja uma opção.

Sumário

/dev/random - seguro, muito lento
/dev/urandom- menos seguro¹,
hardware lento RNG - seguro, rápido, muito caro
( /dev/zero - nada aleatório, muito rápido)

¹ De acordo com um rand de / dev / urandom é seguro para uma chave de login? /dev/urandomé tão seguro quanto /dev/random. Obrigado a Gilles por apontar isso.

Marco
fonte
Ele já está usando urandom.
Patrick
De fato. Meu argumento é que mesmo o urandom é muito lento para as necessidades dele, por isso ele precisa de uma solução diferente da urandom.
Marco
@ Gilles Obrigado pelo link. A página de manual afirma claramente: … Como resultado, se não houver entropia suficiente no pool de entropia, os valores retornados são teoricamente vulneráveis ​​a um ataque criptográfico… Por isso, classifiquei-o como menos seguro.
Marco
0

Eu estava tentando preencher um HDD USB externo de 4 TB com dd if=/dev/urandom of=/dev/sdX status=progressmuito lentidão (independentemente das bs=configurações), e parece que opensslisso limita a quantidade de dados aleatórios que ele gera (pelo menos para a versão 1.0.2p). A melhor opção que encontrei foi o comentário do frostschutz para usar shred, como em:

shred -v -n 1 /dev/sdX

Certifique-se de usar o -n 1padrão, caso contrário, será gravado o dispositivo três vezes (mais o -vque mostra o progresso). Não acho que a qualidade dos números pseudo-aleatórios seja tão alta, mas basta preparar um HDD portátil de grande capacidade para criptografia.

drgibbon
fonte