«Простой» способ безопасного удаления файлов на Unix-сервере?

779
djsmiley2k

Инструменты командной строки, такие как «shred», поставляются со многими заявлениями об отказе от ответственности в ситуациях, когда они не могут безопасно удалять файлы. У меня была идея найти дешевый и простой способ сделать это, и я хотел получить совет.

Как насчет запуска «dd» из / dev / zero и попытки создать файл больше, чем оставшееся место в разделе. Конечно, это заполнит базовые блоки всеми нулями, и, как только он умрет из-за нехватки дискового пространства, вы просто удалите этот файл.

Таким образом, я думаю, что любая утилита восстановления, которая пытается исследовать базовый диск, будет видеть только нули, независимо от того, где он выглядит ...

Да, это было бы неэффективно на большом разделе, но это в сторону - насколько это нормально? ....

0
Какие отказы от ответственности? Может быть, вам нужно придумать способ, чтобы конкретно адресовать эти отказы от ответственности. Однако лучший способ гарантировать, что никто не сможет прочитать старые данные на вашем диске, - это использовать топор, кувалду или что-то в этом роде. Шутки в сторону. Старые компьютеры должны быть разобраны с жесткими дисками и уничтожены. 13 лет назад 0
Основной отказ от ответственности, IIRC, заключается в том, что перезапись файла не уничтожает содержимое при использовании журнализированной файловой системы. Я не уверен, что решение ОП противостоит этому. 13 лет назад 1

4 ответа на вопрос

1
Lazarus

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

0

Не сработает

Такие программы, как "shred", записывают случайный мусор на диск, используемый файлом - несколько раз.

Просто запись нулей все равно оставит «отпечаток» исходных данных. Даже если вы делаете это несколько раз.

Это также неэффективно. У вас могут быть ОГРОМНЫЕ области диска, которые никогда не записывались, на которые вы часами пишете нули без какой-либо причины. Гораздо эффективнее просто перезаписать области, фактически используемые данным файлом.

Я помню, как мой профессор по криминалистике утверждал, что этот отпечаток на жестких дисках является всего лишь (широко распространенным) мифом, возможно, он был правдой для самого первого поколения (жестких) дисков. Сегодняшняя плотность, по его словам, сделает это даже физически невозможным, то есть появление «отпечатков» по ​​современным стандартам обязательно будет означать ошибки чтения / перекрывающиеся биты. Конечно, я понятия не имею, что это правда. У вас случайно есть неоспоримый источник? 13 лет назад 2
Нет, я далеко не эксперт. Я просто знаю, что нынешняя военная численность (о которой сообщают различные «клочковые» программы) составляет около 3 переписываний. Также мое знание технологии HD может быть устаревшим, но я понял, что это образец магнитных отпечатков на диске, и они читаются; силы выше X равны 1, а ниже - 0. Однако, если вы записываете все 0 в сектор, значения более высокого уровня (чуть ниже X) составляли 1 с, а очень низкие значения - 0. Однако, как я уже сказал, моя информация может быть устаревшей. 13 лет назад 0
И военная сила в том, что иностранные правительства будут тратить неисчислимое время и деньги, чтобы взломать жесткий диск. Они могут позволить себе электронные микроскопы и все эти необычные инструменты. Мети-наркоман, который захватывает твой ноутбук, или парень, который покупает твой старый компьютер с ebay, не .. Brian 13 лет назад 2
0
user54114

Проблема отпечатков, если она существует, может быть решена с помощью источника из / dev / urandom вместо / dev / zero. Или даже, так как производительность, кажется, не имеет никакого значения в предпосылке, исходите из / dev / random.

У вас все еще будет проблема с переназначенными дисковыми блоками, особенно в ssds. Если один из блоков, в которые вы записали ваши конфиденциальные данные, будет считаться неисправным микропрограммой, он будет заменен резервным блоком и удален, а содержимое скопировано в блок замены. Файловая система ничего не видит из этого, ваши конфиденциальные данные недоступны из вашего программного обеспечения, но все еще доступны для криминалистических методов. Вы не сможете достичь и перезаписать этот удаленный блок своими конфиденциальными данными на нем любым программным подходом.

0
Brian

ДД будет очень плохим выбором. Это секторный инструмент копирования. Неважно, какие данные в этих секторах. Насколько я знаю, DD не имеет понятия о свободном пространстве или файлах. Я перевел с 120 ГБ до 320 ГБ HD на своем ноутбуке, и DD скопировал 120 ГБ данных, хотя у меня действительно было 30 ГБ бесплатно. (это было действительно круто, даже разделять его не нужно, просто скопировали все разделы, удалили файлы, поменяли местами и т. д.)

Не говоря уже о том, что свободное пространство не является смежным, оно часто разбросано по всему диску. Таким образом, вы не можете просто сказать «перезаписать вторую половину диска», потому что он заполнен только наполовину, потому что данные будут на всем диске.

Похожие вопросы