Информационная безопасность » Наиболее распространенные классы удаленных атак

Атаки на клиентов: ActiveX, Java и другие

admin — Mon, 06 Oct 2008 07:17:42 +0000

При взаимодействии клиента и Веб-сервера возможен запуск кода и на клиентской стороне; наиболее популярные технологии на сегодняшний день, это Java Virtual Machine и ActiveX. Необходимо сразу осознать, что загружаемый с удаленного сервера код — это набор команд, которые ваш хост (компьютер) будет исполнять, возможно, не информируя вас о результатах. Поэтому и относиться к такому коду следует соответственно. Возможно, мы загружаем этот код с доверенного сервера, но что мы можем, знать о его безопасности? Достаточно ли уверенности, что механизм электронно-цифровой подписи сообщил нам, что код не был модифицирован после того, как его разместил на сервере уполномоченный программист? Возможно, мы считаем, что настройка прав такова, что данный код не сможет получить большие привилегии?
Прежде всего необходимо определиться, что мы хотим от данного кода? Большая часть такого кода в Интернете предназначена для визуализации или озвучивания красивых, в значительной степени рекламных, эффектов при посещении данного сайта. Поэтому необходимо разделять следующее.
□ С какого компьютера (хоста) мы сейчас работаем? Это компьютер в Интернет-кафе, обычная пользовательская рабочая станция или компьютер, выполняющий важную роль в сети либо хранящий конфиденциальную информацию?
□ Что мы делаем? Либо это просто просмотр новых сайтов для удовольствия, либо поиск необходимой информации в Интернете, либо работа с функциональностью удаленного сервера?
Соответственно этому будут актуальны и разные варианты ответов на вопрос о том, что можно позволить загружаемой программе на нашем компьютере. При развлечении на временном, общедоступном компьютере мы можем загружать все что угодно, какое нам дело до последствий? Если мы ищем справочную информацию, то необходимы ли нам сложные, загружающие память и канал эффекты? Ведь мы ищем чаще всего текст. Графические файлы, исполняемые модули и даже видео-аудио клипы можно скачать отдельно и просмотреть позже, возможно, на другом компьютере соответственно поддержку исполнения загружаемого кода можно отключить.
Другой вариант — работа значимого компьютера с сервером, обеспечивающим доставку некоторой функциональности для выполнения задач. Наиболее очевидный пример — обслуживание организацией своих банковских операций на сервере банка. С одной стороны, и на хосте организации находятся важные финансовые сведения, но, с другой стороны, задача может функционировать в режиме тонкого клиента, т. е. все функциональные компоненты для обработки финансовой информации загружаются с сервера банка. В этом случае поддержка загружаемого кода должна быть включена. Но должны быть соблюдены все необходимые меры по обеспечению безопасности:
□ идентификация и аутентификация и клиента и сервера;
□ создание защищенного канала обмена информацией;
□ проверка целостности и авторизованности загружаемого кода;
□ обеспечение настройки прав, с которыми будет работать код;
□ доступность данных для кода и т. п.

Атаки на серверы: CGI и HTTP

admin — Mon, 06 Oct 2008 07:17:14 +0000

