Настройка безопасности Windows Server 2025: гайд по Hardening и Group Policy

03.04.2026

Алексей Мишаев

Автор

Инфраструктуры на базе Windows Server 2025 сейчас работают в условиях, когда атаки становятся все более автоматизированными и нацеленными на конкретные уязвимости конфигурации. Microsoft внедряет новые защитные механизмы в каждую новую версию, но ни одна операционная система не является безопасной «из коробки». По умолчанию сервер настраивается для совместимости и удобства развертывания, а не для максимальной защиты. Именно поэтому hardening (усиление) остается критически важным этапом введения сервера в эксплуатацию.

В этом материале мы не будем перечислять все возможные настройки безопасности, а сфокусируемся на ключевых направлениях, которые дают максимальную защиту при разумных затратах на внедрение. Рекомендации применимы как к свежим установкам Windows Server 2025, так и к более ранним версиям (2019, 2022), хотя синтаксис некоторых параметров может незначительно отличаться. Все настройки можно реализовать через локальные политики безопасности или через групповые политики Active Directory, что позволяет централизованно управлять парком серверов.

Содержание

Какие угрозы можно закрыть с помощью правильных настроек

Возможно, самая распространенная угроза для сегодняшних компаний — это шифровальщики (ransomware). Их атаки часто нацелены на непропатченные инфраструктуры, слабые учетные записи, системы с открытыми RDP-портами и возможностью неограниченного запуска исполняемых файлов из временных папок. Один скомпрометированный сервер может привести к шифрованию всей корпоративной сети.

Второй тип вредоносной активности связан с перемещением внутри инфраструктуры. Проникнув в периметр, злоумышленники начинают движение по сети, используя устаревшие протоколы (SMBv1, LLMNR, NBT-NS) для перехвата хэшей и подбора паролей. Правильная настройка этих механизмов резко затрудняет атакующему получение контроля над соседними машинами.

Рустам Галимов

Начальник отдела эксплуатации средств защиты информационных систем, Блок ИБ, «Ростелеком»

Угроза кражи учетных данные и повышения привилегий справедливы для большинства операционных систем. На мой взгляд, подавляющее большинство атак начинается за пределами критичных серверов, и злоумышленник заранее получает все необходимое для атаки, либо обманув пользователя (Pass-the-Hash / Pass-the-Ticket), либо начав ломать старый никем не защищенный сервис. Для этого он может использовать либо уязвимости в службах (например, ZeroLogon), либо устаревшие протоколы (NTLMRelay, SMBRelay) для перехвата аутентификации.

Слабые пароли, отсутствие политик блокировки, локальные учетные записи с одинаковыми паролями — классические векторы, которые до сих пор остаются актуальными. Серьезные риски также создает эксплуатация ненужных служб и открытых портов. Каждая запущенная служба — это потенциальная точка входа, пр этом многие серверы годами работают с активированными компонентами, которые никогда не используются.

Все эти сценарии можно заблокировать или хотя бы сделать более затратными для злоумышленников, если корректно настроить Windows Server.

Базовая гигиена: отключение SMBv1, LLMNR, NBT-NS

Первая линия защиты Windows Server начинается с отключения устаревших протоколов, которые остались в системе только для совместимости с оборудованием и ПО 20-летней давности. В современных сетях эти протоколы фактически не используются, но злоумышленники активно применяют их для первоначального проникновения и горизонтального перемещения.

Server Message Block версии 1 (SMBv1) — это протокол обмена файлами, разработанный еще в 1980-х. Он содержит фундаментальные архитектурные недостатки, позволяющие выполнять удаленный код без аутентификации. Печально известная уязвимость EternalBlue, использованная в атаках WannaCry и NotPetya, поражала именно SMBv1.

В Windows Server 2025 этот протокол по умолчанию не установлен. Однако если сервер был обновлен с более старой версии (2012, 2016, 2019), компонент SMBv1 мог остаться активным. Проверка его статуса и отключение — обязательный шаг при вводе сервера в эксплуатацию. Если в инфраструктуре еще есть устройства, требующие SMBv1 (например, старые принтеры или сканеры), их необходимо заменить либо изолировать в отдельном сетевом сегменте без доступа к критическим системам.

