From: Ilia Kuliev <ilia@kuliev.org>
Newsgroups:
Date: Mon, 24 May 2004 18:21:07 +0000 (UTC)
Subject: IPSec между FreeBSD и Windows XP с использованием сертификатов X.509
Оригинал: http://www.citytel.ru/ipsec/
Настройка взаимодействия по протоколу IPSec между FreeBSD и Windows XP/
Windows-2000 с использованием сертификатов X.509 и протокола обмена
ключами ISAKMP.
Область применения - передача секретных данных через сети общего
пользования или радиоканал между рабочей станцией Windows и сервером
FreeBSD; между серверами Windows и FreeBSD, и т.п. (транспортный режим
IPSec). Основной упор сделан на взаимодействие сервера и рабочей
станции с динамическим IP-адресом, так как прочие случаи более просты.
Вопрос туннелирования пакетов для доступа, например, с удалённой
рабочей станции в локальную сеть через сервер FreeBSD, будет
рассмотрен в следующей версии статьи.
Использование аутентификации с открытым ключом (сертификатов X.509)
обеспечивает более высокую безопасность, чем многократно описанное в
различных How-To использование секретного ключа (pre-shared key) или
статических политик шифрования. При условии соблюдения должных мер
предосторожности при обращении с закрытым ключом ЦС, выдавшего
клиентский сертификат (ограничения доступа, трудно подбираемый пароль,
и т.п.), сертификат X.509 невозможно подделать. Также, теоретически
его невозможно украсть с клиентской машины, поскольку при экспорте
сертификата его закрытый ключ не экспортируется.
Для генерации сертификатов может использоваться как ЦС на Windows, так
и ЦС на FreeBSD (посредством пакета OpenSSL, предполагается, что он
установлен в вашей системе). Процесс генерации сертификатов в ЦС
Windows рассматривать не будем, ограничимся описанием процесса для
OpenSSL.
Если корневой сертификат ЦС еще не создан, его надо создать.
Существует много разных способов генерации пары сертификата и
закрытого ключа, мы будем делать так:
Сначала генерируется закрытый ключ для будущего корневого сертификата:
openssl genrsa -des3 -out ca.key 1024
des3 означает, что ключ будет зашифрован по алгоритму Triple-DES
ca.key - имя файла, где будет сохранён получившийся ключ
1024 - длина ключа в битах, не рекомендуется устанавливать её больше
данного значения, иначе могут быть проблемы с некоторыми реализациями
SSL
После окончания генерации ключа, вас попросят ввести пароль. Помните,
что от длины и качества пароля зависит, в конечном счете, стойкость
всех сертификатов, которые будут выданы под этим корневым
сертификатом. Не забывайте также, что если вы забудете пароль, его
невозможно будет восстановить, и что, не зная пароля, вы не сможете
выдавать новые сертификаты. Фактически, это означает, что ваш ЦС
станет непригоден для использования, и вам нужно будет создавать его
заново, а также выдать заново все клиентские сертификаты.
Затем создается собственно корневой сертификат ЦС. Корневой сертификат
будет самоподписанным, потому что он находится выше всех в создаваемой
иерархии:
730 - это количество дней от текущего дня (в данном случае 2 года); в
течение этого срока сертификат будет считаться действующим. Возможно,
для корневого сертификата есть смысл поставить срок побольше, скажем,
5 или 10 лет.
ca.key - имя файла с закрытым ключом,созданным на предыдущем шаге
ca.crt - имя файла, в который будет записан созданный корневой
сертификат ЦС.
В процессе создания сертификата вам будут задавать вопросы об
информации, которая будет указана в созданном сертификате.
Обязательным является только ответ на Common Name, где имеет смысл
указать название вашего ЦС или что-то в этом роде, например "Vasily
Pupkin Ltd Root CA". В то же время, лучше заполнить все предлагаемые
поля.
Теперь у вас есть пара из корневого сертификата ЦС и его закрытого
ключа, и можно создать сертификаты для сервера и клиентов.
На этом этапе вам снова предложат заполнить информационные поля
сертификата. В поле Common Name следует указать FQDN вашего сервера
(что-то вроде myserver.mydomain.dom)
И наконец, выдаем сертификат и подписываем его закрытым ключом
корневого ЦС:
Вас попросят ввести пароль к закрытому ключу ЦС. Сертификат будет
выдан на 365 дней (можете это изменить). Ключ -CAcreateserial нужен
для того, чтобы OpenSSL вел учет выдаваемым сертификатам в своей
внутренней базе. В принципе, этот ключ можно опустить. Сертификат
будет сохранен в файл ipsec-server.crt. Файл запроса на сертификат
ipsec-server.csr можно удалить, скорее всего, он больше вам не
понадобится.
Таким же образом генерируем сертификат для клиента:
openssl genrsa -out ipsec-client.key 1024
openssl req -new -key ipsec-client.key -out ipsec-client.csr
(в поле Common Name следует указать FQDN компьютера клиента, или его имя)
openssl x509 -req -days 365 -in ipsec-client.csr -CA ca.crt -CAkey
ca.key -CAcreateserial -out ipsec-client.crt
Дополнительный шаг - преобразование сертификата и закрытого ключа в
единый файл формата PKCS#12:
openssl pkcs12 -export -inkey ipsec-client.key -certfile ca.crt -in
ipsec-client.crt -out ipsec-client.p12
Вас попросят ввести пароль, который понадобится впоследствии при
установке этого сертификата на компьютер Windows.
Теперь нужно настроить компьютеры сервера и клиента. Начнем с сервера.
Настройка сервера.
------------------
Предполагается, что в ядре FreeBSD уже включены опции IPSec и
IPSEC_ESP. На сервере должен быть установлен один из сервисов,
обеспечивающих работу ISAKMP, протокола обмена секретными ключами. В
коллекции портов есть два порта наиболее распространённых реализаций:
isakmpd и racoon. В этой версии статьи рассматривается только сервис
racoon.
Переходим в соответствующий каталог дерева портов, компилируем и
устанавливаем его:
cd /usr/ports/security/racoon
make
make install
(Примечание: перед этим очень полезно обновить дерево портов с помощью CVS)
Конфигурационные файлы racoon будут установлены в каталог
/usr/local/etc/racoon. Переходим туда, и редактируем его
конфигурационный файл:
cd /usr/local/etc/racoon
cp racoon.conf.dist racoon.conf
vi racoon.conf
# "path" must be placed before it should be used.
# You can overwrite which you defined, but it should not use due to confusing.
path include "/usr/local/etc/racoon" ;
#include "remote.conf" ;
# search this file for pre_shared_key with various ID key.
#path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;
# racoon will look for certificate file in the directory,
# if the certificate/certificate request payload is received.
path certificate "/usr/local/etc/racoon/cert" ;
# "log" specifies logging level. It is followed by either "notify", "debug"
# or "debug2".
log debug4;
#log notify;
#
# "padding" defines some parameter of padding. You should not touch these.
padding
{
maximum_length 20; # maximum padding length.
randomize off; # enable randomize length.
strict_check off; # enable strict check.
exclusive_tail off; # extract last one octet.
}
# if no listen directive is specified, racoon will listen to all
# available interface addresses.
listen
{
#isakmp ::1 [7000];
isakmp 111.222.333.444 [500];
#admin [7002]; # administrative's port by kmpstat.
#strict_address; # required all addresses must be bound.
}
# Specification of default various timer.
timer
{
# These value can be changed per remote node.
counter 5; # maximum trying count to send.
interval 20 sec; # maximum interval to resend.
persend 1; # the number of packets per a send.
# timer for waiting to complete each phase.
phase1 30 sec;
phase2 15 sec;
}
remote anonymous
{
exchange_mode main,aggressive;
doi ipsec_doi;
situation identity_only;
sainfo anonymous
{
pfs_group 1;
lifetime time 30 sec;
encryption_algorithm 3des, des ;
authentication_algorithm hmac_sha1, hmac_md5;
compression_algorithm deflate ;
}
Пояснения:
- путь к файлу psk.txt закомментирован, так как pre-shared
keys не будут использоваться
- добавлен путь к каталогу с сертификатами
usr/local/etc/racoon/cert (создадим его позже)
- включен максимальный уровень отладочной информации,
записываемой в syslog (log debug4 ), это может понадобиться при настройке
- указано, на каком адресе слушать запросы ISAKMP
(isakmp 111.222.333.444 [500];), если этот параметр закомментировать,
racoon будет слушать на всех адресах
- начало секции <<remote anonymous>> - в секции описываются
параметры для случая, когда клиент подключается с динамического
(неизвестного заранее) IP-адреса
- указано, что в первой фазе установления связи должен
использоваться основной режим (exchange_mode main,aggressive;), может
быть также закомментировано, если racoon не будет выступать в роли
инициатора соединения
- <<my_identifier asn1dn;>> означает, что идентификатор
сервера, отправляемый удаленному хосту, будет взят из поля Subject
сертификата, в данном случае не используется
- <<peers_identifier asn1dn;>> - то же самое, но для
удаленного хоста, в данном случае не используется
- <<verify_identifier off;>> - не проверять соответствие
идентификатора удаленного хоста и идентификатора, использующегося в
поле ID payload. Поскольку у Windows странные представления о полях
ESP, верификацию приходится отключать, так же, как два предыдущих
параметра.
- <<сertificate_type x509 "ipsec-server.crt"
"ipsec-server.key";>> - указание на тип и файлы сертификата и
закрытого ключа сервера
- <<peers_certfile "ipsec-client.crt";>> - указание на файл
сертификата клиента
- <<passive on;>> - указание racoon никогда не инициировать
сессию. Это оправдано в нашем случае, когда racoon запущен на сервере.
- <<generate_policy on;>> - автоматически создавать политику
IPSec. Мы вынуждены это делать, поскольку условились, что у клиента
динамический IP-адрес, который мы не знаем заранее, и соответственно,
не можем заранее установить нужную политику.
Важное примечание к последнему пункту (man racoon.conf):
"Note that inappropriate policy might be installed into the
responder's SPD by the initiator. So that other communication might
fail if such policies installed due to some policy mismatches between
the initiator and the responder."
К сожалению, это наблюдается и на практике (например, если в течение
срока жизни политики произошло отключение и повторное подключение
Windows-клиента к провайдеру, или если на клиенте был перезапущен
сервис IPSec). Единственным выходом в таком случае представляется
задание меньшего времени жизни политики. К ещё большему сожалению,
Windows не позволяет установить ее менее чем 300 секунд. Это серьёзный
недостаток, но альтернативы в данном случае (клиент с динамическим
IP-адресом) нет.
Оставшиеся строчки относятся к предпочтительным алгоритмам шифрования,
аутентификации и проверки целостности данных ESP.
Сохраняем получившийся файл, создаем каталог
/usr/local/etc/racoon/cert, и копируем в него:
- файл сертификата сервера (ipsec-server.crt);
- файл с закрытым ключом сертификата (ipsec-server.key);
- файл с сертификатом клиента (ipsec-client.crt).
На всякий случай выставляем права доступа 0400 для этих файлов, и
проверяем, что их владельцем указан root группа wheel.
Можно запустить racoon в режиме демона, и перейти к настройке Windows.
Настройка клиента.
------------------
Здесь описывается настройка для рабочей станции Windows XP. Настройка
Windows 2000 Pro, Windows 2000 Server или Windows Server 2003 может
иметь отличия (очень незначительные, в основном, в названиях оснасток MMC).
Для начала, сохраните файлы сертификата и ключа (ipsec-client.p12 и
ca.crt) где-нибудь на диске. Затем, запустите консоль управления MMC
(Start -> Run -> mmc -> press "OK"), и добавьте оснастку управления
сертификатами (File -> Add/Remove Snap-in -> press "Add" -> выберите
"Certificates" -> press "Add" -> выберите "Computer account" ->
выберите "Local computer" -> press "Finish" -> press "Close" -> press "OK").
Раскройте дерево сертификатов, отображающееся в оснастке, щелкните
правой кнопкой на контейнер "Trusted Root Certification Authorities",
и выберите "All tasks" -> "Import". Запустится мастер добавления
сертификатов. Нажмите "Next", в следующем окне нажмите кнопку
"Browse", укажите на файл корневого сертификата ЦС ca.crt, который вы
сохранили на диске, и нажмите кнопку "Next". В следующем окне выберите
"Place all certificates in the following store", выберите "Trusted
Root Certification Authorities" и нажмите "Next". Завершите процесс.
Это было необходимо сделать для того, чтобы Windows с доверием
относилась к сертификату сервера и к персональному сертификату
клиента, который мы сейчас будем устанавливать.
В этой же консоли MMC щелкните правой кнопкой на контейнер "Personal",
и выберите "All tasks" -> "Import". Запустится мастер добавления
сертификатов. Нажмите "Next", в следующем окне нажмите кнопку
"Browse", укажите на файл персонального сертификата ipsec-client.p12,
который вы сохранили на диске, и нажмите кнопку "Next".
В следующем окне введите пароль к этому сертификату, и нажмите кнопку
"Next". Не помечайте этот ключ как Exportable, если у вас нет для
этого достойных причин - это снижает безопасность сертификата, так как
в этом случае он может быть похищен.
В следующем окне выберите "Automatically select the certificate store
based on the type of certificate" и нажмите "Next". Завершите
процесс.
Проверьте - сертификат должен оказаться в субконтейнере "Certificates"
контейнера "Personal".
После успешной установки сертификатов необходимо настроить политику
IPSec (предполагается, что на рабочей станции запущен сервис "IPSec
Services", впрочем, он запущен там по умолчанию). Для этого в
запущенной консоли MMC добавьте оснастку управления политиками IPSec
(File -> Add/Remove Snap-in -> press "Add" -> выберите "IP Security
Policy Management" -> press "Add" -> выберите "Local computer" ->
press "Finish" -> press "Close" -> press "OK").
Предполагается, что на рабочей станции не установлены никакие политики
IPSec, кроме установленных по умолчанию ("Client", "Secure" и
"Server"). Эти политики не активированы по умолчанию, таковыми они и
останутся. Если же на компьютере уже есть действующая политика IPSec,
просто добавьте в неё описываемое ниже правило.
Для создания новой политики, щелкните правой кнопкой мыши на "IP
Security Policies on Local Computer" и выберите "Create IP Security
Policy". Запустится мастер настройки политики. Нажмите кнопку "Next",
и в следующем окне укажите какое-нибудь осмысленное имя для
создаваемой политики, например "My IPSec policy for 111.222.333.444".
В следующем окне оставьте помеченным чекбокс "Activate default
response rule" и нажмите кнопку "Next".
В следующем окне оставьте выбор по умолчанию "Active Directory default
(Kerberos V5 protocol)" и нажмите кнопку "Next". Не обращайте
внимания, если получите карточку с предупреждением о том, что протокол
Kerberos может использоваться только на компьютерах-членах домена -
нажмите "Yes".
В следующем окне очистьте чекбокс "Edit properties" и нажмите кнопку
"Finish".
В результате должно получиться окно свойств новой, созданной политики.
Нажмите кнопку "Add", и запустится мастер добавления правил. Нажмите
кнопку "Next", в следующем окне оставьте выбор по умолчанию "This rule
does not specify a tunnel" и нажмите кнопку "Next". В следующем окне
также оставьте "All network connections", и нажмите кнопку "Next". В
следующем за ним окне (Authentication Method) выберите "Use a
certificate from this certification authority (CA)", нажмите кнопку
"Browse" и выберите корневой сертификат вашего CA. (Если вы не можете
его найти, это означает, что вы ошиблись, и установили его не в то
хранилище сертификатов). Нажмите кнопку "Next" и перейдите к
следующему окну.
В следующем окне вам нужно создать новый фильтр. Нажмите кнопку "Add",
присвойте создаваемому фильтру какое-нибудь осмысленное имя, и нажмите
кнопку "Add". Запустится мастер создания фильтра. В качестве "Source
address" оставьте "My IP address", в качестве "Destination address"
укажите "A specific IP address" и введите IP-адрес вашего сервера, с
которым вы планируете соединяться с использованием IPSec. В следующем
окне выберите "Select a protocol type", "Any", и в следующем окне
нажмите "Finish".
(Всё это немного похоже на солюшен к квесту, не правда ли?)
Мастер создания фильтров закроется, и в предыдущем окне (создание
фильтра) вы увидите его появившимся в списке фильтров. Нажмите "OK",
окно закроется, и в предыдущем окне, в самом низу списка вы увидите
новый фильтр. Пометьте его, и нажмите "Next".
Теперь нужно выбрать действие нового фильтра (Filter action). Выберите
"Require security". Это означает, что все пакеты, направляемые на хост
с указанным адресом, должны шифроваться. Если вы хотите усилить
безопасность ещё больше, нажмите кнопку "Edit", и в появившемся окне
очистьте чекбокс "Accept unsecured communication..." и пометьте
чекбокс "Session key perfect forward secrecy (PFS)".
Примечание. Как уже говорилось ранее, у демона racoon существует
проблема с регенерацией SPD. Для того, чтобы ослабить последствия,
можно попробовать уменьшить время жизни SPD до минимума - 300 секунд.
Кроме того, это повышает степень защиты соединения (хотя и слегка
увеличивает объём трафика и нагрузку на процессоры клиента и сервера).
Для этого измените свойства всех предлагаемых Security methods
(нажмите "Edit", нажмите "Settings", и поставьте значение 300 в поле
"Generate a new key every...").
И обратите внимание вот на что. В учебнике по 216 курсу Microsoft
(Windows 2000 Network Infrastructure Administration) сказано:
<<Согласование включает поддержку только подлинности и целостности
данных с использованием протокола заголовка аутентификации (AH) или
поддержку целостности и конфиденциальности данных с использованием
протокола ESP.>>
Из чего можно сделать вывод, что использовать AH+ESP нельзя. Похоже,
что это действительно так - если создать свой Security method и
включить там одновременно поддержку AH и ESP, такой метод не работает.
Итак, политика создана. Щёлкните по ней правой кнопкой мыши, и
выберите "Assign". С этого момента политика стала действующей.
Подключитесь к Интернету, и попробуйте сделать ping на ваш сервер.
Если вы увидели одну или две строчки "Negotiating security" а затем
начали идти ответы, примите поздравления - у вас все заработало. Если
же нет - включайте вывод отладочной информации на сервере, читайте и
анализируйте. Удачи.
377 Прочтений • [IPSec между FreeBSD и Windows XP с использованием сертификатов X.509 ( freebsd win ipsec vpn tunnel security crypt)] [08.05.2012] [Комментариев: 0]
Vova