Не вдаваясь в подробности функционирования механизма CGI (Common Gateway Interface — Интерфейс Единого Шлюза), скажем, что это набор программ (исполняемых скриптов, интерпретаторов и т. п.), выполняемый на сервере по запросу клиента. Он предназначен обеспечивать динамическое (то есть более гибкое) взаимодействие между удаленным клиентомбраузером и Веб-сервером посредством запуска на серверной стороне приложений, выполняющих задания клиента.
Как и любым другим программам, данному механизму присущ ряд возможных уязвимостей, которые усиливаются тем, что он обслуживает клиентов (пользователей), о которых предварительно ничего не известно, т. е. возможны и потенциальные злоумышленники.
Основные проблемы, связанные с работой CGI, сводятся к тому, что:
□ разработчиком допущены ошибки при написании кода;
□ в коде оставлены преднамеренные люки;
□ злоумышленник получил возможность (права) модифицировать код либо данные, используемые кодом на сервере;
□ злоумышленник получил доступ к интерпретатору с правом исполнения команд.
Наиболее часто встречаются уязвимости, относящиеся к ошибкам на этапе разработки, причем в значительной степени это касается необходимости проверок данных, которые поступают от клиента на обработку программой. Этому вопросу был посвящен отдельный бюллетень CERT — CERT Advisory СА-1997-25 Sanitizing User-Supplied Data in CGI Scripts. В качестве примера возможности реализации атаки приведем CERT Advisory СА-1997-24 Buffer Overrun Vulnerability in Count.cgi cgi-bin Program. В документе говорится о программе count.cgi, которая ведет подсчет посещений Веб-вервера. По причине недостаточной проверки данных, вводимых клиентом, возможно произвести переполнение стека. В результате Count.cgi исполнит команды злоумышленника, наделив их при этом правами доступа, равными правам доступа сервиса httpd в данной системе.
В целом, специальным образом подобранные некорректные (в смысле скорее “неожидаемые разработчиком”) наборы данных представляют собой угрозу, характерную не только для CGI. Известны случаи, когда использование специальных символов (“/”, “.” и ряда других) в URL при обращении к Веб-серверу приводило к совсем иным последствиям, чем это предполагалось разработчиками и администраторами Веб-сервера — от отказа в обслуживании до возможности исполнения зловредного кода с высокими привилегиями. Не будем приводить весь список подобных атак — он довольно однообразен (сформированный особым образом URL — в ответ недокументированная реакция сервера). Остановим внимание специалистов на том вопросе, что, обеспечивая защиту своих Веб-серверов, например, с помощью межсетевых экранов, необходимо уделять внимание не только правильной адресации и обращению к службам, но и тому, какие данные получает конкретное приложение. Другими словами, строя защиту, необходимо в анализе угроз подниматься от сетевого и транспортного уровня сетевой модели — вверх до прикладного.

Атаки на маршрутизацию

admin — Mon, 06 Oct 2008 07:16:42 +0000

Возможно, читатель обратил внимание, что иногда в сфере интересов злоумышленника находится не только собственно хост жертвы, но и некоторые промежуточные узлы. В связи с этим рассмотрим еще один класс атак — атаки на маршрутизацию пакетов. Довольно часто для достижения атакующим пакетом хоста-жертвы может существовать альтернативный путь, либо путь, игнорирующий и изменяющий правила доступа к хосту-жертве. Кроме того, сам хост-жертва может по-разному реагировать на пакеты, поступившие различными путями. В любом из этих случаев в область интересов злоумышленника попадают промежуточные устройства доставки пакетов — маршрутизаторы. Учитывая то, что некоторые организации вместо полноценных межсетевых экранов используют маршрутизаторы с фильтрующими функциями либо без таковых, интерес злоумышленников будет вполне обоснованным.
Наиболее удобным с точки зрения атакующего вариантом будет получение доступа на редактирование таблиц маршрутизации — в этом случае он получает полный контроль над способами направления пакетов данным устройством. Однако получение такого доступа — задача нетривиальная, так как маршрутизаторы обычно находятся под пристальным вниманием администраторов и соответствующим образом защищены.
Одним из вариантов атаки на маршрутизацию без получения доступа к таблицам маршрутизации является возможность, заложенная в IP пакетах и называемая маршрутизацией от источника (англ. source routing). Данная опция позволяет отправителю управлять движением пакета, предоставляя промежуточным шлюзам маршрутизирующую информацию и игнорируя тем самым настройки, определенные администратором сети. При этом возможны два варианта: гибкий (англ. loose source route), когда между двумя соседними адресами в пути маршрутизации может стоять несколько других шлюзов, и жесткий (англ. strict source route), когда два соседних адреса должны находится в сетях, соединенных напрямую. Сама опция состоит из добавления к стандартному IP-заголовку набора из нескольких IP-адресов и указателя смещения, определяющего следующий адрес, который должен быть обработан.

