Windows: Базова конфігурація безпеки, що зупиняє 80% атак RDP

February 20, 2026 • February 20, 2026 • Читання: 5 хв • Views: 1

Було корисно?

Вас не зламав якийсь чарівник. Вас зламав відкритий в інтернеті порт RDP, застарілий локальний пароль адміністратора й логи, на які ніхто не дивиться, поки страхова не попросить.

RDP досі залишається основним інструментом віддаленого доступу в багатьох Windows-інфраструктурах. Це також один із найгучніших магнітів для атак у публічному інтернеті. Хороша новина: більшість атак на RDP можна зупинити за допомогою базової конфігурації, яка нудна, строгa та вимірювана. Якщо зробити все правильно, ви спатимете спокійніше — і ваш телефон на чергуванні перестане видавати той самий гудок «нова хвиля підбору облікових даних».

Модель загрози (що реально на вас нападає)

Будьмо чесними щодо того, як «атаки на RDP» виглядають у реальному продакшені:

Масове сканування + brute force: Автоматизоване сканування знаходить TCP/3389 (або ваш «хитрий» альтернативний порт) та пробує звичні імена користувачів і витеклі паролі. Це більшість комерційного шуму.
Password spraying: Повільні спроби по багатьох облікових записах, щоб уникнути блокувань. Це те, що б’є по організаціях із слабкими політиками й без MFA.
Повторне використання облікових даних: Дійсні облікові дані з фішингу, шкідливого ПЗ або попередніх витоків. Для RDP одного працездатного облікового запису часто достатньо, щоб закріпитися.
Збирання неправильних конфігурацій: NLA вимкнено, старі налаштування TLS, слабкі практики локальних адміністраторів, широкі правила вхідного брандмауера, «тимчасовий» доступ для вендора, що став постійним.
Ескалація після входу: Потрапивши всередину, нападники дамплять облікові дані, рухаються латерально, вимикають EDR і починають шифрування. RDP — лише передні двері; будинок все ще потребує внутрішніх замків.

Базова конфігурація в цій статті націлена на ту частину, що спричиняє більшість інцидентів RDP: експозиція в інтернеті + слабка аутентифікація + слабка політика + відсутність моніторингу. Це ті самі 80%. Інші 20% — це те, через що команди безпеки залишаються потрібними.

Цікаві факти та історичний контекст (бо шаблони повторюються)

RDP існує з кінця 1990-х (ера Windows NT 4.0 Terminal Server Edition), достатньо давно, щоб у кожного нападника й захисника була м’язова пам’ять щодо нього.
TCP/3389 став «новим 22-м» для Windows-інфраструктур: стандартний порт для віддаленого адміністрування, який безперервно сканується ботами, незалежно від галузі.
NLA (Network Level Authentication) був введений, щоб зменшити поверхню атаки перед аутентифікацією, вимагаючи аутентифікацію перед створенням повної сесії.
Credential stuffing увійшов у мейнстрім, коли дампи паролів стали регулярними, а користувачі почали повторно використовувати паролі. RDP безпосередньо виграв від цієї поганої звички.
BlueKeep (CVE-2019-0708) став тривожним дзвінком: вразливості RDP до аутентифікації можуть бути червоточними. Навіть якщо ви запатчилися, ви зрозуміли: «відкритий RDP» — це свідомий вибір способу життя.
RD Gateway існує тому, що підприємства жорстко навчилися: прямий RDP з інтернету породжує інциденти, а не є стратегією доступу.
Windows Event ID для телеметрії входу стабільні роками (наприклад, 4624/4625), що добре: ваше виявлення і реагування не повинні залежати від новинок.
Політики блокування облікових записів широко використовувалися задовго до сучасного MFA, але нападники адаптувалися з методом spraying. Тому блокування потрібне, але не достатнє.
Базові конфігурації безпеки стали продуктованими (Microsoft security baselines, CIS Benchmarks), бо «племінні знання адміністраторів» не масштабуються й провалюються на аудитах.

Базова конфігурація: кілька рішень, що ламають більшість атак RDP

Це частина з думкою. Ви хочете зменшити поверхню атаки, зробити аутентифікацію дорогою для нападників і зробити зловживання очевидним у логах. Робіть ці кроки в порядку пріоритету.

1) Припиніть експонування RDP в публічний інтернет

Якщо зробити лише одну річ — зробіть це. Прямий вхідний RDP з інтернету — це як залишити вхідні двері офісу відкритими, бо «реєстраторка зазвичай тут».

Виберіть один із цих підходів:

