Подготовка к вторжению с помощью mtree(1)


http://9737644.ru/ свой бизнес откываем бюро переводов.

Одна из самых больших неприятностей, которые могут произойти с системным администратором, это подозрение, что кто-то проник в его систему. Если вы вдруг обнаруживаете странные файлы в каталоге /tmp, дополнительные команды в /usr/local/sbin или просто появляется ощущение что «что-то не так», сразу возникает вопрос — а не проник ли кто-нибудь посторонний в систему. Самое отвратительное во всем этом, что нет способов доказать обратное. Грамотный взломщик может заменить системные исполняемые файлы своими версиями, чтобы иметь возможность производить действия, которые не регистрируются в системе, и затруднить возможность его обнаружения. Даже Шерлок Холмс с лупой в руках ничего не сможет обнаружить в вашей системе, если лупа предоставлена самим злоумышленником и имеет особенность скрывать его! У некоторых имеется даже взломанный системный компилятор, который позволяет добавлять во вновь создаваемые исполняемые файлы программный код, представляющий собой «черный ход» для умельца.* Хуже того, компьютеры способны творить самые фантастические вещи. Операционные системы имеют чрезвычайно сложное устройство, а приложения содержат ошибки. Возможно, тот самый файл в каталоге /tmp, что вызвал ваше беспокойство, это реакция вашего текстового редактора на ваши попытки слишком быстро нажимать клавиши, а возможно, след, оставленный злоумышленником.

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

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

Запуск mtree(1)

Следующая команда запускает утилиту mtree(1) для сбора информации в корневой файловой системе и сохраняет в файле контрольные суммы md5 и sha256 для последующего анализа:

Хотя mtree(1) можно использовать для сбора информации со всего сервера, тем не менее большинство предпочитают запускать утилиту для исследования одного раздела за раз, с помощью ключа (1). Нет смысла записывать контрольные суммы для файловых систем, содержимое которых меняется слишком часто, как например, разделов с базами данных. Флаги -ic (2) предписывают утилите mtree(1) выводить результаты на экран, с отступами для каждого следующего уровня вложенности в файловой системе. Такой формат соответствует структуре файлов в /etc/mtree. Ключ -K принимает несколько необязательных ключевых слов — в данном случае предписывается генерировать стандартные контрольные суммы (3), контрольные суммы md5 (4) и контрольные суммы sha256 (5). Ключ -p (6) указывает, какой раздел должен проверяться. Практически в каждом разделе имеются файлы или каталоги, которые изменяются регулярно и которые по этой причине проверять было бы нежелательно. С помощью ключа -X (7) можно указать файл, содержащий список каталогов, которые не должны проверяться. В заключение производится перенаправление вывода этой команды в файл /tmp/mtree.out (8).

Составление списка каталогов, которые не должны проверяться, может оказаться непростым делом. Обычно я не выполняю проверку содержимого каталогов /tmp и /var/tmp. Я могу указать оба каталога в одном и том же файле исключений. При использовании файла исключений, содержащем следующую строку, из проверки будет исключаться каталог tmp, находящийся в корне исследуемой файловой системы.

./tmp

Вообще говоря, злоумышленнику скорее потребуется подменить некоторые файлы в корневом разделе или в разделе /usr. Если ваш сервер выполняет функции веб-сервера, целью злоумышленника могут также стать CGI и РНР-приложения.

Вывод mtree(1): файл спецификации

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

/set type=file uid=0 gid=0 mode=0755 nlink=1 flags=none

mtree(1) выбирает эти значения по умолчанию на основе анализа файлов раздела. По умолчанию объектом файловой системы является файл, которым владеют UID 0 и GID 0, с правами доступа 0755, с одной жесткой ссылкой и без флагов файловой системы. Затем для каждого файла и каталога, присутствующего в файловой системе, создается отдельная запись. Ниже приводится пример записи для корневого каталога:

Это файл с именем . (точка) (1), или текущий каталог. Этот файл является каталогом (2) и имеет 24 жестких ссылки (3) на него. Размер файла каталога составляет 512 байтов (4), а последнее его изменение производилось в момент времени, отстоящем на 1 171 639 839.0 секунд от начала эпохи UNIX (5). Эпоха UNIX началась 1 января 1979 года.

Секунды от начала эпохи и реальные даты

У вас нет желания подсчитывать, сколько секунд прошло от начала эпохи UNIX? Чтобы преобразовать число секунд, прошедших от начала эпохи, в обычные дату и время, можно воспользоваться командой date -r число_секунд. Не забудьте при этом исключить завершающую пару символов .0, присутствующих в выводе mtree(1), — date(1) принимает только целые числа.

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

Здесь мы видим имя файла, права доступа, количество жестких ссылок, размер и время, однако, по сравнению с каталогом, здесь появилось несколько дополнительных элементов: контрольная сумма (1), контрольная сумма md5 (2) и контрольная сумма sha256 (3). Эти контрольные суммы вычисляются на основе содержимого файла. Хотя теоретически возможно, чтобы файл, подмененный злоумышленником, имел контрольную сумму, совпадающую с контрольной суммой оригинального файла, а специалисты в области криптографии ищут практические способы создания файлов, которые соответствовали бы произвольным контрольным суммам md5 и sha256, тем не менее крайне маловероятно, чтобы злоумышленнику удалось создать поддельный файл, который соответствовал бы сразу всем трем контрольным суммам, содержал «черный ход» и при этом продолжал выполнять привычные функции, чтобы владелец системы не сразу заметил подмену. К тому времени, когда такое станет возможным, у нас в арсенале появятся дополнительные алгоритмы вычисления контрольных сумм, способные противостоять методам, которые используются злоумышленниками, и нам останется лишь переключиться на них.

Сохранение файла спецификаций

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

Храните копию файла спецификаций в безопасном месте, предпочтительно на съемном носителе, например на дискете или на компакт-диске.

Реакция на вторжение

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

# mtree -f savedspec -f newspec > mtree.differences

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

sbin/conscontrol file

Файл /sbin/conscontrol не изменялся между двумя проверками. Ниже приводятся две строки, которые были получены для файла /sbin/devd:

Сравните старую (1) и новую (2) контрольные суммы файла /sbin/devd, а также размеры. Они совершенно разные. Что-то изменилось в двоичном файле devd(8). He торопитесь жать на кнопку с надписью «Караул», а начните задавать жесткие вопросы системным администраторам. Если вам не удастся получить вразумительный ответ, почему мог измениться двоичный файл, поищите резервную копию у себя на лентах.

Комментарии запрещены.