4.3.3. Внедрение в сеть Internet ложного сервера путем перехвата dns-запроса или создания направленного "шторма" ложныхDns-ответов на атакуемыйDns-сервер

Из рассмотренной в п. 4.3 схемы удаленногоDNS-поиска следует, что в том случае, если указанное в запросе имяDNS-сервер не обнаружил в своей базе имен, то запрос отсылается сервером на один из корневыхDNS-серверов, адреса которых содержатся в файле настроек сервера root.cache.

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

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

Из анализа только что подробно описанной схемы удаленногоDNS-поиска становится очевидно, что в том случае, если в ответ на запрос отDNS-сервера атакующий направит ложныйDNS-ответ (или в случае "шторма" ложных ответов будет вести их постоянную передачу), то в кэш-таблице сервера появится соответствующая запись с ложными сведениями и в дальнейшем все хосты, обратившиеся к данномуDNS-серверу, будут дезинформированы, и при обращении к хосту, маршрут к которому атакующий решил изменить, связь с ним будет осуществляться через хост атакующего по схеме "Ложный объект РВС" ! И, что хуже всего, с течением времени эта ложная информация, попавшая в кэшDNS-сервера, будет распространяться на соседниеDNS-серверы высших уровней, а, следовательно, все больше хостов в Internet будут дезинформированы и атакованы!

Очевидно, что в том случае, если атакующий не может перехватитьDNS-запрос отDNS-сервера, то для реализации атаки ему необходим "шторм" ложныхDNS-ответов, направленный наDNS-сервер. При этом возникает следующая проблема, отличная от проблемы подбора портов в случае атаки, направленной на хост. Как уже отмечалось ранее,DNS-сервер, посылая запрос на другойDNS-сервер, идентифицирует этот запрос двухбайтовым значением (ID). Это значение увеличивается на единицу с каждым передаваемым запросом. Узнать атакующему это текущее значение идентификатораDNS-запроса не представляется возможным. Поэтому предложить что-либо, кроме перебора 216 возможных значений ID, достаточно сложно. Зато исчезает проблема перебора портов, так как всеDNS-запросы передаютсяDNS-сервером на 53 порт.

Следующая проблема, являющаяся условием осуществления этой удаленной атаки наDNS-сервер при направленном "шторме" ложныхDNS-ответов, состоит в том, что атака будет иметь успех только в случае, еслиDNS-сервер пошлет запрос на поиск имени, которое содержится в ложномDNS-ответе.DNS-сервер посылает этот столь необходимый и желанный для атакующего запрос в том и только том случае, когда на него приходитDNS-запрос от какого-либо хоста на поиск данного имени и этого имени не оказывается в кэш-таблицеDNS-сервера. В принципе, этот запрос может возникнуть когда угодно, и атакующему придется ждать результатов атаки неопределенное время. Однако, ничто не мешает атакующему, не дожидаясь никого, самому послать на атакуемыйDNS-сервер подобныйDNS-запрос испровоцироватьDNS-сервер на поиск указанного в запросе имени! Тогда эта атака с большой вероятностью будет иметь успех практически сразу же после начала ее осуществления!

Для примера вспомним недавний скандал (28 октября 1996 года) с одним из московских провайдеров Internet - компанией РОСНЕТ, когда пользователи данного провайдера при обращении к обычному информационному WWW-серверу попадали, как было сказано в телевизионном репортаже, WWW-сервер "сомнительного" содержания (наверное,www.playboy.com). В связи с абсолютным непониманием случившегося как журналистами (их можно понять - они не специалисты в этом вопросе), так и теми, кто проводил пресс-конференцию (специалистов к общению с прессой, наверное, просто не допустили) информационные сообщения о данном событии были настолько убоги, что понять, что случилось, было толком невозможно. Тем не менее, этот инцидент вполне укладывается в только что описанную схему удаленной атаки наDNS-сервер. С одним исключением: вместо адреса хоста атакующего в кэш-таблицуDNS-сервера был занесен IP-адрес хостаwww.playboy.com.

