Внедряване на концепцията за високосигурен отдалечен достъп

Продължаване на поредицата от статии по темата за организацията VPN за отдалечен достъп достъп Не мога да не споделя моя интересен опит с внедряването високо защитена VPN конфигурация. Нетривиална задача беше представена от един клиент (в руските села има изобретатели), но предизвикателството беше прието и креативно изпълнено. Резултатът е интересна концепция със следните характеристики:

1. Няколко фактора за защита срещу подмяна на крайното устройство (със строго обвързване с потребителя);
   • Оценка на съответствието на компютъра на потребителя с присвоения UDID на разрешения компютър в базата данни за удостоверяване;
   • С MFA, използвайки PC UDID от сертификата за вторично удостоверяване чрез Cisco DUO (Можете да прикачите всеки съвместим със SAML/Radius);
2. Многофакторно удостоверяване:
   • Потребителски сертификат с полева проверка и вторична автентификация срещу един от тях;
   • Логин (непроменяем, взема се от сертификата) и парола;
3. Оценяване на състоянието на свързващия хост (Поза)

Използвани компоненти на разтвора:

• Cisco ASA (VPN Gateway);
• Cisco ISE (Удостоверяване/Оторизация/Счетоводство, Оценка на състоянието, CA);
• Cisco DUO (Многофакторно удостоверяване) (Можете да прикачите всеки съвместим със SAML/Radius);
• Cisco AnyConnect (Многофункционален агент за работни станции и мобилни ОС);

Да започнем с изискванията на клиента:

1. Потребителят трябва чрез своето удостоверяване с Вход/Парола да може да изтегли клиента AnyConnect от VPN шлюза; всички необходими модули AnyConnect трябва да бъдат инсталирани автоматично в съответствие с политиката на потребителя;
2. Потребителят трябва да може автоматично да издава сертификат (за един от сценариите основният сценарий е ръчно издаване и качване на компютър), но внедрих автоматично издаване за демонстрация (никога не е късно да го премахнете).
3. Основното удостоверяване трябва да се извърши на няколко етапа, първо има удостоверяване на сертификат с анализ на необходимите полета и техните стойности, след това влизане/парола, само този път потребителското име, посочено в полето на сертификата, трябва да бъде вмъкнато в прозореца за вход Име на субекта (CN) без възможност за редактиране.
4. Трябва да се уверите, че устройството, от което влизате, е корпоративният лаптоп, предоставен на потребителя за отдалечен достъп, а не нещо друго. (Направени са няколко опции, за да се удовлетвори това изискване)
5. Състоянието на свързващото устройство (на този етап компютър) трябва да се оцени с проверка на цяла масивна таблица с изисквания на клиента (обобщаване):
   • Файлове и техните свойства;
   • Записи в регистъра;
   • OS корекции от предоставения списък (по-късно интегриране на SCCM);
   • Наличие на антивирус от конкретен производител и уместност на подписите;
   • Дейност на определени услуги;
   • Наличие на определени инсталирани програми;

Като начало предлагам определено да погледнете видео демонстрацията на получената реализация на Youtube (5 минути).

Сега предлагам да разгледаме подробностите за изпълнението, които не са включени във видеоклипа.

Нека подготвим профила на AnyConnect:

По-рано дадох пример за създаване на профил (от гледна точка на елемент от менюто в ASDM) в моята статия за настройка VPN клъстер за балансиране на натоварването. Сега бих искал отделно да отбележа опциите, които ще ни трябват:

В профила ще посочим VPN шлюза и името на профила за свързване към крайния клиент:

Нека конфигурираме автоматичното издаване на сертификат от страната на профила, като посочим по-специално параметрите на сертификата и, което е характерно, обърнете внимание на полето Инициали (I), където конкретна стойност се въвежда ръчно ТИ ГО НАПРАВИ тестова машина (Уникален идентификатор на устройство, който се генерира от клиента 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; пример е описан в статията ми за настройка VPN клъстер за балансиране на натоварването.

crypto ca trustpoint ISE-CA
 enrollment terminal
 crl configure

Ние конфигурираме разпределението по Tunnel-Group въз основа на правила в съответствие с полетата в сертификата, който се използва за удостоверяване. Профилът AnyConnect, който направихме на предишния етап, също е конфигуриран тук. Моля, имайте предвид, че използвам стойността СИГУРНА БАНК-РА, за прехвърляне на потребители с издаден сертификат към тунелна група 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 ще се използва основно за изтегляне на VPN клиента AnyConnect и издаване на потребителски сертификат с помощта на функцията SCEP-Proxy на ASA; за това имаме активирани съответните опции както в самата тунелна група, така и в свързаната групова политика AC-Изтегляне, и на заредения AnyConnect профил (полета за издаване на сертификат и др.). Също така в тази групова политика посочваме необходимостта от изтегляне ISE модул за поза.

Тунелна група SECURE-BANK-VPN ще се използва автоматично от клиента при удостоверяване с издадения сертификат в предишния етап, тъй като в съответствие с Картата на сертификата връзката ще падне конкретно върху тази тунелна група. Тук ще ви разкажа за интересни опции:

• група за вторичен сървър за удостоверяване DUO # Задайте вторично удостоверяване на DUO сървъра (Radius Proxy)
• потребителско име-от-сертификатCN # За първично удостоверяване използваме полето CN на сертификата, за да наследим данните за вход на потребителя
• вторично-потребителско-име-от-сертификат I # За вторично удостоверяване на DUO сървъра използваме извлеченото потребителско име и полетата с инициали (I) на сертификата.
• клиент с предварително попълване на потребителско име # направете потребителското име предварително попълнено в прозореца за удостоверяване без възможност за промяна
• secondary-pre-fill-username client hide use-common-password push # Скриваме прозореца за въвеждане на данни за вход/парола за вторично удостоверяване DUO и използваме метода за уведомяване (sms/push/телефон) - док за заявка за удостоверяване вместо полето за парола тук

!
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, XNUMX, XNUMX, е както следва:

Можете да проверите как точно UDID от клиента AnyConnect пристига при нас, като разгледате подробностите за клиентската сесия в ISE. По-подробно ще видим, че AnyConnect чрез механизма ACIDEX изпраща не само информация за платформата, но и UDID на устройството като Cisco-AV-PAIR:

Нека обърнем внимание на сертификата, издаден на потребителя и полето Инициали (I), който се използва за приемането му като вход за вторично MFA удостоверяване на Cisco DUO:

От страната на DUO Radius Proxy в дневника можем ясно да видим как се прави заявката за удостоверяване, тя идва с UDID като потребителско име:

От портала DUO виждаме успешно събитие за удостоверяване:

И в свойствата на потребителя съм го задал ALIAS, който използвах за влизане, на свой ред това е UDID на компютъра, разрешен за влизане:

В резултат получихме:

• Многофакторно удостоверяване на потребителите и устройствата;
• Защита срещу подправяне на потребителското устройство;
• Оценка на състоянието на устройството;
• Потенциал за повишен контрол със сертификат на домейн машина и др.;
• Цялостна отдалечена защита на работното място с автоматично разгърнати модули за сигурност;

Връзки към статии от серията Cisco VPN:

• Внедряване на ASA VPN клъстер за балансиране на натоварването
• Оптимизиране на облачни услуги в AnyConnect VPN тунел на Cisco ASA

Източник: www.habr.com