Посмотрело: 7392

0 Давайте рассмотрим детали технологий, составляющих суть IPSec. Стандарты, используемые в рамках IPSec, являются достаточно сложными для понимания, поэтому в этом разделе мы рассмотрим каждую из составляющих IPSec подробно. Для понимания того что такое IPSEC используйте документ "IPSEC как протокол защиты сетевого трафика", опубликованный ранее на этом сайте. Данная статья является продолжением вышеуказанного документа.

В IPSec используются следующие технологии:

• протокол АН;
• протокол ESP;
• стандарт шифрования DES;
• стандарт шифрования 3DES;
• протокол IKE;
• метод согласования ключей по схеме Диффи-Хеллмана;
• хэшированные коды аутентичности сообщений (НМАС);
• защита RSA;
• центры сертификации.

Протокол АН

Данный протокол обеспечивает аутентификацию и целостность данных для пакетов IP, передаваемых между двумя системами. Протокол АН не
обеспечивает конфиденциальность (т.е. шифрование) пакетов. Аутентификация выполняется путем применения к пакету односторонней, зависящей от ключа функции хэширования, генерирующей "профиль" сообщения. Изменение любой части пакета в пути передачи будет обнаружено получателем в результате применения к полученным данным аналогичной односторонней функции хэширования и сравнения вычисленного значения профиля сообщения с тем, которое указал отправитель. Аутентичность полученной информации гарантируется тем, что для одностороннего хэширования обеими системами используется один и тот же секретный ключ. Схема работы протокола АН пока¬зана ниже. При этом выполняются следующие действия.

1. Выполняется хэширование IP-заголовка и полезного груза пакета.
2. Полученный хэш-код используется при построении нового заголовка АН, который подсоединяется к исходному пакету между заголовком и блоком полезного груза.
3. Новый пакет передается второй стороне IPSec.
4. Сторона-получатель вычисляет значение хэш-кода для заголовка IP и полезного груза, извлекает переданное значение хэш-кода из заголовка АН и сравнивает эти два значения. Соответствующие значения хэш-кода должны в точности совпадать. Если в пути изменится хотя бы один бит пакета, вычисленный получателем хэш-код пакета не будет совпадать со значением, указанным в заголовке АН.

Протокол АН обеспечивает аутентификацию для максимально возможного числа полей заголовка IP, как и для полей данных протоколов высших уровней. Однако некоторые поля заголовка IP могут изменяться в пути. Значения изменяемых полей (например, поля TTL, указывающего время существования пакета) изменяются промежуточными сетевыми устройствами, через которые проходит пакет, и такие изменения отправитель прогнозировать не может. Значения изменяемых полей не должны защищаться протоколом АН. Таким образом, защита, которая обеспечивается заголовку IP протоколом АН, оказывается несколько ограниченной. Протокол АН может также дополнительно обеспечить защиту от воспроизведения пакетов, для чего в заголовке IP указывается порядковый номер пакета. Полное описание протокола АН со¬держится в документе RFC 2402.

Протокол ESP

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

Протокол ESP обеспечивает конфиденциальность с помощью шифрования на уровне пакетов IP. При этом поддерживается множество алгоритмов симметричной схемы шифрования. Алгоритмом по умолчанию для IPSec является DES с 56-битовым ключом. Этот шифр должен присутствовать для гарантии совместимости между всеми поддерживающими IPSec продуктами. Продукты Cisco поддерживают также алгоритм 3DES, обеспечивающий более стойкое шифрование. Конфиденциальность может быть выбрана независимо от других сервисов.

Аутентификация источника данных и поддержка целостности без установления соединений используются совместно и являются опциями (т.е. необязательны). Эти возможности можно также объединить с сервисом конфиденциальности.
Сервис защиты от воспроизведения можно выбрать только в том случае, если выбрана аутентификация источника данных, и выбор этого сервиса является исключительной прерогативой получателя. Хотя по умолчанию от отправителя и требуется ав¬томатически увеличивать порядковый номер, используемый для защиты от воспроизведения, этот сервис оказывается эффективным только в том случае, если получатель проверяет этот порядковый номер. Конфиденциальность трафика требует выбора тун¬нельного режима. Наиболее эффективным это оказывается в шлюзе защиты, где маскировка источника-адресата может быть выполнена сразу для всего трафика. Здесь следует отметить, что хотя и конфиденциальность, и аутентификация являются опциями, должен быть выбран по крайней мере один из этих сервисов.
Набор сервисов, обеспечиваемых протоколом ESP, зависит от параметров, которые указываются в конфигурации IPSec и выбираются при создании ассоциации защиты IPSec. Однако выбор конфиденциальности без целостности/аутентификации (или в рамках ESP, или отдельно с помощью АН) оставляет противнику возможность для проведения атак определенного вида, что может ограничить пользу применяемого та¬ким образом сервиса конфиденциальности.
Заголовок ESP вставляется в пакет после заголовка IP перед заголовком протокола высшего уровня (в транспортном режиме) или перед инкапсулированным заголовком IP (в туннельном режиме). Полное описание протокола ESP содержится в документе RFC 2406.

Шифрование ESP с применением НМАС

В рамках протокола ESP может также обеспечиваться аутентификация пакетов с помощью необязательного поля аутентификации. В программном обеспечении Cisco IOS и в брандмауэрах PIX Firewall этот сервис называется ESP НМАС. Значения аутентификации вычисляются после того, как выполнено шифрование. Используемый сегодня стандарт IPSec описывает алгоритмы SHA1 и MD5 как обязательные для НМАС.
Главное различие между аутентификацией ESP и аутентификацией АН заключается в области их охвата. ESP не защищает никаких полей заголовка IP, если только не предполагается инкапсуляция ESP (туннельный режим). На рис указано, какие поля защищаются при использовании ESP НМАС.

Обратите внимание на то, что шифрование охватывает только данные полезного груза, a ESP с хэшированием ESP НМАС - заголовок ESP и данные полезного груза. Заголовок IP не защищается. Сервис ESP НМАС не может использоваться самостоя¬тельно, а должен быть объединен с протоколом шифрования ESP.

Туннельный и транспортный режимы IPSec

IPSec действует или в туннельном, или в транспортном режиме. На рис показана схема реализации туннельного режима. В этом режиме вся исходная дейтаграмма IP шифруется и становится полезным грузом в новом пакете IP с новым заголовком IP и дополнительным заголовком IPSec (на рис. заголовок обозначен аббревиатурой HDR). Туннельный режим позволяет сетевому устройству (например, брандмауэру PIX Firewall) выступать в роли шлюза IPSec или прокси-сервера, выполняющего шифрование для хостов, размещенных за брандмауэром. Маршрутизатор источника шифрует пакет и передает его по туннелю IPSec. Брандмауэр PIX Firewall адресата дешифрует полученный пакет IPSec, извлекает исходную дейтаграмму IP и передает ее системе адресата. Главное преимущество туннельного режима заключается в том, что не требуется модифицировать конечные системы, чтобы обеспечить им возможность использования IPSec. Туннельный режим также не позволяет противнику анализировать поток данных. При обмене в туннельном режиме противник имеет возможность определить только конечные точки туннеля, но не истинных источника и адресата проходящих через туннель пакетов, даже если конечные точки туннеля находятся как раз в системах источника и адресата.

Схема на рис ниже иллюстрирует транспортный режим. Здесь шифруется только полезный груз IP, а исходный заголовок IP остается нетронутым.
Добавляется заголовок IPSec. Преимуществом этого режима является добавление только нескольких байтов к каждому пакету. Кроме того, устройства открытой сети могут видеть истинные адреса отправителя и получателя пакета.

Это позволяет использовать специальные возможности промежуточных сетей (например, гарантированное качество сервиса), основанные на информации в заголовке IP. Однако заголовок уровня 4 шифруется, что ограничивает возможности анализа пакета. К сожалению, передача заголовка IP в открытом виде в транспортном режиме позволяет нарушителю в определенной мере выполнить анализ потока данных. Например, нарушитель может выяснить, сколько пакетов было передано сторонами IPSec, действующими в транспортном режиме. Но нарушитель может узнать только о том, что пакеты IP пересылались. Он не сможет определить, были ли они сообщением электронной почты или каким-то другим приложением, если использовался протокол ESP.

Использование туннельного и транспортного режимов

