Если у вас была система без запущенных других процессов, которая могла бы нуждаться в доступе (или вызывать доступ) к диску, тогда да, это могло бы работать, но это чрезвычайно неэффективно. В идеале вы должны определить используемые дисковые блоки, убедиться, что ни один из блоков не был переназначен контроллером накопителя, и записать поверх блока данных большое разнообразие значений, многократно, чтобы не осталось остаточного отпечатка.
«Простой» способ безопасного удаления файлов на Unix-сервере?
Инструменты командной строки, такие как «shred», поставляются со многими заявлениями об отказе от ответственности в ситуациях, когда они не могут безопасно удалять файлы. У меня была идея найти дешевый и простой способ сделать это, и я хотел получить совет.
Как насчет запуска «dd» из / dev / zero и попытки создать файл больше, чем оставшееся место в разделе. Конечно, это заполнит базовые блоки всеми нулями, и, как только он умрет из-за нехватки дискового пространства, вы просто удалите этот файл.
Таким образом, я думаю, что любая утилита восстановления, которая пытается исследовать базовый диск, будет видеть только нули, независимо от того, где он выглядит ...
Да, это было бы неэффективно на большом разделе, но это в сторону - насколько это нормально? ....
4 ответа на вопрос
- Популярные
- Новые
- С комментариями
- Активные
Не сработает
Такие программы, как "shred", записывают случайный мусор на диск, используемый файлом - несколько раз.
Просто запись нулей все равно оставит «отпечаток» исходных данных. Даже если вы делаете это несколько раз.
Это также неэффективно. У вас могут быть ОГРОМНЫЕ области диска, которые никогда не записывались, на которые вы часами пишете нули без какой-либо причины. Гораздо эффективнее просто перезаписать области, фактически используемые данным файлом.
Проблема отпечатков, если она существует, может быть решена с помощью источника из / dev / urandom вместо / dev / zero. Или даже, так как производительность, кажется, не имеет никакого значения в предпосылке, исходите из / dev / random.
У вас все еще будет проблема с переназначенными дисковыми блоками, особенно в ssds. Если один из блоков, в которые вы записали ваши конфиденциальные данные, будет считаться неисправным микропрограммой, он будет заменен резервным блоком и удален, а содержимое скопировано в блок замены. Файловая система ничего не видит из этого, ваши конфиденциальные данные недоступны из вашего программного обеспечения, но все еще доступны для криминалистических методов. Вы не сможете достичь и перезаписать этот удаленный блок своими конфиденциальными данными на нем любым программным подходом.
ДД будет очень плохим выбором. Это секторный инструмент копирования. Неважно, какие данные в этих секторах. Насколько я знаю, DD не имеет понятия о свободном пространстве или файлах. Я перевел с 120 ГБ до 320 ГБ HD на своем ноутбуке, и DD скопировал 120 ГБ данных, хотя у меня действительно было 30 ГБ бесплатно. (это было действительно круто, даже разделять его не нужно, просто скопировали все разделы, удалили файлы, поменяли местами и т. д.)
Не говоря уже о том, что свободное пространство не является смежным, оно часто разбросано по всему диску. Таким образом, вы не можете просто сказать «перезаписать вторую половину диска», потому что он заполнен только наполовину, потому что данные будут на всем диске.
Похожие вопросы
-
9
В чем разница между командами "su -s" и "sudo -s"?
-
1
Приостановить все, кроме x задач, интенсивно использующих процессор
-
9
"Отсоединить" и "Reattach" Xterms через X сессий?
-
-
1
Windows дата репрезентация
-
9
grep все файлы .java в каталоге для конкретной строки
-
1
Является ли kill -STOP временной командой?
-
2
Изменить количество строк и столбцов в VT420?
-
10
Как я могу найти в истории bash и повторно запустить команду?
-
2
Можно ли передать выходные данные одной команды двум другим командам?
-
3
Хватит cron отправлять мне письма