Profily brány firewall verzus odchod cez VPN: prečo verejné nie je cesta
Profil brány firewall určuje, ktorá sada pravidiel platí. Nehovorí nič o tom, ktoré rozhranie prenieslo paket, a explicitné zablokovanie prevažuje nad užším povolením.
Pravidlo znie presne: povoľ miestnu prevádzku v súkromnom profile a v tom verejnom len prevádzku VPN. Nie je, pretože sieťový profil určuje, ktorá sada pravidiel brány firewall platí, a nehovorí nič o tom, ktorý adaptér paket preniesol. Považovať názov profilu za požiadavku na cestu je chyba, pre ktorú návrh obmedzeného odchodu vyzerá hotový, keď nie je.
Najprv zapíšte toky, potom rozhodnite, ktorý mechanizmus dokáže každý z nich skutočne presadiť. Ten zoznam tokov je jediný artefakt, ktorý prežije nasledujúcu zmenu pravidiel.
Kategória vyberá pravidlá, nie trasy
Keď Windows klasifikuje sieť ako verejnú alebo súkromnú, brána firewall použije sadu pravidiel nakonfigurovanú pre tento profil. Klasifikácia nasleduje sieť, ku ktorej sa adaptér pripojil, a sada pravidiel rozhoduje, čo je v nej povolené. Žiadny z týchto faktov nezávisí od toho, či prevádzka aplikácie použila tunel. Práve táto nezávislosť je celá obťaž.
Voľbu cesty robí smerovanie, cez metriku rozhrania a prefix, ktorý tunel nainštaluje. Profil preto môže byť označený ako verejný, zatiaľ čo pripojenie aplikácie ide fyzickou cestou, a brána firewall napriek tomu ohlási, že bola použitá verejná sada pravidiel.
Preto pravidlo obmedzené na profil nemôže znamenať len tunel. Obe vlastnosti rozhodujú rôzne komponenty a jedna nemôže zastúpiť druhú.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
Explicitné zablokovanie prevažuje nad užším povolením
Usmernenia Microsoftu k pravidlám brány firewall rozlišujú povolenie ako výnimku z predvolenej akcie blokovania od explicitného zablokovania, ktoré je v rozpore s povolením. Explicitné zablokovania túto zrážku vyhrávajú a odchádzajúce pravidlá sa riadia rovnakou prioritou.
Preto populárny recept pridať pravidlo blokujúce všetko a spoľahnúť sa na užšie povolenie umiestnené nad ním nerobí to, čo jeho autor očakáva. Windows Firewall nerieši zrážku podľa poradia pravidiel prideleného správcom. Zablokovanie jednoducho platí a pripájajúca sa aplikácia ohlási vypršanie časového limitu. Pravidlo, ktoré vyzeralo ako výnimka, nikdy nebolo v hre.
Podporovaný tvar je zásada predvoleného odmietnutia so schválenými povoľovacími pravidlami, kde každé povolenie pomenúva program, službu alebo cieľ dostatočne presne na to, aby sa dalo preskúmať. Taký návrh prejde auditom, pretože každá výnimka je viditeľná a žiadna nezávisí od poradia vytvorenia.
Dve pravidlá, ktoré si odporujú, sú horšie ako jedno pravidlo, pretože výsledné správanie je zároveň správne a nevysvetliteľné.
Dajte odchádzajúcej zásade jediného vlastníka
Podporovaný klient VPN už udržiava vlastné správanie blokovania a vlastné výnimky pre koncové body. Pridanie nekoordinovaných ručných pravidiel môže tohto klienta uväzniť mimo tunela, ktorý potrebuje na nastavenie, alebo nechať otvorenú druhú cestu, ktorej si nikto nevšimol.
Rozhodnite, komu odchádzajúca zásada patrí, skôr než začnete písať pravidlá: vlastnej konfigurácii klienta, spravovanej zásade brány firewall alebo dokumentovanému miestnemu zoznamu výnimiek s vlastníkom. Potom zlaďte vrstvy, namiesto toho, aby ste vrstvili experimenty, kým sa niečo nepripojí. Menovaný vlastník je aj ten, koho sa pýtate, keď sa dve vrstvy nezhodujú.
Zachovajte záchranný kanál, skôr než čokoľvek zmeníte. Vzdialený stroj uzamknutý mimo vlastnej cesty správy je horší výsledok než medzera v zásade, ktorú ste zatvárali. Pravidlo obnovy sa ľahšie obhajuje, keď je vopred zapísané, a ľahšie sa nájde, keď sa zmena pokazí v hodinu, ktorú nikto nemá rád.
Otestujte štyri výsledky namiesto čítania štítku
Zásada je len taká dobrá, ako dobre rozlišuje prípady, preto štítok profilu berte ako východiskový bod, nie ako výsledok. Štyri výsledky povedia, či funguje: zamýšľaná požiadavka do LAN uspeje, pokrytá internetová požiadavka uspeje, zakázaná priama požiadavka zlyhá a prípad zlyhania tunela sa správa podľa návrhu, namiesto toho, aby ticho ustúpil. Zapíšte štyri výsledky vedľa zmeny pravidiel. Testovací plán so štyrmi pomenovanými prípadmi je dosť krátky na to, aby sa spúšťal zakaždým, a dosť konkrétny na to, aby hlasno zlyhal.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
Prvý príkaz ukazuje, ako je klasifikovaná každá pripojená sieť, čo často nie je to, čo predpokladal človek, ktorý pravidlo písal. Druhý ukazuje predvolenú akciu pre každý profil a tretí vypisuje povolené odchádzajúce blokovania, vrátane tých, ktoré ticho prepíšu užšie povolenie.
Spustite štyri prípady znova po zmene siete, pretože profil môže byť preklasifikovaný, keď sa stroj pripojí k inej sieti. Zhodný štítok profilu nie je dôkaz, že cesta bola tá, ktorú ste zamýšľali.