Freeipa SSL LDAP и круговой Робин DNS
Я пытаюсь задать этот вопрос таким образом, чтобы он отвечал, но часть проблемы заключается в том, чтобы знать последствия моей нынешней ситуации и, если есть проблема или технический долг, который укусит меня в дальнейшем.
Я настроил несколько IPA-серверов в настройках master и replicas.
server1: dns A запись (и имя хоста fqdn): srv1.mydomain.com
server2: dns A запись (и имя хоста fqdn): srv2.mydomain.com
сервер3: запись DNS (и имя хоста fqdn): srv3.mydomain.com
серверы имеют имена auth-a, auth-b, auth-c соответственно и используют самозаверяющий сертификат в соответствии с обычной установкой IPA.
Это работало в течение нескольких месяцев для ssh-соединений, sssd и так далее. Проблема возникла при попытке подключить приложения, которые позволяют указывать только один сервер ldap. Существуют настройки записи SRV DNS для отработки отказа, но, пытаясь заставить эти приложения работать, я также включил запись циклического перебора DNS.
Подвох в том, что этот циклический прием работает только для обычного поиска ldap, а не для ldap ssl. Однако я могу заставить работать ssl, если отключу проверку ssl-сертификата.
Итак... вопросы!
а) реально, насколько плохо отключить проверку сертификата на внутреннем сервисе? Этот ldap-сервер будет запрашиваться из локальной сети всегда. Я полагаю, что я открыт для возможной атаки MITM, но я не уверен, насколько я должен волноваться об этом. Я имею в виду, сейчас мой другой вариант не использует ssl, и это страшный соус. Чтобы выполнить атаку MITM, они уже должны быть в моей сети и иметь контроль над DNS, нет? Любой совет, который мог бы измерить эту проблему в реальных условиях, был бы полезен.
б) насколько я понимаю, чтобы действительно это исправить, мне нужно дать запись RR dns в качестве имени субъекта alt на самозаверяющем сертификате сервера (ов). Это означает, что необходимо переназначить сервер, верно? что в случае IPA означает присоединение каждого клиента к IPA для получения нового сертификата. Это не стартер, я думаю.
c) учитывая текущую ситуацию и результаты (a) и (b), что бы вы порекомендовали в качестве наилучшего способа действий, чтобы позволить приложениям, которые позволяют указывать только один ldap-сервер (и не использовать записи SRV dns в каких-либо способ) при сбое на другой сервер, если один из них выйдет из строя, и все же разрешить ldap over ssl выдавать мои сертификаты?
3 ответа
Вы должны выпустить новые сертификаты с subjectAlternitiveNames и указать запись DNS для этого имени на балансировщик нагрузки.
- А) Отключение проверки сертификата открывает вас для MITM. Преимущество состоит в том, что зашифрованный канал не может быть пассивно удален. Это больше работы для MITM зашифрованного канала, но это не намного больше. Если вы не очень цените и не работаете через беспроводной или открытый интернет (в отличие от канала VPN), то отключить проверку сертификата не очень рискованно, но не делайте этого. Правильно делать все так же просто.
- Б) Да, серверам нужно будет subjectAlternitiveName или (и не делать это) подстановочный знак subjectName. Однако FreeIPA создает свою собственную PublicKeyInfrastucture (PKI), которая означает, что у вас есть собственный самозаверяющий центр сертификации (CA), а не набор самоподписанных сертификатов. Это означает, что вам нужно только генерировать и заменять сертификаты для серверов FreeIPA (те, которые используются LDAP). Сертификат CA, используемый для подписи (это сертификат, который развернут на всех ваших машинах), остается неизменным, поэтому нет необходимости прикасаться к любым другим машинам. Кроме того, вам не нужны закрытые ключи серверов, только открытые сертификаты.
- В) Посмотрите сверху, А и Б - обоснование.
Round robin dns не обязательно даст большую доступность в случае сбоя сервера, если вы не извлекаете запись A/AAAA из dns, поскольку клиент случайным образом попытается подключиться к одному из серверов, включая отказавший. Если приложение не пытается восстановить соединение, или ему не повезло, и он получает одну и ту же запись достаточно много раз подряд, что приводит к сбою. Добавление балансировщика нагрузки вперед добавляет дополнительную сложность, но означает, что эта возможность уменьшена. Если вы довольны циклическим перебором для распределения нагрузки, я бы посмотрел, удовлетворяет ли ввод имени субъекта в сертификате клиентам ldaps или не подходит ли подстановочный знак. Предотвратить "человека посреди" также можно, запустив собственную внутреннюю PKI и развернув ее как доверенный центр сертификации на своих клиентских компьютерах. Это дает дополнительное преимущество, так как является центральным местом, где вы можете видеть сертификаты с истекшим или истекшим сроком действия, вместо того, чтобы управлять этим на каждом хосте / службе, которая имеет свой собственный сертификат.
Если все, что вам нужно, это HA, я бы сделал что-то немного упрощенное, но полезное:
Настройте кластер высокой доступности для IPA (чтобы избежать проблем - просто запустите его на виртуальной машине, где служба libvirt является защищенным процессом) и используйте этот экземпляр IPA для всех этих ограниченных приложений, в то время как другие IPA склонны к аутентификации пользователя. IPA отлично работает на KVM, я запускал довольно много примеров с нулевыми проблемами в течение многих лет