Разработка и экспериментальное исследование протокола динамического адресного пространства на основе мультикаст-групп

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

В данной статье разработан, реализован и исследован алгоритм динамической адресации, в основе которого лежит метод сокрытия узла путем ретрансляции сообщений через групповое вещание [1].

Используемые технологии. В основе алгоритма динамической адресации лежит технология движущейся цели (ТДЦ) – Moving Target Defense (MTD) [2].

Подход этот находится только на начальном этапе становления и уже привлек к себе серьезное внимание: в условиях распространения технологий виртуализации, программно-конфигурируемых сетей (Software-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

/ Мульпжаст-группа инициал! нации

Мх льшкас!-

Мультикаст-группа 5

Рис. 2. Состояние защищенного сегмента сети после перемещения узлов по мультикаст-группам обмена данными

Мультпкаст-

Мульпжаст-группа4

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. Обработка входящих пакетов данных

  
  

• 3.    Измерение частоты потери кадров необходимо для оценки способности оборудования работать в условиях перегрузки, что является критическим показателем возможности поддерживать приложения реального времени, в которых большое количество потерь резко снижает качество.

Fig. 4. Processing of incoming data packets

Процедура проведения эксперимента. Процедура проведения теста № 1 следующая: послать некоторое количество пакетов N tp на определенной скорости R p на входной порт устройства. Посчитать пакеты, пришедшие с выходного порта устройства – N rp . Если N rp <  N tp , скорость R p уменьшается и тест запускается снова. Пропускная способность – это максимальное R pm = R p , при котором выполняется равенство N rp = = N tp .

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

Размеры кадров устанавливались в соответствии с методикой RFC 2544: 64, 128, 256, 1024, 1280, 1518

байт для конечных кадров Ethernet. Для принятия решения о достижении максимальной скорости время безошибочной передачи данных для каждого размера кадров должно быть не менее 60 с. Количество итераций для каждого размера кадра – 10.

Результаты теста (средние значения по итерациям) представлены в табл. 1 и 2.

Процедура проведения теста № 2 начинается с определения R pm (максимальная пропускная способность) для каждого размера пакета. Для каждого размера пакета S p на соответствующей ему максимальной скорости R pm посылается поток пакетов по определенному адресу. Поток должен иметь длительность минимум 120 с. В 1 пакет по прошествии 60 с вставляется метка. Формат метки – implementation dependent. На передающей стороне записывается время T a – время, к которому пакет с меткой был полностью отправлен. На приемной стороне определяется метка и записывается время T_b – время полного приема пакета с меткой. Задержка – это разница T b – T a .

Этот тест должен повторяться минимум 20 раз. По результатам 20 измерений вычисляется средняя задержка.

Тест следует проводить, отправляя весь тестовый поток на один и тот же узел независимо от интервалов перестроения структуры сети.

Результаты эксперимента (средние значения по итерациям) представлены в табл. 3 и 4.

Процедура проведения теста № 3: на вход канала посылается определенное количество кадров N tp на определенной скорости R p и подсчитывается количество кадров N_rp , принимаемых на выходе канала.

Частота потери кадров LR p рассчитывается следующим образом: LR p = (( N tp – N rp ) ∙ 100) / N tp .

Первая попытка должна проходить на максимальной скорости для данного соединения. Следующая попытка должна проходить на 90 % от максимальной скорости, а затем – на 80 %. Повторение попыток с уменьшением скорости тестового потока на 10 % должно продолжаться до тех пор, пока 2 попытки подряд не будут полностью безошибочными ( LR_p = 0).

Максимальный шаг уменьшения скорости – 10 %.

Согласно методикe RFC 6349 величина N rp может быть заменена для протоколов с гарантированной доставкой данных на величину количества повторно отправленных данных.

Исследования проводились для кадров длиной более 256 байт, позволяющих полностью передавать отправляемые сообщения.

Для скорости канала в 1 % бралась скорость, полученная по результатам теста № 1 (табл. 1 и 2).

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

Важность повторного эксперимента с использованием порта в 1000 Мбит/с заключалась в необходимости показать возможность применения разработанного протокола в современных распределенных информационно-вычислительных системах передачи данных.

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

Результаты данного эксперимента представлены в табл. 5 и 6.

По результатам экспериментальных исследований было установлено, что происходит падение скорости передачи с увеличением числа ретрансляторов примерно в 1,5 раза на каждый промежуточный узел. Данная особенность протокола отмечается для порта в 100 Мбит/с и, как показано в табл. 6, проверена в эксперименте с портом Gigabit Ethernet.

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

Для оценки влияния фрагментации на сетевом уровне, а также канального уровня передачи данных эти показатели были повторно оценены в соотвествии с методикой эксперимента для случая с портом Gigabit 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

Размер кадра, байт	% максимальной скорости канала	Без ретранслятора	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

Размер кадра, байт	% максимальной скорости канала	Без ретранслятора	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

Процент повторной передачи/потери кадров для порта в 100 Мбит/с

Процент повторной передачи/потери кадров для порта в 1000 Мбит/с

По результатам экспериментальных исследований было установлено, что происходит падение скорости передачи с увеличением числа ретрансляторов примерно в 1,5 раза на каждый промежуточный узел. Данная особенность протокола отмечается для портов как в 100, так и 1000 Мбит/с.

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

Увеличение скорости передачи на Gigabit Ethernet обусловлено функцией режима пульсации на канальном уровне.

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

Также было подтверждено, что происходит увеличение времени передачи с количеством промежуточных узлов примерно в 2 раза на каждый дополнительный промежуточный узел. Данная особенность протокола отмечается для портов как в 100, так и 1000 Мбит/с. Наименьшую задержку протокол показал для кадров минимальной длины, поскольку их доставка занимает минимальное время, и задержки вносятся в основном узлом при обработке кадра. С увеличением стороннего трафика в сети будет также увеличиваться временная задержка, поскольку многоадресный трафик по умолчанию имеет меньший приоритет по сравнению с одноадресным. Для устранения данного недостатка необходимо использовать технологии QoS на коммутирующем оборудовании для повышения приоритета трафика из используемого диапазона мультикаст-групп.

Было показано, что при превышении максимальной скорости передачи, установленной по программе экспериментальных исследований при проведении теста № 1 (см. выше), начинается лавинообразный процесс потери данных. Данный факт обусловлен необходимостью обработки поступающих данных и проявляется в существенно большей степени при наличии в канале 1 и 2 ретрансляторов. Полученные данные согласуются с величинами задержек, полученными в ходе экспериментальных исследований. Следовательно, протокол необходимо эксплуатировать в неперегруженном режиме, и особое внимание следует уделить проверке корректности работы механизма гарантированной доставки данных. Полученные данные для определенной максимальной скорости передачи соответствуют установленным показателям и позволяют говорить о 20%-м запасе производительности с увеличением скорости передачи. Для достижения скоростей передачи, достаточных для стандартной работы, рекомендуется использование подключения и оборудование на основе Gigabit Ethernet.

Acknowledgments. The work was supported by the Ministry of Education and Science of Russia under the contract No. 14.574.21.0126 of 27.11.2014, the unique identifier of the project RFMEFI57414X0126.