OpenVPN-script auth-user-pass-verify: de juiste exitcode

OpenVPN handelt op precies één uitvoer van een inlogscript: de exitstatus. Al het andere dat het script doet, is decoratie. Een hook kan de juiste verifier bereiken, het antwoord parseren en een vriendelijke regel printen terwijl hij een status teruggeeft die het tegenovergestelde betekent van wat de auteur bedoelde. Lees eerst het contract en schrijf de adapter eromheen, en die hele klasse fouten verdwijnt.

Het contract is klein: identificeer het ingediende account, stel de goedgekeurde verifier de bedoelde vraag en accepteer alleen het gedocumenteerde positieve resultaat van die verifier voor dat verzoek. Al het andere is infrastructuur.

De drie statussen die de hook kan teruggeven

Voor auth-user-pass-verify, de OpenVPN 2.6-handleiding definieert exitcode 0 als acceptatie, 1 als afwijzing en 2 als uitgestelde authenticatie. Dat zijn de enige drie antwoorden die de server begrijpt, en elk heeft een ander gevolg voor de verbinding. Een script dat eindigt met de status van zijn laatste commando heeft in feite een logaanroep of een opruimstap laten stemmen. Schrijf de status expliciet in elke tak, ook in de takken die de verifier nooit bereikten.

HTTP-succes en authenticatiesucces zijn gescheiden lagen, en ze verwarren is de meest voorkomende manier waarop deze hook misgaat. Een 202-antwoord betekent dat het verzoek is geaccepteerd voor verwerking, niet dat een wachtwoord is geverifieerd. Definieer de verwachte status, de vorm van het antwoord en het definitieve oordeel op basis van het API-contract dat je hebt gekregen, en verzin geen veldnaam omdat die aannemelijk lijkt.

Als het antwoord echt later komt, is dat het uitgestelde pad en dat moet als zodanig worden gebouwd. Een uitgestelde poging die nooit wordt voltooid, houdt resources vast tot de time-out afloopt.

Lees het inloggegevensbestand precies zoals het is geschreven

Bij de gedocumenteerde via-bestand-methode schrijft de server de gebruikersnaam en het wachtwoord als de eerste twee regels van een tijdelijk bestand, geeft dat pad aan het script en verwijdert het bestand wanneer het script terugkeert. Lees die twee regels als data: voer het bestand nooit uit via source, evalueer het nooit en plak de inhoud nooit in een commandoregel waar de procestabel het kan zien. Bewaar het wachtwoord byte voor byte, want normaliseren zoals je een gebruikersnaam zou normaliseren verandert de inloggegevens stil. De map voor dat tijdelijke bestand is een implementatiebeslissing, dus controleer dat die bestaat en niet voor iedereen op de host leesbaar is.

Houd de eigen inloggegevens van de verifier gescheiden van die van de gebruiker: ze horen bij de gateway-integratie, leven in de geheimenkluis van het platform en hebben alleen de toestemming om te verifiëren, dus ze zijn geen bewijs dat een bepaald persoon is geauthenticeerd. Laat de hook ook geen tweede wachtwoordverifier worden. Een hashvergelijking met de hand herschrijven wordt niet veilig door de lus te optimaliseren, en een onderhouden verifier begrijpt al het gezouten en kostbare schema van de accountopslag.

Bepaal wat een niet-classificeerbaar antwoord betekent

Time-outs, transportfouten, misvormde antwoorden en een niet-beschikbare backend delen één eigenschap: geen ervan is een positieve verificatie. De hook zou voor elk daarvan gesloten moeten falen en een reden moeten vastleggen waarop een operator kan handelen. Die reden hoort in een beschermd log, niet in een bericht dat wordt teruggegeven aan de persoon die probeert te verbinden.

Wees even zorgvuldig met de paden die de verifier helemaal niet bereiken. Een ontbrekende configuratiewaarde, een onleesbaar geheim of een niet-geïnstalleerde afhankelijkheid zouden een afwijzing met een aparte operationele markering moeten opleveren in plaats van een toevallige acceptatie. Test die takken door de afhankelijkheid in een lab te verwijderen in plaats van erover te redeneren. Waar een fout in het loggen de exitstatus kan veranderen, is het loggen deel van de beslissing geworden en moet het onschadelijk worden gemaakt.

Serverconfiguratie is hier ook van belang: door de gebruiker gedefinieerde scripts worden alleen gerespecteerd wanneer de draaiende configuratie ze op het vereiste beveiligingsniveau toestaat, en die instelling is een bewuste keuze en geen standaardwaarde die moet worden verhoogd.

Controleer het oordeel, niet de geprinte regel

Bouw een test die de exitstatus rechtstreeks inspecteert. Schrijf een voorbeeldbestand met inloggegevens, voer de hook erop uit met een bekend goed en een bekend slecht account, en lees de status die de shell rapporteert in plaats van de tekst die het script print. Die ene controle vangt de meeste contractfouten voordat een client überhaupt verbindt.

Voer daarna dezelfde gevallen uit via een echte client tegen een niet-productielistener en bevestig wat de server heeft vastgelegd: geaccepteerd, afgewezen of uitgesteld. Dek een uitgeschakeld account, een verkeerd wachtwoord, een misvormd verifierantwoord, een time-out en een onbereikbare verifier af. Als een geval in een toestand belandt die je niet kunt benoemen, is de adapter niet af.

Houd de koppeling van verifierresultaat naar exitstatus naast het script in de repository, zodat de volgende engineer het contract kan lezen zonder de code terug te ontwikkelen.