Cybersecurity Python neo4j Cyber security Bitrix Oracle database GoLang Sean D. Stuber

Похожие элементы

Исследование WireGuard

Информация о материале

Александр Мастер, Кристина Гарман 
Центр образования и исследований в области обеспечения информационной безопасности (CERIAS)
Университет Пердью, Западный Лафайет, США
Электронная почта: Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. 

Оригинальная статья: Alexander Master, Christina Garman. Center for Education and Research in Information Assurance and Security (CERIAS). Purdue University – West Lafayette, USA. https://docs.lib.purdue.edu/ceriastr/1/ 

i. введение

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

Для целей данной статьи авторы стремились провести подробный анализ реализации Wireguard VPN. Исследование включает в себя шифрование с открытым ключом, потоковый шифр, код аутентификации сообщений и функции хэширования в том виде, в каком они реализованы в общедоступных версиях WireGuard по состоянию на 2021 год. Авторы также развернули серверный и клиентский экземпляры, имитируя то, как коммерческий поставщик услуг VPN может устанавливать связь с клиентами. Код для обеих реализаций находится в открытом доступе по адресу https://github.com/smolbytes/wireguard-deployer . Цель данного исследования - осветить этот современный протокол, а также сравнить его с такими лидерами рынка, как OpenVPN и IPSec. В соответствующей презентации также рассказывается о том, как эти протоколы могут быть применены на практике.

II. ПРЕДЫСТОРИЯ

Проект WireGuard был запущен Джейсоном Доненфельдом в конце 2016 года, согласно самым ранним сообщениям на сайте https://git.zx2c4.com. Джейсон описывает, как его идея заключалась в создании замены OpenVPN и IPSec, в своем выступлении на Black Hat 2018 в казино Mandalay Bay в Лас-Вегасе [1]. В целом, протокол работает на уровне 3 модели взаимодействия открытых систем (OSI), обычно называемом сетевым уровнем. Это отличается от IPSec, который предлагает функциональность уровня 2. Команда WireGuard начала с концепции сетевого интерфейса Linux и построила свой протокол на основе этой концепции [2]. Протокол поддерживает трафик IPv4 и IPv6 вне и внутри туннеля. WireGuard использует то, что Джейсон называет "современными, консервативными" криптографическими принципами и примитивами. Он также описывает протокол как "самоуверенный", что означает, что он предоставляет точный набор шифров и механизмы обмена ключами для обеспечения работы WireGuard. Он не позволяет согласовывать или настраивать администратором базовый протокол без его фундаментальной перестройки. Команда WireGuard также уделяет особое внимание простоте и проверяемости протокола. Цель состоит в том, чтобы один исследователь или небольшая команда специалистов по безопасности могли легко провести аудит всей базы кода. Реализация WireGuard для Linux содержит менее 4000 строк кода, что значительно меньше, чем у других конкурентов в области VPN. Кроме того, модель аутентификации аналогична модели Secure Shell (SSH) и ее authenticated_keys; любой администратор, который знает, как управлять с помощью SSH, может, по крайней мере, в общих чертах понять аутентификацию WireGuard. Принципы проектирования безопасности, которым следовала команда WireGuard при разработке протокола, приведены ниже [2].

