RDP-ի թույլտվության կանոն ավելացնելը չի նեղացնում ձեր VPN մուտքը

Ծրագիրը խելամիտ է հնչում՝ թողնել գոյություն ունեցող Հեռավոր աշխատասեղանի թույլտվությունը և ավելացնել փոքր թույլտվություն այն միակ VPN հաճախորդի համար, որը պետք է մուտք ունենա։ Windows Firewall-ը այդպես չի աշխատում։ Կանոնները դասավորված ցուցակ չեն, որտեղ հաղթում է ամենակոնկրետ գրառումը, և նեղ թույլտվությունը լայնի կողքին ոչինչ չի փոխում, քանի որ լայնը դեռևս թույլ է տալիս բոլորին, ում արդեն թույլ էր տվել։ Ծառայությունը նեղացնելը նշանակում է խմբագրել այն թույլտվությունը, որն արդեն կատարում է աշխատանքը։

Այն կանոնը, որը դուք ավելացնում եք, այն կանոնը չէ, որ կարևոր է

Windows Firewall-ը գնահատում է մեքենային վերաբերող քաղաքականության պահոցներում եղած բոլոր կիրառելի մուտքային կանոնները, ապա որոշում՝ արդյոք որևէ թույլտվություն համընկնում է և արդյոք որևէ արգելափակում այն վերացնում է։ Կանոն ավելացնելը ավելացնում է թույլտվություն՝ այն չի հեռացնում կամ չի ճշգրտում արդեն գոյություն ունեցող թույլտվությունները։

Ուստի հարցը երբեք այն չէ, թե ինչ եք ավելացրել։ Հարցն այն է, թե ինչ է պարունակում գործող քաղաքականությունը տեղական քաղաքականության, դոմենի քաղաքականության և պրոֆիլի լռելյայն արժեքների միավորումից հետո։ Մեկ տեղական կանոնով աշխատանքային կայանը հեշտ է մտովի վերլուծել, իսկ դոմենին միացած սերվերը՝ ոչ։

Այդ պատճառով էլ ադմինիստրատորը կարող է ճիշտ թվացող փոփոխություն կատարել, փորձարկել այն սխալ մեքենայից և եզրակացնել, որ այն աշխատել է։ Բացառված աղբյուրը երբեք չի փորձարկվել։ Փորձարկումը, որն ապացուցում է միայն հաջողությունը, ապացուցում է փոփոխության նպատակի կեսից պակասը։

Պարզեք, թե որ հասցեն է տեսնում սերվերը

Նախքան ինչ-որ բան սահմանափակելը՝ դիտեք մեկ թույլատրված սեսիա Windows հոսթում և գրանցեք այն աղբյուրի հասցեն, որը հաղորդում է սերվերը։ Սա միշտ չէ, որ այն հասցեն է, որը հաճախորդը կարծում է, թե ունի։

Եթե VPN դարպասը պահպանում է հաճախորդների հասցեները, սերվերը տեսնում է հաճախորդի թունելի հասցեն, և հասցեով սահմանափակված կանոնը իմաստ ունի։ Եթե դարպասը թարգմանում է, ամեն հաճախորդ գալիս է որպես դարպասի հասցե, և այդ հասցեով սահմանափակելը մուտք է տալիս դրա հետևում գտնվող բոլոր հաճախորդներին։ Այդ դեպքում կանոնը ճշգրիտ է սխալ բանի առումով։

Այս երկու ձևավորումները տարբեր պատասխաններ են պահանջում։ Առաջինը կարող է արտահայտվել firewall-ի կանոնում՝ երկրորդը պետք է պարտադրվի այնտեղ, որտեղ ինքնությունը դեռ գոյություն ունի, այսինքն՝ հենց VPN-ում կամ ծառայության առջև գտնվող նույնականացված դարպասում։

Firewall-ի զտիչը չի կարող վերականգնել այն ինքնությունը, որը ցանցային թարգմանությունը դեն է նետել, որքան էլ հասցեն ուշադիր մուտքագրված լինի։

