SMB1 проти SMB2/3: що вимкнути (і чому це важливо)

Коротко: що вимкнути

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

Рекомендації

• Вимкніть серверну підтримку SMB1 на Windows-серверах та на пристроях Samba.
• Вимкніть клієнт SMB1 на робочих станціях/VDI Windows, якщо немає задокументованого тимчасового винятку.
• Дозволяйте SMB2 і SMB3 (включно з SMB 3.1.1) і впроваджуйте розумні заходи безпеки: підписування там, де потрібно, шифрування лише там, де воно обґрунтоване.
• Відстежуйте останніх власників SMB1 (сканери, старі копіри, вбудовані пристрої) і плануйте їхнє виведення як будь-який інший ризик.

Пряма думка з операційної практики

Єдиною дійсною причиною залишати SMB1 увімкненим є: «ми прийняли ризик, ізольовано його, ведемо логування і маємо дату видалення».
Все інше — це лише відкладення проблеми з підключеним мережевим кабелем.

Жарт №1: SMB1 — це як залишати сітчасті двері на підводному човні, бо ваш дідусь любив «свіже повітря».

Кілька фактів і історія, що мають значення

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

1. SMB1 передує сучасним моделям загроз. Його корені сягають мереж IBM PC і ранніх реалізацій Microsoft LAN Manager.
2. SMB2 з’явився з Windows Vista/Server 2008. Це був не «дрібний апдейт», а переробка, що зменшувала балакучість і покращувала продуктивність.
3. SMB3 запущено з Windows 8/Server 2012. Він приніс можливості для дата-центрів: шифрування, multichannel і SMB Direct (RDMA).
4. Поширенню WannaCry сприяло відкриття SMB1. Після цього «вимкнути SMB1» перестало бути рекомендацією і стало мінімальною гігієною.
5. SMB 3.1.1 покращив механізми пренавігаційної цілісності. Це ускладнило трюки зі зниження версії/mitm-атаки.
6. Підписування SMB існувало раніше, але стало важливішим. Його часто вимагають з міркувань безпеки, і воно може стати вузьким місцем на слабких CPU.
7. SMB — це станова служба і чутлива до затримок. Невелике RTT — нормально; а ось джиттер і втрата пакетів роблять його нещадним.
8. «Діалекти» SMB узгоджуються для кожного з’єднання окремо. Ви можете вимкнути SMB1 і все одно побачити падіння у клієнтів, які не можуть домовитися про SMB2+.
9. Samba — не «Windows SMB», але розуміє ту саму мову. Samba підтримує можливості SMB3 залежно від версії, опцій збірки та підтримки ядра.

SMB1 vs SMB2 vs SMB3: що насправді змінилося

SMB1: багатослівний, крихкий і надто довірливий

SMB1 — це старий світ. Він часто виконує багато дрібних операцій запит/відповідь. Це означає більше кругових поїздок, а отже — більша чутливість до затримок.
Також це дає більше можливостей для посередників заважати і більше шансів на виявлення рідкісних багів.

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

SMB2: менше кругових поїздок, краща семантика

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

Операційно SMB2+ також покращує можливості для спостереження. Часто можна чіткіше запитати погоджений діалект, стан підписування та деталі сесії,
що перетворює «все повільно» на те, що можна виміряти.

SMB3: безпека та можливості для дата-центрів (із гострими краями)

SMB3 додає функції, які хочеться мати у сучасному середовищі: шифрування (на шар або сесію), multichannel (кілька шляхів мережі на сесію),
і SMB Direct (RDMA) у світі Windows/HCI.

Але можливості SMB3 також породжують нові режими відмов:
multichannel може виявити асиметричну маршрутизацію, проблеми з NIC offload або неправильні налаштування комутаторів;
шифрування може стати вузьким місцем CPU;
вимоги підписування можуть перетворити старий NAS на обігрівач, що ще й обслуговує файли.

Цитата

«перефразована ідея» — Werner Vogels: надійність будують, передбачаючи відмови й проєктуючи під них, а не сподіваючись, що все піде по щасливому шляху.

Що вимкнути (і що залишити)

Вимкніть підтримку протоколу SMB1

SMB1 слід вимкнути на серверах і клієнтах. Крапка. Тут деякі скажуть «але копір…».
Добре. Помістіть копір у карантинний VLAN, надайте йому виділений шар із суворими ACL і заплануйте заміну.
Не залишайте SMB1 для всієї інфраструктури через один вбудований пристрій 2009 року.

