способ проверки функционирования протоколов информационных систем

Формула изобретения

Способ проверки функционирования протоколов информационных систем, включающий следующую последовательность действий: строят физический сегмент тестируемой сети, генерируют тестовые блоки, осуществляют отправку тестовых блоков на тестируемый объект, оценивают результат тестирования по соответствующим правилам, отличающийся тем, что после построения физического сегмента тестируемой сети осуществляют построение множества последовательностей параметров полей заголовка пакета тестируемого протокола на основе метода полного перебора, из полученных последовательностей составляют тестовые пакеты, генерируют тестовые блоки, состоящие из набора тестовых и диагностического пакетов, после чего тестовые блоки отправляют с заданной интенсивностью, размерами блоков и структурой, причем завершает каждый блок тестовых пакетов диагностический пакет, реакцию системы на блоки тестовых пакетов анализируют по заданным правилам, в результате чего формируют хранилище критических последовательностей, на основе которого устанавливают фильтрующие правила путем извлечения из хранилища критических последовательностей соответствующих сигнатур и внедрения их в средства обеспечения информационной безопасности.

Описание изобретения к патенту

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

Известна "Система тестирования "Телетестинг" по свидетельству на полезную модель РФ № 98123105/20, "Система тестирования "Телетестинг", класс G06F 15/00, от 22.12.1998. Указанная система содержит следующие блоки: блок подготовительных модулей, соединенный с имеющим вход от потребителя блоков модулей тестирования, который имеет программу тестового диалога, к которой подсоединен снабженный выходом к потребителю блок телекоммуникационных модулей, соединенный обратной и, через канал протоколов, прямой связями с блоком модулей анализа и обработки, содержащим базу данных с результатами телетестинга, блок модулей тестирования снабжен модулем регистрации, а программа тестового диалога снабжена подпрограммой технологического мониторинга, блок телекоммуникационных модулей снабжен модулем программы-робота обработки, выполненного в виде соединенной с выходом к потребителю программы автоматизированной обработки и выдачи первичных тестовых баллов, и соединен с блоком модулей анализа и обработки дополнительной прямой связью через канал данных технологического мониторинга, а обратная связь с блоком модулей анализа и обработки выполнена в виде канала итоговых результатов тестирования, блок модулей анализа и обработки содержит соединенный с каналами протоколов и данных технологического мониторинга модуль анализа достоверности результатов, модуль итоговой обработки результатов, соединенный с каналом итоговых результатов тестирования, и модуль анализа тестовых заданий, выход которого соединен с блоком подготовительных модулей.

Недостатком "Системы тестирования "Телетестинг" является узкая область применения, что обусловлено ее предназначением, в основном, для тестирования характеристик телекоммуникационного оборудования. Предлагаемая система не позволяет осуществлять проверку функционирования протокола в соответствии с нормативными документами, а также осуществлять поиск уязвимостей, внесенных в протоколы разработчиками, и выявление недокументированных возможностей протоколов. Кроме этого указанная система тестирования не позволяет осуществлять построение комплексов защиты коммуникационного оборудования от выявленных угроз безопасности информационных систем.

Известна заявка на изобретение "Раннее определение сетевой поддержки для мобильного межсетевого протокола" по заявке на изобретение РФ № 2005121891/09, класс H04L 29/06, от 11.12.2003. В заявке осуществляется следующая последовательность действий: разъединение беспроводной сетью; тестируются на условие разъединение, при этом условие разъединения представляет собой раннюю индикацию сетевой поддержки мобильного МП, причем шаг тестирования содержит определение того, что беспроводной сетью требуется аутентификация; разъединяются от беспроводной сети, если удовлетворяется условие разъединения; и остаются соединенными с беспроводной сетью, если условие разъединения не удовлетворяется.

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

