Нерідко я читав думку, що тримати RDP (Remote Desktop Protocol) порт відкритим в Інтернеті — це дуже небезпечно, і робити так не треба. А треба доступ до RDP давати або через VPN, або лише з певних "білих" IP-адрес.
Я адмініструю кілька Windows Server для невеликих фірм, у яких мені поставили завдання забезпечити віддалений доступ до Windows Server для бухгалтерів. Такий сучасний тренд — робота з дому. Досить швидко я зрозумів, що мучити бухгалтерів VPN — невдячне заняття, а зібрати всі IP для білого списку не вийде, тому що адреси IP у народу — динамічні.
Тому я пішов найпростішим шляхом – прокинув RDP порт назовні. Тепер для доступу бухгалтерам потрібно запустити RDP та ввести ім'я хоста (включаючи порт), ім'я користувача та пароль.
У цій статті я поділюся досвідом (позитивним і не дуже) та рекомендаціями.
Ризики
Чим ви ризикуєте, відкриваючи порт RDP?
1) Неавторизований доступ до чутливих даних
Якщо хтось підбере пароль до RDP, він зможе отримати дані, які ви хочете тримати приватними: стан рахунків, баланси, дані клієнтів, …
2) Втрата даних
Наприклад в результаті роботи вірусу-шифрувальника.
Або цілеспрямованої дії зловмисника.
3) Втрата робочої станції
Працівникам потрібно працювати, а система - скомпроментована, потрібно встановлювати заново / відновлювати / конфігурувати.
4) Компроментація локальної мережі
Якщо зловмисник отримав доступ до комп'ютера Windows, то вже з цього комп'ютера він зможе мати доступ до систем, які недоступні ззовні, з Інтернету. Наприклад до файл-куль, мережевих принтерів і т.д.
У мене був випадок, коли Windows Server зловив шифрувальника
і цей шифрувальник спочатку зашифрував більшість файлів на диску C:, а потім почав шифрувати файли на NAS по мережі. Так як NAS була Synology, з налаштованими snapshots, то NAS я відновив за 5 хвилин, а Windows Server встановлював з нуля.
Спостереження та Рекомендації
Я моніторію Windows Servers за допомогою які шлють логи в ElasticSearch. У Kibana є кілька візуалізацій, а я ще настроїв собі кастомну дешборд.
Сам моніторинг не захищає, але допомагає визначитись із необхідними заходами.
Ось деякі спостереження:
a) RDP будуть брут-форсити.
На одному із серверів я RDP повісив не на стандартний порт 3389, на 443 — типу замаскуюся під HTTPS. Порт змінити зі стандартного, напевно варто, але користі від цього небагато. Ось статистика з цього сервера:
Видно, що за тиждень було майже 400 тисяч невдалих спроб зайти по RDP.
Видно, що спроби зайти були з 55 001 IP-адрес (деякі IP-адреси вже були заблоковані мною).
Тут прямо напрошується висновок у тому, що треба ставити fail2ban, але
для Windows такої утиліти немає.
Є пара занедбаних проектів на Гітхабі, які начебто це роблять, але я навіть не пробував їх ставити:
Ще є платні утиліти, але їх не розглядав.
Якщо ви знаєте відкриту утиліту для цієї мети, поділіться в коментарях.
Оновити: У коментарях підказали, що порт 443 - невдалий вибір, а краще вибирати високі порти (32000+), тому що 443 сканується частіше, і розпізнати RDP на цьому порту - не проблема
b) Є певні username, які зловмисники віддають перевагу
Видно, що перебір іде за словником із різними іменами.
Але ось що я помітив: значна кількість спроб – це використання імені сервера як логіна. Рекомендація: не використовуйте однакове ім'я для комп'ютера та користувача. Причому іноді схоже ім'я сервера намагаються якось розпарсувати: наприклад для системи з ім'ям DESKTOP-DFTHD7C найбільше спроб зайти з ім'ям DFTHD7C:
Відповідно, якщо у вас буде комп'ютер DESKTOP-MARIA, то, ймовірно, будуть йти спроби заходити під користувачем MARIA.
Ще, що я помітив із логів: на більшості систем більшість спроб зайти — це з ім'ям "administrator". І це недарма, тому що в багатьох версіях Windows це користувач існує. Більше того, його не можна видалити. Це спрощує завдання для зловмисників: замість підбору імені та пароля потрібно лише підібрати пароль.
До речі та система, яка в мене зловила шифрувальника, мала користувача Administrator і пароль Murmansk#9. Я досі не впевнений, як зламали ту систему, бо моніторити я почав саме після того випадку, але гадаю, що перебір — імовірний.
Так якщо користувача Administrator не можна видалити, то що робити? Його можна перейменувати!
Рекомендації з цього пункту:
- не використовуйте ім'я користувача в назві комп'ютера
- переконайтеся, що на системі немає користувачів Administrator
- використовуйте надійні паролі
Ось таким чином, я спостерігаю, як кілька Windows Server під моїм контролем брут-форсять вже десь пару років, і безуспішно.
Звідки я знаю, що безуспішно?
Тому що на скріншотах вище видно, що є логи успішних заходів RDP, в яких є інформація:
- з якого IP
- з якого комп'ютера (hostname)
- Ім'я користувача
- GeoIP інформація
І я регулярно туди подивляюсь — аномалій не виявлено.
До речі, якщо з якогось IP брут-форсят особливо старанно, то заблокувати окремі IP (або підмережі) можна ось так у PowerShell:
New-NetFirewallRule -Direction Inbound -DisplayName "fail2ban" -Name "fail2ban" -RemoteAddress ("185.143.0.0/16", "185.153.0.0/16", "193.188.0.0/16") -Action BlockДо речі, у Elastic, крім Winlogbeat ще є , який може стежити за файлами та процесами на системі. Ще є SIEM (Security Information & Event Management) додаток у Kibana. Я пробував і те, й інше, але користі особливо не побачив - схоже Auditbeat буде кориснішим для Linux систем, а SIEM нічого виразного мені поки не показав.
Ну і фінальні рекомендації:
- робіть регулярні автоматичні бекапи.
- вчасно ставте Security Updates
Бонус: список із 50 користувачів, які найчастіше використовувалися для спроб входу по RDP
"user.name: Descending"
Рахувати
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
АДМІНІСТРАТОР
180678
адміністратор
163842
адміністратор
53541
Майкл
23101
сервер
21983
Стів
21936
Джон
21927
Пол
21913
прийом
21909
мікрофон
21899
офіс
21888
сканер
21887
сканування
21867
Девід
21865
Кріс
21860
власник
21855
менеджер
21852
Administrateur
21841
Бріан
21839
адміністратор
21837
позначити
21824
персонал
21806
ADMIN
12748
ROOT
7772
АДМІНІСТРАТОР
7325
ПІДТРИМКА
5577
ПІДТРИМКА
5418
USER
4558
адмін
2832
TEST
1928
MySql
1664
Адміністратор
1652
ГІСТЬ
1322
КОРИСТУВАЧ1
1179
СКАНЕР
1121
SCAN
1032
АДМІНІСТРАТОР
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
ПРИЙМ
490
КОРИСТУВАЧ2
466
TEMP
452
SQLADMIN
450
КОРИСТУВАЧ3
441
1
422
МЕНЕДЖЕР
418
ВЛАСНИК
410
Джерело: habr.com