Масштабный сбой в работе интернета в России 30 января 2024 года многие посчитали результатом учений Роскомнадзора с неназванными целями (как минимум — частичное ограничение нежелательного контента, как максимум — полная изоляция от мирового интернета). Есть ли другие причины этого сбоя?
- Введение
- Риски DNS-инцидентов
- Кибератаки путём компрометации DNS-сервиса
- Что такое DNSSEC?
- Что же произошло 30 января?
- Геополитика, Brexit, деньги...
- Новые уязвимости DNSSEC
- Подведём итоги
- Кто же управляет интернетом?
- Выводы
Введение
30 января 2024 года Роскомнадзор зафиксировал техническую проблему в работе российских DNS-серверов. Дальнейшие события развивались быстро и стихийно: пользователи стали сообщать, что их обращения к сайтам в зоне «.RU» уходят в тайм-аут. Работа с рунетом для них остановилась или стала весьма затруднительной.
Многие стали высказывать мнение, что произошёл технический сбой после тестового отключения российского интернета (или его части). Эта версия подкреплялась многочисленными слухами о готовящихся учениях по ограничению доступа к запрещённым сайтам. Однако одновременно другие пользователи в тех же регионах сообщали, что не испытывают никаких проблем с доступом в зоне «.RU». Нестыковка налицо и, по-видимому, требует обоснованного анализа с целью понять, что же реально произошло.
Официальный релиз по инциденту с разъяснением его технической части не выпускался. Минцифры подтвердило факт появления технических проблем и сообщило о запуске работ по их устранению. Сообщалось, что проблемы затронули только часть пользователей «некоторых российских провайдеров».
«РИА Новости» сообщило, что больше всего жалоб поступало от жителей Москвы и области, а также из Санкт-Петербурга, Свердловской и Новосибирской областей, Татарстана. Среди пострадавших сайтов называли «Яндекс», Ozon, Wildberries, некоторые крупные банки, такие как «Сбер» и ВТБ. Одновременно сообщалось, что пользователи Национальной системы доменных имён (НСДИ) работали штатно. Сделать на основании этого вывод о технической сути сбоя было трудно.
Рисунок 1. Сообщение «РИА Новости» об инциденте 30 января 2024 года
Позднее Роскомнадзор дал больше информации. Инцидент связали с работой DNS-серверов, находящихся в управлении АО «ЦВКС “МСК-IX”» и ООО «ТЦИ». Сообщалось, что проблемы имеют отношение к использованию протокола DNSSEC.
Столкнувшись со сбоем, многие сисадмины стали искать пути для хотя бы временного обходного манёвра. Быстро нашлось решение: после отключения запроса на цифровую подпись данных DNS доступ восстанавливался и интернет-сервис начинал работать исправно. Отметим, что за достоверность цифровой подписи, её целостность и валидацию на локальных DNS-серверах отвечает именно протокол DNSSEC.
Очень быстро, уже к позднему вечеру (22 часа по Москве), проблема была устранена. Роскомнадзор заявил о полном восстановлении работоспособности DNS в ЦОДе «МСК-IX».
Рисунок 2. Сообщение Роскомнадзора по инциденту 30 января 2024 года
Формально инцидент был, кажется, исчерпан. Но что же это было на самом деле? Возможно ли повторение случившегося? Что делать, если всё повторится?
При чём здесь протокол DNSSEC? Можно ли его отключать в таких ситуациях, чтобы не пострадала система безопасности компании? Эти и другие вопросы повисли в воздухе.
Риски DNS-инцидентов
Все более-менее знакомые с работой интернета знают, что DNS — это просто сервис, переводящий удобочитаемые адреса в форму, которой пользуются на техническом уровне. Но тема безопасности и рисков в этой области часто остаётся без внимания, поэтому начать стоит именно с неё.
Защита системы доменных имён (DNS) позволяет осуществлять фильтрацию нежелательного трафика и добавлять в чёрный список подозрительные (запрещённые) адреса (URL). Благодаря этому создаётся дополнительный слой безопасности между пользователями и интернетом. Особенно полезно это при организации работы дистанционных сотрудников.
В чём состоит опасность DNS-атак? Если хакерам удастся подменить в DNS-таблицах настоящий адрес веб-сайта на мошеннический, то после этого пользователь будет попадать на него взамен искомого, даже не подозревая, что произошла подмена. Это — большой соблазн для преступника и большой риск для безопасности. Типовая тактика мошенников при такой атаке — это фишинг, т. е. кража передаваемых данных. Такое несанкционированное внедрение в сеть создаёт также открытый канал, который позволяет, например, заразить компьютер жертвы.
Чтобы осуществить подобное, достаточно сначала реализовать, например, атаку с посредником (MitM) и перехватить передаваемые данные. Единственная защита в такой ситуации — проводить дополнительную проверку цифровой подписи, которую пересылает DNS-сервер. Эта информация встраивается в отправляемые пакеты, злоумышленник её видит, но не знает, как подменить, чтобы самому остаться невидимым. Благодаря этому пользователи могут проверить валидность источника для любой полученной записи DNS-таблицы.
Другой вариант кибератаки — это поиск веб-сайтов, не защищённых контролем достоверности в таблице DNS. Если применялась типовая веб-разработка, где не предполагалось выявление возможных уязвимостей, то найдя брешь в системе безопасности, злоумышленники могут затем перенаправлять запросы на собственную систему обработки или даже захватить доменное имя и использовать его для собственной выгоды.
Таким образом, контроль DNS является важной частью системы безопасности компании. Через него реализовываются различные виды защиты: фильтрация контента, внесение принудительных изменений при обнаружении опечаток в доменных именах и пр.
Кибератаки путём компрометации DNS-сервиса
Мы ещё вернёмся к инциденту 30 января, но пока продолжим рассказ о проблемах и о кибератаках, которые могут осуществляться через механизм DNS. В дальнейшем мы постараемся объяснить, почему, по нашему мнению, произошёл этот инцидент. Сейчас же мы стараемся показать, что необходимость экстренного выполнения работ, которые привели к его возникновению, была обоснованной.
Итак, вернёмся к DNS и назовём виды кибератак, которые могут быть реализованы через компрометацию DNS-таблиц. Выделяют следующие направления:
— Компрометация данных в самой DNS-таблице или в её кеше. Это может быть подмена действующего IP-адреса в кеше DNS-сервера с целью перенаправления трафика на вредоносный веб-сайт. В результате выполняется установка закладок или проникновение вредоносных программ с последующим хищением учётных и персональных данных.
— Туннелирование через DNS. В этих кибератаках используются дополнительные протоколы, что позволяет туннельно передавать через DNS различные запросы и получать ответы — например, для передачи вредоносных программ или украденной информации в обход большинства межсетевых экранов.
— Перехват управления DNS. В этом случае злоумышленник перенаправляет запросы на другой сервер доменных имён. Добиться такого результата можно с помощью вредоносных программ либо путём внесения несанкционированных изменений в настройки DNS-сервера.
Рисунок 3. Схема кибератаки «Перехват управления DNS»
— NXDOMAIN-атаки. Ошибка «NXDOMAIN» передаётся в ответе DNS-сервера, сообщающем о выявлении несуществующего домена. Злоумышленник может наводнить DNS-сервер запросами по доменным именам, которых не существует, и попытаться тем самым вызвать отказ в обслуживании. Для реализации таких атак используются программы, которые автоматически генерируют уникальные имена доменов для каждого запроса.
— Кибератака через фантомные домены. Злоумышленник устанавливает группу «фантомных» доменных серверов, которые отвечают на запросы слишком медленно либо вообще не отвечают. Когда на узел разрешения (резолвер) начинает поступать поток запросов к этим доменам, он зависает из-за продолжительных задержек в получении ответов. Это приводит к снижению производительности и отказу в обслуживании.
— Кибератака на поддомены со случайными именами. В этом случае злоумышленник отправляет DNS-запросы для получения ссылок на несуществующие поддомены какого-либо реально существующего сайта. Цель — опять же отказ в обслуживании. Попутно может пострадать интернет-провайдер, на ресурсах которого сидит злоумышленник, из-за появления искажённых данных в кеше его DNS-резолвера.
— Кибератаки с целью блокировки легитимного домена. Эта форма атаки связана с запуском специально настроенных доменов и DNS-резолверов, через которые создаются TCP-соединения с легитимными DNS-резолверами, допускающими выполнение рекурсивных запросов. Искусственные домены играют роль замедлителей: они отправляют обратно потоки случайных пакетов, делая это с увеличенной задержкой (аналог DDoS).
Что такое DNSSEC?
Вспомним снова об инциденте 30 января. Как было сказано, его связали с поддержкой протокола DNSSEC. Теперь несколько слов о последнем.
DNSSEC был создан для расширения защитных возможностей и для решения части проблем связанных с безопасностью DNS. Его фундамент — использование цифровой подписи для передаваемых данных, которая служит подтверждением их достоверности. Другими словами, для безопасного получения запрашиваемых адресов сайтов необходимо, чтобы передаваемые данные были подписаны на каждом уровне работы механизма DNS.
DNSSEC реализовывает иерархическую схему цифровой подписи на всех уровнях DNS. Этот протокол совместим с другими мерами безопасности, такими как SSL / TLS, и служит для реализации целостной стратегии безопасности интернета.
Зачем это нужно? Дело в том, что одна из важнейших проблем безопасности DNS — это сохранение конфиденциальности. Так сложилось, что DNS-запросы не шифруются и передаются через интернет в виде открытого текста. Это означает, что любой, кто сможет перехватить DNS-запрос, получит возможность увидеть, какие веб-сайты посещает пользователь.
Так возникает потребность в использовании DNS через TLS и DNS через HTTPS, поскольку эти стандарты шифрования DNS-запросов позволяют предотвратить их прямое чтение внешними сторонами.
Протокол DNSSEC создаёт цепочку доверия от родителя к потомку вплоть до корневой зоны. Эта цепочка доверия не может быть скомпрометирована ни на каком уровне DNS, иначе запрос станет открытым для кибератаки. Например, при запросе адреса «gosuslugi.ru» корневой DNS-сервер подпишет ключ для DNS-сервера зоны «.RU», а тот, в свою очередь, подпишет ключ для DNS-сервера, который авторизован для распространения адреса «gosuslugi.ru».
Однако разработка DNSSEC велась с учётом принципа обратной совместимости: обычные запросы DNS, не требующие цифровой подписи, будут по-прежнему корректно разрешаться, хотя и без дополнительной безопасности. Другими словами, отсутствие цифровой подписи, которое может возникнуть из-за отзыва цифрового сертификата, сохранит работоспособность соответствующего сегмента интернета, хотя безопасность будет существенно снижена.
Что же произошло 30 января?
Поскольку были затронуты многочисленные сайты, то, по всей видимости, причина сбоя была связана с работой DNS верхнего уровня. Что там могло быть не так?
Версия «проверки системы блокировки мирового интернета» была, пожалуй, самой популярной. Но она плохо стыкуется с другими объективными симптомами. Например, со сбоями столкнулись только некоторые из пользователей, тогда как «мировая блокировка» наверняка будет отрабатываться либо на одном провайдере, либо сразу на всех операторах связи, но точно не на нескольких абонентах.
Попробуем поискать другие причины произошедшего.
Геополитика, Brexit, деньги...
Какие важные события или инициативы, связанные с работой DNS верхнего уровня, имели место в последние годы? Первым делом, конечно, вспоминается геополитика, которая для России сейчас тесно связана с событиями на Украине.
Напомним, что после февраля 2022 года вице-премьер-министр Украины обратился в ICANN (центральный орган, который регулирует управление национальными доменами) с просьбой ни много ни мало приостановить для России действие национальных доменов верхнего уровня. Условно говоря, Украина выступила с инициативой по блокировке мирового интернета для России. Эта история многих заставила иначе взглянуть на действия Роскомнадзора по выстраиванию «суверенного рунета».
К чести ICANN, там заявили в ответ на инициативу Украины, что не собираются делать этого, потому что такое действие не принесло бы никакой пользы даже с точки зрения логики запроса.
Хотя некоторые иностранные регистраторы доменов прекратили работу с российскими компаниями, ретранслирующими DNS-адреса верхнего уровня (ccTLD), а некоторые иностранные веб-сайты ограничили ретрансляцию на российские DNS-узлы, выдающие адреса доменов верхнего уровня (gTLD), эти действия не носили глобального характера для России.
Кто-то может возразить, сказав, что внешнее отключение интернета для отдельной страны в принципе невозможно. Однако, увы, уже есть прецеденты.
Например, после «брекзита» (выхода Великобритании из состава ЕС) британские компании потеряли право на пользование доменными именами в зоне «.EU». Причина? Для их легального использования требуется быть резидентом ЕС. Конечно, отдельные британские компании нашли обходные пути, но это стало прецедентом, которым теперь пытаются воспользоваться другие страны.
Критическая значимость ситуации состоит в том, что национальные доменные имена верхнего уровня не являются собственностью законных представителей этих стран. Те не могут «владеть» своим доменным именем, а могут только арендовать его.
До сих пор ICANN старался разумно регулировать эту сферу (в частности, для контроля цен). Но интернет-сообщество до сих пор остаётся в напряжении.
Новые уязвимости DNSSEC
Из заявления Роскомнадзора может следовать, что причиной сбоя 30 января оказалась установка обновления для протокола DNSSEC.
Что говорит в пользу этой версии? 13 февраля международный консорциум ISC (The Internet Systems Consortium) опубликовал информацию об обнаружении новой уязвимости KeyTrap. Она получила обозначение CVE-2023-50387 и рейтинг CVSS 7,5 из 10 (весьма высокий).
Уязвимость была найдена в открытой и наиболее распространённой реализации DNS-сервера BIND 9. BIND поддерживается консорциумом ISC, на нём работают 10 из 13 его корневых DNS-серверов.
Как заявил один из исследователей, обнаруживших эту проблему, «всего один плохой пакет данных может вывести из строя уязвимый DNS-сервер через компрометацию протокола DNSSEC». По мнению исследователей, обнаруженная ошибка позволяла всего одним целевым пакетом данных «исчерпать вычислительную мощность уязвимого DNS-сервера, фактически выводя его из строя, за счёт использования 20-летней ошибки в конструкции спецификации DNSSEC».
Идея потенциальной кибератаки могла состоять в тривиальном удалении DNS-резолвера, где осуществляется проверка цифровой подписи по протоколу DNSSEC, путём отправки внешней команды. После этого все пользователи, которые будут обращаться к этому сервису, получат уведомление, что запрашиваемые ими сайты отключены от сети.
Рисунок 4. Цепочка аутентификации для протокола DNSSEC
Подведём итоги
Итак, давайте подведём итоги в отношении того, что же реально могло произойти 30 января. Какие версии можно выдвинуть?
Идея об установке «большого русского файрвола», пожалуй, несостоятельна. В этом случае должна была бы наблюдаться ровная статистика прекращения доступа к веб-сайтам для всех операторов. Этого не было.
Регламентные работы с цифровыми сертификатами. Как показывают диагностические средства, до сих пор доступ к отдельным DNS-службам маркируется признаком «INSECURE». Поскольку эти сервисы являются частью всемирной сети, проблема, скорее всего, будет постепенно устраняться. Поэтому, возможно, могли проводиться регламентные работы, связанные с пакетной заменой сертификатов. Такие работы могут вызывать временные проблемы вследствие не выявленных заранее ошибок либо из-за кеширования, когда в сети временно возникают несогласованные данные (из-за неправильно спланированной процедуры установки обновлений). Подобные нестыковки кратковременны и не будут носить разрушительного характера.
Рисунок 5. Доступ к отдельным DNS-службам до сих пор маркируется признаком «INSECURE»
Обновление уязвимого DNS-сервера. Очевидно, что изредка в используемом ПО могут находить ошибки и уязвимости, которые необходимо устранять. Обновление — это сложный процесс, прежде всего с точки зрения ввода в продуктив. Он выполняется пакетно на многочисленных серверах, разработчик обновления может не учесть особенности каждой версии ПО на них. Это приведёт к возникновению ошибок. Их будут оперативно исправлять, но полностью избежать их появления невозможно.
Последняя версия того, что случилось 30 января, кажется наиболее правдоподобной.
Кто же управляет интернетом?
Кажется, что проблема исчерпана. Масштабный сбой, который произошел в рунете 30 января, скорее всего, был связан с обновлением ПО для DNS-серверов. Обновление затрагивало поддержку протокола DNSSEC, поэтому в Сети оно проявилось через падение соответствующего сервиса. Необходимость проведения таких работ очевидна, о чём мы старались рассказать ранее. Эти работы проводятся с целью повышения безопасности и распространяются на сегмент распределённых систем. Поэтому «ошибку» увидели только некоторые пользователи и только на части территории России.
Трудности, с которыми пришлось столкнуться, удалось быстро устранить. Кажется, всё решено, но...
Этот сбой поднял заново вопрос о том, насколько зависимы большинство распределённых интернет-систем от набора центральных узлов — корневых DNS-серверов, используемых для инициализации всего процесса обмена данными. Эта проблема значительно шире, чем локальное отключение интернета.
Глобальная система DNS использует тринадцать корневых DNS-серверов. По сути, от живучести этих элементов зависит работоспособность всего мирового интернета.
Рисунок 6. Адреса корневых DNS-серверов, на которых держится интернет
Корневые узлы DNS управляются рядом компаний и учреждений, игравших важные роли на ранней стадии развития интернета. Кто входит в их число?
Одна из таких компаний — это VeriSign: она управляет двумя корневыми серверами. Ещё один располагается в Калифорнийском университете. Три сервера находятся в ведении оборонных организаций США. В списке управляющих также есть ряд ассоциаций интернет-индустрии, например NCC Group. Один сервер числится за ICANN.
Рисунок 7. Владельцы корневых DNS-серверов
До 2004 года все корневые серверы размещались в 13 различных местах — по одному на каждый IP-адрес. Почти все (за исключением трёх) находились в США. Позднее значительные усилия нескольких операторов корневых серверов, включая Netnod, расширили их глобальное присутствие.
Сейчас в мире насчитывается более 1300 экземпляров корневых серверов. Они располагаются на всех шести населённых континентах. Доступ к ним осуществляется с помощью 13 цифровых IP-адресов — по одному на каждую эксплуатирующую организацию, за исключением VeriSign. Большинство из них назначены нескольким серверам по всему миру, поэтому DNS-запросы на эти адреса получают быстрые ответы от локальных серверов.
Для доменов верхнего уровня DNS применяется долговременное кеширование. Это в определённой степени смягчает риск недоступности корневых серверов. Поэтому проблема компрометации или недоступности в случае кибератаки на центральные узлы DNS-системы до сих пор рассматривалась как теоретическая. Но попытки некоторых стран «вычеркнуть» из этой системы своих противников вызывают тревогу. По сути это — та же кибератака, только проводимая на организационном уровне, а не на техническом.
Как бы то ни было, Роскомнадзор старается держать ситуацию под контролем. Например, с 1 февраля в России введён запрет на оказание хостинговых услуг без регистрации в специальном реестре. Это — часть усилий по сохранению управляемости интернета в стране.
Рисунок 8. Роскомнадзор запретил оказание хостинг-услуг в России без регистрации
Выводы
Кажется, инцидент 30 января, связанный с «отключением от мирового интернета», исчерпан. Но всё ли безопасно в системе DNS? Риски кибератак на неё и через неё весьма высоки. Поэтому они должны отслеживаться постоянно, причём на всех уровнях.
