Вопросы безопасности
Категория: Система доменных имен | Автор: admin | 30-04-2010, 03:40 | Просмотров: 2963

DNS по своей сути — открытая система. Именно такой — открытой — она вышла в свет, но в процессе своего развития приобретала все больше средств защиты или, по крайней мере, становилась более защищенной. По умолчанию каждый, у кого есть доступ в Internet, может исследовать чужой домен отдельными запросами с помощью таких утилит, как dig, host или nslookup. В некоторых случаях можно получить дамп всей базы данных DNS.

Для устранения этих недостатков в последние версии BIND были введены различные средства управления доступом, основанные на проверке адресов или криптографической аутентификации. В табл. 16.10 перечислены элементы подсистемы безопасности, которые настраиваются в файле named.conf.

 

Таблица 16.10. Средства защиты в файле nomea.conf

Средство

Инструкции

Что определяет

allow-query

options, zone

Кто может посылать запросы зоне или серверу

allow-transfer

options, zone

Кто может запрашивать зонные пересылки

allow-update

zone

Кто может делать динамические обновления

blackhole

options

Какие серверы нужно полностью игнорировать

bogus

server

Какие серверы никогда нельзя опрашивать

acl

various

Списки управления доступом

 

Демон named может функционировать в среде, где корневой каталог изменен с помощью команды chroot, и при этом иметь непривилегированный идентификатор пользователя. Таким образом, устраняется малейшая вероятность разрушений, вызванных неконтролируемыми действиями со стороны суперпользователя. Благодаря сигнатурам транзакций демон способен контролировать динамические обновления. И конечно же, он полностью поддерживает спецификацию DNSSEC. Обо всем этом речь пойдет в следующих разделах.

 

Еще раз о списках управления доступом

 

Список управления доступом — это именованный список соответствия адресов, который может служить аргументом различных директив, в частности allow-query, allow-transfer и blackhole. Они позволяют справляться с такими нарушениями защиты DNS, как имитация доменного имени и атаки вида "отказ от обслуживания". Синтаксис списков был рассмотрен при описании инструкции acl в параграфе 16.9.

В каждой организации должен существовать по крайней мере один такой список для недоступных адресов и один — для локальных. Например:

 

acl bogusnets  {      //список недоступных и фиктивных сетей

   0.0.0.0/8;          //адреса с подстановочными знаками

   169.254.0.0/16;    //канально-локальные делегируемые адреса

   192.0.2.0/24;      //тестовые адреса,  наподобие example.com

   224.0.0.0/3;       //пространство групповых адресов

   10.0.0.0/8;             //частное адресное пространство  (RFC1918)

   172.16.0.0/8;      //частное адресное пространство  (RFC1918)

   192.168.0.0/16;    //частное адресное пространство  (RFC1918)

};

 

acl cunets {          //список сетей университета штата Колорадо

   128.138.0.0/16;    //основная кампусная сеть

   198.11.16/24;

   204.228.69/24;

};

 

 

Далее нужно в глобальной секции options конфигурационного файла разместить следующие директивы:

 

allow-recursion { cunets;  };

blackhole { bogusnets;   };

 

 

Также желательно ограничить зонные пересылки только легитимными подчиненными серверами. Это достигается с помощью приведенных ниже списков:

 

acl ourslaves {

128.138.242.1;      // anchor

...

};

acl measurements {

128.9.160.157;     // проект Билла Маннинга

198.32.4.0/24;     // проект Билла Маннинга

192.5.5.0/24;      // проект Марка Лотторза

};

 

 

Собственно ограничение реализуется такой строкой:

allow-transfer { ourslaves; measurements;   };

 

Пересылки разрешены только нашим подчиненным серверам, а также компьютерам двух глобальных исследовательских проектов, которые посвящены определению размеров сети Internet и процента неправильно сконфигурированных серверов Подобное ограничение лишает остальных пользователей возможности получать дамп всей базы данных посредством утилиты nslookup, dig или host.

Например:

 

% nslookup

Default Server: имя сервера

Address: IP-адрес сервера

 

> ls cs.colorado.edu.

[имя сервера]

*** Can't list domain cs.colorado.edu: Unspecified error

 

 

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

 

Ограничение возможностей демона named

 

