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

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

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

Вопрос

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

Согласно этому посту , 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 - это проект с открытым исходным кодом, и он имеет возможность написать свой собственный хук аутентификации, есть много людей, которые сделали много разных вещей, чтобы обеспечить разные уровни аутентификации.

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

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

• Используйте аппаратный токен. Закрытый ключ может быть сохранен на физическом токене и не может быть скопирован или восстановлен. (ссылка: 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-адресов. И начните оба, когда произойдет какое-то нарушение, так что Бобу придется позвонить за помощью.

Суть в том, что вы не должны быть уверены в вещах, в которых вы не уверены, и помните об этом при разработке плана обеспечения безопасности. Предположим, что всегда есть умный человек, далеко впереди вас, который не может дождаться, чтобы доказать, что вы ошибаетесь ... просто "за лулз". :-)