DAP reprezinta politicile de acces dinamic configurabile pe Cisco ASA pentru a asigura reguli de acces specific pentru utilizatorii de VPN luand in considerare alte criterii decat ip-ul acestora. Dupa cum am discutat in Tutorialul Anyconnect regulile dinamice pot fi categorisite in functie de grupul din Active Directory, alte atribute AAA sau criterii din configuratia VPN. La un moment dat o sa facem un deep dive si in DAP, dar in acest articol o sa discutam despre cum il putem folosi impreuna cu l2tp asemenea folosirii impreuna cu Anyconnect.

Clientul nostru, pana sa opteze pentru Cisco Anyconnect (pentru anul viitor posibil), doreste sa foloseasca cateva specificatii avansate de autorizare si autentificare in cadrul configuratiei de l2tp vpn. Eu stiam ca pentru a obtine ce isi doreste este obligatoriu folosirea functiei de Dynamic Access Policy din cadrul ASA. Acesta avea mai multe departamente, sa zicem HR, IT și HORECA, in care HR sa aiba acces doar la serverul de salarii, IT la tot, iar HORECA la aplicatiile lor specifice. Serverele se regaseau unele in Data Center, iar altele in sediul central. Local, departamentele sunt restrictionate prin Cisco Firepower + ACL tinand cont de subneturile sursa (retelele departamentelor) si ip-urile destinatie (serverele).

Misiunea este de a aplica aceste restrictii si pe conexiunile departamentelor prin Remote-VPN. Aici este imposibil pe baza de ip sursa, deoarece acesta se schimba dinamic si nu stim cine mai exact se conecteaza daca nu avem alte criterii de identificare. Am putea filtra dupa Group Policy, dar nu recomand, deoarece pe viitor este posibil sa se ceara filtrare per user din departament unde avem neaparat nevoie de un criteriu mult mai specific. Eu sustin intotdeauna mentinerea unei configuratii curate fara subdiviziuni ale subdiviziunilor. Este bine atunci cand configuram un Remote-access VPN sa avem un singur Group Policy unde aplicam elementele acestuia pentru a evita viitoare confuzii.

DAP are 3 tipuri de atribute AAA:

-Cisco. Contine elementele locale configurate pe ASA:

-RADIUS (server configurat in Active Directory) – incadrare pe baza de id folosind coduri RADIUS ce necesita a fi adaptate pentru ASA. De fiecare data nu a functionat. Ca si informare atributul pentru MemberOf la Radius este 146, iar ASA il vede ca 4242, deoarece il aduna cu valoarea 4096. Din pacate nu a functionat, ramane de studiat problema:

-LDAP (server configurat in Active Directory) – aici este cel mai simplu, deoarece selectam atributul direct din ASDM:

Deci, intre sediul central si DC avem un route-based ipsec cu interfete VTI pentru rutare peste acest tunel. Stiti ca pe ASA existau probleme in folosirea LDAP si VTI din cauza interfetei sursa, rezolvarea o gasiți aici. Odata rezolvat cu protocolul AAA LDAP peste tunele VTI pe ASA am putut face disponibila configuratia doar pentru Anyconnect, fiind compatibil cu LDAP pentru autentificare si autorizare, dar L2TP are o limitare specificata in tabelul de mai jos:

L2TP pe ASA este cel mai versatil in privinta protocoalelor de autentificare PPP pe RADIUS, dar pe LDAP are disponibil doar PAP, reprezentand o limitare software in cadrul device-ului ASA. Dezavantajul aparent este acela ca schimbul de pachete in timpul autentificarii ce foloseste PAP se realizeaza in cleartext (informatie inteligibila ochiului uman) lucru neconform cu politicile clientului in conformitate si cu GDPR. Problemele erau urmatoarele:

-Atributele RADIUS se identifica printr-un ID, iar pentru identificarea grupului vpn din care face parte un utilizator nu a functionat in testare. Exista documentatie insuficienta cu privire la acest subiect.
-LDAP nu functiona daca-l selectam in l2tp fara sa activez si PAP sub acesta, iar la client setand doar PAP ca metoda de autentificare.
-datele de autentificare riscau sa fie transmise in clar.

