AnyConnect Linuxon: a bejelentkezési sorrend biztonságos szkriptelése

A Cisco AnyConnecttel érkező vpn kliens úgy viselkedik, mint egy beszélgetés: kiír egy kérdést, vár egy sort, majd kiírja a következőt. Tápláld ezt a beszélgetést fájlból vagy csőből, és ugyanaz a bináris felügyelet nélkül fut. A technika egy átirányítás és egy rendezett válaszlista, és a lista, nem az átirányítás dönti el, hogy a szkript megbízható-e.

A gyakorlatban két dolog töri ezt el. A kérdések sorrendje elmozdul, ha az átjáró valami pluszt kérdez, és egy tárolt jelszó egyetlen elgépelést fiókzárolássá tesz. Kezeld a sorrendet verziózott adatként, amit bármely átjáróváltozás után össze tudsz vetni. Hangosan hibázz újrapróbálkozás helyett, mert pont a ciklus az, ahogy egy elgépelt jelszóból zárolt fiók lesz.

Egy sorrend, abban a sorrendben, ahogy a kliens kérdez

Futtasd a klienst egyszer interaktívan, és írj fel minden kérdést abban a sorrendben, ahogy megjelenik. Ez a leirat lesz a válaszfájl. Amikor a fájlt a binárisba irányítod, az első sornak magának a kapcsolódási parancsnak kell lennie, ezért a sorrend hosztnévvel kezdődik, nem felhasználónévvel.

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

A csupasz 0 az első kapcsolati profilt választja, amikor az átjáró listát kínál; használd azt az indexet, amit az átjáród kiír. A y elfogad egy bejelentkezési bannert, ezért töröld azt a sort, ha nincs banner, és szúrj be egyet ott, ahol az átjáród további kérdést tesz fel. A záró exit az, ami a kliensnek tisztán lezárulni enged, amikor az utolsó válasz elfogyott.

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

A nem interaktív mód itt nem választható. -s nélkül a kliens átveheti a terminált és figyelmen kívül hagyhatja az átirányított bemenetet; vele a válaszok az adatfolyamból olvasódnak, és a folyamat visszatér. Ahol a bináris emelt jogosultságot igényel, csomagold a hívást sudo -n alá, hogy a szkript azonnal meghiúsuljon, ahelyett hogy jelszókérésnél blokkolna.

Ahol a válaszfájl szivárog

A jelszót tartalmazó fájl hitelesítő adat, ezért annak engedélyeit add neki: 600-as mód, a feladatot futtató fiók tulajdonában, és soha nem megosztott vagy szinkronizált könyvtárban. Már alkalmazott móddal hozd létre, ne utólag javítsd, mert a fájl az írás és a chmod között rövid ideig mindenki számára olvasható.

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

A másik fele az argv. A paraméterként átadott jelszó látható minden helyi felhasználónak, aki folyamatokat listáz, és a shell-előzményekbe is bekerül. Inkább fájlleíróból vagy környezeti változóból olvasd, és tedd a terhet idézőjelek közé, hogy a shell semmit ne tudjon benne kiterjeszteni.

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

Figyelj az idézőjelezésre. Kettős idézőjelek között egy ! tartalmazó jelszót egy interaktív shell ki tud terjeszteni, mielőtt a kliens egyáltalán látná, és a hiba általános event-not-found hibaként érkezik, ami protokollproblémának látszik.

Bizonyítsd az alagutat, aztán zárd be

A csatlakoztatott állapot csak azt bizonyítja, hogy a kliens azt hiszi, van munkamenete. Válassz olyan hosztot, amely csak a vállalati hálózat belsejéből válaszol, és próbáld ki egyszer, mielőtt bármi mást tennél. Az ottani hiba útvonalválasztási vagy szabályzati hiba, és a bejelentkezés újrafuttatása nem változtat rajta.

/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

Ellenőrizd az állapotkimenetet a bontás előtt és után. A clavult munkamenettel hagyott kliens elutasíthatja a következő kapcsolódást, miközben a szkript még sikert jelent, és ez a hibaüzemmód láthatatlan, ha csak a kilépési kódokat nézed. Hasonlítsd össze a két leolvasást, ne bízz a másodikban önmagában. A shell-profil aliasai elegendőek a napi használathoz, viszont minden ütemezett dolog ugyanazt a hitelesítőadat- és identitásfelülvizsgálatot érdemli, mint bármely más felügyelet nélküli munka.

Amikor egy rögzített lista már nem biztonságos

A válaszfájl a mai kérdéssorrendet kódolja. Egy megváltozott banner, egy kényszerített jelszócsere vagy egy második tényezős kihívás olyan ciklussá teszi, amely zárolhatja a fiókot, ezért a szkriptnek az első váratlan válasznál ki kell lépnie, nem újraindulnia.

Rögzítsd, mit írt ki a kliens, adj vissza nem nulla állapotot, és hagyd a döntést a hívónak. Ahol az átjáró második tényezőt követel, az őszinte válasz az, hogy felügyelet nélküli bejelentkezés nem elérhető ahhoz a profilhoz, nem az, hogy a sorrendnek még egy sor kell.

A rotáció ugyanahhoz a felülvizsgálathoz tartozik. Ha a hitelesítő adat tárolva van, döntsd el, ki olvashatja, mikor változik, és mi távolítja el, amikor a hoszt újraépül. Egy szkript, amely egy évig működik, mert senki nem nyúlt a jelszóhoz, nem tervezés, hanem baleset, amely egy rotációs szabályzatra vár.

Profilok, amelyek nem AnyConnectek

Két régebbi Cisco hitelesítőadat-stílust kevernek össze ezzel. Egy vpnc profil IPSec ID-t kér, ami valójában a csoport neve, majd csoporttitkot, majd a saját hitelesítő adataidat, és mindhárom attól jön, aki az átjárót üzemelteti. A régi Cisco IPsec más protokoll, mint az AnyConnect, ezért a vpnc nem ér el csak-AnyConnect szolgáltatást; a openconnect --protocol=anyconnect a nyílt kliens erre a munkára.

Egy .pcf fájl a régebbi kliensprofilt írja le. A benne lévő hoszt, csoportnév és csoportjelszó kézzel újra beírható egy Cisco IPsecet beszélő kliensben, bár a fájl nem univerzális import, és bármely nem alapértelmezett port vagy alagút mód általában elvész az átvitelben.

Kezdd azzal, amit az átjáró valóban kínál, aztán válaszd ki a klienst, amely azt a protokollt beszéli. Egy profil más telephelyről való másolása az az út, amelyen az emberek olyan hitelesítő adatok hibakereséséhez jutnak, amelyek soha nem voltak a probléma.