Временные отметки файлов

Временные отметки (ВО) обычно фиксируются в компьютерной памяти в виде 4-байтных полей, содержащих число секунд с новогодней полуночи 1970 года. В индексном дескрипторе файла сохраняются 4 временные отметки [6]:

· время C (Create) – время последнего изменения индексного дескриптора. Судя по справочным данным о системных вызовах (см. ниже), это значение обновляется при создании файла и записи в существующий файл, при изменении прав владения и доступа, а также изменении количества имен файла (прямых ссылок на inode). Для каталога и символической ссылки действуют эти же правила;

· время A (Access) – время последнего открытия файла. Как указано в [6], эта временная отметка обновляется при создании или чтении файла. Но по отношению к каталогам это не вполне верно. Время А также может обновляться или произвольно устанавливаться с помощью системного вызова utime();

· время M (Modify) – время последней модификации файла или каталога, хотя справедливее назвать его временем последнего сохранения файла. Время М устанавливается при создании файла и при записи в существующий файл или каталог, а также при повторной записи в файл прежних данных. Время М также может обновляться или произвольно устанавливаться с помощью системного вызова utime();

· время D (Delete) – время удаления файла (иначе – объявления его inode и занимаемого им дискового пространства свободными). В файловых системах еxt3fs и еxt4fs при удалении файла происходит стирание его индексного дескриптора, включая все временные отметки, поэтому использование этой временной отметки выглядит проблематично.

Работа системы с временными отметками файлов программно реализована на уровне системных вызовов. Системный вызов – это обращение прикладной программы к ядру операционной системы для выполнения какой-либо операции. Любая прикладная программа или системная утилита реализует низкоуровневый ввод-вывод путем вызова подпрограмм или функций из системной библиотеки.

Справочные данные о воздействии системных вызовов на временные отметки файлов сведены в табл. 4.5.

Таблица 4.5

Системный вызов	Временные отметки
C	M	A
creat() – создает новый или очищает существующий файл	+	+	+
read() – читает данные из файла в буфер памяти			+
write() – записывает данные из буфера памяти в файл	+	+
link() – создает еще одно имя для существующего файла	+
unlink() – удаляет одно из существующих имен файла	+
utime() – устанавливает времена доступа и модификации указанного файла	+	+	+

Таким образом, преобразование временных отметок файлов происходит по единым алгоритмам, что позволяет использовать ВО при расследовании компьютерных правонарушений в качестве юридических доказательств. И наоборот, временные отметки прошлого предполагается использовать как свидетельство ранее произведенных над файлами операций.

Многие сложные действия над файловыми объектами включают в себя несколько системных вызовов. Так, копирование файла из одного каталога в другой упрощенно представляет собой:

· открытие первого каталога в режиме чтения,

· открытие второго каталога в режиме записи,

· нахождение и чтение индексного дескриптора файла,

· чтение блоков копируемого файла в буфер памяти,

· создание во втором каталоге записи о новом файле,

· создание нового индексного дескриптора файла,

· выделение новому файлу необходимого количества блоков в новом месте,

· запись данных из буфера памяти в блоки нового файла,

· закрытие файлов и каталогов.

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

Быстродействие современных компьютерных систем позволяет выполнять основные файловые операции почти мгновенно. Если манипулировать файловыми объектами программно, то за секунду можно успеть изменить состояния и временные отметки у сотен файловых объектов. Но при участии пользователя процесс обновления временных отметок происходит гораздо медленнее. Сравнительно медленно может происходить копирование большого файла, копирование или перемещение группы файлов либо большого каталога.

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

В целях автоматизации процесса наблюдения за динамикой временных отсчетов файлов, а также для исключения ошибок, связанных с «ручными» операциями, автором было написано несколько сценариев, в которых использовались возможности системного вызова stat, а также системной утилиты с аналогичным именем. Вызов stat с именем файла возвращает метаданные этого файла, включая его временные отметки. При этом временные отметки промежуточных каталогов на пути к целевому файлу не искажаются. Утилита stat корректно работает с файловыми системами ext*fs, смонтированными в режиме read only.

