"Вечное" выолпнение 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 генерит еще более "случайные" данные. Разве он не лучше?
Или для этой цели такой необходимости нет, а времени/ресурсов займет больше?
комментариев: 9796 документов: 488 редакций: 5664
Размер буфера /dev/random фиксирован, его можно посмотреть в /proc/sys/kernel/random. Если он не слинкован с аппаратным генератором энтропии, то по исчерпании этой энтропии, он ждёт наполнения её из буфера. Предположим, что для этого нужно в течении минуты непрерывно печатать на клавиатуре, а размер буфера — 4096 байт. Тогда для заполнения 300 Гигабайт уйдёт (300 * 230 )/ (2 12) = 78643200 заполнений буфера. В году 365 * 24 * 60 = 525600 минут.
78643200 / 525600 ~ 150 лет. Печатать надо непрерывно.
комментариев: 11558 документов: 1036 редакций: 4118
Потому что, в отличие от /dev/zero, это ГПСЧ. Смотрите нагрузку процессора.
Можно начать писать с нужного оффсета: man dd, параметр seek.
комментариев: 9796 документов: 488 редакций: 5664
А если вот так kill -USR1 `pidof dd`, то можно посмотреть сколько там, но не прерывать.
Есть конечно опция skeep.SATtva уже поправил: offsetСамый быстрый способ такой. Поднять шифрованный раздел, пароль ввести. Файловую систему не создавать. Сделать dd if=/dev/zero bs=1M of=/шифрованный_раздел
Можете bs указать побольше.
Если считать используемый шифр идеальным, то знание противником наличия на разделе в открытом тексте большого числа нулей не поможет в криптоанализе. А с нулями всё пойдёт быстрее.
На случай криптопаранойи после того, как отработается заполнение нулями, можно сменить пароль диска, стерев старый. Можно даже заголовок стереть тем же dd и заново его создать с новым паролем. Получится контейнер, снаружи заполненный случайными числами, внутри которого когда-то были нули на неизвестном пароле. Стойкость такого генератора равна по криптостойкости использованному шифру на неизвестном пароле (ключе), в режиме шифрования нулей.
комментариев: 11558 документов: 1036 редакций: 4118
Отличная идея. Если ещё и процессор имеет инструкции AES-NI, то скорость затирки будет ограничена только скоростью записи физического носителя.
Большущее спасибо за ответы/советы.
А вот еще такой вопрос, этот 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, она будет на смонтированной ФС, но физически будут те же блоки юзаться, где все остальное лежит, и оно должно будет затереть все старые данные вне криптораздела, не?
А почему dd не прерывается так и показывает, что сделалось? А когда такое же делаешь,например, на tar, прерывается?
P.S. Вообще можно и скриптик написать, чтобы остановилось, когда все пройдет, видимо.
комментариев: 11558 документов: 1036 редакций: 4118
Потому что каждая программа вольна по-своему трактовать специальные сигналы. Иногда они описаны в мане.
Для dd? Он сам остановится, когда либо а) дойдёт до конца дискового раздела, либо б) запишет заданное число байт (параметры count, bs и др.).
комментариев: 1060 документов: 16 редакций: 32
Нет, во всяком случае не при "затирке".
В данном случае это будет зависеть ещё и от самой ФС. Если ФС журналируемая, то на это полагаться 100% не стоит.
Мой штатный телепат предполагет, что скорость записи у этого диска около 80-90 Мб/сек, поэтому однократное затирание должно быть сделано примерно за час.
комментариев: 1060 документов: 16 редакций: 32
Да, название программы kill сбивает очень многих :)
То есть, а) касается не только устройства которое if, но и то, которое of? Значит, это я зря испугался, что будет писаться постоянно, пока /dev/urandom генерит псевдослучайные числа.
Затираемые старые данные были под nffs, которую я снес и на место которой я ставлю ext3 под крипторазделом.
Как я понимаю, криптораздел в процессе эксплуатации затирать нет особой необходимости, так как он создается для того, чтобы противник изначально не имел к нему доступа.
Файлы или разделы? Если shred на раздел натравить, разве он просто не удалит файл устройства /dev/sdX?!
Я имел ввиду, при функционировании устройства?
Почему-то почти за 12 часов затерлось из /dev/urandom только треть диска...
Вот сейчас по методике unknown из /dev/zero – скорость всего 2 Мб/с.
(Тут надо иметь ввиду, что это внешний HDD, подключенный через USB).
Ааа, просто я дебил! Я забыл задать bs=1M. Сейчас с bs=1M скорость правда не 80 – 90 Мб/с, но половину от этого.
А если сделать bs=1G? Или чем больше блок, тем хуже затираются старые данные?
И еще такой вопрос, согласно man dd
Если же задано просто bs, то seek берет за основу bs, поскольку согласно мануалу "данная опция перекрывает опции ibs и obs? Или нет?
комментариев: 1060 документов: 16 редакций: 32
По умолчанию shred просто затирает указанный файл, который может быть и блочным устройством. Для удаления нужно ещё ключ -u указать, но я не знаю, что он сделает в случае, если затираемый файл – болчное устройство.
sfill работает с примонтированными ФС и не затрёт блоки, которые ext3 отвела "под себя". В лучшем случае они будут затёрты однократно при форматировании раздела в ext3, в худшем – не перезаписаны ни разу.
Здесь проблем не будет.
Тогда больше 30 Мб/сек не получить никак. По крайней мере, не на USB 2.0. Промерьте скорость чтения/записи тем же dd, если она сильно ниже, то для начала попробуйте заменить usb-кабель.
комментариев: 1060 документов: 16 редакций: 32
А, ну вот всё и выяснилось.
dd сохраняет весь блок в памяти, а потом сбрасывает его на диск, т.е. это просто такой самопальный кэш. Больше десятка мегабайт ставить никакого смысла нет, скорость уже не вырастет. А уж если вы ещё и превысите объем доступной памяти, то это блок будет вообще в своп сбрасываться :)
комментариев: 9796 документов: 488 редакций: 5664