Система доменных имен
 Скачать 35.41 Kb.
|
|
Введение Интернет был задуман как саморегулирующаяся сеть компьютерных сетей. В результате этого, сегодня весь спектр телекоммуникационных технологий используется для непрерывной и надежной связи между различными странами. Технологии стремительно развиваются и с каждым днем становится все сложнее обеспечить безопасность информации в сети. Поэтому вопрос сохранности интернет-ресурсов становится тем более актуальным, чем масштабнее становится Всемирная паутина. Работа в сети построена на протоколах, одним из них является протокол доменных имен DNS. Система доменных имен Каждое обращение к ресурсам сети Интернет начинается с подключения к системе доменных имен DNS. Общение в социальных сетях, отправка электронной почты, посещение любого веб-сайта - для всего вышеперечисленного необходимо определить фактическое местоположение (IP-адрес) ресурса. DNS предоставляет необходимую информацию. Эта система гарантирует, что имя ресурса будет преобразовано в IP-адрес. Пространство доменного имени представляет собой древовидную структуру. Любой узел и лист в дереве соответствуют набору ресурсов (который может быть пустым). Каждый из компонентов доменного имени обслуживается независимым оператором. Через последовательное обращение к серверам происходит трансляция имени. Распределение доменных имен Система доменных имен позволяет получать доступ к веб-сайтам по их доменному имени (например, www.yandex.ru). Благодаря наличию доменных имен, нет необходимости вводить числовые IP-адреса (например, «212.78.1.25»). Когда устройство подключается к системе, используя адрес доменного имени, оно ищет IP-адрес, соответствующий данному доменному имени (далее DNS), а затем устанавливает соединение, используя нужный IP-адрес. Такой подход упрощает процесс перемещения сервера из одного места в другое. Серверу присваивается новый IP-адрес, и данные адреса домена обновляются. После обновления записи DNS новым запросам на доменное имя дается новый IP-адрес. Поскольку конечные пользователи получают доступ к большинству серверов с использованием доменных имен и не видят IP-адрес, сервер можно переместить в новое сетевое соединение, что не повлияет на возможность доступа конечного пользователя к серверу, например, если компания Яндекс захочет перенести свой веб-сервер на другой компьютер, у которого будет другой ip-адрес, то никаких ошибочных ситуаций не произойдет, так как доменное имя не изменится. Люди будут обращаться по тому же самому доменному имени, который будет отображаться по другому ip-адресу. Распределение доменных имен определяется правилами организаций, которые владеют ими. На вершине иерархии владения доменными именами находится организация под названием Корпорация по управлению доменными именами и IP-адресами (Internet Corporation for Assigned Network Names and Numbers – ICANN). ICANN распределяет домены верхнего уровня (top-level domain – TLD), такие как .com, .edu и .org между другими организациям. ICANN также занимается назначением двухбуквенных доменных имен верхнего уровня, таких как .us, .za, .nl и .jp, странам по всему миру. Такие доменные имена принято называть Национальными доменами верхнего уровня (country code top-level domain – ccTLD). Также часто используются TLD второго уровня, например, .co.uk для коммерческих организаций в Великобритании. Политика подачи заявок на доменные имена с любым конкретным ccTLD в разных странах сильно различается. После назначения организации определенного доменного имени контролирующая организация может назначать поддомены внутри домена верхнего уровня. Например, домен верхнего уровня .edu назначен организации Educause. Educause присваивает высшим учебным заведениям такие домены, как umich.edu. Как только университет получает контроль над umich.edu, он может самостоятельно выбирать поддомены в своем новом домене. Физические лица могут приобретать доменные имена с .com и .org. Владельцам таких доменов разрешается управлять своим доменом и создавать в нем поддомены для собственного или общего пользования. В таблице 1 представлены стандартизированные суффиксы имен. Таблица 1. Стандартизированные суффиксы имен
Структура DNS До появления системы доменных имен, роль инструмента для расшифровки символических имен в ip выполнял файл /etc/hosts, который в настоящее время до сих пор является важной составляющей. Однако с ростом числа хостов в глобальной сети стало сложно отслеживать и поддерживать базу данных имен на всех хостах. В результате была изобретена DNS, иерархическая распределенная система доменных зон. DNS выполняет две основных функции: организацию иерархического пространства имен; обеспечение разрешения (т.е. поиска соответствия) доменных имен в IP-адреса. Как и большинство сервисов DNS относится к средствам прикладного уровня модели OSI и строится по принципу "клиент-сервер". В структуре сервиса DNS выделяют следующие компоненты: Информационный ресурс - иерархически организованное пространство доменных имен. Соответствия доменных имен и IP-адресов описывается в распределенной по специальным узлам сети, называемым серверами имен, базе данных. Часть иерархического пространства имен, обслуживаемая одним сервером имен и представленная в его локальной базе данных, называется зоной ответственности (zone of authority). DNS-клиент (resolver) - программный модуль, который обеспечивает выполнение запросов к серверу имен с целью разрешения доменного имени. Как правило, DNS-клиент входит в состав операционной системы. Сервер имен (name server), или DNS-сервер, - программа, обеспечивающая хранение части распределенной базы данных соответствий IP-адресов и доменных имен, а также осуществляющая по запросу клиента поиск IP-адреса на основе предложенного доменного имени. Протокол DNS - протокол взаимодействия DNS-клиентов и DNS-серверов. Пространство доменных имен имеет иерархическую структуру. На самом верхнем уровне иерархии располагается корневой домен, который обычно обозначается точкой ("."). Следующий уровень иерархии составляют домены верхнего, или первого, уровня (Top Level Domains, TLDs). Каждый домен верхнего уровня включает в себя домены второго уровня и т.д. Теоретически домен любого уровня может содержать в себе как отдельные узлы, представленные своими именами, так и домены более низкого уровня (субдомены). Однако, на практике домены, уровень которых ниже третьего, встречаются крайне редко. Домены первого уровня делятся на три группы: домены общего назначения; национальные домены; обратный домен. Изначально домены общего назначения предназначались для объединения доменов нижних уровней, принадлежащих организациям и учреждениям США. Поэтому в силу традиции большая часть доменов, зарегистрированных за организациями других государств, входят не в домены общего назначения, а в так называемые национальные домены. Во вторую группу включены национальные домены (Country Code TLDs, ccTLDs). Имя каждого такого домена состоит из двух символов и представляет собой сокращение названия государства (так называемый "код страны"), которому принадлежит домен, например, "ru" означает Россия. Список национальных доменов разработан и утвержден Национальным Институтом Стандартов США (ISO 3166-1). Третья группа состоит из одного домена с четырехсимвольным именем "arpa", предназначенного для поиска доменного имени по IP-адресу (обратного разрешения). Каждый домен верхнего уровня, как правило, включает в себя домены второго уровня, имена которых выбираются относительно произвольно, например, по имени организации, за которой зарегистрировано это имя, или по названию региона. Порядок создания доменов второго уровня определяется администраторами соответствующего родительского домена верхнего уровня. Так, например, в национальном домене первого уровня "ru" установлен порядок, согласно которому внутри этого домена выделяются три группы доменов второго уровня. Домены общего пользования ("домены типа GENERIC"): "ac.ru" - домен Академии Наук России; "com.ru" - коммерческие организации; "edu.ru" - образовательные проекты и организации; "net.ru" -сети, принадлежащие различным организациям; "org.ru" - некоммерческие организации; "int.ru" - домен для общего использования; "mil.ru" - военные организации и учреждения; "pp.ru" - домен для использования частными лицами. Другие домены, имена которых выбираются произвольным образом, например, по имени владельца (имени человека, названию организации), обобщенной тематике, которой соответствует информация, представленная на узлах домена и т.п. Например, существует домен второго уровня "fio.ru", закрепленный за Федерацией Интернет Образования. Аналогично доменам второго уровня структуру доменов более низких уровней определяет администрация родительского домена. Поэтому не существует какой-либо единой для всех схемы структуризации таких доменов. Рассмотрим в качестве примера организацию домена Федерации Интернет Образования. Федерация имеет домен второго уровня "fio", зарегистрированный в домене "ru". В данном домене представлены как отдельные узлы, например, узел с именем "www" - узел, на котором размещен web-сайт Федерации, информационные узлы различных проектов Федерации ("parent", "teacher", "writer" и т.д.), так и различные субдомены третьего уровня, например, домен "center" - домен Московского Центра Интернет-образования, домен "net" - внутренняя сеть Федерации, домен "dlmsk" - домен поддержки системы дистанционного образования Московского Центра, а также домены региональных центров Федерации, названия которых определяются регионами (например, "spb" или "samara"). В свою очередь, домен третьего уровня "net" содержит в себе субдомен "msk" - домен, в котором размещены компьютеры учебных классов Московского Центра. Атаки DNS Не секрет, что все современные технологии Интернета получили свою жизнь еще в 70-80-х годах. В то время разработчиков интересовала сама возможность, и никто особо не рассчитывал на то, что Сеть станет общедоступной и разрастется до мировых масштабов, а подключаться к Интернету можно будет с любой точки планеты. В итоге практически во всех протоколах не была предусмотрена возможность защиты или повышения безопасности. Результат мы получили в виде спама, атак на ресурсы Сети путем подделки DNS-адресов и многих других проблем. Сегодня изменить что-то глобально невозможно, слишком много сил и средств необходимо потратить. Поэтому и проблемы пытаются решить при помощи разного рода надстроек над протоколами, расширений, использующих в качестве защиты стойкую криптографию. Если DNS выдает неправильную информацию, это сказывается на работе любого сервиса, его запрашивающего. Известны две возможные атаки на DNS как на сервис разрешения имен: DDoS (Denial of Service) – атака на отказ в обслуживании, в результате которой сервер перестает отвечать на запросы клиентов); DNS Spoofing/DNS cache poisoning – атака, заключающаяся в подмене действительной записи о соответствии имени и IP-адреса в кэше DNS-сервера ложной записью, в результате пользователь, набравший это имя, направляется совсем по другому адресу. Атака с помощью рекурсивных DNS-запросов. При такой атаке используются особенности работы рекурсивных DNS-запросов. В рекурсивных DNS-запросах, когда DNS-клиент делает запрос с именем, которое отсутствует в кэш-памяти DNS-сервера, сервер отправляет повторяющиеся запросы другим DNS-серверам до тех пор, пока нужный ответ не будет отправлен клиенту. Воспользовавшись особенностями данного процесса, злоумышленник отправляет рекурсивные запросы с использованием фальшивых имен, которые, как он знает, не существует в кэш-памяти сервера. Чтобы разрешить такие запросы, DNS-сервер должен обработать каждую запись, временно сохраняя ее, и отправить запрос другому DNS-серверу, затем дождаться ответа. Другими словами, потребляется все большее количество вычислительных ресурсов (процессора, памяти и пропускной способности), до тех пор, пока ресурсы не заканчиваются. Есть и другие атаки на DNS вроде man-inthe-middle и так далее, но в итоге все сценарии сводятся к двум возможным последствиям – недоступность сервиса или выдача пользователю ложной информации. Универсального решения против DDOS-атаки на любой сервис нет, DNS здесь не является исключением. Хотя у DNS есть одно существенное преимущество – иерархическая структура, при которой информация не хранится в одном месте, а на многочисленных серверах и запрашивается по мере необходимости. Обращение к серверам верхнего уровня происходит только при отсутствии информации в текущем DNS-сервере. Кэширование DNS-данных приводит к уменьшению числа запросов. В итоге, чтобы DDOS-атака действительно была эффективной, необходимо, чтобы она затронула максимальное количество серверов, в том числе 13 корневых, и действовала в течение продолжительного времени. А это далеко не так просто реализовать. Все реализации атак основываются на том, что протокол не предоставляет клиенту никакой возможности проверки подлинности полученной информации. В итоге клиент вынужден «доверять» любому ответу, полученному от DNS-сервера. При DNS-запросах обычно используется протокол UDP, что упрощает подделку ответа сервера, так как при этом не устанавливается виртуальный канал. Кроме этого, злоумышленнику не нужно атаковать все DNS-серверы, достаточно взять на прицел только один. В итоге пользователь, набравший адрес требуемого ресурса, попадает на подставной сайт, где он может раскрыть свои пароли или другую информацию. Особо нужно отметить, что уязвимым в этом случае является именно протокол, а не программы, его реализующие. Поэтому и проблему можно решить, только изменив подход к получению адреса клиентом. В общем случае, ресурс находится в состоянии защищенности, если выполняются его доступность, целостность, конфиденциальность. Доступность – гарантия того, что авторизованные пользователи получат доступ к нужной им информации. Целостность – гарантия сохранности и достоверности данных, обеспечивается за счет того, что неавторизованные пользователи никак не могут изменять, модифицировать, подменять или создавать данные. Конфиденциальность –гарантия того, что доступ к данным имеют только авторизованные пользователи, или легальные пользователи. Требования безопасности могут варьироваться в зависимости от типа хранимых данных, характера информационной системы и типа возможных угроз. При планировании и разработке защиты необходимо учесть ряд особенностей атак, производимых именно на DNS-серверы: Ведется атака на критически важную инфраструктуру - DNS-сервер является важным элементом инфраструктуры. Это означает, что, если нарушается работа DNS-сервиса организации, отключается весь ее интернет-трафик. Асимметричный характер атаки - асимметричное усиление позволяет атакам на DNS вызвать отказ в обслуживании, пользуясь ограниченными ресурсами и небольшим трафиком. Сохранение анонимности - не использующий информацию о состоянии протокол DNS позволяет злоумышленникам изменить их IP-адрес источника и легко замаскироваться. В связи с этим, разрабатывают различные методы для борьбы с атаками на DNS-сервер: шифровка данных, фильтрация IP-пакетов, использование случайных UDP-портови так далее. Расширение DNSSEC Расширение к протоколу DNS – DNSSEC (DNS Security Extensions), разработанное одноименной группой, не может защитить от самой атаки, направленной на подмену адреса, но дает возможность обнаружить такую попытку и отклонить неправильные данные, обезопасив тем самым клиента. Самое главное – DNSSEC не является заменой DNS. Задачей разработчиков было создать такой протокол, внедрение которого не требовало бы изменений существующей системы и обеспечивало бы совместимость клиентов, поддерживающих и не поддерживающих расширение. Поэтому DNSSEC можно разворачивать постепенно, добавляя новые возможности к уже существующей службе DNS. Работа по улучшению DNS велась давно, первые упоминания об этом датированы еще январем 1997 года в RFC 2065 (через 10 лет после принятия RFC 1034), в котором были предложены два дополнительных поля DNS Security (DNSSEC, так раньше расшифровывалась аббревиатура). Затем в последующих RFC эта идея развивалась и уточнялась. Эксперименты по развертыванию DNSSEC по RFC 2535 показали, что имеется много нюансов, в основном в процедуре распространения ключевых данных, что в итоге привело к появлению доработок, названных – RFC 2535bis или DNSSECbis. Сегодня актуальными/базовыми являются доработки: RFC 4033 – DNS Security Introduction and Requirements –введение и общие условия; RFC 4034 – Resource Records for the DNS Security Extensions – описания расширений в ресурсных записях DNS; RFC 4035 – Protocol Modifications for the DNS Security Extensions – изменения в протоколе DNS. Эти RFC заменили более ранние, в том числе и RFC 2535, которые считаются уже устаревшими. Сами разработчики называют для технологии DNSSEC переломным 2004 год, когда на новые расширения обратили внимание в группепо, которая следит за процессом стандартизации в Интернете. Основная идея DNSSEC – проверка подлинности полученных данных при помощи цифровой подписи, для чего задействуется механизм шифрования с открытыми ключами. Для этого администратор доменной зоны подписывает информацию о соответствии имен и IP-адресов, используя свой закрытый ключ. Клиент (Security-Aware Resolver) вместе с адресом получает подписанную адресную информацию, которую он может проверить, используя открытый ключ администратора. Соответственно, если данные в полученном сообщении не соответствуют подписи, они отбрасываются. Механизм подтверждения применяются только к данным по зоне и при подтверждении отсутствия DNS записей, но не предназначен для защиты таких операций, как перенос зон и динамические обновления. В механизме с открытыми ключами есть слабое место – необходимо точно знать, что открытый ключ принадлежит именно тому субъекту, который нас интересует, в нашем случае клиент, получивший подписанный ответ, должен доверять открытому ключу. И только тогда он может быть уверен, что полученная DNS-запись принадлежит именно ответственному серверу. В DNSSEC эту проблему решают за счет построения цепочек доверия. В этом случае полностью задействуют имеющуюся иерархическую структуру, когда администратор верхнего уровня выступает гарантом, удостоверяющим подпись доменов, находящихся уровнем ниже. В результате клиент, получающий адрес, последовательно может проследить цепочку доверия к открытому ключу, начиная от самого верхнего сервера root/TLD к серверу, отвечающему за конкретную зону. Очевидно, что данный подход требует поддержки DNSSEC в корневых серверах или хотя бы в TLD (top-level domain). Ведь при использовании DNSSEC в root-серверах клиенту потребуется знание единственного ключа для подтверждения любых (в идеале) данных. Иначе потребуется импортировать ключ для каждой зоны или отдельного домена. В отсутствии поддержки DNSSEC корневой зоны и TLD допускается участие в подтверждении ключа третьей стороны (look-aside). Это может быть необходимо при построении «островка безопасности» (в RFC – Island of Security), то есть автономно работающего DNS-сервера, поддерживающего DNSSEC и не завязанного на TLD (в котором не реализован DNSSEC) или другие серверы верхнего уровня. Чтобы упростить процедуру, было принято решение развернуть отдельную инфраструктуру, обеспечивающую централизованное хранение публичных ключей зон, и подтверждать любые зоны, не являющиеся дочерними. Такая структура описана в RFC 4431 и 5074, она получила название DLV (DNSSEC Lookaside Validation). Сейчас централизованная база поддерживается организацией ISC, хотя DLV может быть развернута на любом DNS-сервере. Кстати, наличие открытых ключей в DNS-записях позволяет использовать их и для других операций – SSH, электронная почта и тому подобное. DNSSEC не защищает данные, так как в этом нет смысла, они должны быть открыты, но затрудняет их подделку. Также не следует считать эту схему панацеей, всегда есть вероятность того, что злоумышленнику удастся не только подделать адресную информацию, но и подменить подписи, выдав свой ключ за ключ администратора зоны. Хотя в случае DNSSEC подменить адрес на порядок сложнее. DNSSEC предполагает подписывать не каждую отдельную запись, а все множество ресурсных записей (RRSet). Его внедрение потребовало внесения некоторых изменений в DNS-протокол, в частности в ресурсные DNS-записи: RRSIG (Resource Record Signature) – цифровая подпись и связанная с ней информация (интервал времени, алгоритм, тег для определения связанного DNSKEY и т.д.); DNSKEY (DNS Public Key) – открытый ключ, который используется клиентом для проверки подписи; DS (Delegation Signer) – необязательное поле используется в тех случаях, когда необходимо разрешить проверку подлинности открытых ключей дочерних зон для организации цепочки доверия; DLV – похоже на предыдущий, но разрешает проверку подлинности для любых зон, в ней описанных; NSEC (Next Secure) – перечисление типов ресурсных записей, существующих в данном домене. Детально они рассмотрены в RFC 4034. Так, поле DNSKEY содержит кроме самого ключа еще три записи – флаг (16 позиций, установленный в «1» 7-й бит означает, что запись содержит ключ DNS-зоны), протокол (только значение 3) и алгоритм. |