Одна из составленных программ через фиксированные интервалы времени производит элементарные операции над файловыми объектами (ФО): создает несколько каталогов, помещает в них небольшие текстовые файлы, производит их чтение, дописывание и удаление, создает прямые и символические ссылки, изменяет права доступа к ФО, осуществляет копирование и перемещение файлов и др. После каждого действия программа выводит на экран или в файл информацию об изменившихся временных отметках ФО. Результаты работы сведены в табл. 4.6 и 4.7.

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

Таблица 4.6

№ п/п

Файловая операция

Временные отметки источника

Временные отметки приемника

Каталог

Файл

Каталог

Файл

С

М

А

С

М

А

С

М

А

С

М

А

Копирование файла обычное

Копирование с замещением файла

Копирование с переименованием файла

Перемещение файла

*

*

*

Создание прямой ссылки на файл

Создание символической ссылки на файл

Чтение файла через символическую ссылку

Запись файла через символическую ссылку

Запуск файла через символическую ссылку

Переход в другой каталог

В табл. 4.7 зафиксированы временные отметки, обновившиеся при одноместных операциях. Звездочки в ячейках временных отметок удаленного файла указывают на некорректность их задания.

Таблица 4.7

№ п/п	Файловая операция	Временные отметки
Каталог	Файл
С	М	А	С	М	А
	Создание каталога
	Создание файла
	Запись в файл
	Чтение файла
	Исполнение программного файла
	Удаление файла	*	*	*
	Изменение владельца файла
	Изменение прав доступа к файлу
	Переименование файла
	Поиск файла в каталоге
	Монтирование файловой системы к пустому каталогу
	Вход в каталог и выход из него

Проведенные наблюдения существенно дополняют и корректируют сведения о ВО файлов, приведенных Б. Кэрриэ [6]. Можно говорить о почти однозначном соответствии между комбинацией синхронно измененных ВО и произведенным действием над файлом. Таким образом, по временным отметкам файлов, каталогов и символических ссылок можно с высокой степенью достоверности реставрировать события прошлого. Более подробные сведения о ретроспективном анализе ВО файлов выходят за рамки данного учебного пособия.

Ранее упомянутая утилита touch с именем существующего файла предназначается для изменения временных меток A и M до текущего значения. Используя аргументы, этой же командой можно устанавливать для файла произвольные значения даты и времени модификации и последнего доступа. Такими возможностями может воспользоваться и нарушитель. Для изменения временных отметок файла нужно обладать правом записи в файл и правом исполнения в каталоге, где этот файл находится.

4.3. Алгоритмы логического удаления и восстановления файлов

Многие исследователи и опытные пользователи утверждают, что операционные системы клона Linux весьма надежны и успешно противостоят сбоям в работе. Тем не менее опасность потери файлов с ценной информацией является угрозой для любой системы. Чаще эти угрозы исходят не от операционной системы, а от пользователей. Для обычного пользователя, не имеющего доступа к элементам файловой системы, восстановление уничтоженной информации невозможно. Правда, графическая оболочка современных версий Linux предусматривает «корзину» для удаленных файлов.

Администратор имеет право использовать отладчики и редакторы файловой системы, но восстановление удаленных файлов требует хороших знаний о файловой системе и может потребовать немало времени.

Логическое удаление файла в Linux происходит тогда, когда из соответствующего каталога удаляется последнее имя (жесткая ссылка) файла. Кроме удаления записи в каталоге, система обнуляет биты, закрепленные за этим файлом в битовой карте блоков и индексных дескрипторов, увеличивая цифру свободных inode и блоков.

Удаление объектов файловой системы производится с помощью утилиты rm (remove). Ввод команды с опцией –f означает безусловное удаление файла, при указании -r происходит безусловное рекурсивное удаление каталога. При обычном удалении файла система выводит запрос на удаление, который необходимо подтвердить символом «Y» (Yes) и <Enter>.

