AnyConnect på Linux: sikker skripting av innloggingssekvensen

vpn-klienten som leveres med Cisco AnyConnect, oppfører seg som en samtale: den skriver ut en forespørsel, venter på en linje og skriver så den neste. Gir du den samtalen inn fra en fil eller et rør, kjører samme binærfila uten tilsyn. Teknikken er én omdirigering pluss en ordnet liste over svar, og det er lista, ikke omdirigeringen, som avgjør om skriptet er til å stole på.

I praksis er det to ting som ødelegger dette. Rekkefølgen på forespørslene forskyver seg når en gateway spør om noe i tillegg, og et lagret passord gjør en enkelt skrivefeil om til en låst konto. Behandle sekvensen som versjonerte data som du kan sammenligne etter hver endring i gatewayen. Feil heller høyt enn å prøve igjen, for en løkke er nettopp måten et feilskrevet passord blir en låst konto på.

Én sekvens, i den rekkefølgen klienten spør

Kjør klienten interaktivt én gang og skriv ned hver forespørsel i den rekkefølgen den dukker opp. Den utskriften blir svarfilen. Når du omdirigerer filen inn i binærfila, må første linje være selve tilkoblingskommandoen, og derfor starter sekvensen med et vertsnavn og ikke et brukernavn.

connect vpn.example.com
0
<username>
<password>
y
exit

Den nakne 0 velger den første tilkoblingsprofilen når gatewayen tilbyr en liste; bruk indeksen din gateway skriver ut. y godtar et innloggingsbanner, så fjern den linjen hvis det ikke finnes noe banner, og sett inn én der gatewayen din stiller et tilleggsspørsmål. Den avsluttende exit er det som lar klienten avslutte rent når det siste svaret er brukt opp.

/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

Ikke-interaktiv modus er ikke valgfritt her. Uten -s kan klienten overta terminalen og overse omdirigert inndata; med den leses svarene fra strømmen og prosessen returnerer. Der binærfila trenger forhøyede rettigheter, pakk kallet inn i sudo -n slik at skriptet feiler umiddelbart i stedet for å blokkere på en passordforespørsel.

Der svarfilen lekker

En fil som inneholder et passord, er en legitimasjon, så gi den rettighetene til en: modus 600, eid av kontoen som kjører jobben, og aldri inne i en delt eller synkronisert mappe. Opprett den med modusen allerede satt i stedet for å reparere den etterpå, for en fil er et øyeblikk lesbar for alle mellom skrivingen og chmod.

install -m 600 /dev/null ~/.config/anyconnect.txt
chmod 700 ~/.config

Den andre halvdelen er argv. Et passord som sendes som argument, er synlig for alle lokale brukere som lister opp prosesser, og det havner også i skallhistorikken. Les det fra en fildeskriptor eller en miljøvariabel i stedet, og sett nyttelasten i anførselstegn slik at skallet ikke kan utvide noe inni den.

printf '%s\n' 'connect vpn.example.com' '0' "$VPN_USER" "$VPN_PASS" 'y' 'exit' \
  | sudo -n /opt/cisco/anyconnect/bin/vpn -s

Vær oppmerksom på anførselstegnene. Inne i doble anførselstegn kan et passord som inneholder ! bli utvidet av et interaktivt skall før klienten i det hele tatt ser det, og feilen dukker opp som en generisk event-not-found-feil som ser ut som et protokollproblem.

Bevis tunnelen, og lukk den

En tilkoblet tilstand beviser bare at klienten tror den har en sesjon. Velg en vert som bare svarer fra innsiden av bedriftsnettet, og test den én gang før du gjør noe annet. En feil der er en ruting- eller policyfeil, og å kjøre innloggingen på nytt endrer ikke på det.

/opt/cisco/anyconnect/bin/vpn state
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 10 https://<internal-host>/
/opt/cisco/anyconnect/bin/vpn disconnect

Sjekk tilstandsutdata før og etter at du kobler fra. En klient som blir stående med en utdatert sesjon, kan avvise neste tilkobling mens skriptet fortsatt rapporterer suksess, og den feilmodusen er usynlig hvis du bare ser på utgangskoder. Sammenlign de to avlesningene i stedet for å stole på den andre alene. Aliaser i en skallprofil er tilstrekkelig til daglig bruk, mens alt som er planlagt fortjener samme gjennomgang av legitimasjon og identitet som enhver annen uovervåket jobb.

Når en fast liste ikke lenger er trygg

En svarfil koder dagens rekkefølge av forespørsler. Et endret banner, en tvungen passordendring eller en utfordring med andre faktor gjør den om til en løkke som kan låse kontoen, og derfor må skriptet avslutte ved det første uventede svaret i stedet for å restarte.

Fang opp det klienten skrev ut, returner en status som ikke er null, og la den som kaller avgjøre. Der gatewayen krever en andre faktor, er det ærlige svaret at uovervåket innlogging ikke er tilgjengelig for den profilen, ikke at sekvensen trenger én linje til.

Rotasjon hører med i samme gjennomgang. Hvis legitimasjonen lagres, må du bestemme hvem som kan lese den, når den endres og hva som fjerner den når verten bygges på nytt. Et skript som virker i et år fordi ingen har rørt passordet, er ikke et design, men en ulykke som venter på en rotasjonspolicy.

Profiler som ikke er AnyConnect

To eldre Cisco-stiler for legitimasjon blir forvekslet med denne. En vpnc-profil ber om en IPSec ID, som egentlig er gruppenavnet, deretter en gruppehemmelighet, deretter dine egne legitimasjoner, og alle tre kommer fra den som driver gatewayen. Gammel Cisco IPsec er en annen protokoll enn AnyConnect, så vpnc kan ikke nå en tjeneste som bare er AnyConnect; openconnect --protocol=anyconnect er den åpne klienten for den jobben.

En .pcf-fil beskriver den eldre klientprofilen. Verten, gruppenavnet og gruppepassordet i den kan legges inn på nytt for hånd i en klient som snakker Cisco IPsec, selv om filen ikke er en universell import og enhver port eller tunnelmodus som ikke er standard, vanligvis forsvinner i overføringen.

Begynn med det gatewayen faktisk tilbyr, og velg så den klienten som snakker den protokollen. Å kopiere en profil fra et annet sted er måten folk ender opp med å feilsøke legitimasjon som aldri var problemet.