OpenConnect csd-wrapper: granska skriptet före inloggningen

Att lägga till --csd-wrapper i en profil överlämnar ett lokalt skript till en daemon som kör det vid inloggning, så beslutet framför dig är en kodgranskning, inte en inställningsväxel. Alternativet finns för att gatewayens värdkontrollkomponent ska kunna bytas ut, och det tar en sökväg till ett skript som du tillhandahåller. Allt nedan förutsätter att utrullningsägaren redan har sagt vilken hållningskontroll som krävs; om den delen fortfarande är öppen, avgör den först. Körboken har fyra steg: hitta steget som misslyckades, läs skriptet, välj identiteten det körs som och bevisa resultatet.

Steg 1: Hitta steget som misslyckades

Klientens sista meddelande handlar oftast om en cookie, vilket är slutet på en kedja och inte början. En HTTPS-inloggning, en servercertifikatkontroll, ett autentiseringsutbyte och en hållningskomponent står alla framför det meddelandet.

Anteckna versionen och inloggningsadressen som används, upprepa sedan försöket med utförlig utdata kvar på din egen terminal. Läs det första felet som inte är ett nytt försök, inte den sista raden i transkriptet. Om loggen stannar innan någon utvärderingskomponent har namngetts, är omslaget ännu inte ditt problem. Att lägga till det då vidgar bara ytan du måste försvara senare.

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

Håll transkriptet lokalt, eftersom cookies och autentiseringssvar är åtkomstmaterial. Ett spår som klistras in i en chattråd är ett läckage av inloggningsuppgifter även när utvärderingssteget ser harmlöst ut. Dela feltexten och punkten i flödet där den dök upp, aldrig nyttolasten.

Steg 2: Läs skriptet innan det går in i en profil

Ett omslag är bara så pålitligt som den revision du granskat, så fäst den revisionen och spara dess hash bredvid godkännandenoteringen. De två kommandona nedan ger dig ett fingeravtryck och en billig syntaxkontroll innan du läser en enda rad. De ger också nästa person en fast referens, vilket spelar roll när filen lever utanför pakethantering. Inget av kommandona säger vad skriptet gör, så kör dem och fortsätt läsa.

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

Läs hela filen med fyra frågor i tankarna: gör den utgående HTTP-anrop, läser den autentiseringsfiler eller miljövariabler, skriver den utanför en tillfällig katalog, och rapporterar någon gren en godkänd hållning utan att mäta något. Det sista mönstret är en policykringgång med en loggrada fastsatt. Kopierade omslag smugglar gärna in det bakom en kontroll som ser trovärdig ut. Om skriptet avgör att enheten är okej innan det tittar på enheten, stanna där.

Kontrollera också packade nyttolaster, eftersom ett läsbart huvud inte bevisar något om resten av filen. Att ladda ner ett skript från en forumtråd gör det inte pålitligt bara för att namnet ekar en riktig värdkontrollkomponent. Anteckna vem som installerade det, varifrån det kom och hur det kommer att uppdateras.

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

Steg 3: Välj identiteten som omslaget körs som

--csd-user sänker privilegierna medan CSD-, TNCC- eller HIP-programmet körs. Det kontot är en del av den lokala körningsordningen, inte användarnamnet som skickas till gatewayen.

Ge omslaget ett dedikerat konto utan interaktivt skal, utan sudo-rättigheter och utan gruppmedlemskap som det inte behöver. Ge läsbehörighet till skriptet och till de specifika filer det inspekterar, testa sedan sänkningen innan du rör VPN-profilen. Att hitta problemet här är billigare än att hitta det inne i klienten.

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

Sänkta privilegier begränsar skadan ett dåligt skript kan göra. Det granskar inte koden, gör inte rapporten sann och fastställer inte att gatewayadministratören accepterar denna implementering som uppfyllelse av enhetspolicyn.

Steg 4: Håll ändringen återställbar

Säkerhetskopiera profilen innan du redigerar den, och håll omslaget under versionskontroll så att en återställning återställer en känd hash i stället för att leta efter en kopia. Anteckna skriptets sökväg, hash, körningsanvändare och godkännare på ett ställe.

För att rulla tillbaka, ta bort alternativet, starta om klienten och bekräfta att det ursprungliga felet återkommer. Om gatewayen fortfarande avvisar inloggningen efter återställningen har något annat också ändrats, och att hitta den skillnaden kommer före ett nytt försök med omslaget. Behåll den tidigare kopian under hela ändringsfönstret, vilket för de flesta team innebär tills nästa underhållsfönster har passerat.

Efter en lyckad utrullning, kontrollera två saker i stället för en: tunneln kommer upp, och en enhet som borde misslyckas i hållningskontrollen avvisas fortfarande. En anslutning som fungerar för alla är inte bevis för att utvärderingen överlevde din ändring.

Genvägar som skapar ett nytt problem

Låt inte hjälparen rapportera ett kompatibelt tillstånd utan att köra de nödvändiga kontrollerna, och skriv inte över plattformsidentiteten för att matcha ett annat operativsystem. Att hävda en annan plattform är inte bevis för att den verkliga enheten uppfyller policyn. Det lämnar dig med en klient som ljuger vid varje framtida inloggning.

Att stänga av serververifiering, spela upp en gammal cookie och stapla ogranskade skript byter alla ett synligt fel mot ett osynligt. Om den installerade klienten inte kan slutföra det stödda flödet, be om ett godkänt alternativ i stället för att böja det du har.

OpenConnect-handboken dokumenterar --csd-wrapper och --csd-user var för sig, och det är tipset som spelar roll: skriptet och identiteten är två beslut. Granska dem var för sig och skriv ner båda. Då slutar inloggningsprompten vara ett mysterium du löser genom att klistra in kod.