Продължавайки серията статии по темата за организацията Remote-Access VPN достъпа не мога да не споделя интересен опит по разгръщане високозащитена конфигурация VPN. Задачата не е тривиална и я постави един клиент (има изобретатели в руските села), но предизвикателството е прието и креативно реализирано. В резултат се получи интересна концепция с следните характеристики:
- Няколко фактора за защита от подмяна на крайните устройства (с твърда привързаност към потребителя);
- Оценка на съответствието на компютъра на потребителя с назначеното UDID на разрешения компютър в базата за удостоверяване;
- С MFA, използваща UDID на компютъра от сертификата за вторично удостоверяване през Cisco DUO (Може да се свърже всяка SAML/RADIUS съвместима);
- Многофакторна аутентификация:
- Сертификат на потребителя с проверка на полетата и вторично удостоверяване по едно от тях;
- Логин (незаменяем, взет от сертификата) и парола;
- Оценка на състоянието на свързващото се устройство (Posture)
Използвани компоненти на решението:
- Cisco ASA (VPN шлюз);
- Cisco ISE (Удостоверяване / Авторизация / Отчетност, Оценка на Състоянието, CA);
- Cisco DUO (Многофакторна Аутентификация) (Може да се свърже всяка SAML/RADIUS съвместима);
- Cisco AnyConnect (Многоцелеви агент за работни станции и мобилни ОС);
Да започнем с изискванията на клиента:
- Потребителят трябва да има възможност да свали клиента AnyConnect от VPN шлюза, използвайки своята аутентикация Логин/Парола, всички необходими модули AnyConnect трябва автоматично да се инсталират в съответствие с политиката на потребителя;
- Потребителят трябва да има възможност за автоматично издаване на сертификат (за един от сценарията, основният сценарий е ръчно издаване и зареждане на компютъра), аз реализирах автовипуск за демонстрация (винаги може да се премахне).
- Основната аутентификация трябва да преминава в няколко етапа, първо се извършва удостоверение на сертификата с анализ на необходимите полета и техните стойности, след това логин/парола, но този път в прозореца за логин трябва да се подстави името на потребителя, посочено в полето на сертификата Subject Name (CN) без възможност за редактиране.
- Необходимо е да се уверим, че устройството, от което се извършва вход, е издаденото на потребителя за достъп до корпоративния лаптоп и не е нищо друго. (Създадени са няколко варианта, за да се удовлетвори това изискване)
- Трябва да се проведе оценка на състоянието на свързващото устройство (на този етап компютъра) с проверка на задълбочен списък с изискванията на клиента (обобщавайки):
- Файлове и техните свойства;
- Записи в регистра;
- Кръпки на ОС от предоставения списък (по-нататъшна интеграция с SCCM);
- Наличие на антивирус от определен производител и актуалност на сигнатурите;
- Активност на определени услуги;
- Наличие на определени инсталирани програми;
Първо предлагам да разгледаме задължително видеодемонстрацията на реализираното на Youtube (5 минути).
Сега предлагам да разгледаме детайлите на реализираното, които не са обхванати във видеото.
Ще подготвим профил AnyConnect:
Пример за създаване на профил (в менюто в ASDM) е споменат в моята статия за настройка на . Сега отделно искам да подчертая опциите, които ще ни трябват:
В профила ще укажем шлюза на VPN и името на профила за свързване на клиентското устройство:
Ще направим настройки за автоматично издаване на сертификат от страна на профила, посочвайки, по-специално, параметрите на сертификата и характерно, ще обърнем внимание на полето Initials (I), където ръчно е въведено конкретно значение UDID на тестовото устройство (Уникален идентификатор на устройството, генериран от клиента Cisco AnyConnect).
Тук искам да направя лирично отклонение, тъй като тази статия описва концепцията; за демонстрационни цели, тук е въведен UDID за издаване на сертификат в полето Initials на профила AnyConnect. Разбира се, в реалния живот, ако направите това, всички клиенти ще получат сертификат с еднакъв UDID в това поле и нищо няма да работи, тъй като те имат нужда от UDID, специфичен за техния компютър. За съжаление, AnyConnect в момента не поддържа замяна на поле UDID в профила за запитване на сертификат през променлива на околната среда, както прави например с променливата %USER%.
Трябва да се отбележи, че клиентът (на този сценарий) първоначално планира самостоятелно да издава сертификати с определен UDID в ръчен режим на такива Защитени компютри, което не представлява проблем за него. Обаче, за повечето от нас, желанието е автоматизация (мина така или иначе =).
И ето, что мога да предложа относно автоматизацията. Ако автоматично е нужно да се издаде сертификат с AnyConnect, динамично заместено с UDID, то съществува и друг начин, за който са необходими малко креативно мислене и сръчни ръце – ще разкажа концепцията. Първо нека да разгледаме как се формира UDID на различни операционни системи от агента AnyConnect:
- Windows — SHA-256 хеш на комбинацията от ключа в регистъра DigitalProductID и Machine SID
- OSX — SHA-256 хеш на PlatformUUID
- Linux — SHA-256 хеш на UUID на кореновия дял.
- Apple iOS — SHA-256 хеш на PlatformUUID
- Android – Вижте документа по
Съответно, ще създадем скрипт за нашите корпоративни операционни системи Windows. С този скрипт локално пресмятаме UDID по известни входни данни и формулираме заявка за издаване на сертификат, вписвайки този UDID в необходимото поле; между другото, можем да използваме и машинен сертификат, издаден от AD (добавяйки схема с двустранна аутентификация по сертификат) Множествени сертификати).
Подготвяме настройки от страна на Cisco ASA:
Създаваме TrustPoint за ISE CA сървъра, именно той ще издава сертификати на клиентите. Процедурата по импортиране на Key-Chain няма да обсъждам, примерът е описан в моята статия за настройката .
crypto ca trustpoint ISE-CA
enrollment terminal
crl configureНастройваме разпределението по Tunnel-Group на база правила в съответствие с полетата в сертификата, който се използва за аутентификация. Също така тук се настройва профилът AnyConnect, съставен от нас на предишния етап. Обърнете внимание, че използвам стойността SECUREBANK-RA, за прехвърляне на потребители с издаден сертификат в тунелната група SECURE-BANK-VPN, имайте предвид, че това поле е зададено в колоната за заявка за сертификат на профила AnyConnect.
tunnel-group-map enable rules
!
crypto ca certificate map OU-Map 6
subject-name attr ou eq securebank-ra
!
webvpn
anyconnect profiles SECUREBANK disk0:securebank.xml
certificate-group-map OU-Map 6 SECURE-BANK-VPN
!Настройваме сървърите за аутентификация. В моя случай това е ISE за първата фаза на аутентификация и DUO (Radius Proxy) като MFA.
! CISCO ISE
aaa-server ISE protocol radius
authorize-only
interim-accounting-update periodic 24
dynamic-authorization
aaa-server ISE (inside) host 192.168.99.134
key *****
!
! DUO RADIUS PROXY
aaa-server DUO protocol radius
aaa-server DUO (inside) host 192.168.99.136
timeout 60
key *****
authentication-port 1812
accounting-port 1813
no mschapv2-capable
!Създаваме групови политики и тунелни групи, както и техните помощни компоненти:
Тунелна група DefaultWEBVPNGroup ще се използва основно за изтегляне на клиент за AnyConnect VPN и издаване на потребителски сертификат с използване на функцията SCEP-Proxy на ASA, за което са активирани съответните опции както в самата тунелна група, така и в свързаната групова политика AC-Download, така и в изтегления профил на AnyConnect (полета за издаване на сертификат и т.н.). Освен това в тази групова политика посочваме необходимостта от изтегляне ISE Posture Module.
Тунелна група SECURE-BANK-VPN автоматично ще се използва от клиента при удостоверяване с предоставения сертификат на предишния етап, тъй като в съответствие с Certificate Map, връзката ще бъде поставена именно на тази тунелна група. Ще говоря за интересни опции тук:
- secondary-authentication-server-group DUO # Задаем вторичную аутентификацию на сервере DUO (Radius Proxy)
- username-from-certificate CN # Используем для первичной аутентификации поле CN сертификата для наследования логина пользователя
- secondary-username-from-certificate I # Для вторичной аутентификации на сервере DUO используем имя пользователя, извлеченное и поля Initials (I) сертификата.
- pre-fill-username client # делаем предзаполненным имя пользователя в окне аутентификации без возможности изменения
- secondary-pre-fill-username client hide use-common-password push # Прячем окно ввода логина/пароля для вторичной аутентификации DUO и используем для запроса аутентификации вместо поля пароля метод уведомления (sms/push/phone) – дока
!
access-list posture-redirect extended permit tcp any host 72.163.1.80
access-list posture-redirect extended deny ip any any
!
access-list VPN-Filter extended permit ip any any
!
ip local pool vpn-pool 192.168.100.33-192.168.100.63 mask 255.255.255.224
!
group-policy SECURE-BANK-VPN internal
group-policy SECURE-BANK-VPN attributes
dns-server value 192.168.99.155 192.168.99.130
vpn-filter value VPN-Filter
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelall
default-domain value ashes.cc
address-pools value vpn-pool
webvpn
anyconnect ssl dtls enable
anyconnect mtu 1300
anyconnect keep-installer installed
anyconnect ssl keepalive 20
anyconnect ssl rekey time none
anyconnect ssl rekey method ssl
anyconnect dpd-interval client 30
anyconnect dpd-interval gateway 30
anyconnect ssl compression lzs
anyconnect dtls compression lzs
anyconnect modules value iseposture
anyconnect profiles value SECUREBANK type user
!
group-policy AC-DOWNLOAD internal
group-policy AC-DOWNLOAD attributes
dns-server value 192.168.99.155 192.168.99.130
vpn-filter value VPN-Filter
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelall
default-domain value ashes.cc
address-pools value vpn-pool
scep-forwarding-url value http://ise.ashes.cc:9090/auth/caservice/pkiclient.exe
webvpn
anyconnect ssl dtls enable
anyconnect mtu 1300
anyconnect keep-installer installed
anyconnect ssl keepalive 20
anyconnect ssl rekey time none
anyconnect ssl rekey method ssl
anyconnect dpd-interval client 30
anyconnect dpd-interval gateway 30
anyconnect ssl compression lzs
anyconnect dtls compression lzs
anyconnect modules value iseposture
anyconnect profiles value SECUREBANK type user
!
tunnel-group DefaultWEBVPNGroup general-attributes
address-pool vpn-pool
authentication-server-group ISE
accounting-server-group ISE
default-group-policy AC-DOWNLOAD
scep-enrollment enable
tunnel-group DefaultWEBVPNGroup webvpn-attributes
authentication aaa certificate
!
tunnel-group SECURE-BANK-VPN type remote-access
tunnel-group SECURE-BANK-VPN general-attributes
address-pool vpn-pool
authentication-server-group ISE
secondary-authentication-server-group DUO
accounting-server-group ISE
default-group-policy SECURE-BANK-VPN
username-from-certificate CN
secondary-username-from-certificate I
tunnel-group SECURE-BANK-VPN webvpn-attributes
authentication aaa certificate
pre-fill-username client
secondary-pre-fill-username client hide use-common-password push
group-alias SECURE-BANK-VPN enable
dns-group ASHES-DNS
!Следващата стъпка е ISE:
Настройваме локален потребител (може да се използва и AD/LDAP/ODBC и т.н.), за опростяване създадох локален потребител в самото ISE и го назначих в полето описание UDID на компютъра от който му е позволен достъп през VPN. В случай на локална автентикация в ISE, ще бъда ограничен само до едно устройство, тъй като полетата не са много, но в независими бази за автентикация нямам такива ограничения.
Нека да погледнем политиката за авторизация, която е разделена на четири етапа на свързване:
- Етап 1 — Политика за изтегляне на агента AnyConnect и издаване на сертификат
- Етап 2 — Политика за първоначална автентикация Логин (от сертификата)/Парола + Сертификат с валидация UDID
- Етап 3 — Втора автентикация през Cisco DUO (MFA) с UDID като потребителско име + Оценка на състоянието
- Етап 4 — Крайна авторизация в състояние:
- Съответстващ;
- валидация на UDID (от сертификата + свързване с логина),
- Cisco DUO MFA;
- Автентикация по логин;
- Автентикация по сертификат;
Нека да разгледаме интересното условие UUID_VALIDATED, което проверява дали автентикираният потребител наистина е дошъл от компютър с разрешен UDID, асоцииран в полето Описание на потребителската сметка, условията изглеждат така:
Профилът за авторизация, използван на етапи 1, 2 и 3, изглежда по следния начин:
Можем да проверим как точно получаваме UDID от клиента AnyConnect, като погледнем в ISE детайлите на клиентската сесия. В детайлите ще видим, че AnyConnect чрез механизма ACIDEX изпраща не само данни за платформата, но и UDID на устройството като Cisco-AV-PAIR:
Нека обърнем внимание на издадения на потребителя сертификат и полето Initials (I), което се използва, за да го вземем в ролята на логин за втора автентикация MFA на Cisco DUO:
От страна на DUO Radius Proxy в лога ясно виждаме по какъв начин идва заявката за автентикация, тя идва с използване на UDID като потребителско име:
От страна на портала DUO виждаме успешно събитие на автентикация:
И в свойствата на потребителя имам установен ALIAS, който използвах за логин, като това е UDID на разрешения за логин компютър:
В резултат получихме:
- Многофакторна автентикация на потребителя и устройството;
- Защита срещу подмяна на устройството на потребителя;
- Оценка на състоянието на устройството;
- Потенциал за увеличаване на контрола с машинен сертификат на домейна и т.н.;
- Комплексна защита на отдаленото работно място с автоматично развиващи се модули за сигурност;
Връзки към статии от серията Cisco VPN:
Източник: habr.com
