5.1. Архитектура тестирования МЭ

Данная методика сертификационного тестирования МЭ была разработана на основе рекомендаций ITU-T X.290-296 "Методология и архитектура тестирования Взаимодействия Открытых Систем на соответствие соответствующим стандартам". Согласно данным рекомендациям реальная тестируемая открытая система представляется в терминах модели ISO OSI как набор компонент, располагающихся на одном или нескольких абстрактных уровнях взаимодействия - от канального до прикладного. Соответственно, открытая система в таком представлении имеет точки предоставления сервиса для вышележащих уровней (или пользователя) и использует сервисы, предоставляемые нижележащим уровнем через соответствующие точки доступа. Через эти точки производится тестирование внешнего поведения открытой системы, причем сама открытая система рассматривается в ходе тестирования как "черный ящик", что для тестирования Взаимодействия Открытых Систем на соответствие соответствующим стандартам вполне достаточно.

МЭ - это тоже открытая система, и тестирование МЭ можно рассматривать как тестирование взаимодействия МЭ с другими открытыми системами. Так как МЭ - это открытая система ретрансляционного типа, то тестировать взаимодействие необходимо, по крайней мере, между тремя открытыми системами - открытой системой внешней сети, МЭ и открытой системой внутренней сети.

На основе архитектуры тестирования, рекомендуемой в указанных выше документах, и изложенных здесь особенностях МЭ, предлагается следующая архитектура тестирования МЭ. МЭ абстрактно представляется как набор уровней взаимодействия (в терминах модели ISO OSI), тестирующий субъект подключается одновременно к точкам МЭ предоставления сервиса вышележащим уровням и ко всем точкам (обычно на физическом уровне), через которые МЭ пользуется услугами нижележащего (обычно физического) уровня. Затем начинается, собственно, процесс тестирования: тестирующий субъект моделирует активности во внешней и внутренней сетях, взаимодействуя с МЭ посредством стандартных протоколов на соответствующих уровнях, причем моделируются все возможные штатные и нештатные ситуации, и используются все доступные возможности используемых протоколов взаимодействия. Субъект осуществляет контроль внешнего поведения МЭ и сравнивает его с ожидаемым, описанным в стандартах, на соответствие которым производится тестирование МЭ. Кроме того, в случае сертификационного тестирования указанный субъект в ходе процесса тестирования еще изменяет через соответствующие интерфейсы конфигурацию МЭ. Концептуальная архитектура тестирования МЭ изображается на рисунке 5.

5.2. Модель процесса сертификационного тестирования МЭ

На основе предложенной архитектуры тестирования МЭ была разработана модель процесса сертификационного тестирования МЭ. Эта концептуальная модель связывает следующие понятия-объекты: тестирующий субъект (человек, проводящий сертификационное тестирование), тестовый инструмент (программно-аппаратный комплекс, предназначенный для организации процесса тестирования) и тестируемый МЭ. Эта модель также включает в себя существующие функциональные связи между указанными объектами: два физических соединения между МЭ и тестовым инструментом, направленные связи по управлению от человека к МЭ и тестовому инструменту, и направленные информационные связи от МЭ и тестового инструмента к человеку. Данная модель приведена на рисунке 6.

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

5.3. Используемая терминология

Указанные выше рекомендации ITU-T X.290-296 вводят соответствующую терминологию, удобную для использования в контексте тестирования. Вот список основных терминов, которые потребуются при описании методики тестирования МЭ:

• Абстрактный метод тестирования (abstract test method - ATM);
• Абстрактный примитив предоставляемого сервиса (abstract service primitive - ASP);
• Абстрактный тестовый контекст (abstract testing context);
• Абстрактный тестовый набор (abstract test suite - ATS);
• Абстрактный тестовый пример (abstract test case);
• Базовая спецификация (base specification);
• Воспроизводимость результатов теста (repeatability of results);
• Допустимое тестовое событие (valid test event);
• Зависимость между спецификациями (multi-specification dependency);
• Исполняемый тестовый пакет (executable test suite - ETS);
• Исполняемый тестовый пример (executable test case);
• Локальный метод тестирования (local test method);
• Методология абстрактного тестирования (abstract testing methodology);
• Многопротокольное тестирование (multi-protocol testing);
• Наблюдаемый результат теста (observed test outcome);
• Начальное состояние при тестировании (initial testing state);
• Неопределенное тестовое событие (unidentified test event);
• Неопределенный результат теста (inconclusive verdict);
• Неправильное тестовое событие (invalid test event);
• Тестирование с одним протоколом (single-protocol testing);
• Отрицательный результат теста (fail verdict);
• Отчет о результатах тестирования системы на соответствие (system conformance test report - SCTR);
• Отчет о тестировании на соответствие (conformance test report);
• Параметризованный абстрактный тестовый набор (parameterized abstract test suite - PATS);
• Параметризованный абстрактный тестовый пример (parameterized abstract test case);
• Положительный результат теста (pass verdict);
• Промежуточное тестовое состояние (transient testing state);
• Протокол соответствия (conformance log);
• Протокол управления тестированием (test management protocol - TMP);
• Протокольная единица данных (protocol data unit - PDU);
• Процедуры координации процесса тестирования (test coordination procedures - TCP);
• Процесс оценки соответствия (conformance assessment process);
• Реализация теста (test realization);
• Результат теста (test verdict);
• Семантически недопустимое тестовое событие (semantically invalid test event);
• Синтаксически недопустимое тестовое событие (syntactically invalid test event);
• Система, соответствующая стандартам (conforming system);
• Состояние ожидания при тестировании (idle testing state);
• Спецификация абстрактного тестового набора (abstract test suite specification);
• Спецификация тестирования на соответствие (conformance testing specification);
• Средства тестирования (means of testing - MOT);
• Стабильное тестовое состояние системы (stable testing state);
• Стандартизованный абстрактный тестовый набор (standardized abstract test suite);
• Тест базового взаимодействия (basic interconnection test - BIT);
• Тестирование на соответствие (conformance testing);
• Тестируемая реализация системы (implementation under test - IUT);
• Тестируемая система (system under test - SUT);
• Тестирующая система (test system);
• Тестирующий субъект верхнего уровня (upper tester - UT);
• Тестирующий субъект нижнего уровня (lower tester - LT);
• Тестовое событие (test event);
• Тестовое состояние (testing state);
• Тестовый набор (conformance test suite);
• Тестовый пример (test case);
• Точка управления и наблюдения (point of control and observation - PCO);
• Удаленный метод тестирования (remote test method);
• Утверждение соответствия реализации (implementation conformance statement - ICS);
• Утверждение соответствия системы (system conformance statement - SCS);
• Функциональный тест (capability test);
• Цель тестирования (test purpose);
• Шаг теста (test step).

5.4. Программное средство для автоматизации тестирования

Практической частью данной дипломной работы является реализация программного инструмента, автоматизирующего выполнение работ по сертификационному тестированию МЭ. Данный программный инструмент был написан на языке C под операционную систему Linux RedHat v5.2. Ниже приводятся основные характеристики, принципы использования и структура предлагаемого программного продукта.

Основными характеристиками данного программного инструмента являются:

• простота использования - интуитивно-понятный интерфейс пользователя, простые форматы данных, простота доступа к результатам тестирования;
• модульность - для "прозрачности" тестового инструмента;
• расширяемость - пользователь может создавать новые атаки (модули атак) без изменения основной части программного кода тестового инструмента;
• автономность - конструктивно тестовый инструмент представляет собой один главный исполняемый файл и набор независимых исполняемых файлов-атак, тестовый инструмент функционирует целиком на одном компьютере с установленной ОС;
• многоуровневое тестирование - тестирование (проведение атак) может осуществляться на разных уровнях в терминах модели ISO OSI (от сетевого до прикладного).

Структура программного инструмента приведена на рисунке 7. Ниже дается краткое описание каждого модуля инструмента.

