Skripti auth-user-pass-verify i OpenVPN: kodi i daljes saktë

OpenVPN vepron mbi saktësisht një dalje të një skripti hyrjeje: statusin e daljes. Çdo gjë tjetër që bën skripti është dekor. Një hook mund të arrijë verifikuesin e duhur, të analizojë përgjigjen dhe të shtypë një rresht miqësor, por të kthejë një status që do të thotë e kundërta e asaj që autori synonte. Lexoni së pari kontratën dhe shkruani adaptuesin rreth saj, dhe e gjithë ajo klasë gabimesh zhduket.

Kontrata është e vogël: identifikoni llogarinë e dërguar, pyesni verifikuesin e miratuar pyetjen e synuar dhe pranoni vetëm rezultatin pozitiv të dokumentuar të atij verifikuesi për atë kërkesë. Çdo gjë tjetër është infrastrukturë.

Tre statuset që hook-u mund të kthejë

Për auth-user-pass-verify, manuali i OpenVPN 2.6 përcakton kodin e daljes 0 si pranim, 1 si refuzim dhe 2 si vërtetim të shtyrë. Këto janë të vetmet tre përgjigje që kupton serveri, dhe secila ka një pasojë të ndryshme për lidhjen. Një skript që del me statusin e komandës së vetë të fundit në fakt ka lejuar një thirrje log-u ose një hap pastrimi të votojë. Shkruani statusin shprehimisht në çdo degë, duke përfshirë degët që nuk arritën kurrë te verifikuesi.

Suksesi HTTP dhe suksesi i vërtetimit janë shtresa të ndara, dhe ngatërrimi i tyre është mënyra më e zakonshme që ky hook gabon. Një përgjigje 202 do të thotë se kërkesa u pranua për përpunim, jo se një fjalëkalim u verifikua. Përcaktoni statusin e pritur, formën e përgjigjes dhe verdiktin përfundimtar nga kontrata API që ju është dhënë, dhe mos shpikni një emër fushe sepse duket i besueshëm.

Nëse përgjigja vërtet vjen më vonë, ajo është rruga e shtyrë dhe duhet ndërtuar si e tillë. Një përpjekje e shtyrë që nuk përfundon kurrë mban burime derisa të skadojë afati kohor.

Lexoni skedarin e kredencialeve saktësisht ashtu siç është shkruar

Me metodën e dokumentuar përmes skedarit, serveri shkruan emrin e përdoruesit dhe fjalëkalimin si dy rreshtat e parë të një skedari të përkohshëm, i kalon atë rrugë skriptit dhe e heq skedarin kur skripti kthehet. Lexoni ata dy rreshta si të dhëna: asnjëherë mos e ekzekutoni skedarin përmes source, asnjëherë mos e vlerësoni dhe asnjëherë mos e ngjitni përmbajtjen e tij në një rresht komande ku tabela e proceseve mund ta shohë. Ruajeni fjalëkalimin bajt pas bajti, sepse normalizimi, siç do të bënit me një emër përdoruesi, ndryshon në heshtje kredencialin. Drejtoria për atë skedar të përkohshëm është një vendim vendosjeje, pra konfirmoni se ekziston dhe se nuk është e lexueshme nga të gjithë në host.

Mbani kredencialin e vetë verifikuesit të ndarë nga ai i përdoruesit: i përket integrimit të portës, jeton në depon e sekreteve të platformës dhe ka nevojë vetëm për lejen e verifikimit, prandaj nuk është provë se është vërtetuar një person i caktuar. Mos lejoni as që hook-u të bëhet verifikues i dytë i fjalëkalimeve. Rishkrimi me dorë i një krahasimi hash nuk bëhet i sigurt duke optimizuar ciklin, dhe një verifikues i mirëmbajtur tashmë e kupton skemën e kripur dhe të kushtueshme të depove të llogarive.

Vendosni çfarë do të thotë një përgjigje e paklasifikueshme

Afatet kohore, gabimet e transportit, përgjigjet e keqformuara dhe një backend i padisponueshëm ndajnë një veti: asnjë prej tyre nuk është verifikim pozitiv. Hook-u duhet të dështojë i mbyllur për secilin dhe të regjistrojë një arsye mbi të cilën një operator mund të veprojë. Ajo arsye i përket një log-u të mbrojtur, jo një mesazhi që i kthehet personit që përpiqet të lidhet.

Jini po aq i kujdesshëm me rrugët që nuk arrijnë fare te verifikuesi. Një vlerë konfigurimi që mungon, një sekret i palexueshëm ose një varësi e painstaluar duhet të prodhojnë një refuzim me një shënues operacional të dallueshëm në vend të një pranimi aksidental. Testoni ato degë duke hequr varësinë në një laborator në vend që të arsyetoni për to. Aty ku një dështim regjistrimi mund të ndryshojë statusin e daljes, regjistrimi është bërë pjesë e vendimit dhe duhet bërë i padëmshëm.

Konfigurimi i serverit ka rëndësi edhe këtu: skriptet e përcaktuara nga përdoruesi respektohen vetëm kur konfigurimi që ekzekutohet i lejon ato në nivelin e kërkuar të sigurisë, dhe ajo cilësim është një zgjedhje e qëllimshme, jo një vlerë e parazgjedhur që duhet ngritur.

Verifikoni verdiktin, jo rreshtin e shtypur

Ndërtoni një test që inspekton drejtpërdrejt statusin e daljes. Shkruani një skedar kredencialesh shembull, ekzekutoni hook-un mbi të me një llogari të njohur të mirë dhe një të njohur të keqe, dhe lexoni statusin që raporton shell-i në vend të tekstit që shtyp skripti. Ai kontroll i vetëm kap shumicën e gabimeve të kontratës përpara se një klient të lidhet.

Më pas kaloni të njëjtat raste përmes një klienti të vërtetë kundër një dëgjuesi jo-produktiv dhe konfirmoni çfarë regjistroi serveri: pranuar, refuzuar ose shtyrë. Mbuloni një llogari të çaktivizuar, një fjalëkalim të gabuar, një përgjigje të keqformuar të verifikuesit, një afat kohor dhe një verifikues të paarritshëm. Nëse ndonjë rast përfundon në një gjendje që nuk mund ta emërtoni, adaptuesi nuk është përfunduar.

Mbani hartëzimin nga rezultati i verifikuesit në statusin e daljes pranë skriptit në depo, që inxhinieri i ardhshëm të mund të lexojë kontratën pa bërë inxhinieri të kundërt të kodit.