OpenVPN-skriptet auth-user-pass-verify: rätt utgångskod

OpenVPN agerar på exakt en utdata från ett inloggningsskript: utgångsstatusen. Allt annat skriptet gör är dekoration. En hook kan nå rätt verifierare, tolka svaret och skriva ut en vänlig rad men ändå returnera en status som betyder motsatsen till vad författaren avsåg. Läs kontraktet först och skriv adaptern runt det, så försvinner hela den felklassen.

Kontraktet är litet: identifiera kontot som skickades, ställ den godkända verifieraren den avsedda frågan och acceptera bara den dokumenterade positiva resultatet från den verifieraren för den begäran. Allt annat är infrastruktur.

De tre statusar som hooken kan returnera

För auth-user-pass-verify, OpenVPN 2.6-handboken definierar utgångskod 0 som acceptans, 1 som avvisning och 2 som uppskjuten autentisering. Det är de enda tre svar som servern förstår, och var och en har olika konsekvens för anslutningen. Ett skript som avslutas med statusen från sitt sista kommando har i praktiken låtit ett logganrop eller ett städsteg rösta. Skriv statusen uttryckligen i varje gren, även i grenarna som aldrig nådde verifieraren.

HTTP-framgång och autentiseringsframgång är separata lager, och att blanda dem är det vanligaste sättet den här hooken går fel. Ett 202-svar betyder att begäran godtagits för behandling, inte att ett lösenord verifierats. Definiera den förväntade statusen, svarets form och det slutliga utslaget från det API-kontrakt du fick, och hitta inte på ett fältnamn för att det verkar rimligt.

Om svaret verkligen kommer senare är det den uppskjutna vägen, och den måste byggas som sådan. Ett uppskjutet försök som aldrig slutförs håller resurser tills tidsgränsen löper ut.

Läs autentiseringsfilen exakt som den är skriven

Med den dokumenterade via-fil-metoden skriver servern användarnamn och lösenord som de två första raderna i en tillfällig fil, skickar sökvägen till skriptet och tar bort filen när skriptet återvänder. Läs de två raderna som data: kör aldrig filen genom source, utvärdera den aldrig och klistra aldrig in innehållet på en kommandorad där processtabellen kan se det. Bevara lösenordet byte för byte, eftersom normalisering, som du skulle tillämpa på ett användarnamn, tyst ändrar autentiseringsuppgiften. Katalogen för den tillfälliga filen är ett driftsbeslut, så bekräfta att den finns och inte är läsbar för alla på värden.

Håll verifierarens egna autentiseringsuppgift åtskild från användarens: den tillhör gateway-integrationen, bor i plattformens hemlighetslager och behöver bara behörigheten att verifiera, så den är inte bevis för att en viss person autentiserats. Låt inte heller hooken bli en andra lösenordsverifierare. Att skriva om en hashjämförelse för hand blir inte säkert av att optimera loopen, och en underhållen verifierare förstår redan kontolagrets saltade och kostsamma schema.

Bestäm vad ett oklassificerbart svar betyder

Tidsgränser, transportfel, felaktiga svar och en otillgänglig backend delar en egenskap: ingen av dem är en positiv verifiering. Hooken bör misslyckas stängt för var och en av dem och registrera en anledning som en operatör kan agera på. Den anledningen hör hemma i en skyddad logg, inte i ett meddelande som returneras till personen som försöker ansluta.

Var lika noggrann med de vägar som inte alls når verifieraren. Ett saknat konfigurationsvärde, en oläsbar hemlighet eller ett beroende som inte är installerat bör ge en avvisning med en tydlig operativ markör i stället för ett oavsiktligt godkännande. Testa de grenarna genom att ta bort beroendet i ett laboratorium i stället för att resonera om dem. Där ett loggningsfel kan ändra utgångsstatusen har loggningen blivit en del av beslutet och måste göras ofarlig.

Serverkonfiguration spelar roll här också: användardefinierade skript respekteras bara när den körande konfigurationen tillåter dem på den nivå av säkerhet som krävs, och den inställningen är ett medvetet val och inte ett standardvärde att höja.

Verifiera utslaget, inte den utskrivna raden

Bygg ett test som inspekterar utgångsstatusen direkt. Skriv en provautentiseringsfil, kör hooken mot den med ett känt bra och ett känt dåligt konto och läs statusen som skalet rapporterar i stället för texten skriptet skriver ut. Den enda kontrollen fångar de flesta kontraktsfel innan en klient ens ansluter.

Kör sedan samma fall genom en riktig klient mot en icke-produktionslyssnare och bekräfta vad servern registrerade: accepterat, avvisat eller uppskjutet. Täck ett inaktiverat konto, ett felaktigt lösenord, ett felaktigt verifierarsvar, en tidsgräns och en onåbar verifierare. Om något fall hamnar i ett tillstånd du inte kan namnge är adaptern inte klar.

Håll mappningen från verifierarresultat till utgångsstatus bredvid skriptet i arkivet, så att nästa ingenjör kan läsa kontraktet utan att göra omvänd ingenjörskonst på koden.