Модуль управления и отображения результатов (control and monitoring module) - это главный модуль инструмента, который управляет всем процессом тестирования в целом. Через данный модуль осуществляется все взаимодействие с пользователем: от пользователя данный модуль получает команды управления (например, запустить, приостановить, прекратить процесс тестирования или сменить конфигурацию) и текущее состояние МЭ в случае успешности атаки типа "отказ в обслуживании" (например, "завис" или перезагрузился), а пользователю выдает информацию о ходе процесса тестирования, информацию о текущей тестируемой конфигурации МЭ и в конце тестирования - подробный отчет о тестировании МЭ во всех конфигурациях. Отчет представляет собой перечень успешно осуществленных атак с указанием для каждой такой атаки ее конкретных параметров и параметров соответствующих конфигураций МЭ. Кроме организации взаимодействия с пользователем, данный модуль непосредственно взаимодействует с модулем активации атак и модулем управления конфигурациями МЭ посредством вызова соответствующих функций (процедур) этих модулей.

Модуль управления конфигурациями (configurations control module) выполняет работы, связанные с параметрами конфигурации МЭ. Он осуществляет чтение и интерпретацию специального конфигурационного файла, в котором записаны все варианты конфигураций МЭ, тестирование которых будет осуществляться. Запись каждого варианта в файле представляет собой набор конфигурационных параметров, а запись каждого такого параметра - в виде "Имя = Значение", причем в качестве значения может указываться не только конкретная величина, но и их диапазон. В последнем случае данный модуль осуществляет генерацию случайного числа из указанного диапазона и присваивает значение соответствующего параметра, равное сгенерированному случайному числу. Следует отметить, что конфигурационный файл является частью данного инструмента и написан по методике составления тестов (т.е. эвристический перебор всех крайних значений конфигурационных параметров). Данный модуль предоставляет услуги, связанные с получением значений конфигурационных параметров, двум модулям - модулю управления и отображения результатов, и модулю активации атак.

Модуль активации атак (attacks engine) - модуль, непосредственно инициирующий выполнение отдельных модулей атак (тестовых примеров), контролирующий их выполнение и напрямую взаимодействующий с ними в ходе всего процесса тестирования МЭ с конкретной конфигурацией. Суть работы данного модуля состоит в следующем. В начале процесса тестирования МЭ с конкретной конфигурацией этот модуль строит список всех доступных ему модулей атак (т.е. список всех исполняемых файлов, реализующих модули атак и находящихся в том же каталоге, что и главный исполняемый файл инструмента). После этого данный модуль последовательно исполняет все модули атак из указанного списка, собирая результаты каждой атаки. После исполнения всех этих модулей атак все результаты группируются (в отчет) и передаются модулю управления и отображения результатов. В ходе исполнения каждого отдельного модуля атаки модуль активации атак создает с первым два программных канала, ассоциированных со стандартным вводом-выводом. Через эти каналы каждый модуль атаки, во-первых, получает данные о текущей конфигурации МЭ, во-вторых, осуществляет выдачу команд инструменту на передачу и прием данных на сетевом, транспортном и прикладном уровнях, установление и разрыв соединений и т.д., и, в-третьих, выдает результаты атаки. Модуль активации атак взаимодействует посредством вызова функций со следующими модулями: модулем управления конфигурациями, модулем доступа на сетевом уровне и модулями доступа на транспортном уровне с и без установления соединения.

