SMBv1 в корпоративной сети: отключаем через GPO после дампа Shadow Brokers

После того как Shadow Brokers выложили полный дамп с EternalBlue, Microsoft официально подтвердил то, что специалисты и так рекомендовали последние пару лет: SMBv1 нужно отключать. Не «когда-нибудь», не «после проверки», а прямо сейчас. Мы взяли это за ближайший приоритет в управляемой инфраструктуре и прошлись по клиентскому парку.

Патч MS17-010 к тому моменту был установлен у большинства - мы это разбирали раньше. Но патч и отключение SMBv1 - разные вещи. Патч закрывает конкретную уязвимость в конкретной реализации. Отключение протокола убирает весь класс проблем, которые могут идти через SMBv1, включая то, что ещё не опубликовано.

Как проверяли, что SMBv1 вообще включён

Первый шаг - инвентаризация. Нельзя отключать то, о чём не знаешь состояния.

На Windows Server 2012 R2 и новее состояние проверяется через PowerShell:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Get-SmbServerConfiguration | Select EnableSMB1Protocol

На старых серверах - 2008 R2, 2008 - через реестр:

Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters SMB1

Значение 0 - выключено, 1 или отсутствие параметра - включено (да, по умолчанию включено, потому что обратная совместимость).

На клиентских Windows 7/8.1 картина та же: SMBv1 включён по умолчанию. Быстрый способ проверить по всему домену - через GPO Preference или простой PowerShell-скрипт через Invoke-Command по списку хостов.

Результат у нескольких клиентов оказался предсказуемым: SMBv1 включён на всём парке, потому что никогда не отключался. Некоторые машины никогда и не трогали в этом смысле - зачем, «всё же работает».

GPO для отключения

Сам механизм отключения через GPO несложный. В реестре нужно выставить параметр SMB1 в 0 для серверной части и отдельно проверить клиентскую:

• Серверная часть (принимает SMB-подключения): HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters, параметр SMB1 = 0
• Клиентская часть (инициирует подключения): HKLM\SYSTEM\CurrentControlSet\Services\mrxsmb10, параметр Start = 4 (отключить службу)

Оба параметра раскатываем через GPO Registry Preferences. Политику применяем сначала на пилотную OU - штук двадцать рабочих станций и пара некритичных серверов - ждём сутки, смотрим на жалобы.

Отдельно через GPO закрываем 445/TCP на межсетевых экранах между сегментами там, где SMB между ними не нужен. Windows Firewall через GPO позволяет это сделать централизованно, а не руками на каждом хосте.

Сюрпризы - принтеры и NAS

Вот тут начинается самое интересное.

Сетевые принтеры. Ряд корпоративных МФУ - особенно агрегаты постарше - используют SMBv1 для сканирования в сетевую папку (scan-to-folder). Устройство само инициирует SMB-соединение и кладёт файл в шару. После отключения SMBv1 сканирование просто перестаёт работать. Принтер молчит, пользователь звонит в поддержку, поддержка недоумевает. Типичная цепочка: «принтер сломался» - «а что делали?» - «ничего, само».

Решение зависит от устройства: у части МФУ есть прошивки с поддержкой SMBv2/v3, у части - нет. Где прошивки нет, единственный вариант - FTP или email-to-scan, если железка поддерживает. Иногда проще заменить принтер, чем держать SMBv1 ради него.

NAS-устройства. Здесь ситуация аналогичная. Старые NAS на базе Samba до версии 4.x используют SMBv1 по умолчанию или вообще не умеют v2/v3. После отключения - доступ к шарам пропадает у всех, кто ходит с Windows, потому что Windows после отключения SMBv1 на клиенте тоже перестаёт инициировать v1-соединения.

На одном объекте нашли NAS, который использовался для резервного копирования. Ни одна живая душа не помнила его IP-адреса, потому что он лет пять работал сам по себе. После отключения SMBv1 бэкапы тихо перестали выгружаться. Обнаружили через неделю при проверке.

Файловый сервер на Server 2003. Да, такой нашёлся. Подключать к нему Windows-клиенты с отключённым SMBv1 не получится - Server 2003 умеет только SMBv1. Это отдельный разговор с клиентом о том, что Server 2003 это вообще-то 2003 год.

445 между сегментами

Помимо отключения протокола, закрывали 445/TCP между сегментами сети там, где SMB между ними обоснованно не нужен. Логика простая: если пользователи одного отдела не должны ходить на файловые серверы другого, 445 между этими VLAN незачем быть открытым.

Реализация через ACL на коммутаторах уровня L3 или через NGFW, где трафик между сегментами идёт через него. Проверяли фактическое состояние правил, а не просто наличие политики - разница, как оказалось, есть.

Где сейчас

Основная волна отключения прошла. Принтеры с проблемами - часть перепрошита, часть переведена на email-to-scan, один вопрос ещё висит у клиента на согласовании замены железки. NAS-вопросы закрыты обновлением Samba там, где это было возможно.

Проверка SMBv1 по итогу добавлена в стандартный чеклист аудита инфраструктуры - наравне с состоянием патчей и конфигурацией файервола. Потому что «включено по умолчанию и никогда не трогалось» - это примерно половина того, что находится в корпоративных сетях.