A. Принципы проектирования систем безопасности

  1. Легко поддается проверке. Реализация WireGuard в ядре Linux содержит менее 4000 строк кода и может быть проверена отдельным пользователем или небольшой командой по мере выпуска новых версий. В отличие от этого, OpenVPN содержит более 110 000 строк кода, а IPSec (при создании с использованием пакетов FORM и strongSwan) составляет более 400 000 строк кода. Это делает проверку кода особенно сложной задачей. Потенциальный недостаток этого подхода заключается в том, что протокол реализует только основную функциональность, позволяющую двум одноранговым узлам взаимодействовать друг с другом. Другие желательные функции, распространенные в технологиях VPN, такие как аутентификация по имени пользователя и паролю, должны быть реализованы поверх WireGuard или вокруг него.
  2. Простота интерфейса. Команда WireGuard предоставляет несколько вспомогательных функций, и это все, что нужно для быстрой настройки туннеля WireGuard. Конфигурации могут быть запрограммированы и автоматизированы с помощью этих функций более низкого уровня. Поскольку WireGuard по своей сути является виртуальным сетевым интерфейсом, им и входящим в него трафиком можно управлять с помощью стандартных средств операционной системы.
  3. Статические заголовки фиксированной длины. Эта функция позволяет легко отслеживать трафик WireGuard и устраняет необходимость в парсерах, поскольку заголовки пакетов WireGuard всегда будут формироваться одинаково (или отбрасываться, если они неправильно сформированы). Преимущество этого принципа в плане безопасности заключается в том, что он исключает целый класс уязвимостей синтаксического анализатора из рассмотрения при анализе протокола. Недостатком является то, что трафик легко идентифицируется при прохождении по IP-сетям. Если бы интернет-провайдер (ISP) или национальное государство захотели ограничить трафик VPN от своих пользователей, трафик WireGuard легко идентифицируется с помощью глубокой проверки пакетов, и его было бы трудно запутать.
  4. Статическое распределение и защищенное состояние. Все состояния, необходимые для работы WireGuard, выделяются во время настройки. Кроме того, память не выделяется динамически в ответ на полученные пакеты, что устраняет дополнительные классы уязвимостей, связанных с выделением памяти.
  5. Скрытность. Интересно, что проект WireGuard отчасти вдохновил Джейсона Доненфельда на разработку руткита-невидимки. Он понял, что многие методы, необходимые для скрытности, также полезны для защиты туннелей. Например, WireGuard не является "разговорным" протоколом. Если у одноранговых узлов нет связи для передачи, туннель не работает, в отличие от других технологий VPN, которые широко используют поддерживаемые сообщения. Кроме того, неподтвержденный трафик - трафик, который не соответствует соответствующему IP–адресу туннеля или связанному с ним открытому ключу, - просто отбрасывается и не подтверждается. Наконец, размещение в службе прослушивания UDP затрудняет обнаружение однорангового узла WireGuard с помощью сканирования портов, в отличие от простоты поиска служб на основе TCP в Интернете.
  6. "Надежная" криптография. Команда Wire Guard сосредоточилась на обеспечении надежного обмена криптографическими ключами, а также надежного базового симметричного шифрования для передачи данных по туннелю, что более подробно описано ниже.

III. СОПУТСТВУЮЩАЯ РАБОТА

Авторам известно о двух известных научных исследованиях, связанных с WireGuard. Первое из них - [3], которое было включено в материалы Международной конференции по прикладной криптографии и сетевой безопасности в 2018 году. В ходе исследования не удалось убедительно доказать безопасность обмена ключами без внесения небольших изменений в код и внесения определенных упрощений в их анализ. Исследование подверглось некоторой критике со стороны Джейсона Доненфельда, который объяснил, что Великобритания не может обеспечить безопасность обмена ключами. исследователи использовали более традиционную расширенную модель Канетти-Кравчика (eCK), которая основана на дополнительном раздельном обмене ключами. Авторы заявляют, что представленные атаки требуют особых возможностей от злоумышленника, и рассматривают это как препятствие для надежного обеспечения безопасности, в отличие от практической атаки.

Вторым анализом в литературе является [4], проведенный в 2019 году, в котором анализируется протокол WireGuard "как есть" с использованием модели установления аутентифицированного и конфиденциального канала (ACCE) [5]. В документе приводятся формальные доказательства корректности, секретности сообщений, прямой секретности, взаимной аутентификации, уникальности сеанса и защиты от подделки ключа для WireGuard.
Что касается практической реализации, то в открытом Интернете доступно множество руководств по настройке одноранговых узлов WireGuard в различных сценариях. Веб-сайт WireGuard [6] сам по себе является отличным ресурсом для быстрого запуска и установки на различных платформах. Многие коммерческие поставщики услуг VPN также начали внедрять WireGuard в свои платформы. Разработка авторов была задумана в первую очередь как образовательный инструмент в университетских условиях, чтобы продемонстрировать функциональность WireGuard и показать, что это может быть сделано с разумной легкостью пользователем, не имеющим большого опыта программирования.

iv. ПРОТОКОЛ

A. Криптографические примитивы

Начиная с 2021 года, Wire Guard использует следующие криптографические примитивы:
1. Структура протокола Noise Protocol
2. Кривая 25519 для обмена ключами на эллиптическую кривую Диффи-Хелмана (ECDH)
3. ChaCha20 для сеансовых ключей симметричного шифрования
4. Poly1305 для аутентификации с помощью шифрования
5. BLAKE2 для криптографического хеширования

B. Установление защищенных коммуникаций

Технический документ WireGuard, опубликованный на симпозиуме по безопасности распределенных систем NDSS 2017, представляет протокол и каждый аспект взаимодействия в мельчайших деталях [7]. Ниже приводится краткое изложение для непрофессионала, имеющего базовое представление о концепциях криптографии.

