Общий ключ ipsec


Настройка предварительного доступа к ключу для использования L2TP - Windows Server

Twitter LinkedIn Facebook Адрес электронной почты

  • Статья
  • Чтение занимает 2 мин

В этой статье описывается настройка предварительно используемого ключа для использования с протоколом туннелирования уровня 2 (L2TP).

Применяется к: Windows Server 2003
Исходный номер базы знаний: 324258

Аннотация

Чтобы использовать L2TP в Microsoft Windows Server 2003, необходимо иметь инфраструктуру открытых ключей (PKI) для выдачи сертификатов компьютера серверу виртуальной частной сети (VPN) и клиентам, чтобы можно было выполнять проверку подлинности Internet Key Exchange (IKE).

В Windows Server 2003 можно использовать предварительно используемый ключ для проверки подлинности IKE. Эта функция полезна в средах, в которых в настоящее время нет PKI, или в ситуациях, когда серверы Windows Server 2003 L2TP выполняют подключения к сторонним VPN-серверам, которые поддерживают только использование предварительно используемых ключей.

Примечание.

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

В следующих разделах описывается настройка предварительно используемых ключей как на клиенте L2TP, так и на сервере. Если вы используете операционную систему Windows Server 2003 как для клиентского, так и для VPN-сервера, выполните инструкции в обоих разделах, чтобы L2TP, использующий предварительно общий ключ, можно было работать. Если вы используете VPN-клиент Windows Server 2003 и сторонний VPN-сервер, необходимо выполнить действия, описанные в разделе "Настройка предварительного доступа к ключу vpn-клиента" этой статьи, а также настроить предопределяемые ключи на стороннее устройство.

Настройка предварительного доступа к ключу в VPN-клиенте

  1. В панель управления дважды щелкните "Сетевые подключения".

  2. В разделе "Виртуальная частная сеть" щелкните правой кнопкой мыши подключение, для которого вы хотите использовать предварительно общий ключ, и выберите пункт "Свойства".

  3. Щелкните вкладку Безопасность.

  4. Щелкните "Параметры IPSec".

    Примечание.

    Параметры IPSec могут быть затеняться, если на вкладке "Сеть" для типа VPN задано значение PPTP VPN. Предварительно используемый ключ можно настроить только в том случае, если для этого параметра задано значение L2TP IPSec VPN или automatic.

  5. Щелкните, чтобы выбрать флажок "Использовать предварительно используемый ключ для проверки подлинности ".

  6. В поле ключа введите предварительное значение ключа. Это значение должно соответствовать предварительно указанному значению ключа, введенного на VPN-сервере.

  7. Два раза нажмите кнопку ОК.

Настройка предустановки ключа на VPN-сервере

  1. Запустите оснастку маршрутизации и удаленного доступа. Для этого нажмите кнопку "Пуск", выберите пункт " Администрирование", а затем пункт " Маршрутизация и удаленный доступ".
  2. Щелкните правой кнопкой мыши сервер, который вы настроите с помощью предустановки ключа, и выберите пункт "Свойства".
  3. Щелкните Безопасность.
  4. Щелкните, чтобы выбрать флажок "Разрешить настраиваемую политику IPSec для подключения L2TP ".
  5. В поле предварительного общего доступа введите предварительное значение ключа. Это значение должно соответствовать предварительно указанному значению ключа, введенного в клиенте на основе VPN.
  6. Нажмите кнопку ОК.

Организация VPN подключения к Mikrotik (L2TP+IPSec)

Зачем

Организация VPN-подключений может использоваться в различных сценариях:

  1. Подключение удалённых клиентов к корпоративной сети (работа на дому, из командировок).
  2. Объединение сегментов локальной сети двух офисов, находящихся на удалении.

Несмотря на великое множество различных протоколов и типов VPN, применительно к Mikrotik чаще всего используется связка L2TP + IPsec, т. к. для клиентов на основе Microsoft Windows не требуется установка дополнительного программного обеспечения (в отличие от OpenVPN, например), что существенно облегчает интеграцию пользователей, не обладающих высоким навыком работы на компьютере.

Итак, настраиваем сервер и клиент L2TP + IPsec.

Шаг 1. Диапазон адресов клиентов

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

IP – Pool


Добавляем новый пул, назвав его как-нибудь примечательно, чтобы потом не затупить.

 

Шаг 2. Профиль для VPN-подключения

Следующим шагом создадим настройки профиля подключений по VPN.

PPP

Перейдём на вкладку Profiles и добавим новый профиль. Зададим имя для удобства. Не мудрствуя лукаво, я просто оставил L2TP. А также указал локальный и удалённый адреса из нашего пула (по счастливой случайности он так же называется L2TP).

Я также отметил возможность изменять максимальный размер сегмента TCP (опция Change TCP MSS). Есть подозрение, что это поможет избежать фрагментацию сегментов.

 

Шаг 3. Секреты

