maneira rápida de randomizar HD?

Question

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

No entanto, quando tentei usar dd if=/dev/urandom of=/dev/sda no passado, o ETA estava procurando ficar na ordem de dias. Eu vi algo sobre o uso de badblocks em vez de urandom, mas isso não parece ajudar muito. Gostaria apenas de saber se há alguma maneira que possa me ajudar a acelerar isso, como opções para dd ou algo que eu possa estar perdendo, ou se a velocidade é apenas uma limitação do HD.

    

Answer 1

dd if=/dev/urandom of=/dev/sda ou simplesmente cat /dev/urandom >/dev/sda , não é o caminho mais rápido para preencher um disco com dados aleatórios. O /dev/urandom do Linux não é o RNG criptográfico mais rápido disponível. 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 preencher o disco com dados aleatórios é praticamente inútil. Em primeiro lugar, para dissipar um mito comum, limpar com zeros é tão bom no hardware de hoje . Com a tecnologia de disco rígido dos anos 80, a substituição de um disco rígido por zeros deixou uma pequena carga residual que pode ser recuperada com hardware um pouco caro; múltiplas passagens de sobrescrever com dados aleatórios (o "Gutmann wipe") eram necessárias. Hoje, até mesmo uma única passagem de sobrescrever com zeros deixa dados que não podem ser realisticamente recuperados, mesmo em condições de laboratório.

Quando você criptografa 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ível 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 dá uma boa dica sobre o tamanho máximo do sistema de arquivos (embora, com o passar do tempo, se torne uma aproximação cada vez pior) e pouco mais.

    

Answer 2

Você pode fazer com que o OpenSSL criptografe /dev/zero com uma senha aleatória, fornecendo dados pseudo-aleatórios aceitáveis muito rapidamente (se sua CPU suportar acelerá-la).

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 através de pv para obter progresso / ETA. Os comandos que estou executando agora (em um shell de root) 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

Eu tenho essa idéia de esta resposta , depois tendo o mesmo problema do John irracional , que comentou sobre o caso de Gilles resposta acima. Isso aumentou minha velocidade de limpeza para meu novo conjunto RAID de 11MB / s para cerca de 300MB / s, levando o que levaria uma semana para 10 horas.

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

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

    

Answer 3

O openssl não parece funcionar para mim. Eu tenho "opções desconhecidas" e outros problemas com as soluções fornecidas. Então acabei indo com o fio do programa.

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 19TB 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 isso seja na verdade dados aleatórios. A página man diz fio "Padrão: preenchimento de buffers com dados aleatórios." link

Eu não estou fazendo isso para fins de segurança / criptografia, apenas tentando ter certeza de que meus testes de leitura posteriores são dados reais e não apenas 0s. Este mesmo comando fio poderia ser usado para o pré-condicionamento SSD / NVMe. Como apenas usando / dev / zero pode levar a compressão de nível de disco "batota" quanto é realmente escrito. Apesar de eu adicionar um -loops=2 flag, se for um novo SSD para benchmarking.

Se você quisesse que fosse seguro, talvez pudesse usar a opção -randrepeat=bool , pois isso alternaria "Semear o gerador de números aleatórios de uma maneira previsível para que os resultados sejam repetíveis nas execuções. Padrão: true.", mas ainda não tenho certeza de como isso seria seguro.

Além disso, alguns HDDs de classe empresarial estão disponíveis no mercado (SED - Self Encrypting Drives) e permitem que você gire a chave de criptografia para apagar instantaneamente e com segurança todos os dados gravados.

Finalmente, eu usei no passado o DBAN (também conhecido como Darik's Boot e Nuke), que tem opções de CD e USB inicializáveis e é um projeto de código aberto hospedado no SourceForge. O programa é projetado para apagar com segurança um disco rígido até os dados são permanentemente removidos e não podem mais ser recuperados "

    

Answer 4

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

Você usa um programa simples que ecoa números aleatórios de uma boa biblioteca como boost::random e usa esse em dd .

Se você escolher aumentar, pode usar este exemplo, mudando a função experiment para as suas necessidades.

    

Answer 5

O gargalo não é nem o tamanho do bloco nem o disco rígido, mas a geração lenta de números pseudo-aleatórios. /dev/urandom é por magnitudes mais rápidas em comparação com /dev/random , já que não está 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

Esta taxa será muito mais lenta do que a taxa de gravação do seu disco rígido. Uma solução correta depende totalmente do seu nível de segurança exigido. 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 são tão altas, você pode capturar algumas dezenas de MiB de dados e gravar essa string repetidamente na unidade. Ou talvez até mesmo escrever zeros de /dev/zero seja uma opção.

Resumo

/dev/random - seguro, muito lento
/dev/urandom - menos secure¹, lento
hardware RNG - seguro, rápido, muito caro
( /dev/zero - não 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.}

    

Answer 6

Eu estava tentando preencher um HDD externo de 4 TB USB com dd if=/dev/urandom of=/dev/sdX status=progress , que era muito lento (independentemente de bs= configurações), e parece que openssl tem um limite na quantidade de dados aleatórios que serão gerados 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 1 caso contrário, o padrão será gravar o dispositivo 3 vezes (mais o -v , que mostra o progresso). Não acho que a qualidade dos números pseudo-aleatórios é tão alto, mas é o suficiente para preparar um HDD portátil de grande capacidade para criptografia.