Рассмотрим несколько примеров, иллюстрирующих правила выбора туннельного или транспортного режима. На рис ниже показаны ситуации, в которых используется туннельный режим. Этот режим чаще всего используется для шифрования потока данных между шлюзами защиты IPSec - например, между маршрутизатором Cisco и брандмау эром PIX Firewall. Шлюзы IPSec выполняют функции IPSec для устройств, находящихся за такими шлюзами (на указанном рисунке это персональный компьютер Алисы и серверы HR). В этом примере Алиса получает защищенный доступ к серверам HR через туннель IPSec, установленный между шлюзами.

Туннельный режим используется и для связи конечных станций, в которых выполняется программное обеспечение IPSec, например для связи клиента CiscoSecure VPN и шлюза IPSec.
В данном примере туннельный режим применяется для создания туннеля IPSec между маршрутизатором Cisco и сервером, на котором выполняется программное обеспечение IPSec. Обратите внимание на то, что в программном обеспечении Cisco IOS и брандмауэра PIX Firewall туннельный режим для связей IPSec является режимом, устанавливаемым по умолчанию.
Транспортный режим используется между конечными станциями, поддерживающими IPSec, или между конечной станцией и шлюзом, если шлюз интерпретируется как хост. На рис. ниже показан пример Г, иллюстрирующий применение транспортного режима для создания шифрованного туннеля IPSec от компьютера Алисы, на котором выполняется программное обеспечение клиента Microsoft Windows 2000, к концентратору Cisco VPN 3000, что позволяет Алисе использовать L2ТР-туннель над IPSec.

Использование АН и ESP

В определенных ситуациях проблема выбора между АН и ESP может показаться сложной для решения, но ее можно упростить, если следовать нескольким правилам. Если вам необходимо знать, что данные из идентифицированного источника передают¬ся без нарушения целостности, а их конфиденциальность обеспечивать не требуется, используйте протокол АН, который защищает протоколы высших уровней и поля заголовка IP, не изменяемые в пути. Защита означает, что соответствующие значения нельзя изменить, потому что это будет обнаружено второй стороной IPSec и любая модифицированная дейтаграмма IP будет отвергнута. Протокол АН не обеспечивает защиту от прослушивания канала и просмотра нарушителем заголовка и данных. Но поскольку заголовок и данные незаметно изменить нельзя, измененные пакеты отвергаются.

Если необходимо сохранить данные в тайне (обеспечить конфиденциальность), используйте ESP. Данный протокол предполагает шифрование протоколов высших уровней в транспортном режиме и всей исходной дейтаграммы IP в туннельном режиме, так что извлечь информацию о пакетах путем прослушивания канала передачи невозможно. Протокол ESP может также обеспечить для пакетов сервис аутентификации. Однако при использовании ESP в транспортном режиме внешний оригинальный заголовок IP не защищается, а в туннельном режиме не защищается новый заголовок IP. При использовании IPSec пользователи скорее применят туннельный режим, чем транспортный.

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

В 1994 году Совет по архитектуре Интернет выпустил отчет “Безопасность архитектуры Интернет”. Данный отчет посвящался в основном проблемам защиты от несанкционированного мониторинга, подмены пакетов и управлению потоками данных. Требовалась разработка некоторого стандарта, способного решить все эти проблемы. В результате были созданы стандарты протоколов, в число которых входил IPsec.

IPsec (сокр. IP Security) – группа протоколов, предназначенных для обеспечения защиты данных, передаваемых по IP-сети. Задача IPsec сводится к тому, чтобы выбрать конкретные алгоритмы и механизмы и настроить соответствующим образом устройства, участвующие в создании безопасного соединения. IPsec находит применение в организации VPN-соединений.

При создании защищенного канала участникам данного процесса необходимо произвести следующие действия:

1. Аутентифицировать друг друга
2. Сгенерировать и обменяться ключами
3. Договориться с помощью каких протоколов шифровать данные
4. Начать передавать данные в зашифрованный туннель

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

IKE (Internet Key Exchange) – протокол обмена ключами.

IKE используется на первой стадии установления соединения. К его задачам относят: аутентификация VPN-точек, организация новых IPsec соединений (через создание SA-пар), управление текущими соединениями. SA представляет из себя набор параметров защищенного соединения. При настроенном соединении для каждого протокола создается одна SA-пара: первая для протокола AH, вторая для ESP (расскажу про них дальше). Также стоит отметить, что SA является однонаправленным. Таким образом, при связи двух компьютеров будет использоваться четыре SA. IKE работает в двух фазах, при этом первая фаза может работать как в основном, так и в агрессивном режиме. Рассмотрим две фазы IKE-соединения:

Первая фаза (основной режим):

1. Обмен параметрами безопасности IKE-соединения (алгоритмы и хэш-функции)
2. На каждом конце туннеля генерируются общий секретный ключ
3. Используя алгоритм Деффи-Хеллмана , стороны обмениваются общим секретным ключом
4. Аутентификация обеих концов туннеля

Первая фаза (агрессивный режим): в первый пакет сразу помещается вся необходимая информация для установления IKE-соединения. Получатель посылает в ответ все, что необходимо для завершения обмена, после чего первому узлу необходимо лишь подтвердить соединение.

Агрессивный режим быстрей позволяет установить IKE-соединение, но при этом он менее безопасный, потому что стороны обмениваются информацией до того как безопасное соединение установлено.

Таким образом, первая фаза служит для создания защищенного туннеля, через который будут передаваться параметры для IPSec-туннеля. Во время второй фазы строится основной IPSec-туннель.

Во время второй фазы участники защищенного соединения по очереди предлагают друг другу варианты защищенного соединения и, если приходят к согласию, строят основной IPSec-туннель. Во второй фазы происходит согласование множества параметров:

• Выбирается IPSec-протокол: AH (Authentication Header) и/или ESP (Encapsulation Security Payload)
• Выбирается алгоритм для шифрования данных: DES, 3DES, AES
• Выбирается алгоритм для аутентификации: SHA, MD5
• Выбирается режим работы: туннельный или транспортный
• Устанавливается время жизни IPSec-туннеля
• Определяется трафик, который будет пускаться через VPN-туннель

AH (Authentication Header) – протокол IPSec, предназначенный для аутентификации. По сути это обычный опциональный заголовок, располагающийся между основным заголовком IP-пакета и полем данных. Предназначение AH – обеспечение защиты от атак, связанных с несанкционированным изменением данных в IP-пакете, в частности подмены исходного адреса сетевого уровня.

ESP (Encapsulation Security Payload) – протокол IPSec, предназначенный для шифрования данных. Дословно переводится как “поле данных безопасной инкапсуляции”. Также как и AH представляет из себя опциональный заголовок, вкладываемый в IP-пакет. Основной целью ESP является обеспечение конфиденциальности данных.

Вы могли заметить, что ESP и AH имеют разные форматы в зависимости от типа используемого режима: туннельного и транспортного.

Туннельный режим применяется чаще всего для удаленных VPN-подключений. При таком режиме исходный IP-пакет полностью инкапсулируется в новый таким образом, что для наблюдателя со стороны будет видно только соединение между двумя VPN-точками. Реальные IP-адреса источника и получателя видны не будут, их можно получить только при деинкапсуляции на VPN-точке. Исходя из этого, можно считать, что туннельный режим является более защищенным.

Транспортный режим применяется, как правило, в локальной сети при защите соединения между хостами. Этот режим обеспечивает защиту данных IP-пакета (TCP, UDP, протоколы верхних уровней). Грубо говоря, транспортный режим инкапсулирует все, что находится выше сетевого уровня эталонной модели OSI, при этом не затрагивая сам IP-заголовок. Естественно в таком случае данные IP-пакета: адрес источника и получателя будут видны извне.

Теперь перейдем к практике: настроим защищенный IPSec-туннель между двумя маршрутизаторами Cisco. Схема будет состоять из трех последовательно соединенных маршрутизаторов, при этом крайние R1 и R3 представляют из себя маршрутизаторы для локальных сетей, а центральный R2 имитирует Интернет. Прежде всего необходимо настроить связность между двумя локальными подсетями. Связность обеспечивается за счет GRE-туннеля. Про GRE-туннели я писал в , также там есть конфигурация GRE-туннеля для маршрутизаторов Cisco. Чтобы понимать логику дальнейший действий настоятельно рекомендую ознакомиться с этим материалом.

Итак, основной GRE-туннель у нас “прокинут”. Он не является защищенным и поэтому поверх него мы будем настраивать IPSec. Мы работали вот с такой схемой.