VPN + обмежений RDP: дозволяйте RDP лише з адресного простору VPN. Чисто, звично, ефективно.
RD Gateway: термінуєте HTTPS зовні; RDP прокситься. Ліпше для керованого доступу, політик і аудиту.
Privileged Access Workstations (PAW) + jump host: адміністратори RDP лише з контрольованої робочої станції до jump box, потім далі. Дратує. Правильно.
SSO-базований віддалений доступ: якщо є — добре. Все одно обмежуйте вхідний RDP на брандмауері.

Що не робити: «Ми поміняли порт з 3389 на 53389.» Це не безпека; це змушує боти зробити ще один SYN-скан.

2) Вимагайте NLA і сучасний TLS

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

Також: вимикайте параметр «Allow connections only from computers running Remote Desktop with Network Level Authentication» лише якщо вам подобається пояснювати це під час розслідування інциденту. Вам це не потрібно.

3) Застосуйте MFA для шляхів віддаленого адміністрування

RDP сам по собі не робить MFA. Ви впроваджуєте MFA через шлях доступу:

VPN з MFA
RD Gateway з інтеграцією MFA
Умовний доступ / відповідність пристрою, де застосовано

MFA не виправить жахливу сегментацію мережі, але зупиняє сумну кількість інцидентів «облікові дані спрацювали — гра закінчилась».

4) Використовуйте сильну політику облікових записів: блокування, довжина пароля та відсутність спільних адміністраторів

Спільний локальний адміністратор на серверах досі болісно поширений. Це також шлях, як один зламаний хост стає сорока. Використовуйте LAPS/Windows LAPS, щоб кожна машина мала унікальний локальний пароль адміністратора.

Встановіть розумні пороги блокування. Розумійте компроміс: блокування може стати вектором DoS, якщо у вас багато публічної експозиції (ще одна причина прибрати публічну експозицію).

5) Обмежте, хто може підключатися по RDP (і видаліть решту)

Не давайте «Domain Users» або широким групам право RDP. Використовуйте спеціальну групу, принцип найменших привілеїв і тримайте її малою. Якщо потрібен доступ для вендора — створюйте групу для вендора, доступ із часовими обмеженнями й аудитуйте це серйозно.

6) Загартуйте кінцеву точку: Defender/EDR, патчинг і зменшення латерального руху

Атаки через RDP часто лише початок. Потрапивши на хост, нападники намагаються ескалувати й рухатися далі. Ускладніть їм життя:

Регулярно патчіть (особливо компоненти, пов’язані з RDP і стеком автентифікації Windows)
Вимикайте застарілі протоколи (де це можливо)
Блокуйте вхідний SMB з недовірених сегментів
Використовуйте правила Windows Firewall, які є явними й обмеженими

7) Логуйте так, ніби це знадобиться о 3:00 ранку

RDP без логування — це будинок з привидами: ви чуєте кроки, але не можете нічого довести. Збирайте:

Події входу з Security (успішні/невдалі, тип входу, IP джерела)
Журнали TerminalServices RemoteConnectionManager та LocalSessionManager
Логи брандмауера (принаймні на межі; бажано — на хості теж)

Цитата, яка має бути на стіні кожної опс-команди:

«Надія — не стратегія.» — Джин Кранц

Жарт №1: Зміна порту RDP — це як одягнути серверу фальшиві вуса й назвати його «StealthHost01». Інтернет не ведеться.

Практичні завдання (команди, виводи та рішення)

Ці команди розраховані на запуск у Windows (локально або через віддалене управління). Позначка командного рядка — просто конвенція шелу — не ускладнюйте.

Завдання 1: Чи ввімкнено RDP на цьому хості?

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
    fDenyTSConnections    REG_DWORD    0x0

Що означає вивід: 0x0 означає, що з’єднання RDP дозволені. 0x1 означає заборонені.

Рішення: Якщо ця машина не має бізнес-потреби в RDP, встановіть заборону і видаліть будь-які вхідні правила брандмауера. Якщо має — продовжуйте загартовувати.

Завдання 2: Чи вимагається NLA?

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
    UserAuthentication    REG_DWORD    0x1

Що означає вивід: 0x1 зазвичай вказує, що NLA обов’язкове. 0x0 — не обов’язкове.

Рішення: Якщо 0x0, увімкніть NLA, якщо тільки у вас немає конкретної вимоги старого клієнта — і якщо є, виправте цю вимогу. Не закріплюйте її як виняток.

Завдання 3: На якому порті слухає RDP (і чи він відкритий)?

cr0x@server:~$ netstat -ano | findstr ":3389"
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1148
  TCP    [::]:3389              [::]:0                 LISTENING       1148

