🪟 Windows: SMB через порт 445 в 2026 году — это как ходить в интернет через telnet

Коллеги, признайтесь: у скольких из вас в DMZ или для удалённого офиса проброшен TCP 445 с каким-нибудь ACL "только для своих"? Я видел такое на аудите буквально в прошлом квартале, и это зрелище не для слабонервных.

Windows Server 2025 принёс кое-что важное для всех изданий, не только Azure Edition: SMB over QUIC — это SMB, инкапсулированный в QUIC-протокол и работающий через UDP 443 с TLS 1.3. Для удалённого пользователя это выглядит как обычная сетевая папка, но транспорт полностью зашифрован и firewall-friendly. Никакого VPN, никакого открытого 445-го.

Включаем через PowerShell (WAC для 2025 пока не поддерживает, только PS):

# 1. Убеждаемся что SMBv1 мёртв
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# 2. Включаем аудит — смотрим кто ещё не умеет шифрование
Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# 3. Привязываем сертификат к SMB over QUIC
# (сертификат нужен с SAN = FQDN файл-сервера, можно Let's Encrypt)
$thumb = (Get-ChildItem Cert:\LocalMachine\My | 
  Where-Object {$_.Subject -like "*fileserver*"}).Thumbprint

Set-SmbServerCertificateMapping `
  -Name "QuicCert" `
  -Thumbprint $thumb `
  -StoreName "My" `
  -Force

# 4. Включаем QUIC-листенер на интерфейсе
New-SmbServerNetworkInterface `
  -InterfaceAlias "Ethernet" `
  -QuicListener $true

# 5. Проверяем — клиент должен видеть QUIC
Get-SmbConnection | Select ServerName, Dialect, TransportName
# TransportName = QUIC — победа

Зачем это нужно:
Всё SMB-соединение, включая аутентификацию и авторизацию, находится внутри TLS-туннеля и никогда не открыто на сетевом уровне.

Итог: TCP 445 — это наследие 1996 года. У вас есть Windows Server 2025 и три команды в PowerShell. Нет причин не закрыть этот вопрос сегодня.

#windows #smb #quic #security #windowsserver2025 #sysadmin #admin_future

🪟 Windows: OSConfig — GPO умерло, долго живёт drift control

Коллеги, у вас в домене есть сервера, где кто-то "временно" отключил NTLMv1 и забыл вернуть? Или изменил политику аудита "под задачу"? Или коллега поставил TLS 1.0 для совместимости с каким-то древним ПО и не сказал? Я видел такое. Называется configuration drift, и он медленно разрушает безопасный периметр, который ты тщательно выстраивал.

В Windows Server 2025 Microsoft тихо привезла ответ на этот вопрос: OSConfig. Каждые несколько часов OSConfig сканирует отклонения от baseline-конфигурации и автоматически исправляет их — без необходимости ждать GPO-обновления или вмешательства вручную.

Базовая линия безопасности включает более 300 настроек безопасности, соответствующих отраслевым стандартам. После применения параметры автоматически защищены от дрейфа — это одна из ключевых особенностей платформы.

Разворачиваем и настраиваем:

# Устанавливаем модуль из PSGallery (нужен WS2025)
Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force

# Смотрим доступные сценарии
Get-OSConfigMetadata | Format-Table Name, Description -Wrap
# Сценарии: SecurityBaseline, SecuredCore, AppControl, Defender

# Применяем baseline для Member Server (более 300 настроек разом)
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer

# Для Domain Controller — отдельный сценарий
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/DomainController

# Проверяем что применилось и нет расхождений
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer

# Включаем drift control (автоисправление отклонений)
# По умолчанию проверка каждые 4 часа
Get-OSConfigDriftControl
# Ужесточаем — проверка каждые 45 минут
Set-OSConfigDriftControl 45

# Смотрим конкретный параметр и его текущее состояние
Get-OSConfigDesiredConfiguration `
  -Scenario SecurityBaseline/WS2025/MemberServer `
  -Setting AuditDetailedFileShare