AD-ul se afla in Data Center, iar intre HQ si DC exista un tunel VPN ikev2 protejat prin algoritmul de criptare aes256-cbc. In cazul acesta, cand un user se autentifica prin l2tp va realiza acest lucru protejat de un tunel IPsec care cripteaza payload-ul si partea ce tine de autentificare din header. Prin aceasta captura din Wireshark putem observa ca traficul la pornire este prin IPsec (ISAKMP, Quick Mode, ESP):

Mai departe, traficul venit de la user ajunge la HQ si este mai departe forwardat tot sub protectia IPsec catre Data Center. Astfel, informatiile in clar specifice PAP sunt criptate printr-un extra-layer oferit de IPsec ajutandu-ne sa depasim aceasta limitare. Pe ASA o sa discutam altadata cum configuram l2tp si dap, acum vom discuta aspectele specifice ce tin de realizarea protejarii userilor l2tp-vpn prin politicile de acces dinamice. Procesul prin care realizam acest lucru este acesta:

a) Intram sub Configuration -> Remote Access VPN -> Network Client Access -> IPsec(IKEv1) Connection Profiles:

b) Editam profilul conexiunii l2tp:

c) Intram la Advanced -> PPP -> selectam si PAP:

d) Sa ne asiguram ca la Basic avem selectat server group-ul AAA de Ldap:

e) Clientul ar trebui in acest moment sa selecteze doar PAP in setarile l2tp de pe calculator:

Pentru regulile DAP trebuie sa configuram un ACL si sa-l legam de o politica de acces dinamica. Aici este simplu, alegem destinatiile dorite pentru departamentul HR/IT/HORECA, selectam in cadrul DAP grupul de AD din care fac parte si bifam acl-ul creat, dupa care aplicam si salvam configuratia. Mai jos sunt pasii:

a) Configuram ACL-ul intrand la Configuration -> Remote Access VPN -> Network Client Access -> Advanced -> ACL Manager:

b) Add -> Add ACL:

c) Dăm un nume ACL-ului și OK:

d) Il vom observa ultimul in lista de acl-uri existente. Vom da click pe el si din nou Add – Add ACE (Access Control Entry):

e) Vom scrie sursa, destinatia, actiunea asupra pachetelor, serviciul accesat de user (poate sa fie toata paleta tcp/ip, cateva sau doua unul) si faptul ca logam sau nu cand se permite sau se respinge un pachet marcat de aceasta regula:

La sursa punem any, deoarece poate fi orice ip care a fost asignat prin vpn userului. La destinaaie punem serverul pe care trebuie sa-l acceseze. La actiune selectam permit, adica sa lase traficul sa curga catre aceasta destinatie.

f) Odata creat acl-ul DAP_HR_ACL il vom aplica unei reguli dinamice de autorizare a accesului.

Configurația DAP:

a) Configuration – Remote Access VPN – Network Client Access – Dynamic Access Policies -Add:

b) Add -> completam Policy Name pentru a distinge regula de celelalte (respectand o nomenclatura evident) -> ACL Priority (este importanta atunci cand exista grupuri de vpn comune si dorim sa facem mai multe reguli, aici higher is better) -> Si o descriere:

c) La Selection Criteria ne intereseaza doar atributele AAA dupa care vom identifica specific utilizatorii/grup LDAP(AD). Selectam sa tina cont de oricare/toate/niciuna dintre atributele AAA. Noi o sa selectam ANY, deoarece vom specifica doar un singur grup:

d) Add -> AAA Attribute Type LDAP -> Attribute ID: memberOf (adica grupul de care apartine) si sub vom scrie grupul exact cum apare in AD casesensitive adica in cazul nostru cu majuscule VPN_HR:

e) Ok -> Si acum atasam acl-ul creat in sectiunea Access/Authorization policy attributes tabul Network ACL Filters (client) si adaugam regula creata:

f) Ok si aplicam configuratia. Acum ar trebui sa avem disponibila regula in l2tp vpn.

Pentru a intelege mai bine acest tutorial recomand sa recititi, pentru a aduce putin context, sub-capitolele din articolul Tutorial Anyconnect – ASA (ASDM):

  • Integrare ASA cu AD
  • Ierarhia politicilor si Dynamic Access Policy

Si pentru a intelege ce este l2tp articolul Remote access VPN – soluție pentru WFH

Articol scris de Bogdan Curduban – Network Engineer