Протоколы LLMNR и NBT-NS помогают определять имена компьютеров в локальной сети, когда DNS не может найти нужный хост. Когда пользователь или приложение пытаются подключиться к ресурсу, имя которого не разрешается через DNS, система отправляет широковещательный запрос: «Кто знает адрес этого хоста?».

Злоумышленник, находящийся в том же сегменте сети, может подделать ответ и представиться нужным ресурсом. В процессе аутентификации жертва отправляет злоумышленнику свой хэш пароля (NTLM), который затем может быть расшифрован или использован в атаке «передача хэша» (pass-the-hash). Эта техника называется «отравлением LLMNR/NBT-NS» и представляет собой классический метод перемещения по инфраструктуре.

Оба протокола были актуальны в эпоху Windows NT, но сегодня в корпоративных сетях они не нужны. Их отключение никак не влияет на работу современных приложений и служб, зато полностью закрывает этот вектор атаки. В средах, где еще используются старые приложения, зависящие от NetBIOS, можно применить поэтапное отключение: сначала в тестовых сегментах, затем — после полной инвентаризации зависимостей.

Дмитрий Бабич

Ведущий инженер отдела сопровождения информационных систем, UDV Group

В смешанной среде с Windows Server 2025 можно безболезненно отключать SMBv1, LM/NTLMv1 и анонимный доступ — это усиливает защиту и редко затрагивает современные системы. Настраиваем через политики: отключение SMBv1 через Computer Configuration → Administrative Templates → SMB Server, а запрет LM/NTLMv1 через Network security: LAN Manager authentication level (выбор Send NTLMv2 response only). Риск «уронить» сеть возникает при полном запрете NTLM (Network security: Restrict NTLM) и требовании подписи SMB (Microsoft network server: Digitally sign communications (always)) без предварительной проверки. Это может нарушить работу устаревших сервисов и устройств. Самое главное — внедрять изменения поэтапно, сначала в режиме аудита (политики Restrict NTLM: Audit), с контролем журналов событий — так можно выявить скрытые зависимости до того, как политика начнет блокировать трафик.

Рустам Галимов

Начальник отдела эксплуатации средств защиты информационных систем, Блок ИБ, «Ростелеком»

Минимально поддерживаемой версией можно смело выставлять SMBv2. Принудительное использование SMBv3 может нарушить работу как пользователей, так и множества и legacy-информационных систем. Отключение уже успевших устареть tls 1.0/1.1 может сломать межсистемное взаимодействие, тут нужно быть осторожнее.

Отключение SMBv1, LLMNR и NBT-NS — пример простых и эффективных способов быстро укрепить защищенность. Эти меры не требуют внедрения оборудования или изменений сетевой архитектуры, но закрывают три классических вектора атак, которые до сих пор регулярно используются злоумышленниками:

исчезает риск эксплуатации уязвимостей SMBv1, включая EternalBlue;
становится невозможным перехват хэшей через LLMNR/NBT-NS poisoning;
уменьшается общая поверхность атаки за счет отключения ненужных сетевых служб.

Все перечисленные параметры легко контролируются через групповые политики Active Directory, что позволяет централизованно управлять их состоянием на всем парке серверов и рабочих станций. Регулярный аудит их статуса должен быть встроен в процессы мониторинга безопасности.

Политики паролей и блокировок: Account Lockout Policy, требования к сложности, LAPS

Учетные записи — самый уязвимый элемент любой инфраструктуры. Сколько бы средств защиты ни настроили специалисты, с легитимными учетными данными злоумышленник становится «своим». Однако Windows Server предоставляет встроенные механизмы, которые заметно усложняют компрометацию учетных записей.

Дмитрий Бабич

Ведущий инженер отдела сопровождения информационных систем, UDV Group

