id: Гость   вход   регистрация
текущее время 21:00 25/09/2018
Автор темы: Гость, тема открыта 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 След.
Комментарии
— Гость (24/01/2011 12:04)   <#>
Блин, прервал его, написало, что скопировано только 93 Гб, пришлось снова начать, ппц почему так долго? и видимо начнет по новой писать с первых секторов?
— unknown (24/01/2011 13:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
И еще возник вопрос, почему здесь рекомендуется юзать /dev/urandom, а не /dev/random?

Размер буфера /dev/random фиксирован, его можно посмотреть в /proc/sys/kernel/random. Если он не слинкован с аппаратным генератором энтропии, то по исчерпании этой энтропии, он ждёт наполнения её из буфера. Предположим, что для этого нужно в течении минуты непрерывно печатать на клавиатуре, а размер буфера — 4096 байт. Тогда для заполнения 300 Гигабайт уйдёт (300 * 230 )/ (2 12) = 78643200 заполнений буфера. В году 365 * 24 * 60 = 525600 минут.
78643200 / 525600 ~ 150 лет. Печатать надо непрерывно.
— SATtva (24/01/2011 13:20)   профиль/связь   <#>
комментариев: 11531   документов: 1036   редакций: 4054
Блин, прервал его, написало, что скопировано только 93 Гб, пришлось снова начать, ппц почему так долго?

Потому что, в отличие от /dev/zero, это ГПСЧ. Смотрите нагрузку процессора.

и видимо начнет по новой писать с первых секторов?

Можно начать писать с нужного оффсета: man dd, параметр seek.
— unknown (24/01/2011 13:28, исправлен 24/01/2011 13:32)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

А если вот так kill -USR1 `pidof dd`, то можно посмотреть сколько там, но не прерывать.


Есть конечно опция skeep. SATtva уже поправил: offset


Самый быстрый способ такой. Поднять шифрованный раздел, пароль ввести. Файловую систему не создавать. Сделать dd if=/dev/zero bs=1M of=/шифрованный_раздел


Можете bs указать побольше.


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


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

— SATtva (24/01/2011 13:33)   профиль/связь   <#>
комментариев: 11531   документов: 1036   редакций: 4054
Самый быстрый способ такой. Поднять шифрованный раздел, пароль ввести. Файловую систему не создавать. Сделать dd if=/dev/zero bs=1M of=/шифрованный_раздел

Отличная идея. Если ещё и процессор имеет инструкции AES-NI, то скорость затирки будет ограничена только скоростью записи физического носителя.
— Гость (24/01/2011 14:25)   <#>
SATtva, unknow
Большущее спасибо за ответы/советы.
А вот еще такой вопрос, этот hdd изначально был размечен как имеющий физический раздел /dev/sdb1, аналогичный по размеру /dev/sdb, на нем, как обычно, была ntfs.
Когда я сделал dd if=/dev/urandom of=/dev/sdb (а не dd if=/dev/urandom of=/dev/sdb1), он, конечно, уконтропупил sdb1.
Если не размечать устройство по разделам типа /dev/sdbX, создавать криптораздел непосредственно в /dev/sdb, а не в /dev/sdbX, это может как-то негативно сказаться на HDD или еще в каком-то отношении?
Или все-таки лучше поиграться с fdisk и создать /dev/sdb1? (Я не собираюсь на устройстве делать несколько разделов, мне нужен собственно только один раздел).
И второй вопрос. Очень хочется скинуть туда бэкапы и спокойно делать другие дела.
Если я сейчас (после такого завершения перезаписи данных) смонтирую криптораздел, запишу туда все, что надо, а потом натравляю на точку монтирования этого раздела sfill -vl, это разве не тот же результат будет?! Понятно, что создавать большой файл, наполняемый всяким shit, она будет на смонтированной ФС, но физически будут те же блоки юзаться, где все остальное лежит, и оно должно будет затереть все старые данные вне криптораздела, не?
— Гость (24/01/2011 14:40)   <#>
А если вот так kill -USR1 `pidof dd`, то можно посмотреть сколько там, но не прерывать.


А почему dd не прерывается так и показывает, что сделалось? А когда такое же делаешь,например, на tar, прерывается?

P.S. Вообще можно и скриптик написать, чтобы остановилось, когда все пройдет, видимо.
— SATtva (24/01/2011 14:50, исправлен 24/01/2011 14:50)   профиль/связь   <#>
комментариев: 11531   документов: 1036   редакций: 4054
А почему dd не прерывается так и показывает, что сделалось? А когда такое же делаешь,например, на tar, прерывается?

Потому что каждая программа вольна по-своему трактовать специальные сигналы. Иногда они описаны в мане.


Вообще можно и скриптик написать, чтобы остановилось, когда все пройдет, видимо.

Для dd? Он сам остановится, когда либо а) дойдёт до конца дискового раздела, либо б) запишет заданное число байт (параметры count, bs и др.).

— sentaus (24/01/2011 14:54)   профиль/связь   <#>
комментариев: 1058   документов: 16   редакций: 32
Кстати, затирать ещё можно используя shred.


