Как запретить пользователям обмениваться сертификатами в OpenVPN?

У меня есть сервер OpenVPN, который использует сертификаты и аутентификацию LDAP.

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

Вопрос

Как мне убедиться, что сертификат Боба можно использовать только с пользователем LDAP «bob»?

linux openvpn

В соответствии с эта почта, common_name не могут быть подделаны пользователем.

Добавьте это в openvpn server.conf

script-security 2

# untrusted state
auth-user-pass-verify /etc/openvpn/scripts/check_cn_on_connect.sh via-env

/etc/openvpn/scripts/check_cn_on_connect.sh содержит

#!/bin/bash

# username and common_name must be the same to allow access.
# users are not allowed to share their cert
if [ $username != $common_name ]; then
   echo "$(date +%Y%m%d-%H%M%S) DENIED  username=$username cert=$common_name" >> /var/log/openvpn-access.log
   exit 1
fi

echo "$(date +%Y%m%d-%H%M%S) GRANTED username=$username cert=$common_name" >> /var/log/openvpn-access.log

exit 0

Обновить

Это для OpenVPN 2.1.4. В 2.2.0 они добавили много новых переменных, которые вы можете увидеть по env >> /tmp/env, где одна из этих новых переменных - отпечаток / серийный номер сертификата.

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

Я не пробовал большинство из них, просто видел, как они упоминаются в docs / blogs / maillists. Для некоторых из них могут потребоваться исправления или платная версия.

Один из основных способов - сделать вашу частную часть вашей пары ключей чрезвычайно сложной для извлечения / копирования.

Используйте аппаратный токен. Закрытый ключ может храниться на физическом токене и не может быть скопирован или получен. (ссылка: OpenVPN предлагает поддержку смарт-карт с помощью криптографических токенов на основе PKCS # 11.)
Я видел упоминания об использовании TPM, он похож на аппаратный токен, но встроен в материнскую плату. (ссылка: http://www.cs.tau.ac.il/~orkaplan/TPMWorkshop/downloads/ServerSetup.txt)
Я видел что-то в почтовом ящике, в котором упоминалось, что для ключа можно использовать хранилище сертификатов Windows. Ключи здесь могут быть помечены, чтобы их нельзя было экспортировать. (Ссылка: http://openvpn.net/archive/openvpn-devel/2004-10/msg00019.html)

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

Требовать частого обновления сертификата, поэтому скопированный сертификат нельзя использовать в течение длительного времени.
Установите на своем сервере большое количество журналов, чтобы следить за аномалиями. Если Боб обычно входит в систему только из своего дома, а затем в один прекрасный день он начинает входить в систему из Acme Inc., то вам, возможно, придется провести расследование.
Настройте многофакторную аутентификацию. Ваш сертификат считается «тем, что у вас есть». Таким образом, вы должны искать альтернативы в том, «что вы есть» или «что-то, что вы знаете». Сюда входят биометрические показатели или пароли / фразы-пароли.
Как я уже упоминал, OpenVPN обеспечивает очень гибкую аутентификацию. Это использует auth-user-pass-verify вариант. Эта опция передает предоставленные имя пользователя и пароль внешнему скрипту / программе, которая примет решение об аутентификации на основе того, что вы хотите.

Я не профессионал по безопасности, я строго отношусь к безопасности. Ваш вопрос как раз затрагивает суть ИТ-безопасности: доверие. На мой взгляд, никогда не следует думать, что Бобу можно доверять. Конечно, Боб может быть действительно хорошим парнем, которому можно доверять. Он проработал в вашей компании более 20 лет. Однако человек «Боб» совершенно не имеет отношения к вашей ИТ-инфраструктуре.

Боб использует произвольные «реле», разрешающие доступ. Реле могут быть чем угодно: паролем, сертификатом, аппаратным токеном, сканированием радужной оболочки глаза, ДНК. Это ключи, которые разрешают доступ к вашей системе. Если ваш вопрос касается проверки личности человека, использующего ключ, вероятно, единственный честный ответ - вам придется находиться в той же комнате. Во всех остальных случаях я думаю, вы не должны убеждать себя, что Боб на самом деле является Бобом и в настоящее время его не держат под дулом пистолета, пока он получает доступ. Таким образом, в плане проектирования ИТ-инфраструктуры логично не упоминать «Боб»: организация получил доступ к вашему сайту.

Поскольку вы действительно можете знать, что «сущность» получила доступ с помощью ключа, который вы передали в прошлом, правильная перспектива, вероятно, состоит в том, чтобы ограничить количество дверей, которые ключ может открыть. Чем больше ключей вы передадите, тем меньше дверей они откроют.

OpenVPN также имеет возможность разрешить только одно одновременное соединение для каждого ключа. Затем, если Алиса входит в систему с ключом Боба, когда Боб уже находится внутри, Алисе будет отказано в доступе. К сожалению, это также означает, что Боб не может войти в систему, когда Алиса вошла в систему с ключом Боба. Поэтому вам следует настроить свою систему так, чтобы она сообщала вам об одновременных попытках входа в систему с нескольких исходных IP-адресов. И запускайте оба, когда произойдет какое-то нарушение, поэтому Бобу придется позвонить за помощью.

Дело в том, что не заверяйте себя в том, в чем вы не можете быть уверены, и помните об этом при разработке плана безопасности. Предположите, что всегда есть более умный человек, впереди вас, который не может дождаться, чтобы доказать, что вы неправы ... просто «для лулзов». :-)