# Кастомизируем под свои нужды (без потери drift control)
# Например, разрешаем RDP drive redirection (отключено по умолчанию)
Set-OSConfigDesiredConfiguration `
  -Scenario SecurityBaseline/WS2025/MemberServer `
  -Name RemoteDesktopServicesDoNotAllowDriveRedirection `
  -Value 0

# Проверяем соответствие требованиям CIS/DISA STIG
# (OSConfig покрывает их автоматически при применении baseline)
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer |
  Where-Object {$_.ComplianceState -ne "Compliant"} |
  Select-Object Name, ExpectedValue, ActualValue

Важный нюанс: OSConfig не заменяет GPO и не конкурирует с ним напрямую. Он отлично подходит для изолированных серверов, workgroup-машин и облачных инстансов, где нет централизованного AD. В AD-среде — дополнительный слой защиты поверх GPO.

Зачем это нужно:
Аудиторы любят вопрос "как вы гарантируете, что конфигурация безопасности не изменилась с момента последней проверки?". Раньше честный ответ был "ну, мы стараемся следить". Теперь ответ: "автоматический drift control каждые 45 минут с логами". CIO это оценит на следующем совещании по ИБ.

Итог: GPO — это политика на бумаге. OSConfig — это политика, которая не даёт себя обойти. Разница принципиальная.

#windows #security #osconfig #drift #windowsserver2025 #sysadmin #admin_future

🪟 Windows: Native NVMe в WS2025 — +80% IOPS, и это ещё не включено по умолчанию

Коллеги, фича которая доступна с октября 2025-го, но большинство администраторов её не включили — потому что она opt-in и спрятана за реестром.

Всё Windows Server до 2025 включительно общался с NVMe-дисками через SCSI-эмуляцию. Команды NVMe переводились в SCSI и обратно — лишний слой абстракции, shared locks в kernel I/O path, лишние CPU-циклы. Включение native NVMe даёт до 80% выше IOPS и до 45% ниже CPU utilization под высокой I/O нагрузкой.

Это особенно важно для Storage Spaces Direct, SQL Server и любых disk-intensive workloads.

# Проверяем установлено ли обновление KB5066835 (октябрь 2025) или новее
Get-HotFix | Where-Object {$_.InstalledOn -gt "2025-10-01"} |
  Select-Object HotFixID, InstalledOn |
  Sort-Object InstalledOn -Descending | Select-Object -First 5

# Включаем Native NVMe через реестр (требует перезагрузки):
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" `
  /v 1176759950 /t REG_DWORD /d 1 /f

# Проверяем что драйвер переключился
# После перезагрузки в Device Manager NVMe диски должны показывать
# "NVM Express Controller" вместо "Standard SATA AHCI Controller"
Get-PnpDevice | Where-Object {$_.Class -eq "DiskDrive"} |
  Select-Object FriendlyName, Status

# Бенчмарк до и после — замеряем IOPS с DiskSpd:
# (скачать с https://github.com/microsoft/diskspd)
.\diskspd.exe -b4K -d30 -o32 -t8 -r -w0 -L C:\testfile.dat

# Для S2D кластеров — проверяем здоровье после включения
Get-StoragePool | Get-VirtualDisk | Select-Object FriendlyName, HealthStatus, IOPS

Зачем это нужно:
Windows Server 2025 больше не трактует все устройства хранения как SCSI. Native NVMe обеспечивает прямой многоочередной доступ к устройствам — это означает возможность достичь реальных пределов производительности железа.

Итог: если у тебя WS2025 с NVMe-дисками и это не включено — ты буквально оставляешь 80% производительности хранилища на столе. Одна команда в реестре и перезагрузка. Сделай это сегодня.

#windows #nvme #storage #performance #windowsserver2025 #sysadmin #admin_future

🪟 Windows: Майский Patch Tuesday — hotpatch возобновляется, но есть нюанс

Коллеги, 11 мая — первый hotpatch-вторник после апрельского OOB-фикса, который прервал цикл. Разбираем коротко что происходит и чего ждать.

Напомню схему: январь, апрель, июль, октябрь — полный baseline с перезагрузкой. Февраль, март, май, июнь и т.д. — hotpatch без рестарта. Май по плану должен быть hotpatch-месяцем.

Но апрель внёс коррективу: OOB-фикс KB5091157 для апрельского DC reboot-loop потребовал перезагрузки и приостановил hotpatching. Для тех кто его установил — hotpatch возобновится только с майского обновления.

Ещё важный момент о стоимости: hotpatch для Windows Server 2025 вне Azure требует Azure Arc и платной подписки через Azure Arc — это не бесплатная функция для on-premises серверов.

# Проверяем текущий статус hotpatch на сервере
# Смотрим что установлено последним
Get-HotFix | Sort-Object InstalledOn -Descending |
    Select-Object HotFixID, InstalledOn -First 3

