2. Примеры практических расчетов

Рассмотрим возможности применения предложенной методологии для систем доменных имен DNS (англ. Domain Name System — система доменных имён) – которая представляет собой распределённу систему (в частности распределённая база данных), способную по запросу, содержащему доменное имя хоста (компьютера или другого сетевого устройства), сообщить IP адрес или (в зависимости от запроса) другую информацию [112]. DNS работает в сетях TCP/IP. Как частный случай, DNS может хранить и обрабатывать и обратные запросы, определения имени хоста по его IP адресу — IP адрес по таблице соответствия преобразуется в доменное имя, и посылается запрос на информацию типа «PTR».

К ключевым характеристикам DNS-серверов можно отнести [112]:

- распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности и (возможно) адреса корневых DNS-серверов.

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

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

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

В настоящее время, атаки на DNS-сервера можно условно разделить на две категории [112].

Первая категория – это атаки на уязвимости в DNS-серверах. С этим подвидом атак связаны следующие опасности:

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

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

Вторая категория – это DDoS-атаки, приводящие к неработоспособности DNS-сервера. При недоступности DNS-сервера пользователь не сможет попасть на нужную ему страницу, так как его браузер не сможет найти IP-адрес, соответствующий введённому адресу сайта. DDoS-атаки на DNS-сервера могут осуществляться как за счёт невысокой производительности DNS-сервера, так и за счёт недостаточной ширины канала связи. Потенциально DDoS-атаки второго вида могут иметь мощность до 70 Гбит/с при использовании техник наподобие DNS Amplification и пр.

Система доменных имен Internet — ключевая служба, на которую замыкаются адреса информационных ресурсов, а точнее их идентификаторы Uniform Resource Identifier [111]. Владельцы ресурсов предпочитают использовать домены второго уровня в рамках национальных доменов или доменов общего назначения (например, microsoft.com), а не закапываться вглубь иерархии имен. Кроме того, начиная с 90-х годов, DNS стали использовать в качестве инструмента балансировки нагрузки серверов информационных ресурсов, эксплуатируя для этого алгоритм Round Robin, который применяется серверами доменных имен при ответе на запросы клиентов. Ни первое, ни второе при проектировании системы доменных имен не предполагалось [113, 114].

В системе доменных имен установлена жесткая иерархия. Начинается она с корня. Затем следуют домены верхнего уровня (Top Level Domain, TLD), например, .com, .org, .net, .ru и т.п. Далее следуют домены второго уровня, например, nic.ru, vesti.ru и т.п. Каждый домен поддерживается авторитарным сервером домена и, как правило, не одним. При этом сервер, поддерживающий старшие имена, имеет возможность перепоручить управление младшими именами другому серверу. Такое перепоручение отражается в описании домена, управляемом сервером, и называется делегированием. Та часть дерева иерархи имен, которой управляет сервер, называется зоной. Если серверу поручено управлять корнем дерева имен, и он перепоручил все TLD другим серверам, то в его ведении остается только управление соответствиями между именами доменов и именами серверов, которым он эти домены перепоручил.

Кому поручено управление младшими именами, знает только тот сервер, который осуществляет делегирование. Поэтому, когда мы ищем что-то в домене RU, мы сначала должны узнать, кто поддерживает домен RU, а затем — кто поддерживает ту часть домена RU, которая, собственно, и интересует нас. На первый вопрос отвечает корневой сервер, который обслуживает «корень» имен DNS. Таких серверов 13 — десять в США, два в Европе и один в Японии. (До сих пор такое размещение было оправданным; действительно, согласно данным [115] около 60% клиентов корневых серверов размещены в США.) На второй вопрос ответят серверы, поддерживающие национальный домен RU. Их шесть: три размещены в России и три в Европе. Кстати, согласно статистике Фонда «Общественное мнение» [116], 19% пользователей Рунета находятся в Москве — там же, где расположены и три российских сервера зоны RU. С точки зрения использования DNS правильнее ориентироваться на данные SpyLog, которые получены на основе агрегирования статистики его счетчиков, размещенных на Web-сайтах: в апреле 2003 года в Москве находилось 43% всех городских пользователей Рунета [117].

