Задача — дать людям доступ во внутреннюю сеть конторы через Cisco Anyconnect. Для пущей безопасности добавим требование аутентификации людей учетке в Active directory и наличию сертификата. Также попытаемся сразу решить вопрос использования Anyconnect под разными ОС.
Задачу можно разделить на несколько пунктов:
- Настройка CA и выпуск сертификатов
- Настройка Active directory
- Настройка ASA
В такой же последовательности опишу решение.
I. Certificate Authority.
Мы тут всё-таки на anticisco.ru, а не на linux.org.ru, поэтому вопрос развёртывания CA позволю себе опустить Остановлюсь только на деталях.
В качестве CA используется решение на openssl, после установки и настройки рекомендуется сделать под свои нужды несколько скриптов — для выпуска сертификатов и для генерации из них контейнера типа .p12.
Что следует учесть при выпуске сертификата? Для Cisco VPN Client под MacOS было актуально, чтобы DNS Name, на которое выпущен сертификат, совпадало с именем ASA, к которой вы подключаетесь. Для Anyconnect эта практика полезна (человеку будет проще разобраться в куче сертификатов, лежащих в хранилище), но не необходима. Полезным будет также детально заполнить поля Subject, нам потом по ним сопоставлять пользователя с его профилем VPN. Я выпускаю цепочку сертификатов, делаю из них .p12. Для импорта этого контейнера на ASA следует сделать из .p12 выжимку в 64-битном формате, примерно так:
Содержимое tmp.dmp нам понадобится единожды. В дальнейшем все клиенты будут пользоваться .p12, но есть тонкий момент — клиенты под linux, им нужен не контейнер, а пара ключей. Теоретически каждый линуксоид может сам поставить себе openssl и раздербанить контейнер на составляющие двумя командами:
openssl pkcs12 -in Project01.p12 -clcerts -nokeys -out Project01.pem
Результат сохраняется в каталоги /way/to/.cisco/certificates/client/private и /way/to/.cisco/certificates/client соответственно.
Под всеми остальными системами вы просто два раза дважды щёлкаете на Project01.p12 и устанавливаете его в хранилище.
Пусть результатом наших усилий будет установленный сертификат Project01.p12 с нижеприведёнными данными. Если есть нужда разводить разные группы VPN, различать сертификаты легко, варьируя значения CN и OU.
Subject Alternative Name: DNS Name = ciscoasa.test.ru
Subject: E = admin@test.ru
CN = Project01.test.ru
OU = Project01
O = Test
L = City
S = Region
C = RU
II. Active Directory.
Поднятие и общую настройку AD я тоже опущу (technet.microsoft.com в помощь ), остановлюсь только на нужных для решения задачи деталях, их мало.
ASA должна иметь учетную запись, чтобы спрашивать всякие вещи у AD. Заведите какой-нибудь бесправный ldapauth, пароль будет лежать на asa в полуприкрытом виде.
Заведите группу, членство в которой будет разрешать человеку подключаться к VPN, пусть будет VPN_Project01.
III. Cisco ASA.
Вот мы и подошли к самому главному. Дальнейшее верно для версий 8.4(4)1 и 9.1(4).
Для начала введём общие настройки. Включим сам Anyconnect, выберем приемлемые для нас техники шифрования, укажем (у меня самоподписанный) сертификат, которым представляется ASA клиенту, перевесим ASDM с 443 порта на 8443, повесим Anyconnect на 443.
ssl encryption aes256-sha1 aes128-sha1 3des-sha1
ssl trust-point Trustpoint_Self external
ssl certificate-authentication interface external port 443
webvpn
enable external // я включаю Anyconnect только для подключений снаружи, external — имя внешнего интерфейса
no anyconnect-essentials
anyconnect enable
tunnel-group-list enable // разрешим клиенту смотреть список возможных профилей подключений
tunnel-group-map enable rules // включим возможность поиска профиля по сертификату
Какой путь проходит клиент при попытке подключения? Сначала клиент показывает установленные сертификаты. Если какой-то из показанных подходит (импортирован на ASA в нашем случае), железка ищет соответствие между ним и профилем подключения. Соответствие задаётся через certificate map, профиль подключения называется tunnel-group. Если требуемое находится, из профиля берётся информация, у какого сервера, как и что спрашивать (authentication-server-group, в нашем случае — логин-пароль в AD). Если аутентификация проходит успешно, то человека пускают в профиль и навешивают на него групповую политику, политика берётся исходя из членства в группе в AD. Если в какой-то момент наша логика даёт сбой, т.е. клиент везде аутентифицировался, но конкретную политику на него применить не выходит (map’ы криво настроили), клиент получает политику по умолчанию (default-group-policy). Я предпочитаю политику по умолчанию делать в духе deny ip any any.
Импортируем .p12 на ASA, используя ранее сделанный tmp.dmp.
JNVDdP8Eku+lKGZcCdhynzLY+A1P9mD2plXwTcU/V9h0rXLvuucnzohJo+Ej7Fv1
…
2+PRpnH6K5Qb+DvVuJqjaXV9ibw8sZcJiv7oE29X6tqy3zIn3RtPF0H392Vk68dY
quit
В перспективе будет возможно, что одна железка будет содержать разные группы VPN, а один человек сможет иметь членства в более, чем одной группе AD. Чтобы сразу пресечь возможные проблемы, будем создавать по «опросной группе» на ASA для каждой потенциальной группы VPN. Под опросной группой я подразумеваю настройки сервера aaa и соответствия ldap к политикам.
map-value — устанавливаем соответствие группы AD (VPN_Project01) к групповой политике, применяемой к подключению (GP_Project01).
ldap-login-dn и иже с ним — детали по учетке ldapauth, созданной для того, чтобы ASA могла ходить на AD. Пароль, скрытый за звёздочками, можно себе напомнить через more system:running-config.
map-name memberOf IETF-Radius-Class
map-value memberOf CN=VPN_Project01,CN=Users,DC=test,DC=ru GP_Project01 // та самая группа в AD и политика, ей соответствующая
aaa-server ldap_Project01 protocol ldap
aaa-server ldap_Project01 (local) host 192.168.0.10 // для отказоустойчивости можно добавить ещё один сервер ldap с аналогичными настройками
server-port 636 // ldaps лучше, чем ldap
ldap-base-dn OU=Managed Objects,DC=test,DC=ru // где искать учетку пользователя
ldap-scope subtree
ldap-login-password *****
ldap-login-dn ldapauth // здесь и выше — ранее упомянутая учетка ldapauth
ldap-over-ssl enable
server-type microsoft
ldap-attribute-map LDAPMap-Project01
Создадим политику по умолчанию.
group-policy GP_NO_Access attributes
banner value NO ACCESS
wins-server none
dns-server none
vpn-simultaneous-logins 0
vpn-tunnel-protocol ssl-client
default-domain value test.ru
Создаём профиль подключения, к нему будут применяться групповые политики.
tunnel-group TG_Project01 general-attributes
authentication-server-group ldap_Project01
default-group-policy GP_NO_Access
authorization-required
tunnel-group TG_Project01 webvpn-attributes
authentication aaa certificate
group-alias Project01_VPN enable
Зададим соответствие между сертификатом и профилем подключения (если показан сертификат для Project01, то идём в тоннельную группу для Project01). Условие — операции сравнения свойств сертификата, я сравниваю поля из Subject name. В данном случае смотрю, содержит ли CN слово project01. Можно использовать eq (равно) заместо co (содержит) и над другими полями. Map создан сразу в двух местах, чтобы наша конфигурация работала и в новых версиях аса, и в старых.
subject-name attr cn co project01
tunnel-group-map CM_Project01 10 TG_Project01
webvpn
certificate-group-map CM_Project01 10 TG_Project01
Для создания рабочей групповой политики нужно заранее создать некоторые детали.
Создадим блок адресов, которые ASA будет раздавать подключившимся (DHCP), отдельно создадим группу с этой подсетью, настроим правила фильтрации и список маршрутов, которые будут выдаваться клиентам (т.н. Split-tunneling). В данном примере подключившийся клиент сможет ходить в сеть проекта по ssh и в сеть с корпоративными серверами (по портам, ограниченным группой SG_2Servers). Возможно, что придётся настроить nat (не транслировать трафик из VPN).
object-group network Project01_RAS
network-object 172.31.205.0 255.255.255.0
// список маршрутов, задаётся через ACL такого формата
access-list ACL_Project01_VPN_nets extended permit ip object-group Project01_nets any
access-list ACL_Project01_VPN_nets extended permit ip object-group Servers_nets any
// ACL для фильтрации трафика
access-list ACL_VPN_filter_Project01 extended permit tcp object-group Project01_RAS object-group Project01_nets eq 22
access-list ACL_VPN_filter_Project01 extended permit object-group SG_2Servers object-group Project01_RAS object-group Servers_nets
nat (external,local) source static Project01_RAS Project01_RAS destination static Project01_nets Project01_nets
nat (external,local) source static Project01_RAS Project01_RAS destination static Servers_nets Servers_nets
Теперь мы готовы к созданию групповых политик. Ничего нового тут нет.
group-policy GP_Project01 attributes
banner value VPN for Project01
wins-server none
dns-server value 192.168.0.10 192.168.10.10
vpn-simultaneous-logins 1
vpn-filter value ACL_VPN_filter_Project01
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value ACL_Project01_VPN_nets
default-domain value test.ru
address-pools value Project01_pool
На этом всё, можно подключаться. Не забываем в клиенте убрать галку «Block connections to untrusted servers» (у нас тут самоподписки) и поставить галку «Allow LAN access when using VPN» (чтобы работал Split tunneling).
Если что-то не отрабатывает, в отладке нам помогут:
debug aaa authorization
debug webvpn 255
debug webvpn anyconnect 255
debug crypto ca 255
Если есть подозрение, что что-то не то в ASA закэшировалось, на этапе настройки можно попробовать сделать так (в рабочем окружении такое могут не оценить):
no enable external
no anyconnect enable
enable external
anyconnect enable
Метки: anyconnect, certificate, ldap
Опубликовано: Безопасность cisco
Все хорошо, за исключением того, что ASA не умеет передавать сертификат дальше на центр аутентификации (ISE, например). А как было бы здорово разбирать сертификаты там, централизованно 🙂
Я бы добавил к статье, что можно пользователя привязать к конкретной группе и запретить логиниться в левую tunnel-group без применения certificate map.
Побаиваюсь я выноса рутинных операций на отдельные сервера. Сломаются ещё, а ты тут сиди без сертификата 🙂
Не очень понял про запрет. Под такой конфигурацией пользователь в чужой профиль не пролезет.
Спасибо за статью.
Вопрос такой:
Есть ли возможность передавать поле из сертификата для проверки в AD?
Сейчас получается, что имея сертификат, я могу авторизоваться на AD под любой учеткой. Хотелось бы чтобы авторизация на AD разрешалась бы только под учеткой совпадающей с заранее определенным полем в сертификате.
Да, насколько я знаю, конечно можно. Надо сделать ldap-map в котором явно указать значение. По LDAP высасываются все атрибуты, указанные в СХЕМЕ AD, в открытом виде. Их можно даже парсером разбирать при желании.
Интересней было бы увидеть такую же статью только для роутера. Я вот дома для своих настроил для voip на 891, но хочу увидеть как у других это сделано.