Чтобы предотвратить ущерб, который может быть нанесен в случае атаки на сервер, можно запустить демон named в среде с измененным корневым каталогом и/или от имени непривилегированного пользователя. Флаг -t задает корневой каталог для демона, а флаги -u и -g — значения UID и GID, присваиваемые процессу named. Последний из перечисленных флагов не поддерживается в BIND 9. К примеру, команды

# named -u 53 -g 53 -t /var/named     /* BIND 8 */ 

# named -u 53 -t /var/named           /* BIND 9 */

 

 

запускают демон с идентификатором пользователя 53, идентификатором группы 53 (только в BIND 8) и корневым каталогом /var/named.

Новый корневой каталог не может быть пустым, так как он должен содержать все файлы, необходимые для нормальной работы демона named: /dev/null, библиотеки совместно используемых функций, зонные файлы, named.conf и т.д. Если скомпилировать демон так, чтобы библиотеки компоновались статически, то не придется думать, какие библиотечные файлы копировать в каталог /var/named.

Хакер, взломавший демон named, получает доступ к системе от имени того пользователя, который осуществил запуск демона. Если это пользователь root и корневой каталог не был изменен, последствия могут оказаться разрушительными. Многие администраторы не заботятся об использовании флагов -u, -g и -t, но в таком случае они должны быстрее ставить "заплаты", чем хакеры будут атаковать систему в случае обнаружения очередной "дыры".

 

Безопасные межсерверные взаимодействия посредством спецификаций TSIG и TKEY

 

Пока спецификация DNSSEC (описана в следующем разделе) находилась в стадии принятия, организация IETF разработала более простой механизм, названный TSIG (RFC2845). Он позволял организовывать безопасное взаимодействие серверов благодаря использованию сигнатур транзакций. Контроль доступа, основанный на таких сигнатурах, надежнее, чем контроль на основании исходных IP-адресов.

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

Сигнатурами TSIG подписываются DNS-запросы и ответы на них. Они передаются только между серверами, но не между сервером и распознавателем. Сигнатура проверяется в момент поступления пакета и тут же отбрасывается; она не сохраняется в кэше и не становится частью базы данных DNS. Спецификация TSIG допускает применение различных методов шифрования, но в BIND реализован лишь один из них: алгоритм НМАС-MD5.

Утилита dnssec-keygen, являющаяся частью пакета BIND, генерирует ключ для пары серверов. Например, если имеются два сервера, серв1 и серв2. команда

# dnssec-keygen -Н 128 -h -n серв1-серв2 

 

создаст 128-разрядный ключ и сохранит его в файле Kcepвl-cepв2+157+00000.private. В этом файле содержится строка "Key:", за которой следует собственно ключ, закодированный по основанию 64.

Сгенерированный ключ представляет собой всего лишь длинное случайное число. Создать ключ можно вручную, записав ASCII-строку нужной длины и притворившись, что она закодирована по основанию 64. Можно также воспользоваться утилитой mmencode для кодирования произвольной строки. Способ создания ключа не важен; главное, чтобы он существовал на обеих машинах.

Скопируйте ключ на оба сервера посредством команды scp либо вырежьте и вставьте его в нужном месте. Не используйте программы telnet и ftp для копирования ключа: даже внутренние сети могут быть небезопасными. Ключ должен присутствовать в файле named.conf на обеих машинах. В связи с тем, что этот файл является общедоступным, а ключ — нет, поместите ключ в отдельный файл который будет подключаться к файлу named.conf посредством инструкции include.

 

 

Например, можно создать файл servl-serv2.key и включить в него такой фрагмент:

 

key servl-serv2  {

algorithm hmac-md5;

secret "сгенерированный ключ";

};

 

 

Режим доступа к файлу должен быть 600, а идентификатор его владельца — таким же, как и у демона named. В файл named.conf, ближе к началу, нужно добавить следующую строку:

include "servl-serv2.key";

 

На данном этапе был лишь определен сам ключ. Чтобы его можно было использовать для подписи и проверки обновлений, следует заставить каждый сервер идентифицировать другую сторону посредством директивы keys. Для этого необходимо в файл named.conf первого сервера включить строки

 

server адрес_серв2 {

keys  { servl-serv2;   };

};

 

 

и аналогично в файл named.conf второго сервера — такие строки:

 

server адрес_серв1  {

keys  ( servl-serv2;   };

};

 

 

Любые предложения allow-query, allow-transfer и allow-update в инструкции zone также должны ссылаться на ключ, например:

allow-transfer { key servl-serv2;   );

 

