Skript auth-user-pass-verify za OpenVPN: pravilna izhodna koda

OpenVPN deluje na podlagi točno enega izhoda prijavnega skripta: izhodnega stanja. Vse drugo, kar skript počne, je dekoracija. Kljuka lahko doseže pravega preveritelja, analizira odgovor in natisne prijazno vrstico, pa vrne stanje, ki pomeni nasprotno od tega, kar je avtor nameraval. Najprej preberite pogodbo in napišite adapter okoli nje, in cela ta vrsta napak izgine.

Pogodba je majhna: prepoznajte poslani račun, vprašajte odobrenega preveritelja predvideno vprašanje in sprejmite le dokumentiran pozitiven rezultat tega preveritelja za to zahtevo. Vse ostalo je infrastruktura.

Tri stanja, ki jih lahko kljuka vrne

Za auth-user-pass-verify določa priročnik OpenVPN 2.6 izhodno kodo 0 kot sprejem, 1 kot zavrnitev in 2 kot odloženo preverjanje pristnosti. To so edini trije odgovori, ki jih strežnik razume, in vsak ima za povezavo drugačno posledico. Skript, ki se konča s stanjem svojega zadnjega ukaza, je dejansko pustil, da glasuje klic za dnevnik ali korak čiščenja. Stanje zapišite izrecno v vsaki veji, tudi v vejah, ki niso nikoli dosegle preveritelja.

Uspeh HTTP in uspeh preverjanja pristnosti sta ločeni plasti, njuno mešanje pa je najpogostejši način, da se ta kljuka zmoti. Odgovor 202 pomeni, da je bila zahteva sprejeta v obdelavo, ne da je bilo geslo preverjeno. Določite pričakovano stanje, obliko odgovora in končno sodbo iz pogodbe API, ki ste jo prejeli, in si ne izmišljujte imena polja, ker se zdi verjetno.

Če odgovor res pride pozneje, je to odložena pot in tako jo je treba tudi zgraditi. Odložen poskus, ki se nikoli ne dokonča, zadržuje vire, dokler ne poteče časovna omejitev.

Berite datoteko poverilnic natanko tako, kot je zapisana

Pri dokumentirani metodi prek datoteke strežnik zapiše uporabniško ime in geslo kot prvi dve vrstici začasne datoteke, to pot preda skriptu in datoteko odstrani, ko se skript vrne. Ti dve vrstici berite kot podatke: nikoli ne zaženite datoteke prek source, nikoli je ne ovrednotite in nikoli ne prilepite njene vsebine v ukazno vrstico, kjer jo lahko vidi tabela procesov. Geslo ohranite bajt za bajtom, ker normalizacija, kakršno bi uporabili za uporabniško ime, tiho spremeni poverilnico. Imenik za to začasno datoteko je odločitev o uvajanju, zato preverite, da obstaja in da ni berljiv vsem na gostitelju.

Lastno poverilnico preveritelja hranite ločeno od uporabnikove: pripada integraciji prehoda, živi v shrambi skrivnosti platforme in potrebuje le dovoljenje za preverjanje, zato ni dokaz, da se je preverila določena oseba. Tudi kljuki ne dovolite, da postane druga preveriteljica gesel. Ročno prepisovanje primerjave zgoščenih vrednosti ne postane varno z optimizacijo zanke, vzdrževani preveritelj pa že razume soljeno in drago shemo shrambe računov.

Odločite, kaj pomeni odgovor, ki ga ni mogoče razvrstiti

Časovne omejitve, transportne napake, popačeni odgovori in nedosegljiv backend imajo eno skupno lastnost: nobeden ni pozitivno preverjanje. Kljuka bi morala pri vsakem od njih odpovedati zaprto in zabeležiti razlog, na podlagi katerega lahko operater ukrepa. Ta razlog spada v zaščiten dnevnik, ne v sporočilo, vrnjeno osebi, ki se poskuša povezati.

Bodite enako previdni pri poteh, ki preveritelja sploh ne dosežejo. Manjkajoča konfiguracijska vrednost, neberljiva skrivnost ali nenamščena odvisnost bi morale dati zavrnitev z izrazitim operativnim markerjem namesto naključnega sprejema. Te veje testirajte tako, da odvisnost odstranite v laboratoriju, namesto da bi o njih razmišljali. Kjer lahko neuspeh beleženja spremeni izhodno stanje, je beleženje postalo del odločitve in ga je treba narediti neškodljivo.

Tudi konfiguracija strežnika je tu pomembna: uporabniško določeni skripti se upoštevajo le, ko jih tekoča konfiguracija dovoljuje na zahtevani ravni varnosti, in ta nastavitev je zavestna izbira, ne privzeta vrednost, ki bi jo bilo treba dvigniti.

Preverite sodbo, ne natisnjene vrstice

Zgradite test, ki neposredno pregleda izhodno stanje. Napišite vzorčno datoteko poverilnic, zaženite kljuko nanjo z znanim dobrim in znanim slabim računom ter berite stanje, ki ga poroča lupina, ne besedila, ki ga izpiše skript. Ta ena sama kontrola ujame večino napak pogodbe, preden se odjemalec sploh poveže.

Nato poženite iste primere skozi pravega odjemalca proti neprodukcijskemu poslušalcu in potrdite, kaj je strežnik zabeležil: sprejeto, zavrnjeno ali odloženo. Pokrijte onemogočen račun, napačno geslo, popačen odgovor preveritelja, časovno omejitev in nedosegljivega preveritelja. Če kateri koli primer konča v stanju, ki ga ne znate poimenovati, adapter ni dokončan.

Držite preslikavo izida preveritelja v izhodno stanje ob skriptu v repozitoriju, da bo naslednji inženir lahko prebral pogodbo brez povratnega inženiringa kode.