Jinsi kuingia VPN kunafikia RADIUS na mtoa huduma wako wa utambulisho

Wiki iliyopita mtumiaji aliweza kuingia kwenye VPN na bado akaishia kwenye mtandao ambapo hakuna kitu kilitatuliwa. Mteja alisema ameunganishwa, kumbukumbu ya lango ilisema Access-Accept, na timu ya utambulisho ilisema akaunti iko sawa. Kuingia kulifanya kazi; idhini iliyokuwa nyuma yake haikufanya kazi. Wakati kuingia VPN kunashindikana, ninafuata njia ambayo ombi huchukua kwa kweli — mteja, lango, seva ya RADIUS, mtoa huduma wa utambulisho — na nasimama kwenye hatua ya kwanza ambayo jibu lake halilingani na linalofuata.

Mteja huzungumza RADIUS kamwe

Chochote ambacho programu kwenye kompyuta ndogo inaonyesha, hatua yake ya kwanza ni itifaki ya VPN: IKEv2, OpenVPN, WireGuard au mteja unaotegemea TLS. RADIUS haionekani katika mabadilishano hayo. Mteja anajithibitisha kwa lango kwa cheti, jina la mtumiaji na nenosiri, au mbinu ya EAP inayobebwa ndani ya usanidi wa handaki.

Hilo ni muhimu unaposoma kumbukumbu, kwa sababu hitilafu ya jumla ya uthibitishaji ambayo mtumiaji huona huzalishwa na lango baada ya kuwa limeshaongea na kitu kingine. Ikiwa mteja hafiki kamwe kwenye lango, hakuna ombi la RADIUS la kurekebisha, na saa moja kwenye seva ya RADIUS hupotea. Thibitisha kwamba handaki liliinuka kabisa kabla ya kugusa backend.

Lango ni mteja wa RADIUS

Mara tu usanidi wa handaki unapofikia mahali ambapo vitambulisho vinapaswa kukaguliwa, lango linakuwa seva ya ufikiaji wa mtandao. Huunda Access-Request: User-Name, nenosiri au mzigo wa EAP, NAS-IP-Address au NAS-Identifier, na Message-Authenticator wakati mbinu inahitaji. Ombi huenda kwa UDP 1812 kwa chaguo-msingi, na uhasibu kwa 1813. Usanidi wa zamani bado unatumia 1645 na 1646, kwa hiyo kanuni ya firewall iliyoandikwa kwa jozi moja inaeleza kushindikana nyingi za kimya.

Pande zote mbili zinashiriki siri, na hiyo si kitambulisho cha mtumiaji. Inatia saini mabadilishano, na kila jibu huthibitishwa dhidi yake. Sanidi siri kwa njia tofauti pande zote mbili na seva haijibu kwa siri mbaya — inatupa ombi au jibu linashindwa uthibitishaji, kwa hiyo lango linaripoti muda kuisha. Siri isiyo sahihi na seva iliyokufa zinaonekana sawa kutoka kwenye lango, kwa hiyo hupima hatua hiyo kwa chombo cha mteja kabla ya kulaumu saraka.

Itifaki ni ndogo na ya zamani — RFC 2865 inafafanua mabadilishano ya uthibitishaji — lakini sifa inazobeba ndizo msingi ambao sera nyingi za VPN zimejengwa juu yake.

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

Seva ya RADIUS inaweza kuwa sehemu ya mbele ya mtoa huduma wa utambulisho pekee

Watu huzungumza kuhusu RADIUS na mtoa huduma wa utambulisho kana kwamba ni sanduku moja. Mara nyingi sivyo. Seva ya RADIUS hupokea Access-Request na kisha huuliza kitu kingine kabla ya kujibu — Active Directory kupitia LDAP au Kerberos, faili ya mtumiaji ya ndani au huduma ya nje. FreeRADIUS yenye moduli ya LDAP au krb5, Windows NPS na Cisco ISE zote zinasimama katika nafasi hii.

