Угрозы транзакциям DNS зависят от типа транзакции. DNS NOTIFY. Как правило, хосты, участвующие в транзакциях зонной пересылки, динамических обновлениях и DNS NOTIFY, находятся внутри одного административного домена. Единственным исключением являются первичный или вторичный name-серверы организации, которые часто расположены у Интернет-провайдера или в других организациях. При этом обычно предполагается наличие заранее существующего отношения доверия между первичным и вторичным name-серверами. Тем не менее возможны случаи, когда потребуется установить тот или иной способ взаимной аутентификации при зонных пересылках DNS.
Обычные запросы и ответы сервиса разрешения имен содержат неподписанные и незашифрованные UDP-пакеты. Возможные угрозы транзакциям
Поддельный или выдуманный ответ – это ответ, который отличается от того, который посылает законный авторитетный name-сервер. Поддельный ответ может быть получен от:
Поддельный ответ может быть создан в результате:
Последствия для систем, которым требуются сервисы name-сервера, имеющего испорченный кэш или скомпрометированный зонный файл:
А, NS, MX ресурсные записи, подделаны, система, которая запрашивает данную информацию, никогда не сможет установить соединение с требуемым хостом.RDATA содержит некоторое имя. Примерами таких записей являются CNAME, NS и MX. Информация разрешения имени (т.е. IP-адрес) для имен, содержащихся в этих записях, отыскивается в множестве ресурсных записей, называемых glue (склеенные) записями. Обычно запрашивающий эту информацию клиент получает склеенные записи с помощью последовательных запросов (также называемых triggered-запросами ). Ответы на такие запросы также могут быть скомпрометированы атакующим с помощью вставки поддельных записей. Атакующий может ввести имена, выбранные им, в часть RDATA ресурсных записей; затем атакующий может вставить IP-адреса серверов (выбранные атакующим) в соответствующие склеенные записи, которые передаются в качестве ответа на последовательные запросы. Данный тип атаки на два множества соответствующих ответов называется атакой на цепочку имен. Общий эффект от этого состоит в неправильном перенаправлении клиентов, которые используют сервисы данного name-сервера. Результатом будет перенаправление пользователей к узлам атакующего, что может дать возможность атакующему перехватить разного рода чувствительную информацию.Кроме вставки поддельных данных в ответ, атакующий может удалить некоторые ресурсные записи из ответа. Результатом будет невозможность выполнить разрешение имени, что приведет в дальнейшем к DoS-атаке.
Ликвидация угрозы, связанной с
Эти сервисы могут быть предоставлены для установления доверия к источнику с помощью проверки подписи данных, посланных источником. Описание использования механизма цифровой подписи в контексте инфраструктуры DNS называется стандартом
После аутентификации источника RRSIG. Клиент DNS, используя
Для гарантии того, что ресурсные записи, указанные в запросе, на самом деле отсутствуют в зонном файле и не были удалены при передаче, механизм NSEC RR, в которой перечислены типы ресурсных записей, связанные с конкретным именем, а также следующее имя в зонном файле. Данная специальная ресурсная запись посылается вместе с подписью для нее к рекурсивному name-серверу. Проверяя данную подпись, поддерживающий
Для защиты от атак некорректного применения правил расширения для wildcard в ресурсных записях механизм NSEC -ресурсной записью, и тем самым проверяет, что name-сервер корректно применил в созданном ответе правила расширения wildcard.
Данные DNS считаются публичными, следовательно, конфиденциальность не является целью безопасности
Зонные пересылки выполняют репликацию зонных файлов на несколько серверов для защиты от сбоев DNS-сервиса. Первая угроза, DoS, является общей для любой сетевой транзакции. Вторая угроза основана на использовании знания, которое получено из информации, указанной в зонных пересылках.
DoS-атака может быть минимизирована, если серверы, которым разрешено делать запросы зонных пересылок, ограничены множеством известных участников. Для конфигурирования подобного множества известных участников в первичном name-сервере должны существовать значения, идентифицирующие этих участников. ПО name-сервера, такое как BIND, предоставляет возможность с помощью конфигурационных опций ограничить запросы зонных пересылок множеством указанных IP-адресов. Однако, поскольку IP-адреса могут быть подделаны, такой способ конфигурации не обеспечивает безопасного ограничения выполнения зонных пересылок.
Динамические обновления означают, что клиенты могут делать изменения в данных зоны авторитетного name-сервера в реальном режиме времени. Клиентами, которые обычно выполняют динамические обновления, являются СА-серверы, DHCP-серверы или Интернет
Угроза Т14 – неавторизованные модификации: неавторизованные модификации могут иметь несколько опасных последствий для содержимого зоны. Это включает:
(i) добавление незаконных ресурсов (новый FQDN и новые ресурсные записи в файл зоны);
(ii) удаление законных ресурсов (весь FQDN или конкретные ресурсные записи);
(iii) изменение информации делегирования (NS-ресурсные записи, ссылающиеся на дочерние зоны).
Угрозы Т14 и Т15 могут быть ликвидированы аутентификацией участников и обеспечением способов определения подделанных сообщений. Так как данные цели безопасности в случае зонной пересылки могут быть решены
DNS NOTIFY является сообщением, посылаемым первичным name-сервером вторичному, которое содержит информацию, что зонный файл изменился и что вторичному name-серверу следует выполнить зонные пересылки для поддержания своих зонных файлов в синхронном состоянии. Так как сообщение NOTIFY является сигнальным, то существует минимальный риск безопасности, связанный с данным сообщением. Считается, что основной риск состоит в следующем:
NOTIFY: вторичные name-серверы могут получить поддельные сообщения DNS NOTIFY из других источников, отличных от первичного name-сервера.Единственным воздействием при получении поддельного сообщения DNS NOTIFY является возрастание нагрузки на первичный и вторичный name-серверы из-за более частых зонных пересылок. Так как происходит небольшое воздействие, подход к обеспечению защиты состоит в конфигурировании вторичного name-сервера для получения сообщения DNS NOTIFY только от конкретного первичного name-сервера.
Просуммируем транзакции DNS и связанные с ними угрозы, цели безопасности и механизмы безопасности, обеспечивающие защиту от этих угроз.
| Транзакция DNS | Угрозы | Цели безопасности | Механизмы безопасности |
|---|---|---|---|
| DNS Query/Response | (a) Изменение или вставка ложного ответа (b) Удаление ресурсных записей в ответах (c) Некорректные правила расширения wildcard |
(a) Аутентификация исходных данных (b) Проверка целостности данных |
|
| Зонная пересылка | (a) DoS-атака (b) Изменение сообщений |
(a) Взаимная аутентификация участников (b) Проверка целостности данных |
|
| Динамическое обновление | (a) Неавторизованные модификации (b) Изменение сообщений (c) |
(a) Взаимная аутентификация участников (b) Проверка целостности данных (c) Подписанные отметки времени |
|
| DNS NOTIFY | (a) Ложные уведомления | (a) Предотвращение DoS-атак, возникающих из-за возрастания нагрузки | Конфигурационные опции |
Создание безопасной конфигурации для окружения DNS-хостинга должно обеспечивать следующее:
Рассмотрим рекомендации для каждого перечисленного выше пункта.
На платформе, на которой выполняется ПО name-сервера, должна быть установлена ОС, удовлетворяющая требованиям безопасности. Большинство инсталляций DNS осуществляется либо на ОС Unix, либо на ОС Windows. В любом случае необходимо гарантировать следующее:
Обеспечение безопасности ПО DNS включает выбор версии, установку последних обновлений, выполнение ПО с ограниченными привилегиями, ограничение других приложений, выполняющихся под управлением данной ОС, создание выделенных экземпляров DNS-сервера для выполнения каждой функции и ограничение информации, раскрываемой данными зонного файла или выполнением двух экземпляров ПО name-серверов, которые обслуживают различные категории клиентов.
Каждая последующая версия ПО name-сервера, (особенно это касается BIND), обычно лишена уязвимостей, найденных в более ранних версиях. Если установлены старые версии, то эти уязвимости могут использоваться атакующим, чтобы осуществить атаку. Таким образом, хорошей практикой считается выполнение самой последней версии BIND, потому что теоретически она самая безопасная. Но даже если используется ПО самой последней версии, небезопасно выполнять его в режиме "по умолчанию". Администратор должен свободно владеть всеми установками безопасности для этой последней версии.
В некоторых случаях невозможен немедленный переход на самую последнюю версию BIND. В этой ситуации следует понять уязвимости, обнаруженные в существующей версии, и использовать соответствующие обновления, относящиеся к безопасности.
Рекомендации:
Выполнить следующие действия:
Если ПО name-сервера выполняется от имени привилегированного пользователя (например, root на Unix-системах), то любая ошибка в ПО может иметь катастрофические последствия для ресурсов, расположенных на той же платформе. Следовательно, необходимо выполнять ПО name-сервера от имени непривилегированного пользователя с ограничением доступа только к указанным директориям, чтобы уменьшить ущерб от возможных ошибок.
Ограничение доступа к другим директориям может быть выполнено с помощью команды chroot в Unix. Такой подход называется выполнением name-сервера в jail (тюрьме). Должна быть выполнена следующая команда:
chroot –u named –g other –t /var/named
где:
-u указывает userID, от имени которого name-сервер будет выполняться после старта. Аккаунт данного пользователя должен быть создан до выполнения команды chroot.
-g указывает
-t указывает директорию, к которой name-сервер будет иметь доступ.
Даже если ПО DNS (например, BIND) выполняется на безопасной ОС, уязвимости в другом ПО на данной платформе могут нарушить безопасность ПО DNS. Следовательно, необходимо гарантировать, что платформа, на которой выполняется ПО DNS, не содержит программ, которые не являются необходимыми для функционирования DNS.
Авторитетный name-сервер обслуживает ресурсные записи своей собственной зоны; данная функция называется авторитетной функцией. Обслуживание ресурсных записей из своего кэша (создавая кэш динамически, используя итеративные запросы) называется рекурсивной функцией. Name-сервер может быть сконфигурирован как авторитетный name-сервер, рекурсивный name-сервер или как и то, и другое одновременно. Так как существуют такие атаки, как порча кэша, то политика безопасности, при которой выполняется рекурсивный name-сервера, отличается от политики безопасности, при которой выполняется авторитетный name-сервер. Следовательно, name-сервер должен всегда быть сконфигурирован либо как авторитетный name-сервер, либо как рекурсивный name-сервер.
Авторитетный name-сервер только обеспечивает разрешение имен для зон, для которых он имеет авторитетную информацию. Следовательно, политика безопасности не должна допускать рекурсию для данного типа name-сервера. Запрещение рекурсии означает невозможность посылки запросов от имени других name-серверов и создания кэша из полученных ответов. В BIND рекурсия запрещается использованием утверждения options в конфигурационном файле:
options {
recursion no;
};
Рекурсивный name-сервер предназначен для обработки запросов от имени клиентов. Таким образом, защита рекурсивных name-серверов может быть обеспечена ограничением конкретных типов транзакций для определенных хостов. Это достигается использованием различных конфигурационных опций.
ПО DNS не должно выполняться или присутствовать на хостах, которые не предназначены для функционирования на них name-серверов. Вероятность такого присутствия существует, потому что ПО DNS BIND во многих версиях Unix (включая версии Solaris и Linux) инсталлировано по умолчанию. Следовательно, необходимо проверить наличие инсталляций BIND на рабочих станциях и серверах и удалить его с тех хостов, которые не предназначены для функционирования в качестве name-серверов.
Большинство предприятий имеют авторитетный первичный name-сервер и авторитетные вторичные name-серверы. Важно, чтобы эти авторитетные name-серверы были расположены в различных сетевых сегментах. Такое расположение гарантирует доступность авторитетного name-сервера не только в ситуациях, когда некоторый роутер или коммутатор (switch) даст сбой, но также и при событиях, включающих атаки на весь сетевой сегмент. В дополнение к сетевому разнесению, авторитетные name-серверы должны быть также разнесены географически. Другими словами, в дополнение к размещению в разных сетевых сегментах, авторитетные name-серверы не должны располагаться в одном и том же здании. Один из подходов состоит в том, что организация размещает некоторые name-серверы в своем здании, а другие у Интернет-провайдера или в организациях партнеров.
Рекомендация:
Авторитетные name-серверы предприятия должны быть как географически распределенными, так и распределенными в смысле сетевой топологии. Сетевая распределенность гарантирует, что все серверы не будут расположены за одним и тем же роутером или коммутатором в одной подсети. Географическая распределенность гарантирует, что не все name-серверы будут находиться в одном и том же физическом месте и в любом случае будет доступен по крайней мере один авторитетный name-сервер.
Авторитетные name-серверы организации получают запросы как от внешних, так и от внутренних клиентов. Во многих случаях внешние клиенты должны получать ресурсные записи, которые относятся только к публичным сервисам, таким, как web-сервер, почтовый сервер и т.п. Внутренние клиенты должны получать ресурсные записи, которые относятся как к публичным сервисам, так и к внутренним хостам. Следовательно, зонная информация, которая содержит эти ресурсные записи, может быть разделена на два представления, каждое из которых заключает в себе информацию, предназначенную для определенного типа клиентов: один для внешних клиентов, другой – для внутренних. Такой способ реализации зонного файла называется split DNS.
Рекомендация:
Для реализации split DNS должно быть как минимум два представления, еще называемых views. Одно должно содержать информацию, предназначенную исключительно для разрешения имен для хостов, которые расположены в локальной сети. Оно также может содержать множества ресурсных записей для обслуживания запросов из внешней сети. Другое представление или view должно обеспечивать разрешение имен только для хостов, расположенных во внешней сети или в DMZ, и не предоставлять данный сервис ни для каких хостов, расположенных во внутренней сети.
Для конфигурирования split DNS в BIND следует использовать специальное утверждение в конфигурационном файле BIND. Например, для конфигурирования авторитетного view в зоне sales.mycom.ru для внутренних хостов следует использовать утверждение
view "insider" {
match-clients { internal_hosts; };
recursion yes;
zone sales.mycom.ru {
type master;
file "sales_internal.db";
};
};
В данном утверждении указывается, что файл sales_internal.db содержит авторитетную информацию для зоны sales.mycom.ru, и вводится ограничение, что данная информация может быть запрошена со списка адресов, перечисленных в internal_hosts. Как задать данный список, будет объяснено ниже. Чтобы сконфигурировать view в некоторой зоне только для обслуживания запросов от внешних хостов, используется следующее утверждение в конфигурационном файле:
view "outsider" {
match-clients { any };
match-destination { public_hosts; };
recursion no;
zone sales.mycom.ru {
type master;
file "sales.external.db";
};
};
Данное утверждение очень похоже на предыдущее, за исключением того, что файл с view зоны есть sales.external.db и список клиентов указан как any, — это означает, что запросы могут быть как извне, так и изнутри сети. Вместе эти утверждения позволяют внутренним клиентам видеть как внутренние, так и внешние хосты, а внешние хосты, расположенные вне данной сети, могут видеть только информацию DNS, содержащуюся во внешнем view зоны, где адрес получателя соответствует адресам, перечисленным в public_host.
Вместо того чтобы иметь одно и то же множество авторитетных name-серверов, обслуживающих различные типы клиентов, можно развернуть два различных множества авторитетных name-серверов. Одно множество, называемое external name-серверы, может быть расположено внутри DMZ; это должны быть только те name-серверы, которые доступны внешним клиентам и которые содержат ресурсные записи, относящимся к хостам с публично доступными сервисами (web-серверы, которые обрабатывают внешние web-страницы или предоставляют В2С-сервисы, почтовые серверы и т.п.). Другое множество, называемое internal name-серверы, расположено за firewall’ом и должно быть сконфигурировано таким образом, чтобы эти серверы не были доступны извне и, следовательно, предоставляли сервисы разрешения имен исключительно для внутренних клиентов. Целью обеих архитектур (т.е. создания двух различных множеств name-серверов и split DNS) является предотвращение раскрытия IP-адресов внутренних хостов.
Как уже отмечалось, для управления содержимым зонного файла должен использоваться подход, обеспечивающий защиту на уровне ОС, с использованием различных инструментальных средств проверки целостности. Эффективность этих средств зависит от возможностей, имеющихся в них. Следовательно, процесс развертывания состоит из разработки правильных ограничений и определения правильных значений некоторых ключевых полей различных типов ресурсных записей.
Ранее были перечислены угрозы, цели безопасности и способы обеспечения защиты для различных транзакций DNS. Сейчас рассмотрим шаги, необходимые для реализации этих способов защиты. Перечислим типы способов обеспечения защиты:
DNS NOTIFY, для которой существует только угроза ложного уведомления, управление доступом, основанное на IP-адресе, вполне приемлемо. Хотя данное решение и не рекомендуется в общем случае, описание механизмов управления доступом, использующих IP-адреса, будет приведено далее, потому что аналогичные утверждения применяются для идентификации хостов на основе поименованных ключей, которые реализуют защиту транзакций, используя коды аутентификации сообщений (МАС), основанные на хэшах. Данный подход реализован для всех транзакций DNS.Некоторые реализации name-сервера, такие как BIND 9.x, предоставляют утверждения для управления доступом, с помощью которых можно указать хосты, которые могут участвовать в конкретной DNS-транзакции. Хосты могут быть указаны по их IP-адресам или указанием их IP-подсети (называемой IP-префиксом ) в данных утверждениях.
Список, содержащий эти IP-адреса и/или IP-префиксы, называется списком соответствия адресов. Список соответствия адресов может быть создан на основе не только IP-адресов, но и IP-префиксов. Этот список используется в качестве аргумента в различных утверждениях управления доступом, которые определены в конфигурационных файлах BIND. Существуют отдельные утверждения управления доступом для каждого типа транзакции DNS. Синтаксис таких утверждений и транзакции DNS, для которых они используются, приведен ниже.
| Синтаксис утверждения управления доступом | Транзакция DNS |
|---|---|
| allow-query {address_match_list } | DNS Query/Response |
| allow-recursion {address_match_list } | |
| allow-transfer {address_match_list } | Зонная пересылка |
| allow-update {address_match_list } | Динамическое обновление |
| allow-update-forwarding {address_match_list } | Динамическое обновление |
| allow-notify (address_match_list } | DNS NOTIFY |
| blackhole {address_match_list } | Хосты, попавшие в черный список |
Цель каждого из этих утверждений управления доступом состоит в следующем:
allow-query: указывает список хостов, которым разрешено запрашивать все зоны name-сервера или конкретную зону внутри name-сервера.allow-recursion: указывает список хостов, которым разрешено создавать allow-transfer: указывает список хостов, которым разрешено инициировать запросы зонной пересылки к name-серверу для всех зон или для конкретной зоны внутри name-сервера. Данное утверждение обязательно требуется в конфигурации первичного name-сервера.allow-update: указывает список хостов, которым разрешено инициировать запросы динамического обновления.allow-update-forwarding: указывает список хостов, которым разрешено перенаправление запросов динамического обновления (независимо от того, кто является источником запроса).allow-notify: указывает список хостов, с которых можно принимать сообщения DNS NOTIFY, говорящих об изменениях в зонном файле. Данный список относится только к конфигурации вторичного name-сервера.blackhole: указывает список хостов, которые входят в черный список (запрещен доступ) для инициализации любых транзакций с данным name-сервером.Перечисленные утверждения управления доступом являются в действительности подутверждениями, которые могут использоваться в контексте утверждений options и zone в конфигурационном файле named.conf в BIND 9.x. Когда они используются внутри утверждения zone, они определяют ограничения управления доступом для соответствующей транзакции для указанной зоны. Когда они используются как часть утверждения options, они определяют ограничения управления доступом для соответствующей транзакции для всего name-сервера, который может обслуживать несколько зон.
Рассмотрим пример использования подутверждения allow-query для указания ограничений для транзакции Query / Response, определяя допустимые IP-адреса / подсети в запросах DNS) как на уровне сервера, так и на уровне зоны (для зоны example.ru ):
options {
allow-query {254.10.20.10; 239.10.30.0/24; };
};
zone "example.ru." {
type master;
file "zonedb.example.ru";
allow-query {192.249.249.1; 192.249.249.4; };
};
Указывая список IP-адресов или IP-префиксов внутри утверждений options или zone, можно внести путаницу в конфигурационный файл. Более того, список IP-адресов и IP-префиксов может быть одним и тем же для многих утверждений управления доступом внутри name-сервера, и ошибка может возникнуть, если сделано какое-то одно добавление или удаление в данный список. Чтобы избежать таких проблем, в BIND существует способ создания поименованных списков адресов, которые называются access control lists (ACLs). Эти ACLs могут использоваться в тех местах, где допустимо использование списка IP-адресов или IP-префиксов (в качестве аргумента списка соответствующих адресов) в утверждениях управления доступом.
ACLs создаются с использованием утверждения acl в BIND 9.х. Общий синтаксис утверждения acl следующий:
acl acl-list-name {
address_match_list
};
acl-list-name есть определенная пользователем строка (например, "internal_hosts"). Address_match_list может быть списком IP-адресов, префиксами IP-адресов (обозначающих подсети) или криптографическими ключами. Пример утверждения acl, который использует IP-адрес и подсеть в address_match_list, приведен ниже. В примере 254.10.20.10 обозначает IP-адрес хоста, IP-префикс 239.10.30.0/24 обозначает подсеть класса С.
acl "internal_hosts" {
254.10.20.10;
239.10.30.0/24;
};
Можно использовать ACL internal_hosts в тех местах, где используется список IP-адресов или IP-префиксов в утверждениях options и zone следующим образом:
options {
allow-query { internal_hosts; };
};
zone "example.ru." {
type master;
file "zonedb.example.ru";
allow-query { internal_hosts; };
};
Параметр списка соответствующих адресов в утверждении управления доступом может содержать любое из следующих значений:
Определение ACLs является важным элементом при конфигурировании ограничений транзакций DNS. Следовательно, администратор первым делом должен задать ACLs, относящиеся к различным транзакциям DNS.
Рекомендация:
Необходимо, чтобы администратор создал поименованный список доверенных хостов (или черный список хостов) для каждого типа транзакций DNS. В общем случае следует рассмотреть следующие категории хостов для включения их в соответствующий ACL:
Дополнительно к IP-адресам, IP-префиксам или ACL, параметр списка соответствующих адресов в утверждениях управления доступом может принимать следующие специальные значения:
none: нет соответствующих хостов;any: все хосты;localhost: соответствует всем IP-адресам сервера, на котором выполняется name-сервер.localnets: соответствует всем IP-адресам и маскам подсетей сервера, на котором выполняется name-сервер.Приведем несколько примеров команд для создания ACLs и использования ACLs в утверждениях options и zone:
acl "local_hosts" {
254.10.20.10;
239.10.30.0/24;
};
acl "fake-net" {
0.0.0.0/8;
1.0.0.0/8;
};
options {
allow-query { any; };
blackhole { fake-net; };
};
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-query {local_hosts; };
};
Во фрагменте named.conf, приведенном выше, определены два ACLs, local_hosts и fake_net. На уровне сервера разрешены DNS-запросы с любого хоста. Никакие транзакции не разрешены с хостов, включенных в fake-net. Запросы для зоны example.ru могут быть инициированы только хостами, включенными в ACL local_hosts, потому что любое ограничение, указанное в утверждении zone, перекрывает ограничение, указанное в утверждении options.
Авторитетный name-сервер обеспечивает сервис разрешения имен для клиента, исходя из своих собственных данных. Следовательно, конфигурирование авторитетного name-сервера должно быть сделано таким образом, чтобы он мог принимать запросы от любых хостов. Обеспечение безопасности авторитетного name-сервера состоит в выключении возможности рекурсивного запроса, чтобы этот сервер не испортил свой кэш, запрашивая другие (возможно, скомпрометированные) name-серверы. Локальный рекурсивный name-сервер может быть сконфигурирован таким образом, чтобы принимать запросы только от внутренних хостов, что защитит его от DoS-атак, а также от порчи кэша. Однако возможны ситуации, когда экономически нежелательно иметь выделенные серверы для авторитетного сервиса и сервиса разрешения имен, и рекурсивный name-сервер должен выполняться как авторитетный сервер для одной или более зон. В такой ситуации возможны следующие стратегии с использованием BIND 9.х name-сервера:
views.Ограничение на уровне сервера с перекрытием для авторитетных зон
В этом случае определяется допустимое множество внутренних клиентов, которые могут передавать запросы к name-серверу. Для этого соответствующее acl утверждение таково:
acl "internal_hosts" { 192.158.43.3, 192.158.43.6, 192.158.44.56; };
Опцией на уровне сервера следует указать ограничение, чтобы запросы могли исходить только от данных клиентов:
options {
allow_query { internal_hosts; };
};
Опция может быть перекрыта указанием зон, для которых данный name-сервер является авторитарным (тем самым разрешая запросы, касающиеся ресурсов в данной зоне от всех клиентов):
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow_query { any; };
};
Ограничение всех рекурсивных запросов конкретным множеством IP-адресов
Ограничение на уровне сервера:
options {
allow_recursion { internal_hosts; };
};
Ограничение рекурсии с помощью views
Цель создания views состоит в логической комбинации клиентов (на основе IP-адресов) и зон, для которых будут поддерживаться recursion_view дает возможность определить область IP-адресов и зон, которым разрешено передавать no_recursion_view означает запрещение рекурсии.
view recursion_view {
match-clients ( internal_hosts; };
recursion yes;
};
view no_recursion_view {
match-client { any; };
recursion no;
};
Авторитетные name-серверы (особенно первичные) должны быть сконфигурированы с утверждением управления доступом allow-transfer, содержащим список хостов, с которых запросы зонной пересылки могут приниматься. Это ограничивает DoS-атаки и использование возможных ошибок (allow-transfer должен состоять из IP-адресов вторичных name-серверов, которые указаны в NS множества ресурсных записей, и "невидимых" вторичных name-серверов, которые указаны только в этом подутверждении.
Команда для создания ACL valid_secondary_NS с IP-адресами трех вторичных name-серверов следующая:
acl "valid_secondary_NS" {
224.10.229.5;
224.10.235.6;
224.10.245.25;
};
Подутверждение allow-transfer может быть использовано в утверждении zone и в утверждении options. Если оно используется в утверждении zone, то ограничивает зонную пересылку для данной зоны; если используется в утверждении options, ограничивает зонную пересылку для всех зон в name-сервере.
Подутверждение allow-transfer на уровне сервера является следующим:
options {
allow-transfer { valid_secondary_NS; };
};
Подутверждение allow-transfer на уровне зоны является следующим:
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-transfer { valid_secondary_NS; };
};
Предыдущие утверждения используются на первичных name-серверах. На вторичных и невидимых name-серверах зонная пересылка должна быть запрещена, как показано ниже:
zone "example.ru" {
type slave;
masters { 224.239.5.1 };
file "zonedb_bak.example.ru";
allow-transfer { none; };
};
Динамические обновления зонного файла могут осуществляться только для зонного файла, находящегося на первичном name-сервере зоны. По умолчанию динамические обновления отключены как в BIND 8, так и в BIND 9. Динамические обновления управляются использованием одного из следующих двух утверждений в BIND:
allow-update ;update-policy (доступно только в версиях BIND 9).Эти утверждения могут быть указаны только на уровне зоны, а не на уровне сервера. Следовательно, они являются подутверждениями внутри утверждения zone. Подутверждение allow-update дает возможность указать ограничения динамического обновления на основе IP-адресов и разделяемого секрета (также называемого allow-update с помощью указания только IP-адресов, а затем — использование утверждения allow-update с
Утверждение update-policy дает возможность указать ограничения динамического обновления только на основе allow-update определяет права доступа, касающиеся модификаций, ко всем записям в зоне. Подутверждение update-policy может быть использовано для ограничения прав доступа по модификации к одному или более типам ресурсных записей (например, A ресурсные записи).
Для использования утверждения allow-update должен быть создан список соответствующих адресов. Команда для создания ACL DU_Allowed_List с одним IP-адресом следующая:
acl "DU_Allowed_List" {
192.249.12.21;
};
ACL DU_Allowed_List (содержащий IP-адреса хостов, которым разрешено посылать запросы динамического обновления для изменения содержимого зоны example.ru ) используется внутри подутверждения allow-update утверждения zone следующим образом:
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-update { DU_Allowed_List; };
};
Запросы динамического обновления обычно исходят от таких хостов, как DHCP-серверы, которые динамически связывают IP-адреса с хостами. После того, как они назначат IP-адрес новому хосту, им нужно сохранить информацию отображения доменного имени на IP-адрес (созданием A ресурсной записи) и отображения адреса на доменное имя (созданием PTR ресурсной записи) в первичном авторитетном name-сервере для зоны. Создание данной информации происходит посредством динамических обновлений.
После того как зонные пересылки между серверами установлены, хорошо бы гарантировать, что вторичные name-серверы будут информироваться об изменениях в данных зонного файла посредством получения уведомления. По умолчанию сообщение уведомления посылается всякий раз, когда первичный name-сервер определил, что было сделано изменение в зонном файле. Он посылает сообщение DNS NOTIFY каждому name-серверу, перечисленному в NS -множестве ресурсных записей в зоне, потому что эти серверы считаются вторичными name-серверами зоны. Администратор DNS должен оставить выполнение этой транзакции, потому что это позволяет быстро распространять обновления на вторичные name-серверы. Однако, если администратор хочет выключить данную функциональность для конкретной зоны, следует использовать подутверждение notify в утверждении zone для данной зоны:
zone "example.ru" {
type master;
notify no;
file "zonedb.example.ru";
};
Если существуют дополнительные серверы, на которые администратор хочет посылать сообщение DNS NOTIFY (например, "невидимый" вторичный сервер), должно быть добавлено подутверждение also-notify в утверждение zone, и IP-адреса дополнительных серверов должны быть указаны в качестве значений параметров следующим образом:
zone "example.ru" {
type master;
also-notify { 192.168.25.2; };
file "zonedb.example.ru";
};
Получатель сообщения DNS NOTIFY, которым является вторичный name-сервер, по умолчанию разрешает получать сообщения уведомления только от первичного name-сервера. То, что данный name-сервер является вторичным для первичного name-сервера, указывается посредством подутверждения masters в утверждении zone. Если вторичный name-сервер хочет получать сообщения уведомления также и от других серверов, следует добавить подутверждение allow-notify в утверждение zone, и соответствующие IP-адреса этих серверов:
zone "example.ru" {
type slave;
allow-notify { 193.168.25.4; };
file "zonebak.example.ru";
masters { 192.168.25.1; };
};
Процесс аутентификации источника сообщения и обеспечение целостности сообщения с помощью
Функция
Хэш-алгоритм создает МАС фиксированной длины из сообщения произвольной длины. Функция
Защита транзакции посредством
МАС, создаваемый отправителем DNS-сообщения, помещается в новую ресурсную запись, называемую
timestamp );Поле timestamp указывает время, когда был создан МАС. Цель данного поля состоит в защите от
Для того чтобы обеспечить безопасность транзакции на основе МАС, отправитель вычисляет хэш от всего DNS-сообщения и секретного ключа и записывает результат в
Указание имени ключа в записи timestamp в записи timestamp состоит в предотвращении
Процесс верификации состоит в извлечении соответствующего секретного ключа, вычислении хэша от полученного сообщения и секретного ключа, и сравнении вычисленного хэша с полученным хэшем (в
В BIND версии 8.2 были впервые введены возможности
Для того чтобы была возможность транзакциям DNS использовать
Чтобы обеспечить возможность выполнять аутентификацию зонных пересылок (запросов и ответов), необходимо создать ключи для каждой пары name-серверов. Ключ также может использоваться для обеспечения безопасности других транзакций, таких как динамические обновления, запросы и ответы DNS. Битовая строка ключа, которая создается большинством утилит генерации ключа, используемых с
dnssec-keygen –a HMAC-MD5 –b 128 –n HOST ns1-ns2.example.ru
где параметры команды означают следующее:
-a: название алгоритма хэширования, который будет использоваться (HMAC-MD5).
-b: длина ключа (128 бит).
-n: тип ключа (HOST).
Последний параметр: имя ключа ( ns1-ns2.example.ru ).
Программа
Kns1-ns2.example.ru.+157+34567.key Kns1-ns2.example.ru.+157.34567.private
Когда программа создает пару ключей (открытый и закрытый), файл с расширением key будет содержать строку открытого ключа, а файл с расширением private будет содержать закрытый ключ. Так как в нашем случае создается только секретный ключ, строки ключа в обоих файлах будут одинаковыми. Строка ключа из любого из этих файлов затем копируется в файл, называемый файлом ключа. Данный файл указывается в утверждении include внутри утверждения key.
Ключ, созданный с использованием утилиты
key "ns1-ns2.example.ru." {
algorithm hmac-md5;
include "/var/named/keys/secretkey.conf";
};
где файл secretkey.conf содержит слово secret и реальную строку ключа:
secret "Mdkhhladasdka;"
В каждом конфигурационном файле пары серверов, которые разделяют секретный ключ в зоне, должно быть указано имя ключа, используемого во всех коммуникациях между ними (с помощью утверждения server в конфигурационном файле).
Команда для указания серверу использовать ключ во всех транзакциях (запрос / ответ DNS, зонная пересылка, динамическое обновление и т.п.) следующая:
server 192.249.249.1 {
keys { ns1-ns2.example.ru.; };
};
где параметр keys является именем ключа.
Подведем итоги:
dnssec -keygen /etc/named.conf для BIND, выполняющихся на Unix), которое описывает include в утверждении key в конфигурационном файле. Каждый Для пары серверов, участвующих в транзакциях зонных пересылок, указывается, что они должны использовать ключ, определенный в утверждении key. Такая пара обычно состоит из первичного name-сервера и вторичного name-сервера. Первичный name-сервер конфигурируется таким образом, чтобы принимать запросы зонной пересылки только от вторичных name-серверов, которые посылают МАС с использованием поименованного ключа, передаваемого в сообщении запроса зонной пересылки. Конфигурация создается с использованием подутверждения allow-transfer в утверждении zone. Пример подутверждения allow-transfer, которое указывает, что первичный name-сервер должен разрешать запросы зонной пересылки только для зоны example.ru от name-серверов, использующих ns1-ns2.example.ru ключ, выглядит следующим образом:
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-transfer { key {ns1-ns2.example.ru}; };
};
Вторичному name-серверу указывается использовать ключ ns1-ns2.example.ru в запросе зонной пересылки к первичному name-серверу, задействуя утверждение server.
Ограничения динамических обновлений, основанные на ключах allow-update утверждения zone. Аргументом данного утверждения является ключевое слово key, за которым следует имя
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-update { key {dhcp-server.example.ru.}; };
};
Заметим, что, хотя строка dhcp-server.example.ru. выглядит как FQDN, на самом деле она обозначает имя dhcp-server.example.ru., может посылать запросы динамического обновления (добавления, удаления или модификации ресурсных записей) зонного файла (для зоны example.ru ), который расположен на первичном авторитетном name-сервере.
Динамическим обновлениям разрешено копирование зонного файла на первичный авторитетный name-сервер только потому, что он является "allow-update-forwarding в версии BIND, которые имеют возможность перенаправления динамических обновлений. Пример такого allow-update-forwarding утверждения с использованием
zone "example.ru" {
type slave;
file "backupdb.example.ru";
allow-update-forwarding { key {dhcp-server.example.ru.}; };
};
Подутверждение allow-update определяет ограничения динамического обновления, которые основаны на отправителях запросов динамических обновлений (конкретное множество хостов, идентифицируемых по IP-адресу или обладающих grant или deny ) к динамическим обновлениям, основанным на комбинации имен домена или поддомена и типов ресурсных записей ( A, MX, NS и т.п.), BIND 9 и более поздние версии предоставляют подутверждение update-policy в утверждении zone. Эти ограничения в подутверждении update-policy основаны на update-policy указывает, каким
Общая форма update-policy утверждения следующая:
update-policy {
(grant | deny) TSIGkey nametype name [type]
};
где семантика каждого компонента утверждения такова:
grant / deny – разрешить / запретить динамическое обновление для комбинации, которая следует далее.TSIGkey – имя nametype – может быть одним из следующих значений, с соответствующей семантикой:
name – ограничение, применяемое к имени домена, которое указано в следующем поле name.subdomain name.wildcard – ограничение, применяемое к множеству доменов, которые указаны с использованием wildcard синтаксиса (например, *) в следующем поле name.self – ограничение, применяемое к домену, который является тем же самым, что и в поле TSIGkey (например, имя домена, чьи записи являются модифицируемыми, такое же, что и у ключа, используемого для аутентификации запроса динамического обновления). При таком использовании содержимое поля name становится лишним, но, тем не менее, должно использоваться в утверждении (т.е. поле name не может быть пустым).name – применяется для указания имени домена. Используемый синтаксис и домены, которые указывает данный параметр, основаны на значении, заданном в поле nametype (например, если поддомен является значением поля nametype, то все поддомены используемого имени домена охватываются данным утверждением).type – необязательное поле, которое может содержать любой существующий тип ресурсных записей (за исключением NSEC -типа) или wildcard тип ANY ( ANY означает все типы ресурсных записей, за исключением NSEC -типа). Если параметр опущен, то это означает все типы ресурсных записей, за исключением SOA, NS, RRSIG и NSEC. Также возможно использование нескольких типов ресурсных записей, разделенных пробелами (например, A NS ).Примеры update-policy утверждений и связанная с ними семантика приведены ниже.
Предположим, что существует домен sales.example.ru внутри example.ru и что name-сервер использует sales.example.ru ). Все динамические обновления от sales.example.ru могут быть ограничены ко всем ресурсным записям данного домена следующим образом:
zone "example.ru" {
type master;
file "zonedb.example.ru";
update-policy { grant sales.example.ru. self sales.example.ru.; };
};
Все динамические обновления от sales.example.ru могут быть ограничены только типами ресурсных записей A и MX данного домена следующим образом:
zone "example.ru" {
type master;
file "zonedb.example.ru";
update-policy {
grant sales.example.ru. self sales.example.ru. A MX; };
};
Угрозы транзакциям DNS зависят от типа транзакции. DNS NOTIFY. Как правило, хосты, участвующие в транзакциях зонной пересылки, динамических обновлениях и DNS NOTIFY, находятся внутри одного административного домена. Единственным исключением являются первичный или вторичный name-серверы организации, которые часто расположены у Интернет-провайдера или в других организациях. При этом обычно предполагается наличие заранее существующего отношения доверия между первичным и вторичным name-серверами. Тем не менее возможны случаи, когда потребуется установить тот или иной способ взаимной аутентификации при зонных пересылках DNS.
Обычные запросы и ответы сервиса разрешения имен содержат неподписанные и незашифрованные UDP-пакеты. Возможные угрозы транзакциям
Поддельный или выдуманный ответ – это ответ, который отличается от того, который посылает законный авторитетный name-сервер. Поддельный ответ может быть получен от:
Поддельный ответ может быть создан в результате:
Последствия для систем, которым требуются сервисы name-сервера, имеющего испорченный кэш или скомпрометированный зонный файл:
А, NS, MX ресурсные записи, подделаны, система, которая запрашивает данную информацию, никогда не сможет установить соединение с требуемым хостом.RDATA содержит некоторое имя. Примерами таких записей являются CNAME, NS и MX. Информация разрешения имени (т.е. IP-адрес) для имен, содержащихся в этих записях, отыскивается в множестве ресурсных записей, называемых glue (склеенные) записями. Обычно запрашивающий эту информацию клиент получает склеенные записи с помощью последовательных запросов (также называемых triggered-запросами ). Ответы на такие запросы также могут быть скомпрометированы атакующим с помощью вставки поддельных записей. Атакующий может ввести имена, выбранные им, в часть RDATA ресурсных записей; затем атакующий может вставить IP-адреса серверов (выбранные атакующим) в соответствующие склеенные записи, которые передаются в качестве ответа на последовательные запросы. Данный тип атаки на два множества соответствующих ответов называется атакой на цепочку имен. Общий эффект от этого состоит в неправильном перенаправлении клиентов, которые используют сервисы данного name-сервера. Результатом будет перенаправление пользователей к узлам атакующего, что может дать возможность атакующему перехватить разного рода чувствительную информацию.Кроме вставки поддельных данных в ответ, атакующий может удалить некоторые ресурсные записи из ответа. Результатом будет невозможность выполнить разрешение имени, что приведет в дальнейшем к DoS-атаке.
Ликвидация угрозы, связанной с
Эти сервисы могут быть предоставлены для установления доверия к источнику с помощью проверки подписи данных, посланных источником. Описание использования механизма цифровой подписи в контексте инфраструктуры DNS называется стандартом
После аутентификации источника RRSIG. Клиент DNS, используя
Для гарантии того, что ресурсные записи, указанные в запросе, на самом деле отсутствуют в зонном файле и не были удалены при передаче, механизм NSEC RR, в которой перечислены типы ресурсных записей, связанные с конкретным именем, а также следующее имя в зонном файле. Данная специальная ресурсная запись посылается вместе с подписью для нее к рекурсивному name-серверу. Проверяя данную подпись, поддерживающий
Для защиты от атак некорректного применения правил расширения для wildcard в ресурсных записях механизм NSEC -ресурсной записью, и тем самым проверяет, что name-сервер корректно применил в созданном ответе правила расширения wildcard.
Данные DNS считаются публичными, следовательно, конфиденциальность не является целью безопасности
Зонные пересылки выполняют репликацию зонных файлов на несколько серверов для защиты от сбоев DNS-сервиса. Первая угроза, DoS, является общей для любой сетевой транзакции. Вторая угроза основана на использовании знания, которое получено из информации, указанной в зонных пересылках.
DoS-атака может быть минимизирована, если серверы, которым разрешено делать запросы зонных пересылок, ограничены множеством известных участников. Для конфигурирования подобного множества известных участников в первичном name-сервере должны существовать значения, идентифицирующие этих участников. ПО name-сервера, такое как BIND, предоставляет возможность с помощью конфигурационных опций ограничить запросы зонных пересылок множеством указанных IP-адресов. Однако, поскольку IP-адреса могут быть подделаны, такой способ конфигурации не обеспечивает безопасного ограничения выполнения зонных пересылок.
Динамические обновления означают, что клиенты могут делать изменения в данных зоны авторитетного name-сервера в реальном режиме времени. Клиентами, которые обычно выполняют динамические обновления, являются СА-серверы, DHCP-серверы или Интернет
Угроза Т14 – неавторизованные модификации: неавторизованные модификации могут иметь несколько опасных последствий для содержимого зоны. Это включает:
(i) добавление незаконных ресурсов (новый FQDN и новые ресурсные записи в файл зоны);
(ii) удаление законных ресурсов (весь FQDN или конкретные ресурсные записи);
(iii) изменение информации делегирования (NS-ресурсные записи, ссылающиеся на дочерние зоны).
Угрозы Т14 и Т15 могут быть ликвидированы аутентификацией участников и обеспечением способов определения подделанных сообщений. Так как данные цели безопасности в случае зонной пересылки могут быть решены
DNS NOTIFY является сообщением, посылаемым первичным name-сервером вторичному, которое содержит информацию, что зонный файл изменился и что вторичному name-серверу следует выполнить зонные пересылки для поддержания своих зонных файлов в синхронном состоянии. Так как сообщение NOTIFY является сигнальным, то существует минимальный риск безопасности, связанный с данным сообщением. Считается, что основной риск состоит в следующем:
NOTIFY: вторичные name-серверы могут получить поддельные сообщения DNS NOTIFY из других источников, отличных от первичного name-сервера.Единственным воздействием при получении поддельного сообщения DNS NOTIFY является возрастание нагрузки на первичный и вторичный name-серверы из-за более частых зонных пересылок. Так как происходит небольшое воздействие, подход к обеспечению защиты состоит в конфигурировании вторичного name-сервера для получения сообщения DNS NOTIFY только от конкретного первичного name-сервера.
Просуммируем транзакции DNS и связанные с ними угрозы, цели безопасности и механизмы безопасности, обеспечивающие защиту от этих угроз.
| Транзакция DNS | Угрозы | Цели безопасности | Механизмы безопасности |
|---|---|---|---|
| DNS Query/Response | (a) Изменение или вставка ложного ответа (b) Удаление ресурсных записей в ответах (c) Некорректные правила расширения wildcard |
(a) Аутентификация исходных данных (b) Проверка целостности данных |
|
| Зонная пересылка | (a) DoS-атака (b) Изменение сообщений |
(a) Взаимная аутентификация участников (b) Проверка целостности данных |
|
| Динамическое обновление | (a) Неавторизованные модификации (b) Изменение сообщений (c) |
(a) Взаимная аутентификация участников (b) Проверка целостности данных (c) Подписанные отметки времени |
|
| DNS NOTIFY | (a) Ложные уведомления | (a) Предотвращение DoS-атак, возникающих из-за возрастания нагрузки | Конфигурационные опции |
Создание безопасной конфигурации для окружения DNS-хостинга должно обеспечивать следующее:
Рассмотрим рекомендации для каждого перечисленного выше пункта.
На платформе, на которой выполняется ПО name-сервера, должна быть установлена ОС, удовлетворяющая требованиям безопасности. Большинство инсталляций DNS осуществляется либо на ОС Unix, либо на ОС Windows. В любом случае необходимо гарантировать следующее:
Обеспечение безопасности ПО DNS включает выбор версии, установку последних обновлений, выполнение ПО с ограниченными привилегиями, ограничение других приложений, выполняющихся под управлением данной ОС, создание выделенных экземпляров DNS-сервера для выполнения каждой функции и ограничение информации, раскрываемой данными зонного файла или выполнением двух экземпляров ПО name-серверов, которые обслуживают различные категории клиентов.
Каждая последующая версия ПО name-сервера, (особенно это касается BIND), обычно лишена уязвимостей, найденных в более ранних версиях. Если установлены старые версии, то эти уязвимости могут использоваться атакующим, чтобы осуществить атаку. Таким образом, хорошей практикой считается выполнение самой последней версии BIND, потому что теоретически она самая безопасная. Но даже если используется ПО самой последней версии, небезопасно выполнять его в режиме "по умолчанию". Администратор должен свободно владеть всеми установками безопасности для этой последней версии.
В некоторых случаях невозможен немедленный переход на самую последнюю версию BIND. В этой ситуации следует понять уязвимости, обнаруженные в существующей версии, и использовать соответствующие обновления, относящиеся к безопасности.
Рекомендации:
Выполнить следующие действия:
Если ПО name-сервера выполняется от имени привилегированного пользователя (например, root на Unix-системах), то любая ошибка в ПО может иметь катастрофические последствия для ресурсов, расположенных на той же платформе. Следовательно, необходимо выполнять ПО name-сервера от имени непривилегированного пользователя с ограничением доступа только к указанным директориям, чтобы уменьшить ущерб от возможных ошибок.
Ограничение доступа к другим директориям может быть выполнено с помощью команды chroot в Unix. Такой подход называется выполнением name-сервера в jail (тюрьме). Должна быть выполнена следующая команда:
chroot –u named –g other –t /var/named
где:
-u указывает userID, от имени которого name-сервер будет выполняться после старта. Аккаунт данного пользователя должен быть создан до выполнения команды chroot.
-g указывает
-t указывает директорию, к которой name-сервер будет иметь доступ.
Даже если ПО DNS (например, BIND) выполняется на безопасной ОС, уязвимости в другом ПО на данной платформе могут нарушить безопасность ПО DNS. Следовательно, необходимо гарантировать, что платформа, на которой выполняется ПО DNS, не содержит программ, которые не являются необходимыми для функционирования DNS.
Авторитетный name-сервер обслуживает ресурсные записи своей собственной зоны; данная функция называется авторитетной функцией. Обслуживание ресурсных записей из своего кэша (создавая кэш динамически, используя итеративные запросы) называется рекурсивной функцией. Name-сервер может быть сконфигурирован как авторитетный name-сервер, рекурсивный name-сервер или как и то, и другое одновременно. Так как существуют такие атаки, как порча кэша, то политика безопасности, при которой выполняется рекурсивный name-сервера, отличается от политики безопасности, при которой выполняется авторитетный name-сервер. Следовательно, name-сервер должен всегда быть сконфигурирован либо как авторитетный name-сервер, либо как рекурсивный name-сервер.
Авторитетный name-сервер только обеспечивает разрешение имен для зон, для которых он имеет авторитетную информацию. Следовательно, политика безопасности не должна допускать рекурсию для данного типа name-сервера. Запрещение рекурсии означает невозможность посылки запросов от имени других name-серверов и создания кэша из полученных ответов. В BIND рекурсия запрещается использованием утверждения options в конфигурационном файле:
options {
recursion no;
};
Рекурсивный name-сервер предназначен для обработки запросов от имени клиентов. Таким образом, защита рекурсивных name-серверов может быть обеспечена ограничением конкретных типов транзакций для определенных хостов. Это достигается использованием различных конфигурационных опций.
ПО DNS не должно выполняться или присутствовать на хостах, которые не предназначены для функционирования на них name-серверов. Вероятность такого присутствия существует, потому что ПО DNS BIND во многих версиях Unix (включая версии Solaris и Linux) инсталлировано по умолчанию. Следовательно, необходимо проверить наличие инсталляций BIND на рабочих станциях и серверах и удалить его с тех хостов, которые не предназначены для функционирования в качестве name-серверов.
Большинство предприятий имеют авторитетный первичный name-сервер и авторитетные вторичные name-серверы. Важно, чтобы эти авторитетные name-серверы были расположены в различных сетевых сегментах. Такое расположение гарантирует доступность авторитетного name-сервера не только в ситуациях, когда некоторый роутер или коммутатор (switch) даст сбой, но также и при событиях, включающих атаки на весь сетевой сегмент. В дополнение к сетевому разнесению, авторитетные name-серверы должны быть также разнесены географически. Другими словами, в дополнение к размещению в разных сетевых сегментах, авторитетные name-серверы не должны располагаться в одном и том же здании. Один из подходов состоит в том, что организация размещает некоторые name-серверы в своем здании, а другие у Интернет-провайдера или в организациях партнеров.
Рекомендация:
Авторитетные name-серверы предприятия должны быть как географически распределенными, так и распределенными в смысле сетевой топологии. Сетевая распределенность гарантирует, что все серверы не будут расположены за одним и тем же роутером или коммутатором в одной подсети. Географическая распределенность гарантирует, что не все name-серверы будут находиться в одном и том же физическом месте и в любом случае будет доступен по крайней мере один авторитетный name-сервер.
Авторитетные name-серверы организации получают запросы как от внешних, так и от внутренних клиентов. Во многих случаях внешние клиенты должны получать ресурсные записи, которые относятся только к публичным сервисам, таким, как web-сервер, почтовый сервер и т.п. Внутренние клиенты должны получать ресурсные записи, которые относятся как к публичным сервисам, так и к внутренним хостам. Следовательно, зонная информация, которая содержит эти ресурсные записи, может быть разделена на два представления, каждое из которых заключает в себе информацию, предназначенную для определенного типа клиентов: один для внешних клиентов, другой – для внутренних. Такой способ реализации зонного файла называется split DNS.
Рекомендация:
Для реализации split DNS должно быть как минимум два представления, еще называемых views. Одно должно содержать информацию, предназначенную исключительно для разрешения имен для хостов, которые расположены в локальной сети. Оно также может содержать множества ресурсных записей для обслуживания запросов из внешней сети. Другое представление или view должно обеспечивать разрешение имен только для хостов, расположенных во внешней сети или в DMZ, и не предоставлять данный сервис ни для каких хостов, расположенных во внутренней сети.
Для конфигурирования split DNS в BIND следует использовать специальное утверждение в конфигурационном файле BIND. Например, для конфигурирования авторитетного view в зоне sales.mycom.ru для внутренних хостов следует использовать утверждение
view "insider" {
match-clients { internal_hosts; };
recursion yes;
zone sales.mycom.ru {
type master;
file "sales_internal.db";
};
};
В данном утверждении указывается, что файл sales_internal.db содержит авторитетную информацию для зоны sales.mycom.ru, и вводится ограничение, что данная информация может быть запрошена со списка адресов, перечисленных в internal_hosts. Как задать данный список, будет объяснено ниже. Чтобы сконфигурировать view в некоторой зоне только для обслуживания запросов от внешних хостов, используется следующее утверждение в конфигурационном файле:
view "outsider" {
match-clients { any };
match-destination { public_hosts; };
recursion no;
zone sales.mycom.ru {
type master;
file "sales.external.db";
};
};
Данное утверждение очень похоже на предыдущее, за исключением того, что файл с view зоны есть sales.external.db и список клиентов указан как any, — это означает, что запросы могут быть как извне, так и изнутри сети. Вместе эти утверждения позволяют внутренним клиентам видеть как внутренние, так и внешние хосты, а внешние хосты, расположенные вне данной сети, могут видеть только информацию DNS, содержащуюся во внешнем view зоны, где адрес получателя соответствует адресам, перечисленным в public_host.
Вместо того чтобы иметь одно и то же множество авторитетных name-серверов, обслуживающих различные типы клиентов, можно развернуть два различных множества авторитетных name-серверов. Одно множество, называемое external name-серверы, может быть расположено внутри DMZ; это должны быть только те name-серверы, которые доступны внешним клиентам и которые содержат ресурсные записи, относящимся к хостам с публично доступными сервисами (web-серверы, которые обрабатывают внешние web-страницы или предоставляют В2С-сервисы, почтовые серверы и т.п.). Другое множество, называемое internal name-серверы, расположено за firewall’ом и должно быть сконфигурировано таким образом, чтобы эти серверы не были доступны извне и, следовательно, предоставляли сервисы разрешения имен исключительно для внутренних клиентов. Целью обеих архитектур (т.е. создания двух различных множеств name-серверов и split DNS) является предотвращение раскрытия IP-адресов внутренних хостов.
Как уже отмечалось, для управления содержимым зонного файла должен использоваться подход, обеспечивающий защиту на уровне ОС, с использованием различных инструментальных средств проверки целостности. Эффективность этих средств зависит от возможностей, имеющихся в них. Следовательно, процесс развертывания состоит из разработки правильных ограничений и определения правильных значений некоторых ключевых полей различных типов ресурсных записей.
Ранее были перечислены угрозы, цели безопасности и способы обеспечения защиты для различных транзакций DNS. Сейчас рассмотрим шаги, необходимые для реализации этих способов защиты. Перечислим типы способов обеспечения защиты:
DNS NOTIFY, для которой существует только угроза ложного уведомления, управление доступом, основанное на IP-адресе, вполне приемлемо. Хотя данное решение и не рекомендуется в общем случае, описание механизмов управления доступом, использующих IP-адреса, будет приведено далее, потому что аналогичные утверждения применяются для идентификации хостов на основе поименованных ключей, которые реализуют защиту транзакций, используя коды аутентификации сообщений (МАС), основанные на хэшах. Данный подход реализован для всех транзакций DNS.Некоторые реализации name-сервера, такие как BIND 9.x, предоставляют утверждения для управления доступом, с помощью которых можно указать хосты, которые могут участвовать в конкретной DNS-транзакции. Хосты могут быть указаны по их IP-адресам или указанием их IP-подсети (называемой IP-префиксом ) в данных утверждениях.
Список, содержащий эти IP-адреса и/или IP-префиксы, называется списком соответствия адресов. Список соответствия адресов может быть создан на основе не только IP-адресов, но и IP-префиксов. Этот список используется в качестве аргумента в различных утверждениях управления доступом, которые определены в конфигурационных файлах BIND. Существуют отдельные утверждения управления доступом для каждого типа транзакции DNS. Синтаксис таких утверждений и транзакции DNS, для которых они используются, приведен ниже.
| Синтаксис утверждения управления доступом | Транзакция DNS |
|---|---|
| allow-query {address_match_list } | DNS Query/Response |
| allow-recursion {address_match_list } | |
| allow-transfer {address_match_list } | Зонная пересылка |
| allow-update {address_match_list } | Динамическое обновление |
| allow-update-forwarding {address_match_list } | Динамическое обновление |
| allow-notify (address_match_list } | DNS NOTIFY |
| blackhole {address_match_list } | Хосты, попавшие в черный список |
Цель каждого из этих утверждений управления доступом состоит в следующем:
allow-query: указывает список хостов, которым разрешено запрашивать все зоны name-сервера или конкретную зону внутри name-сервера.allow-recursion: указывает список хостов, которым разрешено создавать allow-transfer: указывает список хостов, которым разрешено инициировать запросы зонной пересылки к name-серверу для всех зон или для конкретной зоны внутри name-сервера. Данное утверждение обязательно требуется в конфигурации первичного name-сервера.allow-update: указывает список хостов, которым разрешено инициировать запросы динамического обновления.allow-update-forwarding: указывает список хостов, которым разрешено перенаправление запросов динамического обновления (независимо от того, кто является источником запроса).allow-notify: указывает список хостов, с которых можно принимать сообщения DNS NOTIFY, говорящих об изменениях в зонном файле. Данный список относится только к конфигурации вторичного name-сервера.blackhole: указывает список хостов, которые входят в черный список (запрещен доступ) для инициализации любых транзакций с данным name-сервером.Перечисленные утверждения управления доступом являются в действительности подутверждениями, которые могут использоваться в контексте утверждений options и zone в конфигурационном файле named.conf в BIND 9.x. Когда они используются внутри утверждения zone, они определяют ограничения управления доступом для соответствующей транзакции для указанной зоны. Когда они используются как часть утверждения options, они определяют ограничения управления доступом для соответствующей транзакции для всего name-сервера, который может обслуживать несколько зон.
Рассмотрим пример использования подутверждения allow-query для указания ограничений для транзакции Query / Response, определяя допустимые IP-адреса / подсети в запросах DNS) как на уровне сервера, так и на уровне зоны (для зоны example.ru ):
options {
allow-query {254.10.20.10; 239.10.30.0/24; };
};
zone "example.ru." {
type master;
file "zonedb.example.ru";
allow-query {192.249.249.1; 192.249.249.4; };
};
Указывая список IP-адресов или IP-префиксов внутри утверждений options или zone, можно внести путаницу в конфигурационный файл. Более того, список IP-адресов и IP-префиксов может быть одним и тем же для многих утверждений управления доступом внутри name-сервера, и ошибка может возникнуть, если сделано какое-то одно добавление или удаление в данный список. Чтобы избежать таких проблем, в BIND существует способ создания поименованных списков адресов, которые называются access control lists (ACLs). Эти ACLs могут использоваться в тех местах, где допустимо использование списка IP-адресов или IP-префиксов (в качестве аргумента списка соответствующих адресов) в утверждениях управления доступом.
ACLs создаются с использованием утверждения acl в BIND 9.х. Общий синтаксис утверждения acl следующий:
acl acl-list-name {
address_match_list
};
acl-list-name есть определенная пользователем строка (например, "internal_hosts"). Address_match_list может быть списком IP-адресов, префиксами IP-адресов (обозначающих подсети) или криптографическими ключами. Пример утверждения acl, который использует IP-адрес и подсеть в address_match_list, приведен ниже. В примере 254.10.20.10 обозначает IP-адрес хоста, IP-префикс 239.10.30.0/24 обозначает подсеть класса С.
acl "internal_hosts" {
254.10.20.10;
239.10.30.0/24;
};
Можно использовать ACL internal_hosts в тех местах, где используется список IP-адресов или IP-префиксов в утверждениях options и zone следующим образом:
options {
allow-query { internal_hosts; };
};
zone "example.ru." {
type master;
file "zonedb.example.ru";
allow-query { internal_hosts; };
};
Параметр списка соответствующих адресов в утверждении управления доступом может содержать любое из следующих значений:
Определение ACLs является важным элементом при конфигурировании ограничений транзакций DNS. Следовательно, администратор первым делом должен задать ACLs, относящиеся к различным транзакциям DNS.
Рекомендация:
Необходимо, чтобы администратор создал поименованный список доверенных хостов (или черный список хостов) для каждого типа транзакций DNS. В общем случае следует рассмотреть следующие категории хостов для включения их в соответствующий ACL:
Дополнительно к IP-адресам, IP-префиксам или ACL, параметр списка соответствующих адресов в утверждениях управления доступом может принимать следующие специальные значения:
none: нет соответствующих хостов;any: все хосты;localhost: соответствует всем IP-адресам сервера, на котором выполняется name-сервер.localnets: соответствует всем IP-адресам и маскам подсетей сервера, на котором выполняется name-сервер.Приведем несколько примеров команд для создания ACLs и использования ACLs в утверждениях options и zone:
acl "local_hosts" {
254.10.20.10;
239.10.30.0/24;
};
acl "fake-net" {
0.0.0.0/8;
1.0.0.0/8;
};
options {
allow-query { any; };
blackhole { fake-net; };
};
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-query {local_hosts; };
};
Во фрагменте named.conf, приведенном выше, определены два ACLs, local_hosts и fake_net. На уровне сервера разрешены DNS-запросы с любого хоста. Никакие транзакции не разрешены с хостов, включенных в fake-net. Запросы для зоны example.ru могут быть инициированы только хостами, включенными в ACL local_hosts, потому что любое ограничение, указанное в утверждении zone, перекрывает ограничение, указанное в утверждении options.
Авторитетный name-сервер обеспечивает сервис разрешения имен для клиента, исходя из своих собственных данных. Следовательно, конфигурирование авторитетного name-сервера должно быть сделано таким образом, чтобы он мог принимать запросы от любых хостов. Обеспечение безопасности авторитетного name-сервера состоит в выключении возможности рекурсивного запроса, чтобы этот сервер не испортил свой кэш, запрашивая другие (возможно, скомпрометированные) name-серверы. Локальный рекурсивный name-сервер может быть сконфигурирован таким образом, чтобы принимать запросы только от внутренних хостов, что защитит его от DoS-атак, а также от порчи кэша. Однако возможны ситуации, когда экономически нежелательно иметь выделенные серверы для авторитетного сервиса и сервиса разрешения имен, и рекурсивный name-сервер должен выполняться как авторитетный сервер для одной или более зон. В такой ситуации возможны следующие стратегии с использованием BIND 9.х name-сервера:
views.Ограничение на уровне сервера с перекрытием для авторитетных зон
В этом случае определяется допустимое множество внутренних клиентов, которые могут передавать запросы к name-серверу. Для этого соответствующее acl утверждение таково:
acl "internal_hosts" { 192.158.43.3, 192.158.43.6, 192.158.44.56; };
Опцией на уровне сервера следует указать ограничение, чтобы запросы могли исходить только от данных клиентов:
options {
allow_query { internal_hosts; };
};
Опция может быть перекрыта указанием зон, для которых данный name-сервер является авторитарным (тем самым разрешая запросы, касающиеся ресурсов в данной зоне от всех клиентов):
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow_query { any; };
};
Ограничение всех рекурсивных запросов конкретным множеством IP-адресов
Ограничение на уровне сервера:
options {
allow_recursion { internal_hosts; };
};
Ограничение рекурсии с помощью views
Цель создания views состоит в логической комбинации клиентов (на основе IP-адресов) и зон, для которых будут поддерживаться recursion_view дает возможность определить область IP-адресов и зон, которым разрешено передавать no_recursion_view означает запрещение рекурсии.
view recursion_view {
match-clients ( internal_hosts; };
recursion yes;
};
view no_recursion_view {
match-client { any; };
recursion no;
};
Авторитетные name-серверы (особенно первичные) должны быть сконфигурированы с утверждением управления доступом allow-transfer, содержащим список хостов, с которых запросы зонной пересылки могут приниматься. Это ограничивает DoS-атаки и использование возможных ошибок (allow-transfer должен состоять из IP-адресов вторичных name-серверов, которые указаны в NS множества ресурсных записей, и "невидимых" вторичных name-серверов, которые указаны только в этом подутверждении.
Команда для создания ACL valid_secondary_NS с IP-адресами трех вторичных name-серверов следующая:
acl "valid_secondary_NS" {
224.10.229.5;
224.10.235.6;
224.10.245.25;
};
Подутверждение allow-transfer может быть использовано в утверждении zone и в утверждении options. Если оно используется в утверждении zone, то ограничивает зонную пересылку для данной зоны; если используется в утверждении options, ограничивает зонную пересылку для всех зон в name-сервере.
Подутверждение allow-transfer на уровне сервера является следующим:
options {
allow-transfer { valid_secondary_NS; };
};
Подутверждение allow-transfer на уровне зоны является следующим:
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-transfer { valid_secondary_NS; };
};
Предыдущие утверждения используются на первичных name-серверах. На вторичных и невидимых name-серверах зонная пересылка должна быть запрещена, как показано ниже:
zone "example.ru" {
type slave;
masters { 224.239.5.1 };
file "zonedb_bak.example.ru";
allow-transfer { none; };
};
Динамические обновления зонного файла могут осуществляться только для зонного файла, находящегося на первичном name-сервере зоны. По умолчанию динамические обновления отключены как в BIND 8, так и в BIND 9. Динамические обновления управляются использованием одного из следующих двух утверждений в BIND:
allow-update ;update-policy (доступно только в версиях BIND 9).Эти утверждения могут быть указаны только на уровне зоны, а не на уровне сервера. Следовательно, они являются подутверждениями внутри утверждения zone. Подутверждение allow-update дает возможность указать ограничения динамического обновления на основе IP-адресов и разделяемого секрета (также называемого allow-update с помощью указания только IP-адресов, а затем — использование утверждения allow-update с
Утверждение update-policy дает возможность указать ограничения динамического обновления только на основе allow-update определяет права доступа, касающиеся модификаций, ко всем записям в зоне. Подутверждение update-policy может быть использовано для ограничения прав доступа по модификации к одному или более типам ресурсных записей (например, A ресурсные записи).
Для использования утверждения allow-update должен быть создан список соответствующих адресов. Команда для создания ACL DU_Allowed_List с одним IP-адресом следующая:
acl "DU_Allowed_List" {
192.249.12.21;
};
ACL DU_Allowed_List (содержащий IP-адреса хостов, которым разрешено посылать запросы динамического обновления для изменения содержимого зоны example.ru ) используется внутри подутверждения allow-update утверждения zone следующим образом:
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-update { DU_Allowed_List; };
};
Запросы динамического обновления обычно исходят от таких хостов, как DHCP-серверы, которые динамически связывают IP-адреса с хостами. После того, как они назначат IP-адрес новому хосту, им нужно сохранить информацию отображения доменного имени на IP-адрес (созданием A ресурсной записи) и отображения адреса на доменное имя (созданием PTR ресурсной записи) в первичном авторитетном name-сервере для зоны. Создание данной информации происходит посредством динамических обновлений.
После того как зонные пересылки между серверами установлены, хорошо бы гарантировать, что вторичные name-серверы будут информироваться об изменениях в данных зонного файла посредством получения уведомления. По умолчанию сообщение уведомления посылается всякий раз, когда первичный name-сервер определил, что было сделано изменение в зонном файле. Он посылает сообщение DNS NOTIFY каждому name-серверу, перечисленному в NS -множестве ресурсных записей в зоне, потому что эти серверы считаются вторичными name-серверами зоны. Администратор DNS должен оставить выполнение этой транзакции, потому что это позволяет быстро распространять обновления на вторичные name-серверы. Однако, если администратор хочет выключить данную функциональность для конкретной зоны, следует использовать подутверждение notify в утверждении zone для данной зоны:
zone "example.ru" {
type master;
notify no;
file "zonedb.example.ru";
};
Если существуют дополнительные серверы, на которые администратор хочет посылать сообщение DNS NOTIFY (например, "невидимый" вторичный сервер), должно быть добавлено подутверждение also-notify в утверждение zone, и IP-адреса дополнительных серверов должны быть указаны в качестве значений параметров следующим образом:
zone "example.ru" {
type master;
also-notify { 192.168.25.2; };
file "zonedb.example.ru";
};
Получатель сообщения DNS NOTIFY, которым является вторичный name-сервер, по умолчанию разрешает получать сообщения уведомления только от первичного name-сервера. То, что данный name-сервер является вторичным для первичного name-сервера, указывается посредством подутверждения masters в утверждении zone. Если вторичный name-сервер хочет получать сообщения уведомления также и от других серверов, следует добавить подутверждение allow-notify в утверждение zone, и соответствующие IP-адреса этих серверов:
zone "example.ru" {
type slave;
allow-notify { 193.168.25.4; };
file "zonebak.example.ru";
masters { 192.168.25.1; };
};
Процесс аутентификации источника сообщения и обеспечение целостности сообщения с помощью
Функция
Хэш-алгоритм создает МАС фиксированной длины из сообщения произвольной длины. Функция
Защита транзакции посредством
МАС, создаваемый отправителем DNS-сообщения, помещается в новую ресурсную запись, называемую
timestamp );Поле timestamp указывает время, когда был создан МАС. Цель данного поля состоит в защите от
Для того чтобы обеспечить безопасность транзакции на основе МАС, отправитель вычисляет хэш от всего DNS-сообщения и секретного ключа и записывает результат в
Указание имени ключа в записи timestamp в записи timestamp состоит в предотвращении
Процесс верификации состоит в извлечении соответствующего секретного ключа, вычислении хэша от полученного сообщения и секретного ключа, и сравнении вычисленного хэша с полученным хэшем (в
В BIND версии 8.2 были впервые введены возможности
Для того чтобы была возможность транзакциям DNS использовать
Чтобы обеспечить возможность выполнять аутентификацию зонных пересылок (запросов и ответов), необходимо создать ключи для каждой пары name-серверов. Ключ также может использоваться для обеспечения безопасности других транзакций, таких как динамические обновления, запросы и ответы DNS. Битовая строка ключа, которая создается большинством утилит генерации ключа, используемых с
dnssec-keygen –a HMAC-MD5 –b 128 –n HOST ns1-ns2.example.ru
где параметры команды означают следующее:
-a: название алгоритма хэширования, который будет использоваться (HMAC-MD5).
-b: длина ключа (128 бит).
-n: тип ключа (HOST).
Последний параметр: имя ключа ( ns1-ns2.example.ru ).
Программа
Kns1-ns2.example.ru.+157+34567.key Kns1-ns2.example.ru.+157.34567.private
Когда программа создает пару ключей (открытый и закрытый), файл с расширением key будет содержать строку открытого ключа, а файл с расширением private будет содержать закрытый ключ. Так как в нашем случае создается только секретный ключ, строки ключа в обоих файлах будут одинаковыми. Строка ключа из любого из этих файлов затем копируется в файл, называемый файлом ключа. Данный файл указывается в утверждении include внутри утверждения key.
Ключ, созданный с использованием утилиты
key "ns1-ns2.example.ru." {
algorithm hmac-md5;
include "/var/named/keys/secretkey.conf";
};
где файл secretkey.conf содержит слово secret и реальную строку ключа:
secret "Mdkhhladasdka;"
В каждом конфигурационном файле пары серверов, которые разделяют секретный ключ в зоне, должно быть указано имя ключа, используемого во всех коммуникациях между ними (с помощью утверждения server в конфигурационном файле).
Команда для указания серверу использовать ключ во всех транзакциях (запрос / ответ DNS, зонная пересылка, динамическое обновление и т.п.) следующая:
server 192.249.249.1 {
keys { ns1-ns2.example.ru.; };
};
где параметр keys является именем ключа.
Подведем итоги:
dnssec -keygen /etc/named.conf для BIND, выполняющихся на Unix), которое описывает include в утверждении key в конфигурационном файле. Каждый Для пары серверов, участвующих в транзакциях зонных пересылок, указывается, что они должны использовать ключ, определенный в утверждении key. Такая пара обычно состоит из первичного name-сервера и вторичного name-сервера. Первичный name-сервер конфигурируется таким образом, чтобы принимать запросы зонной пересылки только от вторичных name-серверов, которые посылают МАС с использованием поименованного ключа, передаваемого в сообщении запроса зонной пересылки. Конфигурация создается с использованием подутверждения allow-transfer в утверждении zone. Пример подутверждения allow-transfer, которое указывает, что первичный name-сервер должен разрешать запросы зонной пересылки только для зоны example.ru от name-серверов, использующих ns1-ns2.example.ru ключ, выглядит следующим образом:
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-transfer { key {ns1-ns2.example.ru}; };
};
Вторичному name-серверу указывается использовать ключ ns1-ns2.example.ru в запросе зонной пересылки к первичному name-серверу, задействуя утверждение server.
Ограничения динамических обновлений, основанные на ключах allow-update утверждения zone. Аргументом данного утверждения является ключевое слово key, за которым следует имя
zone "example.ru" {
type master;
file "zonedb.example.ru";
allow-update { key {dhcp-server.example.ru.}; };
};
Заметим, что, хотя строка dhcp-server.example.ru. выглядит как FQDN, на самом деле она обозначает имя dhcp-server.example.ru., может посылать запросы динамического обновления (добавления, удаления или модификации ресурсных записей) зонного файла (для зоны example.ru ), который расположен на первичном авторитетном name-сервере.
Динамическим обновлениям разрешено копирование зонного файла на первичный авторитетный name-сервер только потому, что он является "allow-update-forwarding в версии BIND, которые имеют возможность перенаправления динамических обновлений. Пример такого allow-update-forwarding утверждения с использованием
zone "example.ru" {
type slave;
file "backupdb.example.ru";
allow-update-forwarding { key {dhcp-server.example.ru.}; };
};
Подутверждение allow-update определяет ограничения динамического обновления, которые основаны на отправителях запросов динамических обновлений (конкретное множество хостов, идентифицируемых по IP-адресу или обладающих grant или deny ) к динамическим обновлениям, основанным на комбинации имен домена или поддомена и типов ресурсных записей ( A, MX, NS и т.п.), BIND 9 и более поздние версии предоставляют подутверждение update-policy в утверждении zone. Эти ограничения в подутверждении update-policy основаны на update-policy указывает, каким
Общая форма update-policy утверждения следующая:
update-policy {
(grant | deny) TSIGkey nametype name [type]
};
где семантика каждого компонента утверждения такова:
grant / deny – разрешить / запретить динамическое обновление для комбинации, которая следует далее.TSIGkey – имя nametype – может быть одним из следующих значений, с соответствующей семантикой:
name – ограничение, применяемое к имени домена, которое указано в следующем поле name.subdomain name.wildcard – ограничение, применяемое к множеству доменов, которые указаны с использованием wildcard синтаксиса (например, *) в следующем поле name.self – ограничение, применяемое к домену, который является тем же самым, что и в поле TSIGkey (например, имя домена, чьи записи являются модифицируемыми, такое же, что и у ключа, используемого для аутентификации запроса динамического обновления). При таком использовании содержимое поля name становится лишним, но, тем не менее, должно использоваться в утверждении (т.е. поле name не может быть пустым).name – применяется для указания имени домена. Используемый синтаксис и домены, которые указывает данный параметр, основаны на значении, заданном в поле nametype (например, если поддомен является значением поля nametype, то все поддомены используемого имени домена охватываются данным утверждением).type – необязательное поле, которое может содержать любой существующий тип ресурсных записей (за исключением NSEC -типа) или wildcard тип ANY ( ANY означает все типы ресурсных записей, за исключением NSEC -типа). Если параметр опущен, то это означает все типы ресурсных записей, за исключением SOA, NS, RRSIG и NSEC. Также возможно использование нескольких типов ресурсных записей, разделенных пробелами (например, A NS ).Примеры update-policy утверждений и связанная с ними семантика приведены ниже.
Предположим, что существует домен sales.example.ru внутри example.ru и что name-сервер использует sales.example.ru ). Все динамические обновления от sales.example.ru могут быть ограничены ко всем ресурсным записям данного домена следующим образом:
zone "example.ru" {
type master;
file "zonedb.example.ru";
update-policy { grant sales.example.ru. self sales.example.ru.; };
};
Все динамические обновления от sales.example.ru могут быть ограничены только типами ресурсных записей A и MX данного домена следующим образом:
zone "example.ru" {
type master;
file "zonedb.example.ru";
update-policy {
grant sales.example.ru. self sales.example.ru. A MX; };
};
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.