Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

Типичный пример назначения политики безопасности:

spdadd 10.0.0.216 10.0.0.11 any –P out ipsec

esp/transport//require

ah/transport//require;

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

Другими словами, Политика Безопасности описывает ЧТО следует предпринять в том или ином случае, а защищенный канал (SA) – КАК получить данные.

Исходящие пакеты "подписываются" соответствующим SPI (КАК). Ядро использует его для нужд шифрования и аутентификации так, чтобы удаленный хост мог выполнить необходимые проверки и дешифрацию.

Ниже следует пример простой конфигурации, обеспечивающей передачу данных от 10.0.0.216 к 10.0.0.11 с аутентификацией, в зашифрованном виде. Обратите внимание на то, что в обратном направлении данные передаются в открытом виде. Это лишь первая версия примера и она не должна рассматриваться вами как пригодная к употреблению.

Для хоста 10.0.0.216:

#!/sbin/setkey –f

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

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;

Для хоста 10.0.0.11, те же самые SA, но без политики безопасности:

#!/sbin/setkey –f

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

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

В этой конфигурации попробуем дать команду ping 10.0.0.11с хоста 10.0.0.216. В результате получим такой вывод от tcpdump:

22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa): ESP(spi=0x00005fb5,seq=0xa) (DF)

22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply

Обратите внимание на то, как возвращается ответ на запрос – он передается в открытом виде. В то время как сам запрос не распознается утилитой tcpdump, но зато она показывает SPI для AH и ESP, которые инструктируют хост 10.0.0.11, КАК выполнить проверку подлинности и дешифровать данные.

Следует сделать несколько замечаний по поводу этих примеров. Такая конфигурация не обеспечивает достаточный уровень безопасности. Проблема состоит в том, что политика безопасности описывает только — ЧТО должен сделать хост 10.0.0.216 при передаче данных хосту 10.0.0.11 и КАК их передать, а для хоста 10.0.0.11 описывается КАК он может получить эти данные, но нет правил, описывающих ЧТО он должен предпринять при получении нешифрованных пакетов, идущих от 10.0.0.216!

Таким образом, если злоумышленник будет в состоянии выполнить "подмену" (spoofing) IP-адреса, то он сможет отправлять незашифрованные данные хосту 10.0.0.11, который примет их! Для устранения этой проблемы нужно прописать политику безопасности для хоста 10.0.0.11:

#!/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, которая отобразит сконфигурированные политики безопасности.

В предыдущем разделе, шифрование было сконфигурировано с применением простых ключей. По идее, чтобы обеспечить необходимый уровень безопасности, мы должны бы передавать сведения о конфигурации по надежным каналам. Если бы нам пришлось настраивать удаленный хост через telnet, то любое третье лицо запросто могло бы получить секретные сведения, и такая конфигурация будет далеко не безопасна.

Кроме того, как только секретная информация становится известной кому-либо, она перестает быть секретной. Знание секретных сведений даст не так много удаленному пользователю, но мы должны быть абсолютно уверены в том, что каналы связи с нашими партнерами действительно надежно защищены. Эта уверенность требует большого количества ключей, если у нас есть 10 партнеров, то необходимо иметь не менее 50 различных ключей.

Помимо проблемы, связанной с необходимостью согласования ключей, существует также необходимость в периодическом их изменении. Если третья сторона сможет перехватить наш трафик, то рано или поздно она будет в состоянии "расколоть" ключ. Это может быть предотвращено за счет периодического изменения ключей, но этот процесс уже требует автоматизации.

Другая проблема состоит в том, что при работе с ключевой информацией "вручную", как это описано выше, мы заранее точно определяем алгоритмы и используемую длину ключа, что в свою очередь требует тесной координации с удаленной стороной. Желательно было бы иметь возможность определения более широкой политики назначения ключей, например так: "Мы можем использовать алгоритмы 3DES и Blowfish, с длиной ключа не менее, чем…".

Решение этих проблем берет на себя Протокол Обмена Ключами — IKE (Internet Key Exchange), позволяющий обмениваться сгенерированными, автоматически и случайным образом, ключами. Передача ключей осуществляется с помощью асимметричной технологии кодирования, в соответствии с предопределенными алгоритмами.

В Linux IPSEC 2.5, реализация этих возможностей выполнена в виде демона KAME 'racoon' IKE. Начиная с 9 ноября 2003 года, доступны исходные тексты racoon, в пакете iptools, распространяемом Алексеем, хотя, возможно, вам придется удалить строки #include в двух файлах. В качестве альтернативы я могу предложить откомпилированную версию .