Однако, видимо, большинство российских кракеров еще не доросли до столь утонченных методов сетевого взлома, как атака наDNSили любая другая атака из данной главы. После того, как был написан предыдущий абзац, нам довелось ознакомиться с интервью, которое якобы дал кракер, осуществивший этот взлом. Из него следовало, что атака использовала одну из известных "дыр" в WWW-сервере РОСНЕТа. Это и позволило атакующему подменить одну ссылку на другую. Осуществление атак такого типа является по сути тривиальным и не требует от взломщика практически никакой квалификации (подчеркнем - именно осуществление; совершенно другое дело - нахождение этой "дыры" ). Высокая квалификация необходима именно для поиска той самой уязвимости, используя которую можно взломать систему. Но, по глубокому убеждению авторов, обнаруживший уязвимость и осуществивший на ее базе взлом, скорее всего будутразными лицами, так как именно высокая квалификация специалиста, обнаружившего "дыру" , не позволит ему причинить ущерб простым пользователям. (Р. Т. Моррис не был исключением. Просто его червь из-за ошибки в коде вышел из-под контроля, и поэтому пользователям сети был нанесен определенный ущерб.)

Рис. 4.6.1. Внедрение в Internet ложного сервера путем перехвата  DNS-запроса отDNS-сервера.

Рис. 4.6.1.1. Фаза ожидания атакующимDNS-запроса отDNS-сервера (для ускорения атакующий генерирует необходимыйDNS-запрос).

Рис. 4.6.1.2. Фаза передачи атакующим ложногоDNS-ответа наDNS-сервер 1.

Рис. 4.6.2. Внедрение в Internet ложного сервера путем создания направленного "шторма" ложныхDNS-ответов на атакуемыйDNS-сервер.

Рис. 4.6.2.1. Атакующий создает направленный "шторм" ложныхDNS-ответов от имени одного из корневыхDNS-серверов и при этом провоцирует атакуемыйDNS-сервер, посылаяDNS-запрос.

Рис. 4.6.2.2.DNS-сервер передаетDNS-запрос на корневойDNS-сервер и немедленно получает ложныйDNS-ответ от атакующего.

В завершение хотелось бы снова вернуться к службеDNSи сказать, что, как следует из предыдущих пунктов, использование в сети Internet службы удаленного поискаDNSпозволяет атакующему организовать в Internet удаленную атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в безопасности этой и так отнюдь не безопасной глобальной сети. Напомню, что, как указывал S. M. Bellovin в ставшей почти классической работе [14]: "A combined attack on the domain system and the routing mechanisms can becatastrophic"("Комбинация атаки на доменную систему и механизмы маршрутизации может привести к катастрофе" ).

КРИПТОГРАФИЧЕСКИЕ ПОДПИСИ

Для ликвидации названных ограничений протокола DNS IETF создала рабочую группу DNSSEC (DNSSEC Working Group, DNSSEC WG) для внесения расширений DNSSEC в существующий протокол. Berkeley Internet Name Daemon (BIND) 8.2 имеет некоторые из функциональных возможностей DNSSEC.

Цель DNSSEC - обеспечить аутентификацию и целостность информации, содержащейся в DNS (см. Рисунок 2). DNSSEC позволяет достигнуть обеих целей посредством шифрования.

Рисунок 2. Два примера ответов и запросов DNS с DNSSEC и без оных. Обратите внимание, что в ответе с DNSSEC ответное сообщение содержит не только подписи и ключи, необходимые для проверки информации, но и сам исходный вопрос. Эта процедура называется "Аутентификацией транзакции и запроса". Благодаря ей запрашивающая сторона может быть уверена, что она получила ответ на тот вопрос, который задавала.

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

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

В случае криптографической подписи аутентификация производится неявно, на основании факта совпадения дешифрованного и вычисленного значений хэша: только держатель личного ключа мог зашифровать хэш, так как открытый ключ дал правильное значение хэша. Таким образом, любая система на базе технологии открытых ключей должна обеспечивать надежную защиту личных ключей. Этому вопросу посвящен документ RFC 2541 рабочей группы DNSSEC.

НОВЫЕ ЗАПИСИ РЕСУРСОВ

Криптографические подписи DNSSEC применяются к данным по зоне, динамическим обновлениям и транзакциям DNS. Кроме того, они используются для подтверждения отсутствия данных DNS. DNSSEC предусматривает три новые записи ресурсов - KEY RR, SIG RR и NXT RR.

KEY RR содержит открытый ключ, принадлежащий имени домена, указанному в KEY RR. Это не сертификат открытого ключа. Механизм обеспечения возможностей поиска сертификатов открытых ключей предусматривается DNSSEC WG, но не для целей защиты данных DNS. Он предоставляется в качестве дополнительного бонуса, благодаря которому DNS может применяться для запроса сертификатов открытых ключей на все, что может быть представлено с помощью имени домена. Эту возможность обеспечивает CERT RR.

