Опасно ли держать открытым RDP в Интернете?
Нередко я читал мнение, что держать RDP (Remote Desktop Protocol) порт открытым в Интернет — это весьма небезопасно, и делать так не надо. А надо доступ к RDP давать или через VPN, или только с определённых «белых» IP адресов.
Я администрирую несколько Windows Server для небольших фирм, в которых мне поставили задачу обеспечить удалённый доступ к Windows Server для бухгалтеров. Такой вот современный тренд — работа из дома. Достаточно быстро я понял, что мучить бухгалтеров VPN — неблагодарное занятие, а собрать все IP для белого списка не получится, потому что IP адреса у народа — динамические.
Поэтому я пошёл самым простым путём — пробросил RDP порт наружу. Теперь для доступа бухгалтерам нужно запустить RDP и ввести имя хоста (включая порт), имя пользователя и пароль.
В этой статье я поделюсь опытом (положительным и не очень) и рекомендациями.
Риски
Чем вы рискуете открывая порт RDP?
1) Неавторизованный доступ к чувствительным данным
Если кто-то подберёт пароль к RDP, то он сможет получить данные, которые вы хотите держать приватными: состояние счетов, балансы, данные клиентов, …
2) Потеря данных
Например в результате работы вируса-шифровальщика.
Или целенаправленного действия злоумышленника.
3) Потеря рабочей станции
Работникам нужно работать, а система — скомпроментирована, нужно переустанавливать / восстанавливать / конфигурировать.
4) Компроментация локальной сети
Если злоумышленник получил доступ к Windows-компьютеру, то уже с этого компьютера он сможет иметь доступ к системам, которые недоступны извне, из Интернета. Например к файл-шарам, к сетевым принтерам и т.д.
и этот шифровальщик сначала зашифровал большинство файлов на диске C:, а затем начал шифровать файлы на NAS по сети. Так как NAS была Synology, с настроенными snapshots, то NAS я восстановил за 5 минут, а Windows Server переустанавливал с нуля.
Наблюдения и Рекомендации
Я мониторю Windows Servers с помощью Winlogbeat, которые шлют логи в ElasticSearch. В Kibana есть несколько визуализаций, а я ещё настроил себе кастомную дэшборд.
Сам мониторинг не защищает, но помогает определиться с необходимыми мерами.
Вот некоторые наблюдения:
a) RDP будут брут-форсить.
На одном из серверов я RDP повесил не на стандартный порт 3389, на 443 — ну типа замаскируюсь под HTTPS. Порт сменить со стандартного, наверное стоит, но толку от этого немного. Вот статистика с этого сервера:
Видно, что за неделю было почти 400 000 неудачных попыток зайти по RDP.
Видно, что попытки зайти были с 55 001 IP адресов (некоторые IP адреса уже были заблокированы мной).
Тут прямо напрашивается вывод о том, что нужно ставить fail2ban, но
Есть пара заброшенных проектов на Гитхабе, которые вроде бы это делают, но я даже не пробовал их ставить:
https://github.com/glasnt/wail2ban
https://github.com/EvanAnderson/ts_block
Ещё есть платные утилиты, но я их не рассматривал.
Если вы знаете открытую утилиту для этой цели — поделитесь в комментариях.
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 ещё есть Auditbeat, который может следить за файлами и процессами на системе. Ещё есть SIEM (Security Information & Event Management) приложение в Kibana. Я пробовал и то и другое, но пользы особо не увидел — похоже Auditbeat будет более полезен для Linux систем, а SIEM ничего внятного мне пока не показал.
Ну и финальная рекомендация:
- делайте регулярные автоматические бэкапы.