Под секретом в данном случае понимаются учётки VPN-юзеров. Заходим также в раздел PPP, на вкладку Secrets и под каждого пользователя создаём свой секрет.

В качестве сервиса выбираем l2tp, а в качестве профиля – созданный на шаге № 2 профиль PPP.

Создал одну учётку пока, для эксперимента. Если уж с ней получится, то и с другими по аналогии должно пойти на УРА.

Шаг 4. Запускаем сервер L2TP

Здесь просто убедимся, что у нас запущены соответствующие сервисы.  Заходим в L2TP Server и убеждаемся в наличии соответствующих настроек:

Здесь, кстати, важный нюанс – для шифрования будем использовать IPsec. Серьёзных уязвимостей протокол не имеет, поэтому этого нам будет достаточно. Нужно указать предварительный ключ – в примере на скрине это слово «ipsec». Можно придумать что-нибудь посекурнее, например «123» или «password» - каждый решает сам J

Шаг 5. Тюним IPsec

Важнячок: «из коробки» мой IPSEC глючил и не давал подключиться. Решение было такое: идём в IP – IPSEC и создаём новую группу в разделе Group. А потом на вкладке «Policies» добавить политику, указав нашу новую группу в качестве шаблона. Видимо какой-то глюк, но с ним многие сталкивались.



Шаг 6. Файрволл

На сетевом экране IP - Firewall необходимо открыть следующие порты (цепочка input - входящий): протокол udp, порты 500, 4500, 1701.


Можно уточнить правила, указав In. Interface, чтобы ожидать пакеты именно с внешнего интерфейса, а также указать конкретные Src. или Dst. адреса, но это уже будет зависеть от конкретной ситуации. Чем точнее описано правило, тем оно более "секурно", но одновременно и менее гибкое.

Соответственно, если политика по умолчанию у вас accept - то делать ничего не надо. Если drop - скорректировать правила соответствующим образом. Настройка файрволла - тема очень интересная, заслуживает отдельной статьи.

Шаг 7. Настраиваем клиента Windows

VPN-сервер настроен! Самое время настроить клиента. Делать это мы будем из операционной системы Windows 7, хотя настройки в общем-то типовые. Дополнительный софт ставить не надо.

Открываем "Центр управления сетями и общим доступом" через "Панель управления" и нажимаем кнопку "Настройка нового подключения или сети":

Тут нужно найти пункт, содержащий в сете три волшебные буквы "VPN", а именно: "Подключение к рабочему месту".

Предлагаются два варианта. Нам подходит первый - подключение через уже имеющееся Интернет-соединение. Условно говоря, поверх уже существующего канала создаётся шифрованный, прямиком "на работу".

На следующем шаге указываем IP-адрес нашего VPN-сервера (в данном случае - внешний интерфейс Mikrotik) и даём подключению хорошо читаемое имя. Я укажу наш сайт )

И вот здесь пригодится имя пользователя и пароль, которые мы создавали на этапе "секреты".

Если попытаться подключиться сейчас, то ничего хорошего не выйдет! Всё правильно, открываем свойства созданного VPN-подключения и идём на вкладку "Безопасность".

Выбираем тип VPN: L2TP IPsec, а также нажимаем на кнопку "Дополнительные параметры" и вводим предварительный ключ (ipsec)

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

Данную статью можно закончить! Оставайтесь с нами, рассмотрим и другие варианты подключений!

Соображения по поводу предварительных общих ключей IPsec

Аутентификация, шифрование, IPsec/VPNBrute-Force, IKE, IPsec, Man-in-the-Middle, Pre-Shared Key, PSK, Site-to-Site VPN, VPNJohannes Weber

Предварительно общие ключи (PSK) являются наиболее распространенным методом проверки подлинности для VPN-туннелей IPsec типа «сеть-сеть». Итак, что можно сказать о безопасности PSK? Какова его роль в сетевой безопасности? Насколько сложными должны быть PSK? Должны ли они храниться дополнительно? Что произойдет, если злоумышленник перехватит мои PSK?

Я перечисляю свои рекомендации по созданию PSK.

Предварительно общие ключи в IPsec

