RTFM.WIKI

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Какие следы ты оставил после себя? ======

//Автор: (c)Крис Касперски ака мыщъх//

//Взято отсюда - [[http://www.insidepro.com/kk/217/217r.shtml]]//

===== Введение =====

Каждый из нас неоднократно испытывал потребность в удалении файлов (и папок) без возможности их дальнейшего восстановления. Компьютер помнит слишком много и доверять ему нельзя, особенно при работе на чужой машине (на которую, кстати говоря, довольно проблематично устанавливать дополнительный софт и приходится использовать то, что есть. Утилит, предназначенных для необратимого удаления файла, там, скорее всего, не окажется).

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

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

{{ :security:what_you_left_behind_1.jpg |}}

<WRAP centeralign>
Рисунок 1.
</WRAP>

===== Проблемы удаления или осколки файлов =====

Как известно, при удалении файла, операционная система не производит его физического удаления с диска, а всего лишь помечает файл как "удаленный", высвобождая принадлежащие ему кластеры и соответствующую файловую запись. Небольшой ликбез. Файловой записью называется специальная структура, описывающая атрибуты файла (имя, дата и время создания/последнего доступа/модификации), а также схему размещения кластеров на диске. Кластером называют группу смежных секторов, с которой файловая система оперирует как с единым целым, то есть, если кластер заполнен хотя бы на один байт, он считается заполненным целиком. Сектором же, в свою очередь, называют минимальную порцию информации, с которой жесткий диск оперирует как с единым целым.

{{ :security:what_you_left_behind_2.gif |}}

<WRAP centeralign>
Рисунок 2.
</WRAP>

Файловая система NTFS (поддерживаемая Windows NT/2000/XP) позволяет устанавливать размер кластера в 512 байт, что соответствует длине сектора. При этом потери дискового пространства в незаполненных "хвостах" кластеров сводятся к минимуму, но вместе с тем растет фрагментация, вызывающая значительное падение производительности. Файловые системы UNIX'а в этом смысле намного более продвинуты и активно используют деление кластера на зоны, убивая одним выстрелом двух зайцев - уменьшая фрагментацию и сокращая потери дискового пространства.

Впрочем, мы отвлеклись. Вернемся к нашим баранам. После удаления файла принадлежащие ему кластеры возвращаются в пул свободного пространства, откуда его черпают вновь создаваемые и увеличивающиеся в размерах файлы, постепенно затирающие содержимое своих "предшественников", однако стратегия выделения свободного пространства построена так, что удаленный файл может "валяться" на диске годами. Даже если до отказа забить диск всяким stuff'ом (типа .mp3 или .avi) это все равно не гарантирует полного затирания удаленного файла. Почему?! Да потому, что если размер записываемого файла не кратен длине одного кластера, "хвост" кластера остается незатертым! Конечно, крошечный "обрывок" файла - это еще не весь файл, но иногда хватает и его (особенно, если он содержит номера телефонов, банковских счетов, и т.д.)

Утилиты, предназначенные для необратимого удаления файлов (с общим названием "шредеры" от английского "shredding" - резанье, кромсание), в большинстве своем анализируют файловую запись, находят кластеры, принадлежащие удаляемому файлу, и многократно перезаписывают их на секторном уровне специальными последовательностями байт, максимально затрудняющих восстановление данных. Необходимость (и целесообразность) многократной перезаписи мы рассмотрим ниже, а сейчас обратим внимание на то, что операционные системы семейства NT/UNIX предоставляют доступ к диску на секторном уровне только администраторам. Это ограничение можно обойти, установив специальный драйвер (например, ASPI32 от компании Adaptec), но установка драйвера также требует прав администратора и на чужом компьютере выполнить ее, скорее всего, не удастся.

Хуже того, работа с диском на секторном уровне требует хорошего знания всех особенностей файловой системы, которая меняется от версии к версии, в результате чего существует риск потери всего дискового тома, превращающий шредеры в потенциальные диск-дестройеры! Ну, и кому такое удаление нужно?!

К тому же, шредеры обычно не обращают внимания на файловую запись, оставляя нетронутыми имя файла, его длину, дату создания/модификации/последнего обращения и прочие атрибуты, раскрытие которых может иметь далеко идущие последствия, особенно если файл назывался "12-yo-asian-gal-fucked-by-black-rapists.avi". Еще один тонкий момент. Файловая система NTFS поддерживает два типа файлов: резидентные и нерезидентные. Нерезидентные хранятся в кластерах на диске (и таких файлов большинство), резидентные - размещаются прямо внутри файловой записи, что ускоряет доступ к файлу, но при этом размер файла не должен превышать размер "хвоста" файловой записи, обычно составляющий 1-2 Килобайт. Причем, если файл был "рождается" как резидентный, а затем увеличивает свою длину, файловая система превращает его в нерезидентный, но не удосуживается подчистить резидентную копию, которая останется "болтаться" в файловой записи даже после ее удаления. Естественно, файловые записи, принадлежащие удаленным файлам, освобождаются, повторно используясь при создании новых файлов, но(!) если данная файловая запись, содержащая незатертую копию резидентного файла, выделяется нерезидентному файлу, резидентная копия остается в целости и сохранности!

