Транзакции DNS

Безопасность транзакций DNS

Ранее были перечислены угрозы, цели безопасности и способы обеспечения защиты для различных транзакций DNS. Сейчас рассмотрим шаги, необходимые для реализации этих способов защиты. Перечислим типы способов обеспечения защиты:

• Ограничение участников транзакций на основе IP-адреса. В данном случае name-серверы и клиенты, участвующие в DNS-транзакциях, ограничены доверенным множеством хостов, которые указаны по их IP-адресам в соответствующих утверждениях управления доступом. Защита, которая обеспечивается утверждениями управления доступом, основанными на IP-адресе, может быть подвергнута таким атакам, как IP-spoofing (подделка IP-адреса). Следовательно, данное решение не рекомендуется для DNS-транзакций запросов и ответов, зонной пересылки и динамических обновлений, которые имеют высокую степень угроз. Однако для транзакции DNS NOTIFY, для которой существует только угроза ложного уведомления, управление доступом, основанное на IP-адресе, вполне приемлемо. Хотя данное решение и не рекомендуется в общем случае, описание механизмов управления доступом, использующих IP-адреса, будет приведено далее, потому что аналогичные утверждения применяются для идентификации хостов на основе поименованных ключей, которые реализуют защиту транзакций, используя коды аутентификации сообщений (МАС), основанные на хэшах. Данный подход реализован для всех транзакций DNS.
• Защита транзакций с помощью кодов аутентификации сообщений, основанных на хэшах (спецификация TSIG ). В данном способе защита транзакции обеспечивается созданием и проверкой кодов аутентификации сообщений, основанных на хэш-функциях ( НМАС ). Так как эти коды хранятся в специальной ресурсной записи, тип которой есть TSIG, описание защиты DNS-транзакций с использованием НМАС называется TSIG. Спецификации TSIG даны в RFC 2845 и 3007. Применение спецификаций TSIG для защиты транзакций зонных пересылок и динамических обновлений будет изложено далее.
• Защита транзакций с помощью цифровых подписей (спецификация DNSSEC). Данный способ, который называется расширениями безопасности DNS (DNSSEC), описан в семействе RFC 4033, 4034 и 4035. Ключевыми сервисами, предоставляемыми DNSSEC, являются аутентификация исходных данных и обеспечение их целостности. DNSSEC в основном используется для обеспечения безопасности транзакций запросов и ответов DNS. Проблемы, связанные с развертыванием DNSSEC, будут рассмотрены далее.

Ограничение участников транзакций на основе IP-адреса

Некоторые реализации name-сервера, такие как BIND 9.x, предоставляют утверждения для управления доступом, с помощью которых можно указать хосты, которые могут участвовать в конкретной DNS-транзакции. Хосты могут быть указаны по их IP-адресам или указанием их IP-подсети (называемой IP-префиксом ) в данных утверждениях.

Список, содержащий эти IP-адреса и/или IP-префиксы, называется списком соответствия адресов. Список соответствия адресов может быть создан на основе не только IP-адресов, но и IP-префиксов. Этот список используется в качестве аргумента в различных утверждениях управления доступом, которые определены в конфигурационных файлах BIND. Существуют отдельные утверждения управления доступом для каждого типа транзакции DNS. Синтаксис таких утверждений и транзакции DNS, для которых они используются, приведен ниже.

Цель каждого из этих утверждений управления доступом состоит в следующем:

• allow-query: указывает список хостов, которым разрешено запрашивать все зоны name-сервера или конкретную зону внутри name-сервера.
• allow-recursion: указывает список хостов, которым разрешено создавать рекурсивные запросы к name-серверу для всех зон или для конкретной зоны, обслуживаемой name-сервером.
• 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-сервера, который может обслуживать несколько зон.

Ограничение участников транзакции DNS Query/Response

Рассмотрим пример использования подутверждения 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; };
};

Параметр списка соответствующих адресов в утверждении управления доступом может содержать любое из следующих значений:

• IP-адрес или список IP-адресов;
• IP-префикс или список IP-префиксов;
• ACLs;
• комбинация перечисленных выше значений.

Определение ACLs является важным элементом при конфигурировании ограничений транзакций DNS. Следовательно, администратор первым делом должен задать ACLs, относящиеся к различным транзакциям DNS.

Рекомендация:

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

• хосты в DMZ, доступные во всех зонах предприятия;
• все вторичные name-серверы, которым разрешено инициировать зонные пересылки;
• внутренние хосты, которым разрешено выполнять рекурсивные запросы.

Дополнительно к 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.