После статьи 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 принадлежат российским провайдерам.
EDNS & TFO
В 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.
DNS и маршрутизация
За 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-ов могу отгрузить по отдельному запросу.
Комментарии (55)
hurtavy
15.06.2017 07:51+11Как утверждает Роскомнадзор, во всём виноват Навальный
White_Scorpion
15.06.2017 10:19+6Хых, не умеют российские спецслужбы работать "правильно и тонко". Вон Ассанж выделился с Wiwkileaks и мгновенно получил обвинение… в изнасиловании… от Швеции!!!
Что-вы — никакого загнобления свободы слова… "Онижедемократия". Обычная криминальная бытовуха.
SBKarr
15.06.2017 09:30+1Я как-то в этом деле не силён, какие последствия ждут при переполнении таблиц маршрутизации?
P.S. Запомните, слово сол пишется с мягким знаком, а слово тарелька — без мягкого знака.mtt
15.06.2017 10:33+2Теоретически, любой из заблокированных доменов может отдавать на каждый dns запрос любые ip адреса в случайном порядке. Пара сотен таких доменов могут заблокировать все пространство ipv4 за несколько месяцев
darkk
15.06.2017 10:44+12какие последствия
При переполнении TCAM маршрутизатор может начать обрабатывать трафик не на data plane, а на control plane. Это может привести к 100%ной загрузке CPU маршрутизатора и потери части трафика (возможно, большой). Перегрузка CPU теоретически может привести к проблемам с пирингом и выпадением этого маршрутизатора из сети. Учитывая, что магистральные провайдеры как РЕТН обрабатывают большую часть трафика, трафик пойдёт другим маршрутом: либо через другой маршрутизатор (перегрузив, возможно, и его), либо через другого провайдера (где каналы тоже не бесконечны). Что может теоретически привести к каскадному распространению аварии. Т.е., грубо говоря, в России внезапно выключится Интернет.
Я не знаю цифр про запас по объему таблиц маршрутизации, про запас по каналам, есть ли автоматически включаемый fallback вида "при отказе фильтра пустить всё напрямую", поэтому сценарий "грянет" считаю гипотетически возможным. Статью написал для того, чтоб обратить внимание на потенциальную мину в "критической инфраструктуре", подложенную РКН :-)
khanid
15.06.2017 12:22Классическое "Если что-то может пойти не так, оно пойдёт не так".
Если оставить всё, как сейчас, то это тупо вопрос времени, как и в случае с уже произошедшим инцидентом.darkk
15.06.2017 16:38+1Да, примерно о том и речь.
Стоит отметить, что я сварщик не настоящий, и не очень глубоко разбираюсь в том, как обрабатывается трафик у магистральных провайдеров и как себя ведёт "большое" операторское железо при подобной перегрузке.
Alexsey
15.06.2017 16:57+2как себя ведёт «большое» операторское железо при подобной перегрузке.
Я так думаю что так же как и «маленькое». Например в 2014 году в Америке многие провайдеры просто слегли из-за того что у старого оборудования произошло переполнение BGP таблицы.
fhsnees
15.06.2017 10:49+2Не надо искать черную кошку в темной комнате.
Предполагаю, что 99% запросов — запросы от АП Ревизор, установленных у каждого оператора связи
(для проверки — сделайте выборку по user agent в запросах)
Сейчас Ревизоры заняты проверкой белых списков, на блокировки внимания на обращают.
После 16.06 счетчики с запросами на ресурсы из реестра запрещенны сайтов закрутятся снова.darkk
15.06.2017 10:51+1user agent в запросах
Какая-то часть запросов наверняка от Ревизоров, да. Если кто-то хочет погрепать логи, могу отгрузить access.log чтоб посмотреть на HTTP трафик приходящий параллельно с DNS. А про какой user-agent в DNS-запросах речь? :)
fhsnees
15.06.2017 12:10user-agent — естественно из http/https запросов. Грепните со счетчиком по user-агент полю.
DNS-запросы в основной массе будут приходить от NS-серверов операторов связи, которых запрашивают те же Ревизоры.
avost
15.06.2017 11:33+1А вы смелый человек, раз проделываете такое внутри российской "юрисдикции". Роскомпозор уже начал охоту на ведьм — поиски стрелочников, на которых можно повесить свои косяки (и, например, убытки банков). На данный момент они решили, что это те, кто купил освободившиеся заблокированные домены… Такие исследования и публикации надо делать из под трёх слоёв анонимности. Один мой знакомый попадал под похищение ментами с рабочего места, увоз в наручниках и содержание под арестом в другом городе за куда меньшее "преступление" — обсуждение на форуме потенциальной уязвимости "золотой короны". Да минует вас чаша сия.
vlreshet
15.06.2017 16:21+1Ваш друг обсуждал такие вещи под настоящим никнеймом и с домашнего IP?
avost
15.06.2017 19:40+5Ну, это было довольно давно. Товарищ не был ни каким хацкером, наоборот, был очень увлечён системами банковской безопасности и, по-моему, как раз в одном банке по безопасности работал. Профвопросы обсуждались на каком-то профессиональном форуме. Ну, вот и всплыла тема теоретической уязвимости. А через некоторое время совсем в другом городе корону, вроде, грабанули. Ну, конечно же, двадцатилетний парень внезапно "оказался" организатором банды (вспоминаем Дмитрия Богатова, держателя торовской экзит ноды, внезапно оказавшегося "экстремистом"), менты приехали из другого города, заковали чувака в наручники и, не сообщая никому, увезли в неизвестном направлении. После долгих поисков родня обнаружила его в сизо в не очень соседнем городе. В общем, провёл он в застенках от полугода, изрядно попортил здоровье, на каких условиях его удалось вызволить я не в курсе, но потом он распродавал аппаратуру — биометрические сканнеры и подобное, которыми занимался. Может ушёл из темы, может срулил из дебильного госустройства.
ЗЫ. Я, в общем-то, о том же — автор статьи под своим именем в и российской юрисдикции с практически "признательнымы показаниями". Очень удобная цель для мразей из потребпозора :(
ЗЗЫ. Насколько мне изменяет память, грабанули тогда корону банальным вскрытием банкомата с помощью грузовика, но кого волнуют такие "мелочи"…puting
15.06.2017 21:26сюрреализм, ля
"правило имен" ле гуин
И ишо, чей-то из старых фантастов… про числа что-то там… типа, "науки для избранных"
darkk
15.06.2017 20:47вы смелый человек
В ответ могу лишь повторить слова президента: кому суждено быть повешенным, тот не утонет. Большей определённости от будущего ждать сложно.
из-под трёх слоёв анонимности
Надеюсь, что, в случае капитальной аварии магистральных провайдеров, инициатора будут пытаться искать компетентные органы, а не массовые преследователи "политических заключённых".
да минует вас чаша сия
Спасибо.
avost
15.06.2017 22:04+3Надеюсь, что, в случае капитальной аварии магистральных провайдеров, инициатора будут пытаться искать компетентные органы
Так подлинный инициатор и так известен, но "кто ж его посадит, он же — памятник" :(
Amoled
15.06.2017 12:02По проверке ping-admin 90% трафика к «без вины виноватым» блокируется до сих пор, не смотря на уведомление РКН.
И уведомление было только по 16-е число, если мне не изменяет память, а значит, после все уж точно вернется на круги своя.
А это в свою очередь означает, что любой сайт, если его нет в белом списке, сможет заблокировать любой школьник.
Да и сам белый список — вещь бесполезная. Всем IT-шникам хорошо известно, что любая JS'ка, любой список отзыва удостоверяющего центра, любой DNS-сервер заблокированный — и сайт уже не работает, даже если сам он в белом списке. И таких «точек отказа» сотни и тысячи. Кстати, корневые серверы зон .ru/.рф/.com в белом списке есть?
Если прочитает кто-то из РКН, то вот вам лайфхак.
Поднимите свой референтный DNS для систем фильтрации провайдеров и Ревизора, и пусть провайдеры пропишут его для резольвинга в соответствующих системах. Это позволит отказаться от белых списков и просто не резольвить домены в те IP, который считаются «белыми». Также можно будет отсечь домены с 2 тысячами A адресов. Со временем можно сделать автоматическую систему мониторинга изменений A/CNAME записей заблокированных доменов, и «подозрительные» отправлять на премодерацию оператору системы. Например если после смены IP открывается совсем другой сайт, или ничего не открывается, и т.п. В общем масса вариантов.
NoRegrets
15.06.2017 20:39Поднимите свой референтный DNS...
Зачем? Зачем, когда реестр должен сливаться каждый час? Проще в реестр пихать все адреса.
osysltd
17.06.2017 20:58Что же будет к компьютерами конечных пользователей (в целом) если CRLы Microsoft'a станут вдруг недоступны…
Cenzo
15.06.2017 12:02+3Серьезное исследование, спасибо. Система блокировки и так не выдерживает никакой критики, а уж если за неё возьмутся по-крупному, то не только простые пользователи пострадают, весь онлайн сегмент бизнса с банками и транзакциями полетит «в труху». Типичный DOS-сценарий «завали конкурента» или «посей полный хаос», по факту РКН даёт убийственный набор инструментов в руки всем желающим. Интересно, сами дойдут что это нереально или дождутся пока всё развалится само.
PS: и да, тэги улыбнули.
Ugrum
15.06.2017 13:51+3И грянет страшный русский firewall
И как всегда, бессмысленный и беспощадный…
Furriest
После субботней истерики РКН любой провайдер, занимающийся самодеятельным резолвингом, нарушает законодательство. Фильтрация должна быть только и исключительно по IP-адресам, которые занесены в официально распространяемый список.
wtigga
А что, письмо из РКН приравнено к подзаконному акту, который после прямой линии превратится в тыкву?
Furriest
Скорее наоборот, письмом из РКН разъяснено, что все их рекомендации не имеют никакого юридического статуса. Включая рекомендацию резолвить.
kemko
Зато юридическую силу имели все штрафы и предупреждения, которые РКН налагал за отсутствие резолвинга ещё месяц назад. Так что, на месте какого-нибудь провайдера, я бы ждал полных официальных разъяснений, а не отписок типа "отключите резолвинг до 16 числа, мамой клянусь не обижу".
Furriest
Вы попали под какой-то штраф или предупреждение?
mxms
Регулярно все провайдеры попадают.
Furriest
Есть ли живой пример попавшего на штрафы из-за нерезолвинга? Без обобщений про «все» (тем более, что обобщение не очень корректное, мы вот, например, именно из-за нерезолвинга не попадали).
mxms
Есть. И неоднократные. Опубликовать по этическим соображениям не могу
Lailore
И в чем этичность заключается? Сейчас это на уровне «потому что я так сказал»
mxms
В том, что информация у меня есть из первых рук, а вот распространять её детали я считаю неэтично по отношению к доверителям. Так понятнее?
Lailore
Так не распространяйте, а то у меня есть информация из первых рук что людьми правят подводные коты.
bud
Мы попали…
Mechanist
Да, я попал. Из-за HTTPS-ной доменной записи. Пока предупреждение. Но рассмотренное без нашего присутствия на суде. Получили сразу решение. Причём, самое что обидное, мы под прикрытием аплинка по договору. Но с конца прошлого года это РКН волновать перестало. Сейчас штраф до 100 тысяч за КАЖДЫЙ пропуск. Мне проще сразу для клиентов белый список сделать и пошло оно всё в лес. Или лицензию сдать и пусть РТК будет единственным и православным. Всё равно мелкий бизнес реально в вышеуказанном месте видел и сам РКН и ФСБ, собственно. А вы тут — незаконно. Смешно :(
Furriest
Именно из-за нерезолвинга https-ной записи? Т.е. она есть в листе, но под другим IP?
Сочувствую, но думаю, что если пойдете в суд — решение можно будет отменить.
По поводу прикрытия аплинком — это действительно никого не трогает, реализация фильтрации — обязанность лицензиата. Если аплинк был настолько оптимистичен, что в договоре согласился на регресс штрафов — вы можете взыскать сумму выставленного вам штрафа с него. Но это вряд ли.
Засуньте «ревизор» под отдельную машину с фильтром (тот же extfilter, как наиболее простое решение) и вероятность появления проблем упадет существенно.
c0ntr0ller
Есть сомнение в уровне компетенции суда или привлеченных экспертов. Скорее будет формулировка, аналогичная той, что услышал мой товарищ от судьи при лишении прав за якобы пересечение сплошной: «у меня нет оснований не доверять работнику ГИБДД», хотя в наличии были и свидетели и видео с регистратора. Да и вообще «идите в суд» у нас равносильно послать человека подальше, только вежливо
Zar1n
Но попытка не резольвить, закончиться административкой и штрафом. Круг замкнулся :(
Furriest
Не закончится. Опротестовывается, причем успешно.
Почему-то у всех мнение о РКН как о каком-то суперзлодее, который подмял под себя все суды и весь закон. На самом деле, работают такие же люди, так же косячат, так же какие-то суды выигрывают, какие-то проигрывают.
Понятно, что если вы будете Ходорковским, за которым лежит вкусный ЮКОС, вас засудят несмотря ни на что. Но тогда и резолвинг не спасёт :) А для абсолютного большинства операторов в РФ вопросы с РКН решаются вполне успешно. Есть опыт.
Ну и, справедливости для, кто вас заставляет «ревизоры» ставить в общую с клиентами сеть с одинаковыми правилами фильтрации? :)
Andrusha
Угу, только этих косячащих людей никто не штрафует, да и вообще по сути не контролирует. Они действительно не суперзлодеи, просто сборище малокомпетентных раздолбаев, получивших власть.
Alex_333
Согласен. У нас процесс еще идет, но по словам юристов — шансы на выигрыш достаточно велики.
c0ntr0ller
Федеральный закон от 28 декабря 2013 г. N 398-ФЗ
Ну это первое что попалось на глаза по поиску «закон о блокировке»
rajven
Смешно. Когда вам штраф придёт — попробуйте сказать, что ресолвинг незаконен. Посмеёмся. Вы прям как не в России живёте.
Furriest
Вы тоже демонизируете РКН, как я писал выше. Не знаю, сколько раз вы ходили с РКН в суд, но у нас есть множество успешных (и неуспешных, впрочем, тоже) кейсов взаимодействия с РКН в суде.
С резолвингом же есть совершенно прекрасное по формулировке официальное письмо регионального РКН «В соответствии с указаниями ЦА РКН необходимо в срочном порядке обеспечить блокирование запрещённых ресурсов в установленном законодательством порядке, без учёта последних требований „резолвинга“». Из которого вполне прозрачно (во всяком случае, наши юристы радостно захлопали), что резолвинг не входит в установленный законодательством порядок. Правом же самовольно расширять требования законодательства РКН не обладает.
rPman
РКН затраты на суд по успешным делам? или кто их оплачивает?
Furriest
Ничего необычного, решение о распределении судебных расходов, как и везде, принимает суд. Иногда принимает решение о компенсации выигравшему, иногда нет. В нашей практике сильно зависело от конкретики кейса.