Администрирование операций для обеспечения безопасности сервисов DNS

Мы рассмотрели операции развертывания и использования возможностей DNSSEC для защиты транзакций запросов и ответов DNS. Рассмотрим операции администрирования, которые должны выполняться периодически, в поддерживающей DNSSEC зоне.

Аварийное обновление ключа

Аварийное обновление ключа происходит тогда, когда один или более ключей в зоне (ZSK или KSKкомпрометируются или закрытая компонента потеряна и необходимо выполнить переподписывание. Данный тип обновления не является плановым, поэтому велика вероятность разорвать цепочку аутентификации, если администратору зоны необходимо выполнить процесс обновления.

Аварийное обновление KSK

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

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

Администратор DNS должен иметь способ аварийного контактирования с администратором родительской зоной, чтобы иметь возможность выполнять аварийное обновление ключа KSK.

Аварийное обновление ZSK

Администратор DNS может обновить компрометированный ключ ZSK более быстро, чем компрометированный ключ KSK, потому что компрометация влияет только на зону. Возможность более быстрого обновления является другой причиной, по которой администратор зоны выполняет обновление ключа ZSK более часто. Если администратор зоны имеет новую DNSKEY-ресурсную запись, уже опубликованную в зоне в качестве части набора ключей зоны (первые три шага в процессе, который рассматривался ранее), следующий шаг зависит от того, является ли ключ компрометированным.

Если используемый в текущий момент ключ ZSK компрометирован, администратор зоны может немедленно заменить его на новый ключ. Нет необходимости ждать, чтобы истек период TTL, потому что новый ключ уже опубликован к данному моменту. Администратор может просто удалить старые RRSIG из зоны и переподписать новым ключом ZSK раньше, чем предполагалось сделать плановое обновление. Функционирование DNS должно продолжиться нормально после такого переподписывания, без разрыва цепочки аутентификации.

Если новый ключ ZSK (следующий ключ ZSK, который будет использоваться) компрометирован, его следует заменить немедленно в множестве ключей зоны. Такая замена также может выполниться автоматически, потому что новый ключ не использовался для создания каких-либо RRSIG; должно быть переподписано только множество ключей зоны. Также возможно просто удалить компрометированный ключ и заменить его новым ключом ZSK за одно обновление.

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

Безопасное хранение закрытых ключей (DNSSEC-OP2)

Закрытые ключи из KSK и ZSK пар ключей должны быть защищены от неавторизованного доступа. В идеале, закрытые ключи должны храниться off-line на физически безопасной, не доступной из сети машине вместе с мастер-копией зонного файла. Подписи, создаваемые с использованием закрытых ключей, должны пересылаться на первичные авторитетные name-сервера посредством процесса загрузки, используя динамически устанавливаемое сетевое соединение (а не постоянный сетевой канал).

Данная стратегия неосуществима в ситуациях, когда поддерживающий DNSSEC name-сервер должен выполнять динамические обновления. Для поддержки транзакций динамических обновлений name-сервер (который обычно является первичным авторитетным name-сервером) должен иметь как мастер-копию зонного файла, так и соответствующий закрытый ключ для подписывания зоны (ZSK-private) в режиме on-line для немедленного обновления подписей для измененных ресурсных записей. Закрытый ключ из KSK (KSK-private) может, тем не менее, храниться off-line. В этом случае должны быть предприняты следующие меры для защиты ZSK-private:

shell, из которого вызывается утилита создания ключа, должен быть недоступен для всех, за исключением администратора зоны.

Директория, в которой хранятся файлы закрытых ключей (обычно это поддиректория с тем же именем, что и зона, с именами файлов, имеющими структуру имени K<zonename>.AlgorithmID+<keytag>.private в BIND), должна быть недоступна и невидима для всех, за исключением администратора зоны.

Возможность быстрого восстановления должна быть обеспечена тем, что имеется зеркальный диск или выполняется периодический backup на съемный носитель.

Другая стратегия состоит в хранении закрытых ключей в зашифрованной файловой системе.

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

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

Безопасность ответов кэширующего name-сервера

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

Безопасное. Поддерживающий DNSSEC кэширующий name-сервер определяет состояние множества ресурсных записей как безопасное, если проверка соответствующей RRSIG прошла успешно. Проверка считается успешной, если может быть сформирована действительная цепочка от множества ресурсных записей до некоторого доверенного anchor’а. В этом случае множество ресурсных записей будет помещено в кэш и удалено, когда данные не будут считаться своевременными (в соответствии со значением TTL) или более не проверяемыми (в соответствии с периодом действительности RRSIG).

Небезопасное. Поддерживающий DNSSEC кэширующий name-сервер определяет состояние множества ресурсных записей как небезопасное, если ресурсные записи не являются безопасными в ответе. Это происходит, когда получено делегирование в неподписанную зону (делегирование, которое не имеет ресурсной записи DS). Небезопасные множества ресурсных записей обрабатываются тем же способом, что и безопасные, но локальная политика на конечной системе может определить, что не следует доверять небезопасным делегированиям или данным в ответе.

Фальшивое. Поддерживающий DNSSEC кэширующий name-сервер определяет ответ как фальшивый, когда проверка подписей (ресурсных записей RRSIG) не проходит или содержит некорректные поля (например, RRSIG истекла). Политика кэширования определяет, что делать с такими множествами ресурсных записей. Они могут быть либо отброшены, либо помещены в специальный BAD кэш, содержащий только те множества ресурсных записей, которые определены как фальшивые.

Когда поддерживающий DNSSEC кэширующий name- сервер получает запрос от не поддерживающего безопасность resolver’а, resolver получает как безопасные, так и небезопасные данные из кэша сервера. Так как данный запрос передан небезопасным способом, ресурсная запись DNSSEC не включается в ответ, тем самым применяется только обычная обработка DNS.

Поддерживающие DNSSEC resolver’ы получают либо безопасные, либо и безопасные, и небезопасные данные от поддерживающего DNSSEC кэширующего сервера с установленным в заголовке ответа битом. Этот Authenticated Data (AD) бит в заголовке указывает, что множества ресурсных записей в ответе прошли или не прошли все проверки безопасности, выполненные кэширующим name-сервером. Клиент может решить, полагаться ли ему на данную проверку или выполнить свое собственное множество проверок безопасности.

В некоторых случаях клиент может захотеть получить фальшивые данные от кэширующего name-сервера. В этом случае клиент посылает запрос с установленным Checking Disabled (CD) битом в заголовке DNS-сообщения. Это дает поддерживающему DNSSEC кэширующему name-серверу команду отвечать фальшивыми данными из BAD кэша. Клиент должен затем выполнить свою собственную проверку множества ресурсных записей в ответе. В таких типах ответов сервер не устанавливает AD бит, указывая, что ответ не прошел все проверки безопасности, выполняемые сервером.

Динамические обновления в поддерживающей DNSSEC-зоне

Напомним возможные операции над зонным файлом при выполнении динамических обновлений. Можно считать, что имеются две основные операции: добавление ресурсных записей и их удаление. Обновление можно рассматривать как комбинацию из операций добавления и удаления. В небезопасной зоне добавление и удаление ресурсных записей не вызывают никакой другой операции в оставшихся ресурсных записях в зонном файле. Однако в безопасной зоне существует NSEC-ресурсная запись (и соответствующая RRSIG-ресурсная запись) на каждую область в пространстве имен.

Имеется одна NSEC-ресурсная запись для каждого уникального имени владельца в зоне. Данная NSEC-ресурсная запись указывает на следующее имя владельца в каноническом порядке (упорядоченность, полученная лексикографической сортировкой доменных имен внутри зоны). NSEC-ресурсная запись для последнего имени владельца в каноническом порядке указывает на имя корня зоны (другими словами, имя зоны). Следовательно, концептуально эти записи образуют циклический список, в котором перечислены уникальные доменные имена в зоне

Рассмотрим содержимое ресурсных записей NSEC для зоны example.ru. Предположим следующую каноническую упорядоченность доменных имен в зоне:

example.ru IN SOA ns.example.ru admin.example.ru (12985 3600 2700 800 3600) IN RRSIG ( SOA ) IN NS ns.example.ru. IN RRSIG ( NS ) IN MX mail.example.ru. IN RRSIG ( MX ) marketing.example.ru IN A 192.253.101.9 IN RRSIG ( A ) IN MX mail.example.ru IN RRSIG ( MX ) sales.example.ru IN NS ns.example.ru. IN RRSIG ( NS ) www.exapmle.ru IN A 192.253.101.10 IN RRSIG ( A )

Псевдоформат (содержащий только информационные поля) NSEC-ресурсных записей, который охватывает интервалы пространства имен, относящиеся к доменным именам и типам ресурсных записей, что находятся в каждом имени в зонном файле, является следующим (ниже приведены четыре ресурсных записи NSEC):

example.ru IN NSEC marketing.example.ru (SOA NS MX RRSIG NSEC) marketing.example.ru IN NSEC sales.example.ru (A MX RRSIG NSEC) sales.example.ru IN NSEC www.example.ru (NS RRSIG NSEC) www.example.ru IN NSEC example.ru (A RRSIG NSEC)

Заметим, что существует столько NSEC- ресурсных записей, сколько уникальных доменных имен в зоне. NSEC-ресурсная запись, чье имя есть example.ru, ссылается на следующий домен в каноническом порядке (например, marketing.example.ru). То же самое выполняется для NS-ресурсных записей, относящихся к доменам marketing.example.ru и sales.example.ru. NSEC-ресурсная запись, относящаяся к последнему доменному имени (т.е, www.example.ru), ссылается на первое доменное имя в зоне (т.е. example.ru).

Когда получен запрос для "package.example.ru IN A" (т.е. запрос для зоны, которой не существует), авторитетный сервер отвечает NSEC множеством ресурсных записей, доказывая, что имя не существует в зоне. В данном случае ответ от сервера будет состоять из обычного DNS-ответа, указывающего, что имя не существует, и следующей информации:



marketing.example.ru. NSEC ресурсная запись, указывающая, что не существует авторитетных имен между marketing.example.ru. и sales.example.ru.

www.example.ru. NSEC-ресурсная запись (последний домен в зоне), доказывающая, что не существует расширений имен в формате wildcard в зоне, которые могут быть расширены таким образом, чтобы соответствовать запросу;

Сопутствующие RRSIG-ресурсные записи для каждой из вышеупомянутых NSEC-записей, используемые для аутентификации.

Модификации NSEC-ресурсных записей, выполняется при следующих операциях:

добавление нового типа ресурсной записи в существующий домен;удаление некоторого типа ресурсной записи из существующего домена;добавление нового имени домена в зону;удаление имени домена из зоны.

Добавление нового имени домена в зону

Чтобы заказчики могли работать в режиме on-line, предприятие решило добавить отдельный домен websales.example.ru. Также был добавлен отдельный name-сервер и множество новых хостов. Этот новый домен требует следующих изменений в зонном файле:

Добавление NSEC-ресурсной записи для нового домена. В этом случае должна быть добавлена NSEC-ресурсная запись для доменного имени websales.example.ru и должно быть определено ее расположение в каноническом порядке. Данная NSEC-ресурсная запись должна быть вставлена таким образом, чтобы указывать на следующее доменное имя в новом каноническом порядке. Добавляемый name-сервер и существовавшие ранее хосты должны отображаться в этой новой ресурсной записи посредством того, что NS и А указываются в поле списка типов ресурсных записей, как показано ниже. Соответствующая RRSIG-ресурсная запись должна быть создана.

websales.example.ru IN NSEC www.example.ru (A NS RRSIG NSEC)

NSEC-ресурсная запись, относящаяся к домену, непосредственно предшествующая добавленному домену (в каноническом порядке) должна быть модифицирована таким образом, чтобы указывать на только что добавленный домен. NSEC-ресурсная запись должна теперь указывать на домен websales.example.ru.

sales.example.ru IN NSEC websales.example.ru (A RRSIG NSEC)

Создается новая ресурсная запись для подписи (RRSIG-ресурсная запись), соответствующая данному модифицированному NSEC-множеству ресурсных записей.

Добавление нового типа ресурсной записи в существующий домен

Предположим, что новый почтовый хост добавлен в домен www.example.ru. Такое изменение требует добавления MX-ресурсной записи к данному имени домена. Следовательно, NSEC-ресурсная запись для www.example.ru должна быть модифицирована следующим образом:

www.example.ru IN NSEC example.ru ( A MX RRSIG NSEC )

Дополнительные меры защиты для DNS Query / Response

Спецификации DNSSEC для защиты транзакций DNS Query / Response определяет следующие типы ответов:

DNS-ответы от удаленных авторитетных name-серверов к локальным рекурсивным name-серверам;DNS-ответы от удаленных кэширующих name-серверов к локальным рекурсивным name-серверам.

Так как большинство запросов первоначально исходят от stub resolver’а (от имени ПО клиента, требующего доступ к ресурсу в Интернете), защита сообщения DNS ответа должна также обеспечиваться для stub resolver’а от рекурсивного name-сервера. Способ обеспечения защиты на этом участке, который часто называется DNS "last hop", определяется природой stub resolver’а и топологией сети.

Stub resolver может:

не поддерживать DNSSEC;

– поддерживать DNSSEC и не проверять правильность ответа;

поддерживать DNSSEC и проверять правильность ответа.

Большинство stub resolver’ов, существующих сегодня, не поддерживают DNSSEC. Другими словами, они не имеют возможности проверить цифровые подписи, связанные с полученными множествами ресурсных записей, и также не могут отличить аутентифицированный ответ (проверяя его подпись) от неаутентифицированного ответа, передаваемого им их локальными рекурсивными name-серверами. Чтобы создать полную end-to-end защиту для DNS Query / Response, эти типы stub resolver’ов как минимум должны иметь возможность выполнять аутентификацию источника и проверку целостности данных в ответах, пришедших от рекурсивного name-сервера, который предоставляет им сервис разрешения имен. Такая возможность может быть обеспечена использованием подхода НМАС, заданного в TSIG (где описано использование НМАС для защиты транзакций зонных пересылок и динамических обновлений). В качестве альтернативы защиту можно обеспечить с помощью других механизмов сетевой безопасности, таких как IPsec. Независимо от механизма, используемого для обеспечения безопасности канала "last hop" (от рекурсивного name-сервера к stub resolver), данная возможность также должна присутствовать в поддерживающих DNSSEC и не проверяющих правильность ответа stub resolver’ах в дополнение к не поддерживающим DNSSEC stub resolver’ам.
Поддерживающий DNSSEC, но не проверяющий правильность ответа stub resolver может увеличить доверие к этому ответу, проверяя значение AD бита в заголовке сообщения в полученном ответе. Данные типы stub resolver’ов могут затем использовать этот бит в качестве признака того, что рекурсивный name-сервер имеет возможность проверять действительность подписей для данных в ответе.

В некоторых ситуациях установление доверенного пути между stub resolver’ами и рекурсивными name-серверами не предоставляется возможным. Примером является ситуация, когда рекурсивный name-сервер не расположен в административном домене предприятия, а выполняется у провайдера. В такой ситуации end-to-end защита может быть обеспечена только при наличии поддерживающего DNSSEC stub resolver’а. Поддерживающий DNSSEC stub resolver может уведомить локальный рекурсивный name-сервер, что он хочет сам выполнить проверку действительности подписи, установив Checking Disabled (CD) бит в свои сообщения запроса.

Использование периода действительности RRSIG для минимизации последствий компрометации ключа

Самым лучшим способом минимизировать последствия компрометации ключа является ограничение периода действительности RRSIG как в самой зоне, так и в родительской зоне. Это позволяет ограничить время, в течение которого атакующий может использовать скомпрометированный ключ для подделки ответов. Атакующий, который имеет скомпрометированный ключ ZSK, может использовать данный ключ только в течение интервала действительности подписи, созданной ключом KSK. Атакующий, который скомпрометировал ключ KSK, может использовать его только в интервале, указаном в DS-ресурсной записи, которая является точкой делегирования у родителя. Но если определить данный период действительности коротким, то потребуется частое переподписывание в зонном файле родителя.

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

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

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

Зона, имеющая делегированную дочернюю зону, должна иметь период действительности от нескольких дней до одной недели для RRSIG, охватывающей DS-ресурсную запись для делегированной дочерней зоны. Такое значение помогает снизить период уязвимости в дочерней зоне, возникший в результате компрометации ее ключа KSK.

Краткое резюме

Перечислим основные принципы, которым необходимо следовать при развертывании DNSSEC.

Размер ключа KSK должен быть достаточно большим, потому что это имеет большее влияние на безопасность DNS при компрометации ключа KSK. Период действительности (период обновления) для ключа ZSK должен быть достаточно коротким, потому что существует больший риск для угадывания ключа.

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

Создание подписи с использованием ключа KSK должно выполняться в режиме off-line с использованием ключа KSK-private, хранящегося off-line; затем множество ресурсных записей DNSKEY вместе с его RRSIG-ресурсной записью должны быть записаны в зонный файл первичного авторитетного name-сервера.

Хранение ключа ZSK-private и создание подписи с использованием данного ключа должно выполняться в режиме off-line; множество ресурсных записей вместе с RRSIG-ресурсными записями может затем быть записано в зонный файл первичного авторитетного name-сервера. Исключением является случай, когда name-сервер поддерживает динамические обновления. При этом ключ ZSK-private должен располагаться на name-сервере.

Механизмы и операции DNSSEC

Механизмы DNSSEC определяют две основных операции: подписывание (и связанные с этим действия) и проверка подписи. Рассмотрим эти операции.

Минимизация раскрываемой DNS-информации

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

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

Обновление ключа KSK в глобально безопасной зоне

Ключ KSK (KSK-public) является ключом, для которого родитель данной безопасной зоны обеспечивает доверие. Для этого он использует ресурсную запись DS, которая содержит хэш дочернего ключа KSK. Делегирующий родитель подписывает данную ресурсную запись DS своим собственным ключом ZSK для того, чтобы отношения доверия осталось в силе. Для обновления ключа KSK дочерней зоны следует выполнить следующее:

создать новый ключ KSK и добавить его в множество зонных ключей;

подписать множество ключей зоны новым ключом KSK, а также старым ключом KSK (ключом, который истекает);

передать новый ключ KSK своему родителю таким способом, при котором родитель мог бы аутентифицировать этот ключ;

в родительской зоне создать новую DS-ресурсную запись (которая заменит старую DS-ресурсную запись), содержащую хэш нового ключа KSK, затем подписать заново созданную DS-ресурсную запись.

Для того чтобы родитель мог аутентифицировать новый ключ KSK (будем называть его KSK2), основываясь на существующей цепочке доверия, дочерняя зона при выполнении обновления ключа создает DNSKEY-множество ресурсных записей, используя DNSKEY-ресурсные записи существующего ключа вместе с новой DNSKEY-ресурсной записью для KSK2. Затем создаются две подписи (две RRSIG-ресурсные записи) – одна с использованием существующего ключа KSK, другая с использованием нового ключа KSK2. Затем родителю посылается заново созданное DNSKEY множество ресурсных записей вместе с RRSIG-ресурсными записями (во множественном числе, потому что существуют две подписи, соответствующие ключам KSK и KSK2). Множество ресурсных записей, посылаемое родителю, приведено ниже в некотором псевдоформате:

example.ru DNSKEY <key-id: 43543> /* новый KSK*/ example.ru DNSKEY <key-id: 78546> /* существующий KSK*/ example.ru DNSKEY <key-id: 98342> /* ZSK*/ example.ru RRSIG (DNSKEY) <signer:example.ru signing-key:78546> /* весь DNSKEY RRset подписан существующим KSK */ example.ru RRSIG (DNSKEY) <signer:example.ru signing-key:43543> /* весь DNSKEY RRset подписан новым KSK */

При получении данной информации родитель выполняет следующие действия:



проверяет правильность подписи, сделанной ключом KSK 78456 для заново созданного множества ресурсных записей DNSKEY, которое включает новый ключ KSK2. Это выполняется с использованием первой из RRSIG-ресурсных записей заново созданного DNSKEY-множества ресурсных записей, (записи, в которой указан 78456 в качестве ключа подписывания) и своей собственной DS-ресурсной записи;

проверяет аутентичность ключа KSK2 по открытому ключу KSK2 дочерней зоны. Для этого он проверяет вторую RRSIG-ресурсную запись (запись, в которой указан 43543 в качестве ключа подписывания) из DNSKEY-множества ресурсных записей;

создает новую DS-ресурсную запись, содержащую хэш нового ключа KSK2;

создает RRSIG для новой DS-ресурсной записи ключа KSK2.

Когда данные задачи выполнены родителем, процесс обновления ключа KSK с точки зрения дочерней зоны полностью выполнен. Родительская зона должна затем обновить свой зонный файл с новой DS-ресурсной записью. Это аналогично обновлению любого другого множества ресурсных записей, которое включает создание, если требуется, любых новых RRSIG. Данное обновление может выполняться автоматически. Это означает, что старая DS-ресурсная запись может быть сброшена и одновременно новая DS-ресурсная запись добавлена. При этом будет выполнено только одно переподписывание в зоне.

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

Обновление ключа в глобально безопасной зоне

Глобально безопасная зона использует два множества ключей: ZSK и KSK.

Обновление ключа в локально безопасной зоне

Зона, которая является локально безопаснойимеет ключ ZSK и, возможно, ключ KSK, который сконфигурирован в resolver’ах клиента как доверенный ключ. Определенные сложности возникают, когда любой из ключей обновляется, хотя наличие ключа KSK для локально подписанной зоны делает обновление ключа ZSK более легким. Когда зона изменяет свой ключ ZSK и имеется ключ KSK, который не изменяется, проблема состоит в том, что следует ввести новый ключ, в то время как старый ключ может находиться в некоторых удаленных resolver’ах или кэшах name-серверов.

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

создать новую пару ключей;

добавить открытый ключ из новой пары в зонный файл (DNSKEY-ресурсная запись);

подписать зону с использованием закрытого ключа из текущей активной пары и подписать ключом KSK новый открытый ключ (DNSKEY-ресурсная запись);

подождать время, равное минимальному TTL для записи зоны;

удалить старую DNSKEY-ресурсную запись из множества ключей зоны и сделать истекшими RRSIG-ресурсные записи;

переподписать DNSKEY множество ресурсных записей новым ключом ZSK.

Следует помнить, что обновлять ключ ZSK необходимо постоянно. Администратор может выполнить первые три шага и подождать определенное время перед тем, как удалить старый DNSKEY из множества ключей, при этом продолжая подписывать зону старым DNSKEY, до тех пор, пока RRSIG в зоне не истекут. Данная процедура позволяет администратору выполнять обновление ключа оптимально.

Зоны, которые заранее опубликовывают новый открытый ключ, должны соблюдать следующие принципы:

безопасная зона, которая предварительно опубликовывает свой открытый ключ, должна сделать так, чтобы по крайней мере один период TTL завершался до времени обновления ключа;

после удаления старого открытого ключа зона должна создать новую подпись (RRSIG-ресурсную запись) для оставшихся ключей (DNSKEY-ресурсные записи) в зонном файле.

При обновлении KSK безопасная зона может не знать, какие resolver’ы хранят открытый ключ в качестве доверенного anchor’а. Если сетевой администратор имеет внешний способ (хотя бы по e-mail) контактирования с администраторами resolver’ов, которые хранят открытые ключи в качестве доверенных anchor’ов, сетевой администратор должен послать соответствующее уведомление и установить безопасные способы распространения нового доверенного anchor’а. Если такого внешнего способа не существует, администратор ничего не сможет сделать, за исключением предварительного опубликования нового ключа KSK, давая администраторам resolver’ов достаточно времени для получения нового ключа KSK.

Обновление ключа ZSK в глобально безопасной зоне

Операции, выполняемые при обновлении ключа ZSK в глобально безопасной зонене отличаются от тех, которые выполняются при обновлении ключа ZSK в локально безопасной зоне.

Опубликование открытого ключа (DNSSEC-OP3) и конфигурирование доверенных anchor’ов (DNSSEC-OP7)

Проверка данных зоны resolver’ом начинается с того, что resolver знает открытый ключ данной зоны (той, чьи данные он проверяет) или любой из открытых ключей зон, расположенных выше в дереве DNS. Если проверяемая зона (например, example.ru) поддерживает безопасность (т.е. поддерживает DNSSEC), а ее родитель (.ru) — нет, то точка доверия начинается с самой зоны. Если зона родителя (зона .ru) поддерживает безопасность, а зона выше по дереву (зона root) — нет, начальной точкой доверия является родитель (т.е. зона .ru). Если зона root поддерживает безопасность, то она становится исходной точкой доверия.

В любом случае открытый ключ данной начальной точки должен быть известен resolver’ам. Такие открытые ключи, известные resolver’ам, называются доверенными anchor’ами. Поскольку не существует возможности средствами DNS выполнить проверку этих открытых ключей, открытый ключ доверенного anchor’а должен распространяться внешним по отношению к DNS способом. Данное распространение может быть осуществлено с использованием таких каналов, как web-сайты или e-mail.

Список доверенных anchor’ов в поддерживающем DNSSEC resolver’е определяет, какой подписанный ответ от зоны будет рассматриваться как безопасный, а какой — нет. Как уже отмечалось, resolver должен установить доверие к открытому ключу зоны, из которой он получил ответ, перед тем как выполнить проверку подписи. Если такое доверие не может быть установлено с помощью построения доверенной цепочки, используя записи в списке доверенных anchor’ов, ответ должен помечаться как небезопасный. Причина, по которой отсутствует возможность построения доверенной цепочки, может состоять в том, что пространство имен DNS содержит только отдельные участки подписанных зон вместо непрерываемой иерархической последовательности подписанных зон. Предположим, что дерево DNS имеет следующую структуру.

Тогда статус ответа (безопасный или небезопасный) зависит от списка хранящихся в resolver’е доверенных anchor’ов и от того, из какой зоны получен ответ.

Рис. 8.2.  "Острова" подписанных зон

Результат приведен в таблице.

Возможные статусы ответаДоверенный anchor, инсталированный в поддерживающий DNSSEC resolverСтатус DNSSEC ответа для запрошенных адресовwww.example.ruwww.example.orgwww.example.com

None	Insecure	Insecure	Insecure
Root	Secure	Insecure	Insecure
.org	Insecure	Secure	Insecure
example.com	Insecure	Insecure	Secure

Переподписывание зоны

Зонный файл переподписывается (т.е. заново создаются RRSIG-ресурсные записи), в следующих ситуациях:

подписи истекли или истекут в скором времени;содержимое зонного файла изменилось в результате динамического обновления;один из ключей подписывания скомпрометирован или заменяется в плановом порядке.

Существуют две стратегии для переподписывания данных зоны.

Полное переподписывание. Все существующие записи подписи (RRSIG-ресурсные записи) удаляются, зонный файл сортируется заново, все NSEC-ресурсные записи создаются, и, наконец, создаются новые записи подписи. Полное переподписывание выполняется в следующих ситуациях:

зонный файл создается из некоторой back-end базы данных;администратор зоны установил выполнение данного переподписывания в пакетном режиме для выполнения на конкретный день и время, основываясь на времени истечения действительности подписи.

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

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

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

Серийный номер в SOA ресурсной записи должен быть увеличен перед переподписыванием зонного файла. Если данная операция не сделана, вторичные name-серверы могут не получить новые подписи, потому что они выполняют обновление исключительно на основе соответствия серийного номера SOA. В результате этого некоторые поддерживающие безопасность resolver’ы не будут иметь возможность проверять подписи (и таким образом иметь безопасный ответ), а другие — будут.

Плановое обновление ключа (время жизни ключа)

Ключи, используемые для подписывания зоны (ZSK), и ключи подписывания ключа (KSK) должны периодически меняться, потому что они становятся уязвимыми после определенного периода использования. Компрометация закрытого ключа означает, что любой хост может подделать данные зоны, подписывая ложное множество ресурсных записей закрытым ключом, тем самым полностью аннулируя цели, которые преследовались при подписывании зонного файла. Обновление ключа может быть плановым (плановое обновление) или может иметь место в результате каких-либо чрезвычайных обстоятельств (чрезвычайное обновление). Чрезвычайное обновление происходит по одной из следующих причин:

закрытый ключ зоны скомпрометирован;

закрытый ключ зоны потерян, и зона обновлена до истечения периода действительности RRSIG, но нет возможности подписать новые данные зоны.

При плановом обновлении ключа период времени, после которого ключи должны быть изменены, определяется несколькими факторами:

большой размер зонного файла, большое количество данных, для которых создаются подписи, делает процесс взлома закрытого ключа более легким;чем меньше размер закрытого ключа, тем легче его взломать.

Основываясь на этих факторах, в каждой зоне определяется частота обновления ключей для ZSK и KSK. Напомним, что ключ KSK (KSK-private) используется для подписывания только множества ресурсных записей DNSKEY, в то время как ключ ZSK (ZSK-private) используется для подписывания всего зонного файла. Независимо от объема данных, ключ ZSK используется намного чаще, а именно, в следующих случаях:

добавляется новая ресурсная запись (например, добавлен новый почтовый сервер, и, следовательно, добавлена новая ресурсная запись MX в зонный файл);

существующие RDATA в ресурсной записи изменяются (например, IP-адрес сервера изменился, и, следовательно, существующая ресурсная запись A должна быть заменена);

истекает период действительности подписи для ресурсной записи RRSIG.

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

Ключ KSK должен обновляться менее часто, чем ключ ZSK. Рекомендуемая частота обновления для ключа KSK равна одному году (при использовании RSA/MD5 с длиной ключа 2048 бит), а ключ ZSK должен обновляться каждый месяц (при использовании RSA/MD5 с длиной ключа 1024 бит).

Воздействие обновления ключа на оставшуюся часть DNS зависит от того, является ли безопасная зона локально безопасной или глобально безопасной (как часть цепочки доверия).

При подписывании зонного файла выполняется следующая последовательность действий:

Зонный файл сортируется в каноническом порядке доменных имен.

Создается ресурсная запись NSEC для каждого имени собственника в зоне.

Используется ключ KSK (KSK-private) для подписывания множества ресурсных записей DNSSEC. Ключ KSK определяется по наличию установленного флага SEP в RDATA в ресурсной записи DNSSEC.

Ключ ZSK (ZSK-private) используется для подписывания всех ресурсных записей в зоне (включая ресурсные записи DNSKEY и NSEC).

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

Создание подписи с использованием ключа KSK должно выполняться off-line, используя KSK-private, также хранимый off-line; затем ресурсные записи DNSKEY вместе в ресурсной записью RRSIG должны быть размещены в первичном авторитетном name-сервере.

Хранение ключа ZSK-private и создание подписи с использованием этого ключа должно выполняться off-line; ресурсные записи вместе с RRSIG ресурсными записями затем могут быть записаны в первичный авторитетный name-сервер. Исключением является случай, когда name-сервер поддерживает динамические обновления. В этом случае ZSK-private должен располагаться в name-сервере.

Пример подписывания зоны

Приведем пример, иллюстрирующий использование программы подписывания зоны (dnssec-signzone в BIND 9.3.x):

dnssec-signzone –o <name of zone> -k <name of file containing KSK> <location of zone file> <name of file containing ZSK>

Для подписывания данных из зоны example.ru с KSK, расположенным в файле Kexample.ru.+005+76425.key, и ZSK, созданным заранее, следует выполнить следующую команду:

dnssec-signzone –o example.ru -k Kexample.ru.+005+76425.key /var/named/zonedb.example.ru Kexample.ru.+005+28345.key

Процесс подписывания зонного файла состоит из следующих шагов:

создание хэша для каждого множества ресурсных записей (ресурсных записей с одним и тем же именем собственника, TTL, классом и RRType); создание подписи для каждого множества ресурсных записей (используя закрытый ключ ZSK-private);

размещение этой информации в новой ресурсной записи с типом RRSIG.

Ключ KSK подписывает только множество ресурсных записей DNSKEY, а ключ ZSK — все ресурсные записи в зонном файле. Участник, чей закрытый ключ используется для подписывания данных зоны, называется подписывающей стороной (signer или signing authority). В большинстве случаев подписывающая сторона является доменом, связанным с зоной. В ответ на DNS-запрос поддерживающий DNSSEC авторитетный name-сервер выдает соответствующие данные зоны вместе с цифровой подписью этих данных. Получатель проверяет цифровую подпись для полученных данных зоны, используя открытый ключ подписавшего (после установления доверия к открытому ключу).

Пример создания пары ключей

Любое ПО name-сервера поддерживающего DNSSECдолжно предоставлять программную утилиту для создания пары асимметричных ключей. Проиллюстрируем использование одной из таких программ, dnssec-keygen (имеющейся в BIND 9.3.x):

dnssec-keygen –a algorithm –b bits –n type [options] name

где algorithm может быть один из следующих:

RSAMD5DSA

bits (длина ключа) имеет следующие диапазоны:

512 … 4096 для RSA-MD5512 … 1024 для DSA

type может быть одним из ZONE или HOST. В принципе, могут быть добавлены и любые другие типы ключей.

name есть имя собственника ключа (обычно имя домена).

Данная команда создает два файла: один содержит открытый ключ, а другой файл — соответствующий ему закрытый ключ. Имена этих файлов следующие:

K<domain_name>+algorithm_id+Key_id.key K<domain_name>+algorithm_id+Key_id.private

domain_name является значением параметра name, указанного в командной строке. Algorithm_id может быть следующим:

3 – DSA

5 – RSAMD5

key_id есть уникальный идентификатор созданного ключа, созданного программой.

Например, для создания ZSK-ключа длиной 1024 бит, который использует набор алгоритмов RSAMD5 для подписывания зоны example.ru, должна быть выполнена следующая команда:

dnssec-keygen –a RSAMD5 –b 1024 –n ZONE example.ru

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

Kexample.ru.+005+28345.private Kexample.ru.+005+28345.key

В этих именах файлов 005 определяет algorithm_id и 28345 есть уникальный идентификатор ключа.

В *.key файле информация открытого ключа имеет тот же самый синтаксис, что и ресурсной записи в зонном файле. Содержимое файла Kexample.ru.+005+28345.key следующее:

example.ru IN DNSSEC 256 3 5 BQFG...... (строка ключа в Base64)

Следовательно, содержимое файла с открытым ключом может быть добавлено к содержимому зонного файла с помощью следующей команды:

cat *.key >> /var/named/zonedb.example.ru

После того как ресурсная запись DNSKEY, содержащая открытый ключ, добавлена в зонный файл, Serial Number зоны должен быть увеличен до того, как будет выполнено подписывание зоны.

Создание доверенной цепочки и проверка подписи (DNSSEC-OP8)

До тех пор, пока все зоны не станут подписанными, возможна ситуация, при которой зона является подписанной, но ее родитель не является подписанной зоной. Единственной точкой доверия для поддерживающего DNSSEC resolver’а в этом случае может считаться заранее сконфигурированный открытый ключ подписывающей стороны. При отсутствии другого источника, подтверждающего достоверность открытого ключа подписывающей стороны, требуется, чтобы открытый ключ был получен безопасным способом. В противном случае, если существует домен X, который может подтвердить достоверность открытого ключа домена Y, resolver может установить доверие к подписывающей стороне Y, используя X. Последовательность зон в дереве DNS, с помощью которых resolver устанавливает доверие к открытому ключу подписывающей стороны, называется цепочкой доверия.

Будем считать, что цепочка доверия начинается с домена X и заканчивается доменом Y. Обычно домен X является непосредственным родителем Y и называемая родительской зоной. Родительская зона обеспечивает доказательство достоверности открытого ключа дочерней зоны, подписывая ее ключ. Данная подпись хранится в ресурсной записи, называемой Delegation Signer (DS). Родительская зона также должна быть подписанной зоной, потому что неподписанная зона не умеет создавать подписи. Таким образом, подписанная зона может быть одного из следующих типов.

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

Глобально безопасная зона – ее родительская зона и, возможно, один или более предков вверх по DNS-дереву являются подписанными. При существовании такой иерархии подписанных зон и соответствующей иерархии сконфигурированных ключей resolver обычно имеет в качестве начала цепочки доверия открытый ключ зоны, которая является вершиной иерархии подписанных зон.
Этот открытый ключ называется доверенный anchor. В resolver’ е может существовать более одного ключа, которые являются доверенными anchor’ами и могут использоваться для построения цепочки доверия к открытому ключу зоны, чьи подписи resolver хочет проверять.

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

создать пару открытый / закрытый ключ;обеспечить безопасное хранение (если необходимо, отдельно от name-сервера) закрытого ключа;

опубликовать открытый ключ с помощью включения ресурсной записи DNSKEY в зонный файл; создать цифровые подписи для данных зоны (подписывание зоны).

Для глобально безопасной зоны существуют дополнительные задачи. Чтобы обеспечить возможность создания цепочки доверия, зона должна безопасным образом (внешним по отношению к сервисам DNS) передать родительской зоне свой открытый ключ (KSK-public). Затем родитель создает хэш этого открытого ключа дочерней зоны и хранит его в своей зоне в виде новой ресурсной записи, называемой DS. Он подписывает эту ресурсную запись DS, создавая ресурсную запись RRSIG. Родителю передается ключ KSK, а не ключ ZSK, потому что в противном случае происходило бы следующее. Всякий раз, когда зона изменяет свой ZSK, ее родитель должен был бы быть уведомлен о новом ключе. При этом родителю приходилось бы создавать новую ресурсную запись DS и снова подписывать ее. Для уменьшения подобной административной нагрузки родительской зоне передается ключ KSK. KSK используется для подписывания только ресурсных записей DNSKEY; все остальные ресурсные записи в зонном файле подписываются ZSK. KSK является тем ключом, который опубликовывается у родителя. Родитель создает ресурсную запись DS, содержащую ключ KSK дочерней зоны, создает подпись для данного KSK и размещает ее в ресурсной записи RRSIG. Ключ KSK создается достаточно большим (например, 2048 бит) по сравнению с ключом ZSK, который может быть, например, длиной 1024 бит и, следовательно, должен изменяться менее часто.



Следовательно, он доверяет ресурсным записям NS и DS в зоне .ru. Из ресурсной записи NS и связанных с ней ресурсных записей resolver определяет, что авторитетный name-сервер для example.ru есть ns.example.ru, и он также знает его IP-адрес. Используя данную информацию, он идет на ns.example.ru и получает ключ KSK для example.ru из его множества ресурсных записей DNSKEY. Он вычисляет хэш данного ключа и сравнивает его с хэшем в ресурсной записи DS его родительской зоны .ru. Равенство этих двух хэшей означает, что ссылка из .ru зоны на example.ru зону аутентифицирована; аутентифицирован также и ключ KSK example.ru зоны. Так как ключ ZSK подписан ключом KSK example.ru, resolver может получить ключ ZSK example.ru аутентифицированным способом. Так как ключ ZSK подписывает все ресурсные записи в example.ru, действительность любого подписанного ответа из данной зоны может быть определена с использованием ключа ZSK, который уже аутентифицирован.

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



Ресурсные записи NS для дочерней зоны, которые включают в себя ссылки на name-сервера дочерних зон.

Относящиеся к ним ресурсные записи. Они определяют расположение серверов, перечисленных в ресурсных записях NS.

Ресурсную запись DS, которая включает в себя хэш KSK дочерней зоны.

Ресурсную запись RRSIG, которая является подписью для ресурсной записи DS.



Просуммируем дополнительные задачи, которые имеют место при глобально безопасной зоне.



Безопасная пересылка открытого ключа KSK зоны своему родителю. Данная пересылка выполняется внешним способом и может не включаться ни в какие DNS-транзакции.

Родитель создает хэш открытого ключа KSK дочерней зоны и хранит хэш в ресурсной записи DS. Родитель также создает цифровую подпись (ресурсную запись RRSIG) для данной ресурсной записи DS. Эта запись включается в информацию делегирования.

Зона, подписывающая ответ, является конечной точкой в цепочке доверия. Предварительно необходимо установить доверие к ZSK для зоны. Доверие к ZSK зоны устанавливается посредством следующих операций:

получение аутентифицированной ссылки от родителя;

аутентификация KSK дочерней зоны.

Для понимания обработки аутентифицированной ссылки, которая находится у родителя, необходимо посмотреть, как обрабатывается обычная ссылка DNS. В обычном DNS-запросе зона, которая не имеет авторитетной информации, относящейся к запросу для доменного имени в дочерней зоне, предоставляет ссылку, указывая множество ресурсных записей NS и соответствующие относящиеся к ним ресурсные записи (ресурсные записи, которые содержат IP-адреса серверов, указанных в ресурсных записях NS). При обычной обработке DNS-запроса следование по этим ссылкам будет следующим шагом обработки. Однако данный процесс является недостаточным с точки зрения установления цепочки доверия; информация о множестве ресурсных записей NS и связанных с ними ресурсными записями не может считаться аутентичной, потому что они не подписаны закрытым ключом аутентичного источника. Аутентификацию данной информации о ссылке родитель предоставляет криптографическим способом с помощью ресурсной записи DS.

Рассмотрим пример того, как поддерживающий DNSSEC resolver проверяет правильность DNS-ответа от подписанной зоны example.ru. Resolver, следуя по своей цепочке доверия, начинающейся от доверенного anchor’а, аутентифицирует открытый ключ для зоны .ru и тем самым доверяет ему.

Создание пары открытый / закрытый ключи (DNSSEC-ОР1)

DNSSEC определяет создание и проверку цифровых подписей с использованием асимметричных ключей. Это требует создания пары открытый / закрытый ключи. Для облегчения операций администрирования, которые должны выполняться периодически, таких как обновление ключа и переподписывание зоны, необходимо иметь два различных типа ключей. Один тип ключа называется Key Signing Key (KSK Ключ данного типа (а именно, закрытый ключ, называемый KSK-private) будет использоваться только для подписывания ключа, содержащегося в зонном файле в ресурсной записи с типом DNSKEY. Другой тип ключа называется Zone Signing Key (ZSK) (соответствующий закрытый ключ называется ZSK-private). Этот ключ используется для подписывания всех множеств ресурсных записей в зоне (включая множество ресурсных записей DNSKEY). Административное разграничение между KSK- и ZSK-ключами осуществляется с помощью флага Secure Entry Point (SEP) в ресурсной записи DNSKEY, который присутствует в открытых ключах, называемых KSK-public и ZSK-public, соответственно.

Причина, лежащая в основе создания двух типов пар ключей, состоит в определении отдельного набора функций для каждого типа ключа для того, чтобы уменьшить сложность задач, связанных с обновлением ключей и переподписыванием зоны. KSK (KSK-private) используется для подписывания множества ключей (т.е. множества ресурсных записей DNSKEY) и является тем ключом, который передается родительской зоне для использования его при аутентифицированном делегировании. Аутентифицированное делегирование выполняется посредством создания ресурсной записи DS, содержащей хэш дочернего KSK-public ключа, и затем создания соответствующей подписи (ресурсной записи RRSIG), используя свой собственный ZSK-private. Ключ KSK (KSK-public) также может использоваться в качестве доверенного anchor для установления доверенных цепочек при проверки подписей.

Ключ ZSK (ZSK-private) применяется для подписывания зонного файла (всех множеств ресурсных записей). Открытый ключ (ZSK-public) не посылается родителю, он всегда хранится в зоне.

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

алгоритм цифровой подписи;длину ключа;период, в течение которого ключ будет использоваться.

Выбор алгоритма цифровой подписи основывается на принятых стандартах. Обычно рассматриваются следующие алгоритмы:

DSA;RSA;Elliptic Curve DSA (ECDSA).

Из этих трех алгоритмов наиболее широко распространены RSA и DSA. С точки зрения производительности RSA и DSA имеют сопоставимую скорость создания подписи, но DSA является более медленным при проверке, а RSA — более быстрым. Единственным обязательным для реализации в DNSSEC алгоритмом является RSA с MD5. Считается, что как минимум name-серверы и клиенты должны иметь возможность использовать RSA. Предполагается, что по крайней мере один ZSK для зоны использует алгоритм RSA.

Выбор длины ключа определяется соотношением между риском компрометации ключа и производительностью. Производительность определяется временем создания подписи и временем проверки подписи. Длина пакета DNS-ответа также должна учитываться, потому что ресурсные записи DNSKEY посылаются в дополнительном разделе DNS-ответа. Так как ключ KSK используется только для подписывания множества ключей (множества ресурсных записей DNSKEY), в этом случае производительность не является решающим фактором. Однако компрометация ключа KSK может иметь большее негативное воздействие, так как этот ключ является фактически мастер-ключом для зоны. Компрометация ключа KSK в зоне, расположенной высоко в DNS-иерархии, может подвергнуть большую часть DNS-поддерева (следовательно, большое число зон) spoofing атакам. Кроме того, обновление ключа KSK в случае компрометации означает изменение доверенных anchor’ов во многих name-серверах и resolver’ах. Тем самым для KSK рекомендуется большая длина ключа: он имеет небольшое воздействие на производительность, но чувствителен к компрометации.

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


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

алгоритм цифровой подписи;длину ключа;период, в течение которого ключ будет использоваться.

Выбор алгоритма цифровой подписи основывается на принятых стандартах. Обычно рассматриваются следующие алгоритмы:

DSA;RSA;Elliptic Curve DSA (ECDSA).

Из этих трех алгоритмов наиболее широко распространены RSA и DSA. С точки зрения производительности RSA и DSA имеют сопоставимую скорость создания подписи, но DSA является более медленным при проверке, а RSA — более быстрым. Единственным обязательным для реализации в DNSSEC алгоритмом является RSA с MD5. Считается, что как минимум name-серверы и клиенты должны иметь возможность использовать RSA. Предполагается, что по крайней мере один ZSK для зоны использует алгоритм RSA.

Выбор длины ключа определяется соотношением между риском компрометации ключа и производительностью. Производительность определяется временем создания подписи и временем проверки подписи. Длина пакета DNS-ответа также должна учитываться, потому что ресурсные записи DNSKEY посылаются в дополнительном разделе DNS-ответа. Так как ключ KSK используется только для подписывания множества ключей (множества ресурсных записей DNSKEY), в этом случае производительность не является решающим фактором. Однако компрометация ключа KSK может иметь большее негативное воздействие, так как этот ключ является фактически мастер-ключом для зоны. Компрометация ключа KSK в зоне, расположенной высоко в DNS-иерархии, может подвергнуть большую часть DNS-поддерева (следовательно, большое число зон) spoofing атакам. Кроме того, обновление ключа KSK в случае компрометации означает изменение доверенных anchor’ов во многих name-серверах и resolver’ах. Тем самым для KSK рекомендуется большая длина ключа: он имеет небольшое воздействие на производительность, но чувствителен к компрометации.

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

Список операций DNSSEC

Ответ, пришедший из подписанной зоны, называется подписанным ответом. Resolver, который имеет возможность проверять подписи в подписанном ответе, называется поддерживающий DNSSEC validating resolver. Прежде чем resolver сможет проверить подпись, созданную для множества ресурсных записей и полученную им в ответе, используя открытый ключ зоны, посланный в ответе, он должен установить доверие к этому открытому ключу. В DNSSEC данное требование означает, что resolver должен выполнить так называемое построение доверенной цепочки. Для этого resolver рассматривает список известных доверенных ключей (называемых trust anchors) и создает цепочку открытых ключей, с помощью которой он устанавливает доверие к открытому ключу зоны, полученному им в ответе. Для построения цепочки используется иерархия пространства имен DNS. В идеале trust anchors в resolver’е содержат открытые ключи root’а (если root-сервер поддерживает DNSSEC или открытые ключи зон, расположенных ниже в иерархии. Список trust anchors в resolver’е не строится с помощью транзакций DNS; для этого используется некоторый внешний механизм.

Процессы DNSSECописанные выше, включают несколько операций name-сервера и несколько операций resolver’а. Операциями name-сервера являются следующие:

DNSSEC-ОР1: создание пары открытый – закрытый ключ.DNSSEC-ОР2: безопасное хранение закрытых ключей.DNSSEC-ОР3: распространение открытого ключа.DNSSEC-ОР4: подписывание зоны.DNSSEC-ОР5: обновление ключа (изменение ключа).DNSSEC-ОР6: переподписывание зоны.

Операциями resolver’а являются:

DNSSEC-ОР7: конфигурирование доверенных anchors.DNSSEC-ОР8: создание цепочки доверия и проверка подписи.

Операции name-сервера с DNSSEC-ОР1 по DNSSEC-ОР4 и операции resolver’а DNSSEC-ОР7 и DNSSEC-ОР8 выполняются либо перед развертыванием DNSSEC, либо перед операциями обеспечения безопасности запросов и ответов (таких как обработка подписанных ответов и проверка подписей). Рассмотрим эти операции в первую очередь. Оставшиеся операции name-сервера (обновление ключа и переподписывание зоны – DNSSEC-ОР5 и DNSSEC-ОР6 соответственно) выполняются периодически после полного развертывания DNSSEC и будут приведены в конце лекции.

Типы записей, используемых DNSSEC

Первой задачей является создание цифровых подписей для ресурсных записей в зонном файле. DNSSEC предполагает создание подписи для всего RRSet (множества ресурсных записей c одним и тем же именем владельца, классом и типом), а не для каждой ресурсной записи. Цифровая подпись и связанная с ней информация (ID использованного ключа, признаки начала и конца подписываемого блока и т.п.) содержатся в специальной ресурсной записи RRSIG. Строка, содержащая открытый ключ, который используется для проверки подписи (в RRSIG), содержится в ресурсной записи с типом DNSKEY. Другой тип ресурсной записи, NSEC (Next Secure) используется для перечисления типов ресурсных записей (в каноническом порядке), существующих в данном домене. Подписи (т.е. ресурсные записи RRSIG) для данного типа ресурсных записей создаются, кроме того, для обеспечения аутентифицированного доказательства невозможности создания ответов на запросы для несуществующего типа ресурсных записей. Дополнительно существует необязательный тип ресурсной записи DS (Delegation Signer) для случая, когда зона хочет разрешать выполнить проверку подлинности открытых ключей своих дочерних зон. Детальный синтаксис каждого из этих дополнительных типов ресурсных записей, введенных спецификацией DNSSECуказан в RFC 4034. Самой важной из них является ресурсная запись RRSIG, потому что именно она содержит строку подписи.

Ресурсная запись RRSIG, подобно другим ресурсным записям, содержит поля имени собственника, TTL, класс, RRType и RDATA. Цифровая подпись и вся связанная с ней информация находится в поле RDATA. Расположение поля RDATA в ресурсной записи RRSIG со всеми подполями показано ниже. Также приведено краткое описание каждого подполя.

Содержимое поля RDATA в ресурсной записи RRSIG

RRRtype Covered	Algorihm Code	Labels
Original TTL
Signature Expiration
Signature Inception
Key Tag		Signer's NAme
Encoded Signature

Поле RRType Covered имеет тип ресурсной записи, для которого RRSIG содержит подпись.

Поле Algorithm Code есть целое число, равное коду соответствующего криптографического алгоритма, использованного для создания подписи.

Поля Labels и Original TTL содержат количество ресурсных записей, для которых создана подпись, и значение TTL для множества ресурсных записей, для которых создана данная подпись.

Значения Signature Expiration и Signature Inception являются абсолютными значениями времени, которые определяют период действительности подписи, – период времени, в течение которого данная RRSIG считается действительной для зоны.

Поля Key Tag и Signer’s Name являются хэшем и доменным именем (FQDN) для ресурсной записи DNSKEY, которая будет использоваться клиентом для проверки действительности подписи.

Наконец, последнее поле содержит саму подпись.

Зона, которая содержит эти дополнительные ресурсные записи наряду с обычными ресурсными записями, называется подписанной зоной. Name-сервер, который создает такие подписанные зоны и включает в свой ответ соответствующие подписи (т.е. соответствующие RRSIG) вместе в запрошенными ресурсными записями, называется поддерживающим DNSSEC name-сервером.

Удаление домена из зоны

Предположим, предприятие решило, что все продажи теперь будут осуществляться только через Интернет. Так как хосты были созданы для выполнения данной функции в новом домене websales.example.ru, хосты в домене sales.example.ru больше не нужны. Поэтому все ресурсные записи, принадлежащие домену, должны быть удалены из зоны. Данное изменение включает следующие операции:

NSEC-ресурсная запись, соответствующая удаляемому домену, должна быть удалена, т.е. NSEC-ресурсная запись, относящаяся к домену sales.example.ru, удаляется;

NSEC-ресурсная запись, относящаяся к домену, непосредственно предшествующему удаленному домену, модифицируется таким образом, чтобы указывать на домен, непосредственно следующий за удаленным доменом (т.е. запись должна указывать на ту, на которую указывала удаленная NSEC-ресурсная запись). В данном случае NSEC-ресурсная запись для marketing.example.ru должна указывать на домен websales.example.ru следующим образом:

marketing.example.ru IN NSEC websales.example.ru (A MX RRSIG NSEC)

Удаление некоторого типа ресурсной записи из существующего домена

Предположим, что предприятие example.ru решило, что больше не требуется отдельного почтового сервера для сотрудников отдела маркетинга. Такое изменение требует удаления почтового сервера (RRType = MX) из домена marketing.example.ru. Модифицированная NSEC-ресурсная запись теперь выглядит следующим образом:

marketing.example.ru IN NSEC sales.example.ru (A RRSIG NSEC)

Утечка информации и Informational RRTypes

Существует несколько типов ресурсных записей, которые сообщают информацию о сети, хостах или сервисах. К этим ресурсным записям относятся Responsible Person (RP) запись, Host Information (HINFO) запись, Location (LOC) запись и различные Text рекурсивные записи (TXT). Хотя данные типы записей предназначены для информирования пользователей, не имеющих плохих намерений, они также позволяют атакующему получить информацию о хостах в локальной сети для того, чтобы попытаться использовать их уязвимости. Например, атакующий может запросить HINFO-записи, просмотреть перечисленные хосты и определить ОС и платформы, которые имеют известные уязвимости. Следовательно, следует быть очень осторожным, включая данные типы записей в зонный файл.

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

Администратор DNS не должен включать в зонный файл или во внешний view зоны (если используется split DNS) HINFO, RP, LOC или другие типы ресурсных записей, которые могут разглашать информацию, полезную атакующему.

Администратор DNS должен просмотреть все данные, которые содержатся в ресурсной записи TXT, для проверки возможной утечки информации, перед тем как добавлять их в зонный файл.

Выбор значений параметров в SOA RR

Первое действие, которое должен предпринять администратор DNS, – это гарантировать, что значения данных ресурсной записи SOA являются корректными. Значения в данной ресурсной записи определяют взаимодействие между первичным и вторичными серверами в зоне, а именно, с какой периодичностью вторичные серверы должны выполнять зонные пересылки с первичного сервера. Эти данные также содержат минимальное значение TTL, которое говорит клиентским resolver’ам, как долго находятся данные в кэше. Смысл этих полей следующий:

Serial Number. Serial number в SOA RDATA используется для указания вторичным серверам, что произошли изменения в зоне и зонная пересылка должна быть выполнена. Данное значение должно возрастать при изменении данных в зоне.

Refresh Value. Refresh value говорит вторичным серверам, сколько секунд проходит между зонными пересылками. Для зон, которые часто обновляются, данное значение должно быть маленьким (от 20 минут до 2 часов). Для зон, которые обновляются не часто, может быть указано большее число (от 2 до 12 часов). Для подписанных зон данное значение не должно быть больше, чем длина периода действительности RRSIG, чтобы гарантировать, что вторичные зоны не содержат зон с истекшими RRSIG. Данное значение также может зависеть от ограничений, связанных с шириной пропускания на стороне первичного сервера. Заметим, что если первичный сервер создает сообщение NOTIFY при своем обновлении, вторичный сервер будет немедленно выполнять зонную пересылку и не ждать, пока нужно будет обновлять с соответствии со значением refresh.

Retry Value. Retry value является периодом времени, через который вторичный сервер должен попытаться выполнить зонную пересылку, если предыдущая попытка окончилась неудачно. Данное значение должно быть делителем значения refresh. Возможный диапазон значений для данного поля может быть от 5 минут до 1 часа.

Expire Value. Expire value является временем, в течение которого вторичный сервер должен считать зонную информацию действительной, если он не может установить соединение с первичным сервером для получения обновления.
Данное поле позволяет вторичным серверам продолжать функционировать при различных сетевых сбоях. Значение зависит от частоты изменений в зоне и надежности соединения между name-серверами, оно может быть от 2 до 4 недель.

Minimum TTL. Значение minimum TTL является значением по умолчанию для всех множеств ресурсных записей в зоне, если они сами не имеют собственного значения TTL, указанного в зонном файле. Данное значение зависит от того, как часто информация изменяется в зоне. Если зона статическая, значение может быть большим; если динамическая, значение должно быть маленьким. Однако для зон, которые используют DNSSECзначение должно быть достаточно большим, чтобы информация оставалась в кэше до тех пор, пока она является действительной. Считается, что минимальным значением должно быть 30 секунд, рекомендуемый диапазон – от 30 минут до 5 дней.

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



Значение refresh в SOA ресурсной записи зоны должно быть выбрано в зависимости от частоты обновлений. Если зона подписана, значение refresh должно быть меньшим, чем период действительности RRSIG.



Значение retry в SOA ресурсной записи зоны должно равняться 1/10 от значения refresh.



Значение expire в SOA ресурсной записи зоны должно быть от 2 до 4 недель.



Минимальное значение TTL должно быть между 30 секундами и 24 часами, чтобы гарантировать, что устаревшие множества ресурсных записей будут очищены из кэшей клиентов.

Альтернативные платформы для web-сервера

Часто web-серверы выполняются на ОС общего назначения. В то же время существуют примеры, когда используется одна из альтернатив, обсуждаемых ниже. Хотя данные средства являются относительно новыми для web-серверов, они основаны на надежных технологиях и, возможно, скоро найдут широкое применение для использования в качестве окружения web-сервера.

Безопасное инсталлирование и конфигурирование web-сервера

После того как ОС инсталлирована и сделана безопасной, следует инсталлировать выбранное ПО web-сервера. Перед началом данного процесса следует прочитать документацию производителя и понять, какие опции доступны при инсталляции. Также следует посетить web-сайт производителя или web-сайт базы данных уязвимостей, такой как ICAT метабаза (http://icat.nist.gov), для определения всех известных уязвимостей и соответствующих patches, которые должны быть инсталлированы или сконфигурированы как часть процесса установки. Только после завершения этих предварительных шагов следует начать инсталляцию. Будем обсуждать только общие процедуры инсталляции и конфигурирования.

Безопасное инсталлирование web-сервера

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

Инсталлировать ПО сервера на выделенный хост.Инсталлировать минимально требуемые сервисы Интернета.Применить все patches или upgrades для корректировки известных уязвимостей.Создать выделенный физический диск или логический раздел (отдельный от ОС и приложения сервера) для содержимого web.

Удалить или запретить все web-сервисы, инсталлированные приложением web-сервера, но не требуемые (например, gopher, FTP и удаленное администрирование).

Из корневой директории приложения web-сервера удалить все файлы, которые не являются частью web-сайта. Удалить всю документацию, а также примеры скриптов и выполняемого кода.

Выполнить разного рода образцы безопасности или "hardening" скрипты, усиливающие безопасность web-сервера.

Переконфигурировать баннер НТТР-сервиса (и других сервисов, если они используются), чтобы он не сообщал о типе и версии web-сервера и ОС. Это может быть выполнено в IIS использованием свободного Microsoft IIS Lockdown Tool и в Apache посредством "ServerTokens" директивы.

Безопасность лежащей в основе ОС

Первым шагом в обеспечении безопасности web-сервера является безопасность лежащей в его основе ОС. Большинство общедоступных web-серверов функционируют на ОС общего назначения. Многих проблем безопасности можно избежать, если ОС соответствующим образом сконфигурирована. Конфигурации по умолчанию аппаратуры и ПО обычно поставляются производителями с упором на возможности безопасного функционирования и возможности легкого расширения. Так как производители не знают потребности безопасности каждой организации, каждый web-администратор должен сконфигурировать новые серверы в соответствии с требованиями безопасности своей организации.

Данная технология в различных ОС может сильно отличаться. Также могут существовать некоторые автоматизированные инструментальные средства для настройки ОС с точки зрения безопасности.

Выбор приложения web-сервера может определяться выбором ОС. Однако по возможности web-администраторы должны выбрать ОС, которая обеспечивает следующее:

возможность ограничить деятельность административного уровня или уровня root только авторизованными пользователями;возможность управлять доступом к данным на сервере;возможность запретить сетевые сервисы, не являющиеся необходимыми, которые встроены в ПО ОС или сервера;возможность управления доступом к различным формам выполнимых программ, таких как CGI-скрипты и plug-ins, на стороне сервера;возможность записывать в лог соответствующую деятельность сервера для определения проникновения и попыток проникновения.

Использование Appliances для web-сервера

Относительно недавние разработки в области web-серверов привели к появлению так называемых web Appliances. Web Appliances является комбинацией ПО и аппаратуры, которая разработана, чтобы быть "plug-and-play" web-сервером. Эти Appliances используют упрощенную ОС, которая оптимизирована для поддержки web-сервера. Упрощенная ОС обеспечивает безопасность, минимизируя возможности, сервисы и опции, которые не являются необходимыми для web-приложений. ПО web-сервера в таких системах часто заранее инсталлировано и заранее сконфигурировано с точки зрения безопасности.

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

Самым большим недостатком таких систем является то, что они не подходят для больших сложных и многоуровневых web-сайтов. Они могут также не подойти организациям, которым требуется более одного сервера, если только организация не захочет покупать web Appliances от одного производителя, так как такая простота делает трудным конфигурирование вместе web Appliances от разных производителей. Web Appliances доступны от основных производителей аппаратуры и от различных специализированных производителей web Appliances.

Некоторые вопросы, которые следует рассматривать при принятии решения о покупки web Appliances:

какая ОС лежит в основе и как она протестирована с точки зрения безопасности;

как web Appliance само протестировано с точки зрения безопасности. (Заметим, что конфигурационные опции web Appliances являются ограниченными, таким образом, web Appliance обычно бывает безопасным только при инсталляции по умолчанию);

какова разнородность инфраструктуры web-сервера организации. (Различные торговые марки web Appliances, как правило, не очень хорошо работают вместе);

имеется ли возможность какого-либо расширения web Appliances. (Организация, которая предполагает быстрый рост, может не захотеть ограничивать себя web Appliance).

Использование программ проверки целостности файлов

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

Хотя программа проверки целостности и является полезным инструментальным средством, которое не требует большого участия человека, для гарантии эффективности она должна использоваться продуманно.

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

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

Программа проверки целостности файлов может также создавать ложные позитивные предупреждения. Каждое изменение файла и каждый системный patch изменяет файл и, следовательно, требуется изменить базу данных контрольных сумм. Таким образом, держать базу данных актуальной может быть непросто.

Однако, даже если программа проверки целостности выполняется только один раз (при первой инсталляции системы), она может быть полезна для определения того, какие файлы были модифицированы в случае предполагаемой компрометации. Наконец, атакующий может так модифицировать файл, что использование 32-битной циклической контрольной суммы (Cyclic Redundancy Check – CRC) не определит модификацию. Следовательно, рекомендуются более сильные алгоритмы подсчета контрольных сумм для гарантирования целостности данных.

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

Конфигурирование аутентификации пользователя в ОС

Авторизованных пользователей, которые могут конфигурировать систему и запускать различные сервисы, обычно очень мало. Однако пользователей, которые могут иметь доступ к публичному web-серверу, может быть как неограниченное количество, так и некоторое ограниченное подмножество Интернет-сообщества. Для обеспечения политики безопасности web-администратор должен сконфигурировать систему для аутентификации пользователей, которым разрешен вход, требуя предоставления доказательства своей идентификации. Даже если web-сервер разрешает неаутентифицированный доступ к большинству сервисов, администрирование и другие типы специализированного доступа должны быть ограничены определенными персонами или ролями.

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

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

Удалить или запретить неиспользуемые аккаунты и группы, созданные по умолчанию. Конфигурация ОС по умолчанию часто включает аккаунт guest (как с паролем, так и без), аккаунты уровня администратора или root, связанные с локальными и сетевыми сервисами. Имена и пароли этих аккаунтов хорошо известны. Удаление или запрещение ненужных аккаунтов предотвращает их использование для проникновения, включая аккаунты guest, на компьютерах, содержащих чувствительную информацию. Если существует требование оставить аккаунт или группу guest, следует ограничить их доступ и изменить пароль в соответствии с политикой для паролей в организации.
Для аккаунтов по умолчанию, которые необходимо оставить, следует изменить имена (где возможно, особенно для аккаунтов уровня администратора или root) и пароли в соответствии с политикой для паролей. Следует помнить, что имена аккаунтов и пароли по умолчанию хорошо известны злоумышленникам.

Запретить неинтерактивные аккаунты. Запретить аккаунты (и связанные с ними пароли), которые должны существовать, но не требуют интерактивного входа. Для Unix-систем запретить входной shell или предоставить входной shell с функциональностью NULL (/bin/false).

Создать группы пользователей. Привязать пользователей к соответствующим группам и назначать права группам. Данный подход предпочтительнее, чем назначать права индивидуальным пользователям.

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

Проверить политику для паролей в организации. Установить пароли аккаунтов соответствующим образом. Данная политика должна рассматривать следующее:



длина – минимальная длина паролей;

сложность – требуемые символы. Требуемые пароли содержат буквы как верхнего, так и нижнего регистров и, по крайней мере, один неалфавитный символ;

срок использования – как долго можно не изменять пароль. Требовать от пользователей периодически изменять пароли. Пароль уровня администратора или root должен изменяться каждые 30–120 дней. Пароль пользователя также должен периодически изменяться. Этот период определяется длиной и сложностью пароля в сочетании с чувствительностью защищаемой им информации;

переиспользуемость – может ли пароль переиспользоваться. Некоторые пользователи пытаются обойти требование устаревания пароля, изменяя пароль на тот, который они уже использовали до этого. Нужно по возможности гарантировать, что пользователь не может изменить пароль простым добавлением "предполагаемых" символов к своему исходному паролю. Например, исходный пароль был "mysecret", а измененный – "mysecret1" или "1mysecret";



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

Запретить неинтерактивные аккаунты. Запретить аккаунты (и связанные с ними пароли), которые должны существовать, но не требуют интерактивного входа. Для Unix-систем запретить входной shell или предоставить входной shell с функциональностью NULL (/bin/false).

Создать группы пользователей. Привязать пользователей к соответствующим группам и назначать права группам. Данный подход предпочтительнее, чем назначать права индивидуальным пользователям.

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

Проверить политику для паролей в организации. Установить пароли аккаунтов соответствующим образом. Данная политика должна рассматривать следующее:



длина – минимальная длина паролей;

сложность – требуемые символы. Требуемые пароли содержат буквы как верхнего, так и нижнего регистров и, по крайней мере, один неалфавитный символ;

срок использования – как долго можно не изменять пароль. Требовать от пользователей периодически изменять пароли. Пароль уровня администратора или root должен изменяться каждые 30–120 дней. Пароль пользователя также должен периодически изменяться. Этот период определяется длиной и сложностью пароля в сочетании с чувствительностью защищаемой им информации;

переиспользуемость – может ли пароль переиспользоваться. Некоторые пользователи пытаются обойти требование устаревания пароля, изменяя пароль на тот, который они уже использовали до этого. Нужно по возможности гарантировать, что пользователь не может изменить пароль простым добавлением "предполагаемых" символов к своему исходному паролю. Например, исходный пароль был "mysecret", а измененный – "mysecret1" или "1mysecret";

Конфигурирование управления доступом

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

ограничение доступа ПО web-сервера к подмножеству вычислительных ресурсов средствами управления доступом ОС;

ограничение доступа пользователей посредством дополнительного управления доступом, обеспечиваемым web-сервером, когда требуются более детальные уровни управления доступом.

Соответствующая установка управления доступом может помочь предотвратить раскрытие чувствительной информации, которая не предназначена для публичного распространения. Дополнительно управление доступом может быть использовано для ограничения использования ресурсов в случае DoS-атаки на публичный web-сайт.

Обычно файлами, доступ к которым должен контролироваться, являются следующие:

ПО и конфигурационные файлы приложения.

Файлы, непосредственно использующиеся механизмами безопасности:

файлы хэшей паролей и другие файлы, используемые при аутентификации;файлы, которые содержат авторизационную информацию, используемую при управлении доступом;криптографический материал ключа, используемый в сервисах конфиденциальности, целостности и невозможности отказа.

Логи сервера и файлы системного аудита.Системное ПО и его конфигурационные файлы.

Планирование развертывания web-сервера

При планировании развертывания web-сервера следует рассмотреть следующие пункты:

Определить цели web-сервера;

Какие категории информации будут храниться в web-сервере.

Какие категории информации будут обрабатываться или передаваться через web-сервер. Каковы требования безопасности для данной информации.Существует ли информация, которая получена с другого сервера или хранится на другом сервере (например, backend база данных, почтовый сервер, прокси-сервер).

Какие еще сервисы предоставляет web-сервер (должен ли web-сервер выполняться на выделенном хосте). Каковы требования безопасности для этих дополнительных сервисов.

Определить сетевые сервисы, которые будет предоставлять web-сервер, и используемые при этом протоколы:

НТТР, НТТРS, SOAP и т.п. – протоколы взаимодействия с клиентами.ODBC, JDBC, LDAP, LDAPS, NFS и т.п. – протоколы взаимодействия с backend-системами.

Определить все необходимое ПО, которое требуется для поддержки функционирования web-сервера;

Определить категории пользователей web-сервера и всех backend-систем;

Определить способы аутентификации пользователей и web-сервера и способы защиты аутентификационных данных; Определить, как будет предоставляться соответствующий доступ к информационным ресурсам.

Причины уязвимости web-сервера

Основные проблемы, связанные с безопасностью функционирования публично доступного web-сайта, возникают по следующим причинам:

Неправильная конфигурация или другое некорректное действие над web-сервером, которое может привести к раскрытию или изменению информации.

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

Неадекватные механизмы защиты web-сервера, предусмотренные в его окружении.

ПО на стороне сервера (скрипты, JSP, ASP и т.п.), которое содержит ошибки, позволяющие атакующим компрометировать безопасность web-сервера.

Применение Patch и Upgrade ОС

После того как ОС инсталлирована, следует применить все patches и upgrades для удаления известных уязвимостей. Все ОС, реализованные сегодня, имеют известные уязвимости, которые должны быть удалены перед использованием ОС в качестве хоста web-сервера. Для адекватного определения и корректирования этих уязвимостей web-администратор должен:

идентифицировать уязвимости и применить patches;смягчить уязвимости, для которых пока patches еще не доступны, не протестированы или не установлены;проводить регулярное инсталлирование fixes (часто называемых patches, hotfixes, service packs или updates).

Разграничение доступа для ПО web-сервера

Первый шаг в конфигурировании управления доступа состоит в гарантировании того, что web-сервер выполняется только от имени пользователя и группы, которые специально созданы для этого и имеют очень ограниченные права доступа. Таким образом, должны быть введены специальные идентификаторы пользователя и группы, используемые исключительно ПО web-сервера. Новый пользователь и новая группа должны быть уникальными и независимыми от всех остальных пользователей и групп. Это необходимо для реализации управления доступом, описанного далее. Хотя сервер может начинать выполняться как root (Unix) или system/administrator (Windows NT/2000/XP) для привязки к ТСР-порту 80 и/или 443 (используемому для предоставления НТТР и НТТРS-сервисов соответственно), не следует допускать, чтобы сервер продолжал выполняться на данном уровне доступа.

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

процессы web-сервера должны быть сконфигурированы для выполнения от имени пользователя с очень ограниченным множеством привилегий (т.е. не выполняться как root, администратор или эквивалентные пользователи);

к файлам содержимого web-сайтов процессы web-сервера должны иметь доступ по чтению, но не по записи;

процессы web-сервера не должны иметь возможность записи в директории, в которых хранится публичное содержимое web-сайтов;

только процессы, авторизованные как администратор web-сервера, могут писать в файлы web-содержимого;

приложение web-сервера может писать в файлы логов web-сервера, но лог-файлы не могут читаться приложением web-сервера. Только процессы уровня root/system/administrator могут читать лог-файлы web-сервера;

временные файлы, создаваемые приложением web-сервера, например, те, которые возникают при формировании динамических web-страниц, должны быть расположены в специальной и соответствующим образом защищенной поддиректории;

доступ к любым временным файлам, созданным приложением web-сервера, ограничен процессами, которые создали эти файлы.

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

Для уменьшения воздействия основных типов DoS-атак нужно сконфигурировать web-сервер с ограниченным количеством ресурсов ОС, которые он может использовать. Чаще всего необходимо совершить следующие действия:



инсталлировать содержимое web на отдельном жестком диске или логическом разделе от ОС и web-приложения;

если допустимы загрузки (uploads) на web-сервер, установить ограничение на объем дискового пространства, которое выделяется для этой цели;

если допустимы загрузки (uploads) на web-сервер, эти файлы не должны быть сразу же читаемы web-сервером и, тем самым, видимы пользователям по протоколу НТТР. Они должны быть читаемы web-сервером только после некоторого автоматизированного или ручного процесса просмотра. Это предотвращает от использования web-сервера для передачи пиратского ПО, инструментальных средств атак, порнографии и т.п.;

гарантировать, что лог-файлы хранятся в соответствующем месте, в котором они не смогут исчерпать ресурсы файловой системы.

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

Дополнительно часто бывает необходимо сконфигурировать таймауты и другие способы управления для дальнейшего уменьшения влияния основных DoS-атак.


Один из типов DoS-атаки состоит в том, чтобы одновременно устанавливать сетевые соединения сверх максимально допустимого, чтобы никакой новый законный пользователь не мог получить доступ. Когда таймауты установлены на сетевые соединения (время, после которого неактивное соединение сбрасывается) в минимально допустимое ограничение, существующие соединения будут завершаться по таймауту так быстро, как только возможно, создавая возможность устанавливать новые соединения законным пользователям. Данная мера только смягчает DoS-атаку, но не уничтожает ее.

Если максимальное число открытых соединений (или соединений, которые являются полуоткрытыми, – это означает, что первая часть ТСР-рукопожатия завершилась успешно) установить в наименьшее число, атакующий может легко израсходовать доступные соединения ложными запросами (часто называемыми SYN flood). Установка в максимум данного числа может смягчить эффект такой атаки, но ценой расходования дополнительных ресурсов. Заметим, что это является проблемой только тех web-серверов, которые не защищены firewall’ом, останавливающим SYN flood атаки. Большинство современных firewall’ов защищают web-сервер от SYN flood атаки, прерывая ее прежде, чем она достигнет web-сервера.

Специально усиленные (pre-hardened) ОС и web-серверы

Сегодня распространяется всё возрастающее число специально усиленных ОС и пакетов web-сервера. Эти пакеты включают ОС и ПО web-сервера, которые модифицированы и заранее сконфигурированы для обеспечения большой безопасности. Некоторые из этих пакетов содержат и аппаратную платформу, другие являются ПО, которое состоит только из ОС и ПО web-сервера. Эти дистрибутивы обычно основаны на специально усиленной и/или модифицированной ОС общего назначения (например, Linux, Unix и, реже, Windows), которая специально разработана для поддержки безопасного web-сервера. Приложение web-сервера также часто основано на усиленном и/или модифицированном обычном ПО web-сервера например, Apache или IIS). Эти пакеты зачастую включают большее число опций безопасности и разработаны для более легкого конфигурирования с помощью заранее cкомпилированных скриптов и GUIs. Хотя все пакеты различны, они обычно обеспечивают какие-либо из следующих возможностей:

безопасная начальная конфигурация обеспечена по умолчанию;

наличие усиленной ОС и/или TOS– наличие усиленного ПО web-сервера; расширяемые возможности аудита;наличие разного рода оберток (wrappers) для приложений;наличие возможностей сетевых wrappers и/или host-based firewall;host-based IDS;упрощенное администрирование безопасности (например, меню, GUIs).

Эти типы систем должны быть рассмотрены организацией, которая понимает важность угроз и/или имеет важные данные на web-сайтах (например, правительственные организации, банки и т.п.). Такие пакеты доступны от некоторых основных производителей аппаратуры и ПО, а также от некоторых специализированных производителей.

Некоторые вопросы, которые следует рассмотреть при приобретении усиленного web Appliance.

Какая ОС лежит в основе и как она протестирована относительно безопасности.

Как само ПО web-сервер протестировано относительно безопасности. Насколько трудно его администрировать.

Совместимо ли усиленное ПО web-сервер с существующими в организации web-приложениями и скриптами.

Список действий для безопасного инсталлирования и конфигурирования web-сервера

Безопасное инсталлирование web-сервера.

Инсталлировать ПО сервера на выделенный хост.Инсталлировать минимально требуемые сервисы Интернета.Применить все patches и upgrades для устранения известных уязвимостей.Создать выделенный физический диск или логический раздел (отдельно от ОС и приложения сервера) для web-содержимого.

Удалить или запретить все сервисы, инсталлированные приложением web-сервера, но в данном случае не требуемые (например, gopher, FTP и удаленное администрирование). Удалить все примеры страниц, скриптов и выполняемого кода.Удалить с сервера всю документацию производителя.Протестировать сервер, применив различные образцы безопасности или скрипты взлома.

Переконфигурировать баннер НТТР-сервиса (и баннеры других сервисов, если требуется), чтобы он не сообщал о типе и версии web-сервера и ОС.

Конфигурирование управления доступом web-сервера со стороны ОС.

Сконфигурировать доступ к файлам со стороны ОС так, чтобы процессы web-сервера могли только читать файлы web-содержимого, но не могли записывать в них.

Сконфигурировать доступ к файлам со стороны ОС так, чтобы процессы web-сервера не могли записывать в директории, в которых расположено содержимое web.

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

– Сконфигурировать доступ к файлам со стороны ОС так, чтобы web-приложение могло писать в лог-файлы web-сервера, но лог-файлы не могли быть читаемы приложением web-сервера.

Сконфигурировать доступ к файлам со стороны ОС так, чтобы временные файлы, создаваемые приложением web-сервера, были расположены только в указанной и соответствующим образом защищенной поддиректории.

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

Инсталлировать web-содержимое на отдельном жестком диске или логическом разделе, отличном от ОС и web-приложения.

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

Сконфигурировать доступ к файлам со стороны ОС так, чтобы лог-файлы имели соответствующий максимальный размер.

Конфигурирование безопасной директории web-содержимого.



Выделить отдельный жесткий диск или логический раздел для web-содержимого и установить соответствующие поддиректории исключительно для файлов содержимого web-сервера, включая графику, но исключая скрипты и другие программы.

Определить отдельную директорию исключительно для всех внешних по отношению к ПО web-сервера скриптов или программ, выполняющихся как часть содержимого web-серверанапример, CGI, ASP и т.п.).

Запретить выполнение скриптов, которые не находятся под управлением административных аккаунтов. Данное действие выполняется созданием доступа и управлением им к отдельной директории, которая предназначена для авторизованных скриптов.

Создать группы и пользователей для web-сервера. Запретить использование жестких и символических ссылок (аналог shortcuts в Windows).

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

Использовать при необходимости файл robots.txt.

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



Инсталлировать проверку целостности для защиты конфигурационных файлов web-сервера. Пересчитывать контрольные суммы при изменении содержимого файлов.Хранить контрольные суммы в защищенном от записи носителе.Регулярно сравнивать контрольные суммы критичных файлов с эталонными значениями.

Список действий для обеспечения безопасности ОС, на которой выполняется web-сервер

Составление плана конфигурации и развертывания web-сервера.

Определить функции web-сервера.

Определить категории информации, которая будет храниться, обрабатываться и передаваться web-сервером. Определить требования безопасности для данной информации.

Определить способы опубликования информации на web-сервере.

Определить необходимость иметь выделенный хост для web-сервера.

Определить пользователей и категории пользователей web-сервера и определить привилегии каждой категории пользователей.

Определить методы аутентификации пользователей на web-сервере.

Выбор подходящей ОС для web-сервера.

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

Возможность управления доступом к различным программам, связанным с web-сервером, таким как CGI-скрипты и plug-ins сервера в случае web-сервера.

Применение patch’ей и upgrade’ов ОС.

Определить и инсталлировать все необходимые patches и upgrades для ОС.Определить и инсталлировать все необходимые patches и upgrades для приложений и сервисов, включенных в ОС.

Удаление или запрещение ненужных сервисов и приложений.

Конфигурирование аутентификации пользователей в ОС.

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

Тестирование безопасности ОС.

Протестировать ОС после начальной инсталляции для определения уязвимостей.Проводить частое тестирование ОС для определения новых уязвимостей.

Тестирование безопасности операционной системы

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

Trusted ОС

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

TOS обычно используются в приложениях, где безопасность очень важна. TOS могут безопасно управлять всеми аспектами своего окружения, включая сетевые ресурсы, пользователей, процессы, память и т.п. Более конкретно, TOS имеют возможность ограничить доступ к системным ресурсам таким способом, в который нельзя вмешаться или скомпрометировать.

Использование TOS обычно приводит к созданию очень безопасного web-сервера, однако существуют определенные трудности при их использовании. Основной недостаток состоит в том, что администрирование TOS требует хорошего знания каждой защищенной подсистемы. Тем не менее, даже при таких ограничениях, организации, которые имеют большие требования к безопасности, должны рассмотреть возможность использования TOS для поддержки web-серверов.

Должны быть рассмотрены следующие вопросы при определении того, какую платформу использовать для web:

какая ОС лежит в основе и насколько проанализирована ее безопасность;

имеет ли организация опыт администрирования TOS– какова дополнительная цена покупки и поддержки TOS по сравнению с ее преимуществами;

совместима ли TOS с существующими в организации web-приложениями и скриптами.

Удаление или запрещение ненужных сервисов и приложений

Идеально, чтобы web-сервер был выделенным и использовался только для этой цели. Многие ОС сконфигурированы по умолчанию для предоставления более широкого круга сервисов и приложений, чем требуется web-серверу; следовательно, web-администратор должен сконфигурировать ОС, удалив или запретив сервисы, не являющиеся необходимыми. Приведем некоторые примеры сервисов, которые обычно должны быть запрещены:

NetBIOS, если не требуется.NFS, если не требуется.FTP.Berkley "r" сервисы (например, rlogin, rsh, rcp).Тelnet.NIS.SMTP.Компиляторы.

Инструментальные средства разработки ПО, за исключением того случая, когда HTML страницы создаются каким-либо интерпретатором, например, Perl. В этом случае должен быть оставлен только используемый интерпретатор.

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

Удаление или запрещение ненужных сервисов усиливает безопасность web-сервера по следующим причинам:

ненужные сервисы не могут быть скомпрометированы и использованы для атаки на хост или для повреждения сервисов web-сервера. Каждый имеющийся в наличии сервис увеличивает риск компрометации хоста, потому что каждый сервис потенциально открывает вход для доступа атакующего;

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

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

при уменьшении числа сервисов уменьшается и количество логов и записей лога, благодаря чему обнаружение некорректного поведения становится легче.

При конфигурировании ОС следует применять принцип "запретить все, за исключением того, что явно разрешено" — это означает запретить и по возможности удалить все сервисы и приложения и затем выборочно разрешить те, которые требуются web-серверу. Также нужно по возможности установить минимальную конфигурацию ОС, которая требуется для приложения web-сервера. Если система инсталляции ОС предоставляет опцию "минимальная инсталляция", то нужно выбрать ее, потому что это минимизирует усилия, требуемые для удаления ненужных сервисов. Многие скрипты или программы типа uninstall не выполняют полного удаления всех компонент сервиса; следовательно, всегда лучше по возможности избегать инсталлирования ненужных сервисов.

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

Управление доступом к директории содержимого web-сервера

Не следует использовать ссылки, aliases или shortcuts из дерева директории содержимого web на директории или файлы, расположенные где-то еще на хосте или сетевой файловой системе. Лучше всего запретить возможность ПО web-сервера следовать по ссылкам и aliases. Как указывалось раньше, лог-файлы и конфигурационные файлы web-сервера должны размещаться вне дерева директории, которое определено для публичного содержимого web.

Для ограничения доступа к дереву директории содержимого web требуется выполнить следующие шаги:

выделить отдельный жесткий диск или логический раздел для web-содержимого и использовать поддиректории на данном жестком диске или логическом разделе исключительно для файлов содержимого web-сервера, включая графику, но исключая скрипты и другие программы;

определить отдельную директорию исключительно для всех внешних по отношению к ПО web-сервера скриптов или программ, выполняющихся как часть содержимого web (например, CGI, ASP, PHP);

запретить выполнение скриптов, которые не находятся под исключительным контролем административных аккаунтов. Данное действие выполняется созданием доступа и управлением им к отдельной директории, предназначенной для хранения авторизованных скриптов; запретить использование жестких и символических ссылок;

определить матрицу доступа к содержимому web. Определить, какие папки и файлы внутри содержимого web-сервера имеют ограничения и какие являются доступными (и кому).

Большинство производителей ПО web-сервера предоставляют директивы или команды, которые позволяют web-администратору ограничить доступ пользователя к файлам содержимого web-сервера. Например, ПО web-сервера Apache предоставляет директиву Limit, которая позволяет web-администратору указать, какие возможности доступа (такие как New, Delete, Connect, Head и Get) связаны с каждым файлом web-содержимого. Директива Require в Apache позволяет web-администратору ограничивать доступ к содержимому аутентифицированными пользователями или группами.

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

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

Управление ресурсами на уровне ОС

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

Управление влиянием web Bots

Web bots (что тоже самое, что и агенты или spiders) есть прикладное ПО, используемое для сбора, анализа и индексирования web-содержимого. Web bots используются многими организациями в разных целях. Некоторые примеры:

Scooter, Slurp и Googlebot анализируют, индексируют и записывают web-сайты для поисковых систем, таких как AltaVista и Google;ArchitextSpider собирает статистику Интернета;Hyperlink validators используются для автоматической проверки корректности гиперссылок на другие сайты;EmailSiphon и Cherry Picker являются bots, специально разработанными для поиска на web-сайтах e-mail адресов для добавления в e-mail списки ("спам"). Это пример bot, который имеет негативное воздействие на web-сайты или их пользователей.

Bots имеют негативные последствия, потому что:

web-серверы часто содержат директории, которые не должны индексироваться; организации могут не хотеть, чтобы часть их сайта появлялась в поисковых системах;

web-серверы часто содержат временные страницы, которые не должны индексироваться; bots часто содержат ошибки или не всегда имеют хорошие намерения и могут нанести вред частыми запросами, создавая DoS-атаку для законных пользователей.

В принципе, существует способ для web-администратора повлиять на поведение большинства bots на своем web-сайте. Была создана серия соглашений, называемая Robots Exclusion Standard (REP). Хотя REP не является официальным стандартом Интернета, он поддерживается большинством хорошо написанных и имеющих благие цели bots, включая те, которые используются в большинстве поисковых систем.

Web-администраторы, которые хотят ограничить деятельность bots на своих web-серверах, должны создать тестовый файл, называемый robots.txt. Файл должен всегда иметь данное имя и располагаться в корневой директории web-сервера. Кроме того, допускается только один такой файл на весь web-сайт. Заметим, что файл robots.txt является стандартом, который на добровольной основе должен поддерживаться программистами bots. Не существует обязательного требования использовать его.
Таким образом, вредоносные bots, такие как EmailSiphon и Cherry Picker, игнорируют данный файл.

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

Допустимы следующие ключевые слова:



User-agent – имя робота или spider. Web-администратор может указать более одного имени агента, при этом действие будет применяться к каждому указанному bot. Запись нечувствительна к регистру (слово "googlebot" – то же самое, что и "GoogleBot", "GOOGLEBOT"). "*" указывает, что это запись по умолчанию, которая используется, если никакого соответствия не найдено. Например, если указать "GoogleBot", то "*" будет применяться к любому другому роботу, за исключением GoogleBot.

Disallow – говорит bots, какие разделы web-сайта следует исключить. Например, /images информирует bots, что не следует открывать или индексировать любые файлы в директории images и любых ее поддиректориях. Таким образом, директория /images/special также не будет индексироваться указанными в user-agent bots.

Заметим, что /do будет соответствовать любой директории, начинающейся с "/do" (например, /do, /document, /docs и т.п.), в то время как /do/ соответствует только директории, называемой "/do/".

Web-администратор может также указать конкретные файлы. Например, он может указать /mydata/help.html для предотвращения доступа только к одному файлу.

Значение "/" указывает, что ничего на web-сайте не разрешено для доступа указанных в user-agent bots.

Должна существовать по крайней мере одна запись на каждый user-agent.

Существует много способов использовать файл robots.txt. Несколько простых примеров:



запретить всем (учитывающим это) bots доступ в указанные директории:

User-agent: * Disallow: /images/ Disallow: /banners/ Disallow: /Forms/ Disallow: /Dictionary/



запретить всем (учитывающим это) bots доступ ко всему web-сайту:

User-agent: * Disallow: /



запретить конкретному bot анализировать конкретную web-страницу:

User-agent: GoogleBot Disallow: tempindex.html



Заметим, что файл robots.txt доступен всем. Следовательно, web-администратор не должен указывать имена чувствительных файлов или папок. Если они должны быть исключены, то лучше использовать защищенные паролем страницы, которые не могут быть доступны bots. Защита паролем является более надежным способом для исключения не придерживающихся правил bots. Более подробная информация будет приведена при описании методов аутентификации.

В самом общем виде web

В самом общем виде web можно разделить на два основных компонента: web-серверы — они являются приложениями, которые формируют информацию, доступную по протоколу НТТР, и web-браузеры (клиенты) — они используются для доступа и показа информации, хранящейся на web-серверах. В основном будем рассматривать проблемы безопасности, касающиеся web-серверов.
К сожалению, web-серверы часто являются целями атак. Вследствие этого важно гарантировать безопасность web-серверов а также сетевой инфраструктуры, которая их поддерживает. Угрозы безопасности, специфичные для web-серверов в общем случае можно разделить на следующие категории:

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

Результатом этого может быть получение доступа к файлам или каталогам, которые не предназначены для открытого доступа, либо выполнение привилегированных команд и/или установка ПО на web-сервер.
Информация на web-сервере может быть преднамеренно изменена с враждебными целями. Наиболее общим примером такой угрозы является подмена содержимого web-сайта.

Denial of service (DoS) атаки могут быть направлены на web-сервер что приведет к отказу в доступе законным пользователям.
Чувствительная информация, передаваемая в открытом виде между web-сервером и браузером, может быть перехвачена.
Пользователи могут получить неавторизованный доступ к ресурсам, расположенным где-то еще в локальной сети организации, используя успешную атаку на web-сервер.
Возможно осуществление атаки на другие сети и серверы, причем будет использован скомпрометированный web-сервер, скрыта настоящая идентификация и, иногда, ответственность за последствия возложена на администратора web-сервера, с которого выполняется атака.
Сервер может быть использован в качестве незаконной точки распространения ПО, инструментальных средств атаки, при этом на администратора сервера может быть возложена ответственность за последствия атаки.


Многих проблем безопасности можно избежать, если ОС, лежащая в основе web-сервера, сконфигурирована соответствующим образом. Конфигурации по умолчанию для аппаратуры и ПО обычно устанавливаются производителями, при этом, как правило, делается упор на использование возможностей, функциональностей исходного ПО, а также на простоту использования возможностей, связанных с безопасностью. Также следует понимать, что производители не знают требований безопасности каждой организации, поэтому web-администратор должен сконфигурировать новые серверы в соответствии с требованиями безопасности и переконфигурировать их каждый раз при изменении этих требований. Обеспечение безопасности ОС как минимум должна включать следующие шаги:
выполнение patch’ей и upgrade’ов ОС;удаление или запрещение ненужных сервисов и приложений;конфигурирование управления ресурсами;тестирование безопасности ОС.
Следует гарантировать, что ПО web-сервера развернуто, сконфигурировано и управляется в соответствии с требованиями безопасности, определенными в организации.
Во многих аспектах инсталляция и конфигурирование безопасности ПО web-сервера аналогично процессу инсталляции и конфигурирования ОС. Главным принципом, как и раньше, является инсталляция минимального числа требуемых сервисов web-сервера и удаление всех известных уязвимостей с помощью patche’ей и upgrade’ов. Если инсталляционная программа устанавливает какие-то ненужные приложения, сервисы или скрипты, они должны быть удалены немедленно после завершения процесса установки. Обеспечение безопасности web-сервера как минимум должно включать следующие шаги:

выполнение patch’ей и upgrade’ов ПО web-сервера– удаление или запрещение ненужных сервисов, приложений и примеров содержимого;
конфигурирование аутентификации пользователей web-сервера;
конфигурирование управления ресурсами web-сервера;
тестирование безопасности приложения web-сервера и конкретного содержимого web-сервера.

Следует предпринять шаги для гарантирования того, что на web-сайте публикуется только корректное содержимое.


Должна существовать четкая политика в определении того, какой тип информации является открытым, к какой информации следует ограничить доступ и какая информация не должна публиковаться в публично доступном репозитории.
Следует гарантировать защиту web-содержимого от неавторизованного доступа или модификации.
Должна существовать определенная политика, гарантирующая невозможность модификации без выполнения авторизации. Требуется обеспечить гарантию целостности, даже если информация не является конфиденциальной. Необходимо защищать содержимое web посредством выполнения соответствующего управления ресурсами web-сервера. Некоторые примеры управления ресурсами включают:
инсталлирование только необходимых сервисов;инсталлирование web-содержимого на выделенном жестком диске или в выделенном разделе;
возможность выполнять запись (uploads) только в директории, которые не являются читаемыми из web-сервера, а доступны по некоторому другому протоколу (например, ftp);
определение единственной директории для всех скриптов или программ, которые выполняются для создания web-содержимого и являются внешними по отношению к web-серверу;
запрещение использования жестких или символических ссылок в файловой системе ОС, на которой выполняется web-сервер;
создание матрицы доступа к web-содержимому, которая определяет, какие папки и файлы внутри директории web-сервера имеют ограничения по доступу; запрет просмотра директории в файловой системе;использование аутентификации пользователей с помощью цифровых подписей и других криптографических механизмов;
использование систем обнаружения проникновений, основанных на хосте и /или проверки целостности файлов, для обнаружения проникновения и проверки целостности web-содержимого.

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


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

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


Частота и варианты web-атак, совершаемых сегодня, говорят о том, что безопасность web- серверов может быть обеспечена только с использованием различных и расположенных на разных уровнях механизмов обороны (так называемая "оборона вглубь").
Следует гарантировать постоянное функционирование системы обеспечения безопасности.
Поддержание безопасного функционирования web-сервера требует постоянных усилий и наличия достаточного количества ресурсов. Поддержание безопасности web-сервера обычно включает следующие шаги:
своевременное применение patch’ей и upgrade’ов;конфигурирование, защита и анализ лог файлов;частое выполнение back up’а критической информации;поддержка защищенных копий web-содержимого;определение процедур восстановления при компрометации и следование им при обнаружении проникновения;периодическое тестирование безопасности.
Рассмотрим общие принципы, которые применимы ко всем системам.

---

---