Miten OpenConnect muuttaa kirjautumisevästeen tunneliksi?

OpenConnect sitoo kaksi erillistä vaihtoa yhteen lyhytikäiseen arvoon: verkkokirjautumisen ja VPN-tunnelin. Ensimmäinen vaihto on tavallinen HTTPS: tunnistetiedot, SAML-edestakaisinmatka tai token menevät yhdyskäytävälle, ja vastaus kantaa todentamisevästeen. Toinen vaihto esittää tämän evästeen samalle yhdyskäytävälle todisteena siitä, että verkkövaihe on jo tapahtunut, ja vasta sitten tunneli nousee.

Kirjautumisen aikana tunnelista ei neuvotella mitään. Juuri se on ymmärtämisen arvoista, koska useimmat skriptivirheet olettavat evästeen olevan tallennettava salasana tai liikennettä suojaava avain, vaikka se on todellisuudessa haltijalippu tiettyä yhdyskäytäväistuntoa varten.

Mitä asiakas ja yhdyskäytävä vaihtavat, järjestyksessä

Todennusvaihe näyttää tavalliselta suojatulta verkkosivustolta. OpenConnect lähettää käyttäjän tunnistetiedot tai seuraa yhdyskäytävän uudelleenohjausta identiteetintarjoajalle, ja yhdyskäytävä vastaa asiakirjalla, joka upottaa todentamisevästeen. AnyConnect-protokollassa tämä arvo kulkee evästeotsakkeessa seuraavissa pyynnöissä, yleensä nimellä kuten webvpn, ja käsikirja kohtelee sitä tunnistetietona, joka vie istuntoa eteenpäin.

Toinen vaihe on CONNECT-pyyntö yhdyskäytävän VPN-päätepisteeseen eväste liitettynä. Yhdyskäytävä tarkistaa sen, antaa osoitteen, ja asiakas käynnistää CSTP:n TLS:n päällä, kun taas DTLS on valinnainen nopeampi datapolku, kun istunto on olemassa. Vasta tässä vaiheessa tunnelin parametrit, reitit, DNS-asetukset ja istunnon liikenneavaimet vahvistetaan. Eväste päästi asiakkaan ovesta läpi; se ei salannut mitään.

Tämä järjestys selittää, miksi openconnect --authenticate on olemassa. Suorita se, niin se tekee verkkövaiheen, tulostaa pienen lohkon shell-muuttujia kuten COOKIE, HOST, CONNECT_URL ja FINGERPRINT ja päättyy ennen kuin mitään tunnelia rakennetaan. Käärintäskripti voi sitten käynnistää varsinaisen yhteyden näillä arvoilla, ja juuri se on se jako, jota headless-käyttöönotto tai kahden kontin käyttöönotto tarvitsee.

Eväste on istunnon haltija, ei avain

Käsittele arvoa kuin käsittelisit istuntotunnistetta verkkosovelluksessa. Kuka tahansa sen elinaikana sitä pitävä voi pyytää yhdyskäytävältä tunnelin, johon kyseinen istunto on oikeutettu, joten sen salaisuus on tärkeä. Kopioiminen ei kuitenkaan paljasta liikennettä, koska tunnelin luottamuksellisuus tulee TLS-kättelystä ja johdetuista avaimista, ei evästemerkkijonosta.

Se ei ole myöskään pysyvä myönnytys. Yhdyskäytävä ja identiteetintarjoaja päättävät, kuinka kauan istunto elää, eikä selain, joka yhä näyttää kirjautuneena olevaa sivua, kerro mitään siitä, onko tunnelistunto vielä voimassa. Uudelleenyhdistäminen vanhenemisen jälkeen tarkoittaa verkkövaiheen toistamista ja tuoreen evästeen tuottamista, ja juuri se on uudelleentodennuksen tarkoitus, ei harmi, joka pitäisi kiertää tekniikalla.