Это свойство дает возможность реализации, например, такой атаки, которая реализуема в некоторых сервисах TCP/IP. Злоумышленник формирует пакет, в котором смещение уже больше длины. Хост назначения, получив пакет, считает маршрут исполненным и формирует пакет ответа, выстраивая обратную цепочку промежуточных узлов и направляя пакет первому хосту в этой цепочке. Поскольку эта цепочка была сформирована злоумышленником, то первым хостом в ней может стоять хост из внутренней сети, на границе которой стоит хост назначения, то есть внутренний хост, достижимый только через внутренний сетевой интерфейс хоста назначения.

Маскировка

admin — Mon, 06 Oct 2008 07:15:40 +0000

Маскировка (англ. masguerading) — общее название для очень большого класса атак, которые заключаются в том, что атакующий выдает себя не за того, кем является на самом деле. Атака, например, использовалась на ранних стадиях развития межсетевых экранов, а в настоящее время может быть использована на маршрутизаторах там, где идентификация и аутентификация производилась только на основе сетевого адреса. Если определенные существенные права присваиваются процессам, инициированным рядом доверенных хостов (то есть пакеты, с адресом источника, входящим в список доверенных, пропускаются без применения к ним ограничивающих правил, и инструкции в этих пакетах принимаются на получающем хосте к исполнению), то злоумышленнику достаточно указать доверенный адрес отправителя в сформированном деструктивном пакете, и он будет пропущен без ограничения.
Маскировкой можно назвать и случай, когда злоумышленник присваивает себе аутентификационные параметры (идентификатор и пароль) легального пользователя и, таким образом, выдает себя за него. Более сложный вариант — это, например, уязвимость в сервере ключей протокола Kerberos версии 4, которая заключалась в слабом генераторе случайных чисел, что давало злоумышленнику возможность взломать сессионный ключ и благодаря этому стать авторизованным пользователем.
Все рассмотренные случаи атак исходят из того, что, маскируясь, злоумышленник является активным субъектом. Но маскировка может происходить и в пассивном варианте. Например, если злоумышленником был получен доступ на изменение записей на соответствующем DNS-сервере, то он сможет выдать свой хост за HTTP, FTP или другой сервер и ввести в заблуждение пользователей, которые станут к нему обращаться. В этом случае атакующий может разместить на ложном сервере выгодную для себя информацию либо, имитируя приглашение к входу, собирать идентификаторы и пароли пользователей для реальных серверов.
Маскировка под другим названием — подмена (англ. spoofing) — используется тогда, когда атакуемый хост использует для сетевого взаимодействия с другим хостом некоего посредника в качестве поставщика определенного рода справочной информации. Наиболее известный вариант — использование сервера разрешения имен DNS. В определенных случаях злоумышленник, выдавая себя за такой сервер, может произвести успешную атаку вне зависимости от того, насколько хорошо защищены общающиеся между собой хосты или сам сервер. Кратко опишем эту атаку. Как известно, основная задача сервера DNS — предоставить запрашивающему хосту (хосту-жертве) в ответ на имя хоста-назначения сетевой адрес хоста-назначения. Если злоумышленнику удается вместо ответа легитимного DNS-сервера направить хосту-жертве свой ответ, то хост-жертва будет направлять свои пакеты не на адрес хоста-назначения, а на тот адрес, который укажет злоумышленник в своем ложном ответе.
Аналогичного эффекта можно добиться, атакуя и другие протоколы и базы данных, ответственные за сопоставление адресов или имен одного уровня адресам другого уровня — ARP (преобразует IP-адреса в МАС-адреса канального уровня), WINS (преобразует Windows-имена хостов в IP-адреса) и т. д.