По легенде у нас было два офиса с подсетями LAN1 и LAN2. Необходимо обеспечить доступ компьютера из LAN1 к серверу, находящемуся в LAN2 (например, для доступа к файлам). Так вот, основной туннель мы создали. На сетевом уровне все работает прекрасно – пинг от компа до сервера есть. Но существует одна проблема: сервер содержит файлы, которые представляет коммерческую тайну для компании. Таким образом, необходимы механизмы шифрования трафика, а также аутентификация для того, чтобы никто кроме нас не мог получить доступ к этим файлам. И вот тут в бой вступает IPSec.

Конфигурация для Router A

Создаем политику безопасности и настраиваем ее RouterA(config)#crypto isakmp policy 1 Указываем метод шифрования (симметричный блочный шифр) RouterA(config)#encryption 3des Указываем метод хеширования MD5 RouterA(config)#hash md5 Указываем метод аутентификации (с предварительным ключом) RouterA(config)#authentication pre-share Выходим из режима редактирования политики безопасности RouterA(config)#exit Ключ для аутентификации (должен совпадать для обеих точек) RouterA(config)#crypto isakmp key PASS address 33.33.33.33 Применение набора преобразований RouterA(config)#crypto ipsec transform-set LAN1 esp-3des esp-md5-hmac Указываем режим работы IPSec (туннельный режим) RouterA(cfg-crypto-trans)#mode tunnel RouterA(cfg-crypto-trans)#exit Создаем крипто-карту (детали туннелирования) RouterA(config)#crypto map MAP1 10 ipsec-isakmp Указываем Ip-адрес маршрутизатора, с которым устанавливаем VPN RouterA(config-crypto-map)#set peer 33.33.33.33 Указываем набор политик безопасности RouterA(config-crypto-map)#set transform-set LAN1 Шифровать данные, которые будут проходить через список доступа под номером 100 RouterA(config-crypto-map)#match address 100 Выходим из режима настройки крипто-карты RouterA(config-crypto-map)#exit GRE-трафик с хоста 11.11.11.11 на хост 33.33.33.33 подлежит шифрованию RouterA(config)#access-list 100 permit gre host 11.11.11.11 host 33.33.33.33 Переходим в режим настройки внешнего интерфейса RouterA(config)#interface fa 0/1 Привязка карты шифрования MAP1 к внешнему интерфейсу RouterA(config-if)#crypto map MAP1

Аналогично настраивается Router B:

RouterB(config)#crypto isakmp policy 1 RouterB(config)#encryption 3des RouterB(config)#hash md5 RouterB(config)#authentication pre-share RouterB(config)#exit RouterB(config)#crypto isakmp key PASS address 11.11.11.11 RouterB(config)#crypto ipsec transform-set LAN2 esp-3des esp-md5-hmac RouterB(cfg-crypto-trans)#mode tunnel RouterB(cfg-crypto-trans)#exit RouterB(config)#crypto map MAP2 10 ipsec-isakmp RouterB(config-crypto-map)#set peer 11.11.11.11 RouterB(config-crypto-map)#set transform-set LAN2 RouterB(config-crypto-map)#match address 100 RouterB(config-crypto-map)#exit RouterB(config)#access-list 100 permit gre host 33.33.33.33 host 11.11.11.11 RouterB(config)#interface fa 0/1 RouterB(config-if)#crypto map MAP2

Подписывайтесь на нашу

pre-shared key : Два даемона racoon подключаются друг к другу, подтверждают, что они именно те, за кого себя выдают (используя секретный ключ, заданный вами, по умолчанию в файле /etc/racoon/psk.txt). Затем даемоны генерируют новый секретный ключ и используют его для шифрования трафика через VPN. Они периодически изменяют этот ключ, так что даже если атакующий сломает один из ключей (что теоретически почти невозможно) это не даст ему слишком много – он сломал ключ, который два даемона уже сменили на другой. Предварительный ключ(pre-shared key) не используется для шифрования трафика через VPN соединение это просто маркер, позволяющий управляющим ключами даемонам доверять друг другу. Права на файл psk.txt должны быть 0600 (т.е. запись и чтение только для root).

IPsec состоит из двух протоколов:

Encapsulated Security Payload (ESP), защищающей данные IP пакета от вмешательства третьей стороны путем шифрования содержимого с помощью симметричных криптографических алгоритмов (таких как Blowfish,3DES, AES).

Authentication Header (AH), защищающий заголовок IP пакета от вмешательства третьей стороны и подделки путем вычисления криптографической контрольной суммы и хеширования полей заголовка IP пакета защищенной функцией хеширования. К пакету добавляется дополнительный заголовок с хэшем, позволяющий аутентификацию информации пакета.

ESP и AH могут быть использованы вместе или по отдельности, в зависимости от обстоятельств.

esp и ah - пакеты ipsec, формируются ядром после того как хосты, при помощи racoon, договорятся о ключе по протоколу isakmp (500/udp).

Режимы работы IPsec(транспортный, туннельный)

Существует два режима работы IPsec: транспортный режим и туннельный режим(когда в транспортном режиме работают только маршрутизаторы).

IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения "виртуальных туннелей" между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Туннельный режим обычно называют виртуальной частной сетью (Virtual Private Network, vpn).

В транспортном режиме шифруется (или подписывается) только информативная часть IP-пакета. Маршрутизация не затрагивается, так как заголовок IP пакета не изменяется (не шифруется). Транспортный режим как правило используется для установления соединения между хостами. Он может также использоваться между шлюзами, для защиты туннелей, организованных каким-нибудь другим способом (IP tunnel, GRE туннели и др.).

В туннельном режиме IP-пакет шифруется целиком. Для того, чтобы его можно было передать по сети, он помещается в другой IP-пакет. По существу, это защищённый IP-туннель. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей виртуальной частной сети. В туннельном режиме инкапсулируется весь исходный IP пакет, и добавляется новый IP заголовок.

Если используется IPsec совместно с GRE туннели , который инкапсулирует исходный пакет и добавляет новый IP заголовок, логично использовать транспортный режим.

Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые SA могут использовать транспортный режим, а другие - туннельный.

Security Associations (SA) . Для возможности проводить инкапсуляцию/декапсуляцию стороны участвующие в процессе обмена должны иметь возможность хранить секретные ключи, алгоритмы и IP адреса. Вся эта информация хранится в Ассоциациях Безопасности (SA), SA в свою очередь хранятся в Базе данных Ассоциаций Безопасности (SAD). Конфигурирование Security Association , позволяет задать например mode transport | tunnel | ro | in_trigger | beet - режим безопасной ассоциации. Соответственно, может принимать одно из значений, означающих транспортный, тоннельный, beet (Bound End-to-End Tunnel), оптимизации маршрута (route optimization) или in_trigger режимы. (последние два используются в контексте mobile ipv6).

Security Policy (SP) - политика безопасности, хранится в SPD (База данных политик безопасности). SA специфицирует, как IPsec предполагает защищать трафик, SPD в свою очередь хранит дополнительную информацию, необходимую для определения какой именно трафик защищать и когда. SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA. SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.

IPSec (сеть-сеть) между серверами FreeBSD

Шаг 1 : Создание и тестирование "виртуального" сетевого подключения.

• Настройте оба ядра с device gif . В версии FreeBSD поддержка gif включена в ядро.

  Отредактируйте /etc/rc.conf на маршрутизаторах и добавьте следующие строки (подставляя IP адреса где необходимо). A.B.C.D - реальный IP первого маршрутизатора, W.X.Y.Z - реальный IP второго маршрутизатора. # IPsec №1 gateway > ee /etc/rc.conf ... # IPsec to S through ISP_V gif_interfaces="gif0" # gifconfig_gif0="local-ip(A.B.C.D) remote-ip (W.X.Y.Z)" gifconfig_gif0="194.x.x.x 91.x.x.x" ifconfig_gif0="inet 10.26.95.254 192.168.1.254 netmask 255.255.255.255" static_routes="vpn vpn1" route_vpn="-net 192.168.1.0/24 192.168.1.254" route_vpn1="-net 192.168.35.0/24 192.168.1.254" # IPsec №2 gateway > ee /etc/rc.conf ... # IPsec na G through ISPGate gif_interfaces="gif0" # gifconfig_gif0="W.X.Y.Z A.B.C.D" gifconfig_gif0="91.x.x.x 194.x.x.x" ifconfig_gif0="inet 192.168.1.254 10.26.95.254 netmask 255.255.255.255" static_routes="vpn" route_vpn="-net 10.26.95.0/24 10.26.95.254"

  Отредактируйте скрипт брандмауэра на обеих маршрутизаторах и добавьте # IPFW ipfw add 1 allow ip from any to any via gif0 # PF set skip on gif0

