О документе
RFC3227/part-001 — от начала документа до заголовка раздела «5 Tools you'll need» включительно.
Рабочая группа Network Working Group D. Brezinski
Запрос комментариев: 3227 In-Q-Tel
BCP: 55 T. Killalea
Категория: Лучшая современная практика neart.org
Февраль 2002
Руководство по сбору и архивированию доказательств
1 Введение
«Инцидент безопасности», как он определён в [RFC2828], представляет
собой значимое с точки зрения безопасности системное событие, при
котором политика безопасности системы не соблюдается либо иным образом
нарушается. Цель настоящего документа — предоставить системным
администраторам рекомендации по сбору и архивированию доказательств,
относящихся к такому инциденту безопасности. Мы не намерены настаивать
на том, чтобы все системные администраторы неукоснительно следовали
этим рекомендациям при каждом инциденте безопасности. Напротив, мы
хотим дать рекомендации о том, что им следует делать, если они решат
собирать и защищать информацию, относящуюся к проникновению.
Такой сбор требует значительных усилий со стороны системного
администратора. В последние годы достигнут большой прогресс в ускорении
переустановки операционной системы и в облегчении возврата системы в
«известное» состояние, что делает «лёгкий вариант» ещё привлекательнее.
Тем временем для предоставления простых способов архивирования
доказательств (сложного варианта) сделано мало. Кроме того, увеличение
ёмкости дисков и памяти, а также более широкое применение атакующими
тактик скрытности и заметания следов усугубили проблему.
Если сбор доказательств выполнен правильно, они значительно полезнее
для задержания атакующего и имеют гораздо больше шансов быть признанными
допустимыми в случае судебного преследования.
Вам следует использовать эти рекомендации как основу для разработки
процедур сбора доказательств на вашем объекте и включить процедуры
вашего объекта в документацию по обработке инцидентов. Рекомендации в
настоящем документе могут не быть применимы во всех юрисдикциях. После
разработки процедур сбора доказательств на вашем объекте вам следует
получить от правоохранительных органов вашей юрисдикции подтверждение
их достаточности.
1.1 Соглашения, используемые в настоящем документе
Ключевые слова «ОБЯЗАТЕЛЬНО (REQUIRED)», «ДОЛЖЕН (MUST)», «НЕ ДОЛЖЕН
(MUST NOT)», «СЛЕДУЕТ (SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)» и «МОЖЕТ
(MAY)» в настоящем документе следует толковать так, как описано в
«Key words for use in RFCs to Indicate Requirement Levels» [RFC2119].
2 Руководящие принципы при сборе доказательств
- Соблюдайте политику безопасности вашего объекта и привлекайте
соответствующий персонал по обработке инцидентов и
правоохранительных органов.
- Зафиксируйте настолько точную картину системы, насколько это
возможно.
- Ведите подробные записи. В них следует включать даты и время.
Если возможно, создавайте автоматическую стенограмму. (Например,
в системах Unix может использоваться программа «script», однако
создаваемый ею выходной файл не следует размещать на носителе,
являющемся частью доказательств.) Записи и распечатки следует
подписывать и датировать.
- Отмечайте разницу между системными часами и UTC. Для каждой
предоставленной временной метки указывайте, используется ли UTC
или местное время.
- Будьте готовы дать показания (возможно, спустя годы), изложив
все предпринятые вами действия и время их выполнения. Подробные
записи будут жизненно важны.
- Минимизируйте изменения данных в ходе их сбора. Это не ограничено
изменениями содержимого; вам следует избегать обновления времени
доступа к файлам или каталогам.
- Устраните внешние пути внесения изменений.
- Столкнувшись с выбором между сбором и анализом, вам следует
сначала выполнить сбор, а анализ — позднее.
- Хотя это едва ли нуждается в упоминании, ваши процедуры следует
делать реализуемыми. Как и любой аспект политики реагирования на
инциденты, процедуры следует тестировать для обеспечения
осуществимости, особенно во время кризиса. Если возможно,
процедуры следует автоматизировать по причинам скорости и
точности. Действуйте методично.
- Для каждого устройства следует применять методичный подход,
следующий рекомендациям, установленным вашей процедурой сбора.
Скорость часто будет критичной, поэтому, если имеется несколько
устройств, требующих обследования, может быть уместно распределить
работу между членами команды для параллельного сбора доказательств.
Однако в одной конкретной системе сбор следует выполнять шаг за
шагом.
- Переходите от более изменчивого к менее изменчивому (см. ниже
порядок изменчивости).
- Вам следует создать побитовую копию носителей системы. Если вы
хотите выполнить криминалистический анализ, вам следует для этой
цели создать побитовую копию вашей копии доказательств, поскольку
ваш анализ почти наверняка изменит время доступа к файлам.
Избегайте выполнения криминалистического анализа на копии
доказательств.
2.1 Порядок изменчивости
При сборе доказательств вам следует переходить от более изменчивого к
менее изменчивому. Ниже приведён пример порядка изменчивости для типичной
системы.
- регистры, кэш
- таблица маршрутизации, ARP-кэш, таблица процессов, статистика
ядра, память
- временные файловые системы
- диск
- данные удалённого журналирования и мониторинга, относящиеся к
рассматриваемой системе
- физическая конфигурация, топология сети
- архивные носители
2.2 Чего следует избегать
Слишком легко уничтожить доказательства, пусть и непреднамеренно.
- Не выключайте систему, пока не завершите сбор доказательств.
Многие доказательства могут быть утрачены, а атакующий мог
изменить сценарии/службы запуска и выключения, чтобы уничтожить
доказательства.
- Не доверяйте программам в системе. Запускайте программы сбора
доказательств с надлежащим образом защищённого носителя (см.
ниже).
- Не запускайте программы, изменяющие время доступа ко всем файлам
в системе (например, «tar» или «xcopy»).
- Устраняя внешние пути внесения изменений, учитывайте, что одно
лишь отключение от сети или фильтрация сетевого трафика могут
активировать «deadman switches», которые обнаруживают отключение
от сети и стирают доказательства.
2.3 Соображения конфиденциальности
- Соблюдайте правила и рекомендации вашей компании и вашей правовой
юрисдикции в отношении конфиденциальности. В частности, убедитесь,
что никакая информация, собранная вместе с разыскиваемыми вами
доказательствами, не доступна никому, кто обычно не имел бы
доступа к этой информации. Это включает доступ к файлам журналов
(которые могут раскрывать модели поведения пользователей), а также
к файлам персональных данных.
- Не вторгайтесь в частную жизнь людей без веского обоснования. В
частности, не собирайте информацию из областей, к которым у вас
обычно нет оснований получать доступ (таких как личные файловые
хранилища), если у вас нет достаточных признаков существования
реального инцидента.
- Убедитесь, что предпринимаемые вами шаги по сбору доказательств
инцидента опираются на установленные процедуры вашей компании.
2.4 Правовые соображения
Компьютерные доказательства должны быть
- Допустимыми: они должны соответствовать определённым правовым
правилам, прежде чем их можно будет представить суду.
- Аутентичными: должна быть возможность однозначно связать
доказательственный материал с инцидентом.
- Полными: они должны излагать всю историю, а не только определённую
точку зрения.
- Надёжными: в способе сбора доказательств и последующего обращения
с ними не должно быть ничего, что вызывало бы сомнения в их
аутентичности и достоверности.
- Убедительными: они должны быть легко убедительными и понятными
для суда.
3 Процедура сбора
Ваши процедуры сбора следует делать настолько подробными, насколько это
возможно. Как и общие процедуры обработки инцидентов, их следует
формулировать недвусмысленно и сводить к минимуму объём принятия решений,
необходимого в процессе сбора.
3.1 Прозрачность
Методы, используемые для сбора доказательств, следует делать прозрачными
и воспроизводимыми. Вам следует быть готовыми точно воспроизвести
использованные вами методы и обеспечить их проверку независимыми
экспертами.
3.2 Шаги сбора
- Где находятся доказательства? Перечислите, какие системы были
вовлечены в инцидент и из каких будет собираться доказательственная
информация.
- Установите, что, вероятно, имеет отношение к делу и будет
допустимым. В случае сомнения склоняйтесь к сбору слишком большого,
а не недостаточного объёма данных.
- Для каждой системы определите соответствующий порядок
изменчивости.
- Устраните внешние пути внесения изменений.
- Следуя порядку изменчивости, соберите доказательства инструментами,
рассмотренными в разделе 5.
- Зафиксируйте величину ухода системных часов.
- По мере выполнения шагов сбора задавайтесь вопросом, что ещё может
быть доказательством.
- Документируйте каждый шаг.
- Не забывайте о вовлечённых людях. Записывайте, кто присутствовал и
что делал, что наблюдал и как реагировал.
Там, где это осуществимо, вам следует рассмотреть вычисление контрольных
сумм и криптографическое подписание собранных доказательств, поскольку
это может облегчить сохранение надёжной цепочки доказательств. При этом
вы не должны изменять доказательства.
4 Процедура архивирования
Доказательства необходимо строго защитить. Кроме того, цепочку хранения
необходимо чётко документировать.
4.1 Цепочка хранения
Вам следует быть способными чётко описать, как были обнаружены
доказательства, как с ними обращались и всё, что с ними происходило.
Необходимо документировать следующее:
- Где, когда и кем были обнаружены и собраны доказательства.
- Где, когда и кем с доказательствами обращались или их исследовали.
- Кто осуществлял хранение доказательств и в течение какого периода.
Как они хранились.
- Когда доказательства передавались на хранение другому лицу, когда
и как происходила передача (включая номера отправлений и т. п.).
4.2 Где и как архивировать
Если возможно, для архивирования следует использовать широко
распространённые носители (а не какие-либо малоизвестные носители
хранения).
Доступ к доказательствам следует крайне ограничить и чётко
документировать. Следует иметь возможность обнаруживать
несанкционированный доступ.
5 Необходимые инструменты
Вам следует иметь программы, необходимые для сбора доказательств и
криминалистического анализа, на носителе, доступном только для чтения
(например, на CD). Вам следует заранее подготовить такой набор
инструментов для каждой из управляемых вами операционных систем, до
того как потребуется его использовать.
В ваш набор инструментов следует включить следующее:
- программу для исследования процессов (например, 'ps').
- программы для исследования состояния системы (например, 'showrev',
'ifconfig', 'netstat', 'arp').
- программу для создания побитовых копий (например, 'dd', 'SafeBack').
- программы для создания контрольных сумм и подписей (например,
'sha1sum', 'dd' с поддержкой контрольных сумм, 'SafeBack', 'pgp').
- программы для создания дампов памяти (core images) и их исследования
(например, 'gcore', 'gdb').
- сценарии для автоматизации сбора доказательств (например, The Coroner's
Toolkit [FAR1999]).
Программы в вашем наборе инструментов следует статически скомпоновать;
им не следует требовать использования каких-либо библиотек, кроме тех,
которые находятся на носителе, доступном только для чтения. Даже в этом
случае, поскольку современные руткиты могут устанавливаться через
загружаемые модули ядра, вам следует учитывать, что ваши инструменты
могут не давать полной картины состояния системы.
Вам следует быть готовыми свидетельствовать о подлинности и надёжности
используемых вами инструментов.
6 Ссылки
[FAR1999] Farmer, D., and W Venema, "Computer Forensics Analysis
Class Handouts", http://www.fish.com/forensics/
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer
Security Incident Response", FYI 8, RFC 2350, June 1998.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC
2828, May 2000.
7 Благодарности
Мы с благодарностью отмечаем конструктивные комментарии, полученные от
Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox,
Andrew Rees, Steve Romig и Floyd Short.
8 Вопросы безопасности
Весь этот документ рассматривает вопросы безопасности.
9 Адреса авторов
Dominique Brezinski
In-Q-Tel
1000 Wilson Blvd., Ste. 2900
Arlington, VA 22209
USA
EMail: dbrezinski@In-Q-Tel.org
Tom Killalea
Lisi/n na Bro/n
Be/al A/tha na Muice
Co. Mhaigh Eo
IRELAND
Phone: +1 206 266-2196
EMail: tomk@neart.org
10. Полное заявление об авторских правах
Copyright (C) The Internet Society (2002). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, содержащие комментарии к нему,
иным образом объясняющие его или содействующие его реализации, могут
создаваться, копироваться, публиковаться и распространяться полностью
или частично без каких-либо ограничений при условии, что приведённое
выше уведомление об авторских правах и этот абзац включены во все такие
копии и производные работы. Однако сам этот документ не может быть
каким-либо образом изменён, например путём удаления уведомления об
авторских правах или ссылок на Internet Society либо другие организации
Интернета, за исключением случаев, когда это необходимо для разработки
стандартов Интернета, при которой должны соблюдаться процедуры,
определённые в процессе стандартизации Интернета в отношении авторских
прав, или когда это требуется для его перевода на языки, отличные от
английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не
будут отозваны Internet Society либо её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на основе
"КАК ЕСТЬ", И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО
ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ
ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ЛИБО ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ
КОММЕРЧЕСКОЙ ЦЕННОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.