Эхлээд EAP арга: VPN ямар нууц үгийн хэш ашиглаж болох вэ
VPN нь нууцыг шалгадаг, вэб хэшийг биш. Аргыг уншиж, дараа нь ижил нууц үгс үргэлжлүүлэн ажиллана гэж амлахаасаа өмнө санд юу байгааг шалгаарай.
Олон баг ажилладаг вэб нэвтрэлттэй боловч ижил хүснэгтийн нууц үг бүрийг VPN-ээс татгалздаг. Вэб програмын өөрөө тооцоолсон хэшийг харьцуулдаг бол туннель нь клиентээс нууцыг эзэмшсэнээ серверийн шалгаж чадах байдлаар нотлохыг шаарддаг. Эдгээр нь хадгалсан материалд тавигдах өөр өөр шаардлага юм. Энэ хоёрын хоорондох завсарт ийм төслүүдийн ихэнх нь гацдаг.
Эхлээд арга, дараа нь схем
Аль ч схемийг харахаасаа өмнө сонгосон арга ямар нотолгоо шаарддагийг бичээрэй. Сорилт-хариу аргад сервер хүлээгдэж буй хариуг тооцоолж чадах материал хэрэгтэй бөгөөд энэ нь практикт нууц үг эсвэл нийцтэй үүсмэл хэлбэрийг хэлнэ. Хамгаалагдсан туннель дотор нууц үгийг зөөдөг аргад шалгагч дээр нууц үг өөрөө хэрэгтэй. Аргын баримт бичгийг клиентийн тохиргооны төлөө биш, шалгагчийн шаардлагын төлөө уншаарай, учир нь клиентийн шаардлага ихэвчлэн хялбар хэсэг байдаг.
Орчин үеийн вэб фреймворкийн үйлдвэрлэсэн давстай хэш хоёуланг нь өгдөггүй. Тэрээр нэг тодорхой харьцуулалтыг шалгадаг бөгөөд үүссэн нууц руугаа буцаах боломжгүй.
Сорилт-хариу нь давстай хэш ашиглаж чадахгүй
MSCHAPv2 бол сорилт-хариу солилцоо, тиймээс сервер нууц үгийг хэзээ ч авдаггүй бөгөөд хадгалсан мөрийг харьцуулж чадахгүй. Тэрээр хүлээгдэж буй хариуг өөрт байгаа материалаас гаргах ёстой, иймээс нийцтэй хадгалсан хэлбэрүүд маш нарийн байдаг. Хэрэглэгч бүрийн давстай bcrypt эсвэл Argon2 утга нь солилцоог бүрэн үгүйсгэдэг байдлаар нэг чиглэлтэй. Доорх хүснэгт нь аргын нэрээс биш, хадгалалтын хэлбэрээс эхэлдэг, учир нь хариуг хадгалалтын хэлбэр шийддэг.
| 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 |
strongSwan-ийн SQL залгаасын баримт бичиг нь тохиргоо болон итгэмжлэлийн өөрийн схемыг тодорхойлдог бөгөөд төсөл уг залгаасыг туршилтын гэж тэмдэглэсэн хэвээр байна. Түүнд юу ч програмын хэрэглэгчийн хүснэгтэд зохицдоггүй, хадгалсан утгыг аль хэшлэх схем үүсгэснийг таамагладаггүй. Тиймээс бодит сонголтууд нь гарц ашиглаж болох сан руу шилжих эсвэл одоо байгаа сангийн өмнө солилцоог гүйцэтгэж чадах баталгаажуулалтын үйлчилгээ юм. Бусад бүх зүйл дотроо далд таамаглалтай холбогч юм.
RADIUS ажлыг зөөдөг, шаардлагыг биш
EAP-г RADIUS серверт шилжүүлэх нь баталгаажуулалт хаана явагдахыг өөрчилж, ихэвчлэн аудитын мөрийг сайжруулдаг. Энэ нь нэг чиглэлт хэшээс нууц үгийг сэргээдэггүй тул баталгаажуулалтын үйлчилгээнд өөрийн дуусгаж буй аргатай нийцтэй материал хэрэгтэй хэвээр. Багууд үүнийг RADIUS замыг барьж, нөгөө төгсгөлд ижил ханатай тулгарсны дараа мэддэг.
RADIUS сервер нийцтэй итгэмжлэл бүхий лавлахыг уншиж чадах газарт шийдэл ажиллаж, VPN гарц энгийн хэвээр байна. Уншиж чадахгүй газарт шударга хариулт нь өөр нэг холбогч биш, бүртгэлийн өөрчлөлт юм. Хангамж ба хүчингүй болголт нь таних тэмдгийг эзэмшигчид хамаарна, тиймээс дэмжигдсэн синхрончлолын процессгүй хуулагдсан хүснэгт нь нэгдсэн нэвтрэлт биш, харин итгэмжлэлийн хоёр дахь амьдралын мөчлөг юм. Хэн нэгэн зөвхөн нэг газарт нууц үгийг шинэчлэх эхний мөчид тэр зөрж эхэлдэг бөгөөд хоёр системд байгаа бүртгэл тус бүрдээ өөрөөр ажиллах хүртэл энэ зөрүү чимээгүй байдаг.
Лавлахыг уншдаг бүртгэлийг зөвхөн тэр уншилтаар хязгаарлаж, гарц өөрийн тохиргоонд ашигладаг бүртгэлээс тусгаар байлгаарай. Хамтарсан административ бүртгэл зөвхөн унших загварыг хамаагүй өргөн нөлөөний радиустай болгодог.
Бүртгэл хаана байх ёстой
Материалын асуудал шийдэгдсэний дараа хоёр архитектур үлддэг. Гарц нь зөвхөн өөрөө уншдаг жижиг итгэмжлэлийн санг эзэмшиж болно, эсвэл корпорацийн лавлахын өмнө зогсож буй баталгаажуулалтын үйлчилгээнд шилжүүлж болно.
Эхнийх нь бодоход хялбар бөгөөд хэрэглэгчид муу, учир нь түүнд засварлах хоёр дахь нууц үг үлддэг. Хоёр дахь нь нэг таних тэмдгийг хадгалж, одоо хэн нэгэн холбогдохоос өмнө ажиллаж байх ёстой үйлчилгээнээс хамаарал нэмдэг. Аль нь ч буруу биш, гэхдээ сонголтыг гарцын тохиргооны хажууд бичих хэрэгтэй, эс бөгөөс дараагийн инженер нөгөөг сонгосон гэж үзнэ. Юу ч сонгосон, доорх хоёр команд нь өөрчлөхөөс өмнөх одоогийн байдлыг харуулдаг.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsБүртгэлийн баталгаажуулалт нь зөвшөөрлийг ч шийддэггүй. Бүлгийн гишүүнчлэл, төхөөрөмжийн төлөв, сүлжээний зөвшөөрөл нь хэрэглэгч шаардлагатай таних тэмдгийг нотолсны дараа ч тодорхой зураглал шаарддаг. Төгс баталгаажуулагдсан боловч юунд ч зөвшөөрөл өгдөггүй холболт нь бодлогын үр дүн, аргын алдаа биш.