Проверка подлинности пользователя WireGuard

Каждая сторона туннеля имеет собственный сгенерированный ключ и производный открытый ключ (определяемый как "узел" на другой стороне соединения). Чтобы действовать так, как вы пишете, вы должны делиться секретным ключом между "клиентами", что является худшим вариантом, который вы можете сделать (технически вы можете это сделать, но я надеюсь, что никто даже не подумает об этом).

Давайте подумаем о ролях "клиент против сервера".

сервер

• собственный секретный ключ
• список всех возможных пиров / пользователей
  • каждый клиент представлен собственным одноранговым определением на стороне сервера с соответствующим открытым ключом клиента

клиент

• собственный секретный ключ
• одноранговое определение с открытым ключом сервера

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

• Предоставление доступа новому клиенту означает добавление определения однорангового узла на стороне сервера (может быть реализовано без перезапуска VPN / без прерывания всех текущих сеансов vpn).
• Отмена доступа для текущего клиента означает удаление определения однорангового узла на стороне сервера (опять же, это можно сделать также без перезапуска VPN - закрытие всех текущих сеансов).

Если я правильно понял ваш вопрос, эта "особенность" присутствует в wireguard из коробки без каких-либо расширений.

Продолжая тему предложения @Securez, как насчет объединения чего-то вроде SSH с Wireguard? Идея здесь заключается в том, что SSH предоставляет желаемую службу «аутентификации», а Wireguard обеспечивает безопасный туннель после успешной аутентификации узла.

Например (в Linux-системе):

• настроить SSH для включения нескольких методов аутентификации, например

  AuthenticationMethods "publickey,keyboard-interactive"

• затем реализуйте комбинацию открытого ключа + пароля + аутентификации TOTP для SSH, используя что-то вроде oathtool (это также может включать аутентификацию на основе LDAP или любую комбинацию нескольких методов аутентификации, поддерживаемых SSH, но обязательно включая аутентификацию на основе ключей)

• затем настройте вызов сценария, который на основе входа пользователя в SSH добавляет узел в Wireguard (при необходимости также открывается порт WG для IP-адреса пользователя на брандмауэре, например iptables)

Затем пользователь подключается следующим образом (может быть автоматизировано с помощью простого скрипта):

1. SSH к удаленному узлу
2. после успешной аутентификации отключите SSH и активируйте соединение Wireguard

Задание cron можно запланировать для проверки времени, прошедшего с момента последнего рукопожатия для каждого активного узла, и, если время превышает указанный интервал, например 180 секунд (это означает, что узел больше не подключен), исключить узел (и, если применимо, , закройте порт брандмауэра).

Если вам не нужно, чтобы подключающийся пользователь мог подключаться к удаленному узлу по SSH, вы можете установить оболочку пользователя на/sbin/nologin. Кроме того, чтобы вызвать скрипт/etc/ssh/sshrcчтобы иметь возможность добавить узел в Wireguard, скрипту потребуется доступ к sudo. Этот риск можно ограничить с помощью чего-то вроде следующего:/etc/sudoers:

%wireguard-users ALL=NOPASSWD: /path/to/add-wg-peer

гдеwireguard-users— это группа, в которую вы можете добавить всех пользователей Wireguard. В идеалеadd-wg-peerсценарий не должен принимать никаких параметров, чтобы ограничить неправильное использование.

Преимущества такой установки:

• Использование проверенных, проверенных, готовых компонентов.
• Комбинация открытого ключа + пароля + TOTP удовлетворяет требованиям a. что-то, что вы знаете, и б. что-то, что у вас есть, что может снизить риск получения несанкционированного доступа скомпрометированным узлом
• Если реализована функциональность брандмауэра, поверхность атаки дополнительно уменьшается за счет ограничения доступа Wireguard авторизованными IP-адресами (а также потенциально решает проблему «роуминга», идентифицированную как известное ограничение в Wireguard ).

Нижняя сторона:

• Вы только что открыли доступ к SSH общедоступному Интернету :o
• Все остальное, что здесь не описано

Мысли, наблюдения, критика? Мне действительно интересно услышать, к каким подводным камням может привести такая установка.

Как говорит @Kamil, концепция Wireguard немного отличается от других решений VPN, я также начал использовать ее не так давно, и если вы хотите реализовать что-то, что использует существующую аутентификацию, вы можете получить то, что я вижу в некоторых проектах:

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

Все это, конечно, можно автоматизировать на стороне клиента.