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 завершают свою работу либо в результате их удаления, либо по причине превышения предельного времени их существования.

Режимы работы ipSec

Существует два режима работы IPSec: транспортный и туннельный.

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

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

Согласование преобразований IPSec

В ходе работы протокола IKE ведутся переговоры о преобразованиях IPSec (алгоритмах защиты IPSec). Преобразования IPSec и связанные с ними алгоритмы шифрования являются следующими:

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

Протокол ESP (Encapsulating Security Payload -- включающий защиту полезный груз). Протокол защиты, обеспечивающий конфиденциальность и защиту данных, а также (в качестве опции) сервис аутентификации и выявления воспроизведения. Поддерживающие IPSec продукты Cisco используют ESP для шифрования полезного груза IP-пакетов. Протокол ESP может использоваться самостоятельно или совместно с АН.

Стандарт DES (Data Encription Standard -- стандарт шифрования данных). Алгоритм шифрования и дешифрования данных пакетов. Алгоритм DES используется как в рамках IPSec, так и IKE. Для алгоритма DES используется 56-битовый ключ, что означает не только более высокое потребление вычислительных ресурсов, но и более надежное шифрование. Алгоритм DES является симметричным алгоритмом шифрования, для которого требуются идентичные секретные ключи шифрования в устройствах каждой из сообщающихся сторон IPSec. Для создания симметричных ключей применяется алгоритм Диффи-Хеллмана. IKE и IPSec используют алгоритм DES для шифрования сообщений.

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

AES (advanced encryption standard ). Протокол AES использует алгоритм шифрования Rine Dale4, который обеспечивает существенно более надежное шифрование. Многие криптографы считают, что AES вообще невозможно взломать. Сейчас AES яв­ляется федеральным стандартом обработки информации. Он определен как алгоритм шифрования для использования правительственными организациями США для защи­ты важных, но несекретных сведений. Проблема, связанная с AES, состоит в том, что для его реализации требуется большая вычислительная мощность по сравнению с аналогичными протоколами.

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

Алгоритм MD5 (Message Digest 5). Алгоритм хэширования, применяемый для аутентификации пакетов данных. В продуктах Cisco используется вычисляемый с помощью MD5 код НМАС (Hashed Message Authentication Code -- хэшированный код аутентичности сообщения)- вариант кода аутентичности сообщения, которому обеспечивается дополнительная защита с помощью хэширования. Хэширование представляет собой процесс одностороннего (т.е. необратимого) шифрования, в результате которого для поступающего на вход сообщения произвольной длины получается вывод фиксированной длины. IKE, АН и ESP используют MD5 для аутентификации данных.

Алгоритм SHA-1 (Secure Hash Algorithm-1 -- защищенный алгоритм хэширования 1). Алгоритм хэширования, используемый для аутентификации пакетов данных. В продуктах Cisco применяется вариант кода НМАС, вычисляемый с помощью SHA-1. IKЕ, АН и ESP используют SHA-1 для аутентификации данных.

В рамках протокола IKE симметричные ключи создаются с помощью алгоритма Диффи-Хеллмана, использующего DES, 3DES, MD5 и SHA. Протокол Диффи-Хеллмана является криптографическим протоколом, основанным на применении открытых ключей. Он позволяет двум сторонам согласовать общий секретный ключ, не имея достаточно надежного канала связи. Общие секретные ключи требуются для алгоритмов DES и НМАС. Алгоритм Диффи-Хеллмана используется в рамках IKE для создания сеансовых ключей. Группы Diffie-Hellman (DH) – определяют «силу» ключа шифрования, который используется в процедуре обмена ключами. Чем выше номер группы, тем «сильнее» и безопаснее ключ. Однако следует учитывать тот факт, что при увеличении номер группы DH увеличивается «сила» и уровень безопасности ключа, однако одновременно увеличивается нагрузка на центральный процессор, так как для генерации более «сильного» ключа необходимо больше времени и ресурсов.

Устройства WatchGuard поддерживают DH группы 1, 2 и 5:

DH group 1: 768-bit key

DH group 2: 1024-bit key

DH group 5: 1536-bit key

Оба устройства, которые обмениваются данными через VPN должны использовать одну и ту же группу DH. Группа DH, которая будет использоваться устройствами, выбирается во время IPSec Phase 1 процедуры.

Протоколы IPSec Организация защищенного канала https://www.сайт/lan/protokoly-ipsec https://www.сайт/@@site-logo/logo.png

Протоколы IPSec

Организация защищенного канала

Протоколы IPSec

Организация защищенного канала с помощью AH, ESP и IKE.

