Skupinová politika NPS nie je vynútenie prostriedkov VPN

Dve skupiny, dva prístupové profily, jedna brána VPN a napokon obe skupiny dosiahnu rovnaké servery. Zvyčajná príčina nie je pokazená politika, ale chýbajúca druhá polovica návrhu: NPS rozhoduje, kto smie nadviazať reláciu, a niečo iné musí rozhodnúť, kam táto relácia smie dosiahnuť. Keď existuje len prvá polovica, autorizácia uspeje u každého, kto sa overí. Politika robí svoju prácu a návrh je stále neúplný.

Sieťová politika zodpovedajúca skupine je dôkazom o prijatí. Nie je dôkazom o paketoch a medzera medzi týmito dvoma tvrdeniami je miesto, kde sa odohráva väčšina tejto práce.

Nájdite politiku, ktorá reláciu skutočne prijala

NPS vyhodnocuje zoradené sieťové politiky a vyhráva prvé povolené pravidlo, ktorého podmienky zodpovedajú. Podmienky môžu zahŕňať členstvo v skupine používateľa alebo počítača, typ pripojenia, čas a stav zariadenia. Preto široká politika umiestnená skôr v zozname prijme pripojenie skôr, než sa užšie pravidlo nižšie vôbec zváži. Poradie nie je detailom rozhrania; poradie je politika.

Prečítajte zoznam v poradí a určte, ktoré zodpovedalo, potom si poznačte, aké nastavenia vrátilo. Názov skupiny v editore nie je výsledok; výsledkom je autorizácia, ktorú server dostal. Udržujte autorizáciu používateľa a autorizáciu zariadenia oddelene tam, kde nasadenie používa obe, pretože účet, ktorý smie otvoriť tunel, nie je automaticky účet, ktorý by mal dosiahnuť každú internú službu.

Odpoveď RADIUS je inštrukcia, nie filter

Atribút Filter-Id nesie názov zoznamu filtrov. Neprenáša prenosnú sadu pravidiel filtrovania paketov, ktorej by rozumel každý príjemca, a odoslanie názvu, ktorý brána nikdy nedefinovala, nevynucuje vôbec nič. Rovnaká opatrnosť platí pre atribúty VLAN: priradenie tunelovej relácie do VLAN samo o sebe nie je smerovaným pravidlom prístupu pre tohto používateľa.

Tu návrh, ktorý na strane NPS vyzerá úplne, potichu nerobí nič. Overte v dokumentácii dodávateľa brány, ktoré autorizačné atribúty sú podporované a čo príjemca robí s každým z nich, namiesto toho, aby ste predpokladali, že štandardný názov atribútu znamená štandardné správanie.

Umiestnite vynútenie tam, kadiaľ prechádza prevádzka

Brána, ktorá spracúva pakety používateľa, môže použiť filter pre každú reláciu, namapovať skupinu na politiku brány alebo dať relácii adresu zo segregovaného fondu, s ktorým firewall zaobchádza inak. Ktorákoľvek z týchto možností môže fungovať a každá zlyháva inak. Určte, ktorý mechanizmus vaša brána podporuje, skôr než napíšete politiku, ktorá ho pomenúva. Potom zapíšte, čo sa stane s reláciou, keď tento mechanizmus chýba, pretože ticho je predvolený stav.

Opíšte zamýšľané povolenie v štyroch častiach: identita zdroja alebo skupina, cieľ, protokol a port. Pridajte závislosti, ktoré používateľ naozaj potrebuje, napríklad DNS alebo autentifikačnú službu, inak obmedzenie rozbije prihlasovacie toky, ktoré nikoho nenapadlo testovať. Píšte pravidlo voči rozhraniu, ktoré skutočne filtruje, nie voči rozhraniu, ktoré je náhodou otvorené v editore.

Vezmite do úvahy aj preklad adries. Ak firewall nižšie vidí jednu preloženú zdrojovú adresu pre každého používateľa tunela, nemôže z tej adresy samej rozlíšiť jednotlivcov, a pravidlo napísané, akoby mohol, bude buď zbytočné, alebo príliš široké.

Klientske profily žijú na nedôveryhodnej strane

Spravovaný profil VPN môže pretlačiť trasy, pravidlá rozdeleného tunela alebo filtre aplikácií a tie formujú správanie dobre vychovaného zariadenia. Nie sú ochranou služby, pretože klient je strana, ktorú sa snažíte obmedziť. Odstránenie trasy v profile tiež nie je autorizácia, keďže klient môže mať inú cestu k rovnakému cieľu.

Berte klientske nastavenia ako pohodlie a nastavenia brány ako kontrolu. Keď sa obe rozchádzajú, brána má pravdu, pretože je to ona, kto vidí pakety.

Prijmite s dvoma účtami, potom sledujte v poradí

Vytvorte dva bežné testovacie účty s odlišnými zamýšľanými povoleniami, nadviažte nové relácie a skontrolujte účinnú politiku brány pre každý z nich. Potom otestujte jednu neškodnú povolenú operáciu a jeden konkrétne zakázaný prostriedok. Neúspešný ping sám o sebe dokazuje veľmi málo, pretože ICMP môže byť filtrovaný, zatiaľ čo služba TCP za ním pokojne odpovedá.

Keď oba účty stále získavajú široký prístup, sledujte v pevnom poradí: ktorá politika zodpovedala, akú autorizáciu niesla odpoveď a čo s ňou brána urobila. Pridávanie ďalších atribútov NPS pred overením, že ich príjemca implementuje, je spôsob, akým sa malý problém s autorizáciou zmení na okno zmien bez výsledku.