Що означає вивід: Хост слухає на 3389 на всіх інтерфейсах; сокет належить PID 1148.

Рішення: Якщо хост слухає на публічному інтерфейсі, ви мусите обмежити вхідні мережеві шляхи (VPN/RD Gateway/прикордонний брандмауер) і налаштувати правила брандмауера на хості. «Ми будемо моніторити» — це не контроль.

Завдання 4: Підтвердіть налаштування вхідних правил Windows Firewall для RDP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Get-NetFirewallAddressFilter | Select-Object Name,RemoteAddress"
Name                           RemoteAddress
----                           -------------
RemoteDesktop-UserMode-In-TCP   Any
RemoteDesktop-UserMode-In-UDP   Any

Що означає вивід: Вбудовані правила RDP дозволяють з Any — зручна за замовчуванням, але не безпекова налаштування.

Рішення: Змініть RemoteAddress на ваші підмережі VPN або IP jump host-ів. Якщо ви не можете чітко назвати дозволені діапазони, ви не готові дозволяти RDP.

Завдання 5: Обмежити RDP відомими підмережами джерел (брандмауер хоста)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'Remote Desktop - User Mode (TCP-In)' -RemoteAddress 10.8.0.0/24,10.9.0.0/24; Get-NetFirewallRule -DisplayName 'Remote Desktop - User Mode (TCP-In)' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
RemoteAddress
-------------
{10.8.0.0/24, 10.9.0.0/24}

Що означає вивід: Тільки клієнти з цих підмереж можуть підключатися по RDP TCP.

Рішення: Якщо ви не можете обмежити доступ до відомих джерел, не експонуйте RDP. Спершу впровадьте VPN або RD Gateway.

Завдання 6: Перевірте, хто має дозвіл на вхід по RDP

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalGroupMember -Group 'Remote Desktop Users' | Select-Object Name,ObjectClass"
Name                      ObjectClass
----                      ----------
CONTOSO\IT-RemoteAdmins    Group

Що означає вивід: У локальну групу «Remote Desktop Users» додана лише вказана група.

Рішення: Якщо ви бачите широкі групи або окремих користувачів, доданих ad hoc, звужуйте. Використовуйте виділені групи. Видаліть винятки, які існують лише тому, що комусь не захотілося створювати запит на доступ.

Завдання 7: Перевірте політику блокування облікових записів (доменну або локальну)

cr0x@server:~$ net accounts
Force user logoff how long after time expires?:       Never
Minimum password age (days):                          1
Maximum password age (days):                          90
Minimum password length:                              14
Length of password history maintained:                24
Lockout threshold:                                    10
Lockout duration (minutes):                           15
Lockout observation window (minutes):                 15

Що означає вивід: Видно довжину пароля, історію та налаштування блокувань. Їх можуть перевизначати політики домену.

Рішення: Якщо поріг блокування = 0 (ніколи не блокується) або довжина пароля коротка — виправте політику. Якщо ви маєте експозицію в інтернеті — також закрийте експозицію; самі блокування — лише пластир.

Завдання 8: Перевірте політику аудиту для подій входу

cr0x@server:~$ auditpol /get /subcategory:"Logon"
System audit policy
Category/Subcategory                      Setting
Logon                                    Success and Failure

Що означає вивід: Події входу реєструються як успішні, так і невдалі.

Рішення: Якщо не «Success and Failure», увімкніть це. Ви не зможете розслідувати те, чого не залоговано.

Завдання 9: Знайдіть невдалі спроби входу по RDP у Security логу (останні 50)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Select-Object TimeCreated,@{n='User';e={$_.Properties[5].Value}},@{n='Ip';e={$_.Properties[19].Value}} | Format-Table -Auto"
TimeCreated             User               Ip
-----------             ----               --
1/28/2026 2:11:05 AM    Administrator      203.0.113.44
1/28/2026 2:10:58 AM    admin              203.0.113.44
1/28/2026 2:10:52 AM    test               203.0.113.44
1/28/2026 2:10:45 AM    svc_backup         203.0.113.44
1/28/2026 2:10:39 AM    user               203.0.113.44

Що означає вивід: Подія 4625 показує невдалі логіни; IP вказує джерело. Публічні IP тут — поганий знак, якщо ви вважали RDP приватним.

Рішення: Якщо джерела не ваші VPN/jump-діапазони, ваша історія з брандмауером неправильна. Блокуйте на межі й на хості. Потім шукайте будь-які успішні входи з того ж джерела.

