Script na auth-user-pass-verify ng OpenVPN: tamang exit code

OpenVPN ay kumikilos sa eksaktong isang output ng login script: ang exit status. Lahat ng iba pang ginagawa ng script ay dekorasyon. Maaaring maabot ng hook ang tamang verifier, masuri ang tugon at mag-print ng magiliw na linya habang nagbabalik ng status na nangangahulugang kabaligtaran ng intensyon ng may-akda. Basahin muna ang kontrata at isulat ang adapter sa paligid nito, at mawawala ang buong klase ng bug na iyon.

Maliit ang kontrata: tukuyin ang account na isinumite, itanong sa aprubadong verifier ang nilalayong tanong, at tanggapin lamang ang dokumentadong positibong resulta ng verifier na iyon para sa kahilingang iyon. Lahat ng iba pa ay imprastraktura.

Ang tatlong status na maaaring ibalik ng hook

Para sa auth-user-pass-verify, ang manwal ng OpenVPN 2.6 ay tumutukoy sa exit code 0 bilang pagtanggap, 1 bilang pagtanggi at 2 bilang ipinagpalibang pagpapatunay. Ito lamang ang tatlong sagot na naiintindihan ng server, at bawat isa ay may ibang kahihinatnan para sa koneksyon. Ang script na lumalabas gamit ang status ng huling utos nito ay talagang hinayaan ang isang log call o hakbang sa paglilinis na bumoto. Isulat ang status nang tahasan sa bawat sangay, kasama ang mga sangay na hindi kailanman umabot sa verifier.

Ang tagumpay ng HTTP at ang tagumpay ng pagpapatunay ay magkahiwalay na suson, at ang paghahalo sa kanila ang pinakakaraniwang paraan na nagkakamali ang hook na ito. Ang tugon na 202 ay nangangahulugang tinanggap ang kahilingan para sa pagproseso, hindi na na-verify ang isang password. Tukuyin ang inaasahang status, ang hugis ng tugon at ang huling hatol mula sa kontrata ng API na ibinigay sa iyo, at huwag mag-imbento ng pangalan ng field dahil mukhang makatwiran ito.

Kung tunay na darating ang sagot sa ibang pagkakataon, iyon ang ipinagpalibang landas at dapat itong itayo nang ganoon. Ang ipinagpalibang pagtatangkang hindi kailanman nakumpleto ay humahawak ng mga mapagkukunan hanggang sa mag-expire ang timeout.

Basahin ang credential file nang eksaktong nakasulat ito

Sa dokumentadong via-file na pamamaraan, isinusulat ng server ang username at password bilang unang dalawang linya ng pansamantalang file, ipinapasa ang landas na iyon sa script, at tinatanggal ang file kapag bumalik ang script. Basahin ang dalawang linyang iyon bilang data: huwag kailanman i-source ang file, huwag kailanman suriin ito, at huwag kailanman i-paste ang nilalaman nito sa command line kung saan makikita ito ng process table. Panatilihin ang password byte sa byte, dahil ang pag-normalize nito gaya ng gagawin mo sa username ay tahimik na nagbabago ng credential. Ang direktoryo para sa pansamantalang file na iyon ay desisyon sa deployment, kaya tiyakin na umiiral ito at hindi nababasa ng lahat sa host.

Ihiwalay ang sariling credential ng verifier mula sa credential ng user: pag-aari ito ng integrasyon ng gateway, naninirahan sa secret store ng platform at nangangailangan lamang ng pahintulot na mag-verify, kaya hindi ito ebidensya na may partikular na taong na-authenticate. Huwag ding hayaang maging pangalawang verifier ng password ang hook. Ang manu-manong muling pagsulat ng paghahambing ng hash ay hindi nagiging ligtas sa pamamagitan ng pag-optimize ng loop, at ang isang pinapanatiling verifier ay nauunawaan na ang salted at magastos na scheme ng account store.

Magpasya kung ano ang ibig sabihin ng hindi maiuuri na sagot

Ang mga timeout, error sa transport, sirang tugon at hindi available na backend ay may isang katangian: wala sa mga ito ang positibong pag-verify. Dapat mabigo nang sarado ang hook para sa bawat isa at magtala ng dahilan na maaaring aksyunan ng operator. Ang dahilang iyon ay para sa protektadong log, hindi sa mensaheng ibinabalik sa taong nagtatangkang kumonekta.

Maging kasing maingat sa mga landas na hindi umabot sa verifier. Ang kulang na halaga ng configuration, hindi mababasang secret o hindi naka-install na dependency ay dapat gumawa ng pagtanggi na may natatanging operational marker sa halip na aksidenteng pagtanggap. Subukan ang mga sangay na iyon sa pamamagitan ng pagtanggal ng dependency sa lab sa halip na pangangatwiranan ang tungkol sa kanila. Kung saan ang kabiguan sa pag-log ay makapagbabago ng exit status, ang pag-log ay naging bahagi ng desisyon at dapat gawing walang pinsala.

Mahalaga rin dito ang configuration ng server: ang mga script na tinukoy ng user ay iginagalang lamang kapag pinapayagan sila ng tumatakbong configuration sa kinakailangang antas ng seguridad, at ang setting na iyon ay sinadyang pagpili at hindi default na dapat itaas.

I-verify ang hatol, hindi ang nakalimbag na linya

Bumuo ng test na direktang sumusuri sa exit status. Sumulat ng sample na credential file, patakbuhin ang hook laban dito gamit ang kilalang mabuti at kilalang masamang account, at basahin ang status na iniuulat ng shell sa halip na ang tekstong ini-print ng script. Ang nag-iisang pagsusuring iyon ay humuhuli sa karamihan ng bug sa kontrata bago pa man kumonekta ang isang client.

Pagkatapos ay patakbuhin ang parehong mga kaso sa pamamagitan ng tunay na client laban sa hindi produksyong listener at kumpirmahin kung ano ang naitala ng server: tinanggap, tinanggihan o ipinagpaliban. Saklawin ang hindi pinagana na account, maling password, sirang tugon ng verifier, timeout at hindi maabot na verifier. Kung may kasong napunta sa estadong hindi mo kayang pangalanan, hindi pa tapos ang adapter.

Itago ang pagmamapa mula sa resulta ng verifier patungo sa exit status sa tabi ng script sa repository, upang mabasa ng susunod na inhinyero ang kontrata nang hindi nire-reverse engineer ang code.