{"id":41229,"date":"2020-02-06T20:43:00","date_gmt":"2020-02-06T17:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/opasno-li-derzhat-otkrytym-rdp-v-internete"},"modified":"2020-02-06T20:43:00","modified_gmt":"2020-02-06T17:43:00","slug":"opasno-li-derzhat-otkrytym-rdp-v-internete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/opasno-li-derzhat-otkrytym-rdp-v-internete","title":{"rendered":"Is it dangerous to keep RDP open on the Internet?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I have often read the opinion that keeping the RDP (Remote Desktop Protocol) port open to the Internet is quite unsafe, and one should not do so. Access to RDP should be provided either through VPN or only from specific 'white' IP addresses.<\/p>\n

<\/p>\n

I administer several Windows Servers for small companies, where I've been tasked with ensuring remote access to Windows Server for accountants. This is a modern trend\u2014working from home. I quickly realized that forcing accountants to use a VPN is a thankless job, and gathering all the IP addresses for whitelisting is impractical due to people having dynamic IP addresses.<\/p>\n

<\/p>\n

Therefore, I took the simplest route\u2014I exposed the RDP port externally. Now, accountants need to launch RDP and enter the hostname (including the port), username, and password.<\/p>\n

<\/p>\n

In this article, I will share my experiences (both positive and negative) and recommendations.<\/p>\n

<\/a><\/noindex><\/p>\n

Risks<\/h3>\n

<\/p>\n

What risks do you face by opening the RDP port?<\/p>\n

<\/p>\n

1) Unauthorized access to sensitive data<\/b>
\nIf someone manages to guess the RDP password, they will be able to access the data you want to keep private: account statuses, balances, client information, ...<\/p>\n

<\/p>\n

2) Data loss<\/b>
\nFor example, due to the actions of ransomware.
\nOr a deliberate attack by an attacker.<\/p>\n

<\/p>\n

3) Loss of workstation<\/b>
\nEmployees need to work, and if the system is compromised, it must be reinstalled\/restored\/configured.<\/p>\n

<\/p>\n

4) Compromise of the local network<\/b>
\nIf an attacker gains access to a Windows computer, they can then access systems that are not available from outside, from the Internet. For example, to file shares, network printers, etc.<\/p>\n

\nI had a case where a Windows Server contracted ransomware<\/b><\/p>\n

and this ransomware first encrypted most of the files on the C: drive and then started encrypting files on the NAS over the network. Since the NAS was a Synology with configured snapshots, I restored the NAS in 5 minutes, while I had to reinstall the Windows Server from scratch.<\/p>\n

<\/p>\n

Observations and Recommendations<\/h3>\n

<\/p>\n

I monitor Windows Servers using Winlogbeat<\/a><\/noindex>, which sends logs to ElasticSearch. In Kibana, there are several visualizations, and I have set up a custom dashboard.
\nMonitoring itself does not provide protection but helps identify necessary measures.<\/p>\n

<\/p>\n

Here are some observations:
\na) RDP will be brute-forced.<\/b>
\nOn one of the servers, I set up RDP not on the standard port 3389, but on 443 \u2014 to kind of disguise it as HTTPS. Changing the port from the standard one is probably a good idea, but it doesn't help much. Here's the statistics from that server:<\/p>\n

\n\"Is<\/p>\n

You can see that there were almost 400,000 failed attempts to access via RDP over the week.
\nIt's evident that the access attempts came from 55,001 IP addresses (some IP addresses had already been blocked by me).<\/p>\n

<\/p>\n

This clearly suggests that I need to install fail2ban, but <\/p>\n

\nThere is no such utility for Windows.<\/b><\/p>\n

There are a couple of abandoned projects on GitHub that seem to do this, but I haven't tried installing them:
\nhttps:\/\/github.com\/glasnt\/wail2ban<\/a><\/noindex>
\nhttps:\/\/github.com\/EvanAnderson\/ts_block<\/a><\/noindex><\/p>\n

<\/p>\n

There are also paid utilities, but I haven\u2019t considered them.<\/p>\n

<\/p>\n

If you know of an open-source utility for this purpose, please share in the comments.<\/p>\n

<\/p>\n

Update<\/strong>: Comments suggested that port 443 is a poor choice, and it's better to choose higher ports (32000+), as 443 is scanned more frequently, making it easy to identify RDP on this port.<\/p>\n

<\/p>\n

Update:<\/strong> Comments indicated that such a utility exists:
\nhttps:\/\/github.com\/digitalruby\/ipban<\/a><\/noindex><\/p>\n

<\/p>\n

b) There are certain usernames that attackers prefer<\/b>
\nIt\u2019s clear that the brute force is going through a dictionary of various names.
\nBut here's what I've noticed: a significant number of attempts involve using the server name as the login. Recommendation: do not use the same name for the computer and the user. Moreover, sometimes it seems like the server name is being parsed: for example, for a system with the name DESKTOP-DFTHD7C, the most attempts come with the name DFTHD7C:<\/p>\n

\n\"Is<\/p>\n

Correspondingly, if you have a computer DESKTOP-MARIA, there will probably be attempts to log in as user MARIA.<\/p>\n

<\/p>\n

Additionally, what I noticed from the logs: on most systems, the majority of login attempts use the username 'administrator'. This is no coincidence, as in many versions of Windows, this user exists. Moreover, it cannot be deleted. This simplifies the task for attackers: instead of guessing both the username and password, they only need to guess the password.
\nBy the way, the system that got hit by the ransomware had the user Administrator and the password Murmansk#9. I'm still not sure how that system was compromised, as I started monitoring right after that incident, but I think brute-forcing is likely.
\nSo if the Administrator user can't be deleted, what should be done? You can rename it!<\/p>\n

<\/p>\n

Recommendations from this point: <\/p>\n

<\/p>\n