Вот, оказывается, какое непростое дело - удаление файлов. На самом деле, если закинуться правильными грибами типа Amanita muscaria и как следует обкурить данный вопрос, расширив свое сознание до границ адресного пространства 64-разрядных процессоров, станет ясно, что спускаться на секторный уровень совершенно необязательно и того же самого эффекта можно добиться путем перезаписывания файлов через стандартные функции ввода/вывода. Достоинства этого подхода в том, что он работает с любой файловой системой, не требует наличия прав администратора, абсолютно безопасен в плане разрушения дискового тома и т.д. и т.п.

Главное - не забывать о файловых атрибутах и после затирания файла нулями переименовать его в случайное имя максимально возможной длинны (для Windows - это 256 символов вместе с путем), чтобы гарантированно затереть "хвост" старого, затем усечь длину файла до нуля, закрыть его. Открыть, записав 512 байт нулей (для затирания резидентной) части и вновь закрыть. Открыть, дописать еще 512 байт, и делать так 6 раз, пока файл гарантированно не превратиться в резидентный, после чего его можно смело удалять. Пусть теперь кто-то попытается восстановить хотя бы кусочек данных!!! И ведь восстановит, гад! А все потому...

А все потому, что мы совершенно забыли о копиях файла, которые создают многие программы как в текущем каталоге, так и в каталогах, обозначенных в переменных окружения TEMP/TMP. Также, если за время своего существования файл менял размер, то увеличиваясь, то сокращаясь, на диске останется множество "следов", которые при затирании файла останутся нетронутыми! Дефрагментаторы, перемещая файл с одно места на другое, могут оставлять множество "осколков", зачастую расположенных весьма упорядоченным образом (очень часто дефрагментатор сначала "собирает" файл по кусочкам в свободном месте, а затем копирует его на новое место обитания).

Избавиться же от "осколков" очень сложно. Забивание диска файлами, с размером кратным 512 байт (чтобы гарантированно затереть все хвосты секторов) не только трудоемко, но еще и нецелесообразно. При форматировании дискового тома, файловая система NTFS резервирует для $MTF-файла (скрытый служебный файл, предназначенный для хранения файловых записей) 10% от его объема, что делается для предотвращения фрагментации $MFT-файла, однако по мере исчерпания свободного пространства, половина оставшегося резерва высвобождается в пул "общего пользования". Затем (при нехватке пространства) - еще половина. И так продолжается до тех пор, пока резерв полностью не истощается. Ок, диск до отказа забит файлами, что происходит после их удалении? А то, что резерв не пополняется, $MFT файл оказывается фрагментирован и при дальнейшем использовании диска эта фрагментация будет неуклонно нарастать, вызывая существенное падение производительности. То есть, **//если NTFS-том хотя бы однажды был заполнен более, чем на 90%, $MFT файл с высокой степенью вероятности фрагментирован//**, причем ни один известный мыщъх'у дефрагментатор не может собрать его по частям в единое целое (O&O Defrag Pro утверждает, что умеет это делать, но со своей работой не справляется).

{{ :security:what_you_left_behind_3.jpg |}}

<WRAP centeralign>
Рисунок 3.
</WRAP>

Таким образом, для сохранения прежней производительности следует всегда оставлять по крайней мере 10% от емкости NTFS-тома. С другой стороны, если диск никогда не заполнялся более чем на 90%, то в зарезервированной под $MFT области никаких "осколков" удаляемого файла заведомо не окажется! Но, чтобы удалить файл наверняка, диск все-таки приходится заполнять до отказа. Иначе - нельзя. Как же тогда бороться с фрагментацией?! Нет ничего проще! Создаем огромное количество (несколько тысяч и больше) файлов нулевого размера, для хранения каждого из которых расходуется одна файловая запись, хранящая в $MFT. Затем забиваем диск до отказа файлами, размер которых кратен 512 байтам и превышает 4 Кбайт, чтобы они не оказались резидентными. Дождавшись исчерпания дискового пространства, удаляем все файлы, освобождая принадлежащие им записи в $MFT. Другими словами, создание файлов нулевой длины увеличивает размер $MFT-файла до его фрагментации, а поскольку при удалении файлов усечения размеров $MFT не происходит, он остается нефрагментированным, если, конечно, не был уже фрагментирован ранее.