Если вы впервые имеете дело с сигнатурами транзакций, запустите демон named на какое-то время на уровне отладки 1 (о режиме отладки рассказывается в параграфе 16.14) и посмотрите, не будут ли выданы сообщения об ошибках. Старые версии пакета BIND не понимают подписанных сообщений и генерируют сообщения об ошибках, иногда даже отказываясь загружать зонные данные.

TKEY — это механизм в BIND 9, позволяющий двум узлам автоматически генерировать совместный секретный ключ без телефонных звонков и удаленного копирования ключа. При этом используется алгоритм обмена ключами Диффи-Хеллмана, в котором каждая сторона создает случайное число, выполняет над ним определенные математические операции и посылает результат противоположной стороне. Полученное число заданным образом объединяется с имеющимся, и получается один и тот же ключ. Человек, прослушивающий линию, будет знать о содержании сеанса, но не сможет выполнить обратные математические преобразования.

 

Технология DNSSEC

 

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

DNSSEC предлагает три разных сервиса: распределение ключей посредством записей KEY, хранящихся в зонных файлах, проверка подлинности серверов и данных, а также проверка целостности зонных данных. Система основана на цепочке доверия: корневые серверы предоставляют подтверждающую информацию для доменов верхнего уровня, те — для доменов второго уровня и т.д.

В системах шифрования с открытым ключом имеется два ключа: один шифрует (подписывает) сообщение, а другой дешифрует (проверяет) его. Опубликованные данные подписываются секретным "личным" ключом Любой может проверить правильность сигнатуры с помощью "открытого" ключа, который свободно распространяется. Если открытый ключ правильно расшифровал зонный файл, значит, зона была зашифрована соответствующим личным ключом. Суть в том, чтобы убедиться в подлинности открытого ключа, используемого для проверки. Подобные системы шифрования позволяют одной из сторон поставить свою "подпись" на открытом ключе, передаваемом другой стороне, гарантируя таким образом легитимность ключа. Отсюда термин "цепочка доверия".

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

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

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

Родительские зоны подписывают открытые ключи своих дочерних зон. Демон named проверяет подлинность записи KEY дочерней зоны, сравнивая ее с сигнатурой родительской зоны. Для проверки подлинности последней демон обращается к родительской зоне более высокого уровня и т.д. вплоть до корневой зоны. Ее открытый ключ имеется в файле корневых "подсказок".

Для создания и использования подписанных зон требуется пройти несколько этапов. Сначала нужно сгенерировать пару ключей для зоны. Это делается с помощью такой команды в BIND 9:

dnssec-keygen -a DSA -Ь 768 -n ZONE mydomain.com.

 

или в BIND 8:

dnskeygen -D768 -z -n mydomain.com.

 

В табл. 16.11 описано назначение аргументов этих команд.

Таблица 16.11. Описание аргументов команд dnssec-keygen и dnskeygen

Аргумент

Назначение

Для dnssec-keygen

-a DSA

-b 768

-n ZONE mydomain.com.

Использование алгоритма DSA

Создание 768-битовой пары ключей

Создание ключей для зоны mydomain.com

Для dnskeygen

-D768

–z

-n mydomain.com.

Использование алгоритма DSA с 768-разрядным ключом

Создание ключа зоны

Создание ключей для зоны mydomain.com

 

Команды dnssec-keygen и dnskeygen возвращают следующий результат:

 

alg = 003

key identifier = 12345

flags = 16641

 

 

Они также создают файлы, содержащие открытый и секретный ключи:

Kmydomain.com.+003+12345.key      # открытый ключ

Kmydomain.com.+003+12345.private     # секретный ключ

 

Файл открытого ключа обычно включается в зонный файл с помощью директивы $INCLUDE. Чаще всего он идет сразу же после записи SOA.

Технология DNSSEC основана на принципе цепочки доверия, т.е. открытый ключ зоны должен быть подписан ее родительской зоной, чтобы считаться гарантированно надежным. В BIND 8 нет механизма, который заставил бы родительскую зону подписать ключ дочерней зоны; единственный выход — взаимодействие администраторов. В BIND 9 имеется программа dnssec-makekeyset, упрощающая этот процесс.

Программа dnssec-makekeyset упаковывает ключи, которые нужно подписать (это могут быть не только зонные ключи), устанавливает значение TTL для полученного набора, задает период действия сигнатуры, а затем посылает пакет в родительскую зону на подпись. Например, команда