Залишайте SMB2 і SMB3, але обдумано ставте підписування та шифрування

Підписування SMB допомагає запобігти підміні та деяким атакам на передавання облікових даних. Але підписування коштує CPU.
На сучасних серверах зазвичай це непомітно; на старих NAS або перевантажених віртуальних машинах воно може бути різницею між «швидко» і «чому все 12 МБ/с?»

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

Вимкніть застарілу автентифікацію, де можна

SMB1 часто притягує старі способи автентифікації. Якщо ви й досі дозволяєте NTLMv1 або LM у 2026 році, ви не «сумісні»; ви запрошуєте зловживання обліковими даними.
Рухайтеся в бік Kerberos і сучасної політики NTLM, і тримайте гостьовий доступ вимкненим, якщо любите реагувати на інциденти.

Жарт №2: «Тимчасовий виняток для SMB1» — це ІТ-еквівалент «я з’їм лише одне печиво».

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

Це реальні завдання, які можна виконувати у продуктивному середовищі з мінімальною драмою. Кожне включає, що значить вивід і як приймати рішення.
Комбінуйте залежно від того, чи ви керуєте Windows-серверами, Samba або NAS.

Завдання 1: Перевірити узгоджений діалект і можливості (Windows-клієнт)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,SigningRequired,Encrypted | Format-Table -Auto"
ServerName ShareName Dialect NumOpens SigningRequired Encrypted
---------- --------- ------ -------- ---------------- ---------
NAS01      data      3.1.1  24       True             False
FS01       profiles  3.0    6        True             True

Значення: Dialect показує, що фактично узгоджено. Якщо ви бачите 1.5 або «1.0» (SMB1), маєте прогалину в політиці.
Рішення: Якщо з’являється SMB1 — ідентифікуйте пару клієнт/сервер і вимкніть SMB1 там, де доречно. Якщо шифрування увімкнено несподівано — очікуйте вплив на CPU.

Завдання 2: Підтвердити, що SMB1-сервер вимкнено (Windows Server)

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

Значення: Це ефективні налаштування серверного SMB.
Рішення: Якщо EnableSMB1Protocol — True, вимкніть його в вікні змін і стежте за скаргами на застарілі пристрої (потім виправте їх).

