Административный апокалипсис, или Главный рубильник

Административный апокалипсис, или Главный рубильник

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

на эти вопросы дают такой общий ответ: «Интернет является распределенной системой и не управляется какой-то одной организацией, а поэтому отключить его «одним рубильником» невозможно». Но этот ответ неполон. И неверен.

В действительности существует даже несколько «главных рубильников». Например, как мы уже разобрались выше, для современного массового пользователя Интернет немыслим без DNS. DNS, конечно, распределенная система. Однако данные в ней имеют общий источник – корневые серверы. Более того, все корневые серверы получают сведения об адресации из одного источника, которым является скрытый сервер, контролируемый компанией VeriSign (см. соответствующую главу книги). Очевидно, что если отключить корневую зону DNS или изменить записи в ней, то либо глобальная доменная система имен окажется полностью недоступна, либо недоступны будут какие-то сегменты, ветви, доменного пространства. Пользователи, набирающие привычные имена доменов в адресной строке браузера, не смогут попасть на свои любимые сайты – для них Интернет будет выключен. Итак, мы довольно быстро нашли первый «главный рубильник» – он в руках тех организаций, которые контролируют корневую зону DNS.

Обмен данными в Интернете, в рамках IP-протокола, организован таким образом, что определяющее значение имеют так называемые автономные системы (упрощенно можно сказать, что это группы узлов, находящиеся под общим управлением и обменивающиеся данными в рамках общей для этой группы политики). В глобальной сети автономные системы известны по номерам, распределением которых в конечном итоге также ведает ICANN (через IANA и сообщества интернет-провайдеров). Каждый известный и достаточно крупный интернет-сервис представляет собой автономную систему (или несколько). Например, Google представлен несколькими автономными системами, не исключение и «Яндекс». Другим примером являются хостинг-провайдеры – обычно они также работают в рамках одной или нескольких собственных автономных систем. Если организация, распределяющая номера автономных систем, решит, что, скажем, у Google не должно быть номера автономной системы, и удалит этот номер из особых таблиц, определяющих маршрутизацию, то достаточно быстро сети Google окажутся недоступны в Интернете – Google погаснет. IP-адресация – это второй «главный рубильник».

Есть и рубильники поменьше, позволяющие отключить только какой-то сегмент адресного пространства, например сайты, размещенные у заданного хостинг-провайдера, или домены, размещенные в заданной доменной зоне. Конечно, не стоит делать выводы, что тот или иной «главный рубильник» будет использован. Пока что таких прецедентов не было. Тем не менее «рубильники» существуют.

Разберем ситуацию с рубильником от DNS на простых примерах. Удалить из доменной зоны можно не только домен второго уровня, но и домен первого уровня. Оба этих момента мы рассмотрели ранее. В результате все сайты в домене станут недоступны. Так как опрос DNS начинается с корневых серверов, то внесение изменений в корневую зону позволяет не только отключить любой домен первого уровня, но и, например, перенаправить трафик внутри этого домена на другие адреса. Конечно, требуется административный доступ к корневой зоне DNS.

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

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

Понятно, что на новых серверах домена верхнего уровня может быть прописана совсем другая адресация для имен уровнем ниже. Но можно и сохранить имевшуюся на момент перехвата управления адресацию. Для этого потребуется заблаговременно получить файл зоны с действующих серверов имен, содержащий все записи о доменах уровнем ниже. Разместив на новых серверах имен копию старого файла зоны, можно замаскировать перехват: для пользователей ничего не изменится. (Конечно, файл зоны может быть «засекречен», но на уровне положения операторов корня DNS такой расклад выглядит непрактичным: они могут попросить свежую копию заранее.)

Забрав управление доменом в описанном незаметном режиме, новый администратор может переадресовать только какие-то ключевые сайты, оставив основную часть адресных настроек без изменений. Этот способ особенно хорош в том случае, если новый администратор не желает, например, чтобы под удар попали лояльные к нему интернет-сервисы: ведь понятно, что если удалить домен полностью, то недоступными окажутся все ресурсы сразу; копирование установленной адресации сильно смягчает ситуацию для рядовых пользователей. (Да, администраторы не смогут менять настройки доменов и т. п., и т. д. но это не так страшно.)

Заметьте, что изменение DNS коснется и электронной почты в домене. Она начнет ходить «не туда».

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

Впрочем, описанный катастрофический сценарий скрывает в себе «второй конец палки». Развернув ключевые особенности реализации в обратную сторону, можно, например, в рамках некоторых автономных сетей, подключенных к Интернету, изменить адресацию в выбранных внешних доменах DNS. Делается это так. Предположим, нам нужно переадресовать (или заблокировать доступ) домен facebook.com. Из легитимной DNS можно легко узнать IP-адреса серверов имен (NS), которые отвечают за этот домен. Теперь «пограничный» маршрутизатор (устройство, обеспечивающее связь автономной сети с Интернетом) настраивается таким образом, что отправляет копии запросов, предназначенных NS домена facebook.com, специальным подставным компьютерам, находящимся под контролем «нужных администраторов».

Отличить запросы в трафике – задача элементарная: они фильтруются по адресам, ранее определенным с помощью DNS. Задача подставных компьютеров – ответить на запрос быстрее, чем это сделают настоящие NS. Ответ, естественно, может содержать совсем другие адреса серверов, а не те, которые назначили администраторы глобального домена facebook.com. Если подставной компьютер находится физически ближе к сети, трафик которой перенаправляется, то ответить быстрее легального NS – несложно. А в случае, если нужно более жестко переопределить адресацию, можно не опережать ответы легальных серверов имен, а просто блокировать их – сразу перенаправляя запросы на подставной сервер.

Я описывал методы DNS-инъекции в прошлом издании книги, вышедшем весной 2011 года. Эти методы, между тем, настолько хороши, что их, как стало известно в 2013 году из опубликованных секретных документов, с успехом использовало на практике Агентство национальной безопасности США (служба, занимающаяся электронной разведкой).

Понятно, конечно, что для уверенной реализации данного метода искажения DNS нужно обладать «уровнем доступа» интернет-провайдера. Аналогичный фокус можно проделать и с корневыми серверами DNS, правда, схема несколько усложняется, но зато можно переопределить сразу всю систему доменных имен. Схема применима в качестве меры борьбы против гипотетического отъема национального домена, но для успешной реализации нужно заранее взять на вооружение такие технологии, как Anycast (что, например, частично сделано в доменах RU и РФ).

Может показаться, что мы только что нашли меру противодействия контролю над DNS, позволяющую превратить грубый «главный рубильник» в мягкий колокольчик, по сигналу которого запускается механизм перехвата запросов и пользователи отдельно взятого сегмента Сети оказываются спасены. Но это не совсем так. Мера эффективна только до тех пор, пока в DNS и на клиентских компьютерах не развернута технология DNSSEC, которая начисто лишает «подмену ответа» эффективности. Про DNSSEC – чуть позже в этой главе, а пока вернемся к менее масштабным вопросам администрирования доменов.