Безопасность DNS
Защита системы доменных имен

Аллан Лиска, Джеффри Стоу
Тимоти Галло, технический редактор

перевод В.Айсин

Посвящение

Крис и Брюс, как всегда, спасибо за вашу поддержку в процессе исследования и написания, люблю вас обоих!
Аллан Лиска

Кэти и Мерфи.
Джеффри Стоу

Об авторах

Аллан Лиска (Allan Liska) - системный инженер-консультант в FireEye Inc. и «случайный» эксперт по безопасности. Хотя Аллан всегда умел ломать вещи, он начал профессионально, работая представителем службы поддержки клиентов в GEnie Online Services (давным-давно не существующем конкуренте AOL), где он проводил свободное время, выясняя, как пользователи получили несанкционированный доступ в систему, загрузив их и сообщив разработчикам, что нужно исправить. По незнанию, это вело его по пути становления профессионалом в области безопасности. С тех пор он работал в таких компаниях, как UUNET, Symantec и iSIGHT Partners, помогая компаниям лучше защищать свои сети. Он также работал в Boeing, пытаясь проникнуть в сети этой компании.

В дополнение к своему времени, проведенному по обе стороны границы безопасности, Аллан много писал о безопасности, включая The Practice of Network Security и Building an Intelligence-Led Security Program. Он также был соавтором Apache Administrator’s Handbook.

Джеффри Стоу (Geoffrey Stowe) живет в Сан-Франциско и является ведущим инженером в Palantir Technologies. Его работа по сетевой безопасности включала исследование уязвимостей, обратное проектирование, реагирование на инциденты и обнаружение аномалий. Было время, когда он мог переводить байтовый код в ассемблер, не заглядывая в инструкции. Джефф начал коммерческий бизнес Palantir в 2010 году и построил свои первые платформы для распределенного крупномасштабного анализа данных. Он окончил Дартмутский колледж по специальности информатика.

Благодарности

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

Я также должен поблагодарить Анну Валуткевич, нашего менеджера проектов в Elsevier. Я ценю то, что вы настаиваете на том, чтобы этот проект заработал, тем более, что я отстал. Я также ценю, что вы работали с Джеффом, чтобы привлечь его на борт и быстро привести в порядок.

Конечно, эта книга также не была бы сделана без огромной поддержки со стороны коллег из самых разных компаний, которые все высказали свои мысли и ответили на мои вопросы. Я хочу особо поблагодарить команды аналитиков iSIGHT Partners и FireEye, Джей Джея Гая и команду Carbon Black, Арни Бьорклунда и команду SecurityZones, Шона Бленкхорна и команду eSentire, а также Шона Мерфи за ваши первые мысли по поводу книги.

Наконец, я хочу поблагодарить всех людей, которые добровольно вкладывают свое время в целостность инфраструктуры DNS и защиту от всех, кто хочет ее разрушить. Люди, которые помогают писать RFC, вносят свой вклад в рабочие группы, создают инструменты, которыми могут свободно пользоваться другие, и многое другое. Спасибо за ваш вклад!

Джеффри Стоу хотел бы добавить свою признательность Аллану Лиске, который был пионером книги и дал мне возможность писать на увлекательную тему. Аллан, Тим и Анна - настоящие профессионалы, и работа с ними была для меня прекрасным опытом. Я также хотел бы поблагодарить Дрю Деннисона, Майлза Сивера и Дэйна Стаки из Palantir за идеи и отзывы. И, конечно же, все стало возможным благодаря поддержке моей жены Кэти и сына Мерфи.

Глава 1
Понимание DNS

Информация в этой главе

Вступление

История DNS

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

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

Лучше всего начать с определения DNS. Аббревиатура DNS означает «Domain Name System» (система доменных имен), хотя некоторые используют DNS для обозначения серверов доменных имен. DNS - это избыточная иерархическая распределенная база данных, которая используется для передачи информации о доменных именах. Отсутствие единой аббревиатуры демонстрирует трудности, с которыми кто-либо столкнется при документировании DNS. Если люди не могут прийти к согласию даже в том, что означает аббревиатура, как они могут согласиться с чем-то еще? По мере продвижения по этой книге вы заметите, что администраторы DNS редко соглашаются с чем бы то ни было.

Метафора, наиболее часто используемая для описания DNS, - это дерево. DNS имеет корень, и различные домены верхнего уровня (TLD (top level domain)) похожи на ветви, которые отходят от корня. Каждая ветвь имеет меньшие ветки, которые являются доменами второго уровня, а листья - это Fully Qualified Domain Names (FQDN) (полностью определенные доменные имена), иногда называемые именами хостов. Не думайте, что это мирная пальма или крепкий дуб. Это чудовищное дерево, посаженное в цемент, с корнями, смыкающимися друг с другом, и ветвями, разлетающимися во всех направлениях, и часто кажется, что оно скреплено силой воли больше, чем чем-либо еще. Если DNS - это дерево, это больше похоже на Banyan Tree в Лахайне, Мауи. Баньян был 8 футов высотой, когда он был впервые посажен в 1873 году, теперь он более 60 футов в высоту и занимает площадь более 2/3 акра. Как и DNS, Баньяновое дерево стало настолько большим, отбрасывая новые корни из своих ветвей, что эти корни становятся новыми стволами баньянового дерева. Полный поток DNS-запроса от рабочей станции к ответу показан на рис. 1.1.

Рисунок 1.1 Стилизованная версия потока трафика DNS-запроса.

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

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

История DNS

Когда большинство людей думают об Интернете, на ум приходят Билл Гейтс, Стив Джобс, Марк Андрессен и Марк Цукерберг. Конечно, эти люди внесли большой вклад в развитие Интернета (или его падение, в зависимости от того, кого вы спросите), но есть целая группа людей, чье влияние было гораздо более глубоким. Их вклады не обязательно привели к многомиллионным IPO, но без них Интернет не был бы тем, чем он является сегодня.

Файл hosts.txt

Интернет иногда сравнивают с организмом. Как любой организм, он развивается с течением времени, а также, как и организм, он оставляет следы своего прежнего существования. В нашем случае остаток предшественника DNS, файл hosts.txt, все еще находится во многих системах.

Чтобы понять, почему возникла необходимость в DNS, взгляните на файл /etc/hosts в системах UNIX или %systemroot%\system32\drivers\etc\hosts.txt в Microsoft Windows или файл hosts.txt на устройствах Android. Формат всех этих файлов одинаковый:

IP Address   Computer Name   Comment

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

Два события помогли создать хост-файл. В декабре 1973 года в связи с RFC 592 было принято «официальное» соглашение об именах хостов. Цифры, буквы и дефисы были единственными символами, разрешенными в именах хостов, круглые скобки были разрешены как часть сетевых имен.

После того, как список имен хостов (всего их было 81!) был собран, следующим шагом стали RFC 606 и RFC 608. Эти RFC описывают создание нового централизованного файла под названием HOSTS.TXT, который можно загрузить через FTP, чтобы все администраторы, подключенные к ARPANET, имели одинаковые данные об именах хостов.

Интересно отметить, что хотя эта идея имеет большой смысл в ретроспективе, автор RFC 606, Л. Питер Дойч, счел необходимым добавить следующий отказ от ответственности:

Я понимаю, что есть проверенная временем ловушка, связанная с такими предложениями, как настоящее: они представляют собой конкретное решение конкретной проблемы и, как таковые, могут быть несовместимы или служить разумной основой для более общих решений более общих проблем. Однако (1) эта конкретная проблема раздражает меня и других, с которыми я разговаривал более года, и действительно абсурдно, что она так долго оставалась нерешенной; (2) никто особо не заинтересован в решении какой-либо более общей проблемы.

Первый файл hosts.txt появился в сети 25 марта 1974 г. и был объявлен в RFC 627. Перед выпуском первого файла hosts.txt было введено другое учреждение DNS. RFC 623 и RFC 625 обсуждали размещение файла hosts.txt на дополнительном сервере. Если первичный сервер, OFFICE-1, был недоступен, хост мог получить файл со вторичного сервера. Опять же, это очень похоже на то, как работает DNS сегодня.

Почтовые проблемы

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

Проблема компьютерной почты заключалась в том, что системой пользовалось слишком много людей, поэтому почтмейстерам стало трудно управлять почтовыми сообщениями. Формат почтовых адресов был основан на адресах в файле хоста. Итак, если кто-то хочет отправить сообщение Аллану Лиске в Example Corp, формат будет примерно таким, как liska@example или aliska@example. Это нормально, если есть только один компьютер, к которому подключены пользователи в исходной организации. Но популярность ARPANET росла, и пользователи компьютеров не были изолированы в одном отделе или даже в одном кампусе. Пользователи ARPANET были разбросаны по организациям и в разных местах.

По мере того, как популярность ARPANET увеличивалась, нам приходилось добавлять почтовые серверы в нескольких местах. Каждому из них нужно было бы присвоить уникальное имя хоста, которое затем нужно было бы добавить в файл hosts.txt. Если Аллан Лиска находится в офисе Example Corp в Вирджинии, необходимо создать имя хоста для этого офиса. Вместо того, чтобы отправлять почту на liska@example, ее нужно будет отправить на liska@exampleva. С другой стороны, если бы Брюс Лиска находился в офисе Example Corp в Калифорнии, почту нужно было бы отправлять на liska@exampleca. Это могло создать огромную путаницу - если отправитель не был уверен, в каком офисе находится человек или каковы различные соглашения об именах, было очень легко неправильно адресовать почту.

Это создало проблему, с которой пришлось столкнуться почтмейстерам. В конце концов, если человек получил доступ к электронной почте, он не может быть лишен ее. 11 января 1982 года было проведено собрание, на котором, среди прочего, обсуждалась эта проблема с почтой и было предложено решение. На встрече присутствовали Винт Серф, Билл Джой, Дэйв Крокер, Пол Мокапетрис, Дэвид Миллс и, конечно же, Джон Постел.

Результаты встречи были опубликованы в документе RFC 805 «Заметки о совещании по компьютерной почте». Банальное название скрывает важность этого документа для DNS. Решение, предложенное во время встречи, представляло собой комбинацию дополнения к текущему формату почты и включения «доменных имен Интернета», предложенных Дэвидом Л. Миллсом в RFC 799.

Основное предложение заключалось в том, что формат адресной системы электронной почты должен быть расширен путем добавления двух уровней, называемых узлами, в текущую схему адресации. В дополнение к «адресу» в «хосте» предложение добавит в адрес организацию и домен узлов. В приведенном выше примере, если вы хотите отправить письмо Аллану Лиске в Example Corp, формат будет изменен на «адрес» @ «имя хоста» разделитель узлов «компания» разделитель узлов «домен», например, allan@mailserver.example.in (.in для адреса в Интернете).

Эта система значительно упростит управление почтой для пользователей в географически разнесенных организациях. Адреса могут быть разбиты по географическому признаку. Если кто-то хочет отправить письмо Аллану Лиске в офис Example Corp в Вирджинии, адрес может быть allan@va.example.in; с другой стороны, Брюс Лиска в офисе в Калифорнии был бы чем-то вроде bruce@ca.example.in. Очевидно, это дало бы организациям больше свободы и облегчило бы жизнь администраторам почты. Конечно, это также означало необходимость переписать почтовые программы, чтобы они могли обрабатывать несколько узлов.

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

RFC 819 и 920

RFC 819 знаменует собой большой скачок в эволюции доменов; в нем описана доменная структура и заложена основа для инфраструктуры DNS. Джон Постел и Зау-Синг Су написали RFC 819, озаглавленный «The Domain Naming Convention for Internet User Applications», и выпустили его в августе 1982 года.

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

На первый взгляд, следующий год был тихим с точки зрения DNS - структура, изложенная в RFC 819, дорабатывалась и формировалась. В 1983 году подряд были выпущены три RFCS. RFC 881, RFC 882 и RFC 883 закладывают основу для текущей инфраструктуры DNS. Эти RFC сформировали то, как работает DNS сегодня. RFC 882 и RFC 883, написанные Полом Мокапетрисом, были особенно важны, потому что они обсуждали способ выполнения DNS-поиска и предоставляли обзор делегирования, что является отличительной чертой DNS и одной из причин его успеха.

После завершения обсуждения структуры DNS, на что потребовался еще почти год, был выпущен RFC 920. RFC 920, выпущенный в октябре 1984 г., изложил требования для фактического внедрения DNS ARPANET в масштабах всей сети и какие шаги необходимо предпринять. RFC 920 также завершил первоначальный список TLD: ARPANET (который должен был стать временным TLD), .GOV, .MIL, .EDU, .COM, .ORG и домены с двухбуквенным кодом страны.

Те, кто участвовал в первоначальном создании DNS, хотели быстро его настроить, и RRC 920 указал на быстрый темп. С момента выпуска RFC 920 все было готово к запуску, и в течение 6 месяцев регистрировались новые домены. Фактически, первым зарегистрированным доменом без TLD был NORDU.NET 1 января 1985 г.[1] Агентство оборонных информационных систем, которое теперь контролировало ARPANET, поручило обслуживание корневой инфраструктуры Стэнфордскому исследовательскому институту, и так родилась современная инфраструктура DNS.

Переходим к коммерциализации

В следующие несколько лет DNS практически не изменился. В октябре 1992 года Национальный научный фонд (NSF), а точнее NSFNet, который стал владельцем ARPANET в 1986 году, заключил контракт на оказание управленческих услуг компании Network Solutions Inc. Это было огромное изменение, поскольку оно передало контроль над DNS от, в основном, академического сообщества частному сектору.

Вплоть до 1995 года любой желающий иметь доменное имя мог его зарегистрировать. По мере того, как все больше людей осознавали коммерческую ценность Интернета, некоторые из них начали регистрировать сотни доменов, полагая, что они могут оказаться полезными в будущем. Чтобы остановить распространение этой практики и возместить часть затрат на обслуживание инфраструктуры DNS, Network Solutions с одобрения NSF начала взимать плату за регистрацию доменных имен. Первоначальный взнос составлял 100 долларов за 2 года, из которых 30 долларов пошли на поддержку инфраструктуры Интернета.

Это совпало с идеями правительства США того времени, которое имело мандат на приватизацию и усиление конкуренции в Интернете. Министерство торговли особенно интересовалось DNS и запрашивало у общественности комментарии о том, как помочь им выполнить мандат президента Клинтона.

В 1998 году правительство выпустило документ, в котором описывается передача контроля над DNS из исключительной области Network Solutions в независимую организацию, которая будет способствовать конкуренции и поощрять дальнейшее использование Интернета. Из этого документа в конечном итоге родилась Internet Corporation for Assigned Names and Numbers (ICANN).

ICANN взяла на себя управление корневыми серверами имен в 1999 году и начала процесс регистрации. Компаниям, отвечающим определенным требованиям, разрешается регистрировать домены от имени широкой публики. Эти домены вводятся в различные базы данных TLD, и все утвержденные ICANN регистраторы могут регистрировать общие TLD.

Корень

Ядром DNS является корень, или, точнее, множественные корни. Корневые системы хранят достоверные данные о доменах и помогают направлять запросы на соответствующие серверы. В DNS используются два разных типа корневых серверов: корневые серверы и корневые серверы TLD.

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

В дополнение к корневым серверам имен каждый TLD также имеет свой собственный корневой сервер или серверы. Этот корневой сервер является полномочным для получения информации о конкретном TLD, корневой сервер домена является верхним узлом в дереве доменов и представлен значком «.» который следует за доменным именем. Завершающий "." обычно не отображается вне области DNS, но важно помнить, что он там есть. Итак, домен example.com правильно представлен как:

example.com.

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

Атаки на root nameservers

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

В феврале 2007 года была запущена еще одна крупная DDoS-атака на корневые DNS-серверы, при этом два из них были временно выведены из строя, остальные корневые серверы продолжали отвечать на запросы.

31 марта 2012 года Anonymous пригрозили отключить корневые DNS-серверы. Атака была полностью безуспешной.

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

Все корневые серверы используют одно и то же соглашение об именах: назначенная им буква, за которой следует домен root-servers.org. Первый - a.root-servers.org, второй - b.root-servers.org и так далее. Эти серверы являются одними из самых загруженных в Интернете. F.root-servers.org - возможно, самый загруженный - обрабатывает более 270 миллионов запросов в день, хотя он создан для обработки значительно большего числа запросов.

Распространенное заблуждение состоит в том, что корневой сервер A более важен для инфраструктуры DNS, чем другие корневые серверы. Это не так, все корневые серверы имен распределяют нагрузку одинаково, и все корневые серверы содержат одинаковую информацию о корнях TLD.

;       This file holds the information on root name servers needed to 
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  . <file>"
;       configuration file of BIND domain name servers). 
; 
;       This file is made available by InterNIC 
;       under anonymous FTP as
;           file                /domain/named.cache 
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
; 
;       last update:     June 24, 2021 
;       related version of root zone:     2021062401
; 
; FORMERLY NS.INTERNIC.NET 
;
.                        3600000      NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30
; 
; FORMERLY NS1.ISI.EDU 
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     199.9.14.201
B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:200::b
; 
; FORMERLY C.PSI.NET 
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
C.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2::c
; 
; FORMERLY TERP.UMD.EDU 
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     199.7.91.13
D.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2d::d
; 
; FORMERLY NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
E.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:a8::e
; 
; FORMERLY NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
F.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2f::f
; 
; FORMERLY NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
G.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:12::d0d
; 
; FORMERLY AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     198.97.190.53
H.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:1::53
; 
; FORMERLY NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
I.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fe::53
; 
; OPERATED BY VERISIGN, INC.
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
J.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:c27::2:30
; 
; OPERATED BY RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
K.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fd::1
; 
; OPERATED BY ICANN
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     199.7.83.42
L.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:9f::42
; 
; OPERATED BY WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
M.ROOT-SERVERS.NET.      3600000      AAAA  2001:dc3::35
; End of file

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

Когда ICANN утверждает новый TLD, это либо спонсируемый, либо не спонсируемый домен (если это не TLD с кодом страны, например .us или .ca). Спонсируемые домены - это те TLD, которые используются в определенной отрасли, например .aero (воздушный транспорт) или .museum (музеи). Большинство TLD не спонсируются и, следовательно, подпадают под контроль ICANN и соблюдают правила, разработанные ICANN.

ICANN не управляет TLD напрямую; вместо этого он поручает обслуживание TLD различным организациям на определенный период времени. Различные организации управляют разными TLD в соответствии со своими собственными наборами правил, но в рамках правил, установленных ICANN. Итак, ICANN с учетом отзывов интернет-сообщества создает новый TLD, а обслуживание этого TLD передается на аутсорсинг другой организации. Эта организация управляет корневым сервером для определенного TLD и обновляет ICANN по мере изменения информации об изменениях TLD.

TLD с кодом страны (ccTLD) обрабатываются несколько иначе. ccTLD основаны на двухсимвольном обозначении, присвоенном стране Международной организацией по стандартизации (ISO). ISO поддерживает документ ISO 3166-1, в котором перечислены страны вместе с их двухсимвольным кодом. Internet Assigned Numbers Authority (IANA) использует этот список для определения того, каким будет ccTLD для каждой страны.

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

Список всех ccTLD

Полный список ccTLD, а также их спонсирующих организаций и другую важную информацию можно найти на веб-сайте IANA: http://www.iana.org/domains/root/db.

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

Хотя важно понимать, что такое корневые серверы и как они работают, в действительности различные корневые серверы будут иметь очень небольшое влияние на повседневные операции большинства администраторов DNS. Корневые серверы имен и корневые серверы TLD работают с очень высоким уровнем безопасности и доступности. Хотя, если бы это было не так, отдельное лицо или корпорация мало что могли бы с этим поделать.

Рекурсивные и авторитетные серверы

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

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

Рекурсивные серверы имени

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

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

Рисунок 1.2 Рекурсивный серверный процесс.

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

Пользователь, который хочет посетить www.example.com, сначала запросит рекурсивный сервер имен на рабочей станции, который будет выглядеть примерно так:

Domain Name System (query)
    Transaction ID: 0x003e
    Flags: 0x0100 (Standard query)
    0... .... .... .... = Response: Message is a query
    .000 0... .... .... = Opcode: Standard query (0)
    .... ..0. .... .... = Truncated: Message is not truncated
    .... ...1 .... .... = Recursion desired:
    Do query recursively
  .... .... ...0 .... = Non-authenticated data OK: Non-authenticated
data is unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
    www.example.com: type A, class inet
    Name: www.example.com
    Type: Host address
    Class: inet

Не беспокойтесь о кодах, они будут объяснены в ближайшее время. Запросы DNS отправляются через порт 53 с использованием протокола пользовательских дейтаграмм (UDP). Рабочая станция отправляет запрос: «Я хотел бы узнать как можно больше о example.com, но меня особенно интересует запись A для www.example.com». Рекурсивный сервер отвечает следующей информацией:

Domain Name System (response)
    Transaction ID: 0x003e
    Flags: 0x8580 (Standard query response, No error)
    1... .... .... .... = Response: Message is a response
    .000 0... .... .... = Opcode: Standard query (0)
    .... .1.. .... .... = Authoritative: Server is an authority for domain
    .... ..0. .... .... = Truncated: Message is not truncated
    .... ...1 .... .... = Recursion desired: Do query recursively
    .... .... 1... .... = Recursion available: Server can do recursive queries
    .... .... ..0. .... = Answer authenticated: Answer/authority
    portion was not authenticated by the server
    .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 2
    Additional RRs: 2
    Queries
            www.example.com: type A, class inet
            Name: www.example.com
            Type: Host address
            Class: inet
            Answers
            www.example.com: type A, class inet, addr 192.0.34.166
            Name: www.example.com
            Type: Host address
            Class: inet
            Time to live: 2 days
            Data length: 4
            Addr: 192.0.34.166

На основании ответа www.example.com преобразуется в IP-адрес 192.0.34.166. После успешного преобразования домена в пригодный для использования IP-адрес рабочая станция выдает HTTP-запрос для www.example.com. Все это происходит без какого-либо вмешательства или ведома пользователя рабочей станции.

Как рекурсивный сервер делает запрос? Опять же, это очень простой процесс. Рекурсивный сервер имен запускает программное обеспечение разрешения, такое как BIND, и использует это программное обеспечение для запроса корневых серверов имен. У программы разрешения есть файл подсказок, аналогичный старому файлу hosts.txt, который содержит список корневых серверов. Когда запрос поступает на рекурсивный сервер, он удерживает запрос и запрашивает один из корневых серверов. Файл подсказок доступен через FTP с FTP-сервера InterNIC, и его имя по умолчанию - root (хотя разные операционные системы и разные резолверы имеют разные соглашения об именах).

Файл named.root имеет очень простой формат; это список корневых серверов с соответствующими IP-адресами. Когда запрос поступает на рекурсивный сервер, он проверяет, есть ли у него самого запись об этом домене, если нет, он затем запрашивает корневые серверы имен.

Знание какой сервер запросить

Как рекурсивный сервер знает, какой сервер имен запрашивать? Рекурсивный сервер имен вычисляет время приема-передачи (RTT) для запросов к каждому серверу имен. RTT - это, по сути, гонка на ногах, которая измеряет время в миллисекундах, которое требуется для извлечения файла зоны. Когда рекурсивный сервер впервые инициирует запрос, он устанавливает RTT для всех авторитетных серверов имен равным 0. Затем рекурсивный сервер запрашивает все серверы имен случайным образом; тот, у которого самый низкий RTT после того, как все они были запрошены, будет предпочтительным сервером имен. После каждого запроса RTT для всех серверов, кроме ранее записанного «самого быстрого» сервера имен, уменьшается. Это сделано для того, чтобы другие серверы имен в конечном итоге стали серверами, запрашиваемыми в первую очередь, что помогает распределить нагрузку между всеми серверами имен. По истечении первоначального срока действия TTL процесс RTT начинается заново.

Авторитетные серверы имен

Последней остановкой в процессе запроса DNS является авторитетный сервер имен. Как следует из названия, авторитетные серверы имен содержат информацию о доменном имени. Рекурсивные серверы запрашивают авторитетные серверы имен, чтобы найти конкретные ответы (например, какой IP-адрес www.example.com). Эти ответы передаются другим машинам, которые запрашивают рекурсивный сервер имен.

Авторитетные серверы имен - это хосты, зарегистрированные в органе или органах TLD, для которых администратор сервера имен намеревается размещать доменные имена. После регистрации хоста его можно назначить для хоста такого количества доменов, которое может выдержать сервер[2].

Процесс работает следующим образом: организация сначала регистрирует домен, используя своего любимого регистратора. Организация решает, что они будут управлять DNS собственными силами; поэтому они создают запись хоста, например, ns1.example.com. Эта запись создается их регистратором и представляет собой сопоставление имени хоста с IP-адресом и хранится на корневых серверах TLD. Теперь не только ns1. example.com содержит авторитетную информацию для example.com, а также может содержать авторитетную информацию для других доменов. Когда домен зарегистрирован, организация просто говорит регистратору использовать ns1.example.com в качестве одного из авторитетных серверов. Кроме того, www.example.com можно зарегистрировать с использованием сторонних авторитетных серверов, как в этом примере:

Domain Name: EXAMPLE.COM
Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
Whois Server: whois.iana.org
Referral URL: http://res-dom.iana.org
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 14-aug-2015
Creation Date: 14-aug-1995
Expiration Date: 13-aug-2016

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

Запрос к корневым серверам .COM возвращает оба авторитетных сервера имен для домена example.com. Затем рекурсивный сервер имен начинает гонку между двумя авторитетными серверами имен, чтобы увидеть, какой из них отвечает быстрее всего. Из двух авторитетных серверов a.iana-servers.net отвечает быстрее всех и возвращает запрошенную информацию. Это также показано на рис. 1.3.

Рисунок 1.3 Корневой сервер TLD направляет рекурсивный сервер на соответствующий полномочный сервер.

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

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

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

Файлы зоны

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

Файл зоны иногда выглядит примерно так:

$ttl 43200
example.com. IN    SOA    ns1.example.com. dns.example.com. (
   2003040401
   10800
   3600
   432000
   43200)
example.com.    IN NS ns1.example.com.
; The servers
www     IN    CNAME example.com.
ftp     IN    A    example.com.
mail      60   IN    A    10.100.0.10
example.com.    IN    A    10.100.0.12
; The name servers
example.com.    IN    NS    ns1.foo.com.
example.com.    IN    NS    ns2.example.com.
; The mail servers
example.com.    IN    MX    10 mail.example.com.
example.com.    IN    MX    50 mail.foo.com.

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

Первая строка в файле зоны определяет время жизни по умолчанию (TTL) - в секундах - для зоны; это TTL, который будет использоваться для всех записей в файле зоны, если не указан другой TTL. Строка 1 устанавливает TTL по умолчанию для этой зоны на 12 часов.

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

Domain Name   Class   Resource Record   Origin   Contact

Первое поле в строке - это сам домен, второе поле - это класс, который всегда имеет значение IN (сокращение от Internet), а третье поле - это запись ресурса (RR), которая всегда является SOA. Следующее поле - это исходный сервер, который является главным сервером для этого домена - сервером, откуда берется информация. Информация в этом поле одинакова как на главном, так и на подчиненном сервере, и она должна ссылаться на каноническое имя, а не на CNAME или IP-адрес.

Последнее поле - это административный контакт для доменного имени. Это должен быть человек или группа, ответственные за поддержку доменного имени и файла зоны. Обратите внимание на формат контактной информации: все три поля разделены точками, первая точка должна быть заменена знаком «@», чтобы поле в действительности читалось как dns@example.com.

Соглашение о контактах

Стандартное соглашение для поля контакта заключается в том, что первая точка заменяется знаком «@», поэтому адрес должен быть как можно более простым. Использование адреса типа dns.admin@example.com приведет к преобразованию в dns.admin.example.com и может запутать кого-то, пытающегося связаться с администратором этого домена.

Строки с 3 по 6 предназначены для использования подчиненными серверами. Строка 3 - серийный номер; это поле следует обновлять каждый раз, когда в главный файл зоны вносятся изменения. Стандартный формат - YYYYMMDDNN, но подойдет любой формат, если каждый раз, когда вносятся изменения, число больше.

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

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

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

Строка 7 предназначена специально для рекурсивных серверов, это TTL по умолчанию. Он должен иметь то же значение, что и TTL, указанный в строке 1.

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

Ресурсные записи

Эта глава прошла путь от общего к частному, и этот раздел является наиболее конкретным, он также является сердцем DNS. Основная функция DNS состоит в том, чтобы обмениваться информацией, чтобы упростить - и автоматизировать - получение доступа к веб-сайту www.example.com или отправки почты на адрес user@example.com.

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

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

Стандартный формат RR состоит из пяти полей, каждое из которых содержит конкретную информацию о RR:

Name  TTL  Class  Type  Data

На практике формат обычно выглядит так:

mail.example.com.   3600   IN   A   10.10.100.102

Здесь важность конечной точки становится очевидной. Если после домена нет конечной точки, программное обеспечение DNS обычно интерпретирует это, чтобы указать имя хоста, и программное обеспечение будет работать с доменом. В приведенном выше примере, если после mail.example.com не будет конечной точки, программа решит, что RR ссылается на mail.example.com.example.com.

В поле «Name» указывается имя хоста или IP-адрес в зависимости от записи; это объект, которому принадлежит этот конкретный RR. TTL используется только в том случае, если для конкретной RR требуется TTL, отличный от указанного в SLA. Если TTL не указан, используется TTL зоны по умолчанию. Класс всегда IN (Интернет), это единственный класс, который в настоящее время поддерживается DNS. Тип определяет цель, которой служит RR, в приведенном выше примере запись «A» является адресной записью, другие записи обсуждаются ниже. Поле данных различается в зависимости от типа RR; данные - это информация, которую сервер имен пытается передать об этом конкретном RR.

Адресные записи

Самый распространенный тип RR - это запись Address или A. Запись A сопоставляет полное доменное имя (FQDN) с IP-адресом, как в приведенном выше примере. Каждый адрес узла в домене должен иметь запись A (узлы в файле зоны, но не часть домена, не требуют записей A в этом файле зоны) или запись канонического имени:

mail.example.com.   3600   IN   A   10.10.100.102

Помните, что поле TTL является необязательным, если RR может использовать TTL по умолчанию для зоны, тогда нет необходимости включать его в RR. Запись A является самой простой из RR и, несомненно, наиболее часто используемой. Даже простой файл зоны часто содержит 5 или 6 записей А.

Если полное доменное имя (FQDN) указывает на несколько IP-адресов, сервер имен будет возвращать их циклически. Первый сервер, запрашивающий запись A, получит первую запись, второй сервер получит вторую запись, третий сервер получит третью запись и т.д. Как только сервер имен вернет все записи A, он начнет с начала.

Также существует запись A, разработанная специально для адресов IPv6. Эта запись известна как запись AAAA и соответствует тому же формату, что и запись A, но с адресом IPv6:

ipv6.example.com.  3600  IN  AAAA  2001:468:504:1:210:5aff:fe1a:11e

Записи канонического имени

Записи канонического имени (CNAME) - это псевдонимы, которые сопоставляют одно полное доменное имя (FQDN) другому. Вместо того, чтобы отображать полное доменное имя напрямую на IP-адрес, часто проще сопоставить его с другим хостом. Это особенно полезно, если есть много FQDN, указывающих на один и тот же IP-адрес, при изменении основного адреса другие адреса обновляются автоматически. CNAME будет выглядеть примерно так:

www.example.com.  3600  IN  CNAME  mail.example.com.
mail.example.com.  3600  IN  A  10.10.100.102

Чтобы CNAME работала, она должна указывать на полное доменное имя (FQDN) с допустимой записью A. CNAME не обязательно указывает на полное доменное имя в том же файле зоны; она может указывать на другие полные доменные имена:

www.example.com  3600  IN  CNAME  www.foo.com.

Опять же, www.foo.com должен иметь действительную запись A, чтобы этот CNAME работал. Еще одна важная вещь о записях CNAME заключается в том, что они не могут использоваться другими RR. Ни MX, ни NS-записи не могут указывать на CNAME-записи.

Записи почтового обмена

Запись Mail Exchanger (MX) используется для определения хостов, на которые следует отправлять почту для домена. Как и записи CNAME, записи MX не должны указывать на полные доменные имена в домене, записи MX могут указывать на любой хост внутри или за пределами домена, если этот хост настроен для приема почты для этого домена. Записи MX должны указывать на полные доменные имена, которые представлены записями A, а не записями CNAME.

Большинство современных агентов пересылки почты (MTA) понимают записи CNAME и могут пересылать им почту, но некоторые по-прежнему этого не делают. Это также противоречит RFC, поэтому, пожалуйста, не делайте этого.

Запись MX будет выглядеть примерно так:

example.com.  3600  IN  MX  10 mail.example.com.
example.com.  3600  IN  MX  20 mail.foo.com.

Существует уникальное поле для записей MX, которое называется весом записи. Вес, используемый для определения предпочтения нескольких записей MX. Чем меньше вес записи, тем больше предпочтение отдается этой записи. В приведенном выше примере mail.example.com предпочтительнее mail.foo.com. Когда MTA пытается отправить почту на user@example.com, сначала он попробует использовать сервер mail.example.com, и только если mail.example.com превысит тайм-аут или вернет почту, обратится к серверу mail.foo.com.

Записи сервера имен

Помимо регистрации в качестве хостов, серверы имен также должны быть определены в файле зоны как записи сервера имен (NS). Как подразумевается, записи NS используются для перечисления авторитетных серверов имен для домена. Записи NS обычно являются первыми RR после SOA и форматируются следующим образом:

example.com.   IN   NS    ns1.example.com.
example.com.   IN   NS    ns1.foo.com.
example.com.   IN   NS    ns2.example.com.

Как и записи MX и CNAME, записи NS не должны указывать на полное доменное имя, которое существует в файле хоста, запись NS может указывать на любой хост, который имеет достоверную информацию о домене. Запись NS обязательно должна быть полным доменным именем, но не IP-адресом; она также должна указывать на полное доменное имя, которое является записью A, а не CNAME.

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

Записи указателя

Записи указателя (PTR) противоположны записям A. Записи PTR сопоставляют IP-адреса с именами доменов. Записи PTR хранятся в специальных файлах зон, называемых файлами зон in-addr.arpa. Информация о данных для блоков IP-адресов распространяется через региональные Network Coordination Centers (NCC).

В настоящее время существует пять NCC: Американский реестр интернет-номеров обрабатывает информацию для Северной Америки; Реестр Интернет-адресов Латинской Америки и Карибского бассейна обрабатывает IP-пространство для Латинской Америки и Карибского бассейна; Reseaux IP Europeens управляет пространством IP-адресов в Европе; Африканский сетевой информационный центр - это Интернет-реестр африканского континента; и Азиатско-Тихоокеанский сетевой информационный центр, который отвечает за пространство IP-адресов в Азиатско-Тихоокеанском регионе.

Информация о выделении IP-адресов обрабатывается почти так же, как информация о доменном имени, и структура DNS идентична. Разница в том, что администраторы работают с блоками IP-адресов, а не с доменными именами, и файлы зон в этом отношении различаются.

Файлы зоны in-addr.arpa именуются с использованием блока IP в обратном порядке, за которым следует in-addr.arpa. Если организации выделен IP-блок 10.100.50.0/24 (сетевой блок класса «C»), файл зоны с информацией об этом сетевом блоке будет иметь имя:

50.100.10.IN-ADDR.ARPA

Файлы зоны обычно содержат только три типа RR: записи SOA, NS и PTR, причем записи PTR представляют основной интерес. Записи PTR следуют тому же общему формату, что и файлы прямой зоны, но имя хоста находится в поле данных:

102  3600  IN  PTR    mail.example.com.

В этой записи указано, что IP-адрес 10.10.100.102 сопоставлен с почтой. example.com. В отличие от записей A, в которых имя хоста может быть сопоставлено с несколькими IP-адресами, IP-адрес может быть сопоставлен только с одним именем хоста.

Информация о записи PTR часто используется для аутентификации. Некоторые администраторы почты отклоняют почту, которая не исходит от сервера с обратной записью, а некоторые FTP-серверы отклоняют вход в систему от пользователей, у которых нет обратных записей, сопоставленных с их именем хоста. Целесообразность этого типа безопасности спорна, но она существует, и о ней следует знать.

Записи информации о хосте

Записи Host Info (HINFO) в наши дни используются не очень часто, но они все же время от времени появляются. HINFO предоставляет информацию об операционной системе и оборудовании хоста. Формат такой же, как и у других записей RR, но поле данных содержит неструктурированные данные хоста:

mail.example.com.  3600  IN  HINFO  "Dell 1650" "Redhat 9.1"

RFC 1035 рекомендует формат для поля данных HINFO, хотя он не соблюдается строго, и другая информация может быть заменена.

Записи сервера

Записи сервера (SRV) были впервые описаны в RFC 2052. Они представляют собой другой способ запроса у серверов имен информации об имени хоста. Обычно, когда кто-то хочет получить доступ к службе для домена, им нужно знать правильное имя хоста. Например, если кто-то пытается посетить веб-сайт Example Corp, этот человек должен знать, что имя хоста www.example.com поддерживает службы HTTP.

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

Service.Proto.Name  TTL  Class  SRV  Priority  Weight  Port  Target

Как и записи MX, записи SRV позволяют администраторам DNS назначать разные веса различным записям SRV. В качестве реального примера можно использовать записи SRV для балансировки трафика между веб-серверами:

http.tcp.www.example.com.  IN  SRV  10 10 80 host1.example.com.
http.tcp.www.example.com.  IN  SRV  10 10 80 host2.example.com.

В приведенном выше примере администратор DNS выполняет балансировку нагрузки HTTP-служб между двумя службами. Конечно, должны быть записи A для host1.example.com и host2.example.com. В этом случае, поскольку администратор хочет равномерно распределить нагрузку между двумя серверами, вес и приоритет задаются одинаковыми. Если бы одному из серверов требовалось брать на себя большую нагрузку, его вес был бы меньше. Точно так же, если один сервер был основным сервером, а другой сервер просто резервным сервером, приоритет основного сервера был бы установлен ниже, чем приоритет резервного сервера.

Записи SRV встречаются не так уж и часто; они в основном используются внутрисетевыми службами, такими как Microsoft Active Directory.

Текстовые записи

Текстовые (TXT) записи - это еще один тип RR, который обычно не используется. Записи TXT представляют собой текст произвольной формы, который используется для предоставления удобочитаемой информации о записи или домене в более общем смысле, они обычно настраиваются примерно так:

allan   IN   TXT   "Hello World!"

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

Выводы

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

Заметки

  1. Некоторые люди скажут вам, что первым зарегистрированным доменом был Symbolics.com или Think.com, вы можете сообщить им, что эти домены были зарегистрированы в марте 1985 г. и мае 1985 г. соответственно, по крайней мере через 3 месяца после того, как был зарегистрирован NORDU.NET.

  2. Это, конечно, при условии, что домен, связанный с хостом, также зарегистрирован.

Глава 2
Проблемы безопасности DNS

Информация в этой главе

Вступление

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

Частично этот недостаток знаний связан с тем, что DNS - это то, что часто «настраивают и забывают». Инфраструктура DNS настроена, и, за исключением нескольких изменений зон здесь и там, это редко рассматривается. DNS также является давно устоявшимся протоколом, многие компании зарегистрировали свои домены 20 или более лет назад, а команда, которая настраивала исходную инфраструктуру DNS, уже давно перешла к другим ролям. Если DNS для организации работает, зачем вносить изменения? Хуже того, может не оказаться никого, кто знает, как вносить изменения.

Старая проблема

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

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

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

Краткая история нарушений безопасности DNS

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

В 1996 году Евгений Кашпурефф использовал эксплойт для отравления кеша DNS, чтобы перенаправить трафик с веб-сайта InterNIC на свой собственный веб-сайт AlterNIC, альтернативный реестр. Эксплойт продолжался несколько дней, прежде чем Кашпурефф вернул обслуживание InterNIC.

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

29 января 2001 года доступ ко всем сайтам Microsoft, включая сайты MSN, был прерван почти на день из-за атаки на серверы имен Microsoft. Администраторы DNS Microsoft упростили атаку, разместив все свои серверы имен в одном сегменте сети, что дало злоумышленнику единую цель.

21 октября 2002 г. была проведена атака на корневые серверы имен. Атака представляла собой DDoS-атаку на основе ICMP, в результате которой несколько корневых серверов имен стали недоступными. Из-за рекурсивности и избыточности на корневых серверах атаку, которая длилась около часа, практически никто не заметил. Если бы атака продолжалась в течение более длительного периода времени, воздействие, несомненно, было бы намного сильнее.

В июне 2008 года турецкая хакерская группа, называющая себя NetDevilz, использовала социальную инженерию, чтобы убедить регистратора доменов для Internet Corporation for Assigned Names and Numbers (ICANN) и Internet Assigned Numbers Authority (IANA) передать контроль над icann.org и iana.org в NetDevilz. Изменение записи длилось всего 20 минут или около того, прежде чем оно было исправлено, но многие пользователи были перенаправлены на неправильные веб-сайты на срок до 24 часов.

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

В 2013 году веб-хостинговая компания CyberBunker запустила крупнейшую в то время DDoS-атаку на DNS-серверы Spamhaus, добровольной организации, которая отслеживает спамеров и предоставляет черный список, на который могут подписаться другие организации, чтобы уменьшить количество получаемого спама. потому что Spamhaus добавил пространство IP-адресов CyberBunker в черный список Spamhaus[1]. Другие организации и раньше предпринимали неудачные попытки DDoS-атак на серверы Spamhaus. Путем нацеливания на DNS-серверы Spamhaus, которые размещались третьей стороной, CyberBunker смог обойти возможности защиты от DDoS-атак, которые имелись в Spamhaus. Эти переданные на аутсорсинг DNS-серверы также обслуживали других клиентов по всему миру, поэтому DDoS-атака не только сделала серверы Spamhaus недоступными, но и ухудшила качество обслуживания клиентов по всему миру.

В 2010 году Verisign стала жертвой нескольких успешных атак неизвестных злоумышленников. Verisign управляет корневыми серверами имен .com и .net, а также корневыми серверами имен для нескольких других общих доменов верхнего уровня и многих национальных доменов верхнего уровня (ccTLD). По данным Verisign, никакие данные, относящиеся к корневым серверам, управляемым компанией, не были скомпрометированы во время атак.

31 марта 2012 года компания Anonymous попыталась отключить весь Интернет с помощью операции «Блэкаут». Целью Operation Blackout было уничтожить 13 корневых серверов с помощью атаки DNS Amplification (описанной далее в этой главе). Атаки DNS Amplification удивительно просты в запуске и эффективно использовались в ряде DDoS-атак. К счастью, команда Anonymous имела очень слабое представление о том, как работает DNS, как настроены корневые серверы имен, как основные интернет-провайдеры работают с корневыми серверами имен. Не говоря уже о том, что они по большей части некомпетентны. У атаки было очень мало шансов на успех. В итоге атака либо не произошла, либо просто не повлияла на производительность корневых серверов имен.

Гораздо более эффективная атака была проведена против Турции в декабре 2015 года. Эта DDoS-атака была нацелена на корневые серверы имен ccTLD .tr и эффективно изолировала Турцию от остального мира с точки зрения Интернета. Атака имела побочное преимущество в виде ухудшения качества обслуживания по всей Европе, поскольку сетевой координационный центр Reseaux IP Europeens предоставил вторичные авторитетные службы DNS для домена .tr.

Атакуя корневые серверы имен .tr с помощью относительно скромной DDoS-атаки 40 Gps, злоумышленники смогли сделать недоступными около 400 000 доменов. Это означало, что пользователи не могли заходить на веб-сайты компании или отправлять электронные письма пользователям с адресами электронной почты .tr. Чтобы заблокировать атаку, турецкое правительство было вынуждено временно заблокировать весь интернет-трафик, исходящий из-за пределов Турции. Это позволило людям в Турции снова начать общаться с доменами .tr, но заблокировало остальную часть Интернета.

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

Почему важна безопасность DNS?

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

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

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

Но безопасность DNS должна быть в центре каждого обсуждения сетевой безопасности. Атаки DNS более распространены, чем думает большинство людей, и сбои в безопасности DNS могут нанести вред организации. Сколько денег организация теряет каждый час, когда недоступна по электронной почте? Как насчет случая, когда полностью функционирующий веб-сайт невидим для Интернета или, что еще хуже, посетители веб-сайта перенаправляются на вредоносный веб-сайт? Исследование, проведенное Vanson Bourne в 2014 году, показало, что 75% организаций в США и Великобритании подверглись атаке DNS, а 49% раскрыли какие-либо атаки на основе DNS за предыдущие 12 месяцев. Итак, DNS-атаки широко распространены, но они не обязательно привлекают к себе то внимание, которого заслуживают.

DNS относится к категории «служебных протоколов», которые поддерживают связь в Интернете. Это надежные протоколы, которые помогают поддерживать поток трафика и взаимодействовать с серверами, о существовании которых большинство пользователей не подозревает. Такие протоколы, как Border Gateway Protocol, Network Time Protocol и, конечно, DNS, имеют решающее значение для поддержания работоспособности Интернета, но обычно выходят за рамки компетенции групп безопасности. Администраторы, которые настраивают системы, в которых работают эти протоколы, и управляют ими, обычно не задумываются о проблемах безопасности, присущих этим протоколам.

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

Ярким примером этого является DNSSEC (подробно обсуждается в главе 10). RFC 3833, который представил способ повышения безопасности инфраструктуры DNS, был впервые выпущен в 2004 году. Даже в 2016 году очень немногие доменные имена добавили подписывание DNSSEC в свой файл зоны, и многие регистраторы доменов до сих пор не поддерживают его.

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

Общие проблемы безопасности DNS

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

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

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

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

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

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

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

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

Это важно помнить: нарушение безопасности не обязательно должно быть преднамеренным. Администратор, который вводит неверный IP-адрес или случайно удаляет важный файл, по-прежнему создает ситуацию безопасности. Подобные события нужно планировать с таким же вниманием, как и враждебные.

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

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

Другое дело - нарушения внешней безопасности; очень редко внешнее нарушение может быть случайным. Большинство внешних атак на DNS-серверы являются либо специально нацеленными на организацию, либо случайными. Случайная атака происходит, когда злоумышленник сканирует диапазон IP-адресов и обнаруживает DNS-сервер с известной уязвимостью. Злоумышленник начнет атаку на этот сервер и попытается получить доступ не потому, что у злоумышленника есть особая неприязнь к организации, а просто потому, что это возможно. Обратите внимание, что атака может быть не целевой и все же иметь сопутствующий ущерб. Например, в 2012 году хакер по имени AnonymousOwn3r запустил DDoS-атаку против регистратора доменов GoDaddy. Атака DDoS не только сделала веб-сайт GoDaddy недоступным, но и повлияла на способность авторитетных DNS-серверов GoDaddy отвечать на запросы. Т.о., произошло ухудшение качества обслуживания клиентов GoDaddy, хотя они и не были намеченной целью.

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

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

Важно сделать все возможное, чтобы обезопасить инфраструктуру DNS от обычных атак со стороны скриптов. В то же время администраторы DNS должны внимательно следить за более опытными злоумышленниками.

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

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

Целевая атака DNS может принимать разные формы в зависимости от намерения злоумышленника. Если намерение злоумышленника состоит в том, чтобы перенаправить службы DNS от организации, то злоумышленник может даже не нацеливаться на DNS-серверы этой организации напрямую. Фактически, если злоумышленник хочет захватить домен - также известный как domain hijacking - прямая атака на DNS-серверы организации часто является последним средством.

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

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

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

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

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

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

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

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

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

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

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

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

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

Административный взлом на критически важном сервере, таком как DNS-серверы, может быть особенно коварным, поскольку он позволяет злоумышленнику контролировать части сети и перенаправлять трафик в сторону от места назначения. Меры безопасности, принятые во всей остальной сети, становятся неактуальными, потому что злоумышленник имеет доступ ко всему.

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

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

Например, злоумышленник может владеть доменом foo.com. Когда DNS-серверы запрашивают информацию о foo.com, сервер злоумышленника также отправляет неверные данные для www.amazon.com. Информация встроена в законный запрос, поэтому получающий DNS-сервер просто принимает данные и делится ими с пользователями.

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

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

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

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

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

Разработка плана безопасности DNS

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

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

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

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

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

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

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

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

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

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

Таблица 2.1 Оценка безопасности DNS

Угрозы Результаты угроз Требования безопасности Текущие методы Уязвимости
Обозначить известные угрозы для инфраструктуры DNS Наихудший сценарий, если эти угрозы эксплуатируются Лучшая политика безопасности Действующая политика безопасности Области, в которых организация уязвима

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

Таблица 2.2 Оценка безопасности DNS: использование root-эксплойтов

Угрозы Результаты угроз Требования безопасности Текущие методы Уязвимости
Root-эксплойты Могут привести к отключению всех функций DNS и разрешить злоумышленнику доступ к сети DNS-серверы должны регулярно обновляться и проверяться на известные эксплойты Нет установленного интервала для тестирования или исправления DNS-серверов Может быть слишком длительным период между выпуском эксплойта или исправления безопасности и фактическим исправлением на серверах

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

Уязвимости DNS обычно можно отнести к одной из трех категорий. Это уязвимости в дизайне, реализации или конфигурации. Проектные уязвимости - это те уязвимости, которые присущи протоколу или приложению. Например, некоторые могут счесть тот факт, что DNS использует UDP для транспорта, своего рода уязвимостью дизайна. Слабые стороны программного обеспечения DNS, такие как root-эксплойты, также считаются конструктивными уязвимостями. Еще одна уязвимость в дизайне - это неправильный мониторинг DNS-трафика, который включает как DNS-трафик, так и мониторинг изменений на уровне регистратора домена.

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

Уязвимости конфигурации являются наиболее распространенными. Эти уязвимости представляют собой административные ошибки, которые делают решение менее безопасным. Например, разрешение неограниченного доступа к данным зоны может считаться угрозой конфигурации. Другим примером может быть неправильное назначение разрешений для файлов зоны.

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

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

  1. Создать новую политику безопасности.
  2. Сохранить существующую политику.
  3. Устранить угрозы без изменения текущей политики.

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

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

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

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

Заметки

  1. CyberBunker имеет другую версию событий, CyberBunker ошибается.

  2. Хотя это может быть больше похоже на «Как удержать пользователей от перехода по очевидным фишинговым ссылкам».

Глава 3
Ошибки конфигурации DNS

Информация в этой главе

Вступление

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

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

Уязвимости DNS-сервера

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

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

Что еще хуже, когда дело доходит до безопасности, самые популярные DNS-серверы не обладают лучшей репутацией. Хотя, честно говоря, и Microsoft DNS, и BIND Консорциума интернет-систем (ISC) добились больших успехов в области безопасности за последние годы (более подробно это обсуждается в главах 6 и 7), но критические недостатки безопасности все еще обнаруживаются.

Отслеживание новых уязвимостей

Чрезвычайно важно отслеживать недостатки безопасности в программном обеспечении DNS-сервера (на самом деле, во всех приложениях, работающих в сети). К счастью, и ISC, и Microsoft позволяют легко узнавать о новых недостатках безопасности. Чтобы узнать об обновлениях безопасности в BIND ISC, посетите https://www.isc.org/downloads/software-support-policy/security-advisory/, а чтобы узнать о последних уязвимостях DNS-сервера Microsoft, посетите https://technet.microsoft.com/en-us/library/security/. И Microsoft, и ISC также имеют RSS-каналы и списки адресов электронной почты, на которые пользователи могут подписаться, чтобы узнавать о новых уязвимостях. Существует также ряд отличных сервисов, как бесплатных, так и платных, которые каталогизируют новые уязвимости и представляют их таким образом, чтобы их можно было легко внедрить в Security Information и Event Manager или Governance, Risk и Compliance server, чтобы эти объявления можно было автоматически сопоставлять и приоритизировать по сравнению с другими предупреждениями.

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

Но все же для группы безопасности DNS это кошмарный сценарий: злоумышленник получает доступ к DNS-серверу и изменяет запись A или CNAME для веб-сайта, устанавливает максимальное время жизни (TTL) для файла зоны и внезапно все посетители веб-сайта этой организации отправляются на серверы, контролируемые злоумышленником. Даже если система безопасности быстро обнаружит и устранит проблему, могут пройти дни, прежде чем весь трафик перейдет в нужное место.

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

Гораздо более распространенной формой этой атаки является простой вызов регистратора домена или компании, которая управляет записями DNS, и использование социальной инженерии, чтобы заставить их внести изменения в записи DNS. Это произошло с New York Times и несколькими другими известными веб-сайтами в 2013 году, когда злоумышленник позвонил в их регистратор доменов и обманом заставил регистраторов внести изменения в записи их соответствующих доменов, отправив посетителей на веб-сайты, контролируемые злоумышленниками.

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

Domain Name: reddit.com
Registry Domain ID: 153584275_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.gandi.net
Registrar URL: http://www.gandi.net
Updated Date: 2014-10-22T02:18:29Z
Creation Date: 2005-04-29T17:59:19Z
Registrar Registration Expiration Date: 2017-04-29T17:59:19Z
Registrar: GANDI SAS
Registrar IANA ID: 81

Приведенная выше информация сообщает злоумышленнику, что домен зарегистрирован на gandi.net. Теперь злоумышленник знает, к какому регистратору обратиться, чтобы внести изменения. Вторая часть информации whois предоставляет DNS-контакт для Reddit:

Admin Name: Domain Administrator
Admin Organization: Reddit Inc
Admin Street: 548 Market St., #16093
Admin City: San Francisco
Admin State/Province: California
Admin Postal Code: 94104-5401
Admin Country: US
Admin Phone: +1.4156662330
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: domainadmin@reddit.com

Reddit здесь умен, потому что они используют псевдоним в качестве администратора домена вместо единой точки контакта, поэтому злоумышленник не может использовать тактику «Фрэнк больше не работает в компании, я новый администратор DNS», чтобы обмануть регистратора. В любом случае, есть много хороших историй, которые стоит попробовать. В этом случае, поскольку reddit является таким популярным веб-сайтом, злоумышленник может попытаться позвонить с историей вроде «Reddit в настоящее время подвергается масштабной DDoS-атаке, поэтому мы не можем получить доступ к нашей электронной почте, но наш DDoS-провайдер требует, чтобы мы внесли изменения в наши записи DNS, чтобы они указывали на них. Не могли бы вы сделать это, мы теряем миллионы долларов каждый час, когда сайт остается недоступным». Скорее всего, сотрудник регистратора доменов не хочет нести ответственность за сохранение сайта в автономном режиме и вполне может подчиниться. Обратите внимание, что регистраторы reddit умны и внедрили меры защиты для предотвращения переводов:

Domain Status: clientTransferProhibited
http://www.icann.org/epp#clientTransferProhibited
Domain Status:

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

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

В дополнение к показанной выше защите clientTransferProhibited существует ряд мер безопасности домена, которые регистраторы домена должны реализовать. Whois на NYTimes.com теперь показывает большинство из этих мер безопасности:

Domain Status: clientUpdateProhibited
(https://www.icann.org/epp#clientUpdateProhibited)
Domain Status: clientTransferProhibited
(https://www.icann.org/epp#clientTransferProhibited)
Domain Status: clientDeleteProhibited
(https://www.icann.org/epp#clientDeleteProhibited)
Domain Status: serverUpdateProhibited
(https://www.icann.org/epp#serverUpdateProhibited)
Domain Status: serverTransferProhibited
(https://www.icann.org/epp#serverTransferProhibited)
Domain Status: serverDeleteProhibited
(https://www.icann.org/epp#serverDeleteProhibited)

Эти дополнительные коды состояния известны как коды расширяемого временного протокола (EPP). Интернет-корпорация по присвоению имен и номеров (ICANN) включила коды EPP, и они бывают двух видов: клиентские и серверные. Коды EPP сервера устанавливаются реестрами и обычно связаны с администрированием доменных имен, например, когда домен впервые зарегистрирован, но еще не активен, или когда его срок действия истек и он будет удален (возвращен в пул регистрации). Статусы клиентского EPP обычно устанавливаются регистратором по запросу клиента, хотя некоторые регистраторы устанавливают его по умолчанию.

Для групп безопасности наибольший интерес представляют клиентские статусы EPP: clientDeleteProhibited, clientTransferProhibited, clientUpdateProhibited. clientDeleteProhibited предотвращает удаление домена, даже если запрос поступает от авторизованного контакта. clientTranferProhibited предотвращает передачу домена от одного регистратора к другому, это обычная тактика среди злоумышленников, использующих социальную инженерию для получения контроля над доменом. Если домен находится в ведении другого регистратора, на устранение любого ущерба уходит значительно больше времени, чем если бы изменения были внесены, пока регистратор оставался на своем месте. Последний код EPP, clientUpdateProhibited, является наиболее серьезным. clientUpdateProhibited предотвращает внесение любых изменений в домен вообще, даже от авторизованных контактов. Каждый раз, когда законный администратор домена хочет внести изменения в домен с включенным EPP-кодом clientUpdateProhibited, он должен сначала попросить регистратора отключить код clientUpdateProhibited, используя любые процессы аутентификации, выполняемые регистратором, внести изменения в домен, а затем повторно включить clientUpdateProhibited.

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

Один из способов обойти это - делегировать поддомены серверу внутри сети. Для большинства организаций существует относительно небольшое количество изменений DNS, внесенных во внешнюю инфраструктуру, такую как веб-серверы и почтовые серверы. С другой стороны, во внутреннюю инфраструктуру могут постоянно вноситься изменения DNS. Объединяя внутреннюю инфраструктуру в субдомен (например, corp.dns-book.net), группа администрирования DNS теперь может создать субдомен с регистратором и направить записи NS для этого субдомена на внутренний сервер. Это позволяет группам безопасности и администрирования легко вносить необходимые изменения во внутренние сопоставления, не открывая DNS-сервер в Интернете. Более подробно эта тема будет рассмотрена в главе 9.

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

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

Как и домашние пользователи, большинство небольших организаций не слишком беспокоятся, если вообще беспокоятся о кэшировании DNS. Как правило, они покупают беспроводной маршрутизатор, подключают его к модему, предоставленному их поставщиком услуг Интернета (ISP), и позволяют поставщику услуг Интернета заполнить все настройки. Через 5-10 минут сеть заработает и подключится к Интернету. После первоначальной настройки к маршрутизатору больше не прикасаются.

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

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

Чтобы облегчить жизнь пользователям во время настройки, большинство производителей беспроводных маршрутизаторов предоставляют довольно простую комбинацию имени пользователя и пароля для доступа к маршрутизатору и его настройки. Комбинация выглядит примерно так: admin/admin или admin/[пустой пароль]. Это необходимо, потому что, когда компания продает миллионы девайсов в год, если бы эта компания пыталась выдать уникальные пароли для каждого маршрутизатора, предоставление уникальных паролей для каждого маршрутизатора было бы кошмаром с точки зрения логистики и поддержки. Однако большинство людей не меняют пароль по умолчанию после первого использования, поэтому злоумышленник, получивший доступ к веб-интерфейсу маршрутизатора, не имеет проблем со входом в устройство.

Легко найти

Существует ряд веб-сайтов, на которых представлены списки всех имен пользователей и паролей по умолчанию для наиболее распространенных беспроводных маршрутизаторов. Такие сайты, как Router Passwords (http://www.routerpasswords.com/) полезны для людей, которые забыли пароли к своим маршрутизаторам. Они также чрезвычайно полезны для злоумышленников, пытающихся проникнуть в сеть.

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

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

Цифровой отпечаток (fingerprinting) DNS-серверов

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

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

Эта проблема усугубляется тем, что DNS по своей конструкции относительно легко отследить. Фингерпринтинг - это запрос к серверу, чтобы определить, какое программное обеспечение и версия работает на сервере. Это обычная тактика, используемая как тестировщиками на проникновение, так и злоумышленниками для незаметного тестирования систем на предмет наличия уязвимостей, которые можно использовать.

Программное обеспечение DNS-сервера относительно легко отследить, потому что в некоторых программах DNS-серверов есть встроенные функции, позволяющие предоставить этот ответ с помощью запроса на копирование. Dig - это инструмент командной строки, доступный во всех вариантах UNIX, BSD и Linux, а также в OS X. Администраторы используют dig для устранения проблем с DNS и выявления ошибок в записях DNS. Вы также можете использовать dig, чтобы узнать, какая версия BIND работает на DNS-сервере. Для этого используется команда dig @[IP Address or Domain of Name Server] version.bind chaos txt, и она выдает примерно такой результат:

[root@server ~]# dig @127.0.0.1 version.bind chaos txt
; << >> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5_7.1 << >> @127.0.0.1
version.bind chaos txt
; (1 server found)
;; global options: printcmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 49112
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind.    CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "9.3.6-P1-RedHat-9.3.6-16.P1.el5_7.1"
;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.

Соответствующая информация находится в разделе ответов: «9.3.6-P1-RedHat-9.3.6-16. P1.el5_7.1». Это сообщает злоумышленнику, что на сервере работает BIND версии 9.3.6 в RedHat Linux. Быстрая проверка показывает, что эта версия BIND сильно устарела и для Metasploit доступен эксплойт-модуль, который может использовать известную уязвимость.

Не каждый поставщик программного обеспечения DNS-сервера принимает команду version.bind, и администраторы DNS могут даже настроить BIND так, чтобы он возвращал пустой ответ или даже помещал что-то вводящее в заблуждение в поле ответа. Более подробно это будет рассмотрено в главе 7.

В случаях, когда version.bind не работает, существуют специальные инструменты для снятия отпечатков DNS, такие как fpdns, которые можно использовать для определения того, какое программное обеспечение DNS работает на сервере. Например, Microsoft.com не использует серверы имен, на которых выполняется BIND, поэтому ни один из серверов имен не будет отвечать на запрос version.bind. Однако выполнение команды fpdns -D microsoft.com возвращает следующее:

allan@allan-1015E:/$ sudo fpdns -D microsoft.com
fingerprint (microsoft.com, 193.221.113.53): Microsoft Windows DNS 2003
fingerprint (microsoft.com, 2620:0:34:0:0:0:0:53): No match found
fingerprint (microsoft.com, 208.76.45.53): Microsoft Windows DNS 2003
fingerprint (microsoft.com, 2620:0:37:0:0:0:0:53): No match found
fingerprint (microsoft.com, 208.84.0.53): Microsoft Windows DNS 2003
fingerprint (microsoft.com, 2620:0:30:0:0:0:0:53): No match found

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

Опрос DNS

Консорциум интернет-систем (ISC) проводит два раза в год опрос хостов в Интернете (последние результаты находятся здесь: https://ftp.isc.org/www/survey/reports/current/). В ходе опроса рассматривается версия программного обеспечения DNS, работающего на хостах (текущие результаты находятся здесь: https://ftp.isc.org/www/survey/reports/current/fpdns.txt). Неудивительно, что все меньше и меньше хостов возвращают результаты, но есть еще десятки тысяч хостов, которые ISC может точно идентифицировать, причем некоторые из них работают на удивительно старых версиях программного обеспечения DNS.

Переполнение буфера, состояние гонки и выполнение с завышенными привилегиями

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

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

Хорошим примером последнего сценария является CVE-2015-6125, который повлиял на DNS-серверы Windows, работающие на серверах Windows 2008 и 2012. Уязвимость позволяла злоумышленнику отправить специально созданный пакет DNS, который приводит к сбою сервера и позволяет запускать произвольный код от имени локального системного администратора. Часто злоумышленник связывает резидентный загрузчик с переполнением буфера, и это код, который будет выполняться после успешного использования сервера. Поскольку загрузчик является резидентным только в памяти, он избегает обнаружения традиционными системами безопасности и позволяет злоумышленнику обследовать систему и решить, какой имплант установить, чтобы он оставался постоянным на скомпрометированном сервере.

Windows DNS - не единственная платформа, которая подвержена переполнению буфера. CVE-2008-0122 описывает переполнение буфера в приложениях, использующих библиотеку libbind BIND. Уязвимость существует в функции inet_network(), и в случае успеха злоумышленник сможет выполнить код на удаленной системе. В случае неудачи атака приведет к сбою сервера и его недоступности.

Другой тип уязвимости, которая может существовать в программном обеспечении DNS, - это состояние гонки. Состояние гонки возникает в многопоточном программном обеспечении, когда несколько потоков одновременно пытаются получить доступ к совместно используемым данным, и эти обращения не контролируются должным образом. Когда это происходит, второй поток обращается к той же точке данных и изменяет значение, так что действие первого потока теперь некорректно. Простой пример этого - если есть файл со значением в нем, и программа требует умножить это значение на 10 (x * 10 = y). Первый поток обращается к файлу и видит, что x = 5, поэтому обрабатывает вычисление, чтобы получить 5 * 10 = 50, но если второй поток обращается к этому файлу, в то время как первый поток обрабатывает свое уравнение и изменяет значение x на 7, тогда результат первого уравнения неверен, и возникает состояние гонки.

Примером состояния гонки в BIND является CVE-2015-8461. Состояние гонки повлияло на BIND 9.9.8 и 9.10 и возникло при сбое утверждения INSIST в resolver.c. Это сложная уязвимость для злоумышленника, потому что время должно быть безупречным, но в случае успеха атака приведет к сбою BIND.

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

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

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

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

Разработчики BIND неоднократно сталкивались с этой проблемой много лет назад до такой степени, что во многих дистрибутивах Linux теперь есть пользователь BIND с именем named, созданный по умолчанию, и рекомендуют, чтобы этот пользователь был предназначен для запуска указанного процесса. Разработчики BIND также рекомендуют запускать BIND в среде chroot. Среда chroot, обычно называемая chroot jail, изменяет корневой каталог на указанный путь. Приложения, работающие в этой chroot-jail, не могут получить доступ ни к чему за пределами указанного пути. Цель chroot jail - ограничить ущерб, который злоумышленник может нанести, если получит удаленный доступ к системе. Да, она потенциально может повредить установку BIND, но не может получить доступ к чему-либо еще на сервере.

Человеческие ошибки

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

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

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

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

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

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

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

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

aliska-mbpr:~ allan.liska$ dig dns-book.net SOA
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 850
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;dns-book.net.    IN SOA
;; ANSWER SECTION:
dns-book.net. 3600 IN SOA dns1.name-services.com. info.name-services.com. 1447308739 172800 900 1814400 3600

Обратите внимание: приведенный выше серийный номер - 1447308739, если в файл зоны для dns-book.net вносятся изменения, файл зоны должен быть обновлен как минимум до 1447308740. Многие администраторы DNS упрощают свою жизнь, используя формат даты, поэтому новая зона, зарегистрированная сегодня, будет начинаться с 20160421, и если изменение будет сделано через неделю после сегодняшнего дня, новый серийный номер будет 20160428. Это помогает отслеживать, когда в последний раз производилось изменение файла зоны, и легко поддерживать постепенное изменение чисел.

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

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

Это не то, что случается часто, но в конечном итоге это происходит, когда домены начинают стареть. Через десять-пятнадцать лет после первой регистрации домена организация может сменить поставщика услуг или перенести инфраструктуру в новый центр обработки данных и будет вынуждена переназначить IP-адреса своих серверов. Во время этого процесса файл зоны может быть обновлен должным образом, но регистратор все еще будет иметь старую информацию для сопоставления IP-адреса с доменом (быстрая проверка whois обычно подтверждает это). Это приводит к тому, что информация о домене не распространяется должным образом между рекурсивными серверами имен, и это может привести к тому, что сеть, электронная почта и другие службы организации будут недоступны в течение 72 часов, пока реестр обновляется новой информацией.

Другая проблема, хотя и менее распространенная, при редактировании файла зоны - неправильное управление записями CNAME. Записи CNAME - отличные ресурсы для управления информацией DNS, особенно с серверами, которые выполняют несколько функций. Например, если организация размещает информацию HTTP, FTP и RSS на одном сервере, имеет смысл создать запись A для субдомена www и записи CNAME для субдоменов ftp и rss. Однако использование CNAME для записей MX или NS, даже если все они указывают на один и тот же сервер, не одобряется, и многие DNS-серверы отклоняют эти запросы. Кроме того, не следует указывать записи CNAME на другие записи, которые сами по себе являются записями CNAME, поскольку это, как известно, приводит к образованию кротовых нор, разрывающих Интернет. Результат не столь серьезен, но он может создать уродливый цикл, с которым некоторые рекурсивные DNS-серверы плохо справляются.

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

Выводы

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

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

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

Глава 4
Внешние эксплойты DNS

Информация в этой главе

Вступление

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

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

В защиту исследователей безопасности

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

Отравление кэша

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

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

Это запрос пользователя:

[user@workstation ~]# host dns-book.net
dns-book.net has address 8.5.1.36
dns-book.net mail is handled by 10 p.nsm.ctmail.com.

Это часть того, что видит рекурсивный DNS-сервер:

[root@server data]# tcpdump -n udp port 53 -v
03:05:05.199542 IP (tos 0x0, ttl 64, id 13085, offset 0, flags [none], proto: UDP (17), length: 73) 192.168.1.15.29092 > 98.124.192.1.domain: 33955 [1au] A? www.dns-book.net. (45)
03:05:05.212049 IP (tos 0x0, ttl 53, id 3897, offset 0, flags [none], proto: UDP (17), length: 201) 98.124.192.1.domain > 192.168.1.15.29092: 33955*- 1/5/1 www.dns-book.net. A 8.5.1.36 (173)
03:05:05.220014 IP (tos 0x0, ttl 64, id 64355, offset 0, flags [none], proto: UDP (17), length: 73) 192.168.1.15.34388 > 98.124.194.1.domain: 63645 [1au] MX? www.dns-book.net. (45)
03:05:05.232466 IP (tos 0x0, ttl 53, id 13094, offset 0, flags [none], proto: UDP (17), length: 214) 98.124.194.1.domain > 192.168.1.15.34388: 63645*- 1/5/1 www.dns-book.net. MX[|domain]

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

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

03:05:05.212049 IP (tos 0x0, ttl 53, id 3897, offset 0, flags [none], proto: UDP (17), length: 201) 98.124.192.1.domain > 192.168.1.15.29092: 33955*- 1/5/1 www.google.com A 8.5.1.40 (173)

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

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

Хотя вышеупомянутый тип атаки с отравлением кеша практически отсутствует на данный момент, другие типы атак с отравлением кеша все еще происходят. В феврале 2015 года исследователи RSA раскрыли атаку на транзакции Boleto, в которой использовалось отравление кеша DNS. Boleto - распространенный способ оплаты в Бразилии. Фактически, Boleto настолько популярен, что на него приходится почти 25% всех платежных транзакций в Бразилии. На самом деле существует семейство вредоносных программ под названием Bolware, специально предназначенных для транзакций Boleto.

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

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

Открытые рекурсивные DNS-серверы

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

Чтобы понять, как работает этот тип отравления кеша, сначала необходимо понять DNS на уровне пакетов. Пакет DNS состоит из трех частей: заголовка, вопроса и ответа (на самом деле это немного сложнее, но это хорошая отправная точка). Заголовок имеет фиксированный размер 12 байтов, в то время как разделы вопросов и ответов различаются по размеру. Поскольку большинство запросов и ответов DNS выполняются через UDP, существует ограничение на размер пакета в 512 байт. Кроме того, поскольку DNS и ответы используют UDP, между рекурсивным и авторитетным серверами имен отсутствует рукопожатие. Вместо этого DNS-сервер полагается на комбинацию исходного порта, исходного IP-адреса назначения и 16-битного идентификатора транзакции для проверки входящего ответа.

Чтобы понять, как это работает, взгляните на следующий запрос/ответ:

11:14:20.316430 IP (tos 0x0, ttl 64, id 35386, offset 0, flags [none], proto: UDP (17), length: 74) 192.168.1.15.16271 > 208.76.58.196.domain: 14324 [1au] A? www.cryptodns.com. (46)
11:14:20.397637 IP (tos 0x0, ttl 54, id 20874, offset 0, flags [none], proto: UDP (17), length: 196) 208.76.58.196.domain > 192.168.1.15.16271: 14324*- 2/4/1 www.cryptodns.com. CNAME cryptodns.com., cryptodns.com. (168)

Первая строка - это запрос от рекурсивного сервера имен. Запрос запрашивает запись A для домена www.cryptodns.com. Запрос имеет идентификатор транзакции 14324, порт источника 16271 и был отправлен на IP-адрес 208.76.58.196. Вторая строка, содержащая ответ на запрос, содержит правильный исходный IP-адрес, отправленный на соответствующий порт, и соответствующий идентификатор транзакции, помеченый звездочкой. В области DNS тот факт, что эти три вещи совпадают, указывает на то, что ответ правильный.

Подделать пакет DNS относительно просто; на самом деле существует ряд инструментов, которые помогают злоумышленникам создать поддельный пакет DNS, и, поскольку протокол доставляется с использованием UDP, подделка IP-адреса является тривиальной задачей. Мощный инструмент для подделки DNS и других пакетов - это hping3. Используя hping3, злоумышленник может сгенерировать поддельные DNS-пакеты, которые выглядят так, как будто они приходят со случайных адресов:

[root@server ~]# hping3 -2 -p 53 --rand-source 8.8.8.8

Эта команда указывает hping3 отправлять DNS-пакеты со случайно подделанных IP-адресов на сервер имен 8.8.8.8. Трафик, генерируемый этой командой, выглядит так:

11:25:59.915754 IP (tos 0x0, ttl 64, id 50693, offset 0, flags [none], proto: UDP (17), length: 28) 184.134.243.10.qip-msgd > 8.8.8.8.domain: [udp sum ok] [|domain]
11:26:00.915799 IP (tos 0x0, ttl 64, id 47876, offset 0, flags [none], proto: UDP (17), length: 28) 20.110.55.234.mti-tcs-comm > 8.8.8.8. domain: [udp sum ok] [|domain]
11:26:01.915877 IP (tos 0x0, ttl 64, id 8542, offset 0, flags [none], proto: UDP (17), length: 28) 174.5.167.152.taskman-port > 8.8.8.8.domain: [udp sum ok] [|domain]

Кажется, что каждый из запросов поступает с разных IP-адресов. Чтобы сделать эту функцию более полезной, трафик должен выглядеть так, как будто он исходит от авторитетного сервера имен. Используя информацию cryptodns.com из предыдущего примера, hping3 может создать поддельный пакет, который, по всей видимости, исходит от авторитетного DNS-сервера для cryptodns.com. Команда выглядит так:

[root@server ~]# hping3 -2 -p 53 --spoof 208.76.58.196 192.168.1.15

И итоговый трафик выглядит так:

11:42:21.136079 IP (tos 0x0, ttl 64, id 45091, offset 0, flags [none], proto: UDP (17), length: 28) 208.76.58.196.1775 > 196 192.168.1.15. domain: [|domain]
11:42:22.136132 IP (tos 0x0, ttl 64, id 56073, offset 0, flags [none], proto: UDP (17), length: 28) 208.76.58.196.femis > 196 192.168.1.15. domain: [|domain]
11:42:23.136178 IP (tos 0x0, ttl 64, id 30499, offset 0, flags [none], proto: UDP (17), length: 28) 208.76.58.196.powerguardian > 196 192.168.1.15.domain: [|domain]

Итак, первая часть работы сделана: IP-адрес подделан. Однако злоумышленнику по-прежнему необходимо определить случайный исходный порт и идентификатор транзакции. До 2008 года первая часть была простой: многие резолверы DNS повторно использовали один и тот же исходный порт для всех транзакций DNS; некоторые администраторы DNS даже устанавливают порт источника 53. Фактически, в BIND все еще есть опция конфигурации для жесткого кодирования порта источника. К счастью, эта функция используется редко.

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

Удивительно, но благодаря парадоксу дня рождения это не так. Парадокс дня рождения утверждает, что в комнате на 23 человека существует вероятность 50%, что e двоих людей в этой комнате день рождения совпадает, процент возрастает до 99,9% в комнате на 75 человек. Математика, лежащая в основе этого, связана с комбинациями и перестановками и выходит за рамки этой книги[1]. Используя ту же математику, в большинстве случаев злоумышленнику нужно будет отправить только 700 пакетов, прежде чем совпадет порт источника.

Тем не менее, это не очень хорошие шансы, однако есть способы еще больше их улучшить. Один из наиболее распространенных способов - злоумышленник инициирует несколько запросов для несуществующих поддоменов. Например, если злоумышленник хочет отравить кеш для домена www.dns-book.net, он может создать список из сотен случайных поддоменов, таких как следующие:

Затем злоумышленник будет запрашивать целевой рекурсивный сервер с каждым из этих запросов по одному, что заставит рекурсивный сервер постоянно обращаться к авторитетному серверу для ответа, пока он не найдет совпадение. В то же время злоумышленник отправит тысячи поддельных пакетов на рекурсивный сервер, надеясь превзойти ответ с соответствующим идентификатором транзакции от полномочного сервера на один из запросов. В этом прелесть атаки: атакующему нужно получить только одно совпадение. Каждый из поддельных ответов содержит дополнительную запись ресурса (RR), которая сопоставляет www.dns-book.net с сервером, контролируемым злоумышленником. На рис. 4.1 показано поле Additional RRs, которое является частью каждого ответа DNS, хотя и не всегда заполняется. Любое успешное попадание отравит кеш для www.dns-book.net и направит весь трафик на сервер, контролируемый злоумышленником. Это еще раз подчеркивает важность отказа от открытого резолвера. Атаку с отравлением кеша провести намного сложнее, если злоумышленник не может отправить запросы на целевой рекурсивный сервер.

Рисунок 4.1 Структура пакета DNS.

Другой тип атаки с отравлением кеша DNS - это атака с отравлением локального кеша DNS. Эта атака не затрагивает рекурсивный DNS-сервер жертвы; скорее он заражает кеш DNS непосредственно на рабочей станции жертвы.

Большинство людей не знают, что по умолчанию рабочие станции Microsoft Windows и Apple OS X поддерживают локальный кеш DNS на основе ответов настроенного рекурсивного сервера. Локальный кеш ускоряет процесс посещения часто запрашиваемых доменных имен. К сожалению, это тоже тривиальный вектор атаки. Чтобы узнать, что находится в локальном кэше на рабочей станции Microsoft Windows, нужно использовать команду ipconfig/displaydns. Ниже приведен фрагмент образца выходных данных при выполнении этой команды.

C:\Documents and Settings > ipconfig /displaydns
Windows IP Configuration

    fileserver
    ----------------------------------------
    Record Name . . . . . : fileserver
    Record Type . . . . . : 1
    Time To Live . . . . : 562795
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 192.168.1.10
    www.dns-book.net
    ----------------------------------------
    Record Name . . . . . : www.cryptodns.com
    Record Type . . . . . : 5
    Time To Live . . . . : 562795
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    CNAME Record . . . . : cryptodns.com

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

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

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

Отравление локального кэша

Существует несколько способов, которыми злоумышленник может отравить локальный кеш на машине жертвы, но одним из наиболее распространенных методов является использование недокументированного интерфейса прикладного программирования (API) DNS на компьютерах с Microsoft Windows. Любое приложение, которое хочет взаимодействовать с базовой операционной системой Windows, должно использовать вызовы API к Windows. Эти API-интерфейсы позволяют приложению взаимодействовать с операционной системой независимо от используемого языка программирования. Большинство вызовов Windows API хорошо документированы, но есть много разных API, для которых вообще нет документации. Разработчики вредоносных программ часто играют с этими API-интерфейсами, чтобы определить, какие изменения они могут внести в базовую операционную систему с помощью конкретного вызова API. В случае отравления кэша DNS на локальном хосте недокументированные вызовы DNS API, такие как DnsAddRecordSet_A, позволяют вредоносным программам (и законным программам) добавлять записи в локальный кэш на рабочей станции жертвы.

Кеширование в веб-браузере

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

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

Подмена DNS

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

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

Во все версии операционной системы Microsoft Windows встроен файл с именем hosts. Файл находится в каталоге C:\%windir%\system32\drivers\etc\hosts (системы Linux, Unix и Apple OS X также имеют этот файл, в случае этих операционных систем он находится в /etc/hosts) и используется для сопоставления IP-адресов с именами систем или доменами. Файл представляет собой возврат к дням, предшествовавшим существованию DNS, и он обеспечивает связь между машинами в сети независимо от того, настроен DNS или нет. Типичный файл hosts выглядит так:

# Copyright (c) 1993-1999 Microsoft Corp.

#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
127.0.0.1 localhost

Это стандартный файл hosts, все, что он делает, это сопоставляет адрес обратной связи с localhost, что позволяет машине разговаривать сама с собой. Win32.QHOST модифицирует файл hosts, чтобы он выглядел как следующий фрагмент:

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
127.0.0.1 localhost
127.0.0.1 symantec.com
127.0.0.1 f-secure.com
127.0.0.1 kaspersky.com
127.0.0.1 liveupdate.symantec.com
127.0.0.1 mcafee.com

Новый файл hosts теперь указывает доменам наиболее распространенных поставщиков средств безопасности на адрес обратной связи, не позволяющий этим приложениям безопасности получать обновления сигнатур или сообщать о подозрительной активности. В целом Win32.QHOST создает более 40 различных записей в файле hosts и эффективно отключает все или часть любого приложения безопасности, работающего на хосте.

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

Другим примером подмены DNS является вредоносная программа DNSChanger, созданная группой Rove Digital и широко использовавшаяся в период с 2007 по 2015 год. Вредоносная программа DNSChanger изменяла рекурсивные DNS-серверы на машине жертвы на хосты, которые контролировались злоумышленниками. В случае DNSChanger злоумышленники использовали свои рекурсивные DNS-серверы для отображения рекламы и перенаправления жертв на сайты, которые платили Rove Digital плату за рекламу.

В 2014 году группа злоумышленников попробовала еще один вариант этой атаки. Атака, получившая название «Poisoned Hurricane» исследователями FireEye, которые ее раскрыли, включала двухэтапный процесс. На первом этапе злоумышленники обнаружили, что авторитетные DNS-серверы поставщика центра обработки данных Hurricane Electric позволяют пользователям вводить записи для любого хоста, даже для хостов, для которых сервер имен не является авторитетным. Например, злоумышленник смог ввести запись A для www.adobe.com и указать запись A на инфраструктуру, принадлежащую злоумышленнику.

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

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

Одним из инструментов, который можно использовать для этого типа атак, является dnsspoof. Инструмент dnsspoof является частью набора инструментов для тестирования на проникновение dnsniff, он также доступен как часть дистрибутива Kali Linux для тестирования на проникновение. Dnsspoof предоставляет готовый инструмент для спуфинга DNS-трафика. Первый шаг - отредактировать файл конфигурации dnsspoof, расположенный в /etc/dnsspoof.conf. Формат файла такой же, как формат файла /etc/hosts. Перенаправление для Facebook будет выглядеть примерно так:

www.facebook.com [Attacker Controlled IP Address]

После создания файла конфигурации команда для запуска dnsspoof проста:

dnsspoof -i [Interface] -f /etc/dnsspoof.conf

Приведенная выше команда указывает dnsspoof искать любые DNS-запросы для www.facebook.com, и отвечать поддельными запросами с указанием целей на IP-пространство, контролируемое злоумышленником. Все, что нужно сделать злоумышленнику, - это опередить ответ реального рекурсивного сервера, что не должно быть слишком сложным, если две машины находятся в одной сети.

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

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

DDoS-атаки с использованием DNS

Категория DNS-атак, которая получает наибольшее освещение в прессе, - это распределенный отказ в обслуживании (DDoS). Несмотря на то, что существует ряд различных способов проведения DDoS-атаки, протоколы на основе UDP, такие как DNS и Network Time Protocol, особенно подвержены злоупотреблениям при атаке. Поскольку UDP-пакеты легко подделать, относительно легко заставить небольшую группу машин направлять большой объем трафика к целевой системе таким образом, чтобы его было трудно заблокировать.

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

Существует ряд инструментов, которые можно использовать для запуска этого типа прямой DDoS-атаки, вероятно, одним из самых известных является Low Orbit Ion Cannon (LOIC). LOIC был первоначально разработан в 2004 году и использовался в ряде успешных DDoS-кампаний против Церкви Саентологии, Ассоциации звукозаписывающей индустрии Америки и сыграл большую роль в операции Payback (Расплата), в ходе которой ряд организаций подвергся нападению из-за их противодействия WikiLeaks.

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

Чтобы упростить использование LOIC, в 2012 году его разработчики выпустили вариант программы под названием LOIC Hive Mind, который позволял конечному пользователю подключаться к каналу IRC или RSS-каналу для загрузки последнего набора целей. Эта версия LOIC была успешно использована во время операции Megaupload в 2012 году.

В отличие от DDoS-атаки, управляемой ботнетом, пользователи LOIC знают о том, что инструмент установлен на их настольных компьютерах, и намеренно участвуют в DDoS-атаке против организации, с которой у них возникли разногласия.

Как упоминалось ранее, LOIC - это универсальный инструмент DDoS. Как показано на рис. 4.2, инструмент можно использовать для запуска DNS- или HTTP-атак, а также для атаки на любой протокол. Интерфейс просто загружает URL или IP-адрес целевого хоста, выбирает протокол и тип пакета, а также размер сообщения. Как только все это загружено, нажмите кнопку атаки, и он будет продолжать отправлять пакеты, пока злоумышленник не остановит атаку.

Рисунок 4.2 Скриншот LOIC.

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

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

Чтобы понять, как работают эти атаки, взгляните на этот запрос dig:

dig @PDNS-PUBLIC-NS1.POWERDNS.COM powerdns.com ANY +dnssec

Запрос довольно простой; он просит сервер имен Power DNS предоставить все известные записи для домена powerdns.com. Запрос также запрашивает любую информацию DNSSEC. При 17 байтах запрос небольшой, как показано в этом выводе tcpdump:

0:41:56.231234 IP (tos 0x0, ttl 53, id 37793, offset 0, flags [ + ], proto: UDP (17), length: 1500) 188.166.104.87.domain > 192.168.1.15.49890: 57446*-| q: ANY? powerdns.com. 14/0/1 powerdns.com. Type46[|domain]

Однако он возвращает большой ответ, вывод dig показывает, что полученный ответ переключился на TCP и вернул 2977 байт.

;; Query time: 82 msec
;; SERVER: 188.166.104.87#53(188.166.104.87)
;; WHEN: Mon Feb 1 00:41:56 2016
;; MSG SIZE rcvd: 2977

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

Запрос ANY

Исследователи безопасности и администраторы DNS любят ANY запросы, особенно с учетом того, что почти каждый администратор DNS ограничивает запросы на передачу полной зоны (AXFR). Однако запрос ANY не является фактическим типом запроса, определенным в RFC 1035. Вместо этого тип запроса 255 представляет собой подстановочный запрос, предназначенный для предоставления информации, которую обычно предоставляет ANY запрос. Существует веский аргумент в пользу того, что, как и тип запроса AXFR, тип запроса ANY должен быть ограничен. Для многих администраторов DNS и специалистов по безопасности потенциал DDoS-атак с использованием результатов ANY запроса перевешивает преимущества использования типа запроса ANY при устранении неполадок или исследовании проблем DNS.

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

[root@server ~]# dig @P50.116.23.211 powerdns.com ANY +dnssec

Следующий шаг - захватить фактический пакет, сгенерированный запросом, с помощью инструмента захвата пакетов, такого как tcpdump, и поместить его в файл, в данном случае с именем query.txt:

0x0000: 4500 0045 db59 0000 4011 bb65 c73a d267 E..E.Y..@..e.:.g
0x0010: 3274 17d3 e21d 0035 0031 b2f3 d596 0100 2t.....5.1......
0x0020: 0001 0000 0000 0001 0870 6f77 6572 646e .........powerdn
0x0030: 7303 636f 6d00 00ff 0001 0000 2908 0000 s.com.......)...
0x0040: 0080 0000 00 .....

Наконец, запустите команду hping3:

[root@server ~]# hping3 -2 -p 53 -E /root/query.txt -d 40 --spoof 98.124.192.1

Конечный результат в выводе tcpdump выглядит так:

10:12:23.246849 IP (tos 0x0, ttl 64, id 20299, offset 0, flags [none], proto: UDP (17), length: 68) 98.124.192.1.docstor > 50.116.23.211. domain: [udp sum ok] 30565 zoneInit [b2&3 = 0x7264] [867a] [28275q] [28525n] Type256 (Class 41)? [|domain]

Что сделала команда hping3, так это взяла запрос dig и запустила его так, чтобы он выглядел так, как будто он исходил с IP-адреса 98.124.192.1 (один из авторитетных серверов имен для dns-book.net). Запрос на двоичный поиск, переданный через открытый резолвер, 50.116.23.211, на авторитетные серверы имен для powerdns.com и большой ответ был отправлен на 98.124.192.1. Чтобы усложнить атаку, злоумышленник может предоставить hping3 большой список открытых резолверов и рандомизировать, через какой из них проходит каждый запрос. На рис. 4.3 показан поток трафика атаки.

Рисунок 4.3. Поток трафика при атаке с усилением и отражением DNS.

Создание ботнета, способного вывести из строя большой сервер или несколько больших серверов, требует времени - если у злоумышленника даже есть для этого навыки. К счастью, уже есть большие ботнеты, созданные другими людьми. Вместо того чтобы пытаться создать и координировать большой ботнет для запуска DDoS-атаки, некоторые злоумышленники предпочитают арендовать ботнет. Согласно одному исследованию, ботнет можно арендовать менее чем за 40 долларов в месяц[2].

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

Использование DNS как канала управления и контроля (C&C) или канала эвакуации

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

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

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

Типичная атака начинается с какой-то полезной нагрузки. Она может быть встроена в документ PDF или Microsoft Office, который злоумышленник отправляет жертве по электронной почте, или это может быть вредоносный файл Flash или JavaScript, который злоумышленник встроил на веб-сайт, или это может быть код, использующий уязвимость в самом веб-браузере. Когда жертва щелкает ссылку или открывает файл (или иногда просто устанавливает вредоносное приложение, потому что письмо сообщило ему об этом), запускается легкий, часто резидентный, загрузчик. Этот загрузчик просканирует систему и отправит запрос в инфраструктуру, принадлежащую злоумышленнику (называемую инфраструктурой управления и контроля, или инфраструктурой C&C), и более мощная вредоносная программа будет автоматически загружена и установлена. Загрузчик удаляет себя, и вредоносная программа берет на себя остальную часть атаки. Но, злоумышленник должен иметь возможность связи с вредоносным ПО, установленным на машине жертвы. Поскольку большинство организаций не разрешают прямую связь с рабочими станциями внутри своей сети, вредоносному ПО требуется способ обратного вызова в инфраструктуру C&C злоумышленника.

Чтобы понять, как это работает, давайте вернемся назад и посмотрим на традиционные механизмы C&C для вредоносных программ. На заре разработки вредоносных программ подойдет любой канал связи, злоумышленники часто использовали Internet Relay Chat (IRC), потому что его было легко написать по сценарию и не требовалось устанавливать выделенный сервер или управлять инфраструктурой. Злоумышленник просто запрограммировал бы то, что он хотел, чтобы вредоносная программа выполняла при следующем вызове, и вредоносная программа звонила каждые несколько минут или часов, чтобы доставить результаты последней задачи и получить новые инструкции.

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

Подобно тому, как службы безопасности смогли развиваться, чтобы реагировать на методы злоумышленников, злоумышленники смогли найти другие способы управления, которые были более эффективными. Наиболее распространенный метод C&C, используемый сегодня, - это обратный вызов через HTTP или HTTPS. Раньше для этого требовалось настроить инфраструктуру хостинга и поддерживать постоянное присутствие в Интернете, хотя некоторые злоумышленники придумали, как использовать существующие сайты, такие как Twitter, GitHub и даже Gmail, в качестве инфраструктуры C&C.

Опять же, группы безопасности эволюционировали, чтобы победить, хотя и не всегда успешно, этот тип связи C&C. Черные списки IP-адресов и доменных имен, веб-прокси, проверка SSL и межсетевые экраны нового поколения - все это полезно для выявления и прекращения связи вредоносных программ с инфраструктурой C&C через HTTP или HTTPS.

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

Действия DNS C&C на первый взгляд выглядят как стандартный трафик DNS, как показано на рис. 4.4. Вредоносная программа отправляет DNS-запрос, который проходит через рекурсивный сервер машины жертвы на авторитетный сервер, контролируемый злоумышленником. В запрос DNS встроен либо запрос на регистрацию, либо обновление статуса, а в ответ встроен следующий набор инструкций для вредоносной программы. Вредоносная программа перехватывает ответ DNS, когда он достигает машины жертвы, и выполняет следующий набор инструкций.

Рисунок 4.4 Поток трафика связи DNS C&C.

Чтобы продемонстрировать, как это работает, давайте взглянем на ныне практически не существующую вредоносную программу DNSTrojan. DNSTrojan был очень активен в 2010 и 2011 годах, но с тех пор в значительной степени утих. DNSTrojan - это разновидность вредоносного ПО, обычно называемого «Fake AV». Fake AV - это программы, которые выдают себя за приложения безопасности, но на самом деле занимаются вредоносной деятельностью. Чаще всего они устанавливаются, потому что жертва наталкивается на всплывающее окно во время серфинга в Интернете, которое сообщает им, что на их компьютере имеется серьезное заражение, и они должны загрузить этот «инструмент безопасности», чтобы исправить это. Конечно, вместо того, чтобы загружать инструмент безопасности, жертва упрощает жизнь злоумышленнику, устанавливая для него вредоносное ПО.

Вредоносная программа DNSTrojan использовала домен httpdsconfig.com (срок действия которого с тех пор истек). После установки DNSTrojan будет обращаться к одному из нескольких поддоменов, связанных с httpdsconfig.com. Одним из поддоменов был 1284726148.httpdsconfig.com, хотя было по крайней мере семь различных поддоменов, все они основывались на числах.

Вредоносная программа на рабочей станции будет делать стандартный запрос TXT, а рабочая станция жертвы получит стандартный ответ TXT, все с использованием обычных каналов DNS. Запись DNS TXT, как определено в RFC 1035, представляет собой RR, который содержит описательный текст произвольной формы. Исторически записи TXT использовались для предоставления удобочитаемой информации о сервере, сети или домене, но сегодня они не являются обычным явлением. Запрос или ответ TXT может содержать до 255 символов.

В случае вредоносного ПО DNSTrojan запрос и ответ TXT были хешированными ответами, которые выглядели примерно так, с веб-сайта abuse.ch[3]:

a0dfe9b34e6c3bc167fc890a20dc283ab8c397eed489f2f737efceb0064fbba77dc71472b59dde25a2f6f1883ffdc3b1f5ec91caf610f02c3b85e8cb831f81e554a83706c8849dd4cfa9ef0c205c87f5e93f7a5323e71e35d566fe9fc8916717f69304

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

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

Конечно, эти типы атак продолжают развиваться. В конце 2015 года исследователи FireEye обнаружили вредоносное ПО под названием DUCKWALK, которое использовало запросы и ответы CNAME в качестве механизма C&C. Запись CNAME - это каноническое имя, которое служит псевдонимом для записи. Например, dns-book.net и www.dns-book.net оба могут указывать на один и тот же IP-адрес, вместо того, чтобы создавать две записи A, администратор DNS просто создает запись A для dns-book.net и CNAME для www.dns-book.net. Это упрощает жизнь, потому что в будущем нужно будет обновлять только одну запись.

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

6IFGEKEAANOPCNRXWRJNPXKPSORORWROOPOVJVIJIRWOROOQSQXORWO.corp.dns-book.net

И ответ может содержать что-то вроде этого:

4IDZOKFAANOPKVJURIVKLQVKTKOKOQOOOKSSMPMWMWMOOPXLLOQXI.ns.corp.dns-book.net

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

Эти же методы можно использовать для эксфильтрации данных из сети. Путем объединения нескольких запросов TXT или CNAME хешированный файл или файлы можно разделить и отправить обратно на C&C сервер по 512 байтов за раз. Конечно, если организация не ведет тщательный мониторинг DNS, к каждому запросу можно добавить больше данных, и рекурсивный DNS-сервер переключит все на запросы TCP. Опасность использования DNS в качестве канала для кражи данных заключается в том, что для этого обычно требуется много запросов, что повышает вероятность обнаружения злоумышленника.

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

В подобных случаях злоумышленник может использовать DNS-туннелирование для создания Telnet- или SSH-соединения через DNS-каналы. DNS-туннелирование позволяет злоумышленнику инкапсулировать другой протокол в обычный DNS-трафик. Например, при использовании DNS-туннелирования Telnet, который использует TCP-пакеты через порт 23, может быть отправлен через DNS. Протокол и порт не меняются; вместо этого они инкапсулируются в трафик DNS. Это похоже на то, как трафик пересылается через виртуальную частную сеть (VPN). Большая разница между DNS-туннелированием и VPN-трафиком заключается в том, что DNS-туннелирование не шифрует трафик.

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

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

Не только для рабочих станций

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

Выводы

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

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

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

Заметки

  1. Великолепное описание парадокса дня рождения со всей необходимой математикой доступно на веб-сайте Better Explained: http://betterexplained.com/articles/understanding-thebirthday-paradox/.

  2. Seebacher, N., 2015. You Can Bring Down a Website for $38. CMS Wire. Simpler Media Group, Inc., 9 June 2015. Web. 11 Oct. 2015. <http://www.cmswire.com/information-management/you-can-bring-down-a-website-for-38/>.

  3. Bernet, M., 2010. New Dropper Uses DNS to Communicate. abuse.ch. abuse.ch, 21 Sept. 2010. Web. 10 Dec. 2015. <https://www.abuse.ch/?p=2740>.

Глава 5
DNS-разведка

Информация в этой главе

Вступление

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

WHOIS

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

Сначала краткий обзор терминологии. Каждый домен верхнего уровня (TLD) управляется реестром; например, Verisign управляет доменом .com. Когда пользователь покупает домен, он часто проходит через регистратора, такого как GoDaddy. Регистратор заключает соглашение с реестром об отправке обновлений домена и соблюдении их политик. Человек, покупающий домен, обычно называется регистрантом.

При покупке домена регистратор собирает контактные данные владельца и технического оператора сайта. Интернет-корпорация по присвоению имен и номеров (ICANN) обычно требует от регистраторов сделать эту информацию доступной через службу WHOIS, работающую на TCP-порте 43. Сам протокол описан в RFC 3912. Например, запрос icann.org показывает следующий результат:

$ whois -h whois.pir.org icann.org
Domain Name: ICANN.ORG
Domain ID: D2347548-LROR
WHOIS Server:
Referral URL: http://www.godaddy.com
Updated Date: 2015-07-07T17:37:26Z
Creation Date: 1998-09-14T04:00:00Z
Registry Expiry Date: 2017-12-07T17:04:26Z
Sponsoring Registrar: GoDaddy.com, LLC
Sponsoring Registrar IANA ID: 146
Domain Status: clientDeleteProhibited
https://www.icann.org/epp#clientDeleteProhibited
Domain Status: clientRenewProhibited
https://www.icann.org/epp#clientRenewProhibited
Domain Status: clientTransferProhibited
https://www.icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited
https://www.icann.org/epp#clientUpdateProhibited
Domain Status: serverDeleteProhibited
https://www.icann.org/epp#serverDeleteProhibited
Domain Status: serverRenewProhibited
https://www.icann.org/epp#serverRenewProhibited
Domain Status: serverTransferProhibited
https://www.icann.org/epp#serverTransferProhibited
Domain Status: serverUpdateProhibited
https://www.icann.org/epp#serverUpdateProhibited
Registrant ID: CR12376439
Registrant Name: Domain Administrator
Registrant Organization: ICANN
Registrant Street: 12025 Waterfront Drive
Registrant Street: Suite 300
Registrant City: Los Angeles
Registrant State/Province: California
Registrant Postal Code: 90094-2536
Registrant Country: US
Registrant Phone: <removed>
Registrant Phone Ext:
Registrant Fax: <removed>
Registrant Fax Ext:
Registrant Email: <removed>
Admin ID: CR12376441
Admin Name: Domain Administrator
Admin Organization: ICANN
<abbreviated>
Tech ID: CR12376440
Tech Name: Domain Administrator
Tech Organization: ICANN
<abbreviated>
Name Server: NS.ICANN.ORG
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
Name Server: C.IANA-SERVERS.NET
DNSSEC: signedDelegation
>> > Last update of WHOIS database: 2016-03-09T21:06:11Z << <

Обратите внимание, что авторы удалили некоторую информацию из вышеприведенного вывода, такую как имена и номера телефонов, хотя все это общедоступно. Это предоставляет три категории информации: контактные данные, серверы имен и метаданные о записи. Из этого можно узнать его местонахождение в Лос-Анджелесе и то, что он использует Службу присвоения номеров Интернета (IANA) для запуска своих серверов имен. Флаги «Domain Status» могут указывать на проблемы с регистрацией. Строки со статусами «client» устанавливаются регистратором, а статусы с пометкой «server» - реестром. Если реестр отмечает домен, это часто происходит из-за судебного спора[1]. В этом случае, поскольку это домен, связанный с самим реестром, он, вероятно, предотвращает случайное изменение.

Как узнать, какой сервер WHOIS запрашивать для данного домена? Хорошее место для начала - это сервер WHOIS для реестра этого TLD, который обычно можно найти, запросив <tld>.whois-servers.net. Например, org.whois-servers.net указывает на whois.publicinterestregistry.net, который является тем же сервером, что и в приведенном выше примере. Некоторые TLD, включая .org, используют так называемую толстую модель данных, то есть в реестре будут храниться все записи. TLD .com использует тонкую модель данных, то есть реестр может включать только ссылку на сервер Whois соответствующего регистратора. Например, запрос icann.org на другом сервере whois вернет ссылку на whois.pir.org:

$ whois -h whois.iana.org icann.org
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
refer: whois.pir.org
domain: ORG
organisation: Public Interest Registry (PIR)
address: 1775 Wiehle Avenue
address: Suite 102A
address: Reston Virginia 20190
address: United States
(remainder of the response is not included)

Обратите внимание, что указанная здесь организация и адрес принадлежат серверу WHOIS, а не запрашиваемому домену. После реферера и запроса на whois.pir.org можно будет увидеть полный ответ, показанный ранее.

Многие регистраторы предлагают «частную регистрацию», иногда за дополнительную плату, когда они указывают свои собственные контактные данные вместо информации о регистранте. Пример из домена dns-book.net (зарегистрирован авторами):

Domain Name: DNS-BOOK.NET
Registry Domain ID: 1978779035_DOMAIN_NET-VRSN
Registrar WHOIS Server: whois.dyndns.com
Registrar URL: http://dyn.com
Updated Date: 2016-03-01T06:00:13Z
Creation Date: 2015-11-12T06:12:02Z
Registrar Registration Expiration Date: 2017-11-12T06:12:02Z
Registrar: DYNAMIC NETWORK SERVICES, INC
Registrar IANA ID: 1040
Registrar Abuse Contact Email: <removed>
Registrar Abuse Contact Phone: <removed>
Domain Status: clientDeleteProhibited
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Registry Registrant ID:
Registrant Name: dns-book.net, Secret Registration Customer ID 397149
Registrant Organization: Dyn Inc
Registrant Street: c/o dns-book.net, 150 Dow Street, Tower 2
Registrant City: Manchester
Registrant State/Province: NH
Registrant Postal Code: 03101
Registrant Country: US
Registrant Phone: <removed>
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:

Обратите внимание, что имя регистранта в этой записи включает фразу «Secret Registration». В других случаях он может использовать фразу «by proxy», которая также указывает на частную регистрацию. В этих случаях адрес и номер телефона принадлежат регистратору, а не регистранту. На крупных веб-сайтах редко используется частная регистрация. Чаще всего это признак малого бизнеса или, возможно, ИТ-магазина, состоящего из одного человека, администратор не хочет, чтобы его адрес электронной почты был доступен в Интернете.

Такие веб-сайты, как DomainTools, автоматизируют большую часть этого исследовательского процесса, а также предоставляют исторические данные. Например, он показывает, что с ноября 2015 г. на dns-book.net было три разных записи whois (рис. 5.1).

Рисунок 5.1. Часть записи DomainTools для dns-book.net.

Данные WHOIS иногда можно использовать для «соединения точек» между различными частями кибератаки. Например, видя, когда были зарегистрированы вредоносные домены, можно построить более точную временную шкалу инцидента. DomainTools может отображать другие домены, зарегистрированные на тот же адрес электронной почты, что может привести к большей части инфраструктуры злоумышленника. Ярким случаем стал отчет Mandiant APT1 за 2013 год, в котором они использовали записи WHOIS, отчасти, для подключения большой хакерской сети к Китаю. Регистрационная информация для одного из доменов, использованных в атаке, включала адрес электронной почты, который затем приводил к публикациям на форуме в Интернете и, в конечном итоге, к отдельному лицу. Они также изучили поля совокупного местоположения в записях WHOIS со всех обнаруженных ими вредоносных доменов, чтобы найти общие страны[2].

Источники данных WHOIS

Чтобы понять, какая информация может быть доступна через WHOIS, важно сначала понять, какая информация собирается и передается на каждом этапе процесса регистрации. Большинство людей регистрируют домен через регистратора, такого как GoDaddy или Network Solutions. Эти компании будут иметь соглашения с операторами каждого TLD, и в конечном итоге домен станет активным, когда регистратор отправит обновление базы данных оператору TLD. Регистратор обычно платит реестру сбор за каждый домен в год. Например, в 2012 году плата за каждый адрес .com составляла 7,85 доллара в год[3]. Регистратор перекладывает расходы на регистранта и должен будет получить действительное имя, адрес и номер кредитной карты для обработки платежа. Он также запросит имя, адрес и номер телефона контактного лица по техническим вопросам для домена, хотя обычно он не проверяет эту информацию. Регистратор также знает IP-адрес источника подключения и может получить отпечаток браузера компьютера, использованного для покупки домена, хотя эта информация обычно не передается извне.

Когда регистратор отправляет запрос оператору TLD на создание нового домена, ему необходимо будет включить любую информацию, указанную в их соглашении с торговым посредником. В общедоступном соглашении Verisign не указано, какая информация должна быть передана, но в нем говорится, что они могут «время от времени использовать собранные демографические данные для статистического анализа»[4]. В документации ICANN указывается некоторая информация, которую реестры должны собирать: «Для каждого регистратора должны быть указаны следующие элементы данных: идентификатор регистратора, адрес регистратора, номер телефона регистратора, адрес электронной почты регистратора, сервер whois, URL-адрес ссылки, дата обновления, а также имя, номер телефона и адрес электронной почты всех административных, платежных и технических контактов регистратора»[5]. Резервная копия этих данных также должна храниться в рамках программы ICANN по депонированию данных регистраторов. С 2007 года предпочтительным поставщиком условного депонирования является Iron Mountain. Если регистратор обанкротится, его записи будут переданы новому провайдеру[6].

Предоставление доступа к этим данным через WHOIS предоставляет Интернет-сообществу полезные услуги. Например, если кто-то обнаруживает спам, исходящий из домена, он может связаться с его администраторами, чтобы узнать, не был ли он скомпрометирован. С другой стороны, сама база данных WHOIS - золотая жила для спамеров, поскольку она содержит миллионы законных адресов электронной почты. Баланс, который устанавливает ICANN, состоит в том, чтобы разрешить (и фактически обязать) общедоступный доступ на основе запросов к данным WHOIS каждого регистратора, но запретить массовые передачи. У них также есть политика против использования информации в любых маркетинговых целях. Несмотря на то, что политики по-прежнему используются не по назначению, часто в форме нежелательных электронных писем или телефонных звонков указанным контактам[7]. Вопрос о том, следует ли вообще публиковать данные WHOIS, горячо обсуждался в начале 2000-х годов. в том числе через слушания в Конгрессе[8]. Но по состоянию на 2016 год та же основная политика осталась в силе. Для администраторов рекомендуется использовать отдельный адрес электронной почты для регистрации. Эту учетную запись следует регулярно контролировать, но также следует подвергать дополнительной проверке, поскольку она, скорее всего, станет целью спама.

Карта инфраструктуры DNS

Самая простая форма DNS-разведки - запросить сервер и посмотреть, какие записи доступны. Большинство доменов будут иметь как минимум NS-запись, MX-запись и A-запись, которые дают адрес сервера имен, почтового сервера и (обычно) веб-сервера соответственно. Это часто показывает, размещает ли домен свою электронную почту и веб-серверы или использует эту инфраструктуру на стороне. Например, в приведенном ниже случае эти службы размещены в другом месте.

$ dig @8.8.8.8 cryptodns.com ANY
; << >> DiG 9.8.3-P1 << >> @8.8.8.8 cryptodns.com ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 13078
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;cryptodns.com.    IN ANY
;; ANSWER SECTION:
cryptodns.com.    3594 IN SOA dns1.name-services.com. info.name-services.com. 1446770972 172800 900 1814400 3600
cryptodns.com.    3594 IN NS dns4.name-services.com.
cryptodns.com.    3594 IN NS dns5.name-services.com.
cryptodns.com.    3594 IN NS dns2.name-services.com.
cryptodns.com.    3594 IN NS dns1.name-services.com.
cryptodns.com.    3594 IN NS dns3.name-services.com.
cryptodns.com.    3594 IN MX 10 p.nsm.ctmail.com.
cryptodns.com.    3595 IN A 64.74.223.41

Эти записи обычно не считаются конфиденциальными сами по себе, но они могут предоставить злоумышленнику больше контекста. Например, если электронная почта компании размещена у поставщика онлайн-пакетов для повышения производительности, такого как Google Apps или Microsoft Office 360, злоумышленник может заключить, что сотрудники используют другие службы на этих сайтах. Это может предоставить контент для целевой атаки. Или злоумышленник может найти ранее просочившиеся учетные данные от известных сотрудников и попробовать их в этих службах. В общем, администратор мало что может сделать для защиты от DNS-аспектов этих атак, поскольку широковещательная передача этой информации и является сутью протокола. Просто важно знать, какая информация находится в открытом доступе.

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

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

Цифровой отпечаток (fingerprinting) DNS

Более агрессивный вариант сопоставления инфраструктуры DNS - это попытка «отследить» точную версию используемого серверного программного обеспечения. Некоторые протоколы, такие как SSH и HTTP, включают версию сервера в сам протокол, поэтому снятие отпечатков - это просто вопрос подключения к службе и чтения заголовков. DNS этого не делает, поэтому исследователи ищут определенные функции или особенности протокола, которые реализованы только на определенных серверах (некоторые серверы, такие как BIND, необязательно предоставляют эту информацию, описанную ниже). Например, предположим, что сервер получает запрос в смешанном регистре (www.EXAmple.com). Это вполне приемлемо для протокола DNS, но некоторые старые серверы возвращают ошибку. Другие серверы преобразуют домен в нижний регистр в ответном пакете. Ответ BIND обычно соответствует регистру запроса. Таким образом, в зависимости от того, содержит ли ответ ошибку, весь нижний регистр или смешанный регистр, противник может сузить точную версию сервера.

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

BIND при необходимости предоставляет информацию о своей версии в записи TXT. Это можно увидеть с помощью следующего запроса:

$ dig @4.2.2.2 -c CH -t txt version.bind
; << >> DiG 9.8.3-P1 << >> @4.2.2.2 -c CH -t txt version.bind
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 40753
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind.    CH TXT
;; ANSWER SECTION:
version.bind.    0 CH TXT "Version: main/17936"

Чтобы отключить эту функцию, можно изменить параметр «version» в файле BIND named.conf. Включение этой функции действительно упрощает отладку сетевых проблем как для самих администраторов, так и для людей, которые полагаются на инфраструктуру. А сторонники безопасности утверждают, что сокрытие информации о версии не добавляет дополнительной защиты, это просто означает, что злоумышленнику придется приложить больше усилий, чтобы получить отпечаток с сервера. Но тот же аргумент также может привести к выводу, что он незначительно улучшает положение в целом.

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

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

Обратный DNS

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

Первоначально предполагалось, что каждый класс A в Интернете может отвечать за каждую из своих сетей класса B, каждый класс B - за свои сети класса C и т.д. Например, если пользователь попытался выполнить обратный запрос DNS на 1.2.3.4, корень мог указать ему на сеть класса A, отвечающую за «1», которая будет иметь запись для авторитетных серверов для каждого из своих серверов класса B. Когда пользователя, наконец, перенаправят на авторитетный сервер класса C для 1.2.3, эта служба будет иметь запись для каждого из 254 хостов в своем IP-пространстве. Как правило, это будет тот же сервер, который отвечал за регулярные запросы DNS для этих имен хостов. Поскольку на обычном DNS-сервере уже было бы сопоставление имен хостов с IP-адресами, он мог бы просто поддерживать обратное сопоставление IP-адресов с именем хоста.

Обратные DNS-запросы могут быть выполнены с опцией «-x» в dig. Например:

$ dig @8.8.8.8 www.ripe.net +short
193.0.6.139
$ dig @8.8.8.8 -x 193.0.6.139
; << >> DiG 9.8.3-P1 << >> @8.8.8.8 -x 193.0.6.139
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 34402
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;139.6.0.193.in-addr.arpa.    IN PTR
;; ANSWER SECTION:
139.6.0.193.in-addr.arpa. 21599  IN  PTR  www.ripe.net.

В этом примере сначала извлекается IP-адрес www.ripe.net (опция +short ограничивает вывод dig), а затем выполняется обратный DNS-запрос для этого IP-адреса. Обратите внимание, что ответ возвращается в записи PTR, которую можно рассматривать как инверсию записи A. В простой модели DNS-сервер может просто просмотреть свои записи A, чтобы найти имя хоста, которое соответствует обратному DNS-запросу, а затем динамически создать ответ PTR. Но по причинам, описанным ниже, они обычно хранятся и поддерживаются в конфигурации сервера как отдельные списки записей PTR, которые могут совпадать, а могут и не совпадать с записями A. Также обратите внимание на формат вопроса в приведенном выше запросе. Чтобы выполнить обратный DNS-запрос на 193.0.6.139, клиент меняет порядок октетов на обратный, а затем добавляет в конец «in-addr.arpa». Используя обычную инфраструктуру DNS, это направит запрос к корню, ответственному за обратный DNS, затем найдет сервер, который является полномочным для 193 класса A, а затем рекурсивно найдет сервер, ответственный за этот IP. Существует удобная симметрия между поддоменами, разделенными знаком «.» и октетами IP-адреса, разделенными одним и тем же символом, что позволяет одной и той же инфраструктуре анализировать оба типа запросов.

Эту простую модель ответа на обратные DNS-запросы нарушили два основных события. Во-первых, сети хотели управлять своим IP-пространством и разделять его на более мелкие блоки, поэтому необходимость делегирования всего класса B или C одному DNS-серверу стала непрактичной. Кроме того, виртуальный хостинг на HTTP-серверах значительно упростил запуск нескольких веб-сайтов (каждый со своим собственным доменом) на одном IP-адресе. Это нарушило общее взаимно однозначное сопоставление доменов с IP-адресами. Оба эти изменения произошли в конце 1990-х годов, а в 1998 году был выпущен RFC 2317 для обновления протокола обратного DNS. RFC указывает, что CNAME можно использовать для делегирования определенных подсетей. Например, CNAME «1.0/25.2.0.192.in-addr.arpa» (вместе с записью NS) будет указывать, что блок 192.0.2.0/25 администрируется другим сервером.

В наши дни крупные хостинговые компании часто используют весь класс B или C, но у большинства доменов не будет однозначного сопоставления имен хостов с IP-адресами. На больших веб-сайтах часто выполняется балансировка нагрузки между несколькими IP-адресами, поэтому обратные DNS-запросы будут давать что-то вроде «server1.<major domain>.com». Небольшие веб-сайты часто работают на инфраструктуре общего хостинга, поэтому обратные DNS-запросы для них будут возвращать «server1.<hosting company>.com». В обоих случаях обратный DNS может выявить организацию, которая администрирует этот блок IP-адресов, и может предоставить подсказки о количестве развернутых серверов. Как и в случае с отпечатками DNS, эту информацию не следует считать конфиденциальной саму по себе, но администраторам важно знать, что можно узнать из публичных исследований.

Отслеживание кеша DNS

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

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

Самый простой способ - запустить запрос с параметром +norecurse, который отключает флаг RD в заголовке. Например:

$ dig @ <server> www.cryptodns.com +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: SERVFAIL, id: 62318
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.cryptodns.com.    IN A

Отсутствие ответа показывает, что у сервера нет этого домена в кэше, что означает, что ни один из его пользователей в последнее время не запрашивал этот домен. Чтобы придумать более конкретное временное окно, можно было бы найти время жизни (TTL) для этой записи и сделать разумное предположение, что ни один пользователь не делал запрос в течение указанного количества секунд. Есть несколько исключений: сервер может не соблюдать TTL, сервер может быть занят и, следовательно, извлекать записи из кеша до истечения срока их действия, или TTL на полномочном сервере мог измениться непосредственно перед отслеживающим запросом. Но в целом это обеспечивает надежную индикацию того, запрашивался ли кеш недавно для этого домена.

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

$ dig @server www.cryptodns.com +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 62127
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.cryptodns.com.    IN A
;; ANSWER SECTION:
www.cryptodns.com. 3563 IN A 64.74.223.41

Защититься от отслеживания кеша очень сложно. Обычная гигиена безопасности, такая как разделение кеша и авторитетных частей DNS-сервера или разрешение доступа к кешу только IP-пространству из белого списка, снизит большую часть внешних рисков. Но пока пользователи могут запрашивать кеш, у них будет возможность отслеживать запросы других пользователей. Один из возможных защитных уровней состоит в том, что сервер всегда запускает рекурсивный запрос для некэшированных записей, чтобы злоумышленник не получил контрольный пустой ответ. Но TTL на записи часто выдает это. Например, если TTL является стандартным значением по умолчанию 86400 или 3600, вероятно, запрос был недавно произведен. Кроме того, задержка ответа будет разной для кэшированных и рекурсивных запросов, поскольку кешу требуется время для подключения к авторитетному серверу. Таким образом, злоумышленник может измерить время отклика и предположить, что более быстрые ответы были кэшированы. Это можно улучшить, измерив задержку в сети между клиентом и сервером и вычтя ее из времени ответа. Теоретически кеш может добавлять колебание ко всем ответам и случайным образом изменять TTL, чтобы новые записи показывали, что прошло некоторое время. Последняя возможность - кэшировать записи только после того, как они были запрошены более заданного числа раз. Это позволит злоумышленникам узнать, что домен был посещен, но сделает невозможным определение того, что домен не был посещен. Но большинство администраторов, которые очень обеспокоены отслеживанием кеша, вместо этого просто отключают кеши.

Пассивный DNS

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

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

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

В качестве упражнения из любопытства можно посмотреть, какие другие домены используют данный IP-адрес. Например, на рис. 5.2 показано несколько доменов, использующих тот же IP-адрес, что и dns-book.net[10].

Рисунок 5.2 Несвязанные домены, размещенные на том же IP-адресе, что и dns-book.net.

Сбор данных запроса

Запросы DNS можно отслеживать и регистрировать как минимум в трех местах, помимо самого клиента: рекурсивный резолвер, полномочный сервер и сеть, соединяющая их все. Профиль угроз часто различается для каждой части инфраструктуры и в конечном итоге будет зависеть от практики организаций, использующих эти службы. Например, крупные технологические компании могут иметь более надежные методы обеспечения безопасности, но с радостью будут сами собирать и анализировать данные в рекламных целях. Мелкие офшорные провайдеры могут ничего не собирать, но могут быть более уязвимыми для взлома. В общем, администратор должен понимать, какие данные покидают его сеть, какие объекты имеют к ним доступ и как их можно использовать в будущем.

Администраторы, использующие собственные рекурсивные резолверы, точно контролируют, какие данные собираются и устанавливают политики хранения. Тем, кто использует общедоступный или сторонний рекурсивный сервер, необходимо знать, как хранятся и используются данные их запросов. Одним из примеров является служба Google Public DNS с четкой политикой. Они будут хранить подробные записи, включая исходный IP-адрес и запрос, в течение 24-48 часов во «временном журнале». Затем они очищают исходный IP-адрес и создают «постоянный» журнал с такой информацией, как запрошенный домен, регион или город пользователя и время ответа. Они также заявляют, что «не сопоставляют и не объединяют информацию из наших временных или постоянных журналов с какой-либо личной информацией, которую вы предоставили Google для других служб»[11]. OpenDNS, еще один общедоступный рекурсивный сервер, не предоставляет столько подробностей об обработке их данных. Но они говорят: «OpenDNS хранит определенные DNS, IP-адреса и соответствующую информацию о вас, чтобы улучшить качество нашего Сервиса, предоставить вам Сервисы, а также для внутренних деловых и аналитических целей»[12]. Некоторые конкурирующие сервисы заявляют, что они не регистрируют никаких данные DNS вообще. Сервис Watch, базирующийся за пределами Германии, является одним из примеров. В зависимости от чувствительности записей DNS организации, некоторые администраторы согласятся с рекурсивными поставщиками, хранящими совокупную информацию, но другим потребуется полная анонимность. Поэтому, приложив определенные усилия, администраторы обычно могут найти поставщиков рекурсивных DNS, которые будут соблюдать желаемый уровень конфиденциальности.

Авторитетные серверы, напротив, обычно предполагают, что они регистрируют и сохраняют все данные, которые они получают. Иногда это является частью их бизнеса, поскольку посещения веб-сайтов можно рассматривать как сигналы «намерения», которые используются при таргетинге рекламы. Часто эти данные также поступают через журналы веб-сервера, поскольку запросы DNS часто предшествуют запросам веб-страниц. Многие крупные хостинг-провайдеры не различают данные DNS и веб-данные в своих политиках конфиденциальности, а просто заявляют, что они могут собирать IP-адреса и другие действия в Интернете. Такой уровень мониторинга не станет сюрпризом для большинства профессионалов в области безопасности и, вероятно, не для большинства пользователей Интернета в целом. Но один потенциально упускаемый из виду вектор угроз - это концентрация поставщиков DNS. Как указано в RFC 7626:

среди 100 тысяч Alexa Top сегодня один DNS-провайдер обслуживает 10% доменов. Десять наиболее важных поставщиков DNS вместе размещают одну треть доменов. Благодаря контролю над несколькими серверами имен (или способности отслеживать трафик) вы можете собрать большой объем информации.

Исследование, проведенное Google и французским институтом Inria, показало, что большинство пользователей Интернета можно однозначно идентифицировать после посещения четырех веб-сайтов[13]. При большой концентрации DNS с нескольких веб-сайтов, хранящихся в одном месте, возможность деанонимизации становится более вероятным. Как описано ранее в этой книге, авторитетные серверы не обязательно увидят истинный источник запроса, поскольку он может поступать через промежуточные резолверы. В сочетании с эффектом кеширования авторитетные серверы не будут иметь такого чистого источника данных, с которым работали исследователи. Но даже небольшие пакеты деанонимных данных представляют собой очень конфиденциальный источник информации. Часто приводят пример того, что информация о том, что конкретный человек регулярно посещал форум поддержки алкоголиков, является чрезвычайно личной информацией.

Сетевые операторы теоретически имеют доступ ко всему трафику DNS, который проходит по их ссылкам, но у них часто есть определенные юридические или политические ограничения на то, что они могут делать с данными. Единственным исключением является то, что у них почти всегда есть возможность отслеживать и собирать любой трафик, чтобы вести свой бизнес и поддерживать целостность инфраструктуры. Некоторые из них являются определяющими; сетевой оператор, конечно, должен просматривать по крайней мере некоторую часть пакета, чтобы выполнять свою задачу по его маршрутизации в нужное место. Например, у Time Warner, одного из крупнейших интернет-провайдеров в США, в уведомлении о конфиденциальности подписчиков говорится, что «мы можем собирать личную информацию (описанную ниже) по кабельной системе без вашего согласия, если это необходимо для предоставления вам наших услуг или предотвращения несанкционированного доступа к услугам или данным подписчика». Хотя в политике конкретно не упоминается DNS, в ней проводится различие между содержанием интернет-трафика и совокупной статистикой. Например, в нем говорится: «если вы используете веб-службу электронной почты, мы не собираем никакой информации об электронных письмах, которые вы отправляете и получаете». Но у них действительно «есть информация о том, как часто и как долго вы пользуетесь нашим сервисом, включая объем используемой полосы пропускания; техническая информация о вашей компьютерной системе, ее программном обеспечении и модеме; и ваше географическое положение. «Они могут использовать эту информацию», чтобы убедиться, что вам выставляют счет за услуги, которые вы получаете; для отправки вам соответствующей информации о наших услугах; для поддержания или улучшения качества оборудования TWC... [и] для продвижения на рынок Time Warner Cable Services и других продуктов, которые могут вас заинтересовать»[14].

Comcast, другой крупный интернет-провайдер, также заявляет, что может «собирать и хранить в течение определенного периода времени личную и неличную информацию о вас, когда вы используете наш высокоскоростной Интернет». Примеры действий, которые можно регистрировать, - это «отправлять и получать электронную почту, видеопочту и мгновенные сообщения» или «посещать веб-сайты»[15]. В 2014 году AT&T опубликовала несколько новостей, предложив более дешевую версию услуг своего оптоволоконного Интернета, если пользователи согласятся на рутинный сбор данных[16].

В США большинство юридических ограничений распространяется на телефонные и видеосервисы, но не на доступ в Интернет. Многие другие страны приняли различие между содержанием и совокупной информацией. Пример политики из Австралии гласит, что «поставщикам услуг связи запрещается использовать или раскрывать любую информацию, которая поступает в их распоряжение в ходе их деятельности и которая относится [среди прочего] к содержанию сообщений, которые передаются или были переданы поставщиками услуг связи». Здесь они также включают исключение для «бизнес-потребностей других операторов или поставщиков услуг» или «выполнения человеком своих служебных обязанностей»[17]. Как правило, конкретные запросы DNS, вероятно, не будут просматриваться сотрудниками, работающими с инфраструктурой Интернета. Но если запросы настолько чувствительны, что никто за пределами доверенной организации никогда не должен иметь к ним доступа, то они никогда не должны покидать корпоративную сеть незашифрованной.

Связанная форма сбора данных - это то, как интернет-провайдеры сохраняют записи о назначении IP-адресов. Они привязывают отдельных клиентов к IP-адресам, которые они использовали в Интернете. Сообщество BitTorrent особенно активно отслеживает эти политики из-за судебных исков, которые были поданы в связи с нарушением авторских прав. Согласно их исследованиям, большинство крупных интернет-провайдеров в США хранят записи об IP от 6 до 12 месяцев[18]. Для тех, кто менее обеспокоен обвинениями в нарушении авторских прав, эти данные могут быть конфиденциальными, если объединить их с журналами DNS из другого источника, поскольку они могут деанонимизировать эти запросы.

Выводы

В этой главе показано, что DNS может быть богатым источником данных. Любой человек в Интернете может найти основную информацию об инфраструктуре сети и узнать контактные данные администраторов. Можно узнать об истории и работе домена с помощью пассивного DNS и снятия отпечатков. Наконец, доверенные операторы сети, такие как интернет-провайдеры или крупные хостинговые компании, могут собирать огромный объем информации о пользователях и организациях, наблюдая за потоком данных DNS. Одно из будущих последствий состоит в том, что чем больше информации будет храниться в DNS, тем больше будет раскрыта конфиденциальная информация о жизни людей. Например, оператор общедоступной DNS в настоящее время может обнаруживать, какие веб-сайты посещают пользователи. Если люди начнут хранить ключи шифрования электронной почты в DNS, как было предложено в случае с DANE, то тот же DNS-сервер будет видеть, какие пользователи обмениваются электронными письмами и как часто[19]. Эти дополнительные возможности деанонимизации данных приведут к появлению новых проблем с данными DNS.

Заметки

  1. https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en

  2. http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf

  3. https://www.verisign.com/assets/com-registrar-agreement.doc

  4. https://www.verisign.com/assets/com-registrar-agreement.doc

  5. https://www.icann.org/en/system/files/files/registry-agmt-app5-22sep05-en.pdf

  6. https://www.icann.org/en/system/files/files/rde-specs-09nov07-en.pdf

  7. https://whois.icann.org/sites/default/files/files/cmu-misuse-study-26nov13-en.pdf

  8. http://jour.sc.edu/news/csj/CSJNov04.html

  9. https://miek.nl/2012/January/28/dns-fingerprinting/

  10. https://www.bfk.de/bfk_dnslogger.html

  11. https://developers.google.com/speed/public-dns/privacy

  12. https://www.opendns.com/privacy-policy/

  13. https://www.petsymposium.org/2012/papers/hotpets12-4-johnny.pdf

  14. http://help.twcable.com/twc_privacy_notice.html

  15. http://www.xfinity.com/Corporate/Customers/Policies/CustomerPrivacy.html

  16. https://gigaom.com/2014/05/13/atts-gigapower-plans-turn-privacy-into-a-luxury-that-few-would-choose/

  17. http://www.acma.gov.au/Industry/Telco/Carriers-and-service-providers/Licensing/service-provider-obligations-licence-fees-and-levies-i-acma

  18. https://torrentfreak.com/how-long-does-your-isp-store-ip-address-logs-120629/

  19. https://tools.ietf.org/html/rfc7626

Глава 6
Сетевая безопасность DNS

Информация в этой главе

Вступление

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

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

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

Размещение DNS-серверов

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

В январе 2001 года microsoft.com и многие другие домены, связанные с Microsoft, были отключены в течение нескольких дней. Проблема заключалась не в программном сбое или успешной атаке на DNS-серверы Microsoft, проблема заключалась в отказе маршрутизатора. К сожалению для Microsoft, ее первичный и вторичный DNS-серверы находились в одном сегменте сети, поэтому, когда маршрутизатор вышел из строя, все DNS-серверы Microsoft оказались недоступными. Поскольку время жизни (TTL) для microsoft.com на рекурсивных серверах по всему миру истекло, посетители не могли получить доступ к домену и многим другим доменам Microsoft (рис. 6.1).

Рисунок 6.1 В то время отключение было очень большой новостью. (Комикс перепечатан с разрешения автора).

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

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

Есть способы добиться этого разделения за кулисами, что создает впечатление, что серверы имен находятся в одной сети, но на самом деле они разделены. Например, UUNET используется для обслуживания трех серверов имен: 198.6.1.1, 198.6.1.2 и 198.6.1.3. Похоже, что они находятся в одной сети, но маршрутизированы в разные места по всему миру. Один из способов сделать это - использовать Anycast, который будет более подробно обсуждаться в главе 11. Разнообразие сети также может быть достигнуто с помощью глобальной балансировки нагрузки, которая перенаправит трафик, отправленный на один IP-адрес, на несколько разных, замаскированных, адресов по всему миру. Большинство организаций не имеют достаточно большой инфраструктуры DNS, чтобы беспокоиться об Anycast или балансировке нагрузки, достаточно поддерживать серверы в различных сетях в разных частях страны или мира.

Рекурсивные службы имен должны быть отделены от официальных служб имен. Назначение авторитетных серверов имен состоит в том, чтобы мог обратиться каждый, что означает, что они должны быть общедоступными через порт 53. Есть очень немного случаев, когда рекурсивные серверы имен должны запрашиваться кем-либо за пределами организации. Запуск рекурсивных служб имен на том же сервере, что и полномочный сервер имен, открывает для организации потенциальные риски безопасности, не принося при этом реальной выгоды для организации. Учитывая возможность атак не только на организацию с открытым резолвером, но и способность злоумышленников использовать этот открытый резолвер для запуска атак на другие сайты, важно следовать этому правилу. К сожалению, многие организации этого не делают. Еще в феврале 2016 года Measurement Factory отслеживала тысячи открытых резолверов почти в каждом Autonomous System Number[1]

.

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

Публичная и приватная инфраструктура DNS

В RFC 761 великий Джон Постел сказал: «...будьте консервативны в том, что вы делаете, будьте либеральны в том, что вы принимаете от других». Это известно как принцип устойчивости, и он помог Интернету превратиться из зародыша в то, чем он является сегодня. В основе принципа устойчивости лежит принцип взаимодействия. Это позволяет различным организациям создавать продукты, которые обмениваются данными друг с другом с использованием одного и того же протокола, даже если этот протокол не включен одинаковым образом. Принцип устойчивости означает, что маршрутизаторы Cisco взаимодействуют с маршрутизаторами Juniper, чтобы серверы Ubuntu под управлением Apache могли доставлять HTTP-трафик на рабочую станцию Microsoft Windows браузеру Microsoft Edge. Любая система, которая предназначена для взаимодействия с другими системами по сети, должна быть максимально точной в реализации общих протоколов. В то же время хосты, с которыми разговаривают эти системы, не должны быть настолько строги в своей интерпретации протоколов, чтобы усложнять связь больше, чем это должно быть.

К сожалению, современный Интернет сильно отличается от того, когда был написан RFC 761 (на самом деле, уже в 1989 году в RFC 1122 было обновление Принципа устойчивости). Дело в том, что большинство организаций не могут быть слишком либеральными в том, что они принимают. Искаженный пакет, отправляемый на DNS-сервер, может быть результатом плохой реализации протокола DNS. Но более вероятно, что он специально разработан для запуска атаки типа «отказ в обслуживании» против серверов имен, отключая его на несколько часов и, возможно, позволяя злоумышленнику получить доступ к серверу.

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

Авторитетный DNS-сервер никогда не должен передавать больше информации, чем необходимо. Он не должен разрешать полную передачу зоны с любого сервера, который не является его вторичным сервером имен, и должен включать некоторую форму двухфакторной аутентификации. Недостаточно просто включить ACL в конфигурации DNS-сервера; второй хороший шаг - также включить подписи транзакций (TSIG). TSIG, подробно описанные в главе 7, позволяют подписывать транзакции. TSIG используют общий секрет в сочетании с односторонним хэш-алгоритмом для защиты запросов от первичных и вторичных полномочных серверов имен. Это имеет два эффекта: гарантирует, что запросы действительно поступают от вторичных серверов имен, а также гарантирует, что ответы действительно поступают от первичного сервера имен.

Даже если общедоступный сервер имен находится в DMZ, это не означает, что он не защищен брандмауэром. DMZ по-прежнему является частью сети, и любые общедоступные DNS-серверы должны находиться за брандмауэром. Большинство современных межсетевых экранов, таких как F5 или Palo Alto Networks, имеют возможности фильтрации приложений. Использование возможностей этих брандмауэров поможет гарантировать, что искаженные или подозрительные пакеты вообще не попадут на DNS-сервер. При этом, поскольку администраторы DNS часто отключены от группы безопасности в организации, они могут не знать о способах включения брандмауэра приложений для лучшей защиты инфраструктуры DNS. И наоборот, службы безопасности или сети могут не рассматривать возможность использования возможностей этих межсетевых экранов с учетом приложений, особенно в отношении протокола DNS, для защиты DNS-сервисов. Вот почему так важно иметь каждую команду внутри организации, участвующую в создании системы безопасности DNS, описанной в главе 2. Это помогает каждому понять не только риски, но и возможности организации. Необходимо обязательно изучить любой шанс улучшить безопасность без увеличения бюджета.

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

Чтобы усилить защиту организации, многие администраторы DNS применяют конфигурацию DNS с расщеплением горизонта. Это подробно объясняется в главе 9, но простая версия заключается в том, что пользователи внутри сети имеют доступ к полному файлу зоны для домена, что позволяет им общаться с другими хостами внутри сети, используя канонические доменные имена. С другой стороны, те, кто находится за пределами сети, имеют файл зоны гораздо меньшего размера, который содержит только общедоступные имена хостов. Это можно реализовать несколькими способами, включая создание одного файла зоны, который находится на общедоступных авторитетных серверах имен, и второго файла зоны, который находится на внутреннем авторитетном сервере имен. Если информация не существует на общедоступном авторитетном сервере имен, то даже если злоумышленник сможет скомпрометировать сервер, он не сможет построить карту сети на основе информации DNS.

Логирование и мониторинг DNS-трафика

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

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

Отключение локального кэша

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

Указание плохих доменов

Чтобы понять, как это можно сделать, взгляните на усеченный образец журнала BIND:

13-Feb-2016 22:54:17.661 queries: info: client 192.168.1.4#47539: query: www.dns-book.net IN A +
13-Feb-2016 22:54:17.876 queries: info: client 192.168.1.4#58532: query: www.dns-book.net IN AAAA +
13-Feb-2016 22:54:17.969 queries: info: client 192.168.1.4#46830: query: www.dns-book.net IN MX +
13-Feb-2016 22:54:23.498 queries: info: client 192.168.1.4#45397: query: www.google.com IN A +
13-Feb-2016 22:54:25.533 queries: info: client 192.168.1.4#50842: query: www.google.com IN AAAA +
13-Feb-2016 22:54:25.554 queries: info: client 192.168.1.4#49238: query: www.google.com IN MX +
13-Feb-2016 22:54:31.852 queries: info: client 192.168.1.4#46170: query: www.abc.com IN A +
13-Feb-2016 22:54:34.065 queries: info: client 192.168.1.4#33302: query: abc.com IN AAAA +
13-Feb-2016 22:54:34.133 queries: info: client 192.168.1.4#55908: query: abc.com IN MX +
13-Feb-2016 22:55:05.827 queries: info: client 192.168.1.4#57957: query: shibanikashyap.asia IN A +
13-Feb-2016 22:55:05.829 queries: info: client 192.168.1.4#38194: query: shibanikashyap.asia IN MX +

В журнале нет ничего, кроме стандартных запросов. Однако у специалиста по безопасности возникает ощущение, что доменное имя shibanikashyap.asia выглядит странно. whois не обнаруживает ничего интересного, но, сравнивая пассивный поиск DNS (pDNS) VirusTotal, он видит, что по крайней мере один поставщик подозрительно относится к сайту, как показано на рис. 6.2.

Рисунок 6.2 Результаты поиска VirusTotal для shibanikashyap.asia.

Девять сайтов из 66 отметили сайт как плохой, но что это за плохой? Переходя к следующему шагу, он ищет домен на сайте McAfee's SiteAdvisor и обнаруживает, что веб-сайт распространяет или распространял вредоносные файлы, как показано на рис. 6.3.

Рисунок 6.3 Результаты поиска McAfee SiteAdvisor для shibanikashyap.asia.

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

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

К счастью, существует ряд уловок, позволяющих автоматизировать процесс выделения доменов, которые необходимо исследовать. Реализуя эти правила в Security Information and Event Manager (SIEM) или другом инструменте, организация может быстро идентифицировать вредоносные домены, которые могли быть пропущены другими инструментами безопасности.

Самое простое правило для начала - новые домены. Согласно одному отчету, подавляющее большинство вновь зарегистрированных доменов используется в злонамеренных целях[2]. Исследование, проведенное в 2013 году, показало, что около 75% доменов, внесенных в черный список Spamhaus, были зарегистрированы в среднем в течение 15 дней. В том же исследовании было обнаружено, что при сужении поиска до домена .com (крупнейшего из TLD) 50% доменов .com в URIBL (черный список URI) были зарегистрированы за последние 60 дней[3]. Из этого исследования можно сделать два вывода: Большинство недавно зарегистрированных доменов используются для злонамеренных действий, этот эффект еще выше в новых gTLD (что объясняет, почему аналитик в предыдущем примере смог так быстро выбрать домен .asia).

Вооружившись этой информацией, легко создать правила, позволяющие аналитикам безопасности отмечать домены, которые могут быть связаны для вредоносной деятельности. Начните с чего-нибудь простого: зарегистрирован ли домен за последние 24 часа? Если домен был настроен за последние 24 часа и с ним уже связана запись A, есть большая вероятность, что в этом есть что-то подозрительное. Даже спустя 30 дней после первоначальной регистрации домен может быть связан со злонамеренными действиями. Правило, которое помечает домены, зарегистрированные в течение последних 24 часов, и выделяет домены, зарегистрированные в течение последних 30 дней, будет предупреждать о большом количестве вредоносных доменов. DNS не существует в вакууме, есть большая вероятность, что прокси-сервер и почтовый сервер организации содержат черные списки. Сопоставляя отслеживаемые DNS-запросы с информацией в этих черных списках, можно активно удалять плохие домены, а не просто предупреждать о них.

В то время как высокий процент вредоносных доменов в пространстве .com появляется в черных списках в течение 30 дней, это число еще выше для некоторых новых gTLD. Исследование, проведенное в Калифорнийском университете в Сан-Диего, показало, что недавно зарегистрированные gTLD в два раза чаще, чем домены .com, появлялись в URIBL в течение первых 30 дней[4]. Это связано с предыдущим правилом, но когда вновь зарегистрированный домен является частью gTLD, отличной от .com, .net или .org, уровень предупреждения должен быть выше.

Не забывайте о ccTLD

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

Есть несколько других индикаторов, которые легко включить в скрипт, и которые также могут указывать на домен, который используется для плохих вещей. В общем, одна из этих вещей - не включить конфиденциальность домена. Конфиденциальность домена - важный инструмент безопасности, который может помочь защитить законные организации от спама и фишинговых атак. Одно исследование показало, что домены с включенной конфиденциальностью домена на самом деле с меньшей вероятностью будут использоваться в злонамеренных целях. Что неудивительно, обеспечение конфиденциальности домена в домене требует дополнительных затрат, и, учитывая, что спам часто является низкорентабельным предприятием, дополнительные 8-12 долларов не стоят усилий, особенно когда так легко использовать поддельную информацию в процессе регистрации домена. Это же исследование показало, что есть некоторые поставщики, у которых значительно больше доменов, вовлеченных во вредоносную деятельность, чем можно было бы ожидать[5]

Например, более 16% доменов, использующих «Information Privacy Protection Services Ltd», были вовлечены в рассылку спама, фишинга, ботнета или доставки вредоносного ПО. Это каждый шестой домен, использующий сервис. Information Privacy Protection Services Ltd, похоже, предоставляет услуги по обеспечению конфиденциальности доменов для двух регистраторов доменов, OurDomains Ltd и Hangzhou Aiming Network Company Ltd. Какой бы регистратор ни использовался, у всех доменов есть адрес электронной почты whois@privacy-protection-services.com. Опять же, это простой поиск, который создаст список доменов, которые можно проверить или автоматически отправить в мусор.

Это напрямую связано с другим важным показателем - адресом электронной почты регистранта домена. Хотя создать бесплатный адрес электронной почты и использовать его для регистрации доменного имени тривиально, многие злоумышленники просто этого не делают, и есть некоторые бесплатные поставщики электронной почты, которые, похоже, используются злоумышленниками чаще, чем другие, при регистрации доменов для злонамеренных целей. В упомянутой выше презентации Хелминга используется пример бесплатной электронной почты yahoo.co.jp. Согласно их исследованию, 28,70% доменов, зарегистрированных с использованием адреса этого провайдера, были задействованы в атаках. Почти каждый третий домен был плохим.

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

Например, служба безопасности обнаруживает вариант вредоносного ПО Zeus на рабочей станции пользователя. Бот Zeus соединяется с hope-found-now.net, поэтому теперь у аналитика есть IP-адрес, доменное имя и связанный IP-адрес. Еще у него есть механизм доставки (фишинг, лейка, флешка и т.д.). Проверяя записи whois, он видит, что домен зарегистрирован на dredskooper@gmail.com. Используя инструмент обратного whois, подобный тому, который предлагает DomainTools[6], он может узнать все другие домены, связанные с этим регистрантом, как показано на рис. 6.4.

Рисунок 6.4 Поиск всех доменов, связанных с регистрантом домена.

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

До сих пор основное внимание уделялось регистрационной информации, но можно предсказать «вредность» домена на основе самого имени домена. Это можно сделать даже программно, с помощью математики[7]. Группа исследователей сделала именно это, когда разработала систему под названием EXPOSURE, которая имеет 15 ключевых характеристик, разделенных на четыре группы, которые можно измерить, чтобы автоматически определить, является ли имя домена плохим[8]. В разделе «Пассивный DNS» будет больше информации о характеристиках; в этом разделе есть шесть функций, основанных на доменных именах, на которых стоит сосредоточиться. Первый набор функций, которые следует обсудить, - это функции, основанные на времени, и есть функции, которые включают количество запросов для ресурсов домена за фиксированный период времени. Есть четыре особенности, которые авторы EXPOSURE отслеживали для временных характеристик:

  1. Короткое время жизни
  2. Ежедневное сходство
  3. Повторяющиеся паттерны
  4. Коэффициент доступа

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

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

  1. Процент числовых символов
  2. Процент длины самой длинной значимой подстроки (LMS)

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

Но домены, созданные DGA, не похожи на домены, зарегистрированные людьми. Они, как правило, гораздо более случайны, чем эти домены, и это потенциальный индикатор. Проблема в том, что человеку легко определить случайность: 5202dlks98.link выглядит некорректно, тогда как 937thefan.com выглядит совершенно нормальным доменом. Эти два правила смотрят на процентное соотношение цифр в домене. В первом домене 60% символов в домене - это необычно высокие числа. Для второго домена только 33% символов в домене являются цифрами, что в пределах нормы. Однако сам по себе это не обязательно хороший показатель, предположим, что вторым доменом был 1073rock.com. Теперь 50% символов в домене являются цифрами, что является статистически большим числом, но домен, скорее всего, является действительным.

Вот где появляется вторая функция, основанная на доменном имени: LMS. Идея LMS заключается в том, что законные владельцы доменов хотят создать запоминающийся домен. С этой целью они обычно используют слова или фразы, которые можно найти в словаре, тогда как домены, созданные с помощью DGA, не будут иметь никакого отношения к словарным словам. В предыдущем примере 1073rock.com, хотя он имеет высокий процент цифр в домене, 50% символов также образуют значимую строку, которая достаточно длинна, чтобы классифицировать ее как наиболее вероятный законный домен.

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

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

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

А как насчет динамического DNS и служб коротких URL?

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

Другое дело - службы сокращенных URL-адресов. Это еще один случай, когда необходимо найти компромисс между безопасностью и удобством использования. На самом деле службы сокращенных URL-адресов, такие как bit.ly и tr.im, маскируют множество злонамеренных действий (не имея в виду конкретно эти две службы), и некоторые злоумышленники используют службы с сокращенными URL-адресами в попытке замаскировать свою атаку. Однако службы сокращенных URL также используются в законных целях. Не раз случалось, что службы безопасности блокировали все службы сокращенных URL-адресов только для того, чтобы обнаружить, что их маркетинговая организация сильно на них полагается. Поскольку эти службы используют перенаправление HTTP на более длинный домен, в отличие от перенаправления DNS, это не строго проблема безопасности DNS. Что, как говорится, в зависимости от профиля риска организации, вероятно, имеет смысл отслеживать перенаправления HTTP, чтобы увидеть, есть ли определенные службы сокращенных URL-адресов, которые чаще связаны с вредоносной активностью, и блокировать эти конкретные службы, а не просто предупреждать или блокировать все из них. Это дает дополнительное преимущество одновременного сохранения безопасности сети и удовлетворенности пользователей организации.

Пометка DNS-запросов

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

Самый очевидный инструмент в наборе инструментов защиты DNS от группы безопасности - автоматическая пометка необычных запросов. Запросы DNS, такие как TXT и NULL, широко не используются, но предоставляют достаточно неструктурированного пространства ответов для доставки полезной нагрузки или информации о командах. RFC 1035 описывает различные типы запросов и ожидаемые ответы, а также служит полезным руководством для выбора полей, которые нужно пометить.

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

Первый метод - измерить количество запросов CNAME к домену за заданный период времени. Большинство доменов относительно статичны с точки зрения имен хостов, поэтому рекурсивный DNS-сервер может получать большое количество запросов для google.com и его поддоменов, но в запросах имени хоста нет большого разнообразия, как в фрагменте BIND. журналы для google.com ниже:

17-Feb-2016 18:36:06.540 queries: info: client 192.168.1.13#40774: query: www.google.com IN A +
17-Feb-2016 18:36:06.567 queries: info: client 192.168.1.13#53209: query: www.google.com IN AAAA +
17-Feb-2016 18:36:06.594 queries: info: client 192.168.1.13#50638: query: www.google.com IN MX +
17-Feb-2016 18:36:15.373 queries: info: client 192.168.1.13#49980: query: mail.google.com IN A +
17-Feb-2016 18:36:15.414 queries: info: client 192.168.1.13#40647: query: googlemail.l.google.com IN AAAA +
17-Feb-2016 18:36:15.435 queries: info: client 192.168.1.13#57577: query: googlemail.l.google.com IN MX +

Несмотря на то, что рекурсивный сервер имен может видеть много запросов для google.com, запросов CNAME не так много, поэтому, отслеживая запросы CNAME для определенного домена, за короткие промежутки времени можно изолировать вредоносную активность. Например, если в течение 1 минуты от одного хоста к домену поступило более 10 запросов CNAME, это следует отметить как потенциально вредоносную активность. Десять запросов в минуту - это просто начало, а не жесткое правило. Вместо этого службы безопасности должны поиграть с соотношением запросов к времени, чтобы найти правильный баланс, который позволит улавливать вредоносный трафик, но не генерирует огромное количество ложных срабатываний.

Второй метод обнаружения потенциально вредоносных запросов CNAME - это поиск DGA в запросе CNAME. Это то же правило, которое обсуждалось в предыдущем разделе в отношении доменов второго уровня, но теперь применяется к доменам третьего уровня. Вредоносное ПО, использующее CNAME для туннелирования или проникновения, будет использовать алгоритмы генерации домена для создания CNAME. Почему? Потому что вредоносная программа должна гарантировать уникальность каждого запроса, что заставляет рекурсивный сервер обращаться к авторитетному серверу для получения ответа. Как и в случае с доменами второго уровня, эти CNAME DGA не будут выглядеть как обычные домены третьего уровня, они будут иметь преобладание чисел и отсутствие значимых подстрок. Применяя те же проверки к этим запросам CNAME, которые применяются к доменным именам, группы безопасности могут выбирать запросы CNAME, которые выглядят подозрительно, и исследовать их или блокировать доступ.

Это вредоносное по или CDN?

Большой проблемой в этом процессе обнаружения является рост сетей доставки контента (CDN). CDN, такие как Akamai, Amazon и CloudFlare, представляют собой гигантские сети с балансировкой нагрузки, которые доставляют контент на популярные веб-сайты по всему миру. Эти услуги очень полезны для организаций, потому что они могут помочь быстрее доставлять контент посетителям веб-сайта и могут помочь доставлять локализованный контент более эффективно.

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

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

Другой метод обнаружения потенциальной вредоносной активности с использованием DNS - это длина домена третьего или четвертого уровня. Типичный домен третьего или четвертого уровня будет коротким, например www.dns-book.net или fileserver.corp.dnsbook.net. Однако домен, используемый для командования и контроля или экзифильтрации, по определению будет длиннее. Злоумышленнику необходимо разместить как можно больше данных в 512-байтовом пакете, поэтому нередко домен третьего или четвертого уровня содержит максимально разрешенные 253 символа. Вообще говоря, любой домен третьего или четвертого уровня, длина которого превышает 20 символов, должен быть помечен. Если написать правило для определенного поддомена слишком сложно, правило можно написать для домена в целом. Начните с предупреждения на 50 символов и настройте в зависимости от количества ложных срабатываний.

Пара слов о TCP

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

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

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

DNS и SIEM

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

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

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

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

Многие разработчики SIEM осознали силу DNS-запросов в выявлении вредоносной активности и включили расширенный сбор DNS. У HP ArcSight есть надстройка под названием DNS Malware Analytics, у IBM QRadar есть расширение безопасности больших данных, которое позволяет проводить экспертизу DNS, а LogRhythm имеет особые правила только для анализа DNS-трафика.

Splunk также имеет ряд доступных приложений, которые позволят службам безопасности выполнять расширенную аналитику журналов DNS. Одна из лучших - это DNS Analytics для Splunk, написанная AlphaSOC. Приложение DNS Analytics для Splunk использует ряд предлагаемых средств защиты, перечисленных выше, и автоматизирует их таким образом, чтобы аналитики безопасности могли сразу же получить значение из своих журналов DNS, как показано на рис. 6.5.

Рисунок 6.5 Аналитика DNS для Splunk, показывающая запросы к незарегистрированным доменам.

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

Пассивный DNS

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

pDNS - это способ отслеживать рекурсивные транзакции DNS с течением времени. Если типичный рекурсивный DNS-сервер регистрирует дату, время, исходный IP-адрес и запрос, который был сделан, система ведения журнала pDNS также регистрирует ответ, информацию о сервере имен и информацию о TTL. Собранные запросы хранятся в базе данных (или ее эквиваленте), и теперь у аналитиков безопасности есть мощное представление о том, как домен изменился с течением времени и как эти изменения выглядят. На рис. 6.6 показано, как это работает для домена 19bee88.com, связанного с программой-вымогателем CryptoWall. В течение 5 месяцев домен 19bee88.com был связан как минимум с тремя разными IP-адресами.

Рисунок 6.6 Результаты VirusTotal pDNS для 19bee88.com.

Если аналитик щелкнет самый последний IP-адрес, он увидит, что существует ряд потенциально подозрительных доменов, связанных с одним и тем же IP-адресом, как показано на рис. 6.7.

Рисунок 6.7. Ряд подозрительных доменов, также связанных с этим IP-адресом.

Углубившись в один из потенциально плохих доменов, blocker-cl.info, аналитик обнаруживает, что он имеет ту же историю IP-адресов, что и 19bee88.com, как показано на рис. 6.8.

Рисунок 6.8 Домены blocker-cl.info и 19bee88.com совместно используют историю IP-адресов.

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

Помимо VirusTotal существует ряд сторонних сервисов, которые предоставляют возможности pDNS. Большинство из них делают это по подписке и предлагают более подробные ответы на запросы, которые позволяют аналитикам безопасности просматривать TTL, используемые серверы имен и многое другое. OpenDNS, Люксембургский центр реагирования на компьютерные инциденты и, конечно же, Farsight Security предлагают решения pDNS (В системе безопасности Farsight находится исходная база данных pDNS, известная как DNSDB). Кроме того, ряд поставщиков аналитики угроз используют pDNS в качестве серверной части, чтобы повысить эффективность своих предложений. Таким образом, хотя pDNS не может занимать центральное место во всех решениях, он часто используется, в частности, для поддержки серверной части продуктов безопасности.

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

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

Чтобы увидеть разницу, сравните журналы DNS для запроса www.google.com с выводом tcpdump. Сначала журналы BIND:

18-Feb-2016 01:08:32.176 queries: info: client 192.168.1.4#41780: query: www.google.com IN A +
18-Feb-2016 01:08:34.440 queries: info: client 192.168.1.4#60344: query: www.google.com IN AAAA +
18-Feb-2016 01:08:34.469 queries: info: client 192.168.1.4#33012: query: www.google.com IN MX +

Теперь вывод tcmpdump:


01:08:32.179217 IP6 (hlim 64, next-header: UDP (17), length: 51) ::1.29195 > 2001:503:231d::2:30.domain: 24072 [1au] A? www.google.com. (43) 01:08:34.179167 IP (tos 0x0, ttl 64, id 57330, offset 0, flags [none], proto: UDP (17), length: 71) 192.168.1.4.12422 > 192.48.79.30.domain: 12718 [1au] A? www.google.com. (43)
01:08:34.419433 IP (tos 0x0, ttl 50, id 30710, offset 0, flags [none], proto: UDP (17), length: 692) 192.48.79.30.domain > 192.168.1.4.12422: 12718- 0/8/5 (664)
01:08:34.419803 IP (tos 0x0, ttl 64, id 42075, offset 0, flags [none], proto: UDP (17), length: 71) 192.168.1.4.54064 > 216.239.36.10.domain: 5847 [1au] A? www.google.com. (43)
01:08:34.440282 IP (tos 0x0, ttl 43, id 14987, offset 0, flags [none], proto: UDP (17), length: 156) 216.239.36.10.domain > 192.168.1.4.54064: 5847*- 6/0/0 www.google.com. A 74.125.29.105, www.google.com.[|domain]
01:08:34.441109 IP (tos 0x0, ttl 64, id 2779, offset 0, flags [none], proto: UDP (17), length: 71) 192.168.1.4.8838 > 216.239.34.10.domain: 19649 [1au] AAAA? www.google.com. (43)
01:08:34.468735 IP (tos 0x0, ttl 40, id 24789, offset 0, flags [none], proto: UDP (17), length: 88) 216.239.34.10.domain > 192.168.1.4.8838: 19649*- 1/0/0 www.google.com. AAAA[|domain]
01:08:34.469563 IP (tos 0x0, ttl 64, id 45957, offset 0, flags [none], proto: UDP (17), length: 71) 192.168.1.4.41887 > 216.239.38.10.domain: 2196 [1au] MX? www.google.com. (43)
01:08:34.493793 IP (tos 0x0, ttl 43, id 26352, offset 0, flags [none], proto: UDP (17), length: 110) 216.239.38.10.domain > 192.168.1.4.41887: 2196*- 0/1/0 (82)

Вывод tcpdump предоставляет всю информацию, необходимую для поддержки базы данных pDNS:

  1. Запросы, включая исходный IP-адрес запроса.
  2. Серверы имен, которые в то время ответили на запрос.
  3. Был ли запрос и ответ UDP или TCP.
  4. TTL, предоставленные официальным сервером имен.
  5. Ответ, включая IP-адрес и любую другую информацию, отправленную официальным сервером имен.

Хотя tcpdump - отличный инструмент для демонстрационных целей, он не является хорошим долгосрочным решением для сбора данных pDNS. С другой стороны, Bro Network Security Monitor - популярный инструмент для мониторинга и пересылки DNS-пакетов с кэширующего сервера имен. Фактически, у bro даже есть модуль pDNS под названием bropdns, который отправляет данные в базу данных MySQL. Однако для сбора с более крупных рекурсивных серверов имен или с кластеров рекурсивных серверов имен HADOOP может быть лучшим решением.

Существуют также коммерческие решения, которые могут вводить данные pDNS в любое разработанное решение, некоторые из них требуют больше работы, чем другие, но компании по обеспечению безопасности, такие как Palo Alto и Carbon Black, собирают данные pDNS в рамках своего процесса сбора. Импорт этих данных в базу данных или SIEM поможет сопоставить то, что видят конечная точка и граница, с тем, что видит рекурсивный DNS-сервер. Этот процесс, среди прочего, поможет администраторам безопасности определить, есть ли пробелы в их плане безопасности DNS, например, мошеннические узлы, настроенные на использование других рекурсивных DNS-серверов или действующие в качестве своего собственного рекурсивного DNS-сервера.

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

Например, в последнем разделе говорилось о статье EXPOSURE и 15 чертах, разработанных авторами для выявления подозрительных доменов. Шесть из 15 признаков можно определить, просмотрев рекурсивные журналы DNS. Однако девять признаков требуют pDNS для работы правильных алгоритмов. Первый набор характеристик, требующих pDNS, - это функции на основе ответов DNS, которые включают следующие характеристики:

  1. Количество различных IP-адресов
  2. Количество отдельных стран
  3. Результаты обратного DNS-запроса
  4. Количество доменов, использующих один и тот же IP-адрес

Каждая из этих черт по своей сути неплоха. Например, большинство малых предприятий размещают свои веб-сайты на сервере общего хостинга. Скорее всего, на этом сервере размещены сотни других веб-сайтов, указывающих на один и тот же IP-адрес. Это не значит, что каждый из этих сайтов плохой. Точно так же PTR этого IP-адреса, скорее всего, разрешается в имя хоста самого сервера, а не в какой-либо из доменов, размещенных на этом сервере. С другой стороны, большинство малых предприятий не часто меняют IP-адреса, связанные с записями A в своих доменах, и не обслуживают ответы на запросы из широкого круга стран. Анализируя данные pDNS для всех четырех характеристик функций ответа DNS и сравнивая домен со всеми четырьмя вместе взятыми, аналитик безопасности может лучше понять, насколько подозрительным является домен.

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

  1. Средний TTL
  2. Стандартное отклонение TTL
  3. Количество различных значений TTL
  4. Количество изменений TTL
  5. Процент определенных диапазонов TTL

В зависимости от цели атакуемого домена у него может быть очень низкий TTL (часто TTL для вредоносных доменов устанавливается равным 0). Но есть также допустимые домены с низким TTL, особенно те, которые используют CDN для обслуживания веб-контента. Однако низкие значения TTL для легитимных сайтов, использующих CDN, остаются относительно статичными, тогда как TTL для сомнительных доменов может сильно колебаться в зависимости от назначения домена в данный момент времени. Злоумышленники, как правило, используют определенные значения TTL в большей степени, чем обычно. Диапазоны TTL для легитимных доменов обычно имеют такие значения (в секундах), как 300, 600, 3600, 14 440 и 86 400. Вредоносные домены, как правило, имеют значения вроде 1 или 100. Помимо более низких значений TTL в среднем, чем у большинства доменов, вредоносные домены также используют нестандартные значения TTL и изменяют эти значения TTL чаще, чем легитимные домены. Опять же, вся информация о TTL доступна в ответе на запрос DNS, который хранится как часть сбора данных pDNS.

Домены Fast-flux

Одна из причин того, что вредоносные домены имеют более низкие значения TTL, - это широкое использование доменов fast-flux. Домены Fast-flux используются злоумышленниками как средство сокрытия и защиты своей реальной инфраструктуры. В атаке fast-flux злоумышленник взламывает ряд легких целей, таких как незащищенные компьютеры или небезопасные домашние маршрутизаторы. Затем эти маршрутизаторы используются в качестве туннелей для перенаправления командных и управляющих сообщений и извлеченных данных в реальную инфраструктуру и из нее.

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

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

DNS-брандмауэры и RPZ

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

Существует два типа брандмауэров DNS: локальные и облачные. Локальные брандмауэры DNS устанавливаются непосредственно на рекурсивный сервер и не позволяют пользователям сети достигать подозрительных доменов. Такие компании, как Infoblox и ThreatSTOP, создают эти типы межсетевых экранов, которые обычно используют зоны политики реагирования (RPZ) или черные списки, чтобы обеспечить принудительное применение плохих доменов. Также существуют облачные решения. Вместо того, чтобы управлять принудительным исполнением на месте, с решениями, подобными тому, что предлагает OpenDNS, рекурсивные функции DNS передаются на аутсорсинг поставщику DNS, который отслеживает трафик DNS, исходящий от организации, и ищет известные плохие домены, а также аномальную активность.

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

Рисунок 6.9 Панель предупреждений брандмауэра eSentire DNS.

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

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

Большая проблема с черными списками заключается в том, что ими сложно управлять, и они очень быстро становятся громоздкими. Вот почему команда Internet Systems Consortium во главе с Полом Викси представила RPZ в 2010 году[9]. RPZ - это специально сконструированные файлы зон, которые находятся на рекурсивных DNS-серверах, которые превращают DNS-сервер в своего рода брандмауэр, который при этом полностью ориентирован на доменную активность.

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

Хотя RPZ по сути является файлом зоны, он может перехватывать запросы DNS и отправлять один из четырех ответов. На самом деле, то, что делают RPZ, - это использование того факта, что рекурсивный DNS-сервер может отвечать авторитетным ответом на запрос, даже если рекурсивный сервер на самом деле не является авторитетным.

Четыре ответа политики, которые могут быть возвращены, следующие:

  1. NXDOMAIN
  2. NODATA
  3. NO-OP
  4. Local Data

NXDOMAIN и NODATA работают так же, как и в обычных ответах на запросы DNS. NXDOMAIN означает, что с доменом вообще нет записей, тогда как ответ NODATA означает, что для домена есть записи, но ни одна из них не соответствует запросу. NO-OP, также называемый PASSTHRU, позволяет конкретному запросу получить правильный ответ, даже если остальная часть домена заблокирована другим правилом. Администратор брандмауэра DNS может захотеть разрешить пользователям посещать www.dns-book.net, но не хочет разрешать трафик на любые другие поддомены. Четвертый ответ политики - это локальные данные, который перенаправляет пользователя на локальный сервер или, по крайней мере, на локальный IP-адрес. Этот ответ очень часто встречается у администраторов безопасности, которые хотят сообщить пользователям, что они пытались подключиться к вредоносному домену. Особенно часто в качестве ответа на домен, используемый в фишинг-кампании, эти локальные страницы можно использовать в качестве учебного момента, давая пользователю понять, что они потенциально могут нанести ущерб организации, перейдя по этой ссылке.

Конфигурация и настройка RPZ более подробно обсуждаются в главе 7.

Черные и белые списки и другая информация об угрозах DNS

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

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

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

Та же логика может быть применена и к белым спискам DNS. Есть ряд организаций, у которых есть белые списки DNS, такие как DNSWL и Spamhaus Whitelist, которые предоставляют списки хороших доменов, которые не следует блокировать. Кроме того, многие администраторы DNS используют список в 1 млн доменов Alexa для создания белых списков для своих DNS-серверов.

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

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

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

Выводы

Есть несколько аспектов безопасности DNS. Существует не только физическая озабоченность относительно того, где разместить DNS-серверы, но также существует поддержка самого программного обеспечения DNS. Обеспечение того, чтобы программное обеспечение оставалось полностью пропатченным, а группы безопасности следили за последними объявлениями безопасности от поставщиков DNS, само по себе может потребовать полной занятости.

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

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

Заметки

  1. Measurement Factory, 2016. DNS Survey: Open Resolvers. Measurement Factory, 10 Feb. 2016. Web. 11 Feb. 2016. <http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html>.

  2. Jayan, J., 2015. Easy Creation of Domain Names by Hackers Leaves SMBs Dangerously Exposed. Third Certainty, 21 Sept. 2015. Web. 15 Feb. 2016. <http://thirdcertainty.com/featured-story/easy-creation-of-domain-names-by-hackers-leaves-smbs-dangerously-exposed/>.

  3. Hao, S., Thomas, M., Paxson, V., Feamster, N., Kreibich, C., Grier, C., et al., 2015. Understanding the Domain Registration Behavior of Spammers. The ICSI Networking and Security Group. 23 Oct. 2013. Web. 15 Feb. 2016. <http://www.icir.org/>.

  4. Halvorson, T., Der, N., Foster, I., Savage, S., Saul, L., Voelker, G., 2015. From .academy to .zone: An Analysis of the New TLD Land Rush. Internet Measurement Conference (2015). 28 Oct. 2015. Web. 15 Feb. 2016. <http://conferences2.sigcomm.org/imc/2015/papers/p381.pdf>.

  5. Helming, T., 2015. Where Badness Lurks: A New Threat Cartography. FireEye Cyber Defense Summit 2015.

  6. DomainTools не предоставляет бесплатные услуги авторам, мы просто фанаты этой услуги.

  7. Математика выходит за рамки этой книги.

  8. Bilge, L., Sen, S., Balzarotti, D., Kirda, E., Kruegel, C., 2014. EXPOSURE: A Passive DNS Analysis Service to Detect and Report Malicious Domains. ACM Transactions on Information and System Security (TISSEC) 16.4 (2014). June 2014. Web. 16 Feb. 2016. <http://seclab.nu/static/publications/tissec14_exposure.pdf>.

  9. Исходную презентацию можно посмотреть здесь: https://www.youtube.com/watch?v=0SSWxSYhNc.

Глава 7
Безопасность BIND

Информация в этой главе

Вступление

BIND - безусловно, самый популярный DNS-сервер, используемый сегодня. Согласно одному исследованию, на BIND приходится почти 54% публичных DNS-серверов. BIND настолько популярен, что в том же опросе второе место (34%) было «не сравнимо»[1]. BIND был разработан и до сих пор поддерживается как эталонная реализация протокола DNS. Это означает, что BIND поддерживает любые текущие стандарты DNS, даже менее безопасные. Таким образом, для администраторов DNS, использующих BIND, становится важным понимать риски и ограничивать доступ к ненужным службам.

BIND также имеет репутацию ненадежной сущности. Согласно базе данных Mitre Common Vulnerabilities and Exposures, с 1999 года было зарегистрировано более 60 уязвимостей BIND. Консорциум Интернет-систем (ISC), организация, стоящая за BIND, сообщает о более чем 70 уязвимостях во всех версиях BIND.

Однако в последние годы команда ISC стала более серьезно относиться к безопасности BIND. BIND 9, текущая версия BIND, превратилась в полную переработку кода BIND 8 с особым упором на безопасность. В BIND все еще есть уязвимости в системе безопасности, но они случаются гораздо реже.

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

Прежде чем перейти к остальной части главы, каждый администратор DNS и группа безопасности, ответственная за поддержку установки BIND, должны сделать две вещи:

  1. Убедитесь, что сервер BIND обновлен до последней версии. Учитывая большое количество уязвимостей в старых версиях и легкость, с которой может быть получен отпечаток версии BIND, важно поддерживать текущую версию BIND. Последнюю версию BIND можно найти на веб-сайте ISC по адресу: https://www.isc.org/downloads/bind/.
  2. Будьте в курсе всех рекомендаций по безопасности BIND. ISC публикует все рекомендации по безопасности BIND 9 по адресу: https://kb.isc.org/category/74/0/10/Software-Products/BIND9/ Security-Advisories/. ISC позволяет пользователям подписаться на RSS-канал или список рассылки, чтобы получать уведомления о публикации новых рекомендаций по безопасности.

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

  1. Не запускайте ненужные службы на общедоступном сервере BIND. Убедитесь, что httpd, ftpd, telnetd и другие службы отключены или, в идеале, удалены.
  2. Доступ по SSH должен быть ограничен определенными сетями, и в идеале доступ должен быть ограничен интерфейсом, отличным от интерфейса, отвечающего на запросы DNS.
  3. НИКОГДА не запускайте BIND от имени пользователя root. Используйте непривилегированную учетную запись для запуска BIND, предпочтительно учетную запись, которая используется только для запуска BIND.
  4. Убедитесь, что у любой непривилегированной учетной записи, используемой для запуска BIND, нет прав удаленного доступа к серверу BIND.
  5. Любые файлы, связанные с BIND, особенно файл named.conf и любые связанные файлы зоны, должны принадлежать непривилегированному пользователю BIND и иметь только разрешения, необходимые для работы BIND (например, чтение/запись только пользователем BIND).

Опять же, эти правила применимы не только к BIND; они также применимы к любому общедоступному серверу, который может эксплуатировать организация.

Запуск BIND в окружении chroot

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

Chroot - это собственный инструмент UNIX/Linux, который позволяет администраторам сервера запускать программу в модифицированном корневом каталоге, известном как окружение. Окружение содержит все, что необходимо программе для запуска, и пользователь, которому принадлежит процесс, запущенный в окружении, видит измененный корневой каталог как корень сервера. На практике это означает, что если злоумышленник может использовать уязвимость в программе, и эта уязвимость позволяет злоумышленнику получить доступ к серверу из командной строки, потому что злоумышленник будет работать с тем же уровнем привилегий, что и пользователь, который владеет скомпрометированным приложением, злоумышленник не сможет получить доступ к чему-либо за пределами каталога окружения.

Например, администратор может реализовать окружение chroot, чтобы BIND располагался в /var/named/chroot/var/named, а не в /var/named. Теперь, если злоумышленник скомпрометирует демон BIND и получит доступ к серверу, он сможет получить доступ только ко всему, что находится ниже каталога chroot/, по сути, chroot/ будет выглядеть для злоумышленника как корень /.

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

Есть несколько способов установить BIND в chroot-окружении. Первый и самый распространенный - это загрузить установочный пакет BIND и пройти через одно из множества учебных пособий, доступных в Интернете, отличное руководство, предоставленное Team Cymru[2]. Это работает для организаций, у которых есть выделенный администратор DNS, который может посвятить свое время, чтобы гарантировать, что исправления установлены своевременно и могут гарантировать, что каждое обновление не окажет существенного влияния на инфраструктуру DNS организации.

Второй способ установить BIND в chroot-окружении - это посмотреть, есть ли в диспетчере пакетов базовой операционной системы доступный пакет, например, с помощью диспетчера пакетов yum в CentOS:

[root@server ~]# yum list bind-chroot
Available Packages
bind-chroot.x86_64    30:9.3.6-25.P1.el5_11.8    updates

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

Обратной стороной является то, что это передает безопасность установки BIND chroot в руки третьей стороны и остается надеяться на то, что эта третья сторона будет обновлять исправления и пакет, особенно когда сообщается о критических уязвимостях безопасности.

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

Способы удаления отпечатков

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

Одна из самых простых вещей, которые администратор DNS может сделать для сдерживания злоумышленников, - это отключить информацию о версии в разделе параметров файла named.conf. Злоумышленник может определить, какая версия сервера BIND работает, выполнив следующую команду:

dig @192.168.1.15 version.bind chaos txt

Что в неотредактированной конфигурации BIND возвращает что-то вроде этого:

;; ANSWER SECTION:
version.bind. 0 CH   TXT "9.9.5-3ubuntu0.8-Ubuntu"

Он не только предоставляет версию BIND, работающую на сервере, но также предоставляет базовую операционную систему. Ответ на запрос можно изменить, отредактировав файл named.conf, добавив следующую строку в раздел параметров:

version "Unknown";

И теперь запрос вернет следующее:

;; ANSWER SECTION:
version.bind. 0 CH TXT "Unknown"

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

Любой ответ на запрос version.bind

Поскольку запрос version.bind не реализован на многих популярных DNS-серверах, потенциально может быть показан любой ответ, предоставляемый запросом. Хотя BIND не дает администраторам DNS возможности отключить запрос version.bind, это делают другие поставщики DNS, такие как Knot и Microsoft DNS. По возможности лучше полностью отключить эту функцию.

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

{
    fingerprint => $iq[3],
    header => $qy[2],
    query => $nct[2],
    ruleset => [
    {
        fingerprint => $iq[4],
        result => {
        vendor => "ISC",
        product => "BIND",
        version => "9.3.0 -- 9.3.6-P1"
    },

fpdns рассматривает «пограничные ответы на запросы», другими словами, ответы, уникальные для конкретного DNS-сервера. Каталогизируя эти ответы, инструменты могут сузить DNS-сервер. В случае приведенного выше фрагмента кода iq[3], qy[2] и nct[2] указывают, что это версия BIND, эти ответы на запросы выглядят следующим образом:

"1,QUERY,0,0,0,1,0,0,NOERROR,. + ,. + ,. + ,. + ", #iq3
"0,$NOTIFY,0,1,1,0,1,1,NOTIMP,0,0,0,0", #qy2a
". IN A",  #nct2

Это последняя строка, iq[4], которая сужает версию до более конкретной версии BIND, ответ на запрос iq[4] выглядит следующим образом:

"1,$NOTIFY,0,0,1,1,0,1,FORMERR,1,0,0,0",  #iq4

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

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

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

Ограничение скорости ответа

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

Для RRL в BIND требуется как минимум версия 9.10, и BIND должен быть скомпилирован с опцией -enable-rrl на этапе настройки установки. После того, как BIND скомпилирован с включенной поддержкой RRL, активировать его так же просто, как добавить оператор в раздел параметров файла named.conf:

rate-limit { responses-per-second 5; };

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

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

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

rate-limit {
    responses-per-second 5;
    log-only yes;
};

Этот фрагмент будет реализовывать то же правило, но будет только регистрировать результаты, а не отбрасывать трафик.

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

rate-limit {
    responses-per-second 5;
    exempt-clients { 10.100.50.8; };
};

Это позволит DNS-серверу отвечать на любой запрос, сделанный 10.100.50.8, независимо от того, сколько запросов в секунду выполняется.

Запросы и переводы

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

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

options {
    // Do not allow queries to the cache
    allow-query-cache { none; };
    // Disable recursive queries
    recursion no;
};

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

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

acl blacklist { 10.10.50.3; 192.168.10.0/24; };
options {
    blackhole { blacklist; };
};

Этот набор команд создает ACL, называемый blacklist, который состоит из одного IP-адреса 10.10.50.3 и сетевого блока 192.168.10.0-255, затем он использует команду параметров blackhole для игнорирования всех запросов к этим IP-адресам и от них. Обратите внимание, что опция blackhole - самый крайний метод для этого, сервер BIND не только не будет принимать запросы с этих IP-адресов, но и не будет запрашивать их. Это означает, что важно убедиться, что в наборе заблокированных IP-адресов нет хостов, с которыми серверу BIND потребуется связываться в будущем.

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

Этот процесс начинается с ограничения передачи зоны (запросы AXFR) только тем серверам, которым необходимо видеть полную зону. Для этого добавьте следующую строку в раздел глобальных параметров файла named.conf:

allow-transfer { none; };

Любая команда в разделе глобальных параметров файла named.conf становится поведением по умолчанию для BIND, поэтому этот оператор предотвращает любой ответ на запрос AXFR. Следующим шагом является использование списков ACL для создания правил, позволяющих вторичным серверам имен выполнять передачу зон. Например, если в организации есть домен cryptodns.com с основным сервером имен 192.168.1.15 (ns1.cryptodns.com) и дополнительным сервером имен 10.100.50.8 (ns2.cryptondns.com). Администратор DNS может редактировать named.conf, чтобы этот DNS-сервер мог выполнять передачу зон. Начните с создания ACL:

acl "cryptodns" {
    192.168.1.15; // ns1.cryptodns.com
    10.100.50.8;  // ns2.cryptodns.com
};

Затем разрешите переводы именно в этом домене:

zone "cryptodns.com" {
    type master;
    file "/var/named/cryptodns.com";
    allow-transfer { localhost; cryptodns; };
};

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

Использование TSIG для подписки передач зоны

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

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

Чтобы транзакция TSIG работала, первым делом необходимо сгенерировать общий секретный ключ. Этот ключ может быть создан вручную (при условии, что он правильно закодирован в base-64) или сгенерирован любым количеством способов, включая использование встроенных функций сервера BIND:

dnssec-keygen -a hmac-sha512 -b 256 -n HOST cryptodns-key

Эта команда генерирует ключ HOST с использованием кода аутентификации сообщения HMAC-SHA512 длиной 256 бит, который хранится в файле с именем cryptodns-key. В этом случае команда сгенерировала общий секретный ключ, который выглядит следующим образом:

KYe4a0U6oG7NdaOzhWAlO213jF+ocn9ftTSonVrQmvA=

Следующим шагом является добавление ключа в файл named.conf как первичного, так и вторичного серверов имен:

key cryptodns {
    algorithm hmac-sha512;
    secret "KYe4a0U6oG7NdaOzhWAlO213jF+ocn9ftTSonVrQmvA=";
};

Очевидно, что публикация такого общего секретного ключа в небезопасном файле named.conf в первую очередь сводит на нет цель защиты транзакций. Важно убедиться, что доступ к файлу named.conf ограничен, и только пользователь BIND имеет доступ для чтения/записи в файл. Если это невозможно, поскольку несколько пользователей должны вносить изменения в файл named.conf, можно сохранить ключ в отдельном, более ограниченном файле. После этого администраторы DNS могут просто добавить файл ключа с помощью инструкции include в файле named.conf:

include "/var/named/cryptodns.key";

Следующий шаг - заставить два хоста использовать вновь сгенерированный ключ при создании пауз. Используя приведенный выше пример, когда ns1.cryptodns.com назначается IP-адрес 192.168.1.15 и ns2.cryptodns.com назначается IP-адрес 10.100.50.8, необходимы два утверждения. На ns1.cryptodns.com инструкция будет выглядеть так:

server 10.100.50.8 {
    keys { cryptodns ;};
};

На ns2.cryptodns.com утверждение будет другим:

server 192.168.1.15 {
    keys { cryptodns ;};
};

Теперь все запросы DNS между двумя хостами будут включать хеш TSIG из общего секрета (общий секрет никогда не передается между двумя хостами).

Наконец, чтобы предотвратить передачу на хосты, которые не имеют надлежащей ключевой информации, в раздел параметров named.conf можно добавить следующую строку:

allow-transfer { key cryptodns; };

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

Зоны политики ответа

В главе 6 представлена концепция Зон политики ответа (Response Policy Zones (RPZ)) как способ простого управления черными и белыми списками непосредственно на DNS-сервере. RPZ также предоставляют простой способ подписаться на стороннюю аналитику угроз, предотвращая посещение пользователями потенциально вредоносных сайтов.

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

Настроить RPZ или несколько RPZ в BIND относительно просто. Он начинается с добавления команды в раздел параметров named.conf:

response-policy {
    zone "rpz.blacklist";
    zone "rpz.mw.surbl.org";
    zone "rpz.ph.surbl.org";
    zone "rpz.spamhaus.org";
};

Строки выше показывают четыре разные зоны. Первая - это локальная зона, созданная командой безопасности и администраторами DNS. Две других - это услуги по подписке, доступные от SURBL и Spamhaus. Обе эти организации, наряду с другими компаниями, такими как Farsight Security и Internet Identity, предлагают доступ к RPZ на основе подписки. Все эти компании используют свои уникальные представления о вредоносной активности, происходящей в Интернете, для составления списков плохих доменов и их регулярной доставки в виде обновлений RPZ своим клиентам. Некоторые из этих компаний, например SURBL, предлагают возможность подписаться на разные RPZ, такие как вредоносные программы и фишинговые RPZ, или сделать все автономным. Конечно, когда дело доходит до безопасности, нельзя подходить ко всем под одну гребенку. Некоторым организациям необходимо более агрессивно блокировать потенциально плохие домены; других больше беспокоят ложные срабатывания. С этой целью ряд поставщиков RPZ действительно предлагают настраиваемые каналы RPZ, SURBL, Spamhaus и Farsight Security являются примерами компаний, которые это делают, но это хороший вопрос, который следует задать любому поставщику RPZ, который организация рассматривает для использования.

Путаница

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

Следующим шагом, начиная снизу, является создание записей файла зоны в файле named.conf для каждой из зон, перечисленных политикой ответа. И SURBL, и Spamhaus RPZ являются подчиненными зонами по отношению к главному серверу, который находится на полномочном сервере имен, контролируемом SURBL и Spamhaus, соответственно. Создание записей файла зоны будет выглядеть так:

zone "rpz.surbl.org";
    type slave;
    masters { [IP Address of Master Nameserver]; };
    file "slave/rpz.mw.surbl.org";
    allow-query { localhost; };
    allow-transfer { none; };
};
zone "rpz.spamhaus.org";
    type slave;
    masters { [IP Address of Master Nameserver]; };
    file "slave/ rpz.spamhaus.org";
    allow-query { localhost; };
    allow-transfer { none; };
};

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

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;alamman.com. IN A
;; AUTHORITY SECTION:
rpz.mw.surbl.org. 180 IN SOA dev.null.  zone.surbl.org.  1459306070  180 180 604800 180

Работа с третьими лицами

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

Верхняя запись, rpz.blacklist, представляет собой локальный файл RPZ, который заполняется на основе сведений, собранных группами безопасности, и снова добавляется так же, как и стандартный файл зоны, путем добавления утверждения, аналогичного этому, в файле named.conf:

zone "rpz.blacklist" {
    type master;
    file "master/rpz.blacklist";
    allow-query { localhost; };
};

Это указывает BIND искать в файле master/rpz.blacklist информацию о зоне, а также предотвращает ответ сервера BIND на любые запросы, исходящие не с localhost.

Последний шаг - собрать файл зоны, помните из главы 6, что есть четыре возможных ответа на доменное имя в RPZ: NXDOMAIN, NODATA, NO-OP и Local Data. Вот как будут выглядеть образцы файлов зон в BIND. Начнем с NXDOMAIN и NODATA:

mgm88tv.com CNAME . ; Locky
jeansowghsqq.com CNAME . ; TeslaCrypt
9hrds.wolfcrap.at CNAME * ; TeslaCrypt

Первые две записи - это записи NXDOMAIN; ответ NXDOMAIN полностью отрицает существование домена. Каждая из этих записей превращается в CNAME, указывающую на корневой домен «.» и вернет правильный ответ. Третья запись, wolfcrap.at, возвращает ответ NODATA, который подтверждает существование домена, но сообщает, что для этого домена нет данных. Результат для конечного пользователя тот же: он не может получить доступ ни к одному из доменов.

Иногда достаточно просто не ответить. В образовательных целях или для сокращения количества обращений в службу поддержки может потребоваться отправить пользователей на страницу перенаправления. Эту страницу перенаправления можно использовать для объяснения пользователям, почему они получили эту страницу, и, возможно, для советов по дальнейшим действиям. Эту страницу перенаправления часто называют огороженным садом или Local Data на языке BIND. Записи для локальных доменов данных выглядят примерно так:

isityouereqq.com  A 192.168.1.4 ; TeslaCrypt
*.jambola.com CNAME * .wall.cryptodns.com. ; CryptoWall

Первая запись - это прямая запись A, которая указывает isityouereqq.com на локальный IP-адрес 192.168.1.4, где есть веб-сайт, настроенный, чтобы сообщить пользователю о потенциальной проблеме с веб-сайтом, который он пытался посетить. Вторая запись делает то же самое, но использует запись CNAME, а также запись с подстановочными знаками. В этом случае запись перенаправит любой поддомен jambola.com на тот же поддомен на wall.cryptodns.com, где, опять же, будет веб-сайт, сообщающий пользователю о потенциальной проблеме с доменом, который он пытался посетить.

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

*.salesforce.com CNAME rpz-passthru. ; SalesForce - sales
dropbox.com CNAME rpz-passthru ; Drop Box - engineering

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

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

response-policy {
    zone "rpz.whitelist" policy PASSTHRU;
};

И полная запись политики ответа будет выглядеть так:

response-policy {
    zone "rpz.whitelist" policy PASSTHRU;
    zone "rpz.blacklist";
    zone "rpz.surbl.org";
    zone "rpz.spamhaus.org";
};

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

Логирование

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

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

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

Ведение системного журнала можно включить в операторе ведения журнала в named.conf:

logging {
    channel default_syslog { severity info; };
};

В BIND 9 и более поздних версиях оператор регистрации анализируется последним, поэтому не имеет значения, где он находится в файле named.conf. В журналах BIND существует семь уровней серьезности: critical, error, warning, notice, info, debug и dynamic. Первые пять, важные для информации, являются стандартными уровнями системного журнала, поэтому их можно отправлять в средство системного журнала. Последние два debug и dynamic уникальны для BIND и должны быть записаны в локальный файл:

logging {
    channel default_syslog { severity info; };
    channel default_debug {
        severity dynamic;
        file "/var/named/logs/debug.log";
};

Теперь есть два канала, один для событий журнала, которые являются информацией и выше, которые будут отправлены на сервер системного журнала, второй - для событий на динамическом уровне, они будут записаны локально в debug.log. Конечно, важно, чтобы debug.log имел правильные разрешения и мог быть просмотрен/записан только владельцем процесса BIND.

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

logging {
channel default_syslog {
    severity info;
    print-category yes;
    print-time yes;
    print-severity yes;
};
channel default_debug {
    severity dynamic;
    file "/var/named/logs/debug.log";
    print-category yes;
    print-time yes;
    print-severity yes;
};

Последний шаг - определить, какие категории на каком объекте регистрируются. BIND поддерживает 20 категорий и одну специальную категорию. Категории: client, config, database, delegation-only, dispatch, dnssec, general, lame-servers, network, notify, queries, resolver, rpz, rate-limit, security, unmatched, update, update-security, xfer-in и xfer-out. Каждой категории может быть назначен другой профиль ведения журнала в зависимости от количества доступных каналов:

category general { default_syslog; };
category security { default_debug; default_syslog; };
category config { default_syslog; };
category resolver { default_syslog; };

Обратите внимание, что журналы можно отправлять более чем на один канал. Если администраторам DNS необходимо иметь доступ к файлам журналов для устранения проблем, но им не нужен широкий доступ к LMS, журналы можно направить в оба места.

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

logging {
    channel default_syslog {
        severity info;
        print-category yes;
        print-time yes;
        print-severity yes;
    };
    channel default_debug {
        severity dynamic;
        file "/var/named/logs/debug.log";
        print-category yes;
        print-time yes;
        print-severity yes;
    };
    category default { default_syslog; default_debug; };
};

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

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

Выводы

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

Заметки

  1. DNS Survey October 2010. Measurement Factory, 10 Oct. 10. Web. 27 Feb. 2016. <http://dns.measurement-factory.com/surveys/201010/>.

  2. Руководство по chroot является частью шаблона Secure BIND, который публикует Team Cymru, он доступен на их веб-сайте по адресу: https://www.cymru.com/Documents/secure-bindtemplate.html.

Глава 8
Безопасность DNS в Windows

Информация в этой главе

Вступление

По большинству измерений Windows является второй по популярности платформой DNS-серверов, примерно треть всех экземпляров работает в Интернете[1]. Малое предприятие может настроить DNS-сервер Windows с помощью нескольких щелчков мышью, а более крупная сеть может управлять несколькими избыточными серверами. в комплекте с динамическими обновлениями и аутентификацией клиента. Администраторам, обеспечивающим безопасность среды Windows DNS, следует рассмотреть несколько поверхностных областей атаки: доступ к файлам на самом DNS-сервере, сетевой доступ к серверу в брандмауэре, сетевой доступ из общедоступного Интернета и способы изменения инфраструктуры. при неожиданных обстоятельствах. Каждый из них будет подробно рассмотрен. Обратите внимание, что эта глава не будет общим руководством по DNS в Windows, а сосредоточится на областях, критически важных для безопасности.

Но сначала краткий обзор последних проблем безопасности с Windows DNS, чтобы понять, какие атаки возможны. В 2006 году Microsoft исправила уязвимость клиентского переполнения буфера в своем резолвере DNS. Она был помечена как MS06-041 или CVE-2006-3440. Если злоумышленник может заставить клиента запросить конкретное имя хоста, вредоносный DNS-сервер может отправить созданный ответ, который воспользуется уязвимостью и получит доступ на уровне системы к цели. По описанию Microsoft, «уязвимость может быть использована злоумышленником, который убедил пользователя открыть специально созданный файл или просмотреть специально созданный веб-сайт»[2].

В 2007 году Microsoft выпустила исправление с маркировкой MS07-029 или CVE-2007-1748. Это была удаленная эксплуатация уязвимости переполнения буфера в службе управления DNS RPC. Обратите внимание, что это была не уязвимость, связанная с самим трафиком DNS, а скорее код, который управлял настройками DNS-сервера. Его можно использовать через порты RPC 139 и 445[3]. Большинство предприятий блокируют эти порты на брандмауэре, но они часто открыты в сети.

В 2015 году Microsoft объявила об уязвимости в том, как DNS-сервер Windows анализирует запросы. Она был помечена как MS15-127 или CVE-2015-6125. Это была уязвимость «использования после освобождения», и любой, кто мог отправлять запросы на DNS-сервер, мог удаленно эксплуатировать ее. По заявлению Microsoft, это может привести к тому, что злоумышленник получит доступ к серверу из локальной системной учетной записи[4]. Это особенно беспокоит администраторов DNS, поскольку любые незащищенные системы, обрабатывающие запросы из Интернета, могут быть захвачены злоумышленниками.

Защита файлов DNS В Windows

Как и в BIND, файлы зон составляют основу настроек Windows DNS. Они хранят все записи домена, а также делегирования и подписи DNSSEC. Разрешения для файлов зоны будут определять, кто может обновлять эти записи. Windows предоставляет графический интерфейс, называемый диспетчером DNS, чтобы помочь администраторам настроить файл зоны. Корпорация Майкрософт также предоставляет контрольные списки действий по обеспечению безопасности различных версий своих DNS-серверов, из которых вытекают многие из этих предложений.

Windows, как и BIND, имеет разные концепции домена и зоны. Все субдомены могут находиться в одной зоне или могут быть перемещены в отдельные зоны по желанию. Администратор обычно создает новую зону при добавлении нового DNS-сервера для управления частью домена. Могут быть и другие случаи, например, если один из поддоменов часто меняется, а другой - нет, когда также имеет смысл создавать отдельные зоны в одном домене.

В Windows есть несколько различных типов зон: первичные зоны, вторичные зоны, заглушки, прямые зоны и условные прямые зоны. Как и в случае с BIND, на первичном сервере файл зоны должен храниться локально, либо в файловой системе, либо в Active Directory (AD). При размещении вторичной зоны какой-либо другой сервер будет действовать как первичная зона, а вторичный сервер не будет хранить файл зоны локально. Вместо этого он должен иметь сетевой доступ к первичному серверу для получения содержимого зоны. Как и в BIND, в Windows есть понятие заглушек, которые не следует путать с резолверами заглушек. Зона-заглушка может отвечать на запросы, но только путем предоставления авторитетных серверов для зоны. Это может быть полезно, если в сети много дочерних зон и администраторы хотят ограничить количество рекурсивных запросов, попадающих во внутренний корень[5]. Наконец, передние зоны и условные передние зоны можно рассматривать как решатели. Они будут отправлять запросы вверх по течению, чтобы найти ответы от имени клиентов.

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

DNS-сервер должен знать IP-адрес корня, чтобы загрузить всю остальную информацию. В случае сервера, который будет отвечать на запросы для Интернет-доменов, эту информацию можно получить из IANA в корневом файле подсказок (https://www.iana.org/domains/root/files). При администрировании внутренней интрасети или сети с воздушными зазорами это будет другой файл, указывающий на внутренний корень. Если это неправильно сконфигурировано, это может привести к утечке внутренних запросов в общедоступный корень DNS. Например, компания использует расширение .internal для частных сайтов в своей локальной сети. Если используется только общедоступный корень DNS, то запросы будут направлены в корень и завершатся ошибкой. Если используются как общедоступный корень, так и внутренний корень, сервер может выполнять циклические запросы к корню, и в этом случае некоторые из этих запросов будут протекать до того, как запись SOA для .local будет кэширована. Напомним, что полный запрос будет отправлен в корень и, возможно, будет виден всем, кто отслеживает это соединение. Если корень настроен правильно, при этом .local принадлежит внутреннему серверу, а все остальное - общедоступному корню, опечатки все равно могут быть направлены за пределы сети. По этой причине важно учитывать чувствительность внутренних имен хостов при смешивании внутреннего и внешнего разрешения на одном сервере. И запросы следует отслеживать на предмет непредвиденных утечек.

Зонами можно управлять путем редактирования текстового файла или через графический интерфейс диспетчера DNS. Даже если администратор не регулярно вносит изменения в настройки DNS, полезно просмотреть меню, чтобы понять, какие параметры доступны. При создании зоны Windows предоставит возможность сделать ее интегрированной в AD. Это означает, что каноническая копия файла зоны будет храниться в AD, а не в файле на диске. Это доступно только в том случае, если сервер является контроллером домена, но он включает некоторые дополнительные функции, такие как безопасные динамические обновления, которые будут описаны в следующем разделе.

Как описано ранее в книге, инфраструктура DNS может использоваться для обратных DNS-запросов, которые сопоставляют IP-адрес с сетевым именем. Эти зоны называются зонами обратного просмотра, а иногда обычные DNS-запросы называются прямыми поисками, чтобы различать эти две зоны. Записи обратной зоны можно управлять так же, как записями прямой зоны, либо через графический интерфейс Windows, либо через командную строку. В файлах зоны обратные записи хранятся как записи PTR в обратном четырехточечном формате как часть домена in-addr.arpa. Например, обратная запись для 1.2.3.4 будет 4.3.2.1.in-addr.arpa. Записи обратной зоны могут быть особенно важны, когда в сети есть общедоступные службы. Например, фильтры спама часто выполняют обратный поиск по входящей электронной почте, чтобы узнать, исходит ли адрес отправителя из ожидаемого места.

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

Обратите внимание, что Windows может хранить резервные копии файлов зон, не интегрированных в AD, в папке %systemroot%/DNS/Backup. Обычно они имеют те же разрешения, что и обычный файл зоны. Если файл зоны содержит конфиденциальную информацию, администраторы должны позаботиться о защите этих файлов так же, как и обычных файлов зоны[6].

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

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

Рисунок 8.1 Делегирование зоны DNS в Windows Server 2012.

Сколько людей должны иметь доступ к файлам зоны? Конечно, на этот вопрос сложно дать конкретный ответ. Для любой большой сети ответ почти наверняка два или больше. По опыту авторов, предприятия, для которых безопасность считается критически важной, часто стараются поддерживать это число ниже 10. ICANN предоставила некоторую количественную оценку при проектировании корневой зоны DNSSEC. Они предполагают, что «уровень недобросовестности» для любого отдельного администратора составляет 5%, что, по-видимому, является вероятностью того, что они будут готовы скомпрометировать ключи в течение любого периода времени. В корневом каталоге DNSSEC это число используется для разработки такой схемы сочетания клавиш, при которой вероятность фактического взлома составляет менее одного на миллион[8]. Используя коэффициент нечестности ICANN, вероятность компромисса со стороны любого из 3 администраторов составляет около 14%, а со стороны любого из 10 администраторов - около 40% (один минус коэффициент честности, увеличенные до количества людей). Если это кажется высоким, помните, что это вероятность любого компромисса, происходящего в течение любого периода времени, и не учитывает дополнительные уровни безопасности. Например, при хорошем аудите риск будет значительно ниже.

Если администратор включит DNSSEC в зоне Windows, возникнут дополнительные соображения относительно того, как управлять ключами. Различные типы ключей подробно обсуждаются в главе 10, но вкратце есть как ключ подписи ключа (KSK), так и ключ подписи зоны (ZSK). KSK используется для создания ZSK, а ZSK, как следует из его названия, используется для подписи файла зоны. RFC DNSSEC рекомендуют хранить KSK на отдельном оборудовании, в идеале - полностью автономно. Но в большинстве сред Windows ключи хранятся на основном сервере. Windows предоставляет графический интерфейс как для генерации ключей, так и для управления их сменой позиций. В Windows Server 2012 это называется службой Key Master, и ее можно включить в качестве роли в AD.

Динамическое управление DNS

Предположим, в сети работает DHCP, и каждая рабочая станция называет каждую рабочую станцию именем человека, которому она назначена (как обсуждается в разделе «Многоадресная рассылка» далее в книге, это может быть плохой идеей, но это всего лишь пример). Если пользователь A хочет подключиться к общему сетевому ресурсу на компьютере пользователя B, как он может это сделать? Большинство сетей реализуют это с помощью динамических обновлений DNS, когда каждая рабочая станция будет периодически сообщать DNS-серверу свое имя хоста и назначенный DHCP IP-адрес. Затем пользователь A может запросить имя пользователя B, получить его IP-адрес от DNS-сервера и установить соединение. Протокол динамического обновления описан в RFC 2136, первый выпуск в 1997 году.

Но что может помешать вредоносной рабочей станции сообщить свое имя хоста, например, «mail.example.com», и перехватить все сеансы электронной почты? В самом протоколе этому ничего не мешает. Как сказано в RFC 2136: «В отсутствие [RFC2137] или эквивалентной технологии протокол, описанный в этом документе, позволяет любому, кто может подключиться к официальному серверу имен, изменять содержимое любых зон на этом сервере»[9]. RFC рекомендует защищать обновления с помощью общих ключей TSIG. Но это создает две новые проблемы: как безопасно распределить ключи потенциально тысячам или десяткам тысяч хостов в сети и как аутентифицировать новые системы, присоединяющиеся к домену. Windows решает обе эти проблемы путем интеграции DNS-клиента с AD. AD выполняет проверку подлинности с помощью существующих учетных записей, а затем генерирует ключ, который клиент DNS может использовать для обновлений.

Динамические обновления будут отправляться каждый раз при изменении IP-адреса рабочей станции. Это включает добавление или удаление IP-адреса из сетевого интерфейса, получение аренды DHCP или при запуске компьютера. Иногда это может привести к противоречивому поведению. Например, запуск «ipconfig/release» на хосте с неправильно настроенным сетевым подключением может фактически привести к зависанию клиента при попытке отправить сообщение об обновлении на DNS-сервер.

Протокол динамических обновлений описан в RFC 2136 и полностью работает в пакетах DNS. Он добавляет новый Opcode 5 для запроса типа обновления. Он также добавляет несколько новых кодов ответа, таких как RCODE 10, указывающих, что запрошенное обновление не принадлежит целевой зоне. Одна из ситуаций, связанных с динамическими обновлениями, заключается в том, как обрабатывать хост, который переходит в автономный режим, пока он зарегистрирован на DNS-сервере. Windows решает эту проблему, периодически «очищая» записи, которые не обновлялись более определенного времени.

Что произойдет, если злоумышленники отправят поддельные сообщения динамического обновления? Это позволит им подделывать пакеты обновлений на сервер, чтобы утверждать, что целевое имя хоста теперь работает на IP-адресе злоумышленника, и его можно использовать в качестве механизма для перехвата соединений, предназначенных для системы жертвы. До выпуска исправления в 2009 году серверы Windows были уязвимы для этого типа атак, нацеленных на прокси-сервер. Как описано в CVE-2009-0093, злоумышленник может зарегистрировать имя хоста «wpad» с помощью динамических обновлений, в результате чего другие хосты в сети попытаются использовать указанный IP-адрес в качестве прокси-сервера. Это, конечно, может позволить злоумышленнику читать или изменять веб-трафик с других хостов в сети[10].

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

К счастью, Windows включает функцию безопасного динамического обновления для защиты от поддельных обновлений. Он будет включать одноразовый ключ, совместно используемый клиентом и сервером при отправке пакетов обновления. Это похоже на использование ключей TSIG в пакетах DNS для аутентификации между клиентом и сервером, но технически это другой протокол, называемый GSS-TSIG. Ключи генерируются как ключи сеанса Kerberos и используются только один раз для обновления. Они отправляются как записи TKEY. Чтобы включить синхронизацию ключей, файл зоны должен управляться AD, а не плоским файлом, чтобы работали безопасные обновления. Важно отметить, что это просто защищает канал, по которому передаются обновления, чтобы предотвратить поддельные обновления, и не обеспечивает никакой дополнительной аутентификации клиентов, когда они присоединяются к AD. Например, система AD, которая позволяет любому клиенту в сети присоединиться к домену, по-прежнему уязвима для поддельных динамических обновлений. Рекомендуется использовать как безопасные обновления, так и методы строгой аутентификации для самого домена. Также важно отметить, что трафик Secure Dynamic Update не шифруется при передаче, поэтому любой, кто может прослушивать сеть, может видеть полное содержимое обновлений. Это может оказаться особенно проблематичным в сетях, где сегментация гостевой сети не выполняется должным образом. Это может позволить неаутентифицированным пользователям (в том числе сидящим на парковке с банкой Pringles) прослушивать DNS-трафик, тем самым раскрывая внутренние соглашения об именах.

Windows позволяет динамическое обновление для каждой зоны. Его можно включить в диспетчере DNS, как показано на рис. 8.2.

Рисунок 8.2. Включение безопасных обновлений в Windows DNS.

Запросы и переводы

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

Рисунок 8.3 Ограничение передачи зон в Windows DNS.

В некоторых случаях администраторы решают использовать DNS в так называемой конфигурации с разделенным горизонтом. Это ограничит количество выполняемых запросов в зависимости от источника трафика. Наиболее распространенный сценарий - когда DNS-сервер выступает в качестве авторитетного источника как для общедоступных доменов, так и для доменов только для внутреннего пользования. До Windows Server 2016 основным способом запуска этой конфигурации была установка двух отдельных DNS-серверов. Было известно, что это создает проблемы в управлении, например, при попытке частичной передачи зон или при ручном редактировании обоих файлов. Начиная с версии 2016 Windows Server включает функцию, называемую DNS-политиками, которая может реализовывать разные представления одной и той же зоны. Это рекомендуемый способ включить разделение горизонтов. Microsoft предоставляет следующие примеры команд для настройки записи с различными внутренними и внешними ответами:

Add-DnsServerZoneScope -ZoneName <zone> -Name "internal"
Add-DnsServerResourceRecord -ZoneName <zone> -A -Name <hostname> -IPv4Address <External IP>
Add-DnsServerResourceRecord -ZoneName <zone> -A -Name <hostname> -IPv4Address <Internal IP> -ZoneScope "internal"
Add-DnsServerQueryResolutionPolicy   -Name   "SplitBrainZonePolicy" -Action ALLOW -ServerInterface "eq,10.0.0.56" -ZoneScope "internal,1" -ZoneName <zone>

Обратите внимание, что IP-адрес «10.0.0.56» является условным и должен быть заменен IP-адресом внутреннего интерфейса DNS-сервера. После выполнения этих команд сервер будет отвечать записью «Internal IP» для запросов от внутреннего интерфейса и «External IP» для всех остальных.

Эту настройку также можно использовать для так называемых DNS-прокси. Этот термин может означать разные вещи в разных контекстах, тем более что любой рекурсивный резолвер, по сути, выполняет роль прокси. Но обычно это относится к управлению локализацией или маршрутизацией запросов на основе некоторых критериев. Некоторыми гнусными примерами являются сервисы, которые избегают геофильтрации потокового мультимедийного контента. Если, например, Netflix заблокирован в определенной стране, сервер будет маршрутизировать эти DNS-запросы через резолвер в разрешенной стране, но все остальные запросы будут маршрутизироваться обычным образом. Более законным использованием могут быть другие способы принудительного разделения внутренних и внешних запросов. Вместо использования сервера с разделенным горизонтом, можно запускать отдельные внутренние и внешние серверы и использовать DNS-прокси для маршрутизации запросов в зависимости от интерфейса и запрашиваемого домена. Это менее распространенная конфигурация, но она может получить больше использования с новыми функциями в Windows Server 2016.

DNS на рабочих станциях Windows

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

Windows следует несколько сложному алгоритму разрешения, в основном из-за обратной совместимости со старыми протоколами. Скажем, пользователь запрашивает www.example.com. Сначала Windows проверит файл hosts, который обычно хранится в папке %system32%\etc\hosts. Если он содержит ответ, Windows будет использовать его без выполнения каких-либо сетевых запросов. Обратите внимание, что этим также можно управлять через API, поэтому, если администратор хочет искать статические записи, ему придется как проверять файл, так и искать записи, которые были программно добавлены на этом хосте. Затем Windows проверит свой кеш.

Примечание. Windows отображает содержимое своего DNS-кеша с помощью этой команды:

ipreconfig/displaydns

Кеш можно очистить с помощью команды:

ipconfig/flushdns

Если запись не кэширована, Windows запросит настроенный DNS-сервер. Еще одна распространенная тактика вредоносных программ - настроить зараженный хост на использование другого DNS-сервера, контролируемого злоумышленником. Это позволяет им отвечать поддельными записями, пока сохраняется настройка. Многие предприятия будут останавливать эти запросы, блокируя ложный трафик порта 53 на брандмауэре, но пользователи, работающие дома, по-прежнему могут быть затронуты. Наконец, если Windows не получает ответа от DNS-сервера, она попытается выполнить запрос через NetBIOS[11]. Это часто упускаемый из виду аспект протокола. Многие сети создают надежную инфраструктуру DNS и предполагают, что это единственное, что будут использовать клиенты. Но если эта инфраструктура выйдет из строя или если злоумышленники ее заблокируют, рабочие станции с радостью отреагируют на ответы NetBIOS[12].

Windows и DDoS

Как обсуждалось ранее в книге, DDoS-атаки - распространенная проблема с инфраструктурой DNS. Сети могут быть задействованы либо в качестве цели атаки, либо в качестве невольного участника, и администраторы должны подготовиться к любому сценарию. В Windows есть три области, которые необходимо изучить: так называемые ответы «вне бейливика» (out of bailiwick), ограничение скорости ответа (RRL) и конфигурация BCP-38. По состоянию на 2016 год все три все еще активно обсуждаются в сообществе DNS, поэтому рекомендации могут измениться в зависимости от новых разработок.

Если сервер настроен как полномочный сервер имен, но не как рекурсивный резолвер, как он должен отвечать на рекурсивные запросы? С технической точки зрения, как он должен отвечать на запросы, для которых он не является авторитетным? Один из подходов - игнорировать их или вернуть ошибку. Исторически DNS всегда старался предоставить полезную информацию, поэтому часто возвращается «ответ восходящей ссылки», содержащий файл корневых подсказок. Логика заключается в том, что клиент может запросить корень, чтобы начать поиск фактического авторитетного сервера. Эти ответы называются «из-под залога», потому что сервер не является для них полномочным. В действительности, большинство резолверов игнорируют ответы вне бейливика, поскольку их можно рассматривать как форму загрязнения кеша. И хотя, казалось бы, безобидный, практика возврата корневых подсказок может использоваться в атаках с усилением DNS, поскольку это относительно большой ответ. Злоумышленник может воспользоваться этим, запросив DNS-серверы на предмет неавторизованных или несуществующих доменов. Для администраторов рекомендуется отключить это поведение, поскольку оно не дает клиентам особой пользы. Начиная с Server 2016, Windows по умолчанию отвечает ошибкой. В более ранних версиях администраторы могут отключить это поведение, удалив файл корневых подсказок[13].

Еще одно дополнение в Windows Server 2016 - это то, что называется RRL. Мотивация состоит в том, чтобы смягчить DDoS-атаки, ограничив количество пакетов, которые сервер будет отправлять на определенный IP-адрес. Вместо генерации ответов на линейной скорости сервер будет отправлять (по умолчанию) только пять идентичных ответов в секунду любому данному клиенту. По умолчанию это отключено, но его можно включить с помощью команды «Set-DNSServerRRL». Правила можно дополнительно настроить, чтобы ограничить количество сообщений об ошибках, отправляемых в секунду, количество IP-адресов, которые должны быть сгруппированы вместе для фильтрации, и как часто фильтры должны переопределяться, чтобы разрешить «утечку» ответов[14]. Скорость утечки должна помочь предотвратить использование самого RRL в качестве вектора DoS. Например, если злоумышленник знает, что IP-адрес 1.1.1.1 использует DNS-сервер 2.2.2.2, он может запустить то, что выглядит как DDoS-атака против 1.1.1.1 с использованием поддельных пакетов, отправленных на 2.2.2.2. Если бы DNS-сервер использовал RRL, он бы послушно блокировал дальнейшие запросы из 1.1.1.1 (при условии, что злоумышленник использовал домены, которые цель будет законно запрашивать). Это может превратить относительно небольшую DDoS-атаку в полное отсутствие доступа к DNS. Как описывают Пол Викси и Вернон Шрайвер в своей заметке о RRL, «LEAKRATE должно быть от 2 до 10 и должно приблизительно соответствовать количеству повторных попыток реальной жертвы для законного запроса»[15].

Когда на инфраструктуру DNS имеют место крупномасштабные DDoS-атаки, часто упоминается, что проблема будет в значительной степени решена, если все будут внедрять BCP-38. Фактически, его название - «Устранение атак типа "Отказ в обслуживании", в которых используется подмена адресов». BCP-38 - это, по сути, набор фильтров сетевого уровня, таких как проверка того, что предполагаемый IP-адрес источника в пакете находится в диапазоне IP-адресов, подключенных к интерфейсу. Если, например, интернет-провайдер видит много пакетов, исходящих от домашнего клиента с исходным IP-адресом правительственного веб-сайта, он должен быть в состоянии определить, что они подделаны. Поскольку это фильтры сетевого уровня, для администратора Windows не так уж много прямых последствий. Это просто еще один доступный инструмент при настройке плана безопасности.

Кэширующие серверы Windows

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

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

$ dig @8.8.8.8 www.palantir.com
; << >> DiG 9.8.3-P1 << >> @8.8.8.8 www.palantir.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 45494
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.palantir.com. IN A
;; ANSWER SECTION:
www.palantir.com. 299 IN CNAME e.ssl.fastly.net.
e.ssl.fastly.net. 29 IN A 23.235.46.230

Обратите внимание, что ответ содержит ответ на исходный запрос (www.palantir.com), который указывает на поддомен на fastly.net. Но он также для быстроты включает IP-адрес поддомена .net. В этом случае ответ действителен, но что, если вредоносный сервер вернул CNAME, указывающий, например, на google.com, а также предоставил фиктивную запись A? Сервер должен решить, следует ли рассматривать запись A как действительный ответ на этот конкретный запрос, а также следует ли кэшировать ее для будущих клиентов. В Windows это называется «загрязнением кеша», и общая рекомендация - не допускать этого. Его можно отключить, как показано на рис. 8.4. В некоторых случаях это может вызвать увеличение задержки в запросах.

Рисунок 8.4 Настройка загрязнения кеша.

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

Резолвер для всей сети может быть настроен как зона пересылки, которая просто запрашивает другой резолвер, а не выполняет рекурсивные запросы. Это может иметь место в домашней сети, если маршрутизатор действует как DNS-сервер и перенаправляет запросы на резолвер провайдера. Некоторые сети малых предприятий также будут работать таким образом. Это можно рассматривать как меру безопасности, хотя здесь есть компромисс. Сервер, работающий в качестве сервера пересылки, может быть ограничен на сетевом уровне для связи только с вышестоящим резолвером, что ограничит способы, которыми злоумышленники могут исследовать эту машину. Но это небольшая степень защиты, потому что любой исходящий трафик, который отправляет сервер, все равно будет в конечном итоге направлен в то же место в Интернете. Так, например, это не снижает риск кражи данных через DNS. В конечном итоге все сводится к тому, предоставляет ли вышестоящий сервер улучшенные механизмы безопасности. Если он более устойчив к заражению кеша, например, путем добавления энтропии к запросам, или более устойчив к DDoS-атакам, он может улучшить состояние безопасности. Если администратор решит, чтобы резолвер кеширования выполнял рекурсивные запросы, ему просто нужно будет загрузить список корневых серверов, что Windows сделает автоматически.

Windows DNS и высокая доступность

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

Классическим примером DNS-сервера, который будет иметь много клиентов в общедоступном Интернете, является сервер, на котором размещен домен популярного веб-сайта. Администраторы могут захотеть убедиться, что сайт устойчив к сбоям оборудования, сетевым проблемам и даже крупномасштабным отключениям электроэнергии. Обычная конфигурация - запуск нескольких экземпляров веб-сервера в разных центрах обработки данных по всему миру. Запись DNS для сайта может содержать несколько записей, и клиенты, как правило, будут пробовать их по порядку, пока одна из них не заработает[16]. Если, например, оборудование в Вирджинии отключится, веб-браузер просто попробует следующий IP-адрес и успешно подключиться к серверу в Калифорнии. Более сложные службы будут определять приоритеты записей в зависимости от географии клиента, поэтому пользователь в Нью-Йорке всегда будет получать IP-адрес Вирджинии перед IP-адресом Калифорнии. Кроме того, записи DNS для очень больших веб-сайтов обычно указывают не непосредственно на веб-сервер, а на балансировщик нагрузки, расположенный перед кластером веб-серверов. Технически эта конфигурация применяется не только к DNS-серверу популярного веб-сайта. Каждый раз, когда в зоне будет мало обновлений, высокие требования к времени безотказной работы и клиенты из разных сетей, администратор может захотеть рассмотреть этот подход.

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

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

В этом сценарии администраторы часто будут полагаться на AD для хранения записей, поэтому сам AD должен быть высокодоступным. Этого можно добиться с помощью репликации AD. Когда этот параметр включен, Windows будет хранить данные AD на нескольких серверах, поэтому, если одна из этих систем выйдет из строя или потеряет сетевое соединение, клиенты могут подключиться к другой[17].

Инструкции по установке Windows

Основным интерфейсом для настройки любой конфигурации является диспетчер DNS Windows. В первой конфигурации можно было бы добавить дополнительные ответы к существующим записям. По заявлению Microsoft, поддержка различных приоритетов адресов в зависимости от географического положения будет включена в Windows Server 2016. Это будет частью функции политик DNS[18]. Для второй конфигурации или для добавления избыточных DNS-серверов к первому сценарию можно было бы создать новую вторичную зону на новом оборудовании, как показано на рис. 8.5.

Рисунок 8.5 Добавление вторичной зоны.

Время восстановления

В худшем случае администратору потребуется полностью перестроить DNS-сервер в течение периода простоя. Например, гарантия безотказной работы 99,9% означает, что услуга может быть отключена не более чем на 43 минуты в месяц. Это означает, что администратор должен иметь возможность восстанавливать службы, обычно из файла резервной копии, за достаточно короткое время, чтобы можно было сначала обнаружить проблему, а затем запустить восстановление. Сам файл резервной копии - это часто забываемый источник данных, который необходимо защищать. Например, в сообщениях в блогах описаны случаи нахождения резервных копий базы данных, которые были случайно сохранены в папке веб-сервера и доступны для всех в Интернете[19]. Резервные копии, как правило, должны быть защищены таким же образом, как файлы зоны, с ограниченным доступом пользователей к файлы и шифрованием при необходимости. Если резервные копии передаются за пределы сайта (часто это хорошая практика для защиты от крупномасштабных сбоев оборудования), сетевое соединение должно быть зашифровано чем-то вроде ssh или sftp. Также обычно рекомендуется использовать аутентификацию с открытым ключом с хорошим управлением ключами.

Последствия для безопасности

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

Последнее соображение - как подготовиться, если взлом или другая атака сама по себе является причиной простоя. Например, во время взлома Sony в 2014 году сообщалось, что 6000 сотрудников их студии потеряли доступ к компьютерам и даже к стационарным телефонам. Это привело к тому, что сотрудники, в том числе ответившие на атаку, обменивались данными с мобильными телефонами и внешними учетными записями электронной почты[20]. Аналогичным образом, если DDoS-атака вызывает сбой или недоступность DNS-сервера, а инфраструктура высокой доступности направляет весь трафик на дополнительный сервер, он может вызвать каскадный отказ. Хороший план аварийного восстановления должен учитывать эти сценарии. Например, если DNS-сервер взломан, сколько времени простоя было бы приемлемо для бизнеса, если бы его нужно было перевести в автономный режим? Как будут доводиться до сведения клиентов и сотрудников планы действий на случай непредвиденных обстоятельств? В конечном итоге они должны быть частью любого надежного плана безопасности.

Логирование

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

К счастью, Windows позволяет довольно легко настроить, сколько данных DNS будет записываться. На самом низком уровне, который обычно является настройкой по умолчанию, Windows создает то, что она называет журналами аудита. Они будут отображать изменения в файле зоны, такие как добавление записей или изменение ключей DNSSEC, но не отдельные запросы или ответы. На самом подробном уровне Windows может регистрировать каждое событие, происходящее на DNS-сервере, например состояние каждого сокета. Обычно это называется ведением журнала диагностики или журналом отладки, и его можно включить с помощью служебной программы tracelog.exe.

Промежуточным звеном является параметр «Аналитическое ведение журнала» (Analytical Logging), который рекомендуется администраторам, заботящимся о безопасности. Он будет фиксировать запросы, ответы, тайм-ауты и сбои. Аналитическое ведение журнала потребует большего количества операций записи на диск, чем более простое ведение журнала аудита, но для всех серверов, кроме наиболее часто используемых, это не должно вызывать серьезных накладных расходов на производительность. Microsoft сообщает, что серверы с менее чем 50 000 запросов в секунду не должны испытывать замедления, а серверы с 100 000 запросов в секунду будут испытывать снижение производительности на 5%[21].

Аналитическое ведение журнала можно просматривать и управлять как в средстве просмотра событий, так и в диспетчере DNS, как показано на рис. 8.6.

Рисунок 8.6. Настройка логирования DNS в Windows.

Файл журнала часто хранится по умолчанию по пути %systemroot%\System32\Dns\Dns.log[22]. Это можно настроить при настройке параметров уровня журнала или изменить в диспетчере DNS. Обратите внимание, что журналы отладки будут храниться в формате ETL, который отличается от обычных журналов DNS. Многие сторонние пакеты агрегирования журналов, такие как Splunk, предоставляют программу «пересылки», которая экспортирует журналы из контроллера домена и загружает их в другую систему. В качестве альтернативы некоторые администраторы используют служебные программы syslog для передачи журналов.

Анализ журнала Windows

Один простой (и бесплатный) набор инструментов, который администраторы могут использовать для хранения и поиска журналов, - это стек под названием ELK. Это расшифровывается как ElasticSearch, LogStash и Kibana. Они предназначены для работы друг с другом, и в Интернете есть множество руководств по их настройке на платформах Windows или Linux. Существуют также готовые виртуальные машины и образы докеров, позволяющие быстро приступить к работе. LogStash обрабатывает процесс получения данных из разных источников, поэтому он будет основным компонентом, который необходимо настроить администраторам. Он может либо прослушивать сообщения (аналогично системному журналу), либо запускать агент сбора на DNS-сервере, чтобы отправлять данные в свое центральное хранилище. Windows Powershell также может изначально поддерживать экспорт журналов событий в формате JSON[23]. После того, как конвейер настроен для отправки журналов DNS в LogStash, данные будут храниться и индексироваться в Elastic Search, а аналитик может войти в Kibana для выполнения запросов и просмотра совокупной статистики. Для коллекций журналов размером в сотни и более гигабайт важна настройка ElasticSearch. Он должен хранить часть индексов в памяти для выполнения запросов, поэтому его, вероятно, потребуется сегментировать по мере роста масштаба.

Как описано в главе 6, существует множество шаблонов, которые можно искать в трафике DNS, чтобы найти индикаторы вредоносной активности. Они в равной степени применимы к сетям на базе Linux и Windows. Например, на базовом уровне администраторы должны смотреть на гистограммы и частоту входящих запросов, чтобы убедиться, что они соответствуют ожидаемым авторитетным доменам. Им также следует проверять исходящие запросы, чтобы узнать, соответствуют ли они доменам из списка Alexa или вместо этого есть много запросов к необычным местоположениям. Для более сложного анализа системные администраторы могут посмотреть длину и энтропию имен хостов в исходящих запросах, чтобы обнаружить каналы управления и контроля. Два вида анализа, которые особенно важны в средах Windows, - это динамические обновления и поиск индикаторов вредоносного ПО.

Исторически Windows была уязвима для атаки, описанной в CVE-20090093, которая позволяла клиентам отправлять фиктивные динамические обновления и выдавать себя за прокси, используемый другими рабочими станциями. Хотя сейчас это исправлено, это указывает на общий недостаток в том, как часто администрируются сети Windows: DNS-сервер обычно полагается на AD для аутентификации пользователей, но в больших сетях этими службами часто управляют разные люди. Например, знают ли администраторы DNS, какие проверки выполняются при добавлении новых учетных записей в AD? Уведомляются ли они об изменении этих политик? Просматривая совокупные записи о том, как динамические обновления фактически происходят в сети, администраторы DNS могут лучше понять, как настроены все части сети. Регулярно просматривая эти данные, они могут обнаружить изменения или отклонения. Например, скажем, в сети есть портал для сторонних поставщиков для отправки счетов, и эти учетные записи поддерживаются в AD отдельно от остальной части домена. Отправляют ли эти учетные записи какие-либо запросы на динамическое обновление? Хорошо зарекомендовавшая себя система анализа журналов должна быть в состоянии ответить на такой вопрос.

Примерно 80% вредоносных программ нацелены на системы Windows[24]. Это связано с тем, что либо Windows является самой популярной операционной системой, либо более привлекательной целью, в зависимости от того, кого спрашивают. Но это означает, что администраторы должны уделять особое внимание индикаторам вредоносного ПО при анализе журналов DNS из крупной сети Windows. В главе 6 описаны более сложные методы, но как минимум следует регулярно проверять журналы на наличие известных плохих доменов.

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

Выводы

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

Заметки

  1. http://w3techs.com/technologies/overview/operating_system/all

  2. https://technet.microsoft.com/en-us/library/security/ms06-041.aspx

  3. https://technet.microsoft.com/library/security/ms07-029

  4. https://technet.microsoft.com/en-us/library/security/ms15-127.aspx

  5. https://technet.microsoft.com/en-us/library/cc771898.aspx

  6. https://technet.microsoft.com/en-us/library/cc755193.aspx

  7. https://technet.microsoft.com/en-us/library/cc755193.aspx

  8. http://www.root-dnssec.org/wp-content/uploads/2010/06/icann-dps-00.txt

  9. https://www.ietf.org/rfc/rfc2136.txt

  10. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name 5 CVE-2009-0093

  11. https://support.microsoft.com/en-us/kb/172218

  12. http://blogs.msmvps.com/acefekay/2009/11/29/dns-wins-netbios-amp-the-client-side-resolver-browser-service-disabling-netbios-direct-hosted-smb-directsmb-if-one-dc-is-down-does-a-client-logon-to-another-dc-and-dns-forwarders-algorithm/

  13. https://blogs.technet.microsoft.com/teamdhcp/2015/09/03/upward-referral-responses-from-authoritative-dns-servers/

  14. https://blogs.technet.microsoft.com/teamdhcp/2015/08/28/response-rate-limiting-in-windows-dns-server/

  15. http://ss.vix.su/Bvixie/isc-tn-2012-1.txt

  16. Например: https://www.digitalocean.com/community/tutorials/how-to-configure-dns-round-robin-load-balancing-for-high-availability.

  17. https://technet.microsoft.com/en-us/library/cc755994%28v 5 ws.10%29.aspx

  18. https://blogs.technet.microsoft.com/networking/2015/05/11/geo-location-based-traffic-management-using-dns-policies/

  19. https://blog.sucuri.net/2015/06/websites-hacked-via-website-backups.html

  20. http://www.wsj.com/articles/behind-the-scenes-at-sony-as-hacking-crisis-unfolded-1419985719

  21. https://technet.microsoft.com/en-us/library/dn800669.aspx

  22. https://support.microsoft.com/en-us/kb/242046

  23. https://blog.rootshell.be/2015/08/24/sending-windows-event-logs-to-logstash/

  24. https://redmondmag.com/blogs/the-schwartz-report/2015/09/malware-strikes-windows-pcs.aspx

Глава 9
DNS-аутсорсинг

Информация в этой главе

Вступление

В октябре 2013 года посетители веб-сайта компании Metasploit, производящей программное обеспечение для тестирования на проникновение, были перенаправлены на сайт, принадлежащий группе палестинских хактивистов, известной как KDMS Team. Команде KDMS не нужно было взламывать веб-сервер Metasploit или даже их DNS-сервер, вместо этого они отправили факс регистратору домена metasploit.com с просьбой к регистратору обновить запись A.

В сентябре 2011 года ряд организаций, в том числе The Register и The Telegraph, указали свои авторитетные серверы имен на серверы, принадлежащие турецкой хакерской группе, называющей себя Turkguvenligi. Злоумышленники смогли запустить атаку с использованием SQL-инъекции против панели управления регистратора доменов организации и использовать этот доступ для перенаправления записей NS для целевых доменов в инфраструктуру, принадлежащую злоумышленникам.

В декабре 2014 года несколько сотрудников Международной корпорации по присвоению имен и номеров (ICANN) стали жертвами успешной целевой фишинг-атаки. ICANN поддерживает базы данных для многих критически важных систем в Интернете, включая DNS. Злоумышленники смогли получить доступ к внутренней сети ICANN и получить доступ к нескольким критически важным системам, включая централизованную систему данных зоны, прежде чем они были обнаружены неделю спустя.

В феврале 2015 года хакерская группа, называющая себя Lizard Squad, использовала уязвимость SQL-инъекции, чтобы проникнуть в регистратор доменов в Малайзии. Вместо того, чтобы просто вносить изменения через панель управления, команда Lizard Squad могла загрузить корневой комплект и иметь полный доступ для внесения изменений в выбранный домен. В данном случае они нацелены на Lenovo и Google Vietnam. Оба веб-сайта были направлены на серверы, принадлежащие Lizard Squad.

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

Учитывая всю эту информацию, любая организация должна задать себе вопрос: должна ли организация передавать DNS на аутсорсинг? Если да, то какая часть инфраструктуры DNS организации должна быть передана на аутсорсинг и как администраторы DNS, а также группы безопасности могут обеспечить целостность информации, управляемой поставщиком DNS?

Dns-аутсорсинг

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

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

Этот контроль начинается с правильного выбора того, где организация регистрирует свои домены. Безопасность регистратора доменов - это то, о чем многие организации мало думают. Фактически, группа безопасности часто не знает о регистрации нового домена до тех пор, пока не возникнет потенциальная проблема. Различные группы внутри организации будут регистрировать домены для различных видов деятельности, не понимая потенциального риска своих действий.

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

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

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

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

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

Какие требования безопасности организация должна предъявлять к поставщику DNS? Это действительно зависит от организации и ее профиля риска. Вот почему обсуждение безопасности регистратора доменов так важно, что позволяет администраторам DNS подходить к каждому регистратору домена с последовательным набором вопросов. Эти вопросы действительно можно разделить на два типа: безопасность самого регистратора домена и функции безопасности, доступные для домена организации.

Примеры вопросов, которые следует задать регистратору домена о его безопасности, могут включать:

  1. Есть ли у регистратора веб-портал для администрирования доменов? Если да, то проверялся ли портал сторонним тестером на проникновение в поисках SQL-инъекций и других распространенных уязвимостей веб-приложений?
  2. Имеет ли портал регистраторов возможности управления доступом на основе ролей, чтобы администраторы портала в организации могли создавать несколько учетных записей и ограничивать доступ этих владельцев учетных записей?
  3. Какие меры безопасности принимаются для защиты авторитетных серверов имен регистратора?
  4. Какие возможности предотвращения отказа в обслуживании (DDoS) при распространении имеются у регистратора для защиты своей инфраструктуры, особенно авторитетных серверов имен?
  5. Поддерживает ли регистратор двухфакторную аутентификацию как для входа на портал, так и для входа по телефону?

Примеры вопросов, которые следует задать потенциальному регистратору доменов о безопасности его доменов, включают:

  1. Поддерживает ли регистратор домена DNSSEC?
  2. Поддерживает ли регистратор домена блокировки реестра, предотвращающие такие вещи, как перенос клиентского домена?
  3. Какие типы мониторинга изменений домена или WHOIS предлагает регистратор? Как контакты оповещаются об изменении?
  4. Предлагает ли регистратор домена варианты обеспечения конфиденциальности WHOIS?
  5. Меняется ли домен журнала регистратора? Если да, доступны ли эти изменения клиенту? Могут ли эти изменения быть автоматически загружены в диспетчер инцидентов и событий безопасности?
  6. Какие методы аутентификации использует регистратор, чтобы подтвердить, что звонящий/отправитель электронной почты является фактическим владельцем домена?

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

Мониторинг третьих сторон

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

Сколько отдать на аутсорсинг

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

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

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

Управляемый DNS

До сих пор разговор об аутсорсинге вращался вокруг работы с регистратором доменов организации для управления аутсорсингом. Однако есть еще один вариант: использовать управляемого DNS-провайдера. Существует ряд поставщиков управляемых DNS, таких как Amazon Route 53, Dyn, EasyDNS, MarkMonitor и Neustar, которые выводят управление DNS за рамки традиционного портала, обычно предлагаемого регистраторами доменов[1].

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

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

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

Разделение DNS

Многие организации решают дилемму аутсорсинга, выбирая модель раздельного DNS. Разделенный DNS позволяет организации получать ответы на свои общедоступные запросы DNS-записей с высоким трафиком от своего регистратора DNS или управляемого DNS-провайдера, в то время как внутренний DNS-сервер отвечает на запросы для внутренних узлов сети. Другими словами, внутренний DNS-сервер действует как полномочный DNS-сервер для домена организации.

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

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

Лучшим способом управления разделенным DNS является использование DNS с разделенным горизонтом, как показано на рис. 9.1. Большинство современных авторитетных серверов имен можно настроить для представления различных ответов в зависимости от того, откуда исходит трафик. Взгляните на конфигурацию этого в BIND:

acl corp-network {
    192.168.1.0/24;
};
// Internal
view "internal" {
    match-clients {corp-network; };
    include "/etc/named.internal.zones";
    include "/etc/named.common.zones";
};
// External
view "external" {
    match-clients { any; };
    include "/etc/named.external.zones";
    include "/etc/named.common.zones";
};

Первым шагом является создание списка управления доступом (ACL), в данном случае называемого корпоративной сетью, и определение IP-пространства для этого ACL. В приведенном выше примере используется сеть 192.168.1.0/24, однако имейте в виду, что если регистратор домена размещает авторитетный сервер имен, адреса RFC 1918 не будут работать. Следующий шаг - просто создать два разных представления: в приведенном выше примере они называются internal и external. Внутреннее представление обслуживает ответы из одного файла зоны, в то время как внешнее представление обслуживает ответы из другого файла зоны. Обратите внимание, что существуют также общие файлы зон, которые возвращают одни и те же ответы на запросы независимо от того, исходит ли этот запрос от внутреннего или внешнего хоста.

Рисунок 9.1 Обзор DNS с разделением горизонта.

Сохранение двух отдельных файлов зон на одном полномочном сервере упрощает управление этими файлами зон и их синхронизацию.

Третий способ разделения файла зоны - переместить все внутренние хосты в субдомен и назначить эту зону внутреннему управляемому серверу имен. Например, организация может использовать домен dns-book.net для Интернета, почты и других общедоступных хостов, но все внутренние хосты будут подпадать под домен corp.dns-book.net. Итак, файловым сервером будет fileserver.corp.dns-book.net, принтером - printer100.corp.dns-book.net. Авторитетный сервер имен должен иметь запись NS для corp.dns-book.net, указывающую на внутренние серверы, примерно так:

corp.dns-book.net.    3600  IN  ns1.corp.dns-book.net.
corp.dns-book.net.    3600  IN  ns2.corp.dns-book.net.
ns1.corp.dns-book.net.    1800  IN  A  192.168.1.14
ns2.corp.dns-book.net.    1800  IN  A  192.168.1.15

Не имеет значения, что записи A для двух записей NS указывают на адреса RFC 1918, единственные люди, которым нужен доступ к этим серверам, находятся в сети организации.

Другой способ разделения представлений домена - добавить другой TLD к внутренним хостам. Многие организации стали использовать TLD .local или .internal для идентификации только локальных хостов, что позволяет им поддерживать полностью отдельный файл зоны для внутренних хостов по сравнению с внешними хостами. Хотя это еще не стандартная практика, она продолжает набирать популярность.

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

Аутсорсинг рекурсивного DNS

Большинство организаций не уделяют слишком много внимания аутсорсингу рекурсивной инфраструктуры DNS. Либо их интернет-провайдер (ISP) предоставляет им предварительно сконфигурированный модем, в который загружается IP-информация резолвера, либо администраторы сервера загружают один из многих доступных общедоступных резолверов в настройки сервера. Фактически, согласно исследованию 2014 года, проведенному Азиатско-Тихоокеанским сетевым информационным центром (APNIC), 90% пользователей Интернета перенаправляют свои DNS-запросы менее чем на 1% видимых разрешающих серверов (~2000), а 23% получают ответы на свои запросы от ферм резольверов, принадлежащих трем организациям: Google, China Net и China 169[2].

Хотя, безусловно, есть много мудрости в том, чтобы позволить профессионалам управлять безопасностью рекурсивного DNS и не беспокоиться о защите еще одной службы в сети, но управление рекурсивным DNS собственными силами имеет большое значение. Microsoft упрощает включение рекурсивного DNS на сервере Active Directory, на самом деле Active Directory требует DNS для правильной работы. Компромисс для группы безопасности сводится к мониторингу безопасности этого DNS-сервера по сравнению с возможным отсутствием атаки, поскольку все DNS-запросы отправляются на сервер за пределами сети.

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

Безопасная работа с DNS-провайдером

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

Некоторые идеи для безопасного взаимодействия с поставщиком DNS включают:

  1. Никогда не используйте личный адрес электронной почты для регистрации домена. Все контакты домена должны включать адрес электронной почты из этой организации.
  2. Двухфакторная аутентификация всегда должна быть включена, но варианты двухфакторной аутентификации, которые легко подделать, такие как факс, должны быть специально запрещены.
  3. Процесс двухфакторной аутентификации должен быть хорошо документирован в организации и предоставлен тем, кому необходимо знать, как он работает.
  4. Если контрольные вопросы требуются для доступа для внесения изменений в домен, должен быть стандартный набор вопросов/ответов (больше, чем минимум три, которые обычно требуются), которые хорошо документированы и предоставляются пользователям при необходимости.
  5. Если возможно, доступ к порталу поставщика DNS должен быть ограничен только сетями, принадлежащими организации.
  6. Любая электронная почта между организацией и поставщиком DNS должна быть зашифрована. Обратите внимание, что стандартные уведомления, такие как уведомления об истечении срока действия домена, не могут быть зашифрованы.
  7. Точно так же все коммуникации с использованием веб-портала поставщика DNS должны быть зашифрованы (в данном случае это обычно означает обмен данными с использованием безопасности транспортного уровня (TLS)).
  8. По возможности поставщик DNS должен предоставлять журналы всех обращений к порталу и изменений, внесенных в домены организации во время этих обращений.

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

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

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

Мониторинг инфраструктуры DNS

«Это только мне, или всем не по душе?» Является ли такой распространенный вопрос среди профессионалов в области информационных технологий, что вокруг этой темы построены целые службы мониторинга (см. www.downforeveryoneorjustme.com). Мониторинг - важная часть построения инфраструктуры DNS, но его слишком часто упускают из виду.

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

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

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

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

Конечно, производительность и доступность - это всего лишь два аспекта доступности DNS. Также важно отслеживать изменения в инфраструктуре DNS. Такие компании, как ThousandEyes и DNSCheck, могут отслеживать изменения в файле зоны организации и обновления своих авторизованных серверов имен. Другие компании, такие как DomainTools, предлагают услуги по мониторингу более крупной картины. Например, DomainTools отслеживает изменения серверов имен и владельцев регистрации. Хотя это в основном используется для отслеживания конкурентов или групп атак, его также можно использовать для отслеживания изменений в собственной инфраструктуре DNS организации.

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

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

DNS-аутсорсинг и защита от DDoS-атак

DDoS-атаки представляют собой угрозу для каждой организации и они никуда не денутся. Слишком легко начать атаку на целевую организацию, и просто слишком много людей, у которых, как представляется, есть свои цели. Согласно отчету «Akamai’s State of the Internet - Security Report», в период с третьего квартала 2014 года по третий квартал 2015 года количество DDoS-атак выросло на 180%. Помимо большего количества атак, атаки продолжаются дольше, в среднем DDoS-атака длится почти 19 часов. а Akamai зафиксировал атаки мощностью до 222 миллионов пакетов в секунду[3].

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

Передав на аутсорсинг значительную часть инфраструктуры DNS организации, эта организация может получить дополнительное преимущество защиты своих DNS-серверов от DDoS-атак. Помимо стандартной защиты, которую уже использует надежный поставщик DNS, некоторые поставщики управляемых DNS также предлагают за определенную плату расширенную защиту от DDoS-атак. Поставщики управляемых DNS, такие как Akamai, Neustar и Verisign, также имеют услуги защиты от DDoS-атак и через другие протоколы.

DDoS-атаки могут быть дорогими

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

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

Выводы

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

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

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

Заметки

  1. Полное раскрытие: оба примера доменов, используемых в этой книге, dns-book.net и cryptodns.com, под управлением Dyn. Dyn не предоставил никаких компенсаций ни в платных, ни в бесплатных услугах, авторам просто нравится их обслуживание.

  2. Huston, G., 2015. The Resolvers We Use. APNIC, 05 Aug. 2015. Web. 16 Jan. 2016. <http://www.potaroo.net/presentations/2015-05-08-resolvers.pdf>.

  3. Akamai, 2015. Q3 2015 State of the Internet—Security Report | Cloud Security Trends. Akamai, 8 Dec. 2015. Web. 30 Jan. 2016. <https://www.stateoftheinternet.com/resources-cloud-security-2015-q3-web-security-report.html>.

Глава 10
DNSSEC

Информация в этой главе

Вступление

При рассмотрении успешных атак с подменой DNS люди часто задавались вопросом, почему DNS не может работать по безопасному протоколу, подобно тому, как веб-трафик может проходить через SSL/TLS. К счастью, исследователи думали об этой проблеме с первых дней Интернета, и в результате появился протокол DNSSEC. В этой главе будет описана мотивация для DNSSEC, трудности добавления безопасности в массово распределенную, отказоустойчивую систему, такую как DNS, и проектные решения, которые входят в протокол. Наконец, он будет включать примеры того, как настроить и использовать DNSSEC в реальной сети.

Предпосылки

В ноябре 2011 года бразильские интернет-пользователи, посещающие популярные веб-сайты, обнаружили сообщение о том, что им необходимо установить программу под названием «Google Defense», прежде чем они смогут продолжить[1]. Программа на самом деле была вредоносной программой, а вектор атаки - отравление кеша DNS. Кто-то изменил кэшированные записи DNS у крупных интернет-провайдеров, чтобы запросы на легитимные сайты отправлялись на сервер, который вернул вредоносную программу. Эта атака была особенно опасной, потому что злоумышленникам не нужно было обращаться к конкретным целям, они просто отравили несколько популярных доменов и ждали, когда к ним подойдут жертвы. С точки зрения жертв, неискушенные пользователи не могли знать, что на них нападают. Они просто просматривали Интернет так же, как и раньше, и получали поддельные сообщения от своего вышестоящего провайдера. Что интересно, другие уровни сетевой безопасности могли смягчить большую часть этой атаки. Например, браузеры могли бы отображать предупреждающее сообщение перед запуском загруженных программ, а некоторые антивирусные программы могли заблокировать загруженный файл. Но этот случай показывает, как единичная атака с заражением кэша DNS может повлиять на миллионы пользователей.

Другой инцидент произошел в январе 2014 года и заблокировал доступ в Интернет для значительной части пользователей в Китае. DNS-сервер начал возвращать один и тот же IP-адрес для всех DNS-запросов. Это могло быть результатом заражения кеша, другой злонамеренной атаки или ошибки администраторов инфраструктуры[2].

С 1990-х годов исследователи предлагали способы повышения безопасности DNS, и получившийся протокол получил название DNS Security Extensions или DNSSEC. RFC 2065, написанный в 1997 году, описывает мотивацию: «Система доменных имен (DNS) стала критически важной рабочей частью инфраструктуры Интернета, но в ней нет надежных механизмов безопасности для обеспечения целостности данных или аутентификации»[3]. Защитой данных являются шифрование и аутентификация. Шифрование шифрует сообщение, так что только тот, у кого есть правильный ключ, может прочитать его содержимое. Веб-сайты онлайн-банкинга будут шифровать всю информацию между клиентом и сервером, чтобы, например, кто-то, контролирующий трафик в общедоступной сети Wi-Fi, не мог прочитать содержимое этих страниц по сети. Аутентификация позволяет убедиться, что сообщение не было подделано. Часто цитируемая низкотехнологичная версия аутентификации - это королевская печать, прикрепленная к письму, чтобы показать, что оно пришло от короля. Фактически, терминология «подписи» и «сертификаты» все еще используется в современной криптографии, чтобы отсылать к более старым методам защиты рукописных писем. DNSSEC явно предпочитает сосредоточиться только на аутентификации, а не на шифровании. Как указано в RFC 2065, «частью философии проектирования DNS является то, что данные в нем являются общедоступными и что DNS дает одинаковые ответы всем запрашивающим». Поскольку протокол описан ниже, важно помнить, что его внимание сосредоточено только на проверке отсутствия подделки ответов DNS, а не на обфускации содержимого ответа.

Обзор криптографии и TLS

Прежде чем перейти к конкретному выбору, сделанному в DNSSEC, в этом разделе будет представлена краткая справочная информация о задействованной криптографии и рассмотрен самый популярный безопасный протокол в Интернете, SSL/TLS. В современной криптографии есть три важных инструмента, которые составляют основу как для TLS, так и для DNSSEC: шифрование с открытым ключом, хэши и подпись. Шифрование с открытым ключом включает создание открытого и закрытого ключей. Сообщения, зашифрованные с помощью открытого ключа, можно расшифровать только с помощью соответствующего закрытого ключа, и наоборот. Обратите внимание, что сам открытый ключ не может расшифровать сообщение после того, как оно было зашифровано открытым ключом. RSA был первым опубликованным алгоритмом открытого ключа и, вероятно, наиболее известным. Вторая концепция - это хеширование, которое означает получение сообщения любого размера и создание «дайджеста» фиксированной длины на основе этого ввода. SHA1, общий алгоритм хеширования, всегда имеет 160 бит вывода независимо от того, является ли ввод 1 символом, 1000 символов или 1 миллионом символов. Иногда сайты распространения файлов в Интернете включают хэш-значение рядом со ссылкой для загрузки, что позволяет кому-то локально хешировать файл после его загрузки, сравнивать его с опубликованным дайджестом и проверять, не был ли файл поврежден при передаче. Наконец, концепция подписи используется для демонстрации того, что сообщение пришло от определенного отправителя и не было ли изменено при передаче. Это делается путем шифрования сообщения закрытым ключом и публикации результата. Помните, что только открытый ключ может отменить шифрование закрытого ключа, поэтому любой может получить открытый ключ отправителя, использовать его для расшифровки сообщения и знать, что он должен быть создан с этой конкретной парой ключей. На практике подписывание и хеширование обычно используются в тандеме. Например, чтобы отправить большой файл и убедиться, что он не был изменен при передаче, можно отправить файл вместе с подписанным хешем файла. Получатель вычисляет хэш, затем расшифровывает подписанный хеш открытым ключом отправителя и проверяет совпадение двух значений. Если они не совпадают, получатель узнает, что что-то в файле было изменено, и может запросить повторную отправку.

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

Самый широко используемый криптографический протокол в Интернете - это SSL/TLS. Технически TLS является преемником SSL, хотя эти термины иногда используются как синонимы. Весь протокол можно рассматривать как способ получения пользователем открытого ключа для веб-сайта. Получив этот открытый ключ, пользователь может зашифровать данные, проверить подписанные хэши и, в конечном итоге, обмениваться любыми данными с веб-сайтом, при этом злоумышленник не сможет прочитать или изменить содержимое. Инфраструктура включает три компонента: клиент, сервер и нечто, называемое центром сертификации (CA). На практике CA заранее распространяет свой открытый ключ клиенту до того, как начнутся какие-либо соединения между клиентом и сервером. С помощью этого одного предварительно распространенного ключа можно безопасно распространить любое количество последующих открытых ключей. По состоянию на 2016 год Firefox включал более 180 доверенных центров сертификации, таких как Comodo, GoDaddy, Symantec и даже Wells Fargo[4]. Оператор веб-сайта может обратиться к одному из этих 180 провайдеров CA, предоставить его открытый ключ, и CA вернет нечто, называемое сертификатом, который включает домен сайта, его открытый ключ и хэш всего содержимого, подписанный открытым ключом CA. Центр сертификации (надеюсь) выполнит шаги, чтобы убедиться, что лицо, запрашивающее сертификат, действительно подключено к домену, например отправит электронное письмо на адрес webmaster@<domain>. или позвонив по номеру телефона, указанному в записях whois (обратите внимание, что это может быть вектор для спуфинга DNS). Затем, когда клиент впервые подключается к серверу, сервер представляет сертификат, выданный CA. Клиент может проверить подпись в сертификате, используя открытый ключ CA, который был предварительно распространен, и убедиться, что ключ с сервера не был изменен. Затем клиент составляет случайный сеансовый ключ, шифрует его открытым ключом сервера и отправляет зашифрованное содержимое на сервер. Обратите внимание, что этот последний шаг включает шифрование между клиентом и сервером, что важно для TLS, но не является частью DNSSEC. Это «рукопожатие TLS» происходит каждый раз, когда кто-то в Интернете посещает веб-сайт HTTPS.

Почему DNS не может работать просто поверх протокола TLS? Одна очевидная проблема заключается в том, что DNS по умолчанию работает через UDP (пока ответы на запросы не превышают 512 байт), тогда как TLS работает через TCP. Предложения и реализации существуют как для постоянного использования DNS через TCP, так и для запуска TLS через UDP. Так что теоретически можно настроить стек, который запускает DNS через TCP и защищает это соединение с помощью TLS (на самом деле это было предложено в проекте IETF в 2015 году). Но эти изменения представляют собой существенный отход от стандартных концепций DNS, к которым привыкли разработчики и администраторы. Например, при запросе через сокет TCP, сколько времени должен ждать резолвер, прежде чем связываться со вторичным DNS-сервером? Должен ли он позволить стеку TCP обрабатывать эти тайм-ауты или реализовать их в приложении? И будет ли у основных DNS-серверов достаточная пропускная способность для обработки дополнительного трафика, связанного с рукопожатием TLS? Наконец, поскольку TLS требует сохранения состояния для каждого соединения (например, ключа сеанса), не будут ли основные службы более уязвимы для атак распределенного отказа в обслуживании (DDoS)? Конечно, есть разумные подходы к каждой проблеме, но для этого потребуется разработать новый протокол.

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

Одна постоянная проблема, с которой столкнулся TLS, которую DNSSEC стремится избежать, - это обработка скомпрометированных ключей. Если веб-сайт теряет доступ к своему закрытому ключу, ему необходимо повторно выпустить сертификат и попытаться убедиться, что старый сертификат не используется злоумышленниками. Если CA обманом заставили выдать сертификат неавторизованному лицу или если закрытый ключ самого CA когда-либо был скомпрометирован, эта проблема усугубляется. TLS добавляет понятие списков отзыва (теперь часто реализуемых как протокол статуса онлайн-сертификатов), которые можно загрузить с самого веб-сайта или с других доверенных сторон. Это создает проблему того, как распространять файлы, которые иногда могут быть многомегабайтными, в начале каждого безопасного соединения, и это добавляет потенциальную точку DoS. DNSSEC пытается смягчить некоторые из этих проблем, создав два ключа, Key Signing Key (KSK) и Zone Signing Key (ZSK), как будет описано ниже.

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

Протокол DNSSEC

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

Например, запись для ripe.net:

$ dig @8.8.8.8 www.ripe.net +dnssec
; << >> DiG 9.8.3-P1 << >> @8.8.8.8 www.ripe.net +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 29930
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.ripe.net.    IN  A

;; ANSWER SECTION:
www.ripe.net.    18076  IN  A  193.0.6.139
www.ripe.net.    18076  IN  RRSIG  A   8   3   21600   20160129112402
20151230102402 48975 ripe.net. b1p/E3oVheJxSJLk98G4eJixmN9O5+NY78OOSfzTlnHdOWKMV7ZRsHmW 9ZH4RrHaeIrhKtTRC9nyUxvJbLb5yB0IOvqVkND6p/OTqAXAhwtq4QYtoBLsmfZJxUlPNavHRrJ7KihDXCAEX6g0/qiVPV5ntKJbEBBNm3lk/MbzWzY=

Обратите внимание, что этот ответ содержит запись A и запись RRSIG, которая представляет собой подписанный хэш содержимого ответа записи A www.ripe.net. Дополнительная запись DNSSEC отправляется так же, как и любая другая, и имеет те же поля, как запрос, TTL и тип. Технически RRSIG является подписью «RRSet», содержащего все записи A в ответе, поэтому, если бы было несколько IP-адресов для www.ripe.net, все равно был бы только один RRSIG. Это сделано для экономии места в ответном пакете. Клиент может проверить подпись, используя открытый ключ сервера, поэтому, если бы у него уже была доверенная копия открытого ключа, процесс был бы завершен здесь. Остальную часть приведенного ниже описания можно рассматривать как просто способ безопасного получения открытого ключа сервера путем построения цепочки доверия обратно к корню.

DNSSEC предоставляет открытый ключ зоны в записи DNSKEY, поэтому следующим шагом клиента является получение этой записи и выполнение процесса ее проверки. Но ключи должны вписываться в пакет DNS, поэтому они обычно короче, чем соответствующие ключи TLS. Например, RFC 6781 рекомендует использовать 1024-битные ключи для DNSSEC, тогда как лучшие практики TLS должны использовать не менее 2048 бит в парах открытых ключей. Это увеличивает вероятность того, что ключ может быть взломан в течение разумного периода времени, поэтому DNSSEC должен иметь механизм для регулярной ротации открытых ключей. DNSSEC также пытается решить одну из распространенных проблем с TLS - если ключ скомпрометирован, администратор должен вернуться к выдающему органу и получить подписанный новый ключ. Таким образом, он фактически использует два ключа - ZSK и KSK. RRSIG подписан ZSK, ZSK подписан KSK, и KSK подписан ZSK родителя. Это можно рассматривать как просто «открытый ключ для зоны», но использование нескольких ключей на практике дает несколько преимуществ. Если администратор хочет выпустить новый ключ, он просто генерирует новый ZSK, подписывает его тем же KSK и не должен обновлять родительскую зону. Тот же процесс выдачи нового ключа можно использовать для отзыва скомпрометированных ключей. Когда клиент проходит процесс проверки (как показано в примере ниже), он запрашивает ZSK, а затем KSK, поэтому любой, кто пытается использовать поддельную запись со скомпрометированным ZSK, не пройдет проверку с новым KSK. Кроме того, как описано в RFC 4641, разделение KSK и ZSK означает, что закрытая часть KSK может храниться в более безопасном месте, например вне сети. При добавлении или удалении записей из зоны, для выхода из зоны потребуется только ZSK. В загруженных сетях это может происходить ежедневно или даже ежечасно. Но KSK нужно будет получить только при создании нового ZSK, что обычно происходит еженедельно или ежемесячно.

Ниже приведен пример получения различных ключей:

$ dig @8.8.8.8 ripe.net DNSKEY
;; Truncated, retrying in TCP mode.

; << >> DiG 9.8.3-P1 << >> @8.8.8.8 ripe.net DNSKEY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 1462
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ripe.net.    IN DNSKEY

;; ANSWER SECTION:
ripe.net.    2326  IN  DNSKEY  256  3  8  AwEAAX8cuWXOvIh2UwlGOc+YUpyNDN2p9qAVYNERccLjgvD1K9LH48U1aHSMzMLP/63HDIMoEwJRQFCr96GuAjZWlX72r3j3lxubXnQo7IV8rylhoqk2HsuziwiTfkIlE2zOan9n8BpLT540lqOZSfbOLMZLcjTciJxst4hT8GtwCZuv
ripe.net.    2326  IN  DNSKEY  257  3  8  AwEAAb6Wg3SaF8e4bNx2DFdvB+A7xk8ithqbvSKKjLglJlhmsQRNqf5iB66+1c1TfgXj7J+sck1ahImRxq4/Kp+1xeJECx9X5Cqrli8z9nDugYAYfV774kLeJ+Eb6hX0XTd0K0o 86hBmG0zaiyeO1Z+uJRUyZklReLSH7sU7CTbY6XBkDo8yp2aJjEv3jZImV6etbPBQtUAxdMtTBeUet6h1umT4h5Lu24yaMRZfIApTIFlS0M6H2WwO9oyUfj4Dql280CVtP9QLS8aIizrl2WmK6mQSST49+XVMnWkgUJsGzjF22WLpwLhSh4H5kuhure+J0y//hIOpF+Yz vcEkiDEpPsM=
ripe.net.    2326  IN  DNSKEY  256  3  8  AwEAAY6L5HgLu1Rfad/6ehXzxJkh6/wBVZHEo5WlhVVZWYr9OzZojaaU GuAph40t/BL2wbpYiO3zGy56Aj8/4i2hxi4F83OXqjUDpZjQxCba9L/iuXDPvKOqtpj1HtGuQ4dGHWQNHEQVQ3THo+xomVYA96MeQh5os7oXgui3Ig7W5yQJ

ZSK имеет тип 256 и является первой записью в ответе. KSK имеет тип 257 и является второй записью. Обратите внимание, что KSK длиннее, чем ZSK, поскольку он обычно активен дольше и должен выдерживать большее окно атак грубой силы. В этом случае есть второй ZSK, последняя запись в ответе. Как обсуждается ниже, при ротации ZSK важно поддерживать доступными как старый, так и новый ключи, чтобы кэшированные записи все еще могли проверяться.

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

$ dig @8.8.8.8 ripe.net DS

; << >> DiG 9.8.3-P1 << >> @8.8.8.8 ripe.net DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 50955
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ripe.net.    IN  DS

;; ANSWER SECTION:
ripe.net.    21599  IN  DS  4331  8  2  C8565943D2B8F9478E441E1A8E58F38204131A5284F53F8E39AFBD08B323789E

С помощью открытого ключа из зоны и подписанного хэша записи теперь можно проверить, что исходный запрос на www.ripe.net не получил поддельного ответа. Цепочка, по которой нужно следовать, такова:

Этот процесс будет продолжаться вплоть до корня DNS, где клиент в конечном итоге найдет ключ, который является предварительно доверенным. Большинство резолверов будут включать корневой ключ, уже скомпилированный, или его можно получить, запустив команду «dig.DNSKEY". При внедрении DNSSEC в закрытой сети администратор генерирует собственный корневой ключ и раздает его клиентам. Некоторые корпоративные сети следуют аналогичной схеме распределения «якорей доверия» для своих собственных доменов или других доверенных доменов своим резолверам. Это позволит клиентам проверять запросы, как только они прослеживаются до якоря доверия, вместо того, чтобы повторять весь путь до корня DNS. Проверка записи DS в родительской зоне выполняется так же, как описано выше, когда клиент запрашивает RRSIG для записи DS, затем ключевой материал, затем, при необходимости, запись DS для родительской зоны этой зоны.

Давайте теперь пройдемся по всей цепочке проверки DNSSEC. Dig предоставляет полезный вывод, описывающий процесс, которому он следует.

$ dig @8.8.8.8 www.ripe.net +sigchase +trusted-key=./root.keys
;; RRset to chase:
www.ripe.net.    2515  IN  A  193.0.6.139
;; RRSIG of the RRset to chase:
www.ripe.net.    2515  IN  RRSIG  A  5  3  21600  20160101160313  201512021
50313 35970 ripe.net. AP7BeT7 ShUou8M+l5t5FALv2ptFQ4Qa5pcrZzUB5sKxNsPkLSBR8RgnJwaUd+AtahawE7g+Dd7wEJBcpkzT690qxI2JkWROZV6jRLsThwPBGZzAV9jwG0fPOouaO/jq5XXyMYGTazs3Ggqm70KzJl/cieYtwIhmaexo9AnvjFdg=

Launch a query to find a RRset of type DNSKEY for zone: ripe.net.

;; DNSKEYset that signs the RRset to chase:
ripe.net.    2390  IN  DNSKEY  256  3  5  AwEAAYZR8W3SReJDELYz1FRNj0esSPf/4M3z+Wo6Y0uyVY7FKodDeZ8le1zuGkUMKRms67mGSXRoL30rFJTwwAvW+/+aIesCI4SP+5+MFOduBZIa9tCt1Ja8+0VWHx4/UVS4yda2KkKNj2FSZDDRqY7MzE0LP34+rqPy06wVYHtlYO/f
ripe.net.    2390  IN  DNSKEY  256  3  5  AwEAAXaE07mYgEFCXkWAMWCssHA4mpOSIdeq0ImM4Hxj7/kSzu2+K5dnX72VVtn9kBFoSaSOaSoc9UHxpzNT7eQPlhCyO/91V8bw6/wu5k/13ee0dF32YnyAZhMoraHWpv2pjmt/CF6KjmtJyeprh+VVv8y127zHThTdwh0thDcwPGz3
ripe.net.    2390  IN  DNSKEY  257  3  5  AwEAAalnxwsXNVENfxBjxSy5LJbTVKaNZmlNoSdexcCEEEg3BnZrNYVb PpWT/OdW7cPHNpvj0Mp9VBaMNWoM+cwdB4LEfkzfhIDblTyBS/Kqxs0EOTzlnL+7MgODsVFesrf3cG+Ys7XtJScqL7T9jnUfHUgLSS7VbNRLdODx4Oelfn9WgaRZkq7Oj6wUeadwDn6zaBPw4Vc3yH6VQpj54cqBBGSULOiRX35a8VoKBGU4CnhSUjgOuo4iA8xCUizU/1Dk1oNyEYIdj8UZFdNT2IBOWSaF9wRG6FkLBfMsP6qHg7qn3lOtzCeKLfzNrQ/gFOzZ1MuNxfmuF7QK65SjPoDRdDE=

;; RRSIG of the DNSKEYset that signs the RRset to chase:
ripe.net.    2390  IN  RRSIG  DNSKEY  5  2  3600  20160101220244  201512022
10244 65306 ripe.net. NbVqWH6F5kBQp5fuzEqO/meoIrSrQMM8xe7fKGk1l5NOXuMsEe11y5Q9OYcSblmaIuNhjO8b5T59elGpdEScPF6dDV+6ZMyONjPgADue2xm89cnVpYqyvwxW4AIai4GbGZMsjvQEhea766oZFCqEMCPwzqaJ9pI1zoYNYzHXcowUbf9Kqpmfopx29IRXZhSxC/ub20DIRr2gu3qfxmbuuiZw2tabCsoppV2uPJyUm5267FJFQtw3nHuBMr9oOJpmLc6ushrtk2VvsRIiLUQVC8J8+aNdj1CCqQ5Zv0AII5eKYZ5g9brWy59Sbakz3NqXWFixjAb6+16N/CxCcoMAKQ==

Launch a query to find a RRset of type DS for zone: ripe.net.

;; DSset of the DNSKEYset
ripe.net.    21599  IN  DS  65306  5  2  DCAB3FF242EA54F6583DCE08D7762D020B2F32C23E720A4CCEA977C4 CCA28EF6
ripe.net.    21599  IN  DS  65306  5 1 F48B9AE1104DD42C39486C0B7406031BFC7C9CC6

;; RRSIG of the DSset of the DNSKEYset
ripe.net.    21599  IN  RRSIG  DS  8  2  86400  20151206062323  201511290513
23 37703 net. CSv58uFqBP1tOdEmY6ptb+brAjs7+XOTG+oJB8CesX9jThisTEDekYW+e0rnGpNMburx2B31cFzuk/77lyrPL0NCMIaX9Eu1II8RFVELdblk8wBxVYv2iRGpCMKsCQgX/GZLYcpgumkHzFkGOve30KmGAtcfCCDm3DZKf3//9Hw=

;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING A RRset for www.ripe.net. with DNSKEY:35970: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Now, we are going to validate this DNSKEY by the DS
;; OK a DS valids a DNSKEY in the RRset
;; Now verify that this DNSKEY validates the DNSKEY RRset
;; VERIFYING DNSKEY RRset for ripe.net. with DNSKEY:65306: success
;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset

;; Now, we want to validate the DS : recursive call

Launch a query to find a RRset of type DNSKEY for zone: net.

;; DNSKEYset that signs the RRset to chase:
net.    7028  IN  DNSKEY  257  3  8  AQOYBnzqWXIEj6mlgXg4LWC0HP2n8eK8XqgHlmJ/69iuIHsa1TrHDG6TcOra/pyeGKwH0nKZhTmXSuUFGh9BCNiwVDuyyb6OBGy2Nte9Kr8NwWg4q+zhSoOf4D+gC9dEzg0yFdwT0DKEvmNPt0K4jbQDS4Yimb+uPKuF6yieWWrPYYCrv8C9KC8JMze2uT6NuWBfsl2fDUoV4l65qMww06D7n+p7RbdwWkAZ0fA63mXVXBZF6kpDtsYD7SUB9jhhfLQE/r85bvg3FaSs5Wi2BaqN06SzGWI1DHu7axthIOeHwg00zxlhTpoYCH0ldoQz+S65zWYi/fRJiyLSBb6JZOvn
net.    7028  IN  DNSKEY  256  3  8  AQOakXaXBtSEU5Ir+ZTQb9SgDAfW0sTaqtbHN2F+2m4BCeh49ciHTw4HuYB/i1/3HEOxaaj+quEAmloGvjWXbH0cpU4176WaoM+3P0H06nC5jYyNX89o7Jnwwcdo2yTidRmBjpcvEEoMGr85Utj72TF3myUyF6ha86G9hLiJgmLF9Q==

;; RRSIG of the DNSKEYset that signs the RRset to chase:
net.    7028  IN  RRSIG  DNSKEY  8+86400  20151212173857  2015112717335
7 35886 net. MAd6ZjSgQL6hPcjwxEtFM9T/n4m9vqKpkMdPGgUO/J/Dzufh4Atd/rK2h7bi8UN31WPuG26RXi1jeuEc44dPPDNJrd+VvS5Re9r5w3l09pJm+hlWWH4hF1jOf9yn7NuV4Q+iPEuSSVML5AODkQHJr/RQraT6fItiKlennOAxJi0+xqo/G35AeygLcuBvxVpzjTpym3nkWU0+RCYTm1iNiL4jG2C0UWkek35LEGtFtJynC74hR9P2j2W0fmH5c0x5l4aeGLHUfOqUZxbBa5+nXrm9 DdcuQAgsEZLRivqW9NlLxIuuJ4HG67qdGxqxwgconZwbFgO5YcsL7e6xmDgWkw==

Launch a query to find a RRset of type DS for zone: net.

;; DSset of the DNSKEYset
net.    7799  IN  DS  35886  8  2  7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D8BD973EE

;; RRSIG of the DSset of the DNSKEYset
net.    7799  IN  RRSIG  DS 8 1 86400 20151212170000 20151202160000 62530 .
FuH3UU1r7QHxcEVfG9CtOTt/8N1RO2Tp6a5jCxfhRkGgHXR4fymSwNlW+VBJl7ZqYqNOHiUY+TQpaBU+GsI7RWnAwTx3dMonmmKH96MkBUSUloXF1FixjuOTfxo78faCwqmBA7VCQPn4S/ZImfkr+Z55homVK90eqECGFSf8mHE=

;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING DS RRset for ripe.net. with DNSKEY:37703: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Now, we are going to validate this DNSKEY by the DS
;; OK a DS valids a DNSKEY in the RRset
;; Now verify that this DNSKEY validates the DNSKEY RRset
;; VERIFYING DNSKEY RRset for net. with DNSKEY:35886: success
;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset

;; Now, we want to validate the DS : recursive call

Launch a query to find a RRset of type DNSKEY for zone: .

;; DNSKEYset that signs the RRset to chase:
.    3076  IN  DNSKEY  256  3  8  AwEAAbgVvZmZibtBpha3AIykU0OY4gcCXTcskYJUxGsdmV/awfmKcHlSrjNMioSgy4sByj+HpcbsyrZVGPp+JBXzYwwuEF/6w1k7vKYTK6vMSqgVcgooNkfb5MaRF2y7MEpPxfStnfwu8knE24ExB0hYE1URxJ9CqB3zMSl/vicXYXXl
.    3076  IN  DNSKEY  257  3  8  AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

;; RRSIG of the DNSKEYset that signs the RRset to chase:
.    3076  IN  RRSIG  DNSKEY 8 0 172800 20151214235959 20151130000000
19036 . E6g bSVVI9acmgAMsdx8+0tRCkrdxd1n2r8KfGYM9ncrCi4M0GAOsh/xbQqLfThUmRr77Wq4Xm5uvAlwAaMoKD1/lkEQOmmHDfzjmtEhc+jkd4/pWeNF32tX4nq/rWEer4MEqpkdbKGTt/MzzYlvAXp20KHgFKBXj3dvQPgY9hftu8de9XwMXCgXzFitA7wEGdBCPRYuiiQJE8XedyVBKQagDzNqbsR3AhVJnWpQr5qhoo0JyiY7lWk6MTk68u0+2ld+dZaMYYXlXl9O6ZKTyoHfCV1EOM5CDt7a92+/4lpx9Iz2gNPy6PPVSPoJUkLo94zYTYcipNT0Vaa3YibBxSQ==

Launch a query to find a RRset of type DS for zone: .

;; NO ANSWERS: no more
;; WARNING There is no DS for the zone: .
;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING DS RRset for net. with DNSKEY:62530: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Ok, find a Trusted Key in the DNSKEY RRset: 62530
;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success

;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS

Ответы NXDOMAIN

Одна из важных сложностей с DNSSEC заключается в том, как обрабатывать отрицательные ответы, указывающие на то, что домен не существует. Напомним, что DNS обрабатывает это, устанавливая код ответа NXDOMAIN и не включая записи ответов. Поскольку DNSSEC не подписывает заголовок ответов DNS, ему нечего аутентифицировать без изменения структуры ответов. Один из альтернативных подходов - включить явные записи «домен не существует» в раздел ответов. Но проблема с этим подходом заключается в том, что DNSSEC хочет разрешать администраторам подписывать записи в автономном режиме, поэтому серверу каким-то образом нужно будет заранее назначать каждый домен, который не существует. Другой вариант - иметь один подписанный ответ NXRECORD, который сервер будет возвращать для любого несуществующего домена. Проблема в том, что злоумышленник может сохранить этот ответ, а затем вернуть его для действительных доменов, создав DoS. Подход DNSSEC заключается в использовании ответа NextSecure (NSEC), который возвращает предыдущий и следующий последовательные домены, окружающие запрашиваемый домен. Эти записи могут быть подписаны в автономном режиме путем сортировки каждого имени хоста в зоне и создания записи NSEC для каждой последовательной пары. Если клиент получает ответ NSEC, он знает, что запрошенный домен не существует. Запись NSEC подписывается RRSIG, как и другие ответы.

Умные читатели могут заметить временную ошибку при таком подходе. Допустим, у домена есть три поддомена: a, c и d. Будет создано три записи NSEC: a -> в, в -> d и d -> а. Обратите внимание, что с этим набором записей злоумышленник не может воспроизвести ответы NSEC, чтобы ложно утверждать, что действительный поддомен не существует. Например, если клиент запрашивает a, злоумышленник не может воспроизвести запись, содержащую «a», и не может использовать c -> d запись, потому что клиент будет знать, что запись лексикографически не покрывает «a». Но предположим, что домен добавляет поддомен «b». Теперь злоумышленник может воспроизвести подписанный a -> c, и ложное утверждение, что b не существует. Как описано в RFC 4470, это известная проблема протокола.

Вот пример записи NSEC:

$ dig @8.8.8.8 asdf.ripe.net +dnssec
; << >> DiG 9.8.3-P1 << >> @8.8.8.8 asdf.ripe.net +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NXDOMAIN, id: 51647
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;asdf.ripe.net.    IN  A

;; AUTHORITY SECTION:
ripe.net.    299  IN  SOA  pri.authdns.ripe.net. dns.ripe.net. 1449054 483 3600 600 864000 300
ripe.net.    299  IN  RRSIG  SOA 5 2 3600 20160101220244 20151202210244
35970    ripe.net.    CqALQMFG6RUszLf+U7fKHEMJEtIPrXspcMp7/zgBHxBwx1+N035Wk+jKNMjWs2nuXj93NLfd1nvpmsqxLFv7yTI7MBOSnOlU/pTYOIvglxgzcvSrW4IHguKfzKYTVXJAXVjeThk7pAeX3vSqGUBE6jPQc66AGIeBsJbf7Sm4Nwg=
ripe.net.    299  IN  NSEC  256cns.ripe.net. A NS SOA MX AAAA RRSIG NSEC DNSKEY
ripe.net.    299  IN  RRSIG  NSEC 5 2 300 20160101220244 20151202210244
35970 ripe.net. P+t7qsYnkEuKB5PtDurI92KmNEBVKUTPeAKq4xNb6S/IjSpwSGFC3VlDPUZfvzPzqS10DfxBH2TIKQzPh2RBHka0q7LVRsboVx6BygfBO6wTAeHiUYlSCkbDtLH2SosJufFUocBYhxrlJtMc0FhJxoZ0iS8cGwC6806Ssfu1cK8=
ns1.nl-ams.as112.ripe.net. 299 IN NSEC aso.ripe.net. A AAAA RRSIG NSEC
ns1.nl-ams.as112.ripe.net. 299 IN RRSIG NSEC 5 5 300 20160101220244
20151202210244 35970 ripe.net. V3u1qNsV6yHSzQfPIq0ufCan3cZmlGH618FiZ0FcgB4FuWP5K5U1xEV1gHIpD5rdw0h2uD8jDImIlqopidyjskUyvEPX3ZvuBetamAcaWcfp2GvTsY3cC4Be8WV21vaSu4tbjTCyKaSzhMPu/xcBA3DcW30lQVIZkGrXd3wVHt8=

Интересно, что этот подход сам по себе создает еще одну проблему - сервер сообщает клиенту два действительных имени хоста, о которых клиент не обязательно знает, что можно рассматривать как утечку информации. Поддомены могут содержать такую информацию, как назначение сервера (например, webserver-backup.example.com), операционная система или даже имена или роли сотрудников. Умный противник может пройти по всему каталогу, чтобы найти эту информацию. Рекомендуется рассматривать имена DNS как информацию, которая может быть обнародована, и не использовать какую-либо информацию, которая может быть полезна злоумышленнику. Еще одно решение - разделение зон DNS, как обсуждалось ранее в книге.

Были предложены другие меры по снижению рисков: RFC 5155 вводит записи NSEC3, которые возвращают хэш следующего домена вместо самого домена. В приведенных ниже примерах настройки DNSSEC в Linux используются записи NSEC3, и это становится обычной практикой в Интернете. По мере увеличения вычислительной мощности стало возможным онлайн-подписание ответов, что позволяет серверу создавать новый несуществующий домен и подписывать этот ответ, а не возвращать существующий домен. Это обычно называется ответом «белая ложь», потому что сервер возвращает несуществующие домены, но делает это в соответствии со спецификацией DNS. RFC 4470 описывает один из таких подходов, который называется «минимальное покрытие записей NSEC». Также есть предложение для NSEC5, которое добавит более надежную криптографию к хешированным ответам.

Внедрение DNSSEC на Linux

Включение DNSSEC в домене включает два шага: подписание записей DNS и отправку хэша в родительскую зону (часто регистратору) для включения в запись делегирования. Как описано выше, подписание записей на самом деле включает в себя множество различных подэтапов, таких как создание отдельных значений KSK и ZSK, подписание каждого набора RRSet и создание записей NSEC. К счастью, есть стандартные инструменты для автоматизации большей части этого процесса.

Команда zoneigner будет генерировать ключи, подписывать существующие записи и добавлять их в ваш файл конфигурации. Он поставляется с пакетом dnssec-tools. Эта команда сгенерирует ключи и подпишет все записи в существующем файле зоны:

zonesigner -genkeys -usensec3 -zone example.org pri.example.org

Чтобы позволить BIND обрабатывать запросы DNSSEC, следующим шагом будет добавление «dnssecenable yes» и «dnssec-validation yes» в раздел параметров в named.conf. Последний шаг - указать параметр файла соответствующего домена на новый подписанный файл зоны. Как только это будет сделано и BIND будет перезапущен, он начнет отвечать на запросы DNSSEC. Эти шаги необходимо будет повторить и на любых подчиненных серверах.

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

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

Внедрение DNSSEC в Windows

Настроить зону в Windows можно либо через командную строку, либо через графический интерфейс, но в этих примерах будет показано в командной строке.

Чтобы включить DNSSEC на сервере Windows:

DnsCmd.exe <Servername> /Config /enablednssec 1

Windows использует термин «trust anchors» для обозначения предварительно распределенных корневых ключей. Для DNS-серверов в общедоступном Интернете это будет корневой ключ, описанный выше. Для корня можно использовать записи DNSKEY или DS, поскольку DS - это просто хэш KSK. Обычно они хранятся в активном каталоге (AD), но для серверов, не относящихся к AD, они могут храниться в текстовом файле.

Для администраторов, которые запускают родительскую зону, записи DS могут быть добавлены к родительской с помощью этой команды:

C:\> Import-DnsServerResourceRecordDS -ZoneName example.com -DSSetFile "c:\windows\system32\dns\example.com"

Управление зоной DNSSEC

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

Лучший способ защитить закрытые ключи DNSSEC - это сгенерировать их на автономном компьютере, отделенном от любого доступа к сети, и использовать их только на этом компьютере. Более параноидальные пользователи могут даже использовать аппаратный модуль безопасности, который будет хранить ключи на отдельных специализированных носителях. Подписание файла зоны должно быть выполнено на том же компьютере, поэтому рекомендуется выполнять все изменения на этом компьютере и копировать подписанный файл зоны только при необходимости. Это очень безопасная установка, но это означает, что вносить изменения будет более громоздко и не разрешается динамическое обновление зоны. Некоторые администраторы предпочитают хранить закрытый ключ из ZSK на сервере имен, что снижает уровень безопасности, но упрощает управление. Следует принять стандартные меры предосторожности для максимальной защиты ключевого файла, например, чтобы его мог читать только пользователь сервера имен, использовать надежные пароли и периодически проверять доступ к серверу.

Теоретически ключи нужно менять только в случае их взлома. Но на практике регулярно менять ключи - это хорошая привычка, поэтому взлом методом грубой силы не может быть выполнен с разумными ресурсами. Кроме того, регулярная ротация ключей означает, что процесс будет лучше понят и менее подвержен ошибкам, если потребуется экстренная смена ключей. Как описано ниже, в протоколе DNSSEC принудительно выполняется периодическое переключение ключей за счет указания времени истечения срока действия в каждом ключе. Основная сложность при изменении ключа заключается в том, что резолверы могут кэшировать старые ключи или старые RRSIG, поэтому в течение некоторого времени необходимо будет поддерживать как старые, так и новые ключи. На самом деле существует две рекомендуемые процедуры для изменения ключей: предварительная публикация и двойная подпись. Более подробная информация об обоих приведена в RFC 6781. Предварительная публикация ZSK включает следующие этапы:

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

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

Обратите внимание, что в приведенном ранее примере выходных данных DNSKEY были два ключа KSK, так как в нем использовался метод двойной подписи.

Управление сроками действия ключей

Обычный DNS уже имеет поля TTL в каждой записи, но DNSSEC добавляет срок действия подписи. Здесь установлено абсолютное время, а не количество секунд, поэтому важно поддерживать синхронизацию часов между DNS-серверами. Срок годности часто устанавливается в неделях, иногда в одну неделю, а иногда в один месяц. Короткий период действия означает, что ключи нужно будет менять чаще, но более длительный период дает злоумышленнику больше времени для кражи или взлома ключей. Поскольку DNSSEC использует более короткие открытые ключи, чем TLS, атаки методом перебора возможны в течение месяцев или лет. Согласно одному расчету, сделанному в 2014 году, ключи могут быть взломаны за 30 дней с использованием оборудования AWS примерно за 1 миллион долларов[5]. Примечание в RFC 6781, написанное в 2012 году, говорит, что ни один 1024-битный ключ RSA никогда не был взломан за какое-либо время. Итак, пока атаки улучшаются, и протокол предназначен для смягчения будущих угроз, 1024-битные ключи должны быть безопасными в течение нескольких месяцев в обозримом будущем.

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

Проверка DNSSEC Look-aside

Разработчики DNSSEC столкнулись с проблемой полагаться на цепочку доверия, которая может касаться многих различных доменов в иерархии DNS, но разные организации могут внедрять DNSSEC в разное время. Например, по состоянию на 2016 год домен верхнего уровня (TLD) .ae не поддерживал DNSSEC, поэтому даже если в субдоменах реализован DNSSEC, цепочка доверия не может быть установлена на всем пути до корня, и, таким образом, DNSSEC будет неэффективным. Чтобы смягчить эту проблему, существует так называемая проверка DNSSEC Look-aside. Это отдельная служба, в которую администраторы могут отправлять хэши своих ключей, и некоторые клиенты знают, что нужно запрашивать эту службу, если они проверяют ключ через родительскую зону, которая не поддерживает DNSSEC. Однако, поскольку подавляющее большинство TLD действительно поддерживают DNSSEC, в большинстве случаев в этой услуге нет необходимости.

Другие использования DNSSEC

Поскольку большая часть базовой инфраструктуры DNS в Интернете теперь поддерживает DNSSEC, это открывает интересную возможность. Инфраструктура предоставляет клиентам возможность безопасно находить авторитетные серверы для любой части пространства имен DNS. Она имеет множество уровней кэширования, которые разрабатывались более двух десятилетий, и рассчитаны на краткосрочное истечение срока хранения данных. Поэтому неудивительно, что люди предложили распространять сертификаты TLS, например, через DNSSEC. Этот процесс, первоначально предложенный в RFC 6698, называется аутентификацией именованных объектов на основе DNS (DANE). В случае широкого внедрения он может создать конкуренцию центрам сертификации TLS. DANE также может использоваться для распространения криптографических ключей для электронной почты, программ обмена мгновенными сообщениями или других протоколов.

DNSSEC и DDoS-атаки с усилением

Последний спор в сообществе DNS заключается в том, сделает ли DNSSEC более серьезными DDoS-атаки. Распространенной тактикой DDoS является отправка миллионов запросов с поддельными IP-адресами источника на большие DNS-серверы. Серверы послушно ответят на поддельный IP-адрес, который является предполагаемой жертвой атаки. Если злоумышленник может отправить 50 байт в запросе и заставить сервер ответить 500 байтами жертве, он «усиливает» свою атаку в 10 раз.

На первый взгляд кажется, что в этих атаках могут использоваться пакеты DNSSEC, поскольку они будут содержать большие ключи. Фактически, сообщения о том, что это уже происходит в реальных условиях, появились в феврале 2016 года. Объем DDoS в этом инциденте достиг пика в 123 Гбит/с, и большая часть содержимого трафика была составлена из ключей DNSSEC[6]. Контраргумент состоит в том, что это не уникально в DNSSEC. При ближайшем рассмотрении атаки 2016 года злоумышленники отправляли поддельные запросы на ANY, поэтому он не был специально нацелен на DNSSEC. Пол Викси утверждает, что вина полностью лежит на другом: «брандмауэр замедляет не общее количество битов в секунду (которое можно увеличить, используя сообщения большего размера, и EDNS0 и DNSSEC подойдут), а скорее общее количество пакетов. в секунду»[7]. Трудно дать окончательные рекомендации, кроме как сказать, что администраторы должны внимательно следить за своей сетью на предмет наличия признаков DDoS-атаки.

Критика DNSSEC

Критика DNSSEC обычно сводится к двум темам: он сложен и, пока не будет включен повсюду, обеспечивает неполную безопасность. Для выполнения запроса с полной проверкой потребуется три запроса для каждого компонента имени хоста (запрос, DNSKEY и DS). Для относительно простых доменов, таких как www.example.com, это означает девять запросов вместо одного. Это может означать, что при использовании DNSSEC запросы будут выполняться на порядок дольше. Кроме того, если трафик DNS внезапно увеличится в девять раз по всему миру, это, безусловно, создаст нагрузку на существующую инфраструктуру. Но большая часть этого смягчается кешированием, уже встроенным в систему. Резолверы быстро создадут список ключей для популярных доменов, чтобы запросы на новые имена хостов в этих доменах могли быть аутентифицированы без каких-либо дополнительных запросов. Выполнение криптографических алгоритмов также увеличивает нагрузку на ЦП на DNS-серверы и резолверы, но, как правило, она минимальна. Для сравнения, TLS требует более сложных операций, но улучшения аппаратного и программного обеспечения за последние 10 лет означают, что он может работать с влиянием на производительность менее 10%[8].

Связанная с этим проблема заключается в том, что для работы зоны DNSSEC с высочайшими стандартами безопасности все еще требуются ручные усилия. Например, хранение ключевого материала на автономных серверах обычно означает, что администратор должен вручную переносить подписанный файл из одной сети в другую каждые несколько недель. Подобная сложность даже вызвала проблемы с магистралью Интернета. В марте 2016 года DNSSEC для больших частей адресного пространства ARIN перешел в автономный режим из-за неисправного сценария[9]. По мере того, как DNSSEC получает все более широкое распространение, инструменты и процессы необходимо будет оптимизировать, чтобы управление безопасной зоной было не сложнее, чем обработка сертификатов TLS.

Это правда, что запрос не может быть проверен, если вся цепочка от имени хоста до корня DNS не реализовала DNSSEC. Впервые он был включен в корне DNS в 2010 году, а по состоянию на 2016 год большинство TLD используют DNSSEC, включая .com, .net и .org. Таким образом, почти все домены могут включить DNSSEC и установить цепочку доверия, которая будет работать с подавляющим большинством кэширующих резолверов. Также многие крупные поставщики DNS, такие как Google Public DNS и Cloudflare, по умолчанию включают DNSSEC. Таким образом, большая часть инфраструктуры уже создана.

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

Одна область, которая требует дальнейшего развития, - это интеграция проверки DNSSEC во все резолверы DNS. Например, большинство веб-браузеров еще не имеют встроенной поддержки. Некоторые библиотеки добавляют новые функции для разрешения DNSSEC, такие как функция val_gethostbyname в Linux. Одна из основных сложностей, которую следует учитывать, заключается в том, что DNSSEC добавляет к запросам новый случай ошибки - запрос может получить ответ, который не прошел проверку. Если веб-браузер обнаруживает такую ошибку, как он должен отображать ее обратно пользователю? Это можно рассматривать как отсутствие ответа, но могут быть случаи, когда пользователь по-прежнему хочет перейти на непроверенную страницу. Наиболее вероятный подход заключается в том, что браузеры будут обрабатывать недопустимые подписи DNSSEC так же, как они обрабатывают недопустимые сертификаты TLS. Браузер может отобразить предупреждение вместе с подробностями о том, почему подпись недействительна, и позволить пользователю продолжить работу. Но эта функция еще не встроена в большинство браузеров, и большинству пользователей необходимо будет узнать, что означают сообщения об ошибках.

Выводы

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

Заметки

  1. https://securelist.com/blog/incidents/31628/massive-dns-poisoning-attacks-in-brazil-31/

  2. http://blogs.wsj.com/digits/2014/01/21/chinas-sina-baidu-and-other-big-websites-are-hit-with-disruptions/

  3. https://www.ietf.org/rfc/rfc2065.txt

  4. https://wiki.mozilla.org/CA:IncludedCAs

  5. http://stoneyforest.net/Bchris/blog/freebsd/dns/dnssec-rollover.html

  6. https://www.stateoftheinternet.com/downloads/pdfs/2016-state-of-the-internet-threat-advisory-dnssec-ddos-amplification-attacks.pdf

  7. http://serverfault.com/questions/708076/what-kinds-of-security-vulnerabilities-does-providing-dnssec-expose/747213#747213

  8. http://www.cs.rice.edu/Bdwallach/pub/tls-tocs.pdf

  9. http://lists.arin.net/pipermail/arin-ppml/2016-March/030726.html

Глава 11
Anycast и другие протоколы DNS

Информация в этой главе

Вступление

В этой главе будут описаны некоторые реальные примеры сложных или экзотических конфигураций DNS. Сначала мы рассмотрим anycast, который обеспечивает большую часть магистральной сети DNS. Крупномасштабные сети все чаще используют anycast для распределения инфраструктуры по всему миру. Затем будет рассмотрен Multicast DNS (mDNS) и протокол обнаружения сервисов DNS (DNS Service Discovery (DNS-SD)), которые популярны на мобильных устройствах. Наконец, будут рассмотрены альтернативные протоколы DNS, такие как Tor Hidden Services и распределенные хеш-таблицы BitTorrent (DHT).

Мотивация ANYCAST

Чтобы понять важность anycast, можно начать с некоторой статистики по магистрали DNS. Напомним, что «корень» DNS - это набор серверов, которые будут указывать на авторитетные серверы для .com, .net и любого другого домена верхнего уровня (TLD).

Из-за максимального размера пакета DNS количество корневых серверов ограничено 13. Этот расчет оставляет место для заголовков и предполагает наименьшие возможные имена владельцев [1]. Корневые серверы помечены от a.root-servers.net до m.root-servers.net. Каждый раз, когда клиент резолвит домен, при условии, что ничего не было кэшировано, первым запросом всегда будет получение списка корневых серверов (технически это запрос к «.»), за которым следует запрос к одному из этих корневых серверов для разрешения TLD.

$ dig @8.8.8.8 . NS
; << >> DiG 9.8.3-P1 << >> @8.8.8.8 . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 31592
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.    IN NS

;; ANSWER SECTION:
.    10404  IN  NS  i.root-servers.net.
.    10404  IN  NS  l.root-servers.net.
.    10404  IN  NS  f.root-servers.net.
.    10404  IN  NS  g.root-servers.net.
.    10404  IN  NS  d.root-servers.net.
.    10404  IN  NS  j.root-servers.net.
.    10404  IN  NS  a.root-servers.net.
.    10404  IN  NS  k.root-servers.net.
.    10404  IN  NS  m.root-servers.net.
.    10404  IN  NS  c.root-servers.net.
.    10404  IN  NS  e.root-servers.net.
.    10404  IN  NS  b.root-servers.net.
.    10404  IN  NS  h.root-servers.net.

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

Оценки общей нагрузки на корневые DNS-серверы варьируются от сотен тысяч запросов в секунду до миллионов запросов в секунду и зависят от времени суток и того, подвергается ли инфраструктура атаке. В начале 2016 года корневой k-сервер обрабатывал от 40 000 до 60 000 запросов в секунду[2]. Пик нагрузки обычно приходился на полдень в часовом поясе UTC и достигал минимума около полуночи. В тот же день l-root получал от 30 000 до 45 000 запросов в секунду[3]. Поскольку запросы к корневым серверам выполняются циклически, разумным приближением будет умножить нагрузку на один сервер на 13 и заключить, что общий корневой сервер трафик составляет от 400 000 до 800 000 запросов в секунду. В крайнем случае, атака на корневые серверы в ноябре 2015 года сгенерировала около 5 миллионов запросов в секунду, которые были поглощены инфраструктурой[4]. По оценкам Cisco, с 2010 по 2015 год интернет-трафик вырос в 5 раз[5], а общий трафик на Amsterdam Internet Exchange - один основных точек пиринга, росла с той же скоростью[6]. Количество DNS-запросов не совсем коррелирует с общим интернет-трафиком, поскольку потоковое видео сейчас доминирует над пропускной способностью, но это дает приблизительное представление о будущем росте сети. Исходя из этого, разумно предположить, что корневой инфраструктуре DNS потребуется обрабатывать среднюю нагрузку в миллионы запросов в секунду, при этом пиковая нагрузка в несколько раз превышает это число.

Как инфраструктура может справиться с этой нагрузкой и оставаться высокодоступной? При проектировании системы для корневых серверов можно столкнуться как минимум с двумя узкими местами: пропускной способностью сети и мощностью процессора. Маршрутизаторы высокого класса обычно предназначены для обработки пакетов на «линейной скорости», поэтому гигабитный маршрутизатор, обрабатывающий только 512-байтовые UDP-пакеты DNS, должен иметь возможность передавать около 250 000 пакетов в секунду. Маршрутизаторы могут столкнуться с другими ограничениями, такими как фильтры безопасности или ведение журнала, но они либо не будут применяться к общедоступной службе, такой как DNS, либо могут быть отключены опытными администраторами. Более серьезной проблемой будет обработка большего количества запросов по TCP, потому что для этого требуется больше пакетов, а у маршрутизаторов часто есть некоторые накладные расходы для каждого нового соединения. Кроме того, поскольку DNSSEC становится все более распространенным, он добавит в два или три раза больше запросов для выполнения проверки. С этим можно справиться, постоянно используя более крупные маршрутизаторы, и на самом деле корневой сервер B использует этот подход[7]. Конечно, пропускная способность восходящей сети должна быть предоставлена аналогичным образом, чтобы избежать создания узких мест.

Другое ограничение - это вычислительная мощность на сервере. Корневому серверу необходимо получить запрос DNS, передать его через стек IP, получить ответ из памяти, создать ответ и передать пакет обратно. Общее практическое правило - сервер может обрабатывать десятки тысяч пакетов UDP в секунду без особой настройки. Cloudflare недавно сообщил об ограничениях, возникающих при попытке максимально увеличить это число. Первый простой подход - написать цикл, который отправляет по существу пустые пакеты с помощью sendmsg и recvmsg, которые можно использовать как массовые версии системных вызовов send и recv. Так можно будет отправлять от 200 000 до 350 000 пакетов в секунду. Чтобы выйти за этот предел, нужно больше разбираться в используемом сетевом оборудовании и ЦП. Например, большинство сетевых карт имеют несколько очередей отправки и получения, которые могут обрабатываться разными ядрами ЦП параллельно. Но часто нужна балансировка нагрузки в зависимости от IP-адреса источника, IP-адреса назначения, порта источника и порта назначения. Таким образом, большой объем трафика на одном сокете будет узким местом для одного ядра ЦП. Как описано в их отчете, путем распределения трафика по нескольким очередям RX, многопоточности отправляющего и принимающего приложения и обеспечения доступа потоков к одной и той же физической оперативной памяти можно отправлять 1 миллион пакетов в секунду[8]. Это не учитывает никакой обработки для создания пакетов, просто чисто отправку и получение. Простая реализация корневых узлов потребует сопоставления TLD с записями SOA, что потребует по крайней мере двух обращений к памяти для каждого ответа. Поскольку доступ к локальной памяти особенно важен для поддержания пропускной способности пакетов для процессоров, любые запросы памяти будут противоречить очередям пакетов.

Последнее соображение - поддержание низкой задержки запросов. Обычный порог для операций, которые считаются полностью интерактивными, составляет 100 миллисекунд. Предположительно, это произошло в системах телефонии, где люди начнут менять свои разговорные модели, если задержка превышает 100 мс[9]. Для инфраструктуры DNS идеальная задержка составляет не менее половины или трети этого числа, потому что часто будет несколько рекурсивных запросов, и за запросом, скорее всего, последуют другие сетевые запросы, такие как загрузка веб-страницы. Корневые серверы публикуют данные мониторинга, и в день начала 2016 года средняя задержка за 10-минутный период составляла от 9 до 165 мс, при этом большинство из них было ниже 50 мс[10]. Для сравнения, Netcraft периодически публикует список «самые надежные хостинговые компании», и в ноябре 2015 года в топ-10 была задержка DNS-запросов от 94 до 278 мс[11].

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

Anycast

Как описано в RFC 4786, anycast - это «практика предоставления определенного служебного адреса в нескольких, дискретных, автономных местах, так что отправляемые дейтаграммы направляются в одно из нескольких доступных мест». Важно понимать несколько терминов. Администраторам необходимо различать IP-адрес, который является «anycasted» (любым), и конкретные экземпляры сервера, использующие этот IP-адрес. Они также не могут говорить о подключении клиента к IP-адресу, потому что это будет означать разные вещи в зависимости от клиента и состояния сети. Таким образом, термин «service address» (служебный адрес) используется для обозначения IP-адреса, который будет совместно использоваться, а серверы, которые совместно используют его, называются «anycast nodes» (узлами anycast) (технически служебный адрес является более общей категорией, чем IP-адрес, и он может относиться к любому адресу в любой схеме маршрутизации, но в этом контексте это обычно относится к совместно используемому IP). Узлы anycast можно охарактеризовать как «internally connected» (внутренние), потому что администратор должен иметь какой-то способ прямого доступа к каждому узлу, часто через отдельный сетевой адаптер с его собственным IP-адресом. Каждый узел anycast будет иметь «catchment» (сбор), который относится к части сети, которая будет маршрутизирована в этот экземпляр. Наконец, узлы anycast могут быть «local» или «global» в зависимости от того, ограничен ли их охват частью сети или открыт для всех.

Лучше всего думать об anycast с точки зрения клиентов. Это способ настройки маршрутизации, при которой два клиента, подключающиеся к одному и тому же IP-адресу, будут направлены в два разных места назначения. Так, например, клиент в Германии будет подключаться к серверу в Германии, клиент в Соединенных Штатах подключится к серверу в Соединенных Штатах, а клиенты в любом другом месте будут подключаться к серверу в Токио, даже если все они подключатся к одному и тому же IP-адресу. Используя жаргон, это будут два узла anycast локальной области действия со сборами в Германии и США, а также один узел глобального рейтинга в Токио.

Реализация anycast

Важно отметить, что anycast - это не протокол, это просто набор правил маршрутизации. Можно реализовать тривиальную версию anycast на домашнем маршрутизаторе, добавив правило для отправки всего трафика, например, из 192.168.1.100, предназначенного для 8.8.8.8, на интерфейс обратной связи. Это будет означать, что трафик, предназначенный для 8.8.8.8, будет идти в разные места в зависимости от исходного IP-адреса (либо на интерфейс обратной связи маршрутизатора, либо на фактический IP-адрес в Интернете). В Интернете это реализовано с помощью нескольких маршрутов BGP к одному и тому же IP-адресу. Например, если бы кто-то транслировал IP 1.1.1.1 с узлом в Германии и Соединенных Штатах, как немецкий, так и американский центры обработки данных объявили бы маршрут в 1 хоп на этот IP. Основные маршрутизаторы в Европе предпочли бы направлять трафик в немецкий центр обработки данных и наоборот для североамериканской магистрали. Упрощенная схема представлена на рис. 11.1.

Рисунок 11.1 В этом примере IP 1.1.1.1 является anycast, а 2.2.2.2 - unicast. Обратите внимание, что клиенты из разных мест будут посещать различные экземпляры 1.1.1.1, но всегда один и тот же 2.2.2.2.

Самый простой способ запустить службу Anycast в Интернете - это купить инфраструктуру у того, кто ее уже настроил. Большинство крупных хостинг-провайдеров не публикуют прайс-листы публично, но они предлагают услуги по договорным ценам. Часто в таблицах маршрутизации BGP хранятся только записи для каждого сетевого блока /24, поэтому необходимо контролировать IP-адрес как минимум класса C и произвольно передавать весь диапазон. Затем маршруты к этим IP-адресам нужно будет объявить или иным образом добавить в таблицы BGP в Интернете[12]. В частной сети нужно просто настроить таблицы маршрутизации на граничных маршрутизаторах, чтобы реализовать то же самое. Например, можно использовать один и тот же IP-адрес для корневого DNS-сервера на предприятии с местоположениями в Нью-Йорке и Берлине и добавить маршрут на базовом маршрутизаторе на каждом сайте для отправки этого IP-адреса в локальный пункт назначения. Обычная практика при настройке anycast - использовать на сервере два интерфейса: один для общего IP-адреса, а другой - для этого хоста. Таким образом, всегда можно подключиться к определенному серверу для обслуживания.

Anycast становится популярным выбором для распространения услуг, но имеет множество ограничений как в теории, так и на практике. Во-первых, он не дает никаких гарантий балансировки нагрузки. В нашем примере немецкий сервер, вероятно, будет более загружен, чем американский, когда в США утро, а в Германии - середина ночи, и anycast не пытается их сбалансировать. Для такой службы, как корень DNS, где и пользователи, и инфраструктура широко распределены, это просто означает, что не все узлы будут иметь одинаковый уровень использования одновременно.

Anycast также может создать проблемы с маршрутизацией. Например, во внутренней сети хост может быть одинаково близок к двум различным узлам anycast. Используя алгоритм маршрутизации, в котором расстояние является основным фактором, например OSPF, клиент может постоянно переключаться между пунктами назначения. Для DNS это обычно не проблема, поскольку он в основном использует одиночные пакеты UDP и является протоколом без сохранения состояния. Общедоступный Интернет использует BGP для межсетевой маршрутизации, которая имеет тенденцию выбирать стабильные маршруты. Но для приложения с отслеживанием состояния, такого как веб-сайт, или даже для любого сеанса TCP, в котором задействовано несколько пакетов, всегда есть вероятность, что маршруты будут колебаться в середине сеанса. Чем ближе топологически экземпляры и чем дольше продолжаются сеансы, тем больше вероятность возникновения этих проблем. Также во всех случаях состояние маршрутизации должно быть тесно связано со статусом приложения. Например, маршрут не должен рекламироваться до того, как приложение станет доступным, и его следует отменять всякий раз, когда услуга отключена.

Еще одна потенциальная проблема - это сценарий «каскадных сбоев», когда большой объем трафика, идущего к одному узлу, перегрузит его, затем весь этот трафик будет перенаправлен на следующий ближайший узел и проблема повторится. Одна из конфигураций, позволяющая избежать этого, - использовать много локальных узлов и несколько глобальных узлов, которые можно рассматривать как два уровня обслуживания. Если локальный узел выходит из строя, клиенты будут направлены на более мощный глобальный узел вместо переключения на другой локальный узел. Корневой сервер F использует эту конфигурацию с двумя глобальными узлами в Сан-Франциско и Пало-Альто и более чем 30 локальными узлами по всему миру. Они обычно развертывают локальные узлы в точках обмена данными в Интернете и отмечают маршруты как неэкспортируемые в BGP[13].

Для обеспечения чрезвычайно высокой доступности рекомендуется избегать одновременного обновления программного обеспечения на всех узлах и фактически изменять версию и сами пакеты программного обеспечения в разных точках сети. Это сделано для того, чтобы ошибки не вывели из строя всю систему. Иногда ошибки могут быть очень незаметными и проявляться только при большом объеме реального интернет-трафика. Эту практику можно увидеть в большом масштабе в корне DNS, где разные поставщики используют BIND, NSD и Knot DNS. Конечно, запуск различных типов и версий программного обеспечения намного сложнее с административной точки зрения; это может привести к человеческим ошибкам, которые хуже, чем каскадные программные сбои. Поэтому его следует предпринимать только в критической инфраструктуре с большой административной операцией.

Последнее препятствие, с которым может столкнуться администратор, заключается в том, что многие маршрутизаторы используют пересылку обратного пути (RPF), чтобы убедиться, что они не пересылают трафик с поддельным IP-адресом источника. Они делают это, проверяя, соответствует ли интерфейс, на котором они получают пакет, текущей таблице маршрутизации. В частности, интерфейс, на котором получен пакет, должен соответствовать интерфейсу, на который он будет отправлен, если вернуться к этому исходному IP. Существуют сценарии, в которых anycast нарушает это предположение, поскольку представление сети с исходного IP-адреса может не совпадать с представлением от промежуточного маршрутизатора. Для администраторов, облегчающих Anycast-трафик, тема RPF в многосетевых сетях обсуждается в RFC 3704. Конечный пользователь мало что может сделать, если восходящий маршрутизатор блокирует Anycast-трафик из части своей сети, кроме попыток переговоров с этим провайдером. Это еще один аргумент в пользу аренды инфраструктуры, которая уже настроена и протестирована.

Anycast создает несколько проблем для анализа безопасности, в основном связанных с обнаружением перехвата маршрута. Например, без какой-либо рассылки можно попытаться подключиться к услуге из разных регионов, чтобы убедиться, что все они маршрутизируются в одно и то же место. Или можно попробовать трассировку из разных мест, чтобы увидеть, есть ли в соединении неожиданные переходы. В сети Anycast можно ожидать увидеть совершенно разные маршруты в зависимости от источника или даже текущего состояния сети. Например, если пользователь в стране A подключается к услуге anycast, которая имеет узел в стране A, но фактически направляется в конечную точку в стране B, это пример перехвата маршрута или просто время, когда сеть в стране А испытывала перегрузку? Этот анализ по-прежнему можно выполнить, сравнивая множество различных хостов, которые топологически близки друг к другу, но это сложнее, чем сценарий с предварительным любыми действиями. DNS помогает решить эту проблему, предоставляя необязательное поле NSID, которое может возвращать номер идентификатора для каждого сервера. Администраторы могут использовать это, чтобы определить, на какой сервер они направляются. Dig предоставит эту информацию с опцией +nsid.

Anycast и DDoS

Поклонники сетевых технологий часто ссылаются на anycast как на решение для распределенных атак типа «отказ в обслуживании» (DDoS). Но что интересно, иногда это происходит по противоречивым причинам. Некоторые скажут, что это эффективно, потому что оно распределяет трафик по широкому кругу серверов и, таким образом, снижает нагрузку на любую конкретную ссылку. Если злоумышленнику требуется 100 Мбит/с для выхода из строя одного сервера, ему потребуется 10 Гбит/с для выхода из строя системы Anycast, равномерно распределенной по 100 различным узлам. Другие утверждают, что anycast эффективен, потому что он концентрирует трафик DDoS на небольшом количестве узлов, сохраняя, таким образом, остальную часть сети. Например, предположим, что ботнет состоит из тысяч взломанных хостов, большинство из которых расположены в университетах США. Если он запустил DDoS-атаку против любого IP-адреса с экземплярами в Соединенных Штатах и Европе, трафик может захлестнуть экземпляр в США, но не отключит европейский.

На самом деле оба аспекта помогают по-разному. Как сказал Крикет Лю в цитате, открывающей эту главу: «Если злоумышленники не смогут одновременно получить достаточно трафика из Северной Америки, Европы и Азии, чтобы завалить вашу инфраструктуру, они не добьются успеха»[14]. Сетевые атаки часто бывают асимметричными по характеру, поскольку злоумышленники выбирают время и метод, а защитники должны готовиться к любому сценарию. Как часто повторяется, злоумышленник может попробовать тысячу векторов, и ему нужно найти только один, который работает. Но это один из способов перевернуть сценарий - при нацеливании на сеть с произвольной трансляцией любая ссылка, которую злоумышленники не заполнят должным образом, позволит всей сети продолжить работу. В 2013 году DDoS-атака со скоростью 75 Гбит/с на Spamhaus была остановлена большой сетью Anycast, управляемой Cloudflare. В сообщении в блоге они упоминают, что распределение трафика по разным центрам обработки данных позволяет им запускать фильтры более эффективно[15]. Это показывает еще одно преимущество anycast - разделение трафика на 23 разных местоположения сделало его более управляемым на 3,3 Гбит/с, где можно запускать более сложные поведенческие черные списки. Это может сформировать полезный цикл: с трафиком, распределенным по большему количеству сетевых ссылок, фильтрация становится проще; с улучшенной фильтрацией сетевые ссылки остаются в рабочем состоянии; и с увеличением числа функциональных сетевых каналов трафик будет по-прежнему широко распределяться.

Мультикаст DNS

Могут ли сетевые службы пропускать запросы DNS к центральному серверу и автоматически находить друг друга? Это мотивация для mDNS, который в настоящее время активен во многих потребительских устройствах. Например, если смартфон подключается к домашней сети, он может использовать mDNS для поиска телевизора, который также находится в сети, без необходимости установки DNS-сервера. Популярной реализацией mDNS является протокол Apple Bonjour, который работает на большинстве их устройств.

По сути, mDNS отправляет запросы каждому хосту в локальной сети, и соответствующая конечная точка отвечает. Например, устройство может называться «smart-tv.local», поэтому любые устройства, желающие подключиться к телевизору, будут выполнять запрос mDNS для этого имени, и телевизор будет отвечать назначенным им IP-адресом. Суффикс «.local» зарезервирован для mDNS, и имена хостов в этой форме называются «link-only» (только для ссылок), поскольку их можно использовать только в локальной сети. RFC 6762 указывает, что клиенты DNS должны пытаться разрешить такие имена хостов через mDNS. Точно так же обратные DNS-запросы для многоадресных IP-адресов или других IP-адресов только для канала должны обрабатываться через mDNS.

Многоадресная рассылка была впервые указана в RFC 1112, опубликованном в 1989 г. Она резервирует диапазон IP-адресов с 224.0.0.0 до 239.255.255.255 исключительно для многоадресных приложений, хотя mDNS всегда использует конкретный IP-адрес 224.0.0.251 (или эквивалентный IPv6 FF02::FB). Таким образом, запросы, отправленные на этот IP-адрес, будут маршрутизироваться всем клиентам в сети, и устройство с указанным именем хоста ответит. В mDNS порт 5353 используется вместо порта 53. Ответы обычно маршрутизируются обратно через многоадресную рассылку, поэтому все клиенты могут их видеть, но в некоторых случаях они отправляются через одноадресную рассылку только запрашивающей стороне. Выбор в ответном поведении будет зависеть от реализации.

Из концептуальной модели есть два исключения. На самом деле это протокол подписки, а не чисто широковещательный протокол. Устройства обмениваются данными через протокол управления группами Интернета (IGMP), чтобы сообщить маршрутизаторам, что они хотят присоединиться к сеансу многоадресной рассылки, и затем маршрутизатор будет пересылать пакеты этим устройствам. Так что, если IGMP по какой-то причине не работает, mDNS также выйдет из строя. Также ничто в протоколе не гарантирует, что указанное устройство ответит на запрос или что оно ответит правильным ответом. Это приводит к большей части проблем безопасности mDNS.

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

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

Более реалистичные сценарии состоят в том, что устройства могут незаметно транслировать информацию, которую пользователи не осознают. Например, многие устройства используют имя хоста по умолчанию, которое содержит настоящее имя пользователя (например, john-smith-phone.local). Когда они подключены к пресловутой сети Wi-Fi кофейни, имена будут транслироваться всем присутствующим. В некоторых случаях пакеты mDNS будут содержать записи SRV, чтобы показать, какие службы работают на этих устройствах, раскрывая ту же информацию, которая была бы найдена при сканировании портов[16]. Периодическая широковещательная передача записей mDNS встроена в протокол Bonjour, который работает на большинстве устройств Apple. Это сделано для того, чтобы обеспечить обнаружение новых сервисов, которые присоединяются к сети, без необходимости постоянного запроса каждому клиенту[17].

Распространенная неправильная конфигурация - доступ к mDNS из внешнего Интернета. Обычно это происходит, когда одноадресные запросы к порту 5353 разрешены через внешний брандмауэр, а службы mDNS отвечают, не проверяя, является ли источник локальным для канала. Это противоречит спецификации RFC 6762, но некоторые программы mDNS будут вести себя подобным образом либо из-за багов, либо из-за ошибок конфигурации. Один исследователь обнаружил более 100 000 примеров сервисов mDNS, которые были открыты для всего мира при сканировании частей Интернета[18]. Это приводит к утечке имен хостов, присутствующих в локальной сети, как описано выше, любому стороннему субъекту. С помощью этого метода исследователь обнаружил MAC-адреса, номера моделей оборудования и даже детали конфигурации NAS. Его также можно использовать в качестве вектора для атаки отражения DDoS. Если, например, многоадресный запрос для общей службы будет давать ответы от нескольких систем в каждой локальной сети, небольшой запрос может быть многократно усилен. В рекомендациях CERT по этой проблеме перечислены несколько основных производителей маршрутизаторов, которые допускают такое поведение по умолчанию[19]. Лучше всего блокировать порт 5353 или любой другой трафик mDNS на брандмауэре, если он не используется для определенной цели. Администраторы также должны отслеживать любой трафик mDNS, покидающий их сеть.

Последней плоскостью атаки в mDNS является DoS против самих сервисов. Часто это менее важная область для защиты, чем внешняя защита от DDoS-атак, поскольку злоумышленникам обычно требуется доступ к локальной сети, чтобы предпринять эти атаки. По состоянию на 2016 год авторам не было известно об успешных атаках. Но это часто упускается из виду, и тот факт, что все клиенты обычно кэшируют ответы mDNS, означает, что атака может затронуть несколько разных систем одновременно. Кроме того, поскольку протокол только недавно получил широкое распространение, некоторые устройства уязвимы для ошибок синтаксического анализа при обработке трафика. Например, уязвимость в некоторых маршрутизаторах Cisco, о которой было сообщено в 2014 году, может позволить удаленным злоумышленникам вызвать утечку памяти и DoS, отправив искаженные пакеты mDNS[20].

DNS service discovery

DNS-SD часто используется в сочетании с mDNS. Фактически, описывающие их RFC были выпущены в том же месяце и имеют последовательную нумерацию (RFC 6762 и 6763 соответственно). Его можно рассматривать как расширение mDNS, где вместо запроса в локальной сети определенного хоста клиент запрашивает такую службу, как «http servers» или «music libraries». Все это достигается с помощью записей PTR, SRV и, в некоторых случаях, TXT. Службы названы в соответствии с соглашением, <instance>.<service>.<domain>. Клиент, ищущий музыкальные устройства, будет запрашивать «_music._tcp.local», и хосты с этой службой будут отвечать записями PTR с названием их собственной службы. Обратите внимание, что этот ответ будет именем службы (например, jane's music._music._tcp.local), а не именем хоста самого компьютера. Также обратите внимание, что пространства имен «_music» и «_tcp» - это соглашения, которые были установлены заранее. Затем клиент будет запрашивать записи SRV для каждого результата PTR, чтобы подключиться к фактической службе. Один из самых популярных программных пакетов DNS-SD - Bonjour, разработанный Apple.

Технически DNS-SD может работать поверх одноадресного DNS, даже если он чаще развертывается с mDNS. Администраторы должны знать, как DNS-SD используется в их сетях и какая информация о хостах доступна для обнаружения. В остальном рекомендации по безопасности аналогичны mDNS. Обычно он должен быть доступен только в локальной сети, и администраторы должны отслеживать трафик на предмет аномального использования. В корпоративных средах, где сотрудники приносят свои собственные устройства, пользователи и администраторы должны остерегаться непреднамеренной утечки имен и другой потенциально конфиденциальной информации. Например, если сеть удалила имена сотрудников из имен хостов устройств, они все равно могут появляться в именах музыкальных библиотек или фотоальбомов. Если они объявляются через DNS-SD, они все равно будут видны всем в сети.

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

DNS-SD предоставляет возможность включения информации о приложении в записи TXT. Хотя это всегда было частью протокола DNS, похоже, что это более распространенная функция для обнаруживаемых служб, поскольку им может потребоваться предоставить информацию о соединении или версии. RFC предоставляет несколько примеров:

Скорее всего, это другой тип информации, который администраторы не используют для просмотра в трафике DNS, поэтому это еще раз подчеркивает важность мониторинга mDNS и трафика DNS-SD.

По состоянию на 2016 год поиск в базе данных CVE не выявил уязвимостей с использованием DNS-SD, но это открывает интересную плоскость атак. Разработчики часто предполагают, что DNS либо правильно направит клиентов к их сервису, либо нет, и это единственные случаи, требующие тестирования. Включение данных приложения в пакеты DNS значительно увеличивает количество возможных перестановок, которые необходимо учитывать. Вредоносные клиенты могут не уважать данные, содержащиеся в ответах, и злоумышленники могут подделать ответы ничего не подозревающих пользователей. Это может привести к незаметным векторам атаки. SSL, например, был уязвим для атак перехода на более раннюю версию, когда злоумышленники могли обманом заставить клиентов и серверы использовать более низкую версию шифрования, подделав пакеты начальной настройки. Подобные векторы следует учитывать при проектировании служб DNS-SD и сетей, в которых они работают. RFC 6763 рекомендует использовать DNSSEC для защиты от атак спуфинга, но по состоянию на 2016 год большинство реализаций DNS-SD, включая Bonjour от Apple, не включали эту поддержку. Между тем, для администраторов рекомендуется периодически просматривать пакеты DNS по сети с ожидаемым содержимым, чтобы отслеживать их на предмет подделки.

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

TOR hidden services

Эта глава завершается обсуждением нескольких альтернатив DNS и компромиссов, с которыми они сталкиваются. Первым примером является Tor - крупномасштабная сеть луковой маршрутизации, которая позволяет пользователям общаться через Интернет, не раскрывая свой исходный IP-адрес. Он имеет функцию, известную как скрытая служба, которая позволяет пользователю подключаться к «onion address» (луковому адресу) и перенаправляться (анонимно) на IP-адрес, на котором запущена эта служба. Это происходит без того, чтобы сервер знал IP-адрес клиента, и наоборот. Фактически, никто в цепочке маршрутизации не будет знать, что эти два IP-адреса обмениваются данными, а также не будет знать содержимое сеанса. В качестве примера часто упоминается продемократический веб-сайт, работающий в репрессивной стране.

Преобразование onion-адресов в сетевые местоположения можно рассматривать как другую форму DNS, но у нее есть два важных ограничения. Первый запечатлен в так называемом треугольнике Зуко. В нем говорится, что любая система адресации может выполнять не более двух из трех желаемых функций: значимые для человека имена, децентрализацию и безопасность. DNS, а точнее DNS с полностью реализованным DNSSEC, имеет значимые имена (например, «cars.com» в отличие от длинного списка цифр) и безопасность за счет централизованного корня. Скрытые службы Tor выбирают децентрализацию и безопасность, но не значимые имена. Таким образом, onion-адреса представляют собой псевдослучайные строки из 16 символов, а не читаемые человеком слова. Интересно, что треугольник Зуко не является теоретическим ограничением, поскольку системы были разработаны с учетом всех трех характеристик. Это скорее описание общих компромиссов в распределенной адресации[22].

Tor реализует поиск скрытых сервисов с помощью DHT. Как и обычная хеш-таблица, DHT хранит каждую запись в сегменте на основе своего ключа, но сегменты могут располагаться на нескольких разных серверах в сети. Ключом для скрытого сервиса Tor является его onion-адрес, полученный из его открытого ключа. Tor использует 80 бит для хранения адреса в своем DHT, что означает, что дубликаты могут возникать, если генерируется достаточно ключей (можно ожидать дублирование примерно каждые 240 или 1 триллион ключей). Это приводит к конфликту хешей внутри DHT, и информация для нового адреса просто перезаписывает старый. Интересно, что это известная проблема, о которой явно упоминают разработчики Tor. Они описывают воздействие следующим образом: «все, что может сделать злоумышленник, - это создать два разных открытых ключа, которые соответствуют одному и тому же имени .onion. Он не сможет выдавать себя за уже существующие скрытые службы»[23]. С точки зрения разрешения имен, возможность перезаписи существующих записей, безусловно, является слабым местом протокола.

BitTorrent/P2P DNS

Идея действительно децентрализованной версии DNS привлекала множество людей за последние пару десятилетий. Но по состоянию на 2016 год ни один из них не стал серьезным соперником. В 1995 году группа под названием AlterNIC создала альтернативный корень DNS, чтобы конкурировать с Network Solutions, которым были предоставлены исключительные права на регистрацию доменов. Это вызвало разногласия: одни утверждали, что это позволит сделать Интернет более демократичным, а другие утверждали, что сетям будет излишне сложно соединяться друг с другом[24]. Другие альтернативные корни, такие как eDNS и OpenRSC, также были активны в 1990-х годах. После того, как веб-сайт The Pirate Bay был отключен в 2010 году, один из его основателей выступил с инициативой по созданию системы DNS, не контролируемой ICANN. Было предположение, что он будет основан на BitTorrent DHT, что создаст проблемы, аналогичные тем, с которыми сталкиваются Tor Hidden Services[25].

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

Выводы

Хотя ядро протокола DNS осталось в основном неизменным с тех пор, как он был впервые разработан почти 30 лет назад, он породил множество сложностей и расширений. Anycast - это метод маршрутизации, используемый для поддержания низкой задержки и высокой надежности через активно используемый корень DNS. mDNS и DNS-SD - это расширения протокола, которые позволяют устройствам автоматически настраиваться в локальных сетях. Наконец, DNS-подобные службы встраиваются в одноранговые службы и анонимные сети, такие как Tor. Поскольку цифровые услуги продолжают расти, безопасное разрешение имен останется жизненно важной частью работы любых сложных систем.

Заметки

  1. https://lists.isc.org/pipermail/bind-users/2011-November/085653.html

  2. http://k.root-servers.org/statistics/ROOT/weekly/

  3. https://www.dns.icann.org/lroot/stats/

  4. http://arstechnica.com/security/2015/12/attack-flooded-internet-root-servers-with-5-million-queries-a-second/

  5. http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/VNI_Hyperconnectivity_WP.html

  6. https://en.wikipedia.org/wiki/Amsterdam_Internet_Exchange

  7. http://www.netnod.se/dns/iroot/faq

  8. https://blog.cloudflare.com/how-to-receive-a-million-packets/

  9. http://www.stuartcheshire.org/papers/latencyquest.html

  10. https://atlas.ripe.net/dnsmon/

  11. http://news.netcraft.com/archives/2015/12/03/most-reliable-hosting-company-sites-in-november-2015.html

  12. http://serverfault.com/a/648340

  13. http://www.aftld.org/bk/html/meetings/docs/anycast%20root%20servers.pdf

  14. http://www.infoworld.com/article/2612835/security/the-ultimate-guide-to-preventing-dns-based-ddos-attacks.html

  15. https://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho/

  16. https://www.trustwave.com/Resources/SpiderLabs-Blog/mDNS---Telling-the-world-about-you-%28and-your-device%29/

  17. https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/NetServices/Articles/about.html

  18. https://github.com/chadillac/mdns_recon

  19. http://www.kb.cert.org/vuls/id/550620

  20. http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140924-mdns

  21. https://tools.ietf.org/html/rfc6763

  22. https://en.wikipedia.org/wiki/Zooko’s_triangle

  23. https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames

  24. https://en.wikipedia.org/wiki/AlterNIC

  25. http://arstechnica.com/tech-policy/2010/11/fed-up-with-icann-pirate-bay-cofounder-floats-p2p-dns-system/