| |
Linux Advanced Routing & Traffic Control HOWTO | ||
---|---|---|
Назад | Глава 7. IPSEC: безопасная передача данных протоколами IP через Интернет | Вперед |
В предыдущем разделе, шифрование было сконфигурировано с применением простых ключей. По идее, чтобы обеспечить необходимый уровень безопасности, мы должны бы передавать сведения о конфигурации по надежным каналам. Если бы нам пришлось настраивать удаленный хост через telnet, то любое третье лицо запросто могло бы получить секретные сведения, и такая конфигурация будет далеко не безопасна.
Кроме того, как только секретная информация становится известной кому-либо, она перестает быть секретной. Знание секретных сведений даст не так много удаленному пользователю, но мы должны быть абсолютно уверены в том, что каналы связи с нашими партнерами действительно надежно защищены. Эта уверенность требует большого количества ключей, если у нас есть 10 партнеров, то необходимо иметь не менее 50 различных ключей.
Помимо проблемы, связанной с необходимостью согласования ключей, существует также необходимость в периодическом их изменении. Если третья сторона сможет перехватить наш трафик, то рано или поздно она будет в состоянии "расколоть" ключ. Это может быть предотвращено за счет периодического изменения ключей, но этот процесс уже требует автоматизации.
Другая проблема состоит в том, что при работе с ключевой информацией "вручную", как это описано выше, мы заранее точно определяем алгоритмы и используемую длину ключа, что в свою очередь требует тесной координации с удаленной стороной. Желательно было бы иметь возможность определения более широкой политики назначения ключей, например так: "Мы можем использовать алгоритмы 3DES и Blowfish, с длиной ключа не менее, чем...".
Решение этих проблем берет на себя Протокол Обмена Ключами -- IKE (Internet Key Exchange), позволяющий обмениваться сгенерированными, автоматически и случайным образом, ключами. Передача ключей осуществляется с помощью асимметричной технологии кодирования, в соответствии с предопределенными алгоритмами.
В Linux IPSEC 2.5, реализация этих возможностей выполнена в виде демона KAME 'racoon' IKE. Начиная с 9 ноября 2003 года, доступны исходные тексты racoon, в пакете iptools, распространяемом Алексеем, хотя, возможно, вам придется удалить строки #include <net/route.h> в двух файлах. В качестве альтернативы я могу предложить откомпилированную версию.
Протокол IKE работает через UDP порт 500, предоставьте ему такую возможность, внеся соответствующие изменения в ваш набор правил для iptables. |
Как уже говорилось ранее, в случае автоматической настройки, обновление и обмен ключевой информацией выполняется без нашего участия. Очевидно, что при этом "на лету" создаются защищенные каналы (SA), которые, как это ни странно, не обеспечиваются какой-либо политикой безопасности.
Таким образом, чтобы воспользоваться преимуществами IKE, необходимо установить для него политику безопасности. Для этого создается такая политика, которая не связана с каким-либо конкретным защищенным каналом (SA). Когда ядро обнаружит такую политику, то оно передаст ее демону IKE, который в свою очередь будет использовать ее в своей работе.
Повторюсь еще раз: Политика Безопасности определяет -- ЧТО следует предпринять в том или ином случае, а Контекст Безопасности (защищенный канал) определяет -- КАК производить обмен данными. Автоматическое управление ключевой информацией позволяет нам избежать неприятностей только с определением "ЧТО предпринять".
Kame racoon имеет достаточно неплохие настройки по-умолчанию, так что мы не будем их касаться. Как уже говорилось выше, мы должны определить только политику безопасности, оставив право на создание защищенных каналов за демоном IKE.
В этом примере, мы опять вернемся к нашим хостам 10.0.0.11 и 10.0.0.216, и еще раз попробуем установить защищенное соединение между ними, но на сей раз с помощью racoon. Для упрощения конфигурации будем использовать предопределенные ключи, сертификаты X.509 будут обсуждаться в отдельном разделе (см. раздел Автоматизация с использованием сертификатов X.509).
Мы будем придерживаться конфигурации, заданной практически по-умолчанию и идентичной для обоих хостов:
path pre_shared_key "/usr/local/etc/racoon/psk.txt"; remote anonymous { exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address; lifetime time 2 min; # sec,min,hour initial_contact on; proposal_check obey; # obey -- повиноваться, требованиям и ограничениям proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 2 min; encryption_algorithm 3des ; authentication_algorithm hmac_sha1; compression_algorithm deflate ; }
Многие из параметров настройки, на мой взгляд, могут быть удалены, поскольку они достаточно близки к заданным по-умолчанию. Здесь приведены два анонимных параметра, которые применяются ко всем удаленным хостам, за счет чего достигается простота конфигурации. На данный момент пока нет особой потребности в создании настроек для каждого конкретного хоста.
Кроме того, в настройках задана самоидентификация на основе собственного IP-адреса (my_identifier address). Затем объявляются используемые алгоритмы шифрования -- 3des и sha1 и указывается, что будут использоваться предопределенные ключи, расположенные в файле psk.txt.
Содержимое файлов psk.txt с ключами приводится ниже. Для разных хостов они различны. Для хоста 10.0.0.11:
10.0.0.216 password2Для хоста 10.0.0.216:
10.0.0.11 password2
Назначте владельцем файла суперпользователя (root), и установите права доступа 0600, в противном случае racoon откажется доверять их содержимому.
Теперь можно приступить к формированию политик безопасности, которые в данной ситуации достаточно просты и незамысловаты. На хосте 10.0.0.216:
#!/sbin/setkey -f flush; spdflush; spdadd 10.0.0.216 10.0.0.11 any -P out ipsec esp/transport//require; spdadd 10.0.0.11 10.0.0.216 any -P in ipsec esp/transport//require;На хосте 10.0.0.11:
#!/sbin/setkey -f flush; spdflush; spdadd 10.0.0.11 10.0.0.216 any -P out ipsec esp/transport//require; spdadd 10.0.0.216 10.0.0.11 any -P in ipsec esp/transport//require;Теперь все готово к запуску racoon! После того, как он будет запущен, попробуем установить сеанс связи, через telnet, с хоста 10.0.0.11 на хост 10.0.0.216, впрочем можно и наоборот. racoon тут же начнет "переговоры" с удаленным хостом:
12:18:44: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA request for 10.0.0.11 queued due to no phase1 found. 12:18:44: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500] 12:18:44: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode. 12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon 12:18:44: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find the proper pskey, try to get one by the peer's address. 12:18:44: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA established 10.0.0.216[500]-10.0.0.11[500] spi:044d25dede78a4d1:ff01e5b4804f0680 12:18:45: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.216[0]<=>10.0.0.11[0] 12:18:45: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=44556347(0x2a7e03b) 12:18:45: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=15863890(0xf21052)Если теперь дать команду setkey -D, чтобы просмотреть список созданных защищенных каналов, мы получим такой вывод:
10.0.0.216 10.0.0.11 esp mode=transport spi=224162611(0x0d5c7333) reqid=0(0x00000000) E: 3des-cbc 5d421c1b d33b2a9f 4e9055e3 857db9fc 211d9c95 ebaead04 A: hmac-sha1 c5537d66 f3c5d869 bd736ae2 08d22133 27f7aa99 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Nov 11 12:28:45 2002 current: Nov 11 12:29:16 2002 diff: 31(s) hard: 600(s) soft: 480(s) last: Nov 11 12:29:12 2002 hard: 0(s) soft: 0(s) current: 304(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 3 hard: 0 soft: 0 sadb_seq=1 pid=17112 refcnt=0 10.0.0.11 10.0.0.216 esp mode=transport spi=165123736(0x09d79698) reqid=0(0x00000000) E: 3des-cbc d7af8466 acd4f14c 872c5443 ec45a719 d4b3fde1 8d239d6a A: hmac-sha1 41ccc388 4568ac49 19e4e024 628e240c 141ffe2f seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Nov 11 12:28:45 2002 current: Nov 11 12:29:16 2002 diff: 31(s) hard: 600(s) soft: 480(s) last: hard: 0(s) soft: 0(s) current: 231(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2 hard: 0 soft: 0 sadb_seq=0 pid=17112 refcnt=0А команда setkey -DP -- список политик безопасности, даст такой результат:
10.0.0.11[any] 10.0.0.216[any] tcp in ipsec esp/transport//require created:Nov 11 12:28:28 2002 lastused:Nov 11 12:29:12 2002 lifetime:0(s) validtime:0(s) spid=3616 seq=5 pid=17134 refcnt=3 10.0.0.216[any] 10.0.0.11[any] tcp out ipsec esp/transport//require created:Nov 11 12:28:28 2002 lastused:Nov 11 12:28:44 2002 lifetime:0(s) validtime:0(s) spid=3609 seq=4 pid=17134 refcnt=3
Если этот вариант у вас не работает, проверьте -- все ли файлы конфигурации принадлежат суперпользователю (root) и доступны на чтение только ему. Чтобы запустить racoon в приоритетном режиме, используйте ключ '-F'. Чтобы указать ему местоположение файла конфигурации -- ключ '-f'. Для того, чтобы увеличить детальность, добавьте инструкцию 'log debug;' в racoon.conf.
Как уже говорилось, использование предопределенных ключей осложнено необходимостью тесной координации с удаленной стороной, что не всегда бывает удобно. Кроме того, при согласовании ключевой информации она становится известной нескольким лицам (по крайней мере двоим), а секрет, который знают несколько человек, перестает быть секретом. К счастью существуют асимметричные технологии кодирования, которые помогают снять эту проблему.
Если каждая из сторон, использующих IPSEC, создаст открытый и секретный ключи, то обе стороны, обменявшись своими открытыми ключами и настроив политику безопасности, смогут установить защищенное соединение.
Процедура создания ключей относительно проста, хотя и требует выполнения некоторых дополнительных действий. Ниже рассматривается пример использования, для этих целей, утилиты openssl.
OpenSSL обладает разветвленной инфраструктурой поддержки ключей, используемых для подтверждения сертификатов подлинности. Прямо сейчас, мы с вами пройдем всю процедуру создания сертификатов и настройки защищенного соединения.
Для начала создадим сертификат для нашего хоста, с именем laptop. Начнем с генерации "запроса на сертификат":
$ openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout \ laptop.private -outform PEM -out request.pemЗдесь будет предложено ответить на ряд вопросов:
Country Name (2 letter code) [AU]:NL State or Province Name (full name) [Some-State]:. Locality Name (eg, city) []:Delft Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linux Advanced Routing & Traffic Control Organizational Unit Name (eg, section) []:laptop Common Name (eg, YOUR name) []:bert hubert Email Address []:ahu@ds9a.nl Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:Заполните поля запроса по своему усмотрению.
Теперь создадим собственно сертификат, подписанный самим собой:
$ openssl x509 -req -in request.pem -signkey laptop.private -out \ laptop.public Signature ok subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic \ Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl Getting Private keyПосле этого файл request.pem можно удалить.
Повторите эту процедуру для всех ваших компьютеров. Вы можете свободно передавать сгенерированные открытые ключи (файлы .public), но сохраняйте файлы .private в секрете!
Теперь, после того как мы создали открытый и секретный ключи, мы можем передать их racoon.
Вернемся к нашей предыдущей конфигурации хостов 10.0.0.11 ('upstairs') и 10.0.0.216 ('laptop').
В файл racoon.conf, на 10.0.0.11, добавим:
path certificate "/usr/local/etc/racoon/certs"; remote 10.0.0.216 { exchange_mode aggressive,main; my_identifier asn1dn; peers_identifier asn1dn; certificate_type x509 "upstairs.public" "upstairs.private"; peers_certfile "laptop.public"; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2 ; } }Тем самым сообщив racoon, что сертификаты находятся в каталоге /usr/local/etc/racoon/certs/. Кроме того, добавим раздел, описывающий удаленный компьютер 10.0.0.216.
Строки asn1dn говорят о том, что локальный и удаленный идентификаторы следует извлекать из открытых ключей. Это -- 'subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl' из листинга, приведенного выше.
Строка certificate_type указывает имена файлов с локальными открытым и секретным ключами. peers_certfile указывает, что открытый ключ удаленного узла следует взять из файла laptop.public.
Блок proposal остается, по сравнению с предыдущей конфигурацией, практически без изменений, за исключением authentication_method для которого теперь указано rsasig, что означает -- использовать для аутентификации RSA открытый/секретный ключи.
Аналогичные изменения вносятся и в конфигурацию хоста 10.0.0.216:
path certificate "/usr/local/etc/racoon/certs"; remote 10.0.0.11 { exchange_mode aggressive,main; my_identifier asn1dn; peers_identifier asn1dn; certificate_type x509 "laptop.public" "laptop.private"; peers_certfile "upstairs.public"; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2 ; } }После внесения изменений в конфигурацию, нам необходимо разместить файлы ключей. На машине 'upstairs', в каталоге /usr/local/etc/racoon/certs, следует разместить файлы upstairs.private, upstairs.public и laptop.public.
ВНИМАНИЕ! Владельцем этого каталога должен быть суперпользователь (root) и ему должны быть назначены права доступа 0700, иначе racoon откажется работать с ним! |
А на машине 'laptop', опять же в каталоге /usr/local/etc/racoon/certs, нужно разместить файлы laptop.private, laptop.public и upstairs.public. Короче говоря, на каждом хосте должны размещаться его собственные открытый и секретный ключи, а так же открытые ключи удаленных систем.
Проверьте настройки политик безопасности (выполните строки spdadd, из раздела Пример). Теперь запустите racoon -- все должно работать.
Чтобы иметь возможность установить защищенное соединение с удаленной стороной, необходимо обменяться открытыми ключами. Несмотря на то, что открытый ключ можно распространять свободно, очень важно сохранить его целостность. Другими словами, всегда следует проверять -- не получили ли вы "кота в мешке".
Сделать это довольно просто, OpenSSL имеет команду digest, которая вычисляет контрольную сумму файла с ключом:
$ openssl dgst upstairs.public MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1После получения вашего ключа, удаленная сторона так же вычисляет его контрольную сумму и, если они совпали (сообщить свою контрольную сумму вы может при личной встрече или по телефону), то все в порядке!
Другой вариант -- воспользоваться услугами третьей доверенной стороны -- Certificate Authority, которая может подписать созданные вами сертификаты.
Назад | В начало документа | Вперед |
IPSEC: безопасная передача данных протоколами IP через Интернет | К началу раздела | Туннели IPSEC |
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |