Можно ли использовать PAP с TTLS на сервере RADIUS?
Мы развернули сервер Radius (Freeradius 3.x) и подключили его к нашей базе данных LDAP (ForgeRock OpenDJ).
Мы успешно настроил EAP-TTLS с действующими сертификатами и установил его в качестве метода подключения по умолчанию. (почти все остальные настройки оставлены по умолчанию)
Однако, когда EAP-TTLS установлен, пароль передается с использованием PAP . Я не специалист по сетям, но я читал, что PAP не защищен и не должен использоваться? ( Мне кажется, в Интернете много запутанного материала )
Если я попытаюсь войти в систему с помощью любого другого, например MS-CHAPv2, произойдет сбой с различными ошибками:
FAILED: No NT/LM-Password. Cannot perform authentication'
или
freeradius_1 | (22) eap_md5: ERROR: Cleartext-Password is required for EAP-MD5 authentication
Очевидно требует дополнительной настройки.
Вопрос в том, подходит ли нам PAP, когда у нас есть EAP-TTLS с 2019 года? Или нам стоит подумать о том, чтобы установить другой тип по умолчанию?
Наш LDAP имеет хешированные пароли (очевидно), так что у нас даже есть другой вариант? На основании этого документа , который я нашел, кажется, что это наш единственный вариант.
В этом случае при условии, что сертификат, представленный сервером, правильно подтвержден запрашивающим, конфиденциальность (защита от отслеживания) и целостность (защита от изменения) обеспечивается EAP-TLS / TLS .
Ключевым моментом здесь является то, что сертификат сервера проверен правильно. Если это не так, злоумышленник может настроить сеть-приманку, предоставить запрашивающему поддельный сертификат и получить учетные данные в виде открытого текста.
Любая организация, серьезно относящаяся к безопасности, либо внедрит EAP-TLS (устраняя необходимость в пароле). или запустите растворимый установщик (SecureW2, Cloudpath, eduroamCAT - если это для eduroam) на их беспроводных клиентах, чтобы правильно настроить параметры аутентификации 802.1X.
В прошлый раз, когда я проверял Windows 10, в частности, не реализовал никакой вид привязки сертификата / SSID, поэтому указание на то, что вы доверяете сертификату сервера во время первоначальной попытки аутентификации, фактически не добавляло никакой безопасности. Для последующих попыток аутентификации с другим сертификатом соискатель с радостью предоставит вам отпечаток нового сертификата без каких-либо указаний на несоответствие. Единственный способ исправить это - явно установить параметры проверки сертификата (доверенные центры сертификации, ожидаемый шаблон имени субъекта) для беспроводной сети, вручную или с помощью установщика с растворяемыми формами (как упоминалось выше).
Чтобы ответить на ваш другой вопрос о какие внутренние методы TTLS / PEAP будут работать с LDAP, если вы используете привязки с аутентификацией LDAPv3 для аутентификации пользователя, то да, будут работать только PAP или GTC (см. PEAPv0 / GTC). Они оба работают примерно одинаково.
Если вы извлекаете хэши и проводите сравнение локально на сервере RADIUS, и сохраняете хэш NT-Password пароля пользователя, а также любой другой хеш-код, который вы using, то это позволяет вам использовать MSCHAPv2.
Честно говоря, NT-пароли используют чрезвычайно слабое хеширование (MD4), так что это почти так же плохо, как хранение открытого текста в OpenLDAP. Вам необходимо взвесить вероятность того, что ваша установка OpenLDAP будет скомпрометирована, и риск того, что все хэши будут украдены / взломаны, и вероятность того, что кто-то проведет атаку MITM, а также риск кражи подмножества паролей.
As последнее замечание: если вы используете EAP-PWD, существует некоторая ограниченная поддержка использования хэшированных копий пароля как на сервере Supplicant, так и на сервере RADIUS, но этот метод EAP широко не поддерживается за пределами сред Linux.
Я довольно недоволен ситуацией, TBH, но для того, чтобы заставить всех принять новый метод EAP, потребуются значительные усилия со стороны нескольких поставщиков.
Единственное, что можно реализовать на стороне FreeRADIUS, - это настроить «выборочные проверки» для параметров проверки сертификатов и исправить любых пользователей, которые их не выдержали. Это можно сделать путем динамической замены сертификата, представленного соискателю, на недействительный и проверки того, что соискатель возвращает правильное предупреждение (invalid_ca) на сервер RADIUS. Это приведет к сбою аутентификации (если все работает правильно), но соискатели также будут довольно быстро повторять попытку, так что, если выборочные проверки проводятся довольно редко, это не слишком большая проблема.