Главная угроза — это получение атакующим привилегированных учетных записей и перемещение по домену. Ключевой сценарий: кража учетных данных (дампы памяти, NTLM-хэши и Kerberos Tickets), после которой идет перемещение по сети через штатные средства (RDP, SMB, PSRemoting, WMI). Это позволяет закрепиться злоумышленнику через утилиты или скрипты. Угроза возрастает из-за членства сервера в домене, т.к. компрометация одной системы открывает доступ к критическим сервисам и всей инфраструктуре домена.

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

Политика блокировки учетных записей (Account Lockout Policy) определяет, сколько неудачных попыток входа допустимо, после чего аккаунт временно блокируется. Чтобы она работала правильно, нужно учитывать несколько ключевых параметров.

Во-первых, нужно правильно настроить порог блокировки (Account lockout threshold). Классическая рекомендация — 5–10 неудачных попыток. Слишком низкое значение (3) приведет к массовой блокировке пользователей из-за случайных ошибок. Слишком высокое (20) делает политику бессмысленной.

Во-вторых, необходимо установить длительность блокировки (Account lockout duration) в районе 15–30 минут. Этого достаточно, чтобы остановить автоматический перебор, но не настолько, чтобы серьезно нарушить работу пользователя.

В-третьих, сброс счетчика неудачных попыток (Reset account lockout counter after) должен также срабатывать в районе 15–30 минут. Если пользователь случайно ошибся паролем, но затем зашел правильно, счетчик должен обнулиться, иначе риск блокировки накапливается.

Политика блокировки должна применяться ко всем учетным записям, включая сервисные и административные. Однако для сервисных аккаунтов, которые используют автоматические подключения, нужно предусмотреть исключения — либо через отдельные организационные единицы (OU) с иными политиками, либо через использование групповых управляемых сервисных аккаунтов (gMSA), которые сами управляют своими паролями.

Следующий фактор безопасности — это требования к сложности паролей. Не секрет, что и в корпоративной среде до сих пор можно встретить пароли вроде admin123, qwerty, Password1. Атакующие используют словари, содержащие миллионы таких комбинаций.

Политика паролей (Password Policy) должна включать:

Минимальную длину в 12–14 символов. Восьми символов уже недостаточно: современное оборудование позволяет подобрать такой пароль за приемлемое время.
Достаточную сложность. Пароль должен содержать символы из трех из четырех категорий: заглавные буквы, строчные буквы, цифры, специальные символы.
Запрет использования предыдущих паролей. Политика «история паролей» (24–12 предыдущих значений) не позволяет пользователям циклически менять один и тот же пароль.
Срок действия пароля — 90–180 дней. Более частую смену сложно администрировать, и пользователи начинают записывать пароли на стикеры.

Современные рекомендации отходят от требования частой смены паролей. Принудительная смена каждые 30–60 дней часто ведет к появлению предсказуемых паролей (!Jan2026pa$$, !Apr2026pa$$ и т.д.) или их записи на бумаге. Гораздо эффективнее сочетать умеренный срок действия (90–180 дней) с двухфакторной аутентификацией (MFA) и мониторингом скомпрометированных учетных данных.

Третий важный блок в этом разделе связан с проблемой локальных администраторов. Такая учетная запись есть на каждом сервере есть встроенная локальная учетная запись администратора. В классическом подходе ее пароль либо одинаков на всех хостах, либо меняется вручную при вводе в эксплуатацию и забывается. Идентичный пароль локального администратора на всех серверах — это «золотой ключ» для злоумышленника: получив доступ к одному серверу, он может войти на любой другой, где пароль не менялся.

LAPS (Local Administrator Password Solution) — встроенная функция Windows (или отдельная утилита для более старых версий), которая автоматически управляет паролями локальных администраторов. Для каждого компьютера в Active Directory генерируется уникальный сложный пароль, который меняется по расписанию. Право на чтение пароля может быть выдано только ограниченному кругу администраторов через специальные разрешения в AD. При необходимости необходимости администратор может запросить текущий пароль конкретного сервера через «Пользователи и компьютеры».

В результате вместо одного «золотого ключа» на каждом сервере используется свой пароль локального администратора. Аудит доступа позволяет контролировать, кто и когда смотрел пароль конкретного сервера. Исключается ручное управление и риск забыть пароль, а ротация обеспечивается без вмешательства человека.