Теперь ping должны ходить между сетями.

Защита соединения с помощью IPsec

Шаг 2 : Защита соединения с помощью IPsec

• Настройте оба ядра: > sysctl -a | grep ipsec

  если команда ничего не вывела, значит нужно пересобрать ядра на обоих маршрутизаторах с параметрами

  # IPSEC for FreeBSD 7.0 and above options IPSEC options IPSEC_FILTERTUNNEL device crypto # IPSEC for FreeBSD 6.3 options IPSEC # IP security options IPSEC_ESP # IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG # Необязательно. debug for IP security

  Устанавливаем порт ipsec-tools. > cd /usr/ports/security/ipsec-tools > make config > make install clean > ee /etc/rc.conf racoon_enable="YES" ipsec_enable="YES" > mkdir -p /usr/local/etc/racoon/cert > cp /usr/local/share/examples/ipsec-tools/racoon.conf /usr/local/etc/racoon/racoon.conf > cd /usr/local/etc/racoon/cert/

  Создаем SSL сертификаты на каждом хосте. Копируем с одной на другую файлики *.public. В принципе, имена ключей неважны, можно называть и по IP, с соответствующими расширениями.

  > openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout your.key1.private -outform PEM -out your.key1.pem > openssl x509 -req -in your.key1.pem -signkey your.key.private -out your.key1.public

Создаем файл ipsec.conf. Настройка на шлюзе #1 (где есть публичный IP адрес A.B.C.D) для включения шифрования всего предназначенного W.X.Y.Z трафика. A.B.C.D/32 и W.X.Y.Z/32 это IP адреса и сетевые маски, определяющие сети или хосты, к которым будет применяться данная политика. В данном случае мы хотим применить их к трафику между этими двумя хостами. Параметр ipencap сообщает ядру, что эта политика должна применяться только к пакетам, инкапсулирующим другие пакеты. Параметр -P out сообщает, что эта политика применяется к исходящим пакетам, и ipsec – то, что пакеты будут зашифрованы.

Оставшаяся часть строки определяет, как эти пакеты будут зашифрованы. Будет использоваться протокол esp, а параметр tunnel показывает, что пакет в дальнейшем будет инкапсулирован в IPsec пакет. Повторное использование A.B.C.D и W.X.Y.Z предназначено для выбора используемых параметров безопасности, и наконец параметр require разрешает шифрование пакетов, попадающих под это правило.

Это правило соответствует только исходящим пакетам. Вам потребуется похожее правило, соответствующее входящим пакетам.

> ee /etc/ipsec.conf spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

Настройка на шлюзе #2 аналогична только меняются IP местами.

Настройка утилиты racoon

> ee /usr/local/etc/racoon/racoon.conf path include "/usr/local/etc/racoon"; path certificate "/usr/local/etc/racoon/cert/"; # following line activates logging & should deactivated later log debug; # если директива listen не задана, racoon слушает все доступные # адреса интерфейсов. listen { #isakmp::1 ; isakmp 202.249.11.124 ; #admin ; # administrative port for racoonctl. #strict_address; # requires that all addresses must be bound. } # описываем удалённый хост (на второй машине - идентично, # тока другой IP и ключи) remote 217.15.62.200 { exchange_mode aggressive,main; my_identifier asn1dn; peers_identifier asn1dn; # сертификаты этой машины certificate_type x509 "via.epia.public" "via.epia.private"; # сертификат удлённой машины peers_certfile x509 "test.su.public"; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2 ; } } sainfo anonymous { pfs_group 2; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; }

Настройка пакетного фильтра PF, где esp_peers шлюз с которым создается шифрованный туннель. Разрешаем прохождение пакетов ESP и IPENCAP в обе стороны.

#pass IPSec pass in on $ext_if_a inet proto udp from { $esp_peers } to ($ext_if_a) port isakmp pass in on $ext_if_a inet proto esp from { $esp_peers } to ($ext_if_a) # pass out on $ext_if_a inet proto udp from { $esp_peers } to ($ext_if_a) port isakmp pass out on $ext_if_a inet proto esp from { $esp_peers } to ($ext_if_a)

Cмотрим логи /var/log/security и /var/log/messages.

Как только параметры безопасности установлены, вы можете просмотреть их используя setkey(8). Запустите

> /etc/rc.d/ipsec start > /usr/local/etc/rc.d/racoon start > setkey -D # список созданных защищенных каналов > setkey -DP # покажет список политик безопасности

на любом из хостов для просмотра информации о параметрах безопасности.

Проверка работоспособности:

ping между сетями должен работать

Запускаем для прослушки физического интерфейса на котором построен туннель (а не виртуального gif0). В другом окне например ping -ем удаленную серую сеть (например, ping 192.168.1.11) tcpdump -i em0 -n host 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x >

tcpdump Linux примеры использования должен показывать ESP пакеты.

IPSec (сеть-сеть) между серверами Linux

# aptitude install ipsec-tools racoon

Алгоритм настройки IPsec

Настройка пакета racoon

Создание политики безопасности

Виртуальные интерфейсы. Они нужны для маршрутизации сетей находящихся в локальных сетях. Два соединенных сервера будут видеть себя без интерфейсов(иногда без них не заводится и между серверами, странно вообще-то).

Ниже приведены конфиги для случая с предопределёнными ключами.

> nano /etc/racoon/racoon.conf path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; #path certificate "/etc/racoon/certs"; remote 10.5.21.23 { exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address; #Определяет метод идентификации, который будет использоваться при проверке подлинности узлов. lifetime time 2 min; initial_contact on; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; # Определяет метод проверки подлинности, используемый при согласовании узлов. dh_group 2; } proposal_check strict; } sainfo anonymous # Отмечает, что SA может автоматически инициализировать соединение с любым партнёром при совпадении учётных сведений IPsec. { pfs_group 2; lifetime time 2 min ; encryption_algorithm 3des, blowfish 448, des, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; }

Создадим политику безопасности

> nano pol.cfg #!/sbin/setkey -f flush; spdflush; spdadd 10.5.21.24 10.5.21.23 any -P out ipsec esp/transport//require; spdadd 10.5.21.23 10.5.21.24 any -P in ipsec esp/transport//require; > chmod +x pol.cfg > ./pol.cfg

Создадим выполняемый файл для создания интерфейсов и запустим его.

>nano tun.sh #!/bin/sh ip tunnel del tun0 ip tunnel add tun0 mode ipip remote 10.5.21.23 local 10.5.21.24 dev eth0 # создаем интерфейс tun0 и устанавливаем туннель # между хостами (здесь нужно использовать реальные IP адреса сетевых интерфейсов). ifconfig tun0 10.0.9.1 pointopoint 10.0.9.2 # назначаем интерфейсу IP адреса, для текущего хоста и для другого конца # туннеля (не обязательно). ifconfig tun0 mtu 1472 ifconfig tun0 up # ниже можно прописать нужные нам маршруты, например так route add -net ... netmask 255.255.255.0 gw ... route add -net ... netmask 255.255.255.0 gw ... > ./tun.sh

Для автоматической загрузки правил файл tun.sh правильно поместить для Debian в директорию /etc/network/if-up.d

Все IPSec тунель между сетями настроен.

iptables IPSec

$IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 500 -j ACCEPT $IPT -A INPUT -p esp -j ACCEPT $IPT -A INPUT -p ah -j ACCEPT $IPT -A INPUT -p ipencap -j ACCEPT $IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 4500 -j ACCEPT

IPsec «узел-узел» без виртуальных интерфесов

Задача . При помощи IPSec (pre_shared_key) соединить два сервера (Debian 5 и Debian 7). У обоих реальные IP. Никаких сетей пробрасывать не надо. Должен шифроваться трафик между этими IP. То есть строим транспортный режим (между двумя хостами).

Настройка сводится к двум пунктам

Настройка пакета racoon

Создание политики безопасности: нужно указать режим transport и any spdadd x.x.x.x/32 y.y.y.y/32 any -P out ipsec esp/transport//require; spdadd y.y.y.y/32 x.x.x.x/32 any -P in ipsec esp/transport//require;