Завдання 3: Вимкнути SMB1-сервер (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force"

Значення: Підтримка SMB1 на сервері вимкнена.
Рішення: Перезапуск заплануйте лише якщо це потрібно за збіркою ОС/політикою; перевірте, що нові підключення узгоджують SMB2/3; дивіться журнали подій на предмет невдалих переговорів.

Завдання 4: Перевірити, чи інстальовано клієнтську функцію SMB1 (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Select-Object FeatureName,State"
FeatureName  State
-----------  -----
SMB1Protocol Enabled

Значення: Клієнтські компоненти SMB1 присутні.
Рішення: Вимкніть/видаліть SMB1 на клієнтах, якщо немає ізольованого винятку. Це зменшить випадкові відкатні підключення і поверхню атаки.

Завдання 5: Видалити клієнтську функцію SMB1 (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart"
Path          :
Online        : True
RestartNeeded : True

Значення: Видалення компонента заплановано; потрібен перезапуск.
Рішення: Узгодьте з управлінням кінцевими точками час перезавантаження. Після перезавантаження перевірте доступ до шарів і відсутність діалекту SMB1.

Завдання 6: Ідентифікувати SMB-сесії та діалекти (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbSession | Select-Object ClientComputerName,ClientUserName,Dialect,NumOpens | Sort-Object Dialect | Format-Table -Auto"
ClientComputerName ClientUserName     Dialect NumOpens
------------------ --------------     ------ --------
WS043              CORP\j.singh       3.1.1  18
WS019              CORP\finance.svc   3.0    4

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

Завдання 7: Samba: перевірити мінімальний/максимальний протокол

cr0x@server:~$ testparm -s 2>/dev/null | egrep -i "server min protocol|server max protocol|client min protocol|client max protocol"
server min protocol = SMB2_02
server max protocol = SMB3_11
client min protocol = SMB2_02
client max protocol = SMB3_11

Значення: Samba не буде домовлятися нижче SMB2_02 і може переговорювати до SMB3_11.
Рішення: Якщо бачите NT1 (SMB1) — підніміть мінімум. Якщо макс занадто низький — оновіть Samba або налаштування, щоб дозволити SMB3.

Завдання 8: Samba: переглянути підключених клієнтів і узгоджений діалект

cr0x@server:~$ smbstatus -S
Service      pid     Machine       Connected at                     Encryption   Signing
------------------------------------------------------------------------------------------
data         1842    10.40.12.77    Tue Feb  5 09:21:44 2026 UTC    -            SMB2
profiles     1920    10.40.10.31    Tue Feb  5 09:24:11 2026 UTC    AES-128-GCM  SMB3_11

Значення: Samba показує стан підписування/шифрування для кожної сесії (залежить від версії).
Рішення: Якщо на важкому шарі несподівано з’явилося шифрування — виміряйте CPU. Якщо підписування показує SMB2, а ви очікуєте SMB3_11 — можлива проблема зі здібностями клієнта або політикою.

Завдання 9: Samba: встановити мінімальний протокол SMB2 (вимкнути SMB1) і перезавантажити

cr0x@server:~$ sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
cr0x@server:~$ sudo bash -lc 'printf "\n[global]\n   server min protocol = SMB2_02\n   server max protocol = SMB3_11\n" >> /etc/samba/smb.conf'
cr0x@server:~$ sudo systemctl reload smbd

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

Завдання 10: Перевірити журнали Samba на помилки переговорів діалекту

cr0x@server:~$ sudo journalctl -u smbd --since "1 hour ago" | egrep -i "protocol|SMB1|NT1|negotiate|reject" | tail -n 20
Feb 05 09:44:10 nas01 smbd[2112]: negotiate_protocol: No compatible protocol. Client offered: NT1
Feb 05 09:44:10 nas01 smbd[2112]: Failed to negotiate protocol with client 10.40.50.19

Значення: Клієнт намагається використовувати SMB1 (NT1) і він відхиляється.
Рішення: Ідентифікуйте пристрій за IP і вирішіть: оновити прошивку, замінити пристрій або ізолювати його за допомогою шлюзу для застарілих пристроїв з суворими контролями.

Завдання 11: Перевірити, чи ввімкнено шифрування SMB на Windows-шарі

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare -Name data | Select-Object Name,EncryptData,CachingMode | Format-List"
Name        : data
EncryptData : False
CachingMode : Manual

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

Завдання 12: Увімкнути шифрування SMB на конкретному Windows-шарі (цільовий, не загальний)

cr0x@server:~$ powershell -NoProfile -Command "Set-SmbShare -Name data -EncryptData $true"

Значення: Клієнти повинні використовувати шифрування SMB3 для доступу до цього шару.
Рішення: Розгортайте по шарах, а не глобально. Перевірте підтримку ОС-клієнтів і стежте за CPU та пропускною здатністю сервера після вмикання.

Завдання 13: Перевірити вимоги підписування на Windows Server

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EnableSecuritySignature | Format-List"
RequireSecuritySignature : True
EnableSecuritySignature  : True

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

Завдання 14: Linux-клієнт: показати узгоджений діалект SMB для змонтованого шару

cr0x@server:~$ mount | grep -i cifs
//nas01/data on /mnt/data type cifs (rw,relatime,vers=3.1.1,sec=krb5,cache=strict,username=CORP\\j.singh,uid=1000,gid=1000)

Значення: Linux-клієнт використовує SMB 3.1.1. Добре.
Рішення: Якщо ви бачите vers=1.0 або vers=2.0 несподівано — налаштуйте опції mount і переконайтеся, що сервер підтримує новіші діалекти.

Завдання 15: Linux-клієнт: примусити SMB3 і швидко провалюватися, якщо сервер не підтримує

cr0x@server:~$ sudo mount -t cifs //nas01/data /mnt/data -o vers=3.1.1,sec=krb5,seal,username=CORP\\j.singh
mount error(95): Operation not supported

Значення: Сервер або стек клієнта не підтримує запитаний набір можливостей (тут: SMB3.1.1 + шифрування).
Рішення: Вирішіть, чи оновлювати Samba/ядро, підлаштуватися під підтримуваний діалект або перенести навантаження. Не «виправляйте» це шляхом увімкнення SMB1.

Завдання 16: Перевірка мережевої реальності з клієнта (підказки про затримки та втрати)

cr0x@server:~$ ping -c 5 nas01
PING nas01 (10.40.10.20) 56(84) bytes of data.
64 bytes from 10.40.10.20: icmp_seq=1 ttl=63 time=1.12 ms
64 bytes from 10.40.10.20: icmp_seq=2 ttl=63 time=12.9 ms
64 bytes from 10.40.10.20: icmp_seq=3 ttl=63 time=1.05 ms
64 bytes from 10.40.10.20: icmp_seq=4 ttl=63 time=1.09 ms
64 bytes from 10.40.10.20: icmp_seq=5 ttl=63 time=1.08 ms

--- nas01 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 1.05/3.45/12.9/4.73 ms

Значення: Втрат пакетів немає, але джиттер підскакує до 12.9 ms.
Рішення: SMB не любить джиттер. Перевірте перевантаження, NIC offloads, погане Wi‑Fi або перевантажені віртуальні комутатори, перш ніж звинувачувати «NAS».

Завдання 17: Швидка перевірка пропускної здатності (підозра: мережа чи сховище)

cr0x@server:~$ dd if=/dev/zero of=/mnt/data/smb-test.bin bs=16M count=64 conv=fdatasync status=progress
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.4 s, 58.4 MB/s
17179869184 bytes (17 GB, 16 GiB) copied, 292 s, 58.8 MB/s
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.4 s, 58.4 MB/s

Значення: Записи ≈58 MB/s. На здоровому 1 GbE-каналі для послідовних записів можна очікувати близько ~90–110 MB/s з урахуванням накладних витрат і шифрування/підписування.
Рішення: Якщо це значно нижче очікувань посилу, перевірте CPU клієнта (шифрування/підписування), узгодження NIC і затримку диска на сервері. Якщо це близько до очікуваного — дивіться на шаблони дрібних I/O в додатках.

Завдання 18: Windows: перевірити швидкість/дуплекс NIC (так, це досі кусається)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,Status,LinkSpeed | Format-Table -Auto"
Name        Status LinkSpeed
----        ------ ---------
Ethernet0   Up     1 Gbps
Ethernet1   Up     100 Mbps

Значення: Один інтерфейс працює на 100 Mbps. Це не «трохи повільніше», це інша епоха.
Рішення: Виправте кабелі/порт комутатора/автонег. Якщо увімкнено SMB multichannel, повільний NIC може тягнути продуктивність або викликати дивну поведінку залежно від політики.

Швидкий план діагностики

Проблеми SMB рідко «тільки SMB». Зазвичай це одне з чотирьох: невідповідність переговорів/політик, якість мережі, CPU сервера (криптографія/підписування)
або затримка диска. Трюк — знайти, що саме за хвилини, а не години.

Перше: підтвердьте діалект і режим безпеки

• На Windows-клієнті: Get-SmbConnection і перевірте Dialect, SigningRequired, Encrypted.
• На Windows-сервері: Get-SmbSession для перегляду діалектів клієнтів.
• На Samba: smbstatus -S (діалект/підписування/шифрування залежать від версії).

Якщо щось домовляється SMB1 — припиніть діагностику продуктивності. Ви маєте справу з порушенням політики. Виправте це спочатку.

Друге: вирішіть, що пахне мережею, CPU чи диском

• Мережа: джиттер у ping, втрата пакетів, Wi‑Fi-клієнти, VPN-шляхи, асиметрична маршрутизація, ECMP-проблеми.
• CPU: продуктивність падає лише при шифруванні/підписуванні; CPU сервера зростає під час копіювання файлів.
• Диск: SMB нормально для одного клієнта, але падає при багатьох; стрибки затримки сховища; робочі навантаження з великою кількістю метаданих повільні.

Третє: вимірюйте по одному параметру

1. RTT/jitter клієнт→сервер: короткий ping для підказки, потім системні інструменти для глибшої перевірки.
2. Одиночний потік пропускної здатності: контрольний запис/читання для ізоляції грубих обмежень.
3. Поведінка при паралелізмі: SMB2/3 використовує кредити; проблеми часто проявляються при паралельних операціях.
4. CPU проти затримки диска: спостерігайте одночасно CPU сервера і затримку сховища під час тесту.

Практичне правило для тріажу

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

Три корпоративні історії з практики

Історія 1: Інцидент через неправильне припущення

Середня компанія мала «виріз для спадщини» для кількох виробничих пристроїв. Припущення було простим: ці пристрої в своєму VLAN,
тож дозволити SMB1 «тільки для тієї мережі» безпечно. Команда файлів увімкнула SMB1 на центральному Windows-файловому сервері, бо це було простіше, ніж робити виділений шлюз.

Через кілька місяців пов’язаний проєкт тимчасово підключив тестову робочу станцію до виробничого VLAN для діагностики. Робоча станція була в домені, недопатчена і мала широкий east-west доступ, про який ніхто не згадав. Вона підчепила шкідливе ПЗ через звичайний візит на сайт.

Шкідливе ПЗ не вимагало генія; йому вистачило доступу.
SMB1 був доступний. Файловий сервер мав шари з надмірно дозволеними ACL через «так завжди було». Атака рухалася латерально й почала шифрувати спільні папки.
Команда спершу ганялася за правами і завданнями резервного копіювання, бо не хотіла вірити, що витік VLAN важливий.

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

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

Інша організація масово ввімкнула шифрування SMB, бо аудит вказав на «незашифровані файлообміни». Команда сховища швидко виконала: вмикнути шифрування на всіх шарах.
Це пройшло аудит. Воно також тихо змінило фізику системи.

Через два тижні служба підтримки отримала скарги «мережевий диск повільний». Потім VDI-команда поскаржилася: часи входу збільшилися, профілі користувачів тайм-аутяться,
і звинувачення перекидалося між мережею, сховищем і «Windows».

Справжня причина була приземленою: файлові сервери були віртуалками з обмеженим CPU. Шифрування штовхнуло їх у CPU-контенцію під піковим навантаженням.
SMB не зламався; він сповільнився. Це гірше, бо виглядає як «майже працює», тоді як продуктивність бізнесу страждає.

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

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

Глобальна компанія мала політику: перед депрецяцією протоколу вони 30 днів інвентаризують реальне використання, потім блокують із логуванням,
потім видаляють опцію. Це не гламурно. Це те, над чим сміються, поки не врятує вашу інфраструктуру.

Коли вони бралися знімати SMB1, вони не почали з глобального вимкнення. Спершу ввімкнули логування на крайніх пристроях і на файлових серверах,
збираючи, які клієнти намагаються вести переговори SMB1. Виявилося кілька пристроїв: сканер на складі, старий багатофункціональний принтер
і забутий Linux-бокс, що монтував шари з vers=1.0.

Вони виправили опції mount на Linux, оновили прошивки де можливо, а для сканера на складі побудували виділений ізольований шлях.
Потім вони вимкнули SMB1 масово і спостерігали журнали. Нічого критичного. Жодних несподіваних відмов. Ніякої «термінової виключної згоди» від керівництва.

Через два місяці пен-тест спробував трюки на основі SMB1 по внутрішніх сегментах. Нічого не слухало. Звіт був коротким.
Команда зробила нудну роботу — і нудна робота це і є надійність у вдалий день.

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

1) «Ми вимкнули SMB1, але десь він все одно домовляється»

Симптом: Ви все ще бачите SMB1/NT1 у журналах або сесіях.

Корінна причина: Вимкнено на одному сервері, але інші сервери досі дозволяють; або клієнт має встановлену функцію SMB1 і підключається до старого NAS, що лише говорить SMB1.

Виправлення: Інвентаризуйте узгоджені діалекти за допомогою Get-SmbSession/Get-SmbConnection або smbstatus.
Вимкніть SMB1 з обох боків. Замініть або ізолюйте пристрій, що лише підтримує SMB1.

2) «Копіювання файлів повільні після вмикнення шифрування»

Симптом: Пропускна здатність падає; CPU на файловому сервері підіймається; користувачі скаржаться в пікові години.

Корінна причина: Шифрування SMB3 вимогливе до CPU; для віртуальних машин або NAS з малою кількістю ядер це може бути критично.

Виправлення: Вмикайте шифрування лише для чутливих шарів або недовірених сегментів; додайте CPU; розгляньте апарат із AES-ускоренням; тестуйте перед масовим розгортанням.

3) «Дрібні файли неймовірно повільні, великі файли — ок»

Симптом: Відкриття папок з багатьма файлами повільне; додатки, що сканують директорії, повільні.

Корінна причина: Операції з метаданими чутливі до затримок; джиттер мережі, перевантажені контролери домену (затримки автентифікації) або затримка сховища на наборі метаданих.

Виправлення: Зменшіть джиттер; перевірте DNS/DC; перевірте затримку й IOPS сховища; розгляньте розміщення метаданих на швидшому носії; уникайте WAN-SMB без акселерації.

4) «Випадкові роз’єднання, запити пароля або «мережевий шлях не знайдено»»