Следующий раздел относится только к VPN типа «сеть-сеть», а НЕ к VPN удаленного доступа.

  1. Общий ключ используется только для аутентификации, а не для шифрования! Туннели IPsec полагаются на протоколы ISAKMP/IKE для обмена ключами для шифрования и т. д. Но прежде чем IKE сможет работать, оба одноранговых узла должны аутентифицировать друг друга (взаимная аутентификация). Это единственная часть, в которой используются PSK (RFC 2409).
  2. Если с обеих сторон используются статические IP-адреса (= можно использовать основной режим), злоумышленник, у которого есть PSK, также должен подделать/перенаправить эти общедоступные адреса на себя, чтобы установить VPN-соединение. То есть: даже если у злоумышленника есть PSK, он должен подделать общедоступный IP-адрес, чтобы использовать его для аутентификации против другой стороны. Это совершенно нереально для обычных людей с обычными подключениями к интернет-провайдеру. Даже опытные хакеры должны иметь возможность внедрить фальсифицированные маршруты BGP или находиться рядом со шлюзом/маршрутизатором по умолчанию клиента.
  3. Но: Если одна удаленная сторона имеет только динамический IP-адрес, IKE должен использовать агрессивный режим для своей аутентификации. В этом сценарии хэш от PSK проходит через Интернет. Злоумышленник может выполнить офлайн-атаку методом грубой силы против этого хэша. То есть: Если PSK недостаточно сложен , злоумышленник может добиться успеха и сможет установить VPN-соединение с сетью (если он, кроме того, знает идентификаторы одноранговых VPN-узлов, что не является проблемой, поскольку они также проходят через Интернет в открытом виде).

Передовой опыт для PSK

Так как PSK должны быть настроены на каждой стороне только один раз, не должно возникнуть проблем с записью 20-40 букв на брандмауэре. Таким образом, действительно сложный ключ может быть сгенерирован и использован для аутентификации узла VPN. Вот мои советы:

  1. Создайте новый/другой PSK для каждого туннеля VPN.
  2. Используйте генератор пароля/парольной фразы для создания PSK.
  3. Создайте длинный PSK, содержащий не менее 30 символов, чтобы противостоять атаке грубой силы. (См. мою статью о сложности пароля.) Чтобы избежать проблем, использует только буквенно-цифровые символы. Поскольку PSK с 30 символами очень длинный, «маленький» набор символов, состоящий всего из 62 алфавитов и цифр, не представляет проблемы. Уровень безопасности в этом примере будет около 178 бит (начиная с ).
  4. НЕ отправляйте PSK партнеру через Интернет, , а по телефону, факсу или SMS.
  5. Нет необходимости хранить PSK где-либо еще. Если он настроен с обеих сторон, вы можете отказаться от него. В худшем случае нужно сгенерировать и передать новый.

Дополнительная литература

  • RFC 2409: Интернет-обмен ключами (IKE)
  • RFC 4301: Архитектура безопасности для интернет-протокола
  • Майкл Туманн, Энно Рей: Взлом PSK с использованием агрессивного режима IKE [PDF]
  • eTutorials: Атака на IPsec VPN

Рекомендуемое изображение: «Эрудит» Васили находится под лицензией CC BY-NC-ND 2.0.

Обмен ключами

. Для чего используется «общий секрет» в IPSec VPN?

Скорее всего, этот «общий секрет» на самом деле был «предварительно общим ключом» IKE; он используется для аутентификации двух сторон (и для IKEv1 добавляется в ключи). На самом деле он не используется в качестве ключа (и, следовательно, тот, кто узнает этот ключ, не может использовать его для прослушивания, если только он не выполнит активную атаку «Человек посередине»).

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

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

Чтобы сделать это еще более сложным, существуют две разные версии IKE (IKEv1 и IKEv2), и они используют общий ключ несколько по-разному. Поскольку я не знаю, какой из них вы используете, я перечислю, как они оба работают отдельно.

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

Вот как работает первая фаза IKEv1 (при условии, что вы используете аутентификацию с предварительным ключом и опускаете части, не относящиеся к генерации ключа):

  • Две стороны обмениваются одноразовыми номерами

  • Обе стороны выполняют обмен Диффи-Хеллмана

  • Обе стороны берут одноразовые номера, общий секрет Диффи-Хеллмана и предварительный общий ключ) и генерируют набор ключей IKE

  • Они обмениваются зашифрованными сообщениями IKE (чтобы убедиться, что оба получили одинаковые ключи IKE; если они использовали разные ключи IKE, они не будут).

Для IKEv2 эта первая фаза выглядит так:

  • Две стороны обмениваются одноразовыми номерами

  • Обе стороны выполняют обмен Диффи-Хеллмана

  • Обе стороны берут одноразовые номера, общий секрет Диффи-Хеллмана, и генерируют набор ключей IKE

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

Теперь и для IKEv1, и для IKEv2 они выполняют вторую фазу; они генерируют SA IPSec, которые являются ключами (и другими данными), используемыми для фактического шифрования трафика. Для этого они обмениваются значениями SPI и одноразовыми номерами, возможно, выполняют еще один обмен Диффи-Хеллмана и создают ключи IPSec из некоторых данных ключей IKE, значений SPI (и общего секрета Диффи-Хеллмана, если использовался алгоритм Диффи-Хеллмана).

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

И, поскольку была задействована операция Диффи-Хеллмана, кто-либо, прослушивающий трафик, не может ничего расшифровать; даже если они знают, что такое «предварительный ключ».


Learn more

Только новые статьи

Введите свой e-mail

Видео-курс

Blender для новичков

Ваше имя:Ваш E-Mail: