Журнал о компьютерных сетях и телекоммуникационных технологиях
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК:
    Домой
 
   
АРХИВ ЖУРНАЛА
   

2008: 1 2 3 4 5 6 7 8 9 10 11 12 13
2007: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2006: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2005: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2004: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2003: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2002: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2001: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2000: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1999: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1998: 1 2 3 4 5 6 7 8 9 10 11 12
1997: 1 2 3 4 5 6 7 8 9 10 11 12
1996: 1 2 3 4 5 6 7 8 9 10


Rambler's Top100

  

Настало ли время безопасности для DNS?

Майк Фратто

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

Допустим, вы набирали в строке браузера имя хоста, например, www.yahoo.com. Как же узнать, что IP-адрес, содержащийся в ответе службы DNS, действительно указывает на один из серверов компании Yahoo, а не на какой-нибудь нелегальный узел?

Да никак. В прошлом году система DeepSight компании Symantec выявила 25 уязвимостей разнообразных серверов и анализаторов (resolvers) DNS. По существу, есть несколько способов заставить DNS предоставлять поддельную информацию. Злоумышленник может получить доступ к серверу DNS и изменить его записи или использовать для фальсификации ответа одно из множества общедоступных инструментальных средств. Он может поместить ложную информацию в кеш DNS или добавить ее в таблицу имен хостов вашего компьютера, что мы наблюдали в случаях атак многочисленных «червей» и «троянов». Многие из этих атак не так-то легко отбить, хотя зачастую они кратковременны и относительно просто обнаруживаются. Даже за короткий период времени они могут нанести компьютеру ощутимый вред.

Подтверждение достоверности имен

Вот уже почти десять лет рабочая группа DNS Extensions организации Internet Engineering Task Force (IETF) концентрирует свое внимание на безопасности службы DNS, реализуя изменения ее базовых протоколов. В настоящее время основу документации (Request for Comments — RFC) по технологии DNS Security (DNSSec) составляют стандарты Интернет RFC 4033, 4034 и 4035. Главной задачей DNSSec является предоставление аутентичных ответов на DNS-запросы, используя криптографию с открытым ключом, подлинность которого может быть установлена DNS-клиентом.

Система DNS представляет собой простую, хотя и обширную, иерархию зон. Вы можете пройти по дереву DNS, читая имя хоста слева направо. Например, в доменном имени www.example.com часть www является именем хоста в зоне example. В свою очередь, example — это домен зоны com и, наконец, .com — это домен верхнего уровня корневой зоны (Root). Если используется протокол DNSSec, то поддерживающий его клиент может «пройти» по цепочке сертификатов и по содержащимся в них открытым ключам удостовериться в подлинности ответов DNS-служб. Предполагается, что если администраторы всех зон надежно хранят свои секретные ключи, то в подлинности подписанных с помощью протокола DNSSec и образующих имя www.example.com ответов DNS можно не сомневаться. Если злоумышленник попытается подсунуть фальшивый ответ, то подделка будет обнаружена (см. «Подтверждение подлинности запроса DNSSec»).

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

Хотя, согласно планам организации IETF, использующие DNSSec фиктивные анализаторы смогут перекладывать задачу подтверждения подлинности DNS-ответа на рекурсивный анализатор, необходимо обеспечить безопасность обмена данными между фиктивным и рекурсивным анализаторами. Одним из способов обеспечения безопасности является использование между клиентом и сервером DNS протокола Authentication Header из набора протоколов IP Security. Если же фиктивный анализатор поддерживает DNSSec, то он может запрашивать все записи DNSSec и сам выполнять процесс подтверждения подлинности DNS-ответов. Учитывая, что протокол DNSSec должен быть обратно совместимым, в нем предусмотрены оба варианта обеспечения безопасности обмена данными.