Симптом: Сесії обриваються періодично; при перепідключенні просять креденшали; маповані диски червоніють.

Корінна причина: Посередники часом вичерпують стан для stateful сесій; проблеми з MTU/фрагментацією; некоректні NIC offloads; погане Wi‑Fi; асиметрична маршрутизація разом із multichannel.

Виправлення: Перевірте MTU по шляху; протестуйте без offloads; забезпечте стабільне дротове підключення для критичних систем; перегляньте дизайн multichannel і симетрію маршрутизації.

5) «Ми вимагали підписування, і на одному сервері стало жахливо»

Симптом: Один файловий сервер повільний, інші в порядку; CPU сервера високий під SMB-навантаженням.

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

Виправлення: Перемістіть навантаження; додайте CPU; розділіть ролі. Не вимикайте підписування глобально через один слабкий вузол.

6) «Linux-клієнти монтують, а Windows-клієнти — ні (або навпаки)»

Симптом: Різна поведінка між ОС; помилки «operation not supported» або проблеми автентифікації.

Корінна причина: Невідповідність діалекту (vers=), режиму безпеки (sec=) або конфігурації Samba, що конфліктує з AD/Kerberos очікуваннями.

Виправлення: Узгодьте діалекти (SMB3.1.1 де можливо), стандартизуйте автентифікацію (Kerberos у домені) і перевірте server min protocol та відображення ідентичностей Samba.

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

