Опасно ли держать открытым RDP в Интернете?

в 8:26, , рубрики: elasticsearch, rdp, remote desktop, антивирусная защита, Серверное администрирование

Нередко я читал мнение, что держать 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 с помощью Winlogbeat, которые шлют логи в ElasticSearch. В Kibana есть несколько визуализаций, а я ещё настроил себе кастомную дэшборд.
Сам мониторинг не защищает, но помогает определиться с необходимыми мерами.

Вот некоторые наблюдения:
a) RDP будут брут-форсить.
На одном из серверов я RDP повесил не на стандартный порт 3389, на 443 — ну типа замаскируюсь под HTTPS. Порт сменить со стандартного, наверное стоит, но толку от этого немного. Вот статистика с этого сервера:

Windows Logs in Kibana

Видно, что за неделю было почти 400 000 неудачных попыток зайти по RDP.
Видно, что попытки зайти были с 55 001 IP адресов (некоторые IP адреса уже были заблокированы мной).

Тут прямо напрашивается вывод о том, что нужно ставить fail2ban, но

для Windows такой утилиты - нету.

Есть пара заброшенных проектов на Гитхабе, которые вроде бы это делают, но я даже не пробовал их ставить:
https://github.com/glasnt/wail2ban
https://github.com/EvanAnderson/ts_block

Ещё есть платные утилиты, но я их не рассматривал.

Если вы знаете открытую утилиту для этой цели — поделитесь в комментариях.

Update: В комментариях подсказали, что порт 443 — неудачный выбор, а лучше выбирать высокие порты (32000+), потому что 443 сканируется чаще, и распознать RDP на этом порту — не проблема.

b) Есть определённые username, которые злоумышленники предпочитают
Видно, что перебор идёт по словарю с разными именами.
Но вот что я заметил: значительное количество попыток — это использование имени сервера, как логина. Рекомендация: не используйте одинаковое имя для компьютера и для пользователя. Причём, иногда похоже имя сервера пытаются как-то распарсить: например для системы с именем DESKTOP-DFTHD7C больше всего попыток зайти с именем DFTHD7C:

image

Соответственно, если у вас будет компьютер 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 ещё есть Auditbeat, который может следить за файлами и процессами на системе. Ещё есть SIEM (Security Information & Event Management) приложение в Kibana. Я пробовал и то и другое, но пользы особо не увидел — похоже Auditbeat будет более полезен для Linux систем, а SIEM ничего внятного мне пока не показал.

Ну и финальные рекомендации:

  • делайте регулярные автоматические бэкапы.
  • своевременно ставьте Security Updates

Бонус: список из 50 пользователей, которые чаще использовались для попыток входа по RDP

"user.name: Descending" Count
dfthd7c (hostname) 842941
winsrv1 (hostname) 266525
ADMINISTRATOR 180678
administrator 163842
Administrator 53541
michael 23101
server 21983
steve 21936
john 21927
paul 21913
reception 21909
mike 21899
office 21888
scanner 21887
scan 21867
david 21865
chris 21860
owner 21855
manager 21852
administrateur 21841
brian 21839
administrador 21837
mark 21824
staff 21806
ADMIN 12748
ROOT 7772
ADMINISTRADOR 7325
SUPPORT 5577
SOPORTE 5418
USER 4558
admin 2832
TEST 1928
MySql 1664
Admin 1652
GUEST 1322
USER1 1179
SCANNER 1121
SCAN 1032
ADMINISTRATEUR 842
ADMIN1 525
BACKUP 518
MySqlAdmin 518
RECEPTION 490
USER2 466
TEMP 452
SQLADMIN 450
USER3 441
1 422
MANAGER 418
OWNER 410

Автор: Славик Фурсов

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js