Быстрый способ рандомизировать HD?

14

Я читал о том, как сделать жесткие диски безопасными для шифрования, и одним из шагов является запись случайных битов на диск, чтобы сделать зашифрованные данные неотличимыми от остальных данных на жестком диске.

Тем не менее, когда я пытался использовать dd if=/dev/urandom of=/dev/sdaв прошлом, ETA выглядела на порядок дней. Я видел кое-что об использовании badblocksвместо случайного, но это, казалось, не очень помогло. Я просто хотел бы знать, есть ли какие-либо способы, которые могут помочь мне ускорить это, такие как варианты ddили что-то еще, что я могу пропустить, или если скорость - только ограничение HD.

bitflips
источник
Измените размер блока на более дружественный к жестким дискам. dd bs=1Mнапример.
Патрик
Какую скорость вы получили? Для записи всего 3 ТБ (например) жесткого диска требуется некоторое время. Также проверьте, iostat -kx 10что занято% на диске.
Дероберт
5
shred -v -n 1 /dev/overwritethisэто быстро. Это единственный случай, когда shredчто-то действительно полезно.
frostschutz
@derobert: Я не могу точно сказать, как быстро это было, но я ушел на несколько часов, вернулся, и он был готов примерно на 10% для моего 500G внутреннего HD в первый раз, когда я попробовал это. Спасибо за подсказку "iostat" между прочим
bitflips
@Patrick: Я пытался вслепую bs = 4M, так как я видел это в руководстве о том, как поставить Arch CD на USB. Это помогло немного, но все еще было довольно медленно.
bitflips

Ответы:

14

dd if=/dev/urandom of=/dev/sdaили просто cat /dev/urandom >/dev/sda не самый быстрый способ заполнить диск случайными данными. Linux /dev/urandomне самый быстрый криптографический RNG. Есть ли альтернатива / dev / urandom? есть некоторые предложения. В частности, OpenSSL содержит более быстрый криптографический PRNG:

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

Обратите внимание, что в конечном итоге, есть ли улучшение или нет, зависит от того, какая часть является узким местом: процессор или диск.

Хорошей новостью является то, что заполнение диска случайными данными в большинстве случаев бесполезно. Во-первых, чтобы развеять общий миф, стереть с нуля так же хорошо на современном оборудовании . С технологией жесткого диска 1980-х, перезапись жесткого диска нулями оставила небольшой остаточный заряд, который можно было бы восстановить с помощью довольно дорогого оборудования; было необходимо несколько проходов перезаписи со случайными данными («стирание Гутмана»). Сегодня даже один проход перезаписи с нулями оставляет данные, которые не могут быть реально восстановлены даже в лабораторных условиях.

При шифровании раздела заполнение диска случайными данными не требуется для обеспечения конфиденциальности зашифрованных данных. Это полезно, только если вам нужно сделать пространство, используемое зашифрованными данными, неотличимым от неиспользуемого пространства. Создание зашифрованного тома поверх неслучайного контейнера показывает, какие блоки диска когда-либо использовались зашифрованным томом. Это дает хороший намек на максимальный размер файловой системы (хотя со временем это будет становиться все хуже и хуже) и немного больше.

Жиль "ТАК - перестань быть злым"
источник
4
Гутманн - миф во всей его полноте, я не думаю, что это вообще когда-либо было сделано для жесткого диска 1980-х годов. Ирония заключается в том, что, когда накопители становятся умнее, в настоящее время вам действительно следует использовать случайные данные, чтобы убедиться, что накопитель вынужден записывать, а не свободный сектор (усечение) или сжатие данных. Нули хороши только если они на самом деле написаны.
frostschutz
1
@ mellowmaroon Да, cat /dev/zeroпочти всегда достаточно. Недостаточно, если вы хотите скрыть, сколько свободного места на зашифрованном томе.
Жиль "ТАК - прекрати быть злым"
1
@ mellowmaroon Это бесполезно. Подслушиватель будет знать, что у вас есть максимум X МБ данных (и, возможно, намного меньше, потому что ранее использованное, но теперь свободное пространство неотличимо от используемого пространства), и что? Также расположение свободного места может указывать тип файловой системы (копии суперблоков); это редко вызывает озабоченность (как правило, это раскрывается в открытом тексте /etc/fstab, если только вы не зашифровали корневой раздел, и даже в этом случае не так много правдоподобных вариантов).
Жиль "ТАК - перестань быть злым"
2
@Gilles Проблема, с которой я столкнулся в Ubuntu 13.10, заключается в том, что, openssl randпохоже, существует верхний предел количества байтов, которые он генерирует. Если вы превысите этот лимит, например '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`, вы получите столько случайных байтов.
иррациональный Джон
1
Для иррациональной проблемы с верхним пределом Джона, 810 миллиардов байт составляют около 754 ГБ. Как насчет разбиения вашего диска на несколько разделов по 700 ГБ, затем openssl randвыполнить команду для каждого раздела в обратном порядке, начиная с sda5 или чего-то еще и работая в обратном направлении к sda1 и, наконец, sda?
jia103 24.12.15
6

