Домены. Все, что нужно знать о ключевом элементе Интернета Венедюхин Александр

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

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

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

В действительности существует даже несколько «главных рубильников». Например, как мы уже разобрались выше, для современного массового пользователя Интернет немыслим без 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 – чуть позже в этой главе, а пока вернемся к менее масштабным вопросам администрирования доменов.

Безопасное администрирование

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

Что угрожает администратору домена? Самая серьезная угроза – «угон» домена, то есть неправомерный переход домена под контроль злоумышленников. Как ни странно, «угон» может быть произведен с помощью разнообразных инструментов, причем некоторые из них вовсе не требуют использования высоких интернет-технологий.

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

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

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

Что в итоге? В итоге сотрудник, получивший задачу создать корпоративный сайт и выяснивший, что для этого потребуется домен второго уровня, регистрирует подходящий домен на себя. Как показывает практика, в подавляющем большинстве случаев сотрудник вовсе не имеет злого умысла – он просто желает избежать лишней бумажной волокиты. Более того, обычно он получает одобрение руководства на такую регистрацию: «Ну ты же будешь сайтом заниматься, вот и регистрируй на себя».

Некоторое время с новоиспеченным «корпоративным» доменом все хорошо. Под ним работает корпоративный сайт, который при нынешних темпах роста Интернета вполне способен в скором времени стать важнейшей «витриной» компании. Но однажды сотрудник, зарегистрировавший домен, увольняется.

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

Администратор домена может просто не оплатить продление регистрации (действительно, зачем, если он уже не работает в компании?) – в результате домен будет освобожден, а фирма останется без корпоративного сайта.

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

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

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

Если для «угона» домена часто требуются бумажные документы, то перехватить управление можно и по «безбумажной технологии». Так, регистраторы предоставляют своим клиентам веб-интерфейс, служащий для оперативного управления доменами через Интернет с помощью веб-браузера. Обычно доступ к веб-интерфейсу производится с авторизацией пользователя по паролю (используется пара логин/пароль; логин – системное имя, присвоенное данному клиенту). Злоумышленник, которому стал известен пароль (и логин) клиента регистратора для доступа к веб-интерфейсу, получает возможность перехватить управление веб-интерфейсом. Соответственно, все операции с доменами клиента, доступные через веб-интерфейс и не требующие дополнительной авторизации, оказываются в распоряжении злоумышленника.

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

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

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

использование нескольких паролей, например технического и административного. Первый пароль может позволять лишь просматривать настройки доменов и выполнять только самые безопасные действия, а для внесения сколько-нибудь критичных изменений будет требоваться дополнительный ввод административного пароля;

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

Доменный рынок растет, а вместе с ним увеличивается и число компаний-регистраторов. Самым ожидаемым образом повышение числа регистраторов приводит к тому, что ширится и разнообразие этих регистраторов в смысле подходов к ведению бизнеса. Например, в домене RU осенью 2013 года действовало около пятнадцати заметных на рынке регистраторов. Это различные компании, отличающиеся и формой собственности, и внутренней организацией, и «деловым стилем». В дальнейшем можно ожидать еще большего роста числа регистраторов.

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

Данная проблема характерна не только для домена RU. Нельзя, конечно, делать вывод, что все новые компании обязательно ненадежны. Накладки возникают и у старейших, крупнейших регистраторов. Тем не менее проблема существует, и рост числа регистраторов ее усугубит.

Наглядным примером может служить история с американским регистратором RegisterFly, который лишился аккредитации ICANN в 2007 году. У RegisterFly, работавшего в том числе с популярными доменами COM и NET, возник внутренний производственный конфликт в совете директоров. Из-за общей неразберихи и технических проблем компания попросту перестала выполнять свои функции по управлению доменами, в результате у клиентов этого регистратора возникли не просто технические трудности: несколько тысяч из них вообще остались без доменов.

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

«Доменная наценка», очевидно, не связана напрямую с безопасностью доменов. С одной стороны, было бы странно ожидать, что надежность выполнения функций по управлению доменом клиента можно обеспечить за сумму, близкую к нулю рублей. С другой – понятно, что средства на управление доменами могут выделяться компанией-регистратором из доходов, получаемых от других видов деятельности.

