DEVELOPMENT AND RESEARCH OF DYNAMIC ADDRESS SPACE PROTOCOL ON MULTICAST-GROUPS

全文:

Введение. Удаленные атаки на информационные системы компаний - существенная проблема инфор- мационной безопасности на сегодняшний день. Перед осуществлением самой атаки злоумышленник прово- дит сетевую разведку, в ходе которой собирает дан- ные о структуре локальной сети, об используемых устройствах, программном обеспечении, их версиях и уязвимостях, об используемых средствах защиты. Для того, чтобы затруднить сетевую разведку зло- умышленника, применяется технология движущейся цели для перемешивания адресного пространства локальной сети или её сегмента. Алгоритм и разрабо- танный протокол динамической адресации не ограни- чивает в действиях злоумышленника, а лишь изменя- ет информацию, на основе которой злоумышленник принимает решение. В данной статье разработан, реализован и иссле- дован алгоритм динамической адресации, в основе которого лежит метод сокрытия узла путем ретранс- ляции сообщений через групповое вещание [1]. Используемые технологии. В основе алгоритма динамической адресации лежит технология движу- щейся цели (ТДЦ) - Moving Target Defense (MTD) [2]. Подход этот находится только на начальном этапе становления и уже привлек к себе серьезное внима- ние: в условиях распространения технологий виртуа- лизации, программно-конфигурируемых сетей (Soft- ware-Defined Network, SDN) и случайным образом формируемой схемы адресного пространства (Address Space Layout Randomization, ASLR) он стал весьма популярен [3]. Исследование безопасности подобных схем при- водит к следующим выводам: не должна нарушаться случайность передачи данных; не должен вводиться дополнительный контроль или передаваться дополни- тельная служебная информация, демаскирующая алгоритм передачи данных; не должны нарушаться требования аутентификации и авторизации. В работе [4] предлагается реализация алгоритма на основе технологии движущейся цели, реализующего передачу данных по случайно чередующимся каналам связи. Исследование этого алгоритма показывает необходимость дополнительной защиты узлов и исполь- зования сетевых протоколов, защищенных от иссле- дования. Исследование этой и подобных работ [2-4] приводит к возможности применения иных протоко- лов и принципов передачи, базирующихся на ограни- ченном широковещательном трафике с динамическим адресным пространством и внутренней аутентифика- цией на основе шифрования с открытым ключом (или стеганографических методов). В основе алгоритма, предложенного в работе, ле- жит идея перемещения узлов по мультикаст-группам и передачи данных средствами группового вещания в соответствующие мультикаст-группы [5]. Многоуровневая схема защиты с использованием движущейся цели, включающая как централизованную, так и децентрализованную схемы, может использо- ваться для полноценной адресации в компьютерных сетях, в том числе распределенных, для противодей- ствия атакам на компьютерные системы различных типов [6-8]. В рамках централизованного подхода с использованием SDN применимы технологии слу- чайного изменения адреса хоста для предотвращения сбора информации о компьютерной сети внешним злоумышленником [5; 9; 10], причем, как показывают исследования, при использовании криптографии этот тип защиты может быть более надежным, в частно- сти, за счет дополнительного обособления случайно выделяемых сегментов сети [1; 11]. Также можно отметить различные подходы к кон- фигурированию сети, в том числе с использованием случайного изменения адресов, которые приводят к невозможности реализации определенных типов атак [12-15], построению безопасных каналов пере- дачи данных [15], и некоторые другие. Злоумышленник, который прослушивает весь сетевой трафик, не может установить отправителя пакета и его получателя, так как пакет данных зашиф- рован и явно не указываются IP-адреса получателя и отправителя, а указаны лишь их идентификаторы. Принцип работы протокола. Узлы, участвующие в защищенном сегменте сети, подключаются к муль- тикаст-группе инициализации обмена, в которой про- исходит обмен идентификаторов участников защи- щенного сегмента сети. Каждый узел формирует свой список узлов-участников защищенного обмена. Затем каждый узел подключается к двум-трем мультикаст- группам, которые определяются специальным алго- ритмом и через которые участники защищенного сегмента сети обмениваются данными. Через интер- вал времени узел покидает мультикаст-группы обмена данными и заново определяет эти мультикаст-группы по алгоритму выбора новых мультикаст-групп обмена данными. На рис. 1 изображен защищенный сегмент сети, после того как узлы подключились к мультикаст- группе инициализации обмена и выбрали мультикаст- группы обмена. Состояние сегмента сети после истечения интер- вала времени и подключение к новым мультикаст- группам обмена данными отражено на рис. 2. Узлы перемещаются по мультикаст-группам через интервал времени, как показано на рис. 3. Рис. 1. Защищенный сегмент сети на этапе первой инициализации обмена Fig. 1. The protected segment of the network during the first initialization of the exchange Рис. 2. Состояние защищенного сегмента сети после перемещения узлов по мультикаст-группам обмена данными Fig. 2. The state of the protected network segment after moving nodes by multicast-groups of data exchange Если узел 1 хочет передать узлу 2 пакет данных, то узел 1 в качестве идентификатора получателя должен указать идентификатор узла 2, который получает узел 1 при подключении к мультикаст-группе для инициа- лизации обмена, а в качестве идентификатора отпра- вителя - свой идентификатор, и отправить пакет дан- ных в каждую мультикаст-группу. В свою очередь, каждый узел-участник мультикаст-группы, в которую был послан пакет, ретранслирует его в другие извест- ные узлу-участнику мультикаст-группы. Так как каж- дый узел-участник в результате алгоритма выбора мультикаст-группы обмена данных будет иметь хотя бы одну общую мультикаст-группу обмена данных с, как минимум, одним любым другим узлом- участником, то пакет данных гарантированно будет доставлен получателю. Рис. 3. Обмен данными в защищенном сегменте сети Fig. 3. Data exchange in a secure network segment В мультикаст-группу участники защищенного обмена данными не отправляют данные, эта группа предназначена для опроса активных узлов. Каждому пакету данных присваивается идентификатор. Иден- тификатор пакета необходим для того, чтобы узел мог отбрасывать уже отработанные пакеты данных. Каж- дый узел формирует базу отработанных пакетов. Узел сравнивает идентификатор пакета с идентификатора- ми уже отработанных пакетов, для того чтобы отбро- сить пакет данных, если он уже ранее был обработан. В том случае, если пакет был предназначен данному узлу, то он также ретранслирует его в известные мультикаст-группы обмена данными, в которых узел является участником. Если пакет предназначался не дан- ном узлу и является ранее не обработанным данным узлом, то пакет также ретранслируется (см. рис. 2). Использование такой последовательности позволяет: а) контролировать обмен пакетами; б) контролировать активность мультикаст-групп; в) корректно описывать процедуру обработки пакетов. Схема обработки пакетов показана на рис. 4. Протокол выбора новых мультикаст-групп обмена данными выглядит следующим образом. Задан общий числовой ключ длиной N. Случайным образом выбирается число q из позиции общего чи- слового ключа. Число m - минуты текущего времени, а h - часы текущего времени. Четвертый октет адреса мультикаст-группы вычисляется следующим образом: net = h + q + (m % 13). И так для каждой мультикаст-группы. Этот алго- ритм срабатывает через каждый интервал времени. Экспериментальное исследование протокола. Тестирование проводилось на тестовом стенде, который состоял из маршрутизатора Totolink N300RT, обеспечивающего передачу данных до 300 Мбит/с, ноутбука с шестью установленными виртуальными машинами VirtualBox под управлением ОС Lubuntu и Raspberry Pi 2 под управлением ОС Raspbian. За осно- ву взята методика тестирования устройств межсете- вых соединений по RFC2544. Тест проводился в трех вариантах. В ходе данного исследования определяется: 1. Максимальное количество кадров в секунду, ко- торое может быть передано по каналу без ошибок. Оно необходимо для проверки эффективности работы модуля определения маршрутных характеристик при передачи данных пользователя через сеть. Это иссле- дование выполняется, чтобы определить реальную максимальную скорость передачи данных, которую может обеспечить оборудование, а не скорость рабо- ты интерфейса отдельного устройства. Данный тест проводится на оборудовании со скоростью доступа к среде передачи в 100 и 1000 Мбит/с. 2. Время прохождения через устройство (или до узла назначения). Если время задержки значительно меняется от кадра к кадру, то это может стать про- блемой для работы таких сервисов, как VoIP, IPTV и TDMoIP, через данное оборудование. Например, вариация задержки может выразиться в ухудшении качества голоса, передаваемого с помощью техноло- гии VoIP или в значительном джиттере псевдопро- водного потока Е1, образованного с помощью техно- логии TDMoIP. Большое время задержки также может ухудшить качество работы приложений. Исследова- ние необходимо для проверки эффективности работы модуля определения маршрутных характеристик при передаче данных пользователя через сеть. Рис. 4. Обработка входящих пакетов данных Fig. 4. Processing of incoming data packets 3. Измерение частоты потери кадров необходимо для оценки способности оборудования работать в ус- ловиях перегрузки, что является критическим показа- телем возможности поддерживать приложения реаль- ного времени, в которых большое количество потерь резко снижает качество. Процедура проведения эксперимента. Процеду- ра проведения теста № 1 следующая: послать некото- рое количество пакетов Ntp на определенной скорости Rp на входной порт устройства. Посчитать пакеты, пришедшие с выходного порта устройства - Nrp. Если Nrp < Ntp, скорость Rp уменьшается и тест запускается снова. Пропускная способность - это максимальное Rpm = Rp, при котором выполняется равенство Nrp = = Ntp. Тест проводился в трех вариантах, когда между узлом-отправителем и узлом-получателем нет ни од- ного ретранслятора, когда между узлом-отправителем и узлом-получателем один ретранслятор и два ретранслятора. Для этого блокировались изменения адресного пространства в зависимости от приращения времени с целью ручного определения узлов, находя- щихся на требуемом количестве ретрансляторов друг от друга. Размеры кадров устанавливались в соответствии с методикой RFC 2544: 64, 128, 256, 1024, 1280, 1518 байт для конечных кадров Ethernet. Для принятия ре- шения о достижении максимальной скорости время безошибочной передачи данных для каждого размера кадров должно быть не менее 60 с. Количество итера- ций для каждого размера кадра - 10. Результаты теста (средние значения по итерациям) представлены в табл. 1 и 2. Процедура проведения теста № 2 начинается с определения Rpm (максимальная пропускная способ- ность) для каждого размера пакета. Для каждого раз- мера пакета Sp на соответствующей ему максималь- ной скорости Rpm посылается поток пакетов по опре- деленному адресу. Поток должен иметь длительность минимум 120 с. В 1 пакет по прошествии 60 с встав- ляется метка. Формат метки - implementation dependent. На передающей стороне записывается вре- мя Ta - время, к которому пакет с меткой был полно- стью отправлен. На приемной стороне определяется метка и записывается время Tb - время полного прие- ма пакета с меткой. Задержка - это разница Tb - Ta. Этот тест должен повторяться минимум 20 раз. По результатам 20 измерений вычисляется средняя задержка. Тест следует проводить, отправляя весь тестовый поток на один и тот же узел независимо от интервалов перестроения структуры сети. Результаты эксперимента (средние значения по итерациям) представлены в табл. 3 и 4. Процедура проведения теста № 3: на вход канала посылается определенное количество кадров Ntp на определенной скорости Rp и подсчитывается коли- чество кадров Nrp, принимаемых на выходе канала. Частота потери кадров LRp рассчитывается сле- дующим образом: LRp = ((Ntp - Nrp) · 100) / Ntp. Первая попытка должна проходить на максималь- ной скорости для данного соединения. Следующая попытка должна проходить на 90 % от максимальной скорости, а затем - на 80 %. Повторение попыток с уменьшением скорости тестового потока на 10 % должно продолжаться до тех пор, пока 2 попытки подряд не будут полностью безошибочными (LRp = 0). Максимальный шаг уменьшения скорости - 10 %. Согласно методикe RFC 6349 величина Nrp может быть заменена для протоколов с гарантированной доставкой данных на величину количества повторно отправленных данных. Исследования проводились для кадров длиной бо- лее 256 байт, позволяющих полностью передавать отправляемые сообщения. Для скорости канала в 1 % бралась скорость, полученная по результатам теста № 1 (табл. 1 и 2). В табл. 6 показано, насколько влияет использова- ние предлагаемой технологии на процент повторной передачи кадров (или потери кадров) для сети, которая может реально применяться в существующих ре- шениях. Важность повторного эксперимента с использова- нием порта в 1000 Мбит/с заключалась в необходимости показать возможность применения разработанного протокола в современных распределенных информа- ционно-вычислительных системах передачи данных. Кроме того, интересным экспериментом, планируе- мым на будущее, была бы передача сообщений по раз- рабатываемому протоколу в беспроводных сетях, где дифференциация скоростей передачи может быть иной. Результаты данного эксперимента представлены в табл. 5 и 6. По результатам экспериментальных исследований было установлено, что происходит падение скорости передачи с увеличением числа ретрансляторов при- мерно в 1,5 раза на каждый промежуточный узел. Данная особенность протокола отмечается для порта в 100 Мбит/с и, как показано в табл. 6, проверена в эксперименте с портом Gigabit Ethernet. Повторная передача/потеря кадров при уменьше- нии пропускной способности канала является мину- сом протокола, поскольку при его применении используется кадр фиксированной длины. Для оценки влияния фрагментации на сетевом уровне, а также канального уровня передачи данных эти показатели были повторно оценены в соотвествии с методикой эксперимента для случая с портом Giga- bit Ethernet. Таблица 1 Данные измерения пропускной способности для порта в 100 Мбит/с, Кбайт/с (средние значения по итерациям) Размер кадра, байт Итерации Без ретранслятора 1 ретранс- лятор 2 ретранс- лятора Размер кадра, байт Итерации Без ретранслятора 1 ретранс- лятор 2 ретранс- лятора 64 10 37 17 12 128 10 61 34 22 256 10 149 58 44 1024 10 667 212 164 1280 10 880 421 236 1512 10 1842 667 335 Таблица 2 Данные измерения пропускной способности для порта в 1000 Мбит/с, Кбайт/с (средние значения по итерациям) Размер кадра, байт Итерации Без ретранслятора 1 ретранс- лятор 2 ретранс- лятора Размер кадра, байт Итерации Без ретранслятора 1 ретранс- лятор 2 ретранс- лятора 64 10 326 223 138 128 10 501 411 355 256 10 1324 981 797 1024 10 6656 3572 3979 1280 10 12320 8827 5868 1512 10 22075 13993 10073 Таблица 3 Данные измерения задержки для порта в 100 Мбит/с, мс (средние значения по итерациям) Размер кадра, байт Итерации Без ретранслятора 1 ретранс- лятор 2 ретранс- лятора Размер кадра, байт Итерации Без ретранслятора 1 ретранс- лятор 2 ретранс- лятора 64 20 11 20 34 128 20 12 24 39 256 20 13 23 40 1024 20 12 24 43 1280 20 14 26 43 1518 20 15 27 46 Таблица 4 Данные измерения задержки для порта в 1000 Мбит/с, мс (средние значения по итерациям) Размер кадра, байт Итерации Без ретранслятора 1 ретранс- лятор 2 ретранс- лятора Размер кадра, байт Итерации Без ретранслятора 1 ретранс- лятор 2 ретранс- лятора 64 20 1,8 4 7,8 128 20 2,2 5 9,05 256 20 1,95 4,85 10,4 1024 20 3,3 5,1 11,7 1280 20 3,05 6,1 11,8 1518 20 4,05 7,3 13,05 Таблица 5 Процент повторной передачи/потери кадров для порта в 100 Мбит/с Размер кадра, байт % максимальной скорости канала Без ретранслятора 1 ретранслятор 2 ретранслятора 1024 100 100 100 100 90 73 100 100 80 46 100 100 70 41 100 100 60 35 100 100 50 33 100 100 40 29 100 100 30 24 100 100 20 20 100 100 10 10 60 67 1 0 0 0 1280 100 100 100 100 90 70 100 100 80 43 100 100 70 37 100 100 60 35 100 100 50 32 100 100 40 30 87 100 30 20 73 90 20 17 50 60 10 5 34 46 1 0 0 0 1518 100 100 100 100 90 68 100 100 80 44 100 100 70 35 100 100 60 36 100 100 50 33 100 100 40 29 89 100 30 21 71 94 20 6 51 58 10 0 34 49 1 0 0 0 Таблица 6 Процент повторной передачи/потери кадров для порта в 1000 Мбит/с Размер кадра, байт % максимальной скорости канала Без ретранслятора 1 ретранслятор 2 ретранслятора 1024 100 100 100 100 90 100 100 100 80 49 100 100 70 45 100 100 60 45 100 100 50 36 100 100 40 39 100 100 30 31 100 100 20 18 100 97 10 8 60 68 1 0 0 0 1280 100 100 100 100 90 100 100 100 80 43 100 100 70 37 100 100 60 32 100 100 50 29 100 100 40 31 86 100 30 22 75 96 20 17 42 83 10 6 19 27 1 0 0 0 Окончание табл. 6 Размер кадра, байт % максимальной скорости канала Без ретранслятора 1 ретранслятор 2 ретранслятора 1518 100 100 100 100 90 98 100 100 80 40 100 100 70 36 100 100 60 38 83 100 50 32 64 100 40 27 40 96 30 18 43 72 20 5 21 37 10 0 0 6 1 0 0 0 По результатам экспериментальных исследований было установлено, что происходит падение скорости передачи с увеличением числа ретрансляторов при- мерно в 1,5 раза на каждый промежуточный узел. Данная особенность протокола отмечается для портов как в 100, так и 1000 Мбит/с. Наибольшую производительность протокол пока- зывает на кадрах максимальной длины, что обуслов- лено меньшими потерями на ожидание доступа к среде передачи. На кадрах длиной до 256 байт не получает- ся полностью разместить пакет данных, и происходит фрагментация на сетевом уровне, что еще в большей мере увеличивает накладные расходы на передачу данных. Увеличение скорости передачи на Gigabit Ethernet обусловлено функцией режима пульсации на каналь- ном уровне. Заключение. Поскольку во время проведения тес- тирования в среде практически отсутствовал допол- нительный трафик, то были получены результаты для идеальных условий. При использовании в реальной высоконагруженной сети скорость передачи может снизиться. Малое отклонение результатов на каждой итерации обусловлено стабильностью функциониро- вания сети передачи и коммуникационного оборудо- вания. Также было подтверждено, что происходит увеличе- ние времени передачи с количеством промежуточных узлов примерно в 2 раза на каждый дополнительный промежуточный узел. Данная особенность протокола отмечается для портов как в 100, так и 1000 Мбит/с. Наименьшую задержку протокол показал для кадров минимальной длины, поскольку их доставка занимает минимальное время, и задержки вносятся в основном узлом при обработке кадра. С увеличением сторонне- го трафика в сети будет также увеличиваться времен- ная задержка, поскольку многоадресный трафик по умолчанию имеет меньший приоритет по сравне- нию с одноадресным. Для устранения данного недос- татка необходимо использовать технологии QoS на коммутирующем оборудовании для повышения приоритета трафика из используемого диапазона мультикаст-групп. Было показано, что при превышении максималь- ной скорости передачи, установленной по программе экспериментальных исследований при проведении теста № 1 (см. выше), начинается лавинообразный процесс потери данных. Данный факт обусловлен необходимостью обработки поступающих данных и проявляется в существенно большей степени при наличии в канале 1 и 2 ретрансляторов. Полученные данные согласуются с величинами задержек, полу- ченными в ходе экспериментальных исследований. Следовательно, протокол необходимо эксплуатиро- вать в неперегруженном режиме, и особое внимание следует уделить проверке корректности работы меха- низма гарантированной доставки данных. Полученные данные для определенной максимальной скорости передачи соответствуют установленным показателям и позволяют говорить о 20%-м запасе производитель- ности с увеличением скорости передачи. Для дости- жения скоростей передачи, достаточных для стан- дартной работы, рекомендуется использование под- ключения и оборудование на основе Gigabit Ethernet.

作者简介

N. Parot’kin

Reshetnev Siberian State University of Science and Technology

Email: nyparotkin@yandex.ru
31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660037, Russian Federation

I. Panfilov

Reshetnev Siberian State University of Science and Technology

31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660037, Russian Federation

V. Zolotarev

Reshetnev Siberian State University of Science and Technology

31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660037, Russian Federation

E. Kushko

Reshetnev Siberian State University of Science and Technology

31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660037, Russian Federation

T. Panfilova

Reshetnev Siberian State University of Science and Technology

31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660037, Russian Federation

参考

补充文件