Правила брандмауера Windows, які справді мають значення (і налаштування за замовчуванням, яким можна довіряти)

Правила, які справді мають значення (90% випадків)

Більшість наборів правил брандмауера Windows галасливі з тієї самої причини, з якої більшість шаф захаращені: ніхто не хоче викидати щось, що може стати в нагоді. Так у вас з’являється 700 вхідних правил, 600 з них вимкнені, і кілька записів «TEMP – DO NOT DELETE» з 2019 року, до яких ніхто не наважується доторкнутися.

Якщо ви керуєте продакшен-системами, існує невелика кількість категорій правил, від яких залежить, чи пройде у вас звичайний день, чи вибухне хвиля заявок у тикет-системі:

1) Доступ для віддаленого адміністрування (RDP, WinRM, WMI)

Це критично. Якщо ви заблокуєте власну площину управління, ваше «загартування безпеки» перетвориться на генератор відмов. Визначте, яким віддаленим управлінням ви користуєтесь, і явно дозволіть його з відомих джерел. Потім протестуйте з цих джерел.

• RDP TCP/3389 (або ваш кастомний порт, якщо наполягаєте)
• WinRM TCP/5985 (HTTP) і TCP/5986 (HTTPS)
• WMI/DCOM RPC endpoint mapper TCP/135 плюс динамічні RPC-порти (про це далі)

2) Справжні порти прослуховування застосунку

Якщо додаток слухає на TCP/443, вам важливий саме TCP/443 вподовж вхідних з’єднань. Усе інше — допоміжні речі. Не «відкривайте діапазон на всякий випадок». Відкривайте порт, до якого сервіс прив’язаний, з обмеженням по мережах-джерелах, яким це потрібно.

3) Розв’язування і синхронізація часу (DNS, NTP)

DNS ламає все, виглядаючи ніби нічого не сталося. Зсув часу ламає автентифікацію, виглядаючи як «рандом». Вихідний DNS (UDP/TCP 53) та вихідний NTP (UDP 123) — це нудні правила, з якими не потрібно вигадувати.

4) Залежності сервісів каталогів (для серверів у домені)

Kerberos, LDAP/LDAPS і час від часу RPC-виклики — це приховані підпори під «вхід у систему працює» і «GPO застосовано». Багато організацій обходяться «дозволити будь-куди для вихідних з’єднань» на серверах — це брудно, але працює. Якщо ви звужуєте вихідний трафік, залежності домену треба планувати, а не виявляти опівночі.

5) Файловий обмін і адміністративні шарінги (SMB)

SMB потужний і часто зловживається. Для серверів, яким не потрібен вхідний SMB, блокуйте його. Для тих, кому потрібен — звужуйте доступ і логуте його.

• SMB TCP/445
• Устарілі NetBIOS-порти (UDP/137, UDP/138, TCP/139) варто розглядати як «чому це ще тут?»

6) Контроль вихідного трафіку, що запобігає перетворенню «малого інциденту» на «великий»

Вхідні правила зупиняють небажаний доступ. Вихідні правила зупиняють ваш сервер від того, щоб стати активним учасником чужого бізнес-моделю. У зрілому середовищі політика виходу важлива — особливо для серверів, які повинні розмовляти лише з кількома внутрішніми залежностями.

Сухий факт: якщо ви не готові інвентаризувати залежності, не починайте з агресивного блокування виходу. Ви просто створите новий вид спорту під назвою «вгадати відсутній егрегес».

Жарт №1: Правило брандмауера з назвою «TEMP» має період напіврозпаду довший, ніж плутоній в більшості підприємств.

Налаштування за замовчуванням, яким можна довіряти (і коли ні)

Налаштування за замовчуванням Windows Defender Firewall не випадкові. Вони створені, щоб ОС була придатною в дуже різних умовах: ноутбуки в кафе з Wi‑Fi, сервери в домені, дев-бокси з сумнівними тулчейн-бібліотеками та кіоски, які взагалі не мали бути онлайн.

Чому зазвичай можна довіряти

• За замовчуванням для вхідних підключень: блокувати небажаний вхідний трафік, якщо немає правила, яке його дозволяє. Це правильна базова політика для хостів Windows.
• Станова поведінка: встановлені з’єднання працюють як слід. Якщо сервер ініціює вихідне TCP-з’єднання, відповідний трафік дозволяється без потреби вхідних правил для ефемерних портів.
• Основні мережеві правила: багато вбудованих правил існують, щоб Windows могла виконувати базові функції (DHCP, поведінка DNS-клієнта, базовий ICMP тощо). Вам не потрібно «спрощувати» шляхом їх видалення. Вимикайте або звужуйте свідомо, але не влаштовуйте тотальний підпал.
• Різні профілі: розділення Domain/Private/Public дійсно корисне — коли машина правильно класифікована.

Де налаштування за замовчуванням можуть підвести

Налаштування за замовчуванням корисні тільки за тих припущень, що їх підкріплюють. Ось де вас можуть підвести:

• Неправильна класифікація профілю: сервер, який думає, що він у Публічній мережі, застосує Публічний профіль. Цей профіль часто більш обмежений. Результат: «вчора працювало, нічого не змінювалося», але насправді зміни сталися.
• Правила «Allow if secure»: деякі вбудовані правила залежать від IPsec або контексту автентифікації. Якщо ви цього не використовуйте, такі правила можуть не працювати як «дозволити».
• Сторонні засоби безпеки: пакети захисту кінцевих точок іноді додають свої виклики, фільтри WFP або локальні правила. Ви виявляєте, що розбираєтеся з «Windows Firewall», коли блок насправді знаходиться в іншому шарі стеку.
• Локальні правила vs GPO: в доменних середовищах політики зливаються. Ваша локальна «правка» може бути перезаписана або взагалі не застосована, і ви неправильно діагностуєте проблему, якщо не перевірите ефективну політику.

Практична позиція: довіряйте базовій поведінці (станова фільтрація, за замовчуванням блокувати вхід), довіряйте вбудованим OS‑правилам, якщо немає підстав інакше, і не довіряйте нічому, що залежить від «правильного» мережевого профілю, поки ви його не перевірили.

Профілі: Доменний vs Приватний vs Публічний (і чому невірна класифікація псує дні)

Брандмауер Windows Defender застосовує правила за профілями. Профілі — це не косметика. Це фактично різні набори політик. Помилково обраний профіль — і ви клянетеся, що брандмауер «випадковий». Він не випадковий. Він слухняний — просто неправильному профілю.

Доменний профіль

Застосовується, коли Windows вважає, що підключений до свого домену та може достукатися до контролера домену. У серверних середовищах тут зазвичай розміщують реальну політику: дозволити управління з бастіонів, дозволити порти додатків від балансувальників, дозволити моніторинг від підмереж систем моніторингу, блокувати решту.

Приватний профіль

Зазвичай для довірених недоменних мереж. В організаціях це часто стає «профілем лабораторії» або «профілем серверів у робочій групі». Розглядайте його як напівдовірений. Не робіть його універсальним «дозволити все».

Публічний профіль

Для недовірених мереж. Ноутбуки люблять цей профіль. Сервери майже ніколи не повинні бути в ньому — хіба що хтось помістив сервер у DMZ без доступності домену і забув, що Windows класифікує на основі виявлення мережі.

Діагностично: коли щось ламається після перезавантаження, переміщення підмережі, змін VPN або обслуговування контролера домену — перш ніж робити щось хитре, перевірте активний профіль.

Оцінка правил і пріоритети: як Windows вирішує «дозволено» vs «ні»

Брандмауер Windows Defender може виглядати як таблиця до тих пір, поки ви не зрозумієте, що він реалізований через Windows Filtering Platform (WFP). Вам не потрібно ставати інженером WFP, але кілька ментальних моделей вам знадобляться:

Станова фільтрація: відповідний трафік не потребує «вхідного дозволу»

Якщо сервер ініціює вихідне з’єднання на TCP/443, відповідний трафік дозволяється назад. Люди іноді створюють вхідні правила для ефемерних портів, щоб «вирішити» це, і так у вас з’являються політики у вигляді швейцарського сиру.

Блокувальні правила перевищують дозволи

Якщо трафік відповідає явному правилу блокування, він буде заблокований навіть якщо інше правило дозволило б його. Це добре. Це дозволяє створювати підхід «дозволити широко, блокувати вузько» (або навпаки) залежно від стилю політики. Але це також означає, що одне надто широке правило блокування може тихо вбити доступ.

Більш конкретні правила не завжди «вищі за пріоритетом»

Windows оцінює набір застосовних правил. Ви не можете покладатися на принцип «я створив правило пізніше» як механізм пріоритету. Потрібно впевнитися, що немає конфліктного блок‑правила, і перевірити ефективну політику.

GPO vs локальна політика: змонтована реальність

У доменних середовищах правила можуть походити з:

• локальної політики брандмауера на хості
• правил брандмауера в Group Policy
• сторонніх викликів WFP (це не «правила», а фільтри, що поводяться як вони)

Коли хтось каже «я дозволив це в брандмауері», ваше наступне питання має бути «в якому шарі, і чи це ефективно?»

Ключові служби Windows: порти, про які варто думати, а не запам’ятовувати

Списки портів корисні, поки вони не перетворюються на культ. Думайте в термінах залежностей і ролей:

Залежності ідентичності та домену

• Kerberos: TCP/UDP 88 (аутентифікація)
• LDAP: TCP/UDP 389; LDAPS: TCP/636
• Global Catalog: TCP 3268/3269
• DNS: TCP/UDP 53 (бо AD тісно пов’язаний із DNS)
• Час: UDP 123 (Kerberos дуже чутливий)

Площина управління

• RDP: TCP 3389
• WinRM: TCP 5985/5986
• Віддалені журнали подій / MMC інструменти: можуть вимагати RPC/SMB залежно від способу використання

Файловий і принт‑шерінг (SMB)

SMB (TCP/445) — ось що справді важливо. Якщо ви ще бачите NetBIOS‑порти у 2026 році, запитайте «яка спадкова залежність тримає нас у полоні?» Потім плануйте її виведення.

