Что такое общий ключ ipsec
L2TP & «IPsec with pre shared key» vs MITM
В статье рассмотрены основные vpn протоколы, которые на текущий момент применимы в бизнес процессах, а также углубленно освещен вопрос использования L2TP в связке с IPsec в режиме pre shared key. На практике разобраны подходы к организации виртуальных сетей на оборудовании MikroTik и выполнен практический аудит безопасности передачи данных с позиции анализа третьими лицами исходящего трафика при возможности MITM атаки.
Vpn технологии прочно вошли не только в корпоративную среду, но и в повседневную жизнь многих IT и других специалистов в реализации рабочих и личных проектов. Если перед вторыми вопрос безопасности может вставать исключительно с исследовательским интересом, то для бизнеса важно понимать риски, связанные с эксплуатацией различных информационных процессов в задействованной инфраструктуре, слабые и сильные места, а также экономическое обоснование применяемых решений. Безопасность стоит денег, но не всегда стоит подходить к этому вопросу, как к неприступной крепости, при условии правильной оценки складывающейся ситуации.
Здесь важно не путать протоколы с сервисами vpn, которых еще больше: ExpressVPN, CyberGhost, NordVPN и т.д. Вторые по сути являются провайдерами услуг, обеспечивая доступ клиентов к собственным ресурсам с целью обхода блокировок со стороны ISP, а также анонимности серфинга в интернете. Про них сейчас речь не идет.
С вариацией протоколов определились, какой же выбрать?
Во-первых, в зависимости от того, что строим client-to-site или site-to-site, потому что GRE для первого случая не подойдет.
Во-вторых, Wireguard хоть молодой, простой и очень перспективный, но на офисном маршрутизаторе Cisco или MikroTik его не поднять пока (на stable версии ОС, для второго вендора). PPTP очень легок в настройке, однако будет либо не шифрованным, либо шифрованным протоколом MPPE, который не имеет аппаратной разгрузки, в следствие чего, многопользовательскую сеть замедлит в работе. SSTP отличный протокол, работает по TLS на 443 порту, пролезет через любой Firewall, а может даже и IDS. У некоторых вендоров, например, MikroTik, может работать по pre shared key вместо сертификата, запускается на Windows клиентах из коробки.
Из минусов: определенные танцы с бубном при настройке Linux клиентов (протокол все-таки от Microsoft) и отсутствие поддержки со стороны вендоров в аппаратной разгрузке. OpenVPN всем хорош, особенно высокой гибкостью. Можно туннелировать на L2, можно на L3, всего не перечислить. Не даром он open soft. Роутер MikroTik скоро научится работать с ним по UDP (ожидается в следующем поколении RouterOS), так как смысла в TCP нет, ведь соединение все равно проверяется во вложенном туннеле. Однако, скорее всего ваша офисная Cisco не умеет с ним работать, поэтому vpn сервер из нее не организовать.
Фактически, стандартом де-факто в корпоративной среде является протокол L2TP. Он работает на UDP, порт по умолчанию 1701. С шифрованием все хорошо, особенно наличие возможности аппаратной разгрузки IPsec. Есть вероятность, что ваш корпоративный MikroTik (несмотря на то, что он софтовый маршрутизатор) умеет шифровать IPsec на железе (смотри таблицу «Hardware acceleration» на сайте производителя ). У Cisco в этом вопросе дела обстоят еще лучше. Даже если ваш офисный роутер не умеет шифровать железом, никто кроме вас это знать не должен не будет.
Итак, подведем промежуточный итог: vpn технологии бизнесу нужны, использовать лучше всего L2TP. Закончив с затянувшейся вводной частью, перейдем непосредственно к теме статьи. Рассмотрим на примере оборудования MikroTik безопасность передачи данных в туннеле при возможности MITM атаки со стороны третьих лиц. Этот вопрос возникает в следствие того, что почти всегда в корпоративной среде используют L2TP в связке с IPsec в туннельном режиме и общим ключем для всей сети, вместо создания PKI и задействования сертификатов. Это удобно, сеть быстро разворачивается и легко обслуживается. Безопасно ли это в условиях компрометации pre shared key? Разберем на практике.
— Начнем с того, что L2TP может быть не шифрованным:
— с интегрированным в протокол шифрованием MPPE:
— с качественным внешним шифрованием от IPsec, вроде AES:
Настройка L2TP сервера осуществляется достаточно просто, активируем его и указываем тип аутентификации:
Здесь же появляется возможность сразу активировать IPsec и настроить pre shared key. Если это сделать, то общий ключ будет закреплен за всей vpn сетью и передан всем ее участникам в качестве настроечной информации. Один и тот же на всех. На самом деле, если активировать IPsec таким образом, то RouterOS автоматически создает необходимые настройки в соответствующем разделе /ip ipsec сразу после установления L2TP соединения.
Конкретно речь идет:
Автоматически созданные настройки IPsec
Очень удобно. Особенно, когда IP адреса динамические и вообще натированные. Клиентам не нужно выполнять лишние процедуры по отслеживанию их текущих значений. В RouterOS в разделе L2TP есть дополнительная настройка, определяющая общий секрет при конфигурировании в сетях Virtual Private DialUp Network протяженных соединений точка-точка между удаленным сервером PPPOE и L2TP сетью, но это к теме статьи не относиться, поэтому просто ее упомянем всуе:
Допустим, мы не хотим простого счастья и дополнительно желаем, чтобы у каждого клиента был индивидуальный сертификат вместо общего ключа (возможно, для этого в компании уже все готово). Звучит очень круто и безопасно. Нет технически не преодолимых проблем, кроме танцев с бубнами: создаем все вышеперечисленное в ручном режиме, не забываем про корректно заданные IP адреса, как со стороны сервера, так и со стороны клиентов.
Здесь нас поджидает кропотливая работа, ведь, скорее всего, адреса у клиентов меняются (и достаточно часто), кроме этого клиенты сидят за провайдорским NAT. Все это можно накрутить кастомными скриптами на RouterOS, и все будет отлично работать. Нужно ли это? Cмоделируем ситуацию, когда общий для всех pre shared key стал известен злоумышленнику, который целенаправленно хочет нам навредить. Или клиент vpn нам больше не клиент. Сразу баним его учетную запись, и теперь аутентификацию mschap2 (или какая у вас там выбрана) он не пройдет и доступ не получит:
Если каким-то чудом у него есть возможность MITM, то есть пропускать трафик через себя, то толку в этом ровно никакого нет. Весь трафик зашифрован. Выдать себя за vpn сервер другим участникам корпоративной сети тоже не удастся. В подобном нереальном сценарии аутентификацию mschap2 клиенты не пройдут, ведь их секрет известен только им и вам, разумеется:
Шифрованный трафик L2TP туннеля
Исследовательский интерес нас ведет дальше. Может все-таки что-то можно сделать с трафиком? И в результате извлечь передаваемую информацию? Попробуем дешифровать трафик в лабораторных условиях. MikroTik позволяет нам выполнить debug соединения и увидеть подробную информацию об установленной IPsec сессии:
/ip ipsec installed-sa print
Как видно, сессия установилась на 30 минут, имеются разные ключи аутентификации и шифрования. Применим их в Wireshark, после приведения шестнадцатеричных значений к корректному формату: SPI 0x0ada181b, вместо MikroTik-овского 0xADA181B, ключи начинаются со значения 0x. Если все сделано правильно, тогда трафик откроется.
Ввод данных сессии для дешифрования 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.
Настройка VPN (L2TP/IPsec) для Android, iPhone и iPad. Бесплатные серверы VPN Gate
Содержание
Настройка VPN (L2TP/IPsec) для Android
Данная инструкция демонстрирует, как подключиться к серверу ретрансляции VPN Gate с помощью L2TP/IPsec VPN клиента, встроенного в мобильную операционную систему Android.
Предварительная конфигурация
Важная информация
Для столбца L2TP/IPsec Windows, Mac, iPhone, Android No client required в списке серверов должна быть отмечена галочка, которая сообщает о поддержке настраиваемого протокола L2TP/IPsec.
Примечание
Рекомендуется использовать имя DDNS – его можно продолжать использовать, даже если соответствующий DDNS IP-адрес в будущем изменится. Тем не менее, в некоторых странах у вас не получиться использовать имя узла DDNS – в этом случае следует использовать IP-адрес.
Запуск VPN-подключения
Интернет без ограничений
Когда соединение установлено, весь сетевой трафик будет проходить через VPN-сервер. Вы также можете перейти на сайт ipinfo.io, чтобы посмотреть глобальный IP-адрес.. Вы сможете увидеть видимое из сети местоположение, которое будет отличаться от вашей фактической локации.
При подключении к VPN вы сможете посещать заблокированные веб-сайты и использовать заблокированные приложения.
Настройка VPN (L2TP/IPsec) для iPhone, iPad
Данная инструкция демонстрирует, как подключиться к серверу ретрансляции VPN Gate на iPhone / iPad с помощью L2TP/IPsec VPN клиента, встроенного в iOS.
Предварительная конфигурация
Важная информация
Для столбца L2TP/IPsec Windows, Mac, iPhone, Android No client required в списке серверов должна быть отмечена галочка, которая сообщает о поддержке настраиваемого протокола L2TP/IPsec.
Примечание
Рекомендуется использовать имя DDNS – его можно продолжать использовать, даже если соответствующий DDNS IP-адрес в будущем изменится. Тем не менее, в некоторых странах у вас не получиться использовать имя узла DDNS – в этом случае следует использовать IP-адрес.
Запуск VPN-подключения
Интернет без ограничений
Когда соединение установлено, весь сетевой трафик будет проходить через VPN-сервер. Вы также можете перейти на сайт ipinfo.io, чтобы посмотреть глобальный IP-адрес.. Вы сможете увидеть видимое из сети местоположение, которое будет отличаться от вашей фактической локации.
При подключении к VPN вы сможете посещать заблокированные веб-сайты и использовать заблокированные приложения.
IPsec VPN. Основы.
IPsec представляет из себя не один протокол, а систему протоколов предназначенную для защиты данных на сетевом уровне IP-сетей. В данной статье будет описан теория применения IPsec для создания VPN туннеля.
Введение
VPN основанный на технологии IPsec можно разделить на две части:
Первая часть (IKE) является фазой согласования, во время которой две VPN-точки выбирают какие методы будут использоваться для защиты IP трафика посылаемого между ними. Помимо этого IKE также используется для управления соединениями, для этого вводится понятие Security Associations (SA) для каждого соединения. SA направлены только в одну сторону, поэтому типичное IPsec соединение использует два SA.
Вторая часть – это те IP данные, которые необходимо зашифровать и аутентифицировать перед передачей методами, согласованными в первой части (IKE). Существуют разные протоколы IPsec, которые могут быть использованы: AH, ESP или оба.
Последовательность установления VPN через IPsec можно кратко описать как:
IKE, Internet Key Exchange
Для шифрования и аутентификации данных требуется выбрать способ шифрования/аутентификации (алгоритм) и ключи используемые в них. Задача Internet Key Exchange protocol, IKE, в этом случае сводится к распространению данных “ключей сессии” и согласованию алгоритмов, которыми будут защищаться данные между VPN-точками.
Основные задачи IKE:
IKE ведет учет соединений путем назначения каждому из них некого Security Associations, SA. SA описывает параметры конкретного соединения, включая IPsec протокол (AH/ESP или оба), ключи сессии, используемые для шифрования/дешифрования и/или аутентификации данных. SA является однонаправленной, поэтому используется несколько SA на одно соединение. В большинстве случаев, когда используется только ESP или AH, создаются только две SA для каждого из подключений, одна для входящего трафика, а вторая для исходящего. Когда ESP и AH используются вместе, SA требуется четыре.
Процесс согласования IKE проходит через несколько этапов (фаз). Данные фазы включают:
Соединения IKE и IPsec ограничены по продолжительности (в секундах) и по кол-ву переданных данных (в килобайтах). Это сделано для повышения защищенности.
Продолжительность IPsec подключения, как правило, короче IKE. Поэтому, когда заканчивается срок IPsec соединения, новое IPsec соединение пересоздается через вторую фазу согласования. Первая фаза согласования используется только при пересоздании IKE подключения.
Для согласования IKE вводится понятие IKE предложение (IKE Proposal) – это предложение того, как защитить данные. VPN-точка инициализирующая IPsec подключение отправляет список (предложение) в котором указаны разные методы защиты подключения.
Переговоры могут вестись как об установлении нового IPsec соединения, так и об установлении нового IKE соединения. В случае IPsec защищаемыми данными является тот трафик, что отправлен чрез VPN-туннель, а в случае IKE защищаемые данные – данные самих согласований IKE.
VPN-точка получившая список (предложение), выбирает из него наиболее подходящее и указывает его в ответе. Если ни одно из предложений не может быть выбрано, VPN шлюз отвечает отказом.
Предложение содержит всю необходимую информацию для выбора алгоритма шифрования и аутентификации и пр.
IKE первой фазы – согласование защиты IKE (ISAKMP Tunnel)
На первой фазе согласования VPN-точки аутентифицируют друг друга на основе общего ключа (Pre-Shared Key). Для аутентификации используются хэш алгоритм: MD5, SHA-1, SHA-2.
Однако перед тем как аутентифицировать друг друга, чтобы не передавать информацию открытым текстом, VPN-точки выполняют обмен списками предложений (Proposals), описанный ранее. Только после того как устраивающее обеих VPN-точек предложение выбрано, происходит аутентификация VPN-точка друг друга.
Аутентификацию можно осуществлять разными способами: через общие ключи (Pre-Shared Keys), сертификаты или шифрование с открытым ключом. Общие ключи являются наиболее распространенным способом аутентификации.
Согласование IKE первой фазы может происходить в одном из двух режимов: main (основной) и aggressive (агресивный). Основной режим более длительный, но зато и более защищенный. В его процесее происходит обмен шестью сообщениями. Агресивный режим происходит быстрее, ограничиваясь тремя сообщениями.
Основная работа первой фазы IKE лежит в обмене ключами Диффи-Хеллмана. Он основан на шифровании с открытым ключем, каждая из сторон шифрует аутентификационный параметр (Pre-Shared Key) открытым ключем соседа, который получив данное сообщение расшифровывает его своим закрытым ключем. Другой способо аутентификации сторон друг друга — использование сертификатов.
IKE второй фазы – согласование защиты IPsec
Во второй фазе осуществляется выбор способа защиты IPsec подключения.
Для работы второй фазы используется материал (keying material) извлеченный из обмена ключами Диффи-Хеллмана (Diffie-Hellman key exchange), произошедшего на первой фазе. На основе этого материала создаются ключи сессии (session keys), использующиеся для защиты данных в VPN-туннеле.
Если используется механизм Perfect Forwarding Secrecy (PFS), то для каждого согласования второй фазы будет использоваться новый обмен ключами Диффи-Хеллмана. Несколько снижая скорость работы, данная процедура гарантирует, что ключи сессии не зависимы друг от друга, что повышает защиту, поскольку даже если произойдет компромат одного из ключей, он не сможет быть использован для подбора остальных.
Режим работы второй фазы согласования IKE только один, он называется quick mode — быстрый режим. В процессе согласования второй фазы происходит обмен тремя сообщениями.
По окончании второй фазы, устанавливается VPN-подключение.
Параметры IKE.
Во время установления соединения используются несколько параметров, без согласования которых невозможно установить VPN-подключение.
Методы аутентификации IKE
Протоколы IPsec
IPsec протоколы используются для защиты передаваемых данных. Выбор протокола и его ключей происходит при согласовании IKE.
AH (Authentication Header)
AH предоставляет возможно аутентифицировать передаваемые данные. Для этого используется криптографическая хэш-функция по отношению к данным содержащимся в IP-пакете. Вывод данной функции (хэш) передается вместе с пакетом и позволяет удаленной VPN точке подтвердить целостность оригинального IP-пакета, подтверждая, что он не был изменен по пути. Помимо данных IP-пакета, AH также аутентифицирует часть его заголовка.
В режиме транспорта, AH встраивает свой заголовок после оригинального IP пакета.
В режиме туннеля AH встраивает свой заголовок после внешнего (нового) IP-заголовка и перед внутренним (оригинальным) IP заголовком.
ESP (Encapsulating Security Payload)
ESP протокол используется для шифрования, для аутентификации или и того, и другого по отношению к IP пакету.
В режиме транспорта ESP протокол вставляет свой заголовок после оригинально IP заголовка.
В режиме туннеля ESP заголовок находится после внешнего (нового) IP заголовка и перед внутренним (оригинальным).
Два основных различия между ESP и AH:
Работа за NAT (NAT Traversal)
Для поддержки работы за NAT была реализована отдельная спецификация. Если VPN-точка поддерживает данную спецификацию, IPsec поддерживает работу за NAT, однако существуют определённые требования.
Поддержка NAT состоит из двух частей:
NAT Traversal используется только в том случае, если обе точки поддерживают его.
Определение NAT: обе VPN-точки посылают хеши своих IP адресов вместе с UDP портом источника IKE согласования. Данная информация используется получателем, для того чтобы определить был ли изменен IP адрес и/или порт источника. Если данные параметры не были изменены, то трафик не проходит через NAT и механизм NAT Traversal не нужен. Если адрес или порт были изменены, значит между устройствами находится NAT.
Как только конечные точки определят, что необходим NAT Traversal, согласование IKE перемещаются с порта UDP 500 на порт 4500. Делается это потому, что некоторые устройства некорректно обрабатывают IKE сессию на 500 порту при использовании NAT.
Другая проблема возникает из-за того, что ESP протокол – протокол транспортного уровня и располагается непосредственно поверх IP. Из-за этого к нему не применимы понятия TCP/UDP порта, что делает невозможным подключение через NAT более одного клиента к одному шлюзу. Для решения данной проблемы ESP запаковывается в UDP дейтаграмму и посылается на порт 4500, тот же самый, который использует IKE при включенном NAT Traversal.
NAT Traversal встроен в работу протоколов, его поддерживающих и работает без предварительной настройки.