Wire Guard исходит из предположения, что два компьютера хотят безопасно взаимодействовать друг с другом по ненадежному (или иному) IP-маршруту. Пары открытых и закрытых ключей, использующие Curve25519, генерируются каждым одноранговым узлом. С помощью какого-либо другого механизма происходит обмен открытыми ключами каждого узла. Затем каждый узел назначает IP-адрес или диапазон IP-адресов, которые его партнеру разрешено использовать в туннеле WireGuard. Эти IP-адреса, как правило, являются адресами RFC1918 в зарезервированном пространстве частных IP-адресов. Они используют IP-адресацию, которая не будет конфликтовать с логической сетью на обоих концах туннеля, в какой бы среде ни находился подключенный узел. Любой узел может выступать в качестве "инициатора" или "ответчика" в любое время. Когда одноранговый узел хочет инициировать обмен данными, от инициатора к ответчику отправляется "Первое сообщение". Он включает в себя тип сообщения, несколько зарезервированных нулевых байт, адрес отправителя, временный ключ ECDH, статический открытый ключ отправителя, временную метку и два значения MAC (всего 122 байта). Предполагая, что сообщение получено, ответчик проверит, имеется ли открытый ключ отправителя. Если это так, то он генерирует "Второе сообщение" с типом сообщения (0x2), несколькими зарезервированными нулевыми байтами, адресом отправителя, адресом ответчика, временным ключом ECDH и двумя значениями MAC (в целом короче, чем исходное первое сообщение). На данный момент у обоих одноранговых узлов есть вся информация, необходимая для использования протокола Noise для генерации общего сеансового ключа ChaCha20. Функция NoiseIK в протоколе Noise Protocol использует форму "тройного D.H.", в которой сочетание сгенерированных статических открытых ключей и эфемерных ключей приводит к одноразовому шифрованию для шифрования значения сеансового ключа k, и два одноранговых узла могут начать обмен данными сразу после первого раунда выполняется транзакция по времени поездки (1-RTT). Этот обмен обеспечивает прямую секретность, поскольку раскрытие ключей или последующий взлом шифрования при обмене данными ECDH приводит к компрометации только одного сеанса, что значительно увеличивает затраты злоумышленников и предотвращает расшифровку больших сеансов, даже если они будут перехвачены и сохранены злоумышленником. Отсюда может начаться передача данных WireGuard, и каждый узел сможет получать доступ к ресурсам с другой стороны туннеля, как если бы он был подключен к этому пространству широковещательной сети. Сообщения с открытым текстом будут зашифрованы интерфейсом WireGuard, перенаправлены из внешнего сетевого интерфейса на его одноранговый узел, пройдут через внешний интерфейс его однорангового узла и будут расшифрованы в интерфейсе WireGuard на принимающей стороне [7].

V. РЕАЛИЗАЦИЯ

В то время как в документации WireGuard каждый узел называется равноправным, в нашей реализации мы называем его клиентом или сервером. Целью нашего сценария является моделирование топологии сети типа "звезда", состоящей из центрального доверенного сервера, к которому один или несколько клиентов могут подключаться и направлять свой IP-трафик. Мы имитируем работу коммерческого VPN-провайдера, предоставляя доступ к общим сетевым ресурсам, позволяя клиентам управлять распределением исходящего трафика во время использования Интернета. Сервер предназначен для работы на CentOS, в то время как клиент в настоящее время поддерживает настольные Linux-среды Ubuntu, Debian и Fedora. Ознакомиться с обоими версиями можно в свободном доступе по адресу [8].

Серверный скрипт "wireguard-server-deployer.sh" выполняет основную часть работы в сценарии. Во-первых, он обновляет системные пакеты и обеспечивает установку необходимых зависимостей для инструментов WireGuard. Протокол реализован в ядре Linux версии 5.6 и выше, но вспомогательные функции от команды WireGuard доступны в виде отдельных пакетов в различных репозиториях. Затем скрипт генерирует каждый набор пар закрытых и открытых ключей, один набор для сервера и один для клиента. Они представлены в виде 44-символьных строк в кодировке base64. Затем скрипт настраивает WireGuard интерфейс на сервере, используя сгенерированные ключи, а также IP-адреса, разрешенные для клиентов, и конкретные значения портов для службы прослушивания UDP, которые могут быть указаны. Далее скрипт включает конфигурацию WireGuard как службу, чтобы интерфейс сохранялся после перезагрузки сервера. После этого хост-демон брандмауэра настраивается таким образом, чтобы разрешить трафик по SSH для администрирования сервера и UDP-порт для внешнего прослушивания WireGuard. Маскировка IP-адресов также включена в брандмауэре. Затем в операционную систему вносятся изменения, позволяющие использовать IP-переадресацию на IPv4 и IPv6, поскольку этот сервер будет выполнять функцию перенаправления клиентского трафика. Наконец, скрипт отображает информацию, необходимую клиенту для успешного подключения.

