AD+82

101

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

ESP (Encapsulating Security Protocol) - инкапсулирующий протокол безопасности, который обеспечивает и целостность и конфиденциальность. В режиме транспорта ESP заголовок находится между оригинальным IP заголовком и заголовком TCP или UDP. В режиме туннеля заголовок ESP размещается между новым IP заголовком и полностью зашифрованным оригинальным IP пакетом.

Т.к. оба протокола - AH и ESP добавляют собственные заголовки, они имеют свой ID протокола, по которому можно определить что последует за заголовком IP. Если вспомнить статью TCP Protocol Layers Explained, то в ней сказано, что каждый тип заголовка имеет собственный номер. Например, для TCP это 6, а для UDP - 17. При работе через firewall важно не забыть настроить фильтры, чтобы пропускать пакеты с ID AH и/или ESP протокола. Для AH номер ID - 51, а ESP имеет ID протокола равный 50. При создании правила не забывайте, что ID протокола не то же самое, что номер порта.

Третий протокол, используемый IPSec - это IKE или Internet Key Exchange protocol. Как следует из названия, он предназначен для обмена ключами между двумя узлами VPN. Насмотря на то, что генерировать ключи можно вручную, лучшим и более масштабируемым вариантом будет автоматизация этого процесса с помощью IKE. Помните, что ключи должны часто меняться, и вам наверняка не хочется полагаться на свою память, чтобы найти время для совершения этой операции вручную. Главное - не забудьте настроить правило на файрволе для UPD порта с номером 500, т.к. именно этот порт используется IKE.

SA (Security Association), что можно приближѐнно перевести как "связь или ассоциация безопасности" - это термин IPSec для обозначения соединения. При настроенном VPN, для каждого используемого протокола создаѐтся одна SA пара (т.е. одна для AH и одна для ESP). SA создаются парами, т.к. каждая SA - это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные SA пары хранятся на каждом узле. Если ваш узел имеет SA, значит VPN туннель был установлен успешно.

Т.к. каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить к какому узлу он относится. Это номер называется SPI (Security Parameter Index) или индекс параметра безопасности.

SA храняться в базе данных c названием, кто бы подумал - SAD (Security Association Database) или БД ассоциаций безопасности. Мы встретимся с ней ещѐ раз при настройке IPSec VPN.

Каждый узел IPSec также имеет вторую БД - SPD или Security Policy Database (БД политики безопасности). Она содержит настроенную вами политику узла. Большинство VPN решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.

Какие настройки включает в себя политика?

1.Симметричные алгоритмы для шифрования/расшифровки данных

2.Криптографические контрольные суммы для проверки целостности данных

3.Способ идентификации узла. Самые распространнѐнные способы - это предустановленные

102

ключи (pre-shared secrets) или RSA сертификаты.

4.Использовать ли режим туннеля или режим транспорта

5.Какую использовать группу Diffie Hellman

6.Как часто проводить переидентификацию узла

7.Как часто менять ключ для шифрования данных

8.Использовать ли PFS

9.Использовать ли AH, ESP, или оба вместе

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

Фаза Один и Фаза Два

Теперь давайте посмотрим как всё это работает вместе. Установка и поддержка VPN туннеля происходит в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш алгоритме и группе Diffie Hellman. Они также идентифицируют друг друга. Всё это может пройти в результате обмена тремя нешифрованными пакетами (т.н. агрессивный режим) или через обмен шестью нешифрованными пакетами (стандартный режим - main mode). Предполагая, что операция завершилась успешно, создаётся SA первой Фазы - Phase 1 SA (также называемый IKE SA) и процесс переходит к Фазе Два.