После получения ответа с сервера, поддерживающего национальный домен, мы можем обратиться к авторитативному (authorative) серверу домена, которому принадлежит интересующее нас имя. Авторитативным этот сервер называют по той причине, что именно ему делегировано право отвечать на запросы к именам из этого домена. По правилам делегирования доменов второго уровня в RU для каждого домена таких серверов должно быть не менее двух. Вообще говоря, их может быть и больше; в [118] рекомендуется иметь три. Нарушением регламента регистрации доменов, способным повлечь временную приостановку делегирования, является ситуация, когда суммарное время отсутствия связи с сервером превышает два часа за сутки [119].

Ели домен обеспечен тремя серверами, то вероятность отказа сразу на двух серверах меньше, чем на одном, что существенно понижает риск временной потери делегирования. На самом деле, локальный кэширующий сервер доменных имен обращается к корневым серверам и авторитативным серверам домена RU только тогда, когда не может найти необходимый ему адрес в своем кэше. Вернемся к вопросу о времени отклика на запрос, а точнее к параметру RTT (Round Trip Time), который обычно и используют в качестве основы различных метрик в расчетах эффективности размещения ресурсов [115]. Как показывают исследования [110, 111], данный параметр времени отклика на запрос в ряде приложений может оказаться критически и полностью определяется задачей, которую решает пользователь. При этом обычно исследуют либо время задержки, которое начинает вызывать простои в работе системы, либо влияние времени задержки на эффективность работы в целом. Обычно время задержки загрузки Web-страницы свыше секунды вызывает дискомфорт; однако если пользователь знает, что он получит, то раздражения не вызывают и задержки до 5 секунд. После 30 секунд речь уже не может идти об интерактивной работе. В целом для работы с известным интерфейсом подходит следующая шкала: до 5 секунд — «хорошо»; до 10 секунд — «удовлетворительно»; более 10 секунд — «плохо». Однако если показывать элементы страницы по мере их получения, то шкала для времени полной загрузки страницы изменится: до 39 секунд — «хорошо»; до 56 секунд — «удовлетворительно»; более 56 секунд — «плохо». Любопытно и другое — непреодолимое желание «ускорить» процесс возникает в среднем после 8,6 секунд ожидания хоть какого-нибудь результата [110,111].

Особое внимание следует обратить на время отклика корневых DNS-серверов, как наиболее загруженные и критичные с точки зрения всей системы серверы (в частности обслуживающие национальные домены). За последнее время были проведены определенные исследования в этой области. В частности CIADA [115] изучали время отклика корневых серверов на запросы клиентов со всего земного шара. Время отклика признавалось большим, если превышало 90% точку распределения времени отклика. Типичным большим временем отклика в этом исследовании было время, превышающее полсекунды. Для России из 437 точек только 14 имели большое время отклика (3% от общего числа российских участников), что сравнимо с данными по Бразилии. Важно также, что за полгода, в течение которого проводились эти исследования, доля точек в России с большим откликом не изменилась (к примеру, в Украине она увеличилась вдвое). Также отмечена общая тенденция к сокращению времени отклика [113].

Более точные измерения проведены в работе [116]. Если в CIADA измерялось RTT от серверов к опрашивающим их хостам, то здесь использовалась программа, которая, будучи установленной в различных точках Сети и измеряла непосредственно отклик корневых серверов и серверов национальных доменов. Согласно данным [116], для США и Европы характерным временем отклика является время, меньшее 0,2 с. Здесь следует сделать оговорку. Основной объем трафика DNS приходится на корневой A-сервер; поэтому именно время отклика этого сервера и является определяющим, а оно при прямом подключении в редких случаях превышает 0,2 с. Как правило, время отклика c TLD-серверов несколько хуже, чем корневых — несколько десятых долей секунды. Например, для Парижа среднее время отклика A-сервера равно 0,18 с, а сервера национального домена FR — 0,25 с.

Следует учитывать тот факт, что серверы, поддерживающие домены второго уровня в зоне RU, как и во всем мире [118], в большинстве случаев (70%) одновременно являются и серверами, которые выполняют рекурсивные запросы. Чем ближе данный сервер расположен к корневому серверу, тем больше времени из интервала «приемлемого времени» останется на передачу полезной информации, а не на накладные расходы, к которым относится и служба DNS.

