RDP працює, файловий ресурс — ні: правильно налаштуйте правила брандмауера

Що доводить RDP (і що ні)

Коли RDP працює, а файловий доступ — ні, корінна причина зазвичай одна з цих:

• Невідповідність області дії правила брандмауера: RDP дозволено для «Any», SMB дозволено лише для «Local subnet», або лише для «Domain» профілю, тоді як сервер опинився в «Public».
• Невідповідність портів: Ви відкрили 139, але SMB насправді використовує 445 (або навпаки в якихось старих сценаріях), або клієнт наполягає на SMB через 445, а ви дозволили лише RPC-ендпойнти для чогось іншого.
• Розбіжність резолювання імен: RDP використовує збережену IP або DNS-запис; SMB намагається через NetBIOS, LLMNR або з неправильним DNS-суфіксом; ви підключаєтеся до іншого хоста, ніж думаєте.
• Невідповідність шляху автентифікації: RDP працює з кешованими обліковими даними або локальними акаунтами; SMB вимагає Kerberos/LDAP до DC, до якого ви не маєте доступу з цієї мережі, тому автентифікація падає після TCP-хендшейку.
• Невідповідність політик підпису/шифрування SMB: З’єднання дозволено, але переговори не вдаються через різні політики.
• Проблеми зі stateful-фільтрацією: Деякі «розумні» брандмауери або IDS поводяться з SMB-сесіями непередбачувано, особливо через VPN/NAT.

RDP і SMB — різні тварини. RDP зазвичай — один TCP-потік до одного порту. SMB — балакуча протокольна сесія з жорсткими очікуваннями щодо неперервності сесії і часто залучає служби каталогів. Ваші правила брандмауера мають відображати цю реальність.

Жарт №1 (короткий, по суті): Брандмауери — як швейцари: вони пам’ятають одного VIP, якого впустили (RDP), і шоковані, коли приходить весь гурт (SMB).

Карта трафіку SMB: порти, протоколи і чому «445» — не вся історія

Мінімальні порти, які мають значення

Якщо йдеться про сучасний SMB (Windows 7+ / Server 2008+ і пізніші), ядро таке:

• TCP/445 — SMB direct hosting. Це той порт, який вам майже завжди потрібен.

У реальному корпоративному житті додаються ще:

• TCP/139 — SMB через NetBIOS session service (старіший; іноді використовується в мішаних середовищах).
• UDP/137, UDP/138 — NetBIOS name service та datagram service (старі механізми виявлення/резолювання імен).
• TCP/135 і діапазон динамічних RPC-портів — не потрібні для базового файлового шарингу, але потрібні для багатьох дій управління (MMC, деякі сценарії принтерів, віддалене адміністрування, DFS-управління тощо).
• Kerberos/LDAP/DNS до контролерів домену — не «порти SMB», але часто потрібні для автентифікації і розв’язування груп:
  • TCP/88 (Kerberos), TCP/389 (LDAP), TCP/636 (LDAPS), TCP/53 і UDP/53 (DNS)

Чому відкриття 445 може не вирішити проблему

Тому що відмова може статися після TCP-підключення. Типові шари:

1. Маршрутизація/ACL: Чи може клієнт дістатися до сервера взагалі (до 445) з потрібної вихідної IP?
2. Stateful-брандмауер: Чи відбувається SYN/SYN-ACK/ACK, і чи дозволено трафік у відповідь?
3. Переговори SMB: Чи погоджуються клієнт і сервер щодо діалектів (SMB2/SMB3), підпису, шифрування?
4. Автентифікація: Чи може сервер перевірити облікові дані (локальний SAM проти AD), і чи може він дістатися DC, якщо це потрібно?
5. Авторизація: Дозволи шару share та NTFS.
6. Стабільність: Проблеми MTU, middlebox-и, що скидуть довготривалі сесії, поведінка opportunistic locking або таймаути SMB.

Швидкий план діагностики: знайдіть вузьке місце перед редагуванням правил

Це найшвидший спосіб перестати ходити в темряві.

Перше: доведіть, що ви потрапляєте на правильний хост

1. Резольвьте ім’я так, як це робить SMB. Перевірте ім’я, яке ви вводите в Explorer або в команді mount.
2. Порівняйте DNS-відповідь з RDP-ціллю. Люди підключаються по RDP до IP, а потім звертаються по імені — так ви починаєте дебажити іншу машину.

Друге: протестуйте TCP/445 з клієнта

1. Запустіть тест порту (Windows: Test-NetConnection; Linux: nc).
2. Якщо він заблокований — зупиніться. Виправте маршрути/ACL/брандмауер перед тим, як змінювати конфіги SMB.

Третє: протестуйте переговори SMB і автентифікацію явно

1. Windows: спробуйте net use або Get-SmbConnection; Linux: smbclient.
2. Розрізняйте: «не вдається підключитися» vs «помилка логіну/паролю» vs «access denied». Це різні команди і різні виправлення.

