Блокирование UDP-соединения с портом 389 через брандмауэр

Обзор

LDAP (Lightweight Directory Access Protocol) — это протокол прикладного уровня, лежащий в основе Active Directory. Обычно он работает по TCP, но имеет и версию без установления соединения — CLDAP (Connectionless LDAP) — которая работает по UDP на порту 389. Клиенты Windows используют CLDAP для поиска контроллеров домена («LDAP-пинг», выполняемый службой DC Locator). Современные версии Windows во многих сценариях могут переходить на обнаружение через DNS и LDAP по TCP, но CLDAP по UDP 389 по-прежнему используется для операций DC Locator и присоединения к домену.

Проблема безопасности — это злоупотребление отражением (усилением). Злоумышленник отправляет небольшой поддельный CLDAP-запрос на UDP-порт 389 сервера, подменяя IP-адрес источника так, чтобы запрос выглядел исходящим от жертвы. Сервер затем отправляет гораздо больший ответ на адрес жертвы. Помноженное на множество открытых серверов, это заваливает жертву трафиком. В прошлом наблюдались коэффициенты усиления свыше 50× в зависимости от размера ответа LDAP — поэтому открытые серверы и используют как отражатели.

Цель этого руководства — не дать вашему серверу выступать таким отражателем, не нарушая при этом легитимные функции Active Directory.

Шаг 1: Определите, является ли ваш сервер контроллером домена

Это самый важный шаг, потому что он определяет, что (и нужно ли вообще) блокировать.

В стандартной установке Windows Server UDP-порт 389 обычно используется только службой Active Directory Domain Services после повышения сервера до контроллера домена. Обычный Windows Server (веб-сервер, сервер приложений, файловый сервер и т. д.) по умолчанию не слушает UDP 389, поэтому не может быть использован как CLDAP-отражатель, если только другое приложение (например, AD LDS или сторонняя служба LDAP) не предоставляет CLDAP-службу на этом порту.

Откройте PowerShell от имени администратора и проверьте фактическую роль сервера в домене:

(Get-CimInstance Win32_ComputerSystem).DomainRole

Интерпретация результата:

0 — Автономная рабочая станция (Standalone Workstation)
1 — Рабочая станция — член домена (Member Workstation)
2 — Автономный сервер (Standalone Server)
3 — Рядовой сервер (Member Server)
4 — Контроллер домена (для исторической совместимости обозначается как «Backup Domain Controller» — это значение возвращают все современные контроллеры домена Active Directory)
5 — Контроллер домена с FSMO-ролью эмулятора PDC (для исторической совместимости обозначается как «Primary Domain Controller»)

Если результат не 4 и не 5, сервер не является контроллером домена.

Можно также проверить, слушает ли что-нибудь на UDP 389:

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Если команда ничего не возвращает, Windows не слушает UDP-порт 389, то есть сервер не предоставляет CLDAP-службы и не подвержен этой атаке.

Если ваш сервер НЕ является контроллером домена

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

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

Если ваш сервер ЯВЛЯЕТСЯ контроллером домена

Контроллер домена действительно слушает UDP 389 и может быть использован как отражатель — но UDP 389 при этом необходим для нормальной работы домена.

Внимание: Не блокируйте вслепую весь входящий трафик UDP 389 на контроллере домена. Клиенты, присоединённые к домену, используют CLDAP (UDP 389) для поиска контроллера домена, и этот же порт нужен для присоединения к домену. Сплошная блокировка может помешать клиентам находить контроллер домена и нарушить вход в систему и присоединение к домену.

Правильный подход на контроллере домена:

В идеале контроллер домена вообще не должен быть доступен из интернета. Злоупотребление отражением приходит снаружи, поэтому самое чистое решение — держать DC за периметровым брандмауэром и не выставлять UDP 389 в публичный доступ.

Если сервер всё же должен быть доступен извне, не блокируйте UDP 389 глобально. Вместо этого блокируйте его только для внешних/недоверенных диапазонов IP, оставляя внутренние подсети домена вне блокировки. Это останавливает поддельные внешние запросы (вызывающие отражение), сохраняя работу внутренних клиентов. Делается это через настройки Области (Scope) правила, описанные ниже.

Тот же принцип ограничения области применим к контроллерам домена только для чтения (RODC).

Создание правила брандмауэра (блокировка входящего UDP 389)

Откройте Брандмауэр Windows и выберите Дополнительные параметры в левом боковом меню:

Выберите Входящие правила в левом боковом меню:

Нажмите Действие → Новое правило... в верхнем меню:

Откроется мастер создания правила. Выберите тип правила Для порта и нажмите Далее >:

На следующей странице выберите UDP, затем в поле Конкретные локальные порты введите 389 и нажмите Далее >:

На следующей странице выберите Блокировать соединение и нажмите Далее >:

Наконец, задайте правилу имя, например UDP LDAP block, и нажмите Готово:

То же правило можно создать через PowerShell, что удобно для скриптов или применения на нескольких серверах:

New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP)" -Direction Inbound -Protocol UDP -LocalPort 389 -Action Block

Внимание: На контроллере домена не останавливайтесь на этом. Приведённое выше правило блокирует UDP 389 со всех источников, что нарушит поиск контроллера домена для внутренних клиентов. Необходимо ограничить его область (следующий шаг).

Ограничение области правила (обязательно на контроллере домена)

После создания правила откройте его Свойства и перейдите на вкладку Область (Scope). В разделе Удалённый IP-адрес выберите Указанные IP-адреса и добавьте внешние или недоверенные диапазоны, которые вы хотите заблокировать. Не добавляйте сюда внутренние подсети домена — любой диапазон, указанный в «Удалённый IP-адрес», — это диапазон, который правило будет блокировать, поэтому указание внутренних подсетей заблокирует ваших же клиентов. Параметр Локальный IP-адрес оставьте Любой IP-адрес.

Таким образом блокировка применяется только к указанным вами недоверенным внешним источникам, а внутренние клиенты (не указанные в списке) остаются незатронутыми.

В PowerShell ту же область можно задать встроенным ключевым словом Internet. Ключевое слово Internet охватывает удалённые адреса, которые брандмауэр Windows классифицирует как внешние, исключая локальный компьютер, петлевой интерфейс (loopback) и типичные диапазоны локальной сети. Это блокирует внешний трафик, оставляя внутренних клиентов незатронутыми:

New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP) from Internet" -Direction Inbound -Protocol UDP -LocalPort 389 -RemoteAddress Internet -Action Block -Profile Public,Private

На правильно настроенном контроллере домена активный профиль брандмауэра обычно — Доменный. Ограничение правила профилями Публичный и Частный не даёт ему влиять на обычный доменный трафик. На контроллере домена всё же безопаснее явно задать внутренние подсети в Области правила, а не полагаться только на ключевое слово Internet — если в вашей сети используются нестандартные частные диапазоны, они могут быть классифицированы неверно; в этом случае перечислите внутренние диапазоны вручную и заблокируйте всё остальное.

Проверка результата

Внимание: Не используйте Test-NetConnection для проверки UDP 389 — он проверяет только TCP-соединения и даст вводящие в заблуждение результаты для UDP.

Самый прямой способ убедиться, что сервер по-прежнему отвечает на CLDAP-запросы, — отправить корректный LDAP-пинг с клиента, присоединённого к домену:

nltest /ping /server:DC_NAME

Это отправляет корректно сформированный CLDAP-запрос и сообщает ответ. Замените DC_NAME именем вашего контроллера домена.

В качестве дополнительной проверки можно использовать PortQry (бесплатную консольную утилиту Microsoft) с другого компьютера:

portqry -n SERVER_NAME -p UDP -e 389

В зависимости от ответа PortQry может сообщить LISTENING или FILTERED. Учтите, что PortQry отправляет пробный пакет, а не полноценный CLDAP LDAP-пинг, и служба CLDAP может не распознать его как корректный запрос, поэтому может выдать FILTERED, даже когда порт открыт. По этой причине считайте nltest /ping основным тестом, а PortQry — грубой вспомогательной проверкой.

На контроллере домена также убедитесь, что поиск домена по-прежнему работает для внутренних клиентов:

nltest /dsgetdc:example.com

Замените example.com именем вашего домена. Успешный ответ означает, что клиенты по-прежнему могут находить контроллер домена. Имейте в виду, что сам по себе успешный dsgetdc не доказывает работу CLDAP по UDP, поскольку DC Locator может переходить на DNS-запросы и LDAP по TCP, если CLDAP недоступен, в зависимости от выполняемой операции — именно поэтому проверка nltest /ping выше является более прямым тестом.

Дополнительные рекомендации

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

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

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

Итог: когда блокировка UDP 389 уместна?

Сервер не является контроллером домена → действий не требуется (UDP 389 не слушает).
Контроллер домена за брандмауэром, не доступен из интернета → действий не требуется; держите его вне публичного интернета.
Контроллер домена, доступный из интернета → ограничьте область правила так, чтобы оно блокировало внешние источники, оставляя незатронутыми доверенные внутренние подсети.