Maneira rápida de randomizar HD?

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.

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.

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 "

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.

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.

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.}

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.