Отказ в обслуживании

admin — Mon, 06 Oct 2008 07:15:02 +0000

Атаки на отказ в обслуживании (англ. deny-of-service — DoS) являются одними из самых распространенных. Это связано с тем, что они сводятся к выведению информационного объекта из строя, а не к получению какого-либо вида несанкционированного доступа к нему. Действительно, наиболее примитивный вариант подобной атаки — разрыв сетевого кабеля или физическое разрушение сетевого устройства — не требует от злоумышленника серьезной технической квалификации. Несмотря на некую крайность, тем не менее этот пример хорошо демонстрирует сущность атак: приведение в неработоспособное состояние устройства приема/передачи либо приведение канала передачи информации в состояние невозможности транспортировки данных, т. е. возможны два основных направления реализации подобных атак.
□ Критическая часть информационного объекта, отвечающая за обеспечение доступа к информации, разрушается или приводится в неработоспособное состояние. Ситуация требует дополнительного вмешательства администратора для восстановления работы.
□ Некий контейнер приема/передачи информации подвергается запредельной нагрузке, превышающей его пропускную способность, и не может функционировать до тех пор, пока нагрузка не вернется к нормальной. Ситуация может не требовать дополнительного вмешательства, если такая нагрузка не приводит к повреждению или разрушению контейнера.
Другая классификация атак на отказ в обслуживании носит более подробный технический характер.
□ Перегрузка пропускной способности сети. Атакующий генерирует такое количество сетевого трафика, которое полностью занимает возможности данного сетевого соединения.
□ Перегрузка системного процессора. Атакующий создает вычислительные задания для атакуемого узла, которые превосходят возможности процессорной обработки.
□ Занятие возможных портов. Атакующий устанавливает соединения с имеющимися портами таким образом, что занимает все имеющиеся открытые порты и допустимое количество соединений на порт.
□ Перерасход системных ресурсов (памяти, процессорного времени). Атакующий генерирует либо огромное количество данных, сохраняемых в системной памяти, либо большое количество запросов, на обработку которых уходит практически все процессорное время системы. Этот класс атак опасен тем, что может быть выполнен на каком-нибудь другом (более уязвимом) сервисе этого же компьютера, а приведет в итоге к неработоспособности всех служб.
Соответственно, согласно этой классификации природа атак на отказ в обслуживании разделяется:
□ на формирование некоего специального, возможно, некорректного, запроса информационному объекту, обработка которого приведет к выводу объекта из строя;
□ генерирование ненормально большого количества корректных данных, с обработкой которых не справятся либо канал передачи информации, либо устройство (объект) приема/передачи информации. Первый вид атак связан с определенной технической и интеллектуальной работой злоумышленника, которая заключается в поиске уязвимого параметра информационного объекта, который может быть подвергнут нападению. Такой вид атак наиболее непредсказуем при реализации в первый раз, однако после того как он становится известен производителю, выпускается соответствующее обновление, которое, будучи установленным на объект, решает проблему с данной атакой (по крайней мере на данном объекте), т. е. после установки такого обновления можно с высокой степенью вероятности утверждать, что данная атака больше не достигнет успешного результата.
Второй вид атак не требует специальной подготовки и может быть осуществлен даже случайно. Например, когда пользователь посылает письмо большого объема (атака типа mailbomb) или большое количество писем (атака типа spam), он может серьезно блокировать работу корпоративного почтового сервиса. Такие атаки при соответствующей квалификации администратора легко обнаруживаются и обычно устраняются путем выдачи устройству приема/передачи инструкций по запрету обработки информации от источника атаки.
Так было до тех пор, пока не появился новый вид атак на отказ в обслуживании — распределенный отказ в обслуживании (англ. distributed deny-of-service — DDoS). О ней стоит рассказать подробнее.
Сама атака состоит из нескольких частей. В подготовительной части атаки хост потенциальной жертвы не принимает участия. Злоумышленник набирает некое количество хостов — промежуточных жертв, на которых размещает некое программное обеспечение, вообще говоря, троянскую программу. Способ доставки троянской программы здесь не рассматривается, это может быть и вирус, и обычное письмо с вложением: главная задача злоумышленника на данном этапе — это набрать количество, вне зависимости от того, кто конкретно это будет. После размещения достаточно большого количества программ, в определенное время или по дополнительной команде промежуточные жертвы (которые называются в терминах данной атаки зомби) начинают посылать запросы собственно на основную цель атаки, выполняя таким образом функции инструмента атаки злоумышленника. Запросы на хост-жертву либо представляют из себя реальные корректные запросы от клиентов хоста (например, от браузеров — веб-серверу), либо очень похожи на них таким образом, что атакуемый хост не может отличить ложные запросы от реальных и вынужден расходовать время на их обработку. То, что запросы приходят не от одного источника, затрудняет идентификацию их, как атаки. Большинство рекомендаций по противодействию такой атаке сводятся к увеличению производительности атакуемого хоста путем приостановки на нем второстепенных сервисов и процессов. Также, если возможно по какому-либо параметру отделить ложные запросы от запросов реальных клиентов, необходимо установить соответствующий фильтр на обработку запросов хостом.