Таблица 3.1 . Рейтинг регистраторов зоны РФ

N	Регистратор	Домены	Домены (%)
1	RUCENTER-REG-RF	317297	39.38
2	REGRU-REG-RF	201181	24.97
3	R01-REG-RF	104555	12.98
4	REGTIME-REG-RF	43600	5.41
5	REGISTRATOR-REG-RF	40535	5.03
6	NAUNET-REG-RF	28068	3.48
7	NETFOX-REG-RF	17336	2.15
8	REGGI-REG-RF	15846	1.97
9	REGISTRANT-REG-RF	9768	1.21
10	SALENAMES-REG-RF	9141	1.13

Таблица 3.2 . Рейтинг регистраторов зоны RU

N	Регистратор	Домены	Домены (%)
1	RUCENTER-REG-RIPN	1332066	28.50
2	REGRU-REG-RIPN	1313858	28.11
3	R01-REG-RIPN	861507	18.43
4	REGTIME-REG-RIPN	352879	7.55
5	REGISTRATOR-REG-RIPN	225314	4.82
6	NAUNET-REG-RIPN	211970	4.53
7	SALENAMES-REG-RIPN	142408	3.05
8	REGGI-REG-RIPN	69212	1.48
9	REGISTRANT-REG-RIPN	57105	1.22
10	DOMENUS-REG-RIPN	31844	0.68

Таблица 3.1 и Таблица 3.2 представляют отсортированный по убыванию числа зарегистрированных доменов список регистраторов доменов по данным Российского центра регистрации доменных имен Ru-Center.

Для оценки времени отклика сервера доменных имен возможно использовать следующий алгоритм [119]:

- шесть раз в час, начиная с 4:00 и до 23:00 включительно, программа измерения времени отклика опрашивает серверы доменных имен в порядке уменьшения числа доменов, для которых сервер является авторитативным;

- для каждого из серверов она выбирает случайным образом домен в зоне RU, для которого данный сервер является авторитативным;

- затем запрашивается SOA-запись описания ресурса для выбранного домена с этого авторитативного сервера;

- время отклика расчитывается как разница между временем посылки запроса и временем получения отклика и кода возврата сервера.

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

Результаты всех сессий за текущие сутки, начиная с первой (4:00) и заканчивая наиболее свежей, обрабатываются и представляются в виде таблицы со следующими колонками:

- Номер п/п;

- Имя сервера доменных имен;

- Число доменов в зоне RU, для которых сервер является авторитативным;

- Исправленное среднее время отклика в миллисекундахза сутки (E[t]^*);

- Среднее время отклика в миллисекундах за сутки (E[t]);

- Максимальное время отклика в миллисекундах за сутки (MAX[t]);

- Минимальное время отклика в миллисекундах за сутки (MIN[t]);

- Среднеквадратичное отклонение времени отклика относительноисправленного среднего (SIGMA[t]^*);

- Наличие отказа в обслуживании в одном из тестов сервера в течение суток.

Исправленное среднее времени отклика сервера (E[t]^*) отличается от среднего времени отклика тем, что в нем не учитываются случайные выбросы измерений. Считается оно следующим образом: с 4 часов утра до 24 часов ночи мы проводим 120 измерений для каждого сервера. В течение часа проводится 6 измерений. При подсчете исправленного среднего за сутки из этих 6 измерений в расчет принемается только 5 - самое большое исключается. Таким образом, исправленное среднее считается не по 120 измерениям, а только по 100.

Среднее время отклика сервера (E[t]) считается, как арифметическое среднее всех измерений за сутки. Выбраковки измерений при расчете среднего времени отклика не производится.

Максимальное время отклика сервера (MAX[t]) - это макисмальное время отклика, полученное системой измерений за сутки. Максимальное время ожидания ответа от сервера системой расчета - 75 секунд. Однако, возможны небольшие задержки в работе системы расчета, которые приводят к тому, это время может быть несколько превышено в отчете.

Минимальное время отклика сервера (MIN[t]) - это минимальное время отклика сервера на запрос системы измерений за сутки. Маленькие времена отклика могут означать как хорошую работу сервера, так и быстрый отказ обслуживания. По этой причине всегда следует обращать внимание и на статистику отказов обслуживания.

