Для системного администратора

Жизнь – штука коварная и достаточно сложная. Постоянно озадачивает чем-нибудь. На сей раз она озадачила вопросом безопасных коммуникаций через интернет и внутри предприятия. Задача звучит донельзя просто – обеспечить безопасную коммуникацию двух некоторых узлов для одного сервиса. В условиях задачи помимо шифрования так же требуется обеспечить взаимную проверку участников обмена данными. Тут за решением далеко ходить не надо – это IPSec. На первый взгляд всё просто, но в процессе реализации пришлось столкнуться с некоторыми не всегда очевидными и интересными моментами.

Итак, имеется домен Active Directory и два узла внутри домена. На узле А размещёна некоторая служба (будь то терминальные службы, будь то незащищённый FTP). Узел Б должен быть единственным узлом, который имеет право доступа к службе на условном сервере. При этом весь трафик данной службы подлежит обязательному шифрованию и проверке целостности/неизменности пакетов во время передачи данных. В первую очередь предстояло подумать на предмет надёжной аутентификации обоих узлов. Если говорить про IPSec, то он предлагает 3 варианта аутентификации:

• Kerberos
• Certificates
• Shared Key

Kerberos в данном случае не поможет, т.к. он позволит аутентифицировать любой компьютер в сети, для которого есть разрешённая учётная запись в Active Directory. Shared Key – просто и гламурно, но не сильно безопасно. Вариант с цифровыми сертификатами в данном случае выглядит более предпочтительным, но и наиболее сложным в плане реализации и поддержке. Для этих целей потребуется развернуть (если его ещё нету) или использовать существующий Enterprise Certification Authority (Enterprise CA). Посредством этого CA необходимо издать для обоих компьютеров сертификат, у которого в поле Purposes указано Server/Client Authentication. Для этого достаточно с каждого компьютера запустить оснастку Certificates для локального компьютера, в меню View выбрать Options и там выставить переключатель в Certificate Purpose. После чего нажать правой кнопкой на Server или Client Authentication (в зависимости от роли компьютера) и выбрать Request New Certificate. В списке доступных шаблонов можно выбрать шаблон IPSec, который идеально подходит для наших целей. Если данный шаблон не предлагается в мастере, то необходимо зайти в оснастку Certification Authority выделить Certificate Templates. Далее Action -> New -> Certificate Template to Issue. Для проверки, что сертификаты выданы можно просмотреть секцию Issued Certificates в оснастке Certification Authority. Напомню, если кто-то не знает, то IPSec может работать только с сертификатами компьютеров, т.к. он работает на сетевом уровне модели OSI, который находится ниже уровня пользователя и приложений. Поэтому работа IPSec для пользователя полностью прозрачна.

Теперь можно приступать к реализации политики IPSec. В рамках данной статьи для защиты был выбран протокол RDP (вместо него можно использовать любой другой). Для запуска консоли IPSec можно запустить консоль secpol.msc и в самом низу будет IP Security Policies. В правой секции нажимаем правой кнопкой и выбираем создание новой политики. Копками Next-Next проходим создание политики, по ходу заполняя нужные поля. Назовём эту политику Custom. Создавать Default Response Rule не обязательно. После создания новой политики мы получим примерно такое окно:

Как известно, по умлочанию дефолтное правило IPSec – запрещено всё, что не разрешено. Поэтому для начала нужно разрешить протекание всего трафика для компьютера, иначе сеть работать не будет. Поэтому в основном окне политики нажимаем кнопку Add и кнопками Next двигаемся вперёд. В окне Tunnel Endpoint указываем, что данное правило не использует туннель IPSec, далее в списке IP Filter List выбираем уже готовое правило All ICMP Traffic и выбираем для него действие Permit (разрешить). Ту же самую процедуру проделываем и для правила All IP Traffic (в списке IP Filter List). В результате мы должны получить вот такую картину:

