Автор: Mike DeGraw-Bertsch
Перевод: Сгибнев Михаил
В предыдущей статье нами было рассмотрено, как соединить два хоста с
помощью предопределенных ключей. Хотите двигаться дальше, в сторону
сертификатов X.509? Это хорошая идея, так как ничего сложного в этом
вопросе нет и тем более, что метод предопределенных ключей может быть
исключен из IPSec версии 2.
Все просто, но только в том случае. если Вы знакомы с OpenSSL, в
противном случае Вы можете получить немало печальных минут. В данной
статье предполагается, что сертификаты формируются между различными
хостами и туннельным сервером, но функциональные возможности и
установка также идентичны и для транспортного режима.
Быстрый обзор
Давайте определим список используемых сокращений и определений.
Сетрификаты X.509 базируются на методе шифрования с открытым ключом.
Каждый сертификат наряду с другой информацией (сроком действия, именем
владельца и т.п.) содержит публичный ключ. Секретный ключ владелец
сохраняет в отдельном файле.
Сертификаты подписываются Certificate Authority (CA), что позволяет
подтвердить подлинность сертификата, информации, содержащейся в
сертификате и, в конечном итоге, удаленного хоста. Подлинность CA
проверяется в соответствии с его свидетельством, которое является
общедоступным.
Для получения более подробной информации относительно сертификатов
X.509 - смотри здесь:
http://java.sun.com/products/jdk/1.2/docs/guide/security/cert3.html#inside
Требования
Выполнение идентификации IPSec на основе сертификатов требует двух
вещей. Наличии racoon, по возможности, самой последней версии (смотри
в /usr/ports/security/racoon) и OpenSSL, версия 0.9.5a или выше.
Версия, идущая с FreeBSD по умолчанию не имеет такого полезного
сценария CA.pl, так что Вы должны загрузить и установить последнюю
версию OpenSSL, которая по умолчанию поместит CA.pl
в/usr/local/ssl/misc/CA.pl.
Создание собственного CA
С OpenSSL, Вы можете создать ваши собственные сертификаты и даже
Certificate Authority - это значит, что Вы можете создать, подписать и
распространить свой сертификат по всему миру. В этом случае вся
мировая общественность не сможет опознать Вас как CA ("я хочу принять
сертификат ООО "Хренсгоры"? Нет!"), но позволяет идентифицировать
уникальный хост. И это - все, что Вам необходимо для двух хостов,
соединяющихся с вашим туннельным сервером.
Вы можете захотеть создать свой CA на туннельном сервере, а можете и
не захотеть. Вам решать.
Для начала, входите на любой хост, который будет играть роль CA и
создайте каталог, где Вы будете хранить свои сертификаты. Создать
подкаталоги CA (demoCA), можно запустив следующий сценарий:
/usr/local/ssl/misc/CA.pl -newca
Когда будет запрошено имя сертификата CA, нажмите Enter. Затем будет
запрошен пароль на защиту секретного ключа CA. Очень важно озаботиться
безопасностью этого пароля, иначе любой человек сможет подписывать
сертификаты от Вашего имени. Затем, будет запрошена информация о вашем
местоположении, компании, общем имени, и адресе электронной почты. Все
это понятно, кроме "общего имени". Это - принудительный бит
однозначного определения данных, типа полностью уточненного имени
домена Вашего хоста или Вашего имени.
После ввода требуемой информации, подкаталог demoCA будет создан. При
большом желании можно дать chmod к файлу частного ключа
(demoCA/private/cakey.pem), разрешив его на чтение только для root. Но
это не должно быть необходимым, ведь Вы указали хороший пароль?
Вы можете игнорировать большинство содержания demoCA, но в ближайшем
будущем Вы будете должны использовать demoCA/cacert.pem.
Создание и установка сертификатов
Теперь, когда все готово для подписи сертификатов, Вы можете создавать
их для всех хостов Вашей сети. Есть несколько простых шагов,
одинаковых для каждого удаленного хоста и туннельного сервера.
Первый шаг должен создать публичный ключ и запрос сертификата. На
сервере СА выполните:
Затем, сертификат должен быть подписан. Проще всего это сделать с
помощью команды CA.pl -sign. Укажите пароль СА, затем ответьте "y" на
подсказки, указав, что Вы хотите подписать сертификат.
В результате Вы будете теперь иметь три файла, чтобы скопировать их на
соответствующую машину: demoCA/cacert.pem, newcert.pem, и privkey.pem.
Поместите их в /usr/local/etc/racoon/cert на конфигурируемом клиенте.
Удостоверьтесь, что только root может читать его!
Заключительный шаг заключается в том, что мы должны позволить хосту
распознавать другие сертификаты, подписанные нашим СА. Заходим на
машину и выполняем:
Символическая ссылка позволяет OpenSSL находить сертификат Вашего СА,
основанного на его хэше, таким образом проверяя, что сертификат
является подлинным и приемлемым.
Все вышеуказанные шаги повторить для всех хостов, соединяющихся с
туннельным сервером.
Конфигурирование racoon
Нашей последней задачей является конфигурирование racoon, таким
образом, чтобы он принимал сертификаты. Начинаем править файл
конфигурации, обычно это /usr/local/etc/racoon/racoon.conf.
Проверяем путь хранения сертификатов6
path certificate "/usr/local/etc/racoon/cert" ;
Затем предстоит изменить блок "remote" для принятия и использования
сертификатов.
remote anonymous
{
exchange_mode main,aggressive;
doi ipsec_doi;
situation identity_only;
my_identifier asn1dn - говорит, что racoon должен идентифицировать
себя используя Distinguished Name (DN), как определено в соответствии
с его сертификатом. peers_identifier asn1dn определяет, что удаленный
хост должен идентифицировать себя с отличительным именем его
сертификата. verify_identifier on гарантирует, что посылаемый тип
идентификации - тот же самый, который определен в peers_identifier; в
этом случае это - asn1dn. Строка certificate_type указывает racoon
использовать сертификацию X.509. cert.pem - имя файла сертификата
локального хоста, в то время как key.pem - его секретный ключ. Эти
имена файла должны быть изменены на данные Вами. Последняя строка,
которая была изменена, authentication_method rsasig, говорит racoon,
что он должен использовать идентификацию на основе сертификатов для
других хостов.
Запуск и поиск неисправностей
Остановите racoon на клиентах и сервере. Перезапустите их и
просмотрите log-файл. Пропингуйте один хост с другого. В конце
лог-файла должны обнаружиться примерно такие строки:
02:12:46: INFO: isakmp.c:1681:isakmp_post_acquire():
IPsec-SA request for 10.0.0.2 queued due to no phase1 found.
02:12:46: INFO: isakmp.c:795:isakmp_ph1begin_i():
initiate new phase 1 negotiation: 10.0.0.77[500]<=>10.0.0.2[500]
02:12:46: INFO: isakmp.c:800:isakmp_ph1begin_i():
begin Identity Protection mode.
02:12:46: INFO: pfkey.c:1365:pk_recvexpire(): IPsec-SA expired:
ESP/Tunnel 10.0.0.2->10.0.0.77 spi=122493290(0x74d196a)
02:12:46: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon
02:12:46: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon
02:12:46: INFO: isakmp.c:2409:log_ph1established():
ISAKMP-SA established 10.0.0.77[500]-10.0.0.2[500] spi:0dab7579614a1047:50c0edf86b1a8602
02:12:47: INFO: isakmp.c:939:isakmp_ph2begin_i():
initiate new phase 2 negotiation: 10.0.0.77[0]<=>10.0.0.2[0]
02:12:47: INFO: pfkey.c:1107:pk_recvupdate():
IPsec-SA established: ESP/Tunnel 10.0.0.2->10.0.0.77 spi=23298201(0x1638099)
02:12:47: INFO: pfkey.c:1319:pk_recvadd():
IPsec-SA established: ESP/Tunnel 10.0.0.77->10.0.0.2 spi=52337518(0x31e9b6e)
Если это не так то в первую очередь проверьте все пути в racoon.conf,
затем правильность создания символической ссылки, проверьте политики
безопасности.
1390 Прочтений • [Введение в сертификаты IPSec и настройка Racoon (ipsec openssl crypt security)] [08.05.2012] [Комментариев: 0]
Vova