Отдельно пользователь может запустить клиентский скрипт "wireguard-client-setup.sh" на клиенте по своему выбору. Первоначально скрипт запросит необходимую информацию: открытый ключ сервера WireGuard, внешний IP-адрес сервера, UDP-порт сервиса (или значение по умолчанию) и закрытый ключ клиента. Эта информация доступна в нижней части выходных данных серверного скрипта. Клиентский скрипт возьмет закрытый ключ клиента, введенный пользователем, и выведет из него свой собственный открытый ключ. Затем он настроит интерфейс WireGuard, указав сервер в качестве доступного однорангового узла. Затем он откроет интерфейс WireGuard и отправит "Первое сообщение", устанавливающее безопасный туннель. Наконец, он настраивает правила iptables таким образом, чтобы весь трафик IPv4 (0.0.0.0/0) проходил через туннель WireGuard с точки зрения маршрутизации. Теперь клиент может свободно просматривать Интернет, сканировать объекты, обнаруживающие ошибки, или проводить исследования, не опасаясь, что трафик поступает из его дома, общественной точки доступа Wi-Fi и т.д. - знать, что трафик зашифрован, по крайней мере, на протяжении "первой мили" по направлению к намеченному пункту назначения.

VI. ЗАКЛЮЧЕНИЕ

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

Протокол WireGuard обладает многими преимуществами, в том числе высокой секретностью, простотой аудита и внедрения, высокой производительностью и минимальной уязвимостью для атак. Этот протокол потенциально может стать основой для создания множества различных систем. Такие проекты, как Tailscale, демонстрируют, как WireGuard можно использовать в качестве основы для более крупных программных платформ [9]. WireGuard может помочь в интеграции механизмов шифрования в другие системы, которые в противном случае могли бы передаваться в открытом виде.

У протокола также есть ограничения. Если интернет-провайдер или государственный субъект хотят заблокировать трафик на основе VPN в обход цензуры, WireGuard в настоящее время отсутствует. Учитывая особенности формата обмена данными WireGuard и форматирования зашифрованного трафика, трафик WireGuard легко обнаруживается с помощью глубокой проверки пакетов (DPI) и впоследствии отфильтровывается. Активные и пассивные локальные злоумышленники могут легко наблюдать за использованием WireGuard. Еще одна интересная дилемма возникает, если закрытый ключ партнера был скомпрометирован (или взломан в постквантовом контексте). Несмотря на сохранение секретности при пересылке, личность пользователя (-ов), с которым (-ами) кто-либо общался, будет раскрыта. В некоторых случаях это может вызывать беспокойство.

В настоящее время WireGuard также использует ChaCha20Poly1305 для симметричного шифрования, которое на момент написания этой статьи не поддерживало аппаратные инструкции по шифрованию. Это является недостатком для крупномасштабных вычислительных систем, которые в противном случае выиграли бы от реализаций, использующих AES-NI. Однако, напротив, использование WireGuard может принести пользу вычислительному оборудованию с низким ресурсом (например, устройствам для Интернета вещей), учитывая его зависимость от ChaCha20. И, наконец, вызывает беспокойство проблема "роуминга". WireGuard позволяет одноранговым узлам перемещаться, например, выходить из сети и получать новый IP-адрес в случае использования мобильного устройства, и поддерживать туннель без повторной аутентификации. Это может привести к проблемам со злоумышленниками, которые будут воспроизводить трафик с законных устройств. Однако временная метка, указанная при отправке сообщения, "сбрасывает" связь, и самая свежая из доступных временных меток выигрывает в порядке приоритета. Наряду с тем фактом, что трафик WireGuard пересматривается каждые две минуты, эти функции должны устранить большинство проблем, связанных с роумингом.

Для будущей работы авторов над внедрением WireGuard потребуется более надежный метод обмена ключами, чтобы коммерциализировать VPN как услугу. Хотя считается, что копирование закрытого ключа клиента через SSH-терминал является безопасным методом, платящие клиенты не будут иметь доступа к VPN-серверу через shell. Пользователям потребуется другой безопасный "внеполосный" метод для получения своего закрытого ключа (или запроса нового статического ключа для отдельного устройства). Текущая реализация также направляет трафик IPv4 только через туннель. Учитывая неизбежность внедрения IPv6 (и тот факт, что оба они в настоящее время совместимы в Интернете в том виде, в каком мы его знаем сегодня), возможно, было бы разумно настроить туннели на использование IPv6 по умолчанию и разрешить пользователям вносить изменения по мере необходимости в соответствии с существующими обстоятельствами.

VII. ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ

Взгляды, представленные здесь, принадлежат исключительно авторам и не отражают точку зрения Университета Пердью, а также не подразумевают одобрения Министерством обороны.

Рекомендации 

Добавить комментарий
Защитный код
Обновить

Архивные материалы