Internet Protocol Security (IPSec) называют в стандартах Internet системой. Действительно, IPSec - это согласованный набор открытых стандартов, имеющий сегодня вполне очерченное ядро, и в то же время он может быть достаточно просто дополнен новыми протоколами, алгоритмами и функциями.

Основное назначение протоколов IPSec - обеспечение безопасной передачи данных по сетям IP. Применение IPSec гарантирует:

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

(Заметим, что в соответствии с классическим определением понятие безопасности данных включает еще одно требование - доступность данных, что в рассмотренном контексте может быть интерпретировано как гарантия их доставки. Протоколы IPSec не решают данную задачу, оставляя ее протоколу транспортного уровня TCP.)

ЗАЩИЩЕННЫЕ КАНАЛЫ НА РАЗНЫХ УРОВНЯХ

IPSec - это только одна из многих, хотя и самая популярная на сегодня, технология безопасной передачи данных по общедоступной (незащищенной) сети. Для технологий такого назначения используется обобщенное название - защищенный канал (secure channel). Термин «канал» подчеркивает тот факт, что защита данных обеспечивается между двумя узлами сети (хостами или шлюзами) вдоль некоторого виртуального пути, проложенного в сети с коммутацией пакетов.

Защищенный канал можно построить с помощью системных средств, реализованных на разных уровнях модели OSI (см. Рисунок 1). Если для защиты данных используется протокол одного из верхних уровней (прикладного, презентационного или сеансового), то такой способ защиты не зависит от того, какие сети (IP или IPX, Ethernet или ATM) применяются для транспортировки данных, что можно считать несомненным достоинством. С другой стороны, приложение при этом становится зависимым от конкретного протокола защиты, т. е. для приложений такой протокол не является прозрачным.

Защищенному каналу на самом высоком, прикладном уровне свойственен еще один недостаток - ограниченная область действия. Протокол защищает только вполне определенную сетевую службу - файловую, гипертекстовую или почтовую. Например, протокол S/MIME защищает исключительно сообщения электронной почты. Поэтому для каждой службы необходимо разрабатывать соответствующую защищенную версию протокола.

Наиболее известным протоколом защищенного канала, работающим на следующем, презентационном уровне, стал протокол Secure Socket Layer (SSL) и его новая открытая реализация Transport Layer Security (TLS). Снижение уровня протокола превращает его в гораздо более универсальное средство защиты. Теперь единым протоколом защиты могут воспользоваться любые приложения и любые протоколы прикладного уровня. Однако приложения необходимо переписывать по-прежнему - в них должны быть встроены явные вызовы функций протокола защищенного канала.

Чем ниже в стеке реализованы средства защищенного канала, тем проще их сделать прозрачными для приложений и прикладных протоколов. На сетевом и канальном уровнях зависимость приложений от протоколов защиты исчезает совсем. Однако здесь мы сталкиваемся с другой проблемой - зависимостью протокола защиты от конкретной сетевой технологии. Действительно, в разных частях крупной составной сети, вообще говоря, используются разные канальные протоколы, поэтому проложить защищенный канал через эту гетерогенную среду с помощью единого протокола канального уровня невозможно.

Рассмотрим, например, протокол защищенного канала Point-to-Point Tunneling Protocol (PPTP), работающий на канальном уровне. Он основан на протоколе PPP, который широко используется в соединениях «точка-точка», например при работе по выделенным линиям. Протокол PPTP не только обеспечивает прозрачность средств защиты для приложений и служб прикладного уровня, но и не зависит от применяемого протокола сетевого уровня: в частности, протокол PPTP может переносить пакеты как в сетях IP, так и в сетях, работающих на основе протоколов IPX, DECnet или NetBEUI. Однако, поскольку протокол PPP используется далеко не во всех сетях (в большинстве локальных сетей на канальном уровне работает протокол Ethernet, а в глобальных - протоколы ATM, frame relay), то PPTP нельзя считать универсальным средством.

Работающий на сетевом уровне протокол IPSec является компромиссным вариантом. С одной стороны, он прозрачен для приложений, а с другой - он может работать практически во всех сетях, так как основан на широко распространенном протоколе IP: в настоящее время в мире только 1% компьютеров не поддерживает IP вообще, остальные 99% используют его либо как единственный протокол, либо в качестве одного из нескольких протоколов.

РАСПРЕДЕЛЕНИЕ ФУНКЦИЙ МЕЖДУ ПРОТОКОЛАМИ IPSEC