Дмитрий Бабич

Ведущий инженер отдела сопровождения информационных систем, UDV Group

Чтобы внедрить Windows LAPS в Windows Server 2025, нужно включить политики Enable local admin password management, Enable password backup for DSRM accounts и Configure password backup directory, а также задать PasswordAgeDays, PasswordLength и PasswordComplexity. Для подготовки сервера к модели PIM на уровне ОС лучше заранее через GPO минимизировать постоянные локальные привилегии: очистить группу Administrators и ограничить использование встроенной учетной записи Administrator. При миграции нужно отключить политики Legacy LAPS и не применять их одновременно с Windows LAPS. Не забываем заранее проверить ACL на чтение новых атрибутов паролей.

Рустам Галимов

Начальник отдела эксплуатации средств защиты информационных систем, Блок ИБ, «Ростелеком»

Не уверен, что можно реализовать PIM на уровне ОС, т.к. необходим доступ в облако Microsoft. При миграции необходимо либо создать новую учетку с новыми GPO с нуля, либо параллельно запустить две версии LAPS. При этом важно чтобы учетные записи были разными – это позволит избежать конфликтов. Обязательно расширьте схему AD сначала старыми атрибутами, а затем новыми, иначе на «старых» серверах все придется доделывать руками.

LAPS не заменяет управление привилегированными учетными записями (Privileged Access Management, PAM), но является обязательной базовой мерой. В инфраструктурах с Active Directory это де-факто стандарт.

Политики учетных записей отсекают массовые автоматизированные попытки проникновения и закрывают классические уязвимости, связанные со слабыми паролями и локальными учетными записями. В совокупности эти меры делают перебор паролей по словарю неэффективным, повышают стоимость компрометации учетных данных, устраняют пробои в периметре.

Защита от шифровальщиков: запрет запуска из Temp, аудит доступа к файлам, защита RDP

Шифровальщики редко проникают через сложные эксплойты — чаще они используют человеческий фактор (фишинг) и уязвимости конфигурации. Правильно настроенный Windows Server может стать непреодолимым препятствием даже для тех случаев, когда вредоносное ПО уже попало в систему.

Классический сценарий работы шифровальщика: пользователь открывает фишинговое письмо с вредоносным вложением или переходит по ссылке. Вредоносный файл (часто в виде .exe, .scr, .js, .vbs) загружается в папки %Temp% или Downloads, после чего запускается жертвой или автоматически через макросы. Если система позволяет запускать исполняемые файлы из этих папок, атака развивается.

Чтобы устранить вероятность этого сценария нужно запретить запуск любых исполняемых файлов из папок с временными данными и загрузок. Это реализуется через AppLocker или SRP (Software Restriction Policies). Идея проста: разрешить запуск программ только из доверенных директорий — Program Files, Windows, путей, определенных администратором. Все, что пытается стартовать из %AppData%, %Temp%, папок пользователей, блокируется.

AppLocker работает только на Windows Server и клиентских редакциях Enterprise/Education. Для более старых версий или ограниченных бюджетом проектов можно использовать SRP, хотя он менее гибок. Внедрение AppLocker требует предварительного периода «аудита» (режим работы только с логированием). За несколько недель вы соберете информацию о том, какие легитимные приложения запускаются из нестандартных путей, чтобы потом добавить их в исключения. Иначе можно заблокировать, например, обновления браузеров, которые распаковываются во временные папки.

Первым шагом должна стать защита RDP-соединений, которые представляют собой самый уязвимый шлюз для атак. Открытый вовне RDP-порт привлекает автоматические сканеры, которые перебирают пароли и эксплуатируют уязвимости. Даже внутри сети RDP-доступ к серверам без дополнительной защиты остается риском.

Чтобы минимизировать риски RDP-атак, нужно закрыть соответствующие порты на внешнем периметре. Если удаленный доступ нужен, следует использовать VPN, шлюз RD Gateway или решения класса Remote Desktop Session Host с дополнительной аутентификацией.

