Аутентификация пользователя WireGuard

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

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

сервер

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

клиента

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

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

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

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

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

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

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

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

Например (в Linux),

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

  AuthenticationMethods "publickey,keyboard-interactive"

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

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

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

1. SSH к удаленному узлу
2. после успешной аутентификации активируйте соединение 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-адресам (а также потенциального решения проблемы «Roaming Mischief»). определено как Известное ограничение в Wireguard)

Недостаток:

• Вы только что выставили SSH в открытый доступ в Интернет :o
• Все остальное здесь не описано

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