Модуль доступа на сетевом уровне (IP-level access module) представляет собой библиотеку функций (и процедур) для организации взаимодействия модулей атак (косвенно через модуль активации атак) с тестируемым МЭ на сетевом уровне, т.е. уровне IP-пакетов. В данном инструменте сетевой уровень является самым нижнем уровнем взаимодействия, который доступен для тестирования. Данный модуль предоставляет следующие основные услуги: передача пакета с заданным заголовком на МЭ через заданный сетевой интерфейс, ожидание прихода одного или нескольких пакетов с заголовками, удовлетворяющими заданным критериям, от МЭ через заданный или любой сетевой интерфейс, чтение данных полученного пакета, исключение из очереди полученного пакета, очистка очереди входящих пакетов и установка времени тайм-аута. Следует отметить, что данный модуль существенно отличается от аналогичного модуля в реализации стека протоколов в ОС. Главное отличие состоит в том, передача пакетов к или от МЭ на сетевом уровне находиться полностью под контролем данного инструмента. Кроме того, при передаче пакета возможно задание любого (в целях тестирования МЭ) заголовка. И, наконец, у данного модуля очень специфический верхний интерфейс, предоставляющий широкие возможности модулям атак по доступу на сетевом уровне. Конструктивной особенностью данного модуля является наличие таймера и очереди входящих пакетов. Таймер позволяет не только измерять пропускную способность МЭ, но и определять отсутствие ответного пакета (например, в случае блокирования пакета без уведомления отправителя или в случае "зависания" МЭ). Наличие очереди (буфера) входящих пакетов позволяет исключить потерю пакетов, посылаемых от МЭ, и добавляет гибкость в доступе к данным полученных пакетов, т.к. все пакеты в буфере адресуются напрямую и могут исключаться из него независимым образом. Реализация модуля доступа на сетевом уровне опирается на услуги, предоставляемые драйвером канального уровня.

Модули доступа на транспортном уровне с/без соединения (TCP/UDP-level access module) предоставляет услуги транспортного уровня для модулей атак. Реализация этих модулей опирается на услуги, предоставляемые модулем доступа на сетевом уровне. Данные модули предоставляют стандартный для транспортного уровня набор сервисов: установление и разрыв соединения, передача и прием данных по соединению, передача и прием дейтаграмм, ожидание получения дейтаграмм по заданному критерию и т.д. Тем не менее, программный интерфейс данных модулей был спроектирован исключительно для целей тестирования и гораздо богаче по возможностям создания соединений и передачи дейтаграмм с нестандартными параметрами.

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

Модуль атаки (attack module) представляет собой конструктивно законченную небольшую программу, которая является реализацией одного тестового примера (тестовой ситуации, сетевой атаки). Все модули атак запускаются последовательно из модуля активации атак, а связь каждого модуля атаки с модулем активации осуществляется с помощью двух программных (однонаправленных) каналов, созданных модулем активации и связанных со стандартными вводом и выводом модуля атаки. Через эти два канала косвенным образом осуществляется связь модуля атаки с МЭ - через модуль активации, через модули доступа на транспортном и сетевом уровнях, через драйвер канального уровня. Через канал, связанный со стандартным выводом, модуль атаки выдает команды (на специальном языке) по запросу информации о текущей конфигурации МЭ, команды соответствующему модуль доступа, а также передает данные (параметры команд), которые должны быть посланы МЭ, и выдает результаты по окончании атаки, реализованной в данном модуле атаки. Через канал, связанный со стандартным вводом, модуль атаки получает запрашиваемые данные (результаты выполнения команд), полученные от МЭ, и информацию о текущей конфигурации МЭ.

Конструктивно весь данный программный инструмент представляет собой набор файлов проекта. Каждый такой файл - это реализация на языке C одного модуля инструмента, внутреннего либо внешнего (модуля атаки). Общий объем исходных тестов инструмента составил в сумме около 200 Кбайт или 7 тысяч строк. Каждый отдельный модуль атаки представляет собой отдельную программу, может в принципе писаться на языке отличном от C, и обычно исходный текст модуля атаки не превышает 100-200 строк. Все исходные тексты инструмента преобразуются с помощью стандартного компилятора языка C в один главный исполняемый файл и несколько (по числу модулей атак) вспомогательных исполняемых файлов атак. Компиляция (и сборка) модулей атак может проводиться раздельно для каждого такого модуля. Следует отметить, что хотя данный инструмент был написан под конкретную ОС, в принципе его можно перенести и в другую среду - основная проблема заключается в существовании в целевой среде аналогичных библиотек (т.е. с таким же программным интерфейсом) сетевого доступа канального уровня.

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

Данный программный инструмент был опробован в действии на нескольких доступных МЭ: встроенный в ОС штатный МЭ, условно-бесплатный пакет Firewall Toolkit фирмы TIS и МЭ Freestone фирмы SOS Corporation. В результате данного тестирования были найдены некоторые уязвимые места перечисленных МЭ, которые не были документированы.

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