7.1. Пример ручного конфигурирования безопасного соединения между двумя хостами.

IPSEC - довольно сложная тема. В Интернет вы найдете множество разнообразной информации по ней. Этот документ концентрируется на проблемах настройки, запуска и объяснении основных принципов функционирования. Все примеры базируются на Racoon, который уже упоминался выше.

Note

Наиболее распространенные примеры настройки iptables не позволяют прохождение пакетов IPSEC! Чтобы сделать это возможным, вам следует добавить следующие правила: iptables -A xxx -p 50 -j ACCEPT и iptables -A xxx -p 51 -j ACCEPT .

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

Шифрование, в IPSEC, выполняется протоколом ESP (Encapsulating Security Payload - Инкапсулированные Защищенные Данные), аутентификация - протоколом AH (Authentication Header - Заголовок Аутентификации). Вы можете сконфигурировать их оба, или один из них.

И ESP, и AH опираются на Security Association (защищенный виртуальный канал, или контекст безопасности). Security Association (SA) - однонаправленное логическое соединение (от отправителя к получателю) между двумя системами, поддерживающими протокол IPSec, которое однозначно идентифицируется следующими тремя параметрами:

• индексом защищенного соединения (Security Parameter Index, SPI - 32-битная константа, используемая для идентификации различных SA c одинаковыми IP-адресом получателя и протоколом безопасности);

• IP- адресом получателя IP-пакетов (IP Destination Address);

• протоколом безопасности (Security Protocol - AH или ESP).

Пример создания защищенного канала (SA) для протокола AH может выглядеть следующим образом:

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

Эта строка говорит нам, что: "Создается защищенный канал от узла сети с адресом 10.0.0.11, к узлу сети с адресом 10.0.0.216. Что это данные аутентификации, которая выполняется протоколом AH, с использованием алгоритма шифрования hmac-md5 и ключом 1234567890123456.". Эта инструкция помечена индексом SPI - 15700. Здесь есть один интересный момент - каждый защищенный виртуальный канал используется для передачи данных только в одном направлении (в данном примере: от 10.0.0.11 к 10.0.0.216). В случае необходимости двустороннего обмена создаются два виртуальных канала. Более того, для каждого из протоколов создаются свои виртуальные защищенные каналы передачи данных. Таким образом, если предполагается двусторонний обмен, с использованием обоих протоколов - и AH, и ESP, то создаются 4 защищенных канала, по одному на каждое направление для каждого из протоколов.

Пример создания защищенного канала (SA) для протокола ESP:

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

Этот пример говорит: "Создается защищенный канал от 10.0.0.11 к 10.0.0.216, в котором данные должны шифроваться алгоритмом 3des-cbc с ключом 123456789012123456789012". Индекс SPI - '15701'.

Фактически, может существовать любое число практически идентичных SA, но при этом, все они отличаются различными индексами SPI. Пока что мы видели только то, как описываются виртуальные каналы безопасности (SA), но до сих пор не встретили ни одного описания политик безопасности (правил обработки получаемых пакетов). Для того, чтобы назначить эти правила, необходимо описать политику безопасности. Она может включать в себя такие действия, как: "обрабатывать пакет с помощью IPSEC, если это возможно" или "сбросить пакет".

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

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