# dnssec-makekeyset -t 3600 -е +864000

Kmydomain.com.+003+12345

 

упаковывает открытый ключ зоны, который был сгенерирован выше, устанавливает время жизни пакета равным 3600 с (один час), а срок действия родительской сигнатуры — 10 дней начиная с текущего момента. Программа dnssec-makekeyset создает один выходной файл, mydomain.com.keyset. Его нужно послать в родительскую зону на подпись. Он содержит открытый ключ и сигнатуры, созданные самими зонными ключами, чтобы родительская зона могла проверить открытый ключ дочерней зоны.

В BIND 9 родительская зона использует программу dnssec-signkey для подписи упакованного набора ключей:

# dnssec-signkey mydomain.com.keyset Kcom +003+56789

 

Эта команда создает файл mydomain.com.signedkey, который родительская зона ("com") возвращает дочерней зоне (mydomain.com) для включения в ее зонные файлы. В BIND 8 этой же цели служит программа dnssigner.

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

В BIND 8 цифровые подписи ставятся посредством программы dnssigner, расположенной в каталоге contrib дистрибутива. В BIND 9 для этого используется программа dnssec-signzone. Например, команды

# dnssigner -or mydomain.com -zi db.mydomain -zo

db.mydomain.signed –k1 mydomain.com dsa 12345 -st     # BIND 8 

# dnssec-signzone -o mydomain.com db.mydomain         # BIND 9

 

 

читают зонный файл db.mydomain и создают подписанную версию зонного файла, называемую db.mydomain.signed. Первая из команд отображает также статистическую информацию о процессе простановки подписи (запрашивается параметром -st). В частности, сообщается, сколько времени заняло подписание, и показывается, какие записи были добавлены или удалены. Запись SIG содержит много информации:

  • тип подписываемой записи;
  • используемый алгоритм (в данном случае — DSA);
  • значение TTL для подписанного набора записей;
  • срок действия сигнатуры (в формате ггггММддччсссс);
  • время простановки подписи (также в формате ггггММддччсссс);
  • идентификатор ключа (в данном случае — 12345);
  • имя подписывающего (mydomain.com.);
  • наконец, сама цифровая подпись.

 

Чтобы можно было работать с подписанной зоной, найдите в файле named.conf зону mydomain.com и измените в инструкции zone параметр file так, чтобы он указывал на файл db.mydomain.signed, а не db.mydomain В BIND 8 нужно также включить в инструкцию zone предложение pubkeys. Дело в том, что сервер BIND 8 проверяет зонные данные по мере их загрузки, поэтому он должен знать ключ заранее. В BIND 9 такая проверка отсутствует: сервер берет открытый ключ из записи KEY зоны и не требует никаких других настроек.

Цифровые подписи прекрасно подходят для положительных ответов следующего вида: "Вот IP-адрес узла anchor.cs.colorado.edu, а вот сигнатура доказывающая, что данные действительно поступили из домена cs.colorado.edu и эти данные «корректны». Но что делать с отрицательными ответами наподобие "Нет такого узла"? При таких ответах обычно не возвращаются подписанные записи.

В DNSSEC проблема решается за счет записей NXT, в которых указывается следующая запись зоны, отсортированной в каноническом порядке. Например, если после записи anchor.cs.colorado.edu идет запись awesome.cs.colorado.edu и поступает запрос к узлу anthill.cs.colorado.edu, в ответ будет получена запись NXT следующего вида:

anchor.cs.colorado.edu.   IN   NXT    awesome.cs.colorado.edu A MX NXT

 

Она говорит о том, что сразу после имени "anchor" в зоне cs.colorado.edu следует имя "awesome", а имени "anchor" соответствует как минимум одна запись A, MX и NXT. Последняя запись NXT в зоне ссылается на первый узел. К примеру, запись NXT для имени zamboni.cs.colorado.edu ссылается на первую запись, т.е. на сам домен cs.colorado.edu:

zamboni.cs.colorado.edu.    IN   NXT   cs.colorado.edu A MX NXT

 

Запись NXT возвращается также в том случае, если узел существует, но запись запрашиваемого типа отсутствует. Если, скажем, запрос производится к записи LOC узла anchor, будет выдана та же самая запись NXT, что и показана выше, но в ней будут отображены только записи A, MX и NXT.