Среднеквадратичное отклонение относительно исправленного среднего (стандарное отклонение, SIGMA[t]^*) считается по тому же множеству значений, что и исправленное среднее. Среднеквадратичное отклонение позволяет оценить степень стабильности работы сервера, а точнее всех условий в которых выполняются запросы (состояние маршрутов до сервера, например). Стабильной может быть не только надежная работа по обслуживанию запросов, но и стабильно быстрые или медленные отказы обслуживания.

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

Состояние "отказ обслуживания" фиксируется при измерении времени отклика серверов. Отказ обслуживания фиксируется в следующих случаях:

- превышено время ожидания (TIMEOUT = 75 секунд);

- запрос отвергнут (REFUSED);

- зафиксирована внутренняя ошибка сервера или сервер на указанном хосте не установлен (SERVFAIL);

- Обнаружено состояние некорректного делегирования (LAME DELEGATION).

Таблица 3.3. Суточное время отклика серверов (информация представлена для 10 регистраторов)

N п/п	Сервер доменных имен	Число доме- нов	Среднее испр. (E[t]*,Мс)	Среднее   (E[t] ,Мс)	Макси- мальное (МAX[t] ,Мс)	Мини- мальное (MIN[t] ,Мс)	Ст. Откло- нение SIGMA[t]	Отказы обслу- живания
1	ns2.reg.ru.	293225	14	49	1111	1	55.08	*
2	ns1.reg.ru.	293223	51	68	159	3	61.46	*
3	ns1.masterhost.ru.	174752	3	21	1848	2	0.73	*
4	ns2.masterhost.ru.	174590	3	3	8	3	0.44	*
5	ns.masterhost.ru.	171729	3	11	724	2	0.43	*
6	ns1.salenames.ru.	149846	2	202	10122	2	0.58	*
7	ns2.salenames.ru.	149846	23675	26998	70978	2	21133.83
8	ns4.nic.ru.	146160	1	6	483	1	0.49	*
9	ns8.nic.ru.	141728	47	47	48	46	0.32	*
10	ns3.nic.ru.	139362	1	11	1041	1	0.19	*

Анализ частоты отказов DNS-серверов RU-зоны в режиме штатного функционирования представлен на рис. 3.9.

Рисунок 3.9 - Ненормированная гистограмма относительных частот количества отказов DNS-серверов RU-зоны

Рисунок 3.10 - Гистограмма относительных частот количества отказов DNS-серверов RU-зоны

Анализ статистических данных позволяет сделать вывод о различной «цене» отказа того или иного DNS-сервера. Очевидно, что чем большее количество доменных имен, которые он обслуживает, тем выше интерес он представляет для злоумышленника в плане проведения Dos/Ddos- атак. Рассмотрим более детально статистику работы DNS-серверов одного из ведущих регистратор по количеству обслуживаемых доменов. На рисунке 3.11 представлена динамика регистрации доменов [131]. На верхнем графике каждому дню с начала месяца соответствует столбовая диаграмма. Она показывает прирост регистраций в зоне RU за сутки для каждого регистратора. Нижний график показывает динамику регистрации в зоне RU для каждого регистратора с начала месяца выбранного периода .

Таблица 3.4. Статистика распределения доменов по регистраторам с указанием доли юридических лиц

	Наименование регистратора	Обслуживаемые домены		Юридические лица
		количество	%	количество	%
1	RUCENTER-REG-RIPN	1336572	28.45	189759	53.91
2	REGRU-REG-RIPN	1328315	28.27	33877	9.62
3	R01-REG-RIPN	864187	18.39	63959	18.17
4	REGTIME-REG-RIPN	353757	7.53	18777	5.33
5	REGISTRATOR-REG-RIPN	225528	4.80	17955	5.10
6	NAUNET-REG-RIPN	211964	4.51	8412	2.39
7	SALENAMES-REG-RIPN	142429	3.03	26	0.01
8	REGGI-REG-RIPN	69412	1.48	2237	0.64
9	REGISTRANT-REG-RIPN	57367	1.22	4700	1.34
10	DOMENUS-REG-RIPN	31945	0.68	3410	0.97

Таблица 3.5. Статистика времени отклика и отказов обслуживания при обслуживании зоны RU регистратором RUCENTER-REG-RIPN