Четверте: проінспектуйте профілі брандмауера і область застосування правил

1. Windows server: підтвердіть активний мережевий профіль (Domain/Private/Public).
2. Підтвердіть, що «File and Printer Sharing (SMB-In)» правило увімкнено для правильного профілю й обмежене потрібними віддаленими IP.

П’яте: робіть захоплення пакетів на обох кінцях (тільки за потреби)

1. Захоплення на клієнті: чи бачите ви, що SYN виходить? Чи повертається SYN-ACK?
2. Захоплення на сервері: чи бачите ви SYN, що приходить? Чи йдуть RST у відповідь? Це підкаже, чи саме серверний брандмауер блокує трафік.

Цікавинки й історичний контекст (що пояснює сучасні дивності)

• Факт 1: SMB починався в 1980-х в IBM і пізніше був значно розширений Microsoft; «проста» протокольна історія має десятиліття багажу.
• Факт 2: TCP/445 став дефолтним для SMB direct hosting, коли Windows відійшли від залежності від NetBIOS; отже 139 відчувається як привид, що досі переслідує аудити.
• Факт 3: Нещасні хробаки початку 2000-х (які зловживали мережевими сервісами Windows) — частина причини, чому команди безпеки ставляться до 445 як до радіоактивного за межами довірених мереж.
• Факт 4: Підпис SMB існує, щоб запобігти MITM; він підвищує цілісність, але може викликати проблеми з продуктивністю та сумісністю, якщо його включати непослідовно.
• Факт 5: SMB 3 додав шифрування на рівні протоколу (не лише через IPsec), що змінило поведінку деяких систем моніторингу та middlebox-ів.
• Факт 6: Профілі Windows Firewall (Domain/Private/Public) були створені для мобільності ноутбуків, а не серверів з кількома NIC; сервери досі дивно часто помилково профілюються.
• Факт 7: Резолювання через NetBIOS і виявлення через широкомовлення були зручні в плоских LAN; вони крихкі через маршрутизовані мережі і часто блокуються за дизайном.
• Факт 8: «File and Printer Sharing» — це набір правил, а не один вимикач; увімкнення неправильної підмножини — поширений напівфікс.
• Факт 9: Багато організацій навмисно блокують SMB через WAN/VPN і натомість надають доступ до файлів через шлюзи (DFS, SFTP, HTTPS-портали). Ваше «має працювати» може бути політикою, а не багом.

Одна цитата, бо вона досі на місці: Парафраз ідеї: «Сподівання — не стратегія.» — часто цитують в операційних колах; сприймайте як девіз SRE, а не як догму.

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

Це реальні перевірки, які ви можете виконати. Кожна містить, що означає вивід і що робити далі. Оберіть шлях, що відповідає вашому середовищу.

Завдання 1: Підтвердити, що ви використовуєте ту саму ціль для RDP і SMB (Windows-клієнт)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName filesrv01.corp.example -Type A | Select-Object -ExpandProperty IPAddress"
10.20.30.40

Значення: Ім’я SMB резольвиться в 10.20.30.40. Якщо ви підключалися по RDP до 10.20.30.41, ви дебажите дві різні машини.

Рішення: Якщо невідповідність — виправте DNS/hosts або використовуйте правильне ім’я/IP послідовно. Зупиніться доти, поки цілі не співпадуть.

Завдання 2: Перевірте маршрут клієнта до SMB-сервера (Linux-клієнт)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 via 10.20.1.1 dev eth0 src 10.20.1.55 uid 1000

Значення: Ваші пакети йдуть через 10.20.1.1 з джерела 10.20.1.55. Брандмауери оцінюватимуть цю вихідну IP, а не ваші відчуття.

Рішення: Якщо маршрут несподіваний (невірний інтерфейс, неправильний source), виправте маршрутизацію/політики VPN split-tunnel перед змінами брандмауера.

Завдання 3: Тест порту 445 з Windows (найшвидша правда)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.20.30.40 -Port 445 | Select-Object ComputerName,RemoteAddress,RemotePort,TcpTestSucceeded"
filesrv01
10.20.30.40
445
False

Значення: TCP-підключення до 445 не вдалося. Це не проблема дозволів SMB; це проблема мережевого шляху.

Рішення: Просувайтесь від клієнта до мережі: клієнтський брандмауер? мережевий ACL? серверний брандмауер? security group? Не витрачайте час на права шару файлів поки що.

Завдання 4: Тест порту 445 з Linux (те саме, менше слів)

cr0x@server:~$ nc -vz 10.20.30.40 445
nc: connect to 10.20.30.40 port 445 (tcp) failed: Connection timed out

Значення: Таймаут зазвичай означає drop (брандмауер/ACL) частіше, ніж reject. Reject повертається швидко з повідомленням «refused».

