LINUX.ORG.RU
ФорумAdmin

FreeRADIUS peap-mschapv2 + удостоверение сертификата

 ,


0

1

Добрый день.

Настроил авторизацию по peap-mschapv2, нашел тривиальные атаки на него. Нашел решение как обезопаситься от этих атак. Но с вопросом как реализовать решил обратиться к вам.

Нужно настроить freeradius c проверкой сертификата его с клиента. Толкового мана не нашел, т.к. во многих случаях предлагается использовать EAP-TLS. Как это реализовать?

FreeBSD 10.1-RELEASE, FreeRADIUS 3.0.6. Если нужен конфиг сообщите.

Спасибо.


Ответ на: комментарий от thesis

В некоторых случаях точка доступа. Но насколько я понимаю, «клиент» радиуса - это посредник. А сертификаты сверяются на радиусе и машине пользователя.

pic0
() автор топика
Ответ на: комментарий от pic0

Но насколько я понимаю, «клиент» радиуса - это посредник. А сертификаты сверяются на радиусе и машине пользователя.

Вижу здесь связку «но...а», предполагающую противоречие, но противоречия не вижу. Да, под «клиентом» я и имел в виду сервис, т.е. посредник с т.з. процесса аутентификации. Да, сервис получает сертификат клиента и передает его радиусу, проверяющему его правильность.

А сертификаты сверяются на радиусе и машине пользователя.

Здесь главный и первоочередной вопрос - умеет ли точка доступа (или другой клиент) осуществлять eat+tls с радиусом. Она это точно умеет?

thesis ★★★★★
()
Ответ на: комментарий от thesis

:) Точка доступа позволяет авторизоваться на радиусе как клиент по «Secret Key». Больше ничего.

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

pic0
() автор топика
Ответ на: комментарий от thesis

Ну вот смотри.Здесь говорят снять галочку с «Проверять сертификат сервера»: Жмык!

В следующем окошке снимаем галку с «проверять сертификат сервера». Так как сертификаты у нас самосгенеренные при установке FreeRadius, Windows не сможет проверить их валидность (это будет показано чуть ниже).

pic0
() автор топика
Ответ на: комментарий от pic0

Ведь пользователь должен проверить верный ли радиус сервер

Да с какой стати? Сам же выше совершенно правильно писал - клиент радиуса это и есть точка доступа. А клиент точки доступа (т.е. юзерское приложение) про радиус и знать не знает.

Я изначально потому и неправильно прочитал сам пост, что «радиус проверяет сертификат клиента» это правильное требование, а вот «клиент проверяет сертификат радиуса» - неправильное.

thesis ★★★★★
()
Ответ на: комментарий от pic0

В чем проблема? Вы не можете нагуглить как собрать свой PKI с CA и остальной сертификационной мишурой?

hizel ★★★★★
()
Ответ на: комментарий от pic0

А я, оказывается, ламер. Понаписал херни выше.

Ладно, а в чем проблема сертификатов нагенерить? Способ тот же, что и для eap-tls и чего угодно вообще (клиентских, разве что, генерить не нужно). Разве что требования вендоклиентов к серверным сертификатам надо поискать, может там нужны специфические расширения, SubjectAltName или еще что.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от thesis

Почти решил. Нужно посоветоваться. В папке raddb есть папка certs там куча всяких сгенеренных при установке радиуса сертификатов, которые можно использоваться для тестирования. Для того чтобы сгенерить новые сертификаты для продакшена нужно использовать Makefile в папке certs. Как именно им пользоваться и что потом получится написано в README в папке certs.

Что касается уязвимостей. То в моем случае можно использовать EAP-TLS, авторизация будет проходить по сертификату. Для полноценного использования нужна дисциплина генерации и выдачи сертификатов, а также их удаления. Для того, чтобы обезопасить подключение к серверу нужно на клиенте настроить проверку сертификата сервера. Добавить корневой

ca.pem
server.pem
Сертификат сервера естественно должен быть подписан корневым, который лежит на сервере. Корневой должен быть добавлен в доверенные. Т.о. образом при подключении клиента всегда будет проверяться сервер подключения.

Не смотря на проведенные операции сервер будет принимать соединения без проверки себя.

Посоветуйте. Как можно обезопасить еще клиентов на которых проверка сертификата сервера не возможна.

Спасибо.

pic0
() автор топика
Ответ на: комментарий от pic0

Не смотря на проведенные операции сервер будет принимать соединения без проверки себя.

Шта? Зачем серверу проверять себя?

anonymous
()
Ответ на: комментарий от pic0

без проверки себя

А что такое «проверка себя»?

