уничтожение данных
Здравствуйте, в Recuva после многократной перезаписи (35 раз) файлов, если попытаться найти удалённые файлы, всё равно видны их названия. Правда при восстановлении такого файла информация недоступна, но как сделать, чтобы и названия нельзя было увидеть? Может программу посоветуете.
Попробуйте BCWipe от Jetico, она затирает и названия файлов.
Пофайловое стирание в современных файловых системах и на современных носителях – ненадёжный метод уничтожения информации. Тогда уж нужно затирать весь носитель целиком.
В Unix программа shred вроде трёт и названия файлов, но вот с названиями директорий у неё какая-то беда.
Есть простая контрмера: создаёте шифрованный LVM-том (раздел) нужного небольшого размера и делаете его чистую копию на другой LVM-том (раздел). Когда надо затереть файлы, просто делаете luksClose, luksKillSlot и форматируете его заново, после чего восстанавливаете содержимое из чистой копии (бэкапа). Это быстрый и надёжный способ удаления файлов. А в других разделах исходите из того, что быстро затереть их нельзя. В общем, это скорее организационный вопрос.
спасибо, попробую BCWipe поскольку работаю под windows.
Очевидно удачный пример использования LVM-ов. Разве что пересоздавать файловую систему заново и заново переносить все файлы на чистую FS может занять заметное время.
Есть ещё всякие free-space-over-FS вайперы, наподобие secure-delete, но особого доверия к ним нет.
Поэтому нужно делать такие файловые системы компактными и хранить на них только то, что реально необходимо — например, логи и настроки IM. У меня примерно такая схема работает для юзера, из-под которого запускается TBB. На файловой системе ничего кроме нескольких конфигов и распакованного бандла TBB нет, всё распаковывается и зачищается за секунды, при этом можно быть уверенным, что всё временное и неважное, связанное с работой браузера в сети, надёжно зачищается.
С теми же целями (если данные нужны в пределах одного сеанса) можно использовать tmpfs, даже слоты в случае чего убивать не нужно.
Но swap лучше шифровать или отключать.
Можно, и это даёт ряд преимуществ, но менее гибко. Например, если у меня есть временный пул важных файлов, который я ещё не успел перенести на постоянный раздел, я буду расстроен, если они утеряются из-за внезапного зависания системы и перезагрузки. К тому же, иногда надо перезагрузиться, а времени скопировать файлы нет — в этом случае копирование можно отложить, если используется убивание слотов LUKS, но нельзя, если используется tmpfs.
Подтверждаю. + В тему этих[link2] комментариев[link3]: делаешь, как описано — df показывает всё равно наличие некоторого свободного места на файловой системе. Повторяешь с другим именем файла — и оно иногда уменьшается, иногда нет. Но факт, что второй файл создаётся, а также создаётся и третий и т.д. Где они создаются, если ФС уже забита? Значит, не всё забито, есть ещё место для хранения данных, есть какие-то резервы. И, вообще, в отличие от BSD, в Linux df показывает где-то на 5% меньше свободного места для ФС, чем есть на самом деле (Used+Avail≠Size в df).
Есть ещё такая параноическая мысль: в Unix используется корневая древовидная система для файлов. Когда в какой-то каталог монтируется внешняя иная файловая система с другого раздела, что происходит? Может ли так быть, что какие-то файловые структуры/метаданные из внутренней ФС могут переползти во внешнюю? Вроде это звучит глупо, тем более, что файловые системы могут быть вообще разными, но вот мало ли... Вдруг я чего-то не знаю? Скажем так, насколько такая изоляция данных (всё критичное подмонтировано с иных разделов, но на ту же корневую ФС) надёжна?
Зарезервировано для рута.
Для чистки дисков нужно использовать стандартную команду – Secure Erase. После неё заполнить устройство случайными данными, для неразличимости использумых участков от неиспользуемых. Эти два шага дают максимальную защиту, которая сейчас доступна. Все остальные способы небезопасны.
Спасибо за информацию. Теперь заодно понял, почему раньше ноль писалось, а потом перестало (ранее из-под рута тёр).
Вы про низкоуровневый доступ к SSD? Там с HPA[link4] что-то не очень вразумительное происходит.
А люди не верят[link5] в возможность надёжного частичного затирания данных на SSD, если вы об этом.
Ну, и, вообще, SSD — это отдельный вопрос.
К любому ATA-устройству. В HPA разве записываются пользовательские данные? Скорей всего нет, поэтому даже если Secure Erase его не затирает, в этом нет необходимости.
Про надёжность не говорилось. Перечислено то, что в любом случае необходимо сделать при уничтожении данных. А для обычных HDD-дисков можно утверждать что этого достаточно.
Как я понял из обсуждений, они туда могут попасть из-за wear leveling'а. Было много обсуждений на форуме про затирание данных на SSD и флэшках, и почти везде высказывались опасения, что в резервные блоки может попасть информация с пользовательскими данными, которая не будет затёрта традиционными средствами.
Со слов разработчика hdparm, Secure Erase по стандарту должен очищать всё доступное для записи место, включая HPA если существует. Хотя есть вероятность, что производитель реализовал эту команду по другому.