SIG RR содержит преимущественно криптографическую подпись, дату окончания срока годности подписи и определение данных DNS, к которым эта подпись относится. NXT RR позволяет проверить (за счет использования криптографии), что RR для данного имени DNS не существует. Таким образом, отсутствие данной RR может быть подтверждено доказательно.

Другим аспектом DNSSEC является подпись транзакции (Transaction Signature, TSIG). TSIG отличается от других подписей DNS тем, что она создается с использованием шифрования с секретными ключами. Мы рассмотрим TSIG позже.

Протокол DNSSEC как таковой не обеспечивает конфиденциальности данных или контроля доступа. Однако конкретные его реализации могут предусматривать те или иные механизмы обеспечения конфиденциальности и контроля доступа. Причина отсутствия такого стандартного механизма в DNS в том, что исходный протокол DNS предназначался для работы с общедоступными данными. Озабоченность утечкой информации относительно имен и местонахождения систем и возможность атак по типу "отказ в обслуживании" порождает спрос на механизмы обеспечения конфиденциальности и контроля доступа. Этот спрос отражается в реализациях DNS.

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

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

Однако, как большинство подобных решений, этот метод просто смещает акценты в проблеме защиты, ставя вопрос: "Как мы можем знать, что данные были действительно подписаны тем, кем они должны были быть подписаны?" В случае шифрования с открытыми ключами подписи генерируются с помощью личного ключа и проверяются с помощью открытого ключа. DNSSEC использует для распространения открытых ключей узлов Internet саму DNS, т. е. необходимый для проверки ключ предоставляется с помощью того же самого совершенно незащищенного протокола, что и данные, которые вы пытаетесь проверить. Кажется, что мы попали в замкнутый круг, но это не так.

Один из способов проверить открытый ключ до использования его для проверки ответа - взглянуть на подпись самого открытого ключа. Родительский узел должен подписывать все свои открытые ключи, поэтому в нашем первом примере проверочный (открытый) ключ examiner.com должен был быть подписан администратором com. Однако, прежде чем проверять подпись com для examiner.com, нам необходимо знать открытый (проверочный) ключ для самого com, а он должен быть подписан родителем com (т. е. вышеупомянутым корнем DNS). Чтобы быть абсолютно уверенными в том, что открытые (проверочные) ключи корня действительно принадлежат ему, они должны находиться на вашем компьютере в файле, полученном защищенным образом (например, на CD-ROM) от надежного источника (например, от производителя компьютера). Так как корень является прародителем всех имен доменов, для всей DNS нужен только один открытый ключ.

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

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

Клиенту приходится доверять, во-первых, серверу, что он выполнил свою работу по проверке данных, и, во-вторых, ответу, что он действительно поступил от локального кэширующего сервера, а не от некой вторгшейся в диалог третьей стороны.

ПОДПИСИ ТРАНЗАКЦИЙ

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

TSIG особенно полезен в случае транзакций DNS UPDATE. Большинство транзакций DNS представляет собой запросы относительно наличия данных. Транзакция DNS UPDATE вносит изменения в данные DNS на узле. Эта транзакция описана в RFC 2136, но для наших целей достаточно будет знать, что она не снабжена собственными механизмами защиты.

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

НЕДОСТАТКИ DNSSEC

Подписание и проверка данных DNS, очевидно, создают дополнительные накладные расходы, отрицательно сказывающиеся на производительности сети и серверов. Подписи занимают немало места, часто они намного превышают по объему данные, под которыми стоят. Это увеличивает нагрузку, которую DNS возлагает на магистраль Internet и многие немагистральные каналы. Генерация и проверка подписей отнимают значительное время ЦПУ. В некоторых случаях однопроцессорный сервер DNS придется даже заменить многопроцессорным сервером DNS. Подписи и ключи могут занимать на порядок больше места на диске и в оперативной памяти, чем собственно данные. Базы данных и системы управления придется наращивать, чтобы они могли справляться с возросшими объемами.

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

Вывод отсюда следующий: развертывание DNSSEC чревато столькими же опасностями, как и отказ от него. Мы бы рекомендовали обождать год или два, пока DNSSEC RFC не получит статуса хотя бы проекта стандарта.