Динамічні порти RPC: те, що люди ламають навмисно

RPC — це не «відкрив TCP/135 і все». TCP/135 — це endpoint mapper. Реальний сервіс часто використовує динамічні порти. Якщо потрібно дозволити управління на основі RPC через фаєрвол, зазвичай обмежують діапазон динамічних портів і явно дозволяють цей діапазон. Інакше ви отримаєте або (a) раптові відмови, або (b) величезний діапазон портів, відкритий «тимчасово».

Практичні завдання: 12+ команд, виводи та рішення

Це команди, які я реально виконую, коли я на Windows‑машині (або в віддаленій сесії) і намагаюся відповісти на одне питання: «Чи саме брандмауер є причиною загибелі цього трафіку?» Кожне завдання містить, що означає вивід і яке рішення ви робите далі.

Завдання 1: Перевірити, які профілі брандмауера активні

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain     True Block                Allow
Private   False Block                Allow
Public    False Block                Allow

Що це означає: Доменний профіль активний і застосовує «Block inbound, Allow outbound». Це розумна база.

Рішення: Якщо активний неправильний профіль (Public на доменному сервері), виправте класифікацію мережі, перш ніж торкатись правил.

Завдання 2: Підтвердити категорію мережі (Private/Public) і сигнал підключення до домену

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory, IPv4Connectivity, DomainAuthenticationKind"
InterfaceAlias NetworkCategory IPv4Connectivity DomainAuthenticationKind
-------------- -------------- --------------- ------------------------
Ethernet0       DomainAuthenticated Internet   Kerberos

Що це означає: Windows вважає, що машина автентифікована в домені. Добре. Якщо тут Public — очікуйте жорсткішу політику.

Рішення: Якщо категорія неправильна після переміщення, перевірте NLA, DNS і досяжність контролера домену; не «вирішуйте» це широкими винятками фаєрволу.

Завдання 3: Перевірити, чи сервіс реально слухає

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -in 443,3389,5985 } | Select-Object LocalAddress, LocalPort, OwningProcess"
LocalAddress LocalPort OwningProcess
------------ --------- ------------
0.0.0.0             443        4120
0.0.0.0            3389        1096

Що це означає: Хтось слухає на 443 і 3389. Якщо порт не слухає — брандмауер не ваш основний підозрюваний.

Рішення: Якщо не слухає, переходьте до конфігурації сервісу/прив’язки додатку. Не відкривайте порти для сервісів, яких немає.

Завдання 4: Зіставити порт прослуховування з процесом і сервісом

cr0x@server:~$ powershell -NoProfile -Command "$p=Get-Process -Id 4120; $p.Name"
w3wp

Що це означає: Процес IIS worker володіє 443. Тепер ви знаєте, що захищаєте і що можете порушити.

Рішення: Якщо власник процесу несподіваний, можливо, неправильний сервіс прив’язаний до порту або якийсь тіньовий сервіс його захопив.

Завдання 5: Перевірити ефективні вхідні правила, що відповідають порту (приклад: 443)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 443 } | Select-Object InstanceID, LocalPort, Protocol"
InstanceID                              LocalPort Protocol
----------                              --------- --------
{A1B2C3D4-1111-2222-3333-444455556666}  443       TCP

Що це означає: Існує принаймні одне ввімкнене правило allow для вхідного TCP/443.

Рішення: Якщо дозволу немає — створіть його, звузивши до потрібних джерел. Якщо є — шукайте конфліктне блок‑правило або невідповідність профілю.

Завдання 6: Полювати на явні блок‑правила, що можуть перебивати ваші дозволи

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Inbound -Action Block | Select-Object DisplayName, Profile, PolicyStoreSource | Format-Table -AutoSize"
DisplayName                         Profile        PolicyStoreSource
-----------                         -------        -----------------
Block inbound from guest VLAN       Domain         GroupPolicy
Block all inbound (temporary)       Domain,Public  Local

Що це означає: Локальне «Block all inbound» може знищити ваш день, і воно перевищить багато правил allow.

Рішення: Якщо існує надто широке блок‑правило, вимкніть або звузьте його, потім повторно протестуйте. Також з’ясуйте, хто його створив і навіщо.

Завдання 7: Підтвердити область дії правила (віддалені адреси) для allow‑правила

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Where-Object DisplayName -Match 'HTTPS' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
RemoteAddress
-------------
10.20.30.0/24

Що це означає: Правило дозволяє лише конкретну підмережу. Чудово для безпеки; жахливо, якщо ваш балансувальник живе в іншому місці.

Рішення: Якщо легітимні клієнти поза цією областю, обережно розширте область (додайте правильні підмережі), а не вмикайте «Any».

Завдання 8: Увімкнути логування фаєрвола (тимчасово) для активного профілю

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallProfile -Name Domain -LogAllowed True -LogBlocked True -LogFileName 'C:\Windows\System32\LogFiles\Firewall\pfirewall.log' -LogMaxSizeKilobytes 32768"

Що це означає: Логування увімкнено. Це допомагає припинити здогадки.

Рішення: Використовуйте логування під час інциденту, потім налаштуйте: тримайте логування блокувань включеним для ключових серверів, але не переповнюйте диски на галасливих машинах.