Рішення: Якщо таймаут — перевірте проміжні пристрої. Якщо «refused» — підтвердіть, що служба SMB слухає порт.

Завдання 5: Підтвердити, що сервер слухає 445 (Windows-сервер)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object -First 3 LocalAddress,LocalPort,OwningProcess"
0.0.0.0
445
4

Значення: Порт 445 слухає на всіх інтерфейсах. PID 4 — процес System у Windows, це нормально для SMB.

Рішення: Якщо нічого не слухає — переконайтеся, що сервіс «Server» запущено і встановлено функції SMB. Зміни брандмауера не допоможуть закритому порту.

Завдання 6: Підтвердити, що сервіс «Server» запущено (Windows-сервер)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service LanmanServer | Select-Object Status,Name,DisplayName"
Running
LanmanServer
Server

Значення: Сервіс SMB запущено.

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

Завдання 7: Перевірити активний профіль Windows Firewall (Windows-сервер)

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

Значення: Сервер вважає, що він у Public мережі. Багато правил «File and Printer Sharing» за замовчуванням відключені для Public.

Рішення: Виправте мережевий профіль (часто через відновлення зв’язку з доменом і правильне прив’язування NIC) або явно увімкніть SMB-правила для Public з суворою областю віддалених IP.

Завдання 8: Переглянути правила, пов’язані з SMB (Windows-сервер)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Select-Object DisplayName,Enabled,Profile,Direction | Format-Table -AutoSize"
File and Printer Sharing (SMB-In)                 True  Domain,Private  Inbound
File and Printer Sharing (NB-Session-In)          False Domain,Private  Inbound
File and Printer Sharing (NB-Name-In)             False Domain,Private  Inbound
File and Printer Sharing (NB-Datagram-In)         False Domain,Private  Inbound

Значення: SMB-In увімкнено, але лише для Domain/Private. Якщо сервер у Public — правило не застосовується.

Рішення: Або виправте профіль на Domain/Private, або увімкніть SMB-In на Public із вузькою областю віддалених адрес.

Завдання 9: Підтвердити область віддалених адрес правила (Windows-сервер)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
Any

Значення: Дозволяє з будь-якої віддаленої IP (в межах дозволених профілів). Це може бути неприйнятним, або може бути нормальним всередині довіреної VLAN.

Рішення: У продакшні звужуйте до відомих підмереж. «Any» — як ви опинитесь на аудиті з порожніми печивами.

Завдання 10: Тест SMB на рівні протоколу (Linux-клієнт)

cr0x@server:~$ smbclient -L //10.20.30.40 -U 'CORP\alice'
Password for [CORP\alice]:
Sharename       Type      Comment
---------       ----      -------
IPC$            IPC       Remote IPC
Shares          Disk
SMB1 disabled -- no workgroup available

Значення: З’єднання та автентифікація пройшли успішно. «SMB1 disabled» — це добра новина, а не проблема.

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

Завдання 11: Тест мапінгу SMB з Windows-клієнта (чіткість автентифікації)

cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use * \\10.20.30.40\Shares /user:CORP\alice'"
The command completed successfully.

Значення: Ви можете аутентифікуватися та змонтувати шар. Якщо Explorer все ще падає при зверненні за ім’ям — це проблеми резолювання імен або SPN/Kerberos нюанси.

Рішення: Якщо по IP працює, а по імені — ні, виправте DNS, SPN і відмовтесь від залежності NetBIOS/LLMNR.

Завдання 12: Перевірити поточні SMB-з’єднання (Windows-клієнт)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,Encrypted,SigningRequired | Format-Table -AutoSize"
10.20.30.40 Shares 3.1.1  2 False True

Значення: Ви домовилися про SMB 3.1.1; підпис вимаганий; шифрування вимкнено.

Рішення: Якщо бачите старий діалект або невдалий переговор — перевірте політики (клієнт/сервер) перед тим, як звинувачувати брандмауер.

Завдання 13: Підтвердити конфігурацію SMB-сервера Windows (Windows-сервер)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RejectUnencryptedAccess,RequireSecuritySignature"
False
True
True
True

Значення: SMB1 вимкнено; SMB2 увімкнено; незашифрований доступ відхиляється; підпис вимаганий.

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

Завдання 14: Визначити, чи серверний брандмауер скиджає трафік (захоплення пакетів на Windows-сервері)

cr0x@server:~$ powershell -NoProfile -Command "pktmon filter remove; pktmon filter add -p 445; pktmon start --etw -m real-time"
PktMon started.

Значення: Ви захоплюєте трафік порту 445 в реальному часі (на базі ETW). Тепер відтворіть спробу клієнта.

Рішення: Якщо SYN приходить, але немає SYN-ACK, або якщо йде RST — ви на серверній стороні брандмауера/сервісу. Якщо нічого не приходить — блокування вгору по ланцюгу.