IPSec (GRE) (узел-сеть) между Debian и Cisco

Задача: построить IPsec в туннельном режиме. Описание RFC протокола SIP сигнализация между поставщиком (Cisco) и клиентом (Debian 5) шифруется IPsec, а RTP минуя туннель идет кратчайшим маршрутом через обычный Интернет.

Клиент tunnel-endpoint is: 193.xxx.xxx.xxx

Сервер tunnel-endpoint is: 62.xxx.xxx.xxx

Клиент Sip Server is: 193.xxx.xxx.xxx

Сервер SIP Servers are: 62.xxx.237.xxx/26 and 62.xxx.246.xxx/26

да и перед настрокой туннеля (перед auto tun0) прописать pre-up modprobe ip_gre

# modprobe ip_gre

Скрипт для создания GRE туннели туннеля в Debian:

#!/bin/sh -e modprobe ip_gre #ip tunnel del tun0 ip tunnel add tun0 mode gre remote 62.xxx.xxx.xxx local 193.xxx.xxx.xxx dev eth0 ifconfig tun0 mtu 1472 ifconfig tun0 up route add -net 62.xxx.237.xxx netmask 255.255.255.192 dev tun0 route add -net 62.xxx.246.xxx netmask 255.255.255.192 dev tun0

Утилиты

Для управления можно использовать утилиту racoonctl racoonctl show-sa esp

Cписок созданных защищенных каналов > setkey -D

список политик безопасности > setkey -DP

Мониторинг IPsec

Мониторинг IPsec в Debian 5.0 2.6.26-2-686-bigmem i686. В уровень детализации логов log notify или log debug устанавливается в файле racoon.conf.

# tail -F /var/log/syslog | grep racoon

IPSec Openswan

OpenSWAN начал разрабатываться как форк прекратившего в настоящее своё существование проекта FreeS/WAN (Free Secure Wide-Area Networking), релизы продолжают выпускаться под свободной GNU General Public License. В отличие от проекта FreeS/WAN, OpenSWAN разрабатывается не только специально под операционную систему GNU/Linux. OpenSWAN обеспечивает стек протоколов IpSec: AH и ESP для ядра Linux,а также инструментарий для управления ими.

OpenSWAN для ветки ядра 2.6 предоставляет встроенную, NETKEY реализацию IpSec, так и собственную KLIPS.

CentOS 6.6 поддерживает только Openswan в основных пакетах.

Задача . Создать шифрованный туннель между CentOS 6.6 и Debian 7.8 Wheezy. GRE туннели + Openswan (type=transport)

Openswan будет шифровать наш трафик в транспортном режиме(host-to-host), не вмешиваясь в маршрутизацию. Установим пакеты на обоих серверах yum install openswan aptitude install openswan

На обоих концах туннеля настраиваем Правила iptables . Открыть 500 порт, по которому идет обмен сертификатам и ключами. iptables -A INPUT -p udp --dport 500 -j ACCEPT iptables -A INPUT -p tcp --dport 4500 -j ACCEPT iptables -A INPUT -p udp --dport 4500 -j ACCEPT # Более строго выпишем правила для IPSec IPT ="/sbin/iptables" $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 500 -m comment --comment "IpSec" -j ACCEPT $IPT -A INPUT -p tcp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 4500 -m comment --comment "IpSec" -j ACCEPT

Подготовка конфигурационных файлов. Используемые файлы и директории / etc/ ipsec.d/ / etc/ ipsec.conf

Проверка системы на правильность окружения для IPsec ipsec verify

Добавить в конец файла sysctl.conf

# IPSec Verify Compliant # Разрешить пересылку пакетов между интерфейсами для IPv4 net.ipv4.ip_forward = 1 # отключаем icmp redirect net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0

Применим параметры ядра без перезагрузки

Первым конфигурационным файлом является /etc/ipsec.conf. Задаем явно в разделе config setup config setup protostack =netkey plutoopts ="--perpeerlog" dumpdir =/ var/ run/ pluto/ nat_traversal =yes virtual_private =% v4:10.0.0.0/ 8 ,% v4:192.168.0.0/ 16 , % v4:172.16.0.0/ 12 ,% v4:25.0.0.0/ 8 ,% v6:fd00::/ 8 ,% v6:fe80::/ 10 oe =off #plutostderrlog=/dev/null

В первую очередь вам необходимо сформировать ключи, используемые шлюзами для аутентификации. В Debian это ключ можно создать при инсталляции. Запускаем на обеих системах ipsec newhostkey, генерируя нужные нам ключи. ipsec newhostkey --output / etc/ ipsec.secrets ipsec showhostkey --left ipsec showhostkey --right

Независимо от того, как вы сконфигурируете сервер, всегда рассматривайте вашу подсеть как расположенную «слева» (left), а подсеть, к которой доступ осуществляется дистанционно, сайт, как расположенный «справа» (right). Следующая конфигурация выполняется на сервере VPN на стороне Left. На другом сервере должен быть точно такие настройки для этого соединения. conn gagahost-to-miraxhost auto =start left =188 .x.x.x leftrsasigkey =0sN4vI6ooUyMyL ... right =91 .x.x.x rightrsasigkey =0sfAhuo4SQ0Qt ... type =transport scp / etc/ ipsec.conf admin@ 192.168.35.254:/ home/ admin/

Диагностика IPSec Openswan

Запуск сервиса и поиск возникающих проблем.

Openwan logs (pluto) : /var/log/auth.log /var/log/syslog /var/log/pluto/peer/a/b/c/d/a.b.c.d.log

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

Кроме того, в таблице маршрутизации сервера должны появиться маршруты к частной подсети.

# ip route via dev eth0 src default via dev eth0

Команды проверки состояний соединений: ipsec verify service ipsec status ip xfrm state list - управления SAD, возможности шире, чем у setkey ipsec addconn --checkconfig - проверка конфигурации ipsec auto --status - подробное состояние ip xfrm monitor

Политики ipsec, согласно которым принимается решение какой трафик направлять в туннель ip xfrm pol show

tcpdump Linux примеры использования запускаем для прослушки физического интерфейса на котором построен туннель (а не виртуального GRE). В другом окне например ping -ем удаленную серую сеть (например, ping 192.168.1.11). tcpdump должен показывать ESP пакеты. tcpdump -i em0 -n host 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x > 91 .x.x.81: ESP(spi =0x01540fdd,seq =0xa20) , length 92 ...

0 В этой статье предлагается обзор средств IPSEC (IP Security - система защиты на уровне IP) и соответствующих протоколов IPSec, доступных в продуктах Cisco и используемых для создания виртуальных частных сетей (VPN). В данной статье мы определим, что такое IPSEC, а также какие протоколы и алгоритмы защиты лежат в основе IPSEC.

Введение

IP Security - это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC.

Продукты Cisco для поддержки VPN используют набор протоколов IPSec, являющийся на сегодня промышленным стандартом обеспечения широких возможностей VPN. IPSec предлагает механизм защищенной передачи данных в IP-сетях, обеспечивая конфиденци¬альность, целостность и достоверность данных, передаваемых через незащищенные сети типа Internet. IPSec обеспечивает следующие возможности VPN в сетях Cisco:

• Конфиденциальность данных . Отправитель данных IPSec имеет возможность шифровать пакеты перед тем, как передавать их по сети.
• Целостность данных . Получатель данных IPSec имеет возможность аутентифицировать сообщающиеся с ним стороны (устройства или программное обеспе¬чение, в которых начинаются и заканчиваются туннели IPSec) и пакеты IPSec, посылаемые этими сторонами, чтобы быть уверенным в том, что данные не были изменены в пути.
• Аутентификация источника данных . Получатель данных IPSec имеет возмож¬ность аутентифицировать источник получаемых пакетов IPSec. Этот сервис за¬висит от сервиса целостности данных.
• Защита от воспроизведения . Получатель данных IPSec может обнаруживать и от¬вергать воспроизведенные пакеты, не допуская их фальсификации и проведе¬ния атак внедрения посредника.

IPSec представляет собой основанный на стандартах набор протоколов и алгоритмов защиты. Технология IPSec и связанные с ней протоколы защиты соответствуют открытым стандартам, которые поддерживаются группой IETF (Internet Engineering Task Force - проблемная группа проектирования Internet) и описаны в спецификациях RFC и проектах IETF. IPSec действует на сетевом уровне, обеспечивая защиту и аутентификацию пакетов IP, пересылаемых между устройствами (сторонами) IPSec - такими как маршрутизаторы Cisco, брандмауэры PIX Firewall, клиенты и концентраторы Cisco VPN, а также многие другие продукты, поддерживающие IPSec. Средства поддержки IPSec допускают масштабирование от самых малых до очень больших сетей.