В инфраструктуре DNSSec все открытые ключи, кроме так называемого «доверенного якоря» (trust anchor), можно распределять посредством сервера DNS. Протокол DNSSec используется в тех случаях, когда зоны представляют собой своего рода «островки доверия» (islands of trust), при этом каждая зона генерирует свою ключевую пару и удостоверяет свой открытый ключ.

Распишитесь здесь

Основным камнем преткновения для глобального развертывания технологии DNSSec стала проблема «курицы и яйца»: глобальная среда DNSSec требует, чтобы корневая зона была удостоверена цифровой подписью. Все домены верхнего уровня, такие, как .com, .net, .info, .biz и .uk, тоже требуют подписи. В цифровой подписи нуждаются и все домены более низкого уровня, желающие в полной мере использовать DNSSec. Таким образом, менеджеры зон DNS вовлекаются в процесс управления ключами шифрования. Кроме того, организациям, вроде VeriSign и GoDaddy, которые заведуют регистрацией доменных имен, придется поддерживать DNSSec и организовывать безопасные процессы регистрации.

И все это необходимо лишь для изначального развертывания инфраструктуры DNSSec.

На клиентской стороне все используемые компаниями и Интернет-провайдерами рекурсивные серверы DNS должны поддерживать протокол DNSSec. Ибо какой смысл развертывать этот протокол, если ни одна компания не будет его использовать? Хотя используемые на настольных системах и серверах фиктивные анализаторы должны поддерживать DNSSec, в настоящее время компания Microsoft не имеет никаких планов относительно встраивания в Windows поддерживающего DNSSec фиктивного анализатора. И наконец, администрирование инфраструктуры DNSSec потребует разработки и развертывания протоколов, процессов и продуктов для распределения ключей и управления ими.

Все это — система, состоящая из множества «подвижных» компонентов. Но, если в игре не будут участвовать все компоненты низших уровней, то для операторов доменов верхнего уровня (Top-Level Domain — TLD) вряд ли найдется какой-нибудь неотразимый аргумент в пользу развертывания дорогостоящей среды DNSSec. Почему дорогостоящей? Согласно оценкам экспертов, объем файлов зон может увеличиться в семь–десять раз, что потребует каналов связи с более высокой пропускной способностью.

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

Испытательный полигон

Но не стоит упускать из своего поля зрения пилотные проекты и инсталляции DNSSec, выполненные TLD-операторами в Пуэрто-Рико и Швеции, которые становятся испытательным полигоном с целью опробывания технологии DNSSec и выработки необходимых методик управления ею. Являющийся подразделением Министерства торговли США, Национальный институт стандартов и технологии (National Institute of Standards and Technology — NIST) также активно осуществляет пилотный DNSSec-проект для домена .gov, реализации которого требует Федеральный закон об управлении информационной безопасностью (Federal Information Security Management Act). Специальные средства контроля безопасности для компьютерных систем среднего и высокого уровней секретности требуют безопасной системы DNS, в обеспечении поддержки которой протокол DNSSec, возможно, будет играть центральную роль.

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

  
8 '2008
СОДЕРЖАНИЕ

бизнес

• К инновационным ИТ-инфраструктурам — разными путями

• 3M ставит на оптику

• Как добиться успеха на рынке СПД

инфраструктура

• Отвод тепла в ЦОДе: плотность или площадь?

• Перелом на рынке средств 10-Gigabit Ethernet

• ЦОД следующего поколения

информационные системы

• Соковыжималка в апельсиновой роще, или eTOM и все-все-все

• Золотая середина в контроле над ПК

• Мыслить в стереотипах SOA

кабельные системы

• СКС: развитие рынка и высокоскоростные решения

• Монтажные шкафы и охлаждение оборудования

сети связи

• Операторам нужно измениться

защита данных

• Настало ли время безопасности для DNS?

• Блюсти ИТ-порядок

новые продукты

• PCI-плата ATEN IP8000; OmniSwitch для жестких условий; Новый анализатор от EXFO


• Калейдоскоп


Реклама:
 Copyright © 1996-2008 ООО "Сети и Системы Связи". вверх