Vispirms EAP metode: kādu paroles jaucējvērtību VPN var izmantot
VPN pārbauda noslēpumu, nevis tīmekļa jaucējvērtību. Izlasiet metodi un pēc tam pārbaudiet, ko glabā krātuve, pirms solāt, ka tie paši ieejas vārdi turpinās strādāt.
Daudzām komandām ir strādājoša tīmekļa pieteikšanās un VPN, kas noraida katru ieejas vārdu no tās pašas tabulas. Tīmekļa lietotne salīdzina jaucējvērtību, ko tā pati aprēķinājusi, bet tunelis lūdz klientu pierādīt noslēpuma turējumu tā, lai serveris to varētu pārbaudīt. Tās ir atšķirīgas prasības pret glabāto materiālu. Tieši šajā starpā esošajā plaisā lielākā daļa šādu projektu iestrēgst.
Vispirms metode, tad shēma
Pierakstiet, kādu pierādījumu prasa izvēlētā metode, pirms skatāties jebkuru shēmu. Izaicinājuma un atbildes metodei vajadzīgs materiāls, no kura serveris var aprēķināt gaidāmo atbildi, kas praksē nozīmē paroli vai saderīgu atvasinātu formu. Metodei, kas nes paroli aizsargātā tunelī, vajadzīga pati parole pie pārbaudītāja. Lasiet metodes dokumentāciju pārbaudītāja prasības dēļ, nevis klienta konfigurācijas dēļ, jo klienta prasības parasti ir vieglā daļa.
Mūsdienu tīmekļa ietvara radītā sālītā jaucējvērtība nedod ne vienu, ne otru. Tā pārbauda vienu konkrētu salīdzinājumu, un to nevar atgriezt atpakaļ noslēpumā, no kura tā radusies.
Izaicinājums un atbilde nevar izmantot sālītu jaucējvērtību
MSCHAPv2 ir izaicinājuma un atbildes apmaiņa, tāpēc serveris nekad nesaņem paroli un nevar salīdzināt glabātu virkni. Tam gaidāmā atbilde jāatvasina no materiāla, kas tam jau ir, un tāpēc saderīgās glabāšanas formas ir tik šauras. Bcrypt vai Argon2 vērtība ar sāli katram lietotājam ir vienvirziena tā, ka apmaiņa tiek pilnībā izslēgta. Tālāk esošā tabula sākas ar glabāšanas formu, nevis metodes nosaukumu, jo tieši glabāšanas forma izšķir atbildi.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
SQL spraudņa dokumentācija programmai strongSwan definē savu shēmu konfigurācijai un akreditācijas datiem, un projekts šo spraudni joprojām atzīmē kā eksperimentālu. Nekas tajā nepiemērojas lietotnes lietotāju tabulai un nenojauš, kura jaucēšanas shēma radīja glabāto vērtību. Tāpēc reālās iespējas ir migrācija uz krātuvi, ko vārteja var izmantot, vai autentifikācijas pakalpojums esošās krātuves priekšā, kas var veikt apmaiņu. Viss pārējais ir savienotājs ar apslēptu pieņēmumu iekšā.
RADIUS pārvieto darbu, nevis prasību
EAP deleģēšana RADIUS serverim maina to, kur notiek pārbaude, un parasti uzlabo audita pēdas. Tas neatgūst paroli no vienvirziena jaucējvērtības, tāpēc autentifikācijas pakalpojumam joprojām vajadzīgs materiāls, kas saderīgs ar metodi, kuru tas pabeidz. Komandas to uzzina pēc tam, kad ir uzbūvējušas RADIUS ceļu un otrā galā saskārušās ar to pašu sienu.
Tur, kur RADIUS serveris var lasīt direktoriju ar saderīgiem akreditācijas datiem, risinājums strādā un VPN vārteja paliek vienkārša. Tur, kur nevar, godīgā atbilde ir reģistrācijas maiņa, nevis vēl viens savienotājs. Nodrošināšana un atsaukšana pieder tam, kam pieder identitāte, tāpēc nokopēta tabula bez atbalstīta sinhronizācijas procesa ir otrs akreditācijas datu dzīves cikls, nevis vienota pieteikšanās. Tā sāk atšķirties pirmajā reizē, kad kāds atiestata paroli tikai vienā vietā, un šī atšķirība ir klusa, līdz abās sistēmās esošais konts katrā no tām uzvedas citādi.
Ierobežojiet direktoriju lasošo kontu tikai ar šo lasīšanu un turiet to atsevišķi no konta, ko vārteja izmanto savai konfigurācijai. Koplietots administratīvais konts tikai lasāmu risinājumu pārvērš daudz plašākā ietekmes rādiusā.
Kur kontam vajadzētu dzīvot
Kad materiāla jautājums ir atrisināts, paliek divas arhitektūras. Vārteja var pārvaldīt nelielu akreditācijas datu krātuvi, ko lasa tikai tā, vai deleģēt autentifikācijas pakalpojumam, kas stāv uzņēmuma direktorijas priekšā.
Pirmā ir vieglāk pārdomājama un sliktāka lietotājam, kuram paliek uzturams otrs ieejas vārds. Otrā saglabā vienu identitāti un pievieno atkarību no pakalpojuma, kam tagad jābūt pieejamam, pirms kāds var pieslēgties. Neviena nav nepareiza, bet izvēle būtu jāpieraksta blakus vārtejas konfigurācijai, citādi nākamais inženieris pieņems, ka izvēlēta ir otra. Lai ko arī izvēlētos, divas zemāk esošās komandas ir tās, kas parāda pašreizējo stāvokli pirms tā maiņas.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsKonta autentifikācija arī neatrisina autorizāciju. Grupas dalība, ierīces stāvoklis un tīkla atļauja joprojām prasa skaidru kartēšanu pēc tam, kad lietotājs ir pierādījis nepieciešamo identitāti. Savienojums, kas lieliski autentificējas un neko neautorizē, ir politikas rezultāts, nevis metodes defekts.