Powershell – изменяем фильтры адресов в правилах фаэрвола


В продолжение темы Наводим порядок с правилами фаэвола для Remote Desktop.

Ситуация: есть политика GPO для администраторов, которая применяется к серверам и добавляет правила фаэрвола разрешающие доступ по RDP к ним; в правилах указан список адресов (Remote Address), с которых разрешён доступ.

Задача: изменить список адресов Remote Address правил фаэрвола группы Remote Desktop

Например, появился новый администратор, и надо добавить его адрес.

Более общая ситуация: есть политика GPO для администраторов, которая применяется к серверам и добавляет правила фаэрвола разрешающие доступ к различным службам на серверах (RDP,EventLog,Shares, DCOM, WMI и т.д.); все правила имеют одинаковый список адресов (Remote Address), с которых разрешён доступ.

Задача: изменить список адресов Remote Address для всех правил фаэрвола в политике

Проблема заключается в том, что в групповой политике может быть несколько десятков правил, и править вручную каждое правило, например, добавляя ip-адрес нового администратора, очень трудоёмко. Читать далее

Реклама

Наводим порядок с правилами фаэвола для Remote Desktop


При установке новой системы на сервер нередко администратор вручную включает доступ к удаленному рабочему столу (RDP, Remote Desktop). При этом автоматически включаются соответствующие стандартные правила фаэрвола.

Если позднее на сервер приезжает групповая политика (GPO), которая централизованно управляет включением сервиса RDP и добавляет кастомизированные правила фаэрвола для RDP (например, содержат разрешение доступа по ip-адресам только для администраторов), то включенные стандартные правила начинают мешать, т.к. разрешают доступ всем, и их необходимо выключить.

Задача: среди множества серверов найти те, где нужно запретить включенные стандартные правила Remote Desktop, и произвести выключение таких правил. Читать далее

Проверка состояния Windows Advanced Firewall


Сетевые карты RTL часто становятся проблемой в доменной сети: драйвер рапортует системе, что сеть доступна, хотя она ещё не поднялась, и система, продолжая загрузку, не находит домен-контроллер и не может применить политики. Это давно известная ситуация. Но недавно обнаружился ещё один побочный эффект этой проблемы.

Если компьютер первый раз включили в некоторую сеть, то система должна эту сеть классифицировать по NLA. Но т.к. сеть недоступна в момент загрузки, то сеть будет отнесена категории Public или Private, но никак не к Domain. И если на системе включен фаервол, то примениться совсем не доменный профиль! В результате компьютер оказывается очень хорошо «защищен» от администраторов J

К сведению: Network Location Awareness (NLA) and how it relates to Windows Firewall Profiles

Чтобы хоть как-то оценить масштабы бедствия, решили использовать Compliance в SCCM 2012 R2. В него зарядили следующий VBScript скрипт (переработанный пример с MSDN):

option explicit

Dim CurrentProfiles

Dim LowerBound

Dim UpperBound

Dim iterate

Dim excludedinterfacesarray

Dim Ret

‘ Profile Type

Const NET_FW_PROFILE2_DOMAIN = 1

Const NET_FW_PROFILE2_PRIVATE = 2

Const NET_FW_PROFILE2_PUBLIC = 4

‘ Action

Const NET_FW_ACTION_BLOCK = 0

Const NET_FW_ACTION_ALLOW = 1

‘ Create the FwPolicy2 object.

Dim fwPolicy2

Set fwPolicy2 = CreateObject(«HNetCfg.FwPolicy2»)

CurrentProfiles = fwPolicy2.CurrentProfileTypes

‘// The returned ‘CurrentProfiles’ bitmask can

‘// have more than 1 bit set if multiple profiles

‘// are active or current at the same time

Ret = 0

if ( CurrentProfiles AND NET_FW_PROFILE2_DOMAIN ) then

if fwPolicy2.FirewallEnabled(NET_FW_PROFILE2_DOMAIN) = TRUE then

‘// WScript.Echo(«Firewall is ON on domain profile.»)

Ret = 1

end if

end if

WScript.Echo(1)

Скрипт оказался вдвойне полезен, т.к. он вываливается в ошибку, если сервис Windows Firewall выключен – это хорошо видно отдельной строкой в отчёте Compliance. Таким образом была отловлена пачка компьютеров, у которых кто-то умудрился выключить фаервол.