Завдання 9: Прочитати останні заблоковані з’єднання з логу фаєрвола

cr0x@server:~$ powershell -NoProfile -Command "Get-Content 'C:\Windows\System32\LogFiles\Firewall\pfirewall.log' -Tail 10"
2026-02-05 12:01:21 DROP TCP 10.20.40.15 10.20.30.10 51512 443 60 S 1234567890 0 65535 - - - RECEIVE
2026-02-05 12:01:22 DROP TCP 10.20.40.15 10.20.30.10 51513 443 60 S 1234567891 0 65535 - - - RECEIVE

Що це означає: Клієнт 10.20.40.15 відкидається при підключенні до 10.20.30.10:443. Це ваша димова гармата.

Рішення: Додайте/підправте allow‑правило для цього джерела (або виправте маршрутизацію/NAT, якщо джерело IP не те, що очікуєте).

Завдання 10: Перевірити підключення до віддаленого сервісу з Windows‑хоста

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.50.20 -Port 1433"
ComputerName     : 10.20.50.20
RemoteAddress    : 10.20.50.20
RemotePort       : 1433
InterfaceAlias   : Ethernet0
SourceAddress    : 10.20.30.10
TcpTestSucceeded : True

Що це означає: Вихід до SQL Server працює з цього хоста (принаймні TCP‑хендшейк).

Рішення: Якщо це не вдається, перевіряйте вихідні правила, профіль і будь‑який верхній фаєрвол. Якщо успішно, але додаток падає — маєте справу з автентифікацією, TLS або проблемами рівня застосунку.

Завдання 11: Перелічити вихідні правила, що можуть блокувати критичний егрегес

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block' | Select-Object DisplayName, Profile, PolicyStoreSource | Format-Table -AutoSize"
DisplayName                          Profile PolicyStoreSource
-----------                          ------- -----------------
Block outbound to Internet           Domain  GroupPolicy
Block outbound except allowlist      Domain  GroupPolicy

Що це означає: Ви в середовищі з обмеженням вихідного трафіку (це добре), і тепер потрібно переконатися, що залежності явно дозволені (також добре, але робота є).

Рішення: Якщо знайдете відсутню залежність, додайте allow‑правило для IP/портів призначення і задокументуйте причину.

Завдання 12: Перевірити, звідки походять правила — GPO чи локально

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True | Select-Object -First 5 DisplayName, PolicyStoreSource, PolicyStoreSourceType | Format-Table -AutoSize"
DisplayName                          PolicyStoreSource PolicyStoreSourceType
-----------                          ---------------  ---------------------
Core Networking - DNS (UDP-Out)      Local            Local
Allow HTTPS inbound to web tier      GroupPolicy      GroupPolicy
Block all inbound (temporary)        Local            Local
Allow WinRM from bastion             GroupPolicy      GroupPolicy
Core Networking - DHCP (UDP-Out)     Local            Local

Що це означає: Ви бачите походження правил. Це покінчує з суперечками.

Рішення: Якщо локальне правило конфліктує з GPO, вирішіть, чи дозволені локальні правки; часто правильне виправлення — в GPO, щоб було консистентно.

Завдання 13: Підтвердити, чи локальні правила взагалі дозволені (GPO може їх відключити)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile -Name Domain | Select-Object Name, AllowLocalRules, AllowLocalIPsecRules"
Name   AllowLocalRules AllowLocalIPsecRules
----   -------------- --------------------
Domain            True                 True

Що це означає: Локальні правила можуть застосовуватись. Якби тут було False, локальні «фікси» не допомогли б.

Рішення: Якщо локальні правила заборонені, припиніть їх редагувати і йдіть до джерела політики (GPO) або до команди, яка її контролює.

Завдання 14: Короткий знімок стану брандмауера (legacy netsh досі корисний)

cr0x@server:~$ netsh advfirewall show allprofiles
Domain Profile Settings:
----------------------------------------------------------------------
State                                 ON
Firewall Policy                        BlockInbound,AllowOutbound
LocalFirewallRules                      N/A (GPO-store only)
LocalConSecRules                        N/A (GPO-store only)
Logging:
LogAllowedConnections                   Enable
LogDroppedConnections                   Enable
FileName                               C:\Windows\System32\LogFiles\Firewall\pfirewall.log
MaxFileSize                             32768

Private Profile Settings:
----------------------------------------------------------------------
State                                 OFF

Public Profile Settings:
----------------------------------------------------------------------
State                                 OFF

Що це означає: Домен увімкнений; локальні правила недоступні, бо політика тільки в GPO (цей вивід залежить від версії/налаштувань).

Рішення: Якщо ви бачите «GPO-store only», виправляйте правила на рівні GPO, а не локально.

Завдання 15: Зняти цілеспрямований трасування WFP, коли логів недостатньо

cr0x@server:~$ netsh wfp capture start file=C:\Temp\wfptrace.cab
WFP capture started.

cr0x@server:~$ netsh wfp capture stop
WFP capture stopped.