Завдання 15: Перевірити правила брандмауера Linux (приклад nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
  }
}

Значення: За замовчуванням drop, дозволено лише SSH. SMB не проходитиме, поки ви не додасте TCP/445 (і можливо 139) з дозволених джерел.

Рішення: Додайте правило accept для SMB, обмеживши джерела потрібними підмережами, а не робіть blanket-allow.

Завдання 16: Переконатися, що SELinux не є несподіваним винуватцем (Linux Samba-сервер)

cr0x@server:~$ getenforce
Enforcing

Значення: SELinux у режимі Enforcing. Це нормально, але неправильні контексти можуть виглядати як «мережева проблема», коли демон не має доступу до файлової системи.

Рішення: Якщо з’єднання встановлюються, але доступ до шарів провалюється на Linux Samba, перевірте журнали audіt і контексти замість того, щоб без потреби чіпати брандмауер.

Три корпоративні міні-історії з поля бою

Міні-історія 1: Інцидент через хибне припущення

У тікеті було написано «Файловий сервер впав». Інженер на чергуванні зробив класичне: підключився по RDP до сервера, побачив здоровий робочий стіл, процесор спокійний, диск у нормі. Вони відповіли: «Сервер живий; це мусить бути проблема з правами». Ця відповідь принесла їм рівно п’ятнадцять хвилин спокою.

Потім служба підтримки почала кидати скріншоти: кожен користувач, кожна шара, кожен сайт. «Network path not found». Якщо ви бачили цю фразу у масштабі, ви майже відчуваєте проблему: не NTFS ACL, не GPO, не корумпований профіль. Це транспорт.

Виявилось, що хтось під час жорсткої політики безпеки затягнув вхідні правила на хості сервера. Вони увімкнули правило RDP для всіх профілів, бо «нам завжди потрібен RDP», але залишили «File and Printer Sharing (SMB-In)» лише для Domain і Private. Профіль NIC сервера переключився на Public після тимчасової втрати зв’язку з доменом під час завантаження.

Хибне припущення було тонким: «Якщо RDP працює, брандмауер в порядку». Ні. Брандмауер виконував свою роботу для одного порту. Вирішення — виправити причину профілю мережі (детекція домену) і явно звузити SMB-In до очікуваних підмереж для всіх релевантних профілів, щоб зміна профілю не опускала файловий доступ глобально.

Міні-історія 2: Оптимізація, що обернулась проти команди

Мережева команда захотіла зменшити ризик латерального руху. Хороша мета. Вони ввели новий набір політик: «дозволяти лише потрібні порти для кожного шару». Також правильно. Потім вони вирішили побавитись і мінімізували правила, дозволивши SMB лише з невеликої множини «jump hosts», припускаючи, що користувачі будуть заходити на шари через віддалені робочі столи.

Тиждень усе було спокійно. Менше відкритих портів. Чистіші діаграми. Потім фінанси закривали місяць, і пачки задач почали падати. Ці задачі не були інтерактивними користувачами, які могли б RDP до jump box. Це були сервери додатків, що тягнули звіти з SMB-шари під service-акаунтами. Оптимізація тихо зламала довготривалі міжмашинні робочі потоки.

Гірше: симптоми були шумні й оманливі: деякі задачі падали швидко, інші зависали. Деякі сервери мали кешовані з’єднання і терпляче працювали. Моніторинг показував файловий сервер «вгору», і всі сперечалися, чи це проблема продуктивності сховища.

Вирішення не в «відкрийте SMB скрізь». Вирішення — ідентифікувати легітимні підмережі клієнтів SMB (app tier, VDI, admin segment) і дозволити TCP/445 лише з цих джерел, з логуванням. Потім задокументувати залежність у процесі змін. Оптимізація не провалилась через те, що безпека погана; вона провалилась тому, що команда оптимізувала кількість портів замість відомих потоків трафіку.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Інша компанія мала звичку, яку я хотів би бачити повсюди: кожна зміна фаєрволу, що може вплинути на east-west трафік, вимагала «чекліст порт-проб» з принаймні двох репрезентативних клієнтських мереж. Не зустріч. Список команд з збереженими виводами.

Одної п’ятниці вони розгорнули новий Windows baseline policy. Воно торкнулось Windows Defender Firewall правил, включно з групою «File and Printer Sharing». На папері це було безпечно: лише звуження RemoteAddress і відключення застарілих NetBIOS-правок. Розумно у 2026.

Перед затвердженням інженер прогнав свій чекліст: Test-NetConnection до 445 з VDI-підмережі, з app-підмережі і з admin-підмережі. Одна підмережа впала. Причина була не в правилі — область правила використала неправильний CIDR для нещодавно розширеного діапазону VDI.

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

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

Виправлення по-правильному: правила Windows Firewall, що пройдуть аудит