Ассоциации защиты (Security Association ,SA)

IPSec предлагает стандартный способ аутентификации и шифрования соединений между сообщающимися сторонами. Чтобы обеспечить защиту связей, средства IPSec используют стандартные алгоритмы (т.е. математические формулы) шифрования и аутентификации, называемые преобразованиями. В IPSec используются открытые стандарты согласования ключей шифрования и управления соединениями, что обеспечивает возможность взаимодействия между сторонами. Технология IPSec предлагает методы, позволяющие сторонам IPSec "договориться" о согласованном использовании сервисов. Чтобы указать согласуемые параметры, в IPSec используются ассоциации защиты.

Ассоциация защиты (Security Association - SA) представляет собой согласованную политику или способ обработки данных, обмен которыми предполагается между двумя устройствами сообщающихся сторон. Одной из составляющих такой политики может быть алгоритм, используемый для шифрования данных. Обе стороны могут ис¬пользовать один и тот же алгоритм как для шифрования, так и для дешифрования. Действующие параметры SA сохраняются в базе данных ассоциаций защиты (Security Association Database - SAD) обеих сторон.

Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.

Протокол IKE (Internet Key Exchange - обмен Internet-ключами) является гибридным протоколом, обеспечивающим специальный сервис для IPSec, а именно аутентификацию сторон IPSec, согласование параметров ассоциаций защиты IKE и IPSec, а также выбор ключей для алгоритмов шифрования, используемых в рамках IPSec. Протокол IKE опира¬ется на протоколы ISAKMP (Internet Security Association and Key Management Protocol - протокол управления ассоциациями и ключами защиты в сети Internet) и Oakley, которые применяются для управления процессом создания и обработки ключей шифрования, используемых в преобразованиях IPSec. Протокол IKE применяется также для формирования ассоциаций защиты между потенциальными сторонами IPSec.
Как IKE, так и IPSec используют ассоциации зашиты, чтобы указать параметры связи.
IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).

Хэш-функция – это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что