Крок 1: Знайти використання SMB1 без руйнування сервісів (фаза інвентаризації)

1. На Windows-файлових серверах перелічіть сесії й діалекти за допомогою Get-SmbSession.
2. На Windows-клієнтах (вибірка) перелічіть підключення за допомогою Get-SmbConnection.
3. На Samba перевірте журнали на пропозиції NT1 і використайте smbstatus.
4. Сформуйте список: пристрій/IP, власник, бізнес-функція, шлях заміни/оновлення.

Крок 2: Вимкнути SMB1 у контрольованій послідовності

1. Вимкніть SMB1 на боці сервера на загальних файлових серверах першими.
2. Вимкніть SMB1 на боці клієнта через управління кінцевими точками далі.
3. Для кількох справжніх утримувачів надайте ізольоване рішення: VLAN + виділений шлюз + мінімальні ACL.

Крок 3: Загартуйте SMB2/3 усвідомлено (не по шаблону)

• Підписування: вимагайте там, де це визначає модель ризику; переконайтеся, що сервери розраховані на це.
• Шифрування: вмикайте на чутливих шарах і недовірених сегментах; перевіряйте запас CPU.
• Автентифікація: віддавайте перевагу Kerberos; мінімізуйте застарілий NTLM; вимикайте гостьовий доступ.
• Аудит: зберігайте журнали переговорів і відмов для аналізу аномалій доступу.