Завдання 10: Знайти успішні RDP входи (Logon Type 10) у Security логу

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20 | Where-Object { $_.Properties[8].Value -eq 10 } | Select-Object TimeCreated,@{n='Account';e={$_.Properties[5].Value}},@{n='Ip';e={$_.Properties[18].Value}} | Format-Table -Auto"
TimeCreated             Account            Ip
-----------             -------            --
1/27/2026 9:14:22 PM    CONTOSO\j.smith    10.8.0.24

Що означає вивід: Logon Type 10 зазвичай вказує RemoteInteractive (RDP). IP джерела повинен відповідати очікуваному шляху керування.

Рішення: Будь-який успішний RDP вхід з несподіваного IP — інцидент до повного з’ясування. Спершу ізолюйте, потім дискутуйте.

Завдання 11: Перевірити operational-логи TerminalServices для спроб підключення

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -MaxEvents 5 | Select-Object TimeCreated,Id,Message | Format-List"
TimeCreated : 1/28/2026 2:12:01 AM
Id          : 1149
Message     : Remote Desktop Services: User authentication succeeded: CONTOSO\j.smith

TimeCreated : 1/28/2026 2:11:55 AM
Id          : 1149
Message     : Remote Desktop Services: User authentication succeeded: CONTOSO\it-admin

Що означає вивід: Ці логи допомагають корелювати аутентифікаційні події RDP із поведінкою сесії; вони корисні, коли Security логи шумлять.

Рішення: Якщо цей лог вимкнений або не збирається централізовано — виправте це. Це дешевий сигнал із великою цінністю.

Завдання 12: Перевірити статус служби RDP

cr0x@server:~$ sc query TermService
SERVICE_NAME: TermService
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Що означає вивід: Remote Desktop Services працює. Якщо вона працює на машинах, які не повинні приймати RDP — це дрейф.

Рішення: Для неадміністративних робочих станцій/серверів розгляньте відключення служби RDP та видалення дозволів замість того, щоб залишати її «на випадок».

Завдання 13: Підтвердити, що не приймаються старі, слабкі шари безпеки RDP

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
    SecurityLayer    REG_DWORD    0x2

Що означає вивід: Значення відрізняються залежно від конфігурації; зазвичай бажано TLS, а не відкат до «RDP Security Layer». (Точне відображення може змінюватися залежно від збірки та політики.)

Рішення: Якщо бачите налаштування, що дозволяють відкат до слабших шарів безпеки — змусьте політику використовувати тільки TLS і видаліть винятки. Винятки — це шлях, яким «тимчасова сумісність» стає «постійною експозицією».

Завдання 14: Перевірити логування Windows Defender Firewall (видимість на хості)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Select-Object Name,LogAllowed,LogBlocked,LogFileName | Format-Table -Auto"
Name    LogAllowed LogBlocked LogFileName
----    ---------- ---------- -----------
Domain  False      True       %systemroot%\system32\logfiles\firewall\pfirewall.log
Private False      True       %systemroot%\system32\logfiles\firewall\pfirewall.log
Public  False      True       %systemroot%\system32\logfiles\firewall\pfirewall.log

Що означає вивід: Блоковані з’єднання логуються. Дозволені — ні (часто нормально; логування всього створює шум).

Рішення: Якщо ви розбираєтеся з експозицією або атаками, логування блокованих підключень допомагає підтвердити, що правила працюють. Якщо логи ніде не увімкнені — ви працюєте в темряві.

Завдання 15: Перевірити доступність 3389 на периметрі з Linux jump (зовнішній погляд)