Почніть з правильного мислення: «увімкнути і звузити», а не «вимкнути»

Вимикання Windows Defender Firewall, щоб «подивитися, чи працює», — це операційний еквівалент зняття гальм з авто, щоб знайти скрип. Так, щось зміниться. І тепер у вас новий інцидент.

Зробіть натомість так:

1. Переконайтеся, що сервер слухає 445 і сервіс Server запущено.
2. Підтвердіть, який профіль брандмауера активний.
3. Увімкніть правильне вхідне правило(а) для цього профілю.
4. Обмежте правило за віддаленими IP-діапазонами, що представляють легітимних клієнтів.
5. Увімкніть логування падінь тимчасово, якщо потрібні докази.

Увімкніть SMB-In з обмеженням віддаленої області (PowerShell)

Приклад: дозволити SMB лише з вашої VDI-підмережі та підмережі додатків.

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' -Enabled True"

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' -Profile Domain,Private,Public"

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' -RemoteAddress 10.20.0.0/16,10.50.10.0/24"

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

Операційна настанова: Застосування на Public прийнятне лише з суворою віддаленою областю. Якщо ви не можете звузити — виправте проблему з профілем.

Підтвердіть, що зміни правила справді застосовані

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' | Select-Object Enabled,Profile"
True
Domain, Private, Public

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
10.20.0.0/16, 10.50.10.0/24

Рішення: Якщо RemoteAddress все ще показує Any, ви модифікували не те правило (поширена помилка з локалізованими назвами) або GPO переадає налаштування.

Коли залучена групова політика (вона зазвичай залучена)

Якщо GPO контролює правила брандмауера, локальні правки — тимчасовий театр. Вам потрібно:

• Виявити джерело переможної політики.
• Виправити правило на рівні GPO.
• Підтвердити за допомогою gpresult і ефективних правил.

cr0x@server:~$ powershell -NoProfile -Command "gpresult /r | Select-String -Pattern 'Applied Group Policy Objects'"
Applied Group Policy Objects
-----------------------------
Default Domain Policy
Server Firewall Baseline

Значення: «Server Firewall Baseline» ймовірно накладає конфігурацію брандмауера.

Рішення: Редагуйте baseline GPO. Якщо ви зробили тимчасову правку локально, задокументуйте як тимчасове виключення і заплануйте виправлення в GPO, інакше воно відкотиться.

Увімкніть логування брандмауера (цілеспрямовано, тимчасово)

Коли потрібні докази, логування допомагає. Не лишайте його ввімкненим на високому рівні постійно, особливо на завантажених файлових серверах.

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallProfile -Profile Domain,Private,Public -LogAllowed True -LogBlocked True -LogFileName '%systemroot%\system32\LogFiles\Firewall\pfirewall.log' -LogMaxSizeKilobytes 16384"

cr0x@server:~$ powershell -NoProfile -Command "Get-Content $env:systemroot\system32\LogFiles\Firewall\pfirewall.log -Tail 5"
2026-02-05 10:14:33 DROP TCP 10.20.1.55 10.20.30.40 51834 445 ...

Значення: Drops підтверджують участь брандмауера; вихідна IP підкаже, яку підмережу потрібно включити в область дозволу.

Рішення: Якщо ви бачите дропи від легітимних джерел — оновіть RemoteAddress або upstream ACLs. Якщо дропи від «нелогічних» джерел — брандмауер працює правильно; лишіть як є.

Не «виправляйте» SMB випадково, увімкнувши NetBIOS

Якщо ви ввімкнете UDP/137-138 і TCP/139, щоб зробити мережеве оглядання робочим, ви можете приховати проблему DNS. Також ви розширюєте поверхню атаки і повертаєте широкомовлення в мережі, де цього не повинно бути.

Краще: надійний DNS, direct hosting SMB через 445 та явні UNC-шляхи.

Виправлення по-правильному: правила брандмауера Linux (nftables/iptables/ufw/firewalld)

Linux SMB-сервери зазвичай — Samba. Linux-клієнти SMB — зазвичай cifs-utils, smbclient або бібліотеки додатків. Принципи брандмауера ті самі: дозволяйте TCP/445 з потрібних джерел, підтримуйте stateful-правила і не відкривайте світ лише тому, що хтось накричав у Slack.

nftables: дозволити SMB з конкретних підмереж

Приклад припускає table inet filter з chain input і політикою drop.

cr0x@server:~$ sudo nft add rule inet filter input ip saddr 10.20.0.0/16 tcp dport 445 ct state new accept

cr0x@server:~$ sudo nft add rule inet filter input ip saddr 10.50.10.0/24 tcp dport 445 ct state new accept

cr0x@server:~$ sudo nft list chain inet filter input
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    ip saddr 10.20.0.0/16 tcp dport 445 ct state new accept
    ip saddr 10.50.10.0/24 tcp dport 445 ct state new accept
  }
}

