How to avoid using RDP in Windows

This is Susan Bradley for CSO Online. This week I’m going to do a challenge to you and also to myself. So if this little window is how you access servers and how you manage servers, I’m going to challenge you to stop using remote desktop connection. So why am I saying that we should stop using RDP? Mainly because of three different vulnerabilities that have come out lately that really showcases how we’re still using a pretty archaic technology that’s putting us at risk. Both in May and in August a vulnerability has been released that basically when an un authenticated attacker can connect to a target system meeting RDP and they send specially crafted request to that port the vulnerability. Is such that the attacker doesn’t have to authenticate on the system. They can just basically throw those crafted packets right to that port 3389. And if the port is open and listening they could access the system and gain rights on the system they could install programs view change and delete data, create accounts with the full user rights on the system. For the first vulnerability we had back in May was so severe that they even released patches for older systems. They recommended that we disable remote desktop services, enable network level authentication and even block port 3389 at the enterprise permanent firewall.
Microsoft even went so far as to release updates out to Windows XP which I haven’t seen a patch for Windows XP for years and they released it to everyone not just those who purchase extended support contracts. So now comes along August and we have two more RDP vulnerabilities. Once again if the attacker has specially crafted packets they can throw them at Port 3389 and again if they gain access they can install programs change or delete data and create new accounts with full user rights. So it’s something you want to really take seriously and make sure that you patch as soon as possible especially if you have systems that you’re accessing straight to the port. Now while it’s been three months since the May updates came out regarding these RDP vulnerabilities. And in that time about a fifth of Internet facing RDP servers haven’t been patched. I want to make sure that you take this seriously and don’t just think just because we haven’t seen an exploit in the wild that it’s something to not take seriously. Open ports are vulnerable to not just exploits like this but to also brute force attacks where somebody sits out there and attempts to guess the password over and over again and finally gets into the system. So many times I hear of medical systems in particular on older platforms that the admin still uses RDP to access and to maintain the system. If RTP use and especially if it’s used by attackers it’s sometimes hard to determine exactly who the good guys are coming in and who the bad guys are. The log files aren’t clear. I’ve included a link in the article to help you determine. And sometimes it’s sometimes hard to determine which ones are the good guys and which ones are the bad guys you sometimes have to go through step by step. And look at both sides of the user side of the logs as well as the server side to determine which things are good authentication or which ones are bad. Back in February of this year I had an article on how to install powerful five on Windows 7 in particular. I recommended that because it enabled logging and also you could turn on PowerShell remoting. With PowerShell remoting you don’t have to open up RDP port or use 3389. You could do it in a secure way. And in fact I recommend that you do it over TLS or SSL. And I’ve got some recommendations on how to do that as well. But just a reminder again if this is how you connect to your servers and manage them. I want to challenge you to stop doing that and think about other ways you can script the same things PowerShell remoting is a very very powerful tool. So that you don’t have to use port 3389 and expose yourself to additional risks. And don’t forget sign up for the IDG tech talk channel out there on YouTube. Until next time this is Susan Bradley for CSO Online.

READ MORE HERE