The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (Безопасность)
Изначальное сообщение [ Отслеживать ]

"ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"  +/
Сообщение от Velos (ok) on 16-Авг-10, 17:26 
Доброго времени суток всем гуру. Простите чайника, если вопросы откровенно глупые.

Стоит следующая задача: реализация 2-х факторной аутентификации для Remote Access VPN.

Дано: Cisco ASA 5520 (IOS 8.0(4)), Домен AD (Win2003), CA (Win2003), FreeRADIUS (Debian), токены (rutoken).

Общая идея, которой руководствовался следующая (см. рис.):
Схема: http://velos.users.photofile.ru/photo/velos/115313786/139110...
1)    Выдаем пользователю сертификат и помещаем его на токен, без возможности экспорта закрытого ключа.
2)    Выдаем сертификат ASA-е.
3)    Создаем туннельную группу с аутентификацией peer-ов с помощью сертификатов.
4)    Настраиваем в туннельной группе аутентификацию пользователей через radius.
5)    RADIUS осуществляет ntlm-аутентификацию и авторизацию пользователя в AD.
6)    RADIUS возвращает на ASA аксесс-лист для пользователя.


Руководствовался следующими документами:
http://www.cisco.com/en/US/products/ps6120/products_configur...
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps...

В настоящий момент получилось реализовать следующее:
Аутентификация Peer-а через сертификат (Асе был выдан сертификат по микрософтовскому шаблону IPSEC, где в поле fqdn было указано её полное доменное имя.). Пользователю также выдается токен с user-сертификатом. Туннель строится, используя этот сертификат (на стороне пользователя Cisco VPN Client).

Для меня остаются не совсем ясны некоторые моменты:

1)    Сертификаты используется исключительно для аутентификации peer-ов через ЭЦП, или же открытые/закрытые ключи сторон используются для формирования разделенного секрета через алгоритм Диффи-Хеллмана?

2)     В такой схеме получается, что с помощью любого сертификата, выданного внутренним удостоверяющим центром, у которого Key Usage = Signature, возможно установить туннель. Такие сертификаты у нас распространяются в домене автоматически, и у пользователей есть возможность его экспортировать вместе с закрытым ключом. Такая возможность нарушает общую идею 2ФА. Что делать в данном случае? Насколько я понял из примеров cisco, они настраивают на ASA certificate matching rule, с помощью которого по одному из значений атрибута сертификата происходит определение пользователя в VPN-группу. Т.е. необходимо для VPN сертификатов создать отдельный шаблон с каким-нибудь зарезервированным значением какого-либо из атрибутов, и на основании этого значения создать определяющее правило на ASA? Или же есть какой-либо иной способ ограничить сертификаты, которые можно было бы использовать для аутентификации peer-а?

3)    Хотелось бы также с помощью сертификата решить проблему временного предоставления доступа: т.е. когда пользователю даётся VPN на какой промежуток времени. (Право доступа для пользователя определяется членством в AD-ой группе и наличием ACL-листа на Freeradius-е). Соответственно, если доступ предоставляется на время, возникает необходимость это где-то учитывать, чтоб потом эти права отнять. Как мне показалось, ограничивать доступ сроком действия сертификата – разумное решение. Но при ближайшем рассмотрении получается так, что срок действия сертификата в MS CA явно можно указать только в шаблоне сертификата. А есть ли возможность определять этот срок непосредственно в запросе?

4)    CRL. Изначально конфигурил асу на прошивке 7.0(5). При настройке CRL наблюдались следующие траблы: точка распространения отозванных сертификатов через http, которая была прописана в выданном устройству сертификате содержала доменное имя. ASA успешно его разрешала в IP-адрес, но наотрез отказывалась его загружать. Проблему решила назначение точки CRL вручную, где вместо доменного имени был явно прописан ип-адрес. После обновления прошивки до 8.0(4), ASA наотрез отказывается подгружать crl в любом виде. Не могу понять, с чем это может быть связано. (С других хостов данный crl успешно загружается).  

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"  +/
Сообщение от Pve1 (ok) on 17-Авг-10, 08:44 
>[оверквотинг удален]
>непосредственно в запросе?
>
>4) CRL. Изначально конфигурил асу на прошивке 7.0(5). При настройке CRL наблюдались
>следующие траблы: точка распространения отозванных сертификатов через http, которая была прописана
>в выданном устройству сертификате содержала доменное имя. ASA успешно его разрешала
>в IP-адрес, но наотрез отказывалась его загружать. Проблему решила назначение точки
>CRL вручную, где вместо доменного имени был явно прописан ип-адрес. После
>обновления прошивки до 8.0(4), ASA наотрез отказывается подгружать crl в любом
>виде. Не могу понять, с чем это может быть связано. (С
>других хостов данный crl успешно загружается).