Значення: Нові SMB-з’єднання приймаються лише з дозволених мереж. Встановлені з’єднання дозволені першим правилом.

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

iptables (legacy): той самий принцип, але з менш приємним синтаксисом

cr0x@server:~$ sudo iptables -A INPUT -p tcp -s 10.20.0.0/16 --dport 445 -m conntrack --ctstate NEW -j ACCEPT

cr0x@server:~$ sudo iptables -S INPUT | sed -n '1,40p'
-P INPUT DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -s 10.20.0.0/16 -m tcp --dport 445 -m conntrack --ctstate NEW -j ACCEPT

Значення: За замовчуванням drop з явним дозволом. Це нормально, якщо ви також дозволили трафік у відповідь (RELATED,ESTABLISHED).

Рішення: Якщо ви забули RELATED,ESTABLISHED, отримаєте дивну односпрямовану поведінку, що виглядає як «SMB неконсистентний». Виправте це першочергово.

ufw: швидко і читабельно (коли можна його використовувати)

cr0x@server:~$ sudo ufw allow from 10.20.0.0/16 to any port 445 proto tcp
Rule added

cr0x@server:~$ sudo ufw status verbose
Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)
To                         Action      From
445/tcp                    ALLOW IN    10.20.0.0/16
22/tcp                     ALLOW IN    Anywhere

Значення: SMB дозволено лише з тієї підмережі.

Рішення: Якщо потрібно кілька підмереж — додайте їх явно. Не робіть ufw allow 445/tcp, якщо не маєте на увазі «з будь-якої адреси».

firewalld (RHEL-подібні): використовуйте сервіси, коли це доцільно, порти — коли потрібна точність

cr0x@server:~$ sudo firewall-cmd --get-active-zones
public
  interfaces: eth0

cr0x@server:~$ sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="10.20.0.0/16" port protocol="tcp" port="445" accept' --permanent
success

cr0x@server:~$ sudo firewall-cmd --reload
success

cr0x@server:~$ sudo firewall-cmd --zone=public --list-rich-rules
rule family="ipv4" source address="10.20.0.0/16" port port="445" protocol="tcp" accept

Значення: Обмежений allow у активній зоні.

Рішення: Якщо ви додали правило в неправильну зону — нічого не зміниться. Завжди перевіряйте активні зони/інтерфейси перед додаванням правил.

Мережа, яку ви забули: NAT, VPN, проксі, IDS і «корисні» middlebox-и

Чому SMB чутливий до дивакуватостей шляху

SMB станозалежний і очікує стабільні сесії. Додайте VPN, агресивний IDS або брандмауер, що робить TCP-нормалізацію, і отримаєте збої, що виглядають випадковими: перервані підключення, «The specified network name is no longer available», або монтинги, що зависають під навантаженням.

NAT і SMB: можливо, але часто погана ідея

SMB через NAT може працювати на TCP-рівні, але часто блокується політикою. Більша проблема — операційна: коли багато клієнтів виглядають з одного NAT-IP, ваша серверна фаєрвол-область і аудит втрачають смисл. Автентифікація може і працювати, але розслідування інцидентів стає інтерпретативним танцем.

VPN split tunneling: тихе розривання

Частий патерн:

• RDP працює, бо його примусово передають через VPN (або дозволяють через інтернет шлюз).
• SMB не працює, бо split tunneling маршрути 445 прямо в інтернет, де він заблокований (що й правильно), або до іншого egress, де немає потрібних ACL.

Виправте політики split tunneling або публікуйте доступ до файлів через погоджений механізм. Не сперечайтесь з мережею, «просто відкривши 445 зовні». Цей шлях закінчується звітом про інцидент.

IDS/IPS і інспекція SMB

Деякі апаратні або віртуальні пристрої інспектують SMB і можуть термінувати сесії при виявленні політик або аномалій. Це може проявлятись як:

• З’єднання встановилось, а потім миттєвий reset під час переговорів.
• Копіювання великих файлів падає при певних розмірах (ліміти буфера інспекції).
• SMB3 шифрування руйнує припущення видимості і викликає дивні блокування.

Якщо підозрюєте це, зробіть захоплення пакетів по обидва боки апарата і порівняйте. Не гадуйте.

MTU і фрагментація: «працює для маленьких файлів»

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

cr0x@server:~$ ping -c 3 -M do -s 1372 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1372(1400) bytes of data.
1372 bytes from 10.20.30.40: icmp_seq=1 ttl=125 time=12.3 ms
1372 bytes from 10.20.30.40: icmp_seq=2 ttl=125 time=12.1 ms
1372 bytes from 10.20.30.40: icmp_seq=3 ttl=125 time=12.2 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Значення: Шлях підтримує пакети розміром 1400 байт без фрагментації. Якщо це падає — налаштуйте MTU на тунелях/інтерфейсах або дозвольте необхідні ICMP для PMTUD.