Приведем примеры некоторых известных атак.
Атака Ping смерти (Ping-of-death), декабрь 1996. Атака производится на сервис стека сетевых протоколов, отвечающего за работу с протоколом ICMP, частью которого является утилита Ping. Превышение стандартной длины сетевого пакета (в данном случае 65 536 байт) может привести к тому, что соответствующий сервис выйдет из строя и операционная система даст сбой (зависание или перезагрузку). Формирование такого пакета может осуществляться, например, стандартной командой ping операционной системы с указанием в качестве цели адреса хоста-жертвы и размера посылаемого пакета, превышающего стандартный.
Атака потоком SYN запросов (англ. SYNflood), сентябрь 1996. Атака основана на специфике функционирования процесса установления соединения протокола TCP. Для установления соединения с сервером клиент посылает серверу запрос SYN, сервер отвечает подтверждением готовности к установке соединения SYN-ACK и ожидает от клиента согласия на соединение АСК, при получении которого соединение считается установленным и можно передавать данные. Однако, если клиент не ответил пакетом АСК, соединение считается полуоткрытым, и сервер, в зависимости от конфигурации, некоторое время ждет сообщения от клиента. Обычно, если время ожидания указано достаточно большим (а ведь количество соединений, которое может быть установлено с сервером одновременно, — это конечное число), то в такой ситуации может быть достигнуто состояние, когда сервер не может больше принимать запросы на соединение и оказывается фактически недоступным. По истечении установленного времени ожидания, полуоткрытое соединение ликвидируется, однако, если злоумышленник посылает SYN-запросы быстрее, чем истекают тайм-ауты фальшивых соединений, то сервер останется недоступным до тех пор, пока SYN-поток не прекратится. Для некоторых систем переполнение списка текущих соединений может привести к зависанию операционной системы.
Атака обычно сопровождается также и подменой IP-адреса отправителя SYN-запроса — каждый раз в пакет помещается в новое произвольное значение адреса, с тем чтобы на сервере нельзя было предотвратить атаку установкой ограничений на количество одновременных соединений с одного IP-адреса. Атака SYN-flood опасна по следующим причинам:
П потенциально она непреодолима, так как неразрывно связана с идеологией протокола TCP (полумерами могут быть только повышение производительности серверов, увеличение их служебных буферов, и, как следствие, количества поддерживаемых одновременно соединений, а также сокращение времени ожидания ответа клиента до предельно возможной разумной величины — например, 0,2—3 с — в зависимости от характера сетевых маршрутов к клиентам);
П у довольно большой части серверов для создания подобного потока достаточно модемного соединения (30—40 Кбит/с) от злоумышленника, несмотря на то, что сам сервер может быть подключен к Интернету качественным каналом пропускной способностью в несколько Мбит/с.
Атака Smurf. Для полного понимания технического механизма атаки необходимо знание принципов функционирования протокола ICMP (Internet Control Message Protocol — Протокол Управляющих Сообщений Интернета). Не углубляясь в технические подробности, укажем, что одной из функций протокола является выяснение, доступен ли для работы удаленный хост. Выяснение производится выполнением команды операционной системы ping, которая формирует пакет запроса (ICMP echo) с указанием адреса удаленного хоста и обратного адреса, куда присылать ответ. Если удаленный хост получают такой запрос и в состоянии его обработать, он посылает в ответ на обратный адрес пакет подтверждения (ICMP echo reply). Протокол допускает широковещательную рассылку запроса, когда сразу все хосты подсети получают запрос на доступность. Этой возможностью и воспользовались злоумышленники. Атака состояла из трех частей. В первой части (рис. 11.2) атакующий формирует широковещательные запросы на несколько подсетей, однако при этом вместо обратного адреса указывает не свой сетевой адрес, а адрес хоста-жертвы. На втором этапе шлюз промежуточной подсети получает запрос хостам подсети и, если на шлюзе не установлена фильтрация широковещательного ICMP-трафика, то шлюз направляет запросы хостам подсети. Уже в этот момент данная промежуточная подсеть может испытать проблемы с пропускной способностью, когда все работающие хосты подсети направят ответ на запрос по обратному адресу, принадлежащему жертве.
На третьем этапе (рис. 11.3) хост-жертва получит множественные ответы на запросы, которые он не посылал. При достаточном количестве запрошенных подсетей с большим количеством хостов в них, подобный поток ответов приведет к тому, что хост-жертва будет выведен из рабочего состояния.

