Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

• Название: Linux Advanced Routing & Traffic Control HOWTO
• Автор: Bert Hubert
• Жанр: Программное обеспечение

Оригинальную версию документа вы найдете по адресу http://lartc.org/.

Практическое руководство по применению iproute2 (и в меньшей степени netfilter) для управления трафиком.

---

#!/sbin/setkey –f

spdadd 10.0.0.216 10.0.0.11 any –P IN ipsec

   esp/transport//require

   ah/transport//require;

Это описание сообщает хосту 10.0.0.11, что весь входящий трафик от хоста 10.0.0.216 должен иметь подтверждение подлинности (AH) и должен быть зашифрован (ESP).

Ниже приводится полная конфигурация сетевых узлов 10.0.0.11 и 10.0.0.216, для двустороннего обмена данными. Полная конфигурация для хоста 10.0.0.216:

#!/sbin/setkey –f

flush;

spdflush;

# AH

add 10.0.0.11 10.0.0.216 ah 15700 –A hmac-md5 "1234567890123456";

add 10.0.0.216 10.0.0.11 ah 24500 –A hmac-md5 "1234567890123456";

# ESP

add 10.0.0.11 10.0.0.216 esp 15701 –E 3des-cbc "123456789012123456789012";

add 10.0.0.216 10.0.0.11 esp 24501 –E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any –P out ipsec

   esp/transport//require

   ah/transport//require;

spdadd 10.0.0.11 10.0.0.216 any –P in ipsec

   esp/transport//require

   ah/transport//require;

И для 10.0.0.11:

#!/sbin/setkey –f

flush;

spdflush;

# AH

add 10.0.0.11 10.0.0.216 ah 15700 –A hmac-md5 "1234567890123456";

add 10.0.0.216 10.0.0.11 ah 24500 –A hmac-md5 "1234567890123456";

# ESP

add 10.0.0.11 10.0.0.216 esp 15701 –E 3des-cbc "123456789012123456789012";

add 10.0.0.216 10.0.0.11 esp 24501 –E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.11 10.0.0.216 any –P out ipsec

   esp/transport//require

   ah/transport//require;

spdadd 10.0.0.216 10.0.0.11 any –P in ipsec

   esp/transport//require

   ah/transport//require;

Обратите внимание — в этом примере использованы идентичные ключи шифрования для обоих направлений. Однако, это не является обязательным требованием.

Чтобы проверить только что созданную конфигурацию, достаточно дать команду setkey –D, которая выведет перечень контекстов защиты (виртуальных защищенных каналов) или setkey –DP, которая отобразит сконфигурированные политики безопасности.

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> в двух файлах. В качестве альтернативы я могу предложить откомпилированную версию.

Note

Протокол 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 тут же начнет "переговоры" с удаленным хостом: