Укрепление Windows Server против DDoS: что ещё настраивать, а что ОС уже делает сама

Это руководство — об укреплении самого хоста Windows Server, без какого-либо устройства перед ним, против той части DDoS-атаки, что исчерпывает состояние и запросы. Оно намеренно короче по части правок реестра, чем большинство руководств по Windows, по одной причине. Большинство этих правок устарели, а следование им простирается от бесполезного до вредного.

Самое ценное, что стоит знать об укреплении Windows от DDoS, — это чего не делать. Ключи реестра SynAttackProtect, TcpMaxHalfOpen, TcpMaxHalfOpenRetried и жёстко заданный TcpWindowSize, которыми забиты старые руководства, либо удалены после Windows Server 2003, либо перекрыты автонастройкой. Задавать их в лучшем случае не даёт ничего. А жёстко фиксировать размер окна — значит прямо ломать понастроечную работу стека.

Устройство	Старый совет (не следовать)	Почему устарел	Что делать вместо этого
SynAttackProtect	Задать в реестре SynAttackProtect=2	Удалён после Server 2003; защита от SYN автоматическая	Проверять через netstat; при нужде ограничить в WFP
TcpMaxHalfOpen	Ограничить полуоткрытые соединения в реестре	Стек больше не читает это значение	Наблюдать через Get-NetTCPConnection -State SynReceived
Окно приёма TCP	Жёстко задать TcpWindowSize	С Vista/2008 автонастройка задаёт размер на соединение	Шаблон Set-NetTCPSetting, не жёсткое значение
Лимиты соединений	Полагаться на умолчание ОС	Умолчание щедрое; ничто не ограничивает по источнику	Фильтр WFP или правило брандмауэра по адресу источника

Весь левый столбец — накопленный интернетом фольклор эпохи Windows 2003. Современный стек сделал большую часть автоматической. Заданные удалённые ключи не делают ничего, а несколько жёстких значений ухудшают положение, перекрывая автонастройку.

0. Сначала базовые значения: прочитайте счётчики, прежде чем что-то менять

Windows показывает своё состояние через счётчики производительности и командлеты Get-Net*, а не через /proc. Запишите нормальную неделю из этих источников:

# Число соединений по состоянию TCP (строка SynReceived — ваш полуоткрытый backlog)
Get-NetTCPConnection | Group-Object -Property State | Sort-Object Count -Descending

# Счётчики стека TCP: сегменты, сбросы, неудачные соединения
Get-Counter '\TCPv4\*' -SampleInterval 5 -MaxSamples 3

# Активный шаблон соединения и его уровень автонастройки
Get-NetTCPSetting -SettingName Internet | Format-List *

# Состояние RSS адаптера и число очередей
Get-NetAdapterRss | Format-Table Name, Enabled, NumberOfReceiveQueues

Сохраните этот вывод. Любое суждение ниже относительно него. «Число SynReceived высокое» означает что-то лишь по сравнению с показателем нормальной недели.

1. Стек TCP: шаблоны, а не ключи реестра

Современный Windows Server не выставляет старые скалярные значения реестра TCP как поверхность настройки. Вместо этого он применяет шаблон на тип соединения, и вы правите шаблон. Шаблоны — это Internet, Datacenter, Datacenter Custom, Internet Custom и Compat.

# Посмотреть каждую настройку, что применяет активный шаблон
Get-NetTCPSetting -SettingName Internet

# Окно приёма автонастройки — оставьте 'normal', если нет измеренной причины
Set-NetTCPSetting -SettingName InternetCustom -AutoTuningLevelLocal Normal

# Убедиться, что автонастройка не отключена старым скриптом укрепления (частая находка)
Get-NetTCPSetting | Format-Table SettingName, AutoTuningLevelLocal
netsh int tcp show global

Самая частая реальная проблема на проверяемом сервере Windows — не отсутствующая правка. Это старый скрипт укрепления, отключивший автонастройку командой netsh int tcp set global autotuninglevel=disabled. Эта одна строка держит окно приёма на малом фиксированном значении и душит каждое легитимное соединение. Включить её обратно — обычно крупнейшее одиночное улучшение:

netsh int tcp set global autotuninglevel=normal

Защита от SYN-потока сама по себе автоматическая, и на поддерживаемой ОС её нельзя осмысленно улучшить из реестра. Её не настраивают, а проверяют, справляется ли она:

# Полуоткрытые соединения прямо сейчас
(Get-NetTCPConnection -State SynReceived).Count

# Неудачные попытки соединения и сбросы, из счётчиков стека
Get-Counter '\TCPv4\Connection Failures','\TCPv4\Connections Reset'

Если во время события число SynReceived взбирается к десяткам тысяч, ответ — не ключ реестра. Ответ — ограничение по источнику на уровне WFP или на вышестоящем слое, рассмотренное ниже.

2. Windows Filtering Platform: где живёт ограничение по источнику

Linux делает ограничение по источнику динамическим набором nftables. Windows-аналог живёт в Windows Filtering Platform, и для большинства операторов его доступное лицо — правило брандмауэра. Встроенного примитива «N соединений в секунду на источник», настолько же чистого, как у nftables, нет. Поэтому практический шаблон — это ограниченная по области блокировка, управляемая мониторингом, плюс правила безопасности соединений, сужающие открытую поверхность.

# Заблокировать конкретный вредоносный источник (то, что вызовет автоматический ответчик)
New-NetFirewallRule -DisplayName "DDoS-block-203.0.113.0/24" -Direction Inbound `
  -RemoteAddress 203.0.113.0/24 -Action Block

# Ограничить службу лишь теми адресами, что вообще должны до неё доходить, —
# крупнейшее одиночное сокращение поверхности атаки, и без всякой логики частоты
New-NetFirewallRule -DisplayName "RDP-restrict" -Direction Inbound -Protocol TCP `
  -LocalPort 3389 -RemoteAddress 10.0.0.0/8 -Action Allow

# Посмотреть, что на самом деле включено
Get-NetFirewallRule -Enabled True -Direction Inbound |
  Where-Object Action -eq Allow | Format-Table DisplayName, Profile

Честное ограничение таково. Брандмауэр Windows сам по себе не ограничивает частоту новых соединений на источник так, как это делает набор nftables. Где это нужно, решение приходит от callout-драйвера WFP, стороннего слоя или, как обычно и бывает на любом масштабе, от сетевого слоя перед хостом. Сильнейший вклад брандмауэра в устойчивость к DDoS — не ограничение частоты. Это сокращение поверхности, то есть гарантия, что каждый слушающий порт достижим лишь оттуда, откуда должен.

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

Get-NetIPsecRule | Format-Table DisplayName, Enabled, Profile

3. http.sys: очередь запросов ядра перед IIS

Для любой HTTP-нагрузки первая очередь, в которую бьёт поток запросов, — это не IIS. Это http.sys, драйвер режима ядра, принимающий и ставящий HTTP-запросы в очередь до того, как их увидит рабочий процесс. Его параметры живут под службой HTTP, и его очередь — ресурс, отдельный от всего, что настраивает IIS.

# Очереди запросов ядра и их глубина
Get-Counter '\HTTP Service Request Queues(*)\CurrentQueueSize'
Get-Counter '\HTTP Service Request Queues(*)\RejectedRequests'

Ключевые поведения для понимания — длина очереди запросов, тайм-аут соединения и тайм-аут ожидания заголовка. Их в основном оставляют по умолчанию, пока счётчик не докажет иное. Тайм-аут ожидания заголовка — это защита уровня http.sys от медленных атак на заголовки (открыть соединение и слать заголовки по байту). Драйвер сбрасывает соединение, не завершившее заголовки в срок, ещё до того, как IIS выделит ему рабочий процесс.

Настройки на стороне IIS — длина очереди пула приложений, динамические ограничения IP, фильтрация запросов — это отдельный слой со своим руководством по укреплению IIS. Здесь важно, что http.sys — очередь под IIS. Сайт может держаться, пока рабочий процесс перегружен, потому что http.sys поглощает; или падать, пока процесс выглядит простаивающим, потому что http.sys отвергает.

4. Receive Side Scaling: защита от частоты пакетов

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

# Включён ли RSS и сколько очередей?
Get-NetAdapterRss -Name * | Format-Table Name, Enabled, NumberOfReceiveQueues, MaxProcessors

# Включить и дать достаточно очередей (по числу доступных ядер)
Enable-NetAdapterRss -Name "Ethernet"
Set-NetAdapterRss -Name "Ethernet" -NumberOfReceiveQueues 8

# Смотреть нагрузку прерываний по процессорам во время теста — одно горячее ядро значит RSS не распределяет
Get-Counter '\Processor(*)\% Interrupt Time' -SampleInterval 2 -MaxSamples 5

# Receive Segment Coalescing может помочь пропускной способности, но вредит чувствительным к задержке; измеряйте
Get-NetAdapterRsc | Format-Table Name, IPv4Enabled, IPv6Enabled

Одно горячее ядро под нагрузкой, пока остальные пусты, — подпись того, что RSS не делает свою работу. Это точный Windows-аналог растущего третьего столбца в softnet_stat Linux.

5. Поведение соединений на уровне приложения

Два элемента уровня хоста поддерживают любой веб-сервер сверху. TCP keep-alive распознаёт и возвращает мёртвые соединения, а диапазон динамических портов определяет, сколько исходящих/эфемерных соединений хост может держать:

# Диапазон эфемерных портов — расширьте, если хост делает много исходящих соединений
netsh int ipv4 show dynamicport tcp
netsh int ipv4 set dynamicport tcp start=1024 num=64511

# TCP keep-alive — настройка стека на соединение; шаблон её несёт
Get-NetTCPSetting -SettingName Internet | Select-Object SettingName, *KeepAlive*

На медленные атаки соединениями в конечном счёте отвечает не ОС, а собственные тайм-ауты веб-сервера. Для IIS они в руководстве по IIS, а для nginx или Apache на Windows — в их руководствах.

Счётчики, которые заводят в мониторинг

Укрепление Windows, как и Linux, читается со счётчиков, а не ощущается. Заведите эти в систему мониторинга:

# Одноразовое чтение здоровья, которое может вызвать ответчик
Get-Counter @(
  '\TCPv4\Connection Failures',
  '\TCPv4\Connections Reset',
  '\HTTP Service Request Queues(_Total)\CurrentQueueSize',
  '\HTTP Service Request Queues(_Total)\RejectedRequests',
  '\Processor(_Total)\% Interrupt Time'
) -SampleInterval 5 -MaxSamples 1

# Полуоткрытый backlog одним числом
(Get-NetTCPConnection -State SynReceived).Count

Они отвечают во время атаки на тот же вопрос, что и счётчики Linux. Сужается ли хост или заполняется канал?

Честный предел этого слоя

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

Первый — насыщение канала. Объём выше канала доступа вообще не доходит до стека Windows, и ни шаблон, ни правило брандмауэра, ни очередь RSS этого не меняют.

Второй — частота пакетов сверх того, что могут обработать даже хорошо распределённые ядра. RSS поднимает этот потолок, но не убирает. Выше этих двух порогов предмет — сетевая архитектура, а не сервер. Укрепление хоста держит сервер на ногах, пока не вступит верхний слой, но само им не является, и считать его таковым — значит порождать ложную уверенность.

Порядок применения

1. Запишите базовые значения (Раздел 0): соединения по состоянию, счётчики TCP, шаблон, состояние RSS.
2. Убедитесь, что автонастройка не отключена старым скриптом; включите, если отключена. Это самый частый одиночный выигрыш.
3. Сократите поверхность брандмауэра: каждый слушающий порт достижим лишь оттуда, откуда должен.
4. Проверьте, что RSS включён и имеет достаточно очередей, особенно на виртуальных адаптерах.
5. Оставьте http.sys и шаблон TCP по умолчанию, пока счётчик не докажет конкретное узкое место.
6. Заведите счётчики в мониторинг как сигналы тревоги.

Заметьте, чего в этом списке нет: длинного раздела про реестр. На поддерживаемом Windows Server такой раздел — признак руководства, написанного двадцать лет назад.