Вернемся к домену RU. Как я писал в главе, посвященной национальному домену России, сумма, которую регистратор перечисляет в пользу реестра и технического центра домена RU, составляет около 70 рублей за каждую операцию регистрации домена. На эту сумму регистратор делает наценку, обеспечивая собственную прибыль. Например, домен для конечного пользователя может стоить 600, 500 или даже 200 рублей. Из чего формируется регистраторская наценка? Из расходов регистратора по сопровождению доменного имени и взаимодействию с клиентом – администратором этого имени. Понятно, что уже оформление отдельного договора с клиентом и прием от него заявки на доменное имя потребуют затрат (оплата труда сотрудника, принимающего договор, и т. д.). В наценку также включаются расходы на обеспечение надежной работы регистраторских функций компании (ведение базы данных клиентов, работа с реестром доменов, предотвращение возможных сбоев).

Обеспечить гарантии клиентам регистраторов доменов могут дополнительные меры, принимаемые на уровнях администраторов национальных доменов или даже ICANN. Наиболее очевидные из этих мер таковы:

резервирование клиентских баз данных с привлечением независимых хранителей;

обеспечение прозрачной и хорошо работающей процедуры перевода клиентов проблемных регистраторов к другим регистраторам с сохранением доменов.

Со своей стороны, администратор домена при выборе компании-регистратора должен принимать во внимание и ее надежность.

Уверенный доступ

Если под зарегистрированным доменным именем размещаются какие-то ресурсы, то домен нужно привязать к определенным серверам DNS, обеспечивающим преобразование символьных имен внутри домена в адреса компьютеров, обслуживающих ресурсы. Например, адрес www.test.ru может соответствовать компьютеру, на котором работает веб-сервер, обслуживающий сайт www. test.ru. Регистрация домена сама по себе, как формальная процедура, не связана с последующим размещением каких-либо онлайн-ресурсов. Однако если такие ресурсы появились, то для их адресации будут использованы серверы DNS, которые связаны с конкретным доменом через общую, глобальную иерархию систем адресации.

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

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

Серверы DNS доменного имени могут быть выбраны более или менее произвольно, скажем, они вовсе не обязательно должны принадлежать регистратору доменов (хотя это довольно распространенная практика). Часто услуга размещения DNS предоставляется хостинг-провайдерами.

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

Серверы DNS часто служат объектом атак со стороны хакеров. Например, могут быть организованы атаки типа «отказ в обслуживании». Отказавшие DNS-серверы не смогут обслуживать запросы, и размещенные под соответствующим доменом ресурсы будут недоступны.

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

Итак, для обеспечения надежной работы своего домена администратор должен правильно выбрать серверы DNS. Желательно использовать услуги по аренде DNS, предоставляемые крупными регистраторами или хостинг-провайдерами. Хорошей практикой является одновременное использование нескольких DNS-серверов, находящихся у разных провайдеров.

Достоверность: а туда ли я попал?

Самым большим по количеству разнообразнейших проблем является класс доверия к доменам и DNS в целом. Причина в том, что классическая DNS вообще не

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

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

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

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

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

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

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

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

Рассерженные пользователи из этой домовой сети, ничего не подозревавшие о подмене DNS, изливали гнев на интернет-форумах: «Ничего не понимаю! У них сайт не работает, ничего найти нельзя. Как же так можно! Бред! Я не стану пользоваться услугами оператора, который даже собственный сайт “из рекламы” не умеет наладить!» При этом, подчеркнем, для всего остального Интернета сайт из рекламы конкурента домовой сети хорошо работал и внятно доносил до своих посетителей информацию об услугах. Эти посетители из других уголков Интернета долго вообще не могли понять, что имеют в виду их обозленные «коллеги» по общению на форумах. «Да как же? Вот же ссылка – все об услугах написано!» – возражали они, так как в их браузерах открывался совсем другой сайт, хоть и под тем же доменным именем. Обманутые же с помощью DNS клиенты домовой сети «попадали не туда», совершенно об этом не подозревая.

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

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

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

