RADIUS in OpenVPN koppel: inprop of scripthaak?

Die inprop word steeds aanbeveel in drade wat ouer as die huidige bouwe is, en dit misluk by laai op 'n bediener wat gister gekompileer is. Dit is nie 'n konfigurasiefout wat jy met 'n pad kan regstel nie. Die inprop en die scripthaak los dieselfde probleem op verskillende vlakke, en om van die een na die ander te skuif verander wat geïnstalleer moet word, wat met bedienerregte loop, en wat 'n mislukte aanmelding jou eintlik vertel.

Die mite: die inprop is die ondersteunde pad

Die inprop is 'n gedeelde objek wat in die OpenVPN-proses gelaai word, so dit moet by die koppelvlak pas wat daardie proses blootstel. Bouwe verander, verpakking verander, en 'n biblioteek wat vir 'n ouer koppelvlak gekompileer is, sal eenvoudig weier om te laai. Niks in die bedienerkonfigurasie kan daardie gaping oorbrug nie, en daarom eindig die raad om "net radiusplugin te installeer" met 'n bediener wat nie begin nie.

Die scripthaak sit eerder buite die proses. OpenVPN voer 'n program uit, gee die geloofsbriewe daaraan en lees 'n uitspraak terug. Daardie ontkoppeling is wat dit opgraderings laat oorleef, en dit is ook wat dit jou verantwoordelikheid maak op 'n manier wat die inprop nooit was nie.

Nie een benadering is konstruksiegewys veiliger nie. Die een laat vreemde kode in die daemon loop; die ander laat jou kode daarnaas loop met die geloofsbriewe in die hand. Die regte vraag is watter van daardie twee risiko's jy werklik kan bedryf.

Wat die inprop saamgebind het

Die inprop het sy eie konfigurasielêer met die RADIUS-gasheer, gedeelde geheim, herprobeerspogings en tydlimiet gedra, en die bedienerkonfigurasie het daarna met een reël verwys. Geloofsbriefhantering het binne die bedienerproses gebly, wat beteken het dat die wagwoord nooit 'n prosesgrens oorgesteek het wat die administrateur moes beveilig nie.

Die koste was koppeling. Elke OpenVPN-opgradering het 'n onversoenbare koppelvlak in die vooruitsig gestel, en elke verspreiding wat die pakket herbou het, het die risiko geloop om 'n biblioteek te lewer wat nie meer pas nie. Wanneer dit gebeur, is die mislukking hard en onmiddellik, en dit is die een genade van die ontwerp.

As so 'n inprop nog op jou bou laai, kan dit die kleiner operasionele oppervlak wees. Bevestig die koppelvlak waarteen dit gebou is, hou dit vasgepen aan die bou wat jy getoets het, en behandel enige opgradering as 'n verandering wat 'n volledige aanmeldingstoets vereis eerder as 'n roetine-pakketopdatering.

Waarop die scripthaak werklik vertrou

Die haak word met auth-user-pass-verify en 'n afleweringsmeganisme opgestel: omgewingsveranderlikes of 'n tydelike lêer. Met die omgewingsvorm vereis OpenVPN script-security 3, die gedokumenteerde vlak wat wagwoordblootstelling aan skripte toelaat. Daardie vlak is 'n doelbewuste verswakking van die verstek, en dit moet behandel word as 'n toestemming met 'n regverdiging daaraan verbonde.

Alles wat die skrip aanraak, erf daardie vertroue. Dit moet deur root besit word, nie deur groep of ander beskryfbaar wees nie, deur 'n absolute pad verwys word, en vry wees van enige plek waar 'n onvertroude waarde 'n dop bereik. Omring elke veranderlike met aanhalingstekens, verwerp onverwagte karakters, en bou nooit 'n opdrag uit die verskafde gebruikersnaam nie. 'n Skrip wat by elke aanmeldpoging as root loop, is werd om een keer juis vir daardie vier eienskappe na te gaan.

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

Die lêerafleweringsvorm vermy die probleem van omgewings-erfenis en gee die geloofsbriewe aan die skrip deur 'n tydelike lêer met beperkte regte. As jou kliënt dit ondersteun, is dit gewoonlik die beter verstek, al voeg dit een meer objek by om by mislukking op te ruim.

Uittreëkodes bepaal of jy oop val

Die skrip se uittreestatus is die uitspraak: nul aanvaar, nie-nul verwerp. Die patroon wat moeilikheid veroorsaak, is 'n dopskrip wat net aanvaar wanneer die RADIUS-antwoord 'n spesifieke aanvaardingsteken bevat en vir alles anders mislukking teruggee, want dit val drie verskillende gebeure in een antwoord saam. 'n Verkeerde wagwoord, 'n onbereikbare bediener en 'n misvormde antwoord word almal dieselfde verwerping.

Skei daardie gevalle in die skrip, selfs al kan die haak net aanvaar of verwerp teruggee. Teken die backend-uitkoms apart aan, waarsku oor tydlimiete en vervoerfoute, en maak dit duidelik in monitering wanneer verifikasie misluk omdat die diens af is eerder as omdat gebruikers verkeerd tik.

Twee gewoontes hou die res verstandig. As RADIUS die gesag is, moet dit die enigste plek wees waar 'n wagwoord nagegaan word, want 'n skadutabel skep twee antwoorde op dieselfde vraag en die tweede een is 'n aanvalsoppervlak wat niemand dophou nie. En onthou die haak word by elke herprobeerspoging weer geroep, so 'n stadige skrip tesame met 'n ongeduldige kliënt word 'n versterker vir wagwoordraai tensy jy vertraging of 'n beleid aan die RADIUS-kant byvoeg.

Wat jy prysgee wanneer die sertifikaat verdwyn

Baie ontplooiings in hierdie vorm skakel kliëntsertifikaatkontrole heeltemal af en laat 'n gebruikersnaam en 'n wagwoord as die hele aanspraak van die kliënt. Wat met daardie instelling verdwyn, is sertifikaatgebaseerde identiteit. Die kanaal bly versleutel, maar die enigste ding wat die kliënt benoem, is die RADIUS-uitspraak. Enigiets stroomaf wat vroeër op 'n sertifikaatonderwerp gesleutel het, moet nou eerder op die gebruikersnaam sleutel.

Hou beheer-kanaalbeskerming in plek sodat 'n onverifieerde eweknie nie die handdruk kan ondersoek of oorstroom nie, en gebruik username-as-common-name wanneer per-gebruiker-konfigurasie van die common name afhang. Bestuurde poorte los dit dikwels anders op, deur sertifikaatverifikasie by 'n poort te beëindig wat EAP-TLS met RADIUS praat, en in daardie geval geld geen van hierdie bedieneropdragte nie. Kopieer die model wat jou eie platform dokumenteer, nie die een van 'n naburige produk nie. Die opdragte wat saak maak, verskil genoeg dat om hulle te meng 'n konfigurasie lewer wat ontleed en dan niemand verifieer nie.