Из Википедии, свободной энциклопедии
  (Перенаправлено из-за отравления DNS )
Перейти к навигации Перейти к поиску

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

Обзор системы доменных имен [ править ]

Основная статья: Система доменных имен

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

Когда DNS-сервер получил ложный перевод и кэширует его для оптимизации производительности, он считается отравленным и передает ложные данные клиентам. Если DNS-сервер заражен, он может вернуть неверный IP-адрес, перенаправляя трафик на другой компьютер (часто злоумышленник). [1]

Атаки с отравлением кеша [ править ]

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

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

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

Варианты [ править ]

В следующих вариантах записи для сервера ns.target .example будут отравлены и перенаправлены на сервер имен злоумышленника по IP-адресу wxyz . Эти атаки предполагают, что сервер имен для target.example - ns.target.example . [ необходима цитата ]

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

Перенаправить сервер имен целевого домена [ править ]

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

Запрос DNS-сервера: какие записи адресов для subdomain.attacker.example ?

subdomain.attacker.example. В

Ответ злоумышленника:

Отвечать:(нет ответа)Раздел полномочий:атакующий. пример. 3600 IN NS ns.target.example.Дополнительный раздел:ns.target.example. IN A wxyz

Уязвимый сервер кэширует дополнительную A-запись (IP-адрес) для ns.target.example , позволяя злоумышленнику разрешать запросы ко всему домену target.example .

Перенаправить запись NS в другой целевой домен [ править ]

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

Запрос DNS-сервера: какие записи адресов для subdomain.attacker.example ?

subdomain.attacker.example. В

Ответ злоумышленника:

Отвечать:(нет ответа)Раздел полномочий:target.example. 3600 IN NS ns.attacker.example.Дополнительный раздел:ns.attacker.example. IN A wxyz

Уязвимый сервер кэширует несвязанную информацию о полномочиях для NS-записи target.example (запись сервера имен), позволяя злоумышленнику разрешать запросы ко всему домену target.example .

Предотвращение и смягчение последствий [ править ]

Многие атаки с отравлением кеша против DNS-серверов можно предотвратить, если меньше доверять информации, передаваемой им другими DNS-серверами, и игнорировать любые переданные DNS-записи, которые не имеют прямого отношения к запросу. Например, версии BIND 9.5.0-P1 [3] и выше выполняют эти проверки. [4] Рандомизация исходного порта для запросов DNS, в сочетании с использованием криптографически безопасных случайных чисел для выбора как исходного порта, так и 16-битного криптографического одноразового номера , может значительно снизить вероятность успешных атак на основе гонки DNS.

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

Безопасный DNS ( DNSSEC ) использует криптографические цифровые подписи, подписанные доверенным сертификатом открытого ключа, для определения подлинности данных. DNSSEC может противостоять атакам отравления кеша. В 2010 году DNSSEC был реализован на серверах корневой зоны Интернета [5], но его также необходимо развернуть на всех серверах домена верхнего уровня . Их готовность к DNSSEC отображается в списке доменов верхнего уровня в Интернете . По состоянию на 2020 год все исходные TLD поддерживают DNSSEC, как и TLD с кодом страны в большинстве крупных стран, но многие TLD с кодом страны по-прежнему не поддерживают.

Атаки этого типа можно смягчить на транспортном или прикладном уровне , выполнив сквозную проверку после установления соединения. Типичным примером этого является использование безопасности транспортного уровня и цифровых подписей . Например, используя HTTPS (безопасная версия HTTP ), пользователи могут проверить, действителен ли цифровой сертификат сервера и принадлежит ли он предполагаемому владельцу веб-сайта. Точно так же безопасная оболочкапрограмма удаленного входа в систему проверяет цифровые сертификаты на конечных точках (если они известны) перед продолжением сеанса. Для приложений, которые загружают обновления автоматически, приложение может встроить копию сертификата подписи локально и проверить подпись, хранящуюся в обновлении программного обеспечения, по встроенному сертификату. [ необходима цитата ]

См. Также [ править ]

  • Перехват DNS
  • Повторная привязка DNS
  • Mausezahn
  • Фарминг
  • Корневой сервер имен
  • Дэн Камински

Ссылки [ править ]

  1. ^ Сын, Суэл; Шматиков, Виталий. «Автостопом по отравлению DNS-кеша» (PDF) . Корнельский университет . Архивировано 14 августа 2017 года (PDF) . Проверено 3 апреля 2017 года .
  2. Перейти ↑ Storms, Andrew (2006). «Не доверяйте методологии распространения программного обеспечения вашего поставщика». Безопасность информационных систем . 14 (6): 38–43 - через ProQuest Central.
  3. ^ «Матрица безопасности BIND» . ISC Bind . Архивировано из оригинального 11 ноября 2011 года . Проверено 11 мая 2011 года .
  4. ^ "Безопасность привязки ISC" . ISC Bind . Архивировано из оригинального 11 ноября 2011 года . Проверено 11 мая 2011 года .
  5. ^ "Корневой DNSSEC" . ICANN / Verisign. п. 1. Архивировано 10 сентября 2017 года . Проверено 5 января 2012 года .