Право на удаление файла в ОС Linux вообще не предусматривается. Для того чтобы удалить файл, пользователь должен иметь права на запись и исполнение в том каталоге, где удаляемый файл находится. На сам удаляемый файл пользователь может вообще не иметь никаких прав. В файловых системах Linux существует единственный каталог, в который имеет право записывать информацию любой пользователь, – это каталог /tmp. И любой пользователь прежде имел возможность в любой момент удалить из этого каталога любые файлы. Для предотвращения такой возможности уже давно используется специальный Sticky-бит, устанавливаемый на этот каталог. Так, права доступа к каталогу /tmp устанавливаются командой

chmod 1777 /tmp,

где первая единица в правах доступа обозначает Sticky-бит.

Права доступа к этому каталогу, отображаемые командой ls –l, будут отображаться так: drwxrwxrwt. Последний символ t как раз и указывает на наличие дополнительных прав (или ограничений) доступа. Но если задать права доступа к этому же каталогу в виде команды chmod 1776 /tmp, то отображаемые права доступа будут выглядеть уже так: drwxrwxrwT. Прописной символ T указывает на противоречие в предоставленных правах: Sticky -бит установлен, но прав на исполнение (поиск в каталоге) для всех пользователей не предоставлено. Это очевидная нелепость, оставшаяся в наследство от давно забытых решений: sticky -бит имеет смысл только при установленном для всех пользователей праве на запись в каталог. Если права записи нет, то и в дополнительном праве (точнее – в запрете) потребности не возникает.

Универсальные операционные системы семейств UNIX и Windows* по умолчанию не предусматривают физического удаления файлов. Для гарантированного стирания файлов пользователям рекомендуется использовать специальные утилиты, которые именуются шредерами (от англ. shred – кромсать, резать). Утилита с таким названием имеется в штатной инсталляции современных операционных систем Linux. Она многократно (по умолчанию 25 раз) перезаписывает 128-байтный фрагмент inode и каждый из выделенных файлу блоков данных. При удалении данных записываемые комбинации бит меняются случайным образом, чтобы каждый элементарный домен на поверхности диска многократно перемагничивался противоположно направленными силовыми линиями магнитного поля. Синтаксис команды shred приведен в кратком справочнике по командам Linux в прил. 1.

Процесс удаления файлов по-разному происходит в файловых системах ext2fs и ext3fs.

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

Восстановление удаленных файлов в файловых системах Linux затрудняется рядом обстоятельств. Файл, как известно, состоит из трех частей: совокупности имен или указателей на номер файла (индексный дескриптор), самого индексного дескриптора и определенного количества блоков. При создании файла системной функции creatе передаются символьное имя файла в файловой системе и устанавливаемые права доступа к нему. Система в соответствии с заложенным алгоритмом выделяет для этого имени свободный индексный дескриптор и минимально необходимое количество свободных блоков.

Прослеживается логическая цепочка: каждое из имен файлов содержит ссылку на номер индексного дескриптора, а inode в свою очередь ссылается на номера блоков данных. Но обратной связи не существует: в блоках данных отсутствует информация о том, какому файлу они принадлежат (если только файл не имеет собственной сложной структуры с дублирующей информацией), а в inode нет упоминания об именах файла. Удаление файла начинается с удаления его последнего имени, поэтому искать удаленный файл по его прежнему имени часто бессмысленно. Пример этого будет приведен ниже.

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

Проверить, как происходит создание и удаление файлов в файловых системах ext2fs и ext3fs,читателям предлагается, выполнив лабораторное задание № 3.

Механизм журнализации, реализованный в современных файловых системах Linux, а также кэширование дисковой памяти и отложенный характер записи на диск чрезвычайно затрудняют подобные наблюдения. Создание новых файлов, удаление существующих, использование освобожденных inode и логических блоков происходит иногда с заметной задержкой, и у исследователя может создаться впечатление, что никаких изменений в файловой системе не происходит.

Теперь рассмотрим, что происходит с данными каталога при удалении файла в файловой системе ext2fs. На рис. 4.15 изображен фрагмент логического блока с номером 0x00100203, содержащего каталог /home. В данном каталоге был удален файл с именем Pr_Linux.doc.