H(m1)=H(m2), где H – хэш функция.

Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC - механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим её как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования - как L (L
ipad = байт 0x36, повторённый B раз;
opad = байт 0x5C, повторённый B раз.

Для вычисления HMAC от данных "text" необходимо выполнить следующую операцию:

H(K XOR opad, H(K XOR ipad, text))

Из описания следует, что IKE использует для аутентификации сторон HASH величины. Отметим, что под HASH в данном случае подразумевается исключительно название Payload в ISAKMP, и это название не имеет ничего общего со своим содержимым

Инфраструктура IPSec

Сети VPN на основе IPSec могут быть построены с помощью самых разных устройств Cisco - маршрутизаторов Cisco, брандмауэров CiscoSecure PIX Firewall, программного обеспечения клиента CiscoSecure VPN и концентраторов Cisco VPN серий 3000 и 5000. Маршрутизаторы Cisco имеют встроенную поддержку VPN с соответствующими богатыми возможностями программного обеспечения Cisco IOS, что уменьшает сложность сетевых решений и снижает общую стоимость VPN при возможности построения многоуровневой защиты предоставляемых сервисов. Брандмауэр PIX Firewall является высокопроизводительным сетевым устройством, которое может обслуживать конечные точки туннелей, обеспечивая им высокую пропускную способность и прекрасные функциональные возможности брандмауэра. Программное обеспечение клиента CiscoSecure VPN поддерживает самые строгие требования VPN удаленного доступа для операций электронной коммерции, а также приложений мо¬бильного доступа, предлагая законченную реализацию стандартов IPSec и обеспечивая надежное взаимодействие маршрутизаторов Cisco и брандмауэров PIX Firewall.

Как работает IPSec

IPSec опирается на ряд технологических решений и методов шифрования, но действие IPSec в общем можно представить в виде следующих главных шагов:

• Шаг 1. Начало процесса IPSec. Трафик, которому требуется шифрование в соответствии с политикой защиты IPSec, согласованной сторонами IPSec, начинает IКЕ-процесс.
• Шаг 2. Первая фаза IKE . IKE-процесс выполняет аутентификацию сторон IPSec и ведет переговоры о параметрах ассоциаций защиты IKE, в результате чего создается защищенный канал для ведения переговоров о параметрах ассоциаций защиты IPSec в ходе второй фазы IKE.
• Шаг 3. Вторая фаза IKE . IKE-процесс ведет переговоры о параметрах ассоциации защиты IPSec и устанавливает соответствующие ассоциации защиты IPSec для устройств сообщающихся сторон.
• Шаг 4. Передача данных . Происходит обмен данными между сообщающимися сторонами IPSec, который основывается на параметрах IPSec и ключах, хранимых в базе данных ассоциаций защиты.
• Шаг 5. Завершение работы туннеля IPSec . Ассоциации защиты IPSec завершают свою работу либо в результате их удаления, либо по причине превышения предельного времени их существования.

В следующих разделах указанные шаги будут описаны подробнее.

В современном мире различные VPN-технологии используются повсеместно. Некоторые (например, PPTP) со временем признаются небезопасными и постепенно отмирают, другие (OpenVPN), наоборот, с каждым годом наращивают обороты. Но бессменным лидером и самой узнаваемой технологией для создания и поддержания защищенных частных каналов по-прежнему остается IPsec VPN. Иногда при пентесте можно обнаружить серьезно защищенную сеть с торчащим наружу лишь пятисотым UDP-портом. Все остальное может быть закрыто, пропатчено и надежно фильтроваться.

В такой ситуации может возникнуть мысль, что здесь и делать-то особо нечего. Но это не всегда так. Кроме того, широко распространена мысль, что IPsec даже в дефолтных конфигурациях неприступен и обеспечивает должный уровень безопасности. Именно такую ситуацию сегодня и посмотрим на деле. Но вначале, для того чтобы максимально эффективно бороться c IPsec, нужно разобраться, что он собой представляет и как работает. Этим и займемся!

IPsec изнутри

Перед тем как переходить непосредственно к самому IPsec, неплохо бы вспомнить, какие вообще бывают типы VPN. Классификаций VPN великое множество, но мы не будем глубоко погружаться в сетевые технологии и возьмем самую простую. Поэтому будем делить VPN на два основных типа - site-to-site VPN-подключения (их еще можно назвать постоянные) и remote access VPN (RA, они же временные).

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

Нас будет интересовать именно второй вариант, так как в случае успешной атаки удается сразу же получить доступ к внутренней сети предприятия, что для пентестера достаточно серьезное достижение. IPsec, в свою очередь, позволяет реализовывать как site-to-site, так и remote access VPN. Что же это за технология и из каких компонентов она состоит?

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

Именно по этой причине IPsec и состоит из стека протоколов, обязанность которых лежит в том, чтобы обеспечить установление защищенного соединения, его работу и управление им. Весь процесс установления соединения включает две фазы: первая фаза применяется для того, чтобы обеспечить безопасный обмен ISAKMP-сообщений уже во второй фазе. ISAKMP (Internet Security Association and Key Management Protocol) - это протокол, который служит для согласования и обновления политик безопасности (SA) между участниками VPN-соединения. В этих политиках как раз и указано, с помощью какого протокола шифровать (AES или 3DES) и с помощью чего аутентифицировать (SHA или MD5).

Две основные фазы IPsec

Итак, мы выяснили, что вначале участникам нужно договориться, с помощью каких механизмов будет создано защищенное соединение, поэтому теперь в дело вступает протокол IKE. IKE (Internet Key Exchange) используется для формирования IPsec SA (Security Association, те самые политики безопасности), проще говоря - согласования работы участников защищенного соединения. Через этот протокол участники договариваются, какой алгоритм шифрования будет применен, по какому алгоритму будет производиться проверка целостности и как аутентифицировать друг друга. Нужно заметить, что на сегодняшний день существует две версии протокола: IKEv1 и IKEv2. Нас будет интересовать только IKEv1: несмотря на то что IETF (The Internet Engineering Task Force) впервые представили его в 1998 году, он по-прежнему еще очень часто используется, особенно для RA VPN (см. рис. 1).

Рис. 1. Cisco ASDM VPN Wizard

Что касается IKEv2, первые его наброски были сделаны в 2005 году, полностью описан он был в RFC 5996 (2010 год), и лишь в конце прошлого года он был объявлен на роль стандарта Интернет (RFC 7296). Более подробно про различия между IKEv1 и IKEv2 можно прочитать во врезке. Разобравшись с IKE, возвращаемся к фазам IPsec. В процессе первой фазы участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения, предназначенного только для обмена информацией о желаемых алгоритмах шифрования и прочих деталях будущего IPsec-туннеля. Параметры этого первого туннеля (который еще называется ISAKMP-туннель) определяются политикой ISAKMP. Первым делом согласуются хеши и алгоритмы шифрования, далее идет обмен ключами Диффи-Хеллмана (DH), и лишь затем происходит выяснение, кто есть кто. То есть в последнюю очередь идет процесс аутентификации, либо по PSK-, либо по RSA-ключу. И если стороны пришли к соглашению, то устанавливается ISAKMP-туннель, по которому уже проходит вторая фаза IKE.

На второй фазе уже доверяющие друг другу участники договариваются о том, как строить основной туннель для передачи непосредственно данных. Они предлагают друг другу варианты, указанные в параметре transform-set, и, если приходят к согласию, поднимают основной туннель. Важно подчеркнуть, что после его установления вспомогательный ISAKMP-туннель никуда не девается - он используется для периодического обновления SA основного туннеля. В итоге IPsec в некоем роде устанавливает не один, а целых два туннеля.

Как обрабатывать данные

Теперь пару слов про transform-set. Нужно ведь как-то шифровать данные, идущие через туннель. Поэтому в типовой конфигурации transform-set представляет собой набор параметров, в которых явно указано, как нужно обрабатывать пакет. Соответственно, существует два варианта такой обработки данных - это протоколы ESP и AH. ESP (Encapsulating Security Payload) занимается непосредственно шифрованием данных, а также может обеспечивать проверку целостности данных. AH (Authentication Header), в свою очередь, отвечает лишь за аутентификацию источника и проверку целостности данных.

Например, команда `crypto ipsec transform-set SET10 esp-aes` укажет роутеру, что transform-set с именем `SET10` должен работать только по протоколу ESP и c шифрованием по алгоритму AES. Забегая вперед, скажу, что здесь и далее мы будем использовать в качестве цели маршрутизаторы и файрволы компании Cisco. Собственно с ESP все более-менее понятно, его дело - шифровать и этим обеспечивать конфиденциальность, но зачем тогда нужен AH? AH обеспечивает аутентификацию данных, то есть подтверждает, что эти данные пришли именно от того, с кем мы установили связь, и не были изменены по дороге. Он обеспечивает то, что еще иногда называется anti-replay защитой. В современных сетях AH практически не используется, везде можно встретить только ESP.

Параметры (они же SA), выбираемые для шифрования информации в IPsec-туннеле, имеют время жизни, по истечении которого должны быть заменены. По умолчанию параметр lifetime IPsec SA составляет 86 400 с, или 24 ч.

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

Режимы IKEv1

Мы рассмотрели в первом приближении основную механику работы IPsec, но необходимо заострить внимание еще на нескольких вещах. Первая фаза, помимо всего прочего, может работать в двух режимах: main mode или aggressive mode. Первый вариант мы уже рассмотрели выше, но нас интересует как раз aggressive mode. В этом режиме используется три сообщения (вместо шести в main-режиме). При этом тот, кто инициирует соединение, отдает все свои данные разом - что он хочет и что умеет, а также свою часть обмена DH. Затем ответная сторона сразу завершает свою часть генерации DH. В итоге в этом режиме, по сути, всего два этапа. То есть первые два этапа из main mode (согласование хешей и обмен DH) как бы спрессовываются в один. В результате этот режим значительно опаснее по той причине, что в ответ приходит много технической информации в plaintext’е. И самое главное - VPN-шлюз может прислать хеш пароля, который используется для аутентификации на первой фазе (этот пароль еще часто называется pre-shared key или PSK).

Ну а все последующее шифрование происходит без изменений, как обычно. Почему же тогда этот режим по-прежнему используется? Дело в том, что он намного быстрее, примерно в два раза. Отдельный интерес для пентестера представляет тот факт, что aggressive-режим очень часто используется в RA IPsec VPN. Еще одна небольшая особенность RA IPsec VPN при использовании агрессивного режима: когда клиент обращается к серверу, он шлет ему идентификатор (имя группы). Tunnel group name (см. рис. 2) - это имя записи, которая содержит в себе набор политик для данного IPsec-подключения. Это уже одна из фич, специфичных оборудованию Cisco.

Рис. 2. Tunnel group name

Двух фаз оказалось недостаточно

Казалось бы, что получается и так не слишком простая схема работы, но на деле все еще чуть сложнее. Со временем стало ясно, что только одного PSK недостаточно для обеспечения безопасности. Например, в случае компрометации рабочей станции сотрудника атакующий смог бы сразу получить доступ ко всей внутренней сети предприятия. Поэтому была разработана фаза 1.5 прямо между первой и второй классическими фазами. К слову, эта фаза обычно не используется в стандартном site-to-site VPN-соединении, а применяется при организации удаленных VPN-подключений (наш случай). Эта фаза содержит в себе два новых расширения - Extended Authentication (XAUTH) и Mode-Configuration (MODECFG).

XAUTH - это дополнительная аутентификация пользователей в пределах IKE-протокола. Эту аутентификацию еще иногда называют вторым фактором IPsec. Ну а MODECFG служит для передачи дополнительной информации клиенту, это может быть IP-адрес, маска, DNS-сервер и прочее. Видно, что эта фаза просто дополняет ранее рассмотренные, но полезность ее несомненна.

IKEv2 vs IKEv1

Оба протокола работают по UDP-порту с номером 500, но между собой несовместимы, не допускается ситуация, чтобы на одном конце туннеля был IKEv1, а на другом - IKEv2. Вот основные отличия второй версии от первой:

В IKEv2 больше нет таких понятий, как aggressive- или main-режимы.
- В IKEv2 термин первая фаза заменен на IKE_SA_INIT (обмен двумя сообщениями, обеспечивающий согласование протоколов шифрования/хеширования и генерацию ключей DH), а вторая фаза - на IKE_AUTH (тоже два сообщения, реализующие собственно аутентификацию).
- Mode Config (то, что в IKEv1 называлось фаза 1.5) теперь описан прямо в спецификации протокола и является его неотъемлемой частью.
- В IKEv2 добавился дополнительный механизм защиты от DoS-атак. Суть его в том, что прежде, чем отвечать на каждый запрос в установлении защищенного соединения (IKE_SA_INIT) IKEv2, VPN-шлюз шлет источнику такого запроса некий cookie и ждет ответа. Если источник ответил - все в порядке, можно начинать с ним генерацию DH. Если же источник не отвечает (в случае с DoS-атакой так и происходит, эта техника напоминает TCP SYN flood), то VPN-шлюз просто забывает о нем. Без этого механизма при каждом запросе от кого угодно VPN-шлюз бы пытался сгенерировать DH-ключ (что достаточно ресурсоемкий процесс) и вскоре бы столкнулся с проблемами. В итоге за счет того, что все операции теперь требуют подтверждения от другой стороны соединения, на атакуемом устройстве нельзя создать большое количество полуоткрытых сессий.

Выходим на рубеж

Наконец-то разобравшись с особенностями работы IPsec и его компонентов, можно переходить к главному - к практическим атакам. Топология будет достаточно простой и в то же время приближенной к реальности (см. рис. 3).

Рис. 3. Общая схема сети

Первым делом нужно определить наличие IPsec VPN шлюза. Сделать это можно, проведя сканирование портов, но здесь есть небольшая особенность. ISAKMP использует протокол UDP, порт 500, а между тем дефолтное сканирование с помощью Nmap затрагивает только TCP-порты. И в результате будет сообщение: `All 1000 scanned ports on 37.59.0.253 are filtered`.

Создается впечатление, что все порты фильтруются и как бы открытых портов нет. Но выполнив команду

Nmap -sU --top-ports=20 37.59.0.253 Starting Nmap 6.47 (http://nmap.org) at 2015-03-21 12:29 GMT Nmap scan report for 37.59.0.253 Host is up (0.066s latency). PORT STATE SERVICE 500/udp open isakmp
убеждаемся в том, что это не так и перед нами действительно VPN-устройство.

Атакуем первую фазу

Теперь нас будет интересовать первая фаза, aggressive-режим и аутентификация с использованием pre-shared key (PSK). В этом сценарии, как мы помним, VPN-устройство или отвечающая сторона отправляет хешированный PSK инициатору. Одна из самых известных утилит для тестирования протокола IKE - это ike-scan, она входит в состав дистрибутива Kali Linux. Ike-scan позволяет отправлять IKE сообщения с различными параметрами и, соответственно, декодить и парсить ответные пакеты. Пробуем прощупать целевое устройство:

Root@kali:~# ike-scan -M -A 37.59.0.253 0 returned handshake; 0 returned notify

Рис. 4. Ike-scan aggressive mode

Ключ `-A` указывает на то, что нужно использовать aggressive-режим, а `-M` говорит о том, что результаты следует выводить построчно (multiline), для более удобного чтения. Видно, что никакого результата не было получено. Причина состоит в том, что необходимо указать тот самый идентификатор, имя VPN-группы. Разумеется, утилита ike-scan позволяет задавать этот идентификатор в качестве одного из своих параметров. Но так как пока он нам неизвестен, возьмем произвольное значение, например 0000.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Aggressive Mode Handshake returned


Рис. 5. Ike-scan ID

В этот раз видим, что ответ был получен (см. рис. 5) и нам было предоставлено довольно много полезной информации. Достаточно важная часть полученной информации - это transform-set. В нашем случае там указано, что «Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK».

Все эти параметры можно указывать и для утилиты ike-scan с помощью ключа `--trans`. Например `--trans=5,2,1,2` будет говорить о том, что алгоритм шифрования 3DES, хеширование HMAC-SHA, метод аутентификации PSK и второй тип группы DH (1024-bit MODP). Посмотреть таблицы соответствия значений можно по этому адресу . Добавим еще один ключ (`-P`), для того чтобы вывести непосредственно пейлоад пакета, а точнее хеш PSK.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P


Рис. 6. Ike-scan payload

Преодолеваем первые сложности

Казалось бы, хеш получен и можно пробовать его брутить, но все не так просто. Когда-то очень давно, в 2005 году, на некоторых железках Сisco была уязвимость: эти устройства отдавали хеш, только если атакующий передавал корректное значение ID. Сейчас, естественно, встретить такое оборудование практически невозможно и хешированное значение присылается всегда, независимо от того, правильное значение ID отправил атакующий или нет. Очевидно, что брутить неправильный хеш бессмысленно. Поэтому первая задача - это определить корректное значение ID, чтобы получить правильный хеш. И в этом нам поможет недавно обнаруженная уязвимость.

Дело в том, что существует небольшая разница между ответами во время начального обмена сообщениями. Если кратко, то при использовании правильного имени группы происходит четыре попытки продолжить установление VPN-соединения плюс два зашифрованных пакета второй фазы. В то время как в случае неправильного ID в ответ прилетает всего лишь два пакета. Как видим, разница достаточно существенная, поэтому компания SpiderLabs (автор не менее интересного инструмента Responder) разработала сначала PoC, а затем и утилиту IKEForce для эксплуатации этой уязвимости.

В чем сила IKE

Установить IKEForce в произвольный каталог можно, выполнив команду

Git clone https://github.com/SpiderLabs/ikeforce
Работает она в двух основных режимах - режиме вычисления `-e` (enumeration) и режиме брутфорса `-b` (bruteforce). До второго мы еще дойдем, когда будем смотреть атаки на второй фактор, а вот первым сейчас и займемся. Перед тем как начать непосредственно процесс определения ID, необходимо установить точное значение transform-set. Мы его уже определили ранее, поэтому будем указывать опцией `-t 5 2 1 2`. В итоге выглядеть процесс нахождения ID будет следующим образом:

Python ikeforce.py 37.59.0.253 -e -w wordlists/group.txt -t 5 2 1 2


Рис. 7. IKEForce enumeration

В результате достаточно быстро удалось получить корректное значение ID (рис. 7). Первый шаг пройден, можно двигаться дальше.

Получаем PSK

Теперь необходимо, используя правильное имя группы, сохранить PSK-хеш в файл, сделать это можно с помощью ike-scan:

Ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk
И теперь, когда правильное значение ID было подобрано и удалось получить корректный хеш PSK, мы можем наконец-то начать офлайн-брутфорс. Вариантов такого брутфорса достаточно много - это и классическая утилита psk-crack, и John the Ripper (с jumbo-патчем), и даже oclHashcat, который, как известно, позволяет задействовать мощь GPU. Для простоты будем использовать psk-crack, который поддерживает как прямой брутфорс, так и атаку по словарю:

Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk

Рис. 8. Psk-crack

Но даже успешно восстановить PSK (см. рис. 8) - это только половина дела. На этом этапе нужно вспомнить про то, что дальше нас ждет XAUTH и второй фактор IPsec VPN.

Расправляемся со вторым фактором IPsec

Итак, напомню, что XAUTH - это дополнительная защита, второй фактор аутентификации, и находится он на фазе 1.5. Вариантов XAUTH может быть несколько - это и проверка по протоколу RADIUS, и одноразовые пароли (OTP), и обычная локальная база пользователей. Мы остановимся на стандартной ситуации, когда для проверки второго фактора используется локальная база пользователей. До недавнего времени не существовало инструмента в публичном доступе для брутфорса XAUTH. Но с появлением IKEForce эта задача получила достойное решение. Запускается брутфорс XAUTH достаточно просто:

Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Program started in XAUTH Brute Force Mode [+]Single user provided - brute forcing passwords for user: admin [*]XAUTH Authentication Successful! Username: admin Password: cisco


Рис. 9. IKEForce XAUTH

При этом указываются все найденные ранее значения: ID (ключ `-i`), восстановленный PSK (ключ `-k`) и предполагаемый логин (ключ `-u`). IKEForce поддерживает как грубый перебор логина, так и перебор по списку логинов, который может быть задан параметром `-U`. На случай возможных блокировок подбора есть опция `-s`, позволяющая снизить скорость брутфорса. К слову, в комплекте с утилитой идут несколько неплохих словарей, особенно полезных для установления значения параметра ID.

Входим во внутреннюю сеть

Теперь, когда у нас есть все данные, остается последний шаг - собственно проникновение в локальную сеть. Для этого нам понадобится какой-нибудь VPN-клиент, которых великое множество. Но в случае Kali можно без проблем воспользоваться уже предустановленным - VPNC. Для того чтобы он заработал, нужно подкорректировать один конфигурационный файл - `/etc/vpnc/vpn.conf`. Если его нет, то нужно создать и заполнить ряд очевидных параметров:

IPSec gateway 37.59.0.253
IPSec ID vpn
IPSec secret cisco123
IKE Authmode psk
Xauth Username admin
Xauth password cisco

Здесь мы видим, что были использованы абсолютно все найденные на предыдущих шагах данные - значение ID, PSK, логин и пароль второго фактора. После чего само подключение происходит одной командой:

Root@kali:~# vpnc vpn
Отключение тоже достаточно простое:

Root@kali:~# vpnc-disconnect
Проверить работоспособность подключения можно, используя команду `ifconfig tun0`.


Рис. 10. VPNC

Как построить надежную защиту

Защита от рассмотренных сегодня атак должна быть комплексной: нужно вовремя устанавливать патчи, использовать стойкие pre-shared ключи, которые по возможности вовсе должны быть заменены на цифровые сертификаты. Парольная политика и другие очевидные элементы ИБ также играют свою немаловажную роль в деле обеспечения безопасности. Нельзя не отметить и тот факт, что ситуация постепенно меняется, и со временем останется только IKEv2.

Что в итоге

Мы рассмотрели процесс аудита RA IPsec VPN во всех подробностях. Да, безусловно, задача эта далеко не тривиальна. Нужно проделать немало шагов, и на каждом из них могут поджидать трудности, но зато в случае успеха результат более чем впечатляющий. Получение доступа к внутренним ресурсам сети открывает широчайший простор для дальнейших действий. Поэтому тем, кто ответствен за защиту сетевого периметра, необходимо не рассчитывать на готовые дефолтные шаблоны, а тщательно продумывать каждый слой безопасности. Ну а для тех, кто проводит пентесты, обнаруженный пятисотый порт UDP - это повод провести глубокий анализ защищенности IPsec VPN и, возможно, получить неплохие результаты.

Подпишись на «Хакер»