Skript auth-user-pass-verify pre OpenVPN: správny návratový kód

OpenVPN reaguje presne na jeden výstup prihlasovacieho skriptu: na návratový stav. Všetko ostatné, čo skript robí, je dekorácia. Hook môže dosiahnuť správny verifikátor, spracovať odpoveď a vytlačiť priateľský riadok, a pritom vrátiť stav, ktorý znamená opak toho, čo autor zamýšľal. Prečítajte si najprv kontrakt a napíšte adaptér okolo neho, a celá táto trieda chýb zmizne.

Kontrakt je malý: identifikujte odoslaný účet, položte schválenému verifikátoru zamýšľanú otázku a prijmite iba dokumentovaný pozitívny výsledok toho verifikátora pre danú požiadavku. Všetko ostatné je infraštruktúra.

Tri stavy, ktoré hook môže vrátiť

Pre auth-user-pass-verify definuje manuál OpenVPN 2.6 návratový kód 0 ako prijatie, 1 ako odmietnutie a 2 ako odloženú autentifikáciu. To sú jediné tri odpovede, ktorým server rozumie, a každá má pre spojenie iný dôsledok. Skript, ktorý skončí so stavom svojho posledného príkazu, vlastne nechal o hlase rozhodnúť volanie logu alebo krok upratovania. Zapíšte stav výslovne v každej vetve, vrátane vetiev, ktoré sa k verifikátoru nikdy nedostali.

Úspech HTTP a úspech autentifikácie sú oddelené vrstvy a ich zamieňanie je najčastejší spôsob, akým tento hook zlyhá. Odpoveď 202 znamená, že požiadavka bola prijatá na spracovanie, nie že bolo overené heslo. Definujte očakávaný stav, tvar odpovede a konečný verdikt z API kontraktu, ktorý ste dostali, a nevymýšľajte názov poľa len preto, že vyzerá vierohodne.

Ak odpoveď skutočne príde neskôr, je to odložená cesta a tak ju treba aj postaviť. Odložený pokus, ktorý sa nikdy nedokončí, drží prostriedky, kým nevyprší časový limit.

Čítajte súbor s prihlasovacími údajmi presne tak, ako je zapísaný

Pri dokumentovanej metóde cez súbor server zapíše používateľské meno a heslo ako prvé dva riadky dočasného súboru, odovzdá túto cestu skriptu a po návrate skriptu súbor odstráni. Čítajte tie dva riadky ako dáta: nikdy nespúšťajte súbor cez source, nikdy ho nevyhodnocujte a nikdy nevkladajte jeho obsah do príkazového riadka, kde ho uvidí tabuľka procesov. Zachovajte heslo bajt po bajte, pretože normalizácia, akú by ste použili na používateľské meno, potichu mení prihlasovacie údaje. Adresár pre tento dočasný súbor je rozhodnutie o nasadení, preto overte, že existuje a že ho na hostiteľovi nemôže čítať každý.

Vlastné prihlasovacie údaje verifikátora držte oddelene od používateľských: patria integrácii brány, žijú v úložišti tajomstiev platformy a potrebujú iba oprávnenie overovať, takže nie sú dôkazom, že sa autentifikovala konkrétna osoba. Nedovoľte ani, aby sa hook stal druhým verifikátorom hesiel. Ručné prepísanie porovnania hash sa nestane bezpečným optimalizáciou slučky a udržiavaný verifikátor už rozumie solenej a nákladnej schéme úložiska účtov.

Rozhodnite, čo znamená nezaraditeľná odpoveď

Časové limity, chyby prenosu, poškodené odpovede a nedostupný backend majú jednu vlastnosť: žiadna z nich nie je pozitívne overenie. Hook by mal pri každej z nich zlyhať zatvorene a zaznamenať dôvod, podľa ktorého môže operátor konať. Ten dôvod patrí do chráneného logu, nie do správy vrátenej človeku, ktorý sa snaží pripojiť.

Buďte rovnako opatrní pri cestách, ktoré sa k verifikátoru vôbec nedostanú. Chýbajúca konfiguračná hodnota, nečitateľné tajomstvo alebo nenainštalovaná závislosť by mali viesť k odmietnutiu s výrazným prevádzkovým markerom namiesto náhodného prijatia. Testujte tie vetvy odstránením závislosti v laboratóriu, namiesto uvažovania o nich. Tam, kde zlyhanie logovania môže zmeniť návratový stav, sa logovanie stalo súčasťou rozhodnutia a musí sa urobiť neškodným.

Konfigurácia servera je dôležitá aj tu: používateľsky definované skripty sa uznávajú len vtedy, keď ich bežiaca konfigurácia povoľuje na požadovanej úrovni zabezpečenia, a toto nastavenie je zámerná voľba, nie predvolená hodnota, ktorú treba zvýšiť.

Overujte verdikt, nie vytlačený riadok

Postavte test, ktorý priamo kontroluje návratový stav. Napíšte vzorový súbor s prihlasovacími údajmi, spustite naň hook so známym dobrým a známym zlým účtom a čítajte stav, ktorý hlási shell, nie text, ktorý vypíše skript. Táto jediná kontrola zachytí väčšinu chýb v kontrakte predtým, než sa klient vôbec pripojí.

Potom prežeňte tie isté prípady skutočným klientom proti nelistovaciemu poslucháčovi a potvrďte, čo server zaznamenal: prijaté, odmietnuté alebo odložené. Pokryte deaktivovaný účet, nesprávne heslo, poškodenú odpoveď verifikátora, časový limit a nedostupný verifikátor. Ak niektorý prípad skončí v stave, ktorý neviete pomenovať, adaptér nie je hotový.

Držte mapovanie výsledku verifikátora na návratový stav vedľa skriptu v repozitári, aby si ďalší inžinier mohol prečítať kontrakt bez reverzného inžinierstva kódu.