cr0x@server:~$ nmap -Pn -p 3389 198.51.100.10
Starting Nmap 7.80 ( https://nmap.org ) at 2026-01-28 02:14 UTC
Nmap scan report for 198.51.100.10
Host is up (0.020s latency).

PORT     STATE SERVICE
3389/tcp open  ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 0.45 seconds

Що означає вивід: Хост доступний на 3389 з місця, звідки ви запускали скан. Якщо це публічний інтернет або недовірена мережа — у вас проблема.

Рішення: Закрийте це на прикордонному брандмауері/групі безпеки. Не покладайтеся лише на брандмауер хоста. Захист у кілька шарів — це не лозунг; це ваша майбутня історія інциденту.

Завдання 16: Перелічити активні RDP сесії (хто на машині?)

cr0x@server:~$ quser
 USERNAME              SESSIONNAME        ID  STATE   IDLE TIME  LOGON TIME
 j.smith               rdp-tcp#12          2   Active          .  1/27/2026 9:14 PM
 it-admin              rdp-tcp#13          3   Disc            8  1/28/2026 1:58 AM

Що означає вивід: Ви бачите активні та відключені сесії. Відключені сесії можуть зберігатися і використовуватися у зловмисних цілях, якщо їх не контролювати.

Рішення: Якщо бачите несподіваних адміністраторів або довго відключені сесії — розслідуйте й розгляньте встановлення таймаутів сесій і політик «вийти відключені сесії».

Завдання 17: Підтвердити, що машина не в профілі «Public» (поширено в образах для хмари)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object InterfaceAlias,NetworkCategory"
InterfaceAlias NetworkCategory
-------------- ---------------
Ethernet0       DomainAuthenticated

Що означає вивід: DomainAuthenticated зазвичай означає, що застосовуються доменні політики й профілі брандмауера відповідні.

Рішення: Якщо несподівано Public, виправте ідентифікацію мережі та застосування профілів брандмауера; можливо, ви втрачаєте доменні GPO або застосовуєте неправильні правила.

Жарт №2: RDP в відкритому інтернеті — це безпековий еквівалент «ми зберігли паролі в електронній таблиці, але на прихованій вкладці». Нападники люблять приховані вкладки.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через хибне припущення

Компанія мігрувала частину Windows-серверів у хмарний VPC. Мережева команда клялася, що «нічого не публічне, якщо ми явно не зробили публічним». Звучить розумно. Насправді — ні.

Проектній команді потрібно було, щоб вендор зробив одноразову інсталяцію на старому сервері застосунку. Хтось додав тимчасове вхідне правило в security group, щоб дозволити TCP/3389 «з діапазону IP вендора». Той діапазон виявився ширшим, ніж хтось уявляв — бо вендор використовував обертовий пул, а в тікеті це переклалось у «просто дозволити звідусіль на цей час». Правило так і не прибрали. Ніхто не помітив, бо нічого не ламається. І «нічого не ламається» — це як ризик отримує підвищення.

Через два місяці Security лог заповнився невдалими спробами 4625 по локальних облікових записах. SOC помітив, але відніс до фонових інтернет-шумів. «RDP не публічний» — так звучала логіка. Компроміс відбувся через повторне використання пароля для локального адміністратора, який існував також на інших серверах. Нападник увійшов один раз, тихо перелічив мережу, зібрав креденшіали і пішов латерально, де RDP дозволявся внутрішньо.

Звіт про інцидент був суворий, але корисний. Основна помилка була не в «поганому паролі». Це було припущення, що середовище робить експозицію неможливою. Виправлення було рівно таким же різким: автоматизовані перевірки, які постійно верифікують, які хости доступні на 3389 ззовні мережі управління, плюс жорстке правило: весь RDP має йти через VPN або RD Gateway, примусово на межі й на хості.

Хибні припущення не оголошують себе вголос. Вони з’являються згодом у вигляді «неочікуваних входів» і календаря повних незручних зустрічей.

Міні-історія 2: Оптимізація, що обернулась проти

Одна команда опс вирішила зменшити кількість дзвінків до helpdesk, послабивши блокування облікових записів. Мотив: віддалені працівники часто помиляються з паролями, і блокування породжує чергу підтримки. Тож вони суттєво підняли поріг блокувань і скоротили тривалість блокування. Це назвали «підвищенням продуктивності». Воно справді підвищило продуктивність — для нападників.

Одночасно підключили підрядників і не захотіли видавати керовані пристрої. Підрядникам видали VPN-креденшіали (без MFA тоді) і сказали RDP на jump host. Jump host мав RDP відкритий для VPN-підмережі, що здавалося нормальним. Але VPN-підмережа була велика, спільна з партнерами і слабо моніторилася.

Потім прийшов password spraying. Не швидкий брутфорс, що тригерить алерти. Терпеливий, розподілений спрей по багатьох обліковках з багатьох VPN IP. З послабленими блокуваннями нападник мав багато часу в запасі. Зрештою потрапив підрядник з слабким паролем. Далі: RDP на jump host, потім внутрішні сервери, дамп кредитів.

Команда відмінила зміни блокування, впровадила MFA на VPN і сегментувала VPN-пули, щоб «підрядники» не плавали в тому ж океані, що й адміністратори. Урок не в тому, що блокування вирішують все. Урок в тому, що оптимізація для меншої кількості тикетів без розуміння поведінки загрози — це як платити за тишу безпеки.

Хороші операції зменшують рутину, не збільшуючи зону ураження. Якщо ваша оптимізація зменшує рутину та збільшує площу ураження — ви не оптимізували. Ви взяли в борг проблеми.

Міні-історія 3: Нудна, але правильна практика, що врятувала

Інша компанія мала вперту, майже старомодну практику: щоквартально вони проводили рев’ю доступів і рев’ю експозиції брандмауера. Не слайд-дек; реальне рев’ю з виконаними змінами й валідацією.

У них було правило: RDP — не метод доступу; це внутрішній протокол. Метод доступу — VPN з MFA, тільки з керованих пристроїв. Брандмауери хостів налаштовані приймати RDP лише з jump host-ів та невеликої адміністраторської VLAN. На додачу, прикордонний брандмауер мав загальну заборону на вхідний 3389. Якщо потрібен виняток — його потрібно було в письмовій формі пояснити двом командам, які люблять говорити «ні».

Однієї вихідної вони отримали алерт в SIEM про сплеск 4625 проти кількох адміністраторських обліковок на сервері, який не мав бути доступним, окрім адмін-VLAN. SRE на чергуванні перевірив логи брандмауера хоста і побачив заблоковані спроби з діапазону партнерської мережі. Це мало бути неможливо.

Виявилось, що мережева зміна випадково направила трафік партнерського діапазону в внутрішній сегмент, що мав доступ до сервера. Брандмауер хоста все одно заблокував спроби, і логи це довели. Виправили маршрут до того, як стався будь-який успішний вхід. Звіт про інцидент був коротким, нудним і приємним — найкращий тип. Запобіжний контроль спрацював, детективний контроль сказав правду, і відновлення було «змінити маршрут, закрити тикет».

Нудні практики не потрапляють на конференції. Вони просто тримають ваше ім’я поза повідомленнями про витоки.

Швидкий план діагностики (знайти вузьке місце швидко)

Це послідовність «ви на чергуванні, RDP поводиться дивно і хтось кричить». Мета — швидко визначити, чи проблема в експозиції, аутентифікації, політиках або ресурсних обмеженнях.

Перший крок: перевірте експозицію й шлях

Ззовні мережі управління, перевірте доступність 3389 (або вашого порту). Якщо він доступний публічно — це не «проблема з підключенням», це політичний провал.
На сервері, перевірте сокети, що слухають (netstat -ano) і область дії брандмауера (RemoteAddress не Any).
Підтвердіть шлях клієнта: чи підключаються користувачі через VPN або RD Gateway? Якщо вони не можуть відповісти — і ви не зможете.

Другий крок: перевірте аутентифікацію та політики

Чи вимагається NLA? Перевірте UserAuthentication і групові політики.
Чи відбуваються блокування облікових записів? Перевірте невдалі входи (4625), події блокування (4740 в доменних середовищах) і визначте, чи це помилка при введенні чи атака.
Чи застосовано MFA на шляху доступу (VPN/RD Gateway)? Якщо ні — вважайте, що облікові дані зрештою будуть відтворені.

Третій крок: перевірте стан служби й сесій

Перевірте стан TermService. Якщо вона зупинилася — чому (креш? патч? політика?).
Перевірте активні/відключені сесії (quser). Забагато сесій може погіршити роботу й маскувати зловживання.
Перевірте навантаження CPU й пам’яті (Task Manager/PerfMon). «Повільний» RDP часто — просто CPU-завантажена VM.

Четвертий крок: швидко шукати зловмисні наміри

Сплеск 4625 з несподіваних IP → трактуйте як атакувальний трафік; блокуйте на межі й на хості.
Будь-який 4624 Logon Type 10 з несподіваного IP → інцидент до з’ясування.
Корелюйте з operational-логами TerminalServices, щоб відокремити часову шкалу користувача/сесії.

Типові помилки: симптом → корінь проблеми → виправлення

1) «Ми відключили RDP, але він усе ще доступний»