Що це означає: Ви зняли події WFP. Це важче, ніж pfirewall.log, і корисно, коли сторонній виклик блокує трафік.

Рішення: Використовуйте це, коли сильно підозрюєте «це не правила фаєрволу, це щось у WFP», і вам потрібні докази для власника інструменту безпеки.

Завдання 16: Додати безпечне, звужене вхідне allow‑правило (приклад: дозволити HTTPS від балансувальників)

cr0x@server:~$ powershell -NoProfile -Command "New-NetFirewallRule -DisplayName 'Allow HTTPS from LB subnets' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 443 -RemoteAddress 10.20.40.0/24,10.20.41.0/24 -Profile Domain"

Що це означає: Ви додали вузько обмежене allow‑правило лише для Domain профілю.

Рішення: Негайно протестуйте з цих підмереж. Якщо працює — внесіть зміну в policy‑as‑code або GPO, щоб витримувати аудит і перезборки.

Завдання 17: Тимчасово відключити підозріле правило (з аудиторським слідом)

cr0x@server:~$ powershell -NoProfile -Command "Disable-NetFirewallRule -DisplayName 'Block all inbound (temporary)'"

Що це означає: Це правило більше не застосовується.

Рішення: Якщо сервіс відновився — ви знайшли винуватця. Тоді замініть його на точніше блок‑правило або видаліть його з джерела істини. Не залишайте «тимчасові» вимкнені правила як постійний артефакт.

Швидкий план діагностики (перший/другий/третій)

Коли з’єднання падає, ви зазвичай переслідуєте одне з чотирьох: сервіс не слухає, маршрут неправильний, блокує фаєрвол або TLS/автентифікація відмовляє. Трюк — визначити, у якій корзині ви за кілька хвилин, а не на зустрічі.

Перший: доведіть, що сервіс існує на цільовій машині

• Перевірте, чи порт слухає (Get-NetTCPConnection -State Listen).
• Підтвердіть процес/сервіс, що володіє ним (зіставити PID до процесу).
• Якщо не слухає — зупиніться. Виправте сервіс. Правила фаєрволу не воскресать прослуховувача.

Другий: доведіть, що пакети доходять (або ні)

• Увімкніть логування фаєрвола (на короткий термін) і перевірте DROPs на цільовий порт.
• Якщо бачите DROPs — це локальний фаєрвол або WFP. Якщо нічого не бачите — трафік може не доходити до хоста (верхній ACL, маршрутизація, неправильний VIP, неправильний IP).
• Перевірте, чи IP‑адреса джерела в логах збігається з очікуваною (балансувальники й NAT люблять сюрпризи).

Третій: перевірте ефективну політику та конфлікти

• Перевірте активний профіль. Неправильно профільовані хости — мовчазний вбивця.
• Пошукайте блок‑правила, що можуть перебивати дозволи.
• Перевірте область дії правила (віддалені адреси, типи інтерфейсів, профілі).
• Підтвердіть джерело правила (GPO vs локально). Не «фіксуйте локально» те, що централізовано нав’язано.

Четвертий (коли все ще дивно): підозрюйте виклики WFP і засоби захисту кінцевої точки

• Якщо логи показують allow, але трафік усе одно падає, або нічого не з’являється — зніміть WFP‑трасу.
• Корелюйте зі змінами засобів захисту кінцевої точки. «Фаєрвол» може бути не тим компонентом, що блокує.

Три корпоративні міні‑історії з передової брандмауера

Міні‑історія 1: Інцидент через неправильне припущення (профіль ≠ домен)

Середовище на папері було акуратним: веб‑сервери Windows у домені, правила брандмауера керуються через GPO, вхід тільки від балансувальників, управління лише з бастіону. Така конфігурація заспокоює аудиторів і дає спокій операторам.

Потім вікно обслуговування вивело з ладу пару контролерів домену в віддаленому сайті. Саме в тому сайті розташовувалися кілька веб‑серверів за локальним балансувальником. Сервери працювали, але через годину перевірки стану почали падати. Половина пулу стала «нездоровою», потім більшість.

Спочатку всі ганялися за балансувальником. VIP був стабільний. Налаштування health check не змінювалося. Мережевики показували чисті потоки на свічі. Апп‑команда наполягала, що сервіс працює. Він працював — локально.

Справжня проблема: сервери тихо переключилися з DomainAuthenticated на Public, бо не могли достукатися до контролера домену. Публічний профіль не мав вхідного allow для джерела health check, бо ніхто не очікував, що доменний сервер стане «публічним». Брандмауер зробив саме те, що йому наказали, у профілі, який вважав активним.

Виправлення не було в «відкрити більше портів». Виправлення — зробити середовище стійким до збоїв доступності DC: забезпечити резервні контролери домену, а для специфічних ролей у DMZ явно визначити поведінку, якщо Доменний профіль недоступний. Також робіть моніторинг змін профілю. Аутгайна не була спричинена фаєрволом; її спричинило припущення.

Міні‑історія 2: Оптимізація, що відвернулась проти (вихідний deny без інвентаризації)

Програма безпеки вирішила «зменшити поверхню атаки», увівши вихідний deny‑за‑замовчуванням на Windows‑серверах. Філософськи це розумно. Практично — це проєкт відкриття залежностей у плащі‑тренчі.