Крок 4: Чек-лист валідації продуктивності

• Тестуйте великий послідовний трансфер і навантаження з багатьма дрібними файлами.
• Переконайтеся, що узгоджений діалект залишається на SMB3.x для сучасних клієнтів.
• Перевірте CPU сервера під піковими копіями з увімкненим підписуванням/шифруванням.
• Перевірте швидкість і стабільність NIC клієнта; уникайте Wi‑Fi для тяжких SMB-робочих навантажень, якщо можливо.
• Підтвердьте затримку сховища під навантаженням; SMB чесно передасть проблеми зі сховищем користувачам.

Крок 5: Обробка винятків (те, що всі намагаються пропустити)

• Кожен виняток SMB1 має мати: власника, обґрунтування, мережеву ізоляцію, моніторинг і дату видалення.
• Якщо ви не можете його ізолювати — це не виняток, це вразливість.

Питання та відповіді (FAQ)

1) Чи колись SMB1 прийнятний у внутрішній мережі?

Ні, не як налаштування за замовчуванням. «Внутрішня мережа» — це не межа безпеки; це лише опис маршрутизації. Якщо ви мусите залишити SMB1 для пристрою — ізолюйте і поставте часові рамки.

2) Якщо я вимкну SMB1, чи Windows-клієнти автоматично перейдуть на SMB2/3?

