После статьи @ValdikSS о блокировке сайтов по тухлым доменам РКН мне не давала покоя мысль о том, что произойдёт, если реестр начнёт резолвится в очень большое число IPv4-адресов. Проводить полноценные "учения" мне кажется сомнительным делом, т.к. они могут случайно обернуться умышленным нарушением связности рунета. Поэтому я ограничился поиском ответов на два вопроса:
- добавляют ли провайдеры автоматически IPv4-адреса из DNS в таблицы маршрутизации?
- корректно ли обрабатывают подобные пополняющие RIB системы большие DNS-ответы, содержащие тысячи записей?
Я нагрепал и зарегистрировал несколько свободных доменов из списка, поднял DNS сервер и поставил писаться трафик в pcap... Домены для регистрации были выбраны следующим образом: два домена присутствующие в выгрузке с https-ссылками, два домена с http ссылками и два "голых" домена без ссылок. Сделано это для проверки гипотезы о равенстве всех доменов перед фильтром. IPv4 адреса, на которые указывают эти домены, были выбраны из существующих в реестре, чтоб не повышать нагрузку на фильтры. Адреса отсутствующие в реестре выделены в настоящий момент моим виртуальным машинам, поэтому DoS-атаки в данном эксперименте не содержится.
Можно пойти по открытым спискам Looking Glass разных провайдеров и посмотреть, какие из крупных около-российских провайдеров имеют на своих маршрутизаторах маршруты с маской /32 на адреса из реестра, т.к. эти провайдеры имеют риск пострадать от атаки на переполнение таблицы маршрутизации. Таких провайдеров находится не так уж мало: Эквант aka GIN aka Orange Business Services, Beeline, Ростелеком, Транстелеком, Obit и, что немного забавно, Федеральная университетская компьютерная сеть России (шутка про академическую свободу и независимость университетов).
Проверим, что IP-адрес, который мы планируем внести "под блок" не присутствуют в таблицах маршрутизации на этих же LG: 1, 2, 3, 4, 5, 6. Если кто-то будет воспроизводить этот эксперимент предельно чисто, то стоит также проверить все IPv4 и IP адреса, которые планируется добавить в таблицу. Я предполагаю, что с ними ситуация аналогичная.
14 июня в 15:00 по Москве я добавил адреса некоторых из своих серверов в файлы DNS-зон и стал наблюдать, что происходит в pcap-файлах, пока резолверы обновляли записи.
Всего в логи за 16 часов попали запросы резолверов из полутора тысяч автономных систем. В них наблюдается довольно большое разнообразие вариантов поведения с точки зрения резолва доменов.
Из сети с abuse-контактом на netup.ru резолвятся только те домены, которые в списке указаны с URLом, при этом домен с 2048 записями получает запросов примерно в 5 раз больше. AS ФГУП Электросвязь с тем же контактом исправно ходит в DNS для всех "маленьких" доменов раз в 8 минут, но почему-то не присылает ни одного запроса на "большие" домены, ровно как и ижевский РадиоЛинк. Tele2 резолвит https и "безурловый" dns, но не резолвит http, предположительно весь http там завёрнут на proxy. Железногорский Сигнал и екатеринбургский Miralogic наоборот -- резолвят только http. SPNet из Сергиевого Посада -- URLы не резолвит вообще, только "голые" домены. Московский citytelecom -- наоборот, только 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, обращаю внимание, что не все ASN принадлежат российским провайдерам.
В pcap-ах практически не обнаружено запросов с опцией EDNS Client Subnet, таких запросов меньше 1%. Это не очень удивительно, т.к. google (практически единственный "поставщик" подобных запросов) раскрывает адреса клиентов только тем DNS-серверам, которые явно анонсируют поддержку данной опции, а мой DNS-сервер этого не делал. Указанный небольшой процент запросов — это, полагаю, и есть те попытки автоматического определения поддержки EDNS Client Subnet: каждый четвёртый запрос из AS гугла приходил с этой опцией.
Помимо гугла с Client Subnet пришло 4 запроса из Бразилии с резолвера, использующего "хак" с bit 0x20:
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, анонсирующая максимальный размер DNS-пакета, который клиент готов принять. Помимо четверти запросов, которые не анонсируют поддержку EDNS и 55% запросов установивших эту опцию в 4096 байта, есть несколько других интересных значений.
2% запросов говорят, что UDP-пакеты увеличенного размера им ни к чему и используют минимальное допустимое значение 512. Примером такого резолвера может служить irc.kristel.ru из Минусинска, который изменяет эту опцию после первого "большого" ответа, который пришлось получать по 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. Конечно, отсутствие этой фичи можно объяснить тем, что если беспокоиться о скорости, то прежде всего не следует отдавать большие DNS ответы, вынуждающие резолвер переходить на TCP.
За 10 часов на вышеперечисленных looking glass не появилось /32 маршрута ни на один из "добавленных" в DNS IPv4 адресов, но через 20 часов как минимум на LG ТТК и университетской сети эти маршруты появились. Если провести измерения с помощью RIPE Atlas, то можно найти некоторое количество транзитных провайдеров, которые, вероятно, выполняют резолвинг и заносят маршруты на фильтр, получив 2049 A записей в ответ:
- ДатаЛайн – в traceroute начинает светиться filter01.dtln.ru,
- Ростелеком – в traceroute по выходу из AS8997 добавляются ростелекомовские хопы 188.254.78.25 и 95.167.93.150 на маршрутах к "заРКНеным" IP, которых не наблюдается на десятках других трейсов к соседним хостам из той же /24 сети, т.е. вряд ли это артефакт балансировки,
- ReTN – аналогичная история с удлинением маршрута на три хопа к "выделенным" хостам, о фильтре на транзите в сети ReTN на хабре уже писал @amarao.
Список неполный, т.к. был составлен методом пристального всматривания. Наличие крупных провайдеров в списке говорит о том, что вопрос о потенциальной уязвимости критической инфраструктуры к данной атаке не закрыт. Также остаются открытыми вопросы:
- как влияет на спецэффекты порядок DNS resource records в ответе? Задать его можно, например, с помощью
sortlistили непосредственно ручной генерации ответа в LUA коде - как быстро добавляется в маршруты IPv4-адрес, попавший "под резолв"?
- выполняется ли резолвинг IPv6 адресов?
- какие ещё интересные выводы можно сделать из подобных данных?
Если кто-то хочет посмотреть на данные самостоятельно, то в RIPE Atlas это измерения 8844224, 8844225, 8844226, 8844227, 8844228, 8844229, 8844230, 8844231, 8844232, 8844233, 8844234, 8844235. Запросы за первые 16 часов эксперимента доступны в виде дампа postgres:9.6. Гигабайты pcap-ов могу отгрузить по отдельному запросу.