Параметр	Значение ns2.reg.ru	Значение ns1.reg.ru
Общее число доменов, поддерживаемых сервером в зоне RU, шт.	299674	299668
Среднее время отклика, мс	50	57
Исправленное среднее время отклика, мс	12	42
Максимальное время отклика, мс	1513	155
Минимальное время отклика, мс	1	3
Стандартное отклонение (исправленное), мс	36.65	55.85

5000000

4000000

3000000

2000000

1000000

0

Рисунок 3.12 – Общая тенденция роста общего числа поддерживаемых доменов в RU-зоне и доля регистратора RU-CENTER-REG-RIPN

Рисунки 3.13 и 3.14 [131] наглядно показывают динамику времени отклика первичного и вторичного DNS-серверов регистратора.

Исходя из таблицы 3.4 и таблицы 3.5, можно сделать прогноз, что при массированной атаке, способной привести хотя бы кратковременному увеличению времени отклика DNS-серверов ведущего регистратора это в той или иной мере затронет порядка 29% доменов российского сегмента сети интернет, более чем половина из которых представляют юридические лица.

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

Например, в августе 2013 года сеть компании ООО «Зенон Н.С.П.» подверглась массированной DDoS-атаке. Это привело к недоступности сайтов, размещенных на одном из старейших российских хостингов, а также к проблемам с внутренней IP-телефонией «Зенон Н.С.П.». Атака стала самой мощной за все время существования хостинга, начиная с 1995 года. Злоумышленники атаковали серверы DNS, обслуживающие доменные имена клиентов «Зенон Н.С.П.». Оборудование и каналы сети подверглись нагрузкам, значительно превышающим возможности оборудования. В список компаний, ставших жертвами DDоS-атаки на хостинг Zenon, попали многие популярные ресурсы крупных компаний. Динамика развития атаки показана на рис. 3.15-3.17.

120000

100000

80000

60000

40000

20000

0

Рисунок 3.17 – Динамика изменения времени отклика DNS-сервера ООО «Зенон Н.С.П.» во время осуществления DDoS-атаки

В результате данной DNS-атаки оказался недоступен условный проект А, использующий DNS-сервера ООО «Зенон Н.С.П.». Статистика отказов и успешных обращений представлена в Таблице 3.6.

Таблица 3.6. Статистика отказов и успешных обращений к серверу проекта А.

День проекта	Частота отказов	Частота успешных обращений	Исправленное среднее время отклика, мс	Максимальное время отклика, мс
1	0,04	0,96	3	10117
2	0,04	0,96	3	10
3	0,09	0,91	2	5060
4	0,06	0,94	3	10118
5	0,05	0,95	3	7
6	0,05	0,95	3	15
7	0,02	0,98	3	16
8	0,01	0,99	3	8
9	0,06	0,94	3	4
10	0,09	0,91	2	4
11	0,06	0,94	3	3
12	0,01	0,99	3	5
13	0,67	0,33	53160	99150

В данной таблице серым выделены строки дней, которым соответвует наиболее активная стадия осуществления DNS-атаки. В соответствии с выражением (3.4) попытаемся оценить живучесть ресурсов данного проекта.

Величины ущербов и пользы, получаемые в результате простоя проекта или же в ходе его успешного функционирования, соответвенно, устанавливает владелец проекта исходя из конкретных экономических соображений. Не затрагивая специфику проекта для простоты и наглядности примера, будем считать равнозначными величины получаемой пользы и ущерба в результате успешного или безуспешного обращения с единичным запросом к DNS-серверу. Учитывая частоты отказов и успешных обращений, легко получить ежедневную живучесть проекта. Она представлена в Таблице 3.7.

Таблица 3.7. Суточная живучесть компонента проекта А.

День проекта	Частота отказов	Частота успешных обращений	Суточная живучесть проекта
1	0,04	0,96	24,00
2	0,04	0,96	24,00
3	0,09	0,91	10,11
4	0,06	0,94	15,67
5	0,05	0,95	19,00
6	0,05	0,95	19,00
7	0,02	0,98	49,00
8	0,01	0,99	99,00
9	0,06	0,94	15,67
10	0,09	0,91	10,11
11	0,06	0,94	15,67
12	0,01	0,99	99,00
13	0,67	0,33	0,49

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

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