0x00203000 01 04 08 00 0C 00 01 02: 2E 00 00 00 02 00 00 00................

0x00203010 20 00 02 02 2E 2E 00 00: 65 0D 08 00 14 00 0C 01.......e.......

0x00203020 50 72 5F 4C 69 6E 75 78: 2E 64 6F 63 66 0D 08 00 Pr_Linux.docf...

0x00203030 14 00 09 01 72 69 73 5F: 66 73 74 61 62 00 00 00....ris_fstab...

0x00203040 67 0D 08 00 14 00 0B 01: 72 69 73 5F 66 64 69 73 g.......ris_fdis

0x00203050 6B 5F 6C 00 68 0D 08 00: 14 00 0A 01 72 69 73 5F k_l.h.......ris_

0x00203060 6C 73 5F 6C 69 31 00 00: 5A 07 08 00 18 00 0D 01 ls_li1..Z.......

0x00203070 72 69 73 5F 69 6E 6F 64: 65 5F 62 69 6E 00 00 00 ris_inode_bin...

0x00203080 6A 0D 08 00 18 00 0D 01: 72 69 73 5F 62 6C 6F 63 j.......ris_bloc

Рис. 4.15. Фрагмент дампа логического блока, содержащего каталог /home (до удаления файловой записи Pr_Linux.doc)

На рисунке 4.16 приведен тот же фрагмент логического блока каталога после удаления файловой записи. Необходимо отметить, что обновления информации об удалении файла на диске пришлось ожидать несколько десятков минут.

0x00203000 01 04 08 00 0C 00 01 02: 2E 00 00 00 02 00 00 00................

0x00203010 20 00 02 02 2E 2E 00 00: 7D 0D 08 00 14 00 02 01.......}.......

0x00203020 30 30 30 30 30 30 75 78: 2E 64 6F 63 66 0D 08 00 000000ux.docf...

0x00203030 14 00 09 01 72 69 73 5F: 66 73 74 61 62 00 00 00....ris_fstab...

0x00203040 67 0D 08 00 14 00 0B 01: 72 69 73 5F 66 64 69 73 g.......ris_fdis

0x00203050 6B 5F 6C 00 68 0D 08 00: 14 00 0A 01 72 69 73 5F k_l.h.......ris_

0x00203060 6C 73 5F 6C 69 31 00 00: 5A 07 08 00 18 00 0D 01 ls_li1..Z.......

0x00203070 72 69 73 5F 69 6E 6F 64: 65 5F 62 69 6E 00 00 00 ris_inode_bin...

0x00203080 6A 0D 08 00 18 00 0D 01: 72 69 73 5F 62 6C 6F 63 j.......ris_bloc

Рис. 4.16. Фрагмент дампа логического блока, содержащего каталог /home (после удаления файловой записи Pr_Linux.doc)

Рассмотрим содержание файловой записи до ее удаления (см.
рис. 4.15). Разбор строки будем производить в обратном порядке, начиная от имени Pr_Linux.doc. Байт, стоящий левее (01h), указывает, что перед нами обычный файл; стоящий перед ним (0Ch) определяет длину имени – 12 байтов (в этом нетрудно убедиться). Два байта, стоящие левее (00 14h), также безошибочно определяют длину записи – 20 байтов. Наконец, 4-байтная последовательность 00 08 0D 65h в десятичном представлении соответствует номеру inode = 527717, который был присвоен данному файлу при его создании или копировании.

Теперь посмотрим, что произошло с этой записью после логического удаления файла (см. рис. 4.16). Запись полностью не исчезла, от нее осталось окончание ux.doc (третья строка сверху). Первая часть имени файла заменена нулями, индексный дескриптор поменялся на 00 08 0D 7Dh =
= 527741, но проверка показывает, что такой inode ни одному файлу еще не выделялся. Длина записи и длина имени файла не соответствуют друг другу. Можно сделать вывод, что мы стали свидетелями не замены записей одного файла другим, а его затирания произвольным кодом. Вероятно, если имя файла имеет какую-то значимость, по имеющемуся остатку имя можно попытаться восстановить. Однако сказать, какому индексному дескриптору это имя соответствовало и, тем более, где располагаются блоки данных удаленного файла, невозможно.

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

