VPN sertifikāts neaizsargā LDAP posmu

VPN pieteikšanās, kas pārbauda akreditācijas datus direktorijā, ietver divus atsevišķus tīkla savienojumus. Lietotāja savienojums ar vārteju ir aizsargāts ar paša VPN sertifikātu un protokola konfigurāciju. Vārtejas savienojums ar direktoriju ir cita sesija ar saviem TLS iestatījumiem, savu uzticēšanās krātuvi un saviem atteices režīmiem. Nekas pirmajā negarantē neko par otro.

Šī asimetrija ir mehānisms aiz pieteikšanās, kas izskatās šifrēta un tomēr sūta bind paroli atklātā tekstā.

Divi savienojumi, divi uzticēšanās lēmumi

Ārējā sesija ir tas, ko lietotājs redz: sertifikāts, kas piesaistīts VPN resursdatora nosaukumam, klienta validēts un pārvadā autentifikācijas apmaiņu. Iekšējā sesija pieder direktorijas klientam vārtejas iekšienē, kas atver savu savienojumu un vai nu vienojas par TLS, vai nē. Katra puse validē sarunu biedru, ar kuru runā, izmantojot materiālu no citas konfigurācijas datnes. Nepareizi konfigurēta iekšējā daļa paliek neredzama no lietotāja puses, jo ārējā daļa darbojas tieši tā, kā paredzēts.

Tāpēc atteice ir klusa, nevis skaļa. Vārteja, kas nekad nepārbauda direktorijas sertifikātu, joprojām autentificē lietotājus pareizi; tā vienkārši autentificē tos pa kanālu, kuru nav pārbaudījusi.

StartTLS un LDAPS, apzināti izvēlēti

StartTLS atveras kā vienkāršs LDAP un tiek jaunināts uz vietas, parasti portā 389. LDAPS sāk TLS kopā ar savienojumu, parasti 636. Abi ir likumīgi, un adapterim jāatbilst tam, ko direktorija piedāvā. Pieprasīt StartTLS ir kas cits nekā to izmēģināt un turpināt, kad jaunināšana neizdodas, un tieši šajā atšķirībā bind parole var izplūst. Konfigurējiet stingro režīmu un nepieļaujiet neaizsargātu rezerves ceļu parolei bind.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ opcija ir visa būtība: vaicājums neizdodas, nevis klusi turpinās bez jaunināšanas. Šīs rindas nosaukumi un konti ir piemēri. OpenLDAP TLS dokumentācija aptver uzticēšanās iestatījumus aiz tā.

Kuru uzticēšanās krātuvi lasa LDAP klients?

OpenLDAP klienta bibliotēka lasa savu uzticēšanās konfigurāciju, vai nu no sistēmas datnes, vai no spraudnim raksturīga iestatījuma. VPN CA direktīva attiecas uz VPN vienaudžiem un nav pierādījums, ka LDAP bibliotēka lasa to pašu datni. Izmantojiet direktorijas resursdatora nosaukumu, ko sertifikāts patiešām aptver, kopā ar izdevēja ķēdi, kurai bibliotēka uzticas. Active Directory vidē izvietojiet direktorijas pakalpojuma sertifikātu ar pareizu servera autentifikācijas lietojumu, nevis spriediet pēc parādītā nosaukuma.

Katram failover galamērķim jāatbilst tai pašai identitātes politikai. Vide, kurā primārais ir validēts, bet sekundārais nav, ir sliktāka nekā vide bez failover, jo vājākais ceļš tiek atklāts tikai pārtraukuma laikā.

Bind konts paliek atsevišķa problēma

Transporta aizsardzība nesamazina to, ko bind konts drīkst darīt. Direktorijas meklēšanas tvērums, grupu autorizācija un pakalpojuma konta privilēģijas ir atsevišķi lēmumi, un plašs bind konts paliek plašs arī pēc TLS iespējošanas. Izmantojiet šaurāko pakalpojuma kontu un meklēšanas bāzi, kas integrācijai nepieciešama, un reģistrējiet galapunktu, TLS režīmu, uzticēšanās īpašnieku un atjaunināšanas procesu kopā ar VPN konfigurāciju.

Kad parādās sertifikāta neatbilstība, izvietojiet pareizo sertifikātu vai ķēdi. Validācijas izslēgšana pārvērš redzamu neatbilstību neredzamā un atstāj otro uzticēšanās attiecību nepārbaudītu.

Divi savienojumi, divi īpašnieki, divi atjaunināšanas datumi. To nošķiršana dokumentācijā ir tas, kas uztur pieteikšanos godīgu.