Prihlásenie do VPN sa zasekne po Access-Challenge z RADIUS

Access-Challenge nie je ani úspech, ani konečné odmietnutie. Pozrite sa, ako musia NAS, brána a klient preniesť ďalšiu odpoveď v tej istej výmene.

Heslo je správne, prihlásenie do VPN napriek tomu zlyhá a server RADIUS možno urobil presne to, čo mu bolo nariadené. Brána pravdepodobne dostala Access-Challenge, neukázala nič užitočné a potom buď vypršal čas, alebo tú odpoveď považovala za odmietnutie. Z pohľadu klienta to vyzerá ako nesprávne prihlasovacie údaje alebo rozbitý tunel. Príčina zvyčajne leží v strede konverzácie, ktorú nikto nezachytil.

Jedno prihlásenie, dve výmeny s RADIUS

Keď backend chce druhý faktor, neodpovedá na prvú požiadavku prijatím ani odmietnutím. Odpovedá kódom 11 a čaká na ďalšiu odpoveď používateľa, ktorú musí brána poslať späť v nadväzujúcej požiadavke. Táto nadväzujúca požiadavka patrí do tej istej autentizačnej konverzácie, nie do nového pokusu o prihlásenie.

Vo funkčnom nastavení používateľ vidí druhú výzvu: najprv heslo, potom jednorazový kód, alebo jednu kombinovanú výzvu, ak ju operátor zdokumentoval. V rozbitom nastavení sa druhá výzva nikdy neobjaví a prihlásenie jednoducho zlyhá.

To je príznak, ktorý treba sledovať, a dá sa ľahko potvrdiť len z pohľadu klienta: ak klient VPN žiada presne jedno tajomstvo a potom odmietne heslo, o ktorom viete, že je platné, výmena sa pravdepodobne skončila pri výzve.

Čo výzva skutočne nesie

Špecifikácia RADIUS opisuje kód 11 v časti 4.4 a povoľuje dva atribúty, ktoré tu hrajú rolu. Reply-Message obsahuje text určený používateľovi a State obsahuje nepriehľadnú hodnotu, ktorú chce server dostať späť. NAS nemá State interpretovať, iba ho vrátiť nezmenený.

Nadväzujúca požiadavka používa nový Identifier a nový Request Authenticator a musí niesť rovnakú hodnotu State plus odpoveď používateľa. Server ju priraďuje k čakajúcej výzve práve cez tento State, a preto brána, ktorá atribút znova vytvorí alebo zahodí, nemôže obrad dokončiť. Response authenticator v každej odpovedi musí tiež prejsť overením, inak má NAS paket zahodiť.

Časť 4.4 dopĺňa detail, ktorý vysvetľuje väčšinu tichých zlyhaní: NAS, ktorý nevie podporovať výzvy, považuje Access-Challenge za odmietnutie. Ak služba VPN vašej brány túto podporu nemá alebo ju vynecháva, požiadavka backendu na druhý faktor sa zmení na okamžité „autentizácia zlyhala“ bez akejkoľvek výzvy.

Kde sa reťazená požiadavka stráca

Prvým podozrivým je cesta výzvy, nie prihlasovacie údaje. Portál, ktorý pre webové prihlásenia zobrazuje pole OTP, to automaticky nerobí pre službu VPN, a niektoré brány odovzdávajú výzvu len klientom, ktorí túto schopnosť oznamujú. Otestujte ten istý účet na oboch vstupoch; ak portál funguje a VPN nie, pozeráte sa na odovzdanie, nie na token.

Druhým podozrivým je formát vstupu. Spájanie hesla a kódu bez výrobcom zdokumentovaného oddeľovača alebo ponechanie uložených údajov, aby prehrali starý kód, zlyháva spôsobom, ktorý vyzerá rovnako ako nesprávne heslo. Použite operátorom zdokumentovanú samostatnú výzvu alebo kombinovaný formát a nikdy nevymýšľajte oddeľovač.

Defekty špecifické pre vydanie existujú, ale zoznam opravených verzií spred rokov nie je diagnózou pre dnešné nasadenie. Čítajte poznámky k vydaniu softvéru, ktorý skutočne prevádzkujete, a pozorovanú fázu výmeny si ponechajte ako dôkaz.

Sledujte jeden pokus od začiatku do konca

Reprodukujte ho raz so zapnutým ladením na strane servera a všetky ostatné relácie držte mimo zachytávaného okna:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

Vo výstupe hľadajte tvar konverzácie, nie jediný riadok. Prvý Access-Request s Identifier 3, Access-Challenge nesúci State, potom druhý Access-Request s Identifier 4, ktorý ten State opakuje a obsahuje odpoveď používateľa. Ak druhý pokus chýba, brána nikdy nenadviazala. Ak dorazí bez State, server ho nemôže priradiť k čakajúcej výzve a zvyčajne ho odmietne.

Pri zdieľaní stopy zredukujte prihlasovacie údaje, tokeny a nepotrebné identitné údaje a korelujte udalosti z jedného pokusu namiesto miešania opakovaní z viacerých kariet prehliadača. Časové pečiatky sú tu váš priateľ; výzva, ktorá dorazí po tom, čo klient vzdal, vyzerá pre používateľa ako odmietnutie a v logu ako pomalá odpoveď.

Konečný stav, ktorý chcete, je dokončená, autorizovaná konverzácia nasledovaná zamýšľaným prístupom k službe. Odpoveď prichádzajúca zo servera RADIUS dokazuje oveľa menej.

Súvisiace články