Palo Alto GlobalProtect 2FA RADIUS-szal, külön RADIUS-szerver nélkül

A Palo Alto Networks tűzfalai a GlobalProtect VPN-bejelentkezéseket RADIUS-szerverhez tudják továbbítani. A Notakey auth-proxynak ennyi elég: a RADIUS-útvonalba épül be, és csak akkor engedi át a bejelentkezést, ha a felhasználó a telefonján jóváhagyta.

A szokásos ellenvetés maga a RADIUS-szerver. Sok csapat nem üzemeltet ilyet, és pusztán egy második faktor kedvéért FreeRADIUS-t vagy Microsoft NPS-t felépíteni önálló projekt. Ez az útmutató ehelyett a helyben telepíthető Notakey készülékkel szállított RADIUS-bővítményt használja, így a teljes háttérrendszer maga a készülék: proxy, RADIUS és telefonos jóváhagyás egy helyen.

Palo Alto tűzfalat mi magunk laborkörnyezetben nem teszteltünk. Az alábbi Palo Alto-beállítások a gyártó dokumentációjából származnak, hivatkozásokkal. A tűzfal szabványos RADIUS-on kommunikál az auth-proxyval, ugyanúgy, mint a többi útmutatónkban szereplő VPN-koncentrátorok.

Hogyan illeszkednek össze az elemek

GlobalProtect app ──▶ Palo Alto portal/gateway ──RADIUS──▶ Notakey auth-proxy ──RADIUS──▶ RADIUS plugin
                                                                  │
                                                                  └──▶ approval request ──▶ user's phone

A felhasználó a GlobalProtecttel csatlakozik, és megadja a felhasználónevét és jelszavát.
A tűzfal RADIUS-kérést küld a készüléken futó auth-proxynak.
A proxy a jelszóellenőrzést a RADIUS-bővítménynek adja át. Hibás jelszó esetén a belépést azonnal elutasítja.
Ha a bővítmény elfogadja a jelszót, a proxy jóváhagyási kérést küld a felhasználó telefonjára, és nyitva tartja a RADIUS-tranzakciót, amíg a felhasználó dönt, alapértelmezés szerint 30 másodpercig.
Jóváhagyás esetén a tűzfal Access-Accept választ kap. Elutasítás esetén vagy válasz hiányában a proxy elutasítja a belépést.

Mit változtat a bővítmény a jelszón

Mielőtt a bővítmény mellett dönt, mérlegeljen egy kompromisszumot. A bővítmény nem ellenőrzi a felhasználó címtárbeli jelszavát. Vagy egyetlen, mindenki által közösen használt globális jelszót fogad el, vagy a bővítmény konfigurációjában tárolt, felhasználónkénti jelszavak rövid listáját (RADIUS-szolgáltatásbővítmény).

A gyakorlatban ez azt jelenti, hogy a bejelentkezést a telefonos jóváhagyás védi: a kérés az adott felhasználónévhez regisztrált telefonra érkezik, és aki a kezében tartja, látja, mit hagy jóvá. Globális jelszó esetén a jelszavas lépés közös kapu, nem pedig egy második, felhasználónként egyedi titok.

Ha a belső szabályzat vagy az auditor elvárja, hogy a két faktor egyike a címtárbeli jelszó legyen, a bővítmény helyett irányítsa az auth-proxyt egy olyan RADIUS-szerverre, amely az Active Directoryt ellenőrzi, például a Microsoft NPS-re. Az útmutató Palo Alto-oldali része változatlan marad; csak a proxy mögöttes címe és titka változik, ahogy azt a VPN 2FA RADIUS-szal útmutatónk leírja.

1. lépés: Hozza létre a VPN-alkalmazást a Notakeyben

A Notakey irányítópulton hozzon létre egy alkalmazást (szolgáltatást) a VPN számára, regisztrálja a felhasználók telefonjait, és másolja ki az alkalmazás Access ID-ját.

A felhasználónévnek, amelyet a felhasználó a GlobalProtectbe beír, pontosan abban a formában kell a proxyhoz érkeznie, ahogy a Notakeyben regisztrálták. Ezt tartsa szem előtt a 4. lépésnél, ahol a Palo Alto hozzáadhat vagy levághat egy tartománynevet.

2. lépés: Indítsa el a RADIUS-bővítményt a készüléken

A készülék parancssorában állítsa be a bővítmény lemezképét (image), cserélje le az alapértelmezett titkot és jelszót, majd indítsa el. Ne hagyja meg az alapértékeket: ezek a dokumentációnkban nyilvánosan olvashatók.

ntk cfg setc :plugins.radius.image "notakey/radius-all:latest"
ntk cfg setc :plugins.radius.env.SECRET "<long-random-secret>"
ntk cfg setc :plugins.radius.env.PASSWORD "<global-password>"
ntk plugins update
ntk plugins start

A PASSWORD az a globális jelszó, amelyet a felhasználók a GlobalProtectbe írnak. Ha egyes felhasználóknak inkább saját jelszót szeretne adni, vegye fel a USER1/PASSW1, USER2/PASSW2 stb. párokat; a beállítások teljes listája a bővítményről szóló cikkben található.

3. lépés: Irányítsa az auth-proxyt a bővítményre

A proxy a bővítményt a konténer neve, a radius alapján találja meg. A bővítményről szóló cikk szerint mindkét oldalon ugyanazt a titkot használja; a tűzfal is ezt fogja használni.

ntk cfg set :ap.vpn_port_in "1812"
ntk cfg set :ap.vpn_radius_address "radius"
ntk cfg set :ap.vpn_secret_in "<long-random-secret>"
ntk cfg set :ap.vpn_secret_out "<long-random-secret>"
ntk cfg set :ap.vpn_access_id "<access-id-from-step-1>"
ntk cfg set :ap.vpn_message_ttl "30"
ntk cfg set :ap.message_title "VPN login"
ntk cfg set :ap.message_description "Allow {0} to connect to the VPN?"
ntk ap start

A vpn_message_ttl azt adja meg, mennyi ideje van a felhasználónak a jóváhagyásra. A leírásban a {0} helyére a felhasználónév kerül. A proxy az 1812-es UDP-porton fogadja a RADIUS-kéréseket; a tűzfalnak ezen a porton el kell érnie a készüléket.

Egy eltérés a többi VPN-hez képest: GlobalProtect esetén ne számítson arra, hogy a jóváhagyási kártyán megjelenik a felhasználó IP-címe. Az auth-proxy a kliens címét az erre szolgáló szabványos RADIUS-attribútumból, a Calling-Station-Id mezőből olvassa ki. A GlobalProtect azonban nem ide írja a kliens IP-címét, hanem csak a Palo Alto saját, gyártóspecifikus attribútumában küldi el (a SecureAuth megjegyzése erről a viselkedésről). Úgy fogalmazza meg a leírást, hogy a kártya így is egyértelművé tegye, mit hagy jóvá a felhasználó: a szolgáltatást és a felhasználónevet.

4. lépés: Konfigurálja a Palo Alto tűzfalat

A Palo Alto Set Up RADIUS or TACACS+ Authentication útmutatója az általános lépéseket ismerteti. Az alábbiak azok a beállítások, amelyeken a telefonos jóváhagyás múlik.

RADIUS-szerverprofil (Device → Server Profiles → RADIUS) (a mezők leírása):

Server: a készülék címe, az 1812-es port és a 3. lépésben megadott titok.
Timeout (időkorlát): az alapérték 3 másodperc, ami egy jelszóellenőrzéshez elég, ahhoz viszont távolról sem, hogy valaki megkeresse a telefonját. A megengedett tartomány 1–120 másodperc, és a Palo Alto saját megjegyzése szerint többfaktoros beállításoknál elegendő időt kell hagyni a felhasználóknak a válaszra. Állítsa bőven a proxy 30 másodperces ablaka fölé, például 60-ra.
Retries (újrapróbálkozások): az alapérték 3. Hosszú időkorlát mellett elég az 1. Ha a tűzfal mégis újraküldi a kérést, az auth-proxy felismeri és figyelmen kívül hagyja, így a felhasználó nem kap második jóváhagyási kérést.
Authentication Protocol: válassza a PAP-ot. Az alapértelmezett PEAP-MSCHAPv2 titkosított alagútba csomagolja a bejelentkezést, és alapértelmezés szerint a külső kérésben elrejti a felhasználó azonosítóját. A proxynak viszont ki kell olvasnia a felhasználónevet, hogy tudja, kinek a telefonjára küldje a kérést. A PAP az a lehetőség, amelyet a Palo Alto a sem EAP-t, sem CHAP-ot nem használó RADIUS-szerverekhez jelöl meg. PAP esetén a RADIUS a felhasználónevet nyílt szövegként küldi, és csak a jelszót rejti el a megosztott titok segítségével (RFC 2865). A tűzfal és a készülék közötti kapcsolat legyen megbízható hálózaton, a titok pedig hosszú és véletlenszerű.

