MFA недостатньо: сім інженерних уроків із захисту RDP у Windows Server

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Кирило Виноградов, я розробник Lira RDP Security у Vyvick Engineering. Цей матеріал буде корисний системним адміністраторам, DevOps/SRE-інженерам і MSP-командам, які підтримують Windows Server та регулярно мають справу з RDP.

Одразу зафіксую конфлікт інтересів: це не незалежний огляд продукту. Я не збираюся доводити, що RDP варто відкривати в інтернет або що одна консоль розв’язує всі проблеми. Хочу розібрати інше: чому задача «додаймо MFA до RDP» дуже швидко перетворюється на роботу з журналами Windows, Firewall, сертифікатами, відмовостійкістю та відновленням доступу.

RDP важко назвати новою технологією, але для адміністрування Windows Server він досі зручний і в багатьох середовищах нікуди не зник. Проблеми починаються, коли віддалений доступ стає доступним ззовні.

Зміна стандартного порту відсікає частину випадкового шуму, але не є захистом від сканування. Складний пароль допомагає проти простого перебору, але не рятує, якщо облікові дані вже вкрадені. MFA зменшує ризик входу з викраденим паролем, проте не зупиняє потік невдалих авторизацій. Firewall може заблокувати джерело, але нічого не знає про те, хто насправді вводить пароль.

Під час роботи над Lira ми поступово дійшли висновку: захист RDP — не одна функція, а ланцюжок контролів. Нижче — сім уроків, які найбільше вплинули на наш підхід.

1. Event ID — це ще не інцидент

Публічно доступний RDP-сервер доволі швидко починає отримувати спроби входу. На одному сервері ситуацію ще можна перевірити через Event Viewer або PowerShell. Коли серверів десятки, проблема вже не у відсутності даних, а у відсутності контексту.

Windows реєструє невдалі входи як події 4625, а успішні — як 4624. Для віддаленого інтерактивного входу корисно також дивитися на Logon Type 10. Але якщо просто скласти всі ці записи в одну велику таблицю, оператор отримає не систему виявлення, а ще один Event Viewer — тільки в браузері.

Під час розслідування інженеру зазвичай потрібно відповісти на значно конкретніші запитання:

• який саме сервер отримує спроби;
• коли почалася активність;
• які імена користувачів перебирають;
• скільки спроб надійшло з однієї адреси;
• чи належить адреса офісу, VPN або віддаленому адміністратору;
• чи спрацювало правило блокування;
• чи був після серії помилок успішний вхід.

Окрема подія 4625 не відповідає на запитання, чи бачимо ми атаку. Причиною може бути сканер, але так само — старий пароль у збереженому RDP-підключенні, служба, запланована задача або звичайна помилка адміністратора.

Тому одиницею аналізу для нас став не Event ID, а епізод автентифікації: сервер, користувач, адреса джерела, час, кількість спроб і результат застосованого правила. Це невелика зміна у формулюванні задачі, але саме вона визначає, чи буде консоль допомагати інженеру, чи просто накопичувати записи.

2. Блокування має виконуватися там, куди приходить трафік

Найочевидніша реакція на серію невдалих входів — заблокувати IP-адресу. У нашому випадку такі правила застосовуються локально через Windows Firewall. Блокування може мати строк дії або залишатися активним до ручного рішення адміністратора.

Чому не тримати всю логіку лише в хмарній консолі? Тому що центральний сервіс не повинен бути критичною ланкою для вже застосованого мережевого правила. Якщо агент тимчасово втратить зв’язок із порталом, локальне правило Windows Firewall продовжить працювати.

По суті, тут корисно розділяти control plane та enforcement plane. Портал зберігає політику, контекст і рішення оператора. Сервер виконує блокування у власному Firewall. За втрати зв’язку нові команди та події можуть затриматися, але чинний захист не зникає разом із зеленою крапкою в консолі.

Цей принцип стосується не лише RDP. Якщо керована система перестає виконувати вже застосовану політику одразу після втрати control plane, ми отримуємо не відмовостійкість, а приховану залежність від мережі та SaaS-сервісу.

3. Автоматичне блокування треба починати зі сценарію self-lockout

IP-адреса — це джерело трафіку, а не надійна ідентичність користувача. За однією зовнішньою адресою можуть стояти весь офіс, VPN-шлюз або кілька адміністраторів через NAT. Тому агресивне автоблокування легко перетворює атаку на інцидент, який команда створила собі сама.

Типові хибні спрацювання виглядають буденно:

• адміністратор кілька разів помилився в паролі;
• mstsc продовжує надсилати старі збережені облікові дані;
• служба або задача запускається під обліковим записом зі зміненим паролем;
• кілька людей виходять через одну зовнішню адресу.