1.) исключительно для аутентификации peer-ов

2.) Все совершенно верно. Нужен шаблон и хитрое правило.

3.) ИМХО мудрите лишнее

4.) здесь ничего не скажу.


Вопрос такой... а нафиг вам freeradius? Этож гиморой с AD дружить. Да и ntlm не оч секьюрно.   Есть же виндовый IAS, который уже интегрирован с AD?
По крайней мере на 2008R2 в NAP это делается легко. А там, как я понял - тот же IAS, немного в другой оболочке. И инфраструктура однообразной будет.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"  +/
Сообщение от Gbyte email(ok) on 17-Авг-10, 08:50 

>
>Вопрос такой... а нафиг вам freeradius? Этож гиморой с AD дружить. Да
>и ntlm не оч секьюрно.   Есть же виндовый IAS,
>который уже интегрирован с AD?
>По крайней мере на 2008R2 в NAP это делается легко. А там,
>как я понял - тот же IAS, немного в другой оболочке.
>И инфраструктура однообразной будет.

+1

я сам юниксоид, но пользуем IAS, так как не нужно интегрировать руками.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"  +/
Сообщение от Velos (ok) on 17-Авг-10, 22:02 
>[оверквотинг удален]
>>и ntlm не оч секьюрно.   Есть же виндовый IAS,
>>который уже интегрирован с AD?
>>По крайней мере на 2008R2 в NAP это делается легко. А там,
>>как я понял - тот же IAS, немного в другой оболочке.
>>И инфраструктура однообразной будет.
>
>+1
>
>я сам юниксоид, но пользуем IAS, так как не нужно интегрировать руками.
>

Ну... тут так сложилось исторически, в боевой схеме сейчас работает RADIUS, поэтому предложенное решение должно выписываться в существующую схему. Переход на IAS планируется...

Ещё вот такой вопросик по пункту 1: получается для проверки ЭЦП, peer-ы дожны что-то некий набор бит друг другу послать, чтоб затем каждая из сторон это значение зашифровав закрытым ключём, вернула обратно, а отправляющая смогла это расшифровать и сравнить с оригиналом. Это ведь так? А вот что они посылают друг другу? Или используется другая схема? Я просто не могу понять, как обладатель сертификата подтверждает владение закрытым ключем.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"  +/
Сообщение от Velos (ok) on 30-Авг-10, 23:48 
В итоге сделал на IAS :) Работает ) Правда в отличие от freeRADIUS-а, access-лист завязать получается только на AD-ой группе, а не на пользователя.

>Ещё вот такой вопросик по пункту 1: получается для проверки ЭЦП, peer-ы
>дожны что-то некий набор бит друг другу послать, чтоб затем каждая
>из сторон это значение зашифровав закрытым ключём, вернула обратно, а отправляющая
>смогла это расшифровать и сравнить с оригиналом. Это ведь так? А
>вот что они посылают друг другу? Или используется другая схема? Я
>просто не могу понять, как обладатель сертификата подтверждает владение закрытым ключем.
>

Судя по данной инфе http://www.ciscopress.com/articles/article.asp?p=24833&seqNum=5
насколько я понял происходит всё следующим образом:

1.    Клиент соединяется с ASA, peer-ы производят обмен сертификатами, которые будут использоваться для аутентификации каждой из сторон в Phase 1 IKE.
2.    ASA и клиент загружают CRL, после чего каждая из сторон проверяет подлинность сертификата противоположного peer-a.  
3.    Если сертификат каждой стороны действительный (не истек срок действия и его нет в CRL), начинается IKE Phase 1. Стороны согласуют параметры безопасности (SA): алгоритм шифрования, алгоритм хеширования и группу Диффи-Хельмана. Также происходит обмен peer ID,  которые с помощью закрытого ключа каждой из сторон подписываются. (В качестве ID выступают либо FQDN или IP-адрес каждой из сторон - или что-то ещё...). Если подпись верна – этот параметр учувствует в выработке общего сессионного ключа DH.
Так ли это? :)

Такой вопрос по-поводу xauth:
после того, как тунель будет установлен, от пользователя потребуется ввести логин и пароль. (Для тунельной группы назначен authentication-server-group).
А возможно ли избавится от этой части, взяв в качестве логина значение из сертификата?
Насколько я понял, сделать это нужно как-то так:


asa#(config)tunnel-group VPN general-attributes
asa(config-tunnel-general)# authorization-dn-attributes CN (к примеру)

Правильно ли это? Или же назначение на тунельной группе authentication-server-group однозначно предполагает аутентификацию?
Насколько я понял, фичи "pre-fill username" и "username-from-certificate", доступные в IOS 8.2(1)  всего лишь заполняют имя пользователя заранее... Но как таковую, аутнетификацию пользователя не отменяют.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"  +/
Сообщение от svetts email(??) on 23-Июн-11, 20:10 
Добрый день!
Подскажите, скорее всего вы уже разобрались=)
Поднимаю vpn на ASA 5520 + CA.
AD не учавствует на данном этапе.
Получается,что любой юзер может скачать сертификат c CA и подрубиться, пройдя local аутентификацию к ASA5520-ведь сертификаты у них одинаковые..
Существует ли возможность контролировать подключение VPNclienta с помощью центра сертификации?
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "ASA5520+MS CA - 2-х факторная аутентификация - вопросы реализац"  +/
Сообщение от Velos (ok) on 23-Июн-11, 23:28 
> Добрый день!
> Подскажите, скорее всего вы уже разобрались=)
> Поднимаю vpn на ASA 5520 + CA.
> AD не учавствует на данном этапе.
> Получается,что любой юзер может скачать сертификат c CA и подрубиться, пройдя local
> аутентификацию к ASA5520-ведь сертификаты у них одинаковые..
> Существует ли возможность контролировать подключение VPNclienta с помощью центра сертификации?

На ASA сертификаты могут использоваться только на первой фазе IKE - аутентификации peer-ов (фактически - рабочих станций, с которых строится туннель). После первой фазы - идёт аутентификация пользователя (xauth) - в Ipsec реализации циски она возможна только через ввод логина/пароля (EAP у меня по-крайней мере так и не получилось прикурить к этой конструкции). Поэтому как производится xauth - локально, через внешний сервер или вообще не производится - с т.з. использования сертификата в Phase 1 - нет никакой разницы.

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

Если Вы переживаете за то, что пользователь скачает сертификат УЦ и предоставит его - спешу успокоить - всё в порядке :)
Очень советую почитать про основы ассиметричной крпитографии вот тут:
https://rapidshare.com/files/2637983018/____________________...
Этот документ я немного подправил в своё время - в оригинале было пара опечаток на картинках. Но сам документ напсан очень простым языком и очень доступно.


Суть в том, что сам по себе сертификат не имеет никакой ценности - он наоборот создан для того, чтобы его можно было свободно и без опасений распространять всем желающим. Главное - это закрытый ключ, который соотвествует сертификату.
Т.е. когда peer устанавливает подключение с ASA с использовании сертификата - просиходит обмен параметрами DH. Точно такой же обмен производится и без использования сертификатов, разница только в том, что параметры подписываются закрытыми ключами каждой из сторон. При этом подпись будет считаться верной, в случае если ни один из сертификатов каждой стороны не отозван и выданы они удостоверяющим центром, которому доверяют оба.
Скачав сертификат УЦ - я не скачаю его закрытый ключ :) А значит не смогу подписать параметры, необходимые для генерации сессионого ключа через алгоритм DH.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру