TCP/IP и безопасность


Автор Arnaud Aubert

Перевод Войновича Андрея

Мировое распространение компьютерной сети Интернет сделало TCP/IP самым распространенным сетевым протоколом. Несмотря на свою популярность, в нем не хватает некоторых возможностей, особенно в отношении безопасности. На самом деле, при использовании TCP/IP нет никакой уверенности, что вы установили соединение с тем, кем хотите и что данные не перехватываются. Например, пароли, используемые в протоколах HTTP, POP3, и telnet очень редко шифруются.

Инфраструктура IPsec, одобренная IESG (Internet Engineering Steering Group - Группа по Стандартизации Инженерных Решений в Интернете), позволяет определять политику, какие именно пакеты вы хотите защитить. Эти пакеты будут просто инкапсулированы в IP дэйтаграммы при использовании двух видов слоев:

Authentication Header (AH) обеспечивает целостность соединения, аутентификацию исходных данных и дополнительно может обеспечивать anti-replay сервис. Целостность данных гарантирована на 100%, но этот метод не остановит атаки вида MITM, т.е. весь аутентифицированный трафик можно прослушать.

Encapsulating Security Payload (ESP) протокол может обеспечивать конфиденциальность (шифрование) трафика. ESP также может обеспечивать целостность соединения, аутентификацию исходных данных и дополнительно anti-replay сервис. Целостность обеспечивается только для протоколов более высокого уровня. Хотя бы один из этих сервисов должен быть задействован при использовании ESP.

Эта технология абсолютно независима от протоколов, поверх которых она используется. Существуют спецификации для распространенных алгоритмов MD5 или SHA1 для аутентификации, и DES, 3DES, или Blowfish для шифрования.

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

Ключи, используемые в алгоритмах безопасности, должны быть определены в отдельном хранилище, называемом Security Association Database - SADB. Она включает набор соглашений безопасности (security associations, SA), которые, в свою очередь, состоят из определений для:

Тип соглашений безопасности (ESP или просто AH)
Уникальный 8-битный идентификатор, называемый Security Parameter Index SPI. Этот параметр должен быть одинаковым у обеих сторон.
Используемый алгоритм аутентификации (для АН и аутентифицированного ESP).
Используемый алгоритм шифрования (только для ESP соглашений безопасности).
Адреса источника и получателя для этого подключения. Отмечу, что соглашение безопасности зависит от направления; так что понадобиться создать два соглашения для защиты соединения в обоих направлениях.
Кроме того, соглашение безопасности должна включать любой ключ, используемый алгоритмами безопасности. Длины ключей зависят от алгоритма и должны быть одинаковыми у обеих сторон соединения.

Использование IPsec в Соединениях Solaris/Linux

В Linux используется два открытых проекта для реализации IPsec:

FreeSWAN – Одна из первых реально завершенных IPsec реализаций. Несмотря на его преимущества, проект приостановлен. Два других проекта продолжают его развитие: openSWAN и strongSWAN.
KAME – результат совместных разработок японских компаний для BSD платформ. Проект был портирован в Linux ядро, начиная с версии 2.5.47 и добавлен в старые ядра некоторых дистрибутивов, например Red Hat Enterprise Linux. Это ПО использовалось в данной статье для Linux.
В примере я применю политику IPsec для защиты трафика между хостом Solaris 9 192.168.1.201 и Red Hat Enterprise Linux 3 ES host 192.168.1.203. Трафик будет защищен ESP с использованием DES для шифрования и MD5 для аутентификации.

Создание Базы Данных Политик (Policy Database)

База данных политик Solaris управляется командой /usr/sbin/ipsecconf. Значения читаются во время загрузки из конфигурационного файла /etc/inet/ipsecinit.conf. Обновления можно делать во время работы при помощи анализа конфигурационных файлов с использованием параметра -a policyfile, но они не сохраняться при перезагрузке. Для защиты трафика между хостом Solaris и 192.168.1.203, мы воспользуемся ESP с любым алгоритмом шифрования или аутентификации «до» и «от» адреса Linux. Запустите следующий сценарий на хосте Solaris для использования IPsec при соединении с 192.168.1.203:

#!/usr/sbin/ipsecconf -a

{ raddr 192.168.1.203 } ipsec { encr_algs any encr_auth_algs any }

На Solaris, конфигурирование IPsec осуществляется командой ipsecconf. Основные ключи команды:

-a – загрузить конфигурационный файл IPsec.

-f – очистить текущие политики IPsec.

-l – отобразить текущие правила.

Конфигурационный файл представляет собой набор правил, определяющих, соединения с какими хостами следует защищать IPsec и какие алгоритмы при этом использовать.

Реализация KAME управляется командой setkey. KAME получает инструкции и от stdin с аргументом –с или из файла с аргументом –f. Как и в Solaris, обновления политик не сохраняются при перезагрузках.

Следующий сценарий определит такую же политику на конечной точке Solaris:

#!/sbin/setkey -f

# Secure outgoind communications

spdadd 192.168.1.203 192.168.1.201 any -P out ipsec esp/transport//require;

# Secure ingoing communications

spdadd 192.168.1.201 192.168.1.203 any -P in ipsec esp/transport//require;

Команда setkey ответственна за политики KAME и управление ключами. Самые полезные параметры:

-f filename – загрузка конфигурационного файла KAME.

-DP и -FP – отобразить и очистить текущие правила.

-D и -F – отобразить и очистить текущие ключи.

Синтаксис инструкции spdadd следующий: src_range dst_range proto_to_secure -P in|out policy.

При использовании KAME нужно добавить два явных правила для обоих транспортных направлений (определяется -P in|out). В синтаксисе Solaris инструкция raddr неявно активирует двунаправленную безопасность.

Создание базы данных соглашений безопасности (Security Association Database)

В данный момент передача данных между этими двумя хостами невозможна, т.к. политики усиливают безопасность, а ключи еще не были определены. Соглашения безопасности как раз отвечают за это и расположены в /etc/inet/secret/ipseckeys в случае с Solaris. Загружаются командой ipseckey -f filename. Для читаемости статьи были выбраны короткие ключи алгоритмов.

Выполните следующие команды в Solaris для установки соглашений безопасности, относящихся к выше описанным политикам:

#!/usr/sbin/ipseckey -f

add esp spi 0x10001 src 192.168.1.201 dst 192.168.1.203 \

encralg DES encrkey 0123456789abcdef authalg MD5 authkey \

0123456789abcdef0123456789abcdef

add esp spi 0x10002 src 192.168.1.203 dst 192.168.1.201 \

encralg DES encrkey fedcba9876543210

authalg MD5 authkey fedcba9876543210fedcba9876543210

На стороне KAME это осуществляется при помощи команды setkey:

#!/sbin/setkey -f

add 192.168.1.2O1 192.168.1.203 esp 0x10001 -E \

des-cbc 0x0123456789abcdef -A hmac-md5 0x \

0123456789abcdef0123456789abcdef;

add 192.168.1.2O3á192.168.1.201 esp 0x10002 -E des-cbc \

0xfedcba9876543210 -A hmac-md5 0x fedcba9876543210fedcba9876543210;

Заметьте, что числа 0x10001 и 0x10002 это индексы параметров безопасности (Security Parameter Indexes - SPI). Они используются для определения соглашения безопасности в SADB и должны быть одинаковыми на обеих сторонах соединения. Итак, ключи и политики настроены правильно. Теперь дамп сессии telnet будет выглядеть примерно так:

# tcpdump host 192.168.1.101

18:07:51.910553 test1 > test3: ESP(spi=0x00010002,seq=0x1e2) (DF)

18:07:51.910754 test3 > test1: ESP(spi=0x00010001,seq=0x191) (DF) [tos 0x10]

18:07:51.912927 test3 > test1: ESP(spi=0x00010001,seq=0x192) (DF) [tos 0x10]

18:07:51.953335 test1 > test3: ESP(spi=0x00010002,seq=0x1e3) (DF)

18:07:51.953436 test3 > test1: ESP(spi=0x00010001,seq=0x193) (DF) [tos 0x10]

18:07:52.003291 test1 > test3: ESP(spi=0x00010002,seq=0x1e4) (DF)

Теперь данные не передаются в открытом виде и полностью аутентифицированы. Снифер показывает SPI, которые были использованы при генерации IPsec пакетов. Для просмотра расшифрованных данных в tcpdump придется задать ключи, использованные соглашениями безопасности.

Туннелирование с IPsec