На втором этапе генерируются данные ключей, узлы договариваются насчёт используемой политики. Этот режим, также называемый быстрым режимом (quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Такое положение дел усложняет решение проблем в случае неполадок на второй фазе при успешном завершении первой. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA, и на этом установка туннеля считается завершённой.

Когда же это всё происходит? Сначала на узел прибывает пакет с адресом назначения в другом домене шифрования, и узел инициирует Фазу Один с тем узлом, который отвечает за другой домен. Допустим, туннель между узлами был успешно установлен и ожидает пакетов. Однако, узлам необходимо переидентифицировать друг друга и сравнить политику через определённое время. Это время известно как время жизни Phase One или IKE SA lifetime.

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

который называется временем жизни Phase Two или IPSec SA lifetime. Phase Two lifetime короче,

чем у первой фазы, т.к. ключ необходимо менять чаще. Типичное время жизни Phase Two - 60 минут. Для Phase One оно равно 24 часам.

Ваша задача заключается в том, чтобы сконфигурировать оба узла с одинаковыми параметрами времени жизни. Если этого не произойдёт, то возможен вариант, когда изначально туннель будет установлен успешно, но по истечении первого несогласованного промежутка времени жизни связь прервётся. Странные проблемы могут возникнуть и в том случае, когда время жизни Фазы Один меньше аналогичного параметра Фазы Два. Если настроенный ранее туннель виснет, то первая вещь, которая нуждается в проверке - это время жизни на обоих узлах. В заключение стоит упомянуть, что при смене политики на одном из узлов, изменения вступят в силу только при следующем наступлении Фазы Один. Чтобы изменения вступили в силу немедленно, надо убрать SA для этого туннеля из SAD. Это вызовёт пересмотр соглашения между узлами с новыми настройками политики безопасности.

84. Компоненты политики удаленного доступа RAS

Политика коммутируемого удаленного доступа:

103

Расположена локально, не в Active Directory Состоит из:

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

•Разрешений (разрешение либо предоставлено либо нет)

•Профиля (настройки, которые применяются к авторизованному соединению)

Примеры условий при попытке подключения:

■Между восемью и пятью утра понедельник-пятница,

■Производится с любого IP адреса, который соответствует 192.168.*.*,

■Пользователь, запрашивающий соединение, принадлежит группе sales.

Настройка разрешений удаленного доступа

104

Профили удаленного доступа

Пример настройки профиля:

■Время соединения 90 минут,

■Четыре линии multilink (линия отключается, если используется на 50% в течение 10 минут)

■Требуется IPSec шифрование

105

85. Алгоритм политики предоставления соединения клиенту удаленного доступа

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

1.Проверяется первая политика из списка политик удаленного доступа. Если политик удаленного доступа нет, попытка подключения отклоняется.

2.Если не все параметры попытки подключения соответствуют политике удаленного доступа, проверяется следующая политика удаленного доступа. Если политик удаленного доступа больше нет, попытка подключения отклоняется.

3.Если все параметры попытки подключения соответствуют политике, проверяется значение атрибута Ignore-User-Dialin-Properties.

4.Если для атрибута Ignore-User-Dialin-Properties установлено значение “Ложь”, проверяется настройка разрешений удаленного доступа для пользователя, пытающегося установить соединение.

Если в политике задано разрешение “Запретить доступ”, попытка подключения отклоняется.

Если в политике задано разрешение “Разрешить доступ”, применяются параметры учетной записи пользователя и параметры профиля. Если попытка подключения не соответствует параметрам учетной записи пользователя и параметрам профиля, попытка подключения отклоняется. Если попытка подключения соответствует параметрам учетной записи пользователя и параметрам профиля, попытка подключения принимается.

Если разрешение на удаленный доступ отлично от “Разрешить доступ” и “Запретить доступ”, то оно должно иметь значение “Управление на основе политики удаленного доступа”. Выполняется проверка разрешения на удаленный доступ, заданного политикой удаленного доступа.

Если задано разрешение “Отказать в праве удаленного доступа”, попытка подключения отклоняется.

Если в политике задано разрешение “Предоставить право удаленного доступа”, применяются параметры учетной записи пользователя и параметры профиля. Если попытка подключения не соответствует параметрам учетной записи пользователя и параметрам профиля, попытка подключения отклоняется. Если попытка подключения соответствует параметрам учетной записи пользователя и параметрам профиля, попытка подключения принимается.

5.Если для атрибута Ignore-User-Dialin-Properties установлено значение “Истина”, проверьте настройку разрешений политики.

Если задано разрешение Отказать в праве удаленного доступа, попытка подключения отклоняется.

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

доступа.

106

Примечания

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

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

Политики удаленного доступа проверяются в том порядке, в котором они перечислены в списке. Более конкретные политики удаленного доступа обычно помещаются выше более общих политик удаленного доступа.

Атрибут Ignore-User-Dialin-Properties является новым средством в Windows Server 2003, Стандартный выпуск, Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition, позволяющим игнорировать все параметры входящих звонков в учетной записи пользователя. Дополнительные сведения см. в разделе Новые возможности IAS.

В Windows Server 2003 Стандартный выпуск службу IAS можно настроить не более чем с 50 клиентами RADIUS и двумя группами внешних RADIUS-серверов. Для определения RADIUS-клиентов можно использовать полные доменные имена или IP-адреса узлов, но определять группы RADIUS-клиентов, указывая диапазон IPадресов, нельзя. Если полное доменное имя RADIUS-клиента разрешается в несколько IP-адресов, IAS-сервер использует первый IP-адрес, возвращаемый в ответе на запрос DNS. С помощью службы проверки подлинности в Интернете

(IAS) в Windows Server 2003 Enterprise Edition и Windows Server 2003 Datacenter Edition можно настроить неограниченное число клиентов RADIUS и групп внешних RADIUS-серверов. Кроме того, для настройки RADIUS-клиентов можно указывать диапазоны IP-адресов.

107

86. Настройка Radius-сервера и клиента

Remote Authentication Dial-In User Service (Сервис удаленной аутентификации dial-in

пользователя)

RADIUS основывается на режиме клиент / сервер, что позволяет использовать централизованную аутентификацию, авторизацию и учет для доступа к сети.

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

•RADIUS-сервер принимает и обрабатывает запросы на подключение или учет сообщений, которые посылают клиенты RADIUS или RADIUS прокси. На основе набора правил и информации в базе данных учетных записей пользователей сервер RADIUS либо производит проверку подлинности и авторизацию соединения и отправляет обратно сообщение «Доступ разрешен» или отправляет обратно сообщение «Доступ запрещен».

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

RADIUS.

При развертывании подключений удаленного доступа или виртуальной частной сети (virtual private network, VPN) с сервером политики сети, выступающим в качестве RADIUS-сервера, необходимо выполнить следующие действия:

Установить и настроить серверы доступа к сети в качестве RADIUS-клиентов.

Развернуть компоненты для методов проверки подлинности.

Настроить сервер политики сети в качестве RADIUS-сервера.

Установка и настройка серверов доступа к сети (RADIUS-клиентов)

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

Important

Важно!

Клиентские компьютеры, такие как портативные компьютеры с беспроводным подключением и другие компьютеры с клиентскими операционными системами, не являются клиентами RADIUS. Клиенты RADIUS представляют собой серверы сетевого доступа (такие как точки беспроводного доступа, коммутаторы с поддержкой 802.1X, серверы виртуальных частных сетей (VPN), а также серверы удаленного доступа к сети), поскольку они используют протокол RADIUS для взаимодействия с RADIUSсерверами, такими как серверы политики сети.

Службу маршрутизации и удаленного доступа можно установить как на локальном сервере политики сети, так и на удаленном компьютере.

108

Развертывание компонентов для методов проверки подлинности

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

Протокол EAP в сочетании с протоколом TLS, что носит название EAP-TLS.

Протокол PEAP в сочетании с протоколом MS-CHAP v2, что носит название PEAP- MS-CHAP v2.

Протокол PEAP в сочетании с протоколом TLS, что носит название PEAP-TLS. При использовании методов EAP-TLS и PEAP-TLS необходимо развернуть инфраструктуру публичного ключа путем установки и настройки служб сертификации Active Directory®, которые будут осуществлять выдачу сертификатов включенным в домен клиентским компьютерам и серверам политики сети. Эти сертификаты используются при выполнении проверки подлинности в качестве доказательства подлинности как клиентских компьютеров, так и серверов политики подлинности. При необходимости вместо использования сертификатов компьютера можно развернуть смарткарты. В этом случае необходимо выдать сотрудникам организации смарт-карты и устройства считывания смарт-карт.

При использовании метода PEAP-MS-CHAP v2 можно развернуть собственный центр сертификации со службами сертификации Active Directory для выдачи сертификатов серверам политики сети или приобрести сертификаты сервера у публичного доверенного корневого центра сертификации, обладающего доверием клиентов, такого как VeriSign.

Настройка сервера политики сети в качестве RADIUS-сервера.

При настройке сервера политики сети в качестве RADIUS-сервера необходимо настроить RADIUS-клиентов, политику сети и RADIUS-учет.

Настройка RADIUS-клиентов

Настройка RADIUS-клиентов выполняется в два этапа:

Настройка физического RADIUS-клиента, такого как сервер виртуальной частной сети или удаленного доступа, путем указания сведений, которые позволят серверу доступа к сети взаимодействовать с серверами политики сети. К таким сведениям относится настройка IP-адреса сервера политики сети и общего секрета в интерфейсе пользователя сервера виртуальной частной сети или удаленного доступа.

Добавление нового RADIUS-клиента на сервере политики сети. На сервере политики сети следует добавить в качестве RADIUS-клиента каждый сервер виртуальной частной сети или удаленного доступа. На сервере политики сети можно указать понятное имя для каждого RADIUS-клиента, а также IP-адрес этого RADIUS-клиента и общий секрет.

Настройка политик сети

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

Настройка RADIUS-учета

RADIUS-учет позволяет регистрировать запросы проверки подлинности пользователей и учета в локальном файле журнала или в базе данных сервера Microsoft® SQL Server® на локальном или удаленном компьютере.