Lidhja e RADIUS me OpenVPN: plugin apo grep skripti?

Plugini vazhdon të rekomandohet në fije më të vjetra se ndërtimet aktuale, dhe në një server të përpiluar dje dështon gjatë ngarkimit. Ky nuk është gabim konfigurimi që rregullohet me një rrugë. Plugini dhe grepi i skriptit zgjidhin të njëjtin problem në shtresa të ndryshme, dhe kalimi nga njëri te tjetri ndryshon çfarë duhet instaluar, çfarë ekzekutohet me privilegje serveri dhe çfarë të thotë në të vërtetë një hyrje e dështuar.

Miti: plugini është rruga e mbështetur

Një plugin është një objekt i përbashkët i ngarkuar në procesin e OpenVPN, prandaj duhet të përputhet me ndërfaqen që ai proces ekspozon. Ndërtimet ndryshojnë, paketimi ndryshon, dhe një bibliotekë e përpiluar për një ndërfaqe më të vjetër thjesht refuzon të ngarkohet. Asgjë në konfigurimin e serverit nuk mund ta mbyllë atë hendek, prandaj këshilla "thjesht instalo radiusplugin" përfundon me një server që nuk niset.

Grepi i skriptit qëndron jashtë procesit. OpenVPN ekzekuton një program, i jep kredencialet dhe lexon një verdikt. Kjo shkëputje është ajo që e lejon të mbijetojë përmirësimet, dhe po ajo e bën atë përgjegjësinë tënde në një mënyrë që plugini nuk ishte kurrë.

Asnjëra qasje nuk është më e sigurt nga ndërtimi. Njëra ekzekuton kod të huaj brenda daemon-it; tjetra ekzekuton kodin tënd pranë tij me kredencialet në dorë. Pyetja e duhur është cili nga këto dy rreziqe mund të operosh vërtet.

Çfarë lidhte plugini

Plugini kishte skedarin e vet të konfigurimit me hostin RADIUS, sekretin e përbashkët, numrin e përpjekjeve dhe afatin kohor, dhe konfigurimi i serverit i referohej me një rresht të vetëm. Trajtimi i kredencialeve qëndronte brenda procesit të serverit, që do të thotë se fjalëkalimi nuk kalonte kurrë një kufi procesi që administratori duhej të siguronte.

Çmimi ishte lidhja. Çdo përmirësim i OpenVPN rrezikonte një ndërfaqe të papërputhshme, dhe çdo shpërndarje që rindërtonte paketën rrezikonte të prodhonte një bibliotekë që nuk përputhet më. Kur kjo ndodh, dështimi është i zëshëm dhe i menjëhershëm, dhe kjo është e vetmja mëshirë e dizajnit.

Nëse një plugin i tillë ende ngarkohet në ndërtimin tënd, mund të jetë sipërfaqja operacionale më e vogël. Konfirmo ndërfaqen për të cilën u ndërtua, mbaje të fiksuar te ndërtimi që testove, dhe trajto çdo përmirësim si një ndryshim që kërkon një test të plotë hyrjeje, jo si një përditësim rutinë pakete.

Çfarë beson vërtet grepi i skriptit

Grepi konfigurohet me auth-user-pass-verify dhe një mekanizëm dorëzimi: variabla mjedisi ose një skedar i përkohshëm. Në formën e mjedisit, OpenVPN kërkon script-security 3, niveli i dokumentuar që lejon ekspozimin e fjalëkalimit te skriptet. Ai nivel është një dobësim i qëllimshëm i parazgjedhjes, dhe duhet trajtuar si një leje me një arsyetim bashkangjitur.

Çdo gjë që skripti prek trashëgon atë besim. Duhet të zotërohet nga root, të mos jetë i shkruajtshëm nga grupi ose të tjerët, të referohet me një rrugë absolute, dhe të jetë pa asnjë vend ku një vlerë e pabesuar arrin një shell. Vendos çdo variabël në thonjëza, refuzo karaktere të papritura, dhe mos ndërto kurrë një komandë nga emri i përdoruesit i dhënë. Një skript që ekzekutohet si root në çdo përpjekje hyrjeje meriton një rishikim pikërisht për ato katër veti.

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

Forma e dorëzimit me skedar shmang problemin e trashëgimisë së mjedisit dhe i jep kredencialet skriptit përmes një skedari të përkohshëm me leje të kufizuara. Nëse klienti yt e mbështet, zakonisht është parazgjedhja më e mirë, edhe pse shton një objekt më shumë për të pastruar në rast dështimi.

Kodet e daljes vendosin nëse dështon hapur

Statusi i daljes së skriptit është verdikti: zero pranon, jo-zero refuzon. Modeli që shkakton telashe është një skript shell që pranon vetëm kur përgjigja e RADIUS përmban një shenjë të caktuar pranimi dhe kthen dështim për çdo gjë tjetër, sepse kjo shkrin tre ngjarje të ndryshme në një përgjigje. Një fjalëkalim i gabuar, një server i paarritshëm dhe një përgjigje e deformuar bëhen të gjitha i njëjti refuzim.

Ndaji ato raste në skript edhe pse grepi mund të kthejë vetëm prano ose refuzo. Regjistro rezultatin e backend-it veçmas, alarmo për afate kohore dhe gabime transporti, dhe bëje të qartë në monitorim kur vërtetimi dështon sepse shërbimi është jashtë funksionit dhe jo sepse përdoruesit shtypin gabimisht.

Dy zakone e mbajnë pjesën tjetër të arsyeshme. Nëse RADIUS është autoriteti, duhet të jetë vendi i vetëm ku kontrollohet një fjalëkalim, sepse një tabelë hije krijon dy përgjigje për të njëjtën pyetje dhe e dyta është një sipërfaqe sulmi që askush nuk e vëzhgon. Dhe mbani mend se grepi thirret përsëri në çdo përpjekje, kështu që një skript i ngadaltë me një klient të paduruar bëhet një përforcues për hamendjen e fjalëkalimeve, përveç nëse shton vonesë ose një politikë në anën e RADIUS.

Çfarë heq dorë kur certifikata zhduket

Shumë vendosje të kësaj forme çaktivizojnë plotësisht kontrollin e certifikatës së klientit, duke lënë një emër përdoruesi dhe një fjalëkalim si e gjithë pretendimi i klientit. Ajo që zhduket me atë cilësim është identiteti i bazuar në certifikatë. Kanali mbetet i kriptuar, por e vetmja gjë që emërton klientin është verdikti i RADIUS. Çdo gjë në rrjedhën e poshtme që më parë bazohej te subjekti i certifikatës tani duhet të bazohet te emri i përdoruesit.

Mbaj mbrojtjen e kanalit të kontrollit në vend që një palë e paautentikuar të mos mund të hetojë ose përmbytej shtrëngimin e duarve, dhe përdor username-as-common-name kur konfigurimi për përdorues varet nga emri i përbashkët. Portat e menaxhuara shpesh e zgjidhin këtë ndryshe, duke përfunduar vërtetimin me certifikatë te një portë që flet EAP-TLS me RADIUS, dhe në atë rast asnjëra nga këto direktiva serveri nuk zbatohet. Kopjo modelin që dokumenton platforma jote, jo atë të një produkti fqinj. Direktivat që kanë rëndësi ndryshojnë mjaftueshëm saqë përzierja e tyre prodhon një konfigurim që analizohet dhe pastaj nuk vërteton askënd.