Փոխեք գործող կանոնի սեփականատիրոջը

Ստուգեք գործող մուտքային քաղաքականությունը և գտեք յուրաքանչյուր կանոն, որն այժմ թույլ է տալիս RDP երթևեկություն, ներառյալ այն կանոնները, որոնց ցուցադրվող անվանումը երբեք չի հիշատակում 3389 պորտը։ Հաշվի են առնվում նաև ծառայությամբ և հավելվածով սահմանափակված կանոնները, ինչպես նաև UDP տրանսպորտը, որը մի քանի RDP տեղակայումներ միացնում են։

Այնուհետև խմբագրեք գոյություն ունեցող կանոնները այն պահոցի միջոցով, որը տիրապետում է դրանց։ Կանոնի տեղական խմբագրումը, որը սահմանում է նաև դոմենի քաղաքականությունը, կարող է միավորվել, անտեսվել կամ վերագրվել, և արժե իմանալ, թե դրանցից որն է տեղի ունենում՝ նախքան դրա վրա հույս դնելը։

Այս հրամանները գտնում են ակտիվ կանոնները, ցույց են տալիս դրանցից մեկին կապված հասցեի զտիչը և նախադիտում են շրջանակի փոփոխությունը՝

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

Կանոնների անուններն այստեղ տեղապահներ են այն բանի համար, ինչ գտել է վերանայումը, և նախադիտման դրոշը գոյություն ունի, որպեսզի հասցեի մեջ տառասխալը ձեզ չկողպի այն սերվերից, որը խմբագրում եք։

Սկզբում արգելափակել, ապա թույլատրել՝ այլ մոդել է

Այլ firewall-ների սովորույթն է գրել լայն արգելափակում, ապա դրա վրա նեղ թույլտվություն։ Windows-ում բացահայտ արգելափակումը սովորաբար հաղթում է թույլտվությանը, ուստի այդ հերթականությունը ստեղծում է ծառայություն, որին ոչ ոք չի կարող հասնել՝ մեկ հաճախորդի համար բացառության փոխարեն։ Արդյունքը ընդհատում է, որը նման է կոտրված RDP ծառայության։ Իրականում դա առաջնահերթության սխալ է, և ուղղումը արգելափակումը հեռացնելն է, այլ ոչ թե ևս մեկ թույլտվություն ավելացնելը։

Պահեք մուտքային արգելափակման լռելյայն վարքը ակտիվ պրոֆիլներում և փոխարենը նեղացրեք կոնկրետ թույլտվությունները։ Սա մեքենան թողնում է մեկ հասկանալի դիրքում՝ երկու հակասական կանոնների փոխարեն, որոնց փոխազդեցությունը կախված է առաջնահերթության մանրամասներից։

Ապացուցեք երկրորդ աղբյուրով

Փորձարկեք թույլատրված հաճախորդից և այն աղբյուրից, որը հիմա պետք է ձախողվի։ Մեկ հաջող միացումը ապացուցում է միայն, որ թույլատրված ուղին աշխատում է՝ այն ոչինչ չի ասում հենց նոր արված բացառության մասին։

Կրկնեք փորձարկումը IPv6-ով, եթե սերվերում այն միացված է, քանի որ միայն IPv4-ի համար նախատեսված մտադրությունը կարող է գոյակցել լայն IPv6 թույլտվության հետ, որին ոչ ոք չի նայել։

Վերջապես, նույնականացումը առանձին պահեք հասանելիությունից։ Ցանցի մակարդակի նույնականացումը, հաշվի իրավունքները և մուտքի սահմանափակումները դեռևս որոշում են, թե ով կարող է օգտվել սեսիայից, և firewall-ը որոշում է միայն, թե ով կարող է հարցնել։ Սարքը հետագայում հեռացնելը պետք է հեռացնի և՛ դրա VPN գրանցումը, և՛ այս ցանցային թույլտվությունը, այլապես ձեր սահմանափակած հասցեն մի օր կպատկանի ուրիշի։