RADIUSin liittäminen OpenVPN:ään: lisäosa vai skriptikoukku?

Lisäosaa suositellaan edelleen ketjuissa, jotka ovat nykyisiä koontiversioita vanhempia, ja eilen käännetyssä palvelimessa se epäonnistuu latauksessa. Kyse ei ole kokoonpanovirheestä, jonka voisi korjata polulla. Lisäosa ja skriptikoukku ratkaisevat saman ongelman eri kerroksissa, ja siirtyminen toisesta toiseen muuttaa sitä, mitä täytyy asentaa, mikä toimii palvelimen oikeuksin ja mitä epäonnistunut kirjautuminen todella kertoo.

Myytti: lisäosa on tuettu polku

Lisäosa on jaettu objekti, joka ladataan OpenVPN-prosessiin, joten sen on vastattava sitä rajapintaa, jonka prosessi tarjoaa. Koontiversiot muuttuvat, paketointi muuttuu, ja vanhemmalle rajapinnalle käännetty kirjasto yksinkertaisesti kieltäytyy latautumasta. Mikään palvelimen kokoonpanossa ei voi siltaa tätä kuilua, siksi neuvo "asenna vain radiusplugin" päättyy palvelimeen, joka ei käynnisty.

Skriptikoukku on sen sijaan prosessin ulkopuolella. OpenVPN suorittaa ohjelman, antaa sille tunnistetiedot ja lukee tuomion takaisin. Juuri tämä irrotus auttaa sitä selviämään päivityksistä, ja se tekee siitä myös vastuusi tavalla, jota lisäosa ei koskaan ollut.

Kumpikaan lähestymistapa ei ole rakenteellisesti turvallisempi. Toinen suorittaa vierasta koodia daemonin sisällä; toinen suorittaa sinun koodisi sen vieressä tunnistetiedot kädessä. Oikea kysymys on, kumpaa näistä kahdesta riskistä voit todella hallita.

Mitä lisäosa sitoi yhteen

Lisäosalla oli oma kokoonpanotiedosto RADIUS-isännällä, jaetulla salaisuudella, uudelleenyritysten määrällä ja aikakatkaisulla, ja palvelimen kokoonpano viittasi siihen yhdellä rivillä. Tunnistetietojen käsittely pysyi palvelinprosessin sisällä, eli salasana ei koskaan ylittänyt prosessirajaa, joka järjestelmänvalvojan oli suojattava.

Hinta oli kytkentä. Jokainen OpenVPN-päivitys riskeerasi yhteensopimattoman rajapinnan, ja jokainen jakelu, joka kokosi paketin uudelleen, riskeerasi kirjaston, joka ei enää vastaa. Kun niin käy, vika on äänekäs ja välitön, ja se on suunnittelun ainoa armo.

Jos tällainen lisäosa vielä latautuu koontiversiossasi, se voi olla pienempi toimintapinta. Vahvista rajapinta, jolle se koottiin, pidä se kiinnitettynä testaamaasi koontiversioon ja kohtele jokaista päivitystä muutoksena, joka vaatii täyden kirjautumistestin, ei rutiininomaista pakettipäivitystä.

Mihin skriptikoukku todella luottaa

Koukku määritetään auth-user-pass-verifyllä ja toimitustavalla: ympäristömuuttujat tai väliaikainen tiedosto. Ympäristömuodossa OpenVPN vaatii script-security 3:n, dokumentoidun tason, joka sallii salasanan paljastamisen skripteille. Tämä taso on tarkoituksellinen oletuksen heikennys, ja sitä tulisi kohdella lupana, johon on liitetty perustelu.

Kaikki, mitä skripti koskee, perii tämän luottamuksen. Sen on oltava rootin omistuksessa, ei ryhmän tai muiden kirjoitettavissa, viitattava absoluuttisella polulla ja vapaa mistä tahansa kohdasta, jossa epäluotettu arvo päätyy komentotulkkiin. Laita jokainen muuttuja lainausmerkkeihin, hylkää odottamattomat merkit äläkä koskaan rakenna komentoa annetusta käyttäjänimestä. Skripti, joka toimii rootina jokaisella kirjautumisyrityksellä, ansaitsee yhden tarkastuksen juuri näiden neljän ominaisuuden vuoksi.

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

Tiedostotoimitustapa välttää ympäristön periytymisen ongelman ja antaa tunnistetiedot skriptille rajoitetuilla oikeuksilla varustetun väliaikaisen tiedoston kautta. Jos asiakkaasi tukee sitä, se on yleensä parempi oletus, vaikka lisää yhden siivottavan objektin epäonnistuessa.

Paluukoodit päättävät, epäonnistutko avoimesti

Skriptin paluutila on tuomio: nolla hyväksyy, ei-nolla hylkää. Ongelmia aiheuttava malli on komentotulkkiskripti, joka hyväksyy vain, kun RADIUS-vastaus sisältää tietyn hyväksyntätunnuksen, ja palauttaa vian kaikelle muulle, koska se sulauttaa kolme eri tapahtumaa yhteen vastaukseen. Väärä salasana, saavuttamaton palvelin ja epämuodostunut vastaus muuttuvat kaikki samaksi hylkäykseksi.

Erottele nämä tapaukset skriptissä, vaikka koukku voi palauttaa vain hyväksynnän tai hylkäyksen. Kirjaa taustajärjestelmän tulos erikseen, hälytä aikakatkaisuista ja siirtovirheistä ja tee valvonnassa selväksi, kun todennus epäonnistuu siksi, että palvelu on alhaalla, eikä siksi, että käyttäjät kirjoittavat väärin.

Kaksi tapaa pitää loput järkevänä. Jos RADIUS on auktoriteetti, sen tulisi olla ainoa paikka, jossa salasana tarkistetaan, koska varjotaulukko luo kaksi vastausta samaan kysymykseen ja toinen on hyökkäyspinta, jota kukaan ei valvo. Ja muista, että koukku kutsutaan uudelleen joka yrityksellä, joten hidas skripti ja kärsimätön asiakas muodostavat salasanojen arvailun vahvistimen, ellet lisää viivettä tai käytäntöä RADIUS-puolelle.

mistä luovut, kun varmenne poistuu

Monet tämän muodon käyttöönotot kytkevät asiakasvarmenteen tarkistuksen kokonaan pois ja jättävät käyttäjänimen ja salasanan asiakkaan koko väitteeksi. Sen asetuksen mukana katoaa varmenneperusteinen identiteetti. Kanava pysyy salattuna, mutta ainoa asiakkaan nimeävä asia on RADIUS-tuomio. Kaiken alavirrassa, mikä ennen perustui varmenteen subjektiin, on nyt perustuttava käyttäjänimeen.

Pidä ohjauskanavan suojaus paikallaan, jotta todennus ei voi tunnustella tai tulvia kättelyä, ja käytä username-as-common-name, kun käyttäjäkohtainen kokoonpano riippuu yhteisnimestä. Hallitut yhdyskäytävät ratkaisevat tämän usein eri tavalla, päättämällä varmenne todentamisen yhdyskäytävällä, joka puhuu EAP-TLS:ää RADIUSin kanssa, ja silloin mikään näistä palvelindirektiiveistä ei päde. Kopioi malli, jonka oma alustasi dokumentoi, älä naapurituotteen mallia. Merkittävät direktiivit eroavat niin paljon, että niiden sekoittaminen tuottaa kokoonpanon, joka jäsennetään ja sitten ei todenna ketään.