Often I read the opinion that keeping the RDP (Remote Desktop Protocol) port open on the Internet is very insecure, and you don’t need to. And you need to give access to RDP either through a VPN, or only from certain “white” IP addresses.

I administer several Windows Server for small companies, in which I was tasked with providing remote access to Windows Server for accountants. Such a modern trend is work from home. Quickly enough, I realized that tormenting VPN accountants is an ungrateful task, and collecting all the IPs for the white list will not work, because the IP addresses of the people are dynamic.

So I went the simplest way – I forwarded the RDP port out. Now, for access, accountants need to run RDP and enter the host name (including port), username and password.

In this article I will share my experience (positive and not) and recommendations.

The risks

What are the risks of opening the RDP port?

Unauthorized access to sensitive data

If someone selects a password for RDP, he will be able to get the data that you want to keep private: account status, balances, customer data,…

Data loss

For example, as a result of the work of the encryption virus.

Or targeted action by an attacker.

Workstation loss

Workers need to work, and the system is compromised, you need to reinstall / restore / configure.

Compromise of the local network

If an attacker gained access to a Windows computer, then from that computer he will be able to access systems that are not accessible from the outside, from the Internet. For example,to network printers, etc.

Observations and Recommendations

I monitor Windows Servers using Winlogbeat, which send logs to ElasticSearch. Kibana has several visualizations, and I also set up a custom dashboard for myself.

Monitoring itself does not protect, but helps to determine the necessary measures.

Here are some observations:

1. a) RDP will be brute force.

On one of the servers I didn’t put RDP on the standard port 3389, on 443 — well, I’ll disguise myself as HTTPS. It’s probably worth changing the port from the standard one, but there’s little sense in it.

It can be seen that during the week there were almost 400,000 unsuccessful attempts to enter the RDP.

It can be seen that the attempts to enter were from 55,001 IP addresses (some IP addresses were already blocked by me).

Here the conclusion directly suggests that you need to set fail2ban, but

1. b) There are certain username that attackers prefer

It can be seen that the search goes through the dictionary with different names.

But here is what I noticed: a significant number of attempts are using the server name as login. Recommendation: do not use the same name for the computer and for the user. Moreover, sometimes they seem to try to parse the server name: for example, for a system with the name DESKTOP-DFTHD7C, the most attempts are to enter with the name DFTHD7C.

Accordingly, if you have a DESKTOP-MARIA computer, then there will probably be attempts to log in as user MARIA.

Also, what I noticed from the logs: on most systems, most attempts to log in are with the name “administrator”. And this is no accident, because in many versions of Windows, this user exists.

This simplifies the task for attackers: instead of selecting a name and password, you only need to pick up a password.

By the way, the system that I caught the cryptographer had the Administrator user and Murmansk # 9 password. I’m still not sure how the system was hacked, because I started monitoring right after that incident, but I think that busting is possible.

So if the Administrator user cannot be deleted, then what should I do? You can rename it!

Recommendations from this paragraph:

•     do not use username in computer name
•     make sure there is no Administrator user on the system
•     use strong passwords
  

So in this way, I am observing how several Windows Server under my control have brute-forced for about a couple of years, and to no avail.

How do I know it is unsuccessful?

Because there are logs of successful calls on RDP, in which there is information:

•     what IP
•     from which computer (hostname)
•     Username
•     GeoIP Information

And I regularly look there – no anomalies were found.

By the way, Elastic, in addition to Winlogbeat, also has Auditbeat, which can monitor files and processes on the system. There is also a SIEM (Security Information & Event Management) application in Kibana. I tried both, but I didn’t see much benefit – Auditbeat seems to be more useful for Linux systems, and SIEM hasn’t shown anything intelligible to me yet.

Well, the final recommendations:

•      do regular automatic backups
•      put Security Updates on time.