Ядро IPSec составляют три протокола: протокол аутентификации (Authenti-cation Header, AH), протокол шифрования (Encapsulation Security Payload, ESP) и протокол обмена ключами (Internet Key Exchange, IKE). Функции по поддержанию защищенного канала распределяются между этими протоколами следующим образом:

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

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

Для шифрования данных в IPSec может быть применен любой симметричный алгоритм шифрования, использующий секретные ключи. В основе обеспечения целостности и аутентификации данных также лежит один из приемов шифрования - шифрование с помощью односторонней функции (one-way function), называемой также хэш-функцией (hash function) или дайджест-функцией (digest function).

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

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

Разделение функций защиты между двумя протоколами AH и ESP вызвано применяемой во многих странах практикой на ограничение экспорта и/или импорта средств, обеспечивающих конфиденциальность данных путем шифрования. Каждый из этих двух протоколов может использоваться как самостоятельно, так и одновременно с другим, так что в тех случаях, когда шифрование из-за действующих ограничений применять нельзя, систему можно поставлять только с протоколом AH. Естественно, защита данных только с помощью протокола AH во многих случаях будет недостаточной, так как принимающая сторона в этом случае будет уверена только в том, что данные были отправлены именно тем узлом, от которого они ожидаются, и дошли в том виде, в котором были отправлены. От несанкционированного просмотра по пути следования данных протокол AH защитить не может, так как не шифрует их. Для шифрования данных необходимо применять протокол ESP, который может также проверить их целостность и аутентичность.

БЕЗОПАСНАЯ АССОЦИАЦИЯ

Для того чтобы протоколы AH и ESP могли выполнять свою работу по защите передаваемых данных, протокол IKE устанавливает между двумя конечными точками логическое соединение, которое в стандартах IPSec носит название «безопасная ассоциация» (Security Association, SA). Установление SA начинается со взаимной аутентификации сторон, потому что все меры безопасности теряют смысл, если данные передаются или принимаются не тем или не от того лица. Выбираемые далее параметры SA определяют, какой из двух протоколов, AH или ESP, применяется для защиты данных, какие функции выполняет протокол защиты: например, только аутентификацию и проверку целостности или, кроме того, еще и защиту от ложного воспроизведения. Очень важным параметром безопасной ассоциации является так называемый криптографический материал, т. е. секретные ключи, используемые в работе протоколов AH и ESP.

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

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

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

Для обеспечения совместимости в стандартной версии IPsec определен некоторый обязательный «инструментальный» набор: в частности, для аутентификации данных всегда может быть использована одна из функций односторонней шифрации MD5 либо SHA-1, а в число алгоритмов шифрования непременно входит DES. При этом производители продуктов, включающих IPSec, вольны расширять протокол за счет других алгоритмов аутентификации и шифрования, что они с успехом и делают. Например, многие реализации IPSec поддерживают популярный алгоритм шифрования Triple DES, а также сравнительно новые алгоритмы - Blowfish, Cast, CDMF, Idea, RC5.

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

ТРАНСПОРТНЫЙ И ТУННЕЛЬНЫЙ РЕЖИМЫ

Протоколы AH и ESP могут защищать данные в двух режимах: транспортном и туннельном. В транспортном режиме передача IP-пакета через сеть выполняется с помощью оригинального заголовка этого пакета, а в туннельном режиме исходный пакет помещается в новый IP-пакет и передача данных по сети выполняется на основании заголовка нового IP-пакета. Применение того или иного режима зависит от требований, предъявляемых к защите данных, а также от роли, которую играет в сети узел, завершающий защищенный канал. Так, узел может быть хостом (конечным узлом) или шлюзом (промежуточным узлом). Соответственно, имеются три схемы применения IPSec: «хост-хост», «шлюз-шлюз» и «хост-шлюз».

В первой схеме защищенный канал, или, что в данном контексте одно и то же, безопасная ассоциация, устанавливается между двумя конечными узлами сети (см. Рисунок 2). Протокол IPSec в этом случае работает на конечном узле и защищает данные, поступающие на него. Для схемы «хост-хост» чаще всего используется транспортный режим защиты, хотя разрешается и туннельный.

В соответствии со второй схемой, защищенный канал устанавливается между двумя промежуточными узлами, так называемыми шлюзами безопасности (Security Gateway, SG), на каждом из которых работает протокол IPSec. Защищенный обмен данными может происходить между любыми двумя конечными узлами, подключенными к сетям, которые расположены позади шлюзов безопасности. От конечных узлов поддержка протокола IPSec не требуется, они передают свой трафик в незащищенном виде через заслуживающих доверие сети Intranet предприятий. Трафик, направляемый в общедоступную сеть, проходит через шлюз безопасности, который и обеспечивает его защиту с помощью IPSec, действуя от своего имени. Шлюзы могут использовать только туннельный режим работы.