Hitelesítési profil (Device → Authentication Profile):

Type: RADIUS, a fenti szerverprofillal.
Username Modifier: a %USERINPUT% változatlanul adja tovább a felhasználónevet. Ha User Domaint is megad, a Palo Alto azt a név elé vagy mögé illeszti, illetve levágja a felhasználó által beírt tartományt. Bármi legyen is az eredmény, egyeznie kell a Notakeyben regisztrált felhasználónévvel.
Allow List (Advanced lap): a lista alapértelmezés szerint üres, ami mindenkit kizár. Vegye fel azokat a felhasználókat vagy csoportokat, akiknek csatlakozniuk kell, vagy adja meg az all értéket.

Portál és átjáró: vegye fel a hitelesítési profilt a GlobalProtect portál és átjáró klienshitelesítési beállításai közé, majd véglegesítse (commit) a módosításokat.

5. lépés: Kerülje el a kapcsolatonkénti két jóváhagyást

Egy GlobalProtect-kapcsolat kétszer hitelesít: egyszer a portálon, egyszer az átjárón. Ha mindkettő RADIUS-t használ, a felhasználó egyetlen kapcsolathoz két jóváhagyási kérést kap, és éppen ez az a fajta zaj, amely arra szoktatja az embereket, hogy olvasás nélkül hagyjanak jóvá.

Erre a Palo Alto authentication override sütijei (a hitelesítést kiváltó sütik) adnak megoldást (a portál hitelesítési beállításai). Az első sikeres bejelentkezés után a portál titkosított sütit állít ki, az átjáró pedig ezt fogadja el ahelyett, hogy újra rákérdezne:

A portálon kapcsolja be a Generate cookie for authentication override beállítást.
Az átjárón kapcsolja be az Accept cookie for authentication override beállítást.
A süti titkosításához és visszafejtéséhez a portálon és az átjárón ugyanazt a tanúsítványt használja.
A süti élettartamát tudatosan válassza meg. Amíg a süti érvényes, a felhasználótól a rendszer nem kér újabb jóváhagyást, így a hosszú élettartam kevesebb jóváhagyást, de egyben kisebb védelmet is jelent, ha a laptopot ellopják.

Próbálja ki

Csatlakozzon a GlobalProtecttel. A jelszó után a jóváhagyási kérés a 3. lépésben beállított címmel és leírással érkezik meg a telefonra. Hagyja jóvá, és felépül az alagút. Ezután próbálja meg újra, és utasítsa el: a kapcsolatnak ekkor meg kell hiúsulnia.

Ha a bejelentkezések gyors jóváhagyás mellett is meghiúsulnak, először az időkorlátokat ellenőrizze:

a tűzfal RADIUS-szerverprofiljának időkorlátját, amelynek hosszabbnak kell lennie a proxy 30 másodpercénél;
a GlobalProtect saját kapcsolódási időkorlátját. A Palo Alto közösségi fórumán adminisztrátorok arról számolnak be, hogy többfaktoros bejelentkezésekhez megemelték (fórumszál). Ha a gyors jóváhagyások működnek, de az időablak vége felé adottak nem, ez a valószínű ok; emelje meg ezt az időkorlátot, vagy rövidítse a vpn_message_ttl értékét.

Amit ez nem fed le

A továbbított adathalász bejelentkezéseket. A telefonos jóváhagyás megakadályozza, hogy egy ellopott vagy kitalált jelszó önmagában elég legyen. Azt a támadót viszont nem állítja meg, aki egy hamis oldalon keresztül valós időben közvetít egy valódi bejelentkezést; erre csak a webhelyhez kötött módszerek, például a FIDO-kulcsok képesek. A különbséget az MFA-kifáradásról és a közvetítéses támadásokról szóló bejegyzésünkben fejtjük ki.
Magának a tűzfalnak a kitettségét. Hogy miért jelent problémát a csak jelszóval védett VPN- vagy adminisztrációs bejelentkezés, és mit érdemes előbb rendbe tenni, azt a FortiBleedről szóló bejegyzésünk tárgyalja. A tanulságok bármely gyártó tűzfalára érvényesek.

Próbálja ki az élő demót, és körülbelül két perc alatt jóváhagyhat egy bejelentkezést a saját telefonjáról, vagy kérjen bemutatót, és segítünk megtervezni egy GlobalProtect pilot projektet.