При настройке сетевой безопасности на базе Windows Server 2016 системные администраторы часто сталкиваются с ситуацией, когда попытка «затянуть гайки» приводит к полной потере доступа к серверу. Типичный сценарий: вы создаете разрешающие правила для нужных служб (например, RDP), а затем добавляете общее запрещающее правило для всех портов, ожидая, что брандмауэр обработает их по порядку. Однако доступ пропадает. Разберем подробно, почему классическая логика сетевых устройств здесь не работает и как настроить систему правильно.
Рассмотрим ситуацию, описанную в обсуждении. Администратор соединил ноутбук и сервер кабелем в одной подсети. Изначально RDP (порт 3389) работает отлично. В брандмауэре настроен «Общий профиль», где по умолчанию входящие подключения запрещены, а исходящие — разрешены. Но как только создается пользовательское правило «Блокировать все входящие TCP-порты», подключение к удаленному рабочему столу обрывается, хотя стандартные разрешающие правила для RDP никуда не делись.
Проанализируем причину. Многие специалисты привыкли к работе со списками контроля доступа (ACL) на оборудовании типа Cisco или в цепочках iptables в Linux. Там правила проверяются строго сверху вниз: как только пакет встретил первое совпадение (будь то разрешение или запрет), дальнейшая проверка прекращается. В Windows Firewall (WFAS) используется совершенно иной механизм — приоритет типов правил.
Выясним, в какой последовательности операционная система обрабатывает входящий трафик. В Windows Server 2016 (и более новых версиях) порядок всегда жестко задан, и его нельзя изменить простым перемещением строк в графическом интерфейсе:
WSH запрещает трафик, никакое пользовательское правило его не откроет.Посмотрим на пример автора: создав правило «Запретить всё для TCP», он автоматически поместил его на 3-й уровень иерархии. Разрешающее правило для RDP находится на 4-м уровне. Поскольку пакет RDP является TCP-пакетом, он моментально попадает под действие блокировки, и до проверки разрешений дело просто не доходит.
Разберем, почему попытка реализовать логику deny ip any any в конце списка через пользовательское правило является ошибочной. В консоли wf.msc (Брандмауэр Windows в режиме повышенной безопасности) вы видите список правил, который можно сортировать по имени, порту или группе. Но эта сортировка — лишь визуальное представление для удобства администратора. Она никак не влияет на логику работы ядра ОС.
Если вы хотите, чтобы сервер был защищен и принимал только определенные подключения, вам не нужно создавать правило «Блокировать всё». Этот функционал уже встроен в настройки профиля. Посмотрим на правильный алгоритм настройки:
Рассмотрим, как правильно настроить брандмауэр, чтобы он работал по принципу «запрещено всё, что не разрешено явно», не создавая конфликтов приоритетов:
RDP это порт 3389 TCP, для веб-сервера — 80, 443 TCP.В такой конфигурации логика будет работать безупречно: пакет приходит, система не находит явных запретов (Block Rules), затем находит ваше разрешающее правило (Allow Rules) и пропускает трафик. Если бы правила для этого порта не было, сработала бы настройка профиля «Блокировать по умолчанию».
Проанализируем ситуацию, если сервер является частью домена. В этом случае правила могут прилетать через Групповые политики (GPO). Существует важный параметр политики: «Брандмауэр Windows: разрешение применения локальных правил брандмауэра».
Если в домене настроено «Нет», то все ваши локальные изыскания в wf.msc будут игнорироваться, и сервер будет работать только по тем правилам, которые прислал контроллер домена. Если же локальные правила разрешены, они объединяются (мержатся) с доменными. Но приоритет остается прежним: если в GPO или локально есть хоть одно правило «Блокировать порт X», этот порт будет закрыт, сколько бы разрешающих правил вы ни создали в других местах.
Для глубокого анализа можно воспользоваться инструментами автоматизации. Выясним, как посмотреть реальное положение дел с помощью PowerShell. Это поможет увидеть скрытые правила, такие как Windows Service Hardening. Используйте следующую команду для просмотра активных правил:
Get-NetFirewallRule | Where-Object {$_.Enabled -eq 'True'} | Select-Object DisplayName, Action, Direction, Priority
Хотя поле Priority в выводе часто имеет технический характер, оно помогает понять, какие правила сейчас активны и каков их тип (Allow или Block). Помните, что для диагностики сетевых соединений также полезно использовать команду Test-NetConnection для проверки доступности конкретного порта с удаленной машины.
Главный вывод нашего разбора: брандмауэр Windows Server 2016 работает не по принципу «порядка строк», а по принципу «приоритета типа действия». Чтобы избежать проблем с доступом:
Allow Rules для открытия конкретных портов.Block Rules (например, на все порты или подсети), если вы планируете внутри этих диапазонов что-то разрешать.Соблюдение этой иерархии позволит вам гибко настраивать безопасность сервера, не опасаясь внезапной потери управления над системой.