Впровадили по фазах. Початкові результати були гарні: менше вихідного трафіку, менше дивних з’єднань в інтернет, панелі трендів виглядали краще. Потім настала ніч оновлень.

Windows Update було заблоковано. Також CRL/OCSP‑перевірки для TLS‑сертифікатів у кількох додатках. Потім агент моніторингу не зміг дістатися свого колектора, бо хтось забув, що він використовує TCP/443 до SaaS‑ендпоінту. Тим часом операційна команда, щоб стабілізувати ситуацію, додавала ad‑hoc allow‑правила локально — і виявилося, що локальні правила вимкнені через GPO.

Провал полягав не в тому, що контроль виходу поганий. Провал — у тому, що це сприйняли як одноразову «оптимізацію», а не як операційну здатність. Allowlist виходу вимагає підтримуваного каталогу залежностей, процесу винятків, що працює швидко, і спостереження (логи), щоб бачити, що ви блокуєте.

Вони врешті досягли успіху, але тільки після побудови пайплайна allowlist, прив’язаного до маніфестів додатків і тегів середовища. Урок: контролі безпеки, що неоперабельні, стають причиною відмов. Відмови стають винятками. Винятки стають реальною політикою.

Міні‑історія 3: Нудна, але правильна практика, що виручила (звужені правила + логування)

У фінансовій системі була проста політика: кожен production Windows‑сервер повинен мати увімкнене логування відкинутих пакетів для Domain профілю з відправкою логів до центрального колектора. Не вічно деталізовано; достатньо, щоб відповісти на питання «що було заблоковано?» без RDP‑входів у кожну машину.

Одного ранку пакетна задача перестала діставатися файлового сервера. Задача працювала від сервісного акаунту на апп‑сервері і працювала роками. Команда файлового сервера казала, що «нічого не міняла». Апп‑команда казала, що «нічого не міняла». Всі технічно праві — найгірший вид правоти.

Логи відкинутих пакетів розповіли історію за п’ять хвилин: змінилася IP‑адреса джерела. Апп‑сервер був перебудований у нову підмережу під час чистки віртуалізації. Правило файлового сервера дозволяло SMB лише зі старої підмережі. Ось і все. Ніякої таємниці.

Виправлення було так само нудне: оновити SMB allow‑правило, додати нову підмережу, підтвердити доступ і оновити автоматизацію побудов, щоб нові адреси реєструвалися у джерелі істини для області правил. Нікому не довелося гадати або «тимчасово відкривати 445 для Any». Нудна практика — звужені правила плюс централізовані логи відкинутих пакетів — виручила.

Жарт №2: Найшвидший спосіб дізнатися, від чого залежить ваш додаток — заблокувати вихідний трафік і почекати, поки хтось не закричить.

Типові помилки: симптом → корінна причина → виправлення

1) «Працює з однієї підмережі, але не з іншої»

Симптом: Деякі клієнти підключаються, інші — таймаут або відмова.

Корінна причина: Allow‑правило має вузьку область RemoteAddress, що не включає підмережу, яка падає, або трафік NAT‑иться, тому IP‑адреса джерела відрізняється.

Виправлення: Перевірте логи відкидання для фактичного IP‑адреси джерела. Розширте область правила, щоб включити правильні діапазони. Якщо є NAT — координуйтеся з мережею, щоб дозволити трансляцію джерела.

2) «Після перезавантаження ніхто не підключається»

Симптом: Сервер піднімається, сервіси працюють, але вхідний доступ відсутній.

Корінна причина: Змінився профіль (Domain → Public) через NLA/DC‑доступність. Або GPO пере‑застосовано і вилучило локальний виняток.

Виправлення: Перевірте профіль і стан автентифікації домену. Виправте DNS/досяжність DC. Не засовуйте широке allow у Public, якщо ви навмисно не підтримуєте недоменний сценарій.

3) «RDP заблоковано, але правило ввімкнене»

Симптом: RDP таймаутиться; ви бачите allow‑правило для 3389.

Корінна причина: Правило застосовується до неправильного профілю, неправильного типу інтерфейсу, або його перекриває ширше блок‑правило. Також можливо: RDP переміщено на інший порт, а правило не оновлено.

Виправлення: Підтвердіть порт прослуховування, активний профіль і пошукайте inbound block‑правила. Звужуйте allow лише до мережі бастіону. Переконайтеся, що конфігурація сервісу відповідає правилу.

4) «WinRM працює на деяких серверах, але не на інших»

Симптом: Автоматизація не працює для підмножини Windows‑хостів.

Корінна причина: Непослідовне застосування GPO, локальні правила вимкнені на деяких хостах, або WinRM прив’язаний до HTTPS без доступного ланцюжка сертифіката (виглядає як «мережа»).

Виправлення: Перевірте джерело політики. Підтвердіть конфігурацію і порти WinRM. Якщо використовується 5986 — переконайтеся в довірі сертифікатів і досяжності CRL/OCSP (вихідні правила важливі).

5) «DNS не працює, але тільки на цьому сервері»

