🥇 Реализация на концепцията за високо защитен отдалечен достъп

Продължавайки серията статии по темата за организацията 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 Load-Balancing клъстера. Сега искам отделно да подчертая онези опции, които ще са ни необходими:

В профила ще зададем 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 на root партицията.
Apple iOS — SHA-256 хеш PlatformUUID
Android – Виж документа по връзката

Съответно, изработваме скрипт за нашите корпоративни ОС Windows, с който локално изчисляваме UDID на базата на известни входни данни и формулираме заявка за издаване на сертификат, вписвайки този UDID в необходимото поле, между другото, може да се използва и машинен сертификат, издаден от AD (добавяйки двойна аутентификация с сертификат) Multiple Certificate).

Подготвяме настройки от страна на Cisco ASA:

Създаваме TrustPoint за ISE CA сървър, именно той ще издава сертификати на клиентите. Процедурата по импортиране на Key-Chain няма да я разглеждам, примерът е описан в моята статия за настройка VPN Load-Balancing клъстера.

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, връзката ще бъде установена точно с тази тунелна група. Ще разкажа за интересни опции тук:

втора група сървъри за удостоверяване DUO # Задаем вторичную аутентификацию на сервере DUO (Radius Proxy)
потребителско име от сертификата CN # Используем для первичной аутентификации поле CN сертификата для наследования логина пользователя
второ потребителско име от сертификата I # Для вторичной аутентификации на сервере DUO используем имя пользователя, извлеченное и поля Initials (I) сертификата.
предварително попълване на потребителското име клиент # делаем предзаполненным имя пользователя в окне аутентификации без возможности изменения
второ предварително попълване на потребителското име клиент скрий използвай обща парола 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 и назначих в полето description 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

Реализация на концепция за високо защитен дистанционен достъп