dxdt.ru: занимательный интернет-журнал

C доверенными TLS-сертификатами для IP-адресов связан интересный аспект, касающийся проверки права управления адресом. Так как через DNS проверять право управления IP-адресом нельзя, то проверка проводится путём отправки запроса и получения ответа непосредственно и только по IP-адресу, для которого запрашивается сертификат. Конечно, нельзя забывать, что в IP-сетях всегда фактический обмен данными происходит по IP-адресам. Вот только, в зависимости от схемы проверки, разными могут быть и задействованные адреса, и физические узлы, которые адресам соответствуют. Но в схеме с подтверждением IP-адреса – адрес один, по определению. При этом свойство сети таково, что по заданному IP-адресу может ответить практически любой промежуточный узел – то есть, вовсе не тот узел, которому, как ожидается, предназначен пакет с запросом. В Интернете промежуточные узлы есть почти всегда, обычно – их много.

Это означает, что пройти проверку и получить доверенный сертификат для IP-адреса может любой промежуточный узел. Пример. Пусть проверка права управления происходит по HTTP. Проверяющий сервис направляет HTTP-запрос по IP-адресу, который указан в запросе на выпуск сертификата. Но этот HTTP-запрос обрабатывается на каком-то транзитном, промежуточном узле и этот же узел отправляет нужный ответ. Откуда узел узнал нужный ответ? Ну, например, сертификат для подмены IP-адреса был запрошен этим же узлом (возможны варианты: не обязательно заказывать сертификат с того же узла, который будет делать подмену).

Тут необходимо учитывать, что сам трафик, между двумя узлами, но в обе разные стороны, может ходить разными маршрутами. Однако промежуточный узел может отправить ответы и от себя – это уже технические детали подключения. При этом промежуточный узел даже может все прочие запросы – транслировать прозрачно на сторону настоящего узла.

Таким образом, получается, это промежуточный узел прошёл проверку и получил доверенный сертификат для другого, с административной точки зрения, IP-адреса. Заметьте, что статус промежуточного узла вовсе не означает, что этот узел как-то связан с администрацией блока адресов, к которому относится “настоящий” IP (может быть связан, но это не является строгим требованием).

Естественно, нетрудно заметить, что при HTTP-проверке промежуточный узел точно так же может подтвердить право управления и для DNS-имени, перехватив HTTP. Запросы всё равно ведь отправляются по IP-сети. Так что, если промежуточный узел умеет перехватывать HTTP-трафик, адресованный IP-узлу под проверяемым DNS-именем, то схема подмены не будет отличаться. Более того, сертификат по такой схеме будет получен для доменного имени, а это означает, что перехватывать трафик в дальнейшем, используя подменный сертификат, можно уже с другими IP-адресами. Перехват же с “IP-адресным” сертификатом – потребует продолжения подмены/перехвата части IP-маршута. Другое дело, что так как для поиска IP-адреса в случае HTTP-проверки для DNS-имени УЦ должен использовать DNS, то есть слабая надежда на то, что можно воспользоваться дополнительными мерами защиты: например, CAA-записью.

А вот проверка через DNS, то есть, с размещением кода подтверждения в DNS, – отличается. Здесь перехватывать и подменять уже нужно DNS-ответы, а они, скорее всего, проходят через другие промежуточные узлы. В идеале, для доставки кодов подтверждения через DNS используется несколько совсем разных маршрутов. Более того, если используется DNSSEC, то такая подмена DNS вообще не сработает.

Поэтому “проверка по IP”, в каком-то смысле, играет по собственным правилам, иногда оказываясь довольно слабой.

Cloudflare пишут об утечке BGP-маршрутов крупного венесуэльского провайдера, случившейся в начале января этого года, непосредственно перед известной операцией США. Краткий вывод: утечки маршрутов происходят постоянно (это факт, не поспорить), поэтому единственное, на что эта утечка может косвенно указывать, так это на то, что были проблемы с сетевым оборудованием, точнее – с его настройками (тут тоже не поспорить – глобальные утечки в BGP вполне себе служат сигналами о том, что именно происходит на сетевом оборудовании провайдера, но для интерпретации сигнала – нужно знать схему сети; соответственно, если вы хорошо подготовленный атакующий, то и утечки маршрутов помогают).

