ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 03.02.2024
Просмотров: 15
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
реализации атак основываются на том, что протокол не предоставляет клиенту никакой возможности проверки подлинности полученной информации. В итоге клиент вынужден «доверять» любому ответу, полученному от DNS-сервера. При DNS-запросах обычно используется протокол UDP, что упрощает подделку ответа сервера, так как при этом не устанавливается виртуальный канал. Кроме этого, злоумышленнику не нужно атаковать все DNS-серверы, достаточно взять на прицел только один.
В итоге пользователь, набравший адрес требуемого ресурса, попадает на подставной сайт, где он может раскрыть свои пароли или другую информацию. Особо нужно отметить, что уязвимым в этом случае является именно протокол, а не программы, его реализующие. Поэтому и проблему можно решить, только изменив подход к получению адреса клиентом. В общем случае, ресурс находится в состоянии защищенности, если выполняются его доступность, целостность, конфиденциальность. Доступность – гарантия того, что авторизованные пользователи получат доступ к нужной им информации. Целостность – гарантия сохранности и достоверности данных, обеспечивается за счет того, что неавторизованные пользователи никак не могут изменять, модифицировать, подменять или создавать данные. Конфиденциальность –гарантия того, что доступ к данным имеют только авторизованные пользователи, или легальные пользователи. Требования безопасности могут варьироваться в зависимости от типа хранимых данных, характера информационной системы и типа возможных угроз. При планировании и разработке защиты необходимо учесть ряд особенностей атак, производимых именно на DNS-серверы:
В связи с этим, разрабатывают различные методы для борьбы с атаками на DNS-сервер: шифровка данных, фильтрация IP-пакетов, использование случайных UDP-портови так далее.
Расширение к протоколу 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 заменили более ранние, в том числе и 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-записи:
Детально они рассмотрены в RFC 4034. Так, поле DNSKEY содержит кроме самого ключа еще три записи – флаг (16 позиций, установленный в «1» 7-й бит означает, что запись содержит ключ DNS-зоны), протокол (только значение 3) и алгоритм.
В итоге пользователь, набравший адрес требуемого ресурса, попадает на подставной сайт, где он может раскрыть свои пароли или другую информацию. Особо нужно отметить, что уязвимым в этом случае является именно протокол, а не программы, его реализующие. Поэтому и проблему можно решить, только изменив подход к получению адреса клиентом. В общем случае, ресурс находится в состоянии защищенности, если выполняются его доступность, целостность, конфиденциальность. Доступность – гарантия того, что авторизованные пользователи получат доступ к нужной им информации. Целостность – гарантия сохранности и достоверности данных, обеспечивается за счет того, что неавторизованные пользователи никак не могут изменять, модифицировать, подменять или создавать данные. Конфиденциальность –гарантия того, что доступ к данным имеют только авторизованные пользователи, или легальные пользователи. Требования безопасности могут варьироваться в зависимости от типа хранимых данных, характера информационной системы и типа возможных угроз. При планировании и разработке защиты необходимо учесть ряд особенностей атак, производимых именно на 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) и алгоритм.