IPsec может работать и вне безопасных пакетов, в режиме туннелирования. То есть целые пакеты будут инкапсулированы. Если инкапсулируется целая дэйтаграмма, то две интрасети могут установить безопасное соединения через Internet. Адреса интрасетей включаются в туннелируемые пакеты, и таким образом будут перенаправлены правильному адресату.

Приведем пример: пусть хост Linux соединен с частной сетью 172.17.0.0/16 через интерфейс eth1 как 172.17.0.1; тогда как Solaris соединен с сетью 172.16.0.0/16 через sfe1 как 172.16.0.1.

На Solaris мы очистим политики командой ipsecconf –f и создадим классический IP-IP туннель. Не забудьте задействовать перенаправление на соответствующие сетевые интерфейсы. Использование ESP с DES и MD5 для туннеля нужно назначить аргументами encr_algs и encr_auth_algs команды ifconfig:

#!/bin/sh

ipsecconf -f

ndd -set /dev/ip ip_forwarding 0

ndd -set /dev/ip ip_strict_dst_multihoming 1

ifconfig ip.tun0 plumb

ifconfig ip.tun0 172.16.0.1 172.17.0.1 tsrc 192.168.1.201 tdst 192.168.1.203

ifconfig ip.tun0 encr_algs DES encr_auth_algs MD5

ifconfig ip.tun0 up

ndd -set /dev/ip sfe1:ip_forwarding 1

ndd -set /dev/ip ip.tun0:ip_forwarding 1

Теже операции будут сделаны на Linux/KAME:

#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward

ip tunnel add mytun mode ipip remote 192.168.1.201 local 192.168.1.203

ifconfig mytun 172.17.0.1

route add -net 172.16.0.0/16 dev mytun

setkey -c << EOF

spdflush;

flush;

add 192.168.1.201 192.168.1.203 esp 0x10001 -m tunnel -E des-cbc \

0x0123456789abcdef -A hmac-md5 0x0123456789abcdef0123456789abcdef;

add 192.168.1.203 192.168.1.201 esp 0x10002 -m tunnel -E des-cbc \

0xfedcba9876543210 -A hmac-md5 0xfedcba9876543210fedcba9876543210;

spdadd 172.16.0.0/16 172.17.0.0/16 any -P in ipsec \

esp/tunnel/192.168.1.201-192.168.1.203/require;

spdadd 172.17.0.0/16 172.16.0.0/16 any -P out ipsec \

esp/tunnel/192.168.1.203-192.168.1.201/require;

EOF

В этом примере инструкции spdflush и flush, соответственно, очищают политики и соглашения безопасности прямо в конфигурационном файле.

Заметьте, что под Linux определения соглашений безопасности теперь должны включать туннельный аргумент –m. Сеть 172.16.0.0/16 теперь может безопасно обмениваться данными с сетью 172.17.0.0/16 через сеть 192.168.1.0/24, потому что все данные туннелируются «до» и «от» 192.168.1.203 и 192.168.1.201.

Автоматизация Управления Ключами

Еще один механизм IPsec называется Internet Key Exchange – IKE (RFC 2409). Он позволяет двум хостам автоматически согласовывать способ шифрования. Автоматизация включает в себя протоколы и ключи, время жизни ключей или способ доверия, которым IKE будет оперировать до согласования. Протокол IKE делится на две фазы:

Фаза 1 (a.k.a. Основоной режим - Main Mode) – Используется метод шифрования открытым ключом для создания двустороннего соглашения безопасности ISAKMP (Internet Security Association and Key Management Protocol). Далее этот безопасный канал будет использоваться для согласования новых ключей. Можно использовать множество методов аутентификации, но мы остановимся на основных, совместно используемых ключах. Не забывайте, что вы также можете использовать сертификаты X.509.
Фаза 2 (a.k.a. Быстрый режим - Quick Mode) – Используется ISAKMP первой фазы для обмена ключами безопасности при одновременном обновлении SADB. Согласованные ключи можно запросить через дамп SADB командой setkey -D на Linux и ipseckey dump на Solaris.
Безопасное соединение будет такое же, за исключением того, что теперь мы будем использовать 3DES, а задачу выбора и смены ключей безопасности доверим операционной системе. Эти ключи будут выбираться в случайном порядке. Для начала, очистим предыдущие политики командой ipsecconf –f и SADB командой ipseckey flush. Кроме того, запросим шифрование 3DES в Solaris:

#!/usr/sbin/ipsecconf -a