Наиболее близким по своей технической сущности к заявленному является "Способ и система тестирования DVD плеера" по заявке на изобретение РФ № 2003115966/09, класс G06F 11/00, от 29.05.2003. Заявка содержит способ тестирования, включающий использование тестового DVD, содержащего набор функциональных тестов плеера, тестирование DVD плеера осуществляют с помощью тестов в управляющий компьютер, при этом связывают проверяемый DVD плеер и управляющий компьютер интерфейсом, протокол которого поддерживает передачу команд управления от компьютера к плееру и информации о состоянии плеера обратно, от плеера к компьютеру; копируют содержимое тестового DVD на накопитель управляющего компьютера, загружают тестовый DVD в тестируемый плеер и запускают управляющую программу; с помощью управляющей программы анализируют состав и структуру тестового DVD; выбирают режим тестирования: ручной, полу- или полностью автоматизированный; используя функции управляющей программы, составляют сценарии тестирования из набора тестов выбранного DVD и сохраняют сценарии в виде последовательностей инструкций для модулей системы; выбирают тест или сценарий тестирования, выполняют тестирование и регистрируют его результаты.

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

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

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

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

Сущность изобретения поясняется чертежами, приведенными на фигурах 1-5, на которых показаны:

фиг.1 - структурная схема программно-аппаратного комплекса проверки протоколов информационных систем;

алгоритм реализации процедуры тестирования составляют три основных этапа, представленные на фигурах 2-5:

фиг.2 - алгоритм реализации предсессионного этапа;

фиг.3 - алгоритм реализации стадии генерации сессионного этапа;

фиг.4 - алгоритм реализации стадии анализа сессионного этапа;

фиг.5 - алгоритм реализации постсессионного этапа.

Алгоритм реализации процедуры тестирования составляют три основных этапа, представленные на фигурах 2-5:

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

- сессионный этап (фиг.3-4), включающий две стадии функционирования:

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

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

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

Структурная схема программно-аппаратного комплекса тестирования протоколов информационных систем изображена на фиг.1. На структурной схеме программно-аппаратного комплекса тестирования протоколов информационных систем представлены следующие элементы:

Тестирующий узел - рабочая станция, непосредственно на которой установлена система тестирования, представляющая собой прикладной программный продукт, реализующий алгоритм процедуры тестирования.

Исследуемый узел - рабочая станция (либо сервер), являющаяся объектом исследования в ходе проведения процедуры тестирования.

Исследуемый / Транзитный коммутатор - коммуникационное устройство, которое в ходе проведения процедуры тестирования может выступать как в качестве непосредственно объекта исследования, так и посредником, осуществляющим доставку тестовых блоков от тестирующего узла к исследуемому.

Исследуемый / Транзитный маршрутизатор - коммуникационное устройство, которое в ходе проведения процедуры тестирования также как и коммутатор может выступать как в качестве непосредственно объекта исследования, так и посредником, осуществляющим доставку тестовых блоков от тестирующего узла к исследуемому.

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

Алгоритм реализации процедуры тестирования:

1. Алгоритм реализации предсессионного этапа (фиг.2):

Блок № 1. Осуществляется ввод исходных данных в пользовательский интерфейс, задается интенсивность следования, размер тестовых блоков и их структура, а также режим отправки.

Блок № 2. Проверяется корректность ввода исходных данных. Если веденные данные оказываются некорректными, алгоритм возвращается к блоку № 1, иначе - переходит к блоку № 3.

Блок № 3. Инициализация начальных установок системы. Происходит преобразование исходных данных (интенсивности следования, размера тестовых блоков и их структуры, а также режима отправки) к машинному формату, что подразумевает под собой переход от визуальной формы представления информации к машинным кодам, которые затем заносятся в рабочую память системы.

Блок № 4. Подготовка системы к выработке тестовых блоков. В соответствии с начальными установками системы (интенсивности следования, размера тестовых блоков, их структуры и режима отправки, хранящихся в рабочей памяти системы в форме машинных кодов) активизируются генератор и анализатор тестовых последовательностей, что заключается в инициализации служебных временных переменных, отвечающих как за выработку тестовых блоков с заданной интенсивностью следования, размером и структурой, так и за генерацию и отправку диагностических пакетов, а также разбор принятых ответных диагностических пакетов.

