Додавање правила дозволе за RDP не сужава ваш VPN приступ

Друго, уско правило дозволе стоји поред широког уместо да га замени. Ограничите постојећа правила, а затим докажите адресу коју сервер заиста види.

План звучи разумно: оставите постојећу дозволу за Удаљени радни сто као што јесте и додајте малу за јединог VPN клијента који би требало да има приступ. Windows Firewall не ради тако. Правила нису уређена листа у којој побеђује најконкретнији унос, а уско правило поред широког не мења ништа, јер широко и даље пушта све које је већ пуштало. Сужавање услуге значи уређивање дозволе која већ обавља посао.

Правило које додате није правило које је важно

Windows Firewall процењује сва применљива долазна правила у складиштима смерница која се односе на машину, затим одлучује да ли се нека дозвола подудара и да ли је нека блокада надјачава. Додавање правила додаје дозволу; не уклања нити прецизира дозволе које већ постоје.

Зато питање никада није шта сте додали. Питање је шта садржи ефективна смерница након спајања локалне смернице, смернице домена и подразумеваних вредности профила. Радну станицу са једним локалним правилом је лако промислити; сервер придружен домену није.

Зато администратор може да направи измену која изгледа исправно, тестира је са погрешне машине и закључи да је успела. Искључени извор никада није тестиран. Тест који доказује само успех доказује мање од половине онога због чега је измена направљена.

Сазнајте коју адресу сервер види

Пре него што било шта ограничите, посматрајте једну дозвољену сесију на Windows хосту и запишите изворну адресу коју сервер пријављује. То није увек адреса за коју клијент мисли да је има.

Ако VPN гејтвеј чува адресе клијената, сервер види тунелску адресу клијента и правило ограничено адресом има смисла. Ако гејтвеј преводи адресе, сваки клијент долази као адреса гејтвеја, а ограничавање на ту адресу даје приступ сваком клијенту иза ње. Тада је правило прецизно у погледу погрешне ствари.

Та два дизајна траже различите одговоре. Први се може изразити у правилу заштитног зида; други мора да се спроведе тамо где идентитет још постоји, то јест у самом VPN-у или у аутентификованом гејтвеју испред услуге.

Филтер заштитног зида не може да поврати идентитет који је мрежно превођење одбацило, колико год пажљиво адреса била укуцана.

Промените власника ефективног правила

Прегледајте ефективну долазну смерницу и пронађите свако правило које тренутно допушта 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

Имена правила су овде замене за оно што је преглед пронашао, а заставица за преглед постоји да вас грешка у куцању адресе не закључа изван сервера који уређујете.

Прво блокирај, па дозволи је други модел

Навика са других заштитних зидова је да се напише широка блокада и затим уска дозвола изнад ње. У Windows-у експлицитна блокада обично побеђује дозволу, па такав редослед ствара услугу до које нико не може да стигне уместо изузетка за једног клијента. Резултат је прекид који изгледа као покварена RDP услуга. То је заправо грешка приоритета, а поправка је уклонити блокаду уместо додати још једну дозволу.

Задржите подразумевано блокирање долазног саобраћаја на активним профилима и уместо тога сузите конкретне дозволе. То оставља машину са једним разумљивим ставом уместо са два противречна правила чија интеракција зависи од детаља приоритета.

Докажите то другим извором

Тестирајте са дозвољеног клијента и са извора који сада треба да не успе. Једина успешна веза доказује само да дозвољени пут ради; не говори ништа о искључењу које сте управо направили.

Поновите тест преко IPv6 ако га сервер има укљученог, јер намера само за IPv4 може постојати уз широку дозволу за IPv6 у коју нико није погледао.

На крају, држите аутентификацију одвојено од доступности. Аутентификација на мрежном нивоу, права налога и ограничења пријаве и даље одлучују ко сме да користи сесију, а заштитни зид одлучује само ко сме да пита. Уклањање уређаја касније требало би да уклони и његову VPN регистрацију и ову мрежну дозволу, иначе ће адреса коју сте ограничили једног дана припасти неком другом.

Повезани чланци