Когда оценивают влияние отключения тех или иных магистральных кабелей на связность Интернета, нередко забывают о паре важных факторов: во-первых, сам момент переключения путей доставки трафика может создать дополнительные проблемы – уже и разнообразное “мигание” связности мешает нормальной работе коммутаторов/маршрутизаторов, а неожиданно большие затраты на передачу изменений маршрутов могут привести к тому, что и резервные пути окажутся недоступны; во-вторых, с резервированием в “этих интернетах” регулярно случается так, что после поступления действительно большого потока на резервные схемы – схемы эти падают, так как резервными они являлись не в “тёмном” режиме stand-by, а лишь резервировали некоторую полосу, доступную сверх типичной загрузки.

Оба этих фактора едва ли не гарантируют, что в момент каких-то пиковых изменений распространение информации о самих изменениях приводит к возникновению задержек, которые, в свою очередь, с необходимостью вызывают новые изменения, информация о которых тоже должна передаваться, что увеличивает задержки, ну и, в общем, понятно, что происходит далее. Подобные каскадные “штормы” периодически случаются более или менее “локально”, разработаны методы борьбы, но, всё же, умело нанесённый удар по кабелям может обрушить почти всё.

А так-то, да, конечно, в Интернете были задуманы механизмы самоорганизации межсетевого взаимодействия, на случай “глобальных проблем”. Вот только было это сорок лет назад, отчасти являлось прикрытием для других задач, нуждавшихся в финансировании, да и вообще предлагалось для одного конкретного и небольшого сегмента межсетевых соединений, где пытались сохранять связность – времена несколько поменялись.

Кстати, одним из весьма вероятных вариантов развития систем пропуска пользовательского трафика через (условный) Интернет является пропуск маршрутизаторами только пакетов, подписанных ключами доверенных приложений; либо это могут быть подписанные сессии – тут зависит от выбранного подхода. Интересно, что в описании европейского цифрового удостоверения личности (eID – European Digital Identity), которое недавно прошло очередной этап утверждения, можно уже увидеть что-то подобное, пусть и в общих чертах: приложение на устройствах, привязанное к оплате телекоммуникационных услуг – понятно, что задача идентификации интернет-пользователя там давно заявлена, но, развивая контекст по заданному направлению, нетрудно предположить, что соответствующие приложения появятся и у провайдеров на BRAS (это инженерное название для систем управления массовым клиентским доступом); даже есть занятная оговорка, что, мол, некоторое программное обеспечение, из реализующего работу eID, можно будет не публиковать в открытых исходниках (последний момент, конечно, не стоит переоценивать, но всё же).

Почему “спагеттизация” Интернета не относится напрямую к технологиям создания, собственно, “каналов связи”? В принципе, на уровне от “физического порта” до “физического порта” сейчас тоже присутствует виртуализация, а создание туннелей под собирательным названием “L2VPN/MPLS” – вполне себе распространённая практика. То есть, трафик и на этом уровне может ходить замысловатыми путями, тут имеется собственная маршрутизация, хитрая динамическая коммутация и прочие занимательные инструменты. Это так, однако Интернет – это IP плюс автономные системы с BGP (и плюс DNS, конечно), а также более или менее непрерывная, в смысле IP/BGP, “глобальность” (которая пока что ещё остаётся доступной на практике). “Глобальность” важна потому, что IP-сети повсеместно используются и вполне себе изолированные. Но, конечно, элементы “битвы за банхаммер” наблюдаются и на уровне “отключения канала и портов доступа”.

В качестве развития технологии ESNI, которая так и не вышла из статуса черновика (draft), сейчас разрабатывается вариант с передачей полного дополнительного сообщения ClientHello, но в зашифрованном виде. Предлагаемая сейчас схема выглядит чрезмерно сложной, в основном, из-за того, что логические составляющие вложены одна в другую, при этом есть ссылки из внутреннего сообщения на элементы внешнего. Вряд ли это удастся реализовать без множества ошибок, порождающих уязвимости. Тем не менее, само направление интересное. Вообще, в теории, большинство прикладных протоколов современной Сети можно сделать полностью зашифрованными, включая этап установления соединения. Конечно, на практике такое если и возможно, то не скоро, однако можно рассмотреть гипотетическую картину, которая возникнет, если схему всё же воплотить. Сейчас, в TLS 1.3, зашифрованы не все сообщения, но, если сравнить с предыдущими версиями, то на защищённый обмен стороны переходят гораздо раньше. Например, в случае развития TLS в выбранном направлении, первое же сообщение клиента будет передаваться полностью в зашифрованном виде.

Возникает традиционная проблема: где клиенту взять ключи? Ключи для такой схемы публикуются в DNS. При этом, использование DNSSEC – позволяет защитить данные от подмены, а доставка запросов и ответов DNS через TLS – защищает от прослушивания трафика.

То есть, опять же, на примере TLS, – клиент извлекает серверные криптографические параметры для установления соединения из DNS, генерирует нужные ключи и зашифровывает первое же сообщение, которое направляет серверу. Это сообщение может вообще не содержать фиксированных заголовков в открытом виде (кроме, понятно, относящихся к TCP/IP или UDP). Третья сторона видит только факт обмена узлов псевдослучайными данными. Более того, даже на уровне DNS – тоже видны только псевдослучайные данные, поскольку обмен защищён TLS, в том числе, на пути между рекурсивным резолвером и авторитативным сервером.

Основных проблем у такой схемы, если она внедрена повсеместно, несколько. Во-первых, сервер должен принимать и пытаться расшифровать любые входящие пакеты. Это очень затратно в вычислительном плане. Конечно, криптография сейчас довольно быстрая, но нагрузки всё равно возрастут в тысячи раз (и более). Нужно учитывать, что быстрые решения по фильтрации пакетов на уровне протоколов, доступные сейчас и работающие с данными в открытом виде, работать перестанут: для фильтрации в таком режиме окажутся доступны только параметры уровня номера порта и IP-адреса (ну, ещё ряд параметров TCP), а для обработки протоколов – придётся выгружать ключи на узлы балансировки и фильтрации. (Это можно сделать, но потребует очень больших затрат; которым, впрочем, наверняка будут рады крупнейшие производители сетевого оборудования.)

Во-вторых, каждому клиенту нужна будет некоторая точка старта – источник актуальных ключей, необходимых для того, чтобы сделать первый защищённый запрос. В принципе, эта проблема попроще: ключи могут быть встроены в дистрибутив, а для проверки целостности дистрибутива – годится уже имеющаяся сейчас инфраструктура.

В-третьих, полностью исчезнут современные возможности по приоритизации разных типов трафика силами DPI: никаких сигнатур отдельных протоколов не останется, кроме самых базовых – номеров портов и IP-адресов (ну, ещё количество потоков можно как-то измерить).

Кроме того, гораздо сложнее станет отлаживать работу сетевого ПО и обнаруживать ошибки, поскольку типы прикладного трафика полностью потеряют “различимость”. Недоступным окажется пассивное блокирование ресурсов на уровне протокола (опять же, с использованием DPI).

И тем не менее, переход на такой уровень – вполне возможен в ближайшие годы.

Немного теорий заговора. Сетевого уровня.

Маршрутизаторы – эффективное направление атак на сети, которые являются сегментами глобальной Сети. В подавляющем большинстве случаев, если “погасить” несколько умело выбранных маршрутизаторов, сеть падает полностью, несмотря на попытки резервирования, предпринятые при проектировании и построении сегмента. Хрестоматийная ситуация: резервные маршрутизаторы не справляются с изменившейся конфигурацией сети; причин может быть много разных – от возросшего трафика, до невозможности обмена управляющей информацией в результате возникших в сети “штормов”. Например, предполагается, что довольно давний случай с глобальной аварией сети в Сирии был вызван тем, что специалисты АНБ, во время операции по удалённому внедрению (обновлению?) программных закладок, случайно “уронили” ключевой маршрутизатор.