Рішення: Якщо PMTUD зламано — ви назавжди гнатиметесь за «нестабільним SMB». Виправте шлях.

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

1) Cимптом: RDP працює, SMB таймаутить (без підказок, просто крутить)

Корінна причина: TCP/445 відкидається брандмауером/ACL/секьюріті групою, часто тому, що дозволено лише RDP (3389).

Виправлення: Дозвольте вхідний TCP/445 до файлового сервера з погоджених підмереж. Перевірте за допомогою Test-NetConnection -Port 445 або nc. Звужуйте область.

2) Cимптом: SMB падає тільки за іменем; по IP працює

Корінна причина: Невідповідний DNS suffix/search order, застарілий DNS-запис або резолювання через NetBIOS/LLMNR, яке не проходить через маршрутизатори/VPN.

Виправлення: Виправте DNS-записи і налаштування клієнта. Віддавайте перевагу FQDN. Відключіть залежність від широкомовних механізмів між сегментами.

3) Cимптом: «Access denied» миттєво

Корінна причина: Права share/NTFS або користувач потрапляє на інший сервер через DFS/аліас; іноді кешовані облікові дані мапляться на неправильний акаунт.

Виправлення: Підтвердіть, що ви на очікуваному сервері, потім перевірте дозволи share + NTFS ACL; очистіть кешовані SMB-сесії (net use * /delete).

4) Cимптом: «The specified network name is no longer available» під час копіювання файлу

Корінна причина: Middlebox скиджає з’єднання, idle timeout, проблеми MTU/PMTUD або невідповідність підпису/шифрування SMB в певних операціях.

Виправлення: Захоплення пакетів; перевірка політик VPN/IDS; валідація MTU; підтвердження узгоджених SMB-політик між клієнтом і сервером.

5) Cимптом: Працює з однієї підмережі, падає з іншої

Корінна причина: Область віддалених адрес правила занадто вузька, відсутні маршрути або асиметрична маршрутизація, що викликає drop через stateful-пристрої.

Виправлення: Порівняйте вихідну IP і шлях. Розширте область правила до правильних підмереж. Виправте симетрію маршрутів або розміщення stateful-пристроїв.

6) Cимптом: Windows-сервер несподівано показує Public профіль

Корінна причина: Детекція домену не працює (DNS/DC недоступні), проблеми з чергою NIC/зв’язками або кілька NIC з різними категоріями мережі.

Виправлення: Відновіть доступ до DC/DNS; переконайтеся, що правильний NIC використовується для домену; застосуйте правила брандмауера, які не залежать лише від профілю (але зі строгою областю RemoteAddress).

7) Cимптом: Linux CIFS mount зависає, але ping працює

Корінна причина: Порт 445 заблоковано або переговори SMB/автентифікація не проходять; ping — це ICMP і мало що каже про доступність SMB.

Виправлення: Тестуйте з nc -vz host 445 і smbclient. Потім налаштовуйте брандмауер або опції автентифікації.

8) Cимптом: Ви відкрили 445, але доменні користувачі все одно не підключаються

Корінна причина: Блоковано шлях автентифікації: сервер не може дістатися контролерів домену для Kerberos/LDAP/DNS з цієї інтерфейсу/підмережі.

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

Чеклісти / покроковий план

Покроково: коли RDP працює, але файловий шар ні

1. Підтвердьте ідентичність: Переконайтеся, що ім’я, до якого ви звертаєтесь, резольвиться в той самий IP, до якого ви підключались по RDP.
2. Протестуйте транспорт: З клієнтської мережі протестуйте TCP/445 до IP сервера.
3. Підтвердіть сервіс: На сервері підтвердіть, що порт 445 слухає і сервіс SMB запущено.
4. Підтвердіть профіль і збіг правила: На Windows перевірте активний профіль брандмауера і переконайтеся, що SMB-In правило увімкнено для нього.
5. Звузьте дозвіл: Встановіть RemoteAddress на погоджені клієнтські підмережі. Уникайте «Any», якщо сервер не за межами довіреної мережі.
6. Повторно протестуйте порт 445: Якщо тепер доступний — тестуйте листинг/мапінг SMB.
7. Тестуйте автентифікацію SMB явно: Використовуйте net use або smbclient -L, щоб відокремити помилки автентифікації від мережевих.
8. Перевірте доступ до DC (у доменних середовищах): Якщо автентифікація падає, протестуйте DNS/Kerberos/LDAP від сервера до DC.
9. Лише тоді: Виправляйте права share і NTFS ACL, бо тепер ви на правильному шарі.
10. Захоплення пакетів: Якщо поведінка нестабільна, робіть capture, особливо при reset/timeout під час передачі.