Изложенный здесь материал касается реализации DNSSEC в BIND 9.0.0 (июль 2000). В пакет непрерывно вносятся значительные изменения, поэтому информация вряд ли будет оставаться корректной в течение долгого времени. Как всегда, точные детали можно узнать в справочных руководствах и документации к пакету BIND. Помня об этом, рассмотрим, какие потенциальные проблемы могут возникать в текущей реализации DNSSEC.

Спецификация DNSSEC не согласуется с понятиями кэширования и переадресации. В ней предполагается, что запрос сначала адресуется корневой зоне, а затем следует за отсылками вниз по дереву доменов в поисках ответа. Каждая подписанная зона в свою очередь подписывает ключи своих дочерних зон, и эта цепочка доверия надежна и нерушима. Если же в системе имеется переадресующий сервер, то первоначальный запрос попадает к нему, а не в корневую зону. Кэширующий сервер, посылающий запросы через переадресующий сервер, будет перепроверять сигнатуры, поэтому ответы будут гарантированно надежными. Но чтобы запрос имел успех, переадресующий сервер должен уметь возвращать все записи SIG и NXT, требуемые для проверки сигнатур. Серверы, не поддерживающие спецификацию DNSSEC, не умеют этого делать, и в документах RFC ничего не говорится о проблеме переадресации.

В BIND 9 реализован ряд дополнительных механизмов помимо тех, которые определены документом RFC2535, поэтому кэширующий сервер BIND 9 способен работать по протоколу DNSSEC через переадресующий сервер BIND 9. Таким образом, для одновременного использования протокола DNSSEC и переадресующего сервера во всей системе должен быть установлен пакет BIND 9.

Технология DNSSEC основана на существовании инфраструктуры открытых ключей, которая на практике еще не реализована. Нет четкого способа заставить родительскую зону подписать ключи дочерней зоны; нельзя послать письмо по адресу hostname@com и получить в ответ подписанные ключи. Широкое распространение технология DNSSEC, вероятно, получит в ближайшие несколько лет. Сначала, очевидно, появятся подписанные версии корневых зон.

Сигнатуры транзакций (технологии TSIG/TKEY) требуют меньше процессорного времени и меньшую полосу пропускания, чем системы аутентификации с открытым ключом. Но они гарантируют подлинность лишь отправителя, а не самих данных. Было бы неплохо взаимодействовать по технологии TSIG с сервером, реализующим протокол DNSSEC, однако невозможно установить подобные отношения с каждым сервером, так как технология TSIG требует ручной настройки DNS-файлов.

 

Microsoft — плохо, UNIX — хорошо

 

В Windows 2000 записи SRV используются для нахождения всего: серверов имен, принтеров, файловых систем и т.д. Реализуя записи SRV, компания Microsoft следовала спецификациям организации IETF, но способ вставка этих записей в базу данных DNS посредством защищенных динамических обновлений совершенно нестандартен. Компания использует разновидность сигнатур транзакций, называемую спецификацией GSS-TSIG, которая также основана на совместном секретном ключе. Ключ можно получить через систему Kerberos из центра распределения ключей. Вся прелесть в том, что реализация Kerberos, используемая компанией Microsoft, не совместима с открытой версией Kerberos 5! И как прикажете называть тех, кто все это придумал?

Если нужно работать с Win2K и использовать записи SRV, придется отказаться от существующей системы Kerberos и запустить сервер Win2K Kerberos. Для многих организаций, где вся инфраструктура давно налажена это становится неразрешимой проблемой. Возможно, компания Microsof. разработает какие-то свои расширения.

Через неделю после того, как была выпущена ОС Win2K, число запросов, адресуемых корневым серверам DNS, резко возросло. Проведенные исследования показали, что неправильно сконфигурированные системы Win2K пытались динамически обновить корневые зоны или зоны верхнего уровня. В результате число UDP-запросов к корневому серверу А увеличилось более чем вдвое. Хуже того, когда запросы на обновление заканчивались неудачей системы Win2K открывали TCP-соединение, чтобы запросить запись KEY и попытаться выполнить аутентифицированное динамическое обновление. У корневого сервера нет возможности отвечать на миллионы запросов об установлении TCP-соединения. На момент выхода книги в печать проблема все еще не была разрешена. Операторы корневых серверов тычут пальцами на сотрудников Microsoft, а те говорят: "Нет, нет, это не мы!"



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page