Вирусы и троянские программы

admin — Mon, 06 Oct 2008 07:11:37 +0000

Как уже указывалось в главе 2, вирусы и троянские программы (трояны) функционально похожи, и многие из зловредных программ в настоящее время несут в себе черты и тех и других, поэтому как пример удаленной атаки рассмотрим их совместно. Теоретически и вирус и троянская программа могут быть примером и локальной атаки (когда злоумышленник сам находится за консолью управления атакуемой системы), но этот случай не так интересен, как удаленная атака “в чистом виде”.
Для того чтобы начать свои деструктивные действия, вирус/троянская программа должны быть доставлены на атакуемый хост, и далее, в зависимости от реализации кода и используемой уязвимости, возможны два варианта развития событий.
□ Внедрение вируса/троянской программы произойдет только после некоторых действий пользователя.
□ Внедрение произойдет автоматически, используя уязвимость одного из работающих сервисов.
На самом деле оба случая довольно трудно различимы, так как даже во втором случае автоматическое срабатывание, возможно, будет вызвано некими действиями (либо, наоборот, бездействием) пользователя за некоторое время до поступления деструктивного субъекта на хост, т. е. например, пользователь неверно сконфигурировал настройки определенной службы либо вовремя не произвел обновление уязвимого модуля, что и послужило причиной успеха атаки. В чистом виде успех атаки совершенно без участия пользователя может быть только в случае серьезной уязвимости в службе, допущенной скорее всего разработчиком при проектировании или реализации службы. Такие атаки встречаются реально не очень часто, но тем не менее возможны.
Большую же часть успешных попаданий вирусов/троянских программ на хост обуславливают соответствующие действия пользователя, поэтому интересны именно такие случаи.
Пользователь может выступать либо активной, либо пассивной стороной. Яркий пример активных действий — ситуация, когда пользователь сам загружает на свой хост программное обеспечение или другой объект, который может скрывать деструктивный код — с дискеты, компакт-диска, по сети. Пассивный вариант действий атакуемого пользователя — он получает предложение от некоего субъекта к загрузке кода (письмо, переданная дискета, диск и т. п.). В этом случае успех или неуспех реализации атаки будет зависеть от того, насколько легкомысленно пользователь отнесется к такой загрузке.
Теперь попробуем еще раз перечислить возможные причины потенциального успеха атаки вируса/троянской программы и дать общие рекомендации (рис. 11.1).
1. Ошибки в работе сервиса. Наиболее сложный вид атак, так как может быть произведен без участия самого пользователя. Решение — быть постоянно осведомленным о новостях по безопасности производителя сервиса, о новостях с основных форумов и он-лайн служб безопасности.
2. Несвоевременное обновление ПО. Различают два вида таких ошибок.
• Несвоевременное обновление соответствующих модулей самого сервиса. Решение — подписка на регулярную рассылку информации об имеющихся обновлениях сервиса.
• Несвоевременное обновление модулей системы защиты сервисов (например, антивирусного программного обеспечения). Решение — приобретать лицензионные системы защиты с соответствующей поддержкой производителем обновления систем.
3. Ошибки в конфигурации. Подобные ошибки довольно трудно предупреждать, так как они требуют серьезной квалификации администратора сервиса. В качестве общей рекомендации можно высказать следующее: не давать сервису в функционировании больше прав и возможностей, чем это нужно для выполнения работы. Скажем, если FTP-сервер предназначен только для публикации материалов, нет необходимости оставлять поддержку команды PUT.
4. Загрузка пользователем постороннего программного обеспечения или других контейнеров зловредных программ (документов и таблиц с макросами, скриптов, компонент и т. п.). Наилучшей рекомендацией в данном случае, конечно, был бы полный запрет на любую загрузку перечисленных объектов, однако по производственной задаче такие загрузки могут быть необходимыми. В этом случае возможны следующие варианты.
• Служба безопасности должна иметь отдельный “полигон” (компьютер или набор компьютеров) для проверки посторонних информационных объектов. На этот “полигон” пользователи соответственно направляют подозрительные или незнакомые информационные объекты.
• Если создание подобного “полигона” невозможно, то его аналог придется создать на своем хосте. Последовательность действий в этом случае такова. Следует обеспечить ограничение распространения возможного ущерба — отключить компьютер от сети. Затем создать учетную запись тестового пользователя с минимальными привилегиями, необходимыми для исследования информационного объекта. При этом особое внимание обратить на то, чтобы права этой учетной записи на доступ к критическим разделам (системные каталоги и файлы, другие важные объекты) были минимальными — скажем, только на чтение, а полный контроль или даже право на запись на жесткий диск имелось бы только для ограниченного (проще всего, одного) каталога, в котором и проводить исследование. Далее, необходимо зарегистрироваться на хосте от имени этого тестового пользователя и получить доступ к исследуемому объекту (переписать его на жесткий диск, вставить дискету и т. д.), произвести его проверку имеющимися средствами защиты — скажем, антивирусным программным обеспечением. Перед запуском исполняемой части объекта на выполнение рекомендуется посчитать и записать все процессы, выполняемые в текущий момент на хосте, с тем чтобы можно было обнаружить новые несанкционированные процессы. Кроме того, если есть возможность, запустить службу аудита — регистрации попыток записи и другой работы с критическими разделами, либо сосчитать и сохранить на независимом устройстве контрольные суммы системных и наиболее важных пользовательских файлов. После этого можно произвести запуск исполняемой части и протестировать ее функциональность, получить и скопировать необходимую информацию и т. д. Затем остановить выполнение модуля и проанализировать имеющиеся результаты (новые процессы, новые и модифицированные файлы на диске, журнал аудита). По указанным источникам можно сделать определенные выводы об опасности или безопасности исследуемого объекта.