Блокування 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 не слухає).
Контролер домену за брандмауером, не доступний з інтернету → дій не потрібно; тримайте його поза публічним інтернетом.
Контролер домену, доступний з інтернету → обмежте область правила так, щоб воно блокувало зовнішні джерела, залишаючи незачепленими довірені внутрішні підмережі.