7.2. Пример автоматического конфигурирования безопасного соединения между двумя хостами.
В предыдущем разделе, шифрование было сконфигурировано с применением простых ключей. По идее, чтобы обеспечить необходимый уровень безопасности, мы должны бы передавать сведения о конфигурации по надежным каналам. Если бы нам пришлось настраивать удаленный хост через 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. |
7.2.1. Теория.
Как уже говорилось ранее, в случае автоматической настройки, обновление и обмен ключевой информацией выполняется без нашего участия. Очевидно, что при этом "на лету" создаются защищенные каналы (SA), которые, как это ни странно, не обеспечиваются какой-либо политикой безопасности.
Таким образом, чтобы воспользоваться преимуществами IKE, необходимо установить для него политику безопасности. Для этого создается такая политика, которая не связана с каким-либо конкретным защищенным каналом (SA). Когда ядро обнаружит такую политику, то оно передаст ее демону IKE, который в свою очередь будет использовать ее в своей работе.
Повторюсь еще раз: Политика Безопасности определяет -- ЧТО следует предпринять в том или ином случае, а Контекст Безопасности (защищенный канал) определяет -- КАК производить обмен данными. Автоматическое управление ключевой информацией позволяет нам избежать неприятностей только с определением "ЧТО предпринять".
7.2.2. Пример.
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
7.2.2.1. Известные проблемы и недостатки.
Если этот вариант у вас не работает, проверьте -- все ли файлы конфигурации принадлежат суперпользователю (root) и доступны на чтение только ему. Чтобы запустить racoon в приоритетном режиме, используйте ключ '-F'. Чтобы указать ему местоположение файла конфигурации -- ключ '-f'. Для того, чтобы увеличить детальность, добавьте инструкцию 'log debug;' в racoon.conf.
7.2.3. Автоматизация с использованием сертификатов X.509
Как уже говорилось, использование предопределенных ключей осложнено необходимостью тесной координации с удаленной стороной, что не всегда бывает удобно. Кроме того, при согласовании ключевой информации она становится известной нескольким лицам (по крайней мере двоим), а секрет, который знают несколько человек, перестает быть секретом. К счастью существуют асимметричные технологии кодирования, которые помогают снять эту проблему.
Если каждая из сторон, использующих IPSEC, создаст открытый и секретный ключи, то обе стороны, обменявшись своими открытыми ключами и настроив политику безопасности, смогут установить защищенное соединение.
Процедура создания ключей относительно проста, хотя и требует выполнения некоторых дополнительных действий. Ниже рассматривается пример использования, для этих целей, утилиты openssl.
7.2.3.1. Создание собственного сертификата X.509.
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 в секрете!
7.2.3.2. Настройка и запуск.
Теперь, после того как мы создали открытый и секретный ключи, мы можем передать их 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 -- все должно работать.
7.2.4. Как сохранить настройки туннеля в безопасности.
Чтобы иметь возможность установить защищенное соединение с удаленной стороной, необходимо обменяться открытыми ключами. Несмотря на то, что открытый ключ можно распространять свободно, очень важно сохранить его целостность. Другими словами, всегда следует проверять -- не получили ли вы "кота в мешке".
Сделать это довольно просто, OpenSSL имеет команду digest, которая вычисляет контрольную сумму файла с ключом:
$ openssl dgst upstairs.public
MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1
После получения вашего ключа, удаленная сторона так же вычисляет его контрольную сумму и, если
они совпали (сообщить свою контрольную сумму вы может при личной встрече или по телефону),
то все в порядке!
Другой вариант -- воспользоваться услугами третьей доверенной стороны -- Certificate Authority, которая может подписать созданные вами сертификаты.