Симптом: Розв’язування імен не працює; IP‑зв’язок є.

Корінна причина: Вихід UDP/53 блокується політикою виходу, або TCP‑fallback для DNS заблокований, або неправильна конфігурація DNS‑серверів у поєднанні з вихідними обмеженнями.

Виправлення: Тестуйте UDP і TCP до DNS‑серверу. Додайте явні вихідні дозволи до DNS‑серверів. Перевірте налаштування DNS сервера та будь‑які умовні форвардери в середовищі.

6) «Поставник каже, що потрібні “купа портів”, тому ми відкрили 1–65535»

Симптом: Постачальник наполіг. Заяву схвалили. Ніхто не пам’ятає, навіщо це було.

Корінна причина: Відсутність відображення залежностей і страхове управління змінами.

Виправлення: Відкотіть до найменшого привілею: визначте фактичні порти прослуховування, обмежте діапазони для RPC динаміки за потреби, дозволяйте лише потрібні джерела. Використовуйте логи, щоб перевірити, що падає при звуженні.

7) «Ми створили правило, але воно все одно не працює»

Симптом: Правило існує; трафік все одно падає.

Корінна причина: Правило в локальному сховищі, але локальні правила вимкнені через GPO. Або правило ввімкнене, але не застосовується через невідповідність профілю/інтерфейсу.

Виправлення: Перевірте AllowLocalRules і джерело правила. Помістіть правило у правильне сховище політик (зазвичай GPO) і переконайтеся, що воно відповідає активному профілю.

Контрольні списки / покроковий план

Контрольний список A: Мінімальна життєздатна позиція брандмауера для Windows‑серверів

1. Тримайте блокування вхідних за замовчуванням на всіх профілях. Не «тимчасово дозволяйте весь вхід». Зробіть це соціально неприйнятним.
2. Дозвольте управління (RDP/WinRM) лише з бастіонних/джамп‑підмереж. Якщо дозволяєте з «Any», ви створили приціл.
3. Дозвольте порти додатків лише з реальних мереж клієнтів (балансувальники, шари додатків, підмережі користувачів за потреби).
4. Дозвольте вихід до внутрішнього DNS і NTP явно, якщо ви застосовуєте обмеження вихідного трафіку.
5. Блокуйте вхідний SMB на серверах, яким воно не потрібно. Якщо потрібно — дозволяйте лише з мереж адміністраторів.
6. Увімкніть логування відкинутих пакетів принаймні на критичних шарах і централізуйте логи.
7. Документуйте винятки з власником і датою закінчення. Потім примусово контролюйте терміни.

Контрольний список B: Коли просять «відкрити порти для додатку»

1. Визначте порти прослуховування додатка на хості (не довіряйте PDF від постачальника).
2. Визначте мережі‑джерела, яким потрібен доступ (клієнти, балансувальники, моніторинг, пакетні задачі).
3. Створіть вхідні allow‑правила, звужені за: профілем, протоколом, локальним портом, віддаленою адресою та (якщо можливо) програмою/сервісом.
4. Якщо задіяний RPC — обмежте діапазон динамічних портів і дозволяйте цей діапазон — не відкривайте «всі високі порти».
5. Увімкніть логування під час розгортання. Переконайтеся, що очікувані клієнти дозволені, а небажані сканування блокуються.
6. Запишіть набір правил у систему запису (шаблон GPO, конфігураційний менеджмент, policy‑as‑code). Локальні правки — борг.

Контрольний список C: Загартування без самосаботажу

1. Почніть з вхідного найменшого привілею перед вихідним. Це простіше і дає реальне зниження ризику.
2. Якщо впроваджуєте контроль виходу — робіть це за ролями (веб, апп, БД, управління) з каталогами залежностей.
3. Тестуйте залежності домену явно для доменних хостів (Kerberos, LDAP, DNS, час).
4. Моніторте зміни профілю і зміни політики брандмауера як первинні сигнали.
5. Не видаляйте вбудовані правила лише щоб відчути продуктивність. Вимикайте з наміром і фіксуйте причину.

Цікаві факти та контекст (бо історія пояснює налаштування за замовчуванням)

• Факт 1: Брандмауер Windows став широко вмикатись за замовчуванням ще за епохи Windows XP SP2, коли черв’яки зробили витрати від відкритих вхідних портів надто болючими.
• Факт 2: Сучасний движок — Windows Filtering Platform (WFP), який дозволяє кільком компонентам (включно із засобами безпеки) брати участь у прийнятті рішень по трафіку.
• Факт 3: Профілі (Domain/Private/Public) пов’язані з Windows Network Location Awareness. Це не ручні «мітки»; вони змінюються залежно від того, що Windows виявляє про мережу.
• Факт 4: Багато «Core Networking» правил існують, бо Windows має виконувати базові хост‑функції (DHCP, виявлення сусідів, поведінка DNS). Їх видалення зазвичай створює відмови, що виглядають як «Windows нестабільний».
• Факт 5: Динамічна поведінка RPC історично гнучка, щоб уникнути колізій портів і підтримати кілька сервісів; водночас це часта причина, чому проекти з жорсткого захисту брандмауера ускладнюються.
• Факт 6: Group Policy не лише додає правила брандмауера — вона може вирішити, чи локальні правила взагалі можуть застосовуватися, тому «я додав правило локально» іноді нічого не дає.
• Факт 7: Станова фільтрація означає, що вхідні ефемерні порти не потрібно відкривати для зворотного трафіку, але люди все ще це роблять, бо вчилися на старіших статeless‑файрволах.
• Факт 8: Правила брандмауера Windows можна звужувати по програмах/сервісах, а не лише по портах, що робить їх більш стійкими на хостах з кількома додатками.
• Факт 9: Формат логів фаєрвола (pfirewall.log) свідомо простий. Він задуманий як парсабельний і придатний для відправки, а не як красивий.