если оставить всё как есть, то после применения политики ничего не изменится, т.к. весь трафик разрешён, как IP, так и ICMP. Эту операцию необходимо выполнить на обоих компьютерах-участников защищённого соединения. Теперь нужно создать правило прохождения трафика RDP. Сначала возьмём условный сервер. Возвращаемся к окну редактирования основной политики. Для этого снова нажимаем Add и доходим до окна IP Filter List без изменений. В окне IP Filter List нажимаем кнопку Add. В окне редактора правил вводим созвучное название правилу, например, RDP Server и сбоку ещё раз нажимаем Add. В окне IP Filter Description and Mirrored property убеждаемся, что выставлен чек-бокс напротив Mirrored. Суть этой галочки в том, что она позволяет как получать запрос, так и отправлять ответ используя одно и то же правило. В нашем примере RDP трафик для сервера описывается следующими характеристиками:

• Source Address = указать конкретный адрес клиента, которому разрешено (или нужное выбрать из списка)
• Destination Address = My IP Address. Т.к. этот компьютер является сервером, то получать основные запросы будет он.
• Protocol Type = TCP (в списке протоколов есть RDP, но это совсем не то, о чём вы подумали :) )
• Source Port = Any
• Destination Port = по дефолту 3389 для RDP

применяем все изменения и возвращаемся снова в окно IP Filter List, где выбираем новое правило – RDP Server. Переходим кнопкой Next на окно действия фильтра. Можно выбрать Require Security, но для практики мы создадим самое жёсткое действие – HardSecurity, поэтому нажимаем кнопку Add, вводим название, далее шаблон действия – Negotiate Security, следующее окно пропускаем без изменений и доходим до окна IP Traffic Seccurity. Здесь мы можем выбрать режим защиты. Можно выбрать следующее:

• Integrity and Encryption – обеспечивает максимальную защищённость, как шифрование, проверка подлинности, проверка целостности пакетов, проверка очереди отправки пакетов и т.д. Для шифрования будет использоваться метод 3DES (Triple Data Encryption Standart), а целостность и проверка подлинности пакетов будет проводиться за счёт алгоритма SHA1 (Secure Hash Algoritm).
• Integrity only – обеспечивает проверку целостности, подлинности, очерёдности следования пакетов. Обеспечивается алгоритмом SHA1
• Custom – можно вручную настроить алгоритмы проверки целостности и подписания пакетов и алгоритмы шифрования.

В условиях статьи использовался Integrity and Encryption. Когда создание действия фильтра сделано, в окне Filter Action (куда мы вернёмся после создания нового действия фильтра) и нажимем Next. Т.к. мы выбрали Negotiate Security (согласование безопасности), то в окне Authentication Metod нужно выбрать метод аутентификации участников соединения. Т.к. мы находимся в домене, где есть Enterprise CA и для компьютеров уже изданы сертификаты, то выбираем метод аутентификации сертификатами. При нажатии кнопки Browse откроется список всех доступных CA, для которых на локальном компьютере есть корневые сертификаты и которым данный компьютер доверяет. Поэтому сертификаты компьютерам может выдавать не только доменный Enterprise CA, но и любой доверенный. Т.к. сертификаты для компьютеров выдал доменный CA, то в списке нужно указать именно его. Если всё сделано правильно, то основное окно политики должно выглядеть примерно так:

Ту же самую процедуру проделываем и на клиенте за одной лишь разницей: при создании нового фильтра в отличии от сервера меняются местами Source Address и Destination Address. Всё остальное делается точно так же. Когда всё будет завершено кнопкой Ok закрываем основное окно редактора политики. Применить политику легко – правой кнопкой на политику и нажать Assign. Следует отметить, что политика применяется мгновенно. Если применить политику только на одном компьютере, то коммуникации по протоколу RDP не произойдёт, поскольку второй участник соединения не будет знать как согласовывать безопасность и его подлинность не удастся проверить. Если теперь применить созданную политику на всех компьютерах-участниках защищённого соединения, то RDP трафик станет шифрованный с проверкой подлинности каждого пакета. Пользователь не будет знать, что RDP трафик защищён, всё будет предельно прозрачно для пользователя.