2. Алгоритм реализации стадии генерации сессионного этапа (фиг.3):

Блок № 5.1. Осуществляется запуск циклического процесса тестирования. Указанный процесс является циклическим исходя из того, что происходит генерация и анализ реакции исследуемого узла не для одного, а для множества тестовых блоков.

Блок № 5.2. Происходит чтение текущих установок системы (параметров интенсивности следования, размера тестовых блоков, их структуры и режима отправки, а также служебных временных переменных). На первом цикле они соответствуют начальным установкам (соответственно блоку № 3).

Блок № 5.3. В генераторе тестовых последовательностей вырабатывается тестовый блок заданного размера и структуры.

Блок № 5.4. Осуществляется подготовка и последующая отправка тестового блока с заданным размером и структурой к исследуемому узлу. При этом обе указанные процедуры осуществляются на основе известного компонентного драйвера WinPcap 4.1.1 и полностью прозрачны для пользователя.

Блок № 5.5. Ожидается подтверждение успешной отправки. Если таковое приходит, алгоритм переходит к стадии анализа сессионного этапа (блок № 5.6), в противном случае - переходит к блоку № 5.2.

3. Алгоритм реализации стадии анализа сессионного этапа (фиг.4):

Блок № 5.6. Запускается режим прослушивания в анализаторе последовательностей. Режим прослушивания осуществляется на основе известного компонентного драйвера WinPcap 4.1.1, котоый прозрачно для пользователя прослушивает канал и ожидает поступление ответного диагностического пакета (имеющего формат пакета протокола ICMP).

Блок № 5.7. Осуществляется прием ответного диагностического пакета (имеющего формат пакета протокола ICMP).

Блок № 5.8. Ожидается подтверждение приема пакета. Если таковое приходит, алгоритм переходит к блоку № 5.10, в противном случае - к блоку № 5.9.

Блок № 5.9. Ожидается подтверждение остановки таймера ожидания диагностического пакета. Если таковое приходит, алгоритм переходит к блоку № 5.10 (передает ему управляющий сигнал), в противном случае - возвращается к блоку № 5.7.

Блок № 5.10. Происходит преобразование и разбор ответного диагностического пакета (имеющего формат пакета протокола ICMP), после чего на основании управляющих сигналов из блоков № 5.8 и № 5.9 осуществляется принятие решения в системе о степени критичности отправленного тестового блока, а результат в форме управляющего сигнала направляется в блок № 5.11.

Блок № 5.11. Уточняется решение системы о степени критичности отправленного тестового блока. Если тестовый блок признается критичным, алгоритм переходит к блоку № 5.12, иначе - к блоку № 5.13.

Блок № 5.12. Осуществляется запись критического (текущего) блока в хранилище в форме последовательности параметров полей заголовка пакета тестируемого протокола.

Блок № 5.13. Происходит обновление установок системы (изменение значений параметров интенсивности следования, размера тестовых блоков, их структуры и режима отправки, а также служебных временных переменных) и подготовка ее к следующему циклу работы.

Блок № 5.14. По завершении установленного пользователем цикла работы, циклический процесс останавливается.

4. Алгоритм реализации постсессионного этапа (фиг.5):

Блок № 6. Сброс текущих установок системы. При остановке циклического процесса происходит остановка анализатора и генератора тестовых последовательностей (стираются значения параметров интенсивности следования, размера тестовых блоков, их структуры и режима отправки, а также служебных временных переменных в системе).

Блок № 7. Осуществляется чтение собранных данных из хранилища. При этом все записанные (на сессионном этапе) в хранилище данные загружаются в рабочую память системы.

Блок № 8. Полученный результат интерпретируется. Осуществляется индексирование загруженных в рабочую память системы критических последовательностей и преобразование полученного результата к стандартному виду, то есть к визуальной форме представления информации.

Блок № 9. Осуществляется вывод результата в пользовательский интерфейс.