Схема «хост-шлюз» часто применяется при удаленном доступе. Здесь защищенный канал организуется между удаленным хостом, на котором работает IPSec, и шлюзом, защищающим трафик для всех хостов, входящих в сеть Intranet предприятия. Удаленный хост может использовать при отправке пакетов шлюзу как транспортный, так и туннельный режим, шлюз же отправляет пакет хосту только в туннельном режиме. Эту схему можно усложнить, создав параллельно еще один защищенный канал - между удаленным хостом и каким-либо хостом, принадлежащим внутренней сети, защищаемой шлюзом. Такое комбинированное использование двух SA позволяет надежно защитить трафик и во внутренней сети.

Наталья Олифер

Операции с документом

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 ...

Ссылки

IPsec (IP security) - набор протоколов для безопасной передачи трафика через IP сеть. Пожалуй, самый сложный и разветвленный стек протоколов из поддерживаемых системой VPNKI.

Включает в себя три основных протокола:

• AH (Authentication Header) - управление целостностью передаваемых данных и аутентификацию

• ESP (Encapsulating Security Payload) - шифрование данных

• ISAKMP (Internet Security Association and Key Management Protocol) - управление установкой соединения, взаимную аутентификации конечными узлами друг друга и обмен секретными ключами

Основные используемые порты и номера протоколов

• Протокол UDP, port 500 (IKE, управление ключами)
• Протокол UDP, port 4500 (IPSEC NAT-Traversal mode)
• Протокол ESP, значение 50 (for IPSEC)
• Протокол AH, значение 51 (for IPSEC)

Вообще, набор протоколов IPsec непрост с точки зрения возможностей его использования, которые весьма многогранны. Однако, базовой особенностью всего взаимодействия по этому протоколу является понятие SA (Security Association) - это набор параметров о том как стороны будут в дальнейшем использовать те или иные свойства протоколов из состава IPsec.

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

Аутентификация

Взаимодействие двух узлов начинается с установления SA. Точнее с двух ассоциаций - для протокола AH и ESP причем в одну и в другую стороны. SA начинается с аутентификации и затем стороны согласовывают будущие параметры сессии:

• для протокола AH - используемый алгоритм аутентификации, ключи, время жизни ключей и другие параметры,
• для протокола ESP - алгоритмы шифрования и аутентификации, ключи, параметры инициализации, время жизни ключей и другие параметры.

Здесь же стороны договариваются о туннельном или транспортном режиме работы IPsec.

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

Фаза 1 и Фаза 2

В IPsec все происходит по Фазам.

На фазе 1 происходит установление SA первой фазы. В первой фазе стороны договариваются о методе идентификации, алгоритме шифрования, алгоритме хэшировнаия и группе Diffie Hellman. Эта фаза может пройти путем обмена тремя нешифрованными пакетами (агрессивный режим) или шестью нешифрованными пакетами - стандартный режим. Если все прошло успешно, то создается SA фазы 1 под названием IKE SA и осуществляется переход ко второй фазе.

На фазе 2 стороны договариваются о политике и создаются сами ключи. Эта фаза, в отличии от первой полностью шифруется и она наступает только в случае успешного окончания первой фазы. В связи с тем, что трафик этой фазы полностью шифрован становится сложно осуществлять поиск неполадок, однако если все прошло успешно, то создается SA фазы 2 под названием IPSec SA. В этот момент можно сказать, что туннель установлен.

Компрессия данных

В составе IPsec нет собственного механизма компрессии данны, однако можно использовать механизм IPcomp который компрессирует содержимое IP пакета до его передачи в процесс IPsec. Некоторые демоны IPsec поддерживают включение этого механизма из файлов настроек ipsec.conf (например пакет Strongswan)

Автоматическая проверка работоспособности VPN соединения

Внутри IPsec нет штатного средства для проверки работоспособности соединения (типа ping), поэтому работу туннеля можно проверять внешними средствами.

Разрыв VPN соединения и смена ключей

Согласованные на двух фазах ключи должны работать оговоренное политикой время. Это означает, что сторонам возможно предстоит пережить процедуру смены ключей (rekeying), а иначе согласованные SA распадутся. Как было сказано выше, у сторон есть ключи в рамках процесса фазы 1 (IKE) и фазы 2 (IPsec). Процедуры их смены различны, как и таймеры, которые за это отвечают. Для того, чтобы не было перерыва связи в процессе смены ключей стороны сначала согласовывают параметры новой SA и лишь после этой успешной процедуры уничтожают старую SA.

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