Перед увімкненням автоматичного блокування ми радимо додати до allowlist щонайменше офісну зовнішню адресу, VPN-шлюз, захищений jump host і резервний канал адміністрування. Але самого списку недостатньо — сценарій треба перевірити.

Мінімальний тест, який варто провести до продакшену:

1. Відкрити резервну адміністративну сесію або перевірити out-of-band доступ.
2. Додати довірені адреси до allowlist.
3. З тестової адреси навмисно перевищити поріг невдалих входів.
4. Переконатися, що правило справді з’явилося у Windows Firewall.
5. Перевірити автоматичне завершення тимчасового блокування та ручне розблокування.
6. Повторити перевірку за тимчасово недоступного порталу.

Налаштування в інтерфейсі ще не означає, що recovery-сценарій працює. Перевіряти це після втрати єдиного адміністративного доступу вже запізно.

4. MFA і мережеве блокування розв’язують різні задачі

У нашій моделі пароль Windows не передається до порталу Lira і не зберігається там. Основні облікові дані перевіряє сама операційна система на сервері, а для визначених користувачів додається TOTP як другий фактор.

Спрощено послідовність виглядає так:

1. Користувач вводить ім’я та пароль Windows.
2. Windows перевіряє основні облікові дані.
3. Система визначає, чи потрібна MFA для цього користувача.
4. Користувач вводить одноразовий TOTP-код.
5. Після успішної перевірки Windows завершує вхід.

Найскладніша частина тут не форма із шістьма цифрами. MFA-виклик потрібно пов’язати з конкретним користувачем, сервером і сесією. Код не має прийматися повторно в тому самому часовому вікні. Виклик повинен мати обмежений строк дії, а нова RDP-сесія після невдалої спроби не повинна успадковувати попередній результат перевірки.

Також варто заздалегідь відповісти на неприємне питання: що відбувається, коли сервіс перевірки другого фактора недоступний? Fail-open зберігає доступність, але послаблює контроль. Fail-closed краще тримає політику, проте може відрізати адміністраторів під час збою. Універсальної відповіді немає, але режим має бути явним, задокументованим і перевіреним разом із резервним доступом.

При цьому MFA не замінює блокування. Навіть якщо зловмисник не пройде другий фактор, він усе одно може безперервно створювати невдалі спроби входу. І навпаки: Firewall зменшує шум від конкретного джерела, але не допоможе, якщо хтось входить із дозволеної мережі та має правильний пароль.

Ми також не розглядаємо вимкнення Network Level Authentication як нормальний спосіб спростити інтеграцію. NLA переносить автентифікацію до створення повної віддаленої сесії, і Microsoft рекомендує залишати його увімкненим у більшості середовищ.

5. TLS-сертифікат — це не косметика для RDP-клієнта

Майже кожен, хто працював із RDP, бачив попередження про недовірений сертифікат. На тестовому сервері його закривають один раз, на робочому — ще раз, а потім користувач перестає перевіряти ім’я сервера та видавця взагалі.

Так формується небезпечна звичка: попередження є завжди, отже воно нічого не означає.

Коректний TLS потрібен не лише для шифрування каналу. Він дає клієнту можливість перевірити, що підключення встановлюється саме з очікуваним сервером.

Тут часто плутають DNS-ім’я, внутрішню адресу й зовнішній порт. Наприклад, користувач підключається до:

rdp.example.com:27515

Зовнішній порт 27515 може перенаправлятися на локальний 3389, але порт не входить до імені в сертифікаті. Сертифікат має відповідати rdp.example.com, а не rdp.example.com:27515.

На Windows Server недостатньо просто імпортувати сертифікат. Його потрібно додати до Personal store облікового запису комп’ютера та прив’язати thumbprint до RDP listener. У Windows ця прив’язка зберігається у властивості SSLCertificateSHA1Hash класу Win32_TSGeneralSetting.

Поточний thumbprint listener можна перевірити без зміни конфігурації:

Get-CimInstance -Namespace root/cimv2/terminalservices `
  -ClassName Win32_TSGeneralSetting `
  -Filter "TerminalName='RDP-tcp'" |
  Select-Object TerminalName, SSLCertificateSHA1Hash

Після цього окремо варто перевірити, що сертифікат із цим thumbprint справді є у Cert:\LocalMachine\My, має потрібне ім’я, приватний ключ і достатній строк дії. Інакше в консолі може бути «сертифікат встановлено», а listener продовжить використовувати інший або самопідписаний.

Для автоматичного випуску та поновлення сертифікатів зручно використовувати ACME і DNS-01. Цей challenge не потребує відкривати HTTP-порт на RDP-сервері. _acme-challenge можна делегувати через CNAME або NS до окремої DNS-зони для валідації.