Чекліст: якість правила брандмауера («щоб не було соромно на аудиті»)

• Правило має зрозумілу назву та мету («Allow SMB from VDI subnets»).
• Вхідний allow звузжений за RemoteAddress (або еквівалентним source CIDR).
• Відкриті лише потрібні порти (зазвичай TCP/445; додавайте 139/137/138 лише з обґрунтуванням).
• Логування ввімкнене тимчасово під час rollout або діагностики, потім знижене.
• Правила застосовуються через вашу реальну систему конфігурації (GPO, Ansible, DSC), а не через «кліки народних знань».
• Тестові кейси охоплюють щонайменше дві реальні клієнтські мережі (VDI + app subnet, або офіс + VPN).
• План відкату існує (відновлення попереднього набору правил) і протестований в непро- середовищі.

Чекліст: коли треба відкрити SMB між сегментами

• Підтвердіть, що сегмент довірений і моніториться.
• Використовуйте найменші привілеї: лише файлові сервери, лише TCP/445, лише з конкретних джерел.
• Віддавайте перевагу SMB3 з підписом (і шифруванням, коли потрібно).
• Майте детекцію: логи відмов та алерти на сканування.
• Задокументуйте залежність (які додатки, які підмережі, хто відповідальний).

FAQ

1) Якщо RDP працює, хіба це не означає, що брандмауер пропускає трафік?

Це означає, що брандмауер пропускає одну річ: TCP/3389 (або порт, який використовує ваш RDP-шлюз). SMB — це TCP/445 і часто інша група правил, профілів та областей.

2) Який єдиний порт потрібен для Windows file sharing?

Зазвичай TCP/445. Якщо маєте справу зі спадковими NetBIOS-сценаріями, можливо також TCP/139 і UDP/137-138, але розглядайте їх як винятки, які треба обґрунтувати, а не як дефолт.

3) Чому працює по IP, але не за ім’ям?

Через резолювання імен. SMB може використовувати інший шлях резолювання, ніж ваш RDP-клієнт. Виправте DNS, використовуйте FQDN, і припиніть покладатися на NetBIOS-широкомовлення через маршрутизовані мережі.

4) Чи слід увімкнути «File and Printer Sharing» на Public профілі?

Лише якщо ви також звузите віддалені адреси правила до відомих, довірених підмереж. «Public + Any» — знайдеться в аудиторському звіті й безпечні печива не допоможуть.

5) Я відкрив 445 на сервері, але клієнти все одно не підключаються. Що робити?

Доведіть, де блокується трафік. Якщо сервер не бачить SYN — блокування upstream (мережевий ACL, security group, маршрутизація). Якщо сервер бачить SYN, але не відповідає — локальний брандмауер або прив’язка сервісу.

6) Чи може антивірус або endpoint security блокувати SMB, навіть якщо брандмауер дозволяє?

Так. Деякі EPP/EDR рішення містять мережеву інспекцію або правила «network attack surface reduction», які можуть блокувати або заважати SMB. Тестуйте з packet capture і перевіряйте логи продукту.

7) Чому я бачу «SMB1 disabled» і чи варто хвилюватися?

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

8) Чи треба відкривати порти до контролерів домену, щоб SMB працював?

Не завжди, але часто. Доменно-автентифікований доступ до SMB покладається на Kerberos/LDAP/DNS. Якщо файловий сервер не може дістатися DC з цієї мережі, ви отримаєте помилки автентифікації, навіть якщо TCP/445 відкритий.

9) Який найдорожчий спосіб дозволити SMB для віддалених користувачів?

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

10) Мій Linux CIFS mount не вдається, а Windows-клієнти працюють. Це фаєрвол?

Іноді. Частіше це нюанси діалекту SMB/підпису/шифрування або форматування облікових даних. Спочатку перевірте TCP/445 з Linux-хосту, потім протестуйте smbclient, потім змініть опції монтування.

Наступні кроки, які можна зробити сьогодні

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

Зробіть наступне:

1. З клієнтської мережі, де виникає проблема, протестуйте TCP/445 до IP сервера. Якщо не пройшло — немає SMB.
2. На сервері підтвердіть, що порт 445 слухає і сервіс SMB запущено.
3. Перевірте профіль Windows Firewall і ефективне правило «File and Printer Sharing (SMB-In)». Увімкніть його, де потрібно, і звузьте RemoteAddress до реальних клієнтських підмереж.
4. Якщо по IP працює, а по імені ні — виправте DNS. Не відроджуйте NetBIOS як коврик для несправностей.
5. Якщо транспорт працює, а автентифікація падає — переконайтеся, що сервер може дістатися контролерів домену (DNS/Kerberos/LDAP) з цього інтерфейсу.
6. Запишіть остаточну зміну правила у вашу систему конфігурації (GPO/DSC/Ansible) і додайте простий порт-пробний тест у чекліст змін.

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