Интересно, как можно обнаруживать подобные действия?

Предположим, доверять маршрутизатору нет оснований, поэтому сразу считаем, что там есть закладки. Естественно, крайний вариант закладки – это продвинутый kill switch, срабатывающий по какой-нибудь последовательности в проходящих через маршрутизатор данных. Обнаружить его до срабатывания – чрезвычайно сложно, поэтому противодействовать не получится. Можно рассчитывать, что нет универсального “выключателя”, поэтому взамен вышедших из строя удастся быстро ввести новые маршрутизаторы. (Наличие подобного инструмента, конечно, вообще выглядит довольно фантастично. Тем не менее, совсем не рассматривать его тоже нельзя.)

С универсальным выключателем – мало что можно сделать. Но возможен более мягкий вариант: наличие несанкционированного удалённого доступа к маршрутизатору (через недокументированные возможности). Такой доступ позволяет управлять настройками и, скажем, выстраивать хитрые логические атаки. Каналы, реализующие доступ, могут быть хорошо замаскированы средствами стеганографии. Быстрый поток там не нужен, достаточно передавать несколько десятков коротких команд в минуту. Поэтому набор транспортов – радует свой широтой. Можно передавать биты “полезной нагрузки” в заголовках пакетов (TCP, IP, UDP и т.п. – выбирайте сами). Для этого нужно знать маршруты и располагать узлами, находящимися по разные стороны от контролируемого маршрутизатора: пакеты должны ходить через маршрутизатор, чтобы процессоры могли считывать недокументированные команды и отвечать на них. Естественно, можно ограничиться и отправкой пакетов только снаружи, лишь бы они достигали маршрутизатора, но вариант с трафиком, проходящим “через пару портов”, гораздо более привлекателен с точки зрения реализации недокументированных возможностей: во-первых, так проще реализовать скрытую обработку (из-за архитектуры маршрутизатора); во-вторых, больше способов отправить ответ. С ответами – вообще отдельная задача. Маршрутизатор не может просто так заменять какие-то параметры в заголовках, допустим, произвольных пакетов – велика вероятность ненамеренно испортить значимые данные, тем самым демаскировав всю операцию. Но зато специально выделенные пакеты – можно заменить (или сгенерировать) полностью, даже вместе с содержимым. Выделить пакеты для связи помогут ранее отправленные команды, сам пакет – будет передан узлом, находящимся за одним из портов, но данные в пакете заменяются маршрутизатором (пакет передаётся для того, чтобы не рисковать поднятием флагов во всяких системах учёта трафика, повсеместно внедрённых – они считают именно пакеты и иногда их длину; впрочем, перекос даже в один процент – вряд ли вызовет подозрения).

IP или, например, UDP, оказываются универсальными в силу того, что работают на общем для всех узлов IP-сети логическом уровне. При этом другие протоколы спускаются на несколько уровней ниже. Так, есть инструменты VLAN (виртуальные сети) и другие логические элементы, невидимые для IP. Связанные с ними протоколы также можно было бы использовать для передачи недокументированных сигналов. Однако из-за того, что свойства даже соседствующих сетей на соответствующих уровнях очень сильно разнятся, тут встречаются трудности. С другой стороны, можно представить ситуацию, когда использование расширений стандарта Ethernet (например) позволяет скрывать от анализаторов трафика, работающих параллельно маршрутизаторам, целый пласт ходящих по физической линии связи данных. Элементарный пример, понятный каждому: представим, что для анализа трафика используется обычный компьютер и Wireshark, но продвинутая сетевая карта – игнорирует часть пакетов, например, обнаружив в заголовке Ethernet некоторый заранее зашитый в процессор карты индекс (заметьте, что такое поведение аналогично штатной функции, позволяющей разграничивать VLAN-ы). Понятно, что Wireshark в таком случае не будет видеть часть трафика, и обнаружить, что видны не все пакеты, вряд ли получится. Конечно, пакеты могло бы прятать и ядро ОС, но аппаратная фильтрация сетевой картой – куда как более эффективна: зафиксировать передачу данных теперь можно только при помощи логического анализатора, подключенного непосредственно к проводам. А вот уже представить себе логический анализатор, который прячет сигналы, гораздо сложнее, чем только что описанную конфигурацию с продвинутой сетевой картой. Но многие ли мониторят сети при помощи логических анализаторов? (Вопрос даже не риторический, а скорее похож на шутку.)

