A VPN-bejelentkezés elakad egy RADIUS Access-Challenge után

A jelszó helyes, a VPN-bejelentkezés mégis meghiúsul, és a RADIUS-kiszolgáló valószínűleg pontosan azt tette, amit kértek tőle. Az átjáró valószínűleg kapott egy Access-Challenge-et, nem mutatott semmi hasznosat, majd lejárt az időkorlát, vagy elutasításként kezelte ezt a választ. Az ügyfél oldaláról hibás hitelesítő adatoknak vagy törött alagútnak tűnik. Az ok általában egy olyan beszélgetés közepén van, amelyet senki nem rögzített.

Egy bejelentkezés, két RADIUS-eszmecsere

Amikor a háttérrendszer második tényezőt kér, nem fogadással vagy elutasítással válaszol az első kérésre. A 11-es kóddal válaszol, és megvárja a felhasználó következő válaszát, amelyet az átjárónak egy nyomon követő kérésben vissza kell küldenie. Ez az utánkövető kérés ugyanahhoz a hitelesítési beszélgetéshez tartozik, nem egy új bejelentkezési kísérlethez.

Működő beállításban a felhasználó egy második felszólítást lát: először a jelszót, aztán egy egyszeri kódot, vagy egyetlen kombinált felszólítást, ha az üzemeltető dokumentált ilyet. Hibás beállításban a második felszólítás soha nem jelenik meg, és a bejelentkezés egyszerűen meghiúsul.

Ez a keresendő tünet, és könnyen megerősíthető csak az ügyfél oldaláról: ha a VPN-ügyfél pontosan egy titkot kér, majd elutasít egy jelszót, amelyről tudja, hogy érvényes, az eszmecsere valószínűleg a kihívásnál véget ért.

Mit hordoz valójában a kihívás

A RADIUS-specifikáció a 4.4. szakaszban írja le a 11-es kódot, és két olyan attribútumot engedélyez, amely itt számít. A Reply-Message a felhasználónak szánt szöveget tartalmazza, a State pedig egy átlátszatlan értéket, amelyet a kiszolgáló visszakapni szeretne. A NAS-nak nem kell értelmeznie a State-et, csak változatlanul visszaadnia.

Az utánkövető kérés új Identifiert és új Request Authenticatort használ, és ugyanazt a State-értéket plusz a felhasználó válaszát kell hordoznia. A kiszolgáló ezen State alapján párosítja a várakozó kihíváshoz, ezért az átjáró, amely újragenerálja vagy eldobja az attribútumot, nem tudja befejezni a szertartást. A response authenticatort minden válaszban validálni kell, különben a NAS-nak el kell dobnia a csomagot.

A 4.4. szakasz hozzáteszi azt a részletet, amely a legtöbb csendes hibát megmagyarázza: az a NAS, amely nem tudja támogatni a kihívásokat, elutasításként kezeli az Access-Challenge-et. Ha az átjáró VPN-szolgáltatása régebbi ennél a támogatásnál, vagy kihagyja azt, a háttérrendszer második tényező iránti kérése azonnali «hitelesítés sikertelen» lesz, minden felszólítás nélkül.

Hol vész el a láncolt kérés

Az első gyanúsított a felszólítás útvonala, nem a hitelesítő adat. Az a portál, amely webes bejelentkezéshez OTP-mezőt jelenít meg, ezt nem teszi meg automatikusan a VPN-szolgáltatásnál, és egyes átjárók csak azoknak az ügyfeleknek adják tovább a kihívást, amelyek hirdetik a képességet. Tesztelje ugyanazt a fiókot mindkét belépési ponton; ha a portál működik és a VPN nem, az átadást nézi, nem a tokent.

A bemeneti formátum a második gyanúsított. A jelszó és a kód összefűzése a szállító dokumentált elválasztója nélkül, vagy a mentett hitelesítő adatok régi kód újrajátszása olyan módon hibázik, amely pontosan rossz jelszónak látszik. Használja az üzemeltető által dokumentált külön felszólítást vagy kombinált formátumot, és soha ne találjon ki elválasztót.

Léteznek kiadásspecifikus hibák, de a sok évvel ezelőtti javított verziók listája nem diagnózis a mai telepítéshez. Olvassa el annak a szoftvernek a kiadási megjegyzéseit, amelyet valóban futtat, és tartsa meg a megfigyelt eszmecsere-szakaszt bizonyítékként.

Kövessen végig egyetlen kísérletet

Reprodukálja egyszer, bekapcsolt kiszolgálóoldali hibakereséssel, és tartson minden más munkamenetet a rögzítési ablakon kívül:

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

A kimenetben a beszélgetés alakját keresse, ne egyetlen sort. Egy első Access-Request Identifier 3-mal, egy State-et hordozó Access-Challenge, majd egy második Access-Request Identifier 4-gyel, amely megismétli ezt a State-et, és tartalmazza a felhasználó válaszát. Ha a második kérés hiányzik, az átjáró soha nem követett. Ha State nélkül érkezik, a kiszolgáló nem tudja a várakozó kihívás mellé párosítani, és általában elutasítja.

A nyom megosztásakor takarja el a hitelesítő adatokat, tokeneket és a felesleges személyazonossági adatokat, és egyetlen kísérlet eseményeit korrelálja ahelyett, hogy több böngészőfül ismétlődéseit keverné. Az időbélyegek itt a barátai; az a kihívás, amely azután érkezik, hogy az ügyfél feladta, a felhasználónak elutasításnak, a naplóban lassú válasznak látszik.

A kívánt végállapot egy befejezett, jogosított beszélgetés, amelyet a szándékolt szolgáltatáshozzáférés követ. A RADIUS-kiszolgálótól érkező válasz ennél sokkal kevesebbet bizonyít.