Симптом: Порт 3389 все ще відкритий при скануванні; користувачі все ще можуть підключатися.

Корінь проблеми: Ви відключили підключення в одному місці (реєстр/UI), але лишили правила брандмауера або шлях через RD Gateway, або скануєте інший хост/NAT-ціль.

Виправлення: Перевірте на хості fDenyTSConnections, стан служби та правила брандмауера; перевірте на межі (security group/файрвол) і підтвердіть NAT-мапінги. Переконайтеся, що немає альтернативного слушателя або балансувальника, що форвардить.

2) «Ми увімкнули NLA, але старі клієнти не підключаються»

Симптом: Старі thin-клієнти або вбудовані системи перестали підключатися після змін.

Корінь проблеми: Клієнт не підтримує NLA/CredSSP вимоги.

Виправлення: Оновіть або замініть клієнтів. Якщо мусите підтримувати їх тимчасово, ізолюйте цільові хости, жорстко обмежте IP джерел і встановіть крайній термін. Не робіть виняток глобальним.

3) «RDP постійно блокує облікові записи»

Симптом: Користувачі регулярно блокуються; кількість звернень у службу підтримки зростає.

Корінь проблеми: Password spraying або збережені облікові дані (заплановане завдання, сервіс, змонтований диск), що повторно терпить невдачу. Іноді це нападник; іноді — ваша автоматизація.