# Проверяем включён ли VBS (обязательное требование):
Get-CimInstance -ClassName Win32_DeviceGuard `
    -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus
# 2 = Running = hotpatch возможен

# Проверяем подключение к Azure Arc (нужно для on-prem hotpatch):
azcmagent show 2>$null | Select-String "Status"
# Connected = готов к hotpatch

# Смотрим историю hotpatch vs обычных обновлений:
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" |
    Where-Object {$_.Id -eq 19} |  # ID 19 = успешная установка
    Select-Object TimeCreated, Message |
    Format-List |
    Select-Object -First 5

# Если нужно временно отключить hotpatch (например для тестов):
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" `
    -Name "HotPatchRestrictions" -Value 1 -Type DWORD
# Вернуть: Value 0

Зачем это нужно:
Hotpatch не охватывает все обновления — .NET-патчи, несекьюрити-обновления и патчи сторонних компонентов по-прежнему требуют перезагрузки. Нельзя считать, что сервер с hotpatch больше никогда не перезагружается.

Итог: четыре перезагрузки в год вместо двенадцати — реальное улучшение для uptime. Но hotpatch не бесплатен на on-prem и не заменяет полный patch management. Знай что у тебя включено и почему.

#windows #hotpatch #patchtuesday #windowsserver2025 #sysadmin #admin_future

🪟 Windows: DNS over HTTPS на сервере стал GA — шифруем DNS для клиентов

Коллеги, в июньском обновлении Windows Server 2025 (KB5094125) тихо приехала фича которую ждали — и которую затмили 206 CVE и Secure Boot. Разбираем.

Июньское обновление включает server-side DNS over HTTPS (DoH) как generally available. Это обеспечивает шифрованную DNS-коммуникацию между сервером и его клиентами, улучшая приватность и безопасность за счёт защиты DNS-запросов, особенно против определённых атак. Важно: DoH-поддержка применяется только к server-to-client коммуникации, не к шифрованию между серверами.

Почему это важно: DNS-запросы исторически идут открытым текстом. Любой кто видит трафик — видит какие домены резолвят твои клиенты. Для внутренней сети это вектор разведки при компрометации, для филиалов через недоверенные каналы — прямая утечка. DoH закрывает это на уровне DNS-сервера.

Также в этом же обновлении — важный фикс по теме которую мы разбирали в апреле:

Обновление решает проблему когда некоторые устройства могли входить в BitLocker recovery после обновления boot-файлов, на системах с определёнными настройками TPM validation (особенно невалидными PCR7-конфигурациями). Это поведение возникало после установки апрельского обновления KB5082063.

# Включаем DNS over HTTPS на Windows Server 2025 DNS-сервере:

# 1. Проверяем что июньское обновление установлено:
Get-HotFix -Id KB5094125 -ErrorAction SilentlyContinue

# 2. Включаем DoH на DNS-сервере:
Set-DnsServerSetting -Name "EnableDoHServer" -Value $true
# (точное имя командлета может отличаться — проверяем доступные:)
Get-DnsServerSetting -All | Select-String -Pattern "DoH|HTTPS"

# 3. Привязываем сертификат для DoH (нужен валидный TLS-сертификат):
# Сертификат с SAN = FQDN DNS-сервера
$cert = Get-ChildItem Cert:\LocalMachine\My |
    Where-Object {$_.Subject -like "*dns-server-fqdn*"}
# Регистрируем сертификат для DoH listener

# 4. Проверяем что DoH слушает (порт 443):
Get-NetTCPConnection -LocalPort 443 -State Listen |
    Where-Object {$_.OwningProcess -eq (Get-Process dns).Id}

# 5. Также новая GPO для контроля Secure Boot телеметрии:
# Computer Config -> Admin Templates -> Windows Components
# -> Secure Boot -> LimitSecureBootRequiredServiceData
# Позволяет ограничить какие Secure Boot данные уходят в Microsoft

# 6. Настраиваем клиентов на использование DoH:
# GPO: Computer Config -> Admin Templates -> Network -> DNS Client
# -> Configure DNS over HTTPS (DoH) name resolution -> Require DoH

Зачем включать сейчас: после месяцев фокуса на патчинге уязвимостей — это редкая возможность улучшить базовую безопасность инфраструктуры проактивно. Шифрование DNS закрывает целый класс пассивной разведки в сети.

Итог: июньское обновление это не только 206 CVE и Secure Boot. Это DoH server-side GA + фикс апрельской BitLocker-проблемы. Подними DoH в лабе на этой неделе — это базовая гигиена которую долго ждали в Windows Server.

#windows #dns #doh #windowsserver2025 #security #sysadmin #admin_future