1. Введение
DNSSEC (DomainNameSystemSecurityExtensions)представляет собой группу спецификаций из InternetEngineeringTaskForce(IETF), которые обеспечивают проверку подлинности происхождения DNS (DomainNameSystem)данных, отрицание существованияданных при проверке их подлинности и целостности (необеспечивает доступность и конфиденциальность данных).
Целью DNSSEC является защита DNS посредствомиспользования цифровых подписей. DNSSEC по сутипредставляет собой собрание новых компонентов, добавленных во взаимодействие между клиентом и сервером DNS, которое поможет повысить безопасностьосновных протоколов DNS.
Корректное функционирование DNS является критически важным для сети предприятия, подсоединеннойк Интернету, и для Интернета в целом. Действительно,если злоумышленнику удастся сделать так, чтобы атакуемый хост получил из DNS сфальсифицированнуюинформацию, то хост будет отправлять данные на подложный IP-адрес (InternetProtocol). В лучшем случаерезультатом будет отказ в обслуживании, в худшем —злоумышленник получит возможность перехвата трафикасо всеми вытекающими последствиями.
Принцип работы DNSSEC можно сравнить с цифровой подписью. Используется два типа ключей, закрытымключом данные подписываются, а открытым сверяются.Но главное отличие в том, что — одним подписываетсязона (ZSK, zonesigningkey), другим подписывается наборключей (KSK, keysigningkey). Сделано это из следующихсоображений: зона может быть достаточно большой,чтобы удалось подобрать закрытый ключ ZSK, поэтомуего необходимо чаще менять, и можно сделать его менеедлинным, чтобы зоны подписывались быстрее; открытый ключ KSK используется для небольших объемовданных, поэтому его можно сделать длиннее и режеизменять. Тем более, что хэш от открытой части KSKтребуется отправить в родительскую зону, что слишкомчасто делать не целесообразно.
Вся информация о защищенном домене в системеDNSSEC определенным образом зашифрована, поэтомуможет быть изменена только при помощи закрытого ключа шифрования. В процессе защищенного делегирования домена генерируется пара ключей. Информация о ключах хранится на первичном DNS-сервере.Закрытый ключ используется для подписи зоны после каждого изменения. Цифровая подпись закрытогоключа (DS-запись) передается администратору родительской зоны и подписывается его закрытым ключом.Таким образом, организуется цепочка доверия. Знаяоткрытый ключ администратора родительской зоны,можно проверить «валидность» открытого ключа любойиз дочерних зон.
Каждый узел в дереве DNS связан с некоторым открытым ключом. Каждое сообщение от DNS-серверовподписывается под соответствующим закрытым ключом.Эти ключи используются для генерации сертификатовили подписей, которые сохраняют идентификационныеданные о каждом домене верхнего уровня на соответствующий открытый ключ.
Такие криптографические подписи обеспечиваютцелостность за счет вычисления криптографическогохэша (т. е. уникальной контрольной суммы) данныхи, затем, защиты вычисленной величины от несанкционированных изменений посредством ее шифрования.Хэш шифруется с помощью личного ключа из парыключей, чтобы любой желающий мог воспользоватьсяоткрытым ключом для его дешифровки. Если дешифрованное получателем значение хэша совпадает с вы-численным, то данные достоверны (не подвергалисьнесанкционированному изменению).
Цифровые подписи хранятся в зоне DNS в новыхзаписях ресурсов RRSIG (подпись записи ресурса). Когдасопоставитель выдает запрос на имя, в ответе возвращаются одна или несколько RRSIG-записей. Для проверкиподписи используется открытый криптографическийключ, который хранится в DNSKEY-записи ресурса.В ходе проверки DNS-сервер извлекает DNSKEY-запись.
KSK означает ключ подписи ключа (ключ долговременного пользования), а ZSK означает ключ подписизоны (ключ кратковременного пользования).
В случае асимметричной криптографии или шифрования с открытым ключом, используемой в DNSSEC,атакующему необходимо определить, посредством прямого перебора или других методов, закрытую половину в паре открытый-закрытый ключ, используемойдля создания подписи, подтверждающей достоверностьDNS-записи. Это позволит ему обойти защиту DNSSEC.DNSSEC предотвращает эти попытки взлома, используяключ кратковременного пользования — ключ подписизоны (ZSK) — для регулярного вычисления подписейDNS-записей и ключ долговременного пользования —ключ подписи ключа (KSK) — для вычисления подписи ZSK, дающей возможность проверки. Ключ ZSKчасто изменяется, чтобы атакующему было тяжелее «угадать» его, в то время, как более длинный ключ KSKизменяется гораздо реже (лучше всего — раз в год).Так как ключ KSK подписывает ключ ZSK, которыйподписывает DNS-записи, для проверки DNS-записив зоне необходимо знать только ключ KSK. Ключ KSKв форме записи DelegationSigner (DS) передается вышепо дереву записей — родительской зоне. Родительскаязона (например, корень) подписывает дочернюю записьDS (например, .org) своим ключом ZSK, который подписывается своим ключом KSK.
Это значит, что если DNSSEC полностью принялаключ KSK для корневой зоны, то она становится частьюцепочки проверки для каждого проверяемого доменногоимени DNSSEC (или разрабатываемого приложения).
2. Уязвимости DNS
DNS-протокол может работать как поверх TCP (TransmissionControlProtocol),так и поверх UDP (UserDatagramProtocol),причем в 99 % случаев используетсяименно UDP — как более быстрый, менее ресурсоемкий,но, в тоже время, и менее защищенный. Чтобы послатьподложный пакет, который будет воспринят жертвойкак правильный, достаточно угадать (подобрать) идентификатор последовательности и номер порта-отправителя.
В простейшем случае злоумышленник может отправить подложный DNS-ответ с подложным IP-адресомнекоторого узла, на который жертва пытается зайти.Сложность реализации атак подобного рода в том, чторабочие станции кэшируют DNS запросы. Более того,система не принимает DNS-ответов, которые не запрашивались. Хакер должен дождаться момента, когда жертвапошлет DNS-запрос, и сгенерировать подложный ответпрежде, чем это сделает настоящий DNS-сервер. Насамом деле, обе проблемы имеют решение. DNS-кэшобычно невелик, а потому, послав жертве HTML-письмос кучей картинок, лежащих на внешних серверах с разными доменными именами, хакер может вытеснить изкэша все старые записи. После чего, последняя ссылкав письме, ведущая на сервер обновлений, гарантированнопошлет обозначенный запрос в Сеть. Предшествующаяей ссылка на Web-сервер, подконтрольная хакеру, подскажет точное время, когда следует начинать генерациюподложных пакетов. Если хотя бы один из них будетвоспринят как правильный, в DNS-кэш попадет «левый»адрес сервера с обновлениями, имеющий все шансы«дожить» до очередной сессии обновлений.Атаки на DNS можно условно разделить на два вида:
— Пассивные — атакующий получает необходимуюинформацию без заметного влияния на систему; система при этом продолжает функционировать какпрежде.
— Активные — атакующий реализует некотороевоздействие на систему, в результате которого изменяется ее поведение. Такое изменение может бытьи неопределимым для атакуемой системы, но криптоаналитик в состоянии определить и использоватьэту информацию.
3. Реализация атак на DNS
Тестовая среда представляет собой два сервера с развернутой операционной системой WindowsServer 2008R2и клиентским ПК на базе WindowsXP. Тестированиезащиты DNS сервера проводится путем организацииразного рода атак при стандартной защите DNS сервера и при дополнительно развернутой системе защиты DNSSEC.
3.1. Пример 1. Организация MITM-атак с помощью«dsniff». Служба DNS использует простые UDP-пакеты,обмен которыми происходит через порт 53. Так какUDP является протоколом, не ориентированным наустановление соединений, то можно подменить информацию его пакетов.
В состав пакета «dsniff» (http://www.monkey.org/~dugsong/dsniff), входит средство под названием «dnsspoof». Эта программа содержит в себе простой анализатор пакетов, который отслеживает запросы DNSотносительно информации записей «А» или «PTR». При использовании параметра -f, запушенная на компьютере хакера программа «dnsspoof» будет выполнятьчтение локального файла, который записан в стандарт-ном формате /etc/hosts, и будет отвечать на все перехваченные «А» или «PTR» DNS-запросы.
testb$ host www.victim.com
www.victim.com has address 192.168.1.25
c rackerbox# cat /ete/dnssnifff.hosts
crackerbox# dnssniff -f /etc/dnssniff.hosts
testb$ host www.victim.com
www.victim.com has address 192.168.1.3
Если параметр -f не указан, ответом на все «А»и «PTR» запросы DNS будет IP-адрес или имя хоста,на котором запущена «dnsspoof». Это приведет к тому,что все запросы на поиск IP-адресов будут проходитьчерез хост нарушителя, т. е. можно выполнять перехваттрафика, маршрутизацию или изменение данных, ещедо того, как они попадут по действительному адресуназначения.
Суть атаки заключается в том, что если пакет от«dnsspoof» поступит раньше, чем пакет от реальногоDNS-сервера, то предпочтение получит первый, фальшивый пакет, а действительный ответ будет отброшен.Поэтому успех работы программы «dnsspoof» зависитот скорости передачи пакета запросившему узлу. Таккак «dnsspoof» не нуждается в выполнении поиска действительной информации по запросу, то вероятнее всего,что ее пакет поступит первым.
3.2. Пример 2. DNShijacking. Данная атака также частоиспользуется для изменения принципа работы системDNS. В данном случае не вносится никаких измененийв кэш DNS клиента, но производятся изменения в настройках, после которых все запросы разрешения именадресуются личному DNS-серверу взломщика. Обычноданная атака ставит своей целью не похищение данных, а сбор статистической информации с компьютераклиента. Все запросы разрешения имен, отправляемые серверу взломщика, выполняются корректно, но приэтом взломщик получает информацию о сайтах, посещаемых клиентом.
Пакет для проведения атаки «DNSHijacker» представляет собой сочетание sniffer& DNS spoofed.Рассмотрим пример проведения атаки.
1. Злоумышленник запускает набор для проведенияатаки «DNSHijacker».
./dnshijacker —i eth0 —v —f ftable
2. Злоумышленник прослушивает DNS запросы исходящие от жертвы к DNS серверу.
3. Жертва отправляет запрос DNS серверу на получение адреса www.ххххх.com.
13:59:20.042628 192.168.1.2732839 > 192.168.1.60.
domain: [udp sum ok] 24959+ A? www.ххххх.com [|domain](DF) (ttl 64, id 30800, len 61)
Запрос содержит в себе следующие части:
1. 192.168.1.27: адресWeb-сайта.
2. 192.168.1.60: IP адрес внутреннего DNS.
3. 24949
NSID запроса отправленного жертвой навнутренний DNS.
4. (DF): Флаг.
5. Time to live64.
6. IPID 30800.
7. length61.
Внутренний DNS сервер пытается обработать ответ, не находя запроса в свой базе, он посылает запроск вышестоящему DNS-серверу.
4. «Dnshijackertool» отправляет ответ с подмененнойинформацией об IP адресе DNS сервера и IP-адресезапрашиваемого ресурса, до того как внутренний DNSсервер получит ответ.Результатом данной атаки является перенаправлениежертвы на подделанный веб-ресурс.
3.3. Пример 3. Подмена DNS ID (DNS ID Spoofing).Заголовок пакета DNS-протокола содержит идентификационное поле для соответствия запросов и ответов.Целью подмены DNS ID является посылка своего ответа на DNS-запрос до того, как ответит настоящийDNS-сервер. ID — это единственный способ различитьразличные запросы DNS. Серверы DNS используют ID,чтобы определить каков был первоначальный запрос.Для выполнения этого, нужно спрогнозировать идентификатор запроса. Локально это реализуется простымпрослушиванием сетевого трафика, но удаленно выполнить эту задачу можно путем проверки всех доступныхзначений идентификационного поля (общее количествовозможных значений составляет 65535), или же посылкой нескольких сотен DNS-запросов в правильномпорядке. Очевидно, что этот метод не очень надежен.Еще одной задачей для злоумышленника является то,что он должен иметь возможность прослушивать пакеты,идущие от произвольного DNS, для чего злоумышленникдолжен контролировать DNS-сервер, который являетсяавторитетным для этой зоны.
Для этого типа атаки будет использован пакет «ADMIDtools,который обычно используется для тестирования уровня защиты DNS.
Утилита «ADMkill» прослушивает ответы, отправляемые DNS сервером, и отсылает неверные ответы с подделанным IP-адресом уполномоченного сервера имен.
Для проведения атаки, нужно угадать DNSID. Инструмент «dnshijackertool» может быть использован дляпрослушивания DNS трафика, после чего злоумышленник может оценить диапазон ID для запросов сервераимен. Атакующий должен выполнить следующиедействия:
1. Злоумышленник посылает DNS-запрос на разрешение имени www.test.com целевому серверуns.dnstest.com.
2. Целевой DNS-сервер перенаправляет полученныйзапрос к серверу доменаns.test.com.
3. Злоумышленник прослушивает запросы, получаемые ns.test.com и определяет ID.
4. Злоумышленник посылает DNS-запрос на разрешение имени www.victim.com серверу ns.dnstest.com.И сразу же шлет группу фальсифицированных DNS-ответов (передавая в качестве IP-адреса, один из адресовзлоумышленника — 10.0.0.1) на свой же запрос с подмененным IP-адресом источника на адрес одного из DNS-серверов victim.com. В каждом ответе ID увеличиваетсяна 1 по сравнению с идентификатором, полученнымво время второго этапа атаки, для увеличения вероятности нахождения правильного номера ID. Сервер ns.dnstest.com мог ответить на запросы других клиентови, соответственно, увеличить свой DNS ID. Для этогоможет быть использована утилита «ADMkill», котораябудет отсылать серию подделанных ответов с IP-адресомс заданным диапазоном ID (т.е. мы отсылаем пакетыс ID от 27300 до 27330):
# ./ADMkillDNS 10.0.0.1 192.168.1.60 ns2.victim.com27300 27330
В результате такой атаки по подложным IP-адресамбудет ходить не отдельный клиент-жертва, а все пользователи будут обращаться к машине злоумышленника.
4. DNSSEC и нагрузка на сеть
Как уже упоминалось выше, в основе протоколаDNSSEC лежит метод цифровой подписи ответов назапросы, в результате чего пакеты DNSSEC несут больше информации, что увеличивает нагрузку на память,процессор и полосу пропускания сервера. ВнедрениеDNSSEC увеличивает объем передаваемых данных, засчет использования цифровой подписи. Для того, чтобыэто проверить, были прослушаны запросы отправляемыепользователями. Проанализаровав их можно однозначносделать вывод, что объем трафика увеличивается приразвернутом DNSSEC почти на 20 %. Также следуетзнать, что если пакет превысит 512 байт, то могут воз-никнуть проблемы с его приемом. Конечно, у этой проблемы есть решение. Согласно протоколу DNS клиентдолжен сообщить об этом серверу, который, в своюочередь, постарается уместить ответ в установленные512 байт. При этом часть информативных данных может быть обрезана. В случае, если даже необходимаяинформация не помещается, сервер сообщит об этомклиенту установкой бита «обрезания» (truncationbit).Однако, сжатие не безгранично, и если после него размер пакета все еще большой, то клиент автоматически переключится из транспортного протокола UDP в TCP,в котором нет подобных ограничений. Некоторыемаршрутизаторы или устройства безопасности могутработать на правиле об ограничении пакета в 512 байт,что в свою очередь требует переконфигурации.
5. Выводы
В этой статье были исследованы и реализованы атакина сервер имен, в результате чего было выяснено, чтооригинальный DNS стандарт не заботится о безопасности. При проведении атак на сервер с развернутымDNSSEC методы, которые использовались при атакена «чистый» DNS, оказались безуспешными. Причинойэтого является то, что в основе протокола DNSSECлежит метод цифровой подписи ответов на запросы.В ходе анализа проведенных атак, было выяснено, чтоDNSSEC может бороться с таким уязвимостями DNSкак «отравление кэша» или «человек посередине». Этообъясняется тем, что DNSSEC защищает DNS путемпроверки подлинности и целостности системы DNS-сообщений. Атаки, ориентированые на DNS сообщения, невозможны при использовании DNSSEC, так какклиенты проверяют цифровую подпись предоставляемуюв ответ. Расширения безопасности DNS SecurityExtensionsзащищают клиентов и сервера от атак, при которых модифицируется кэш DNS, путем подписывания записис использованием шифрования с открытым ключом.
В ходе работы было выявлено, что внедрение DNSSECувеличивает объем передаваемых данных, нагрузку напамять, процессор и полосу пропускания сервера на20 %, что не является критичным, с учетом уровня осуществляемой безопасности.
DNSSEC (DomainNameSystemSecurityExtensions)представляет собой группу спецификаций из InternetEngineeringTaskForce(IETF), которые обеспечивают проверку подлинности происхождения DNS (DomainNameSystem)данных, отрицание существованияданных при проверке их подлинности и целостности (необеспечивает доступность и конфиденциальность данных).
Целью DNSSEC является защита DNS посредствомиспользования цифровых подписей. DNSSEC по сутипредставляет собой собрание новых компонентов, добавленных во взаимодействие между клиентом и сервером DNS, которое поможет повысить безопасностьосновных протоколов DNS.
Корректное функционирование DNS является критически важным для сети предприятия, подсоединеннойк Интернету, и для Интернета в целом. Действительно,если злоумышленнику удастся сделать так, чтобы атакуемый хост получил из DNS сфальсифицированнуюинформацию, то хост будет отправлять данные на подложный IP-адрес (InternetProtocol). В лучшем случаерезультатом будет отказ в обслуживании, в худшем —злоумышленник получит возможность перехвата трафикасо всеми вытекающими последствиями.
Принцип работы DNSSEC можно сравнить с цифровой подписью. Используется два типа ключей, закрытымключом данные подписываются, а открытым сверяются.Но главное отличие в том, что — одним подписываетсязона (ZSK, zonesigningkey), другим подписывается наборключей (KSK, keysigningkey). Сделано это из следующихсоображений: зона может быть достаточно большой,чтобы удалось подобрать закрытый ключ ZSK, поэтомуего необходимо чаще менять, и можно сделать его менеедлинным, чтобы зоны подписывались быстрее; открытый ключ KSK используется для небольших объемовданных, поэтому его можно сделать длиннее и режеизменять. Тем более, что хэш от открытой части KSKтребуется отправить в родительскую зону, что слишкомчасто делать не целесообразно.
Вся информация о защищенном домене в системеDNSSEC определенным образом зашифрована, поэтомуможет быть изменена только при помощи закрытого ключа шифрования. В процессе защищенного делегирования домена генерируется пара ключей. Информация о ключах хранится на первичном DNS-сервере.Закрытый ключ используется для подписи зоны после каждого изменения. Цифровая подпись закрытогоключа (DS-запись) передается администратору родительской зоны и подписывается его закрытым ключом.Таким образом, организуется цепочка доверия. Знаяоткрытый ключ администратора родительской зоны,можно проверить «валидность» открытого ключа любойиз дочерних зон.
Каждый узел в дереве DNS связан с некоторым открытым ключом. Каждое сообщение от DNS-серверовподписывается под соответствующим закрытым ключом.Эти ключи используются для генерации сертификатовили подписей, которые сохраняют идентификационныеданные о каждом домене верхнего уровня на соответствующий открытый ключ.
Такие криптографические подписи обеспечиваютцелостность за счет вычисления криптографическогохэша (т. е. уникальной контрольной суммы) данныхи, затем, защиты вычисленной величины от несанкционированных изменений посредством ее шифрования.Хэш шифруется с помощью личного ключа из парыключей, чтобы любой желающий мог воспользоватьсяоткрытым ключом для его дешифровки. Если дешифрованное получателем значение хэша совпадает с вы-численным, то данные достоверны (не подвергалисьнесанкционированному изменению).
Цифровые подписи хранятся в зоне DNS в новыхзаписях ресурсов RRSIG (подпись записи ресурса). Когдасопоставитель выдает запрос на имя, в ответе возвращаются одна или несколько RRSIG-записей. Для проверкиподписи используется открытый криптографическийключ, который хранится в DNSKEY-записи ресурса.В ходе проверки DNS-сервер извлекает DNSKEY-запись.
KSK означает ключ подписи ключа (ключ долговременного пользования), а ZSK означает ключ подписизоны (ключ кратковременного пользования).
В случае асимметричной криптографии или шифрования с открытым ключом, используемой в DNSSEC,атакующему необходимо определить, посредством прямого перебора или других методов, закрытую половину в паре открытый-закрытый ключ, используемойдля создания подписи, подтверждающей достоверностьDNS-записи. Это позволит ему обойти защиту DNSSEC.DNSSEC предотвращает эти попытки взлома, используяключ кратковременного пользования — ключ подписизоны (ZSK) — для регулярного вычисления подписейDNS-записей и ключ долговременного пользования —ключ подписи ключа (KSK) — для вычисления подписи ZSK, дающей возможность проверки. Ключ ZSKчасто изменяется, чтобы атакующему было тяжелее «угадать» его, в то время, как более длинный ключ KSKизменяется гораздо реже (лучше всего — раз в год).Так как ключ KSK подписывает ключ ZSK, которыйподписывает DNS-записи, для проверки DNS-записив зоне необходимо знать только ключ KSK. Ключ KSKв форме записи DelegationSigner (DS) передается вышепо дереву записей — родительской зоне. Родительскаязона (например, корень) подписывает дочернюю записьDS (например, .org) своим ключом ZSK, который подписывается своим ключом KSK.
Это значит, что если DNSSEC полностью принялаключ KSK для корневой зоны, то она становится частьюцепочки проверки для каждого проверяемого доменногоимени DNSSEC (или разрабатываемого приложения).
2. Уязвимости DNS
DNS-протокол может работать как поверх TCP (TransmissionControlProtocol),так и поверх UDP (UserDatagramProtocol),причем в 99 % случаев используетсяименно UDP — как более быстрый, менее ресурсоемкий,но, в тоже время, и менее защищенный. Чтобы послатьподложный пакет, который будет воспринят жертвойкак правильный, достаточно угадать (подобрать) идентификатор последовательности и номер порта-отправителя.
В простейшем случае злоумышленник может отправить подложный DNS-ответ с подложным IP-адресомнекоторого узла, на который жертва пытается зайти.Сложность реализации атак подобного рода в том, чторабочие станции кэшируют DNS запросы. Более того,система не принимает DNS-ответов, которые не запрашивались. Хакер должен дождаться момента, когда жертвапошлет DNS-запрос, и сгенерировать подложный ответпрежде, чем это сделает настоящий DNS-сервер. Насамом деле, обе проблемы имеют решение. DNS-кэшобычно невелик, а потому, послав жертве HTML-письмос кучей картинок, лежащих на внешних серверах с разными доменными именами, хакер может вытеснить изкэша все старые записи. После чего, последняя ссылкав письме, ведущая на сервер обновлений, гарантированнопошлет обозначенный запрос в Сеть. Предшествующаяей ссылка на Web-сервер, подконтрольная хакеру, подскажет точное время, когда следует начинать генерациюподложных пакетов. Если хотя бы один из них будетвоспринят как правильный, в DNS-кэш попадет «левый»адрес сервера с обновлениями, имеющий все шансы«дожить» до очередной сессии обновлений.Атаки на DNS можно условно разделить на два вида:
— Пассивные — атакующий получает необходимуюинформацию без заметного влияния на систему; система при этом продолжает функционировать какпрежде.
— Активные — атакующий реализует некотороевоздействие на систему, в результате которого изменяется ее поведение. Такое изменение может бытьи неопределимым для атакуемой системы, но криптоаналитик в состоянии определить и использоватьэту информацию.
3. Реализация атак на DNS
Тестовая среда представляет собой два сервера с развернутой операционной системой WindowsServer 2008R2и клиентским ПК на базе WindowsXP. Тестированиезащиты DNS сервера проводится путем организацииразного рода атак при стандартной защите DNS сервера и при дополнительно развернутой системе защиты DNSSEC.
3.1. Пример 1. Организация MITM-атак с помощью«dsniff». Служба DNS использует простые UDP-пакеты,обмен которыми происходит через порт 53. Так какUDP является протоколом, не ориентированным наустановление соединений, то можно подменить информацию его пакетов.
В состав пакета «dsniff» (http://www.monkey.org/~dugsong/dsniff), входит средство под названием «dnsspoof». Эта программа содержит в себе простой анализатор пакетов, который отслеживает запросы DNSотносительно информации записей «А» или «PTR». При использовании параметра -f, запушенная на компьютере хакера программа «dnsspoof» будет выполнятьчтение локального файла, который записан в стандарт-ном формате /etc/hosts, и будет отвечать на все перехваченные «А» или «PTR» DNS-запросы.
testb$ host www.victim.com
www.victim.com has address 192.168.1.25
c rackerbox# cat /ete/dnssnifff.hosts
crackerbox# dnssniff -f /etc/dnssniff.hosts
testb$ host www.victim.com
www.victim.com has address 192.168.1.3
Если параметр -f не указан, ответом на все «А»и «PTR» запросы DNS будет IP-адрес или имя хоста,на котором запущена «dnsspoof». Это приведет к тому,что все запросы на поиск IP-адресов будут проходитьчерез хост нарушителя, т. е. можно выполнять перехваттрафика, маршрутизацию или изменение данных, ещедо того, как они попадут по действительному адресуназначения.
Суть атаки заключается в том, что если пакет от«dnsspoof» поступит раньше, чем пакет от реальногоDNS-сервера, то предпочтение получит первый, фальшивый пакет, а действительный ответ будет отброшен.Поэтому успех работы программы «dnsspoof» зависитот скорости передачи пакета запросившему узлу. Таккак «dnsspoof» не нуждается в выполнении поиска действительной информации по запросу, то вероятнее всего,что ее пакет поступит первым.
3.2. Пример 2. DNShijacking. Данная атака также частоиспользуется для изменения принципа работы системDNS. В данном случае не вносится никаких измененийв кэш DNS клиента, но производятся изменения в настройках, после которых все запросы разрешения именадресуются личному DNS-серверу взломщика. Обычноданная атака ставит своей целью не похищение данных, а сбор статистической информации с компьютераклиента. Все запросы разрешения имен, отправляемые серверу взломщика, выполняются корректно, но приэтом взломщик получает информацию о сайтах, посещаемых клиентом.
Пакет для проведения атаки «DNSHijacker» представляет собой сочетание sniffer& DNS spoofed.Рассмотрим пример проведения атаки.
1. Злоумышленник запускает набор для проведенияатаки «DNSHijacker».
./dnshijacker —i eth0 —v —f ftable
2. Злоумышленник прослушивает DNS запросы исходящие от жертвы к DNS серверу.
3. Жертва отправляет запрос DNS серверу на получение адреса www.ххххх.com.
13:59:20.042628 192.168.1.2732839 > 192.168.1.60.
domain: [udp sum ok] 24959+ A? www.ххххх.com [|domain](DF) (ttl 64, id 30800, len 61)
Запрос содержит в себе следующие части:
1. 192.168.1.27: адресWeb-сайта.
2. 192.168.1.60: IP адрес внутреннего DNS.
3. 24949
NSID запроса отправленного жертвой навнутренний DNS.4. (DF): Флаг.
5. Time to live64.
6. IPID 30800.
7. length61.
Внутренний DNS сервер пытается обработать ответ, не находя запроса в свой базе, он посылает запроск вышестоящему DNS-серверу.
4. «Dnshijackertool» отправляет ответ с подмененнойинформацией об IP адресе DNS сервера и IP-адресезапрашиваемого ресурса, до того как внутренний DNSсервер получит ответ.Результатом данной атаки является перенаправлениежертвы на подделанный веб-ресурс.
3.3. Пример 3. Подмена DNS ID (DNS ID Spoofing).Заголовок пакета DNS-протокола содержит идентификационное поле для соответствия запросов и ответов.Целью подмены DNS ID является посылка своего ответа на DNS-запрос до того, как ответит настоящийDNS-сервер. ID — это единственный способ различитьразличные запросы DNS. Серверы DNS используют ID,чтобы определить каков был первоначальный запрос.Для выполнения этого, нужно спрогнозировать идентификатор запроса. Локально это реализуется простымпрослушиванием сетевого трафика, но удаленно выполнить эту задачу можно путем проверки всех доступныхзначений идентификационного поля (общее количествовозможных значений составляет 65535), или же посылкой нескольких сотен DNS-запросов в правильномпорядке. Очевидно, что этот метод не очень надежен.Еще одной задачей для злоумышленника является то,что он должен иметь возможность прослушивать пакеты,идущие от произвольного DNS, для чего злоумышленникдолжен контролировать DNS-сервер, который являетсяавторитетным для этой зоны.
Для этого типа атаки будет использован пакет «ADMIDtools,который обычно используется для тестирования уровня защиты DNS.
Утилита «ADMkill» прослушивает ответы, отправляемые DNS сервером, и отсылает неверные ответы с подделанным IP-адресом уполномоченного сервера имен.
Для проведения атаки, нужно угадать DNSID. Инструмент «dnshijackertool» может быть использован дляпрослушивания DNS трафика, после чего злоумышленник может оценить диапазон ID для запросов сервераимен. Атакующий должен выполнить следующиедействия:
1. Злоумышленник посылает DNS-запрос на разрешение имени www.test.com целевому серверуns.dnstest.com.
2. Целевой DNS-сервер перенаправляет полученныйзапрос к серверу доменаns.test.com.
3. Злоумышленник прослушивает запросы, получаемые ns.test.com и определяет ID.
4. Злоумышленник посылает DNS-запрос на разрешение имени www.victim.com серверу ns.dnstest.com.И сразу же шлет группу фальсифицированных DNS-ответов (передавая в качестве IP-адреса, один из адресовзлоумышленника — 10.0.0.1) на свой же запрос с подмененным IP-адресом источника на адрес одного из DNS-серверов victim.com. В каждом ответе ID увеличиваетсяна 1 по сравнению с идентификатором, полученнымво время второго этапа атаки, для увеличения вероятности нахождения правильного номера ID. Сервер ns.dnstest.com мог ответить на запросы других клиентови, соответственно, увеличить свой DNS ID. Для этогоможет быть использована утилита «ADMkill», котораябудет отсылать серию подделанных ответов с IP-адресомс заданным диапазоном ID (т.е. мы отсылаем пакетыс ID от 27300 до 27330):
# ./ADMkillDNS 10.0.0.1 192.168.1.60 ns2.victim.com27300 27330
В результате такой атаки по подложным IP-адресамбудет ходить не отдельный клиент-жертва, а все пользователи будут обращаться к машине злоумышленника.
4. DNSSEC и нагрузка на сеть
Как уже упоминалось выше, в основе протоколаDNSSEC лежит метод цифровой подписи ответов назапросы, в результате чего пакеты DNSSEC несут больше информации, что увеличивает нагрузку на память,процессор и полосу пропускания сервера. ВнедрениеDNSSEC увеличивает объем передаваемых данных, засчет использования цифровой подписи. Для того, чтобыэто проверить, были прослушаны запросы отправляемыепользователями. Проанализаровав их можно однозначносделать вывод, что объем трафика увеличивается приразвернутом DNSSEC почти на 20 %. Также следуетзнать, что если пакет превысит 512 байт, то могут воз-никнуть проблемы с его приемом. Конечно, у этой проблемы есть решение. Согласно протоколу DNS клиентдолжен сообщить об этом серверу, который, в своюочередь, постарается уместить ответ в установленные512 байт. При этом часть информативных данных может быть обрезана. В случае, если даже необходимаяинформация не помещается, сервер сообщит об этомклиенту установкой бита «обрезания» (truncationbit).Однако, сжатие не безгранично, и если после него размер пакета все еще большой, то клиент автоматически переключится из транспортного протокола UDP в TCP,в котором нет подобных ограничений. Некоторыемаршрутизаторы или устройства безопасности могутработать на правиле об ограничении пакета в 512 байт,что в свою очередь требует переконфигурации.
5. Выводы
В этой статье были исследованы и реализованы атакина сервер имен, в результате чего было выяснено, чтооригинальный DNS стандарт не заботится о безопасности. При проведении атак на сервер с развернутымDNSSEC методы, которые использовались при атакена «чистый» DNS, оказались безуспешными. Причинойэтого является то, что в основе протокола DNSSECлежит метод цифровой подписи ответов на запросы.В ходе анализа проведенных атак, было выяснено, чтоDNSSEC может бороться с таким уязвимостями DNSкак «отравление кэша» или «человек посередине». Этообъясняется тем, что DNSSEC защищает DNS путемпроверки подлинности и целостности системы DNS-сообщений. Атаки, ориентированые на DNS сообщения, невозможны при использовании DNSSEC, так какклиенты проверяют цифровую подпись предоставляемуюв ответ. Расширения безопасности DNS SecurityExtensionsзащищают клиентов и сервера от атак, при которых модифицируется кэш DNS, путем подписывания записис использованием шифрования с открытым ключом.
В ходе работы было выявлено, что внедрение DNSSECувеличивает объем передаваемых данных, нагрузку напамять, процессор и полосу пропускания сервера на20 %, что не является критичным, с учетом уровня осуществляемой безопасности.