Одна операційна ідея, яка залишається істинною у всі часи: Управління передбачуваними відмовами дає надійність, а не надія на їх відсутність — парафраз думки John Allspaw

Питання й відповіді

П1: Чи можна довіряти налаштуванням брандмауера Windows за замовчуванням на серверах?

Довіряйте базовій моделі: блокувати вхід за замовчуванням, станова обробка зворотного трафіку і вбудовані правила основних мережевих служб. Не довіряйте сліпо, що профілі завжди будуть правильними або що сторонні засоби безпеки не додадуть свої фільтри.

П2: Чому інколи мій доменний сервер показує Публічний профіль?

Зазвичай тому, що він не може достукатися до контролера домену або DNS неправильно налаштований, тож Network Location Awareness не може підтвердити автентифікацію домену. Виправте з’єднання і розв’язування імен; не заклеюйте проблему правилом «allow all» для Публічного профілю.

П3: Чи потрібні вхідні правила для ефемерних портів?

Не для зворотного трафіку на з’єднання, ініційовані вашим хостом. Потрібно думати про динамічні порти, коли дозволяєте вхідне управління на основі RPC або служби, які домовляються про динамічні порти.

П4: Який найпростіший безпечний підхід для дозволу RDP?

Дозвольте TCP/3389 вхід лише з бастіонної/джамп‑підмережі (або з конкретних робочих станцій адміністраторів через VPN), на Domain профілі. Логируйте відкидання. Не дозволяйте RDP з «Any», якщо вам подобається інцидент‑респонс як хобі.

П5: Якщо мій додаток використовує HTTPS, чи можна дозволити 443 з будь‑де?

Можна, але не варто за замовчуванням. Звужуйте по мережах‑джерелах (балансувальники, зворотні проксі, підмережі користувачів) і розгляньте можливість звуження за програмою/сервісом, щоб випадковий процес не міг прив’язати 443 і успадкувати довіру.

П6: Чому я бачу allow‑правило, але трафік все одно блокується?

Поширені причини: блок‑правило перекриває, правило застосовується до іншого профілю, локальні правила вимкнені GPO, або сторонній WFP‑виклик блокує. Перевірте логи і джерело правила.

П7: Чи варто блокувати вихідний трафік?

Так, але лише якщо ви можете його експлуатувати: підтримувати інвентар залежностей, мати швидкий процес винятків і моніторинг блокувань. Інакше це фабрика відмов і врешті отримає безліч винятків.

П8: Як швидко зрозуміти, чи фаєрвол — вузьке місце?

Підтвердіть, що порт слухає, увімкніть/перевірте логи відкидань для цього цільового порту і підтвердьте профіль та конфлікти правил. Якщо логи показують потік, що відкидається — це локальна політика. Якщо слідів немає — трафік, ймовірно, не доходить до хоста.

П9: Чи варто видаляти вбудовані правила, щоб зменшити захаращеність?

Ні. Вимикайте з наміром, якщо потрібно, але видалення вбудованих правил рідко приносить безпекову вигоду і часто шкодить стабільності. Захаращення краще вирішувати дисципліною політик і зрозумілими іменами.

Висновок: практичні подальші кроки

Якщо ви хочете, щоб брандмауер Windows перестав бути будинком з привидами, вам не потрібні сотні правил. Потрібен невеликий набір правил, які звужені, мають власника та тестуються — плюс дисципліна не «тимчасово» латаючи продакшен молотком.

1. Аудитуйте активний профіль і дії за замовчуванням на ваших серверах. Невірно профільовані хости — постійний клас відмов.
2. Визначте стандартну політику управління (RDP/WinRM) зі звуженням джерел і логуванням.
3. Для кожної ролі сервера задокументуйте порти прослуховування і створіть вхідні правила, звужені до реальних клієнтів.
4. Вирішіть, чи вихід за замовчуванням Allow або Allowlist, і якщо це allowlist — спочатку побудуйте інвентар залежностей і логування.
5. Увімкніть логування відкинутих пакетів для критичних шарів і централізуйте їх. Догадки дорого коштують.
6. Перенесіть правила у систему запису (GPO/конфігураційний менеджмент). Локальні правки не масштабуються і не переживуть відновлення.

Мета не в «максимальних налаштуваннях безпеки». Мета — політика брандмауера, яку ви зможете пояснити під час інциденту без брехні і яку зможете змінити без молитви.