Таким образом, на фигурах 2-5 указан общий порядок функционирования программно-аппаратного комплекса, реализующего способ проверки функционирования протоколов информационных систем. Как видно из представленного алгоритма, в предлагаемом способе осуществляют построение множества последовательностей параметров полей заголовка пакета тестируемого протокола на основе метода полного перебора, из полученных последовательностей составляют тестовые пакеты, генерируют тестовые блоки, состоящие из набора тестовых и диагностического пакетов, после чего тестовые блоки отправляют с заданной интенсивностью, размерами блоков и структурой, причем завершает каждый блок тестовых пакетов диагностический пакет, реакцию системы на блоки тестовых пакетов анализируют по заданным правилам, в результате чего формируют хранилище критических последовательностей.

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

Заявленный способ реализуют следующим образом.

Пусть исследуемым протоколом будет протокол сетевого уровня IP 4, и пусть имеется физический сегмент тестируемой сети, представленный на структурной схеме программно-аппаратного комплекса тестирования протоколов информационных систем (фиг.1), где на тестирующем узле реализована система тестирования, выполняется алгоритм процедуры тестирования, а тестовые блоки отправляют на исследуемый узел.

Согласно алгоритму реализации процедуры тестирования осуществляются следующие основные этапы (фигуры 2-5):

1. Предсессионный этап(фиг.2).

Пользователем задаются исходные данные: интенсивность следования пакетов - 0,01 пакета/мс, размер тестовых блоков и их структура - 3 тестовых IP-пакета в тестовом блоке, режим отправки - повторение тестовой последовательности.

Системой тестирования проверяется корректность ввода указанных исходных данных, которые затем преобразуются к машинным кодам и заносятся в рабочую память системы.

Далее в системе тестирования инициализируются служебные временные переменные, отвечающие за выработку тестовых блоков с заданной интенсивностью следования, размером и структурой, при этом из выбранной пользователем тестовой последовательности в системе тестирования составляются тестовые ЕР-пакеты с установленным флагом фрагментации (общий вид тестовой последовательности со структурой IP-пакета указан в таблице 1):

Таблица 1
Общий вид тестовой последовательности со структурой IP-пакета
4 бита	Ver	Версия протокола, соответствующая текущему стандарту
4 бита	HL	Длина заголовка в 32-битовых словах
8 битов	TOS	Тип обслуживания
16 битов	FL	Длина пакета в байтах
16 битов	PaID	Идентификационный номер пакета
3 бита	Flag	Флаги фрагментации пакета
13 битов	FO	Смещение фрагмента
8 битов	TTL	Время жизни пакета в секундах
8 битов	PrID	Идентификатор инкапсулированного протокола
16 битов	НС	Контрольная сумма заголовка
32 бита	SIP	IP-адрес отправителя
32 бита	DIP	IP-адрес получателя
	Data	Инкапсулированные данные

Также в системе тестирования инициализируются служебные временные переменные, отвечающие за генерацию и отправку диагностических ICMP-пакетов, а также разбор принятых ответных диагностических ICMP-пакетов (общая структура диагностических ICMP-пакетов отражена в таблице 2):

Таблица 2
Общая структура диагностических ICMP-пакетов
8 битов	Type	Тип сообщения
8 битов	Code	Код дополнительной диагностической информации
16 битов	Checksum	Контрольная сумма данного сообщения
32 бита	Unused	Заполнитель
	Data	Инкапсулированные (необязательные) данные

2. Сессионный этап (фиг.3-4), включающий две стадии функционирования:

- Стадия генерации (фиг.3).

Осуществляют запуск циклического процесса тестирования, последовательно читают параметры интенсивности следования пакетов, размера тестовых блоков, их структуры и режима отправки, а также служебные временные переменные.

Вырабатывают тестовый блок заданного размера и структуры, подготавливают его и отправляют по сети к исследуемому узлу фрагментами, соответствующими тестовым IP-пакетам, с интервалами задержки между отправкой смежных тестовых IP-пакетов, равными 100 мс. В каждом тестовом блоке упаковано три тестовых IP-пакета, структура и содержание задаваемых полей которых отражены в таблице 3:

