И грянет страшный русский firewall

После статьи ValdikSS ^[1] о блокировке сайтов по тухлым доменам РКН ^[2] мне не давала покоя мысль о том, что произойдёт, если реестр начнёт резольвится в очень большое число IPv4-адресов. Проводить полноценные "учения" мне кажется сомнительным делом, т.к. они могут случайно обернуться умышленным нарушением связности рунета. Поэтому я ограничился поиском ответов на два вопроса:

• добавляют ли провайдеры автоматически IPv4-адреса из DNS в таблицы маршрутизации?
• корректно ли обрабатывают подобные пополняющие RIB системы большие DNS-ответы, содержащие тысячи записей?

Я нагрепал ^[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 принадлежат российским провайдерам.

EDNS & TFO

В 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.

DNS и маршрутизация

За 10 часов на вышеперечисленных looking glass не появилось /32 маршрута ни на один из "добавленных" в DNS IPv4 адресов. Но, если провести измерения с помощью RIPE Atlas, то можно найти некоторое количество транзитных провайдеров, которые, вероятно, выполняют резольвинг и заносят маршруты на фильтр, получив 2049 A записей в ответ:

• ДатаЛайн ^[37] – в traceroute начинает светиться filter01.dtln.ru,
• Ростелеком ^[38] – в traceroute по выходу из AS8997 добавляются ростелекомовские хопы 188.254.78.25 и 95.167.93.150 на маршрутах к "заРКНеным" IP, которых не наблюдается на десятках других трейсов к соседним хостам из той же /24 сети, т.е. вряд ли это артефакт балансировки,
• ReTN ^[39] – аналогичная история с удлинением маршрута на три хопа к "выделенным" хостам, о фильтре на транзите в сети ReTN на хабре уже писал @amarao ^[40].

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

• как влияет на спецэффекты порядок DNS resource records в ответе? Задать его можно, например, с помощью sortlist или непосредственно ручной геренации ответа в LUA коде
• как быстро добавляется в маршруты IPv4-адрес, попавший "под резолв"?
• выполняется ли резольвинг IPv6 адресов?
• какие ещё интересные выводы можно сделать из подобных данных?

Если кто-то хочет посмотреть на данные самостоятельно, то в 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]