Диссертация - Государственный университет морского и

<I>e,n:epanbHoe rocy,n:apcTBeHHoe o6pa3oBaTeJihHoe 6JO,n:)l(eTHoe ~pe)l(,n:eHHe
BhiCIIIero rrpo<PeccHofianhHoro o6pa3oBaHH51
«CaHKT-11eTep6yprcKHH rocy,n:apcTBeHHhiH YHHBepcHTeT TerreKOMMYHHKaU:HH
MM. rrpo<P. M.A. EoHq-EpyeBHqa» (CI16fYT)
Ha rrpaBax pyKorrHcH
~v
THaMHHY Ocyorrane A6,n:yrrpaxaMoH
Hccrre,n:oBaHHe MexaHH3Ma ,n:oBepeHHOH MapiiipyTH3aU:HH B rrro6anbHhiX
TeJieKOMMYHHKaU:HOHHbiX CeT51X
05.12.13- CHcTeMhi, ceTH H ycTpoH.cTBa TerreKOMMYHHKaU:HH
,[(HCCepTaU:H51 Ha COHCKaHHe ~eHOH CTerreHH KaH.z:t:H.z:t:aTa TeXHHqeCKHX HayK
HayqHhiH pyKoBO.IJ:HTerrh
EyH.HeBHq MHXaHrr BHKTopoBHq
.IJ:OKTOp TeXHHqecKHX HayK, rrpo<Peccop
CaHKT-11eTep6ypr - 2015
2
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ .................................................................................................................. 3
1 АНАЛИЗ ВОЗМОЖНОСТИ РЕАЛИЗАЦИИ МЕХАНИЗМА ДОВЕРЕННОЙ
МАРШРУТИЗАЦИИ В СЕТЯХ TCP/IP ................................................................. 8
1.1 Постановка задачи на алгоритмизацию механизма доверенной
маршрутизации в сетях TCP/IP ......................................................................... 8
1.2 Создание топологической карты сети ............................................................. 12
1.3 Расширенная идентификация узлов сети ........................................................ 21
1.4 Вычисление доверенного маршрута ............................................................... 25
1.5 Принудительная маршрутизация .................................................................... 29
Выводы по разделу 1 .............................................................................................. 35
2 СИНТЕЗ ПРОГРАММНОЙ АРХИТЕКТУРЫ СИСТЕМЫ УПРАВЛЕНИЯ
ДОВЕРЕННОЙ МАРШРУТИЗАЦИЕЙ ................................................................ 37
2.1 Разработка специальных средств доверенной маршрутизации ..................... 37
2.2 Программная архитектура системы управления доверенной
маршрутизацией ............................................................................................... 55
2.3 Типовые сценарии функционирования механизма ДМ ................................. 69
Выводы по разделу 2 .............................................................................................. 75
3 ОЦЕНКА СВОЙСТВ МЕХАНИЗМА ДОВЕРЕННОЙ МАРШРУТИЗАЦИИ В
ГЛОБАЛЬНЫХ ТЕЛЕКОММУНИКАЦИОННЫХ СЕТЯХ................................ 77
3.1 Имитационное моделирование ТКС с доверенной маршрутизацией ........... 77
3.2 Оценка свойств механизма ДМ ....................................................................... 86
3.3 Оценка информационной безопасности глобальных ТКС при использовании
механизма ДМ .................................................................................................. 97
3.4 Рекомендации по совершенствованию механизма ДМ................................ 105
Выводы по разделу 3 ............................................................................................ 112
ЗАКЛЮЧЕНИЕ ........................................................................................................ 114
СПИСОК ЛИТЕРАТУРЫ ........................................................................................ 117
3
ВВЕДЕНИЕ
Актуальность темы исследования. Актуальность темы обусловлена значительным количеством угроз информационной безопасности в глобальных телекоммуникационных сетях. Для противодействия угрозам существуют и стандартизованы соответствующие механизмы защиты. Анализ современных международных и российских стандартов в области обеспечения безопасности и устойчивого функционирования сетей связи, выполненный в работе [1] показал, что
управление маршрутизацией в контексте доверительной функциональности, которое поглощается понятием «доверенная маршрутизация», даже не упоминается
как сетевой механизм защиты информации. Под доверенной маршрутизацией понимается процесс планирования передачи информационных потоков по вычисленному маршруту через узлы, исключающие возможность подмены, модификации или внедрения информации в потоки данных, проходящих через них [2]. Будучи малоизученной научным сообществом, этот защитный механизм практически не используется для борьбы с сетевыми атаками, несмотря на потенциальную
возможность обеспечения безопасной передачи конфиденциальных данных через
глобальную телекоммуникационную сеть. Дефицит знаний о возможностях, ограничениях, условиях применения, способах реализации и границах эффективности
доверенной маршрутизации в глобальных телекоммуникационных сетях и обуславливает необходимость исследования этого механизма.
Степень разработанности темы. Круг работ, посвященных анализу, обобщению и поиску решения проблемы организации доверенной телекоммуникационной среды «поверх» недоверенной еще весьма ограничен. Отдельные аспекты
обеспечения безопасности передачи данных при помощи доверенных механизмов
защиты, и в частности, управления маршрутизацией, затрагивались в работах ведущих российских и зарубежных ученых: оптимальная маршрутизация и доверенная инфотелекоммуникационная среда - И. Абрахам
[3], З. Вонг [4],
М. В. Буйневич [1, 2], В. М. Зима [5. 6], М. О. Калинин [7, 8], С. И. Макаренко
4
[9-11], Б. И. Марголис [12, 13], С. Н. Новиков [14-16], К. К. Сумасундарам [17];
системы управления сетью - Б. С. Гольдштейн [18-20], В. А. Ефимушкин
[21-23], А. Клемм [24], Д. С. Комер [25], А. А. Костин [26, 27], В. А. Нетес
[28-30]; агентные системы и архитектура сетевой защиты - Ю. А. Гатчин [31-32],
И. В. Котенко [33-34], Х. Лин [35], И. Б. Саенко [34, 36], М. Шумахер [37]; моделирование и оценка устойчивости функционирования телекоммуникационных
сетей - А. А. Зацаринный [38, 39], А. Н. Назаров [40], В. К. Попков [41, 42],
Ю И. Стародубцев [43, 44], А. А. Шелупанов [45-47], О. И. Шелухин [48, 49],
Ю. К. Язов [50] и др. Состояние и тенденции развития рассматриваемой предметной области актуализируют вопрос о проведении комплексного исследования механизма доверенной маршрутизации в глобальных телекоммуникационных сетях.
Цели и задачи.
Целью работы является установление возможных способов реализации,
ограничений и условий применения, а также границ эффективности механизма
доверенной маршрутизации в глобальных телекоммуникационных сетях.
Для достижения поставленной цели в работе были поставлены и решены
следующие задачи:
1) Анализ возможности реализации механизма доверенной маршрутизации
«штатными» средствами TCP/IP;
2) Разработка специальных средств доверенной маршрутизации;
3) Синтез программной архитектуры системы управления доверенной
маршрутизации;
4) Оценка эффективности механизма доверенной маршрутизации в глобальных телекоммуникационных сетях;
5) Выработка рекомендаций по совершенствованию механизма доверенной
маршрутизации.
Объект исследования - механизм доверенной маршрутизации.
5
Предмет исследования - алгоритмизация, программная реализация, оценка
эффективности механизма в глобальных телекоммуникационных сетях и рекомендации по его совершенствованию.
Научная новизна. Научная новизна работы определяется новой предметной областью и новизной полученных результатов и состоит в:
- комплексировании алгоритмов, реализующих содержание принципиально
нового механизма защиты информации в глобальных телекоммуникационных сетях - механизма доверенной маршрутизации - «штатными» средствами TCP/IP;
- разработке специальных средств доверенной маршрутизации и создании
оригинального протокола информационного взаимодействия менеджера с агентами доверенной маршрутизации и базой данных в интересах управления механизмом;
- имитации механизма доверенной маршрутизации в модели полносвязной
сети, которая в отличие от известных учитывает признак доверенности узлов и их
временный контроллинг.
Теоретическая и практическая значимость работы.
Теоретическая значимость научных положений, изложенных в работе, состоит в установлении ограничений и условий реализации механизма доверенной
маршрутизации в глобальных телекоммуникационных сетях, модификации
алгоритма
Дейкстры
(для
нахождения
кратчайшего
доверенного
пути),
установлении свойств механизма доверенной маршрутизации, а также динамики
влияния его ключевых факторов на интегральное качество телекоммуникационных сетей.
Практическая значимость результатов проведенных исследований состоит в
получении требований к специальным средствам (алгоритмам) доверенной маршрутизации, использовании агентной архитектуры системы управления при проектировании программного обеспечения телекоммуникационного и маршрутизирующего оборудования, а также в научном обосновании требований к протоколу
доверенной маршрутизации в глобальных телекоммуникационных сетях.
6
Полученные научные результаты используются на кафедрах «Сети связи и
передачи данных» и «Защищенные системы связи» СПбГУТ им. проф.
М. А. Бонч-Бруевича при подготовке и проведении лекционно-практических занятий по учебным дисциплинам «Маршрутизация услуг», «Информационная безопасность в сетях передачи данных», «Моделирование инфокоммуникационных
сетей и систем», «Качество обслуживания в IP-сетях».
Методология и методы исследования. При решении поставленных задач
использовались современные и традиционные методы исследования - системный,
логический и сравнительный анализ, структурный и функциональный синтез,
имитационное моделирование, теория планирования и обработки результатов
эксперимента. Научно-методической базой исследования явились теоретические и
практические разработки отечественных и зарубежных ученых в области маршрутизации, управления и безопасного масштабирования глобальных телекоммуникационных сетей, а также моделирования процессов их функционирования.
Положения, выносимые на защиту. Соискателем лично получены следующие основные научные результаты, выносимые на защиту:
1) Метод доверенной маршрутизации в глобальных телекоммуникационных
сетях;
2) Программная архитектура системы управления доверенной маршрутизацией;
3) Модель сети с доверенной маршрутизацией и рекомендации по совершенствованию реализации механизма защиты.
Степень достоверности. Достоверность основных полученных результатов
обеспечивается корректностью постановки научно-технической задачи исследования, строго обоснованной совокупностью ограничений и допущений, представительным библиографическим материалом, опорой на современную научную
базу, корректным применением апробированных общенаучных и специальных
методов исследования; и подтверждается непротиворечивостью полученных
результатов практике функционирования глобальных телекоммуникационных
7
сетей и их широкой апробацией на научных форумах, а также получением авторского патента на полезную модель.
Апробация результатов. Основные положения и результаты диссертации
докладывались, обсуждались и получили одобрение на XVI Всероссийской научно-методической конференции «Фундаментальные исследования и инновации в
национальных исследовательских университетах» (г. Санкт-Петербург, СПбГПУ,
17-18 мая 2012 г.), научно-практической конференции «Информационные технологии и непрерывность бизнеса» (г. Санкт-Петербург, СПбГИЭУ, 8 ноября 2012
г.), X Международной научно-технической конференции «Новые информационные технологии и системы (НИТиС-2012)» (г. Пенза, ПГУ, 27–29 ноября 2012 г.),
Международной научно-технической конференции «Фундаментальные и прикладные исследования в современном мире» (г. Санкт-Петербург, СПбГПУ, 20-22
июня 2013 г.), II-ой Международной научно-технической и научно-методической
конференции «Актуальные проблемы инфотелекоммуникаций в науке и образовании» (г. Санкт-Петербург, СПбГУТ, 26–27 февраля 2013 г.), XIV СанктПетербургской Международной конференции «Региональная информатика (РИ2014)» (г. Санкт-Петербург, 29-31 октября 2014 г.), IV-ой Международной научно-технической и научно-методической конференции «Актуальные проблемы
инфотелекоммуникаций в науке и образовании» (г. Санкт-Петербург, СПбГУТ, 34 марта 2015 г.).
Публикации. Основные результаты диссертационного исследования опубликованы в 15-ти научных работах [51-65], из них: 4 работы в изданиях, входящих в перечень рецензируемых научных изданий, рекомендованных ВАК; 1 результат интеллектуальной деятельности (патент на полезную модель); 9 работ в
других изданиях и материалах (трудах) конференций.
Структура и объем работы. Диссертационная работа состоит из введения,
основной части (содержащей 3 раздела), заключения и списка литературы. Общий
объем работы - 132 страницы. Работа содержит 35 рисунков и 16 таблиц. Список
литературы включает 140 библиографических источников.
8
1 АНАЛИЗ ВОЗМОЖНОСТИ РЕАЛИЗАЦИИ МЕХАНИЗМА
ДОВЕРЕННОЙ МАРШРУТИЗАЦИИ В СЕТЯХ TCP/IP
1.1 Постановка задачи на алгоритмизацию механизма доверенной
маршрутизации в сетях TCP/IP
Передача конфиденциальной информации между компьютерами, принадлежащим различным сетям, по глобальной телекоммуникационной сети является
небезопасной, так как существует риск несанкционированного доступа (НСД) к
этой информации в процессе ее следования от отправителя к получателю. Количество и разнообразие атак на телекоммуникационную инфраструктуру нарастает
с каждым днем и уже с трудом поддается какой-либо систематизации и классификации [66]. С неким асимметричным опозданием, но также бурно, развиваются
технологии защиты. Еще в начале 80-х гг. прошлого века Международная организация по Стандартизации (ISO) и Международный Консультативный Комитет по
Телеграфии и Телефонии (МККТТ) признали необходимость создания модели
защищенной от НСД сети, которая могла бы помочь создавать безопасные реализации взаимодействующих сетей. В тесном сотрудничестве была разработана эталонная модель «Взаимодействия Открытых Систем» (ВОС), которая в дальнейшем была описана в рекомендациях Х.200 (МККТТ) и ISO 7498. ГОСТ Р ИСО
7498-2-99 определяет архитектуру безопасности для модели ВОС, дополняя базовую справочную модель, определенную в ГОСТ Р ИСО 7498-1-99 [67]. Этот документ является введением в архитектуру безопасности Интернета и включает
краткое описание набора механизмов защиты, а также таблицу, которая связывает
последние со средствами защиты.
По ГОСТ Р ИСО 7498-2-99 (далее - ГОСТ) структура механизмов защиты
делится на специальные и общеархитектурные. Специальные механизмы защиты
включают понятия об аутентификации, заполнении трафика, управлении доступом, нотаризации, целостности данных, шифровании, электронной цифровой
9
подписи и управлении маршрутизацией. К общеархитектурным механизмам защиты относятся сведения о метках защиты, обнаружении события, отслеживании
защиты, восстановлении защиты и доверительной функциональности. Список
этих механизмов является не полным, а те, которые представлены на рисунке 1.1,
как правило, совершенно не детализированы.
Рисунок 1.1 - Механизмы защиты по ГОСТ Р ИСО 7498-2-99
Научный и чисто практический интерес в контексте безопасности глобальных телекоммуникационных сетей представляет механизм управления маршрутизацией – применение правил в процессе маршрутизации по выбору или исключению конкретных сетей, звеньев данных или ретрансляторов. Согласно пп. 5.3.7.1
– 5.3.7.1 ГОСТ «маршруты могут выбираться либо динамически, либо путем такого предварительного распределения, которое использует только физически защищенные подсети, ретрансляторы или звенья данных»; «при обнаружении постоянных попыток манипуляции данными оконечные системы могут передать поставщику сетевой услуги команду на установление соединения через другой
маршрут»; «инициатор соединения может установить запрет на использование
маршрутов, что требует исключения из маршрута заданных подсетей, звеньев
данных или ретрансляторов».
Такое «предварительное распределение, запрет на использование маршрутов и установление соединения через другой маршрут» поглощается понятием
доверенная маршрутизация (ДМ), под которой понимается процесс планирования
10
передачи информационных потоков по вычисленному маршруту через (доверенные) узлы, исключающие возможность подмены, модификации или внедрения
информации в проходящие через них потоки данных [1]. С позиций общеархитектурных механизмов защиты она реализует, так называемую, доверительную
функциональность, согласно которой: «Любая функциональность, непосредственно обеспечивающая механизмы защиты или доступ к ним, должна быть заслуживающей доверия» (см. п. 5.4.1.1 ГОСТ). Можно сказать, что ДМ реализует
формулу «управление маршрутизацией + доверительная функциональность».
С целью определения содержания и последующей реализации доверенной
маршрутизации автором в работах [55, 56] проанализированы известные стандартизованные механизмы сетевой защиты, также претендующие на доверенность
образуемой ими телекоммуникационной среды - MPLS и VPN.
VPN (от англ. Virtual Private Network – виртуальная частная сеть) – логическая сеть, которая создается «поверх» другой ТКС за счет туннелирования, основанного на RFC-1234 [68]. Для обеспечения безопасности трафика используется
шифрование, то есть применяется формула «шифрование + доверительная функциональность». Механизм поддерживает различные протоколы и масштабируемость. В работе автора [55] показано, что безопасность с помощью шифрования и
туннелирования не препятствует недоверенной сети или сетевым узлам участвовать в маршрутизации данных - будучи частью туннеля, это промежуточное
маршрутизирующее оборудование может исследовать, копировать или модифицировать данные, даже если пакеты зашифрованы.
Технология MPLS (от англ. Multiprotocol Label Switching - многопротокольная коммутация по меткам) реализует коммутацию пакетов в многопротокольных сетях, используя общеархитектурный механизм меток [69,70], и в этом
смысле работает по формуле «управление маршрутизацией + метки защиты». Несмотря на то, что MPLS дает преимущества управления потоками данных (повышает производительность, интегрирует IP и АТМ-сети, позволяет создавать виртуальные каналы), существует проблема потери целостности и конфиденциаль-
11
ности трафика, проходящего через сеть MPLS [71-73]. В то время как гипотетически механизм ДМ гарантирует целостность и конфиденциальность сетевого
трафика. В работе автора [56] анализируются и сравниваются эти два механизма
по отношению к безопасности данных, QoS и масштабируемости сети.
Осуществим прототипирование метода реализации механизма ДМ, усилив
традиционные этапы механизма управления маршрутизацией требованиями
доверительной функциональности.
Во-первых, поскольку основным принципом ДМ является прокладывания
точного маршрута через конкретные узлы в сети, то первым этапом метода должно быть определение и изучение ее структуры – то есть топологии. Классически,
под топологией понимается способ описания конфигурации сети и схема расположения ее устройств, что является недостаточным для прокладывания доверенного маршрута. Следовательно, необходимо получение более детальной информации о структуре сети с учетом всех доступных межузловых маршрутов, а именно – топологической карты. Формально, такая карта имеет вид двунаправленного
графа, узлами которого является маршрутизирующее оборудование (МО), а ребрами – доступные маршруты для пересылки пакетов между ними.
Во-вторых, хотя топологическая карта сети и дает информацию о наличии
узлов и возможных маршрутах между ними, однако характеристики каждого конкретного узла, на основании которых можно судить о его применимость в качестве промежуточной точки маршрута, на данной карте не представлены. Для этого предназначен второй этап метода ДМ – расширенная идентификация узлов сети. В данном случае под идентификацией понимается сбор информации об узле,
которая позволит отнести его к списку доверенных.
В-третьих, требование доверенности к маршруту означает разделение всех
узлов (и, соответственно, их МО) на два типа - «доверенные» и «недоверенные» с
дальнейшим построением маршрута только из узлов «первого» типа. Вычисление
такого (доверенного) маршрута является отдельным (третьим) этапом метода ДМ.
12
Представляется, что алгоритм, реализующий этап, может быть не только бинарным, но и способным учитывать некий заданный уровень доверия к узлам.
Механизм ДМ должен обеспечить строгое следование сетевых пакетов по
вычисленному на предыдущем (третьем) этапе маршруту, так как их проход даже
через один недоверенный узел может быть критичным. Таким образом, четвертый
этап метода ДМ заключается в принудительной отправке (маршрутизации) пакетов через выбранные доверенные узлы.
С учетом вышеизложенного, гипотетический метод реализации механизма
ДМ имеет следующую этапность:
1) Создание топологической карты сети;
2) Расширенная идентификация узлов сети;
3) Вычисление доверенного маршрута;
4) Принудительная маршрутизация.
Исследуем возможности и ограничения реализации механизма ДМ «штатными» средствами, под которыми понимаются утилиты и протоколы, являющиеся
стандартными и применяемые в сетях TCP/IP без каких-либо модификаций. Рассмотрим способ реализации каждого этапа различными алгоритмами с последующим их сравнением. В случае отсутствия доступных реализаций произведем
обоснование на разработку соответствующего средства.
1.2 Создание топологической карты сети
Рассмотрим способ создания топологической карты сети (далее - Карта) алгоритмами на основе «штатных» протоколов и утилит. Поскольку Карта состоит
из узлов и их связей друг с другом, то потребуются алгоритмы, позволяющих получить, по крайне мере, идентификаторы узлов (IP-адрес и доменное имя) и сетевые маршруты. В сетях TCP/IP под эту категорию попадают алгоритмы трассировки и алгоритмы доступа к МАТ.
13
1.2.1 Алгоритм трассировки с помощью опций IP-пакета
Применяемый в сетях TCP/IP протокол сетевого уровня на сегодняшний
день имеет две версии – IPv4 и IPv6, в основном отличающиеся поддержкой разного количества адресуемых узлов [74].
Формат пакета IPv4, помимо основных полей, содержит также необязательные опции. Одна из них, а именно опция номер 7 (называемая «запись маршрута») – предназначена для сохранения в специально зарезервированном месте пакета всех пройденных им IP-адресов узлов. Впоследствии, такая информация может быть возвращена отправителю пакета. Таким образом, с помощью данной опции возможно получение существующих маршрутов между узлами с последующим анализом.
Более современная, вводимая на сегодняшний день в эксплуатацию версия
пакетов IPv6 имеет аналогичную функциональность, но реализованную в дополнительном заголовке пакета [75].
Рассмотрим возможный способ реализации текущего этапа метода ДМ данным с помощью опций IP-пакета. Во-первых, выбирается конечный узел для трассировки. Во-вторых, создается IP-пакет с включенной опцией «запись маршрута»
и посылается выбранному узлу. Каждый из промежуточных маршрутизаторов при
получении такого пакета сохраняет в нем посредством специально-отведенного
поля свой IP-адрес. При достижении пакетом конечного узла, он будет содержать
пройденные маршрутизаторы в виде последовательного списка их IP-адресов.
Конечный узел, проанализировав пакет, отправляет данные о пройденном маршруте исходному. И, в-третьих, производится обработка пакета с маршрутом исходным узлом.
Рассмотренный алгоритм трассировки в схематичном виде представлен на
рисунке 1.2.
14
Рисунок 1.2 - Блок-схема алгоритма трассировки с помощью опции IP-пакета
Основным достоинством данного алгоритма является возможность его реализации стандартными средствами, а именно установкой опции «запись маршрута» для отправляемых пакетов. Следствием такого преимущества будет, соответственно, и быстрая реализация алгоритма. Достоверность полученной информации подтверждается использованием штатных протоколов (как и их реализаций) и
формальной понятностью алгоритма. Возможна передача результатов трассировки по защищенному каналу.
Недостатком применения алгоритма является необходимость согласования
источников и приемников пакета по опции «запись маршрута», что очевидно,
возможно не всегда. Также, существенным является ограничение записываемых
по опции IP-адресов: так, для IPv4 максимально-сохраняемый маршрут равен 9-ти
адресам. Для устранения второго недостатка возможно применение транзитных
узлов-посредников, которые переносили бы уже записанный маршрут в поле данных, освобождая при этом поле опций для дальнейшей записи маршрута.
15
1.2.2 Алгоритмы трассировки с помощью стандартных утилит
Большинство популярных ОС (таких, как Linux и Windows) имеют в своем
составе стандартные утилиты, предназначенные для трассировки доступных сетевых маршрутов. Наиболее известными из них являются две: traceroute, предназначенная непосредственно для определения маршрутов следования пакетов между узлами, узлами, и ping - применяемая для проверки соединений между узлами
(что косвенно дает аналогичную информацию). Утилита traceroute имеет такое
название лишь в ОС Linux, в отличие от ОС Windows, где она называется tracert.
В качестве отличия также следует указать тип посылаемого по умолчанию сообщения: для Linux это UDP, а для Windows – ICMP.
Рассмотрим данные утилиты на предмет их применения для трассировки сети.
Утилита ping отправляет эхо-запросы (ICMP Echo-Request) указанному узлу
сети и фиксирует поступающие ответы (ICMP Echo-Reply) [76]. Вариант алгоритма с применением утилиты состоит из следующих шагов. Во-первых, выбирается
конечный узел для трассировки. Во-вторых, осуществляется запуск утилиты с
указанием адреса выбранного узла. Утилита посылает эхо-запрос конечному узлу,
который должен ответить эхо-ответом. И, в-третьих, по времени получения этого
пакета исходным узлом (или отсутствия такового) делается вывод о доступности
узла. Рассмотренный алгоритм в схематичном виде представлен на рисунке 1.3.
Утилита traceroute отправляет серию эхо-запросов указанному узлу, меняя
их «время жизни» (так называемое, TTL) [77, 78]. Узлы по маршруту будут возвращать эхо-ответ (а точнее, сообщение «время вышло») в тот момент, когда
«время жизни» проходящего через него пакета станет равным 0. Это даст возможность определить промежуточные узлы и время доступа к ним. Основным результатом работы утилиты является список промежуточных узлов, через которые
прошел к конечному узлу пакет. Проанализировав полученный список, можно составить отдельную ветку маршрута на топологической карте сети.
16
Рисунок 1.3 - Блок-схема алгоритма трассировки с помощью утилиты ping
Вариант алгоритма с применением утилиты traceroute состоит из следующих шагов. Во-первых, выбирается конечный узел для трассировки и намеренно
недопустимый номер порта. Во-вторых, осуществляется запуск утилиты с указанием адреса выбранного узла. Утилита посылает неявные эхо-запросы каждому из
узлов (меняя для этого «время жизни» пакета), находящихся на маршруте к выбранному узлу. «Время жизни» пакетов инкрементируется от 1-го и до того момента, как только конечный узел получит эхо-запрос. Промежуточные узлы
должны ответить эхо-ответами, передавая исходному узлу свой IP-адрес. И, втретьих, по факту и времени получения ответов, как и соответствующих адресов
узлов, исходный узел собирает и анализирует информацию о доступных маршрутах сети. Необходимо отметить, что конечный узел вернет эхо-ответ с сообщением «недоступный порт», поскольку он изначально был выбран «неверным».
Рассмотренный алгоритм трассировки в схематичном виде представлен на
рисунке 1.4.
17
Начало
Выбор конечного узла
Запуск утилиты traceroute с указанием конечного узла
Формирование ICMP тип 8
Time-exceeded сигнал?
TTL:=1
Сообщение о недостижимости
конечного узла
Да
Нет
Нет
Назначение счетчика
отправленных пакетов = 0
Получен ответ?
Да
ICMP-ответ
тип 11?
Нет
ICMP-ответ
тип 0 или 3?
Да
Нет
Отправка эхо-запроса
конечному узлу
Инкрементирование счетчика
отправленных пакетов
Нет
Да
Ожидание Time-exceeded сигнала
Счетчик
пакетов = 3?
Да
Увеличение TTL на 1
Заполнение остальных полей пакета
Обработка полученной информации
Заполнение поля пакета c информацией
об IP-адресе источника ответа
Конец
Рисунок 1.4 - Блок-схема алгоритма трассировки с помощью утилиты traceroute
Достоинством рассмотренных алгоритмов трассировки с помощью стандартных утилит является простота использования, широкая применяемость механизма эхо-пакетов, а также высокая информативность: конкретные временные задержки от отправителя до получателя пакетов и список IP-адресов всех промежуточных узлов.
Однако не все узлы в сети могут поддерживать такие ICMP-пакеты полноценно: так, в случае блокировки входящих ICMP-сообщений, узел не будет реагировать на входящие эхо-запросы; а в случае применения фильтрации исходящих
ICMP-сообщений типа «время вышло», последний достигнутый пакетом с 0-м
TTL узел не будет возвращать никакого ответа.
1.2.3 Алгоритмы доступа к МАТ
Маршрутно-адресная таблица (МАТ) содержит информацию, на основе которой маршрутизатор принимает решение о дальнейшей пересылке пакетов. Таб-
18
лица состоит из некоторого числа записей - маршрутов, в каждой из которых содержится адрес сети получателя, адрес следующего узла, которому следует передавать пакеты и некоторый вес записи - метрика. В зависимости от модели маршрутизатора и используемых протоколов маршрутизации, в МАТ может содержаться некоторая дополнительная служебная информация.
В случае наличия автономных подсетей, их пограничные маршрутизаторы
обмениваются информацией доступности этих сетей с помощью основного протокола динамической маршрутизации – BGP [79]. Этот же протокол может быть
использован и для сбора необходимой информации о сетевых маршрутах, поскольку он, по сути, обеспечивает доступ к МАТ отдельного маршрутизатора.
Рассмотрим возможность реализации текущего этапа метода ДМ данным
способом. Во-первых, выбирается маршрутизатор для получения МАТ с помощью BGP. Во-вторых, с ним открывается BGP-сессия, производится получение
МАТ с помощью пакетов обновления информации «update» и закрытие сессии. И,
в-третьих, производится обработка полученной информации.
Рассмотренный алгоритм в схематичном виде представлен на рисунке 1.5.
Рисунок 1.5 - Блок-схема алгоритма получения МАТ с помощью BGP
19
Достоинствами алгоритма является возможность получения полной действующей МАТ отдельных маршрутизаторов, информация в которой является достоверной на момент применения алгоритма. Однако для применения алгоритма
соответствующее сетевое устройство должно поддерживать BGP-протокол.
Для управления устройствами в IP-сетях предназначен стандартный протокол – SNMP. С его помощью возможно получение значений различных переменных, описывающих конфигурацию управляемой системы [80]. В частности, такой
переменной может быть элемент МАТ – доступный маршрут. Вся информация
иерархически структурирована и хранится в базе управляющей информации –
MIB (Management Information Base). Для поддержки протокола каждое из управляемых устройств (в нашем случае – МО) должно содержать агента SNMP – программное обеспечение, имеющее доступ к управляющей информации устройства
и переводящее ее в специфичную для SNMP форму.
Рассмотрим возможность реализации текущего этапа метода ДМ данным
способом. Во-первых, выбирается маршрутизатор для получения МАТ с помощью SNMP. Во-вторых, между исходным узлом и маршрутизатором осуществляется обмен SNMP-сообщениями с целью получения объектов MIB – маршрутов.
И, в-третьих, производится обработка полученной информации.
Рассмотренный алгоритм в схематичном виде представлен на рисунке 1.6.
Рисунок 1.6 - Блок-схема алгоритма получения МАТ с помощью SNMP
20
Достоинством алгоритма является то, что используемый в нем протокол изначально предназначен для обмена информацией – в данном случае, получения
значений переменных различного типа, такого как доступные маршруты. Это дает
возможность получения только выбранных объектов – МАТ, при этом для всех
устройств сети. Тем не менее, для работы алгоритма требуется наличие работающего SNMP-агента на каждом из опрашиваемых устройств, что не всегда встречается на практике. Также очевидно, что информация о МАТ (которая хранится в
локальных MIB устройств) способна устаревать и требует периодического подтверждения достоверности.
Хотя рассмотренные выше алгоритмы предоставляют информацию о доступных сетевых маршрутах, однако промежуточными точками последних являются IP-адреса, которые порой не имеют взаимно-однозначного соответствия реальному МО. Так, один физический узел сети может иметь несколько IP-адресов
(или псевдонимов), что вносит ошибки в конечную Карту – граф будет содержать
несколько узлов с различными маршрутами, физически соответствующие одному
МО. Таким образом, отображение топологии, (например, Интернета), требует
разрешение IP-псевдонимов. Разрешение IP- псевдонимов – это процесс распознавания интерфейсов, которые принадлежат одному и тому же МО, что помогает
определять истинную топологию сети.
Известны многочисленные техники разрешение IP-псевдонимов [81-83]:
счетчики общего IP ID, анализаторы DNS, анализаторы графов и проч. - способные произвести отображение IP к МО. В [81] утверждается, что наилучшие результаты (более точное и полное отображение) дает объединение техник, например: метод по адресу общего источника + метод по анализу графа + метод по анализу графа с ограничением TTL и «пропавшей серединой».
Аналогично, сочетание стандартной утилиты traceroute и IP-опции «записи
маршрута» повышает точность топологии отображаемой сети. Поэтому, чтобы
иметь истинное представление о топологии сети в качестве способа создания Карты потребуется использовать некий обобщенный (комплексный) алгоритм, реали-
21
зующий последовательность шагов. Во-первых, строятся части Карты, полученные с использованием описанных ранее алгоритмов. Во-вторых, производится согласование построенных частей (с разрешением конфликтов) и синтезируется общая Карта. И, в-третьих, разрешаются IP-псевдонимы.
1.3 Расширенная идентификация узлов сети
1.3.1 Алгоритм геопривязки узлов
Рассмотрим способ расширенной идентификации узлов на базе получения
информацию об их физическом расположении – определении геопривязки IPадресов. Такая информация будет полезна для определения степени доверия конкретному узлу, поскольку территория расположения оборудования узла, как правило, более «прозрачна» с точки зрения безопасности (как для проверки, так и
обеспечения). Для получения подобной информации существует штатный протокол WHOIS и публичные серверы баз данных (БД).
Протокол WHOIS основан на TCP, подразумевает архитектуру «клиентсервер» и обеспечивает доступ к публичным БД регистраторов IP-адресов и доменных имен [84]. Среди мировых БД можно выделить наиболее известные:
AFRINIC (African Network Information Center) – региональный реестр Интернет
для стран Африки (основан в 2005 году); RIPE NCC (от фр. Reseaux IP Europeens
+ англ. Network Coordination Centre) – один из пяти региональных интернетрегистраторов, выполняющих распределение интернет-ресурсов, а также связанную с этим регистрацию и координацию деятельности, направленную на глобальную поддержку функционирования Интернета (основан в 1992 году); APNIC (от
англ. Asia-Pacific Network Information Center) – Азиатско-Тихоокеанский сетевой
информационный центр, аналогичный RIPE NCC (основан в 1993 году); ARIN
(American Registry for Internet Numbers) – Американский реестр адресов сети Ин-
22
тернет, региональный интернет-регистратор, действующий в Канаде, на многих
Карибских и Североатлантических островах и в США (основан в 1997 году).
Формат данных, обмениваемых с различными серверами WHOIS, практически идентичен. В общем случае, запрос к БД содержит имя домена или IP-адрес, а
результирующий ответ имеет текстовый читабельный вид. Помимо технической
информации, последний может содержать географические данные о запрашиваемом узле, такие, как страна, название организации или даже почтовый адрес.
Рассмотрим способ реализации текущего этапа метода ДМ алгоритмом геопривязки. Во-первых, выбирается узел для сбора информации. Во-вторых, выбирается сервер WHOIS. В-третьих, делается запрос на получение информации и
принимается ответ. И, в-четвертых, ответ обрабатывается с целью выделения информации о геопривязке узла.
Алгоритм целесообразно применить для различных серверов WHOIS, синтезировав полученную информацию и скорректировав возможные коллизии. Рассмотренный алгоритм в схематичном виде представлен на рисунке 1.7.
Рисунок 1.7 - Блок-схема алгоритма геопривязки по серверам WHOIS
Достоинством алгоритма является возможность получения географического
положения узла по его IP-адресу или доменному имени. Как показывает практика,
определение страны происходит более чем в 90% случаев. К недостаткам можно
отнести зависимость результативности алгоритма от качества информации, со-
23
держащейся на серверах WHOIS (последние могут, как не содержать информации
о запрашиваемом узле, так и иметь таковую в неполном или заведомо искаженном виде).
1.3.2 Алгоритмы идентификации маршрутизирующего оборудования
Тот факт, что МО компания Cisco доминирует (около 70% оборудования
Интернет) в глобальных телекоммуникационных сетях, предполагает, что знание
о конкретных моделях устройств, версиях их ОС – IOS, работающих сервисах и
другие детали позволит спрогнозировать некую меру безопасности создаваемых
сетевых маршрутов. Таким образом, целесообразно специализированно рассмотреть алгоритмы для сбора информации об устройствах именного этого производителя.
Известно несколько распространенных техник идентификации маршрутизаторов в сети, эффективных для оборудования Cisco [85-89]. Их можно условно
разделить на две группы: прямого взаимодействия и перехвата управляющего
трафика.
Исследуем техники прямого воздействия на предмет реализации текущего
этапа метода ДМ.
1) При трассировке маршрутов пакетов с помощью утилиты traceroute будет
получен список промежуточных узлов с их именами. Наличие в этих строках таких названий, как « cs3640» или «cisco1800», с большой долей вероятности будет
указывать на модель маршрутизатора производства Cisco.
2) Идентификацию маршрутизатора возможно произвести с помощью утилиты Nmap (так называемого «Network Mapper», или «сетевого картографа») – инструмента, производящего сканирование указанных хостов различными способами (например, UDP, TCP-connect, ICMP-эхо-запросы и др.). В случае сканирования портов маршрутизатора Cisco, результат работы Nmap может содержать следующую строку: «Remote operating system guess: Cisco Router/Switch with IOS
24
12.4», - идентифицирующую узел, как маршрутизатор компании Cisco с выполняемой операционной системой IOS версии 12.4.
3) Использование стандартной утилиты telnet, реализующей клиентскую
часть одноименного протокола доступа к сетевому устройству, также может дать
определенную информацию о МО. Так, при попытке доступа к маршрутизатору
Cisco ответные данные будут содержать строку «User Access Verification», что
позволит идентифицировать узел как маршрутизатор компании Cisco.
С учетом вышеизложенного способ реализации текущего этапа метода ДМ
представляется следующим обобщенным (по разным техникам прямого воздействия) алгоритмом. Во-первых, выбирается узел для идентификации. Во-вторых,
осуществляется прямое взаимодействие с ним вышеприведенными утилитами. И,
в-третьих, обрабатываются результаты этого взаимодействия – текстовый вывод
утилит.
Исследуем техники перехвата управляющего трафика с использованием
специальных протоколов.
1) Для целей обнаружения сетевого оборудования Cisco компанией разработан и используется специальный протокол CDP (Cisco Discovery Protocol). Он
поддерживается многими устройствами компании, и почти не используется сторонними [90, 91]. Получаемая по нему информация содержит типы подключенных Cisco устройств, их модели и интерфейсы подключения соседних (в том числе, использующихся для создания соединений). Таким образом, перехват и анализ
данных CDP-протокола предоставит идентификационную информацию об узлах.
Пример строки данных, полученных из CDP пакетов: «Cisco IOS Software, 2800
Software
(C2800NM-ADVIPSERVICESK9-M),
Version
12.4(12),
RELEASE
SOFTWARE (fc1)», - однозначно идентифицирует узел как маршрутизатор компании Cisco (модель 2800) с исполняемой операционной системой IOS версии 12.4 и
сборкой fc1.
2) Перехват SNMP-пакетов и их анализ (с применением дешифрования в
случае необходимости) также позволяет раскрыть передаваемую в них информа-
25
цию. Последняя может содержать такие данные о конфигурации сетевых
устройств (группа данных MIB с OID = «system»), как текстовое описание устройства, его физическое расположение и информацию о службе поддержки. Важно,
что данный алгоритм применим к любому типу сетевого оборудования, а не только от производителя Cisco. Пример строки данных, полученных из SNMP пакетов:
«=OCTET STRING - (ascii): Cisco IOS Software (tm), Version 12.4 (12) RELEASE
SOFTWARE (fc1) Copyright (c)», - также однозначно идентифицирует узел как
маршрутизатор компании Cisco с исполняемой операционной системой IOS версии 12.4 и сборкой fc1.
С учетом вышеизложенного способ реализации текущего этапа метода ДМ
представляется следующим обобщенным (по разным техникам перехвата) алгоритмом.
Во-первых, выбирается область сети с присутствием управляющего трафика. Во-вторых, осуществляется перехват трафика выбранного типа (CDP или
SNMP). И, в-третьих, трафик анализируется на наличие информации о маршрутизаторах Cisco.
Достоинством рассмотренных алгоритмов является сбор достаточно широкого рода информации об узле, которая может быть использована для его идентификации и на последующих этапах метода.
Недостатком алгоритмов является их ограниченная применимость к оборудованию других производителей, а также отсутствие гарантии доверенности.
1.4 Вычисление доверенного маршрута
Практически все реализации выбора маршрута между узлами сети основаны
на известном алгоритме Дейкстры [92, 93], назначением которого является поиск
кратчайшего расстояния от одной вершины графа (узла) до всех остальных с учетом весов ребер (каналов).
26
Алгоритм Дейкстры является широко используемым (базовым) в телекоммуникационных сетях и проверенным на практике: на его основе работают такие
протоколы маршрутизации, как OSPF, PNNI и IS-IS, поддерживаемые современными маршрутизаторами. По алгоритму Дейкстры путь ко всем узлам выбирается
последовательно для каждого узла от начальной точки с постепенным расширением области поиска и корректировкой путей в сторону кратчайших.
Однако алгоритм Дейкстры, включая известные модификации [94-96], никак не учитывает степень доверия узлам, и значит, проложенный им маршрут
нельзя считать надежным, в смысле - доверенным.
Известно несколько запатентованных алгоритмов, претендующих на повышение степени доверия к получаемому маршруту. Рассмотрим эти, дополнительные по отношению к базовому, алгоритмы на предмет решения задачи вычисления доверенного маршрута.
1) Алгоритм «безопасной маршрутизации на основе степени доверия» («Secure routing based on degree of trust»), патент U.S. 20130019317 [97]. С помощью
него данные могут быть направлены через цепочку узлов, где, по крайней мере,
один имеет более низкий уровень доверия, а остальные узлы имеют приемлемые
уровни доверия.
В патенте предложен алгоритм создания и использования зашифрованного
туннеля для случая, когда маршрут проходит через узел с недостаточной степенью доверия, с последующей их расшифровкой на доверенном. Алгоритм по патенту требует, чтобы маршрутизаторы определяли путь, при движении по которому может быть применен, по крайней мере, один зашифрованный туннель для
поддержки более высокого уровня доверия.
Алгоритм имеет существенные недостатки. Так, зашифрованные данные в
конечном итоге могут быть скопированы или удалены устройством маршрутизации не внушающим доверия, или даже расшифрованы третьими лицами.
27
2) Алгоритм «одноранговой доверенной сети на основе общих симметричных ключей» («Peer-to-Peer Trusted Network Using Shared Symmetric Keys», патент
U.S. 20120324218 [98].
Алгоритм предлагает устанавливать уровень доверия узлам, посылая друг
другу аутентификационные сообщения и используя общие симметричные ключи
шифрования, и затем добавляют сообщения в свои списки доверия.
В некоторых случаях при реализации алгоритма возникает проблема, когда
обмен общими симметричными ключами шифрования может быть скомпрометирован (в результате атак) из-за НСД к передаваемой информации. Как результат невозможность обеспечить целостность и конфиденциальность данных при их передаче по вычисленному маршруту.
3) Алгоритм «Метод и устройство обеспечения доверия на основе маршрутизации в сетях передачи данных» («Method and apparatus for trust based routing in
data networks»), патент U.S. 7984294 [99].
Алгоритм предлагает устанавливать уровень доверия маршрута, используя
дополнительную информацию от каждого маршрутизатора на этом маршруте. Когда маршрут получен отправителем, его устройство определяет, является ли уровень доверия этого маршрута приемлемым, используя эту информацию из базы
данных. Если маршрут считается доверенным (приемлемым), то отправитель посылает сообщение о подтверждения этого маршрута в виде кода RSVP-ТРАСТ
всем узлам этого маршрута. В противном случае, маршрутизатор отправителя передает сообщение RSVP-РАЗРЫВ всем узлам этого маршрута, сигнализируя о
нем, как не заслуживающим доверия. Далее маршрутизатор отправителя продолжает выбирать маршрут, пока не будет найден приемлемый (или до отсутствия
такового).
Однако выбранный маршрут может оказаться не очень надежным, поскольку для его выбора используется некая оценка пояснительной информации об
уровнях доверия маршрутизаторов, что влечет за собой вероятность ошибочности
суждений.
28
4) Алгоритм «Устройство маршрутизации, модуль маршрутизации и способ
маршрутизации для сети доступа», патент RU 2 411 673 С2 [100].
Алгоритм описывает техническое решение, раскрывающее способ и устройство, в которых предлагается идея использования данных о полномочиях, например, информации об аутентификации и авторизации, или данных о подписке как
основы для разрешения альтернативного адреса. Данные о полномочиях, например, являются основой для назначения или привязки посылающего устройства к
относящимся к нему устройствам-адресатам. Назначение может быть выведено
или получено из данных о полномочиях. Также сервер может переслать данные о
назначении на устройство или модуль маршрутизации на основе данных о полномочиях. Также возможно, чтобы данные или информация о назначении уже хранились в устройстве или модуле маршрутизации, и чтобы устройство или модуль
маршрутизации активизировали данные о назначении или привязывали посылающее устройство к возможным или предпочтительным устройствам-адресатам на
основе данных о полномочиях.
Каждый из рассмотренных дополнительных алгоритмов имеет свои сильные и слабые стороны с позиции реализации механизма ДМ. Так, первый из них
обеспечивает безопасность данных путем создания зашифрованного канала, что
не лишает потенциальной возможности их удаления, копирования или же расшифровки недоверенным маршрутизатором. Второй алгоритм устанавливает
уровни доверия узлам путем обмена аутентификационными сообщениями с использованием общих симметричных ключей, которые могут быть скомпрометированы при атаках из-за доступа к передаваемой информации. Третий алгоритм
является наиболее близким из всех для целей ДМ, поскольку он использует информацию об уровнях доверия маршрутизаторам, производит оценку каждого из
них и выбирает оптимальный; тем не менее, алгоритм прокладывает маршрут и
через недоверенные узлы. Четвертый алгоритм обеспечивает переадресации сообщений с альтернативным адресом подходящему (в частности, связанному с
конкретным поставщиком услуг) устройству-адресату, однако источник данных о
29
полномочиях адресата сам должен заслуживать доверия. Комбинация же алгоритмов, хотя и увеличит уровень доверенности получаемого маршрута, однако
такое решение все равно будет недостаточным.
1.5 Принудительная маршрутизация
Исследуем возможность принудительной маршрутизации «штатными»
средствами TCP/IP. Известно, что в сетях TCP/IP маршруты могут задаваться как
административно (так называемые, статические маршруты), так и вычисляться
(так называемые, динамические маршруты), базируясь на информации о топологии и состоянии сети [101]. Но и во втором случае IP-протокол обладает возможностью направления сетевого трафика через определенные узлы – маршрутизацией от источника [102-104]. Данная его особенность востребована в таких ситуациях, когда используемые сети не предусматривают традиционную маршрутизацию (например, IPX/SPS), некоторые узлы имеют ограничения по мощности (в
случае беспроводных сетей) и при специальных сетевых политиках безопасности.
Рассмотрим способ принудительной маршрутизации с помощью алгоритмов
маршрутизации от источника и в случае использования статических маршрутов.
Для этого проведем их анализ по следующим критериям. Во-первых, результативность применения - алгоритмы по-разному обеспечивают гарантию отправки
пакетов по доверенному маршруту. Во-вторых, сложность алгоритмов напрямую
повлияет на время их реализации и возможные ошибки; это позволит сделать выбор одних алгоритмов, как более стабильных, чем других (особенно при ограниченном времени на разработку). В-третьих, более скрытно работающие алгоритмы не позволят выявить их активность администратором сети и предпринять превентивные действия. В-четвертых, простота использования алгоритмов позволит
более эффективно и безошибочно строить их взаимодействие с окружением (другими алгоритмами, стандартными протоколами, и т.п.). В-пятых, на реализацию
метода ДМ могут быть наложены дополнительные требованиям, а, следовательно,
30
реализующие его алгоритмы должны иметь нужную степень расширяемости. И,
в-шестых, у любого алгоритма, как правило, существуют ограничения в работе.
1.5.1 Алгоритмы маршрутизации от источника
Если необходимо заставить пакеты пройти по какому-то другому (принудительному, неоптимальному) маршруту или отдельным направлениям, в протоколе
IPv4/IPv6 имеется встроенные опции для задания маршрута. Алгоритм, с помощью которого отправитель может влиять на маршрут, называется маршрутизацией от источника. Существует два варианта этого алгоритма – так называемая,
«гибкая» и «жесткая» маршрутизация. В протоколе IPv4 для этого предназначены
опции LSRR (Loose Source and Record Route) и SSRR (Strict Source and Record
Route), в то время как в IPv6 – «заголовок маршрутизации типа 0» (RH0) [75].
В первом случае (LSRR) отправитель задает частичный список IP-адресов
обязательных узлов пути; при этом пакет может проходить и через другие узлы,
помимо заданных. Вторым является однозначная маршрутизация от источника
(SSRR), при которой узел-отправитель точно задает весь путь следования IPдейтаграммы.
Опции IPv4, связанные с маршрутизацией от источника, более точно называются опциями «маршрутизации от источника с записью», так как при прохождении дейтаграммы через каждый из перечисленных в списке узлов, его адрес сохраняется в поле опций. Это позволяет получателю дейтаграммы обратить полученный список, превратив его в маршрут, по которому может быть послан ответ
отправителю. В силу ограничения на размер поля опций, число узлов в списке не
может превышать 9.
В случае IPv6 маршрутизация от источника реализована в расширенном заголовке, находящемся после заголовка IPv6 до верхнего уровня нагрузки (пространства данных). Расширенные заголовки не ограничены в размерах; они состоят из набора различных данных и могут быть огромными. Если фрагментация за-
31
прещена, то количество узлов маршрута в расширенном IPv6-заголовке будет
ограничено максимальным размером пакета. Последний определяется TCP MTU,
максимальное значение которого равно 1500 байтам, и, следовательно, внутри пакета можно составить список из 90 IP-адресов [75].
Вышеуказанные свойства алгоритмов позволяют их использовать в интересах принудительной маршрутизации. Рассмотрим перечисленные варианты алгоритма принудительной маршрутизации (для примера – только для IPv4).
1.5.1.1. Гибкая маршрутизация от источника
В этом варианте маршрутизатор при получении пакета с установленным
указателем-параметром опций IP-пакета «гибкая маршрутизация» проверяет адрес назначения пакета. Если он не совпадает с адресом данного маршрутизатора,
то пакет пересылается в соответствии с таблицей маршрутизации для текущего
адреса назначения. Если адрес назначения пакета совпадает с адресом данного
маршрутизатора и значение поля «указатель» (указывающего на следующий адрес
гибкой маршрутизации) меньше длины поля опций, тогда:
1) По текущему значению «указателя» из списка извлекается следующий
адрес, который используется в качестве адреса назначения;
2) В соответствии с таблицей маршрутизации выбирается интерфейс для
отправки пакета;
3) Происходит замена адрес интерфейса на выбранный согласно п. 2);
4) Значение поля «указатель» увеличивается на 4 для синхронизации с размером поля IP-адреса;
5) Пакет пересылается в соответствии с таблицей маршрутизации.
Вариант алгоритма гибкой маршрутизации состоит из следующих шагов.
Во-первых, определяются узлы на доверенном маршруте, через которые трафик
может пойти на недоверенные. Во-вторых, определяются основные узлы, на которые необходимо перенаправить трафик, чтоб избежать его утечки по недоверен-
32
ным маршрутам. И, в-третьих, IP-адреса для перенаправления трафика заносятся в
поле адреса получателя и поля опций для управления маршрутом IP-пакета.
Таким образом, вариант алгоритма состоит из следующих шагов (для каждого из недоверенных узлов вблизи от доверенного маршрута):
1) Определить IP-адрес любого недоверенного узла маршрута и ближайшего к нему доверенного узла;
2) Определить IP-адрес доверенного узла, являющегося соседним с найденным доверенным в текущем маршруте;
3) В поле опций IP-пакета последовательно занести адреса предпоследнего
доверенного узла и конечного получателя информации;
4) В поле «адрес получателя» заголовка IP-пакета занести адрес последнего
доверенного узла.
1.5.1.2. Жесткая маршрутизация от источника
Вариант алгоритма жесткой маршрутизации состоит из шагов, аналогичных
гибкой, но с тем отличием, что в поле опций IP-пакета заносятся последовательно
все транзитные узлы, а не только основные.
Таким образом, вариант алгоритма состоит из следующих шагов (для каждого из недоверенных узлов вблизи доверенного маршрута).
1) В поле «адрес получателя» заголовка IP-пакета занести адрес первого доверенного узла;
2) В поле опций IP-пакета последовательно занести адреса следующего доверенного узла, всех транзитных доверенных узлов до конечного и самого узла
получателя.
Достоинствами обоих вариантов алгоритма перенаправления трафика от источника является возможность их реализации стандартными средствами, что приводит и к высокой скорости выполнения последней. Также, немаловажным будет
и достоверность получаемой информации.
33
Вариант гибкой маршрутизации более эффективен в случае отсутствия возможных утечек трафика по недоверенным каналам вдоль доверенного маршрута.
Жесткая маршрутизация же позволит значительно увеличить точность следования
трафика доверенному маршруту (поскольку задает все транзитные узлы); однако
она требует заполнение поля пакета большим количеством адресов.
У алгоритма есть существенные недостатки. Для его применения все транзитные маршрутизаторы должны иметь разрешенную маршрутизацию от источника (то есть, в конфигурационном файле должна отсутствовать строка «no ip
source route»). Также, из-за особенностей формата пакетов и сетей передачи данных, количество записанных IP-адресов ограничено размером соответствующего
поля пакета.
1.5.2 Принудительная
маршрутизация
с
использованием
статических
маршрутов
Как правило, статические маршруты настроены и добавлены в МАТ администратором [105]. Это происходит по ряду причин, таких, как отсутствие динамического маршрута, недоступность протоколов динамической маршрутизации и
проч. Использование статических маршрутов позволяет перенаправить сетевой
трафик по доверенному маршруту, так как данный алгоритм основан на внесении
изменений в текущие конфигурации транзитных маршрутизаторов с целью принудительной отправки пакетов через доверенные узлы.
Алгоритм статической маршрутизации в интересах ДМ состоит из следующих шагов. Во-первых, определяются узлы на доверенном маршруте, через которые трафик может пройти. Во-вторых, происходит подключение (на привилегированном уровне) к доверенным узлам, через которые трафику нужно пройти. Втретьих, производится вставка в их МАТ статических маршрутов с целью направления трафика по доверенному маршруту. В-четвертых, собирается результиру-
34
ющая информация об изменении в МАТ и заносится в информационное хранилище.
Таким образом, алгоритм состоит из следующих шагов:
1) Определение маршрута;
2) Подключение к узлам на выбранном маршруте на привилегированном
уровне;
3) Добавление строки, содержащей информацию о статическом маршруте в
конфигурационный файл каждого узла на выбранном маршруте;
4) Сбор и систематизация ответов от узлов о результатах изменения маршрута;
5) Запись собранных результатов в информационное хранилище.
Основным достоинством алгоритма является крайне высокая гарантия отправки пакетов по заданному доверенному маршруту, на который не повлияют ни
особенности реализации IP-протокола, ни какие-либо ограничения.
Тем не менее, алгоритм имеет очень существенный недостаток. Статическая
маршрутизация приведет к тому, что весь сетевой трафик пойдет по заданному
маршруту. И если такая ситуация полностью подходит для пакетов, передаваемых
в рамках ДМ, то для остальных (пользовательских, служебных) это может стать
критичным.
Также, любое изменение конфигурационных файлов оборудования (в данном случае, с целью управления маршрутизацией) может привести к обнаружению «вторжения» в сеть. Выход же из строя транзитного маршрутизатора приведет к разрыву канала, поскольку при использовании статической маршрутизации
нельзя будет обнаружить отказ узла. Поэтому после передачи информации «в режиме ДМ» (которая не должна занимать много времени) следует сразу восстановить «в исходное» все модифицированные МАТ. Также при перенаправлении
трафика с использованием статических маршрутов необходимо «мониторить» узлы на выбранном маршруте (например, с помощью зондирования).
35
Результаты сравнительного анализа рассмотренных алгоритмов принудительной маршрутизации на предмет их использования в интересах реализации
механизма ДМ приведены в таблице 1.1.
Таблица 1.1 - Результаты сравнительного анализа алгоритмов принудительной маршрутизации
Маршрутизация от
источника
Критерий
«гибкая» «жесткая»
1. Результативность
низкая
средняя
2. Сложность реализации
низкая
низкая
3. Скрытность
высокая
высокая
4. Простота использования
высокая
высокая
5. Расширяемость
низкая
низкая
6. Степень ограничений в работе низкая
средняя
Алгоритм
Маршрутизация с помощью
статических маршрутов
высокая
средняя
низкая
средняя
высокая
средняя
Выбор конкретного алгоритма принудительной маршрутизации делается на
основании их многокритериального сравнения.
Выводы по разделу 1
В качестве объекта исследовались возможности и ограничения «штатных»
средств TCP/IP на предмет их использования в алгоритмах метода реализации механизма ДМ в глобальных ТКС.
В ходе исследования:
1) Проанализированы известные механизмы сетевой защиты, претендующие на доверительную функциональность, и установлены этапы алгоритмизации
механизма доверенной маршрутизации в сетях TCP/IP - создание топологической
карты сети, расширенная идентификация узлов, вычисление доверенного маршрута и принудительная маршрутизация.
2) Исследована возможность создания топологической карты сети с использованием алгоритмов трассировки с помощью опций IP-пакета и стандартных
утилит, а также алгоритмов доступа к МАТ по протоколам BGP и SNMP; разработаны блок-схемы указанных алгоритмов. Предлагается обобщенный алгоритм, ре-
36
ализующий согласование построенных частей карты с последующим разрешением IP-псевдонимов.
3) Рассмотрен способ расширенной идентификации узлов на базе получения информацию об их физическом расположении – определении геопривязки IPадресов. Рассмотрен способ расширенной идентификации узлов обобщенным алгоритмом, для чего исследованы техники прямого воздействия на маршрутизирующее оборудование и перехвата управляющего трафика с использованием специальных протоколов. Установлены достоинства и недостатки рассмотренных алгоритмов для решения задачи идентификации узлов в интересах ДМ.
4) Установлены принципиальные ограничения базового протокола маршрутизации Дейкстры для целей ДМ. Изучены запатентованные алгоритмы, претендующие на повышение степени доверия к получаемому маршруту; установлены
их сильные и слабые стороны с позиции реализации механизма ДМ.
5) Исследованы возможности принудительной маршрутизации «штатными» средствами TCP/IP, для чего проанализированы способы принудительной
маршрутизации с помощью алгоритмов маршрутизации от источника и в случае
использования статических маршрутов. Проведен их сравнительный анализ по
критериям результативности, сложности реализации, скрытности, простоты использования, расширяемости и степени ограничений в работе.
Основным научным результатом, изложенным в первом разделе, является
метод ДМ в глобальных ТКС, суть которого состоит в алгоритмизации следующих этапов механизма ДМ: создание топологической карты сети, расширенная
идентификация узлов, вычисление доверенного маршрута и принудительная
маршрутизация, - с использованием «штатных» средств TCP/IP.
Частным научным результатом, изложенным в первом разделе, являются
установленные ограничения «штатных» средств TCP/IP, необходимых для реализации механизма ДМ в глобальных ТКС.
Основное содержание первого раздела и полученных научных результатов
изложено в работах автора [51-57].
37
2 СИНТЕЗ ПРОГРАММНОЙ АРХИТЕКТУРЫ СИСТЕМЫ УПРАВЛЕНИЯ
ДОВЕРЕННОЙ МАРШРУТИЗАЦИЕЙ
2.1 Разработка специальных средств доверенной маршрутизации
2.1.1 Алгоритм зондирования узлов
Основной недостаток рассмотренных ранее алгоритмов идентификации, а
именно неоднозначность деления узлов на «свои» и «чужие», является довольно
критичным – в ряде случаев необходима максимальная гарантия доверенности
прокладываемого маршрута.
Приемлемым решением может быть модификация ПО оборудования узлов с
целью их однозначной идентификации как «свой» путем внедрения специального
агента, отвечающего на заданные сетевые запросы менеджера, ответственного за
ДМ. Естественно, помимо просто внедрения такого агента, необходима проверка
самого ПО на наличие различного рода закладок, критичных уязвимостей и других особенностей, влияющих на безопасность передаваемых данных, как и корректность активной МАТ. Таким образом, агент, по сути, является гарантом того,
что оборудование узла (включающее также и ПО), является проверенным – а,
следовательно, и доверенным.
Рассмотрим гипотетический способ расширенной идентификации узлов сети с помощью алгоритма зондирования. Пусть в ПО узлов располагаются агенты,
гарантирующие их доверенность. Способ основан на лавинообразной рассылке
зондов и сборе ответов от них. Во-первых, менеджер рассылает зондирующие пакеты по всем инцидентным веткам сети. Во-вторых, каждый агент обрабатывает
поступивший зонд; проверяется, не был ли он уже обработан – ситуация возможна из-за «зацикливаний». Если зонд вновь поступивший, производится его рассылка по всем направлениям, исключая направление-источник зонда. Также агент
производит проверку своего узла и генерирует обратный подтверждающий пакет
38
– они распространяются по той же схеме, что и зондирующие. Если агент получает повторный зондирующий или подтверждающий пакет, то он прекращает их
дальнейшую рассылку. И, в-третьих, менеджер собирает все подтверждающие пакеты и систематизирует их в идентификационную таблицу.
Алгоритм зондирования узлов в схематичном виде представлен на рисунке
2.1.
Рисунок 2.1 - Блок-схема алгоритма зондирования узлов
Предложенный алгоритм позволяет производить идентификацию узлов,
наличие и расположение которых изначально неизвестно, с помощью специальных сетевых пакетов, при этом, исключая риск неограниченного их размножения
и появления зацикливаний.
2.1.2 Модифицированный алгоритм Дейкстры
Исходя из потребностей 3-го основного этапа реализации механизма ДМ, а
также возможностей базового алгоритма маршрутизации и дополнительных алгоритмов, призванных повысить ее доверенность (см. п. 1.4), решением стоящей за-
39
дачи может быть создание модифицированного алгоритма Дейкстры, вычисляющего маршрут с учетом доверенности узлов. В случае наличия на потенциальном
пути недоверенных узлов, они должны по возможности преобразовываться в доверенные с помощью отдельного этапа ДМ. Таким образом, модифицированный
алгоритм Дейкстры будет выполняться итеративно, пока не будет получен полностью доверенный маршрут.
Опишем способ реализации 3-го основного этапа метода ДМ модифицированным алгоритмом Дейкстры. Он практически соответствует базовому алгоритму с тем исключением, что перед обходом очередного узла, последний проверяется на факт доверенности. В случае неподтвержденности этого, обработка узла будет пропущена, а он добавится к списку потенциально-необходимых для преобразования. Если доверенного маршрута алгоритмом не будет найдено, то этот список будет поэлементно передан в отдельный этап метода ДМ для преобразования
узлов в доверенные. В случае успешности преобразования повторный запуск алгоритма позволит обработать ранее пропущенные узлы, что поможет найти необходимый маршрут.
Блок-схема модифицированного алгоритма Дейкстры представлена на рисунке 2.2; опишем его работу. Сначала инициализируем RD - множество узлов/вершин сети - и помечаем их как непосещённые C. Также инициализируем
D(S):=0, где S - метка самой вершины, D - множество метрик маршрутизации
(например, расстояние или стоимость хопа), а также P:=¥, который по окончании
работы алгоритма является кратчайшим путем из S в N, а вначале еще не найден
(не определен).
После инициализации каждой вершине из RD сопоставим метку D(n), которая по окончании работы алгоритма равна длине кратчайшего пути от узла/вершины S (от которой ищутся доверенный маршрут) до посещаемого узла N,
метку D(z) − минимальное известное расстояние от узла Z до узла S, а также метку D(zn) − минимальное известное расстояние от вершины N до узла Z.
40
Рисунок 2.2 - Блок-схема алгоритма модифицированного алгоритма Дейкстры
Алгоритм работает пошагово и на каждом шаге он посещает одну вершину.
Метка самой вершины S полагается равной 0, метки остальных вершин - бесконечности, пока они являются непосещенными, что отражает факт, что расстояния
от S до других вершин пока неизвестны.
Далее выбираем S и определяем ее как Z (S:=Z). Каждый раз из ещё не посещённых вершин RD (то есть, среди C) выбирается соседняя вершина N, подключенная к S и имеющая минимальную метку D(n), при условии, что узел N является доверенным (или существует возможность его контроллинга), и определяется как Z. Вершины, в которые ведут рёбра из Z, отмечаем как соседи этой вершины. Далее рассматриваем всевозможные маршруты, в которых Z является
предпоследним пунктом.
41
Для каждого соседа вершины/узла N, кроме отмеченных как посещённые,
вычисляем новую длину пути, равную сумме значений текущей метки Z и длины
ребра, соединяющего Z с этим соседом. Если полученное значение длины меньше
значения метки соседа, заменяем значение метки вычисленным значением длины.
Определяем пути от Z к S как P. Рассмотрев всех соседей, помечаем вершину Z
как посещённую и повторяем шаги алгоритма, пока N не сравняется с T. По окончании, то есть когда N является конечной вершиной/узлом T, реверсируем P. Полученный результат будет кратчайшим доверенным маршрутом от S к T. Данный
алгоритм входит в состав устройства ДМ в ТКС, защищенного патентом [59].
Пример,
иллюстрирующий
работу
модифицированного
алгоритма
Дейкстры в сравнении с базовым, представлен на рисунках 2.3 - 2.5.
Пусть имеется графовая модель ТКС (см. рисунок 2.3), в которой есть несколько устройств маршрутизации (RD), обозначенных как S, A, B, C, D, E, F, G,
Y, T, и где каждый узел соединен дугами с другими узлами; дуги имеют определенный вес, соответствующий расстоянию между узлами; при этом узлы B и G
являются недоверенными.
F
9
A
1
3
1
H
4
1
B
1
4
S
D
2
3
T
1
3
3
C
2
3
G
2
E
Рисунок 2.3 - Графовая модель ТКС
В случае выбора маршрута с применением базового алгоритма (алгоритма
Дейкстры) он пройдет через узел B (см. рисунок 2.4), что в рамках задачи текущего этапа является недопустимым.
42
F
9
A
1
1
3
1
H
4
B
1
4
S
D
2
3
T
1
3
3
C
2
3
G
2
E
Рисунок 2.4 - Пример вычисления маршрута (алгоритм Дейкстры)
При использовании модифицированного алгоритма Дейкстры маршрут минует
узлы B и G (см. рисунок 2.5), что позволяет позиционировать его как доверенный.
Рисунок 2.5 - Пример вычисления маршрута (модифицированный алгоритм Дейкстры)
В авторском патенте [59] показано, что при вычислении доверенного маршрута с помощью модифицированного алгоритма Дейкстры (см. рисунок 2.2),
определение уровня доверия узлам может осуществляться по множеству параметров {a, b, c, d}, где a – определяет аутентификации, которые узел способен выполнять при проверке его физического местоположения, поскольку уровень доверия узлов может быть неприемлемым из-за их особого географического расположения; b – определяет узел, известный маршрутизатору отправителя как недоверенный из-за недоверия стране или корпорации, в которой этот узел находится; c
– определяет средние значения измерений физического местоположения узла, полученные с помощью «пингования» сети (физическое расположение узла может
быть определено путем его размещения в известном безопасном месте, например,
43
на закрытой базе или в правительственном здании; d – характеризует информацию, найденную в узле, хранящуюся с целью идентификации (например, программный модуль в виде агента).
Поскольку после каждого выполнения алгоритма будут выбираться узлы
для преобразования в доверенные, создание доверенного маршрута полностью
может занимать определенное время. Но при необходимости время может быть
уменьшено путем предварительного единовременного преобразования большой
группы узлов в доверенные, и этим давать модифицированному алгоритму
Дейкстры возможность найти маршрут за одну итерацию. Для этого возможно
вычисление всех или определенного количества возможных маршрутов от источника до получателя – активных маршрутов - и преобразование их узлов в доверенные.
Для решения этой задачи предлагается использовать алгоритм X-BDV (от
англ. bidirectional version of Dijkstra's algorithm - упрощенная версия двунаправленного варианта алгоритма Дейкстры), с помощью которого можно найти кратные маршруты (кратчайшие маршруты и локально оптимальные) между двумя
вершинами на ориентированном графе с неотрицательными, целыми весами по
краям. Это алгоритм описан в недавнишнем исследовании [3, 106]. Результаты
экспериментов, приведенные в [3], показали, что алгоритм X-BDV по-настоящему
практичен для «континентального» размера сети и является быстрым по сравнению с другими подобными алгоритмами.
Таким образом, использование алгоритма Х-BDV гипотетически сокращает
время нахождения доверенного маршрута, так как существует возможность его
получения из первых альтернативных кратчайших маршрутов, что уменьшает потребное количество преобразуемых в доверенные узлов.
Блок-схема такого синтетического (совместного использования Х-BDV и
модифицированного Дейкстры) алгоритма нахождения доверенного маршрута
приведена на рисунке 2.6.
44
Рисунок 2.6 - Блок-схема нахождения доверенного маршрута с помощью алгоритма XBDV и модифицированного алгоритма Дейкстры
2.1.3 Способы контроллинга узлов
Рассмотрим способы получения удаленного управления узлами в интересах
ДМ - контроллинга (от англ. to control - управлять). Суть организации контроллинга улов состоит в удаленном доступе к его оборудованию с последующим
внедрением агента ДМ в программное обеспечение маршрутизатора. Поскольку
по соображениям безопасности удаленное управление оборудованием узла не
предусмотрено, то оно может быть получено лишь с помощью нештатных возможностей, например, используя уязвимости протоколов, обеспечения, настроек
оборудования и т.п. [107] – то есть, создания специальных средств ДМ.
45
2.1.3.1. Техники и утилиты удаленного доступа к узлам сети
Исследуем основные техники, реализующие удаленный «нештатный» доступ к телекоммуникационному оборудованию на примере маршрутизаторов
компании Cisco (как наиболее распространенных), а также используемые при
этом утилиты на предмет применения в качестве средства для контроллинга.
1) Перехват SNMP-трафика.
Аналогично технике расширенной идентификации узлов путем перехвата
SNMP-трафика, эти пакеты могут содержать строку доступа, с помощью которой
возможно не только чтение, но и запись данных в конфигурационные файлы оборудования на узле (в случае, если используется одна и та же строка). Для перехвата возможно применение утилиты shell-скрипта snmpsniff.sh, разработанной Nuno
Leitao [108].
Пример запуска и результат работы утилиты показан ниже:
>snmpsniff.sh
snmpsniffer: listening on eth0
(12:00:00) 192.168.0.1 (secret)->> 192.168.0.2 (ReqID: 123456789)
Как хорошо видно, утилита определила для маршрутизатора 192.168.0.1
строку доступа на чтение данных – secret, которая может оказаться также и строкой доступа на запись. Также, выявился узел 192.168.0.2, который может иметь
такую же строку доступа.
На данный момент известны 3 версии протокола SNMP, определяющие 3
модели безопасности. Безопасность у SNMPv1 основана на строках доступа, как и
у SNMPv2c. Но у SNMPv3 безопасность доступа обеспечивается комбинацией
аутентификации и шифрования передаваемых по сети пакетов [109]. SNMPv3
поддерживает модели безопасности (стратегии аутентификации, которые устанавливаются для пользователя и группы, в которой он находится) и уровни безопасности (разрешенные уровни в модели безопасности). Их комбинация определяет, какой механизм безопасности применяется при обработке SNMP-пакета (см.
таблицу 2.1).
46
Таблица 2.1 - Модели и уровни безопасности протокола SNMP
Модель
v1
v2(c)
v3
v3
v3
Уровень безопасности
noAuthNoPriv
noAuthNoPriv
noAuthNoPriv
authNoPriv
authPriv
Аутентификация
Строка доступа
Строка доступа
Имя пользователя
MD5 или SHA
MD5 или SHA
Шифрование
Нет
Нет
Нет
Нет
DES
2) Перебор пароля SNMP
Строками доступа для SNMP по умолчанию являются «public» для чтения и
«private» для записи. Строка может быть подобрана, как по словарю, так и полным перебором символов. Словарь может быть составлен на основе информации
об интересующем узле, полученной, например, с его Web-сайта или на этапе расширенной идентификации метода ДМ. При необходимости возможно использование более объемных словарей, таких как в стандартном файле wordfile ОС
Linux.
Для прямого перебора строк доступа SNMP существуют такие утилиты, как
ADMsnmp, UDC-SNMP, Solarwinds и др. Утилиты осуществляют перебор по словарю, пытаясь получить доступ к узлу и сообщая о результатах.
Для применения данной техники, возможно, потребуется обеспечить доступ
к SNMP-агенту, минуя фильтрацию по спискам правил.
3) Перебор пароля telnet
Telnet является незащищенным сетевым протоколом взаимодействия с узлом, который может быть использован для удаленного доступа к его оборудованию. Для этого можно осуществить перебор паролей, начиная с наиболее распространенных или содержащихся в словарях, и заканчивая полным перебором символов. Для прямого перебора паролей telnet (как и множества других сервисов)
существуют множество утилит.
Хотя протокол может быть взломан путем перебора пароля, тем не менее
(по причине ненадежности) от него, как от средства управления ОС, зачастую отказываются в пользу SSH (Secure Shell); последний предназначен именно для безопасного удаленного управления [110].
47
4) Сбор информации о сети с помощью расширенной идентификации
Информация, собранная на этапе расширенной идентификации (см. п. 2.2),
не может быть применена для получения непосредственно удаленного доступа к
узлам. Однако она может использоваться для анализа сети с целью поиска способов получения удаленного доступа, сокрытия их факта, составления расширенных
словарей перебора паролей и т.п. Так, сетевые кадры CDP и SNMP содержат IPузлов, данные об их оборудовании, версии ПО, возможные именах пользователей
и другую информацию.
Достоинством данной техники является достаточно тривиальное получение
полезной информации из полуоткрытых источников.
5) Перебор имен пользователя из идентификационных служб
Часто оборудование узлов поддерживает расширенную идентификацию
(помимо пароля) с использованием имени пользователя. В этом случае потребуется перебор имен пользователя, полученных с помощью идентификационных
служб.
Одна из таких служб использует finger – сетевой протокол, предназначенный для предоставления списков пользователей удаленного компьютера и информации о них: имя регистрации в системе, полное имя, имя терминала, статус
записи, время простоя, время регистрации, нахождение места работы, телефонный номер и т.п.
Пример запуска и полученной информации показан ниже:
>finger @example.com
Login Name Idle Login Time Office Phone
root root 1:00 Oct 20 6:00 123-4567
user I Am 2:00 Oct 20 9:00 333-4455
Как хорошо видно, утилита вернула информацию о пользователях узла example.com, включающую имена их учетных записей и время входа в систему; это
может быть использовано для попытки входа в систему в интересах ДМ.
48
Тем не менее, сервис finger из соображений безопасности, как правило, не
предоставляется в сети; а при его наличии возможна блокировка учетной записи
пользователя после нескольких неудачных попыток подбора пароля.
6) HTTP-уязвимость оборудования Cisco
Известна HTTP-уязвимость (HTTP Configuration Arbitrary Administrative Access Vulnerability), затрагивающая большинство оборудования Cisco и обнаруживаемая большинством сканеров уязвимостей [111]. Она предоставляет возможность удаленного администрирования целевого маршрутизатора с использованием простого Web-браузера. Уязвимость раскрывает конфигурацию атакуемого
оборудования, используемые интерфейсы, списки управления доступом (ACL –
Access Control Lists), SNMP-строки и пароли (в открытом или зашифрованные виде).
Пароли в файле конфигурации, как правило, хранятся в следующих форматах: Clear Text, Vigenere и MD5. Первый представляет собой хранение в открытом
виде и не требует дополнительных действий для его расшифровки. Формат второго является простой формой многоалфавитной замены и для его расшифровки
возможно использование утилиты GetPass [112]. Наиболее безопасным форматом
хранения паролей является одностороннее MD5-хеширование, алгоритма декодирования которого не существует. Однако, в этом случае можно выполнить «словарную атаку» или прямой перебор – для этого может быть использована утилита
«Cain and Abel» [113].
Хотя использование данной уязвимости практически полностью решает задачу удаленного управления оборудованием узла, однако при «правильном» администрировании она будет исправлена в первую очередь.
7) Уязвимости DHCP-сервиса оборудования Cisco
Устройства Cisco могут обеспечивать выделение адресов и установку конфигурационных параметров узлов – то есть они могут работать как DHCP- серверы. Кроме того, устройства могут пересылать пакеты DHCP и BootP, работая в
этом случае как трансляторы. Обычно при получении DHCP-пакета, он помеща-
49
ется во входную очередь для последующей обработки. Пакеты DHCP, которые не
удалось доставить, сохраняются в очереди. При заполнении очереди устройство
будет прекращать прием всех пакетов из данной сети; для этого достаточно просто передать множество некорректно сформированных пакетов – осуществить
DoS-атаку. Таким образом, передавая специально сформированные пакеты атакуемому устройству можно полностью блокировать его обработку входящего трафика. Для восстановления работоспособности устройства потребуется перезагрузка.
Уязвимость устройств сохраняется независимо от того, используются ли
они в качестве серверов или трансляторов DHCP, и поэтому, для запрета сервиса
DHCP требуется явное включение команды «no service dhcp» в конфигурационный файл устройства [111]. Отсутствие этой команды не означает, что сервис не
поддерживается устройством; его необходимо явно отключить с помощью приведенной выше команды.
Как правило, подобные уязвимости достаточно быстро исправляются и
включаются в новые версии ОС оборудования.
8) Уязвимости telnet-сервиса оборудования Cisco
Telnet, аналогично DHCP-сервису оборудования Cisco, также подвержен
DoS-атаке. В случае успешности атак, сервис становится недоступным. Атака
может быть объединена с другими прямыми атаками на сеть, как часть скоординированной попытки закрыть администратору доступ к базовому оборудованию.
Как правило, подобные уязвимости достаточно быстро исправляются и
включаются в новые версии ОС оборудования.
9) SNMP-уязвимости переполнения ловушек
В SNMP существуют особые сигналы – «ловушки» [114, 115], отправляемые устройствами для оповещения администратора сети о наступлении какихлибо критических событий, требующих немедленного вмешательства. События
могут быть крайне широкого диапазона: от неудачной попытки авторизации до
перехода оборудования на питание от батарей. Уязвимость заключается в том,
50
что число отправляемых «ловушек» существенно ограничено (не чаще 4-х раз в
секунду на каждый адрес). Таким образом, генерация большого числа SNMPзапросов приведет к созданию ложных «ловушек», что заблокирует обработку истинных, и атаки на устройства (такие, как подбор пароля/строк доступа и/или допустимого адреса источника пакета, удаленное управление устройством, его перезагрузка и т.п.) будут скрыты.
Техника состоит в генерации большого числа ложных SNMP-запросов во
время проведения атаки, не давая обрабатывать истинные «ловушки». Соответственно утилиты, необходимые для реализации алгоритма, должны осуществлять
автоматическую генерацию потока таких запросов (одинаковых или, например,
эмулирующих подбор пароля). Они позволяют скрыть неуспешные попытки авторизации и удаленного управления устройством путем блокирования генерируемых в процессе «ловушек» при отсутствии ограничений по конфигурации сети.
Однако такая техника обладает следующими недостатками. Во-первых, она
не может гарантировать, что все истинные «ловушки» будут заблокированы, поскольку некоторые из них могут попасть в число обработанных. И, во-вторых, такая многочисленная генерация ложных «ловушек» может привлечь внимание
средств мониторинга сети и впоследствии администратора.
Таким образом, для обеспечения удаленного доступа к оборудованием узлов потребуется совместное применение различных техник, поскольку каждая
конкретная ситуация доступа к МО возможна отдельным способом.
2.1.3.2. Алгоритм внедрение программных агентов в ПО маршрутизаторов
Наличие агента в доверенном узле необходимо, как минимум, по двум причинам. Во-первых, требуется обеспечить гарантии того, что ПО его оборудования
не содержит закладок и работает требуемым образом. Во-вторых, следует иметь
средство для принудительного управления маршрутизацией узла. Возможным ва-
51
риантом этого является модификация исходной версии ПО для добавления требуемого функционала.
Способом решения задачи является модификация исходной версии ПО оборудования узла путем добавления специальных программных модулей (ПМ) в
форме агентов (для идентификации/проверки и маршрутизации), имеющих требуемый функционал. Возможный алгоритм реализации способа может состоять из
следующих последовательных шагов: получить удаленный доступ к узлу для скачивания ПО; скачать и проверить ПО оборудования; встроить ПМ в ПО; получить
удаленный доступ к оборудованию узла; загрузить доверенное и модифицированное ПО.
Однако в этом случае процесс преобразования узла в доверенный может занять ощутимое время, что в реальных условиях работы сети недопустимо. Получение удаленного доступа, скачивание исходного ПО и загрузка модифицированного занимают немного времени по сравнению с его проверкой и встраиванием
ПМ. Отсюда следует целесообразность разделения алгоритма на две стадии –
подготовительную и основную.
На первой стадии должна быть создана база ПО оборудования узлов сети,
проверенного и с внедренными агентами. На второй происходит собственно замена исходного ПО на модифицированное.
Подготовительная стадия алгоритма не входит непосредственно в метод
ДМ, поскольку выполняется до его применения. Также она, по мере необходимости, будет дополняться поддержкой ПО нового оборудования. Хранение исходного ПО пригодится в случае дополнительных задач, таких, как восстановление исходного состояния узла, повторная модификация и т.п. Все варианты ПО, как и
идентификационную информацию о содержащем их оборудовании, целесообразно хранить в специальном информационном хранилище (ИХ). Время выполнения
стадии не существенно, так как не влияет на построение доверенного маршрута за
разумное время.
52
Основная стадия алгоритма предназначена для замены ПО оборудования на
модифицированное, взятое из ИХ. Стадия должна проидентифицировать оборудование узла, запросить модифицированное ПО для этого оборудования у ИХ и
произвести замену исходного. Для идентификации оборудования и получения
удаленного доступа может быть использована информация, полученная на этапе
расширенной идентификации узла, такая как модель оборудования, версия ОС и
способ (по возможности) получения удаленного доступа. Время выполнения стадии минимально, поскольку она может быть полностью автоматизирована.
Таким образом, алгоритм внедрения программных агентов в ПО маршрутизаторов состоит из следующих, разнесенных во времени, стадий. Подготовительная: получить удаленный доступ к оборудованию узла для скачивания ПО ® скачать ПО оборудования ® проверить ПО оборудования ® встроить ПМ в ПО как
агент ДМ. Основная: проидентифицировать оборудование узла ® получить модифицированное ПО из ИХ по идентификации оборудования ® получить удаленный доступ к оборудованию узла для загрузки ПО ® загрузить модифицированное ПО.
В качестве обоснования существований подобной технической возможности приведем известные применяемые подходы и существующие реализации подобных задач для маршрутизаторов компании Cisco, ПО которых содержит собственную операционную систему – IOS (Internetwork Operating System, Межсетевая Операционная Система).
IOS с точки зрения задачи встраивания ПМ не имеет особых отличий от типичного ПО и представляет собой набор взаимодействующих модулей (согласно
задачам программы), состоящих из функций (каждая из которых решает отдельную подзадачу). Однако встраиваемый код (в данном случае, программный код
агентов) должен разрабатываться с учетом архитектуры исходного ПО – обеспечивать как функционирование остального кода, так и взаимодействие встраиваемого модуля с другими. Возможна, как подмена отдельных функций, так и моду-
53
лей в целом. Также, встроенный модель должен быть максимально незаметен для
пользователей и администратора сети.
Примерами подобных ПМ (но работающих по другим причинам или критериям) являются halluxwater, stuccomontana, genie, gourmettrough, souffletrough, jetplow, sierramontana, headwater и feedtrough, которые можно найти не только в Cisco, но и в телекоммуникационных устройствах Juniper или Huawei. Для некоторых
вариантов ПО (в частности для оборудования Cisco) требуется выполнение вспомогательных действий, таких как начальная распаковка и последующая запаковка
ПО, с возможным пересчетом контрольных сумм или изменением цифровой PKIподписи данных и вложением соответствующего сертификата.
В работе [116] показано использование дизассемблера IDA Pro, поддержанного скриптами на языке IDA Python, для решения задачи распознавания строк.
Задача выполнялась путем поиска известных типов сегментов кодов и ссылок на
данные.
Типичными размещениями встраиваемого кода могут быть различные области, такие как информация об отладке, незанятые сегменты кода, редкоиспользуемые функции, текстовые строки и т.п.
Судя по работам авторов в [116-118] внедрения ПМ в ПО состоит из следующих шагов: идентифицировать версию ПО ® распаковать образ ПО и дизассемблировать его в IDA ® проанализировать дисассемблированный образ и исправить ошибки ® разработать внедряемый ПМ ® выбрать область и подготовить ее для внедрения ® внедрить ПМ в выбранную область ® подключить
внедренный модуль ® упаковать модифицированный образ ПО с необходимыми
корректировками (контрольные суммы и т.п.).
Блок-схема подобного алгоритма внедрения программных агентов в ПО
маршрутизаторов приведена на рисунке 2.7.
54
Рисунок 2.7 - Блок-схема алгоритма внедрения программных агентов в ПО
маршрутизаторов
Достоинствами такого алгоритма (в случае успешности его применения) является как высокая гарантированность доверия узлу, так и тот факт, что ПО узла
останется доверенным не только на период использования текущего маршрута, но
и в дальнейшем.
К недостаткам алгоритма можно отнести сильную зависимость от удачности выполнения этапа удаленного доступа к узлу.
55
2.2 Программная архитектура системы управления доверенной
маршрутизацией
2.2.1 Требования к структуре системы управления ДМ и функционалу ее
элементов
Необходимая взаимообусловленность и предполагаемая конфликтность
«штатных» алгоритмов и специально разработанных средств ДМ указывает на то,
что для их совместного функционирования потребуется соответствующая система
управления (СУ). Наличие СУ приводит к появлению принципиально нового метода реализации механизма ДМ (далее - Метод).
Обоснуем требования к СУ ДМ, для чего рассмотрим этапы Метода. Гармонизированный прототип Метода состоит из основных (О_№) и вспомогательных
(В_№) этапов: О_1 - создание топологической карты сети; О_2 - расширенная
идентификация узлов сети; О_3 - вычисление доверенного маршрута; О_4 - принудительная доверенная маршрутизация; В_1 - обеспечение удаленного управления узлом (контроллинг); В_2 - преобразование узла в доверенный. При этом
этапы О_1 - О_4 должны выполняться последовательно, а этапы В_1 и В_2 - в
случае необходимости. Так, в случае невозможности выполнения этапа О_3, для
недоверенных, но потенциально-необходимых узлов должен быть выполнен этап
В_2 с предшествующим ему вспомогательным этапом В_1.
В соответствии с вышеизложенным, Метод ДМ состоит из набора этапов,
каждый из которых инициируется по сигналу из единого места – следовательно, в
структуре СУ должен центральный элемент – менеджер ДМ (МДМ). Большинство этапов Метода реализуются с помощью одинаковых и равноправных агентов
ДМ (АДМ), встроенный в ПО узлов – что приводит к требованию построения СУ
ДМ, как распределенной.
Для Этапа О_1 отсутствует необходимость в создании отдельного элемента
СУ, однако информация о топологической карте сети должна хранится в выде-
56
ленной базе данных (БД). Этап О_2 требует распределенных по узлам АДМ для
идентификации и централизованного МДМ для сбора и анализа информации.
Этап О_3 требует централизованного элемента для хранения БД и алгоритмов построения доверенного маршрута. Этап О_4, как указывалось, требует централизованного элемента для управление статическими маршрутами или маршрутизацией от источника. Этап В_1 является лишь набором алгоритмов по обеспечению
удаленного доступа и не должен содержать элементов системы. Этап В_2 использует элемент АДМ, который внедряется в недоверенный узел.
Для полноценной работы ДМ необходимо не только создание маршрута, но
и отслеживание его состояние на всем протяжении передачи данных. Иначе в
случае сбоя одного из элементов СУ (например, один из агентов будет скомпрометирован и узел станет недоверенным), маршрут уже не будет считать доверенным, поскольку безопасность в этом случае не гарантируется. Следовательно, на
всем протяжении выполнения этапов метода необходим мониторинг их состояния, и в особенности самого доверенного маршрута. Целесообразно ответственным за это сделать центральный элемент системы – МДМ.
Поскольку инициатором создания доверенного маршрута и отправкой по
нему данных является один и тот же субъект, то имеет смысл располагать центральный элемент на узле, с которого планируется передача данных – на первом
узле доверенного маршрута.
Метод ДМ основан на взаимодействии реализующих его элементов.
Например, на одном из этапов информация собирается и записывается в БД (топологическая карта сети) в одной части СУ (МДМ), на очередном идет обработка
этой БД и получение другой информации (доверенные маршруты), на следующем
эта информация частично передается в другие части СУ (АДМ). Таким образом,
для организации работы СУ ДМ необходимо создание канала информационного
взаимодействия (КИВ).
Поскольку инициатором всех действий является центральный элемент
(МДМ), а исполнителями – различные подчиненные элементы (АДМ) и БД, то ка-
57
нал следует сделать двунаправленным; каждому запрашиваемому действию в нем
будет соответствовать отдельный запрос (от МДМ к АДМ или БД) – специальная
инструкций (например, инструкция получения идентификатора АДМ или собранной геоинформации об узле). Необходимо также поддерживать и инструкции с
результатами выполнения действий и полученными данными, передаваемые в обратном направлении (от АДМ к МДМ). Первый вид будем называть «инструкциями-действиями», а второй – «инструкциями-ответами» (или «инструкциямирезультатами»).
Работа СУ должна быть максимально незаметна для внешних наблюдателей
(сетевых сканеров, администратора), поэтому сетевое взаимодействие элементов
системы целесообразно построить на базе широко-распространенных протоколов.
Безопасность данных обеспечивается множеством устройств, идентифицированных и настроенных согласно ДМ – следовательно, доверенностью должны
обладать не только узлы, но и способы взаимодействия с ними. Таким образом,
необходима защита информационного канала, например, шифрованием (в случае
его локального применения в пределах одного устройства такая задача не стоит).
Согласно задачам, выполняемым этапами ДМ, элементы СУ (совместно
и/или по отдельности) должны обладать различным функционалом. Поскольку
Метод инициируется по необходимости (когда требуется создать доверенный
маршрут), то он должен стартовать по запросу. Следовательно, необходим базовый функционал по управлению всем процессом применения Метода – его запуска, останова и контроля выполнения. Можно сделать упрощение, согласно которому все управление происходит на центральном элементе с помощью стандартного интерфейса (такого, как командная строка, Web-интерфейс, скрипты, API и
др.).
Создание топологической карты сети требует возможности генерации
настраиваемых сетевых пакетов и запуск стандартных утилит. Расширенная идентификация узлов с помощью зондирования возможна при информационном обмене центрально узла с распределенными, являющимися доверенными. В ином
58
случае, при идентификации (для контроллинга) должны использоваться алгоритмы по сбору информации о МО. Доверенный маршрут вычисляется по собираемой и анализируемой информации с помощью применения алгоритмов на графе
узлов, поэтому необходима поддержка БД и функционала по работе с ней. Принудительная маршрутизация обеспечивается либо маршрутизацией от источника
– для этого необходима генерация настраиваемых сетевых пакетов, либо модификацией статических маршрутов в МАТ оборудования узлов – для этого центральный элемент должен получить доступ к соответствующему контролирующему
оборудованию и произвести необходимое изменение в его МАТ. Для обеспечения
удаленного доступа используется информация, собранная на предыдущих этапах
метода (топология сети, информация об оборудовании, перехваченном трафике).
В процессе выполнения всех этапов необходима проверка успешного выполнения всех их задач и алгоритмов (в особенности, для удаленных по сети) –
для этого для каждого функционала требуется поддержка результата его выполнения. Применение защищенного канала информационного взаимодействия требует от элементов поддержки шифрования и согласование его параметров. Также
следует отметить, что элементы СУ не выполняют никаких действий над передаваемыми данными, а лишь обеспечивает безопасность их передачи.
Целесообразно разделить функционал по элементам согласно его типу в системе: часть функционала должна быть централизована в МДМ, поддерживать
основную ветку Метода и контролировать выполнение всех этапов ДМ, а часть
должна находиться на распределенных по сети элементах (в АДМ) – быть вспомогательной и подчиняться центральному элементу.
Таким образом, СУ ДМ должна состоять из следующих элементов:
− центрального элемента – МДМ (выполняющего роли: управления ДМ;
ИХ; менеджера расширенной идентификации, принудительной маршрутизации;
монитора состояния системы; пространства алгоритмов работы с информацией
БД – графами топологических карт сети, формализованными МАТ, таблицами доверенных узлов, списками возможных и доверенных маршрутов и т.п.);
59
− множества равноправных элементов – АДМ (внедренных в узлы и выполняющих роль идентификатора узла как доверенного.
Элементы системы взаимодействуют с помощью специального информационного канала – КИВ, который может быть локальным или сетевым, и при этом
должен являться защищенным и скрытым (за счет построения на базе широкораспространенных протоколов).
Резюмируем требования к функционалу элементов СУ ДМ. Для МДМ это
работа с сетью, поддержка шифрования, отправка «инструкций-действий» и анализ «инструкций-результатов», контролирование состояния системы, работа с БД,
генерация сетевых пакетов, запуск сетевых утилит, вывод информации для анализа, синхронизация этапов, их алгоритмов и общее согласования процесса ДМ,
предоставление интерфейса для управления Методом. Для АДМ это также работа
с сетью и поддержка шифрования, обработка «инструкций-действий» и их выполнение с возвратом «инструкций-результатов», идентификация подконтрольного
узла, управление конфигурацией подконтрольного оборудования.
2.2.2
Программная структура менеджера и агентов ДМ
Опишем архитектуру СУ ДМ с помощью структуры взаимосвязи ее элементов, программной структуры каждого элемента, их интерфейсов и протокола взаимодействия, учитывая, что каждую группу функциональных возможностей реализуют составляющий элемент программные модули (модульная парадигма программирования).
Изучение принципов современного управления сетью [18-20, 24-30, 119],
существующих типов архитектур [21-23, 31-37, 120-123], а также подходов к
идентификации и работе с БД, вопросов сетевой безопасности и мониторинга
позволило синтезировать следующую структуру СУ ДМ (рисунок 2.8).
Инструкции-результаты
Ин
Се
ст р
т
укц евой к
ана
иид
ейс л
Ин
тви
стр
укц
я
иирез
уль
тат
ы
Инструкции-действия
Преобразование в доверенный
60
с
про
За
ык
ра
ве
сер
HO
мW
IS
Рисунок 2.8 - Структурная схема СУ ДМ
Представленная структура СУ ДМ соответствует сформированным выше
требованиям. МДМ является центральным, а АДМ – подчиненными элементами.
МДМ взаимодействует с АДМ через сетевой защищенный информационный канал посредством запросов «инструкций-действий» и ответов «инструкцийрезультатов». БД связана с МДМ локальным незащищенным информационным
каналом. Также часть функционала МДМ, такого как запросы к серверам WHOIS
и построение карты сетевой топологии, выполняются с помощью стандартных
утилит и протоколов через открытую сеть. МДМ имеет средства вывода собранной информации в формализированном виде: эта информация будет использована
для получения удаленного доступа к оборудованию узлов и внедрения АДМ (будет выполнен этап преобразования узлов в доверенные).
Для программной реализации требуемого функционала МДМ элемент целесообразно выполнить из следующих программных модулей. Во-первых, необходим основной модуль выполнения этапов метода ДМ (ВЭДМ-модуль). Он должен
обеспечить взаимодействие всех остальных модулей, инициализацию, выполнение, синхронизацию и мониторинг их алгоритмов. Во-вторых, для управления
61
ВЭДМ-модулю необходим модуль интерфейса взаимодействия (ИВ-модуль),
поддерживающий операции внешнего запуска Метода, его остановки и базового
контроля (например, ведение логов, приостановка, внесение изменений в промежуточные данные). В-третьих, модуль сетевого взаимодействия менеджера (СВМмодуль) обеспечит взаимодействие МДМ с сетью, такое как отправка и прием пакетов, шифрование данных, запуск сетевых утилит. В-четвертых, взаимодействие
с БД целесообразно также вынести в отдельный модуль (БД-модуль), который будет предоставлять высокоуровневый интерфейс для работы с данными другим
модулям (например, получение IP-адресов доверенного маршрута). В-пятых, для
поддержания маршрута в состоянии доверенного требуется наличие модуля проверки узла (ПУ-модуль). В-шестых, для двухэтапного обеспечения процесса преобразования узлов в доверенные целесообразно выделить отдельный модуль контроллинга узлов (КУ-модуль). И, в-седьмых, для принудительной маршрутизации
потребуется соответствующий модуль (ПМ-модуль).
Модуль анализа информации (АИ-модуль) предназначен для аналитической
обработки информации. БД расположена на рабочей станции в начальном узле (то
есть, локально) и хранит информацию, используемую в процессе выполнения Метода. Модульная программная структура МДМ, включая все внутренние и внешние взаимодействия, приведена на фрагменте а) рисунка 2.9.
ВЭДМ-модуль по сути управляет БД-модулем, СВМ-модулем и АИмодулем, которые можно считать вспомогательными в рамках структуры элемента. БД-модуль осуществляет взаимодействие с БД посредством инструкций,
предоставляя лишь данные по запросу. СВМ-модуль поддерживает весь сетевой
функционал, в частности посылку инструкций к АДМ.
ПУ-модуль осуществляет мониторинг состояния системы путем проведения
периодической расширенной идентификации узлов на доверенном маршруте
средствами СВМ-модуля. В случае обнаружения недоверенного узла на пути передаваемых данных ПУ-модуль сигнализирует об этом в ВЭДМ-модуль, что приводит к мгновенному прекращению использования уже недоверенного маршрута
62
с возможным поиском иного - доверенного. Таким образом, ПУ-модуль работает
параллельно с ВЭДМ-модулем в фоновом режиме и, в этом смысле, является «демоном МДМ».
а) МДМ
б) АДМ
Рисунок 2.9 - Модульная программная структура элементов СУ ДМ
По запросу от ВЭДМ-модуля КУ-модуль инициирует процесс преобразования узла в доверенный. Для этого он использует формализованную информацию
об узле и формирует запрос на получение модифицированного ПО. Все эта информация уже хранится в БД. В ответ модуль получает требуемое ПО, которое загружает на оборудование узла путем автоматизированного удаленного доступа к
узлу, например, с помощью FTP (TFTP). Также по запросу от ВЭДМ-модуля ПМмодуль инициирует процесс принудительной маршрутизации. Для этого он получает информацию о доверенном маршруте из БД и производит перенаправление
трафика вдоль этого маршрута.
Для программной реализации требуемого функционала элемент АДМ целесообразно выполнить из следующих программных модулей. Во-первых, необходим основной модуль проведения проверки узла (ПУ-модуль) для самопроверки
самого агента, проверки неизменности ПО оборудования и корректности данных
63
узла. Во-вторых, как и в МДМ, необходим сетевой модуль, который, помимо
расшифровки сетевых пакетов, сможет их обрабатывать, выделять специальные
типа «инструкции-действия», определять передаваемую в них информацию о действии и генерировать «инструкции-ответы». И, в-третьих, в случае необходимости изменений конфигурации узла (включение/выключение некоторых служб или
внесение статического маршрута), потребуется модуль управления конфигурацией (УК-модуль).
Модульная программная структура АДМ, включая все внутренние и внешние взаимодействия, приведена на фрагменте б) рисунка 2.9.
Элемент АДМ лишь выполняет полученные от МДМ инструкции, поэтому
не имеет центрального модуля. Схема его работы построена на выполнении запрашиваемых в инструкциях действий. Модуль сетевого взаимодействия агента
(СВА-модуль) на основании анализа сетевых пакетов выделяет предназначенные
ему инструкции, дешифрует их (при необходимости) и отправляет одному из модулей: в ПУ-модуль, если запрашивается проверка узла; в УК-модуль, если требуется изменение конфигурации узла.
Среда, образованная программными модулями МДМ и АДМ, получила
название TraConDa, которое является акронимом от слов Transfer Confidential Data (от англ. Передача Конфиденциальных Данных).
2.2.3 Протокол канала информационного взаимодействия
КИВ, согласно структуре системы управления ДМ, предназначен для обмена информацией между ее элементами и модулями, поэтому должен обладать
собственным протоколом обмена. Построение полноценного КИВ на базе стандартных протоколов средств TCP/IP не представляется возможным по ряду очевидных причин, однако для реализации его функционала может использоваться,
так называемое, ICMP-туннелирование. Во-первых, ICMP-пакеты являются достаточно распространенными, а значит, поддерживаются большинством МО и не
64
привлекут излишнего внимание администратора сети. Во-вторых, принцип работы ICMP построен по схеме «запрос-ответ», что схоже с принципом управления в
TraConDa. И, в-третьих, все управляющие данные (запросы от МДМ к АДМ и ответы в обратную сторону) могут быть внедрены в эхо-пакеты без какого-либо
нарушения структуры пакета и механизма обмена ими. Так, для соответствия
«инструкций-результатов» к «инструкциям-действиям» введение никаких дополнительных идентификаторов (общих для этих пакетов) не потребуется, поскольку
этот механизм связки поддерживается самим ICMP.
Для защиты канала возможно использование шифрования его данных по
аналогии с протоколами SSL/TLS [124], или например, с симметричными ключами, заданными заранее в МДМ и АДМ. Чтобы сторона, получающая ICMP-пакет
с данными, правильно идентифицировала их, как относящимися к КИВ (то есть
содержащими инструкции), может быть введено специальное «магическое число»
в начале данных ICMP-пакета (например, 0xD03AFACE); за ним следуют основные данные инструкции согласно протоколу КИВ. Так, при получении ICMPпакета, каждый из сетевых модулей элементов системы (СВМ-модуль и СВАмодуль) проверяет первые четыре байта данных ICM-пакета на соответствие «магическому числу» и трактует оставшуюся часть данных, как инструкции TraConDa.
Так как схема работы КИВ заключается в передаче инструкций в обоих
направлениях, то его протокол может быть задан через их формат.
Опишем формат инструкций КИВ. Инструкция состоит из различного числа
полей, зависящих от типа инструкции; для простоты будем считать, что кроме инструкции одного типа, все поля имеют размер по 4 байта. Первое поле определяет
тип инструкции, а последующие – дополнительные опции, специфичные для каждого конкретного типа. Формат протокола КИВ для основных инструкций приведен в таблице 2.2, где «Вид» означает направление инструкции и может следующим: «Д» - для «инструкций-действий» от МДМ к АДМ и БД, и «Р» - для «инструкций-результатов» от АДМ и БД к МДМ.
65
Таблица 2.2 - Формат информационного протокола
Назначение
Тип инструкции
1. Запрос проверки АДМ
2. Результат проверки АДМ
3. Установка принудительного
маршрута
4. Результат установки принудительного маршрута
5. Запрос данных из БД
6. Получение данных из БД
7. Сохранение данных в БД
8. Результат сохранения данных в БД
9. Деактивация принудительного
маршрута
10. Результат деактивации принудительного маршрута
Д
Р
Тип
1
1
2
Д
3
Р
4
Результат
Д
Р
Д
Р
5
6
7
8
ID данных
Данные
Данные
ID данных
Д
9
ID агента
Р
10
Результат
Вид
Дополнительные опции
2
3
4
ID агента
Результат
Начальный Конечный
ID агента
IP-адрес
IP-адрес
Инструкция_1 - Запрос проверки АДМ.
Инструкция посылается от МДМ к АДМ и предназначена для проверки
факта доверенности узла, содержащего АДМ; таким образом, она относится к виду «инструкций-действий».
Поля имеют следующие значения. Тип равен 1. Имеется единственная опция, определяющая уникальный идентификатор АДМ для запроса. Например,
следующие поля пакета:
0x00000001 0x12345678,
определяют идентификационный запрос к АДМ с номером 0x12345678.
Инструкция_2 - Результат проверки АДМ.
Инструкция посылается от АДМ МДМ и предназначена для информирования о результате проверки узла на доверенность; таким образом, она относится к
виду «инструкций-результатов». В случае отсутствия ответа (то есть узел не содержит АДМ), результатом считается недоверенность узла.
Поля имеют следующие значения. Тип равен 2. Имеется единственная опция, содержащая результат идентификации. Например, следующие поля пакета:
0x00000002 0x00000201,
66
подтверждают факт доверенности (значение 0x1) и опциональную дополнительную информацию (значение 0x2, определяющее для примера статус идентификации).
Инструкция_3 - Установка принудительного маршрута.
Инструкция посылается от МДМ к АДМ и предназначена для установки
статических маршрутов в МАТ узла, содержащего АДМ; таким образом, она относится к виду «инструкций-действий».
Поля имеют следующие значения. Тип равен 3. Имеется три опции, определяющие последовательно уникальный идентификатор АДМ для установки маршрута и IP-адреса узлов для начала и конца маршрутизации. Так, все пакеты, пришедшие с первого IP-адреса, должны быть перенаправлены АДМ на IP-адрес второго узла. Например, следующие поля пакета:
0x00000001
0xC0A80001
0xC0A80002,
определяют указание для АДМ с номером 0x00000001 осуществлять перенаправление пакетов с IP 192.168.0.1 (0xC0A80001) на IP 192.168.0.2 (0xC0A80002).
Инструкция_4 - Результат установки принудительного маршрута.
Инструкция посылается от АДМ к МДМ и предназначена для информирования о результате установки принудительной маршрутизации для узла, содержащего АДМ; таким образом, она относится к виду «инструкций-результатов». В
случае отсутствия ответа (то есть, узел не содержит АДМ) результат считается
неудачным, а узел – недоверенным.
Поля имеют следующие значения. Тип равен 4. Имеется единственная опция, содержащая результат установки принудительного маршрута. Например,
следующие поля пакета:
0x00000004 0x00000001,
подтверждают, что установка переадресации выполнена успешно (значение 0x1).
Инструкция_5 - Запрос данных из БД.
67
Инструкция посылается от МДМ к БД и предназначена для получения данных, хранящихся в БД; таким образом, она относится к виду «инструкцийдействий».
Поля имеют следующие значения. Тип равен 5. Имеется единственная опция, содержащая уникальный идентификатор данных, которые необходимо получить из БД. Например, следующие поля пакета:
0x00000005 0x00001111,
определяют запрос из БД данных с идентификатором 0x00001111.
Инструкция_6 - Получение данных из БД.
Инструкция посылается от БД к МДМ и предназначена для получения данных, запрошенных из БД; таким образом, она относится к виду «инструкцийрезультатов».
Поля имеют следующие значения. Тип равен 6. Имеется единственная опция не заданного размера, содержащая возвращаемые данные в бинарном виде.
Например, следующие поля пакета:
0x00000006 0x12345678 0x90ABCDEF ...,
определяют данные, возвращаемые из БД по запросу, в бинарном виде
(0x12345678 0x90ABCDEF ...).
Инструкция_7 - Сохранение данных в БД.
Инструкция посылается от МДМ к БД и предназначена для сохранения данных в БД; таким образом, она относится к виду «инструкций-действий».
Поля имеют следующие значения. Тип равен 7. Имеются две опции, определяющие последовательно уникальный идентификатор данных и сами данные не
заданного размера. Например, следующие поля пакета:
0x00000007 0x00001111 0x12345678 0x90ABCDEF ...,
определяют сохранение данных в бинарном виде (0x12345678 0x90ABCDEF ...) в
БД, имеющих идентификатор 0x000011111.
Инструкция_8 - Результат сохранения данных в БД.
68
Инструкция посылается от БД к МДМ и предназначена для информирования о результате сохранения данных в БД; таким образом, она относится к виду
«инструкций-результатов».
Поля имеют следующие значения. Тип равен 8. Имеется единственная опция, содержащая результат сохранения данных в БД. Например, следующие поля
пакета:
0x00000008 0x00000001,
подтверждают успешность сохранения данных в БД (значение 0x1).
Инструкция_9 - Деактивации принудительного маршрута.
Инструкция посылается от МДМ к АДМ и предназначена для изменения
конфигурации узла, например, приведения МАТ (в случае принудительной маршрутизации с помощью статических маршрутов) в первоначальный вид. В случае
нарушений безопасности в доверенном маршруте, инструкция позволит максимально предотвратить передачу трафику по маршруту, ставшим уже недоверенным. В случае же полного завершения использования доверенного маршрута, инструкция уберет с узлов все изменения, произведенные в интересах ДМ.
Поля имеют следующие значения. Тип равен 9 (в шестнадцатеричном виде
0x9). Имеется единственная опция, определяющая уникальный идентификатор
АДМ для запроса. Например, следующие поля пакета:
0x000000009
0x12345678,
определяют необходимость деактивации принудительного маршрута в заданном
АДМ с номером 0x12345678.
Инструкция_10 - Результат деактивации принудительного маршрута.
Инструкция посылается от АДМ МДМ и предназначена для информирования о результате деактивации принудительного маршрута в заданном АДМ; таким образом, она относится к виду «инструкций-результатов».
Поля имеют следующие значения. Тип равен 10 (в шестнадцатеричном виде
0xА). Имеется единственная опция, содержащая результат деактивации АДМ.
Например, следующие поля пакета:
69
0x0000000А
0x00000001,
подтверждают успешность деактивации принудительного маршрута (значение
0x1).
Инструкция_1 и Инструкция_2 используются на этапе расширенной идентификации узлов сети; Инструкция_3 и Инструкция_4 - на этапе принудительной
ДМ; остальные - на всех этапах метода, при этом Инструкция_9 и Инструкция_10
- в случае компрометации маршрута.
2.3 Типовые сценарии функционирования механизма ДМ
Рассмотрим типовые сценарии функционирования механизма ДМ в среде
TraConDa. Для этого детально опишем последовательность шагов на каждом из
этапов Метода - функционирование элементов СУ ДМ и их модулей с применением инструкций, создаваемые промежуточные данные и результаты, инициированные взаимодействием.
Шаг_1 - Запуск механизма ДМ.
Происходит запуск механизма ДМ через интерфейс МДМ. ВЭДМ-модуль
начинает пошаговое выполнение Метода. Поскольку Метод не является линейным (имеет цикл), то порядок этапов может меняться согласно его алгоритму. Изначально никакой информации о сети, доступных маршрутах и доверенных узлах
нет.
Шаг_2 - Создание топологической карты сети.
ВЭДМ-модуль выполняет Этап О_1 и передает управление СВМ-модулю,
который запускает алгоритмы трассировки сети и доступа к МАТ узлов. Инициатором трассировки является начальный узел доверенного маршрута - МДМ.
ВЭДМ-модуль анализирует результаты работы СВМ-модуля и заносит их в БД с
помощью соответствующего модуля; последний для этого использует Инструкцию_7, проверяя результат сохранения данных по Инструкции_8. Построенная
карта сети приведена на рисунке 2.10.
70
Рисунок 2.10 - Сценарий: Топологическая карта сети
На карте Узел_Н является начальным, инициирующим посылку данных; на
нем также расположен МДМ. Получателем данных является Узел_К. Узел_Н и
Узел_К связаны взаимно-соединенными промежуточными узлами Узел_1,
Узел_2, Узел_3 и Узел_4; при этом пока неизвестно, на каких узлах расположены
АДМ (если АДМ были уже внедрены в некоторые из узлов), и, следовательно, построение требуемого доверенного маршрута невозможно. Тем не менее, хорошо
видно, что от Узла_Н до узла_К существует 4 следующих маршрута:
Узел_Н ® Узел_1 ® Узел_2 ® Узел_К,
Узел_Н ® Узел_1 ® Узел_4 ® Узел_К,
Узел_Н ® Узел_3 ® Узел_2 ® Узел_К,
Узел_Н ® Узел_3 ® Узел_4 ® Узел_К.
На текущий момент считается, что доверенными являются лишь два узла:
начальный Узел_Н (содержащий МДМ) и конечный Узел_К (адресат данных), –
что отображено на рисунке штрихами фона узлов.
Шаг_3 - Расширенная идентификация узлов сети.
ВЭДМ-модуль инициирует выполнение Этапа О_2 запросом к БД на получение узлов построенной карты сети – делая запросы через БД-модуль с помощью
Инструкции_5 и получая данные по Инструкции_6. Затем, ВЭДМ-модуль проводит идентификацию узлов путем их опроса с проверкой наличия АДМ (которая
71
означает доверенность узла); для этого используется Инструкция_1, посылаемая
каждому из узлов.
Ее получение и анализ в АДМ выполняет СВА-модуль, который по данному
типу инструкции передает управление в ПУ-модуль. Последний производит идентификацию узла, формирует ответ (подтверждающий доверенность узла или
опровергающий ее) и передает его в Инструкции_2 через СВА-модуль. Этот результат идентификации будет передан в МДМ (по сети Узлу_Н), получен СВМмодулем, проанализирован ВЭДМ-модулем и занесен в БД (через БД-модуль по
Инструкции_7 и Инструкции_8).
Карта сети, обновленная идентификационной информацией – то есть содержащая отметки о доверенных узлах, приведена на рисунке 2.11.
Рисунок 2.11 - Сценарий: Топологическая карта сети после расширенной идентификации
По результатам идентификации лишь один узел считается доверенным –
Узел_3, поскольку от его АДМ пришел ответ об успешной идентификации (Инструкция_8). На рисунке это отображено штрихами фона узла (факт доверенности) и звездочкой (факт наличия АДМ).
Как видно из рисунка, доверенный маршрут должен пройти через Узел_3,
однако все равно не достигнет конечного Узла_К. Существует два потенциально
возможных его продолжения: через Узел_2* и Узел_4*:
Узел_Н ® Узел_3* ® Узел_2 ® Узел_К,
Узел_Н ® Узел_3* ® Узел_4 ®Узел_К,
однако задача выбора доверенного маршрута решается на следующих шагах.
72
Шаг_4 - Вычисление доверенного маршрута.
ВЭДМ-модуль выполняет Этап О_3 с помощью запуска модифицированного алгоритма Дейкстры, который получает данные об узлах из БД (через БДмодуль по Инструкции_5 и Инструкции_6). В случае невозможности построения
полностью доверенного маршрута, алгоритм запоминает недоверенные узлы, необходимые для последующего контроллинга, который реализуется путем последовательного выполнения Этапа В_1 и Этапа В_2.
На этапе В_1 используется собранная на ранних шагах информация, содержащаяся в БД, для вывода которой предназначен АИ-модуль. Данный модуль запрашивает данных из БД (через БД-модуль по Инструкции_5 и Инструкции_6),
формирует отчет и передает его через интерфейсы для последующего анализа. На
этапе В_2 анализируется ПО оборудования узла и в него встраивается код АДМ.
По результатам контроллинга происходит актуализация данных в БД соответствующим модулем.
Согласно построенной ранее карты и особенностям работы модифицированного алгоритма Дейкстры, в доверенный будет преобразован Узел_2* (и/или
Узел_4* по возможности). Итоговый доверенный маршрут будет следующим:
Узел_Н ® Узел_3* ® Узел_2* ® Узел_К.
Карта сети, обновленная информацией по результатам контроллинга, приведена на рисунке 2.12.
Рисунок 2.12 - Сценарий: Топологическая карта сети после осуществления контроллинга и построения доверенного маршрута
73
Согласно рисунку, в топологии сети появился новый доверенный Узел_2* с
внедренным АДМ. Построенный доверенный маршрут отображен утолщенными
стрелками.
Шаг_5 - Принудительная доверенная маршрутизация.
ВЭДМ-модуль выполняет Этап О_4 с помощью СВМ-модуля. Как указывалось ранее, возможны два алгоритма реализации этапа принудительной маршрутизации: от источника и с помощью статических маршрутов.
В первом случае ВЭДМ-модуль через СВМ-модуль будет создавать IPпакеты с опцией жесткой маршрутизации от источника, указывая при этом в опциях пакетов с данными последовательность IP-адресов, соответствующих доверенным узлам – это Узел_3* и Узел_2*. Доверенный маршрут будет получен
ВЭДМ-модулем из БД по Инструкции_5 и Инструкции_6. Таким образом, опция
маршрутизации от источника IP-пакета будет содержать IP узлов Узел_Н,
Узел_3* и Узел_2*,а адрес получателя пакетов будет соответствовать Узлу_К.
Во втором случае ВЭДМ-модуль через ПМ-модуль вставляет статические
маршруты в МАТ узлов – это Узел_3* и Узел_2*, чтобы выполнить принудительное перенаправление трафика вдоль доверенного маршрута, полученного из БД.
Для этого используется Инструкция_3, принимающая (помимо ID АДМ) предыдущий и следующий доверенные узлы.
Каждый АДМ, получив такую инструкцию и проанализировав ее в СВАмодуле, передаст управление УК-модулю, который произведет необходимые изменения в ответственном ему оборудовании узла. Успешность выполнения указания будет подтверждена АДМ путем формирования и отправки через СВАмодуль Инструкции_4. Этот результат будет передан в МДМ (по сети Узлу_Н),
получен СВМ-модулем, проанализирован ВЭДМ-модулем и занесен в БД (через
БД-модуль по Инструкции_7 и Инструкции_8). Таким образом, Узел_3* получит
указание о перенаправлении трафика с Узла_Н на Узел_2*, а Узел_2* – с Узла_3*
на Узел_К.
74
Карта сети с указанием изменений в статических маршрутах узлов приведена на рисунке 2.13.
Рисунок 2.13 - Сценарий: Топологическая карта сети после принудительной маршрутизации с
помощью статических маршрутов
Каждый АДМ, получив такую инструкцию и проанализировав ее в СВАмодуле, передаст управление УК-модулю, который произведет необходимые изменения в МАТ данного узла, направленные на удалении информации о статических маршрутах. Успешность выполнения указания будет подтверждена АДМ путем формирования и отправки через СВА-модуль Инструкции_10; последняя
также может содержать дополнительную информацию о выполненной работе
агента. Этот результат будет передан в МДМ (по сети Узлу_Н), получен СВМмодулем, проанализирован ВЭДМ-модулем и занесен в БД (через БД-модуль по
Инструкции_7 и Инструкции_8).
В результате все модифицированные МАТ будут приведены в исходное состояние. Существуют вариации реализации данного шага, такие как полное восстановление состояния оборудования (в частности, удаление кода АДМ из ПО узла) или полная его перезагрузка со стиранием всех данных. АДМ деактивируется
путем «заливки» оригинального (не модифицированного) ПО в заданный узел. В
исключительных случаях возможно стирание энергонезависимой памяти оборудования узла с последующей полной перезагрузкой.
После выполнения данного шага процесс передачи информации считается
завершенным, а состояние узлов сети - соответствующее изначальному.
75
Выводы по разделу 2
В качестве объекта исследовались потребности механизма ДМ в специальных средствах реализации на предмет синтеза программной архитектуры системы
управления ДМ.
В ходе исследования:
1) Рассмотрен гипотетический способ расширенной идентификации узлов
сети с помощью зондирования и разработан соответствующий алгоритм, исключающий риск неограниченного размножения и появления зацикливаний специальных сетевых зонд-пакетов.
2) Исходя из потребностей третьего основного этапа реализации механизма
ДМ, а также возможностей базового алгоритма маршрутизации и дополнительных алгоритмов, призванных повысить ее доверенность, модифицирован алгоритм Дейкстры, вычисляющий маршрут с учетом признака доверенности узлов.
Для сокращения времени нахождения доверенного маршрута предлагается использовать алгоритм X-BDV - упрощенную версию двунаправленного варианта
алгоритма Дейкстры.
3) Проанализированы способы получения удаленного управления узлами в
интересах ДМ - контроллинга, суть которого состоит в удаленном доступе к
маршрутизатору с последующим внедрением агента. Исследованы основные техники, реализующие удаленный «нештатный» доступ к телекоммуникационному
оборудованию на примере маршрутизаторов компании Cisco, а также используемые при этом утилиты на предмет использования в качестве средства для контроллинга. Показана техническая возможность и разработана блок-схема алгоритма внедрения программных агентов в ПО маршрутизаторов.
4) Обоснованы требования к структуре системы управления ДМ и функционалу ее элементов - менеджера, агентов, канала информационного взаимодействия и информационного хранилища. Синтезирована архитектура СУ ДМ с по-
76
мощью структуры взаимосвязи ее элементов, программной структуры каждого
элемента, их интерфейсов и протокола взаимодействия.
5) Предложен формат протокола канал информационного взаимодействия и
описан формат его инструкций - запрос проверки АДМ, установка принудительного маршрута, получение данных из информационного хранилища, деактивация
принудительного маршрута и др.
6) Рассмотрены типовые сценарии функционирования механизма ДМ в программной среде TraConDa, для чего детально описано функционирование элементов СУ ДМ и их модулей с применением инструкций, создаваемые промежуточные данные и результаты, инициированные взаимодействием на каждом шаге
разработанного метода.
Основным научным результатом, изложенным во втором разделе, является
программная архитектура системы управления ДМ, суть которой состоит в организации информационного взаимодействия программных модулей менеджера и
агентов ДМ, обеспечивающих совместное функционирование «штатных» и специально разработанных средств реализации этапов механизма.
Частными научными результатами, изложенными во втором разделе, являются специально разработанные алгоритмические средства, достаточные для реализации механизма ДМ, оригинальный протокол канала информационного взаимодействия элементов системы управления ДМ, а также типовые сценарии функционирования механизма ДМ в среде TraConDa.
Основное содержание второго раздела и полученных научных результатов
изложено в работах автора [58-61].
77
3 ОЦЕНКА СВОЙСТВ МЕХАНИЗМА ДОВЕРЕННОЙ МАРШРУТИЗАЦИИ
В ГЛОБАЛЬНЫХ ТЕЛЕКОММУНИКАЦИОННЫХ СЕТЯХ
3.1 Имитационное моделирование ТКС с доверенной маршрутизацией
Поскольку чисто теоретическое исследование механизма ДМ затруднено
при причине крайне сложной его формализации без потери сущности и ограничено только алгоритмизацией (см. п. 1), а практическое – требует полноценного
внедрение реализации (см.п. 2) в глобальную ТКС и сбор фактологических статистических данных, то целесообразным является исследование его свойств на соответствующей модели – модели ТКС с ДМ.
3.1.1 Имитационная модель ТКС с ДМ
В настоящее время значительная часть исследований ТКС осуществляется с
использованием программ имитационного моделирования (сетевых симуляторов),
которые имитируют функционирование заданной топологии и конфигурации на
ЭВМ [38-50, 125-131]. После чего результаты моделирования визуализируются и
анализируются исследователем. Адекватность модели зависит от целей исследования, навыков моделирования и собственно
характеристик программы-
симулятора.
Выбор подходящего сетевого симулятора для предметной области настоящего исследования является нетривиальной задачей вследствие наличия десятка
достойных конкурентов (ns-2, OPNET, GPSS, OMNeT++ и др.), которые, сверх
традиционных, учитывают целый ряд дополнительных характеристик, связанных
с ДМ: возможность работы с таблицей маршрутизации, поддержка протоколов
сетевого и транспортного уровня, использование IP адресации и др.
Сравнительный анализ средств имитационного моделирования ТКС, поддерживающих доверенную маршрутизацию, проведен автором в работе [63], где
78
дается, в том числе, краткая характеристика сравниваемых программных продуктов. Сравнительный анализ сетевых симуляторов показал, что большинство из
них подходит для исследования свойств механизма ДМ в глобальных ТКС и что
выбор «сбалансированного» средства имитационного моделирования будет, в
большей степени, определяться сценарием модельного эксперимента и структурой концептуальной модели ТКС с ДМ.
Концептуальная модель ТКС с ДМ разработана в предположении, что: сеть
полносвязная, причем первый и последний узлы - терминальные; узлы ненадежны - вероятности отказов и интенсивность восстановлений узлов зависят от их
номера; вероятность выбора очередного узла (маршрута) зависит от типа сообщения и номера текущего узла; все линии связи абсолютно надежны; время обработки сообщения в узле зависит от его номера; если очередной узел занят или неисправен, включается механизм контроллинга (см. пп. 2.1.3) дополнительных узлов;
есть ограничение по времени пребывания сообщения в сети и интенсивности контроллинга; время контроллинга дополнительных узлов конечно.
Разработанная концептуальная модель ТКС с ДМ реализуется следующим
образом. Поток сообщений генерируется и поступает в 1-й узел. При поступлении
сообщения, оно обслуживается и передается в следующей узел. При условии, что
узел не является терминальным (r ¹ R), время жизни (Т) еще не истекло и узел не
занят (или исправен), проверяется, не превышен ли еще лимит контроллинга – в
этом случае будет осуществлен контроллинг очередного узла; в противном случае
будет зафиксирован отказ в обслуживании сообщения. Если узел терминальный (r
= R), то порядковый номер сообщения (n) инкрементируется и процессы повторяются, пока порядковый номер сообщения не превысит максимального (N).
Блок-схема алгоритма, реализующего изложенную концептуальную модель
ТКС с ДМ, приведена на рисунке 3.1.
79
Рисунок 3.1 – Блок-схема алгоритма, реализующего концептуальную модель ТКС с ДМ
Данная модель характеризуется транзакционным обслуживанием потока сообщений в сети, инвариантным к протокольной и иным реализациям работы
маршрутизирующего оборудования, что приводит к возможности выбора в качестве инструментария GPSS [132-134] –достаточно мощного и, одновременно, достаточно простого языка имитационного моделирования СМО (систем массового
обслуживания) - и позволяет перейти непосредственно к разработке программной
имитационной модели ТКС с ДМ в его программной среде.
80
GPSS-модель в среде строится из отдельных элементов, называемых объектами; совокупность состояний всех объектов определяет состояние модели в любой момент времени. Состояние модели изменяется лишь тогда, когда транзакт
проходит через блок. Таким образом, транзакт является первым (динамическим)
обязательным объектом модели на GPSS, а вторым (статическим) является блок −
операционный объект GPSS-модели, совокупность которых задает логику функционирования модели через определение пути движения транзактов. Блоки представляют собой подпрограммы и содержат набор операндов: в языке GPSS более
50 таких блоков [132-134]. Для построения модели нужно выбрать требуемые
блоки и выстроить их в логической последовательности.
Разработанная программная имитационная ТКС с ДМ имеет модульную
структуру, которая представлена на рисунке 3.2.
Модуль задания исходных данных для моделирования
Модуль генерацииобслуживания потока отказов
Модуль генерации потока
сообщений
Модуль обработки
сообщений в узле
Модуль маршрутизации
Модуль
контроллинга
Модуль сбора статистики и расчета ВВХ
Рисунок 3.2 – Структура программной имитационной модели ТКС с ДМ
Представленные на рисунке 3.2 программные модули в совокупности реализуют концептуальную модель ТКС с ДМ и в нотации GPSS приведены на рисунке 3.3. Фрагмент разработанной программной имитационной модели представлен на рисунке 3.4.
81
Рисунок 3.3 – Блок-схемы программной имитационной модели ТКС с ДМ
82
;МОДУЛЬ ОБРАБОТКИ ТРАНЗАКТА-СООБЩЕНИЯ В УЗЛЕ:
node gate nu p2 dvrmtz; если узел p2 занят, то переход на модуль dvrmtx – доверенной маршрутизации
test ne p2 x$number_node dvrmtz; если узел p2 отказал, то переход на модуль dvrmtx доверенной маршрутизации
;если узел p2 не занят и не отказал, то:
;передача сообщения до узла по каналу связи имитируется задержкой во времени
advance (exponential(357,0,time_line)); по эксп. закону ДСЧ № 357 со смещением 0 и средним из функции time_line
;производится занятие узла сообщением
seize p2; имя занимаемого узла – p2
;обслуживание сообщения в узле имитируется задержкой во времени
advance (exponential(157,0,fn$time_delay)); по эксп. закону ДСЧ № 157 со смещением 0 и
средним из функции time_delay
;производится освобождение занимаемого узла
release p2; имя освобождаемого узла – p2
;осуществляется проверка системного атрибута m1 – времени пребывания в модели
активного транзакта
test l m1,time_limit,fail1; если time_limit – допустимое время доставки истекло, то переход на процедуру fail1
;осуществляется переход активного транзакта в модуль маршрутизации
transfer,cont_
Рисунок 3.4 – Фрагмент программной имитационной модели ТКС с ДМ
(модуль обработки сообщений в узле)
Наличие программной модели ТКС с ДМ позволяет перейти к организации
и проведению имитационных экспериментов с целью оценки основных свойств
исследуемого механизма.
3.1.2 Организация и проведение имитационных экспериментов
Первым экспериментом определим зависимость влияния одновременно
действующих факторов на отклики разработанной имитационной модели ТКС с
ДМ.
Наименование (содержание) оцениваемых факторов, модельное имя соответствующей входной переменной, а также нижний и верхний уровни (в предположении перекрытия возможного диапазона изменений, исходя из опыта) приведены в таблице 3.1.
83
Таблица 3.1 - Оцениваемые факторы
Фактор
Наименование (содержание)
допустимое время передачи
заданное время передачи сообщения по
сети
математическое ожидание времени контроллинга
математическое ожидание времени обработки в узле
предельная интенсивность контроллинга
математическое ожидание времени между отказами узлов
математическое ожидание времени восстановления исправности узла
Уровни
Имя переменной в модели
time_limit
Входная
переменная
х1
-1
1
500
1000
tz
х2
150
500
time_control
х3
1
50
time_node
х4
1
50
control_limit
х5
0.0
1.0
time_crash
х6
200
2000
time_restore
х7
50
200
С целью получения наиболее полной и достоверной информации о поведении ТКС с ДМ спланируем и проведем дробный факторный эксперимент с общим
количеством наблюдений 25. Согласно [135] план, построенный по такому способу, обладает свойствами симметричности, нормированности, ортогональности и
ротатабельности, что обеспечивает повышение качества проводимого эксперимента. Матрица планирования дробного факторного эксперимента для 7факторного случая и 32 наблюдений приведена в таблице 3.2.
Таблица 3.2 - Матрица планирования эксперимента
№
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
x1
-1
1
–1
1
–1
1
–1
1
–1
1
–1
1
–1
1
–1
1
x2
–1
–1
1
1
–1
–1
1
1
–1
–1
1
1
–1
–1
1
1
x3
–1
–1
–1
–1
1
1
1
1
–1
–1
–1
–1
1
1
1
1
x4
–1
–1
–1
–1
–1
–1
–1
–1
1
1
1
1
1
1
1
1
x5
–1
–1
–1
–1
–1
–1
–1
–1
–1
–1
–1
–1
–1
–1
–1
–1
x6
1
–1
–1
1
1
–1
–1
1
1
–1
–1
1
1
–1
–1
1
x7
–1
–1
–1
–1
1
1
1
1
1
1
1
1
–1
–1
–1
–1
№
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
x1
–1
1
–1
1
–1
1
–1
1
–1
1
–1
1
–1
1
–1
1
x2
–1
–1
1
1
–1
–1
1
1
–1
–1
1
1
–1
–1
1
1
x3
–1
–1
–1
–1
1
1
1
1
–1
–1
–1
–1
1
1
1
1
x4
–1
–1
–1
–1
–1
–1
–1
–1
1
1
1
1
1
1
1
1
x5
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
x6
1
–1
–1
1
1
–1
–1
1
1
–1
–1
1
1
–1
–1
1
x7
1
1
1
1
–1
–1
–1
–1
–1
–1
–1
–1
1
1
1
1
84
Наименование (содержание) оцениваемых откликов, модельное имя соответствующей выходной переменной приведены в таблице 3.3, а матрица 32´4 полученных результатов приведена в таблице 3.4.
Таблица 3.3 - Оцениваемые Отклики
Наименование (содержание)
вероятность недоставки сообщения
вероятность доставки сообщения за время, не менее
заданного
интенсивность контроллинга
среднее время передачи сообщения по сети
Имя переменной в модели
prop_fail
Входная переменная
y1
prop_tz
y2
control_intensive
time_transfer
y3
y4
Таблица 3.4 - Числовой массив результатов эксперимента
№
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
y1
0,24
0,202
0,263
0,191
0,261
0,219
0,263
0,179
0,703
0,592
0,767
0,582
0,715
0,575
0,727
0,57
y2
0,447
0,441
0,737
0,745
0,452
0,405
0,737
0,772
0,104
0,086
0,232
0,273
0,114
0,097
0,273
0,291
y3
0,002
0,003
0,001
0,005
0,002
0,001
0
0,001
0
0
0
0,001
0,001
0,002
0
0
y4
148,404
191,559
150,233
187,552
145,569
206,708
168,428
173,97
229,621
396,255
236,774
407,86
213,918
399,034
209,638
375,972
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
y1
0,116
0,02
0,149
0,022
0,156
0,056
0,154
0,034
0,667
0,494
0,683
0,438
0,658
0,52
0,744
0,486
y2
0,507
0,458
0,85
0,89
0,472
0,464
0,846
0,85
0,115
0,129
0,317
0,332
0,104
0,097
0,256
0,3
y3
0,691
0,593
0,539
0,65
0,402
0,543
0,375
0,418
0,41
0,625
0,333
0,782
0,329
0,473
0,266
0,606
y4
154,201
228,037
172,703
205,93
157,636
215,279
163,74
223,275
233,275
404,285
229,099
435,365
238,036
432,138
235,464
452,383
Для получения уравнений регрессии вида:
y = m1x1 + m2x2 + ... + b,
(3.1)
где y - функция независимого значения x,
m - коэффициенты, соответствующие каждой независимой переменной x,
b - константа,
воспользуемся встроенной Excel-функцией «ЛИНЕЙН», которая рассчитывает
статистику линейного ряда с применением метода наименьших квадратов для то-
85
го, чтобы вычислить прямую линию, наилучшим образом аппроксимирующую
имеющиеся данные.
Для вероятности недоставки сообщения функция «ЛИНЕЙН» возвращает
массив, который описывает полученную прямую y1 (см. таблицу 3.5), где: se1,
se2,..., sen - стандартные значения ошибок для коэффициентов m1, m2,..., mn; r2 коэффициент детерминированности; sey - стандартная ошибка для оценки y; F F-наблюдаемое значение; df - степени свободы; ssрег - регрессионная сумма квадратов; ssост - остаточная сумма квадратов.
Таблица 3.5 - Массив, описывающий линейную функцию y1
m7
m6
m5
0,0036... -0,0128... -0,0516...
se7
se6
se5
0,0071... 0,0071... 0,0071...
r2
sey
0,9801... 0,0404...
F
df
169,1004
24
ssрег
ssост
1,9375... 0,0392...
m4
0,2311...
se4
0,0071...
m3
0,0058...
se3
0,0071...
m2
0,0018...
se2
0,0071...
m1
-0,0651...
se1
0,0071...
b
0,3889...
seb
0,0071...
На основе табличных данных запишем уравнение множественной линейной
регрессии для вероятности недоставки сообщения:
y1 = 0,39-0,07x1+0,002x2+0,006x3+0,23x4-0,05x5-0,01x6+0,004x7.
(3.2)
По аналогии получим уравнения множественной линейной регрессии для
вероятности своевременной доставки - y2, интенсивности контроллинга - y3 и
среднего времени передачи сообщения - y4:
y2 = 0,41+0,002x1+0,135x2-0,004x3-0,22x4+0,02x5+0,01x6-0,004x7, (3.3)
y3 = 0,25+0,04x1-0,003x2-0,038x3-0,014x4+0,25x5+0,017x6+0,008x7, (3.4)
y4 = 251+58x1+x2+0x3+70x4+11x5-2x6+5x7,
(3.5)
и соответствующие им коэффициенты детерминированности: 0,9655...; 0,9101...;
0,8640...
Из анализа таблицы 3.5 видно, что коэффициент детерминированности r2
равен 0,9801..., что указывает на сильную корреляцию между независимыми пе-
86
ременными и вероятностью недоставки сообщения. Используем F-статистику,
чтобы доказать неслучайность получения результатов с таким высоким значением
r2. Положим вероятность ошибочного вывода о том, что имеется сильная зависимость, a = 0,05. Для получения критического значения F-распределения воспользуемся встроенной Excel-функцией «FРАСПОБР»: Fкрит = 2,422628534... Значение
F-наблюдаемое из таблицы 3.5 гораздо больше Fкрит (169,1004 >> 2,423), так что
гипотеза об отсутствии связи между независимыми переменными и вероятностью
недоставки сообщения отвергается. Аналогично для уравнений (3.3 - 3.5): 96,126
>> 2,423; 34,717 >> 2,423; 21,785 >> 2,423.
Вычисленные с помощью встроенной Excel-функцией «FРАСП» значения
вероятностей получения наибольшего значения F также чрезвычайно малы:
7,6179E-19; 5,40104E-16; 4,70913E-11; 6,01274E-09.
Проведенные F-проверки позволяют сделать вывод, что полученные уравнения множественной линейной регрессии (3.2 - 3.5) можно использовать для
предсказания значений вероятности недоставки сообщения, вероятности своевременной доставки, интенсивности контроллинга и среднего времени передачи сообщения.
3.2 Оценка свойств механизма ДМ
3.2.1 Оценка влияния факторов на отклики имитационной модели ТКС с
ДМ
Оценим влияние факторов на вероятность недоставки сообщения, для чего
отобразим коэффициенты уравнения (3.2) в виде гистограммы (см. рисунок 3.5).
В результате графического анализа рисунка 3.5 установлено, на что
prop_fail - вероятность недоставки сообщения - факторы влияют следующим образом (см. таблицу 3.6).
87
0,25
time_limit
0,2
tz
0,15
time_control
0,1
time_node
0,05
control_limit
0
time_crash
-0,05
time_restore
-0,1
Рисунок 3.5 - Влияние факторов на prop_fail - вероятность недоставки сообщения
Таблица 3.6 - Влияние факторов на prop_fail - вероятности недоставки сообщения
Сильно
Средне
Слабо
Практически не влияет
«+»
Время обработки в узле
«-»
Допустимое время передачи
Предельная интенсивность
контроллинга
Время между отказами узлов
Время восстановления узла
Время контроллинга
Заданное время передачи
То есть, наибольшее «положительное» (со знаком «+») влияние на вероятность недоставки сообщения по сети оказывает время обработки в узле: чем
меньше производительность маршрутизатора, тем дольше передаются сообщения
и тем больше у них «шансов» не уложиться в допустимое время передачи и «сойти с дистанции»,- что не противоречит здравому смыслу. Соответственно, собственно допустимое время передачи влияет на вероятность недоставки сообщения
по сети «отрицательно» (со знаком «-»), но не так сильно. Предельная интенсивность контроллинга также увеличивает живучесть ТКС за счет увеличения количества доверенных маршрутизаторов и, в этом смысле, влияет на вероятность недоставки сообщения по сети «отрицательно».
«Отрицательно» на вероятность недоставки сообщения по сети влияет время между отказами: чем надежнее маршрутизаторы, тем меньше «шансов» у сообщения получить отказ в обслуживании и быть удаленным из сети,- правда это
влияние относительно слабое.
88
Практически на вероятность недоставки сообщения по сети не влияют: время восстановления узла, так как всегда можно перенаправить трафик на исправный (контролируемый) узел; аналогично - время контроллинга, так как доминируют в передаче трафика все же «штатные маршрутизаторы». По определению
заданное время передачи сообщения никак не влияет на вероятность его недоставки по сети.
Оценим влияние факторов на вероятность своевременной доставки, для чего
отобразим коэффициенты уравнения (3.3) в виде гистограммы (см. рисунок 3.6).
0,15
time_limit
0,1
tz
0,05
time_control
0
time_node
-0,05
-0,1
control_limit
-0,15
time_crash
-0,2
time_restore
-0,25
Рисунок 3.6 - Влияние факторов на prop_tz - вероятность своевременной доставки
В результате графического анализа рисунка 3.6 установлено, что на prop_tz
- вероятность своевременной доставки - факторы влияют следующим образом
(см. таблицу 3.7).
Таблица 3.7 - Влияние факторов на prop_tz - вероятность своевременной доставки
Сильно
Средне
Слабо
Практически не влияет
«+»
Заданное время передачи
Предельная интенсивность
контроллинга
Время между отказами узлов
Допустимое время передачи
Время восстановления узла
Время контроллинга
«-»
Время обработки в узле
Вполне очевидно, что наиболее «положительное» влияние на вероятность
доставки сообщения по сети за время, не менее заданного, оказывает собственно
заданное время передачи. Надежность маршрутизаторов через время между отказами также «положительно» сказывается на «шансах» сообщения добраться до
89
пункта назначения и, тем самым, на вероятности своевременной доставки, однако
значительно слабее.
Также очевидно, что чем меньше производительность маршрутизатора, тем
дольше передаются сообщения по сети и тем больше у них «шансов» не уложиться в заданное время, тем самым время обработки в узле оказывает сильное «отрицательное» влияние на вероятность своевременной доставки.
Практическое отсутствие влияния времени восстановления узла и времени
контроллинга на вероятность своевременной доставки сообщения по сети имеет
аналогичное (см. таблицу 3.7) объяснение. Что касается допустимого времени передачи, то оно не влияет на вероятность своевременной доставки сообщения по
сети в силу «поглощения» заданного времени передачи.
Оценим влияние факторов на интенсивность контроллинга, для чего отобразим коэффициенты уравнения (3.4) в виде гистограммы (см. рисунок 3.7).
0,3
time_limit
0,25
tz
0,2
0,15
time_conrol
0,1
time_node
0,05
control_limit
0
time_crash
-0,05
time_restore
-0,1
Рисунок 3.7 - Влияние факторов на control_intensive - интенсивность контроллинга
В результате графического анализа рисунка 3.7 установлено, что на control_intensive - интенсивность контроллинга - факторы влияют следующим образом (см. таблицу 3.8).
Таблица 3.8 - Влияние факторов на control_intensive - интенсивность контроллинга
Сильно
Средне
Слабо
Практически не влияет
«+»
Предельная интенсивность
контроллинга
Допустимое время передачи
Время между отказами узлов
Время восстановления узла
Заданное время передачи
«-»
Время контроллинга
Время обработки в узле
90
Вполне очевидно, что наиболее «положительное» влияние на интенсивность
контроллинга оказывает собственно ее предел.
Допустимое время передачи существенно «положительно» влияет на интенсивность контроллинга, что вполне объяснимо: чем дольше сообщение «блуждает» по сети, тем больше у него шансов попасть на неисправный маршрутизатор и
вызвать механизм контроллинга.
Менее очевидно «отрицательное», хотя и слабое, влияние на интенсивность
контроллинга времени обработки в узле и времени контроллинга - природа зависимости «чем больше задержка сообщения в узле, тем меньше потребность в контроллинге» на данном этапе исследований не имеет удовлетворительного объяснения.
«Положительное» влияние времени между отказами узлов на интенсивность
контроллинга выглядит парадоксально, так как чем выше надежность маршрутизаторов, тем меньше потребности в контроллинге новых узлов, однако может
быть объяснено несоответствием временных масштабов диапазонов исходных
данных и поэтому это влияние незначительно.
Заданное время передачи не влияет на интенсивность контроллинга по
определению, а время восстановления влияет слишком опосредованно.
Оценим влияние факторов на среднее время передачи сообщения по сети,
для чего отобразим коэффициенты уравнения (3.5) в виде гистограммы (см. рисунок 3.8).
80
70
time_limit
60
tz
50
time_control
40
30
time_node
20
control_limit
10
time_crash
0
time_restore
-10
Рисунок 3.8 - Влияние факторов на time_transfer - среднее время передачи сообщения по
сети
91
В результате графического анализа рисунка 3.8 установлено, что на time_
transfer - среднее время передачи сообщения по сети - факторы влияют следующим образом (см. таблицу 3.9).
Таблица 3.9 - Влияние факторов на time_transfer - среднее время передачи сообщения по
сети
Сильно
Средне
Слабо
Практически не влияет
«+»
Время обработки в узле
Допустимое время передачи
Предельная интенсивность
контроллинга
Время восстановления узла
Время между отказами узлов
Время контроллинге
Заданное время передачи сообщения
«-»
То есть, наибольшее «положительное» влияние на среднее время передачи
сообщения по сети оказывает время обработки в узле: чем меньше производительность маршрутизатора, тем дольше передаются сообщения,- что не противоречит здравому смыслу. Также существенно «положительно» на среднее время
доставки влияет допустимое время передачи, что может быть объяснено увеличением шансов у сообщения добраться до пункта назначения даже в ущерб оперативности. По этой же причине меньшее, но все же «положительное» влияние на
среднее время доставки оказывает предельная интенсивность контроллинга.
Очевидно, что чем дольше восстанавливаются узлы, тем больше среднее
время доставки, однако это влияние достаточно слабое.
Заданное время передачи сообщения не влияет на среднее время доставки
по определению. Время между отказами узлов слишком опосредованно влияет на
среднее время доставки сообщения, чтобы быть практически значимым. Отсутствие влияние времени контроллинга на среднее время доставки, на первый
взгляд, трудно объяснимо (так как затраченное на обработку сообщения время в
любом узле неизбежно увеличивает время доставки) и требует дальнейших исследований.
92
Результат вычисления коэффициентов корреляции между вероятностью недоставки сообщения - y1, вероятностью своевременной доставки - y2, интенсивностью контроллинга - y3 и средним временем передачи сообщения - y4 приведен
в таблице 3.10.
Таблица 3.10 - Коэффициентов корреляции между откликами
Вероятность недоставки сообщения
Вероятность своевременной доставки сообщения
Предельная интенсивность контроллинга
Среднее время доставки сообщения по сети
y1
y2
y3
1
y1
1
y2 -0,8062...
1
y3 -0,3107... 0,1265...
y4 0,4516... -0,5746... 0,2036...
y4
1
Анализ содержимого таблицы 3.10 позволяет зафиксировать следующие достаточно очевидные взаимосвязи между откликами имитационной модели функционирования ТКС с ДМ:
1) Вероятность своевременной доставки сообщения находится в сильной
«отрицательной» взаимосвязи с вероятностью недоставки & vv1, в незначительной «положительной» взаимосвязи с предельной интенсивностью контроллинга &
vv и в существенной «отрицательной» взаимосвязи со средним временем доставки сообщения по сети & vv;
2) Среднее время доставки сообщения по сети находится в существенной
«положительной» взаимосвязи с вероятностью недоставки & vv и в несущественной «положительной» взаимосвязи с предельной интенсивностью контроллинга &
vv;
3) Вероятность недоставки сообщения находится в слабой «отрицательной»
взаимосвязи с предельной интенсивностью контроллинга & vv.
Проведенный эксперимент позволил установить силу и направление влияния каждого из учитываемых факторов на оцениваемые переменные, однако для
практического использования полученные результаты анализа потребуют соответствующей интерпретации.
1
& vv - от латинского vice versa (и наоборот).
93
3.2.2 Оценка влияния факторов на интегральное качество ТКС с ДМ
Согласно методологии планирования эксперимента [135] определим главные эффекты факторов и эффекты взаимодействия. Наличие установленной
функциональной зависимости не позволяет использовать «чисто» аддитивный
критерий для анализа эффектов взаимодействия факторов на некое интегральное
качество ТКС с ДМ. Поэтому в состав свертки введем мультипликативные пары,
имеющие наибольший коэффициент корреляции, а именно: вероятности недоставки и своевременной доставки сообщения, вероятность недоставки сообщения
и среднее время доставки сообщения по сети, вероятность своевременной доставки сообщения и среднее время доставки сообщения по сети.
Предварительно нормализуем уравнение (3.5), для чего разделим все коэффициенты на max{y4} = 452,383:
y4 = 0,554+0,128x1+0,002x2+0x3+0,154x4+0,023x5-0,004x6+0,01x7. (3.6)
Итоговый критерий Y некого интегрального качества ТКС с ДМ имеет вид:
Y = y1 + y2 + y3 + y4 + y1y2 + y1y4 + y2y4,
(3.7)
а его значения приведены в таблице 3.11.
Таблица 3.11 - Значения итогового критерий Y
x7
x6
x5
x4
x3
x2
x1
y1
0,0036...
–0,0128...
–0,0516...
0,2311...
0,0058...
0,0018...
–0,0651...
y2
–0,0045...
0,0107...
0,0244...
–0,2172...
–0,0041...
0,1315...
0,0020...
y3
0,0078...
0,0170...
0,2505
–0,0124...
–0,0380
–0,0031...
0,0422...
y4
0,0100...
–0,0038...
0,0234...
0,1544...
2,417E-6
0,0023...
0,1277...
y1
–1,665E-5
–0,0001...
–0,0012...
–0,0502...
–2,441E-5
0,0002...
–0,0001...
y2
3,651E-5
4,992E-5
–0,0012...
0,0356...
1,42E-8
4,311E-6
–0,0083...
y3
–4,627E-5
–4,177E-5
0,0005...
–0,0335...
–1,005E-8
0,0003...
0,0002...
Y
0,0168...
0,0109...
0,2448...
0,1077...
–0,0363...
0,1331...
0,0986...
R
6
7
1
3
5
2
4
Оценим влияние факторов на интегральное качество ТКС с ДМ, для чего
отобразим коэффициенты уравнения (3.7) в виде гистограммы (см. рисунок 3.9).
94
0,3
0,25
0,2
0,15
0,1
0,05
0
-0,05
time_limit
tz
time_control
time_node
control_limit
time_crash
time_restore
-0,1
Рисунок 3.9 - Влияние факторов на Y - интегральное качество ТКС с ДМ
Графический анализ рисунка 3.9 позволяет констатировать следующие интегральные (синергетические) эффекты:
Наибольшее влияние (ранг R = 1) на интегральное качество Y оказывает
предельная интенсивность контроллинга, что хорошо согласуется с внедренным в
ТКС механизмом ДМ, призванным существенно улучшить вероятностновременные характеристики.
Достаточно сильное влияние (R = 2) на интегральное качество Y оказывает
заданное время передачи, как определяющее целевое назначение ТКС по своевременной передаче трафика.
Существенное влияние (R = 3) времени обработки в узле на интегральное
качество Y достаточно очевидно: производительность маршрутизатора во многом
определяет характеристики узлов сети - основного источника задержек и отказов
согласно концептуальной модели ТКС.
Также существенное влияние (R = 4) на интегральное качество Y оказывает
допустимое время передачи как определяющее шансы у сообщения добраться до
пункта назначения.
Время контроллинга слабо влияет (R = 5) на интегральное качество Y, что
может быть объяснено его несоизмеримостью в исходных данных модели со временем обработки в узле.
Примечание - Это особенно важно с позиций принципиальной целесообразности применения метода ДМ, так как его внедрение привносит значительный
положительный эффект только при условии малого времени контроллинга МО..
95
Практически на интегральное качество ТКС с ДМ не влияют (R = 6, 7)
надежностные характеристики маршрутизаторов (время между отказами и время
восстановления узлов), так как при наличии ДМ всегда можно перенаправить
трафик на заведомо исправный (подконтрольный) узел.
3.2.3 Оценка динамики влияния ключевых факторов ДМ на целевую функцию ТКС
С помощью разработанной имитационной модели оценим динамику влияния ключевых факторов ДМ - интенсивности контроллинга (control_intensive) и
заданного времени (tz) - на целевую функцию ТКС - вероятность своевременной
доставки сообщений (prop_tz). Результаты имитационного эксперимента, приведенные на рисунках 3.10 и 3.11, подтверждают высокую (свыше 25%) эффективность ДМ в ТКС; при этом, чем больше контролируется узлов ТКС и чем больше
заданное время передачи, тем больше у сообщения шансов добраться до назначения, уложившись в «норматив».
Здесь очевидная зависимость вероятности своевременной доставки сообщений по ТКС от заданного времени приведена также с целью доказательства адекватности разработанной имитационной модели процессам в реальных сетях, что
повышает степень доверия к результатам проводимых экспериментов.
1,00
0,90
1000
prop_tz
0,80
700
0,70
500
0,60
400
300
0,50
200
0,40
0,30
100
0,0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1,0
control_intensive
Рисунок 3.10 - Зависимость вероятности своевременной доставки сообщений от интенсивности
контроллинга для различных значений tz
96
1,00
0,90
1
prop_tz
0,80
0,8
0,70
0,6
0,60
0,4
0,50
0,2
0
0,40
0,30
100,0
200,0
300,0
400,0
500,0
600,0
700,0
800,0
900,0
1000,0
tz
Рисунок 3.11 - Зависимость вероятности своевременной доставки сообщений от заданного времени передачи для различных значений control_intensive
С помощью разработанной имитационной модели ТКС с ДМ проведем оптимизационный эксперимент. Его суть состоит в том, что с ростом контроллинга,
с одной стороны, растет вероятность своевременной доставки сообщений, а с другой - падает уровень скрытности передачи, так как в результате применения ДМ в
сети наблюдается нештатная активность, «перебои» в работе маршрутизирующего оборудования и т.п. И если целевой функцией (ЦФ) является своевременная, но
скрытная передача, то имеет место некий оптимум, когда своевременность уже
достаточно велика, а скрытность еще достаточно велика.
График на рисунке 3.12 показывает очевидный рост вероятности доведения
и падение уровня скрытности (одного из показателей информационной безопасности - ИБ) передачи при увеличении интенсивности контроллинга (control_intensive).
1,00
0,95
0,90
ЦФ
0,85
Тзад = 800
0,80
ИБ
0,75
0,70
0,0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1,0
control_intensive
Рисунок 3.12 - Результаты оптимизационного эксперимента
97
Для оптимизационного эксперимента, а также оценки динамики влияния
ключевых факторов были использованы исходные данные из таблицы 3.1, а
именно: time_limit = 1000, time_control = 10, time_node = 10, time_repair = 10,
time_crash = 5000. В качестве ЦФ была выбрана следующая структура:
1-n
ЦФ = Ptzn ´ Pскр
,
(3.8)
где Ptz - вероятность доведения за время не более заданного (tz);
n - коэффициент важности показателя качества, n = 0 - 1 (в настоящем случае
n = 0.9);
1-n
Pскр
= 1 - e - k / l - скрытность передачи (k - эмпирический коэффициент, l -
интенсивность контроллинга).
Эксперимент показал наличие перегиба ЦФ в районе интенсивности контроллинга (control_intensive) от 0.5 до 0.7.
Для практического использования результатов подобных оптимизационных
экспериментов необходимы реальные исходные данные, научно-обоснованная
структура ЦФ, а также дополнительные исследования по определению влияния
повышенной активности в глобальной ТКС на значение показателя скрытности.
При этом следует учесть, что применение ДМ одновременно улучшает такие показатели безопасности ТКС, как конфиденциальность и идентифицируемость
трафика, а также показатели устойчивости функционирования (в частности, живучесть).
3.3 Оценка информационной безопасности глобальных ТКС при использовании механизма ДМ
Исследуем границы эффективности механизма ДМ через оценку информационной безопасности глобальных ТКС, которая определяется составом актуальных угроз. Для определения состава типичных угроз информационной безопасно-
98
сти (УИБ) в глобальных ТКС проанализируем соответствующие модели основных
компетентных сторон - производителей МО, операторов и регуляторов.
Наиболее крупным производителем МО, имеющим громадный трансконтинентальный опыт, является компания Cisco. Согласно ее модели сетевой безопасности [136], УИБ делятся на отказ в обслуживании, внедрение вредоносного или
разрушающего ПО, получение данных за счет использования сетевых мониторов
для прослушивания данных, навязывание ложного маршрута сети, присвоение
чужих прав доступа, переполнения буфера, перехват и анализ потока передаваемых данных, выявление протоколов портов и активных сетевых служб, перехват
пакетов (sniffing), выявление пароля для получения НСД, подмена доверенного
объекта (IP-spoofing), навязывание ложной информации, НСД к сетевым ресурсам, манипулирование информацией, отказы технических средств и сбои ПО.
В качестве крупного потребителя МО (точнее - сетевого провайдера) можно воспользоваться опытом компании «Ростелеком» в сфере предоставления телекоммуникационных услуг. В 2012 г. из-за необходимости гарантировать качественную, надежную и безопасную работу своей сети IP MPLS, компания объявила о начале коммерческой эксплуатацию системы защиты от внешних сетевых
угроз, позволяющей их обнаружить и локализовать. Согласно ее модели [137] существуют 32 разновидности УИБ, которыми являются: неправомерные действия
авторизованных пользователей в системах и приложениях, отказ в обслуживании,
внедрение вредоносного или разрушающего ПО, подмена имени пользователя посторонними лицами, перехват информации, отрицание приема/передачи сообщений, умышленная порча имущества посторонними лицами, отказы и сбои серверного оборудования, пропадание каналов связи, непреднамеренная ошибка маршрутизации, стихийные бедствия и др.
Регулятором информационной безопасности ТКС в России является государственная организация - ФСТЭК. Согласно ее базовой модели [138] выделено 8
реализуемых сетевых угроз, а именно: 1) анализ сетевого трафика для перехвата
потока передаваемых данных; 2) сканирование сети для выявление протоколов
99
портов и активных сетевых служб; 3) выявление пароля для получения НСД; 4)
подмена доверенного объекта сети и передача по каналам связи сообщений от его
имени с присвоением его прав доступа; 5) навязывание ложного маршрута сети;
6) внедрение ложного объекта сети для получения возможности перехвата нарушителем поискового запроса и выдачи на него ложного ответа; 7) отказ в обслуживании, при котором операционная система оказывается не в состоянии обрабатывать поступающие пакеты; 8) удаленный запуск приложений для нарушения
конфиденциальности, целостности, доступности информации и получения полного контроля за работой хоста.
Используя рассмотренные модели, сформируем контекстный (в отношении
предметной области) итоговый список типовых актуальных УИБ в глобальных
ТКС, представленный в таблице 3.12.
Таблица 3.12 - Типовые актуальные УИБ в глобальных ТКС
Условный
Название УИБ
номер
УИБ-1
Анализ сетевого трафика
УИБ-2
Сканирование сети:
УИБ-2.1
выявление протоколов портов
УИБ-2.2
выявление активных сетевых служб
УИБ-3
Подмена доверенного объекта сети:
УИБ-3.1
с установлением виртуального соединения
УИБ-3.2
без установления виртуального соединения
УИБ-4
Навязывание ложного маршрута сети:
УИБ-4.1
межсегментное
УИБ-4.2
внутрисегментное
УИБ-5
Внедрение ложного маршрута сети:
УИБ-5.1
ложного ARP-сервера
УИБ-5.2
ложного DNS-сервера
УИБ-6
Отказ в обслуживании:
УИБ-6.1
снижение пропускной способности и производительности сети
УИБ-6.2
исчерпание ресурсов сети
УИБ-6.3
нарушение логической связности сети
УИБ-6.4
отказ или сбой сетевых служб
УИБ-7
Удаленный запуск приложений
УИБ-8
Отказы технических средств
УИБ-9
Сбои программного обеспечения
100
Опишем краткое содержание представленных в таблице 3.12 угроз:
1) УИБ-1 - исследование характеристик сетевого трафика, перехват передаваемых данных, в том числе идентификаторов и паролей пользователей;
2) УИБ-2.1 - сканирование сети и анализ ответов от хостов, чтобы выявить
используемые протоколы;
3) УИБ-2.2 - сканирование сети и анализ ответов от хостов, чтобы определить активные сетевые сервисы;
4) УИБ-3.1 - изменение трассы прохождения сообщений для несанкционированного изменения МАТ;
5) УИБ-3.2 - изменение трассы прохождения сообщений для НСД к сетевым
ресурсам;
6) УИБ-4.1 - несанкционированное изменение МАТ с целью, например, перехвата трафика;
7) УИБ-4.2 - несанкционированное изменение МАТ с использованием,
например, протокола ICMP с целью нарушения связи;
8) УИБ-5.1 - использование протокола удаленного поиска ARP для изменения МАТ, чтобы трафик проходил через ложный ARP-сервер;
9) УИБ-5.2 - использование протокола удаленного поиска DNS для передачи ложного DNS-ответа на ложный сервере, передачи направленного шторма
DNS-ответов для получение ложного DNS-ответа (с последующей передачей перехваченной информации на ложный сервер) и изменения кэш-таблицы DNSсервера для прохождение трафика через ложный сервер;
10) УИБ-6.1 - снижение пропускной способности и производительности сети путем шторма запросов типа Ping flooding, ICMP-flooding, FTP-flooding;
11) УИБ-6.2 - исчерпание ресурсов сети путем шторма запросов (SYNflooding) и сообщений типа Smurf и Spam;
12) УИБ-6.3 - нарушение логической связности сети путем изменения МАТ
или идентификационной/аутентификационной информации;
101
13) УИБ-6.4 - отказ или сбой сетевых служб путем направленного шторма
запросов, или передачи нестандартных пакетов;
14) УИБ-7 - использование возможностей удаленного управления системой,
предоставляемых скрытыми программными и аппаратными закладками;
15) УИБ-8 - сбои, вызывание перебоями в электропитании, выходом из
строя аппаратных элементов в результате старения и снижения надежности,
внешними воздействиями электромагнитных полей технических устройств и др.;
16) УИБ-9 - сбои, вызванные ошибками в программах, или сбои при нештатном использовании системных средств.
Оценка критичности УИБ в глобальных ТКС может быть произведена с помощью одной из общепринятых методик – SANS/GIAC, разработанной в институте SANS (System Administration, Networking and Security Institute) и центре анализа компьютерных инцидентов GIAC (Global Incident Analysis Center) [139, 140].
Суть методики заключается в оценке «критичности» сетевой атаки (Severity, Sv),
которая определяется величиной риска осуществления соответствующей угрозы.
При этом величина риска определяется вероятностью успешного осуществления
атаки (Lethality, Le) и величиной возможного ущерба (Criticality, Cr). Величина
уязвимости ТКС определяется эффективностью контрмер системного (System
countermeasures, Sc) и сетевого уровней (Network countermeasures, Nc), применяемых против данного вида УИБ.
Уровень «критичности» сетевой атаки определяется с помощью числовой
шкалы от «минус» 8 до «плюс» 8 в соответствии с формулой:
Sv = (Cr + Le) - (Sc + Nc).
(3.9)
Величина возможного ущерба (Cr) определяется по 5-бальной шкале согласно объектам атаки следующим образом: 5 баллов - для данных безопасности,
маршрутизатора, межсетевого экрана (МЭ), DNS-сервера; 4 балла - для данных
адресации и маршрутизации, почтового шлюза; 3 балла - для ресурсов связи; 2
балла - для данных взаимодействия, рабочей станции; 1 балл - для локальных обрабатываемых данных, персональных компьютеров.
102
Вероятность успешного осуществления атаки (Le) определяется по 5бальной шкале согласно результатам проведения атак следующим образом: 5 баллов - при получении права суперпользователя на удаленной системе; 4 балла при отказе в обслуживании; 3 балла - при снижении функциональности, внедрении ложной информации, получении прав непривилегированного пользователя на
удаленном хосте; 2 балла - при раскрытии конфиденциальной информации для
несанкционированного сетевого доступа; 1 балл - при вскрытии топологической
и потоковой структуры.
Эффективность контрмер системного (Sc) уровня определяется по 5-бальной
шкале согласно имеющимся системным средствам защиты следующим образом: 5
баллов - при наличии современной защищенной ОС, установке всех программных коррекций, использовании дополнительных сетевых средств защиты; 3 балла
- для ОС со специализированными средствами защиты, неустановленными некоторыми программные обновлениями, устаревшей версией ОС; 1 балл - для ОС
без специализированных средств защиты, передаваемыми паролями по сети в открытом виде, отсутствии политик управления паролями.
Эффективность контрмер сетевого (Nc) уровня определяется по 5-бальной
шкале согласно имеющимся сетевым средствам защиты следующим образом: 5
баллов - в случае одного метода сетевой защиты и наличии МЭ, являющегося
единственной точкой входа в сеть и реализующего принцип минимизации привилегий; 4 балла - в случае нескольких механизмов сетевой защиты, наличия МЭ и
дополнительных точек входа в сеть; 3 балла - в случае нескольких механизмов
сетевой защиты в комбинации с организационными мерами; 2 балла - при наличии МЭ и разрешительной политики управления доступом; 1 балл - при наличии
только организационных мер.
Оценим критичность типовых актуальных УИБ в глобальных ТКС по вышеуказанной методике. Результат экспертной оценки параметров и расчета «критичности» сетевых атак и реализуемых ими УИБ приведен в таблице 3.13, в графическом виде представлен на рис. 3.13.
103
Таблица 3.13 - Результат расчета «критичности» сетевых атак и реализуемых ими УИБ
УИБ, реализуемая
в результате атаки
УИБ-1
УИБ-2.1
УИБ-2.2
УИБ-3.1
УИБ-3.2
УИБ-4.1
УИБ-4.2
УИБ-5.1
УИБ-5.2
УИБ-6.1
УИБ-6.2
УИБ-6.3
УИБ-6.4
УИБ-7
УИБ-8
УИБ-9
Cr
Le
Sc
Nc
Sv
5
2
2
4
4
4
2
4
5
3
3
3
3
1
3
3
2
3
3
2
2
2
4
3
3
4
4
4
4
3
4
4
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
4
4
4
1
1
4
4
3
3
3
3
3
3
1
1
1
0
-2
-2
2
2
-1
-1
1
2
1
1
1
1
0
3
3
4
3
2
1
0
-1
-2
УИБ-9
УИБ-8
УИБ-7
УИБ-6.4
УИБ-6.3
УИБ-6.2
УИБ-6.1
УИБ-5.2
УИБ-5.1
УИБ-4.2
УИБ-4.1
УИБ-3.2
УИБ-3.1
УИБ-2.2
УИБ-2.1
УИБ-1
-3
Рисунок 3.13 - Диаграмма «критичности» сетевых атак и реализуемых ими УИБ
Для качественной оценки информационной безопасности глобальных ТКС
при использовании механизма ДМ произведем взвешенную оценку влияния механизма ДМ на каждую из типичных УИБ. Оценка произведена на основании особенностей работы механизма и их ликвидирующих воздействий на УИБ; для этого определены 3 прогнозируемых результата: угроза устраняется, ослабляется или
находится вне действия механизма ДМ.
104
Опишем каждую из угроз (классы угроз) с позиции их устранения механизмом ДМ.
УИБ-1 – угроза анализа сетевого трафика устраняется за счет его перенаправления согласно доверенным маршрутам;
УИБ-2 – угрозы сканирования сети находятся вне действия механизма;
УИБ-3 − угрозы подмены доверенного объекта сети устраняются в полном
объеме за счет контролинга узлов и перенаправления трафика согласно доверенным маршрутам;
УИБ-4.1 − угроза навязывания ложного маршрута (межсегметного) устраняется в полном объеме за счет контролинга узлов и перенаправления трафика согласно доверенным маршрутам;
УИБ-4.2 − угроза навязывания ложного маршрута (внутрисегметное) находится вне зоны действия механизма, однако косвенно может быть ослаблена за
счёт перенаправления трафика по более устойчивому маршруту;
УИБ-5 – угрозы внедрения ложного объекта устраняются за счет перенаправления трафика согласно доверенным маршрутам (включая промежуточные
доверенные узлы);
УИБ-6 – угрозы отказа в обслуживании устраняются регулированием
нагрузки на управляемые маршрутизаторы и контролингом сторонних узлов;
УИБ-7 – угроза удаленного запуска приложений находится вне зоны действия ДМ, однако косвенно может быть ослаблена за счет контролинга узлов и
перенаправления трафика по маршрутам, не включающим потенциально уязвимые узлы;
УИБ-8, УИБ-9 – угрозы отказов технических средств и сбоев ПО находятся
вне зоны действия ДМ, однако косвенно могут быть ослаблены за счет перенаправления трафика по более надежному маршруту.
Итоговая оценка влияния ДМ на УИБ приведена в таблице 3.14.
105
Таблица 3.14 - Итоговая оценка влияния ДМ на УИБ в глобальных ТКС
УИБ
Результат
влияния ДМ
УИБ-1, УИБ-3.1,
УИБ-3.2, УИБ-4.1,
УИБ-5.1, УИБ-5.2 Устраняется
УИБ-6.1, УИБ-6.2,
УИБ-6.3, УИБ-6.4
УИБ-4.2, УИБ-7,
Ослабляется
УИБ-8, УИБ-9
УИБ-2.1, УИБ-2.2 Вне действия
Результирующее действие
Контроллинг и перенаправления трафика согласно
доверенным маршрутам
Регулирование нагрузки на управляемые маршрутизаторы и контролинг сторонних узлов
Перенаправление трафика по более надежному/устойчивому маршруту
Отсутствует
Согласно критичности типовых УИБ (таблица 3.13, рисунок 3.13) и влияния
на них механизма ДМ (таблица 3.14) можно сделать следующие выводы. Вопервых, механизм ДМ не действует на угрозы с заведомо низким значением критичности, что не сильно снижает усредненную оценку механизма. Во-вторых, хотя угрозы сбоев технических средств и отказов ПО, лишь ослабляемые механизмом, и имеют высокую критичность, однако они, как правило, носят непреднамеренный характер и могут быть устранены соответствующими организационнотехническими мероприятиями (созданием резервных блоков питания, своевременным обновлением аппаратных элементов и ПО, применением электромагнитных экранов и т.п.). В-третьих, большинство всех угроз (10 из 16) полностью
устраняется механизмом ДМ, что доказывает его достаточно высокую эффективность в борьбе с УИБ в глобальных ТКС.
3.4 Рекомендации по совершенствованию механизма ДМ
3.4.1 Варианты реализации механизма ДМ
Синтезированный ранее метод ДМ (Раздел 1 - с использованием только
«штатных» средств TCP/IP; Раздел 2 - с использованием специализированных
средств и системы управления) предназначен изначально для исследования
свойств механизма ДМ и поэтому с точки зрения возможности организации «до-
106
веренной сети передачи данных поверх недоверенной» обладает целым рядом недостатков.
Во-первых, он использует заведомо недостаточные по функционалу штатные средства, что приводит к необходимости разработки новых и их не всегда
удачному согласованию с существующими (например, идентификации узлов с
помощью внедрения агентов). Во-вторых, метод позволяет учесть лишь ряд требований к доверенному маршруту (например, его построение заново без возможности использования уже существующих, доверенных). И, в-третьих, при реализации метода никак не учитываются особенности его реального внедрения в существующую сеть.
Все эти недостатки существенно ограничивают возможность использования
предложенного метода ДМ для организации «доверенной сети поверх недоверенной», что актуализирует задачу совершенствования реализации механизма ДМ и
создания новых соответствующих алгоритмов и процедур.
Рассмотрим возможные подходы (варианты) к реализации механизма ДМ с
учетом полученных новых знаний.
1) Одним из требований к методу реализации механизма ДМ является согласованное выполнение его этапов. Полярными вариантами здесь выступают
централизованная диспетчеризация (см. п. 2.2) и децентрализованное функционирование. В первом случае отправка данных возможна только из центрального
элемента (например, менеджера ДМ), который и берет на себя ответственность за
построение и использования доверенного маршрута. Во втором, каждый из элементов сети может являться источником передаваемых сообщений и потому выступает равноправным элементом распределенной системы управления ДМ. Реализация механизма ДМ по второму варианту обладает большей универсальностью
и отказоустойчивостью, однако реализуется более сложно и может инспирировать
новые коллизии. В частности, экстренное прекращение передачи данных в случае
компрометации маршрута для распределенного варианта представляется крайне
нетривиальной задачей.
107
2) Процесс организации передачи данных по доверенным маршрутам может
обладать различной степенью автоматизации; в этом контексте предложенный
метод ДМ можно считать автоматизированным. Тем не менее управление процессом может быть смещено как в сторону большей автоматизации, так и быть более
контролируемым оператором. Вариант механизма, при котором подготовкой данных для передачи, выбором доверенного маршрута, его контролем, мониторингом
и проч. занимается построенная система будет считаться полностью автоматическим. Полярный, полностью ручной, вариант предполагает участие оператора на
всех этапах. Реализация первого варианта необходима, когда требуется удобство
и многократность использования механизма ДМ. Реализация второго - когда
необходима высокая гарантия передачи отдельных блоков данных в условиях
враждебной среды; тогда оператор должен полностью контролировать процесс,
реагируя на возникающие угрозы и экстренно принимая ситуативные решения.
3) На текущий момент не существует полноценно работающих реализаций
механизма ДМ, а особенности функционирования глобальной ТКС не предполагают его простого развертывания. Таким образом, возникает задача по внедрению
механизма ДМ в сети TCP/IP. В зависимости от требований к параметрам такого
внедрения, возможна как постепенная поддержка отдельными узлами сети механизма ДМ, так и построение новой подсети в рамках существующей, изначально
поддерживающей этот механизм. Постепенное внедрение функционала ДМ в узлы сети может быть сопряжено с необходимостью нового функционала одних узлов сочетаться с функционалом менее безопасных и «конкурирующих» за сетевую среду других. Замена же целой группы узлов на поддерживающие механизм
ДМ в случае возникновения ошибок в реализации или конфигурации нарушит работоспособность целого участка глобальной сети. Тем не менее, построенная и
отлаженная таким образом подсеть будет более надежной и безопасной.
4) Несмотря на то, что наличие доверенного маршрута необходимо лишь на
время передачи данных, его наличие до и после собственно передачи может быть
применено для улучшения отдельных характеристик механизма ДМ. Так, под-
108
держка актуального доверенного маршрута между отдельными передачами позволит как сократить время на его повторное создание, так и осуществлять мониторинг за состоянием безопасности сети. Первое следует из того, что будет отсутствовать этапы, подобные идентификации узлов и выбору доверенного маршрута.
Второе же будет возможно по оценке отказов узлов и нарушению доверенности
маршрута. Однако постоянная поддержка доверенного маршрута может быть не
достаточно скрытной, а, следовательно, механизм ДМ будет сильнее подвержен
атакам злоумышленника.
5) Поскольку в любой реализации механизма ДМ должно присутствовать
управление маршрутом посредством транзитных узлов, то необходим специальный протокол (некий формализованный набор соглашений и форматов) такого
управления. Протокол должен обеспечивать доставку маршрутизирующей информации узлам и результатов создания ими доверенного маршрута. Данные протокола могут являться частью передаваемых данных (а точнее, располагаться в
отдельных секциях пакета, таких, как опция IP-пакета для задания маршрутизации от источника). Альтернативной такого расположения может быть создание
отдельного канала управления маршрутизацией, с помощью которого перед началом передачи данных все транзитные узлы будут оповещены о том, как пакеты с
данными необходимо перенаправлять.
Первый вариант можно считать более стандартным, поскольку он, скорее
всего, будет использовать штатные сетевые средства – следовательно, он практически не потребует специальной реализации и может функционировать в существующей сетевой среде. Второй является более трудоемким и требуемым разработки дополнительного функционала. Например, для него необходимо будет решать задачу идентификации пакетов для того, чтобы маршрутизации подверглись
только лишь требуемые передаваемые данные, а не все, проходящие через узел.
Тем не менее, создание канала управления маршрутизацией сделает ее более гарантированной (поскольку канал априори будет поддерживать подтверждение
принятия информации узлами) и даст большие возможности по ее управлению
109
(например, позволит, как экстренно прекратить передачу или изменить ее маршрут для выбранного узла, так и узнать о состоянии последнего).
Результат сравнительной оценки рассмотренных подходов к реализации механизма ДМ приведен в таблице 3.15.
Таблица 3.15 - Сравнительная таблица вариантов реализации механизма ДМ
Подход
1) Управление этапами
2) Управление процессом
3) Внедрение
4) Время жизни маршрута
5) Преимущественное
расположение протокола
управления маршрутизацией
Вариант
Центральным элементом
Распределенное
Сравнительные особенности
Больший функционал
Относительная простота реализации
Отказоустойчивость
Универсальность
Полностью ручное
Экстренное реагирование на угрозы
Автоматизированное Компромисс альтернатив
Полностью автомаУдобство использования
тическое
Полной заменой
Надежность
Безопасность
Постепенное
Поддержание работоспособности
всех участков сети
Только необходимое Скрытность
Постоянное
Скорость построения маршрута
В передаваемых
Простота реализации
данных
Широта функционирования в сети
В виде отдельного
Гарантированность маршрутизации
канала
Дополнительные возможности по
управлению
Рассмотренные подходы не являются взаимоисключающими и могут быть
применены совместно. Так, в случае требования максимальной надежности механизма ДМ, следует выбрать (см. таблицу 3.14) следующие варианты его реализации: система должна быть распределенной; механизм ДМ должен быть внедрен в
сеть «с нуля»; для управления маршрутизацией узлов по специальному протоколу
должен быть реализован соответствующий канал и т.д.
3.4.2 Требования к протоколу доверенной маршрутизации
Рассмотрим возможность реализации механизма ДМ с помощью соответствующего протокола, взяв за основу OSPF (от англ. Open Shortest Path First), как
110
наиболее близкого по целям и реализации. OSPF основан на технологии отслеживания состояния каналов и использует для нахождения кратчайшего пути алгоритм Дейкстры. В рамках протокола, маршрутизаторы обмениваются специальными пакетами с соседями, устанавливают логические отношения и синхронизируют топологическую базу данных. В конечном итоге, все базы маршрутизаторов
одной OSPF-зоны будут идентичными. В случае ДМ логические отношения
должны быть установлены лишь между доверенными узлами (то есть имеющими
агентов ДМ), а база данных должна содержать лишь доверенные маршруты. Этого можно добиться модификацией алгоритма Дейкстры, что потребует использования дополнительной идентификационной информации, а именно, наличия
столбца в топологической таблице, где будет храниться информация о существовании или отсутствии программного модуля (агента) ДМ в маршрутизаторах сети
OSPF.
Определим требования к протоколу ДМ в терминах рассмотренных вариантов реализации ее механизма
Во-первых, протоколы динамической маршрутизации основываются на
равноправном отношении узлов сети – например, в OSPF единая таблица маршрутов создается в каждом из узлов на основании их взаимного обмена. Следовательно, управление механизмом ДМ должно быть распределенным, поэтому
начало передачи данных по доверенному каналу, управление передачей и ее завершение должны осуществляться каждым из маршрутизаторов, а не отдельно
выделенным узлом.
Во-вторых, управление всем процессом передачи должно быть полностью
автоматизированным, поскольку протоколы маршрутизации, как правило, подразумевают именно высокоскоростное (а в данном случае и динамическое) управление передачей трафика без участия человека и его субъективных временных решений.
И хотя, в-третьих, вопрос внедрения нового протокола в глобальные ТКС не
относится напрямую к самому протоколу, тем не менее, он может повлиять на
111
структуру последнего. Так, в случае необходимости максимально надежного и
безопасного перехода на новый протокол отпадает необходимости поддержки им
альтернативных – например, традиционного OSPF. И наоборот, если планируется
постепенный переход на протокол ДМ с минимизацией рисков прекращения
функционирования сети в результате непредсказуемых проблем такой интеграции, целесообразно сделать новый протокол совместно функционирующим с уже
работающими в сети. При необходимости (когда все критичные узлы будут обновлены и работа сети стабилизируется) протокол ДМ может быть полностью заменен на его «версию 2.0» без поддержки всех иных действующих. Таким образом, данное требование к протоколу ДМ зависит от условий интеграции в глобальную ТКС.
В-четвертых, хотя поддержка «жизни» канала передачи данных только необходимое время и способствует его скрытности, тем не менее, такая реализация
в рамках создания механизма ДМ посредством протокола (по крайне мере на базе
OSPF) представляется крайне проблематичной задачей. Постоянная же поддержка
доверенного маршрута в актуальном состоянии полностью соответствует особенности динамических протоколов – постоянному обмену данными между узлами
для поддержания актуальной таблицы всех маршрутов. Таким образом, рациональным решением является вариант реализации протокола ДМ вторым способом, хотя это и сделает его более подверженным атакам.
И, в-пятых, управление маршрутизацией в рамках протокола ДМ может
быть реализовано как посредством информации в передаваемых данных, так и явным заданием маршрута на всех транзитных узлах. Тем не менее, рациональным
решением видится использование возможностей самого разрабатываемого протокола – это гипотетически обеспечит заданную гарантированность доставки и заложит возможности для дополнительного функционала. При этом на трудоемкость реализации такой вариант не будет иметь сильного влияния, поскольку протокол ДМ и так разрабатывается изначально, а после полной интеграции и вовсе
может перейти на работу лишь с собственным функционалом.
112
Более детальное изучение и определение процедур работы протокола, его
форматов и спецификации является отдельной научно-исследовательской и опытно-конструкторской работой, и может быть рекомендовано для дальнейшего развития механизма ДМ.
Выводы по разделу 3
В качестве объекта исследовалась имитационная модель полносвязной сети
с ДМ на предмет установления свойств и границ эффективности механизма ДМ в
глобальных ТКС, а также рекомендаций по его совершенствованию и созданию
новых алгоритмов и процедур его реализации.
В ходе исследования:
1) В интересах установления свойств и границ эффективности механизма
ДМ в глобальных ТКС разработана имитационная модель полносвязной сети,
учитывающая отказы и временный контроллинг узлов. Последовательно разработаны концептуальная, алгоритмическая и программная модель на языке GPSS.
2) Путем экспериментов с разработанной имитационной моделью определена зависимость влияния допустимого и заданного времени передачи сообщения
по сети, времени контроллинга и обработки в узле, предельной интенсивности
контроллинга, а также надежностных характеристик маршрутизаторов на вероятности недоставки и своевременной доставки сообщений, интенсивность контроллинга и среднее время передачи сообщения.
3) С помощью разработанной имитационной модели оценена динамика влияния интенсивности контроллинга и заданного времени передачи на вероятность
своевременной доставки сообщений, а также проведен оптимизационный эксперимент, который показал, что имеет место некий оптимум в районе интенсивности контроллинга от 0.5 до 0.7, когда своевременность уже, а скрытность еще достаточно велика.
113
4) Произведена качественная оценка влияния механизма ДМ на информационную безопасность глобальных ТКС. которая подтвердила его потенциально высокую эффективность в качестве средства сетевой защиты. Оценка произведена
по уточненной методике оценивания «серьезности» сетевой атаки SANS/GIAC
для типовых угроз информационной безопасности глобальных ТКС.
5) Сформированы возможные подходы к реализации механизма ДМ с учетом установленных свойств, ограничений, границ и произведен их сравнительный
анализ, а также рассмотрена возможность реализации механизма ДМ на базе протокола OSPF.
Основным научным результатом, изложенным в третье разделе, являются
модель сети с ДМ, суть которой состоит в имитации механизма ДМ в полносвязной сети путем генерации и обслуживания потока сообщений в условиях отказов
узлов и их временного контроллинга, а также рекомендации по совершенствованию механизма ДМ, суть которых состоит формировании вариантов его реализации и обосновании требований к перспективному протоколу доверенной маршрутизации на основе OSPF.
Частным научным результатом, изложенными в третьем разделе, является
оценка влияния механизма ДМ на информационную безопасность глобальных
ТКС.
Основное содержание третьего раздела и полученных научных результатов
изложено в работах автора [62-65].
114
ЗАКЛЮЧЕНИЕ
В работе исследовался механизм доверенной маршрутизации на алгоритмизации, программной реализации, оценки эффективности механизма в глобальных
телекоммуникационных сетях и рекомендаций по его совершенствованию.
В соответствии с целевой установкой были решены следующие задачи.
1) Проанализированы возможности реализации механизма доверенной
маршрутизации «штатными» средствами TCP/IP;
2) Разработаны специальные средства доверенной маршрутизации;
3) Синтезирована программная архитектура системы управления доверенной маршрутизацией;
4) Оценена эффективность механизма доверенной маршрутизации в глобальных телекоммуникационных сетях;
5) Выработаны рекомендаций по совершенствованию механизма доверенной маршрутизации.
В ходе решения указанных задач были получены основные научные результаты, выносимые на защиту, а именно:
1) Метод доверенной маршрутизации в глобальных телекоммуникационных
сетях;
2) Программная архитектура системы управления доверенной маршрутизацией;
3) Модель сети с доверенной маршрутизацией и рекомендации по совершенствованию реализации механизма защиты.
Полученные результаты являются достоверными, обладают необходимой
степенью новизны, имеют теоретическую ценность и практическую значимость,
апробированы и опубликованы в 15 научных трудах.
Кроме того в работе получен ряд частных научных результатов. Во-первых,
установлены ограничения «штатных» средств TCP/IP, необходимых для реализации механизма ДМ в глобальных ТКС. Во-вторых, разработаны специальные ал-
115
горитмические средства, достаточные для реализации механизма ДМ,
ориги-
нальный протокол канала информационного взаимодействия элементов системы
управления ДМ, а также типовые сценарии функционирования механизма ДМ в
программной среде TraConDa. В-третьих, оценено влияние механизма ДМ на информационную безопасность глобальных ТКС.
Совокупность полученных научных результатов свидетельствует о достижении поставленной цели исследования - установлены возможные способы реализации, ограничения и условия применения, а также границы эффективности
механизма ДМ в глобальных телекоммуникационных сетях.
Даны рекомендации по совершенствованию механизма ДМ, для чего рассмотрены возможные подходы (варианты) к реализации механизма ДМ с учетом
полученных новых знаний и обоснованы требования к перспективному протоколу
ДМ на основе OSPF.
Значимой вехой на пути совершенствовании реализации механизма ДМ
следует считать его доведение до состояния возможности полноценного практического использования. Критериями этого может быть появление у механизма
статуса «стандартизованного» и его распространение в реальных системах. Для
этого необходимо проведение целого спектра научных исследований по трем следующим направлениям, совокупность которых можно считать основными перспективами дальнейшей разработки настоящей темы.
Во-первых, это разработка стандарта механизма ДМ. Описание механизма в
работе было дано в слабо-формализованной форме, поскольку основным ее предназначением служило исследование принципиальной возможности реализации.
Доведения же до стандарта требует четкой и детальной проработки всех аспектов
механизма в специализированном виде. Такое представление должно быть согласовано и гармонизировано со смежными стандартами, следуя которым реализуется большинство других механизмов. В ином случае реализация механизма ДМ в
строгом соответствии со стандартом может оказаться неработоспособной в некоторых сетевых окружениях. Очевидно, что данному исследованию должен пред-
116
шествовать анализ существующих стандартов, решающих подобные задачи или
описывающих подобные механизмы.
Во-вторых, это разработка спецификации сетевых протоколов ДМ. Механизм ДМ считается распределенным, поскольку его элементы – сетевые узлы –
разделены в пространстве и связаны средствами передачи данных. При этом механизм может спокойно функционировать на целом наборе компьютерных сетей
(для которых актуальны вопросы доверительной функциональности управления
маршрутизацией), поскольку он никак не завязан на работоспособности лишь в
какой-то конкретной ТКС. Таким образом, помимо стандарта самого механизма
необходимы спецификации используемых им протоколов для работы «поверх»
большинства сетей и стеков. В этом случае разработчики смогут создавать систему управления ДМ для необходимой сети, строго следуя выбранной спецификации, не проводя каких-либо исследований и доработок. Также следует уделить
дополнительное внимание вопросу сокрытия управляющих каналов и данных механизма, например при помощи протокольной стеганографии.
В-третьих, это разработка методик по внедрению системы управления ДМ.
Очевидно, что попытки создания системы управления ДМ на «чистой» сети
крайне маловероятны. Массовое внедрение функционала механизма в существующую сеть (например, путем замены целой группы узлов) несет в себе риск приведения ее в неработоспособное состояние. Постепенное же внедрение (сопровождаемое созданием резервных точек и постоянным мониторингом) хотя и
наиболее безопасно, однако для крупных и растущих сетей будет являться крайне
негибким и занимающим длительное время процессом. Таким образом, для практического развертывания системы управления ДМ необходимо достаточное количество методик ее внедрения, применимых для большинства востребованных задач и предназначенных для изначального, группового и единичного внедрения.
Выполнение перспективных исследований по перечисленным направлениям
позволит дополнить теоретическую базу механизма ДМ необходимой методологической информацией, достаточной для его применения на практике.
117
СПИСОК ЛИТЕРАТУРЫ
1. Буйневич, М. В. Организационно-техническое обеспечение устойчивости
функционирования и безопасности сети связи общего пользования / М. В. Буйневич, А. Г. Владыко, С. М. Доценко, О. А. Симонина. - СПб.: Изд-во СПбГУТ,
2013. - 144 с.
2. Буйневич, М. В. Анализ возможности безопасного масштабирования телекоммуникационной структуры АСУ путем принудительной маршрутизации трафика стандартными средствами/ М. В. Буйневич, А. Е. Магон, Д. М. Ширяев //
Вопросы современной науки и практики. Университет им. В.И. Вернадского.2008. - № 3(13).– Том 2. Серия «Технические науки». – С. 161–164.
3. Abraham, I. Alternative routes in road networks / I. Abraham, D. Delling, A. V.
Goldberg & R. F. Werneck // Journal of Experimental Algorithmics (JEA). – 2013. – V.
18. – PP. 1-3.
4. Wang, Z. Analysis of shortest-path routing algorithms in a dynamic network environment / Z. Wang, J. Crowcroft // ACM SIGCOMM Computer Communication Review. – 1992. – Т. 22. - № 2. – PP. 63–71.
5. Зима, В. М. Безопасность глобальных сетевых технологий / В. М. Зима, А.
А. Молдовян, Н. А. Молдовян. - СПб.: БХВ-Петербург, 2001. - 320 с.
6. Зима, В. М. Подход к построению защищенных распределенных сетей обработки данных на основе доверенной инфраструктуры / С. В. Новиков, В. М. Зима, Д. В. Андрушкевич // Труды СПИИРАН. - 2015. - Вып. 38. - C. 34-57.
7. Калинин, М. О. Обеспечение доверенности информационной среды на основе расширения понятия «целостность» и управления безопасности / П. Д. Зегжда, М. О. Калинин // Проблемы информационной безопасности. Компьютерные
системы. - 2009. - № 4. - С. 7-16.
8. Калинин, М. О. Безопасная маршрутизация в Mesh-сетях с выявлением недоверенных узлов и применением генетических алгоритмов оптимизации маршрутов / М. О. Калинин, А. А. Минин // Региональная информатика (РИ-2014): ма-
118
тер. XIV Санкт-Петербургской Междунар. конф., г. Санкт-Петербург, 29-31 октября 2014 г. – СПб.: СПОИСУ, 2014. - С. 141.
9. Макаренко, С. И. Адаптация параметров сигнализации в протоколе маршрутизации с установлением соединений при воздействии на сеть дестабилизирующих факторов / С. И. Макаренко, Р. Л. Михайлов // Системы управления, связи
и безопасности. - 2015. - № 1. - С. 98–126.
10. Макаренко, С. И. Модель функционирования маршрутизатора в сети в
условиях ограниченной надежности каналов связи / С. И. Макаренко, Р. Л. Михайлов // Инфокоммуникационные технологии. - 2014. - Т. 12. - № 2. - С. 44–49.
11. Макаренко, С. И. Формирование резервных путей на основе алгоритма
Дейкстры
в
целях
повышения
устойчивости
информационно-
телекоммуникационных сетей / С. И. Макаренко, Р. Л. Михайлов, К. Ю. Цветков
// Информационно-управляющие системы. - 2014. - № 2(69). - С. 71-78.
12. Марголис, Б. И. Оптимальная маршрутизация с использованием критерия
перегрузки сети / Г. А. Дмитриев, Б. И. Марголис, М. М. Музанна // Программные
продукты и системы. - 2013. - № 4. - С. 173-176.
13. Марголис, Б. И. Синтез магистральных телекоммуникационных сетей / Б.
И. Марголис, М. М. Музанна // Программные продукты и системы. - 2014. - № 1.
- С. 162-168.
14. Новиков, С. Н. Классификация методов маршрутизации в мультисервисных сетях связи // Вестник СибГУТИ. - 2013. - № 1 (21). - С. 57-67.
15. Новиков, С. Н. Обеспечение конфиденциальности передаваемой информации на сетевом уровне // С. Н. Новиков, О. И. Солонская // Научно-технические
ведомости Санкт-Петербургского государственного политехнического университета. - Серия «Информатика. Телекоммуникации. Управление. - 2009. - Т. 4. № 82. - С. 60-65.
16. Новиков, С. Н. Обеспечение целостности в мультисервисных сетях // С.
Н. Новиков, О. И. Солонская // Проблемы информатики. - 2009. - № 4. - С. 37-40.
119
17. Somasundaram, K. K. Path Optimization and Trusted Routing in MANET: An
Interplay Between Ordered Semirings / K. K. Somasundaram & J. S. Baras // Advances
in Networks and Communications. − Springer Berlin Heidelberg, 2011. − PP. 88-98.
18. Гольдштейн, Б. С. Сети связи пост-NGN / Б. С. Гольдштейн, А. Е. Кучерявый. - СПб. : БХВ-Петербург, 2013. - 160 с.
19. Гольдштейн, Б. С. Сети связи / Б. С. Гольдштейн, Н. А. Соколов, Г. Г.
Яновский. - СПб. : БХВ-Петербург, 2011. - 399 с.
20. Гольдштейн, Б. С. Интеллектуальные сети / Б. С. Гольдштейн, И. М.
Ехриель, Р. Д. Рерле. - М.: Радио и связь, 2000.- 500 с.
21. Ефимушкин, В. А. Сравнительный анализ архитектур и протоколов программно-конфигурируемых сетей / В. А. Ефимушкин, Т. В. Ледовских, Д. М. Корабельников, Д. Н. Языков Д.Н. // Электросвязь. - 2014. - № 8. - С. 9-14.
22. Ефимушкин, В. А. Архитектура QoS для конвергентных сетей и особенности ее применения / В. А. Ефимушкин, И. В. Углов // T-Comm: Телекоммуникации и Транспорт. – 2010. – № 7. – С. 162-163.
23. Ефимушкин, В. А. Механизмы взаимодействия функциональных элементов конвергентной сети при предоставлении инфокоммуникационных услуг / В.
А. Ефимушкин, И. В. Углов // Электросвязь. – 2010. – № 8. – С. 29-32.
24. Clemm, A. Network management fundamentals / A. Clemm. - Indianapolis:
Cisco Press. - November 21, 2006. - P. 552.
25. Comer, Douglas E. Automated network management systems / D. E. Comer. New Jersey: Pearson Prentice Hall. - December 7, 2007. - P. 342.
26. Костин, А. А. Проектирование системы централизованного управления
ССОП России в чрезвычайных ситуациях // Электросвязь. - 2013. - № 3. - С. 4146.
27. Костин, А. А. Управление производительностью сети и качеством предоставляемых услуг / А. А. Костин, В. В. Ребров // Электросвязь. - 2009. - № 2. - С.
42-45.
120
28. Нетес, В. А. Мониторинг параметров работы сетей и временная синхронизация / В. А. Нетес // T-Comm: Телекоммуникации и транспорт. 2014. - Т. 8. № 2. - С. 36-37.
29. Нетес, В. А. Управление сетями связи: люди - процессы – технологии / В.
А. Нетес // Вестник связи. - 2008. - № 8. - С. 28-32.
30. Нетес, В. А. Сеть управления электросвязью (TMN) [Электронный ресурс] / В. А. Нетес // Сети и системы связи. - 2007. - № 11 - Режим доступа:
http://www.ccc.ru/magazine/depot/96_10/read.html?0301.htm.
31. Гатчин, Ю. А. Формирование признаков описания агентного множества
оценки информационной безопасности систем / Ю. А. Гатчин, С. В. Ширяев //
Научный вестник Новосибирского государственного технического университета.
- 2014. - № 2(55). - С. 105-108.
32. Гатчин, Ю. А. Архитектура программного обеспечения автоматизированного рабочего места разработчика бортового авиационного оборудования / Ю. А.
Гатчин, И. О. Жаринов, О. О. Жаринов // Научно-технический вестник информационных технологий, механики и оптики. - 2012. - № 2(78). - С. 140-141.
33. Котенко, И. В. Многоагентное моделирование механизма защиты от распределенных компьютерных атак / И. В. Котенко, А. В. Уланов // Информационные технологии. - 2009. - № 2. - С. 38-44.
34. Котенко, И. В. Архитектура системы интеллектуальных сервисов защиты
информации в критически важных инфраструктурах / И. В. Котенко, И. Б. Саенко
// Труды СПИИРАН. - 2013. - Вып. 1(24). - С. 21-40.
35. Lin, H. (ed.) Architectural Design of Multi-Agent System: Technologies and
Techniques / H. Lin. - IGI Global, 2007. - P. 442.
36. Саенко, И. Б. Метод интеллектуального многоагентного управления рисками информационной безопасности в защищенных мультисервисных сетях специального назначения / С.А. Агеев, И. Б. Саенко // T-Comm: Телекоммуникации и
транспорт. - 2015. - Т. 9. - № 1. - С. 5-10.
121
37. Schumacher, M. Objective Coordination in Multi-Agent Engineering: Design
and Implementation / M. Schumacher. - Springer-Verlag, 2001. - P. 124.
38. Зацаринный, А.А. Метод формирования системы показателей живучести
информационно-телекоммуникационных сетей / А. А. Зацаринный, Н. Г. Буроменский, А. И. Гаранин А.И. // Системы и средства информатики. - 2014. - Т. 24.
- № 1. - С. 138-152.
39. Зацаринный, А.А. Некоторые методические подходы к оценке надежности элементов информационно-телекоммуникационных сетей / А. А. Зацаринный,
С. В. Козлов, А. И. Гаранин А.И. // Системы и средства информатики. - 2011. - Т.
21. - № 2. - С. 21-23.
40. Назаров, А. Н. Модели и методы исследования процессов функционирования и оптимизации построения сетей связи следующего поколения / А.Н. Назаров, К.И. Сычев // Электросвязь. - 2011. - № 3. - С. 43-49.
41. Попков, В. К. Исследование имитационной модели живучести интегральной информационной сети / В. П. Блукке, В. К. Попков // Электросвязь. - 2010. № 11. - С. 52-56.
42. Попков, В. К. Модели анализа устойчивости и живучести информационных сетей / В. К. Попков, В. П. Блукке, А. Б. Дворкин // Проблемы информатики.
- 2009. - № 4. - С. 63-78.
43. Стародубцев, Ю.И. Моделирование системы защиты информационнотелекоммуникационной сети, используемой при обеспечении бизнес-процессов /
Ю. И. Стародубцев, О. А. Баленко, Г. А. Терентьев // Проблемы экономики и
управления в торговле и промышленности. - 2013. - № 1. - С. 110-115.
44. Стародубцев, Ю.И. Модель процесса мониторинга безопасности информации в информационно-телекоммуникационных системах / Ю. И. Стародубцев,
В. Г. Ерышов, А. С. Корсунский // Автоматизация процессов управления. - 2011.
- № 1. - С. 58-61.
45. Шелупанов, А. А. Имитационная модель комплексной сети систем безопасности / С. Ю. Исхаков, А. А. Шелупанов, А. Ю. Исхаков // Доклады Томского
122
государственного университета систем управления и радиоэлектроники. - 2014. № 2 (32). - С. 82-86.
46. Шелупанов, А. А. Модель надежности передачи информации в защищенной распределенной телекоммуникационной сети / А. Ю. Крайнов, Р. В. Мещеряков, А. А. Шелупанов // Известия Томского политехнического университета. 2008. - Т. 313. - № 5. - С. 60-63.
47. Шелупанов, А. А. Имитационное моделирование системы передачи сообщений, использующей варьирование маршрутов / П. А. Мельниченко, А. А.
Шелупанов // Доклады Томского государственного университета систем управления и радиоэлектроники. - 2008. - Т. 2. - № 1. - С. 118-120.
48. Шелухин, О. И. Имитационное моделирование аномалий трафика в локальной компьютерной сети / О. И. Шелухин, А. В. Савелов // T-Comm: Телекоммуникации и транспорт. - 2013. - Т. 7. - № 10. - С. 103-109.
49. Шелухин, О. И. Разработка программного обеспечения для имитационного моделирования системы широкополосного доступа WIMAX в среде MATLAB
SIMULINK / О. И. Шелухин, Ю. А. Иванов, К. А. Ненахов, А. В. Арсеньев //
Электротехнические и информационные комплексы и системы. - 2010. - Т. 6. № 3. - С. 23-33.
50. Язов, Ю. К. Имитационная модель процесса перехвата информации при
ее обработке в информационной системе, построенной с использованием беспроводной технологии IEEE 802.11B / В. Б. Шербаков, Ю. К. Язов, Г. В. Кретинин //
Информация и безопасность. - 2012. - Т. 15. - № 1. - С. 15-22.
51. Тиамийу, О. А. Анализ IP-протоколов для доверенной маршрутизации в
глобальных сетях передачи данных / О. А. Тиамийу // Вестник ИНЖЭКОНа.2012.- № 8(59).- Серия « технические науки ».- С. 157-159.
52. Тиамийу, О. А. Проблемные вопросы международной стандартизации в
области информационной безопасности / О. А. Тиамийу, Д. А. Олаоде, Ф. Ахмаммуш // Вестник ИНЖЭКОНа.- 2013.- № 8(67).- Серия «технические науки».С. 100-102.
123
53. Тиамийу, А.О. Беспроводные широкополосные сети vs безопасность / М.
В. Буйневич, К. А. Горохова, О. А. Тиамийу // Фундаментальные исследования и
инновации в национальных исследовательских университетах: матер. XVI Всероссийской научно-методической конференции, г. Санкт-Петербург, 17-18 мая
2012 г.- СПб.: СПбГПУ, 2012.- С. 170-173.
54. Тиамийу, О. А. Обзор задач безопасности современных телекоммуникационных сетей / О. А. Тиамийу // Национальная безопасность и стратегическое
планирование. − 2013. − № 2 (2). − С. 37-43.
55. Тиамийу, О. А. Доверенная маршрутизация vs VPN за безопасность передачи данных по IP-сетям/Интернет / О. А. Тиамийу // Фундаментальные и прикладные исследования в современном мире: матер. Междунар. науч.-практ. конф.,
г. Санкт-Петербург, 20-22 июня 2013 г. – СПб: Инф.-изд. центр «Стратегия будущего», 2013. – С. 63-70.
56. Тиамийу, О. А. Доверенная маршрутизация vs MPLS: безопасность данных, качество обслуживания и масштабируемость / О. А. Тиамийу // Информационные технологии и телекоммуникации: электрон. науч. журнал. СПбГУТ. – 2013.
– Вып. 3. – С. 4-13.
57. Тиамийу, О. А. Выбор и обоснование алгоритма определения топологии
сети в интересах доверенной маршрутизации / О. А. Тиамийу // Информационные
технологии и телекоммуникации: электрон. науч. журнал. СПбГУТ. – 2014. –
Вып. 1. – С. 54-66.
58. Тиамийу, О. А. Программная архитектура системы управления доверенной маршрутизации в глобальных телекоммуникационных сетях / М. В. Буйневич, О. А. Тиамийу // Информатизация и связь. – 2014. − № 3. − С. 35-38.
59. Тиамийу, О. А. Устройство доверенной маршрутизации в телекоммуникационных сетях: пат. на полезную модель 150245 Рос. Федерация: МПК51 H04L
12/723 (2013.01) / О. А. Тиамийу (Нигерия); заявитель и патентообладатель ФГОУ
ВПО С-Петербургский гос. университет телекоммуникаций. – № 2014105205/08;
заявл. 12.02.14; опубл. 10.02.15; Бюл. № 4. – 8 с.: ил.
124
60. Тиамийу О. А. Обеспечение конфиденциальности трафика путем его
маршрутизации от источника / О. А. Тиамийу // Новые информационные технологии и системы: тр. X Междунар. науч.-техн. конф., г. Пенза, 27–29 ноября 2012 г.
– Пенза: Изд-во ПГУ, 2012. – С. 153-156.
61. Тиамийу, О. А. Управление трафиком при механизме доверенной маршрутизации / О. А. Тиамийу // Региональная информатика (РИ-2014): матер. XIV
Санкт-Петербургской Междунар. конф., г. Санкт-Петербург, 29-31 октября 2014 г.
– СПб.: СПОИСУ, 2014. - С. 163-164.
62. Тиамийу, О. А. Имитационные эксперименты с моделью полносвязной
телекоммуникационной сети по исследованию механизма доверенной маршрутизации / М. В. Буйневич, О. А. Тиамийу // Телекоммуникации. – 2014. − № 2. − С.
6-16.
63. Тиамийу, О. А. Сравнительный анализ средств имитационного моделирования ТКС, поддерживающих доверенную маршрутизацию / О. А. Тиамийу // Актуальные проблемы информационной безопасности: сб. научн. тр.; отв. ред. Е. В.
Стельмашонок. – СПб.: СПбГИЭУ, 2012. – С. 49-53.
64. Тиамийу, О. А. К вопросу о моделировании механизма доверенной маршрутизации / О. А. Тиамийу // Актуальные проблемы инфотелекоммуникаций в
науке и образовании: матер. II-ой Междунар. науч.-техн. и науч.-метод. конф., г.
Санкт-Петербург, 26–27 февраля 2013 г. - СПб.: СПбГУТ, 2013. - С. 879-882.
65. Тиамийу, О. А. Рекомендации по совершенствованию реализации механизма доверенной маршрутизации / О. А. Тиамийу // Актуальные проблемы инфотелекоммуникаций в науке и образовании: матер. IV-ой Междунар. науч.-техн.
и науч.-метод. конф., г. Санкт-Петербург, 3-4 марта 2015 г. - СПб.: СПбГУТ,
2015. - С. 571-575.
66. Буйневич, М.В. Систематизация компьютерных атак на телекоммуникационные сети в контексте модели нарушителя / М. В. Буйневич // Вестник СанктПетербургского университета МВД России.- 2005. - № 3(27-2). – С. 306-315.
125
67. ГОСТ Р ИСО 7498–2–99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Ч. 2. Архитектура защиты информации. - М.: Изд-во стандартов, 1999. - 39 с.
68. Provan, D. RFC 1234: Tunneling IPX traffic through IP networks / D. Provan
// Internet Engineering Task Force (IETF). – 1991.
69. Rosen E. RFC 4364: MPLS IP Virtual Private Networks (VPNs) / E. Rosen, Y.
Rekhter // Internet Engineering Task Force (IETF). – 2006.
70. Ghein, L. D. MPLS Fundamentals / L. D. Ghein. - Indianapolis: Cisco press,
2006. − P. 672.
71. Awduche, D. О. MPLS and traffic engineering in IP networks / D. O. Awduche
// Communications Magazine, IEEE. – 1999. – Т. 37. - № 12. – PP. 42-47.
72. Davie, B. MPLS: technology and applications / B. Davie & Y. Rekhter. – New
York.: Morgan Kaufmann Publishers Inc., 2000.
73. Iwan, P.-E. What Is MPLS and GMPLS? Retrieved from Metaswitch Networks
website. [Electronic resource] / P.-E. Iwan. – 2013. − Access mode: http:// network technologies.metaswitch.com/mpls/what-ismpls-and-gmpls.aspx.
74. Hagen, S. IPv6 essentials / S. Hagen. - California: O'Reilly Media, Inc., 2006.
– P. 438.
75. Kitamura, H. (2000). Record Route for IPv6 (RR6) Hop-by-Hop Option Extension / H. Kitamura // Work in progress. − November 2000. – P. 15.
76. Deering, S. RFC 1256: ICMP router discovery messages / S. Deering // Internet Engineering Task Force (IETF). − 1991.
77. Malkin, G. S. RFC 1393: Traceroute using an IP option / G. S. Malkin // Internet Engineering Task Force (IETF). − 1993.
78. Branigan, S. What can you do with traceroute? / S. Branigan, H. Burch, B.
Cheswick & F. Wojcik // Internet Computing, IEEE. – 2001. – V. 5. − № 5. – PP. 96.
79. Ben, H. Understanding slow BGP routing table transfers / H. Ben, M. Meulle
& R. Teixeira // Internet Measurement Conference, 2009. 9th ACM SIGCOMM confer-
126
ence on Internet measurement conference. Chicago, 4-6 November 2009. Proceedings
of the 9th ACM SIGCOMM conference. – Chicago: ACM, 2009. − PP. 350-355.
80. Walsh, L. SNMP MIB Handbook: essential guide to MIB development, use
and diagnosis / L. Walsh. - Wyndham Press, 2008. – P. 408.
81. Keys, K. Internet-scale IP alias resolution techniques / K. Keys // ACM
SIGCOMM Computer Communication Review, 2010. – № 40(1). – PP. 50-55.
82. Marchetta, P. A. Yet another active probing technique for alias resolution / P.
Marchetta, V. Persico & A. Pescapé // ACM CoNEXT, 2013. – PP. 229-234.
83. Gunes, M. H. Analytical IP alias resolution / M. H. Gunes & K. Sarac // IEEE
International Conference on Communications, 2006. ICC'06. Istanbul, 11-15 June
2006.: Proceedings of conference. – IEEE, ICC'06. − V. 1. − PP. 459-464.
84. Daigle, L. RFC 3912: WHOIS protocol specification / L. Daigle // Internet Engineering Task Force (IETF). – 2004.
85. Wolfgang, M. Exploiting Cisco Routers: Part 1 [Electronic resource] / M.
Wolfgang. − September 28, 2003. − Access mode: http://www.symantec.com/connect/
articles/exploiting-cisco-routers-part-1.
86. Wolfgang, M. Exploiting Cisco Routers: Part 2 [Electronic resource] / M.
Wolfgang. – December 1, 2003. − Access mode: http://www.symantec.com/connect/
articles/exploiting-cisco-routers-part-2.
87. Boney, J. Cisco IOS in a Nutshell / J. Boney. – California: O'Reilly Media,
Inc., 2005. – P. 798.
88. Cisco Systems, Inc. Internetworking Technologies Handbook / Cisco Systems,
Inc. − Indianapolis: Cisco press, 2004. – P. 1078.
89. Leinwand, A. Cisco router configuration / A. Leinwand, B. Pinsky & M. Culpepper. − Indianapolis: Cisco press. – 1998. – P. 436.
90. Pham, E. (2001). CISCO-CDP-MIB. my.[CP]. Cisco Systems.
91. Empson S. CCNA Routing and Switching Portable Command Guide, Third
Edition / S. Empson. - Indianapolis: Cisco press. - June 22, 2013. − P. 320.
127
92. Dijkstra, E. W. A Note on Two Problems in Connexion with Graphs / E. W.
Dijkstra // Numerische Mathematik. − 1959. – V. 1. − Issue 1. − PP. 269-271.
93. Кормен, Томас Х. Алгоритмы: построение и анализ / Т.Х. Кормен, Ч.И.
Лейзерсон, Р.Л. Ривест, К. Штайн. - М.: Вильямс, 2013. - 1324.
94. Wang, Z. Analysis of shortest-path routing algorithms in a dynamic network
environment / Z. Wang, J. Crowcroft // ACM SIGCOMM Computer Communication
Review. – 1992. – Т. 22. - № 2. – PP. 63–71.
95. Кузнецов, Н. А. Алгоритм Дейкстры с улучшенной робастностью для
управления маршрутизацией в IP-сетях / Н.А. Кузнецов, В.Н. Фетисов // Автоматика и телемеханика. - 2008. - № 2. - С. 80-85;
96. Макаренко, С.И. Формирование резервных путей на основе алгоритма
Дейкстры
в
целях
повышения
устойчивости
информационно-
телекоммуникационных сетей / С.И. Макаренко, Р.Л. Михайлов, К.Ю. Цветков //
Информационно-управляющие системы.- 2014. - № 2(69). - С. 71-78.
97. Pat. 20130019317 A1 US: Secure routing based on degree of trust / Whelan, D.
A.; applicant «The Boeing Company», inventor «D. A. Whelan, G. M. Gutt, D. G. Lawrence, M. L. O'connor & А. Ayyagari» − № 13/366,098; filed Feb 3, 2012; published
Jan 17, 2013. – PP. 35.: illus.
98. Pat. 20120324218 A1 US: Peer-to-Peer Trusted Network Using Shared Symmetric Keys / Duren, M. J.; applicant « M. J. Duren, I. R. Menard, J. L. Rasmussen, K.
R. Thal », inventors « M. J. Duren, I. R. Menard, J. L. Rasmussen, K. R. Thal» − №
13/163,086; filed Jun 17, 2011; published Dec 20, 2012. – PP. 6. : illus.
99. Pat. 7984294 US: Method and apparatus for trust based routing in data networks / Goringe, C. M.; applicant «AVAYA INC.»; inventors «C. M. Goringe, М.
Minhazuddin, А. M. Scholte & J. Schreuder» − № 11/106,314; filed April 4, 2005, issued July 19, 2011. – PP. 9.: illus.
100. Пат. 2411673 Российская Федерация: H04L 12/56. Устройство маршрутизации, модуль маршрутизации и способ маршрутизации для сети доступа / Ван
128
Ден Абееле Ян, Резаки Али; заявитель и патентообладатель Алькатель Люсент. –
№ 2009107714; заявл. 03.08.2007; опубл. 10.02.2011. – 8 с. : ил.
101. Black, U. N. IP Routing Protocols: RIP, OSPF, BGP, PNNI and Cisco Routing Protocols / U. N. Black. − Prentice Hall. – March 10, 2000. – P. 387.
102. Argyraki, K. Loose source routing as a mechanism for traffic policies / K. Argyraki & D. R. Cheriton // ACM SIGCOMM workshop on Future directions in network
architecture. Portland, - August 30 - September 03, 2004: Proceedings of workshop. ACM. – 2004. − PP. 57-64.
103. Ben-Ameur, W. Routing strategies for IP networks / W. Ben-Ameur, N.
Michel, B. Liau, E. Gourdin // Telektronikk. – 2001. – Т. 97. - № 2/3. – PP. 145–158.
104. Medhi, D. Network routing: algorithms, protocols, and architectures / D.
Medhi. – San Francisco: Morgan Kaufmann, 2010.
105. Todd, L. Configuring static and default routing / L. Todd [Electronic resource]. – July 2001. – Access mode: http://www.techrepublic.com/article/ configuringstatic-and-default-routing/.
106. Alan, J. Choice Routing. [Electronic source] / J. Alan // CAMVIT. − 2005. –
Access mode: http://www.camvit.com/camvit-technical-english/Camvit- BackgrounderChoice-Routing-english.pdf.
107. McClure, S. Hacking exposed: network security secrets and solutions / S.
McClure, J. Scambray & G. Kurtz. - New York: McGraw-Hill, 2009. – P. 484.
108. Leitao, N. SNMP Sniff v1.0 / N. Leitao [Electronic resource]. – August 1999.
– Access mode: https://packetstormsecurity.com/files/14461/snmpsniff-1.0.tar.gz.html.
109. Wijnen, B. RFC 3414: User-based security model (USM) for version 3 of the
simple network management protocol (SNMPv3) / B. Wijnen and U. Blumenthal // Internet Engineering Task Force (IETF). − 2002.
110. Williams, R. M. Exploiting the SSH CRC32 Compensation Attack Detector
Vulnerabilities [Electronic resource] / R. M. Williams − 2001. − Access mode: http://
pen-testing.sans.org/resources/papers/gcih/exploiting-ssh-crc32-compensation-attackdetector-vulnerability-103026.
129
111. Singh, A. Vulnerability Analysis for DNS and DHCP / A. Singh, B.Singh &
H. Joseph // Vulnerability Analysis and Defense for the Internet. – New York: Springer.
– 2008. − PP. 111-124.
112. Lundh, F. Python Standard Library / F. Lundh. − California: O'Reilly Media,
Inc. − May 10, 2001. – P. 304.
113. Zetter, K. NSA Hackers Get the «Ungettable» With Rich Catalog of Custom
Tools [Electronic resource] / K. Zetter. – December 2013. − Access mode: http://www.
wired.com/2013/12/nsa-hackingcatalogue/.
114. Stallings, W. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 / W. Stallings.
- Addison-Wesley Longman Publishing Co., Inc., 1998. – P. 619.
115. Настройка SNMP в Windows Server 2008 R2 и Windows 7. Вкладка ловушек SNMP [Электронный ресурс].- Режим доступа: http://winintro.ru/snmp.ru/
html/68219299-c666-4737-ae36-3de0b3dd76cb.htm.
116. Chawdhary, G. Cisco IOS Shellcodes [Electronic resource] / G. Chawdhary &
V. Uppal – 2007. – Access mode: http://www.blackhat.com/presentations/bh-usa-08/
Chawdhary_Uppal/BH_US_08_Chawdhary_Uppal_Cisco_IOS_Shellcodes.pdf.
117. Lynn, M. The holy grail: Cisco IOS shellcode and exploitation techniques.
[Electronic resource] / M. Lynn. − July 2005. – Access mode: https://securityvulns.com/
files/lynn-cisco.pdf.
118. Muniz, S. Killing the myth of Cisco IOS rootkits / S. Muniz. − DIK. − 2008.
– P. 37.
119. Verma, D. C. Principles of computer systems and network management / D.
C. Verma. – New York: Springer, 2009. – P. 260.
120. Maier, M. W. The Art of Systems Architecting, Third Edition / M. W. Maier.
– London: CRC press. – January, 2009. – P. 472
121. Программа фундаментальных исследований VI.32: Архитектура, системные решения, программное обеспечение и информационная безопасность
информационно-вычислительных комплексов и сетей новых поколений. Систем-
130
ное программирование // Отчет ИВМ СО РАН за 2010 год.- http://icm. krasn.
ru/rprojects.php?id=470&scid=474.
122. Майоров А.А. Соловьев И.В. Проектирование информационных систем.
Фундаментальный курс / Под ред. В.П. Савиных.- М.: Академический проект,
2009.- 398 с.
123. Тихоненко, А. М. Определение архитектуры зон действия цепи базовых
станций АИС на ВВП России / Ю. Н. Андрюшечкин, В. В. Каретников , А. А. Сикарев, А. М. Тихоненко // Морская радиоэлектроника. - 2011. - № 4(38). - С. 1213.
124. Гатчин, Ю.А. Использование цифровых сертификатов и протоколов
SSL/TLS для шифрования данных при облачных вычислениях / М. Я. Беккер, Ю.
А. Гатчин, Н. С. Кармановский, А. О. Терентьев // Научно-технический вестник
информационных технологий, механики и оптики. - 2011. - № 4(74). - С. 125130.
125. Гатчин, Ю.А. Подход к задаче анализа эффективности системы безопасности на основе вероятностных оценок временных параметров процесса проникновения на защищаемый объект / В. В. Волхонский, Ю. А. Гатчин // Вестник компьютерных и информационных технологий. - 2012. - № 2. - С. 35-39.
126. Гатчин, Ю.А. Применение скрытых марковских моделей в системах обнаружения вторжений / Ю. А. Гатчин, К. В. Лазарев, В. И. Милушков // Вестник
компьютерных и информационных технологий. - 2012. - № 10. - С. 44-46.
127. Гатчин, Ю.А. Математические модели оценки инфраструктуры системы
защиты информации на предприятии / Ю. А. Гатчин, И. О. Жаринов, А. Г. Коробейников // Научно-технический вестник информационных технологий, механики
и оптики. - 2012. - № 2(78). - С. 92-95.
128. Макаренко, С. И. Оценка устойчивости сети связи в условиях воздействия на нее дестабилизирующих факторов / С. И. Макаренко, Р. Л. Михайлов //
Радиотехнические и телекоммуникационные системы. - 2013. - № 4. - С. 69–79.
131
129. Макаренко С. И., Моделирование обслуживания нестационарного информационного потока системой связи со случайным множественным доступом //
С. И. Макаренко, М. А. Татарков // Информационно-управляющие системы. 2012. - № 1. - С. 44-50.
130. Макаренко, С. И. Анализ математических моделей информационных потоков общего вида и степени их соответствия трафику сетей интегрального обслуживания // Вестник ВГТУ. - 2012. - Т. 8. - № 8. - С. 28-35.
131. Тихоненко, А. М. Математическая модель цифровых информационных
каналов речных автоматизированных идентификационных систем при воздействии взаимных помех / Т. А. Волкова, С. В. Рудых, А. М. Тихоненко // Журнал
университета водных коммуникаций. - 2011. - Вып. 4(12). - С. 121-125.
132. Томашевский, В.Н. Имитационное моделирование в среде GPSS / В.Н.
Томашевский, Е.Г. Жданова. – М.: Бестселлер, 2003. – 416 c.;
133. Боев, В.Д. Моделирование систем. Инструментальные средства GPSS
World / Д.В. Боев. – СПб.: БХВ-Петербург, 2004. – 368 с.;
134. Кудрявцева, Е.М. GPSS World. Основы имитационного моделирования
различных систем / Е.М. Кудрявцева. – М.: ДМК Пресс, 2003. – 320 с.
135. Сидняев, Н. И. Теория планирования эксперимента и анализ статистических данных / Н. И. Сидняев. - М.: Изд-во Юрайт; ИД Юрайт, 2011. - 399 с.
136. Cisco, Modern Network Security Threats, Cisco learning institute. – 2012.
[Electronic resource]. – 2012. – Access mode: http://www.google.ru/url?sa=t&rct=j&q=
&esrc=s&source=web&cd=5&ved=0CD4QFjAE&url=http%3A%2F%2Ffaculty.weber.
edu%2Fkcuddeback%2FClasses%2FNTM3300%2FSlides%2Fen_CCNAS_v11_Ch01.
pptx&ei=OuxYVLfuFIzqaJuYgtgN&usg=AFQjCNG16Ucfqkt8IiH3s_F_fIwJxgOQFw
&bvm=bv.78677474,d.d2s&cad=rjt.
137. Ростелеком начал коммерческую эксплуатацию защиты своей IP MPLSсети [Электронный ресурс] / PCWEEK newsletter. – 2012. – Режим доступа: http://
www.pcweek.ru/security/article/detail.php?ID=137656?ID=137656.
132
138. Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных (выписка) [Электронный ресурс] / ФСТЭК России (официальный сайт).- 2008. – Режим доступа:
http://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty/114-spetsialnye-normativnye -dokumenty.
139. Chapple, M. The GSEC Prep Guide: Mastering SANS GIAC Security Essentials / М. Chapple. – New Jersey: John Wiley & Sons, Inc., 2003. – P. 474.
140. Newfield, M. SANS GIAC Certification: Security Essentials Toolkit (GSEC)
/ M. Newfield, J. M. Millican. – Delhi: Pearson Education, 2002. - P. 384.