Openssl, похоже, не работает для меня. Я получил "неизвестные варианты" и другие проблемы с предоставленными решениями. Так что я закончил с программой FIO.

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

Что, кажется, занимает 3 часа, чтобы сделать 19 ТБ на 24 жестких дисках. Итак, примерно 1800 МБ / с

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]

Я надеюсь, что это на самом деле случайные данные. Страница man говорит fio "По умолчанию: заполнить буферы случайными данными." http://linux.die.net/man/1/fio

Я не делаю это в целях безопасности / шифрования, просто пытаюсь убедиться, что мои последующие тесты на чтение - это реальные данные, а не просто нули. Эту же команду fio можно использовать для предварительной подготовки SSD / NVMe. Как только использование / dev / zero может привести к сжатию на уровне диска, «обманывая», сколько фактически написано. Хотя я бы добавил -loops=2к нему флаг, если это свежий SSD для бенчмаркинга.

Если вы хотите, чтобы он был безопасным, вы можете использовать эту -randrepeat=bool опцию, так как она переключит «Заполнить генератор случайных чисел предсказуемым образом, чтобы результаты можно было повторять при каждом прогоне. По умолчанию: true.», Но я все еще не уверен, насколько это безопасно.

Кроме того, некоторые жесткие диски корпоративного класса, такие как SED (Self Encrypting Drives), позволяют вращать ключ шифрования для мгновенного и безопасного удаления всех записанных данных.

