Что такое ipsec в роутере
Что такое ipsec в роутере
Пока что в серии криптосистем мы познакомились с общей терминологией криптографии и криптосистемой SSH (включая её конфигурацию). Сегодняшнюю статью я начну с с описания того, как работает VPN, а затем расскажу о стандарте IPSec.
VPN Туннели
Прежде чем приступить к настройке VPN, необходимо познакомится с общепринятой терминологией и с некоторыми проблемами настройки. Начнём с терминологии. VPN соединение всегда состоит из канала типа точка-точка, также известного под названием туннель. Туннель создаётся в незащищённой сети, в качестве которой чаще всего выступает Интернет. Соединение точка-точка подразумевает, что оно всегда устанавливается между двумя компьютерами, которые называются узлами или peers. Каждый peer отвечает за шифрование данных до того, как они попадут в туннель и расшифровке этих данных после того, как они туннель покинут.
Хотя VPN туннель всегда устанавливается между двумя точками, каждый peer может устанавливать дополнительные туннели с другими узлами. Для примера, когда трём удалённым станциям необходимо связаться с одним и тем же офисом, будет создано три отдельных VPN туннеля к этому офису. Для всех туннелей peer на стороне офиса может быть одним и тем же. Это возможно благодаря тому, что узел может шифровать и расшифровывать данные от имени всей сети, как это показано на рисунке 1:
Интересно отметить, что внутри домена шифрования самого шифрования не происходит. Причина в том, что эта часть сети считается безопасной и находящейся под непосредственным контролем в противоположность Интернет. Это справедливо и при соединении офисов с помощью VPN шлюзов. Таким образом гарантируется шифрование только той информации, которая передаётся по небезопасному каналу между офисами. Рисунок 2 показывает VPN соединяющую два офиса:
Сеть A считается доменом шифрования VPN шлюза A, а сеть B доменом шифрования VPN шлюза B, соответственно. Когда пользователь сети A изъявляет желание отправить данные в сеть B, VPN шлюз A зашифрует их и отошлёт через VPN туннель. VPN шлюз B расшифрует информацию и передаст получателю в сети B.
Существует много вариантов VPN шлюзов и VPN клиентов. Это может быть аппаратное VPN устройство или программное VPN обеспечение, которое устанавливается на маршрутизаторах или на ПК. ОС FreeBSD поставляется вместе с ПО для создания VPN шлюза и для настройки VPN клиента. В коллекции портов существуют и другие приложения, позволяющие соединяться со станциями под управлением других ОС.
К счастью, в Интернет есть много источников информации о VPN, FAQ и варианты настроек. Я могу порекомендовать Tina Bird’s VPN Information, VPN Labs, и Virtual Private Network Consortium (VPNC).
Назависимо от используемого ПО, все VPN работают по следующим принципам:
IPSec
Приведём краткое описание каждого, чтобы получить необходимую информацию для понимания следующей статьи, посвящённой настройке IPSec VPN на FreeBSD системе. Начнём с сокращений, а затем посмотрим как они укладываются в общую картину создания виртуальной частной сети.
Т.к. каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить к какому узлу он относится. Это номер называется SPI (Security Parameter Index) или индекс параметра безопасности.
Какие настройки включает в себя политика?
При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie Hellman групп. В таком случае будет использована первая совпавшая на обоих узлах позиция. Запомните, очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VPN соединение. При настройе VPN между различными системами уделите время изучению того, какие алгоритмы поддерживаются каждой стороной, чтобы иметь выбор наиболее безопасной политики из возможных.
Фаза Один и Фаза Два
На втором этапе генерируются данные ключей, узлы договариваются насчёт используемой политики. Этот режим, также называемый быстрым режимом (quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Такое положение дел усложняет решение проблем в случае неполадок на второй фазе при успешном завершении первой. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA, и на этом установка туннеля считается завершённой.
Когда же это всё происходит? Сначала на узел прибывает пакет с адресом назначения в другом домене шифрования, и узел инициирует Фазу Один с тем узлом, который отвечает за другой домен. Допустим, туннель между узлами был успешно установлен и ожидает пакетов. Однако, узлам необходимо переидентифицировать друг друга и сравнить политику через определённое время. Это время известно как время жизни Phase One или IKE SA lifetime.
Что такое IPSec туннель в VPN и как его настроить бесплатно?
Всем привет! IPSec – набор компонентов, обеспечивающих защиту конфиденциальной информации, передаваемой с помощью межсетевого протокола IP. Эффект безопасности достигается через аутентификацию, обязательную проверку целостности пакетов с трафиков и поэтапного шифрования данных в сети.
По бесплатной настройке IPSec на компьютере и телефоне, а также более подробно про VPN – читайте инструкцию тут.
Особенности
Экскурс в историю
В 1994 году технические специалисты из «Совета по архитектуре Интернета» (IAB) подготовили отчет, описывающий низкий уровень безопасности сети. В качестве доводов за организацию специальных протоколов или стандартов, приводились концепции несанкционированного доступа к пакетам трафика, важным данным и инструментам. После ряда экспериментов и появился IPSec (как и остальные протоколы), необходимый для защиты публичных телекоммуникационных сетей и шифрования передаваемой информации.
Стандарты
Сначала появились спецификации под кодовым названием: RFC1825, RFC1826 и RFC1827. Но чуть позже специалисты из «IP Security Protocol» пересмотрели некоторые требования и выпустили комплект архитектур и компонентов с RFC2401 по RFC2412. Среди новых спецификаций скрываются алгоритмы шифрования, инструменты для управления общими ключами аутентификации и проверки IP-пакетов.
Этапы работы IPSec
Сценарий взаимодействия с протоколом формально делиться на 5 частей. Сначала – подготовка «политики безопасности», описывающей правила шифрования трафика, способы отсеивания лишних данных, а также алгоритмы и функции, включенные в работу.
Далее – организация безопасного канала между связанными сторонами: аутентификация, проверка политики безопасности, передача секретных ключей. К третьему этапу соединение через IPSec устанавливается с полным согласованием необходимых параметров и особенностей сети.
Четвертый шаг сосредоточен вокруг полноценного взаимодействия между узлами. А последний посвящен прекращению обслуживания. Причем предусмотрено два сценария – ручное удаление и прекращение связи после истечения определенного времени и в целях безопасности.
После – описанный порядок действий повторяется вновь.
Применение
Протокол IPSec незаменим при построении и организации VPN туннелей, где компоненты AH (Authentication Header) и ESP (Encapsulated Security Payload) запускаются в режиме туннелирования с функцией межсетевого экрана – фильтрующего поступающий трафик в соответствии с выбранными и заранее настроенными правилами. Система способна отклонять небезопасные пакеты с данными или вовсе запрещать связь с сетью или с некоторыми интернет-ресурсами.
Межсетевой экран IPSec пригодится и при проблемах с безопасностью на серверах. Если правильно организовать работу компонентов AH и ESP, то весь веб-трафик начнет автоматически отбрасываться, за исключением соединений через 80-й порт TCP (или 443 порт TCP при HTTPS).
Архитектура IPSec
Комплекс протоколов и компонентов, появившийся благодаря специалистам из «IP Security Protocol IETF», на момент релиза включал 3 спецификации, описывавших архитектуру безопасности, параметры аутентификации и шифрования. Чуть позже стандарты изменились, но вот принципы и цели остались прежними. Как и раньше IPSec поделен на взаимосвязанные части.
Основные компоненты
IKE – протокол, осуществляющий обмен ключами шифрования через фреймворк ISAKMP. Представлен в двух версиях – IKEv1 и IKEv2, получивших развитие в ближайшие годы и частично изменившие некоторые стандарты IPSec. Протокол IKE разделяется на части для обеспечения дополнительной безопасности с использованием сторонних расширений, вроде «Extended Authentication» (XAUTH) или «Mode-Configuration» (MODECFG). В совокупности модификации вместе с дополнительными ключами PSK (Pre-shared key) способны отсеять тех пользователей, которые смогли преодолеть первую фазу проверку IPSec.
VPN на домашнем роутере: быстро и надежно
Обычно беспроводные роутеры используются для предоставления доступа к Интернет различным домашним устройствам. Но иногда требуется решить и в определенном смысле противоположную задачу – реализовать удаленный доступ к размещенным в домашней сети сервисам и системам. Традиционный вариант решения этой задачи обычно состоит из трех шагов – использовать сервис динамического DNS для автоматического определения внешнего IP-адреса роутера, назначить в параметрах сервиса DHCP роутера выделение фиксированного адреса для нужного клиента и создать правило трансляции портов для требуемого сервиса на этом клиенте. Заметим, что удаленный доступ в большинстве случаев возможен только при наличии «белого»/«внешнего» адреса на WAN-интерфейсе роутера (подробнее см. в статье), а DDNS может не требоваться, если ваш провайдер предоставляет фиксированный IP-адрес.
Правил трансляции портов часто вполне достаточно для реализации задачи, но у них есть определенные особенности. Например, в случае необходимости защиты передаваемой информации, вам потребуется решать этот вопрос для каждого соединения индивидуально. Вторая потенциальная проблема – ограничения в случае, когда программное обеспечение требует использования определенного номера порта, а серверов в локальной сети несколько. Кроме того, если сервисов и внутренних систем у вас много, то есть очевидные неудобства прописывания в роутер каждого правила трансляции.
Помочь справиться с этими вопросами помогут технологии VPN – виртуальных частных сетей. Они позволяют создать безопасное соединение между удаленным клиентом или локальной сетью и сразу всей сетью за роутером. То есть вам будет достаточно один раз настроить этот сервис и при подключении к нему клиент будет вести себя так, как будто он находится в локальной сети. Заметим, что эта схема тоже требует внешнего адреса на роутере и, кроме того, имеет некоторые ограничения связанные с использованием имен систем и других сервисов.
В прошивках многих современных роутеров среднего и верхнего сегмента предусмотрен встроенный сервер VPN. Чаще всего он работает с протоколами PPTP и OpenVPN. Первый является популярным вариантом, который был разработан более 15-ти лет назад при участии крупных ИТ-компаний, включая Microsoft. Его клиент встроен во многие современные ОС и мобильные устройства, что упрощает реализацию. Однако считается, что в этом решении не очень хорошо решаются вопросы безопасности. Скорость защищенного соединения для этого протокола в зависимости от производительности платформы роутера обычно составляет 30-50 Мбит/с, на самых быстрых устройствах мы встречали и 80 Мбит/с (см. например статью).
OpenVPN является свободной реализацией VPN сходного возраста и выпускается по лицензии GNU GPL. Клиенты для него есть для большинства платформ, включая мобильные. Серверы можно встретить во многих альтернативных прошивках для роутеров, а также в оригинальных версиях от производителей оборудования. Минусом этого протокола является требование значительных вычислительных ресурсов для обеспечения высокой скорости работы, так что 40-50 Мбит/с можно получить только на решениях верхнего сегмента (см. например).
Еще один вариант, который чаще связывают с «серьезными» решениями безопасных сетевых коммуникаций, – IPsec (см. статью). Его история началась немного раньше и сегодня его можно встретить во многих продуктах удаленного доступа корпоративного уровня.
Тем не менее, относительно недавно его реализация появилась и в таком явно массовом оборудовании, как роутеры серии Zyxel Keenetic. Используемый в них программный модуль позволяет реализовать безопасные сценарии удаленного доступа, а также объединения сетей без сложных настроек. Кроме того, он совместим с решениями серии ZyWall. К плюсам этого производителя стоит отнести удобную базу знаний с подробными статьями о реализации типовых сценариев. По данной теме можно обратить внимание на статьи по объединению двух сетей и подключению клиента с Windows. Приводить подробные скриншоты настроек не имеет смысла, поскольку они есть по указанным ссылкам. Отметим только что все просто и понятно.
Учитывая ресурсоемкость используемых в данном сценарии алгоритмов, важным является вопрос производительности такого решения. Для его изучения были выбраны три модели роутеров последнего поколения – топовые Keenetic Ultra II и Keenetic Giga III, а также бюджетный Keenetic Start II. Первые два имеют процессоры MediaTek серии MT7621, по 256 МБ оперативной памяти и по 128 МБ флэшпамяти, гигабитные сетевые порты, два диапазона Wi-Fi, поддержку 802.11ac, порт USB 3.0. При этом в старшей используется чип с двумя ядрами, работающими на частоте 880 МГц, а во второй – такой же чип, но только с одним ядром. А третий роутер оборудован 100 Мбит/с портами (причем в количестве двух штук – один WAN и один LAN) и однодиапазонным беспроводным модулем. Процессор в нем используется MT7628N с одним ядром и частотой 575 МГц, а объем оперативной памяти составляет 64 МБ. С точки зрения программных возможностей, связанных с IPsec, устройства не отличаются.
На все три роутера были установлены прошивки из ветки бета версий v2.07(xxxx.2)B2. Режим подключения к сети Интернет на всех устройствах выбирался самый простой – IPoE. Работа с другими вариантам, скорее всего, приведет к снижению результатов. На следующих двух графиках приводятся результаты тестирования пар с разными настройками параметров соединения – Ultra II и Giga III, Ultra II и Start II. В первой устройства в целом сравнимы по скорости (правда у старшего два ядра), а во второй ограничения будут от младшей модели. Направление указано относительно второго устройства. Использовались сценарии передачи, приема и одновременной передачи и приема данных между подключенными к роутерам клиентами.
Как мы видим, скорости здесь достаточно низкие и даже не дотягивают до 100 Мбит/с. При этом нагрузка на процессор во время активного обмена данными очень высока, что может иметь негативные последствия и для других решаемых устройством задач.
Однако, как мы помним по другим сходным ресурсоемким сценариям (например, обработке видео), существенный рост производительности на специализированных задачах можно получить благодаря использованию выделенных блоков чипов, «заточенных» на эффективную работу с определенными алгоритмами. Что интересно, в современных SoC от MediaTek такие как раз присутствуют и программисты компании в недавних обновлениях прошивок реализовали эту возможность.
При этом максимальный эффект можно получить на чипах MT7621 и RT6856, а на MT7628 поддерживаются не все режимы. Посмотрим, что изменится при использовании данного блока. Для его включения используем команду в консоли, как на скриншоте.
Старшая пара показывает скорость в 200 Мбит/с и более, что еще раз подтверждает правильность идеи создания специализированных блоков для определенных стандартных алгоритмов, которые существенно производительнее универсальных ядер.
Для младшей однокристальной системы эффект менее заметен, но и здесь можно отметить увеличение скорости в два раза для некоторых конфигураций.
Посмотрим теперь, насколько хорошо устройства справятся с обслуживанием подключений с достаточно быстрого компьютера с процессором Intel Core i5 и ОС Windows 8.1 x64 (описание настройки соединения доступно по ссылке выше). В роли условных серверов (в соединениях IPsec участники в определенном смысле равноправны) выступили старший Keenetic Ultra II и младший Keenetic Start II.
Топовый роутер в некоторых конфигурациях разгоняется более чем до 300 Мбит/с. Так что видимо второе ядро процессора помогает и в этом сценарии. Впрочем, на практике для достижения этих результатов вам понадобится и соответствующие Интернет-каналы.
Результаты Keenetic Start II по понятным причинам практически не отличаются от того, что мы видели выше.
Стоит заметить, что использование оптимизации не сказалось на стабильности соединения. Все участники успешно выдержали все тесты без каких-либо замечаний.
Проведенные тесты еще раз подтвердили, что современные продукты сегмента ИТ представляют собой программно-аппаратные комплексы и эффективность решения ими поставленных задач существенно зависит не только от установленного «железа», но и эффективной программной реализации его возможностей.
Пока я проводил тесты, оказалось, что компания в последних отладочных прошивках серии 2.08 для энтузиастов реализовала еще одну полезную возможность, позволяющую использовать сервис IPsec с мобильными клиентами. Описанный выше сценарий создания профиля соединения требовал постоянных IP-адресов с двух сторон соединения, что для смартфонов в обычных ситуациях не встречается. Подробности и инструкции можно прочитать в этих ветках: Android, iOS/OS X, Windows (Cisco VPN Client).
В настоящий момент этот режим не полностью поддерживается в Web-интерфейсе, однако это не помешало провести несколько быстрых тестов с Keenetic Giga III. С Apple iPhone 5S реальная скорость составила 5-10 Мбит/с в зависимости от направления, а Xiaomi Mi5 оказался побыстрее – 10-15 Мбит/с (оба устройства подключались через Wi-Fi). Штатный клиент Cisco IPsec в OS X 10.11 на современной системе показал 110 Мбит/с на передачу и 240 Мбит/с на прием (при использовании гигабитной локальной сети и с учетом описанной выше операции по настройке роутера в консоли). Windows с известным, хотя и уже не поддерживающимся клиентом Cisco VPN Client, работала также достаточно быстро – 140 Мбит/с на передачу и 150 Мбит/с на прием. Таким образом, данная реализация IPsec явно может быть интересна широкому кругу пользователей для реализации быстрого и безопасного удаленного доступа к своей локальной сети с мобильных устройств и компьютеров из любой точки мира.
VPN везде и всюду: IPsec без L2TP со strongSwan
достаточно сильный лебедь
Если вы когда-либо искали VPN, который будет работать на десктопах, мобильных устройствах и роутерах без установки дополнительного ПО и перепрошивки роутера, вы, вероятно, выбирали между PPTP и L2TP+IPsec. У протокола PPTP имеются проблемы с безопасностью и прохождением через брандмауеры и NAT, так что в 2015 году его уже использовать не стоит, а использование L2TP излишне, т.к. L2 VPN, по моему мнению, для обычного удаленного доступа не нужен практически никогда.
Удивительно, что в интернете не так-то просто можно найти информацию о настройке чего-то помимо L2TP+IPsec в транспортном режиме, учитывая, что это обширный стек протоколов, который можно конфигурировать буквально как душе угодно, поэтому я попытаюсь устранить такое несовершенство мира.
Небольшое введение в мир IPsec
Вообще говоря, не совсем правильно называть IPsec VPN. IPsec не предназначен для построения «виртуальных частных сетей», а создан для шифрования или защиты от подмены передаваемых по IP данных. Это специальный слой поверх IP, который, в зависимости от режима и настроек, работает по-разному. В отличие от привычного VPN, который создает новый интерфейс в системе, на который вы, как это чаще всего бывает, назначаете IP-подсеть из диапазона частных адресов (т.е. создаете новый сетевой сегмент), и через который маршрутизируется трафик в зашифрованном виде, IPsec просто шифрует трафик магическим образом между «внешними» интерфейсами сервера и клиента.
Все современные десктопные ОС (Windows Vista/7/8/8.1, OS X, Linux), мобильные устройства (Android, iOS, Windows Phone, Blackberry) и некоторые роутеры поддерживают VPN с использованием IPsec ESP в туннельном режиме и его настройкой через протокол Internet Key Exchange (IKE) версии 1 или 2, а значит IPsec мы именно так и будем настраивать.
Кстати, писать правильно IPsec, но Cisco IPSec.
IPsec в Linux
Жизнь со swanctl: 
Жизнь без swanctl: 
Переходим к настройке
Будем настраивать подключение через IKEv2 (Windows, Linux, Blackberry), IKEv1+XAUTH (iOS, OS X, Android) и IKEv2+EAP-TLS (Windows Phone). Используем ключи, никаких PSK!
Разработчики strongSwan предлагают нам использовать команду «ipsec pki» для генерации ключей, но она настолько же неудобная, насколько и обычный openssl, поэтому я адаптировал Easy-RSA v3 из OpenVPN для генерации как OpenVPN, так и IPsec-совместимых ключей. С ним вы можете использовать одну связку ключей для двух протоколов!
github.com/ValdikSS/easy-rsa-ipsec
Easy-RSA чрезвычайно простой, поддерживать PKI-инфраструктуру с ним одно удовольствие!
Итак, инициализируем PKI и создаем CA, серверный и клиентский ключи. Важно, чтобы название серверного ключа совпадало с FQDN (доменом, проще говоря) вашего сервера!
Ключи сгенерированы. Я добавлял параметр nopass на каждом шагу, чтобы ключи не были защищены паролем (его можно установить позже в любое время).
Переходим к настройке strongSwan!
Первым делом, указываем наш приватный ключ в /etc/ipsec.secrets
Редактируем конфигурационный файл /etc/ipsec.conf
Теперь у нас есть три подключения: ikev2-pubkey для IKEv2, ikev1-fakexauth для IKEv1 с фейковой проверкой логина и пароля и ikev2-eap-tls — IKEv2+EAP-TLS для Windows Phone. Перезапускаем strongSwan.
Проблемы MTU
Из-за особенностей и ошибок в реализации разных IPsec-клиентов, MTU внутри туннеля нельзя угадать заранее, а на Android вообще устанавливается MTU 1500, из-за чего большие пакеты не передаются и вообще ничего не работает. Чтобы нивелировать этот недостаток, достаточно изменять параметр TCP MSS в момент установки TCP-соединения на стороне сервера. Будем использовать значение 1360 для IPv4 и 1340 для IPv6, чтобы размер пакета не превышал 1400 байт внутри туннеля:
На этом настройка сервера закончена. Не забудьте настроить NAT, если вам он нужен!
Настройка клиентов
Алгоритм настройки клиентов в общих чертах заключается в импорте сертификатов из файла *.p12, создании нового подключения с типом IPsec PKI, IPsec XAUTH RSA или IKEv2 (в зависимости от устройства), указания клиентского сертификата и адреса сервера.
Внимание! Нужно вводить именно тот адрес сервера, который вы вводили при создании серверного ключа. Подключиться по другому домену или просто по IP-адресу, если сертификат был сгенерирован на домен, не получится!
Windows
OS X и iOS
Android
Вы можете использовать как IPsec-клиент Android и подключаться по протоколу IKE, так и клиент strongSwan и использовать IKEv2. Клиент strongSwan работает стабильнее и надежно переподключает в случае потери соединения.
Импортируйте сертификат либо через файловый менеджер, либо используя пункт «Установка с SD-карты» в разделе «Безопасность». Перейдите в настройки VPN, создайте новое подключение с типом «IPSec Xauth RSA», в поле «Адрес сервера» впишите, собственно, адрес сервера, в поле «Сертификат пользователя IPSec» и «Сертификат ЦС IPSec» укажите сертификат «client1». Нажмите на соединение, введите любые логин и пароль и попробуйте подключиться.
IPSec — протокол защиты сетевого трафика на IP-уровне
Введение
Необходимость защиты данных
В конце шестидесятых годов американское агентство перспективных исследований в обороне DARPA приняло решение о создании экспериментальной сети под названием ARPANet. В семидесятых годах ARPANet стала считаться действующей сетью США, и через эту сеть можно было получить доступ к ведущим университетским и научным центрам США. В начале восьмидесятых годов началась стандартизация языков программирования, а затем и протоколов взаимодействия сетей. Результатом этой работы стала разработка семиуровневой модели сетевого взаимодействия ISO/OSI и семейства протоколов TCP/IP, которое стало основой для построения как локальных, так и глобальных сетей.
Базовые механизмы информационного обмена в сетях TCP/IP были в целом сформированы в начале восьмидесятых годов, и были направлены прежде всего на обеспечение доставки пакетов данных между различными операционными системами с использованием разнородных каналов связи. Несмотря на то, что идея создания сети ARPANet (впоследствии превратившейся в современный Интернет) принадлежала правительственной оборонной организации, фактически сеть зародилась в исследовательском мире, и наследовала традиции открытости академического сообщества. Ещё до коммерциализации Интернета (которая произошла в середине девяностых годов) многие авторитетные исследователи отмечали проблемы, связанные с безопасностью стека протоколов TCP/IP. Основные концепции протоколов TCP/IP не полностью удовлетворяют (а в ряде случаев и противоречат) современным представлениям о компьютерной безопасности.
До недавнего времени сеть Интернет использовалась в основном для обработки информации по относительно простым протоколам: электронная почта, передача файлов, удалённый доступ. Сегодня, благодаря широкому распространению технологий WWW, всё активнее применяются средства распределённой обработки мультимедийной информации. Одновременно с этим растёт объём данных, обрабатываемых в средах клиент/сервер и предназначенных для одновременного коллективного доступа большого числа абонентов. Разработано несколько протоколов прикладного уровня, обеспечивающих информационную безопасность таких приложений, как электронная почта (PEM, PGP и т.п.), WWW (Secure HTTP, SSL и т.п.), сетевое управление (SNMPv2 и т.п.). Однако наличие средств обеспечения безопасности в базовых протоколах семейства TCP/IP позволит осуществлять информационный обмен между широким спектром различных приложений и сервисных служб.
Краткая историческая справка появления протокола
В 1994 году Совет по архитектуре Интернет (IAB) выпустил отчет «Безопасность архитектуры Интернет». В этом документе описывались основные области применения дополнительных средств безопасности в сети Интернет, а именно защита от несанкционированного мониторинга, подмены пакетов и управления потоками данных. В числе первоочередных и наиболее важных защитных мер указывалась необходимость разработки концепции и основных механизмов обеспечения целостности и конфиденциальности потоков данных. Поскольку изменение базовых протоколов семейства TCP/IP вызвало бы полную перестройку сети Интернет, была поставлена задача обеспечения безопасности информационного обмена в открытых телекоммуникационных сетях на базе существующих протоколов. Таким образом, начала создаваться спецификация Secure IP, дополнительная по отношению к протоколам IPv4 и IPv6.
Архитектура IPSec
IP Security — это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC.
Спецификация IP Security (известная сегодня как IPsec) разрабатывается Рабочей группой IP Security Protocol IETF. Первоначально IPsec включал в себя 3 алгоритмо-независимые базовые спецификации, опубликованные в качестве RFC-документов «Архитектура безопасности IP», «Аутентифицирующий заголовок (AH)», «Инкапсуляция зашифрованных данных (ESP)» (RFC1825, 1826 и 1827). Необходимо заметить, что в ноябре 1998 года Рабочая группа IP Security Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов, это RFC2401 — RFC2412. Отметим, что RFC1825-27 на протяжении уже нескольких лет считаются устаревшими и реально не используются. Кроме этого, существуют несколько алгоритмо-зависимых спецификаций, использующих протоколы MD5, SHA, DES.
Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка Internet Key Management Protocol (IKMP), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием спецификации Internet Security Association and Key Management Protocol (ISAKMP) и протокола Oakley Key Determination Protocol. Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Ранее рассматривались также возможности использования механизмов управления ключами протокола SKIP, однако сейчас такие возможности реально практически нигде не используются. Создаваемые стандарты управления ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos. Протоколами ключевого управления для IPSec на основе Kerberos сейчас занимается относительно новая рабочая группа KINK (Kerberized Internet Negotiation of Keys).
Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного обмена т.н. «контекста безопасности» – применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией и их параметров. Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом согласования контекста безопасности является установление индекса параметров безопасности (SPI), представляющего собой указатель на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности.
По сути, IPSec, который станет составной частью IPv6, работает на третьем уровне, т. е. на сетевом уровне. В результате передаваемые IP-пакеты будут защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.
К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе Data Encryption Standard (DES) и Message Digest 5 (MD5).
Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты, такие как алгоритмы аутентификации и ключи. IPSec поддерживает два типа схем управления ключами, с помощью которых участники могут согласовать параметры сеанса. Эта двойная поддержка в свое время вызвала определенные трения в IETF Working Group.
С текущей версией IP, IPv4, могут быть использованы или Internet Secure Association Key Management Protocol (ISAKMP), или Simple Key Management for Internet Protocol. С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как IKE, хотя не исключается возможность использования SKIP. Однако, следует иметь в виду, что SKIP уже давно не рассматривается как кандидат управления ключами, и был исключён из списка возможных кандидатов ещё в 1997 г.
Заголовок AH
Аутентифицирующий заголовок (AH) является обычным опциональным заголовком и, как правило, располагается между основным заголовком пакета IP и полем данных. Наличие AH никак не влияет на процесс передачи информации транспортного и более высокого уровней. Основным и единственным назначением AH является обеспечение защиты от атак, связанных с несанкционированным изменением содержимого пакета, и в том числе от подмены исходного адреса сетевого уровня. Протоколы более высокого уровня должны быть модифицированы в целях осуществления проверки аутентичности полученных данных.
Формат AH достаточно прост и состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей достаточно ясно отражают их содержимое: Next Header указывает на следующий заголовок, Payload Len представляет длину пакета, SPI является указателем на контекст безопасности и Sequence Number Field содержит последовательный номер пакета.
Последовательный номер пакета был введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Поскольку сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (обычно это число равно 64).
В отличие от алгоритмов вычисления контрольной суммы, применяемых в протоколах передачи информации по коммутируемым линиям связи или по каналам локальных сетей и ориентированных на исправление случайных ошибок среды передачи, механизмы обеспечения целостности данных в открытых телекоммуникационных сетях должны иметь средства защиты от внесения целенаправленных изменений. Одним из таких механизмов является специальное применение алгоритма MD5: в процессе формирования AH последовательно вычисляется хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям.
Заголовок ESP
В случае использования инкапсуляции зашифрованных данных заголовок ESP является последним в ряду опциональных заголовков, «видимых» в пакете. Поскольку основной целью ESP является обеспечение конфиденциальности данных, разные виды информации могут требовать применения существенно различных алгоритмов шифрования. Следовательно, формат ESP может претерпевать значительные изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные поля: SPI, указывающее на контекст безопасности и Sequence Number Field, содержащее последовательный номер пакета. Поле «ESP Authentication Data» (контрольная сумма), не является обязательным в заголовке ESP. Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.
Различают два режима применения ESP и AH (а также их комбинации) — транспортный и туннельный.
Транспортный режим
Транспортный режим используется для шифрования поля данных IP пакета, содержащего протоколы транспортного уровня (TCP, UDP, ICMP), которое, в свою очередь, содержит информацию прикладных служб. Примером применения транспортного режима является передача электронной почты. Все промежуточные узлы на маршруте пакета от отправителя к получателю используют только открытую информацию сетевого уровня и, возможно, некоторые опциональные заголовки пакета (в IPv6). Недостатком транспортного режима является отсутствие механизмов скрытия конкретных отправителя и получателя пакета, а также возможность проведения анализа трафика. Результатом такого анализа может стать информация об объемах и направлениях передачи информации, области интересов абонентов, расположение руководителей.
Туннельный режим
Туннельный режим предполагает шифрование всего пакета, включая заголовок сетевого уровня. Туннельный режим применяется в случае необходимости скрытия информационного обмена организации с внешним миром. При этом, адресные поля заголовка сетевого уровня пакета, использующего туннельный режим, заполняются межсетевым экраном организации и не содержат информации о конкретном отправителе пакета. При передаче информации из внешнего мира в локальную сеть организации в качестве адреса назначения используется сетевой адрес межсетевого экрана. После расшифровки межсетевым экраном начального заголовка сетевого уровня пакет направляется получателю.
Security Associations
Security Association (SA) — это соединение, которое предоставляет службы обеспечения безопасности трафика, который передаётся через него. Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.
Политика безопасности
Политика безопасности хранится в SPD (База данных политики безопасности). SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA.
SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.
ISAKMP/Oakley
Протокол ISAKMP определяет общую структуру протоколов, которые используются для установления SA и для выполнения других функций управления ключами. ISAKMP поддерживает несколько Областей Интерпретации (DOI), одной из которых является IPSec-DOI. ISAKMP не определяет законченный протокол, а предоставляет «строительные блоки» для различных DOI и протоколов обмена ключами.
Протокол Oakley — это протокол определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает идеальную прямую безопасность (Perfect Forward Secrecy — PFS). Наличие PFS означает невозможность расшифровки всего траффика при компрометации любого ключа в системе.
IKE — протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным. IKE находится на вершине ISAKMP и выполняет, собственно, установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).
Хэш-функция — это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что H(m1)=H(m2), где H — хэш функция.
Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC — механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим её как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования — как L (L