Кстати говоря, на языке Си несложно написать программу, открывающую файл на запись и позиционирующую указатель на величину, равную размеру свободного пространства. Теперь, если закрыть файл, мы сможем прочитать все, что находилось на диске (в том числе и содержимое ранее удаленных файлов!). Хороший трюк для похищения конфиденциальной информации с чужих компьютеров, не правда ли? Особенно в свете того, что он не требует прав администратора и работает с любой операционной системой - будь то Linux, Windows или BSD. Соответственно, если забить этот файл нулями, мы очистим все дисковое пространство. Ну, или практически. Останутся только "хвосты" кластеров, принадлежащие еще неударенным файлам и резидентные копии внутри $MFT. К сожалению, на прикладном уровне их удалить невозможно, но ведь не спускаться же на уровень голых секторов?!

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

===== Практические советы по удалению файлов =====

Ладно, оставим теорию и перейдем к практике. В FAR'е для необратимого удаления файлов достаточно нажать <ALT-DEL>, при этом FAR забьет файл нулями, после чего переименует его в случайно сгенерированное имя, усечет длину для нуля и благополучно удалит его с диска. В большинстве случаев этого более чем достаточно, однако следует помнить, что на диске могут оставаться неудаленные копии файла и для надежности желательно забить все свободное пространство по методике, описанной выше.

{{ :security:what_you_left_behind_4.jpg |}}

<WRAP centeralign>
Рисунок 4. Затирание файла по <ALT-DEL> в FAR'е.
</WRAP>

Полная дефрагментация также затирает все неудаленные копии, однако тот дефрагментатор, что входит в штатный комплект поставки Windows 2000/XP, для этой цели категорически не годится, поскольку дефрагментирует лишь наиболее фрагментированные файлы и не изменяет положения остальных. Дефрагментор O&O Defrag Pro поддерживает несколько стратегий дефрагментации, позволяя упорядочивать файлы по дате, типу или времени последнего доступа. Достаточно очевидно, что если мы сначала выберем стратегию упорядочивания файлов по типу/имени, а следом за ней - по времени доступа, то дефрагментатор совершит множество перемещений файлов, в результате чего все "осколки" ранее удаленных файлов с высокой степенью вероятности окажутся затертыми. И хотя некоторый шанс на их восстановление все-таки есть, в обыденной жизни им можно пренебречь.

{{ :security:what_you_left_behind_5.jpg |}}

<WRAP centeralign>
Рисунок 5. Отклонения траектории головки записи от центра дорожки.
</WRAP>

Также полезно держать "секретные" файлы в сжатом состоянии (файл -> свойства -> атрибуты -> другие -> сжимать содержимое для экономии места на диске). Это сделает невозможным прямой секторный поиск "осколков" файла по его содержимому. С другой стороны, при затирании сжатого файла нулями, реально затирается лишь небольшая часть, поскольку нули очень хорошо сжимаются, так что прежде чем нажимать <Alt-Del> в FAR'е, следует обязательно сбросить атрибут сжатия.

{{ :security:what_you_left_behind_6.jpg |}}

<WRAP centeralign>
Рисунок 6.
</WRAP>

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

