- PVSM.RU - https://www.pvsm.ru -
После статьи ValdikSS [1] о блокировке сайтов по тухлым доменам РКН [2] мне не давала покоя мысль о том, что произойдёт, если реестр начнёт резольвится в очень большое число IPv4-адресов. Проводить полноценные "учения" мне кажется сомнительным делом, т.к. они могут случайно обернуться умышленным нарушением связности рунета. Поэтому я ограничился поиском ответов на два вопроса:
Я нагрепал [3] и зарегистрировал несколько свободных доменов из списка [4], поднял DNS сервер и поставил писаться трафик в pcap...
Домены для регистрации были выбраны следующим образом: два домена присутствующие в выгрузке с https-ссылками, два домена с http ссылками и два "голых" домена без ссылок. Сделано это для проверки гипотезы о равенстве всех доменов перед фильтром. IPv4 адреса, на которые указывают эти домены, были выбраны из существующих в реестре, чтоб не повышать нагрузку на фильтры. Адреса отсутствующие в реестре выделены в настоящий момент моим виртуальным машинам, поэтому DoS-атаки в данном эксперименте не содержится.
Можно пойти по открытым [5] спискам [6] Looking Glass [7] разных провайдеров и посмотреть, какие из крупных около-российских провайдеров имеют на своих маршрутизаторах маршруты с маской /32 на адреса из реестра, т.к. эти провайдеры имеют риск пострадать от атаки на переполнение таблицы маршрутизации. Таких провайдеров находится не так уж мало: Эквант aka GIN aka Orange Business Services [8], Beeline [9], Ростелеком [10], Транстелеком [11], Obit [12] и, что немного забавно, Федеральная университетская компьютерная сеть России [13] (шутка про академическую свободу и независимость университетов).
Проверим, что IP-адрес, который мы планируем внести "под блок" не присутствуют в таблицах маршрутизации на этих же LG: 1 [14], 2 [15], 3 [16], 4 [17], 5 [18], 6 [19]. Если кто-то будет воспроизводить этот эксперимент предельно чисто, то стоит также проверить все IPv4 и IP адреса, которые планируется добавить в таблицу. Я предполагаю, что с ними ситуация аналогичная.
14 июня в 15:00 по Москве я добавил адреса некоторых из своих серверов в файлы DNS-зон [20] и стал наблюдать, что происходит в pcap-файлах, пока резольверы обновляли записи.
Всего в логи за 16 часов попали запросы резольверов из полутора тысяч автономных систем. В них наблюдается довольно большое разнообразие вариантов поведения с точки зрения резолва доменов.
Из сети с abuse-контактом на netup.ru [21] резольвятся только те домены, которые в списке указаны с URLом, при этом домен с 2048 записями получает запросов примерно в 5 раз больше. AS ФГУП Электросвязь [22] с тем же контактом исправно ходит в DNS для всех "маленьких" доменов раз в 8 минут, но почему-то не присылает ни одного запроса на "большие" домены, ровно как и ижевский РадиоЛинк [23]. Tele2 [24] резольвит https и "безурловый" dns, но не резольвит http, предположительно весь http там завёрнут на proxy. Железногорский Сигнал [25] и екатеринбургский Miralogic [26] наоборот — резольвят только http. SPNet из Сергиевого Посада [27] — URLы не резольвит вообще, только "голые" домены. Московский citytelecom [28] — наоборот, только https и, как ФГУП Электросвязь, даже не пытается порезольвить "большие" домены, что позволяет предположить наличие альтернативного способа распространения чёрных списков с пред-резолвленными адресами.
| HTTPS | HTTP | Domain-only
asn | tiny | 2k/udp | 2k/tcp | tiny | 2k/udp | 2k/tcp | tiny | 2k/udp | 2k/tcp
------+------+--------+--------+------+--------+--------+------+--------+-------
50317 | 903 | 1416 | 1030 | 285 | 1295 | 1012 | 0 | 0 | 0
57835 | 207 | 0 | 0 | 200 | 0 | 0 | 200 | 0 | 0
38959 | 29 | 0 | 0 | 56 | 0 | 0 | 39 | 0 | 0
39475 | 155 | 217 | 217 | 0 | 0 | 0 | 151 | 209 | 209
42514 | 0 | 0 | 0 | 120 | 136 | 13 | 0 | 0 | 0
12668 | 0 | 0 | 0 | 95 | 103 | 18 | 0 | 0 | 0
43826 | 0 | 0 | 0 | 0 | 0 | 0 | 13 | 33 | 12
56705 | 415 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
Полное содержание статистики числа запросов за первые 16 часов можно увидеть в gist [29], обращаю внимание, что не все ASN принадлежат российским провайдерам.
В pcap-ах практически не обнаружено запросов с опцией EDNS Client Subnet [30], таких запросов меньше 1%. Это не очень удивительно, т.к. google (практически единственный "поставщик" подобных запросов) раскрывает адреса клиентов только тем DNS-серверам, которые явно анонсируют поддержку данной опции [31], а мой DNS-сервер этого не делал. Указанный небольшой процент запросов — это, полагаю, и есть те попытки автоматического определения поддержки EDNS Client Subnet: каждый четвёртый запрос из AS гугла [32] приходил с этой опцией.
Помимо гугла с Client Subnet пришло 4 запроса из Бразилии с резольвера, использующего "хак" с bit 0x20 [33]:
ts | src | query | client4
---------------------------+---------------+----------------------+--------------
2017-06-14 04:47:41.231796 | 187.1.128.119 | udp A zenitbET66.CoM | 200.248.248.0
2017-06-14 04:47:41.748585 | 187.1.128.119 | tcp A ZenItbET66.cOm | 200.248.248.0
2017-06-14 04:47:42.274296 | 187.1.128.119 | udp A zEnItbET66.coM | 200.248.248.0
2017-06-14 04:47:42.798544 | 187.1.128.119 | tcp A zeNitBET66.com | 200.248.248.0
Хак с битом 0x20 относительно популярен – с ним приходит порядка 5% запросов от 2.5% резольверов (если считать уникальные резольверы по ASN).
Другой интересной опцией EDNS является EDNS UDP payload size [34], анонсирующая максимальный размер DNS-пакета, который клиент готов принять. Помимо четверти запросов, которые не анонсируют поддержку EDNS и 55% запросов установивших эту опцию в 4096 байта, есть несколько других интересных значений.
2% запросов говорят, что UDP-пакеты увеличенного размера им ни к чему и используют минимальное допустимое значение 512. Примером такого резольвера может служить irc.kristel.ru из Минусинска [35], который изменяет эту опцию после первого "большого" ответа, который пришлось получать по TCP. Аналогичное поведение наблюдается и на некоторых других резольверах, включая сброс размера обратно в 512 байт через некоторое время.
ts | proto | qtype | qname | udpsz
---------------------------+-------+-------+--------------------+------
2017-06-14 12:41:59.678401 | udp | A | zenitbet66.com | 512
2017-06-14 12:41:59.898596 | tcp | A | zenitbet66.com | 512
2017-06-14 12:42:32.14485 | udp | A | m.zenitbet66.com | 4096
2017-06-14 12:44:40.532815 | udp | A | www.kisa54.com | 4096
2017-06-14 12:56:54.083849 | udp | A | diplom-lipetsk.com | 4096
2017-06-14 12:56:54.311013 | tcp | A | diplom-lipetsk.com | 4096
2017-06-14 13:06:38.524876 | udp | A | www.cool-sino.com | 4096
Также в логи попали пара сканеров, которые могли искать DNS amplification, т.к. выставили клиентский размер в 65527 байта, что является максимальным значением. Интересно, что "большие" ответы powerdns отправляет без каких-либо ответных resource records, ставя флаг truncated в заголовке, что вынуждает резольвер перейти на TCP. Так powerdns избегает DNS amplification при работе с большими ответами по UDP.
Я был немного удивлён, что ни одного DNS-запроса по TCP не пришло с использованием TCP Fast Open [36]. Конечно, отсутствие этой фичи можно объяснить тем, что если беспокоиться о скорости, то прежде всего не следует отдавать большие DNS ответы, вынуждающие резольвер переходить на TCP.
За 10 часов на вышеперечисленных looking glass не появилось /32 маршрута ни на один из "добавленных" в DNS IPv4 адресов. Но, если провести измерения с помощью RIPE Atlas, то можно найти некоторое количество транзитных провайдеров, которые, вероятно, выполняют резольвинг и заносят маршруты на фильтр, получив 2049 A
записей в ответ:
Список неполный, т.к. был составлен методом пристального всматривания. Наличие крупных провайдеров в списке говорит о том, что вопрос о потенциальной уязвимости критической инфраструктуры к данной атаке не закрыт. Также остаются открытыми вопросы:
sortlist
или непосредственно ручной геренации ответа в LUA кодеЕсли кто-то хочет посмотреть на данные самостоятельно, то в RIPE Atlas это измерения 8844224 [41], 8844225 [42], 8844226 [43], 8844227 [44], 8844228 [45], 8844229 [46], 8844230 [47], 8844231 [48], 8844232 [49], 8844233 [50], 8844234 [51], 8844235 [52]. Запросы за первые 16 часов эксперимента доступны в виде дампа postgres:9.6 [53]. Гигабайты pcap-ов могу отгрузить по отдельному запросу.
Автор: darkk
Источник [54]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/setevy-e-tehnologii/257895
Ссылки в тексте:
[1] ValdikSS: https://habrahabr.ru/users/valdikss/
[2] о блокировке сайтов по тухлым доменам РКН: https://geektimes.ru/post/289947/
[3] нагрепал: https://github.com/darkk/where-is-resolver/tree/master/z-i
[4] списка: https://github.com/zapret-info/z-i/
[5] открытым: http://www.bgplookingglass.com/
[6] спискам: https://archive.li/BhylY
[7] Looking Glass: https://ru.wikipedia.org/wiki/Looking_Glass
[8] Эквант aka GIN aka Orange Business Services: https://archive.li/i66ic
[9] Beeline: https://archive.li/Vy5Ue
[10] Ростелеком: https://archive.li/8nK6U
[11] Транстелеком: https://archive.li/JM5If
[12] Obit: https://archive.li/x05wg
[13] Федеральная университетская компьютерная сеть России: https://archive.li/WBKUV
[14] 1: https://archive.li/m5JA9
[15] 2: https://archive.li/zUoNP
[16] 3: https://archive.li/MI30v
[17] 4: https://archive.li/n8oBQ
[18] 5: https://archive.li/AW3Ow
[19] 6: https://archive.li/cmopR
[20] файлы DNS-зон: https://github.com/darkk/where-is-resolver/commit/d22e2debc3c10812dda68f3872e3c80917fcf57c
[21] netup.ru: https://stat.ripe.net/AS50317
[22] ФГУП Электросвязь: https://stat.ripe.net/AS57835
[23] ижевский РадиоЛинк: https://stat.ripe.net/AS38959
[24] Tele2: https://stat.ripe.net/AS39475
[25] Железногорский Сигнал: https://stat.ripe.net/AS42514
[26] екатеринбургский Miralogic: https://stat.ripe.net/AS12668
[27] SPNet из Сергиевого Посада: https://stat.ripe.net/AS43826
[28] Московский citytelecom: https://stat.ripe.net/AS56705
[29] gist: https://gist.github.com/darkk/e9c96ca11282493b03fe964b94a6fd59
[30] EDNS Client Subnet: http://www.afasterinternet.com/howitworks.htm
[31] анонсируют поддержку данной опции: https://groups.google.com/forum/#!topic/public-dns-announce/67oxFjSLeUM
[32] AS гугла: https://stat.ripe.net/AS15169
[33] bit 0x20: https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
[34] EDNS UDP payload size: https://tools.ietf.org/html/rfc6891#section-6.2.3
[35] Минусинска: https://stat.ripe.net/213.110.250.58
[36] TCP Fast Open: https://en.wikipedia.org/wiki/TCP_Fast_Open
[37] ДатаЛайн: http://AS49063
[38] Ростелеком: http://AS8997
[39] ReTN: http://AS9002
[40] уже писал @amarao: https://habrahabr.ru/post/192046/
[41] 8844224: https://atlas.ripe.net/measurements/8844224/
[42] 8844225: https://atlas.ripe.net/measurements/8844225/
[43] 8844226: https://atlas.ripe.net/measurements/8844226/
[44] 8844227: https://atlas.ripe.net/measurements/8844227/
[45] 8844228: https://atlas.ripe.net/measurements/8844228/
[46] 8844229: https://atlas.ripe.net/measurements/8844229/
[47] 8844230: https://atlas.ripe.net/measurements/8844230/
[48] 8844231: https://atlas.ripe.net/measurements/8844231/
[49] 8844232: https://atlas.ripe.net/measurements/8844232/
[50] 8844233: https://atlas.ripe.net/measurements/8844233/
[51] 8844234: https://atlas.ripe.net/measurements/8844234/
[52] 8844235: https://atlas.ripe.net/measurements/8844235/
[53] дампа postgres:9.6: http://darkk.net.ru/garbage/pg_dnsq_2017-06-14T02:54:14_2017-06-14T18:51:59.sql.bz2
[54] Источник: https://habrahabr.ru/post/330934/
Нажмите здесь для печати.