На декабрь 1999 года TSIG полностью и DNSSEC частично были реализованы только в BIND 8.2. Другие разработчики (включая Microsoft) собираются реализовать различные формы TSIG в следующих редакциях своих продуктов. Спецификация BIND 9.0, появление которой ожидается в первой четверти 2000 года, будет содержать полную реализацию DNSSEC.

РАБОТА ПРОДОЛЖАЕТСЯ

Работа над некоторыми функциональными сторонами DNSSEC еще продолжается, например над тем, как именно администрация com будет подписывать открытые ключи. Соответствующий новый протокол может вскоре появиться. Кроме того, во время смены ключей может потребоваться поддерживать одновременно более одной пары открытых/личных ключей, но, как это будет реализовано, пока неясно. Если личный ключ окажется украден и, как следствие, должен будет изъят из обращения, то в настоящее время никаким способом нельзя известить о компрометации ключа тех, кто будет проверять с его помощью подпись.

Наконец, это вопрос защиты личного ключа корня. Этот ключ будет по сути ключом ко всей коммерции Internet в мировом масштабе, но администрация корневых серверов постоянно меняется.

Должны ли Соединенные Штаты продолжать администрировать это всемирное средство обеспечения электронной коммерции? Если администрирование будет передано некоммерческой отраслевой ассоциации, например Internet Corporation for Assigned Name and Numbers (ICANN), то сможет ли такая организация учесть интересы и законодательство всех стран? Должно ли оно быть передано Объединенным Нациям? В состоянии ли Объединенные Нации справиться с подобной ответственностью? В состоянии ли кто-нибудь вообще? Развертывание DNSSEC во всемирном масштабе невозможно, пока вопрос с администрацией корня не будет урегулирован.

Верно, конечно, что работа над DNSSEC еще не завершена. Однако любая организация, активно использующая Internet, должна рассматривать DNSSEC в качестве важнейшего компонента своей инфраструктуры защиты, потому протокол DNS по-прежнему уязвим для злоупотреблений. Только DNSSEC, благодаря своим мощным криптографическим механизмам, в состоянии обеспечить одновременно аутентификацию и целостность всех аспектов DNS.

Дайана Давидович работает в Национальном управлении океанических и атмосферных исследований. С ней можно связаться по адресу: compsec101@yahoo.com. Пол Викси - президент и основатель Internet Software Consortium (ISC) и архитектор BIND. С ним можно связаться по адресу: paul@isc.org.

Защита серверов DNS без помощи DNSSEC

Воспользуетесь ли вы неполной реализацией DNS Security (DNSSEC) в BIND 8.2 или будете ждать полной стандартизации расширений защиты, в любом случае вы можете принять некоторые меры предосторожности для защиты информации DNS до появления полной реализации DNSSEC. Сервер, где выполняется программное обеспечение DNS, должен быть хорошо защищен. Все ПО, включая программное обеспечение DNS, должно быть представлено в последних редакциях, и к ним должны быть применены все выпущенные заплаты. При оценке возможности размещения DNS на сервере вы должны помнить, что всякое выполняющееся на сервере сетевое приложение увеличивает риск взлома. Для сокращения степени риска на сервере должны выполняться только самые необходимые для его работы приложения. Затем вы можете ограничить доступ к этим сервисам и предусмотреть жесткую идентификацию для тех приложений, для которых она необходима.

С появлением автоматизированного инструментария сканирования при выходе в Internet серверы DNS подвергаются постоянному зондированию и попыткам вторжения. Здесь практически ничего нельзя поделать, так как серверы DNS должны отвечать на запросы.

Однако их открытость можно ограничить за счет применения модели расщепленной DNS. При такой модели один сервер DNS с минимальной информацией помещается с внешней стороны сети, в то время как второй сервер - с внутренней стороны. Доступ к этому серверу возможен только из внутренней сети, и он содержит всю информацию DNS по внутренней сети.

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

Ресурсы Internet

Internet Software Consortium (ISC) - некоммерческая организация, занимающаяся созданием, обновлением и публикацией реализаций базовых протоколов Internet в виде исходных кодов. Домашняя страница ISC имеет адрес: http://www.isc.org.

Collaborative Advanced Interagency Research Network (CAIRN) представляет собой тестовую сеть, спонсируемую Defense Advanced Research Projects Agency (DARPA). CAIRN предлагает информацию о DNSSEC на http://www.cairn.net/DNSSEC/index.html.

Более подробную информацию о DNSSEC и других вопросах защиты можно найти на http://www.geocities.com/compsec101/.

-16-