Каталог /lost+found используется программами проверки целостности файловой системы. В этот каталог помещаются индексные дескрипторы, обозначенные в битовых картах inode как занятые, но не принадлежащие ни одному из файлов.

Операционная система Linux вне зависимости от используемых и монтируемых файловых систем заполняет неиспользуемые байты блоков нулями. Остаточные данные из удаленных файлов могут сохраняться в блоках, объявленных свободными, но еще не занятых новым файлом.

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

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

Во-первых, в файл текущего каталога (назовем его lsdel.out) выводятся номера всех удаленных inode на данном логическом разделе:

lsdel | debugfs /dev/hdc3 > lsdel.out

Затем, предполагая, что список удаленных inode, сформированный командой lsdel, находится в файле lsdel.out, можно сделать так:

cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > inodes

Новый файл с именем inodes содержит номера inode, подлежащих восстановлению, по одному в строке. Он используется в следующей команде:

sed 's/^.*$/stat <\0>/' inodes|debugfs /dev/hda5 > stats

результирующий файл stats содержит данные всех команд stat.

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

Для восстановления данных в файловой системе ext2fs нужно найти их метаданные и сделать так, чтобы они снова стали восприниматься операционной системой. Для этого существует два способа. Первый – изменить существующую файловую систему так, чтобы в удаленном inode был снят флаг удаления (число ссылок на индексный дескриптор и обнуление времени удаления файла), после чего довериться утилите автоматической проверки и восстановления файловой системы fsck. Другой способ, намного более безопасный, но медленный, – выяснить, где именно в разделе лежат данные, после чего записать их в новый файл в другой файловой системе.

Для реализации восстановления по первому варианту следует воспользоваться возможностями утилиты fsck (filesystem consistency check – проверка целостности файловой системы). Эта утилита способна в автоматическом режиме распознать следующие повреждения:

· индексные дескрипторы, на которые нет ссылок в каталогах либо содержащие большое число (более сотни) ссылок,

· блоки данных, поименованные в индексных дескрипторах, но обозначенные в битовой карте блоков как свободные,

· блоки данных, обозначенные в битовой карте блоков как занятые, но не числящиеся ни в одном индексном дескрипторе,

· блоки данных, на которые имеются ссылки в нескольких inode,

· каталоги, содержащие ссылки на индексные дескрипторы, значащиеся свободными.

При обнаружении файла, у которого нет имени (отсутствуют ссылки в каталогах), утилита помещает такой файл в каталог /lost+found, присваивая ему новое имя, совпадающее с именем индексного дескриптора. Здесь, кстати, таится еще одна угроза безопасности. Восстановленный файл не обязательно сохраняет свои прежние ограничения в доступе. По умолчанию утилита fsck присваивает «потерянным и найденным» файлам права rwxr-xr-x. Просматривать список файлов в этом каталоге рекомендуется с помощью команды

ls –lad ‘locate /lost+found’

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

Практические рекомендации по восстановлению удаленных и поврежденных файлов на логическом разделе Linux с файловой системой ext2fs сводятся к следующему:

1) логический раздел Linux с поврежденными или логически удаленными файлами не следует монтировать к дереву каталогов своей системы до ликвидации всех повреждений. В крайнем случае следует ограничиться монтированием «только для чтения»,

2) поиск удаленных файлов по их именам в ext2fs – занятие бесперспективное, поскольку имена файлов затираются в первую очередь. Искать следует удаленные индексные дескрипторы, т. е. inode с нулевым числом ссылок и установленной датой удаления. Inode сохраняют свою ценность до тех пор, пока содержат ссылки на номера блоков данных,

3) каждый найденный удаленный inode, если он содержит адреса блоков данных, следует модифицировать для дальнейшего использования. Модификацию можно провести с помощью отладчика debugfs. Для этого следует последовательно выполнить следующие команды (более подробное описание этих команд содержится в приложении):

· входим в командную среду отладчика

Дата добавления: 2015-03-31