Виправлення: Перевірте Security логи: шаблони 4625 і IP джерела. Якщо з зовнішніх/неочікуваних діапазонів — блокуйте. Якщо з внутрішніх хостів — знайдіть джерело збережених облікових даних (завдання, сервіс, кешований RDP). Скиньте й оновіть.

4) «Ми обмежили брандмауер підмережею VPN, але люди все одно підключаються з дому без VPN»

Симптом: Підключення успішні з публічних IP.

Корінь проблеми: Інше правило брандмауера дозволяє це (вищий пріоритет), або є зовнішнє правило з NAT hairpinning, або ви обмежили неправильне правило (UDP vs TCP, або інша назва відображення).

Виправлення: Перелічіть усі вхідні правила, які посилаються на 3389 і групи Remote Desktop; перевірте ефективну політику; відключіть широкі правила; увімкніть логування заблокованого трафіку і повторно тестуйте з зовнішньої мережі.

5) «Ми перемістили RDP на інший порт і атаки припинилися» (поки що)

Симптом: Менше записів у логах; менше алертів.

Корінь проблеми: Ви зменшили шум, а не ризик. Нападники сканують усі порти; ви просто на деякий час впали з низькосячкового списку.

Виправлення: Поверніть стандарт, якщо вам подобається уніфікація. Важливіше: усуньте інтернет-експозицію, вимагайте NLA, впровадьте MFA через шлях доступу, обмежте джерела і моніторте. Зниження шуму — не контроль.

6) «RDP повільний і ненадійний»

Симптом: Часті розриви, лаг, чорні екрани.

Корінь проблеми: Часто дефіцит ресурсів (CPU/пам’ять), або проблеми мережевого шляху (втрати пакетів, MTU-проблеми на VPN), або переповнений хост сесій.

Виправлення: Перевірте кількість сесій, CPU/пам’ять і події для причин розривів. Розділяйте питання продуктивності від безпеки, але не дозволяйте «виправленням продуктивності» послаблювати контролі безпеки.

7) «Ми маємо RD Gateway, тож ми в безпеці»

Симптом: Прямий RDP усе ще відкритий «на випадок аварії», і його використовують.

Корінь проблеми: Культурна хаканина. Шлях для аварійних ситуацій стає основним, бо він простіший.

Виправлення: Приберіть прямий вхідний RDP. Якщо потрібен break-glass шлях — він має бути тимчасовим, залогованим і вимагати явного дозволу з MFA.

Чеклісти / покроковий план

Фаза 0: Визначте, яким RDP може бути

Політика: «RDP лише для внутрішнього використання.» Запишіть це.
Метод доступу: Виберіть VPN+MFA або RD Gateway+MFA (або обидва).
Модель адміністрування: Виділені акаунти адміністраторів; ніяких спільних локальних адмінів; використовуйте LAPS/Windows LAPS.
Логування: Security + TerminalServices логи централізовано зберігаються, з алертингом на аномалії.

Фаза 1: Приберіть експозицію

На периметрі блокуйте вхідний TCP/3389 (і UDP/3389, якщо застосовано) з інтернету.
Якщо не можете заблокувати глобально — блокуйте по хостам і документуйте винятки з власниками й датою закінчення.
На кожному хості обмежте правила RDP брандмауера підмережами VPN/jump host-ів.
Перевірте з зовнішньої мережі, що 3389 закритий.

Фаза 2: Загартуйте аутентифікацію

Увімкніть NLA всюди.
Впровадьте MFA на VPN/RD Gateway.
Забезпечте мінімальну довжину пароля та історію; уникайте слабких винятків для сервісних акаунтів.
Встановіть поріг/вікно/тривалість блокування відповідно до вашого середовища (та спочатку зменшіть експозицію, щоб уникнути DoS через блокування).

Фаза 3: Зменшіть зону ураження

Використовуйте окремі акаунти адміністраторів (без пошти, без браузингу) і обмежуйте місця входу.
Обмежте членство в «Remote Desktop Users» до виділених груп.
Сегментуйте мережі так, щоб користувацькі підмережі за замовчуванням не могли RDP до серверів.
Переконайтеся, що EDR/Defender увімкнено і захист від втручання налаштований відповідно до стандартів організації.