Далее, необходимо ограничить круг пользователей, которые имеют право подключаться к серверу по RDP. Для этого нужно настроить группы пользователей в локальной политике «Разрешить вход через службы удаленных рабочих столов». Кроме того, политики учетных записей должны предусматривать блокировку после неудачных попыток входов по RDP.

Для ужесточения аутентификации следует требовать сетевой уровень аутентификации (NLA) — это стандарт. Для критических серверов также понадобится двухфакторнуя аутентификация. Наконец, нужно логировать успешные и неудачные попытки подключения, отслеживать аномалии (например, подключения в нерабочее время, с необычных IP-адресов).

Внутри сети RDP между серверами часто необходим для администрирования. Но и здесь не должно быть «разрешено всем подряд». Используйте отдельные административные сегменты и ограничивайте доступ по IP-адресам (например, только с джамп-хостов). Для серверов, где RDP используется постоянно, рассмотрите использование уже упомянутых подходов по настройке локальных администраторов, чтобы каждый сервер имел уникальный пароль.

Дмитрий Бабич

Ведущий инженер отдела сопровождения информационных систем, UDV Group

Политики на базе Virtualization-Based Security (Credential Guard, HVCI) требуют аппаратной виртуализации, SLAT, TPM 2.0 (рекомендуется) и UEFI Secure Boot, а на серверах старых поколений процессоров часть функций может отсутствовать или быть отключена в BIOS. HVCI и WDAC нередко блокируют устаревшие или неподписанные драйверы RAID-контроллеров, сетевых карт и средств резервного копирования. Отдельная проблема — это старые приложения и устройства, зависящие от NTLM или устаревших сетевых механизмов. Поэтому политики обычно внедряют поэтапно, начиная с режима аудита.

Если шифровальщик попал в систему, он начинает массово читать, изменять и шифровать файлы. Пропуск этого события может привести к критическому ущербу. Если система зафиксирует аномальную активность через минуту — есть шанс остановить атаку. Чтобы это было возможно, нужно настроить аудит доступа к файлам и папкам, содержащим критичные данные.

Windows Server позволяет логировать попытки чтения, изменения и удаления объектов. Эти события отправляются в централизованную систему сбора логов (SIEM) или, как минимум, в журнал безопасности с последующим мониторингом. Самое главное: аудит нужно настраивать заранее — в момент атаки включать его поздно.

Логирование тысяч событий каждую секунду требует ресурсов. Поэтому нужно выбирать критические папки и типы операций (например, аудит только изменения и удаления, а не чтения).

Ключевые объекты для аудита:

Общие сетевые папки с документами.
Базы данных и их резервные копии.
Файловые серверы с пользовательскими данными.

События аудита бесполезны, если их никто не анализирует. Обязательно свяжите эту настройку с SIEM или хотя бы с регулярным ручным просмотром критических предупреждений.

Комбинация запрета запуска из временных папок, аудита доступа к файлам и жесткой защиты RDP создает три защитных слоя:

Барьерный: RDP-доступ становится серьезной целью для взлома, что отсекает большинство автоматизированных атак.
Превентивный: шифровальщик не может запуститься из стандартных мест, куда он обычно попадает.
Детективный: аномальная активность (массовое изменение файлов) фиксируется на ранней стадии.

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

Сетевые настройки: правила межсетевых экранов и отключение неиспользуемых служб

После того как компания закрыла учетные записи, запретила запуск вредоносных программ и защитила RDP, пора привести в порядок саму сетевую поверхность сервера. Каждая открытая служба и каждое разрешенное сетевое соединение — это потенциальная точка входа. Чем меньше на сервере активных портов и служб, тем сложнее атакующему найти уязвимость.

По умолчанию Windows Server открывает ряд портов для работы служб (файловый обмен, удаленное управление, DNS, DHCP и т.д.), даже если эти службы не используются. Кроме того, в процессе эксплуатации администраторы часто открывают порты «для теста» и забывают закрыть. В результате сервер оказывается с избыточной сетевой поверхностью атаки.