Если не размечать устройство по разделам типа /dev/sdbX, создавать криптораздел непосредственно в /dev/sdb, а не в /dev/sdbX, это может как-то негативно сказаться на HDD или еще в каком-то отношении?

Нет, во всяком случае не при "затирке".

Понятно, что создавать большой файл, наполняемый всяким shit, она будет на смонтированной ФС, но физически будут те же блоки юзаться, где все остальное лежит, и оно должно будет затереть все старые данные вне криптораздела, не?


В данном случае это будет зависеть ещё и от самой ФС. Если ФС журналируемая, то на это полагаться 100% не стоит.


Мне кажется, что полсуток достаточно для 300-гигового диска, что называется, с "головой".


Мой штатный телепат предполагет, что скорость записи у этого диска около 80-90 Мб/сек, поэтому однократное затирание должно быть сделано примерно за час.
— sentaus (24/01/2011 14:57)   профиль/связь   <#>
комментариев: 1058   документов: 16   редакций: 32

Потому что каждая программа вольна по-своему трактовать специальные сигналы. Иногда они описаны в мане.

Да, название программы kill сбивает очень многих :)
— Гость (24/01/2011 15:05)   <#>
Для dd? Он сам остановится, когда либо а) дойдёт до конца дискового раздела, либо б) запишет заданное число байт (параметры count, bs и др.).

То есть, а) касается не только устройства которое if, но и то, которое of? Значит, это я зря испугался, что будет писаться постоянно, пока /dev/urandom генерит псевдослучайные числа.

Кстати, затирать ещё можно используя shred.


В данном случае это будет зависеть ещё и от самой ФС. Если ФС журналируемая, то на это полагаться 100% не стоит.


Затираемые старые данные были под nffs, которую я снес и на место которой я ставлю ext3 под крипторазделом.
Как я понимаю, криптораздел в процессе эксплуатации затирать нет особой необходимости, так как он создается для того, чтобы противник изначально не имел к нему доступа.

Файлы или разделы? Если shred на раздел натравить, разве он просто не удалит файл устройства /dev/sdX?!

Если не размечать устройство по разделам типа /dev/sdbX, создавать криптораздел непосредственно в /dev/sdb, а не в /dev/sdbX, это может как-то негативно сказаться на HDD или еще в каком-то отношении?

Нет, во всяком случае не при "затирке".


Я имел ввиду, при функционировании устройства?

Мой штатный телепат предполагет, что скорость записи у этого диска около 80-90 Мб/сек, поэтому однократное затирание должно быть сделано примерно за час.


Почему-то почти за 12 часов затерлось из /dev/urandom только треть диска...

Вот сейчас по методике unknown из /dev/zero – скорость всего 2 Мб/с.
(Тут надо иметь ввиду, что это внешний HDD, подключенный через USB).
— Гость (24/01/2011 15:34)   <#>
Вот сейчас по методике unknown из /dev/zero – скорость всего 2 Мб/с.


Ааа, просто я дебил! Я забыл задать bs=1M. Сейчас с bs=1M скорость правда не 80 – 90 Мб/с, но половину от этого.
А если сделать bs=1G? Или чем больше блок, тем хуже затираются старые данные?

И еще такой вопрос, согласно man dd

Если же задано просто bs, то seek берет за основу bs, поскольку согласно мануалу "данная опция перекрывает опции ibs и obs? Или нет?
— sentaus (24/01/2011 15:42, исправлен 24/01/2011 15:43)   профиль/связь   <#>
комментариев: 1058   документов: 16   редакций: 32
Если shred на раздел натравить, разве он просто не удалит файл устройства /dev/sdX?!

По умолчанию shred просто затирает указанный файл, который может быть и блочным устройством. Для удаления нужно ещё ключ -u указать, но я не знаю, что он сделает в случае, если затираемый файл – болчное устройство.


которую я снес и на место которой я ставлю ext3 под крипторазделом.

sfill работает с примонтированными ФС и не затрёт блоки, которые ext3 отвела "под себя". В лучшем случае они будут затёрты однократно при форматировании раздела в ext3, в худшем – не перезаписаны ни разу.


Я имел ввиду, при функционировании устройства?

Здесь проблем не будет.


(Тут надо иметь ввиду, что это внешний HDD, подключенный через USB).

Тогда больше 30 Мб/сек не получить никак. По крайней мере, не на USB 2.0. Промерьте скорость чтения/записи тем же dd, если она сильно ниже, то для начала попробуйте заменить usb-кабель.

— sentaus (24/01/2011 15:48)   профиль/связь   <#>
комментариев: 1058   документов: 16   редакций: 32
Сейчас с bs=1M скорость правда не 80 – 90 Мб/с, но половину от этого.

А, ну вот всё и выяснилось.

А если сделать bs=1G? Или чем больше блок, тем хуже затираются старые данные?

dd сохраняет весь блок в памяти, а потом сбрасывает его на диск, т.е. это просто такой самопальный кэш. Больше десятка мегабайт ставить никакого смысла нет, скорость уже не вырастет. А уж если вы ещё и превысите объем доступной памяти, то это блок будет вообще в своп сбрасываться :)
— unknown (24/01/2011 15:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вообще давно назрело.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3