AnyConnect på Linux: script login-sekvensen sikkert
AnyConnect vpn-binæren læser svar fra stdin, og det er nok til et gentageligt login. Byg sekvensen, beskyt filen, verificer og stop.
vpn-klienten, der følger med Cisco AnyConnect, opfører sig som en samtale: den skriver en prompt, venter på en linje og skriver så den næste. Fodrer du samtalen ind fra en fil eller en pipe, kører den samme binære fil uden opsyn. Teknikken er én omdirigering plus en ordnet liste af svar, og det er listen, ikke omdirigeringen, der afgør, om scriptet er pålideligt.
To ting ødelægger det i praksis. Rækkefølgen af prompter flytter sig, når en gateway spørger om noget ekstra, og en gemt adgangskode gør en tastefejl til en kontolåsning. Behandl sekvensen som versionsstyret data, som du kan diffe efter enhver ændring på gatewayen. Fejl højt i stedet for at prøve igen, for en løkke er netop måden, hvorpå en fejlskrevet adgangskode bliver en låst konto.
Én sekvens, i den rækkefølge klienten spørger
Kør klienten interaktivt én gang, og skriv hver prompt ned i den rækkefølge, den vises. Den transskription bliver svarfilen. Når du omdirigerer filen ind i den binære fil, skal den første linje være selve forbindelseskommandoen, og derfor begynder sekvensen med et værtsnavn i stedet for et brugernavn.
connect vpn.example.com
0
<username>
<password>
y
exit
Den nøgne 0 vælger den første forbindelsesprofil, når gatewayen tilbyder en liste; brug det indeks, din gateway udskriver. y accepterer et login-banner, så slet den linje, hvis der ikke er noget banner, og indsæt en linje, hvor din gateway stiller et ekstra spørgsmål. Det afsluttende exit er det, der lader klienten afslutte rent, når det sidste svar er brugt.
/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt
Ikke-interaktiv tilstand er ikke valgfri her. Uden -s kan klienten overtage terminalen og ignorere omdirigeret input; med den læses svarene fra strømmen, og processen vender tilbage. Hvor den binære fil kræver forhøjede rettigheder, pak kaldet ind i sudo -n, så scriptet fejler med det samme i stedet for at blokere på en adgangskodeprompt.
Hvor svarfilen lækker
En fil med en adgangskode er en legitimationsoplysning, så giv den rettighederne som en: tilstand 600, ejet af den konto, der kører jobbet, og aldrig inde i en delt eller synkroniseret mappe. Opret den med tilstanden allerede anvendt i stedet for at rette den bagefter, for en fil er kortvarigt læsbar for alle mellem skrivningen og chmod.
install -m 600 /dev/null ~/.config/anyconnect.txt
chmod 700 ~/.config
Den anden halvdel er argv. En adgangskode, der sendes som argument, er synlig for enhver lokal bruger, der lister processer, og den ender også i shell-historikken. Læs den fra en fildeskriptor eller en miljøvariabel i stedet, og sæt nyttelasten i citationstegn, så shellen ikke kan udvide noget indeni.
printf '%s\n' 'connect vpn.example.com' '0' "$VPN_USER" "$VPN_PASS" 'y' 'exit' \
| sudo -n /opt/cisco/anyconnect/bin/vpn -s
Hold øje med citationstegnene. Inde i dobbelte citationstegn kan en adgangskode med ! blive udvidet af en interaktiv shell, før klienten overhovedet ser den, og fejlen kommer som en generisk event-not-found-fejl, der ligner et protokolproblem.
Bevis tunnelen, luk den så
Tilstanden forbundet beviser kun, at klienten tror, den har en session. Vælg en vært, der kun svarer indefra virksomhedens netværk, og prøv den én gang, før du gør noget andet. En fejl der er en routing- eller policyfejl, og at køre login igen ændrer det ikke.
/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
Tjek tilstandsoutputtet før og efter afbrydelsen. En klient, der efterlades med en forældet session, kan afvise den næste forbindelse, mens scriptet stadig rapporterer succes, og den fejltilstand er usynlig, hvis du kun ser på exitkoder. Sammenlign de to aflæsninger i stedet for at stole på den anden alene. Aliaser i en shell-profil er nok til daglig brug, mens alt planlagt fortjener samme gennemgang af legitimationsoplysninger og identitet som ethvert andet uovervåget job.
Når en fast liste ikke længere er sikker
En svarfil koder dagens promptrækkefølge. Et ændret banner, en tvungen adgangskodeændring eller en andenfaktor-udfordring gør den til en løkke, der kan låse kontoen, og derfor skal scriptet afslutte ved det første uventede svar i stedet for at genstarte.
Fang, hvad klienten udskrev, returner en ikke-nul status, og lad kalderen beslutte. Hvor gatewayen kræver en anden faktor, er det ærlige svar, at et uovervåget login ikke er tilgængeligt for den profil, ikke at sekvensen mangler en linje mere.
Rotation hører til samme gennemgang. Hvis legitimationsoplysningen gemmes, så beslut, hvem der kan læse den, hvornår den skiftes, og hvad der fjerner den, når værten genopbygges. Et script, der virker i et år, fordi ingen har rørt adgangskoden, er ikke et design, men et uheld, der venter på en rotationspolitik.
Profiler, der ikke er AnyConnect
To ældre Cisco-legitimationsstile forveksles med denne. En vpnc-profil spørger om et IPSec ID, som egentlig er gruppenavnet, derefter en gruppehemmelighed, derefter dine egne legitimationsoplysninger, og alle tre kommer fra den, der driver gatewayen. Legacy Cisco IPsec er en anden protokol end AnyConnect, så vpnc kan ikke nå en kun-AnyConnect-tjeneste; openconnect --protocol=anyconnect er den åbne klient til det job.
En .pcf-fil beskriver den ældre klientprofil. Værten, gruppenavnet og gruppeadgangskoden i den kan indtastes igen manuelt i en klient, der taler Cisco IPsec, selvom filen ikke er en universel import, og enhver ikke-standard port eller tunneltilstand forsvinder normalt i overførslen.
Start med det, gatewayen faktisk tilbyder, og vælg så den klient, der taler den protokol. At kopiere en profil fra et andet site er måden, hvorpå folk ender med at fejlfinde legitimationsoplysninger, der aldrig var problemet.