Наконец, в прошлом я использовал DBAN (он же Darik's Boot and Nuke), который имеет параметры загрузки с CD и USB и «является проектом с открытым исходным кодом, размещенным на SourceForge. Программа предназначена для безопасного стирания жесткого диска до тех пор, пока его данные не будут навсегда сохранены». удалены и больше не подлежат восстановлению "

TaylorSanchez
источник
1
Размер = 100% у меня не сработал, но fill_device = 1 (или fill_fs = 1) сработало.
d.jamison
Я думаю, что это будет зависеть, если вы предоставите ему устройство блочного уровня или файловую систему для заполнения. С помощью устройства уровня блока он знает, насколько он большой, и его размер составляет процент от размера устройства. Куда идет fill_device до тех пор, пока не получит ошибку переполнения устройства. Я думаю, что флаг fill_device не может перезаписывать файлы, только неиспользуемое пространство. Я не проверял это, поскольку я обычно избегаю файловых систем, если в этом нет необходимости, когда я тестирую устройство.
Тейлор Санчес
6

Вы можете заставить OpenSSL зашифровать /dev/zeroслучайным паролем, предоставляя приличные псевдослучайные данные очень быстро (если ваш процессор поддерживает их ускорение).

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

Вы можете передать это, pvчтобы получить прогресс / ETA. Команды, которые я сейчас запускаю (в корневой оболочке):

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

Я получил эту идею из этого ответа , после того, как столкнулся с той же проблемой, что и иррациональный Джон , который прокомментировал ответ Жиля выше. Это увеличило мою скорость очистки до моего нового RAID-массива с 11 МБ / с до примерно 300 МБ / с, что заняло неделю до 10 часов.

Я добавлю, что вы должны быть в состоянии использовать, а не более сложный оператор, описанный выше, но есть ошибка, которая позволит производить только 16 МБ вывода. (Эта ошибка была подана, январь 2016 г.)openssl rand #of_bytesopenssl enc ...ssl

И, согласно ответу на этот вопрос , и продолжая предполагать, что ЦП является узким местом, возможно, можно еще больше увеличить скорость, запустив несколько параллельных opensslпроцессов на отдельных ядрах, комбинируя их с помощью FIFO.

tremby
источник
Не уверен, что редактирование было необходимо. Другие ответы на этот вопрос предлагают openssl rand.
Тремби
2
Тест: dd if=/dev/urandom18 МБ / с, openssl enc~ 180 МБ / с, fio169 МБ / с, openssl randбез поддержки> 754 ГБ. Обратите внимание , что если вы хотите автоматическое вычисление размера, используйте: 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. Осторожно, sdaприсутствует дважды в этой команде.
KrisWebDev
0

Завершая ответ Марко, вам нужен более быстрый генератор случайных чисел.

Вы используете простую программу, которая выводит случайные числа из хорошей библиотеки, например, boost::randomи используете ее в dd.

Если вы выберете boost, вы можете использовать этот пример, изменив experimentфункцию в соответствии с вашими потребностями.

RSFalcon7
источник
Насколько быстрее решение для повышения в вашей системе? Быстрый ненаучный тест на моей машине дает точно такую ​​же скорость, что и /dev/urandom.
Марко
boost::randomне предлагает крипто-ГСЧ, не так ли? Если вы собираетесь использовать не крипто-ГСЧ, вы также можете использовать нули: по крайней мере, у вас не будет иллюзии безопасности.
Жиль "ТАК - перестань быть злым"
Я не могу точно boost::randomсказать, насколько быстры генераторы, единственный способ узнать наверняка, это измерить их самый быстрый алгоритм/dev/urandom
RSFalcon7
0

Узким местом является не размер блока и не жесткий диск, а медленная генерация псевдослучайных чисел. /dev/urandomпо величине быстрее по сравнению /dev/randomс тем, что он не блокируется в пуле с низкой энтропией.

Вы можете подтвердить это, измерив необработанный вывод ваших псевдослучайных чисел:

pv /dev/urandom >/dev/null

Эта скорость будет намного ниже, чем скорость записи вашего жесткого диска. Правильное решение полностью зависит от вашего уровня безопасности. Если вам требуется высокий уровень безопасности, используйте быстрый аппаратный генератор случайных чисел или примите медленную скорость. Если ваши потребности в безопасности не так высоки, вы можете записать несколько десятков МБ данных и многократно записать эту строку на диск. Или, может быть, даже запись нулей из /dev/zero- это вариант.

Резюме

/dev/random - безопасный, очень медленный
/dev/urandom- менее безопасный - медленный
аппаратный ГСЧ - безопасный, быстрый, очень дорогой
( /dev/zero - вообще не случайный, очень быстрый)

¹ Согласно: Является ли ранд из / dev / urandom безопасным для ключа входа? /dev/urandomтак же безопасно, как /dev/random. Спасибо Жилю за указание на это.

Marco
источник
Он уже использует urandom.
Патрик
В самом деле. Я хочу сказать, что даже урандом слишком медленный для своих нужд, поэтому ему нужно другое решение, чем урандом.
Марко
@ Жиль Спасибо за ссылку. Страница руководства ясно заявляет: … В результате, если в пуле энтропии недостаточно энтропии, возвращаемые значения теоретически уязвимы для криптографической атаки… Вот почему я классифицировал ее как менее безопасную.
Марко
0

Я пытался заполнить внешний жесткий диск USB емкостью 4 ТБ, dd if=/dev/urandom of=/dev/sdX status=progressкоторый был слишком медленным (независимо от bs=настроек), и, похоже, в нем opensslесть ограничение на количество случайных данных, которые он будет выводить (по крайней мере для версии 1.0.2p). Лучший вариант я нашел был комментарий от frostschutz для использования shred, как в:

shred -v -n 1 /dev/sdX

Убедитесь, что вы используете его, -n 1иначе по умолчанию устройство будет перезаписано 3 раза (плюс то, -vчто показывает прогресс). Я не думаю, что качество псевдослучайных чисел такое высокое, но мне достаточно подготовить переносной жесткий диск большой емкости для шифрования.

drgibbon
источник