I often read the opinion that keeping an RDP (Remote Desktop Protocol) port open to the Internet is very unsafe, and you shouldn't do it. And it is necessary to give access to RDP either through VPN, or only from certain "white" IP addresses.
I administer several Windows Servers for small businesses where I have been tasked with providing remote access to Windows Server for accountants. Such is the current trend - work from home. Quite quickly, I realized that tormenting VPN accountants is a thankless task, and collecting all the IPs for the whitelist will not work, because the IP addresses of the people are dynamic.
Therefore, I went the simplest way - I forwarded the RDP port to the outside. Accountants now need to run RDP and enter the hostname (including port), username, and password to gain access.
In this article I will share my experience (positive and not so) and recommendations.
Risks
What are you risking by opening an RDP port?
1) Unauthorized access to sensitive data
If someone guesses the password to RDP, then he can get the data that you want to keep private: account status, balances, customer data, ...
2) Loss of data
For example, as a result of the operation of a ransomware virus.
Or the targeted action of an attacker.
3) Loss of workstation
Employees need to work, and the system is compromised, needs to be reinstalled / restored / configured.
4) Compromising the local network
If an attacker has gained access to a Windows computer, then from this computer he will be able to access systems that are inaccessible from the outside, from the Internet. For example, to file-balls, to network printers, etc.
I had a case where Windows Server caught a ransomware
and this ransomware first encrypted most of the files on the C: drive and then started to encrypt the files on the NAS over the network. Since the NAS was Synology, with snapshots configured, I restored the NAS in 5 minutes, and reinstalled Windows Server from scratch.
Observations and Recommendations
I monitor Windows Servers with , 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:
a) RDP will brute force.
On one of the servers, I hung RDP not on the standard port 3389, but on 443 - well, Iβll disguise myself as HTTPS. It's probably worth changing the port from the standard one, but it's a little useless. Here are the statistics from that server:
It can be seen that in a week there were almost 400 unsuccessful attempts to enter via RDP.
It can be seen that there were attempts to enter from 55 IP addresses (some IP addresses have already been blocked by me).
This directly suggests the conclusion that you need to install fail2ban, but
there is no such utility for Windows.
There are a couple of abandoned projects on Github that seem to do this, but I have not even tried to install them:
There are also paid utilities, but I did not consider them.
If you know an open utility for this purpose, share it in the comments.
Update: The comments suggested that port 443 is a bad choice, but it is better to choose high ports (32000+), because 443 is scanned more often, and recognizing RDP on this port is not a problem.
b) There are certain usernames that attackers prefer
It can be seen that the enumeration goes through the dictionary with different names.
But here's what I noticed: a significant number of attempts is the use of the server name as a login. Recommendation: Do not use the same name for the computer and for the user. Moreover, sometimes it seems that they try to somehow parse the server name: for example, for a system named DESKTOP-DFTHD7C, the most attempts to enter with the name DFTHD7C:
Accordingly, if you have a DESKTOP-MARIA computer, then there will probably be attempts to log in as the MARIA user.
Another thing 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. Moreover, it cannot be deleted. This simplifies the task for attackers: instead of guessing a name and password, you only need to guess the password.
By the way, the system that caught the ransomware from me had an Administrator user and a Murmansk#9 password. I'm still not sure how that system was hacked, because I started monitoring just after that incident, but I think that bust is likely.
So if the Administrator user cannot be deleted, then what to do? You can rename it!
Recommendations from this paragraph:
- do not use the username in the computer name
- make sure there is no Administrator user on the system
- use strong passwords
So, I've been watching several Windows Servers under my control brute force for a couple of years now, without success.
How do I know it's not successful?
Because the screenshots above show that there are logs of successful RDP logins that contain information:
- from which IP
- from which computer (hostname)
- Username
- GeoIP Information
And I regularly look there - no anomalies were found.
By the way, if brute-forcing is especially diligent from some IP, then you can block individual IPs (or subnets) like this in 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 BlockBy the way, Elastic, in addition to Winlogbeat, also has , 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 - it looks like Auditbeat will be more useful for Linux systems, and SIEM hasnβt shown me anything intelligible yet.
And here are the final recommendations:
- make regular automatic backups.
- install Security Updates in a timely manner
Bonus: List of 50 Users Most Used for RDP Login Attempts
"username: 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
administrator
21841
brian
21839
administrator
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRATOR
7325
SUPPORT
5577
SUPPORT
5418
USER
4558
admin
2832
TESTS puedo modificarlo
1928
MySql
1664
admin
1652
GUEST
1322
USER1
1179
TO SCAN
1121
SCAN
1032
ADMINISTRATOR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPTION
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
OWNER
410
Source: habr.com