RADIUS oan OpenVPN keppelje: plugin of skriptheak?

De plugin wurdt noch altyd oanret yn diskusjes dy't âlder binne as de hjoeddeiske builds, en hy mislearret by it laden op in server dy't juster kompilearre is. Dat is gjin konfiguraasjeflater dy't jo mei in paad oplosse kinne. De plugin en de skriptheak losse itselde probleem op ferskate lagen op, en fan de iene nei de oare gean feroaret wat ynstallearre wurde moat, wat mei serverrjochten rint, en wat in mislearre oanmelding jo eins fertelt.

De myte: de plugin is it stipe paad

In plugin is in dield objekt dat yn it OpenVPN-proses laden wurdt, dus it moat passe by de ynterface dy't dat proses bleatleit. Builds feroarje, ferpakking feroaret, en in bibleteek kompilearre foar in âldere ynterface wegeret gewoan te laden. Neat yn 'e serverkonfiguraasje kin dy kleau oerbringe, dêrom einiget it advys "ynstallearje gewoan radiusplugin" mei in server dy't net start.

De skriptheak stiet ynstee bûten it proses. OpenVPN fiert in programma út, jout it de oanmeldgegevens en lêst in oardiel werom. Dy ûntkeppeling is wat it oerlibje lit by upgrades, en it is ek wat it jo ferantwurdlikheid makket op in manier dy't de plugin nea wie.

Gjin fan beide oanpakken is by konstruksje feiliger. De iene fiert frjemde koade yn 'e daemon út; de oare fiert jo koade njonken him út mei de oanmeldgegevens yn 'e hân. De juste fraach is hokker fan dy twa risiko's jo wier beheare kinne.

Wat de plugin byinoar bûn

De plugin hie syn eigen konfiguraasjebestân mei de RADIUS-host, it dielde geheim, it oantal besikings en de time-out, en de serverkonfiguraasje ferwiisde der mei ien rigel nei. It behanneljen fan oanmeldgegevens bleau yn it serverproses, wat betsjutte dat it wachtwurd nea in prosesgrins oerstiek dy't de behearder feilichje moast.

De priis wie keppeling. Eltse OpenVPN-upgrade rûn it risiko fan in ynkompatibele ynterface, en eltse distribúsje dy't it pakket op 'e nij boude rûn it risiko om in bibleteek te meitsjen dy't net mear paste. As dat bart, is de mislearring lûd en daliks, en dat is de iennichste genede fan it ûntwerp.

As sa'n plugin noch op jo build laden wurdt, kin it it lytsere operasjonele oerflak wêze. Befêstigje de ynterface wêrop't er boud is, hâld him fêst oan 'e build dy't jo test hawwe, en behannelje elke upgrade as in feroaring dy't in folsleine oanmeldtest freget, net as in routinemjittige pakketfernijing.

Wêrop de skriptheak wier fertrout

De heak wurdt konfigurearre mei auth-user-pass-verify en in leveringsmeganisme: omjouwingsfariabelen of in tydlik bestân. By de omjouwingsfoarm freget OpenVPN script-security 3, it dokumintearre nivo dat wachtwurdbleatstelling oan skripts tastean. Dat nivo is in bewuste ferswakking fan 'e standert, en it moat behannele wurde as in tastimming mei in begrûning derby.

Alles wat it skript oanrekket, erft dat fertrouwen. It moat eigendom wêze fan root, net skriuwber foar groep of oaren, ferwiisd wurde mei in absolút paad, en frij wêze fan elke plak dêr't in net fertroudwearde in shell berikt. Sette elke fariabele tusken oanhellingstekens, wiis ûnferwachte tekens ôf, en bou nea in opdracht fan 'e oanlevere brûkersnamme. In skript dat by elke oanmeldpoging as root rint, fertsjinnet ien kear in resinsje krekt foar dy fjouwer eigenskippen.

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

De bestânsleveringsfoarm foarkomt it probleem fan omjouwingserving en jout de oanmeldgegevens oan it skript fia in tydlik bestân mei beheinde rjochten. As jo klant it stipet, is it meastal de bettere standert, al foeget it noch ien objekt ta om by mislearring op te romjen.

Utgongskoades beslute oft jo iepen mislearje

De utgongsstatus fan it skript is it oardiel: nul akseptearret, net-nul wiist ôf. It patroan dat problemen feroarsaket is in shell-skript dat allinnich akseptearret as it RADIUS-antwurd in bepaald akseptaasjetoken befettet en foar al it oare mislearring weromjout, want dat smelt trije ferskate barrens yn ien antwurd gear. In ferkeard wachtwurd, in net berikbere server en in misfoarme antwurd wurde allegear deselde ôfwizing.

Skied dy gefallen yn it skript, sels as de heak allinnich akseptearje of ôfwize weromjaan kin. Log it backend-resultaat apart, alarmearje by time-outs en transportflaters, en meitsje it dúdlik yn monitoring as autentikaasje mislearret om't de tsjinst del is en net om't brûkers ferkeard type.

Twa gewoanten hâlde de rest sûn. As RADIUS de autoriteit is, moat it it iennichste plak wêze dêr't in wachtwurd kontrolearre wurdt, want in skade-tabel makket twa antwurden op deselde fraach en it twadde is in oanfalsoerflak dat nimmen besjocht. En tink derom dat de heak by elke besiking wer oproppen wurdt, dus in stadich skript mei in ûngeduldige klant wurdt in fersterker foar wachtwurdrêden, útsein as jo fertraging of in belied oan 'e RADIUS-kant tafoegje.

Wat jo opjouwe as it sertifikaat ferdwynt

In protte útrolen fan dizze foarm skeakelje klantsertifikaatkontrôle folslein út, en litte in brûkersnamme en in wachtwurd as de hiele oanspraak fan 'e klant. Wat mei dy ynstelling ferdwynt, is sertifikaatbasearre identiteit. It kanaal bliuwt fersifere, mar it iennichste dat de klant neamt is it RADIUS-oardiel. Alles stroomôf dat earder op in sertifikaatsubjekt boude, moat no op 'e brûkersnamme bouwe.

Hâld kontrôlekanaalbeskerming yn plak sadat in net-autentisearre peer de hânskudding net probearje of oerstreamje kin, en brûk username-as-common-name as konfiguraasje per brûker fan 'e mienskiplike namme ôfhinklik is. Behearde poarten lossen dit faak oars op, troch sertifikaatautentikaasje te beëinigjen by in poarte dy't EAP-TLS mei RADIUS praat, en yn dat gefal jildt gjin fan dizze serverdirektiven. Kopiearje it model dat jo eigen platfoarm dokumintearret, net dat fan in oanbuorjend produkt. De direktiven dy't der ta dogge ferskille genôch dat it mingen derfan in konfiguraasje jout dy't parsearre wurdt en dan nimmen autentisearret.