Сучасні Windows домовляться SMB2/3, якщо сервер їх підтримує. Якщо щось ламається, зазвичай причина в тому, що сервер (або NAS) підтримує лише SMB1,
або клієнт застарілий чи неправильно налаштований.

3) У чому практична різниця між SMB2 і SMB3 для більшості організацій?

SMB3 додає шифрування і більш просунуті можливості продуктивності (multichannel, SMB Direct). Якщо вам це не потрібне, SMB2 все одно значно краще за SMB1.
Практично бажано мати SMB3 для сучасних Windows-флотів і позиції безпеки.

4) Чи замінює шифрування SMB потребу в підписуванні?

Шифрування захищає конфіденційність (і цілісність шифрованих даних), але підписування все ще відіграє роль у запобіганні підміні в різних режимах і політиках.
Розглядайте їх як пов’язані контрзаходи, а не взаємозамінні.

5) Чому SMB іноді швидкий для одного користувача, але повільний для багатьох?

Конкурентність виявляє обмеження CPU сервера (підписування/шифрування), обмеження IOPS/затримки сховища і поведінку кредитів SMB. Тести для одного користувача можуть вводити в оману.
Завжди тестуйте під реалістичним паралельним навантаженням при валідації змін.

6) Чи слід вмикати SMB multichannel повсюдно?

Тільки якщо ваш дизайн мережі підтримує це чисто (кілька NIC, стабільна маршрутизація, однаковий MTU, немає дивних посередників).
Multichannel може підвищити пропускну здатність, але також може загострити неправильні налаштування до нестабільних сесій.

7) У нас є NAS. Чи ті самі правила застосовуються?

Так. Ручки можуть бути в GUI, але ризики й режими відмов ті самі. Переконайтеся, що прошивка NAS підтримує SMB3.x, вимкніть SMB1
і перевірте узгоджені діалекти з клієнтів.

8) Щодо Linux-клієнтів, що монтують SMB-шари — що стандартизувати?

Стандартизуйте на SMB3.1.1 де можливо, використовуйте Kerberos (sec=krb5) у доменних середовищах і уникайте дозволяючих відкатів.
Робіть mount-опції явними, а не покладайтеся на дефолти, що змінюються за дистрибутивом або версією ядра.

9) Якщо я вимкну SMB1, як обійти старі принтери/сканери, що підтримують лише SMB1?

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

10) Як довести керівництву, що вимикання SMB1 того варте?

Покажіть докази: які пристрої ще домовляються SMB1, які можливості це відкриває, і як винятки можна ізолювати.
Потім представте план видалення з мінімальним впливом на бізнес і чіткими відповідальними.

Висновок: наступні кроки, що не зіпсують вам вихідні

SMB1 — це не «підтримка спадщини». Це ризик, що проявляється у випадках безпеки і дивних проблемах надійності, які ви ніколи повністю не виправите.
SMB2/3 не ідеальні, але вони створені для світу, в якому ви реально працюєте: завантажені мережі, віртуалізовані сервери і супротивники, що сканують усе підряд.

Практичні кроки:

1. Інвентаризуйте узгоджені діалекти SMB у всьому середовищі (клієнти і сервери). Знайдіть, хто говорить SMB1.
2. Вимкніть SMB1 на боці сервера на загальних файлових серверах. Потім видаліть клієнтську функцію SMB1 по всьому парку машин.
3. Для утримувачів — ізолюйте і поставте часові рамки. Ніяких винятків без ізоляції і дати видалення.
4. Перевірте продуктивність SMB2/3 двома тестами: великі послідовні копії і багато дрібних файлів.
5. Налаштовуйте безпеку осмислено: підписування згідно з політикою, шифрування за шарами там, де це знижує реальний ризик, і плануйте потужності CPU під ці витрати.

Мета не у виграші у конкурсі чистоти протоколу. Мета — нудні файлові шари: досить швидкі, достатньо безпечні і не причина, чому ви пропускаєте вечерю.