У такої автоматизації є своя межа. Постійний CNAME сам по собі не випускає сертифікат. Потрібні успішна ACME-перевірка, імпорт нового сертифіката до Windows, доступ RDS до приватного ключа, правильна прив’язка thumbprint і перевірка після поновлення. Окремо варто обмежувати права DNS API: повні облікові дані від основної DNS-зони на кожному сервері створюють зайвий ризик.

6. Heartbeat агента не доводить, що телеметрія повна

Цей нюанс легко пропустити під час проєктування консолі. Агент регулярно надсилає heartbeat, інтерфейс показує сервер online — здається, що все працює.

Але heartbeat відповідає лише на одне запитання: чи може агент зараз зв’язатися з порталом. Він не доводить, що колектор читає потрібний журнал, що черга не накопичується, а всі події вже передані й оброблені.

Наприклад, агент може залишатися online, коли:

• колектор подій зупинився;
• змінилися права доступу до журналу;
• локальна черга зростає швидше, ніж відбувається передавання;
• портал приймає heartbeat, але відхиляє частину пакетів із подіями;
• остання оброблена подія відстає від поточного часу на години.

Тому статус агента краще розкладати щонайменше на кілька окремих сигналів: останній heartbeat, час останньої прочитаної події, час останньої доставленої події, розмір або вік черги та остання помилка колектора.

Зелений індикатор без цих даних створює хибне відчуття контролю. Найгірший момент для виявлення такого розриву — розслідування інциденту, коли команда раптом бачить порожнє вікно в історії.

7. Захист RDP швидко перетинається з експлуатацією Windows Server

Спочатку ми намагалися тримати фокус лише на входах, блокуваннях і MFA. Але під час реального розслідування поруч постійно з’являлися інші запитання:

• чи отримував сервер оновлення;
• чи увімкнений Microsoft Defender;
• чи не заповнений системний диск;
• чи працюють критичні служби;
• чи не завершується TLS-сертифікат;
• чи актуальна версія агента;
• хто з локальних користувачів досі має право входу.

Це не означає, що інструмент захисту RDP автоматично має стати універсальною RMM-платформою. Навпаки, межу продукту потрібно називати чесно. Велика RMM охоплює більше операційних систем, пристроїв, інтеграцій і сценаріїв автоматизації. Наш фокус вужчий: Windows Server, RDP і ті операційні сигнали, без яких важко зрозуміти стан віддаленого доступу.

Для MSP до цього додається ще одна вимога — ізоляція клієнтів. Централізація корисна лише тоді, коли сервери, події, політики та права операторів не змішуються між організаціями. Одна консоль без чіткої tenant boundary створює новий ризик замість того, щоб зменшити старі.

Критичні операції також не варто робити непомітними. Увімкнення MFA, заміна сертифіката, постійне блокування або відновлення доступу мають залишати зрозумілий audit trail: хто виконав дію, для якого сервера, з якими параметрами та яким результатом. Автоматизація корисна доти, доки інженер розуміє, що система збирається зробити і як це відкотити.

Що я б радив зробити навіть без окремого продукту

Якщо прямого RDP-доступу можна уникнути, краще винести його за VPN, RD Gateway, jump host або принаймні обмежити дозволеними адресами. Якщо RDP усе ж доступний ззовні, базовий набір дій для мене виглядає так:

• не сприймати зміну порту як контроль безпеки;
• залишити NLA увімкненим;
• додати MFA для адміністративних облікових записів;
• контролювати невдалі входи разом із користувачем, джерелом і сервером;
• підготувати allowlist та резервний спосіб відновлення доступу;
• стежити за Windows Firewall, Defender і оновленнями;
• регулярно переглядати локальних користувачів і права на RDP;
• використовувати довірений TLS-сертифікат і контролювати його прив’язку до listener;
• окремо моніторити не лише heartbeat, а й відставання колектора;
• перевірити весь сценарій до інциденту.

Останній пункт для мене найважливіший. Без тесту ми маємо не захист, а припущення про те, як він повинен працювати.

Висновок

Під час роботи над захистом RDP найбільше складнощів виникло не через окрему технологію. TOTP, Windows Firewall, журнали подій і TLS-сертифікати давно відомі. Складність з’являється на межах між ними.

Windows перевіряє пароль. MFA знижує ризик використання викрадених облікових даних. Firewall обмежує джерела атак. TLS підтверджує ідентичність сервера. Агент збирає локальний стан. Центральна консоль додає контекст і розмежовує доступ. Recovery-процедура залишає адміністратору шанс виправити невдалу автоматизацію.

Жоден із цих елементів не є повним захистом сам по собі. Практична цінність з’являється тоді, коли вони працюють разом, не приховують свій реальний стан і не забирають у людини контроль над критичними діями.

Цікаво, як ви розв’язуєте дві найнеприємніші задачі у своїх Windows-середовищах: fail-open чи fail-closed для MFA та автоматичне поновлення сертифікатів саме для RDP listener?