id: Гость   вход   регистрация
текущее время 20:40 28/03/2024
Автор темы: Гость, тема открыта 24/01/2011 12:02 Печать
Категории: криптография, софт, инфобезопасность, хард, свободный софт
https://www.pgpru.com/Форум/UnixLike/ВечноеВыолпнениеDdIfdevurandomOfdevsdX
создать
просмотр
ссылки

"Вечное" выолпнение dd if=/dev/urandom of=/dev/sdX


Решил переформатировать HDD в криптованный диск для бэкапов.
Следуя советам, данным на форуме, для перезаписи данных на диске дал команду:

Сначала думал сделать что-то типа или , но что-то подумалось мне, что это делается на текущую mount point, и – не знаю, прав я или нет, но мне показалось, что дать команду на раздел безопаснее.
И вот уже полсуток продолжается работа dd и нет ей ни конца, ни краю... Причем, sfill по одному разу или по два раза, имхо, давно бы уже прошла вся (обычно на такой же объем уходило неск. часов, но не полсуток, если конечно не делать sfill без аргументов -l или -ll, когда оно будет 30 с гаком раз перезаписывать.
И только сейчас сообразил, что /dev/urandom генерит данные постоянно, это же не клонирование с диска на диск, если его не остановить, то он будет делать это вечно, или пока компьютер/диск не сломаются :)
Мне кажется, что полсуток достаточно для 300-гигового диска, что называется, с "головой".
Как правильно определить/задать время для данной работы?
И еще возник вопрос, почему здесь рекомендуется юзать /dev/urandom, а не /dev/random?
Я посмотрел, это разные устройства, а не ссылки одного на другого. Согласно манам, /dev/random генерит еще более "случайные" данные. Разве он не лучше?
Или для этой цели такой необходимости нет, а времени/ресурсов займет больше?



 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— Гость (12/11/2012 19:07)   <#>
Приведённый вами пример у меня работает
— Гость (13/11/2012 04:31)   <#>
«Команда выполняется без сообщений об ошибках» «работает», если что.
Вы проверяли, что skip корректно отработал?
— Гость (13/11/2012 06:42)   <#>
Если бы не проверял, то не написал бы. Правда опцию skip без буквы M использовал (подумал что опечатка), может в этом загвоздка? На петлевом устройстве /dev/loop0 удобно тестировать.
— unknown (13/11/2012 10:05, исправлен 13/11/2012 10:16)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Сначала у меня не сработало из-за того, что в первом dd задал ещё и count. При этом, какой бы большой count не задавать, получалось


А теперь, сравните без skip:


и со skip:


Со skip не работает второй dd и ничего не выдаёт на выход, в то время как из первого dd всё проходит через openssl и pv (или mbuffer), вот только куда?

— Гость (13/11/2012 19:30)   <#>
В сообщении comment57746 я уже привёл причину: вы используете букву M после количества пропускаемых блоков stdin задаваемого в skip. Это множитель 1024*1024=1048576, поэтому при bs=1M skip=4M соответствует сдвигу равному 4 терабайтам (1M x 4M = 4T). Это также объясняет вывод ошибки при задании числа блоков в 1-м dd (cannot skip to specified offset), поскольку смещение skip превышает размер stdin.

Попробуйте



Хотя мне кажется что достаточно пропустить один блок: skip=1.
— Гость (14/11/2012 00:00)   <#>
Кстати, таким же способом можно очищать CD



Но только перед каждым циклом очистки нужно готовить CD для перезаписи.

— unknown (14/11/2012 10:08)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
На первый взгляд это работает:

Но только если не использовать count, даже со множителем.
И опять же, просто при таком выводе маскируется ошибка dd: `standard input': cannot skip to specified offset:

Можно перенаправить её в файл даже из "работающей" команды:
— Гость (14/11/2012 17:01)   <#>
Похоже что эта ошибка связана с проходом потока через команду (openssl, mbuffer или др.) между двумя dd. Появляется начиная с определённого размера блока. При bs=1k и менее ошибка не появляется. Если первый dd передаёт поток напрямую второму (между ними нет команды), то ошибка отсутствует при любом размере блока, в том числе 1M и 1G. На случайность генерируемой последовательности данная ошибка видимо не влияет, может быть даже результат не искажает.
— unknown (14/11/2012 17:56)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
На случайность генерируемой последовательности данная ошибка видимо не влияет, может быть даже результат не искажает.

С gpg -c возникает такая же ошибка на dd, он ещё и заметно медленнее.
С другой стороны, ещё один повод задуматься, стоит ли доверять внешним командам в нестандартных вариантах использования, когда дело касается не наглядных результатов, а безопасности. Как бы такой, доведённый до абсурда Unix-way, не вышел боком. Может надёжнее всё-таки нулями в сам LUKS-контейнер? Все команды LUKS легко запомнить.
— Гость (14/11/2012 23:54)   <#>
По моему в данном случае дело не в самих командах, а в наличии посредника между двумя dd, на которого реагирует опция skip. Если хотите видеть прогресс с помощью pv или mbuffer будет та же самая ошибка при задании skip, независимо от того чем будете шифровать – dmcrypt, openssl или gpg. Просто при бессигнатурном шифровании опция skip не нужна и дефект программного канала себя не проявляет.
— Гость (13/12/2012 20:48)   <#>
А можно ли через dd забить рандомом неиспользуемое дисковое пространство на ext4 после обычного удаления чувствительных файлов без применения shred? И эффективно ли будет такое затирание?
— Гость (14/12/2012 06:35)   <#>
И эффективно ли будет такое затирание?

С учётом современной плотности записи на диски... наверное, однократной перезаписи достаточно. Я иногда тру как dd if=/dev/zero of=/path/to/file count=999999999999999, где file — файл на файловой системе, которую надо зачистить. Не знаю, насколько это безопасно. Обычно жду, когда dd вылетит с ошибокой, жалуясь на недостаток места, и считаю, что относительно безопасно всё затёрто.

Но тут есть тонкости, типа имён вложенных директорий, которые, возможно, могут как-то остаться. Например, обычная директория занимает 4.0K при вызове как ls -lad /path/to/dir, но у меня есть директория на ext3, в которой содержалось очень много мелких файлов. После того, как я зашреддил те файлы, размер директории так и остался большим — 1.3M, хотя внутри неё пусто. В общем, чудеса. Для серьёзного затирания информации вряд ли стоит полагаться на такой метод, но, если вы отдаёте себе отчёт во всех подводных камнях, то можно.
— Гость (14/12/2012 19:14)   <#>
Если файл модифицируется и размеры меняются, то его содержимое может оставаться в блоках, которые уже не связаны с данным файлом. Затирание файла с помощью dd, srm, shred и т.п. ненадёжно.

Для себя определил наиболее безопасный способ уничтожения информации с сохранением работоспособности диска:

1. Встроенная ATA-команда Secure Erase (заполняет нулями всё доступное место, а не только LBA)

2. Тройной проход dd с заполнением устройства случайными битами.

В общем-то первого пункта достаточно, второй скорее по традиции, для перестраховки. Это относится к hdd. С флешем и CD/DVD могут быть свои тонкости.
— Гость (14/12/2012 21:28)   <#>
Правильный метод — не создавать на основном разделе такие файлы, которые потом позарез захочется стереть. Т.е. для таких файлов нужна отдельная файловая система, к которой будут более строгие требования безопасности — например, почти всегда держать её отмонтированной, а ключ шифрования — удалённым из оперативной памяти.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3