Tofauti hiyo huamua wapi uangalie. Nenosiri lililokataliwa ni jibu la mtoa huduma wa utambulisho ambalo RADIUS hupitisha. Muda kuisha kwa kawaida ni sehemu ya RADIUS-hadi-saraka: akaunti ya bind iliyoisha muda, saraka isiyofikiwa, au ombi lililoelekezwa kwenye backend isiyo sahihi. Ikiwa jina la mtumiaji lina kiambishi cha kikoa, seva inaweza kuelekeza kwa msingi wake, na akaunti hiyo hiyo iliyotumwa kama CORP\alice na [email protected] inaweza kuishia maeneo tofauti. Katika Windows NPS, kumbukumbu ya Security hurekodi 6272 kwa kutoa na 6273 kwa kukataa, ambayo inakuambia kama uamuzi ulitoka kwa NPS.

Soma kushindikana kwenye hatua iliyokizalisha

Ujumbe mmoja wa hauwezi kuunganisha unashughulikia kushindikana kune tofauti. Kabla ya kubadilisha chochote, linganisha dalili na hatua iliyokizalisha.

Mstari wa mwisho ndio unaowatuma watu kwa timu isiyo sahihi. Access-Accept inamaanisha vitambulisho vilikubaliwa; haimaanishi lango liliweka mtumiaji kwenye dimbwi sahihi au likasukuma njia. Sifa za kikundi ni muhimu tu ikiwa sera ya lango inazisoma. Nimeona kuingia sahihi kukiishia kwenye dimbwi la wageni kwa sababu uchoraji wa ramani wa vikundi ulikuwa umesanidiwa upande wa RADIUS kwa sifa tofauti na ile ambayo lango hukagua.

Fuatilia kuingia kumoja kutoka mwanzo hadi mwisho

Chagua akaunti moja ya majaribio na lango moja, kisha angalia jaribio lilelile katika sehemu zote nne. Anzisha uendeshaji wa urekebishaji upande wa RADIUS — freeradius -X huchapisha ombi na kila moduli inayogusa — fuatilia kumbukumbu ya uthibitishaji ya lango, na endesha tcpdump kwa mabadilishano ya UDP. Ungana mara moja na usome alama nne kwa mpangilio.

Unachotaka kuona ni makubaliano: lango liliuliza kuhusu mtumiaji uliyemtarajia, seva ya RADIUS ilichagua backend uliyoitarajia, backend hiyo ilirudisha uamuzi, na sifa zilizo kwenye jibu zinalingana na sera ambayo lango hutumia. Mahali pa kwanza ambapo alama hazikubaliani ni mstari wako wa hitilafu. Ikiwa jibu halibebi sifa ya kikundi, tatizo liko upande wa RADIUS, si kwenye wasifu wa VPN; ikiwa sifa ipo na lango linaipuuza, sera ya lango ndilo tatizo.

Kumbuka moja la usalama ukiwa huko. Siri inayoshirikiwa hulinda mabadilishano, lakini haisimbi sifa nyingi. Ikiwa lango na seva ya RADIUS ziko kwenye sehemu tofauti, weka hatua hiyo kwenye RADIUS kupitia TLS au njia ya kibinafsi. Handaki la mtumiaji lililosimbwa halisemi chochote kuhusu kiungo cha backend.

Kabla ya kufunga tikiti, thibitisha mambo manne. Lango linaweza kufikia seva ya RADIUS kwenye bandari ambayo imesanidiwa kweli. Siri inayoshirikiwa inalingana pande zote mbili. Seva ya RADIUS hutatua umbo kamili la jina la mtumiaji ambalo lango hutuma. Kukubaliwa hubeba sifa ambazo sera ya lango inahitaji. Mambo yote manne yakiwa sawa, kuingia ambako bado kunashindikana ni tatizo la sera ya lango, si la uthibitishaji.