Курс лекций «Проблемы безопасности в информационных технологиях»



жүктеу 4.51 Mb.
бет30/44
Дата13.09.2017
өлшемі4.51 Mb.
түріКурс лекций
1   ...   26   27   28   29   30   31   32   33   ...   44

Проблемы протокола DNS


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

DNS (Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись), получения имени по известному IP-адресу (обратный запрос).

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

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

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

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

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

Межсегментная атака на DNS-сервер выглядит следующим образом. Предположим для определенности, что целью атаки является «подмена» IP-адреса web-сервера www.coolsite.com на IP-адрес сервера www.badsite.com для пользователей некоторой подсети, которую обслуживает DNS-сервер ns.victim.com. В первой фазе атаки ns.victim.com провоцируется на поиск информации об IP-адресе www.coolsite.com путем посылки ему соответствующего рекурсивного запроса. Во второй фазе атакующий посылает серверу ns.victim.com ложный ответ от имени ns.coolsite.com, который является ответственным за домен (зону) coolsite.com. В ложном ответе вместо реального IP-адреса www.coolsite.com указывается IP-адрес www.badsite.com. Сервер ns.victim.com кэширует полученную информацию, в результате чего в течении определенного промежутка времени (величина этого промежутка указывается в поле TTL ложного ответа и может произвольно выбираться атакующим) ничего не подозревающие пользователи вместо сервера www.coolsite.com попадают на www.badsite.com.

Для того, чтобы ложный ответ был воспринят сервером ns.victim.com как истинный, достаточно выполнения четырёх условий:


  • IP адрес отправителя ответа должен соответствовать IP-адресу запрашиваемого сервера (в нашем случае ns.coolsite.com);

  • UDP-порт, на который направляется ответ, должен совпадать с портом, с которого был послан запрос;

  • идентификатор ответа должен совпадать с идентификатором запроса;

  • ответ должен содержать запрашиваемую информацию (в нашем случае IP-адрес web-сервера www.coolsite.com).

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

Когда-то большинство DNS-серверов (BIND, MS DNS) использовали для исходящих запросов 53 порт, так что можно было «на удачу» послать ложный ответ на этот порт. Однако данный метод будет срабатывать не всегда, поскольку, например, BIND8 и новее может использовать для исходящих запросов любой случайно выбранный непривилегированный порт2.

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

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

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

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

DNS-сервер транслирует доменное имя (такое, как example.com) в IP-адрес, используемый хостами для соединения с ресурсами Интернета. Если DNS-сервер отравлен, он может возвращать некорректный IP-адрес, направляя таким образом клиента на другой компьютер.

В демонстрационном примере было показано, как пользователь, имеющий доступ к DNS серверу осуществляющему рекурсивные запросы, может подменить IP адрес для заданного хоста, отправив порядка 7000 фиктивных запросов и одновременно 140 тысяч фиктивных ответов. Общее время, необходимое для осуществления успешной атаки на сервер с BIND 9.4.2 составляет 1-2 минуты (Дэн Каминский ранее заявлял, что его метод реализует атаку за считанные секунды).

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

В случае DNS-сервера особых проблем у атакующего не возникает – он просто посылает серверу легитимные запросы, получая ответы с TXID в заголовке. Зная алгоритм, используемый для рандомизации (а он известен с точностью до системы, версию которой определить не так уж и сложно), можно достаточно легко угадать нужный TXID, простым перебором3.

Установка свежих заплаток на DNS-сервера однозначно полностью не решает проблему, угроза атаки слишком велика, чтобы позволить себе её игнорировать. Небольшие ISP и офисные сервера достаточно легко перевести на «DNS over TCP», который, в отличие от классического «DNS over UDP», практически не подвержен атакам данного типа. Также можно упомянуть новую технологию DNSSEC.

Однако все эти решения работают лишь на узлах с небольшой нагрузкой. Самое простое – использовать DNS-сервер PowerDNS. Он действительно намного более надёжен, да и работает быстрее стандартного BIND 9.

Многие атаки на кеш могут быть предотвращены на стороне DNS-серверов с помощью уменьшения степени доверия к информации, приходящей от других DNS-серверов, или даже игнорирования любых DNS-записей, прямо не относящихся к запросам. Например, последние версии BIND (версии 9, 10) выполняют такие проверки. Существенно снизить вероятность успешной атаки на кеш может использование случайных UDP-портов для выполнения DNS-запросов4.

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

Безопасный DNS (DNSSEC) использует электронную цифровую подпись с построением цепочки доверия для определения целостности данных. Применение DNSSEC может свести результативность атак на кеш к нулю. В 2011 году внедрение DNSSEC идет уже довольно быстрыми темпами (большинство доменных зон gTLD: .com, .net, .org – уже подписаны DNSSEC). Начиная с июля 2010 года все корневые серверы DNS содержат корневую зону DNS, подписанную при помощи стандартов DNSSEC.

Атакам на кеш также можно противопоставить транспортный уровень либо уровень приложений модели OSI, так как и на этих уровнях могут быть использованы цифровые подписи. К примеру, в безопасной версии HTTP — HTTPS — пользователь может проверить, имеет ли сервер, с которым он соединился, сертификат ЭЦП и кому этот сертификат принадлежит. Похожий уровень безопасности имеет SSL, когда программа-клиент проверяет ЭЦП удаленного сервера при установке соединения. Соединение с помощью IPSес не установится, если клиентом и сервером не будут предъявлены заранее известные ключи. Приложения, которые загружают свои обновления автоматически, могут иметь встроенную копию сертификата ЭЦП и проверять подлинность обновлений с помощью сравнения ЭЦП сервера обновлений со встроенным сертификатом.




Достарыңызбен бөлісу:
1   ...   26   27   28   29   30   31   32   33   ...   44


©kzref.org 2019
әкімшілігінің қараңыз

    Басты бет