Идея о том, что средства мониторинга сетей, которые позволяют выявить использование недокументированных возможностей, сами содержат в себе недокументированные возможности, направленные на сокрытие специального трафика, это уже добротный киберпанк, с рекурсией. Задумываться над таким следует с большой осторожностью.

Основой для объединения множества сетей в Интернет является понятие автономной системы (AS). В случае Интернета, а точнее, в случае IP, автономная система – это вовсе “не вычислительная система, способная работать автономно”, а, фактически, набор маршрутизаторов, формирующих видимую для Интернета IP-сеть, которая находится под единым управлением. В рамках этого управления определяется то, как внутри этой сети доставляются пакеты. (В терминологии IP – группа маршрутизаторов с общей собственной политикой маршрутизации). Очень важная оговорка: этот “набор маршрутизаторов” подключен к другим автономным системам. То есть, определение автономной системы (AS) обладает некоторой занятной рекурсивностью: нельзя определить понятие AS, если нет других AS. Почему? Потому что “единое управление маршрутизацией” определяется с внешней точки зрения. Грубо говоря, подключающиеся к данной AS через пограничный узел – видят внутреннюю политику маршрутизации как единую. Как ни странно, эта политика не обязана являться единой, если вы вдруг влезли внутрь AS и исследуете взаимосвязи между составляющими её узлами. Определение автономной системы – не столько техническое, сколько административное. Автономные системы в Интернете пронумерованы, и за каждой из них закреплено некоторое подмножество адресного пространства IP (так называемые IP-префиксы, обозначающие “непрерывные” блоки адресов), а смотрят они друг на друга, используя BGP.

BGP – или Border Gateway Protocol – это строго описанный формальный интерфейс, который автономные системы используют для формирования представления о маршрутах в Интернете. Фундамент BGP – обмен информацией о возможностях доставки пакетов. То есть, это внешний протокол взаимодействия между AS. Элементарную основу такого взаимодействия составляет распространение информации о желании автономных систем, являющихся соседними, доставлять пакеты в адрес того или иного IP-префикса. Под “соседними” подразумевается, что пограничные маршрутизаторы этих AS взаимодействуют непосредственно (заметьте, это не означает, что маршрутизаторы физически соединены напрямую). На логическом стыке между маршрутизаторами появляется понятие анонса: одна автономная система анонсирует префикс, а вторая – принимает или не принимает данный анонс. Отсюда же вырастают все другие конструкции, определяющие пути пакетов в глобальной Сети. Самой известной такой конструкцией является таблица Full View – глобальная сводная таблица путей (маршрутов), построенная для той или иной точки Сети.

Вот. При чём же здесь связность? Дело в том, что исследование BGP – подчеркну: внешнего протокола маршрутизации, – выливающееся, например, в анализ взаимной “видимости” AS по таблице Full View, это не более чем исследование BGP. Связность Сети – существенно сложнее. Например, распространена ситуация, когда некоторые операторы устраивают между собой широкий канал, который, между тем, никак не анонсируется наружу: в общедоступном BGP его нет, а соответствующие автономные системы, хоть и имеют прямой канал между собой, используют его только чтобы друг к другу ходить. Пример (реальный): сеть роботов поисковой системы и тот или иной крупный хостер. Хостеру нередко выгодно напрямую подключить поисковик к своим фермам, чтобы он индексировал сайты, чем платить кому-то за транзит того же трафика. Это пример лучшей реальной связности, по сравнению с глобальной картиной.