Где еще могут храниться удаленные файлы? Прежде всего, в файле подкачки. Ведь при любом действии с файлом (открытие/копирование) он загружается в оперативную память, а оттуда с некоторой вероятностью попадает в файл подкачки, который закрыт для записи даже администратору (но, загрузившись с другого носителя, мы можем нажать <ALT-DEL> в FAR'е, удалив файл на хрен. Не стоит волноваться - при следующей загрузке операционная система его создаст заново. Также можно запустить "прожорливое" приложение, поглощающее всю свободную память).

{{ :security:what_you_left_behind_7.jpg |}}

<WRAP centeralign>
Рисунок 7.
</WRAP>

Папка "Recent" в "Documents and Settings" хранит имена последних открываемых документов и хранит она их много. Аналогичным образом поступает и FAR, сохраняя список последних копируемых файлов в реестре, в ветке FAR. Конечно, имена файлов - это еще не сами файлы, однако в некоторых случаях знания имени файла вполне достаточно если не для вынесения приговора, то для порчи репутации.

{{ :security:what_you_left_behind_8.jpg |}}

<WRAP centeralign>
Рисунок 8.
</WRAP>

===== Обзор шредеров =====

==== Acronis Privacy Expert Suite 9.0 ====
продвинутый коммерческий шредер, работающий на секторном уровне и поддерживающий практически все системы линейки Windows. Имеет богатый ассортимент методов необратимого удаления данных, реализуя следующие национальны стандарты: DoD 5220.22-M, NAVSO P-5239-26/RLL, NAVSO P-5239-26/MFM (американские), VSITR (немецкий), ГОСТ P 50739-95 (отечественный), а также ряд нестандартных алгоритмов: метод Питера Гутмана (35 проходов), метод Брюса Шнайера (7 проходов), а так же некий "простой, но эффективный в большинстве случаев Быстрый метод". Ни в одном из этих методов очистка файловых записей в $MFT и подчистка кластерных "хвостов" не выполняется и возникает дурацкий вопрос - какого черта елозить головкой целых 35 проходов, когда рядом лежат нетронутые "осколки" неудаленных данных?! К тому же, Acronis печально известен своими конфликтами как с программным, там и с аппаратным обеспечением и потому может быть рекомендован только врагу, купившему его прямо у разработчиков: http://www.antivir.ru/main.phtml?/products/products_home/acronis_priv;

==== RedBut ====

условно-бесплатная программа, представляющая собой довольно навороченное средство для предотвращения утечек информации и умеющая (в том числе) необратимо удалять файлы, если, конечно, верить разработчикам. Однако о полной очистке дискового пространства от возможных "осколков" RedBut не заботится, а потому восстановление информации оказывается не только "возможным", но и тривиальным. Достаточно запустить любой дисковый редактор и - вперед! Желающие познакомится с этим "добром" могут посетить сайт: http://liepass.com.ru/download.htm, заплатить $20 за "офисную" версию или 140$ за "профессиональную", получив в результате ту же самую надежность, которую дает бесплатный (для граждан СНГ) FAR по <Alt-Del>.

==== BCWipe ====

от компании Jetico (http://www.jetico.com/) - довольно известная утилита, выпущенная для всего зоопарка операционных систем, начиная от древней Windows 3.1 и заканчивая Linux. BCWipe придерживается американского стандарта DoD 5200.28-STD, однако чисткой "хвостов" не занимается со всеми вытекающими отсюда последствиями.

===== Заключение =====

Мыщъх'у не известен ни один готовый шредер, удаляющий файлы без возможности их полного или частичного восстановления за разумное время и при наличии доступных программных средств типа дискового редактора. Невероятно, но факт (а факты - вещь упрямая)! Тем не менее, эту операцию легко осуществить по вышеописанной методике своими собственными руками и хвостом. Мыщхъ подчеркивает еще раз - проблема необратимого удаления файлов чаще всего встает при работе на чужом компьютере, на котором у нас нет ни прав администратора, ни возможности устанавливать какое бы то ни было программное обеспечение. Так что, хвост рулит. А лапы тем временем забивают вот такооооой косяк!

===== Искусство затирания =====

Интуиция подсказывает: чем больше раз перезаписано содержимое сектора, тем труднее его восстанавливать.

Согласно стандарту 5220.22 (http://en.wikipedia.org/wiki/DOD_5220.22-M), подготовленного Министерством обороны США (United States Department of Defense), удаляемый файл должен быть перезаписан, по меньшей мере, трижды, в противном случае данные могут быть восстановлены за счет "остаточного" намагничивания и "вихляниям" магнитной головки вдоль дорожки.

{{ :security:what_you_left_behind_9.jpg |}}

<WRAP centeralign>
Рисунок 9. Отклонения траектории головки записи от центра дорожки.
</WRAP>

В народе ходят легенды о существовании аппаратуры, восстанавливающей файлы даже после нескольких циклов перезаписи, однако неизвестно ни одного прецедента восстановления файла по остаточной намагниченности. Теоретически такая операция может быть осуществлена с помощью сканирующего зондового микроскопа (процесс работы которого подробно описан в статье "Методы сканирующей зондовой микроскопии для исследования поверхностей накопителей информации и восстановления данных" - http://www.epos.kiev.ua/pubs/spm.htm), однако учитывая плотность записи современных носителей, "выудить" полезную информацию таким образом невозможно. Сканирующий микроскоп - это что! К нему еще потребуется прикрутить анализатор прочитанной информации, учитывающий систему модуляции конкретной модели жесткого диска, алгоритм кодирования битов, механизм трансляции секторов и кучу всего...

Возможно, Министерство Обороны США и располагает подобной техникой (хоть это и маловероятно), тщательно скрывая ее существование от народа, но на местном уровне восстановление данных даже после однократной перезаписи невозможно! Однозначно! За это не возьмется ни одна фирма, специализирующаяся на спасении информации. Исключения составляют случаи, когда данные "вытягиваются" из не затертых копий файлов, разбросанных по всему дисковому пространству, но к остаточному намагничиванию эта тема никакого отношения не имеет, поэтому будем считать, что вопрос о количестве циклов перезаписи закрыт раз и навсегда. **Однократной перезаписи вполне достаточно!**