Транзакции DNS

Создание безопасного окружения для сервисов DNS

Создание безопасной конфигурации для окружения DNS-хостинга должно обеспечивать следующее:

• безопасность платформы, на которой выполняется DNS;
• безопасность ПО DNS;
• управление содержимым зонного файла.

Рассмотрим рекомендации для каждого перечисленного выше пункта.

Безопасность платформы

На платформе, на которой выполняется ПО name-сервера, должна быть установлена ОС, удовлетворяющая требованиям безопасности. Большинство инсталляций DNS осуществляется либо на ОС Unix, либо на ОС Windows. В любом случае необходимо гарантировать следующее:

• установлены последние обновления ОС;
• рекомендуемые конфигурации ОС можно найти, например, на сайте CERT/CC. Данные рекомендации основаны на найденных уязвимостях, относящихся к ПО name-сервера. В частности, ОС, на которой выполняется ПО name-сервера, не должна предоставлять никаких других сервисов и, следовательно, должна быть сконфигурирована для получения только трафика DNS. Другими словами, должны быть разрешены только входящие и исходящие сообщения на порты 53/UDP или 53/TCP.

Безопасность ПО DNS

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

Использование самой последней версии ПО name-сервера

Каждая последующая версия ПО name-сервера, (особенно это касается BIND), обычно лишена уязвимостей, найденных в более ранних версиях. Если установлены старые версии, то эти уязвимости могут использоваться атакующим, чтобы осуществить атаку. Таким образом, хорошей практикой считается выполнение самой последней версии BIND, потому что теоретически она самая безопасная. Но даже если используется ПО самой последней версии, небезопасно выполнять его в режиме "по умолчанию". Администратор должен свободно владеть всеми установками безопасности для этой последней версии.

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

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

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

2. Выполнить следующие действия:

   • Подписаться на список рассылки ISC, называемый "bind-announce".
   • Периодически проверять найденные уязвимости BIND на http://www.isc.org/product/BIND/bind-security.html.
   • Проверять базу данных уязвимостей CERT/CC на http://www.kb.cert.org/vuls/ и NIST NVD базу данных на http://nvd.nist.gov/.

Выполнение ПО name-сервера с ограниченными привилегиями

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

Ограничение доступа к другим директориям может быть выполнено с помощью команды chroot в Unix. Такой подход называется выполнением name-сервера в jail (тюрьме). Должна быть выполнена следующая команда:

chroot –u named –g other –t /var/named

где:

-u указывает userID, от имени которого name-сервер будет выполняться после старта. Аккаунт данного пользователя должен быть создан до выполнения команды chroot.

-g указывает groupID, которой userID должен принадлежать. Если –g не указано, name-сервер выполняется от имени основной группы для userID.

-t указывает директорию, к которой name-сервер будет иметь доступ.

Изоляция ПО name-сервера

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

Выделенный экземпляр name-сервера для каждой функции

Авторитетный name-сервер обслуживает ресурсные записи своей собственной зоны; данная функция называется авторитетной функцией. Обслуживание ресурсных записей из своего кэша (создавая кэш динамически, используя итеративные запросы) называется рекурсивной функцией. Name-сервер может быть сконфигурирован как авторитетный name-сервер, рекурсивный name-сервер или как и то, и другое одновременно. Так как существуют такие атаки, как порча кэша, то политика безопасности, при которой выполняется рекурсивный name-сервера, отличается от политики безопасности, при которой выполняется авторитетный name-сервер. Следовательно, name-сервер должен всегда быть сконфигурирован либо как авторитетный name-сервер, либо как рекурсивный name-сервер.

Авторитетный name-сервер только обеспечивает разрешение имен для зон, для которых он имеет авторитетную информацию. Следовательно, политика безопасности не должна допускать рекурсию для данного типа name-сервера. Запрещение рекурсии означает невозможность посылки запросов от имени других name-серверов и создания кэша из полученных ответов. В BIND рекурсия запрещается использованием утверждения options в конфигурационном файле:

options {
  recursion no;
};

Рекурсивный name-сервер предназначен для обработки запросов от имени клиентов. Таким образом, защита рекурсивных name-серверов может быть обеспечена ограничением конкретных типов транзакций для определенных хостов. Это достигается использованием различных конфигурационных опций.

Удаление ПО name-сервера с не предназначенных для этого хостов

ПО DNS не должно выполняться или присутствовать на хостах, которые не предназначены для функционирования на них name-серверов. Вероятность такого присутствия существует, потому что ПО DNS BIND во многих версиях Unix (включая версии Solaris и Linux) инсталлировано по умолчанию. Следовательно, необходимо проверить наличие инсталляций BIND на рабочих станциях и серверах и удалить его с тех хостов, которые не предназначены для функционирования в качестве name-серверов.

Сетевое и географическое расположение авторитетных 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-серверов, обслуживающих различные типы клиентов, можно развернуть два различных множества авторитетных name-серверов. Одно множество, называемое external name-серверы, может быть расположено внутри DMZ; это должны быть только те name-серверы, которые доступны внешним клиентам и которые содержат ресурсные записи, относящимся к хостам с публично доступными сервисами (web-серверы, которые обрабатывают внешние web-страницы или предоставляют В2С-сервисы, почтовые серверы и т.п.). Другое множество, называемое internal name-серверы, расположено за firewall’ом и должно быть сконфигурировано таким образом, чтобы эти серверы не были доступны извне и, следовательно, предоставляли сервисы разрешения имен исключительно для внутренних клиентов. Целью обеих архитектур (т.е. создания двух различных множеств name-серверов и split DNS) является предотвращение раскрытия IP-адресов внутренних хостов.

Управление содержимым зонного файла

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