Нередко я читал мнение, что держать 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 Ещё есть платные утилиты, но я их не рассматривал. Если вы знаете открытую утилиту для этой цели — поделитесь в комментариях. Update: В комментариях подсказали, что порт 443 — неудачный выбор, а лучше выбирать высокие порты (32000+), потому что 443 сканируется чаще, и распознать RDP на этом порту — не проблема. Update: В комментариях подсказали, что такая утилита есть:
https://github.com/digitalruby/ipban После запуска IPBan, количество неуспешных логинов радикально упало:
 2020-02-11 00:01:18.2517|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 31.131.251.228,, RDP, 1
2020-02-11 00:01:18.2686|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 31.131.251.228, Administrator, RDP, 2
2020-02-11 00:02:49.7098|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 95.213.143.147,, RDP, 3
2020-02-11 00:02:49.7098|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 95.213.143.147, Administrator, RDP, 4
2020-02-11 00:04:20.9878|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 95.213.184.20,, RDP, 5
2020-02-11 00:04:20.9878|WARN|DigitalRuby.IPBanCore.Logger|Banning ip address: 95.213.184.20, user name:, config black listed: False, count: 5, extra info:
2020-02-11 00:04:20.9878|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 95.213.184.20, Administrator, RDP, 5
2020-02-11 00:04:21.0040|WARN|DigitalRuby.IPBanCore.Logger|IP 95.213.184.20, Administrator, RDP ban pending.
2020-02-11 00:04:21.1237|WARN|DigitalRuby.IPBanCore.Logger|Updating firewall with 1 entries…
2020-02-11 00:05:36.6525|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 31.131.251.24,, RDP, 3
2020-02-11 00:05:36.6566|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 31.131.251.24, Administrator, RDP, 4
2020-02-11 00:07:22.4729|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 82.202.249.225, Administrator, RDP, 3
2020-02-11 00:07:22.4894|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 82.202.249.225,, RDP, 4
2020-02-11 00:08:53.1731|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 45.141.86.141,, RDP, 3
2020-02-11 00:08:53.1731|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 45.141.86.141, Administrator, RDP, 4
2020-02-11 00:09:23.4981|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 68.129.202.154,, RDP, 1
2020-02-11 00:09:23.5022|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 68.129.202.154, ADMINISTRATOR, RDP, 2
2020-02-11 00:10:39.0282|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 95.213.143.147,, RDP, 5
2020-02-11 00:10:39.0336|WARN|DigitalRuby.IPBanCore.Logger|Banning ip address: 95.213.143.147, user name:, config black listed: False, count: 5, extra info:
2020-02-11 00:10:39.0336|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 95.213.143.147, Administrator, RDP, 5
2020-02-11 00:10:39.0336|WARN|DigitalRuby.IPBanCore.Logger|IP 95.213.143.147, Administrator, RDP ban pending.
2020-02-11 00:10:39.1155|WARN|DigitalRuby.IPBanCore.Logger|Updating firewall with 1 entries…
2020-02-11 00:12:09.6470|WARN|DigitalRuby.IPBanCore.Logger|Login failure: 82.202.249.225,, RDP, 5
2020-02-11 00:12:09.6470|WARN|DigitalRuby.IPBanCore.Logger|Banning ip address: 82.202.249.225, user name:, config black listed: False, count: 5, extra info:  b) Есть определённые username, которые злоумышленники предпочитают
Видно, что перебор идёт по словарю с разными именами.
Но вот что я заметил: значительное количество попыток — это использование имени сервера, как логина. Рекомендация: не используйте одинаковое имя для компьютера и для пользователя. Причём, иногда похоже имя сервера пытаются как-то распарсить: например для системы с именем DESKTOP-DFTHD7C больше всего попыток зайти с именем DFTHD7C: Соответственно, если у вас будет компьютер DESKTOP-MARIA, то вероятно будут идти попытки заходить под пользователем MARIA. Ещё, что я заметил из логов: на большинстве систем, большинство попыток зайти — это с именем "administrator". И это неспроста, потому что во многих версиях Windows, это пользователь существует.  https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts#administrator-account
Administrator account
The default local Administrator account is a user account for the system administrator. Every computer has an Administrator account (SID S-1-5-domain-500, display name Administrator). The Administrator account is the first account that is created during the Windows installation. The Administrator account has full control of the files, directories, services, and other resources on the local computer. The Administrator account can create other local users, assign user rights, and assign permissions. The Administrator account can take control of local resources at any time simply by changing the user rights and permissions. The default Administrator account cannot be deleted or locked out, but it can be renamed or disabled. Это упрощает задачу для злоумышленников: вместо подбора имени и пароля нужно только подобрать пароль.
Кстати та система, которая у меня словила шифровальщика имела пользователя Administrator и пароль Murmansk#9. Я до сих не уверен, как взломали ту систему, потому что мониторить я начал как раз после того случая, но думаю, что перебор — вероятен.
Так если пользователя Administrator нельзя удалить, то что же делать? Его можно переименовать! Рекомендации из этого пункта:  Вот таким образом, я наблюдаю, как несколько Windows Server под моим контролем брут-форсятся уже где-то пару лет, и безуспешно. Откуда я знаю, что безуспешно?
Потому что на скриншотах выше видно, что есть логи успешных заходов по RDP, в которых есть информация: И я регулярно туда посматриваю — аномалий не обнаружено. Кстати, если с какого-то IP брут-форсят особо усердно, то заблокировать отдельные IP (или подсети) можно вот так в PowerShell: Кстати у Elastic, помимо Winlogbeat ещё есть Auditbeat, который может следить за файлами и процессами на системе. Ещё есть SIEM (Security Information & Event Management) приложение в Kibana. Я пробовал и то и другое, но пользы особо не увидел — похоже Auditbeat будет более полезен для Linux систем, а SIEM ничего внятного мне пока не показал. Ну и финальные рекомендации: Developer