{ raddr 192.168.1.203 } ipsec { encr_algs 3des encr_auth_algs md5 }

The same would be done on Linux/KAME using:

#!/sbin/setkey -f

spdflush;

spdadd 192.168.1.203 192.168.1.201 any -P out ipsec esp/transport//require;

spdadd 192.168.1.201 192.168.1.203 any -P in ipsec esp/transport//require;

Элементы SPD определены заново, теперь мы передадим управление ключами IKE.

Конфигурирование IKE на Solaris

Начнем с настройки хоста Solaris. Воспользуемся файлом /etc/inet/ike/config, который загружается in.iked демоном при включении:

{

label "Partnership with Linux/Racoon"

local_addr 192.168.1.201

remote_addr 192.168.1.203

local_id_type ip

p1_xform { auth_method preshared oakley_group 2 auth_alg md5 encr_alg 3des }

}

Правила IKE разделяются скобками и определяются меткой (label). Правила задают как локальный (local_addr) так и удаленный (remote_addr) конец. Кроме того, инструкция p1_xform заключается в указании способа защиты соединения. Более подробные инструкции доступны в man’е для ike.config (4).

Это правило IKE будет действовать между local_addr и remote_addr в обоих направлениях. Инструкция p1_xform описывает, каким образом система будет защищена. Инструкция oakley_group определяет уровень шифрования для второй фазы. Теперь необходимо определить совместно используемый закрытый ключ.

Сейчас не нужно определять длину ключа для каждого алгоритма, потому что соглашения безопасности будут сгенерированы IKE. Совместно используемые ключи в Solaris хранятся в etc/inet/secret/ike.preshared в виде набора правил. В SunOS ключи необходимо записывать в шестнадцатеричном виде. Приведем пример для ключа "AAAAAAAA":

{

localidtype IP

localid 192.168.1.201

remoteidtype IP

remoteid 192.168.1.203

key 4141414141414141

}

Каждый ключ определяется в пределах пары скобок. Ключ должен связывать один хост с другим. Localid и remoteid будут представлены в зависимости от localidtype и remoteidtype, которым указывается, как следует идентифицировать хост (в нашем случае по IP адресу).

При выполнении /usr/lib/inet/in.iked -f /etc/inet/ike/config запустится демон и применится определенное правило, перезагрузки не потребуется.

Конфигурирование IKE на Racoon

В проект KAME включен демон racoon, отвечающий за управление ключами. Файл /etc/racoon/racoon.conf определяет те же самые правила, как и на Solaris, за исключением того, что правила применятся для любого удаленного хоста.

path include '/etc/racoon';

path pre_shared_key '/etc/racoon/psk.txt'

# Phase 1 - Configuration

remote anonymous

{

exchange_mode main;

proposal { encryption_algorithm 3des; hash_algorithm md5; \

authentication_method pre_shared_key; dh_group 2; }

}

# Phase 2 - Configuration

sainfo anonymous

{

encryption_algorithm 3des ;

authentication_algorithm hmac_md5;

compression_algorithm deflate;

}

Как основная (Phase 1), так и быстрая (Phase 2) фазы должны быть настроены в файле racoon.conf. Ключевое слово работает также как p1_xform в Solaris. Compression_algorithm – обязательная инструкция, определяющая, что не должно быть задействовано сжатие пакетов (IPComp).

В /etc/racoon/psk.txt будет всего одна строка - этот закрытый ключ "AAAAAAAA" в шестнадцатеричном виде:

192.168.1.101 0x4141414141414141

Демон запускается командой racoon -f /etc/racoon/racoon.conf.

Проверяем шифрование

Теперь raccoon и in.iked запущены и правильно настроены. При помощи tcpdump удостоверимся, что были автоматически созданы соглашения безопасности для обоих направлений и проиндексированы SPI, которые не были определены вручную:

# tcpdump host 192.168.1.201

tcpdump: listening on eth0

19:39:26.127175 test1 > test3: ESP(spi=0x06db34e8,seq=0x3) (DF)

19:39:26.127284 test3 > test1: ESP(spi=0x7aa657a6,seq=0x2)

2 packets received by filter

0 packets dropped by kernel

Целью статьи было наглядно показать некоторые основные и в то же время мощные возможности инфраструктуры IPsec. Существует множество реализаций этой технологии, однако заставить их совместно работать довольно таки сложно.