Нужно настроить файрвол Windows по принципу наименьших привилегий: запретить все, что не требуется для работы конкретной роли сервера. Администраторы должны активно использовать профили. Для серверов, подключенных к домену, активен профиль «Домен» с максимально строгими правилами. «Частные» и «Общедоступные» профили на сервере лучше полностью заблокировать, чтобы случайное подключение к недоверенной сети не открывало дыры.

Определите, какие службы реально используются (например, HTTP/HTTPS для веб-сервера, 445 для файлового сервера, 1433 для SQL Server). Для всего остального создайте правило «Запретить все». Используйте групповые политики, чтобы настроить брандмауэр единообразно на всех серверах одной роли. Прежде чем включать режим «запрещено все», нужно убедиться, что в результате не окажутся заблокированными критически важные службы: DNS, обновления Windows, связь с контроллером домена. Лучше сначала перевести правила в режим аудита или вести логирование блокировок, чтобы выявить легитимный трафик.

Для серверов, работающих в кластерах (Hyper-V, SQL Server Always On), могут требоваться специфические порты — их нужно явно разрешить. Не забывайте про ICMP — его отключение не повышает безопасность существенно, но затрудняет диагностику. Лучше разрешить ping для ограниченных IP-адресов (например, из сегмента мониторинга).

Отключение неиспользуемых служб также должно происходить по принципу «чем меньше, тем лучше». В Windows Server каждая служба имеет свой сетевой интерфейс, может содержать уязвимости и создавать фоновую активность. Злоумышленник, получивший ограниченный доступ, может попытаться использовать легитимную, но ненужную службу для эскалации привилегий или латерального перемещения.

Службы, которые можно отключать на большинстве серверов:

Print Spooler — если сервер не используется как принт-сервер.
Windows Search — не нужна на серверах.
WebClient (WebDAV) — редко используется.
Computer Browser — устаревшая служба, не нужна в современных доменах.
Server (LanmanServer) — только если сервер не предоставляет файловые ресурсы (внимание: ее отключение разорвет доступ к общим папкам).
Workstation (LanmanWorkstation) — если сервер не подключается к общим ресурсам других систем.
Bluetooth, Fax, Infrared — очевидно, не нужны на сервере.

Для серверов с конкретными ролями отключайте службы, не связанные с этой ролью. Например, на контроллере домена не нужен веб-сервер IIS или службы DHCP, если они не используются.

Перед отключением любой службы обязательно проверьте зависимости. Некоторые службы (например, Server или Workstation) являются базовыми для многих операций. Используйте групповые политики для централизованного отключения служб на группах серверов. Однако помните, что разные серверы могут требовать разных наборов служб, поэтому лучше применять политики к организационным единицам (OU) по ролям. Регулярно пересматривайте список активных служб — в процессе эксплуатации могут появляться новые компоненты, которые включают дополнительные службы.

Жесткие сетевые настройки и отключение служб — это часть более широкой практики. Серверы должны выполнять только одну роль (принцип минимальной функциональности). То есть веб-сервер не должен быть контроллером домена, а файловый сервер не должен содержать службы баз данных. Если сервер исполняет несколько функций, его поверхность атаки многократно возрастает, а настройка правил становится запутанной.

Все эти настройки управляются через групповые политики и могут быть внедрены поэтапно: сначала аудит, затем включение блокирующих правил на непилотных серверах, и только потом — на критических системах. В совокупности с ранее описанными мерами (базовая гигиена, политики учетных записей, защита от шифровальщиков) это создает надежный фундамент для безопасности Windows Server 2025.

Заключение

Четыре рассмотренных блока — базовая гигиена, политики учетных записей, защита от шифровальщиков и сетевые ограничения — формируют минимальный, но достаточный набор мер для повышения безопасности Windows Server. Они не требуют закупки дополнительных продуктов (за исключением, возможно, LAPS, который идет в комплекте с ОС) и реализуются штатными средствами. Однако внедрение этих практик требует дисциплины: регулярного аудита, централизованного управления через групповые политики и постоянного мониторинга.

В условиях, когда атаки становятся все более автоматизированными, правильно настроенный сервер перестает быть «легкой добычей» и заставляет злоумышленника тратить время и ресурсы. А это уже серьезный барьер на пути к компрометации.