AnyConnect pe Linux: scriptarea sigură a secvenței de autentificare

Clientul vpn care vine cu Cisco AnyConnect se comportă ca o conversație: afișează o solicitare, așteaptă o linie și apoi o afișează pe următoarea. Dacă alimentezi acea conversație dintr-un fișier sau dintr-un pipe, același binar rulează fără supraveghere. Tehnica este o singură redirecționare plus o listă ordonată de răspunsuri, iar lista, nu redirecționarea, decide dacă scriptul este fiabil.

În practică, două lucruri strică asta. Ordinea solicitărilor se schimbă când un gateway întreabă ceva în plus, iar o parolă stocată transformă o singură greșeală de tastare într-o blocare a contului. Tratează secvența ca date versionate pe care le poți compara după orice modificare a gateway-ului. Eșuează zgomotos în loc să reîncerci, pentru că bucla este exact modul în care o parolă tastată greșit devine un cont blocat.

O secvență, în ordinea în care întreabă clientul

Rulează clientul interactiv o dată și notează fiecare solicitare în ordinea în care apare. Acea transcriere devine fișierul de răspunsuri. Când redirecționezi fișierul în binar, prima linie trebuie să fie comanda de conectare propriu-zisă, de aceea secvența începe cu un nume de gazdă și nu cu un nume de utilizator.

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

0 simplu selectează primul profil de conectare când gateway-ul oferă o listă; folosește indexul pe care îl afișează gateway-ul tău. y acceptă un banner de autentificare, așa că șterge acea linie dacă nu există banner și inserează una acolo unde gateway-ul tău pune o întrebare suplimentară. exit final este ceea ce permite clientului să se încheie curat când ultimul răspuns a fost consumat.

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

Modul neinteractiv nu este opțional aici. Fără -s clientul poate prelua terminalul și ignora intrarea redirecționată; cu el, răspunsurile sunt citite din flux și procesul revine. Acolo unde binarul are nevoie de privilegii ridicate, învelește apelul în sudo -n ca scriptul să eșueze imediat în loc să se blocheze la o cerere de parolă.

Unde se scurge fișierul de răspunsuri

Un fișier care conține o parolă este o acreditare, așa că dă-i permisiunile uneia: mod 600, deținut de contul care rulează sarcina, și niciodată într-un director partajat sau sincronizat. Creează-l cu modul deja aplicat în loc să-l repari după, pentru că un fișier este pentru scurt timp citibil de toți între scriere și chmod.

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

Cealaltă jumătate este argv. O parolă transmisă ca argument este vizibilă pentru fiecare utilizator local care listează procese și ajunge și în istoricul shell-ului. Citește-o dintr-un descriptor de fișier sau dintr-o variabilă de mediu, și pune încărcătura între ghilimele ca shell-ul să nu poată extinde nimic în ea.

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

Atenție la ghilimele. Între ghilimele duble, o parolă care conține ! poate fi extinsă de un shell interactiv înainte ca clientul să o vadă, iar eșecul vine ca o eroare generică event-not-found care arată ca o problemă de protocol.

Dovedește tunelul, apoi închide-l

Starea conectat dovedește doar că clientul crede că are o sesiune. Alege o gazdă care răspunde doar din interiorul rețelei corporative și testeaz-o o dată înainte de a face orice altceva. Un eșec acolo este o defecțiune de rutare sau de politică, iar rularea din nou a autentificării nu o va schimba.

/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

Verifică ieșirea stării înainte și după deconectare. Un client lăsat cu o sesiune învechită poate refuza conectarea următoare în timp ce scriptul raportează încă succes, iar acel mod de eșec este invizibil dacă te uiți doar la codurile de ieșire. Compară cele două citiri în loc să te bazezi pe a doua singură. Aliasurile dintr-un profil de shell sunt suficiente pentru uzul zilnic, dar orice lucru programat merită aceeași revizuire a acreditărilor și identității ca orice altă sarcină fără supraveghere.

Când o listă fixă nu mai este sigură

Un fișier de răspunsuri codează ordinea de astăzi a solicitărilor. Un banner schimbat, o schimbare forțată de parolă sau o provocare cu al doilea factor îl transformă într-o buclă care poate bloca contul, de aceea scriptul trebuie să iasă la primul răspuns neașteptat în loc să repornească.

Capturează ce a afișat clientul, returnează un status diferit de zero și lasă decizia apelantului. Acolo unde gateway-ul cere un al doilea factor, răspunsul onest este că autentificarea fără supraveghere nu este disponibilă pentru acel profil, nu că secvenței îi mai trebuie o linie.

Rotația ține de aceeași revizuire. Dacă acreditarea este stocată, decide cine o poate citi, când se schimbă și ce o elimină când gazda este reconstruită. Un script care funcționează un an pentru că nimeni nu a atins parola nu este un proiect, ci un accident care așteaptă o politică de rotație.

Profiluri care nu sunt AnyConnect

Două stiluri mai vechi de acreditări Cisco sunt confundate cu acesta. Un profil vpnc cere un IPSec ID, care de fapt este numele grupului, apoi un secret de grup, apoi propriile tale acreditări, și toate trei vin de la cel care administrează gateway-ul. Cisco IPsec vechi este un protocol diferit de AnyConnect, așa că vpnc nu poate ajunge la un serviciu doar-AnyConnect; openconnect --protocol=anyconnect este clientul deschis pentru acea sarcină.

Un fișier .pcf descrie profilul clientului mai vechi. Gazda, numele grupului și parola de grup din el pot fi reintroduse manual într-un client care vorbește Cisco IPsec, deși fișierul nu este un import universal și orice port sau mod de tunelare care nu este implicit dispare de obicei la transfer.

Începe cu ceea ce oferă gateway-ul de fapt, apoi alege clientul care vorbește acel protocol. Copierea unui profil de pe alt site este modul în care oamenii ajung să depaneze acreditări care nu au fost niciodată problema.