Обратный пример (не менее реальный): внутри некоторой выборки автономных систем анализ BGP обнаруживает большое количество путей и высокую степень “видимости” (когда одна AS анонсирует префиксы других AS). Вроде бы, это говорит о высокой связности. В реальности же все физические каналы между этими автономными системами, хоть и принадлежат разным операторам, но сходятся в одной общей канализации – поэтому единственный точечный удар ковшом экскаватора разом прерывает все, казавшиеся надёжными, связи. Чуть более продвинутый вариант: в BGP вовсе не видно ёмкости канала, наличие пути говорит лишь о том, что ближайшая AS готова принять пакеты для данного префикса (заметьте, эта AS вообще может задумать какую-нибудь атаку, так что вовсе не собирается доставлять пакеты в заявленном направлении). Соответственно, когда ковш экскаватора где-то уничтожает широкий канал, перераспределённый трафик успешно затапливает заявленные в BGP пути, которые ещё за сутки до этого служили основанием для демонстрации “высокой степени связности”.

При этом, сам по себе анализ BGP является очень полезным инструментом. Но его эффективность велика только при “локальном” применении, когда результат используется в разрезе информации о внутренней топологии сети, например, берётся в связке с данными мониторинга трафика (NetFlow и эквиваленты). При глобальном же использовании – нельзя забывать, что таким образом проводится лишь анализ таблиц BGP, а вовсе не оценка связности Интернета.

(На правах технократического юмора.) Если кто не знает, то “циска” – это собирательное название маршрутизаторов, произошедшее от Cisco и почти ставшее нарицательным. Известно, что если отключить достаточное число маршрутизаторов, то национальный сегмент Интернета потеряет внутреннюю связность (а не только связность с глобальной Сетью). То есть внешняя атака, отключающая “циски”, приводит к пропаданию Интернета в выбранной стране. Естественно, маршрутизаторы содержат уязвимости-закладки, некоторые из них позволяют маршрутизатор не просто отключить, а убить совсем. Идеальным решением задачи активации закладки является передача в составе трафика специального ключа.

Маршрутизаторы копируют все пакеты и обязательно анализируют часть их заголовков, а факультативно – содержимое самих пакетов. Так что обнаружив ключ активации в составе полученного пакета данных, маршрутизатор отключается. Ключ может представлять собой строку из 256 бит, соответственно подобрать его не представляется возможным. Понятно, что программная реализация проверки валидности полученного кода должна быть устроена так, что сам код на основании анализа алгоритма вычислить не удастся. Это очень важный аспект: иначе кто-то сможет получить ключ уничтожения в своё распоряжение, прикупив одну уязвимую “циску”.

Вопрос в том, как правильно встроить в трафик убивающий маршрутизаторы ключ. Ситуация тут напоминает искусственно создаваемую биологическую эпидемию.

Предположим, что пакет, содержащий “смертельный код”, отправляется внешним узлом в направлении ближайшего пограничного маршрутизатора атакуемого сегмента сети. Если маршрутизатор, получив пакет, умирает немедленно, то гарантировать можно лишь уничтожение этого самого маршрутизатора – остальные узлы-маршрутизаторы останутся работоспособными, а вот связь их с внешним сетевым миром прервётся, поэтому вырубить их извне уже не получится. Проблема.

Допустим, маршрутизатор сперва отправляет пакет далее по маршруту, и лишь потом – умирает. При такой схеме возможно вывести из строя один из маршрутов, в который входит начальный маршрутизатор, да и то – гарантировать ничего нельзя: пакет может потеряться в пути, а переслать его повторно будет уже некому. Так как маршрутов доставки пакетов обычно несколько, получаем проблему с покрытием: после того, как откажет несколько “цисок”, эпидемия затихнет, а связность сохранится.

Естественно, можно продолжать бомбардировать все доступные узлы пакетом, содержащим смертельный код, но есть и другое решение. Для качественного уничтожения связности пакеты должны пройти через каждый маршрутизатор, обеспечивающий работу национального сегмента Сети. При этом желательно, чтобы вредоносные пакеты вообще не покидали пределов сегмента. Это означает, что источником пакетов должны быть пользовательские компьютеры – тогда они заведомо охватят большое число маршрутизаторов, а распространяться эпидемия отключений начнёт с самого подходящего уровня: ведь без конечных пользователей Интернет не имеет особого смысла.