Теперь можно перейти к насущным вопросам реализации IPSec

Необходимо понимать, что на пути между двумя узлами не должно быть NAT-маршрутизаторов. Дело в том, что NAT изменяет заголовки пакетов (а соответственно новые контрольные суммы не будут совпадать с контрольными суммами в шифрованном пакете), после чего пакеты по мнению IPSec будут считаться повреждёнными и будут дропаться. Для Windows XP SP2, Windows Server 2003, а для Windows 2000 в виде отдельного обновления есть возможность использования NAT-Traversal (NAT-T), который обеспечивает прохождение IPSec трафика через NAT-маршрутизаторы.

И немного о сертификатах

Если сертификат компьютера в CA будет по каким-то причинам отозван, то в теории коммуникация посредством этого сертификата будет невозможна. Но на практике всё не совсем так. Дело в том, что даже если зайти в CA домена и отозвать один из сертификатов, которые были изданы для IPSec (или оба сертификата), то защищённое соединение будет установлено с использованием отозванного сертификата! Как так? Здесь нужно учитывать два момента:

1. если сертификат отозван, то он незамедлительно помещается в список отозванных сертификатов – CRL (Certificate Revocation List). Но компьютеры в сети смогут узнать о том, что сертификат отозван не ранее очередного времени публикации полного списка CRL или инкрементального списка DeltaCRL. По умолчанию полный список CRL в Windows Server 2003 публикуется раз в неделю. А Delta CRL – раз в сутки. До времени публикации одного из списков CRL отозванный сертификат можно будет ещё использовать. К слову говоря, Windows 2000 не умеет считывать Delta CRL, поэтому для Windows 2000 можно будет использовать отозванный сертификат до очередной публикации полного списка CRL (по дефолту может занять до недели). Чтобы принудительно опубликовать список CRL вне расписания нужно зайти в консоль CA и на разделе Revoked Certificates на жать Publish. После чего выбрать какой тип CRL (полный или только дельта) публиковать.
2. особенности проверки компьютерами списков CRL. Вот тут остановлюсь подробнее.

Как работают различные системы со списками CRL при проверке сертификата (адреса, по которым доступны списки CRL публикуются в самом сертификате):

• Windows 2000 – при проверке сертификата по умолчанию НЕ проверяет списки CRL на предмет отозванности сертификата и руководствуется только содержимым самого сертификата.
• Windows XP/Windows Server 2003/Windows Vista – по умолчанию проверяют списки CRL на предмет отозванности сертификатов. Но, при недоступности этого списка для проверки сертификата руководствуются только содержимым самого сертификата!

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

netsh ipsec dynamic set config strongcrlcheck value=2

данная команда включит принудительную проверку списков CRL только на момент текущей сесси. После перезагрузки компьютера вновь будет использоваться дефолтное значение. Чтобы использовать строгую проверку постоянно нужно отредактировать (или создать, если не существует) следующее значение реестра:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley

необходимо изменить (или создать, если отсутствует) параметр типа DWORD с именем StrongCRLCheck. Значение этого параметра может принимать 3 значения:

• 0 – списки CRL не проверяются. Решение о принятии/отклонении сертификата принимается на основе только самого сертификата.
• 1- списки CRL проверяются. Если же список CRL недоступен, то решение о принятии/отклонении сертификата принимается на основе только самого сертификата.
• 2 – списки CRL проверяются. Если список CRL будет недоступен на момент проверки сертификата – сертификат будет отклонён и признан как недействительный.

Вот, в принципе, и всё, о чём я хотел сегодня рассказать. Может, несколько сумбурно, просто старался акцентировать внимание на наименее очевидные моменты реализации развёртывания IPSec с использованием цифровых сертификатов.

Автор:т Vadims Podāns
Источник