Таблица 3
Структура и содержание задаваемых полей тестовых IP-пакетов
Ver	0100 (4)
HL	0101 (5)
TOS	00000000 (0)
FL	1000000000000000 (32768)
PaID	0000000000000001 (1)
Flag	001 (1)
TTL	10000000 (128)
PrID	00000000 (0)
Data	00000000 00000000 (0)

Кроме того, в тестовый блок входит один диагностический ICMP-пакет (реализующий стандартную утилиту PING по протоколу ICMP), структура и содержание задаваемых полей которого отражены в таблице 4:

Таблица 4
Структура и содержание задаваемых полей диагностических ICMP-пакетов
Type	00001000 (8)
Code	00000000 (0)

Отправив к исследуемому узлу тестовый блок, система тестирования ожидает получения подтверждения успешной его отправки.

- Стадия анализа (фиг.4).

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

Далее ожидают получение подтверждения приема ответного диагностического пакета до момента остановки таймера ожидания диагностического пакета (в рассматриваемом примере - 10 с). Если на момент остановки таймера ответный диагностический пакет не прибывает, система тестирования делает вывод о критичности отправленного тестового блока (произошел либо логический разрыв соединения, либо критический сбой в работе исследуемого узла, что обусловлено наличием уязвимости протокола IP, полученной в отправленном тестовом блоке) и передает сигнал в блок принятия решения (фиг.4).

Далее принимают ответный диагностический пакет, выполняют его преобразование и разбор. Пусть на данном этапе произошел прием следующего ответного диагностического ICMP-пакета:

Таблица 5
Содержание значимых полей ответного диагностического ICMP-пакета
Type	00000011 (3)
Code	XXXXXXXX

В поле Type ответного диагностического ICMP-пакета указан общий код значения ошибки (3), соответствующий недостижимости узла назначения (Destination Unreachable). В поле Code ответного диагностического ICMP-пакета код значения ошибки уточняется (ХХХХХХХХ), где ХХХХХХХХ одно из значений, указанных в таблице 6:

Таблица 6
Значения кода недостижимости узла назначения
00000000 (0)	Сеть недостижима
00000001 (1)	Компьютер недостижим
00000010 (2)	Протокол недостижим
00000011 (3)	Порт назначения недостижим
00000100 (4)	Необходима фрагментация передаваемого пакета
00000101 (5)	Ошибка при маршрутизации источника
00000110 (6)	Сеть назначения неизвестна
00000111 (7)	Компьютер назначения неизвестен
00001000 (8)	Компьютер-источник изолирован
00001001 (9)	Взаимодействие с сетью административно запрещено
00001010 (10)	То же самое с компьютером назначения
00001011 (11)	Сеть недостижима из-за класса обслуживания
00001100 (12)	Компьютер недостижим из-за класса обслуживания

Поскольку все сгенерированные тестовые пакеты имели установленный флаг фрагментации в протоколе IP (поле Flag в таблице 3), на исследуемом узле осуществляется их сборка согласно процедурной характеристике протокола IP. Размер каждого тестового пакета - 32 кб (поле FL в таблице 3), а в каждом тестовом блоке 3 тестовых пакета, поэтому в процессе сборке произойдет ошибка (вследствие превышения максимального порогового размера - 64 кб (65535 байт)), в результате которой произойдет логический разрыв связи между рабочими станциями.

Логический разрыв связи между рабочими станциями может выражаться как отсутствием ответного диагностического ICMP-пакета в течение 10 с, так и приемом ответного диагностического ICMP-пакета, имеющего значения полей заголовка, указанные в таблицах 5 и 6.

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

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

3. Постсессионный этап (фиг.5).

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

Способ проверки функционирования протоколов информационных систем реализован в виде элементов программно-аппаратного комплекса для проверки протоколов, в которых реализован алгоритм процедуры тестирования. Система тестирования может функционировать на любой рабочей станции, на которой установлена операционная система семейства Windows, а также компонентный драйвер WinPcap 4.1.1 и старше.

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

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

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

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