Как получить нужный эффект? Например, использовать механизм, встроенный в распространённую операционную систему. Пусть в определённый момент центральные серверы, куда эта операционная система обращается за обновлениями, отправят некий “праймер” – сигнал к атаке. После этого операционная система в любой пакет исходящего трафика встраивает убивающий маршрутизаторы код и – вуаля, сегмент посыпался, причём падают маршрутизаторы во всех возможных путях доставки пакетов к пользователям, покрытие идеальное. Естественно, операционная система пользовательских компьютеров не содержит секретного кода: он передаётся центральными серверами, в зашифрованном виде, чтобы не вызвать преждевременного срабатывания. От конечного компьютера требуется только расшифровать код и вернуть его обратно в Сеть – самая обычная операция, кстати, не вызывает подозрений, встречается во многих протоколах, так как может являться чем-то вроде проверки электронной подписи или служить частью системы аутентификации.

А после того как в национальном сегменте умерли хотя бы две трети “цисок”, на восстановление связности потребуются многие месяцы (не исключено, что и годы).

Кстати, я не так давно писал, что гипотетически возможен вариант с “внешним отключением Интернета“. Однако, насколько можно судить, сейчас в новостях речь идёт не просто об отключении Рунета, а о том, чтобы получить возможность всё же использовать Интернет, в том случае, если от него пытаются отключить внешние силы.

Вообще, разумными представляются действия, направленные на сохранение присутствия в глобальной Сети, вне зависимости от внешних попыток отключения. Действующая сейчас глобальная инфраструктура, конечно, создаёт тут весьма заметные трудности, но их можно и преодолеть. Неотключаемый (для всех) Интернет – был бы наиболее интересен. Однако, он, пока что, невозможен.

Технически, сломать национальный сегмент можно, если ломающая сторона обладает достаточными полномочиями и ресурсами. Тут сомнений быть не может. Ломать, естественно, нужно не на уровне DNS, а на уровне BGP (то есть, на уровне маршрутизации). Если у вас не работает BGP, то национальный сегмент разваливается на множество автономных систем, которые не могут обмениваться трафиком. То есть, нет даже единого интранета. Естественно, DNS при этом тоже не работает. Но локальные сети – остаются. Также, остаётся “локальный” обмен трафиком, если между несколькими автономными системами установлены прямые подключения (“пиры”). Например, у “Яндекса” есть прямые каналы к крупным российским хостингам (возможно, и к зарубежным). Эти каналы не видны для всего остального Интернета. (Не видны – в терминах BGP.)

(Очень интересно будет вспомнить, что отключение Интернета в Сирии, если верить иностранной прессе, произошло из-за ошибки сотрудников АНБ, которые удалённо ковырялись в пограничном маршрутизаторе и – сломали его. Медийное пространство хорошо выстроено, да.)

Между прочим, сильный противник в Интернете может сделать гораздо больше, чем просто устраивать банальные DDoS. Сильный противник – это игрок уровня АНБ, например. А самый действенный вариант здесь – активная атака на ключевые маршрутизаторы и на BGP.

Известно, что системное программное обеспечение маршрутизаторов содержит уязвимости. Это касается не только “домашних роутеров”, но и дорогих продуктов уровня Cisco. Эти уязвимости, вероятно, позволяют не просто остановить работу маршрутизатора, но повлиять на то, как работает большой сегмент сети, где взломанный маршрутизатор находится. Маршрутизатор позволяет делать с трафиком всё что угодно, в том числе, проводить инъекцию пакетов, заменять данные в пакетах и выполнять другие, не менее занимательные, вещи. Атаковать маршрутизатор можно удалённо, а если он удачно расположен, то послужит отличной отправной точкой для проведения других атак.

Что касается BGP (это протокол обмена информацией о сетевых маршрутах, определяющий то, как ходят пакеты в Сети): здесь поможет использование точек присутствия на основных магистралях для воздействия на BGP . При должном масштабе и информированности атакующего эта, вполне себе инфраструктурная, атака может заставить трафик в выбранном сегменте Интернета “ходить не туда”. Естественно, захваченные чужие маршрутизаторы служат идеальным базисом для BGP-атак.