Älä kohtele evästettä muiden tunnistetietojen yleisenä korvaajana. SAML-väite, selaimen salasana ja toisen palvelun myöntämä eväste ovat eri objekteja, joilla on eri yleisöt, ja yhden liittäminen toisen kenttään epäonnistuu yleensä yhdyskäytävällä tai, mikä pahempaa, onnistuu väärää luottamusrajaa vastaan.

Evästeen välittäminen kopioita jättämättä

Turvallisin mekaaninen luovutus Linuxissa on vakiosyöte. --cookie-on-stdin lukee arvon stdinistä, joten eväste ei koskaan näy prosessin argumenttiluettelossa, josta kuka tahansa paikallinen käyttäjä voi lukea sen komennolla ps. Putki, joka todentaa yhdessä prosessissa ja ruokkii tunnelia toisessa, pitää arvon putkessa eikä tiedostossa tai ympäristömuuttujassa.

Argumentit ja ympäristömuuttujat ovat heikompia eri syistä. Argumentti on näkyvissä prosessitaulukossa asiakkaan koko eliniän ja päätyy usein shellin historiaan. Ympäristömuuttuja periytyy lapsiprosesseille, ja systemd-yksikkö, joka asettaa sen yksikkötiedostossa, tallentaa salaisuuden luettavaan kokoonpanoon. Jos tiedosto on välttämätön, rajaa se palvelutilille ja poista se istunnon päättyessä.

Pidä myös käyttöoikeusraja tarkoituksellisena. Prosessin, joka puhuu identiteetintarjoajan kanssa ja mahdollisesti avaa selaimen, tulisi ajaa käyttäjänä, jolle kyseinen kirjautuminen kuuluu. Prosessi, joka konfiguroi reitit, DNS:n ja tunnelilaitteen, voi tarvita enemmän oikeuksia. Koko selaimen ajaminen rootina, jotta sen eväste olisi rootin omistaman tunnelin saatavilla, on väärä vaihtokauppa, ja nykyaikaiset OpenConnect-asennukset voivat välittää arvon tämän rajan yli nimenomaisesti.

Lokitus ansaitsee saman epäluulon. Yksityiskohtainen asiakastuloste, apuskriptit ja yhdyskäytävän diagnostiikka voivat kaikki toistaa pyyntöaineistoa, eikä jokainen lokitustaso peitä evästettä. Tallenna pienin tarvitsemasi virhetietue, pidä se poissa jaetuilta kanavilta ja tarkista peitetty näyte ennen sen liittämistä tikettiin.

Varmennus ja vanheneminen toisessa vaiheessa

Toisen vaiheen on yhä varmennettava palvelin. FINGERPRINT, jonka --authenticate tulostaa, on varmennekiinnitys muodossa pin-sha256:, ja sen välittäminen tunnelikutsulle valitsimella --servercert pitää tarkistuksen ankkuroituna siihen yhdyskäytävään, jota vasten todensit. Varmenteen tarkistuksen poistaminen käytöstä skriptin yksinkertaistamiseksi poistaa ainoan todisteen siitä, että eväste luovutetaan aiotulle isännälle.

Kun yhdyskäytävä hylkää evästeen, ratkaisu on uusi todennuskierros, ei pidempi välimuisti. Säilytä evästettä vain yhteyden eliniän, poista väliaikaistiedostot lopetuksessa ja käytä identiteetintarjoajan tai yhdyskäytävän istunnonpoistoprosessia, kun istunto paljastuu tai laite katoaa. Välimuistiin tallennettu eväste ei ole vapautus MFA:sta.

Ennen kuin automatisoit tämän, varmista neljä asiaa: tunneli toimii oikealla tilillä, eväste saapuu stdinin kautta, varmenteen sormenjälki on kiinnitetty ja istunto hylätään, kun tunneli sulkeutuu. Jos jokin näistä puuttuu, automaatio on laajentanut luottamusta evästeeseen sen sijaan, että se toistaisi manuaalisen kulun.