Windows VPN megerősítése: előbb a hitelesítést javítsa, aztán a tunnelt

A Windows VPN-kiszolgálója felhasználónevet és jelszót kér, és ez az egyetlen párbeszédablak három, egymástól független feladatot rejt. Az egyik bizonyítja, ki az illető, a másik megakadályozza, hogy a vonalat figyelő valaki újra felhasználja ezt a bizonyítékot, a harmadik pedig eldönti, mely címeket érheti el utána. A legtöbb kis telepítés először a tunnelt erősíti meg, és az első két feladatot az alapértelmezett értéken hagyja, ami rossz sorrend.

A támadó sorrendjében dolgozzon. Először az, ami a vonalról elfogható. Aztán az, ami ezzel a felvétellel később újrajátszható. Végül az, ahová egy hitelesített támadó bejutva elérhet.

Három feladat, egy párbeszédablak

Az identitás az a rész, amelyre az emberek gondolnak, és csak a probléma egyharmada. Az identitás bizonyítékának túl kell élnie egy megfigyelőt, aki rögzíti az eszmecserét és később újra próbálkozik. Az engedélyezés külön döntés, amelyet a kiszolgáló az identitás tisztázása után hoz, és a Windows más szolgáltatásban tartja, mint amelyik a hitelesítő adatokat ellenőrzi.

Amikor mindhárom egyetlen gondolati vödörben él, a szokásos eredmény egy kiszolgáló, amely erősen hitelesít, majd mindent megenged a felhasználónak. Ezt később kijavítani nehezebb, mint most eldönteni a szabályzatot, mert akkorra a tűzfalprofil, a címpool és az útvonalak mind a régi feltevést kódolják.

Válassza szét a hármat a jegyzeteiben, mielőtt bármely beállításhoz nyúlna, aztán a leggyengébb láncszemtől felfelé javítsa őket.

Miért nem állja ki az MS-CHAPv2 az újrajátszásos próbát

Ha a kiszolgáló még elfogadja a PPTP-t MS-CHAPv2-vel, a tunnel semmilyen érdemi értelemben nem védi a jelszót. A kihívás és a válasz elfogható és offline támadható, és 2012-ben egy nyilvános törőszolgáltatás egy ilyen kézfogásból körülbelül egy nap alatt mutatta be a visszafejtést egy tipikus jelszó esetén. A hosszabb és összetettebb jelszó növeli a költséget; nem távolítja el azt az anyagot, amire a támadónak a hálózatból szüksége van.

A kívánt tulajdonság egy olyan hitelesítő adat, amely nem játszható újra. Az EAP-TLS ügyféltanúsítványokkal minden eszköznek saját identitást ad, és lehetővé teszi pontosan egy eszköz visszavonását.

A tanúsítványok bevezetése valódi munka: saját hitelesítésszolgáltató, az ügyfelek által ellenőrzött visszavonási útvonal és a személyzetváltást is túlélő megújítási terv. Kezelje ezt a munkát projektként, ne akadályként ön és egy működő tunnel között. Költségvetést tervezzen rá úgy, ahogy egy tűzfalcserére tervezne. A megosztott jelszó csak az első visszavonásig olcsóbb.

Az előre megosztott kulcs a párt hitelesíti, nem a személyt

L2TP/IPsec előre megosztott kulccsal bizonyítja, hogy két átjáró ugyanazt a titkot ismeri. Semmit nem mond arról, melyik ember kapcsolódik, és ezen a rétegen nem tudja megkülönböztetni az egyik munkatársat a másiktól. Használjon hosszú véletlen értéket, jóval túl azon a tíz karakteren, amelyet egyes útmutatók javasolnak, mert aki elkapja a kézfogást, offline támadhatja a kulcsot.

A profil minden ügyfele osztozik a titkon, így egy személy eltávolítása azt jelenti, hogy újra ki kell osztani mindenkinek, aki marad. Tartson külön felhasználóhitelesítési lépést a gép szintű titok fölött, és térjen át a tanúsítványokra, ahogy az ügyfélállomány nő. Az előre megosztott kulcs az MS-CHAPv2-vel két gyenge réteg, és a második hatástalanítja az elsőt.

Az engedélyezés helye a Network Policy Server

A Windows NPS-e dönti el, ki kapcsolódhat, és ezt azután teszi, hogy a hitelesítés már sikeres volt. Ez a szétválasztás a termék leghasznosabb megerősítési kontrollja, és sok telepítés érintetlenül hagyja.

Használjon olyan házirend-feltételeket, amelyek valós korlátokat tükröznek: csoporttagság, az az időablak, amikor a támogatás személyzettel működik, és az eszköz állapota egy állapotellenőrzésből. Adjon hozzá második tényezőt ott, ahol az adatok indokolják a súrlódást, és ne feledje, hogy a házirendet minden kapcsolódási kísérletnél értékelik, ami élő kontrollá teszi, nem dokumentummá.

A RADIUS-elszámolás egyetlen rekordot is ad arról, ki és mikor kapcsolódott. Ez a napló a különbség egy incidens áttekintése és egy találgatás között, és létezik attól függetlenül, hogy valaki valaha olvassa-e.

Korlátozza, hová juthat el egy sikeres bejelentkezés

A VPN-adapternek olyan tűzfalprofilba kell kerülnie, amely a szerepéhez szükséges szolgáltatásokat engedi, nem a teljes alhálózatot. Az útválasztás kérdése különáll a szűréstől. A teljes tunnel védi az ügyféleszközt és minden bájtot a felső kapcsolatán keresztül továbbít, míg a megosztott tunnel a helyi forgalmat helyben tartja, és kiteszi az eszközt annak a hálózatnak, amelyen éppen van.

Egyik választás sem biztonsági alapértelmezés. Mindkettőt le kell írni az általuk feltételezett tűzfalprofil mellé.

Ellenőrizze a hibaútvonalakat

Tesztelje, minek kell eltörnie: rossz jelszó, lejárt tanúsítvány, visszavont eszköz, csoporton kívüli felhasználó. Mindegyiknek más ponton kell meghiúsulnia, és a naplónak meg kell mondania, melyik volt. Futtassa a készletet először tesztfiókon, majd ismételje meg valódi felhasználóval. Az ok nélkül az eseménynaplóba kerülő elutasítást érdemes jóval azelőtt kijavítani, hogy szüksége lenne arra a rekordra.

Ezután erősítse meg, mely portok vannak közzétéve és miért. A PPTP-nek TCP 1723 és GRE kell IP-protokollként, nem portként, az IKEv2-nek UDP 500 és 4500, az L2TP-nek pedig UDP 1701 plusz IPsec. A felügyeleti felület megnyitása, hogy egy ügyfél kapcsolódhasson, nem javítás, hanem egy második incidens, amely a felfedezésre vár.

Végül döntse el, mit rögzít a kiszolgáló és mennyi ideig. Egy végpont hitelesítési előzmények nélkül nem tud válaszolni az incidens utáni első kérdésre, arra, hogy a kísérlet valaha engedélyezett volt-e.