Фаза 4: Зробіть систему спостережуваною

Увімкніть політику аудиту для успішних/невдалих входів.
Збирайте 4624/4625 та operational-логи TerminalServices централізовано.
Алертуйте на:
- Сплеск 4625 з одного IP або з багатьох IP
- 4624 Logon Type 10 з неуправлінських IP-діапазонів
- RDP входи поза очікуваними вікнами змін для критичних серверів
Щомісяця проводьте перевірки експозиції (зовнішнє сканування + внутрішня перевірка).

Питання та відповіді

1) Чи допомагає зміна порту RDP?

Вона зменшує шум, але не ризик. Це може створити невелику перепону, але сканери це знаходять. Робіть це тільки якщо це допомагає стандартизації у вашому середовищі, а не як основний контроль.

2) Чи достатньо NLA для захисту RDP?

Ні. NLA необхідне, але недостатнє. Потрібен ще обмежений мережевий доступ (VPN/RD Gateway), MFA і належний контроль облікових записів.

3) Чи варто дозволяти RDP лише з allowlist IP?

Так, якщо allowlist стабільний (підмережі VPN, IP jump host-ів, адмін-VLAN). Уникайте allowlist для випадкових домашніх IP; це стає неможливо підтримувати і заохочує винятки.

4) Які Event ID найважливіші для розслідування RDP?

Почніть із Security логів 4624 (успішний вхід) і 4625 (невдалий вхід). У доменних середовищах також стежте за подіями блокування (4740). Додайте operational-логи TerminalServices RemoteConnectionManager для кореляції, специфічної для RDP.

5) Нам треба, щоб вендори підключалися по RDP. Який мінімально поганий підхід?

Використовуйте RD Gateway або VPN з MFA, обмежуйте членство в групах, давайте доступ з часовими обмеженнями і звітуйте про це. «Постійний вендор локальний адміністратор» — це шлях до постійних інцидентів з боку вендора.

6) Чи потрібен UDP/3389 відкритий?

Багато середовищ можуть працювати лише на TCP, але функції продуктивності можуть використовувати UDP. З погляду безпеки, ставтеся до UDP-експозиції так само: обмежуйте джерела і уникайте інтернет-експозиції. Перед відключенням тестуйте з вашими клієнтами.

7) Який найшвидший виграш, якщо я успадкував безладну інфраструктуру?

Заблокуйте вхідний RDP на периметрі, потім обмежте правила брандмауера хостів до мереж управління. Це миттєво обриває масове сканування й brute force з інтернету.

8) Якщо ми використовуємо RD Gateway, чи можемо залишити прямий RDP відкритим як резерв?

Не можна. Резервні шляхи стають основними під тиском. Якщо потрібен break-glass шлях — зробіть його тимчасовим, захищеним MFA і залогованим з явним дозволом.

9) Як зрозуміти, чи наші «атаки RDP» реальні чи просто інтернет-шум?

Якщо бачите невдалі входи (4625) з публічних IP — це шум, але все одно проблема, бо вказує на експозицію. Якщо бачите будь-який успішний вхід (4624 тип 10) з несподіваних джерел — це реальна загроза.

10) Чи варто повністю відключити RDP на серверах?

Якщо ви можете керувати серверами через безпечніші канали (інструменти віддаленого управління, just-in-time admin, консольний доступ) — так, скорочуйте кількість машин з доступним RDP. Для решти — тримайте RDP приватним і контрольованим.

Практичні наступні кроки

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

Інвентаризація: Знайдіть кожен Windows-хост з увімкненим RDP і кожен шлях, що може його досягнути (внутрішній і зовнішній).
Закриття експозиції: Заблокуйте вхідний RDP на периметрі. Потім обмежте правила брандмауера хостів до джерел VPN/jump.
Впровадьте NLA: Увімкніть всюди, приберіть винятки, оновіть клієнтів.
Додайте MFA у шлях доступу: VPN або RD Gateway, з політикою, що адміністратори використовують керовані пристрої.
Виправте гігієну адміністраторів: Розділіть акаунти адміністраторів, приберіть широкі RDP-дозволи, розгорніть LAPS/Windows LAPS.
Операціоналізуйте телеметрію: Увімкніть аудит входів, збирайте логи централізовано і налаштуйте алерти на кілька важливих сигналів.
Доведіть це: Пере запускайте наведені вище команди після змін. Якщо ви не можете довести базу — у вас не базова конфігурація, а відчуття.

Схожі статті

Безпека RDP: 9 кроків для зміцнення перед відкриттям порту 3389