При этом действенных мер, позволяющих бороться с подделкой ответов DNS о сайтах, пока не выработано. Хотя проблема специалистам понятна, и способы ее решения ищутся. Например, одним из методов противодействия подделке ответов DNS является технологическая инициатива DNSSEC (http://www.dnssec.net/), предлагающая набор мероприятий, которые позволят DNS-серверам, ответственным за тот или иной конкретный домен, подписывать ответ с помощью электронной подписи и механизма сертификации. Введение DNSSEC позволяет на стороне операционной системы компьютера конечного пользователя проверять корректность полученных от локального DNS-сервера ответов об адресах сайтов.

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

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

Впрочем, неверная реализация метода из рекомендаций крупнейшим российским канальным провайдером однажды привела к блокировке «Яндекса». Ключевую роль опять сыграла DNS. Владельцы заблокированного ресурса просто взяли и перенастроили свой домен так, что он стал показывать на IP-адреса «Яндекса». Это можно сделать с любым доменом, никаких проблем тут нет. В результате в список блокировки попали адреса «Яндекса», и один из ключевых сервисов российского сегмента Интернета оказался в течение примерно часа недоступен для большой части интернет-пользователей.

Эта история показывает, что среди основных угроз существованию современного Интернета числится и блокирующая «Красная кнопка», которая однажды может попасть в неумелые руки.

Конечно, общепринятые (но не имеющие юридической силы) правила работы в Интернете запрещают провайдерам нарушать связность сети и валидность DNS.

А подделка сетевых реквизитов числится в ряду самых серьезных нарушений. Тем не менее провайдеры правила нарушают – с умыслом и без – по разным причинам: будь то цензура содержимого Сети (как в описанном выше случае с домовой сетью), системный сбой или хакерская атака. Радует только одно: такие нарушения пока не носят массового характера.

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

Заверено подписью

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

На первый взгляд может показаться, что для «подсовывания» конечному клиенту DNS дефектной информации об адресах узлов злоумышленник должен контролировать используемый атакуемым компьютером сервер DNS, ну, или по крайней мере находиться в одной сети с атакуемым компьютером. Но на практике дела обстоят гораздо хуже. Особенности реализации обмена запросами и ответами в DNS позволяют злоумышленнику атаковать даже весьма удаленные от его узла системы, и успешные атаки клиентских машин вовсе не требуют контроля над DNS-серверами. Однако в таком случае реализация атаки усложняется и требует параллельной работы нескольких «хакерских сетевых механизмов», которые, впрочем, хорошо изучены и отработаны.

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

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

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

Впрочем, это лишь одна часть проблемы. Другая часть, не менее важная, имеет отношение к политическим факторам, как и следует ожидать в Глобальной сети. Подробнее о них – чуть ниже, а сейчас остановимся на том решении проблем безопасности DNS, непосредственное внедрение которого в Глобальной сети начато в 2010 году.

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

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

Несколько десятков лет назад криптографами были разработаны методы, позволяющие создавать так называемые цифровые подписи, удостоверяющие подлинность заданного набора данных. Предположим, что у нас имеется запись о соответствии имени домена и IP-адреса. В рамках DNSSEC в строгое соответствие этой записи ставится специальная последовательность байтов, представляющая собой цифровую подпись. Главная особенность «подписывания» заключается в том, что есть простые и, самое главное, публично доступные (открытые) методы проверки достоверности подписи, а вот генерирование подписи для произвольных данных требует наличия секретного ключа в распоряжении подписывающего. То есть проверить подпись может каждый участник системы, а подписать что-либо, используя доступные вычислительные ресурсы и за разумное время (это очень важное дополнение), – только обладатель секретного ключа. На первый взгляд, это может показаться парадоксальным. Тем не менее именно так работают асимметричные системы шифрования с открытым ключом, лежащие в основе алгоритмов цифровой подписи.

Попробуем разобраться на очень простом примере. Следует иметь в виду, что этот пример лишь похож на операции в рамках DNSSEC, а не описывает их в деталях. Предположим, администратор зоны fort.test.ru хочет удостоверить с помощью цифровой подписи данные об адресации, хранящиеся на его DNS-сервере. У администратора есть пара ключей: секретный и открытый (публичный). Используя секретный ключ и данные об адресации (можно считать, что эти данные представляют собой простой компьютерный файл) в качестве исходных данных, администратор генерирует новый файл, содержащий цифровую подпись, соответствующую секретному ключу и исходным данным. Получив значение цифровой подписи (а она представима в виде набора байтов), администратор размещает эту подпись в публичном доступе вместе с адресной информацией.

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

Теперь для других участников, использующих DNSSEC, доступна информация об адресации и связанная с этой информацией цифровая подпись. Для проверки подписи используется открытый ключ из пары, принадлежащей администратору, который также опубликован. Для проверки, которая выполняется по специальному, известному всем участникам DNSSEC алгоритму, используются файл данных об адресации, файл с соответствующей цифровой подписью и открытый ключ. Заметьте, что открытый ключ дает возможность проверять достоверность подписи, но не позволяет за разумное время вычислять новые подписи для измененных данных. Важная особенность цифровой подписи в том, что при изменении подписываемых данных изменяется и сама подпись, поэтому просто скопировать подпись от одних данных и «прицепить» ее к другим не получится.

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

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

Так и есть: одними подписями обойтись не удается. Требуется механизм, позволяющий удостоверять полномочия источников этих подписей. В DNSSEC для создания этого механизма должна использоваться естественная иерархия прав, уже существующая в доменной системе имен. То есть на базе системы делегирования прав администраторам доменов, о которой подробно рассказано несколькими главами выше, создается механизм подписывания ключей. Так, достоверность источника ключа для какого-либо домена удостоверяется с помощью цифровой подписи, исходящей от вышестоящего «удостоверяющего центра», подпись этого центра удостоверяет другой, стоящий еще выше в иерархии, а в итоге образующаяся «цепочка доверия» сводится с корневому домену и корневому ключу. Этот ключ должен быть распространен по всем участникам DNSSEC независимо от DNS. Например, он может быть встроен в операционные системы. Корневой ключ – главный ключ всей системы, позволяющий проверить достоверность любой подписи на всех прочих уровнях, – принадлежит той организации, которая отвечает за достоверность DNS в целом, и поэтому, строго говоря, этот ключ не может являться частью DNS.

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

DNSSEC уже внедрена во многих доменах первого уровня. Есть немало доменов уровнем ниже, внутри которых также используется DNSSEC. Однако совершенно преждевременным было бы говорить, что DNSSEC развернута, до тех пор пока не «подписаны» корневые серверы имен, соответствующие корневому домену. (Как я рассказывал ранее, таких серверов 13, и в настоящий момент они в административном плане контролируются ICANN.)

Именно с «подписыванием» корневых серверов были связаны политические проблемы в управлении Глобальной сетью. Они сводятся к довольно простому вопросу: у кого ключ?

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

До внедрения DNSSEC контроль над верхушкой иерархии DNS был более размазан. Да, фундаментальные решения принимала ICANN после согласования с соответствующими подразделениями Минторга США. Техническую сторону обеспечивают технические службы (например, корпорация VeriSign или такая организация, как IANA). При этом сами 13 корневых серверов вовсе не являются тринадцатью физическими компьютерами, а представляют собой большое количество сложных многокомпьютерных систем, разбросанных по дата-центрам разных стран. Понятно, что в управлении этими базовыми узлами DNS так или иначе задействовано большое количество различных телекоммуникационных компаний.

После того как состоялось подписание корневых серверов, управление DNS получило еще одну строгую криптографическую процедуру, однозначно привязанную к корневому ключу. Корневую зону DNS окончательно подписали в ночь с 15 на 16 июля 2010 года. Конечно, после завершения многомесячной и довольно сложной процедуры поэтапного развертывания технологии на корневых серверах. Открытые ключи для проверки подписей DNSSEC опубликованы на сайте IANA (https:// data.iana.org/root-anchors/). Таким образом, несмотря на существенные административные сложности, Минторг США, компания VeriSign и службы ICANN в 2010 году успешно завершили развертывание DNSSEC в корневой зоне.

Споры вокруг того, кому должен достаться «главный ключ», кто будет подписывать данные, а кто станет генерировать новые ключи, шли довольно долго. В итоге утвердили следующую схему. Существует два ключа – самый главный KSK (Key Signing Key – ключ для удостоверения ключа) и чуть менее «главный» ZSK (Zone Signing Key – ключ для подписывания зоны). KSK удостоверяет ZSK, а уже последний используется для удостоверения данных в корневой доменной зоне. Достоверность ZSK можно проверить, используя открытую часть KSK.

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

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

Собственно, по состоянию на 2013 год KSK вообще ни разу не менялся – для этого просто забыли предусмотреть процедуру. Да, и такие провалы случаются в истории DNS, несмотря на участие в проектировании действующей версии системы множества признанных специалистов. Вполне возможно, что процедуры смены (ротации, как говорят специалисты) KSK все же разработают в ближайшие годы. И ключ изменится. Хотя кто знает – не исключены и более пессимистичные варианты.

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

Команда экспертов, выступающих представителями интернет-сообщества, включает в себя 21 человека в «основном составе», плюс 13 человек – «скамейка запасных». Назначение команды – обеспечивать процесс генерации и сопровождения ключей, подписывающих корневую зону DNS, выступая фактически в роли доверенных контролеров;

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

Третья группа хранит смарт-карты с частями ключа, позволяющего расшифровать резервную копию секретного KSK в случае, если вдруг основная копия, находящаяся в криптосервере, исчезнет в результате какого-нибудь катаклизма. В резерве – семь человек с ключами «от криптосервера» (условно) и шесть – с частями ключей от резервной копии.

Как я только что рассказал, используют два ключа: KSK и ZSK. С помощью KSK подписывают ZSK, которым подписывается корневая зона. ZSK генерирует VeriSign, потому что эта компания технически отвечает за распространение корневой зоны DNS. По процедуре, новые ZSK «выкатываются» четырежды в год. Каждый новый ZSK должен быть подписан защищенным криптосервером, в котором содержится секретная часть KSK. В идеале никто из людей не знает секретной части KSK – она просто не должна покидать пределы криптосерверов в открытом виде. То есть четыре раза в год эксперты с ключами от криптосервера приезжают в дата-центр и отпирают криптосервер, тем самым разрешая этому устройству подписать новый ZSK. Те доверенные люди, что хранят смарт-карты с частями ключа, которым зашифрована резервная копия KSK, выезжают «на восстановление» не по графику, а только если основная копия утрачена. (Видимо, только этот момент, благодаря его драматургии, и привлек журналистов.)

Понятно, что, если действовать по процедуре, без держателей ключей от криптосервера подписать зону восстановленным из резервной копии KSK не получится. Более того, по существующей процедуре не выйдет вообще что-либо сделать с корневой зоной без участия VeriSign и Минторга США – какими ключами ни размахивай. Очевидно, что утрата секретного ключа KSK не приведет одномоментно к отключению DNS и краху DNSSEC. До момента истечения срока действия текущего ZSK даже изменения в зону можно будет вносить. А вот подписать новый ZSK утраченным KSK – не получится.

Ну а самое интересное, что в крайнем случае никто не помешает просто сгенерировать новый KSK силами ICANN, Минторга и VeriSign, равно так же, как это было сделано при развертывании DNSSEC. Впрочем, возникнет большая проблема с распространением этого нового KSK по клиентам. Ситуация поменялась из-за того, что проникновение DNSSEC за эти годы возросло: просто так опубликовать ключ на сайте не выйдет, система сломается. А добротная процедура ротации KSK включает использование старого ключа, он потребуется для удостоверения нового, так что терять ключи ICANN не стоит.

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

Решая главную проблему «дырявости DNS», DNSSEC гарантированно создает множество новых проблем, ранее не существовавших. Это происходит прежде всего потому, что DNSSEC намного сложнее по сравнению с «классической DNS».

Уничтожая одни уязвимости, DNSSEC готовит почву для других. Разработчики системы, конечно, знают об этом. Уже понятно, что внедрение DNSSEC создаст новые возможности для атак типа «Отказ в обслуживании» (DoS), ведь криптографические процедуры защищенной DNS гораздо более ресурсоемки в вычислительном смысле. Злоумышленники при помощи отправки системам, поддерживающим DNSSEC, «дефектных» наборов данных смогут с большей относительно «классической» DNS легкостью занять все вычислительные ресурсы компьютера проверкой «бессмысленных» адресных данных.

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

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

На этом доверии сетевым реквизитам паразитируют так называемые фишеры.

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

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

Например, фишеры регистрируют домены, по тому или иному «психологическому» аспекту похожие на домен атакуемого сервиса (а атака не обязательно проводится на банк). Скажем, для атаки на сервисы известной поисковой машины «Яндекс», размещающей свои «точки входа» под доменом yandex.ru, предназначался домен yanclex.ru. В этом случае использовалась графическая схожесть буквы d и последовательности букв cl. Для осуществления атаки с использованием графически похожего домена пользователям рассылают поддельные сообщения электронной почты, в данном случае якобы от «Яндекса», в тексте которых содержится приглашение зайти по указанной ссылке и ввести свои авторизационные данные. Здесь важную роль играет именно то, что пользователь не набирает адрес в строке браузера и не использует «браузерную закладку» для перехода на сайт «Яндекса», а кликает по предложенной ссылке, на глаз определяя ее как ведущую на «Яндекс».

Регистрация домена yanclex.ru вполне может вызвать некоторые подозрения у регистратора, хотя никаких правовых оснований для запрета регистрации подобного домена нет. Но встречаются и куда более изящные с технической точки зрения решения, не могущие даже вызвать подозрений до того момента, как начнется фишинговая атака. Например, в 2010 году фишеры очередной раз использовали старый механизм дезинформирования пользователя и атаковали интерфейсы некоторых интернет-сервисов с помощью довольно изящного алгоритма. (Как обычно, я не излагаю атаку во всех деталях и незначительно изменяю некоторые технические моменты – эта книга не о взломе чужих аккаунтов.)

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

ffghfs.com. Здесь название домена второго уровня вообще не имеет значения, ставка делается на фрагмент twitter.com, имитирующий адрес известного сервиса микроблогов. На первый взгляд кажется, что пользователь легко отличит поддельный адрес от настоящего именно благодаря наличию избыточного «суффикса». Но не так все хорошо: злоумышленники использовали тот факт, что многие пользователи заходят в данный сервис с мобильных устройств (телефонов, коммуникаторов), в которых возможности по отображению адреса ограничены. Поэтому пользователи таких устройств, получив в специальном письме (или через систему обмена мгновенными сообщениями) некую ссылку, видели на экране только «начало» доменного имени в адресе URL: «http://www.twitter.c…» и предполагали, что соединяются со страницей известного им сервиса. Подготовить копию веб-интерфейса, запрашивающего пароль, и разместить ее под поддельным доменом – такая операция не представляет какой-либо трудности для интернет-мошенников.

Хитрость в том, что URL разбирается компьютером как положено по стандартам: то есть в области, определяющей адрес сервера, справа налево (терминальным – отделяющим адрес сервера от других элементов URL – тут является правый символ '/'). То есть, с точки зрения компьютера, вся строка адреса, начинающаяся с www.twitter.com, представляет собой адрес внутри домена ffghfs.com – а это никакой не «Твиттер»!

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

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

Некоторые владельцы раскрученных торговых марок и посещаемых ресурсов щепетильно относятся к «доменам-опечаткам», заранее регистрируя их на себя. Другие, видимо, из-за недопонимания проблемы упускают момент, отдавая «опечатки» охотникам за доменами. Уходят «домены-опечатки» даже от известных ИТ-компаний, чей бизнес прямо связан с Интернетом. Например, в управлении у российской компании «1С-Битрикс» находится домен bitrix.ru, под которым размещен сайт известной в Рунете коммерческой системы управления сайтами (CMS) «Битрикс». При этом очевидный «домен-опечатка» biRTix.ru (из-за особенностей зрительного восприятия текста при беглом чтении этот домен неотличим от оригинала; «перестановка» специально выделена заглавными буквами) управляется вовсе не «1С-Битрикс» (по состоянию на 2013 год). Другой пример: компания «Яндекс» запустила сервис для веб-мастеров под доменом webmaster.yandex.ru. Менеджеры компании, прежде чем публично объявлять о запуске нового сервиса, не позаботились о перехвате «тайпсквоттерских» доменов. В результате очевидное доменное имя с опечаткой webmasteryandex. ru (без точки) оказалось под управлением опытных домейнеров.

Рост тайпсквоттерской активности в приобретении доменов наблюдается регулярно, как только какой-то новый (или не очень новый) интернет-проект вдруг обретает большую популярность. Например, как только в 2006–2007 годах набрал популярность проект «Одноклассники», размещенный под доменом odnoklassniki.ru, тут же началась регистрация десятков «доменов-опечаток», например odnoklasniki.ru, odnolkassniki.ru, ondoklassniki.ru и т. п.

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

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

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

SSL-сертификаты лишь затрудняют деятельность по введению посетителей атакуемого сайта в заблуждение, но не делают ее невозможной.

Введение в строй многоязычных доменов, например кириллического домена РФ, создает новое пространство и для злоумышленников, которые обязательно начнут использовать особенности новых имен.

Для борьбы с самым очевидным вариантом фишинга, со смешением графически идентичных букв латиницы и кириллицы (типа буквы «эр» и буквы p – «пи»), в домене РФ запрещают использование латиницы вообще. Это очень разумно.

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

Кириллические домены верхнего уровня – это домены верхнего уровня. Но никто не запрещает использовать многоязычные имена в других доменных зонах, третьего уровня, скажем, и ниже. Punycode здесь также работает, а ограничения регистраторов доменов на смешивание символов нет. В большинстве случаев, практически важных для фишеров, преобразование алфавитов осуществляют браузеры. От введения дополнительного слоя преобразований безопасность пользователя в данном случае не может улучшиться, это очевидно. Ожидать, конечно, нужно и дыр в реализациях преобразований Punycode. Но с появлением и распространением домена РФ важнее умелое использование этих технологий в других доменных зонах.

В 2009 году я провел эксперимент, создав доменное имя, закодированное вот такими «кракозябрами»: xn-80adjurfhd. xn-click-uye2a8548c.dxdt.ru, что в перекодированном по таблицам Unicode виде смотрится так: проверка. рфclick. dxdt.ru. Здесь для имитации слеша использован специальный символ из таблиц Unicode с кодом 0х2044 (математический «знак деления»). Итоговый URL может быть вот таким: http://проверка. рфclick.dxdt.ru/ – мимикрия под проверка. рф, при этом реально домен находится в зоне. dxdt.ru, которой управляю я. Отличить сложно. Во многих браузерах в 2009–2010 годах – успешно работало. Правда, в 2010 году, например, в браузере Opera работа со смешанными многоязычными адресами уже была скорректирована и при переходе по данному URL выдавалась ошибка «Invalid URL», что неплохо. Позже подоспели и другие браузеры – Firefox, IE, Chrome, – исправив отображение подобных URL. Понятно, что на практике фишеры вместо проверка. рф могли использовать другие варианты исходных доменов, какие-нибудь известные бренды или названия банков.

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

Читатель спросит: ну и что с того, что на первом месте? Подумаешь, поисковый запросто не самый, как говорится, интересный! Но дело в том, что очень многие пользователи Сети вводят адреса сайтов не в адресной строке браузера, а строке запроса поисковика. После чего просто переходят по первой ссылке. То есть в данном случае поисковик помог создать идеальную видимость работы домена проверка. рф в то самый момент, когда и самого домена РФ еще не было в DNS (я затеял этот небольшой опыт в ноябре 2009 года). Надо сказать, что демонстрация эффекта даже на бывалых системных администраторов производила впечатление: «Постой, постой! А как это? Не может быть!» – спрашивали они; и лишь через пару минут, поизучав ситуацию, понимали, что к чему. Что уж ожидать от рядовых пользователей. Так что в связи с появлением многоязычных доменов нас, к сожалению, ждет новый всплеск оригинального доменного фишинга.

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