Как можно обезопасить еще клиентов на которых проверка сертификата сервера не возможна.

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

Самый правильный путь это сгенерить корневой сертификат и подписывать им и серверные, и клиентские сертификаты (или, как у больших пацанов, корневой -> подразделения -> клиенты/серверы). Тогда придется раздать клиентам помимо собственно клиентских сертификатов еще и корневые, зато все будет работать как положено.

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

thesis ★★★★★
()
Ответ на: комментарий от thesis
Проверять себя

Не правильно выразился. Я имел ввиду как со стороны сервера заставить клиента проверять сертификат сервера.

А что касатеся больших пацанов. Да это понятно, это круто. Но когда человек свалит ему сертификат нужно перевести в «недействительные» или просто уничтожить. Нужен немного другой подход. Тем более когда у тебя большой штат под каждого человека генерить сертиф. с ума сойти можно.

pic0
() автор топика
Ответ на: комментарий от pic0

как со стороны сервера заставить клиента

Никак, конечно.

Но когда человек свалит ему сертификат нужно перевести в «недействительные» или просто уничтожить.

Отозвать. CRL, OCSP.

Нужен немного другой подход.

Биометрия пока почему-то не распространена, а лучше ничего не придумали.

Тем более когда у тебя большой штат под каждого человека генерить сертиф. с ума сойти можно.

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

thesis ★★★★★
()
Ответ на: комментарий от thesis

Никак, конечно.

Ну вот поэтому и спрашивал.

Отозвать. CRL, OCSP.

Попытался общественно доступным языком написать

Биометрия пока почему-то не распространена, а лучше ничего не придумали.

Ну не почему-то. Штука не очень гибкая. Отпечатки пальцев можно подделать. Где-то была инструкция даже. Распознавание лица не очень точно зависит от многих факторов. Сетчатка дороговато, но алгоритмы похожи на распознавание лица. Все остальное относительно дорого и нужно с собой носить дополнительный девайс.

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

Ну да. Очень хотел обойтись без этого,т.к. PKI полезная и правильная вещь, но им нужно рулить. А заниматься этим нет особо времени.

pic0
() автор топика
Ответ на: комментарий от pic0

PKI полезная и правильная вещь, но им нужно рулить. А заниматься этим нет особо времени.

Ты разрушаешь мне мозг.
«Хочу использовать клиентские сертификаты, но нет времени ими управлять». Ну как так можно, а?
И, возвращаясь к истокам темы, что там вообще может быть за «тривиальная атака» на mschap2, который идет внутри шифрованного канала?
И до кучи, что у тебя за клиенты такие, за которых ты так волнуешься, но при этом не можешь принудить их выставить правильные настройки подключения, с проверкой сертификата сервера?

BTW, не вижу, чем PKI принципиально сложнее горы текстовых паролей. Еще и проще местами вообще. Хоть не надо гонять юзера менять пароль после создания, и думать о том, что он же обязательно возьмет «1234321», да и тот на бумажке напишет.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от thesis

Ты разрушаешь мне мозг.

Я не хотел.

«Хочу использовать клиентские сертификаты, но нет времени ими управлять». Ну как так можно, а?

Поясню. Если меня будет больше, то буду поддерживать. :)

И, возвращаясь к истокам темы, что там вообще может быть за «тривиальная атака» на mschap2, который идет внутри шифрованного канала?

Отвечу просто ссылками:
Первая
Вторая
Третья
Самая главная

И до кучи, что у тебя за клиенты такие, за которых ты так волнуешься, но при этом не можешь принудить их выставить правильные настройки подключения, с проверкой сертификата сервера?

Да клиенты самые обычные. Человек, который их администрирует задачи больше 10 кликов отправляет на аутсорс. Там вообще ппц.

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

Active Directory напомнит о смене.

pic0
() автор топика
Ответ на: комментарий от pic0

А, так это «атака на слабую конфигурацию», тогда фиг с ней. Итак, мы выделили главный вопрос темы: как принудить юзеров держать галочку «проверять сертификат сервера» включенной. Причем, все виды галочек на всех видах устройств.

На что есть только один ответ: а вот хер его знает.

Не давать создавать подключение самому юзеру и молиться о том, чтобы он не никогда не пересоздавал и не редактировал его самостоятельно. Заткнуть максимальное количество возможностей для юзера сменить настройки подключения. Или искать сторонние решения. Вот, наверное, и всё.

Active Directory напомнит о смене

И запретит написать пароль на бумажке, угу)

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от thesis

Вдруг кто-то наткнется на эту тему. Вот староватая, но все еще актуальная информация по данного рода атакам.

Клац!

pic0
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.